企业官网建设流程全解析

我见过太多人安装完 Claude Code 之后的第一个动作，就是打开settings.json把模型改成自己想要的，然后噼里啪啦写一堆CLAUDE.md塞进项目根目录，最后发现 AI 的行为几乎没什么变化——不是配置没生效，而是你把三套完全不同的配置体系混在一起用了。

Claude Code 的配置体系实际上分成三块：settings.json、CLAUDE.md和memory。它们各自负责不同层级的东西，加载时机不同、优先级不同、覆盖逻辑也不同。大多数教程只教你某个键怎么填，却很少讲清楚这三者之间的关系。这篇东西我想从"配置体系"的角度，把这三套东西拆开揉碎，讲明白每套配置解决什么问题、什么场景该用哪一套、以及它们之间是怎么协作的。适合刚上手 Claude Code 的开发者，也适合已经把配置写得乱七八糟、想重新梳理一遍的人。

1. 为什么是"三套配置"而不是一个设置面板

1.1 一套配置解决不了的事

Claude Code 是一个跑在终端里的编码代理，它需要同时处理三种完全不同的信息：

1. 它运行在一个什么样的环境里——用什么模型、什么权限、连接哪些外部工具、跑什么钩子脚本。这是运行环境的信息。
2. 它服务的这个项目是什么——技术栈、目录结构、编码规范、构建命令、哪些事绝对不能再碰。这是领域知识的信息。
3. 它协作的人是谁——你的习惯、偏好、常用工作流、历史决策。这是长期记忆的信息。

这三种信息的生命周期完全不同。运行环境基本不变，项目信息跟着项目走，个人偏好跟着你走。如果你把它们全塞进一个配置文件，那这个文件要么在被项目共享时泄漏个人偏好，要么在换项目时带着一堆无关配置，要么在你想调模型的时候还得小心翼翼不敢动别的东西。

所以我一直把三套配置理解成三个不同的槽位：settings.json是机器参数，CLAUDE.md是项目说明书，memory是协作记忆。它们的分工是天然形成的，不是设计上多余的。理解了这一点，你再看那些教你"把 .claude 配置扔进仓库"之类的操作，就会明白问题出在哪。

1.2 用系统设置、项目说明书、工作记忆来理解三者的分工

如果非要打个比方：

• settings.json相当于一台设备的系统设置。它决定了软件以什么身份运行、能调用什么权限、有什么外设、有什么自动化脚本。这是机器层面的东西——你换一个项目，这台机器的设置照旧生效。
• CLAUDE.md相当于放在工位上的项目操作手册。手册上写着这个项目的特殊规则：别动哪个文件、用什么命令构建、代码风格是什么。手册跟着项目走，换机器、换人都得带上。
• memory相当于你对这个 AI 助手的长期协作记忆。它记得你说过自己喜欢什么、不喜欢什么，记得上次你是怎么做某件事的。它不写在操作手册里，但确实在协作中影响行为。

这个类比解释了为什么三套配置的修改方式不同：settings.json是一个结构化 JSON 文件，改了重启就生效；CLAUDE.md是自然语言文档，需要重新加载才触发；memory则是对话过程中持续写入的，需要明确命令或专门管理才会删掉或修改。

很多人踩的坑就是把三者混用。比如在CLAUDE.md里写"请使用某个模型"——这基本没用，因为模型选择是settings.json的职责。又比如在settings.json里写一大堆项目规范——这会让这些规范跟着你所有项目跑，反而造成全局污染。搞清楚边界之后，很多配置问题其实就迎刃而解了。

2. settings.json：决定"机器怎么跑"的全局配置文件

2.1 文件位置与优先级

settings.json不是放在项目根目录下那个大文件名的，而是放在.claude目录里。我实际用下来，至少会有三个层级：

• 用户级：~/.claude/settings.json，对所有项目生效。放默认模型、全局权限、常用环境变量。
• 项目级：<项目根>/.claude/settings.json，只对这个项目生效。适合覆盖用户级配置——比如这个项目必须用某个特定模型，或者单独开放某些命令权限。
• 项目级本地配置：<项目根>/.claude/settings.local.json，这个文件通常应该加入.gitignore，放你个人在这台机器上的临时调整，不提交给团队。

和很多 IDE 的用户设置、项目设置、工作区设置三层结构类似，优先级上，最具体的覆盖最通用的：项目级覆盖用户级，settings.local.json再覆盖项目级settings.json。

