代码被AI写了，人干什么？SDD规格驱动开发重新定义工程师价值

代码都被AI写了，那人干什么？（SDD超级干货）

这两年“AI写代码”从段子变成了日常。我身边不少团队已经默认：能交给AI生成的基础代码，绝不让工程师手写。于是很多人在问同一个问题——代码都被AI写了，那人干什么？这个问题听起来像焦虑，实际上是机会。真正的问题不是“人要不要写代码”，而是“人怎么组织AI写代码”。今天想聊的SDD（Specification-Driven Development，规格驱动开发），就是我对这个问题的答案。

这套东西在个人项目和团队协作里都试过，适合正在用AI编程工具但觉得产出质量不稳定的人，也适合管理者——想让大家从“手写模式”切到“指挥模式”却不知道从哪下手。我先把SDD的底层逻辑讲透，再把能直接复用的规格模板和实操流程铺开。

1. 代码确实在被AI改写，但AI的“会写”撑不起“能用”

1.1 从补全到Agent，AI编程实际走到了哪个阶段

先看清现实。现在的AI编程工具大致分了三层。第一层是补全工具，代表是GitHub Copilot、通义灵码这类，你写了函数开头它帮你补函数体，本质是“高级自动补全”。第二层是对话生成，ChatGPT、Claude这类，你用自然语言描述需求，它给你一整段代码，你再复制回项目里。第三层是Agent形态，典型的有Cline、OpenAI Codex agent、Cursor Agent，它能自己读仓库结构、搜索上下文、改多个文件、跑测试，然后告诉你“我改完了，测试通过了”。

很多人对AI编程的体感停留在第一层和第二层，但其实第三层才是真正改变工作流的东西。当Agent能自主修改代码时，人的角色不再是一个字符一个字符地编码，而是告诉Agent“系统里有一个订单状态不一致的Bug，需要统一状态流转逻辑”，然后它按描述去修。代码的“量”已经不是人类写的，但代码的“方向”和“对错”仍然取决于人。

1.2 用过AI写代码的人，多少都撞过这几堵墙

不过，工具好用不代表工作流好用。我用AI编程踩过的坑完全可以列成一份避雷清单。

首先，AI特别容易生成“看着对但跑不起来”的代码。比如你让它写一个文件上传接口，它把表单解析、文件存储、异常处理全写了，看起来完美，一运行发现路径写死、缺少依赖、忘记处理文件名编码。这类问题不是AI解决不了，而是你的需求里根本没写这些边界条件。

其次，AI会一本正经地“编造”不存在的API。你问它某个第三方SDK怎么用，它能给你编出一个其实不存在的方法名，连参数都像模像样。原因很简单：大模型学的是概率分布，它不知道你的项目里到底装了哪个版本的依赖。

第三是“局部正确、全局失控”。AI擅长生成一个函数，但不会自动替你权衡“这个模块要不要拆成微服务”“消息队列这个场景是不是过度设计”。代码可以生成，架构很难生成，尤其是基于真实业务约束的架构。

所以说到底，AI缺的不是编码能力，而是“需求准确性”“边界约束”“验收标准”这三样东西。而这三样，恰好是规格（Specification）要解决的事。

2. SDD是什么：你写规则，AI写代码

2.1 SDD不是新词，但AI时代重新定义了它

SDD全称是Specification-Driven Development，以前更多翻译成“规格驱动开发”或“规范驱动开发”，最早和契约式设计（Design by Contract）、形式化方法（Formal Methods）这些概念是近亲，常见于讲究严谨性的系统和安全关键领域。传统SDD的思路是：先写详细规格文档，再由人来照着实现，规格和代码的双重维护是最大的负担。

到了AI时代，SDD的内涵变了。因为它不再需要你写一套、人再翻译成一套，而是直接把规格交给AI，AI负责整个“翻译成代码”的过程。规格成了唯一需要人深度维护的东西，代码是由规格生成出来的产物。这个变化让SDD从“重流程”变成了“高杠杆”。

