端侧 AI · 部署
离线 AI 结果为什么需要用户复核
分开 source、生成结果、不确定性、编辑和最终批准。
主查询：离线 AI 结果复核 · 核验：2026-09-16 · 事实卡：PRIVACY-01, BENCHMARK-01
先给结论
离线 AI 复核必须把原始来源、AI 生成结果、不确定性提示、人类编辑与最终批准严格分开记录。这一边界确保复核只针对本地可追溯的素材进行判断，任何向外延伸的推断都越过了既有事实卡的范围，结论不能来自模型在原始材料之外的联想，必须由用户在看到全部原始信息后自行决定。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 复核状态 schema
- 接受拒绝 fixture
- 编辑导出记录
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
为支撑这样的复核流程，需要在本地维护一份结构化的复核状态 schema，分别标识已接受、已拒绝与待编辑三类条目；针对典型接受与拒绝场景准备对应 fixture，以便逐条对照原始来源与生成结果；每次编辑都导出独立记录，写明改动位置、改动内容与操作者，便于事后回放与差异比对。这样做的目的是让复核过程本身可复核，而不是只留下一个最终结论。
- 先写任务和最大输入
- 确定运行时与 artifact 格式
- 固定 revision 与发布清单
- 做最小可复现工程
- 在目标设备跑代表任务
- 记录失败、回退与清理
最容易写错的地方
- 覆盖原始内容
- 把生成等同批准
最危险的错误模式是编辑覆盖了原始来源内容，使后续检查无法再回到未改动的输入；另一类是把模型的生成直接视同人类批准，省掉了不确定性与边界 ID 的核对环节。任何最终发布结论都只能基于已落盘的记录，包括来源、生成、不确定性与编辑痕迹，不得以“看起来合理”为由跳过其中任何一环，更不能把模型输出当作已经过审。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。