企业官网建设流程全解析

1. 从"人写代码"到"人管意图"：AI Native 团队到底在变什么

这两年"AI Native"这个词被喊得太多，多到有点廉价。但我真正带团队把一整套研发流程从传统模式切到 AI Native 模式之后，才发现大多数人对它的理解停留在"用 AI 写代码"这个层面——这其实是最浅的一层。真正的 AI Native 团队，变的是整个软件开发生命周期（SDLC）的组织方式：需求怎么进来、方案怎么定、代码谁来写、测试谁来跑、上线谁把关，每一个环节的"人机分工"都被重新分配了一遍。

我先把结论摆出来：AI Native 团队的核心不是"AI 替代人"，而是人从"执行者"变成"意图定义者 + 质量守门人"。以前一个工程师 80% 的时间在敲代码、调 bug、写测试，20% 在想"这个需求到底要什么"。现在这个比例反过来了——你要花大量时间把意图表达清楚，把约束条件写明白，把验收标准定死，然后让 Agent 去执行。执行得对不对，取决于你意图表达得够不够精确。

这个转变听起来简单，落地的时候全是坑。我见过太多团队买了最贵的模型、搭了最花哨的 Agent 框架，结果效率不升反降——因为他们的 SDLC 还是老的那一套，只是硬塞了个 AI 进去。就像给马车装了个喷气发动机，车架先散架了。

所以这篇手册我想讲的是完整落地这件事：从团队角色怎么重新划分，到 CLAUDE.md 这类"项目宪法"怎么写，到 Plan Mode 这种规划机制怎么用，到 Agent 的架构怎么设计、安全边界怎么划、评测集怎么建。这些不是理论，是我和团队一个个坑踩出来的。适合谁看？适合正在或者准备把团队往 AI Native 方向转的技术负责人、一线工程师，以及想搞清楚"Agent 开发到底怎么回事"的开发者。哪怕你现在只是一个人用 AI 辅助写代码，这里面的思路也能直接用。

2. 重新定义 SDLC：AI Native 团队的五个阶段与人的站位

传统 SDLC 是需求、设计、开发、测试、部署、运维这条线，每个阶段都有明确的人在做。AI Native 之后，这条线还在，但每个阶段的"人机配比"完全变了。我把它拆成五个阶段来讲，每个阶段说清楚人该干什么、Agent 该干什么、边界在哪。

2.1 需求阶段：从"写文档"到"写意图契约"

传统需求阶段，产品经理写 PRD，工程师读 PRD，中间靠会议对齐。AI Native 模式下，需求文档的形态变了——它不再是给人读的自然语言描述，而是给 Agent 读的意图契约。什么意思？就是你要把需求写成结构化的、无歧义的、带验收标准的格式，因为 Agent 不会像人一样"猜你的意思"。

我们团队现在的做法是：需求进来先过一遍"意图澄清"，把模糊的地方全部问清楚，然后写成一份带以下要素的文档：

• 目标：这个功能要解决什么问题，一句话说清
• 输入输出：明确的接口定义、数据结构
• 约束条件：性能要求、兼容性要求、不能碰的东西
• 验收标准：可执行的测试用例，或者可验证的行为描述
• 边界情况：异常输入、并发场景、降级策略

这份文档写完之后，Agent 可以直接拿它去生成方案和代码。人的角色从"写文档的人"变成"定义契约的人"。这里有个反直觉的点：需求阶段人的工作量不是减少了，而是增加了。因为你要把以前靠口头沟通、靠默契补全的东西，全部显式写出来。但这一步做扎实了，后面开发和测试阶段能省下大量返工。

2.2 设计阶段：Plan Mode 让 Agent 先"想"再"做"

设计阶段是 AI Native 团队最容易出问题的地方。很多人直接让 Agent 拿到需求就开写，结果写出来的东西结构混乱、到处是补丁。正确的做法是引入Plan Mode——让 Agent 先输出一份实现计划，人审核通过之后再进入编码。

Plan Mode 的核心价值在于把"思考"和"执行"分离。Agent 在规划模式下，只输出方案：要改哪些文件、新增哪些模块、用什么数据结构、有哪些风险点、分几步走。人看完这份计划，能快速判断方向对不对，不对就让它重规划，成本极低。如果直接让它写代码，方向错了就是几百行代码白写。