我的理解是：把SDD底层逻辑凝练成一句大白话——你要什么、满足什么条件、为什么这么做，这些必须写在代码之前；AI承担“怎么做”，人承担“是什么”和“为什么”。它真正回答的是那个标题里的问题：代码被AI写了，人干什么？人干最核心的活，干AI最不擅长的活，干事情定义和结果验收的活。

2.2 传统开发、普通AI辅助开发、SDD开发，差在哪

我做了一张对照表，能直观看出三者核心差异：

传统开发的问题是“人脑翻译”成本太高，需求到设计、设计到代码的每一步都是损耗，最后写出来的东西和用户要的经常两回事。普通AI辅助开发虽然省了翻译，但很多人在“问一题写一题”，代码是一块一块被焊上去的，缺少整体性和约束，越往后越难维护。SDD则试图让“目标、约束、验收”先行，所有代码行为都有据可依。

2.3 为什么SDD是AI时代“人”的核心竞争力

我不断强调这个观点：AI生成代码的能力越强，规格的重要性越高。原因在于大模型的基本运作方式是“概率续写”。你给它的上下文越模糊，它的输出越发散；你给它的上下文越精确，它的输出越收敛。规格就是让AI收敛的那套上下文。

打个比方。你让一个新来的实习生写一个用户注册功能，只丢给他一句“你去把用户注册写了”，他大概率写出一堆不合预期的东西。但如果你先给他需求文档、接口定义、字段约束、异常清单、验收标准，他干出来的活就会八九不离十。现在AI就是这个执行力强但需要前提约束的实习生，而你，就是那个提供前提约束的人。

另外还有一层原因：可维护性。代码生成了，如果三个月后要迭代，你和AI都忘了当初为什么这么写，那改起来就是灾难。但如果你保留了规格，把规格和代码一起提交到仓库里，后续迭代只需要修改规格、重新生成代码，整个过程是可控的、可回溯的。

3. 人干什么：从“码字员”变成“需求架构师”

3.1 新模式下四个不可替代的角色

既然写代码不再是唯一核心，那人的时间到底花在哪？按我自己的实践，SDD工作流里人的职责可以拆成四个角色，这四个角色常常由同一个人或者一个小团队同时承担，但思维模式完全不同。

第一个角色是“需求分析师”。你要能从用户描述里提炼出真实意图，区分“用户说的”和“用户真正想要的”，还要把模糊业务转述成明确规则。举个例子，用户说“商品列表要有筛选”，你真的要从这句提炼出：筛选条件有哪些？多条件之间是AND还是OR？无结果时显示什么？要不要分页？这些细节不问清楚，AI生成的代码永远是“通用版”，不是“你的版本”。

第二个角色是“架构决策者”。规格里不仅要写功能，还要写非功能约束，例如性能指标、安全要求、扩展性预期。是同步调用还是异步？要不要引入缓存？数据库选什么？这些决策没法甩给AI，因为AI没有你的业务全景。越大的系统，越需要人做这类取舍。

第三个角色是“验收标准设计者”。这有点像测试工程师思维。每条需求都要能翻译成“怎样才算完成”的条件。没有验收条件，AI给你的就是一份没有契约的承诺，你根本没法反驳它。有了验收条件，你就能把AI交出来的东西放进测试环境里一条条过。

第四个角色是“代码审查者”。AI生成代码仍然要人审。但审查重点变了——不是逐行找语法错误，而是看它有没有偏离规格，有没有引入隐藏问题，有没有过度设计或者偷工减料。审查者手里有规格这把尺子，效率远高于凭经验裸审。

3.2 写代码的人和不写代码的人，各自的发力点

不同背景的人切入SDD的方式不太一样。如果你是有经验的开发，你要练的是“把代码思维翻译成自然语言约束”的能力，也就是写规格的能力。你越能把约束写得精确、写得可验证，AI的产出越稳定。

