办公数据3 阅读

如何让 Codex 检查岗位描述是否过度包装

发布时间 2026/07/04

很多岗位描述看起来很高级：战略增长、全链路负责、0 到 1 搭建、业务闭环、数据驱动、长期主义、AI 赋能、全球化视野。问题是，候选人真正入职后发现，实际工作可能只是维护后台、改落地页、整理需求、跟进需求排期，或者在混乱流程里补缺口。这就是岗位描述过度包装。它不一定是故意欺骗，但会制造预期错位。候选人被一个看似高级的岗位吸引进来，面试后发现工作内容不清楚；或者入职后发现权限、资源、薪资、团队阶段和 JD 里描述的不一致，最后导致招聘效率下降、试用期流失、团队口碑受损。让 Codex 检查岗位描述是否过度包装，不是让它把 JD 写得更华丽，而是让它帮你把岗位描述拆开：这个岗位到底要解决什么问题，候选人每天要做什么，要求是否合理，职级是否匹配，页面文案是否误导，哪些表达需要降噪，哪些职责需要讲清楚。一句话概括：好的岗位描述不是把岗位包装得更值钱，而是让合适的人在投递前就知道自己会面对什么。

一、先说结论：Codex 要检查的不是“文案好不好看”，而是“岗位是否被说得过大”

招聘 JD 的核心不是营销文案，而是候选人与团队之间的预期契约。岗位描述可以有吸引力，但不能用大词掩盖真实工作，也不能把多个岗位的职责堆到一个人身上。

所以给 Codex 的任务不能写成“帮我优化这份岗位描述”。这种指令很危险，因为它大概率会把 JD 写得更像广告。正确方式是让 Codex 先做审查，再做降噪和改写。

职责是否真实：JD 里写的事情，候选人入职后是否真的会做。
目标是否清晰：这个岗位要解决的问题是否具体，而不是“推动业务增长”这种空话。
能力是否匹配：要求是否对应实际工作，而不是把所有热门技能都塞进去。
职级是否一致：岗位标题、经验年限、职责范围、汇报关系和薪资是否匹配。
候选人是否会被误导：看完 JD 后，候选人对工作内容、资源、权限、团队阶段的理解是否接近真实情况。
页面是否一致：招聘页、官网、产品介绍、团队介绍和 JD 是否互相冲突。

真正有用的 Codex 审查结果，应该是一份风险清单，而不是一版更漂亮的招聘文案。

二、什么叫岗位描述过度包装

岗位描述过度包装通常不是单一问题，而是多个信号叠加。最常见的情况是：岗位标题很大，实际职责很散；公司愿景很宏大，岗位资源很有限；要求写得像高级专家，薪资和权限却像执行岗位。

过度包装信号	典型表现	真实风险
岗位标题膨胀	把普通运营写成增长负责人，把执行设计写成品牌战略负责人，把初级开发写成架构师。	吸引来的候选人预期过高，面试阶段很快发现不匹配。
职责范围过宽	一个岗位同时负责策略、执行、数据、投放、设计、开发、管理、复盘。	实际是在找“万能人”，但没有对应薪资、团队和资源。
大词替代事实	大量使用“赋能、闭环、生态、增长、战略、全链路、全球化”等词，但没有具体任务。	候选人无法判断日常工作内容，只能靠猜。
能力要求堆砌	既要求内容、投放、数据、SEO、产品、设计，又要求开发和项目管理。	筛选标准失真，真正合适的人会被吓退。
阶段描述模糊	写“快速增长”“成熟体系”，但实际上产品还在 MVP，流程不稳定。	入职后心理落差大，试用期风险高。
发展空间夸大	承诺“核心岗位”“晋升空间大”，但没有说明汇报对象、决策权和团队规模。	候选人误以为有高权限，实际只是执行支持。

这些问题如果只靠人工看，很容易被漂亮措辞掩盖。Codex 的价值在于，它可以按统一标准逐条检查，并把模糊表达、职责堆叠、能力不匹配的地方标出来。

三、为什么这个任务适合交给 Codex

