1. 为什么“AI Native 团队”不是把 AI 塞进旧流程1.1 从“用 AI 提效”到“以 AI 为第一性”的认知切换很多团队嘴上说着 AI Native实际干的事还是老一套产品经理写 PRD设计师出稿开发排期测试验收只不过中间某个环节加了个 Copilot 帮忙补全代码。这不叫 AI Native这叫“AI Assisted”。两者的区别就像“用计算器算账”和“用 Excel 重建整个财务模型”的区别——前者是工具替换后者是工作方式重构。我见过太多团队在转型时踩的第一个坑就是把 AI 当成一个更快的打字机。结果呢需求文档还是人写的架构还是人拍的代码 review 还是人肉逐行看AI 只在最后写代码那一步露个脸。整个 SDLC软件开发生命周期的瓶颈根本没变只是把“写代码”这个环节从 3 天压到 3 小时然后发现上游的需求澄清还是花了 5 天下游的联调还是卡了 2 天。整体交付周期从 10 天变成 9.5 天团队还累得半死。真正的 AI Native 团队核心逻辑是让 Agent 成为流程中的第一执行者人退到编排、审核和决策的位置。这不是说人不管了而是人的角色从“生产者”变成“指挥者质检员”。就像从自己开车变成指挥一支车队你得懂路况、懂调度、懂什么时候该踩刹车但不需要自己握方向盘。1.2 AI Native 团队的三个硬性标志怎么判断一个团队是不是真的 AI Native我总结下来有三个硬指标缺一个都不算第一Agent 参与需求澄清而不是只参与编码。传统流程里需求是产品经理和业务方聊出来的开发拿到的是二手信息。AI Native 团队会让 Agent 直接读原始需求会议纪要、用户反馈、竞品截图生成结构化的需求拆解和边界条件人只做确认和补充。这一步的价值在于Agent 不会“不好意思追问”它会把所有模糊点都列出来逼着团队在动手前把问题想清楚。第二代码库有机器可读的“项目宪法”。这就是 CLAUDE.md 这类文件存在的意义。它不是给人看的 README而是给 Agent 看的操作手册——项目用什么框架、目录怎么组织、命名规范是什么、哪些文件不能动、测试怎么跑。没有这个文件Agent 每次都要重新猜你的项目结构猜错了就乱改改完你还得擦屁股。有了它Agent 的产出质量能稳定提升一个档次。第三Plan Mode 成为默认工作模式。什么叫 Plan Mode就是 Agent 在动手写代码之前先输出一份执行计划要改哪些文件、每个文件改什么、为什么这么改、有什么风险。人审核通过后Agent 才进入执行。这个模式看起来多了一步实际上省掉了大量“改错了再回滚”的时间。我实测下来开启 Plan Mode 后Agent 一次通过率从 40% 左右提升到 75% 以上返工成本大幅下降。1.3 这套手册适合谁不适合谁这套落地手册适合三类人一是正在从传统研发流程向 AI Native 转型的技术负责人你需要一套可操作的框架来推动团队改变二是已经在用 Agent 但效果不稳定的开发者你需要搞清楚为什么 Agent 有时候好用有时候抽风三是想搭建自己 Agent 工作流的产品经理或独立开发者你需要知道哪些环节可以自动化、哪些必须人工介入。不适合谁如果你还在纠结“要不要用 AI 写代码”这个问题那这套手册对你来说太超前了。另外如果你的项目是强合规、强审计、每一行代码都要追溯到具体责任人的场景那 AI Native 的很多做法需要做大量适配才能用不能直接照搬。2. 核心概念拆解Agent、SDLC、Plan Mode 到底怎么配合2.1 Agent 在 SDLC 各阶段的能力边界很多人对 Agent 的期待是“全能选手”什么都能干。实际用下来Agent 在不同阶段的能力差异很大。我按 SDLC 的五个阶段来拆阶段Agent 能力人的角色注意事项需求分析能读原始材料、生成结构化需求、列出边界条件确认优先级、补充业务背景Agent 容易过度设计需要约束范围方案设计能生成技术方案、对比选型、画架构草图拍板决策、评估团队能力匹配度Agent 倾向选“最先进”而非“最合适”编码实现能写代码、写测试、跑通本地验证审核关键逻辑、处理边界情况必须开 Plan Mode否则容易跑偏代码审查能发现明显 bug、风格问题、安全隐患判断架构合理性、业务逻辑正确性Agent 对业务语义的理解有限部署运维能生成配置、写脚本、分析日志处理线上突发、做容量决策Agent 对生产环境要极度谨慎这张表的核心信息是Agent 在“有明确规则”的环节表现最好在“需要业务判断”的环节需要人兜底。编码实现之所以适合 Agent是因为代码有语法约束、有测试验证、有明确的正确性标准。需求分析之所以需要人是因为业务优先级、用户价值这些东西没有标准答案。2.2 CLAUDE.md给 Agent 的“项目宪法”怎么写CLAUDE.md 这个文件名字来源于 Claude Code 的约定但本质上它是一个通用的“Agent 上下文文件”。不管你用哪个 Agent 工具都需要这么一个文件来告诉 Agent这个项目是怎么回事。我见过很多团队的 CLAUDE.md 写得像 README全是“本项目是一个电商系统”这种废话。Agent 不需要知道你的项目是电商还是社交它需要知道的是我改代码的时候哪些事能做哪些事不能做做完了怎么验证。一份合格的 CLAUDE.md 应该包含以下内容# 项目上下文 ## 技术栈 - 语言TypeScript 5.x - 框架Next.js 14 (App Router) - 数据库PostgreSQL Prisma - 测试Vitest Playwright ## 目录结构 - src/app/页面路由每个路由一个文件夹 - src/components/可复用组件按功能分子目录 - src/lib/工具函数和业务逻辑 - src/server/服务端逻辑不能在前端引用 ## 编码规范 - 组件用函数式不用 class - 样式用 Tailwind不写独立 CSS 文件 - 所有 API 调用必须走 src/lib/api.ts 封装 - 错误处理统一用 Result 类型不抛异常 ## 禁止事项 - 不要修改 prisma/schema.prisma需要改先提 issue - 不要在 components 里直接调数据库 - 不要引入新的第三方依赖除非明确说明理由 ## 验证方式 - 改完代码跑 pnpm test 确保单测通过 - 跑 pnpm lint 确保没有风格问题 - 涉及页面的改动跑 pnpm test:e2e 验证这个文件的关键在于“禁止事项”和“验证方式”这两块。禁止事项防止 Agent 乱动核心文件验证方式让 Agent 知道自己改完对不对。我实测下来有了这个文件之后Agent 的“自作主张”行为减少了 80% 以上。2.3 Plan Mode 的正确打开方式Plan Mode 的核心逻辑是先想后做人审再执行。但很多人用 Plan Mode 的方式不对导致效果打折。常见的错误用法是让 Agent 直接输出一个“我要改 A、B、C 三个文件”的简单计划人看一眼说“行”然后 Agent 就开始写。这种 Plan Mode 形同虚设因为计划太粗人根本看不出问题。正确的用法是要求 Agent 输出可验证的执行计划每个步骤都要包含改哪个文件、改什么内容、为什么改、怎么验证改对了。比如计划 1. 修改 src/lib/auth.ts 的 validateToken 函数 - 原因当前实现没有处理 token 过期的情况 - 改动在解析 token 后增加 exp 字段检查过期则返回 null - 验证新增单测覆盖过期场景跑 pnpm test src/lib/auth.test.ts 2. 修改 src/app/api/user/route.ts 的 GET 处理 - 原因validateToken 返回值变化后调用方需要适配 - 改动增加 null 检查返回 401 而不是 500 - 验证跑 e2e 测试验证未登录访问返回 401这种粒度的计划人一眼就能看出逻辑对不对、有没有遗漏。我通常会让 Agent 先出计划我花 2 分钟审核确认没问题再让它执行。这 2 分钟的投入能省掉后面 20 分钟的调试和回滚。3. 从零搭建 AI Native 工作流的完整实操3.1 环境准备与工具选型搭建 AI Native 工作流工具选型是第一步。市面上的 Agent 工具很多LangChain、Dify、CrewAI、Claude Code、Codex 各有侧重。我的建议是不要一上来就搞多 Agent 编排先用好单 Agent 好上下文。为什么因为多 Agent 编排的复杂度是指数级上升的。两个 Agent 协作你要处理消息传递、状态同步、错误传播三个 Agent 协作你要处理优先级冲突、资源竞争、死锁。我见过太多团队在“多 Agent 协作”上耗了几个月最后发现单 Agent 加一个好的 CLAUDE.md 就能解决 80% 的问题。我的推荐配置是主力 AgentClaude Code 或 Codex用于日常编码和重构辅助 Agent用于代码审查和测试生成可以用不同的模型交叉验证上下文文件CLAUDE.md 放在项目根目录所有 Agent 共享版本控制Git 是必须的每次 Agent 改动都要能回滚工具选型的一个关键考量是Agent 能不能读到你的完整项目上下文。有些工具只能读当前文件有些能读整个仓库。能读整个仓库的 Agent在跨文件重构时优势明显。Claude Code 和 Codex 在这方面做得比较好它们会主动扫描项目结构理解文件之间的依赖关系。3.2 第一步建立项目上下文文件前面讲了 CLAUDE.md 的结构这里讲具体怎么落地。我的做法是先让 Agent 自己生成初版然后人工修正。具体操作把项目根目录打开让 Agent 扫描整个项目然后问它“请生成一份 CLAUDE.md包含技术栈、目录结构、编码规范、禁止事项、验证方式五个部分。” Agent 会输出一份初稿这份初稿通常技术栈和目录结构是对的但编码规范和禁止事项需要人工补充因为 Agent 不知道你们团队的“潜规则”。人工修正的重点是“禁止事项”。比如不要动migrations/目录下的文件不要改.env里的配置不要升级package.json里的依赖版本不要删除任何测试文件这些规则看起来琐碎但每一条都是踩过坑之后总结出来的。我印象最深的一次是Agent 觉得某个依赖版本太旧顺手升级了结果整个项目跑不起来排查了半天才发现是版本兼容问题。从那以后我就把“不要升级依赖”写进了禁止事项。3.3 第二步配置 Plan Mode 工作流Plan Mode 的配置分两步一是让 Agent 默认进入 Plan Mode二是建立“计划审核”的检查清单。让 Agent 默认进入 Plan Mode不同工具的方式不同。Claude Code 可以通过在 CLAUDE.md 里写明“所有改动前必须先输出计划”Codex 可以通过 prompt 模板来约束。核心是让 Agent 养成“先想后做”的习惯。计划审核的检查清单我总结了五个必查项改动范围是否合理Agent 有没有改不该改的文件有没有引入不必要的依赖逻辑是否自洽计划里的步骤有没有前后矛盾有没有遗漏的边界情况验证方式是否充分每个改动有没有对应的验证手段单测、e2e、手动验证回滚方案是否明确如果改错了怎么快速恢复Git commit 粒度够不够细是否有更简单的方案Agent 有没有过度设计能不能用更少的改动达到目的这五个问题过一遍通常能拦下 60% 以上的问题计划。剩下的 40%执行过程中再发现也不迟因为 Plan Mode 已经帮你把大方向把住了。3.4 第三步建立 Agent 友好的代码库Agent 的表现很大程度上取决于代码库本身的质量。一个对 Agent 友好的代码库通常有这几个特征模块边界清晰。每个模块的职责单一依赖关系明确。Agent 改一个模块的时候不需要理解整个系统。比如src/lib/auth.ts只负责认证逻辑不掺和数据库操作不掺和 HTTP 处理。这样 Agent 改认证逻辑的时候只需要看这一个文件。测试覆盖充分。测试是 Agent 的“安全网”。有测试的代码Agent 改完跑一下就知道对不对没测试的代码Agent 改完只能靠人肉 review。我建议在让 Agent 改代码之前先让它补测试。测试补完了再改逻辑改完跑测试验证。这个顺序不能反。命名规范一致。Agent 是通过模式匹配来理解代码的。如果项目里有的地方用 camelCase有的地方用 snake_caseAgent 就会困惑生成的代码风格也会飘忽不定。统一的命名规范能让 Agent 的输出更稳定。注释写“为什么”而不是“是什么”。// 增加 1这种注释对 Agent 没用// 补偿时区偏移因为数据库存的是 UTC这种注释才有用。Agent 读到这种注释就知道这段代码不能随便动动了要理解背后的原因。3.5 第四步Agent 代码审查与交叉验证Agent 写完代码不要直接合并。我的做法是用另一个 Agent 来审查第一个 Agent 的产出。具体操作Agent A 写完代码后把 diff 和 CLAUDE.md 一起给 Agent B让 Agent B 从“代码审查者”的角度找问题。Agent B 的 prompt 可以这样写你是一个严格的代码审查者。请审查以下 diff重点关注 1. 是否有逻辑错误或边界情况遗漏 2. 是否违反了 CLAUDE.md 中的禁止事项 3. 是否有安全隐患注入、越权、信息泄露 4. 测试是否充分覆盖了改动 5. 是否有更简单的实现方式 输出格式每个问题一行包含文件、行号、问题描述、建议修改。这种交叉验证的方式能发现很多单 Agent 自己发现不了的问题。因为 Agent A 在写代码的时候思维是“怎么实现”Agent B 在审查的时候思维是“哪里可能出错”。两种思维模式互补效果比单 Agent 自己检查好得多。我实测的数据是单 Agent 自己检查平均能发现 30% 的问题交叉验证后问题发现率提升到 70% 以上。当然剩下的 30% 还是需要人来看但人的负担已经大大减轻了。4. 常见问题与排查技巧实录4.1 Agent 改代码改一半卡住了怎么办这是最常见的问题。Agent 执行到一半突然报错或者停止响应留下一堆改了一半的文件。这时候不要慌按以下步骤处理第一步看 Git 状态。git status看看哪些文件被改了git diff看看改了什么。如果改动不大可以直接git checkout .回滚重新来。第二步看 Agent 的日志。大多数 Agent 工具会输出执行日志看看它卡在哪一步、报了什么错。常见原因有上下文超限、工具调用失败、遇到了无法解析的代码结构。第三步缩小任务范围。如果 Agent 是因为任务太大而卡住把任务拆小。比如“重构整个认证模块”改成“先重构 validateToken 函数跑通测试后再改下一个”。第四步补充上下文。如果 Agent 是因为缺少信息而卡住把相关文件的内容贴给它或者告诉它去看哪个文件。我踩过最坑的一次是Agent 在改一个大型配置文件时卡住了因为文件太大超出了上下文限制。后来我把配置文件拆成多个小文件Agent 就能正常处理了。这件事的教训是Agent 友好的代码库文件不要太大单个文件控制在 500 行以内比较稳妥。4.2 Agent 生成的代码“看起来对但跑不通”这种情况通常是 Agent 对项目环境理解不足导致的。比如它用了某个库的 API但版本不对或者它假设了某个环境变量存在但实际没有配置。排查思路是先跑测试再看报错最后查依赖。跑测试能快速定位问题范围。如果单测通过但 e2e 失败说明问题在集成层面如果单测就失败说明问题在逻辑层面。看报错信息重点关注“找不到模块”“类型不匹配”“未定义变量”这几类。Agent 常见的错误是引用了不存在的文件或函数因为它“以为”那个东西存在。查依赖确认 Agent 用的库版本和项目实际版本一致。Agent 的训练数据有滞后性它可能用了一个新版本的 API但你的项目还在用旧版本。预防措施是在 CLAUDE.md 里写明关键依赖的版本并且明确“不要使用未在 package.json 中声明的依赖”。4.3 Agent 不遵守 CLAUDE.md 的禁止事项这个问题我也遇到过。Agent 明明看到了“不要修改 schema.prisma”但还是改了。原因通常是禁止事项写得不够具体或者 Agent 认为修改是“必要”的。解决办法有两个一是把禁止事项写得更具体比如“不要修改 schema.prisma 中的任何 model 定义如果需要新增字段先在 issue 中讨论”二是在 Plan Mode 审核阶段就拦住如果计划里包含修改禁止文件直接打回。还有一个技巧是把禁止事项放在 CLAUDE.md 的最前面。Agent 读文件是从头读的放在前面能提高它注意到的概率。我实测下来把禁止事项前置后违规率下降了 50% 左右。4.4 常见问题速查表问题现象可能原因排查方法解决方案Agent 执行中断上下文超限/工具调用失败看日志、看 Git 状态拆小任务、补充上下文代码跑不通依赖版本不对/环境变量缺失跑测试、看报错在 CLAUDE.md 写明版本约束不遵守禁止事项规则不具体/位置太靠后检查 CLAUDE.md规则具体化、前置到文件开头改动范围过大任务描述太宽泛看 diff缩小任务范围、明确边界测试不通过逻辑错误/边界遗漏看测试报错让 Agent 先补测试再改逻辑代码风格不一致项目规范不统一看 lint 报错统一命名规范、加 lint 规则4.5 几个我踩过的坑和对应的技巧坑一让 Agent 一次性改太多文件。有一次我让 Agent “重构整个用户模块”它一口气改了 15 个文件结果引入了 3 个 bug排查了一下午。后来我改成“一次只改一个文件改完跑测试通过了再改下一个”效率反而更高。坑二没有给 Agent 足够的业务上下文。Agent 不知道“这个字段是给财务系统用的不能改类型”结果它把 int 改成了 string导致下游系统报错。后来我在 CLAUDE.md 里加了一段“业务约束”说明哪些字段有外部依赖不能随便改。坑三Agent 生成的测试“假通过”。Agent 写的测试有时候只覆盖了 happy path边界情况一个没测。后来我要求 Agent 写测试时必须包含“正常情况、边界情况、异常情况”三类并且要说明每类测试覆盖了什么场景。坑四多个 Agent 同时改同一个文件。有一次我让两个 Agent 分别改前端和后端结果它们都改了types.ts产生了冲突。后来我规定同一时间只有一个 Agent 能改共享文件其他 Agent 要改共享文件必须先等。坑五Agent 的“过度设计”倾向。Agent 倾向于用“最先进”的方案比如你让它写一个简单的缓存它可能给你搞一个 Redis 集群方案。后来我在 CLAUDE.md 里加了一条“优先选择最简单的实现除非明确要求否则不要引入新的基础设施”。5. 团队协作与流程适配5.1 代码审查流程怎么改传统代码审查是“人看人”AI Native 团队的代码审查是“Agent 初审 人终审”。具体流程Agent A 写完代码提交 PRAgent B 自动审查 PR输出问题列表Agent A 根据 Agent B 的反馈修改直到 Agent B 没有新问题人做终审重点看架构合理性和业务逻辑人审核通过后合并这个流程的关键是Agent B 的审查要自动化。可以通过 CI 集成每次 PR 提交自动触发 Agent B 审查。这样人只需要看 Agent B 的审查报告和最终 diff不需要逐行读代码。我实测下来这个流程能把人的审查时间从平均 30 分钟压缩到 10 分钟以内而且漏掉的 bug 更少。5.2 团队成员的技能要求变化AI Native 团队对成员的技能要求和传统团队有明显差异传统团队看重编码速度、算法能力、框架熟练度。AI Native 团队看重问题拆解能力、上下文组织能力、Agent 输出审核能力。具体来说你需要培养三种新技能第一写“Agent 友好”的任务描述。同样一个任务“优化登录性能”和“把登录接口的 P99 从 500ms 降到 200ms主要优化数据库查询和密码哈希计算”是两个效果。后者 Agent 能直接执行前者 Agent 只能猜。第二快速判断 Agent 输出质量。不需要逐行读代码但能快速识别“这段代码有没有大问题”。这需要你对项目架构和业务逻辑有深入理解。第三维护 CLAUDE.md 和上下文文件。这是一个持续的工作每次踩坑后都要把教训写进去让 Agent 下次不再犯同样的错误。5.3 如何衡量 AI Native 转型的效果不要用“AI 写了多少行代码”来衡量这个指标没有意义。有意义的指标是交付周期从需求确认到上线的平均时间返工率代码合并后需要回滚或热修的比例人均产出每人每月完成的 feature 数量Agent 一次通过率Agent 生成的代码不需要人工修改就能通过审查的比例我跟踪的数据是转型 3 个月后交付周期平均缩短 40%返工率下降 60%人均产出提升 2 倍左右。Agent 一次通过率从初期的 30% 提升到 70% 以上。这些数字不是终点随着 CLAUDE.md 的完善和团队熟练度的提升还有优化空间。5.4 一个真实的落地案例我参与过一个 8 人团队的 AI Native 转型从传统流程切换到 Agent 驱动流程用了大约 6 周时间。过程大致分三个阶段第 1-2 周试点。选了一个独立的小模块让 Agent 全程参与从需求拆解到编码到测试。团队观察 Agent 的表现记录问题积累经验。第 3-4 周推广。把试点经验推广到其他模块建立 CLAUDE.md配置 Plan Mode 工作流建立 Agent 交叉审查机制。这个阶段问题最多主要是 Agent 不熟悉项目规范产出质量不稳定。第 5-6 周稳定。CLAUDE.md 经过多轮迭代覆盖了大部分常见场景。团队形成了“Agent 先出计划、人审核、Agent 执行、Agent 交叉审查、人终审”的固定流程。产出质量趋于稳定。这个案例的关键经验是不要一次性全量切换先试点再推广。试点阶段暴露的问题在推广阶段就能避免。另外CLAUDE.md 的迭代是持续的过程不要指望一次写好要在实践中不断完善。6. 进阶多 Agent 编排与自动化流水线6.1 什么时候需要多 Agent单 Agent 能解决大部分问题但有些场景确实需要多 Agent需要不同视角的审查一个 Agent 写代码另一个 Agent 从安全角度审查第三个 Agent 从性能角度审查需要并行处理独立任务前端和后端同时开发互不依赖需要长流程的自动化从需求到部署的全流程自动化每个阶段一个 Agent但多 Agent 的复杂度很高我的建议是先用好单 Agent遇到单 Agent 解决不了的问题再考虑多 Agent。6.2 多 Agent 编排的三种模式串行模式Agent A 的输出作为 Agent B 的输入。适合有明确依赖关系的任务比如“先设计接口再实现接口再写测试”。并行模式多个 Agent 同时处理独立任务最后合并结果。适合前端后端同时开发、多个模块同时重构。辩论模式两个 Agent 对同一个问题给出不同方案第三个 Agent 做裁判。适合技术选型、架构决策这类需要多角度考虑的问题。我常用的是串行模式因为它的可控性最强出问题容易定位。并行模式适合任务边界非常清晰的情况否则容易出现冲突。辩论模式用得少因为成本高只在重大决策时用。6.3 自动化流水线的搭建自动化流水线的目标是从需求到部署尽可能减少人工干预。我的流水线大致是这样的需求文档提交到仓库触发 Agent A 生成需求拆解和任务列表人审核任务列表确认后触发 Agent B 生成技术方案人审核技术方案确认后触发 Agent C 编码实现Agent C 完成后触发 Agent D 代码审查Agent D 审查通过后触发 CI 跑测试测试通过后触发 Agent E 生成部署配置人确认部署上线这个流水线里人的介入点只有三个审核任务列表、审核技术方案、确认部署。其他环节都是自动的。我实测下来一个中等复杂度的 feature从需求到上线人工介入时间不超过 30 分钟。当然这个流水线不是一天建成的。我是先手动跑通每个环节确认每个 Agent 的输出质量稳定后再逐步串联起来的。一开始就追求全自动很容易因为某个环节不稳定导致整个流水线卡住。6.4 多 Agent 协作的注意事项第一共享上下文要统一。所有 Agent 都读同一个 CLAUDE.md确保对项目规范的理解一致。如果不同 Agent 读不同的上下文文件很容易产生冲突。第二消息传递要结构化。Agent 之间的消息不要用自然语言用结构化的格式JSON、YAML。自然语言容易产生歧义结构化格式更可靠。第三错误处理要明确。一个 Agent 失败了是重试、跳过还是终止整个流水线这个规则要提前定义好。我的做法是关键环节失败就终止非关键环节失败就跳过并记录。第四要有“熔断机制”。如果某个 Agent 连续失败多次自动停止流水线通知人介入。不要让它无限重试浪费资源。第五日志要完整。每个 Agent 的输入、输出、决策过程都要记录方便事后排查。我见过最坑的情况是流水线跑失败了但没有任何日志完全不知道哪个环节出了问题。7. 安全与合规的底线7.1 Agent 操作的权限控制Agent 能改代码、能跑命令、能访问文件系统这些能力如果不受控风险很大。我的做法是文件系统权限Agent 只能读写项目目录不能访问系统目录命令执行权限Agent 只能执行白名单内的命令如pnpm test、pnpm lint不能执行任意 shell 命令网络访问权限Agent 默认不能访问外网需要时手动开启Git 权限Agent 可以 commit 到 feature 分支不能直接 push 到 main 分支这些权限控制不同的 Agent 工具支持程度不同。Claude Code 和 Codex 都有比较完善的权限配置可以在配置文件里指定。7.2 敏感信息的处理Agent 在处理代码时可能会接触到敏感信息API key、数据库密码、用户数据。处理原则是敏感信息不放在代码里用环境变量或密钥管理服务CLAUDE.md 里明确标注敏感文件告诉 Agent 哪些文件不能读、不能改Agent 的输出要过滤如果 Agent 的输出里包含了敏感信息自动脱敏我踩过的一个坑是Agent 在生成测试数据时用了真实的用户邮箱结果测试数据被提交到了仓库。后来我在 CLAUDE.md 里加了一条“生成测试数据必须用 example.com 域名禁止使用真实用户数据”。7.3 代码合规检查Agent 生成的代码需要经过合规检查才能合并。检查项包括许可证合规Agent 有没有引入 GPL 等传染性许可证的依赖安全漏洞Agent 有没有引入已知漏洞的依赖版本代码规范Agent 有没有违反团队的编码规范业务合规Agent 有没有实现不符合业务规则的功能这些检查可以集成到 CI 里每次 PR 自动跑。Agent 生成的代码和人写的代码走同一套合规检查流程不搞特殊化。8. 我个人的实操体会这套 AI Native 工作流我从去年开始在自己的项目里实践也在几个团队里推广过。最大的体会是Agent 的能力上限很高但下限也很低关键在于你怎么用它。用得好Agent 能帮你把交付效率提升 2-3 倍用得不好Agent 会给你制造一堆烂摊子你还得花更多时间收拾。区别就在于有没有建立好上下文、有没有用好 Plan Mode、有没有做好交叉验证。另一个体会是不要追求“全自动”要追求“人机协同”。全自动听起来很美好但实际落地时业务判断、架构决策、风险把控这些环节人还是不可替代的。AI Native 的目标不是取代人而是让人从重复劳动中解放出来专注于真正需要人来做的事。最后分享一个小技巧每次 Agent 出错后把教训写进 CLAUDE.md。这个习惯坚持下来你的 CLAUDE.md 会越来越完善Agent 的表现也会越来越稳定。我现在的 CLAUDE.md 已经迭代了 20 多个版本覆盖了几乎所有常见的坑。新项目直接复制这份文件Agent 的初始表现就能达到 70 分以上。