build-report

相关技能

如果报告依赖市场规模测算、指标诊断、KPI 报告、产品／业务分析、数据质量检查或验证，请先使用针对性分析技能，再构建报告。

构建报告

当用户需要一份持久化的分析报告，而不是仪表板、仅限笔记本的输出或临时聊天摘要时，请使用此技能。报告负责面向读者的叙述、受众定位、证据呈现、图表／表格的位置、注意事项、来源元数据和交付。底层分析仍应来自合适的分析、笔记本、数据质量、诊断、KPI 或产品分析工作流。

如果直接选择此技能，或通过报告模式工作流将其纳入，则只有在选定的报告载体已创建或记录了具体阻碍时，本次运行才算完成。不得仅以聊天文字、内嵌小组件、本地 URL 或跳过报告结构的临时产物作为最终交付。请将内嵌摘要和笔记本输出视为进度证据，而不是报告的替代品。选择此技能后，图表、表格和预览应放在选定的报告载体中。用户明确要求内嵌回复、仅聊天回复、简短／不生成产物的答案，不要报告／文件／产物，或选择了其他主要产物时，可免于创建报告。不要仅因用户未提到“报告”，或提出了直接的诊断、建议、测算或解读问题，就推断用户放弃了报告。

技能配置

每次运行恰好选择一种报告交付模式：

• Codex 桌面端：默认使用 mcp-app。
• 明确识别为 ChatGPT Web Work Mode：使用 html；MCP app 报告渲染在该界面不可用。MCP 服务及其他可调用工具仍可作为证据来源。
• 检测到 Work Mode 信号，但界面类型未知或非桌面端：使用 html；不得将未知的界面分类视为渲染 MCP app 报告的许可。只有明确的 surface = codex_desktop 信号才可采用 Codex 桌面端的 MCP 默认模式。
• 任何其他无法渲染 MCP app 报告的运行环境：使用 html。
• 未知或未分类的运行环境：默认使用可移植的 html，不要省略报告。

在 Codex 桌面端，只有在用户明确要求 HTML、离线可移植性、基于文件的产物或不使用 MCP 渲染；需要进行下游转换且该转换要求 HTML；或已实际尝试生成 MCP app 报告，但因功能不可用或超出有记录的渲染器限制而失败时，才使用 html。

如果选定的 MCP app 报告在一次针对性修正后仍无法渲染，除非用户明确拒绝 HTML，否则应在同一次运行中改用 html。渲染失败会改变交付模式，但不免除报告义务。如果两种载体都无法创建，则在完成前记录具体阻碍以及已尝试的载体。

如果 MCP app 报告已经渲染，而当前上下文随后表明这是 Work Mode，且没有明确的 Codex 桌面端界面信号，则应将该 MCP 产物视为交付模式不正确。在最终交付前，应将报告重建为独立的 HTML，而不是解释 MCP 产物可以接受。

每次运行只能选择一种交付模式。除非用户明确要求在后续单独交付第二种模式，否则不要同时构建 MCP app 报告和静态 report.html。对于所有选定的 HTML 报告路径，包括 Codex 桌面端明确要求 HTML、ChatGPT Web Work Mode，以及为转换为 PDF、Google Docs 或 Google Slides 而创建的 HTML，都应使用 recharts-html.md 中预编译的 Recharts-in-HTML 路径，并在交付的 HTML 中提供清晰易读、数据相同的静态回退内容。

工作流

1. 明确报告任务。

   说明报告要支持的用户问题、决策或行动、主要受众、范围、时间范围、对比基准、成功标准，以及报告需要具备什么才能帮助用户做出决策。恰好选择一个受众：

   • product stakeholders：产品、业务、领导层、战略、诊断、KPI 解读和常规利益相关方报告的默认受众。
   • technical：仅当用户要求面向技术受众或以方法为先的报告，或者报告的主要价值在于方法论（如指标定义、测量设计、统计、建模、实验或验证）时使用。

   如果工作的方法论比重异常高，但用户没有要求面向技术受众，请先询问，再切换受众。

