1+1 假说：能否把编程问题拆到任何 LLM 都能做？

随便一个 LLM 都能算 100 乘 100。随便一个能写代码的 LLM 都能帮你改个变量名。但你让 Qwen 3.5 照着验收标准去实现一个功能，一半的概率会给你一段写得信心满满、结果完全跑不通的代码。同样的任务丢给 Opus 或 GPT-5.4，基本不会翻车。

我自己跑一套 多 AI pipeline 有段时间了。用强模型的时候一切顺利。但只要把模型换成 Qwen 3.5、GLM-5、MiniMax M2.5 这些稍弱的，pipeline 就开始出问题。不是因为这些模型不会写代码——它们显然会。只是输出不够稳定，没法放心丢进自动化流程里。

这让我开始琢磨一件事：如果从「绝对正确」（简单算术）到「基本翻车」（复杂功能）之间存在一个光谱，可靠性到底是在哪个位置断崖式下跌的？更关键的问题是——我们能不能靠工程手段把这条边界往前推，而不是一味等更强的模型出来？

我把它叫做 1+1 假设。不是说软件像算术一样可以叠加（显然不是）。这个假设更具体：对于任何一个能写代码的模型，都存在一个任务粒度，在这个粒度下，解空间足够窄，模型能稳定输出正确结果。工程上的挑战，是找到并达到这个粒度。

能力断崖

我的 pipeline 会把任务拆成大概 50 行代码的单元。强模型处理这些毫无压力。但弱模型的翻车点完全出乎我意料——代码实现本身其实还行。真正出问题的是上游的语义理解工作：模型能不能综合调研结果？能不能判断需求是否完整？能不能看出代码到底有没有符合 review 背后的意图？

这些阶段的解空间太宽了。「这段代码是否符合验收标准」根本没有唯一正确答案。弱模型挂掉的地方不是敲代码，而是做判断。

所以真正的问题不是「弱模型能不能写代码」，而是「我们能不能把 pipeline 的每个环节都收窄到模型能力几乎不影响的程度」。

不是代码行数，是残余解空间熵

我第一个尝试是把单元拆得更小。50 行 Qwen 搞不定，那 10 行总行了吧？结果没啥用。一个需求模糊的 10 行函数，比一个契约写得清清楚楚的 50 行函数更容易翻车。

真正起决定作用的不是代码行数，而是我称之为「残余解空间熵」的东西：当你把所有条件都限定死之后，还有多少种合法实现？如果答案基本就一种，弱模型也能写对。如果答案有几十种，强模型也可能挑到错的。

有三种手段可以压缩这个熵。

第一，接口契约。一个函数签名，带上类型、前置/后置条件、明确的边界 case，基本不留什么自由发挥的空间。模型只需要填函数体，不需要做设计。

第二，测试用例。提前写好的测试把「实现这个功能」变成了「让这些 assertion 通过」。这完全是不同类型的任务，更接近约束求解，而不是开放式生成。

第三招，说实话让我挺意外的——算法提示。就一句话，比如「密码校验用 bcrypt.compare」或者「用滑动窗口遍历」，就能把无限多种实现方式压缩到一两种。最小的干预，换来最大的可靠性提升。

一个实用的收敛性测试：让弱模型跑同一个任务五次。如果四次都产出语义等价的代码，说明任务已经够窄了。如果五次给你五种完全不同的写法，解空间熵还是太高。

分工

这就引出一个不太舒服的事实：你还是得在某处用上强模型。任务拆解本身——决定怎么拆问题、写契约、设计测试用例——需要的恰恰是弱模型最不擅长的那种推理能力。

但这不意味着假设不成立。这恰恰是杠杆效应。

一次 Opus 调用生成 50 个契约，50 次 Qwen 调用分别去填实现。强模型只推理一次，弱模型抄写很多次。比全程跑强模型便宜得多，而且契约在重试时还能复用。

这个模式在学术界有个名字。Burns et al. (2023) 把它叫做「weak-to-strong generalization」——核心思想是，一个强监督者可以通过精心的规格说明，让弱模型也输出可靠的结果。这里的机制一模一样：强模型当架构师，弱模型当施工队。

经济账也算得过来。强模型的 token 花在写 spec 上，弱模型的 token 花在写代码上。Spec 的成本按单元类型固定，实现的成本随尝试次数线性增长。只要弱模型能在几次之内搞定，总成本就比全用强模型低。

不只是实现，上游语义环节也能搞定

但我前面说了，真正翻车的是上游环节。调研、需求分析、code review、任务拆解——这些弱模型也能 handle 吗？

我又专门做了一轮调研，答案是：能搞定一部分，前提是你得重新设计这些环节的流程。

有两种方法管用，原理各不相同。

多视角分发可以收窄判断空间。不是让一个模型「review 这段代码」，而是给十个模型各自一个聚焦点：「检查 SQL 注入」「评估错误处理」「验证 API 契约」。每个聚焦的问题都窄到弱模型能处理。然后机械地合并结果：取并集、去重、按严重程度排序。我的多 AI pipeline 本来就是这么干的，但这次我理解了它为什么能 work——不是因为模型多样性，而是因为每个问题的范围被压窄了。

