当我开始让克劳德代码构建新的网络工具时，我交给它的是抽象规范：设计约定、组件规则、禁止模式。它会阅读规范，生成看似合理的内容，但质量停留在 80%。剩下的 20% 需要多轮修正。在重复了几十次之后，我从零开始重建了技能架构。
开门见山的结论是：停止让智能体阅读规范——让它复制一个已部署在生产环境中的实时参考实例。并将“构建新工具”和“修复现有工具”拆分为完全独立的技能。这是基于管理包含 600 个工具的设备集群所得出的两个设计决策。
1. 参考驱动：从“阅读规范并构建”转变为“复制可运行的工件并进行修改”
规范的问题在于，从你写下它们的那一刻起，它们就开始与现实脱节。在实现过程中做出的每一个细微判断——比如这个模式使用这种内边距，那个情况是个例外——从未被写回规范中。这是不可持续的。因此，人工智能每次都会以自己的方式填补这些未书面化的判断，且每次的方式都不同。
另一方面，生产代码已经融入了所有这些判断。所以我重构了技能：
技能文件本身只是一个薄封装层；实质内容存在于目录（权威文档）中。目录以决策树开篇——通过三个问题来选择实现模式（直接画布二维绘图 / html2canvas / dom-to-image / 专用库 / 纯可缩放矢量图形）。对于选定的模式，从目录列表中选取两个生产参考实例并阅读它们：一个作为基础，另一个用于差异对比。目录中的每一行都记录了行号——下载处理程序的位置、渲染核心的位置。然后完整复制基础参考实例，并针对新工具的数据结构进行修改。
首次输出的质量从“80% 加上多轮修正”提升到了基本达到生产级别的质量。
规范会腐化；只要生产代码一直在运行，它在相当长的时间内就不会腐化。
一个额外的好处是：目录记录了收敛趋势。我为图像输出工具尝试了五种实现模式；大多数生产环境最终选择了直接画布二维绘图。只有因为存在这种收敛数据，才能写出“如有疑问，首选画布二维绘图”这样简洁的规则。
2. 将构建技能与修复技能分离
第二个决策：新建工具和修复现有工具分别属于不同的技能。同属一个领域——为什么要拆分？
| 构建（新建） | 修复（现有） | |
|---|---|---|
| 输入 | 新工具的需求 | 报告的错误 / 验证器标记 |
| 输出 | 完整的新模板 | 针对症状的精准修复 |
| 验证深度 | 完整检查清单 | 仅限症状周围范围 |
如果将它们合并为一个技能，会发生两件坏事：构建过程会积累仅用于修复的分支并变得臃肿，而修复参考资料会被构建步骤稀释。无论哪种情况，你都在让智能体在每次阅读时支付“跳过无关部分”的税。智能体的上下文是有限的；这种税直接从输出质量中扣除。
修复端变成了一个“母舰”：它接收一个症状，将其路由到一个类别（布局损坏 / 图像输出保真度 / 翻译质量 / 按钮约定 / 描述与实现漂移 / 交互），并仅打开该类别的参考资料。未构建的类别是指向权威源的空存根——因此智能体无法幻觉出不存在的流程。
3. 技能是参考资料。强制执行属于钩子
最后一个界限。技能（流程文档）仅是建议性的——它没有强制执行力。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
