工具产出的稿子怎么直接进站：八个字段、六种标签、五道检查-墨子教育咨询

摘要：把批量产稿当交付接口来设计：必须交哪些字段、正文只认哪几种标签、图片怎么命名、入库前自动查什么、返工原因怎么归类，以及发布后的回执。

用工具批量产稿，最常见的卡点不在生成，而在落地：写出来的东西是一段带星号的纯文本，站里要的是一个带结构、带图、带字段的页面，中间那一步全靠人手工搬。搬一篇二十分钟，十篇就是半天，产量优势立刻被吃掉。

这篇讲的是这中间那一步怎么定下来——把工具的产出当成交付接口来设计：它必须交出哪些字段、正文用哪些标签、图片怎么命名、什么时候可以被判为合格。接口定好了，人工只剩审和改，不再有搬。

先想清楚谁是上游，谁是下游

批量生产的链条上只有三方：出题的人、产稿的工具、收稿的站。多数团队把三方混在一起谈，责任就糊了。

出题的人负责给出这一批要回答哪些问法、每篇对应哪个页面、必须出现哪些事实。这一层是判断，工具替不了。

工具负责把题目变成结构完整的正文，包括段落、小标题、表格、图的说明。它不需要懂业务判断，但必须严格按格式交。

收稿的站负责校验与发布：字数、图数、表数、禁用词、标签闭合、链接可达。这一层是机械检查，越自动越好。

三方各自的产出物写清楚之后，返工就有了明确落点：稿子不合格先看是题没出好、格式没守、还是检查没做，而不是笼统地说「质量不行」。

工具必须交出的八个字段

把产出做成一个结构化的对象，比交一段纯文本好得多。哪怕最后落地成网页，中间也该先有这个对象，它是后面所有自动检查的抓手。

八个字段里最容易被省掉的是最后两个。省掉的代价通常在一个月后才显现：某一批稿子被发现有问题，却查不出是哪天、用什么生成的，只能全量重审。

正文只认六种标签

工具的默认输出常常很花：加粗、引用、代码块、分割线、多层嵌套列表。这些在文档里好看，落到页面上就是样式灾难，还容易让抓取端判断错结构。

约定一份白名单，只允许六种：二级标题、三级标题、段落、无序列表、有序列表、表格。图片单独用约定格式插入。白名单之外的一律视为不合格，让工具重出，不要人工删。

为什么坚持让工具重出而不是人工删？因为人工删一次，下次还会犯。检查脚本能识别多余标签并直接拒收，工具方才会去改模板。这是一次性成本和长期成本的差别。

标签还有两条硬规矩：层级不能跳（有了三级标题就必须有对应的二级标题），标签必须成对闭合。这两条看起来琐碎，实际是渲染出错最常见的原因。

见过一批稿子，因为生成时把表格闭合标签漏了，整页后面的内容被吞进表格里，页面上看是空的，抓取端看到的是残缺结构。三十篇一起出问题，人工排查花了两天。

图片走固定命名，不要随机

图片是批量生产里最容易乱的一环。工具生成的图名往往是一串随机字符，同一张图在不同批次里出现几次，站内就有几份副本。

做法很简单：图片资产集中放在一个目录，命名按主题加用途，比如结构示意图、流程示意图、对比示意图。写作时只引用已有资产，不让工具自己造图。

这样做有两个好处。一是同一张图跨篇复用不会产生重复文件，站内不用清理。二是图挂了能一次修好，不用逐篇找。

如果确实需要新图，走单独流程：先出图、再定名、再登记到资产清单，然后才允许在正文里引用。跳过这一步，三个月后没人说得清某张图是干什么用的。

入库前的五道自动检查

人工审稿应该只做判断类的事：这篇说得对不对、有没有价值。机械类的事全部交给脚本，五道检查足够挡掉大部分低级问题。

1. 字数：去掉标签与空白后是否达到下限。这一道能挡掉大量「看起来很长实际很空」的稿子。
2. 结构：图是否够数、表是否够数、标题层级是否连续。
3. 用词：禁用词表逐条扫，包括标题、摘要与正文；案例类表述里不允许出现承诺效果的说法。
4. 标签：白名单之外的多余标签、未闭合标签、空段落。
5. 链接：站内链接是否可达，指向的页面是否存在。

