代码都被AI写了，程序员还剩什么活？SDD给出答案

代码都被AI写了，那人干什么？这个问题在2026年已经不再是玩笑。58沈剑在一篇3500字的干货长文中，给出了一个系统性的答案：SDD，规范驱动开发（Specification-Driven Development）。

传统研发流程里，最耗时的不是写代码本身，而是人与人之间的沟通。需求评审、设计评审、架构评审、测试用例评审、联调沟通、测试沟通、上线沟通——这些环节占据了项目周期的大头。AI时代到来后，写代码、做设计、写用例这些"执行"环节被极大压缩，如果流程不变，人与人之间的沟通就成了新的瓶颈。

真正AI-native的公司，已经对研发流程做了彻底重构。而大部分非AI-native的公司，只是让流程中的每个角色各自用AI工具提效，流程本身没变。这两者的差距，会越来越大。

AI的问题不是能力，是"方差"

把流程彻底交给AI，会遇到三个问题：AI见过所有类型的业务和产品，但不知道你公司的业务和产品；AI见过所有设计，但不知道你产品的设计约束与规范；AI见过所有架构与技术，但不知道你团队的技术栈约束与规范。

换句话说，AI的知识太广，幻觉太多，如果不加约束，产出质量的"方差"会特别大。SDD的思路，就是让研发流程从"人工驱动"进化到"约束与规范驱动"——AI不再只是执行，而是在约束与规范的范围内执行。

三个基线文档，把资深经验蒸馏成"宪法"

SDD把研发生命周期拆成四个阶段：需求结构化、设计约束、架构约束、计划与执行。对应地，需要三个规范基线：需求模板基线（prd.md）、设计约束基线（design.md）、架构约束基线（arch.md）。

这三个基线，是把团队里最资深的产品经理、设计师、架构师的经验蒸馏成三个规范文档。不同公司、不同产品、不同团队、不同技术栈，约束原则上不同；相同公司、相同产品、相同团队、相同技术栈，约束原则上相同。

为什么传统PRD不适合AI？因为传统PRD是给人评审用的，充满自然语言歧义。产品经理说"用户登录后可见"，人知道，AI却不知道登录流程是什么。最关键的原则是：给AI"事实"而非"描述"。你给AI一个真实的用户ID、真实的分数数据，比你说"一个典型的分数"有效十倍。

设计约束也一样。AI没有设计直觉，你让它设计一个按钮，它可能给你做出一个带3D动画、粒子效果、声音反馈的超级按钮，但你只是想要一个提交表单的普通按钮。design.md就是特定产品的原型设计"宪法"，规定颜色必须从Token选取、字号必须在字阶内、组件必须有五态、红线清单有哪些禁止事项。

架构约束同理。以X学科技为例，四类产品对应四类arch.md：单.html架构、多文件模块化架构、游戏引擎架构、云原生全栈架构，分别覆盖从简单到复杂的四类需求。

五个步骤，从基线到实例的规范驱动

有了三个基线"宪法"，具体执行时如何"执法"？以需求A为例，SDD的实例化过程分五步。

第一步，需求实例化。输入prd.md模板加具体需求，加上人调优审核兜底，输出prd-A.md。人可以跟AI对话，也可以用工具产生实例化文档，但必须严格遵循模板结构、不遗漏字段，然后人调优、审核、兜底。

第二步，设计实例化。输入design.md约束加prd-A.md需求，加上人调优审核兜底，输出design-A.html设计原型。如果发现新的组件状态需要规范，就升级design.md。

第三步，架构实例化。输入arch.md约束加prd-A.md需求加design-A.html原型，加上人调优审核兜底，输出arch-A.md技术与架构设计。

第四步，生成执行计划（PLAN模式）。PLAN模式读取基线文档和实例化文档：实例化文档告诉AI"需求是什么"，约束基线文档告诉AI"边界在哪里"。它做三件事：从prd-A提取功能点、验收标准、业务规则；从design-A提取页面组件交互，同时用design.md校验是否符合规范；从arch-A提取模块接口数据流，同时用arch.md校验。最后生成PLAN-A.md，包含原子任务拆解、依赖管理、验收标准、风险回退。

第五步，执行计划（CODE模式），真正把代码写出来。核心原则是单任务上下文，一次只处理一个任务。

人被蒸馏成基线之后，就没用了吗？

答案是否定的。AI不可能生成完全确定的prd-A，必须有人在中间反复对话、调优、补充、审核、折衷、兜底。但这个过程，是人与AI的高效互动，而不是人与人之间的低效沟通与评审。

还有一个重要机制：如果有通用实践，可以升级基线。公司与团队的基线是需求与项目的底线，底线会在不断做需求、不断打磨项目的过程中逐步完善、逐步提升。

所以，代码都被AI写了，人干什么？答案是：人负责定义约束、审核产出、兜底质量，以及持续升级基线。从"人做所有事"到"人定义规则、AI执行规则"，这才是AI时代研发流程重构的核心逻辑。