我们团队的实践是：Plan Mode 输出的计划必须包含"影响面分析"——这个改动会影响到哪些现有功能、哪些接口、哪些测试。这一步能挡掉大量"改一处崩三处"的问题。审核计划的时候，我重点关注三件事：模块划分是否合理、依赖关系是否清晰、有没有遗漏的边界情况。这三点过了，编码阶段基本不会跑偏。

2.3 开发阶段：Agent 写代码，人管"意图一致性"

到了编码阶段，Agent 是主力。但"Agent 写代码"不等于"人不管了"。人的核心职责变成了保证意图一致性——Agent 写出来的代码，是不是真的实现了需求契约里定义的东西。

这里有个很实用的技巧：让 Agent 自己写测试，但测试的验收标准由人来定。Agent 写的测试容易"迎合自己的实现"，就是它写什么代码就测什么，测了个寂寞。所以我们的做法是，人在需求阶段就把关键验收用例定好，Agent 写完代码后必须让这些用例全绿，才算完成。

另一个经验是小步提交。不要让 Agent 一口气写几千行，而是按 Plan Mode 里的步骤，一步一提交，每步都跑测试。这样出问题的时候，定位范围小，回滚成本低。我见过有人让 Agent 一次性重构整个模块，结果出了个隐蔽 bug，排查了两天才发现是某一步的假设错了——如果分步提交，第二步就能发现。

2.4 测试阶段：Agent 生成用例，人建评测集

测试阶段是 AI Native 团队能拉开差距的地方。传统测试靠人写用例，覆盖率上不去，边界情况容易漏。AI Native 模式下，Agent 可以批量生成测试用例，覆盖各种边界和异常场景。但这里有个关键：Agent 生成的用例质量参差不齐，必须有人来建"评测集"。

评测集是什么？就是一组固定的、有标准答案的、能自动跑的测试用例集合。它不追求覆盖率，追求的是"能稳定衡量质量"。每次 Agent 改完代码，跑一遍评测集，看通过率有没有下降。这比看代码 diff 靠谱得多。

我们团队的评测集分三层：单元层（函数级正确性）、集成层（模块间协作）、端到端层（完整业务流程）。每层都有固定的用例，Agent 每次提交都要全跑。评测集的维护是持续工作——发现新 bug 就补一条用例进去，让它永远不再犯。

2.5 部署与运维：Agent 值守，人定策略

部署和运维阶段，Agent 可以做很多值守类工作：监控告警、日志分析、异常定位、甚至自动回滚。但策略必须由人来定。什么情况自动回滚、什么情况只告警、什么情况需要人工介入，这些决策边界要提前写清楚，写成 Agent 能执行的规则。

我们现在的做法是：把运维策略写成一份"运行手册"，Agent 按手册执行。手册里明确写了各种异常场景的处置流程。Agent 遇到手册里没写的情况，就升级给人处理。这样既保证了响应速度，又不会让 Agent 在没授权的情况下乱动生产环境。

3. CLAUDE.md 这类"项目宪法"：为什么它是 AI Native 的地基

如果你只从这篇手册里带走一件事，我希望是这一件：给 Agent 写一份项目级的"宪法"文件。在 Claude Code 生态里它叫 CLAUDE.md，在其他 Agent 工具里可能叫别的名字，但本质一样——它是 Agent 每次进入项目时必读的上下文，定义了"这个项目是什么、怎么组织、有什么规矩"。

3.1 没有项目宪法的团队，Agent 每次都在"重新认识项目"

我刚开始用 Agent 的时候，最大的痛点就是：每次开新会话，Agent 都像失忆一样，不知道项目结构、不知道代码规范、不知道哪些文件不能碰。你得一遍遍重复解释，效率极低。更糟的是，它会按自己的"通用习惯"写代码，跟你项目的风格完全不搭。

CLAUDE.md 解决的就是这个问题。它是一份放在项目根目录的 Markdown 文件，Agent 启动时自动读取。里面写什么？我总结了几个必备板块：

• 项目概述：这个项目是干什么的，技术栈是什么
• 目录结构：关键目录的用途，哪些是源码、哪些是配置、哪些是生成物
• 代码规范：命名约定、格式化规则、注释要求
• 构建与测试命令：怎么编译、怎么跑测试、怎么本地启动
• 禁区：哪些文件不能改、哪些操作不能做
• 常用模式：项目里反复出现的代码模式，让 Agent 照着写

这份文件写好了，Agent 的"上手成本"几乎为零。新来的工程师也能靠它快速理解项目。

3.2 一份能用的 CLAUDE.md 该写哪些内容

我拿我们一个真实项目的 CLAUDE.md 结构来举例，你可以直接参考这个骨架：

