此内容由人工智能翻译,尚未经过人工编辑审核。图像和图表保持其原始语言。
要点速览
- Power BI Report 要按你想要的方式进行格式设置,往往既难又耗时。 许多具体选项在 UI 中不可用;为 Visual 进行高度定制的格式设置非常耗时。
- 你可以通过修改 Report 元数据,实现 UI 里做不到的 Visual。 借助用于 Report 元数据的 Power BI 增强报表格式 (PBIR),就能以受支持的方式修改这些元数据。 最近一些很有想法的社区成员发现了某些模式:虽然 UI 里没有,但依然能在 Visual 中渲染出来。
- 这些由元数据驱动的模式,人手几乎做不到,但 AI 智能体可以。 Claude Code 这类代码智能体可以修改 PBIR 元数据,让你用自然语言为 Visual 做格式设置。 它们也能创建这类定制化的 Visual 和格式设置。
- 智能体驱动的 Report 开发是可行的,但很复杂。 智能体确实可以处理 Report 元数据,但现实是:这里有很多层复杂性与细微差别,导致这件事很难、很脆弱,而且非常耗时。 智能体必须同时理解语义模型、主题、DAX、渲染引擎,以及 Report 元数据。 让智能体更容易专注于 R、Python 或 Deneb 等 Custom visual。
本摘要由作者撰写,并非由 AI 生成。
<!--more-->在 Power BI 折线图中对线条进行条件格式设置
Power BI Report 的核心 Visual 仍在每月持续改进。 不过,仍有很多属性和格式设置选项无法使用。 例如:在折线图中对“线条”进行条件格式设置,如下方演示:

如你所见,线条、填充区域和标记点会根据数值是高于零还是低于零而改变颜色。 我们将在本文后面说明如何在 Power BI 中创建这张图。
过去,这种设计通常只能通过各种变通方案或 custom visual 来实现。 这些变通方案往往需要对 Visual 配置进行复杂的“土法改造”,硬把 Visual 掰到一种不直观、也难以维护的状态。 它们通常还会用到特定的 DAX 模式或多个度量值,从而带来性能问题。 确实,很多在实际环境中遇到的“很慢的 Report”,并不完全是因为糟糕的 DAX 或模型本身 per se,而更多是因为大家在努力让 Power BI 的 Visual 按某种方式工作;以便按他们想要的方式展示数据。 这并不理想,但最近的一些发现让事情变得更有意思。
最近,Marcus Wegener、Rahat Qayyum 等人展示了一种耐人寻味的技巧:通过操控 Power BI Report 元数据,为 Power BI 用户界面不支持的某些属性和 Visual 实现条件格式设置。 但 Visual 依然会正常渲染并按预期运行。 这不只适用于颜色和标题,也适用于图表布局等其他属性。 这确实有意思,但也带来问题:
- 很容易出错,把 Visual “弄坏”,或者得到一个无法渲染的结果。
- 要做修改必须阅读并改 JSON;不能用 UI。
- 这没有文档说明;在某些场景或 visualTypes 中可用,但在另一些则不行。
在本文中,我们会演示并扩展这个场景,并说明你如何用它来创建上面展示的 Visual。 此外,我们还会讨论这对智能体驱动的 Report 开发意味着什么:当代码智能体直接修改 PBIR 元数据,以帮助报表作者节省时间并完成 Report 的格式设置。
警告
我们不建议将这种技巧用于部署到生产环境的 Report。 本文只是展示 PBIR 元数据的一种奇特而有趣的特性,以及代码智能体在促进智能体驱动的 Report 开发时的能力(与挑战)。 如果你需要 Power BI Desktop 用户界面中无法实现的格式设置选项,我们建议使用 Power BI custom visuals,例如 AppSource 中的那些,或 Deneb、Python 或 R Visual。
使用 Claude Code 来管理你的 Report 元数据可能会很有帮助。 不过你需要注意:Report 元数据中可能包含来自你的语义模型的数据点,并且在某些场景下,还可能包含该 Report 此前绑定过的其他语义模型中的数据点。
场景:为折线图中的折线设置条件格式
在这个场景里,我们希望对折线图的折线、面积和标记点进行条件格式设置:

目标是生成我们之前展示过的那张图:这些图表元素会根据它们位于零线之上还是之下而应用不同的条件格式。
在这个场景里,我们仅使用 Power BI 自带的核心 Visual 就能制作该图表。
通过用户界面为折线设置条件格式
在 Power BI 的折线图或面积图中,我们可以很轻松地创建基础图表。 但问题就出在条件格式上。 截至 2025 年十月,仍不支持对线条进行条件格式设置。 我们可以手动为每个月分别设置格式来实现想要的效果,但这并不具备动态性。
确实 有 一些变通办法可以对折线标记点进行条件格式设置。 具体来说,你可以先在柱状图中设置条件格式,然后再切换为折线图,就会得到如下结果:

