先给结论:如果这篇长文要承接的是“读者带着一个明确动作来、中途会停、停完还要回来继续”的场景,按用户任务拆分;如果读者需要先建立一套判断标准,再拿这套标准去比较多个对象,按概念拆分。判断依据不是字数,而是读者读完前半段后会不会立刻去执行,以及执行完是否还需要回到原文。
条件一:读者进入页面的意图是“解决一个具体麻烦”,比如发帖前想确认标题怎么写、发完被删想判断原因。这类意图天然带顺序,动作之间有依赖,拆成任务单元后每个单元都能独立收尾。条件二:读者进入页面的意图是“先弄懂一类判断逻辑”,比如什么样的论坛软文推广内容会被版主视为广告、什么情况下软文反而适合放在回复区。这类内容的核心是标准之间的比较,拆成任务单元会切断推理链。
两种条件同时存在时,优先看哪个条件决定页面能否被继续使用。如果读者看完一段就离开去操作,操作结果决定他是否回来,按任务拆;如果他必须读完整套标准才能做第一个判断,按概念拆。
任务拆分的单位不是“写帖”“回帖”这种宽泛动作,而是“动作 + 完成信号”。例如:
这样拆的好处是每个小节都能单独回答“我下一步做什么”。实际操作时,把每个任务小节的最后一句写成下一步动作,比如“确认版规后,再决定标题里是否保留行业词”。如果读者按这句话执行后发现版规不允许,他会回到上一节调整,而不是从头重读全文。
例外:如果任务之间共享同一套前提,拆开后每个小节都要重复一遍前提,读者会感到啰嗦。这时把共享前提单独写成一节,任务部分只写差异动作。
概念拆分的单位是“一个判断维度 + 它排除的误判”。例如,判断一段论坛软文推广内容是否会被当作广告,可以拆成:
这三个维度之间没有先后依赖,读者可以任意顺序阅读,最后合起来形成判断。概念拆分适合那些读者会拿标准去比较不同论坛、不同版块或不同内容类型的场景。如果强行按任务拆,读者会先看到“怎么发”,但还没有标准判断“该不该发”,执行后容易返工。
一个假设例子:某业务同时运营两个论坛账号,一个账号用于回答具体问题,另一个账号用于发布行业观察。前者适合按任务拆,因为读者要的是操作步骤;后者适合按概念拆,因为读者要的是判断这类观察是否可信。把两者混在同一篇长文里,任务部分会显得像操作手册,概念部分又像评论,读者很难决定从哪段开始。
无论按哪种方式拆,拆完都要检查一件事:读者执行完当前小节后,是否知道回到哪里继续。按任务拆时,返回路径是“上一节的前提是否仍然成立”;按概念拆时,返回路径是“下一个判断维度是否需要用前一个维度的结论”。如果返回路径不存在,说明拆分点选错了。
具体动作:在每个小节末尾加一句指向下一步的短句,但不要写成目录式链接堆叠。比如任务拆分后写“确认版规允许后,再处理标题”,概念拆分后写“用同样三个维度看另一个版块,结论可能不同”。这句话的作用是让读者知道当前小节已经结束,而不是把长文切成互不相关的碎片。
如果检查后发现两个小节之间既没有动作依赖,也没有概念依赖,考虑合并或删除其中一节。过长的文章被拆开后,真正的问题往往不是拆得不够细,而是有些段落本来就不该出现在同一篇里。
原本按任务拆的文章,如果论坛版规发生变化,比如从允许签名引导变为完全禁止,原来的任务链会断掉。这时不要继续在旧任务上加补丁,而是回到概念层,先重新判断“什么内容在这个版块仍然可以被接受”,再按新标准重建任务小节。反过来,原本按概念拆的文章,如果业务从“让读者理解判断标准”变成“让读者完成一次具体发布”,概念部分可以压缩成前提,任务部分必须补上完成信号。
判断前提是否真的变了,看一个证据:读者读完前半段后的行为是否改变。如果以前读完会直接去发帖,现在读完先去查版规,说明前提已经变了。这时按用户任务拆分更稳,因为读者需要的是在新前提下重新走一遍动作链,而不是继续比较旧标准。