过去两年，软件行业反复上演同一种演示：对着一个空白输入框说一句话，几分钟后，一个能跑的应用出现在屏幕上，界面体面，交互完整，第一次点击样样都对。台下的人惊呼，台上的人见惯不惊。这不是魔术，随时可以复现。AI 能把一个想法变成一件作品，这件事已经没有争议。

争议在下一站。演示台上的惊艳，一进正经项目就换了性格：需求一改，说好的地方悄悄变形；修好一处，另一处又漂回去，交付变成一个漫长的“差不多”。演示惊艳，交付艰难，两件事同时为真，又同时落在几乎每个认真用 AI 做项目的人身上。到这个程度，它就不再是手感问题，而是行业级现象，值得认真解释。

这个系列给出的答案叫 GSDD（Governed Spec-Driven Development，治理规范驱动开发）：把“什么是对的”从聊天记录里拿出来，立成一套有唯一出处、自带治理规则的规范文件集，也就是 SSOT（Single Source of Truth，唯一事实来源）。程序员盯 SSOT，不盯代码。本篇回答“为什么需要”：回看这几年的行业历程，用一个修了六周的真实案例钉住病根，然后立论，业界最激进的那批预测放在结尾正面回应。后续三篇各有分工，02 篇立规范，03 篇重构验收与测试，04 篇落地运行时与启动。

一、AI 编程这几年：从补全到多智能体

把镜头拉远，这几年可以整理成七个阶段。它们不是某条产品路线图，而是几乎所有把 AI 拉进日常开发的团队被推着走过的同一条路。这些阶段在时间上互相重叠，与其说先后替代，不如说问题接力：每出现一个新瓶颈，就长出一种新做法。下面只讲两件事：出现了什么，解决了什么；讲完再回头看缺了什么。

最早是补全。2021 年起，AI 住进编辑器，猜你的下一行：注释写一半，函数签名刚起头，剩下的自动补出来。打字提速了，样板代码消失了，写循环、判空、样板配置这类体力活大半外包了出去。AI 第一次坐到程序员的工位旁边，尽管它只负责把行接好。

行接得再顺，任务还得由人拆成一句句指令递过去。于是有了对话生成（prompt）：2022 年起，把想法整句交给 AI，“帮我写一个××”，回来一个能跑的初版。从 0 到 1 的速度问题，历史性地消失了：周五晚上的想法，周六早上就有初版可以点开。

初版能跑，但和你的项目无关，它是最平均的那个答案。行业随即开始喂上下文（context）：2023 年起，把项目文档、历史决策放进对话，让 AI 检索代码库再回答。AI 的建议开始贴着你的项目说话：它知道你的技术栈、你的目录结构、你上个月定下的方案。“懂项目”从比喻变成了日常。

喂出来的“懂”，每次对话都从头再来。约定需要常驻，2024 年，把项目规则（rules）写成文件放进代码库成了通行做法：“错误一律返回这个格式”“不要再引入新的状态管理库”，写一次，此后每次对话自动生效。重复交代的沟通成本，就此清零。

文件管得住愿意听的 AI，管不住它的动作。2025 年，护栏（harness）登场：权限体系、危险命令拦截、敏感操作审批，AI 想动不该动的文件、跑不该跑的命令，会被当场拦下。这是行业第一次用机制而不是措辞约束 AI，越界有了成本。

边界划好之后，AI 的活动半径继续扩大，它学会了自己转，这就是自主循环（loop）。同样在 2025 年，定计划、执行、自检、继续成为标准工作方式：给一个目标，AI 能埋头干上一小时，人从每一步的驱动位上退下来，从“每句话都盯着”变成“看结果说话”。

一个人的上下文装不下的大工程，就让多个 AI 分工。2025 到 2026 年，多智能体编排（orchestrator）从论文和演示走进生产环境：拆解、分派、汇总，几个 AI 分头写模块，再有 AI 把结果拼起来。规模的天花板，被推开了。

七个阶段摆在一起看，有一件事非常清楚：它们解决的全是“AI 干活快不快”。补全解决打字，对话解决从 0 到 1，上下文解决懂不懂项目，规则解决重复沟通，护栏解决越不越界，自主循环解决人盯不动，多体解决规模。每一步都在给执行力升级，整个行业的精力，全压在了执行力这一侧。

但有两个问题，七个阶段始终没有人回答。其一，“什么是对的”没有唯一出处：事实散落在聊天记录、文档、口头约定和 AI 的猜测里，没有一处是权威，AI 信了哪一份，你不知道，它自己也未必知道。其二，“凭什么信”没有独立判卷：生产速度翻了几番，判定正确性的手段还停留在逐行看，而逐行看早在自主循环阶段就被速度甩开了。

