技术文章发布前，怎样核对事实

官方文档列出的输入限制，是可以查证的产品信息；某次测试出现的结果，是特定条件下的观察；建议先做小样再批量运行，则属于制作方法。三者可以写在同一篇文章中，但不要用同一种确定口吻表达。

比如“本次在某版本中导出了竖版文件”，不能直接改写成“所有套餐都支持竖版导出”。如果没有实际测试，就说明依据来自文档；如果是编辑提出的工作建议，也不必把它包装成行业统一规范。

价格、套餐权益、接口字段、输出规格和使用条款，应回到提供方的原始页面核对。记录查阅日期、对应版本和具体链接，优先指向能支持那句话的段落或文档页，而不是只链接网站首页。

可以建立一张简短的事实表：原句、依据、适用范围、处理结果。没有依据的“最佳”“零损失”“完全一致”等说法，先删去或改为有条件的描述。不同来源相互矛盾时，把差异查清再发布，不用数量更多的一方代替判断。

检查教程时，从读者拿到什么输入开始，一直看到应该出现什么结果。涉及命令，说明文件名怎样替换；涉及软件界面，注明版本或可能的名称差异；涉及导出，写清结果保存在什么位置、怎样验证。

例如文章让读者“检查帧率”，就应交代看的是哪个信息字段，以及它与项目要求怎样对应。如果输出包含多个视频流，还应提醒先确认目标流。能执行命令并不等于读者理解了结果，判断方法也是正文的一部分。

逐张检查配图：它是实际界面、制作示例，还是概念封面？封面可以帮助表达主题，但不能被当成软件操作结果。对照图要保持比较条件可理解，裁切范围、显示比例或调色差异可能影响读者判断。

示例数字应明确写“假设”或“演示计算”。没有测试记录，不写成“实测节省”；没有真实项目材料，不编造客户名称、制作周期和投放成绩。把这些边界说清，读者反而更容易判断内容是否适合自己的工作。

正式发布前，换一个阅读视角检查标题、摘要、正文与附件是否一致。特别留意标题是否夸大了正文的结论，以及旧截图、旧下载文件是否还在使用。只有正文更新，其他入口没改，错误仍可能继续传播。

文章页保留发布者、更新日期和联系方式。读者指出具体问题后，先复核依据，再决定更正、补充适用条件或暂时撤下受影响内容。对影响操作的修改，写一句清楚的更正说明，让已经读过旧版的人也能找到变化。