添加关键词方法，产品文档改版后旧文章哪些引用需要更新
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28df6d5a1c95.html
📄
添加关键词方法，产品文档改版后旧文章哪些引用需要更新
改版后要更新的不是所有出现旧术语的句子，而是那些会让读者做出错误动作的引用。判断标准可以压成一条：读者顺着这句话去操作，会不会得到与新版产品不一致的结果。会，就必须改；不会，只是读起来旧，可以排进低优先级队列。下面按这个标准，把一篇旧文档拆成可执行的处理清单。
先给旧文里的引用分三类
拿一篇旧文章，把其中指向产品其他部分的表述逐条圈出来，分成三类。
- 动作型引用：告诉读者去点某个入口、填某个字段、按某个顺序操作。改版后入口位置、字段名称、步骤顺序变了，这类引用会让读者卡住或做错，必须更新。
- 概念型引用：解释某个术语、机制或限制条件。改版只改了界面，没改机制，这类引用可以保留，但要检查术语是否已经改名。
- 装饰型引用：截图、旧版菜单名、举例里出现的按钮文字。它们不影响读者完成动作，可以最后处理，甚至只换图不换文。
分类完成后，优先处理动作型。一个可操作的检验方法是：把这句话单独发给一个不熟悉旧版的同事，让他照着做一遍。他做不下去的位置，就是必须改的位置。这个动作的结果会直接决定下一步：如果动作型引用超过全文引用的三分之一，说明这篇旧文已经不适合局部修补，应该考虑重写或合并；如果只是零星几处，逐个替换即可。
规模化之后，局部替换会开始失效
单篇文档里替换几个入口名称，看起来很简单。但当成百篇旧文都引用同一批入口时，逐个替换会暴露两个问题。
第一，同一个旧说法在不同文章里被写成了不同版本，替换时你会不确定哪个才是新版标准叫法。第二，有些引用藏在示例、注释和代码片段里，正文搜索能命中，代码块里的注释却容易被漏掉。
这时候需要先建立一份对照表，而不是直接开改。对照表至少包含三列：旧表述、新表述、影响范围。影响范围可以粗分为“仅本文”“多篇共用”“全站通用”。全站通用的那一类，先改被引用最多的那篇源头文章，再让其他文章指向它，而不是把新说法复制到每一篇里。这样做的好处是，下次再改版时只需要动一处。
边界也要说清楚：如果旧文本身已经不再被任何新版文档链接，也没有站内入口指向它，那么它的引用优先级可以降到最低，甚至只做归档标记。不要因为“看起来旧”就投入同等精力。
用一段假设例子走完判断流程
假设某产品把设置页里的“通知渠道”改名为“消息通道”，同时把原来的三个选项合并成两个。旧文里出现三处相关表述：一处是正文说“进入通知渠道，勾选邮件和短信”，一处是截图里的菜单名，一处是文末示例代码的注释写着“# 配置通知渠道”。
按前面的分类：正文那处是动作型，因为读者照着做会发现选项对不上，必须改；截图是装饰型，可以换图或加一句“界面以实际版本为准”；代码注释是概念型偏装饰，如果它不影响代码运行，可以后改，但如果读者会复制这段代码去改配置，它就会变成动作型，需要同步。
处理顺序是：先改正文动作型，再决定截图是否值得重拍，最后处理注释。改完之后，把这篇旧文加入一个待观察列表，下次产品再改版时优先检查它，而不是重新全站扫描。这个动作把一次性的批量替换，变成了可延续的检查点。
哪些引用可以明确不动
不是所有旧引用都值得更新。以下情况可以保留：
- 文章本身已经标注为历史版本，且读者被引导到新版文档。
- 引用的是产品底层概念，改版没有改变其含义，只是换了呈现方式。
- 引用出现在“旧版对比”或“迁移说明”语境里，保留旧说法反而有助于读者理解变化。
反过来，如果一篇旧文没有任何历史版本标记，又持续从导航或搜索结果进入，那么它的动作型引用就不能拖。判断依据不是文章发布时间，而是它现在是否还在承担引导读者操作的角色。
把判断转成可执行的处理方案
对读者手中的那篇旧文，可以按下面顺序操作：
- 通读一遍，圈出所有指向产品其他部分的引用。
- 逐条标注动作型、概念型或装饰型。
- 只对动作型引用做“照着做一遍”的检验，记录卡住的位置。
- 如果动作型引用集中在少数几处，直接替换并更新截图；如果分散且数量多，先建对照表，再决定重写还是合并。
- 改完后，把这篇文加入一个短名单，下次改版只检查短名单，而不是全站重扫。
这套流程不承诺任何收录或排名结果，它只解决一个具体问题：让旧文里的引用不再把读者带向错误操作。判断的落脚点始终是读者的下一步动作，而不是术语新旧本身。
