企业官网建设流程全解析

先把结论放这儿：我用了 3 个 AI Agent，把原本 4 人团队排期 2 个月的企业内部项目，压到 3 周交付，功能全量上线，三个星期内没有出现 P0/P1 级线上问题。这不是拿个 to-do list demo 糊弄人，而是一个 20 多个业务模块的订单管理系统，有客户、订单、审批流、库存联动、对账报表、多级权限。这篇文章不聊虚的，把我当时怎么拆分 Agent 角色、怎么选工具、怎么给三个 Agent 定交接协议、token 花了多少钱、踩过哪些坑，全部摊开讲，适合所有想用 AI Agent 提速却又怕翻车的朋友参考。

先说清楚我的处境：项目是一家制造企业的内部订单管理系统，需求文档 30 多页，散落着各种 Excel 表、聊天记录和口头补充。原团队配置是 1 个产品 + 1 个前端 + 1 个后端 + 1 个测试，计划工期 8 周。我实际是一个人，用三个 Agent 分别承担“需求方案”、“开发编码”、“质检验收”三个角色，自己只做架构决策、需求裁决和最终代码把关。3 周交付，质量不缩水，核心靠的不是某个 Agent 多聪明，而是把工作流拆成了三道互相校验的闸门。

1. 项目拆解：先搞明白企业项目的真实盘子

很多人一听“企业项目用 AI Agent 做”就觉得不靠谱，其实问题不在 AI 行不行，而在你有没有把项目的盘子拆清楚。企业项目之所以慢，通常不是代码难写，而是需求散、口径乱、联调等、测试返工。

1.1 看起来 2 个月的工作量，实际是多少人日

我给这个项目粗略做过估算，按原团队 4 个人、40 个工作日计算，累计投入约 160 人日。拆开看大概是这样的：

• 需求梳理、原型确认、反复澄清：约 10 个工作日
• 数据库设计、接口契约定义：约 5 个工作日
• 后端开发：约 20 个工作日
• 前端开发：约 15 个工作日
• 前后端联调：约 5 个工作日
• 测试执行与缺陷修复：约 10 个工作日
• 其余是被会议、等待、返工吃掉的时间

这个账拆出来之后你会发现，真正“写代码”的部分只占一半左右，另一半都在做澄清、对齐、修改、验证。AI Agent 能压缩的，恰恰是后面这一半，因为它的读取速度和产出速度远高于人，而且不会因为重复劳动而产生情绪疲劳。

1.2 传统协作里的时间黑洞

企业项目里最磨人的几个地方，我这次全遇到了。第一是需求口径不一致，业务方描述一个“订单状态”，产品理解一种，后端实现一种，前端展示又是一种，等到验收才发现对不上。第二是联调等待，后端接口字段命名不统一，前端拿着 Mock 数据先进度，真正联调时改来改去。第三是测试滞后，代码写完了才开始补测试用例，缺陷集中爆发在项目末期。

这些时间黑洞的共同点是：它们都发生在人与人之间的信息传递环节。信息每经过一个人，就会损耗一次。AI Agent 解决这个问题的方式很简单——把信息变成结构化文档，让每个环节都基于同一份规格去工作。

1.3 三个 Agent 的切入点

我的策略很明确：与其让一个 Agent 从头干到尾，不如把流程切成“需求→实现→验收”三段，每一段配一个专职 Agent。这个思路参考了当前 AI Agent 主流架构里的两种路线：一种是单 Agent 自主完成所有事，另一种是多 Agent 协作，各有适用场景。单 Agent 的优点是简单，缺点是自我确认偏差严重，写出来的代码自己检查自己，容易“盲区一致”。多 Agent 协作虽然编排成本高一些，但每个 Agent 只做自己擅长的事，而且互相之间形成制衡。对这个项目来说，三层的粒度刚刚好。

2. 三个 Agent 的分工与选型逻辑

三个 Agent 不是简单把任务丢给同一个模型跑三遍，而是每个 Agent 有独立的系统提示词、独立的输入输出规范和独立的工具集。下面把每个角色的职责和选型理由说透。

2.1 Agent A：需求与方案智能体（大脑）

Agent A 的输入是那一堆乱七八糟的原始材料：30 页 PRD、十几张 Excel 表、聊天记录里零散的补充说明。它的输出必须是三样东西：需求清单、数据字典、API 契约文档。

