避免重复建设页面的核心做法,是在动手之前先建立一份全站页面清单,为每个页面写清唯一职责、目标用户和主要入口。多人协作时,只要两个页面的职责描述几乎相同,就应当合并或改成一个页面加锚点,而不是各建一页。这一步做在准备阶段,比事后删页面省力得多。
重复建设往往不是技术问题,而是职责没写清。准备阶段可以要求每个页面在进入设计或开发前,先填写三项信息:这个页面解决谁的什么问题、用户从哪些入口到达、它和相邻页面的边界在哪里。三项中任意一项说不清,就先不要开工。
判断是否重复,可以看一个简单标准:如果两个页面的核心问题可以用同一句话概括,它们大概率是重复的。例如“帮助新用户了解服务范围”和“介绍我们提供哪些服务”,指向的是同一类需求,应合并为一个页面,再用<h2>分区承载不同侧面。
多人协作时,重复常出现在需求提交环节:两个人从不同角度提出“再做一个介绍页”。此时不要直接排期,而是先查页面清单,看是否已有页面承担相同职责。如果有,就把新需求改成对现有页面的补充,例如增加一段说明、一个对比表或一组常见问题。
具体执行可以按下面顺序:
这里最关键的一步是第三步的判断。只有当新页面面向明显不同的用户意图、且合并后会让原页面主题变得混乱时,才值得单独建页。否则优先扩展,减少维护成本。
页面完成、准备交付前,做一次交叉检查。把新页面的职责描述与清单中其他页面逐条对比,重点看三类信号:标题含义是否高度接近、目标用户是否相同、主要入口是否重叠。三项中命中两项以上,就应停下来讨论合并。
检查时也要区分“内容相似”和“职责重复”。同一主题下不同深度的内容,例如概览页与详细操作页,可以共存,前提是各自入口清晰、互不争抢同一批用户。若两个页面都试图承接同一批搜索需求,就属于需要处理的重复。
页面合并、拆分或下线后,清单必须同步修改,否则下一次协作又会基于过期信息做判断。可以约定每次涉及页面新增或删除的交付,都把清单更新列为完成条件之一。这样,重复建设会在需求阶段被拦住,而不是等到上线后才被发现。
下一步,可以先从现有页面中挑出职责描述最接近的两三个,尝试合并为一个页面并保留互链,观察用户路径是否更清晰,再把这套判断标准写进团队的需求模板。