1. 从用AI写代码到和AI一起交付AI Native团队到底改变了什么大多数团队嘴上说着AI Native实际干的事还是老一套产品经理写PRD开发照着文档敲代码测试等提测运维等上线。区别无非是开发用Copilot补全几行函数测试让大模型帮忙写几条用例。这不叫AI Native这叫给传统流程贴了张AI的皮。真正的AI Native团队改变的不是某个环节的效率而是整个软件交付生命周期SDLC的协作拓扑结构。传统SDLC是一条流水线需求→设计→开发→测试→部署→运维每个环节是人的接力。AI Native的SDLC更像一个以Agent为执行单元、以人为编排者的网状结构——人负责定义目标、约束边界、审查关键决策Agent负责在边界内自主规划、执行、验证、迭代。这个转变带来的核心差异我用一张表说清楚维度传统AI辅助模式AI Native模式人的角色执行者AI辅助编排者审查者任务粒度函数级补全端到端任务闭环上下文载体聊天窗口项目级配置文件如CLAUDE.md规划方式人拆解任务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 ComposeCI 用 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 --tbshort - 跑单个测试文件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做还是适合人做。我的判断标准任务类型适合Agent适合人有明确规范的重复性工作是否需要跨模块协调的复杂改动否是探索性、方向不明确的任务否是有清晰Plan的执行性任务是否涉及架构决策的任务否是测试编写、文档生成是否这个划分不是绝对的但能帮你快速判断一个任务该交给谁。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.md7.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该怎么改、流程该怎么优化。