需求清单我要求它每条都带编号、模块、优先级、验收标准，方便后续跟踪。数据字典规定到表名、字段、类型、约束、索引，连枚举值的含义都要写清楚。API 契约则细化到 method、path、请求参数、响应结构、错误码。这套东西一出来，后面两个 Agent 才有据可依。

我这里用了一个比较核心的提问模板，第一步不让 Agent 自由发挥，而是先让它“复述需求”，把散落的原始材料转成一份带疑问清单的整理稿，我确认后它才继续产出正式规格。这一步非常关键，等于给 Agent 装了一个“先对齐再动手”的开关。

2.2 Agent B：编码智能体（手）

Agent B 是产出代码的主力，我给它配了完整的开发环境：一个基于 Rust 语言构建的高性能 Agent 命令行工具做底座，外加两个主流编码 Agent 引擎作为可选后端。选择 Rust 底座的逻辑在于：Agent 工具本身要高频启动、频繁读写上下文，Rust 编译出来的二进制启动速度快、内存占用低，实测在长任务切换时几乎没有等待感。对于需要反复“读规格→写代码→跑测试”的循环来说，工具链自身的开销越小，效率越高。

Agent B 的典型工作方式是：我给它一个任务卡，它读取对应的规格文档，在独立分支上实现代码，然后自己执行 lint 和单元测试。如果测试失败，它会读报错日志、修复、再跑，最多自己重试三轮。三轮还解决不了的问题，它就写一份 issue 说明卡在哪里，留给人类介入。这个“三轮上限”很重要，否则它会陷入无意义的死循环，白白消耗 token。

2.3 Agent C：质检智能体（眼睛）

Agent C 是我最看重的一道闸门。它不写业务代码，专门做几件事：对照 API 契约检查 Agent B 的实现是否跑偏，检查权限矩阵是否在每个接口上生效，运行 pytest 并核对覆盖率，扫描 SQL 查询有没有 N+1 或慢查询风险。

为什么一定要独立的质检 Agent？因为写代码的 Agent 天然倾向于觉得自己写得对。让同一个模型既写代码又评审，等于让考生自己改自己的卷子。独立质检角色，哪怕底层模型相同，只要给它不同的系统提示词、不同的检查清单、不同的视角，产出的问题清单就会客观很多。我把这叫做“角色隔离”，这是多 Agent 架构里最简单也最有效的设计。

2.4 为什么是 3 个而不是 7 个：主流架构的取舍

我也考虑过更复杂的编排，比如再加一个运维 Agent、一个安全 Agent、一个文档 Agent。但最后砍到 3 个，原因是编排成本。Agent 越多，互相之间的信息同步就越复杂，而企业项目里很多信息本来就是我一个人能掌握的。三层的“需求→实现→验收”是一条线性流水线，每一层的输出是下一层的输入，不需要复杂的组织协调。如果项目规模再大一倍，我可能会把编码 Agent 拆成前端 Agent 和后端 Agent，再把质检 Agent 拆成测试 Agent 和审查 Agent。但就这个项目而言，3 个是最优解，多一个都嫌吵。

3. 搭建 Agent 协作流水线：核心实操

这一节是整个玩法的工程核心。三个 Agent 不是“你一言我一语”地聊天协作，而是通过共享目录里的结构化文档传递信息。这种设计的好处是：每一条信息都可追溯，人类能随时插进来审查，Agent 也不会因为上下文窗口有限而互相遗忘。

3.1 环境与仓库准备（模块化目录结构）

项目开始前，我先把仓库目录按“文档驱动”的方式搭好，结构大致是这样：

repository/ ├── docs/ │ ├── specs/ # 需求规格、数据字典、API 契约 │ ├── tasks/ # 任务卡（一个文件一个任务） │ └── reports/ # 质检报告、测试报告、进度报告 ├── backend/ # Django + DRF 工程 ├── frontend/ # Vue3 + Element Plus 工程 └── scripts/ # 环境初始化、数据迁移脚本

开发环境我统一用 Docker 封装，后端镜像、前端镜像、数据库镜像都固定版本。这样做的好处是 Agent 每次执行任务都在一个干净一致的环境中，不会出现“在我机器上能跑”的经典问题。我这边给 Agent 下了死规矩：任务卡要求改哪些文件就只改哪些文件，不允许顺手清理无关代码。

