企业官网建设流程全解析

1. 为什么“AI Native 团队”不是加个工具那么简单

这两年“AI Native”这个词被喊得震天响，但我见过太多团队，嘴上说着 AI Native，实际干的事还是老一套：产品经理写 PRD，设计师出图，开发照着文档敲代码，测试等提测，最后在流程尾巴上挂一个“AI 助手”的入口，就对外宣称自己是 AI 原生团队了。这种做法我一般叫它“AI 贴牌”，跟真正的 AI Native 差着十万八千里。

真正的 AI Native 团队，核心变化不在于用了多少 AI 工具，而在于整个软件开发生命周期（SDLC）的底层假设被重写了。传统 SDLC 的假设是“人写代码，机器执行”；AI Native 的假设是“人定义意图，Agent 执行，人做验收”。这个转变听起来简单，落地的时候会牵扯到文档规范、协作方式、代码审查、测试策略、甚至团队角色分工的全盘调整。

我拿一个最直观的例子来说。传统团队里，一个新功能从需求到上线，中间要经过需求评审、技术方案、编码、自测、联调、提测、回归、发布，每个环节都有明确的“人”作为负责人。AI Native 团队里，这套流程依然存在，但每个环节的“执行者”变了——需求可以变成结构化的CLAUDE.md上下文文件，技术方案可以由 Plan Mode 先跑一遍可行性，编码由 Agent 完成初稿，人只做关键决策和验收。这不是把人换掉，而是把人的精力从“执行”挪到“判断”上。

所以这份手册要解决的问题很具体：一个团队想真正落地 AI Native 研发范式，从哪开始、按什么顺序、每个阶段用什么工具、踩哪些坑、怎么衡量有没有落地成功。它适合三类人：一是正在推动团队转型的技术负责人，二是想搞清楚 AI Native 到底怎么落地的一线开发，三是已经在用 Agent 但觉得“用了个寂寞”的团队。我会尽量把每一步都拆到可以直接抄作业的程度，同时把背后的“为什么”讲透，因为不理解原理的照搬，最后一定会变形。

2. AI Native SDLC 的整体设计与思路拆解

2.1 传统 SDLC 和 AI Native SDLC 的本质差异

先把两套流程摆在一起对比，差异一目了然。

这张表里最关键的一行是最后一行。很多团队转型失败，就是因为人的角色没转过来——还是把自己当执行者，结果发现 Agent 干得比自己快，就慌了，要么排斥，要么过度依赖。正确的姿势是：人负责定义“什么是对的”，Agent 负责“把对的做出来”。

2.2 为什么选“上下文文件 + Agent + Plan Mode”这套组合

市面上 Agent 框架多得让人眼花缭乱，从开源的到商业的，从通用到垂直的，为什么我推荐以CLAUDE.md这类上下文文件为核心，配合 Plan Mode 和 Agent 执行？这里有几个实打实的考量。

第一，上下文文件是团队知识的唯一真相源。传统团队里，项目规范散落在 Confluence、飞书文档、代码注释、老员工脑子里，新人进来要花几周才能摸清。AI Native 团队把这些规范收敛到一个CLAUDE.md文件里，Agent 每次执行前都读它，人也可以随时查。这个文件就是团队的“操作手册”，改一处，全局生效。

第二，Plan Mode 解决了 Agent “瞎干”的问题。直接让 Agent 写代码，它可能理解偏了，写出一堆看着对但不符合团队规范的东西。Plan Mode 强制 Agent 先输出方案，人审核通过后再执行。这一步看似多了一道工序，实际上省下了大量返工时间。我实测下来，加了 Plan Mode 之后，Agent 产出的一次通过率能从四成提到七成以上。

第三，Agent 的可替换性。今天用这个 Agent，明天可能换那个，但上下文文件和 Plan Mode 的工作方式是通用的。把团队知识绑在某个具体工具上，是转型里最大的坑之一。

2.3 落地路线的三个阶段

