想做好bi 平台，先掌握新手避坑中的仪表盘
做 BI 仪表盘最容易走偏的时刻，往往不是数据接不出来，而是页面已经摆满了数字，业务负责人看完仍然问：“所以我现在该做什么？”想做好 BI 平台，先别急着挑图表、套模板或调配色。我更看重一条顺序：先明确决策问题，再统一指标口径，接着检查数据条件，最后才设计页面、交互和验收。仪表盘的价值不在于展示了多少数据，而在于能不能让合适的人更快作出有依据的判断。
我判断一个仪表盘是否值得做，通常先问三个问题：谁会在什么场景下打开它？他打开后要作出什么判断？判断之后可能采取什么行动？如果这三个问题答不上来，页面很容易变成“把现有报表搬到线上”，看起来内容丰富，实际却没有明确用途。
例如，“看销售情况”不是足够具体的需求。它可能指销售负责人每天确认目标是否达成，也可能指区域经理排查某个渠道的下滑原因，还可能指财务核对订单与回款。三种任务的使用者、时间范围、指标口径和下钻路径都不同，硬塞进一个页面，常见结果就是每个人都能看到东西，却没有人觉得它正好回答了自己的问题。
更可执行的需求表达应该包含“角色、问题、动作”三个部分。例如：“销售负责人每天查看本月回款是否偏离目标；若差距扩大，就按区域和客户类型定位原因，并安排跟进。”这句话已经能指导关键指标、趋势区间、筛选器和明细表的设计。
页面上的数字能不能被解释，比数字是否突出更重要。一个指标至少要说清统计对象、计算方式、时间范围、去重规则和更新时间。以“销售额”为例，它可能按下单金额、发货金额或已回款金额统计；也可能包含或排除取消订单、退款、税费。名称一样，含义不一定一样。
如果业务负责人、财务和运营各自带着不同口径来评审，图表颜色再统一也解决不了争议。我的建议是先把关键指标做成可复用定义：写明口径、数据来源、维护责任人和适用场景。暂时不能统一的指标，不要假装只有一个答案，可以在页面名称或指标说明中标出差异。
仪表盘不是越简洁越好，也不是图表越多越专业。页面应该让目标用户尽快找到关键结论，同时保留足以解释结论的上下文。管理者看总体趋势，分析人员可能需要拆分维度，执行人员则常常需要明细和下一步操作。好的简洁，是删除与决策无关的信息；不是把解释数字所需的条件也一并删掉。
因此，我会把页面内容分成“结论、解释、行动”三个层次：先展示需要关注的关键结果，再提供变化趋势和维度拆解，最后连接到必要的明细或处理动作。仪表盘应当像一条判断路径，而不是一张没有阅读顺序的图表墙。
很多团队从 Excel 报表转向 BI 平台，最初会把已有表格和图形逐个搬到线上。这一步可以解决文件分散、版本不一致或手工汇总的问题，但它并不自动解决“数字为何变化”“异常从哪里来”“谁负责处理”等业务问题。换句话说，报表电子化与决策流程改善不是同一件事。
常见场景是：每周一，运营人员手工汇总各渠道数据；负责人要看总体结果，也会追问某个区域、商品或客户群为何变化。团队把原表做成仪表盘后，数字更新得更方便了，但筛选条件没有统一，更新时间没有标明，明细还得导出后再加工。最后，仪表盘成了新的数据入口，却没有替代原来的追问与人工核对。
要判断是不是只做了“线上搬家”，可以观察三个现象：用户是否还要重复导出数据；同一个问题是否要在多个页面来回找；数字出现异常时，是否知道该找谁核实。如果答案大多是肯定的，接下来要改的很可能不是配色，而是数据定义、页面路径或责任机制。
下面用一个虚构的销售运营场景说明设计过程。某业务团队希望负责人每天知道“本月表现怎么样”，并能在发现差距时迅速判断是区域、渠道还是商品组合造成的。这里的数字均为演示用情景数据，不代表任何企业实绩或行业基准。
如果直接把所有可用字段都铺上去，页面可能同时出现订单数、销售额、退款额、客单价、毛利率、渠道排行、商品排行、地区地图和客户明细。问题是，负责人首先想判断的不是“字段够不够多”，而是“是否偏离目标、偏离发生在哪、接下来查什么”。因此，第一版可以围绕三个层次组织：目标进度作为入口，时间趋势解释变化，区域或渠道拆解帮助定位，明细仅在需要追查时出现。
在使用九数云等 BI 平台搭建时，可以把它当作业务建模和展示的工作台来考虑：先整理数据源及字段含义，再确认指标逻辑与展示方式，最后根据平台实际支持的能力配置筛选、联动和权限。具体功能名称、操作路径与支持范围会随产品版本变化，发布前应以平台当前官方文档和实际环境为准，不能因为某个界面看起来能拖拽组件，就跳过口径和数据质量检查。
仪表盘显示一个精确到个位的数字，容易让人误以为数据是完整、即时且可直接决策的。如果数据实际上延迟一天，或某个来源还没有完成同步，页面却不说明更新时间，用户可能把“尚未到达的数据”误解成“业务下滑”。这类误判并非视觉设计问题，而是数据状态没有被展示。
因此，更新时间、统计截止时间和异常提示不是页脚装饰，而是判断数字可信度所需的上下文。对于刷新频率较低的指标，应直接说明截止时间；对于异常或缺失数据，应显示状态、影响范围或暂不可用提示。一个明确标注“数据截至昨日”的结果，通常比一个看似实时、实际含义不清的数字更可靠。
平台里图表类型很多，很容易让人从“这个图看起来高级”开始设计。但图表必须匹配比较任务。用户要看随时间变化，可以考虑趋势图；要比较不同类别，通常需要清晰的分类对比；要看构成，应确认各部分是否适合放在同一口径下；要追查具体记录，表格或明细视图可能比复杂图形更直接。
同一种图表也可能因为轴、排序、时间粒度和筛选条件不同而传递出不同印象。比如纵轴从非零值开始，可能夸大波动；把过多系列叠在一张趋势图上，可能让每条线都难以辨认。选图时应先写出“用户要比较什么”，再验证这张图能否让这种比较变得容易。
指标多不等于信息完整。若十几个数字都使用同等字号和颜色，用户反而难以判断哪一项最重要。首页的任务通常是帮助用户确定“是否需要进一步查看”，不是代替所有分析工作。把每个可用字段都放在第一屏，会增加阅读和维护成本，也容易让关键异常被淹没。
我会先区分“必须一眼看到”“用于解释变化”“需要时再查”三类内容。第一类放在视觉主路径上；第二类跟随关键指标或趋势；第三类放在筛选、下钻或明细中。分类后如果仍有争议，就回到用户任务：删除某一项后，用户会不会无法作出目标判断？如果不会，它未必需要占据首页位置。
“新增客户”“活跃用户”“订单金额”“库存周转”等名称看起来明确，实际可能存在定义差异。例如新增客户按首次注册、首次下单还是首次完成支付计算？活跃是登录、浏览还是完成关键动作？若不同团队把定义写在各自的 SQL 或表格里，问题会在仪表盘上线后集中暴露。
建议关键指标配套一份简明的数据字典，至少记录业务定义、计算规则、时间范围、来源表、刷新频率、负责人和适用限制。口径发生变化时，明确版本和生效日期。不要只在会议里口头解释，也不要把关键条件藏在复杂公式中，让后来维护的人只能靠猜。
红色不一定代表坏，绿色不一定代表好。退款率上升可能是风险，毛利率上升通常是改善；但某些指标处于业务特殊阶段时，还要结合目标、季节性和样本量理解。若团队没有定义阈值和判断规则，只靠颜色提醒，很容易让用户把视觉强调误当成业务结论。
颜色应该服务于含义，并在同一产品或同一业务体系内保持一致。关键异常最好同时给出文字、数值或状态说明，例如“低于目标8%”“数据待补齐”，而不是仅把卡片染成红色。还要考虑色觉差异、屏幕显示和打印场景，避免只靠色相区分信息。
筛选器、联动、下钻和跳转都可能有用，但每增加一种交互，也增加了用户理解操作结果的成本。筛选器过多，用户可能忘了自己选了什么；联动没有明确反馈，用户不知道其他图表为何变化；下钻层级太深，找到答案的路径反而变长。
我更愿意逐个问：这个交互解决什么问题？用户是否知道当前条件？结果变化是否可解释？如果删掉它，用户是否仍能完成任务？不能回答这些问题的交互，先不要加。特别是默认筛选条件、日期区间和筛选影响范围，应该清晰可见，必要时提供重置方式。
把“想看什么”改写成“要判断什么、判断后做什么”。可以用一句话描述：某类用户在某个时点，需要依据哪些信息判断某个状态，并采取什么动作。若用户、判断和动作仍然模糊，先做访谈或流程梳理，不要急着把模糊需求固化成页面。
核心指标是用户快速判断状态的入口；解释指标帮助理解变化；明细用于进一步定位。三者不必都在同一视觉层级。每个指标都应该能回答一个具体问题，若两个指标回答相同问题，可考虑合并、调整展示位置或明确两者的区别。
确认分子、分母、时间窗口、去重方式、业务过滤条件及空值处理。涉及目标值或环比、同比时，还要说明比较基准是否完整、日期范围是否匹配。指标定义不应只存在于开发者脑中；可读、可维护的解释，是跨部门使用的前提。
从页面指标向上追溯到数据源，确认字段映射、刷新频率、异常处理和数据权限。尤其要确认是否存在重复记录、延迟入库、状态回补或历史数据重算。业务定义正确但数据链路不稳定，同样会生成误导性的结果。
根据任务选择图表，而不是为了使用某个图表去创造任务。页面布局应对应阅读顺序：先确认整体状态，再理解变化，再按需要定位原因。颜色、单位、小数位、日期粒度和标题也要形成一致规则，避免用户每看一张图都重新猜测。
筛选器和联动需要说明影响哪些组件、默认值是什么、选项是否互斥以及如何恢复默认状态。日期筛选尤其要明确采用自然日、滚动区间还是业务周期。用户不能判断当前页面条件时，页面即使数据正确，也可能被解读错。
上线前至少准备几项真实问题，让目标用户独立完成查找。例如“本月目标差距是多少”“差距主要来自哪个区域”“找到该区域后，能否确认需要跟进的对象”。记录用户找错、看错、重复导出、等待加载或无法访问的地方，再判断是口径、布局、交互、性能还是权限问题。
如果没有用户测试条件，也可以做桌面推演：让不参与搭建的人按照任务描述操作，观察他是否能在不接受口头提示的情况下完成。测试结果不必包装成效率提升比例；把失败位置、发生条件和修改方式记录清楚，往往更有助于下一轮迭代。
设想一个线上零售团队，希望销售负责人每天判断本月进度是否落后，并在发现偏差后定位区域和渠道。我们先不决定放地图、排名还是折线，而是把判断拆开：当前累计回款与目标差多少？差距从什么时候开始扩大？哪些区域贡献了主要差异？是否有退款、取消或数据延迟影响当前判断？
这样拆分以后，页面的基本结构自然浮现：目标进度回答“现在到哪了”；趋势图回答“变化何时发生”；区域与渠道对比回答“差异在哪里”；必要明细回答“下一步联系谁或检查哪笔记录”。图表只是呈现方式，业务问题才是页面结构的起点。
假设团队需要观察“本月销售额”，我会要求页面说明它是下单金额、已支付金额还是已回款金额，是否扣除退款和取消订单，采用自然月还是业务结算周期。若负责人关心现金回收，却拿下单金额与回款目标比较，即使每个数都计算正确，结论仍然不适用。
对于“完成率”，也要写清目标值来自哪里，是按月固定分配，还是根据工作日和历史季节性拆分。目标拆分方式改变，日常完成率就会改变。没有可靠目标时，可以先展示实际值和历史对照，不应为了让卡片看起来完整而随意设置一个“目标”。
下表是一组演示数据，用于解释页面如何组织信息，不代表真实企业表现。假设某团队当月目标为100万元，当前已回款72万元；若同期目标进度为80%，那么差距是8万元。这个差距提示需要继续判断，但它本身并不能说明原因。
| 页面信息 | 情景示例 | 用户可以判断什么 | 必须补充的说明 |
|---|---|---|---|
| 当月回款 | 72万元 | 当前累计回款规模 | 说明统计截止时间、退款处理和币种 |
| 当期目标 | 90万元 | 当前阶段应达到的金额 | 说明目标拆分方式和目标版本 |
| 目标差距 | 低于目标18万元 | 是否需要进一步排查 | 说明比较周期是否一致，避免拿不同截止日比较 |
| 区域差异 | 甲区低于阶段目标10万元 | 优先从哪个区域开始定位 | 说明区域归属规则和未分配订单处理方式 |
这组例子里，“低于目标18万元”并不是根因结论。它只是提示接下来查看时间趋势和区域差异。如果页面只放一个红色数字，用户可能立刻把责任归到某个团队；如果同时展示数据截止时间、目标口径和拆分路径，数字才更像可靠的判断依据。
如果负责人发现某区域的销售额突然归零，第一步不是立刻换图表，而是按顺序检查：数据是否刷新、日期筛选是否正确、区域字段是否映射、订单状态是否被排除、该区域是否真的没有有效订单。只有这些条件确认后，才讨论是否是业务异常。把“图上不对”直接等同于“图表配置错”，容易掩盖数据链路问题。
同理，如果不同页面的销售额不一致，要比对统计范围、筛选条件、刷新时间和汇总粒度。一个页面按订单创建时间统计，另一个按支付时间统计，数值不同可能是合理结果。差异应被解释，而不是为了追求页面一致，强行把其中一个数字改到看起来相同。
先不要搭页面。安排一次短访谈，让提出需求的人拿最近遇到的实际问题举例：当时怎么发现问题、用了哪些数据、最后做了什么决定。如果对方说不清楚，可以先从现有周报、会议记录和重复查询中找任务线索，再选择一个频率较高、价值明确的问题做第一版。
输出物可以很简单：使用角色、查看时点、核心问题、需要的指标、判断后的行动、不可接受的误判。关键是把模糊的“看业务”变成可以验收的任务，而不是一开始就讨论图表颜色和页面布局。
优先建立指标字典和责任归属。先挑最常被使用、最常引发争议的少数指标，确定业务定义、计算方式、时间窗口和负责人。若相关部门暂时无法统一，可以先在页面中明确区分不同口径，并说明各自适用场景，不要通过隐藏其中一个口径来制造表面一致。
当指标定义需要变更时，应记录生效日期和影响范围，必要时保留历史版本。否则，业务人员会发现同一个月份在不同时间打开页面时数值变化，却不知道是数据回补、计算逻辑调整，还是源数据发生更正。
先做数据链路排查，不要用更漂亮的图表掩盖数据问题。查看缺失率、重复情况、更新时间、状态回补和异常值处理方式。对于暂时无法解决的延迟，要在页面标示最后更新时间和受影响范围，并决定该数据能否用于当前决策。
重要业务指标可以设置适当的核对流程，但阈值应按业务特点设定。比如某些指标每天都会波动，适合看趋势；某些财务数字需要在结账后确认。没有背景说明的异常提醒可能引发无效告警，告警过多会让用户逐渐忽略真正重要的变化。
不要立刻把所有表格搬进仪表盘。先观察用户导出后做了什么：是补充了当前页面没有的维度、重新计算了口径、还是只为了获得明细？如果加工逻辑稳定且具有重复性，可考虑把规则纳入数据模型或页面；如果是临时探索，保留明细分析的空间可能更合适。
对于需要定期执行的任务，可以明确从页面到下一步工作的路径，例如定位对象后查看必要明细、导出受控数据或通知责任人。是否能在平台内完成，要以平台当前能力、权限政策和数据安全要求为准。不要为了减少导出而牺牲用户完成任务的效率。
先盘点而不是继续增加。检查每个页面的负责人、目标用户、使用频率、更新时间和重复指标。长期无人使用、用途重叠或口径失效的页面，应考虑合并、重构或下线。页面数量增加会带来维护、权限和口径治理成本，旧页面也可能继续传播过时定义。
页面治理不必一开始就建立复杂制度。可以从目录、负责人、适用范围、更新时间和下线机制做起。对于关键页面，保留变更记录和验收信息；对于临时分析页面，则明确临时属性和有效期限，避免临时成果慢慢变成没人负责的“正式报表”。
管理者通常需要较少的核心信息和清晰的异常线索，页面应帮助其快速判断是否需要关注、关注什么。分析人员更需要维度拆解、筛选能力和追溯细节，页面可以提供更丰富的探索路径。把两类任务强行合并，常常会出现管理者觉得太复杂、分析人员觉得不够用。
取舍方式不是简单地做两份重复页面，而是明确共同指标与不同任务层级。可以让管理视图保持重点集中，再为需要进一步分析的人提供深入查看的路径；也可以依据权限、维护成本和产品能力拆分页面。分不分，应由用户任务决定，而不是由组织架构图决定。
有些运营任务确实需要高频更新，有些财务或经营分析更重视口径稳定和结算确认。提高刷新频率可能增加数据处理负担，也会让尚未完成回补的数据频繁变化。对于决策后果较大的指标，稳定、可解释的刷新规则，往往比单纯追求“看起来实时”更重要。
可以按指标用途分类：即时监控、日常经营、周期复盘和结算确认。不同类别设定不同的刷新节奏、截止时间和异常处理方式。不要让一个页面上的所有指标都默认共享同一刷新周期，因为它们的数据来源和业务要求可能并不相同。
“一屏展示全部信息”对某些值班监控场景可能有意义，对日常经营分析却未必有效。信息越多，用户需要筛选和理解的内容越多；信息过少，又可能看不出指标变化的上下文。设计时应确认用户是在快速巡检、定位原因还是做周期复盘，再决定首屏信息量。
如果不同角色差异很大，可以考虑用不同视图、标签页或受控筛选来区分，不必试图让一个首屏满足所有人。拆分页面会增加维护成本，所以每新增一个视图都要说明它解决了哪类任务、由谁维护，以及与其他视图的关系。
低风险、规则明确且重复发生的流程，适合尽可能自动化；高风险、口径仍在调整或涉及人工判断的流程，应保留必要复核。仪表盘提供的是判断依据，不代表所有业务动作都应该自动触发。自动化范围越大，越需要明确异常处理、权限、审计记录和回滚方案。
若页面数字会直接影响奖惩、预算或资金操作，应提高口径确认和变更管理要求；若页面用于探索性分析，则可以给用户更大的筛选自由度，但需要提醒其注意样本范围和数据限制。正确的取舍不是追求功能最多，而是让风险与控制措施相匹配。
在正式发布前，我建议把检查拆成需求、口径、数据、页面、交互和治理六组。检查清单的目的不是增加签字流程，而是避免大家只盯着页面是否好看，却漏掉影响结论的条件。若一项暂时无法满足，记录风险、责任人和替代措施，比默默跳过更可靠。
第一版不必追求把所有数据都纳入。选择一个高频、决策价值明确且数据条件相对可控的任务，完成从指标定义到用户验收的闭环。若第一版无法让用户完成基本判断，继续加图表只会增加复杂度，并让团队更难定位问题到底出在哪里。
试运行期间，关注的不只是访问次数，还要记录用户是否找到答案、是否重复导出、是否频繁询问口径、是否因数据延迟误判。数量指标可以提示使用情况，但最好结合具体反馈和任务观察。没有可靠采集方式时，不要虚构“效率提升百分比”，也不要把一次成功演示当成普遍有效的证明。
收集反馈时，尽量让用户指出具体位置和任务：在哪里停住了？看见哪个数字后不确定？筛选后预期发生什么变化？这比“页面不够好用”更容易转化成可执行改动。每次迭代保留修改原因、影响范围和验收结果，避免不同团队在不知情的情况下重复改动同一逻辑。
如果用户觉得页面信息太少，先确认他缺的是指标、解释还是明细；如果用户觉得筛选不灵活，先弄清是选项不足还是筛选关系不清。反馈往往描述的是体验症状，真正的修复点可能在数据模型、命名、默认条件或业务流程里。
做好 BI 仪表盘，关键不是掌握多少图表类型，而是建立一条可靠的判断链：用户知道自己在看什么，指标有稳定定义，数据状态被如实说明，图表匹配比较任务，交互不会制造新的误读，最后由真实用户验证页面能否支持行动。
下一步可以从一个正在引发重复沟通的业务问题开始：写清使用者、判断问题和后续动作；为最关键的指标补齐口径；核对数据截止时间；再搭一版只覆盖核心任务的页面。先解决“看完能不能做出正确判断”，再讨论“页面还能不能更漂亮、更丰富”。这才是新手避坑中最值得优先掌握的仪表盘方法。
我刚开始做仪表盘时，总觉得先把平台里的图表都试一遍，才能找到合适的呈现方式。可图做出来后，我还是说不清用户看完应该采取什么行动；到底应该从哪里开始？
先写清楚用户要做的判断，再选指标和图表。比如“看销售情况”太宽泛，可以拆成“本月是否达标”“差距主要来自哪个区域”“哪些客户需要跟进”。每个问题对应不同的信息：达标情况看目标与实际值，区域差异看分组对比，客户跟进则需要可定位的明细。
可以用一个简单的对应表检查页面是否跑偏： 业务问题需要的信息可能的呈现方式 本月是否达标实际值、目标值、完成率指标卡或目标对比 差距何时出现按时间变化的数据趋势图 哪个区域需要跟进区域对比及可追溯明细排名与明细表 表格里的销售场景只是示例。
关键判断是：如果一个图表无法帮助目标用户回答具体问题，先别急着美化它，回头检查业务问题和指标是否定义清楚。
我遇到过不同报表里的“销售额”看起来是同一个指标，数字却对不上。大家都说自己的数据没问题，我不确定应该先查图表、数据源，还是统计规则；指标口径到底要写到什么程度？
指标名称相同，不代表统计方式相同。以“销售额”为例，含税与否、按下单日还是支付日统计、退款是否回冲、按订单还是按商品去重，任意一项不同，都可能让结果产生差异。此时调整图表颜色或筛选器解决不了根因。
建议给关键指标配一张口径卡，至少记录指标定义、统计范围、时间字段、去重规则、数据来源、更新时间和维护责任人。遇到数字不一致时，按这些字段逐项对照，通常比反复刷新页面更容易定位问题。在上线前，可选一个具体时间段和一组业务对象，把仪表盘结果与经过确认的源报表逐项核对。
若两边结果不同，先确认口径是否一致，再查数据处理链路；不要在没有解释差异的情况下直接把两个数字都放到页面上。
我担心页面太空，常常会再加几张图；但图多了以后，重点反而不明显。我也找不到适用于所有场景的固定图表数量，应该用什么标准判断哪些内容该留下？
不要用固定图表数量判断信息是否过载，先检查每张图是否回答了一个独立问题。若两张图展示同一指标、同一时间范围和相近维度，用户通常只是在重复读取信息；若页面上每张图都要求用户重新理解单位、颜色和筛选条件，阅读成本也会快速上升。
可以按“结论，变化，原因，明细”的顺序组织页面：顶部放最需要关注的指标，中间展示趋势或对比，后续再提供拆解和追查所需的明细。并不是每个仪表盘都需要四层，只有确实支持用户下一步判断的内容才保留。一个实用的删减测试是：暂时隐藏某张图，问目标用户是否因此无法回答某个关键问题。
如果答案是否定的，而且这张图没有承担核验或追溯作用，就可以考虑移除、合并或放到次级页面。配色和装饰应在信息层级确定后再处理。
我做完页面后，自己能找到数据，也能解释每张图，但不确定第一次使用的人是否看得懂。我想知道上线前要检查哪些项目，怎样发现口径错误、筛选误解或权限问题，而不是等业务方投诉后再返工？
验收不要只检查页面能否打开，也不要只由制作人自己试用。可以准备一组真实任务，例如“找出本月未达标的区域，并确认对应变化发生在哪一周”，请目标用户独立完成，同时记录他点了什么、在哪一步停顿、是否误读单位或筛选条件。上线前至少核对四类问题：关键数字能否与可信来源对上；更新时间和数据延迟是否明确；
筛选、联动或下钻是否会改变用户以为不会变化的结果；不同角色能否看到符合其职责的数据。具体校验规则应按业务风险和平台能力制定，不宜套用未经验证的统一阈值。试用记录可以包含“任务、预期结果、实际路径、问题、处理人、复测结果”。先修正会导致错误决策的问题，例如口径不一致、筛选范围不清或权限过宽；
再处理布局和视觉细节。这样验收关注的是用户能否可靠地完成判断，而不只是页面看起来是否完整。
读者评论
先明确使用者、判断问题和后续动作，再设计页面，这个顺序很实用。尤其是“看销售情况”太宽泛，直接拿来做需求容易把不同团队的需求混在一起。
文中对数据更新时间和完整性的提醒很重要。延迟数据如果没有截止时间说明，确实可能被误读为业绩下滑；不过具体提示方式还要结合数据刷新机制设计。
仪表盘不该把所有指标都堆在首页。按结论、解释和明细分层，能减少信息干扰；指标口径、筛选条件和异常规则也需要同步维护。