第一章 · 上手

六步跑通:从一份 JD 到一个可复用的 Skill

这一章不解释原理。你只需要挑一个今天真的要交的活,跟着六步走一遍。走完之后,你手上会多出三样东西:一份能发出去的 JD 初稿、一个存下来的 Skill、一个能替你值周的自动化。

预计投入:首轮 40–60 分钟 前置条件:已开通智能体工作台 产出:1 份初稿 + 1 个 Skill + 1 个专家

开始之前,先备三样东西

  1. 一个真实岗位:正在招或下季度要招的,不要用虚构岗位练手,虚构岗位不会暴露口径问题。
  2. 一份口径材料:你们的职级说明、能力模型片段,或哪怕只是一份写得还行的历史 JD。
  3. 一个验收标准:这次输出要给谁看、他会挑什么毛病。写在纸上,一句话。

第 1 步 · 认清三种模式:问一问、做一做、想一想

WorkBuddy 提供三种工作模式。很多人第一次用觉得「不就是聊天框」,于是不管干什么都用同一种,结果要么拿到一堆不痛不痒的段落,要么文件被改得措手不及。它们的真正差别不在语气,而在会不会动你的文件

问一问(Ask)

只回答,不改动任何文件。适合先摸清情况:某项制度怎么规定、某个口径怎么算、某种情形一般怎么处理。

用法要点:要求标注依据;没有依据的部分让它明说「不确定」。这是最安全的模式,拿不准时就用它。

做一做(Craft)

直接执行,并会改动文件。适合已经想清楚要什么、可以放手交付的活:写 JD、生成面试提纲、整理面评记录。

用法要点:先说清交付物类型与读者,再给约束和样例。动手前确认工作目录里没有你不想被改的东西。

想一想(Plan)

先给计划,你确认后再执行。适合步骤多、影响面大的活:一个招聘季怎么排、一次组织调整怎么推、一轮绩效怎么走。

用法要点:在计划阶段就要求它标出哪几步必须人工确认——这正是本书人审闸的落点。

选错模式的代价很具体:用「问一问」去要 JD,你会得到一段「JD 应该包含哪些要素」的说明而不是一份稿子;反过来,对一个还没想清楚的大改动直接用「做一做」,它会真的动手改文件,而你还没决定要不要这么改。本书的建议很简单:涉及多步骤或影响面大的任务,一律先走「想一想」,把计划和人审闸位置定下来,再让它执行。

与本书人审闸的对应关系

「想一想」的计划确认环节,天然就是一道人审闸。后面章节里每条强制链路上的 ,在工作台里的落地方式通常就是:这一步用「想一想」,看完计划再放行。功能名称与交互细节请以你所用客户端的官方说明为准。

第一次使用的三个动作

  • 把公司名、业务简介、你所在团队职责写进一段固定的背景说明,之后每个任务都复用它。
  • 确认企业知识库 / 文件上传能力是否开通——能读到你们自己的材料,输出质量差别极大。
  • 先做一次脱敏演练:拿一份简历,手动删掉手机号、身份证号、家庭住址、具体毕业院校之外的隐私项,形成你自己的脱敏习惯。

第 2 步 · 跑通第一个任务

下面三个任务是本书推荐的 HR 起手式。它们的共同点是:交付物边界清楚、你自己就是验收人、当天就能用上。挑一个开始,不要三个一起。

起手式 A · JD 初稿(推荐第一个做)

JD 是最适合起手的任务:输入可控、格式固定、错误后果可挽回,而且它天然带一个合规检查点(歧视性表述),能让你第一次就体会到「红线要写进提示词,而不是靠事后检查」。

提示词骨架 · JD 初稿
【角色】你是一名资深招聘负责人,熟悉岗位胜任力建模与招聘广告合规要求。

【背景】
- 公司:{{公司名}},{{一句话业务描述}},团队规模 {{人数}}。
- 岗位:{{岗位名称}},汇报给 {{直接上级}},所属 {{部门}}。
- 招聘原因:{{新增编制 / 替补 / 业务扩张}}。
- 用人经理最看重的三点:{{要点1}}、{{要点2}}、{{要点3}}。

【任务】撰写一份 JD 初稿,供用人经理评审后对外发布。

【结构要求】按以下小节输出,每节独立成段:
1. 岗位概述(3 句以内,说明这个岗位存在的业务价值)
2. 核心职责(4–6 条,每条以动词开头,写清产出物而非日常动作)
3. 任职要求(区分「必备」与「加分」,必备不超过 5 条)
4. 团队与发展(写清汇报关系、协作面、成长路径)
5. 我们提供什么(不写虚词,写具体机制)

