起因 #
今天群里有人问：文章在 Obsidian 里用 Markdown 写，想按文章类型加载不同风格的 CSS 排版，连带渲染效果和图片一起进公众号编辑器，有没有人跑通过？他没有公众号开发权限，之前的做法是把 Markdown 复制到第三方编辑器渲染再粘贴，流程繁琐，图片还要重贴。
我正好有现成方案：Agent 调排版工具（提取自开源项目 Raphael，30 个主题）渲染成内联样式 HTML，浏览器自动化存进公众号草稿箱，我在手机订阅号助手里点发送。
于是我建了个派单任务，验收标准里关键的一条：文档要面向「对方的 Agent 直接照做」，步骤可执行、命令具体。
第一次交付 #
Agent 很快完成了：通读我自己的发布技能文档，提炼出链路总览、依赖清单、五步可执行命令、主题定制方法、插图方案，还附了一段可以直接抄给群友 Agent 的交接提示词。验收标准 1-3 逐条自验通过，产出落点、工作区记录、滴答回填都按规范走完。
按我平时的习惯，到这就结束了。
那句反问 #
但这次是对外交付。我追问了一句：
对方的 Agent 按照这个工作流就完全 OK 了吗？也不需要什么我的技能或者其他的了吗？你最后再检查一下。
复查发现两个真实缺口：
- 排版工具对方拿不到。 文档里写的是「从 Raphael 仓库提取，或直接找我要打包好的目录」。但这个工具是我手工提取改造的——对方从原仓库拿不到现成可用的 CLI，「找我要」等于把关键一步悬空。
- 浏览器自动化工具缺安装方式。 只写了名字，没写
npm install -g agent-browser，也没写 Node 版本要求。
修复：把工具打成 21KB 的源码包（剔除 33MB 的 node_modules，依赖只有 markdown-it / highlight.js / jsdom 三个，对方 npm install 即可），补全安装命令，然后在干净目录从零解压、安装、跑了一次渲染验证——通过。
前后多花几分钟。没有那句反问，文档发出去对方大概率跑不起来。
对内和对外的两个标准 #
这种检查我在个人任务里很少做——嫌麻烦。给自己用的东西，断了就自己修，上下文都在我脑子里。
对外交付不同：断点出在对方手里。对方跑不起来，要么回来问，要么默默放弃，无论哪种交付都算失败。
以前做 AI 开发、和公司协作时是常识：API、文档、代码，保证自己测通再交给对方。到了 AI 帮自己干活，这个习惯反而一度丢了——AI 说「做完了」，就默认它真做完了。
更早的一次：夹在两拨 AI 中间做验收 #
这不是第一次。之前在公司做过一次 AI 应用开发，我是「中场」角色：上游给功能需求文档、API 接口、产品原型，我事先完全没接触过。第一步是用浏览器自动化把这些资料批量转成 AI 可读的格式，然后给 AI 找工具、派活，自己把住验收，最终把整个功能交付出去。全程流畅。
过程中查出的 bug 有两类：自己这边 AI 写的，改掉即可；另一类是对面交付团队平台上的 bug——下游同事也在用 AI 开发，接口对接没问题，但他们对代码了解不深、交付前没完全验收好，我在自己这头排查时把他们那边的两个 bug 翻了出来。
同样是 AI 干活，一边流畅、一边带 bug 出厂，差别不在 AI，在中间有没有人做检查。
另一个对比：那次开发里 AI 做的有些工作，我并不需要知道它具体怎么实现的——用了些代码质量工具和流程，细节不用懂，结果 OK 就行。「不需要知道 AI 怎么做的」和「不需要验收 AI 做的」是两回事：前者是分工，后者是放弃闸门。
一个判断 #
Agent 之间的交互不会把人干掉，但人的位置变了：从干活的，变成验收和闸门。
AI 第一次交付的「看起来完整」和「对方真能跑通」之间有差距。这个差距 AI 自己不一定意识得到——按它理解的验收标准它确实做完了，但「对方能不能用」这个标准，在交付发生之前只有人知道。
检查的成本是一句追问，不检查的成本是对方跑不起来、信任打折。过渡期人累一点：既放手让 AI 干，也保留看代码、做检查的能力，「古法编程」的基本功和正向学习摩擦不能省。这个闸门，目前只能人来当。
后续 #
排版工作流本身会另写一篇工具向的文章。本文关联产出：
- 交付文档（给群友）：
agent-hub/data/agents/main:4/deliverables/2026-08-31-公众号发布排版工作流-给群友.md - 随文档交付的工具包：
wechat-formatter.tar.gz