企业官网建设流程全解析

先说个真实体验：我第一次用 Claude Code 的时候，上来就去翻settings.json，改了一堆权限和环境变量，满心以为万事大吉。结果换个项目一跑，它照样不知道我习惯先写测试、不知道这个仓库的构建命令是什么、做完一次重构后重启会话又把约定忘得干干净净。折腾到最后我才反应过来：settings.json、CLAUDE.md、memory这三样东西，名字听起来都是"配置"，实际管的根本不是一码事。这篇文章我不打算复述官方文档，而是把这三套体系放在一起对比着讲清楚——每一层解决什么问题、什么时候该写哪个、配置冲突了怎么排查，以及怎么把它们接到第三方模型、VSCode、终端命令这类真实场景里。如果你是刚开始接触 Claude Code，或者已经用了一段时间但总觉得"配置了跟没配置差不多"，这篇应该能帮你把整个配置体系理顺。

1. 三套配置的真正分工：先搞清楚谁管什么

很多人把这三个概念混在一起，本质上是因为它们都叫"配置"，但它们的定位差异非常大。我用一个比较接地气的类比来拆解：settings.json是操作系统的环境参数，CLAUDE.md是项目的团队协作契约，memory是会话之间自动沉淀的工作记忆。三者面向的对象、生效的时间尺度、存放的位置完全不同。

1.1 三个文件解决的是三种不同的问题

settings.json管的是一堆"执行层面的硬规则"：哪些操作被允许、哪些工具要询问确认、环境变量是什么、要不要挂 MCP 服务。它影响的是 Claude Code 这个程序本身的运行行为，跟你写的是 Vue 项目还是 Rust 项目基本没有关系。你可以把settings.json理解成"全局偏好 + 项目级偏好"的组合，它决定了工具链的边界。

CLAUDE.md管的则是"业务上下文"。它告诉 Claude 这个项目是干什么的、有什么代码规范、构建命令是什么、哪些目录不能乱动。它不控制工具的权限，而是作为上下文的一部分被注入到每次会话里，让 Claude 在动手之前就知道自己面对的是一个什么样的世界。可以理解为团队的 README，但它是给 AI 看的，且要写得极其具体。

memory才是最容易被误解的东西。它不是用户主动写的配置文件，而是 Claude 在对话过程中自动提炼的、跨会话保留的"记忆"。好比一个人做完一个任务后，会把"这个项目的测试跑得特别慢，别频繁全量执行"这类体会记在脑子里。它不需要你手动维护，但你可以通过/memory命令查看、补充和删除。

1.2 一张表看清边界：配置范围与生命周期

为了把这三种东西的差异彻底说清楚，我整理了一份对照表，这也是我平时给团队做培训时直接用的一张表：

从这张表可以看到，settings.json是"配置"，它决定运行边界；CLAUDE.md是"上下文"，它决定理解深度；memory是"记忆"，它决定连续性。三者的读写方式和维护频率完全不一样，后续所有操作都应该先回到这张表去判断"这个需求应该落在哪一层"。

1.3 最容易犯的第一个错误：把CLAUDE.md当配置指令

我见过不少人在CLAUDE.md里写"你必须先执行某个命令再开始"或者"不允许修改 XX 文件"，然后发现根本不生效。原因很简单：CLAUDE.md只是注入给 AI 看的上下文，AI 可以选择参考，但真正限制它行为的硬规则在settings.json的permissions里。你可以在CLAUDE.md里强调"本项目使用 pnpm，不要用 npm"，但如果你想强制禁止 Claude 执行npm install，正确的做法是在settings.json的deny里写Bash(npm install)。理解了这一点，后面所有配置都不会再跑偏。

2. settings.json 逐字段拆解：真正的执行规则在这里

先说清楚settings.json的文件层级。它实际存在两个位置：用户级配置在~/.claude/settings.json（macOS/Linux，Windows 下对应你的用户目录），项目级配置在项目根目录下的.claude/settings.json。实际生效时，项目级配置会覆盖用户级里的同名字段，但permissions这类数组型配置不是简单覆盖，而是做合并。这一点非常关键，很多人配置"不生效"其实就是因为对合并规则理解错了。

2.1 用户级与项目级：同样的文件名，完全不同的优先级

