Claude 使用指南：细小但不可忽视的细节与技巧

不讲 "怎么注册账号"、不讲 "如何写好 prompt 工程"——讲那些用了三年才会自然形成的小习惯。它们单独看都不起眼，叠加起来决定你和 Claude 协作的上限。

2026-05-18claudeaitipspromptclaude-codeproductivity

这不是"prompt 工程入门"，是老用户才会注意到的细节。每条单独看都很小，但你会发现：真正用 AI 很顺的人和卡壳的人，差距几乎全在这些小事上。分四块：日常对话 / Claude Code / Anthropic API / 通用心法。

第一部分：日常对话（Claude.ai / 桌面端）

1. 话题切换 = 新建对话，不要"在一个窗口里聊到底"

最常见的坏习惯：一个对话从代码聊到行程到购物。长上下文带来三个问题：

上文的"杂质"会影响新问题的回答
整段历史被重新读一遍，响应变慢、有时变贵
模型可能基于已有对话风格继续"角色扮演"，而不是直答你的新问题

经验法则：换话题 = Cmd+N（或 Ctrl+N）开新对话

2. 把"上下文"放在问题之前，但把"指令"放在最后

模型对最近出现的文字更敏感。处理长文档时：

不好:
[问题]
[2 万字资料]
→ 模型已经"忘了"问题在问什么

好:
[2 万字资料]
[问题]
→ 问题在最近位置，模型紧扣它回答

把任务/指令放在最末段，对长输入特别有效。

3. 用 XML 标签包裹复杂输入

Claude 对 XML 风格的结构特别敏感（训练数据里有大量类似结构）。复杂任务里这样写：

<context>
我是一名独立开发者，正在做一个跨境电商工具。
</context>

<task>
帮我写一段产品落地页文案。
</task>

<constraints>
- 不超过 200 字
- 重点强调速度和定价
- 面向欧美中小卖家
</constraints>

<output_format>
返回三个不同风格的版本，编号 1/2/3。
</output_format>

比"一句话扔过去 + 五条要求散在文里"成功率高得多。

4. 让模型"先输出计划，确认后再执行"

任何复杂任务，加一句："先列出你要做的步骤，等我确认 OK 后再写正式版本"。

好处：

你能在它跑偏前纠正方向
节省 token，少返工
复杂分析类问题质量明显更高

5. 不要说 "你是世界顶级 XX 专家"

这个老 prompt 套路在 Claude 上效果存疑甚至倒退。模型已经知道自己是 Claude，给它扣一个"专家"帽子反而触发表演性回答而不是直白的答案。

不好:  你是一位资深 Rust 工程师，请告诉我……
好:    我在写 Rust，遇到 lifetime 编译错误，下面是代码……

直接描述场景比角色扮演更让 Claude 进入"工程师状态"。

"描述场景 + 给出具体素材" 永远比 "赋予角色 + 抽象提问" 更可靠。这一条价值千金，但很多人坚持五年没改过。

6. 让它"承认不知道"

模型默认会试图给出答案——哪怕它没把握。在 prompt 末尾加一句：

如果不确定，请直说 "不确定"，不要编造细节。

这一句话能**显著减少"看起来很专业但其实是编的"**的回答。

7. 处理 PDF / 长文档：先要"摘要 + 目录"

直接问 50 页文档的细节，模型容易抓重点不准。先这么走：

1. 把整份文档发给它，先要："列出本文目录与每章 2 句摘要"
2. 看完摘要后，问具体章节："基于第 3 章，回答 XXX"
3. 需要原文佐证时，问："请引用原文段落"

这套流程不仅准确率高，还方便你判断它有没有"瞎答"。

8. 利用 Artifacts / 侧边输出区做"渐进式迭代"

写代码、写文档时不要让它"重新输出整版"。要这样：

保持当前 Artifact 不变，只修改 X 函数的实现。
其他部分不要动。

这能避免它整版重写时不小心改掉你已经改好的部分—— 一个非常常见的踩坑点。

9. Projects 用来放"持久背景"，不要每次贴

Claude.ai 的 Projects 里放：

你的项目背景（公司、产品定位、技术栈）
写作风格示例（你之前的 2–3 篇）
经常用到的术语表
不要做的事

