企业官网建设流程全解析

1. 从"用AI写代码"到"AI Native 团队"：差的不是工具，是整套协作契约

这两年我参与过几个号称"全面拥抱 AI"的团队，也帮朋友的公司做过研发流程改造。一个很普遍的现象是：大家把 Copilot、Claude、Cursor 装了个遍，代码补全确实快了，但一到需求评审、联调、上线，节奏还是老样子——该堵的堵，该返工的返工。工具换了，流程没换，人也没换，最后得出的结论往往是"AI 也就那样"。

问题出在哪？出在大多数团队把 AI 当成了一个"更快的打字员"，而不是把它当成一个有上下文、有记忆、有边界、需要被编排的团队成员。这就是 AI Native 团队和"用了 AI 的团队"最本质的区别。前者重新设计了整个软件开发生命周期（SDLC），让 AI 从需求澄清、方案设计、编码、测试到文档沉淀都占据一个明确的位置；后者只是给旧流程贴了一层 AI 皮肤。

这篇手册想聊的就是前者。它适合三类人：一是正在推动团队 AI 化转型的技术负责人，二是想搞清楚 Agent 到底怎么落地到真实项目里的工程师，三是已经在用 Claude Code、Cursor 这类工具但总觉得"没发挥出全部威力"的开发者。我会把 AI Native 团队的完整落地路径拆开讲——从协作契约的设计、CLAUDE.md 这类"团队记忆文件"的写法、Plan Mode 的正确用法，到 Agent 的架构选型、并发与安全、记忆机制，再到怎么衡量这套东西到底有没有用。全程都是我在实际项目里踩过、验证过的东西，不是概念科普。

先给一个我自己的定义，方便后面展开：AI Native 团队 = 一套以 Agent 为核心执行单元、以结构化上下文为协作媒介、以人做决策与兜底的研发组织形态。关键词是"结构化上下文"和"人做决策"，这两点后面会反复出现。

2. AI Native SDLC 到底长什么样：把每个阶段重新分配给人还是 Agent

2.1 传统 SDLC 的瓶颈从来不在写代码

很多人以为 AI 提效最大的环节是编码，其实不是。我统计过自己参与的项目，一个需求从提出到上线，纯编码时间大概只占 25% 到 35%，剩下的大头是：需求澄清反复拉扯、方案设计来回讨论、联调时接口对不上、测试用例覆盖不全、上线后文档没人更新。编码快了一倍，整体交付周期可能只缩短 10%。

所以 AI Native SDLC 的设计重点，不是"让 AI 写更多代码"，而是让 AI 吃掉那些重复的、信息搬运型的、需要跨文件检索的工作。下面这张表是我在几个项目里实际跑下来，各阶段人机分工的一个参考：

这张表的核心逻辑是：凡是"信息已经存在，只是需要被搬运、比对、展开"的工作，交给 Agent；凡是"需要判断、权衡、承担后果"的工作，留给人。这条线划清楚了，AI Native 的落地就不会跑偏。

2.2 为什么"上下文"比"模型能力"更决定成败

我见过太多团队纠结"用 GPT 还是 Claude 还是国产模型"，但真正决定 Agent 输出质量的，是它拿到的上下文。同一个模型，给它一份结构清晰的 CLAUDE.md 和一堆散乱的聊天记录，产出质量能差出三倍。

这里有个反直觉的结论：在 AI Native 团队里，写"给 AI 看的文档"比写"给人看的文档"更重要。因为人可以从模糊描述里脑补出意图，AI 不行。你写"接口要健壮一点"，人知道大概是要加校验和重试，AI 可能给你加一堆 try-catch 然后吞掉异常。

所以 AI Native 团队的第一项基建，不是买工具，而是建立一套机器可读的项目上下文体系。这套体系通常包含：

• 项目级记忆文件（如 CLAUDE.md）：技术栈、目录约定、命名规范、禁止事项
• 模块级说明：每个核心模块的职责边界、依赖关系
• 决策记录：为什么选了这个方案而不是那个，避免 Agent 反复"重新发明轮子"
• 接口契约：结构化的 API 定义，让 Agent 能直接比对

