1. AI Native 团队到底在解决什么问题1.1 从“用AI提效”到“以AI为底座”的认知转变过去两年我参与过不少团队从零搭建 AI 辅助研发流程的尝试。大多数团队一开始的做法很朴素给每个人开个 AI 助手账号写代码时让它补全写文档时让它润色测试时让它生成用例。这种模式我称之为“AI Enhanced”——AI 是外挂是工具是锦上添花。但真正跑过几个完整迭代之后你会发现这种模式的瓶颈非常明显AI 的能力被人的工作流切碎了它只能在你主动调用的时候发挥作用而团队真正的效率损耗往往发生在“人没想到要调用 AI”的那些环节。AI Native 的核心区别就在这里。它不是“团队用 AI”而是“团队的运转方式本身就以 AI 为第一性原理来设计”。SDLC软件开发生命周期的每一个阶段——需求澄清、方案设计、编码、评审、测试、部署、运维——都要重新回答一个问题如果这个环节默认由 Agent 来执行人的角色应该是什么我见过最典型的一个反例某团队引入了代码生成 Agent但需求文档还是人写的评审还是人做的结果 Agent 生成的代码质量参差不齐因为上游的输入本身就是模糊的。这就是典型的“局部 AI 化”陷阱。AI Native 要求的是端到端的重构而不是单点替换。1.2 一个 AI Native 团队的典型画像那么一个真正跑起来的 AI Native 团队长什么样我总结下来有几个特征上下文资产化团队所有的规范、约定、架构决策、历史踩坑记录都以结构化文件的形式沉淀在代码仓库里比如CLAUDE.md、ARCHITECTURE.md、DECISIONS.md。这些文件不是给人看的文档而是给 Agent 读的“操作手册”。Plan Mode 优先任何非平凡的任务第一步不是写代码而是让 Agent 进入 Plan Mode产出可评审的执行计划。人评审计划而不是评审代码。Agent 编排而非人工调度多个 Agent 之间有明确的分工和交接协议比如一个负责需求拆解一个负责实现一个负责验证。人负责定义边界和处理异常。可观测性内建Agent 的每一次决策、每一次工具调用、每一次失败重试都有日志和追踪。没有可观测性的 Agent 系统就是黑盒黑盒在生产环境里是灾难。这套东西听起来很理想化但落地路径其实是可以拆解的。下面我会按照 SDLC 的阶段逐个讲清楚每个环节该怎么设计、怎么配置、怎么避坑。2. 上下文工程AI Native 的地基2.1 CLAUDE.md 到底该写什么CLAUDE.md这个文件在 AI Native 团队里的地位相当于传统团队里的《开发规范手册》但它的读者不是人是 Agent。这就决定了它的写法跟传统文档完全不同。传统规范手册会写“变量命名应遵循驼峰命名法”但 Agent 需要的是可执行的指令。我建议CLAUDE.md至少包含以下几类内容项目结构说明。用简洁的树形结构告诉 Agent 这个项目的目录组织逻辑哪些目录是源码哪些是测试哪些是配置文件。Agent 不需要你解释“为什么这样分”它需要知道“东西在哪”。技术栈与版本约束。明确列出项目使用的语言版本、框架版本、关键依赖。这一点极其重要因为 Agent 的训练数据里混杂着大量不同版本的信息如果你不显式约束它很可能给你生成一个已经废弃的 API 调用。编码约定。比如错误处理的方式、日志的格式、注释的语言、提交信息的规范。这些约定要写成“必须/禁止”的硬性规则而不是“建议”。常用命令。构建、测试、lint、部署的命令行。Agent 在执行任务时需要自己跑这些命令来验证结果如果它不知道命令是什么就会瞎猜。禁区。哪些文件不要动哪些操作需要人工确认哪些依赖不要引入。这一条是保命的后面讲 Agent 安全的时候会展开。我自己的经验是CLAUDE.md的篇幅控制在 200 行以内比较合适。太短了信息不够太长了 Agent 的注意力会被稀释反而抓不住重点。如果内容确实多就拆成多个文件在CLAUDE.md里用引用链接的方式组织。2.2 上下文分层从全局到局部一个常见的误区是把所有上下文都塞进一个文件。实际上AI Native 团队的上下文应该分层管理层级文件示例作用范围更新频率全局层CLAUDE.md整个仓库低模块层src/module/README.md单个模块中任务层tasks/xxx/plan.md单次任务高会话层Agent 对话历史单次会话实时全局层定义“这个项目是什么”模块层定义“这个模块怎么工作”任务层定义“这次要做什么”会话层是 Agent 的短期记忆。分层的好处是Agent 在处理具体任务时只需要加载相关的上下文而不是把整个仓库的信息都灌进去。这既节省了 token也提高了 Agent 的专注度。2.3 上下文腐化的防治上下文文件最大的敌人是腐化。项目在演进代码在变但CLAUDE.md没人维护三个月后它就变成了误导 Agent 的毒药。我踩过这个坑一个团队的技术栈从 Webpack 换到了 Vite但CLAUDE.md里还写着 Webpack 的配置说明结果 Agent 生成的构建配置全是错的排查了半天才发现是上下文文件的问题。防治腐化的办法有几个。一是把上下文文件的更新纳入 Code Review 流程任何影响项目结构或约定的改动必须同步更新对应的上下文文件。二是定期做上下文审计比如每个 Sprint 结束时花半小时检查一遍。三是让 Agent 自己参与维护在任务完成后让它检查上下文文件是否需要更新这个可以做成一个固定的 Agent Skill。3. Plan Mode把评审前移到计划阶段3.1 为什么 Plan Mode 是 AI Native 的关键传统开发流程里评审发生在代码写完之后。Code Review 的成本很高因为这时候代码已经成型改动的代价大而且评审者需要花大量时间理解代码的意图。Plan Mode 把这个顺序倒过来了先让 Agent 产出执行计划人评审计划计划通过了再让 Agent 去实现。这个转变的价值在于计划的抽象层级比代码高评审起来更快。一个中等复杂度的功能代码可能有几百行但计划可能就十几条。评审者只需要判断“这个思路对不对”“有没有遗漏的边界情况”“依赖关系是否合理”而不需要逐行看实现细节。我实测下来的数据是引入 Plan Mode 之后返工率下降了大概 40%。因为大部分返工不是因为代码写错了而是因为方向就错了。方向错误在计划阶段被发现修复成本几乎为零等到代码写完再发现那就是推倒重来。3.2 Plan Mode 的实操流程一个完整的 Plan Mode 流程大概是这样第一步任务描述。人用自然语言描述需求尽量包含背景、目标、约束条件。不要写得太简略比如“加个登录功能”这种描述Agent 只能靠猜。好的描述应该说明为什么要加登录支持哪些登录方式有没有安全要求跟现有系统的关系是什么。第二步Agent 探索。Agent 读取相关代码和上下文文件理解现状。这一步 Agent 可能会问你一些问题比如“现有的用户表结构是什么”“有没有现成的认证中间件”。认真回答这些问题它们往往暴露了需求描述里的模糊点。第三步计划产出。Agent 输出一份结构化的计划通常包括改动范围、涉及的文件、实现步骤、测试策略、风险点。我要求 Agent 的计划必须包含“我不确定的地方”这一节明确列出它没有把握的部分。这比让它假装什么都懂要诚实得多。第四步人工评审。人逐条看计划重点看三件事方向对不对、边界全不全、依赖清不清。有问题的直接批注让 Agent 修改计划。这个来回可能要进行两三轮。第五步计划冻结。计划确认后写入tasks/xxx/plan.md作为后续实现的依据。实现过程中如果发现计划需要调整也要更新这个文件保持计划和实现的一致性。3.3 Plan Mode 的常见反模式我见过几种典型的 Plan Mode 误用。一种是“计划太粗”Agent 输出的计划就三行字这种计划评审了等于没评审。另一种是“计划太细”细到每一行代码怎么写这就失去了 Plan Mode 的意义还不如直接写代码。好的计划粒度应该是“一个步骤对应一个可验证的中间状态”。还有一种反模式是“评审走过场”。人看到计划觉得“差不多”就放行了。这种态度下Plan Mode 就退化成了形式主义。评审者要真正带着怀疑的眼光去看特别是那些 Agent 说“这里应该没问题”的地方往往就是问题所在。4. Agent 编排从单兵作战到协同4.1 单 Agent 的能力边界先说清楚一个事实单个 Agent 的能力是有天花板的。这个天花板不是模型能力决定的而是上下文窗口和注意力机制决定的。当一个任务涉及的文件超过一定数量或者需要同时考虑多个维度的约束时单 Agent 的表现会急剧下降。它会开始遗忘早期的指令或者在不同约束之间顾此失彼。我做过一个实验让单 Agent 实现一个涉及 15 个文件的功能改动。结果是前 5 个文件改得不错到第 8 个文件开始出现风格不一致到第 12 个文件已经忘了最初的架构约定。这不是模型不行而是任务本身超出了单 Agent 的处理能力。4.2 多 Agent 的分工模式多 Agent 编排的核心是分工。常见的分工模式有几种按阶段分工。一个 Agent 负责需求分析一个负责设计一个负责实现一个负责测试。这种模式适合流程清晰的场景每个 Agent 的职责边界明确。缺点是交接成本高上一个 Agent 的输出要完整传递给下一个。按模块分工。每个 Agent 负责一个模块的实现最后有一个集成 Agent 负责合并。这种模式适合模块化程度高的项目并行度高。缺点是需要处理好模块间的接口约定。按角色分工。一个 Agent 扮演实现者一个扮演评审者一个扮演测试者。实现者写完代码评审者挑毛病测试者验证。这种模式的好处是有对抗性能发现单 Agent 自己发现不了的问题。我自己的实践里最常用的是“实现者 评审者”的双 Agent 模式。实现者负责写评审者负责挑刺。评审者的 prompt 里会明确要求它“假设实现者的代码有问题找出至少三个潜在缺陷”。这种对抗性设计能显著提高输出质量。4.3 Agent 之间的交接协议多 Agent 系统最容易出问题的地方是交接。Agent A 的输出传给 Agent B如果格式不统一、信息不完整B 就会基于错误的假设工作。所以交接协议必须显式定义。我通常要求 Agent 之间的交接包含以下字段任务标识这次交接对应哪个任务方便追溯。输入摘要我收到了什么我的理解是什么。输出产物我产出了什么文件路径是什么。未决问题我遇到了什么没解决的问题需要下游注意什么。置信度我对这次输出的把握有多大哪些部分我不确定。这个协议看起来繁琐但它能极大减少“传话游戏”式的信息失真。特别是“未决问题”和“置信度”这两个字段能让下游 Agent 知道该重点检查什么。4.4 Agent 并发与资源控制当多个 Agent 并行工作时资源竞争是个现实问题。我遇到过的情况包括两个 Agent 同时修改同一个文件导致冲突多个 Agent 同时调用同一个 API 触发限流Agent 数量太多导致 token 消耗失控。控制手段有几个。一是文件锁Agent 在修改文件前先申请锁避免并发写冲突。二是任务队列把任务排队执行控制并发度。三是预算控制给每个 Agent 设定 token 上限超了就暂停等人工介入。关于并发度我的经验值是同时运行的 Agent 不超过 5 个。超过这个数协调成本会超过并行带来的收益。而且人的注意力也是有限的同时盯着太多 Agent 的进展人自己就成了瓶颈。5. Agent 安全与边界控制5.1 权限最小化原则Agent 安全的第一原则是权限最小化。Agent 能做的事严格限制在它必须做的范围内。具体来说文件系统权限Agent 只能读写指定的目录不能碰系统文件和其他项目。网络权限Agent 只能访问白名单内的域名防止它把敏感信息发到外部。命令执行权限危险命令如删除、格式化、批量替换需要人工确认。依赖安装权限Agent 不能自行安装新依赖必须走人工审批。这些限制听起来很严格但都是血的教训换来的。我见过 Agent 因为一个错误的路径拼接把整个项目的配置文件覆盖了。也见过 Agent 在调试时把测试数据写到了生产数据库。这些事故的共同点是Agent 有它不该有的权限。5.2 敏感信息隔离Agent 的上下文里绝对不能出现敏感信息。API 密钥、数据库密码、用户隐私数据这些都不能让 Agent 接触到。做法是把敏感信息放在环境变量或密钥管理服务里Agent 通过引用变量名来使用而不是直接读取值。还有一个容易忽略的点是日志。Agent 的执行日志里可能包含它读到的文件内容如果这些内容里有敏感信息日志本身就成了泄露渠道。所以日志也要做脱敏处理。5.3 人工确认的触发条件哪些操作必须人工确认我整理了一个清单操作类型是否需确认理由读取文件否只读操作风险低修改已有文件视情况小改动可自动大改动需确认创建新文件否不影响现有代码删除文件是不可逆操作执行测试否安全操作执行部署是影响生产环境安装依赖是可能引入安全风险修改配置是可能影响系统行为调用外部 API视情况写操作需确认读操作可自动这个清单不是死的要根据项目的实际情况调整。核心原则是不可逆的操作、影响范围大的操作、涉及外部系统的操作都要人工确认。6. 实操落地从零搭建一个 AI Native 工作流6.1 环境准备与工具选型搭建 AI Native 工作流工具选型是第一步。我的建议是不要追求“全家桶”而是根据团队实际情况组合。核心组件包括Agent 运行时。这是执行 Agent 的平台需要支持工具调用、上下文管理、多 Agent 编排。选型时重点看它对自定义工具的支持程度以及是否提供可观测性接口。版本控制集成。Agent 的产出要能直接进入 Git 流程包括分支管理、提交、PR 创建。这块的集成质量直接影响工作流的顺畅度。任务管理集成。Agent 的任务最好能跟团队现有的任务管理系统打通这样任务的创建、分配、追踪都在一个地方。可观测性平台。Agent 的执行日志、token 消耗、成功率、失败原因都要有地方看。没有可观测性出了问题就是抓瞎。6.2 第一个 Agent 的配置实录假设我们要配置一个“代码实现 Agent”让它能接收任务描述产出代码改动。配置过程大概是这样第一步定义 Agent 的角色和边界。在配置文件里写清楚这个 Agent 负责实现功能代码不负责写测试不负责部署不负责修改配置文件。它的输入是任务描述和 Plan Mode 产出的计划输出是代码改动和实现说明。第二步配置工具集。这个 Agent 需要的工具包括读文件、写文件、搜索代码、执行测试命令、查看 Git 状态。不需要的工具一律不配减少误操作的可能。第三步注入上下文。把CLAUDE.md和相关的模块文档作为系统提示的一部分。注意上下文的加载策略不是所有任务都需要加载全部上下文按需加载能提高效率。第四步设置约束。比如单次任务修改文件不超过 10 个单次任务 token 消耗不超过 50k遇到不确定的情况必须停下来问人。第五步测试验证。用一个简单的任务跑一遍看 Agent 的表现是否符合预期。重点观察它是否遵守了约束是否在不确定时主动求助输出格式是否规范。6.3 工作流的日常运转配置好之后日常运转的流程是这样的早上人 review 昨天 Agent 的产出处理需要人工确认的事项。然后从任务队列里挑选今天的任务分配给对应的 Agent。Agent 接到任务后先进入 Plan Mode 产出计划。人在半小时内 review 计划确认或要求修改。计划确认后Agent 开始实现。实现过程中Agent 遇到不确定的地方会暂停并提问。人集中处理这些提问避免频繁打断。实现完成后Agent 自动触发测试和 lint产出结果报告。人 review 最终产出确认无误后合并。如果有问题反馈给 Agent 修改或者人工介入。这个流程的关键是“批处理”。不要 Agent 一提问就马上回答而是攒一批问题集中处理。这样人的注意力不会被频繁打断效率更高。6.4 度量与迭代AI Native 工作流不是配好就完事了需要持续度量和迭代。我关注的指标包括Agent 任务完成率多少任务是一次通过的多少需要返工。人工介入频率平均每个任务需要人介入几次。Token 消耗每个任务的 token 成本跟人工成本对比。产出质量Agent 产出的代码在后续的 bug 率如何。周期时间从任务创建到完成的平均时间。这些指标每周看一次发现异常就深入排查。比如完成率下降可能是上下文腐化了介入频率上升可能是任务描述不够清晰。7. 常见问题与排查技巧实录7.1 Agent 输出质量不稳定的排查Agent 输出质量忽好忽坏是最常见的问题。排查思路是从上往下查先查上下文。上下文文件是不是有矛盾的地方是不是有过时的信息Agent 是不是加载了不相关的上下文我遇到过一次Agent 时而用 TypeScript 时而用 JavaScript最后发现是CLAUDE.md里同时提到了两种语言的约定Agent 随机选了一个。再查任务描述。任务描述是不是有歧义是不是缺少关键约束好的任务描述应该让一个新人也能看懂要做什么。然后查工具配置。Agent 用的工具是不是最新的工具的返回格式是不是稳定工具报错时 Agent 能不能正确处理最后查模型参数。温度是不是设得太高上下文窗口是不是不够用这些参数对输出质量有直接影响。7.2 Agent 卡死或循环的应急处理Agent 卡死或者陷入循环是另一个高频问题。典型表现是 Agent 反复执行同一个操作或者在一个问题上绕来绕去。应急处理的第一步是中断。大多数 Agent 运行时都支持手动中断先停下来再说。然后看日志找到循环的起点。常见原因包括工具返回了 Agent 没预料到的格式Agent 不知道该怎么处理就反复重试或者任务本身有矛盾Agent 在两种方案之间反复横跳。处理办法是给 Agent 设置重试上限。同一个操作失败超过 3 次就停下来问人。另外在系统提示里明确告诉 Agent“如果你连续两次尝试都没有进展停下来向人求助不要继续尝试。”7.3 多 Agent 冲突的协调多 Agent 并行工作时冲突不可避免。常见的冲突类型和处理方式冲突类型表现处理方式文件写冲突两个 Agent 改同一文件文件锁 串行化依赖冲突Agent A 引入的依赖跟 Agent B 不兼容依赖变更需人工审批接口冲突Agent A 改了接口Agent B 还在用旧接口接口变更需广播通知资源冲突多个 Agent 抢同一个资源资源池 排队机制预防冲突的关键是“提前声明”。Agent 在开始任务前先声明它要改哪些文件、用哪些资源。调度器根据声明来分配避免冲突。7.4 常见问题速查表问题现象可能原因排查方向解决措施输出格式不对提示词不明确检查系统提示补充格式示例忘记约束上下文过长检查上下文长度精简上下文反复重试工具返回异常查看工具日志修复工具或加重试上限质量下降上下文腐化审计上下文文件更新过时内容Token 超支任务粒度过大分析任务复杂度拆分任务并发冲突资源未隔离检查资源分配引入锁机制安全告警权限过大审计 Agent 权限收紧权限8. 我踩过的坑和给你的建议8.1 不要一开始就追求全自动我见过太多团队一上来就想搞“全自动研发”结果摔得很惨。AI Native 的落地应该是一个渐进的过程。第一阶段先做“AI 辅助”让 Agent 帮人做一些边角料工作建立信任。第二阶段做“AI 主导人审核”Agent 负责主要工作人负责把关。第三阶段才是“AI 自治”人只在异常时介入。每个阶段至少跑一个完整的迭代周期确认稳定了再进入下一阶段。跳步的代价往往是返工。8.2 上下文质量决定一切如果只能给一条建议我会说把 80% 的精力花在上下文工程上。Agent 的能力上限是由上下文质量决定的。上下文清晰、准确、完整Agent 的表现就会好上下文模糊、过时、矛盾再强的模型也救不了。我自己的做法是每完成一个任务都花 5 分钟检查上下文文件是否需要更新。这个习惯坚持下来上下文文件始终保持新鲜Agent 的表现也就稳定。8.3 人的角色不是消失而是升级AI Native 不是要取代人而是把人从重复劳动中解放出来去做更有价值的事。在 AI Native 团队里人的核心价值体现在定义问题、设计架构、处理异常、做价值判断。这些是 Agent 做不了的。所以不要担心“被取代”要担心的是“不会用”。会用 Agent 的人效率是普通人的好几倍不会用的人会被会用的人取代。这个趋势在 AI Native 团队里尤其明显。8.4 保持怀疑持续验证Agent 的输出永远需要验证。它可能会自信地给出错误答案可能会遗漏关键约束可能会在细节上偷懒。所以验证环节不能省。我的做法是Agent 的产出必须经过至少一道自动验证测试、lint、类型检查和一道人工抽查。自动验证保证基本质量人工抽查发现深层问题。最后分享一个小技巧让 Agent 在完成任务后自己写一份“如果我错了最可能错在哪里”的分析。这个自我批判的环节往往能暴露出一些隐藏的问题。我试过几次Agent 自己指出的问题里有大概三成是真实存在的。这个比例不算低值得花这个 token。