Claude Code源码泄露,我提炼了10条提示词的高级用法!

Hi，这里是周行 (Xing)。

之前写了一篇 Claude Code 源码拆解，偏底层机制，更多是面向开发者的。

但我主要的方向并非产品开发，所以我其实会更关心一些实用性的提示技巧：怎么跟 Claude Code 说话，它才更听得懂、干得好。

基于此，我又整理了10条如何用好claude code （或其他Ai） 的提示词技巧。

这些技巧不需要你会写代码，任何人都能用。

而且跟网上大多数”提示词教程”不同，这些技巧是从源码和官方最佳实践里提炼出来的，有明确的机制支撑。

知道”为什么有效”，你就能举一反三。

1. CLAUDE.md 写法

上一篇聊过 CLAUDE.md 的加载机制，这次说说怎么写。

很多人的 CLAUDE.md 写得像文档：项目背景、技术架构、代码规范、命名约定、测试流程……恨不得把所有东西都塞进去。

但源码告诉我们，Claude Code 的系统提示词本身已经有大约 50 条内置指令。而模型能可靠遵循的指令总量大概在 150-200 条。也就是说，留给你的 CLAUDE.md 的”指令预算”其实很有限。

写太多，真正重要的指令反而会被淹没。

怎么写才有效？把 CLAUDE.md 当成给新同事的入职手册，只写”如果不告诉你，你一定会搞错的事情”。比如：

• ➔➔
  
  项目里有哪些特殊约定 (命名规则、目录结构)
• ➔➔
  
  常用的命令 (测试、构建、部署)
• ➔➔
  
  绝对不能碰的东西 (某个目录、某个配置文件)

其他的，Claude Code 自己能从代码里推断出来的东西，就别写了。写了反而浪费预算。

还有一个技巧：CLAUDE.md 支持 @path/to/file 语法引用其他文件。详细的流程规范可以放在单独的文档里，在 CLAUDE.md 里用一行引用就行。这样既保持了主文件的精简，又不会丢失细节。

2. 验证标准

这一条可能是所有技巧里杠杆效果最高的。

大多数人用 Claude Code 的方式是：给它一个任务 → 它做完 → 你人肉检查 → 发现问题 → 让它改 → 再检查……

如果你在任务描述里直接告诉它怎么验证自己的工作，这个循环就能自动化。

比如：

“

实现用户登录功能后，运行 npm test auth 确认所有测试通过。如果有失败的，自己修复，直到全部通过。

Claude Code 的创始人说过，这一个技巧就能带来 2-3 倍的质量提升。

原理很简单：没有验证标准的时候，你是唯一的反馈来源，Claude Code 做完就停了，等你来看。有了验证标准，它自己就能跑一个”做→验→改”的闭环。

即使你不是开发者，同样的思路也适用：

“

写完这篇文章后，检查是否每个段落都只讲一件事，是否有超过 3 句的排比，是否有”综上所述”之类的书面腔。发现了就自己改掉。

3. 一个任务一个会话

这条听起来很简单，但很多人做不到。

随着对话越来越长，Claude Code 会开始”忘事”。前面聊过的对话压缩机制就是原因——早期的上下文会被压缩成摘要，细节不可避免地会丢失。

更重要的是，前期对话的上下文会”污染”后续任务。比如你先让它改了一个按钮样式，然后在同一个会话里让它改数据库逻辑。它脑子里还残留着按钮的上下文，可能会做出一些奇怪的关联。

最佳实践：一个任务做完，用 /clear 清掉，开一个干净的会话继续下一个。

如果担心丢失进度，可以在下一个会话开头简要说明前情。或者把重要的上下文写进 CLAUDE.md，它每个会话都会自动读取。

4. 思考深度关键词

这个很多人不知道。

Claude Code 支持在提示词里用特定关键词来调整它的”思考预算”：

• ➔➔think
  
  ：基础思考，适合简单任务
• ➔➔think hard
  
  ：中等深度，适合需要权衡的决策
• ➔➔think harder
  
  ：深度思考，适合复杂 bug 调试
• ➔➔ultrathink
  
  ：最大思考预算，适合架构级决策

日常用的话，大多数任务不需要加任何关键词。遇到复杂问题的时候，在提示词里加一句”think hard about this”就行。

注意：思考越深，消耗的 token 越多，花费也越高。别每个任务都 ultrathink。

5. 走偏了，引用它自己的规则

