企业官网建设流程全解析

我每天在终端里跟 Claude Code 打交道，代码量确实上来了，但效率反而被拖住的情形也不少：项目背景翻来覆去解释、生成风格忽好忽坏、不该动的文件它偏要改、一个长任务做到一半上下文彻底放飞。这些事挤在一起，足以让人怀疑手里的 AI 编程助手是不是真的“智能”。直到我认真搭了一套配置体系，把所有规则、命令、权限、上下文全部文件化、版本化，起名就叫 everything-claude-code。搭完之后，同一个工具，干活的稳定性和质量完全不是一个层级，这不是玄学，是把默认改造成体系的工程收益。

这篇文章不画饼，就讲这套体系的完整搭建过程：为什么默认状态不好用、目录和配置怎么设计、CLAUDE.md 怎么写到“助手敢当制度执行”、自定义命令和钩子怎么接、最后再附一份我踩坑换来的避坑清单。适合谁看？适合已经用上 Claude Code、但还停留在“打开对话框就干”阶段的人。不需要你多懂底层原理，只要会操作终端，沿着下面步骤走完，你也能得到一个“随手一叫就靠谱”的编程助手。

1. 先想清楚：Claude Code 默认状态到底缺什么

1.1 为什么默认配置只能算“能用”

Claude Code 的优势之一是能直接读取项目文件、执行命令、修改代码，但它默认没有你的行业背景、团队规范和个人习惯。打个比方，默认状态下的助手像是刚入职的实习生：专业底子没问题，但不了解项目历史，也不知道你讨厌哪种代码风格。你让这位实习生写代码，第一版往往方向歪，你得不断纠正。问题在于，AI 编程助手的每一次会话都有上下文窗口限制，你说过的要求会随对话变长被“稀释”，甚至彻底遗忘。于是你发现自己反复复制粘贴同样的说明，在十几个项目里重复解释同一件事。

我观察到的三个明显痛点：

• 项目上下文没有沉淀。换了一个任务，助手又变回“首次见面的实习生”，你被迫重新交代目录结构、技术栈、注意事项。
• 工具调用不稳。它有时会自作主张动不该动的文件，或者把测试命令执行到一半卡在权限确认上。
• 代码风格统一不了。同一个团队的项目，它一会儿用单引号，一会儿用双引号，一会儿函数式，一会儿面向对象。

这三个痛点的根子都在于：默认能力没有被约束成可复用的规则。所以我才重新设计了一套“让规则变成文件、让工具调用变得可控”的配置方案，就是 everything-claude-code。

1.2 everything-claude-code 这个名字到底指什么

它不是某个官方插件，而是一种“把 Claude Code 武装成工程流水线”的完整配置方法。我给它取这个夸张名字，是因为它的覆盖面确实广：全局配置管脑子、项目配置管专业、自定义命令管重复劳动、Hook 管工具调用的边界、权限白名单管安全底线。整套东西都放在你的目录里，每个文件都能被 Git 追踪，任何人接手都能看懂助手为什么会这样干活。

这套体系从下往上分四层：

• 配置层：settings.json 控制权限、模型、钩子、环境变量。
• 规则层：CLAUDE.md 保存长期记忆和项目上下文，全局一份，项目一份。
• 命令层：像/review、/commit、/todo这样的自定义斜杠命令，把复杂任务压缩成一句话。
• 工具层：Hook 脚本在编辑文件、执行命令前后做纪律检查。

四层互相配合，AI 的“自由发挥”被控制在合理范围内，剩下的是把效率留给创造性问题。

1.3 为什么选择文件化而不是“记忆”

很多人听说 AI 助手支持“记住你的偏好”，第一反应是多聊几句让它形成记忆。我的建议是别依赖聊天式记忆，原因很直观：

• 会话一旦清理，记忆即消失。
• 多次会话之间的记忆容易互相污染。
• 记忆不能被代码评审，出了问题你没法定位是哪一个偏好在作怪。