Agent B 的启动命令很简单，比如实现某个接口时，我会在任务卡里写清楚规格文件路径，然后用命令行工具指定上下文和任务：

claude -p "阅读 docs/specs/order_api.md 和 docs/tasks/003_order_create.md，在 backend/ 下实现对应接口，并运行 backend 目录下的 pytest 验证。"

3.2 用文档做交接：三个 Agent 的协作协议

三个 Agent 不直接对话，全部通过文件交接。我定义了几种标准文档格式。

需求清单大概长这样：

req_id: REQ-007 module: 订单管理 name: 订单创建 priority: P0 acceptance: | - 创建订单必须校验库存充足 - 订单状态初始为 pending_payment - 创建成功后返回订单号和应付金额

任务卡是给 Agent B 的核心输入，它会从任务卡里知道要读哪些规格、实现哪些功能、跑哪些测试、完成后把变更记录写到哪个文件。任务卡末尾固定有一段自检清单，比如：是否处理了权限、是否校验了入参、是否补充了单元测试。这段清单对防止需求漂移非常有效，Agent 在收尾时会自己逐项打勾。

3.3 token 成本到底怎么算

先说清楚 token 是什么。AI 模型处理文本时，会把文字切分成最小单位，英文一个词大约一到两个 token，中文一个字大约一到两个 token。你可以把它理解成 AI 世界里的“计费字数”。上下文窗口就是模型一次能“记住”的最大 token 量，超过的部分就得丢弃或重新输入。所以同样的仓库，如果每次任务都让 Agent 全量读一遍，token 消耗会非常可观。

我统计过三个 Agent 三周的总消耗，大约 800 万 token，换算成费用不到 2000 元人民币。这个成本对于企业项目来说几乎可以忽略，因为一个人的人力成本远不止这个数。但控制 token 的方法值得说：第一，任务卡里明确指定要读的文件路径，禁止 Agent 遍历整个仓库；第二，尽可能复用会话上下文，避免反复把相同的大文件塞进去；第三，把规格文档按模块拆小，一次只让 Agent 关注当前模块。

3.4 一天的协作流程长什么样

我每天的节奏基本固定。早上到公司，先看 Agent A 昨晚生成的规格更新，做需求裁决，把新任务拆成任务卡放进 docs/tasks/。上午交给 Agent B 批量执行三到五个任务卡，每个任务都在独立分支上开发。下午 Agent C 开始质检，产出问题清单。晚上我根据问题清单决定哪些让 Agent B 直接修复、哪些需要人工介入，最后做一次代码 review，确认无误再合并主干。

这中间的“人”不是甩手掌柜，而是流水线的质检员、仲裁者和架构师。我会在几个节点上强制介入：核心表结构评审、审批流状态机设计、联调冲突仲裁、上线前安全复查。这些节点就是本文第四部分要展开的实况记录。

4. 3 周实况：从零到上线的关键节点

下面按时间线记录整个过程中最有代表性的节点，包括每一周重点做了什么、Agent 产出了什么、我在哪里踩了刹车。

4.1 第一周：需求收敛、数据模型与脚手架

第一周的主线是让 Agent A 把原始材料变成可执行的规格。三天时间，Agent A 输出了 12 个业务模块、34 张数据表、27 个前端页面、31 个 API 接口的完整定义。我拿到手之后做了这次项目中最重要的一件事：砍需求。

业务方原本提了三项“锦上添花”的功能，包括一个自定义报表设计器。我很清楚这类功能看起来小，实际上牵扯动态表单、权限模型和前端画布，复杂度极高。我直接把它从 P0 挪到 P2，当作二期再说。砍完之后，剩余的规格逻辑收敛了很多，这也直接决定了后面两周没有出现大范围的返工。

第一周后半段，Agent B 用规格文档搭起了整个工程脚手架：Django 项目初始化、DRF 配置、JWT 登录认证、RBAC 权限基础框架、CI 流水线里的 lint 和基础测试。到周五的时候，系统已经能登录并跑通健康检查接口，三条核心数据表的基础 CRUD 也已经就位。第一周结束时，我们有了一个“地基干净、目录规范、能跑的骨架”。

4.2 第二周：核心业务逻辑与前后端联调

第二周是最吃劲的一周，重点啃三块硬骨头：订单主流程、审批流、库存联动。这三个模块业务耦合度高，状态流转复杂，是那种最容易让 Agent 写崩的地方。