2. 阅读匹配的受众规范。

   在收集证据、梳理报告主线或起草报告呈现内容之前，准确阅读一份匹配的受众规范：

   • product stakeholders 对应 executive-report.md
   • technical 对应 technical-report.md

   将选定的受众规范视为报告质量契约，而不是以下工作流的替代品。在报告计划或支持性来源说明中记录其中的 Required Structure 条目；如果无法阅读匹配的规范，则停止并说明阻碍。

3. 收集证据并明确范围。

   清点支持报告所需的源数据、指标定义、分母、假设、用户要求的拆分、注意事项、笔记本、SQL、脚本、查询永久链接、源文档和已审核的数据集。起草结论前先解决歧义。如果无法支持某项请求的指标或拆分，请记录原因，并说明需要哪些证据才能补充。将流程说明、来源清单和可复现性说明保存在来源元数据、来源说明或支持性材料中，而不要放在报告正文中。

   如果直接选择此技能，且用户明确要求“使用示例数据”或“使用示例数据”创建报告，但未指明或附上其他示例，则将此表述视为选择内置的合成演示数据。相对于此技能定位 demo-product-growth.csv，分析其中的数据行，标注其为合成数据，不要在工作区中寻找替代数据，也不要编造替代数据。

4. 提炼报告主线。

   在选择呈现形式前，写出或在脑中核实一份精炼、结论优先的报告主线，包含以下条目：

   • 问题
   • 有助于决策的答案
   • 指标、队列、分母、时间窗口和比较依据
   • 按请求的细分或驱动因素呈现的发现及其支持证据
   • 答案涉及比较、近似因果关系或令人意外时的敏感性或验证检查
   • 可能改变解读的注意事项
   • 建议的后续步骤、监测点或待解决问题

   确保报告各部分清晰区分，并删除重复的功能或指标覆盖。每个主要部分都应在报告中承担明确的作用，并将结论与证据、解读和具体影响相结合。

   如果主线只有标题、执行摘要和一张图表或表格，请停止并扩展证据链后再呈现，除非用户明确要求简报。

5. 规划面向读者的结构。

   在构建呈现内容之前，先拟定主要部分的顺序、读者可见的部分标题，以及每部分预期使用的证据形式。存在真实数据时，量化发现默认使用可视化；精确查找、审计细节或图表会掩盖要点时使用表格。如果量化部分没有可视化，请在来源说明或支持性材料中记录省略原因。

   每个计划中的主要部分都必须有一个会出现在最终报告中的读者可见标题。不要仅依赖图表标题、表格标题或未渲染的结构来充当部分标题。

   在构建呈现内容前，先应用报告深度门槛：

   • 执行摘要不计入证据部分。
   • 包含定量发现的报告，必须在读者需要依据这些定义解读证据之前，清晰呈现指标和队列的定义。
   • 比较报告必须包含细分层面的解读，不能只有汇总值。
   • 涉及因果关系或行为差异的报告，必须在相关发现附近至少附上一条验证、敏感性或局限性说明。
   • 只有一个叙述区块，再加上图表证据的报告内容过于单薄；除非用户明确要求简报、行内回答或单图解读。

6. 应用报告标准和受众要求。

   建立通用结构后，应用本技能中的相关标准。将计划中的每个主要部分对应到所选受众规范的 Required Structure 条目，并记录任何合并、重命名、重新排序或省略条目及其原因。

7. 设计可视化内容和表格。

   所有报告可视化内容都必须通过 $visualize-data，用于选择图表、制定图表规范并进行最终上下文质量检查。除非用户要求了解方法，或相关细节会改变面向读者的结论，否则将图表选择理由、验证器备注和质量检查详情保留在工作笔记、来源备注或支持材料中。确保每个可视化内容或表格都能支撑具体的报告主张，而不是仅作装饰性背景。渲染前，为每个可视化内容规划一段相邻的解释性文字。图表、表格和预览输出仅保留在所选报告载体中。

