30种源自实际日常使用的Claude提示词技巧

无数“提示词工程”指南被添加到书签后便再无人查阅。太多这类指南的内容看起来就像是有人随便生成两个提示词，截个图就宣称这就是一种方法论。

以下内容之所以不同，主要在于其形成过程：我在多个副业项目及自由撰稿工作中，与Claude进行了数月乃至更长时间的每日交流，期间经历了大量反复试验，才确定哪些经常被提及的“最佳实践”真正能在实际工作中发挥作用。

下面介绍的一些技巧确实改变了开发者使用提示词的方式。还有少数技巧虽经过测试后被认为效果不佳，但由于仍能很好地解决特定问题而得以保留。另外还有几项看似花招的技巧，最终却成为整个列表中最有价值的条目。每个部分都会注明其所属类别。

这些方法是根据每种技术实际能实现的功能来划分成四类的，而非依据其理论上听起来有多复杂：

Part 1 — Say What You Mean          (clarity & structure)
Part 2 — Put Up Guardrails          (constraints & format control)
Part 3 — Make It Reason Out Loud    (thinking & iteration)
Part 4 — Build a System, Not a Prompt (workflows & long context)

第一部分 — 清晰表达意图

1. 具体明确，避免模糊

这仍是人们在编写提示语时最常犯的错误之一。要求“让这个更好”只会得到一些泛泛而谈、容易被遗忘的内容；而要求“重写这段文字，让没有技术背景的创始人能用两句话理解其中的权衡”则能得到实用的结果。

一个实用的经验法则：如果编写一条提示语所需时间少于10秒，那它很可能还不够具体。

2. 使用结构化标签来划分提示语的各个部分

XML风格的标签值得持续使用——并非因为有人声称这是Claude的“原生语言”（这种说法难以验证，若被全然肯定地提出则应持怀疑态度），而是因为标签能够解决一个实际问题：当指令、背景信息和示例混杂在同一个文本块中时，模型不得不猜测每个部分的起始与结束位置。标签则完全消除了这种猜测。

<instructions>
Summarize the risks section only. Ignore financial projections.
</instructions>
<context>
[pasted document]
</context>
<output_format>
3 bullet points, no more than 15 words each
</output_format>

3. 先说明背景，最后提出问题

这种顺序的重要性超出了初看时的想象。先粘贴长篇文档再提问，往往会导致得到的答案明显不如在所有内容呈现后再提问时的质量。一个合理的解释——尽管尚未得到科学验证——是这种顺序能防止模型在尚未读完所有内容时就试图给出答案。

[long document]
---
Based on everything above, what's the single biggest
risk to the Q3 timeline?

4. 用实例展示而非仅作描述（少样本示例）

描述性形容词往往过于笼统且缺乏具体性。一个关于所需语气、结构或格式的实例，其作用远超过一整段描述文字。对于那些重复出现的任务——如客户邮件回复、代码审查反馈以及类似的工作——最好在笔记文件中保存两三个“标准范例”，每当遇到同类任务时即可直接复制使用。

5. 需要解释原因，而不仅仅是规则

这是列表中较为出人意料的技术之一。从技术层面讲，让Claude“将内容控制在280个字符以内”确实有效。但告知它“这段内容会直接发布到推文中，超过280个字符的部分会在句子中间被截断”，就能让输出显得更加谨慎。似乎给出理由后，模型会在整个回复过程中都考虑这一限制，而不仅仅在最后统计字符数。

6. 明确允许回答“我不知道”

几乎每个研究或分析类提示语中都值得加上这样一句话：

If the available information isn't enough to draw a
conclusion, say so directly instead of guessing.

如果跳过这一行，就很有可能得到看似有理实则无意义的回答。加上这一行后，有时回复会是“目前信息不足，无法确定”，虽然当下会让人不满意，但总比几小时后发现是编造的事实要好。

7. 明确指定输出格式，不要想当然