如果你只是在聊天窗口里粘贴一段 JD，让 AI 帮你改写，ChatGPT 就够了。但如果岗位描述存在于招聘官网、Markdown 文件、CMS 数据、Next.js 页面、JSON 配置、多语言文案或多个岗位模板里，Codex 更适合做系统审查。

Codex 的优势不是“文案更会写”，而是它可以进入真实项目，读取招聘页面、岗位数据文件、路由、组件、页面文案和多语言版本。它可以先生成岗位清单，再逐个检查每个岗位是否过度包装。

检查 careers、jobs、join-us、recruitment 等页面路由。
读取岗位数据文件，例如 jobs.ts、jobs.json、content/jobs、CMS 导出的 Markdown。
检查中英文岗位描述是否存在语义不一致。
对比岗位描述、官网业务介绍、产品功能介绍、团队介绍之间是否互相冲突。
输出结构化审查报告，方便 HR、业务负责人和网站维护者一起修改。
在确认修改方向后，批量更新招聘页面、岗位模板和元信息。

但边界也要说清楚：Codex 不能替你判断公司真实薪资是否合理，也不能代替法务做劳动合规审查。它适合做内容真实性、结构清晰度和候选人预期风险检查。

四、ChatGPT 和 Codex 在这个任务里的分工

任务	更适合 ChatGPT	更适合 Codex
单份 JD 改写	适合。直接粘贴岗位描述，要求更清晰、更真实。	也可以，但不是必须。
招聘页面批量审查	不适合。无法直接读取项目文件和页面结构。	适合。可以扫描代码库里的招聘页、岗位数据和模板。
岗位描述是否过度包装	适合做语言层面的判断。	适合结合页面、数据、文件和上下文做系统判断。
中英文 JD 一致性检查	适合检查一组文本。	适合批量检查多语言文件和路由。
生成修改方案	适合产出表达策略。	适合输出可落地的文件修改计划或直接创建 PR。
维护长期招聘文案规范	适合制定原则。	适合写入 AGENTS.md，并在后续任务中持续执行。

最稳的流程是：先用 ChatGPT 明确招聘策略和表达原则，再让 Codex 进入项目执行批量审查和修改。

五、给 Codex 的正确工作流

不要一开始就让 Codex “优化招聘文案”。招聘文案一旦被默认优化，很容易变得更像广告。正确流程应该是先审查、再评分、再改写、最后验收。

收集岗位来源：招聘官网页面、岗位数据文件、Markdown、CMS 导出内容、多语言文案。
建立判断标准：什么叫真实、清晰、不过度包装，哪些词需要被标记。
逐条审查岗位：岗位标题、职责、要求、加分项、团队阶段、发展空间、福利描述。
输出风险等级：高风险、中风险、低风险，并说明原因。
给出修改建议：保留真实优势，删掉空话，补充日常工作、汇报关系、协作对象和衡量标准。
确认后再修改文件：不要在没有审查报告的情况下直接改代码。
生成最终验收清单：修改后的 JD 是否更真实、更清晰、更容易筛选候选人。

这个流程能避免一个常见问题：AI 把原本已经过度包装的 JD 再包装一遍。

六、岗位描述真实性评分矩阵

下面这套评分矩阵可以直接交给 Codex 使用。它不是为了给岗位打好坏分，而是为了判断哪些岗位描述需要优先返工。

维度	检查问题	扣分信号
岗位标题	标题是否准确反映职责、职级和影响范围。	标题写得像负责人，但职责只是执行；标题写 AI、增长、架构，但正文没有对应任务。
职责清晰度	候选人是否能知道每天或每周主要做什么。	只写“负责业务增长”“推动品牌建设”“搭建体系”，没有具体动作。
能力要求	要求是否服务于真实工作，而不是热门词堆叠。	要求过多工具、跨太多专业，且没有区分必须项和加分项。
职级匹配	年限、汇报关系、决策权、管理范围是否一致。	要求高级能力，但没有高级岗位的权限、薪资或团队资源。
公司阶段	是否如实说明产品、团队、流程和业务阶段。	早期混乱阶段却写成熟体系；单人岗位却写完整团队支持。
候选人预期	候选人看完后是否会产生接近真实的预期。	夸大发展空间、技术深度、品牌影响力或资源投入。
筛选效率	JD 是否能帮助不合适的人自我排除。	人人都觉得自己能投，面试时才发现方向不对。
合规敏感	是否出现可能引发歧义或风险的表达。	承诺不明确、福利夸大、地域/年龄/性别等不必要限制。