一次设置，长期受益。这是 Claude 最被低估的功能之一。

第二部分：Claude Code（CLI / IDE）

10. CLAUDE.md 要小，不要"应有尽有"

CLAUDE.md 是每次会话都会被读进上下文的内容。塞进 1000 行项目说明 ≠ 模型更懂你的项目—— 反而稀释了它对当前任务的注意力。

推荐: 100–200 行以内
内容:
- 项目一句话定位
- 关键目录结构（不超过 20 行）
- 必须遵守的约定（缩进、命名、commit 风格）
- "千万别做" 清单

详细的架构说明留给 README 或专门的 docs，让 Claude 按需读取。

11. 用 `/clear` 比想象中频繁

复杂任务做完一段就 /clear。原因和第 1 条一样： 长上下文会让模型在新任务上更迟钝。

经验做法：

改完一个模块 → /clear
Code review 完一份 PR → /clear
调通一个 bug → /clear

12. 用 `@文件路径` 而不是粘贴文件内容

不好:  我把这个文件全贴出来给你看……（接 500 行）
好:    请看 @src/lib/auth.ts 第 40-80 行

@ 引用让 Claude 自己读文件，保留完整路径上下文 + 行号定位。模型回答时也会引用准确的位置，便于你跳转。

13. 复杂改动先进 Plan Mode

按两次 Shift+Tab 进入 Plan Mode（只读模式）：

Claude 会先给出完整计划，不修改任何文件
你确认后再切回执行模式
避免它一上来就改 20 个文件，最后发现方向错了

凡是涉及 5 个以上文件的修改，都应该先 Plan。

14. 让子代理（Agent）做并行调研，不要主代理什么都干

当你要"调研整个仓库的 X 怎么实现"时：

不好:  让 Claude 在主对话里自己 grep + read 一堆文件
好:    "用 subagent 帮我并行调研以下 3 个问题：……"

子代理跑完只返回总结到主上下文，主上下文保持干净 —— 等于给你的对话加了一个"实习生研究员"。

15. 不要"事无巨细汇报"——让它一段一段做

不好: "每一步都告诉我你在做什么"  →  上下文被刷屏
好:   "做完所有改动后，给我一份摘要"

中间过程让它自己跑，只在关键节点（确认计划 / 执行结果 / 异常）汇报。

16. 用 hooks 把"重复的提醒"自动化

每次让 Claude "改完跑一下 prettier"、"提交前跑 typecheck" 很烦—— 把它写进 hooks，让 Claude 自动执行。

settings.json 里配置 PostToolUse / Stop 等钩子。配好之后它会自动执行，不再需要你提醒。

17. Skill 比"长 CLAUDE.md" 更优雅

如果有一类任务每周都要做（写 commit、做 PR review、写博客）：

做法 A: 全塞进 CLAUDE.md       ← 占常驻上下文，污染其他任务
做法 B: 写一个 Skill           ← 按需触发，干净

Skill 是 "按需加载的专长" ——只有触发时才进入上下文。这是上下文经济学里最便宜的"扩容"方式。

18. 不要立刻信任它说"已完成"

每次 Claude 说"done"或"all tests pass"，自己也跑一遍：

git status
git diff
pnpm test

它的"完成"是 "我的工具调用没报错"，不是 "你的需求被满足"。两者经常不一样。

这一条建议刻在显示器上： "Claude 说完成 ≠ 真的完成"。尤其在大改动后，自己 review diff 五分钟比事后回滚十小时划算。

第三部分：Anthropic API（开发者）

19. 启用 Prompt Caching——这是最大的省钱杠杆

任何重复出现的长上下文（系统指令、文档、代码库）都应该走缓存：

system=[
  {
    "type": "text",
    "text": LONG_SYSTEM_PROMPT,
    "cache_control": {"type": "ephemeral"}
  }
]

效果：

缓存命中：成本降到原价的 ~10%
延迟降低：复用部分不重新读
缓存 TTL 默认 5 分钟——超过就要重新建

实操：把 "5 分钟内会被多次调用的内容" 优先放进缓存。

20. 用 Batch API 处理离线任务，便宜 50%

非实时任务（数据清洗、批量摘要、离线分析）走 Batch：

