企业官网建设流程全解析

1. 从"用AI写代码"到"和AI一起交付"：AI Native团队到底改变了什么

大多数团队嘴上说着"AI Native"，实际干的事还是老一套：产品经理写PRD，开发照着文档敲代码，测试等提测，运维等上线。区别无非是开发用Copilot补全几行函数，测试让大模型帮忙写几条用例。这不叫AI Native，这叫"给传统流程贴了张AI的皮"。

真正的AI Native团队，改变的不是某个环节的效率，而是整个软件交付生命周期（SDLC）的协作拓扑结构。传统SDLC是一条流水线：需求→设计→开发→测试→部署→运维，每个环节是人的接力。AI Native的SDLC更像一个以Agent为执行单元、以人为编排者的网状结构——人负责定义目标、约束边界、审查关键决策，Agent负责在边界内自主规划、执行、验证、迭代。

这个转变带来的核心差异，我用一张表说清楚：

我见过太多团队卡在第一步：把Agent当成"更聪明的代码补全工具"，结果发现它生成的代码质量参差不齐，然后得出结论"Agent也就那样"。问题不在Agent，在于你没有给它一个AI Native的工作环境。

什么叫AI Native的工作环境？简单说就是：Agent打开项目就能理解这个项目是干什么的、代码规范是什么、哪些文件不能碰、测试怎么跑、部署流程是什么。这些信息不是靠你每次对话时手动粘贴，而是固化在项目仓库里的结构化配置文件。这就是CLAUDE.md这类文件存在的意义——它是Agent的"入职手册"，也是团队AI Native化的第一块基石。

这篇文章要聊的，就是怎么从零搭建这样一套完整的AI Native开发落地体系。从项目级配置文件的写法，到Plan Mode的正确使用姿势，到Agent的编排与安全边界，再到团队协作流程的重构。适合正在尝试把Agent引入研发流程的技术负责人、全栈工程师，以及任何想让AI真正参与交付而不只是打杂的人。

2. CLAUDE.md不是README的翻版：项目级Agent配置文件的写法与心法

2.1 为什么Agent需要一个专属的"项目说明书"

先想一个问题：你新招一个工程师入职，你会给他什么？大概率是一份 onboarding 文档，里面写着项目架构、代码规范、环境搭建步骤、常见坑、谁负责什么模块。没有这份文档，新人要花两周才能上手。

Agent面临的情况一模一样，甚至更严峻——它没有"观察学习"的能力，你不告诉它的，它就不知道。每次开新对话，它都是从零开始。CLAUDE.md的本质就是把老员工脑子里的隐性知识显性化，写成一个Agent每次启动都会读取的配置文件。

很多人把CLAUDE.md写成README的复制粘贴，这是最大的误区。README是给人看的，讲的是"这个项目是什么"；CLAUDE.md是给Agent看的，讲的是"你在这个项目里应该怎么干活"。两者的信息密度和指令性完全不同。

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

我经过多个项目的迭代，总结出一个比较稳定的结构。不是让你照抄，而是理解每个模块解决什么问题：

项目定位与架构速览。用三五句话讲清楚这个项目是做什么的、技术栈是什么、核心模块有哪些。不要长篇大论，Agent需要的是"地图"不是"游记"。比如：

## 项目概览 - 这是一个基于 Django + DRF 的后端 API 服务，为移动端提供数据接口 - 核心模块：accounts（用户）、orders（订单）、payments（支付） - 数据库：PostgreSQL 15，缓存：Redis 7 - 部署：Docker Compose，CI 用 GitHub Actions

代码规范与约定。这是减少Agent"自由发挥"的关键。你不写清楚，它就用它自己的风格，最后代码review时你气得半死。要写清楚命名规范、目录结构约定、错误处理方式、日志格式等。比如：

## 代码规范 - 所有 API 视图使用 DRF 的 ViewSet，禁止使用函数视图 - 异常统一走 custom_exception_handler，禁止在视图里裸写 try-except - 所有数据库操作必须通过 service 层，视图层不直接调 ORM - 日志使用 structlog，禁止 print 调试

常用命令速查。Agent需要知道怎么跑测试、怎么启动服务、怎么执行迁移。这些命令写清楚，它就能自主验证自己的改动：

## 常用命令 - 启动开发服务：`docker compose up -d && python manage.py runserver` - 跑测试：`pytest tests/ -x --tb=short` - 跑单个测试文件：`pytest tests/test_orders.py -v` - 数据库迁移：`python manage.py makemigrations && python manage.py migrate` - 代码检查：`ruff check . && mypy .`