这套东西听起来像"文档工作"，但它其实是 AI Native 团队的"操作系统"。没有它，Agent 每次都是从零开始猜，你永远在给它擦屁股。

2.3 一个真实的落地节奏：别想一步到位

我建议的推进节奏是分三步，别一上来就搞全流程自动化：

1. 单点突破：先在一个模块里把 CLAUDE.md 写扎实，让 Agent 稳定产出符合规范的代码。这一步的目标是"让团队相信 AI 能按我们的规矩干活"。
2. 流程串联：把 Plan Mode 引入方案设计，把 Agent 引入测试用例生成，形成"设计-编码-测试"的小闭环。
3. 组织固化：把上下文文件纳入代码仓库管理，把 Agent 的使用规范写进团队 onboarding，新人第一天就学怎么和 Agent 协作。

我见过跳过第一步直接搞第三步的团队，结果就是上下文文件写得又长又空，Agent 根本不遵守，最后大家又退回手写。上下文文件的质量，是靠一个个真实任务磨出来的，不是一次性写出来的。

3. CLAUDE.md 这类"团队记忆文件"怎么写才不沦为摆设

3.1 大多数 CLAUDE.md 失败的原因：写成了 README

我翻过不少团队的 CLAUDE.md，十个里有八个长这样：项目简介、技术栈、如何启动、目录结构。这基本就是把 README 复制了一遍。问题是，README 是给人看的，人看完就懂了；Agent 需要的是可执行的约束和明确的边界。

一份有效的 CLAUDE.md，核心不是"介绍项目"，而是"约束行为"。它要回答的是：Agent 在这个项目里，什么能做、什么不能做、遇到某类问题该怎么做。举个具体对比：

• 无效写法："本项目使用 TypeScript，注重代码质量。"
• 有效写法："所有新增函数必须显式标注返回类型；禁止使用 any，如需动态类型用 unknown 并做类型收窄；错误处理统一用 Result 类型，禁止直接 throw。"

后者才是 Agent 能直接执行的指令。前者它只能靠猜。

3.2 一份可复用的 CLAUDE.md 骨架

下面是我在项目里反复迭代出来的一份骨架，你可以直接拿去改。注意每一块都对应一类"Agent 容易犯错的地方"：

# 项目上下文 ## 技术栈与版本 - 语言：TypeScript 5.x，严格模式开启 - 框架：React 18 + Vite - 测试：Vitest + Testing Library - 包管理：pnpm（禁止使用 npm/yarn） ## 目录约定 - src/features/：按业务域组织，每个域自包含 - src/shared/：跨域复用，改动需谨慎 - 禁止在 features 之间直接互相 import，必须通过 shared ## 编码规范 - 组件一律函数式，禁止 class 组件 - 状态管理优先用局部 state，跨组件才上 store - 所有异步操作必须有 loading 和 error 分支 ## 禁止事项 - 禁止引入新的 UI 库，现有组件不够用时先提 issue - 禁止修改 shared/ 下的公共类型而不更新所有引用方 - 禁止在提交信息里写"fix bug"这类无意义描述 ## 常见任务指引 - 新增页面：参考 src/features/user 的结构 - 新增 API：先在 shared/api 定义类型，再实现

这份骨架的关键在于：每一条都是"可验证"的。Agent 写完代码，你可以对照检查它有没有违反。而"注重代码质量"这种话，没法验证，等于没说。

3.3 记忆文件的维护：让它随项目一起"生长"

CLAUDE.md 不是写完就完事的。我的做法是：每次 Agent 犯了同类错误两次以上，就把对应的约束补进去。比如它老是忘记给异步操作加 error 分支，那就在规范里明确写死。这样这份文件会越来越贴合项目的真实痛点。

