powerbi-report-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Power BI Report Design Skill

Power BI报表设计技能

This skill provides design guidance for Power BI reports. It commits a design identity (tone + signature), routes user requests to the right archetype per page, and applies cross-cutting design principles (color, typography, iconography, layout, interactivity, accessibility).

Scope boundary — This skill decides what a report should look like and why. It does not write PBIR files. After producing a design contract, hand off to

powerbi-report-authoring

for all file mechanics: page/visual creation, theme registration, expression encoding, formatting objects, and validation.

本技能为Power BI报表提供设计指导。它确定设计标识（风格基调+标志性视觉元素），根据页面将用户请求分配到合适的原型，并应用跨领域设计原则（色彩、排版、图标、布局、交互性、无障碍设计）。

范围边界 — 本技能决定报表应该是什么样子以及为什么要这样设计。它不负责编写PBIR文件。生成设计契约后，将所有文件操作工作移交至

powerbi-report-authoring

：页面/视觉对象创建、主题注册、表达式编码、格式对象设置和验证。

Must/Prefer/Avoid

必须/推荐/避免

MUST

必须

Inspect the semantic model or available fields before making design decisions.
Produce concrete design choices: tone, signature, page archetype, chart rationale, layout direction, color, typography, and accessibility considerations.
Hand off file mechanics to
```
powerbi-report-authoring
```
; this skill does not edit PBIR.

在做出设计决策前检查语义模型（semantic model）或可用字段。
生成具体的设计选择：风格基调、标志性视觉元素、页面原型、图表设计依据、布局方向、色彩、排版和无障碍设计考量。
将文件操作工作移交至
```
powerbi-report-authoring
```
；本技能不编辑PBIR文件。

PREFER

AVOID

避免

Do not create pages, visuals, filters, themes, or PBIR files directly.
Do not provide vague "make it modern" guidance without concrete layout/color/chart decisions.
Do not replace the planning workflow for broad create/build requests.

不要直接创建页面、视觉对象、筛选器、主题或PBIR文件。
不要提供模糊的“使其现代化”指导，而不给出具体的布局/色彩/图表决策。
不要替代针对广泛创建/构建请求的规划工作流。

Topic Files and Examples

主题文件与示例

This root file covers the end-to-end workflow, theme, gotchas, and the design contract template. Read the topic files as needed:

File	When to read
`references/tone-catalog.md`	Read when the prompt lacks a specific tone or needs concrete downstream palette/type choices
`references/signatures.md`	Read when selecting or refining the report's signature visual move
`references/archetype-composition.md`	Read for multi-page reports when page roles or variant rotation are unclear
`references/archetypes/<name>.md`	Read before laying out each page — layout template, density, chart mix
`references/chart-selection.md`	Read before selecting a chart type — encoding hierarchy, purpose matching
`references/visual-cookbook.md`	Read before configuring any visual — sort, color, labels, CF per type
`references/layout.md`	Read before placing visuals on canvas — 8-px grid, composition templates
`references/color.md`	Read if defining palette, color semantics, gradients, or conditional formatting
`references/typography.md`	Read if overriding font sizes, type pairings, or weight conventions
`assets/base.json`	Read before theme work for generated reports — preserve its textbox/card/table per-type safeguards when adapting a custom theme
`references/interactivity.md`	Read if adding drill-through, bookmarks, or cross-filter rules
`references/brownfield.md`	Read for redesigns, restyles, theme swaps, or brand application
`references/accessibility.md`	Read before finalizing any report — WCAG checklist, alt text, contrast
`references/anti-patterns.md`	Read before finalizing any report — common failures and how to fix them
`references/pre-flight-checklist.md`	Read for the full checklist before handoff/final audit
`references/design-brief.md`	Read before handoff — full `Design Brief:` template, mechanical `layout_contract` schema, page title/header band, slicer placement, non-overlap rules, and validation checklist

本根文件涵盖端到端工作流、主题、常见问题和设计契约模板。根据需要阅读主题文件：