禁区与红线。哪些文件不能改、哪些操作不能做、哪些依赖不能引入。这一块极其重要，是Agent安全的第一道防线：

## 禁止事项 - 禁止修改 migrations/ 目录下已存在的迁移文件 - 禁止在 settings.py 中硬编码密钥，一律走环境变量 - 禁止引入新的第三方依赖，如需引入必须先说明理由 - 禁止直接操作生产数据库

当前任务上下文。这一块是可选的，但对于正在进行的迭代很有用。可以写当前sprint的目标、正在做的feature、已知的tech debt等。

2.3 写CLAUDE.md的几个反直觉经验

第一个经验：越具体越好，越抽象越没用。"请写高质量的代码"这种话等于没说。"所有函数必须有类型注解，返回值不能是Any"这种才是有效指令。

第二个经验：用否定句划定边界比用肯定句描述期望更有效。Agent天生倾向于"多做"，你不告诉它不能做什么，它就会到处改。我一般会把"禁止事项"放在文件靠前的位置，因为Agent对开头和结尾的内容注意力更集中。

第三个经验：CLAUDE.md要跟着项目演进。每次你发现Agent犯了一个重复性的错误，就把对应的规则加进去。它本质上是一个"错误驱动的配置文件"，是团队和Agent协作过程中不断沉淀的共识。

第四个经验：不要把所有东西都塞进去。CLAUDE.md太长，Agent反而抓不住重点。我的经验是控制在200-400行之间，超过这个长度就要考虑拆分——把模块级的细节放到子目录的配置文件中，主文件只放全局规则。

提示：CLAUDE.md的命名和位置因工具而异，有的工具读CLAUDE.md，有的读.cursorrules，有的读AGENTS.md。核心思路是一样的：在项目根目录放一个Agent启动时必读的配置文件。具体文件名以你使用的工具文档为准。

3. Plan Mode：让Agent先想清楚再动手，而不是边写边错

3.1 为什么"直接让Agent写代码"是最低效的用法

我观察到一个普遍现象：大部分人用Agent的方式是——描述一个需求，然后看着它噼里啪啦生成一堆代码，跑一下发现报错，再让它改，改完又报错，来回几轮之后要么放弃要么自己上手。

这种用法的根本问题是：Agent在没有任何规划的情况下就开始执行，它的每一步决策都是局部最优，但整体可能是错的。就像你让一个施工队直接砌墙，不给他们图纸，他们砌到一半发现承重墙位置不对，只能推倒重来。

Plan Mode解决的就是这个问题。它的核心机制是：Agent先输出一份完整的执行计划，包括要改哪些文件、每个文件改什么、按什么顺序改、怎么验证，然后等人确认之后才开始执行。

3.2 Plan Mode的正确打开方式

很多人开了Plan Mode但用不好，原因是他们把Plan Mode当成"让Agent多说几句话"。不是的，Plan Mode的价值在于给你一个审查和纠偏的窗口。

我的标准流程是这样的：

第一步，给足上下文。不要只说"帮我加一个订单导出功能"，而是说清楚：这个功能给谁用、数据量大概多大、导出格式是什么、有没有性能要求、涉及哪些现有模块。上下文越充分，Plan的质量越高。

第二步，审查Plan的完整性。一份好的Plan应该包含：涉及的文件清单、每个文件的改动点、新增的依赖（如果有）、测试策略、潜在风险。如果Plan里缺了测试策略，直接打回去让它补。

第三步，重点审查"顺序"和"边界"。顺序错了会导致中间状态不可运行；边界模糊会导致Agent改到不该改的地方。比如一个涉及数据库迁移的改动，Plan里必须先改model、再生成迁移、再改service层、最后改视图，顺序不能乱。

第四步，确认后执行，但保持监控。Plan Mode不是"确认了就撒手不管"。执行过程中如果Agent遇到了Plan里没预料到的情况，它应该停下来报告，而不是自作主张。这个行为需要在CLAUDE.md里明确写出来。

3.3 Plan Mode的粒度控制：太粗和太细都是坑

Plan的粒度是个需要反复调试的参数。太粗了，比如"实现用户模块"，Agent会给你一个模糊的方向，执行时全靠临场发挥；太细了，比如把每一行代码都规划好，那你自己写得了，还要Agent干嘛。

我的经验是：Plan的粒度应该到"函数级"或"文件级"，而不是"行级"或"模块级"。也就是说，Plan应该告诉你"在orders/service.py里新增一个export_orders函数，接收日期范围和格式参数，返回文件路径"，而不是"在orders/service.py第45行插入以下代码"。

