这几天，我们一直在把对话写文章这件事往系统里收。候选池、deep-dive tick、cluster 报告、博客发布、公众号草稿、Codex 配图，都已经不是单独动作，而是在进入一条更完整的流程。
这里面有一个堵点很重要：工具到底应该做到哪一步。如果边界不清，系统很快会乱。一个工具本来只该采集候选，却顺手写了文章；一个入口本来只该接受主题，却自动触发发布；一个配图流程本来只该生成 prompt，却在失败后用了兜底图。表面看工具很主动，实际是在越界。
工具要有边界，流程要有出口，AI 同事要知道自己做哪一段，不该把所有事情一口气做完。这个判断看起来有点“慢”，但它会让后面的自动化更稳，因为每一步都有自己的责任，也有自己的停止条件。
最开始堵在自动化边界
最开始，我们讨论的是对话候选。系统可以扫描对话，把可能写成文章的主题找出来。这个能力很有用，因为对话量太大，靠人回忆一定会漏。普通扫描负责接住新增内容，深挖模式负责把主题聚类，再给出哪些能写、哪些要脱敏、哪些要回看来源。
但这里马上出现一个问题：扫描出候选以后，要不要直接写。如果工具一看到候选就自动写，听起来很省事，但风险很高。因为候选只是输入，不是结论。它可能重复，可能太浅，可能有隐私，可能缺来源，也可能不适合现在发布。
所以我们后来把边界拆清楚。扫描工具只负责发现候选；候选池负责保存、分级、聚类和给出建议；写作计划负责决定什么时候写；写作入口负责生成正文；配图入口负责走 Codex 流程；质量门负责判断能不能进入草稿箱；草稿箱入口负责真正推送。这几个动作不能混成一个“自动帮我全做完”。
自动化最危险的地方，不是它做不了，而是它做多了。做不了会暴露问题，做多了反而会把问题藏起来。一个系统如果总是悄悄替人跨过判断层，短期看省时间，长期看会让人不知道问题到底从哪一步开始。
accept 不是 write
这次一个很关键的设计，是 accept 不能自动触发 write。accept 的意思，是我认可这个候选可以进入写作计划。它不是说这篇文章现在就要被写出来，更不是说马上配图、质检、推草稿。
这个区别看起来小，其实很重要。如果 accept 直接触发 write，候选池就不再是判断层，而变成了执行按钮。人还没确认写作角度，系统就开始生成正文；人还没确认账号和平台，系统就开始走流程；人还没确认是否脱敏，文章可能已经产出了。
所以 accept 只能做一件事：把候选纳入计划。写不写、何时写、写到哪个账号、是长文还是小绿书、是否需要先脱敏，都应该由后面的写作计划决定。这种边界一旦清楚，系统会稳很多。因为每个入口只承担一层责任，出了问题，也容易知道是哪一层的问题。
候选不准，是扫描层问题；重复太多，是聚类层问题；文章太浅，是写作层问题；图片不合规，是配图层问题；质量不过，是质量门问题；草稿重复，是发布出口问题。如果所有动作都挤在一个按钮里，问题就会变成一团，最后只能靠人重新梳理。
工具越强，越要限制动作
有意思的是，工具越强，越需要限制动作。弱工具做不了太多，越界风险反而小。强工具可以扫描、归纳、写作、配图、发布，如果没有边界，它就会很自然地把所有动作串起来。表面看，这是效率；长期看，这是失控。
比如对话深挖文章必须走 Codex 配图。这个要求不是可选项。如果某个工具发现 Codex prompt 生成失败，就自动用兜底图补上，表面看流程完成了，实际质量门已经被绕开。再比如多台电脑都能采集对话，这个能力本身很好，但如果每台电脑各自写、各自推、各自同步，系统就会出现重复草稿和状态冲突。
所以我们这次反复做的一件事，就是把“能做”和“该做”分开。能扫描，不代表该写；能写，不代表该推草稿；能配图，不代表可以绕过 Codex；能同步，不代表可以覆盖别人的改动；能自动运行，不代表不需要质量门。
这也是 AI 同事协作里很核心的一点。AI 同事不是越主动越好，而是越清楚边界越好。真正可靠的主动，不是替人把所有动作都做完，而是在该停的时候停，在该问的时候问，在该留下证据的时候留下证据。
标准入口比临场聪明更重要
这次我们还碰到一个具体问题。配图流程里，先生成了 fallback prompt。后来我们重新校准，必须严格按照 jianfei-wechat 流程来生成 prompt 和用 Codex 作图。这个提醒很关键，因为 fallback prompt 也能出图，图也可能看起来不错，但它不是标准入口生成的 prompt。
它没有走 jianfei-cards 的 prompts-only，没有形成标准 prompt 格式，也没有严格经过 snapshot、Codex 作图、collect、apply 这条链路。所以正确动作不是继续用这批图，而是回到标准流程：重新跑 prompts-only，确认 prompt 里有整体风格说明和本张图内容，用 Codex 当前会话按 prompt 出图，再用 collect 和 apply 生成 codex-images 版本。
这一步本质上不是为了配图，而是在修正工具边界。临场聪明解决的是这一次能不能过，标准入口解决的是下一次能不能重复。如果一个系统每次失败都靠临场绕路，它表面上很灵活，实际上很难沉淀。因为下次遇到同类问题，系统记住的不是标准流程，而是某一次临时处理。
流程里的入口越标准，后面的证据越清楚。谁生成了 prompt，谁生成了图，图放在哪里，哪篇正文引用了它，质量门是否通过，这些都能追溯。能追溯，才有复盘；能复盘，才有改进。
不能让工具静默降级
还有一个必须说清楚的原则：工具不能静默降级。所谓静默降级，就是标准流程失败以后，不告诉用户真实问题，自动换一个看起来能跑通的方法。比如 Codex 作图失败，就改用普通卡片图；prompt 生成失败，就写一个短 prompt；草稿推送失败，就只生成本地预览但说已经完成。
这种问题很危险。用户看到的是结果完成，系统内部却已经偏离流程。自动化系统最怕的不是报错，而是悄悄绕路。报错至少让人知道哪里坏了，悄悄绕路会让人误以为系统可靠，直到后面出现更大的混乱。
所以这次我们把规则写得很硬：对话深挖文章必须 Codex 配图，Codex 失败就停止，不允许手工伪造 manifest，不允许用本地兜底图冒充正式配图，不允许 agent 自己绕开标准入口。只有用户明确要求非 Codex 配图，才可以改变策略。
这不是保守，而是为了让自动化长期可用。真正可靠的工具，不是永远不失败，而是失败时不装作成功。失败暴露出来，系统还有修复机会；失败被盖住，后面每一步都可能建立在错误状态上。
AI 同事也要守岗位
这篇文章说的是工具边界，其实也在说 AI 同事的岗位边界。AI 同事参与工作，不代表它要一口气把所有事全做完。它应该先判断自己处在哪个流程段：现在是扫描，还是 deep-dive tick；现在是写作，还是配图；现在是质量门，还是推草稿。
每个阶段都有自己的证据，不是说一句“完成了”就算完成。扫描要有候选池，deep-dive 要有 cluster 报告，写作要有文章文件，配图要有 manifest 和 codex-images 稿，预览要有本地预览和微信预览，质量门要 pass，推草稿要有 media_id。证据连起来，才叫流程完成。
如果少了一段，就不能靠语言补齐。这一点对多 Agent 协作尤其重要。一个 Agent 说完成，另一个 Agent 接着跑，如果前面没有证据，后面就只能靠猜。猜得越多，系统越不稳。岗位边界不是限制协作，而是让协作可以接力。
最后沉淀下来的方法其实很朴素：把每个工具的职责写窄，把每个流程的出口写清楚，规定失败时不能静默降级，要求每一步留下证据，再让 AI 同事按岗位协作，而不是自由发挥。这样系统看起来慢一点，但长期更快，因为少了返工，少了重复，少了状态不一致。
这个边界还有一个好处：它能减少“完成感幻觉”。很多工具最大的问题，不是没有输出，而是太容易给人一种已经完成的感觉。扫描有结果，像完成了；文章生成了，像完成了；图片出来了，像完成了；部署成功了，像完成了。但真正的完成，必须看它是不是走到了正确出口。没有质量门，没有证据，没有可追踪状态，完成感就只是界面上的一个提示。
我后来越来越觉得，工具边界不是技术洁癖，而是协作礼貌。一个工具不越界，后面的工具才知道自己接到的是什么。一个 AI 同事不越界，另一个 AI 同事才不会在错误状态上继续加工。人也一样，看到系统停在某一步，就知道现在该判断、该授权、该补材料，还是该重跑标准入口。
所以流程里最重要的不是“能不能一键到底”，而是“每一键到底做了什么”。如果每个入口都能讲清楚自己读了什么、写了什么、留下什么证据、下一步交给谁，这套系统就算暂时慢一点，也会越来越稳。
很多时候，我们以为自动化要解决的是“少点几次按钮”。但真正难的不是按钮数量，而是每个按钮背后的责任边界。如果一个按钮既扫描、又判断、又写作、又配图、又发布，那么它一旦出错，我们很难知道该修哪里。相反，如果每个入口只做一件事，系统虽然多了几个步骤，但每个步骤都能被检查。
这也是我后来更愿意接受“慢一点”的原因。慢不是目标，清楚才是目标。清楚以后，后面才会快。因为下一次再跑同类任务，不需要重新解释为什么不能绕过 Codex，不需要重新讨论为什么 accept 不是 write，也不需要重新判断失败后能不能静默降级。
边界清楚以后，人的判断也会轻松很多。看到扫描结果，就知道先看候选；看到候选通过，就知道进入计划；看到计划执行，就知道检查正文；看到正文完成，就知道走配图和质量门。流程不是为了增加规矩，而是为了减少每次重新判断的成本。
最后
让工具只做该做的事，不是限制工具能力，而是在保护流程。工具可以强，但边界要清楚。AI 同事可以主动，但岗位要明确。流程可以自动化，但每一步都要有证据。失败可以发生，但不能静默绕路。
不是让一个工具变得无所不能，而是让每个工具在自己的位置上可靠地工作。当扫描只负责扫描，候选池只负责判断，写作只负责写作，Codex 只负责配图，质量门只负责拦截，草稿箱只负责推送，整个系统才真正开始稳定。
这比多写几篇文章更重要。因为文章只是结果，边界清楚，后面的每一篇文章都会更稳。