用开发驱动规范，而非规范驱动开发
I Use Development-Driven Specs, Not Spec-Driven Development
Bill Cox 在 Ensemble 项目中提出了一种全新的开发理念：不要预先撰写详尽的规范再交给 AI，也不要先写代码后补文档。真正的做法是与 AI 结对编程，在实时调试、纠正错误和记录决策的过程中，将专家经验转化为可执行的规范。这种方法生成的不仅是代码，更是包含构建逻辑、权衡取舍和深层知识的“可执行说明书”。通过这种方式，人类专家在开发过程中不断成长，而不仅仅是依赖对陌生生成代码的最终审查。Ensemble V3 正是由 V2 执行这本书构建而成，完美诠释了“开发赢得规范”的核心理念。
不要只记录要构建什么，而要教授如何以及为何以这种方式构建；你无法在开端就掌握所有知识。
HN 评论区
26- dromologist
我的日常工作涉及一个非常老旧的框架，我发现要想达到最佳效果，往往需要在 agent 上堆砌各种技能、额外工具等等，以至于到了这一步，它已经变成了一个专门为这个项目定制的 harness。
虽然这是出于无奈的结果，但我认为让 harness 贴合你特定的开发体验是非常有帮助的，就像一个装满了你所需特定插件的 IDE——只不过它不是 IDE，因为 IDE 已经过时了。
- WaywardGeek
这会生成一份可执行的规范：把它交给 Ensemble 这样的 AI 编程 agent，它就能自主执行该规范，生成代码的新版本。当我通过执行《构建 AI 编程 Agent 的艺术》来创建 Ensemble 的新版本时，这套方法完美奏效。我从未见过比这更成功的规范。
你必须边写代码边构建规范。这两个过程无法分离。我会像往常一样先和 AI 进行前置设计讨论，然后让它只撰写下一章的 TL;DR（太长不看版）和练习题部分。之后，我会与 AI 结对编程来实现它，遵循 TL;DR，并在过程中撰写笔记以澄清模糊之处，实时引导 AI 朝着我的设计方向前进。
只有当新代码通过了所有练习题的评分器后，我才会让 AI 阅读笔记、voice.md 文件，并撰写章节正文。接着，我会让它启动一个“学生”来测试它是否能仅凭章节内容和评分器就写出代码。
在这个过程结束时，我就是专家，甚至不需要再审查代码。
代码仅仅是执行正确规范的结果。不过是编译器的另一个产物罢了。
别再搞什么“氛围编程”（vibe-coding）了。通过在与 AI 结对编程构建代码的过程中成为专家，然后基于你构建代码的过程来构建规范。不要为了构建而记录代码。要记录过程、吸取的教训以及为何选择这种方式构建。这些无法在事前完成。
如果你不知道如何结对编……
- ozlikethewizard
“一本构建 AI 编程 agent 的书。这个 agent 又构建了下一版。”
真的吗？