8. 选择并构建一种交付载体。

   在报告主线和证据计划明确后，使用选定的单一交付模式。除非用户明确要求将第二种模式作为单独的后续交付，否则不要添加第二种模式。

   构建所选载体时，确保其保留报告的阅读路径、可见标题、证据顺序、注意事项和来源元数据。将 Report Standards 中的交付模式规范作为所选载体的实现指导，而不是替代报告构建工作流。

   如果用户要求以托管链接分享 MCP 应用报告或仪表板，请在 MCP 应用有效后，使用 Artifact 应用的 Site Creator 分享流程。调用 export_artifact_package，将当前清单、范围受限的快照、软件包元数据、可安全内嵌的源文本和真实的 MCP Artifact 运行时封装为与 Site Creator 兼容的应用；不要手工编写独立 HTML，也不要发布依赖 MCP 专属主机负载状态的查看器。遵循 sites-hosting 工作流；除非用户要求更严格的访问权限，否则新托管报告默认使用 workspace_all 访问权限。

   修改现有报告时，应以当前渲染的报告和来源元数据为起始材料。除非用户明确要求更改，或所请求的编辑必然需要进行范围有限的关联更新，否则应原样保留所有现有部分、可视化内容、表格、来源、数据集、标题和注意事项。要求添加某个部分、替换图表、调整可视化样式或自定义报告的一部分，并不意味着要求概述、替换、重新排序或删除报告的其余内容。在所选载体中渲染完整的修订版报告；如果原报告完整，不要交付仅包含一个部分、精简版或不完整的替换材料。 对验证或渲染问题进行修正时，应就地修改之前的完整报告产物。将更改限制在受影响的可视化、表格、章节、数据集或来源，以及任何直接依赖项上。如果所选呈现界面包含无关的 ID、阅读顺序、叙述文本、注意事项、建议、来源元数据、软件包元数据和数据集，则应保持这些内容不变。渲染前，对比新旧产物结构，并确认只有预期部分发生了变化。如果无法获取之前的完整产物，请停止并说明这一阻碍，而不是凭记忆重新构建一份精简替代品。

9. 验证最终报告。

   检查渲染后的报告本身，而不仅仅是源文件。确认：

   • 报告开篇直接回答用户的问题
   • 每个主要部分都有清晰可见的标题
   • 论点、可视化内容、表格、注意事项和影响按预期阅读顺序呈现
   • 所选交付界面符合其特定模式的标准
   • 支持性证据和来源说明足以满足可审计性要求

   如果任何一项检查未通过，请在交付前修复报告。

10. 交付所选报告。

首先说明所选报告产物的结果或阻碍。然后只列出相关的 MCP 应用产物或 HTML 报告路径，以及支持性来源、SQL、代码、笔记本和图表产物。在 HTML 模式下，实际的交互式 report.html 文件是主要交付物。只有在明确标注为非交互式 QA 预览时，才可附上渲染后的 PNG 或截图；绝不能仅交付 image.png、截图或其他扁平化图片作为报告。如果宿主无法在页面内渲染 HTML，请附上或链接 .html 文件，而不是将其扁平化。交付前，根据质量标准对报告进行自检。如果需要共享或转换 HTML 且操作安全，请解决呈现界面问题；否则，记录共享不安全、不可用或被明确豁免的原因。不要用聊天摘要代替报告。

报告标准

PDF 导出规范

当用户要求将 Data Analytics 报告、仪表板或内嵌图表界面导出为 PDF 时，请使用 report-to-pdf。该子技能负责 PDF 转换的具体机制，使此根工作流不受交付模式限制。

MCP 应用报告规范

如果所选报告界面是 MCP 应用报告，请阅读 mcp-app-report.md。该文件负责 MCP 应用报告的具体机制，使此根工作流不受交付模式限制。

HTML 报告规范

