2 篇博文 含有标签「system-prompts」

你的系统提示最初只有十二行，运行得非常顺畅。后来产品团队要加语气规范，法务部门要加免责声明，安全团队又追加了三条约束。现在你有了四十条规则，模型却忽略了其中一半——而且每次忽略的还不是同一批。

这就是指令遵循悬崖：当你在提示中多加一条规则时，不仅仅是这条新规则的合规率下降——昨天还运转良好的其他规则也会跟着失稳。而且与大多数工程故障不同，这种失败方式令人抓狂地不确定。

你的系统提示词（system prompt）起初只有 200 个 token。一个清晰的角色定义，几条格式规则，一两个约束条件。六个月后，它变成了 4,000 个 token 的指令堆砌，其中一半互相矛盾，团队里也没人能解释为什么会出现关于 JSON 格式化的第三段内容。欢迎来到提示词膨胀（prompt sprawl）—— 这种生产环境中的问题会在每个人都认为提示词“没问题”的情况下，悄悄削弱你的 LLM 应用。

提示词膨胀发生在你把提示词当作“只增不减”（append-only）的配置时。每一个 bug 都会换来一条新指令。每一个边缘案例都会换来一条新规则。每一个利益相关者（stakeholder）都会换来一段新文字。提示词不断增长，却没人删掉任何东西，因为没人知道哪些是起到支撑作用的（load-bearing）。

这就是遗留代码 —— 甚至更糟。没有编译器来捕捉矛盾。没有类型系统来强制执行结构。没有测试套件能验证第 47 条指令是否否定了第 12 条。而且，与乱作一团的代码库不同，你无法安全地进行重构，因为没有依赖图（dependency graph）来引导你。