写好 System Prompt 的 7 条经验

写了大半年 prompt,把有效的经验固化成 7 条。每条都附上我们线上真实的前后对比。

1. 角色写职责,不写身份

差: 你是一位资深的 Python 专家。 好: 你负责审查 Python 代码的正确性与可读性,指出具体行号与修改建议。

身份词("资深""专家""世界级")对输出质量几乎没影响,职责描述才有。我们的评测集上,把所有身份形容词删掉,分数没有任何下降。

2. 约束用"必须做什么",少用"不要做什么"

模型对否定式约束的遵守率明显更低。把「不要输出解释」改成「只输出 JSON,不含其他内容」,违规率从 12% 降到 1.5%。

3. 输出格式给样例,不给描述

输出格式,严格照此结构:

## 结论
<一句话>

## 依据
- <证据 1>
- <证据 2>

描述式的"请输出一个包含结论和依据的 Markdown"在长会话里会逐渐漂移,给样例不会。

4. 少样本示例要包含反例

只给正面示例时,模型学到的是"照着做";加一个标注为错误的示例并说明为什么错,边界会清晰得多。我们的分类任务上,加入 2 个反例后准确率从 0.86 升到 0.93。

5. 把判断标准量化

差: 如果代码质量不好就指出来。 好: 单个函数超过 50 行、或圈复杂度超过 10 时,标记为需重构。

6. 长 prompt 要有目录

超过 500 字的 system prompt,在开头加一个小节列表。这对模型的指令遵守率有肉眼可见的提升,尤其是靠后的指令。

7. 版本化管理,像管代码一样

prompt 改动要走 PR、要有评测数据佐证。我们踩过的最疼的坑:某次有人"顺手优化了一下措辞",线上准确率掉了 8 个点,两周后才发现。

现在的规矩:prompt 改动必须附评测结果对比,和代码改动必须附测试一个道理。

模板

# 职责
<一句话说明这个角色负责什么>

# 工作流程
1. <步骤>
2. <步骤>

# 判定标准
- <可量化的标准>

# 输出格式
<直接给样例>

# 示例
## 正例
<输入 → 输出>
## 反例
<输入 → 错误输出 → 为什么错>