1. AI Native 团队开发落地从概念到可执行手册这两年“AI Native”这个词被喊得震天响但真正落到团队日常开发里多数人还是一头雾水。我见过太多团队把 Copilot 装上了、把 Claude 接进来了结果研发效率没涨多少代码 review 反而更累了。问题出在哪出在大家把 AI Native 当成了一个工具升级问题而它本质上是一套研发范式的重构。这份手册就是我在过去一年里带着一个十几人规模的团队从零摸索出来的一套可落地、可复现的 AI Native 开发流程。它不聊虚的只讲怎么把 AI 真正嵌进 SDLC 的每一个环节怎么用 CLAUDE.md 管住上下文怎么用 Plan Mode 做前置设计怎么让 Agent 在团队协作里不添乱。适合谁看适合那些已经用过 AI 编码工具、但觉得“也就那样”的团队负责人和一线开发者也适合正准备把 AI 引入研发流程、但不知道从哪下手的技术管理者。2. 为什么是 AI Native而不是 AI Assisted2.1 两个词背后是两套完全不同的工作方式很多人分不清 AI Assisted 和 AI Native 的区别觉得不就是用 AI 写代码嘛。我举个实际场景你就明白了。AI Assisted 模式下开发者还是那个“写代码的人”AI 只是一个更聪明的自动补全。你写一个函数签名它帮你补全函数体你写一段注释它帮你生成几行代码。本质上人还是执行主体AI 是辅助工具。这种模式下效率提升是有天花板的因为瓶颈依然在人身上——你得知道要写什么你得能判断 AI 写得对不对你得手动把代码拼接到项目里。AI Native 就完全不一样了。它的核心逻辑是人负责定义问题和验收标准AI 负责执行和迭代。听起来好像只是换了个说法但实际操作中差异巨大。在 AI Native 模式下你打开编辑器的第一件事不是写代码而是写清楚“我要做什么、做到什么程度算完成、有哪些约束条件”。这些信息会被组织成结构化的上下文喂给 Agent由 Agent 去生成代码、跑测试、甚至提交 PR。人的角色从“写代码的人”变成了“定义问题的人”和“验收结果的人”。这个转变带来的直接后果是上下文的质量决定了产出的质量。你给 AI 的信息越结构化、越完整它产出的代码就越接近可用状态。反过来如果你只是丢一句“帮我写个登录功能”那出来的东西大概率没法直接用。所以 AI Native 团队的第一课不是学怎么用工具而是学怎么组织上下文。2.2 从 SDLC 的每个环节看 AI Native 的切入点传统 SDLC 分为需求、设计、开发、测试、部署、运维几个阶段。AI Native 不是要颠覆这个流程而是在每个环节里找到 AI 能真正扛事的位置。我画过一张表把我们团队实际落地的情况列了出来SDLC 阶段传统做法AI Native 做法关键工具/文件需求分析产品写 PRD开发读 PRD产品写 PRDAI 生成验收用例和边界条件CLAUDE.md 中的需求模板方案设计开发画架构图写设计文档Plan Mode 下 AI 生成多套方案人做选择Plan Mode、架构约束文件编码实现人写代码AI 补全Agent 根据上下文生成完整模块人做 reviewAgent、CLAUDE.md测试人写测试用例AI 根据需求生成测试用例人补充边界测试规范文件代码审查人 review 人AI 先做一轮静态检查和逻辑审查人做最终判断Review Agent部署运维人写脚本人排查AI 生成部署脚本AI 辅助日志分析运维知识库这张表不是理论推演是我们实际跑通了的流程。每个环节里AI 的介入程度不同但核心原则是一致的让 AI 做它擅长的生成、检查、归纳让人做只有人能做的判断、决策、担责。2.3 为什么很多团队推不动 AI Native我观察下来推不动的原因通常有三个。第一个是上下文管理没做好。团队里每个人都在用 AI但每个人喂给 AI 的上下文都不一样导致产出质量参差不齐。第二个是没有统一的规范文件。CLAUDE.md 这种文件不是随便写写就行的它需要团队一起维护把编码规范、架构约束、常见模式都沉淀进去。第三个是验收标准不清晰。AI 生成的东西什么叫“好”什么叫“不好”如果没有明确的验收标准review 就会变成扯皮。这三个问题本质上都是工程化管理缺失的问题。AI Native 不是让 AI 自由发挥而是给 AI 划好跑道让它在这个跑道里跑出最快的速度。跑道就是上下文就是规范文件就是验收标准。3. CLAUDE.mdAI Native 团队的上下文基石3.1 这个文件到底该写什么CLAUDE.md 这个名字来源于 Claude 的上下文文件约定但在 AI Native 团队里它已经演变成一个通用的项目上下文描述文件。不管你用的是 Claude、GPT 还是其他模型这个文件的逻辑是一样的用结构化的方式把项目里那些“新人来了要花一周才能搞明白”的信息一次性写清楚。我们团队的 CLAUDE.md 大概长这样我截取几个关键段落给你看# 项目上下文 ## 技术栈 - 语言TypeScript 5.x Node.js 20 - 框架NestJS Prisma - 数据库PostgreSQL 16 - 测试Jest Supertest - 部署Docker K8s ## 架构约束 - 所有 API 必须走 Controller - Service - Repository 三层 - 禁止在 Controller 里直接调用 Prisma - 所有数据库操作必须通过 Repository 层 - 错误处理统一使用自定义 AppError 类 ## 编码规范 - 函数参数超过 3 个时必须使用对象参数 - 所有异步操作必须处理错误禁止裸 await - 日志使用 winston禁止 console.log - 环境变量统一从 config 模块读取 ## 常见模式 - 分页查询统一使用 PaginationDto - 认证使用 JwtAuthGuard - 权限校验使用 RolesGuard Roles 装饰器这个文件不是写一次就完事的。我们团队的做法是每次 code review 发现一个反复出现的问题就把它补进 CLAUDE.md。比如有一次 review 发现三个人都在 Controller 里直接写了 Prisma 查询我们就把“禁止在 Controller 里直接调用 Prisma”这条加进去了。下次 AI 生成代码时就会自动避开这个坑。3.2 怎么写才能让 AI 真正读懂写 CLAUDE.md 有个误区很多人把它写成了给人看的文档用了大量自然语言描述。但 AI 读文件的方式和人不一样它更擅长处理结构化、短句、明确指令的内容。我踩过的坑是一开始写了一大段“我们团队倡导整洁架构希望大家在开发时注意分层……”结果 AI 生成代码时完全没理会。后来改成“所有 API 必须走 Controller - Service - Repository 三层”AI 立刻就遵守了。所以写 CLAUDE.md 的核心技巧是用命令式短句不用描述性长句。对比一下不好的写法“我们建议在开发过程中尽量保持代码的可测试性避免在业务逻辑中直接依赖外部服务。”好的写法“业务逻辑禁止直接依赖外部服务必须通过接口注入。”再比如不好的写法“关于错误处理团队希望大家统一使用自定义错误类这样方便排查问题。”好的写法“错误处理统一使用 AppError 类禁止直接 throw new Error。”3.3 维护 CLAUDE.md 的实操节奏我们团队维护 CLAUDE.md 的节奏是这样的每周五下午花 30 分钟做一次“上下文同步”。具体做法是把这一周 code review 里出现的所有问题过一遍挑出那些“反复出现、AI 容易犯、但人一眼能看出来”的问题补进 CLAUDE.md。这个动作看起来简单但坚持三个月后AI 生成代码的可用率从最初的 40% 左右提升到了 75% 以上。注意CLAUDE.md 不是越长越好。我们控制在 200 行以内超过这个长度AI 读取时反而会丢失重点。如果内容太多就拆成多个文件比如CLAUDE.md放核心约束CLAUDE-testing.md放测试规范CLAUDE-api.md放 API 设计规范。4. Plan Mode把设计前置到编码之前4.1 为什么需要 Plan ModePlan Mode 是 Claude 等工具提供的一种交互模式核心逻辑是在写代码之前先让 AI 生成一份实现计划人确认后再执行。这个模式看起来只是多了一步确认但实际上它解决了一个大问题AI 直接写代码时很容易跑偏。我举个例子。有一次我让 AI 实现一个“用户积分过期”的功能直接让它写代码它吭哧吭哧写了 200 行包括数据库表设计、定时任务、通知逻辑。结果我一看它把积分过期和积分扣减混在一起了而且定时任务用的是 node-cron但我们项目里统一用的是 BullMQ。如果一开始就用 Plan Mode它会先输出一份计划“1. 新增积分过期表2. 使用 BullMQ 创建定时任务3. 过期前 7 天发送通知……”我一眼就能看出问题直接让它改计划而不是等它写完 200 行再返工。4.2 Plan Mode 的实际操作流程我们团队用 Plan Mode 的流程是这样的写清楚需求不是一句话而是包含背景、目标、约束条件的完整描述。比如“我们需要实现用户积分过期功能。背景是产品要求积分在获得后 12 个月过期。约束是必须使用现有的 BullMQ 队列不能引入新的定时任务库。目标是过期前 7 天通知用户过期当天扣减积分。”让 AI 生成计划在 Plan Mode 下AI 会输出一份分步骤的实现计划包括涉及的文件、数据结构、关键逻辑。人工审查计划这一步最关键。重点看三件事有没有违反 CLAUDE.md 里的架构约束有没有引入不必要的依赖有没有遗漏边界情况确认后执行计划确认后AI 按步骤生成代码。因为计划已经对齐了生成的代码可用率会高很多。4.3 Plan Mode 的注意事项Plan Mode 不是万能的有几个坑我踩过。第一个坑是计划太粗。如果 AI 生成的计划只有“1. 创建 Service2. 创建 Controller”这种粒度那确认了也没用。解决办法是在需求描述里明确要求“请给出每个步骤涉及的具体文件、函数签名和关键逻辑。”第二个坑是计划太细。有些 AI 会把每一行代码都写进计划里那就失去了 Plan Mode 的意义。我们的做法是计划粒度控制在“函数级别”不深入到具体实现。实操心得Plan Mode 下我习惯让 AI 生成两到三套方案然后对比选择。比如实现一个功能方案 A 用继承方案 B 用组合方案 C 用策略模式。对比之后再做决定比只看一套方案要靠谱得多。5. Agent 在团队协作中的角色与边界5.1 Agent 和普通 AI 补全的区别Agent 这个词现在被用得很泛但在 AI Native 团队的语境里它特指能自主执行多步任务的 AI 实体。普通 AI 补全是你写一行它补一行Agent 是你给它一个目标它自己规划步骤、调用工具、执行操作、检查结果。比如你说“帮我把用户模块的测试覆盖率提到 80%”Agent 会自己去读代码、找没覆盖的分支、生成测试用例、跑测试、看结果、再补用例。整个过程不需要你一步步指挥。这个区别带来的影响是巨大的。普通 AI 补全的瓶颈在人身上你得知道下一步写什么。Agent 的瓶颈在任务定义的清晰度和工具链的完善度上。任务定义得越清楚工具链越完整Agent 能扛的事就越多。5.2 我们团队怎么用 Agent我们团队目前把 Agent 用在三个场景里。第一个是代码生成。给定一个模块的需求描述和 CLAUDE.mdAgent 生成完整的模块代码包括 Service、Controller、DTO、测试。第二个是代码审查。Agent 先跑一轮静态检查然后根据 CLAUDE.md 里的规范做逻辑审查输出一份审查报告。第三个是问题排查。线上出了告警Agent 去读日志、查监控、分析可能的原因给出排查建议。这三个场景里Agent 的介入程度不同。代码生成是“AI 做人验”代码审查是“AI 先做人后做”问题排查是“AI 辅助人主导”。核心原则还是那条让 AI 做它擅长的让人做只有人能做的。5.3 Agent 的边界在哪里Agent 不是万能的有些事它做不了或者做不好。我总结了几条边界涉及外部系统交互的决策比如要不要调用某个第三方 API、要不要改数据库 schema这些必须人来做。涉及业务逻辑判断的比如“这个优惠券能不能叠加使用”这种业务规则 AI 很难自己推断出来必须人明确告诉它。涉及安全敏感操作的比如删除数据、修改权限这些操作必须有人工确认环节。涉及跨团队协调的比如接口变更、依赖升级这些需要人和人沟通AI 替代不了。注意Agent 执行任务时一定要有回滚机制。我们团队的做法是Agent 生成的代码先提交到一个独立分支跑完 CI 后由人 review 再合并。Agent 执行的数据库操作必须先在一个事务里跑确认无误再提交。6. 实操从零搭建一个 AI Native 开发流程6.1 第一步建立上下文文件体系搭建 AI Native 流程的第一步不是装工具而是写文件。我们团队的文件体系是这样的CLAUDE.md核心架构约束和编码规范控制在 200 行以内。CLAUDE-testing.md测试规范包括测试框架、命名约定、覆盖率要求。CLAUDE-api.mdAPI 设计规范包括 URL 命名、请求响应格式、错误码规范。CLAUDE-deploy.md部署规范包括环境变量、构建流程、回滚流程。这些文件放在项目根目录下Agent 每次执行任务前会自动读取。写这些文件的时候有个技巧先让 AI 根据现有代码库生成一版初稿然后人工修改。具体做法是把项目里最规范的几个模块的代码喂给 AI让它总结出规范然后你再补充那些“代码里看不出来但团队约定俗成”的规则。6.2 第二步配置 Plan Mode 工作流Plan Mode 的配置不复杂但需要团队统一习惯。我们的做法是在 IDE 里配置好 Plan Mode 的快捷键比如CmdShiftP。写一个需求描述模板放在templates/requirement.md里每次写需求时直接复制。规定所有超过 50 行的代码改动必须先走 Plan Mode。需求描述模板大概长这样## 背景 [为什么要做这个功能] ## 目标 [做到什么程度算完成] ## 约束 [有哪些不能违反的规则] ## 验收标准 [怎么验证做完了]这个模板看起来简单但实际用起来效果很好。因为写模板的过程就是逼你把需求想清楚的过程。很多需求模糊的问题在写模板的时候就被发现了。6.3 第三步Agent 的接入与调优Agent 的接入分三步。第一步是选工具。我们试过几种方案最后选的是 Claude 的 Agent 模式因为它的 Plan Mode 和文件读取能力比较成熟。第二步是配工具链。Agent 需要能读代码、跑测试、查日志所以要把这些工具都接进来。第三步是调参数。Agent 的自主程度是可以调的我们一开始调得太高Agent 自己改了一堆不该改的文件后来调低了一些要求它每次操作前先确认。调优过程中最重要的指标是任务完成率和返工率。任务完成率是指 Agent 一次性能把任务做到什么程度返工率是指需要人重新修改的比例。我们团队调了两个月任务完成率从 30% 提到了 65%返工率从 50% 降到了 20% 左右。6.4 第四步建立验收和回滚机制AI Native 流程里验收和回滚机制是保底的东西。我们的做法是代码验收Agent 生成的代码必须通过 CI包括 lint、类型检查、单元测试。CI 过了之后由人做逻辑 review。数据验收Agent 执行的数据库操作必须在事务里跑确认无误再提交。涉及数据修改的必须先备份。回滚机制所有 Agent 的操作都要有回滚方案。代码回滚靠 Git数据回滚靠备份配置回滚靠版本管理。实操心得我们团队有个规矩叫“AI 做的每一件事都要有人能兜底”。意思是不管 Agent 做了什么都要有人能把它撤回来。这个规矩看起来保守但实际跑下来反而让团队更敢用 Agent因为知道有兜底。7. 常见问题与排查技巧实录7.1 Agent 生成代码跑偏了怎么办这是最常见的问题。Agent 生成的代码不符合预期通常有三个原因。第一个是上下文不够。Agent 不知道项目的架构约束所以按自己的理解写了。解决办法是把约束写进 CLAUDE.md。第二个是需求描述模糊。Agent 理解错了你的意图。解决办法是用 Plan Mode 先对齐计划。第三个是Agent 自主度过高。它自己做了太多决定。解决办法是调低自主度要求它每步确认。排查的时候我习惯先看 Agent 的“思考过程”。大多数 Agent 工具都会输出它的推理步骤看它是在哪一步跑偏的就能定位问题。7.2 多个 Agent 协作时冲突了怎么办我们团队试过多 Agent 协作一个 Agent 写代码一个 Agent 写测试一个 Agent 做审查。结果发现冲突很多比如写代码的 Agent 改了接口写测试的 Agent 不知道测试就挂了。后来我们的做法是串行执行不并行。先让写代码的 Agent 跑完确认接口稳定了再让写测试的 Agent 跑。虽然慢一点但冲突少了很多。如果一定要并行那就需要有一个协调 Agent负责维护一个共享的上下文文件所有 Agent 都从这个文件里读接口定义。但这个方案复杂度高我们试了一段时间后放弃了觉得投入产出比不划算。7.3 Agent 执行到一半报错了怎么排查Agent 执行报错常见的原因有几种。我整理了一个速查表报错类型常见原因排查方法上下文超限喂给 Agent 的文件太多精简 CLAUDE.md拆分文件工具调用失败Agent 调用的工具没配置好检查工具链配置确认权限逻辑死循环Agent 在某个步骤反复重试设置最大重试次数人工介入输出格式错误Agent 生成的代码不符合语法检查 CLAUDE.md 里的格式约束权限不足Agent 没有执行某操作的权限检查 Agent 的权限配置注意Agent 报错时不要急着重跑。先看日志定位是哪一步出的问题。很多时候问题出在上下文上重跑也没用得先把上下文修好。7.4 怎么衡量 AI Native 流程的效果衡量效果不能只看“AI 写了多少代码”那太粗了。我们团队看几个指标AI 生成代码的可用率生成后不需要大改就能用的比例。我们目前是 75% 左右。需求到上线的周期从需求确认到代码上线的平均时间。引入 AI Native 后缩短了约 30%。返工率AI 生成的代码需要人重新修改的比例。目前是 20% 左右。开发者满意度这个很主观但我们每季度会做一次匿名调查。目前满意度是 4.2/5。这些指标不是孤立的要结合起来看。比如可用率高了但返工率也高了说明 AI 生成的代码虽然能跑但质量不行需要人擦屁股。这时候就要回头去看 CLAUDE.md 是不是没写好。8. 一些踩过的坑和总结的经验8.1 不要试图让 AI 做所有事我见过一些团队恨不得把整个开发流程都交给 AI。结果就是AI 生成的东西没人能看懂出了问题没人能修。AI Native 的核心不是“AI 替代人”而是“AI 和人各干各的”。人负责定义问题、做决策、担责任AI 负责执行、生成、检查。这个分工不能乱。8.2 上下文文件要持续维护CLAUDE.md 不是写一次就完事的。我们团队每周花 30 分钟维护它三个月下来AI 生成代码的可用率翻了一倍。这个投入产出比是很高的。反过来如果写完就不管了AI 会反复犯同样的错误团队就会觉得“AI 也就那样”然后放弃。8.3 Plan Mode 要成为习惯Plan Mode 最大的价值不是让 AI 生成计划而是逼人把需求想清楚。很多需求模糊的问题在写计划的时候就被发现了。我们团队现在有个规矩不写计划不准写代码。这个规矩执行了两个月后返工率明显下降。8.4 Agent 的自主度要逐步放开一开始不要把 Agent 的自主度调太高。先让它做简单任务确认靠谱了再逐步放开。我们团队的做法是第一周只让 Agent 写测试第二周让它写简单的 Service第三周才让它写完整的模块。这个渐进的过程让团队对 Agent 建立了信任也让我们有时间调优上下文。8.5 验收标准要前置AI 生成的东西什么叫“好”必须在生成之前就定义清楚。我们的做法是在需求描述里就写清楚验收标准比如“所有 API 必须有单元测试覆盖率不低于 80%”“所有错误必须返回统一的错误码”。这样 AI 生成的时候就有目标人 review 的时候也有依据。8.6 回滚机制是底线不管 AI 多靠谱回滚机制必须有。代码回滚靠 Git数据回滚靠备份配置回滚靠版本管理。我们团队有个规矩AI 做的每一件事都要有人能兜底。这个规矩看起来保守但实际跑下来反而让团队更敢用 AI。8.7 不要忽视人的成长AI Native 流程里人的角色变了但人的能力要求反而更高了。以前你只需要会写代码现在你需要会定义问题、会写上下文、会做验收。这些能力不是天生的需要刻意练习。我们团队的做法是每周做一次“上下文 review”大家一起看 CLAUDE.md 写得对不对、需求描述写得清不清楚。这个动作看起来简单但坚持下来团队的整体能力提升很明显。8.8 工具是次要的流程是主要的我们试过很多工具Claude、Copilot、Cursor、各种 Agent 框架。最后发现工具之间的差异其实不大真正决定效果的是流程。同样的工具流程对了效果就好流程不对效果就差。所以不要花太多时间选工具花时间把流程跑通。8.9 从小处着手逐步扩展不要一上来就搞大而全的 AI Native 流程。我们是从一个模块开始试的跑通了再推广到其他模块。这个过程中我们踩了很多坑但也积累了很多经验。如果一上来就全团队推广踩坑的成本会高很多。8.10 保持耐心AI Native 不是一夜之间就能见效的。我们团队跑了三个月才看到明显的效果。前两个月效率甚至比之前还低因为要花时间写上下文、调 Agent。但第三个月开始效果就出来了。所以保持耐心不要因为短期没效果就放弃。这个内容后续还可以这样扩展比如针对不同技术栈前端、后端、移动端的 AI Native 流程差异或者针对不同团队规模小团队、大团队的落地策略。这些我们团队也在摸索中有机会再分享。