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/servicesAPI调用层 - 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不是让人退场而是让人从重复劳动里解放出来把精力放在真正需要人的地方。
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/servicesAPI调用层 - 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不是让人退场而是让人从重复劳动里解放出来把精力放在真正需要人的地方。