我建议的实践是：用户级settings.json只放那些你希望在任何项目里保持一致的习惯，比如个人偏好的默认模型、通用的环境变量；项目级.claude/settings.json放这个仓库特有的东西，比如项目的 MCP 服务、这个项目里特定的权限规则。

这里有个容易踩坑的细节：项目级配置所在的.claude目录通常会被提交到 Git 仓库里。如果你在项目配置里写了本机的绝对路径，同事拉下来代码之后配置就直接失效。所以项目级配置里尽量用相对路径或命令名，不要写/home/xxx/...这类本机路径。

另外还有一个经常被人忽略的文件叫managed-settings.json，一般由企业或团队托管配置时使用，优先级在用户级和项目级之上。普通个人使用不需要管它，但如果你的电脑是公司配发的，配置一直"改不动"，先去检查是不是被managed-settings.json给限住了。

2.2 permissions 三兄弟：allow / ask / deny 的优先级逻辑

permissions是settings.json里我使用频率最高的字段，它分为三个子数组：allow表示无需询问直接放行，ask表示执行前需要你确认，deny表示直接禁止。写法上支持返回具体工具和参数匹配，例如：

{ "permissions": { "allow": [ "Bash(npm run dev)", "Read(project/backend/**)", "Write(project/frontend/components/**)" ], "ask": [ "Bash(git push *)", "WebFetch(api.localhost)" ], "deny": [ "Bash(curl *)", "Bash(npm install)" ] } }

关键知识点来了：deny的优先级最高，只要规则匹配到了 deny，即使同时出现在 allow 里也不会放行。ask次之，allow最低。也就是说，你不能靠加一条宽泛的allow去覆盖一条具体的deny，只能去改掉 deny 本身。这个设计其实很合理——它保证"禁区"绝对可靠，不会因为某种合并顺序被意外放开。

我实测下来的经验是：allow规则要写得尽量具体，最好带参数匹配，而不是写裸的Bash或Read。如果你写一个裸的Bash，那 Claude 执行任何 shell 命令都不需要问你，这在真实项目里风险极高。一个合理的节奏是：先让规则保持较严，观察几天，把确实频繁且安全的操作逐个加入allow，而不是一开始就全部放开。

2.3 env、hooks、mcpServers：settings 的另外三个高频入口

env字段用来设置会话内的环境变量。这对挂第三方 API 特别有用，因为很多兼容 Anthropic API 的服务都要求自定义base_url和auth_token，你可以直接放在这里，而不是每次启动终端都 export。写法是：

{ "env": { "ANTHROPIC_BASE_URL": "https://your-endpoint.example.com", "ANTHROPIC_AUTH_TOKEN": "your-token-here" } }

hooks是另一个特别值得玩味的字段，它能让你在 Claude 执行工具的前后挂脚本。我最常用的场景是在PreToolUse阶段拦截危险操作，比如检测到Bash(rm -rf *)时直接终止执行并通知我。它本质上是一套可编程的安全网，比靠 deny 一个个写死要灵活得多。需要注意的是 hooks 脚本的返回结果必须符合 Claude Code 约定的 JSON 结构，所以初次配置时建议先在本地跑通一个最小示例再逐步扩展。

mcpServers则是把 Claude Code 连接到外部工具生态的关键入口。每一条配置会注册一个 MCP 服务，Claude 在会话中就能调用到该服务暴露的工具。一个典型的本地服务配置是：

{ "mcpServers": { "my-db-server": { "command": "npx", "args": ["-y", "my-mcp-server"], "env": {} } } }

在配置成功之后，通常需要重开会话才能让新工具被 Claude 感知到。如果你发现配置了却没出现新工具，先别急着怀疑配置格式，优先检查该服务能不能在命令行里独立启动成功。

2.4 一份可直接抄的完整 settings.json 示例

上面讲的是拆开看，下面给一份我在真实项目中使用的、相对完整的用户级配置示例，加了必要的注释。注意settings.json本身是纯 JSON 格式，不支持注释，所以下面的注释仅作说明，实际文件里要去掉：

{ "model": "sonnet", "permissions": { "allow": [ "Bash(npm run dev)", "Bash(pnpm build)", "Read(project/**)", "Write(project/src/**)" ], "ask": [ "Bash(git push *)", "Bash(pnpm test *)" ], "deny": [ "Bash(rm -rf *)", "Bash(brew update)" ] }, "env": { "MY_PROJECT_MODE": "development" }, "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "./scripts/hooks/pre-tool.sh" } ] } ] }, "mcpServers": { "sequential-thinking": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"] } } }