最典型的使用场景是：团队仓库里提交一个.claude/settings.json，规定所有人在这个项目里必须用同一种模型、开启某些检查钩子；你个人的~/.claude/settings.json不用跟着仓库走，里面是你的偏好。这样你克隆别人项目时，本地配置不会干扰项目的统一配置，反过来项目配置也不会污染你的其他项目。

2.2 核心配置键逐个拆解

不同版本的 Claude Code 在配置键名和默认值上会有一些差异，以官方文档为准。但有几个键是相对稳定的，我几乎每个项目都会用到：

1. model：指定默认模型。这个键主要控制主对话使用的模型。我一般不会在用户级设置里写死模型，而是在 CLI 交互时选择；在项目级设置里才固定模型，保证团队一致性。

2. permissions：权限控制。这是最值得花时间研究的键。它通常包含几个子数组，比如允许自动执行的工具、禁止执行的工具与命令、执行前需要询问的项。你可以让 Claude Code 自动跑测试脚本，但绝不能让rm -rf /这种命令偷偷执行。

3. env：注入环境变量。比如给某个项目设置专用的 API Key、配置模型名称，或者注入一些供构建脚本读取的变量，避免每次启动前手动 export。

4. hooks：钩子。它可以在特定事件发生时自动运行外部脚本，比如消息发送前检查敏感信息、工具调用后自动格式化代码。hooks 的配置是事件驱动的，比权限模型更灵活。

5. includeCoAuthoredBy：布尔值，控制是否在生成代码时自动附加 Co-Authored-By 署名。团队协作相关的仓库常会用到。

6. mcpServers：MCP 服务器配置。相当于外挂插件，让 Claude Code 能主动调用外部服务的工具，比如 GitHub、数据库、浏览器等。

我建议的策略是：用户级settings.json尽量精简，项目级settings.json才放团队约束。配置文件越多，排查越难，这是我在多个项目里踩出来的经验。一个几百行的全局配置，带来的价值不一定比一个十几行的配置高，反而让每次排查"为什么行为不对"都变得痛苦。

2.3 权限系统与 hooks：让自动化处于可控状态

权限系统是settings.json里看起来最啰嗦、实际上最救命的部分。没有权限控制时，Claude Code 默认会在执行可能影响系统的命令前询问你，这既打断自动化流程，也可能在你不注意时造成误操作。

我举个例子：你希望它跑npm run build时不要每次问你，但绝对不希望它自己执行git push。那项目级 settings.json 里可以写类似这样的配置（示意，具体键名以版本为准）：

{ "permissions": { "allow": ["Read", "Edit", "Bash(npm run build)", "Bash(npm test)"], "deny": ["Bash(git push)", "Bash(rm -rf *)"] } }

这里Read和Edit是文件读写类工具的基础权限；Bash(...)里的模式匹配用的是类似 glob 的语法，支持按命令前缀精确控制。配好之后，Claude Code 在执行命令时会更果断，而你不希望出现的危险操作会被这层规则拦下。

hooks 则是权限的补充——权限管能不能做，hooks 管事件发生时自动做什么。比如我配置过一个工具调用前的钩子，在 Claude 即将执行 Shell 命令前抓一下命令内容，如果发现命令里带.env就把命令内容发给我确认，相当于给高危操作加了一层自定义守卫。这类事件驱动的自动化，在纯权限模型里做不到，需要 hooks 来完成。

我自己常用的 hooks 事件有这几个：

• PreToolUse：某个工具被调用前触发，可以修改或阻止调用。
• PostToolUse：工具调用完成后触发，适合自动格式化、自动补注释。
• UserPromptSubmit：用户提交提示词后触发，适合做输入审计或注入额外上下文。
• Notification：Claude 发送通知时触发，适合接自己的提醒系统。

hooks 里的脚本可以用 bash、node、python 等任意可执行环境，只要你在配置里写好启动命令。要注意一个细节：hook 脚本本身执行时会不会再次触发 hook？大部分情况下官方设计避免了死循环，但我写 hook 时还是会在脚本开头加一个环境变量守卫，防止意外递归。

2.4 环境变量与 MCP 服务器配置

很多人以为环境变量只能在 shell 里export，其实settings.json的env键可以直接注入给 Claude Code 进程。典型用法：

{ "env": { "SOME_PROJECT_TOKEN": "value", "SMALL_MODEL_NAME": "fast-model" } }