我把落地分成三个阶段，每个阶段有明确的交付物和验收标准。

阶段一：上下文基建（1-2 周）。核心任务是写出第一版CLAUDE.md，把项目结构、编码规范、常用命令、禁忌事项写清楚。这个阶段不追求完美，先跑起来，后面持续迭代。验收标准是：Agent 读完这个文件后，能独立完成一个简单功能的开发，不需要人额外解释项目背景。

阶段二：流程嵌入（2-4 周）。把 Plan Mode、Agent 执行、人审查这套流程嵌入到日常开发里。选一两个非核心模块先试点，跑通完整链路。验收标准是：团队里至少一半的开发任务是通过这套流程完成的，且返工率不高于传统方式。

阶段三：知识沉淀与规模化（持续）。把重复性的操作沉淀成 Agent Skill，把常见问题的排查方法写进上下文文件，让新人和 Agent 都能快速上手。验收标准是：新人入职一周内能独立提交符合规范的代码，Agent 能处理团队八成的常规开发任务。

3. 核心细节解析与实操要点

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

CLAUDE.md是整套体系的基石，但很多人第一次写的时候容易走两个极端：要么写得太少，Agent 读完还是不知道项目怎么跑；要么写得太细，把每一行代码的规范都塞进去，结果文件几千行，Agent 读起来反而抓不住重点。

我的经验是，CLAUDE.md应该包含五类内容，按重要性排序：

• 项目概览：一句话说清项目是干什么的，技术栈是什么，目录结构怎么组织。这部分控制在 20 行以内。
• 常用命令：安装依赖、启动开发环境、跑测试、构建、部署，每个命令一行，附上简短说明。这是 Agent 最常查的部分。
• 编码规范：命名约定、文件组织、错误处理方式、日志规范。不要写“要写清晰的代码”这种废话，要写具体的，比如“所有 API 响应统一用{ code, data, message }结构”。
• 禁忌事项：哪些操作绝对不能做，比如“不要直接改config/prod.yaml”、“不要引入新的第三方依赖而不更新锁文件”。
• 常见任务的操作步骤：比如“新增一个 API 接口的完整步骤”，列出从建文件到写测试到注册路由的全流程。

不该写的内容也很明确：不要写大段的业务逻辑说明（那应该放在代码注释或单独的设计文档里），不要写会频繁变动的信息（比如具体的版本号），不要写跟项目无关的通用编程知识。

提示：CLAUDE.md要当成活文档来维护。每次发现 Agent 犯了同样的错误，就把对应的规范补进去。我一般每周花 15 分钟回顾一下这周 Agent 出的问题，把共性的补进文件里。

3.2 Plan Mode 的正确打开方式

Plan Mode 的核心价值是让 Agent 在动手之前先“想清楚”。但很多人用 Plan Mode 的方式不对，要么让它输出一份几百行的详细方案（人根本看不完），要么方案太粗（“我会创建一个文件然后写代码”），起不到审核的作用。

我推荐的 Plan Mode 输出结构是这样的：

1. 任务理解：用一两句话复述它理解的需求，确认没跑偏。
2. 影响范围：列出会改动哪些文件、哪些模块，有没有可能影响其他功能。
3. 实现步骤：分步骤列出要做什么，每步一句话，控制在 5-8 步。
4. 风险点：它认为可能出问题的地方，以及打算怎么处理。
5. 验收方式：怎么验证做完了，跑什么测试，看什么指标。

这个结构的好处是，人审核的时候只需要看“影响范围”和“风险点”两栏，就能快速判断方案靠不靠谱。如果这两栏有问题，直接打回重做；没问题就放行执行。

注意：Plan Mode 不是万能的。对于特别简单的任务（改个文案、调个样式），直接让 Agent 干就行，走 Plan Mode 反而浪费时间。我的判断标准是：如果这个任务需要改动超过 3 个文件，或者涉及核心逻辑，就走 Plan Mode；否则直接执行。

3.3 Agent 执行阶段的人机分工