另外，记忆文件要分层。项目根目录放全局约束，各模块目录下可以放模块级的补充说明。Agent 处理某个模块时，会同时读到全局和模块级的上下文，这样既保证一致性，又保留灵活性。

提示：记忆文件一定要纳入 Git 管理，和代码一起 review。我见过把 CLAUDE.md 放在本地不提交的，结果每个人机器上的 Agent 行为都不一样，协作时全是坑。

4. Plan Mode 的正确打开方式：先想清楚再动手，而不是让 Agent 边写边猜

4.1 为什么"直接让 Agent 写代码"是最贵的做法

新手用 Agent 最常见的操作是：把需求一贴，直接说"帮我实现"。然后 Agent 吭哧吭哧写了一堆，你一看，方向全错，推倒重来。这个过程浪费的不只是 token，还有你的 review 时间和耐心。

Plan Mode 的价值就在这：让 Agent 先输出"打算怎么做"，你确认后再让它执行。这相当于把"返工"提前到了"纸面阶段"，成本低得多。我自己的经验是，用了 Plan Mode 之后，Agent 产出的一次通过率能从大概 40% 提到 75% 以上。

4.2 Plan Mode 里应该让 Agent 输出什么

不是让它写一段"我将要实现这个功能"的空话，而是要求它输出结构化的方案。我通常要求包含这几块：

1. 任务拆解：把需求拆成几个可独立验证的子任务
2. 影响面分析：会改动哪些文件、哪些模块、有没有破坏性变更
3. 方案选择：如果有多种实现路径，列出各自的取舍
4. 验证方式：怎么证明做完了、做对了
5. 风险点：哪些地方可能出问题、需要人工确认

举个实际例子。需求是"给用户列表加一个按注册时间筛选的功能"。让 Agent 在 Plan Mode 下输出，它应该告诉你：需要改列表组件、需要改查询 API、需要加一个日期选择器、可能影响分页逻辑、需要补测试用例。你一看，发现它漏了"时区处理"这个坑，就可以在计划阶段补上，而不是等它写完再发现。

4.3 Plan Mode 和"人做决策"的边界

这里要强调一个原则：Plan Mode 是让 Agent 提方案，不是让它替你拍板。我见过有人把 Plan Mode 的输出直接当最终方案执行，结果选了一个技术上可行但业务上不合适的路径。

正确的用法是：Agent 出方案，人做选择。尤其是涉及架构变更、第三方依赖引入、数据模型调整这类决策，必须人来定。Agent 擅长的是"穷举可能性"和"分析影响面"，不擅长的是"理解业务优先级"和"承担决策后果"。

注意：Plan Mode 的输出要存档。我习惯把每次的方案计划存到项目的 docs/plans/ 目录下，一是方便回溯"当时为什么这么设计"，二是这些计划本身就是很好的上下文，后续 Agent 处理相关任务时可以参考。

5. Agent 架构选型：别被框架绑架，先搞清楚你要解决什么问题

5.1 Agent 到底是什么，和普通脚本、和 harness 有什么区别

先把概念理清楚，因为这块被各种热词搅得很乱。

Agent的核心特征是：它能自主决定"下一步做什么"。你给它一个目标，它会自己规划步骤、调用工具、根据结果调整。而普通脚本是你把每一步都写死了，它只负责执行。

Harness这个词最近很火，它指的是"包裹在模型外面的那层脚手架"——负责给模型喂上下文、解析模型的输出、执行模型要求的工具调用、把结果再喂回去。你可以理解为：模型是发动机，harness 是变速箱和传动系统。很多所谓的"Agent 框架"，本质上就是在做 harness 的活。

搞清这个区别很重要，因为它决定了你的选型思路：如果你只是想让模型按固定流程干活，你需要的可能只是一个好的 harness，而不是一个复杂的 Agent 框架。过度设计是这块最常见的坑。

5.2 主流架构的取舍：ReAct、Plan-and-Execute、多 Agent

我实际用过的架构大概分三类，各有适用场景：