这份配置的基本思路是：读操作尽量放行，写操作限制在src目录，危险命令直接禁掉，提交和测试等需要确认的操作走 ask。实际使用中你会发现，只要allow给得够精准，会话里被打断让确认的次数会明显减少，但 Claude 依然不敢越雷池半步。

3. CLAUDE.md 不是说教文档，而是项目上下文契约

在 Claude Code 的配置体系里，CLAUDE.md常常是被误解最深的一个。它不是让 AI"变得更守规矩"的约束文件，而是让 AI"更懂这个项目"的说明文件。在理解这一点的基础上，你才能真正写出有质量的 CLAUDE.md。

3.1 它如何被加载：全局、根目录、子目录的三级扫描

CLAUDE.md的加载规则其实很有意思。Claude Code 会按顺序寻找三类文件：首先是全局的~/.claude/CLAUDE.md，然后是项目根目录的CLAUDE.md，最后是工作区内各子目录里的CLAUDE.md。这三类文件的内容都会被读到上下文里，而不是只有其中一个生效。

这一点在真实项目中非常有用。比如我在全局的CLAUDE.md里写的是"代码注释一律使用中文"，在项目根目录的CLAUDE.md里写的是这个仓库的架构边界和构建命令，在某个子目录里放一个只针对该模块的CLAUDE.md，规定该模块的接口风格。三层配合下来，Claude 既能保持你的个人风格，又能适配不同项目的特殊要求。

但注意，CLAUDE.md 不是越多越好。它的全部内容都会占用上下文空间，而且如果三个文件里有相互矛盾的说法，AI 还需要在推理时自行判断"哪个优先级更高"。我测试下来发现，最简单的约定是：全局写"个人习惯"，根目录写"项目硬约束"，子目录写"模块特殊约定"，三方各管一摊，不要互相越界。

3.2 什么样的CLAUDE.md真的有用：我的结构模板

一开始我写CLAUDE.md非常随性，想到什么写什么，结果 Claude 经常抓不住重点。后来我固定了一套结构，效果好了非常多，分享给你做参考。不管项目大小，我都会在CLAUDE.md里保持这几个板块：

• 项目一句话定位：用一句话说明这是一个什么系统，用谁、解决什么问题。
• 常用命令：开发、构建、测试、部署分别是什么。这里要避免写"见 package.json"，直接把命令写出来，AI 就不需要再去翻文件。
• 代码规范：命名风格、目录结构、错误处理方式等。写得越具体越好，比如"错误信息必须以ERR_前缀开头"。
• 禁止事项：哪些目录不能动、哪些操作不能做。注意这里是"上下文约定"，最后的安全兜底还是要靠 settings.json 的 deny。
• 当前架构要点：核心模块的职责边界、数据流向、关键依赖关系。

下面是我给一个中等规模前端仓库写的CLAUDE.md节选模板：

# 项目：XXX 管理后台 ## 项目定位 面向运营人员的管理后台，核心模块包括用户管理、订单管理、报表中心。 ## 常用命令 - 安装依赖：pnpm install - 本地开发：pnpm dev - 单元测试：pnpm test - 生产构建：pnpm build ## 代码规范 - 使用 TypeScript，禁止 any - 组件统一放在 src/components，页面放在 src/pages - API 调用统一走 src/api 下的封装，禁止在组件里直接 fetch ## 禁止事项 - 不要直接操作数据库 - 不要修改 src/backend 下的文件（该目录属于独立服务） ## 架构要点 - 前端通过 http 请求调用 xxx 服务 - 权限模型基于角色，所有按钮级别权限走统一指令

写完之后你可以做一个简单验证：新开一个会话，问它"这个项目的测试命令是什么"，如果它能直接答出pnpm test，说明写入生效了。如果它还去翻文件，多半是你的CLAUDE.md没放在项目根目录，或者文件名大小写不对。

3.3 团队场景：CLAUDE.md 应该随代码入库

CLAUDE.md有一个非常重要的特征：它应该被提交进 Git 仓库。这跟settings.json很不一样，后者往往带有个人或本机属性，不太适合全员共用。但CLAUDE.md本质上是"团队与 AI 的协作契约"，它应该随代码一起评审、一起演进。

