企业官网建设流程全解析

1. 从"用AI写代码"到"和AI一起交付"：AI Native团队到底改变了什么

大多数团队对AI的用法还停留在"补全一段函数""解释一段报错"的层面，工具是工具，流程还是老流程。而AI Native团队的本质区别在于：交付流程本身被重新设计了。不是给旧SDLC贴一层AI皮肤，而是从需求进入的那一刻起，人和Agent就在同一套上下文里协作，直到代码合入、验证通过。

我所在的团队从去年开始把整条研发链路往这个方向迁移，中间踩了不少坑，也沉淀出一套能跑通的落地方法。这篇手册面向的是正在或准备把AI深度嵌入研发流程的工程师、Tech Lead和平台建设者。它不讲概念，讲的是：一个需求从进入到交付，人和Agent各自负责什么、上下文怎么组织、并发怎么扛、安全边界画在哪里、哪些环节必须留人工卡点。

先给一个整体判断：AI Native SDLC（软件开发生命周期）的核心不是"更强的模型"，而是上下文的组织方式和编排层的设计。模型能力是水位，编排决定你能用多高的水位干多少活。下面按落地顺序拆开讲。

2. 上下文工程：CLAUDE.md这类文件为什么是整个体系的基石

2.1 没有持久上下文的Agent，每次都在从零开始

Agent最容易被低估的成本是"重新理解项目"。你让它改一个接口，它得先搞清楚项目用什么框架、目录怎么分、命名规范是什么、测试怎么跑、哪些模块不能碰。这些信息如果每次都靠对话临时喂，一是慢，二是必然遗漏，三是不同会话之间不一致。

解决办法是把项目级上下文固化成一个Agent每次都会读取的文件。业界比较通行的做法是在仓库根目录放一个约定命名的说明文件（比如CLAUDE.md、AGENTS.md这类），内容不是给人看的README，而是给Agent看的"作业须知"。

2.2 一份能用的上下文文件应该写什么

我试过很多版本，最后稳定下来的结构大致是这几块：

• 项目定位与边界：一句话说清这个仓库干什么，以及明确不做什么。Agent很擅长"顺手多做"，边界不写清楚它就会越界改无关模块。
• 技术栈与版本约束：框架、语言版本、包管理器、构建命令。版本一定要写死，否则Agent会按训练数据里的旧版本写代码。
• 目录结构与职责：每个顶层目录负责什么，新代码应该放哪里。
• 编码与提交规范：命名风格、错误处理约定、提交信息格式。
• 验证方式：怎么跑测试、怎么跑lint、怎么本地起服务。这是最容易被忽略但最关键的一块。
• 禁区清单：哪些文件、哪些配置、哪些依赖不允许Agent改动。

# 项目上下文（示例结构） ## 定位 订单服务，负责下单、支付回调、订单状态流转。不处理用户账户逻辑。 ## 技术栈 - 语言：Go 1.22 - 框架：gin - 数据库：PostgreSQL 15，迁移用 golang-migrate - 测试：go test ./...，覆盖率要求新增代码 >= 70% ## 目录职责 - internal/handler HTTP入口，只做参数校验和调用service - internal/service 业务逻辑，禁止直接操作DB - internal/repo 数据访问层 - internal/model 领域模型 ## 禁区 - 不要修改 go.mod 中的依赖版本 - 不要改动 migrations/ 下已存在的迁移文件 - 不要引入新的第三方库，除非在PR描述中说明理由

注意：这份文件要跟着项目演进持续维护。我见过团队写完就放着不管，三个月后Agent按过时的规范写代码，反而制造了更多返工。

2.3 上下文分层：项目级、任务级、会话级

只有项目级上下文还不够。一个需求进来，还需要任务级上下文（这个需求要改什么、验收标准是什么）和会话级上下文（当前这轮对话的临时信息）。三层分开管理，好处是项目级可以长期复用，任务级随需求走，会话级用完即弃。

我的做法是：项目级放仓库里，任务级放issue或任务描述里，会话级靠对话本身承载。Agent每次启动先读项目级，再读任务级，然后开始干活。这样即使换一个Agent实例接手，上下文也不会丢。

3. Plan Mode：为什么"先让Agent想清楚"比"直接让它写"重要十倍

3.1 直接生成的代价

让Agent直接写代码，最典型的问题是：它会在没理解需求的情况下选一个看起来合理的方案，然后一路写下去。等你发现方向错了，已经生成几百行，改起来比自己写还累。

