T2.04.5Versioned error taxonomy and message governance设计研究
同类错误的措辞需一致
别名: 错误分类法 · 原因码映射 · 跨渠道错误治理
概念解释
版本化错误分类与消息治理（versioned error taxonomy and message governance）把内部原因码映射为稳定的用户错误类，再为每类定义名称、数据状态、恢复策略、严重度和各渠道 message key。同一用户意义使用一致概念，不同后果不能为减少模板而合并。版本治理确保 UI、邮件、状态页、帮助与客服在规则变化时共同更新，并能处理未知或过期映射。
机制
实现层的原因码通常比用户概念更细或更粗：多个端点超时对用户可能都是暂时不可用，同一码在付款和草稿场景却可能对应不同状态。直接用码生成句子会制造漂移或错误恢复。taxonomy 先按用户可见 outcome、可恢复性、责任主体和风险分类，再把内部码映射进去；消息资产与恢复动作绑定同一版本，避免文案说“重试”而按钮已失效。未知映射必须安全降级，不能沿用过期授权或猜测类别。
怎么研究
收集跨渠道错误事件、消息、用户行动和支持结果，以用户状态与恢复路径聚类，再由工程、内容、支持和风险人员审查拆分/合并。用混淆矩阵检查同类是否得到一致名称、不同后果是否被误并，并按渠道和版本追踪自助恢复、重复失败与错误升级。taxonomy 变更需回放历史事件，验证新映射不会改变旧记录含义或让未知状态消失。
边界
一致不等于逐字相同：toast、邮件和客服话术可按空间与对话调整，但必须保留同一错误类、状态和恢复承诺。每种语言可自然表达，不需字面对齐。taxonomy 不是安全规则清单，也不应把敏感内部原因公开；公开消息只消费获准字段。一次性故障也要有 unknown 路径，但不必为每个底层异常建立用户类别。
怎么落地
- 为每个用户错误类记录 ID、定义、outcome、data/transaction state、recoverability、responsible actor、severity、safe disclosure、recovery action、owner、version 和 message keys。
- 维护原因码到用户类的多对一/条件映射，按渠道发布同一版本 bundle；CI 检查缺失、冲突、过期映射及恢复动作可用性。
- taxonomy 更新生成影响清单，协同修改 UI、通知、状态页、帮助、客服宏和分析；保留旧版本解释历史事件，不静默重写审计记录。
- 监控 unknown 率、跨渠道版本差和同类恢复差异；unknown 使用安全兜底与公开 reference ID，并进入分类审查队列。