这个粒度下，你审查Plan时能判断方向对不对，Agent执行时又有足够的灵活度处理细节。

3.4 一个真实的Plan Mode踩坑记录

有一次我让Agent给一个Django项目加缓存层。Plan看起来没问题：引入Redis缓存、在service层加缓存装饰器、配置缓存过期时间。执行也顺利，测试也过了。

上线后发现一个问题：某些接口返回了过期数据。排查发现，Agent在实现缓存失效逻辑时，只处理了"更新时删缓存"的情况，没处理"批量更新时删缓存"的情况。而Plan里写的是"更新订单时清除对应缓存"，这个描述本身就有歧义——"更新"是指单条更新还是包括批量更新？

这个坑的教训是：Plan里的每个动词都要明确它的范围。"更新"、"删除"、"创建"这些词，在Plan里必须写清楚是单条还是批量、是同步还是异步、是软删除还是硬删除。这些歧义在Plan阶段不解决，执行阶段就会变成bug。

4. Agent编排：从单兵作战到流水线协作

4.1 什么时候需要多个Agent，什么时候一个就够

先说结论：大部分场景一个Agent就够了，不要为了"架构好看"而强行拆分。我见过一些团队，一个CRUD项目搞了五六个Agent，什么需求分析Agent、编码Agent、测试Agent、审查Agent，结果Agent之间的通信成本比任务本身还高。

那什么时候确实需要多Agent？我的判断标准是：当任务存在明显的阶段划分，且不同阶段需要的上下文和能力差异很大时。

典型的需要多Agent的场景：

• 代码生成与代码审查分离。生成Agent和审查Agent用不同的prompt、不同的上下文，审查Agent不参与生成过程，能保持独立性。这就像开发者和reviewer不能是同一个人。
• 探索性任务与执行性任务分离。比如先让一个Agent去调研某个技术方案的可行性，输出调研报告，再让另一个Agent基于报告做实现。
• 并行任务。比如同时给多个模块加测试，每个模块一个Agent，互不干扰。

不需要多Agent的场景：单一功能的开发、bug修复、重构、文档编写。这些任务一个Agent从头做到尾，上下文连贯，效率最高。

4.2 Agent之间的协作模式

如果确实需要多Agent，协作模式主要有三种：

串行流水线。Agent A的输出是Agent B的输入，依次传递。适合有明确阶段划分的任务。关键是要定义清楚每个阶段的交付物格式，否则下游Agent拿到一堆非结构化文本没法用。

并行分治。一个大任务拆成若干独立子任务，多个Agent并行处理，最后合并。适合模块化程度高的任务。关键是子任务之间不能有依赖，否则并行会出问题。

主从编排。一个Orchestrator Agent负责任务分解和调度，多个Worker Agent负责执行。这是最灵活但也最复杂的模式。Orchestrator需要有能力判断子任务是否完成、是否需要重试、是否要调整计划。

我个人的偏好是：能用串行就不用并行，能用单Agent就不用多Agent。每增加一个Agent，就增加一份上下文同步的成本和一份出错的可能性。

4.3 Agent的记忆管理：什么该记，什么该忘

Agent的记忆是个容易被忽视但极其重要的问题。上下文窗口是有限的，你不能把所有历史都塞进去。

我的做法是分层管理：

项目级记忆放在CLAUDE.md里，是所有Agent共享的长期知识。这部分相对稳定，不随任务变化。

任务级记忆放在当前对话的上下文里，包括任务描述、Plan、执行过程中的关键决策。这部分随任务结束而丢弃。

跨任务记忆需要显式持久化。比如"这个项目里所有日期字段都用UTC存储"这种约定，如果是在某个任务中发现的，应该回写到CLAUDE.md里，而不是留在对话历史里。

一个实用的技巧：在每个任务结束时，让Agent总结这次任务中发现的、值得沉淀到CLAUDE.md里的经验。这相当于让Agent自己维护自己的知识库。

4.4 Agent编排中的错误处理

Agent执行出错是常态，关键是怎么处理。我的原则是：区分可恢复错误和不可恢复错误。

可恢复错误：测试失败、lint报错、依赖缺失。这类错误Agent应该能自己重试或修复，不需要人工介入。

不可恢复错误：需求歧义、架构冲突、权限不足。这类错误Agent应该立即停止并报告，而不是自作主张。

在CLAUDE.md里明确写出这个区分，能大幅减少Agent"瞎折腾"的情况。比如：

## 错误处理原则 - 测试失败：自行分析原因并修复，最多重试3次 - 依赖缺失：停止执行，报告缺失的依赖和用途 - 需求不明确：停止执行，列出所有歧义点等待确认 - 涉及数据库schema变更：必须先输出变更方案，等待确认后再执行

