你是不是也遇到过这样的情况：业务部门用 Copilot 问数据，结果每个人问出来的数字都不一样？或者 Copilot 虽然跑出了结果，但查询慢得让人抓狂，消耗的 CU 成本还高得离谱？
最近 Power BI Copilot 迎来了一次重大更新——现在它和 M365 Copilot 深度集成，不再需要 Fabric 容量，Pro 工作区也能用。这听起来是好事，但实际用起来，两个痛点立刻浮现出来：
- 结果对，但性能差——M365 Copilot 生成的 DAX 查询在语法上几乎不会出错，但它不一定会选择最优的查询方式，要么跑得慢，要么消耗大量 CU 成本。
- 同一问题，不同答案——多个用户想做同一种分析，但每个人描述方式不同，给出的指令模糊又随意，最后得到的结果可能大相径庭。
这两个问题，作为语义模型开发者，我发现最有效的解决办法就是：在模型里添加 DAX 用户定义函数（UDF）。
为什么 DAX UDF 能解决这两大痛点？
去年我写过一篇关于 DAX UDF 的文章，但当时还没意识到它在 Copilot 时代会变得如此关键。现在，如果你打算把所有的业务逻辑都集中在语义模型里，那么复杂的分析操作也应该定义在模型内——而 DAX UDF（尤其返回表的 UDF）比在 AI Instructions 里写一段文本描述，或者嵌入一段 DAX 片段要可靠得多。
就拿我常用的一个例子来说：我用英国土地注册局的房价数据建了一个语义模型，并在模型里定义了一个叫 ABC 的 DAX UDF，用来做 ABC 分析。这个函数接受三个参数：AUpperBoundary（A 组交易上限）、BUpperBoundary（B 组交易上限）、AnalysisDate（分析日期），返回一个可直接使用的表。
在 AI Instructions 中声明 UDF，效果立竿见影
我只在语义模型的 AI Instructions 里加了两段话，告诉 Copilot 这个 UDF 的存在和用法。然后，我在 M365 Copilot 里测试了一下。结果非常理想：
- 一致性：无论用户怎么提问，Copilot 都会优先调用这个 UDF，而不是自己临时生成 DAX，结果自然一致。
- 性能：因为 UDF 是预先优化过的，查询效率远高于 Copilot 临时生成的 DAX，CU 成本也降了下来。
如何操作？三步走
- 在模型中创建 DAX UDF：用
DEFINE关键字定义一个返回表的函数，确保它封装了你想要的分析逻辑。 - 在 AI Instructions 中清晰描述：在语义模型的 AI Instructions 里，用自然语言说明这个 UDF 的名称、参数和用途。比如：“本模型包含一个名为
ABC的 DAX 用户定义函数，用于对 Transactions 表进行 ABC 分析，参数包括……” - 测试验证：在 M365 Copilot 中用不同方式提问，确保它总是调用 UDF，而不是自行生成。
国内用户怎么看？
其实这个思路对国内企业特别有借鉴意义——很多公司用 Copilot 做自助分析时，最怕的就是“数据口径不一致”。业务部门各说各话，IT 部门天天解释“为什么数字对不上”。DAX UDF 相当于把口径固化在模型里，Copilot 只是个执行工具，这样无论谁来问，结果都是唯一的。
当然，DAX UDF 目前还有学习门槛，但相比在 AI Instructions 里写一堆规则，它更直接、更可控。如果你正在为 Copilot 的查询质量发愁，不妨试试在模型里加几个 UDF。
