Opus 5.5 在架构上的神之一手

2026-10-29 · 技术笔记 · 1082 字 · 约 3 分钟

这篇记一件让我挺震撼的事:同一个问题,换了个模型去问,拿到一个我完全没想到的答案。

同一个问题,两个模型,两种思路

遇到的问题

事情是这样的,我们在做财务处审批的项目,审核接口会给出两样东西,一个是结论,一个是意见。

问题就是,这两个东西老是对不上。意见里写的是一回事,结论又是另一回事,审核的人一看就懵了,到底该信哪个。而且还不稳定,同一张单据跑两次,有时候一致有时候又不一致。

先问的 Astra 6.0

当时我是在和 Astra 6.0 一起探讨这个项目的架构,就把这个问题丢给它了。

它给我的建议就是:不断地去优化 prompt。强调结论必须和意见一致,多加点例子,反复调措辞。

我也确实照着改了很多轮,但是这个问题一直解决不了。不一致的情况是少了点,但是从来没有彻底消失过。

换 Opus 5.5 去问

后来我把一模一样的问题,拿去问了 Opus 5.5。

它给的答案让我很意外。它根本没让我继续改 prompt,而是直接说:

把结论和意见的生成顺序调换一下。

就这一句。

为什么这样就行

我自己的理解是这样的:大模型是一个字一个字往后写的,后面写的东西,会受前面已经写出来的内容影响。

原来的顺序是先出结论、再写意见。这样结论是在它还没“想清楚”的时候就先定了,后面的意见就只能给这个结论找理由,一旦结论下得草率,意见就会跟它别扭。

调换之后是先写意见、再给结论。它先把理由一条一条摆出来,最后的结论是从自己写的意见里推出来的,那肯定就对得上了。

说白了就是:原来是先下判断再补理由,现在是先讲理由再下判断。

结果

调完之后,这个问题就完美解决了。没加什么新的 prompt,也没加例子,就只是把顺序换了一下。

对比我前面改了那么多轮 prompt,这一手的性价比真的高得离谱,我觉得说是“神之一手”一点都不夸张。

我的几点收获

  • 输出的顺序本身就是设计的一部分。 结构化输出里字段的先后,就是模型生成的先后,把“理由”放在“结论”前面,又简单又有用。
  • 一个问题改了很多轮 prompt 还没进展的时候,先别急着继续改,停下来想想是不是结构出了问题。
  • 同一个问题多问几个模型。 这次 Astra 6.0 把我带去了“优化 prompt”,Opus 5.5 把我带去了“改结构”,后者才是根上的问题。

当然,这只是我在这个项目上的一次经历,不是什么严格的对比实验,别的任务上效果可能不一样。但以后遇到类似的问题,这个思路我肯定会先试一下。