AI 原生业务系统不是一个聊天框

很多产品一说 AI 原生，最后落到界面上就是多一个聊天框。

聊天框当然有用。它适合表达不确定的意图，也适合把复杂入口收敛成自然语言。但如果一个业务系统真正要被 AI 深度参与，聊天框只是最外层的交互形式，不是系统能力本身。

我在 LinchKit 上持续做的一些实验，核心其实不是“让 AI 多写一点代码”，而是另一个问题：业务系统内部的能力、规则和边界应该怎样表达出来。

规则、权限和状态必须先被表达出来

真实业务系统里，最重要的东西经常不是页面，而是规则。

谁可以做这个动作？动作发生前要校验什么？失败时应该返回什么原因？审批后能不能重放？状态变更是否幂等？字段为什么不能被改？一次执行产生了哪些元数据？这些问题如果只藏在代码和口头约定里，AI 很难可靠参与。

所以我更关心实体、动作、规则、状态、事件、权限、执行元数据这些东西。它们不是为了让架构图更漂亮，而是为了让系统有更清楚的语义边界。

当一个动作失败时，系统不能只告诉用户“操作失败”。它应该把规则阻断的原因、执行上下文、可恢复路径清楚地暴露出来。这样后续排查和调整才有事实依据。

另一个容易走偏的地方，是把自动化能力当成一个可以绕过系统边界的超级用户。

这很危险。能力越强，越需要被放在清楚的权限和审计边界里。它可以提出建议、生成方案、解释规则、准备动作，也可以在确认后执行一部分流程；但系统必须知道它做了什么、为什么做、依据是什么、有没有被人批准。

这也是我会反复关注 proposal、approval、execution meta、permission、workflow enforcement 这类机制的原因。它们看起来不如聊天框显眼，但更接近 AI 原生业务系统真正的底座。

AI 原生不是把自然语言贴到旧系统上，而是让系统本身的能力、边界、证据和变化路径变得可读、可审查、可组合。这篇文章只讨论这件事：业务系统的内部结构，必须先经得起人审查，才谈得上让自动化参与。