说实话我入行前几年就是个典型的代码搬运工。遇到问题第一反应是去各个技术社区和代码仓库搜现成答案复制下来改吧改吧塞进项目里能跑就算成功。这种状态持续很久直到AI编程助手大规模普及我才发现自己连搬这个技能都没练明白——连自己复制的东西为什么这么写都说不清楚的人在AI面前根本没有议价能力。后来我慢慢理解了从代码搬运工到意图架构师这句话的分量在AI已经能负担绝大多数编码实现的今天开发者的真正价值正在从写代码向描述意图定义规格迁移。围绕这个转变很多人都提到一个词SDDSpecification-Driven Development规格驱动开发。网上有把它捧上神坛的也有说它是换个花样的PPT工程。这个标题留了个问号是想问AI编程的终点到底是不是SDD。我自己的答案没那么浪漫但足够务实。1. 从代码搬运工到意图架构师这个转型到底转的是什么1.1 我当代码搬运工的那几年刚入行的时候团队里有个老前辈跟我说过一句话写代码这事80%的工作是在读懂别人已经解决过的问题。当时的我深以为然。那时候没有大模型遇到一个没写过的新功能我能想到的最可靠方案就是找相似模块把关键逻辑搬出来再一层层往上补胶水代码。这种工作模式不丢人它甚至在很长一段时间内就是行业主流。但问题是搬运工模式有一个致命弱点搬运的速度永远受制于找到合适参考物的速度而搬运质量永远受制于理解原始代码意图的深度。我见过太多同事把一段适配了当时场景的代码搬进自己的系统结果因为依赖版本、业务边界、并发模型完全对不上硬是花了两天去修在原有项目中根本不会出现的怪问题。后来我才想明白那些问题不是代码的问题是我自己根本没有完成从照搬到内化的过程。AI编程工具出来后搬运工这个岗位确实受了很大冲击。以前我需要花一两个小时搜索和拼凑答案现在一句话就能生成一个看起来更完整的实现。于是大量开发者一夜之间从手动搬运升级成了AI搬运工——不是自己搬是指挥AI搬。这个阶段看起来效率高了但本质上还是在搬运只是把搜索引擎换成了对话窗口。1.2 变的是工具不变的是理解力真正刺激我思考意图架构师这个身份是一次内部项目的翻车经历。当时我负责给一个老系统接入新的通知逻辑需求本身不算复杂但牵扯到多个状态流转。我图省事直接把需求描述扔给AI帮忙生成核心模块它确实生成了一版很完整的代码接口、异常处理、日志全都有。结果一上测试环境就出问题原因是我没有在需求里说清楚只有在用户主动取消的情况下才发补偿通知AI默认按任何状态变更都发通知来实现了。这个教训让我意识到AI生成代码时非常依赖我们对输入信息的组织方式。你给它一句含混的需求它就给你一版含混的实现你给它一份有歧义的状态描述它就给你一个有歧义的逻辑分支。工具并不能替代我对业务意图的理解工具只会放大我理解中的模糊地带。所以所谓从代码搬运工到意图架构师核心不是掌握什么新技术栈而是三件事第一能把模糊的业务诉求翻译成边界清晰的规格描述第二能判断AI生成的实现是否真正满足这个规格第三能在出错时快速定位是规格的问题还是实现的问题。这三件事每一件都比单纯写一行漂亮代码要难得多。1.3 意图架构师的核心能力清单如果非要把意图架构师拆成能力清单我以为是这样的需求澄清能力面对业务方一段充满大概可能差不多的话能通过一连串提问把模糊地带逼出来。规格表达能力把澄清后的需求写成人能读懂、AI能执行、测试能验证的结构化描述。验收条件设计能力每条规格都对应明确的输入、输出和边界行为而不是一句正常返回结果。代码审查能力能识别AI生成代码里看起来对但实际不对的部分尤其是并发、事务、边界值。快速验证与回滚能力敢于尝试AI方案也随时准备退回稳妥方案不被AI的自信节奏拖着走。这五项能力里最容易被忽略的是快速验证与回滚。很多开发者把AI当成确定性工具用觉得它生成了就等于做完了。这是目前AI编程实践里最大的认知错位。它生成的是候选方案不是最终答案你的工作是把候选方案通过规格和测试快速验证成最终答案。2. 人人都提SDD我先把它说清楚2.1 SDD不等于写文档规格要可验证SDD这个概念在很多技术帖子里已经被讨论烂了但说实话大部分讨论都停留在先写文档再写代码这个层面。如果只是这样那早在三十年前的瀑布模型里就有了完全不需要AI来凑热闹。SDD在AI时代的特殊意义在于规格不再是一份给人看的仪式性文档而是一份既能驱动AI生成实现、又能驱动测试验证行为的可执行契约。一份好的规格不是单纯描述页面有个表单用户填写信息后提交而是要把行为边界写清楚哪些字段必填、哪些是可缺省、提交成功返回什么、失败返回什么、不同角色看到的内容是否一样。我在实际操作中会把这些拆成一条条验收条件每条都能独立判断通过或不通过。比如一个简单的登录功能我的规格写法大概是这样功能用户登录 前置条件用户已注册且账号未锁定 输入 账号必填长度 4-20 位 密码必填长度 8-64 位 业务规则 - 连续输错 5 次后账号锁定 30 分钟 - 锁定期间不区分密码是否正确统一提示账号已锁定 验收条件 - 账号为空时返回错误码 LOGIN_EMPTY_ACCOUNT不触发任何验证逻辑 - 密码错误且未达锁定次数时返回 LOGIN_INVALID_PASSWORD记录错误次数 - 密码错误达到 5 次时返回 LOGIN_ACCOUNT_LOCKED开始计时锁定期 - 锁定期内即使密码正确也返回 LOGIN_ACCOUNT_LOCKED - 锁定期结束后错误计数清零正确密码可正常登录这样的规格人看得懂AI生成代码时有明确边界测试用例可以直接从验收条件映射。灰度上线前拿这份规格去给测试人员看每个人都会非常清楚自己在验什么。2.2 SDD和TDD、DDD、PDD之间的关系很多朋友一听到SDD就开始纠结它和已有方法论的关系其实没必要。这些不是同一个维度的东西。TDD是测试驱动开发核心流程是先写失败测试再写让测试通过的实现它管的是微观开发节奏。DDD是领域驱动设计核心是把业务概念建模成领域模型管的是中观架构设计。PDD是提示驱动开发核心是怎么向AI提好问题管的是人与AI对话的艺术。而SDD管的是从需求到实现的契约层先定义什么是正确再去实现正确。它们可以共存甚至应该共存。我在实际项目里的组合思路是用DDD的思维梳理业务领域边界用SDD的方式把领域规则写成明确规格用PDD把规格转成AI提示再用TDD的方式让测试用例覆盖关键验收条件。SDD更像是粘合剂把传统工程能力和AI生成能力串在一起。对比起来更直观方法关注点产物在AI编程中的角色TDD微观实现测试用例验证AI生成结果DDD领域建模领域模型与边界划分AI任务范围PDD提示交互提示词模板驱动AI生成过程SDD规格契约可验收规格说明定义AI的约束所以说SDD不是取代TDD更不是取代DDD。它是在这些方法论之上补上了一层把模糊目标变得可判定的机制。没有这层机制AI生成的代码越漂亮后续返工越痛苦。2.3 为什么约束越强输出越稳在AI这里特别灵验大模型生成代码的本质是概率预测它根据上下文预测下一个最可能的token。如果上下文里只有一句帮我写个订单接口模型能选择的内容空间极其巨大方向千奇百怪。但如果你把输入参数、业务规则、异常分支、返回格式全部写清楚模型能够发挥的空间就被压缩了生成结果自然更稳定。我举一个很生活化的类比同样让一个人帮你带饭你说随便带点吃的他大概率会买回来让你意外的东西你说我要一份少辣、不要香菜、主食选米饭、价格25元以内的黄焖鸡他几乎不可能买错。AI编程也一样。它不怕你的约束多怕的是你的约束少。约束不是限制它的能力恰恰是让它把能力用在你真正想要的地方。这套逻辑放在代码生成上约束具体化还能显著减少后续的调试成本。AI生成代码后我们不是靠肉眼一行行看逻辑对不对而是拿验收条件逐条过。过不去的再反馈给它让它改。这种循环越紧凑AI的表现就越可预期。3. 一次完整的SDD实战演练把模糊需求变成可运行代码3.1 第一步先把需求从人话逼成规格我这里用一个很常见的场景举例某团队想做一个内部工单系统需求方最初的说法只有一句话就是用户能提工单然后处理人能看到并处理最好有通知功能。这句话放进AI里生成的代码大概率是能跑但没人愿意用的Demo。差距就在于中间缺少一轮又一轮的规格澄清。我习惯的做法是先把自己当成产品经理连续追问几个问题工单提交人有哪些角色处理人怎么分配工单是不是支持转派通知的触发时机是什么处理完的工单还能不能重新打开超时未处理要不要升级这些问题看起来琐碎但正是它们在决定系统的复杂度。在这个例子里我追问出来的关键规则包括提交人和处理人分属不同角色新工单进入公共队列由处理人手动认领认领后其他人不可修改超过48小时未处理的工单自动升级到管理员通知只在工单状态被处理人变更时发给提交人。这几条比一开始那句有通知功能有价值一百倍。需要注意的是追问规格的过程不能太依赖AI。AI能帮你整理已有信息但它不知道业务方内心真正想要的东西是什么。业务方说最好有通知功能他脑子里可能只是希望用户别老打电话来问进度而不是真的要一套完整的消息系统。只有通过人来追问才能把这种潜台词挖出来。3.2 第二步把规格拆成接口、数据结构和验收项需求澄清之后我会把规格拆成AI可以分块实现的任务。这里有个重要经验不要让AI一次性生成整个系统。系统层面的复杂度会让模型在局部细节上失真一次性产出一堆接口还不如逐个模块生成、逐个验证来得可靠。我会先把系统拆成几个模块工单创建模块、工单队列模块、工单处理模块、通知模块。然后对第一个模块写出详细规格包括接口定义、字段约束和验收条件。比如工单创建模块POST /api/tickets 请求参数 title 必填1-50字符 description 必填0-2000字符 priority 可选值为 low/medium/high默认 medium category 必填枚举network/permission/hardware 权限 仅登录用户可调用 响应 成功返回 201响应体包含 ticket_id、created_at、状态 statuspending 失败返回 4xx并返回对应错误码 验收条件 1. title 缺失时返回 400 TICKET_TITLE_REQUIRED 2. priority 传入非法值时不静默忽略返回 400 TICKET_PRIORITY_INVALID 3. 创建成功后工单状态必须为 pending 且自动进入公共队列 4. 创建成功后触发一条待处理事件日志这份规格我通常用Markdown或JSON格式组织好再配合一段提示词一起丢给AI。提示词的写法反过来会决定交付质量我常用的模板是指定身份与上下文粘贴规格明确输出范围要求它不实现规格之外的任何功能。3.3 第三步让AI逐模块实现并持续对照规格在模块逐块生成的时候我有一个比较稳定的循环节奏先丢规格要求AI实现指定接口。拿到代码后看一遍结构确认没有做超出规格的设计。把验收条件转成自动化测试脚本跑一遍。没通过的反馈给AI要求它对照规格修正而不是让它自由发挥。全部通过后再进入下一个模块。以工单创建模块为例AI给我的第一版实现基本能用但它自己额外加了一个防止重复提交的逻辑。这个逻辑本身不坏但规格里没有定义测试里没有覆盖客户流程里也不需要。如果不加约束后续的模块组合起来会积累大量AI自作主张带来的隐性复杂度。所以每次遇到AI主动加戏我第一步不是接受它而是回到业务流程里去问一句这个功能真的需要吗需要的话先补进规格再让它生成实现。这就是SDD比较良性的实践状态规格是源代码生成的代码只是规格的一次具体体现。修改行为、修改边界优先改规格而不是在代码里打补丁。3.4 第四步审查、测试与回写规格把所有模块实现完远没有到收工的时候。我会做一次完整的串跑验证模块之间的交互是否符合预期。这个过程最容易发现的是字段口径不一致比如创建工单模块返回的优先级字段是字符串high而处理模块读的是数字1。单看每个模块它们的实现都满足了自己的局部规格但合在一起却对不上。解决这个问题的办法是在写规格阶段就定义好全局字典和公共枚举让所有模块共用同一份定义。串跑发现问题后也不是偷偷改代码了事而是回头更新规格文档把这次交互约定固化下来。这样后续如果再用AI重构某个模块不会把当初的方案给弄丢。测试在这个环节的价值怎么强调都不为过。没有测试兜底的AI生成代码就像没有试驾就上高速的车。我现在要求团队里每一个由AI产出的模块都必须至少覆盖验收条件里列出的正常路径和异常分支。测试不是用来证明AI写得好而是用来证明我们对需求的理解没有跑偏。4. 哪些环节AI真的靠谱哪些环节是变相挖坑4.1 AI生成代码的信任边界使用AI编程一段时间后我对不同代码类型的信任等级有了很清晰的划分。这不是拍脑袋说某类功能AI一定靠谱而是基于概率推理AI在训练语料里见过的内容越多、模式越固定生成结果就越稳。反之特定业务规则越强、历史数据越少出错概率就越大。我整理了一张实操参考表代码类型信任程度说明增删改查接口高模式高度一致验收条件容易定义数据模型与字段映射高输入输出清晰容易用测试验证权限与状态机中逻辑分支多必须显式覆盖每个分支并发与事务边界低隐蔽问题多AI容易写出看起来对的错误代码性能敏感代码低需要基准测试和压力测试支撑安全相关逻辑低必须独立人工审核不能直接采信所以我的原则是AI适合承担确定性强的编码工作人可以专注在定义约束和审查结果上。越是听起来很专业、很难验证的代码越不能因为AI写起来流畅就放松警惕。尤其是权限校验、支付金额计算、数据导出这类逻辑我建议无论AI生成得多完整都要有人逐行人工过一遍。4.2 适合SDD的典型场景和应该避开的雷区从场景类型来看SDD在以下几个方向特别合用内部管理系统业务流程明确但技术含量不高的表单、列表接口整合层多个系统之间做标准化对接遗留系统维护老逻辑重构但要保持行为不变。这些场景有一个共同点行为可以被精确描述验收条件可以被测试覆盖。反过来有几个场景我不建议直接上SDD。比如探索型产品需求连用户要不要这个功能都不确定这时候写详细规格其实是浪费再比如强实时系统性能才是核心约束光有功能规格远远不够必须搭配压测与性能分析还有数据密集型处理AI生成的核心算法往往不够优化不是规格不好写而是规格写清楚了也不保证实现足够好。这里还有个大坑必须提醒别让AI帮你写所有可能情况都考虑到的规格。规格的价值在于精确定义业务需要的边界而不是穷举宇宙所有分支。规格写得太庞大AI生成时会迷失重点人审查时也会疲劳反而不如小步拆分来得稳。4.3 团队落地SDD时最大的阻碍往往不是技术如果说个人实践SDD靠的是自律那团队落地SDD考验的就是协作契约。我在推进过程中遇到的最大阻力不是AI生成代码质量不行而是团队认知不统一。有人觉得写规格是浪费时间直接让AI生成多快有人则觉得AI写的代码都不能信宁可自己手写。这两类人对AI的态度完全相反但底层问题一致都没有建立规格-实现-验证的分工意识。前者省略了规格验证环节用AI的速度掩盖了返工成本后者不相信AI能生成任何有价值代码把人工时间浪费在重复性实现上。团队要落地SDD第一步其实是统一所有人对代码从哪来的预期。我比较推荐的做法是设置一个过渡期头两周只挑低风险模块跑SDD流程大家拿到规格模板和验收清单后先磨合默契再逐步扩展到核心模块。同时让经验丰富的同事专门负责规格评审让初级工程师多做执行和验证这比让每个人都从头摸索要高效得多。落地过程中的产出物不用一次做到完美先把规格文档测试清单这个最小闭环跑通后面迭代优化都有抓手。5. 踩坑实录意图在传递中是怎么一步步丢失的5.1 案例A一条伪需求引发了八次实现偏差有一段时间团队里反馈用户总收不到工单处理结果。听起来像通知模块坏了于是我把通知相关的规格列出来让AI检查代码。结果AI查了三轮结论都是实现逻辑没问题。后来我亲自翻用户反馈才发现用户真正说的收不到结果不是通知没发出去而是通知内容里只写了工单已处理没说处理结果到底是什么。用户打开工单才能看到处理内容但对很多用户来说他压根就不想再打开系统他要的是在通知里直接看到结论。问题根源是我最初定义的规格是状态变更时发送通知而不是状态变更时发送处理结论摘要。AI完全按规格实现了但因为这个规格本身没有对齐真实意图所有下游工作都白做了。这个坑给我留下的教训是写规格之前一定要先确认问题场景是不是真问题场景否则规格描述得越精确返工的时候越狼狈。现在我在规格文档的头部都会加一段背景驱动场景写清楚这个功能是为了解决谁在什么情境下的什么痛点。这样AI虽然不直接依赖这段背景生成代码但它会约束我和业务方在后续讨论中别跑偏。5.2 案例BAI在一处过度自信的实现里埋了雷还有一次我让AI为一个工单分配逻辑补充认领功能。规格里明确写了认领后的工单他人不可操作但AI生成的代码在主流程里做得很到位却在列表查询接口里漏掉了这个约束任何处理人仍然能看到被认领工单的详情甚至能调用后续处理接口。这种问题不是功能不可用而是权限边界被静默突破了。这类问题最麻烦的地方在于单看代码结构它非常工整甚至有一堆防御性校验。但它只是在自己看到的局部路径里进行了防御对整体权限上下文的理解完全缺失。所以我对AI生成代码的审查从来不会只看它有没有处理主要分支而是专门盯谁能在什么条件下执行这个操作这类横向规则。横向规则是AI最容易漏掉的因为它往往不体现在单个函数里而是分散在多个模块之间。这个案例之后我在规格模板中增加了权限与状态约束独立段落并且要求测试用例专门覆盖非授权访问这些负面路径。如果没有测试这种隐性漏洞可能会一直躺在生产环境里直到某一天被异常行为触发。5.3 补救链路规格-验收-测试三层兜底从上面两个案例能看出AI编程翻车并不总发生在代码编写阶段更多是发生在需求理解阶段、规则定义阶段和验证覆盖阶段。所以我后来的补救策略从来不是单点修复而是三层兜底第一层是规格兜底每次需求澄清时至少问三轮如果……会怎样把边界条件和异常分支固化进规格。第二层是验收兜底每次AI生成完成后拿验收条件清单逐条过宁可多写了测试也不放过一条我觉得应该没问题的路径。第三层是测试兜底用自动化测试把验收条件变成回归保护这样后续每次让AI改功能都能快速发现新改动是否破坏了旧行为。这套三层防线建立起来之后我对AI编程的信任度反而大幅提升了。因为我已经不依赖AI自己保证正确性而是依赖自己的规格体系和测试体系来兜底。AI生成代码只是流水线上的一环它出错我有能力及时发现并修正它不出错整个流程也能跑得飞快。5.4 开发者的自我保护习惯再分享几个我现在已经形成条件反射的习惯。第一AI给出的代码绝不直接粘贴必须先看一遍结构尤其是函数入口和出口。第二任何涉及状态流转的改动都要画一张简化的状态图放到规格文档里哪怕AI已经指定了状态枚举我仍会自己再过一遍完整链路。第三每个AI生成的模块都要有最小可运行验证绝不能攒了一堆模块到最后再串跑那样定位问题成本会爆炸式上升。这些习惯看起来琐碎但它们就是把使用AI从娱乐项目变成工程生产力的分水岭。AI编程时代开发者真正的护城河不是谁能更熟练地使用提示词而是谁能建立一套让AI输出快速被验证和约束的工程体系。6. AI编程的终点真的写在SDD那里吗6.1 可能的终局形态规格与实现不再是两个阶段回到标题那个问号AI编程的终点是SDD吗如果SDD指的是永远靠人手工写详细规格再让AI去实现那它大概率只是过渡态不可能是终点。因为用户最终不会满足于还要亲手动笔写规格他们会希望用更自然的表达让系统自己生成规格、生成执行计划、再生成代码。我理解的终局形态是规格与实现之间的边界变得模糊系统能自动从一段模糊意图里提取出可验证的规格然后在这个规格的约束下生成实现并自我验证是否符合规格。到那个阶段写规格和写代码都变成了系统内部的过程人只需要做两件事提出真正的意图以及在关键节点上确认系统是否朝着自己想要的方向走。这并不意味着SDD这个思路会消失恰恰相反SDD的核心原则会被吸收进系统里。因为不管AI怎么进化它本质上仍然需要约束和验证只不过约束从手写文档变成了自动推导验证从人工测试变成了内置机制。所以更准确地说SDD不是AI编程的终点而是它走向终点的必要基础设施。6.2 我的个人判断与给不同阶段开发者的建议基于我目前的实践经验我觉得现在是时候主动完成从代码搬运工到意图架构师的心态转变了。初级开发者不要被AI会取代程序员这种话吓到但要清醒地认识到如果你只会写代码不关心业务边界、不设计验收条件、不建立验证体系那你的技能确实很容易被AI替代。反过来如果你能从需求中提炼出清晰规格能设计出可验证的方案AI对你来说就是放大生产力的利器。给不同阶段的伙伴一点实际建议刚入行一两年的人与其花时间研究五花八门的提示词技巧不如先把手头每个模块的规格写清楚这比多写几百行代码更有价值。工作三五年的人重心可以放在如何把规格拆成AI能逐步执行的粒度以及如何设计测试来防住AI的常见幻觉。带团队的人建议先把团队的规格模板和验收清单标准化这比催大家多用AI、用得狠靠谱得多。说到底AI编程时代的开发工作会越来越像一种高杠杆的谈判你要清楚地知道自己要去哪里然后用规格和验证机制确保AI每一次发力都不偏航。这不是贬低技术能力而是把技术能力从手动实现上升到系统设计的位置。我自己现在的日常已经很少逐行敲业务代码了。更多的时间花在和需求方反复确认边界、把模糊想法变成可执行的规格清单、以及盯着测试报告看有没有意外。偶尔会有人质疑说你这不是变成写文档的了吗我的回答是如果一个开发者做的事情居然让一个概率模型来替他完成那这些事情本来就不该是他的核心竞争力。真正的核心竞争力永远在于你比模型更清楚什么样的结果才是对的。
说实话我入行前几年就是个典型的代码搬运工。遇到问题第一反应是去各个技术社区和代码仓库搜现成答案复制下来改吧改吧塞进项目里能跑就算成功。这种状态持续很久直到AI编程助手大规模普及我才发现自己连搬这个技能都没练明白——连自己复制的东西为什么这么写都说不清楚的人在AI面前根本没有议价能力。后来我慢慢理解了从代码搬运工到意图架构师这句话的分量在AI已经能负担绝大多数编码实现的今天开发者的真正价值正在从写代码向描述意图定义规格迁移。围绕这个转变很多人都提到一个词SDDSpecification-Driven Development规格驱动开发。网上有把它捧上神坛的也有说它是换个花样的PPT工程。这个标题留了个问号是想问AI编程的终点到底是不是SDD。我自己的答案没那么浪漫但足够务实。1. 从代码搬运工到意图架构师这个转型到底转的是什么1.1 我当代码搬运工的那几年刚入行的时候团队里有个老前辈跟我说过一句话写代码这事80%的工作是在读懂别人已经解决过的问题。当时的我深以为然。那时候没有大模型遇到一个没写过的新功能我能想到的最可靠方案就是找相似模块把关键逻辑搬出来再一层层往上补胶水代码。这种工作模式不丢人它甚至在很长一段时间内就是行业主流。但问题是搬运工模式有一个致命弱点搬运的速度永远受制于找到合适参考物的速度而搬运质量永远受制于理解原始代码意图的深度。我见过太多同事把一段适配了当时场景的代码搬进自己的系统结果因为依赖版本、业务边界、并发模型完全对不上硬是花了两天去修在原有项目中根本不会出现的怪问题。后来我才想明白那些问题不是代码的问题是我自己根本没有完成从照搬到内化的过程。AI编程工具出来后搬运工这个岗位确实受了很大冲击。以前我需要花一两个小时搜索和拼凑答案现在一句话就能生成一个看起来更完整的实现。于是大量开发者一夜之间从手动搬运升级成了AI搬运工——不是自己搬是指挥AI搬。这个阶段看起来效率高了但本质上还是在搬运只是把搜索引擎换成了对话窗口。1.2 变的是工具不变的是理解力真正刺激我思考意图架构师这个身份是一次内部项目的翻车经历。当时我负责给一个老系统接入新的通知逻辑需求本身不算复杂但牵扯到多个状态流转。我图省事直接把需求描述扔给AI帮忙生成核心模块它确实生成了一版很完整的代码接口、异常处理、日志全都有。结果一上测试环境就出问题原因是我没有在需求里说清楚只有在用户主动取消的情况下才发补偿通知AI默认按任何状态变更都发通知来实现了。这个教训让我意识到AI生成代码时非常依赖我们对输入信息的组织方式。你给它一句含混的需求它就给你一版含混的实现你给它一份有歧义的状态描述它就给你一个有歧义的逻辑分支。工具并不能替代我对业务意图的理解工具只会放大我理解中的模糊地带。所以所谓从代码搬运工到意图架构师核心不是掌握什么新技术栈而是三件事第一能把模糊的业务诉求翻译成边界清晰的规格描述第二能判断AI生成的实现是否真正满足这个规格第三能在出错时快速定位是规格的问题还是实现的问题。这三件事每一件都比单纯写一行漂亮代码要难得多。1.3 意图架构师的核心能力清单如果非要把意图架构师拆成能力清单我以为是这样的需求澄清能力面对业务方一段充满大概可能差不多的话能通过一连串提问把模糊地带逼出来。规格表达能力把澄清后的需求写成人能读懂、AI能执行、测试能验证的结构化描述。验收条件设计能力每条规格都对应明确的输入、输出和边界行为而不是一句正常返回结果。代码审查能力能识别AI生成代码里看起来对但实际不对的部分尤其是并发、事务、边界值。快速验证与回滚能力敢于尝试AI方案也随时准备退回稳妥方案不被AI的自信节奏拖着走。这五项能力里最容易被忽略的是快速验证与回滚。很多开发者把AI当成确定性工具用觉得它生成了就等于做完了。这是目前AI编程实践里最大的认知错位。它生成的是候选方案不是最终答案你的工作是把候选方案通过规格和测试快速验证成最终答案。2. 人人都提SDD我先把它说清楚2.1 SDD不等于写文档规格要可验证SDD这个概念在很多技术帖子里已经被讨论烂了但说实话大部分讨论都停留在先写文档再写代码这个层面。如果只是这样那早在三十年前的瀑布模型里就有了完全不需要AI来凑热闹。SDD在AI时代的特殊意义在于规格不再是一份给人看的仪式性文档而是一份既能驱动AI生成实现、又能驱动测试验证行为的可执行契约。一份好的规格不是单纯描述页面有个表单用户填写信息后提交而是要把行为边界写清楚哪些字段必填、哪些是可缺省、提交成功返回什么、失败返回什么、不同角色看到的内容是否一样。我在实际操作中会把这些拆成一条条验收条件每条都能独立判断通过或不通过。比如一个简单的登录功能我的规格写法大概是这样功能用户登录 前置条件用户已注册且账号未锁定 输入 账号必填长度 4-20 位 密码必填长度 8-64 位 业务规则 - 连续输错 5 次后账号锁定 30 分钟 - 锁定期间不区分密码是否正确统一提示账号已锁定 验收条件 - 账号为空时返回错误码 LOGIN_EMPTY_ACCOUNT不触发任何验证逻辑 - 密码错误且未达锁定次数时返回 LOGIN_INVALID_PASSWORD记录错误次数 - 密码错误达到 5 次时返回 LOGIN_ACCOUNT_LOCKED开始计时锁定期 - 锁定期内即使密码正确也返回 LOGIN_ACCOUNT_LOCKED - 锁定期结束后错误计数清零正确密码可正常登录这样的规格人看得懂AI生成代码时有明确边界测试用例可以直接从验收条件映射。灰度上线前拿这份规格去给测试人员看每个人都会非常清楚自己在验什么。2.2 SDD和TDD、DDD、PDD之间的关系很多朋友一听到SDD就开始纠结它和已有方法论的关系其实没必要。这些不是同一个维度的东西。TDD是测试驱动开发核心流程是先写失败测试再写让测试通过的实现它管的是微观开发节奏。DDD是领域驱动设计核心是把业务概念建模成领域模型管的是中观架构设计。PDD是提示驱动开发核心是怎么向AI提好问题管的是人与AI对话的艺术。而SDD管的是从需求到实现的契约层先定义什么是正确再去实现正确。它们可以共存甚至应该共存。我在实际项目里的组合思路是用DDD的思维梳理业务领域边界用SDD的方式把领域规则写成明确规格用PDD把规格转成AI提示再用TDD的方式让测试用例覆盖关键验收条件。SDD更像是粘合剂把传统工程能力和AI生成能力串在一起。对比起来更直观方法关注点产物在AI编程中的角色TDD微观实现测试用例验证AI生成结果DDD领域建模领域模型与边界划分AI任务范围PDD提示交互提示词模板驱动AI生成过程SDD规格契约可验收规格说明定义AI的约束所以说SDD不是取代TDD更不是取代DDD。它是在这些方法论之上补上了一层把模糊目标变得可判定的机制。没有这层机制AI生成的代码越漂亮后续返工越痛苦。2.3 为什么约束越强输出越稳在AI这里特别灵验大模型生成代码的本质是概率预测它根据上下文预测下一个最可能的token。如果上下文里只有一句帮我写个订单接口模型能选择的内容空间极其巨大方向千奇百怪。但如果你把输入参数、业务规则、异常分支、返回格式全部写清楚模型能够发挥的空间就被压缩了生成结果自然更稳定。我举一个很生活化的类比同样让一个人帮你带饭你说随便带点吃的他大概率会买回来让你意外的东西你说我要一份少辣、不要香菜、主食选米饭、价格25元以内的黄焖鸡他几乎不可能买错。AI编程也一样。它不怕你的约束多怕的是你的约束少。约束不是限制它的能力恰恰是让它把能力用在你真正想要的地方。这套逻辑放在代码生成上约束具体化还能显著减少后续的调试成本。AI生成代码后我们不是靠肉眼一行行看逻辑对不对而是拿验收条件逐条过。过不去的再反馈给它让它改。这种循环越紧凑AI的表现就越可预期。3. 一次完整的SDD实战演练把模糊需求变成可运行代码3.1 第一步先把需求从人话逼成规格我这里用一个很常见的场景举例某团队想做一个内部工单系统需求方最初的说法只有一句话就是用户能提工单然后处理人能看到并处理最好有通知功能。这句话放进AI里生成的代码大概率是能跑但没人愿意用的Demo。差距就在于中间缺少一轮又一轮的规格澄清。我习惯的做法是先把自己当成产品经理连续追问几个问题工单提交人有哪些角色处理人怎么分配工单是不是支持转派通知的触发时机是什么处理完的工单还能不能重新打开超时未处理要不要升级这些问题看起来琐碎但正是它们在决定系统的复杂度。在这个例子里我追问出来的关键规则包括提交人和处理人分属不同角色新工单进入公共队列由处理人手动认领认领后其他人不可修改超过48小时未处理的工单自动升级到管理员通知只在工单状态被处理人变更时发给提交人。这几条比一开始那句有通知功能有价值一百倍。需要注意的是追问规格的过程不能太依赖AI。AI能帮你整理已有信息但它不知道业务方内心真正想要的东西是什么。业务方说最好有通知功能他脑子里可能只是希望用户别老打电话来问进度而不是真的要一套完整的消息系统。只有通过人来追问才能把这种潜台词挖出来。3.2 第二步把规格拆成接口、数据结构和验收项需求澄清之后我会把规格拆成AI可以分块实现的任务。这里有个重要经验不要让AI一次性生成整个系统。系统层面的复杂度会让模型在局部细节上失真一次性产出一堆接口还不如逐个模块生成、逐个验证来得可靠。我会先把系统拆成几个模块工单创建模块、工单队列模块、工单处理模块、通知模块。然后对第一个模块写出详细规格包括接口定义、字段约束和验收条件。比如工单创建模块POST /api/tickets 请求参数 title 必填1-50字符 description 必填0-2000字符 priority 可选值为 low/medium/high默认 medium category 必填枚举network/permission/hardware 权限 仅登录用户可调用 响应 成功返回 201响应体包含 ticket_id、created_at、状态 statuspending 失败返回 4xx并返回对应错误码 验收条件 1. title 缺失时返回 400 TICKET_TITLE_REQUIRED 2. priority 传入非法值时不静默忽略返回 400 TICKET_PRIORITY_INVALID 3. 创建成功后工单状态必须为 pending 且自动进入公共队列 4. 创建成功后触发一条待处理事件日志这份规格我通常用Markdown或JSON格式组织好再配合一段提示词一起丢给AI。提示词的写法反过来会决定交付质量我常用的模板是指定身份与上下文粘贴规格明确输出范围要求它不实现规格之外的任何功能。3.3 第三步让AI逐模块实现并持续对照规格在模块逐块生成的时候我有一个比较稳定的循环节奏先丢规格要求AI实现指定接口。拿到代码后看一遍结构确认没有做超出规格的设计。把验收条件转成自动化测试脚本跑一遍。没通过的反馈给AI要求它对照规格修正而不是让它自由发挥。全部通过后再进入下一个模块。以工单创建模块为例AI给我的第一版实现基本能用但它自己额外加了一个防止重复提交的逻辑。这个逻辑本身不坏但规格里没有定义测试里没有覆盖客户流程里也不需要。如果不加约束后续的模块组合起来会积累大量AI自作主张带来的隐性复杂度。所以每次遇到AI主动加戏我第一步不是接受它而是回到业务流程里去问一句这个功能真的需要吗需要的话先补进规格再让它生成实现。这就是SDD比较良性的实践状态规格是源代码生成的代码只是规格的一次具体体现。修改行为、修改边界优先改规格而不是在代码里打补丁。3.4 第四步审查、测试与回写规格把所有模块实现完远没有到收工的时候。我会做一次完整的串跑验证模块之间的交互是否符合预期。这个过程最容易发现的是字段口径不一致比如创建工单模块返回的优先级字段是字符串high而处理模块读的是数字1。单看每个模块它们的实现都满足了自己的局部规格但合在一起却对不上。解决这个问题的办法是在写规格阶段就定义好全局字典和公共枚举让所有模块共用同一份定义。串跑发现问题后也不是偷偷改代码了事而是回头更新规格文档把这次交互约定固化下来。这样后续如果再用AI重构某个模块不会把当初的方案给弄丢。测试在这个环节的价值怎么强调都不为过。没有测试兜底的AI生成代码就像没有试驾就上高速的车。我现在要求团队里每一个由AI产出的模块都必须至少覆盖验收条件里列出的正常路径和异常分支。测试不是用来证明AI写得好而是用来证明我们对需求的理解没有跑偏。4. 哪些环节AI真的靠谱哪些环节是变相挖坑4.1 AI生成代码的信任边界使用AI编程一段时间后我对不同代码类型的信任等级有了很清晰的划分。这不是拍脑袋说某类功能AI一定靠谱而是基于概率推理AI在训练语料里见过的内容越多、模式越固定生成结果就越稳。反之特定业务规则越强、历史数据越少出错概率就越大。我整理了一张实操参考表代码类型信任程度说明增删改查接口高模式高度一致验收条件容易定义数据模型与字段映射高输入输出清晰容易用测试验证权限与状态机中逻辑分支多必须显式覆盖每个分支并发与事务边界低隐蔽问题多AI容易写出看起来对的错误代码性能敏感代码低需要基准测试和压力测试支撑安全相关逻辑低必须独立人工审核不能直接采信所以我的原则是AI适合承担确定性强的编码工作人可以专注在定义约束和审查结果上。越是听起来很专业、很难验证的代码越不能因为AI写起来流畅就放松警惕。尤其是权限校验、支付金额计算、数据导出这类逻辑我建议无论AI生成得多完整都要有人逐行人工过一遍。4.2 适合SDD的典型场景和应该避开的雷区从场景类型来看SDD在以下几个方向特别合用内部管理系统业务流程明确但技术含量不高的表单、列表接口整合层多个系统之间做标准化对接遗留系统维护老逻辑重构但要保持行为不变。这些场景有一个共同点行为可以被精确描述验收条件可以被测试覆盖。反过来有几个场景我不建议直接上SDD。比如探索型产品需求连用户要不要这个功能都不确定这时候写详细规格其实是浪费再比如强实时系统性能才是核心约束光有功能规格远远不够必须搭配压测与性能分析还有数据密集型处理AI生成的核心算法往往不够优化不是规格不好写而是规格写清楚了也不保证实现足够好。这里还有个大坑必须提醒别让AI帮你写所有可能情况都考虑到的规格。规格的价值在于精确定义业务需要的边界而不是穷举宇宙所有分支。规格写得太庞大AI生成时会迷失重点人审查时也会疲劳反而不如小步拆分来得稳。4.3 团队落地SDD时最大的阻碍往往不是技术如果说个人实践SDD靠的是自律那团队落地SDD考验的就是协作契约。我在推进过程中遇到的最大阻力不是AI生成代码质量不行而是团队认知不统一。有人觉得写规格是浪费时间直接让AI生成多快有人则觉得AI写的代码都不能信宁可自己手写。这两类人对AI的态度完全相反但底层问题一致都没有建立规格-实现-验证的分工意识。前者省略了规格验证环节用AI的速度掩盖了返工成本后者不相信AI能生成任何有价值代码把人工时间浪费在重复性实现上。团队要落地SDD第一步其实是统一所有人对代码从哪来的预期。我比较推荐的做法是设置一个过渡期头两周只挑低风险模块跑SDD流程大家拿到规格模板和验收清单后先磨合默契再逐步扩展到核心模块。同时让经验丰富的同事专门负责规格评审让初级工程师多做执行和验证这比让每个人都从头摸索要高效得多。落地过程中的产出物不用一次做到完美先把规格文档测试清单这个最小闭环跑通后面迭代优化都有抓手。5. 踩坑实录意图在传递中是怎么一步步丢失的5.1 案例A一条伪需求引发了八次实现偏差有一段时间团队里反馈用户总收不到工单处理结果。听起来像通知模块坏了于是我把通知相关的规格列出来让AI检查代码。结果AI查了三轮结论都是实现逻辑没问题。后来我亲自翻用户反馈才发现用户真正说的收不到结果不是通知没发出去而是通知内容里只写了工单已处理没说处理结果到底是什么。用户打开工单才能看到处理内容但对很多用户来说他压根就不想再打开系统他要的是在通知里直接看到结论。问题根源是我最初定义的规格是状态变更时发送通知而不是状态变更时发送处理结论摘要。AI完全按规格实现了但因为这个规格本身没有对齐真实意图所有下游工作都白做了。这个坑给我留下的教训是写规格之前一定要先确认问题场景是不是真问题场景否则规格描述得越精确返工的时候越狼狈。现在我在规格文档的头部都会加一段背景驱动场景写清楚这个功能是为了解决谁在什么情境下的什么痛点。这样AI虽然不直接依赖这段背景生成代码但它会约束我和业务方在后续讨论中别跑偏。5.2 案例BAI在一处过度自信的实现里埋了雷还有一次我让AI为一个工单分配逻辑补充认领功能。规格里明确写了认领后的工单他人不可操作但AI生成的代码在主流程里做得很到位却在列表查询接口里漏掉了这个约束任何处理人仍然能看到被认领工单的详情甚至能调用后续处理接口。这种问题不是功能不可用而是权限边界被静默突破了。这类问题最麻烦的地方在于单看代码结构它非常工整甚至有一堆防御性校验。但它只是在自己看到的局部路径里进行了防御对整体权限上下文的理解完全缺失。所以我对AI生成代码的审查从来不会只看它有没有处理主要分支而是专门盯谁能在什么条件下执行这个操作这类横向规则。横向规则是AI最容易漏掉的因为它往往不体现在单个函数里而是分散在多个模块之间。这个案例之后我在规格模板中增加了权限与状态约束独立段落并且要求测试用例专门覆盖非授权访问这些负面路径。如果没有测试这种隐性漏洞可能会一直躺在生产环境里直到某一天被异常行为触发。5.3 补救链路规格-验收-测试三层兜底从上面两个案例能看出AI编程翻车并不总发生在代码编写阶段更多是发生在需求理解阶段、规则定义阶段和验证覆盖阶段。所以我后来的补救策略从来不是单点修复而是三层兜底第一层是规格兜底每次需求澄清时至少问三轮如果……会怎样把边界条件和异常分支固化进规格。第二层是验收兜底每次AI生成完成后拿验收条件清单逐条过宁可多写了测试也不放过一条我觉得应该没问题的路径。第三层是测试兜底用自动化测试把验收条件变成回归保护这样后续每次让AI改功能都能快速发现新改动是否破坏了旧行为。这套三层防线建立起来之后我对AI编程的信任度反而大幅提升了。因为我已经不依赖AI自己保证正确性而是依赖自己的规格体系和测试体系来兜底。AI生成代码只是流水线上的一环它出错我有能力及时发现并修正它不出错整个流程也能跑得飞快。5.4 开发者的自我保护习惯再分享几个我现在已经形成条件反射的习惯。第一AI给出的代码绝不直接粘贴必须先看一遍结构尤其是函数入口和出口。第二任何涉及状态流转的改动都要画一张简化的状态图放到规格文档里哪怕AI已经指定了状态枚举我仍会自己再过一遍完整链路。第三每个AI生成的模块都要有最小可运行验证绝不能攒了一堆模块到最后再串跑那样定位问题成本会爆炸式上升。这些习惯看起来琐碎但它们就是把使用AI从娱乐项目变成工程生产力的分水岭。AI编程时代开发者真正的护城河不是谁能更熟练地使用提示词而是谁能建立一套让AI输出快速被验证和约束的工程体系。6. AI编程的终点真的写在SDD那里吗6.1 可能的终局形态规格与实现不再是两个阶段回到标题那个问号AI编程的终点是SDD吗如果SDD指的是永远靠人手工写详细规格再让AI去实现那它大概率只是过渡态不可能是终点。因为用户最终不会满足于还要亲手动笔写规格他们会希望用更自然的表达让系统自己生成规格、生成执行计划、再生成代码。我理解的终局形态是规格与实现之间的边界变得模糊系统能自动从一段模糊意图里提取出可验证的规格然后在这个规格的约束下生成实现并自我验证是否符合规格。到那个阶段写规格和写代码都变成了系统内部的过程人只需要做两件事提出真正的意图以及在关键节点上确认系统是否朝着自己想要的方向走。这并不意味着SDD这个思路会消失恰恰相反SDD的核心原则会被吸收进系统里。因为不管AI怎么进化它本质上仍然需要约束和验证只不过约束从手写文档变成了自动推导验证从人工测试变成了内置机制。所以更准确地说SDD不是AI编程的终点而是它走向终点的必要基础设施。6.2 我的个人判断与给不同阶段开发者的建议基于我目前的实践经验我觉得现在是时候主动完成从代码搬运工到意图架构师的心态转变了。初级开发者不要被AI会取代程序员这种话吓到但要清醒地认识到如果你只会写代码不关心业务边界、不设计验收条件、不建立验证体系那你的技能确实很容易被AI替代。反过来如果你能从需求中提炼出清晰规格能设计出可验证的方案AI对你来说就是放大生产力的利器。给不同阶段的伙伴一点实际建议刚入行一两年的人与其花时间研究五花八门的提示词技巧不如先把手头每个模块的规格写清楚这比多写几百行代码更有价值。工作三五年的人重心可以放在如何把规格拆成AI能逐步执行的粒度以及如何设计测试来防住AI的常见幻觉。带团队的人建议先把团队的规格模板和验收清单标准化这比催大家多用AI、用得狠靠谱得多。说到底AI编程时代的开发工作会越来越像一种高杠杆的谈判你要清楚地知道自己要去哪里然后用规格和验证机制确保AI每一次发力都不偏航。这不是贬低技术能力而是把技术能力从手动实现上升到系统设计的位置。我自己现在的日常已经很少逐行敲业务代码了。更多的时间花在和需求方反复确认边界、把模糊想法变成可执行的规格清单、以及盯着测试报告看有没有意外。偶尔会有人质疑说你这不是变成写文档的了吗我的回答是如果一个开发者做的事情居然让一个概率模型来替他完成那这些事情本来就不该是他的核心竞争力。真正的核心竞争力永远在于你比模型更清楚什么样的结果才是对的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