五道里最容易漏的是链接。批量生成的稿子经常引用一个看起来合理的站内地址，实际那个页面从来没建过。发布后读者点到空页，比不写链接更糟。

检查不通过时的处理也要约定：不通过的稿子退回工具重出，而不是当场人工修补。人工修补会让同一类问题在下一批继续出现，而且修出来的风格和原稿不一致。

把禁用词拦在生成这一端

事后扫描能挡住问题，但每次被挡都要返工，成本高。更好的做法是把词表前置：生成时就把禁用词写进约束，让它一开始就不出现。

前置之后仍然要扫，因为工具会绕：把「保证效果」换成「确保结果」，把「行业领先」换成「行业前列」。所以词表要维护两个层次，一层是明确的禁用词，一层是需要在审稿时人工判断的模糊表达。

模糊表达这一层不必做成硬规则，做成提示就够：扫到就在审稿界面上标黄，让人决定。硬卡会把正常表达也卡掉，反而让人开始想办法绕过检查。

词表本身要有维护人。每次上线新稿发现一个新说法，就补一条，一个月下来词表会变得很实用，比一开始就列两百条管用。

批次号与回滚：出问题时能退回去

批量发布最大的风险不是某一篇写错，而是同一类错误一次性铺开。有一个能回退的机制，风险就小得多。

做法是每批带一个批次号，入库时记下来。发现问题时按批次筛选，一次性把这些页面下线或改回旧版本，而不是逐篇找。

配套的是保留旧版本。发布前把被替换的正文存一份，哪怕只是纯文本。这一步很多人省，等到需要对比「改之前是什么样」时才发现没有。

回滚要演练一次。真的出问题时才头一次用，十有八九会卡在权限或流程上。

常见返工原因对照表

把返工原因归归类，能看出问题到底出在接口的哪一层。同一类问题重复出现两次以上，就不是偶发，是接口没写清。

表里最麻烦的是最后一行。风格不统一不会导致发布失败，所以最容易被放过，但它是读者流失最快的理由：同一个站里两篇文章语气完全不同，读的人会怀疑是不是换了个站。

遇到风格混用，先查是不是有两批稿子用了不同模板。确认后不要逐篇改，直接把旧版本下线重出，比逐篇润色便宜得多。

小团队的头两周：先跑通一篇

接口文档写得再好，不跑一篇就不知道哪里卡。建议头两周只做一件事：用完整流程跑通一篇，从出题到发布，中间不跳步。

跑通的标准是能被检查脚本一次放过，不需要人工修补。做不到，就回头改接口，不要改稿子。改稿子只会让下一次重蹈覆辙。

这一篇跑通后，再跑三篇不同题材的。三篇都能过，说明接口基本稳；三篇里有两篇卡在同一个地方，说明那一处必须写进文档。

头两周不要追求量。这段时间产出的稿子本来就要重做，赶量只会把错误扩散出去，后面清理更贵。

多语言与多地版本怎么走同一套接口

多语言站点常常把批量接口做成两套，结果维护成本翻倍。其实可以共用一套，只在两个地方分支：一是术语表，二是地区事实。

术语表决定同一个概念在不同语言里怎么叫，这个必须人工定，不能让工具自译。定完之后写成对照文件，工具按文件取词。

地区事实包括地址、电话、服务范围、交付周期这些会随地区变的内容。这部分单独存一份，正文里只引用变量，不写死。

共用一套接口的好处是一处修改全局生效。坏处是错也会全局生效，所以多语言站点的发布前检查要比单语言多一道：抽查两个语言版本，对照关键事实是否一致。

把审稿记录变成下一版的约束

审稿时改的每一处，其实都在说明接口缺了一条。可惜大多数团队改完就完了，同样的修改下个月还会再做一遍。

做法是在审稿时随手记一行：改了什么、为什么改。一周下来攒二十条，就能看出重复的那几条，把它们升级成约束条件。

升级的时候要看这句约束能不能被机器判断。「太空泛」不能判断，「每节不少于三段」能判断。把前者写成后者，才是真的把经验沉淀下来。

约束也会过期。半年前必须写的「必须提到某款产品」，产品下架之后就成了负累。建议每季度清一次，把过期的删掉，否则约束越堆越多，工具只能越来越僵。

人工还剩哪三件事

