aso优化：平台功能改名后旧教程如何保留可理解性
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f8a683852ac9.html
📄
aso优化：平台功能改名后旧教程如何保留可理解性
旧教程能否继续用，取决于它是在讲"按钮在哪"还是"用户要完成什么"。前者会随改名失效，后者只需补一句新旧名称对照。假设你运营一款记账应用，商店页里的"预算提醒"被平台改叫"智能预算"，你手上有一篇讲"如何设置预算提醒"的旧教程，这就是本文要处理的情境。
先判断旧教程依赖的是位置还是意图
把教程里的每一句操作拆成两类。第一类绑定界面：点击某个标签、进入某个二级菜单、看到某个图标。第二类绑定用户意图：想让用户在超支前收到通知、想区分固定支出和弹性支出。改名只破坏第一类，不破坏第二类。判断方法很直接：把教程里所有出现的功能名划掉，剩下的句子如果还能说清"用户为什么做这一步"，这篇教程就属于可救的；如果划掉之后整段变成空白，说明它从头到尾只是界面复述，需要重写而不是修补。
这个判断必须在改名生效后立刻做，因为平台通常不会长期保留旧入口。拖延的代价是用户按旧教程找不到入口，转而给差评或卸载，而你无法确定差评来自产品本身还是教程过期。
假设情境：一篇教程的三种处理结果
假设你的记账应用有二十篇帮助文档，其中八篇提到"预算提醒"。改名后你逐篇检查，会得到三种结果。
- 第一种，教程标题和首句都写"预算提醒"，但正文讲的是"设置一个金额上限，超过时收到通知"。这种只需改标题和首次出现的名称，正文动作不变。
- 第二种，教程写"点击底部第二个标签，找到预算提醒开关"。改名往往伴随入口调整，这类教程的路径描述整体作废，需要重新截图并重写步骤。
- 第三种，教程把"预算提醒"当成一个功能名词反复解释它是什么，而不是教用户做什么。这种最麻烦，因为改名后连概念都对不上，只能重写。
三种结果对应三种工作量，先分类再动手，比逐篇改字快得多。分类完成后，第一种当天可改完，第二种需要重新走一遍流程，第三种要排进内容重写队列。
保留可理解性的具体做法：新旧名称对照加意图句
对第一种和第二种教程，最小改动是在首次出现旧名称的位置加一句对照，例如"预算提醒（现称智能预算）"。这句话的作用不是解释改名原因，而是让按旧名称搜索进来的用户确认自己找对了地方。同时把教程的第一句从功能名改成意图句，比如把"预算提醒怎么开"改成"如何让应用在超支前通知你"。
做完这一步后，观察两个信号。一是站内搜索词：如果仍有用户搜旧名称，说明对照句有必要保留；如果搜索词已经切换到新名称，对照句可以逐步删除。二是教程页的跳出情况：如果用户在前三十秒离开，可能是对照句没放在足够靠前的位置，而不是内容本身有问题。这两个信号都只是线索，不能单独证明改动正确，因为跳出也可能来自页面加载或用户本来只想扫一眼。
规模化后不能照搬的边界
单篇教程加对照句有效，不代表二十篇都这么处理。当改名涉及的功能出现在多个教程、且这些教程互相引用时，逐篇加对照会造成同一句话重复出现，用户读到第三遍会开始怀疑自己看的是不是同一版本。此时更合适的做法是建一个独立的名称对照说明，教程内只保留一次指向它的链接。
另一条边界是平台推荐和站内搜索的区别。教程页在站内搜索里被搜到，靠的是标题和正文是否匹配用户输入的名称；而如果教程被放进应用的推荐位或更新公告，用户是被动看到的，对照句的价值下降，更需要直接使用新名称。把这两种分发场景当成一回事，会导致你在推荐文案里保留旧名称，反而让用户以为功能没更新。
最后一条边界关于时间。改名初期保留旧名称有助于老用户过渡，但如果旧名称已经停用很久，继续保留会让新用户困惑。判断依据不是过了多少天，而是旧名称在站内搜索里是否还有真实请求。请求归零也不能立刻断定可以删除，因为用户可能已经改用新名称，也可能干脆放弃搜索直接联系客服，这两种情况的处理方式不同。
可执行的动作顺序
- 改名生效后，列出所有提到该功能的教程，按"仅名称""名称加路径""概念解释"三类归档。
- 对前两类，在首次出现处加新旧对照，并把首句改成意图句。
- 对第三类，排入重写，不要试图用加括号的方式修补。
- 改动上线后，观察站内搜索词和教程页停留情况，据此决定对照句保留多久。
- 当同一对照句在多个页面重复出现时，抽出一个独立说明页，其余页面改为指向它。
这套顺序的核心是把"改名"当成一次内容分类任务，而不是一次全局替换。替换只能解决字面问题，分类才能决定哪些教程值得修、哪些必须重写，以及修完之后拿什么信号判断下一步该删还是该留。
