技术内容自动化别灌水：五道闸门挡住空转输出

上个月我接手一条技术内容流水线：每周产出二十篇云产品相关文章，跑了两周，运营同事把数据拍在桌上——阅读完成率 11%，有三篇被读者在评论区指出「参数名写错了」「示例代码跑不通」。翻回来看，问题不是模型能力，而是流水线本身没有闸门：选题靠关键词拼接，生成完直接入发布队列，中间没有任何校验环节。

这篇文章讲我怎么把这条线改成「宁可少发，不发垃圾」，五个环节都能直接抄。

一、选题池绑定到真实工程问题

灌水的源头往往在选题。用「华为云 + 对象存储 + 优化」这种词组合成的标题，写出来必然是泛泛而谈，因为选题本身没有指向任何具体问题。

我的做法是让选题池只接受三类来源，每条必须附一个可追溯的链接或工单号：

• 工单与工单聚类：把近 30 天工单按错误码聚簇，出现次数 ≥5 的簇自动进池，例如 OBS 403 SignatureDoesNotMatch 在临时凭证场景下的高频报错。
• 社区提问：技术社区里带代码片段、带完整报错文本的提问，把提问 URL 存进选题记录。
• 内部踩坑记录：团队自己的变更单、复盘文档，标记 verified_by: 人名。

落库时给每条选题加一个字段 evidence_url，不允许为空。生成任务启动前先校验：evidence_url 为空或打不开，任务直接拒绝，不消耗 token。这一条把「泛泛而谈」消灭在了上游。

二、字数与结构校验挡掉空转输出

模型很擅长用「总而言之」「随着业务发展」凑篇幅。光看总字数没用，得分段看密度。我在生成后加了一个 Python 校验脚本，几秒钟跑完：

import re

def check(text):
    paras = [p for p in text.split("\n\n") if p.strip()]
    body = len(re.sub(r"\s", "", text))
    issues = []
    if body < 800:
        issues.append(f"正文字数不足: {body}")
    # 每段至少一个可执行元素：命令、代码或具体参数
    for i, p in enumerate(paras):
        if not re.search(r"`[^`]+`|（[^（）]*=[^（）]*）|\d+", p):
            issues.append(f"第{i+1}段无具体信息")
    # 套话密度
    cliche = ["随着", "在当今", "综上所述", "总而言之", "众所周知"]
    hit = sum(text.count(w) for w in cliche)
    if hit > 2:
        issues.append(f"套话出现{hit}次")
    return issues

规则很土，但有效。第一版跑出来，二十篇里十一篇没过，集中在「段落无具体信息」——那些段落全是抽象描述。不过校验的输出不能直接丢掉，而是回传给模型做定向重写，指定「第 3 段补充一个真实报错文本或命令」，通常两轮能过。

三、真实性检查：人和规则都得上

结构达标不代表内容正确。我见过模型编出一个看起来很像的 API 参数名，工程师一眼能看出来，但运营看不出来。

规则侧做三件事：

• 代码块可执行性：所有 bash 代码块抽出来，在隔离环境里做 shellcheck 语法检查；CLI 命令做参数拼写校验，与官方文档的参数清单比对。
• 接口名白名单：抓取正文里形如 xxx.yyy.zzz 的标识符，与内部维护的 API 清单求差集，不在清单里的一律标记待复核。
• 数字与版本：正文中出现的版本号、限额数字，要求与引用链接中的原文一致，不一致标记。

规则能挡掉七成硬错误，剩下三成必须人看。我在流程里固定一个 human_review 环节，由写过该产品代码的工程师签字，签的是「文中命令我跑过」而不是「看了一遍」。这一步是整条线上最贵的，但也是唯一能保证不丢人的。

四、重复投同一份内容的查重风险

流水线一开，最容易犯的错是拿旧稿改个开头重发。这不只是读者体验问题：同一账号短时间内投高度相似的稿件，平台侧会判低质甚至降权，而技术社区通常会记录并拒收。

我的做法是入库前先算相似度。用字符级 SimHash 对全文和历史库做比对，阈值设 0.85，超过直接拒；0.7 到 0.85 之间进入人工确认，要求作者说明与旧文的差异点，且差异必须落在「新增命令、新增报错场景、新增版本变化」上，而不是换措辞。

另外，同一选题在同一季度内只允许产出一篇，选题池表上加唯一约束 unique(topic_cluster, quarter)，从数据层面堵死重复生成。

五、把「宁缺毋滥」写成硬规则

口号落不到代码里就是空话。我给流水线定了三条硬规则，写在任务调度配置里：

• 配额不追平：每周产出上限 20 篇，但下限是 0。校验未通过的数量不进入待办，不触发补生成。
• 失败即熔断：同一选题连续两次真实性复核不通过，该选题冻结 30 天，并通知提交人补充材料。
• 质量分门槛：每条内容按「具体信息密度 + 校验通过项 + 人工复核结论」打分，低于阈值的内容只能进草稿箱，不能进发布队列，草稿超过 14 天自动归档。

改完之后第一周只发出了 9 篇，运营一度不满。但第四周数据回来了：完成率 47%，评论区没人再挑参数错误，还有两篇被产品团队拿去做了内部培训材料。内容自动化真正的价值不是产能，是把人从写废话里解放出来，去做那些只有人能做的判断。