这里提醒一个坑：settings.json里的 env 是在 Claude Code 启动时读取的。如果你中途修改再继续对话，不一定立即生效。改完环境变量后，最稳妥的做法是重启 Claude Code 会话，而不是指望热加载。

MCP 服务器配置有两种常见方式。第一种是命令行方式，执行claude mcp add之类命令手动添加，适合快速尝试。第二种是配置文件方式，在settings.json的mcpServers键里定义，适合团队共享和版本管理。比如：

{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] } } }

我在实际使用中的体会是：MCP 服务器不要贪多。每挂一个服务器，Claude 就要多加载一堆工具定义，这些工具声明本身会占用上下文窗口，反而影响核心编码任务的性能。只挂你真正会高频用到的服务，其他临时需求用命令行工具解决就好。一个配置了十个 MCP 的项目，Claude 可能光理解工具就耗费了不少精力，编码质量反而下降，这是很多人没意识到的问题。

3. CLAUDE.md：让 AI 从"聪明"变成"懂你"的项目说明书

3.1 CLAUDE.md 的加载机制：不是"读一次就完事"

CLAUDE.md是项目根目录下一个用自然语言写的 Markdown 文件。它的作用不是配置行为参数，而是给 Claude Code 提供关于这个项目的背景知识。比如：

• 这个项目是什么、用什么技术栈
• 目录结构有什么讲究
• 构建和测试命令是什么
• 代码风格规则，命名、格式化、文件组织
• 哪些目录是自动生成的，不要手动改
• 部署流程和常见注意事项

它的加载机制和普通文档不一样。Claude Code 在启动会话时会读取相关的 CLAUDE.md 内容，把项目背景注入到上下文里，相当于让 AI 先读一遍项目说明书再开始干活。这带来几个实际影响：

1. 文件内容越精炼越好，因为每个 token 都在消耗上下文窗口。
2. 修改 CLAUDE.md 后新对话会生效；但当前进行中的对话可能还停留在旧上下文里。想刷新当前对话，一般需要重启会话或用压缩命令整理上下文。
3. 子目录里的 CLAUDE.md 也会被加载，不过通常是在涉及该目录下的文件时加载，不是整个仓库所有说明文件全部塞进来。

3.2 全局 CLAUDE.md 与项目级 CLAUDE.md 的关系

~/.claude/CLAUDE.md是你全局的个人说明书，放的是所有项目通用的偏好和习惯。比如"我习惯用 2 空格缩进""提交信息用动词开头""先写测试再写实现"之类的稳定偏好。它相当于跨项目的协作偏好设定。

项目根目录的CLAUDE.md则只服务这个项目。两者加载时都会进入上下文，全局的和项目的都会生效。我在实践中的处理原则是：

• 全局CLAUDE.md只写关于"我怎么协作"的稳定偏好，不写具体技术栈。
• 项目CLAUDE.md只写这个项目的客观事实和规则，不写个人偏好。

这种分离非常有用。你换了新项目，全局说明书里关于你的偏好仍然适用；项目说明书则跟着仓库走，团队所有人共享。如果两者写混了，就会出现一种尴尬场面：你的个人偏好进了项目仓库，同事克隆下来后 AI 的行为完全不符合他们的预期，而你根本不知道问题出在哪个文件里。

3.3 好的 CLAUDE.md 长什么样：结构模板与内容取舍

我见过的质量差的 CLAUDE.md 绝大多数是废话堆砌。写一堆"你是一个专业的编程助手"这种对 AI 毫无用处的开场白，或者把整个 README 复制进来，都是常见错误。真正有用的 CLAUDE.md 应该信息密度大、规则明确、可以直接对照执行。

我给一个我常用的结构模板（根据你的项目替换内容）：

# 项目规范 ## 技术栈 - 前端: React + TypeScript + Vite - 后端: Node.js + Express - 测试: Vitest ## 目录结构 - src/ 源码 - src/components/ UI 组件，每个组件一个目录 - generated/ 自动生成代码，不要手动修改 ## 常用命令 - 安装依赖: npm install - 启动开发: npm run dev - 测试: npm test - 构建: npm run build ## 编码约定 - 函数命名用动词开头 - 组件使用函数式组件，不接受 class 组件 - 禁止直接修改 generated/ 下的文件，应修改生成脚本 ## 注意事项 - 修改 API 时要同步更新 docs/api.md - 不要提交 .env 文件 - 数据库迁移必须写回滚脚本