接口定好之后，人工不是没事做，而是只做三件工具做不了的事。

一是判断这篇该不该发。结构合格、字够、词不犯忌，仍然可能是一篇没有价值的稿子，因为它回答的问题没人问。

二是核对事实。数字、时间、适用范围，这三类必须有人对一遍原始材料。工具会编，而且编得很像真的。

三是决定这一批是不是要停。连续几批返工率都高，说明模板或题目出了问题，继续加量只会放大问题。

这三件事都需要判断力，也正是这三门课里最难被工具替代的部分。

接口变了怎么办

接口不是定一次就永远不变。站内改版、分类调整、字数门槛变化，都会牵动接口。变化本身不可怕，可怕的是改了没通知，工具还在按老格式交。

建议把接口写成一份版本化的文档，放在团队共享的位置，每次改动记一行：改了什么、为什么改、从哪一批开始生效。工具侧按版本号对齐。

改动要小步走。一次改五个字段，下半月的稿子全乱；一次改一个字段，跑一批确认没问题再改下一个。

如果工具是外部提供的，接口文档就是合同附件。写清楚交付格式，比事后争论「为什么格式不对」有效得多。

还有一条容易忽略的：变更要留旧版。新接口上线时，旧版至少并行两批。并行期间两批产出都要能入库，否则工具侧出事时没有退路。

一套最小可用的接口长什么样

如果不想一上来就设计得很重，可以先做最小版本：标题、正文、图、对应问法，四个字段。检查只做字数、图数、禁用词三项。跑两周，看返工主要卡在哪，再决定加哪一道。

最小版本的好处是能立刻开始，坏处是容易停在最小版本。建议跑满一个月就做一次复盘，把这一月里人工补得最多的那一项，升级成必须字段。

接口成熟的标志是：新人接手时只看文档就能交出一批合格稿，不需要再问人。做不到这一点，说明还有隐性规则没写下来。

接口通了之后，瓶颈会换位置

很多团队以为把批量做起来就解决了产能问题。真的跑起来会发现，卡点从「产不出来」变成「审不过来」：一天能出五十篇，一天只能认真看十篇，剩下四十篇堆在队列里。

这时候提升产能的办法不是继续催稿，而是把审稿也拆开。机械项交给脚本，判断项分批取样：全量扫结构，抽三成看事实，抽一成看整体语气。

抽样的比例可以按题材调。同模板、同题材的一批，抽一成足够；换题材或换模板的头一批，前五篇要全看。

队列本身也要管。积压超过三天的稿子，往往发布时已经跟不上节点了。与其继续堆，不如把这一批拆小，先把能发的发完。

判断一个团队能不能吃下更大的量，不看工具多强，看审稿环节有没有被改过。审稿还是逐篇通读，量一大就会崩。

接口里要带一张发布后的回执

很多批量流程到「已发布」就结束了，实际上发布只是中间状态。页面能不能被正常看到、能不能被找到，还需要一道回执环节。

回执要确认三件事，每件都能在一分钟内查完：

• 页面能打开，且标题与摘要显示完整，没有被截断；
• 分类页与列表页里能找到这个新页面，不是只靠直链才能访问；
• 站点地图里已经有它，并能在抓取日志里看到它被请求过。

三件里最容易被漏的是第二件。页面已经发布，但没挂到任何列表，实际上是一个没有入口的页面，除了直接知道地址的人，没人会看到。

把回执做成流程里的一步，每次发布后自动跑一遍，出问题当场修。拖到一周后再查，已经不知道是发布时就没对，还是后来被别的改动弄坏了。

合集里对应的三门课

接口这一层主要靠GEO 优化工具实操的流水线与模板方法；正文结构与图片规范，靠网站 GEO 优化里的页面与抓取部分；至于哪一批该发、哪一批该停，靠GEO 优化实战训练营里的判断方法。三门合起来是这套合集。

顺序上建议先定接口再上量。接口没定就开批量，产得越多，返工越贵。

最后一段

批量生产真正的门槛不是生成能力，是交接的标准化程度。同样的工具，接口定得好，一个人一天能处理几十篇；接口没定，三个人一天也处理不了十篇。

本文的字段与检查项来自我们的项目实践，不构成对任何排名、引用或获客效果的承诺；具体门槛请按团队产能与站内规范调整。