最近我在做一个企业内部的业务系统4人团队排期2个月最后我一个人用3个AI Agent3周做完。不是炫耀是这套打法确实改了我的工作方式也踩了不少坑值得好好复盘一次。先说背景。项目是一个典型的中后台业务系统权限体系、审批流、数据看板、客户管理外加一堆增删改查的报表页面。传统做法是前后端拆分产品经理写需求后端出接口前端调接口测试再来一轮轮回归。听起来不复杂但企业项目真正的耗时点从来不在写代码而在沟通、对齐和返工——需求细节没对齐接口字段没说清页面效果和预期不一致每一条都能吃掉一两天。我把项目拆成了三条Agent流水线分别承担规划、编码、审查的职责自己只做需求接口人和最终验收人。这套模式跑通后干活节奏基本就是早上给Agent派活中午回来做一轮review下午修问题、继续派下一批活晚上合代码。3周下来业务功能、部署、演示、交付一个没少。这篇就把我的完整方案、Prompt设计、工具链选型、成本消耗以及所有踩过的坑都写出来给想在真实项目里用AI Agent的人一个直接能抄的参考。1. 项目到底做了什么为什么传统2个月的项目能压到3周先把这个项目的范围说清楚不然“3周做完”听起来像吹牛。项目是给一家做供应链贸易的公司做的内部订单协作平台核心模块有组织架构与用户权限支持多角色、多层级审批数据权限要能隔离到部门。订单全流程管理从下单、审核、出库到对账状态机流转异常订单要能回退。数据看板与报表包括销售趋势、回款统计、库存周转图表不能只是摆设要能按时间段筛选。客户与供应商管理基础资料维护、关联订单查询、信用额度控制。操作日志与消息通知关键操作留痕审批待办要推送到内部工作台。原计划是4个人1个产品、2个后端、1个前端干2个月。但我和老板商量后把范围做了硬约束不做移动端App不做复杂的自定义报表设计器不做遗留系统数据迁移。所有业务逻辑在一个新系统里闭环对接老系统只走导出导入。为什么3周能做完核心原因不是AI写代码比人快多少而是提前把“返工成本”压到了最低。传统模式里2个月里有大量时间耗在“产品写完文档—开发理解错—测试发现不对—返工”这个循环里。而我用Agent架构后需求文档会先被规划Agent转成可直接落地的任务清单和接口定义编码Agent只按图施工审查Agent又专门查逻辑漏洞。每一层都有独立的“质检关”错误在递进过程中就被拦下来了不会累积到最后才爆发。这里要解释一个关键认知AI Agent交付项目的优势不是代码生成速度说实话生成速度也就那么回事而是“执行链路的确定性”。只要你把每个Agent的职责边界和协作接口定义清楚它可以像个不知疲倦的初级团队一样把需求逐步变成可运行的软件并且每一层都有审查和校验。我后来复盘真正让2个月的活压到3周的因素大概是这个配比规划Agent省掉了约70%的返工编码Agent顶掉了约90%的普通CRUD开发审查Agent省掉了约一半的测试人工介入。省下来的时间刚好用在了最容易出问题的联调和部署上。2. 三个AI Agent怎么分工谁干规划、谁写代码、谁做质检很多人在项目里用AI Agent一上来就开一堆角色什么“前端Agent”“后端Agent”“测试Agent”“运维Agent”结果Agent之间互相打架代码互相覆盖上下文互相污染最后比人工还乱。我的经验是3个Agent是上限超过这个数协调成本会指数增长。我设计的三个Agent分别是Agent角色定位核心职责对应传统团队角色Agent A规划者拆解需求、设计数据模型、生成任务卡、定义接口契约产品经理 架构师 技术LeaderAgent B执行者按任务卡实现业务代码、增删改查、状态机流转、页面后端开发 前端开发Agent C审查者Code Review、跑测试、查安全风险、核对需求覆盖度测试工程师 代码审查人 运维安全检查这里的关键是三个Agent不是平行的是流水线式的上下游关系Agent A的输出是Agent B的输入Agent B的输出又交给Agent C审查发现问题后打回给Agent B修改Agent C复核通过后才算任务完成。在实际操作中我不让Agent之间直接对话所有交接都通过文件和消息队列完成。比如Agent A产出一个任务卡就是一个Markdown文件里面包含需求描述、验收标准、涉及的数据表、接口签名。Agent B只认任务卡不自己发挥。Agent C只认代码仓库的diff和测试结果。这样每一环都是“输入—处理—输出”的标准结构中间出了问题我一眼就能定位是哪一环的问题。接下来是我实际在用的Prompt框架我把它简化后贴在下面你可以直接改改就用。Agent A规划者的核心Prompt你是本项目的规划Agent。你只能输出规划和设计不允许编写业务代码。 针对下面这个需求你必须输出 1. 按优先级排序的任务清单每个任务包含标题、描述、验收标准、预估工时 2. 涉及的数据表和字段定义用DDL描述 3. 核心接口签名用OpenAPI格式描述 4. 潜在风险点和回滚方案 需求内容 【在这里粘贴你的需求描述】 输出时严格按以上四部分组织不要有多余内容。Agent B执行者的核心Prompt你是本项目的编码Agent。你只负责实现下面这个任务卡不允许擅自重构其他模块不允许修改任务范围以外的代码。 任务卡 【在这里粘贴Agent A生成的任务卡】 实现要求 1. 严格遵循项目现有的代码风格和目录结构 2. 必须编写对应的单元测试 3. 完成后输出修改的文件列表、关键实现说明、测试结果 4. 如果遇到任务卡描述不清的地方列出疑问清单不要自行假设Agent C审查者的核心Prompt你是本项目的审查Agent。你只负责审查代码变更不修改代码。 审查对象是下面这个代码diff或文件列表 【在这里粘贴Agent B的改动】 你必须检查 1. 逻辑漏洞和边界条件比如空指针、除零、状态机非法流转 2. 安全风险SQL注入、越权访问、敏感信息泄露 3. 测试覆盖率关键分支是否都有测试 4. 需求覆盖度任务卡里的验收标准是否全部满足 输出格式 - 严重问题列表必须修复才能合入 - 建议优化列表可延迟处理 - 结论通过 / 打回这个流水线跑起来之后你会发现一个很有意思的现象Agent A和Agent C都是“不写代码的”但它们恰恰是提升效率的关键。因为正是它们把需求和实现之间的缝隙填平了编码Agent才能像“按图纸施工”一样高效。我给那些“让Agent自由发挥写整个项目”的人一句忠告自由发挥的Agent产出的是看起来很合理但实际跑不通的代码必须有人在前面定方向、在后面做验收。3. 技术选型为什么用Django做业务、Rust做边缘服务、部署在阿里云技术栈选型这事在AI Agent交付项目里比传统项目更敏感。原因很现实你选的每一种语言、每一个框架AI生成代码的“靠谱程度”天差地别。Python Django生态成熟AI训练语料极多生成代码的准确率远高于那些冷门框架。而冷门技术栈一旦让AI去写它经常会一本正经地编造不存在的API坑到你怀疑人生。这个项目我最终用在业务侧的是Python Django PostgreSQL直接用Django自带的Admin和DRFDjango REST Framework快速搭CRUD接口。为什么不用Java Spring Boot按理说企业项目用Spring更“正统”但Spring那套注解和依赖注入配置AI生成时的出错率明显高于Django。Django的ORM和Model定义接近字面表述一个请求进来到数据落库之间几乎没有黑魔法这对AI生成代码的可控性和可审查性都是极大的加分项。那Rust在这个项目里干什么用了我用Rust写了一个独立的边缘数据服务负责三件事从外部Excel批量导入订单数据、做数据格式校验和清洗、生成对账报表。为什么这部分用Rust因为它是一个高频、独立、并发压力大的模块而且逻辑闭环不需要和Django的业务模型纠缠。Rust在这里的优势是编译期就能拦住很多问题单二进制文件部署特别友好。但我不建议把Rust塞给规划Agent去生成大量复杂业务代码——Rust的所有权和生命周期对AI来说还是容易出概念错误调试成本高我在这个项目里就让Agent只在极小范围内生成Rust代码核心代码我自己手写校验。Django和Rust两个服务之间通过一个简单的HTTP接口通信Rust服务纯粹做数据处理把清洗好的结构化数据吐给Django的APIDjango负责落库和业务流转。这样的边界设计让AI Agent写Django侧的代码时不需要理解Rust内部反过来Rust侧的手写代码也不受Agent代码的干扰。部署这块我放在阿里云上一台4核8G的ECS跑DjangoGunicorn Nginx一台2核4G的跑Rust服务数据库用云上的PostgreSQL对象存储放导入的Excel源文件和生成的报表。打包部署直接编写Dockerfile用云效流水线做CI/CD提交代码后自动跑测试、构建镜像、推送、发布。整个部署链路我花了大概一天半的时间搭好之后3周里再也没有手工上服务器操作过。有一说一阿里云这种主流的云平台胜在文档全、控制台顺手、生态工具齐。AI Agent在写部署脚本和Dockerfile时也能从训练数据里学到大量阿里云的正确用法不会给我编造一堆根本不存在的控制台按钮或CLI参数。4. 3周实操复盘每天在干什么、任务怎么拆、节奏如何把控光说方案太虚我直接把这3周的关键节奏复盘出来你可以对照着看AI Agent到底是怎么实打实干活的。第一周核心是做架构和数据地基。周一上午我把项目需求文档扔给规划Agent让它输出全量任务清单。它产出大概52个任务卡我花了一下午把任务卡一个一个过了一遍把明显不合理的地方打回重做比如它把权限模型设计得过于复杂把简单的RBAC搞成了多租户隔离我让它简化。周二到周三让规划Agent产出数据库DDL和接口签名这个环节就是不断“挑毛病”的阶段。数据字典对齐、字段类型确认、状态机枚举值统一全部在周四前定稿。周五Agent B开始按任务卡搭建Django项目骨架实现用户登录、权限校验、基础CRUD。周末我自己加班补了一些Agent做不好的事编写初始种子数据配置Nginx和Gunicorn的部署脚本。第一周跑下来我最大的体会是规划Agent的产出质量直接决定后续两周的顺畅程度。如果你不花时间在前期去校验它的任务拆解、数据模型和接口契约后面所有Agent都会在一个错误的地基上疯狂盖楼那种返工是灾难级的。第二周进入业务功能密集开发期。我把52个任务卡按依赖关系排成队列每天早晨并发派给Agent B两到三个任务它完成一个我立刻跑一轮测试并把diff丢给Agent C审查。Agent C打回的问题我再连同审查意见一起发回给Agent B修改。这个循环一天能跑三到四轮每天大概合并20到30个文件。我在这个阶段的角色已经从“写代码的”变成了“派活、复核、把关的工头”。这个环节里我总结了一个特别重要的技巧永远不要让Agent B同时处理两个关联度高的任务。比如“订单创建”和“订单审批流”如果一起交给它它会自作主张地合并表结构或调整字段语义然后两边逻辑全乱。我宁可把任务切得更小一个卡只干一件事哪怕多派几轮都行。整个第二周订单管理、客户管理、供应商管理、库存台账这些核心模块陆续跑通测试用例从0涨到260多个。当然这不是说没有返工但Agent C审查提前拦掉了七八成的问题人工返工基本控制在“改需求”范畴内。第三周进入联调、修数、演示交付。这一周的工作大头其实是“接缝处修补”。Django后端、Rust数据处理服务、前端页面这三块单独看起来各自都能跑但连起来总有数据对不上的地方。比如Rust导入的订单金额在Excel里是“元”Django业务里存的是“分”对账报表里又用“万元”同一个数字三个口径反复改了好几轮才统一。这种事Agent不会替你发现必须靠人工盯着看全局数据流。第三周后半段我做了一次全量回归测试把所有核心流程按真实业务场景跑了一遍然后把部署流水线调整到生产环境做了数据初始化、权限分配、操作手册编写。第21天下午项目演示给业务方订单流转、审批通知、报表导出全部顺畅项目交付。做演示的时候业务方还在问功能细节是不是要再调我心里清楚这套代码里埋着Agent C拦住的那些雷所以心里还算有底。5. 实战中出的问题以及我的排查与规避方法用AI Agent交付项目一定不是一帆风顺的。我在3周里遇到了不少具体问题挑几个典型的说说也附上我的处理办法和避坑建议。第一个问题是上下文丢失这是最多发、最头疼的问题。Agent B在实现复杂任务时经常写到一半忘记任务卡里的约束条件。比如任务卡里明确写了“只有部门主管角色可以发起审批”它实现到后期竟然只判断了登录态权限校验没做。追问它为什么没写它的回复是“根据上下文推断此处不需要权限”。这种“自信的理解偏差”是AI生成代码的第一大杀手。我的解法是两条腿走路第一条把任务卡写得特别细验收标准必须量化、可执行比如“非主管角色调用该接口必须返回403”不写“需要权限控制”这种模糊表述第二条依赖Agent C的审查兜底提醒它在审查时把任务卡里的每一条验收标准和代码行为逐一对应缺少权限判断等问题就会被打回返工。第二个问题是幻觉API多见于Rust侧。我在让Agent B补一段读写文件并做并发处理的Rust代码时它使用了某个并不存在于标准库的并发工具函数编译直接报错。解决这个问题没有捷径只能是我自己在编译错误面前逐行排查把幻觉API换成了标准库的成熟方案。这里延伸出一个思考热词里总被提到的“基于Rust语言的AI Agent”我在这个项目里用到的程度比较克制。Rust本身做高性能数据处理服务没有任何问题但让Agent大规模生成Rust代码当前阶段我还不太推荐。相比Python和TypeScriptRust代码一旦生成错误纠错成本高得多这会让“Agent提效”大打折扣。第三个问题是Token成本控制。规划Agent在分析需求时会一次性读入很长的项目背景Coder在实现大任务时还会反复读入之前的代码Token消耗大得吓人。我一度担心项目做完后AI工具账单会爆炸。后来我做了两个调整一是严格控制Agent B的输入只让它读当前任务相关的代码文件不把整个项目一股脑塞给它二是给每个Agent设置一个“输出精简模式”比如要求Agent C只输出严重问题和打回原因不要长篇大论地写分析报告既省Token又没降低审查质量。整个项目跑下来三个Agent的Token消耗折合人民币大概400多元加上云服务器费用总共不超过600元。相较于4人团队2个月的人力成本这个成本完全可以忽略。第四个问题是Agent的“过度自信”。这个问题在一开始尤其严重Agent B写完代码后它会自信地说“代码已完成测试全部通过”但实际上测试用例一个都没跑。后来我在Agent B的工作流里硬性加了“必须贴出测试执行命令和输出结果”的要求它才老实下来。从此我发现给Agent设定行为约束比给它灌知识更重要。最后一个问题是多Agent协作时的模型幻觉释放。因为Agent A想把数据模型设计得特别完整Agent B又想把功能实现得特别全面两者叠加很容易把一个简单需求放大成一个怪物系统。比如本来一个客户管理模块Agent A给出了30多个字段的复杂表结构Agent B又加上了批量导入、历史版本、数据对比等一堆额外功能。面对这种“撒欢行为”我就是砍。需求文档没有明确提及的功能一律不进开发范围这是我对所有Agent的绝对红线。6. 什么样的项目适合用Agent交付以及最后的几条心得这套3 Agent交付的打法并不是所有项目都能复制的。我做完这个项目后仔细想了想它的适用边界毫无保留说清楚。最适合的是“逻辑闭环清晰、需求边界稳定、没有太多历史包袱”的企业业务系统。比如订单管理、审批流、库存管理、CRM这种业务规则明确CRUD占比高状态流转可预测AI Agent能发挥最大价值。反过来如果项目是探索性的、需求天天变或者要深度集成一堆老旧系统甚至要处理大量晦涩的业务历史遗留逻辑我劝你不要硬上Agent老老实实靠人一步步摸。我的最终交付配置很简单4人团队实际全职投入只有我一个人你如果也想像我一样压缩团队前提是你自己有足够的技术判断力外加三个Agent分别承担规划、编码、审查。项目结束时代码仓库里大约有3000多次提交超过1100个测试用例最终项目按期交付业务方验收一次通过。最后分享几条我自己最深的体会也是这个项目真正教给我的东西第一AI Agent交付项目人永远是最关键的瓶颈和天花板。Agent可以把你的产能放大但它不会替你思考。需求怎么拆、边界怎么定、Agent产出怎么把关、哪些功能不能做这些判断只能由人来完成。别指望扔一个需求给Agent它就能自己把项目做完。第二流水线式协作优于自由式协作。3个Agent各司其职、上一个的输出是下一个的输入远比一个全能Agent什么活都干要稳定。后者看着灵活实际跑起来上下文混乱和各种幻觉会让你崩溃。第三审查永远不要省。规划、编码、审查这个铁三角里审查Agent的价值是被我严重低估后重新抬起来的。它不只是找Bug它还在持续用任务卡校准Agent B的“跑偏倾向”这种“用代码审查对抗代码幻觉”的机制是整个模式稳定运行的定海神针。第四迭代节奏越短越好。我的实操经验是把大任务切小让“编码—审查—修复—复核”这个循环以2到3小时为单位推进比让Agent长跑几小时交一个大结果要靠谱得多。每一个小循环都是一次纠错和校准的机会。这套方案现在还能不能继续优化我觉得可以。下一步我想把Agent A和Agent C的上下文做成知识库形式把项目历史决策、常见返工原因沉淀下来让它们在后续项目中越用越聪明。但那是下一篇的题材了这3周的项目先记到这里。