企业官网建设流程全解析

接下一个真实的活儿时，我心里其实没底。项目是个典型的企业信息管理系统，客户预期是4人团队干2个月，而我只打算用3个AI Agent外加我自己，3周就交。说出去像吹牛，但我想试试现在AI Agent到底能把一个人撑到什么程度。

先说结论：做完了。从需求梳理到数据库设计、后端接口、前端页面、权限体系、基础测试，再到部署上线，走完了一整套企业项目流程。这篇文章不聊概念，只讲我是怎么拆角色、怎么控制上下文、怎么让Agent不胡写代码，以及一套能直接抄的Agent协作玩法。

1. 项目全貌：为什么传统团队要2个月

1.1 企业项目到底“重”在哪里

客户要的是一套客户关系管理系统，表面功能清单不长：客户档案管理、跟进记录、销售漏斗看板、审批流、角色权限、消息提醒、报表导出。听起来也就这么回事，但这类项目在传统研发模式下，时间通常是这样消耗掉的：

• 需求沟通反复确认，光这个环节就可能一两周
• UI设计稿出来后，前端按图施工，改一版需求就要动一遍布局
• 后端按文档写接口，前端等接口、联调改字段，来来回回
• 测试阶段发现边界问题，又回到开发手里
• 最后还要处理交付部署环境的各种意外

真正的开发量可能不大，但“人与人之间的等待”才是大头。一个需求文档从产品经理手上传到开发手上，中间的信息损耗、排期等待、返工成本，才是项目延期的元凶。

我拿到的信息其实很零散，客户给了一段需求描述、几张手画的原型草图，还有之前供应商做过一版半成品截图。正儿八经的需求文档?不存在的。

1.2 把我的打法和传统流程对照

我给自己定的策略很简单：把传统团队里的“产品经理+后端开发+前端开发+测试”四个角色，换成三个各司其职的AI Agent，我自己只做最核心的人工判断和最终把关。

传统模式下，信息要在不同岗位的人之间传递，每一层都是一次损耗。而Agent之间不会抱怨、不会扯皮、不会因为“这不是我的活儿”就拖延，只要我定义好每一个Agent的输入和输出，它就能持续工作。

这也是我踩过很多坑之后才悟到的：Agent协作不是把一个任务丢给一个模型让它干到底，而是要像管理一支队伍一样，拆分工、定边界、立规矩。

2. Agent架构与角色设计：谁指挥、谁执行、谁把关

2.1 三个Agent的明确分工

我给每个Agent都起了个代号，分别对应传统团队里的关键角色：

• Agent A：策划师。负责需求分析、数据模型设计、任务拆分。它不写业务代码，产出的是数据字典、接口清单、项目状态文档。相当于产品经理+技术架构师的合并体。
• Agent B：后端工程师。专职写Django应用代码，包括models、serializers、views、urls和基础单元测试。它只跟代码打交道，不参与需求讨论。
• Agent C：前端工程师与质检员。负责生成页面模板、对接后端接口、检查接口返回字段和页面字段是否匹配，同时跑一轮基础巡检，把问题列成清单交给我。

有人会问，为什么不干脆让一个大模型同时干所有活？我也这么干过，效果很不理想。后面专门讲。

2.2 为什么不用“一个超级Agent解决全部”

我第一次尝试Agent写项目时，就是一个会话里又催它设计数据库又让它写前端又让它修bug，结果前500行代码还行，越到后面越离谱，它开始忘记自己定义过的表名，把不存在的字段写进查询，甚至两份模块的逻辑互相冲突。

原因很直观：上下文窗口是有限的，一个对话塞得越久，模型对早期内容的“记忆”就越模糊。你让它在同一个会话里既当产品经理又当UI设计师又当全栈工程师，它一定会“精神分裂”。

所以我的做法是彻底隔离职责。每个Agent有独立的会话，面对独立的输入和输出，这样它们各自维护的上下文就足够干净。Agent A管“要做什么”，Agent B管“后端怎么写”，Agent C管“页面长什么样”，互不交叉。

关键点：Agent之间不直接对话。它们交互的唯一媒介，是项目仓库里的文档和代码文件。这和真实团队一个道理，不靠口头八卦，靠文档和代码说话。

2.3 Agent协作的“接口契约”：状态文档

三个Agent能稳定协作，核心靠的不是模型多聪明，而是我设计的一套项目状态文档。这套文档放在仓库docs/目录下，就像传统项目的《接口文档》加《项目日报》。

