智能助理还是万能木匠：概率模型的能力边界与正确使用范式

> 前三篇我们聊了上下文密度衰减、工程实践指南和Claude Code 源码拆解。这一篇我们从底层原理出发，系统回答一个根本问题：概率模型到底擅长做什么，不擅长做什么？为什么同样的模型，做策略研究一把好手，抠 UI 细节就频频翻车？

---

一个真实的场景

一个产品版本带着若干 UI bug 上线，需要紧急发小版本修复。事后复盘发现：这些 bug 的共同特征是——让大模型自主完成了精细 UI 需求，margin、padding、动效参数、响应式断点……约束一堆，结果每条约束都漏了一点，叠加起来就是一次带 bug 的上线。

这不是个例。行业里反复出现同样的模式：

• 让 LLM 做策略研究、方案设计、代码解释——产出惊艳
• 让 LLM 做像素级 UI 还原、精确数值计算、多约束同步满足——频频翻车

老板们在 PPT 上看到的提效数字和一线工程师实际感受到的提效之间，存在一个巨大的断层。这个断层不是"模型还不够强，等 GPT-5 就好了"能解释的——它根植于概率模型的本质结构。

---

核心认知：大模型是什么，不是什么

1. 它是 next-token 预测器，不是真理机

大语言模型的本质，是一个在万亿 token 语料上训练出来的自回归概率分布：

P(next_token | previous_tokens)

给定前面的所有词，预测下一个词最可能是什么——这是它唯一做的事。它没有"理解"，没有"意图"，没有"对质量的追求"，只有一个训练目标：最小化下一个 token 的预测损失。

Ted Chiang 在《New Yorker》的比喻很精准：LLM 是"词语的模糊计算器"——就像计算器做算术但不懂数学，LLM 做 token 补全但不理解语义。它生成的东西"看起来合理"，是因为合理的序列在训练数据中出现概率高，而不是因为它"知道那是对的"。

2. 它是 System 1，不是 System 2

认知心理学里，Kahneman 把思考分成两个系统：

Zhang et al. (2024) 的研究 *"Language Models are Not Mostly Left-Brained"* 用神经影像学隐喻论证了：LLM 本质上是 System 1。即便通过 Chain-of-Thought 让它"一步步想"，底层的每一步仍是 next-token 的直觉式预测，不是真正的推理。所谓"推理"只是把 System 2 的过程模仿成了 System 1 能处理的 token 序列。

这直接决定了它擅长和不擅长的事。

---

概率模型擅长的四件事

一、模式补全与生成（Pattern Completion）

这是它的原生能力，也是最强的能力。训练目标就是补全序列，所以：

• 给一个开头，续写合理的内容
• 给一段代码上下文，补全下一行
• 给一个设计方向，生成完整的 UI 骨架
• 给一个研究问题，生成探索性的方案

在这些任务上，模型调用的是万亿 token 中内化的统计最佳实践。当你说"做个 Notion 风格的卡片"，它不是在"计算"卡片应该长什么样，而是在调用它见过的几百万张 Notion 风格卡片的统计分布——这比任何一个设计师凭记忆做得都全面。

量化实践中的成功案例：让 LLM 帮你探索因子组合、生成回测脚本框架、解读一篇新论文的核心思想、把一个想法从 0 到 1 搭出原型——这些都是模式补全的甜蜜区。你给方向，它给第一版，质量往往超出预期。

二、语义映射与转换（Semantic Transformation）

翻译、改写、摘要、解释、重构——这些任务的本质是在保持语义不变的前提下改变表示形式。

• 把一段业务逻辑翻译成代码
• 把一篇学术论文改写成通俗解释
• 把一段复杂代码重构得更清晰
• 把一个自然语言查询转换成 SQL

这些任务的容错空间大：意思对了就行，措辞差一点、代码风格不统一都没关系。模型在这些任务上的准确率可以达到 90%+，因为这本质上是在高维语义空间做映射，而这正是预训练过程中反复练习的事。