# 项目名称 ## 项目概述 一句话说明项目用途，核心技术栈版本。 ## 目录结构 - src/ 源码目录 - src/api/ 接口层 - src/service/ 业务逻辑层 - tests/ 测试目录 - config/ 配置文件 ## 开发规范 - 使用 TypeScript strict 模式 - 函数命名用 camelCase，类型用 PascalCase - 每个导出函数必须有 JSDoc 注释 - 禁止使用 any 类型 ## 常用命令 - 安装依赖：npm install - 本地启动：npm run dev - 跑测试：npm test - 类型检查：npm run typecheck ## 禁区 - 不要修改 config/production.json - 不要直接操作数据库，走 service 层 - 不要引入新的第三方依赖，除非明确要求 ## 代码模式 （附上项目里典型的代码片段作为参考）

这份文件不是写完就完了，它是活的。每次发现 Agent 犯了重复错误，就往里加一条规则。比如它老是忘记处理空值，就加一条"所有外部输入必须做空值检查"。用久了，这份文件就成了项目的"经验沉淀"。

3.3 项目宪法怎么写才不会被 Agent 忽略

这里有个坑：CLAUDE.md 写太长，Agent 会"选择性忽略"。我试过写了两千多行，结果 Agent 经常漏掉关键规则。后来我总结出几条原则：

第一，规则要具体、可执行。不要写"代码要优雅"这种没法执行的，要写"函数不超过 50 行"这种能判断的。

第二，重要规则放前面。Agent 对上下文的注意力是递减的，越靠前的内容权重越高。禁区、核心规范这些放最前面。

第三，用例子代替描述。与其描述"接口要这样写"，不如直接贴一段标准接口代码。Agent 模仿能力很强，给例子比给描述有效。

第四，分层组织。项目级的通用规则放根目录的 CLAUDE.md，模块级的规则放各模块目录下的 CLAUDE.md。Agent 进入某个模块时，会同时读两级规则。

提示：CLAUDE.md 里的规则要定期清理。过时的规则会让 Agent 困惑，甚至产生矛盾行为。我一般每个月过一遍，删掉不再适用的。

4. Agent 架构与编排：从单 Agent 到多 Agent 协作的取舍

聊完流程和宪法，进入技术核心：Agent 到底怎么搭。这块是热词里出现频率最高的——agent架构、agent框架、agent编排、agent记忆、agent沙箱，全是围绕这个的。我按实际落地顺序讲。

4.1 单 Agent 够用吗：先别急着上多 Agent

新手最容易犯的错，就是一上来就搞多 Agent 协作。什么规划 Agent、执行 Agent、审核 Agent，搭得花里胡哨，结果调试地狱。我的建议是：能用单 Agent 解决的，绝不上多 Agent。

单 Agent 的优势是链路短、状态简单、调试容易。一个 Agent 拿着工具集，按 Plan Mode 规划、执行、验证，大部分任务都能搞定。什么时候才需要多 Agent？当任务天然可以并行，或者需要不同角色互相制衡的时候。比如一个负责写代码、一个负责审查代码，这种"对抗式"设计能提高质量。但如果只是串行任务，多 Agent 只会增加通信开销和出错概率。

我们团队的经验是：先单 Agent 跑通，遇到明确的瓶颈再拆。瓶颈通常是两类：一是上下文太长导致 Agent 注意力涣散，二是任务需要不同"人格"（比如一个激进一个保守）。这两类问题才值得上多 Agent。

4.2 Agent 的记忆设计：短期、长期、工作记忆怎么分

Agent 的"记忆"是热词里反复出现的，也是实际开发中最容易设计错的地方。我把 Agent 记忆分成三类：

短期记忆：当前会话的上下文。就是对话历史，Agent 靠它理解"刚才说到哪了"。这块的坑是上下文窗口有限，聊太久会丢信息。解决办法是定期做"上下文压缩"——把历史对话总结成要点，释放窗口空间。

长期记忆：跨会话的知识。比如项目规范、历史决策、用户偏好。这块通常存在外部文件或数据库里，Agent 需要时检索。CLAUDE.md 就是一种长期记忆的载体。

工作记忆：当前任务的中间状态。比如 Plan Mode 生成的计划、已经完成的步骤、待办事项。这块要显式管理，不能让 Agent 自己"记在脑子里"，因为它随时可能忘。我们的做法是把工作记忆写成文件，Agent 每步都读写这个文件，保证状态不丢。