项目状态文档包含几部分：

• 当前数据模型定义（每个表的字段、类型、关系）
• 已完成的接口清单（URL、方法、入参、出参）
• 进行中任务和待办事项
• 遗留问题和已知坑
• 项目决策记录（比如“权限用Django自带的Group，不自己造轮子”）

每次我给Agent下达新任务前，先把相关部分的最新状态贴给它，让它“读完简报再干活”。这样就算隔了一天、换了会话，它也能快速恢复项目记忆，不会问出“这个customer表是哪来的”这种问题。

提示：这个状态文档不是一次性写完就不动了。每次Agent完成任务后，我都要求它同步更新对应部分。维护好这份文档，整个项目就成功了一半。

3. 3周实操记录：每天怎么推进的

3.1 第一周：定需求、建骨架、完成数据层

周一，我先做了一件最重要的事：把客户零散的需求整理成一份结构化的功能清单，并让Agent A基于这份清单输出数据模型。它给了我一个很长的话题列表：客户表、联系人表、跟进记录表、合同表、审批流、用户表、角色表、操作日志表等，还标出了每张表之间的关系。

我花了一个下午自己审核这份数据模型。这一步不能偷懒，因为后面所有代码都建立在模型之上，一旦错了返工成本极高。我修正了几个字段冗余和逻辑问题，然后把定稿版本写进状态文档。

周二到周三，Agent B开始基于数据模型生成Django的models和序列化器。它的产出我基本可以直接用，但有几处细节需要调整，比如部分外键的多对多关系、删除时的级联策略、时间字段的时区处理。

这里贴一段Agent B当时生成的models.py核心片段，我觉得可以作为参考模板：

from django.db import models from django.contrib.auth.models import User class Customer(models.Model): """客户档案""" name = models.CharField("客户名称", max_length=200) industry = models.CharField("所属行业", max_length=100, blank=True) source = models.CharField("客户来源", max_length=100, blank=True) level = models.CharField("客户等级", max_length=20, choices=[ ("A", "A类-重点"), ("B", "B类-潜力"), ("C", "C类-普通") ], default="C") owner = models.ForeignKey( User, verbose_name="负责人", on_delete=models.SET_NULL, null=True, related_name="customers" ) created_at = models.DateTimeField("创建时间", auto_now_add=True) updated_at = models.DateTimeField("更新时间", auto_now=True) class FollowUpRecord(models.Model): """跟进记录""" customer = models.ForeignKey( Customer, verbose_name="客户", on_delete=models.CASCADE, related_name="follow_ups" ) content = models.TextField("跟进内容") next_follow_time = models.DateTimeField("下次跟进时间", null=True, blank=True) creator = models.ForeignKey( User, verbose_name="创建人", on_delete=models.SET_NULL, null=True ) created_at = models.DateTimeField("创建时间", auto_now_add=True)

周五之前，数据迁移做完，基础后台也通了。第一周结束时，整个系统的数据骨架已经立起来。

3.2 第二周：业务逻辑和自动化测试

第二周的重点转向业务逻辑：跟进记录的增删改查、审批流的创建和流转、客户分配给销售、角色权限控制。这些都是纯后端的事，Agent B是主力。

我给Agent B的任务不是“把功能写出来”这么宽泛，而是拆成一条条可验证的子任务，比如：

• 提供“创建跟进记录”的API，入参包含customer_id和content，校验客户是否存在，返回完整记录
• 为审批流增加“通过/驳回”操作，只有发起人或审批人可以操作
• 销售主管角色可以查看部门所有客户，但普通销售只能看自己的

每个任务我都要求：给出代码之外，必须附带对应的测试用例。这一步很关键，因为Agent写代码容易，但让它自己验证代码更像“逼”出来的责任感。

我举个例子，当时Agent B写了一个“批量更新客户负责人”的接口。我要求它补测试，它自己发现了两个问题：如果传入了不存在的用户ID，应该抛异常而不是静默失败；批量操作要包在事务里，否则中途失败会导致数据不一致。这些如果只靠人工review，很容易放过。

第二周结束前，我专门做了一次模拟全流程测试：登录不同角色账号，跑了一遍客户建档、分配负责人、跟进记录、审批通过、数据看板展示。整体流程能跑通，但发现了一处权限漏洞：普通销售通过修改请求参数，竟然能看到非本部门客户的详情。这个问题后面修复了，办法是让Agent B加上基于对象级权限的校验。

3.3 第三周：前端对接与试点上线

