二类电商推广：平台功能改名后旧教程如何保留可理解性
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4b6553c798de.html
📄
二类电商推广：平台功能改名后旧教程如何保留可理解性
旧教程不必推倒重写，更实用的做法是保留原文，在每处旧功能名旁补一层“现在叫什么、当时指什么、按哪一步操作”的对照说明。判断标准不是名字新旧，而是读者能否据此完成同一个动作。下面用一个假设情境说明取舍。
先判断旧教程是“名字过时”还是“逻辑失效”
假设你手上有一份半年前的二类电商推广投放教程，里面写到在某个后台的“计划列表”里调整出价。现在后台把这一栏改叫别的名字，但分组、预算、出价之间的关系没有变。这种情况下，教程的主体逻辑仍然成立，失效的只是入口名称。
反过来，如果改名的同时，原本的层级被拆开，或者某个设置从必填变成由系统自动处理，那就不是补一句对照能解决的，需要重写该步骤。区分方法很简单：让一个没看过旧版后台的人按教程走一遍，看他是卡在“找不到按钮”，还是卡在“找到了也不知道该填什么”。前者补对照即可，后者必须重写。
给旧功能名加一层对照，而不是直接替换
直接全局替换成新名字，看似干净，实际会制造新的理解断层：老读者记得旧叫法，新读者看到的教程与自己的后台截图对不上。更稳的做法是保留旧名，在后面用括号补上新名和判断依据。
可以按这个顺序处理每一处旧名称：
- 标出旧名第一次出现的位置，补一句“该入口后来更名为××，功能范围是否变化需以当前后台为准”。
- 在涉及操作步骤的段落，把“点击旧名”改成“找到当前承担同一职责的入口（旧称××）”。
- 如果新旧功能范围不一致，单独用一段说明差异，不要塞进括号里。
这样处理的结果是：读者不需要先记住一套新词汇，也能顺着旧教程的叙述找到对应位置。下一步再决定是否把高频步骤单独整理成新版，而不是一次性重写全部内容。
用“动作是否可达”检验改写是否合格
改完之后，不要只检查术语是否统一，而要检查动作链是否完整。一份合格的旧教程，读者应该能回答三个问题：这一步在解决什么、在哪个入口完成、完成后下一步看什么指标。
假设教程原文写“在旧入口把预算调到目标值，然后观察消耗速度”。改名后如果只把“旧入口”换成新词，读者仍可能不知道新入口是否还包含原来的预算设置。这时应补一句限定：“若当前入口不再提供预算设置，则预算可能已上移到上一层，需先确认层级再操作。”这句话的作用不是给出确定答案，而是把读者引向正确的核对位置。
需要说明的是，后台改名、入口迁移这类现象，往往同时存在多种解释：可能是产品整合，也可能是你看到的样本账号与多数账号不一致。个别账号里旧入口还在，不代表所有账号都能照旧操作；反过来，一个账号里入口消失，也不能单独证明该功能已对所有账号下线。写教程时应把这种不确定性写进去，而不是替读者下结论。
哪些内容必须重写，哪些可以只加注
可以只加注的：入口名称变化、菜单层级微调、同一功能换了展示位置但字段含义未变。这类改动保留旧教程原文，加对照说明即可，成本低且对老读者友好。
必须重写的：原本的必填项变成自动判断、多个步骤被合并成一步、数据口径发生变化（例如原来按支付口径统计，现在展示的是另一个口径）。口径变化尤其危险，因为读者按旧教程算出的结果会与新后台对不上，却未必意识到是口径问题。遇到这种情况，应在教程开头显式标注适用时间段，并说明旧口径与新口径各自适合回答什么问题。
最后给一个可执行的收尾动作：在旧教程顶部加一个不超过三行的状态说明，写清它基于哪个时期的后台、哪些步骤已核对、哪些步骤需要读者自行确认。这个动作不会让旧教程变成新教程，但能让读者在动手前就知道边界在哪里，从而决定是照着做还是先去找更新版本。
