visualize-data

相关技能

如果视觉内容需要解释指标变化，请使用 $metric-diagnostics。

如果视觉内容属于一份长期使用的分析报告，请使用 $build-report。

数据可视化

创建在分析上可靠、易于理解且足够精良、可用于报告、备忘录、幻灯片、仪表板、笔记本、小组件或 HTML 产物的定量可视化。将图表视为支持结论的证据。重新设计外观吸引人但分析上薄弱的图表，并修改技术上正确但难以解读的图表。

运行时交付路由

如果已明确识别 surface = chatgpt_web 和 mode = work_mode，则不要使用 Data Analytics MCP 图表或表格小组件进行渲染，不要为内联交付调用 render_chart 或 render_table，也不要选择 MCP 产物作为视觉呈现界面。只有在其他工作流已选择内联交付后，才适用此分支；它不会选择内联交付而非报告、仪表板、HTML、笔记本或其他界面。对于已选择的内联视觉内容，优先使用原生 Work Mode 渲染，并阅读 native-inline-visualizations.md，以选择并调用 charts_widget_v2 或 app_block。对于一个受支持的 bar、line、pie 或 scatter 图表，在此运行时中应将 charts_widget_v2 视为可直接呈现，并在考虑备用方案前输出其实时 genui 内容引用；不要自行声称它不可用，也不要查找它。完整的外层结构为 genui{"charts_widget_v2":{"content":{...}}}：将 {...} 替换为真实图表规范，并直接输出该引用，不要使用 Markdown 反引号。仅有内层图表规范并非有效响应；不要输出裸 JSON、纯 HTML 或代码围栏。仅当宿主支持 app_block 时才使用它。如果已安装 Visualize 插件，还要查阅并遵循其当前有关原生图表或应用区块编写的指导，同时以本技能的交付门槛和备用方案顺序为准。如果输出的原生视觉内容被拒绝或渲染失败，请使用适合非 MCP 界面的可复现静态图表或 Matplotlib 图表；仅当无法交付任何视觉渲染器时，才使用紧凑表格。当原生渲染失败需使用备用方案，或用户明确要求 Python、静态图片／文件、面向笔记本的输出或导出时，使用静态图表或 Matplotlib 绘图。在 Web Work Mode 中，Data Analytics MCP 工具成功返回并不代表已完成交付，因此除非所选的原生或非 MCP 界面确实完成渲染，否则不要声称视觉内容已绘制或渲染。MCP 服务和其他可调用工具仍可作为有效数据来源。

只要选定的报告或仪表板交付界面是 HTML，就要阅读 recharts-html.md，并使用其打包的 Recharts-in-HTML 路径及相同数据的静态备用方案。这包括 Codex 明确要求的 HTML、ChatGPT web Work Mode，以及用于转换为 PDF、Google Docs 或 Google Slides 的 HTML。

除非已明确识别为 Web Work Mode，否则保持现有界面选择规则不变。

图表选择

当最终呈现形式为报告、仪表板、幻灯片、笔记本、微件或 HTML 成品时，常见的呈现形式应在图表约定中明确说明。

数据关系	最佳图表	使用建议
随时间或有序轴变化的趋势	line	显示足够的数据点以呈现趋势形态；仅当填充区域有助于表达数值大小时才使用 area，仅在密集的 KPI 卡片中使用 sparkline
随时间变化的组成	stackedArea	当各部分应呈现为一个整体时使用；当比较各组成部分的变化轨迹更重要时，改用 line
跨类别比较	bar	当顺序没有语义意义时进行排序；标签较长时使用水平条形图；避免使用冗余图例
排名或前 N 项	leaderboard	保持紧凑，且仅使用一个度量；当比较需要更多图表上下文时，改用排名 bar
部分与整体的组成关系	堆叠 bar	明确标出分母；仅在扇区较少、只需粗略了解时使用 pie
分布或离散程度	histogram	使用能呈现分布形态的数值分箱；当重点是比较组别时，改用 boxPlot
跨组分布	boxPlot	当中位数和离散程度比完整分布形态更重要时使用；当需要展示分布形态时，改用 histogram
两个数值变量之间的关系	scatter	使用有意义的观测粒度对应的数值 x 和 y，并提供足够多的不同数据点以呈现规律；安全可行时，保留点标签、样本量／规模字段，以及一个有用的分组候选项
密集的二维模式或队列矩阵	heatmap	用于呈现矩阵形态或强度；当点级差异更重要时，改用 scatter
从起始值到结束值的加法桥接	waterfall	仅当各驱动因素能够准确累加至结束值时使用；否则使用排名 bar
有序阶段进展或流失	funnel	仅用于有序的单系列阶段；当漏斗几何形状会扭曲比较结果时，优先使用阶段 bar

