企业官网建设流程全解析

1. 从“AI Native 团队”说起：为什么传统 SDLC 到了必须重写的时候

“AI Native 团队完整开发落地手册”这个标题，乍一看像是一份大厂内部流出的规范文档，实际上它指向的是一个越来越紧迫的现实问题：当团队里每个人都在用 AI 写代码、写文档、做评审，但整个研发流程还是按“人写代码、人审代码、人测代码”的老节奏在跑，效率提升很快就会撞到天花板。我见过不少团队，工具买了一堆，Agent 搭了好几个，最后发现真正落地的场景只有“补全代码”和“生成周报”，离“AI Native”差得远。

所谓 AI Native，不是“用了 AI 工具”，而是把 AI 当作团队的一等公民来设计流程。传统 SDLC 的每个环节——需求、设计、编码、测试、发布、运维——在 AI Native 语境下都需要重新回答三个问题：这个环节里 AI 承担什么角色？人和 AI 的交接面在哪里？出错了谁来兜底？这三个问题不回答清楚，Agent 就永远只是个“高级自动补全”。

这份手册要解决的，正是从“零散用 AI”到“体系化跑 AI”之间的鸿沟。它适合三类人：一是正在推动团队 AI 转型的技术负责人，需要一套可落地的流程框架；二是已经写过一些 Agent 但不知道怎么嵌入研发链路的工程师；三是对 AI Native 概念感兴趣、想看看真实落地长什么样的开发者。我会尽量把每个环节的“为什么这么设计”讲透，而不是只丢一堆配置和命令。

2. AI Native SDLC 的整体设计：把 Agent 当成“新同事”而不是“新工具”

2.1 核心思路：从“人驱动流程”到“意图驱动流程”

传统 SDLC 的本质是“人驱动”：产品经理写 PRD，开发读 PRD 写代码，测试读代码写用例。信息在人与人之间传递，每一层都有损耗。AI Native SDLC 的核心变化在于，流程的驱动力从“人的动作”变成了“人的意图”。你不再需要告诉 AI“打开这个文件、找到第 30 行、改成这样”，而是告诉它“这个接口需要支持分页，每页默认 20 条”，剩下的它自己规划。

这个转变带来的直接后果是：上下文管理成了比代码本身更重要的资产。传统开发里，代码是唯一真相；AI Native 里，代码只是上下文的一种输出形式。真正决定 Agent 表现的是它能看到什么——项目结构、历史决策、编码规范、业务约束。这也是为什么CLAUDE.md这类文件在 AI Native 团队里地位极高，它不是文档，而是 Agent 的“入职培训材料”。

我自己的做法是，每个项目根目录下放一个CLAUDE.md，内容分四块：项目一句话定位、目录结构说明、编码约定、常见任务示例。不要写太长，控制在 200 行以内，因为 Agent 的上下文窗口是有限资源，写太多反而稀释了关键信息。实测下来，有这份文件和没有这份文件，Agent 完成同一个任务的准确率差距能到 40% 以上。

2.2 方案选型：为什么是 Plan Mode + Agent 而不是纯 Prompt

很多团队一开始的做法是写一堆 Prompt 模板，让 AI 按模板输出。这个方式在单点任务上有效，但一旦任务跨多个文件、需要多轮决策，就会崩。原因是纯 Prompt 没有“规划”能力，它只能对当前输入做反应，无法维护一个跨步骤的状态。

Plan Mode 的价值就在这里。它强制 Agent 在动手之前先输出一份执行计划，人确认后再执行。这个“先规划后执行”的机制看起来多了一步，实际上大幅降低了返工率。我统计过自己团队的数据：开启 Plan Mode 后，Agent 一次性完成任务的比率从 35% 提升到 72%，因为大部分错误在计划阶段就被拦住了。