这个模板的好处是每个条目都可以被 AI 直接执行或检查，而不是模糊的方向性建议。比如"禁止直接修改 generated/ 下的文件"比"请小心处理生成文件"有效得多。规则越具体，AI 的遵守率越高。

3.4 用 @路径 引用补全文件，避免说明书膨胀

CLAUDE.md 最常见的维护问题就是越来越长。一开始写技术栈、命令，后来加上页面结构、API 说明、部署手册，最后整个文件几百行，每次启动会话都吃掉几千 token，说明书的维护成本也直线上升。

解决办法是引用外部文件的语法：在 CLAUDE.md 里可以用@路径把其他文件的内容引入。比如：

## 目录结构 @docs/architecture.md ## 编码约定 @docs/code-style.md

这样 CLAUDE.md 本身保持精简，需要细节时按需加载。不同版本对@引用的处理方式可能略有不同——有的是直接读取文件内容纳入上下文，有的只是提示 Claude 需要时再自行读取。我自己的经验是，在引用语句里写清楚"需要做什么的时候，再读取这个文件"，效果更可控。

如果你的项目说明确实很大，我的建议是在 CLAUDE.md 里只保留索引和最关键的一两条规则，把细节拆到docs/下面的独立文件。给 Claude 的上下文窗口留出余量给真正的任务，比把每个细节都塞进说明书里要有用得多。一个能在 20 秒内读完的项目说明书，比一个 2000 行的百科全书更可能被 AI 完整遵守。

4. memory 系统：从会话记忆到长期协作记忆

4.1 memory 是什么：它和 CLAUDE.md 的区别

memory 是 Claude Code 在协作过程中自动积累的关于你和项目的偏好记忆。它和 CLAUDE.md 最大的区别在于：CLAUDE.md 是你主动编写的文档，memory 是系统在对话过程中动态写入的。

举个例子：你和 Claude Code 说"以后提交信息都用动词开头"。如果它在对话中记住了这个偏好，之后你提交代码时，它就会自动按这个风格写提交信息，不需要你在每条对话里重复提。这种记忆是自动积累的——它在你对话和操作中抓取你的偏好，写入记忆层。

和 CLAUDE.md 相比，memory 的写入门槛低得多。你不需要专门编辑文件，说你希望记住什么就行。但低门槛也意味着低可控性——你未必知道它记住了什么，什么时候记住了，什么时候又忘了。

4.2 记忆怎么查看与管理

实际使用中，可以用斜杠命令打开记忆管理界面：/memory。它会显示当前会话中的记忆使用情况、记忆条目的内容，让你查看更详细的信息。

另外 Claude Code 提供两个直接的控制指令：

• 记得（remember）：显式让 Claude 记住某事。比如"记得我在这个项目里习惯用 pnpm 而不是 npm"，它会把这条写入长期记忆。
• 遗忘（forget）：让 Claude 遗忘某个记忆条目。比如"遗忘'用 pnpm'这条"，之后这条记忆不再生效。

这里有个容易被忽视的点：显式记忆指令写入的内容，是跨会话生效的长期记忆，不只是当前会话的临时记忆。这意味着你可以在任何项目里用/memory来管理长期记忆。真正重要的规则，最好显式地让它记住，而不要指望对话中顺嘴一提就会被长期保留。

4.3 什么时候记忆会被压缩或丢失

Claude Code 有自动压缩机制。当上下文接近上限时，系统会自动压缩较旧的部分对话，保留核心信息。在这个过程中，压缩后的上下文会保留关键记忆和最近的操作摘要，但过于细节的中间过程可能被丢弃。

我见过很多人以为"说了就永远记住了"。结果在一个很长的上下文里工作到一半，AI 突然忘了关键事实，前期讨论的结论仿佛没存在过。这类问题其实不是 bug，而是记忆机制的正常行为：对话是短期工作记忆，显式 memory 指令写入的才是跨会话的稳定长期记忆。所以对于真正重要的规则，我会同时写进 CLAUDE.md 或显式用记忆指令固化，而不是只在对话里提一句。

另外要注意，自动压缩发生后，你可以主动检查/memory看当前的记忆状态。如果发现关键信息没了，补一下就行。这就像人一样，重要的事要写进日程本，只靠脑子记早晚会忘。

4.4 什么该进 memory，什么该进 CLAUDE.md

