GEO 交付要对四本账：标题、正文、入队、上线｜拓路人

一、先说一个我们踩过的坑

一个 GEO 项目跑完一个月，甲方问：「这个月做了什么？」

如果答案是「发了 80 篇」，那这个项目多半是有问题的。不是因为这 80 篇没用，而是因为「80 篇」这个数字本身，对不上项目里真实发生的事。

我们内部有一条规定：每一轮生产结束，必须对四本账—— 标题数 → 正文数 → 入队数 → 上线数。四个数字必须能串起来，中间任何一处对不上，都要查清是哪一层掉的。

为什么是四本账，不是一本？ 因为从「想出一个标题」到「真的上线」，中间至少有四个会静默丢东西的地方。这篇文章把这条链子摊开讲。

配图：每一轮生产结束，四本账要能对得上

标题是整条链子的入口。它从哪来？从知识库、从产品资料、从客户自己填写的服务区域和客户类型里来。

这一层最容易出的问题是「标题多、能用的少」。 我们曾经统计过自己的一条产品线：一个批次生成了几十条标题，但真正进入下一层的不到七成。

原因通常不是模型不行，而是门禁在前、产出在后：标题生成之后要过一整套规则（长度、句式、是否带术语、是否重复、是否踩到品牌安全线），被拦下的标题不进入下一层——这是对的，但如果拦下来的原因不留痕，这一层的账就永远是平的。

所以我们给自己定的规矩是：每一次拦截都要写日志，并且日志里要能回答「它为什么被拦」。一条标题被拦，要么改，要么明确废弃；不能既没改、也没记，就从世界上消失。

标题有了，接下来是成文。这一层的账最容易被人忽略，因为它看起来「理所应当」：有标题，就该有正文，对吧？

不对。 我们实测过一条规律：文章数 = 标题数 − 补出来的标题数。

什么意思？为了让每个平台都发够配额，系统会在主批次跑完之后，再补一批标题。但如果这批补出来的标题错过了当轮的生文窗口，它们就会永远停在「只有标题、没有正文」的状态。第二天再跑，又是新的一轮，这批就彻底成了死标题。

这个坑的隐蔽之处在于：界面上看起来一切正常。 标题在库里、数量在涨、没有报错。只有当你去对第二本账的时候，才会发现「标题攒了 400 条，正文只有 300 篇」，而那 100 条差额永远不会有正文。

修法不是「多跑几次」，而是把补标题这件事挪到生文窗口之前——让补出来的标题和主批次一起进入正文生产。改完之后， 标题数 = 正文数，这条账才真正平了。

正文写完了，还要入到发布队列里。这一层的账，是四本里最像「运输」的一环—— 东西生产出来了，但没有运出去。

我们遇到过的情况是：补写的正文落在了主流程之后才写盘，而队列是在主流程里就排好的。结果就是「正文有了，队列里没有」。

那一轮	标题	正文	入队	差额
某次批量生产	有	有	少了 5 条	补写落盘晚于排队
另一次	有	有	少了 34 条	同上

这 5 条和 34 条，都是事后人工补进去的。 所以我们的收尾清单里有一句硬规定： 正文数 ≠ 入队数时，先跑一次补队，再结项。

最后一本账是「真的发出去了吗」。

这一层要区分三种状态，很多人会把它们混成一种：

「入队」不等于「上线」，这是我们最常纠正的一个误解。 一个项目结项时，我们会把第一本账和第四本账并排放在一起： 这一轮一共想了多少条 → 最后有多少条真的拿到了公开链接。 中间每一层的差额，都要能说出去哪了。

到这里可能有人会问：这是内容生产的管理问题，跟 GEO 有什么关系？

关系在于：AI 引用的，是「网上真实存在的那一篇」。

所以「标题 400 / 正文 300」这件事，在 GEO 语境下不是「少写了 100 篇」，而是那 100 个本来可以出现在 AI 答案里的位置，从一开始就是空的。

四本账的真正用途，是让你在结项那天能回答一个问题：我们说做了 N 篇，这个 N 是怎么算出来的。

问：这四个数字正常应该是什么关系？

健康的状态是四个数字基本相等，差额全部有明确、可查的去向。如果第一本账（标题）远大于第四本账（上线），说明问题在中间某一层，而不是「这个月产出少」。

问：客户能自己核这四本账吗？

能，而且我们建议核。你可以要求看：标题清单、正文清单、队列记录、以及每一篇的公开链接。 四份东西放在一起，能对上的就是真的，对不上的就会当场露出来。

问：这算不算过度管理？

反过来想：如果不对这四本账，你要么高估了自己（拿标题数当产出），要么低估了自己（明明写了，只是没入队）。两个方向的错都会影响你对这件事的判断。

问：界问GEO 自己是怎么做的？

上面写的这套，就是我们在执行的流程。四本账、拦截留痕、补队收尾，都是内部的固定动作，不是为这篇文章写的。

在 GEO 这件事上，「发了多少」是一个很容易说出口、也很容易说不准的数字；能对得上四本账的，才是能拿出去核的产出。