文件	阅读时机
`references/tone-catalog.md`	当提示缺少特定风格基调，或需要具体的后续调色板/排版选择时阅读
`references/signatures.md`	当选择或优化报表的标志性视觉元素时阅读
`references/archetype-composition.md`	当多页报表的页面角色或变体轮换不明确时阅读
`references/archetypes/<name>.md`	在规划每个页面之前阅读 — 布局模板、密度、图表组合
`references/chart-selection.md`	在选择图表类型之前阅读 — 编码层级、用途匹配
`references/visual-cookbook.md`	在配置任何视觉对象之前阅读 — 排序、色彩、标签、各类视觉对象的条件格式（CF）
`references/layout.md`	在画布上放置视觉对象之前阅读 — 8px网格、布局模板
`references/color.md`	当定义调色板、色彩语义、渐变或条件格式时阅读
`references/typography.md`	当覆盖字体大小、字体配对或字重规范时阅读
`assets/base.json`	在为生成的报表进行主题工作之前阅读 — 调整自定义主题时，保留其针对文本框/卡片/表格的按类型防护设置
`references/interactivity.md`	当添加钻取、书签或交叉筛选规则时阅读
`references/brownfield.md`	当进行重新设计、样式更新、主题替换或品牌风格应用时阅读
`references/accessibility.md`	在最终确定任何报表之前阅读 — WCAG检查清单、替代文本、对比度
`references/anti-patterns.md`	在最终确定任何报表之前阅读 — 常见问题及修复方法
`references/pre-flight-checklist.md`	在移交/最终审核前阅读完整检查清单
`references/design-brief.md`	在移交之前阅读 — 完整的 `Design Brief:` 模板、机械性 `layout_contract` schema、页面标题/页眉栏、切片器放置规则、无重叠规则和验证检查清单

Workflow

工作流

Step 0 — Data-First Investigation

步骤0 — 数据优先调研

Inspect the semantic model before making any design decision. Use the Semantic Model MCP server if available, or read

.tmdl

files directly. Sample top-N rows per table to understand distributions, cardinality, and magnitudes. Catalog tables, columns, measures, hierarchies, and relationships. Map each measure+dimension to the analytical question it answers.

在做出任何设计决策前检查语义模型。如果可用，请使用Semantic Model MCP服务器，或直接读取

.tmdl

文件。抽样每个表的前N行以了解分布、基数和量级。分类表、列、度量值、层级和关系。将每个度量值+维度映射到它所回答的分析问题。

Step 1 — Design Identity

步骤1 — 设计标识

Before routing archetypes or picking charts, commit to a tone and signature. The tone captures the report's feel; the signature is the one defining visual move that recurs across pages. If the prompt lacks a specific identity, use

references/tone-catalog.md

and

references/signatures.md

to choose, remix, or author a tone/signature. Do not force-fit catalog entries; the requirement is a concrete identity that drives palette, typography, layout, and recurring visual treatment. For brownfield redesigns, read

references/brownfield.md

and capture both current and target tone/signature.

在分配原型或选择图表之前，确定风格基调和标志性视觉元素。风格基调体现报表的整体感觉；标志性视觉元素是在各页面重复出现的核心视觉设计。如果提示中没有明确的设计标识，请使用

references/tone-catalog.md

和

references/signatures.md

来选择、混合或创建风格基调/标志性视觉元素。不要强行套用目录条目；要求是有具体的设计标识，以指导调色板、排版、布局和重复视觉处理。对于已有系统的重新设计，请阅读

references/brownfield.md

并记录当前和目标的风格基调/标志性视觉元素。

Step 2 — Archetype Router

步骤2 — 原型路由

Route per page, not per report. Even a single broad request ("a report covering everything about our business") usually decomposes into pages with different audiences, purposes, and cadences — and therefore different archetypes. Treat each page as an independent routing decision.

