UFound
先把发布变成状态
一篇文章写完以后，离发布还有一段路。来源要核，图片要重做，四种语言要审，标题和摘要要跟正文对得上，构建以后还要确认链接、站点地图和移动端。小团队喜欢把这些事放在脑子里，平时觉得灵活，赶时间时就开始漏项。像老板临时催一份方案，大家都记得要交，却没人知道最终版到底在哪个群里。这套 SOP 不负责把普通选题包装得更漂亮，它只负责让一篇已经值得发布的内容稳稳上线，并且随时能回答现在走到哪一步、谁在负责、为什么还不能发。
研究阶段先去重
开始前先建一张内容卡，至少写清栏目、读者、文章要回答的问题、明确不做什么、负责人和计划日期。来源表记录 URL、作者、时间、核验日期和证据等级。官方文档、仓库实现与可验证数据优先，创作者自述和转发只做线索。研究时先合并同源内容，同一个项目被十个账号转发，不能算十份证据。把事实分成已确认、第三方自述和待测试三栏，写作语气跟着证据走...已确认能力可以陈述，公开演示写成对方展示了什么，待测试就把验证方法写出来。
正文要经得住反向检查
正文先钉住一个问题。教程需要前置条件、实际步骤、检查点和失败处理；观察类文章需要现象、原因、判断与可行路径。每段承载一个完整逻辑，不要一句一段，也别拆成十几个粗体小标题。初稿完成后做两次反向检查：先删掉标题，只读正文，看能不能说出文章到底在回答什么；再只看标题和摘要，检查它们有没有承诺正文给不出的结果。价格、模型版本、平台规则和 API 限额必须带核验日期，动态数字没有日期就先删掉。
图片、SEO 和四语一起验收
图片要先看内容一致性，再看美观。流程教程就用流程关系，工具文章说明输入和输出，不直接搬来源原图，也不把网址、仓库地址或水印塞进画面。每篇至少有一张 1600×1200 封面和具体的 imageAlt。SEO 从稳定 slug 开始，只用小写字母、数字与连字符；标题、摘要、H1 和正文说同一件事。四语版本分别审标题、正文、替代文本和服务边界，不能把机器翻译直接标成已发布。canonical、hreflang、Article 数据、站点地图和图片 URL 要作为一组检查，而不是分散到最后碰运气。
发布前做一次真实演练
进入 review 后先本地构建，再用真实页面检查。脚本负责卡片数量、链接、图片、重复正文、canonical、hreflang 与站点地图，人负责看 375、768、1440 三档排版、标题换行、图片裁切、目录和口吻。发布包必须有唯一版本号，部署前备份，静态目录切换后再做线上 smoke。为了验证 SOP 不是纸上流程，可以故意放一个不存在的图片路径、重复 slug 和失效来源，看检查能不能在上线前拦下来。如果必须靠某个人记得哪里会坏，这个规则就还没有进入系统。
让后台字段替人记规则
内容卡不是一张只有标题和正文的表。最少还要保存 type、slug、status、tags、cover、sourceRefs、datePublished、dateModified，以及四种语言各自的标题、摘要、正文、SEO、替代文本和状态。type 决定前台栏目，slug 决定稳定 URL，status 表示整篇内容走到哪一步，locales 则告诉你哪种语言真的过审。后台点已发布不等于公开站已经上线，静态构建、部署、线上检查是另一段有证据的流程。字段越明确，团队越不需要靠聊天记录猜最终版本。
把发布节奏固定下来
日常运营可以把研究、制作和发布分开排。研究池持续收材料和去重，制作中的文章限制数量，避免同时开十篇都停在半成品；进入 review 才分配配图、多语言和上线检查。每周固定一次链接复查和动态事实复核，每月抽查旧文中的价格、模型名、平台规则与失效来源。教程实质更新时改 dateModified，并写清改了什么；只是标点和错字，不要把它包装成一次大更新。稳定节奏能减少临时催稿，也让读者知道页面是否仍然可信。
上线以后再看一次真实阅读
发布后 24 小时内做一次短复查：从首页、栏目、搜索和站点地图分别进入文章，查看图片、目录、来源和语言切换；再从手机网络打开，确认首屏没有因为大图变得迟钝。读者反馈如果指出看不懂的步骤，先判断是正文缺条件还是界面缺提示，不要只在评论里补充。把有效反馈写回文章和发布规范，下一篇内容才能真正少走弯路。
失败以后回到安全版本
出了问题先判断影响范围。单篇事实或图片错误，恢复该内容上一版并重新构建；多语言路由或构建整体失败，切回上一份完整发布包。不要直接删除目录留下断链，也不要恢复整个业务数据卷去覆盖新订单或订阅。回滚后把状态退回 research、writing 或 review，记录原因、修复项和重新发布条件。最后再补一条防止复发的规则，例如来源失效检查、密钥扫描或图片授权字段...这一步做完，事故才真正变成系统资产。