一、问题的起点
这两年，AI编程工具发展很快。GitHub Copilot、Cursor、各种代码生成工具不断涌现。但我一直有一个疑问：
既然AI已经能写代码了，为什么我们还是要一行行手写高级语言？
顺着这个思路，我设想了两种可能的替代方案：
一种是“提示词即程序”。用自然语言描述需求，直接交给LLM执行逻辑判断。虽然性能会慢，但开发效率能提升很多。
另一种是“让AI直接生成低级语言”。绕过高级语言的中间层，直接输出汇编代码甚至机器码，追求极致的性能。
带着这些想法，我和AI进行了一次深入的对话。
二、最初的反驳：高级语言为什么依然存在
AI给出的回应让我重新思考了高级语言的价值。
高级语言是可验证的逻辑描述。
如果你让LLM直接生成机器码，拿到一串十六进制数字，你根本无法判断它是否真的实现了你的需求。唯一的验证方式就是运行测试。但黑盒测试永远无法覆盖所有情况。任何需要可靠性的系统，都需要人能看懂、能审查的代码。
高级语言保留了设计意图。
int、string这些类型概念，在编译后都会消失，变成无类型的内存字节。函数调用在汇编层面退化为寄存器和栈操作。你失去了所有模块结构，也失去了“这段代码代表一个订单”这样的业务语义。当需要修改逻辑时，面对汇编代码，你看到的只是指令序列，而不是业务意图。
高级语言是团队协作的基础。
大型软件项目动辄几百万行代码，需要几十上百人协作。如果没有清晰的抽象和类型约束，协作几乎不可能进行。
三、一个新的角度：GPU并行与CPU串行
在讨论中，我注意到一个现象：
现在的LLM底层运行在GPU上，其架构天生就是为大规模并发和概率计算设计的。这解释了为什么LLM的输出总是带有一丝“发散”和“随机”——它在本质上是基于概率的。
而传统的程序是运行在CPU上的，其核心特征是确定性。CPU的每一步运算都是确定的逻辑门操作，没有概率，没有随机。这保证了程序的可预测性。
这两种硬件的哲学从根本上就是不同的。一个擅长并行联想，一个擅长串行确定。
那么问题来了：如果我们要“创造程序”，究竟应该用哪种能力？
四、核心设想：用CPU“反向计算”出程序
一个想法突然冒了出来：
既然CPU能运行程序，那能不能反过来——用CPU的确定性逻辑，去“算”出一个程序？
具体来说是这样的：
传统计算：已知程序P和输入I，计算出输出O
反向计算：已知输入I和期望输出O，搜索出程序P
这让我想到超级计算机的应用方式。别人用超级计算机是给定方程和数据，求解未来状态（比如天气预报）。而我设想的，是给定需求和示例，让计算机在一个巨大的程序空间中搜索，找出那个满足所有约束的程序代码。
这就是学术上所说的程序合成。
五、程序合成的现实与挑战
这个想法在理论上完全成立。程序合成的基本方法包括：
符号执行与约束求解：把“程序能正常运行”的要求，翻译成一组精确的逻辑约束方程，然后求解。
程序空间搜索：在所有可能的指令组合中，进行系统性的搜索，直到找到一个能完美匹配所有输入输出示例的程序。
形式化验证：通过数学方法证明一段代码满足给定的规范，而不仅仅是测试它。
但这条路面临一个根本性的困难：组合爆炸。
程序空间的大小是惊人的。对于一个只有几行代码的简单函数，其可能的写法数量就超过了宇宙中的原子总数。纯粹的暴力搜索在计算上完全不可行，无论多少CPU核都无法穷举。
六、物理边界：熵增定律允许这种事吗？
聊到这里，一个更深层的问题浮现出来：用计算去“创造”程序，是不是在凭空产生信息？这会不会违反热力学第二定律？
答案是：不违反，但代价极大。
这里涉及一个物理学原理——兰道尔极限。它指出，计算中每擦除1比特的信息，最少需要消耗 kTln2kTln2 的能量。
程序合成需要不断测试候选方案，每次发现“这个方案不对”，就要擦除中间结果，再尝试下一个。每一次擦除都产生不可逆的熵增。整体来看，局部信息的“创造”，被巨大的热耗散所补偿。所以理论可行，物理上也不违背任何定律，只是能耗极高。
七、一条可行的融合路径
既然纯暴力搜索不行，纯AI的概率生成又不够可靠，那么把两者结合起来，就成了一条自然的路径。
这就是目前学术界在探索的神经符号系统：
联想单元负责生成。
利用神经网络在高维空间中的模式匹配能力，从海量的程序可能性中，快速提出一批有希望的候选方案。这解决了“从哪里开始搜”的问题。
逻辑单元负责验证。
利用CPU/FPGA等确定性计算资源，对这些候选方案进行严格的形式化验证。通过验证的，才能被确认为正确的程序。
这种架构下，两种计算方式各司其职：
GPU负责“猜”，提供速度和覆盖面
CPU负责“验”，提供确定性和可靠性
八、结论
回到最初的问题：为什么AI时代我们还在写高级语言？
经过这番推演，我理解到高级语言暂时无法被替代，不是因为它“古老”，而是因为它扮演着一个独特的角色：它是人类意图、AI生成、机器执行三者之间最可靠的中间表示。既是人能审查的逻辑描述，也是机器能精确编译的规范输入。
但未来的编程范式确实在变化。
我们可能会走向一个多层级协同的模式：顶层用自然语言描述需求，AI生成高级语言代码作为“审查稿”；中层由人类确认和修改，成为“可信任的源本”；底层则由编译器与验证引擎深度结合，进行优化和验证。
程序合成的终极目标——让计算机从需求中直接“算”出程序——在理论上是成立的，只是受限于计算复杂度和物理成本，目前还只能应用于特定领域。
理解这些之后，我对“写代码”这件事有了新的认识。我们现在手写高级语言，不是技术不够先进，而是因为精确的逻辑表达始终需要一种人能理解、机能执行的形式。这个本质需求没有变，只是我们实现它的方式正在发生变化。
写在最后：思辨本身，就是推动力
回头看看这次对话，从最初一个开发者的日常抱怨，到一路逼问至兰道尔极限，我深刻体会到：最有价值的，往往不是直接获得一个标准答案，而是那个不断把问题推向极限的过程。
很多技术的突破，最初都源于一个执拗的提问：“为什么不能反过来？”“为什么必须这样？”
或许我们离真正的“需求直出程序”还很远，但至少这次的吹牛和推演，让我看到了一条清晰的路径。
最后，也把这个问题扔给你：
如果有一天，算力和能源足够强大，我们真的能让CPU集群“反向计算”出任意程序，你第一件想让计算机帮你创造的，会是什么？
（欢迎在评论区留下你的脑洞）
本文源自一次与AI的深夜技术对谈，内容经过整理与扩展，以期引发更多关于程序合成、计算范式与物理极限的讨论。
