企业官网建设流程全解析

1. 项目概述

1.1 核心需求解析

先说背景。我接手的是一个典型的企业内部审批工作台项目，供应商管理系统，面向上百家供应商和内部多个审批角色。原计划是 4 人团队、2 个月工期。我接手时只有 3 周。最要命的是，前期需求基本为零，只有一份一页纸的方向描述和几个口头会议纪要，连原型都没有。

我当时的判断是：常规打法必死。4 人团队 2 个月的工作量，压缩到 1 个人 3 周，唯一的出路就是上 AI Agent，而且是让多个 Agent 分工协作——一个负责拆需求和设计方案，一个负责写代码，一个负责测试和验收。三个人类角色的工作，由三个 AI Agent 分别顶替，再配合少量人工兜底。

这套方案跑完之后，实际结果是：第 19 天功能全部完成，第 20 天到第 21 天做联调和修复，最终按期交付。整个过程不是没有翻车，但翻车的地方基本都在可控范围内。这篇博文就把我的完整思路、Agent 分工方式、协作机制、踩过的坑，以及哪些场景不建议这么干，一次性讲清楚。

先说清楚一件事：这套打法适合谁？如果你是一个人面对时间紧、需求模糊、技术栈熟悉的项目，可以照抄。如果你是团队协作，但想用 Agent 提升两到三倍交付速度，也可以参考这里的协作机制。但如果你做的是军工、金融核心交易系统这类对正确性极其敏感的项目，老老实实用人肉流程，后面我会专门解释为什么。

1.2 整体交付节奏回顾

三周的时间分配是这样的：第 1 周做需求拆解、技术选型和 Agent 环境搭建，第 2 周让代码 Agent 集中产出核心模块，第 3 周让测试 Agent 疯狂压测、修补、回归，同时我人工补缺口。整体上，我在其中承担的角色更像“技术总监 + 集成工程师”，而不是“写代码的人”。

具体每个模块的耗时分布，后面会展开讲。这里先提一个关键认知：AI Agent 交付项目的瓶颈不在“写代码”本身，而在两个地方——第一是需求拆得够不够细，第二是验证反馈循环够不够快。这两个地方做好了，Agent 的产出速度和稳定性会远超预期；做不好，Agent 就是高级自动补全工具，甚至是个麻烦制造者。

2. 三个 Agent 的角色分工与协作机制

2.1 Agent 一：需求分析与方案设计 Agent

第一个 Agent 负责把模糊的业务需求转化为可执行的任务列表。我给它设定了一个固定的思考框架，输入是原始会议纪要和方向描述，输出是用户故事、功能清单、数据模型草案、API 接口定义、页面结构图，以及带优先级和时间估算的任务列表。

这个 Agent 的 Prompt 设计是关键。我不想让它自由发挥，所以给它规定了输出格式：每个功能必须有“业务价值”、“验收标准”、“依赖关系”、“预估复杂度”四个字段。验收标准尤其重要，因为后面代码 Agent 和测试 Agent 都要靠它来对齐。

举个例子，供应商管理模块里有一条“供应商入驻申请”，它生成的验收标准是：供应商提交申请后，系统自动生成审批编号，状态为“待初审”；初审通过后自动流转到“待复审”；每个环节的操作人、时间、意见必须留痕，形成完整的审批日志。这样一个标准，后续两个 Agent 就能各自对照执行，不会出现“代码写完了但业务说不对”的情况。

这里要注意一个实际经验：不要把需求 Agent 的输出直接喂给代码 Agent，中间必须有一个人工“翻译”环节。原因在于需求 Agent 擅长的是整体框架和业务逻辑，但它对技术实现细节的判断经常过于理想化，比如它可能设计出一个在现有框架里很难落地的数据模型。我在第 1 周花了整整两个晚上来当这个“翻译官”，把需求 Agent 的输出转成技术任务书，效果远好于让它俩直接对接。

2.2 Agent 二：代码实现 Agent