工作流

1. 选择图表前，先定义分析问题和一句话结论。确定最终呈现界面、预期比较内容，以及使可视化诚实可信所需的背景信息。
2. 从 Chart Selection 中选择最简单且有充分依据的图表类别和变体。如果可视化属于 $build-dashboard 或 $build-report 生成的成果，请与相应工作流协调；如果需要验证支持性分析，请使用 $validate-data。
3. 在编写绘图代码、配置仪表板或开展特定渲染器的实现工作前，先编写一份简洁的图表契约。包括：
   • 分析问题和结论
   • 标准图表类别和具体变体
   • 所选可视化的数据充分性：预期行数、趋势视图的时间点数、散点图的观测数和粒度、请求的日期范围和粒度，以及首次查询结果过于稀疏时的回退方案
   • 具体渲染器已选定时，注明界面原生图表类型、Recharts HTML 图表类型，或明确的静态渲染器
   • 仅在选择交付界面后注明交付专属约束；对于 MCP 小组件或应用成果，请使用共享 MCP 规范
   • 调色板策略、批准使用的调色板根色，以及非颜色区分方案
   • 输出占用空间、最终容器、导出路径或交付目标，以及最终 QA 检查界面
4. 选择与最终呈现界面匹配的交付路径。
   • 在明确识别为 Web Work Mode 的情况下，只有当当前工作流已选择行内或聊天可见的交付方式后，才读取 references/native-inline-visualizations.md，并优先使用原生 Work Mode 渲染；行内交付时，不要调用 render_chart 或 render_table。对于一个受支持的 bar、line、pie 或 scatter 图表，请先输出可直接呈现的 charts_widget_v2 实时内容引用，再考虑回退。只有在该引用被拒绝或无法渲染，或所请求的图表类别没有合适的原生渲染器时，才使用可复现的静态图表或 Matplotlib 图表；仅当无法交付任何可视化渲染器时，才使用精简表格；不要将 Data Analytics MCP 工具结果描述为已渲染。仅在原生渲染失败时回退，或明确要求使用 Python、静态图片/文件、notebook 或导出时，才使用静态图表或 Matplotlib。
   • 在 Web Work Mode 之外，对于临时、行内、聊天可见或其他未明确指定的图表请求，默认使用 Data Analytics MCP 图表小组件。除非用户明确要求使用 Python、静态图片/文件、notebook 代码、HTML、BI/仪表板编辑、导出演示文稿/文档，或不需要渲染的成果，否则将“制作/显示/渲染此图表”视为 MCP 小组件请求。
   • 只有当用户明确选择某个报告、仪表板、BI、notebook、幻灯片或静态 HTML 界面，或当前报告/仪表板工作流在图表渲染前已选定该界面时，才使用所选界面的原生图表基元。
   • 所选报告或仪表板界面为 HTML 时，必须读取 references/recharts-html.md，并使用其打包的 Recharts 运行时和基于相同数据的静态回退方案。
   • 除 Web Work Mode 原生渲染失败时的回退情形外，只有当用户明确要求使用 Python、独立静态图片/文件或面向 notebook 的输出时，才使用静态 Python 绘图。选择可复现的本地渲染器，导出所需格式，并检查输出。不要将此路径作为 HTML 报告或仪表板的默认方案。

