1. 从“人写代码”到“人管意图”：AI Native 团队到底在变什么
“AI Native”这个词最近被喊得很响，但真正落到一个研发团队里，它到底意味着什么？我见过太多团队把 AI Native 理解成“给每个人发一个 AI 编程助手账号”，然后发现效率提升有限，甚至代码质量还下降了。问题出在：他们只换了工具，没换范式。
AI Native 团队的核心变化，不是“用 AI 写代码”，而是把 AI Agent 当作团队的一等公民来管理。传统 SDLC（软件开发生命周期）里，需求、设计、编码、测试、部署是一条人类主导的流水线；而在 AI Native 范式下，这条流水线上多了若干个“数字同事”——它们有自己的上下文、记忆、技能边界和权限范围。你的工作从“写每一行代码”变成了“定义意图、编排 Agent、审查产出”。
这个转变的难点在于：Agent 不是确定性系统。同一个 prompt 给两次，结果可能不同；上下文窗口一满，它就开始“忘事”；权限给大了会闯祸，给小了又干不了活。所以 AI Native 团队的落地手册，本质上是一套围绕不确定性做工程化管理的方法论。
这篇文章面向的是正在或准备把 Agent 引入研发流程的团队——无论你是 Tech Lead、一线工程师，还是负责搭建 AI 基础设施的平台同学。我会从范式转变讲起，拆解 SDLC 各环节的 Agent 编排方式，重点讲清楚 CLAUDE.md 这类“项目宪法”文件怎么写、Plan Mode 怎么用、多 Agent 怎么扛并发、安全边界怎么划。所有内容都来自实际项目中的踩坑和迭代，不是纸上谈兵。
2. AI Native SDLC 的四个阶段：意图、编排、执行、审查
2.1 为什么传统 SDLC 在 Agent 时代会失灵
传统 SDLC 的假设是：执行者（人）能理解模糊需求，能自我纠偏，能在遇到边界情况时做出合理判断。但 Agent 不具备这些能力——它只会严格按照你给的上下文和指令执行。你给它一个模糊的“优化一下这个接口”，它可能真的只改了个变量名。
所以 AI Native SDLC 的第一个变化是：需求必须被结构化成 Agent 可执行的意图。这不是让你写更详细的文档，而是要求你把“做什么、不做什么、验收标准是什么”用 Agent 能解析的格式表达出来。比如一个接口优化任务，在 AI Native 流程里应该被拆成：
- 输入：当前接口的 OpenAPI 定义 + 性能基线数据
- 约束：不能改变现有请求/响应结构，P99 延迟目标 < 200ms
- 验收：压测报告 + 单元测试覆盖率不低于 85%
- 禁止：不得引入新的外部依赖
这种结构化意图，才是 Agent 能可靠执行的前提。
2.2 四个阶段的职责划分与交接物
我把 AI Native SDLC 拆成四个阶段，每个阶段有明确的输入、输出和 Agent 参与方式：
| 阶段 | 人类职责 | Agent 职责 | 关键交接物 |
|---|---|---|---|
| 意图定义 | 拆解需求、设定约束、定义验收 | 辅助生成任务描述、检查遗漏 | 结构化任务卡 |
| 编排规划 | 选择 Agent 组合、设定权限 | 生成执行计划、识别依赖 | Plan 文档 |
| 执行落地 | 审查关键产出、处理异常 | 编码、测试、文档生成 | 代码变更 + 测试报告 |
| 审查验收 | 最终质量把关、合并决策 | 自动审查、回归测试 | 审查意见 + 合并记录 |
这个划分的关键在于：人类不退出流程，但角色从“执行者”变成“审查者和编排者”。你不再逐行写代码，但你要对 Agent 的产出做最终判断。这要求你比之前更懂架构和边界，而不是更少。
2.3 交接物为什么比流程更重要
在传统团队里，流程靠会议和口头沟通驱动；在 AI Native 团队里，流程靠文件化的交接物驱动。因为 Agent 没有“开会记忆”，它只能读取你给它的文件。所以每个阶段的输出必须是持久化的、结构化的、Agent 可读的。
我见过一个团队，他们的 Agent 在编码阶段总是跑偏，排查后发现：意图定义阶段的输出是一段自然语言描述，Agent 每次读取时理解都不一样。后来他们把意图定义改成 YAML 格式的任务卡，包含goal、constraints、acceptance_criteria、forbidden四个字段，Agent 的执行准确率立刻上了一个台阶。
提示：交接物的格式比内容更重要。同样的需求，用结构化格式表达，Agent 的执行稳定性会显著高于自然语言描述。
3. CLAUDE.md 与项目宪法：让 Agent 第一次就做对
3.1 CLAUDE.md 到底是什么，为什么它不是 README
CLAUDE.md 是放在项目根目录的一个 Markdown 文件，作用是告诉 AI Agent“这个项目是什么、怎么跑、有什么规矩”。很多人把它当成 README 的复制品，这是最大的误区。README 是给人看的，讲的是“这个项目能做什么”；CLAUDE.md 是给 Agent 看的，讲的是“你在这个项目里应该怎么做”。
区别体现在细节上。README 会说“运行npm install安装依赖”；CLAUDE.md 会说“安装依赖必须用pnpm install --frozen-lockfile，禁止用 npm，因为 lock 文件格式不兼容”。README 会说“测试用 jest”；CLAUDE.md 会说“测试文件必须放在__tests__目录下，命名格式为*.test.ts，禁止在源码目录里写测试”。
这些“禁止”和“必须”，才是 CLAUDE.md 的核心价值。Agent 不会自己推断团队约定，你必须显式写出来。
3.2 一份可复用的 CLAUDE.md 骨架
下面是我在实际项目中反复迭代出来的 CLAUDE.md 骨架，你可以直接拿去改：
# 项目宪法 ## 项目概述 - 技术栈：TypeScript + Node.js 20 + PostgreSQL 15 - 包管理器：pnpm（禁止使用 npm 或 yarn） - 测试框架：Vitest ## 目录约定 - 源码：`src/` - 测试：`src/**/__tests__/` - 类型定义：`src/types/` - 禁止在 `src/` 根目录下直接创建文件 ## 编码规范 - 所有导出函数必须有 JSDoc 注释 - 禁止使用 `any`，必要时用 `unknown` + 类型守卫 - 异步操作必须处理错误，禁止空 catch ## 命令 - 安装：`pnpm install --frozen-lockfile` - 测试：`pnpm test` - 类型检查：`pnpm typecheck` - 提交前必须跑通以上三个命令 ## 禁止事项 - 禁止修改 `package.json` 中的依赖版本 - 禁止删除现有测试用例 - 禁止在代码中硬编码密钥或连接字符串这份骨架的关键在于：每一条都是可验证的。Agent 执行完后，你可以用脚本检查它是否遵守了这些约定。不可验证的约定不要写，写了也没用。
3.3 项目宪法的维护节奏与常见坑
CLAUDE.md 不是写完就完了。我的经验是：每次 Agent 犯了一个“本不该犯”的错误，就往 CLAUDE.md 里加一条。比如 Agent 把测试文件写到了源码目录，你就加一条“测试文件必须放在__tests__目录下”。这样迭代几轮之后，CLAUDE.md 就变成了团队真正的“项目宪法”。
常见的坑有三个：
- 写得太长：CLAUDE.md 超过 200 行后，Agent 的遵守率会下降。因为上下文窗口有限，太长的文件会被截断或稀释注意力。建议控制在 150 行以内，超出的内容拆到子目录的 CLAUDE.md 里。
- 写得太模糊：“代码要整洁”这种话等于没写。必须写成可检查的规则，比如“函数不超过 50 行”。
- 不更新：团队约定变了但 CLAUDE.md 没变，Agent 就会按旧规则执行。建议把 CLAUDE.md 的更新纳入代码审查流程。
注意：CLAUDE.md 的优先级高于 Agent 的默认行为。如果你发现 Agent 没遵守某条规则，先检查这条规则是否写在了 CLAUDE.md 里，以及是否写得足够明确。
4. Plan Mode 实战：先想清楚再动手，省掉一半返工
4.1 Plan Mode 解决的是什么问题
Agent 最大的浪费不是写错代码，而是在错误的方向上写了很多代码。你让它“优化用户查询接口”，它可能直接重写了整个查询层，而你其实只想让它加个索引。Plan Mode 的作用就是：让 Agent 先输出执行计划，你确认后再动手。
这个机制看起来简单，但实际用起来有个关键点：Plan 的粒度要合适。太粗了（“我要优化查询”）等于没计划；太细了（“我要在第 42 行加个索引”）又失去了 Agent 自主规划的价值。我的经验是：Plan 应该细化到“文件级别 + 操作类型”，比如：
计划： 1. 修改 src/db/queries/user.ts：为 getUserById 添加索引提示 2. 修改 src/db/migrations/：新增索引迁移文件 3. 修改 src/db/queries/__tests__/user.test.ts：添加索引命中测试 4. 不修改：src/api/ 下的任何文件这个粒度让你能快速判断“方向对不对”，同时给 Agent 留了实现细节的自由。
4.2 怎么写出高质量的 Plan 提示词
Plan Mode 的效果，八成取决于你给的提示词。我总结了一个模板：
任务：{一句话描述目标} 背景：{相关文件路径 + 当前行为} 约束：{不能做什么 + 必须满足什么} 验收：{怎么判断做完了} 请先输出执行计划，不要直接修改代码。关键在“约束”和“验收”这两段。没有约束，Agent 会过度发挥；没有验收，Agent 不知道什么时候停。举个例子：
任务：为 getUserById 查询添加索引以降低 P99 延迟 背景：src/db/queries/user.ts 中的 getUserById 当前全表扫描 约束：不改变函数签名，不引入新依赖，索引名遵循 idx_{table}_{column} 格式 验收：迁移文件可执行，测试用例验证索引命中，P99 延迟目标 < 100ms 请先输出执行计划，不要直接修改代码。这个提示词给出去，Agent 的 Plan 基本不会跑偏。
4.3 Plan 审查的检查清单
拿到 Plan 之后，不要急着点“确认”。我通常会检查这几项：
- 文件范围：Plan 里涉及的文件是否都在预期范围内？有没有动不该动的文件？
- 操作类型：是新增、修改还是删除？删除操作要特别警惕。
- 依赖关系：多个步骤之间有没有顺序依赖？Agent 有没有识别出来？
- 回滚方案：如果执行失败，能不能回滚？Plan 里有没有体现？
- 验收标准：Plan 的最后一步是不是验证？有没有明确的验证命令？
这五项里，文件范围和操作类型是最容易出问题的。我遇到过 Agent 在 Plan 里写“重构 user 模块”，结果执行时删了三个它认为“冗余”的函数。从那以后，我在约束里必加一条：“禁止删除任何现有导出函数，除非明确说明理由并获得确认。”
5. 多 Agent 编排与并发：怎么让一群 Agent 不打架
5.1 单 Agent 的能力边界在哪里
先说结论：单 Agent 适合线性任务，不适合并行任务。一个 Agent 处理“改接口 + 写测试 + 更新文档”这种有先后依赖的任务没问题，但如果你让它同时处理三个独立模块的修改，它会在上下文切换中丢失细节。
我实测过一个场景：让单 Agent 同时修改三个微服务的配置文件。结果它改完第一个后，第二个的上下文已经被第一个的细节污染了，改出来的格式和第一个不一致。这不是 Agent 笨，而是它的注意力机制决定的——上下文越长，每个细节的权重越低。
所以当任务可以并行时，正确的做法是拆成多个 Agent，每个 Agent 只负责一个模块。
5.2 多 Agent 的三种编排模式
根据任务依赖关系，我常用三种编排模式：
| 模式 | 适用场景 | 实现方式 | 风险 |
|---|---|---|---|
| 流水线 | 有严格先后依赖 | Agent A 输出作为 Agent B 输入 | 上游错误会传导 |
| 并行扇出 | 任务相互独立 | 多个 Agent 同时执行，最后合并 | 合并冲突 |
| 监督者 | 需要动态决策 | 一个 Orchestrator Agent 调度多个 Worker | 调度逻辑复杂 |
流水线模式最简单，适合“设计→编码→测试”这种天然串行的流程。并行扇出适合“同时改多个独立模块”，但合并时要注意冲突。监督者模式最灵活但也最难调，适合任务边界不清晰、需要动态判断的场景。
我的建议是：从流水线开始，遇到瓶颈再升级。不要一上来就搞监督者模式，调度逻辑的复杂度会吃掉你所有的收益。
5.3 并发场景下的资源竞争与隔离
多 Agent 并发时，最大的坑是资源竞争。两个 Agent 同时修改同一个文件，后写的会覆盖先写的。解决办法有三个层次：
- 文件级隔离：给每个 Agent 分配独立的文件范围，禁止交叉。这是最简单的办法，在 Plan 阶段就划定好。
- 分支级隔离：每个 Agent 在自己的 Git 分支上工作，最后合并。适合文件范围无法完全隔离的场景。
- 锁机制：在 Agent 执行前检查文件锁，有锁则等待。这个需要平台支持，实现成本最高。
我实际用得最多的是文件级隔离。在编排阶段，我会给每个 Agent 一个明确的“文件白名单”，并在 CLAUDE.md 里写明“只能修改白名单内的文件”。这样即使 Agent 想“顺手优化”别的文件，也会被规则拦住。
提示：并发 Agent 的数量不是越多越好。我实测下来，3-5 个并发 Agent 是效率和稳定性的平衡点。超过 5 个后，合并冲突和上下文管理的开销会急剧上升。
6. Agent 安全边界：权限、沙盒与失控预防
6.1 Agent 能闯什么祸
Agent 的权限如果不受限，它能干的事包括但不限于：删除生产数据库、把密钥提交到公开仓库、给所有用户发邮件、修改计费配置。这些不是危言耸听，而是真实发生过的事故类型。
根本原因在于：Agent 没有“后果意识”。它只知道执行指令，不知道这个指令在生产环境意味着什么。所以安全边界必须由外部机制来强制，不能指望 Agent 自己判断。
6.2 三层防护：权限、沙盒、审计
我建议的安全架构分三层：
第一层：权限最小化。Agent 的凭证只授予完成任务所需的最小权限。比如一个只负责写代码的 Agent，不应该有数据库写权限，也不应该有部署权限。具体做法是给每个 Agent 角色分配独立的服务账号，权限按角色划分。
第二层：沙盒隔离。Agent 的执行环境应该是隔离的，不能直接操作生产资源。代码修改在独立分支上进行，测试在独立环境跑，部署必须经过人工审批。沙盒的粒度可以是容器级、虚拟机级或分支级，根据团队基础设施选择。
第三层：审计与回滚。Agent 的每一步操作都要有日志，包括读了哪些文件、改了哪些内容、执行了哪些命令。日志要持久化，便于事后追溯。同时要有快速回滚机制，一旦发现 Agent 闯祸，能在分钟级恢复到之前的状态。
6.3 怎么设计 Agent 的权限矩阵
权限矩阵的核心是按角色分配，而不是按 Agent 实例分配。我常用的角色划分：
| 角色 | 文件读 | 文件写 | 命令执行 | 网络访问 | 部署 |
|---|---|---|---|---|---|
| 编码 Agent | 全部 | 白名单内 | 测试命令 | 禁止 | 禁止 |
| 测试 Agent | 全部 | 测试文件 | 测试命令 | 禁止 | 禁止 |
| 文档 Agent | 全部 | 文档目录 | 禁止 | 禁止 | 禁止 |
| 审查 Agent | 全部 | 禁止 | 只读命令 | 禁止 | 禁止 |
这张表的关键是：写权限永远限定在白名单内，部署权限永远不直接给 Agent。部署必须经过人工审批，这是最后一道防线。
注意：不要给 Agent 配置长期有效的凭证。凭证应该有有效期，且绑定到具体任务。任务结束后凭证自动失效，减少泄露风险。
7. 踩坑实录：Agent 执行失败的五种典型场景与排查链路
7.1 场景一：Agent 说“完成了”，但什么都没改
这是最常见的问题。Agent 回复“已完成修改”，但你git diff一看，没有任何变更。排查链路：
- 检查 Agent 的工作目录是否正确。有时候 Agent 在错误的目录下执行，改的是另一个副本。
- 检查文件白名单是否配置正确。如果 Agent 想改的文件不在白名单内，它可能“假装”改了。
- 检查 Agent 是否有写权限。权限不足时，某些 Agent 框架会静默失败而不是报错。
- 检查是否有多个 Agent 同时操作同一文件，导致变更被覆盖。
我遇到过一次，排查了两小时才发现是工作目录配置错了。Agent 在/tmp下的一个副本里改了半天，真正的项目目录纹丝不动。从那以后，我在 Plan 阶段必加一条“确认工作目录”。
7.2 场景二：Agent 陷入循环，反复改同一个文件
Agent 改完文件后跑测试，测试失败，它又改，又失败，又改……陷入死循环。排查链路：
- 检查测试失败的原因是否在 Agent 的能力范围内。如果是环境问题（比如数据库没启动），Agent 再怎么改代码也没用。
- 检查 Agent 是否有“最大重试次数”限制。没有限制的话，它会一直试下去。
- 检查 Plan 里是否定义了“失败后的处理策略”。比如“如果测试失败超过 3 次，停止并报告”。
解决办法是在编排层加一个“熔断机制”：Agent 连续失败 N 次后自动停止，把问题上报给人类。N 的建议值是 3。
7.3 场景三：Agent 修改了不该修改的文件
Agent 在“顺手优化”的驱动下，改了白名单外的文件。排查链路：
- 检查 CLAUDE.md 里的禁止事项是否明确写了“只能修改白名单内文件”。
- 检查白名单的配置是否被 Agent 正确读取。
- 检查是否有“隐式白名单”漏洞，比如 Agent 通过符号链接绕过了限制。
预防措施是在审查阶段加一道“文件范围检查”：对比git diff --name-only和白名单，有超出就拒绝合并。
7.4 场景四：Agent 的上下文被污染，输出质量下降
长会话中，Agent 的输出越来越差，格式不一致、遗漏细节。排查链路：
- 检查会话长度是否超过了模型的上下文窗口。
- 检查是否有无关信息被塞进了上下文。
- 检查是否应该开启新会话而不是继续当前会话。
解决办法是“任务隔离”：每个独立任务开一个新会话，不要在一个会话里连续处理多个不相关的任务。如果任务确实很长，用“摘要+重启”的方式：让 Agent 总结当前进度，然后在新会话里带着摘要继续。
7.5 场景五：Agent 执行超时或卡死
Agent 执行到一半没反应了，日志也不更新。排查链路：
- 检查是否在执行某个阻塞命令（比如等待用户输入的命令）。
- 检查网络请求是否超时。
- 检查资源是否耗尽（内存、CPU）。
预防措施是给 Agent 的执行加超时限制，超时后自动终止并报告。同时避免让 Agent 执行交互式命令，所有命令都要用非交互模式。
8. 从落地到迭代：AI Native 团队的日常节奏
8.1 每日站会怎么开
AI Native 团队的站会和传统团队有个关键区别：要同步 Agent 的状态，而不只是人的状态。我通常会让每个人回答三个问题：
- 昨天你的 Agent 完成了什么？有没有异常？
- 今天你打算让 Agent 做什么？Plan 是什么？
- 有没有遇到 Agent 搞不定的问题，需要人工介入？
第三个问题最重要。Agent 搞不定的问题，往往暴露了流程或规则的缺陷，是迭代 CLAUDE.md 和编排策略的输入。
8.2 周度复盘看什么指标
我关注的指标有四个：
- Agent 任务成功率：完成且通过审查的任务占比。低于 70% 就要排查原因。
- 返工率：需要人工修改的 Agent 产出占比。高于 30% 说明意图定义或 Plan 有问题。
- 平均任务时长：从任务下发到合并的时间。用来判断编排效率。
- 安全事件数：Agent 越权或闯祸的次数。这个必须是零容忍。
这些指标不需要很精确，趋势比绝对值更重要。连续两周成功率下降，就说明流程有问题。
8.3 什么时候该升级 Agent 的能力
不是所有任务都适合交给 Agent。我判断的标准是：如果这个任务的验收标准可以自动化检查，就适合交给 Agent；如果需要人类主观判断，就不适合。
比如“写一个符合规范的 CRUD 接口”适合 Agent，因为可以用测试和 lint 检查；“设计一个高可用的架构方案”不适合，因为需要权衡和判断。随着 Agent 能力提升，这个边界会移动，但判断标准不变。
我在实际项目中的体会是：AI Native 团队的竞争力，不在于用了多强的模型，而在于把多少隐性知识显性化成了 Agent 可执行的规则。CLAUDE.md 写得越细，Plan Mode 用得越熟，Agent 的产出就越稳定。这是一个需要持续投入的工程，没有一劳永逸的配置。
最后分享一个小技巧：每次 Agent 犯错后，不要只修代码，要问一句“这个错误能不能通过规则预防”。能，就写进 CLAUDE.md；不能，就写进编排策略。坚持三个月，你会发现 Agent 的犯错率下降一个数量级。
