大模型输出不可靠是一项已知事实。工程上的可行回应，不在于为模型输出背书， 而在于用四道约束把 AI 的输出与动作限定在可控范围之内： 不确定处着色、结论可反查来源、写操作必经审批、执行前先行预演。
关于大模型能否用于资产管理业务，讨论通常从一个问题开始：它会不会出错。 这一提问方式隐含了一项并不成立的前提——存在不出错的大模型。
生成式模型的输出由概率决定。当输入信息不足、单据缺失或字段含义存在歧义时， 它仍会给出结构完整、行文通顺的回答，其形式与有依据的回答并无差别。 这属于该类模型的固有属性：与版本高低无关，也不会因提示词的改进而消失。
由此得出的工程结论是：目标不宜设定为消除输出中的差错，而应设定为 使差错在造成后果之前被识别或被拦截。要把这一结论落成可以实施的事情， 需要回答四个具体问题：
| 约束 | 具体做法 | 拦截的对象 |
|---|---|---|
| 置信度可视化 | 识别结果逐字段给出置信度，低置信度字段在表单中着色 | 看似确定、实际缺少依据的字段取值 |
| 来源可追溯 | 结论标注所引用的资产字段、单据与集成接口，可反查 | 无来源的结论被当作事实使用 |
| 写操作必经审批 | 高危动作在动作定义上标注 confirm，未携带确认一律拒绝执行 |
未被授权的写入与越权变更 |
| 执行前可预演 | dryRun 先行返回将要发生的结果，不产生写入 |
审批对象与最终执行结果不一致 |
四道约束的共同点是：它们均由接口层实现，不依赖模型自身的判断。 可靠性若依赖模型的自觉，则无法在评审会上被证明； 若由契约与执行管道保证，则可逐条核验。
依据：EAMX 动作契约与统一执行管道的内部实现记录；字段级置信度与动态表单着色的实现说明。
模型对同一份材料的把握程度并不均匀：铭牌上的型号通常清晰可辨， 功率、出厂编号、生产日期等字段则可能因锈蚀、遮挡或拍摄角度而难以确认。 若界面只给出一个填写完整的表单，填写者无从区分哪些取值可靠、哪些取值存疑。
置信度可视化要解决的是这一处信息缺失：识别结果逐字段给出置信度， 低于阈值的字段在表单中着色，并在提交前要求人工复核。 使用者的注意力因此可以被集中到需要核实的少数字段上，而非整体重做一遍核对。
这项机制改变的是差错被发现的位置。缺少着色时，错误取值与其他字段一同录入， 往往要到下一次盘点或对账时才暴露；有着色时，错误取值在录入环节即被标注， 由现场人员当场判断。相关实现见技术系列 《动态表单与置信度着色》。
同时需要说明其边界：着色的含义是「该字段的取值需要核实」，并非「该字段的取值正确」。 置信度阈值为可调整参数，阈值的调整不改变一项前提——最终采信与否，由有权限的人决定。
依据：铭牌识别两阶段管线的字段级置信度输出与动态表单着色实现；置信度阈值按业务域配置。
置信度说明的是「这一取值有多可靠」，来源说明的是「这一取值从何而来」。 两者需要分开处理：一个高置信度的结论同样可能被用于错误的场景， 只有可反查的来源才能支持事后的复核与责任认定。
在本系统中，可追溯分为两层：
上述两项各自解决一个问题：置信度提示哪些内容需要核实，来源支持如何核实。 二者都不改变输出可能出错这一事实，其作用是使差错在事后可被定位， 而不至于只能被追认。
依据：统一执行管道（executeAction）的审计记录字段与三条通道的身份来源设计。
前两道约束处理的是输出的可判读性，第三道处理的是动作的可授权性。 资产数据的差错在多数情况下可以更正，写入类动作一旦执行，其后果需要走完整的更正流程； 部分动作（如报废核销、权限变更）不具备可逆性。
EAMX 的处置方式是把审批要求写在动作定义上，而非交给调用方判断：
高危动作标注 confirm，未携带确认的调用一律拒绝执行。
全部写操作经由同一条执行管道，参数校验、权限裁决、预演、人工确认、幂等与审计
均在管道内部完成——与调用方是 Web 控制台、内嵌 AI 助手还是外部 Agent 无关。
| 动作类型 | 可否自主执行 | 机制 |
|---|---|---|
| 识别、检索、预演、计算、建议 | 可以 | 读操作与 dryRun 预演不产生写入，因此可以放权 |
| 常规写入 | 需确认 | 经 confirm 确认后执行，与人工操作同一管道 |
| 改账、报废、权限变更 | 需人工确认 | 已在动作定义中固定，未携带确认一律拒绝执行 |
| 权限判定在服务端完成：工具清单由服务端按账号权限生成 | 客户端拿到的清单即为服务端的授权结果，前端不存在可绕过的调用路径 |
最后一行需要补充一句：权限判定在服务端完成，这属于权限设计的结果，而非运行时的拦截规则。 两者的差别在于，前者没有可绕过的路径。
登录页内演示账号，由贵方自有 AI 客户端导出工具清单， 与站内所述的动作契约总数与业务域覆盖逐项比对，即可核对上述口径，无需申请。 查看核验方式 →
依据：executeAction 管道的七道环节、CASL 同构权限裁决与动作契约的动作级标注。口径：动作契约共 247 条，覆盖 35 个业务域，该账号可见工具数由端点实时返回。
审批要成立，审批人必须知道自己在批准什么。若提交给审批人的仅是一句自然语言描述， 审批人只能依据描述作出判断，而描述与将要执行的动作之间可能存在偏差—— 这属于 AI 参与业务操作时最常见的一处风险。
dryRun 的用途是消除这处偏差：执行前先请求预演，
系统返回将要发生的结果，而不产生任何写入。审批人看到的是预演结果，
例如哪些字段将变为哪个值、哪些关联记录将随之变化、金额如何变动，据此决定是否确认。
预演同时处理重复提交的问题。Agent 的重试与网络抖动可能造成同一动作被提交多次； 幂等键使同一次调用只生效一次，重复提交不产生第二次入账。
依据：dryRun 预演的返回结构说明与幂等键（idempotencyKey）的实现记录。
能力清单通常被放在页面前部，边界被放在末尾。这一顺序在集团客户的评审场合并不适用： 多数评审会先追问边界，再讨论能力。因此本文将不承诺的事项单独列为一节。
| 事项 | 边界说明 |
|---|---|
| 不承诺识别准确率 100% | 识别结果带字段级置信度，低置信度字段需要人工复核。置信度阈值为可调整参数，其调整不改变人工复核的必要性。 |
| 不承诺完全无人值守 | 高危动作在动作定义上固定要求人工确认。取消人工确认等同于取消审批，本系统不提供该项配置。 |
| 不承诺输出不再出现差错 | 上述四道约束处理的是差错的可见性、可追溯性与可控性，并非差错的发生率。 |
| 不承诺替代管理判断 | 资产处置、预算分配与责任认定等判断仍由有权限的人作出。系统提供依据与预演，不承担决策责任。 |
说明：本页不列示无实测数据支撑的指标，亦不以百分比形式承诺识别准确率或系统可用性水平。
四道约束并非四项孤立的最佳实践，它们的成立依赖同一个前提： 业务能力以契约形式定义。只有动作在契约层被逐条定义， 才可能在其上标注审批要求、绑定权限规则、提供预演入口并统一留痕； 若业务动作散落在各个页面的接口之中，上述四项均无从落实。
247 条动作契约同时投影为 Web 控制台、内嵌 AI 助手与 MCP 工具。约束写在契约上，因此对三条通道同等生效。
全部写操作经同一条执行管道。任何通道都没有绕过的路径，约束无需按通道分别实现。
确认与审批由有权限的人作出，审计记录可回答操作主体。人始终是责任的承担者，AI 的部分以第 06 节所述边界为准。
反过来说，若一项 AI 能力无法回答「它在哪个动作上、受何种约束、由谁确认、留下了什么记录」， 那么它尚不具备进入资产系统的条件。以自然语言操作与以契约操作之间的差别，正在于此。
actionRegistry）与统一执行管道（executeAction）的七道环节设计；CASL 同构权限与只读角色的工具可见范围；字段级置信度与动态表单着色的实现记录247 条动作契约、35 个业务域、该账号可见工具数由端点实时返回、统一执行管道—— 上述各项均无需采信本文陈述，可由演示环境自行核实。