1. 从"能跑就行"到"AI原生"：SDLC到底被改写了什么
大多数团队对AI编码工具的用法，还停留在"打开对话框，贴一段代码，让它帮我改个bug"的阶段。这种用法本质上只是把AI当成了一个更聪明的搜索引擎，SDLC的骨架没变，需求评审、方案设计、编码、测试、发布这条流水线还是靠人在每个环节手动衔接。而AI-Native SDLC要解决的核心问题，是让智能体真正嵌入到软件开发生命周期的每一个节点里，成为流程的参与者而不是旁观者。
我最初接触这个概念时也有点犯嘀咕——"AI原生"是不是又一个包装出来的热词？直到我把Claude Code接进一个真实项目，让它读完整个仓库的CLAUDE.md之后自主完成了一次跨模块重构，我才意识到差别在哪。传统AI辅助是"你问它答"，AI-Native是"你定规则它执行"。前者需要你每次把上下文喂到它嘴边，后者只需要你在项目根目录放一份约定文件，它就知道这个项目的技术栈、代码规范、目录结构、测试命令、提交格式。
这个转变带来的直接后果是：SDLC的瓶颈从"写代码的速度"转移到了"规则定义的质量"。你写得越清楚，智能体跑得越顺；你含糊其辞，它就会在某个环节自作主张，给你埋一个三天后才炸的雷。所以这篇手册不打算讲空泛的方法论，而是围绕一个核心问题展开：怎么用Claude Code这类终端智能体，把AI-Native SDLC从概念落成一套能天天跑的工作流。
适合读这篇的人有三类：一是已经在用Claude Code但只拿它当补全工具的开发者；二是想给团队引入智能体工作流但不知道从哪下手的技术负责人；三是好奇"智能体到底能自主到什么程度"的工程师。下面我会从环境搭建、CLAUDE.md的写法、智能体在SDLC各阶段的分工、以及踩过的坑这几个角度，把整套东西拆开讲。
2. 环境落地：Claude Code在Windows、Ubuntu、VS Code里的三种装法
2.1 为什么终端智能体比IDE插件更值得投入
先说一个反直觉的判断：如果你只是想要代码补全，那IDE自带的补全够用了，没必要折腾Claude Code。Claude Code的价值在于它能直接执行终端命令——读文件、跑测试、查git log、执行构建脚本，这些动作它都能自己发起。这意味着它不是一个"回答问题的工具"，而是一个"能动手的协作者"。
我试过在VS Code里用插件形态的AI助手，体验是流畅，但每次涉及跨文件操作，它只能给你建议，实际执行还得你自己复制粘贴。Claude Code不一样，你说"把这个模块的日志改成结构化输出"，它会先grep出所有相关文件，逐个读取，然后批量修改，最后跑一遍测试确认没破坏东西。这个链路是闭环的。
所以选型逻辑很清楚：需要补全用IDE插件，需要执行用终端智能体。两者不冲突，可以并存。
2.2 Windows和Ubuntu下的安装差异
Claude Code的安装本身不复杂，但不同系统下的坑点不一样。Windows用户最容易卡在环境变量和路径分隔符上，Ubuntu用户则经常遇到权限和Node版本的问题。
Windows下的安装步骤大致是这样：
# 确认Node版本，Claude Code对Node版本有要求 node -v # 如果版本过低，先升级 npm install -g n n stable # 安装Claude Code npm install -g @anthropic-ai/claude-code # 验证安装 claude --versionUbuntu下多一步权限处理：
# 如果npm全局安装报权限错误 sudo chown -R $(whoami) ~/.npm # 然后再执行全局安装 npm install -g @anthropic-ai/claude-code实测下来，Ubuntu 22.04和24.04都能正常跑，但如果你用的是WSL，建议直接在WSL里装而不是Windows侧，因为终端命令的执行环境更干净，路径问题也少。
注意：安装完成后第一次运行会要求登录授权。如果你所在的组织禁用了订阅访问，会看到"your organization has disabled claude subscription access"这类提示，这时候需要联系管理员确认权限策略，或者改用API密钥的方式接入。
2.3 VS Code集成与本地模型接入的取舍
VS Code里集成Claude Code有两种思路。一种是用官方提供的VS Code扩展，在编辑器内直接调用；另一种是在VS Code的集成终端里跑Claude Code，把它当成一个终端工具用。我个人更推荐后者，因为终端形态下智能体的命令执行能力是完整的，而扩展形态有时候会受限于编辑器的沙箱。
如果你想把Claude Code接到本地模型上（比如通过LM Studio跑的模型），思路是配置第三方API端点。具体做法是在环境变量里指定base URL和模型名称，让它走本地推理。这么做的好处是数据不出本地，适合处理敏感代码库；代价是本地模型的指令遵循能力通常不如云端模型，复杂重构任务容易跑偏。
我的建议是：日常开发用云端模型保证质量，涉及敏感模块时切本地模型做隔离。两套配置可以共存，通过环境变量切换。
3. CLAUDE.md：决定智能体表现上限的那份文件
3.1 为什么一份约定文件比反复提示更有效
很多人用Claude Code的方式是每次开新会话都重新交代一遍背景："这是个React项目，用TypeScript，测试用Vitest，提交信息遵循Conventional Commits……"说一遍两遍还行，说十遍就烦了，而且每次交代的细节还不一样，导致智能体的行为不稳定。
CLAUDE.md解决的就是这个问题。它放在项目根目录，Claude Code启动时会自动读取，相当于给智能体发了一份"项目入职手册"。你写一次，之后每次会话它都带着这份上下文工作。
我踩过的坑是：一开始把CLAUDE.md写得太简略，只写了技术栈，结果智能体在改代码时用了跟项目不一致的命名风格，review的时候被打回来重做。后来我把代码规范、目录约定、测试命令、禁止事项都写进去，返工率明显下降。
3.2 一份能打的CLAUDE.md应该包含哪些段落
下面是我在多个项目里迭代出来的结构，你可以直接参考：
# 项目概述 一句话说明这个项目是做什么的。 # 技术栈 - 语言：TypeScript 5.x - 框架：React 18 + Vite - 测试：Vitest + Testing Library - 包管理：pnpm # 目录结构约定 - src/components：纯展示组件 - src/hooks：自定义hook - src/services：API调用层 - src/utils：无副作用的工具函数 # 代码规范 - 组件用函数式，不用class - 命名用camelCase，组件名用PascalCase - 禁止使用any，必要时用unknown加类型守卫 - 所有导出函数必须有JSDoc注释 # 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 跑测试：pnpm test - 类型检查：pnpm typecheck - 构建：pnpm build # 禁止事项 - 不要修改package.json里的依赖版本 - 不要删除现有的测试用例 - 不要在没有测试覆盖的情况下改核心逻辑这份文件的关键在于具体。"遵循良好规范"这种话等于没说，"禁止使用any"才是可执行的约束。智能体不会揣摩你的意图，它只会照字面执行。
3.3 让CLAUDE.md随项目演进的维护节奏
CLAUDE.md不是写完就扔那不管的。项目在演进，规范也在变，如果这份文件跟实际代码脱节，智能体就会按过时的规则干活。
我的做法是把它纳入code review流程：每次有新的约定产生（比如引入了新的测试框架、调整了目录结构），就在同一个PR里更新CLAUDE.md。这样它始终跟代码库保持同步。
另外一个技巧是：当你发现智能体反复犯同一个错误时，不要每次都手动纠正，而是把这条规则补进CLAUDE.md。比如它总是忘记给新组件写测试，你就在禁止事项里加一条"新增组件必须同时提交对应的测试文件"。下次它就会自己遵守。
4. 智能体在SDLC各阶段的真实分工
4.1 需求阶段：把模糊描述转成可执行的任务清单
需求阶段智能体能帮的忙，不是替你做产品决策，而是把一段模糊的需求描述拆成结构化的任务清单。比如你给它一段"用户希望能批量导出订单数据，支持按时间筛选"，它可以输出：
- 新增导出接口，接收时间范围参数
- 前端增加导出按钮和日期选择器
- 导出格式支持CSV和Excel
- 大数据量时走异步任务，避免请求超时
- 补充对应的单元测试和集成测试
这个拆解过程本身不新鲜，产品经理也会做。但智能体的优势是它拆完之后可以直接进入执行环节，不需要你再手动把任务分配给不同的人。你确认清单没问题，它就能接着往下干。
需要注意的是，需求阶段的输出必须人工确认。智能体不懂业务优先级，它拆出来的任务清单可能技术上合理但业务上跑偏。我一般会让它先出清单，我改一遍，再让它执行。
4.2 编码阶段：跨文件重构是它最擅长的场景
编码阶段是Claude Code最能体现价值的地方，尤其是跨文件重构。举个我实际遇到的例子：项目里原本用moment.js处理时间，想换成dayjs减小打包体积。这个改动涉及几十个文件，手动改的话一下午就没了。
我把任务交给Claude Code，指令是："把项目里所有moment的用法替换成dayjs，注意API差异，改完跑一遍测试。"它的执行过程是：
- 先grep出所有import moment的文件
- 逐个读取，识别出用到的moment API
- 对照dayjs的API做替换，遇到不兼容的地方（比如moment的某些插件）单独处理
- 修改package.json
- 跑测试，发现两个用例失败，自己定位到是时区处理差异，修正后重跑通过
整个过程我只需要在最后review一遍diff。这种任务如果手动做，出错概率还高，因为人容易漏掉某个角落的文件。
但这里有个前提：测试覆盖要够。如果项目没有测试，智能体改完你根本不知道有没有改坏。所以AI-Native SDLC的一个隐含要求是，测试基础设施得先到位。
4.3 测试与审查阶段：智能体做初筛，人做终审
测试阶段智能体能做两件事：一是根据代码变更自动生成测试用例，二是对现有测试做补充。我通常让它先跑一遍现有测试，看覆盖率报告，然后针对没覆盖到的分支生成用例。
代码审查阶段，智能体可以充当第一道筛子。你让它review一个PR，它会指出命名问题、潜在的空指针、未处理的异常、跟CLAUDE.md规范不符的地方。这些机械性的检查它做得比人快，也不会因为疲劳而漏看。
但终审必须是人。智能体不懂业务上下文，它可能把一个符合业务需求的"奇怪"写法标记为问题。我遇到过它建议把一个故意的重试逻辑删掉，因为"看起来冗余"，实际上那个重试是为了应对下游服务的不稳定。所以审查环节的分工是：智能体负责找技术问题，人负责判断业务合理性。
4.4 发布阶段：把重复的发布检查交给它
发布阶段有很多重复性的检查：版本号有没有更新、CHANGELOG有没有写、构建产物是否正常、环境变量是否齐全。这些都可以写成脚本让智能体执行。
我的做法是在CLAUDE.md里定义一条发布检查清单，然后每次发布前让智能体逐项确认。它会跑构建、检查git tag、对比环境变量配置，最后输出一份检查报告。人只需要看报告确认没问题，点发布。
这个环节省下的时间不算多，但省下的是注意力。发布前的紧张感很大一部分来自"怕漏了什么"，有了自动检查清单，这种焦虑就消失了。
5. 踩坑实录：那些文档里不会写的教训
5.1 智能体"自作主张"的边界问题
智能体最让人头疼的行为是自作主张。你让它改A，它顺手把B也改了，理由是"这样更合理"。我遇到过一次：让它给一个函数加日志，它把函数的返回类型也改了，说是"顺便优化一下"。
这个问题的根源是CLAUDE.md里没有明确边界。后来我加了一条规则："只修改任务明确指定的文件，如需改动其他文件，先说明理由并等待确认。"这条规则加上之后，越界行为基本消失了。
所以经验是：智能体的自主性是双刃剑，你得用规则给它划边界。边界越清晰，它越可靠。
5.2 上下文窗口耗尽后的行为退化
Claude Code处理大项目时，上下文窗口会被逐渐填满。填满之后它的表现会明显退化：开始忘记之前的约定、重复问已经回答过的问题、改代码时忽略CLAUDE.md的规范。
应对办法是主动管理会话长度。一个任务做完就开新会话，不要在一个会话里连续干十几个任务。另外，把大任务拆成小任务，每个任务独立会话，这样每次它读到的上下文都是干净的。
我现在的习惯是：一个会话只做一件事，做完就关。虽然看起来麻烦，但比在一个长会话里跟退化的智能体较劲要高效得多。
5.3 第三方API接入时的模型切换陷阱
如果你用第三方API接入Claude Code（比如接DeepSeek、Qwen、GLM这些模型），会遇到一个陷阱：不同模型对工具调用的支持程度不一样。有些模型能很好地遵循CLAUDE.md的指令，有些则会把指令当耳旁风。
我试过用几个不同的模型跑同一个任务，表现差异很大。指令遵循能力强的模型，跨文件重构一次过；能力弱的模型，改到一半就开始胡来。所以切换模型时一定要先做小任务验证，别直接上大任务。
另外，第三方API的稳定性也是个变量。我遇到过API超时导致智能体执行到一半中断的情况，这时候项目可能处于一个中间状态。所以用第三方API时，建议在git的干净分支上操作，出问题可以直接reset。
6. 把AI-Native SDLC跑成日常：我的工作流配置
6.1 一个典型工作日的智能体使用节奏
我现在的工作流大致是这样：早上到工位，先看昨天的CI结果和待处理的PR。如果有需要review的代码，让智能体先跑一遍初筛，把明显的问题标出来，我再重点看业务逻辑部分。
然后进入开发任务。每个任务开始前，我会先让智能体读一遍相关模块的代码，确认它理解了上下文，再下达具体指令。任务完成后，让它跑测试、生成commit message、提交。
下午如果有重构类的大任务，我会专门留出时间块，因为这类任务需要我全程盯着，随时准备在它跑偏时介入。零散的小任务则穿插在会议间隙处理。
这个节奏的关键是把智能体当成一个需要管理的协作者，而不是一个随叫随到的工具。它有它的强项和短板，你得知道什么时候该用它，什么时候该自己上。
6.2 团队协作中如何统一智能体行为
如果是团队使用，CLAUDE.md应该纳入版本控制，所有人共用一份。这样不同人用智能体时，行为是一致的，不会出现"张三的智能体改了代码风格，李四的智能体又改回去"这种混乱。
另外建议在团队里约定：智能体生成的代码，提交时在commit message里标注。不是为了追责，而是方便review时知道这段代码需要额外关注——智能体写的代码有时候会有一些"看起来对但实际有隐患"的地方，标注出来能让reviewer多留个心眼。
6.3 什么任务不该交给智能体
最后说说什么任务不该交给智能体。涉及核心业务逻辑的决策、需要跟外部团队协调的改动、安全敏感的操作（比如改权限配置、动数据库schema），这些我都不交给智能体。它适合做的是有明确边界、有测试兜底、可回滚的任务。
判断标准很简单：如果这个任务搞砸了，你能不能快速发现并回滚？能，就交给它；不能，就自己来。这个标准帮我避免了好几次潜在的灾难。
智能体再强，它也只是执行者。SDLC里那些需要判断力、需要权衡取舍的环节，还是得人来把关。AI-Native不是让人退场，而是让人从重复劳动里解放出来，把精力放在真正需要人的地方。