返回板块

X04 公众号文章查重降重技术标准

1 公众号文章查重降重技术标准

标准编号：LHB/TS-2026-008 ｜ 版本：V1.0.0 ｜ 发布日期：2026-09-14 ｜ 实施日期：2026-09-14 ｜ 归口：利衡辨 · 全域治理

标准性质：规则性标准（首版，A 类新建）· 执行层落地件 ｜ 上位依据：《全域文件技术体系宪法》现行版 M0.7 第 23 条「公众号成文查重降重铁律」

权威关系：本文件为公众号成文链路「查重降重（去重复率）」环节的执行层标准。效力层级为：宪法 > MEMORY > 台账 > 国家标准 > 本文件 > 其他规范。与宪法冲突时以宪法为准；与《全域文件工作流规则技术标准》就区域路由与四盘同步冲突时，以该标准为准（本文件复用，不替代）；与《利衡辨·公众号助手·技术规范要求》及 `optimize_content.py` 内嵌「洗稿红线」表述冲突时，以本文件为准（本文件将该红线收敛为可实测的 8% 单一阈值）。

前言

本标准由一次明确的生产需求触发。2026-09-14 用户提出：公众号成文链路应增加「去重复率」功能，且重复率须低于原稿的 8%。经三口径确认，最终锁定为句子级查重、原稿与历史稿库双基准、超标自动降重。

立标前本域存在两处口径真空：

第一，「原创度」此前只有提示词口径、没有可实测的判据。`optimize_content.py` 的 SYSTEM_PROMPT 第 6 条列出「洗稿红线由 >30% 收紧至 >10%」，但该比例是写在提示词里的自约束，由模型自评，既无计量脚本、也无留痕，出现分歧时无法复核。本域一贯的判据要求是「能被第三方仅凭留档复算」，提示词自约束不满足该要求。

第二，「重复率」在成文链路中无环节承接。既有链路为 `fetch → optimize → humanize → generate_images → build_package → publish`，`humanize` 只负责「去 AI 味」，不承担「与原稿/历史稿的相似度控制」；两者的优化目标正交——一篇文章可以既「不像 AI 写的」、又「与原稿高度雷同」。

本标准把「原创度」从取决于模型是否恰好遵守了提示词，收敛为四要素可实测判定 + 超标自动降重 + 不达标预警三重确定项，并配一键执行脚本 `dedup_check.py`（纯脚本判据，超标前零 LLM 调用）。

本标准的设计受两条既有裁定约束：其一，宪法 M0.7 第 4 条「1进1出管道」——本环节为单一输入（成稿 Markdown）、单一输出（降重后 Markdown + 判定报告），不得引入回环；其二，宪法 M0.7 第 10 / 13 条「技术经济性 / 载体收敛」——查重不得成为新增冗余载体的理由，故判定采样全部下沉为本地纯脚本，净增常驻载荷 0，仅超标改写时按次调用 LLM。

1.1 规范性要求等级（RFC 2119）

表 0-1 规范性要求等级（RFC 2119）

等级	含义	本文用法
**必须**（MUST）	绝对要求，违反即判不合格、禁止发布	用于红线与闸门条款
**不得**（MUST NOT）	绝对禁止	用于禁止性条款
**应**（SHOULD）	推荐执行；不执行须书面说明理由并登记	用于强推荐项
**不应**（SHOULD NOT）	不推荐；执行须说明理由	用于弱禁止项
**可**（MAY）	可选	用于允许性条款
**宜**（RECOMMENDED）	较「应」更弱的推荐	用于经验性建议

引言

1.2 三项核心原则（强制贯穿）

表 0-2 三项核心原则与本文落地方式

原则	内涵	本文落地方式
场景定义需求	先定场景，再由场景推导需求	场景＝公众号稿件需过平台原创/查重判定；由此推导需求「重复率低于阈值的可实测控制」；不先定算法
技术经济性	以最小代价取得确定收益	判定阶段纯本地脚本、**0 LLM 调用**；仅当重复率超阈值时按次触发一次改写 pass；净增常驻载荷 0
1进1出	单一事实源，单一当前态	输入恒为一份成稿 Markdown；输出恒为一份降重后 Markdown + 一份判定报告；同一稿件同一时点只保留一份当前判定

1.3 认知入口（逻辑思维简图）

图1-1 公众号查重降重认知框架逻辑思维简图