显然这不是我们想要的。 我们想要格式化的是折线,而不只是它的标记点。 加上标记点往往会让折线图变得没那么有效:注意力会从斜率和趋势被拉走,转而更聚焦在离散点上;说实话,如果标记点真的那么重要,你可能干脆直接用柱状图就行。
不过,为了继续往下探讨,还有一种变通办法:使用两个度量值,把它们作为不同的序列,并分别指定颜色。 你可以用 DAX 按条件把它们隐藏起来。 下面每个度量值都会变成各自的序列:
Demo Order Lines (Above Zero) :=
VAR _Value = [Demo Order Lines]
RETURN
IF(_Value >= 0, _Value, BLANK())
Demo Order Lines (Above Zero) :=
VAR _Value = [Demo Order Lines]
RETURN
IF(_Value < 0, _Value, BLANK())
不过,结果显然也不理想:

我们还可以用更多“MacGyver 式”的技巧把它做得更复杂:比如误差线阴影、SVG 等等。 当你想让折线相对于另一条序列进行格式化时,情况会变得更复杂——正如 Daniel Marsh-Patrick 在这篇文章中解释得很清楚。 所以我们现在就把桌子掀了、把笔记本扔出窗外、然后回家了,对吧?
对折线进行条件格式设置
正如我们在本文开头提到的那样:只要以一种非常特定的方式修改 Report 中的 Visual 元数据,就可以实现这个效果:

要得到这个结果,我们必须做如下元数据更改:

第一个更改(红色)是把“Literal”值替换为“度量值”引用,从而让它变成动态的。 该度量值定义了条件格式设置,如这篇文章所述。 这也是 Power BI 社区里其他人此前提到过的方法;它能让你动态控制 Visual 的许多(但并非全部)属性。 这点很好理解。
但第二处属性更改(橙色)就没那么直观了。 读到这里,你很可能还是不明所以——除非你以前开发过 Custom visual,或者你对 Power BI Report 元数据非常熟悉。 简而言之,这个属性让条件格式的筛选语境不再按折线序列应用,而是按折线片段应用;这里的“片段”指的是 X 轴的类别(本例中是月份)。
那我们是怎么弄明白的? 嗯,我们并没有。 Claude Code 做到了。
Power BI Report 的智能体式开发
为了得到这个结果,我们给 Claude Code 提供了需求,以及若干带条件格式的折线图和其他 Visual 的示例。 然后,我们放手让 Claude Code 全权处理元数据,并且(通过 Fabric CLI)具备发布 Report 的能力;再(借助 Playwright MCP server)去“查看”它们。 在人工监督下,这个编码智能体以迭代循环的方式持续推进,直到它产出了我们想要的结果(经历了很多很多次迭代)。
这就是智能体式 Report 开发的一个例子:编码智能体直接修改 Report 元数据。 这与修改 TMDL 文件的智能体类似。 但它要复杂得多,原因包括:
- Report 元数据文件是 JSON,嵌套层级很深,很难理解。
- 元数据文件包含对字段、表和数据点的引用,因此智能体必须同时理解语义模型和 Report。
- 元数据还会引用 Report 主题;主题可能是一个非常大的 JSON 文件,智能体会很难处理和理解。
- 元数据中存在大量不一致之处,容易让智能体产生混淆。
- 智能体必须理解 DAX,包括模型度量值、thin report 度量值,以及 Visual 计算。
- 智能体还需要偶尔处理其他语言,比如 Python、R,以及 Vega 或 Vega-Lite(用于 Deneb)。
- 元数据中的许多属性与 Power BI 用户界面中的命名并不一致,而且其用法往往不直观(例如,把误差线用作柱状图的目标线)。
总之,相比处理语义模型元数据,编码智能体在处理 Report 元数据时更容易出错。 它们确实可以帮助你做一些简单改动或寻找模式,但一遇到任何定制化或复杂需求,就会力不从心。
编码代理在处理 Report 元数据方面确实很擅长,比如:
- 在指令清晰的情况下,批量修改(例如标题、Visual 大小、颜色等)。
- 操作文件(复制、删除、移动)。
- 将 Report 模板化(拿一个 Visual 作为示例,并按照你的指令,把它以正确的字段与格式插入到你的 Report 中)。
- 处理 Custom visual。
最后一个例子或许最有意思。 你可以很轻松地让编码代理只用 Python 或 R 就生成完整的 Report 和 Dashboard,以及相关 Visual,例如下面这个例子:

但现实是,Report 元数据既复杂又讲究细节;即使“代理式开发”可行,也需要人类编排者投入更多精力。 我们已经和社区里的其他人一起深入研究了这个问题,并在探索能让这件事更容易的工具。
总的来说,编码代理不仅能帮你明显节省时间,也有机会做到用户界面做不到的事情。 目前来看,这么做风险很高,而且不够稳定。 未来,这会解锁 Power BI 报表层的更多可能性。
结语
格式化和管理 Power BI Report 非常耗时,而且在格式窗格菜单里“捉迷藏”往往令人沮丧。 有很多选项要么不可用,要么在 UI 里并不明显。 如果 Power BI Report 采用 PBIR 格式,你可以直接修改 Report 元数据——无论手动还是用脚本——从而得到新颖且有意思的结果。 不过,有了编码代理之后会更有意思:这些代理甚至还能发现新的模式。 但在实践中,这仍然是一个脆弱且困难的过程;“代理式”的 Report 开发,对代理的要求比语义模型开发更高。
即便如此,只要编排得当,仍能产生有趣的结果,尤其是在使用 Custom visual 时。
