原文：《让AI变成Super员工的秘密：高效训练Skills》，作者 solonnliu，来源：腾讯技术工程公众号
不是 AI 不够强，而是大多数 AI 还没有被你训练成”懂业务、会自检、能稳定交付”的员工。
目录
核心结论先行
把 AI 训成 S 级员工，作者最信这 4 件事：
- AI 的上下文一定有限。任务一复杂，它就会健忘。
- Skill 里不能只写”想要什么”，还要写”具体怎么做”。
- 光写清楚还不够。 上下文一撑爆，AI 会自动忽略细节，所以一定要配可校验、可自测的 checklist 和门禁规则。
- Skill 不是一次写成的。 最有效的方法永远是：跑一遍、复盘一次、让 AI 分析原因并自动改 Skill，再跑一遍，循环迭代。
一句话总结：
Skill 的作用，不是让 AI 更聪明，而是让 AI 在你的业务里更可靠。
一、为什么 AI 很强，还是当不了 S 级员工？
大模型拥有的是通用能力，不是岗位能力。
| 通用能力 | 岗位能力 |
|---|---|
| 能不能理解任务 | 你这个业务里什么才算真正完成 |
| 能不能大致做出来 | 哪些步骤绝对不能跳 |
| 能不能输出”像样的结果” | 哪些细节最容易被漏掉 |
| 哪些错误过去已经真实发生过 | |
| 最终交付物应该长什么样，谁来消费，怎么验收 |
AI 特别像一个非常聪明的新同学：它能读懂你说的话，但它不知道你们团队的”行规”、“教训”和”交付标准”。
Skills 做的事，就是把这些原本散落在你脑子里、团队经验里、事故教训里的内容，变成 AI 可以执行的岗位 SOP。
模型提供通用智力，Skill 提供业务操作系统。
二、训练 Skill 的前提：承认”AI 会失忆”
这是整个训练体系的底层假设，也是最容易被忽视的一点。
现实是：
- 任务一长，前面的约束会被稀释
- 阶段一多，后面的细节会被忽略
- 输出一复杂，AI 会主动压缩结构
- 上下文接近极限时，模型会优先保”看起来完成”，而不是保”严格完整”
所以，复杂任务不是”写清楚一次”就结束了，而是必须被设计成”每一步都能自我校验”的流程。
Skill 训练闭环
真实任务执行
↓
发现问题/翻车
↓
把错误写成规则，把经验写成 SOP，把 SOP 写成 AI 自己也能检查的门禁
↓
更新 Skill
↓
再次执行验证
↓（循环）图里最关键的不是”再次执行”，而是中间那一步：把错误写成规则，把经验写成 SOP，把 SOP 写成 AI 自己也能检查的门禁。
三、4 个真实翻车教训（web-testing Skill 实战复盘）
作者以打造一个 web-testing Skill 为案例，目标是：给它任意一个网站链接，它都能深入完整地探索每一层页面，并输出完整测试报告（含总评分、站点地图、UI/UX 审查、CURD 全链路测试、截图等）。
🚧 第一坑：AI 不是不会点页面，而是不知道”哪些地方必须点”
问题复现：
AI 在页面发现阶段漏掉了一个隐藏入口：/admin/product/deployment/{deploymentId}
这个页面藏在：版本详情页的某个 Tab → Tab 内容区的表格 → 一个蓝色链接后面。
AI 的策略是：
- 识别到了 Tab ✓
- 知道有部署方案这个区域 ✓
- 也看到了蓝色链接 ✓
- 但没有把它当成”必须递归验证的新页面入口” ✗
结果：它不是完全没探索，而是探索到一半，靠主观判断停下来了。
根因分析：
Web 测试的难点，很多时候不在”有没有能力点击”，而在”知不知道哪些交互必须被系统性穷举”。
修复方案：
把”仔细”拆成可执行动作：
| 原来（模糊要求） | 修复后（可执行 SOP） |
|---|---|
| 请认真检查页面，不要遗漏入口 | 页面必须滚动到底再结束扫描 |
| Tab 切换后必须重新扫描链接 | |
| 展开行里的链接必须实际点击验证 | |
| 不能靠颜色或视觉主观判断链接是否重要 | |
| 阶段结束前必须做递归终止自检 |
Skill 里不能写：
请认真检查页面，不要遗漏入口。而要写成：
当页面存在 Tab、展开行、子表格、蓝色链接时，必须执行 DOM 枚举与逐链接验证；
只要还存在未验证链接，就禁止结束阶段 1。核心原则：不要写原则，要写触发条件 + 必做动作 + 结束门槛。
效果： 优化前只识别到 2 层页面；优化后识别到 4 层页面，并标注了页面类型（只读/可 CURD）。
AI 不是天然会”穷举”的。穷举能力，很多时候要靠 Skill 强行教出来。
🚧 第二坑：AI 会优先做”最像成果的那个”，然后漏掉其他交付物
问题复现：
阶段 4 要求输出三个文件：sitemap.md、test-report.md、test-report.html
结果 AI 只生成了 HTML。
根因分析：
HTML 最像”最终成果”——最显眼、最复杂，最容易吸走模型的注意力和上下文预算。AI 的”心理活动”：
- 先把最复杂的做了
- 做着做着上下文变紧张了
- 后面两个相对”朴素”的产物被自动忽略
不是故意偷懒，而是本能地优先做那个最有存在感的东西。
修复方案：
直接把顺序写死，并配上门禁：
1. 先生成 sitemap.md → 立刻验证文件存在且大小 > 0
2. 再生成 test-report.md → 立刻验证文件存在且大小 > 0
3. 最后生成 test-report.html → 立刻验证文件存在且大小 > 0
4. 阶段结束做阻断式完整性检查，不通过就不能宣布完成复杂任务里，顺序本身就是质量控制。
🚧 第三坑：不要假设 AI 懂工程约束，它经常会选”看起来最省事”的方案
问题复现：
AI 为了生成带截图的 HTML 报告，走了一条”看起来聪明”的捷径：
- 用
python3 -c直接拼长脚本 - 把截图数据做成 base64
- 一起塞进命令行
结果：Shell 命令长度上限被打爆，整条命令失败。
根因分析：
模型并不天然具备你当前执行环境里的工程常识。
它可能”知道有这种写法”，但不知道这在你的环境里是否稳定、是否可维护、是否会炸。
修复方案：
明确写入工程约束：
禁止用 python3 -c 生成长报告
禁止用超长 echo "..." > file 硬写大文件
优先直接写文件，或者先写脚本文件再执行
HTML 报告禁止 base64 内嵌截图，统一改成本地路径引用Skill 不只是业务手册，它还得是 AI 的”工程生存指南”。
🚧 第四坑：最危险的不是”没生成”，而是”看起来生成了”
问题复现：
表面上报告是有的，甚至有问题列表、CRUD 结果、结论。但一对模板才发现：真正关键的”逐页面详细模块”被悄悄压缩掉了。
少了什么：
- 每个页面独立模块
- UI/UX 审查
- 功能测试明细
- 本页问题汇总
- HTML 的 page-card 结构
根因分析：
前面测试过程已经消耗了大量上下文，到了最后生成报告时，AI 自动进入”节约模式”，开始压缩结构。
这类错误最危险，因为它不是”完全没有”，而是”看上去像有”——最容易骗过第一次验收。
修复方案：
补上结构门禁（示例 checklist）：
报告结构完整性 checklist：
- [ ] 页面模块数 = sitemap 页面数
- [ ] 每页都有截图
- [ ] 每页都有 UI/UX 审查
- [ ] 每页都有功能测试结果表
- [ ] 每页都有本页问题汇总
- [ ] HTML 中 page-card 数量 = 页面数
- [ ] 问题汇总表存在
- [ ] 修复计划表存在
- [ ] 数据清理记录存在关键不是 checklist 写得多漂亮，而是它要变成门禁：
上一项没过，下一项不能开始；最终结构没过，整个阶段不能宣告完成。
复杂任务如果没有门禁，AI 很容易从”完整交付”滑向”看起来完成”。
四、一套可复用的 Skill 训练方法论
方法 1：先让 AI 在真实任务里跑起来，再谈训练
别一上来就闭门写一大坨 Skill。先让 AI 真做 3～5 次真实任务，重点不是看它多惊艳，而是看它怎么错：
- 漏了什么
- 跳了哪一步
- 哪些地方看起来做了，其实没做
- 哪些错误会重复出现
没有真实翻车，就很难写出真的有用的 Skill。
方法 2：Skill 里不止要写”做什么”，还要写”怎么做”
| 坏写法（提要求） | 好写法（写 SOP） |
|---|---|
| 请仔细检查页面 | 当页面存在 Tab/展开行/子表格时，切换后必须重新枚举链接 |
| 请保证报告完整 | 每生成一个交付物，立刻验证文件存在且大小大于 0 |
| 请在结束前自查 | 页面模块数必须等于站点地图页面数，否则报告不合格 |
前者是在提要求，后者是在写 SOP。而 Skill 要的，恰恰是 SOP。
方法 3：只写清楚还不够，一定要给 AI 配 checklist 和门禁
上下文一长，AI 会自动：
- 压缩不那么显眼的步骤
- 忽略长尾细节
- 优先保住”看起来像成果”的部分
- 把”差不多完成”当成”已经完成”
所以 Skill 里必须有两层东西：
- checklist：告诉 AI 要检查什么
- 门禁：告诉 AI 没检查过就不能往下走
这一步特别像带新人：你不能只告诉他”注意质量”。你得告诉他：
- 先做什么
- 做到什么算完成
- 怎么验收
- 不通过怎么办
方法 4：效果不好时，让 AI 参与复盘并自动改 Skill
低效的调优方式：
跑一遍 → 觉得不满意 → 自己手改 Prompt → 再跑一遍高效的调优方式：
跑一遍 → 指出不理想的地方 → 让 AI 分析根因 → 让 AI 提出修改 Skill 的方案
→ 让 AI 自动完善 Skill → 再跑一遍验证 → 重复闭环AI 不只是执行者，还应该成为 Skill 的共同调参者。
推荐使用这类迭代指令：
请基于本次执行结果，对当前 Skill 做一次复盘：
1. 哪些输出没有达到预期？
2. 这些问题分别属于：页面发现、交付完整性、工程约束、结构完整性、消费场景适配中的哪一类？
3. 根因是什么？是规则缺失、规则不明确、没有门禁，还是上下文过长导致细节被忽略？
4. 请给出应补充到 Skill 中的具体规则，要求包含：触发条件、必做动作、自检方式、不通过后果。
5. 直接输出修改后的 Skill 片段，并说明这次修改预期解决什么问题。Skill 一旦进入这个循环，就会越来越像一个真正会吸收经验的业务系统，而不只是一个长 Prompt。
五、web-testing Skill 的文件结构
web-testing/
├── SKILL.md # 主控文件：触发条件、执行流程、门禁规则、失败模式
└── references/
├── checklist-template.md # 执行过程的"进度控制器"和"阶段门禁表"
├── report-template.md # 最终 Markdown/HTML 报告的输出契约
└── ui-ux-checklist.md # UI/UX 审查时的详细评分参考标准通过主 SKILL.md + checklist 的形式，确保了 AI 在执行过程中不健忘，按照期望交付成果。
六、训练 Skill 的本质：抬高下限，而非上限
很多人讨论 AI 时关注上限：模型够不够聪明、推理强不强、会不会写代码。
但真到了业务里，决定体验的往往不是上限，而是下限。
你最怕的不是 AI 偶尔不够惊艳，最怕的是它：
- 这次做得很好，下次突然漏半页
- 这次三份文件都有，下次只交一份
- 这次结构完整，下次悄悄缩水
Skill 真正解决的是：让 AI 的交付质量从”靠状态”变成”靠机制”。
训练 Skill，本质上不是增强 AI 的天赋，而是在建立 AI 的职业素养。
总结
训练 Skill 的完整心法：
1. 先跑，不要先写
└── 让 AI 真做任务，从翻车里找规律
2. 写 SOP，不要写要求
└── 触发条件 + 必做动作 + 结束门槛
3. 加门禁，不要靠自觉
└── checklist + 阶段门禁 = 结构质量保障
4. 让 AI 参与复盘，自动迭代 Skill
└── AI 是执行者，也是调参者最后一句话：
要让 AI 先去干活，允许它犯错，把错复盘出来，把经验写回 Skill，然后再让它继续干。反复几轮之后，它就会慢慢从”能干活”，进化成”能把活干好”。而这，才是 AI 真正变成 S 级员工的开始。