记忆设计的核心原则是：该显式化的绝不隐式化。Agent 不像人，它没有"潜意识"，所有需要记住的东西都要有明确的存储和读取机制。

4.3 工具调用与沙箱：Agent 的手脚和安全边界

Agent 要干活，就得有"手脚"——工具调用。读文件、写文件、跑命令、调接口，这些都是工具。工具设计有两个关键点：粒度和安全。

粒度上，工具不要太细也不要太粗。太细（比如"读一行"）会导致调用次数爆炸，太粗（比如"重构整个项目"）会导致 Agent 失控。合适的粒度是"一个完整的、有明确语义的操作"，比如"读取文件内容""在指定位置插入代码""运行测试"。

安全上，沙箱是必须的。Agent 跑命令、改文件，必须在受控环境里。我们团队的沙箱策略是：

• 文件操作限制在项目目录内，不能碰系统文件
• 命令执行有白名单，危险命令（删除、格式化）直接拦截
• 网络访问有审计，记录所有外部请求
• 敏感操作（改生产配置、推代码）需要人工确认

注意：沙箱不是可选项。我见过 Agent 误删项目文件的案例，没有沙箱兜底，损失是实打实的。

4.4 编排模式：串行、并行、对抗，什么时候用哪个

Agent 编排（orchestration）决定了多个 Agent 或步骤之间怎么协作。三种基本模式：

串行：A 做完交给 B，B 做完交给 C。适合有明确依赖关系的流程，比如"规划→编码→测试"。简单可靠，但慢。

并行：多个 Agent 同时干活，最后汇总。适合任务可拆分的场景，比如"同时给五个模块写测试"。快，但需要处理冲突。

对抗：一个 Agent 产出，另一个 Agent 挑刺，循环直到达标。适合质量要求高的场景，比如"代码审查"。质量高，但成本也高。

实际项目里通常是混合的。我们的代码开发流程就是：规划（单 Agent）→ 编码（单 Agent）→ 审查（对抗，一个写一个审）→ 测试（并行，多个测试 Agent 同时跑）。选哪种模式，看任务的性质和你的质量要求。

5. Agent 安全与评测：怎么知道你的 Agent 是"靠谱"的

Agent 能干活之后，下一个问题就是：它干得对不对、安不安全。这块是很多团队忽略的，但恰恰是 AI Native 能不能真正落地的关键。

5.1 Agent 的失控场景：从"幻觉"到"越权"

Agent 失控的场景比你想的多。我列几个真实遇到过的：

幻觉型失控：Agent 编造了一个不存在的 API，代码跑不起来。或者它"以为"某个文件存在，直接去读，报错。

越权型失控：Agent 为了完成任务，擅自修改了不该改的文件，或者执行了危险命令。比如它觉得"这个配置碍事"，就把它删了。

循环型失控：Agent 陷入死循环，反复做同一个操作，烧掉大量 token 和时间。

目标偏移型失控：Agent 在执行过程中"理解偏了"，做出来的东西跟需求南辕北辙，但它自己觉得完成得很好。

这些场景的共同点是：Agent 没有"常识"和"边界感"。它只会按字面执行，不会像人一样"觉得不对劲就停下来"。所以安全机制必须由外部强加。

5.2 权限分级与人工确认点怎么设

我们的做法是权限分级 + 人工确认点。把 Agent 的操作按风险分成三级：

人工确认点设在"不可逆操作"之前。什么是不可逆？删了恢复不了的、推上去影响别人的、改了生产影响用户的。这些操作 Agent 必须停下来等人点头。

这里有个经验：确认点不要设太多，否则人会被打断到崩溃，最后干脆全部放行，安全机制形同虚设。只在高风险操作前设确认，中低风险靠日志和回滚兜底。

5.3 评测集构建：让 Agent 的质量可量化

Agent 的质量怎么衡量？靠感觉不行，得靠数据。评测集就是干这个的。它是一组固定的测试任务，每个任务有明确的预期结果，Agent 跑完能算出通过率。

评测集怎么建？我的步骤是：

1. 收集真实任务：从历史项目里挑出有代表性的任务，覆盖各种类型
2. 定义预期结果：每个任务的正确输出是什么，要能自动判断
3. 分层组织：简单任务、中等任务、困难任务分开，看 Agent 在不同难度上的表现
4. 持续补充：每次发现 Agent 犯错，就把这个场景加进评测集