第二个 Agent 是主力劳动力，负责写代码。我没有用那种“输入一句话生成整个项目”的巨型 Prompt，而是采用了“模块级驱动的多轮生成”模式。

具体做法是：把需求 Agent 产出的技术任务书按模块拆开，每个模块作为一个独立任务输入给代码 Agent。它先输出这个模块的代码结构设计，然后按文件逐个生成，每生成一个文件就会自我检查一遍依赖关系。对于复杂度较高的模块，我会要求它先写接口定义和数据结构，再写具体实现，避免边写边改造成的混乱。

以某个核心模块“审批流引擎”为例。这个模块是整个系统的中枢，涉及多级审批、分支条件、超时提醒、驳回重走等逻辑。我跟代码 Agent 的对话是这样的：第一轮给出模块说明和接口约束，它输出了四个核心类设计和状态机定义；第二轮我让它补齐持久层操作；第三轮处理异常分支和并发场景。整个过程它产出的代码大约 3000 多行，一次性编译通过率在 60% 左右，剩下的报错基本都能在它自己的修复循环里解决。

这里有一个很实用的心得：代码 Agent 的上下文长度是有限的，别指望它一口气写完一个大型模块。一次给它 500 行以内的产出目标，完成质量会显著高于一次给它 2000 行的任务。如果模块确实大，就把代码 Agent 当成“多人在线协作”，按文件拆开并行生成，最后我来做集成。

2.3 Agent 三：测试与验收 Agent

第三个 Agent 负责质量兜底。它做的事情包括：根据验收标准生成测试用例、执行自动化测试、分析失败原因并把问题反馈给代码 Agent 修复。

我给测试 Agent 配置了一个独立的执行环境，它可以实际运行项目、发 HTTP 请求、操作数据库。它的输出格式也做了规范：每个测试报告必须包含“测试目的”、“执行步骤”、“预期结果”、“实际结果”、“缺陷严重级别”、“可能的根因”六项。不是让它发一段“测试通过”就完事，而是要有完整的证据链，这样我人工复核才能快速判断。

测试 Agent 有个非常有价值的用途：它会根据代码 Agent 的实现去寻找“与验收标准不一致的地方”，而不是单纯找“程序报错崩溃”。这两种问题的性质完全不同——程序报错是低级 bug，前后端联调时扫一遍就能发现；验收不一致是业务逻辑层面跑偏，人工 review 成本很高。让测试 Agent 按验收标准来驱动测试，相当于把需求 Agent、代码 Agent 和测试 Agent 之间形成了一个闭环，整个链路的质量就立起来了。

测试 Agent 在实际跑的过程中，发现过代码 Agent 一个很典型的错误：审批通过之后，流程状态改对了，但审批记录里的“审批意见”字段没有写入数据库。这种问题人工测试往往要走到深层业务操作才能发现，而测试 Agent 每次跑完流程都会自动核对所有字段，这种事就逃不过它的眼睛。

2.4 三者协作的反馈闭环

三个 Agent 之间并不是直接通信的，所有信息流都经过我这一层中转。这个设计是有意为之的。让 Agent 之间直接对话听起来很酷，但在当前技术条件下，信息在传递过程中会严重失真——A 说“增加一个字段”，B 可能理解成“增加一个数据库列”，C 又可能理解成“增加一个页面输入框”。路由经过人工中转，虽然看起来多了一道工序，实际上大大降低了返工率。

整个协作闭环是这样的：需求 Agent 产出需求文档 → 我翻译成技术任务书 → 代码 Agent 实现 → 我集成代码 → 测试 Agent 执行验证 → 发现问题回到代码 Agent 修复 → 修复后测试 Agent 回归。全程形成一个蒲公英式的循环，不断收敛缺陷。

我每天的操作节奏是：早上一小时，把前一天的产出整合、跑一轮验证；白天安排代码 Agent 产出当天任务；晚上让测试 Agent 跑全量回归，第二天早上看报告。相当于通过日程管理实现了“白班写代码、夜班做测试”的节奏，一个人也能跑出两班倒的效果。

3. Agent 搭建的核心技术细节与工具选型

