看板越做越像长文，报告越做越像指标大屏，往往不是设计问题，而是没有先分清：读者到底要持续看状态，还是理解一次判断？
Data Analytics Skills 用两个 Skill 处理这件事：Build Dashboard 和 Build Report。它们共享一套可信底座，但服务的目的、结构和验收标准都不同。
看板：让人持续知道发生了什么
Build Dashboard 的第一步是明确看板简报：谁用、监控什么、多久刷新、需要哪些过滤和访问权限、交付面在哪。
原文要求先判断看板属于哪一类，因为这决定了布局和验收标准：
- 状态监控：持续看有没有异常。
- 周期性经营复盘：按节奏对比目标与计划。
- 分析性探索：支持临时的多角度下钻。
这个分类很实用。很多“看板很乱”的问题，本质是把三种目的塞进了同一个页面：监控区被探索控件淹没，复盘所需的对比基线又被省略。
指标模型要有分层，但不要凑数
原文要求按测量对象选择平衡的指标模型，而不是套固定清单。
通常需要考虑的指标族包括：主结果、驱动、护栏、明细与诊断。原文特别提醒，没有要求固定放四张指标卡——数量由决定需要什么来确定，不要为了排版凑数。
另一条要求是默认视图要直接回答主要问题，而不是让读者先点一圈筛选器。过滤器和参数是为追问服务的，不是进入看板的前置门槛。
报告：让人理解为什么这样判断
Build Report 的起点是报告要完成的工作：用户问题、要支持的决定或行动、主要受众、范围、时间框架、比较基线、成功标准。
原文要求恰好选择一个受众：
- 产品与业务相关方：产品、业务、管理层、战略、诊断、KPI 读数和一般相关方报告。
- 技术受众：用户明确要求技术或方法优先的报告，或者报告的主要价值在方法论。
受众的选择不是措辞风格问题，而是结构契约问题。同一份证据，写给管理层要答案先行，写给技术读者要方法先行。
报告的结构不能只有摘要
原文在动手之前要求先写出“报告骨架”：
- 问题
- 对决定有用的答案
- 指标、队列、分母、时间窗口与比较基线
- 按细分或驱动组织的发现，附支撑证据
- 比较性或因果邻近结论所需的敏感性或验证检查
- 会改变解读的注意事项
- 建议的下一步、监控点或未决问题
然后设了一道“深度闸门”：只有标题、执行摘要和一张图表或表格的报告，除非用户明确要求简报，否则应当先扩充证据路径。
它同时规定：一段总结配几张图，不自动等于完整报告。图旁要解释读法、发现和含义；比较性发现要交代人群、分母、时间与基线；因果表述附近必须放限制说明。
共用可信底座，不代表共用版式
两者都需要可靠来源、统一指标口径、足够的数据检查与可追溯记录。
差别在于对账的对象不同：
| 维度 | 看板 | 报告 |
|---|---|---|
| 对账对象 | 卡片、图表、明细之间能互相解释 | 每条主张能找到对应证据 |
| 时间处理 | 数据新鲜度、刷新节奏 | 比较窗口、基线、截止时间 |
| 读者动作 | 发现异常后去追问 | 读完形成一个判断 |
| 主要失败 | 数字对不上、刷新滞后、越权可见 | 结论超出证据、限制缺失 |
原文对数据的要求也很直接：来源路径必须在渲染之前找到；核心看板数据不可用时应当停下，不能拿样例数据冒充真实业务看板，除非用户明确要的是演示原型。
完成标准不同，但都要打开检查
看板的完成标准：默认视图可用、过滤器行为正确、指标对账通过、数据新鲜度达标、权限正确、性能可接受。
报告的完成标准：阅读顺序清楚、证据解释到位、限制与可行动结论完整、每条主张可追溯。
两者还有一条共同要求：必须打开最终产物检查。聊天里说“已经完成”，不是文件或页面真实可用的证明。
这条规则针对的是一种典型的 Agent 失败：工具调用返回成功，模型据此宣布完成，而实际渲染出来的页面是空白或错位的。
交付面的选择要看环境
原文区分 BI 平台、MCP 应用、便携 HTML、Sites 托管等交付路线，并对运行模式设了条件：只有在明确识别的工作模式下、且完整生命周期工具可调用时，才走自动发布路线；桌面端非工作模式则要求明确请求或接受建议。
这条边界值得单独强调：不能把某个分支简化成“所有报告都会自动上线”。交付能力取决于环境、权限和工具可用性，而不是模型的意愿。
设计自己的交付物时
三个可以立刻用的检查：
- 这份产物是给读者反复看的，还是给读者看一次的？前者是看板，后者是报告。
- 报告里每条结论，能不能指到一张表、一段查询或一张图？
- 看板的默认视图，能不能在不点任何筛选器的情况下回答问题？
看板帮助你反复发现值得关注的变化，报告帮助你理解这次变化意味着什么。可以组合使用，但各自要完成不同的工作。