评测集的价值在于可比较。你换了模型、改了提示词、调了架构，跑一遍评测集就知道是变好了还是变差了。没有评测集，所有优化都是"感觉好像好点了"，不可靠。

5.4 从评测结果反推提示词和架构优化

评测集跑出来的结果，是优化的指南针。我一般看三个指标：通过率、平均耗时、平均 token 消耗。

通过率低，说明 Agent 能力不够或者提示词不清楚。这时候先看失败案例，是"不会做"还是"理解错了"。不会做就补上下文或换模型，理解错了就改提示词。

耗时和 token 消耗高，说明流程有冗余。可能是 Plan Mode 规划太啰嗦，或者工具调用次数太多。这时候优化的是架构和工具设计。

我踩过的一个坑：一开始只看通过率，忽略了 token 消耗。结果通过率上去了，成本也上去了，一算账不划算。后来把成本纳入评测指标，才找到平衡点。

6. 落地路线图：一个团队从零到 AI Native 的实操步骤

讲了这么多原理，最后落到"怎么做"。我给一个可执行的路线图，分四周推进，适合中小团队。

6.1 第一周：选一个低风险项目试点

不要一上来就全团队全项目切换，风险太大。选一个低风险、边界清晰、有明确验收标准的项目试点。比如一个内部工具、一个独立模块的重构。

这一周的目标是跑通流程，不是追求效率。让团队熟悉 Plan Mode、CLAUDE.md、评测集这些概念，建立基本的工作习惯。产出是一份试点报告：哪些环节顺、哪些环节卡、Agent 在哪些任务上表现好。

6.2 第二周：建立项目宪法和评测基线

试点跑通后，把经验沉淀成项目宪法（CLAUDE.md）和评测基线（第一版评测集）。这两样东西是后续所有工作的基础。

项目宪法要覆盖试点中暴露的所有问题——Agent 犯过的错、需要反复解释的规则，全部写进去。评测基线要能自动跑，给出通过率数字。有了基线，后面所有优化才有参照。

6.3 第三周：扩展场景，补齐安全机制

基线建立后，开始扩展应用场景。从试点项目扩展到相关模块，从单一任务类型扩展到多种任务类型。同时补齐安全机制：权限分级、沙箱、人工确认点。

这一周的重点是发现边界。哪些任务 Agent 做得好，哪些做不好，做不好的原因是能力问题还是流程问题。把边界摸清楚，才知道 AI Native 的适用范围。

6.4 第四周：全流程复盘与规模化准备

最后一周做全流程复盘。把四周的数据拉出来：效率提升了多少、质量变化如何、成本增加多少、团队接受度怎么样。基于数据决定下一步：是继续扩大范围，还是先解决暴露的问题。

规模化的关键是可复制。把试点中形成的流程、宪法、评测集模板化，让其他团队能直接套用。这一步做扎实了，AI Native 才能真正在组织里铺开，而不是停留在个别团队的"个人英雄主义"。

7. 那些没人告诉你但一定会踩的坑

最后这部分，是我和团队踩过的坑，文档里不会写，但实际做的时候一定会遇到。

坑一：Agent 的"过度自信"。Agent 经常在没把握的时候也表现得很有把握，说"已完成"但实际没做完。对策是强制验证——任何"完成"的声明，都要有可验证的证据（测试通过、命令输出、文件 diff）。

坑二：上下文污染。长会话里，早期的错误信息会一直影响 Agent 的判断。对策是定期开新会话，把必要状态显式传递过去，而不是让 Agent 背着历史包袱干活。

坑三：提示词的"边际递减"。提示词写到一定程度，再加内容收益就很小了。这时候该优化的是架构和工具，而不是继续堆提示词。我见过有人把提示词写到上万字，效果还不如重构一下工具设计。

坑四：团队的心理阻力。不是所有人都愿意把代码交给 Agent 写。有人觉得"这不安全"，有人觉得"这不算我的工作"。对策是用数据说话——拿评测集的结果、效率的对比，让事实说服人。同时给团队时间适应，不要强推。

坑五：把 Agent 当"万能工具"。Agent 擅长的是有明确规则、可验证的任务。对于需要大量领域判断、模糊决策的任务，它表现很差。认清这个边界，把 Agent 用在刀刃上，比什么都重要。

我个人在实际操作中的体会是：AI Native 不是一次性的技术升级，而是工作方式的持续演进。工具会变、模型会变、最佳实践也会变，但核心不变——人定义意图和质量标准，Agent 负责执行，评测集负责衡量。这三件事立住了，剩下的就是不断迭代。