SkillsAI工具Prompt工程OpenClaw
你有没有这种经历——
认认真真写了一份 Skill，把业务逻辑、注意事项、质量标准全塞进去了，结果 AI 用起来跟没看过一样。它能跑，但跑出来的结果跟你想的完全不是一回事。
我折腾 zhihu-creator 从 v8 到 v10，花了快一个月，每次都是这样：改完一个坑冒出一个新坑，改完两个坑发现根子在别的地方。
直到我读到腾讯工程师 solonnliu 的复盘文章才一拍大腿——他踩的坑我全踩过，而且讲得比我清楚。
这篇文章就是我把他那套方法论，结合我自己写 zhihu-creator 的真实经历，重新整理出来的。
先搞明白一件事：AI 不缺通用智力，缺的是岗位 SOP#
大模型默认拥有的是通用能力 ：
能不能理解任务？能不能大致做出来？能不能输出一个像样的结果？
但你的业务要的不是这些。你的业务要的是：
这个场景里什么才算”完成”？哪些步骤绝对不能跳？交付物长什么样？谁来验收？
这是两个完全不同层级的问题。
很多人第一次用 AI，会被它的”会很多”震住——它能写代码、能做分析、能把报告排版得像模像样。但真正扔进复杂任务里，你才发现它特别像一个非常聪明的新同学：什么都知道一点，但不知道自己这个岗位具体要干什么 。
Skills 在做的事情，就是把散落在你脑子里、团队经验里、事故教训里的那些”岗位要求”，变成 AI 可以执行的 SOP。
换句话说：模型提供通用智力，Skill 提供业务操作系统。
4 个真实翻车：Skill 写不好，不是 Prompt 问题，是格式问题#
翻车 1：把”要求”写成”愿望”，AI 不会按字面意思执行#
场景： 写 web-testing Skill，AI 在页面发现阶段漏掉了一个关键入口——藏在 Tab 里、表格里、蓝色链接后面的那个页面。
我们当时写的 Skill：
请仔细检查页面，不要遗漏任何入口。AI 的理解： “好，我知道了。”
实际情况： 它识别到了 Tab、识别到了蓝色链接，但主观判断 那个链接”看起来不太重要”，于是没点进去。
这不是 AI 不认真，是我们的 Skill 没有把”仔细”拆成可执行动作 。
后来改成这样：
当页面存在 Tab / 展开行 / 子表格 / 蓝色链接时，必须执行 DOM 枚举与逐链接验证；
只要还存在未验证链接，就禁止结束阶段 1；
页面必须滚动到底再结束扫描；
Tab 切换后必须重新扫描链接。这不是在提要求，这是在写 SOP——触发条件 + 必做动作 + 结束门槛 。
我写 zhihu-creator 也踩过同一个坑。有段时间我在 Skill 里写”请确保输出通过审核评分”，结果 AI 每次都输出了评分表但分很低，因为我没写”评分低于 80 分怎么办”。
后来我把规则改成：
评分 < 80 分 → 列出具体扣分项 → 给出修改建议 → 重新生成 → 再评分
直到评分 ≥ 80 且 AI 味扣分 ≤ 20 → 才算完成这才解决了问题。
核心结论： 写 Skill 不能只说”想要什么”，还要写：
- 什么时候触发这个动作（触发条件）
- 具体要做什么（必做动作）
- 做到什么程度才能停（结束门槛）
翻车 2：AI 会优先做”最像成果”的那个，然后漏掉其他交付物#
场景： 输出三份文件：sitemap.md、test-report.md、test-report.html。
结果： AI 只生成了 HTML。
为什么？因为 HTML 最显眼、最复杂、最像”最终成果”。做着做着上下文变紧张了，后面两个相对”朴素”的产物就被自动忽略了。
后来改成这样：
生成顺序固定：
① 先生成 sitemap.md → 立即检查文件存在且大小 > 0
② 再生成 test-report.md → 立即检查文件存在且大小 > 0
③ 最后生成 test-report.html → 立即检查文件存在且大小 > 0
阶段结束做阻断式完整性检查，不通过不能宣告完成。复杂任务里，顺序本身就是质量控制。
我写 zhihu-creator 的审核评分（Step 5），一开始只写了”评分 ≥ 80 才算通过”，没写先评哪些维度、后评哪些维度。加上门禁之后：
评分 → 不达标 → 打回 Step 3 重写 → 重新评分
评分 → 达标 → 才允许进入 Step 6这才把流程锁死。
翻车 3：假设 AI 懂工程约束，它会选”最省事”的方案#
AI 为了生成带截图的报告，用 python3 -c 把截图做成 base64 一起塞进命令行——结果： Shell 命令长度上限打爆，整条命令失败。
这件事说明了一件事：模型并不天然具备你当前执行环境里的工程常识。
后来明确写入 Skill：
禁止用 python3 -c 生成长报告
禁止用超长 echo "..." > file 硬写大文件
HTML 报告禁止 base64 内嵌截图，统一改成本地路径引用
优先直接写文件，或者先写脚本文件再执行Skill 不只是业务手册，它还得是 AI 的工程生存指南 。否则逻辑明明全对，最后死在命令行里。
翻车 4：最危险的不是”没做”，是”看起来做了”#
场景： 测试报告表面看是有的——问题列表、CRUD 结果、结论全在。
但仔细一对发现少了：
- 每个页面的独立模块
- UI/UX 审查
- 功能测试结果表
- page-card 结构
根因：前面消耗了大量上下文，到了最后生成报告时，AI 自动进入”节约模式”，悄悄压缩了结构。
这类错误最危险，因为它不是”完全没有”，而是**“看上去像有”** ——最容易骗过第一次验收。
这次修的核心不是”补内容”，而是补门禁：
报告结构 checklist：
[ ] 页面模块数 = sitemap 页面数
[ ] 每页都有截图
[ ] 每页都有 UI/UX 审查
[ ] HTML 中 page-card 数量 = 页面数
[ ] 问题汇总表存在上一项没过，下一项不能开始。最终结构没过，整个阶段不能宣告完成。
从 4 个坑里，总结出一套真正能用的 Skill 训练方法#
方法 1：先让 AI 在真实任务里跑起来，再谈训练#
不要闭门写 Skill。先让 AI 真做 3～5 次真实任务，看它怎么错：漏了什么？跳了哪一步？哪些地方看起来做了，实际没做？
没有真实翻车，就很难写出真正有用的 Skill。
方法 2：Skill 里不止要写”做什么”，还要写”怎么做”#
坏写法：
请仔细检查页面
请保证报告完整
请在结束前自查好写法：
Tab 切换后必须重新枚举链接
每生成一个交付物，立刻验证文件存在且大小 > 0
页面模块数必须等于站点地图页面数，否则报告不合格前者是在提要求。后者是在写 SOP。而 Skill 要的，恰恰是 SOP。
方法 3：只写清楚还不够，一定要给 AI 配 checklist 和门禁#
复杂任务里，AI 会自动：
压缩不那么显眼的步骤 → 忽略长尾细节 → 优先保住”看起来像成果”的部分 → 把”差不多完成”当成”已经完成”
所以 Skill 里必须有两层东西：
- checklist ：告诉 AI 要检查什么
- 门禁 ：告诉 AI 没检查过就不能往下走
这一步特别像带新人——你不能只告诉他”注意质量”，你得告诉他：先做什么、做到什么算完成、怎么验收、不通过怎么办。
方法 4：让 AI 参与复盘，不要自己硬改#
跑一遍 → 不满意 → 自己手改 → 再跑，这样效率不高。更高效的方式：
请基于本次执行结果，对当前 Skill 做一次复盘：
1. 哪些输出没有达到预期？
2. 根因是什么？是规则缺失、规则不明确、没有门禁，还是上下文过长？
3. 请给出应补充到 Skill 中的具体规则，包含：触发条件、必做动作、自检方式、不通过后果。
4. 直接输出修改后的 Skill 片段。AI 不只是执行者，还应该成为 Skill 的共同调参者。Skill 一旦进入这个循环，就会越来越像一个真正会吸收经验的业务系统。
Skill 训练闭环图#
结论：训练 Skill，不是在抬高上限，是在抬高下限#
很多人提到 AI，总会讨论上限——这个模型够不够聪明、那个模型推理强不强。但真到了业务里，决定体验的往往不是上限，而是下限。
你最怕的不是 AI 偶尔不够惊艳，最怕的是它：这次做得很好，下次突然漏半页。
Skill 真正解决的是：让 AI 的交付质量从”靠状态”变成”靠机制”。
训练 Skill，本质上不是增强 AI 的天赋，而是在建立 AI 的职业素养。
它要知道流程，它要记住教训，它要会自检，它要过门禁，它要稳定交付。这才是一个 S 级员工的样子。
你写过 Skill 吗？踩过哪个坑？评论区说说。