如果你是产品经理、项目经理这类不直接写代码的人，SDD反而给了你一个很好的抓手。以前你不懂技术细节，提出的需求经常被开发一句“这不合理”挡回来。现在你可以把需求写成结构化规格，用“给出输入、绑定约束、定义验收”的方式表达，开发同事和AI都看得懂，沟通成本少了，扯皮也少了。

我记得有个做运营的朋友听过我的分享后，自己尝试写了一个“批量导出用户数据”的规格，然后丢给AI，还真跑出了一个能用的Python脚本。他说那一刻才真正理解：程序员的日常，从“编写逻辑”变成了“描述清楚逻辑”，这人人可上手，只是专业度深浅问题。

4. 手把手落地SDD：从一段文本到一门代码

4.1 规格文档到底怎么写：先装进一个模板

现在进入这篇文章的“超级干货”部分。SDD听起来玄乎，落地就要有一个能直接抄的规格模板。我用的是六段式结构：

• 背景：这一段要讲清楚“为什么做这个功能”，给AI提供上下文，避免它为了堆功能而设计。
• 需求：列出核心功能点，一条一个描述，每一条描述必须以“用户能/系统会”开头，保证行为明确。
• 约束：写明技术栈、性能指标、安全要求、兼容性要求，任何不能越界的边界都在这。AI最吃这一套。
• 输入输出定义：定义关键接口的入参、出参、错误码。接口有了契约，AI生成时就不会乱造方法名。
• 业务规则与边界：分支条件和异常场景，比如“库存不足时返回错误”“超时时间5秒”这类。
• 验收标准：逐条写“当……时，系统会……”，这是测试能跑通过的判断条件。

拿电商项目里最常见的“创建订单”来做示例，一份精简版规格可以长这样：

背景：用户从购物车发起结算，系统需要生成一笔新订单，并锁定商品库存，如失败需回滚。

需求：用户提交结算后，系统创建待支付订单；订单创建成功后，系统扣减库存；如果扣减失败，订单创建回滚。

约束：技术栈是Java 17 + Spring Boot 3；数据库为MySQL 8，事务隔离级别设为可重复读；接口响应时间需小于500毫秒。

输入输出定义：

• 输入：userId（长整型）、cartItems（列表，含skuId与quantity）、addressId（长整型）
• 输出：订单ID、支付金额、订单状态
• 异常：库存不足返回INSUFFICIENT_STOCK，地址无效返回INVALID_ADDRESS

业务规则：

• 同一用户的相同SKU，在购物车中合并数量；
• 下单时商品价格取价格服务实时价格，不以购物车快照价为准；
• 锁库存采用“预扣除”方式，超时30分钟未支付则自动释放。

验收标准：

1. 当购物车包含三种商品且库存足够时，系统创建一笔含三个商品项的订单，并返回支付金额。
2. 当任一SKU库存不足时，系统返回INSUFFICIENT_STOCK，不创建订单、不扣减任何库存。
3. 当请求包含无效地址时，系统返回INVALID_ADDRESS，不做库存变更。

把这段文本直接贴给AI编程工具，生成质量会高到一个吓人的程度。你可能会问我为什么没有在规格里写“订单号规则”这类细节，因为规格的关键是约束，不是事无巨细。你把细节框得太死，AI反而没有优化空间。

4.2 一个完整流程，照着就能执行

有了规格，接下来的流程可以分五步走。

第一步是写规格。哪怕你心里已经有完整方案，也强迫自己先把规格写出来。别小看这个动作，它逼着你先思考、再编码。我在个人项目里用这种“先写规格后写码”的方式，整体返工率至少降了一半。

