AI 写的营销文案，怎样才能先证明每个承诺都是真的？Omni Verify 的发布门禁实践
让 AI Agent 批量写推广文案，速度很快；但如果文案里的功能、链接参数或产品承诺不准确，错误也会被批量放大。更麻烦的是，这类错误未必会让程序报错：按钮仍能打开，帖子也能发布，只有归因数据或用户预期悄悄偏离。
Omni Verify 是一个开源实验项目，展示了如何把“先验证、再发布”做成营销工作流的门禁。它围绕 Kane CLI 的真实浏览器检查构建：Agent 先起草内容，再将文案中的说法转成检查项；检查不通过时，依据浏览器实际看到的页面修正文案；只有通过验证的特定版本才允许进入发布确认。项目 README 还展示了发布后的复核流程，用于发现产品更新后旧帖子仍在承诺过时功能的问题。
它验证的不是“页面能打开”
在作者提供的案例中，官网 App Store 按钮会使用站点自身的 ct 追踪参数。帖子虽然带有活动参数，实际按钮链接却可能覆盖它。单看 HTTP 成功或点击成功，无法发现归因标签已经改变。Omni Verify 的思路是让浏览器读取最终按钮链接，再把观察到的事实与活动承诺比较。
另一类问题发生在产品迭代之后：旧帖继续引流，却描述着已经改变的功能。项目对历史帖子重新核验，将说法按结果分为通过、失败或无法确认；失败项可以提出改写或归档建议。作者特别说明，历史审核本身不会自动编辑、删除或发布 Threads 内容，这一步仍留给人决定。
发布门禁如何避免检查与发布脱节
仅仅“检查过一次”还不够。如果检查通过后文案或链接又被改动，先前结果就不再适用。该项目把验证结果绑定到活动版本（文案、链接和声明的哈希），并要求最新检查为通过状态，发布按钮才可用；服务端确认时还会再次检查门禁和确认的版本。这种设计把验证结论绑定到待发布对象，而不是绑定到一个模糊的“曾经通过”。
仓库提供的本地启动方式是：
bun install && bun run dev
默认发布模式是 dry-run；README 指出，真正发布需在 .env 设置 PUBLISH_MODE=live 并重启。新草稿需要 OpenAI API 凭证，新执行 Kane 检查需要相应 CLI 登录。不要把示例项目的真实发布配置照搬到生产环境；应先确认账号、目标平台和人工确认流程。
可以借鉴的工程边界
这套模式适合把生成式内容接入任何有外部影响的工作流：广告文案、产品更新公告、销售邮件，甚至自动生成的操作说明。关键不是要求模型“再自查一次”，而是让外部验证器依据实际页面或系统状态检查可观察的断言，并把结果与准确的内容版本关联。
可以从小处落地：先挑出会造成实际损失的声明，例如价格、功能可用性、跳转目标和追踪参数；将它们拆成可验证断言；无法访问或证据不足时明确标记为“未确认”，而不是默认通过；最后保留人工确认和审计记录。尤其要区分“验证失败”与“验证器没有证据”，否则网络故障可能被错误地当成内容正确。
Omni Verify 的价值不在于证明 AI 永远不会写错，而在于展示一条更可靠的控制链：生成内容、检查事实、针对失败修复、绑定版本、再由人确认发布。对会影响客户决策或业务指标的自动化流程而言，这比单纯增加提示词中的自我审查要求更可操作。