我用 WorkBuddy 把业务方一句话变成 5 份能过审的 JD

昨天业务方在群里甩了一句「招个 AI 产品经理，要懂大模型」。我回了个好的，心里想的是，亲，这句话要是能写成 JD，简历里的「负责」也能当证据。刷到一篇资讯，说 HR 写 JD 可以 1 分钟用 AI 出 5 个招聘版本。第一反应是快，第二反应是五份错法。

我用了 WorkBuddy 大约一个月，平时拿它拆文档、整理表格还算稳。上周试单 Agent 模式，也就是一个 AI 从头做到尾，跑了一周，发现它很容易把一份 JD 写得像简历模板，岗位齐全，全是套话。后来我把 WorkBuddy 改成一条 JD 生产线。JD 就是招聘职位描述，既要给候选人看，也要逼业务方把话说清楚。

打开 WorkBuddy，左侧进「文档空间」，点「新建项目」，项目名写「JD生产线」。把一张空白《业务需求收集表》拖进去。这里不要直接丢需求，先选专家团模式。专家团就是多个 AI 角色按步骤分工，比单 Agent 一次生成稳定。我固定四个角色，HRBP、业务面试官、合规审查、渠道文案。

在输入框贴业务原话，然后加一段硬指令。

你先不要写 JD。请按事实、可验证、业务方 1 分钟能答三个原则，列出 5 个问题。每个问题后面加一个示例答案。不要出现「优秀」「负责」「抗压」这类空词。

预期结果是一份《需求缺口清单》。我上周拿它问 AI 产品经理，它先问，你期望候选人做过哪类大模型产品，是调用 API 搭流程，还是自己训模型。这个问题有点毒，但毒得对。之前我觉得指令要温柔，后来发现温柔没用，业务方只会回「你看着办」。

这里踩过一个坑。我一开始写「帮我问得友好一点」，结果它问「您希望候选人具备哪些优秀品质」。这跟候选人写「沟通能力强」一样，没有证据。后来改成「只能问可验证事实」，才像面试评估。

生成 5 个版本不能靠灵感，得靠字段表。我这边环境是 WorkBuddy 的表格模块，不一定适用所有人。打开「表格」，点「新建表格」，名称「JD字段表」。列设置包括岗位、部门、汇报对象、工作地、硬技能、软素质场景、第一季度结果、禁用词、渠道版本。硬技能必须能用是或否判断，比如「能独立拆解 RAG 检索链路」。软素质必须配场景，比如「能在需求反复变更时，把业务方拉回可验收标准」。

关键参数我会固定。官网标准版控制在 600 字以内，岗位职责 4 到 6 条，任职要求分硬条件和加分项。内推短版 120 字左右，只说岗位、关键能力、第一结果、推荐奖。技术岗证据版写真实技术栈和问题，不写精通。销售岗结果版写客户类型、销售周期、单笔金额、CRM 工具。海外岗合规版不写年龄婚育，薪资范围用占位，语言要求具体到工作场景。

生成时，把《需求缺口清单》和字段表一起传给 WorkBuddy，让它按角色跑。HRBP 出初稿，面试官删空话，合规审查查禁词，渠道文案改标题和首段。我一般不让它一次改五版，先出一版，确认没问题，再批量派生。这个习惯是踩出来的。

权限我也设得比较死。WorkBuddy 项目里，业务方只给「可评论」，HR 给「可编辑」，招聘负责人给「可发布」。字段表如果同步到共享表格，硬技能、薪资带、禁用词这几列锁定，只有 HR 能改。我这边 ATS 也用了大约一个月，字段名尽量和 WorkBuddy 表格一致，不然导入岗位会分错。协作最怕一句话需求被传成一句话承诺。

日常运维不复杂。每周五我让 WorkBuddy 把本周新增岗位合并到岗位库，检查有没有重复 JD。每月复盘一次，看哪些版本打开高但简历差，哪些硬条件导致没人投。不是所有岗位都适合 AI 出稿，非技术岗尤其要人工看手感。AI 能验证需求到岗位的链路是否完整，细节还是得人磨。

后面看，HR 写 JD 大概更看谁能把模糊需求变成可验证招聘入口。WorkBuddy 这类工具真正省下来的，是后面跟业务方拉扯的一整天。