企业官网建设流程全解析

1. 从“用AI写代码”到“AI Native 团队”：到底差在哪

这两年我见过太多团队号称自己在做 AI Native 开发，实际拆开一看，无非是给每个人配了个代码补全插件，或者让产品经理用对话框生成几段需求文档。这不叫 AI Native，这叫“给旧流程贴了张 AI 的皮”。真正的 AI Native 团队，是把 AI 当成团队里的一等公民——它有明确的职责边界、有可追溯的工作产物、有独立的上下文记忆，甚至有自己的“入职手册”和“绩效考核标准”。换句话说，你不是在用一个工具，你是在管理一个由人和 Agent 混编的交付组织。

这份手册要解决的问题很具体：当一个团队决定把 SDLC（软件开发生命周期）从“人写代码、人评审、人测试”切换到“人定目标、Agent 执行、人做关键决策”时，到底该怎么落地。它适合三类人看：一是正在推动团队转型的技术负责人，二是想搞清楚 Agent 协作边界的资深工程师，三是刚接触 Agent 开发、想知道真实生产环境长什么样的新人。我不会只讲概念，会把 CLAUDE.md 怎么写、Plan Mode 怎么用、Agent 之间怎么交接、沙箱怎么隔离这些实操细节全部摊开。

先给一个我自己的判断：AI Native 团队的核心不是模型多强，而是上下文工程做得多细。模型能力是公共资源，大家用的是同一批，真正拉开差距的是你喂给它的项目记忆、约束规则和任务拆解方式。这也是为什么 CLAUDE.md 这类文件在 AI Native 团队里地位极高——它不是配置文件，它是 Agent 的“员工手册”。

2. AI Native SDLC 的整体设计与角色拆解

2.1 为什么传统 SDLC 在 Agent 参与后会失效

传统 SDLC 的假设是：每个环节的执行者都是人，人有常识、有隐性知识、能自己补全模糊指令。需求文档写“优化登录体验”，工程师知道要去查埋点、看竞品、问产品经理。但 Agent 不会，它只会严格按你给的字面意思执行，你写“优化登录体验”，它可能真的去把登录按钮换个颜色然后告诉你完成了。

所以 AI Native SDLC 的第一个设计原则是：所有交给 Agent 的输入必须是可验证的、无歧义的、带验收标准的。这不是让文档变啰嗦，而是把过去藏在人脑里的隐性约束显性化。我自己的做法是给每个任务定义三件套：目标（做什么）、约束（不能做什么）、验收（怎么算做完）。缺任何一个，Agent 都会给你惊喜——通常是惊吓。

第二个原则是阶段之间要有机器可读的交接物。人跟人交接可以靠口头同步，Agent 跟 Agent 交接必须靠结构化产物。比如 Plan Mode 产出的计划文档，就是规划 Agent 和执行 Agent 之间的合同。这份文档写得好不好，直接决定后面执行会不会跑偏。

2.2 AI Native 团队的角色分工模型

我把一个典型的 AI Native 团队拆成四层，这个模型是我在多个项目里磨出来的，不是理论推演：

这里有个关键设计：校验 Agent 必须和执行 Agent 隔离。我踩过的坑是让同一个 Agent 既写代码又自测，结果它永远说“测试通过”，因为它倾向于认为自己写的是对的。后来我把校验拆出来，给它独立的上下文和更严格的验收标准，问题才暴露出来。这跟人类团队里“开发不能自己测自己的代码”是同一个道理。

2.3 上下文分层：Agent 记忆到底该怎么管

热词里“agent记忆”被反复提到，但很多人理解得太简单，以为把历史对话全塞进去就叫有记忆。真实生产环境里，上下文必须分层管理，否则 token 成本会爆炸，而且关键信息会被淹没。

我的分层方案是这样的：

• 项目级记忆：放在 CLAUDE.md 里，包含技术栈、目录约定、代码规范、禁止事项。这部分相对稳定，每次会话都加载。
• 任务级记忆：当前任务的 Plan 文档、相关代码片段、接口定义。任务结束就归档。
• 会话级记忆：当前对话的临时上下文，比如刚才试了哪个方案失败了。会话结束即丢弃。
• 长期记忆：跨任务的经验沉淀，比如“这个模块的历史 bug 都出在并发上”。需要主动写入专门的记忆文件。

