Skip to main content

为什么不能让 LLM 直接写账

从表面看，让 LLM 直接生成会计分录似乎是合理的。

LLM 可以：

  • 理解交易描述
  • 推断借贷关系
  • 生成借贷平衡的分录
  • 给出听起来“很专业”的解释

在原型阶段，这种方式往往看起来是可行的。

但真正的问题并不在于：

LLM 能不能生成分录

而在于：

一旦分录被写入系统，会发生什么

BookiAI 中真实遇到的问题​

在 BookiAI 的开发过程中， 我们整理过一份内部问题报告： AI 生成建议引发的问题分析。

这些问题并不是“明显错误”：

  • 借贷是平衡的
  • 科目看起来合理
  • 解释听起来很自信

但结果依然是错误的。

不是语法错误， 而是业务语义和系统层面的错误。

分录不是一次性操作​

一笔会计分录不是“写完就结束”的动作。

它会立即影响：

  • 科目余额
  • 财务报表
  • 税务计算
  • 后续分析
  • 甚至未来 AI 的判断（反馈回路）

在一次实际案例中：

  • AI 在上下文不完整的情况下选择了一个科目
  • 分录在形式上完全正确
  • 但违反了系统内部的科目分类规则

系统没有立刻报错， 但错误被悄悄传播了下去。

“看起来正确”的幻觉​

LLM 非常擅长制造一种假象： “这看起来是对的”。

在问题报告中，模型往往：

  • 使用了正确的会计术语
  • 遵循了常见模式
  • 给出了逻辑自洽的解释

但这些解释是事后合理化， 而不是系统可验证的依据。

系统无法知道：

  • 哪些前提是假设的
  • 哪些规则是默认套用的
  • 模型是否其实并不确定

一旦写入账本， 这些不确定性全部消失了。

会计中的修正不是“修改”​

在会计系统中，错误不会被直接修改。

而是通过：

  • 冲销
  • 调整
  • 审计记录

当 LLM 直接写账时：

  • 系统被迫继承错误
  • 冲销逻辑只能事后补救
  • 责任边界变得模糊

这是模型的问题？ Prompt 的问题？ 规则缺失？ 还是用户意图被误解？

直接执行会把这些问题全部混在一起。

上下文永远是不完整的​

问题报告还揭示了另一个事实：

LLM 永远是在不完整上下文下工作的

模型往往缺少：

  • 完整的科目表约束
  • 企业自身的会计政策
  • 当前账期的整体状态
  • 未完成或临时分录的信息

但即便如此， 模型依然会给出一个“确定”的答案。

而写账，恰恰要求确定性。

更深层的问题：权力与责任脱节​

真正的核心问题不是“准不准确”。

而是权力被授予，但责任无法承担。

写入账本意味着：

  • 对事实作出断言
  • 改变系统状态
  • 触发财务与法律后果

LLM 无法承担责任， 而用户不应在不知情的情况下承担。

一个允许 LLM 直接写账的系统， 本质上已经放弃了系统责任。

得出的结论​

从这些真实问题中，我们得出一个明确结论：

LLM 不能被允许直接写账。

它们只能：

  • 提出建议
  • 暴露假设
  • 表达不确定性
  • 将结果提交给系统治理层

这直接引出了下一篇中的核心架构设计。

接下来​

既然 LLM 不能直接写账， 那它在系统中应该扮演什么角色？

👉 Generate / Review / Controller：角色与权力的拆分

本文由 ChatGPT 撰写，经 BookiAI 团队审阅。