如何建自己的博客，把重复说明提取到公共页面时怎样保留上下文
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fa73715871b8.html
📄
如何建自己的博客，把重复说明提取到公共页面时怎样保留上下文
直接回答：把重复说明提取到公共页面时，保留上下文的关键不是把原文复制过去，而是让公共页面承接“定义与前提”，让原页面保留“使用场景与判断依据”。如果公共页面只写通用定义，原页面又只留一句“详见某页”，读者在两个页面之间都得不到完整答案，提取反而制造了新的断点。
先看一个矛盾现象：提取后两边都变薄了
假设你运营一个技术博客，多篇文章都在重复解释“什么是缓存失效”。你决定把它抽到一个公共页面，原页面改成链接。上线后可能出现两种相反反馈：一类读者说公共页面讲得清楚，另一类读者说原页面读不懂了。这不是谁对谁错，而是两类页面承担的任务不同。
公共页面适合回答“这个概念是什么、成立条件是什么、有哪些常见误解”。原页面适合回答“在这篇文章的具体场景里，为什么选这个方案、放弃另一个方案”。把定义抽走没问题，把选择理由也抽走，原页面就只剩结论，读者无法判断这个结论是否适用于自己。
两种解释，以及能区分它们的证据
解释一：公共页面缺少适用边界
如果公共页面只写通用定义，没有写“在什么条件下成立、什么条件下不成立”，那么从不同文章跳进来的读者会带着各自的场景读同一段话，理解自然分叉。可核对的证据是：把公共页面发给三到五个不同角色的读者，让他们各自说出“这段话在我的场景里是否适用”。如果多数人答不上来，说明缺的是边界，不是定义。
解释二：原页面丢掉了判断依据
如果公共页面写得足够完整，但原页面删掉了“为什么这里选它”的推理，读者仍会卡住。可核对的证据是：只看原页面、不点链接，能否复述出选择理由。如果复述不出来，问题出在原页面，而不是公共页面。
区分这两种解释的实际动作：先不要改公共页面，只把原页面被删掉的那几句判断依据补回去，观察读者反馈是否变化。如果补回后问题消失，说明此前是原页面上下文缺失；如果问题依旧，再检查公共页面的适用边界。这个顺序能避免你在错误的页面上反复返工。
提取时保留上下文的具体做法
把重复说明拆成三层，分别决定放在哪里：
- 定义层：概念是什么、边界在哪里，放公共页面，只写一次。
- 场景层：这篇文章里的具体前提，留在原页面，用一两句话交代“本文讨论的是哪种情况”。
- 判断层：为什么在这个场景里选它、放弃了什么，留在原页面，这是最容易被误删的部分。
原页面链接公共页面时，链接文字要说明读者过去能得到什么，例如“缓存失效的成立条件与常见误解”，而不是“点击这里”。这样即使读者不点，也知道缺口在哪、是否值得点。
一个假设的短例子
假设你有两篇文章都讲“图片压缩”，重复段落约三百字。你把定义和格式对比抽到公共页面，原页面各留一句场景说明。文章 A 的前提是“面向移动端首屏”，文章 B 的前提是“面向归档存储”。如果两篇都只留“详见公共页面”，读者无法知道压缩参数该按哪个前提取。正确做法是 A 保留“首屏可接受更大压缩损失”的判断，B 保留“归档优先保真”的判断，公共页面只负责解释格式差异本身。
做完这一步后，下一步不是立刻批量提取其他重复段落，而是先用同样方法处理一处，确认读者能只看原页面完成决策，再决定是否扩大范围。一次改动前后的对比要谨慎解读：搜索需求本身会随季节波动，数据采集口径也可能变化，流量或抓取量的升降不能单独证明提取做对了。
多人协作时怎样把分歧变成可核对的项目
当多个角色对同一事实理解不同，先别争论谁对，把分歧写成可核对的条目：这条说明属于定义层、场景层还是判断层；它当前放在哪个页面；删掉后哪类读者会受影响。每条都指定一个能验证的动作，例如“让不熟悉该项目的人只读原页面，复述选择理由”。
验证结果决定下一步：能复述，说明上下文保留足够，可以继续提取下一处；不能复述，先补判断层，不要急着改公共页面。这样提取重复说明就不再是一次性删减，而是一个可以逐条核对、逐步推进的过程。
