Loading... # 足够详细的规范就是代码 # 一、新闻概述 ## 1. 标题 足够详细的规范就是代码 ## 2. 发布时间 2026 年 3 月 17 日 ## 3. 来源 Haskell for all 技术博客 # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 本文作者以批判的视角分析了"从规范文档生成代码"（agentic coding）的理念，认为这种做法本质上是在重蹈历史覆辙——试图用自然语言替代精确的代码表达。 ### B. 核心亮点 - 指出 agentic coding 宣传的两个常见误解 - 以 OpenAI 的 Symphony 项目为案例，剖析其"规范文档"的本质 - 引用 Dijkstra 的理论，说明精确描述必然演变为代码 - 通过实际测试证明，即使非常详细的规范也无法可靠生成工作代码 ## 2. 关键信息 ### A. 涉及项目 OpenAI Symphony：一个声称从规范文档生成的 agent 编排器 ### B. 核心论点 - 当规范文档足够精确到能可靠生成实现时，它必然扭曲成代码或类似代码的形式 - 规范文档从来不是省时工具，如果追求交付速度，直接写代码更有效 ### C. 技术术语 - Agentic coding：基于 AI agent 的代码生成 - Specification：规范文档 - Narrow interfaces：狭义接口（即代码） ## 3. 背景介绍 ### A. 相关上下文 近年来，业界兴起"从自然语言规范生成代码"的理念，宣传工程师可以转变为编写规范的"管理者"，而由 AI agent 完成编码工作。 ### B. 作者立场 作者对此持反对意见，认为这是对软件工程本质的误解。 # 三、详细报道 ## 1. 主要内容 ### A. 两个常见误解 **误解 1：规范文档比对应代码更简单** Agentic coding 推广者常将此理念卖给相信者，让他们幻想工程师变成管理者，只需编写规范文档后交给 agent 团队执行。这只有在规范工作比实际编码更便宜时才成立。 **误解 2：规范工作必须比编码工作更深思熟虑** 推广者用此观点说服怀疑者，声称通过规范文档过滤工作能提高质量并促进更好的工程实践。 ### B. Symphony 案例分析 OpenAI 的 Symphony 项目被宣传为从规范文档生成项目的范例。其所谓的"规范文档"（SPEC.md）实际上更像 Markdown 形式的伪代码，而非传统意义上的规范。 文档包含： - 数据库 schema 的散文描述：列出字段名、类型、约束 - 代码的散文描述：如并发控制、重试逻辑 - 专门为模型代码生成添加的"速查表"部分 - 完整的算法代码块 示例：服务启动算法 ``` function start_service(): configure_logging() start_observability_outputs() start_workflow_watch(on_change=reload_and_reapply_workflow) state = { poll_interval_ms: get_config_poll_interval_ms(), max_concurrent_agents: get_config_max_concurrent_agents(), running: {}, claimed: set(), retry_attempts: {}, completed: set(), codex_totals: {input_tokens: 0, output_tokens: 0, total_tokens: 0, seconds_running: 0}, codex_rate_limits: null } ... ``` ### C. Dijkstra 理论支持 Edsger W. Dijkstra 在 EWD667 文章中解释了为何精确描述必然演变为代码：数学史表明，希腊数学停留在口头和图形阶段，穆斯林代数在符号化尝试后因回归修辞风格而消亡，现代文明世界只有在西欧摆脱中世纪经院主义后才能兴起。软件工程同理，试图用自然语言追求精确性是徒劳的。 ## 2. 技术细节 ### A. 规范与代码的关系 ```mermaid graph LR A[自然语言想法] --> B{足够精确?} B -->|否| C[模糊规范] B -->|是| D[结构化形式] D --> E[伪代码] D --> F[形式化规范] E --> G[实际代码] F --> G C --> H[生成失败/不完整] ```  ### B. 实际测试结果 作者尝试使用 Claude Code 按照 Symphony 规范生成 Haskell 实现，结果： - 存在多个 bug，需要多次提示修复 - 即使"成功"运行，codex agent 也只是静默旋转，无法处理 Linear 工单 - 结果存储在 Gabriella439/symphony-haskell 仓库 ### C. 其他规范示例 YAML 规范极其详细、广泛使用、包含一致性测试套件，但大多数 YAML 实现仍不完全符合规范。这印证了精确规范不等于可靠实现。 ## 3. 数据与事实 ### A. 规范文档规模 - Symphony 规范文档长度：已达到所含 Elixir 实现的 1/6 - 若继续扩展，将重演博尔赫斯"论科学的精确性"中的荒谬故事 ### B. 代码质量问题 作者指出 Symphony 规范中充斥着"AI 产物"的痕迹： - 代码片段标注为 text 而非代码块 - 缺乏连贯性、目的感和对全局的理解 - 例如第 10.5 节的"规范形"句子杂乱堆砌 # 四、影响分析 ## 1. 行业影响 ### A. 技术趋势 Agentic coding 运动试图将工程师转变为规范编写者，但这忽视了软件工程对精确性的内在需求。 ### B. 工程实践 过度依赖规范文档可能导致： - 规范本身质量下降（为求快而牺牲思考） - 生成代码质量不稳定 - 维护成本增加 ## 2. 用户影响 ### A. 工程师 - 被误导以为可以"外包"编码工作 - 实际上需要投入与编码相当的精力编写精确规范 ### B. 团队 - 在追求速度的工程文化中，规范质量无法保证 - "垃圾输入，垃圾输出"原则依然适用 ## 3. 技术趋势 ### A. 根本问题 代码就是规范最精确的表达形式。试图绕过这一本质是徒劳的。 ### B. 前景 AI 辅助编码有价值，但不应寄望于完全替代精确思维和直接编码。 # 五、各方反应 ## 1. 作者立场 规范文档从来不是省时设备。如果优化交付时间，直接写代码比通过中间规范文档更有效。 ## 2. 业内观点 ### A. 支持 Agentic Coding 认为规范能提高质量、减少编码工作、让工程师转向更高层抽象。 ### B. 反对意见 强调精确描述必然演变为代码，规范质量决定生成质量。 # 六、相关链接 ## 1. 相关项目 - [OpenAI Symphony 项目](https://github.com/openai/symphony) - [Symphony Haskell 实现](https://github.com/Gabriella439/symphony-haskell) ## 2. 参考资料 - [Dijkstra EWD667](https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html) - [YAML 规范](https://yaml.org/spec/1.2.2/) *** ## 参考资料 1. [A sufficiently detailed spec is code - Haskell for all](https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code) 最后修改：2026 年 03 月 19 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