【硬性约束】
- 禁止出现性别、年龄、婚育、户籍、地域、健康状况、宗教信仰等
  与岗位胜任力无关的限定,也禁止用暗示性措辞实现同样效果。
- 不使用「抗压能力强」「能吃苦」「拥抱变化」等无法验证的形容词,
  改为可观察的行为描述。
- 学历与年限如非硬性门槛,一律写入「加分项」。
- 全文不出现具体薪资数字,除非我在背景里给出了带宽。

【输出附加】正文之后另附两块:
- 【口径疑问】列出你为了写这份 JD 而做出的假设,标明需要我确认的点。
- 【合规自查】逐条说明你如何满足上面的硬性约束。

拿到初稿后,请务必做一件事:自己动手改一版,并记下你改了什么。改动会分成两类——一类是它不知道的信息(团队现状、真实汇报线),另一类是它反复犯的毛病(爱写空话、职责写成动作)。第二类就是你下一步要写进 Skill 的东西。

起手式 B · 简历盘点

这个任务的价值不在「筛人」,而在把一堆非结构化材料变成一张可讨论的表。请特别注意:本书主张 AI 只做分档与摘要,淘汰决定由人做,且分档结果必须附带依据原文。

提示词骨架 · 简历盘点
【角色】你是招聘协调员,负责把候选人材料整理成用人经理可快速评审的形式。

【输入】我将提供 {{数量}} 份已脱敏简历(以候选人编号代替姓名,
已删除联系方式与身份证信息)。

【岗位胜任力要素】(这是唯一的评估依据,不要引入其他标准)
1. {{要素1,如:B 端产品从 0 到 1 经验}}
2. {{要素2,如:跨部门推动落地的实证}}
3. {{要素3,如:数据驱动的决策习惯}}

【任务】输出一张盘点表 + 一份提问清单。

【盘点表字段】
候选人编号 | 相关经历摘要(≤40 字) | 逐要素评估(每个要素给
「有实证 / 有提及但无实证 / 未体现」,并附简历原文片段) |
建议分档(A 优先沟通 / B 待补充信息 / C 与本岗要素匹配度低) |
待核实事项

【规则】
- 不得依据性别、年龄、婚育状况、毕业院校层级、户籍、照片信息做出
  任何评估或分档。
- 「未体现」不等于「不具备」,只说明材料中没有证据。
- 任何分档都必须能对应到简历原文,不允许基于推测。
- 分档只是排序建议,最终淘汰与推进由我决定。

【提问清单】针对 B 档候选人,各列出 2 个电话初筛时应确认的问题。

起手式 C · 面试复盘

面试复盘常年是招聘链路里最容易烂掉的一环:面试官口头说了一堆,落到系统里只剩「感觉还行」。让智能体把口述整理成结构化评价,是投入产出比很高的一步。

提示词骨架 · 面试复盘整理
【角色】你是面试委员会的记录员,负责把面试官的零散反馈整理为
结构化评价,供后续轮次与决策会使用。

【输入】以下是面试官的口述记录(可能口语化、有重复、有跳跃):
{{粘贴口述或语音转写文本}}

【岗位评估维度】{{维度1}}、{{维度2}}、{{维度3}}、{{维度4}}

【任务】输出四块内容:
1. 事实摘要:候选人在面试中陈述的具体经历与数据(只记录他说过的,
   不做推断,不补充你的行业常识)
2. 逐维度证据:每个维度下列出支持性证据与反面证据,
   并标注证据强度(自述 / 有细节 / 可验证)
3. 结论缺口:为了做出录用判断,还缺哪些信息,
   建议在下一轮由谁来验证
4. 下一轮问题:3 个针对性追问,每个说明想验证什么

【规则】
- 不给最终录用建议,不打总分。是否推进由面试委员会决定。
- 剥离与胜任力无关的描述(外貌、口音、家庭状况、婚育计划等),
  如原始记录中出现,请在末尾单独提示「以下表述与岗位无关,
  建议在正式评价中移除」。
- 面试官的主观形容词(如「悟性高」)需改写为其依据的具体行为,
  找不到依据则标注「无支撑」。

这一步最容易犯的错

把整份未脱敏简历、员工完整档案、薪酬明细表直接粘进去。请先删除联系方式、证件号、家庭信息、健康与体检记录;人才盘点用编号,薪酬分析用带宽和分位值。企业是否允许上传何类数据,以你们的信息安全规定为准。

第 3 步 · 把这次经验存成第一个 Skill

如果第 2 步你改了三版才满意,那这三版的差异就是最值钱的资产。Skill 的作用是:让下一次不必再改这三版。它不是提示词的另存为,而是把「你的判断」写成规则。

