一张报表数字不对，最麻烦的往往不是改公式，而是没人说得清它从哪张表来、途中经过了什么。Reddit 用户 Code_Bandits 分享了一套正在搭建的轻量方案：不用专用平台，改从现有线索拼出数据血缘——也就是数据从接入、加工到报表的完整去向。
具体做法是把多个仓库串起来：Power BI 项目存于 Git——记录文件版本和变更历史的系统；Python 脚本读取其中的 M 查询，找出报表访问的 SQL 对象；再查询 SQL Server 的依赖信息，把视图追溯到底层表。数据库定义和 ADF 配置则位于另外两个仓库，作者尝试用表名中的统一前缀，例如 finance_gl，充当跨系统的连接钥匙。
这条思路的价值在于，它利用团队已经拥有的代码和 SQL 元数据，先回答“改这里会影响哪些报表”。但它目前仍是求助方案，并非经过验证的成品：Power BI 若直接执行 SQL 查询，关联就会变复杂；仅靠静态分析——读取代码而不实际运行任务——也可能漏掉动态生成的 SQL 和运行时分支。摘要未披露覆盖率或准确率。