Agent 开始执行之后，人不是就没事干了。这个阶段人的核心工作是盯关键节点，而不是盯每一行代码。

具体来说，我会关注三个节点：一是 Agent 第一次提交代码后，快速扫一遍整体结构，看有没有方向性错误；二是 Agent 遇到报错卡住的时候，看它是怎么排查的，如果排查思路不对，及时介入；三是 Agent 声称完成之后，跑一遍验收测试，确认功能真的可用。

这里有个反直觉的经验：不要频繁打断 Agent。我见过一些团队，Agent 每写几行代码，人就凑过去看一眼，觉得不对就打断。这样效率极低，因为 Agent 的执行是有上下文的，频繁打断会让它丢失状态。正确的做法是给它一个完整的执行窗口，比如 10-15 分钟，中间不干预，等它告一段落再统一审查。

3.4 Agent Skill 的沉淀逻辑

Agent Skill 是把重复性操作固化下来的机制。但不是什么操作都值得沉淀成 Skill。我的判断标准是：如果一个操作每周至少重复 3 次，且步骤固定，就值得沉淀。

比如“新增一个 CRUD 接口”这种操作，步骤非常固定：建 model、建 service、建 controller、注册路由、写测试。这种就适合做成 Skill，Agent 调用一次就能生成全套代码，人只需要填业务逻辑。

反过来，“排查线上性能问题”这种操作，虽然也经常做，但每次情况都不一样，就不适合做成固定 Skill，更适合把排查思路写进上下文文件，让 Agent 参考。

Skill 的维护也有讲究。我一般把 Skill 放在独立的目录里，每个 Skill 一个文件，文件开头写清楚这个 Skill 解决什么问题、什么时候用、输入输出是什么。这样 Agent 在需要的时候能自己找到对应的 Skill。

4. 实操过程与核心环节实现

4.1 从零搭建 AI Native 开发环境的完整步骤

假设你现在接手一个中等规模的项目（比如一个后端服务，十几万行代码），要把它改造成 AI Native 的开发模式。下面是我实际走过的步骤。

第一步：梳理项目现状。花半天时间，把项目的技术栈、目录结构、构建命令、测试命令、部署流程全部摸清楚。这一步不能省，因为你要把这些信息写进CLAUDE.md，自己都不清楚就写不出来。

第二步：写第一版 CLAUDE.md。按照前面说的五类内容，先写一个初版。我的习惯是先写“常用命令”和“项目概览”，这两部分最容易写，也最有用。编码规范和禁忌事项可以后面慢慢补。

第三步：选一个试点任务。不要一上来就拿核心模块开刀，选一个边缘的、独立的、影响面小的任务，比如“给某个接口加一个参数校验”。用这个任务跑通 Plan Mode + Agent 执行的完整流程。

第四步：记录问题并迭代。试点任务跑完后，把 Agent 犯的错、人审核时发现的问题、流程卡顿的地方全部记下来，针对性地更新CLAUDE.md和流程。

第五步：扩大试点范围。第一个任务跑顺之后，再选 2-3 个类似的任务，验证流程的稳定性。确认没问题后，逐步推广到更多模块。

这个过程中，最关键的是第三步和第四步。很多团队失败就是因为跳过了试点，直接全员推广，结果问题集中爆发，士气受挫。

4.2 一个真实任务的完整执行记录

我拿一个实际做过的任务来演示：给一个用户服务新增“批量查询用户信息”的接口。

任务描述：现有GET /user/{id}接口，需要新增POST /user/batch接口，接收用户 ID 列表，返回对应的用户信息列表，要求处理不存在的 ID。

Plan Mode 输出：

