一家连锁零售企业的月度经营会上运营岗当着团队的面问助手上个月华东区销售额是多少。助手给出了一个数字。财务岗会后用自己的账号问了同一句话得到的是另一个数字两者差了十几万。事后追查两边都站得住脚运营那边的统计按客户下单时间计入当期、包含未发货订单财务这边按仓库发货确认时间计入并且扣掉了当期退款。同一句话两套口径两个都成立的结果。这类分歧常被记到模型账上处理办法于是落在固定模型版本、收紧随机性参数或者在提示词里反复强调答案要前后一致。这些动作本身没有错作用的位置却不对。两次回答各自的计算过程都经得起复核出错的是销售额这个词在系统里没有被定义成一件确定的事。没有定义的指标只能由执行者在当下替它解释一次解释不同结果自然不同。指标名和指标本体是两层东西。业务人口中的销售额、回款率是约定俗成的叫法落到数据系统里要拆成时间口径、金额口径、范围口径与计算逻辑四个部分。时间口径决定按下单、支付还是发货确认计入当期金额口径决定取原价、实付还是扣除退款后的净额范围口径决定是否含税、是否纳入已取消单据计算逻辑决定去重方式与跨表关联条件。四部分缺了任何一个同一个词都能算出多个说得通的结果而系统不会报错。把指标登记成带口径的定义比较实用的处理办法是把高频指标做成登记在册的定义。登记内容不必复杂但要包含口径字段、责任人、生效版本与变更记录。登记要落到字段一级而不是停在指标名上销售额这类笼统的叫法需要写明它对应哪张表的哪个时间字段、哪个金额字段。业务部门与数据部门共同确认口径确认后的定义才能被查询引用没有登记的叫法不能算作指标。查询先做映射口径不明就问一句使用者说上个月华东区销售额系统在生成查询之前应当先完成一次映射这句话对应哪条登记定义华东属于哪个适用范围上个月落在哪个日历区间。命中登记定义时系统带着口径去执行没有命中或者同时存在几个候选口径时系统应当把候选列出来让使用者确认而不是替他挑一个继续算。代价是一次追问换来的是结果能被别人验证。答案要把口径一起交出来口径应当和数字同时出现。时间口径、金额口径、范围口径随答案展示使用者才能判断这个数能不能与别处的报表比较。两个来源的口径不一致时系统应当说明差在哪个口径上而不是摆出两组数字让人自己猜。口径调整时历史区间的处理方式也要在登记阶段写清楚从变更当期生效还是向前重述否则同一指标在跨越变更点时会出现两套算法。需要说明的是通用模型或Agent平台通常都能连接数据源并生成查询语句但指标口径由谁定义、变更如何生效、历史区间是否重述仍需结合企业自身的指标管理办法来确定。在青山不语AI工作室的企业AI Agent定制方案中企业的高频指标会先登记为带口径字段的定义助手在查询阶段把使用者的表述映射到具体定义遇到多个候选口径时先请求确认答案与口径一并返回口径调整按版本管理并记录受影响的计算范围。这套做法的边界也要说清。指标登记解决的是同一个词指向同一件事它解决不了数据本身不一致的问题。源系统的字段定义出现歧义或者业务内部对一笔交易是否计入存在分歧登记得再多也得不到一致的数字。口径的所有权在业务部门与数据部门助手这一侧负责识别、映射、标注与留痕不负责裁定业务上的分歧。验收可以用两个动作。挑一对只差一个条件的近义指标例如含税与不含税、是否扣除退款各问一次观察结果是否区分口径还是给出同一个数字让使用者自行判断再把某个指标的口径改一版看历史区间的回答有没有同步说明。两个动作的结果大致能说明口径有没有真正进入计算过程。我的判断是企业用Agent查数据真正的难点从来不在查询语句写得对不对而在查询的前提有没有被讲清楚。把指标的口径登记好、在答案里说清楚看似是一件落后于模型能力的工作它却决定了这份数据能不能被拿到经营会上讨论。数字本身不难得到难的是让不同的人说到同一个数字。