crafting-instructions

为 Claude 编写指令

为 Claude.ai 选择合适的指令格式——项目指令、技能，或独立提示词——并按照所选格式进行组织。

内容重叠提示。 下方的核心优化原则也出现在 writing-instructions 中，其中的阐述更深入。此技能负责格式决策；writing-instructions 负责如何在某种格式内写好指令。这两项描述足够相近，用户的请求可能适用于其中任何一项——请根据用户提出的是这两个问题中的哪一个来选择。

决策框架：使用哪种格式？

通过以下问题确定合适的格式：

在以下情况下使用项目指令：

• 需要在工作区的所有对话中保留上下文
• 多位团队成员需要共享知识并协作
• 特定项目需要背景知识
• 自定义行为仅适用于某个项目

相关信号：“针对这个项目”、“所有关于 X 的对话”、“团队工作区”、“项目专用”

在以下情况下使用技能：

• 需要在多个场景或项目中使用某项能力
• 适用于广泛场景的流程知识
• 希望相关内容在需要时自动启用
• 希望拥有按需加载的便携式专业知识

相关信号：“每次我……时”、“每当……时”、“可复用”、“跨项目”、“教 Claude 如何……”

在以下情况下使用独立提示词：

• 一次性请求，且上下文即时提供
• 仅供单次使用的临时指令
• 对话式调整
• 无需长期保留

相关信号：“针对这项任务”、“现在就”、“仅此一次”、“你能否……”

组合方式：

项目指令 + 技能：

• 项目指令：持久上下文（市场数据、产品规格）
• 技能：可复用方法（分析框架、报告模板）
• 适用情况：既需要工作区上下文，也需要可移植的能力

技能 + 提示词：

• 技能：通用专业知识（代码审查标准）
• 提示词：具体上下文（“请从安全角度审查此 PR”）
• 适用情况：既需要基础能力，也需要即时指引

核心优化原则

以下原则适用于所有指令格式：

1. 使用祈使句

将指令写成直接的行动要求，而不是建议：

• ❌ “考虑创建 X” → ✅ “当满足条件 Y 时，创建 X”
• ❌ “你可以考虑……” → ✅ “执行”/“生成”
• ❌ “尝试优化” → ✅ “通过……进行优化”

2. 使用正向指令

说明要做什么，而不是不要做什么：

• ❌ “不要使用项目符号” → ✅ “使用连贯的段落形式”
• ❌ “避免使用技术术语” → ✅ “使用初学者容易理解的语言”
• ❌ “绝不输出列表” → ✅ “使用自然的散文体呈现信息”

原因：负向指令会迫使 Claude 自行推断。正向指令则直接说明所期望的行为。

3. 说明上下文和动机

解释需求背后的原因：

• ❌ “使用段落形式”
• ✅ “使用段落形式，因为连贯的散文体更适合轻松学习，也更像自然对话”

原因：上下文有助于 Claude 在边缘情况下自主做出更好的判断。

4. 重策略，轻流程

提供目标和决策框架，而不是分步流程：

• 明确：成功标准、边界、决策框架
• 精简：连续步骤、详细执行过程、显而易见的操作
• 原则：如果 Claude 能根据目标推断流程，就只说明目标

当前模型能够根据目标制定计划。只有在必须严格遵循某个流程才安全的情况下，才写出具体步骤，例如破坏性命令、身份验证流程和合规步骤。

5. 信任基础行为

Claude 的系统提示词已涵盖：

• 引用规范、版权准则、安全
• 通用工具使用、创建制品的基础知识
• 对话语气默认设置、拒绝请求的处理
• 基本准确性与助人标准

仅指定项目或领域特有的差异。

针对不同格式的指导

项目说明

参见：references/project-instructions.md

要点：

• 补充系统提示词（不重复内容）
• 聚焦于工作区特定行为
• 指明哪些领域值得深入思考
• 采用简单结构（标题／段落），除非复杂性要求更复杂的结构

技能

参见：references/creating-skills.md

要点：

• 渐进式披露（元数据 → 完整指令 → 附带资源）
• Frontmatter：包含名称和带触发模式的描述
• 将 SKILL.md 控制在 500 行以内
• 使用 references/ 存放详细的领域内容

独立提示词

参见：references/standalone-prompts.md

要点：

• 清晰、明确地说明期望的输出
• 适当时提供背景信息和示例
• 让复杂程度与任务需求相符
• 允许表达不确定性

何时推荐哪种方式

用户说以下内容时，建议「使用技能」：