我的做法是把审批流的状态机先自己画出来，再把状态图塞进规格文档。是的，我没让 Agent 自己设计状态机，因为这个东西牵一发动全身，任何遗漏都会在后续模块里放大。状态机定成“草稿→提交→审批中→通过/驳回→完成”五态，再加边界条件：撤回、超时、驳回后重新提交。Agent B 按这个状态机实现后端逻辑，Agent C 同步对照状态图生成状态流转测试。

前后端联移是第二周的主要摩擦点。前端页面和后端接口并行开发，Mock 数据与真实数据混着跑，出现了字段命名不一致、时区处理差 8 小时、金额浮点精度偏差等一系列经典问题。这些问题靠 Agent 自己是仲裁不了的，因为它们属于规格本身的歧义。每次遇到，我都回到 Agent A 的契约文档做裁决，把规格修正后再让两边同步改。这个过程很机械化，但也很可靠，因为每一次裁决都有文档留痕。

4.3 第三周：测试、性能与交付验收

第三周进入收割阶段。Agent C 跑全量回归，汇总缺陷清单，我记得累计登记了 47 个问题，从纯 UI 错位到权限校验漏洞都有，按严重级别排序后，我要求先清 P0/P1。Agent B 修一个，Agent C 复测一个，闭环效率很高。

性能方面，Agent C 的 SQL 扫描发现了 12 个慢查询，集中在报表模块。原因是多表关联查询没有走索引，还有几处循环里调用数据库的写法。解决办法并不复杂：加联合索引、把循环查询改成批量查询、大报表加分页和异步导出。这些都是常规优化，但能让 Agent 在交付前自动发现，省掉了上线后再救火的尴尬。

最后两天，Agent A 自动生成了部署手册和用户操作手册，我检查一遍后补充了几个业务侧的特殊口径。演示环境搭好，权限矩阵按五个角色逐项演练了一遍，确认没有越权访问之后，项目正式提交验收。客户这边三天内确认通过。

4.4 我亲手介入的五个关键决策点

复盘整个三周，我在五个节点上是必须人工把关的，少了任何一个，这项目都有可能翻车。

第一个是需求边界。第一天砍需求，保住了后续两周的节奏。第二个是核心数据模型评审。34 张表的结构在动工前我逐张过了一遍，改了 4 处关联关系和 2 处唯一约束，这种改动如果在开发中途发生，代价是灾难性的。第三个是审批流状态机，这个前面说了，必须人来定。第四个是联调冲突仲裁，前端和后端对接口理解不一致时，我不能让 Agent 自己让步，而要回到规格统一。第五个是上线前安全复查，重新检查所有接口的权限校验和水平越权场景，这类问题 Agent 容易漏，因为它默认所有请求都合法。

5. 翻车现场：常见问题与排查心得

再顺的流程也会翻车。这一节是我最想分享的部分，把这次实操中遇到的真问题、排查思路和最终解法记录下来。

5.1 代码风格失控与规范问题

Agent B 写代码有个特点：功能没问题，但风格随心所欲。有时用 A 方式写查询，有时用 B 方式，模型一换风格又变。对个人项目无伤大雅，在企业项目里这就是维护噩梦。

我的解法不是靠嘴说，而是靠工具强制。后端配好 ruff、black、mypy，前端配好 eslint、prettier，把这些检查全部接进 CI。Agent B 每次提交代码前必须跑一遍检查，不过就自己改。质检 Agent 的检查清单里也加了一条“风格规范检查”。这样即使模型换了好几个，产出的代码风格也会被工具拽回同一条线。一句话，不要相信 Agent 的自律，要相信机制。

5.2 上下文丢失导致需求漂移

这是多 Agent 协作里最容易出现的毛病。有一次 Agent B 在实现订单列表接口时，完全忘记了对应用户只能看自己部门订单这条权限规则。原因很简单：这个规则写在三天前的另一个规格文档里，新会话的上下文窗口没有加载进去。

后来我规定，每个任务卡开头必须有一段“必读上下文”清单，里面列出本次实现必须遵守的约束，包括权限规则、数据范围、审计日志要求。Agent B 开工前第一件事就是把必读清单通读一遍。宁可多花一点 token，也要把关键约束重复加载。此外，每个任务卡末尾有完成自检清单，其中第一条永远是：是否检查了数据权限和越权场景。