注意：不要把会话级记忆当长期记忆用。我见过团队把所有对话历史都存下来喂给 Agent，结果 token 费用一个月翻了三倍，Agent 还因为信息过载变得迟钝。记忆不是越多越好，是越精准越好。

3. 核心文件与关键机制：CLAUDE.md、Plan Mode 与 Agent 编排

3.1 CLAUDE.md 到底该写什么，不该写什么

CLAUDE.md 是 AI Native 团队里最重要的单个文件，没有之一。它相当于 Agent 的项目入职手册。但很多人写成了 README 的复制粘贴，这是浪费。

我总结的写法是：只写 Agent 猜不到、但必须知道的东西。具体分四块：

第一块是技术栈与版本约束。比如“用 pnpm 不用 npm”“React 18 不用 19”“所有日期处理用 dayjs 不用 moment”。这些 Agent 默认可能选错，必须明确。

第二块是目录与命名约定。Agent 需要知道新文件放哪、组件怎么命名、测试文件跟源码怎么对应。写清楚这些，能省掉大量返工。

第三块是禁止事项。这是最有价值的部分。比如“禁止直接改 package.json 的依赖版本”“禁止在业务代码里写 console.log”“禁止绕过类型检查”。每一条禁止事项背后，都应该是一次真实的踩坑。

第四块是常用命令。构建、测试、lint、启动本地环境的命令，让 Agent 能自己跑验证。

# CLAUDE.md 示例片段 ## 技术栈 - 包管理：pnpm（禁止使用 npm/yarn） - 框架：Next.js 14 App Router - 状态：zustand，禁止引入 redux ## 禁止事项 - 禁止修改 tsconfig.json 的 strict 配置 - 禁止在组件内直接 fetch，统一走 lib/api 封装 - 禁止提交任何带 TODO 的代码 ## 常用命令 - 开发：pnpm dev - 测试：pnpm test -- --run - 类型检查：pnpm typecheck

提示：CLAUDE.md 要定期更新。每次 Agent 犯了新错误，就把对应的约束补进去。三个月后你会发现这个文件比任何文档都值钱。

3.2 Plan Mode：把“想清楚”变成可执行产物

Plan Mode 是我认为 AI Native 开发里被低估最严重的能力。很多人直接让 Agent 写代码，结果它边写边改方向，最后交付的东西跟预期差十万八千里。Plan Mode 的价值在于强制 Agent 先输出计划、等人确认、再执行。

一个合格的 Plan 文档应该包含：任务拆解成哪几步、每步的输入输出、步骤之间的依赖关系、每步的验收标准、以及识别出的风险点。我要求规划 Agent 输出的 Plan 必须细到“改哪个文件的哪个函数”这个粒度，否则执行阶段一定会跑偏。

实操上，我会在 Plan 确认环节做三件事：一是检查步骤有没有遗漏依赖，二是检查验收标准是否可机器验证，三是检查有没有“隐含假设”——比如 Agent 假设某个接口已经存在，但实际没有。这三件事做完，执行阶段的返工率能降一大半。

3.3 Agent 编排：串行、并行还是混合

Agent 编排不是越复杂越好。我见过有人一上来就搞多 Agent 并行，结果调试成本高到怀疑人生。我的建议是从串行开始，遇到瓶颈再并行。

串行适合有强依赖的任务链，比如“设计接口 → 实现接口 → 写测试 → 校验”。每一步的产物是下一步的输入，顺序不能乱。

并行适合相互独立的任务，比如“同时给三个模块加日志”。这时候可以起多个执行 Agent，各自负责一块，最后统一校验。

混合模式是生产环境最常见的：主干串行，支线并行。比如主流程是“规划 → 执行 → 校验”，但执行阶段内部可以并行处理多个独立模块。

3.4 Agent 沙箱：为什么隔离是安全底线