文件化之后，规则是静态的、可见的、可回滚的。你改了一行规则，马上就能重新遛一遍，验证行为变化。这才是工程化思维，而不是对着对话框练“咒语”。

2. 地基准备：目录设计与环境前置条件

2.1 需要准备的运行环境

一切配置的前提是 Claude Code 已经能在命令行运行。需要的基础环境如下：

• 操作系统：macOS、Linux 或 Windows 下的 WSL 都行。
• Node.js 18.0 及以上版本，很多 Hook 脚本依赖 Node 运行时。
• Git 2.23 及以上版本，用于配合版本管理和部分自动化流程。
• Claude Code CLI 已登录并正常启动。

检查环境最直接的方式是在终端里敲：

claude --version node -v git --version

三条命令都能正常返回版本号，就说明地基没问题。接下来要处理的，是目录怎么摆。

2.2 everything-claude-code 的目录拓扑

这套配置涉及全局和项目两个层面。全局配置放在用户主目录下的.claude文件夹，用来保存跨项目的通用规则；项目配置放在各自项目根目录下的.claude文件夹，保存只属于这个项目的知识。

一个标准的目录树长这样：

~/.claude/ ├── CLAUDE.md # 全局规则记忆 ├── settings.json # 全局权限与钩子配置 └── commands/ # 全局自定义命令 your-project/ ├── CLAUDE.md # 项目专属规则记忆 └── .claude/ ├── settings.local.json # 项目级权限配置 ├── commands/ # 项目自定义命令 └── hooks/ # 工具调用守卫脚本

之所以这样安排，是因为 Claude Code 在启动时会自动读取多级配置文件。全局配置相当于操作系统级别的环境变量，项目配置相当于项目独享的环境变量，最终生效的规则是两者叠加。我建议把公共规范放进全局层，把技术栈细节放进项目层，避免所有项目都被无关信息拖累。

2.3 配置优先级与覆盖逻辑

如果你在全局规则里写了“统一使用单引号”，项目规则里写了“本项目使用双引号”，最后生效的是项目规则。默认的覆盖原则是：越靠近当前项目的配置，优先级越高。这个设计非常合理，因为它允许你在不同项目间自动切换行为，不用手动改一堆东西。

但也要注意，有些配置会被“合并”而不是“覆盖”。比如 settings.json 里的权限列表，全局允许项和项目允许项会合并成一份。这时候我习惯在项目配置里主动“缩小权限”，而不是只靠全局白名单宽松放行。毕竟一旦合并，安全边界可能比你预想的更宽。

3. 把规则写成可执行的东西：CLAUDE.md 的高级用法

3.1 全局 CLAUDE.md 不要写废话

很多人第一次写 CLAUDE.md，容易写完一段“你要做一个负责任的编程助手，保持代码整洁”之类的废话。助手确实会读这种话，但它没有执行锚点，等于没写。真正有效的全局规则，应该是“可验证、可执行、分场景”的检查项。

下面是我那份全局 CLAUDE.md 的核心内容骨架：

## 通用编码纪律 - 修改代码前，先查看相关文件的现有风格和依赖关系 - 不修改 package-lock.json、*.lock 后缀文件，除非用户单独明确要求 - 新建文件前，先判断是否已有同名或相似功能的文件 ## 命令执行原则 - 执行测试命令时，优先使用包管理器中定义的脚本 - 不擅自执行 git push --force，不擅自清理分支 - 执行高危命令前，用最简洁的话说明影响范围 ## 回答风格 - 结论先行，再给依据 - 给出修改建议时，同步给出需要用户确认的风险点

你注意看，每一条都包含动作主体和判断条件。“不修改 lock 文件”是动作约束，“除非用户单独明确要求”是解锁条件。这样 Claude Code 在执行 Edit 或 Write 之前就有据可依，不会凭感觉发挥。