这两个洞有一个共同点：都不是模型能力问题。换再强的模型，事实还是散的，判卷还是缺的，而且模型越强，散落的旧口径被抄进代码的速度反而越快。这是治理问题，得用治理的办法解。

二、最新现状：能力在涨，项目照样卡

按理说，局面正在被两股力量冲掉。第一股是模型：一代比一代强，上下文更长、推理更深、代码更漂亮，每一代都把上一年做不到的事变成默认能力。第二股是方法：AI 开发的工程实践正在学科化。到 2025–26 年，harness engineering（护栏工程）已经成为有名字的学科，怎么给 AI 划权限、设拦截、留审批，有了成体系的做法，不再是一篇篇零散的博客；多智能体编排已经实用化，拆任务、派工、汇总在生产环境里日常运转；规范驱动开发（spec-driven development，先写规范、再让 AI 按规范实现）从小众主张变成了行业议题。

方向确实对了，尤其是规范驱动开发，它说对了一件关键的事：不能让需求停留在聊天记录里，得先把规范写出来。但“把规范写出来”只是第一步。写出来的规范本身怎么治理，谁来改、怎么改、改了怎么记录、怎么保证它不腐烂，还没有答案。规范写完就进仓库吃灰，和需求留在聊天记录里，是同一个病的两个病程。这正是 GSDD 的立足点，它与一般 SDD 的分界，02 篇专门展开。至于业界最激进的那批声音，直接预测代码审查和单元测试会消失，分量足够重，本篇结尾正面回应。

先落回现实。能力在涨，方法在成熟，但项目的状态曲线没有跟着能力曲线走。认真做过正经项目的人都认识这条曲线：启动惊艳，中盘胶着。看起来快好了，改一个小需求，三处说好的地方悄悄变形；再修，另外两处又漂回去。项目在“看起来快好了”里打转，一圈，又一圈。

这个模式值得起个名字：许愿式编程。一句话做出第一眼惊艳的作品，但极难按需调整，也无法达到交付标准。

拆开看，两个现象互为表里。

为什么第一眼惊艳？因为 AI 替你做了大量决定，而且做得体面。惊艳恰恰来自“它替你决定了”，而不是“它决定对了”：你没说出口的部分，它用最常见、最平均的方式补齐，第一眼永远光鲜。

为什么极难调整？因为每次调整都是一次新的许愿。AI 按新愿望再猜一遍，上一版里已经说好的部分悄悄漂移。你在跟一台记不住上次愿望的许愿机打交道，每次许愿都是重开一局。

病根两句就能说完：愿望没有立成规矩，正确性没有出处。

愿望没有立成规矩，意思是需求不是被管理的事实，只是聊天记录里的随口一句话：没有唯一出处，没有变更记录，没有改动门槛。改了就改了，没有人知道需求在什么时候变成了什么。

正确性没有出处，意思是“什么算对”散落在聊天历史、截图、口头约定和 AI 的猜测里。AI 写错的时候你怪它，可它依据的口径本来就是散的、旧的、互相矛盾的。

下一节，用一场六周的真实拉锯，把这两句病根钉死。

三、一个“重复客户”问题，修了六周

案例项目化名领英智能触达：一个帮销售在领英上做自动化拓客的工具，半路接手。前期需求反复变动，规范一直没立起来，这个背景，是后面所有事情的土壤。

用户报告：系统里，同一个客户出现了两条记录。

听起来是小问题，加一条“发现重复就合并”的规则。结果，这一修就是六周。

六周里，“这两条记录是不是同一个客户”的判定标准，来回翻了三次方向。按一套标准修好了这条数据进门的路，另一条路上马上冒出新的重复；再按新标准修那条，这条又坏了。团队不是不努力，每一版修复都真的修好了它盯着的那条路。坏就坏在，每次都只修好了那一条。

为什么修不完？因为这个系统里，“是不是同一个客户”的判断标准不止一套。数据从几条不同的通道进门，每条通道各自认一套身份判定，互相不通气。修 bug 的人每次只能看见自己眼前那条路，于是修好一处，打爆另一处。真正的麻烦在于，修复本身没有 bug，“修复”这个动作，只是在多条互不知情的标准之间搬运矛盾。

拉锯的终点倒也干净：把判定收拢到所有数据进门都要过的唯一一道关卡。一个事实，一处判定，六周战争当场结束。

事后复盘，根因清晰得近乎无聊：需求不断改，但每次变更既没记录到唯一出处，也没同步进给开发（和 AI）看的规范文件。于是每段代码按各自拿到或猜到的旧口径写，口径自然越写越散。那几条通道、几套标准，不是哪个架构师设计出来的，是需求每次变更都无处落地时的自然沉积。

教训一句话：**一个事实没有唯一出处，修 bug 就是打地鼠。**先收拢标准，再修现象。