• 仅在 Skill Configuration 中的交付规则允许时使用 HTML 模式；在 Codex 桌面版中，除非用户或下游转换明确要求 HTML，否则不要在尝试 MCP 之前选择 HTML。
• 对于每种 HTML 报告路径，都要阅读 recharts-html.md，从 ../../assets/html-report-shell.html 开始，并根据选定的受众规范保留或调整其报告 data-contract-section 属性。使用其打包的 Recharts 运行时呈现动态图表，并将使用相同数据的静态 SVG／表格回退内容直接保留在 HTML 中。
• 在每份 HTML 报告中保留外壳对系统外观的自动支持：保留 <meta name="color-scheme" content="light dark">、语义化颜色令牌，以及 @media (prefers-color-scheme: dark) 令牌覆盖。在浅色和深色系统模式下检查报告内容、图表、回退内容、来源工具提示和焦点状态；不要将此行为替换为仅支持手动切换的主题开关。
• 保持 HTML 阅读路径具备报告风格：先给出答案，显示分段标题，将证据与解读放在一起，并在适当位置说明注意事项；保留来源元数据，除非用户明确要求，否则不要附加可见的来源、备注或可复现性附录。
• 在 HTML 报告中，每个有来源支持的量化值都必须有直接关联的来源工具提示。这包括标题和 KPI 数值、行内数字声明、表格数值，以及其他由检索数据得出的显示数字。工具提示必须标明 Source: <source system, connector, or artifact>；对于结构化数据，还必须标明 Table: <fully qualified table or view>。对于由联接或多个输入得出的值，列出所有具有实质贡献的来源和表。对于非表格证据，将 Table 替换为准确的 Dataset、File 或 Document 名称。切勿虚构来源信息；明确标注无法获取的表或来源，并在来源备注中保留这一信息缺口。
• 使用外壳的 source-tooltip 模式，将 HTML 来源工具提示实现为真正支持悬停和键盘焦点的交互方式，而不能只使用原生 title 属性。数字在没有交互时也必须清晰可读，工具提示文本应简洁。将每个工具提示关联到其支持的数字；仅当一个共享工具提示能明确涵盖所在组中的每个数字，且它们的来源信息完全相同时，才可使用共享工具提示。
• 在叙述性数值、KPI 和指标卡数值、表格数值及图表数字中使用相同的 source-tooltip-content 样式。不得创建卡片、叙述、表格或图表专用的工具提示变体。前景色、背景色、字体排版、内边距、圆角和阴影必须一致；工具提示文本必须明确使用共享的前景色，不得继承其周围数值的弱化或强调颜色。
• 仅靠 HTML，动态图表 Recharts 和使用相同数据的静态回退内容无法为每个数据标记提供来源信息。为每个图表添加可访问的来源工具提示，列出绘图数据所用的所有重要来源和完整限定表名，但只能将可见的 Source 提示作为悬停和焦点触发区域，不能将整个图表或图表图片设为触发区域。不要在面向读者的工具提示中包含查询文本、凭据、请求 ID 或本地路径。
• 为图表添加可见的来源提示，使其工具提示易于发现；不要依赖悬停在没有标记的图片上。来源支持的行内数字必须保留点状下划线或其他等效的可见提示。
• 交付前，检查生成的 report.html 本身，而不仅仅是外壳或截图。验证 Recharts 动态挂载已渲染、脚本无法运行时相同数据的回退内容仍然清晰可读，并确认交付文件不依赖同级图表图片、本地运行时或远程脚本。验证每个有来源支持的可见数字都由 source-tooltip 包裹；每个工具提示都包含真实、非占位的来源信息；每个图表都具有可见的来源提示，其工具提示内容的悬停／焦点目标是 Source 提示，而不是整个图表图片。对比典型的行内、卡片、表格和图表工具提示，确认它们使用相同的计算后前景色、背景色、字体排版、内边距、圆角和阴影。不要将 HTML 展平为图片作为报告交付物。仅在使用 HTML 报告时使用 report-to-google-doc 或 report-to-google-slides，不要将其用于实时 MCP 应用报告。

Narrative

