产品决策分析工作台

项目背景

这是一次针对内部经营分析场景的产品化改造。原有数据能够描述销售、损失和质量表现，但分类层级较多、指标入口分散，使用者仍然需要在多个视图之间来回判断：哪些产品值得关注、哪些异常需要先处理、哪些结论只是数据波动。

项目公开版本仅保留通用的问题、方法和设计判断。公司名称、内部平台、具体产品、合作方、价格成本、业务规模和可反推经营主体的数据均已移除或抽象化。

我的角色

我负责梳理业务问题、调整分类口径、确定信息优先级，并通过多版交互原型验证“看见数据”能否真正转化为“知道下一步做什么”。Codex 参与结构推演、原型实现、版本比较和规则检查。

从指标集合转向决策任务

改造没有从增加图表开始，而是先重新定义使用者需要完成的判断：

• 哪些产品处于相对健康状态；
• 哪些产品具有增长或优化机会；
• 哪些产品存在经营异常；
• 哪些记录需要进入质量复核；
• 当前结论是否有足够数据支撑。

只有能够服务这些判断的指标才进入主要界面，其余信息被放到下钻层或暂时移除。

收敛分类，而不是继续叠加层级

早期方案尝试过多层分类，希望同时表达产品表现、原因和处理建议。但实际使用中，同一条记录可能被多个标签重复解释，顶层视图也因此越来越难扫描。

最终方案收敛为少量、平级的顶层类别。每条记录优先进入一个最需要采取行动的类别，原因和辅助指标放到详情中说明。这样既保留分析依据，也避免主界面变成复杂的标签树。

质量复核是最高优先级覆盖项

产品表现良好，并不代表数据或业务过程没有质量问题。因此，质量复核没有被设计成普通分类，而是一个最高优先级的覆盖规则：只要触发质量条件，就应优先进入复核队列，再讨论增长、损失或经营机会。

这个决定把“数据是否值得相信”放在“数据说明了什么”之前，也防止高销售或低损失掩盖潜在异常。

原型如何演进

原型迭代主要经历了三个方向：

1. 从展示尽可能多的指标，转向突出少数关键判断；
2. 从多层、密集分类，转向更少的平级入口；
3. 从静态结果标签，转向能够解释优先级和下一步动作的工作台。

每轮调整都围绕同一个标准：使用者能否在更短时间内识别重点，并理解系统为什么给出这个判断。

最终留下的方法

这个项目最终沉淀的不是一套只适用于单一公司的报表，而是一组可以迁移到其他 BI 场景的方法：先定义决策任务，再选择指标；顶层分类保持少而互斥；风险与质量规则可以覆盖普通经营分类；所有自动判断都应保留依据和人工复核入口。

报表的价值不在于容纳了多少数据，而在于它是否帮助人更快、更加一致地采取行动。