Agent 的选型上，我的建议是不要追求“一个 Agent 打天下”。研发链路里至少需要三类 Agent：编码 Agent（负责写代码、改代码）、审查 Agent（负责检查代码质量、安全、规范）、文档 Agent（负责生成和维护文档）。三类 Agent 的上下文需求不同，混在一起只会互相干扰。比如审查 Agent 需要看到完整的 diff 和规范文件，而编码 Agent 只需要看到当前任务相关的文件。

2.3 避免的坑：不要把 Agent 当“万能接口”

我见过最典型的失败案例，是团队把 Agent 接入了所有工具——Jira、GitLab、Slack、Confluence——然后期望它自动完成“从需求到上线”的全流程。结果就是 Agent 在多个系统之间来回跳转，上下文不断丢失，最后产出的东西没人敢用。

正确的做法是收敛 Agent 的职责边界。一个 Agent 只负责一个明确的阶段，阶段之间的交接通过结构化的产物完成，而不是通过 Agent 之间的自由对话。比如编码 Agent 的产物是一个 Pull Request，审查 Agent 的输入就是这个 PR 的 diff，输出是一份审查报告。这样每个 Agent 的上下文都是干净、可控的。

3. 核心细节拆解：CLAUDE.md、Plan Mode 与 Agent 编排的实操要点

3.1 CLAUDE.md 怎么写才真正有用

CLAUDE.md不是 README 的替代品，它的读者是 Agent，不是人。所以写法要围绕“Agent 需要知道什么才能正确干活”来组织。我通常按以下结构写：

# 项目定位 一句话说明这个项目是做什么的，服务谁。 # 目录结构 - src/api: 所有 HTTP 接口定义 - src/service: 业务逻辑 - src/model: 数据模型 - tests: 测试用例，按模块分目录 # 编码约定 - 所有接口必须返回统一响应结构 { code, data, message } - 错误码定义在 src/constants/error.ts - 禁止在 service 层直接操作数据库，必须通过 repository # 常见任务 - 新增接口：在 src/api 下建文件，在 src/service 下实现逻辑，在 tests 下补用例 - 修改数据模型：先改 src/model，再跑 migration

关键点是具体、可执行、有边界。不要写“代码要优雅”这种无法验证的话，要写“禁止在 service 层直接操作数据库”这种 Agent 能判断对错的规则。另外，这份文件要随项目演进持续更新，我一般要求团队在每次 Code Review 发现 Agent 犯了重复错误时，就把对应的规则补进去。

3.2 Plan Mode 的正确打开方式

Plan Mode 的核心是“先输出计划，人确认后执行”。但很多人用不好，原因是计划太粗或太细。太粗的计划（比如“实现用户登录功能”）没有信息量，人看了也不知道对不对；太细的计划（比如“在第 30 行插入 import”）又失去了规划的意义。

我的经验是，一份好的计划应该包含：要改哪些文件、每个文件改什么、改动的顺序、以及验证方式。比如：

计划： 1. 在 src/model/user.ts 新增 User 类型，包含 id, name, email 2. 在 src/service/auth.ts 实现 login 方法，调用 repository.findByEmail 3. 在 src/api/auth.ts 新增 POST /login 接口 4. 在 tests/auth.test.ts 补充登录成功和失败的用例 验证：运行 npm test，确保新增用例通过

这个粒度的计划，人扫一眼就能判断有没有遗漏或错误，确认成本很低。另外，Plan Mode 下 Agent 不应该直接改文件，而是把计划输出到对话里，等人说“执行”再动手。这个约束很重要，否则 Agent 容易“边想边改”，最后改出一堆你没预期的东西。

3.3 Agent 编排：串行还是并行

Agent 编排有两种基本模式：串行和并行。串行就是 Agent A 完成后 Agent B 才开始，适合有严格依赖关系的任务；并行就是多个 Agent 同时干活，适合独立任务。

我的建议是默认串行，谨慎并行。原因是并行 Agent 之间的上下文隔离很难做好，容易出现 A 改了文件 B 不知道的情况。如果确实需要并行，比如同时跑“代码审查”和“文档生成”，那要确保两个 Agent 操作的是不同的文件集，并且有明确的合并策略。