3.2 项目 CLAUDE.md 写什么

项目层级的 CLAUDE.md 是 everything-claude-code 的灵魂，它应该包含五个固定模块：项目简介、技术栈、目录说明、命令约定、禁忌清单。以前面那个目录树里的your-project为例：

# your-project ## 项目简介 这是一个面向企业客户的跨平台数据看板系统，核心业务是实时报表生成与权限管理。 ## 技术栈 - 前端：React + TypeScript + Vite - 后端：Node.js + Express - 数据存储：PostgreSQL + Redis ## 目录说明 - src/api 下存放所有接口定义，禁止在页面组件中直接访问数据库 - src/shared 存放跨端共用类型，改动前需确认不会破坏其他模块 ## 命令约定 - 使用 pnpm 作为包管理器 - 测试只跑 pnpm test -- --runInBand ## 禁忌清单 - 不得修改 migrations 目录下已发布的迁移文件 - 不得在业务代码中引入 console.log 调试输出

这个文件的作用是给助手一个精确的项目地图。它不用大段讲解背景故事，而是把关键坐标和红线标出来。助手读完之后，即使在全新的会话里，也能快速进入“这个项目的资深成员”状态。

3.3 让规则不容易被忽略的写法

光有 CLAUDE.md 还不够，写法决定执行率。我实际测试下来，以下四个写法技巧见效最快：

第一，规则编号。每条规则前面加编号，比如[R-001]。当助手执行偏离时，你只需要说一句“违反 R-001 了”，它会立刻知道错在哪里。

第二，多用“当...时，必须...”句式。这种触发条件式表达比“要保证代码质量”这种空泛指示有效得多。

第三，重要规则重复但不同角度。在 CLAUDE.md、自定义命令、settings.json 三个地方都会出现“不要修改 lock 文件”，重复不是浪费，而是增加被遵守的概率。

第四，让规则主动被触发。用 Hook 脚本读取 CLAUDE.md 里的关键词，在关键工具调用前做自动拦截。这条我放到后面章节细讲。

4. 连接自动化：settings.json、自定义命令与 Hook

4.1 settings.json 里的权限棋盘

settings.json 是 everything-claude-code 的控制面板。我一般至少配置三块内容：权限白名单、模型选择、Hook 挂载点。

下面这个配置是我常用的模板：

{ "permissions": { "allow": [ "Bash(pnpm run lint)", "Bash(pnpm test:*)", "Read" ], "deny": [ "Bash(git push --force)", "Bash(rm -rf *)" ] }, "hooks": { "preToolCall": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "node .claude/hooks/guard-write.mjs" } ] } ] } }

把频繁使用的测试命令加入allow，能省掉大量弹窗确认；把危险操作加入deny，则是安全底线。权限配置的核心原则是“最小够用”，不是越多越好。白名单太宽，助手会越来越“胆大”；白名单太窄，你光点确认框就能点到手抽筋。

4.2 自定义命令：把重复任务封装成一句话

自定义斜杠命令放在.claude/commands/目录下，文件名就是命令名。比如创建一个review.md，那么在对话框里敲/review，助手就会执行这个文件里定义的任务。

一个实用的代码审查命令模板：

执行一次代码审查，审查范围是当前会话刚修改过的文件。 审查重点： 1. 是否存在未捕获的异步错误 2. 是否有重复逻辑可以抽取公共函数 3. 边界条件是否处理完整，尤其是空值和超长输入 4. 是否违反项目 CLAUDE.md 中 R-002 关于模块边界的约定 输出格式： - 按严重程度列出问题清单：高、中、低 - 每个问题给出修改建议和对应文件路径 - 最后说明哪些问题必须先修复才能提交

同样地，你可以建commit.md、test.md、todo.md等命令。这些文件都受 Git 版本控制，团队其他人拉下来就是一套统一的工作流。

4.3 Hook 脚本：给工具调用装一道安全门

