企业官网建设流程全解析

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

先说一个我观察到的现象。过去两年，很多团队把 Copilot 装进 IDE，把聊天窗口挂在侧边栏，然后宣布自己“AI 化了”。但真到交付节点，节奏还是老样子：需求评审两小时，写代码三天，联调两天，测试一天，上线前夜通宵改 bug。工具换了，流程没换，人还是那个瓶颈。

AI Native 团队要动的不是工具，是软件开发生命周期（SDLC）的骨架。传统 SDLC 里，人负责从需求到代码到验证的全部环节，AI 只是加速某一个点；AI Native 的 SDLC 里，人负责定义意图、设定边界、验收结果，AI 负责在边界内自主完成从计划到执行到自检的闭环。这个转变听起来抽象，落到具体操作上，就是几个非常实在的东西：一份写清楚项目约束的CLAUDE.md、一套让 AI 先想再做的 Plan Mode 工作流、一组能并行干活的 Agent 编排、以及一套防止 Agent 跑偏的安全与验收机制。

我带的团队从去年开始按这套范式跑，最直观的变化是：一个中等复杂度的功能模块，从“提需求”到“可合并的 PR”，人介入的时间从原来的两三天压缩到半天以内，而且代码风格一致性反而比纯人工写的时候更好。原因不复杂——AI 不会因为赶进度就偷懒跳过测试，也不会因为心情不好就写出风格割裂的代码，前提是你把规则喂给它。

这篇手册面向的是正在或准备把团队往 AI Native 方向推的技术负责人、一线开发、以及想搞清楚“Agent 到底怎么落地”的工程师。我会把整套流程拆成可复制的步骤，包括配置文件怎么写、Plan Mode 怎么用、多 Agent 怎么编排、并发怎么扛、安全怎么兜底。不堆概念，只讲我实际跑通过的东西。

2. 地基先打好：CLAUDE.md 不是 README 的替代品

2.1 为什么一份项目约束文件决定了 Agent 的上限

很多人第一次用 Agent 写代码，上来就丢一句“帮我实现一个用户登录功能”，然后看着 Agent 自由发挥，最后拿到一堆能跑但完全不符合项目规范的代码，再花大量时间改。问题不在 Agent 笨，在于你没告诉它这个项目的“家规”。

CLAUDE.md这类项目级约束文件，本质上是给 Agent 的常驻上下文。它和 README 的区别在于：README 是给人看的，讲的是“这个项目是什么”；CLAUDE.md是给 Agent 看的，讲的是“在这个项目里干活必须遵守什么”。前者是介绍，后者是纪律。

我踩过的第一个坑就是没写这个文件。当时让 Agent 加一个接口，它用了项目里根本没引入的 HTTP 库，还自作主张改了目录结构。后来我把约束写清楚，同样类型的任务，Agent 一次就能给出符合规范的代码。这个投入产出比极高——写一份好的约束文件大概花两小时，但它能省下后面几十次返工。

2.2 一份能用的 CLAUDE.md 应该包含哪些块

我不建议照搬网上的模板，因为每个项目的技术栈和纪律点都不一样。但结构上，这几块是必须有的：

• 技术栈与版本锁定：明确语言、框架、关键依赖的版本。比如“Node 20 + TypeScript 5.4 + Fastify 4.x，禁止引入 Express”。Agent 在选型时最容易发散，锁死版本能避免它用上你根本没装的库。
• 目录结构与职责边界：说清楚哪个目录放什么。比如“所有数据库访问必须走src/repo/，业务逻辑放src/service/，路由层只做参数校验和转发”。这样 Agent 新增文件时不会乱放。
• 代码风格硬规则：命名约定、错误处理方式、日志规范。比如“所有异步函数必须用 try/catch 包裹并记录结构化日志，禁止裸抛异常”。
• 测试要求：什么级别的改动必须配什么级别的测试。比如“新增 service 方法必须配单元测试，覆盖率不低于 80%”。
• 禁止事项清单：这一块最容易被忽略但最重要。比如“禁止修改migrations/下已存在的文件”“禁止在业务代码里硬编码密钥”“禁止绕过 lint 提交”。

我习惯把这份文件控制在 200 行以内。太长了 Agent 反而抓不住重点，而且维护成本高。核心原则是：每一条规则都对应一个你真实踩过的坑或真实的团队约定，不要写正确的废话。

