需求多维化拆分的防扩散设计原则

为什么”1→N 拆分”是 bug 高发区#

典型模式：

1. 旧需求定义了一个单维度概念（“延期” = 看子任务 deadline）
2. 新需求把它拆成多维度（“延期” = 研发延期 / 测试延期 / 父任务延期 三类）
3. 拆分时没有重整架构，而是在每个消费点各自加分类判断
4. 消费点散落在计算层、AI 层、导出层、前端 N 个页面
5. 漏改 / 改错一处 → bug，且因边界场景才触发，往往上线几天后才被发现

同一个概念，N 个地方各写一遍分类逻辑，必然漂移。

五条防扩散设计原则#

启动三问（下次遇到”1→N 分类”需求时必问）#

改之前先回答这三句，任何一句答不上来就先补设计、别急着写代码：

1. 计算层的单一数据源在哪？ 这个概念的核心计算，是不是只有一个函数在算？如果 N 个地方各算一遍，先收口。

2. 分类能不能只活在展示层？ 新增的维度能不能做成最后渲染时贴的标签，而不是侵入计算的 if？

3. 所有消费点是否都有测试覆盖？ grep 出来的每个消费点，有没有对应的用例守着？漏改了能不能被测试抓住？

一个讽刺的真实现场#

某系统”人数”这个统计被 3 处消费：顶部总览、部门卡、横向对比。某天领导要求”人数排除组长”——三处逐个改完。当天领导又改口”人数要含组长”（组长数据仍排除在工时/任务外，但人数含组长）——三处又得逐个改回。

如果当初抽了 group_member_count() 单一函数，这次翻转只改一个函数、所有页面自动同步。 朝令夕改在业务系统是常态，“一处改全同步”的价值正是在这种时候兑现。

什么时候必须建聚合函数层#

不是所有项目都要做。涉及上万条级数据库记录 + 偏仪表盘 / 多页面对账的网页才需要——同一个统计口径被多个页面 / 接口 / 导出 / AI 同时消费时，立项阶段就要建统一聚合函数层，别等 bug 出来再补。

分层规范：

1
数据源 DB → 统一聚合函数（一个概念一个函数）
2
         → 后端算好派生字段（禁止把原始复合结构抛给消费端各自解读）
3
         → API 契约（字段字典，前端只读渲染，不做 len() 推导）

加 跨页一致性断言测试 兜底：“同一对象在 A 页的统计 = B 页 = C 页”，后端改错立刻被抓，不用等用户报。

结论#

需求多维化本身没错，错的是用”加 if”的方式去做架构级的改动。下次遇到”把 X 拆成几类”的需求，先停一下，回答启动三问——任何一个答不上来，先补设计。

改动的影响面必须被显式识别，不能靠”改完看看”兜底。