这是配置体系中最容易搞混的部分。我的划分原则非常简单：

• 进 CLAUDE.md：项目的客观事实、团队共享规则。因为它跟着仓库走，团队所有人都能受益。
• 进 memory：你个人的协作偏好、跨项目的习惯。因为它跟着你走，换项目仍然有效。
• 都不进：临时任务细节、一次性上下文。这些本来就会随会话结束消失，不需要专门管理。

比如"这个项目禁止修改 generated 目录"应该进项目 CLAUDE.md，"我提交代码喜欢用简短一句话"应该进全局 CLAUDE.md 或记忆，"本次要把登录页 bug 修了"基本不进配置体系。

这样划分之后，你会发现配置体系的维护成本显著降低。项目规则不会因为你在另一个项目里的个人偏好而被污染，个人偏好也不会被不小心提交到团队仓库。如果一条配置你反复在两个项目里各来一遍，那就是它在提醒你：这条应该进全局层。

5. 三套配置如何协作：优先级、加载顺序与最佳实践

5.1 我实测的加载顺序与覆盖逻辑

结合我这段时间的使用，Claude Code 在启动一个会话时，大致会经历这样一个加载过程（不同版本可能有差异，以实际观察为准）：

1. 读取用户级~/.claude/settings.json，确定运行环境、默认模型、全局权限与 hooks。
2. 读取项目级.claude/settings.json，用更具体的配置覆盖或补充用户级配置。
3. 加载全局CLAUDE.md（~/.claude/CLAUDE.md）中的个人通用偏好。
4. 加载项目根目录的CLAUDE.md，注入项目说明。
5. 如果会话中涉及某个子目录，而该子目录下存在CLAUDE.md，再按需加载。
6. 从 memory 中恢复之前积累的长期记忆。

这六个步骤里，前两步是"环境参数"，中间两步是"项目说明书"，最后一步是"协作记忆"。覆盖逻辑上，同一类配置之间有优先级（settings 是项目覆盖用户，CLAUDE.md 是全局和项目并存），不同类配置之间则是各管各的，不存在谁覆盖谁的问题。

所以当你问"谁能覆盖谁"的时候，要先分清楚是在同一类配置里比优先级，还是跨类配置想要传递信息。比如你可以让项目 CLAUDE.md 里写"这些规则是团队约定，优先于个人偏好"，但规范类文件本身不会覆盖设置文件里的权限。

5.2 一套可直接照抄的三层配置组合示例

为了让你直观感受，我给一个我常用的基础配置组合（以实际项目为例，保留通用部分）：

用户级~/.claude/settings.json：

{ "permissions": { "allow": ["Read", "Edit", "Bash(npm run *)", "Bash(ls)"], "deny": ["Bash(rm -rf *)", "Bash(git push)"] } }

全局~/.claude/CLAUDE.md：

# 协作偏好 - 我习惯用简洁的英文写提交信息，动词开头 - 写代码优先写测试，再写实现 - 遇到需要执行危险命令时，先向我确认下一步 - 代码注释保持精简，只在解释"为什么"时添加

项目级.claude/settings.json：

{ "model": "你的项目指定模型", "permissions": { "allow": ["Bash(npm run test)", "Bash(npm run build)"], "deny": ["Bash(git push --force)"] } }

项目CLAUDE.md用我在 3.3 节给的项目规范模板。

这份组合的效果是：你在任何项目里用 Claude Code，AI 都知道你的个人偏好，来自全局配置和记忆，又清楚当前项目的具体规则，来自项目配置和 CLAUDE.md。团队成员克隆仓库时，项目级配置自动生效，个人偏好不会干扰他们。这套结构我用了很久，唯一要经常调整的就是项目 CLAUDE.md，其他两层基本稳定不动。

5.3 初始化新项目的配置清单

每次我开新项目，都会按固定流程完成配置，避免后面反复补：

1. 在项目根目录创建.claude/settings.json，先只写模型和权限，不写 hooks。
2. 创建CLAUDE.md，从 README 和技术栈文档中提炼关键信息，控制在 20 到 40 行。
3. 检查全局~/.claude/settings.json是否需要为这个项目加例外权限。
4. 用几条显式记忆指令，把与这个项目相关的偏好写入 memory，比如这个项目用哪个包管理器。
5. 手动跑一轮最简单的对话，确认模型加载、权限询问、CLAUDE.md 内容是否被正确执行。