2.3 让约束文件“活”起来的维护节奏

写完不是终点。我的做法是把它当成活的文档：每次 Code Review 发现 Agent 犯了新类型的错误，就补一条规则进去。比如有次 Agent 在循环里做数据库查询，我就在约束里加了“禁止在循环体内发起 IO 操作，批量场景必须用批量接口”。下次它就不会再犯。

这里有个反直觉的经验：约束文件不是越细越好，而是越“可判定”越好。“代码要优雅”这种没法判定，Agent 不知道怎么做；“函数参数超过 4 个必须用对象传参”就可判定，Agent 能严格执行。写规则的时候多问自己一句：这条规则能不能用一句话判断对错？不能就重写。

3. Plan Mode：让 Agent 先交方案再动手，省下的返工时间远超想象

3.1 直接让 Agent 写代码，为什么大概率会翻车

我做过一个对比实验。同一个需求“给订单模块加一个超时自动取消的功能”，两种方式各跑五次。

第一种，直接下指令“实现订单超时自动取消”。五次里有四次 Agent 直接开始写代码，结果分别是：有的用了轮询、有的用了定时任务但没考虑分布式重复执行、有的改了订单状态机但没同步更新相关索引。能跑，但都需要人再花时间修正。

第二种，先让 Agent 进入 Plan Mode，输出实现方案，我确认后再执行。五次里有四次方案是合理的，唯一一次偏差是它没考虑时区问题，我在方案阶段就指出来了，改起来只是改几行文字。

差距在哪？代码是方案的下游，方案错了，代码写得再快也是白写。Plan Mode 的价值就是把纠错点前移到成本最低的阶段。改一行方案文字的成本，和改一堆已经写好的代码的成本，差着数量级。

3.2 Plan Mode 的实操流程与确认清单

具体怎么用？我的标准流程是这样的：

1. 下需求时明确要求先出计划。指令里带上“先不要写代码，输出实现计划，包括涉及的文件、改动点、潜在风险”。
2. Agent 输出计划后，逐项核对。我有一份固定的确认清单：
   • 涉及的文件是否都在预期目录内？
   • 有没有引入约束文件里禁止的依赖？
   • 边界情况（空值、并发、超时）有没有覆盖？
   • 测试计划是否包含？
   • 有没有需要人工决策的取舍点？
3. 确认或修正后，再让 Agent 执行。执行阶段我通常不再干预，除非它偏离了确认过的计划。

这里有个技巧：让 Agent 在计划里显式列出“我不确定的地方”。比如它会写“关于超时时间的配置来源，我假设从环境变量读取，如果不对请指出”。这种显式的不确定性标注，能让你快速定位需要人工决策的点，而不是等代码写完才发现假设错了。

3.3 什么任务值得走 Plan Mode，什么任务可以直接干

不是所有任务都值得走完整计划流程。我的判断标准很简单：

我一般的做法是：凡是改动超过三个文件，或者涉及状态变更、数据迁移、并发处理的，一律先走 Plan Mode。其他情况灵活处理。这个阈值可以根据团队熟练度调整，但核心逻辑不变——纠错越早越便宜。

4. Agent 编排：单打独斗和团队作战的边界在哪

4.1 一个 Agent 干到底，什么时候会力不从心

单个 Agent 处理一个完整功能，在中等复杂度下是够用的。但遇到这几种情况就会明显吃力：

• 任务跨度大：比如“设计数据库表 + 写后端接口 + 写前端页面 + 配部署脚本”，一个 Agent 在长上下文里容易丢失早期决策，导致前后不一致。
• 需要并行：多个独立子任务本来可以同时推进，单 Agent 只能串行。
• 需要不同专长：前端 Agent 和后端 Agent 关注点不同，用同一套上下文反而互相干扰。

我遇到过一次典型翻车：让一个 Agent 同时改后端接口和前端调用，结果它改了后端字段名但忘了同步前端，联调时才发现。这不是 Agent 能力问题，是任务编排问题。

4.2 多 Agent 分工的三种常见模式

根据我的实践，多 Agent 编排主要有三种模式，各有适用场景：

模式一：流水线式。Agent A 出方案，Agent B 按方案写代码，Agent C 做代码审查。适合对质量要求高、需要多重校验的场景。缺点是链路长，每个环节都要传递上下文。

