★ FEATURED ARTICLE 周六晚上十点微信弹出一条消息一位老同学转来一份企业需求文档附着一张外包报价单直排 4 人开发组工期 2 个月。我翻完那二十几页需求回了一句话“3 周我一个人做用 AI Agent 跑。”三周后项目按期交付。客户验收通过源码、数据库脚本、部署文档、操作手册一应俱全。这不是一个赛博神话而是一场有方法、有边界、有代价的工程实验。今天这篇复盘我想把这 3 周里三个 AI Agent 的分工方式、推进节奏、质量守门手段以及哪些项目不适合这么干完整拆开讲清楚。适合正在做中后台业务系统、又对 AI Agent 开发模式感兴趣的人参考。1. 一个从周六晚开始的判断为什么 3 周能顶 4 人 2 个月先还原一下这个项目到底是什么。它是一家做区域供应链贸易的企业内部系统核心模块包括用户与 RBAC 权限管理、商品/客户/供应商主数据维护、订单管理含四级审批流、库存台账、销售/采购统计报表导出、站内待办通知外加一个后台审计日志。整张表结构理出来大约 24 张业务表前端是标准的管理后台页面——表格、表单、弹窗、下拉选择、树形结构没有实时计算没有高并发没有复杂算法。这类系统放在外包公司手里报价单上写 4 人 2 个月并不算宰人。但你要知道那 4 个人的时间并没有全花在写代码上。1.1 外包报价的真实成本结构4 人团队典型构成是2 个后端、1 个前端、1 个需求兼测试。看起来是 8 人月但真实的工作量拆开算纯编码和数据库设计的时间通常只占 1.5 到 2 人月。剩下的大头去哪了需求沟通会议、反复确认字段含义、页面样式来回调整、联调时的等待、测试返工、写文档、再等客户签字确认。每多一个人沟通链路就多一截信息的衰减和失真就多一层。人月神话在这里体现得淋漓尽致——项目时间不是被代码撑长的而是被协作放大系数撑长的。而 AI Agent 压缩的恰恰不是“打字速度”而是这一整段协作放大系数。一个人坐在电脑前向 Agent 描述需求、让 Agent 生成代码、再以人的判断力去验收沟通链路从“客户-需求-后端-前端-测试-客户”变成了“客户-我-Agent-我-客户”。链条短了返工就少时间自然就压下来了。1.2 敢接单的三个底气接单之前我给自己做了三轮评估不是拍脑袋。第一业务确定性足够高。这种供应链贸易管理系统市面上有大量成熟参照模板字段怎么设计、审批流怎么走、报表怎么算都是高度模式化的东西。Agent 在训练数据里见过无数遍生成质量有保障。反过来说如果是个需要发明新算法的项目再强的 Agent 也顶不了一个算法工程师。第二技术栈是最主流的 Web 开发组合。后端用 Django DRF前端用 Vue 3 Element Plus数据库 MySQL部署用 Docker Compose。这条路太成熟了Agent 的语料覆盖度极高生成的代码基本不会跑偏。第三需求方愿意配合高频验收。我明确要求每周三、周五固定做两次线上会议按验收清单逐条过。对方业务负责人是产品出身的老板能拍板不摇摆。这一点比技术栈还重要——如果需求方两周才回复一次3 周交付就是天方夜谭。同时我立了三道底线不负责存量数据迁移不做超出需求文档的个性化定制承诺不承担 7×24 运维责任。这三个边界把不确定性挡在项目范围之外也让 Agent 的工作可以安心地限定在一个清晰闭环里。1.3 最核心的认知转变很多人问我三个 Agent 是不是三个不同的 AI 产品其实不是。关键在于“角色拆分”而不在于工具数量。我把一个软件开发团队的工作方式压缩成了三个角色每个角色由一个独立配置的 Agent 承担人为中心做翻译和仲裁。这句话值得多看两遍。AI Agent 的主流架构不管各家白皮书怎么写落到真实项目里本质就是模型 工具调用 上下文管理 人的决策闸门。架构图是虚的信息流是实的。2. 三个 Agent 的角色分配我在电脑里装了一支“外包团队”接项目之前我花了两天时间干了一件事给三个 Agent 写“岗位说明书”。这件事决定了后面所有环节的流畅度。2.1 Agent-T负责需求拆解与方案设计的技术负责人Agent-T 的定位是“技术负责人兼架构师”我不让它写一行业务代码只让它干三件事读需求文档、输出数据库表结构设计、产出接口契约和验收用例。每拿到一段业务描述我会把原文贴给它同时附上一句固定约束“不要解释直接输出表结构 DDL包含字段注释不要假设不确定的业务规则列出来让我回答。”这套指令看起来简单实际效果差异巨大。没有约束的 Agent 会写出一堆正确的废话有了输出格式约束它给出的就是可直接落地的建表脚本。它产出的东西长这样-- 订单状态机约束 -- draft - submitted - first_approval - second_approval - approved / rejected CREATE TABLE order_main ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号规则SOyyyyMMdd序列号, customer_id BIGINT NOT NULL COMMENT 客户ID关联 customer_main.id, amount_total DECIMAL(12,2) NOT NULL COMMENT 订单总金额含税, ... );到这一步我只需要做一件事逐字段核对业务口径。比如“订单总金额含税还是不含税”“客户编码是否允许修改”这些业务问题我在需求确认会上拍板然后把答案回填给 Agent-T让它修订表结构。这个回合制问答最多两轮数据库设计就冻结了。2.2 Agent-D负责把方案变成代码的主力开发Agent-D 是纯编码角色也是三周里工作量最大的 Agent。它的输入只有三样东西Agent-T 产出的表结构 DDL、接口契约文档、以及我按模块拆分好的“任务卡”。任务卡是我这一套打法里的核心发明格式固定为四段# 任务卡订单审批接口 背景订单状态机为 draft - submitted - first_approval - second_approval - approved/rejected 需求实现 POST /api/order/{id}/approve 接口 规则 1. 仅状态为 first_approval 的订单可执行此操作 2. 审批人必须属于对应审批层级角色否则返回 403 3. 审批通过后写 operation_log 表记录操作人与时间 4. 金额精度统一 DECIMAL(12,2)禁止使用 float 产出要求DRF ViewSet Serializer 单元测试需通过 pytest任务卡写得好不好直接决定 Agent-D 的产出质量。我踩过的坑是如果任务卡里不写“禁止使用 float”它真的会给你甩两个 float 字段出来如果不写“需通过 pytest”它会在你运行测试失败后回答“逻辑上没问题”。不是 Agent 笨是它真的会把模糊指令往对自己最有利的方向理解。2.3 Agent-Q负责挑毛病和补文档的测试兼文档Agent-Q 是质检角色专门负责唱反调。它的工作内容是读 Agent-D 生成的代码找漏洞跑测试用例分析失败日志根据最终代码补齐接口文档和部署手册。一个容易忽略的细节是Agent-Q 和 Agent-D 的会话是严格隔离的。我不让 Agent-Q 直接修改代码它只输出问题清单和修改建议由我把建议转述给 Agent-D。为什么这么设计因为如果让同一个 Agent 既写代码又检查自己的代码它会倾向于为自己的逻辑辩护很难发现设计层面的问题。这就好比你不该让写代码的人独自完成代码评审。人为中转看似多了一道手实际是挡住了“自我感觉良好式”的漏检。另外Agent-Q 还承担了一个特殊任务解释 token 预算。很多人问 AI Agent 的 token 是什么意思简单说就是模型处理文本的上下文计量单位。Agent-D 在长对话里一旦超过上下文窗口就开始出现两种症状忘记早期的字段命名规则或者突然推翻自己之前的实现。所以我的做法是每个模块的任务卡都开一个新的对话会话把该模块的背景重新粘贴一遍。宁可多花点 token 做上下文重置也不能让 Agent 带着混乱的记忆继续编代码。三个 Agent 之间不直接通信全部信息经由我来转发。这个设计在外面看来很低效但恰恰是稳定三角的关键。我后补了一个用 Rust 写的几十行脚本做任务分发和日志归集纯粹是因为 Rust 编译出来是个单文件放到服务器上省心不依赖 Python 环境。不要神话这个脚本它就是一个人肉消息队列而已。3. 三周推进的真实节奏人盯节点机器跑流程三周不是均匀铺开的而是按“地基-主体-收尾”三个节奏走的。这里我把每周的安排原样贴出来你能直观看到人和 Agent 的时间是怎么咬合的。3.1 第一周地基和骨架我盯契约第一周的核心目标是把地基夯实数据库建库建表、Django 工程骨架、DRF 基础配置、登录认证和 RBAC 权限框架、以及前后端联调的基础通道。前三天Agent-T 已经把 24 张表全部设计完我核完业务字段后就进了数据库初始化阶段。Agent-D 的活是写用户认证模块和菜单权限接口。这里有个非常重要的节点接口契约必须在写代码之前冻结。我先把第一版 API Schema路径、方法、请求参数、响应结构发给前端部分的 Agent-D让它按这个契约开发页面同时让同一个 Agent-D 在另一个会话里写后端接口。看似是同一个工具但会话隔离保证了两个方向的代码不会互相“商量着来”最终以契约为唯一标准。第一周后半段我几乎把所有精力花在代码走读上。Agent-D 生成的 RBAC 代码表面上能跑通登录但我点开数据库一看权限菜单表里居然藏着一个裸写的超管删除接口没有做角色校验。这种问题单元测试测不出来必须人肉走读。说句实在话第一周每晚十点之前我都在改 Agent 的“低级错误”但从第二周开始这些低级错误明显减少因为我在任务卡里写清了边界规则。3.2 第二周功能并线三轮验收替代例会第二周进入主体功能开发主数据维护、订单管理、审批流、库存台账。这一周的节奏可以用“三回合”总结。上午回合我把当天的任务卡批量喂给 Agent-D每张卡对应一个小模块限时让它独立产出。下午回合我逐个跑测试、看运行效果、把失败反馈给 Agent-Q 定位。晚上回合我汇总 Agent-Q 的问题清单能当场拍板的就直接回指令给 Agent-D 修订需要业务确认的先记进待办准备到周五的验收会上和客户过。这一周取代了传统团队的每日站会和周例会。三轮验收不是跟人开会而是跟代码开会。每完成一个模块我会在浏览器里把页面点一遍模拟业务人员操作从新建订单一路走到审批完成。就是这一步模拟让我抓出了审批流后端实现里一个隐蔽的状态机跳级 bugAgent-D 和 Agent-Q 都没发现它因为我故意测试了一条没有权限的审批操作而 Agent 写测试时只会按“正常路径”写。3.3 第三周联调收尾最后的红利来自上文第三周的核心词是“联调”。后端模块多了之后跨模块的数据流问题开始暴露。比如订单里要显示客户等级但客户主数据的等级字段改动了订单模块的序列化器不知道。这种问题靠 Agent 单点测试测不出来必须靠我建立一份跨模块字段依赖表把每个字段的引用关系列出来再逐个验证。第三周的另一个大头是报表导出。统计 SQL 本身不难难的是导出大文件时的内存控制以及 Excel 格式兼容。Agent-D 第一版导出逻辑直接把全量数据载入内存订单量一大服务器直接内存溢出。我给它的修正指令加了一句“必须使用分页流式查询每 5000 行写一批”改完内存占用降了七成。最后两天我开启了一个特殊的“回合制验收”每隔两小时我把测试环境跑出来的报错原样丢给 Agent-Q让它先做定位再给出修复方案。注意我只让它定位和给方案最终改不改、怎么改还是要回到 Agent-D 那边或者我自己直接改掉。最后 48 小时我修了 30 多个问题正式验收时没有再出现一个 P0 级阻塞项。4. 守住企业项目质量底线的四个闸门3 周快是快但企业项目不比个人玩具交付时不需要运气需要的是可验证的标准。我担心别人问我“AI 写的代码能上线吗”所以从一开始就设计了四道闸门。4.1 闸门一分级验收清单而不是相信任何人的自我检查我在项目第二天就拉了一份验收清单全部分成三级级别定义示例P0阻塞交付的问题权限校验缺失、导出崩溃、金额精度错误、审批状态错乱P1影响正常使用体验的问题报表列宽错误、筛选条件丢失、操作无确认提示P2优化建议不影响验收按钮位置、页面加载动画、提示文案措辞每周三全量走查一遍 P0 清单每周末过一遍 P1。验收不是对着需求文档看而是把每个功能从头到尾操作一遍用真实业务数据跑。Agent-D 的自我报告里经常出现“所有测试通过功能正常”但我只要人肉点一遍页面一定能找到至少三处它没覆盖到的交互边界。所以我的规则很简单Agent 说完成不算完成页面能跑通才算完成。4.2 闸门二测试倒逼让 Agent 先写测试再写实现我一直信奉测试先行这个习惯在管 AI Agent 时意外有用。我给 Agent-D 的任务卡里明确要求“先输出 test 文件再输出实现文件”。这不是形式主义因为当 Agent 必须先写测试时它实际上被迫把需求细节想清楚了。如果测试用例里缺了“审批人无权限”分支我在走读 test 文件时就能发现而不是等到实现代码写完再补救。这一招的效果很明显。Agent-D 生成的测试覆盖率大约在 80% 左右剩下 20% 的边界条件我和 Agent-Q 会各补一轮。到交付时pytest 跑一次 300 多个用例全部通过。4.3 闸门三代码走读的四查清单Agent 生成的代码再快我也坚持每天至少走读一小时。我的走读不是通读而是带着四查清单去的一查安全所有 SQL 必须参数化禁止拼接字符串日志里禁止输出身份证号、手机号等敏感字段。二查业务规则金额计算、状态流转、审批层级这些关键逻辑必须逐行对着需求确认。三查异常处理凡是外部调用发短信、连文件服务器必须有 try-catch 和降级方案不能一崩到底。四查性能边界列表查询必须分页导出必须流式写循环内禁止 N1 查库。这四个问题Agent 在每个新模块都会重犯一遍。第一周我每天都能抓到到第三周就明显少了。不是 Agent 变聪明了是任务卡里的“禁忌清单”已经覆盖了大多数坑。4.4 闸门四数据安全与交付物完整性关于数据安全我必须多说一句。整个开发过程中我从未把真实企业数据喂给任何云端 Agent 模型。测试数据全部用脚本生成姓名、电话、金额字段全部脱敏。这不是小题大做企业合同里往往有保密条款把客户名单塞进外部模型训练池出事的后果谁也担不起。本地部署的模型处理敏感需求云端模型只处理脱敏样本和纯技术问题这条红线我守了三周。交付物方面我定了六个必须交付的目录源码工程、数据库初始化脚本、部署文档、操作手册、接口文档、验收测试报告。前三个由 Agent-Q 生成初稿后三个我和它一起修订。部署文档生成完后我做了三次干净环境从零部署演练——自己注册域名、装 Docker、拉镜像、跑数据库迁移——每次演练都能发现文档缺步骤。这个演练千万别让 Agent 代劳因为 Agent 不会犯“新手安装错误”而你交付的对象偏偏是新手。5. 这件事能不能复制边界、代价与清醒认识复盘完三周我得泼几盆冷水。这套“三个 Agent 干翻一个团队”的打法很爽但不是万能药它有一堆适用边界和隐性代价。5.1 三类项目适合四类项目千万别碰先说适合的。第一类管理系统类订单、库存、客户、审批、报表业务规则清晰界面形态标准市面上有大把参照物。第二类流程型工具工单跟进、合同管理、项目协作本质是数据流转和状态转换。第三类内部中后台用户量小、并发低、逻辑主要是 CRUD 加少量复杂查询性能要求不高。不适合的也清清楚楚。核心交易系统别碰——支付、结算、账务这类涉及资金和风控的容错率为零AI 生成代码的不确定性不该被这里吸收。强低延迟场景别碰——实时竞价、消息推送这类对响应时间极度敏感的需要深度调优Agent 给不了那么细。重遗留系统改造别碰——如果项目要跟一个跑了十年的老系统对接里面的历史包袱和隐晦规则Agent 从需求文档里看不出来。还有安全合规极重的场景也别碰——金融、医疗、政务领域审计要求你解释每一段代码的逻辑来源Agent 生成过程没法提供这种追溯链。5.2 一拖三的真正成本是碎掉的时间很多人看到“3 周做完”会想象我很轻松真实情况完全相反。三周里我每天的有效工作时间在 10 小时以上而且在三个 Agent 之间来回切换注意力是反复被打断的。最累的部分不是敲键盘而是审代码、补上下文、转换角色。早上还是架构师跟 Agent-T 过表结构中午变成测试工程师跟 Agent-Q 抠测试用例下午又切换到项目经理跟客户对验收进度晚上还要当文档编辑改部署手册。这种“单兵指挥官”模式脑力消耗比在 4 人团队里当开发组长高得多。省下的是协调成本增加的是决策压力。如果你只是公司里负责一个模块的普通开发直接套用这套 Persona 容器方法大概率会被各种流程卡住因为你不是最终拍板的人。5.3 留给未来团队的是一块“冷启动蛋糕”最后一点也是我最想提醒的AI 生成式开发最大的坑不在开发期而在交付后的维护期。三周压出来的代码大量背景信息是靠注释、文档和任务卡里的上下文保存下来的。如果接手的人不懂这套上下文他会对着一堆“聪明的代码”发愣。所以我在交付物里留了一份百来行的“项目血泪史”专门记录 Agent 容易犯的错误、已经踩过的坑、以及为什么要这么设计。这不是给客户看的是给未来维护者应急用的。这也是我建议所有做 AI Agent 交付项目的团队必须额外养成的习惯把隐性知识显性化不然后续的维护成本会把你三周省下来的时间全吃回去。最后再说句掏心窝子的。三周做完这个项目我最大的收获并不是“3 周”这个数字而是想明白了一个问题AI Agent 不是取代工程师而是把工程师从重复劳动中解放出来去干那些真正需要人的判断力的事——定义边界、把守质量、承担决策。这 21 天里我像一个既当架构师又当监理又当操作工的单人施工队而 Agent 是手底下干活麻利、但需要不停给他画红线的新工人。能画清楚红线是一个人未来几年最值钱的能力。
阅读完成 · 觉得有帮助？