要求“一个表格”与要求“一个格式恰当、能直接粘贴到代码块中的纯文本表格”之间存在很大差异，因为Medium往往无法正确显示Markdown表格。明确说明期望的答案具体形式可以完全避免这种不匹配。

8. 不仅要定义任务，还要明确“完成”的标准

与其描述任务本身，不如说明成功结果应具备的特征，这样往往能获得更精准的结果：

I need a competitor comparison so my co-founder can
pick a pricing tier in under 5 minutes without asking
me follow-up questions.

那一句话的分量，远超过三段格式规则所能表达的。

第二部分 —— 设定约束

9. 负面约束——明确说明不应做什么

有时，通过规定不允许的内容来定义目标，比试图精确描述期望的内容更为快捷：

Do not sound like: a LinkedIn thought-leader post.
Do not include: "in today's fast-paced world," filler
caveats, or a summary that repeats the intro.

10. “合同”风格的系统提示

对于任何计划重复使用的内容，应将系统提示写成简短的法律合同形式，而非人物描述：

Role: technical editor for a solo dev's blog
Goal: tighten prose without changing meaning
Constraints:
 - keep first-person voice
 - no invented statistics
 - flag anything that sounds AI-generated
If unsure: ask one clarifying question, don't guess
Output: plain markdown, no headers added

11. 不必装作资深专家

这是一种值得摒弃的技巧。即便指令已经十分精确，让Claude“扮演一名有20年经验的工程师”似乎也改变不了什么。角色设定远不如你给出的实际约束重要。依靠某种角色来弥补细节缺失，通常意味着指令本身需要进一步细化。

12. 根据评分标准进行自我评估

不要只说“检查你的工作”，而应提供具体的评分标准，并要求在最终输出前给出自我评估分数：

Score your draft 1-10 on: technical accuracy, whether
a beginner could follow it, and whether it sounds
like a real person wrote it. Then revise based on
your own score. Show only the revised version.

这种方法曾多次发现代码解释和数据总结中的真实错误。

13. 精选长文档内容而非全部呈现

输入更多材料并不会自动提升回答质量。直接粘贴整个代码库或冗长的PDF文件而不进行任何预过滤，往往会导致模型只浏览文档的开头和结尾部分，而忽略中间内容。更好的方法是让Claude先提取出相关段落，然后再对这些段落进行分析——这其实就是“检索后再推理”流程的简化版本：

Step 1: extract the 5 passages most relevant to
[my question], quoting them exactly.
Step 2: analyze only those passages.

14. 比较多个来源时为文档添加标签

在比较多个来源时，应明确地为每个文档标注标签并编号，而不仅仅是用空行分隔它们。这一小处调整就能显著减少模型将某项内容错误地归到其他文档的情况。

<document index="1" name="Q3_report.pdf">...</document>
<document index="2" name="Q2_report.pdf">...</document>

15. 结构化输出的明确边界

当需要严格的 JSON 格式或特定架构时，应直接说明并要求列出确切的键名，而非含糊地描述结构并期望模型能正确推断：

Return only a JSON object with keys: title, summary,
confidence (0-1), open_questions (array of strings).
No text before or after the JSON.

第三部分 —— 要求模型清晰阐述推理过程

16. 对于任何非简单的问题，要求模型逐步给出推理过程

要求模型在给出最终答案之前分步骤解决问题，并指出过程中的所有边缘情况，这比看上去需要做更多的工作。对于任何涉及数学、多步骤逻辑或需权衡取舍的决策，都应采用这种方法。而在那些看似“显然简单”的任务中跳过这一步，恰恰是问题容易出错的时候。

17. 使用提示链而非一个庞大的请求

人们很容易想把所有任务都整合到同一个请求中：阅读内容、总结要点、将其转化为社交帖文，还要想出标题。但将任务拆分成一系列依次进行的提示，能在每个阶段都获得更好的结果，因为每一步只需专注做好一项工作即可：

[1] extract key facts
      |
      v
[2] turn facts into a 3-paragraph summary
      |
      v