Hook 是 everything-claude-code 里最有“工业感”的部分。它能在工具调用前后执行一段外部脚本，拦截非法操作。比如我要防止助手误改 protected 文件，就在preToolCall钩子里挂一个守卫脚本。

简单示例guard-write.mjs：

import { readFile } from 'node:fs/promises'; const toolInputRaw = process.env.CLAUDE_CODE_TOOL_INPUT || '{}'; const toolInput = JSON.parse(toolInputRaw); const filePath = toolInput.file_path || ''; const protectedList = [ 'node_modules/', '.git/', 'package-lock.json' ]; const isProtected = protectedList.some((item) => filePath.includes(item)); if (isProtected) { console.error(`Blocked: ${filePath} is in protected list`); process.exit(2); } process.exit(0);

这段脚本的意图很清晰：拦截任何写入node_modules或修改 lock 文件的行为。如果进程退出码为 2，Claude Code 会判定该工具调用被拒绝；退出码为 0 则放行。你可以根据项目实际需要扩展保护名单，比口水式规则强硬得多。

5. 保姆级落地：从零搭一套 everything-claude-code

5.1 第一步：创建全局配置目录

打开终端，执行：

mkdir -p ~/.claude/commands touch ~/.claude/CLAUDE.md ~/.claude/settings.json

全局文件夹创建成功后，先把前面 3.1 节那份通用编码纪律写入~/.claude/CLAUDE.md。虽然这一步看起来简单，但它奠定了所有项目的“公共记忆”基础。

5.2 第二步：给项目写入唯一上下文

进入你的项目目录，执行：

mkdir -p .claude/commands .claude/hooks touch CLAUDE.md .claude/settings.local.json

然后在CLAUDE.md里填入项目专属的信息。注意，项目 CLAUDE.md 不要照搬全局模板，而是要聚焦目录结构、技术栈、测试命令以及特殊禁忌。每新增一个信息，都问自己一句：这个信息对当前项目是否真的必要？不必要的东西反而会稀释重点。

5.3 第三步：配置权限和命令文件

先编辑.claude/settings.local.json，把你在第 4 章看到的权限模板放进去，再根据项目实际修改。同时创建一个.claude/commands/review.md，内容可以先用第 4 章那段审查模板临时占位，后续再按团队风格调整。

完成后，目录结构应该是这样的：

your-project/ ├── CLAUDE.md ├── .claude/ │ ├── settings.local.json │ ├── commands/ │ │ └── review.md │ └── hooks/ │ └── guard-write.mjs

5.4 第四步：验证配置是否真的生效

重启 Claude Code，在会话里敲/status（不同版本命令可能略有差异）或直接问它：

“请阅读项目 CLAUDE.md，并总结本项目几条核心纪律。”

如果助手能准确说出“不修改迁移文件”“测试用 pnpm”这类细节，说明配置已经生效。接着再让它执行一次/review，看它是否会按照设计的审查清单逐项检查。这一步验证很关键，配置文件的语法错误一般都会在这里暴露。

5.5 第五步：把配置纳入版本管理

在项目根目录执行：

git add CLAUDE.md .claude git commit -m "chore: add everything-claude-code config"

全局配置虽然没有和项目绑定，但我也建议单独建一个 dotfiles 仓库管理。这样一旦你把某个项目克隆到新电脑，git pull之后，整套助手配置立即可用，不需要重新写一遍。

6. 实战踩坑记录：常见问题与排查技巧

6.1 规则写了，助手却不执行

这是最常见的问题，十次里面有八次是配置文件优先级出了问题。Claude Code 会按一定顺序读取全局 CLAUDE.md、项目 CLAUDE.md、子目录 CLAUDE.md，越靠近当前工作目录的规则优先级越高。如果你发现项目规则被全局规则“压住”了，先确认全局里有没有冲突条款。另一个隐蔽原因是文件编码或换行符问题，Windows 用户尤其注意要把文件保存为 UTF-8 和 LF 换行。