• 若由受管控的 BI 或仪表板原生小组件负责该界面的渲染，则应使用这些小组件；本技能应提供可视化规范和 QA 标准。
• 只有当最终界面确实需要本地渲染、自定义交互、离线可移植性，或需要承载超出小组件容量的大型成果时，才实现本地 HTML/CSS/SVG/canvas/JavaScript 可视化。

5. 按以下顺序构建：格式、结构、颜色，然后 QA。先选择图表类别、变体和交付界面；再确定标签、注释、基准和保留信息；最后选择调色板策略和具体颜色。
6. 在实际使用场景中渲染或导出图表。对于 HTML 报告和仪表板，请检查实时 Recharts 挂载图表及其使用相同数据的静态回退图表。对于明确要求的独立静态输出，请保存并检查用户要求的图片格式。
7. 在最终报告、幻灯片、仪表板、notebook、小组件或 HTML 布局中检查可视化。如果图表、标签、配色系统或容器未通过最终场景 QA，请先修改再交付。
8. 对于包含多个可视化内容的已交付报告或仪表板，请在备注或源材料中维护一份精简的图表清单。注明章节、分析问题、所选类别和图表类型、字段、支持的结论、调色板策略，以及交付成果、图片路径或来源。

标准

选择规则

从读者需要解答的分析问题和进行的比较出发，而不是从偏爱的图表类型出发。顶层类别应保持精简：

• 表格与记分卡
• 趋势
• 比较与排名
• 构成
• 分布
• 关系
• 不确定性与基准
• 矩阵与队列
• 分解与进展

高亮多系列折线图、李克特量表、饼图、帕累托图、瀑布图、分面点图与区间图和队列热力图等具体形式，是这些类别中的变体，而不是同级类别。

