它怎么把「应该」和「实际」对上
场景 2 的报销合规审查和场景 6 的门店监控，看似一财务一业务，其实是同一件事 —— 同一个引擎的两个朝向。差别只在节奏（离散单据 / 连续状态），不在本质。
应该是什么 —— 制度、限额、SKU 清单、营业时段。可明文，或从历史学出基线。
实际是什么 —— 发票、报销单、导出表、后台状态。由人按权限导出交给它。
逐条对上，不是抽样。一万张小额票和一百张大额票，成本相同。
找出对不上的那些 —— 重复、超标、离群、缺配置。
每条偏差指到制度第几条、凭证第几张。举不出，就降级为存疑。
排出可执行的清单，交回给人。副作用越大，人的确认越前置。
这个闭环跑成 plan → act → verify → fix —— 拾遗自己造出可校验的信号（内部一致性、制度举证、影子库比对、重跑一致性），再据此自我纠正。
自主性的前提是造得出测试，否则「自主」就是「自主地错」。
能力通用，身份垂直
招一个财务专员：他会 Excel、会写邮件、会读文档（通用能力），但你雇他不是因为这些 —— 是因为他知道你们公司差旅怎么算、哪几个供应商有问题、月末口径是什么（垂直身份）。
拾遗一样。它的垂直度不由 prompt 里写「你是一个财务助手」决定，而由它运行在什么环境里决定 —— 挂载了制度库、主数据、历史台账、数据配方的「业财工作区」。工作区的边界，就是它的垂直度。
模型写代码，代码跑数据 —— 数据基本不出网
模型不看原始数据，它拿到的是表结构、列名、几行脱敏样例和统计摘要；产出 pandas 代码； 代码在本地沙箱里跑，只回传聚合结果和异常行。
出网量降 1–2 个数量级
出去的是结构，不是内容。几十万行明细本来也塞不进上下文 —— 顺带解决了大表处理。
数据不动，权限继承人
它不访问任何你自己访问不到的数据。数据边界完全等于现有权限体系，IT 不需要做任何新的授权决策。
每次出网都记账
发出去了什么、多少字节，都进出网审计日志。可观测、可审计，是产品的一等公民能力。
代价：数据是快照
所以每个结论都显式标注新鲜度 ——「基于 7 月 25 日导出的预算数据」。不拿过期数据硬下结论。
影子库：跑得越久，判断越准
即使不能实时查 ERP，拾遗也持续沉淀本地台账：历史付款、发票指纹、供应商主数据、预算快照、经营基线。
它的判断质量不取决于有没有 API，而取决于影子库积累了多久。 跑上半年，查重和勾稽能力可以接近有 API 的水平。护城河不是发布日建成的，是运行出来的。
不按业务条线分类，用四个正交维度描述任何任务：
设计对了，合同台账、银行流水对账、供应商资质到期提醒 …… 都是免费的。
工具少而通用，知识多而垂直
底层只给沙箱代码执行、文件读写、检索、连接器这几样通用原语；垂直的部分全在知识里 —— 制度、主数据、判例、SOP。反过来做就错了：为「合并表格」「拆分工作簿」各写一个专用工具， 就是把模型当成菜单选择器，自主性从那里就死了。