这家AI团队用3个旧工具驯服了大模型，提示词长度砍掉70%

去年有个数据在圈内流传：某头部AI产品的提示词迭代了47版，规则条款从12条膨胀到89条，agent的违规率反而从8%涨到了23%。规则越多，模型越聋——这不是bug，是特征。

ProjectBrain团队最近公开了他们反直觉的解法。他们没加规则，反而把提示词砍了七成，用三个老掉牙的技术重新搭建了agent的行为框架。效果？生产环境的可靠性"显著提升"——这是他们自己说的，具体数字没放，但愿意把整套方法开源出来聊。

规则清单的死亡螺旋

他们的起点很典型。早期提示词长这样：

「You are an AI assistant. You must read files before editing them. You must not create a new file when revising. You must not signal completion if tests are failing. You must always include the file_id in your response...」

读完这段的人都能预判结局。模型会"acknowledge"这些规则，然后该干嘛干嘛。长规则列表对模型不是约束，是背景噪音——当规则和流畅输出冲突时，流畅性赢了。这是训练目标的副产品，不是能靠"请严格遵守"修复的。

ProjectBrain的转向发生在第N次迭代后。他们放弃了"编程思维"，转用行为科学的框架：不告诉agent该做什么，而是描述它所处的情境、期望的结果、以及成功/失败的具体样例。

设计成本更高了。每个场景要过一遍happy path、edge case、failure mode。但上线后的稳定性让他们觉得值。

Gherkin：用场景替代指令

第一个工具是Gherkin，行为驱动开发（BDD）时代的产物。结构固定：Given（前提）/When（触发）/Then（预期结果）。

他们改写的提示词长这样：

「As a user, I want to hear the plan before work begins」

没有"必须""禁止"，只有用户故事和场景描述。模型从"遵守规则"切换成"扮演角色完成任务"——这更接近它的训练数据分布。

关键差异：规则是负向约束（别做X），Gherkin是正向描述（在这种情况下，做Y）。大模型对后者的对齐程度明显更高，这是RLHF（基于人类反馈的强化学习）的遗产。

信封DSL：给消息加上下文层

第二个工具是他们自研的"message envelope DSL"（领域特定语言）。简单说，每条消息包一层元数据信封，里面写清楚：这条消息从哪来、当前处于什么流程阶段、对回复的格式预期是什么。

类比的话，传统提示词像群发邮件，所有人看同一份说明书。信封DSL像给每个人发带便签的文件夹——便签上写着"你现在在第3步，下一步需要X格式的输出"。

这解决了多轮对话中的上下文漂移问题。agent不用从冗长的对话历史里推断自己该干嘛，信封上的状态字段直接告诉它。

结构化完成信号：让结束变得可验证

第三个工具最细，但最关键。他们设计了一套"structured completion signal format"——agent完成任务时，必须输出固定格式的JSON，包含：任务ID、完成状态、关键输出摘要、自检通过的字段列表。

不是让agent说"我完成了"，而是让它填一张表格。下游系统可以程序化地验证：必填字段有没有？格式对不对？自检项勾了哪些？

这把"完成"从自然语言承诺变成了可校验的数据结构。幻觉型完成（agent以为自己做完了其实没有）的发生率因此下降。

三个旧工具的组合效应

Gherkin负责行为描述，信封DSL负责上下文管理，结构化信号负责输出验证。单独看都没新意，但叠加后的效果是让agent获得了一份"cleaner operating contract"——更干净的操作契约。

ProjectBrain团队的原话是：「None of these are original. But together, they give agents a much cleaner operating contract in our experience.」

他们的经验数据没全放，但提到一个细节：迁移到这套框架后，提示词的平均长度下降了约70%，而生产环境的违规率"进入可接受区间"。具体数字被模糊处理，可能是商业敏感，也可能是样本量还不够大。

这套方法的成本转移很明显：前期设计时间增加，后期调试时间减少。适合对可靠性有硬性要求的场景，不适合快速试错的原型阶段。

ProjectBrain把完整方法写进了系列博客，这是第三篇。他们还在迭代，下一步据说是把Gherkin场景和实际用户反馈闭环起来——让生产环境的失败案例自动触发新场景的编写。

如果这套框架真的泛化，我们可能会看到提示工程的一个分野：写规则的人，和写场景的人。后者的门槛更高，但产出的agent更可控。你现在的团队，prompt是谁在写？