企业官网建设流程全解析

直接把一个命令行工具用顺溜，和把它变成真正趁手的生产力，差距往往就在那几个配置文件里。Claude Code 这三个体系——settings.json、CLAUDE.md、memory，就是决定你从“能用”跨到“好用”的关键。我最初用的时候也没太上心，顶多改改模型、调调权限，直到有几次被它反复犯同样的低级错误搞到破防，才意识到：这玩意儿就像给一个聪明但记性差的实习生立规矩，规矩写在哪、怎么写，效果天差地别。

这篇东西我会从实际使用的角度，把这三大配置体系的底层逻辑、具体写法、协作关系都拆开讲清楚。不管你是刚装好 CLI 准备跑第一个 demo，还是已经用了一阵子但总觉得差点意思，应该都能找到有用的东西。

1. 三大配置体系的分工逻辑：项目规则、用户偏好与长期记忆

先明确一个核心概念：这三套东西不是功能重复的备选方案，它们各自管的是不同维度的信息，缺一不可。

• settings.json管的是“工具本身怎么运行”。模型用哪个、权限开多大、要不要自动接受编辑、日志怎么写——这些是机器层面的运行参数。
• CLAUDE.md管的是“这个项目的规矩是什么”。技术栈约束、代码风格、测试要求、目录结构、禁用行为——这些是项目层面的语义规则。
• memory管的是“Claude 记住的长期偏好”。不管你在哪个项目里，它都记得你习惯用 TypeScript、讨厌某个库、提交信息爱怎么写——这些是跨项目的用户画像。

打个不严谨但好懂的比方：settings.json像是给电脑设的启动参数，CLAUDE.md像是工位墙上贴的项目流程图，memory则是 Claude 自己那个随身带的小本本。启动参数错了工具没法正常跑，流程图不贴它做事就跑偏，小本本不记东西它就永远拿你当陌生人。

这三个可以独立使用，但真正顺手的工作流通常是组合拳：

1. 全局settings.json设好个人偏好的默认运行环境；
2. 项目级settings.json覆盖特殊需求（比如这个项目必须用 mini 模型省钱）；
3. CLAUDE.md放进仓库，随代码走，团队共享；
4. memory存个人长期偏好，跨项目生效。

这一套下来，换了新机器、新同事、新项目，拉下来就能跑，Claude 的表现也会越来越对你胃口。

2. settings.json 详解：从运行参数到模型与权限控制

settings.json是 Claude Code 的配置主文件，有全局和项目两级。常规的做法是全局文件放用户目录下，比如~/.claude/settings.json，而项目级文件放在项目根目录的.claude/settings.json。项目管理里很常见的一条原则是：个人偏好放全局，团队约定进项目仓库。

2.1 关键字段逐一拆解

这部分我直接给一份我平时用得最多的字段清单，附上注释说明：

{ "model": "claude-sonnet-4-20250514", "permissionMode": "acceptEdits", "includeCoAuthoredBy": true, "cleanupPeriodDays": 30, "env": { "MY_CUSTOM_KEY": "some-value" } }

逐条拆解一下：

• model：指定默认模型。这个最直观，claude-opus-4-20250514、claude-sonnet-4-20250514、claude-3-5-haiku-20241022都有各自的能力和计费档位。日常开发我多用 Sonnet，跑重活儿切换到 Opus，简单任务用 Haiku 省钱。
• permissionMode：权限预设，最常用的三档是default（每个操作都询问）、acceptEdits（自动接受文件编辑，但终端命令仍需确认）、bypassPermissions（基本全放行）。注意，这里放行的范围非常广，建议只在信任的沙盒环境里开最后一档。
• includeCoAuthoredBy：控制在生成的 commit 信息里要不要带上 “Co-Authored-By: Claude” 的署名。你的开源项目如果对署名有洁癖，这里直接关掉。
• cleanupPeriodDays：清理会话历史的天数。默认值不算长，过度堆积会拖慢启动速度，但设太短又会丢上下文，30 天是很多人的平衡点。
• env：注入自定义环境变量。适合把 API Key 之类的东西通过配置传进去，不用写死在命令里。

2.2 权限模型：为什么它值得你专门花时间调

默认权限模式下，Claude Code 每执行一次写操作或终端命令都可能打断你。用多了会烦，但完全不设防也容易出事。

我的建议是，先在默认模式下跑一两天，摸清它的操作节奏，再逐步把那些你信任的高频操作放到允许列表里。项目级配置里可以直接加：

{ "permissions": { "allow": [ "Bash(npm run lint:fix)", "Read(tsconfig.json)", "Write(package.json)" ], "deny": [ "Bash(git push --force)" ] } }

allow和deny列表会在权限询问时提前匹配，命中规则的操作就不弹窗了。注意，deny优先于allow，所以哪怕全局放得很宽，git push --force这种高危操作也可以在项目级死死摁住。