模式二：并行分工式。把大任务拆成互不依赖的子任务，多个 Agent 同时干。比如前端 Agent 和后端 Agent 按约定好的接口契约各自实现。适合模块化清晰的项目。关键是接口契约必须先定死，否则并行出来的东西对不上。

模式三：主从式。一个 Orchestrator Agent 负责拆解任务和汇总结果，多个 Worker Agent 负责执行。适合任务边界不太清晰、需要动态调整的场景。这种模式对 Orchestrator 的规划能力要求高。

我团队目前主力用的是模式二，因为大部分功能模块的前后端边界是清楚的。模式一用在核心模块上，模式三还在小范围试验。

4.3 编排中最容易出问题的三个衔接点

多 Agent 协作，问题几乎都出在衔接处。我总结的三个高频坑：

第一个坑：上下文传递丢失。Agent A 做的决策，Agent B 不知道。解决办法是把关键决策显式写进共享的上下文文件，而不是依赖对话历史传递。比如接口契约写成一份api-contract.md，所有 Agent 都读它。

第二个坑：职责重叠。两个 Agent 都以为对方会处理某个边界情况，结果都没处理。解决办法是在任务拆解时明确“谁不负责什么”，边界写清楚。

第三个坑：结果冲突。两个 Agent 改了同一个文件，合并时冲突。解决办法是按文件或目录划分职责范围，尽量避免多个 Agent 碰同一片区域。

提示：多 Agent 不是越多越好。我见过有团队为了“显得先进”上了五六个 Agent，结果协调成本比省下的时间还多。两个 Agent 能搞定的事，不要上三个。

5. 并发与稳定性：Agent 跑起来之后才真正开始的问题

5.1 Agent 任务并发时，资源竞争怎么处理

当多个 Agent 同时干活，最先撞上的就是资源竞争。最常见的是文件锁冲突和外部服务限流。

文件层面，如果两个 Agent 同时改同一个文件，后写的会覆盖先写的。我的做法是在任务分配阶段就做文件级隔离，一个文件同一时间只允许一个 Agent 操作。如果确实需要多人改同一文件，就串行化，或者拆成不同的文件再合并。

外部服务层面，比如多个 Agent 同时调数据库或第三方 API，容易触发限流。解决办法是给 Agent 的调用加统一的速率控制，或者让它们走同一个代理层，由代理层统一排队。这个和传统后端的限流思路是一样的，只是调用方从人变成了 Agent。

5.2 长任务中断了怎么办：断点续跑的设计

Agent 跑长任务，中途因为网络、超时、上下文超限中断，是家常便饭。如果每次都从头再来，成本很高。

我的做法是让 Agent 把进度写到文件里。比如每完成一个子任务，就往progress.md里追加一条记录，包含已完成的部分和下一步要做什么。中断后重新启动，先读这个文件，从断点继续。

这个机制听起来简单，但效果很好。我有个重构任务，Agent 跑了四十多分钟中断了三次，靠进度文件每次都从断点续上，最终完整跑完。如果没有这个机制，三次重跑的时间成本会让人崩溃。

5.3 怎么判断 Agent 是真的卡住了还是在正常思考

这个判断很关键，因为误判会导致你过早干预或过晚发现异常。我的经验是看输出节奏：

• 正常思考：输出是断续的，有工具调用、有中间结果、有阶段性文字。
• 真卡住：长时间没有任何输出，或者反复调用同一个工具、反复读同一个文件。

遇到后者，不要干等。我的处理方式是先中断，让它汇报当前状态和卡点，再决定是调整任务还是换方案。干等十分钟和主动中断问一句，后者效率高得多。

6. 安全兜底：Agent 能自主到什么程度，红线在哪

6.1 Agent 权限分级：哪些操作必须人工确认

Agent 自主性越高，风险越大。我按操作的危险程度做了分级：

这个分级不是拍脑袋定的，是踩坑踩出来的。有次 Agent 自作主张改了一个环境配置，导致本地跑得好好的服务在测试环境起不来，排查了半天。从那以后，配置文件改动一律要人工过目。

6.2 防止 Agent 跑偏的几道防线

除了权限分级，我还会设几道防线：

第一道：约束文件里的禁止清单。前面提过，把明确不能做的事写进去。

第二道：改动范围限制。给 Agent 划定它能碰的目录范围，范围外的文件它无权修改。这个在工具层面可以配置。