注：本图回答「为什么这样组织」——自顶向下的分层认知框架与层间依赖关系

1.4 全生命周期模型（生命周期结构图）

图1-2 公众号查重降重全生命周期生命周期逻辑结构图

注：本图回答「每一步做什么」——各阶段触发条件、责任人、校验方式与例外回路

第一篇 目的与底层逻辑

2 范围

本标准规定了公众号成文链路中「查重降重（去重复率）」环节的比对基准、计量口径、相似度判定信号、处置规程、执行接口与校验要求。

本标准适用于「利衡辨·公众号助手」成文链路于 `humanize_content` 之后、`build_package` 之前插入的查重降重环节，及其执行脚本 `dedup_check.py`。

本标准不适用于：对外部公开网络的查重（需外部检索/AI 判定，不在本地纯脚本能力内）；对单句事实性表述（人名、数字、机构名）的原创度判定；以及非公众号类交付物的查重。

3 规范性引用文件

下列文件对于本标准的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本标准。

表 2-1 规范性引用文件

编号	文件	版本	关系
UP-1	全域文件技术体系宪法	V2.27.0	上位（M0.7 第 23 条，公众号成文查重降重铁律）
UP-2	全域文件技术体系宪法	V2.14.0	上位（M0.7 第 4 / 13 条，1进1出管道 / 载体收敛）
UP-3	全域文件技术体系宪法	V2.18.1	上位（M0.7 第 18 条，Token 预算——判定阶段零 LLM 为其落地）
UP-4	利衡辨·公众号助手·技术规范要求	现行版	同层（本标准为其成文链路新增环节的执行细则）

4 术语和定义

下列术语和定义适用于本标准。

4.1 重复率 duplication rate

稿件的散文正文中，与基准语料构成复制或近义改写的句子 CJK 字数之和，占散文正文 CJK 总字数的百分比。

4.2 原稿 source manuscript

本次成文所依据的源素材，其内容以成文链路的 `article_raw.json` 之 `paragraphs` 字段为准。

4.3 历史稿库 history corpus

账号既有成稿的集合，取工作区 `_stage_*/article.md` 与 `*_待发表包/article.md` 的散文正文。必须排除与当前稿同标题（`# 三字标题`）的同源文件，否则将出现「当前稿与其自身待发表包比对」的自我比对虚高。

4.4 复制信号 exact copy

两段文本之间存在长度 ≥ 20 的连续相同 CJK 字符子串。此为直接复制/粘贴的判据。

4.5 近义改写 near-dup

两段文本在长度比 ∈ [0.7, 1.43] 且字符 bigram Jaccard ≥ 0.85 时，判为近义改写。此为「同义换词但保留语序骨架」的洗稿判据。

4.6 降重 dedup rewrite

在重复率超阈值时，对超标的散文正文行触发大模型改写、以降低重复率的过程。

第二篇 技术要求

5 比对基准

查重的基准由三部分构成，必须全部纳入：

· 原稿：`article_raw.json` 的 `paragraphs`（`--raw` 指定）；

· 历史稿库：工作区既有成稿（`--history-dir` 指定，默认工作区根）；必须排除同标题同源文件；

· 自身：当前稿内先出现的句子（自重复检测，捕获稿件内部重复）。

原稿缺失时可退化为历史稿库单基准；历史稿库为空时可仅作自重复检测。二者均缺失时，本标准判「不得判定」（见 §判定）。

6 计量口径

表 5-1 计量口径锁定

口径项	规定值
粒度	句子级（按 `。！？!?；;…` 切分）
计入范围	仅「散文正文」（标题 / 引用行 / 结尾模块均不计）
结尾模块	【摘要】【中心思想】【个人感悟】【辩证哲学】【利衡辨理论分析】不计入、不改写
最短句长	单句 CJK 字数 < 12 者不计入分子与分母
重复率公式	复制/近义句 CJK 字数之和 ÷ 散文正文 CJK 总字数 × 100%
阈值	≤ 8.0%

7 相似度判定信号

表 6-1 双信号判定

信号	判据	语义
复制	存在长度 ≥ 20 的连续相同 CJK 子串（去标点后比对）	直接复制/粘贴
近义改写	长度比 ∈ [0.7, 1.43] 且 字符 bigram Jaccard ≥ 0.85	同义换词、保留骨架

两信号为或关系，命中其一即判该句为重复句。判定不得采用「短子串包含」（如 ≥10 字互相包含）等宽口径——该口径在同主题中文内误报率高，已由实测证否。

