怎样建博客：把重复说明提取到公共页面时怎样保留上下文
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f4ac88a85c88.html
📄
怎样建博客：把重复说明提取到公共页面时怎样保留上下文
可以提取，但前提是这段说明在不同页面承担的判断作用相同；一旦它需要结合页面自身条件才能理解，提取后就必须在原位保留一句承接语和指向公共页面的链接。缺少完整数据或权限时，最小可执行动作是先选一组结构最接近的页面做试点，观察原页面段落被替换后的可读性，再决定是否扩大范围；这个动作只能说明试点页面的表现，不能证明全站都适合提取。
先判断这段重复说明是事实块还是判断块
事实块是放之各页都成立的内容，例如同一项服务的通用定义、同一套流程的固定步骤。判断块则依赖页面条件，例如“本方案适合预算有限的团队”这类表述，离开原页面的产品范围、地区或阶段就容易失真。提取的对象应优先是事实块；判断块即便文字重复，也应在公共页面保留条件分支，而不是只留一段统一结论。
一个可操作的区分方法是：把该段文字单独复制到一个空白文档，遮住原页面标题和上下文。如果读者仍能准确理解它在说什么，适合提取；如果读者会追问“对谁、在什么条件下”，说明它需要上下文才能成立。
提取后保留上下文的三个位置
公共页面负责完整说明，原页面负责承接和限定，链接负责把两者连起来。具体可以这样安排：
- 原页面保留一句短承接，说明这里讨论的是什么问题，再链接到公共页面，例如“关于这项流程的通用步骤，见公共说明页”。
- 公共页面开头交代适用范围，把原本分散在各页的条件集中列出，避免读者把通用说明当成对自己场景的承诺。
- 原页面如有页面特有的参数、限制或例外，继续留在原位，不要一并搬走；这些内容一旦搬走，公共页面会变得含糊，原页面也会失去判断依据。
这样处理的结果是：读者从原页面进入公共页面时，知道自己在读的是通用部分；回到原页面时，仍能看到只适用于该页的条件。下一步是否继续提取其他段落，取决于读者能否在不返回原页面的情况下理解公共页面的内容。
缺少完整数据和权限时的最小动作
没有全站内容清单、没有模板修改权限，也可以先做一件事：挑三到五个结构最接近的页面，手动把重复说明替换为承接语加链接，公共页面同步补上适用范围。观察一周内这几个页面上的读者路径是否还顺畅，例如承接语是否被点击、原页面是否出现理解断层。
需要说明的是，点击少或停留短不能单独证明提取失败，也可能是入口位置、页面本身需求变化或采集口径差异造成的。反过来，点击多也不能证明提取正确，只能说明链接被注意到了。这个动作的价值在于暴露承接语写得是否清楚，而不是给出全站结论。
一个会让结论失效的反例
假设某段重复说明在原页面里紧跟在价格或规格之后，读者是靠前后文理解它的。提取到公共页面后，原页面只剩一句承接语，读者可能误以为公共页面里的通用条件也适用于当前价格或规格。此时提取不但没有减少重复，反而制造了新的误解。
这个反例说明：重复文字是否适合提取，不取决于它出现了多少次，而取决于它是否与页面局部条件绑定。绑定越紧，越应该保留在原位，公共页面只承担补充说明的角色。
下一步动作与不能推出的结论
如果试点页面的承接语能独立说清问题，且公共页面补上了适用范围，就可以把同一类事实块扩展到结构相似的页面；如果试点中出现理解断层，应先改写承接语，而不是继续扩大提取范围。每次改动前后比较要考虑季节、搜索需求变化和数据采集差异，不能把一次波动直接归因于提取动作。
最后要记住：提取重复说明的目标是让读者更快找到完整解释，而不是让页面看起来更短。缺少完整数据时，先做小范围试点、保留原位条件、记录承接语效果，比一次性全站替换更稳妥。