三、知识回忆与重组（Knowledge Recall & Recombination）

模型在训练中"读过"了人类公开语料的大部分。当你问它一个在分布内的问题：

• "Python 的 GIL 是什么？"
• "MACD 指标怎么算？"
• "SQLite 的 WAL 模式有什么好处？"

它能快速给出准确、组织良好的答案。更重要的是，它能跨领域重组知识——比如把行为心理学的概念类比到量化交易，把物理里的动量概念迁移到因子投资。这种跨域联想能力，在人类专家中也是稀缺的。

四、启发式探索（Heuristic Exploration）

面对开放问题时——"这个策略思路有没有搞头？"、"这个 bug 可能是什么原因？"、"这个模块怎么设计比较好？"——模型能快速给出有价值的候选方向。

它给出的答案不一定对，但大概率有信息量：可能指出了你没想到的方向，可能提供了新的关键词，可能帮你排除了一些错误路径。这正是"智能助理"最核心的价值——不是替你做决定，而是帮你更快地探索可能性空间。

---

概率模型不擅长的六件事（以及为什么）

一、多约束精确满足（Combinatorial Constraint Failure）

这是 UI bug 的头号元凶。

La Malfa et al. (2024) 在 *"The Combinatorial Bottleneck of Language Models"* 中给出了一个残酷的公式：

当任务同时有 k 个独立约束时：
约束满足率 ≈ p^k

其中 p 是单约束满足率（即使 GPT-4 级别，约 90-95%）

代入算一下：

一个典型的精细 UI 需求，约束数量轻松超过 20 条（边距、颜色、字号、圆角、动画参数、hover 状态、响应式断点……）。数学上就注定了一次成功率极低。

更糟糕的是，约束之间往往有隐性冲突——模型遇到冲突不会报错，它会默默妥协其中一边，而你无法预测它会妥协哪边。这就是为什么"看着差不多但到处是小问题"是 LLM 做精细 UI 的典型输出。

二、像素级/数值级精度（Sub-Token Precision）

Design2Code 基准（Liu et al., 2024, Microsoft）系统测试了 GPT-4V 和 Claude 3 Opus 将网页截图转为 HTML/CSS 的能力：

• 颜色、间距、字体大小等像素级属性错误率 >60%
• 布局结构（flex/grid）错误率 30-40%
• CSS 冲突处理几乎全部失败
• 响应式多断点设计失败率 >80%

原因有两个：

• Token 化损失：颜色 #FF5733、像素 16px、时间 200ms 这些精确值会被拆成多个 token，模型对这些 token 之间的精确关系没有强建模。它知道"应该是个蓝色"，但不知道是 #007AFF 还是 #0066CC。
• 没有反馈闭环：人做 UI 时眼睛实时看到效果，不对就调。模型输出完代码就结束了，没有"渲染→看→调"的闭环。它无法像人一样感知"这里差了 2px"。

三、长链条精确推理（Long-Chain Deductive Reasoning）

当一个任务需要 10 步以上的严格逻辑推导，且每一步都不能错时——复杂数学证明、多步算法实现、大规模重构中的跨文件一致性——模型的错误率会沿着链条累积。

这和约束满足的乘积衰减是同一个原理：如果每一步推理的准确率是 95%，那么 20 步链式推理的全对率只有 36%。

Karger & Mendoza (2024) 在 *"Why Do LLMs Fail at Reasoning?"* 中论证了：模型不是"不会推理"，而是它做的是最可能的推理路径而非正确的推理路径。在训练分布内，这两者高度重合；一旦走出分布（复杂的、新颖的、多步的），两者就会分叉。

SWE-bench 的数据（截至 2025 年底）最能说明问题：

也就是说，即使是精心设计的 Agent 框架加持、有测试用例当裁判，真实世界软件工程任务的成功率也就在 50-75%。在更复杂的企业级场景（没有清晰 issue、没有测试用例、约束众多），成功率掉到 12%。

四、分布外泛化与真创新（Out-of-Distribution Generalization）