• 使用图表呈现形态和对比；使用表格进行精确查询。如果表格会展示 3–8 个可比较的实体，且只有一个主要数值指标，除非重点是按行精确查询，否则优先使用条形图、点图、棒棒糖图、排行榜或其他图表。
• 当审查过的证据包含许多可比较的值、行、类别、细分项或时间点时，如果所选交付界面可用且安全，默认在该界面上渲染简单图表。仅当主要任务是按行精确查询、数据过于稀疏而无法如实制图、用户只要求表格或文字，或所选界面无法支持实用的可视化时，才跳过渲染。
• 不要仅仅因为提示词中出现“趋势”或“趋势变化”，就选择 line。先判断读者需要了解的是当前状态、变化、与计划的偏差、构成、集中度、驱动因素、进展还是分布。
• 不要交付信息不足的趋势图表。对于折线图、面积图、迷你趋势图、指数趋势图或其他时间序列视图，先尝试展示更细的时间粒度或更长的日期范围，让序列包含足够多的观测点以呈现形态。默认情况下，趋势可视化至少应有 8–12 个时间点；如果现有证据只有少数几个锚定时段，请查询每日或每周数据行、延长回溯范围，或添加有意义的细分项或对比项，然后再渲染。如果问题实际上只是比较少数几个离散时段，则改用 KPI 条、分组条形图、斜率图、表格或文字说明。
• 不要交付信息不足的散点图。实用的散点图需要足够多的可比较观测值，以展现形态、聚类、异常值或例外；默认应至少有 12–20 个有意义的数据点，少于 8 个时通常应改用表格、条形图、点图／棒棒糖图或文字对比，除非每个数据点都经过有意挑选并带有标签。如果首轮结果只有少数几个细分汇总值，请有针对性地尝试查询更细的分析粒度，例如账户、工作区、用户群组、客户、模型、端点、路由、地理区域或按时段细分的分组。所有绘制的数据行必须采用相同粒度；不要在同一张散点图中混合总计、平均值和明细行。
• 对于散点图，选择的 x 轴和 y 轴指标应有合理可能独立变化，并且使用相同的分母、时间窗口、总体和筛选条件。加入用于判断可靠性的分母、样本量或业务量指标；仅当第三项指标会实质改变解读时，才使用尺寸编码。对于数据点较少或面向管理层的散点图，添加数据点标签字段，并保留有意义的分类字段，例如细分项、套餐、路由、产品线、模型系列或地区，以便按需着色或筛选。避免按唯一行 ID 着色；要精确标识时，请使用标签或表格。
• 标签较长时使用横向条形图；当顺序没有语义意义时，使用排序条形图。
• 仅在单一数值、3–8 个可见行的 Top-N 预览中使用紧凑的排行榜式排序条形图。紧凑型仪表板卡片默认显示 5–6 行。长尾浏览或精确查询应使用分页表格，呈现累计集中度应使用帕累托图，呈现加总后从起点到终点的驱动因素桥接应使用瀑布图。
• 不要用排行榜对 KPI 定义或时间窗口定义进行排名，例如最新 DAU 与 WAU、MAU 之间的比较。最新值应使用 KPI 卡或紧凑表格；变化或关系问题应使用趋势图、指数趋势图、占比趋势图或比率图。
• 条形图比较不同类别下的同一指标时，使用一个分类轴和一个定量轴。不要将同一分类字段设置为 color、series 或分组条形图编码，仅仅为了给每根条形着色；这会产生冗余图例，并暗示多出一个分组维度。如果界面支持在不添加图例的情况下按类别着色，请使用调色板／样式选项或直接标签；否则使用单一标记颜色。
• 条形图比较不同 KPI 类别中单位相同的变化时，例如各指标最新的周环比百分比变化，按类别使用不同条形颜色有助于快速浏览，但这应仅用于样式，而不应显示为分组或图例，除非存在第二个分类维度。
• 条形图比较彼此无关的业务实体或组成部分时，例如产品、模型系列、细分项或席位支持领域，如果类别身份很重要，不要让所有数据行都使用同一种固定颜色。优先使用分类样式和直接标签；只有当同一语义实体对应一个重复指标时，才使用单一颜色。坐标轴标签已标明类别时，避免添加颜色图例。
• 对于活跃用户仪表板，最新 DAU、WAU、MAU、Plus DAU 和 Plus WAU 值应使用 KPI 卡；随时间变化应使用趋势图或指数趋势图；问题涉及构成或比率时应使用占比图或黏性指标视图；彼此无关的指标周环比变化应使用分类横向条形图。
• 优先在同一图表家族中升级变体，再另创新图表类型：折线图改为小倍图，条形图改为点图／棒棒糖图，散点图改为密度图；仅当圆形形式确实有助于解读时，才将堆叠条形图改为饼图。
• 饼图、帕累托图、瀑布图和李克特量表应作为变体，而不是默认选择。
• 除非第三个变量会实质改变解读，否则避免使用气泡图。
• 如果省略业务量、分母、样本量或群组背景可能造成误导，请将其纳入。
• 在包含多个领域的管理层报告中，反复使用折线图是一个危险信号。仅当主要问题是随时间连续变化时才使用折线图。对于计划偏差，可考虑带参考线的点图／棒棒糖图或条形图；对于构成，可考虑堆叠面积图或 100% 堆叠条形图；对于类别对比，可考虑排序条形图或排行榜；对于加总驱动因素，可考虑瀑布图；对于群组或矩阵结构，可考虑热力图；对于有序进展，可考虑阶段条形图。
• 对于每个领域各占一页的管理层报告，在编写可视化方案前，应先检查图表家族。审查重复使用的图表家族；如果不同章节提出不同问题，却使用了相同的图表家族，则必须说明理由。
• 如果报告中的所有可视化都属于同一图表家族，请在图表映射中记录原因，并确认没有任何章节实际上是在询问状态、构成、偏差或驱动因素。
• 如果全部使用折线图的可视化达到 4 个或更多，则不符合多图表报告规范；除非重新设计报告，采用与数据兼容的替代图表，或减少可视化数量。

