大多数提示词失败，都源自少数反复出现的错误。下面每一条都有你会认出的症状、修正方法，以及能检测它的 PromptFlowEngine 规则的链接，规则页面附有触发它的示例和修正后的提示词。
清晰度方面的错误
1. 没有说明目标
提示词只描述了材料，却从不说明要拿它做什么。模型只能在总结、分析和改写之间猜测。
修正： 以一个说明成果的祈使动词开头。参考：缺少目标。
2. 含糊的措辞
“某些”“东西”“等等”这样的词，会让模型自行编造具体内容。
修正： 列出真实的条目。如果清单是开放的，就加以限定：“其中最多 3 项”。参考：含糊的措辞。
3. 含糊其辞的指令
“尽量”“如果可能”“也许”会把要求变成建议，模型会把它当作可选项。
修正： 把它写成要求，或者准确说明它何时适用。参考：含糊其辞的指令。
4. 只有否定式约束
由一连串“不要……”组成的提示词，只告诉模型要避免什么，却没说要产出什么。
修正： 把每条禁令与你想要的行为配成一对。参考：只有否定式约束。
具体性方面的错误
5. 没有数字的大小描述
“短”“几个”和“详细”在每次运行中都不同，会破坏版式和解析器。
修正： 使用数字加单位，例如“不超过 150 个词”。参考：未量化的大小。
6. 没有输出格式
没有格式时，模型会在散文、要点和表格之间选择，而且每次选得不同。
修正： 指定结构；如果有代码读取结果，还要指定 schema。参考：缺少输出格式和缺少篇幅要求。
7. 引用了并不存在的东西
提示词里写着“修复上面的 bug”或“使用附件”，却两者都没有。
修正： 把材料放进去，或说明它会被插入的位置。参考：指代不明。
一致性方面的错误
8. 相互矛盾的指令
“要简短，但要详细。”多人编辑的长提示词容易积累这类矛盾。模型会自行解决冲突，结果无法预测。
修正： 先确定优先级并写明：“保持简洁。当简洁与准确冲突时，选择准确。”参考：相互矛盾的指令。
9. 重复
为强调而说两遍会消耗 token。用略有不同的措辞说两遍，则会让人不清楚哪个版本算数。
修正： 每条指令只在它所属的部分写一次。参考：重复的指令和近似重复的指令。
结构方面的错误
10. 一大堵文字墙
一个长段落把任务、背景、规则和输入混在一起。埋在中间的指令分量更轻，下一个编辑者也找不到任何东西。
修正： 拆分为任务、背景、要求、输出格式和输入。参考：文字墙。
安全方面的错误
11. 未加分隔的用户输入
把模板变量直接放进指令里，会让用户输入的任何内容读起来像是指令的一部分。
Translate this to French: {{user_text}}
修正： 用标签包裹变量，并告诉模型标签里是数据。参考：未加分隔的模板变量。背景：提示词注入。
12. 提示词中的密钥和个人数据
粘贴的配置里有 API 密钥，日志里有密码，工单里有客户邮箱。一旦发送出去，它就进入了第三方的系统。
修正： 发送前先脱敏，并让凭据远离提示词文件。参考：提示词中的敏感数据。背景：提示词中的 PII 与密钥检测。
规则无法发现的流程错误
- 只用一个输入来测试。 在你的示例上有效的提示词，可能在真实流量上失败。建立一个小型测试集。参阅提示词评估。
- 一次改动多处。 结果变了，你却不知道原因。每次迭代只改一处。
- 不对提示词做版本管理。 如果提示词只存在于聊天窗口里，就无法回滚。参阅提示词管理。
- 把上下文窗口塞满。 更多上下文不一定更好。参阅 token 优化。
在你自己的提示词里找到它们
把提示词粘贴到 PromptFlowEngine 提示词分析器中。它会运行上面所有规则，引用触发每条发现的文字，并给出修正建议。完整规则目录列出了全部规则。