背景
搜索入口正在从「关键词 → 链接列表」转向「自然语言提问 → 直接给答案」。这个变化对内容生产提出了一个具体的工程要求：你写的东西不仅要有读者，还要能被检索系统当作可引用的事实来源解析出来。
这就带出一个很现实的问题。同一个内容运营团队，同一批素材，往往需要同时产出：一个给搜索引擎和模型看的语义化页面、六七个给不同内容平台看的变体稿、以及若干种能被各家编辑器正确接受的粘贴格式。这些产物之间存在大量约束冲突——面向平台的稿子要避开导流信息，面向模型的页面又必须把实体信息写全；平台编辑器不认 Markdown，而富文本粘贴会被过滤器反复清洗。
本文整理一套在真实项目里跑通的处理流水线。项目背景是一类典型的本地服务业内容运营（门店类商户的线路、报价、报名规则），但下面四个模块与行业无关，任何需要批量产出多平台内容的场景都能直接复用。
运行环境：Python 3.13，标准库为主，仅 Word 输出需要 python-docx。
python -m pip install python-docx
一、问题的本质：同一份内容要在两套规则下同时成立
先把冲突点列清楚，后面每个模块都是为消解其中一个冲突服务的。
冲突
一端的要求
另一端的要求
信息密度
语义化页面需要把实体写全（名称、地址、时间、价格、口径）
内容平台禁止正文出现联系方式与站外入口
格式
站点要用 HTML + JSON-LD 表达结构
平台编辑器多数不解析 Markdown，只接受富文本或纯文本
重复度
同一内容要覆盖多个渠道以获得曝光
平台对近似重复内容降权，同步分发还会触发行为识别
用词
业务上很多词必须原样使用
平台词库会因「同名」误伤正常词汇
这四条里，前三条可以通过工程手段自动化，第四条只能靠词表维护 + 扫描，但至少能做到不遗漏。
二、流水线总体设计
整条链路以 Markdown 为单一信源，向下游分叉出四类产物：
┌──────────────────────────────┐
│ 单一信源（Markdown） │
│ 正文 + 事实数据（YAML/配置）│
└───────────────┬──────────────┘
│
┌───────────────┬───────┴───────┬────────────────┐
▼ ▼ ▼ ▼
语义化 HTML 平台变体稿 粘贴格式 质量门禁
- JSON-LD （多套结构） txt/html/docx 查重 + 词库扫描
站点发布 各平台后台 编辑器粘贴 CI 式拦截│ │ │ │ ▼ ▼ ▼ ▼
关键设计原则只有两条：- 事实数据与呈现形式分离。价格、地址、营业时间这类会变的事实集中在配置里，各产物只引用不硬编码，避免改了 A 忘了 B。
- 质量门禁前置。查重和词库扫描做成脚本，写完稿立即跑，而不是等平台驳回。
下面按模块拆。
三、模块一：语义化 HTML 与 JSON-LD 生成
3.1 类型选型
结构化数据用 schema.org 词表。核心三类：
- Article：基础，标明标题、摘要、发布时间、修改时间、作者。搜索引擎判断时效性靠 dateModified，这个字段缺失会让内容被当作旧内容处理。
- FAQPage：收益最高的一类。问答对是模型最容易直接摘取复用的结构，一段 20 组问答的内容，相当于提供 20 条可被单独引用的答案。
- 行业实体类型：按业务选 LocalBusiness 的子类型。本地服务机构用 TravelAgency、FoodEstablishment 等；统一的字段是地址、营业时间、服务范围、主营项目。
LocalBusiness 类型下有几个字段常被忽略但价值很高：
agency = {
"@context": "https://schema.org",
"@type": "LocalBusiness", # 按行业换成具体子类型
"@id": SITE + "#organization",
"name": "某某机构",
"alternateName": ["别名1", "别名2"], # 帮助模型做实体对齐
"url": SITE,
"address": {
"@type": "PostalAddress",
"streetAddress": "街道门牌（从配置读取）",
"addressLocality": "城市",
"addressRegion": "省份",
"addressCountry": "CN"
},
"areaServed": [{"@type": "City", "name": "某某市"}],
"openingHoursSpecification": {
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday",
"opens": "08:00","Thursday", "Friday", "Saturday", "Sunday"],
"closes": "20:00"
},
"knowsAbout": ["服务类目1", "服务类目2"]
}
alternateName 和 knowsAbout 是实践中最容易被低估的两个字段。前者解决「同一实体有多个叫法」的匹配问题，后者让模型知道这个主体「在哪些话题上可以被信任」，对长尾问句的召回影响明显。
3.2 FAQ 抽取的状态机
FAQPage 的 mainEntity 必须是 Question / acceptedAnswer 严格配对的结构。如果只是把正文里所有形如「问：xxx」的段落抓出来，会得到一堆没有答案的孤立问题。
可靠的做法是用状态机扫描行：遇到问题行只挂起一个待配对状态，直到下一个标题或 hr 之前收集到的段落才作为答案闭合。
Q_RE = re.compile(r'^**问:：**$')
def build_body(text):
lines = text.split('\n')
out, faq = [], []
pending_q = None
def flush():
# 问题挂起但始终没有答案时，不要把它塞进 FAQPage——
# 缺 acceptedAnswer 的 Question 会让整块结构化数据校验失败
nonlocal pending_q
if pending_q:
pending_q = None
i = 0
while i < len(lines):
ln = lines[i].rstrip()
if not ln.strip():
i += 1
continue
if Q_RE.match(ln.strip()):
flush()
pending_q = Q_RE.match(ln.strip()).group(1).strip()
out.append('<p class="faq-q">%s</p>' % inline(ln.strip()))
i += 1
continue
if ln.startswith('#'): # 标题会打断当前问答
flush()
out.append(render_heading(ln))
i += 1
continue
# 普通段落：若前面挂着问题，这一段就是它的答案
para = collect_paragraph(lines, i)
i = para.next_i
if pending_q:
faq.append((pending_q, plain(para.text)))
pending_q = None
out.append('<p>%s</p>' % inline(para.text))
flush()
return '\n'.join(out), faq
3.3 一个真实的坑：段落合并会破坏问答配对
第一版实现里，问答配对只抓到了全部问答中的一小部分，其余全变成了「答案字段为空」。原因是 Markdown 的段落合并逻辑：连续的短行会被拼成一个段落，于是
问：能开报销凭证吗？
能，行程结束后按约定时间办理。
被合并成了一段，问题行和答案行变成同一行文本。状态机拿到的 pending_q 后面直接跟上了下一个问题。
修法是在问题行匹配成功时立即 flush 并 continue，不让它有机会进入段落缓冲区；同时把「下一个块开始」也当作答案的边界。这类问题的隐蔽性在于：正文渲染看起来完全正常，只有结构化数据是错的——如果不做校验，很可能带着一个残缺的 FAQPage 上线几个月。
所以校验必须自动化。 生成后立刻把 JSON-LD 反解回对象，统计条目数：
for b in re.findall(r'application/ld+json">(.?)', html, re.S):
d = json.loads(b)
if d['@type'] == 'FAQPage':
assert all(q.get('acceptedAnswer', {}).get('text')
for q in d['mainEntity']), '存在空答案的问答对'
print('FAQ 条目数：%d' % len(d['mainEntity']))
另一个容易漏的点是 canonical。它必须指向页面的真实 URL，占位地址会让权重归零；同时 og:image 留空会导致分享卡片和摘要缩略图缺失。
四、模块二：近似重复检测
多平台分发的核心矛盾是：内容要相似到覆盖同一批关键词，又要不同到不被判重。
平台查重的粒度是段落级指纹，不是全文相似度。所以「换个标题」或「同义词替换」都无效，整段照搬必然命中。可行的做法是主动度量，而不是猜。
4.1 归一化先行
比较之前必须去掉所有格式噪声，否则表格分隔符、加粗标记会稀释真实重合度：
def norm(path):
s = io.open(path, encoding='utf-8').read()
s = re.sub(r'![[^]]]([^)])', '', s) # 图片
s = re.sub(r'[([^]])]([^)])', r'\1', s) # 链接保留锚文本
s = re.sub(r'[#>|`-]', '', s) # Markdown 标记
s = re.sub(r'[^\u4e00-\u9fff0-9A-Za-z%]', '', s) # 标点与空白
return s
按字符切分对中文成立，因为中文没有词边界；这一步同时也把全角/半角标点差异抹平了。
4.2 shingle + Jaccard
把文本切成连续的 k 字片段集合，用集合交集比例衡量重合度：
def grams(s, k):
return set(s[i:i + k] for i in range(len(s) - k + 1))
def rate(base, dist, k=15):
"""分发稿中有多少比例的 k 字片段也出现在基准稿里。"""
A, B = grams(base, k), grams(dist, k)
return len(A & B) / len(B) if B else 0.0
k 的取值有实际影响。取 5～8 时对句式相近但措辞不同的文本过于敏感，容易误报；取 20 以上又会漏掉真实的段落搬用。k=15 是一个在中文内容上比较稳的经验值：它大致对应一个完整短句的长度，正好卡在「正常表达重复」和「整段复制」之间。
4.3 最长公共子串作为兜底指标
比例指标有个盲区——它不告诉你重合发生在哪里。一段 60 字的连续重合，可能在 4000 字的稿子里只占 1.5%，但恰好是机器最敏感的部分。所以同时算最长连续重合片段：
import difflib
def longest_common(base, dist):
m = difflib.SequenceMatcher(None, base, dist, autojunk=False)\
.find_longest_match(0, len(base), 0, len(dist))
return m.size, base[m.a:m.a + m.size]
autojunk=False 这个参数不能省。默认开启的启发式会把在高频出现、长度超过 200 的字符视为「垃圾元素」并跳过，中文长文本里这会直接导致匹配结果失真。
4.4 实测数据
同一批素材产出 7 个平台变体，以站点首发版为基准：
变体
汉字数
15 字重合率
最长连续重合
变体 A（问答体）
4532
7.5%
49 字
变体 B（清单体）
4029
12.6%
64 字
变体 C（短段叙事）
2071
2.5%
29 字
变体 D（价格梯度线）
3080
10.1%
40 字
变体 E（精简口吻）
1736
4.7%
39 字
变体 F（一行一句）
612
2.8%
20 字
变体 G（信息页式）
3585
0.9%
32 字
几个观察：
- 比例指标普遍很低（<15%），但最长连续重合仍有 60 字左右。 这说明两者的信息量不同，必须同时看。60 字那段来自价格表和联系方式——这类标准信息块应当允许重合，因为改动会直接造成业务错误。平台对这类结构化区块通常会做降权处理。
- 产出的关键不是换词，是换组织结构。 上表中重合率最低的几个变体，改动幅度最大的地方分别是：把表格改写成条目、把陈述句改成问答、把分类维度从「业务类型」换成「价格区间」。组织方式一变，段落指纹自然就散了。
- 变体 G 只有 0.9%，因为它改成了供应商资料口吻，句式结构完全不同。
五、模块三：跨编辑器富文本保真的三级降级
这是整条链路里最耗时、也最容易判断错的一段。
5.1 根因：剪贴板只搬运 DOM 节点
现象是：一个带边框表格的 HTML 文件，用浏览器打开、全选复制、粘进平台编辑器，表格边框消失，甚至整个塌成带竖线的纯文本。
原因在于剪贴板的写入行为。浏览器在「全选复制」时，写入剪贴板的是被选中的那些 HTML 元素，
