我最早接触 Claude Code 的时候它的定位很简单一个能跑在终端里的 AI 编程助手。当时我拿它当高级版补全工具用丢进去一个 issue 描述它帮我改文件、跑测试、提 commit。真正让我改观的是我开始翻官方文档里写 customization 的部分——原来这个工具允许你改的不只是 prompt而是它完整的运行机制。Claude Code 的 Mods 能力正在把它从一个 AI 工具变成一个可以被你重新设计行为模式的 AI 工具。这篇文章我围绕自己实际改造它的过程讲清楚运行机制到底指什么、能改哪些位置、怎么改才不会翻车给同样想深入玩转 AI 编程工具的人一套可落地的思路。1. 先搞清楚 Claude Code 的运行机制到底指什么1.1 CLI 工具的完整运转链路Claude Code 本质上是一个 Node.js 写的命令行程序。它的运行链路并不神秘你在终端输入自然语言指令程序把指令连同项目上下文一起打包成请求送到模型模型返回工具调用序列读文件、写文件、执行命令、搜索等程序实际执行这些调用再把结果回填给模型循环往复直到任务结束或者达到停止条件。以前我用 AI 编程工具的时候能动的只有输入侧——换个说法、换个 prompt期待输出好一点。但 Claude Code 把输入侧之外的东西全部暴露给了使用者。你可以干预上下文怎么拼、任务开始前要做哪些检查、工具执行前允不允许、工具执行完要不要追加验证、最后输出用什么样的风格。这些位置组合起来就是一个可以自定义的运行机制。这就像玩同一台游戏机以前你只能选择键位和画质现在你能改物理引擎、改掉落率、改 NPC 的行为逻辑。Mods 这个词放在这里非常贴切它指的不是简单的插件安装而是对工具本身行为逻辑的重新组装。1.2 可改造的六个切入面我自己的经验是先把改造面盘清楚再动手比直接抄别人的配置重要得多。Claude Code 的改造入口可以分成下面这六层改造层主要载体作用位置典型用途记忆层CLAUDE.md 文件系统提示词拼接阶段注入项目规范、架构说明、约束条件行为层Hooks 钩子工具调用前后、会话周期节点自动检查、拦截危险命令、记录结果交互层自定义斜杠命令、输出风格指令解析与输出格式化固化高频操作流程、统一回答形态能力层MCP 服务器工具集合扩展接入数据库、浏览器、内部服务配置层settings.json、环境变量全局参数与认证模型路由、权限策略、代理开关协作层git 管理的 .claude 目录多人共用团队级规范同步、新成员快速上手这六层不是并列关系而是嵌套关系。记忆层决定模型知道什么行为层决定它能怎么动作能力层决定它手里有什么工具交互层决定你怎么叫它干活。把它们组合起来才是真正意义上的改运行机制而不是在某一个文件里塞两行配置。2. 记忆层改造CLAUDE.md 与项目上下文的工程化2.1 CLAUDE.md 的加载规则Claude Code 的记忆机制核心是 CLAUDE.md。它遵循一套简单但容易误用的加载规则项目根目录的CLAUDE.md默认加载是项目的全局记忆。任意子目录里也可以放CLAUDE.md当对话涉及该目录时按需加载适合维护局部模块的专属约定。用户主目录下的~/.claude/CLAUDE.md是跨项目的个人偏好记忆。对话中可以用路径显式导入任意文件哪怕是不在当前目录树里的说明文档。刚开始我理解的记忆就是往文件里写一堆项目介绍。后来发现一个问题模型每次请求都要把这些内容拼进去写太多不仅费 token还会稀释真正的关键约束。记忆层改造的核心不在写得多而在写得准。2.2 一套可复用的记忆模板下面这个模板是我在多个项目里迭代出来的它解决了项目记忆到底该写什么的问题# 项目名 ## 一句话定位 这是一个面向 xxx 的 xxx 服务核心指标是 xxx。 ## 架构速览 - 前端React Vite代码在 apps/web - 后端Go PostgreSQL代码在 services/api - 关键链路gateway - auth - api - db ## 常用命令 - 启动开发环境make dev - 跑全部测试make test - 单测某个包go test ./internal/xxx -run TestXxx ## 代码规范 - 所有对外接口必须带超时控制 - 数据库迁移文件禁止修改只能新增 - 错误处理统一走 errors 包不直接 fmt.Println ## 高频任务约束 - 修改 API 时必须同步更新 OpenAPI 文档 - 涉及支付相关改动必须补测试且至少覆盖成功/失败两条路径 ## 禁止事项 - 不要用全局变量保存用户状态 - 不要引入未在 go.mod 中声明的依赖注意这些条目的写法全部是祈使句直接告诉模型做什么、不做什么。我见过很多人写项目应该注意代码质量这种废话模型看了跟没看一样。CLAUDE.md 的每一条都应该是可执行、可验证的指令而不是价值观宣传。2.3 记忆层最容易踩的坑第一个坑是记忆膨胀。我有个项目CLAUDE.md 写到了三百多行结果模型开始忽略前置约束反而过分关注低优先级内容。后来我在一个长对话里明显感觉它忘掉了最初的约束排查下来发现不是上下文窗口的问题而是太长的记忆让模型的注意力分配变得混乱。我的经验是项目级 CLAUDE.md 控制在 60 行以内超过就拆到子目录或做成导入的独立文档。第二个坑是优先级冲突。~/.claude/CLAUDE.md、项目级 CLAUDE.md、子目录 CLAUDE.md 同时存在时谁优先并没有一个绝对透明的规则。我遇到过一次全局记忆里写了所有代码用 TypeScript而某个子项目其实是 Python导致模型反复尝试生成.ts文件。解决办法是全局记忆只放通用习惯不碰任何可能与具体项目冲突的技术选型。第三个坑是把它当成普通文档写。CLAUDE.md 是要被模型逐字读取的不是给人读的 README。我后来养成了一个习惯每写一条就问自己如果我是模型看到这句话能产生一个确定的行为改变吗不能就删掉。3. 行为层改造Hooks 子系统的实战解析3.1 Hooks 触发的完整事件链如果说 CLAUDE.md 是给模型灌知识Hooks 就是在运行机制里插桩。Claude Code 的 Hooks 定义了一套生命周期事件每个事件发生时都可以执行外部命令并让命令的输出反过来影响工具行为。我实际用到的核心事件是这几个事件触发时机典型用途UserPromptSubmit用户提交指令后、发送给模型前改写问题、注入约束、拒绝敏感请求PreToolUse模型请求执行某个工具前安全检查、命令白名单、文件路径校验PostToolUse工具执行完成后自动格式化、补跑测试、校验产物Stop一次完整任务结束时生成总结、通知、上报结果SubagentStop子代理任务结束时汇总子代理产出SessionStart会话启动时初始化环境、打印自定义提示PreCompact上下文压缩前提取关键状态、防止丢失任务上下文配置入口是.claude/settings.json或~/.claude/settings.json。下面是我在一台 CI 机器上的真实配置片段{ hooks: { PreToolUse: [ { matcher: Bash, hooks: [ { type: command, command: python3 /opt/claude-hooks/check_bash.py \$CLAUDE_COMMAND\ } ] } ], Stop: [ { hooks: [ { type: command, command: bash /opt/claude-hooks/stop_report.sh } ] } ] } }注意matcher字段——它决定了钩子挂在哪个工具或命令上。Bash(git-*)只匹配 git 开头的命令Bash匹配所有 Bash 工具调用。挂得越细误伤越少。3.2 用 PreToolUse 做自动安全检查PreToolUse 钩子最有价值的用法是在模型真正执行命令前做一道闸门。比如我不希望模型在非交互会话里执行破坏性的 git 操作就写了这样一个检查脚本#!/usr/bin/env python3 import json import os import sys command os.environ.get(CLAUDE_COMMAND, ) blocked_prefixes [ git push --force, rm -rf /, kill -9, ] decision { hookSpecificOutput: { hookError: , permissionDecision: allow, permissionDecisionReason: } } for prefix in blocked_prefixes: if command.strip().startswith(prefix): decision[hookSpecificOutput][permissionDecision] deny decision[hookSpecificOutput][permissionDecisionReason] ( f命令 {prefix} 被项目安全策略禁止 ) print(json.dumps(decision)) sys.exit(0) print(json.dumps(decision))这里的关键是输出格式Hook 脚本往 stdout 打印一个 JSON其中的hookSpecificOutput.permissionDecision可以是 allow 或 deny。deny 会让工具调用被拦截模型会收到原因并尝试换一种实现方式。实际使用中我还加过路径校验——比如写文件时不允许模型往src/generated之外的目录输出。这个机制的威力在于你不是在 prompt 里请求模型别做某事而是在运行机制层面让它做不到某事。前者是可选的后者是强制的。3.3 Stop 钩子的实际用途Stop 钩子是我用得第二多的。它在一个完整任务结束或达到最大轮次时触发此时环境变量里有CLAUDE_MESSAGE和CLAUDE_SUMMARY。我曾经把它接到一个内部机器人上让 Claude Code 每次处理完需求后自动把总结发到团队群里#!/bin/bash summary$(cat EOF $CLAUDE_SUMMARY EOF ) curl -s -X POST http://internal-bot/send \ -H Content-Type: application/json \ -d {\channel\:\dev-report\, \message\:\$summary\}这样团队不用盯着终端也能知道 AI 助手这次帮忙改了什么、卡在哪里。Stop 钩子特别适合做事后处理因为此时所有上下文都已经结算完了。3.4 Hooks 调试踩过的坑Hooks 看着简单实际跑起来问题不少。我踩过三个比较典型的坑第一个是静默失败。Hook 脚本如果直接报错退出Claude Code 有时候只会把错误记到日志里对话照常继续你以为安全策略生效了其实根本没有。建议所有 Hook 脚本都加日志输出到固定文件并且先手动执行一遍验证输入输出。第二个是超时与性能。每个 Hook 都会增加一轮工具调用的延迟如果脚本里还要起 Python 环境、连数据库查参数一次会话能慢好几倍。我后来把所有高频 Hook 都改成纯 shell 或者 Go 编译成的单个二进制启动开销控制在十毫秒级别。第三个是全盘 deny反而更难控制。我之前把 SSH、curl 之类的命令全部拦住结果模型开始改用 Python 的 requests 库去实现同样的事情。安全钩子最好按前缀精确匹配而不是一刀切。你要拦的是某个具体行为不是某一类工具。4. 交互层改造自定义斜杠命令与输出风格4.1 自定义斜杠命令的制作方法斜杠命令是提高 Claude Code 使用效率最直接的方式。它本质上是把一段精心编写的 prompt 模板固化成可复用的命令放在.claude/commands/或~/.claude/commands/目录下文件名去掉.md就是命令名。我在团队项目里写过一个review命令--- description: 对当前改动做一轮代码走查 argument-hint: [scope] --- 请对 $1 范围内的代码改动做一次同行评审。 评审时严格按以下顺序执行 1. 先运行 git diff $1理解改动全貌 2. 检查是否引入了安全问题敏感信息、越权、注入 3. 检查是否遵守项目 CLAUDE.md 中的代码规范 4. 检查测试覆盖新增逻辑是否有对应测试 输出要求 - 按严重问题 / 建议改进 / 亮点三节输出 - 每个问题都必须给出文件路径和具体行号 - 不要输出泛泛的赞美使用的时候在终端敲/review src/services文件里的$1会被替换成src/services。除了$1到$9的位置参数还有$ARGUMENTS表示全部参数。命令里甚至可以加路径把其他文档一起导入上下文。建命令的文件名要克制。我见过有人一天建二十个命令最后自己都记不住。我的标准是某个操作每周至少重复三次才值得固化成命令。一次性的任务写 prompt 就行不要制造新的心智负担。4.2 多段命令与流程编排自定义命令文件里可以用分隔线把一段 prompt 拆成多个逻辑段落让模型分阶段思考。比如一个发布检查命令可以先让它跑测试再让它看变更集最后输出发布风险。这种编排比一段大而全的 prompt 效果稳定得多因为模型不会被一堆互相缠绕的要求搞晕。另一个实用技巧是组合使用导入和系统命令的CLAUDE.md引用。比如给某个子模块写一个独立的CHECKLIST.md然后在斜杠命令里用CHECKLIST.md导入命令就永远指向最新版的检查项不用每次改命令本身。4.3 输出风格改模型说话的样子Claude Code 还支持通过.claude/output-styles/目录定义输出风格并在settings.json里通过outputStyle字段指定。这个机制会把你定义的风格描述注入到系统提示词里影响模型回答的形态。比如做日常开发时我不希望模型长篇大论解释原理就定义了一个compact.md风格所有回答遵循以下规则 - 直接给出结论先说什么改了、为什么改 - 代码块之外的解释不超过三句话 - 不输出分析过程类的思考过程 - 遇到不确定的地方明确列出假设不要暗示自己已经确定实际用下来输出风格对体验的提升非常明显。它和 CLAUDE.md 的区别在于CLAUDE.md 约束的是行为输出风格约束的是表达。对 AI 编程工具来说这两者经常需要配套使用——行为改了但表达没改你依然会觉得它不像那么回事。5. 能力层改造MCP 与外部工具链注入5.1 MCP 为什么是外挂思路如果说 Hooks 是在现有工具链上插桩那 MCPModel Context Protocol就是给模型直接接新的工具仓库。MCP 的思路是把外部能力封装成标准协议模型可以像调用本地函数一样调用远程或本地服务。Claude Code 作为一个支持 MCP 客户端的运行时能动态加载这些能力。我把它理解成一个外挂工具栏。默认情况下模型手里只有读文件、写文件、执行命令这些基础工具接上 MCP 之后它可以查询数据库、操作浏览器、读写 Redis、调用内部接口。这等于重新定义了AI 编程工具能干什么的边界。5.2 给 Claude Code 接入 MCP 的实战配置MCP 服务器的接入有两种常见 transportstdio 和 SSE/HTTP。本地工具一般用 stdio远程服务一般走 HTTP。常用命令是# 添加一个基于 stdio 的 MCP 服务器 claude mcp add my-tools --transport stdio --env KEYvalue -- npx -y some-mcp-server # 查看当前已加载的服务器 claude mcp list # 移除不再需要的 claude mcp remove my-tools配置同样会写进.claude/settings.json的mcpServers字段方便进入版本库共享。我给一个内部项目接入过 PostgreSQL 数据库的 MCP配置长这样{ mcpServers: { pg: { type: stdio, command: npx, args: [-y, modelcontextprotocol/server-postgres], env: { DATABASE_URL: postgres://user:passdb.internal:5432/prod } } } }接完之后模型在处理任务时可以直接执行 SQL 查询不需要我手工导数据或者写临时代码。这让改代码和查数据变成同一个对话里的连续动作效率提升非常明显。5.3 哪些 MCP 值得装哪些是智商税我装过的 MCP 不少最后长期保留的其实不多。值得装的三类带官方语义的 git 操作、无头浏览器、数据库查询。这三类解决的都是 AI 编程工具最致命的短板——它看不到系统实际状态只能靠猜测。让模型能直接查 git 状态、打开网页、查数据库等于还给它一双眼睛。不建议装的是两类一类是万能型服务器什么都能接但每条指令都要传巨大的 schema上下文浪费严重另一类是玩具服务器接一个外部天气 API 就号称极大扩展能力实际对开发流程毫无帮助。MCP 也会占用上下文预算。接十几个服务器模型每次决策前都要遍历所有工具定义反而变笨。还要注意MCP 服务器的质量参差不齐很多是社区爱好者写的错误处理做得稀烂可能反过来干扰主流程。我的建议是先接一个跑通、观察一两天 token 消耗和误用情况再决定是否保留或扩展。另外提一句模型路由Claude Code 支持通过环境变量ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL指向兼容的 API 端点让这个 harness 接上其他模型服务。如果你打算这么做先确认目标模型对工具调用function calling的支持程度——Mods 改造里最依赖的 tools 能力如果模型不支持前面说的 Hooks、MCP 整套机制都会失效。6. 综合实战把 Claude Code 改造成团队专属的代码审查助手6.1 需求拆解前面说的是单项能力的拆解真正让 Mods 发挥威力的是把它们组合起来。我拿一个实际例子说明我们团队想用 Claude Code 做合并请求的第一轮机器审查目标是拦截明显的问题减少人工 review 的负担。需求拆解下来是四件事让模型知道这个仓库的架构和规范记忆层提供一个标准化的审查指令交互层在模型尝试执行危险命令时拦下来行为层审查完成后输出结构化报告并通知团队行为层 交互层6.2 从 CLAUDE.md 到 Hooks 的完整组装首先在仓库根目录的CLAUDE.md里加了三条硬性约束- 本项目涉及用户敏感数据禁止在任何输出中包含原始 token 或未脱敏的用户信息 - 新增依赖必须走 RFC 流程不允许直接修改 package.json 后不说明理由 - 合并请求审查只关注代码层面不输出主观评价然后在.claude/commands/review.md里写入标准审查命令指定接收目标分支名作为参数。最后在settings.json里挂上两个 HookPreToolUse 拦截包含硬编码密钥的写文件操作Stop 钩子把审查摘要发送到团队群。整个组合完成之后团队成员只需要在终端执行claude /review feature/xxx模型会加载仓库记忆、按命令模板执行 diff 分析、调用 git 工具查改动范围、最后输出一份带文件路径和行号的审查报告。6.3 实测效果与迭代过程第一版跑出来非常啰嗦每条 diff 都点评一遍报告长得没人看。我调整了输出风格文件强制要求按严重问题 / 建议改进 / 亮点三节输出每个问题必须附路径和行号。第二版好了一些但误报还是多——它把很多正常日志里出现的数字当成敏感信息。我又在 CLAUDE.md 里补了一条说明日志中的 requestId 字段属于允许输出的非敏感标识。迭代到第三版才达到可用状态。这个过程中我发现一个规律Mods 改造不是一次性的它更像调参。每次只改一个变量、确认生效再动下一个否则出了问题你根本不知道是哪条配置导致的行为偏移。我把这个过程类比成写测试——先让它在一条明确的用例上跑出预期结果再逐渐扩大覆盖范围。7. 改造运行机制的边界与隐患7.1 Mods 太重的陷阱我见过一些开发者把 Claude Code 的配置堆得非常华丽Hooks 挂了三层、MCP 接了九个、自定义命令建了几十个。结果真正干活的时候每次请求都要经过一堆额外检查和上下文注入响应速度明显变慢行为也变得不可预测。Mods 本质上是一套运行时编排逻辑编排越复杂出问题的概率就越高。我的底线是一个项目里 Hooks 不超过三四个关键场景、MCP 不超过两三个、斜杠命令控制在十个以内。超过这个阈值维护成本就开始倒挂——你花在修配置上的时间比省下来的时间还多。7.2 团队协作的注意点把.claude目录纳入版本库这件事我强烈建议做但要做就得有纪律。个人实验性的配置先放~/.claude确定值得共用再升级到项目目录。项目目录里的每一项配置都要配一层注释式说明讲清楚它解决什么问题、被谁引入、什么时候可以删。新成员上手的时候别让他们直接面对一堆 Hooks 和自我改造后的行为。我给团队准备的 onboarding 文档里有一张表每个 Hook 的触发条件、matcher 范围、脚本位置、可能误伤的场景。这张表在排障时也特别有用——有一次模型行为异常最后定位到是别人新加的一个 PostToolUse Hook 悄悄改了文件权限。配置是有生命周期的过时的配置比没有配置更危险。我建议每个季度做一次清理把没有实际调用记录的 Hook 和命令全部删掉。7.3 关于改造运行机制这件事的个人判断最后说一点我自己的体会。Claude Code 开放 Mods 能力真正改变的不是某一个功能的便利性而是使用者和工具之间的关系。以前我们和 AI 编程工具的交互是单向的它给我答案我接受或拒绝。现在我可以重新定义它的行为边界、给它装上新工具、让它在特定时机做特定动作。这种从使用工具到编写工具行为的转变给 AI 编程工具这个品类带来的可能性比某一个具体功能重要得多。实操层面的建议就一条改造要像写测试一样每次只动一个变量。先跑通最小闭环再逐步加约束。你的第一个 Mod 不需要多复杂哪怕只是在 CLAUDE.md 里加一条禁止使用全局变量保存状态然后观察它接下来会不会遵守都已经是在体验改造运行机制这件事了。