一、业务背景同一笔业务为什么会有多个口径中小企业经营数据里的对不上通常不是采集失败而是同一笔业务被多个持有方各自记录且各自的口径不同。典型表现有六类客户进度只存在于销售的聊天记录查询靠人工回翻合同额、开票额、到账额分属三张表对不齐项目延期只在问题发生后才知道验收与回款风险后置费用异动要财务重新拉表解释利润为正但现金紧张两个口径长期分离票据、审批、记账卡在哪一步只能逐一问人。这六类问题的根子在同一个位置事实产生的那一刻没有被记录成可核对的结构后续所有环节都在补录和对账。本文所举数字均为场景化示例用于说明数据口径问题不作为任何企业的案例引用。要解的不是如何让人记得更清楚而是如何让事实在产生的当下就落进一个可复核的结构。下面按背景 → 约束 → 取舍 → 落地 → 边界展开。二、约束条件这个场景不能假设什么先明确约束否则方案会偏离实际。没有专职信息化团队。方案不能依赖专人持续维护 ETL 作业、调度和口径映射。入口已经在 IM 里。员工日常沟通在飞书或企业微信不应要求他们迁移到一套新界面重新录入。财务人手有限。目标是把重复的收集、匹配、改名、搬运降下来而不是增加一道新的录入岗。模型可用性不作前提。识别类能力允许失败、允许降级业务不能因模型繁忙而中断。决定权不在系统。付款、入账、结账、申报、经营决策这些动作必须由责任人完成系统只提供依据与流程。三、方案取舍为什么不用定时对账也不用单一强约束入口方案 AT1 定时批处理对账。每天夜里把三边数据拉齐做差异比对。问题在于它仍在事后工作口径依旧是拼出来的差异出现后定位到单据仍要人工介入等于把对账成本从白天挪到晚上。方案 B单一强约束入口所有事项先在系统里建结构再流转。数据质量更有支撑但改变了员工的动作习惯且要求基础数据先完备落地阻力大。方案 C事件驱动 事实即记录 分层承接。保留员工原有入口在提交那一刻把事项转成结构化事实由分层架构分别承接理解、规则、结论同时满足上面的约束不动入口、不依赖专人、允许降级、决定权仍在人。分层结构如下接入层 / 应用层 / 智能层 / 数据层各层只做自己该做的事接入层 飞书 / 企微 / Web 工作台 / 开放接口 → 统一认证与分发 应用层 六大业务模块 流程引擎 权限引擎 → 规则与流转判定 智能层 意图识别 / 票据识别 / 要素抽取 / 流水匹配 / 摘要生成 数据层 业务库 / 凭证账簿 / 影像存储 / 缓存 / 日志 → 事实底座各层只做自己该做的事接入层解决谁在哪里办事应用层解决按什么规则流转、谁有权处理智能层解决看懂并整理成事实与结论数据层解决事实落在哪里、如何核对。层与层之间以确定的接口衔接任一层的实现变化不改变其它层的契约。四、落地要点1一笔业务落成六个环节事实的归一不是一次性映射而是按环节留下状态。一笔业务的完整走向含六个环节序号环节系统处理1发起员工在飞书、企微或 Web 工作台提交事项识别意图并补齐缺失信息2确认员工核对生成的摘要确认后正式提交3审批进入企业自定义审批流按岗位与金额等条件分支4执行需收付事项进入财务环节核对流水与回单、确认资金5入账凭证草稿生成经复核后过账6呈现账簿、报表和经营摘要随之更新相关责任人收到结果或提醒2计划与账必须分开标识这是解决利润为正、现金紧张的口径关键合同约定的应收应付、预计回款属于计划不等同实际到账流水识别到的收付款属于资金到账财务复核后的入账属于会计确认。三者分开标识才不会把合同生效误读成钱已到账。# 同一笔业务不同事实分表存储不合并为单一已完成状态 fact { biz_id: CT-2026-00871, # 业务对象 plan: {amount: 2_000_000}, # 合同计划应收/预计回款 delivery: {done: False}, # 交付事实 billing: {issued: False}, # 结算事项 fund_arrival: {matched: False}, # 资金到账 accounting: {posted: False}, # 会计确认 } def operating_summary(fact): # 结论层只读事实层 if fact[accounting][posted]: return 已入账 if fact[fund_arrival][matched]:return 已到账待核销 if fact[billing][issued]: return 已开票待收款 if fact[delivery][done]: return 已交付待开票 return 已签约履约中3三端一接口按角色渲染接入层对外是同一套接口服务端按角色渲染不同视图因此飞书、企业微信和 Web 工作台看到的是同一笔业务、同一笔钱、同一份结果——口径不需在三端再对齐一次避免同一件事三个说法。4配置化与降级流程与权限配置化不写死在代码里审批按企业自身流程配置。智能能力与业务数据分离模型繁忙或暂时不可用时规则、模板和工作台照常办事业务不中断。数据层结构化数据与影像文件分离存储便于检索与备份日志在线保留 180 天详情脱敏。五、系统边界哪些不在这套架构的职责内把边界写清楚比把能力写大更有用。以下事项明确不在职责范围内法定申报的提交系统提供申报所需材料与辅助文件提交动作由企业与办税责任人完成记账判断与责任凭证复核、过账与结账由企业责任人执行系统提供依据与流程经营决策系统给出结论与建议动作决定由管理者做出员工薪酬决定调薪、计薪规则由企业确定系统按规则计算与留痕。分工口径也写死在设计里AI 负责理解与整理听懂要办什么、看懂票据与合同、把事实放回同一条链、形成经营摘要同意或驳回、付款、认领流水、生成正式凭证、修改合同核心金额、计算工资与税款、结账、申报由人机规则与责任人完成。数据隔离上一套服务服务一个企业数据不与其它企业混用模型侧可选云端、企业自带账号或本地部署三种方式业务功能一致。上面这套分层与事实模型是这类系统白皮书里的公开设计口径它要回答的其实只是一个问题——怎么让业务与财务之间的那一层由系统承接而不是由人兜底。参考完整的分层说明与字段定义在配套文档里篇幅关系不在本文展开本文只保留能直接对照代码的那部分结构。