Plan Mode的思路很简单：先让Agent输出一份执行计划，人工确认后再动手。这一步看起来拖慢了速度，实际上大幅降低了返工率。我统计过我们团队的数据，加了计划确认环节后，单个需求的平均返工次数从2.3次降到0.7次。

3.2 一份合格的执行计划长什么样

计划不是"我要实现这个功能"这种废话，而是要具体到可验证的程度：

1. 改动范围：要动哪些文件，新增哪些文件。
2. 实现步骤：分几步，每步做什么，步与步之间的依赖关系。
3. 关键决策：涉及方案选择的地方，说明为什么选A不选B。
4. 验证方式：每步做完怎么验证，最终怎么验收。
5. 风险点：哪些地方可能出问题，需要人工重点看。

需求：订单支持部分退款 执行计划： 1. 在 model 层新增 RefundRecord 结构，记录退款金额、时间、操作人 - 决策：不复用现有 Payment 结构，因为退款和支付的生命周期不同 2. 在 repo 层新增退款记录的读写方法 3. 在 service 层实现部分退款逻辑： - 校验退款金额 <= 订单可退金额 - 更新订单状态为 partial_refunded - 写入退款记录 4. 在 handler 层新增 POST /orders/:id/refund 接口 5. 补充单元测试，覆盖：正常退款、超额退款、重复退款 验证：go test ./... 全绿，手动调用接口验证三种场景 风险：并发退款场景需要加锁，计划中用数据库行锁处理

3.3 计划确认环节的人工卡点

计划确认不是走形式。我要求团队在确认计划时重点看三件事：改动范围是否超出预期、关键决策是否合理、验证方式是否覆盖了边界情况。这三件事任何一件有问题，都打回去重做计划。这个卡点花5分钟，能省下后面半小时的返工。

4. Agent编排：单Agent、多Agent和Harness的边界在哪

4.1 先搞清楚Harness和Agent的区别

很多人把这两个概念混着用。简单说：Agent是干活的，Harness是管Agent怎么干活的。Harness负责调度、上下文注入、工具调用、结果校验、错误重试这些编排逻辑；Agent负责在给定上下文下完成具体任务。

打个比方，Agent是工人，Harness是工头加流水线。工人再强，没有好的流水线也出不了活。很多团队一上来就追求"更强的Agent"，其实瓶颈往往在Harness这一层。

4.2 单Agent够用的场景

不是所有任务都需要多Agent。以下场景单Agent完全够用：

• 任务边界清晰，改动集中在一两个模块
• 不需要跨领域知识（比如既懂前端又懂数据库）
• 验证方式明确，跑个测试就知道对不对

单Agent的好处是上下文简单、调试容易、成本低。我建议默认从单Agent开始，遇到明确的瓶颈再拆。

4.3 什么时候需要多Agent

多Agent的价值在于上下文隔离和并行。典型场景：

但多Agent的代价是编排复杂度上升、上下文同步成本高、调试困难。我的经验是：只有当单Agent的上下文确实装不下，或者任务确实可以并行时，才上多Agent。

4.4 编排层要处理的核心问题

不管单Agent还是多Agent，编排层都要解决这几个问题：

• 上下文注入：什么时候注入什么上下文，注入多少。注入太多会稀释重点，太少会缺信息。
• 工具调用：Agent能调哪些工具，调用结果怎么回传。
• 结果校验：Agent的输出怎么验证，验证失败怎么处理。
• 错误重试：失败了重试几次，重试时要不要换策略。
• 状态管理：多步任务中间状态怎么存，中断了怎么恢复。

这些问题的处理质量，直接决定了整套体系能不能稳定跑起来。

5. 并发：AI Agent怎么扛住真实团队的负载

5.1 并发问题的本质

Agent的并发不是简单的"多开几个实例"。真实团队里，多个需求同时推进，每个需求可能对应多个Agent任务，这些任务共享仓库、共享CI资源、共享上下文文件。并发问题主要出在三个地方：

• 仓库冲突：两个Agent同时改同一个文件，合并时冲突。
• 资源竞争：CI流水线、测试环境、数据库被多个任务同时占用。
• 上下文污染：一个任务的中间状态影响了另一个任务。

5.2 隔离策略

我们的做法是按任务隔离工作区。每个Agent任务在独立的git worktree或独立分支上工作，互不干扰。合并时按顺序来，冲突在合并阶段解决，而不是在生成阶段。

# 为每个任务创建独立worktree git worktree add ../task-1234 -b feature/task-1234 # Agent在 ../task-1234 目录下工作 # 完成后合并回主分支

