代码都被AI写了那人干什么SDD超级干货这两年“AI写代码”从段子变成了日常。我身边不少团队已经默认能交给AI生成的基础代码绝不让工程师手写。于是很多人在问同一个问题——代码都被AI写了那人干什么这个问题听起来像焦虑实际上是机会。真正的问题不是“人要不要写代码”而是“人怎么组织AI写代码”。今天想聊的SDDSpecification-Driven Development规格驱动开发就是我对这个问题的答案。这套东西在个人项目和团队协作里都试过适合正在用AI编程工具但觉得产出质量不稳定的人也适合管理者——想让大家从“手写模式”切到“指挥模式”却不知道从哪下手。我先把SDD的底层逻辑讲透再把能直接复用的规格模板和实操流程铺开。1. 代码确实在被AI改写但AI的“会写”撑不起“能用”1.1 从补全到AgentAI编程实际走到了哪个阶段先看清现实。现在的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的内涵变了。因为它不再需要你写一套、人再翻译成一套而是直接把规格交给AIAI负责整个“翻译成代码”的过程。规格成了唯一需要人深度维护的东西代码是由规格生成出来的产物。这个变化让SDD从“重流程”变成了“高杠杆”。我的理解是把SDD底层逻辑凝练成一句大白话——你要什么、满足什么条件、为什么这么做这些必须写在代码之前AI承担“怎么做”人承担“是什么”和“为什么”。它真正回答的是那个标题里的问题代码被AI写了人干什么人干最核心的活干AI最不擅长的活干事情定义和结果验收的活。2.2 传统开发、普通AI辅助开发、SDD开发差在哪我做了一张对照表能直观看出三者核心差异维度传统开发普通AI辅助开发SDD开发需求来源口头沟通、零散文档口头描述直接问AI结构化规格文档人花时间最多的事写代码、改Bug不断调提示词、试错写规格、验验收条件代码质量依赖程序员个人能力AI模型的运气规格的清晰度边界约束靠代码走查发现靠报错和返工发现规格里直接写清回归验证手动测试或补测试经常忽略规格驱动测试用例可追溯性较弱几乎没有从需求到代码全程可追传统开发的问题是“人脑翻译”成本太高需求到设计、设计到代码的每一步都是损耗最后写出来的东西和用户要的经常两回事。普通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分钟未支付则自动释放。验收标准当购物车包含三种商品且库存足够时系统创建一笔含三个商品项的订单并返回支付金额。当任一SKU库存不足时系统返回INSUFFICIENT_STOCK不创建订单、不扣减任何库存。当请求包含无效地址时系统返回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字符串列表。输出替换后的字符串。特殊规则说明当多个敏感词重叠时优先替换更长的词。 验收标准text包含敏感词时所有敏感词都被替换为等长*号。英文大小写混合时同样被替换。重叠场景下优先替换最长词。粘贴给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写了没关系真正值钱的始终是那个能定义问题、设计约束、验收结果的人。