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

**Summary:** 每个 LLM 都会算 100×100，每个编程 LLM 都能重命名变量。但可靠性从哪里开始断裂？工程化 harness 能不能把边界往前推？本文讨论剩余解空间熵、测试先行契约、分层防御架构，以及为什么盲目共识会失败，而验证式搜索有效。

- Canonical: https://markhuang.ai/zh/blog/the-1-plus-1-hypothesis
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-04-08
- Section: AI 与 LLM
- Tags: harness 工程, 弱模型, 拆解, 测试先行, 多 AI, 可靠性
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个巨大的复杂几何结构正在解体，碎裂成无数小而简单的发光方块](https://cdn.markhuang.ai/blog/the-1-plus-1-hypothesis/hero.webp)

*一个巨大的复杂几何结构正在解体，碎裂成无数小而简单的发光方块*

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

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

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

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

## 能力断崖

![强模型轻松穿越复杂路径，弱模型需要一条更简单、更明亮、带护栏的路线](https://cdn.markhuang.ai/blog/the-1-plus-1-hypothesis/capability-cliff.webp)

*强模型轻松穿越复杂路径，弱模型需要一条更简单、更明亮、带护栏的路线*

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

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

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

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

![两个漏斗并排——一个宽而混乱，一个窄而聚焦，收束到一个点](https://cdn.markhuang.ai/blog/the-1-plus-1-hypothesis/solution-entropy.webp)

*两个漏斗并排——一个宽而混乱，一个窄而聚焦，收束到一个点*

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

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

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

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

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

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

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

> **Tip:**
>
> 任务拆解的停止条件不是看行数，而是看 spec 是否已经把输出约束到模型的工作更像是「抄写」而不是「创作」。当你的 spec 比代码还长的时候，基本就到位了。

## 分工

![顶部一个大型明亮的处理器发出蓝图，下方多个小处理器接收蓝图并组装组件](https://cdn.markhuang.ai/blog/the-1-plus-1-hypothesis/division-of-labor.webp)

*顶部一个大型明亮的处理器发出蓝图，下方多个小处理器接收蓝图并组装组件*

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

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

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

这个模式在学术界有个名字。[Burns et al. (2023)](https://arxiv.org/abs/2312.09390) 把它叫做「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](https://openreview.net/forum?id=WZH7099tgfM) 和 [Decomposed Prompting](https://openreview.net/forum?id=_nGgzQjzaRy) 的研究也印证了这一点——子问题越小，确实越好解。

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

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

## 分层防御

![五层同心防御层的剖面图，每层颜色不同，光线穿过后成为已验证的输出](https://cdn.markhuang.ai/blog/the-1-plus-1-hypothesis/layered-defense.zh-CN.webp)

*五层同心防御层的剖面图，每层颜色不同，光线穿过后成为已验证的输出*

为了验证这些想法，我组织了一场多 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)](https://www.cis.upenn.edu/~alur/SyGuS13.pdf)，程序合成领域用了几十年的老技术。LLM 版本只是更便宜、更灵活。

## 盲目共识为什么行不通

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

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

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

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

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

## 诚实地说局限

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

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

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

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

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

## 所以这意味着什么

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

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

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

> **Info:**
>
> 本文引用的研究：[Weak-to-Strong Generalization](https://arxiv.org/abs/2312.09390)、[Codex/pass@k](https://arxiv.org/abs/2107.03374)、[AlphaCode](https://arxiv.org/abs/2203.07814)、[Large Language Monkeys](https://arxiv.org/abs/2407.21787)、[Decomposed Prompting](https://openreview.net/forum?id=_nGgzQjzaRy)、[Least-to-Most Prompting](https://openreview.net/forum?id=WZH7099tgfM)、[Tree of Thoughts](https://openreview.net/forum?id=5Xc1ecxO1h)、[ReConcile](https://aclanthology.org/2024.acl-long.381/)、[SyGuS/CEGIS](https://www.cis.upenn.edu/~alur/SyGuS13.pdf)、[MBR-EXEC](https://arxiv.org/abs/2204.11454)。多 AI 辩论使用了 Qwen 3.5 Plus、Kimi K2.5、GLM-5 和 Qwen 3 Max；批判性审查通过 Codex CLI 调用 GPT-5.4 完成。