网站内容采集，一篇文章过长时按用户任务还是概念拆分
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a3041a6d19bb.html
📄
网站内容采集，一篇文章过长时按用户任务还是概念拆分
优先按用户任务拆分，只有当读者必须先建立一组彼此依赖的概念才能完成任务时，才按概念拆分。判断依据不是文章字数，而是读者读完一段后能否独立完成一个动作；如果每段都指向同一个动作的不同环节，按任务拆成多篇更容易被找到和使用；如果多个概念互相定义、缺一不可，硬拆会制造理解断点，此时应保留在同一篇内，用清晰的层级组织。
先判断读者是否带着一个可完成的任务进来
把文章开头读者最可能的目标写成一句话，例如“把旧系统里的联系人导出并迁移到新系统”。如果这句话里包含明确的输入、动作和结果，说明读者是任务驱动。此时按任务拆分，每篇只解决一个可验收的动作，读者不需要读完所有篇才能动手。
反过来，如果读者的目标只是“理解这套分类体系为什么这样设计”，输入和结果都不明确，说明他需要的是概念地图。概念之间互相引用，拆开后每篇都要重复定义，读者反而要在多篇之间来回跳。这种情况下不拆，改为在同一篇内用小节标题标出概念层级。
按任务拆分的实施动作与结果
假设一篇旧文原本覆盖“导出、清洗、导入、校验”四个环节。按任务拆分时，先为每个环节写一句完成标准，再决定哪些环节合并。例如导出和清洗可以合并，因为清洗依赖导出结果的格式；导入和校验可以合并，因为校验要在导入后立即执行。拆分后的每篇开头直接给该环节的前置条件和完成标志。
这个动作的结果是：读者从搜索进入某一篇后，能判断自己是否处在正确环节，并知道下一步该去哪篇。如果拆分后发现某篇缺少独立的前置条件，说明它不该单独成篇，应并回相邻任务。
按概念拆分的适用条件与操作
当一组概念构成定义链，例如“采集范围”依赖“数据边界”的定义，“数据边界”又依赖“权限模型”的说明，拆开会让每篇都变成不完整的定义。此时保留长文，但要做三件事：在开头列出概念依赖顺序；每个概念小节末尾用一句话指向下一个概念；把可独立执行的操作步骤单独抽成任务篇，并在概念篇里链接过去。
这样处理的结果是：概念篇承担解释和判断依据，任务篇承担操作和验收。读者如果只想动手，可以直接跳到任务篇；如果卡在判断上，再回到概念篇补定义。例外情况是，如果概念篇超过读者一次能消化的范围，且每个概念都有独立的外部依据，可以拆成系列，但必须在每篇开头注明前置概念，避免读者从中间进入。
用旧内容退出场景检验拆分是否成立
旧内容、旧系统或旧合作关系需要退出时，拆分决策还要多一层：保留仍然有价值的部分。具体动作是，把原文中依赖已退出系统或已终止合作的段落标出来，这些段落不应作为独立任务篇保留，而应合并成一篇“历史说明”或直接删除；只把与当前任务仍然一致的操作步骤拆出来，并更新前置条件。
假设一篇旧文讲的是从旧版后台导出数据，旧后台已经停用，但导出后的字段清洗规则仍然适用于新后台。此时不应把整篇按任务拆成“旧后台导出”“字段清洗”两篇，而应删除旧后台操作部分，保留字段清洗并补上新后台的导出前提。结果是读者不会进入一篇无法执行的操作文，同时仍然能用到有价值的清洗规则。
可区分两种选择的证据清单
- 读者搜索词里是否包含动作动词，如导出、迁移、校验；包含动作词偏向按任务拆分。
- 文章内部是否出现“要理解这一点，先要知道……”的依赖句；依赖句多偏向按概念保留。
- 拆开后每篇是否都有独立的前置条件和完成标志；没有则说明拆错了层级。
- 旧内容中依赖已退出系统或合作的部分是否超过一半；超过时先做退出处理，再谈拆分。
最后，拆分不是一次性决定。发布后观察读者是否在某一篇反复回到另一篇补前提，如果是，说明拆分点选在了概念依赖上，应把两篇合并或调整链接位置；如果读者只读一篇就能完成任务，说明按任务拆分成立。判断依据是读者的行为路径，而不是文章字数或段落数量。