Surface And Implementation

• 对于 Web 工作模式之外的数据可视化请求，如果用户尚未选择文件、笔记本、BI/仪表板、报告、幻灯片、文档、HTML 或不渲染输出界面，且 MCP widget 工具可用，则默认使用 Data Analytics MCP 图表 widget 进行渲染。在 Web 工作模式中，只有在已选择内联交付后，才读取 references/native-inline-visualizations.md，并优先使用原生工作模式渲染；对于一个受支持的 bar、line、pie 或 scatter 图表，应在回退前输出直接呈现的 charts_widget_v2 实时内容引用。只有在该引用被拒绝或渲染失败，或请求的图表类型没有合适的原生渲染器时，才先尝试可复现的静态/Matplotlib 图表，再回退到精简表格。Web 工作模式交付时不要调用 render_chart 或 render_table；不要将 Data Analytics MCP 工具返回 ok:true 视为浏览器已渲染该可视化的证明；只有在原生渲染失败并需要回退，或用户明确要求 Python、静态图片/文件、面向笔记本的输出或导出时，才使用静态图表或 Matplotlib 绘图。用户明确选择其他界面时，本技能的输出仅限于该界面的图表选择、数据规划、实现指导和 QA。
• 如果选定的交付界面是 MCP Apps widget 或 Data Analytics MCP 报告/仪表板产物，则选择图表类型后读取 ../../src/analytics-app-core.md。不要让 MCP 支持的类型列表左右非 MCP 界面的一般图表选择。
• 从已审核的查询结果渲染 MCP 内联图表时，调用 render_chart 并提供来源元数据、可供探索的表格、图表编码和显示设置。除非用户明确要求 Python/静态输出或 widget 渲染器不可用，否则不要为同一结果创建中间 Python 图表图片。
• 为图表提供数据的任何表格，其内容都必须丰富于绘制该图表所需的最少字段。如果已审核结果可以安全地包含上下文维度、分子/分母字段、日期或群组字段、排名、基准值、对比时段数值或相邻指标，则不要只提供包含 x、y 及可选系列/颜色字段的源数据表。如果隐私、查询成本、来源限制或指标定义导致无法提供更丰富的表格，则在图表/报告备注中说明这一限制。
• 渲染或导出之前，检查已审核结果表的信息密度。如果图表包含少于 8 个时间点、少于 4 个有意义的类别、少于 8 个散点观测值，或路径几乎是由两三个点构成的直线，则针对支持数据进行一次有针对性的改进尝试：查询更细的粒度、延长时间范围，或增加支持同一结论的相关细分。如果来源限制、查询成本、隐私或指标定义阻止了改进，则记录限制，并改用更诚实的形式，例如 KPI 卡片、离散时段分组柱状图、表格，或附带精确数值的文字说明。
• 如果用户可能会合理地比较指标、交换坐标轴、检查目标值与实际值，或选择关系视图，则应包含多个有意义的量化字段。不要捏造辅助指标，也不要仅为展示更多可能的图表类型而提供原始明细行。
• 为图表准备的数据应支持切合实际的替代方案，而非任意形式。趋势图通常应保留时间字段、数值字段和有意义的细分/对比字段；类别对比通常应保留类别、数值、有用的分组候选字段以及排名/排序上下文；构成图应在可用时保留分母或占比上下文。散点图应保留稳定的点标识或标签、数值型 x 和 y 指标、任何分母或样本量字段、有用的数量/大小候选字段，以及一两个可解释的分组或筛选字段。如果保留的分组候选字段所承载的信息已由坐标轴、分面或表格标签体现，就不要将其用作颜色/系列编码。
• 只有在自定义本地可视化实现符合所选交付模式并通过最终上下文 QA 后，才可视为报告已完成。
• 如果所选界面提供原生图表块，则使用该图表块。不要在图表外围添加多余的装饰性边框。
• 对于每份 HTML 报告或仪表板，都应使用 references/recharts-html.md：嵌入打包好的 Recharts 运行时，保留基于相同数据的静态回退方案，并且不要安装依赖或依赖远程脚本。
• 对于明确要求的独立静态/Python 输出，使用可复现的本地渲染器，并检查导出的结果。不要让静态图片方案取代打包好的 Recharts HTML 默认方案。
• 假设本地环境可能精简或处于离线状态。不要假设网络安装一定成功。

