夜雨聆风
拆解 Claude Code 源码:我发现了和 AI 编程助手高效对话的底层逻辑
分析了”泄漏“的 Claude Code 的全部源码，从 4756 个还原文件中，找到了它的系统提示词架构、工具路由规则、Agent 编排逻辑、权限决策链路。这篇文章不讲玄学，只讲源码级别的事实 —— 告诉你 Claude Code 内部到底在想什么，以及你应该怎么说话才能让它又快又准地帮你干活。
— — —
前言：为什么你需要了解 Claude Code 的”内心世界”
大多数人使用 Claude Code 的方式是这样的：打开终端，输入一段话，然后等结果。效果时好时坏，有时候精准得像资深工程师，有时候又会犯一些让人哭笑不得的低级错误。
你可能会归结为”AI 就是这样”。但事实并非如此。
Claude Code 不是一个自由发挥的 AI，它运行在一套精密的系统提示词框架中 —— 总计超过 914 行的提示词代码，定义了它的行为边界、工具选择优先级、安全约束、输出风格，甚至连什么时候该犹豫、什么时候该果断都有明确规则。
核心事实：你的对话方式和这套规则的契合度，直接决定了 Claude Code 的表现。
当你的请求”顺着”规则说，Claude Code 会像一台精密的自动化流水线一样高效运转。当你的请求和规则”逆着来”，它会犹豫、绕弯、浪费 token，甚至产生幻觉。
接下来，我会从源码级别拆解 Claude Code 的内部运作逻辑，然后一条一条告诉你：基于这些逻辑，你应该怎么说话。
— — —
第一章：Claude Code 的”大脑”长什么样 —— 四层提示词架构
在深入使用技巧之前，你需要先建立一个基础认知：Claude Code 的系统提示词不是一段简单的文字，而是一个四层叠加的架构。
第一层：静态核心提示词
这是 Claude Code 的”基因”，在源码中由 7 个函数生成，内容固定不变：
- 身份识别
-
：告诉 Claude “你是一个交互式软件工程助手” - 系统机制
：解释工具权限、标签处理、Hooks 等机制 - 编码规范
：定义”先读后改”、”最小改动”、安全编码等原则 - 操作约束
：规定破坏性操作需确认、授权不可扩大 - 工具使用
：建立专用工具优先级（Read 替代 cat，Grep 替代 grep） - 语调风格
：不用 emoji、简洁回答、引用代码要带行号 - 输出效率
：开门见山、一句能说完的不用三句
这 7 段内容对所有用户、所有会话都一样，系统通过全局缓存来节省 API 成本。
第二层：动态上下文
这些内容根据你的会话状态动态生成，包括：会话指导、MEMORY.md 内容、环境信息（工作目录、OS、Shell、模型名、知识截止日期）、语言设置、MCP 服务器指令等。
第三层：系统上下文
追加在提示词末尾，包含 Git 状态（当前分支、主分支、最近 5 个提交、文件修改状态）。这是会话开始时的快照，不会实时更新。
第四层：用户上下文
以 <system-reminder> 标签注入到对话消息中，包含你的 CLAUDE.md 文件内容和当前日期。
为什么要知道这些？ 因为每一层的”影响力”不同。第一层是硬规则，Claude 几乎不会违背。第四层的 CLAUDE.md 则被标注为”可能相关也可能不相关”，写得不够强势的指令可能被忽略。理解了这个架构，你才能理解后面所有技巧为什么有效。
— — —
第二章：减少幻觉的第一原则 —— 让 Claude 先看再说
源码中的硬性规则
系统提示词明确要求：
"Do not propose changes to code you haven't read." "If a user asks about or wants you to modify a file, read it first."
更关键的是，Edit 工具有硬性前置条件：
"You must use your Read tool at least once before editing. This tool will error if you attempt an edit without reading the file."
这不是建议，是技术层面的强制。Edit 工具内部有检查机制，没有 Read 过的文件直接编辑会报错。
你应该怎么做
给出具体的文件路径，而不是模糊描述。
|
|
差：
|
|
|
好：
|
|
|
更好：
|
如果你不确定文件在哪，显式要求搜索：
"先搜索项目里所有和认证相关的文件，列出来让我看看，然后再分析问题"
这句话的关键是”列出来让我看看” —— 把搜索和修改拆成两步。Claude 先搜索，你确认目标文件，然后再深入。
— — —
第三章：理解”最小改动”原则 —— Claude 的刻意克制
源码中的强硬约束
这是源码中最”强硬”的一段提示词：
"Don't add features, refactor code, or make 'improvements' beyond what was asked." "Don't add error handling for scenarios that can't happen." "Don't create helpers or abstractions for one-time operations. Three similar lines of code is better than a premature abstraction."
核心思想：只做你要求的事，不做你没要求的事。
你应该怎么做
|
|
“帮我改善一下这个文件”
|
|
|
只修 bug：
|
|
|
想要更多：
|
关键认知：系统默认倾向最小改动。你想要更多，必须明确表达。否则 Claude 会刻意克制自己。
— — —
第四章：工具路由 —— 别让 Claude 走弯路
源码中的工具优先级
系统提示词中用了极少出现的 “This is CRITICAL” 来强调：
"Do NOT use Bash to run commands when a relevant dedicated tool is provided. This is CRITICAL." - Read instead of cat/head/tail - Edit instead of sed/awk - Glob instead of find/ls - Grep instead of grep/rg
你应该怎么做
自然语言描述意图，不要指定工具。
|
|
|
|
|
|
|
|
|
|
|
|
什么时候该用 Bash？ 真正的系统命令和终端操作：
✅ "运行 npm test" ✅ "执行 docker-compose up -d" ✅ "启动开发服务器" ✅ "安装 lodash 依赖"
— — —
第五章：Agent 系统 —— 让多个”分身”并行工作
Claude Code 内部有 5 种内置 Agent：
|
|
|
|
|---|---|---|
| GeneralPurpose |
|
|
| Explore |
|
|
| Plan |
|
|
| Verification |
|
|
| ClaudeCodeGuide |
|
|
关键数字：3 次查询是 Agent 分派阈值。预计超过 3 次搜索才值得启动 Explore Agent。
你应该怎么做
简单搜索直接问：
✅ "找到 UserService 类在哪个文件里定义的" → 一次 Glob/Grep 就能搞定
复杂研究暗示深度：
✅ "深入分析这个项目的认证架构，包括 OAuth 流程、 token 管理、中间件调用链，给我一个完整的理解"
列出独立子任务触发并行：
✅ "并行帮我做三件事： 1. 搜索所有 API 端点 2. 检查测试覆盖率 3. 分析依赖关系"
关键词是“并行”。系统规则说”make all independent tool calls in parallel”。明确列出独立任务 + 使用”并行”关键词，Claude 会同时启动多个 Agent。
— — —
第六章：CLAUDE.md 的写法决定了 Claude 的”记忆质量”
源码中的注入机制
CLAUDE.md 被包裹在 <system-reminder> 中注入，且有一句关键说明：
"IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant."
重要：系统告诉 Claude 你的 CLAUDE.md 不一定要遵守。如果写得像”背景信息”，Claude 可能会忽略。只有写成明确的指令，才会可靠地遵守。
两种 CLAUDE.md 的写法对比
背景信息式（容易被忽略）：
这个项目是一个电商平台的后端，用 TypeScript 写的， 数据库用 PostgreSQL，ORM 用 Prisma。
指令式（可靠遵守）：
# 代码规范（必须遵守） ## TypeScript - 所有新代码必须使用 TypeScript strict mode - 禁止使用 any 类型 ## 测试 - 每个新功能必须有对应的单元测试 - 测试框架：vitest - 运行测试：npm run test ## Git - 提交信息使用 Conventional Commits 格式 - 不要直接 push 到 main 分支
多级 CLAUDE.md 的最佳实践
~/.claude/CLAUDE.md ← 全局偏好（语言、风格）
项目目录/.claude/CLAUDE.md ← 项目规范（提交到 git，团队共享）
项目目录/CLAUDE.local.md ← 个人笔记（不提交到 git）
项目目录/.claude/rules/*.md ← 细分规则文件
— — —
第七章：权限系统 —— Claude 为什么老是问你”确认吗”
源码中定义了一套完整的风险评估框架，需要确认的操作包括：
- 破坏性操作
：删除文件/分支、rm -rf - 难以撤销
：force-push、git reset –hard - 对他人可见
：push 代码、创建 PR、发消息
而且源码明确说：
"A user approving an action once does NOT mean they approve it in all contexts."
你上次同意了 push，不代表这次也同意。
减少确认的三种方法
方法一：对话中预先授权
"帮我重构 auth 模块，过程中可以自由创建、编辑、删除 src/auth/ 下的文件，不需要每次问我确认。 但不要动 .env 文件，不要 push 代码。"
方法二：CLAUDE.md 中持久授权
# CLAUDE.md 权限设置 - 可以自由修改 src/ 下的任何文件 - 可以运行 npm test 和 npm run build - 不允许修改 .env 文件 - 需要 push 时必须先问我
方法三：给破坏性操作提供充分上下文
"我确认要 git reset --hard HEAD~3， 最近三个 commit 都是错误的，没有需要保留的修改"
— — —
第八章：Skill 系统 —— 一键触发标准化流程
源码中 Skill 的触发被定义为 BLOCKING REQUIREMENT（阻断性需求）—— 匹配到 Skill 后必须先执行，优先于任何其他响应。
内置 Skill 速查表
|
|
|
|---|---|
/commit |
|
/review |
|
/simplify |
|
/debug |
|
/init |
|
/batch |
|
自定义 Skill —— 在 .claude/skills/deploy/SKILL.md 创建：
--- name: "部署到测试环境" description: "构建并部署" allowed-tools: - "Bash(npm:*)" - "Bash(docker:*)" --- 1. 运行 npm run build，确认构建成功 2. 运行 npm run test，确认测试通过 3. 执行 docker build -t myapp:latest . 4. 报告部署结果
然后只需输入 /deploy 即可一键执行。
— — —
第九章：Hooks —— 让质量检查自动化
系统提示词说：“Treat feedback from hooks as coming from the user.” Hook 的反馈被当作你的指令处理。
在 settings.json 中配置：
{ "hooks": { "PostToolUse": [ { "if": "Write|Edit", "command": "npx prettier --write \"$CLAUDE_FILE_PATH\"" } ], "Stop": [ { "command": "npm run lint -- --quiet" } ] } }
效果：每次文件修改自动格式化，每次对话结束自动 lint。Claude 不会”忘记”检查 —— 即使它觉得代码没问题，Hook 也会自动运行并反馈。
— — —
第十章：减少幻觉的 5 个高级策略
策略一：涉及外部资源时自己提供链接
系统规则说 “NEVER generate or guess URLs”，但对 API、库方法名可能仍会猜测。
|
|
|
|
|
|
策略二：超出知识截止日期的技术必须提供文档
系统注入了知识截止日期（如 “May 2025″）。之后发布的技术更新，Claude 不一定知道。
策略三：要求看到实际输出
✅ "运行 npm test，把完整的测试输出贴给我看，不要总结" ✅ "编译一下，把所有 warning 和 error 都给我看"
策略四：主动要求对抗性验证
✅ "实现完成后，帮我验证：运行测试、试边界输入 （空值、超大值、特殊字符）、检查错误处理"
策略五：分离搜索和修改
第1步："搜索所有处理用户输入的地方，列出文件路径和行号" → 你检查结果 第2步："看一下这几个文件的具体实现" → 你确认理解正确 第3步："基于你看到的代码，给所有用户输入加上 XSS 防护" → 基于真实代码修改
— — —
第十一章：对话节奏 —— 不同任务不同节奏
简单任务 —— 一句话直接搞定
"把 getName 改成 getFullName" "/commit" "删除 src/legacy/ 目录"
中等任务 —— 目标 + 范围 + 约束
"目标：给 src/api/routes.ts 加一个 GET /api/health 端点 范围：只改 routes.ts 和对应的测试 约束：返回 { status: 'ok', uptime: 进程运行时间 }， 响应格式和其他端点保持一致"
复杂任务 —— 分阶段进行
阶段1（研究）："分析支付模块架构，给我完整报告" ↓ 你审查分析结果 阶段2（规划）："制定 Stripe V2→V3 迁移计划" ↓ 你审查并反馈 阶段3（实施）："按计划第一阶段开始实施" ↓ 阶段4（验证）："运行所有支付相关测试"
为什么分阶段？ 因为系统内部的 Coordinator 模式的工作流就是「研究 → 合成 → 实现 → 验证」。你手动分阶段，正好匹配 Claude Code 最优的内部处理流程。
— — —
第十二章：必须避免的 12 个反模式
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
— — —
总结：和 Claude Code “同频”的四条核心法则
法则一：具体胜于模糊
系统的每一层都在追求确定性。给路径比给描述好，给行号比给功能名好，给约束列表比说”改善一下”好。
法则二：顺势而为，不逆规则
系统说”先读后改”，你就先让它读。系统说”最小改动”，想要更多就明确说。每一次对抗都会消耗额外的处理成本。
法则三：分层控制，持久规则写进配置
一次性指令 → 对话中说项目规则 → CLAUDE.md自动化检查 → Hooks重复流程 → Skill全局偏好 → ~/.claude/CLAUDE.md
法则四：验证驱动，不要盲目信任
改完代码要跑测试。看到”已完成”要看实际输出。涉及外部 API 要验证地址。信任但验证 —— 这是和所有 AI 工具合作的核心原则。
— — —
Claude Code 不是一个黑盒。它的每一个行为都有源码级别的解释。理解了它的系统提示词架构，你就理解了它的”思维模式”。
你不需要记住这篇文章的每一个细节。记住核心的四条法则就够了：具体、顺势、分层、验证。
然后在实际使用中，慢慢感受什么样的表述能让 Claude Code 发挥最好的效果。你会逐渐建立起一种直觉 —— 一种和 AI 编程助手”同频”的直觉。
这种直觉，会让你的编程效率进入一个全新的维度。
— END —
本文基于 claude-code-sourcemap 项目（Claude Code v2.1.88 源码还原）分析完成