[3] turn summary into 5 short takeaways

18. 用于解决决策僵局的逆向头脑风暴法

这种技巧起初看似只是个花招，但实际上非常有用。不要直接询问如何让项目成功推出，而应先从反方向入手提出问题：

Brainstorm 10 ways this launch could fail. For each
one, invert it into a concrete thing we'd do
differently. Flag the 3 inversions that are the least
obvious.

这种方法能揭示出那种直接要求“给出策略”的提示往往忽略的盲点。

19. 面对存在实际权衡的决策时采用的多角色辩论法

这可能是列表中最有效的技巧。在面对相互冲突的决策时，让 Claude 从多个不同角度阐述观点，然后再综合出建议：

Optimist            Skeptic           End user
      "ship faster"      "watch runway"    "don't care
           |                   |            about our
           v                   v             problems"
            \                 |                /
             \                |               /
              \               |              /
               v              v             v
                    synthesized recommendation

如果只输入“直接给我你的建议”这样的指令，得到的往往是最容易让人接受的答案。而先强制其进行内部讨论，就能得出更为清晰、更有说服力的结果。

20. 在同一轮对话中自我批评并修改

这一方法在之前提到的评分标准基础上进行了简化——通过一个指令即可同时获取初稿、对该初稿的自我批评以及修改后的最终版本，无需多次来回沟通：

Draft 1 -> list 3 weaknesses in Draft 1 -> Draft 2

21. 让其在开始工作前先提出澄清问题

对于任何含糊或可能产生重大影响的情形，应明确指示模型先不要开始处理，而是先询问它需要哪些问题的答案。这虽然会在首次真正给出回应之前造成短暂延迟，但往往能避免后续的反复修改。

22. 元提示——让模型优化你的提示

这是一种很少被使用的技巧。当某个提示持续生成质量一般的输出时，不必自己重新编写，可以直接询问：

Here's the prompt I've been using: [paste]. Here's the
output it produces: [paste]. What's wrong with the
prompt, and rewrite it.

这样往往能发现你自己未曾注意到的含糊表述，主要是因为你已经知道自己的意图，从而忽略了那些模糊之处。

23. 将其视为对话，而非一个完美的单一提示

这是思维方式上最大的转变，与其说是一种技巧，不如说是摒弃一个坏习惯：不必执着于寻找那个完美的提示词。先要求得到一个初步版本，对其作出反应，再逐步优化。试图将所有要求都塞进一个庞大的提示词中，其结果往往比经过几轮简短的迭代和反馈还要糟糕。

第四部分 —— 构建系统而非提示词

24. 使用持久化的规则文件，避免重复输入

这可能是所有习惯改变中最有价值的一点。不必在每个新的提示词中重复输入语气、受众和限制条件，只需将它们保存在一个独立的 rules.md 文件中：

# Writing rules
- tone: direct, no fluff
- audience: builders, not consumers
- never use: "leverage", "in today's world"
- always: specific numbers, source links, one action item
- format: short paragraphs, 3 sentences max

然后每次开始工作前都先参考该文件：“在开始之前请完整阅读 rules.md。如果你打算违反其中某条规则，请先停下来告诉我。”

这将每次都需要重新进行的提示操作转变为配置一个小型持久化工具。这就如同每天重复打同一场战斗与一次性解决它之间的区别。

25. 明确规划、执行、验证、迭代循环

对于需要多步骤处理的任务——即 Claude 调用工具、编辑文件或运行命令的任务——不要以为模型会自动安排流程。应直接明确说明这个循环：

 ┌─────────┐    ┌────────┐    ┌────────┐    ┌────────┐
 │  PLAN   │ -> │  ACT   │ -> │ VERIFY │ -> │ ITERATE│
 │ max 5   │    │ use    │    │ against│    │  or    │
 │ steps   │    │ tools  │    │criteria│    │ done   │
 └─────────┘    └────────┘    └────────┘    └────────┘
                                  |  fail
                                  v
                             back to ACT

