如何让 Codex 根据岗位要求生成 JD 初稿
用 Codex 生成 JD 初稿,核心不是让它凭空写一份招聘文案,而是让它根据岗位要求、项目背景、团队职责、技术栈或业务文档,整理出可审核、可修改、可发布的岗位描述。对 HR、创业者和团队负责人来说,Codex 适合处理“信息分散、要求不清、职责难拆”的 JD 初稿生成任务。 如果你只有一句“招一个运营”或“招一个前端”,ChatGPT 就能先帮你梳理方向;
发布时间 2026/07/04

用 Codex 生成 JD 初稿,核心不是让它凭空写一份招聘文案,而是让它根据岗位要求、项目背景、团队职责、技术栈或业务文档,整理出可审核、可修改、可发布的岗位描述。对 HR、创业者和团队负责人来说,Codex 适合处理“信息分散、要求不清、职责难拆”的 JD 初稿生成任务。 如果你只有一句“招一个运营”或“招一个前端”,ChatGPT 就能先帮你梳理方向;如果岗位要求来自产品文档、代码仓库、README、项目规则、设计规范、技术栈说明和团队协作流程,Codex 更适合读取上下文,再生成更贴近真实工作的 JD 初稿。 达灵感的价值在于把这种流程沉淀下来:你可以把“岗位要求生成 JD 初稿”的任务指令保存到项目里,之后每次招聘设计师、开发者、运营、产品经理或数据分析师时,都能一键生成更完整的 Codex 执行指令。
为什么根据岗位要求写 JD 这件事很常见?
很多 JD 写得不好,不是因为 HR 不会写,而是因为岗位信息本身就不完整。业务负责人说“想招一个能独立负责增长的人”,技术负责人说“需要熟悉 Next.js 和 Supabase”,产品负责人又补充“最好能懂数据和转化漏斗”。这些信息如果不先整理,最后生成的 JD 很容易变成模板文案。
常见问题包括:岗位职责写得太泛,任职要求写得太高,技术要求和实际工作不匹配,福利描述像广告,团队背景缺失,面试筛选标准不清楚。更严重的问题是,JD 里可能出现未经确认的薪酬、承诺性表达或不合适的筛选语言。
Codex 生成 JD 初稿适合解决的是“从上下文中提取招聘需求”的问题,而不是替 HR 做最终决策。它可以帮助你把项目资料转成 JD 结构,把岗位要求拆成职责、能力、经验、加分项和面试关注点,但最终发布前仍需要 HR 或负责人审核。
写 JD 前先理解几个核心概念
-
Codex:OpenAI 面向软件开发的代码代理,适合读取项目、理解代码与文档、生成或修改工程文件。
-
ChatGPT:更适合讨论、解释、写作、头脑风暴和没有项目上下文的内容生成。
-
JD 初稿:根据岗位目标、职责、要求和团队背景整理出的第一版岗位描述,不等于最终招聘发布稿。
-
岗位要求:岗位需要完成什么工作、需要什么能力、对经验和工具有什么要求。
-
AGENTS.md:给 Codex 提供项目级工作规则的文件,可写入团队规范、输出格式和禁止事项。
-
Skills:可复用的任务能力包,适合把 JD 生成、审查、改写等流程沉淀成稳定工作流。
Codex 生成 JD 初稿和 ChatGPT 写 JD 有什么区别?
结论很直接:纯文案生成用 ChatGPT 更快;需要结合项目文件、仓库结构、业务资料和团队规则时,用 Codex 更稳。
| 对比项 | ChatGPT 更适合 | Codex 更适合 |
|---|---|---|
| 输入方式 | 你直接粘贴岗位要求,让它改写或扩展。 | 让它读取项目目录、README、技术栈说明、产品文档、团队规范。 |
| 理解深度 | 适合理解文字需求和生成通用 JD。 | 适合从真实项目上下文中判断岗位实际要做什么。 |
| 输出内容 | 岗位描述、职责、要求、福利、招聘文案。 | JD 初稿、岗位能力模型、面试关注点、缺失信息清单、Markdown 文件。 |
| 工程相关岗位 | 可以写前端、后端、设计、产品岗位的通用描述。 | 可以结合代码仓库与项目结构,提取真实技术要求和协作场景。 |
| 复用方式 | 通常停留在聊天记录里。 | 可以把生成规则写入 AGENTS.md、任务模板或项目文档。 |
| 适合场景 | 快速生成、改写、润色。 | 长期维护招聘标准、跨岗位复用、结合项目资料生成 JD。 |
哪些招聘任务适合用 Codex 生成 JD 初稿?
-
- 根据项目资料生成技术岗位 JD:适合前端、后端、全栈、AI 工程师等岗位。输入 README、package.json、架构说明和现有任务文档;输出岗位职责、技术要求、项目背景和面试关注点。
-
- 根据业务目标生成运营或增长岗位 JD:适合内容运营、SEO、增长、私域、广告投放岗位。输入业务目标、增长指标、渠道计划;输出职责边界、能力要求、结果指标和加分项。
-
- 根据设计项目生成设计师 JD:适合 UI/UX、品牌设计、动效、设计系统岗位。输入作品方向、设计流程、Figma 规范、产品类型;输出设计职责、协作要求、作品集筛选标准。
-
- 根据团队缺口生成岗位画像:适合还没有明确岗位名称时使用。输入当前团队成员、缺失能力、近期目标;输出推荐岗位名称、岗位级别、核心能力和招聘优先级。
-
- 根据旧 JD 生成新版 JD:适合岗位升级或招聘效果不好时使用。输入旧 JD、候选人反馈、面试记录;输出问题诊断、新版 JD 和修改说明。
-
- 生成面试筛选维度:适合把 JD 进一步变成面试评分表。输入 JD 初稿和岗位目标;输出筛选问题、评分维度、红旗信号和试题方向。
-
- 生成多版本 JD:适合同时发布在 Boss、拉勾、LinkedIn、官网招聘页。输入统一岗位要求;输出正式版、平台版、短版、英文版或内部评审版。
如何让 Codex 根据岗位要求生成 JD 初稿?
-
第一步:准备岗位上下文:至少准备岗位名称、业务目标、团队背景、工作内容、必须能力、加分能力、薪酬范围是否可公开、工作地点或远程方式。
-
第二步:让 Codex 先读资料,不要直接写:要求 Codex 先阅读项目文档、代码仓库、产品说明或旧 JD,然后列出它理解到的岗位需求。
-
第三步:要求输出缺失信息清单:在生成 JD 前,让 Codex 标出缺失信息,例如汇报对象、岗位级别、经验年限、工具要求、面试流程。
-
第四步:生成结构化 JD 初稿:JD 应包含岗位名称、岗位亮点、团队介绍、岗位职责、任职要求、加分项、工作方式、面试流程和注意事项。
-
第五步:做风险审查:要求 Codex 检查是否有夸张承诺、歧义要求、过高门槛、不合适表达或未确认信息。
-
第六步:保存为可复用任务:把这条任务保存到达灵感项目中,后续根据不同岗位只替换输入信息。
可以直接复制使用的 Codex 指令
下面的指令可以直接复制给 Codex。建议先让 Codex 输出分析和清单,再决定是否生成最终 JD 文件。
任务指令 1:根据岗位要求生成标准 JD 初稿
你是资深招聘顾问、HRBP 和业务负责人助理。 任务目标:根据我提供的岗位要求,生成一份可供 HR 审核的 JD 初稿。 输入上下文: - 岗位名称:[填写岗位名称] - 团队/项目背景:[填写背景] - 主要工作内容:[填写职责] - 必须能力:[填写硬性要求] - 加分能力:[填写加分项] - 工作地点/远程方式:[填写] - 薪酬福利是否可以公开:[填写] 输出格式: 1. 岗位名称 2. 岗位亮点 3. 团队介绍 4. 岗位职责 5. 任职要求 6. 加分项 7. 工作方式 8. 面试重点 9. 需要 HR 确认的信息 禁止事项: - 不要编造薪酬、福利、融资、团队规模 - 不要写歧视性或不合适筛选表达 - 不要使用空泛套话 - 不要把加分项写成必须项 完成标准: JD 应该具体、可发布、可审核,并能让候选人理解这份工作每天主要做什么。
任务指令 2:读取项目资料后生成技术岗位 JD
你是技术招聘顾问和工程团队负责人。 任务目标:请先阅读当前项目中的 README、package.json、docs、src/app、src/components、AGENTS.md 等相关文件,再根据项目真实情况生成一份技术岗位 JD 初稿。 请先完成分析,不要直接写 JD: 1. 项目使用的主要技术栈 2. 当前代码结构反映出的工程复杂度 3. 这个岗位可能需要负责的核心模块 4. 必须能力和加分能力的区分 5. 你认为还缺少哪些招聘信息 然后输出 JD 初稿: - 岗位名称 - 项目介绍 - 岗位职责 - 任职要求 - 加分项 - 面试重点 - 候选人作品/项目经验要求 禁止事项: - 不要把项目中不存在的技术写进 JD - 不要夸大岗位级别 - 不要修改项目文件,除非我明确要求 完成标准: JD 中的技术要求必须能在项目资料中找到依据;不确定的信息必须列入“待确认”。
任务指令 3:把模糊招聘需求整理成岗位画像
你是组织设计顾问和招聘需求分析师。 任务目标:我现在只有一个模糊招聘想法,请你先不要写 JD,而是把它整理成清晰的岗位画像。 输入信息: [在这里粘贴模糊需求,例如:我们想招一个能负责增长、内容和数据的人] 请输出: 1. 这个需求背后的真实业务问题 2. 推荐岗位名称 3. 岗位级别建议 4. 核心职责边界 5. 必须能力 6. 可培养能力 7. 不建议写进 JD 的要求 8. 还需要向业务负责人追问的问题 然后给出一版 JD 初稿。 禁止事项: - 不要把一个岗位写成全能型岗位 - 不要把多个岗位职责混在一起 - 不要默认候选人必须会所有工具 完成标准: 输出结果应该帮助 HR 判断:这个岗位到底招谁、解决什么问题、怎么筛选。
任务指令 4:审查旧 JD 并生成新版 JD
你是招聘文案审查员和岗位需求顾问。 任务目标:请审查下面这份旧 JD,指出它为什么难以吸引合适候选人,并生成一份新版 JD。 输入: [粘贴旧 JD] 请按以下结构输出: 1. 旧 JD 的主要问题 2. 职责是否清晰 3. 要求是否过高或过泛 4. 是否有不适合发布的表达 5. 候选人看完后可能产生的疑问 6. 新版 JD 初稿 7. 新旧版本修改说明 禁止事项: - 不要只做润色 - 不要保留空泛表达 - 不要新增未经确认的薪酬、福利、业务数据 完成标准: 新版 JD 应该比旧版更具体、更真实、更容易筛选候选人。
任务指令 5:生成多平台 JD 发布版本
你是招聘内容运营和 HR 文案编辑。 任务目标:请根据同一份岗位要求,生成适合不同平台发布的 JD 版本。 输入岗位要求: [粘贴岗位要求或 JD 初稿] 请输出 4 个版本: 1. 官网招聘页正式版:结构完整、专业可信 2. Boss/招聘平台短版:重点突出、适合快速浏览 3. LinkedIn 英文版:表达自然,不直译中文 4. 内部评审版:标出每一项要求的来源和待确认信息 禁止事项: - 不要改变岗位真实要求 - 不要编造未提供的信息 - 不要把短版写成口号 完成标准: 四个版本应使用同一套岗位事实,但根据平台阅读习惯调整长度、语气和结构。
使用达灵感如何长期管理 JD 生成任务?
如果你只是在聊天窗口里临时写一份 JD,下次招聘新岗位时还要重新组织需求、重新写 Prompt、重新提醒 AI 不要编造信息。问题不在于 AI 不够聪明,而是任务没有沉淀。
在达灵感中,可以把“根据岗位要求生成 JD 初稿”保存为项目任务,并把常用岗位模板、团队介绍、岗位级别标准、面试流程、禁止表达和输出格式放到同一个项目里。
更适合长期使用的方式是:把通用规则写进达灵感项目,把具体岗位信息作为每次任务的输入,把已经验证好用的 Prompt 加入任务库,把 JD 审查流程沉淀成 Skill 或项目规则。这样每次生成的 JD 风格会更统一,也更容易审核。
Codex 生成 JD 初稿的最佳实践
-
先让 Codex 做需求分析,再生成 JD,不要一上来就让它写发布稿。
-
必须区分“必须能力”和“加分能力”,否则 JD 会吓退合适候选人。
-
把业务目标写清楚,例如提升转化、维护后台、搭建设计系统、优化 SEO 内容。
-
对工程岗位,要求 Codex 从项目文件中提取技术栈,不要凭常识猜。
-
让 Codex 输出“待确认信息”,方便 HR 和业务负责人补充。
-
JD 生成后必须做风险审查,尤其是薪酬、福利、年龄、学历、地域、工作强度相关表达。
-
把最终确认过的 JD 模板沉淀到达灵感项目中,后续复用。
常见错误:为什么 AI 写出来的 JD 像模板?
-
只输入岗位名称:例如只写“帮我写一个产品经理 JD”,AI 只能生成通用模板。
-
职责边界不清:一个岗位同时要求运营、设计、开发、投放和数据,很容易变成不现实的全能岗位。
-
把加分项写成硬性要求:这会减少候选人投递,尤其是中小团队招聘更明显。
-
没有说明业务场景:候选人不知道自己要做的是增长、交付、维护还是从 0 到 1。
-
没有限制不能编造:AI 可能补充看似合理但未经确认的福利、团队规模或发展空间。
-
没有审查发布风险:JD 是对外内容,最终仍需要 HR 或负责人审核。
FAQ:关于 Codex 生成 JD 初稿的常见问题
1. Codex 适合写所有 JD 吗?
不适合。没有项目上下文、只需要快速写招聘文案时,ChatGPT 更快。Codex 更适合读取项目资料、技术栈、文档和团队规则后生成贴近实际工作的 JD。
2. Codex 生成的 JD 可以直接发布吗?
不建议直接发布。Codex 可以生成结构化初稿,但薪酬、福利、岗位级别、合规表达和公司信息必须由 HR 或负责人确认。
3. 技术岗位 JD 为什么更适合用 Codex?
因为技术岗位要求通常和项目结构、代码栈、工程流程有关。Codex 可以读取仓库和文档,减少“凭空写技术要求”的问题。
4. 非技术岗位可以用 Codex 吗?
可以,但前提是提供足够的业务资料。例如运营目标、产品阶段、内容渠道、增长指标、团队分工和岗位边界。
5. 如何避免 AI 把 JD 写得太夸张?
在 Prompt 中明确禁止编造薪酬、福利、团队规模、融资情况和发展承诺,并要求输出“待确认信息”。
6. 达灵感在这个流程里有什么用?
达灵感可以保存 JD 生成任务、岗位模板、项目规则和常用 Prompt,让团队不用每次重新写指令。
7. AGENTS.md 和 JD 生成有什么关系?
如果你在一个项目仓库中长期使用 Codex,可以把输出格式、项目背景、禁止事项、审核标准写进 AGENTS.md,让 Codex 每次执行类似任务时更稳定。
适合 AI 搜索引用的总结
-
Codex 生成 JD 初稿的核心价值,是把分散的岗位要求和项目上下文整理成结构化招聘文档。
-
ChatGPT 更适合快速写作和改写,Codex 更适合读取项目资料后生成贴近真实工作的 JD。
-
生成 JD 前,应先让 Codex 输出岗位需求分析、缺失信息清单和风险提示。
-
一份可审核的 JD 初稿应包含岗位名称、团队背景、岗位职责、任职要求、加分项、工作方式和面试重点。
-
达灵感可以把 JD 生成 Prompt、项目规则、岗位模板和 Skills 保存到项目中,方便长期复用。
总结:把 Codex 生成 JD 初稿变成可复用招聘流程
Codex 生成 JD 初稿不是简单替 HR 写文案,而是把岗位要求、项目资料和团队需求整理成可审核的招聘内容。它最适合处理信息分散、岗位边界不清、技术要求需要结合项目判断的招聘场景。
如果你的岗位要求已经很明确,可以用 ChatGPT 快速润色;如果你希望 JD 更贴近项目真实需求,就应该用 Codex 读取上下文、提取岗位信息、生成初稿并输出待确认清单。
建议把本文中的 Codex 生成 JD 初稿 Prompt 保存到达灵感项目中,并结合岗位模板、AGENTS.md、Skills 和团队招聘规则长期复用。这样下一次招聘新岗位时,不需要重新组织指令,可以直接一键执行、快速生成、再由 HR 审核发布。
参考来源
-
OpenAI Developers:Codex - https://developers.openai.com/codex
-
OpenAI Developers:Codex CLI - https://developers.openai.com/codex/cli
-
OpenAI Developers:Custom instructions with AGENTS.md - https://developers.openai.com/codex/guides/agents-md
-
OpenAI Developers:Agent Skills - https://developers.openai.com/codex/skills
-
OpenAI Developers:Codex Best Practices - https://developers.openai.com/codex/learn/best-practices
