1. 从人写代码到人管意图AI Native 团队到底在变什么这两年AI Native这个词被喊得震天响但真正落到团队日常开发里绝大多数人做的其实只是给 IDE 装个补全插件。这跟 AI Native 差着十万八千里。我见过太多团队嘴上说着转型 AI Native实际工作流还是需求文档、排期、编码、联调、测试、上线那一套只不过中间某个环节塞了个对话框进去。这不叫范式转变这叫工具叠加。真正的 AI Native 团队核心变化只有一句话人负责定义意图和验收标准Agent 负责执行和迭代。听起来简单但它把整个软件开发生命周期SDLC的骨架都重构了。传统 SDLC 里人是每个环节的执行主体工具是辅助AI Native SDLC 里Agent 是执行主体人是编排者和裁判。这个主客体的调换才是所有实践差异的根源。我拿一个最直观的例子说明。传统模式下你让一个后端同学加一个用户积分过期的功能他会去翻代码、找相关表、写迁移脚本、改接口、补测试、提 PR。AI Native 模式下你给 Agent 的是一段意图描述加上验收条件比如积分在获取后 365 天未使用则失效失效前 7 天发提醒失效操作需幂等且可回溯。Agent 自己去读代码库、定位相关模块、生成迁移、改接口、写测试、跑 CI最后把 diff 和测试报告交给你。你的工作从写变成了审和定标准。这个转变带来的第一个硬性要求就是上下文必须结构化。Agent 不是人它没法靠我上次听谁说过来补全信息。你团队里那些口口相传的约定、藏在老代码注释里的坑、某个接口为什么不能改的历史原因如果不显式写下来Agent 就会一遍遍踩。这就是为什么CLAUDE.md这类文件在 AI Native 团队里地位极高——它不是文档它是 Agent 的团队记忆和行为约束。我自己的团队在转型初期吃过一个大亏。当时我们让 Agent 去重构一个订单状态机结果它把几个看起来冗余的分支删了那几个分支其实是处理历史遗留的异常订单的删完之后线上直接炸。复盘时发现代码里没有任何地方写明这几个分支不能动。从那以后我们强制要求任何非直觉的代码约束必须写进 Agent 可读的上下文文件。这条规则后来救了我们无数次。所以这一章我想先把这个认知打透AI Native 不是买几个 Agent 工具就完事它是一次工作流的重新分工。你要想清楚哪些环节交给 Agent、哪些必须人把关、上下文怎么沉淀、验收标准怎么定义。想不清楚这四件事后面所有的工具选型和流程设计都是空中楼阁。1.1 AI Native SDLC 和传统 SDLC 的分工对照我把两种模式下的环节分工拉了个表你可以对照自己团队现在处在哪个阶段环节传统 SDLC 执行主体AI Native SDLC 执行主体人的角色变化需求拆解产品 技术负责人人定义意图Agent 拆任务从写 PRD 到写验收条件方案设计架构师Agent 出方案人评审从设计到裁决编码实现工程师Agent 为主人补边界从写到审测试测试工程师Agent 生成 执行从写到定标准联调排错工程师Agent 定位人确认从查到判上线发布运维 工程师Agent 执行人审批从操作到授权复盘沉淀人写文档Agent 提炼人校准从写到校这张表最关键的一列是最后一列。你会发现人的工作全部往定义、评审、裁决、授权、校准这几个动作上收拢。这意味着 AI Native 团队对人的要求不是降低了而是要求你更懂系统、更懂边界、更能把模糊需求翻译成精确约束。一个连自己系统都说不清楚的人在 AI Native 团队里会非常痛苦因为他没法给 Agent 提供有效上下文。1.2 为什么上下文工程比提示词技巧重要十倍很多人一上来就研究怎么写提示词怎么让 Agent 更听话。方向错了。提示词是单次交互的技巧上下文工程是长期协作的基础设施。你提示词写得再花哨Agent 每次都要重新理解你的代码库、你的规范、你的历史决策那效率永远上不去。上下文工程要解决的是三件事Agent 知道什么知识、Agent 遵守什么约束、Agent 怎么验证标准。这三件事对应到文件上通常就是项目说明文件、编码规范文件、测试与验收标准文件。我建议每个 AI Native 团队都维护一个专门的目录比如.agent/里面放这些 Agent 必读的上下文并且纳入版本管理跟代码一起演进。提示上下文文件不是写完就完事的静态文档。每次 Agent 犯错、每次你发现它漏掉了某个约束都要回头把这条约束补进去。这个文件是活的它的质量直接决定 Agent 的产出质量。2. CLAUDE.md 到底该写什么一份被低估的团队契约CLAUDE.md这个文件名字来源于 Claude Code 的约定但现在它已经成了 AI Native 团队里Agent 项目说明书的代名词不管你用的是哪家工具这个思路都通用。我见过两种极端一种是完全不用Agent 每次从零开始猜另一种是写成了一本几百页的百科Agent 读都读不完反而抓不住重点。我的经验是CLAUDE.md要写得像给一个刚入职但能力很强的同事做交接。他不会问你这个项目是干嘛的这种基础问题但他需要知道项目结构、关键约定、禁区、常用命令、验收方式。写多了是噪音写少了是坑。2.1 必写模块清单我总结了一份经过多个项目验证的必写模块你可以直接照着搭项目一句话定位这个仓库是干什么的服务谁核心价值是什么。一到两句话别展开。目录结构说明哪些目录是核心业务、哪些是工具、哪些是生成物不要手改。这一条极其重要Agent 最容易在生成物目录里乱改。技术栈与版本约束语言、框架、关键依赖的版本。版本约束必须写死否则 Agent 可能给你引入一个不兼容的库版本。编码规范要点命名、分层、错误处理、日志规范。不用写全写那些违反了一定会出问题的硬约束。禁区清单哪些文件不能动、哪些接口不能改、哪些分支不能删。这是保命的。常用命令构建、测试、lint、本地启动。Agent 需要知道怎么验证自己的改动。验收标准什么样的改动算完成。测试通过覆盖率性能指标我特别想强调禁区清单。前面说的订单状态机事故就是因为没有禁区清单。后来我们在CLAUDE.md里专门开了一节叫禁止修改区域把那些历史遗留的、有特殊逻辑的、涉及合规的代码全部列进去并写明原因。Agent 读到原因后不仅不会乱改还会在必须触碰时主动提醒你。2.2 一个真实的 CLAUDE.md 片段下面是我从自己项目里脱敏出来的一个片段你可以感受一下颗粒度## 项目定位 订单履约服务负责订单从创建到完成的状态流转与异常处理。 ## 目录约定 - src/core/ 核心状态机修改需走评审 - src/adapters/ 外部系统适配层可自由扩展 - src/generated/ 代码生成产物禁止手动修改 - migrations/ 数据库迁移只增不改 ## 禁区 - src/core/legacy_branch.go 中的 handleLegacyOrder 分支 处理 2021 年前的历史订单逻辑不可简化禁止删除。 - 任何涉及金额计算的函数禁止改变舍入方式。 ## 验收标准 - 所有改动必须通过 make test - 状态机改动必须补充对应状态迁移的单元测试 - 涉及金额的改动必须附带边界用例你看这个片段没有任何废话全是 Agent 真正需要的信息。它不解释什么是状态机因为 Agent 知道它只告诉 Agent这个项目里状态机在哪、怎么改、什么不能碰。2.3 上下文文件的维护节奏很多人写完CLAUDE.md就扔那了几个月不更新结果 Agent 的行为越来越离谱。我的做法是把它跟代码同等对待每次 Agent 产出不符合预期先问一句是不是上下文没写清楚如果是立刻补进去。这个习惯坚持三个月你会发现 Agent 的返工率断崖式下降。另外上下文文件不要一个人写。让团队里最懂系统的人主笔其他人补充定期一起过一遍。因为每个人脑子里的隐性约束不一样只有碰撞出来才能写全。3. Plan Mode让 Agent 先想清楚再动手的关键机制如果你只从这篇文章里带走一个实操技巧我希望是 Plan Mode。这是我在 AI Native 实践里收益最大的一个机制没有之一。Plan Mode 的核心思想很简单在 Agent 真正修改代码之前强制它先输出一份执行计划由人确认后再执行。这听起来像是多了一道手续但它解决的是 Agent 最大的问题——它会自信地朝着错误方向狂奔。你让它加个功能它可能理解偏了然后吭哧吭哧改了一堆文件等你发现时已经面目全非。Plan Mode 把理解偏差这个风险提前暴露在计划阶段此时纠正的成本几乎为零。3.1 Plan Mode 的执行流程我团队现在的标准流程是这样的人给出意图描述要做什么附上验收条件。Agent 进入 Plan Mode只读代码不改文件输出一份计划包含它理解的需求、打算改哪些文件、每个文件改什么、怎么验证。人评审计划重点看三件事——需求理解对不对、改动范围合不合理、验证方式够不够。确认或修正计划没问题就放行有问题就指出Agent 重新出计划。Agent 执行按确认的计划改代码。人验收对照验收标准检查产出。这个流程里第 3 步是价值最高的。我经常在这一步发现 Agent 把需求理解偏了或者改动范围远超预期。有一次我让它优化查询性能它的计划里居然包含改数据库索引和重构缓存层这明显超出了我的意图。如果没有 Plan Mode它可能真就去改索引了那影响面就大了。3.2 计划评审时该盯什么评审计划不是走过场我总结了三个必看维度需求映射计划里的每个动作能不能对应到需求里的某一条对不上的动作要么是 Agent 自作主张要么是需求没写清楚。影响半径改动涉及哪些模块有没有碰到禁区跨模块改动要格外警惕。验证闭环Agent 打算怎么证明自己改对了如果它只说改完了没有验证手段这个计划不合格。注意Plan Mode 不是让你偷懒的。有些人一看计划挺长就懒得读直接放行那还不如不用。计划评审是人的核心职责这一步省不得。3.3 复杂任务的计划拆分对于大任务我建议让 Agent 把计划拆成多个可独立验证的阶段每个阶段做完就验收一次而不是一口气全做完再验。比如重构支付模块这种任务可以拆成先补测试、再抽接口、再迁移实现、最后清理旧代码。每个阶段都能独立跑通、独立回滚。这样即使某个阶段出问题也不会把整个任务拖垮。这个思路其实借鉴了传统工程里的小步快跑只不过执行者从人变成了 Agent。Agent 特别适合做这种分阶段的机械性工作但前提是你得帮它把阶段划清楚。4. Agent 编排从单打独斗到流水线协作单个 Agent 能干的活是有限的。真正让 AI Native 团队效率起飞的是多 Agent 编排——把一个大任务拆给多个各司其职的 Agent让它们像流水线一样协作。这一章我讲讲编排的实战经验包括框架选型、角色划分和踩过的坑。4.1 主流 Agent 框架的选型逻辑现在 Agent 框架多如牛毛从轻量的到重型的都有。我不打算给你列一堆名字让你自己挑而是给你一套选型逻辑你对着自己的场景套就行。选型看四个维度编排能力能不能定义多个 Agent 的协作关系是线性流水线还是可以分支、循环状态管理Agent 之间的中间结果怎么传递有没有 working memory 的概念可观测性每个 Agent 干了什么、花了多少 token、哪一步失败了能不能追踪集成成本跟你现有的代码库、CI、工具链对接难不难我的经验是别一上来就上重型框架。很多团队一转型就引入一个庞大的编排平台结果发现 80% 的功能用不上反而被框架的抽象层拖累。先用最轻的方式跑通一个真实任务遇到瓶颈再升级。我自己的团队就是从一个 Agent Plan Mode起步的跑了两个月才引入多 Agent 编排。4.2 角色划分别让 Agent 既当运动员又当裁判多 Agent 编排最容易犯的错是让同一个 Agent 既写代码又审代码。这跟让一个人自己审自己的 PR 一样不靠谱。正确的做法是角色分离规划 Agent负责理解需求、拆任务、出计划。执行 Agent负责按计划改代码。审查 Agent负责检查执行结果独立于执行 Agent。测试 Agent负责生成和运行测试。审查 Agent 和测试 Agent 的价值在于它们没有我写的代码肯定对这种偏见。我实测下来审查 Agent 能抓出执行 Agent 大概 20% 到 30% 的问题包括边界没处理、命名不一致、漏改调用方等。这个比例相当可观。4.3 并发与资源控制Agent 跑起来是要烧 token 和算力的多 Agent 并发时如果不控制成本会失控。我踩过的坑是一次让 5 个 Agent 并行处理 5 个模块结果它们互相改到了同一个公共文件产生了冲突最后还得人工合并。后来我加了两条规则一是公共资源加锁同一时间只允许一个 Agent 改公共文件二是任务粒度对齐尽量让并行任务之间没有文件重叠。这两条规则加上之后冲突率大幅下降。另外并发数不是越多越好。我实测下来3 到 5 个并发 Agent 是性价比最高的区间再多的话协调成本会吃掉并行带来的收益。5. 让 Agent 扛住真实流量并发、记忆与安全前面讲的都是开发阶段的编排。但 AI Native 团队迟早要面对一个问题Agent 本身也是要上生产的。比如你做了个客服 Agent、运营 Agent它要面对真实用户和真实流量。这时候并发、记忆、安全这三座大山就压过来了。5.1 Agent 怎么扛并发Agent 扛并发和传统服务扛并发难点不一样。传统服务是无状态的加机器就行Agent 是有状态的它带着上下文、带着记忆还有可能调用外部工具这些都会成为瓶颈。我的实践是分三层处理无状态层把 Agent 的推理逻辑尽量做成无状态的每次请求带上完整上下文这样可以水平扩展。记忆层把 working memory 外置到独立的存储里比如 Redis 或专门的向量库Agent 实例本身不持有长期状态。工具层Agent 调用的外部工具要做限流和熔断否则一个慢工具能把整个 Agent 拖死。这里有个反直觉的点Agent 的并发瓶颈往往不在模型推理而在工具调用和记忆读写。模型推理可以批处理、可以排队但工具调用是同步的记忆读写有延迟。所以优化并发时先看工具层和记忆层别一上来就想着换更快的模型。5.2 Agent 记忆的设计取舍Agent 记忆分短期和长期。短期记忆就是当前会话的上下文长期记忆是跨会话的知识沉淀。设计记忆时最大的取舍是记多少、记多久、怎么检索。记太多上下文爆炸成本和延迟都上去了记太少Agent 每次都像失忆。我的做法是分层当前会话的完整上下文保留跨会话只保留提炼后的关键事实检索时用向量相似度召回最相关的几条。这样既保证了连贯性又控制了上下文长度。提示记忆的写入要有节制。不是什么都要记只记那些下次还会用到的信息。我见过一个 Agent 把用户的每句闲聊都记下来结果记忆库膨胀得飞快检索质量还越来越差。5.3 Agent 安全的三道防线Agent 安全是个大话题我按优先级给你三道防线输入防线对用户输入做过滤和意图校验防止恶意指令注入。Agent 特别容易被忽略之前的指令这类话术带偏。权限防线Agent 能调用的工具、能访问的数据必须按最小权限原则配置。别给 Agent 一个能删库的工具除非它真的需要。输出防线Agent 的产出在对外之前要过一遍校验尤其是涉及金额、权限、敏感操作的必须有人工或规则兜底。我踩过的最惊险的一次坑是让一个 Agent 直接操作生产数据库做数据修复。幸好当时加了审批环节Agent 生成的 SQL 被拦下来人工看了一眼发现它漏了 where 条件差点全表更新。从那以后任何写操作类 Agent 都必须有审批或 dry-run 环节这条我写进了团队铁律。6. 落地路线图从一个 Agent 到一支 AI Native 团队讲了这么多机制和技巧最后我想给你一条可执行的落地路线。别想着一步到位AI Native 转型是个渐进过程我把它分成四个阶段每个阶段有明确的里程碑。6.1 四个阶段的推进节奏第一阶段单点试用。选一个低风险、高频次的开发任务比如写单元测试、补文档、做代码格式化让一个 Agent 跑起来。目标是让团队熟悉 Agent 的工作方式建立基本信任。这个阶段别碰核心业务代码。第二阶段上下文沉淀。把CLAUDE.md这类上下文文件建起来把团队约定、禁区、验收标准写进去。同时引入 Plan Mode让 Agent 先出计划再执行。这个阶段的目标是让 Agent 的产出稳定可控。第三阶段多 Agent 编排。在单 Agent 跑顺的基础上引入角色分离让规划、执行、审查、测试各司其职。这个阶段开始能处理中等复杂度的任务效率提升明显。第四阶段生产化。把 Agent 能力延伸到生产环境处理并发、记忆、安全问题。这个阶段要建立完善的监控和审批机制确保 Agent 的行为可追溯、可回滚。6.2 每个阶段的验收信号怎么判断一个阶段可以进入下一个我给你几个信号单点试用阶段Agent 在选定任务上的产出人工修改量低于 30%。上下文沉淀阶段Agent 连续一周没有因为不知道约定而犯错。多 Agent 编排阶段多 Agent 协作完成的任务返工率低于单 Agent。生产化阶段Agent 处理的生产请求异常率在可接受范围内且有完整的回滚预案。这些信号不是硬指标但能帮你判断团队是不是真的准备好了。我见过太多团队跳阶段推进结果基础没打牢后面全是坑。6.3 我踩过的三个组织层面的坑技术之外AI Native 转型最大的阻力其实来自组织。我踩过三个坑分享给你避雷第一个坑是把 Agent 当外包。有些团队觉得 Agent 就是个便宜劳动力把最脏最累的活扔给它自己不动脑子。结果 Agent 产出质量差团队又怪工具不行。Agent 是放大器你给它清晰的意图和上下文它放大你的能力你给它模糊和混乱它放大你的混乱。第二个坑是没有度量。转型了半天说不清效率到底提升了多少。我建议从第一天就记录关键指标任务完成时间、返工率、人工介入次数。有了数据你才知道哪些实践有效、哪些是自嗨。第三个坑是人的角色没转过来。有些工程师转型后还是习惯自己写代码不愿意花时间写上下文、评审计划。这其实是没理解 AI Native 的分工逻辑。在 AI Native 团队里把意图表达清楚、把标准定义清楚比亲手写代码更有价值。这个认知转变比任何工具都重要。我在实际推进过程中最大的体会是AI Native 不是一场工具革命而是一场协作方式的革命。工具会不断迭代今天好用的框架明天可能就过时了但人定义意图、Agent 执行、人验收这个协作骨架是稳定的。把精力花在打磨这个骨架上比追逐任何一个具体工具都划算。团队里那些能把模糊需求翻译成精确约束、能把隐性知识显性化的人会成为 AI Native 时代最稀缺的角色。