我见过一些团队把个人偏好塞进项目的CLAUDE.md，比如"作者本人喜欢用双引号"，这其实是个坏习惯。项目级CLAUDE.md里只应该出现"所有人都会认同的共识"，比如代码风格、构建流程、架构边界，而个人口味应该放在全局CLAUDE.md或者靠 memory 去沉淀。判断标准很简单：如果这句话是"我"而不是"我们"，它就不该出现在项目级 CLAUDE.md 里。

3.4 从CLAUDE.md延展出去：.claude/commands 自定义斜杠命令

当你把项目级配置维护到一定程度后，会发现.claude/目录下面还能放更多东西，其中我强烈推荐的是自定义斜杠命令（commands）。在项目根目录的.claude/commands/里放一个.md文件，文件名就是命令名，文件内容就是该命令执行时的提示词。比如我建了一个review.md，内容是：

请对当前工作区最近的代码变更做一次全面代码评审，重点检查： 1. 是否引入内存泄漏或安全问题 2. 是否符合项目 CLAUDE.md 中约定的代码规范 3. 是否存在明显的性能隐患 4. 测试覆盖是否充分 按严重程度分类输出问题清单。

然后在会话里输入/review，Claude 就会自动按这套指令执行。这个机制不是官方强调的"三大配置体系"之一，但它和CLAUDE.md配合起来非常好用：CLAUDE.md 负责提供项目背景，commands 负责把"你希望 AI 怎么干"的方法论沉淀成可复用的指令。很多重复性的操作，比如发版本前检查、提交前自检、安全扫描，都可以做成项目级的斜杠命令。

4. memory 不是缓存，是跨会话的工作记忆

如果说settings.json和CLAUDE.md都需要主动配置，那memory就是唯一一个"会自动生长"的配置层。它被很多人忽略，但我觉得它对长期使用体验的提升不亚于前两个。

4.1 /memory 指令和记忆文件的实际形态

在 Claude Code 中，你可以在会话里输入/memory来查看当前项目积累的记忆。它实际上就是在当前项目的独立目录下，以 Markdown 文件的形式存储了一些"值得长期记住的内容"。这些记忆文件可以由 Claude 在对话过程中自动提炼生成，也可以由你自己补充，补充的方式通常是在/memory的交互界面里添加。

我实测下来，Claude 会在某些场景下主动判断"这段信息值得记下来"，比如你告诉它某个服务只在内网可用、某个目录不能动、某种写法在这个项目里是约定俗成的。它把这些提炼成一条条记忆，在下一次会话里直接加载，这样你就不需要在每次新会话里重新说一遍。

也正因为如此，memory 和CLAUDE.md正好形成互补：CLAUDE.md 是"你主动教 Claude"的知识，memory 是"Claude 从经验里学到"的知识。前者稳定，适合放项目的事实性信息；后者动态，适合放实践中发现的坑和约定。

4.2 哪些东西值得沉淀进memory，哪些不要

我用了一段时间后，总结了一套"值得沉淀"的清单：

• 项目的隐性约束：例如"测试环境数据库每天凌晨会被重置""某些接口有调用频率限制"这类只在实际使用中才能发现的规律。
• 踩坑结论：例如"这个仓库用 pnpm 安装依赖时不要用 npm，会把 lock 文件搞乱"。
• 用户偏好：例如"代码注释尽量写中文""遇到不确定的 API 先看类型定义再动手"。

不建议放进 memory 的内容包括：一次性的任务上下文（比如"这次目标是修 bug"）、会频繁变化的状态性信息（比如"当前分支叫 feature-xxx"）、以及任何敏感信息。memory 的本质是给后续所有会话看的"长期事实"，一旦写入，会在相当长的时间里反复影响后续的对话。

这里有个很实用的技巧：如果你发现 Claude 反复遗忘某个约定，与其每次新会话都手打一遍，不如主动通过/memory把这条约定加进去。你会发现后续它记住的概率高很多，因为它是作为记忆被载入的，而不是只存在于某一次对话历史里。

4.3 记忆安全边界：为什么不能把密钥和个人敏感信息写进memory