2.3 常见配置错误与排查

• 全局和项目配置都写了model字段，项目级会覆盖全局，这点别搞反。
• JSON 格式错误会导致启动直接报错，但报错信息有时候不太友好。稳妥做法是修改完先用jq或者在线校验工具跑一遍。
• 改了配置不生效，先确认改的是不是当前项目生效的那份文件。用claude config list或直接看claude的启动日志可以定位到底加载了哪个文件。

另外提一句：有些第三方接入工具（网上不少人在讨论用 cc switch 之类的路由工具接入国产模型或第三方 API）本质上也还是在帮你改settings.json里的model、baseURL或env。所以就算你用这类工具，理解了配置格式，遇到问题排查起来也顺手很多。

3. CLAUDE.md 详解：把上下文喂给 AI 的正确姿势

如果说settings.json是在教 Claude Code“怎么干活”，CLAUDE.md就是在教它“你的活儿是什么、有什么禁忌”。这个文件我倾向理解为项目的“交接文档”——任何一个新成员（包括 AI）来了，读一遍它就能快速上手。

3.1 放哪、叫什么、给谁看

官方按作用域区分了几种路径，我建议按优先级从高到低记：

# 当前执行的子目录（比如 modules/auth/CLAUDE.md） # 当前目录（比如 CLAUDE.md） # 父目录逐级向上 # 用户级 ~/.claude/CLAUDE.md

关键点是：离当前工作目录越近的，优先级越高。同一个主题，项目根目录写了一套规则，子目录里写了一套，以子目录为准。

我还见过一种用法，把CLAUDE.md链接到团队 wiki 或设计文档，引入一些 AI 不需要关心的内容，到头来反而拖慢了响应、浪费了 token。只放与编码直接相关的内容才是正确姿势。

3.2 内容结构：怎么写才高效

一个高效的CLAUDE.md不需要很长，但应当结构清晰。我常用的骨架：

# 项目概述 一句话说清项目做什么，核心业务是什么。 # 技术栈 - 前端：React 18 + TypeScript + Vite - 后端：Node.js + Express + PostgreSQL - 禁止引入：MobX、Redux Toolkit（已被 zustand 替代） # 代码规范 - 组件文件使用 PascalCase - 样式必须使用 CSS Modules，禁止使用全局 class - 所有 API 调用必须经过 `src/api/client.ts` 统一封装，禁止直接 fetch # 测试要求 - 新增功能必须补充单元测试 - 运行测试：npm run test # 常用命令 - 启动开发服务器：npm run dev - 构建：npm run build - 执行 lint：npm run lint:fix # 特殊注意事项 - `src/legacy/` 目录下的代码不要动，等待迁移 - 数据库迁移文件只能手工生成，禁止让 AI 直接修改

这里面的每一条最好都带上“为什么”。比如光写“禁止直接 fetch”不够，加一句“因为统一走 client.ts 可以自动附带鉴权头和错误上报”，Claude 在权衡取舍的时候就能做出更符合你意图的判断。

3.3 动态记忆更新：让 CLAUDE.md 真正“活”起来

官方文档里专门提过，Claude Code 可以在你确认某项约定后，自主将关键约定写入CLAUDE.md。例如，你用一次/memory指令明确告诉它“以后都用 pnpm 而不是 npm”，它可能会在用户级或项目级CLAUDE.md里追加一条记录。

这个机制很强大，但也要小心：如果你不希望它自动改文件，可以在settings.json里加上"disableAutoMemory": true，或者手动把关写入的内容。自动追加的条目有时候太啰嗦，我会定期去清理。

3.4 三条我踩过的实战建议

第一，别把 CLAUDE.md 写成论文。我见过同事把一份两万多字的业务文档直接塞进去，结果每次请求都要读一遍，又慢又贵。控制在 200 行以内，其他的放外部文档，用到再让 AI 去查。

第二，负面清单比正面清单更有效。写“不要怎么做”比写“要怎么做”更能约束行为，因为正面期望往往容易被过度发挥。

第三，随仓库走、随团队共享。这份文件提交到 Git 里之后，所有协作者和 CI 都能受益，它是团队知识沉淀的一部分，不只是给 AI 看的。

4. memory 详解：跨会话、跨项目的长期记忆管理

用过 Claude Code 的人大多有个感受：不配置 memory 的情况下，它的上下文基本就是“一锤子买卖”。你这次告诉它的偏好、约定、背景知识，关掉终端再开一个会话，可能就忘干净了。memory就是为了补上这块。

4.1 memory 与 CLAUDE.md 的区别再强调一次

很多人会把 memory 和 CLAUDE.md 搞混，其实它们完全在不同维度：

• CLAUDE.md是项目维度的共享上下文，跟着仓库走，团队所有人都能看到、改到。
• memory是用户维度的私人记忆，跨项目生效，记录的是“我喜欢怎么工作”。