• 每份报告都必须有一个简短、面向读者的纯英文标题。对于 HTML 报告，文档标题和可见的页面标题必须相同。对于 MCP app 报告，请遵循 mcp-app-report.md。
• 不要在未标注的副标题、导语、范围说明或第二个摘要块中重复标题或执行摘要。
• 将报告标题和执行摘要作为两个独立的可见元素。报告标题是整个报告的名称，不能替代执行摘要部分。对于利益相关者报告，请在标题后立即显示 Executive Summary 部分标题，再呈现摘要内容。
• 利益相关者报告应以执行摘要开篇，直接回答用户的问题。默认采用 2-4 条要点或简短的小段落，并为每条要点添加加粗的主题句。
• 技术报告应以技术摘要开篇，先说明主要结果，再提供读者判断其可信度所需的定义、方法、不确定性和局限。
• 报告的主要部分应以结论开头，而非背景铺垫。使用能体现洞察的标题，不要照搬通用标签。
• 所有交付模式下的每个主要报告部分都必须有可见标题。标题是面向读者的报告约定的一部分，而非仅供内部使用的元数据。在 HTML 报告中，应在各部分内将标题呈现为标题元素。对于 MCP app 报告，请遵循 mcp-app-report.md。当证据支持时，应使用“API ARR 正领先于计划”等与内容相关的标题，而非通用标签。
• 报告应有清晰、从上到下的阅读顺序。除非用户要求仪表板，否则不要将报告做成仪表板网格。默认采用单列文档布局；只有在所选界面中标签、系列和解读均清晰易读时，才可使用半宽可视化区块。
• 使用报告 Markdown 区块呈现叙述性洞察和解读。每个独立布局或可编辑的主要报告部分都应有自己的 Markdown 区块；不要在同一个 Markdown 正文中放置多个同级的 ## 部分标题。仅当内容从属于同一张卡片时，才使用 ### 标题。图表和表格的标题应保持中性，并在相邻的叙述区块中呈现结论，不要把论点藏在可视化元数据中。Markdown 区块是叙述报告内容的主要位置。
• 报告应内容充实，能够独立呈现。不要交付主要由图表或表格组成、仅附简短摘要的报告。读者应能仅通过叙述内容理解答案、证据、解读、注意事项和建议的下一步。
• 灵活设置部分名称和内容顺序，但报告仍须完成核心任务：直接回答用户的问题；在影响解读时说明指标、群组、分母、时间窗口和比较依据；为每个重要数值或可视化提供通俗易懂的解读；说明发现为何与决策相关；指出仍存在哪些不确定性或哪些因素可能改变结论；并在证据支持时提供切实可行的下一步。
• 除执行摘要外，也应在能提升可读性的地方使用丰富的 Markdown：重要正文段落应加粗主题句，建议应使用标准 Markdown 列表，避免把列表项合并成冗长段落。
• 使用有序或无序列表时，每个列表项都应单独占一行 Markdown。不要把 1.、2. 和 3. 放在同一段中，也不要将本应为列表项的内容写成无编号的续行。
• 对于执行类、战略类和诊断类报告，标题后的第一段叙述内容必须是执行摘要。不要在摘要前插入未标注的导语、重复摘要、方法说明、注意事项部分、KPI 条带或指标卡行。
• 对于诊断类和战略类报告，不要在执行摘要前默认插入 KPI 卡片行。如果有可用的核心实际值、差值和状态信号，KPI、投资组合、MBR/QBR 以及每个领域单独成节的报告，可在摘要后使用紧凑的 KPI 卡片条带。
• 不要在 KPI、投资组合或多领域报告的执行摘要正下方放置宽泛的比较表作为主要摘要内容。如果有可用的核心实际值、差值和状态信号，应使用指标卡快速呈现总体状态；表格则用于补充精确数值或审计细节。
• 每张指标卡应包含一个核心数值，但这并不意味着只能有一个 metrics[] 条目。应使用带标签的简短信息标签，补充与该核心数值直接相关的比较背景，例如上一时段的数值、目标值或差值。如果执行摘要或发现中已经采用了与决策相关的方向性比较，应在后续比较指标中保留该比较，并设置 signed: true；将独立的次要指标移至其他卡片、图表、表格或叙述区块。
• 应根据报告所需的决策来确定核心指标卡的数量。不要为了凑成四张或任何偏好的数量而增减卡片。只纳入彼此不同且有意义的核心指标，将相关卡片归在同一条带中，并将无关指标拆分至另一条带或辅助表格；数量为奇数也可以，因为制品渲染器会以响应式方式平衡各行。
• 百分比数值在所选界面中必须采用一致的数值尺度。
• 每个主要报告部分都应包含一个主张及其证据和解读，并进一步说明其意义，指出相应的影响、风险、机会、建议、监测事项或后续行动。
• 证据支持采取行动时，应给出建议的下一步。如果证据仅支持监测，应说明要监测的事项及原因。
• 当重要的不确定性、证据缺失或后续分析可能改变决策时，应列出待进一步解答的问题。只有在不存在与决策相关的未决问题时，才可省略该部分，并应在源注释中记录这一选择。
• 应在会影响解读的位置明确说明注意事项和不确定性，同时避免喧宾夺主，遮盖报告结论。