说到敏感信息，我要专门提醒一句：永远不要把 API Key、密码、私有 token 等写进 memory。原因有两个层面。第一，memory 文件是以明文形式存放在本机磁盘上的，而且它在每次会话中都会被当作上下文的一部分送进模型读取，这意味着它被后续任何提示词"看到"的机会非常大。第二，也是更隐蔽的：凡是会被模型长期记忆并反复利用的信息，都存在被后续不可信输入诱导利用的可能。学术界有一个专门的攻击方向叫 memory poisoning，研究的就是攻击者如何通过污染 AI 的记忆或上下文，让 AI 在后续会话中按攻击者的意图行动。作为使用者，我们能做的就是减少暴露面：不把密钥、个人隐私、未经验证的外部信息写入记忆。

一个更安全的做法是：敏感信息用环境变量管理，写入settings.json的env字段或系统环境变量；memory 里只存放那些你愿意被模型长期保留的工程结论。每过一段时间，建议用/memory过一遍已有的记忆，把过时的、或者不想再让 AI 记住的条目删掉。记忆在精不在多，积累了一堆噪声反而会干扰模型判断。

5. 配置不生效的排查链路：从文件层级到JSON语法

讲完三套配置各自的细节，接下来要说的这个问题是每个 Claude Code 用户都会遇到的：配置写了，但好像没生效。我总结了一套固定的排查链路，按顺序走一遍，大多数问题都能定位到根因。

5.1 优先级冲突的三个客观事实

先说三个容易被踩的优先级事实：

第一，项目级 settings.json 会覆盖用户级 settings.json。如果你在用户级配置了"model": "opus"，又在某个项目的.claude/settings.json里写了"model": "sonnet"，那这个项目里实际生效的是 sonnet。很多人忘了自己在项目里配过啥，还跑去改用户级配置，自然没有效果。

第二，permissions 是合并而不是覆盖。用户级和项目级的 allow/ask/deny 会做并集操作，而且 deny 的优先级永远最高。这就意味着，即使你在用户级 allow 了某个命令，只要项目级 deny 里有匹配规则，这个命令照样会被拦下来。这其实是安全设计，但排查时容易让人困惑。

第三，CLAUDE.md 与 settings.json 不是同一个维度。CLAUDE.md是上下文，settings.json是执行规则。你不能指望在 CLAUDE.md 里写一句"不要用 npm"就能阻止 Claude 执行 npm，它只会"知道"这个约定，但真正强硬的拦截必须靠 deny 规则。排查时如果发现"AI 还是不听话"，先想想你有没有把约束写到它必须遵守的层里。

5.2 标准排查五步法

当"配置没生效"时，我建议按下面的顺序排查，效率最高：

1. 确认你改的是哪个层级：打开~/.claude/settings.json，再看项目里有没有.claude/settings.json，确认你期望生效的字段有没有被项目级覆盖。这是最高频的"无效修改"原因。
2. 检查 JSON 语法：settings.json是严格 JSON，不允许注释，不允许尾逗号。很多人在调试时随手加了注释，结果整个文件解析失败，配置全部不生效。
3. 用 /status 或 claude --debug 看加载信息：在会话里输入/status可以查看当前会话的模型、工作目录等基础状态；启动 Claude Code 时加--debug可以输出更详细的加载过程日志，能看到它实际加载了哪些配置文件。
4. 验证权限规则的匹配粒度：如果你写了allow但执行时仍然弹出确认框，检查一下实际命令是否和你的规则完全匹配。比如你写了Bash(pnpm build)，但实际执行的命令是pnpm build --mode production，两者就不匹配，照样会走 ask。
5. 重开会话验证：很多配置是在会话启动时加载的，修改配置后不重开会话，Claude 可能还在用旧配置。特别是 MCP 服务和 hooks，几乎必须重启才能生效。

5.3 我踩过的两个具体坑

第一个坑是CLAUDE.md放错了目录。有段时间我习惯把文档放在docs/下，于是在docs/CLAUDE.md里写了大量项目规范，结果 Claude 完全无动于衷。后来才明白，Claude Code 只按约定位置查找文件，项目根目录的CLAUDE.md才是默认入口，放进docs/里它根本不会主动读。这个只要理解加载规则就不会犯第二次。

第二个坑是 hooks 的 JSON 返回结构。第一次配PreToolUse钩子时，脚本逻辑没问题，但返回结果漏了必填字段，结果 Claude Code 直接在调用工具时报错，我还以为是权限配置写崩了，排查了半天。后来经验是：hooks 脚本先用最简单的"返回允许"跑通，再加业务逻辑，最后再补失败分支。配置体系的调试，永远要先做最小验证。

6. 把配置体系放进真实工作流：第三方模型、终端命令与VSCode

