产品文案撰写，一篇文章过长时按用户任务还是概念拆分
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /735a89adb016.html
📄
产品文案撰写，一篇文章过长时按用户任务还是概念拆分
优先按用户任务拆分，只有当同一任务下存在多个必须分别理解、否则会误用的概念时，才按概念拆。判断依据不是文章现在有多长，而是读者带着什么目标进来、在哪一步会离开。若一个页面能同时回答“我该选哪种”和“具体怎么操作”，且两步之间没有需要独立解释的前提，就不必拆。
先看读者是来完成任务还是来建立理解
任务型读者通常有明确的下一步动作，例如比较、配置、申请、替换或排除故障。他们关心的是条件、顺序和结果。概念型读者则还没有确定动作，需要先弄清几个术语之间的关系，再决定要不要行动。
如果文章的主体是步骤、判断条件、选择依据，按任务拆分更稳。每个页面围绕一个可完成的目标组织，读者读完能进入下一步。若文章的主体是定义、边界、分类和常见误解，且这些概念会被后续多个任务反复引用，按概念拆分更合适，便于分别维护和链接。
一个可操作的检验方法：把文章里每个小标题改写成读者可能的提问。若多数提问以“怎么”“要不要”“选哪个”开头，偏任务；若多数以“是什么”“有什么区别”“为什么不算”开头，偏概念。
按任务拆分的适用条件与代价
按任务拆分成立的前提是：每个任务有独立的触发场景，读者不会在同一个页面里同时需要两个任务的全部内容。比如同一产品的安装、迁移和故障排查，读者通常只处于其中一种状态。
这样拆的好处是标题和摘要更容易对应真实意图，页面之间的内链也更有方向：从选择页指向操作页，从操作页指向排错页。代价是任务之间可能共享同一段背景说明，需要决定这段说明放在哪里，避免每个页面重复。
实际动作：先列出读者从进入到完成的最短路径，把路径上每个必须做出的决定标出来。若某个决定需要一整段独立解释，就把它变成一个新页面的核心，而不是塞回原文。
按概念拆分何时更合理
当同一任务下存在容易混淆的概念，且混用会导致错误操作时，概念页值得独立。例如两种计费方式、两类账户权限、两种兼容模式，读者必须先分清差别，才能正确执行任务。这时把概念解释留在任务页里，会让任务步骤被大段定义打断。
但概念拆分有一个反例：如果概念之间的差别只影响文案表述，不影响读者动作，那么拆成多个页面只会制造重复。读者看完仍然不知道下一步做什么，页面之间只能靠同义词互相链接。这种情况下，合并为一个任务页，用一段对照说明即可。
另一个反例是概念本身还在变化。若定义、边界或分类尚未稳定，过早拆成独立页面会增加后续维护成本。此时更适合先放在同一页面内，等概念稳定、被多个任务引用后再拆出。
用假设例子比较两种拆法
假设一个后台工具的介绍页，原本包含三部分：什么是批量导入、如何准备文件、导入失败怎么排查。文章变长后，有两种拆法。
- 按任务拆：准备文件、执行导入、排查失败各一页，开头用一句话说明批量导入的用途。
- 按概念拆：批量导入的概念、文件格式规范、错误类型各一页，操作步骤分散其中。
如果读者多数是已经决定使用该工具、只想把文件传上去的人，按任务拆更合适，因为他们不需要先读概念。如果读者多数还在评估是否使用批量导入、需要先理解它和单条录入的差别，按概念拆更合适，否则任务页会反复解释同一个前提。
这个例子的关键不是哪边字数更少，而是读者进入时处于哪个阶段。阶段不同，拆分依据就不同。
决定之后立刻做的一件事
选定拆法后，先写一个页面级的任务声明：这个页面让读者完成什么、完成后他能做什么。然后检查原文中不属于这个声明的段落，把它们移到对应页面或暂时删除。
这个动作会直接影响下一步：如果移走后原页面仍然完整、读者能独立完成目标，说明拆分成立；如果移走后读者必须来回跳转才能理解，说明拆错了，应该合并或重新划分边界。不要用字数判断拆分是否成功，也不要用同义词把同一段内容改写成两个页面。