前端我没有从零写页面，而是选了现成的后台管理模板，让Agent C基于模板改造成业务页面。它生成的页面骨架能直接用，重点在于和接口的字段对齐。

第三周的三天都在处理一件事：联调。页面上的字段和后端返回的字段不一致、日期时间格式不统一、下拉选项的value和label对不上，这些是Agent C的排查重点。我给它定了规则：除了生成代码，每次联调跑完必须输出一张“字段核对表”，把页面用到的字段、接口返回的字段、数据库字段三列对齐。

到了周四，试点环境已经可以登录。周五我现场给客户业务骨干做了一次演示，把三个角色账号的界面过了一遍。客户当场提了几个小调整，比如列表默认按更新时间排序、报表增加按月份筛选，这些改动周五当天就让Agent B和C加班完成了。

注意：这里说的“加班”当然不是让模型真正加班，而是指我把需求更新到状态文档，然后把任务下发给对应Agent。每一条小改动5到15分钟就能返回结果，这就是Agent模式在后期迭代上的优势。

4. 核心参数与成本控制：Token预算、上下文窗口、人工介入点

4.1 先把“Token”这个事说清楚

很多朋友问我AI Agent里Token到底是什么意思。简单说，Token是大模型处理文本时的最小计费单位，英文大致一个单词算一个左右，中文一个汉字可能折算一到两个Token。你发给模型的指令、模型返回的代码、中间的各种工具调用，全部按Token累计计费。

企业项目体量下，Token消耗不是小数目。这3周下来，我统计了一下全部Agent调用的Token总量，大约120万Token。按我当时用的模型和平台价格折算，总费用在2400元人民币左右，其中主要消耗在Agent B写代码和修bug上，占了大概六成。

这个费用如果换成4人团队的人力成本，相当于一天的工资。所以从成本上看，这个项目用AI模式做非常划算。

4.2 压低Token消耗的三个实操方法

我先说结论：控制Token消耗，核心不是省，而是让每一次调用都花在刀刃上。

• 不往对话里贴整个文件。这是新手最爱犯的错。让Agent改某个函数，有人直接把整个文件几千行全贴进去。我通常只贴目标函数、相关类定义和报错信息，通常几百行内解决问题。上下文短，模型注意力集中，Token费用也低。
• 状态文档要做增量更新。状态文档本身可能会越写越长，所以我要求每个Agent在更新文档时只保留最新结论，旧的设计讨论和废弃方案归档到单独的archive文件里，不塞在活跃文档中。这样每次喂给Agent的“简报”体积可控。
• 批量合并同类修改。比如周五下午客户提的那几个小改动，我攒成一条任务清单再一次性发给Agent，而不是想到一条发一条。每发起一次对话，都有系统提示词和初始上下文的固定开销，批量处理能把这部分摊薄很多。

4.3 哪些节点必须人工介入

AI Agent再强，也不是全程无人值守。我这3周里，人工介入最频繁的节点有几个：需求整理和澄清、数据模型最终拍板、权限和安全逻辑的审查、以及最终的验收决策。

企业项目里最怕的不是写得慢，而是写错方向。Agent不会主动说“这个需求有歧义，咱们聊一下”，它只会按你给的信息往下执行。所以你必须在需求源头和关键节点上亲自把关，发现方向不对马上止损。

压缩团队的意义不是干掉人，是让人只做机器做不了的事：理解客户、判断取舍、把控质量。其余的重复劳动可以交给Agent。

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

5.1 Agent生成“看起来很对但跑不起来”的代码

这个现象我给它起了个名字：幻觉代码。表面看结构完整、函数齐全、变量命名规范，一跑就报错。最常见的原因是版本不匹配，比如Agent按新版语法生成了代码，但项目环境装的是旧版。

我的排查方法三步走：

• 要求Agent给出“自测结果说明”，让它自己先跑一遍并汇报输出
• 把真实报错栈原样贴回给它，让它定位问题，不要自己去猜
• 如果同一问题反复出现，直接在状态文档里锁定依赖版本，并明确要求Agent“只能使用以下版本”

另外，给Agent一个明确的“红线清单”很有用。我在项目开始时就让Agent B知悉：本项目固定使用Python 3.11和Django 4.2，禁止擅自升级任何依赖。有了这条规则，很多版本类幻觉代码在一开始就被拦住了。

5.2 上下文丢失导致重复劳动

这个问题主要出在会话被中间改动打断的场景。你让Agent写了10个接口，中途因其他事关了会话，重开会话后它已经忘了之前的设计，很可能重新生成一套风格不一致的代码。