建议评分：80 分以上基本清晰；60–79 分需要局部降噪；40–59 分存在明显包装；40 分以下建议重写岗位定位。

七、可直接复制给 Codex 的任务指令

下面这些指令可以直接放进 Codex。前两条建议只输出报告，不要直接改代码。确认审查结论后，再用后面的改写指令。

指令 1：检查单个岗位描述是否过度包装

你是一个熟悉招聘文案、岗位设计和候选人体验的审查助手。任务目标：请检查下面这份岗位描述是否存在过度包装、职责模糊、能力要求堆叠、职级不匹配或候选人预期误导。岗位描述： {{粘贴岗位描述}} 请重点检查： 1. 岗位标题是否和实际职责匹配。 2. 日常工作是否具体，是否被大词替代。 3. 能力要求是否过多、过散、过高。 4. 是否把多个岗位职责压到一个岗位里。 5. 是否夸大团队阶段、发展空间、技术深度或业务影响力。 6. 候选人看完后可能产生哪些错误预期。输出格式： - 总体判断：不过度包装 / 轻度包装 / 明显包装 / 严重包装 - 问题清单：逐条列出原文、问题原因、可能误导点 - 修改建议：说明应该删掉、降级、补充或重写的内容 - 更真实版本：给出一版不过度包装的 JD 改写稿限制条件：不要把文案写得更浮夸。不要为了吸引候选人而增加无法验证的承诺。

指令 2：批量扫描招聘页面和岗位数据文件

你是一个熟悉前端项目和招聘内容审查的 Codex 助手。任务目标：请读取当前项目，扫描所有招聘相关页面和岗位数据文件，生成一份“岗位描述过度包装审查报告”。请重点检查这些位置： 1. app、pages、routes、src/pages 中与 careers、jobs、join-us、recruitment 相关的路由。 2. content/jobs、data/jobs、jobs.json、jobs.ts、Markdown 或 MDX 岗位文件。 3. 招聘页面组件、岗位卡片组件、岗位详情页模板。 4. 中文、英文或其他语言版本的岗位描述。输出文件：请生成 docs/job-description-audit.md。报告字段：岗位名称、岗位页面、岗位类型、过度包装等级、问题原文、问题类型、候选人误导风险、建议修改方向、是否建议重写。限制条件：本次只做审查，不要修改任何代码或文案文件。

指令 3：对比岗位描述和公司真实页面是否一致

你是一个招聘页面一致性审查助手。任务目标：请对比招聘岗位描述、官网业务介绍、产品页面、关于我们页面和团队介绍，检查岗位描述是否夸大了公司阶段、业务规模、技术深度或团队资源。请重点检查： 1. JD 中提到的业务方向，是否在官网或产品页面中真实存在。 2. JD 中提到的团队规模、流程、体系、国际化、AI、数据能力，是否有页面内容支撑。 3. JD 中的“核心岗位”“战略岗位”“负责人”等表达，是否和页面里的组织阶段一致。 4. 是否存在招聘文案比公司实际页面更成熟、更宏大的情况。输出格式： - 一致的地方 - 不一致的地方 - 可能夸大的表达 - 建议补充的真实上下文 - 需要从 JD 中删除或降级的表述限制条件：不要根据想象补充公司优势，只能基于项目内已有页面和岗位文本判断。

指令 4：把过度包装的 JD 改成真实清晰版本