Signal	Archetype	Reference
C-suite, board, GM; ≤10 s scan; "is it on track?"	Executive Summary	`references/archetypes/executive-summary.md`
Shift operator, NOC, wallboard; "is it broken?"	Operational Monitor	`references/archetypes/operational-monitor.md`
Analyst; hypothesis testing; "why did X happen?"	Analytical Canvas	`references/archetypes/analytical-canvas.md`
Author-driven argument; "here's what happened"	Narrative Story	`references/archetypes/narrative-story.md`
Ranking, benchmarking, variance; "relative to what?"	Comparative Benchmark	`references/archetypes/comparative-benchmark.md`

When the signal is ambiguous, default to Analytical Canvas — it is the most flexible archetype and degrades gracefully.

Vague prompts: ASK before routing. A prompt is vague if audience, purpose, page count, or filtering depth is missing. When vague, stop and offer 2–3 concrete named options in user-facing terms (never expose archetype names). Each option references a specific archetype + variant combination tailored to what's in the semantic model from Step 0. If the user picks, proceed; if still unsure, ask one narrowing follow-up; after at most two rounds, pick the best option, document the assumption in

variant_rationale

, and proceed.

Then pick a layout variant. Each archetype reference file ships 2–3 layout variants (A / B / C) with a selection table keyed on data signals. Walk the variant selection table per page using the data shape from Step 0. Do NOT default to variant A out of habit. Record the variant + the data signal that drove the pick (

layout_variant

variant_rationale

in the

Design Brief:

YAML).

Treat archetype zones as advisory, not mandatory. A variant is a layout starting point, not a required component checklist. Every card, callout, annotation, and context tile must earn its space by answering a distinct analytical question. If the semantic model lacks the needed derived insight (delta, variance %, rank shift, exception threshold, comparison baseline, or dynamic explanatory text), drop or repurpose that zone rather than filling it with a duplicate absolute measure.

For multi-page reports, see

references/archetype-composition.md

— common compositions (Executive + Drill, Ops + Detail, Story + Evidence, Multi-domain) + cross-page variant rotation rules. Avoid mono-archetype reports; same-archetype pages must rotate variants where data signals support it.

按页面进行路由，而非按报表。即使是一个宽泛的请求（“一份涵盖我们业务所有内容的报表”），通常也会分解为面向不同受众、具有不同用途和更新频率的页面——因此需要不同的原型。将每个页面视为独立的路由决策。

信号	原型	参考文件
高管层、董事会、总经理；≤10秒扫描；“是否按计划进行？”	执行摘要	`references/archetypes/executive-summary.md`
轮班操作员、网络运营中心（NOC）、看板；“是否出现故障？”	运营监控	`references/archetypes/operational-monitor.md`
分析师；假设检验；“X为什么会发生？”	分析画布	`references/archetypes/analytical-canvas.md`
作者主导的论证；“这是发生的情况”	叙事报告	`references/archetypes/narrative-story.md`
排名、基准对比、差异；“相对于什么？”	对比基准	`references/archetypes/comparative-benchmark.md`

当信号不明确时，默认使用分析画布——它是最灵活的原型，适应性强。

模糊提示：路由前先询问。如果提示缺少受众、用途、页面数量或筛选深度等信息，则视为模糊提示。遇到模糊提示时，停止操作并向用户提供2-3个具体的命名选项（不要暴露原型名称）。每个选项都参考一个特定的原型+变体组合，根据步骤0中的语义模型量身定制。如果用户选择了某个选项，则继续；如果仍不确定，请提出一个缩小范围的跟进问题；最多两轮后，选择最佳选项，在

variant_rationale

中记录假设，然后继续。

然后选择布局变体。每个原型参考文件都包含2-3个布局变体（A/B/C），并配有基于数据信号的选择表。使用步骤0中的数据形态，为每个页面逐一查看变体选择表。不要习惯性默认选择变体A。记录变体以及驱动选择的数据信号（在

Design Brief:

的YAML中记录

layout_variant

和