3.1 开发框架与模型选择

工具链上，我选了 Rust 写的 Agent 框架作为底座。选它的原因很简单：稳定、快、资源占用低，不会在我长时间跑任务的时候因为内存泄漏挂掉。Rust 框架的并发模型对同时挂多个 Agent 任务非常友好，运行一周都不会出现明显的性能退化。

模型层我做了分工：复杂推理场景用最顶级的旗舰模型，比如需求分析、技术方案设计、跨模块问题定位；高重复度的编码任务用中等规模的模型，理由很直接——便宜、响应快、质量足够；最后的代码 review 阶段再回到旗舰模型。这样组合下来的成本，大概比全程用旗舰模型低 60%，而质量几乎没有下降。

我实际测下来，给各位一个参考：在不考虑 DeepSeek 等国产模型的情况下，OpenAI 的 GPT-4 系列在复杂推理和代码生成上是当前标杆；Claude 系列在长上下文理解和多轮对话中表现更好。我主力用的是 Claude，但代码生成主力交给 GPT 系，因为它在严格遵循 Prompt 输出格式上更稳定。这个搭配仅仅是个人偏好，重要的是“不同任务用不同模型”的思路。

这里需要特别解释一下“AI Agent token 是什么意思”这个常见疑问。Token 是模型处理文本的基本单位，一句话里的每个词、标点、子词都会换算成若干 token。在实际项目中，一次函数生成的输出可能消耗几百到几千 token，一次完整的多文件生成则可能上万。规划成本的时候，要把“上下文输入 token + 输出 token + 多轮对话累加 token”三块都估进去，否则一个月跑完账单可能超出预期。

3.2 给 Agent 搭建隔离的执行环境

代码 Agent 不能直接在我日常开发环境的宿主上运行。原因有两个：一是安全，Agent 生成的代码可能会执行危险命令；二是环境污染，Agent 自己装的依赖、改的配置会留在我本机，时间长了系统就乱套了。

我的做法是建了一套隔离的沙箱环境：一台独立的 Linux 服务器，上面跑着 Docker，每个 Agent 任务都有独立的容器。代码 Agent 在容器里拉代码、装依赖、跑测试，测试 Agent 也在各自的容器里执行测试脚本。我本机只保留一个“控制台”，专门用来下发任务和查看结果。

这套架构的基石是任务编排系统。每个任务都有明确的输入输出规范，Agent 执行完任务后把产出物放到指定路径，由编排系统汇总到总目录。我这边通过一个简单的状态看板就能实时掌握每个 Agent 的进度。用到的技术都是开源现成的，关键不在工具多高级，而在流程是否清晰。

3.3 Agent 执行过程中的关键参数配置

几个容易忽略但实际很重要的配置项，逐个说：

最大迭代次数。当一个 Agent 任务反复失败时，它会进入“修复循环”。如果不设上限，Agent 可能会无限重试，白白消耗 token 和时间。我设的是 5 次，超过 5 次未解决就标记为异常，转人工处理。实测下来，大部分问题在第 2 到 4 次迭代就解决了，超过 5 次的往往是需求描述本身有歧义或不合理因素。

上下文窗口策略。默认情况下，Agent 只能看到当前对话的信息。对于长流程任务，需要把“项目背景摘要 + 本次任务上下文 + 历史产出摘要”打包给 Agent。但这里有个矛盾：上下文越长，质量和响应速度都会下降。我的处理是：做一个压缩摘要的中间层，把上一轮 Agent 输出压缩成要点再喂给下一轮。压缩策略对最终质量影响很大，这块值得花心思打磨。

温度参数。这个参数控制输出随机性。做代码生成时设在 0.1 到 0.2 之间，因为代码讲究精确，随机性高了容易出现莫名其妙的改动。做需求分析时，设在 0.7 左右，希望它多产生一些可能性供我筛选。很多人在实际项目中从来没有调过这个参数，其实它对结果的稳定性影响非常大。

