字典记录事实，不替平台“翻译原因”
社媒任务失败代码字典不是把所有失败塞进几个模糊标签，而是为每一种可观察提示保存原文、来源、发生阶段、影响范围、证据位置、已验证处置和禁止动作。平台未给出明确原因时，应标为未知或待核验，而不是为了报表完整而猜测。
例如，同样显示“发布未完成”，一个账号可能在媒体上传阶段中断，另一个可能在提交后无法确认页面。两者的操作边界不同，不能共享同一个“重试”按钮。
把字典条目拆成“原始信号”和“内部判断”
原始信号应尽量原样保存：平台名称、提示文本、时间、请求或任务标识、出现阶段和截图或页面证据。内部判断则写明当前假设、已排除条件和下一步。二者分栏，能让后来的人区分“平台说了什么”和“团队当时怎么理解”。
如果平台文本为空或系统只返回失败状态，条目应明确写“原因未提供”。这不是低质量记录，反而能防止团队把网络、权限或内容原因混为事实。发生混合结果时，先参考批量发布部分失败排查按共同条件分组。
| 字段 | 可记录内容 | 不应写成 |
|---|---|---|
| 原始信号 | 平台提示原文、任务时间、发生阶段 | 未证实的根因 |
| 内部分类 | 素材、权限、状态未知等工作标签 | 伪造的平台代码 |
| 影响范围 | 已确认账号和任务数 | 没有证据的全局影响 |
| 安全处置 | 暂停、核对、单账号验证 | 无条件全量重试 |
| 复核结论 | 验证时间、负责人和结果 | “已解决”但无证据 |
分级是为了决定谁要介入
可按影响而非情绪设置分级：仅 1 个低风险任务且提示明确的，交给执行人按条目处理；影响客户交付、关键账号或多个账号的，转由事件负责人判断暂停；涉及所有权、敏感资料或平台申诉的，必须由授权联系人参与。这里没有适用于所有团队的数量阈值。
自动重试尤其需要谨慎。短暂且有明确证据的连接问题，可能适合有限、可记录的重试；权限变化、内容拒绝、未知状态和多账号聚集错误应先人工判断。自动重试是效率还是风险解释了为什么“能再试一次”不等于“应该全量再试”。
让字典随着复盘变得更可靠
每次事件结束后，新增条目或更新已有条目时都应附上日期和证据来源。若一个内部分类后来被证明错误，要保留修订说明，而不是悄悄改掉历史。这样字典会积累经过验证的处置，而不是累积传言。
例如，某媒体格式提示在两个不同账号上用同一修正素材验证成功，才可以把“先验证素材”写入建议。即便如此，也应标注验证场景，而非宣称适用于所有平台、所有格式和所有时间。
TikTok 的 Business Help Center和 Meta 的 Business Help Center是核验当前平台说明的入口。内部字典应链接到实际查阅日期；它不能替代官方支持、政策或账号所有者的决定。
好字典会降低不确定性，不会假装消灭不确定性
Ainnc 运营研究组认为，错误字典的价值不在于把每次失败自动归类，而在于保存区分条件：失败发生在哪一步、哪些账号受影响、哪些变量没有改变、什么修复经过了验证。例如 2 次相同提示却发生在不同阶段，就不应先合并成一个原因。未知原因被诚实保留，才有机会在下一次形成可靠模式。
Google 的 Site Reliability Engineering Workbook讨论了从事件中形成可学习记录的价值。社媒任务不是软件服务，但可追溯的事实、行动和结果同样能避免团队重复做没有证据的修复。
字典的最后一栏应当是“下一次先看什么”
一条合格条目应让新成员在 1 分钟内找到首个安全动作：停什么、看什么、向谁升级、什么情况下可以继续。若条目只写“失败，联系技术”，它仍然把判断成本推回给现场人员。
把字典与任务日志、账号分组和素材版本关联后，复盘就不再是统计失败次数，而是把一次真实事件转成下一次更稳妥的起点。
常见问题
平台没有返回错误代码，还能建立字典吗？
可以。保留提示原文、发生阶段和证据链接，再用内部分类标记未知原因；不要把推测包装成平台正式错误代码。
错误代码字典是否等于自动重试规则？
不等于。字典先描述证据与处置边界，只有经过验证、风险较低的错误才可能配置有限重试，其余仍需要人工判断。