AI 输出不合心意时，说清「要什么」并给个样例，别只说「不要」
Anthropic 的提示词最佳实践建议，引导输出格式时告诉模型要做什么，而不是不要做什么，例如把「回复里不要用 markdown」换成「回复由流畅的段落组成」。同一份指南还指出，示例是引导输出格式、语气和结构最可靠的方式之一，建议给 3–5 个，并用 `<example>` 标签与指令分开。反馈迭代时同样适用：与其说「太长了、别这样」，不如直接描述想要的样子。
对比示例反馈迭代
场景：AI 帮忙澄清需求后写了一大篇层层嵌套的列表文档，没人看完，你想让它改短
较差的描述
太长了，不要写这么多，也别用那么多列表。
更好的描述
请重写成给开发同事看的需求确认，用不超过 [5] 句的连贯段落：第一句说要做什么，接着写 [2–3] 条验收标准，最后列出仍需我确认的问题，最多 [3] 个。格式参考下面的样例： <example> [一段你认可的简短需求确认] </example>
- 把「不要写太多」换成读者、句数和结构，模型知道改成什么样才算完成
- 用段落代替「别用列表」，是在描述想要的形态而不是禁止某种形态
- 附一个样例，格式和语气比任何形容词都具体
- 限制待确认问题的数量，避免澄清环节本身又变得冗长
今天就试试找一次你回复过「不要……」的 AI 对话，改写成「请……」加一个样例，比较两次输出。
目标表达上下文供给任务拆解审查验证反馈迭代委派与边界判断与取舍
示例由编辑根据下方来源中的原则撰写。
要点
- 指南原例：用「你的回复应由流畅的散文段落组成」代替「不要在回复中使用 markdown」
- 提示词本身的格式会影响输出格式，去掉提示词里的 markdown 可以减少输出中的 markdown
- 示例要贴近实际场景、彼此有差异，避免模型学到不想要的模式
为什么值得关注
这条原则不依赖具体模型，开源权重模型同样适用；对「AI 澄清需求时写得太长、没人看完」的问题，可以直接用这种写法约束输出。
来源
### [AI 输出不合心意时，说清「要什么」并给个样例，别只说「不要」]({{URL}})
Anthropic 的提示词最佳实践建议，引导输出格式时告诉模型要做什么，而不是不要做什么，例如把「回复里不要用 markdown」换成「回复由流畅的段落组成」。同一份指南还指出，示例是引导输出格式、语气和结构最可靠的方式之一，建议给 3–5 个，并用 `<example>` 标签与指令分开。反馈迭代时同样适用：与其说「太长了、别这样」，不如直接描述想要的样子。
**场景**：AI 帮忙澄清需求后写了一大篇层层嵌套的列表文档，没人看完，你想让它改短
✕ 较差：太长了，不要写这么多，也别用那么多列表。
✓ 更好：请重写成给开发同事看的需求确认，用不超过 [5] 句的连贯段落：第一句说要做什么，接着写 [2–3] 条验收标准，最后列出仍需我确认的问题，最多 [3] 个。格式参考下面的样例：
<example>
[一段你认可的简短需求确认]
</example>
- 把「不要写太多」换成读者、句数和结构，模型知道改成什么样才算完成
- 用段落代替「别用列表」，是在描述想要的形态而不是禁止某种形态
- 附一个样例，格式和语气比任何形容词都具体
- 限制待确认问题的数量，避免澄清环节本身又变得冗长
- 指南原例：用「你的回复应由流畅的散文段落组成」代替「不要在回复中使用 markdown」
- 提示词本身的格式会影响输出格式，去掉提示词里的 markdown 可以减少输出中的 markdown
- 示例要贴近实际场景、彼此有差异，避免模型学到不想要的模式
**为什么值得关注**：这条原则不依赖具体模型，开源权重模型同样适用；对「AI 澄清需求时写得太长、没人看完」的问题，可以直接用这种写法约束输出。
来源：[Prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)