RE:CZ

现在是 2026年1月29日，星期四，中午。

调整了一下作息，变成早上起床了。

昨天和 C1 聊了一下 LegionMind 的 RFC ¹功能。他提到：

现在分模块之后，整体干活变得更慢了，就使得早期的文档对齐变得更重要了。

有点像实现的成本和代价变大之后走向了瀑布开发模式。

有没有适用于 AI 工作速度的敏捷模式呢？那一定是 AI 自治的敏捷。

给予 AI 事实，让它能够正确理解事实和意图变得更重要了，就可以产生有效的中间环节的 review 和敏捷迭代。

对此，我的评论是：

AI 自治是对的。因为人介入的成本太高了。但是 AI 如何自治呢？核心在于科学观的对齐。

AI 自治的核心是科学观的对齐

AI 自治的核心在于科学观的对齐。也就是说，AI 需要理解并遵循人类的科学观念和方法论。

人类意图有时候是模糊的、多变的，事前无法测量的。要求人类在实验结果出来之前，与 AI 对齐意图中的每个细节，往往是徒劳的。人类的初始表达中，只有价值观的表达是比较稳定的，其他的意图细节往往需要在实验过程中不断调整和优化。

但是，AI 仍然可以做出一些努力，来对齐人类的基本科学观。

比如说，奥卡姆剃刀原则（Occam's Razor）：如无必要，勿增实体（Entities should not be multiplied beyond necessity）。这是科学界一种非常常用的启发式方法。AI 可以采用这种原则来优化 RFC。

在 AI 生成 RFC 时，AI 往往会加入很多看似美好却不切实际的功能。这样会增加实现的复杂度和成本。这一点相信使用过 PLAN 模式的读者都深有体会。例如，在简单的功能中，添加复杂的错误处理机制，设计长达 6 个月的迭代计划，或者引入不必要的技术栈等。

因此，AI 需要学会如何简化它的目标，避免过度设计和复杂化。通过采用奥卡姆剃刀原则，AI 可以更有效地管理它的目标，从而实现更高效的自治。

AI 应当使用对抗生成架构来处理 RFC 的生成任务。RFC 评审 AI 需要指出 RFC 中的每一个设计点，向生成 RFC 的 AI 提出质疑，要求它解释为什么需要这个设计点。如果设计点的必要性无法被合理解释，那么它就应该被移除。 而生成 RFC 的 AI 需要通过事实约束来支持它的设计选择。

事实约束来源于 Supervisor 提供的事实信息、在环境中探索得到的事实信息，或者从外部知识库中获取的事实信息。AI 需要学会如何利用这些事实信息来支持它的设计选择。这些事实，必须是第三方可验证的。

事实的界定，来源于设计一个可验证的实验🧪，而这向来是科学界的拿手好戏。AI 也可以在工程中参考这一做法，设计一个实验代码。实验方案就是代码本身，而实验的结果即可证明事实的真实性。任何人，包括人类和 RFC 评审者，都可以运行这个实验来验证事实。