还要补一句时代注脚：这是 AI 深度参与开发的项目。AI 只知道它读到的规范，规范旧了、散了、或者根本没写下来，AI 就把旧口径原样再抄一遍，而且抄得比人快得多。事实散落这个老病，在 AI 时代装上了放大器。

四、GSDD：程序员盯 SSOT，不盯代码

缺的那块东西，就是 SSOT。一份住在固定位置、自带治理规则的规范文件集：“什么是对的”在那里有唯一出处，需求怎么改、谁来改、改了怎么记录，都有明确答案。把规范的制定与治理当作一等公民，再用它驱动 AI 开发，这套做法就是 GSDD。

核心主张，也是全系列的绝对主张：

程序员盯 SSOT，不盯代码。

这不是修辞，是岗位说明。程序员的注意力是稀缺资源，注意力锚在哪，岗位就在哪。GSDD 把这个锚点从“逐行读实现”挪到“维护并盯住 SSOT”。

字段结构、存储格式，同样落在这条边界之内：它们的定义是事实层设计文档的一部分（ssot/L1-facts/design.md，完整布局 02 篇给出），要看的是这份文档，不是实现。审设计，是审 SSOT 里白纸黑字的定义；看代码，是逐行读 AI 生成的实现。审设计不等于看代码，绝对主张在这里不留后门。

与 harness engineering 的分界

先承认 harness 的价值真实存在，第一节第五阶段的全部成果，越界有成本，这个功绩不小，再看它的管辖边界。一句话：harness 管 AI 越不越界，GSDD 管 harness 不管的三件事。

1. **人干什么。**harness 不回答程序员的价值在哪。GSDD 的回答是岗位本体论：价值锚点从代码迁到 SSOT，工作对象是规范与验收证据，剩下的实现整体交给 AI。
2. **事实烂没烂。**harness 拦得住危险动作，拦不住口径腐烂。GSDD 用分层规范加变更流水账，让规范本身成为被治理对象。领英智能触达的六周里，AI 没有越界一步，护栏无灯可亮，因为烂掉的是事实，不是行为。
3. **凭什么信。**harness 保证 AI 没干被禁止的事，不保证干成的事就是你要的事。GSDD 的回答：人审验收证据，不审代码。

反过来，harness 在 GSDD 里没有被抛弃，它是四支柱之一。这是本篇第二套框架，与第一套分工不同：第一节的七个阶段是行业历程，讲别人做过了什么；这四根支柱是机制构成，讲这套方法由什么搭成：

四根支柱不是概念，每根都落到可执行的机制，细节留给对应篇目，这里给锚点：

• 人的岗位，落在 SSOT 入口文件的头部治理规则里：第一行就是主张句，角色栏写明职权，AI 在开发 session 中对 SSOT 全层只读、严禁修改，SSOT 由程序员维护。这一条是岗位本体论的机制底线：如果 AI 能改规范，“盯 SSOT”就退化成盯一份 AI 自己写的作业。
• 分层规范，落成三层：需求层（L0）、事实层（L1）、流程层（L2），共 8 个文件。改动门槛随“变更频率 × 爆炸半径”递增：入口头部改动需负责人批准；需求变更必须录入只追加的流水账（日期、新需求描述、波及文件）；事实修改过第二双眼睛；流程文件由程序员日常维护。
• 验收体系，落成三层单向引用：acceptance 由程序员手写、住在 SSOT、验收项带编号；testcase 只串联验收项编号，不定义新标准；自动化测试强制引用编号，测试是验收项的实现，不是第二出处。AI 只执行验收并产出证据（日志、截图、测试结果），无权自造或改写验收项。
• 护栏保障，落成 SSOT 只读的机械保障与运行时装载：通过 harness 设置明确修改权限归人管，系统层隔离兜底，指路与流程封装装进 AI 的日常，唯一一道闸门架在不可逆的动作上。每道护栏必须答得上四问：哪个工具、执行点在哪、判定数据是什么、失败了会怎样。答不上来的“护栏”是愿望，删掉。

三件事加四支柱，落到代码库上就是一条分界线。一边是 ssot/，“什么是对的”住在那里，由程序员维护；另一边是其余一切，源码、测试代码、构建脚本，都是 AI 从 SSOT 派生的产物。分界线的权限通过 harness（护栏）设置来明确：SSOT 的修改权归人管。GSDD 治理的是整个版图，外加一张岗位说明书。

最后把岗位本体论说透。程序员的产出物，从“代码”换成三样东西：立得住的规范（需求有出处、口径唯一）、写得清的验收（标准在人手里）、看得懂的证据（AI 执行验收产出的日志与截图）。至于源码、测试代码、构建脚本，整体交给 AI。就像计算器出现之后，“会算”不再是会计的价值所在，“该算什么、结果对不对”才是。不是人退场了，是人的价值锚点搬家了。