5.3 测试假阳性与假阴性

质检 Agent 也会“作弊”。我遇到过两种情况，一种是测试用例写得很漂亮但断言为空，只要接口不报错就算通过，覆盖率数字虚高；另一种是 Mock 数据太干净，全是理想情况，边界值一概没测。这两种问题都很隐蔽，光看报告根本发现不了。

我的对策是双管齐下。对 Agent C 强制要求覆盖率不低于 80%，并且关键函数的分支覆盖要单独在报告里列出。与此同时，我自己手工补充了一批边界用例，包括超长字段、空字符串、负数金额、并发下重复提交等场景。每次我把这些用例丢给 Agent C 跑，都能逼出三五个隐藏问题。人的边界感，Agent 短时间内还是学不会的。

5.4 与现有团队和流程的摩擦

Agent 干活快，但企业流程不会因为你快就变快。这家公司的代码上线要经过人工 review、审批单、发布窗口。我在后半段明显感觉到，卡点从“写不完”变成了“审不完”。

针对这一点，我的做法是让 Agent 顺手生成变更说明文档，每次提交对应一个任务卡，里面写清楚改了什么、为什么改、影响哪些接口。人工 review 的人不用去 diff 一堆代码，直接对照变更说明和质检报告就能快速放行。这一招把 review 的时间从每人半小时压到了十分钟，非常值。另外，所有 Agent 的产出都走我这一关，再由我提交到正式评审，保证流程上的责任边界是清晰的。

6. 收益、边界与可复制的经验

最后把账算清楚，同时说点实在话：这套玩法有明确的适用边界，不是所有项目都能这么干。

6.1 数据对比：3 周与 2 个月的账

我把原文团队的估算和我的实际投入放一起做了个对照表：

整体投入折算下来大约是原来的 40%，日历时间从 8 周压到 3 周。这里我必须说明，人日折算是按我实际投入的工时统计的，头两周我平均每天工作 9 到 10 小时，后一周恢复正常。如果非要算总账，我不是“一个人干了四个人的活”，而是“一个人加三个 Agent，用更短的时间交付了同等质量的成果”。

6.2 哪些项目适合这么干

先说适合的：业务逻辑清晰、接口边界明确、有相对完整需求文档的企业内部系统，比如 OA、CRM、订单管理、审批类应用。这类项目痛点不在算法和性能，而在信息流转的损耗，恰好是 AI Agent 最擅长解决的。团队小、周期紧、需求变化可控，也是加分项。

不太适合的：强实时、强一致性、极端性能要求的系统，比如交易撮合、设备控制；复杂的遗留系统改造，牵涉大量历史逻辑和隐性问题；需求极度模糊、业务方自己都没想清楚的项目。这类项目里，Agent 的幻觉会被无限放大，变成灾难。另外，如果一个组织连基本的需求评审流程都没有，我建议先把流程补上再谈 Agent，否则它只会加速混乱。

6.3 想复制这套玩法需要的四项能力

第一，能拆需求。把一段自然语言变成一条条机器可读的任务卡，这种能力是这套玩法的基础，它需要你理解产品逻辑和开发逻辑之间的翻译。第二，能看懂代码和测试。不是要求你手写代码，而是你必须有判断能力，知道 Agent 写得好不好、测试到底测了没测。第三，有架构判断力。哪些环节可以让 Agent 自由发挥，哪些环节必须人来拍板，这个分寸感最重要。第四，会算 token 账。知道上下文怎么管理、成本怎么控制，才不会让 Agent 变成一个吞金兽。

把这四项能力拆开看，其实每一项都是传统软件工程能力的延伸。AI Agent 没有取消工程师，它只是把工程师的战场从“写代码”挪到了“定义问题、设计机制、保证质量”。

我个人实际操作中的体会是：这三周我加班的时间并不比传统方式少，只是把时间从“亲手敲代码”换成了“高频 review 和精准喂需求”。如果你也想试，我建议别一上来就全量铺开，先挑一个小模块，把三个 Agent 的流水线跑通，感受一下交接文档怎么设计、任务卡怎么写才不会被 Agent 误解。真正值钱的不是让 AI 多写几行代码，而是让每一行代码都有据可查、有测试兜底、有人负责。这套“人定方向、Agent 干活、机制兜底”的协作方式，会是接下来很长一段时间里，小团队交付企业项目的常态。