夜雨聆风因为搭 Agent 是容易的——你可以在一个下午攒出十几个 Agent，给每个 Agent 起个名字、写段系统 Prompt、挂几个工具，看起来一片繁荣。但 Skill 不一样。你很难在一个下午写出一个稳定、可复用、经得起生产考验的 Skill。
两者的难度完全不在一个层级。
---
我先说一个真实的场景。
朋友的团队上个月做了一件事：把他们积累的二十几个"好用的 Prompt"整理成文件，放进仓库，统一命名，叫 skill-xxx.md。然后在团队群里宣布：我们有 Skill 体系了。
两周后他跟我吐槽。同一个 Skill，两个工程师用出来的结果完全不一样。有人拿它生成的代码直接能跑，有人生成出来全是幻觉。更要命的是，Skill 里引用的编码规范改了一版，但 Skill 文件没人更新，新来的同事照着旧 Skill 写了三天代码，全部返工。
他问我：是不是我们的 Prompt 写得还不够好？
不是 Prompt 的问题。
是他们写的根本不是 Skill，而是"长期 Prompt"。
---
你可能觉得，Prompt 和 Skill 有什么本质区别？不都是一段文字告诉 AI 该干什么吗？
我以前也这么想。直到我开始在生产系统里真正维护 Skill，才意识到两者的差距就像一张操作说明和一个完整工位之间的差距。
Prompt 是说明书。它告诉 AI"做什么"。但一个真正的 Skill，不只是说明书——它是一个完整的能力单元，包含规则、上下文和工具。
一句话定义：Skill 等于能力单元加规则加上下文加工具。
Prompt 只管指令，Skill 管整个工位。
---
拆开来看，一个 Skill 的最小结构需要四样东西。
第一样是指令文件，相当于大脑。它定义流程——做什么、怎么做、输出什么格式、遇到异常怎么处理。这是大多数人唯一会写的部分，也是他们误以为写完就算有 Skill 的原因。
第二样是触发规则，相当于入口。它定义什么时候使用这个 Skill——是用户说了某个关键词，还是代码变更触发了某个事件，还是流程走到了某个节点。没有触发规则的 Skill，就像一把没有扳机的枪，威力再大也没法启动。
第三样是参考资料，相当于经验库。编码规范、架构约定、历史案例、团队偏好——这些不是写在 Prompt 里的，而是 Skill 执行时能够按需查阅的外部知识。我朋友团队踩的坑，就是因为经验库和 Skill 脱节了。规范改了，Skill 不知道。
第四样是工具能力，相当于手脚。读代码、跑测试、调接口、查日志——Skill 不是只能输出文字，它需要能操作真实环境。没有工具的 Skill，就像一个只会说不会做的顾问，建议再精准也无法落地。
这四样东西，缺任何一样，都不是完整的 Skill。只有指令没有工具，是纸上谈兵；只有工具没有规则，是蛮力乱干；只有规则没有上下文，是刻舟求剑。
---
但光有结构还不够。一个 Skill 要真正在生产环境里跑起来，必须解决一个关键问题——上下文爆炸。
举个具体场景。假设你有 30 个 Skill，每个 Skill 的指令文件加参考资料加工具描述，平均 2000 token。如果每次执行都把所有 Skill 全量加载，光 Skill 本身就吃掉 6 万 token 的上下文窗口。模型还没开始干活，窗口就满了一半。
这在玩具项目里不是问题，但在生产系统里是致命的。
解法是按需加载——技术上叫 Progressive Disclosure。
启动的时候，只加载 Skill 的元信息：名字、描述、触发条件。几十个 Skill 加起来可能也就几百 token。等到真正触发了某个 Skill，再加载它的完整指令。执行过程中需要参考资料或调用工具，再按需拉取。
这个思路不复杂，但它决定了 Skill 体系能不能规模化。不做按需加载，你的系统永远只能挂十几个 Skill；做了按需加载，挂一百个也不会压垮上下文。
---
说到这里，可能有人会问：Skill 和 Workflow 是什么关系？听起来 Workflow 也能做这些事。
它们的确有交集，但本质逻辑不同。
Workflow 是固定流程、强约束。第一步做什么，第二步做什么，分支条件是什么，全部预定义好。它的优势是确定性强，适合高频、标准化的操作。它的劣势也在这里——一旦遇到预定义之外的情况，要么报错，要么走兜底，不会自己想办法。
Skill 是动态执行、模型驱动。它有指令和规则，但具体怎么组合、什么顺序、怎么处理异常，是模型在运行时根据上下文决定的。它的灵活性远高于 Workflow，但对 Skill 的设计质量要求也更高——写得不好，模型就会乱来。
最好的结构不是二选一，而是两者配合。
Workflow 做骨架，Skill 做执行。Workflow 负责"先做 A 再做 B，B 完成后触发 C"，每个节点里具体怎么做，交给 Skill。流程的确定性由 Workflow 保证，执行的灵活性由 Skill 提供。
---
那是不是所有业务都适合 Skill 化？
不是。
Skill 化有成本——设计成本、维护成本、测试成本。只有同时满足三个条件的场景，才值得投入。
高频：这件事每周甚至每天都在做。如果一个月才做一次，手动跑一遍比维护一个 Skill 划算。
可复用：不同的人、不同的项目、不同的上下文，都需要做这件事。如果只有一个人在一个项目里做一次，写个 Prompt 就够了。
有标准：这件事有明确的输入输出格式、有可检验的质量标准。如果输出好坏全凭主观判断，Skill 的效果就很难稳定。
代码审查、技术评审、测试生成、周报撰写——这些场景天然符合。它们高频、跨项目复用、有明确的质量基线。
反过来，架构决策、技术选型、团队沟通——这些高度依赖上下文和判断力的事情，Skill 可以辅助，但不应该主导。
---
回到最开始那个问题：Skill 到底怎么写？
到这里你应该已经看出来了——"怎么写"不是一个 Prompt 技巧问题，而是一个工程设计问题。
指令写得再漂亮，没有触发规则就无法自动启动；触发规则设得再精准，没有参考资料就会跟团队实践脱节；参考资料挂得再全，没有工具就只能输出建议不能真正执行。
一个 Skill 经不经得起生产考验，取决于四个组件是否完整、是否协同、是否可维护。
---
这段时间围绕 Skill 的实践，让我认清了几件事。
第一，AI 能不能真正干活，不取决于模型有多聪明，而取决于你给它什么工位。同一个模型，给一句 Prompt 和给一个完整 Skill，产出质量可以差三到五倍。
第二，Skill 不是提示词优化，而是工程能力的封装。写 Prompt 是文案活，写 Skill 是架构活。能写好 Skill 的人，往往也是能做好系统设计的人。
第三，Skill 体系的扩展性取决于按需加载的设计。上下文窗口是硬约束，不解决加载策略，Skill 数量永远过不了两位数。
下一篇我会写：AI Coding 不是写代码，而是一个执行系统。当 AI 从"补全工具"变成"执行主体"，整个编码流程的组织方式都需要重新设计。
如果你的团队也在尝试让 AI 从聊天窗口走进生产系统，这些问题迟早会摆到桌面上。与其到时候踩坑返工，不如现在就把工位搭对——转发给你在做 AI 工程化的朋友，这些弯路不必每个人都走一遍。