最后一部分，我想把前面拆开的配置体系放回真实工作流里，讲几个我几乎每天都会用到的组合场景。这三个场景也是很多新手最容易卡住的地方。

6.1 通过 env 接入第三方兼容API端点

Claude Code 的配置体系里，env字段给了你一条接入第三方兼容 API 的快捷路径。只要某个服务提供了和 Anthropic API 兼容的端点，你都可以通过设置ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN来切换。对开发者来说，这意味着你可以根据需求在不同模型之间切换，而不需要改业务代码。

我自己的做法是：在用户级settings.json里维护一套默认端点，然后针对不同项目在项目级配置里覆盖env。这样每个项目都能锁定自己需要的模型服务。社区里常见的做法是配合cc-switch这类小工具，在多个端点配置之间快速切换。这类工具本质上就是自动帮你改settings.json里的env字段，比手动编辑要方便很多，也不容易出错。配置之后记得确认一下当前使用的环境变量是否真的被加载到了，可以用/status快速验证。

顺便说一下登录和第三方密钥的区别：如果你有官方账号，登录取用订阅权益是标准玩法，会话历史、用量管理都方便一些；如果只是临时试用或者通过兼容端点接入，不登录也能正常工作。区别主要体现在一些依赖账号体系的功能和速率限制上，看你的具体需求来定。

6.2 终端命令执行权限的精细控制

这是settings.json里我使用频率最高的一类配置：控制 Claude 能不能执行终端命令、能执行哪些命令。

默认情况下，Claude Code 对于 Bash 工具是相对谨慎的，很多操作会征求你的确认，这跟你对permissions的配置有关。如果想让工作流更流畅，你应该往allow里写明确允许的命令，而不是直接甩给它一个全局放行。

举个例子，我经常对 Claude 说"帮我跑一下测试"，如果我希望它直接执行而不每次问我，我会在allow里加Bash(pnpm test)。如果我希望某些更敏感的操作必须问我，比如推送代码，就放进ask，写Bash(git push *)。如果有些命令无论如何都不许执行，比如清空磁盘或者全局卸载依赖，就放进deny。

这里要特别提醒：命令的匹配是精确的，你写Bash(pnpm test)不代表它能执行pnpm test --coverage。如果你期望某个前缀范围的命令都被允许，需要用通配符或更宽泛的规则。但宽泛规则会带来安全风险，建议先精确放行，观察几次后再逐步放宽。不要因为嫌确认弹窗烦就直接写一个裸Bash，这个坑踩下去容易出大事。

6.3 VSCode与跨平台环境下的配置联动

在 VSCode 里使用 Claude Code 扩展时，配置文件的位置和命令行版本是同一套，不存在"编辑器配置"和"命令行配置"两套体系。你在终端里改了settings.json，VSCode 里也会读到，反之亦然。唯一的区别是 VSCode 插件的界面入口可能会多一层"工作区设置"的视觉引导，但底层还是一样。

跨平台方面，macOS 和 Linux 上用户级配置都在~/.claude/下，Windows 上则在用户目录下的.claude文件夹里，路径逻辑一致但目录形态不同。Ubuntu 这类 Linux 环境里最容易踩的坑不是 Claude Code 本身，而是 PATH 问题：你在终端里能运行的命令，在 Claude Code 的 Bash 工具里可能因为 PATH 环境没有加载到而找不到。这在用 npx 启动 MCP 服务时尤为常见。解法通常是在用户级settings.json的env里补上路径，或者确保 shell 配置文件里 export 的 PATH 能覆盖到图形界面启动的进程。

在 VSCode 插件里，我还有一个个人习惯：把常用的斜杠命令也放到项目级的.claude/commands/下面，这样插件端我只需要输入/就能列出全套常用动作，省去重复输入大段提示词的时间。

在实际使用中，我最舒服的组合方式是：用户级settings.json只管模型端点、全局权限和通用 hooks；项目级.claude/settings.json管项目特定的 MCP 和权限；项目根目录的CLAUDE.md作为团队的固定背景知识；memory 则放任它自然沉淀，但每两周用/memory清理一轮，把过时的条目删掉。这套组合跑起来之后，你会发现新开一个会话的沟通成本低了很多——Claude 开箱就知道自己在哪个项目里、该守什么规矩、有哪些前车之鉴。剩下的时间，就可以留给真正需要动脑子的那部分工作了。