我的建议是：从 ReAct 起步，任务稳定后再考虑 Plan-and-Execute，多 Agent 除非任务真的能清晰拆分，否则别碰。多 Agent 听起来很酷，但实际项目里，两个 Agent 之间的沟通成本经常比它们各自干的活还大。

5.3 选型时真正该问的几个问题

别一上来就问"用哪个框架"，先问自己：

• 这个任务的步骤是固定的还是需要动态决策的？
• Agent 需要访问哪些工具（文件、数据库、API）？
• 出错了怎么回滚？有没有人工介入的检查点？
• 单次任务的 token 预算大概多少？能不能接受？
• 这个 Agent 是跑一次还是长期运行？

这几个问题答清楚了，框架选型基本就水到渠成了。我见过太多团队先选框架再想需求，最后发现框架的能力和自己的需求根本不匹配。

6. Agent 的记忆机制：为什么你的 Agent 总是"失忆"

6.1 短期记忆、长期记忆、工作记忆，别混为一谈

Agent 的"记忆"是个被说烂但很少说清的话题。我把它分成三层：

• 短期记忆：当前这次对话/任务的上下文，就是喂给模型的那些 token。它受限于上下文窗口，超了就丢。
• 长期记忆：跨任务持久化的信息，比如项目规范、历史决策。通常存在文件或数据库里，需要时检索出来。
• 工作记忆：Agent 在执行一个复杂任务时，中间产生的临时状态，比如"我已经改了哪几个文件""还剩哪几步"。

大多数 Agent "失忆"的问题，出在长期记忆和工作记忆没有做好衔接。比如它改完一个文件，下次再处理相关任务时，完全不知道上次改过什么。

6.2 用文件做长期记忆：简单但有效

我试过向量数据库、试过各种记忆框架，最后发现对大多数团队项目来说，用结构化的文件做长期记忆是最稳的。原因很简单：可读、可版本控制、可人工修正。

具体做法是维护几个文件：

• context/decisions.md：记录重要决策和原因
• context/conventions.md：编码和协作规范
• context/glossary.md：业务术语表，避免 Agent 理解偏差

Agent 每次启动时读这些文件，就相当于"回忆"起了项目的来龙去脉。这比向量检索更可控，因为你能直接看到它读到了什么。

6.3 工作记忆的管理：让 Agent 知道自己走到哪了

复杂任务里，Agent 很容易"忘记"自己已经做了什么。解决办法是让它显式地维护一个任务清单。比如用 TodoWrite 这类工具，把任务拆成条目，每完成一条就标记。这样即使上下文被截断，它也能通过读清单恢复状态。

我在实际项目里的经验是：任务超过 5 步，就一定要让 Agent 维护清单。否则它做到一半就开始重复劳动或者漏步骤。

7. 并发、安全与"Agent 到处跑"：落地时最容易被忽视的三件事

7.1 Agent 怎么扛并发：不是加机器那么简单

"AI Agent 怎么扛并发"是最近被问得很多的问题。我的看法是：先别急着扛并发，先搞清楚你的 Agent 是不是真的需要并发。

Agent 的并发和普通服务的并发不一样。普通服务是无状态的，加机器就行；Agent 是有状态的，它带着上下文、带着工具调用、带着中间结果。并发跑多个 Agent，最大的风险是它们互相踩脚——同时改同一个文件、同时调同一个有副作用的接口。

我的处理原则是：

• 读操作可以并发：多个 Agent 同时检索、分析，没问题
• 写操作必须串行或加锁：改文件、写数据库，要么排队，要么用锁
• 有副作用的工具调用要幂等：比如发消息、下单，必须能安全重试

如果确实需要高并发，通常的做法是给每个 Agent 分配独立的工作区（独立的文件副本或分支），最后再合并。这比让它们共享一个工作区安全得多。

7.2 Agent 安全：三个必须设的边界

Agent 安全不是"防黑客"那么遥远，日常就有很多风险点。我总结了三类必须设的边界：

