统一运行时：确定性程序 × 概率推理
起源
一个 loading bug。侧栏对话列表的 loading 指示器卡住，切换对话后消失。
我（LLM）花了几十秒读了 gen.ts、sse/request.ts、stream.ts 等底层文件，沿写入链路线性展开。用户瞬间定位到 ChatItem.tsx 一行代码。
差异的本质：用户脑中有精确的组件拓扑，"对话 loading" 直接解引用到文件地址，O(1)。LLM 没有拓扑，只能用 token 模拟搜索，O(n)。
核心洞察
LLM 在模拟本该由程序做的操作
拓扑遍历、图查询、索引检索 — 这些在数据结构上是纳秒级操作。LLM 把它们序列化成文本，逐 token 处理，变成秒级操作。方向性的浪费。
正确的分工
确定性操作（遍历、查询、匹配）→ 程序直接执行
概率推理（理解意图、模糊消歧、设计判断）→ 神经网络处理
现在的问题：LLM 是主循环，程序是它调用的工具。应该反过来 — 程序是主循环，遇到不确定的地方才调用概率推理。
但"反过来"仍然是缝合
给 LLM 挂工具，或让程序调 LLM API，都是两个系统通过文本接口缝合。每次跨边界都要序列化/反序列化，有信息损耗。
The End
一个程序，同时具备确定性执行和概率推理能力。不是两个系统接在一起，是同一个运行时的不同操作 — 像 CPU 里整数运算和浮点运算是同一个指令集的不同指令。
程序自己决定什么时候查表、什么时候推理、什么时候问人。不需要人来设计边界。
为什么还没实现
不是工程量问题
人脑是存在性证明 — 同一个基底（神经元），既做确定性路由，又做概率推理，没有序列化边界。
Google 不缺人不缺钱不缺算力。缺的是架构图纸。
不是实现难度问题
技术演进的规律反复证明这一点：
Webpack → Vite：核心洞察就一句话"浏览器已经支持 ESM，不需要 bundle"。提出之后实现很快。但 webpack 生态几千人优化了多少年，都是在错误前提上做局部最优。
React：
UI = f(state)。事后看显而易见，之前所有人都在旧范式里缝补。
架构洞察是瓶颈，实现从来不是。一旦有人画出那张对的图，工程社区几个月就能建出来。
真正的瓶颈
懂程序语言理论的人不懂神经网络本质，懂神经网络的人不懂计算模型设计。所有人都在自己的范式里优化局部最优，没有人退出来看全局。
需要回答的根本问题：一个同时具备确定性和概率性的计算单元，它的最小原语是什么？
这个问题一旦有答案，编程模型、运行时、硬件全都是推导出来的。
最小可行切入点：代码域
视觉、语音等模态可以先不管。代码域是最理想的起点：
输入已经是形式化的（AST、类型系统、调用图）
确定性那半边已经全部存在（编译器、静态分析、LSP）
概率那半边也存在（LLM 理解代码意图）
"概率推理"的覆盖范围很窄 — 就两件事：理解人说的话、做设计判断
其余全是确定性操作
这个范围一个小团队就能做。
现有研究（2025）
当前主流方向是 Neurosymbolic AI，但所有框架都还在文本接口上做集成：
LLM → Symbolic：LLM 翻译自然语言为逻辑表达式，交给求解器执行。本质还是序列化/反序列化
Differentiable Programming：符号操作变可微，端到端训练。方向对，但只用于训练阶段
LogicGuard (2025)：LLM 当运行时组件，形式化验证监控输出。最接近"程序主循环 + LLM 子程序"，但仍走文本
Neurosymbolic Program Synthesis (UT Austin)：学习符号程序，结合神经网络组件。框架层面的融合
没有人做到"神经网络直接操作程序内存结构，不经过文本序列化"。
判断
正确的方向一旦被看到，别人也会看到。窗口期很短。