最能有效避免隐性连锁错误的指令其实很简单：只有当前步骤通过验证后才能进入下一步。

26. 以获取的事实而非记忆作为论据依据

对于任何需要事实依据的内容，应明确指示模型从眼前的材料中获取信息，而非依赖训练数据中的记忆。要求它“注明具体出自哪一行或哪个部分”，就能将看似合理的答案转化为可实际核实的答案。如果它无法指出信息来源，那就应视为暂停并手动验证的信号。

27. 在不可逆操作前设置人工检查点

任何发送邮件、提交代码或花费金钱的任务都应包含明确的暂停指令：“在最终操作前停下来，让我看看你准备做什么。”没有任何系统——无论你在深夜时对自己判断有多大的信心——能够可靠到可以跳过这一步。

28. 识别何时不应使用长篇提示语

较大的上下文窗口让人倾向于将所有文档都输入进去，然后寄希望于最好的结果。有时这样确实可行，但往往情况下，仅包含三段相关内容的简短、精心挑选的提示语，其效果会比输入整份文档更好，因为这样就不会迫使模型同时进行筛选和分析。应优先对输入内容进行筛选处理，只有当确实不知道哪些内容是相关时，才考虑粘贴所有内容。

29. 像管理代码一样对提示语进行版本控制

一旦某个提示语开始用于处理实际且重复性的任务——比如生成定期报告、客户交付物或任何持续性的工作——应将其保存在带有日期戳和简短变更记录的文件中。在某个“小改动”悄然破坏了你所依赖的功能之前，这可能看起来有些多余，但一旦没有记录显示该提示语在前一周的具体内容，问题就会显现。

30. 当您希望避免按令牌计费或不让数据存储在外部服务器上时，可在本地运行工作流

这些方法均无需依赖托管 API。对于需要反复迭代的内容——比如测试自我评估标准，或是上述的规划/执行/验证循环——通常可以先使用 Ollama 的本地模型进行原型设计，待最终确定提示词后再将其导入 Claude 进行最终处理。这样不仅成本更低，而且在调整提示词时数据也不会离开您的设备。

如需快速测试 Claude API，可使用托管版本：

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 500,
    "messages": [{"role": "user", "content": "Score this draft 1-10 on clarity, then revise it: [paste draft]"}]
  }'

使用 Ollama 实现的本地自托管版本，无需 API 密钥且没有按令牌计费：

# one-time setup
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama pull llama3.1
# same self-evaluation prompt, run locally
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Score this draft 1-10 on clarity, then revise it: [paste draft]",
  "stream": false
}'

本地模型虽无法完全匹配Claude的细微表达能力，但用于优化提示词结构——比如检查评分标准是否格式正确、约束条件是否真正得到遵守——已经足够了，而且一旦设置好就无需额外成本。

快速参考：投入与回报

以下是根据哪些技术真正提升了输出质量、哪些仅能带来表面上的良好效果而做出的大致排序：

TECHNIQUE                             EFFORT TO ADOPT   PAYOFF
----------------------------------    ----------------  --------
Rules/context file (#24)              low                very high
Multi-persona debate (#19)            low                high
Plan-act-verify loop (#25)            medium             high
Prompt chaining (#17)                 low                high
Permission to say "I don't know"(#6)  trivial            high
Explain the "why" (#5)                trivial            high
Reverse brainstorming (#18)           low                medium-high
Contract system prompt (#10)          medium             medium
"Act as an expert" persona (#11)      trivial            low

如果只能从这份清单中记住一点，那就重点关注那些投入少但回报高的方法：为约束条件附加理由，并明确允许模型表示自己不知道。这两个简单的改进，比任何复杂的结构框架都更有效地解决了大量不良输出问题。

如果您不同意此排名中的任何部分，或者发现这些技巧中有某种实际上会损害您的特定使用场景，这样的反例远比另一篇泛泛而谈的“能改变你生活的提示词”文章更有用。