Visual Design

• 让图表标题与展示场景相匹配。报告和仪表板中的可视化标题应保持中性、描述性，并将结论放在相邻的说明文字中。独立静态图表若没有周边说明文字，则可以使用以结论为主的标题。
• 必要时，在副标题中注明指标详情、单位、分母、日期范围、群组、筛选条件、样本量或数据量。注释可以补充注意事项，但不能取代副标题。
• 尽可能在图表和周边输出中使用同一字体系列。优先使用白色或近白色背景、低调的灰色网格线、深炭灰文字，以及以蓝色、金色、橙色、橄榄色和粉色为核心的克制、经批准的调色板基色。
• 不要仅依赖颜色。若需要区分系列或状态，可使用色调、空心填充、标记填充、线型、直接标签、排序或分面。
• 仅当 segment、product_line 或 series 等有意义的分组维度不是唯一的轴类别时，才为其设置颜色或系列编码。单系列图表不设置颜色，也不要仅为生成图例而虚构或重复分组字段。
• 绘图前选择一种调色板策略：
  • 优先单基色系：简单趋势、排名、分布、关系、矩阵和重复面板使用一种非中性色基色及其色阶、空心填充和中性色参考项。
  • 严格限制为两种基色：二元、有符号、焦点与背景、基准、比较、瀑布图、帕累托图、发散图、重点趋势和有序线点图，最多使用两种非中性色基色及中性色。
  • 宽松的多类别：当类别身份是重点时，最多使用五种经批准的基色，例如饼图、堆叠条形图、堆叠面积图、分组条形图和阶段条形图。若需要更多颜色，则归并为前 N 项加“其他”，或更换图表形式。
• 将所选每种基色的 base 色调用作默认的非中性标记颜色。mid 仅用于有意增强对比的特殊情况；dark 用于关键线、轮廓、标签或参考线；light、xlight 或 open 用于辅助填充。
• 根据声明的颜色生成明确的调色板映射。不要让绘图库的类别默认值决定交付图表的颜色。
• 对有符号值，默认避免使用绿色和红色。使用深色与空心／浅色填充、直接标注正负值，并明确显示零线背景；除非有文档记录的领域语义要求例外。
• 瀑布图应使用匹配的中性起点和终点锚点，并且恰好使用两种非中性增量颜色：一种表示正值，一种表示负值。不要为单个驱动因素引入额外色相，也不要使用更深或更浅的非中性色关键线。
• 对瀑布图、桥接图、差异图及其他以变化量为重点的图表，如果结论关注的是相对于较大基数的变化，不要在零点会显著压缩预期变化时强制坐标轴从零开始。应围绕累积路径或变化范围设置聚焦的数值轴范围并留出边距；通过精确的起点／终点／变化量标签、清晰可见的单位，以及必要时在副标题、图注或坐标轴上明确标示聚焦刻度，确保表达准确。若数值跨越零点，或问题关注绝对量级，则应保留零点。
• 标记、关键线、辅助线和参考线统一使用一套线宽系统。基准线、校准线或理想线使用深中性色样式。
• 当标签依赖坐标轴锚点时，应显示左侧和底部的轴锚点。移除不会改善预期比较的刻度、辅助线或连接线。
• 若直接标签可以减少图例查阅，就优先使用直接标签；若直接标签导致拥挤，则使用紧凑的顶部图例。
• 对带有长标签或负值的水平条形图或发散条形图，应为左右两侧明确留出空间。不要为了勉强塞进窄卡片而缩小字体。
• 不要在图表标记中使用渐变、任意颜色的图表背景、不一致或临时设定的圆角，也不要用粗细作为强调手段。
• 对于 HTML 制品，独立图表应占据实际的网格空间：默认 8 columns，最低 6，复杂图表使用 10 或 12，在移动设备上纵向堆叠。多图表行应从左侧／起始边缘对齐。
• HTML 图表容器、图例、KPI 条和注释应与周边报告或仪表板使用相同的 Data Viz System 令牌。如果未实际渲染，则移除未使用的多色 CSS 变量。
• 仅当所在制品采用深色主题时，才使用深色图表变体。对于交付的品牌化 Web 输出，应检查浅色和深色两种变体。
• 对于研究图表，将花朵图案固定在标题右上角。第三方、合作项目及非研究图表中不使用该图案。

