这几天，我们一直在做一件看起来很具体的事。把大量对话、文章候选、博客发布、公众号草稿、配图流程和多台电脑协作，整理成一个可以持续运转的内容系统。
表面看，这是「把对话写成文章」。
但真正做下来，我越来越明确，重点不是让 AI 同事替我写几篇文章。重点是我和 AI 同事在互动中，把一个个堵点拆开，把方向重新理顺，再把能重复执行的流程固定下来。
真正值得记录的，不是一个虚构故事，而是一套真实发生的工作方式。
这次最开始卡在数量
最开始的问题很直接。之前已经有几十篇对话文章候选，最近几天对话和执行内容又非常多，那么现在到底还能写多少篇，哪些已经写完，哪些只是候选，哪些应该进入深挖。
这个问题如果只用普通扫描回答，很容易变成表层统计。
系统可以告诉我，候选池里一共有多少条，可采纳多少条，A 类多少，B 类多少，C 类多少。这个结果有用，但它只回答了「现在列表里有什么」。
我真正想知道的是，这些对话背后，有多少条可以持续写的内容线。
这时候，AI 同事的价值不是给我一个数字，而是继续追问数字背后的结构。哪些主题已经重复，哪些主题能拆成系列，哪些内容需要脱敏，哪些内容必须回看来源，哪些内容已经被最近草稿覆盖。
也就是说，AI 同事不能只做统计员。它要参与判断。
这个判断一开始没有那么清楚。我们先看到候选池，再看到最近草稿，再看到三台电脑都可能有对话，再看到博客和公众号要分别处理。事情混在一起，就会堵住。
后来方向才逐渐清楚。普通扫描负责接住新增内容，深挖模式负责判断结构，写作计划负责排队，标准出口负责发布。
这就是第一次清方向。
候选池不是待办清单
第二个堵点，是候选池到底应该是什么。
如果把候选池当成待办清单，逻辑就会很简单。新增一条，排一条。看到一条，写一条。列表越长，任务越多。
但对话内容不是任务列表。
一段对话可能对应一篇文章，也可能对应十篇文章。一个标题看起来很小，背后可能是一整套方法。一个工具报错看起来只是执行问题，背后可能是流程边界不清。一个多机协作问题看起来是硬件问题，背后其实是权责和状态同步问题。
所以候选池不能只负责排队。
它应该先做判断。
第一，判断能不能写。这里涉及隐私、内部路径、具体账号、来源证据和发布风险。
第二，判断值不值得写。不是所有执行记录都适合对外变成文章。真正值得写的，是那些能把个人协作经验转化成普遍方法的内容。
第三，判断应该怎么写。同一个素材，可以写成执行复盘，也可以写成流程说明，还可以写成方法论文章。角度不同，读者得到的价值完全不同。
你想想看，如果这一层判断不做，后面写得越快，系统越乱。AI 同事会很努力地写，但努力方向未必对。
所以候选池真正的作用，不是告诉我「还有多少篇没写」，而是帮助我在写作之前先做分诊。
哪些可以直接写。哪些先脱敏。哪些要补来源。哪些不适合公开。这个分级一旦清楚，内容系统才不会把所有素材都当成马上可发布的任务。
深挖模式必须持续运行
第三个堵点，是普通模式和深挖模式怎么分工。
普通模式有价值。它像入口，负责把最近对话扫描进来，避免素材丢失。没有普通模式，新内容会散在不同机器、不同线程、不同工具里，很快就没人记得。
但普通模式不能成为最终判断。
普通模式容易把一段复杂对话归纳成一个标题。这个标题可以作为候选，但不能代表全部价值。一个大主题可能被压缩成一条候选，结果我们误以为它只能写一篇。
深挖模式要做的，是把这个压缩重新展开。
它要看主题之间的关系。哪些候选属于同一个 cluster。哪些已经有近期草稿。哪些适合作为系列开头。哪些应该延后。哪些只是同一件事的不同说法。
有意思的是，这一步越持续，系统越稳。
因为内容系统不是一次性整理。我们每天都在对话，每天都在执行，每天都有新堵点和新判断。如果深挖只偶尔跑一次，很快又会回到靠记忆管理的状态。
所以后来的方向很明确。普通模式作为参数候选，深挖模式持续进行。
这句话背后，其实是工作方式变化。我们不再只问「今天新增几篇」，而是持续问「最近这些互动，正在形成哪些清晰方向」。
这也是 AI 同事应该参与的地方。不是替我凭空扩写，而是在持续互动中识别结构变化。
三台电脑可以采集，但不能各写各的
第四个堵点，是多台电脑如何协作。
三台电脑都有对话，也都可能发现文章素材。那么它们会不会各自写文章。
这个问题看似是执行问题，其实是系统边界问题。
答案很清楚。可以各自采集，但不能各写各的。
三台电脑分布式采集，是好事。不同机器上的对话和任务都能进入候选池，素材不容易漏。
但写作、配图、博客发布、公众号草稿，必须集中调度。
如果三台电脑各自写，各自发，就会出现重复写、状态不一致、草稿箱混乱、配图策略不一致、质量门绕过等问题。
一台机器以为这篇文章还没写，另一台机器已经推了草稿，第三台机器又开始补图。表面看是并行，实际是在制造新的堵点。
所以我们把方向拆清楚。
采集可以分布式。候选池要统一归并。deep-dive tick 要统一聚类。写作计划要统一排队。发布出口要统一走标准流程。
这样，AI 同事可以分工，但不能乱跑。
说实话，这一点很重要。多 Agent 协作不是让每个 Agent 都自由发挥，而是让每个 AI 同事知道自己负责哪一段，完成后把状态交回系统。
这才是真正的协作。
CEO 角色要变成控制塔
第五个堵点，是 CEO 是否真的知道这件事。
我问过一个问题。如果下次我让 CEO 做，它能不能成功。
这个问题不能靠一句「知道」回答。
因为知道不等于能做成。当前对话里说过，不代表下次换线程、换机器、换 Agent 后还能执行。
要让它能做成，必须把流程写进控制文档、入口说明、分工规则和脚本命令里。
所以我们后来把责任拆开。
CEO 负责控制塔，负责知道这件事应该怎么调度。
jianfei-wechat 更适合负责对话候选池、深挖 tick、写作计划、公众号草稿和质量门。
jianfei-blog 负责博客发布。
Codex 负责对话深挖文章的配图。
deep-dive tick 负责持续生成 cluster 报告。
这些写清楚以后，AI 同事才不是临时聊天，而是进入岗位。
我跟你说，这一步特别关键。很多 AI 协作失败，不是因为模型不会做，而是因为职责没有落地。每次都靠人临时提醒，每次都重新解释上下文，系统当然跑不稳。
控制塔的意义，就是把临时理解变成可重复执行。
配图也必须进入流程
第六个堵点，是配图。
我明确说过，对话深挖文章的配图一定要从 Codex 作图，而且这件事必须在流程中。
为什么要强调这一点。
因为配图如果只是写完之后随便补，很容易变成装饰。更糟糕的是，如果标准入口失败后自动降级，用本地兜底图、卡片图或者手工图冒充正式配图，那么质量门就被绕过去了。
对话深挖文章讲的是系统、协作、判断和流程。配图也应该服务这些判断，而不是只做漂亮图片。
所以流程要清楚。
先生成 prompt。再由 Codex 当前会话作图。图片保存到标准目录。再运行 apply 脚本生成 codex-images 版本。再跑预览、质量门、推草稿。
这样配图不是事后补丁，而是发布证据的一部分。
讲道理，流程里最容易出问题的地方，往往不是大家都知道的重要步骤，而是那些看似可以随便处理的小步骤。配图就是这种地方。
一旦它可以随便降级，整个流程都会慢慢松掉。
AI 同事最重要的价值
这次互动之后，我对 AI 同事的定位更清楚了。
AI 同事不是替我制造故事，也不是替我包装场景，更不是把简单事情写得很玄。
它最重要的价值，是陪我把真实工作里的堵点拆开。
哪里卡住。为什么卡住。属于内容问题，流程问题，权限问题，分工问题，还是发布问题。谁负责。下一步命令是什么。结果写入哪里。下次能不能重复执行。
这些问题拆清楚，方向就清楚。
这也是为什么我后来提醒，文章不要随便加人物和场景。因为我们真正有价值的内容，已经在互动本身里面了。
我们问问题。AI 同事执行。执行中发现问题。我们继续追问。AI 同事修改流程。系统记录结果。下一次再用同一套入口继续跑。
这就是堵点变清楚的过程。
你有没有这种感觉，很多时候不是没有能力，而是很多能力混在一起，没有人把它们分开。AI 同事如果只负责写漂亮文章，这个问题解决不了。AI 同事如果参与拆分、归类、记录和验证，问题就开始变清楚。
所以我现在更愿意把它看成协作同事，而不是写作工具。
以后这类文章要这样写
这次也顺便校准了写作口径。
以后写这类文章，重点不是编一个开头故事，也不是写一个很圆滑的感悟。
更合适的结构是直接总结。
我们做了什么。
一开始卡在哪里。
AI 同事怎么参与。
中间发现了哪些堵点。
每个堵点怎么拆开。
最后沉淀成什么流程。
这个结构更真实，也更适合公开文章。读者看到的不是一个包装过的故事，而是一套可以迁移的工作方法。
说真的，AI 协作最容易被误解成「让 AI 替人干活」。但这次更重要的经验是，人和 AI 同事一起把方向清楚。
人提出真实问题。
AI 同事拆解执行路径。
系统记录状态。
流程固定责任。
文章总结判断。
博客和草稿箱完成闭环。
这条链路跑通以后，写文章只是结果之一。更重要的是，后面再遇到同类问题，不需要重新从混乱里摸索。
最后
这次真正沉淀下来的，不是某一篇文章，也不是一个候选池数字。
真正沉淀下来的，是一套 AI 同事协作方式。
普通扫描接住新增内容。
深挖模式持续清结构。
候选池先做前置判断。
三台电脑分布式采集，集中式调度。
CEO 作为控制塔。
jianfei-wechat 负责公众号流程。
jianfei-blog 负责博客发布。
Codex 配图进入标准流程。
每一步都留下证据。
这样做的目的，不是让系统看起来复杂，而是让真实工作里的堵点更快被看见，更快被拆开，更快变成可重复执行的流程。
AI 同事不是替我写文章。
AI 同事是和我一起，把堵住的地方拆开，把混乱的方向理顺，把已经做过的事情沉淀成下一次还能继续用的系统。