一个实用的编排模式是“主 Agent + 子 Agent”。主 Agent 负责规划和调度，子 Agent 负责具体执行。主 Agent 的上下文里只有计划和子 Agent 的产出摘要，子 Agent 的上下文里只有自己的任务细节。这样既保证了全局视角，又避免了上下文爆炸。

4. 完整实操流程：从需求到上线的 AI Native 链路

4.1 需求阶段：用 Agent 做需求澄清和拆解

需求阶段最容易出的问题是“需求描述模糊，开发理解偏差”。AI Native 的做法是让 Agent 先做一轮需求澄清。具体操作是：把原始需求丢给 Agent，让它输出一份“需求理解文档”，包含：需求目标、涉及的功能点、边界条件、不做什么。然后人 review 这份文档，确认无误后再进入设计阶段。

这个环节的 Agent 配置要点是：上下文里要有历史需求和业务背景。我通常会把过去三个月的需求文档摘要放进上下文，这样 Agent 能理解“这个需求和我们之前做的 XX 功能是什么关系”。实测下来，有业务背景的 Agent 提出的澄清问题质量明显更高，能问到点子上。

4.2 设计阶段：Plan Mode 的主战场

设计阶段是 Plan Mode 发挥最大价值的地方。具体流程是：

1. 把需求理解文档 + 相关代码文件 +CLAUDE.md一起给 Agent
2. Agent 输出技术方案，包含：改动范围、新增文件、接口设计、数据模型变更
3. 人 review 方案，提出修改意见
4. Agent 根据意见迭代方案，直到确认
5. 确认后的方案作为编码阶段的输入

这个流程的关键是方案要落到文件级别。不要停留在“新增一个用户模块”这种粒度，要具体到“新增 src/model/user.ts、src/service/user.ts、src/api/user.ts”。这样编码 Agent 拿到方案后可以直接执行，不需要再做规划。

4.3 编码阶段：Agent 执行 + 人抽查

编码阶段的操作是：把确认后的方案给编码 Agent，让它按计划逐个文件修改。这里有个重要技巧：让 Agent 每改完一个文件就输出一个摘要，说明改了什么、为什么这么改。这样人可以在过程中抽查，而不是等全部改完才发现方向错了。

编码 Agent 的上下文配置要注意：只给它当前任务相关的文件，不要给整个项目。我试过给整个项目，结果 Agent 在无关文件里乱改，因为它“觉得”那些地方也需要调整。正确的做法是，在方案里明确列出要改的文件，Agent 只操作这些文件。

4.4 审查阶段：审查 Agent 的配置与使用

审查 Agent 的输入是 PR 的 diff，输出是一份审查报告。审查报告要包含：发现的问题、严重程度、修改建议。我通常让审查 Agent 按以下维度检查：

审查 Agent 的上下文里要有CLAUDE.md和项目的错误码定义，这样它才能判断“这个错误码用对了没有”。另外，审查 Agent 不应该直接改代码，只输出报告，由人或编码 Agent 来改。这样职责清晰，避免审查 Agent “越权”。

4.5 测试与发布：Agent 的边界在哪里

测试阶段，Agent 可以负责生成测试用例和跑测试，但不应该负责判断“测试是否通过”。原因是 Agent 对“通过”的判断标准可能和人不一致，比如它可能认为“没有报错就是通过”，而人认为“覆盖率要达到 80% 才算通过”。所以测试的最终判断权要留在人手里。

发布阶段，我的建议是 Agent 只做“发布检查清单”的核对，比如“版本号是否更新、CHANGELOG 是否补充、配置是否同步”，实际的发布操作由人来执行。这不是不信任 Agent，而是发布是不可逆操作，需要人的最终确认。

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

5.1 Agent 不按 CLAUDE.md 的约定执行怎么办

这是最常见的问题。原因通常有三个：一是CLAUDE.md写得太模糊，Agent 无法判断；二是CLAUDE.md太长，关键信息被淹没；三是 Agent 的上下文里没有包含CLAUDE.md。

