我见过很多人第一次打开 Claude Code敲两句需求等它把代码改完然后关掉终端。这样用当然没问题但等于你把一台可编程的机器人当成固定电话用。真正让 Claude Code 产生质变的是那些藏在配置目录里的扩展位——CLAUDE.md、自定义 slash 命令、MCP 接入、hooks 钩子。这也是标题里“魔改”二字的准确含义不是去破解它的内部实现而是把官方留出的扩展机制用透让它从一个“问答工具”变成一个“能按你的规矩干活的小团队”。这篇文章我按一条完整的路径来讲从安装到登录从第一份规则文件到自定义命令再到外部工具接入和自动化拦截最后给一套能直接抄的完整示例。适合三类人看刚开始摸索的第一次用户、已经用了但觉得它“不够听话”的进阶用户、想在团队里统一 AI 工作方式的组织者。我会把每一步背后的原因讲清楚也会把踩过的坑原样摆出来。1. 先想清楚Claude Code 的“魔改”到底改哪里1.1 魔改的边界别把“定制”理解成破解“Mod”这个词在中文社区里容易被联想到游戏模组、破解补丁似乎要动到软件本体才算魔改。但在 Claude Code 这个工具上真正的魔改恰恰是另一条路官方在架构上留了一堆扩展点你的任务是把这些扩展点填满。Claude Code 本质是一个运行在终端里的 AI 编程代理它能看到文件、执行命令、调用工具再根据你的自然语言指令完成任务。模型本身的智商是训练出来的但它的“习惯”“风格”“边界”完全由上下文和配置决定。默认状态下它是一个通用的 AI 工程师定制之后它可以是只认你那一套代码规范、先写计划再动手、遇到违规直接罢工的项目成员。我见过有人花很大力气去改安装包、替换模型参数最后既不安全也不可持续。正确的做法是顺着官方支持的机制玩你写规则它读规则你加工具它用工具。改的是配置不是软件本体这才是对“魔改”的正确理解。1.2 四个官方扩展点CLAUDE.md、slash 命令、MCP、hooksClaude Code 的扩展机制可以拆成四层每一层解决不同的问题。我整理了一张表方便你对照理解扩展点作用解决的核心问题难度CLAUDE.md写入长期记忆和规则每次会话自动加载让 AI 记住你的技术栈、代码风格、工作流程低自定义 slash 命令把一段复杂提示词封装成一条命令高频动作不用每次重新描述中MCP 服务器接入外部工具和数据源让 AI 能查数据库、调接口、操作外部系统中高Hooks 钩子在 AI 执行动作的前后注入脚本自动化拦截、校验、通知高这四层可以单独用也可以组合。大多数人的魔改路径是先写 CLAUDE.md再封装 slash 命令接着接 MCP最后上 hooks。一层比一层重效果也一层比一层深。1.3 魔改前和魔改后的体感差异我举个团队里的例子。某小组用默认配置跑了一个月AI 能写代码但每次提交前还要人肉检查风格、补测试、梳理影响面。后来花了一个下午做了基础魔改项目级 CLAUDE.md 里写清楚技术栈和命名规范加了两个自定义命令/review和/testplan再配了一个 PreToolUse hook 拦截带TODO的写入。一个月后再看AI 生成的代码风格稳定了很多提交流程里少了大半重复劳动。默认配置不是不好而是“通用”。通用意味着它要适配所有人因此不可能贴合你的具体场景。魔改做的事就是把这些通用参数调成你的专属参数。你喂给它的规则越具体它产出的东西才越接近你想要的。2. 从零开始安装、登录与目录准备2.1 安装前的三件事运行时、包管理器、账号先把前提条件确认好省得装到一半卡住。Claude Code 依赖 Node.js 运行时环境建议用 LTS 版本。如果你的机器上还没有先装运行时版本太旧的话很多新功能跑不起来这是最常见的启动报错来源。安装方式很直接用包管理器装官方 CLI 包npm install -g anthropic-ai/claude-code装完先看版本确认安装成功claude --version如果你更习惯用原生安装器去官方文档复制对应系统的命令即可。版本迭代很快我强烈建议你在动手之前先跑一下claude --help看当前版本的命令列表因为有些子命令在新版本里改过名字后面我会不断提醒这一点。账号方面需要有一个已开通对应订阅的 Claude 账号。第一次启动会走登录流程跟着提示操作就行。2.2 初始化工作目录别让配置污染全局第一次启动之前先规划好目录。我的建议是新建一个专门的项目目录在这个目录里跑claude。为什么因为 Claude Code 会在当前目录下生成.claude文件夹里面装着该项目专属的配置、命令、会话记录。如果你直接在用户目录或者系统根目录启动配置会散落到奇怪的地方后面排查问题会非常痛苦。启动命令cd /path/to/your/project claude首次启动会进入交互界面确认登录状态后你可以先问它一句“请读取当前目录结构告诉我你看到了什么。”这是一个最小体检能同时验证登录是否成功、文件读取权限是否正常、基础上下文是否加载。登录认证信息会存在用户目录下这部分是全局的项目之间共享。而.claude下的其他内容默认属于当前项目。2.3 第一次启动的三项体检新装完的 Claude Code我建议不要急着干正事先完成三项检查。第一项确认加载了哪些配置。直接在对话里问“你当前加载了哪些配置文件分别来自哪里”如果它列出了多个 CLAUDE.md说明目录选择正确。第二项确认权限弹窗策略。让它执行一次ls或读取一个文件观察它是否主动询问权限。默认情况下写操作和需要联网的命令会触发确认这个机制很关键后面魔改时要通过 permissions 控制。第三项确认日志目录可写。Claude Code 会把会话记录写到用户目录下的 projects 子目录如果这里有权限问题会导致会话无法恢复功能虽然能跑但一断开连接上下文就丢了。这三项体检总共花不了五分钟却能帮你提前排除一半的“为什么我的配置没生效”类问题。2.4 目录地图用户级和项目级分别放在哪搞清楚配置目录的划分是魔改的第一步。我常用一张表记录这些路径逐步魔改时对照着放路径类型作用~/.claude/CLAUDE.md用户级规则全局生效所有项目共用./CLAUDE.md项目级规则当前项目生效优先级更高./.claude/settings.json项目级设置权限、hooks、环境变量~/.claude/settings.json用户级设置全局权限、hooks~/.claude/commands/*.md用户级命令自定义 slash 命令全局可用./.claude/commands/*.md项目级命令自定义 slash 命令仅当前项目注意一个细节项目级配置的优先级高于用户级。也就是说如果项目级 CLAUDE.md 说“不要写单元测试”用户级说“每个函数都要有测试”那模型会听项目的。这个覆盖关系很多初学者搞反导致改了用户级配置却觉得“AI 不听话”其实是被项目级规则压制了。3. 第一层魔改用 CLAUDE.md 把规则焊进模型记忆3.1 三个作用域用户级、项目级、团队级CLAUDE.md 是 Claude Code 的“永久记忆”每次会话开始都会自动注入上下文不需要你重复说明。它有三级作用域用户级、项目级、团队级。个人使用最多的是前两级。用户级文件在~/.claude/CLAUDE.md适合放你的通用偏好比如“所有代码注释用中文”“日志输出保持简洁”“我先看方案再动手”。这些偏好和项目无关跟你个人强相关。项目级文件在项目根目录的CLAUDE.md适合放这个项目的专属约定比如技术栈、目录结构、测试命令、禁用的第三方库。它是跟着项目走的放进版本管理之后每个克隆这个仓库的人都会自动继承相同的 AI 行为准则。团队级文件一般由组织托管统一推送个别开发者甚至改不动。它的存在意义是一个团队用同一套 AI 工作规范避免不同成员的 AI 输出风格千差万别。3.2 一份可以直接抄的规则骨架给你一份我实际在用的骨架按这个结构填内容就不会把规则写成没人看得懂的废话。直接复制到项目根目录的CLAUDE.md里把括号里的内容替换成你的实际情况# 角色 你是本项目的资深开发助手先理解再动手不要急于给结论。 # 技术栈 - 前端Vue 3 TypeScript Vite - 后端Node.js Express PostgreSQL - 测试Vitest Testing Library # 代码风格 - 所有新函数必须包含类型标注 - 组件命名使用 PascalCase变量命名使用 camelCase - 公共方法必须有注释说明输入、输出和边界情况 - 禁用 any 类型除非有注释说明原因 # 工作流偏好 1. 接到任务后先列出实施计划确认后再动手 2. 修改代码前先梳理影响范围 3. 完成一个功能后主动提示可以运行哪些测试 # 负面清单 - 不要修改 lock 文件除非明确要求 - 不要在代码中留下 console.log - 不要一次性大改多个无关文件这里最有价值的是“负面清单”。模型默认倾向于讨好你、多干事如果你不告诉它哪些事别做它会顺手帮你改了不该改的文件。写清楚边界之后它的“越界”行为会大幅减少。3.3 反面教材口号式规则为什么没用很多人第一次写 CLAUDE.md写出来的是“代码质量要好一点”“注意安全”“保持整洁”。这些话全对但全没用。因为模型没法验证“什么是好一点”它只能验证“函数是否有类型标注”“是否包含 console.log”。我改造过一个同事的规则文件。他原来写的是“请写出高质量的、可维护的代码。”我把这句话换成“所有公共函数必须有 JSDoc 注释行数超过 80 行必须拆分为多个函数。”第二天他跑来跟我说效果好得多。原因很简单可验证的规则才叫规则不可验证的规则叫愿望。写完之后还有一个自检动作把规则中最核心的三条抽出来直接问 Claude Code“请复述你加载的项目规则并告诉我哪三条最重要。”它的回答能帮你确认哪些规则真正被理解了哪些被淹没了。3.4 记忆分层法常量规则和任务上下文分开CLAUDE.md 不是让你把所有东西都塞进去的。我推荐“记忆分层”的做法把稳定的“常量”写进 CLAUDE.md把会变的“变量”留在对话里。举个具体例子。技术栈、代码风格、禁止事项属于常量写进项目 CLAUDE.md半年都不怎么变。而“这次重构要把模块 A 拆成模块 B 和 C”“本周的目标是优化首屏速度”属于变量应该在会话里用自然语言给出。如果你把变量也写进 CLAUDE.md会面临两个问题一是文件越来越长挤占上下文空间二是任务结束后忘了删留下过期指令干扰后续会话。所以我的习惯是CLAUDE.md 只做减法——只放长期有效的规则并且定期检查清理。4. 第二层魔改自定义 slash 命令把高频动作压成一行4.1 内置命令和自定义命令的关系Claude Code 自带一些斜杠命令比如/help、/clear、/compact这些是“系统功能”。而自定义 slash 命令是“提示词模板”本质上是把一个复杂的、固定流程的指令存成一个文件输入/命令名就能触发。为什么要做这一步因为你会发现有些任务你每天都在重复比如“帮我看一下最近的改动有什么风险”“给这个模块补测试计划”“生成接口文档”。每次手打一大段描述既慢又容易漏细节。自定义命令把这段描述固化下来还带上参数一条命令就能启动一个完整流程。它的原理并不复杂你输入/review之后Claude Code 读取对应的.md文件把文件内容作为系统提示词注入对话。所以本质上slash 命令是“可触发的提示词包”。4.2 建命令文件目录、frontmatter、参数自定义命令放在两个位置用户级~/.claude/commands/或项目级.claude/commands/。文件名就是命令名比如review.md对应/review。文件开头有一段 YAML frontmatter用来告诉系统这个命令的基本信息。最常用的是description和argument-hint--- description: 对最近的代码改动做评审输出影响面、风险和建议 argument-hint: 可选指定评审重点例如 /review 支付模块 --- 请对最近的代码改动做一次代码评审 1. 先查看 git diff 和最近提交记录 2. 梳理改动涉及的文件和影响范围 3. 检查是否命中项目 CLAUDE.md 中的代码风格规则 4. 输出影响面分析、风险点、修改建议 评审重点如果有$ARGUMENTS$ARGUMENTS会把你在命令后面输入的参数原文填充进来。如果你需要单独引用第一个参数和第二个参数可以用$1、$2。参数不是必填项但给一个argument-hint可以让使用者知道该怎么填。4.3 三个可以直接抄的命令模板下面三个命令是我在不同项目里长期在用的直接复制到你的commands目录就能用。第一个是评审命令上面已经给了。第二个是文档生成命令--- description: 为指定文件生成 API 文档 argument-hint: 必填目标文件路径例如 /doc src/services/user.ts --- 请为 $1 文件生成 API 文档 1. 读取该文件梳理所有导出函数、类、接口 2. 每个导出项输出名称、签名、参数说明、返回值、抛出的异常 3. 标注需要调用方特别注意的边界情况 4. 文档格式使用 Markdown按功能模块归类第三个是测试计划命令--- description: 根据最近改动生成测试计划 argument-hint: 可选指定要覆盖的模块 --- 请根据最近的代码改动生成测试计划 1. 查看 git diff 了解本次改动的范围 2. 识别每条改动对应的业务逻辑和边界条件 3. 为关键路径设计测试用例包含正常流、异常流、边界值 4. 标注哪些用例当前测试代码已经覆盖哪些需要补充 5. 输出一份 Markdown 格式的测试计划这三个命令的共同特点都包含明确的步骤编号都要求先读取信息再输出都强调了输出格式。提示词模板里最忌讳的是只有一句话“帮我评审代码”模型不知道该按什么标准评审结果就是泛泛而谈。4.4 命令联动让 slash 命令组合起来自定义命令还可以互相调用。比如你在/review文件末尾加一句“如果发现存在风险点生成一份修复任务清单并调用/testplan生成针对改动的测试计划。”当你触发/review时模型可能就会自动衔接/testplan这个命令。但这里有个不稳定的点Claude Code 会不会真的调用另一个命令取决于模型对当时上下文的判断不是强制行为。如果你需要强制的流程串联交给 hooks 更可靠下一章会讲。slash 命令适合“引导式”流程hooks 适合“强制式”流程两者场景不同。4.5 调试和迭代不要一次写太复杂我给新手的建议是第一个自定义命令永远是最基础的那种固定提取某一类信息。先用/plan命令让模型输出实施计划跑通了再加步骤。等模型每一次的输出都稳定符合预期再往里面加条件分支。调试 slash 命令有一个小技巧命令写完后用一个最小的测试输入跑一遍观察它有没有漏步骤。如果它漏了多半是命令里的步骤写得太隐晦。把它改成“第几步做什么输出什么”这样的显式结构模型的完成度会明显提升。5. 第三层魔改MCP 接入给 Claude Code 装外部器官5.1 MCP 一句话解释一个外挂工具的通用协议MCPModel Context Protocol是让 AI 工具能调用外部服务的标准化协议。如果你熟悉手机应用商店里的“插件”MCP 服务器就相当于 Claude Code 的第三方插件生态——通过它模型可以读数据库、查服务器状态、操作代码托管平台、发消息通知。模型本身不具备“主动联网调用”能力它的知识截止于训练时间也只能通过内置工具操作本地文件。MCP 把外部世界的操作能力接进来相当于给 Claude Code 装了眼睛和手。装了 MCP 之后你直接说“查一下这张订单的支付状态”模型就能通过数据库 MCP 执行查询并返回结果。5.2 添加一个 MCP 服务器两种方式添加 MCP 服务器的命令结构是claude mcp add 服务器名称 -- 启动命令比如你想接一个本地数据库查询服务本地跑了一个标准的 MCP 服务进程那么注册方式就是claude mcp add project-db -- uvx --from 某个MCP服务包注册完成后用claude mcp list查看全部服务器用claude mcp get project-db查看某个服务器的配置详情。如果服务器配置错了用claude mcp remove project-db删掉重来。另一种方式是在配置文件里直接声明适合团队统一分发。在.claude/settings.json里加一段mcpServers字段写清楚每个服务器的命令参数。项目成员拉取代码后启动 Claude Code 就能自动加载这些 MCP 配置不用每个人手动add。5.3 安全接入的四条军规MCP 接入外部系统安全是第一优先级。我总结四条必须遵守的军规第一数据库连接用只读账号。查询类 MCP 绝对不要用管理员账号杜绝“AI 帮你把数据库清空”的极端情况。我见过不止一次因为权限过大导致 AI 误改线上数据的例子教训太深刻了。第二文件类 MCP 限定目录范围。如果 MCP 提供文件读写能力启动参数里就要限定根目录只允许它操作指定文件夹。第三最小工具集。刚开始接入时只挂一个最必要的工具验证整体流程跑通后再逐步增加。给模型的工具越多它选错工具的概率也越大。第四敏感信息不写进配置。MCP 服务器需要的 API 密钥、数据库连接串通过环境变量注入不要直接写在settings.json里。否则这个文件一旦被提交到仓库等于把密钥公开了。5.4 连接失败的高发原因与排查顺序MCP 时好时坏是常见的坑我按出现频率排序给你症状最可能的原因处理方式mcp list有但调用报错环境变量没传给 MCP 进程在启动命令前注入env确认子进程能读到返回 JSON 解析失败服务进程往 stdout 打印了非协议内容检查服务日志去掉多余打印确保只输出协议 JSON工具调用超时服务启动慢或网络不通先手动运行启动命令看它能否在几秒内就绪路径含空格导致启动失败引号处理不对在claude mcp add时整条命令加引号包裹配置生效但无法访问MCP 记录在用户级而你在项目里用claude mcp list确认作用域或用项目级配置覆盖排查的顺序我一般是这样先看mcp get拿到的配置对不对再手动在终端里执行启动命令接着用claude mcp list确认注册状态最后在对话里让它调用一次。一级一级往后退基本能在十分钟内定位问题。5.5 实测先跑通命令再接 AI我有一个习惯在把任何 MCP 接给 Claude Code 之前先自己在终端里把它跑通。比如你要接一个查询服务先手动执行启动命令确认它输出的是标准 MCP 初始化响应然后再注册给 Claude Code。这一步能过滤掉一半的无效接入。接好之后第一句测试命令不要太复杂“请调用 project-db 查询用户表有多少条记录。”如果模型能正确调用并返回结果说明链路已经通了。接下来再去慢慢扩展使用场景。MCP 是功能强大的扩展点但它也是最容易翻车的一层稳扎稳打远比一步到位可靠。6. 第四层魔改Hooks 自动化在关键节点注入拦截6.1 五个生命周期点什么时机注入脚本Hooks 是 Claude Code 里的自动化钩子能在它执行动作的特定时机触发外部脚本。这就像给 AI 装上护栏和哨兵在关键节点检查、拦截、通知。我用得最多的是这几个时机PreToolUseAI 调用工具之前触发。最适合做拦截比如禁止写入某些文件、禁止执行危险命令。PostToolUseAI 调用工具之后触发。适合做校验比如检查生成的文件是否符合规范。UserPromptSubmit你提交提问时触发。可以在这里做输入过滤或预处理。NotificationAI 需要请求权限或完成任务时触发。可以接消息通知。Stop一轮任务完成时触发。可以自动整理总结、清理临时文件。理解了时机才能设计出合理的自动化。钩子不是越复杂越好而是要在合适的位置做合适的事。6.2 钩子脚本的输入输出契约hooks 配置写在settings.json的hooks字段里。一个典型的最小配置长这样{ hooks: { PreToolUse: [ { matcher: Write|Edit, hooks: [ { type: command, command: python ~/.claude/hooks/check_todo.py } ] } ] } }这里面matcher匹配工具名Write|Edit表示凡是写文件和编辑文件的操作都触发。脚本通过标准输入接收一段 JSON里面包含工具名、输入参数等上下文信息。脚本退出码是核心约定退出码0校验通过放行。退出码2校验失败。在PreToolUse中会阻止工具执行在PostToolUse中会把错误反馈给模型模型看到后通常会主动修正。在PreToolUse里用退出码2是强制拦截的最有效手段。6.3 一个拿来即用的拦截脚本我给你一个最简单的拦截逻辑任何写入文件中如果出现“TODO”字样就阻止写入。完整脚本思路如下#!/usr/bin/env python3 import sys import json data json.load(sys.stdin) tool_name data.get(tool_name, ) tool_input data.get(tool_input, {}) # 只看文件写入相关工具 if tool_name not in (Write, Edit, MultiEdit): sys.exit(0) file_path tool_input.get(file_path, ) content tool_input.get(content, ) if TODO in content: print(f拦截{file_path} 中存在残留的 TODO 标记请先处理再提交。) sys.exit(2) sys.exit(0)把脚本放到~/.claude/hooks/check_todo.py在settings.json里配上前面的 hooks 配置然后给脚本执行权限。之后你再让 Claude Code 写代码凡是带 TODO 的写入都会被拦截模型会收到错误信息并主动修正。这个脚本虽然简单但展示了 hooks 的核心逻辑读 JSON 上下文、做判断、用退出码控制流程。往这个骨架里加逻辑就能实现更复杂的功能比如检查是否修改了 schema 文件但没写迁移脚本、是否在提交信息里缺少编号等。6.4 什么时候别用 hookshooks 功能强大但不是什么场景都适合。如果你只是在 CLAUDE.md 里写一句“不要留下 TODO”模型大概率会遵守那就没必要上 hook。hooks 的价值在于“必须遵守”的场景比如安全红线、上级检查、数据合规这些不能靠模型自觉必须强制执行。还要警惕递归。如果你的 hook 会触发修改文件而修改文件又触发了同一个 hook就会无限循环。解决办法是 hook 脚本里过滤条件写严格比如只匹配 src 目录下的文件、只匹配特定后缀。hooks 还会拖慢每次操作。每次 Write 都要跑一遍脚本如果你把脚本写得很重比如调用外部 API体验会明显变卡。所以 hook 脚本要尽量轻量逻辑复杂就拆到异步任务里不要阻塞主流程。7. 魔改翻车现场五个高发问题与排查链路7.1 症状一改了 CLAUDE.md模型根本不听这是出现频率最高的问题规则写了AI 也复述了第二天它又开始自由发挥。排查链路先确认作用域。用“你加载了哪些配置”确认文件确实被读取了再看内容本身是否属于可验证规则如果是“代码写得好一点”这类口号立刻改成可验证条款最后检查规则之间是否自相矛盾比如 CLAUDE.md 说“所有函数都要有注释”另一个规则文件说“保持简洁避免冗余注释”模型面对冲突时往往会选更模糊的那个解释。7.2 症状二自定义 slash 命令不见了明明放了review.md输入/review却提示命令不存在。先检查文件名和后缀——文件名不能有空格后缀必须是.md。再确认放置路径项目级命令放.claude/commands/用户级放~/.claude/commands/放反了在当前项目里自然看不到。最后在对话里输入/help查看命令列表如果列表里有但无法触发多半是 YAML frontmatter 格式出错少了一个字段或者引号没闭合。7.3 症状三MCP 时好时坏昨天还能用今天不行了MCP 类问题最典型的特征是“间歇性”。链路很长注册配置 → 启动命令 → 网络连接 → 数据格式 → 模型调用任何一环抖动都会表现为“时好时坏”。排查顺序我先看日志Claude Code 的会话日志在用户目录的 projects 子目录下MCP 的报错信息会出现在里面。接着手动执行 MCP 的启动命令确认它单独跑没有问题。如果单跑没问题但 AI 调用失败再检查是不是模型同时加载了太多工具导致调用参数拼接出错。最后用最小复现临时只挂这一个 MCP其他全部去掉如果恢复正常了再一个一个加回来定位干扰项。7.4 症状四hook 疯狂触发或者卡死hook 明显的故障是“重复触发”。最常见的原因是 matcher 写得太宽比如Write|Edit然后脚本内部又修改了文件修改动作再次触发同一个 hook形成循环。解决办法是收紧 matcher或者在脚本内部加一个跳过逻辑处理过的文件不再处理。卡死的另一个原因是脚本依赖了交互式输入。hook 脚本必须能无人值守运行任何input()、等待键盘操作的逻辑都会让它悬在那里直到超时。写 hook 脚本时我习惯先设置一个超时保护再在关键步骤打印日志剪掉所有交互逻辑。7.5 症状五权限失控模型总在问或者总不问权限问题分为两个极端。一个极端是模型每做一步都弹确认框烦到你不想用另一个极端是模型什么都能干删错了文件你事后才知道。两个都要通过settings.json里的permissions字段调节{ permissions: { allow: [ Read, Bash(git:*) ], deny: [ Bash(rm:*), Bash(drop:*) ], ask: [ Write, Edit ] } }allow是无条件放行deny是无条件拒绝ask是每次询问。这三个清单是按具体工具的规则匹配的规则越具体越好比如Bash(git:*)只放行 git 命令Bash(rm:*)直接拒绝所有删除命令。调权限的原则是让 AI 有事干allow常用操作、别乱干deny危险操作、关键时刻问你ask高风险操作。7.6 翻车排查的通用方法论所有翻车问题最后都能归纳到一条排查主线上最小复现 二分定位 日志验证。最长遇到的场景是改了多处配置出了问题不知道是哪一处引起的。我的做法是先把所有自定义配置全部停掉回到最原始状态确认问题消失然后按 CLAUDE.md → slash 命令 → MCP → hooks 的顺序一次只恢复一层每恢复一层跑一次最小测试。搭配诊断命令claude config list查看当前生效配置用claude --help确认当前版本命令名这条主线能覆盖绝大部分配置类问题。8. 完整实战做一个“评审 提交”全流程助理8.1 目标定义让 AI 自己把关再放行这一节把前面四层魔改串起来做一个更完整的场景。某团队的需求是每次代码改动后希望 AI 自动做影响面分析、检查代码风格、阻止带 TODO 的文件写入并且在本地验证通过前不允许提交到仓库。一句话让 AI 像一个严格的评审人员先自检后放行。拆解下来需要三个能力评审规则CLAUDE.md、一键触发评审流程slash 命令、强制拦截违规写入和提交hooks。8.2 分步搭建规则、命令、钩子三件套第一步在项目CLAUDE.md里加入与评审相关的规则明确“改动涉及公共接口时必须更新对应文档”“新逻辑必须包含测试用例”这些硬性要求。第二步在.claude/commands/review.md放评审命令命令模板包含固定的步骤编号先 git diff再对照 CLAUDE.md 检查最后输出影响面、风险点和建议。同时放一个testplan.md用来生成测试计划。第三步在.claude/settings.json里配两个 hooks。一个用PreToolUse拦截Write|Edit检查内容是否包含 TODO 和调试日志另一个用PreToolUse的 matcher 匹配Bash(git:commit*)在提交前检查工作区是否还有未清理的调试残留。8.3 实测调整三次改进过程第一次实测就发现一个问题评审命令输出的影响面分析总是漏掉测试文件。原因是命令模板里只写了“查看 git diff”没有强制它关注测试目录。我修改了命令模板加了一句“特别关注 tests 目录下是否有对应更新”效果立刻改善。第二次实测遇到 hook 误伤TODO 拦截把第三方依赖目录里生成的临时文件也拦住了而那个目录本来就不需要走代码风格检查。调整方案是脚本里加过滤逻辑只检查项目源码目录跳过 node_modules 和 dist。第三次调整是提交拦截策略。最初的 matcher 是Bash(git*)结果连git status都被拦下来询问太影响体验。后来把范围缩到Bash(git commit:*)只在真正提交时拦截日常查询一概放行。8.4 后续扩展还能往哪里走这套“评审 提交”助理跑顺之后往上叠加扩展很自然。比如在Notificationhook 里接入团队消息渠道让 AI 完成任务时自动通知同事按仓库分支自动生成变更说明在Stophook 里读取本轮的 git diff 和提交信息整理成一份结构化的变更记录把命令和 hooks 配置放进团队共享配置仓库新成员克隆后即可获得同样的 AI 工作流。我自己的体会是别想着一步到位搭一个“终极系统”。Claude Code 的魔改是一个持续迭代的过程今天加一条规则明天调整一个 matcher每次改动只解决一个具体痛点积累一段时间后回头看你的 AI 助手和你刚安装时已经完全是两个物种了。这个从“能跑”到“好用”的打磨过程才是魔改最大的乐趣所在。