鬼游这周我接到一个不算新但很烦的需求：给一个已经三个月没人碰过的 Python 服务，增加一套带 dry-run 的容量评估入口。它不复杂，但跨了配置文件、路由、缓存层和好几个测试模块。按老流程，我至少得先花半小时把代码仓库翻熟，再写接口、跑测试、修脏数据。这周我换了个方式：直接把 Claude Code 扔进仓库，先让它做仓库侦察，再让它按我给的验收条件完成实现。中途我只做了两件事：看 diff、决定要不要继续。
结果比我预想的好很多，不是因为它把代码写得有多聪明，而是它把“找代码、读代码、改代码、跑测试、看报错、再改”这一段本来最耗时的循环，变成了一种我可以随时介入的自动化过程。如果你已经装了 Claude Code 但还在把它当高级聊天框用，或者刚听说这个工具、想从零开始摸清安装和配置，这篇文章应该能帮你少走不少弯路。
我尽量按真实项目的操作顺序来写：先讲我为什么愿意把“需求到交付”整段链路交给它，再讲 Windows 和 VSCode 环境里怎么装、怎么配、怎么接不同的模型服务，然后给一套我一直在用的工作流，最后把高频报错的排查思路和几个省 token 的小习惯一起放出来。这些都是我实际踩过、试过、最后沉淀下来的做法，可以直接抄。
1. 我为什么会让 Claude Code 负责“需求到交付”的整段链路
1.1 代码补全工具和“能干活的 Agent”是两种东西
很多人第一次接触 Claude Code 时，会下意识拿它和编辑器里的代码补全工具对比，然后得出一个结论：这玩意儿也就是能聊得更细一点。
这个判断其实漏掉了最关键的差异。普通的 AI 补全工具默认是“你写一行，它补下一行”，模型能看到的信息有限，也不具备执行能力；而 Claude Code 是一个跑在终端里的 Agent，它有权读取你的文件树、搜索关键函数、修改文件、执行命令，甚至在被测试结果打脸后自己回头改代码。换句话说，它面对的不是“当前这个函数接下来该写什么”，而是“这个仓库里的一个需求应该怎么被实现”。
最直观的差别出现在一个典型场景里。以前改一个服务端接口，我得先在 IDE 里全局搜接口名，找到控制器、服务层、DTO、测试文件，逐个点开读一遍，心里有了数才开始动手。现在我会直接让 Claude Code 去干同样的事，而它会把阅读路径和使用到的证据列出来，我再基于它的输出做判断。真正省时间的不是“帮我写代码”，而是“帮我读代码、找代码、建立上下文”这件事被自动化了。
1.2 完整闭环意味着效率模型发生了改变
如果你拆解任何一个开发任务，会发现它其实是这样一个循环：检索信息、形成方案、修改代码、运行验证、根据失败信息再修正。过去这个循环里最消耗注意力的不是“写”这个动作，而是反复搬运上下文——查完这个文件切到那个文件，跑完测试再回去看日志，找到问题后又得重新回忆设计意图。
Claude Code 的工作方式恰恰是把整个循环收拢到同一个会话里。它能自己执行测试，然后把失败信息读进来，再定位到出错行。我在旁边做的更像是一个“技术负责人”：看它判断得对不对，方向偏了就纠正一句，没问题就让它继续。
这种模式的直接收益是，我能一次性并行处理更多事情。以前跑一趟完整测试要等输出、读日志、定位问题，一连串动作做完基本没精力再做别的；现在我可以让它先跑出一个失败清单，趁它修复的时候去 review 另一个需求的 diff。编程效率的增量，主要来自这段“验证和修正”的时间被压缩了。
1.3 什么任务适合全流程交付，什么不适合
Claude Code 确实能干活，但我不建议你把所有事情都塞给它。用了一段时间后，我自己会按任务类型做取舍。
| 任务类型 | 适用程度 | 我的操作习惯 |
|---|---|---|
| 仓库级需求调研、影响面分析 | 很合适 | 让它先读结构和关键文件，再输出影响清单 |
| 按明确规则修改代码、补单测 | 很合适 | 给验收标准，让它小步实现并跑测试 |
| 重构跨模块调用链 | 比较合适 | 分阶段推进，每阶段都看 diff |
| UI 像素级调样式 | 一般 | 只有视觉规范非常具体时才会交给它 |
| 产品决策、需求边界确认 | 不适合 | 这里没有“代码正确”的验证标准，需要人决定 |
| 权限严格的生产环境变更 | 不建议全自动 | 让它生成脚本和命令，人工执行和复核 |
这个表格背后的逻辑是：Claude Code 在“有明确正确性标准”的任务里最可靠。测试能跑通、lint 能通过、接口契约能对齐，这类任务它能自我验证；反过来，如果一件事只有人类审美和业务经验能判断对错，那就别让它独立发挥。
1.4 我为什么不担心它替代我
聊到 AI 编程工具，身边总有人问：那你以后是不是就不用写代码了？
我的真实感受正相反。用了 Claude Code 以后，我对需求定义、代码评审、质量把关这些环节投入的时间反而更多了。原因很简单：工具把执行速度提上来了，瓶颈就变成了“我有没有把需求说清楚”和“我有没有能力判断它的产出是否符合要求”。这两件事恰好是工程师最核心的价值。
所以与其说 Claude Code 替代了编程，不如说它把编程拆成了两个环节：一个环节是由模型快速完成的检索与编写，另一个环节仍然保留给人类——明确目标、设定边界、验收结果。认清这一点之后，你才不会在一个明明该由人来拍板的问题上，反复追问模型“你觉得呢”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Windows 与 VSCode 环境实测：安装、配置与模型接入的完整过程
2.1 官方安装路径和最基本的验证
我先说一套在主流系统上都通用的安装路径。Claude Code 以 npm 包的形式分发，前提是你机器上有 Node.js 运行环境。建议 Node 版本不低于 18，太老的版本装完很容易出现运行时异常，排查起来很浪费时间。
安装命令很简单：
bash复制npm install -g @anthropic-ai/claude-code
装完以后先别急着开干，执行一下版本验证：
bash复制claude --version
能正常打印版本号，说明 CLI 本身已经装好。如果你之后想卸载，执行 npm uninstall -g @anthropic-ai/claude-code 就行，它不会在你的项目目录里塞一堆无法清理的残留文件。
如果你用的是 Ubuntu 或 macOS，基本上走到这里已经可以运行 claude 开始对话了。但在 Windows 上，尤其你平时用的是 PowerShell 和 VSCode，还有几个非常容易绊倒人的细节。
2.2 在 VSCode 里使用 Claude Code 的三种方式
我日常的主要阵地还是 VSCode，所以重点说说怎么在编辑器里顺畅地用它。
第一种方式最简单：直接打开 VSCode 的集成终端，按 Ctrl + `` 调出终端面板，然后输入 claude`，在当前项目目录下启动会话。这种方式不需要装任何额外扩展，适合快速提问、快速验证命令。
第二种方式是在 VSCode 扩展市场里搜索并安装官方 Claude Code 扩展。装完后，它能更紧密地把会话内容和编辑器结合起来：模型修改代码后，你可以在编辑器里直接看到文件变化；一些文件操作和 diff 查看也能在图形界面里完成。比起纯终端操作，扩展方式对刚上手的人更友好。
第三种方式是使用桌面板版本，也就是把 Claude Code 独立成一个桌面应用来用。桌面板适合那些希望把编码会话和编辑器窗口分开管理的人，界面体验比终端更直观。不过我个人仍然习惯待在编辑器里，因为开发过程中需要频繁查看代码和测试，少切换一个窗口就少一分打断。
别忘了，你现在工作的目录就是 Claude Code 的项目上下文。在 VSCode 里打开一个文件夹作为工作区，再从集成终端启动，它才能准确理解“当前项目”指的是哪一套代码。
2.3 认证方式：Claude 订阅与 API Key 计费
安装完成只是第一步，真正决定能不能跑起来的是认证配置。Claude Code 官方支持两种计费通道。
一种是使用 Claude 订阅账号登录。运行 claude 后按提示完成登录授权即可，适合个人日常使用。另一种是基于 API Key 的按量计费，适合需要精细化控制费用的场景，或者账号层面暂时无法开通订阅入口的情况。
API Key 方式主要靠环境变量传递：
bash复制export ANTHROPIC_API_KEY="你的key"
在 Windows PowerShell 里对应写成：
powershell复制$env:ANTHROPIC_API_KEY="你的key"
设置好之后重新运行 claude，它会优先读取这个环境变量完成认证。需要说明的是，这种“用自己的 API Key”的做法是官方支持的正常计费通道，不是绕过，遇到账号层面限制时，优先看能不能切换到 API Key 计费，这才是安全且合规的路径。
2.4 模型接入、settings.json 与第三方兼容入口
很多用户在搜索“Claude Code 接入其他模型”“Claude Code settings.json”时会看到各种配置方式。我的建议是先理解它的配置结构，再动手改。
Claude Code 的配置分为用户级和项目级。用户级配置文件一般在用户主目录的 .claude/settings.json 下，作用于所有项目；项目级配置在 .claude/settings.json，会跟随仓库一起提交，适合团队共享。常见的模型相关配置都会写在这些文件的 env 字段里，比如：
json复制{
"env": {
"ANTHROPIC_BASE_URL": "你的兼容服务地址",
"ANTHROPIC_MODEL": "服务商提供的模型ID",
"ANTHROPIC_SMALL_FAST_MODEL": "服务商提供的轻量模型ID"
}
}
如果你要通过兼容服务商接入其他模型，核心就是设置这两个值：ANTHROPIC_BASE_URL 指向你使用的 Anthropic 兼容接口地址，ANTHROPIC_MODEL 改成该服务实际支持、实际下发的模型名。
这里就引出一个非常常见的报错，也是很多人发帖求助的场景："deepseek-v4-flash" is not a model this version of claude code recognizes。这个错误乍一看很像“版本太旧不认识新模型”，但根据我的排查经验，绝大多数情况下真正原因是：你填写的模型名根本不在当前后端服务的可用模型列表里。Claude Code 启动时会对模型名做可用性校验，发现不是它能识别的名字就会直接拒绝，而不是等到请求发出后才失败。
你需要做的不是反复猜测“再填一个别的名字试试”，而是去你配置的兼容服务提供方那里查“真实的模型标识是什么”。比如服务商文档里明确写了可用模型列表，那就把 ANTHROPIC_MODEL 严格改成列表里存在的标识。不要自己去发明一个听起来很厉害的版本号。
另一个被频繁提到的工具是 CC Switch。它本质上是一个配置切换器，解决的是“我有多个模型服务、多套 API Key，每次改环境变量太麻烦”的问题。你可以把不同的 base URL、模型名、密钥组合存成多个 profile，在使用时一键切换。社区里有人用它同时管理远程 API 和本地模型，也有人用 Ollama 把本地推理服务跑起来后，再通过兼容配置让 Claude Code 连到本地端点。整套链路对隐私敏感、想离线验证的场景确实有意义。
但我要提醒一句：Ollama 这类本地推理服务跑起来的小模型，能力上限和在线大模型差距明显。用它辅助做一些简单的代码解释、单文件脚本生成还凑合，但真要跑“全仓库检索—多文件修改—自动测试修正”这种完整 Agent 工作流，会非常吃力。别把它当成省钱版主力模型，期望值要放对。
2.5 Windows 环境速查表
最后给你一张我在 Windows 上整理的环境速查表，可以直接对着检查：
| 检查项 | 推荐值 / 操作 | 说明 |
|---|---|---|
| Node.js 版本 | 18+ | 太低会导致运行时异常 |
| 全局安装 | npm install -g @anthropic-ai/claude-code |
官方分发方式 |
| 版本验证 | claude --version |
先确认 CLI 存在再谈配置 |
| PowerShell 执行策略 | Set-ExecutionPolicy RemoteSigned -Scope CurrentUser |
只影响当前用户，不需要动管理员全局策略 |
| PATH 检查 | npm prefix -g |
把输出的目录加到用户 PATH |
| API Key | $env:ANTHROPIC_API_KEY="你的key" |
当前终端临时生效 |
| 模型接入 | settings.json 的 env 字段 | 按服务商真实模型 ID 填写 |
3. 一套我反复在用的“需求到交付”工作流，以及它在真实任务中的表现
3.1 第一阶段：先做仓库侦察，不急着写代码
我见过很多刚开始用 Claude Code 的人犯同一个错误：需求还没说清楚，就直接丢一句“帮我实现登录功能”，然后期待它开始写代码。后果通常是它凭空臆造一堆接口和目录结构，跟你的项目实际风格完全对不上。
我的做法是把任务拆成两个阶段，第一阶段只让它读、不让它改。拿这周那个容量评估需求举例，我启动会话后先下了一条指令：
text复制先不要修改任何文件。请按下列顺序做一次仓库侦察：
1. 读 README、pyproject.toml 和 app/main.py，告诉我项目技术栈和启动方式。
2. 搜索所有出现 capacity、evaluate、dry_run 的位置，列出对应的路由和核心函数。
3. 查看相关测试文件的组织方式，指出如果我加一个新入口，应该在哪个测试模块里补充用例。
最后输出三样东西：影响文件清单、风险点、以及你建议的实现步骤。
这一步的核心价值，是让 Claude Code 在你写任何代码之前先把上下文建立起来。它的输出如果够准确，后面实现阶段的返工率就会非常低；如果输出有明显偏差，那也是在你付出大量修改成本之前就能发现的。
3.2 第二阶段：给出边界和验收标准，再让它动手
仓库侦察通过后，我会接着下第二道指令，这道指令通常带明确的约束条件。约束越具体，模型发挥失控的概率越小。
text复制开始实现需求。请遵守以下边界：
1. 新增接口路径为 /api/v1/capacity/preview，HTTP 方法为 POST。
2. 入参里必须带 dry_run 字段，缺省时默认 true，不允许在 dry_run=false 的情况下真正修改线上配置。
3. 所有新增代码的日志必须走项目已有的 logger 封装。
4. 可以修改 app 目录和 tests 目录，但不要动数据库迁移文件。
5. 实现完成后运行相关 pytest，跑通后才能提交总结。
注意第 4、5 条，这相当于给 Agent 画了一块“可以动的草皮”，也给了它一个明确的终止条件。AI 编程工具最让人头疼的不是它不会写代码，而是它容易在没人喊停的情况下越改越多。通过设置“可改动范围”和“出口条件”，我能保证它的工作成果是可预测的。
3.3 第三阶段：验证闭环，让测试结果自己驱动修正
Claude Code 在真实项目里最大的优势，是它能跑命令、能看测试输出、能根据失败信息自我修正。这个能力把“写完代码—人工跑测试—复制报错—再让它改”这样的低效循环删掉了。
我在实践中通常给它这样的授权：允许执行测试命令和静态检查，但禁止执行任何会改动生产资源的命令。例如让它跑 pytest、npm run lint，但所有数据库变更、部署命令只允许输出到控制台，由我手工执行。
这个阶段我会把注意力放在观察它的修正逻辑上。比如第一次测试失败后，它是直接改了失败的测试去迎合实现，还是认真分析了报错原因然后修实现代码。如果是前者，我会立刻打断并纠正；如果是后者，说明它在正确轨道上，那就放心让它多跑几轮。
3.4 第四阶段：人看 diff，机器写提交说明
代码全部跑通后，我很少让 Claude Code 直接推代码到远端，甚至不会让它直接 commit。我的固定动作是先让它生成一份改动摘要和提交信息建议，然后我手动检查所有 diff。
bash复制git diff --stat
git diff app/
这一步不可省略。AI 能给你一个看着合理的提交信息，但不代表它的每行改动都符合你的本意。尤其要警惕两类情况：一类是模型为了让测试通过而删掉了本来就该保留的校验逻辑；另一类是它“好心”帮你重构了与需求无关的老代码，平白扩大改动范围。发现这类问题，直接选中 diff 里不需要的部分，再让它还原，然后重新跑测试。
标准流程走完后，我会让它基于最终 diff 更新一次提交信息，再由我执行 commit 和 push。效率和质量并不冲突，关键是人要在验收节点牢牢把关。
3.5 一次实际任务的时间账
用这套流程做完这周的容量评估需求后，我粗略记录了一笔时间账：仓库侦察和影响面梳理从原来手工的二三十分钟压缩到五分钟左右；编码实现部分在一个小时内完成，包括新增路由、参数校验、dry-run 分支和测试用例；测试修正过程因为是 Claude Code 自己在循环里完成的，几乎不占用我连续注意力。真正没有缩短的，是我最后 review diff 的半小时。
这意味着什么？开发任务的“找、读、写、测”环节被大幅压缩，但“审、拍板、交付”依然保留着它该有的重量。这个结论我觉得比“AI 能自动写代码”更值得传播：提效不是让 AI 替你做决定，而是把更多的可支配时间还给决策本身。
4. 高频报错不是黑盒：按排查链路复现问题的经验
4.1 模型名不被识别：先分清是版本问题还是名字问题
报错信息长这样："some-model-name" is not a model this version of claude code recognizes。很多人第一反应是更新 Claude Code 版本，但更新完发现问题依旧，原因就在于它根本不一定是版本问题。
我在 2.4 节已经说了这个错误的本质：Claude Code 会对模型名做可用性校验，它查不到这个模型名，就直接在启动阶段拒绝。至于为什么查不到，有两种可能。第一种是你的版本真的旧了，内置的模型字典里没有新模型；第二种是你的 ANTHROPIC_MODEL 填的是一个服务商不存在的名字。
所以完整的排查顺序应该是：
- 先执行
claude --version确认当前版本，再查阅该版本文档支持哪些模型名。 - 查看你的 settings.json 或环境变量，确认填进去的模型名到底从哪里来的。
- 如果你接的是第三方兼容服务，去该服务提供方的文档里找真实可用的模型标识，然后严格照抄。
- 如果是本地模型，确认本地推理服务已经启动，并且模型确实已被加载。
我见过有人在本地没启动 Ollama 的情况下反复改模型名，折腾半小时才发现在报连接错误。建议遇到任何模型相关报错，先确认“后端服务真的活着吗，名字真的对吗”，再谈版本更新。
4.2 CLI 不在 PATH 里：VSCode 集成终端最常见的暗坑
报错 failed to run claude code: error: could not locate the claude cli on path 几乎都出在 Windows 用户身上。排查链路不复杂，但你得理解它为什么会发生。
npm 全局安装的包通常不在系统默认 PATH 里。VSCode 扩展试图启动 Claude Code 时，如果它继承的 shell 环境没有加载更新后的用户 PATH，自然就找不到这条命令。可问题是，你明明在终端里执行 claude --version 是成功的。
遇到这种情况，不要急着重装，按下面顺序来：
- 在任意终端执行
claude --version，确认 CLI 确实能跑。 - 执行
npm prefix -g，拿到 npm 全局目录的绝对路径。 - Windows 上把这个路径加到“系统属性—环境变量—用户变量—Path”里。
- 完全关闭所有已打开的 VSCode 窗口，再重新打开。不要只重开终端面板，因为扩展进程不会自动重新读取 PATH。
如果问题依旧，再看 PowerShell 执行策略是不是阻止了脚本运行。执行 Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 可以放宽当前用户的脚本执行权限，这也是官方文档里推荐的做法，不需要也不应该去动本机管理员权限。
4.3 账号与订阅层面的限制：别绕，换合法通道
有些团队账号会碰到 your organization has disabled claude subscription access for claude code 这类提示。看到这个信息时，第一反应不该是找怎么绕过限制，而是确认两件事：你的账号走的到底是订阅通道还是 API Key 计费通道？
如果团队策略禁用订阅访问但允许 API Key 计费，直接改用环境变量注入自己的 API Key，就能正常工作；如果连 API Key 通道也不允许，那就应该去找管理员确认团队规范，而不是私底下想办法绕开。这条线我建议你守得很清楚：模型能力再强，也不值得让你在账号合规上冒风险。
4.4 中文乱码、声音提示和其他“体验类”问题
Windows 下跑 Claude Code，偶尔会遇到输出中文乱码的问题。这通常不是 Claude Code 本身的问题，而是终端代码页和输出编码不一致。处理方式很直接：
powershell复制chcp 65001
这会把当前终端代码页切成 UTF-8。如果每次都要手动执行太麻烦，可以在 PowerShell profile 里预设。VSCode 用户可以在设置里把终端默认编码调整为 UTF-8，或者直接改用 Windows Terminal。顺便说一句，如果你的 Python 服务输出也乱码，还可以检查环境变量 PYTHONIOENCODING=utf-8，这能解决不少子进程输出乱码的情况。
至于有网友问“Claude Code 询问时会发出声音提示”，这其实是终端会话触发系统通知音的现象。如果你在专注编码时不希望被打扰，可以去系统声音设置里关闭终端通知音，或直接静音系统通知；不用因为这个去翻配置文件找奇奇怪怪的开关。工具是为专注服务的，声音打扰到你了就该优先处理掉。
4.5 长会话中断后如何找回历史
开发过程中我经常遇到这个问题：一个会话跑到一半，电脑重启或者我不小心关掉了终端，再打开后上下文没了。
Claude Code 本身支持会话恢复。你用 claude --continue 可以直接接续最近一次会话；用 claude --resume 则可以选择历史会话列表。这样即使终端窗口关闭，之前积累的上下文大概率还能找回来。
不过我也要提醒一句：别把会话历史当成团队知识库。命令行历史记录的容量和管理能力都有限，更有价值的做法是在会话结束时，把“这次改动为什么这么做”的关键结论写进项目里的 CLAUDE.md。这样即便历史找不回来，你的项目还留着一份可持续复用的上下文。
5. 把“省 token”和“团队规范”做成可持续的习惯
5.1 省 token 的核心不是选便宜模型，是控制被读入的代码量
很多人一想到省成本，第一反应是切到更便宜的模型。但在 Claude Code 的场景里，token 消耗的大头往往不在“生成回复”，而在“读取代码”。模型要理解你的项目，就必须把相关文件内容读进上下文，一次读一个大文件就是几千甚至上万 token。
所以真正有效的省 token 方法是控制它“看什么”。我前面说的仓库侦察阶段，本质上就是一种 token 管控手段：先让它看小文件、看目录结构、看关键函数的调用位置，确认哪些文件必须读全文，哪些只需要知道大概作用。把任务拆细，让每个阶段只加载当前必要的信息，比单纯换便宜模型有效得多。
还有一个小技巧：在指令里明确“只读与本次改动直接相关的模块，不需要扫描整个仓库”。如果你让它做一个 bug 修复，它是没有动机主动去读所有无关代码的，但你不说，它就缺少一个判断边界，容易在犹豫时把更多文件拖进来。
5.2 CLAUDE.md 是常驻记忆，省掉重复解释的时间
我每次用 /init 让 Claude Code 分析项目时，它都会生成一份 CLAUDE.md，里面记录项目结构、技术栈、常用命令和约定。这个文件最有用的一点是：它会作为项目背景随每次会话自动加载，等于给模型配置了一个“项目本地记忆”。
但生成完之后不能放着不管。我会持续维护它，把新获得的关键信息补进去。比如某个模块的架构决策、某个测试命令的特殊运行方式、某个常见的编译坑。这些东西与其放在个人笔记里，不如放进 CLAUDE.md，因为 Claude Code 每次开始新会话时都会读到，等于把我积累的项目经验复制给了每一轮新的 AI 会话。
维护得好的 CLAUDE.md，甚至比一堆设计文档还值钱。它不追求面面俱到，只记录“模型在这个项目里做事时最需要知道的东西”。
5.3 Skills：把团队规范从“口头要求”变成可调用的技能
随着 Claude Code 功能迭代，Skills 成了一个值得关注的能力。简单说，它允许你把一组规则和操作流程打包成一个“技能”，让模型在遇到对应场景时自动按这套流程走。
举个例子。你希望模型在提交代码前自动检查团队规范：运行 lint、检查提交信息格式、补文档。与其每次在 prompt 里复述一遍，不如把这些步骤拆成一份独立的 Skill。模型会识别到当前动作进入“提交检查”场景，然后自动按 Skill 定义的步骤操作。
Skill 文化和 CLAUDE.md 的区别可以这样理解：CLAUDE.md 是相对静态的“项目背景说明”，告诉你这个项目是什么，常用命令有哪些；Skill 是更接近动作流的东西，定义了“当用户要求 X 时，应该按步骤做 1、2、3”。
在做团队推广时，我建议优先把 CLAUDE.md 做好，再逐步沉淀少量高频使用的 Skill。规则太多会变成一个沉重的包袱，反而让轻量任务变得臃肿。好的规范应该让模型在关键场景里自动踩准节奏，而不是在每个细小动作上都插一条规矩。
5.4 其他让体验更顺的固定偏好
Claude Code 默认的回复语言比较随缘，跟 prompt 里的语言和项目文档语言相关。如果你希望它稳定用中文解释问题，可以把这条硬性要求写进项目级 CLAUDE.md 或用户级配置里，例如“默认用中文回复；输出代码时保留英文标识符；遇到错误时先给出复现命令再解释原因”。这样每个新会话都会自动遵守，不必每次手工交代。
同样的思路也适用于提交说明风格、变量命名偏好、注释语言等。凡是那些你在 code review 时总得反复强调的点，都值得固化成一段指令。它不会让模型变成完美的团队成员，但至少能帮你省掉大量重复纠正的口舌。
最近我还养成了一个习惯，如果当天会话里产生了重要的架构取舍，我会顺手花一两分钟把决策和原因写进 CLAUDE.md，然后第二天开始新任务时，就不再需要把前因后果重新解释一遍了。这算是我用 Claude Code 以来收获最大的一个小动作。工具本身能帮你跑得很快，但要让每一轮跑动都不在原地打转，靠的还是这些需要人主动维护的小习惯。