variant_rationale

）。

将原型区域视为建议，而非强制要求。变体是布局的起点，而非必须遵守的组件清单。每个卡片、标注、注释和上下文磁贴都必须通过回答独特的分析问题来证明其存在的必要性。如果语义模型缺少所需的衍生洞察（差值、差异百分比、排名变化、异常阈值、对比基准或动态解释文本），则删除或重新利用该区域，而非用重复的绝对度量值填充它。

对于多页报表，请参阅

references/archetype-composition.md

——常见组合（执行摘要+钻取、运营监控+详情、叙事报告+证据、多领域）+跨页面变体轮换规则。避免单一原型的报表；当数据信号支持时，相同原型的页面必须轮换变体。

Step 3 — Chart Selection

步骤3 — 图表选择

Read

references/chart-selection.md

to match each analytical question to the right visual type. Respect the encoding hierarchy: position → length → angle → area → hue. Sample the data first — a line chart with flat lines or a bar chart with two bars indicates the wrong visual choice.

阅读

references/chart-selection.md

，将每个分析问题匹配到合适的视觉类型。遵守编码层级：位置→长度→角度→面积→色调。先抽样数据——线条平缓的折线图或只有两个条形的条形图表明视觉类型选择错误。

Step 4 — Visual Configuration

步骤4 — 视觉对象配置

Read

references/visual-cookbook.md

for per-visual-type rules: sort order, color strategy, label placement, axis config, and conditional formatting. These rules determine whether charts look professional or amateur. Read

references/layout.md

before placing visuals on the canvas.

阅读

references/visual-cookbook.md

获取针对各类视觉对象的规则：排序方式、色彩策略、标签位置、轴配置和条件格式。这些规则决定了图表看起来是专业还是业余。在画布上放置视觉对象之前，请阅读

references/layout.md

。

Step 5 — Theme

步骤5 — 主题

Adapt the report theme to the design identity from Step 1. For generated reports, start from

assets/base.json

or preserve its critical per-type safeguards when creating an adapted custom theme:

textbox

padding/background/border overrides,

cardVisual

zero padding/card spacing, table grow-to-fit styling, hidden visual headers, and type-specific chart defaults. Do not replace these with a blunt wildcard

visualStyles["*"]["*"].padding

/ background unless every affected visual type is checked and overridden. If the report already has a theme, preserve it unless the user asked for a theme swap or brand refresh. For full mechanics of theme registration — including how to choose the

$schema

version when adapting

assets/base.json

— use the

powerbi-report-authoring

skill.

根据步骤1中的设计标识调整报表主题。对于生成的报表，从

assets/base.json

开始，或在创建调整后的自定义主题时保留其关键的按类型防护设置：

textbox

内边距/背景/边框覆盖、

cardVisual

零内边距/卡片间距、表格自适应样式、隐藏视觉对象标题，以及针对特定类型图表的默认设置。除非检查并覆盖了所有受影响的视觉对象类型，否则不要用生硬的通配符

visualStyles["*"]["*"].padding

/背景替换这些设置。如果报表已有主题，除非用户要求更换主题或刷新品牌风格，否则保留该主题。有关主题注册的完整机制——包括调整

assets/base.json

时如何选择

$schema

版本——请使用

powerbi-report-authoring

技能。

Step 6 — Canonical Design Contract

步骤6 — 标准设计契约

Emit a structured

Design Brief:

YAML block. This is the contract with

powerbi-report-authoring

. Populate every field with concrete values from Steps 0-5 and include a mechanical

layout_contract

per page.

When this skill is used inside the planner workflow, embed this YAML block in

_brief/report-spec.md

under a "Canonical design contract" section. For the full template, field rationale, brownfield current/target fields, minimal-brief escape hatch, page-level mechanical schema, examples, and validation checklist, read

references/design-brief.md

The contract must have a design provenance marker (

generated_by: powerbi-report-design

) and

contract_version

