你的 system prompt 不是指令，是数据
作者的本地模型（Flash Onyx，31B 基础模型 + 约 680 行 system prompt 构建的 agent shell）开始用 prompt 里的示例短语开真邮件——"Morning all, quick one:"——甚至在他输入 "hey" 时回 "Morning."（模型看不见时钟，这是小谎言）。加规则禁止复用示例，三次重建都没用；删掉那个短语，下次构建就修好了。
顿悟：模型不把你的 system prompt 当指令列表读，它当"很可能出现在自己输出附近"的文本来读。 以下每条规则都从这一个想法推出。
四条写 prompt 的规则
- 禁止出现在输出里的短语，就不能出现在 prompt 里。Banning 没用，Deleting 有用。点名坏例子会召唤它——"不是银行余额那条"是得到银行余额那条的好方法。
- 位置胜过措辞：埋在段落中部的规则会被读出又被换掉；同样的话放在该节顶部就立得住。
- 具体胜过原则："rename 前调用 fsync()"立刻落地；"只描述代码实际做出的保证"毫无作用。
- 相信任何结论前，先在三颗种子上验证——这是花时间最多、也省时间最多的一条。
证据与做法
没有任何微调。Onyx 是基础模型 + 内建进 Ollama tag 的 system prompt（用脚本构建）。2.5 版起停止凭感觉编辑 prompt：改 prompt → 重建 tag → 固定种子跑固定 prompt 集 → 读输出 → 判断是否真变了。种子固定让两次运行可比——这是"读起来更好"与"从三颗种子失败到三颗种子通过"的区别。
示例不是示例，是样本：给 Onyx 演示"什么是死锁"的答案（两个函数反序拿锁）后，它开始在自己的解释里复现那段演示——prompt 里的样例文本会被模型当作输出风格的统计证据。
实践建议
- 审查 prompt 里每个短语：它会被当成输出样本，不只是指令；
- 想禁止的行为，删样例而不是加"不要…"规则；
- prompt 迭代用固定种子 + 固定测试集做对照，别靠"读起来感觉"判断改对没有。
来源：Your system prompt isn't instructions. It's data. - DEV Community