5. Agent安全：别让"自主执行"变成"自主闯祸"

5.1 Agent安全的核心不是"防黑客"，而是"防自己"

聊Agent安全，很多人第一反应是prompt injection、越权访问这些外部攻击。但对于内部研发团队来说，最大的安全风险来自Agent自己的"过度执行"。

什么叫过度执行？举几个我亲身经历或听说的例子：

• Agent在执行"清理无用代码"任务时，删掉了一个看起来没被引用、但实际上通过反射调用的函数
• Agent在执行"优化数据库查询"任务时，擅自加了一个索引，导致写入性能下降
• Agent在执行"重构"任务时，顺手把一些它认为"不规范"的代码也改了，引入了意料之外的变更
• Agent在执行"修复测试"任务时，直接修改了测试用例让它通过，而不是修复被测试的代码

这些都不是外部攻击，而是Agent在"自主执行"名义下的越界行为。防范这类风险，靠的不是防火墙，而是清晰的边界定义和强制的确认机制。

5.2 三层防护：配置层、执行层、审查层

我的做法是建立三层防护：

配置层：在CLAUDE.md里明确列出禁区。哪些目录不能碰、哪些操作必须确认、哪些文件是只读的。这是最基础的防护，成本最低。

执行层：使用Agent工具本身的权限控制。比如限制Agent只能访问项目目录、禁止执行某些危险命令、对文件写入操作要求确认。不同工具的权限模型不一样，但核心思路是最小权限原则——Agent只拥有完成任务所需的最小权限。

审查层：所有Agent的产出在合并前必须经过人工审查。审查的重点不是代码风格（那个可以让lint工具管），而是变更的范围是否符合预期。我一般会看diff的文件列表，如果出现了Plan里没提到的文件，就要警惕。

5.3 沙箱：给Agent一个可以随便折腾的环境

Agent执行任务时，最安全的做法是在一个隔离的环境里操作。这个环境应该满足：可以随意修改文件而不影响主工作区、可以随意安装依赖而不污染全局环境、可以随意执行命令而不影响宿主机。

实现方式有很多种：容器、虚拟机、git worktree、甚至简单的文件系统快照。选择哪种取决于你的团队基础设施。核心原则是：Agent的破坏半径应该被限制在沙箱内。

我个人的做法是用git worktree。每个Agent任务开一个独立的worktree，任务完成后review diff，满意就merge，不满意就丢弃。成本低，隔离性好，而且天然有版本控制。

5.4 敏感信息处理：Agent不该看到的就别让它看到

Agent在处理任务时，可能会接触到敏感信息：API密钥、数据库密码、用户数据等。这些信息一旦进入Agent的上下文，就有可能被记录、被泄露、被误用。

我的做法是：

• 密钥一律走环境变量，不写在代码里，也不写在CLAUDE.md里
• 测试数据用脱敏数据，不用生产数据
• 敏感操作要求人工执行，比如数据库迁移、生产部署
• Agent的日志要审查，确保没有把敏感信息打印出来

这些做法其实和传统开发的安全实践是一样的，只是在Agent场景下变得更加重要——因为Agent的"记忆力"比人好，它看到的东西会一直留在上下文里。

6. 团队协作流程重构：当Agent成为团队成员之后

6.1 代码审查的重点变了

传统代码审查，reviewer关注的是：逻辑对不对、边界处理全不全、命名规不规范、有没有性能问题。Agent参与开发之后，这些依然要关注，但审查的重点要前移。

什么意思？传统模式下，代码是人写的，人的思维是连贯的，reviewer通过读代码能理解作者的意图。Agent模式下，代码是Agent按Plan生成的，reviewer更应该关注的是Plan本身是否合理，而不是逐行审查代码。

我的做法是：Plan审查花70%的精力，代码审查花30%的精力。Plan审查关注方向、边界、风险；代码审查关注实现细节、边界条件、测试覆盖。这样效率最高，也最能发挥Agent的价值。

6.2 任务分配的逻辑变了

传统模式下，任务分配考虑的是"谁擅长什么"。Agent模式下，任务分配要考虑的是"这个任务适合Agent做还是适合人做"。

我的判断标准：

这个划分不是绝对的，但能帮你快速判断一个任务该交给谁。

6.3 知识沉淀的方式变了

传统模式下，知识沉淀靠文档和代码注释。Agent模式下，知识沉淀多了一个载体：CLAUDE.md和Plan记录。