. Greenfield reports default to FHD (

1920 x 1080

) unless the user asks for another size; brownfield reports preserve the existing canvas unless resize is approved. Do not hand off a non-trivial page until its

layout_contract

has a

page_title

placement, a reserved header/slicer band or justified filter rail, a

space_audit

, and non-overlapping regions/placements.

Keep this minimal shape in mind; use

references/design-brief.md

for the full template and validation rules:

yaml

Design Brief:
  generated_by: powerbi-report-design
  contract_version: 1
  mode: greenfield
  design_identity: { tone: <tone>, signature: <signature> }
  pages:
    - name: <descriptive insight title>
      role: <landing | detail | drillthrough | tooltip>
      archetype: <Executive | Analytical | Operational | Narrative | Comparative>
      layout_variant: <A | B | C>
      variant_rationale: <one sentence: which data signal drove this pick>
      layout_contract:
        canvas: { width: 1920, height: 1080, margin: 32, gutter: 24, snap: 8 }
        grid:
          columns: 12
          rows: 12
          regions:
            header:  [1, 1, 9, 2]
            filters: [9, 1, 13, 2]
            body:    [1, 2, 13, 13]
        placements:
          - id: page_title
            region: header
            kind: textbox
            text: <descriptive insight title>
          - id: <visual_or_slicer_id>
            region: <defined region>
            kind: <cardVisual | barChart | lineChart | tableEx | slicer | azureMap | ...>
            purpose: <one analytical question>
            field_bindings: <Table[Field] or role map>
        space_audit:
          content_cell_count: <cells after excluding reserved header/slicer/rail>
          placed_cell_count: <cells covered by regions with placements>
          empty_cell_pct: <0-100>
          unplaced_regions: []
          largest_region: { name: <region>, pct_of_content: <0-100> }
          balance_rationale: <why region sizes match analytical priorities>

Minimal-brief escape hatch (trivial single-visual asks): 3 lines suffice —

mode

design_identity { tone, signature }

(or

unchanged

in brownfield), and the one decision. See

references/design-brief.md

for examples.

输出结构化的

Design Brief:

YAML块。这是与

powerbi-report-authoring

的契约。使用步骤0-5中的具体值填充每个字段，并为每个页面包含一个机械性的

layout_contract

。

当本技能在规划工作流中使用时，将此YAML块嵌入

_brief/report-spec.md

的“标准设计契约”部分。有关完整模板、字段依据、已有系统的当前/目标字段、极简简报快捷方式、页面级机械schema、示例和验证检查清单，请阅读

references/design-brief.md

。

契约必须包含设计来源标记（

generated_by: powerbi-report-design

）和

contract_version

。全新报表默认使用FHD（

1920 x 1080

）尺寸，除非用户要求其他尺寸；已有系统的报表保留现有画布尺寸，除非调整尺寸已获得批准。在页面的

layout_contract

包含

page_title

位置、预留的页眉/切片器栏或合理的筛选器栏、

space_audit

以及无重叠区域/放置规则之前，不要移交重要页面。

请记住这个极简结构；使用

references/design-brief.md

获取完整模板和验证规则：

yaml

Design Brief:
  generated_by: powerbi-report-design
  contract_version: 1
  mode: greenfield
  design_identity: { tone: <tone>, signature: <signature> }
  pages:
    - name: <descriptive insight title>
      role: <landing | detail | drillthrough | tooltip>
      archetype: <Executive | Analytical | Operational | Narrative | Comparative>
      layout_variant: <A | B | C>
      variant_rationale: <one sentence: which data signal drove this pick>
      layout_contract:
        canvas: { width: 1920, height: 1080, margin: 32, gutter: 24, snap: 8 }
        grid:
          columns: 12
          rows: 12
          regions:
            header:  [1, 1, 9, 2]
            filters: [9, 1, 13, 2]
            body:    [1, 2, 13, 13]
        placements:
          - id: page_title
            region: header
            kind: textbox
            text: <descriptive insight title>
          - id: <visual_or_slicer_id>
            region: <defined region>
            kind: <cardVisual | barChart | lineChart | tableEx | slicer | azureMap | ...>
            purpose: <one analytical question>
            field_bindings: <Table[Field] or role map>
        space_audit:
          content_cell_count: <cells after excluding reserved header/slicer/rail>
          placed_cell_count: <cells covered by regions with placements>
          empty_cell_pct: <0-100>
          unplaced_regions: []
          largest_region: { name: <region>, pct_of_content: <0-100> }
          balance_rationale: <why region sizes match analytical priorities>