8 处置规程

表 7-1 处置规程

条件	动作	约束
重复率 ≤ 8%	不改写，直接进入后续环节	记 `passed=true`
重复率 > 8%	收集超标散文正文行，触发 LLM 逐行改写并回填	改写**必须**保持原意、保留行数
改写后复测	重新计量，循环至 ≤ 8%	轮次上限 **≤ 3**，防死循环
3 轮后仍 > 8%	记 `degraded=true` 并**预警人工**	**不得**阻断出稿、**不得**静默通过
无 API Key	记 `degraded=true` 并预警	**不得**伪报通过

结尾模块、标题与引用行不得进入改写集合。

第三篇 执行与校验

9 执行接口

表 8-1 执行接口

项	内容
脚本	`scripts/dedup_check.py`（公众号助手 skill 内）
调用	`python dedup_check.py --md <成稿> --raw <原稿json> --history-dir <工作区> --out <成稿> --threshold 8 --mode l2`
接入点	`custom_run.py` ③.5 步（`humanize_content` 之后、`build_package` 之前）
输出	1）降重后 Markdown（覆盖 `--out`）；2）判定报告 JSON（stdout）

判定报告必须含字段：`engine`、`threshold`、`initial_rate`、`final_rate`、`passed`、`rewrite_rounds`、`degraded`、`usage`（`prompt_tokens` / `completion_tokens` / `total_tokens` / `calls`）。

10 硬闸与校验

· 阈值硬判：`passed` 当且仅当 `final_rate ≤ 8.0`。

· 零调用闸：`final_rate` 首次即 ≤ 8% 时，`usage.calls` 必须为 0（判定阶段零 LLM）。

· 轮次闸：`rewrite_rounds ≤ 3`。

· 不阻断闸：`degraded=true` 时不得使编排层退出码非 0——稿件照常打包与发布，仅预警留痕。

· 统计并入：本环节 `usage` 必须并入链路 token 统计落盘（`token_usage.json`）。

11 技术经济性核算

表 10-1 成本核算（实测）

场景	判定阶段 LLM 调用	改写 LLM 调用	实测 tokens
原创稿（重复率 0%）	0
复制稿（重复率 43.48%）	0	1	≈ 1162

结论：判定阶段零 LLM；改写仅在超标时按次发生。相较「无论是否超标都整篇重写」的朴素方案，本设计在原创稿上节省 100% 改写开销。

第四篇 治理与实施

11.1 职责与监督

表 11-1 职责分工

角色	职责
编排层（`custom_run.py`）	于 ③.5 步调用本环节，透传源稿与历史库路径，汇总 token 统计
判定脚本（`dedup_check.py`）	建库、计量、判定、超标改写、复测、出报告
审核人	对 `degraded=true` 的稿件人工复核原创度

监督要点：任一稿件的 `dedup` 判定报告必须留痕于产出文件夹的 `token_usage.json` 之 `步骤.dedup` 字段。

11.2 文档管理

本标准的权威源为 `~/.workbuddy/specs/标准库/`；发布副本由四盘同步（`sync_disks.py`）复制至三副本盘。同主题现存版本数必须为 1（旧版按版本保留策略归档至 `specs/_archive/`）。本标准的执行层配套件为 `scripts/dedup_check.py`。

11.3 审批记录

表 12-1 审批记录

环节	结论	日期
起草	完成 V1.0.0 全文（四篇式 + 附录 A–E）	2026-09-14
三原则校验	通过（场景锚定 / 净增常驻 0 / 1进1出）	2026-09-14
上位对齐	宪法升 现行版，M0.7 新增第 23 条	2026-09-14
发布	全域发布（标准 + 宪法 + 记忆 + 四盘同步）	2026-09-14

12 修订记录

表 13-1 修订记录

版本	日期	归口	修订内容
V1.0.0	2026-09-14	利衡辨 · 全域治理	首版。由用户「去重复率、重复率低于原稿 8%」需求立标：确立原稿+历史库双基准、句子级计量、复制（≥20 连续同字）/近义改写（bigram Jaccard ≥0.85）双信号、8% 阈值、超标自动降重（≤3 轮）、不阻断出稿的预警机制，并同步发布执行层配套件 `dedup_check.py`。

附录 A

A.1 A.1 一页判定链