举个例子：CLAUDE.md写“这个项目用 React 18”，memory写“用户偏好使用函数组件而不是类组件”。

4.2 memory 的配置文件与管理方式

Claude Code 的用户级记忆通常存放在~/.claude/目录下，具体的文件会随版本演进有所不同，可能是内存数据库文件、纯文本记录或结构化存储。你可以直接打开看一眼，里面一般是一段段带时间戳和标签的记忆条目。

日常管理记忆的入口主要还是对话内指令：

• 用自然语言告诉它：“记住，我提交信息用 Conventional Commits 格式。”
• 用/memory指令查看或管理已有记忆。

注意，记忆不是你随口说一句它就永久记住了。它会结合上下文判断这条信息的稳定性和重要性，有时会先跟你确认，有时会忽略掉。要想稳妥地写入记忆，最好用明确的指令开头，比如“请记住：...”。

4.3 memory 的实际使用技巧

我日常会刻意去用记忆的场景有这几类：

• 个人工具链：比如“我常用 pnpm 而非 npm”、“我的代码编辑器是 VS Code”。
• 编码风格偏好：比如“缩进用两个空格”、“组件文件命名 PascalCase”。
• 常用命令别名：比如“跑测试用pnpm vitest”。
• 业务背景补充：比如“我在做电商中台项目，用户体系走内部 SSO”。

要注意的是，memory 里存太多无关紧要的东西反而会干扰 Claude 的判断，甚至出现“记忆污染”——它记了一些过时或错误的偏好，在关键时刻给你错误建议。

我建议每过几周清理一次记忆：翻一遍，把过时的删掉，保留真正稳定、长期有效的偏好。

5. 三大配置体系的协同：项目实践中如何组织

讲清楚各自的定位以后，再回头看我开头说的“组合拳”，你就能明白为什么一套好的配置比命令本身更值钱了。

5.1 一套顺手的配置模板

假设我用 Claude Code 参与一个 TypeScript 项目，通常我会这样铺三层配置：

1. 全局~/.claude/settings.json——设置默认模型、acceptEdits权限、我的个人环境变量。
2. 项目根目录.claude/settings.json——覆盖模型为 Sonnet、禁用自动记忆、按项目需要限定权限。
3. 项目根目录CLAUDE.md——写清技术栈、规范、目录约定、常用命令、注意事项。

在这之上，memory里再沉淀我个人的工作习惯和跨项目偏好。这套配置下来，新机器只要装好 Claude Code、恢复一下全局配置和 memory，拉到任意一个配置齐备的仓库，立刻就能干活，基本不用重新“调教”。

5.2 配置生效顺序

从优先级角度简单梳理一下：

一句话总结：项目级的显式配置永远优先于用户级的默认配置，memory 作为基础偏好，在项目没有明确覆盖时生效。

5.3 几个我亲测有效的配置组合场景

• 单人维护多个项目：全局设置固定 model + acceptEdits，项目里各自写好 CLAUDE.md。切项目时上下文不串味。
• 团队协作：项目级 settings.json 锁死权限，CLAUDE.md 团队成员共享，禁止个人在项目里乱改配置。
• 低成本跑量：把默认 model 设成 Haiku，CLAUDE.md 写得更精简，memory 里存好常用命令，减少 token 消耗。

6. 配置高频问题排查实录

把我在实际操作中经常遇到的、以及社区里反复讨论的几个问题整理成一张速查表，方便你对照排查。

另外补充两个很少被提及但实际很影响体验的细节：

第一，CLAUDE.md里写命令时，尽量用$符号或代码块明确标注可执行命令，Claude 识别起来更快更准。

第二，settings.json里可以设置hooks字段，在特定事件（如文件编辑后、命令执行前）触发自定义脚本。这个能力很强，但复杂度也高，初期不建议折腾。

7. 最后的几点心得

实际用下来，我对这三套配置最有感触的一点是：它们本质上是在帮 AI 建立一套“人格化的工作协议”。模型本身的能力大家都一样，但你能不能把它驯化成符合你习惯的工程师，完全取决于这些配置怎么写、怎么配合。

我踩过的最深的坑，就是一开始只盯着settings.json调参数，觉得权限、模型改好就万事大吉，结果每次换项目、每次新会话，Claude 都像是第一次认识我，反复踩同样的雷。直到认真把CLAUDE.md按项目建起来、把 memory 里的偏好一点点喂进去，才真正有“它在替我干活”而不是“我在陪它调试”的感觉。

如果你现在刚开始配置，我建议的路线很简单：先花一个下午把全局 settings.json 定好，再给你手上最核心的项目写一份精简的 CLAUDE.md，然后边用边沉淀 memory。不用追求一次配到完美——这套东西本来就是越用越准，越调越顺。