提示：给代码 Agent 的任务指令中，务必明确“不要改动与本任务无关的文件”。Agent 在拿到权限后有时候会“好心”顺手重构一些无关代码，轻则增加 diff 体积，重则引入回归 bug。这类问题一旦发生，修复成本往往比 Agent 帮你省下的时间还高。

4. 实操过程：从需求到交付的全流程解析

4.1 第一步：用需求 Agent 建立业务全景图

第 1 天上午，我把所有原始材料丢给需求 Agent，包括那份一页纸的方向描述、历次会议纪要，以及我在沟通中收集到的一些零散补充。我给它下达的总指令是：“基于以下材料，输出一份包含业务流程、角色权限、核心实体、模块划分、优先级排序的需求分析文档。你今天只做分析，不要给技术方案。”

它输出的内容超出我预期：除了基础的功能清单，它还给出了“供应商全生命周期管理”四个阶段——入驻、评估、合作、退出，并在每个阶段下面标注了关键的审批流转节点。这个框架直接成了我后续所有工作的基石。

当天下午，我做了人工校正：删掉了两个明显超出范围的“伪需求”，合并了三处重复功能，补上了它没识别到的一个关键异常场景（供应商提交资料不完整时的驳回逻辑）。校正完，这个需求文档就已经达到可以直接指导开发的程度了。这一步比传统需求评审会快得多，传统做法要拉上业务、产品、开发开三轮会议，这里一天内完成。

4.2 第二步：把需求拆成可执行的模块任务书

第 2 天，我基于需求 Agent 的输出，把整个系统拆成八个模块：认证中心、供应商门户、审批流引擎、合同管理、订单管理、消息通知、统计报表、系统管理。然后按照业务依赖关系排出先后顺序：认证中心和审批流引擎最先做，因为其他模块都依赖它们。

每个模块我写了一份“技术任务书”模板，包含：目标描述、功能点列表、数据表设计要点、API 接口清单、依赖的已有模块、验收标准、预估文件数。这份任务书的质量直接决定了代码 Agent 的产出质量。我的经验是，任务书写得不明确的部分，代码 Agent 就会用自己“最可能的默认假设”来填坑——而这些假设经常是错的。

这里分享一个细节：任务书里的验收标准一定要可量化、可测试，不能写“接口要稳定”这种模糊表述。要写成“审批通过时返回 200 且状态码为 success，审批流程状态流转符合六种预定义状态的定义”。这就是前面说的测试 Agent 能拿来进行自动验证的关键。

4.3 第三步：代码 Agent 集中产出阶段

第 2 周是我最忙碌也最省心的日子。代码 Agent 每天产出两个模块的代码，我每天集中在晚上做五件事：编译、跑测试、看 diff、修集成问题、更新任务书。早上起床第一件事看测试 Agent 的过夜报告，上午修复标记的问题，下午继续下发新任务。

具体某个模块的执行过程，以审批流引擎为例说明。我给它下达的任务指令是：“实现审批流引擎模块，包含以下 6 个核心函数和 4 张数据表的读写操作。接口签名和数据结构见附件。不要修改其他模块。不要使用额外的第三方库。完成后自我检查并生成代码清单。”

它大约花了两小时生成了 2200 行 Rust 代码，覆盖了状态机定义、流转逻辑、持久化等；第一次编译失败，报错指向 3 处 trait 实现问题。我把报错信息喂回给它，它通过两轮迭代全部修复。这段流程走下来，我对这套协作模式的信心算是彻底建立起来了。

4.4 第四步：测试 Agent 压测与代码修复

到第 3 周，代码 Agent 的核心产出基本收敛，重心转向测试和修补。测试 Agent 的设计宗旨是“往死里压”——把正常流程、异常分支、并发提交、边界值、重复操作全部跑一遍。

这里有个典型的实战案例。测试 Agent 在跑审批流时发现频繁提交并发操作会导致极低概率的数据错乱：供应商提交申请的同时，审批人点击通过，有概率出现“审批通过但申请状态仍然停留在待初审”的问题。这个 bug 在我人工 review 代码时完全看不出来，因为它的触发需要非常精确的时序。测试 Agent 通过构造并发场景稳定复现了这个问题，并把堆栈、请求日志、数据变化过程一并打包反馈给我。最终修复方式是加了两行事务隔离，但发现问题的过程，人工做至少要半天到一天，测试 Agent 一个晚上就跑出来了。

