夜雨聆风AI 可以提出改变，不能绕过验证和业务裁决直接改变事实; 可信编程的语境下 AI 不应该是最终决策者；
一次需求讨论结束后，AI 从会议记录中提取出三个实体、两条关系和一组权限。草案看起来完整，还主动补上了客户联系人常见字段。
其中一条也很“合理”：销售经理可以查看所有客户。
问题是，这家企业按区域隔离客户数据，销售经理只能看本区。AI 没有胡乱拼接字段，它只是生成了一条不属于这家企业的常见规则。
这类错误很难靠模型能力彻底消失。模型越了解通用业务，越会直接做出自认为合理的决策；企业真正关心的，恰恰是自己与“常见做法”不同的地方。
所以，人机协作的关键问题不是 AI 能不能生成业务模型，而是它生成的东西拥有什么权限。
我更赞同一条简单原则：AI 可以提出建议或修改，但不能绕过验证和业务裁决直接采纳。若不先建立提案、验证和裁决边界，AI 只会提高代码产量，不会自动提高业务结果的可信度。
把 AI 放在输出端有什么机制问题
最常见的链路是：Prompt → AI → Project。模型读取需求和仓库，直接修改数据库、后端、前端和测试。
这种方式对局部任务非常有效，但作为长期主链有几个问题。
同一意图可以得到不同实现；生成结果缺少稳定中间锚点；业务知识继续散落在对话与代码中；每次大范围生成都需要重新审查产物。模型升级会改善平均质量，却不会让非确定输出自动变成企业业务合同。
更隐蔽的问题是错误合成。AI 在数据库、后端和前端分别做出“合理”选择，组合后口径已经不同，而每个局部文件都没有明显语法错误。
解决方式不是禁止 AI 写代码，而是区分两类场景。在开发编译器、平台适配与代码生成层以及特殊扩展时，AI Coding 完全可以提高效率；处理企业业务模型时，最终软件应从验证通过的模型确定地产生。
验证三明治
一种可控结构是：
确定性输入 → AI 提案 → 确定性验证 → 人工裁决或策略合入 → 确定性编译AI 接收良构的 IR 和明确任务，输出结构化增量，而不是直接改最终代码。例如“为 Quote 实体建议 lifecycle Pattern”，输出只包含新增状态、初始状态和迁移。
提案随后经过 schema、符号引用、Pattern 前置条件和不变量检查，与人工输入一样经过完全相同的验证。验证器不需要知道内容来自 AI 还是人。
低风险提案可以在验证通过后按策略自动合入，高风险提案必须由人确认。权限、审批、金额和数据删除默认属于高风险；标签补全、说明文字和部分显示顺序可以更自动。
模型最终如何升级，不改变这套信任边界。团队不需要证明 AI 永不犯错，只需让错误不能静默越过确定性关卡。
AI 最适合做哪些 Pass
在建模之前，AI 可以从访谈、需求文档和旧系统中提取实体、关系和规则草案。它减少的是把自然语言整理成结构的机械成本。
模型稀疏时，AI 可以补全常见字段或反向关系；已有多个实体时，可以推断潜在所有权和索引；遇到“提交后需经理确认”，可以推荐 lifecycle 与 approval Pattern 及参数。
验证阶段也不只依赖机械规则。AI 可以发现命名不一致、流程描述中的语义矛盾，或者解释为什么某次业务 diff 会扩大可见数据范围。这些结果仍是诊断报告或建议，不是最终判决。
验证失败后，AI 可以根据结构化诊断报告提出修复增量。相比让它重新生成整个项目，修复对象更小，成功与否也有明确判据。
最后，AI 可以把模型 diff 翻译成业务语言：“本次修改允许财务角色读取已确认报价，但没有新增编辑权限。”这会缩短业务人员与代码审查之间的距离。
验证器能拦住什么，拦不住什么
schema 能发现字段缺失、类型错误和未知属性；符号检查能发现引用不存在；Pattern 不变量能拒绝非法状态迁移和冲突权限；一致性检查可以验证同一输入是否产生预期 IR。
它们拦不住“合理但不符合本企业实际”的规则。销售经理查看全量客户在很多公司合理，在区域隔离的公司就是越权。只凭通用 schema 无法判断。
这也是人的位置。业务负责人决定本企业的语义，AI 提供候选，编译器保证已确认语义被一致执行。把人留在高风险决策上，不是对自动化的妥协，而是承认企业事实不能从公共语料推导出来。
未来可以用企业既有模型、政策包络和历史采纳记录缩小提案空间，但这仍不能取消责任边界。
审查对象为什么会变小
直接生成项目时，一次权限修改可能涉及迁移、Policy、Controller、路由、前端按钮和测试。审查者必须跨文件确认它们是否一致。
在模型链路中，业务审查首先面对一小段 IR diff：给哪个角色增加了哪个作用域的动作。确定性编译器如何投影权限，属于可重复测试的公共机制，不必在每次业务变更中从头证明。
这并不意味着代码完全无需审查。平台适配、代码生成和编译器改动仍需严格 code review，因为它们影响多个项目。变化是审查成本从每个业务实例上移到共享机制：机制审一次、测很多次，业务语义按小 diff 审查。
AI Coding 仍然有自己的正确位置
算法、创意 UI、性能热点、一次性迁移和模型外扩展，本就不适合全部声明化。让 AI 帮工程师直接写这些代码，往往是最短路径。
平台适配与代码生成层的开发也可以由 AI 辅助。开发者用 AI 写 Laravel 模板，不会让后续的生成过程变得不确定；就像编译器开发者使用 AI，并不意味着编译器每次随机输出。
应当反对的不是“AI 写代码”，而是反对把所有企业业务事实永久寄存在 AI 的一次性生成结果里。
目前仍是一项待验证假设
Software Compiler 项目目前还没有接入 AI Pass。这套人机分工有清楚的架构边界，但缺少对照实验。
要证明它优于直接生成代码，至少要选定同一组需求，让两条路线完成等价系统，然后比较业务缺陷率、人工审查时间、变更后的回归成本和模型提案采纳率。还要明确“缺陷”如何计算，不能只展示成功演示。
在得到数据前，最准确的说法是：验证三明治是一种值得实验的信任架构，不是已经证实的效率定律。
下一篇将讨论人的变化。如果 AI 负责业务知识的提取和补全，编译器负责生成和验证，程序员会被挤出生产链吗？
留给读者的问题： 在你们的业务中，哪些 AI 提案可以“验证通过即采用”，哪些即使结构完全合法也必须由具体责任人批准？
