重复内容处理：用户提问包含错误前提时怎样先纠正再回答
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9dcdb66cafb2.html
📄
重复内容处理：用户提问包含错误前提时怎样先纠正再回答
先把提问里的错误前提拆出来，标成“可核对的事实”，再决定是纠正后回答、还是只回答其中成立的部分。不要把错误前提当成既定事实继续往下推，否则后面的重复内容处理方案会建立在错误基础上，越做越偏。
第一步：把错误前提改写成一条可核对的事实
用户说“这两个页面内容一样，肯定会被判重复”，这里藏着一个错误前提：内容一样就等于重复内容处理问题。你要做的不是争论，而是把它改写成一条能核对的事实：这两个页面的正文是否真的高度重合、重合的是哪些段落、它们各自服务什么搜索意图。改写之后，分歧就从“是不是重复”变成“哪几段重复、重复到什么程度”，问题立刻可操作。
具体动作：把两个页面的正文复制到同一份文档里，按段落并排标记。凡是连续三段以上表达同一意思的，用<mark>式标记圈出来。结果是你会得到一张重合清单，而不是一句结论。这张清单决定下一步是合并、改写还是保留，而不是靠感觉拍板。
第二步：区分“事实分歧”和“理解分歧”
多个角色对同一事实有不同理解时，先判断分歧属于哪一类，因为处理方式完全不同。
- 事实分歧：一方说页面A已删除，另一方说还能访问。这类分歧靠核对解决，谁对谁错有客观答案。动作是让双方各自给出可复查的依据，比如页面状态截图或访问记录，而不是继续口头争论。
- 理解分歧：双方都承认页面内容重合，但对“算不算重复内容处理问题”判断不同。这类分歧没有唯一答案，取决于目标意图。动作是把判断标准写下来，比如“若两页面向同一搜索意图且正文重合超过一半，则视为需要处理”，让标准先统一。
把这两类混在一起谈，讨论会一直打转。先分类，再分别处理，是让分歧转为可核对项目的关键一步。
第三步：用一条假设例子验证处理方向
假设你手上有两个页面，都在讲同一款工具的安装步骤，正文重合约六成，但一个面向新手、一个面向排错。这是一个假设场景，用来演示比较方法，不是真实项目结论。
此时有两种成立的选择：
- 合并：如果两页搜索意图一致，且重合部分正是核心内容，合并成一页更清晰。动作是把排错部分作为独立小节并入新手页，然后处理旧地址的跳转。结果是维护成本下降，但需要确认没有外部链接依赖被合并的那一页。
- 保留并差异化：如果两页意图确实不同，保留但重写重合段落。动作是把新手页的重合部分改成操作导向，把排错页改成症状导向。结果是两页各有侧重，但需要持续检查它们是否又逐渐趋同。
判断依据不是“重合多少算多”，而是“两页是否服务同一个搜索意图”。意图相同就合并，意图不同就差异化。这个判断会直接决定你下一步是写跳转规则还是写改写清单。
第四步：把结论落成可执行的处理方案
纠正错误前提之后，你要给出一份能直接执行的处理方案，而不是停留在“确实有重复”这个结论上。方案至少包含三项：
- 处理对象：具体是哪几个页面、哪几段重合。
- 处理方式：合并、改写、保留还是删除，并写明理由对应的是哪条判断标准。
- 验证动作：处理完成后，用什么方式确认问题已解决，比如重新核对重合清单是否清空。
如果用户原本的前提是“重复内容一定会被惩罚”，纠正后的回答应该是：重复内容处理的核心不是躲避惩罚，而是让每个页面有独立价值。这个转向会让后续动作从“删到不重复”变成“改到各有用途”，方向更稳。
什么时候不该急着纠正
有一种情况要先回答再纠正：用户的错误前提不影响当前决策，且纠正会打断紧急处理。比如对方只想知道某个页面要不要先下线，你可以先给出下线动作，再补充说明“重复判断标准需要另外核对”。
反过来，如果错误前提会导致后续动作全错，比如基于“所有重复都必须删除”去批量删页，那就必须先纠正再回答。判断标准很简单：这个前提错了，下一步动作会不会伤到不该动的内容。会，就先纠正；不会，可以边做边校准。
把分歧转成可核对的项目，本质上就是让每个人对着同一份清单说话。清单越具体，争论越少，重复内容处理才真正可执行。