证据与来源

• 每项主要论断都应基于任务期间保存或检查过的数据、代码、查询结果、笔记本输出、源文档或渲染图表。
• 在所选界面支持的情况下，在相关段落或可视化附近，将重要数字、图表和建议与易读的来源元数据关联起来。
• 除非出于可信度需要，否则应将原始路径、笔记本位置、临时目录、请求 ID 和面向实现的审计详情保留在来源元数据、来源注释或辅助产物中。在 HTML 报告中，应在 HTML Report Specifications 要求的来源工具提示中公开来源系统和表名；除非出于可信度需要，否则不要将其放入始终可见的叙述内容中。
• 将来源 SQL 保留在来源元数据、来源弹窗、关联的查询产物或辅助注释中。除非用户明确要求查看、编写、审查、调试或获取 SQL 或查询方法，否则不要将来源 SQL 粘贴到报告正文或最终聊天交接内容中。
• 除非用户明确要求提供方法说明，否则不要添加可见的底部来源、注释或可复现性章节。
• 即使数据集来源、查询或转换产物、渲染代码、输出文件夹、假设、未包含的指标和图表 QA 注释不会显示在报告正文中，也应将其保留在来源元数据、来源注释或辅助产物中。
• 提供足够的证据入口以便审计，同时避免创建繁重且可见的论断关系图。在界面支持的情况下，优先使用块级来源引用。

可视化与表格

• 报告中的可视化标题应保持中性：仅包含图表／表格名称，以及仅在指标、分母、群组、筛选条件或时间范围需要说明时添加的简短描述。叙述性洞察和注意事项应放在相邻的 Markdown 区块中。
• 每个报告可视化都必须在阅读流程中紧邻其前方或后方附有解释性段落。段落应说明要点、如何阅读可视化，以及解读所需的影响或注意事项；仅有图表标题、副标题、说明文字、指标卡或表头并不满足此要求。
• 图表和表格的副标题应补充标题未涵盖的、面向读者的洞察或解读背景。优先说明趋势方向、幅度、转折点、排名、比较依据、范围、时间段、计量单位、筛选条件／排除项、分母、群组、样本量或比较基准，例如 4 月中旬后增长加速，并在期末达到阶段高点 或 FY2021-FY2024，数值单位为百万美元。除非需要通过 showDescription 或等效标志来明确阅读路径，否则默认隐藏描述和副标题。
• 在可见的 Markdown、图表标题／副标题、说明文字、表格标签和生成日期信息中，优先使用易读的日期。查询绑定、来源元数据和其他机器可读字段中保留 ISO 时间戳。
• 不要将源表名、原始查询 ID、仪表板 slug、笔记本路径、SQL 意图、指标定义或实现标签用作图表／表格副标题。除非来源身份对读者信任至关重要，否则应将这些细节放在来源元数据、来源说明或配套材料中。对于 HTML 报告，来源系统和表名也必须出现在相关数值或图表的来源工具提示中，以便在不让副标题显得杂乱的情况下保留这些信息。
• 渲染报告表格前，应逐一核对表格副标题与表格标题及可见列。如果副标题未能说明行的范围、涵盖的时期、数值的计量方式、适用的筛选条件或所作的比较，则应改写或省略，而不是退而使用来源名称。
• 不要将可视化缩小为难以阅读的侧边卡片。对于信息密集的图表、较长标签或需要更多空间的 HTML 图表回退方案，应使用全宽区块。
• 在阅读流程中，应将报告图表单独放在清晰易读的行或区块中，除非已在最终上下文中检查半宽布局并确认其可读。不要使用狭窄的右侧栏图表卡片呈现报告证据。
• 报告趋势图需要足够的观测数据，才能让趋势形态值得解读。如果报告图表只能展示少数几个锚点时期，应先通过 $visualize-data 请求更细的粒度、更长的回溯期或有意义的细分，再进行渲染。如果数据源无法在不误导读者的情况下支持这些要求，则应改用 KPI 条带、分组时期柱状图、表格或简洁的叙述性比较，并在来源说明或配套材料中记录未采用更丰富趋势图的原因。
• 对于行数较少、以叙述为主且适合展示的报告表格，默认使用宽松密度。仅审计／明细表或紧凑型查找数据才使用高密度表格。
• 正／负表格颜色仅用于明确标记为 movement: true、semantic: "movement" 或 role: "movement" 的列。这些列中的数值应带有预期的正负号或箭头，例如 +12%、-$4.2M、↑3 pp 或 -18。构成、占比、份额、百分位数和当前值列应保持中性。
• 对于多图表报告，应在来源说明或配套材料中保留一份精简的图表映射。逐一列出每个可视化所属的报告部分、分析问题、所选图表系列／类型、字段和可支持的结论。重复使用图表类型必须有充分理由；不同报告部分若分别探讨状态、构成、差异、驱动因素或分布等问题，不要默认所有可视化都使用趋势图。
• 导出或转换报告时，每个交互式或界面原生可视化都必须有清晰易读的静态表示。如果静态表示缺失或具有误导性，应记录为阻碍项。