Helwe et al. (2024) 在 *"On the Limits of Autoregressive Generation"* 中从信息论角度证明：自回归模型本质上是在训练分布上做 annealed sampling，因此：

• 不可能系统性生成训练分布中罕见的事件（长尾组合）
• 对训练数据中不存在的组合只能插值，不能外推（true novelty 的天花板）

换句话说：模型是"见过一切的平均者"，不是"突破范式的创新者"。它能做"现有最佳实践的重新组合"，但做不出"颠覆现有范式的东西"。

这也解释了为什么模型做策略研究效果很好——量化策略是开放问题，重组现有思路就能产生有价值的新方向。但让它做一个需要突破现有认知的数学证明，它往往给出"看起来对但有 hidden flaw"的答案。

五、自我置信度校准（Calibration of Confidence）

Xiong et al. (2024) 的研究 *"Can LLMs Express Their Uncertainty?"* 得出了一个反直觉但极其重要的结论：

• 让模型自己说"我有多确定"（verbalized confidence）是最不可靠的置信度评估方式
• 模型在分布外任务上严重过度自信：正确率 60% 时声称的置信度可能高达 85%
• 多次采样一致性（self-consistency）和 logprob 分析比 verbal confidence 可靠得多

通俗讲：模型越说"我确定"，你越要小心。它在会的任务上可能说"可能是这样"，在不会的任务上反而自信满满地给出错误答案。这是人类使用 LLM 最容易掉进去的陷阱之一。

六、否定约束遵循（Negative Constraints）

Si et al. (2024) 在 *"Why Can't LLMs Follow Simple Instructions?"* 中发现：

• 肯定约束（"要做 X"）的遵守率显著高于
• 否定约束（"不要做 Y"）——后者失败率高出 30-50%

原因在于：预训练的本质是学会"什么是常见的"，而不是"什么是禁止的"。"不要用全局变量"、"不要超过 80 字符"、"不要在这个文件里 import XXX"——这些否定指令和模型的生成直觉冲突时，它很难系统性地遵守。

---

根本矛盾：创造力-精度帕累托前沿

Beam et al. (2024) 的论文 *"The Creativity-Precision Tradeoff in Large Language Models"* 提出了一个关键洞察：

不存在一个"完美温度"能同时最大化创造力和精度。
这是一个本质的 Pareto 权衡，不是超参数问题。

创造力 ↑
  │        ★ 高温度：创意好、多样性高、错误多
  │
  │    ★ 中温度：平衡区（默认推荐）
  │
  │              ★ 低温度：精确高、模板化、无惊喜
  └──────────────────────→ 精度

• 低 temperature（<0.3）：精确性提升但输出高度模板化，无法应对新情况
• 高 temperature（>0.8）：多样性和创意爆发，但事实错误率上升 3-5 倍
• 你不可能在同一个 prompt 里同时要"天马行空的创意"和"丝毫不差的精度"

这就解释了为什么 Vibe Coding（说感觉、给方向、自由发挥）效果好——它把模型放在创造力帕累托前沿的最优区域；而"30 条 UI 约束精确执行"把模型推到了精度前沿的死胡同——它在那里既没创造力，也达不到真正的精度。

---

能力矩阵：一张表说清楚什么时候用、怎么用

---

正确范式：把 LLM 当"聪明的研究员+实习生"，不当"万能木匠"

核心类比：木匠 vs 助理

LLM 是后者，不是前者。 这不是对模型的贬低——一个聪明助理的价值本身就是巨大的。一个随叫随到、读遍人类知识、30 秒出一版方案、不知疲倦的助理，是人类历史上从未有过的生产力工具。

但如果你把助理当木匠用——给它一个模糊的"做个完美的 XX"然后指望它交付成品、处理所有意外、自己兜底质量——你会失望。助理不会主动发现它没注意到的问题，不会在你没说的地方给你兜底，不会在"看起来差不多"的时候继续抠 2px 的偏差。

正确的协作模型