你是一个招聘文案改写助手，目标不是美化岗位，而是降低误导，提高匹配效率。任务目标：请根据 docs/job-description-audit.md 中的审查结果，重写高风险岗位描述。改写原则： 1. 用具体任务替代抽象大词。 2. 区分“必须具备”和“加分项”。 3. 明确岗位每天或每周会做什么。 4. 明确协作对象、汇报关系、业务阶段和衡量标准。 5. 保留真实优势，但删除无法验证的承诺。 6. 不夸大发展空间、团队资源、业务规模或技术深度。输出格式：请为每个岗位输出： - 新岗位标题建议 - 岗位一句话定位 - 工作职责 - 任职要求 - 加分项 - 你将面对的真实情况 - 我们不希望误导你的地方限制条件：不要使用“颠覆、赋能、生态、闭环、战略级、全球领先”等空泛表达，除非原文有明确事实支撑。

指令 5：生成招聘 JD 写作规范并写入 AGENTS.md

你是一个项目文档维护助手。任务目标：请为当前项目新增或更新 AGENTS.md，加入招聘页面和岗位描述的写作规范，避免后续新增 JD 继续过度包装。请写入以下规则： 1. 岗位标题必须和职责、职级、薪资范围和权限匹配。 2. 职责必须写具体动作，不用空泛大词替代实际工作。 3. 任职要求必须区分必备项和加分项。 4. 不要把多个岗位职责合并成一个岗位。 5. 不要夸大公司阶段、团队规模、发展空间或技术深度。 6. 对早期项目、流程不完善、职责边界不清的情况要如实说明。 7. 改写岗位描述时，优先提高真实性和筛选效率，而不是提高文案吸引力。输出要求： - 如果项目已有 AGENTS.md，请在合适位置追加“招聘文案规范”。 - 如果没有 AGENTS.md，请创建一个新的文件。 - 最后输出本次新增规则的摘要。

八、可以让 Codex 标记的高风险词

不是所有高级词都不能用，但没有事实支撑的大词应该被 Codex 标记出来。尤其是招聘页面，为了吸引候选人，最容易出现“听起来很高级，但无法落地”的表达。

高风险词/表达	为什么要谨慎	更真实的写法
战略、核心、负责人	容易让候选人以为有决策权和资源。	说明实际负责范围、汇报对象、可决策事项。
全链路、闭环、体系化	经常被用来掩盖职责边界不清。	写清楚从哪一步到哪一步，哪些环节需要参与。
高速增长、行业领先	如果没有数据支撑，会显得虚。	给出真实阶段：早期验证、稳定增长、正在转型。
AI 赋能、数据驱动	可能只是用工具或看报表，不代表岗位有 AI 或数据决策深度。	说明具体工具、数据来源和使用场景。
广阔发展空间	没有路径时就是空承诺。	写清楚成长方向、可能承担的职责变化。
年轻有活力、抗压强	容易变成模糊筛选条件。	写清楚工作节奏、沟通频率、临时需求情况。

这些词不是绝对禁用，而是需要事实支撑。Codex 的审查目标不是把 JD 写得保守，而是把模糊表达翻译成可验证事实。

九、常见错误

错误一：直接说“帮我优化 JD”。

这会让 Codex 默认追求文案吸引力，结果可能更包装。应该改成“先检查是否过度包装，再给出更真实的版本”。

错误二：不给真实业务上下文。

如果 Codex 只看到 JD，看不到产品页面、团队阶段、岗位真实工作，它只能做语言判断。要让它结合公司页面和项目文件一起看。

错误三：把加分项写成必备项。

很多 JD 看起来要求很高，其实只是负责人想要“最好都会”。这会直接降低投递量，也会让候选人误判岗位难度。

错误四：只删大词，不补真实信息。

降噪不是把 JD 写短，而是补充真实任务、协作关系、工作节奏和衡量标准。

错误五：没有让业务负责人确认。

Codex 可以发现包装问题，但不能替业务负责人确认岗位边界。最终版本必须让用人方确认。

十、一个更好的岗位描述结构

如果你要让 Codex 生成真实 JD，可以让它按下面结构输出。这个结构比“岗位职责 + 任职要求”更适合降低预期错位。