一个够用的 Skill 只需要六个字段。多了没人维护,少了就会退化成随口一问。

Skill 最小字段 · 以 jd-writer 为例
字段 作用 示例内容
何时用 触发条件,防止被误用 需要为某个具体岗位产出对外发布的 JD 初稿时
要什么输入 缺输入时应主动追问 岗位名称、汇报关系、招聘原因、用人经理关注的三点;缺任一项先问,不要猜
怎么做 固定步骤 先明确岗位业务价值 → 由产出物倒推职责 → 区分必备与加分 → 全文合规扫描 → 列出待确认假设
输出成什么 格式与长度 五个小节 + 口径疑问 + 合规自查;正文 600–900 字
怎么算合格 自检清单 职责均以产出物描述;必备项 ≤5 条;无不可验证形容词;无歧视性限定
红线 绝不能做的事 不编造薪资带宽;不虚构团队规模与融资情况;不承诺晋升时间表
展开:jd-writer 的 Skill 说明书写法(可直接改用)

名称:jd-writer · 岗位说明书撰写

一句话职责:把用人需求转化为合规、可验证、用人经理愿意直接改的 JD 初稿。

行为准则:

  1. 信息不足时提问,绝不用行业通稿填空。
  2. 每条职责都要指向一个可交付的产出物;写不出产出物的职责删掉。
  3. 任职要求默认放进「加分」,只有用人经理明确说是门槛的才进「必备」。
  4. 合规扫描在输出前执行一次,并在文末公开自查结果。
  5. 结尾必须列出本次做过的假设,供人工确认。

失败模式(要主动避免):堆砌形容词;把公司愿景写成职责;把「熟悉 Office」这类无区分度条件列入必备;用「年轻化团队」暗示年龄偏好。

维护约定:每积累 10 次使用,回看被人工改动最多的段落,把修正规则补进「怎么算合格」。

判断 Skill 是否成立的唯一标准

找一位没参与制作的同事,只给他 Skill 和一个新岗位,不做口头解释。如果他拿到的初稿质量和你差不多,这个 Skill 就成立了;如果他还要来问你「这个要怎么填」,说明缺的那句话应该写进 Skill,而不是靠你口头传授。

第 4 步 · 组装第一个专家

当你有了两三个相关 Skill,就该把它们收进一个专家。专家的本质是职责边界:它知道自己该干什么,也知道什么不该接。一个只有一个 Skill 的专家没有意义,一个装了十五个 Skill 的专家会开始乱用。

建议第一个专家做「岗位画像专家」,因为它是招聘链路的上游,做好了后面全都受益。

专家必须写清的四件事

  1. 职责范围:一句话说清它负责哪个环节。
  2. 可用资料:能读哪些知识库、哪些历史材料,读不到的要明说。
  3. 固定口径:职级怎么叫、部门怎么称、能力模型用哪一版。
  4. 移交条件:什么情况下它应该停下来交给人或交给别的专家。

不要装进这个专家的东西

  • 薪酬定价(口径不同,应归薪酬类专家)
  • 候选人淘汰决定(属于人的职责)
  • 劳动关系风险判断(需要法务口径)
  • 「顺便帮我写个周报」这类无关任务

第 5 步 · 接上第一个自动化

自动化的价值不是智能,而是不忘记。HR 工作里大量损耗来自「本该周一看的东西周四才看」。第一个自动化建议做「招聘进展周报」,因为它输入稳定、读者明确、错了也不会造成伤害。

自动化任务 · 每周一 09:00 · 招聘进展摘要
【触发】每周一 09:00

【输入】{{招聘系统导出的进展表 / 共享表格}},字段包含:
岗位、状态、当前轮次、停留天数、负责人

【产出】一份 300 字以内的摘要,发给招聘负责人,包含四块:
1. 本周需要推动的岗位(停留 > 7 天的,按停留天数降序)
2. 卡在同一轮次超过两周的岗位,并指出卡点在哪一方
3. 本周待安排的面试与需协调的资源
4. 需要我人工决策的事项清单(不要替我决策,只列出来)

【规则】
- 只使用表格中的字段,缺数据写「数据缺失」,不要推测补齐。
- 不在摘要中出现候选人姓名与联系方式,用编号或岗位指代。
- 不给出「建议放弃某岗位」这类结论,只呈现事实与卡点。

自动化的三个前提

  1. 先手动跑三次。手动都跑不稳的任务,自动化只会稳定地产出垃圾。
  2. 产出必须有明确读者。没人看的自动化会在两周内变成噪音,然后所有人开始忽略它。
  3. 不要自动发对外邮件。给候选人、员工的任何正式沟通,一律经人工确认后再发。