┌────────────────────────────────────────────────┐
│  人类（工头/导演/研究员）                         │
│  ├─ 目标分解：把模糊需求拆成清晰的子任务           │
│  ├─ 约束设定：只给核心约束，细节靠迭代             │
│  ├─ 质量判断：人眼/人脑/测试做最终裁决             │
│  └─ 兜底责任：对最终结果负责                     │
│                                                │
│  交付 ─→ ┌──────────────────────┐ ←─ 反馈        │
│         │   LLM（智能助理）      │                │
│         │  ├─ 模式补全/生成      │                │
│         │  ├─ 语义转换          │                │
│         │  ├─ 知识重组          │                │
│         │  └─ 启发式探索        │                │
│         └──────────────────────┘                │
│                    ↓ 输出                       │
│              第一版草稿/骨架/方案                 │
│                    ↓ 验证                       │
│         人看 → 调整指令 → 再生成 → 收敛           │
└────────────────────────────────────────────────┘

量化研究中的正确姿势（个人实践验证）

在量化系统开发中，我自己的经验是：

LLM 极其擅长的：

• 读一篇新论文，1分钟告诉你核心思想、什么策略可以借鉴
• 搭一个回测框架骨架，从数据加载到可视化一气呵成
• 写数据处理脚本，清洗、合并、计算指标
• debug 时给你列"可能是这 5 个原因"，快速定位排查方向
• 解释一个你不熟悉的库/API/报错

需要你自己把关的：

• 策略逻辑的每一步是否符合金融常识（模型会"看起来对"但逻辑有洞）
• 回测结果是否过拟合（模型没有"这曲线太好看了一定有问题"的直觉）
• 实盘交易的边界条件（网络断开、数据缺失、涨跌停）
• 资金管理和风险控制（涉及精确计算和业务理解）

简单讲：LLM 帮你加速"从 0 到 1"的探索，但"从 1 到 100"的精细化必须你自己来。这和做 UI 是同一个道理——骨架让它搭，边距你自己调；策略让它提，逻辑你自己验。

---

为什么"AI 100% 替代程序员"是幻觉

把上述所有分析放在一起，你会发现：目前的 LLM 架构（自回归 Transformer）从原理上就无法可靠地执行精细多约束任务。这不是"等模型更大就好"的问题——

• 组合爆炸是数学问题，不是规模问题：约束满足率按 p^k 衰减，模型再大，单约束满足率也不可能到 100%，k 大了一样崩。Berglund et al. (2024) 发现增大模型规模不能自然消除反转诅咒等结构化缺陷。

• 精度-创造力权衡是信息论问题：同一组权重不可能同时在两个帕累托最优点上。Beam et al. 的实验表明这不是超参数能解决的。

• System 1 到 System 2 不是"升级"，是"换架构"：让 next-token 预测器真正实现 System 2 推理，可能需要外部符号系统、验证器、搜索算法的加持——这就是为什么 Agent 框架（搜索+验证+工具使用）比裸模型效果好得多，也是为什么 SWE-bench 上 Agent 框架比裸模型高 25-50 倍。

真正的提效路径不是"让 AI 自己做完所有事"，而是构建"人类+AI"的协作系统：

• AI 做它最擅长的：生成、探索、补全、转换
• 人做 AI 做不到的：目标设定、质量判断、边界兜底、创意决策
• 工程系统做兜底：自动化测试、类型检查、视觉回归、CI/CD

这三者叠加，才是真正的生产级范式。裸模型自动驾驶——无论模型多大——在当前架构下都会在精细约束场景翻车。

---

给实践者的五条铁律

铁律一：不要一次性给超过 5 条硬约束

要么拆分任务分步做，要么让它先做骨架你再迭代，要么用约束解码（guidance/outlines）在解码层强制执行。超过 10 条硬约束的 prompt，数学上成功率已经很低了。

铁律二：对 AI 输出保持"信任但验证"

任何进入生产环境的代码，必须经过：

• 自动化测试（单元测试、类型检查、lint）
• 人类审查（特别是边界条件和业务逻辑）
• 真实环境运行验证