第二步是拆分任务。把一个大规格拆成多个小任务，每个任务独立生成一个规格片段，每个片段控制在AI单次能处理的范围。例如上面的订单创建，可以拆成“订单创建接口”“库存扣减服务”“异常处理统一化”三个子任务。任务小了，AI每个输出就更稳。

第三步是执行生成。现在主流AI编程工具都支持直接把规格粘贴进对话，让它生成代码。习惯用Agent工具的，可以让它创建文件并自测。这一步的关键是你要把规格的第六部分（验收标准）作为最终兜底，明确告诉AI“生成完需要按验收标准自测”。

第四步是验证。生成之后不做盲审，直接把验收标准转成测试用例，跑一遍。现在很多AI工具已经能帮你生成测试代码，但测试用例本身必须来自规格里的验收标准，不能是AI编的“自娱自乐”用例。

第五步是审查与迭代。把AI代码和规格一起提交，做一次人肉审查，重点看有没有超范围实现、有没有偏离约束条件。审查通过后，代码才算完成。后续任何一次迭代，都是先改规格，再让AI改代码，避免直接手改代码造成规格和代码脱节。

有人会问：“文本文档怎么运行代码？”这里顺便解答——SDD的规格本身就是一个文本文件（Markdown最合适），它不直接运行，但它描述的行为会被转成测试用例，然后在构建流水线里自动运行。也就是说，规格不是文档摆设，它是测试用例和代码生成的双重源头。如果你用的是支持自然语言转测试的工具，规格文本可以直接变成集成测试的“注释性驱动”，但更简单实用的做法是手动把验收标准转录成单元测试或集成测试。

4.3 从零开始，一个小需求全流程演示

为了把流程串得再具体一点，我演示一个“关键词过滤工具”的完整SDD过程，这个规模适合练习，指令也短。

规格写：

背景：聊天场景需要过滤敏感词，替换为*号。 需求：给定原文和敏感词列表，系统返回替换后的文本。 约束：Python 3.10+；使用pytest测试；替换规则为最长优先匹配；大小写不敏感；性能上单次调用处理1000字文本需在50ms内。 输入输出定义：

• 输入text字符串，sensitiveWords字符串列表。
• 输出替换后的字符串。
• 特殊规则说明：当多个敏感词重叠时，优先替换更长的词。 验收标准：

1. text包含敏感词时，所有敏感词都被替换为等长*号。
2. 英文大小写混合时，同样被替换。
3. 重叠场景下优先替换最长词。

粘贴给AI，生成代码和测试，跑pytest。很快就能得到一个功能完整、测试覆盖的小模块。这个例子小但五脏俱全，适合第一次尝试SDD的读者练手。关键是：整个过程你几乎没有写业务代码，你写的是描述、规则和验收标准。你干的活，远比写代码更值钱。

5. 踩坑记录：SDD实践里最常见的五个坑

5.1 规格写得太模糊或被AI“带偏”

实践SDD半年后，我发现自己最大的问题不是不会用AI，而是不会写规格。早期我写的规格经常是“做一个博客系统，支持发布文章”，这种空泛描述丢给AI，产出的东西毫无个性、到处是通用实现。

后来我把每一条需求都改成“When-Then”式描述，AI输出立刻稳定不少。比如“当用户未登录时访问发布页，系统跳转到登录页并附带来源地址参数”。这就是把模糊需求变成行为约定，AI的可执行空间瞬间收敛。

第二个坑是AI的“带偏”。有时候你明明在规格里写了“不要引入新依赖”，AI生成代码时还是自作主张import了一个第三方库，理由是“这样更高效”。这纯粹是概率惯性。解决方法是生成之后做“依赖扫描”或审查时紧盯import行，并且把“保持现有依赖集不变”写进约束部分。

5.2 规格和代码不同步，回归测试也跟着失效

AI生成代码容易，但如果你后面做了“手改代码”，规格文档就被晾在一边了。一个常见场景：AI生成代码后，你发现某个字段名不符合预期，直接改了代码。结果三个月后，产品说要调整逻辑，你翻出规格重新生成一遍，发现版本对不上了，该有字段的测试也失败了。