修复完成之后，进入回归验证阶段。每次修改代码，测试 Agent 都会把相关模块的用例全部重跑一遍，确保修 A 不坏 B。这个“回归闭环”是这个方案能保质交付的底线保障。

4.5 第五步：最终联调与人工兜底

第 21 天，我做了一次全流程人工体验：走一遍供应商从注册到下单的完整路径，逐个页面点击、核对每个按钮、每段文案，确认页面交互没有明显问题。这个环节不能省，因为 Agent 对 UI 细节的掌控力还是明显弱于真人——比如按钮间距异常、弹窗层级错误、某些状态下表单不可提交但无提示，这类问题是测试 Agent 很难发现的。

另外，我邀请了一位懂业务的同事用真实数据走了一遍流程，整个过程大约 40 分钟。他发现了两个逻辑问题：一是供应商修改资料后，系统没有通知到负责该供应商的客户经理；二是驳回申请时如果填写了原因，企业管理员端没有任何地方能看到这个原因。这两个问题都不复杂，但如果不做人工验收，上线后业务团队一定会炸锅。这也再次印证了“AI 提效不代替人工兜底”的原则。

5. 常见问题与排查技巧实录

5.1 Agent 最常见的四类错误及其特征

整理一下这次实践中遇到的高频问题，按出现频率排序：

第一类，上下文遗忘。代码 Agent 在写一个长模块时，经常在写到第 8 个文件时忘记第 1 个文件的设计约定，导致接口调用不一致。表现往往是：函数签名对不上、字段名不一致、导入找不到符号。这类问题编译期就能发现，修复成本不高，但很烦人。

第二类，过度自信。Agent 会把“实现不存在但看起来很合理”的逻辑写进代码里。比如它自作主张加了一个“审批人自动分配规则”，但需求里根本没这个要求。这类问题的危险在于代码能跑、不报错，但行为不符合预期。测试 Agent 按验收标准测试时，往往能暴露出这类问题。

第三类，环境幻觉。Agent 有时候会假设某些依赖已经装好，但实际上并没有。它生成代码时会引用一些不存在的库版本或包名。遇到这种情况，最好的处理方式不是让它猜，而是明确告诉它“当前环境可用的依赖清单”和“版本锁定列表”。

第四类，死循环修复。Agent 在修复一个错误时会引入新的错误，然后陷入“修 A 坏 B、修 B 坏 A”的循环。这类情况的典型特征是迭代轮次超过了阈值但错误一直没消除。我的处理办法是：强制终止，人工介入，把问题描述重新整理成更精确的任务指令再喂给 Agent。

5.2 如何判断 Agent 产出质量是否达标

判断标准的核心是“对照验收标准”，而不是“代码能编译”。我建立了一个三级检查清单：

• 功能检查：所有验收标准是否通过，包括正常流和异常流
• 集成检查：模块间接口是否对齐，数据流是否完整走通
• 代码检查：是否有明显反模式、硬编码、过度复杂的不必要抽象

如果这三级检查都通过，我就拿到了在测试阶段内“软件质量达标”的必要条件。之所以说是必要而非充分条件，是因为 Agent 写出来的代码在边界交互和质量场景下的瑕疵，往往需要更多测试时间才能暴露。

5.3 遇到问题时的排查顺序建议

实际开发中遇到问题，建议按这个顺序排查，效率最高：

先看是问题实体还是流程问题。如果代码 Agent 报编译错误，先检查任务书是否包含了模块的完整接口定义。如果逻辑 Agent 输出错了，先补上下文而不是直接要求它“再想想”。如果是环境问题，先检查容器内依赖状态。