"它说改好了"不是信号，"测试全过+你看了代码+跑了一遍"才是信号。

铁律三：Vibe Coding 做骨架，精确迭代做细节

Step 1: 说方向 → 让它出第一版（Vibe 模式，高温度）
Step 2: 跑起来看 → 你判断整体对不对
Step 3: 反馈调整 → 一次只说 1-2 个问题（低温度，精确改）
Step 4: 重复 Step 2-3 → 直到收敛

这比"开头写 30 条约束一次做完"成功率高一个数量级。

铁律四：开放问题用 AI 发散，精确问题用 AI 辅助

铁律五：知道什么时候关掉它

AI 是工具，不是宗教。如果遇到以下情况，关掉 AI 自己写可能更快：

• 你已经知道怎么写，只是懒得打字（这种情况反而容易被 AI 带偏）
• 任务是精确的数学/算法/边界条件处理
• 改第 5 版了还不对，说明方向有问题，需要人重新思考
• 上下文已经 30 轮了，模型开始失忆——开新对话或自己写

---

结语：聪明助理，不是万能木匠

概率模型是人类有史以来最强的智能助理——知识渊博、反应迅速、不知疲倦、擅长联想和生成。但它从原理上就不是一个能独立完成精细活的万能木匠。

认清这个边界，你会发现 AI 的提效是真实的、巨大的——但不是老板们 PPT 上写的那种"一个人干十个人的活"，而是"一个人加上 AI 能干原来三个人的活，而且干得更有趣"。

试图让 AI 当木匠的人，会反复被 2px 的边距、漏掉的边界条件、自信满满的错误答案折磨；把 AI 当助理用的人，会发现它是一个能极大扩展你认知半径和执行速度的神器。

它不是来替代你的。它是来放大你的。

前提是——你要知道它擅长什么，不擅长什么，然后把它放在对的位置上。

---

参考论文与延伸阅读

能力边界的理论基础

• Helwe et al., "On the Limits of Autoregressive Generation" (2024) — 自回归模型的信息论极限
• La Malfa et al., "The Combinatorial Bottleneck of Language Models" (2024) — 约束满足的组合爆炸
• Beam et al., "The Creativity-Precision Tradeoff in Large Language Models" (2024) — 创造力-精度帕累托权衡
• Karger & Mendoza, "Why Do LLMs Fail at Reasoning? A Statistical Perspective" (2024) — 推理失败的统计本质

具体缺陷研究

• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (2023) + Zhang et al. (2024) 后续验证
• Longpre et al., "The Reversal Curse" (2023) + Berglund et al. (2024) 扩展研究
• Gonen et al., "And the Winner is... The Prompter" (2024) — 格式约束的遵循率
• Si et al., "Why Can't LLMs Follow Simple Instructions?" (2024) — 指令遵循失败分析
• Xiong et al., "Can LLMs Express Their Uncertainty?" (2024) — 置信度校准问题

UI / 代码生成专项

• Liu et al., "Design2Code: How Far Are We From Automating Front-End Engineering?" (2024, Microsoft)
• White et al., "Can Vision-Language Models Generate Accurate UI Code?" (2024)
• Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" (2024)
• SWE-bench Mobile (小红书, 2025) — 企业级 App 开发成功率 12%

认知与隐喻框架

• Ted Chiang, "ChatGPT Is a Blurry JPEG of the Web" (New Yorker, 2023) — "模糊计算器"隐喻
• Zhang et al., "Language Models are Not Mostly Left-Brained" (2024) — System 1/2 分析
• Bommasani et al., "Foundation Models and the Automation of Competence" (2024) — 流动智力 vs 晶体智力
• Shanahan, "Talking About Large Language Models" (Philosophical Transactions of the Royal Society, 2024) — 拟人化陷阱

本系列前文

• 01 - 上下文密度衰减：为什么越详细的需求越容易做崩
• 02 - 最大化 LLM 能力的工程实践指南
• 03 - Claude Code 源码深度拆解