极简简报快捷方式（简单的单一视觉对象请求）：3行即可——

mode

、

design_identity { tone, signature }

（已有系统中为

unchanged

），以及一个决策。请参阅

references/design-brief.md

中的示例。

Step 7 — Review and Handoff

步骤7 — 审核与移交

Before handing off, read

references/design-brief.md

and

references/pre-flight-checklist.md

, then critically review the design contract against both. For brownfield, also walk the brownfield-specific items in

references/brownfield.md

. Fix problems before handing off.

If you can get an independent review (a separate reasoning pass or a colleague), do so — layout gaps, missing slicers, monochrome charts, raw field names, and tone-not-propagated failures are easiest to catch with fresh eyes.

Once the contract passes the checklist, hand off to

powerbi-report-authoring

for implementation.

移交前，请阅读

references/design-brief.md

和

references/pre-flight-checklist.md

，然后对照两者严格审核设计契约。对于已有系统的报表，还需查看

references/brownfield.md

中针对已有系统的特定项目。在移交前解决所有问题。

如果可以进行独立审核（单独的推理环节或同事审核），请务必进行——布局漏洞、缺失的切片器、单色图表、原始字段名称和风格基调未贯彻等问题最容易被新鲜的视角发现。

一旦契约通过检查清单，将其移交至

powerbi-report-authoring

进行实施。

Gotchas

常见问题

Non-obvious issues that cause reports to look broken or indistinct. Check each one.

Tone declared but never propagated — A brief that says

tone: editorial newsroom

but ships the same typography, palette, and gridline/border treatment as every other report. The tone has to show up in concrete visual choices. Walk the tone-catalog row's downstream-choices column.

Page background — Use an intentional page surface on every page; avoid white canvas + white visual containers, which creates flat, borderless visuals that bleed into the background. Authoring owns the exact

page.json

mechanics.

No overlap / clipped controls — No visual bounding boxes may overlap unless the overlap is explicitly intentional (for example, an annotation shape behind a chart). Top-bar slicers share a reserved title/slicer band: the page title remains the left anchor and slicers sit to the right. Charts/cards start below that band, not underneath it. Raising slicer z-order is not a substitute for non-overlapping layout.

Redundant callouts — A side callout or KPI context tile that repeats the same absolute measure already shown in the adjacent chart is noise. Callouts need

insight_basis

callout_value_basis

tied to a derived comparison, threshold, rank, anomaly, or generated narrative; otherwise remove the callout and give the space to a chart, table, filter context, or annotation that adds information.

Temporal slicer grain — Do not reflexively choose a full-date

Between

slicer just because a date column exists. For executive pages and annual-grain data, use a Year dropdown/tile unless users need day/month range exploration and the column is a renderable Date/DateTime field.

Textbox scrollbar — Textboxes need enough height for their font size plus any VCO/theme padding or Desktop renders a scrollbar. Height formula:

max(18, ⌈fontSize × 25/16⌉) + padding_top + padding_bottom

. If the theme uses wildcard padding, add a textbox-specific zero-padding override or increase the textbox height.

Color-map contract — Every measure-bound visual must follow

Design Brief.color_map

measure_match

means exact base color reuse across cards, lines, bars, maps, and tables;

gradient

means tint → base for that same measure. Audit the built report for mismatches before handoff.