每次Agent完成一个任务，产生的Plan、执行记录、遇到的问题、解决方案，都是宝贵的知识资产。我的做法是建立一个docs/agent-logs/目录，把重要的任务记录归档进去。下次遇到类似任务时，可以直接参考。

更重要的是，从任务记录中提炼出的通用规则，要回写到CLAUDE.md里。这样知识就从"一次性"变成了"可复用"。

6.4 团队角色的演变

AI Native团队里，会出现一些新的角色或角色变化：

Agent编排者：负责设计Agent的工作流程、编写和维护CLAUDE.md、审查Plan、处理Agent无法处理的异常。这个角色需要既懂技术又懂Agent的能力边界。

上下文工程师：负责为Agent准备高质量的上下文，包括项目文档、代码规范、任务描述。这个角色有点像技术写作，但要求更高的技术理解力。

审查者：负责审查Agent的产出，重点是Plan和变更范围。这个角色需要很强的架构判断力。

这些角色不一定需要专人担任，但团队里必须有人对这些事负责。否则Agent就会变成"没人管的野马"。

7. 落地路线图：从第一个CLAUDE.md到完整的AI Native流程

7.1 第一阶段：单点突破（1-2周）

不要一上来就搞全套。先选一个边界清晰、风险低、重复性高的任务，比如"给现有模块补单元测试"或"生成API文档"。

这个阶段的目标是：让团队熟悉Agent的基本用法，建立对Agent能力的正确预期，同时产出第一版CLAUDE.md。

关键动作：

• 写第一版CLAUDE.md，包含项目概览、代码规范、常用命令、禁区
• 选一个低风险任务，用Plan Mode跑通完整流程
• 记录Agent犯的错，回写到CLAUDE.md

7.2 第二阶段：流程嵌入（2-4周）

把Agent引入到日常开发流程中。不是所有任务都用Agent，而是在适合的任务上默认用Agent。

关键动作：

• 建立Plan审查的标准流程
• 建立Agent产出的代码审查标准
• 建立任务记录的归档机制
• 开始尝试简单的多Agent协作（比如生成+审查）

7.3 第三阶段：流程重构（1-2个月）

当团队对Agent的使用比较熟练之后，开始重构整个SDLC。这时候要考虑的是：哪些环节可以完全交给Agent、哪些环节需要人机协作、哪些环节必须人来做。

关键动作：

• 重新设计任务分配逻辑
• 建立Agent的权限和沙箱体系
• 建立Agent产出的质量度量
• 培养团队里的Agent编排者

7.4 几个容易踩的坑

坑一：CLAUDE.md写得太长。我见过一个团队的CLAUDE.md有800多行，Agent根本抓不住重点。控制在400行以内，超出的拆到子目录。

坑二：Plan Mode开了但不用。开了Plan Mode但每次都直接确认，等于没开。Plan审查要真的花时间看，发现问题要打回去重做。

坑三：Agent出错就放弃。Agent出错是正常的，关键是从错误中学习。每次出错都要问：是CLAUDE.md没写清楚？是Plan有歧义？是任务本身不适合Agent？找到原因并改进。

坑四：没有沙箱。让Agent直接在主工作区操作，出了问题很难回滚。一定要用worktree或容器隔离。

坑五：把Agent当人管。Agent不是人，不能用管理人的方式管理它。它需要的是清晰的指令、明确的边界、结构化的上下文，而不是"你看着办"。

8. 一些关于Agent能力边界的个人观察

用了大半年Agent之后，我对它的能力边界有一些比较明确的判断，分享出来供参考。

Agent擅长的事：有明确规范的任务、需要大量重复的任务、需要跨文件一致性的任务、需要快速试错的任务。比如写测试、重构、迁移、生成文档、修复lint错误。

Agent不擅长的事：需要理解业务背景的决策、需要权衡多个方案的架构设计、需要和外部系统交互的调试、需要创造性思维的问题。这些事Agent能做，但做不好，或者做出来的东西需要大量修改。

Agent正在变好的事：长上下文的理解、多步骤任务的规划、对模糊需求的推断。这些能力在快速提升，今天的判断可能半年后就过时了。

我的建议是：不要用静态的眼光看Agent的能力边界。每隔一段时间重新评估一下，之前不适合Agent的任务，现在可能适合了。保持开放的心态，但也要保持对风险的警惕。

最后分享一个我一直在用的技巧：每次Agent完成一个任务，花5分钟问它三个问题——这次任务中你遇到了哪些不确定的地方？哪些信息是你希望我提前提供的？如果重来一次你会怎么做？这三个问题的答案，往往比任务本身的产出更有价值，因为它们直接告诉你CLAUDE.md该怎么改、流程该怎么优化。