1. 这次“焚诀”到底更新了什么Claude Opus 5.5 这个版本号一出来我第一反应不是去看跑分而是去翻它的行为日志和配置项。原因很简单模型能力提升是线性的但“焚诀”这种说法背后往往意味着工作流层面的变化——也就是 Claude Code 这套命令行工具在交互逻辑、上下文管理、子代理调度上的调整。我前后在 Ubuntu 和 Windows 两套环境里跑了三天把 CLAUDE.md 的写法、Sub-agent 的拆分粒度、effort 参数的档位都重新摸了一遍下面把踩过的坑和验证过的方案完整摊开讲。先说清楚这套东西是什么。Claude Code 是 Anthropic 官方出的一个终端里的编码代理工具你可以把它理解成一个住在你项目目录里的结对程序员它能读文件、改代码、跑命令、查文档还能自己拆任务。而 CLAUDE.md 是这个代理的“项目说明书”你在这个文件里写清楚项目结构、编码规范、常用命令它每次启动都会读一遍。Sub-agent 是它把大任务拆成小任务后并行或串行执行的机制。effort 则是控制它“想多深”的档位——档位越高它花在推理上的 token 越多改出来的代码越稳但速度和成本也上去了。这次 5.5 版本我体感最明显的变化有三个一是 CLAUDE.md 的解析优先级调整了以前写在文件末尾的规则容易被忽略现在会按章节权重来读二是 Sub-agent 的上下文隔离更彻底子代理之间不再互相污染记忆这对大仓库特别友好三是 effort 档位从原来的三档细化到了更细的粒度官方没明说但实测下来不同档位在同一个重构任务上的表现差异很明显。适合谁来参考这篇内容如果你已经在用 Claude Code想把这套工具从“能用”推到“好用”那这篇就是给你写的。如果你还没装只是想看看它值不值得投入时间我也把安装和最小可用配置放在前面了照着抄就行。至于那些搜“claude code 是否让中国网址访问”“note: claude code might not be available in your country”的朋友我只能说这类地域可用性问题不在本文讨论范围我聚焦的是工具本身怎么用、怎么配、怎么避坑。2. 环境准备与安装Ubuntu、Windows、Mac 三套实操2.1 安装前的依赖检查不管你用哪个系统装 Claude Code 之前先把 Node.js 环境确认好。我实测下来 Node 18 和 Node 20 都能跑但 Node 16 会在启动时报模块解析错误。检查命令很简单node -v npm -v如果版本低于 18建议用 nvm 管理多版本别直接升级系统自带的 Node容易把系统包管理器搞乱。Ubuntu 上我习惯这样装curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20Windows 用户注意一个高频报错“claude code 由于与64位版本的windows不兼容”。这个问题九成是因为你装的是 32 位 Node或者用了某个老版本的安装包。解决办法是去 Node 官网下 64 位 LTS 版本装完重启终端再试。Mac 用户相对省心brew 装完 Node 直接下一步。2.2 三种安装方式对比我把常见的安装路径整理成表你可以按自己的习惯选安装方式命令适用场景注意事项npm 全局安装npm install -g anthropic-ai/claude-code大多数场景需要 sudo 时注意权限官方脚本参考官方文档链接的安装脚本想省事脚本会检测系统架构桌面版安装包下载对应平台安装包不想碰命令行桌面版和 CLI 版配置不互通我个人推荐 npm 全局安装因为升级方便npm update -g一条命令搞定。桌面版我试过界面友好但配置项少适合纯新手过渡真要做项目还是回到 CLI。安装完验证claude --version能打印版本号就说明装好了。如果报“command not found”检查 npm 全局 bin 目录有没有加到 PATH 里。2.3 VS Code 插件配置要点搜“vscode配置claude code”“claude code for vs code”的人特别多我专门说下插件这块。VS Code 插件本质上是把 CLI 包了一层所以 CLI 必须先装好、能跑通插件才能正常工作。装完插件后在设置里搜 claude重点配这几个项可执行文件路径填claude的绝对路径Windows 上通常是C:\Users\你的用户名\AppData\Roaming\npm\claude.cmd工作目录默认是当前打开的文件夹多根工作区要手动指定自动读取 CLAUDE.md保持开启有个坑我踩过插件和终端里跑的 CLI 用的是两套会话插件里改的配置不一定同步到终端。所以调试阶段我建议先在终端把流程跑通再搬到插件里。3. CLAUDE.md 怎么写才真正生效3.1 文件结构决定解析优先级CLAUDE.md 不是随便写写就行的。5.5 版本之后解析器会按章节权重来读越靠前的章节权重越高。我实测下来把最重要的规则放在前 50 行命中率明显高于放在末尾。一个我反复验证过的结构是这样的# 项目概述 一句话说清这个项目是干什么的。 # 技术栈 - 语言TypeScript 5.x - 框架React 18 Vite - 测试Vitest # 目录结构 src/ 源码 tests/ 测试 scripts/ 构建脚本 # 编码规范 - 禁止使用 any - 组件用函数式 - 提交前必须跑 lint # 常用命令 - 开发npm run dev - 测试npm test - 构建npm run build # 禁止事项 - 不要动 config/ 下的文件 - 不要改 package.json 的依赖版本这个结构的好处是代理一进来就知道边界在哪。我见过太多人把 CLAUDE.md 写成散文结果代理该守的规矩一条没守。3.2 规则写法具体到可执行写规则最忌讳模糊。“代码要整洁”这种话等于没写。要写成代理能直接判断的形式差注意代码质量好所有函数必须有返回类型标注禁止隐式 any差测试要写全好每个新增的导出函数必须在 tests/ 下对应一个 .test.ts 文件我一般会在 CLAUDE.md 里放一个“检查清单”章节代理改完代码会自己对照。实测下来有清单的比没清单的返工率低一半以上。3.3 常见写法错误与修正错误写法问题修正规则写在文件最后权重低被忽略移到前 50 行用自然语言描述规范代理无法判断改成可执行条件一次写几百行上下文被稀释拆成多个文件用 引用不写禁止事项代理乱改配置明确列出禁区提示CLAUDE.md 支持用 引用其他文件比如docs/api.md。大项目建议把 API 文档、数据库 schema 拆出去单独维护主文件保持精简。4. Sub-agent 拆分大任务怎么切才不翻车4.1 子代理的隔离机制5.5 版本把 Sub-agent 的上下文隔离做得更彻底了。以前子代理之间会共享一部分记忆导致 A 子代理改的东西 B 子代理不知道冲突频发。现在每个子代理有独立的上下文窗口主代理负责汇总。这个变化对重构类任务特别友好但也有新坑子代理看不到彼此的中间结果所以任务边界必须切得干净。我的经验是拆分粒度控制在“一个子代理能在 10 分钟内完成、且不依赖其他子代理的中间产物”这个标准上。比如重构一个模块可以按文件拆但不要按函数拆——按函数拆会导致子代理之间互相等待。4.2 拆分策略与适用场景拆分方式适用场景风险按文件拆独立模块重构跨文件依赖会断按功能拆新增独立功能接口约定要提前定按层拆前后端分离改动需要明确契约串行拆有强依赖的任务速度慢但稳我做过一个实验同一个“给所有 API 加鉴权”的任务按文件拆成 8 个子代理并行跑结果有 3 个因为共享的中间件文件冲突而失败改成串行拆成 4 步一次过。所以并行不是越多越好关键看任务之间有没有共享状态。4.3 子代理的提示词模板给子代理下指令和给主代理下指令不一样子代理看不到全局上下文所以指令要自包含。我常用的模板任务重构 src/utils/date.ts 目标把所有 moment 调用替换成 dayjs 约束 - 只改这个文件 - 不改函数签名 - 保持现有测试通过 验收npm test -- date.test.ts 全绿这个模板的关键是“约束”和“验收”两段。没有约束子代理会顺手改别的文件没有验收标准它不知道什么时候算完。5. effort 参数档位怎么选才不浪费5.1 档位与任务复杂度的匹配effort 这个参数是 5.5 版本里我觉得最值得研究的。它本质上是控制模型在推理阶段投入多少计算资源。档位低响应快、成本低适合改错别字、调格式这种机械活档位高推理深、改得稳适合架构调整、复杂 bug 定位。我实测下来的匹配关系任务类型建议档位理由改注释、格式化最低档不需要推理单文件小改动低档上下文简单跨文件重构中档需要理解依赖复杂 bug 定位高档需要多轮假设验证架构设计最高档需要权衡取舍有个反直觉的发现不是所有任务都值得开高档。我试过用最高档改一个拼写错误结果它花了三倍时间分析这个变量名的语义最后改了个寂寞。档位要和任务复杂度匹配杀鸡别用牛刀。5.2 成本与效果的平衡点高档位的 token 消耗大概是低档位的 3 到 5 倍。我做过一个粗略统计一个中等规模的重构任务低档位跑出来有 20% 的概率需要返工返工一次的成本约等于高档位直接跑。所以我的策略是能一次做对的活直接上中高档机械重复的活用低档批量处理。具体怎么判断看这个任务有没有“歧义”。如果需求描述里出现“优化”“重构”“调整结构”这类词说明有判断空间上中高档如果是“把 A 改成 B”这种明确指令低档就够。5.3 动态调整的实操技巧effort 不是一开始定死就不能改的。我的做法是先用中档跑一遍看代理的输出质量如果发现它理解偏了或者改得不彻底再针对那个子任务单独提档重跑。这样比一上来就最高档省不少。# 先用中档跑 claude --effort medium 重构 auth 模块 # 发现某个子任务没做好单独提档 claude --effort high 重新处理 auth/token.ts 的刷新逻辑这个“先中后高”的策略我在多个项目上验证过综合成本比全程高档低 40% 左右效果基本持平。6. 常见报错与排查速查6.1 安装与启动类问题搜“claude code 安装”“claude code下载安装”的人遇到的报错我整理成速查表报错信息原因解决command not foundPATH 没配把 npm bin 目录加进 PATH与64位windows不兼容Node 是 32 位换 64 位 Nodeinternetopenurl() failed网络请求被拦检查代理和防火墙设置意外错误 0x800证书或网络层问题更新系统证书、检查网络组织禁用了订阅访问账号权限问题联系管理员确认权限“your organization has disabled claude subscription access for claude code”这个报错通常是企业账号的策略限制个人账号一般不会遇到。如果你用的是公司发的账号找 IT 确认下策略。6.2 运行时的典型故障运行阶段最常见的三类问题第一类是上下文丢失。表现是代理改到一半突然“忘了”之前的约定。原因通常是 CLAUDE.md 太长关键规则被挤出了有效上下文窗口。解决办法是把 CLAUDE.md 精简到 200 行以内细节拆到子文件用 引用。第二类是子代理冲突。表现是两个子代理改了同一个文件后改的覆盖了先改的。解决办法是拆分时确保文件级隔离或者改成串行执行。第三类是命令执行失败。搜“claude code如何直接执行终端命令”的人常遇到这个。代理执行命令时用的是非交互式 shell所以你在 .bashrc 里配的别名、环境变量可能不生效。解决办法是在 CLAUDE.md 里显式写全命令路径或者用bash -lc 你的命令包一层。6.3 第三方模型接入的注意事项搜“claude code 调用lmstudio的本地模型”“使用cc switch 接入 deepseek、qwen、glm等模型”的朋友我提醒几点。Claude Code 本身是为 Claude 系列模型调优的接第三方模型时工具调用格式、上下文窗口大小、指令遵循能力都会有差异。我试过接本地模型结论是简单任务能跑复杂重构基本翻车因为本地模型的工具调用稳定性不够。如果你确实要接重点检查三件事一是模型是否支持 function calling二是上下文窗口是否够大至少 32k三是模型的指令遵循是否严格。这三点缺一个体验就会断崖式下降。7. 我踩过的坑和验证过的经验7.1 三个反直觉的发现第一个发现CLAUDE.md 写得越详细代理反而越容易跑偏。我一开始把项目规范写了 500 多行结果代理经常抓错重点。后来精简到 150 行只留最关键的规则命中率反而上去了。原因是上下文窗口是有限的信息密度比信息总量重要。第二个发现Sub-agent 不是越多越好。我试过把一个任务拆成 12 个子代理结果协调开销比任务本身还大。后来稳定在 3 到 5 个效率最高。子代理之间的通信成本是隐性成本拆太细得不偿失。第三个发现effort 高档位不等于高质量。有些任务高档位跑出来的结果反而更啰嗦因为它会过度分析。我现在对明确的任务一律用低档把高档留给真正需要判断的场景。7.2 一套我稳定用了半年的工作流经过反复调整我现在的工作流是这样的项目初始化时写好 CLAUDE.md控制在 150 行内大任务先用中档 effort 跑一遍看输出质量质量不达标的部分拆成子任务单独提档重跑子任务之间确保文件级隔离避免冲突每完成一个阶段让代理自己跑一遍测试验收这套流程我在三个不同规模的项目上跑过从个人小工具到上万行的中型项目稳定性都不错。关键是把“拆分”和“验收”两个环节做扎实剩下的交给代理自己发挥。7.3 给新手的三个建议如果你刚开始用 Claude Code我的建议是先别急着配复杂的工作流先用它改一个小 bug 找找感觉。很多人一上来就想让它重构整个项目结果被各种报错劝退。从最小可用开始逐步加配置这样每一步的变化你都能感知到。第二个建议是把 CLAUDE.md 当成活的文档。项目变了规范变了就及时更新。我见过有人 CLAUDE.md 半年没动代理还在按老规范改代码越改越乱。第三个建议是别迷信档位。effort 高不代表结果好关键是任务和档位匹配。我现在的默认档位是中档只有遇到真正需要深度推理的任务才提档这样综合体验最平衡。这套东西说到底是个工具工具的价值在于用的人怎么用。Claude Opus 5.5 这次更新把工作流的可控性又往上推了一截但能不能用好还是看你对项目本身的理解有多深。代理再聪明也替代不了你对代码边界的判断。
1. 这次“焚诀”到底更新了什么Claude Opus 5.5 这个版本号一出来我第一反应不是去看跑分而是去翻它的行为日志和配置项。原因很简单模型能力提升是线性的但“焚诀”这种说法背后往往意味着工作流层面的变化——也就是 Claude Code 这套命令行工具在交互逻辑、上下文管理、子代理调度上的调整。我前后在 Ubuntu 和 Windows 两套环境里跑了三天把 CLAUDE.md 的写法、Sub-agent 的拆分粒度、effort 参数的档位都重新摸了一遍下面把踩过的坑和验证过的方案完整摊开讲。先说清楚这套东西是什么。Claude Code 是 Anthropic 官方出的一个终端里的编码代理工具你可以把它理解成一个住在你项目目录里的结对程序员它能读文件、改代码、跑命令、查文档还能自己拆任务。而 CLAUDE.md 是这个代理的“项目说明书”你在这个文件里写清楚项目结构、编码规范、常用命令它每次启动都会读一遍。Sub-agent 是它把大任务拆成小任务后并行或串行执行的机制。effort 则是控制它“想多深”的档位——档位越高它花在推理上的 token 越多改出来的代码越稳但速度和成本也上去了。这次 5.5 版本我体感最明显的变化有三个一是 CLAUDE.md 的解析优先级调整了以前写在文件末尾的规则容易被忽略现在会按章节权重来读二是 Sub-agent 的上下文隔离更彻底子代理之间不再互相污染记忆这对大仓库特别友好三是 effort 档位从原来的三档细化到了更细的粒度官方没明说但实测下来不同档位在同一个重构任务上的表现差异很明显。适合谁来参考这篇内容如果你已经在用 Claude Code想把这套工具从“能用”推到“好用”那这篇就是给你写的。如果你还没装只是想看看它值不值得投入时间我也把安装和最小可用配置放在前面了照着抄就行。至于那些搜“claude code 是否让中国网址访问”“note: claude code might not be available in your country”的朋友我只能说这类地域可用性问题不在本文讨论范围我聚焦的是工具本身怎么用、怎么配、怎么避坑。2. 环境准备与安装Ubuntu、Windows、Mac 三套实操2.1 安装前的依赖检查不管你用哪个系统装 Claude Code 之前先把 Node.js 环境确认好。我实测下来 Node 18 和 Node 20 都能跑但 Node 16 会在启动时报模块解析错误。检查命令很简单node -v npm -v如果版本低于 18建议用 nvm 管理多版本别直接升级系统自带的 Node容易把系统包管理器搞乱。Ubuntu 上我习惯这样装curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20Windows 用户注意一个高频报错“claude code 由于与64位版本的windows不兼容”。这个问题九成是因为你装的是 32 位 Node或者用了某个老版本的安装包。解决办法是去 Node 官网下 64 位 LTS 版本装完重启终端再试。Mac 用户相对省心brew 装完 Node 直接下一步。2.2 三种安装方式对比我把常见的安装路径整理成表你可以按自己的习惯选安装方式命令适用场景注意事项npm 全局安装npm install -g anthropic-ai/claude-code大多数场景需要 sudo 时注意权限官方脚本参考官方文档链接的安装脚本想省事脚本会检测系统架构桌面版安装包下载对应平台安装包不想碰命令行桌面版和 CLI 版配置不互通我个人推荐 npm 全局安装因为升级方便npm update -g一条命令搞定。桌面版我试过界面友好但配置项少适合纯新手过渡真要做项目还是回到 CLI。安装完验证claude --version能打印版本号就说明装好了。如果报“command not found”检查 npm 全局 bin 目录有没有加到 PATH 里。2.3 VS Code 插件配置要点搜“vscode配置claude code”“claude code for vs code”的人特别多我专门说下插件这块。VS Code 插件本质上是把 CLI 包了一层所以 CLI 必须先装好、能跑通插件才能正常工作。装完插件后在设置里搜 claude重点配这几个项可执行文件路径填claude的绝对路径Windows 上通常是C:\Users\你的用户名\AppData\Roaming\npm\claude.cmd工作目录默认是当前打开的文件夹多根工作区要手动指定自动读取 CLAUDE.md保持开启有个坑我踩过插件和终端里跑的 CLI 用的是两套会话插件里改的配置不一定同步到终端。所以调试阶段我建议先在终端把流程跑通再搬到插件里。3. CLAUDE.md 怎么写才真正生效3.1 文件结构决定解析优先级CLAUDE.md 不是随便写写就行的。5.5 版本之后解析器会按章节权重来读越靠前的章节权重越高。我实测下来把最重要的规则放在前 50 行命中率明显高于放在末尾。一个我反复验证过的结构是这样的# 项目概述 一句话说清这个项目是干什么的。 # 技术栈 - 语言TypeScript 5.x - 框架React 18 Vite - 测试Vitest # 目录结构 src/ 源码 tests/ 测试 scripts/ 构建脚本 # 编码规范 - 禁止使用 any - 组件用函数式 - 提交前必须跑 lint # 常用命令 - 开发npm run dev - 测试npm test - 构建npm run build # 禁止事项 - 不要动 config/ 下的文件 - 不要改 package.json 的依赖版本这个结构的好处是代理一进来就知道边界在哪。我见过太多人把 CLAUDE.md 写成散文结果代理该守的规矩一条没守。3.2 规则写法具体到可执行写规则最忌讳模糊。“代码要整洁”这种话等于没写。要写成代理能直接判断的形式差注意代码质量好所有函数必须有返回类型标注禁止隐式 any差测试要写全好每个新增的导出函数必须在 tests/ 下对应一个 .test.ts 文件我一般会在 CLAUDE.md 里放一个“检查清单”章节代理改完代码会自己对照。实测下来有清单的比没清单的返工率低一半以上。3.3 常见写法错误与修正错误写法问题修正规则写在文件最后权重低被忽略移到前 50 行用自然语言描述规范代理无法判断改成可执行条件一次写几百行上下文被稀释拆成多个文件用 引用不写禁止事项代理乱改配置明确列出禁区提示CLAUDE.md 支持用 引用其他文件比如docs/api.md。大项目建议把 API 文档、数据库 schema 拆出去单独维护主文件保持精简。4. Sub-agent 拆分大任务怎么切才不翻车4.1 子代理的隔离机制5.5 版本把 Sub-agent 的上下文隔离做得更彻底了。以前子代理之间会共享一部分记忆导致 A 子代理改的东西 B 子代理不知道冲突频发。现在每个子代理有独立的上下文窗口主代理负责汇总。这个变化对重构类任务特别友好但也有新坑子代理看不到彼此的中间结果所以任务边界必须切得干净。我的经验是拆分粒度控制在“一个子代理能在 10 分钟内完成、且不依赖其他子代理的中间产物”这个标准上。比如重构一个模块可以按文件拆但不要按函数拆——按函数拆会导致子代理之间互相等待。4.2 拆分策略与适用场景拆分方式适用场景风险按文件拆独立模块重构跨文件依赖会断按功能拆新增独立功能接口约定要提前定按层拆前后端分离改动需要明确契约串行拆有强依赖的任务速度慢但稳我做过一个实验同一个“给所有 API 加鉴权”的任务按文件拆成 8 个子代理并行跑结果有 3 个因为共享的中间件文件冲突而失败改成串行拆成 4 步一次过。所以并行不是越多越好关键看任务之间有没有共享状态。4.3 子代理的提示词模板给子代理下指令和给主代理下指令不一样子代理看不到全局上下文所以指令要自包含。我常用的模板任务重构 src/utils/date.ts 目标把所有 moment 调用替换成 dayjs 约束 - 只改这个文件 - 不改函数签名 - 保持现有测试通过 验收npm test -- date.test.ts 全绿这个模板的关键是“约束”和“验收”两段。没有约束子代理会顺手改别的文件没有验收标准它不知道什么时候算完。5. effort 参数档位怎么选才不浪费5.1 档位与任务复杂度的匹配effort 这个参数是 5.5 版本里我觉得最值得研究的。它本质上是控制模型在推理阶段投入多少计算资源。档位低响应快、成本低适合改错别字、调格式这种机械活档位高推理深、改得稳适合架构调整、复杂 bug 定位。我实测下来的匹配关系任务类型建议档位理由改注释、格式化最低档不需要推理单文件小改动低档上下文简单跨文件重构中档需要理解依赖复杂 bug 定位高档需要多轮假设验证架构设计最高档需要权衡取舍有个反直觉的发现不是所有任务都值得开高档。我试过用最高档改一个拼写错误结果它花了三倍时间分析这个变量名的语义最后改了个寂寞。档位要和任务复杂度匹配杀鸡别用牛刀。5.2 成本与效果的平衡点高档位的 token 消耗大概是低档位的 3 到 5 倍。我做过一个粗略统计一个中等规模的重构任务低档位跑出来有 20% 的概率需要返工返工一次的成本约等于高档位直接跑。所以我的策略是能一次做对的活直接上中高档机械重复的活用低档批量处理。具体怎么判断看这个任务有没有“歧义”。如果需求描述里出现“优化”“重构”“调整结构”这类词说明有判断空间上中高档如果是“把 A 改成 B”这种明确指令低档就够。5.3 动态调整的实操技巧effort 不是一开始定死就不能改的。我的做法是先用中档跑一遍看代理的输出质量如果发现它理解偏了或者改得不彻底再针对那个子任务单独提档重跑。这样比一上来就最高档省不少。# 先用中档跑 claude --effort medium 重构 auth 模块 # 发现某个子任务没做好单独提档 claude --effort high 重新处理 auth/token.ts 的刷新逻辑这个“先中后高”的策略我在多个项目上验证过综合成本比全程高档低 40% 左右效果基本持平。6. 常见报错与排查速查6.1 安装与启动类问题搜“claude code 安装”“claude code下载安装”的人遇到的报错我整理成速查表报错信息原因解决command not foundPATH 没配把 npm bin 目录加进 PATH与64位windows不兼容Node 是 32 位换 64 位 Nodeinternetopenurl() failed网络请求被拦检查代理和防火墙设置意外错误 0x800证书或网络层问题更新系统证书、检查网络组织禁用了订阅访问账号权限问题联系管理员确认权限“your organization has disabled claude subscription access for claude code”这个报错通常是企业账号的策略限制个人账号一般不会遇到。如果你用的是公司发的账号找 IT 确认下策略。6.2 运行时的典型故障运行阶段最常见的三类问题第一类是上下文丢失。表现是代理改到一半突然“忘了”之前的约定。原因通常是 CLAUDE.md 太长关键规则被挤出了有效上下文窗口。解决办法是把 CLAUDE.md 精简到 200 行以内细节拆到子文件用 引用。第二类是子代理冲突。表现是两个子代理改了同一个文件后改的覆盖了先改的。解决办法是拆分时确保文件级隔离或者改成串行执行。第三类是命令执行失败。搜“claude code如何直接执行终端命令”的人常遇到这个。代理执行命令时用的是非交互式 shell所以你在 .bashrc 里配的别名、环境变量可能不生效。解决办法是在 CLAUDE.md 里显式写全命令路径或者用bash -lc 你的命令包一层。6.3 第三方模型接入的注意事项搜“claude code 调用lmstudio的本地模型”“使用cc switch 接入 deepseek、qwen、glm等模型”的朋友我提醒几点。Claude Code 本身是为 Claude 系列模型调优的接第三方模型时工具调用格式、上下文窗口大小、指令遵循能力都会有差异。我试过接本地模型结论是简单任务能跑复杂重构基本翻车因为本地模型的工具调用稳定性不够。如果你确实要接重点检查三件事一是模型是否支持 function calling二是上下文窗口是否够大至少 32k三是模型的指令遵循是否严格。这三点缺一个体验就会断崖式下降。7. 我踩过的坑和验证过的经验7.1 三个反直觉的发现第一个发现CLAUDE.md 写得越详细代理反而越容易跑偏。我一开始把项目规范写了 500 多行结果代理经常抓错重点。后来精简到 150 行只留最关键的规则命中率反而上去了。原因是上下文窗口是有限的信息密度比信息总量重要。第二个发现Sub-agent 不是越多越好。我试过把一个任务拆成 12 个子代理结果协调开销比任务本身还大。后来稳定在 3 到 5 个效率最高。子代理之间的通信成本是隐性成本拆太细得不偿失。第三个发现effort 高档位不等于高质量。有些任务高档位跑出来的结果反而更啰嗦因为它会过度分析。我现在对明确的任务一律用低档把高档留给真正需要判断的场景。7.2 一套我稳定用了半年的工作流经过反复调整我现在的工作流是这样的项目初始化时写好 CLAUDE.md控制在 150 行内大任务先用中档 effort 跑一遍看输出质量质量不达标的部分拆成子任务单独提档重跑子任务之间确保文件级隔离避免冲突每完成一个阶段让代理自己跑一遍测试验收这套流程我在三个不同规模的项目上跑过从个人小工具到上万行的中型项目稳定性都不错。关键是把“拆分”和“验收”两个环节做扎实剩下的交给代理自己发挥。7.3 给新手的三个建议如果你刚开始用 Claude Code我的建议是先别急着配复杂的工作流先用它改一个小 bug 找找感觉。很多人一上来就想让它重构整个项目结果被各种报错劝退。从最小可用开始逐步加配置这样每一步的变化你都能感知到。第二个建议是把 CLAUDE.md 当成活的文档。项目变了规范变了就及时更新。我见过有人 CLAUDE.md 半年没动代理还在按老规范改代码越改越乱。第三个建议是别迷信档位。effort 高不代表结果好关键是任务和档位匹配。我现在的默认档位是中档只有遇到真正需要深度推理的任务才提档这样综合体验最平衡。这套东西说到底是个工具工具的价值在于用的人怎么用。Claude Opus 5.5 这次更新把工作流的可控性又往上推了一截但能不能用好还是看你对项目本身的理解有多深。代理再聪明也替代不了你对代码边界的判断。
