外观
治理与可信机制
企业把 AI 接进生产系统时真正担心的是三件事：它会不会瞎说、它会不会乱改、出事能不能查。下面逐条说明这三件事在 ISCMS 里是怎么被机制而不是被承诺约束住的。
1. 写操作只能生成"待确认提案"
53 个 *_propose_* 工具的共同契约：
- 工具体只写提案表，不写业务表；
- 生成后模型只能回答"已生成待确认提案（提案ID：xxx），尚未生效，请在下方点击【确认】后才会真正生效"；
- 严禁谎报完成——这条写进基线提示词的原因是实测中出现过模型没有调用任何工具却声称"任务已创建生效"。
红线动作永不工具化，AI 侧连提案都出不了：
| 模块 | 一律人工的动作 |
|---|---|
| 货代 | 提交订单、撤回退回、关账与强制关账、发送/执行动作、费用落账与清账、换操作人/委托人/运输段、删单 |
| 船代 | 航次放行、联检结果认定 |
| 拼箱 | 正式下单、落账、删单删方案、改计费基数 |
| 堆场 | 放行/完成闸口、预约核验与取消、实际移箱、主数据变更 |
| 车队 | 派车、司机接单/拒单、状态到已结算/已关闭/取消、运力停用、批量保养生成 |
| 账务 | 审核、记账、结账等内控动作 |
| 人事 | 审批、月报发布与锁定、日结果改写、薪资字段、跨员工数据 |
2. fail-closed：没登记的工具，模型看不见
写工具必须逐个在写策略里登记为「提案」模式才会被注册。未登记、或该模块的写总闸关掉时，工具从画像里直接消失，模型压根没有调用它的可能，而不是"调用了会被拒绝"。
登记的完整性由产品内置的自检断言守着——漏登记会静默让工具消失，所以这条断言是每次发版的回归门禁之一。
11 个模块各自注册自己的写策略（货代、船代、拼箱、仓储、堆场、车队、账务、CRM、人事、邮件、流程），公共层不硬编码清单。
3. 写前先预演
移库、计量、盘点、对账、库位状态这类提案，先调 wms_preview_proposal 看影响 diff（含是否会产生差异单）再出提案。预演与真实执行共用同一套校验，结论一致——所以"预演说会动 3 条"和"确认后真的只动 3 条"是同一份代码保证的。
4. 只答工具返回的事实
- 需要数据必须调工具查询，逐条引用工具结果，工具没返回的内容一律不回答；
- 查询走与页面相同的 Service 与分页通路，部门数据权限照常注入，不会出现"AI 里的数和报表对不上"；
- 名称歧义命中多条时必须让用户选，不得默认取第一条，也不得凭记忆解析 ID。
一个真实的口径教训
货代模块按箱号/提单号查询时，如果绕过页面通路直接查实体，某些通路缺少对应的条件字段，会整条丢掉过滤条件、返回无关单据。所以画像约定：查询一律走页面在用的那条通路。这类约束来自实测而不是设计偏好。
5. 全量留痕，可回查可评测
系统内有一处集中的 AI 运维视图，管理员能查到的是这些：
| 能力 | 说明 |
|---|---|
| 调用审计 | 每次 AI 调用的场景、状态、耗时、用到的工具与结果，逐条落表 |
| 分页回查与统计 | 按场景、按状态筛，看采纳率与驳回率 |
| 生效清单 | 当前生效的画像、工具目录与写策略表，输出顺序稳定可对比 |
| 自检断言 | fail-closed 等机制是否仍然成立，随版本回归 |
| 场景评测 | 典型问题跑评测集，看改动后回答质量有没有退化 |
被拒率监控：产品持续统计每个写工具提案的被拒率，超阈值会给该工具打上降级标记，随即被写策略拒绝注册。也就是说，一个老是提错方案的 AI 能力会被自动摘掉，而不是继续留着消耗人的信任。
6. 权限靠结构，不靠话术
对外查货画像（拼箱客服、货代客服、员工自助）挂的工具组里结构上就没有成本、费率、他人数据取数。隔离强度取决于"组里有没有"，而不是提示词写得多严。