1. 权限边界：Agent 能访问哪些文件、哪些接口、哪些数据。默认应该是最小权限，需要什么开什么。
2. 操作边界：哪些操作需要人工确认。比如删除文件、推送代码、调用支付接口，这些必须卡一道人工确认。
3. 资源边界：单次任务的 token 上限、执行时间上限、工具调用次数上限。防止 Agent 陷入死循环把预算烧光。

我踩过最惨的一次坑，是让 Agent 自动整理一个目录，结果它把不该动的文件也"整理"了。从那以后，凡是涉及删除和移动的操作，我一律加人工确认。

7.3 "Agent Anywhere"的诱惑与陷阱

现在很流行"让 Agent 无处不在"——自动发消息、自动整理笔记、自动处理邮件。这些场景确实诱人，但落地时要非常小心。

我的建议是：从"低风险、高频、可回滚"的场景开始。比如让 Agent 帮你把网页内容整理成 Markdown、帮你生成会议纪要草稿，这些即使出错，代价也小。而像"自动回复客户消息""自动提交代码"这类，一旦出错就是事故，必须有人工审核环节。

8. 怎么衡量 AI Native 改造到底有没有用

8.1 别只看"代码写了多少行"

衡量 AI Native 改造的效果，最容易犯的错是看"AI 生成了多少代码"。这个指标毫无意义，甚至有害——它鼓励 Agent 写更多冗余代码。

我实际用的指标是这几个：

• 需求到上线的周期：这是最终指标，但受太多因素影响，要结合其他指标看
• 一次通过率：Agent 产出不需要返工的比例，反映上下文质量
• 人工介入次数：一个任务里人需要介入多少次，反映自动化程度
• 返工原因分布：返工是因为需求不清、上下文缺失还是模型能力，反映改进方向

8.2 一个我常用的"周度复盘"方法

每周我会花半小时做一次复盘，记录这周 Agent 表现好的地方和翻车的地方。翻车的地方分两类：一类是上下文没给够，一类是模型能力确实不行。前者补上下文，后者调整任务分配。

坚持几周之后，你会发现一个规律：大部分翻车都是上下文问题，不是模型问题。这个认知会彻底改变你的优化方向——从"换更强的模型"转向"把上下文写得更清楚"。

9. 我在实际落地中踩过的几个坑

第一个坑是过早追求全自动化。一开始我想让 Agent 从需求到提交全自动跑通，结果每个环节都出问题，排查起来极其痛苦。后来改成每个环节单独跑通、人工确认后再串联，反而快得多。

第二个坑是上下文文件写得太长。我以为写得越详细越好，结果 Agent 读到后面就"忘了"前面。后来学会分层：全局的放根目录，模块的放模块目录，按需加载。

第三个坑是没有给 Agent 设预算上限。有一次一个 Agent 陷入循环，一晚上烧掉了一大笔 token。从那以后，所有 Agent 任务都设了执行时间和调用次数上限。

第四个坑是把 Agent 的输出直接当最终结果。早期我太信任它，结果它生成的测试用例看着很全，实际漏了关键边界。现在我坚持：Agent 产出必须经过人工 review，尤其是测试和涉及数据的部分。

10. 给准备启动 AI Native 改造的团队的最后几条建议

如果你正准备在团队里推这套东西，我的建议是：先选一个"痛但不致命"的场景试点。比如文档同步、测试用例生成、代码 review 辅助，这些场景失败了影响可控，成功了又能快速建立信心。

然后，把上下文建设当成一等公民。别把它当成"顺便写写"的文档，它是整个体系的地基。我甚至建议指定一个人专门负责维护项目的上下文文件，就像维护 CI 配置一样。

最后，接受"人机协作"而不是"人机替代"。AI Native 团队不是把人换掉，而是把人从重复劳动里解放出来，去做真正需要判断力的事。这个心态摆正了，落地过程会顺很多。

这套东西我还在持续迭代，每次项目跑完都会回头改上下文文件和协作规范。它不是一套一次成型的标准答案，而是一个需要和团队一起生长的实践体系。