1. 先把这个项目的底牌摊开3周交付企业项目到底靠什么看到3个AI Agent交付一个企业项目4人团队2个月我3周做完这个标题很多人的第一反应是吹牛或者标题党。我先把背景交代清楚这是一个真实的中型企业内部管理系统项目包含权限体系、审批流、报表导出、消息通知四大模块原本排期是4个人做2个月。我实际投入的是3个AI Agent加上我自己一个人3周完成交付并上线。这里说的AI Agent不是那种只会聊天的对话框而是能读代码库、能改文件、能跑测试、能提交PR的编码智能体。我用的组合是一个负责后端接口和业务逻辑一个负责前端页面和联调一个负责测试用例、CI配置和代码审查。我自己则充当架构师、产品经理和最终把关人。为什么能压缩到3周核心不在于AI写代码有多快而在于并行度和上下文管理。传统4人团队最大的损耗不是写代码本身而是沟通、等待、环境冲突和返工。AI Agent没有情绪、不需要开会、不会因为分支冲突互相等待——前提是你得把工程基础设施搭对。这个项目里真正起决定作用的三样东西是git worktree隔离工作区、CI流水线自动把关、RAG知识库喂上下文。这三个词也是这次被搜得最多的我下面会一个一个拆开讲。这篇文章适合谁看如果你是一个人接私活、小团队赶交付、或者想在自己项目里引入AI Agent提效那这篇就是给你写的。如果你指望复制粘贴就能躺赢那可能会失望——AI Agent提效的前提是你自己得懂工程知道哪里该卡、哪里该放。2. 整体方案设计为什么是3个Agent而不是1个或10个2.1 Agent数量不是越多越好3个是并行度和协调成本的平衡点我一开始试过用1个Agent串行做所有事结果是它写完后端再写前端时上下文已经被前面的代码塞满了开始出现忘记前面接口定义的情况改一个字段名要来回好几轮。后来我又试过5个Agent问题变成了互相覆盖文件、依赖版本打架、合并冲突处理到崩溃。最后定在3个分工是这样的Agent角色负责范围主要工具交付物后端Agent接口、数据模型、业务逻辑编码Agent 终端后端服务代码、API文档前端Agent页面、组件、接口联调编码Agent 浏览器预览前端代码、联调记录质量Agent测试、CI配置、代码审查编码Agent CI测试用例、流水线配置、审查报告3个的好处是每个Agent的上下文窗口不会被撑爆职责边界清晰出问题能定位到具体是谁干的。再多就会进入协调成本大于收益的区间这个经验值跟很多团队反馈的3到5个Agent是甜点区是一致的。2.2 用git worktree做物理隔离而不是靠branch切换这是整个项目最关键的一个工程决策。很多人第一反应是用git branch给每个Agent开一个分支但实际用下来会踩坑多个Agent如果共享同一个工作目录切换分支时未提交的改动会互相干扰Agent A正在改的文件可能被Agent B的git checkout搞乱。git worktree解决的就是这个问题。它允许你把同一个仓库的不同分支同时检出到不同的物理目录每个目录是独立的工作区互不影响。区别可以这样理解git branch同一间办公室里的不同抽屉你一次只能打开一个抽屉干活。git worktree同一栋楼里的不同房间每个房间可以同时有人干活共享同一套水电同一个.git仓库。具体操作# 在主仓库目录下为每个Agent创建工作区 git worktree add ../proj-backend -b feat/backend git worktree add ../proj-frontend -b feat/frontend git worktree add ../proj-qa -b feat/qa # 查看所有工作区 git worktree list这样后端Agent在../proj-backend目录里干活前端Agent在../proj-frontend里干活各自git commit互不干扰。合并的时候走正常的PR流程由质量Agent和我来把关。注意worktree的每个工作区是独立目录但共享同一个.git对象库所以磁盘占用不会翻倍这是它比克隆多份仓库更优雅的地方。2.3 CI是AI Agent的刹车片没有它别谈提效AI Agent最大的风险是看起来很对但实际是错的。它写的代码能跑通编译但可能漏了边界条件、可能引入了安全漏洞、可能破坏了原有功能。如果没有人把关3周做完的代价可能是上线后3个月填坑。CI流水线在这里扮演的角色就是自动刹车片。每次Agent提交代码CI自动跑单元测试、静态检查、构建、依赖漏洞扫描。任何一项挂了PR就不允许合并。这样我作为人类只需要审查CI通过了的代码而不是从零开始看每一行。这个项目里我配的CI阶段lint阶段代码风格和静态分析几十秒出结果。test阶段单元测试加集成测试覆盖率门槛设80%。build阶段确认能正常构建打包。security阶段依赖漏洞扫描高危直接阻断。质量Agent的工作就是维护这套CI配置并且在CI挂掉时去修复。实测下来CI把大约70%的低级错误挡在了合并之前我的审查精力可以集中在架构和业务逻辑上。2.4 RAG知识库解决Agent不懂我们项目的问题AI Agent的通用能力很强但它不知道你这个项目的数据库表结构、接口命名规范、历史遗留的特殊逻辑、内部组件库用法。如果不喂这些上下文它写出来的代码风格会跟项目格格不入你得反复纠正。RAG检索增强生成在这里的作用就是给Agent配一个项目知识库。我把这些东西整理进去数据库schema和字段说明现有接口的请求响应示例内部组件库的使用文档编码规范和命名约定历史踩坑记录Agent每次干活前先检索相关知识再动手。这样它写出来的代码第一次就能贴近项目风格返工率大幅下降。3. 核心细节拆解每个环节到底怎么落地3.1 上下文工程决定Agent产出质量的第一变量很多人用AI Agent效果差根本原因不是模型不行而是喂的上下文不对。我踩过的坑是一开始直接把整个代码库丢给Agent结果它被无关文件干扰抓不住重点。后来我改成精准投喂任务级上下文只给跟当前任务相关的文件比如做用户模块就只给用户相关的model、service、controller。规范级上下文通过RAG检索编码规范而不是全文塞进去。示例级上下文给一两个照着写的样板代码比写一堆文字描述管用。这里有个实操心得给Agent的上下文要像给新同事交接工作一样。你不会把公司所有文档甩给新同事让他自己看而是告诉他这个功能参考XX文件注意XX规范。对Agent也一样。3.2 任务拆解粒度一个Agent一次只干一件事我见过最常见的失败模式是给Agent一个巨大的任务帮我实现整个审批流模块。结果它要么做一半卡住要么做出来的东西跟预期差很远。我的做法是把任务拆到单个Agent单次能完成的粒度大概是一个接口加它的测试这种规模。比如审批流模块拆成审批单数据模型和迁移脚本创建审批单接口审批单查询接口审批动作接口同意/驳回审批历史记录接口每个接口对应的单元测试每个子任务单独交给Agent完成后立即提交、跑CI、合并。这样即使某个子任务做错了回滚成本也很低。3.3 代码审查AI审AI人审关键路径质量Agent会先做一轮自动审查检查命名规范、明显的逻辑漏洞、重复代码、缺失的错误处理。但AI审查不能全信我作为人类重点审查这几类涉及权限和安全的代码AI很容易写出看起来对但能被绕过的权限判断。涉及金额和数据的代码计算逻辑必须人工核对。数据库迁移脚本改错了可能丢数据必须人工确认。对外接口的契约字段类型、必填项、错误码这些一旦定错影响面大。经验AI审查适合抓风格和低级错误人类审查适合抓业务正确性和风险。两者分工不要指望AI全包。3.4 并发冲突处理worktree之外的协调机制即使有worktree隔离Agent之间还是会有逻辑冲突。比如后端Agent改了接口返回结构前端Agent还在按老结构联调。我的处理方式是接口契约先行开工前先把API文档定死前后端Agent都按这个文档干活。每日同步点每天固定时间做一次合并把各worktree的成果合到主干跑一次全量CI。冲突早暴露宁可每天合并一次小冲突也不要攒到最后合并大冲突。这套机制下来整个项目期间没有出现过合并地狱。4. 实操过程3周时间线是怎么排的4.1 第1周搭地基不写业务代码第一周我几乎没让Agent写业务代码全部精力放在基础设施上搭好git worktree结构3个工作区就位配好CI流水线跑通lint、test、build、security四个阶段建好RAG知识库把schema、规范、示例整理进去定好API契约文档给每个Agent写好角色说明书系统提示词这一周看起来没产出但它是后面两周能起飞的前提。我见过太多人跳过这步直接让Agent写代码结果第二周全在收拾烂摊子。4.2 第2周三线并行火力全开第二周是产出爆发期。三个Agent并行后端Agent按API契约实现接口每完成一个就提交、跑CI。前端Agent按契约做页面用mock数据先联调。质量Agent同步写测试用例并维护CI。我这一周的主要工作是审查PR、处理Agent卡住的问题、调整任务优先级。平均每天合并10到15个PR。这里的关键是保持主干随时可发布任何时刻拉出来的代码都是能跑的。4.3 第3周联调、修bug、上线准备第三周前后端真正对接问题集中爆发。这时候质量Agent的价值体现出来了它写的测试用例帮我快速定位是前端问题还是后端问题。我自己的精力主要花在处理联调中发现的接口不一致补充边界场景的测试准备部署脚本和上线检查清单做一轮完整的人工验收第三周末项目上线。从启动到交付正好3周。4.4 关键参数与配置参考为了让这套流程可复现我把几个关键配置列出来配置项取值说明Agent数量3后端/前端/质量worktree数量3与Agent一一对应CI阶段数4lint/test/build/security测试覆盖率门槛80%低于则阻断合并合并频率每日至少1次避免冲突堆积任务粒度单接口级一个Agent单次完成5. 常见问题与排查技巧实录5.1 Agent幻觉出不存在的方法或字段这是最高频的问题。Agent会自信地调用一个项目里根本不存在的函数。排查思路先看它检索到的上下文是不是过时了RAG知识库有没有及时更新。解决方法是在CI里加类型检查和静态分析这类错误在编译阶段就能暴露不用等到运行时。5.2 CI频繁挂掉Agent陷入修了又挂的循环有时候Agent改一个地方CI挂了它去修结果又挂了别的地方。这种情况通常是任务粒度太粗。我的处理是暂停Agent人工介入把任务拆细然后重新交给它。硬让Agent自己循环修复往往越修越乱。5.3 前后端接口对不上根因通常是契约没定死或者某一方偷偷改了字段。解决办法是把API契约做成CI的一部分接口变更必须同步更新契约文档否则CI报错。这样接口不一致在合并前就被拦住了。5.4 RAG检索不到相关内容常见原因是知识库切分粒度不对。切得太碎检索出来的是碎片切得太大检索出来一堆无关内容。我的经验是按一个完整知识点切分比如一个接口的说明作为一个块而不是按固定字数硬切。5.5 常见问题速查表问题现象可能原因处理方式调用不存在的方法上下文过时/幻觉更新RAG加静态检查CI反复挂任务粒度过粗拆细任务人工介入接口对不上契约未同步契约纳入CI校验检索不准切分粒度不当按知识点切分合并冲突多合并频率低提高每日合并次数5.6 几条踩坑换来的经验别让Agent碰生产配置数据库连接串、密钥这类东西Agent只读不写改动必须人工。每个Agent的提示词要写死边界明确告诉它你只负责X不要碰Y否则它会越界改别的模块。保留人工回滚能力每次合并前确保能一键回滚AI再靠谱也要留后路。定期清理worktree任务完成后及时git worktree remove不然目录越堆越多。6. 这套打法能复制到什么程度先说结论这套方法在中等复杂度、需求相对明确的企业项目上可复制性很高。它不适合的场景是需求天天变、涉及大量遗留系统改造、或者对安全性要求极高的核心系统——这些场景AI Agent能帮上忙但压缩不了那么多时间。我个人在实际操作中的体会是AI Agent提效的本质不是AI替你写代码而是你从写代码的人变成管流程的人。你的价值从敲键盘转移到拆任务、定契约、搭CI、审关键路径。这三周里我写的代码可能不到总量的10%但项目的架构决策、风险判断、验收标准全是我定的。最后分享一个我觉得最值钱的小技巧把每次Agent踩的坑记进RAG知识库。第一次它犯的错第二次检索到这条记录就不会再犯。这个知识库会随着项目推进越来越聪明到后期Agent的返工率会明显下降。这比任何提示词技巧都管用。