指标与语言

• 在披露实现细节之前，先用通俗易懂的语言描述指标。
• 在报告中使用指标之前，先说明其定义、群组、分母、筛选条件和比较基准。
• 选择最便于受众理解的粒度：用户、账户、工作区、任务、轮次、会话、请求、收入、端点、客户、组织，或其他面向业务的单位。
• 为原始数字提供背景：占活跃群体的比例、占漏斗上一步的比例、占总变化的比例、与基准值或目标值的比较、与同类群体的比较，或与历史区间的比较。
• 在叙述文本、图表标签和摘要中使用大数字的简写形式，例如 899k、10.9k 或 1.2M。精确的千位分隔数值仅用于审计表、SQL 输出、附录，或精度会影响解读的情况。
• 除非对建立信任至关重要，否则不要在主要叙述中出现面向实现的事件名称、字段名称、表名称和精确谓词。将其放入注意事项、来源元数据或简短的括号补充说明中。
• 根据所选受众润色最终语言：简洁、开门见山、不含流程说明，方法论的深入程度以受众建立信任所需为限。

质量标准

最终交付前，请确认：

• 如果以下任何必需项未通过，请修正报告，或在最终定稿前明确记录阻碍问题。
• 除非用户明确要求混合模式或第二种交付模式，否则只使用一种交付模式和一种受众规格。
• 所选受众规格中的 Required Structure 应对应报告中可见的章节；任何合并、重命名、调整顺序或省略，都应记录在来源说明或辅助材料中。
• 已检查报告主线、报告深度门槛、所选交付模式规格和渲染后的报告。
• 渲染后的报告能直接回答用户的问题，包含醒目的面向读者的分段标题，并且每项主要结论都配有证据、解读、必要的注意事项，以及对决策有用的启示。
• 在最终结论可用于决策之前，已明确说明定义、分母、基准、用户要求的指标和注意事项；对于省略的指标，已说明原因及所需的后续跟进。
• 方法论的深入程度符合所选受众；对于省略的用户要求指标，已说明原因及所需的后续跟进。
• 可视化图表和表格均通过 $visualize-data 生成，并已在所选界面中检查；图表保持易读，包含有用的副标题、每个可视化图表旁边的说明段落、来源元数据和辅助说明。
• HTML 报告中的每个有来源支持的定量值，都有可正常使用的悬停和键盘聚焦来源提示；每个静态图表也都有等效提示，并注明精确的来源系统及表、视图、数据集、文件或文档出处。
• 来源和可复现性说明、图表映射及省略原因均保存在元数据、来源说明或辅助材料中，不会让可见报告显得杂乱。
• 最终交付内容列出选定的报告文件及相关佐证材料，而不是以聊天摘要代替报告，也不应额外交付用户未要求的并行应用和 HTML 报告。