这几天，我们一直在把对话写文章这件事往系统里收。候选池、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_codex_images.py 收集。
用 apply_codex_images.py 生成 codex-images 版本。
再跑 preview、quality、push-draft。
这一步本质上不是为了配图，而是在修正工具边界。
临场聪明不重要。标准入口更重要。
因为临场聪明解决的是这一次能不能过。标准入口解决的是下一次能不能重复。
为什么不能让工具静默降级
还有一个必须说清楚的原则。工具不能静默降级。
所谓静默降级，就是标准流程失败以后，不告诉用户真实问题，自动换一个看起来能跑通的方法。比如 Codex 作图失败，就改用普通卡片图。prompt 生成失败，就写一个短 prompt。草稿推送失败，就只生成本地预览但说已经完成。
这种问题很危险。
因为用户看到的是结果完成，系统内部却已经偏离流程。
说真的，自动化系统最怕的不是报错，而是悄悄绕路。报错至少让人知道哪里坏了。悄悄绕路会让人误以为系统可靠，直到后面出现更大的混乱。
所以这次我们把规则写得很硬。
对话深挖文章必须 Codex 配图。
Codex 失败就停止。
不允许手工伪造 manifest。
不允许用本地兜底图冒充正式配图。
不允许 agent 自己绕开标准入口。
只有用户明确要求非 Codex 配图，才可以改变策略。
这不是保守。恰恰相反，这是为了让自动化长期可用。
你懂吧，真正可靠的工具，不是永远不失败，而是失败时不装作成功。
AI 同事也要守岗位
这篇文章说的是工具边界，其实也在说 AI 同事的岗位边界。
AI 同事参与工作，不代表它要一口气把所有事全做完。它应该先判断自己处在哪个流程段。
现在是扫描吗。
现在是 deep-dive tick 吗。
现在是写作吗。
现在是配图吗。
现在是质量门吗。
现在是推草稿吗。
每个阶段都有自己的证据。不是说一句「完成了」就算完成。
扫描要有候选池。
deep-dive 要有 cluster 报告。
写作要有文章文件。
配图要有 manifest 和 codex-images 稿。
预览要有本地预览和微信预览。
质量门要 pass。
推草稿要有 media_id。
这些证据连起来，才叫流程完成。
如果少了一段，就不能靠语言补齐。
这次沉淀下来的方法
这次我们真正沉淀的，不是一条命令，而是一种做系统的方式。
先把每个工具的职责写窄。
再把每个流程的出口写清楚。
再规定失败时不能静默降级。
再要求每一步留下证据。
最后让 AI 同事按岗位协作，而不是自由发挥。
你想啊，如果每个工具都只做该做的事，系统反而更能自动化。因为边界清楚以后，工具之间可以安全衔接。
候选池不会擅自写文章。
写作计划不会绕过脱敏判断。
配图入口不会乱用非 Codex 图片。
质量门不会被口头承诺替代。
草稿箱不会被重复标题冲乱。
这样系统看起来慢一点，但长期更快。
因为少了返工，少了重复，少了状态不一致，也少了「到底谁做了什么」的追问。
最后
让工具只做该做的事，不是限制工具能力。
它是在保护流程。
工具可以强，但边界要清楚。AI 同事可以主动，但岗位要明确。流程可以自动化，但每一步都要有证据。失败可以发生，但不能静默绕路。
这就是我们这次互动里清出来的方向。
不是让一个工具变得无所不能，而是让每个工具在自己的位置上可靠地工作。
当扫描只负责扫描，候选池只负责判断，写作只负责写作，Codex 只负责配图，质量门只负责拦截，草稿箱只负责推送，整个系统才真正开始稳定。
讲真，这比多写几篇文章更重要。
因为文章只是结果。边界清楚，后面的每一篇文章都会更稳。