关于推送通道:不同版本、不同地区的客户端支持的助理通道并不一致(海外站点公开列出 Slack、Telegram 等,国内材料中也涉及微信、企业微信、飞书等)。本书不依赖任何特定通道——上面的自动化产出到一份文档或表格里同样成立。请以你客户端实际支持的助理通道为准。

第 6 步 · 按任务选模型

工作台通常提供多个模型。不要纠结排行榜,按任务性质选就够了。HR 场景里真正需要顶配推理能力的任务其实不多,而需要稳定格式和低成本的任务非常多。

选型速查 · 按 HR 任务性质
任务性质 典型 HR 场景 选型倾向 注意
格式化改写 面试记录整理、JD 润色、邮件模板套用 快、便宜的通用模型 关键是稳定格式,不是文采
长材料归纳 批量简历盘点、员工访谈汇总、培训反馈聚类 长上下文能力优先 宁可分批处理,也别让它超窗后自行删减
多步推理 组织设计方案权衡、薪酬结构测算逻辑、争议应对预案 推理能力更强的模型 必须要求它展示推理依据,便于人工检查
制度检索问答 假期规则、社保口径、内部政策查询 模型次要,检索质量优先 没有可靠资料源就不要做这类问答
数据计算 人力成本分摊、编制缺口测算、离职率计算 让它写公式与步骤,别让它心算 数字结果一律回表格复核

一个务实的成本策略:日常高频任务全部用快模型,只在三类场景切到强模型——第一次搭建某个 Skill 时(用来找出好的做法)、涉及方案权衡时、以及输出要进正式汇报时。

第一周验收清单

不要用「感觉有用」来判断。第一周结束时,逐条对下面这张表。做到五条以上,你就可以进入第二章开始建团;做到三条以下,说明你还在「随口问问」阶段,请回到第 2 步重做一次。

  1. 跑通了至少一个真实任务产出物已经给真实读者看过,并收到了反馈。
  2. 记录了改动清单你知道 AI 稳定会犯哪三个毛病,而不只是「有时候不太行」。
  3. 存下了一个 Skill六个字段都填了,尤其是「怎么算合格」和「红线」。
  4. 同事盲测通过没参与制作的同事只看 Skill 就能用出接近的质量。这是第一道闸:过不了不要往下推广。
  5. 组装了一个专家写清了职责范围、可用资料、固定口径、移交条件。
  6. 接上了一个自动化已手动跑过三次,读者明确,且不涉及对外发送。
  7. 明确了脱敏习惯你能说出哪些字段绝不进上下文,并且已经这样做了。
  8. 记下了三个指标的基线返工率、首稿时间、口径一致性——用你自己的数据,不用书上的示例。

常见卡点

输出很漂亮,但用人经理说「不是我们要的」

九成情况是缺口径,不是缺能力。请补三样:一份写得还行的历史同类材料作为样例、你们的职级与部门称谓表、以及用人经理的原话(哪怕是微信里那几句零散的要求)。

另一个常被忽略的原因:你没告诉它读者是谁。给用人经理看的 JD、给候选人看的招聘广告、给内部走审批的岗位说明书,是三份不同的东西。

它编内容:编制度条款、编薪资带宽、编团队规模

把「不许编」从愿望变成机制:在提示词里明确要求「无依据的部分必须写『未提供,需确认』」,并要求输出末尾单列「本次假设清单」。有了假设清单,你一眼就能看出哪里是它自己填的。

如果是制度类问答,根源在资料源。没有接入可靠的制度文件时,这类问题应该直接不做,而不是靠提示词补救。

每次结果都不一样,没法给同事用

波动通常来自三处:输出格式没写死(改成明确的小节与字数)、输入完整性没校验(缺项要主动追问而不是继续生成)、口径没固定(职级、部门、能力模型都要指定版本)。

把这三处补进 Skill 的「怎么算合格」,波动会大幅收窄。仍然不稳的,说明这个任务本身边界太模糊,应该拆小。

团队里没人用,只有我在用

推广失败几乎总是因为你给的是「工具」而不是「省事」。有效的做法是选一个所有人都讨厌的活(比如面试记录整理、周报汇总),把它做到不用学就能用,然后在例会上现场跑一次。

不要发培训文档,不要做分享会。让一个人先省下两小时,其他人自己会来问。

下一步

如果你已经存下了第一个 Skill,接下来的问题就变成「怎么把它编成建制」。第二章讲三层结构的划分方法和建团九原则;如果你更想先看成品长什么样,可以直接跳到第三章的九个专家团。