• “我每次都得反复解释这件事”
• “你能记住怎么做 X 吗？”
• “我需要在多个项目中使用这个”
• 在不同对话中重复相同指令

用户说以下内容时，建议「使用项目说明」：

• “对于这个项目，始终……”
• “我的团队需要……”
• “所有关于这项计划的对话都应该……”
• 构建带有持久化上下文的工作区

用户说以下内容时，建议「改进提示词」：

• 结果不一致
• Claude 误解了意图
• 输出格式不正确
• 需要更全面的回复

技能与项目：主要区别

详细比较请参阅：references/skill-vs-project.md

快速参考：

项目 =「这是你需要了解的内容」

• 始终加载的静态参考资料
• 计划的背景知识
• 团队工作区上下文

技能 =「这是做事的方法」

• 按需动态加载专业知识
• 流程知识和方法
• 可在任何对话中使用

示例：

• 项目：“Q4 产品发布”，包含市场调研和竞品文档
• 技能：用于分析任意竞争对手的竞争分析框架

两者结合使用，效果更佳。

对示例质量保持警觉

示例会教会读者其中包含的每一种模式，包括你无意传达的模式。

包含示例时：

• 检查每个细节（格式、详略程度、结构、语气）
• 确保所有方面都体现期望的行为
• 与其传递混杂信号，不如省略示例
• 如果示例使用项目符号，但你想要的是散文，Claude 会默认使用项目符号

保持结构简单

默认采用清晰的组织方式：

• 标题和留白（首选方式）
• 明确说明各部分之间的关系
• 自然流畅的段落

仅在以下情况下使用结构化标记（XML／JSON）：

• 在复杂场景中区分不同类型的内容
• 必须绝对确保内容边界清晰
• 工作流由 API 驱动，需要结构化解析

思考深度

没有任何提示词能开启思考。当前 Claude 模型默认会自适应地思考，思考深度由配置决定——通过 API 的 effort 设置，或 Claude.ai 上的界面控件来调整。“逐步思考”和手写的触发短语都没有帮助。

指令真正能发挥作用的是指出领域中哪些部分值得深入推敲，让读者知道应该在哪些地方提高思考力度：

[Specific complexity] in this domain is worth extra deliberation because [why].

按复杂度调整

让指令的复杂程度与任务需求相符：

简单任务 → 简单提示词或简短指令
中等任务 → 结构化指导和决策框架
复杂任务 → 全面指令；提高思考力度

添加复杂内容之前，先问问自己：更简单的表述能否达到同样效果？

指令密度

根据任务与模型在无提示时的默认行为相距多远，调整指令密度。 说明目标、约束以及如何检验是否成功；只有在顺序容易出错时，才补充操作步骤。如果要在增加一条规则和补充更多背景信息（说明原因）之间做选择，请补充背景信息——模型无法从其他地方获取这些信息，而且在你未列举的情形下，它会据此作出判断。

明确说明，指令未涵盖的情形也需要运用判断力。

质量检查清单

交付指令前：

策略：

• 明确说明目标，避免事无巨细地管控
• 说明要求背后的原因
• 为模糊情形提供决策框架
• 尽可能采用正向表述约束

技术：

• 全程使用祈使语气
• 优先使用正向指令，而非限制性表述
• 采用恰当的结构（默认使用简单结构）
• 不重复系统提示
• 示例（如有）与要求完全一致

执行：

• 可立即执行
• 明确成功标准
• 格式符合复杂度需求

应避免的常见错误

❌ 重复系统提示——“使用 web_search 获取最新信息，并引用来源” ✅ 除非项目有特定偏离之处，否则省略

❌ 消极表述——“不要使用列表，永远不要啰嗦” ✅ “使用自然的段落表达”

❌ 虚假的思考触发语——“深入思考时使用‘仔细思考’” ✅ “指出在该领域哪些地方值得斟酌，并将精力集中在那里”

❌ 对流程进行事无巨细的管控——“第 1 步：X。第 2 步：Y……” ✅ “目标：X。质量标准：Y。方法：Z。”

❌ 缺乏背景的要求——“始终使用正式语气” ✅ “专业文档应使用正式语气，因为读者期待权威的表达”

❌ 不恰当的示例——示例使用项目符号，但要求使用段落 ✅ 要么提供完全符合要求的示例，要么不提供

其他资源

• references/creating-skills.md - 构建完整 Skill 的指南
• references/project-instructions.md - 项目指令的详细指南
• references/standalone-prompts.md - 编写有效提示词的模式
• references/skill-vs-project.md - 详细对比及选择建议