AI 写代码太快，图工程需要编译器
Graph Engineering Needs a Compiler
AI 生成代码的速度已远超人类理解系统整体行为的能力。LLM 能瞬间写出逻辑自洽的局部代码，却难以把握全局执行顺序，导致系统逐渐演化出无人能完全掌控的隐式模型。图工程让应用结构可视化，但仅靠图还不够，关键在于如何确定执行逻辑。Fluxtion 提出将编排视为编译器问题，通过执行推理（execution inference）从封闭的对象图中自动推导全局调度器，而非依赖人工编写复杂的编排逻辑。这不仅适用于电子交易系统，也为 AI 时代构建可靠、可复现的复杂系统提供了新范式。
AI 生成组件的速度，已经快过人类理解它们组合执行的能力。
- kkkqkqkqkqlqlql
> AI 写代码太快，导致一种奇怪的倒置：编写代码变得廉价，而理解所有这些代码组合起来会做什么却变得昂贵
我相当确定情况一直如此。这难道不是整个软件工程领域存在的理由吗？
- deterministic
> AI 生成组件的速度快于人类理解其组合执行逻辑的速度
没错，但你仍需对最终提交入库的代码负责。所以慢下来，在提交之前确保你真的理解了它。
- v12technology
Hi HN，我是作者。
我来自电子交易领域。当 AI 模型部署在运营交易系统中时，模型本身可能是概率性的，但其护栏、权限以及周围的运行行为必须保持可预测。
我们发现，将这些系统连接起来成本高昂、容易出错，且任何单个开发者都难以完全在脑海中掌握全貌。LLM 可能会让情况更糟：局部看似合理的修改可能会静默地改变全局执行顺序，从而引入微妙的 bug。
我的论点是，对于一个具有声明式局部事件语义的封闭对象图，大部分全局编排是可以推导出来的。组件通过事件处理器、触发器和生命周期方法声明局部意图；编译器随后可以计算出协调计划，并为该事件处理器生成一个固定的、确定性的编排器。
我在文章中包含了一个基于浏览器的 playground，你可以并排查看 Java 组件、推导出的图以及生成的编排器，无需安装任何东西或注册账号。
我很想知道大家认为，哪些编排必须保留为运行时动态执行，而哪些协调可以推导并编译。