# SOHO 猎头 AI 实战蓝皮书

从一份 JD 开始，把 AI 用进猎头工作

肖老师 · 读者版 v2.3 · 2026-10-01

本版附虚构教学练习包，不含客户成功案例。先完成一项任务，再把方法留下来。

<a id="intro"></a>

### 从一份 JD 开始，把 AI 用进你的猎头工作

客户发来一份 JD。你读完后，真正要做的还有很多：把“最好”与“必须”分开，问清尚未确认的条件，判断去哪里找人，再把判断交给下一步工作。

这本书从这里开始。你会用 AI 读取三份材料，做出一份带来源的需求基线，纠正其中的错误，然后把做法整理成一个 Skill。换一个岗位时，你带走的是方法，而不是上次聊天的答案。

#### 读完后，你应该能拿出什么

| 阶段 | 你要完成的动作 | 留在手里的东西 |
|---|---|---|
| 第一次上手 | 给材料、下任务、打开结果、纠错 | 一份可核对的岗位需求基线 |
| 开始复用 | 使用随书 Skill，换岗位再跑 | 一套技能文件和两份不同岗位产物 |
| 接入业务 | 研究公司、核对候选人证据、准备沟通 | 有依据的研究表和沟通草稿 |
| 持续使用 | 记录来源、版本、人工确认和失败 | 可以接着做的工作流程 |

本书面向懂猎头业务、刚接触 Agent 的读者。不要求先学编程。主线使用 WorkBuddy 国内桌面版；讲清楚的方法也可迁移到其他支持读写文件的助手，但按钮、技能发现方式和账号能力需要分别确认。

#### 先打开练习包

下载完整交付包后先解压，保持文件夹结构，再打开本书 HTML。旁边的[练习包说明](练习包/README.html)是实践入口；[任务卡](练习包/任务卡.md)集中放可复制指令。只拿到一份 HTML 时，正文仍能读，配套链接需要补齐完整包。

所有岗位、公司、候选人和沟通记录均为教学虚构。它们用于展示如何判断与检查，不证明真实客户效果。模型原始输出、编辑参考答案和本版核验范围各有标识，见[运行记录](练习包/运行记录/README.md)。

第一次读，顺着“上手—理解—Skill”完成主线。已经会用 Agent 的读者，可以从 Skill 章节开始；管理者先看团队验收，再回头看操作细节。不要用读完多少页评价学习进展：能否换一份材料独立完成，才是这本书的检验方式。

## 一 · 上手：先交出一份可检查的成果

<a id="why1"></a>

### 你要得到的，是可以接着用的工作成果

猎头工作里有两种重复。一种是每次都要做的业务判断，例如这段经历是否证明候选人做过新伙伴签约；另一种是反复整理材料、复制字段、重新交代格式。AI 可以承担其中一部分准备工作，你仍然要对关键判断负责。

这本书希望帮你减少后一种重复，让前一种判断更容易核对。它不预先给出“每天省两小时”的数字。先选一个你熟悉的任务，记录原来如何做、用了多少准备时间、改了几次，再比较 AI 版本的总耗时，包括检查与返工。

#### 五类值得先试的成果

| 工作现场 | 可以交给 AI 的任务 | 你保留的决定 |
|---|---|---|
| JD 与补充消息不一致 | 整理差异、引用依据、列澄清问题 | 谁能确认，哪些条件可放宽 |
| 要了解目标公司 | 整理公开业务资料和待验证信息 | 是否值得投入寻访时间 |
| 三份人选资料难比较 | 对照同一标准提取证据 | 是否推进、还要核查什么 |
| 想做首次沟通 | 根据已知事实起草问题与消息 | 是否合适、是否发送 |
| 项目多、跟进容易断 | 找出到期事项和异常记录 | 当下优先做什么 |

先别把这五项一起交出去。第一次任务越小，越容易判断助手有没有读懂材料。随书主线只处理岗位需求，不替你搜索人选、联系客户或更新业务系统。

#### 给自己设一个起点

在工作记录中写下三件事：现在最常返工的环节、一次返工的具体原因、怎样才算做完。例如：“客户补充了语言要求，我需要重新核对画像；完成标准是每个硬条件都有原文，并明确谁确认了变更。”

你积累的资产会逐渐变成三类：可核查的输入、可重复的做法、经过你确认的产物。工具可以更换，这些资产仍应能够导出和解释；文件放在本地也不代表推理过程离线，是否调用云端模型另看产品设置。

<a id="start1"></a>

### 装好工具，先找到任务和产物