质量标准

• 图表类型应遵循 Chart Selection。
• 选择并遵循明确的交付载体。仅当 MCP 小组件可用、安全、有用，且不违背用户要求的输出模式时，才使用它们。
• 除非用户要求了解方法，或相关细节会改变面向读者的结论，否则不要在面向管理层的报告正文中展示图表规范、未纳入图表的说明、验证器备注和 QA 理由。
• 明确要求提供独立静态绘图代码或 Python 绘图代码时，代码应可复现，并明显针对所要求的图表规范进行了调整。通用的临时代码片段仅适用于探索性图表。
• 图表形式必须符合分析比较的需求，且可比较图表中的刻度必须诚实一致。
• 比较绝对量值的标准条形图应从零开始。只有在零基线会明显掩盖预期变化，且图表包含精确标签和清晰刻度提示时，聚焦差值的瀑布图、桥接图、方差条形图和小倍图变化图才可使用非零或缩窄的坐标范围。
• 数据粒度、筛选条件、日期范围、分母和单位必须与图表所支持的论点一致。
• 每张交付的图表都必须有适合其载体的可见标题，以及包含所需单位、时间／群组背景、分母、样本量或总量的副标题。
• 导出的图表或最终容器中的标签、刻度、标题、图例、标注、基准标签和注释不得相互重叠、被裁切，或与证据脱节。
• 长标签、负值、末端外侧标签、零线背景和直接数值标签都需要预留明确的布局空间。
• 多系列填充标记必须使用不同色调、空心填充、描边、标记填充、线型、直接标签或分面进行区分。视觉上完全相同且相邻或重叠的填充不符合 QA 要求。
• 当线型、标记填充、空心填充、描边、排序、分面和直接标签用于区分数据时，应确保它们在灰度下仍清晰可辨。
• 正负状态应通过色调、空心填充、零线背景和带正负号的标签来表示，而非默认使用绿色／红色语义；如有例外，应记录说明。
• 导出的 SVG 或 HTML 颜色应与声明的调色板主色及中性色一致；除非是在记录有意采用的例外，否则应移除未使用的多色调标记。
• 图表辅助元素应保持克制：不得使用任意彩色背景、渐变、装饰性辅助线、不一致的描边宽度或装饰性标记填充。填充标记应保留描边，基准线、校准线和参考线应使用深中性色。
• 标题、图例和主要标签应使用深色，并共享清晰的页眉锚点。模板系统要求时，数字刻度和直接数值标签应采用等宽字体样式。
• 研究图表应将 blossom 固定放置在右上角；第三方、合作伙伴关系及非研究类图表不应包含该元素。
• 交付前，应在读者会打开的成品查看器中检查图表，确认它能回答所述分析问题，正负号和刻度诚实无误，标签在笔记本电脑和移动设备宽度下均能完整显示，颜色及非颜色编码均易于理解，并且在图注涉及这些信息时明确写出指标、时间范围和来源。
• 交付前，应检查最终报告、幻灯片、仪表板、笔记本、小组件或 HTML 布局。若有任何要求未达标，应在交付前修改。