看板与报告：共用可信底座，但完成不同的工作

Thu, 15 Oct 2026 00:00:00 +0000

看板越做越像长文，报告越做越像指标大屏，往往不是设计问题，而是没有先分清：读者到底要持续看状态，还是理解一次判断？

Data Analytics Skills 用两个 Skill 处理这件事：Build Dashboard 和 Build Report。它们共享一套可信底座，但服务的目的、结构和验收标准都不同。

看板：让人持续知道发生了什么

Build Dashboard 的第一步是明确看板简报：谁用、监控什么、多久刷新、需要哪些过滤和访问权限、交付面在哪。

原文要求先判断看板属于哪一类，因为这决定了布局和验收标准：

这个分类很实用。很多“看板很乱”的问题，本质是把三种目的塞进了同一个页面：监控区被探索控件淹没，复盘所需的对比基线又被省略。

原文要求按测量对象选择平衡的指标模型，而不是套固定清单。

通常需要考虑的指标族包括：主结果、驱动、护栏、明细与诊断。原文特别提醒，没有要求固定放四张指标卡——数量由决定需要什么来确定，不要为了排版凑数。

另一条要求是默认视图要直接回答主要问题，而不是让读者先点一圈筛选器。过滤器和参数是为追问服务的，不是进入看板的前置门槛。

Build Report 的起点是报告要完成的工作：用户问题、要支持的决定或行动、主要受众、范围、时间框架、比较基线、成功标准。

原文要求恰好选择一个受众：

受众的选择不是措辞风格问题，而是结构契约问题。同一份证据，写给管理层要答案先行，写给技术读者要方法先行。

原文在动手之前要求先写出“报告骨架”：

然后设了一道“深度闸门”：只有标题、执行摘要和一张图表或表格的报告，除非用户明确要求简报，否则应当先扩充证据路径。

它同时规定：一段总结配几张图，不自动等于完整报告。图旁要解释读法、发现和含义；比较性发现要交代人群、分母、时间与基线；因果表述附近必须放限制说明。

两者都需要可靠来源、统一指标口径、足够的数据检查与可追溯记录。

差别在于对账的对象不同：

原文对数据的要求也很直接：来源路径必须在渲染之前找到；核心看板数据不可用时应当停下，不能拿样例数据冒充真实业务看板，除非用户明确要的是演示原型。

看板的完成标准：默认视图可用、过滤器行为正确、指标对账通过、数据新鲜度达标、权限正确、性能可接受。

报告的完成标准：阅读顺序清楚、证据解释到位、限制与可行动结论完整、每条主张可追溯。

两者还有一条共同要求：必须打开最终产物检查。聊天里说“已经完成”，不是文件或页面真实可用的证明。

这条规则针对的是一种典型的 Agent 失败：工具调用返回成功，模型据此宣布完成，而实际渲染出来的页面是空白或错位的。