1. 这份手册为什么值得每个开发者认真读一遍Anthropic 公开内部 AI 原生软件开发手册这件事在开发者圈子里炸开的速度比我预想得快得多。我第一时间把公开的内容翻了一遍又结合自己这大半年用 Claude Code 做项目的实际体验做了对照最大的感受是这份手册的价值不在于它教了你几个命令而在于它把AI 原生开发这件事从玄学拉回到了工程实践层面。什么叫 AI 原生开发简单说就是把 AI 编码助手当作团队里一个真实的、需要被管理的成员来对待而不是把它当成一个高级的代码补全工具。这个区别听起来像是文字游戏但实际落地的时候差别大到离谱。大多数人用 AI 写代码的方式是打开对话框描述需求复制粘贴结果遇到问题再问一轮。这种方式在写小脚本、改 bug 的时候确实够用但一旦项目规模上去、协作人数变多、代码需要长期维护就会立刻暴露出问题——AI 生成的代码风格不统一、上下文丢失、重复劳动、没人知道某段代码到底是人写的还是 AI 写的。这份手册要解决的就是这些问题。它适合所有已经在用或者准备用 AI 编码工具的开发者不管你是刚接触 Claude Code 的新手还是已经用了一段时间但总觉得差点意思的老用户。接下来我会把手册里的核心思路拆开讲同时补上我自己在实际项目中踩过的坑和总结出来的操作细节。2. AI 原生开发和传统 AI 辅助开发到底差在哪2.1 从工具到协作者的认知转变传统 AI 辅助开发的思路是我遇到一个问题去问 AIAI 给我答案我判断对错然后采用。这个流程里AI 是一个被动的查询对象主动权完全在人手里。AI 原生开发的思路是我把 AI 当成一个需要明确职责、需要提供上下文、需要设定约束的协作者。这意味着你要主动为 AI 准备它工作所需的一切信息而不是等它猜。这个转变带来的第一个实际变化就是你需要为 AI 写入职文档。就像新员工入职需要了解项目背景、代码规范、部署流程一样AI 也需要这些信息。在 Claude Code 的体系里这个入职文档就是 CLAUDE.md 文件。2.2 CLAUDE.md 不是可选项是基础设施很多人第一次看到 CLAUDE.md 这个东西的时候反应是这不就是个配置文件吗随便写写就行了。我一开始也是这么想的结果吃了大亏。当时我在一个中型项目里用 Claude Code没有认真写 CLAUDE.md导致 AI 每次生成的代码都要我手动调整命名风格、导入顺序、错误处理方式一天下来光改格式就花掉大量时间。后来我认真补了一份 CLAUDE.md把项目的技术栈、目录结构、命名约定、测试要求、常用命令全部写进去效果立竿见影。AI 生成的代码第一次就能达到可提交的水平我只需要做逻辑层面的 review不用再当格式校对员。一份合格的 CLAUDE.md 至少应该包含这些内容项目概述这个项目是做什么的核心业务逻辑是什么有哪些关键模块技术栈说明语言版本、框架版本、数据库类型、依赖管理工具目录结构约定哪个目录放什么类型的文件新文件应该放在哪里代码规范命名风格、注释要求、错误处理模式、日志规范测试要求用什么测试框架测试文件放在哪里覆盖率要求常用命令如何启动开发服务器、如何跑测试、如何构建、如何部署禁止事项哪些操作绝对不能做比如不能直接改某个核心文件、不能引入新的依赖等提示CLAUDE.md 不是写一次就完事的它应该随着项目演进持续更新。我现在的习惯是每次项目结构有变动第一件事就是更新 CLAUDE.md然后再让 AI 参与后续开发。2.3 上下文管理是 AI 原生开发的核心技能传统开发里上下文切换的成本主要在人身上。AI 原生开发里上下文管理的对象变成了 AI。Claude Code 这类工具的工作方式是它在一次会话里能记住的内容是有限的超出窗口的内容会被截断或压缩。如果你在一个超长会话里让 AI 处理一个复杂任务它很可能会忘记前面说过的约束。我的做法是把大任务拆成小任务每个任务单独开一个会话并且在会话开始时把相关的 CLAUDE.md 内容和当前任务的具体要求一起提供给 AI。这样虽然看起来多了一些手动操作但 AI 的输出质量会稳定很多。另外一个技巧是在会话进行到一半的时候主动让 AI 总结一下当前的状态和待办事项然后把这个总结作为新会话的起点。这样可以在不丢失关键信息的前提下重置上下文窗口。3. 把 AI 编码助手接进 CI/CD 流水线的具体做法3.1 为什么要把 AI 和 CI/CD 绑在一起CI/CD 流水线的核心价值是自动化验证。代码提交之后自动跑测试、自动检查代码风格、自动构建、自动部署。把 AI 编码助手接进这个流程意味着 AI 生成的代码也要经过同样的质量门禁。这听起来是理所当然的事情但实际操作中很多人会忽略这一点——他们让 AI 直接生成代码然后手动提交跳过了自动化检查环节。我现在的做法是AI 生成的代码必须先通过本地测试然后提交到分支触发 CI 流水线流水线跑通之后才允许合并。如果流水线挂了我会把报错信息直接贴给 AI让它自己修。这个循环跑几轮之后AI 生成的代码质量会明显提升因为它能从报错中学习到项目的实际约束。3.2 在 GitLab CI 里集成 AI 代码检查GitLab CI 是目前用得比较多的持续集成方案它的配置文件是.gitlab-ci.yml。下面是一个我实际在用的配置片段作用是每次提交时自动跑测试和代码风格检查stages: - test - lint - build run-tests: stage: test script: - npm install - npm run test only: - merge_requests - main lint-check: stage: lint script: - npm run lint allow_failure: false build-app: stage: build script: - npm run build artifacts: paths: - dist/这个配置本身不涉及 AI但它的意义在于它为 AI 生成的代码设定了一个明确的验收标准。你可以在 CLAUDE.md 里写明所有提交必须通过 lint-check 和 run-tests这样 AI 在生成代码的时候就会主动考虑这些约束。3.3 Docker 环境下的 CI/CD 注意事项如果你的 CI/CD 跑在 Docker 容器里有几个细节需要特别注意。首先是基础镜像的选择建议用官方提供的语言运行时镜像不要用过于精简的版本否则可能会缺少 AI 工具需要的依赖。其次是缓存策略Docker 层的缓存如果配置不当会导致每次构建都重新下载依赖拖慢整个流水线。我在一个项目里遇到过这样的情况CI 流水线每次跑都要花十几分钟排查之后发现是 Docker 缓存没有正确挂载。后来在.gitlab-ci.yml里加了缓存配置构建时间直接降到了三分钟以内。具体的配置思路是把node_modules或者对应的依赖目录挂载为缓存卷这样依赖没有变化的时候就不需要重新安装。注意Docker 环境里的网络配置和权限设置需要提前确认好否则 AI 工具在容器里可能无法正常访问外部服务。这个问题在本地开发时不容易发现一到 CI 环境就会暴露。4. Claude Code 从安装到跑通第一个任务的完整路径4.1 安装前的环境确认Claude Code 的安装本身不复杂但环境准备阶段有几个容易忽略的点。首先确认你的操作系统版本macOS 和 Windows 的安装方式略有不同。其次确认 Node.js 的版本Claude Code 对 Node 版本有最低要求版本太低会直接报错。在 Ubuntu 上安装的话基本流程是先确保 Node.js 和 npm 是最新的稳定版然后通过 npm 全局安装 Claude Code 的命令行工具。安装完成之后第一次运行会引导你完成认证配置。Windows 用户建议在 WSL 环境下操作原生 Windows 环境的兼容性虽然一直在改善但 WSL 下的体验明显更顺畅。安装完成之后建议先跑一个最简单的任务验证环境是否正常比如让 Claude Code 读取当前目录下的文件列表或者生成一个简单的 Hello World 脚本。这一步的目的是确认工具能正常访问文件系统、能正常调用模型、能正常输出结果。4.2 在 VS Code 里配置 Claude CodeVS Code 是大多数开发者日常使用的编辑器把 Claude Code 集成进去能省掉不少切换窗口的时间。配置方式一般是在 VS Code 的扩展市场里搜索对应的插件安装之后在设置里填入必要的配置项。配置完成之后你可以在 VS Code 里直接打开 Claude Code 的对话面板让它读取当前打开的文件、分析选中的代码片段、生成新的代码文件。这个体验比在终端里操作要直观很多尤其是在处理多个文件关联修改的时候。我自己的使用习惯是简单的单文件修改直接在终端里用 Claude Code 命令行完成涉及多文件重构或者需要看代码上下文的时候切到 VS Code 插件里操作。两种方式配合使用效率比只用一种要高。4.3 第一次让 Claude Code 干活的正确姿势很多人第一次用 Claude Code 的时候会直接扔一个很大的需求过去比如帮我实现一个用户管理系统。这种用法大概率会得到一堆看起来能用但实际上跑不起来的代码。正确的做法是从小任务开始逐步建立信任。我的建议是第一次任务选择这样的类型修改一个已有函数的实现、给一个现有模块添加一个小的功能点、修复一个明确的 bug。这类任务的特点是边界清晰、验证简单、不需要太多上下文。跑通几个小任务之后你对工具的能力边界会有更准确的判断再逐步加大任务复杂度。每次任务开始之前确保 CLAUDE.md 文件在项目根目录下并且内容是最新的。任务描述要具体包含输入、输出、约束条件。任务完成之后不要直接提交先自己 review 一遍跑一下测试确认没有问题再进入下一步。5. 那些手册里没写但实际会踩的坑5.1 模型路由和网关配置的常见报错在实际部署 Claude Code 的过程中我遇到过好几次和模型路由相关的报错。典型的表现是工具启动之后无法正常调用模型日志里会出现类似expected a gateway model route这样的提示。这个问题的根源通常是网关配置和实际使用的模型标识不匹配。排查思路是这样的先确认你配置的模型名称和网关支持的模型列表是否一致然后检查网络连接是否正常最后确认认证信息是否有效。这三个环节任何一个出问题都会导致调用失败。我的经验是把配置信息集中管理不要散落在多个文件里这样排查的时候只需要看一个地方。5.2 权限配置过松或过紧都会出问题Claude Code 在执行操作的时候需要一定的文件系统权限和命令执行权限。权限给得太紧AI 无法读取项目文件、无法运行测试命令基本干不了活。权限给得太松AI 可能会修改不该修改的文件、执行有风险的操作。我的做法是采用最小权限原则只开放当前任务必需的权限。比如让 AI 修改某个模块的代码就只开放那个模块目录的读写权限不要开放整个项目的写权限。需要 AI 跑测试的时候单独授权测试命令的执行权限不要开放所有命令的执行权限。5.3 会话中断和状态丢失的应对长时间运行的会话可能会因为各种原因中断比如网络波动、工具超时、手动关闭等。中断之后重新打开之前的上下文可能已经丢失了。这个问题在复杂任务中特别让人头疼因为重新建立上下文需要花不少时间。我的应对策略是在会话进行到关键节点的时候让 AI 输出一份当前状态的总结包括已完成的工作、待完成的工作、已知的问题。把这份总结保存下来会话中断之后直接用它作为新会话的起点。这个习惯看起来麻烦但实际节省的时间远超预期。另外一个技巧是把大任务拆成多个小任务每个小任务单独开一个会话。这样即使某个会话中断影响范围也有限不会导致整个任务需要重来。6. 把 AI 原生开发落到团队协作里的实际经验6.1 团队共享 CLAUDE.md 的维护方式个人项目里 CLAUDE.md 自己维护就行团队项目里就需要考虑协作问题。我的做法是把 CLAUDE.md 纳入版本控制和代码一起提交、一起 review。任何对项目结构、技术栈、代码规范有影响的变更都必须同步更新 CLAUDE.md。为了避免多人同时修改导致冲突我建议把 CLAUDE.md 拆成几个部分项目级别的通用约定放在根目录的 CLAUDE.md 里模块级别的特殊约定放在各模块目录下的 CLAUDE.md 里。这样不同模块的负责人可以各自维护自己模块的配置减少冲突概率。6.2 代码 review 时怎么区分人和 AI 的产出在 AI 原生开发的团队里代码 review 的流程需要做一些调整。传统 review 主要关注逻辑正确性、边界条件、性能问题。AI 生成的代码在这些方面通常不会有大问题但容易在项目一致性上出问题比如命名风格不统一、错误处理方式和项目其他部分不一致、引入了项目里没有使用过的依赖等。我的做法是在 review 清单里增加几项针对 AI 生成代码的检查项命名是否符合项目约定、错误处理是否和现有代码一致、是否引入了新的依赖、是否有不必要的抽象。这几项检查能拦住大部分 AI 生成代码的常见问题。6.3 什么时候不该用 AI 写代码这个问题很少有人讨论但实际很重要。我的经验是以下几种情况不适合让 AI 主导涉及核心业务逻辑且没有明确规格说明的模块、需要深度理解历史遗留代码的修改、安全敏感的操作、性能极度敏感的代码路径。这些场景的共同特点是正确性依赖于大量隐性知识而这些知识很难通过 CLAUDE.md 或者任务描述完整传达给 AI。强行让 AI 做这些任务结果往往是看起来能用但埋了坑后期排查成本远高于自己写。7. 我在这套流程里总结出的几条实用原则第一条原则是AI 生成的代码必须经过和人工代码完全相同的质量门禁。不要因为这是 AI 写的就降低标准也不要因为这是 AI 写的就额外加码。统一标准才能让流程可持续。第二条原则是上下文的质量决定输出的质量。你给 AI 的信息越准确、越完整、越结构化它给出的结果就越接近可用状态。花时间写 CLAUDE.md、写清楚任务描述这些投入最终都会以更少的返工形式回报给你。第三条原则是小步快跑比大步慢走更适合 AI 原生开发。把大任务拆成小任务每个任务单独验证跑通之后再进入下一个。这样即使某个环节出问题影响范围也可控排查起来也容易。第四条原则是保持对 AI 输出的判断力。AI 编码助手的能力在快速提升但它仍然会犯错仍然会有理解偏差。你的价值不在于能写多少代码而在于能判断哪些代码是对的、哪些代码需要改、哪些代码根本不该用。这个判断力是 AI 原生开发时代最核心的竞争力。我在实际项目里跑这套流程跑了大概半年最大的体会是AI 原生开发不是让 AI 替你做决定而是让你把精力从重复劳动转移到真正需要判断力的地方。手册里的方法给了我们一个起点但每个团队、每个项目都需要根据自己的实际情况做调整。照搬手册不一定能成功理解手册背后的逻辑然后找到适合自己的落地方式才是正确的打开方式。
Anthropic AI原生开发手册解读：Claude Code工程化实践与CI/CD集成
1. 这份手册为什么值得每个开发者认真读一遍Anthropic 公开内部 AI 原生软件开发手册这件事在开发者圈子里炸开的速度比我预想得快得多。我第一时间把公开的内容翻了一遍又结合自己这大半年用 Claude Code 做项目的实际体验做了对照最大的感受是这份手册的价值不在于它教了你几个命令而在于它把AI 原生开发这件事从玄学拉回到了工程实践层面。什么叫 AI 原生开发简单说就是把 AI 编码助手当作团队里一个真实的、需要被管理的成员来对待而不是把它当成一个高级的代码补全工具。这个区别听起来像是文字游戏但实际落地的时候差别大到离谱。大多数人用 AI 写代码的方式是打开对话框描述需求复制粘贴结果遇到问题再问一轮。这种方式在写小脚本、改 bug 的时候确实够用但一旦项目规模上去、协作人数变多、代码需要长期维护就会立刻暴露出问题——AI 生成的代码风格不统一、上下文丢失、重复劳动、没人知道某段代码到底是人写的还是 AI 写的。这份手册要解决的就是这些问题。它适合所有已经在用或者准备用 AI 编码工具的开发者不管你是刚接触 Claude Code 的新手还是已经用了一段时间但总觉得差点意思的老用户。接下来我会把手册里的核心思路拆开讲同时补上我自己在实际项目中踩过的坑和总结出来的操作细节。2. AI 原生开发和传统 AI 辅助开发到底差在哪2.1 从工具到协作者的认知转变传统 AI 辅助开发的思路是我遇到一个问题去问 AIAI 给我答案我判断对错然后采用。这个流程里AI 是一个被动的查询对象主动权完全在人手里。AI 原生开发的思路是我把 AI 当成一个需要明确职责、需要提供上下文、需要设定约束的协作者。这意味着你要主动为 AI 准备它工作所需的一切信息而不是等它猜。这个转变带来的第一个实际变化就是你需要为 AI 写入职文档。就像新员工入职需要了解项目背景、代码规范、部署流程一样AI 也需要这些信息。在 Claude Code 的体系里这个入职文档就是 CLAUDE.md 文件。2.2 CLAUDE.md 不是可选项是基础设施很多人第一次看到 CLAUDE.md 这个东西的时候反应是这不就是个配置文件吗随便写写就行了。我一开始也是这么想的结果吃了大亏。当时我在一个中型项目里用 Claude Code没有认真写 CLAUDE.md导致 AI 每次生成的代码都要我手动调整命名风格、导入顺序、错误处理方式一天下来光改格式就花掉大量时间。后来我认真补了一份 CLAUDE.md把项目的技术栈、目录结构、命名约定、测试要求、常用命令全部写进去效果立竿见影。AI 生成的代码第一次就能达到可提交的水平我只需要做逻辑层面的 review不用再当格式校对员。一份合格的 CLAUDE.md 至少应该包含这些内容项目概述这个项目是做什么的核心业务逻辑是什么有哪些关键模块技术栈说明语言版本、框架版本、数据库类型、依赖管理工具目录结构约定哪个目录放什么类型的文件新文件应该放在哪里代码规范命名风格、注释要求、错误处理模式、日志规范测试要求用什么测试框架测试文件放在哪里覆盖率要求常用命令如何启动开发服务器、如何跑测试、如何构建、如何部署禁止事项哪些操作绝对不能做比如不能直接改某个核心文件、不能引入新的依赖等提示CLAUDE.md 不是写一次就完事的它应该随着项目演进持续更新。我现在的习惯是每次项目结构有变动第一件事就是更新 CLAUDE.md然后再让 AI 参与后续开发。2.3 上下文管理是 AI 原生开发的核心技能传统开发里上下文切换的成本主要在人身上。AI 原生开发里上下文管理的对象变成了 AI。Claude Code 这类工具的工作方式是它在一次会话里能记住的内容是有限的超出窗口的内容会被截断或压缩。如果你在一个超长会话里让 AI 处理一个复杂任务它很可能会忘记前面说过的约束。我的做法是把大任务拆成小任务每个任务单独开一个会话并且在会话开始时把相关的 CLAUDE.md 内容和当前任务的具体要求一起提供给 AI。这样虽然看起来多了一些手动操作但 AI 的输出质量会稳定很多。另外一个技巧是在会话进行到一半的时候主动让 AI 总结一下当前的状态和待办事项然后把这个总结作为新会话的起点。这样可以在不丢失关键信息的前提下重置上下文窗口。3. 把 AI 编码助手接进 CI/CD 流水线的具体做法3.1 为什么要把 AI 和 CI/CD 绑在一起CI/CD 流水线的核心价值是自动化验证。代码提交之后自动跑测试、自动检查代码风格、自动构建、自动部署。把 AI 编码助手接进这个流程意味着 AI 生成的代码也要经过同样的质量门禁。这听起来是理所当然的事情但实际操作中很多人会忽略这一点——他们让 AI 直接生成代码然后手动提交跳过了自动化检查环节。我现在的做法是AI 生成的代码必须先通过本地测试然后提交到分支触发 CI 流水线流水线跑通之后才允许合并。如果流水线挂了我会把报错信息直接贴给 AI让它自己修。这个循环跑几轮之后AI 生成的代码质量会明显提升因为它能从报错中学习到项目的实际约束。3.2 在 GitLab CI 里集成 AI 代码检查GitLab CI 是目前用得比较多的持续集成方案它的配置文件是.gitlab-ci.yml。下面是一个我实际在用的配置片段作用是每次提交时自动跑测试和代码风格检查stages: - test - lint - build run-tests: stage: test script: - npm install - npm run test only: - merge_requests - main lint-check: stage: lint script: - npm run lint allow_failure: false build-app: stage: build script: - npm run build artifacts: paths: - dist/这个配置本身不涉及 AI但它的意义在于它为 AI 生成的代码设定了一个明确的验收标准。你可以在 CLAUDE.md 里写明所有提交必须通过 lint-check 和 run-tests这样 AI 在生成代码的时候就会主动考虑这些约束。3.3 Docker 环境下的 CI/CD 注意事项如果你的 CI/CD 跑在 Docker 容器里有几个细节需要特别注意。首先是基础镜像的选择建议用官方提供的语言运行时镜像不要用过于精简的版本否则可能会缺少 AI 工具需要的依赖。其次是缓存策略Docker 层的缓存如果配置不当会导致每次构建都重新下载依赖拖慢整个流水线。我在一个项目里遇到过这样的情况CI 流水线每次跑都要花十几分钟排查之后发现是 Docker 缓存没有正确挂载。后来在.gitlab-ci.yml里加了缓存配置构建时间直接降到了三分钟以内。具体的配置思路是把node_modules或者对应的依赖目录挂载为缓存卷这样依赖没有变化的时候就不需要重新安装。注意Docker 环境里的网络配置和权限设置需要提前确认好否则 AI 工具在容器里可能无法正常访问外部服务。这个问题在本地开发时不容易发现一到 CI 环境就会暴露。4. Claude Code 从安装到跑通第一个任务的完整路径4.1 安装前的环境确认Claude Code 的安装本身不复杂但环境准备阶段有几个容易忽略的点。首先确认你的操作系统版本macOS 和 Windows 的安装方式略有不同。其次确认 Node.js 的版本Claude Code 对 Node 版本有最低要求版本太低会直接报错。在 Ubuntu 上安装的话基本流程是先确保 Node.js 和 npm 是最新的稳定版然后通过 npm 全局安装 Claude Code 的命令行工具。安装完成之后第一次运行会引导你完成认证配置。Windows 用户建议在 WSL 环境下操作原生 Windows 环境的兼容性虽然一直在改善但 WSL 下的体验明显更顺畅。安装完成之后建议先跑一个最简单的任务验证环境是否正常比如让 Claude Code 读取当前目录下的文件列表或者生成一个简单的 Hello World 脚本。这一步的目的是确认工具能正常访问文件系统、能正常调用模型、能正常输出结果。4.2 在 VS Code 里配置 Claude CodeVS Code 是大多数开发者日常使用的编辑器把 Claude Code 集成进去能省掉不少切换窗口的时间。配置方式一般是在 VS Code 的扩展市场里搜索对应的插件安装之后在设置里填入必要的配置项。配置完成之后你可以在 VS Code 里直接打开 Claude Code 的对话面板让它读取当前打开的文件、分析选中的代码片段、生成新的代码文件。这个体验比在终端里操作要直观很多尤其是在处理多个文件关联修改的时候。我自己的使用习惯是简单的单文件修改直接在终端里用 Claude Code 命令行完成涉及多文件重构或者需要看代码上下文的时候切到 VS Code 插件里操作。两种方式配合使用效率比只用一种要高。4.3 第一次让 Claude Code 干活的正确姿势很多人第一次用 Claude Code 的时候会直接扔一个很大的需求过去比如帮我实现一个用户管理系统。这种用法大概率会得到一堆看起来能用但实际上跑不起来的代码。正确的做法是从小任务开始逐步建立信任。我的建议是第一次任务选择这样的类型修改一个已有函数的实现、给一个现有模块添加一个小的功能点、修复一个明确的 bug。这类任务的特点是边界清晰、验证简单、不需要太多上下文。跑通几个小任务之后你对工具的能力边界会有更准确的判断再逐步加大任务复杂度。每次任务开始之前确保 CLAUDE.md 文件在项目根目录下并且内容是最新的。任务描述要具体包含输入、输出、约束条件。任务完成之后不要直接提交先自己 review 一遍跑一下测试确认没有问题再进入下一步。5. 那些手册里没写但实际会踩的坑5.1 模型路由和网关配置的常见报错在实际部署 Claude Code 的过程中我遇到过好几次和模型路由相关的报错。典型的表现是工具启动之后无法正常调用模型日志里会出现类似expected a gateway model route这样的提示。这个问题的根源通常是网关配置和实际使用的模型标识不匹配。排查思路是这样的先确认你配置的模型名称和网关支持的模型列表是否一致然后检查网络连接是否正常最后确认认证信息是否有效。这三个环节任何一个出问题都会导致调用失败。我的经验是把配置信息集中管理不要散落在多个文件里这样排查的时候只需要看一个地方。5.2 权限配置过松或过紧都会出问题Claude Code 在执行操作的时候需要一定的文件系统权限和命令执行权限。权限给得太紧AI 无法读取项目文件、无法运行测试命令基本干不了活。权限给得太松AI 可能会修改不该修改的文件、执行有风险的操作。我的做法是采用最小权限原则只开放当前任务必需的权限。比如让 AI 修改某个模块的代码就只开放那个模块目录的读写权限不要开放整个项目的写权限。需要 AI 跑测试的时候单独授权测试命令的执行权限不要开放所有命令的执行权限。5.3 会话中断和状态丢失的应对长时间运行的会话可能会因为各种原因中断比如网络波动、工具超时、手动关闭等。中断之后重新打开之前的上下文可能已经丢失了。这个问题在复杂任务中特别让人头疼因为重新建立上下文需要花不少时间。我的应对策略是在会话进行到关键节点的时候让 AI 输出一份当前状态的总结包括已完成的工作、待完成的工作、已知的问题。把这份总结保存下来会话中断之后直接用它作为新会话的起点。这个习惯看起来麻烦但实际节省的时间远超预期。另外一个技巧是把大任务拆成多个小任务每个小任务单独开一个会话。这样即使某个会话中断影响范围也有限不会导致整个任务需要重来。6. 把 AI 原生开发落到团队协作里的实际经验6.1 团队共享 CLAUDE.md 的维护方式个人项目里 CLAUDE.md 自己维护就行团队项目里就需要考虑协作问题。我的做法是把 CLAUDE.md 纳入版本控制和代码一起提交、一起 review。任何对项目结构、技术栈、代码规范有影响的变更都必须同步更新 CLAUDE.md。为了避免多人同时修改导致冲突我建议把 CLAUDE.md 拆成几个部分项目级别的通用约定放在根目录的 CLAUDE.md 里模块级别的特殊约定放在各模块目录下的 CLAUDE.md 里。这样不同模块的负责人可以各自维护自己模块的配置减少冲突概率。6.2 代码 review 时怎么区分人和 AI 的产出在 AI 原生开发的团队里代码 review 的流程需要做一些调整。传统 review 主要关注逻辑正确性、边界条件、性能问题。AI 生成的代码在这些方面通常不会有大问题但容易在项目一致性上出问题比如命名风格不统一、错误处理方式和项目其他部分不一致、引入了项目里没有使用过的依赖等。我的做法是在 review 清单里增加几项针对 AI 生成代码的检查项命名是否符合项目约定、错误处理是否和现有代码一致、是否引入了新的依赖、是否有不必要的抽象。这几项检查能拦住大部分 AI 生成代码的常见问题。6.3 什么时候不该用 AI 写代码这个问题很少有人讨论但实际很重要。我的经验是以下几种情况不适合让 AI 主导涉及核心业务逻辑且没有明确规格说明的模块、需要深度理解历史遗留代码的修改、安全敏感的操作、性能极度敏感的代码路径。这些场景的共同特点是正确性依赖于大量隐性知识而这些知识很难通过 CLAUDE.md 或者任务描述完整传达给 AI。强行让 AI 做这些任务结果往往是看起来能用但埋了坑后期排查成本远高于自己写。7. 我在这套流程里总结出的几条实用原则第一条原则是AI 生成的代码必须经过和人工代码完全相同的质量门禁。不要因为这是 AI 写的就降低标准也不要因为这是 AI 写的就额外加码。统一标准才能让流程可持续。第二条原则是上下文的质量决定输出的质量。你给 AI 的信息越准确、越完整、越结构化它给出的结果就越接近可用状态。花时间写 CLAUDE.md、写清楚任务描述这些投入最终都会以更少的返工形式回报给你。第三条原则是小步快跑比大步慢走更适合 AI 原生开发。把大任务拆成小任务每个任务单独验证跑通之后再进入下一个。这样即使某个环节出问题影响范围也可控排查起来也容易。第四条原则是保持对 AI 输出的判断力。AI 编码助手的能力在快速提升但它仍然会犯错仍然会有理解偏差。你的价值不在于能写多少代码而在于能判断哪些代码是对的、哪些代码需要改、哪些代码根本不该用。这个判断力是 AI 原生开发时代最核心的竞争力。我在实际项目里跑这套流程跑了大概半年最大的体会是AI 原生开发不是让 AI 替你做决定而是让你把精力从重复劳动转移到真正需要判断力的地方。手册里的方法给了我们一个起点但每个团队、每个项目都需要根据自己的实际情况做调整。照搬手册不一定能成功理解手册背后的逻辑然后找到适合自己的落地方式才是正确的打开方式。