第 5 步很关键。很多人配置完从不测试，结果等到真正干活时才发现 CLAUDE.md 没生效或者权限规则写错了。花两分钟做一次冒烟测试，比在长任务中排查配置问题要划算得多。我的冒烟测试一般是让 Claude 描述一下这个项目的技术栈和目录结构，如果它能把 CLAUDE.md 里的关键规则说出来，说明加载没问题。

6. 配置踩坑实录与排查思路

6.1 settings.json 改了不生效，先检查位置和格式

最经典的坑：改了settings.json但行为没有变化。先说排查顺序：

1. 你改的是哪个文件？如果改到了~/.claude/settings.json，但项目里有.claude/settings.json，项目级会覆盖用户级。先确认当前生效的到底是哪个。
2. 改的是settings.json还是settings.local.json？项目本地配置优先级更高，如果团队项目只认本地文件，改非 local 文件可能不影响你本地会话。
3. 改了 env 之后是否重启了会话？很多 env 只在启动时读取，改完不重启会话，配置自然不会生效。

另外一个容易踩的坑是 JSON 格式。settings.json是严格 JSON，不能有注释，不能有尾逗号。我见过太多人从教程里复制配置，结果多了一个尾逗号，整个配置文件直接失效，而 Claude Code 启动时只给一个模糊的解析错误。这种问题排查起来最快的方式，是把文件内容贴到任意 JSON 校验工具里过一遍，几秒钟就能定位错误。

6.2 CLAUDE.md 内容被无视，先检查描述是否可执行

如果你在 CLAUDE.md 里写了规则，但 AI 干活时完全没遵守，常见原因有四个：

1. 描述太模糊。比如"请小心修改文件"——AI 不知道该把"小心"落实成什么动作，它只会按默认习惯干活。改成"修改 src/components 下文件时，必须同步更新对应的 stories 文件"这种可验证指令。
2. 被上下文挤出。长对话中，早期加载的 CLAUDE.md 内容可能被后续大量对话内容稀释，尤其是自动压缩之后。解决方法是把关键规则也通过记忆指令固化，或者在对话中重新强调。
3. 你改的是全局 CLAUDE.md，但项目 CLAUDE.md 里有冲突规则。比如全局说用 2 空格缩进，项目说用 4 空格缩进。AI 通常会优先跟随项目级说明。
4. 当前对话是在修改 CLAUDE.md 之前启动的。改完后新开一个会话，或做一次上下文压缩，重新加载说明文件。

我在实际项目中碰到的多数"CLAUDE.md 不生效"问题，最后都落到了第一类，规则写得太抽象。把规则改具体，AI 的执行率会肉眼可见地提升。

6.3 记忆错配引发的"灵异行为"

memory 是最容易让人困惑的部分，因为它看不见摸不着。我遇到过一个真实场景：在某项目里跟 Claude Code 说这个项目用 pnpm 不要用 npm，过了几天，在另一个 npm 项目里，它仍然试图用 pnpm。这就是典型的记忆错配——当时那条记忆被写成了全局记忆，而没绑定到具体项目。

处理办法是识别出这类错误记忆，然后用遗忘指令删掉，或者重新用更具体的语句写入记忆，比如"在 xx 项目仓库中使用 pnpm"。如果你发现自己经常要管理这种跨项目的记忆冲突，更稳妥的做法是在项目 CLAUDE.md 里显式写清楚工具偏好，因为项目说明是跟仓库走的，不会串到其他项目。

这类"灵异行为"其实都能从配置体系的视角解释：记忆没有项目边界，它跨项目生效；settings 和 CLAUDE.md 有明确的作用域。分清三者的边界，是排查这类问题最快的方式。再遇到 AI 行为不符合预期，先从"它把哪条配置记串了"的角度去想，往往能省下半天排查时间。

最后说一点个人体会：配置的本质不是把文件写满，而是把职责分清楚。settings.json管机器怎么跑，CLAUDE.md管项目是什么，memory管和你协作的人是谁。三件事搞混了，配置越多越乱；搞清楚了，哪怕每个文件都很短，AI 的行为也会非常贴合预期。我自己的配置加起来也就几十行，但比很多上千行的配置工程好用得多——配置的关键从来都是边界，不是数量。如果你现在觉得配置体系一团乱麻，不妨先把你已有的配置按照这三类重新归类一遍，你会惊讶地发现，真正需要保留的东西其实少得可怜。