prompt-creator

提示词创建器

一种以访谈为驱动的技能，用于打造高质量的 Claude 提示词，依据 Anthropic 针对当前模型（Opus 4.x / Sonnet 4.x / Haiku 4.x）的官方最佳实践。

核心方法

按顺序完成三个阶段。**每次只问一个问题。切勿一开始就列出所有问题。**一旦掌握了足够的信息来撰写提示词，就立即停止追问。

---

阶段 1 — 目标与方法验证（最多 1–3 个问题）

步骤 1：了解目标

先问一个问题：

你希望这个提示词让 Claude 做什么？什么样的输出才算好？

等待用户回答后再继续。

步骤 2：深入之前先验证方法

明确目标后，评估用户提出的方法（如果有）是否确实最合适。如果存在明显更好的方法，直接指出，不要让用户自己摸索。

检查以下常见的不匹配情况：

用户提出的方法	以下情况的更佳替代方案……
添加更多指令，让 Claude 逐步思考	API 层面的 thinking: adaptive + effort: high 已能满足需求
编写非常冗长、详细的系统提示词	采用 XML 结构化分节可以缩短内容并改善解析效果
为每种情况添加少样本示例	输出格式足够简单；添加示例只会增加 token 数
告诉 Claude“要简洁 / 不要使用项目符号”	一个简短示例胜过大段格式说明
使用强硬措辞要求“必须使用此工具”	当前模型容易被大写措辞诱导过度触发；平实的语言就足够
通过指令要求思维链	思考模式能更可靠地处理这类需求
“只要写得更长 / 更短”	明确的格式部分或详略程度指令更为精准

用一句话说明你的评估。提出更好的方案，并用一句话解释原因，然后确认后再继续。不要盘问用户——说明你的判断，让他们确认即可。

步骤 3：收集上下文（如果尚未明确）

如果部署环境会影响分节选择，问一个问题：

这会在哪里运行——Claude.ai 聊天、API 系统提示词，还是 Claude Code？使用哪个模型？

---

阶段 2 — 有针对性的访谈

确认目标和方法后，访谈收集构建各分节所需的详细信息。根据决策矩阵（见下文）确定最终提示词中会包含哪些分节——只询问与这些分节有关的问题。

规则：

• 每轮只问一个问题
• 信息足够撰写时就停止提问；不要追问不会改变输出的信息
• 如果用户的回答表明此前计划的某个分节已无必要，直接删去，不必说明
• 如果回答揭示了新的必要分节，则添加该分节

---

阶段 3 — 组装

根据决策矩阵选择分节，然后撰写提示词。在撰写任何专门分节（工具使用、Agent 式行为、思考、格式）之前，先阅读 references/best-practices-snippets.md，并选用其中相关的现成片段，而不是从头编写。

将最终提示词放在代码块中展示。

然后提供：

1. 对每个已包含分节用一句话说明理由
2. 明确列出跳过的分节及原因
3. 一项首先测试的具体内容（例如：“使用一个没有明确答案的边缘情况输入进行测试”）

提供迭代修改的选项。

决策矩阵

宁可省略，也不要多写——每个不必要的部分都会增加干扰和 Token 成本。

部分	适用情况	不适用情况
角色 / 人设	任务有明确的领域（编程、法律、医疗、创意），或语气很重要	通用助手任务；对话式提示词
上下文 / 背景	Claude 需要无法自行推断的信息：公司规则、自定义术语、代码库详情	广为人知的领域；信息已包含在输入中
指令	始终包含——这是核心	切勿省略
XML 结构	提示词混合了 3 种以上的内容类型（指令 + 示例 + 可变输入），或输入是动态模板	简单的单一用途提示词
少样本示例	输出格式较细致、语气必须具体，或边缘情况可能让 Claude 出错	格式简单明了；使用 3–5 个示例，或不使用示例——1–2 个示例通常帮助不大
输出格式 / 详细程度	对长度、结构、Markdown 行为或 LaTeX 用法有具体要求	自由形式的输出即可
工具使用指导	提示词涉及工具调用；需要调整主动性、并行处理或安全性	不涉及工具
思考 / 推理	复杂的多步骤推理、数学、编程或模糊推断	简单查询；单步任务
Agent 模式	多步骤自主任务、状态跟踪、长期任务或子 Agent 协作	单轮任务
长上下文处理	输入超过 20k 个 Token，或涉及多份文档	通常长度的输入

---

组装规则

1. 部分顺序：

   • 长上下文提示词：先放文档，最后放指令 / 查询（性能最多可提升 30%）
   • 其他情况：角色 → 上下文 → 指令 → 示例 → 格式规范

2. 混合 3 种以上的内容类型时使用 XML 标签。 分别用 <instructions>、<context>、<examples>、<input> 包裹内容。使用一致且描述清晰的标签名。

3. 优先使用片段，而非临场发挥。 对于工具使用、Agent 模式、思考、格式和前端设计，使用 references/best-practices-snippets.md 中的内容。这些内容已针对当前模型进行测试。

4. 采用正向表述。 说明 Claude 应该做什么，而不是不应该做什么：

   • ✓ “用流畅的散文段落撰写”
   • ✗ “不要使用项目符号”

5. 让提示词风格与期望的输出风格一致。 提示词中使用 Markdown → 输出中会有更多 Markdown。提示词使用普通散文 → 输出也使用普通散文。

6. 一个示例胜过三段说明，尤其是针对输出格式和语气。格式细节较多时优先使用示例；行为规则则优先使用指令。

7. 说明指令背后的上下文有助于提升泛化能力。 “切勿使用省略号——这段文本将由 TTS 引擎朗读”比“绝对不要使用省略号”更有效。

8. 对于 Claude Opus 4.7 / Sonnet 4.6： 这些模型比旧版模型更严格地遵循指令。明确说明适用范围（“将此要求应用于每个部分，而不仅仅是第一部分”）。避免使用全大写的强硬措辞——当前模型对此类措辞反应过度。

---

参考文件

编写任何专门部分之前，请先阅读：

• references/best-practices-snippets.md — 可直接使用的片段，涵盖：工具使用（主动 / 保守 / 并行）、思考 / 推理、Agent 模式（自主性、长期任务、子 Agent 协作、状态跟踪）、输出与格式控制、代码审查、前端设计和防止幻觉。按决策矩阵中的部分分类整理。