解决办法很土但很有效：每次让Agent干重活前，先贴状态文档中相关部分，然后明确问一句“你理解上下文了吗？请先复述你接下来要做的改动”。我要求Agent在正式动手前先输出一份“执行计划”，我确认无误后再让它继续。这个确认动作看起来多花了一次对话，实际上能避免大量返工。

另外，重要任务尽量在一个会话里连续完成，不要中途切换话题。如果需要多个不相关的改动，宁可分开会话，也不要塞在一起。

5.3 三个Agent互相“踩代码”

这在多Agent模式里特别容易出现。Agent B改了接口参数，Agent C还在按旧字段适配页面，或者Agent C为了配合自己写的页面，擅自改动了后端的返回结构，导致Agent B那边的测试挂了。

我的约束很简单：同一时刻只允许一个Agent写文件，提交代码前有人工review环节。所有跨Agent的字段调整，只能通过更新状态文档来通知另一方，不允许Agent直接跨权限修改对方负责的文件。这样虽然少了一点“自动化”的感觉，但换来的是稳定的交付节奏。

实际执行中，我还做了一张简单的“文件归属表”：

这张表贴在项目根目录的README里，每次Agent开工前，我都会提醒它“只改你职责范围内的文件”。

5.4 企业部署环境的一堆坑

开发环境跑得好好的，部署到客户内网就炸了，这是最让人崩溃的一环。我遇到的坑包括：内网环境无法访问外网、服务器Python版本太旧、数据库版本与本地不一致、依赖包安装超时。

这次我们目标服务器是Ubuntu，但数据库从本地MySQL 8换成了客户已有的MySQL 5.7，某些字段类型兼容性就出了问题。解决流程是：先在本地用Docker启动一个MySQL 5.7的容器，完整回归一遍所有SQL，把不兼容的字段类型调整好，再带着调整后的部署文档去现场。

避坑提示：和客户约部署时间前，一定要先拿到目标服务器的基础信息，包括操作系统版本、Python版本、数据库版本、网络策略。拿到信息后先在本地模拟一遍，再去现场操作。企业项目交付的最后一公里，往往是最不AI的部分。

6. 这套玩法能扩展到什么场景

这个项目之后，我又用类似的Agent协作模式做过几个小尝试，效果都不错：

• 内部运维脚本工具站：三个Agent分别负责生成脚本、写使用文档、检查敏感信息，两天收工
• 数据迁移脚本：客户从旧系统导出的数据清洗成新系统导入格式，Agent B主攻，Agent C负责生成核对报告
• 小程序的后端接口：体量比较小，两个Agent足够应对

如果团队现有流程偏传统，我不建议一上来就全员上Agent。可以先从单个模块试点，比如让Agent B单独负责一个后端服务模块，跑顺了再逐步扩展。前期最大的成本不是工具，而是建立“任务拆解+状态文档”这套工作习惯。

个人开发者或者小团队想尝试的，建议先从一个内部工具开始练手，不用一上来就接企业单。这套模式对企业管理系统这类“业务逻辑清晰、界面常规、流程标准化”的项目效果最好，但如果你要做的是全新的创意型项目，或者需求本身高度模糊，AI Agent能替代的仍然有限。

7. 想清楚再动手：给后来者的几点建议

做完这个项目，我自己最大的收获不是“3周交付”这个数字，而是对AI协作这件事的理解从“让AI写代码”变成了“设计好一套协作机制”。如果只让我给后来者留三条建议，我会说：

第一，把Human-in-the-loop设计好。需求确认、数据模型评审、权限审查、验收把关，这四个节点无论AI多强，人都要亲自盯。Agent适合做执行，不适合做决定。

第二，状态文档比代码本身更重要。这套模式能不能跑通，取决于你对项目信息的组织能力。文档乱了，Agent的产出就会乱。

第三，从小项目练手。不要拿第一个Agent项目去接对交付时间很敏感的客户，先拿内部工具熟悉这套玩法，知道每种问题该怎么处理，再上真项目。

我实际做完这一单之后，最明显的感受是：以前接项目要考虑“这个月排了三个App，还得养一个团队”，现在一个人加上三个Agent，成长型项目的承接能力高了一个量级。当然，中间也有血压升高的时刻，比如Agent改了字段没告诉另一个Agent，又比如部署时发现数据库版本不兼容。但问题总有解法，而且每一次解法都会沉淀成状态文档里的一条经验，下次更稳。