一份稿子的三个化身：md、网页、服务器，和一套发布对账的笨办法

卡住我的不是写稿，是写完之后：同一份稿子存成三个化身，数字、配图、结论各改各的，发布前对不上账。排查过程、等价变换表和那套对账提示词全在下面，改改就能用。

1. 起点：发布不是写作的结束

本周一给开发者大赛新疆赛区写发布稿：媒体要 md 贴编辑器，内部要网页版挂看板，外网还要发一版到服务器。一份稿子，三个化身——md 是源稿，HTML 是视觉版，服务器是分发面。

写完那天一切正常。三天后改一个数字，第二个化身改了、第三个忘了。这就是发布链路的真实形状：写作是一次性的，同步是持续性的。后来我把发布前对账固化成一个环节，靠两样东西兜底：一套等价变换规则，一份化身清单。

2. 第一个坑：对账对的是值，不是字符串

发布稿初验就演了一场假 FAIL。源报告里日期写「11.27 / 12.5 / 8.24」，我正文自然写成「11月27日 / 12月5日 / 8月24日」——对账脚本字面匹配，全部报「数字未在源材料找到」。数字明明对得上。

第一反应是把正文改回「11.27」，后来想明白不对：对账的目的是确认值一致，不是强迫字符串长得一样。「600余」和「600+」是同一个值的两种书面形态，硬统一成一种，稿子和页面总有一边要拗着写。

修法是把等价变换写进对账：日期「X月X日」附加「X.X」变体；「500+」取裸数字 500 匹配；纯个位数跳过（「L1」「件一」是噪音）。改完重跑，27 项数字对账全部落地，真对不上的会进人工核对清单——那才是需要人看的。

这个判别函数我抽出来单独用（可以直接抄）：

import re

def article_numbers(text):
    found = {}
    for m, d in re.findall(r"(\d{1,2})月(\d{1,2})日", text):
        found["%s月%s日" % (m, d)] = ["%s月%s日" % (m, d), "%d.%d" % (int(m), int(d))]
    for tok in re.findall(r"\d+(?:\.\d+)?", text):
        if "." not in tok and len(tok.lstrip("0")) < 2:
            continue  # 纯个位数是噪音
        found.setdefault(tok, [tok])
    return found

for num, vs in sorted(article_numbers(open("稿子.md").read()).items()):
    if not any(v in open("源材料.txt").read() for v in vs):
        print("需人工核对:", num)

教训一：对账比对的是值不是字符串，字符串差异先过等价变换，再进人工清单。

3. 第二个坑：删配图是四处动作，不是一处

第二次险情更隐蔽。配图里有一张理事授证照片因口径问题决定撤下，我删了网页版里的 figure 块。自检脚本扫过一遍：图片在磁盘、正文有引用，绿灯。

假的。images/ 目录里那张图还在，md 源稿的【配图】行还挂着，待确认清单里「授证照片待核」那条也还躺着——四处化身删了一处。更糟的是旧关键词「理事」还留在 HTML 图注和清单里，哪天核对的人照着清单去找一张已经撤掉的图，就是一次静默事故。

之后我立了规矩：删配图是四处动作——网页 figure、md 配图行、images/ 文件、待确认清单关联条目，删完逐处搜旧关键词，全部清零才算删干净。那条漏挂的清单条目，最后就是校验脚本帮我抓出来的。

教训二：同一事实的每个化身都列进清单，残留扫描逐化身清零，绿灯不等于干净。

4. 第三个坑：同步之前，先分清谁新谁旧

第三个坑踩得早，教训留到现在。有一次源稿被直接改了总览矩阵，六个专项扩成八个，服务器上的网页版没动。我拿着本地旧版网页去「同步」，差点把改好的内容用旧版盖回去——被当场抓到「关系图怎么没刷新」。

从那以后，同步前先做新旧判定：把 md 里新增的关键词拿到网页版里搜，缺哪补哪；网页版反而比本地新时，先从服务器拉回、在最新版上做增量修改，再推回去。还有一点：图形区块（关系图、流程图）是化身的图形态，只刷表格和正文、不刷新图，看的人照样发现旧版。顺带说清一个相邻问题——两个会话同时写服务器上同一个文件，那叫并发写覆盖，得靠改前看修改时间、改后立刻验证字段在位来防；两类事故修法不同，别混着处理。

教训三：先判谁新谁旧，再谈同步；旧版盖新版是发布链路里最贵的错误。

5. 一套可以直接抄的发布对账提示词

把三课合起来，就是我每次发布前跑的那套动作（可以直接抄）：

[发布对账员] 发布前对这篇文章执行五步：
[口径源] 每个数字对回源材料；对不上的进人工清单，裁决后写回稿子
[等价变换] 11月27日 等价于 11.27；600余 等价于 600+；超500 等价于 500+——比对取值，不比对字符串
[化身清单] 列全化身：md 源稿 / 网页版 / 服务器分发面 / images 目录 / 待确认清单
[残留清零] 删过配图或章节时，逐个化身搜旧关键词，全部清零才算删干净
[新旧判定] 同步前先 diff 新关键词定方向；服务器比本地新，先拉回再增量改，旧版永远不盖新版

6. 总结

三句话收尾。对账系统有三种失败：假 FAIL（值对字符串不对）、假 CLEAN（绿灯但化身漏删）、假同步（旧版盖新版），三种各配一个判别。等价变换表是这套流程里复用率最高的一份资产，一次写好各篇通用。发布链路的验收单位是「三个化身一致」，不是「写完了」。

写稿是把内容变对，发布是让三份拷贝同时保持对——后者才是智能体时代内容生产者的日常工程。

作者：林华鼎 · 华为云开发者发展与支持部 · 科技博主系列