递归拆解则在每一层收窄推理范围。不是直接说「把这个 500 行的功能拆成原子单元」（太难了），而是先说「把这个功能拆成 3 到 5 个主要部分」（简单），再把每个部分拆成 3 到 5 个子部分（更简单），一层层递归直到原子粒度。每一步都比一次性全拆要简单。Least-to-Most Prompting 和 Decomposed Prompting 的研究也印证了这一点——子问题越小，确实越好解。

但有个坑：朴素的递归拆解会层层放大错误。顶层拆错了，下面全废。它只有在每一层都有类型化的输出 schema、能在局部验证，并且系统能回溯或尝试其他拆法的时候才靠谱。本质上这已经是一种 Tree of Thoughts 方法了。

真正能跑的组合方案是：递归拆解管结构，多视角分发管每层的覆盖面，结果机械合并，只把冲突往上抛。综合这一步不需要多聪明，需要的是结构化。

分层防御

为了验证这些想法，我组织了一场多 AI 辩论：11 个模型，横跨 4 个家族（Claude Opus、Qwen 3.5、Kimi K2.5、GLM-5、Qwen 3 Max），两轮对抗式讨论。结果它们独立收敛到了同一套五层架构：

层	作用	举例
能力分类器	把任务路由到对应的模型层级	新算法 → 强模型；CRUD → 弱模型
结构化约束	在生成前压缩解空间	契约、schema、算法提示、checklist
静态验证	最便宜的关卡——拦截表层错误	类型检查、lint、schema 校验
测试执行	功能验证	预写测试当 oracle
迭代修正	错误反馈闭环	生成 → 测试 → 把错误喂回去 → 重试（最多 3 次）

最小可用技术栈取决于你的可靠性目标：

目标	最小技术栈
~80%（内部工具）	契约 + 静态关卡
~90%（面向用户）	+ 迭代修正
~95%+（关键系统）	+ 能力分类器 + 强模型 review

迭代修正这一层值得单独说说。弱模型第一版可能只有 60% 的正确率，但当你把具体的测试失败信息和报错贴给它看，第二版就能跳到 85%。这其实不是什么新概念——本质上就是现代版的 counterexample-guided inductive synthesis (CEGIS)，程序合成领域用了几十年的老技术。LLM 版本只是更便宜、更灵活。

盲目共识为什么行不通

我最初还有一个假设：靠量堆共识——让五个弱模型做同一个任务，输出结果多数投票。Token 成本低，规模化跑起来似乎可行。

辩论中每个模型都否决了这个方案。全票否决。讽刺的是，恰恰是这些本应被该方案使用的模型，自己论证了自己不该被这么用。

原因可以用 Condorcet 陪审团定理来解释。多数投票只有在各个判断的错误相互独立时才能提高可靠性。但这些模型都训练在相似的 GitHub 和 Stack Overflow 语料上，共享着系统性的盲点。五个 Qwen 实例给你的不是五个独立意见，而是同一个意见采样了五次，只带点微小差异。

但这里有个细微之处我差点忽略了。盲目共识（多数投票，没有 oracle）行不通。带验证的搜索（大量采样 + 强选择器）行得通。AlphaCode 生成成千上万个候选方案，然后用测试执行来过滤。Codex 的实验表明 pass@100 远超 pass@1。Brown et al. (2024) 也发现，只要有 verifier，inference-time scaling 就是有效的。

这个区分很关键。共识衡量的是「一致性」，不是「正确性」。Oracle 直接衡量的才是正确性。当你有一个足够强的 oracle（测试、静态分析、执行），大量采样就变成了一种搜索策略，而不是投票策略。

诚实地说局限

我得先交代一下自己的盲点。产出这些发现的多 AI 辩论，本身可能就存在认知同质化的问题。这些模型共享训练数据、共享 benchmark 常识、共享常见论文。它们的「普遍收敛」可能只是来自重叠知识库的相关性一致——跟我们刚才批评的盲目共识是同一类失败模式。

所以，请把这些发现当作假设，而不是定论。

话虽如此，失败模式是真实存在的，值得逐一列出来：oracle 失灵（弱测试带来虚假的安全感）、接口泄漏（被拆开的单元之间存在隐式耦合）、分布不匹配（常见 Python 写法没问题，碰到冷门 API 就歇菜）、拆解错误（抽象边界划错了，每个下游单元局部看都对，拼起来全局就错）、以及经济账问题（拆到某个程度，分解本身的开销就超过直接上强模型的成本了）。

能覆盖多少比例，高度依赖领域。CRUD 和数据转换类任务，大概 80% 都够窄。安全关键代码或全新算法，可能只有 60%。至于从零开始的架构设计，答案可能就是「老老实实用强模型」。

还有一个 bootstrapping 问题。总得有人——不管是人类还是强模型——先把契约写好。这个假设减少的是强模型的使用量，不是消灭它。

所以这意味着什么

1+1 假设站得住脚的版本是这样的：对于目标编程范式有非零覆盖率的模型，只要你加上一个足够强的 oracle，可靠性问题就变成了一个搜索空间工程问题。

别想着把弱模型变聪明。把解空间收窄，把 oracle 变强。

Harness 和模型本身一样重要。甚至可能更重要。