自查顺序建议：先问助手“你现在读到的全局规则有哪些，项目规则有哪些”，看它的复述是否偏离你写的原文。有偏差就检查文件路径、编码、是否在正确的目录层级。

6.2 上下文越聊越长，回答越来越飘

长会话后期，助手表现会明显下降，这不是错觉。上下文窗口里的关键细节被大量中间推理挤占，规则记忆被稀释。我这里的处理办法有两个：

一是关键动作拆成短会话，提高/todo或自定义命令的使用频率，每个子任务完成后就开新会话，让规则重新“清零加载”。

二是在 CLAUDE.md 里明确写“当回答问题时，先给出结论，控制解释不超过 5 行”。这个约束能有效减少无意义的长篇推理，把上下文留给真正重要的信息。

6.3 Hook 脚本写了但没生效

先检查 matcher 写没写对。比如你拦截的是 Edit 和 Write，matcher 写成"Edit|Write"是正则语法；写错成"Edit,Write"很可能不会匹配任何工具调用。再检查脚本是否有执行权限，以及脚本内部抛出的异常是否被正确捕获。

还有一个很容易忽略的点：Hook 脚本的运行环境。如果你的脚本依赖某些 npm 包，但全局环境没安装，脚本就会静默失败。我一般把 Hook 相关脚本的依赖声明在项目package.json里，避免环境不一致。

6.4 多个项目规则互相串台

当你同时维护多个项目时，容易发生“这个项目的助手用另一个项目的规则”这种乱象。排查时先看助手当前工作目录是不是在正确的项目根目录。如果你从子目录启动会话，它会优先查找子目录里的 CLAUDE.md，下行目录距离更近。建议固定从项目根目录启动助手。

另外，我习惯在每份项目 CLAUDE.md 里写一句“本项目禁止引用其他项目结构”，这句话能很有效地阻止跨项目联想。

6.5 权限配置被合并后失控

前面提过，全局和项目的 settings.json 权限会合并。有一次我把全局 permissions 开了很宽的 Bash 白名单，项目配置里想收紧，结果助手依然能执行危险命令，就是因为合并机制给了我宽松的权限集合。解决方法是：在项目 settings 里用"disableGlobalSettings": true类配置切断继承（具体开关名以当前版本文档为准），让项目独立成城邦。

7. 最后分享几个让 everything-claude-code 更值钱的习惯

这套配置我能用到现在，靠的不只是文件堆叠，还有几个习惯。最有用的一条是：给每条规则加版本号。规则不是一成不变的，项目演进后旧规则可能反而拖后腿。我每调整一次 CLAUDE.md，就把版本号升一下，并在规则变更记录里写一行原因。这样助手行为一旦“突变”，我可以直接查看哪些规则在最近一次变更中被改掉，回滚也方便。

第二个习惯是让助手自己维护一份“规则摘要”文件。我会在项目 CLAUDE.md 里指示助手：“每次完成较大任务后，在 .claude/log.md 中追加一条当次任务的关键纪要和规则建议。”这些日志累积到一定程度，就是你调优 everything-claude-code 的最佳数据源。

第三个习惯是少做“一次性对话”，多把重复劳动沉淀成自定义命令。只要你发现自己连续三次让助手做同一类事情，就应该停下来把它升级成一个.claude/commands/xxx.md。这个过程消耗的时间不会超过十分钟，但之后每次调用，都是免费的。

我个人实际使用中的体会是，配置体系的最大价值不是让 AI 变得“更强”，而是让它的输出变得“可预期”。一个行为不稳定的高效助手，远不如一个稳定输出中上水平的助手让人放心。everything-claude-code 这套东西，本质上就是用工程方法驯服不确定性的过程。希望这篇全流程教程能帮你把 Claude Code 真正变成自己的秘密武器。