一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 聊天、剪贴板、文件名和屏幕永远不应进入通用故障分析。大多数归因只需 release、错误码、阶段、候选类型和时间关系。
数据与模型只能在明确目的、最小输入和可重复评测下进入决策链。确定性规则负责权限和副作用，模型提供带证据与置信度的辅助结论，并允许安全拒答。
设计时必须回答的问题
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 客户端和服务端双重 allowlist，实体标识替换为单请求随机 token；供应商配置 no-training/短保留，响应只保存结构化 hypothesis 与证据引用。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“用 LLM 分析故障但不泄露用户载荷：本地提取、最小证据和保留期”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 先上传全日志再让模型“自行脱敏”已经发生泄露；固定匿名 ID 让供应商跨事件构建用户画像。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
用证据确认它真的可用
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 在所有禁止字段放唯一 canary 并触发分析，抓取实际出站 body、供应商审计和本地存储，证明仅允许字段出现且可按期删除。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 对日志和埋点做字段白名单检查，证明内容载荷、密钥、完整 IP 与用户可识别信息不会离开设备。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。