代码都被AI写了，那人干什么？（SDD超级干货）
架构师之路 · 软件开发
58沈剑 2026-09-05 18:47 北京 3500字，SDD。 《AI驱动SDD工业化开发全流程》，3500字，阅读需要10分钟。 一、传统研发流程为什么失效？ 传统研发流程： 人做需求 → 人需求评审 人做设计（指原型） → 人设计评审 人做架构（总体+详细） → 人架构评审 人做测试用例 → 人测试用例评审 人做开发联调 → 人开发联调沟通 人做测试 → 人测试沟通 人做上线 → 人上线沟通 前半部分最花时间，人与人之间的沟通时间（加粗部分）在项目过程中只是很小一部分。 AI时代呢？ 通过AI工具，前半部分的时间（做需求，做设计，做架构，做用例，做开发联调，做测试，做上线）极大缩短，如果研发流程不变， 人与人之间的沟通，就会成为项目的瓶颈。 真正AI-native的公司，对研发流程彻底进行了重构。而 绝大部分非AI-native的公司，流程未变，只是流程中的各个角色，使用了AI工具提高自己的效率而已。 画外音：你们公司呢？ 那将上述流程彻底交给AI，会存在什么问题？ 1. AI见过所有类型的业务和产品，但不知道特定公司的业务和产品； 2. AI见过所有设计，但不知道特定产品和团队的设计约束与规范； 3. AI见过所有架构与技术（含开发，测试，运维等），但不知道特定产品，团队，技术栈的架构约束与规范； AI并不是能力不行，而是 AI的知识太广，幻觉太多，如果不加以约束与规范，产出质量的“方差”将特别大。 如何提升AI产出质量的下限，减少“方差”呢？ SDD， Specification-Driven Development ，规范驱动开发。 产研研发流程，从“人工驱动”进化到“约束与规范驱动”。 AI不再只是执行，而是让AI进入到流程，在约束与规范的范围内执行。 二、SDD规范驱动开发全流程细节 我们把研发生命周期拆成四个阶段： 1. 需求结构化； 2. 设计约束（原型相关）； 3. 架构约束（技术相关，包含测试）； 4. 计划与执行； 规范驱动体现在哪些阶段，需要哪些规范？ 1. 需求阶段：由结构化需求模板驱动； 2. 设计阶段：由设计约束与规范驱动； 3. 架构阶段：由架构约束与规范驱动； 需要强调的是： 1. 不同公司，不同产品，不同团队，不同技术栈，原则上约束 不同 ； 2. 相同公司，相同产品，相同团队，相同技术栈，原则上约束 相同 ； 因此，特化到一个具体的产品，具体的设计，具体的技术栈，具体的团队，就有 3个通用的规范基线 ： 1. 需求模版基线； 2. 设计约束基线； 3. 架构约束基线； 这三个基线，就是结合团队研发的产品，团队内最资深的产品经理，设计师，架构师的蒸馏，而形成的三个规范文档 ： 1. prd.md 2. design.md 3. arch.md 【需求基线】 第一个基线，prd.md，PRD模板母版。 为什么传统PRD不适合AI？因为传统PRD是给人评审用的，充满自然语言歧义。产品经理说"用户登录后可见"，人知道，可AI却不知道登录流程是什么。 具体细节，可参考给定的文档。 这里最关键的原则是：给AI"事实"而非"描述"。你给AI一个真实的用户ID、真实的分数数据，比你说"一个典型的分数"有效十倍。 prd.md就是规定"公司内所有PRD应该怎么写"的模板。 【设计基线】 第二个基线，design.md，设计约束规范。 为什么需要设计约束？ 因为AI没有设计直觉，你让它设计一个按钮，它可能给你做出一个带3D动画、粒子效果、声音反馈的超级按钮，但你只是想要一个提交表单的普通按钮。AI会过度设计，也会设计不足。 design.md就是对于特定产品，原型设计的"宪法"，规定颜色必须从Token选取、字号必须在字阶内、组件必须有五态、红线清单有哪些禁止事项。 而且设计规范是可复用的公司级资产，对于同一个产品，设计约束规范应该是固定的，对于不同的产品，理论上设计约束规范应该是不一样的。 具体细节，可参考给定的文档。 【架构规范】 第三个基线，arch.md，架构约束规范。 具体细节，可参考给定的文档。 补充说明：X学科技有四类产品，对应四类arch.md - 单.html架构 - 多文件模块化架构 - 游戏引擎架构 - 云原生全栈架构 分别实现从简单到复杂的四类需求，本例演示的是第一类架构arch.md 产品，设计，架构三个基线是“宪法”，具体到执行的时候，是如何完成“执法”，如何完成规范到实例的映射，如何规范驱动的呢？ 如上图所示： 1. 左侧是基线约束与规范； 2. 中间是一个具体的需求； 3. 右侧是针对这个需求，规范实例化后的实际产品需求、需求原型、需求架构； 假设我们要做需求A，实例化的过程如何呢？ 【步骤一：需求实例化】 第一个实例化，prd-A。 具体怎么做？ 输入：prd.md