确定性详解

传统生成器的问题

当 AI 直接编写应用的代码时，每一次修正都是一次重新撰写。要求一个小改动可能会在别处破坏另一处，且毫无预警。这正是「修正循环」的根源：你修正，它损坏，你再修正。

Maker 的方法：app = builders(规格说明)

在 Maker 中，AI 不编写应用的骨架。它设计一份规格说明：实体清单、业务规则、指标。随后由确定性的构建器——是程序，而非 AI——将这份规格说明转化为数据库、API 路由、表单与导航。

「确定性」意味着：同一份规格说明始终产生相同的骨架。那里没有即兴发挥，也没有凭空捏造的代码。

不过，确实有一些屏幕区块是由模型编写的：仪表盘、列表的汇总区、示例数据，以及 Masterpiece 级别的签名视图。它们范围明确，调用次数事先固定，并且必须通过编译和运行时校验——否则就会被其确定性版本替换。这正是「在受控之下把一个部件交给模型」与「把整个应用交给模型」之间的区别。

流程，逐步进行

• 你的提示词——用自然语言。
• 规格说明——由 AI 设计（实体、规则、指标）。
• 骨架——数据库、API 路由、表单、导航——由确定性构建器根据规格说明编写。
• 交给模型编写的屏幕区块，在保留之前先通过编译、再通过运行时校验。

这对你意味着什么

调整你的应用等同于调整规格说明，然后让构建器重新构建。行为保持可预测：没有意外的回退，没有每次尝试都被计费的修正循环。你可以充满信心地迭代。