Monochrome bars — Single-measure bar charts can render all bars in one color because PBI assigns palette colors by series, not by category. If category contrast matters, specify the intended per-category or gradient treatment in the brief and let authoring handle the mechanics. Do not work around this by duplicating the same field as both category and legend.

Raw field names — Agents consistently leave raw database names like

method_category

customer_id

Count of order_line_id

, or

date_of_enrolment

on axes, headers, and legends. Check every axis label, column header, legend entry, and card label. Set human-readable display names on every field.

Display names for aggregations — Use descriptive names like "Total Fights" or "Students", not "Sum of fight_key" or "Count of student_id". Set via

displayName

in the projection or via axis title override.

Percentage formatting — Rates stored as decimals (e.g., 0.53) should display as "53%", not "0.53". Set the number format string to

"0%"

"0.0%"

on the relevant visual property.

导致报表看起来有问题或缺乏特色的非明显问题。请逐一检查。

风格基调已声明但未贯彻 — 简报中写着

tone: editorial newsroom

，但使用的排版、调色板和网格线/边框处理与其他所有报表相同。风格基调必须体现在具体的视觉选择中。查看风格目录行中的后续选择列。

页面背景 — 每个页面都要使用有意设计的页面表面；避免白色画布+白色视觉对象容器，这会导致扁平化、无边框的视觉对象融入背景。文件操作负责具体的

page.json

机制。

无重叠/控件不被裁剪 — 除非是明确有意的重叠（例如，图表后的注释形状），否则视觉对象的边界框不得重叠。顶部栏切片器共享预留的标题/切片器栏：页面标题始终位于左侧锚点，切片器位于右侧。图表/卡片从该栏下方开始，而非下方。提高切片器的层级不能替代无重叠布局。

冗余标注 — 侧边标注或KPI上下文磁贴重复显示相邻图表中已有的相同绝对度量值，这属于冗余信息。标注需要

insight_basis

callout_value_basis

与衍生对比、阈值、排名、异常或生成的叙事相关；否则删除标注，将空间留给能增加信息的图表、表格、筛选上下文或注释。

时间切片器粒度 — 不要因为存在日期列就本能地选择完整日期的

Between

切片器。对于高管页面和年度粒度的数据，使用年份下拉列表/磁贴，除非用户需要日/月范围探索且该列是可渲染的Date/DateTime字段。

文本框滚动条 — 文本框需要足够的高度以容纳其字体大小加上任何VCO/主题内边距，否则Desktop会显示滚动条。高度公式：

max(18, ⌈fontSize × 25/16⌉) + padding_top + padding_bottom

。如果主题使用通配符内边距，请添加文本框特定的零内边距覆盖或增加文本框高度。

色彩映射契约 — 每个绑定度量值的视觉对象必须遵循

Design Brief.color_map

。

measure_match

意味着在卡片、线条、条形、地图和表格中重复使用相同的基础颜色；

gradient

意味着该度量值使用色调→基础色的渐变。移交前审核已生成报表中的不匹配情况。

单色条形 — 单度量值条形图可能将所有条形渲染为同一种颜色，因为Power BI按系列而非类别分配调色板颜色。如果类别对比度很重要，请在简报中指定预期的按类别或渐变处理方式，由文件操作负责具体机制。不要通过将同一字段同时作为类别和图例来解决此问题。

原始字段名称 — 智能体（Agent）经常在轴、标题和图例上保留原始数据库名称，如

method_category

、

customer_id

、

Count of order_line_id

或

date_of_enrolment

。检查每个轴标签、列标题、图例条目和卡片标签。为每个字段设置易读的显示名称。

聚合的显示名称 — 使用描述性名称，如“总航班数”或“学生人数”，而非“Sum of fight_key”或“Count of student_id”。通过投影中的

displayName

或轴标题覆盖进行设置。

百分比格式 — 存储为小数的比率（例如0.53）应显示为“53%”，而非“0.53”。在相关视觉对象属性上将数字格式字符串设置为

"0%"

或

"0.0%"

。