规格驱动开发的致命缺陷与自维护规格的解法

摘要

文章指出一个软件工程的根本困境：所有文档几乎注定过时，因为持续维护文档是一项无人看见、无人奖励的隐性工作。规格驱动开发（SDD）同样深陷此困——过时的规格会让AI代理自信地执行一个与现实脱节的计划。解决方案是构建双向自维护规格：人类与代理共同读写同一份规格，代理执行过程中将约束、变更和关键决策自动写回，使规格始终与实际构建保持一致。

内容框架与概述

文章开篇建立一个核心论断：唯一可以百分百信任的文档是代码本身。设计文档、架构图、README 等一切书面产物几乎在完成后就开始失效。作者将原因归结为人类的行为模式——工程师擅长集中爆发式工作，写完即转向下一件事，文档的持续更新在与其他任务的竞争中几乎总是落败。这不是流程或工具能解决的问题，而是人类天性。

在此基础上，作者将矛头指向规格驱动开发。SDD 的出发点是合理的——在启动编码代理前先写清楚意图，远胜于向聊天窗口粘贴提示词。但规格本质上也是文档，面临同样的失效风险。更严峻的是，过时的设计文档只是误导偶尔读到它的工程师，而过时的规格则会误导不加质疑、自信执行的代理，后果更难察觉。

作者随后介绍其团队在 Intent 产品中探索出的解法：一份由人类与代理共同维护的活性规格。人类描述需求，协调代理起草规格并分解任务，人类审核通过后代理开始执行，执行中发现的假设偏差、约束冲突和方向调整均被写回规格。这一机制类比于一名优秀的初级工程师——发现 API 不支持原定方案时，他会主动更新任务单并说明理由，而非沉默地构建错误结果。

文章最后点明设计难点与核心结论：代理写回规格的粒度至关重要，过多变成噪声，过少让人失去感知。好的代理只应上报改变执行方向的关键决策。每一次文档优先的工程运动都因同一原因失败——它要求人类做持续的隐性维护工作。SDD 若不让代理承担其应有的维护份额，将重蹈覆辙。

核心概念及解读

规格驱动开发（Spec-Driven Development）：在启动AI编码代理前，先用规格文档描述意图的开发范式。初衷合理，但规格同样面临文档失效的根本困境。

自维护规格（Self-Maintaining Spec）：由人类与代理共同读写的活性规格。代理执行任务时将发现和变更自动写回，无需人工记住更新，始终与实际构建同步。

双向维护机制（Bidirectional Maintenance）：人类负责提供意图与审核决策，代理负责执行与反馈变更，形成闭环协作，使规格保持诚实与准确。

协调代理（Coordinator Agent）：读取代码库、起草规格、分解子任务的专职代理角色，是多代理协作体系的调度核心，也是衔接人类意图与执行代理的关键枢纽。

更新粒度（Update Granularity）：代理向规格写回信息的详细程度。过细沦为噪声，过粗失去可见性，只上报改变执行方向的关键决策是理想状态，是系统设计中真正困难的问题。

原文信息

此摘要卡片由 AI 自动生成