我一直在使用代码智能体（克劳德代码、柯瑟），并撞上了一堵众所周知的墙：氛围编程——描述任务并让人工智能生成代码——这种模式难以扩展。它在前三次修改中还奏效，但之后没人还记得最初的意图是什么。代码成了唯一的真实来源，而它在解释为什么要做某事方面表现糟糕。
就在这时，我接触到了规格驱动开发（SDD）：将规格说明放在代码之前。在实践中，“规格”是仓库中版本化的 Markdown 文件——包含需求与验收标准——人工智能在生成任何代码行之前都会先阅读它。它成为主要产物，而不是躺在文件夹里腐烂的文档。
我得出的论点是：使用人工智能编程的瓶颈不再是“人工智能能写出好代码吗？”。现在是“人工智能理解我真正想要的是什么吗？”。规格说明正是填补这一空白的关键。
有三件事让我开始认真对待这种方法：
-
这不是瀑布模型。规格说明是活的——你在短周期中运行四个阶段：指定 → 计划 → 任务 → 实现（在诸如规格工具包这样的工具中，它们变成命令：
/speckit.specify、/speckit.plan……）。这更接近测试驱动开发，而非瀑布式开发。 - 规格说明引导智能体。人工智能不再依赖松散的提示词，而是阅读规格说明和计划。在我的使用中，错误更少了——并且让我在审查四百行差异之前，先审查意图。
-
已经有真正的工具可用。规格工具包（吉特哈布）、基罗（亚马逊云科技）、泰斯尔、开放规格——全部开源。而且起步并不需要太多：在仓库根目录下一个简单的
CLAUDE.md（或AGENTS.md）文件，就已经是一种应用该理念的轻量级方式。
这并不是银弹。对于五十行的脚本来说，这是额外的负担。其优势体现在需要维护的代码、团队协作中，或者当你大量委托给自主智能体时。
我写了一份更深入的指南，详细介绍了这四个阶段，对比了规格工具包 vs 基罗 vs 泰斯尔 vs 开放规格（如何选择），以及使用克劳德代码实践规格驱动开发的逐步教程：techknow.com.br/post/spec-driven-development
这里有多少人已经在人工智能工作流中使用规格说明作为真实来源？我很想知道大家选择了哪种工具——以及在哪里遇到了阻碍。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
