从 Prompt 到 Skill Engineering：AI 能力为什么需要工程化

从 Prompt 到 Skill Engineering：AI 能力为什么需要工程化

先看一段很常见的 Prompt：

第一次用，多半还行。

第二次发现它不知道项目规范，于是把规范贴进去。第三次发现它审错了范围，又补一句“只看当前分支与 main 的差异”。后来还得告诉它哪些目录不要碰、结论必须带代码位置、没有证据不要报问题。

Prompt 就这么越写越长。

再往后，它需要自己读取 Git diff、查仓库里的规范文件、运行测试。检测到安全问题时只能报告，不能直接改；遇到无法确定的基线要停下来问人；规则更新以后，旧案例还得重新跑一遍。

到了这一步，我们维护的还是 Prompt 吗？

文件形式也许还是 Markdown，里面装的东西已经很像一个软件模块：有输入，有依赖，有执行顺序，有权限边界，也有验收办法。继续把它当成“提示词技巧”，后面的维护会越来越别扭。

一、Prompt 越写越长，只是表面问题

长 Prompt 不一定差。复杂任务本来就需要更多上下文。麻烦在于，一段文本开始同时承担几种不同责任，而且这些责任彼此牵连。

还是前面的代码审查：

• “只检查本次 diff”是在限定输入范围；
• “先读取仓库规范”是在声明依赖；
• “高风险问题必须给出证据”是在规定验收条件；
• “不要直接修改代码”是在控制副作用；
• “找不到比较基线就询问用户”是在处理失败分支。

它们挤在同一个 Prompt 里，模型能不能理解是一回事，人能不能长期维护是另一回事。

删掉一句规则，会影响哪些场景？换了项目，哪些内容需要替换？工具执行失败以后，后续步骤还应不应该继续？修改完成，拿什么证明旧能力没有退化？

单次对话不需要回答这些问题。准备复用和交付，就绕不开了。

这也是 Prompt Engineering 与 Skill Engineering 的分水岭。前者关心怎样把当前意图说清楚；后者开始接手一项能力的完整维护责任。

二、Skill 只是把藏起来的责任摆到明面上

不同平台对 Skill 有不同的文件格式和加载方式，这些先放一边。格式会变，工程责任不会。

在这个系列里，我更愿意把 Skill 理解成一项有名字、有边界的 Agent 能力。它至少要让维护者看清几件事：

• 用户给了什么，什么情况下应该启动；
• 执行时依赖哪些知识、文件和工具；
• 哪些判断交给模型，哪些步骤交给代码；
• 哪些操作会产生副作用，谁有权确认；
• 什么算完成，失败时停在哪里；
• 修改之后，怎样检查原来的行为。

这份清单没有多少新概念。写过后端服务的人，可以把它看成接口、依赖、流程、权限和测试；做过前端组件的人，也会关心 props、状态、副作用和回归。Agent 换了一套运行环境，并没有获得免做工程设计的特权。

Skill 的作用，就是给这些责任一个明确的容器。

Prompt 仍然在里面。它负责告诉模型如何判断、如何表达。项目规范可以放进参考资料，固定格式交给模板，机械检查交给脚本，读文件和写系统通过工具完成。执行顺序、暂停条件和失败处理则由工作流程约束。

所以，Skill 并不神秘。它只是拒绝再让一段 Prompt 假装自己能包办所有事情。

三、几个容易混在一起的东西

Prompt、工具、Skill 和 Agent 应用经常被混用，因为用户看到的入口可能都是一句自然语言。对开发者来说，区分它们最省事的办法，是看各自负责哪一层。

对象	主要负责	一个简单例子	留给上一层处理的事
Prompt	描述当前任务和判断要求	“检查这段代码里的并发问题”	依赖管理、完整流程、回归测试
工具	完成一个具体动作	读取 diff、运行测试、提交评论	为什么调用、何时停止、结果怎么判断
Skill	封装一项可复用能力	按仓库规范完成一次代码审查	产品交互、跨能力编排、长期业务状态
Agent 应用	交付完整任务体验	研发助手、客服系统、内容工作台	具体能力可以继续下沉给 Skill 和工具

它们没有替代关系。

一个 Skill 里面通常会有 Prompt，也可能调用多个工具。一个 Agent 应用可以根据任务选择不同 Skill。至于普通代码，该写还得写：输入输出确定、规则明确的工作，交给代码往往更便宜，也更稳。

把 Skill 放在中间这一层很重要。做得太薄，它只是换了文件名的 Prompt；做得太厚，它又会吞掉界面、业务状态和一堆无关能力，最后长成一个没人敢动的“大 Skill”。

四、判断有没有工程化，只看一件事

不要先看目录里有没有 SKILL.md，也不要数拆了多少个文件。问一个开发者更熟悉的问题：

改完以后，你敢不敢发？

敢发，通常意味着几件具体的事：

• 知道这次改动落在哪项责任上；
• 知道哪些调用场景可能受影响；
• 手里有几个能重跑的输入样例；
• 能检查关键约束有没有失效；
• 出问题时能定位到指令、资料、脚本、工具还是流程。

这些条件不要求一步到位。刚开始，一个 Skill 可能只有清楚的职责说明和几条测试样例。等任务变复杂，再加入参考资料、脚本和更严格的流程。工程结构应该跟着真实问题长，没必要先造一座空城。

反过来，一份几千行的“超级提示词”，哪怕偶尔表现很好，只要没人说得清改动影响，也没有办法回归验证，它就很难成为可维护的能力。

Skill Engineering 的起点不是某种文件格式，而是承认 Agent 能力也要进入软件生命周期：需求会变，依赖会变，行为会退化，版本之间需要解释，修改之后需要证据。

至于什么样的需求值得付出这套成本，下一篇再具体讨论。临时任务用 Prompt 很舒服，确定性任务可能一段代码就够了。别因为手里有锤子，看什么都像 Skill。