价格直接 50% off
24 小时内返回（多数任务远比这快）
通过文件批量提交，无需自己控并发

很多人不用 Batch 是因为"实时习惯了"—— 但其实大量场景根本不需要实时。

21. 工具定义里的 description 比函数名更重要

模型决定"要不要调用这个工具"看的是 description。

# 不好
{"name": "get_user_data", "description": "Gets user data"}

# 好
{"name": "get_user_data",
 "description": "Retrieves user profile, last_login, and subscription tier
                 from the production DB. Use when you need any user-level
                 info beyond what's in the current message."}

把 "什么时候该用它" 写清楚比函数名重要得多。

22. Temperature 不是越低越好

很多人默认 temperature=0：

适合精确性任务（解析、提取、分类）
不适合写作 / 头脑风暴——输出趋于平庸

经验值：

任务类型	推荐温度
结构化抽取 / 解析	0
Code 生成	0–0.3
客服 / 文档问答	0.2–0.5
写作 / 创意	0.7–1.0
头脑风暴	1.0+

23. 用 stop_sequences 控制输出截断

不要靠 prompt 求模型"只输出 X 之前的内容"—— 直接用 stop_sequences=["</answer>"] 干净利落地截断。

24. Extended Thinking 不是越多越好

打开思考预算时：

复杂推理任务（数学 / 多跳逻辑）：值得
简单 chat / 提取：浪费——它会"过度思考"

推荐策略：
默认不开 thinking
仅在测试发现简单 prompt 也答错的场景下打开

25. Files API + Citations 是文档问答最佳组合

长文档场景不要把全文塞 messages：

1. 用 Files API 上传 PDF
2. 在 messages 里引用文件
3. 启用 Citations

模型回答时带原文出处，便于核对。

第四部分：通用心法

26. "模糊的输入 = 模糊的输出"

不好:  "帮我改一下这个函数"
好:    "把这个函数的错误处理改成抛 AuthError，
        而不是返回 null；保留原有的成功路径不变"

你的输入越具体，模型的产出越准确——没有例外。

27. 不要拿"做不到"的事难为它

模型不擅长的事：

当前实时事件（除非接联网）
精确计算（用工具，不要让它心算）
长篇虚构里的"完全一致性"
关于自己的细节（"你用什么训练？""你和 X 比怎么样？"）

把这类问题交给它擅长的工具或它本身处理不到的人。

28. 一次只问一件事

不好: "解释这段代码、找出 bug、改写成 TypeScript、再写测试"
好:   分四轮做，每轮一件事

复合问题里模型容易**"答了一半就跑偏"**—— 分轮做反而总用时更短。

29. 把"反馈"喂回去，不要换模型

效果不满意时，继续在同一个对话里反馈比换模型有效：

不好:  "Claude 答得不对，我去试试 GPT"
好:    "你刚才回答里 X 部分有问题，应该是 Y。重新生成一版"

模型在反馈循环里学得很快——两轮反馈胜过换十次工具。

30. 把 AI 当"实习生"而不是"全能助手"

最后一条心态题：

"全能助手" 心态:  我问，它答，对错听天由命
"实习生" 心态:    我布置 → 它做 → 我审 → 给反馈 → 再做

后者质量永远高于前者—— 不是因为模型更强，是因为你的协作姿势更对。

AI 使用的差距，归根到底是协作姿势的差距，不是 prompt 模板的差距。把它当一个"很快、很博学、有时不靠谱的实习生"来管理—— 这一个心态调整，比任何 prompt 技巧都更有杠杆。

一份"小习惯检查表"

每周自查一次，养成习惯：

这周有没有在一个对话里聊太多无关话题？
长任务有没有先 plan 再做？
CLAUDE.md 是不是又膨胀了？
工具 description 写清楚了吗？
该开 Prompt Caching 的地方都开了吗？
有没有盲信"它说完成了"？
给反馈的次数够不够？

打勾越多，你和 AI 的协作就越顺。

一句话总结

高手用 AI 不是因为他们写 prompt 更花哨，是因为他们把无数个小细节稳稳做到位—— 切换对话、控制上下文、给清楚指令、审验输出、迭代反馈。三十条没有一条是"魔法"，但叠加起来就是别人 5 倍的产出。