建库（原稿 + 历史库，排除同源）→ 计量（句子级、仅散文正文、短句 <12 字不计）→ 判定（复制 ≥20 连续同字 或 近义 Jaccard ≥0.85）→ 重复率 ≤ 8% ？→ 超标则改写 ≤3 轮 → 复测 → 出报告并并入 token 统计。

A.2 A.2 阈值与信号速查

表 A-1 阈值与信号速查

项	值	依据
阈值	8.0%	用户 2026-09-14 裁定
复制信号	连续相同 CJK ≥ 20 字	直接复制判据
近义信号	length-ratio ∈ [0.7, 1.43] 且 Jaccard ≥ 0.85	洗稿判据
最大改写轮次	3	防死循环
判定阶段 LLM 调用	0	技术经济性

A.3 A.3 四条最容易犯的错

第一，把结尾模块计入重复率——【摘要】等为模板化段落，计入将虚高。第二，不排除同源文件——会拿当前稿与自己的待发表包比，实测误报 88.86%。第三，用短子串包含做判据——≥10 字互相包含在同主题中文内误报极高。第四，超标即阻断出稿——本标准要求预警而非阻断。

附录 B

表 B-1 失效模式速查

编号	失效模式	表现	处置
D-1	自我比对虚高	重复率异常偏高（如 >80%）	检查历史库是否已排除同标题同源文件
D-2	误报满篇	原创稿被判高重复率	检查判据是否退化为短子串包含
D-3	判据空转	报告 `usage.calls=0` 但重复率恒为 0	检查参考库句数是否为 0（基准缺失）
D-4	改写不收敛	3 轮后仍 >8%	记 `degraded` 并转人工复核
D-5	无 Key 假通过	无 Key 却报 passed	无 Key 时必须记 `degraded` 并预警

附录 C

表 C-1 本标准的机器判定链路

工具	用途	调用方式	是否新增
`dedup_check.py`	查重计量 + 判定 + 超标改写（本标准 §5–§9 的机器实现）	`python dedup_check.py --md ... --raw ... --history-dir ...`	**新增**（唯一新增件）
`custom_run.py`	编排层 ③.5 接入点	自动调用	复用（加一步）
`deliverable.py`	命名 / 路径闸门	被 import	复用
`doc_style_check.py`	文档母规则判定	`python doc_style_check.py <md|docx>`	复用
`sync_disks.py`	四盘同步	`python sync_disks.py --strict`	复用

附录 D

D.1 D.1 判定报告字段

表 D-1 判定报告结构

字段	类型	说明
`engine`	str	`local`（未改写）/ `deepseek`（已改写）
`threshold`	num	阈值（默认 8.0）
`initial_rate`	num	改写前重复率
`final_rate`	num	最终重复率
`passed`	bool	`final_rate ≤ threshold`
`rewrite_rounds`	num	实际改写轮次
`degraded`	bool	未达阈值需人工复核
`ref_sentence_count`	num	参考库句数（判定基准是否为空）
`usage`	obj	`prompt_tokens` / `completion_tokens` / `total_tokens` / `calls`

D.2 D.2 CLI 参数

表 D-2 CLI 参数

参数	必填	默认	说明
`--md`	是	—	待查重成稿
`--raw`	否	无	源素材 JSON（原稿基准）
`--history-dir`	否	无	历史稿库根目录
`--out`	否	= `--md`	降重后写出路径
`--threshold`	否	8.0	重复率阈值 %
`--max-rounds`	否	3	最大改写轮次
`--no-self`	否	关	关闭自重复检测

附录 E

表 E-1 映射表

上游/邻接	关系	本文件对应
宪法 M0.7 第 23 条	上位依据	全文
宪法 M0.7 第 4 条（1进1出）	上位约束	§8 执行接口单入单出
宪法 M0.7 第 10 / 13 条（载荷压缩 / 载体收敛）	上位约束	§10 净增常驻 0、判定零 LLM
利衡辨·公众号助手·技术规范要求	同层	`optimize_content.py` 洗稿红线收敛至 8%
全域文件工作流规则技术标准	邻接	区域路由与四盘同步以其为准

E.1 定稿校核结论

本标准现行版本 现行版；上位条款为宪法 现行版 M0.7 第 23 条。同主题现存版本数 = 1。执行层配套件 `scripts/dedup_check.py` 已实测：原创稿 0%（0 调用）、复制稿 43.48%→0%（1 轮改写，1162 tokens）。