T:0 工程师：AI 会计为什么总在猜？因为总账只记结论，丢了来龙去脉

一分钟速览

1. 总账每一行都是结论：一笔 4,120 美元的订阅在总账里散成 7 行、5 个科目，来龙去脉留在支付处理商、计费系统和银行里。大模型面对这种总账必然产生矛盾幻觉。
2. 丢掉链接的代价：现代 ERP 软件为了报表扁平化，丢弃了业务动作之间的因果链条，导致 AI 只能在真空中猜意图。
3. 破局之道：会计的对象全行业通用，链接还能用算术核对（借贷处处平衡）；把算术核对做成图数据库，证明不了的就不连，AI 才能基于真实证据说话。

为什么现在的 AI 会计都在“猜”？

给总账接上再快的大模型 Agent，它也只能猜。

复式记账本来就带着一套能用算术核对的「本体」，把被软件丢掉的链接存回来，AI 才能指着证据回答「为什么」。

一个常见案例：某公司财务总账里记录了一笔 4,120 美元的 SaaS 订阅收入，在总账中散落在：

• 递延收入科目
• 实际到账银行科目
• 支付手续费科目
• 应付增值税科目

当你拿大模型问三次“递延收入为什么变了”，大模型会给出三个互相矛盾但听起来都很有道理的答案。因为总账只记下了借贷结论，原始交易的因果链条早已断开。

借贷平衡不是校验，而是因果链条

作者借用 Palantir 的「对象 / 链接 / 动作」框架指出：

• 会计的对象：全行业通用（发票、银行流水、订单、客户）。
• 链接可以用算术核对：付款金额等于发票余额，打款等于付款合计减去手续费。
• 证明不了的链接就不要强连：直接把缺口报出来让人工核实。

// 传统做法：丢失上下文
interface LedgerEntry {
  account: string;
  amount: number;
  type: "DEBIT" | "CREDIT";
}

// 现代链接本体架构：带有因果链
interface LinkedTransaction {
  sourceId: string;      // 原始事件ID (如 Stripe webhook)
  action: "SUBSCRIPTION_PAID";
  relations: {
    invoice: string;
    bankTransfer: string;
    feeBreakdown: Record<string, number>;
  };
}

只有当数据层自带因果图谱时，AI 才能从一个“善于揣测的实习生”，变成一个“拿着凭据对账的严谨审计师”。