当前AI自动开发的热度不用我多说但很多团队把AI写代码这件事理解得太简单了。他们以为把需求丢给一个Agent它就能自动把整个功能写完。实际跑过一轮就会知道直接端到端让AI干活翻车率极高。我最近在搭建一套AI自动开发流水线最核心的设计思路只有两条第一把AI的能力边界画清楚知道哪些环节能自动化、哪些必须留人第二把规划和执行拆成两个工具让每个工具只做自己最擅长的事。这套架构跑通之后AI的产出质量、可审查性、可回滚性都上了一个台阶。这篇文章就把这套设计的完整思路拆开讲包括能力边界的判断方法、双工具的分工逻辑、任务状态流转与验证闭环设计最后附上一个可以直接参考的落地案例。1. 能力边界先分清楚哪些能自动化哪些不能1.1 为什么边界比效率更重要很多人一上来就问AI一天能写多少行代码我反而觉得应该先问AI写的代码你敢不敢直接合并。AI生成代码的速度早就不是瓶颈真正的瓶颈在于你无法预判它会在哪一步给你埋一个意想不到的坑。模型生成代码时它的信心程度和代码正确性没有强关联它完全可能用逻辑清晰、句式完整的方式给你写出一段调用某个不存在接口的实现而且在编译之前毫无破绽。所以AI自动开发的首要任务不是提升效率而是明确边界。边界画得越清楚AI的发挥空间越可控。我在实际项目中总结出来的经验是凡是满足目标明确、范围可控、验证可自动化这三个条件的任务都可以交给AI去干反过来只要有一个条件不满足就应该在流程里加入人工介入点。这不是保守而是务实。AI自动开发最怕的不是AI菜而是你把一个模糊的需求交给它它就用一个漂亮的方案把你的项目带进沟里。1.2 三个判断维度任务、上下文、验证判断一个开发任务是否适合纳入AI自动开发链路我一般用三个维度来打分。第一个维度是任务目标是否清晰。如果你的需求是给订单模块加一个导出Excel的功能这就足够清晰但如果需求是优化下单流程体验这个目标太抽象AI没有能力去做业务价值判断强行自动化只会产出一些表面好看、实际没用的改动。任务清晰的标准是可以写出明确的验收条件比如输入一个订单ID列表输出一个xlsx文件包含订单号、金额、状态等字段。第二个维度是上下文范围是否可控。AI改动的代码如果只涉及少数几个文件、少数几个模块那它的成功率非常高。反过来如果一个需求需要跨服务、跨团队、跨多个仓库同时修改AI根本Hold不住。原因很好理解模型在有限的上下文窗口里根本无法同时理解和维护几十个文件之间的隐含依赖关系。所以我通常会看一个指标这个需求改动的文件能不能被完整装进上下文里而且不遗漏关键依赖。装得下自动化的可能性就大装不下就先拆。第三个维度是验证手段是否可自动化。这一个最关键也最容易被忽略。AI把代码写完之后你拿什么证明它是对的如果项目里有足够的单元测试、集成测试、静态检查那AI写完代码后可以自己跑验证形成一个闭环。但如果一个项目连测试都没有AI就只能靠感觉判断自己写完没——这个感觉通常不怎么可靠。没有验证闭环的AI自动开发本质是在裸奔。1.3 适合自动化与不适合自动化的典型场景结合上述维度我整理了自己实际验证过的任务分类直接套用即可任务类型是否适合AI自动开发原因CRUD接口开发很适合模式固定、验收标准明确、测试容易补齐单元测试补全很适合有现有代码作为参考验证手段天然存在日志脚本、数据处理脚本很适合范围小、依赖少、可本地验证Bug修复有复现路径较适合复现步骤即验收标准但需人审查根因分析代码重构局部模块较适合依赖测试兜底重构后跑全量测试跨服务链路改造不适合上下文爆炸、依赖环境复杂、验证成本高系统级架构设计不适合需要业务判断与多团队协同AI无法负责安全与合规审查不适合风险等级高必须人来兜底灰度发布与监控策略不适合依赖线上数据与业务经验AI无法感知这张表不是一成不变的。随着项目测试覆盖率提升、代码模块化程度提高原本不适合自动化的任务也会逐渐变成可自动化。所以我的建议是能力边界不是静态的它应该随项目的工程质量同步演进。你测试写得越多模块拆得越干净AI能自动化的疆域就越大。2. 双工具分工为什么一个端到端Agent行不通2.1 端到端方案的三个致命问题不少人设想过一个超级Agent从理解需求到提交代码全部搞定的理想形态。我试过这个路线结论是在现有模型能力下这条路走不通至少不适合严肃的工程项目。端到端方案有三个绕不开的致命问题。第一是上下文爆炸。一个大型项目的代码量动辄几十万行即使只涉及一个需求也往往需要同时参考数据模型、接口定义、既有实现、配置文件等多个文件。把这些全部塞进Prompt很快就把上下文窗口撑爆模型开始顾头不顾尾注意力被无关信息稀释生成的代码质量断崖式下跌。第二是意愿漂移。所谓意愿漂移就是AI在长流程执行过程中逐渐偏离最初的目标。比如你让它写一个导出接口它写到一半灵光一闪顺手帮你把定时任务也加了甚至贴心地改了另一个不相关模块的命名规范。在端到端模式下这种偏离非常难控制因为没有一个中间检查点来实时约束它。第三是问题排查困难。当端到端流程失败时你很难判断是需求理解错了、方案设计错了、代码生成错了还是验证方式错了。所有环节纠缠在一起出了问题只能从头看日志成本极高。这就好比一条流水线上只有一个工人既做设计又做焊接最后产品出了瑕疵你连是图纸问题还是工艺问题都说不清。2.2 规划者与执行者的职责拆解双工具分工就是为了规避上面这三个问题。这套架构里两个工具各管一段规划器Planner负责想清楚再动手。它的输入是用户需求输出是一份结构化、可执行、带验收标准的任务清单。规划器需要理解需求背后的业务逻辑判断技术方案的合理性并把一个大需求拆解成多个彼此独立、边界清晰的小任务。它的核心能力是强推理而不是写代码。执行器Executor负责照章办事。它的输入是任务清单中的单条任务输出是代码变更与验证结果。执行器需要有稳定的文件读写能力、命令执行能力、代码搜索能力能够按任务描述完成编码并运行测试和静态检查来确认结果。它的核心能力是强编码和稳定的工具调用。在整个流程中规划器不直接碰代码执行器不负责做技术决策。这样设计的好处非常多上下文被切分到每个任务级别执行器每次只加载跟当前任务相关的代码上下文爆炸问题得到缓解意愿漂移被任务清单的边界限制住执行器只改清单里列出的文件问题排查也变得简单一旦某个任务失败错误信息回流到规划器规划器针对性地调整方案或重拆任务定位精准。2.3 分工之后的接口设计任务清单双工具之间的衔接点是一份结构化的任务清单。这份清单就是两个工具之间的接口协议它必须足够精确既能指导执行器落地又能约束执行器的行为边界。我在实践中把单条任务设计成下面这个结构{ id: T002, title: 创建OrderExportService, goal: 实现订单查询并生成Excel字节流, files: [ src/main/java/com/example/order/service/OrderExportService.java ], acceptance: service方法接收ListString订单ID返回byte[]文件头为xlsx格式, dependencies: [T001], status: todo }每个字段都有明确作用files字段是文件边界执行器只能新建或修改这个列表内的文件如果它发现任务需要改动其他文件必须停下来向规划器上报而不是自己顺手改掉acceptance字段是完成定义执行器判断任务结束的唯一依据不是代码写完了而是验收条件满足了dependencies字段用来表达任务间的先后关系避免执行器在依赖未就绪时盲目开工。把任务清单设计成这种结构化格式之后我发现团队里的人工Review也变得轻松了。以前Review一份AI生成的PR要逐行检查代码逻辑现在只需要先看任务清单确认规划器拆得对不对再抽查执行器在每个任务里的实现是否满足验收条件。审查粒度从代码级提升到了任务级效率翻倍。3. 架构落地从需求到代码的完整流转3.1 整体架构与状态流转设计前面讲的是分工思路落到工程上需要一个清晰的状态流转机制。我搭的结构大致是这样用户需求 ↓ [规划器] → 需求澄清 → 方案设计 → 任务拆分 ↓ [任务队列]todo / doing / done / blocked ↓ [执行器循环] → 拉取任务 → 加载上下文 → 编码 → 验证 ↓ 失败 ↓ 成功 ↓ 错误信息回流规划器 ↓ [验证网关] ←←─────────────────┘ ↓ [汇总输出]变更摘要 测试报告 风险提示任务队列是整个架构的中枢。执行器不直接接收用户需求它只从队列里拉取单个任务。这样做的好处在前面提过任务级别上下文隔离、边界清晰、便于追踪。我特别强调队列要带blocked状态因为实践中经常会遇到某个任务依赖的外部条件没就绪比如测试环境还没部署好、某个接口文档还没定。有了blocked状态执行器遇到障碍时不用死等而是可以把任务标记为阻塞继续处理其他不受影响的任务或者停下来等待规划器介入。状态流转的规则要定得很死板每个任务只能由todo → doing → tested → done单向推进任何一环不通过就转回todo或blocked。不要给AI设置跳过验证直接完成的通路否则前面设计的验证闭环就形同虚设。3.2 上下文裁剪让执行器只看该看的东西执行器最怕的其实是上下文嘈杂。同一份代码库里和当前任务相关的可能只有三个文件但Agent框架往往倾向于把整个项目的结构、所有配置、历史对话都带进Prompt这会让模型对核心信息的注意力大幅下降。我在架构中加入了一层上下文裁剪模块执行器拉取任务后不直接读全文件而是按需检索。具体做法有三种第一种文件级裁剪。从任务清单的files字段直接拿到目标文件列表只加载这些文件的内容。如果文件过大就进一步做块级裁剪只读取与验收标准直接相关的类、函数、方法片段。第二种依赖级补充。执行器发现当前文件里引用了某个类或接口但缺少其定义会主动调用代码搜索工具只把引用对象本身的定义抓回来而不是把整个依赖文件全部读入。这样既能理解上下文又不会让无关内容涌入模型。第三种任务说明书注入。每个任务在创建时规划器会附带一段背景说明简要描述这个任务在整体需求里的位置、与前后任务的关系、需要遵循的既有约定。有了这段说明书执行器即便没有完整的历史对话记录也能理解自己在干什么这为多个任务并行执行或失败后任务重试创造了条件。经过这套裁剪之后单个任务的实际上下文占用通常能压缩到原来的五分之一以下。模型执行时的专注度明显提升生成代码质量和一次通过率都上来了。3.3 验证闭环让AI自己确认真的做完了前面反复强调验证手段具体落到架构里我的做法是设置一个验证网关它位于执行器循环内部每个任务完成后都必须经过它。验证网关里至少包含三层校验。第一层是静态校验包括编译、类型检查、Lint检查这些是硬门槛任何一个过不了任务直接判失败错误信息回流。第二层是动态校验包括单元测试和集成测试。对于AI新增的代码我还会要求它在任务验收标准里附带对应的测试用例运行通过的测试本身就是AI产出质量的最直接证据。第三层是边界校验执行器在提交任务结果之前会先检查自己实际改动的文件清单和任务清单里files字段的边界做比对。凡是改了边界之外的文件一律自动回退并标记告警。这三层校验全部通过任务才会被标记为done。如果执行器在完成编码后发现无法通过验证它会自动把错误信息打包连同相关代码上下文一起作为异常输入交给规划器规划器分析后给出两种可能要么任务本身拆得不合理要么实现方案有问题。规划器调整任务定义或者换个技术方案再重新压入执行队列。这个执行-验证-反馈-再规划的闭环是整个AI自动开发架构里最有价值的部分它让AI系统具备了自我纠偏的能力。4. 实操案例用这套架构跑通一个订单导出功能4.1 场景与初始输入只看理论可能还是觉得抽象我拿一个实际跑通的例子来说明。假设现在有一个基于Spring Boot的订单系统需要新增订单数据导出Excel功能。用户给规划器的原始输入很简单需求给订单模块增加一个导出Excel的功能 用户传入一个订单ID列表导出包含订单号、下单时间、 订单金额、订单状态的Excel文件。这个需求在能力边界模型里属于目标明确、改动范围受限、有测试可补的任务适合纳入自动开发流程。规划器先对需求做澄清比如导出之后是返回给前端下载还是存储在服务端最终确定方案新增一个Service负责生成Excel字节流新增一个Controller暴露HTTP接口同时补充Maven依赖和单元测试。4.2 规划器产出的任务清单设计规划器最终产出一份包含五个任务的任务清单实际结构大致如下{ project: order-export-demo, goal: 为订单模块增加Excel导出接口, tasks: [ { id: T001, title: 添加Apache POI依赖, files: [pom.xml], acceptance: pom.xml包含org.apache.poi:poi-ooxml:5.2.5, status: todo }, { id: T002, title: 创建OrderExportService, files: [src/main/java/com/example/order/service/OrderExportService.java], acceptance: 提供export(ListString orderIds)方法返回xlsx格式的byte[], dependencies: [T001], status: todo }, { id: T003, title: 创建OrderExportController, files: [src/main/java/com/example/order/controller/OrderExportController.java], acceptance: 暴露POST /api/orders/export接口请求体为订单ID列表返回application/vnd.ms-excel, dependencies: [T002], status: todo }, { id: T004, title: 编写OrderExportServiceTest, files: [src/test/java/com/example/order/service/OrderExportServiceTest.java], acceptance: 测试export方法返回的xlsx中行数与输入订单数一致且包含指定字段, dependencies: [T002], status: todo } ] }每个任务都足够小小到执行器可以在不读取整个项目的情况下完成每个任务都有明确的acceptance条件执行器做完之后知道怎么样才算通过。特别注意的是我没有把运行mvn test全量验证单独拆成一个任务而是把它作为整个流程的收尾验证由验证网关统一执行避免无谓地让AI重复跑测试。4.3 执行器逐项落地与验证过程执行器拿到任务队列后按依赖顺序开始工作。执行T001时它只读取pom.xml找到dependencies节点插入POI依赖。完成后运行mvn dependency:resolve验证依赖下载成功。它想顺手把pom.xml里其他过时依赖也升级一下但因为files边界明确写着只允许改pom.xml的依赖添加部分而且有额外的git diff检查这个越界行为在执行前就被拦截了。T002和T003是核心编码任务。执行器先读取OrderExportService.java所在目录的现有代码理解订单实体类OrderEntity的结构然后生成导出逻辑。期间它发现需要调用订单查询的Mapper接口于是通过代码搜索定位了OrderMapper.java的定义只加载了接口方法签名避免了把整个Mapper实现类也读进来。生成代码后验证网关执行编译第一次编译报错原因是实体类中的时间字段类型是LocalDateTime生成的Excel单元格写入代码类型不匹配。错误信息被自动打包发送给规划器规划器判断这是实现方案瑕疵输出修复建议在Service中加入时间格式化步骤。执行器收到更新后的方案修改代码再次编译这次通过了。T004是测试编写任务。执行器模拟订单数据调用Service的export方法再用POI的读取API校验生成的Excel内容断言行数和字段值。测试运行通过后验证网关执行全量mvn test所有用例通过。此时任务队列全部标记为done流程自动生成一份汇总报告包括每个任务的变更文件列表、git diff统计、测试执行结果。我把这份报告拿给同事做人工Review他们只需要看几个关键点任务拆分是否合理、关键实现是否符合既有约定、测试是否真正覆盖了验收标准。整个Review过程不到15分钟。5. 常见问题与排查经验5.1 典型问题速查表这套架构跑了一段时间后我积累了一些高频问题的排查经验整理成速查表症状根因处理办法AI改了任务清单之外的文件执行器上下文边界约束不严检查files边界配置增加自动git diff比对同一个错误反复重试始终无法通过执行器诊断能力不足或测试用例本身写错限制重试次数超过3次强制转人工AI使用了不存在的第三方库版本模型幻觉或对依赖版本掌握不准规划器在任务说明中写明确切版本号功能越加越多需求逐渐失控验收标准缺失AI自己定义完成严格执行acceptance字段不满足不算done生成代码风格与项目现有代码不一致上下文里缺少项目编码规范信息在任务说明书中注入项目规范摘要编译和测试都过了但业务逻辑是错的测试覆盖不足只验证了表面路径加强规划器侧的需求澄清与边界条件补全表中最后一条是最隐蔽的问题也是我最警惕的。AI能够轻松通过Happy Path的测试但它很少主动去思考边界条件、空值、并发冲突、资源泄露这些问题。所以我在任务清单里会要求规划器明确列出边界条件测试点比如输入空列表、列表中包含不存在的订单ID、重复ID等场景确保验证不是流于形式。5.2 从坑里爬出来的几条硬经验最后分享几条我自己踩出来的经验这些在官方文档里基本看不到。第一任务拆得越小成功率越高。这是我把任务粒度从一个功能逐步缩小到一个文件、一个方法之后得到的结论。小任务不仅执行成功率高而且失败后重试成本极低不会牵一发动全身。一个原本靠大需求一锅端需要3个小时才能完成的功能拆成6个小任务后总耗时反而降到了40分钟。第二完成定义必须比代码更明确。对AI来说代码写完了不等于完成了。我在acceptance字段上吃过很多教训最典型的就是生成一个接口这种描述AI会只写个空壳接口就算交差。后来我把验收条件改成了可量化的行为描述例如输入有效参数时返回200输入空列表时返回400AI的执行表现立刻改善。第三人工检查点不能省。双工具分工解决的是AI自己干活的效率问题但该不该让AI干这个活的判断权一定要留在人手里。我在流程里设置了两个强制人工检查点一是任务清单产出后由开发负责人确认拆分合理性二是所有任务完成后、合并分支前由至少一个人对关键任务进行代码Review。这两道关卡不消耗太多时间却能拦住绝大多数严重问题。第四每个失败案例都是能力边界的真实情报。我会把每次AI自动开发失败的任务沉淀到一个内部知识库里标注失败原因、根因分类、纠偏策略。这个知识库反过来又作为规划器的参考让它下次拆任务时更清楚哪些需求容易踩坑、哪些边界条件需要提前约束。所谓的AI越来越懂你的项目其实就是通过这种持续沉淀慢慢实现的。
