形式验证难在人力而非复杂度，LLM 或重启其实用价值

jdpressman 在与 lusichu 的多轮讨论中系统阐述了对形式化验证（formal verification）实用性的看法：所谓「复杂系统无法形式化验证」是过时的缓存直觉，自它作为通用方法被放弃以来，学术界在形式验证方法与工具上持续有稳步进展，且已存在经过形式化验证的操作系统内核（如 seL4 一类工作）。真正的瓶颈不是可计算性，而是人力成本——过去劳动密集到无法实际应用，这一局面可能因 LLM 的出现而改变。

已确认

• 讨论共识：形式验证的困难主要在依赖结构而非可计算性本身。从零（内核）开始强制验证会破坏所有下游软件的兼容性；若坚持兼容性，就被迫使用难以证明的编程模式；从外部向内推进则收益极小，且需要递归式重写全部依赖才能真正获益，因此形式化验证的实用域目前极小。
• 即便部分实用编程模式无法验证或无法替换为可验证等价物，把搜索空间缩小仍有价值。
• 学术界已有 seL4 等经过形式化验证的操作系统内核成果。
• 历史上「已验证软件」要真正有意义，其依赖项也必须经过验证，这正是软件工程持证化运动的动因——只有职业许可制度才能协调验证工具的统一使用。
• LLM 使写代码足够便宜，让「100 倍的代码量」不再构成不可逾越的障碍，为大规模递归式重写提供了新的工程路径，尤其面向对抗性软件场景。

为什么重要

• 针对「用 LLM 逐段加固应用层软件」的「牙签镊子式」设想，jdpressman 指出应用软件本就近乎一次性，这样做并不合理，且底层依赖仍是 C，得到的保护有限；真正的杠杆点在依赖链的根部。这为 LLM 时代重估形式验证的价值提供了框架：当人力成本不再是决定性约束，曾被放弃的通用形式验证方法可能重新进入实用域。

2026-10-23 ~ 2026-10-23 · 7 条相关

• 形式化验证难在人力而非复杂度：已有验证过的 OS 内核 — jd_pressman · 2026-10-23
• 【源头】形式验证被弃用的真相：不是不行，是太费人力 — jd_pressman · 2026-10-23
• 把可验证代码从 1% 缩到全集：形式验证的现实困境 — jd_pressman · 2026-10-23
• 用 LLM 重写软件有多难：从内核下手毁兼容，保兼容就难验证 — jd_pressman · 2026-10-23
• jd_pressman：形式化验证受困于依赖递归，实用域极小 — jd_pressman · 2026-10-23
• LLM 让代码便宜到可递归重写：对抗性软件的新工程路径 — jd_pressman · 2026-10-23
• 【源头】LLM 让代码廉价化,递归重写或破解软件验证难题 — jd_pressman · 2026-10-23