解读内容纠错政策提案
解读文章可能出现多类错误：历史日期不对、牌位写错、产品说法缺乏支持，或转述改变了来源的含义。拟议纠错政策需要区分这些情况，让修正真正对准问题。
这是为 Mystilink 内容库和预备社区材料提出的草案，需要获批并有可执行流程，才会成为政策。它不设响应时间保证，也不声称已有特定报告渠道。
确定哪些情况需要纠正
事实错误，是与相关证据冲突的说法。缺少限定，导致表述误导时，也可能需要纠正。解读偏好不同，可能需要讨论或补充另一种解释，但不一定意味着原解读存在事实错误。
举一个虚构例子：文章正确列出三张牌的抽牌顺序，讨论时却把最后一张当成开头位置。这是可以核查的不符。编辑应同时修正牌位标签，以及依赖错误顺序的推理。
产品文章也可能把仓库里找到的代码，写成每位用户都能使用的功能。纠正时，应把说法缩回实际检查过的证据范围，并指出还需做哪些发布核查。不要用另一个关于部署状态的猜测，替代原来的无依据说法。
接收有足够背景的报告
拟议报告流程会请报告者提供文章或帖子、存在争议的段落，以及怀疑有误的原因。出处引用或一个小型重现例子可能有帮助，但读者提出疑问，不应以提交私人信息为前提。
涉及计算问题时，尽量请对方提供虚构输入；涉及隐私问题时，不要让报告者把已泄露信息再贴到公开场合。在公布敏感报告提交说明之前，运营团队需要先准备合适的接收渠道。
确认收到时，应准确说明报告状态。有人提出疑问，不代表疑问已被证实；要求补充证据，也不应变成对疑问的否定。任何时间承诺，都必须来自已获批准、且有人负责落实的流程。
核查说法及其关联内容
编辑应保留原段落，检查所引证据。引用失效或不支持说法时，应寻找合适的原始来源，查看相关内容。尚未解决的出处问题要记下来，不要用听起来合理的细节填空。
沿着文章其余部分，追查错误的影响。输入错误可能影响图示、解释和结论；产品状态错误可能同时出现在教程、预览摘要和社交媒体摘录中。团队能控制的所有受影响位置，都应修复；无法直接修改的副本，也应记录。
争议材料超出编辑能力时，应请另一位合格审阅者参与。这份草案并未给某个未明确的团队安上资质。采纳前，公司需要决定由谁审查专业历史、技术和语言问题。
让公开说明对应实际改动
不影响含义的拼写修正，通常可以作为常规编辑处理。输入、来源归属、产品可用性或结论发生变化时，则应给出可见的纠正说明，写清哪里错了、文字怎样改了。
针对那个虚构牌位错误，说明可以写：“早先版本把最后一张牌放在起始牌位讨论。现已修正牌位标签及受影响的解读。”措辞不应让人误以为，新解读已经获得超出实际检查范围的独立验证。
注明日期；发布系统支持时，也注明受影响版本。事实说法变了，就不要只写“为清晰起见作了更新”这类含糊说明。看过旧版的读者需要知道，自己的理解是否也应改变。
保留仍无定论的分歧
证据支持多种解读时，应说明分歧及各方依据。不能只因作者偏好某个流派或译本，就靠纠错流程强求解释统一。
读者反馈个人解读不合实际时，应在获得适当许可后保留其陈述。不要把反馈改写成隐藏洞见的证据。编辑可以缩小原说法、加入回应，或删除文章无法支持的判断。
团队若认为无须纠正，应内部记录原因，并按获批流程向报告者说明。即使底层事实经复核仍成立，文章也可能需要把话说得更清楚。
把纠正延伸到页面之外
实质纠正可能还需要同步到相关论坛帖、可下载文档、图片说明或已排期的社交媒体摘录。发布篇幅较大或内容较重要的材料时，应留一份简短副本清单，便于日后修复。
定期查看反复出现的错误。多次混淆版本，可能说明投稿表单需要增加版本字段；反复把源码实现与已发布功能混为一谈，则可能需要加强产品审阅环节。
采纳这份草案之前，要明确谁负责接收报告、作出编辑决定，以及更新副本。一项纠错政策能把读者引向具体负责人，并让他们看到实质错误得到准确说明和修复，才会有实际作用。