最后说清适用边界。GSDD 治理的是“什么是对的”，前提是“什么是对的”说得清、验得出。需求说不清、验收定不出的探索期项目，先轻后重，拿最简的规范跑起来，等业务的形状稳定了再立规范；一次性脚本和纯原型不必上这套流程，流程自身的成本会超过它护住的产出。GSDD 也不解决“人不懂业务”：规范写得对不对，首先取决于人知道什么算对，它治的是“懂了业务却没把规范立起来”。

立论至此完成，剩下的问题各有归属：

• 02《规范：SSOT 分层与改动纪律》回答：什么是对的、住哪、谁把控、怎么改。
• 03《执行：验收与测试重构》回答：凭什么信，验收与测试怎么重构。
• 04《落地：让 GSDD 成为 Agent 的默认开发工作流》回答：怎么落地，装起运行时，第一周干什么。

五、“测试会消失”？

立论摆完了，业界还有一组更激进的预测没回应。资深程序员 Thorsten Ball（经阮一峰《科技爱好者周刊》第 416 期转述）对未来编程有一串判断，其中两条与本文直接相关：

1. 代码审查将消失，人类跟不上 AI 生成代码的速度，以后只能审查系统架构，没法逐行审。
2. 单元测试可能消失，“整栋楼就会重建，何必再去检查单块砖头”，只留集成与系统级测试。

先说同意的部分，而且同意得很彻底。逐行看代码会消失，这本来就是 GSDD 的立场，系列副题写的就是“不盯代码”。砖头检查让位给整楼验收，同意。Ball 说人只能审架构，这件事在 GSDD 里有准确的名字：审规范，审 SSOT 里的设计文档与验收标准。他预测这个岗位消失，GSDD 给它留了位置，只是工作对象换了。

分歧在下一步推理。从“逐行跟不住”，Ball 推出“独立验收也可以一并撤掉”，GSDD 推出相反的结论：

会消失的是逐行看代码，不能消失的是独立验收。

生成越快，“这还是不是你要的那栋楼”这个问题越贵重。楼重建得越便宜，问错这个问题的代价就越大：等你发现楼不对，返工的不是一个函数，是整栋楼。生成速度没有让验收变得可有可无，它把验收从“好习惯”变成了唯一还站在人这边的环节。

GSDD 的回答因此是一句话：**楼可以整栋重建，验收标准不跟着重建。**验收标准由人手写、住在 SSOT、验收项带编号；AI 只执行验收并产出证据，日志、截图、测试结果，无权自造或改写验收项。户型图不变，楼重建一百次，就对着户型图验收一百次。砖头确实不用查了，但那是因为我们把“查”的对象从砖换成了户型图，而不是取消。至于单元测试本身的去留，03 篇给出收窄方案：业务规则必须测，UI 文案与样式不进自动化，慢测试转手动、快速冒烟保持自动。收窄，不是取消。

Ball 还有一个更冷峻的判断：Bug 的性质变了，多数 Bug 来自需求提错或表达不准确，而非代码错误。这句话是 GSDD 最硬的外部佐证。如果多数错误出在需求侧，那么把治理投资全押在代码侧（linter、类型系统、逐行审查）就是押错了赛道，真正需要立规矩管理的是需求。GSDD 的需求层（L0）正为此设：需求有唯一出处，变更必须录入只追加的流水账。领英智能触达修不完的那六周，就是这条断言的项目级注脚，没有一行代码错误，全是需求口径的漂移。

最后是那句在 Hacker News 上广为流传的话：“不要让 AI 设计代码，而要让它实现你已经设计好的代码。”它与本文的主张句互为印证，但引用时必须精确化一步：GSDD 并不是“AI 不许碰设计”。AI 可以起草，起草设计文档、起草验收项；人逐条采纳、修改、批准，采纳那一刻它才成为 SSOT 的一部分。区别不在 AI 动不动手，而在谁的话算数：AI 的话是草稿，人采纳了才算数。HN 这句话说对了方向，GSDD 把“已经设计好的”落成了一份可治理、可变更、可验收的 SSOT。

把全篇收个尾。七个阶段把“AI 干活快不快”解决到了多体协作的程度，留下两个洞：事实没有唯一出处，正确性没有独立判卷。这两个洞是治理问题，模型变强填不上，GSDD 的答案是程序员盯 SSOT、不盯代码，人立规范、人审证据，AI 实现。harness 是这套治理的四分之一，不是全部，分界一句话：harness 管越不越界，GSDD 管人干什么、事实烂没烂、凭什么信。

这套方法不是从原则推出来的，是从六周的打地鼠里长出来的。旧岗位没有消失，它搬了家，从代码搬进 SSOT。

下一篇，立规范。