我的习惯是把规格文档放进项目仓库，和代码一起版本管理，让AI生成的代码注释里带上规格片段的ID，例如// spec: order-create-001。这样改动代码时，你一眼能看到这段代码对应的规格，想改代码就顺手更新规格，形成闭环。这也意味着规格不是一份“写一次就归档”的文档，它是活的，是需要持续维护的源码。

5.3 AI写测试只写快乐路径，验收标准外全是盲区

AI生成单元测试的能力不错，但它有个倾向：只写“happy path”测试，也就是正常情况的用例。异常路径、边界值、并发冲突这些几乎不会主动覆盖。如果你把验收标准写进了规格，AI生成的测试基本能覆盖验收标准里的点，但验收标准之外的隐性场景，AI不会替你操心。

于是我把验收标准细分成两层，一层是“显性验收”，直接来自规格；另一层是“隐性验收”，来自经验累积，比如超时重试、幂等、并发、极端输入。隐性验收这层，人在审查阶段必须亲自补测试或强制要求AI补充。这是很关键的一步，因为AI生成的代码执行正常场景没什么问题，但一到边界和异常场景就暴露各种隐患。

5.4 团队抗拒：习惯手写代码的人抵触“写文档”

再好的方法，推进时都会遇到团队配合问题。很多开发一听“写规格”就觉得是在写文档、走流程，产生天然抗拒。

我的经验是不要一开始就搞大团队全流程，而是找一个边缘小功能做试点，效果好了再扩大，以“省下加班时间”为诱惑推广。还有一点，规格文档不等于传统死板的需求文档，它的价值是干活时真的能当杠杆用，是不需要写一行产品PPT的“给AI的详细指令”。一旦团队成员发现改一个功能只需要改规格、再让AI跑一遍、测试就更新了，很少有人愿意回到手工改代码再手工改测试的日子。

5.5 文本规格膨胀后的检索难题

最后一个是实用问题。项目大了之后，规格文档会越来越长，很可能一个模块的规格就数百行。AI生成代码时如果把这数百行全丢给它，token消耗大，还可能让它抓不住重点。

我一般会把规格做成树形结构：根目录是README索引、一级目录按业务域划分，二级目录是具体任务规格。生成代码时只把关联任务的规格片段喂给AI，不需要全量上下文。这样既控制了token，又保持精确度。如果你用文件系统管理，每个任务建议一个独立Markdown文件，文件名用“模块-任务”命名，比如order-create.md、order-cancel.md，找起来很快。

6. 未来推演：SDD会走向哪，你现在要做什么

我肉眼可见的一个趋势是：AI编程工具会越来越接近“读规格、跑验收、交代码”的自动化执行器。现在它在代码生成上已经很强了，接下来大家会卷“从自然语言到可执行规格”的自动提取，以及“从规格到验收测试”的自动编制。到那时候，代码不只是AI写，规格也可能被AI辅助生成。那人的价值在哪？

我认为在两端。一端是需求扎根能力——你能从混沌的业务现场提取真正的用户目标，能区分“方案”和“问题”，能定义出非确认条件的复杂规则。另一端是判断力——你能判断AI自动生成的规格和代码是否符合长期目标，能识别技术债，能做出取舍。这两端，都是目前AI做不到的。这也是为什么我强烈建议现在的开发者，尽快把只盯代码的注意力，挪一部分到规格能力上。

最初用SDD时，我也会觉得“绕了一道弯，没直接写代码快”。但用了几周，我发现这个“弯”其实是在缩短返工周期。当你把要什么、边界在哪、怎样算完成都写在代码之前，AI只是你的执行者，而不是替你思考的替代品。代码被AI写了没关系，真正值钱的，始终是那个能定义问题、设计约束、验收结果的人。