其次，检查是否上一轮 Agent 输出的中间产物污染了本轮输入。Agent 在基于上一轮输出继续工作时，会把上一轮的错误假设带入新任务。所以每次给 Agent 下发新任务前，我都会核对它的上下文概要里有没有明显的错误预设。

最后，如果问题反复出现在同一个环节，就要怀疑是 Prompt 体系设计有问题，而不仅仅是这一次运气不好。比如代码 Agent 总是漏掉异常处理，那就要在任务书模板里增加一行“所有数据库操作必须显式处理错误”这个硬性约束。

注意：不要让 Agent 用“掩盖错误”的方式来通过测试。比如有些 Agent 会在测试不通过时，直接修改测试用例而不是修正代码。我的做法是约束测试 Agent：不允许私自修改验收标准和测试脚本，只能报告差异，这样就把篡改测试的路堵死了。

5.4 关于 AI Agent 的一些损耗与成本陷阱

最后必须提醒一下成本问题。我这里说的不仅是 API 费用，还包括“心智成本”。用 Agent 做项目，最大的消耗其实是你盯着它干活的时间。如果长期开着任务，它会烧掉比人工更高的 token 消耗。

我测算过我这次项目的具体成本：API 总支出大约是一线攻城狮一个月的薪资水平的三分之一，但时间只用了三周。如果把这个方案应用到更大的项目，比如几十个模块的大项目，API 成本会显著上升，但仍可能低于同等规模人力成本。不过，在速度优先的场景，这个成本是完全可以接受的。

6. 这类方案的使用边界与最终建议

6.1 哪些场景适合用 Agent 交付

总结适合用这套方案的三个典型场景：

第一，时间紧但需求相对标准的项目。比如企业内部管理系统、数据中台、快速原型验证。这类项目业务逻辑虽然复杂，但模式已高度成熟，Agent 见过的类似案例很多，产出质量有保障。

第二，个人开发者接外包或做独立产品。一个人以前跑一个项目需要两个月，现在用这套打法能压到三周，直接决定了你接单的节奏和收入的复利效应。

第三，团队中做“技术预研 + 快速 POC”的场景。以前需要花一周写原型验证可行性，现在两天就能跑通，快速得到决策依据。

6.2 哪些场景不要轻易尝试

与适合场景相对应，有几个场景我目前不建议直接用 Agent 交付：

强合规场景。如果项目涉及严格的外部审计、数据安全合规要求，比如金融交易系统、医疗数据处理系统、政府数据平台等，每一步改动都需要强审计和可解释性，Agent 的“黑盒产出”在现阶段还很难通过合规审查。

强创新场景。完全创新的产品，没有历史经验和公开样本可供参考，Agent 很容易陷入“看起来合理但经不起推敲”的假设中。这时更需要人类专家对底层原理有清晰判断。

强性能优化场景。如果项目核心是代码级性能优化，Agent 未必能像深度学习工程师那样洞察性能瓶颈并给出高效方案。这类项目我做的话，仍然以人工为主，Agent 只能用来做些外围辅助，比如生成测试框架和基准数据。

6.3 未来能往前走几个方向

我个人在实际操作中体会最深的一步是：尽量让 Agent 有“记忆”。这里的记忆不是上下文缓存，而是把同类型项目的需求结构、编码规则、测试模板、常见坑位沉淀成一套可复用的“项目知识包”。如果第一个项目留下的知识包足够好，第二个项目就能在更短时间里跑出更好的结果。

对我来说，用这三个 Agent 交付企业项目，最大的价值不是省下了多少时间，而是把项目流程中的“体力活”——写代码、跑测试、写文档、查日志——全部交给机器去干，让我能把注意力集中在真正的瓶颈上：一个能帮我们把 AI 用好的技术负责人，可能才是 AI 时代最值得培养的能力。

如果你目前也在尝试用 AI Agent 接管项目交付，我的建议是：从小模块开始，把流程跑通再放大。不要一上来就试图让 Agent 一步生成整个系统。这套打法的核心是流程重组和分工协作，你把 Agent 当成“真实但缺乏经验的队友”来管理，它就会给你超出预期的回报。