在公司中使用 AI 辅助问数时一个常见痛点是权限管理与查询模型脱节——使用者能在 DSL 里随意指定过滤条件。却无法保证这些条件与后台真正的行级权限同步，从而导致潜在的数据泄露。

同一条 DSL，为什么会得到不同的销售结果？

最近看到很多关于 AI 问数准确性、指标口径和自然语言查询的文章，但关于数据权限如何真正落到查询模型中的内容相对少一些。说起来，

我看到过一些问数产品。公开介绍更多集中在菜单权限、功能权限等方面。可能是我还没有遇到更专业的介绍。也可能部分产品主要面向领导驾驶舱和聚合指标场景，权限细节没有展开。

下面以 Codex 为例。分享一种我们目前正在实践的行级数据权限配置方式，抛砖引玉。

先把场景说清楚

• 再看查询模型，wwi_oltp_invoice_lines
• TM这方面，WwiOltpInvoiceLineModel
• 再看销售金额字段。totalIncludingTax
• 至于权限字段，customer$salesTerritory

使用者痛点： 你只关心业务结果，却发现同一条 DSL 在不同身份下返回的数据截然不同，这让你无法快速判断哪些数据被隐藏了。

customer$salesTerritory 是 TM/QM 中的语义字段，用来表示客户所属销售区域。它对应 WWI 数据里的销售区域字段，不是使用者自己在 DSL 中填写的权限参数。

给这个查询模型增加下面的行级权限：

增加“跨区域支持人员”。是为了展示多值权限范围：他可以看几个被授权的区域，但不能看全部区域。

为什么用代码表达权限？老实说，

传统配置式方案虽然能减少重复开发量。但要维护一套真正可用的数据权限配置程序，需要处理组织树、动态数据范围、多租户、策略版本、生效时间、缓存和审计等问题。程序本身往往并不简单，怎么说呢，

Ai 的出现让编码式权限更易上手——只需用业务语言告诉 Codex “总部看全部、区域经理看自己的区、跨区人看授权区”。Codex 就能协助检查 TM、生成 QM/FSScript，并补充验证请求。

痛点提醒： 如果你已经有成熟的数据权限程序。可通过自定义函数或 Spring Bean 调用已有接口，将可信范围转换为行级条件；但如果没有，就得从基础开始搭建——这是一大技术挑战。老实说，

# 帮我给现在这个 WWI 发票明细查询加上销售区域权限。# 总部能看全部，# 区域经理只能看自己的区。# 跨区支持人员只能看分配给他的几个区。# 没有身份或身份不对，就不要返回数据。# 你先看看 TM 里有没有现成的销售地区字段。# 直接在 QM 里处理，别让我在 DSL 里传权。# 身份怎么拿先用 FSScript 伪代码，# 注释里说明以后可以通过 get/post 调业务程序
# 或者接 Spring Bean。# 最终用同一条查询，# 给我看看总部、地区经理和跨区人生成
# 的 SQL 有什么不同。

关键痛点： 很多团队习惯一次性写完所有接口定义与验收标准，却导致提示词过长且难以维护；逐步迭代提示词更贴最近常工作流程，更容易获得准确结果。其实，