任务理解：新增批量查询接口，输入 ID 列表，输出用户信息列表，需处理无效 ID。 影响范围： - 新增文件：controller/user_batch.go, service/user_batch.go - 修改文件：router/routes.go（注册路由） - 可能影响：无，纯新增功能 实现步骤： 1. 在 service 层新增 BatchGetUsers 方法，接收 ID 列表 2. 处理无效 ID，返回时标记哪些 ID 不存在 3. 在 controller 层新增 handler，解析请求体，调用 service 4. 在 router 注册 POST /user/batch 路由 5. 写单元测试，覆盖正常、空列表、含无效 ID 三种情况 风险点： - 批量查询可能触发数据库 IN 查询的性能问题，需限制单次最大 ID 数量 - 无效 ID 的处理方式需要明确，是报错还是忽略 验收方式： - 跑单元测试全部通过 - 手动调用接口，验证三种场景

人审核：我看了影响范围和风险点，觉得没问题，但补充了一条要求：“单次最大 ID 数量限制为 100，超过返回错误”。然后放行。

Agent 执行：Agent 按照步骤生成了代码，中间遇到一个编译错误（import 路径写错），自己排查后修复了。整个过程大约 8 分钟。

人验收：我跑了测试，手动调了接口，确认功能正常。然后检查了代码风格，发现 Agent 生成的错误处理用了fmt.Errorf，而团队规范要求用自定义的AppError。我把这个问题记下来，更新了CLAUDE.md里的编码规范。

这个任务从开始到完成，人投入的时间大约是 15 分钟（写任务描述 + 审核方案 + 验收），传统方式下大概需要 1-2 小时。效率提升是明显的，但更重要的是，这个过程中沉淀下来的规范（最大 ID 限制、错误处理方式）会惠及后续所有类似任务。

4.3 参数选择与配置的关键考量

在配置 Agent 和 Plan Mode 的时候，有几个参数需要根据团队情况调整。

上下文窗口大小：这决定了 Agent 一次能“看到”多少代码。太小了，它理解不了项目全貌；太大了，响应变慢且容易抓不住重点。我的经验是，对于中等规模项目，把CLAUDE.md加上当前任务相关的 3-5 个文件作为上下文，效果最好。

Plan Mode 的详细程度：前面说了，控制在 5-8 步。如果团队新人多，可以要求更详细；如果都是老手，可以更简洁。

Agent 执行的超时时间：我一般设 15 分钟。超过这个时间还没完成，要么是任务太复杂需要拆分，要么是 Agent 卡住了需要介入。

审查粒度：不是所有代码都需要逐行审查。我的做法是，核心逻辑逐行看，样板代码扫一眼，测试代码看覆盖率。

这些参数没有标准答案，需要根据团队的实际反馈持续调整。我建议每两周回顾一次，看看哪些参数需要改。

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

5.1 Agent 产出不符合规范怎么办

这是最常见的问题。Agent 生成的代码能跑，但风格跟团队规范不一致。比如命名用了驼峰而团队要求下划线，或者错误处理方式不对。

排查思路分三步。第一，确认CLAUDE.md里有没有写清楚这条规范。很多时候问题出在规范没写，Agent 只能按自己的习惯来。第二，如果规范写了但 Agent 没遵守，检查规范的表述是不是太模糊。比如“错误处理要规范”这种话，Agent 理解不了，要改成“所有错误必须用AppError包装，包含 code 和 message 字段”。第三，如果规范清晰但 Agent 还是犯错，可能是上下文里没有相关的示例代码。在CLAUDE.md里附上一段正确示例，效果会好很多。

5.2 Plan Mode 方案看着对但执行出来不对

这种情况通常是方案太粗，缺少关键细节。比如方案里写“处理无效 ID”，但没写清楚是报错还是忽略，Agent 执行时就可能选错。

解决办法是在 Plan Mode 的“实现步骤”里，要求 Agent 对每个步骤补充“预期结果”。比如“处理无效 ID，预期结果是返回成功响应，无效 ID 在结果中标记为 null”。这样执行的时候就有明确的判断标准。

5.3 Agent 执行到一半卡住或报错

Agent 卡住的原因通常有三类：一是任务太复杂，超出了它的处理能力；二是遇到了它不熟悉的错误，排查不下去；三是上下文丢失，忘了之前做了什么。

