Lobsters 97 points
A Sufficiently Detailed Spec is Code
核心观点
两个常见误解：
- 误解1：规范文档比代码简单 → 实际上，要让规范足够精确以可靠生成代码，规范必然会变成代码
- 误解2：规范工作比编码更需思考 → 实际上，当优化交付速度时，规范文档会变成"AI生成的slop"
关键亮点
1. 详细规范 = 代码
作者以 OpenAI 的 Symphony 项目为例，这个项目的 SPEC.md 文件实际上包含：
- 数据库模式的详细 prose dumps
- 类似代码的并发控制算法
- 显式"babysat the model"的配置摘要
- 甚至是伪代码
"当你想让规范文档足够精确以可靠生成可工作的实现时，你必然会把这个文档'扭曲'成代码或强烈类似代码的东西。"
2. Dijkstra 的解释
作者引用了 Dijkstra 关于"narrow interfaces"的观点：
- 跨越接口的通信工作必须被添加
- 接口的改变很容易增加双方的工作量
- 所以现在偏好"窄接口"
3. 不稳定性问题
即使有详细规范，从规范生成代码也不能可靠工作：
- 作者尝试用 Claude Code 按照 SPEC.md 实现 Symphony → 失败
- 即使"成功"（无错误），代码也只是默默空转而不完成任务
- YAML 规范极其详细，但大多数实现仍不完全符合规范
4. Slop 问题
当优化交付速度时，规范文档质量会下降：
- Symphony 规范读起来像"AI生成的slop"
- 缺乏连贯性、目的性或对全局的理解
- 规范文档变成"规格化的句子袋子"
结论
规范从来不是节省时间的工具。如果你优化交付速度，最好直接编写代码而不是通过中间规范文档。
核心原则： "garbage in, garbage out" —— 你无法输入一个缺乏清晰度和细节的文档，然后期望编码代理可靠地填补这些空白。