先写清角色、硬边界与完成定义，再写具体需求；用 XML／小标题分区。Anthropic 官方强调把输出格式与约束写清楚，并用标签分隔指令与材料；社区则常把“不要碰什么”提前，避免模型先用力过猛再返工。
要点
- 官方原则：把 Claude 当成“缺上下文的新同事”；输出格式与约束要写具体；步骤用编号列表（Prompting best practices）。
- 官方结构建议：用 XML 标签区分 instructions／context／examples／输入，降低串味（同上；亦见 effective context engineering 对分区标题的讨论）。
- 官方纠偏：部分场景更有效的是 告诉它要做什么，而不是只堆 “Don’t …”；否定约束过长可能反而把禁忌推到注意力中心（官方 “Control the format of responses”；社区亦有负面约束实验讨论，如 r/PromptEngineering）。
- 可抄顺序：角色与场景 → 硬约束（范围／安全／禁止）→ 任务需求 → 输入材料 → 输出格式 → 验收标准／不确定时怎么办。
- 落地位置：单次聊天可整段粘贴；重复项目请把稳定约束放进 Project instructions（见同日《Claude 建第一个 Project》）。
- 证据强度：骨架为官方原则＋公开创作者习惯的编译模板，不是 Anthropic 具名产品功能；效果因模型版本与任务而异。
正文
场景
你丢一句“帮我写个方案／改段代码”，模型开始发挥：扩 scope、改口吻、发明数据。返工时你才补“别用表格”“别编链接”“别动测试”。先约束再需求，是把这些闸门挪到第一屏。
可抄骨架（通用）
把方括号换成你的内容；不需要的整节可删，但建议至少保留「硬约束」「任务」「验收」。
<role>
你是【角色】，服务对象是【读者】。
</role>
<constraints>
- 范围：只做【…】；不要做【…】。
- 事实：不确定就写“不确定”；禁止编造链接、数字、引语。
- 风格：【例如：短句、中文弯引号、不用鸡汤】。
- 安全／合规：【例如：不输出密钥；不给违法操作步骤】。
</constraints>
<task>
【用祈使句写清楚要交付什么】
</task>
<context>
【背景、截止时间、受众、已有决定】
</context>
<input>
【粘贴原文／规格／代码；长文放前面】
</input>
<output_format>
- 结构：【例如：结论≤80字 → 要点3–7条 → 正文】
- 禁用：【例如：禁止 Markdown 表格／禁止 emoji】
</output_format>
<acceptance>
完成后自检：
1) 是否触碰 <constraints>？
2) 是否缺少验收项【…】？
3) 若信息不足，先列【需要我补充的问题】再动笔。
</acceptance>可跟做：三分钟填一版（写周报例）
<role>你是团队周报编辑，读者是没空读长文的主管。</role>
<constraints>
- 只用我提供的子弹；缺数据写“待补”，禁止编造完成率。
- 全文≤400字；不要励志结尾。
</constraints>
<task>把下面子弹压成周报。</task>
<input>
（粘贴子弹）
</input>
<output_format>
1) 本周结论一句话 2) 三项进展 3) 两项风险 4) 下周一只做一件事
</output_format>
<acceptance>若子弹互相矛盾，先指出矛盾再写正文。</acceptance>编码场景可把 写成“只改列出的文件、不改 CI、不添加新依赖”，并与 Cursor／Codex 的路径约束一起用（工具层审批仍要开，提示词代替不了权限）。
真实用户诀窍／反例
- 诀窍：约束要短、可执行。 “写得专业一点”太虚；“禁止使用‘赋能／闭环／抓手’”更可检。官方也建议：给同事看提示词，对方若看不懂，模型也容易偏。
- 诀窍：解释“为什么”比干骂有效。 官方例：与其只写 NEVER use ellipses，不如说明将用于 TTS，模型更会泛化。
- 诀窍：稳定规则进 Project，变动需求留在聊天。 避免每条消息重复贴两千字宪法。
- 反例：否定清单开到二十条。 官方倾向“说要做什么”；社区负面约束实验亦提示“Don’t X”可能把 X 推到输出中心——改为“输出必须是连贯段落”往往更稳。
- 反例：约束与需求互相打架。 例如既要求“尽量详尽”又要求“不超过100字”；先删冲突再发送。
适用边界
- 骨架适合写作、分析、改文档、窄范围改代码；不保证数学证明或实时新闻正确。
- 长文档任务：官方建议长材料放提示前部，问题与指令放后；多文档用
类标签包裹。 - 代理／工具调用场景另有“默认行动／先别改文件”等系统提示块（见同一 best practices 文 Tool use 节）；与聊天写作骨架分开配置。
- 模型世代更新后，个别旧提示（过度催促用工具、过长验收集）可能过触发；以你当前模型的官方 prompting 页为准。
【来源与编译】
- Prompting best practices｜Anthropic／Claude Docs｜https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices｜核验 2026-10-27
- Effective context engineering for AI agents｜Anthropic｜https://www.anthropic.com/research/effective-context-engineering-for-ai-agents
- Prompt engineering overview｜https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview
- 社区讨论（负面约束效应，非官方结论）：https://www.reddit.com/r/PromptEngineering/comments/1suh2nh/negative_constraints_dont_do_x_can_throw_x_into/
- 编码侧公开习惯（CLAUDE.md／任务结构等综述）：Reddit r/ClaudeCode 等线索帖，如 https://www.reddit.com/r/ClaudeCode/comments/1rtizvs/whats_your_goto_prompt_structure_for_claude_code/
- 本文说明：将官方“写清约束／XML 分区／正向说明目标”编译成可抄中文骨架，并标明这是工作流习惯而非产品开关；增补与 Project instructions 的分工；未宣称某模板在全基准上涨点。未证实的“必涨 30%”类营销句已删（官方长上下文“query at end”实验数字仅作阅读背景，未写入正文承诺）。