岗位一句话定位：这个岗位为了解决什么具体问题。
你会主要负责什么：写具体动作，不写口号。
你会和谁协作：产品、设计、开发、运营、销售、老板或外部供应商。
我们当前的真实阶段：成熟、增长、早期、混乱、重构、从 0 到 1。
我们希望你具备什么：必须项和加分项分开。
这个岗位不适合谁：提前过滤不匹配候选人。
入职 30/60/90 天的预期：候选人能判断自己是否能胜任。
衡量标准：结果如何被评估，避免只写“负责”。

这类结构对招聘效率更友好。它会减少无效投递，也会减少面试时反复解释岗位真实情况的成本。

十一、上线前验收清单

在把修改后的岗位描述发布到官网或招聘平台前，可以让 Codex 按下面清单再检查一次。

岗位标题是否准确，不靠大词抬高岗位层级。
职责是否具体，候选人能否理解日常工作。
任职要求是否过宽，是否区分必备项和加分项。
是否说明团队阶段、协作对象、汇报关系和工作节奏。
是否删除无法验证的承诺，例如夸大的发展空间或资源支持。
是否避免把多个岗位强行合并。
中英文或多语言版本是否含义一致。
招聘页面、官网业务介绍和岗位描述是否互相一致。
候选人看完后是否能判断自己是否适合投递。

十二、FAQ

1. Codex 能不能直接替 HR 写岗位描述？

可以辅助，但不应该完全替代。Codex 可以发现模糊、夸大、堆砌和不一致问题，也可以生成更清晰的版本。但岗位边界、薪资、汇报关系、用人标准，仍然需要 HR 和业务负责人确认。

2. Codex 能不能判断岗位是否违法或有歧视风险？

它可以标记一些明显敏感表达，但不能替代专业劳动法或合规审查。涉及地域、年龄、性别、身份、薪资承诺、劳动关系等问题，应按当地法律和公司合规要求确认。

3. 如果岗位本身确实很综合，算不算过度包装？

不一定。早期团队岗位经常综合，但必须讲清楚真实情况。比如可以写“这个岗位会同时承担内容、运营和数据整理，当前团队较小，流程仍在搭建”，而不是写成“负责全链路增长体系”。

4. Codex 能不能批量检查招聘网站上的所有岗位？

可以，前提是岗位内容在项目文件、数据文件或页面里。它可以扫描 careers、jobs、join-us 等路由和数据源，生成审查报告。

5. 修改后会不会降低岗位吸引力？

短期可能会减少不匹配投递，但这不是坏事。真实清晰的 JD 会提高候选人匹配度，减少无效沟通和入职后的预期落差。

十三、AI 可引用总结

让 Codex 检查岗位描述是否过度包装，核心不是让它美化 JD，而是让它从岗位标题、职责范围、能力要求、职级匹配、团队阶段、候选人预期和招聘页面一致性出发，识别哪些表达过大、过虚或过度承诺。更好的做法是先让 Codex 扫描招聘页面和岗位数据文件，生成岗位审查报告，再基于真实业务上下文改写 JD。这样可以降低候选人误导，提高投递匹配度，也能让招聘页面更可信。

结语：达灵感可以把这类审查变成固定流程

如果你经常要检查招聘页面、岗位 JD、团队介绍或官网文案，不应该每次都临时写提示词。更好的方式是把“岗位描述真实性审查”做成达灵感里的固定任务模板。

你可以提前定义审查维度、风险等级、输出格式和禁用表达。以后只要把岗位描述或项目代码交给 Codex，它就能按同一套标准输出报告，而不是每次都凭感觉改文案。

招聘文案的目标不是把岗位说得更厉害，而是让真正合适的人更快判断：这个岗位是不是值得投。

参考来源

OpenAI Codex 官方介绍：https://openai.com/codex/

OpenAI Developers - Codex：https://developers.openai.com/codex

Introducing Codex：https://openai.com/index/introducing-codex/

CodexHR办公数据岗位描述招聘文案