第三道：提交前审查。Agent 的产出不直接合并，必须经过人工或审查 Agent 过一遍。我团队的做法是所有 Agent 产出的 PR 都必须有人 review，哪怕只是快速扫一眼。

第四道：可回滚。所有改动走版本控制，出问题能一键回退。这是最后的保险。

6.3 敏感信息处理：别让 Agent 碰到不该碰的

Agent 在自主工作时，可能会读到包含密钥、凭证、用户数据的文件。我的处理原则是：

• 敏感信息不放在代码仓库里，用环境变量或密钥管理服务，Agent 读不到。
• 给 Agent 的工作目录做隔离，只挂载它需要的那部分代码。
• 在约束文件里明确禁止 Agent 读取或输出任何凭证类内容。

这几条不是杞人忧天。Agent 的输出可能被记录、被传递，一旦敏感信息进了它的上下文，就有泄露风险。把敏感信息从源头隔离掉，比事后补救靠谱得多。

7. 从零搭一套 AI Native 工作流的落地顺序

7.1 第一周该做什么：最小可用闭环

不要一上来就搞全套。我的建议是第一周只做一件事：把 CLAUDE.md 写好，然后让 Agent 完成一个小功能，走一遍 Plan Mode 流程。

具体步骤：

1. 花两小时写约束文件，覆盖技术栈、目录结构、代码风格、测试要求、禁止事项。
2. 挑一个边界清晰的小需求，让 Agent 先出计划。
3. 你确认计划，Agent 执行。
4. 你 review 产出，把发现的问题补进约束文件。

这一周的目标不是提效，是跑通流程、建立信任、积累约束。跑完这一轮，你就知道这套东西在你们项目里大概是什么手感了。

7.2 第二到四周：把编排和并发加进来

流程跑顺之后，开始加复杂度：

• 引入多 Agent 分工，先从两个 Agent 的前后端并行开始。
• 加上进度文件机制，让长任务能断点续跑。
• 建立权限分级，把高风险操作拦下来。
• 开始积累“踩坑记录”，把每次 Agent 犯的错变成约束文件里的新规则。

这个阶段的关键是不要贪快。每加一个机制，先在小范围验证，稳定了再推广。我见过团队一次性把所有机制全上，结果出了问题不知道是哪个环节的锅。

7.3 稳定期：怎么衡量这套流程到底有没有用

跑了一两个月之后，需要一些指标来判断效果。我关注的几个：

• 人介入时间占比：一个功能从下需求到可合并，人实际花的时间占比。健康值应该在 30% 以下。
• 一次通过率：Agent 产出不需要返工直接通过 review 的比例。这个指标反映约束文件的质量。
• 返工原因分布：返工是因为方案错、代码错还是规范错。方案错多说明 Plan Mode 没用好，规范错多说明约束文件要补。

这些指标不用搞得很复杂，手工记几周就能看出趋势。关键是用数据驱动约束文件的迭代，而不是凭感觉。

8. 一些踩过坑之后才明白的事

最后分享几条我在实际推行这套范式时，踩过坑才想明白的经验。

第一条：Agent 的能力上限，取决于你给它的上下文质量，而不是模型本身。同一个模型，喂了清晰约束和没喂，产出质量差一大截。与其追新模型，不如先把约束文件打磨好。

第二条：Plan Mode 的确认环节不能省，但也不能过度。我一开始每个计划都逐字看，效率很低。后来改成只看关键决策点——涉及数据变更、并发、外部依赖的部分重点看，纯代码组织方式的部分快速扫过。找到适合自己的粒度很重要。

第三条：多 Agent 的协调成本是真实存在的。两个 Agent 协作，沟通成本不是零，是实打实的上下文传递和结果合并开销。只有当任务本身足够大、并行收益能覆盖协调成本时，多 Agent 才划算。

第四条：安全机制要在流程设计阶段就考虑，不能事后补。我最初没做权限分级，Agent 改了一个不该改的配置，排查花了很久。后来把权限分级加进流程，这类问题再没出现过。安全不是限制效率，是保护效率不被打断。

第五条：这套东西的收益是复利的。约束文件越写越全，Agent 犯的错越来越少，人介入的时间越来越短。前期投入的两三周看起来慢，但三个月后回头看，整个团队的交付节奏完全不一样了。