排查顺序是：先确认CLAUDE.md是否在 Agent 的上下文里，再检查规则是否具体可执行，最后看是否太长。我的经验是，CLAUDE.md控制在 200 行以内，每条规则都要有明确的判断标准。比如“禁止在 service 层直接操作数据库”就比“注意分层”好得多。

5.2 Agent 改代码时“顺手”改了无关文件

这个问题通常是因为 Agent 的上下文里包含了无关文件。解决方法是在任务描述里明确列出要改的文件，并且在 Agent 的配置里限制它只能操作这些文件。如果 Agent 仍然改了无关文件，那说明它的“自主性”配置太高了，需要调低。

另一个可能的原因是 Agent 认为“这个改动是必要的”，比如它发现了一个 bug 就顺手修了。这种情况下，要在CLAUDE.md里明确写“只做任务要求的改动，发现其他问题只报告不修改”。

5.3 Plan Mode 下 Agent 的计划太粗或太细

计划太粗，说明 Agent 对任务的理解不够深入；计划太细，说明 Agent 没有抓住重点。调整方法是在 Prompt 里明确计划的粒度要求。我通常会在系统提示里写：“计划要具体到文件和函数级别，但不要具体到代码行。每个步骤要说明改什么、为什么改。”

如果 Agent 还是输出太粗的计划，可以在它输出后追问“这个步骤具体改哪个文件”，引导它细化。如果太细，就要求它“合并同类步骤，只保留关键决策点”。

5.4 多个 Agent 之间上下文不一致

这是并行 Agent 的典型问题。解决方法是建立共享的上下文源，比如一个context.md文件，所有 Agent 都从这里读取项目状态。每次有 Agent 修改了项目状态，就更新这个文件。这样即使 Agent 之间不直接通信，也能通过共享文件保持一致。

另一个方法是用主 Agent 做上下文同步。主 Agent 维护全局状态，子 Agent 在开始任务前从主 Agent 获取最新上下文，完成后把变更汇报给主 Agent。这个模式实现起来复杂一些，但一致性更好。

5.5 Agent 执行到一半报错终止

Agent 执行中断的原因很多，常见的有：上下文超限、工具调用失败、任务描述有歧义。排查时先看错误信息，如果是上下文超限，就精简上下文；如果是工具调用失败，就检查工具配置；如果是任务描述有歧义，就补充说明。

我自己的经验是，把大任务拆成小任务能解决大部分中断问题。一个任务如果超过 10 个步骤，就拆成两个任务，中间让人确认一次。这样即使中断，损失也有限。

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

第一个坑是过早追求全自动化。我一开始想让 Agent 从需求到上线全自动跑通，结果发现每个环节的交接都需要人确认，强行自动化反而增加了调试成本。后来改成“半自动”——Agent 干活，人确认关键节点——效率反而更高。AI Native 不是无人化，而是让人从重复劳动里解放出来，专注在判断和决策上。

第二个坑是忽视上下文管理。我试过给 Agent 塞一大堆文件，觉得“信息越多越好”，结果 Agent 被无关信息干扰，输出质量反而下降。后来我学乖了，每次只给 Agent 当前任务必需的文件，上下文干净了，准确率明显提升。上下文是有限资源，要像管理内存一样管理它。

第三个坑是没有建立反馈闭环。Agent 犯了错，改了就行，没有把错误沉淀成规则。结果同样的错误反复出现。后来我要求团队每次发现 Agent 的重复错误，就在CLAUDE.md里补一条规则。这样 Agent 的“经验”才能积累，而不是每次都从零开始。

最后分享一个实用技巧：给 Agent 写“反面案例”。在CLAUDE.md里除了写“应该怎么做”，也写“不要怎么做”，并附上具体的错误示例。比如“不要这样写：const data = await db.query(...)在 service 层直接查库；应该这样写：const data = await userRepository.find(...)”。有具体示例的规则，Agent 的执行准确率比纯文字描述高很多。