我的处理方式是：先看它的错误信息，如果是明确的编译或测试错误，把错误信息贴回去，让它继续排查；如果是它反复在同一个地方打转，就打断它，把任务拆小，分步执行；如果是上下文丢失，重新给它完整的任务描述和当前进度。

提示：我一般会要求 Agent 在执行过程中定期输出进度，比如每完成一个步骤就报一下。这样卡住的时候能快速定位到是哪一步出的问题。

5.4 团队抵触 AI Native 流程怎么办

这是人的问题，不是技术问题。抵触通常来自两个原因：一是觉得 AI 抢饭碗，二是觉得流程变复杂了，不如自己写快。

对于第一种，要明确传达“AI 是工具不是替代”的定位，同时在实际工作中让成员感受到，用了 AI 之后自己的产出更高、加班更少。对于第二种，要先在小范围跑出效果，用数据说话。我一般会统计“传统方式耗时”和“AI Native 方式耗时”的对比，在团队会上展示，效果比讲道理好得多。

5.5 常见问题速查表

6. 落地效果衡量与持续迭代

6.1 怎么判断 AI Native 落地成功了

不能只看“用了多少 AI 工具”，要看实际效果。我一般用四个指标衡量。

任务吞吐量：同样时间内，团队完成的任务数量有没有提升。我实测下来，跑顺之后提升 30%-50% 是正常的。

一次通过率：Agent 产出的代码，不需要返工就能通过审查的比例。这个指标反映的是上下文文件和 Plan Mode 的质量。初期可能只有 40%，迭代几周后能到 70% 以上。

新人上手时间：新人从入职到能独立提交符合规范的代码，需要多长时间。传统方式下通常要 2-4 周，AI Native 方式下能压缩到 1 周以内。

人的时间分配：团队成员花在“执行”上的时间占比有没有下降，花在“判断和设计”上的时间有没有上升。这个指标最能反映转型是否到位。

6.2 持续迭代的节奏

AI Native 不是一次性的项目，是持续迭代的过程。我建议的节奏是：每周花 15 分钟回顾 Agent 出的问题，更新CLAUDE.md；每两周回顾一次流程参数，看有没有需要调整的；每月做一次效果复盘，看四个指标的变化趋势。

迭代的重点始终是CLAUDE.md和 Skill 库。这两个东西越完善，Agent 的表现越好，人的介入越少。我见过跑得最好的团队，CLAUDE.md迭代了上百个版本，Skill 库有几十个常用操作，Agent 能独立处理八成的日常开发任务。

6.3 我踩过的几个坑

第一个坑是一开始就想写完美的 CLAUDE.md。我花了整整一周写了一个几百行的文件，结果发现很多内容根本用不上，真正有用的就是那几十行常用命令和核心规范。后来我改成先写最小可用版本，用起来再补，效率高多了。

第二个坑是过度依赖 Plan Mode。有段时间我要求所有任务都走 Plan Mode，结果简单任务也要等方案审核，反而变慢了。后来改成按复杂度判断，简单任务直接执行，效率才回来。

第三个坑是忽视人的验收。有段时间我太信任 Agent，验收环节走过场，结果上线后发现一个边界条件没处理。从那以后，我坚持核心逻辑必须人工验收，不管 Agent 说得多有信心。

第四个坑是Skill 沉淀过早。有些操作只做了两三次就沉淀成 Skill，结果后来发现步骤还会变，Skill 反而成了负担。现在我要求一个操作至少重复 5 次以上，才考虑沉淀。

这套东西说到底，核心就一句话：把团队的知识和规范显性化，让 Agent 能读懂、能执行，人从执行者变成判断者。听起来简单，做起来每个环节都有细节。我个人的体会是，最难的不是技术，是习惯的转变——团队要习惯“先写清楚再动手”，习惯“审核方案而不是审核代码”，习惯“把经验沉淀下来而不是留在脑子里”。这些习惯养成了，AI Native 才算真正落地。