过去一周,我一直在琢磨 RAD 式的代码生成器。老式的、确定性的那种。
经典系统有个根本问题:代码生成容易,维护困难。你几乎总得去改输出,重新生成于是变得脆弱。
有些问题现在看着可解了,尤其是通过正规批准的扩展机制来保住自定义改动。
RAD 系统有件事做对了,而且很重要:把模型当成事实的源头。
很多系统比 SOAP 和 REST 还老,所以它们的模型基本是数据库 schema。今天,我们可以更丰富地表达应用意图,把契约、权限、工作流、集成和 UI 行为都装进去。
难点在于应用演进时,怎么保持可维护。
安全性、再生成、可扩展性、架构僵化,是当年的主要弱点。Low-code 活下来了,但「生成可维护的应用代码」这个承诺始终没有真正兑现。
我的理论是:一个干净、灵活的生成器,通过 MCP 露出来,也许能把智能体的 token 消耗降一个数量级。前提是这条工作流真的比直接写代码便宜。这个还有待观察。
我很欣赏 RAD 系统的可预测性。不管你造什么,你都知道会拿到什么。代码质量也许是垃圾,但它是稳定的垃圾。
架构熵
现代编码智能体的问题几乎正相反。
它们能产出杰出的代码,但未必能产出两次相同的架构。这种灵活性带来了架构熵。
这里存在一个很有用的分工。
让确定性生成器去干重复性的实现、惯例和可预测的输出。让智能体去干解读、规格和例外。
把智能放在操作生成器的那家伙里,而不是生成器本身。
我怀疑,当年的很多局限反映的是那个时代的技术、预算和实践,而不是确定性生成本身。
开发者的生产力从那时起已经天翻地覆。编码智能体也把造生成器、养生成器变便宜了。
假如我们能从三个小时生成一个复杂企业应用,变到十分钟,影响可能相当可观。
第二十次修改
但初次生成时间可能是错误的指标。
更有揭示性的测试,是第二十次修改。
经典 RAD 系统就是在这儿散架的。每一次自定义,都在拉大应用与其底层模型之间的距离。
一个因为模型持续表达应用意图所以始终容易修改的系统,会是根本不同的东西。
也许机会根本不在生成更多代码,甚至不在生成得更快……而在减少开发者必须亲自操持的复杂度。
我很好奇可能性空间变了多少。
Codex 刚交了一份初稿。
瞧瞧这个美丽的畸形儿原型。
我要再琢磨一阵子。