热词里“agent沙箱”出现频率很高，这是有原因的。Agent 执行代码时，如果直接跑在你的开发机上，一个 rm -rf 就能让你哭出来。沙箱的本质是给 Agent 一个可以随便折腾、但折腾不坏真实环境的隔离空间。

我的沙箱方案分三层：文件系统隔离（Agent 只能访问项目目录的副本）、网络隔离（默认禁止外网访问，需要时白名单放行）、资源隔离（限制 CPU 和内存，防止死循环拖垮机器）。

注意：沙箱不是万能的。我遇到过 Agent 通过合法的构建脚本间接执行了危险操作。所以沙箱之外，还要有操作审计——记录 Agent 执行的每一条命令，定期人工抽查。安全是纵深防御，不是单点方案。

4. 完整实操流程：从任务下达到产物验收

4.1 任务下达：三件套模板与实操示例

任务下达是整个流程的起点，也是最容易出问题的地方。我用的模板长这样：

## 目标 给用户列表页增加按注册时间筛选的功能 ## 约束 - 不改动现有分页逻辑 - 筛选参数走 URL query，不用全局状态 - 必须兼容移动端 ## 验收 - 筛选后列表正确刷新 - URL 可分享，刷新后筛选状态保留 - 移动端布局不溢出 - 新增单元测试覆盖筛选逻辑

这个模板的关键是验收标准必须可验证。“体验好”不可验证，“移动端布局不溢出”可验证。Agent 拿到可验证的标准，才知道什么时候算做完。

4.2 规划阶段：让 Agent 先交计划再动手

任务下达后，第一件事不是写代码，是让规划 Agent 出 Plan。我会明确告诉它：“先不要写任何代码，只输出计划，等我确认。”

规划 Agent 的输出我会重点看三处：一是依赖识别，它有没有发现这个功能依赖后端接口先上线；二是风险点，它有没有意识到移动端布局可能影响现有样式；三是验收映射，它的每一步是否对应到验收标准上。

确认 Plan 之后，我会把它存成独立文件，作为后续执行和校验的依据。这个文件就是整个任务的“合同”。

4.3 执行阶段：Agent 写代码时的现场记录

执行阶段我会让 Agent 严格按 Plan 走，每完成一步就汇报。这里有个实操技巧：要求 Agent 每步都跑一次验证命令，而不是全部写完再跑。这样问题能早发现，定位范围也小。

我记录过一次典型的执行现场：Agent 实现筛选功能时，第一步改了组件，第二步改 URL 处理，第三步跑测试发现失败。因为它是分步验证的，立刻定位到是 URL 参数解析的问题，而不是在几百行改动里大海捞针。

执行阶段还要注意产物落盘。Agent 的中间产物（改动的文件、跑过的命令、遇到的错误）都要记录下来，方便回溯。我习惯让 Agent 每步输出一个简短的执行日志。

4.4 校验阶段：独立 Agent 的验收清单

校验 Agent 拿到的输入是：原始任务三件套 + Plan 文档 + 执行产物。它的职责是独立验证，不是复述执行 Agent 的话。

我的校验清单包含：功能是否覆盖所有验收标准、有没有引入回归、代码是否符合 CLAUDE.md 约束、测试是否真的覆盖了边界情况。校验 Agent 必须给出明确的“通过/不通过”结论，不通过要指出具体哪条标准没过。

提示：校验 Agent 的上下文要干净，不要让它看到执行 Agent 的“自我评价”，否则会被带偏。独立判断是校验的价值所在。

4.5 人工验收：哪些环节必须人来拍板

AI Native 不等于全自动。有些环节必须人来拍板：涉及架构变更的决策、涉及数据安全的操作、涉及用户体验的取舍、以及最终上线前的验收。

我的原则是：Agent 负责“怎么做”，人负责“做什么”和“能不能上”。把决策权和执行权分开，既享受了 Agent 的效率，又守住了关键关口。

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

5.1 Agent 跑偏的典型症状与定位方法

Agent 跑偏有几种典型症状，对应不同的排查方向：