上一篇提过，Claude Code 的系统提示词里写死了一套行为准则。

这套准则的实际用法是：当 Claude Code 走偏的时候，你可以直接引用它的规则来把它拉回来。

比如它自作主张创建了一堆新文件，你可以说：

“

你的规则说了，不要创建不必要的文件。请撤销刚才创建的文件，只修改我指定的部分。

比它过度重构了你没让它动的代码，你可以说：

“

你的规则说了，改动要严格限定在请求范围内。请只改我说的那个函数。

我自己用下来，这招比单纯说”不要这样做”有效得多。因为你是在提醒它自己认同的规则，它的遵从度会更高。

6. 复杂任务拆三步

源码里 Claude Code 的 Sub-Agent 架构是：Explore → Plan → Execute。

你可以直接按这个节奏给它下指令：

“

第一步：先读一遍 src/auth/ 目录下的所有文件，告诉我现在的认证逻辑是怎么实现的。
第二步：基于你的理解，给我一个迁移方案。先别动手。
第三步：方案我确认后，再开始改代码。

这样做的好处是：每一步你都有机会检查和纠偏。如果直接说”帮我把认证从 session 迁移到 JWT”，它可能理解错了方向，改了一大堆之后你才发现问题，回滚成本很高。

即使是非代码任务，同样的思路也适用：

“

第一步：先研究一下这个话题的主流观点。
第二步：给我一个文章大纲。
第三步：大纲确认后再写全文。

7. 用 todo/next 标记待办

源码里的压缩算法会优先保留包含 todo、next、pending、remaining 这些关键词的内容。

也就是说，当你在对话中提到待办事项时，刻意用这些词来标记，它们在上下文压缩后更有可能被保留下来。

比如：

“

TODO：登录功能做完后，还需要处理密码找回的逻辑。
NEXT：等这个 PR 合并后，开始做用户权限模块。

这不是什么玄学，是压缩算法的硬编码逻辑。

8. /compact 可以带参数

大多数人只知道 /compact 可以手动触发对话压缩，但不知道你可以告诉它压缩时重点保留什么。

“

/compact 保留所有修改过的文件路径和当前的测试状态

这样压缩出来的摘要会更精准，不会丢掉你最关心的信息。

你甚至可以在 CLAUDE.md 里写一条常驻指令：”压缩时，始终保留修改文件列表和当前任务进度。”这样每次自动压缩都会按你的优先级来。

9. Plan Mode 防止走错方向

按两次 Shift+Tab 就能进入 Plan Mode。

Plan Mode 下，Claude Code 只分析、不动手。它会告诉你它打算怎么做、会改哪些文件、预计的影响范围。你确认后它才开始执行。

什么时候该用？

• ➔➔

  涉及多个文件联动的改动

• ➔➔

  你对这块代码不太熟悉

• ➔➔

  任务比较模糊，你想先看看它怎么理解的

什么时候不用？

• ➔➔
  
  任务很明确，一句话就能说清楚要改什么
• ➔➔
  
  简单的单文件修改

Plan Mode 的价值在于：防止 Claude Code 花 20 分钟自信地解决了一个错误的问题。

10. 指向现有代码，别口头描述

让 Claude Code 参照现有代码来复制模式，比你口头描述精确得多。

比如：

“

参照 src/auth/login.ts 的错误处理模式，给 logout 也加上同样的处理。

比这样好得多：

“

用我们项目的错误处理风格来写 logout 的逻辑。

口头描述会产生”微漂移”——它写出来的代码看起来风格差不多，但总有些地方跟你项目的约定不太一样。直接指向现有代码，它就能精确复制模式。

CLAUDE.md 里的 @ 引用也是同样的思路。与其在 CLAUDE.md 里长篇大论描述项目结构，不如直接写：

“

项目概览见 @README.md，可用命令见 @package.json。

最后

这 10 条技巧，核心其实就一个思路：

Claude Code 有自己的运行逻辑，你越顺着这个逻辑来跟它沟通，效果就越好。

它有指令预算上限，你就精简 CLAUDE.md。它会压缩上下文，你就用 todo/next 标记重要内容。它内部按 探索→方案→执行 调度，你就按这个节奏拆任务。

不是让你迁就它，而是了解它的工作方式后，用最省力的方式拿到最好的结果。

好了，今天就到这里。

希望这篇推文，对朋友们有些帮助🍀。