夜雨聆风
Claude Code 源码泄露:真正值得开发者抄走的,是这 8 个提效细节
Claude Code 的源码泄露了一段时间了。
这次真正泄露出来的重点，不是模型权重，也不是什么隐藏 API，而是 Claude Code 的系统提示词、工具定义、上下文组装方式、agent loop 和记忆机制。换句话说，它让大家第一次更清楚地看到了：Claude Code 不是“会写代码的聊天框”，它本质上是一套被精心设计过的 coding agent harness。
下面来看这 8 个可以帮我们提效的细节
1）Claude Code 支持并行调工具，但你最好明确说出来
Claude Code 被设计成能并行调用独立工具；但如果任务之间的独立性没有写清楚，它往往会保守地顺序执行。
这件事很重要，因为很多人以为“慢”是模型慢，实际上可能只是你把本来能并行做的事，描述成了串行任务。
不是所有任务都该并行。关键是独立任务要明确标成独立。
可以这样用
例子 1：对比两个实现文件
不够好的写法：
先看
src/auth.ts，再看src/session.ts，然后告诉我哪个文件里的函数更多。
更好的写法：
同时读取
src/auth.ts和src/session.ts，比较两个文件的函数数量，并列出各自对外暴露的函数名。
这样 Claude Code 更容易一次发起两个读取动作，而不是一前一后地慢慢查。
例子 2：同时排查前后端报错
更好的写法可以是：
同时检查前端错误堆栈和后端最近 200 行日志，判断这是不是同一个登录失败问题，并给出最可能的根因。
你真正想要的是“并行收集证据”，不是让它像人一样一步一步翻。
例子 3：批量搜关键词
同时在
src/和tests/里搜索useLegacyAuth，然后总结哪些地方还依赖它。
凡是这些任务，都尽量显式写“同时”。这会直接影响速度。
2）CLAUDE.md 不是民间偏方，而是正式设计的一部分
CLAUDE.md 是 first-class feature。也就是说，它不是社区自己摸索出来的土办法，而是 Claude Code 在系统层就会主动寻找和遵守的一层项目记忆。
这意味着你不应该再把 CLAUDE.md 当成“可有可无的说明文件”。它更像是你项目给 Claude Code 配的一层持久记忆。
最值得放进去的内容
-
项目命名习惯 -
目录结构约定 -
技术栈和版本 -
禁区，比如“不要碰 legacy auth” -
优先使用哪些库 -
测试、构建、部署命令
可以这样用
例子 1：给新仓库写最小可用版 CLAUDE.md
# CLAUDE.md## Project overview- Next.js 15 + TypeScript- Auth handled by Supabase- UI uses shadcn/ui- Package manager: pnpm## Conventions- Prefer server actions over custom API routes when possible- Use Zod for request validation- Keep React components under 250 lines## Avoid- Do not modify legacy/ unless explicitly asked- Do not introduce Redux- Do not change database migrations without confirmation## Commands- Dev: pnpm dev- Test: pnpm test- Lint: pnpm lint- Build: pnpm build这类内容本来你每次开新 session 都要重新解释一次。放进 CLAUDE.md 之后，就变成项目级的长期记忆。
例子 2：给子目录单独补上下文
# apps/mobile/CLAUDE.md- React Native Expo project- Prefer expo-router conventions- Avoid adding native modules unless necessary这样 Claude Code 进入这个目录干活时，不用你再额外提醒“这是 Expo 项目，不要乱上原生依赖”。
例子 3：团队统一 AI 行为
如果你们团队都在同一个 repo 里用 Claude Code，那么把“命名规范、禁区模块、测试命令、常用依赖”写进 CLAUDE.md，比每个人各自写 prompt 更稳定。
3）你越直接，它越好用
Claude Code 的系统提示词会鼓励它少寒暄、少道歉、直接回答。这看起来是小事，但实际很影响效率。
很多用户习惯用自然礼貌语言去说需求，这当然没问题，但对于 coding agent 来说，越礼貌、越绕、越像聊天，任务边界往往就越模糊。
可以这样用
例子 1：解释函数
不够好的写法：
能不能帮我看一下这个函数大概在做什么，如果方便的话也可以顺便讲讲怎么优化？
更好的写法：
解释这个函数在做什么。列出 3 个潜在问题。不要改代码。
例子 2：修 bug
找出登录失败的原因。只检查 token 校验链路。先不要改代码。
这样 Claude Code 不会顺手开始重构别的地方。
例子 3：写测试
给
formatInterest()补单元测试。覆盖空值、负数、四舍五入三种情况。沿用现有测试风格。
直接、短句、明确约束，通常效果更好。
4）Bash 才是 Claude Code 的真正主力工具
Bash 是 Claude Code 最强的工具之一，适合搜索、git、包管理和多步骤文件操作。
这点和很多人的直觉不一样。不少人还把 Claude Code 当成“看文件—改文件”的工具，但从实现思路上看，它更偏向于：能用 bash 一把做完的，就不要拆成很多小工具慢慢做。
可以这样用
例子 1：搜索整个仓库
用
rg搜索整个仓库里interestRateCap的出现位置，并按业务模块分类总结。
这比“去一个个看哪些文件用了这个字段”更符合它的强项。
例子 2：看改动
直接运行
git diff --stat和git diff，总结这次改动影响了哪些模块，以及是否有明显风险点。
例子 3：批量重命名
先用搜索确认影响范围，再批量替换明显的字段命名，从类型定义开始，不要修改接口返回字段。
这类任务如果完全靠“打开文件—改一处—再打开下一处”，会很慢；借助 bash 工具链会更像一个熟练工程师。
5）它编辑文件时，更像“精确替换”，不是整篇重写
Claude Code 的编辑更接近字符串匹配和替换，而不是整文件重写。很多失败都来自“它以为要改的那段文本，和当前文件里实际内容对不上”。
这也解释了很多人都遇到过的怪现象：它明明知道我要改哪里，结果改失败了，或者改歪了。
可以这样用
例子 1：刚格式化完文件后改动失败
你前一秒刚跑完 Prettier，下一秒再让它“按刚才那段改”，就可能失败。因为缩进、换行、引号风格都变了。
这时更稳的写法是：
先完整读取当前文件，再把
calculateInterest里的返回值改成对象结构，其他逻辑不动。
例子 2：只改一小块，不要整段重写
只改 render 部分：在
items.length === 0时显示空状态文案，其余逻辑不要动。
越精确，字符串匹配越容易成功。
例子 3：连续失败时先同步现状
读取这个文件的完整当前内容，告诉我
submitForm函数的精确代码块，然后只修改里面的 error handling。
这其实是在帮 Claude Code 对齐“它脑中的旧版本”和“磁盘上的新版本”。
6）Agent loop 不是无限聪明的，退出条件越清楚越好
Claude Code 的 agent loop 有明确停机信号，比如任务完成、不可恢复的工具错误、或者达到 turn limit。任务如果只写“过程”，不写“什么算完成”，就容易绕圈。
可以这样用
例子 1：查日志
容易绕圈的写法：
一直看日志，直到找出问题。
更好的写法：
检查最近 100 行日志。如果发现 500 错误，解释最可能原因；如果没有，就明确告诉我最近 100 行里没有 500 错误。
例子 2：排查测试失败
运行失败的测试文件一次。找出第一处失败原因。只修这一处。修完后重新跑同一个测试文件验证。
这类任务拆开之后，更不容易陷入“修一处、又顺手动三处、再引入新问题”的循环。
例子 3：代码审查
只审查这次改动里的认证逻辑。输出最多 5 个高优先级问题，没有就说未发现高优先级问题。
“最多 5 个”本身也是退出条件。
7）Git 安全策略是内建的，不是它临时谨慎
Claude Code 明确被要求避免破坏性 git 操作，优先可逆操作。它不是“胆小”，而是在产品层就被设计成偏稳。
所以你会看到它更可能先看 git diff、git status，更倾向新建分支，而不是直接在主分支上乱动。
可以这样用
例子 1：生产仓库
这是正式仓库。先新建分支再改。不要直接提交到
main。任何会删除文件的操作都先说明。
这种提示会和 Claude Code 本来的安全倾向叠加，结果更稳。
例子 2：实验仓库
这是实验目录，不需要保守。可以直接 reset、删临时文件、强制覆盖本地改动，不必反复确认。
这类指令适合 demo、POC、临时脚本仓库，不适合正式项目。
例子 3：提交前检查
改完先跑测试，再给我
git diff --stat摘要。不要自动 commit。
这类 prompt 很适合你想先看结果、再决定是否提交的时候。
8）“深度思考”不是单独按钮，更像由任务表述触发
分析型、架构型、复杂调试型任务更容易触发更深的 reasoning，而简单执行任务则不需要。
很多人会把所有任务都用一种口吻来问，结果要么太慢，要么太浅。更合理的做法，是区分“分析型任务”和“操作型任务”。
可以这样用
例子 1：架构权衡
这个 savings product 比较页，应该用静态生成、服务端渲染，还是客户端拉取？给我 3 种方案，并比较 SEO、更新频率、实现复杂度。
这类问题天然需要更长链条的思考。
例子 2：复杂 debug
在改代码前，先分析为什么这个表单在 preview 环境能提交、production 环境却失败。列出 3 个最可能根因，并说明你会如何验证。
例子 3：简单执行任务
给这个函数补
try/catch，日志格式沿用当前文件其他位置的写法。
这种任务就不需要它展开长篇分析，越短越好。
例子 4：先分析再修改
先分析这个模块里为什么会重复请求 API。不要改代码。确认原因后，再给我最小改动方案。
这类写法比“直接优化一下”更容易得到高质量结果。