我遇到最多的是第一种。Agent 改了不该改的文件，八成是 CLAUDE.md 没写清楚。每次遇到就补一条约束，慢慢就完善了。

5.2 token 成本失控的三个隐藏原因

token 成本是 AI Native 团队绕不开的话题。除了明显的“上下文太长”，还有三个隐藏原因：

一是重复加载。每次会话都把整个项目文档加载一遍，其实很多内容跟当前任务无关。解法是按任务类型动态加载相关文档。

二是无效重试。Agent 失败后重试时，把之前的失败上下文也带上了，越试越长。解法是重试时清理无关上下文，只保留任务定义。

三是产物冗余。Agent 输出的中间产物没及时归档，一直挂在上下文里。解法是每步完成后把产物落盘，从上下文里移除。

5.3 Agent 之间交接失败的排查思路

多 Agent 协作时，交接失败很常见。排查思路是先看交接物，再看交接协议。

交接物的问题：上游 Agent 输出的产物格式不对、信息不全、或者有歧义。比如规划 Agent 输出的 Plan 里写“优化性能”，执行 Agent 根本不知道优化到什么程度。

交接协议的问题：两个 Agent 对同一个字段的理解不一致。比如上游用“status: done”表示完成，下游期望的是“status: completed”。

解法是把交接物格式固化下来，用 schema 约束。我一般用 JSON schema 定义 Plan 文档的结构，上游必须按格式输出，下游按格式解析，歧义就消除了。

5.4 沙箱逃逸的真实案例与加固建议

我亲身遇到过一次沙箱逃逸：Agent 通过构建脚本里的一个 hook，间接执行了沙箱外的命令。虽然没造成损失，但吓出一身冷汗。

加固建议有三条：一是白名单机制，只允许 Agent 执行预定义的命令，其他一律拒绝；二是命令审计，所有执行记录留存，定期人工抽查；三是最小权限，Agent 用的账号只给必要的权限，不给管理员权限。

注意：安全没有一劳永逸。每次 Agent 能力升级，都要重新评估沙箱策略。能力越强，风险越大。

5.5 团队落地时的组织阻力与化解

技术问题好解，组织问题难搞。我见过团队里资深工程师抵触 Agent，觉得“它写的代码我不放心”。这种抵触不是没道理，化解方法是让 Agent 先做低风险的事，比如写测试、改文档、做代码格式化。等大家看到 Agent 在这些事上靠谱了，再逐步放开权限。

另一个阻力是流程改变带来的不适。以前写完代码直接提交，现在要先出 Plan、等确认、再执行。短期看是变慢了，但长期看返工少了、质量稳了。这个账要算给团队看。

6. 我踩过的坑和几条实在建议

先说一个最贵的坑：早期我让 Agent 直接在生产分支上操作，结果它一次误操作差点把主干搞乱。后来我强制所有 Agent 操作都在独立分支和沙箱里进行，人工确认后才合并。这条规矩救了我好几次。

第二个坑是过度信任 Plan。有次 Plan 看起来很完美，我就直接放行执行，结果执行到一半发现 Plan 里假设的一个接口根本不存在。从那以后，我要求 Plan 里每个外部依赖都必须标注“已验证/待验证”，待验证的必须先确认再执行。

第三个坑是忽略 Agent 的“疲劳”。长会话里 Agent 的表现会下降，因为它要处理的上下文越来越多。我的解法是定期开新会话，把必要的记忆通过文件传递，而不是靠对话历史。

最后分享一个我觉得最实用的技巧：给 Agent 建一个“错题本”。每次它犯错，就把错误和正确做法记到一个专门的文件里，下次会话加载。三个月下来，这个错题本能把重复错误降低一大半。这跟带新人是一个道理——好记性不如烂笔头，Agent 也一样。

这套手册不是终点，是个起点。AI Native 团队的玩法还在快速演化，今天的最佳实践明天可能就过时了。但底层逻辑不变：把隐性知识显性化，把模糊指令结构化，把关键决策留给人。抓住这三条，工具怎么变都不慌。