先把近似问句按“用户此刻要做的决定”分组,而不是按措辞分组,再给每组绑定一个可执行的下一步;只有当这些问句确实来自同一决策路径时,合并才成立。若问句背后是不同角色、不同预算阶段或不同风险承受度,强行合并会让页面看似覆盖很多,实际无法回答任何一类人的问题。
近似问句最容易被误判为同义词。比如“要不要做”“怎么做”“做了之后怎么判断有没有效”,字面都围绕同一件事,但分别对应要不要投入、怎么执行、如何验收三个不同阶段。判断方法不是看句子像不像,而是看提问者拿到答案后马上要采取什么动作。
一个实际动作是:把每条问句后面补一句“他看完会去做什么”。如果补出来的动作相同,才考虑合并;如果动作不同,就保留为不同阶段的内容单元。这个动作会直接影响下一步:你不再按字数或句式整理,而是按动作链整理。
即使处于同一阶段,问句也可能因为约束不同而不能共用答案。常见约束包括:是否有历史内容需要处理、是否已有稳定访问来源、是否允许改动现有页面结构、是否涉及多个渠道并行。约束不同,答案的取舍就不同。
假设一个已有业务站点,过去把大量近似问句堆在同一页面,现在要重新整理。可以先用假设例子说明比较方法:把“要不要做”类问句放在一起,再把“预算有限时先做哪一步”单独列出。前者回答方向,后者回答优先级。若把两者合并,读者会看到一段既讲方向又讲优先级的文字,但无法判断自己该先执行哪个动作。这里的数字只用于说明分组逻辑,不代表任何真实流量或效果。
整理的目的不是让清单更整齐,而是让每个阶段都有明确的下一步。决策前阶段,下一步通常是收集自身条件并做取舍;执行阶段,下一步通常是确定一个可交付动作并记录假设;验证阶段,下一步通常是对照假设检查结果,并决定继续、调整或停止;纠偏阶段,下一步通常是定位异常来源并限定改动范围。
如果某个问句找不到明确的下一步动作,它很可能只是背景信息,不适合单独成组。此时可以把它并入相邻阶段的解释段落,而不是硬造一个标题。这样处理的结果是:后续更新时,你能按阶段复查,而不是按句子数量复查。
如果大量近似问句其实来自完全不同的业务线、不同地区或不同用户角色,那么按决策阶段整理仍然不够。此时同一阶段内可能包含互相冲突的答案,例如一条业务线要求先验证再投入,另一条业务线因为前提已经变化而要求先投入再验证。遇到这种情况,先按业务线或角色分域,再在域内分决策阶段;否则阶段分组会把冲突答案压在一起,读者越看越难判断。
另一个反例是:问句虽然近似,但其中一部分涉及具体品牌、具体机构或联系方式的查询。这类问题需要单独核实,不能靠通用阶段分组回答。核实动作本身会影响下一步:若信息无法确认,就不应把它写成确定结论,而应保留为待核实项。
可以按以下顺序执行:
完成这一步后,再回头看哪些问句可以合并。合并的依据是动作相同且前提一致,而不是措辞接近。若后续发现某组答案开始互相矛盾,说明前提已经变化,应回到第一步重新判断,而不是继续在旧分组里补写。