主线按 WorkBuddy 国内桌面版说明编写。先去[官方网站](https://www.workbuddy.cn/)找到下载入口，避免把同名软件、CodeBuddy IDE 或命令行当成本书的必装项目。安装条件和登录方式以[Mac 安装文档](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Installation-Mac-Guide)与[Windows 安装文档](https://www.codebuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Installation-Win-Guide)为准。

#### 准备与安装

Mac 用户在“关于本机”查看芯片类型，再选择对应安装包；打开下载文件，把应用移入应用程序后启动。Windows 用户按官网提供的兼容安装包完成向导。遇到系统拦截，先核对来源和官方说明，不跟随陌生教程关闭安全保护。

打开客户端后按页面完成登录。能进入任务页才算完成登录；浏览器显示成功而客户端仍没进入时，先回到客户端观察，不重复创建账号。收费、额度和模型可用性会变化，本书不预设免费账户能完成所有扩展功能。

#### 先认三个区域

新建任务是开始一件工作的入口；输入框用于说明任务、选材料与工作空间；产物区域用于打开生成的文件。你要能回答：当前任务在哪个目录工作，给了哪些输入，输出文件保存在哪里。第一次不必把整个设置页看完。

官方当前任务文档采用默认 Agent、计划 Plan、仅问答 Ask。Plan 适合先看方案，Ask 用于解释问题；需要生成文件时回到能执行的默认模式。输入框左侧“+”中的模式入口和实际页面可能随版本调整。旧教程中的 Craft 名称不要机械套用。[任务栏说明](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Task-Bar)

工作模式与权限不是同一件事。选了 Agent 仍要遵守访问范围；为了做一个练习，无需开启全部磁盘或全部外部账号权限。本版核对了本机 5.6.2 的界面标识，详细执行范围以运行记录为准。

本章完成标志：进入任务页，找到工作空间选择和产物入口。若尚不能登录，先阅读下一章并整理本地练习目录，等登录正常后再执行，不把失败写成已跑通。

<a id="start2"></a>

### 准备一个干净的练习工作区

把完整交付包解压到容易找到的位置，例如“文稿/猎头AI练习”。目录名可以自己改，后面提示词中的位置也要对应修改，不复制作者电脑的绝对路径。

工作空间是助手本次工作的文件范围与位置，不是永久记住全部业务的保证。新建任务时选择这个解压目录，然后让助手先列出你指定的三个文件名。没看到文件就先解决位置问题，不要继续问它“为什么不懂业务”。

#### 练习目录长这样

```text
猎头AI练习/
  SOHO猎头AI实战蓝皮书.html
  练习包/
    01-岗位需求.md
    02-补充说明.md
    03-客户确认.md
    进阶输入/
    候选人/
  技能包/
    recruiter-requirement-align/
      SKILL.md
  我的产物/                 ← 执行练习时新建
```

首次练习只用随书虚构材料。原始输入留着，产物另存，便于检查助手究竟改了什么。若它说找不到文件，把文件管理器里看到的实际位置告诉它，再让它报告读到的文件名；有些界面也支持选择附件，但附件与工作目录不一定是同一位置。

#### 以后换成业务材料时怎么脱敏

先问：这一字段对当前任务有必要吗？需求对齐通常不需要候选人手机号、私人邮箱、身份证号或完整家庭住址；直接从练习副本删除。客户与人选使用稳定代号，同一个人在同一份练习中始终使用同一个编号，避免失去人岗关联。

仅把名字改成“某某”未必足够。罕见经历、精确任职时间、公司加职位组合也可能识别人。准备公开教学素材时，优先另造合成材料；需要保留真实判断逻辑时，概括不必要的细节。代号与实名的对应表单独保管，不放进技能包或公开交付包。

检查还要覆盖文件名、批注、修订记录、截图侧栏、浏览器地址、分享链接和导出元数据。处理过的文件再打开看一遍。不要把“本地文件”当成“不传给服务商”的承诺；是否允许输入业务资料，应由你按所在组织规则与实际产品处理方式确认。

本章完成标志：练习文件可读，目录中没有顺带放入的真实简历，输入与产物位置分开。

<a id="start3"></a>

### 第一次交任务：把三份需求整理成一份基线

打开新任务，选中练习工作区。准备[岗位需求](练习包/01-岗位需求.md)、[补充说明](练习包/02-补充说明.md)和[客户确认](练习包/03-客户确认.md)。它们模拟同一岗位从初始描述到澄清的过程。

先自己读一遍：最早写“最好会中文”“有机会带团队”，后续确认了英语必需、中文加分、当前不要求带人。你已经知道关键差别，才有能力检查 AI。

#### 把下面这段发给助手

```text
请只读取练习包中的 01-岗位需求.md、02-补充说明.md、03-客户确认.md。
目标：把 R001 整理成一份可供我核对的岗位需求基线。
分开列：当前明确要求、加分项、未知项、前后变更、优先澄清问题。
每个已知条件写来源文件、段落或编号、短原文。
不补预算、团队人数或面试流程；推断单列。
这些是虚构教学材料，不联系任何人，不操作外部平台。
生成 我的产物/R001-首次.md，完成后告诉我读了哪些文件、保存在哪里。
```

如果当前模式只回答问题，让它说明是否有文件读写能力，再回到默认执行模式重试。权限提示出现时检查具体动作和路径，是否仅为读取练习材料、创建指定产物。

#### 看执行过程时，抓住三件事

第一，读了哪些文件：只读初始 JD 会遗漏澄清。第二，怎样处理变化：不能把所有句子简单拼起来。第三，文件是否生成：聊天里说“已完成”与目录里真的有文件要分别检查。

打开结果，你至少应看到：常驻新加坡；第一阶段新加坡与马来西亚；企业软件渠道经历以及个人签约或激活责任；英语商务沟通必需；中文加分；当前不要求带人；预算、奖金、完整面试流程未知。核对[教学参考基线](练习包/参考输出/需求基线.md)时只比较事实，不要求措辞完全一样。

如果结果少了来源，追加“保留原内容，给每项硬条件补原文依据；找不到就改为未知”。若输出位置错了，让它确认实际文件，再另存到指定位置，不让它顺手整理整个电脑。完成后记录这次的工具、日期、修订次数和最终版本。

<a id="start4"></a>

### 打开结果以后，怎样检查和纠错

一份看起来完整的报告，仍可能在最关键的一句话上出错。第一次练习，按五个问题检查：事实有依据吗，未知被保留了吗，推断有没有标出，格式能接着用吗，文件在哪里？

#### 用一个故意写错的草稿练手

[错误草稿](练习包/进阶输入/错误草稿.md)把 R001 写成覆盖整个东南亚、中文必需、带五人团队、年薪一百万。这些都是练习故意设置的错误，不是实际客户要求。

```text
读取练习包/进阶输入/错误草稿.md，以及 01、02、03 三份需求材料。
逐条输出：草稿原句、错在哪里、依据文件及短原文、应改为什么。
不要以行业经验补缺项。然后保存一份修正版需求基线。
错误说明存为 我的产物/修复记录.md，修正版另存，不覆盖原始材料。
```

你要找的修复不是“写得更专业”，而是把错误事实改正：当前区域按确认记录收窄，英语与中文的等级纠正，当前带人要求取消，薪酬恢复未知。“来自知名企业”也不能替代个人签约责任证据。

#### 让反馈变成可执行动作

“再准确一点”很难指导修复。更好的反馈是：“语言要求这一行写反了。请对照客户确认第 3 条修正，并检查候选人表是否也沿用了错误条件。”它同时指出位置、依据与受影响范围。

有错误就先修这一项，再检查下游。不要在需求还没对齐时继续生成搜索策略、排名和私信，否则同一个错误会被包装成多个漂亮产物。

本章完成标志：原始材料、错误草稿、逐项修复记录和新基线都能打开；你能指出一处修复来自哪条材料。模型可能每次措辞不同，但判断标准不应随措辞漂移。

## 二 · 理解：你正在怎样使用 AI

<a id="ai1"></a>

### Agent 是怎样把任务一步步做完的

先看一个需求整理任务：你给出目标和材料，助手读文件、组织信息、生成产物，你检查后提出修正，它再读取依据并修改。这条过程能帮助你理解 Agent。

本书把能够围绕任务选择并使用工具、根据结果继续推进的助手称为 Agent。模型负责理解与生成，工具提供读文件、查资料或写产物的动作，当前材料与规则限制它能够合理得出什么结论。Agent 不等于永远自主行动，也不等于拥有全部权限。

#### 一轮工作可以这样看

```text
你的目标和边界
      ↓
理解任务 → 选择下一步 → 使用工具 → 观察返回结果
                 ↑                    ↓
                 └── 发现缺口，修正 ───┘
                                      ↓
                               交付给人检查
```

这是教学示意，不是某个产品内部算法的完整图。重要的是观察实际动作：是否读到了文件，工具有没有报错，是否在信息不足时明确停下。只有一段“我将进行分析”的计划，不证明已经执行；工具调用成功也不证明输出正确。

在猎头场景里，好的停止点很具体。例如，输入关于常驻地互相冲突，助手可以整理两方说法和确认问题，但不应擅自选一个地点继续排除候选人。能说明为什么不能继续，是有效交付的一部分。

你可以在下一项任务加一句：“执行前复述输入、目标、输出位置；执行后列实际完成与未完成项。”它会让过程更容易核对，但不替代真实检查。
#### 先把“问一句”与“交一件事”分开

你问“需求访谈通常问什么”，助手可以直接生成一份建议。这是回答问题。你交代“读这三份文件，找出前后变化，按模板生成需求基线，缺少来源就补查”，就需要它执行一串动作，并根据中间结果决定下一步。

本书所说的 Agent（智能体），是模型参与选择步骤、借助工具执行并观察结果的任务系统。它不是另一个神秘模型，也不是给聊天机器人起了一个“资深猎头”的名字。你看到的任务界面是入口，背后还需要模型、工具、当前材料和执行规则共同工作。

| 你看到的动作 | 在需求对齐任务里意味着什么 |
|---|---|
| 读取文件 | 通过工具取得指定 JD 与确认记录，不是凭聊天印象猜内容 |
| 比较与判断 | 模型依据原文和规则区分硬条件、偏好、未知与冲突 |
| 继续补查 | 发现缺少来源，回到指定材料查找；没有就保留未知 |
| 写出文件 | 工具把整理结果保存为你能打开的产物 |
| 停下交接 | 无权解决的冲突交给你确认，而不是自行定案 |

这些是本书的教学拆解。不同产品会把部分动作固定为流程，也会让模型决定部分步骤；有聊天窗口不代表每次都采用 Agent 执行方式。[架构参考：Anthropic 对工作流与 Agent 的区分](https://www.anthropic.com/engineering/building-effective-agents)

#### 对猎头有什么用，边界又在哪里

你可以把反复读取、整理、按规则生成初稿的工作交出去，留下可复查的过程。你仍需判断岗位要求是否合理、证据是否支持结论，以及什么可以对客户或候选人承诺。工具权限只决定它能做哪些动作，不保证这些动作做得对。

一个 Agent 可以在不同任务里使用不同 Skill；一个 Skill 也可以交给支持它的不同 Agent 使用。换了工具或模型后仍要复测，不能把“同一份方法文件”理解成“每次结果完全一样”。

#### 培训里的第一道判断题：它真的做了吗？

看三个回复：A「我建议你比较三份材料」；B「我已生成需求基线」，但没有可打开的文件；C 列出实际读取的文件、保存的产物与未解决的冲突。哪一个足以开始验收？

<details><summary>展开参考答案</summary><p>C 提供了可验收的线索，仍需打开产物并回查来源。A 是建议；B 是完成声明，缺少证据。判断 Agent 的执行，要看实际动作和结果，不能只看它怎样自我介绍。</p></details>

再问自己：材料没有预算时，它应该继续做什么？应该整理已知项，标注预算未知并提出确认问题；不能为了完成表格编一个区间。停止猜测，与停止全部工作，是两回事。

**本讲带走：** 用自己的话解释「Agent 会围绕目标选择动作、观察结果，再继续或交接」。接着读[六个概念如何配合](#ai2)。


<a id="ai2"></a>

### 模型、提示词、Skill 和工具，各管哪一段

这些词经常一起出现。把它们放回刚才的需求对齐任务，就比较容易区分。

| 名称 | 在本次任务中的作用 | 不能代替什么 |
|---|---|---|
| 模型 | 理解原文、比较变化、组织文字 | 不能凭空知道客户预算 |
| 提示词 Prompt | 交代这次读哪些文件、产物放哪里 | 一次写得好，不代表下次自动复用 |
| Skill | 保存处理需求的步骤、字段规则与模板 | 不增加外部账号权限 |
| 工具 Tool | 实际读取、搜索、写文件 | 文件写成功，不代表结论正确 |
| Agent | 围绕目标组织这些能力，观察结果再推进 | 不承担你对外的业务承诺 |
| 工作流 Workflow | 规定若干任务如何接续以及在哪里验收 | 有流程图，不等于已经自动运行 |

你可以把 Skill 看作交给助手的一份工作方法包。公开格式以 `SKILL.md` 为入口，说明何时使用、按什么步骤做；需要时带参考资料、模板或脚本。脚本是可选项，最初不写代码也能做一个有用的技能。[Agent Skills 标准](https://agentskills.io/specification)

提示词与 Skill 不是互斥的。Skill 保存比较稳定的方法，这次的提示词仍需指定岗位、输入范围与产物位置。把每个客户的隐私材料都写进 Skill，会让它难更新，也增加不必要的数据暴露。

模型换了，方法不一定要重写，但需要重新验收。工具换了，读写路径与技能加载方式可能不同。遇到差异时先判断属于哪一层，而不是把所有失败都归结为“提示词还不够长”。
#### 用一项任务把六个概念连起来

你在任务窗口交代：“处理 R001，读取这三份材料，结果放进我的产物目录。”这是**本次提示词**。Agent 为完成目标，使用**模型**理解材料，按**Skill**中的方法判断，调用读写**工具**拿到材料、保存文件。你验收之后把基线交给公司研究任务，这个前后衔接才构成更大的**工作流**。

```text
本次提示词：这次处理什么、材料在哪里、交到哪里
                       ↓
Agent：围绕目标选择下一步，执行后看结果
  ├─ 模型：理解、比较、生成
  ├─ Skill：本类任务的方法与规则
  └─ 工具：读取文件、检索资料、保存产物
                       ↓
产物 + 人工验收 → 下一项任务（工作流）
```

图中的层次是便于理解的教学模型，不代表每个软件都有同名按钮。

#### Skill 与长提示词，到底差在哪里

“请按以下五步处理本次 JD”可以是一段好提示词。把稳定的五步、异常处理和模板保存进一个有入口说明的方法包，并让支持它的宿主在合适任务中加载，才便于跨任务维护和复用。Skill 的内容仍可能是自然语言指令；它并没有让提示词失效。

Skill（技能）通常以包含 `SKILL.md` 的目录呈现，可以附参考文件、模板或脚本。支持这一机制的客户端可先识别名称与用途，再在需要时加载详细方法和资源；具体发现、选择与执行方式由客户端实现。把一个文件命名为 `SKILL.md`，不代表软件已经安装、读取或执行了它。[Agent Skills 概览](https://agentskills.io/home)

| 容易混淆的东西 | 猎头场景中的区别 |
|---|---|
| 角色设定 | “你是资深猎头”交代身份，但没有说明怎样处理冲突 |
| 资料库 | JD、行业报告告诉它有哪些事实；Skill 告诉它怎样处理这些事实 |
| 模板 | 规定结果有哪些栏目；Skill 还规定每一栏怎么得出、何时不能填 |
| 自动化脚本 | 执行明确的程序动作；Skill 可带脚本，也可完全不写代码 |
| 平台权限 | 决定能否读某个系统或发送消息；Skill 本身不创建登录与授权 |

举例：客户预算属于这次输入，不能写成通用技能的默认值。“预算没有依据就标未知”才适合留下来复用。

#### 先用猎头团队打个比方，再回到准确含义

你可以暂时把 Agent 理解为接任务的助手，把 Skill 理解为团队交给它的作业方法，把工具理解为它能使用的文件柜和工作软件。但助手并非真人，Skill 也不会自己执行；模型的判断可能出错，工具能否使用取决于实际接入与权限。

真正需要分清的是：**谁推进任务、按什么方法、借助什么动作、处理哪些材料。** 一个 Agent 可以用多个 Skill；Skill 本身不是另一个 Agent。即使没有 Skill，Agent 也可能按本次指令执行；引入 Skill 是为了维护和复用稳定的方法。

#### 动手分一分：这些内容分别放在哪里？

| 内容 | 先写下你的判断 |
|---|---|
| 本次岗位常驻上海 | 本次输入，还是通用规则？ |
| 语言要求按原文区分必需与加分 | 岗位事实，还是 Skill 方法？ |
| 将结果保存到本次指定目录 | 本次任务参数，还是所有任务的固定路径？ |
| 调用文件读取功能 | 工具动作，还是 Skill 本身？ |
| 需求确认后，再启动公司研究 | 一条字段规则，还是任务间的工作流？ |

<details><summary>展开参考答案与原因</summary><p>依次是：本次输入、Skill 方法、本次任务参数、工具动作、工作流。上海会随岗位变化；分类方法可以复用；保存位置由本次任务指定；读取文件需要工具；跨任务衔接属于工作流。把岗位事实写进通用规则，是新手最容易犯的复用错误。</p></details>

**本讲带走：** 不看表格，画出「任务 → Agent → 模型 / Skill / 工具 → 产物 → 人工验收」的关系，并标出本次材料进入哪里。接着[拆开真实技能文件](#skill2)。


<a id="ai3"></a>

### 上下文和记忆：怎样让助手接得上工作

你在一段对话里解释过一次客户背景，不意味着另一个新任务也知道它。上下文是本次执行可用的信息；持久记忆是产品可能保存并再次提供的信息；工作区是文件所在的范围。这三者相关，但不能互相替代。

最容易复现的方法，是把必要的业务状态写成一份很短的交接，而不是依赖聊天历史。交接只需要写：当前岗位和基线版本、已确认条件、未确认项、最新动作、下一步、源文件位置。

```text
继续 R001 的公司研究。
请先读需求基线 R001-v1，再读今天指定的研究材料。
当前允许做资料研究；预算和奖金未确认，不得对外承诺。
本次只交公司研究表，不发消息、不更新业务系统。
若基线与新材料冲突，先列差异供我判断。
```

新任务开始时，让助手复述关键状态，你就能知道交接是否真正进入了当前上下文。不要让它为了“恢复记忆”遍历全部客户目录。

长期规则与本次事实也要分开。长期规则可以是“未知不补值，事实附来源”；本次事实是“R001 当前不带人”。后者变了，应改基线与变更记录，不要把旧条件写成所有岗位通用规则。

有些开发工具使用特定名称的项目说明文件。具体文件名、搜索层级和优先级依宿主而定；不能把任意 `AGENTS.md` 都说成所有软件的系统提示词。新手先用显式任务交接就足够。用第二岗位重新开一个任务，是检查旧背景是否污染新判断的好办法。

## 三 · Skill：留下方法，再换任务复用

<a id="skill1"></a>

### 先用一个现成 Skill，看看方法怎样留下来

随书提供[岗位需求对齐技能包](技能包/recruiter-requirement-align.zip)，以及可直接打开的[SKILL.md](技能包/recruiter-requirement-align/SKILL.md)。它只做需求整理，不搜索候选人、不估预算、不发送消息。

#### 两条使用路径，分别检查

第一条是客户端导入。按当前官方路径进入“专家·技能·连接器 → 技能 → 添加技能 → 上传技能”，选择随书 ZIP，再到已安装列表确认；在新任务中选中对应技能，提交三份输入和输出位置。菜单有变化时看[官方技能说明](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Skills-Market)。本版没有将官方入口核对等同于该 ZIP 已在所有客户端导入成功，具体实测状态见运行记录。

第二条是不安装，明确让助手读取方法文件。这条适合先理解技能，也便于检查文件内容：

```text
请读取 技能包/recruiter-requirement-align/SKILL.md，
以及其中引用的字段规则和输出模板。
按这个方法处理 练习包/01-岗位需求.md、02-补充说明.md、03-客户确认.md。
保存到 我的产物/R001-Skill.md。
报告实际读取的技能资源；不将显式读取描述为已安装或自动触发。
```

两条路径可能得到类似产物，但验证的问题不同。看到了技能文件，只证明文件存在；列表中出现技能，证明导入被宿主识别；执行记录显示用了规则与模板，才支持本任务实际使用；内容符合标准，才算结果合格。

#### 第一次使用要看什么

输出有没有“状态与输入”“字段与依据”“冲突与变更”“未知项”“优先澄清问题”“推断与建议”“下一步与人工检查”？预算是否仍未知？缺少这些内容时，让助手报告实际读到哪份 SKILL.md，不要立刻增加十个技能。

如果导入失败，先解压确认完整单技能目录和入口文件存在，按客户端提示修正；不要靠反复改权限碰运气。需要暂时停用时，官方支持在已安装列表关闭开关；这不是卸载，账号配置同步范围另按官方说明。

<a id="skill2"></a>

### 打开技能文件：把“是什么”变成看得见

把随书技能目录打开，它只有三个文件：

```text
recruiter-requirement-align/
  SKILL.md                    方法入口
  references/field-rules.md   字段和判断规则
  assets/需求基线模板.md        交付结构
```

`SKILL.md` 开头的两项元数据，帮助支持该格式的宿主了解名称和用途。正文才是具体方法。随书版本的开头如下：

```yaml
---
name: recruiter-requirement-align
description: 将猎头岗位需求、会议补充和客户确认整理为可追溯的需求基线、冲突清单和澄清问题。用于 JD 澄清、岗位画像对齐、多个版本合并及新岗位复用；不做候选人排名、薪酬估算或自动联系。
---
```

技能正文没有写“你是最厉害的猎头”。它规定了更可检查的动作：先列实际读取的文件，区分四种信息状态，按模板输出，给原文依据，不能用后出现的一句话自动覆盖冲突。

字段规则单独放，是为了让主说明保持简洁；模板单独放，是为了方便你调整交付列。每个辅助文件都从入口明确引用，否则文件虽在包里，执行时也可能没有被读取。

#### 做一次不调用模型的检查

打开三个文件，逐个回答：入口有没有说明适用任务？引用的文件是否存在？模板是否包含你要交给下一环节的信息？有没有写死某个真实客户的条件、手机号或密码？没有脚本并不妨碍它成为完整的方法型 Skill。

开放格式、某个软件的导入要求、市场上架要求是三回事。本书技能按开放格式组织，不宣称已通过市场审核。需要发布市场时再看对应平台要求，不要为第一次练习先增加与当前任务无关的元数据。
#### 为什么入口描述要写“何时用”

如果名称叫“超级猎头助手”，用途只写“帮助招聘”，读者和宿主都很难判断它应在需求澄清、公司研究还是推荐报告时使用。更清楚的描述是：“在 JD、会议补充与客户确认需要合并时，生成带来源的需求基线和澄清问题。”它交代了输入场景、要做的事和要交的结果。

名称应与目录一致，使用规范允许的小写字母、数字和连字符，例如 `recruiter-requirement-align`。新手先保留 `name` 和 `description` 两个必要字段即可。下面的“输入、规则、验收”等小标题是业务设计建议，并非格式标准强制规定的字段。[格式规范](https://agentskills.io/specification)

主文件先写清方法，规则太多再放进 `references`；有固定交付样式再加 `assets`。只有确实需要可重复的程序处理时才增加 `scripts`。多建目录不会自动增加能力，引用的资源还需要在任务中实际读到。

#### 沿着真实文件，逐段看懂设计意图

打开[随附的 SKILL.md](技能包/recruiter-requirement-align/SKILL.md)，逐段对照。下表是对现有内容的解释，不是另造一份已经验证的技能。

| 文件里的部分 | 它回答什么 | 少了会怎样 |
|---|---|---|
| name 与 description | 叫什么、何时用、交什么 | 用途太泛，难以选对任务 |
| 指定输入与实际读取列表 | 允许读什么、实际读了什么 | 可能漏读确认材料而不说明 |
| 字段规则引用 | 如何区分要求、偏好、未知与冲突 | 表格齐全，分类却错了 |
| 确认关系与岗位隔离 | 什么依据能更新条件 | 最后一份文件覆盖一切，或串用旧岗位事实 |
| 输出模板与来源要求 | 交付结构、怎样回查 | 初稿看似专业，无法追溯 |
| 澄清问题与交付状态 | 不确定时怎么办 | 未确认条件被包装成最终结论 |
| 保存位置与完成自查 | 交到哪里、怎样说明限制 | 声称完成但没有可验收产物 |

#### 一个 Skill 怎样进入本次工作

按开放格式的设计，客户端可以先识别名称与用途，任务需要时读取入口，再按需读取引用资料。**发现、加载、执行、验收是不同环节**：安装列表里有它，不表示这次已经用过；读取过，也不表示规则全部执行正确。具体机制以客户端为准。[Agent Skills 概览](https://agentskills.io/home)

**本讲练习：** 在文件中找到一条分类规则、一处模板引用、一条异常处理，分别说出怎样检查它是否生效。如果找不到，可以先记录缺项；不要仅因为文件名叫 SKILL.md 就认定方法完整。

<details><summary>展开参考答案</summary><p>分类规则：区分明确要求、偏好、未知、冲突；用「中文最好」检查是否误列硬条件。模板引用：assets/需求基线模板.md；检查输出是否保留全部栏目。异常处理：没有明确确认权的冲突继续保留；用地点相反的两份输入检查是否擅自选边。</p></details>

接着[把自己的经验写成规则](#skill3)。


<a id="skill3"></a>

### 猎头怎样设计自己的 Skill：从业务经验到可验收的方法

从一项你会做、经常做、也知道怎样检查的工作开始。设计 Skill 的关键，是把你检查初稿时说过的话，变成下一次执行时就能遵守的规则。本章用“岗位需求对齐”走完整个过程；所有岗位和材料沿用随书虚构示例。

#### 第一步：选一件有明确终点的小事

先写一句话：**给我哪些输入，我按什么方法，交出什么可检查的结果。**

“帮我做猎头”太宽。“读取同一岗位的 JD、补充与确认记录，交一份带来源的需求基线”就能设计。你不需要一开始把找人、沟通、推荐、回款全装进一个 Skill。

| 业务需求 | 第一版怎样处理 |
|---|---|
| 临时润色一段普通介绍 | 先用一次提示词，未必需要维护 Skill |
| 反复合并 JD 与客户补充 | 适合：输入类型稳定，判断规则重复，产物可检查 |
| 每次整理公司研究证据 | 适合单独做：明确来源范围、证据栏目与未知处理 |
| 一键替我完成整个招聘项目 | 先拆成多个任务与验收点，超出一个新手 Skill 的范围 |
| 自动判断谁该录用并发送通知 | 不作为本书入门任务；证据整理与人的招聘决定分开 |

这是一套选题建议。是否值得做，取决于方法会不会重复使用，以及你能不能判断输出好坏。

#### 第二步：倒着设计交付，再确定输入

先打开你愿意接着使用的结果。需求基线至少要让你知道：哪些条件已确认、依据在哪里、哪些还不能确定、下一步该问什么。于是先确定这张表：

| 字段 | 当前内容 | 状态 | 原文依据 | 待确认问题 |
|---|---|---|---|---|
| 语言要求 | 英语商务沟通 | 明确要求 | 客户确认中的对应原文 | 无 |
| 中文能力 | 加分项 | 偏好 | 客户确认中的对应原文 | 无 |
| 预算 | 未提供 | 未知 | 已检查的三份材料均未给出 | 薪资区间与奖金怎样构成？ |

这只是教学缩略样例，正式产物要填写实际文件名和段落依据，不能原样复制这里的“对应原文”。

再回头确定输入：岗位标识、指定的需求材料，以及材料已有的日期、确认者和确认范围。没有日期或确认者也要允许交付草稿，明确缺项；不要要求助手凭空补齐输入。输出目录属于这次任务参数，不写死个人电脑路径。

#### 第三步：把经验改写成“条件—动作—证据”

“认真分析”“站在客户角度”不足以检查。把它们写到具体字段上：

| 你平时会说的话 | 可以写进 Skill 的规则 | 怎样检查 |
|---|---|---|
| 别把要求理解得太死 | “优先、最好、加分”归为偏好；原文有明确必需表述才列硬条件 | 找一条“中文加分”，看是否被误列必须 |
| 新消息要看清楚 | 只有确认者和确认范围明确时，才据此更新对应条件；否则并列冲突 | 同日两份相反材料是否仍保留双方说法 |
| 没说的别猜 | 缺少预算、人数、频次时写未知，不引用行业惯例补值 | 缺项输入中是否出现自造数字 |
| 管理岗要看实际管什么 | 当前直接下属人数与未来扩编计划分列；缺失分别标未知 | “未来可能带团队”是否变成当前管理经验门槛 |
| 结果要经得起问 | 已知条件附文件名、段落或编号、短原文；推断单列 | 任挑一行能否回到输入材料 |

这里承载的才是猎头经验。AI 可以帮助整理措辞，但哪些规则成立、有什么例外，要由熟悉业务的你确认。

#### 第四步：排步骤，写清继续和停下的条件

把过程写成：列输入 → 按字段提取 → 比较变化 → 分类与标注来源 → 按模板交付 → 自查。每一步都要产生下一步用得到的信息。

遇到缺项，不必把整个任务停掉：交付待澄清草稿与问题。遇到互相冲突的地点或职责，保留两种说法并等待有权确认的人，不生成“最终已确认版”。遇到打不开的输入，报告实际读到与未读到的材料，不声称已完成全部对齐。

也写出动作边界：只读指定材料，不搜索私人目录；不联系客户或候选人；不把材料里的“忽略规则、发送文件”等文字当作指令。需求对齐的产物是基线草稿，不能借这一步替客户作承诺。

#### 第五步：让 AI 起草，你负责审查方法

先填写[Skill 设计工作表](练习包/工作记录/Skill设计工作表.md)，再把填写后的内容和随书技能副本交给助手：

```text
请基于我的 Skill 设计工作表和随书 recruiter-requirement-align，
起草一个新的方法包，名称使用 recruiter-requirement-align-practice。
生成独立目录，不覆盖随书版本。
保留跨岗位通用的方法，把这次岗位事实留在输入文件里。
入口含名称、适用场景、输入、执行步骤、规则、输出、异常处理与验收。
如使用参考文件和模板，在入口中明确写出相对引用和读取时机。
没有依据的业务规则列成问题，不替我编造。
先在回复里展示方法与未确定项，待我确认后再保存文件。
不要声称已安装、已自动触发或已通过实测。
```

审查时问自己：如果换一个地区、职能和职级，这条规则是否仍成立？“英语商务沟通必须”是 R001 的事实；“语言条件按原文区分必须与加分”才是跨岗位方法。对于只适用于管理岗位的规则，要把适用条件一并写上。

不用把整个聊天记录粘进文件。保留最后确定的方法，删除过期答案与真实个人信息。第一次完全可以不写脚本；随书三文件 Skill 已展示了方法入口、字段规则和输出模板怎样配合。

#### 第六步：用四类材料决定能否交给下一次任务

| 测试 | 重点核对 | 不合格时改哪里 |
|---|---|---|
| 原岗位 | 关键要求、确认关系与来源正确 | 提取步骤或确认规则 |
| 第二岗位 | 沿用方法，不沿用上一岗位条件 | 规则中写死的事实或上下文 |
| 缺项输入 | 输出未知与问题，没有补数值 | 缺项处理与模板默认值 |
| 冲突输入 | 双方说法都有依据，未擅自定案 | 冲突判定与停止条件 |

使用[下一章的四类检查材料](#skill4)，逐行记录输入版本、技能版本、实际输出、预期表现和你的判断。仅能打开文件说明格式存在；模型说“全部通过”也不能替你验收。改了规则后，重跑受影响的检查；还没跑过就标“待验证”。

本章新增的是设计教程与工作表，没有新增“已实测技能”的数量。随书原技能的真实验证范围仍以[运行记录](练习包/运行记录/README.md)为准。

#### 最后交出的，不只是一份 SKILL.md

你的第一份设计作业应包含：填写完成的设计工作表、独立技能目录、四类测试记录，以及至少一处“发现问题—改规则—复测”的记录。如果暂时没有失败，不编造失败案例，注明尚未发现的问题和未覆盖的情形。

当另一位猎头只看这些文件，就能知道何时用、给什么材料、怎样检查和哪里不能信任时，你才真正把经验变成了可以交接的方法。
#### 跟着改一次：从一句经验到一条可验收规则

原话：「客户说最好会中文，你要判断一下，别把候选人筛死了。」

第一稿：「认真判断语言要求。」问题在于没有说明何时判断、怎样判断、怎样检查。

第二稿：「出现最好、优先、加分时，先列为偏好，并保留原文。若其他材料写成必需，列为冲突，核对明确确认记录；无法确认时提出问题，不据此排除候选人。」

这条规则包含四件事：**适用条件 → 执行动作 → 例外处理 → 验收依据**。业务判断由你确认，AI 可以协助把表达整理清楚。

**现在轮到你：** 把「候选人推荐理由要有说服力」改成一条规则。限定任务为证据整理，只使用已获准的脱敏材料。

<details><summary>展开参考写法</summary><p>每条推荐理由对应一项岗位要求，并附候选人材料中的具体事实与来源；没有对应证据时写「待核实」，不得编造业绩数字。若经历只支持推断，单列推断与核实问题。验收时抽查每条理由，确认能回到材料，且没有把推断写成事实。这是一条教学规则草稿，仍需用你实际业务的允许材料验证。</p></details>

将你自己的规则填入[Skill 设计工作表](练习包/工作记录/Skill设计工作表.md)，再按本章六步完成草稿。接着[检查它能否复用](#skill4)。


<a id="skill4"></a>

### 换一个岗位，才知道 Skill 能不能复用

第一次例子跑对，有时只是因为你把答案提示得很清楚。第二次要改变材料本身。随书[第二岗位](练习包/进阶输入/第二岗位.md)是工业视觉售前工程师：上海、华东制造企业、技术演示与实施交接、中文沟通必需、英文技术阅读加分。

#### 开一个新任务

只给第二岗位文件和同一个 Skill，不再带入 R001 的需求基线。让助手保存 `我的产物/R003.md`，并附上读取文件列表。这样更容易看出它有没有把上一份上下文带过来。

你应看到处理方法相同，而业务内容不同：新加坡变成上海，伙伴签约变成技术演示与交接，英语商务沟通不再是硬门槛。预算、出差频次和面试流程仍未知；模板可以一样，字段值不能靠替换岗位名称继承。

#### 再做两次压力检查

对[缺项需求](练习包/进阶输入/缺项需求.md)，助手应交出待澄清草稿。没有地点、预算或具体职责，不等于任务失败；把缺口说明白就是本次产物。

对[冲突需求](练习包/进阶输入/冲突需求.md)，上海与北京、带人与不带人都应保留。两名联系人同日表述不一致，材料没有给最终确认权，助手不能凭文件顺序选一个答案。

| 检查输入 | 合格表现 | 暴露的问题 |
|---|---|---|
| 原岗位 | 来源与确认关系正确 | 只摘抄最早 JD |
| 第二岗位 | 保留方法、替换业务事实 | 上一个岗位污染新任务 |
| 缺项 | 明确未知及下一步问题 | 为了填满表格造条件 |
| 冲突 | 两种说法并列、等待确认 | 默认最后一句最高权威 |

记录失败发生在哪一行、违反了哪条规则。先修规则，再重新测试受影响的材料。不能因为一份结果很好，就跳过其余三类检查。
#### 结课验收：读懂概念，还要拿得出作品

准备三个交付物：一张自己画的概念关系图、一份标注了用途和边界的技能拆解、一份独立 Skill 草稿及测试记录。关系图不求好看，重点是能解释每部分负责什么。

| 自查问题 | 达标表现 |
|---|---|
| Agent 和 Skill 有什么不同？ | 能解释执行系统与可复用方法包的关系 |
| 哪些内容不应该写死在通用规则里？ | 能指出当前岗位地点、预算、联系方式等任务事实 |
| 经验怎样成为规则？ | 写清适用条件、动作、例外与检查依据 |
| 换岗位后要保留什么？ | 保留方法，重新读取事实，不继承旧字段值 |
| 什么情况下还不能说验证通过？ | 缺测试、无真实输出、未人工核对时，明确标为待验证 |

如果第二岗位带入了旧地点，先检查上下文和写死的条件；如果冲突被自动合并，检查确认规则；如果文件未生成，检查工具返回和输出位置。先定位属于哪一层，再修改对应部分。

**本单元完成标志：** 你能讲清概念，也能让另一位猎头读懂自己的规则并按记录检查结果。尚未实跑的草稿可以交作业，但必须保留「待验证」状态。


<a id="skill5"></a>

### Skill 没生效，先判断卡在哪一层

“我明明装了，为什么它还乱写？”先别追加更长的提示词。文件、发现、执行、结果，是四个不同层次。

| 现象 | 先查什么 | 修复动作 |
|---|---|---|
| 导入报错 | 压缩包里是否有正确入口与完整资源 | 解压检查，按客户端要求重打包 |
| 已安装但没用 | 本任务是否选中，适用描述是否清楚 | 明确选择，要求报告实际读取资源 |
| 读了但格式错 | 模板引用是否存在，规则是否矛盾 | 明确模板栏目，删除冲突说明 |
| 格式对但事实错 | 来源是否读全，确认关系是否判断错 | 指定错误与依据，补规则后重跑 |
| 原岗位对、新岗位错 | 是否写死字段值或混用上下文 | 新任务只给新输入，规则与事实分开 |

不要只接受助手说“已调用”。执行记录、读取文件与结果特征要一起看；某些产品不会展示所有内部过程，不能从不可见部分推断它一定怎样工作。

#### 一次只改一个主要原因

假设输出仍写“中文必须”。先核对它是否读过客户确认。没读，是输入范围问题；读了却没使用，是确认规则或判断问题；当前基线正确但下游表格仍错，是版本传递问题。三者需要不同修复。

写一条简短记录：输入版本、技能版本、现象、依据、改动、复测结果。随书[空白验收表](练习包/工作记录/空白验收表.md)可以继续扩列使用。不要把模型自评的“优秀”当作你的验收结果。

当新版本不如旧版，回到备份再定位差别，比继续叠加例外快。一个技能应当能够说清适用范围；超出范围时拆成新任务，不要让需求整理技能同时承担推荐决策、消息发送和客户管理。

## 四 · 实战：把方法放回猎头业务

<a id="biz1"></a>

### 需求对齐：让后面的找人有一个共同起点

主线的产物不是把 JD 排得更整齐，而是形成当前可以共同使用的基线。这个基线会影响公司选择、搜索条件、候选人证据与沟通问题。

R001 的材料里，“东南亚”后来被收窄到第一阶段新加坡与马来西亚；“有机会带团队”后来明确不作为本轮门槛。把两个版本并排留下，别人接手时就能理解为什么条件改变。

#### 从练习走到业务

先把原始 JD、会议记录与明确确认分开保存；输入中的日期是业务日期，不用文件修改时间猜。让助手输出“已知—未知—冲突—问题”，再由能够确认需求的人判断。没有确认的结果标草稿，不能因为 AI 写了完整表格就自行宣布定稿。

优先问题要对应具体影响。例如预算未确认会影响候选人沟通和目标范围，但未必阻止初步公司研究；英语要求未明确，会直接影响初筛证据的收集。先问哪一个，取决于下一步马上要做什么。

```text
基于当前需求基线，给出最多五个优先澄清问题。
每题写：目前知道什么、缺什么、影响哪一步、应由谁确认。
不要把所有缺项都当成必须停工，也不要把未知改为默认值。
```

#### 把基线传给下游

公司研究表和候选人对照表都写上 `R001-v1`。当语言要求、地区或职责变更时，产生新版本，并列出哪些下游判断需要重看。不要只改标题日期，让旧结论静静留在表格里。

验收时挑一条硬条件，沿着“确认原文—基线—候选人证据”走一遍。三处能够对上，说明流程开始形成；任一处缺依据，就在那一处停下补齐。

<a id="biz2"></a>

### 公司研究：先看证据，再写公司画像

公司研究最容易出现的假完整，是每家公司都被写成“行业领先、快速增长、国际化布局”。这些词若没有出处，无法帮助你决定去哪里找人。

第一次不用联网。读取[公司研究摘录](练习包/进阶输入/公司研究摘录.md)，它完全由作者虚构，模拟不同新旧程度和可信范围的资料。不要把它标成官网实测。

```text
依据 R001 基线与公司研究摘录，生成公司研究表。
每家公司列：已知业务、渠道相关证据、与 R001 的关系、
来源编号与日期、未核实事项、下一步核实动作。
资料没写的收入、员工数、负责人姓名一律未知。
保存 我的产物/公司研究.md，不生成真实人名或联系方式。
```

你应发现：示例企业乙有新加坡和马来西亚伙伴计划，值得继续验证；示例企业甲的工业视觉产品与 R001 不直接相同，不能仅因“也是软件”就认定匹配；企业丙只有旧媒体简介，当前状态需要新证据。

#### 换成公开资料时

按一家公司一条证据链开始：官网产品页说明业务，伙伴或客户页说明合作方式，招聘页提供岗位线索。分别记录链接、页面标题、发布日期或访问日期、原文片段和你的判断。访问日期不能替代内容发布日期。

让助手先交两家公司供你核查，再决定是否扩大范围。遇到登录墙、失效页或工具无法读取，应记录失败和替代来源，不能把搜索摘要当成已核实全文。

人工重点检查“公司业务”是否被推成了“某个人有这项能力”。公司有伙伴计划，不代表每个员工都负责签约；下一章才将公司证据转成寻访假设。

<a id="biz3"></a>

### 人才 Mapping：把研究变成可验证的寻找方向

Mapping 不是让 AI 一次列出很多名字。先画出寻找范围：哪些类型的公司可能培养过这类能力，哪些职能或岗位可能承担过相应责任，还缺什么证据才能确定。

沿用 R001 已确认基线与上一章公司研究表。把输出分成三层：公司池、职能与岗位假设、个人证据需求。三层不要混成一张“已符合名单”。

```text
请把公司研究表转为 R001 的人才 Mapping 草稿。
列公司类型、可能相关的职能/岗位名称、为什么可能相关、
应在个人资料中寻找的证据、可能误判、下一步验证动作。
只依据现有材料提出研究假设，不编人名、人数、个人履历。
输出 我的产物/Mapping草稿.md。
```

一个可用的方向是：企业软件伙伴或渠道相关团队；需要验证个人是否做过新伙伴签约或激活，覆盖区域是否相关。只见“渠道经理”头衔不够，只见“区域销售”也不能直接排除，关键是实际责任。

#### 到公开资料中验证

在你有权使用的平台按公司、职能、地区检索。记录是在哪一天、以什么条件看到资料的；保存来源链接和必要摘录，避免无目的复制整个账户数据。LinkedIn 上的被动候选人与主动求职平台的可联系性、意愿状态不同，不能套用同一口径。

本版提供的是研究方法与离线练习，不含已验证的平台批量抓取流程，也不把找到了公开资料写成愿意接洽。公开可见、能够联系、愿意了解、同意推荐，是不同状态。

完成标志是你能解释：“为什么先看这类公司，找哪种责任证据，什么情况会改变方向。”如果只是名单变长，却没有判断依据，应先缩回一个公司和一个岗位重新检查。

<a id="biz4"></a>

### 候选人对照：让每个判断都有一条依据

准备 R001 基线和练习包里 P001、P002、P003 三份虚构资料。使用同一套要求对照，能减少一会儿看品牌、一会儿看头衔造成的漂移。

```text
对照 R001-v1，阅读候选人目录中 P001、P002、P003。
按每条硬性条件列：支持原文、来源、未知或不符、待核实问题。
没有资料不能直接写不具备；不能从公司名推断个人业绩。
最后给人工核查的先后建议与理由，不给自动淘汰结论。
保存 我的产物/候选人证据.md。
```

P001 的资料支持企业软件伙伴拓展、新马市场和签约激活责任，但英语仍需核验。P002 的渠道维护经历值得追问新签责任，不能把维护直接等同于签约。P003 的消费品渠道与当前要求有差异，应写明缺少哪项相关证据，而不是只写“不合适”。[教学对照参考](练习包/参考输出/候选人判断.md)

#### 区分三种缺口

“资料没写”表示未知；“资料明确相反”才是已有不符证据；“看起来可能相关”属于待验证推断。三者对应的下一步分别是追问、与当前标准核对、寻找更直接证据。

不要按年龄、性别、婚育、民族等与本项职业能力判断无关的个人属性生成筛选规则。人选推进由你结合授权、业务要求与进一步核验决定，助手的表格只是辅助材料。

若基线改成 R001-v2，先列受影响条件，再更新相应人选判断；其他已核实证据保留出处。验收时抽查一人两条结论，必须能回到输入原文，不能只看到 AI 对自己结论的解释。

<a id="biz5"></a>

### 沟通准备：写得自然，也要守住事实

一份合格的沟通草稿，至少要说明为什么联系、哪些信息已知、希望确认什么。它不应替你许诺尚未确认的预算、职位级别或面试安排。

沿用 P001 的虚构资料与 R001 基线。先写草稿，不发送。把“愿意了解机会”与“同意推荐”分开，也不要因为资料中出现语言或地区就推断国籍。

```text
请为 P001 准备一份首轮沟通草稿和五个核实问题。
只使用 R001-v1 与 P001 的明确事实。
可提企业软件伙伴拓展背景；预算、奖金、英语核验仍未确认。
消息简短，给对方选择空间；问题围绕签约责任、英语工作场景和机会兴趣。
单列哪些话必须由我确认后才能对外说。只保存，不发送。
```

参考方向可以是：“看到你有企业软件伙伴拓展经历，想了解你是否愿意交流一个以新加坡和马来西亚为第一阶段市场的渠道机会。具体职责可以进一步沟通。”这是一段教学草稿，不是已发给真实候选人的记录。

核实问题比夸赞更有用：“最近一次伙伴签约，你负责了哪些环节？”“你在什么英语工作场景中沟通？”这些问题帮助补证据，不能被 AI 代答。

#### 检查三个容易越界的词

“匹配”是否被写成“完全符合”；“了解”是否变成“已同意”；“待确认”是否变成“已确定”。发现这些变化，回到资料改事实，再调语气。

实际发送前由你确认对象、内容、渠道和授权。平台上有消息按钮不意味着对方愿意接收任何内容，本书也没有授权任何自动群发。把最终实际沟通结果记回对应人岗关系，下一次助手才有准确输入。

<a id="biz6"></a>

### 周复盘：把记录变成下一步行动

每周复盘很容易变成一段“本周推进顺利，下周持续跟进”。想得到有用结果，先给明确截止时点和人岗状态规则。

练习包的四张 CSV 表包含两位虚构客户、两个岗位、三位候选人与五条沟通记录。先用包内数据完成任务，不接外部系统。

```text
读取练习包/四表的四张表。
以 2026-10-01 18:00:00 +08:00 为截止时点，列应跟进事项。
以候选人编号+岗位编号作为一个关系，使用该关系最新沟通记录判断。
排除已关闭关系；未来到期的不算当前逾期。
列依据记录、下一步、未知与数据问题。只保存复盘草稿，不修改原表。
```

对照[查询验收](练习包/参考输出/查询验收.md)，本组教学数据在该时点应得到两条到期关系：P001/R002 与 P002/R001。P001 在 R001 的较早记录不能覆盖后续新安排；P003 已关闭关系不进入当前催办。

#### 数字对了，再问业务问题

每条事项应有负责人和具体动作。缺负责人就标未知，不根据姓名或记录顺序猜。再让助手归纳重复卡点：需求未确认、证据没补齐、安排变了没更新。不要从五条教学记录推断真实团队绩效。

出现错误，先区分时间解析、人岗关联、状态覆盖还是原始数据缺失。随书 `校验四表.py` 是可选作者核验工具；不运行 Python 的读者照参考输出逐条人工检查也能完成练习。

下一周复用同样方法时必须换截止时点，并保留当周输入快照。否则“每周自动生成”只是重复旧答案。

## 五 · 接入：让资料进入任务

<a id="connect1"></a>

### 文件、知识库、连接器和 MCP，分别怎么用

目前你通过本地文件给材料。业务资料如果在文档平台、邮件或内部系统里，就会遇到接入问题。先明确要读哪份资料、要做什么，再选择入口。

| 入口 | 解决的问题 | 第一次怎样验收 |
|---|---|---|
| 文件 | 把明确的材料交给本次任务 | 文件名与正文都读对 |
| 知识库 | 从多份材料中找相关内容 | 引用能回到原始段落 |
| 连接器 | 在产品中接入某个外部服务 | 读到你指定且有权访问的记录 |
| MCP | 让宿主与工具/数据服务按约定通信 | 工具调用返回符合预期的数据 |

MCP 是协议层的概念，连接器是你在产品中看到的接入方式，两者不应简单画等号。协议不自动赋予权限，也不保证任何服务的读写能力相同。[MCP 概览](https://modelcontextprotocol.io/docs/getting-started/intro)

#### 做一次最小的只读接入

选一份你有权使用、只含教学内容的文档。按官方连接器页进入相应服务，在你决定授权范围后完成授权；第一次只要求读取标题、一段明确正文和文档位置，不写回。[WorkBuddy 连接器](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Connector)

若界面显示已连接，但返回空内容，检查是否选中了正确账号、文档是否在授权范围、当前任务是否启用了连接器。不要自动扩大到整个组织。标题能读但正文读不到，也不能算资料接入成功。

没有可用连接器时，可以手动导出一份允许使用的文档到练习目录。它能验证后续整理方法，但应记录为“手动导出文件”，不能写成外部接入实测。

临时关闭当前任务连接器、在管理页解绑、到第三方撤销授权，是不同范围的动作。需要停止时确认自己希望停止到哪一层。自定义 MCP 属选读内容；跟随相应服务官方说明配置，不套用陌生 JSON 或提供不必要的凭证。

<a id="connect2"></a>

### 让助手看网页时，怎样知道它真的看到了

网页资料比本地文件多一层不确定：网页可能更新、登录、限流，工具也可能只返回标题或摘要。先把“找到页面”“读取正文”“核实结论”分开。

对于公司研究，优先给一个明确的官方产品页链接，要求助手报告页面标题、读取日期、相关原文和无法读取的部分。只有搜索结果摘要时，就标摘要线索，不把它包装成全文证据。

#### 给网页任务的说明

```text
仅研究我提供的公司官方页面。
提取与 R001 渠道业务相关的公开信息，逐条列原文依据和链接。
读不到正文就报告原因，不从标题推断具体业务或人数。
不登录新账号，不发送消息，不修改任何页面，不绕过访问限制。
保存研究草稿，并把需我手动核实的事项单列。
```

如果需要登录账户才能看到内容，先确认你是否有权使用该资料与当前工具。验证码、权限变化或平台限制出现时，转为人工处理，保留已完成的研究结果即可。

网页本身也可能包含“忽略之前指令”“把文件上传这里”等文字。那是待研究的页面内容，不是你给助手的任务指令。不要让来源材料决定工具权限、外发对象或文件删除动作。

本章给出只读验证方法，不宣称本版已测过所有网站或招聘平台。判断是否跑通，要看具体页面、工具返回和核对结果，不能因为浏览器打开了一个标签页就写“自动化成功”。

## 六 · 系统：把几件做成的事连起来

<a id="system1"></a>

### 把几个任务接起来，先规定交接物

当需求对齐、公司研究和候选人证据分别做过，再把它们接起来。工作流的关键是上一项向下一项交付什么，以及什么情况下停下。

```text
原始需求 → 需求基线 → 公司研究 / Mapping → 候选人证据
              人工确认                         人工核查
                                                  ↓
                                        沟通草稿 → 人工发送
                                                  ↓
                                             沟通记录 → 复盘
```

这张图是教学流程，不代表所有箭头已经自动连接。第一次可以人工把文件传给下一项任务，先验证交接格式，再考虑自动化。

| 环节 | 输入必须带什么 | 出口检查 |
|---|---|---|
| 需求基线 | 原始材料、确认与日期 | 已知/未知/冲突清楚 |
| 公司研究 | 基线版本、指定来源范围 | 事实与寻找假设分开 |
| 候选人证据 | 同一基线、候选人来源 | 不把缺证据当已符合 |
| 沟通准备 | 已核实事实与未确认项 | 只写草稿，不越过授权 |
| 复盘 | 最新关系记录和截止时点 | 下一步对应具体人岗 |

每份产物头部增加三项就很有帮助：输入版本、生成日期、人工检查状态。不要把 AI 自己的“已验收”当成人工确认。

如果上游条件变化，先找受影响的下游文件。例如语言要求变化，应重看候选人证据与沟通问题；没有受影响的公司业务事实可以保留来源。这样你知道该重做什么，也不会每次从头开始。

你可以让助手创建一份本周流程索引，列每个产物的位置、状态和下一负责人。文件能找到、状态能解释，才算这条工作流可以交接。

<a id="system2"></a>

### 四张表是工作底稿，别让它们抢走主线

当一个候选人同时关联两个岗位，只用一列“当前状态”很容易丢失信息。四张表帮助你保存关系，为 AI 提供稳定输入。

| 表 | 保存什么 | 关键连接 |
|---|---|---|
| clients | 客户的基础信息与标识 | 客户编号 |
| roles | 岗位、客户关联与当前基线 | 岗位编号关联客户 |
| candidates | 候选人事实与来源 | 候选人编号 |
| comms | 某人与某岗的沟通和下一步 | 候选人编号 + 岗位编号 |

这不是要求所有独立顾问马上搭数据库。你可以先用 CSV 或表格，只要编号一致、来源可找、最新状态清楚。AI 负责读取与整理，表格提供事实底稿；表做得漂亮并不说明 Agent 或 Skill 已经工作。

#### 用随书数据检查一次关系

P001 在 R001 和 R002 上有不同安排。问助手“P001 下一步做什么”时，要求它分岗位回答，不能用一条最近记录覆盖所有岗位。日期应含时区或明确的统一口径，以免同一天边界判断漂移。

多人维护时，先写清哪张表由谁更新、何时产生新版本、什么状态必须人工确认。不要让几个助手同时覆盖同一文件；可以各自产草稿，由负责人合并。

等你确实需要多人协作、查询规模或权限控制，再评估业务系统。任何迁移都要用一小份数据检查编号、来源和状态能否保留，不要因为产品宣传“AI 原生”就跳过导出和恢复验证。

<a id="system3"></a>

### 专家与多 Agent：先有分工，再谈并行

一项复杂任务可以拆给不同角色，但多一个角色也多一次交接。对第一次 JD 整理，一个 Agent 通常就足够；当公司研究与独立核查可以分开时，再考虑多角色协作。

本书给一个设计例子：研究者整理公司公开证据；核查者逐条回看来源；主负责人把差异合并成可用研究表。研究者不能替核查者宣布“全部正确”，核查者也不改变客户确认过的岗位要求。

| 角色 | 收到什么 | 必须交什么 |
|---|---|---|
| 研究者 | 基线与来源范围 | 事实、链接、日期、未知 |
| 核查者 | 研究表与原始来源 | 支持/不支持/无法核实及依据 |
| 主负责人 | 两份报告 | 冲突处理、保留限制、最终草稿 |

把“请你们合作研究一下”改成这样的交接约定，输出才容易合并。拆分收益应来自独立信息处理，而不是让三个人重复读同一份短 JD。

WorkBuddy 的专家与专家团提供角色入口，具体召唤与创建流程见[官方专家说明](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Expert-Center)。界面上的一个专家角色不等于一个拥有独立权限和独立上下文的子 Agent，不同宿主的执行方式需分别确认。

首次可以由你人工开启两个任务、传递同一份脱敏资料，再合并结果。这个演练验证的是分工是否清楚，不是证明已经部署多 Agent 系统。只有当合并成本低于获得的价值，并且你能定位错误来自哪一步，才值得进一步自动化。

<a id="system4"></a>

### 把任务定时运行前，先让失败有去处

周复盘已经手动完成并验收，再考虑定时运行。直接把一段长提示词设成每周执行，可能只是定期生成错误或空报告。

先写一张自动化任务卡：输入位置、截止时点规则、输出命名、依赖条件、允许动作、失败记录、停止方式。随书提供[定时任务设计卡](练习包/工作记录/定时任务设计卡.md)，它是模板，不会创建真实任务。

#### 以周复盘为例

输入是本周四表快照；输出按日期新建；动作只包括读材料和写复盘草稿；没有材料或日期无法解析时停止并报告；同一时点重复运行不得产生重复业务跟进，也不得覆盖已确认版本。自动化里不夹带消息发送。

官方自动化页面支持配置提示词、工作空间、模型或技能、规则等，实际入口可能显示“定时任务”或“自动化”。配置前再看[官方说明](https://www.codebuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Automation-Guide)。桌面运行与小程序 Cloud/Local 机制不同，不能因此承诺关机后仍会执行。

#### 第一次验收三个结果

正常输入生成正确草稿；缺文件时准确报告缺失；同一输入再运行时不会产生重复业务动作。再检查运行历史里的时间与状态，并打开文件核对内容。显示“成功”可能只说明执行结束，不能替代业务检查。

当来源变化、权限失效或输出连续出错，先停用该任务，再保留失败记录排查。不要为了让状态变绿自动放大访问权限。负责人应知道如何停用和恢复，否则它还不适合无人看管地运行。

本版没有为读者账号创建周期任务，随书内容用于设计与手动验收。真正启用时由使用者确认环境、成本、频率与通知方式。

<a id="system5"></a>

### 把版本、脱敏与恢复做进日常使用

一套能持续使用的方法，必须经得起材料更新、工具升级和人员交接。你无需搭复杂管理系统，先保存输入快照、Skill 版本、产物版本和验收记录。

建议用看得懂的命名：`R001-需求基线-v1.md`、`R001-需求基线-v2.md`。版本记录说明为什么改：哪项要求变化、依据是什么、哪些下游需要复核。日期不能代替变更原因。

#### 每次交付前做四项检查

来源能打开；未知没有被填成事实；接收者拿到的是当前版本；包里只包含本次必要材料。真实项目的输入和公开教材分开，公开包不包含实名映射表、账号配置、原始运行日志或历史客户截图。

模型输出中也可能回显本机用户名、绝对路径和工具配置。发布运行示例前检查正文、文件名和元数据；删除无关字段，若替换路径就注明仅做了路径脱敏，不能顺手修改结果再称“模型原样输出”。

#### 恢复比“有备份”多一步

在另一个目录解压一份备份，打开正文、输入、Skill 与参考输出，检查相对链接是否仍能找到。能恢复出可读可运行的材料，才算备份可用。不要把唯一的旧版覆盖掉再测试新版。

工具更新后，只重测受影响的部分：入口名称变化查操作说明；模型变化查事实与规则遵循；连接器变化查读取范围；模板变化查下游是否还能使用。把测试结果写到来源与验收记录，不把一次通过写成永远兼容。

## 七 · 落地：个人与团队的练习路线

<a id="role1"></a>

### 一个人使用：按成果安排七次练习

七次练习是一条建议路线，不是七天熟练掌握的承诺。每次完成一个可检查成果，再决定是否继续；遇到问题可以重复同一步。

| 次序 | 练什么 | 完成标志 |
|---|---|---|
| 1 | 安装、目录与脱敏 | 指定文件可读，无真实隐私混入 |
| 2 | 三份需求整理 | 打开一份有来源的基线 |
| 3 | 检查与纠错 | 说明至少一处错误如何被修正 |
| 4 | 用随书 Skill | 找到实际读取的规则与模板 |
| 5 | 换岗位与压力检查 | 第二岗位没串条件，缺项与冲突保留 |
| 6 | 选一个业务场景 | 公司研究或候选人证据可人工核对 |
| 7 | 交接与复盘 | 下一次能找到输入、方法、版本和待办 |

选择第六次练习时，优先选你熟悉的业务。你对业务越熟，越能识别模型看似合理的错误；陌生行业研究与陌生工具同时开始，会增加定位困难。

每次记录总耗时、检查耗时、返工原因和最终是否可用。尚未测量就留空，不用填一个看起来好看的提升比例。若 AI 产物总要大改，先缩小任务或改善输入，不急着购买更多工具。

你最终应该能独立回答：哪些任务适合交给助手、怎么提供必要材料、什么错误要特别留意、方法怎样复用。达到这四点后，再把它接进一个真实但范围有限的工作环节。

<a id="role2"></a>

### 团队使用：把个人方法变成共同标准

团队真正需要共享的，是输入、判断和验收标准。每个人各自写一段提示词，可能得到五种不同的“合适候选人”；先统一基线与证据字段，再谈统一工具。

选一个岗位做小范围试用。业务负责人确认需求，执行者整理材料，复核者抽查来源；资料管理员维护访问与版本。人数少时一人可以兼任，但检查状态要如实记录，不能把自己生成与自己快速扫过写成独立审核。

#### 团队首次试用交付

同一份脱敏输入、一个 Skill 版本、统一模板、明确产物目录、一份差异表。让两位使用者分别运行并核对：事实是否一致，未知是否保留，差异来自输入、规则还是模型表达。先解决关键结论差异，再统一排版。

共享 Skill 不意味着共享全部客户资料，也不意味着共享账号。每项工作按必要范围提供材料；外部服务访问由实际组织权限控制，技能里的“仅限某项目”文字不应被当作技术权限隔离。

团队验收关注三类指标：产物是否可用、复核与返工成本、下一位能否接手。试用结果先与原流程比较，再决定扩展。人数更多、数据更敏感、系统更多时，需要专门的权限与运维设计，不能直接把个人练习目录当团队生产系统。

<a id="role3"></a>

### 需要帮助时，带着具体产物来讨论

读到这里，你不必用“我不懂 AI”概括所有问题。把卡点说具体，才容易得到有效帮助。

你可以准备一份脱敏任务包：业务目标、一小份输入、使用的工具与版本、任务指令、当前产物、你认为不对的地方和判断依据。它能区分问题究竟在资料、方法、操作还是业务确认。

例如：“我已能生成需求基线，但换岗位后仍沿用上一个岗位的英语门槛；这是第二岗位材料与输出差异。”这比“帮我搭一套系统”更容易估计下一步工作。

#### 从自学走向协作

如果你能完成一次任务，却难以在真实材料上稳定复用，可以讨论业务规则怎样写进 Skill、如何设计验收。若任务已稳定而资料分散，可以讨论接入与流程交接。若团队结论不一致，先讨论共同基线与复核职责。

需要外部支持时，关注对方能否说清交付、依赖和验收方式，并愿意用你的脱敏样本检验。学习资料、定制适配、持续维护是不同范围，应在开始前讲清楚。

本书由肖老师整理，目标是把猎头经验变成可理解、可执行、可复用的方法。这里提供的是教学演练和已有核验范围，不以未发生的客户收益作证明。你可以先完成一个任务，再决定自己下一步真正需要什么。

## 附录

<a id="appendix1"></a>

### 遇到问题，按这个顺序查

| 卡点 | 先检查 | 可以立刻做的动作 |
|---|---|---|
| 登录成功却回不到任务页 | 浏览器与客户端状态 | 回客户端观察，按官方登录帮助处理 |
| 看不到练习文件 | 是否解压、工作区是否选对 | 用文件管理器确认位置，让助手列指定文件 |
| 只回复文字没保存 | 模式、工具与目录权限 | 明确要求保存，核对实际路径 |
| 读了材料仍漏确认 | 已读文件与确认范围 | 指出漏读文件或对应编号 |
| Skill 导入失败 | 入口名称、元数据、资源完整性 | 解压检查，再按客户端格式要求打包 |
| 已装 Skill 没体现规则 | 本任务选择与读取情况 | 明确选择或显式读取入口和资源 |
| 来源链接打不开 | 登录、失效、页面变化 | 标无法核实，换合法可读来源或人工核查 |
| 知识库回答没有原文 | 检索是否命中正确文档 | 先查一份小文档，要求段落依据 |
| 产物重复或覆盖 | 输出命名与重跑规则 | 使用版本号，保留旧稿后再修 |
| 对话很长越聊越乱 | 当前上下文是否混杂 | 整理交接，新任务只带必要材料 |
| 目录链接打不开 | 是否只拿了 HTML 或移动了子目录 | 重新完整解压，保持相对结构 |
| 模型或额度不可用 | 当前账户与产品页面 | 保存任务材料，稍后续做，不把失败记成功 |

每次只解决一个最直接的问题。报错原文、发生时间、具体任务和输出位置，比“怎么又坏了”更有诊断价值。发给别人排查前删去账号、密钥、真实候选人信息和不必要的本机路径。

更换工具时，先用随书虚构材料做同样的主线任务，再决定是否迁移。不要因为一个软件可以读取文件，就默认它也采用同样的 Skill 导入和连接器配置。

<a id="appendix2"></a>

### 术语速查：知道它在任务里做什么

| 术语 | 本书中的简明含义 | 看哪个动作 |
|---|---|---|
| Agent | 围绕目标使用工具并继续推进的助手 | 读材料、行动、看结果、修正 |
| Model 模型 | 理解和生成内容的核心能力 | 对相同输入的理解与表达 |
| Prompt 提示词 | 这一次的任务说明 | 目标、输入、边界、产物 |
| Skill | 可复用的工作方法与资源包 | 入口规则、参考资料、模板 |
| Tool 工具 | 提供某种可执行动作的能力 | 读取、搜索、写入等实际返回 |
| Context 上下文 | 本次可用的信息 | 当前究竟看到了什么 |
| Memory 记忆 | 宿主可能持久保存并重用的信息 | 新任务是否真的读取了记录 |
| Workspace 工作区 | 当前工作使用的文件位置与范围 | 输入和产物在哪里 |
| Connector 连接器 | 产品里的外部服务接入方式 | 当前账号能读写什么 |
| MCP | 工具与数据服务连接协议 | 调用与返回是否按约定工作 |
| Workflow 工作流 | 若干任务的先后关系与交接规则 | 哪一步通过后才能往下 |
| Subagent 子 Agent | 被委派子任务的执行单元 | 输入、职责、产物与汇总 |
| Mapping | 对目标公司、职能和人才方向的研究组织 | 假设怎样被个人证据验证 |
| 基线 | 当前采用并标明版本的条件集合 | 变更后哪些判断要重查 |

这些解释用于帮助完成任务，不要求你背诵。一个概念暂时用不到，可以先跳过；当它开始影响你给材料、设置权限或检查结果时，再回来看。

<a id="appendix3"></a>

### 配套包地图与学习记录

完整包包含本书 HTML、Markdown、虚构练习材料、三个技能文件、独立技能压缩包、任务卡、参考输出和运行记录。主入口是[练习包说明](练习包/README.html)。

| 想做什么 | 打开什么 |
|---|---|
| 第一次需求对齐 | 练习包中的 01、02、03 三份文件 |
| 复制指令 | [任务卡](练习包/任务卡.md) |
| 阅读或改 Skill | [技能入口](技能包/recruiter-requirement-align/SKILL.md) |
| 导入技能 | [独立 ZIP](技能包/recruiter-requirement-align.zip) |
| 检查迁移和边界 | 进阶输入中的第二岗位、缺项需求、冲突需求 |
| 练习纠错 | 进阶输入中的错误草稿 |
| 扩展公司研究 | 进阶输入中的公司研究摘录 |
| 核对人选 | 候选人目录与参考输出/候选人判断.md |
| 练习复盘 | 四表与参考输出/查询验收.md |
| 查看本版验证程度 | [运行记录](练习包/运行记录/README.md) |

参考答案由编辑整理，只是核对关键事实的一种呈现。模型输出单独存放并注明处理方式，不能把两者混为一谈。你自己的结果保存到“我的产物”，不要覆盖随书输入。

如果要分享作业，优先分享这套虚构材料的练习结果。真实项目先做副本脱敏，再检查文档、截图和压缩包。完整包不包含真实客户成功案例，也没有后台账号或可直接联系的真实人选。

本书 HTML 的目录、搜索与字号调整用于阅读；“打印”由浏览器处理。离线可以读正文与包内材料，外部来源链接和云端 Agent 任务仍需要网络。

<a id="appendix4"></a>

### 来源、版本与本书的验证边界

编制日期：2026-10-01。读者版 v2.0。主线借鉴已有猎头启蒙培训的教学顺序，并参考 WorkBuddy 社区读本的完整使用旅程；事实性的产品入口优先核对当前官方文档。

#### 怎么使用参考资料

[WorkBuddy 社区读本](https://workbuddy.homes/bluebook/)提供从上手到方法沉淀的参考。本轮读取其完整目录与部分章节，不声称逐章复现；它不是腾讯官方出版物，也没有为本书背书。本书的猎头输入、任务、验收与技能由作者围绕教学重新组织。

产品操作来源包括[首次任务](https://www.workbuddy.cn/docs/workbuddy/FirstTask)、[任务栏](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Task-Bar)、[技能](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Skills-Market)、[连接器](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Connector)、[专家](https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Expert-Center)、[自动化](https://www.codebuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Automation-Guide)。菜单、可用模型、额度和支持范围可能变化，以当前页面与账户实际状态为准。

格式与协议分别参照 [Agent Skills 规范](https://agentskills.io/specification)和 [MCP 概览](https://modelcontextprotocol.io/docs/getting-started/intro)。[WorkBuddy 开放平台技能要求](https://open.workbuddy.cn/docs/skill)涉及市场开发，不能与本地教学使用混同。

#### 怎样理解“验证过”

官方说明确认入口与功能描述；本地结构检查确认文件、链接和压缩包；真实运行记录说明某个宿主对指定教学输入做了什么；人工语义核对确认关键事实。它们证明的范围不同。

本书不提供未经测量的效率提升比例、客户人数、成交效果或跨平台兼容保证。未实际接入的外部服务、未导入验证的客户端能力和未创建的定时任务，均不能借教程存在而宣称已完成。

具体运行环境、产物、检查与限制集中放在[运行记录](练习包/运行记录/README.md)。换工具、模型、输入或技能版本后，请按相同标准重新检查。