资源层面，CI流水线按任务排队，测试环境用容器隔离，每个任务起一套独立的依赖服务。这样即使某个任务把环境搞坏了，也不影响其他任务。

5.3 上下文隔离

多任务并行时，上下文文件不能共享可变状态。项目级上下文是只读的，任务级上下文每个任务独立，会话级上下文用完即弃。这样设计的好处是，任何一个任务的上下文出问题，都不会扩散到其他任务。

5.4 并发下的成本控制

Agent并发跑起来，token消耗是线性增长的。我们设了几个闸：

• 单任务token上限，超了就中断，人工介入
• 并发任务数上限，根据团队实际吞吐量定
• 简单任务用轻量模型，复杂任务才用重模型
• 定期清理无效的上下文注入

这些闸门看起来限制了能力，实际上是保证了整套体系不会因为成本失控而被迫停摆。

6. 安全边界：Agent能碰什么，不能碰什么

6.1 权限最小化

Agent的权限要按最小必要原则给。能读的就不给写，能写测试的就不给写生产配置。具体来说：

• 文件系统：限制在项目目录内，禁止访问系统目录和敏感路径
• 网络：限制可访问的域名，禁止访问未知外部服务
• 命令执行：白名单机制，只允许执行预定义的命令
• 凭证：Agent不直接持有生产凭证，需要时通过受控通道获取

6.2 敏感操作的人工卡点

以下操作必须人工确认，不能由Agent自主执行：

• 修改生产环境配置
• 执行数据库迁移
• 合并到主分支
• 发布版本
• 修改权限相关代码

这些卡点不是不信任Agent，而是风险不对称：Agent做对了省几分钟，做错了可能造成小时级的故障。卡点的成本远低于故障成本。

6.3 审计与追溯

每个Agent任务都要有完整的审计记录：谁发起的、用了什么上下文、执行了哪些操作、产生了什么结果。出问题时能快速定位是哪一步出的错。我们的做法是把Agent的每一步操作都记到日志里，和CI流水线的记录关联起来。

6.4 代码审查不能省

Agent生成的代码必须经过人工审查才能合入。审查的重点不是语法（Agent语法一般没问题），而是业务逻辑正确性和边界情况处理。我见过Agent写出语法完美但业务逻辑完全错误的代码，这种错误只有懂业务的人才能发现。

7. 落地路线：从一个小场景开始，别一上来就搞大平台

7.1 选第一个场景的原则

第一个落地场景要满足：边界清晰、验证明确、失败成本低。比如：

• 补充单元测试
• 修复明确的bug
• 写文档和注释
• 小范围的重构

不要一上来就选核心业务逻辑，失败成本太高，一旦出问题整个团队对这套体系的信心就没了。

7.2 逐步扩展的节奏

我们的扩展节奏大致是：

1. 第一阶段：单Agent + 项目级上下文，跑通"需求到代码"的闭环
2. 第二阶段：加入Plan Mode，降低返工率
3. 第三阶段：引入多Agent，处理需要并行或上下文隔离的场景
4. 第四阶段：完善编排层，处理并发、安全、审计

每个阶段跑稳了再进下一个，不要跳步。

7.3 团队协作方式的调整

AI Native不只是工具变化，团队协作方式也要跟着调：

• 需求描述要更精确：Agent不会猜你的意图，需求写得模糊，产出就模糊
• 验收标准要前置：在需求阶段就定义清楚怎么算完成
• 代码审查重点转移：从"写得对不对"转向"逻辑对不对"
• 知识沉淀方式变化：项目知识要写成Agent能读的格式，而不只是人读的文档

7.4 常见误区

最后列几个我见过或踩过的误区：

• 追求全自动：以为Agent能端到端搞定一切，结果发现关键环节还是得人工。正确做法是找到人机协作的最佳分工点。
• 忽视上下文维护：上下文文件写完就不管，导致Agent按过时规范工作。
• 过早多Agent：单Agent还没跑稳就上多Agent，编排复杂度直接压垮团队。
• 安全后置：先跑起来再说安全，结果出了事故才补，代价大得多。
• 只看模型能力：以为换个更强的模型就能解决所有问题，忽视了编排和上下文的作用。

这套体系我们跑了大半年，最大的体会是：AI Native的难点不在AI，在Native。把AI嵌进现有流程很容易，难的是重新设计流程让AI真正发挥作用。上下文怎么组织、编排怎么做、边界怎么画，这些才是决定成败的地方。模型会一直变强，但这些工程问题不会因为模型变强就消失。