有一个判断我最近越来越明确： LLM 产品优化这件事，本质上在分叉。 不是“效果好不好”，而是——你到底在改什么。 是结构，还是概率。
我一开始其实也没意识到这个问题。很多所谓的“优化”，看起来都很合理，比如 prompt 调整、few-shot 补充、system prompt 细化、甚至加一点 heuristic rule。短期看，效果是提升的，有时候还挺明显。 但我后来反过来看这些工作，有点不太对劲。 它们大多数，其实是在“挤概率”。 就是：在当前模型的概率分布上，通过提示词、上下文组织、采样参数，去让某些输出更容易被采出来。 这类优化有个隐含前提——模型本身的能力边界是固定的，你只能在它已有的分布里调权重。 问题也在这里。 如果下一代模型来了，这个分布变了，你之前“挤”的那些局部概率，其实没有任何继承性。甚至很多时候是反向的——你之前的 prompt hack，在新模型上反而变成 noise。 这件事我见过太多次了。
换个角度说。 概率性优化，本质上是在“顺着模型的偶然性工作”。
结构性消歧，是在“对抗模型的不确定性”。 这两个方向，长期结果完全不一样。
我现在越来越倾向于把 LLM 产品问题，拆成一个更底层的判断： 用户的意图，是不是在进入模型之前就已经被“确定”了？ 如果没有，那你后面做的一切 prompt engineering，本质上都是在赌。 赌模型能不能在一个模糊输入下，恰好走到你想要的那条路径。 这件事短期是可用的，但不可积累。
我反而觉得，真正有积累价值的，是“结构性消歧”。 这个词我也是后来才慢慢想清楚的。 不是让模型更聪明，而是让输入更“单义”。 比如： 这些事情，看起来不像“AI能力提升”，甚至有点“传统软件工程味”。 但我现在反而觉得，这是 LLM 产品的核心护城河。
这里有个反直觉点。 很多人会觉得：模型越来越强，这些结构是不是就不重要了？ 我一开始也这么想。 但后来发现刚好相反。 模型越强，它的“可行路径”越多，不确定性反而更高。
如果没有结构约束，它更容易“合理但不对”。 这点在复杂任务里特别明显。
再说一个我自己踩过的坑。 我们曾经在forge产品开发的一个场景里，通过 prompt 精调，把成功率从 60% 提到了 85%。当时觉得已经很不错了。 但过了一段时间，基础模型升级之后，这个 prompt 直接掉到了 70%，而且还不稳定。 后来我们换了个思路——不是调 prompt，而是把输入拆成结构化字段，再做一次意图归一。 结果是：在旧模型上 80%，新模型上 90%+，而且几乎不需要改。 那一刻我才意识到：
之前那 25% 的提升，其实是“借来的”。
本质上，概率性优化是在做“局部最优解”。
结构性消歧是在改变“问题本身的解空间”。 这两者的时间尺度完全不一样。 前者是版本级的。
后者是范式级的。
如果再往下抽象一点，其实就是： 你是在优化“模型行为”，还是在优化“系统约束”。 优化模型行为，本质上是依赖模型。
优化系统约束，本质上是在定义模型。 这两者谁会被下一代模型覆盖，其实答案很明显。
当然，我不是说概率性优化没有价值。 它在很多阶段是必要的，尤其是 MVP 阶段，你不可能一开始就把结构设计到位。 但问题在于，大多数团队会停在这里。 因为它“见效快”。 而结构性消歧，前期是慢的，甚至是反直觉的——你会感觉在“绕远路”。 但如果你不走这一步，你其实没有在做产品，只是在调模型。
这里其实对应一个更大的分水岭。 有些团队，本质上是在做“模型适配层”。
有些团队，在做“AI-native系统”。 前者的价值，会被模型吃掉。
后者的价值，会随着模型增强而放大。
我现在会用一个很简单的标准来判断一项优化有没有长期价值： 如果明天模型换了，这个优化还在不在？ 如果答案是不在，那它大概率只是概率性优化。 如果答案是还在，甚至更强，那它才可能是结构性的。
写到这里，其实有点不太想收束。 因为这个问题我自己也还在反复调整判断。 但有一个方向我基本确定了： LLM 产品的核心，不在“让模型更会做事”，
而在“让问题更少歧义”。 前者是幻觉，后者才是工程。 |
