这几天我一直在追一个问题，我们每天有大量对话，也做了很多事情，如果把这些内容都交给系统扫描，它到底能发现多少篇文章？
表面看，这是一个效率问题。 对话很多，人不可能一条条看。让工具扫描，把候选主题抽出来，再交给写作系统处理，好像是最自然的办法。
但做着做着，我越来越觉得，真正的问题不是“扫描够不够快”，而是“扫描结果能不能全信”。
答案很明确，不能全信。 不是因为工具没用。相反，扫描工具非常有用。它能把人眼容易漏掉的内容捞出来，能把碎片对话变成候选主题，能持续记录新增内容，能给出一个初始判断。
但扫描结果只能当输入，不能当结论。 如果把它当结论，内容系统很快会出问题。
扫描会看到表面，却未必看懂深层
对话里的内容有一个特点，它不是按文章结构说出来的。 人在对话里经常是边做边想，边想边改。一个话题可能分散在十几轮里面，中间穿插工具结果、错误修复、临时判断、路线调整。很多重要内容，不是以“我要写一篇文章”为开头出现的，而是藏在一句追问、一次怀疑、一个纠偏里。
扫描工具擅长识别显性信息。 比如它能看见“候选池”“三台电脑”“草稿箱”“博客发布”“深挖模式”这些关键词。它也能把这些词组合成主题。
但它未必能看懂深层关系。 “三台电脑都有对话的话，它们会各自写吗？”这句话表面是问多机执行。深处其实是问内容系统的权责边界，采集能不能分布式，写作能不能并行，发布是否需要中心化，状态如何避免冲突。
如果扫描只给出“多设备协同”这个标题，就太浅了。 再比如“CEO 是否知道这个事情，如果下次我让他做的话，他能做成功吗？”表面是问某个 agent 能不能执行。深处其实是问一套流程是否已经被写入系统记忆、入口、RACI、控制台和命令里。也就是说，用户关心的不是“它知道吗”，而是“它能不能可重复地做成”。
扫描可以发现这个问题，但不一定能自动回答到这个层次。 所以扫描结果必须经过深挖。
扫描还会低估文章数量
我问过一个问题，这两天对话和做的事情非常多，只新增了一部分吗？如果深度解析，可能会有多少篇？
这个问题很关键，因为它暴露了扫描结果的一个天然缺陷，扫描通常会低估。 为什么低估？ 因为扫描倾向于把一段连续对话压缩成一个主题。它为了避免重复，会把相近内容合并。这在候选管理上是好事，但在写作判断上会损失很多分叉。
比如“对话写文章系统”这个大主题，普通扫描可能只得到一条候选，原始对话不是文章，而是选题矿。
但深挖以后，它至少能拆出很多篇。 第一篇可以写候选池为什么不是待办清单。 第二篇可以写扫描结果为什么不能全信。 第三篇可以写隐私分级为什么要发生在写作之前。 第四篇可以写三台电脑为什么应该分布式采集、中心化调度。
第五篇可以写配图为什么必须进入标准流程。 第六篇可以写写作计划为什么需要状态、证据和执行 marker。 第七篇可以写 CEO 角色为什么不该只是聊天代理，而应该是控制塔。 这些文章都来自同一片对话，但它们不是同一篇文章。
所以当系统说“新增 0 条”时，不等于没有新内容。当系统说“候选 53 条”时，也不等于只能写 53 篇。
普通扫描给的是显性候选数。深度解析给的是可写空间。
两者不能互相替代。
扫描也会高估可发布性
低估文章数量是一种问题，高估可发布性是另一种问题。 扫描工具看到一个主题，可能觉得它能写。但能写不等于能发布。 对话里面有很多内容带着现场性。比如本地路径、机器名称、内部流程、未公开的工具状态、账号、草稿、错误日志。这些东西在协作里很有用，但不适合直接进入公开文章。
还有一些内容虽然不敏感，但需要上下文。读者如果看不到完整来源，很容易误解。这样的主题不能直接写，要先回看原对话，把原因、经过、判断链补齐。
所以我现在把候选分成四类。 A 类可以直接写。 B 类需要先脱敏。 C 类需要回看来源。 D 类内部阻塞，不写。 这个分级看起来简单，但非常重要。它让扫描结果从“自动结论”变成“待复核输入”。
尤其是对话深挖文章，不能为了产量跳过这一步。越是自动化，越要把隐私和来源放在前面。 不然系统会越来越能写，也越来越容易写出不该写的东西。
扫描结果要被聚类，而不是逐条执行
还有一个容易犯的错，扫描出候选以后，按列表从上往下写。 这很像处理任务，但写作不是这样。 写作需要看主题之间的关系。 如果两个候选都在讲“三台机器协作”，它们可能不是两篇独立文章，而是一组系列。也可能其中一篇已经被另一篇覆盖，需要换角度。还有可能这组主题最近已经写过几篇，再继续写就会让读者觉得重复。
所以扫描之后必须做 cluster。 cluster 的意义，不只是把相似标题放在一起。它要回答几个更深的问题。 这个主题群里，哪一篇最成熟？ 哪一篇最有公共价值？
哪一篇和最近草稿重复？ 哪一篇需要延后？ 哪一篇适合作为系列开头？ 哪一篇应该拆成方法论，而不是写成流水账？ 这就是为什么我要求生成 deep-dive tick 和 cluster 报告。
tick 负责持续刷新。cluster 负责把散落候选变成结构。没有 cluster，候选池只是列表。有了 cluster，候选池才开始像内容系统。
人的判断不是被替代，而是被前移
很多人一提自动化，就会自然地想，能不能让工具自己扫描、自己写、自己发？ 短期看，当然可以做一部分。 但这几天的经验让我更确定，真正重要的不是把人拿掉，而是把人的判断前移。 以前人的判断发生在写完之后。文章写出来了，再看能不能发，哪里不合适，哪里要删。
现在应该反过来。 在扫描之后、写作之前，就先判断主题价值、隐私风险、相似度、文章角度和发布路径。 这样做有一个好处，后面的自动化会更可靠。 如果前面判断不清楚，后面写作越快，问题越多。可能重复写，可能写浅，可能泄露细节，可能文章和草稿状态对不上，可能博客发布了但公众号没有推，可能配图走了错误流程。
如果前置判断清楚，后面的自动化反而可以大胆一点。因为它知道哪些能写，哪些不能写，哪些先脱敏，哪些要回看来源，哪些进入博客，哪些推到草稿箱。
这不是人让位给工具。 这是人把自己最重要的判断，放到系统最上游。
我现在怎么用扫描结果
现在我对扫描结果的用法，比一开始谨慎很多。 我会先看总数，但不迷信总数。 我会看新增，但不把“新增少”理解成“内容少”。
我会看 A 类候选，但不会直接全写。 我会看 B 类和 C 类，因为它们往往代表更深、更真实、但还需要处理的内容。 我会看 cluster，而不是只看单条标题。 我会看最近草稿，避免同一方向连续重复。
我还会要求配图、预览、质量门、博客和草稿箱都在同一条流程里完成。因为内容系统不是只把正文写出来，而是要让一篇文章从素材、判断、写作、配图、发布到留证全部闭环。
扫描是入口，不是终点。 它负责把可能性找出来。 深挖负责把可能性拆开。 判断负责决定能不能写。 流程负责保证写完之后不乱。
扫描之后还要有人做编辑判断
你想想看，扫描工具给出来的主题，很多时候像一堆刚挖出来的矿石。它们确实有价值，但还没被打磨。哪一块能直接用，哪一块里面有杂质，哪一块看起来普通但里面可能有更深的东西，这些都不是扫描本身能完全判断的。说实话，如果没有后面的编辑判断，扫描越勤快，候选池越容易变成噪音池。
我跟你说，一个内容系统最危险的状态，不是没有候选，而是候选很多却没人分辨。数量一多，人就容易被数字带着走。看到五十篇，就觉得应该马上写五十篇；看到新增为零，就以为这两天没什么可写。可真实情况往往相反，新增少可能只是被合并了，候选多也可能只是重复多。
有意思的是，扫描结果最有价值的地方，恰恰不是它给出的标题，而是它暴露出的疑问。为什么这个主题被归到这一类？为什么它和最近草稿相似？为什么它被判成需要来源？为什么它没有进入 A 类？这些问题一问，人的判断就被调动起来了，系统也开始从记录工具变成思考工具。
说真的，我现在更愿意把扫描看成初筛。它像一个早班编辑，先把所有可能有价值的东西摆到桌面上。深挖模式像主编，负责看关系、看结构、看系列、看风险。最后写作才像作者，负责把判断变成读者能读懂的文章。三个环节缺一个，都会出问题。
你想啊，如果以后对话量继续翻倍，我们不可能靠人工回忆来保证不漏内容，也不能靠扫描工具自动决定什么都能写。更稳的办法，是让扫描持续跑，让 cluster 持续更新，让分级持续生效，然后让人只在关键判断点上用力。这样系统才不是替人乱写，而是帮人把注意力放回最值钱的地方。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
结尾
扫描结果不能全信。 但这不是否定扫描。恰恰相反，只有承认扫描不能全信，扫描才真正有用。 如果把扫描当结论，它会制造幻觉，好像所有内容都已经被理解，好像所有候选都可以执行。 如果把扫描当输入，它会变成一个很强的起点，帮我们找到素材，提醒我们不要漏掉对话，给深挖模式提供基础。
我现在更愿意把它看成内容系统里的第一道门。 门口有人递来一篮子矿石。 扫描告诉我，矿石在这里。 深挖告诉我，里面可能有什么。 判断告诉我，哪些能打磨，哪些要先放一放。 最后写作才开始。 这条顺序不能反。
讲真，这也是我这次最想留下来的判断。对吧，系统不是为了替我们省掉思考，而是为了让思考更早发生。你懂吧，当判断放在前面，后面的写作、配图、发布和草稿箱推送，才不会每一步都靠临场补救。
作者：剑飞，本文共3220字