这两年只要聊到 AI 辅助编程大家第一反应都是“提效神器”但真放进项目里跑一轮翻车的概率其实一点不低。我见过最典型的场景一个需求下来直接把上下文丢给大模型让它从零写整个模块结果代码表面看着能跑一上 Code Review 就发现命名混乱、边界条件全没处理、跟现有框架规范对不上改起来比手写还费劲。这不是模型能力不行而是工作方法没跟上。AI 编程早就不是“会不会用提示词”的问题而是怎么把一个模糊的开发任务拆成 AI 能稳定发挥、人能有效把关的一连串阶段化动作的问题。这篇文章要讲的就是我在实际项目中反复打磨出来的一套AI 辅助编程阶段化开发 SOP。它不依赖某个特定工具不绑定具体语言核心是把一次“让 AI 写代码”变成五段可控流程需求澄清、方案设计、编码实现、测试补全、重构收尾。每一段都有明确的输入、动作、产出和验收标准。适合刚接触 AI 编程、正在为“生成的代码不敢合入”发愁的个人开发者也适合想在公司内部统一 AI 使用姿势、降低代码返工率的技术负责人。照着这套流程走AI 生成代码的合入率会明显提升你也能从“帮 AI 擦屁股”里解放出来。1. 为什么需要“阶段化开发 SOP”1.1 一次失败的 AI 写码经历先说一个真实案例。之前我负责一个内部数据看板项目需要新增一个“按部门汇总工单耗时”的接口。需求很简单我当时的做法也很粗暴把现有 Service 层代码粘给 AI附加一句“帮我写一个按部门分组的统计接口返回耗时均值和中位数”然后回车。AI 三秒钟给了一段看起来非常完整的实现有 SQL、有 DTO、有 Service 方法甚至帮我补了单元测试。我眼睛一扫觉得没问题合入代码结果联调时出了两个事第一它把时间字段的时区硬编码成了 UTC而项目里一直用的是东八区第二它的 SQL 用了GROUP BY department但是没处理历史数据里部门为 NULL 的情况刚好生产环境有一批脏数据。最后我花了半天排查发现“看起来能跑”的代码实际上既不符合现有代码规范也没覆盖真实业务边界。这个问题不在 AI 身上——是我在让它动手之前根本没有把需求边界、时间字段约定、脏数据预期告诉它。后来我反思了一下问题出在“一次性生成”的思维。传统开发里我们不会让一个新人直接闭卷写整个模块而是会先对齐需求、再讨论方案、实现后做详细代码评审。但用 AI 的时候大部分人的做法恰恰是最危险的那种把窗口当成了“许愿池”把生成结果当成“外包代码”没有中间校验环节。1.2 阶段化到底解决了什么阶段化开发 SOP 的本质是把“生成代码”这一个高风险动作拆成多个低风险的子动作。每个阶段 AI 只做一件明确的事产出一份可以被检查的中间物人只需要在每个关口做一次轻量评审。我见过很多团队对 AI 编程的态度是两个极端要么完全禁止怕引入不可维护的代码要么完全放开让大家各写各的 prompt结果代码库里混进了五六种风格、三四套无用依赖。阶段化 SOP 恰好站在中间既不神话 AI也不敌视它而是把它当成一个“动手能力很强、但需要不断确认需求”的初级工程师来管。用工程管理的角度看阶段化的好处是熵减。需求澄清阶段把模糊变清晰方案设计阶段把清晰变成结构编码实现阶段把结构变成代码测试阶段把代码变成可信代码重构阶段把可信代码变成可维护代码。每一步都留下痕迹每一步出问题都能在最小范围内修正不会出现“生成三百行业务代码然后发现整体方向错了”的局面。1.3 一个核心原则人负责判断模型负责生成整套 SOP 能运转起来最重要的不是写多厉害的 prompt而是确立一条工作原则AI 只负责生成候选内容所有判断权都在人手上。选择哪个方案、接受哪个实现风格、要不要引入某个第三方库、边界条件覆盖到哪一层这些决策必须由人来定。这个原则听起来像废话但实际执行中特别容易失守。比如 AI 在实现时自作主张引入了一个日期处理库理由是“代码更简洁”——如果你没在方案阶段约定好“不允许新增依赖”这个改动就会悄悄混进代码。再比如 AI 在补测试时为了让用例通过反过来修改了业务逻辑里的判断条件这种“测试迁就实现”的反向污染如果不靠阶段检查和人工评审几乎不可能被发现。所以我的 SOP 里每个阶段结束都设定了一个“确认点”。确认点的作用不是走形式而是强制人停下来看一下 AI 到底做了什么、依据是什么、有没有越权。作为开发者你的工作的重心从“写每一行代码”变成“在正确的关口做正确的判断”这才是 AI 辅助编程时代真正的核心能力。2. SOP 的整体框架与阶段设计思路2.1 五阶段流程与产出物总览先给出一张直观的流程总览方便脑海里先建立整体结构。这套流程实际执行下来一个中等复杂度的功能比如一个带权限校验的 CRUD 接口 配套测试完整走一遍大约需要一到两个小时其中人的实际操作时间只需要 30 分钟左右其余时间都在等 AI 生成和做检查。阶段核心目标人的关键动作阶段产出物1. 需求澄清把模糊想法写成明确需求补充边界、规则、约束一页需求卡2. 方案设计确定技术路线和接口边界拍板选型、定接口签名方案说明文档3. 编码实现让 AI 增量生成代码分批提交、逐批评审可编译的增量代码4. 测试补全用测试固化正确行为审查用例质量、补边界测试用例集5. 重构收尾提升可读性和一致性检查规范、更新文档干净的可合入代码这套流程里的五个阶段并不是按时间先后严格串行的实际跑起来经常会有回退。比如编码实现过程中发现接口设计有问题就回退到阶段二重新确认测试补全时发现某个分支逻辑根本走不到就要回到阶段三改实现。阶段化的价值不在于流程本身有多精美而在于它为“回退”提供了明确的路标你能清楚地知道当前问题出在哪一环、需要重新对齐什么而不是对着整段生成代码发呆。2.2 贯穿全程的三条底线第一是最小上下文原则。不要一上来就把整个项目的代码全部塞给 AI。上下文越长AI 的注意力越分散越容易忽略你希望它关注的那几个关键文件。实操做法是只挑选与当前任务直接相关的文件内容、接口定义和配置片段控制在几百行以内让 AI 在“局部信息完整、全局信息简洁”的环境里工作。第二是变更边界原则。每次让 AI 干活之前先明确告诉它可以动的文件范围。我给你一个非常实用的 prompt 句式“本次任务只允许修改service/order_stat.go和dto/order_dto.go两个文件其他文件一律不得改动。如果发现需要修改其他文件请先停下来说明原因。”AI 严格遵守这个指令的比率其实挺高但前提是你必须显式地写出来不能默认它“应该懂”。第三是验收先行原则。不要让 AI 先写代码再想怎么验证而是先在需求卡和方案说明里写明“怎么算完成”。比如接口的入参出参格式、异常时返回什么错误码、响应时间有没有要求、要不要写单元测试。验收标准越具体AI 生成的内容就越有方向感你的评审也越有依据。2.3 为什么不能“一条龙生成”有人可能会问现在很多 AI 编程工具已经在推 Agent 模式号称能自动读代码、自动跑测试、自动改 bug我为什么不直接让它把所有阶段一口气干完我的回答是成熟的项目里绝对不要这样做。Agent 模式确实能处理“从仓库里新建一个完整 CLI 工具”这类绿地场景但在有大量历史代码、团队规范、隐式业务约定和复杂边界条件的存量项目里全自动模式的风险在于它缺少对“为什么这么写”的理解。它能看到现有代码的样子但看不到当初写这段代码的人推翻过什么方案、避开过什么坑。这些隐性问题只能靠人在阶段确认点上做判断。另外全自动的“一条龙”会大大提高定位问题的成本。如果 AI 一口气改了二十个文件测试挂了你很难判断是哪个改动引入的问题。但如果按阶段拆开每批改动只有两三个文件出问题时的排查范围就小得多。这也是我把流程拆成五段、而不是让 AI 一把梭的最现实理由。3. 工具选型与工程准备3.1 三类 AI 编程工具怎么选市面上的 AI 编程工具大致分三类适用场景完全不同选错了会直接影响 SOP 的执行效率。第一类是通用大模型会话工具。它们擅长理解复杂需求、生成大段代码、解释技术概念适合在需求澄清和方案设计阶段使用。你可以把它当顾问让它列出这个功能的实现选项、分析每种方案的优劣、生成接口设计的初稿。这类工具的优势是知识面广弱点是看不到你的项目代码所以不适合让它直接闭卷写业务代码。第二类是IDE 插件 / 代码补全工具。它们能感知你的当前文件、语言服务、最近打开的相关代码补全和生成都会自动贴合项目上下文。这类工具最适合编码实现阶段。需要注意的是补全工具的上下文窗口通常比通用会话小你不要指望它凭“当前文件一百行”就能写出跨五个文件的完整实现它更适合做“函数级别的生成”和“样板代码补全”。第三类是AI Agent 模式工具包括命令行工具和 IDE 内建的 Agent 面板它们具备读取仓库、执行命令、编辑文件、运行测试的能力。运营得当的话它们是编码阶段的主力但风险也在前面说过了如果缺少人工阶段确认Agent 会顺着自己的错误理解一路狂奔。我的建议是只在“有明确需求卡 变更边界清单”的前提下启用 Agent它可以在阶段三做增量实现但阶段一和阶段二的判断决策必须留在人手里。3.2 给 AI 准备的“工程上下文包”很多人在用 AI 写代码时习惯于直接贴文件内容想到哪贴到哪这其实是非常低效的行为。我现在的做法是在编码实现阶段开始前先花十分钟整理一份“上下文包”结构如下技术栈说明语言版本、框架类型、构建工具、测试框架。比如“Java 17 Spring Boot 3.2 MyBatis Plus JUnit 5 Maven”。现有代码规范命名风格、分层方式、异常处理约定。比如“Controller 层只做参数校验和转发Service 层不允许出现 HttpServletRequest业务异常统一抛 BizException由全局处理器转成错误码”。本次任务的输入文件与相关定义给出精确路径以及里面最关键的类型定义、接口签名、配置片段。明确禁止的事项不允许新增依赖、不允许修改数据库表结构、不允许改变既有方法签名。这里有一个特别实用的细节上下文包建议写成一份独立的CONTEXT.md或叫任务说明文件放在临时目录或项目根目录的.ai文件夹里然后在每次对话开始时直接引用它。这样不重复粘贴也不容易漏信息。如果用的是 Agent 类工具这个文件还能充当“任务简报”Agent 会先读它再动手效果比在命令行里输一大段说明稳定得多。3.3 测试环境与安全边界处理用 AI 生成代码有一个容易忽略的前提你必须在本地有一套能随时跑起来的测试环境。因为 AI 生成的代码尤其涉及数据库、缓存、外部接口的代码很多时候要实际跑过才知道有没有问题。没有测试环境人只能靠肉眼 review那 SOP 的价值就打了一半折扣。另外安全边界要提前设好。如果项目里存在密钥、证书、内部接口地址这类敏感信息绝对不要放进给 AI 的上下文包里。我的习惯是上下文包里的配置全部用脱敏的占位符替换让 AI 只知道“配置在application.yml里的order.api.key”不会看到真实值。这不光是防范数据泄露也是给 AI 减少噪音——它不需要理解密钥的意义只需要知道引用的位置。4. 五阶段 SOP 逐层实操详解4.1 阶段一需求澄清与“一页需求卡”这个阶段的目标是把“大概想做一个 XXX 功能”变成一份可以交给任何开发者执行的一页需求卡。它不需要是正式的 PRD但必须把以下八项说清楚功能名称与一句话描述使用方与使用场景谁在什么情况下会调用它输入参数及格式含类型、取值范围、是否必填预期输出及格式数据结构、是否分页、字段含义关键业务规则时间口径、状态流转、去重逻辑、权限要求异常与边界入参非法、数据不存在、依赖超时验收标准怎么算做好肯定不做的范围防止 AI 自由发挥我在实际操作中会用这样的 prompt 模板让 AI 帮我起草需求卡我准备开发一个「按部门汇总工单处理耗时」的统计接口使用方是内部运营后台的报表模块。请基于以下零散描述帮我列出一份结构化需求卡包含输入输出格式、业务规则、异常边界、验收标准四部分。不要写代码不要建议技术方案只做需求层面的整理。请注意以下几点1. 时间统计口径必须以工单关闭时间所在自然日为准2. 部门数据有历史脏数据存在可能存在空值3. 接口只读不允许修改任何业务表。这里唯一需要人类自己确认的重点是“业务规则”里那些 AI 无法从代码中推断的隐式约定。时间口径、排序规则、数据权属边界这些往往散落在产品经理的语言或者老同事的记忆里不写进需求卡AI 在编写阶段一定会用它的“常识”来补——而它的常识往往不是你们项目的真实规则。需求卡写完后建议把它粘贴回给 AI让它以“审查者”身份挑问题哪些描述有歧义、哪些情况还没覆盖、哪些验收标准不可验证。这一步很有效AI 识别模糊描述的能力其实不错它自己在生成时遇到这些歧义也会主动追问。用它的追问来反向修正需求卡等于做了一次免费的需求评审。4.2 阶段二方案设计与接口先行需求卡确认后进入方案设计阶段。这个阶段的核心任务有两个确定技术路线确定对外接口形状。记住一个关键要点先让 AI 出方案但由人拍板。我的做法是给 AI 提供一个开放式 prompt基于这份需求卡给出两到三种实现方案每种方案需要包含核心思路、涉及的文件变更清单、对现有架构的影响点、实现工作量评估、潜在风险。暂时不要写任何具体代码。我会在你看完输出后选择一种方案然后我们再深入那个方案的接口细节。为什么要出多方案因为单一方案会让 AI 把你带进它的偏好里。它默认倾向用最熟悉的套路而这个套路可能跟你的项目现状并不匹配。有两三个方案摆在桌上做比较你的选择才是真正的“决策”而不是“默认接受”。方案确定后紧接着做接口设计。接口设计的产出物不是代码而是方法签名、请求响应结构、依赖关系以及它跟现有模块的交互方式。我会要求 AI 用这种格式输出POST /api/v1/order/stats/dept请求体为{ startDate: 2025-01-01, endDate: 2025-01-31, pageNum: 1, pageSize: 20 }响应结构为{ code: 0, data: { total: 150, list: [ { deptName: 技术支持部, avgDurationHours: 12.5, medianDurationMinutes: 45 } ] } }校验规则startDate必须不晚于endDate格式必须为yyyy-MM-ddpageNum从 1 开始pageSize最大 100接口一旦定下来后续的编码、测试、前端对接就都有了锚点。我有一次搞过一个反面教材先让 AI 把实现写完了再来定义接口结果 AI 定义了一个奇怪的自定义响应体前端不愿意接测试也没法写。后来但凡涉及接口的功能我都在编码前先定签名返工率降了大半。4.3 阶段三编码实现与增量生成编码实现阶段是最容易走偏的所以我执行得也最严格。总原则是一次只让 AI 实现一个内聚的功能单元然后立刻停下人来做检查。以那个统计接口为例我不会让它一口气把 Controller Service Mapper DTO 测试全写出来。我会按依赖顺序拆成四批第一批生成 DTO 和接口签名相关代码。先让 AI 照着阶段二确定的结构生成DeptOrderStatsRequest、DeptOrderStatsResponse、DeptOrderStatsVO这些纯数据结构。这类代码几乎没有业务逻辑AI 生成准确率极高人也容易快速检查字段名和类型。第二批生成数据访问层代码。给它看现有 Mapper 的写法风格和对应的 XML 文件示例再让它实现“按部门分组统计工单耗时”的 SQL。重点检查三件事分组键是否包含全部非聚合字段、时间过滤是否用对了列名、空值是否有COALESCE处理。第三批生成 Service 层的业务逻辑。给它看需求卡里的业务规则和边界条件清单要求它逐条对应实现。这时候我会专门检查几个地方入参校验是否完整、异常分支是否抛出适当的业务异常、时间口径用的是不是项目统一的工具类。第四批生成 Controller 层代码。这个最薄主要是参数绑定和封装响应。它往往依赖前几批代码的存在所以放在最后。每批生成之后马上做“三查”查编译、查边界、查风格。编译可以直接本地跑边界就是对着需求卡逐项核对风格是对着上下文包里的规范例子看有没有出现跟项目习惯不一致的写法。三查通过后再进行下一批。这样做的好处是问题永远在十行内出现你不会面临“AI 写了一千行然后完全跑不起来”的绝望局面。4.4 阶段四测试补全与边界用例设计代码实现之后测试不能省。这个阶段的核心工作是让 AI 基于实现代码补全单元测试但人必须审查“测试质量”。我常用的 prompt 是这是刚实现的 Service 方法源码。请为该方法的每个分支和关键边界条件补充 JUnit 测试用例包括正常路径、入参非法、部门数据为空、开始日期晚于结束日期、大数据量分页等场景。测试数据不要包含真实业务数据全部使用构造数据。只生成测试代码不要修改被测方法。需要注意AI 生成测试有一个常见毛病为了凑覆盖率会写出大量“同义反复”的用例看起来五个测试实际上验证的是同一个行为。我踩过的坑是AI 生成的测试里有两个用例一个断言返回空列表、一个断言列表长度为 0本质上完全等价却占了两个用例。所以审查测试时我会逐条标注“这个用例验证的规则是什么”凡是重复的就删掉凡是缺边界的一定补上。边界用例的设计思路可以借助需求卡里的异常与边界清单一条条去对。正常路径、超时路径、空数据、非法输入、权限不足、并发冲突这些都是最容易出 bug 的缝。如果项目对覆盖率有硬性指标可以让 AI 生成一个“覆盖报告与缺口清单”列出哪些分支还没被测试命中然后决定是补测试还是确认该分支确实不可达需要删除。4.5 阶段五重构收尾与文档沉淀最后这个阶段容易被赶着上线的人跳过去但它的长期价值最大。AI 生成的代码即使经过了前四关仍然可能存在问题命名不够统一、方法过长、存在重复逻辑、注释缺失或者注释与实现不符。阶段五就是做这些收尾工作。我会让 AI 做一次“冷静的代码审查”prompt 如下请以资深代码评审者的身份审查以下刚完成的代码变更输出问题清单。按严重程度分为 P0必须修复、P1建议修复、P2可不改三级。问题类型包括代码可读性、命名一致性、重复逻辑注意与项目中已有工具方法重复、隐藏的性能隐患、潜在的空指针和并发问题。不要直接修改代码先说问题。这一步非常出乎意料的好用。AI 站在评审者立场上的输出质量往往比让它继续写代码时更严谨原因是它不再有“证明自己正确”的倾向可以更客观地指出自己的产出中存在的问题。拿到问题清单后你挑选 P0 和必要的 P1 项再以“请按评审意见修复这些具体问题”为 prompt 让 AI 批量修改。文档沉淀是很多人忽略的部分。AI 能帮你写注释、生成接口说明、整理变更记录但我建议让它在每个功能完成后同步产出一小段“为什么这样实现”的设计备注放进项目的 AI 开发记录目录里。理由是这类备注刚好是 AI 的“思考过程”它知道当时为什么选了某个方案、放弃了哪些备选这比让人类后来回忆要准确得多也能极大降低后续维护者的认知成本。5. 常见问题与排查技巧实录5.1 AI 幻觉与代码错误怎么发现AI 生成的代码里经常出现“一本正经地编造”的情况引用了一个不存在的方法、调用了一个早已废弃的 API、生成了一个自定义注解但没有定义它。这类问题最坑人因为编译都不一定报错取决于 IDE 的解析能力。我总结了一套三层排查法。第一层编译跑一遍这是底线。第二层全局搜索 AI 可能“自以为存在”的符号。比如它会写OrderService.getStats()你就在整个项目里搜一下这个方法到底有没有。第三层针对它引用的三方库 API打开官方文档核验参数。尤其是你项目里用了比较小众的版本时AI 的知识很容易停留在旧版本或新版本的用法上。我见过最离谱的幻觉是AI 引用了一个DecimalUtils.divide()方法实际项目里根本没有这个类但它把这个类写在 import 里居然 IDE 也没报错——因为我项目里有一个同名类别的工具包。这种“碰巧名字相近、签名完全不同”的情况靠肉眼扫代码很难看出来必须靠实际运行触发异常才能发现。从这个角度说阶段四的测试补全不是可选项它是你对抗幻觉最有效的防线。5.2 上下文过长导致“越聊越糊涂”用对话式 AI 写代码聊到第四五轮之后质量往往明显下降。这不一定是你 prompt 的问题而是上下文太长模型开始丢失早期指令中的重点。它把你后来随口说的一句“你看着办吧”理解成了对前面约束的否定然后放开手脚自由发挥。应对策略非常朴素频繁开启新会话而不是在旧会话里续聊。每次开启新会话时把上下文包精简后重新粘贴把本次任务要解决的问题写成一个清晰的任务标题。我通常在完成一个内聚功能单元比如一批 DTO 或一个 Service 方法之后就关掉当前会话下一批代码用新会话生成。如果你用的工具支持“上下文管理”或“会话压缩”功能也可以手动把早期确认过的需求卡和接口定义置顶压缩掉那些“是的”“好的”“继续”之类的无意义轮次让模型重新聚焦。这个习惯对质量的提升特别明显值得专门训练自己。5.3 提示词反复不达预期的通用解法很多人在 AI 编程时最大的挫败感来自同样的需求AI 输出一会儿符合预期、一会儿跑偏。后来我总结出一套通用的“三剂药方”。第一剂给例子。你希望 AI 用什么风格写代码就给一个同类代码片段作为范例。模型非常擅长“模仿”这种隐式的风格传递远比你在文字里写十句“注意简洁”“遵循规范”有效。第二剂收范围。当 AI 输出泛泛而谈、不解决问题时大概率是因为任务描述得太大。把“优化这个功能”改为“把 Service 方法前三行中重复的校验逻辑提取到一个私有方法中”它的输出会立刻变具体。第三剂换立场。同一个任务换个角色身份去要求它产出的角度完全不同。“作为这个模块的负责人请审查这段代码”和“作为一位刚接手的新人请说明这段代码做了什么”得到的信息结构截然不同你可以在不同阶段用不同的立场 prompt 来获得多角度的产出。遇到过很多次的情况是不是 AI 不行而是我一直执着于让它用第一人称编代码其实它用“评审者”身份给出的问题列表才是我想知道的内容。察觉到对话方向走偏时主动切换角色设定通常能跳出死循环。5.4 多 AI 协作时的互相“污染”问题有些场景会用两个 AI 模型做协作比如 A 模型生成代码、B 模型审查代码。这里有一个坑如果你把 A 模型的完整输出直接丢给 B 模型做审查B 模型大概率会被 A 的输出带偏会顺着错误思路给出“看起来合理、实则错误”的强化意见。这是因为语言模型有很强的“顺承倾向”审查者会被生成者的表述框架限制住。正确的做法是给审查者 B 一份不带答案的原始素材——给它需求卡、接口设计、原始文件内容但不要直接给它 A 生成的完整代码。让它先基于需求描述列出“应该检查什么”然后你再把 A 的代码放进去让它逐项对照。这个流程破坏了一味“顺着说”的链条审查者就有了独立判断的立足点。我在实际中测试过多轮用这种隔离审查的方式B 模型发现真实缺陷的数量明显高于直接丢代码的方式。6. 轻量落地建议从个人习惯到团队制度6.1 个人开发者怎么低成本起步如果你是个人开发者不一定要把这套 SOI 做成正式文档更不必引入任何协作平台。我的建议是按“最少必要流程”起步只抓三件事写需求卡、控制每批代码范围、验收先行。哪怕前面几个功能你都手写只是把需求卡和实现拆批这两件事做了AI 生成的可用率也会涨一大截。具体落地方法新建一个.ai/目录放在项目里里面放两份文件requirements.md和context.md。requirements 维护当前任务的需求卡context 维护项目的技术栈、代码规范、禁止事项。每次开启一个新的 AI 对话前花两分钟把这两份文件更新到最新。这看起来像额外负担实际上是在为 AI 构建它的“工作记忆”省下的返工时间远超这两分钟。6.2 团队落地时的三个关键开关团队落地比个人复杂但也不用搞得很重。我认为有三个开关值得首先打开。第一个开关是统一模板。团队仓库里放一套标准的需求卡模板和上下文包模板任何成员用 AI 开发前都先填充模板。我不建议强制所有人都用同一款 AI 工具但模板统一能让互相 review 时的交流成本降到最低。第二个开关是合入门禁。把“需求卡存在”和“变更边界清单存在”设成代码合并前的检查项。这个不用写脚本在 PR 描述里加两个勾选项即可。它的作用是提醒没有想清楚的事不要让 AI 替你决定。第三个开关是按阶段分离评审。不要让开发者在 PR 里一次提交 AI 生成的五百行代码让同事评审而是鼓励他们在需求澄清和方案设计阶段就把 AI 产出的方案文档发出来先对齐思路再上实现。代码评审的成本会骤降——因为大部分争议在方案阶段就已经消解了。6.3 我对这套 SOP 的进一步扩展想法这套流程我用了大半年目前还在往两个方向扩展。一个是把阶段一、阶段二的 prompt 模板沉淀成团队内部的“AI 使用手册”配套材料让新入职的同事能照着手册独立跑完整个流程。另一个是把阶段五的评审问题清单积累成一个缺陷库慢慢就能看出哪些类型的错误是 AI 高概率会犯的后续在需求卡里就能提前打补丁比如明确写“禁止把时间格式化逻辑散落在业务方法里”。也有人问过我是不是可以让 AI 自动执行这套 SOP 里的某些环节做成一个自动化流水线我的看法是阶段三、四、五的绝大多数操作性工作确实可以交给 Agent 自动化但阶段一、二的需求澄清和方案拍板短期内还是得留在人手里。一个连带的好消息是把这套 SOP 写成提示词模板之后它本身就变成了一种“人机协作协议”以后不管换什么工具和模型核心流程都不用重写只换接口而已。最后说一句我的个人体会。踩过很多坑之后我深刻认识到AI 辅助编程提效的关键不在于模型选得多好、提示词写得多花哨而在于你有没有一套稳定的协作流程。需求靠人理清由 AI 补全结构由人拍板由 AI 执行边界由人定义由 AI 覆盖质量由人验收由 AI 兜底。这套阶段化开发 SOP 说白了就是给人和机器之间画出了干净的边界。按照它来AI 就能安安分分当你的强力执行者而不是那个制造混乱的厨房帮手。