文章核心观点是：足够详细的规范本质上就是代码，那些声称能直接从规范生成代码的主张存在误导性。作者指出这种观点源于两个误解：一是误以为规范比代码简单，二是忽视了规范与代码之间的转换仍需人工介入。

详细到极致的规范就是代码

本文通过分析OpenAI的Symphony项目，揭示了"通过规范文档生成代码"这一理念存在的根本问题。

核心观点

1. 规范文档与代码的界限模糊
   Symphony项目的SPEC.md文件本质上就是伪代码的Markdown版本，包含了：

   • 数据库架构的详细描述
   • 算法逻辑的直接描述
   • 明确的代码片段
   • 专门为AI代码生成设计的"速查表"

2. 两大认知误区
   支持者基于两个错误假设：

   • 误区一：规范文档比对应代码更简单
   • 误区二：规范工作比编码工作更需要深思熟虑

3. 实际验证失败
   作者尝试用Haskell实现Symphony规范时发现：

   • 需要多次修正AI生成的代码
   • 即使没有报错，核心功能也无法正常工作
   • 类似问题也存在于YAML等成熟规范中

深层问题

1. 精确性悖论
   要使规范足够精确以生成可靠代码，它必然会变成代码或类代码的形式——正如Dijkstra所言，工程劳动需要"狭窄接口"（即代码）的精确性。

2. 规范膨胀风险
   Symphony规范已经是实现代码的1/6大小，继续增加细节将陷入"精确制图寓言"的困境——地图最终变得与实际领土一样大而失去实用价值。

3. 质量滑坡
   当前行业追求交付速度而非质量的风气，导致规范文档沦为"AI生成的表面文章"，缺乏真正的连贯性和深层思考。

结论

规范文档从来不是节省时间的工具。在"垃圾进，垃圾出"的原则下，如果输入的规范本身缺乏清晰度和细节，编码代理也无法可靠地填补这些空缺。真正的解决方案是： - 接受编码工作需要精确性的本质 - 不要试图用规范文档替代编码工作 - 重视工程实践中的深度思考而非表面效率

（注：本文保留了原作者的Haskell实现案例、Dijkstra引述等关键论据，删减了部分重复论证和博客特有的格式说明）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持"详细规范即代码"的观点

1. 规范定义行为边界

   • "Specifications are not really code but a good specification will cut out a definable subset of expected behaviors" (评论1)
   • "Once you remove all ambiguous information from an informal spec... automatically becomes a formal description" (评论12)

2. 规范与实现分离

   • "The C++ standards... won't allow for logic that is dependent on the implementer" (评论2)
   • "A given sin() is either correct or it's not. Yet sin() can have many implementations" (评论20)

反对"规范即代码"的观点

1. AI可填补规范空白

   • "AI agents can figure out unspecified parts of the spec on their own" (评论4)
   • "When one prompts an AI... what they really mean is 'write me something better than I imagined'" (评论9)

2. 规范与代码本质不同

   • "Natural language is fluid while code is rigid. Spec-driven development is the worst of both" (评论16)
   • "Code without a spec is undefined behavior" (评论14)

中间立场/其他观点

1. 技术语言演进论

   • "People will create technical dialects (LLMSpeak) to reduce ambiguity" (评论5)
   • "LLMs are better at Python/SQL than Haskell because syntax mirrors human language" (评论7)

2. 开发实践差异

   • "The-spec-as-management-artifact vs the-spec-as-engineering-artifact" (评论18)
   • "Software devs don't know what real planning is" (评论22)

3. 极端观点

   • "I only write assembly. Imagine software deciding register spill for you!" (评论11)
   • "Absolute nonsense. A sufficiently detailed 'spec' is the code" (评论15)

关键分歧点在于：规范是否应达到代码级的精确度，以及AI是否改变了传统规范的作用。支持者强调规范的定义功能，反对者则认为规范与代码存在本质差异，而AI的出现使得严格规范的必要性降低。