当AI工具能快速生成文章，真正的挑战在于如何确保内容完整、事实一致。作者分享了一套content-publishing-sop工作流，从完整对话中提取关键决策，生成母稿后适配多平台，并坚持发布后从读者视角检查。这套方法避免了“只记住最后答案”的陷阱，让复杂经验真正可复用。
我现在已经不太会对 Codex 说：“把刚才的内容总结成一篇文章。”
Codex 通常几分钟就能给我一篇结构完整的稿子。麻烦在后面：那篇稿子很可能只记住了最后的答案。
我为什么改方案，哪些做法试过但没有采用，一张图片对应的是哪一版内容，视频有没有配音，读者最后能不能拿到完整提示词，这些信息都散在几十轮对话、截图和文件里。“总结一下”很难把它们重新接起来。
所以后来我做了一个 content-publishing-sop Skill。我想补上的，是从读取对话到公开检查的整段工作流程。
我把整段对话交给它这套 Skill 的起点，来自我改造 Browser Use 的一次真实对话。
最初的问题很小：Codex 能不能稳定打开一个闲鱼短链接。继续用下去以后，问题变成了专用 Chrome 怎么隔离、浏览器为什么总抢到前台、同一个会话要怎么使用多个标签页、标签占满以后能不能安全回收。
如果只看最终结果，这件事可以被压缩成一句话：给 Browser Use 做一个隔离浏览器。
但真正值得分享的恰好是中间那些变化。为什么不能直接接管日常 Chrome？为什么后台运行不等于把窗口藏起来？为什么资源满了以后，宁可让新任务失败，也不能随便清掉仍在使用的页面？
这些判断决定了最终方案，也决定了一篇文章有没有复用价值。
因此，我不再让 AI 根据最后几轮聊天自由发挥。我把完整对话交给 Skill，让它先恢复最初需求、发现的问题、尝试过的办法、我的反馈、最后选择和实际检查结果，再判断哪些变化应该进入文章。
我不希望它把聊天记录按时间抄一遍。讨论过程必须完整，但文章仍然需要一个中心判断。对 Browser Use 来说，这个判断是：浏览器 Agent 能打开网页只是起点，真正影响使用体验的是权限、打扰、可观察性和异常处理。
同一段事实，不应该复制成六篇相同的文章以前做多平台内容，我最容易犯的错误是先写一篇长文，再删成小红书，改成口播稿，最后给每个平台换一个标题。
这样很快，但读起来总像同一篇文章的不同长度。
我后来给 Skill 定了一条规则：事实只能有一套，表达必须重新组织。
人人都是产品经理更适合讲为什么做、我怎么判断和方案之间的取舍；知乎可以把论证和边界展开；简书要让命令和步骤更容易复现；小红书需要重新安排短段落和图片；抖音、B 站则要重新考虑口播、字幕和画面。
这里最容易混淆的是“平台适配”和“改写事实”。标题、开头和结构可以不同，但用过什么工具、做过哪些修改、测试结果是什么、还有哪些限制，不能因为平台不同就跟着变化。
所以 Skill 会先生成一份母稿，再从同一组事实制作平台稿、图片和视频。生成顺序很重要：先把事实固定住，再分别回答不同平台的读者为什么要继续看。
写完文案，我先检查内容有没有交齐有一段时间，我把很多精力花在文章语气上。后来几次返工让我改变了判断：比正文不好看更麻烦的，是内容看起来做完了，实际却没有交齐。
最典型的是完整提示词。
文章里写着“完整提示词见文件”，但那个文件只在我的电脑上，对读者没有任何意义。提示词太长时，把它拆成十几张图片，虽然形式上完整，阅读体验又很差。
现在的处理方式是先看内容本身。如果提示词短，就直接放在正文或一两张图片里；如果提示词很长，而且项目原本就有公开仓库，就使用能直接打开具体文件的链接。没有现成项目时，不会为了发一篇经验文章临时创建 GitHub 仓库。
图片和视频也一样。图片文件可能还属于上一篇文章；时间线虽然有配音，导出的 MP4 后半段仍可能没有声音。
所以在发布前，Skill 会把正文、图片、视频、完整提示词和目标平台放在一起检查。它要确认讨论中的关键变化没有漏，图片对应当前版本，视频没有长空白或缺音轨，公开链接不是某台电脑上的本地路径。
我看完最终内容说可以，才进入发布。
这是我在整套流程里保留得最坚决的一条判断。
平台提示“提交成功”，只能证明内容已经交到平台。它可能还在审核，也可能没有通过。即使文章已经有了公开地址，图片、正文或提示词链接仍可能缺失。
因此，发布动作之后还有一次读者视角检查。能打开公开页面，才检查标题、正文、图片和提示词入口；仍在审核，就如实记录审核中；审核没有通过，就记录失败，不把后台成功当作文章已经发布。
这听起来比“让 Agent 自动点发布”麻烦，但我认为这才是自动化最需要解决的地方。按钮可以很快点完，状态一旦记错，后面所有补发、重试和数据统计都会跟着错。
登录、验证码和平台协议也没有被包装成全自动。遇到账号授权、站外同步、删除或覆盖旧内容时，Skill 会停下来单独询问。能自动完成的部分尽量自动，涉及账号和公开发布的边界则保留人的决定。
这个 Skill 适合什么情况如果只是临时写一条短文，直接让 AI 生成可能更省事。
我做这套 Skill，是因为自己的内容经常来自一段已经发生过的长对话：需求改过几轮，有真实文件和测试结果，要同时制作长文、图片或视频，还要发布到多个平台。我并不缺稿子，真正让我返工的是过程、媒体和提示词互相对不上。
使用时，我会在事情已经做完、方案已经确定以后告诉 Codex：
使用 $content-publishing-sop，把我们这次的完整讨论整理成文章，
配好图片和视频，发布到人人、知乎、小红书、抖音和 B 站。
如果仍在原会话里，它可以直接读取前文。换了会话、电脑或 IDE，就把聊天导出和内容项目一起交给它。Codex、Claude Code、Cursor、Windsurf 都可以通过同一套文件和命令继续处理，不需要依赖上一段聊天的记忆。
项目地址：
https://github.com/372790111z-wq/content-publishing-sop
安装前可以先克隆仓库并检查当前电脑具备哪些能力：
git clone https://github.com/372790111z-wq/content-publishing-sop.git
cd content-publishing-sop
python3 tools/content_publishing.py doctor –deep
完整的一键执行提示词放在下面这个公开文件里，可以直接查看和复制：
https://github.com/372790111z-wq/content-publishing-sop/blob/main/EXECUTE-PROMPT.md
它不会保证每个平台一定通过审核，也不会绕过登录和验证码。它负责把一段复杂对话整理成可检查、可继续、可公开验证的内容，避免只留下那篇看起来已经完成的文章。
我现在用一个很实际的标准判断 AI 内容工具是否可用：读者最后拿到的东西，是否仍然和讨论结果一致。至于一分钟能不能写完，反而没那么重要。
本文由 @弗洛伊德 原创发布于人人都是产品经理。未经作者许可，禁止转载
翔云优配配资提示：文章来自网络，不代表本站观点。
