第一次把 Claude Code 接进日常开发的时候，我犯过一个特别蠢的错误：装完命令行工具就直接开干，用了整整一周还觉得它"有点笨"——不知道项目规范、记不住我交代过的事、偶尔还会自作主张改错文件。后来我才意识到，问题根本不在模型，而在配置。这套工具真正拉开体验差距的，是三大配置文件体系：settings.json、CLAUDE.md、memory。如果你也在研究 Claude Code，或者已经装上了但用得磕磕绊绊，这篇文章就是把这三样东西的底层逻辑、职责边界和实操细节一次讲透。
先说结论：settings.json 管"规矩"，CLAUDE.md 管"知识"，memory 管"记忆"。三者配合好了，Claude Code 才能从一个"什么都能干但什么都不懂"的通用工具，变成一个真正熟悉你项目和习惯的得力搭档。下面按顺序把这套体系拆开揉碎讲清楚。
1. 先搞懂三套配置的定位：一个"新员工入职"的比喻
1.1 三套配置到底各管什么
你可以把 Claude Code 想象成一个刚入职的资深工程师。能力很强，但对你这家"公司"一无所知，所以它需要三样东西才能进入状态。
settings.json 是"公司规章制度"。它规定这位员工能访问哪些资源、哪些操作必须提前请示、哪些命令永远禁用、什么时候需要触发外部脚本来做检查。对应到系统里，就是模型选择、权限控制、钩子脚本、环境变量这些硬规则。
CLAUDE.md 是"入职培训手册"。它告诉这位员工：咱们项目是干什么的、代码目录怎么组织、命名规范是什么、测试命令是什么、构建流程怎么走。一个认真读过手册的员工，不会反复问"测试怎么跑"这种蠢问题，也不会用一套通用习惯乱套你的项目。
memory 是"带教老师的小本本"。它记录这位员工在工作中不断积累的对你的了解：你喜欢函数式风格还是面向对象、你习惯的什么格式写 commit、你上次提到某个接口将来要重构。有了它，就算换了个新会话，他也还记得你是谁。
这三套配置缺一不可。没配 settings.json，他会乱动不该动的文件；没配 CLAUDE.md，他每次都要现场问背景；没配 memory，他永远记不住你的偏好，每次对话都是"最熟悉的陌生人"。
1.2 为什么要拆成三个体系而不是一个"总配置"
有人会问，把所有东西塞进一个文件里不是更省事吗？我的看法是，这三样东西的生命周期、敏感程度和修改频率完全不同，硬塞在一起只会互相拖累。
settings.json 属于"低频修改、高频生效"的规则，你一个月未必改一次，但它每天约束着所有会话的行为边界；CLAUDE.md 是"项目一有变化就要更新"的动态文档，代码结构调整、依赖变更、命令变动，它都要跟着改；memory 则是"随时可能追加"的个人积累，你可能在某个对话里突然说"以后都用 pnpm 来管理依赖"，这句话应该被记住，而不一定要写进团队共享的项目规范里。
把这三类信息分开存放，本质上是做职责分离。更关键的是安全问题：settings.json 里的权限规则直接决定了 Claude Code 能执行哪些命令、能读写哪些路径，这是安全边界；CLAUDE.md 是给模型读的项目资料，没有安全风险；memory 包含个人操作习惯，虽然不算敏感，但也不该和团队文件混在一起。三者混成一个文件，要么改起来畏手畏脚，要么权限形同虚设。
补充一个底层机制：Claude Code 加载配置是有明确顺序的。实际使用中最常见的情况是"用户级配置做兜底，项目级配置做定制"，如果两个文件里出现同一个配置项，项目级会覆盖用户级。这个优先级关系，我在后面的实操部分会用案例详细展开。
2. settings.json：给 Claude Code 立规矩的"职场守则"
2.1 三个作用域：先确认你到底在改哪个文件
我第一次配置时就踩了坑：随便在某个目录建了个 settings.json，改了发现没反应。后来才搞明白，settings.json 有三个常见位置，优先级和使用范围完全不同。
第一个是用户级配置，路径在~/.claude/settings.json。它对你机器上的所有项目生效，适合放通用规则和个人偏好，比如默认模型、全局禁用的危险命令、你的 API 接入配置。第二个是项目级配置，路径在项目根目录下的.claude/settings.json，只对当前项目生效，适合放项目特有的规则。第三个是本地个人配置，路径在.claude/settings.local.json，这个文件一般要写进.gitignore，因为它可能包含你个人的环境变量或临时调试配置，不应该提交到团队仓库。
这里最需要记住的规则是：配置优先级是 local > project > user，也就是更靠近当前项目的配置会覆盖更全局的配置。这句话写起来简单，实际排错时很容易碰一鼻子灰——你明明在用户级禁止了某个命令，项目级设置里却又放行了，结果 Claude Code 照样执行。出现这种"规则失灵"的情况，八成就是作用域覆盖搞混了。
还有一个团队协作的点：CLAUDE.md 和 settings.json 都可以放进团队仓库。如果你们团队统一使用 Claude Code，我强烈建议把项目级的.claude/settings.json和根目录的CLAUDE.md提交到 Git，这样所有同事拿到代码后自动拥有同一套规则，新人上手的成本会直线下降。
2.2 核心配置项拆解：从 model 到 hooks
先讲model。它指定 Claude Code 默认使用的模型，可以写成"model": "opus"、"model": "sonnet"这样的别名，也可以写成完整模型名。我的建议是别在项目文件里写死具体模型，因为团队里每个人的账号权限不同，硬编码会导致别人连不上或者费用异常。更稳妥的做法是把模型放到用户级配置里，或者通过环境变量ANTHROPIC_MODEL来控制。
再讲permissions，这是 settings.json 里最值得花时间的一块。它控制 Claude Code 在什么情况下可以直接干活、什么情况下必须征求你的意见。一个典型的结构长这样：
{ "permissions": { "allow": [ "Read", "Bash(npm run lint)", "Bash(git *)", "WebFetch(domain:developer.mozilla.org)" ], "deny": [ "Bash(rm -rf *)", "Bash(curl *)" ], "ask": [ "Write", "Edit" ] } }allow是放行，deny是拒绝，ask是每次都要询问。规则可以只写工具名，比如Read，也可以带参数匹配，比如Bash(git *)，甚至可以写正则表达式。这块是保护项目安全的生命线，我后面会专门用一个小节讲怎么配才既高效又安全。
然后是hooks（钩子系统），这是把 Claude Code 接入你现有工程化流程的关键。它允许你在特定事件发生时执行外部命令，常用事件有PreToolUse（工具调用前）、PostToolUse（工具调用后）、UserPromptSubmit（用户提交提示词时）、SessionStart（会话开始）等。配置示例：
{ "hooks": { "PreToolUse": [ { "matcher": "Edit", "hooks": [ { "type": "command", "command": "python3 /path/to/check_style.py $CLAUDE_FILE_PATHS" } ] } ] } }举个例子，你想在 Claude Code 每次自动改文件之前先跑一遍 ESLint 检查，就可以用这个钩子。我实际项目里用得最多的两个场景：一是在UserPromptSubmit阶段把用户输入记录到本地审计日志，方便事后追溯"当时我到底让它干了什么"；二是在PostToolUse阶段，在每次 Bash 命令执行后把输出存下来供复盘。钩子系统的学习曲线稍微陡一点，但一旦用起来，它能把 AI 工具和团队既有流程严密地缝合在一起。
最后是env字段，它用来给每个会话注入环境变量。有时候你的 Claude Code 需要访问某个私有 API，又不想写进系统的全局环境变量，就可以在这个字段里配置。注意一个坑：写在项目级env里的内容会被提交到 Git，如果里面有密钥，一定要放到.claude/settings.local.json里并加入.gitignore。密钥泄漏这种事，一次就够你吃一壶了。
2.3 权限配置实测：从"什么都问"到"放心放权"
刚用 Claude Code 的时候，我做的是"小白配置"：所有权限默认 ask，也就是它每做一步都来问你要不要继续。安全是安全了，但体验非常崩溃——写个代码改了七八个文件，每改一个都要确认一次，效率低到让人怀疑人生。
后来我换了一种策略，可以总结为：读操作全放行，写操作分级放行，危险操作一律拒绝。具体来说，Read、Glob、Grep这类只有读取能力、不会产生破坏的工具直接 allow；Write、Edit这类修改文件的操作保留 ask，但可以通过路径规则缩小范围，比如只编辑src/目录下的文件时免确认；Bash命令则按命令白名单放行，跑测试、构建、git 操作直接放行，rm -rf、curl 任意地址、sudo这类命令直接 deny。
配置看起来像这样：
{ "permissions": { "allow": [ "Read", "Glob", "Grep", "Bash(git *)", "Bash(npm run *)", "Bash(python3 -m pytest *)", "Edit(src/**)" ], "deny": [ "Bash(rm -rf *)", "Bash(.* curl .*)", "Bash(.* sudo .*)" ], "ask": [ "Write", "Edit", "Bash" ] } }这样一个配置下来，日常开发中 Claude Code 的自主度会提高很多，同时危险边界清晰。我的经验是，权限策略要"反向配置"：先把所有操作设为 ask，记录自己一周内重复确认过的操作，再把这些操作逐步挪进 allow 白名单。千万不要一上来就全盘放行，AI 有时候真的会脑补出你想不到的危险命令，比如为了"清理临时文件"直接执行rm -rf加通配符，这种事故在社区里并不少见。
提示：permissions 规则支持正则匹配，比如
"Bash(git commit.*)"，但写正则时要小心边界。"Bash(git.*)"这种宽匹配看起来方便，实际上git push --force也会被放行。想让"允许 git 操作"这个想法安全落地，最好配合 deny 规则做重点拦截。
3. CLAUDE.md：让 AI 真正"懂"你的项目
3.1 加载机制：为什么它放在项目根目录最稳
CLAUDE.md 是一个纯文本文件，放的位置不同，作用范围也不同。项目根目录下的CLAUDE.md只要在这个目录里启动 Claude Code，它就会自动作为上下文的一部分加载；用户目录下的~/.claude/CLAUDE.md则对所有项目生效，通常用来存通用的编码偏好和个人说明。
这里有一个常见误区：把文件放到.claude/目录里，以为能被加载。实际上，Claude Code 加载的是项目根目录的CLAUDE.md，以及通过@指令引用的外部文件。.claude/CLAUDE.md这个位置并不在默认加载范围内。团队如果要统一维护，建议放在根部，或显式用@路径引用。
另一个要点是：CLAUDE.md 是在会话开始时就加载的，不是你想要的时候才调出来。也就是说，你在这个文件里写什么，相当于每轮对话都带着这部分上下文。写完代码、修完 bug，记得随手更新这个文件，否则它会像一份过期的地图，越往后越有误导性。
3.2 一个高效 CLAUDE.md 的写作结构与避坑
很多人把 CLAUDE.md 当成备忘录，啥都往里写，结果文件越来越长，模型上下文被大量占用，反而显得"变笨"。我建议用类似下面的结构来组织：
# 项目概述 一句话说清楚项目做什么、当前处于什么阶段。 # 技术栈与目录结构 - 前端：React 18 + TypeScript + Vite - 后端：Python FastAPI + PostgreSQL - 关键目录说明：src/ 为源码，scripts/ 为一次性脚本 # 常用命令 - 安装依赖：pnpm install - 本地开发：pnpm dev - 测试：pnpm test - 构建：pnpm build # 代码规范 - 提交信息使用 Conventional Commits 规范 - 组件文件名使用 PascalCase - 禁止在业务代码中写 TODO/FIXME # 架构约定 - API 层统一走 /api/v1 前缀 - 状态管理只使用 Zustand，不使用 Redux # 已知事项 - 数据库迁移脚本统一放在 scripts/migrations 目录下 - 线上环境由 CI 自动部署，不要手动操作服务器这个结构的核心是"信息密度高、篇幅短"。能一行说清的绝不用三段话；能用列表的不用大段叙述。CLAUDE.md 本质上不是给人读的文档，它是给模型吃的高压缩背景资料。我会把"背景故事、历史原因"这类内容尽量删掉，只保留模型真正需要的事实性信息。
关于语气也有讲究。Claude Code 对文件内容是"照单全收"的，你写的每个"不要"它都会当规则处理。所以我习惯用祈使句，比如"必须使用 pnpm"、"不要在业务代码中写入 TODO"，而不是"我们通常会用 pnpm"这种模糊表达。模糊的语气会让模型自己发挥，结果就是它猜的规范和实际项目偏差很大。
还有一个容易忽略的细节：CLAUDE.md 里可以写"给 Claude 的话"。比如"当你修改这个模块时，注意同步更新__init__.py中的导出列表"，模型会在修改模块时真的顺带处理相关文件。这种"连坐式提醒"比在代码里写注释管用得多，因为它直接作用于模型的行事流程。
3.3 用 @ 引用拆文件：大项目怎么维护
项目一旦变大，CLAUDE.md 很容易膨胀到几千行。这时候硬塞在一个文件里，加载效率和更新体验都不好。Claude Code 支持在 CLAUDE.md 中用@路径的方式引用其他文件，比如：
# 项目概述 这是一个电商中台系统，核心模块说明见 @docs/architecture.md # API 规范 详细接口规范请见 @docs/api-conventions.md被@引用的文件会自动作为上下文的一部分加载。我的实践是：主 CLAUDE.md 保持精简，只放项目最核心的信息；把不同领域的细节拆到 docs 目录里，按需引用。这样其实等于做了一个小型知识库，模型每次自动加载的是"总纲 + 被引用的专题"，而不是一坨全量文本。
这个做法尤其适合团队协作。后端同学维护api-conventions.md，前端同学维护frontend-guidelines.md，每人只改自己负责的文件，既能减少冲突，又能提高文档的及时性。我见过不少团队把 CLAUDE.md 当成"AI 使用规范"来评审，这个思路是对的，但千万别变成文档民主化，最后写出一堆谁都不看的表面文章。好的 CLAUDE.md 是给模型省 token 的，不是给自己省事的。
4. Memory：Claude Code 的"长期记忆"到底存在哪
4.1 记忆的三层结构
Memory 是很多人最容易忽略、也是我觉得三套体系里"后劲最大"的一块。它本质上是让 Claude Code 记住"你是谁、你怎么工作"的机制，分三个层次。
第一层是用户级记忆，默认存放在~/.claude/CLAUDE.md。注意，这个名字跟你项目里的 CLAUDE.md 一样，但作用域完全不同。用户级记忆负责记录你的通用偏好，比如"默认使用 pnpm"、"函数命名用动词开头"、"不喜欢堆砌注释"这类跨项目通用规则。
第二层是项目级记忆，就是我们上一章讲的项目根目录CLAUDE.md，它记录的是"这个项目"相关的约定和状态。
第三层是会话内上下文，它不落盘，只存在于当次对话中。你每轮对话的交流、你纠正模型的语句、AI 得出的结论，都会影响本轮后续输出，但换了新会话就丢了。
这三层的关系可以用一个比喻来理解：会话上下文是"工作台"，项目记忆是"项目档案"，用户级记忆是"个人档案"。Claude Code 每次开启会话，会把后两者加载到工作台上，然后在这一轮的交流里持续修正和补充。优先级对应也很清晰：具体项目的规则优先于通用偏好，但即时对话里的明确指令，往往又高于一切文件规则——毕竟你每句话都是最新指令。
4.2 如何主动写入与查询记忆
记忆不全是自动的。你有没有遇到过这种情况：某天顺手告诉 Claude Code "这个接口将来可能要迁移到 v2"，过了几天开新会话，它完全想不起来。原因很简单，它没记，或者记了但优先级不对。
主动管理记忆最直接的方法，就是编辑~/.claude/CLAUDE.md这个文件。你想让它记住的事情，直接写进去。比如你常用 Python 写脚本，希望它默认用python3 -m pytest跑测试，那就在这个文件里加一行规则。每个新会话加载时，它都会看到，这就够了。
在对话里也可以直接说"记住：以后默认使用 pnpm 安装依赖"，Claude Code 会主动重写记忆文件，把这条规则加进去。在我的使用经验里，这类操作通常会有确认反馈，你看一眼改动再放行，比自己动手编辑更省心。不过需要特别注意的是，它并非类似会话持续记忆那种自动语义记忆，而是基于文件的结构化记忆。所以既有的记忆文件要定期整理，否则一堆互相冲突的规则会让模型行为变得不可预测。
还有一个快捷入口是/memory这样的斜杠命令。你可以用它查看当前可用的记忆文件路径和内容摘要，也可以直接跳转编辑。具体命令名在不同版本里略有差异，最稳妥的方式是敲/help看看当前版本支持哪些记忆相关指令。这个习惯和我最开始说的"CLAUDE.md 要随项目更新"一样，都属于配置体系的日常运营，容易被忽略，但影响极大。
4.3 记忆维护：避免遗忘和冲突
记忆文件用久了一定会乱，常见问题有两个：一是规则矛盾，二是内容过时。
规则矛盾的典型案例：全局记忆里写着"优先使用 TypeScript"，而某个项目的 CLAUDE.md 写着"本项目为纯 JavaScript，不要引入 TypeScript"。如果两边都加载，模型就会困惑，行为表现为：一会听项目的话，一会又按全局偏好强行推荐 TS。解决办法是统一优先级表达，在处理项目相关任务时让项目级文件用更强硬的措辞，比如"必须使用 JavaScript，禁止引入 TypeScript 相关依赖"。
内容过时也很好理解：你的项目三个月前把构建工具从 Webpack 换成了 Vite，但 CLAUDE.md 忘了更新，模型就会坚定不移地建议你执行npm run build:webpack。所以我把 CLAUDE.md 和项目级记忆纳入日常维护清单，每次大版本切换或架构调整时，顺手打开文件同步改一遍。这个习惯看起来琐碎，但对 AI 工具体验的提升是立竿见影的——因为你省去了每次对话里纠正它错误的成本，这些成本攒起来非常可观。
5. 三套配置协同实战：一次完整的项目落地
5.1 场景设定与目标
纸上谈兵聊到这里，接下来用一个实际场景演示三套配置怎么协同工作。假设我现在接手了一个小型 API 服务项目，技术栈是 FastAPI + SQLModel，前端是一个简单的静态页面。我希望 Claude Code 能做到三件事：
第一，安全地帮我做代码修改，不要未经确认就重写整个文件；第二，每次跑测试都用我指定的命令；第三，记住我个人的开发习惯，比如提交代码喜欢用 Conventional Commits、函数命名喜欢用动词开头。这三件事，恰好对应 permissions、CLAUDE.md、memory 三个体系的职责。
5.2 完整配置展示与逐项解释
先看项目级.claude/settings.json：
{ "model": "sonnet", "permissions": { "allow": [ "Read", "Glob", "Grep", "Edit(src/**)", "Bash(git *)", "Bash(python3 -m pytest *)", "Bash(uvicorn *)" ], "deny": [ "Bash(rm -rf *)", "Bash(.* sudo .*)", "Bash(.* curl .*)" ], "ask": [ "Write", "Edit", "Bash" ] } }Edit(src/**)这一条是整份配置的精华。它表示修改src目录下的代码文件时不需要逐次询问，但写新文件（Write）或改src以外的内容（比如动了requirements.txt）仍然要确认。这样日常迭代会很流畅，而它想碰依赖清单这种"敏感区域"时，我还能把住最后一道闸。
再看项目根目录CLAUDE.md：
# 项目说明 FastAPI 提供任务管理 API，使用 SQLModel 存储数据，前端为静态页面。 # 常用命令 - 安装依赖：pip install -r requirements.txt - 启动服务：uvicorn app.main:app --reload - 跑测试：python3 -m pytest - 数据库初始化：python3 scripts/init_db.py # 代码约定 - 路由文件集中在 app/api/ 目录，一个模块一个路由文件 - 数据模型放 app/models/，统一使用 SQLModel - 函数命名使用动词开头，如 get_task_list - 禁止在路由函数中直接写 SQL # 修改注意 - 修改数据模型后必须同步更新数据库迁移文件 - 新增路由时，记得在 app/api/__init__.py 注册这份文件控制在 20 行左右，信息密度很高。模型拿到它之后，跑测试不会乱敲pytest，而是会执行python3 -m pytest；新增路由时它也会自动想到去注册。这就是 CLAUDE.md 的意义：把项目里"人尽皆知但没人写下来的规矩"变成模型必读的入职手册。
然后是用户级~/.claude/CLAUDE.md（即用户级记忆）：
# 全局偏好 - 工具默认优先使用命令行方式，不使用 GUI - 提交信息遵循 Conventional Commits 规范 - 代码注释使用中文，保持简洁 - 遇到不明确的需求，先列出可选方案再实施，不要直接动手这份文件的价值在我换项目时特别明显。我换了三四个仓库，每个项目的 CLAUDE.md 各不相同，但用户级记忆提供的个人偏好始终生效。特别是"先列方案再实施"这一条，让协作模式稳定成了"它先出方案，我确认后它再动手"，这种节奏一旦建立，工作效率的提升是质的飞跃。
5.3 落地效果与调优思路
配置完之后，我实测了一个简单需求：让它给 API 增加一个"标记任务已完成"的接口。它的行为是：先读app/api/下的路由文件和app/models/下的模型定义，然后按照约定新增路由函数mark_task_done，主动更新app/api/__init__.py，最后提醒我运行python3 -m pytest验证。整个过程没有问任何无关问题，也没有乱装依赖。
这中间如果哪一步踩线，比如想直接执行pip install新包，权限配置会拦住它并发起确认。这个表现基本达到我最初的设想：权限管边界，CLAUDE.md 管项目知识，memory 管个人习惯，三层各司其职。如果之后发现某些场景下它还"不够懂"，优先看对应层级的配置是否覆盖到，而不是急着换模型或重新教一遍。配置调优是一个渐进过程，每次对话中的纠正都在给你提供素材。
6. 常见问题与排查技巧
6.1 settings.json 不生效怎么办
最常见的原因无非三种：改错了文件、放错了位置、配置文件本身有语法错误。先说文件位置，记住三个作用域和优先级：local 覆盖 project、project 覆盖 user。你改了用户级配置，项目里刚好也有同名规则，那以项目为准。排查时先确认当前会话到底加载了哪些配置文件，再看你改的那个文件是否在加载列表里。
其次是 JSON 语法。settings.json 严格遵循 JSON 格式，多一个逗号、少一个引号都会导致整个文件解析失败。我踩过的坑是手写 JSON 时习惯性地在最后一个键值对后面加逗号，Claude Code 会直接忽略整个文件，而且不一定给你报错提示。建议写完配置后用任意 JSON 校验工具过一遍。
最后是缓存问题。部分场景下 Claude Code 会缓存配置，修改后需要重启会话甚至重启进程。如果你改了配置没反应，先重启会话试试，别急着怀疑人生。这三个排查方向按顺序走下来，基本能覆盖九成以上的"改配置不生效"问题。
6.2 CLAUDE.md 太长导致"变笨"怎么处理
很多人的 CLAUDE.md 会越写越长，最后模型的表现反而变差。原因在于过量的低信息密度文本占用了上下文窗口，模型处理关键规则时的注意力被稀释。判断标准很简单：如果模型开始频繁复述文件里无关紧要的内容，或者明明文件里有明确规则却不遵守，大概率就是这个文件已经"膨胀"了。
我的处理方式是定期"瘦身"：把 CLAUDE.md 里的背景叙述、历史记录、解释性文字删掉，只保留规则、命令、事实性信息；长时间不变的内容挪到@引用的附属文档里；临时的、会过期的信息不要写进 CLAUDE.md，放在当次会话里交代即可。如果一定要保留详细文档，就把它放到被引用的子文件里，让主文件保持精炼。这个习惯和代码重构里的"小函数、高内聚"是一个道理，文件职责单一，模型才可能精准发挥。
6.3 全局记忆与项目规则冲突的排查
如果你发现 Claude Code 同时加载了~/.claude/CLAUDE.md和项目里的 CLAUDE.md，但两者矛盾时行为飘忽不定，那就是典型的"规则打架"。排查步骤：先打开两个文件，对照看有没有同一事物的不同表述；然后给项目级文件的语句改成优先级更高的强表达，比如"本项目的依赖安装命令一律使用 pnpm，禁止使用 npm"；最后在全局记忆里也删掉可能引起冲突的规则，避免干扰其他项目。这类排查没有捷径，只能靠定期审视记忆文件来预防。
6.4 Windows 与 VSCode 场景下的补充提醒
如果你在 Windows 上使用 Claude Code，有几个和配置相关的细节值得注意。第一个是路径写法，配置文件里涉及路径的命令，最好统一使用正斜杠或双反斜杠，否则部分 shell 场景会解析异常。第二个是 hooks 里的命令，不同 shell 环境下可执行文件的解析方式不一样，我建议在 hooks 里写的命令尽量简单，复杂逻辑放到独立脚本里再调用。
如果你用的是 VSCode 插件方式接入 Claude Code，配置体系完全相同，只是要注意配置文件的位置依然以项目根目录为准。VSCode 插件的集成偶尔会带来环境变量不一致的问题，比如终端里明明配置好了ANTHROPIC_API_KEY，插件却提示缺密钥。这种场景把环境变量显式写进配置文件的env字段是最省心的解决办法。
最后补充一个进阶用法：想接入本地模型服务或公司内部的兼容网关时，可以通过配置ANTHROPIC_BASE_URL指向目标端点，settings.json 里的model字段就填目标服务支持的模型名。配置本身不复杂，复杂的是弄清目标端点的能力边界，建议先在一个小项目里验证通了，再推广到日常使用。
我个人折腾下来最大的体会是：配置这件事，最难的不是某个参数不会写，而是搞不清楚"该把信息放在哪一层"。早期我把所有规则全堆进 CLAUDE.md，文件写了三四百行，模型却越用越笨；后来逐步把通用偏好挪到用户级记忆、项目规则精简进项目级 CLAUDE.md、危险操作交给 permissions，才真正体会到"配置体系"四个字的分量。如果你现在刚接触 Claude Code，别想着一步到位，先用一个真实需求跑通三套配置的配合流程，再根据实际对话里的纠正慢慢调。settings.json 是底线，CLAUDE.md 是起点，memory 是长期积累，顺序不能乱，耐心不能少。等这套体系运转起来，你会发现它值回所有投入的配置时间。
