网站内容采集多个相近页面怎样分工：别把同义词换写当成不同页面
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /49011d9b6207.html
📄
网站内容采集多个相近页面怎样分工：别把同义词换写当成不同页面
多个相近页面不能靠把同一段内容换几个同义词来分工，而要先判断它们各自承担什么任务：是覆盖不同搜索意图、服务不同使用场景，还是仅仅重复同一信息。如果任务相同，应合并成一个页面；如果任务不同，再按意图边界拆分，并让每个页面有独立的标题、开头结论和例子。
常见误解：相近主题就得多做几个页面
多人协作时，最容易出现的做法是：一个人先写主页面，另一个人把主页面里的词替换成近义词，再发一个“更细分”的页面。这样看起来分工清楚，实际上两个页面回答的是同一个问题，用户点进去得到的结论几乎一样。结果往往是内部页面互相竞争，编辑之间反复改稿，交付时也说不清谁负责哪一块。
问题不在于页面数量，而在于每个页面有没有独立的任务。如果两个页面都回答“网站内容采集怎么做”，那它们就不该同时存在。真正需要拆分的情况是：用户带着不同的前置条件来，需要不同的判断标准或操作步骤。
先按搜索意图分，而不是按词形分
判断两个相近页面能否共存，可以看三个检查项：
- 用户要解决的问题是否相同。如果都是“怎么采集”，只是说法不同，应合并。
- 用户的前置条件是否不同。例如一个人要采集自己有权使用的内容，另一个人要判断采集他人内容是否合规，这是两种任务，可以拆。
- 交付结果是否不同。一个页面给出操作步骤，另一个页面给出判断清单，分工才算成立。
假设你负责一个关于内容整理的专题，已有页面讲“网站内容采集的基本流程”。现在要新增一个页面，如果新页面只是把“流程”换成“步骤”“方法”“做法”，那它不应该独立存在。如果新页面专门讲“采集前如何确认内容使用边界”，它服务的是另一个决策点，可以独立，但要在开头明确它不重复基本流程。
多人协作时，用一张分工表固定边界
减少返工的关键不是多开会，而是让每个页面在动笔前就写清边界。可以用下面这张最小分工表，每行对应一个页面：
- 页面任务：用一句话写“这个页面帮用户做什么决定”。
- 不写什么：列出容易混进来的相邻内容，明确交给哪个页面。
- 开头结论：第一段直接回答本页问题，不铺垫。
- 独有例子：至少一个只属于本页的场景或检查项。
- 内部指向：需要继续看相邻问题时，指向哪个页面。
例如两个页面的分工可以这样写：A 页任务为“判断某类内容能不能采集”，不写具体采集工具操作；B 页任务为“采集后如何整理字段”，不重复合规判断。这样两个人同时写，也不会把同一段话搬来搬去。
合并还是拆分，看一个简单测试
把两个相近页面的开头结论各读一遍。如果读者只看这两段，无法说出“我该去哪个页面”，就说明分工失败，应合并或重写。如果读者能明确说出“我先看 A 判断能不能做，再看 B 知道怎么做”，拆分才有意义。
另一个测试是看例子。如果两个页面的例子可以互换而不影响理解，说明它们回答的是同一件事。真正分工清楚的页面，例子往往不能互换：一个例子围绕判断条件，另一个例子围绕操作顺序。
交付前检查：三个页面边界是否清楚
在多人协作中，交付前可以让每个页面的负责人回答三个问题：这个页面替用户做了什么决定？哪部分内容明确不属于本页？如果用户不需要本页，应该去哪里？三个问题都能用一句话回答，页面边界才算清楚。回答不了，就先别继续扩写，回到分工表修改任务描述。
下一步，挑出你手上最相近的两个页面，各写一句“本页帮用户做的决定”。如果两句话意思相同，就合并；如果不同，再检查它们有没有各自独有的例子和检查项。
