你的语义模型就是API：为代理提供经过认证的指标。
为什么人工智能代理会自行定义收入和库存的概念，以及如何通过具备粒度、所有者和拒绝机制的受管控语义模型为它们提供统一的契约。
两个官方数据
一次规划会议以一张标题为“上周销售情况”的幻灯片开始。前一天晚上，两位协理都收到了同样的询问，两人都返回了附有SQL代码的图表。其中一个数据比计划高4%，另一个则低3%。
在场没人将问题归咎于幻觉产生的列数据。仓库里确实存在一个包含net_amt列及日期的sales表。查询能够正常编译，连接键也存在，从数据库的角度来看，这两个结果都是合法的。
财务部门随后提供了第三个数据，这个数据早已为每周董事会报告准备好了。它按照发票日期统计已确认的收入，扣除贷项通知单，同时不计入员工采购和批发业务。Copilot one是按订单日期计算的，但把员工商店的采购数据也包含在内了。Copilot two则是按发货日期计算，且区域信息取自发货地址而非销售机构地址。
在同一讨论中有人询问各自使用的是哪个日期，一个回答是order_dt，另一个则是ship_dt。两人都未提及贷项通知单。关于是否包含员工采购数据，一人称没有看到相关过滤条件，另一人则编造了一个关于channel标志的说法，但实际上那只是一个与员工商店无关的营销归因字段。
问题在于服从性。两名处理人员表现得就像是在艰难工作中仍保持专业能力的分析师：他们看到一列名称与问题相似的数值便直接进行了汇总。正常情况下人类会停下来询问需要的是哪个销售编号，但这两名处理人员却将看似合理的列视为可以继续操作的信号。
之后，Slack对话中出现了三张图表和一个财务数字。没人标注指标名称，只有截图，这是个值得警惕的信号。当争论仅围绕图片展开时，合同就从未被提及。
给智能体一个仓库和恰当的提示，它就能自行创造业务模式。这种“创造”看起来像是专业能力的体现，结果却出现在 Slack 中，人们在那里争论模型权重，而本应讨论的是缺失的合同。这类问题很容易被归类为文化问题，但实际上根源在于接口的缺失，只有每日站会时，这些问题才会显现出来。
将语义模型想象成 API 是一种直观的方式，但并非 REST 风格的那种。要设想一种杜绝私人解读的接口：当有人询问上周的销售额时，调用者无法决定使用哪一列日期数据。系统会按照既定粒度执行 recognized_revenue 计算，否则就会拒绝请求。虽然引擎仍可生成 SQL 语句，但智能体并不会亲自编写。
如果有助于理解，用图表展示端点与 API 密钥也没问题。但更重要的是更具体的内容：一个有明确名称且含义已被定义、任何获授权的调用者都能使用的操作。
API 还包含所有者、版本以及版本变更规则。没有所有者的度量标准不过是偶然能计算出的传言而已。当财务部门改变信用票据的处理方式时，应当通过版本升级让所有调用者都能感知到变化，否则就又回到了之前的状态。在每周报告的页脚中打印一个月的度量版本看似繁琐，却能将“哪部分收入”的争议从个人分歧转化为版本问题。
查询本身很完美，但含义并不准确
给现代模型提供架构结构信息以及收入相关问题，生成的 SQL 通常已经足够整洁，甚至十年前都会让人印象深刻。但风险已不再出在那个环节了。
收入并非一个独立的列。即便只有一家公司，也可能存在已入账、已开票、已交付但尚未确认的收入，以及退货前通过收银系统记录的收入。贷项通知单可能会抵消部分金额，也有可能不会。公司间销售同样可能被计入或被排除在外。“荷兰”可能指开票国、交货国或负责该账户的销售机构，而“上个月”则可能是日历月份，也可能是在周日结束的财务周期。
这一切都与JOIN语法无关。即便使用标准的连接操作，也仍可能得出与实际决策需求不符的答案。
库存的处理方式也是如此。现有库存并非可承诺供应的库存，而可承诺供应的库存也并非分配系统今晚实际会发放给电商平台的数量。如果客服仅根据现有库存回答“能否在周五交付”，虽然听起来像是能处理订单，但实际上仍会让客户失望。
曾有一例，客服因为将所有仓库的qty_on_hand数值相加——包括那些已损坏的货架——就向仓库主管保证某款产品有足够库存，尽管计划部门早已标记那些货架无法使用。SQL查询语句看似合理，但其结论纯属猜测。实际上该主管当天早些时候已经亲自检查过那些货架，而客服却只依据表格数据做出判断。
即时报告显示的差异依然存在。门店运营部门希望获取下午4点前完成收银的操作记录，而财务部门则要求在抵扣后确认收入。在会议上，双方都会提到“昨天的销售额”。接到该要求的分析人员只需选择时间戳列和金额列即可，争论则要等到图表生成之后才会开始。
商品规划也存在同样的问题。需求数据与销售点数据不一致，而一旦出现退货，销售点数据又会与实际净销售额不同。在电子商务系统里某款商品可能显示已售罄，但销售人员看到的表格仍显示有库存，因为该表格还包含了在运输中的商品、质检中待处理的商品，以及为批发业务预留的待发货数量。如果销售人员根据错误的信息回答“我们有货”，公司就会在早上做出过度承诺，随后整个下午都得花费精力去解释那些表格上根本没显示的缺货情况。
将此称为提示词故障其实并不准确，因为“我们有这个吗？”这个提示词本身并无问题。真正缺失的是一个包含详细信息的available_to_promise对象：包括所在位置、排除的暂存类型、在途库存数量以及对应的快照时间。由于缺乏这样的信息，每个调用者都只能自行拼凑供应链信息。
这就是为什么传统的自助式商业智能工具已无法再发挥作用。十个人查看同一个仪表板时至少会得到相同的错误数据；而十名员工各自编写十条独立的查询，虽然在局部看来似乎合理，但最终只会造成一片混乱，依然得不到准确的数据。
缺乏上下文的分析师会提出跟进问题，而缺乏上下文的操作员则会补全句子。在演示环境中这或许只是趣事，但在实际应用中却是隐患，因为正是那种让数据易于获取的技术，也使得在未达成任何共识的情况下就能轻易查询数据。
人们花了二十年时间通过数据仓库、湖仓、ELT平台、笔记本以及API让数据可被访问，如今瓶颈已出现在其他地方。软件能否看到表格这一点已经有了定论，但软件是否有权决定表格的含义却仍未明确。
含义契约的作用
词汇表存在不足，因为它可能被误读，而契约要么执行，要么被拒绝。一个实用的语义模型所定义的操作，正是企业已经经过讨论并达成共识的内容：
- 已确认的收入有明确的定义，某些行绝不属于此类收入。
- 活跃客户的判定依据是规则，而非主观感觉。
- 财务部门愿意支持的正是客户与区域之间的关联关系。
- 对于这一关键绩效指标，时间范围以发票日期为准，而非订单日期。
- 有些维度可用于数据划分，其余的则仅具装饰性。
其底层包含度量值、维度、层次结构、计算字段、元数据以及行过滤器，这些数据存储在哪个供应商的文件中并不重要。从功能上讲，业务语言中的相关内容已被转化为表格软件能够调用的形式。直到最近，主要调用这些数据的还是报表；而新的调用方式永远不会让人感到厌烦，也无需走到分析师面前，更不必为犯错而羞愧。
团队往往忽略细节处理，因为这看起来像建模作业，但实际上却是API设计中的关键部分。如果不明确规定，每个调用方都会自行定义。归根结底，只需在同一个地方回答四个问题：
- 周期结束的日期是什么。
- 该数值对应的是哪个实体，是销售方、收货方还是开票方。
- 哪些行需要排除，比如员工订单、批发订单、公司间订单以及测试订单。
- 当调用方为代理时，哪些安全规则仍然适用。
如果模型中未包含这些答案，它们最终只会出现在Slack讨论串中，也就是无处可寻。
边际度量指标可以显示具体情况。公式本身没问题，但日期处理有疏漏。一位调用者使用了订单日期，因为事实表默认显示该日期；另一位则使用了发票日期，因为财务视图采用的是该日期。两者都报告了“边际值”，而在运费急剧上升的那周，两者数值相差了两点。虽然真正的缺陷在于缺失了相关数据，但责任却落在了客服人员身上。通过加入发票日期、运费计入规则以及明确数据归属方，问题得到了解决，随后一周的数值便一致了。虽然没人感谢这个模型，但后续的查询请求也消失了。
设计上的目标路径相当单调：意图、绑定、强制执行、运行、回复。模型从未对“收入”究竟意味着什么进行过判断。选择哪个经过验证的指标来对应问题是可以接受的，因为那属于分类任务。而从原始表格中重新组合出指标则属于插值，而插值正是两个官方数字在喝第一杯咖啡之前出现的方式。
追踪记录能讲述整个故事。如果代理程序是通过名称相似度来选择列的，那它就是个“拾荒者”；如果它调用带有小数点和区域的recognized_revenue函数，那它就是个“调用者”。第二种追踪记录虽然没那么生动，但却是审计时需要提供的。
元数据已不再仅仅是文档
过去，描述只是事后才补充的内容，通常在控制面板发布后，且只有当冲刺周期还有剩余时间时才会填写，但这种情况很少见。名为 [NS Adj LY %] 的指标尚可接受，因为负责编辑该文件的三个人了解其历史背景。
智能体并不了解这些规则。微软关于为数据智能体准备语义模型的指南也明确指出：名称、描述、关联关系以及降低歧义性是决定答案质量的关键因素，这一原则在该技术栈之外同样适用。如今，这些字符串已成为强制性的输入条件。即使没有描述，智能体依然可以给出答案，只不过答案会基于传闻内容。
由于文件看起来毫无变化，这种转变很容易被低估。文件中仍然存在包含指标的模型。真正改变的是使用方：人类开发者需要自行推断，而智能体则直接依据输入内容生成结果，即便绑定过程不够严谨，依然能生成附带图表的答案。
如今，一个含义模糊的指标名称也会被视为生产缺陷，就如同没有文档记录的公共函数一样。没人会把fn_x3()用作计费API，但由于有人会调用它，十年来它一直被当作指标API使用。
各平台采取了相同的策略
去掉产品页面上的品牌颜色后，一种规律便显现出来：微软、Snowflake、Databricks和ThoughtSpot都在投资于语义层、治理机制以及他们所称的可靠业务上下文。他们的宣传并非展示模型能够输出SQL的炫酷演示。
所有人都认为，模型应当基于经过验证的含义进行推理，而非仅仅依据与问题中的单词位置最近的那一列数据。在仓库、湖仓及 Power BI 语义模型中工作的 Fabric 风格数据代理便体现了这一理念。同样，倾向于采用语义视角而非原始架构结构的 Cortex 风格分析工具，以及将关键绩效指标提升为平台对象的指标视图与目录系统，也都遵循这一理念。ThoughtSpot 多年来一直在通过建模层提供“向数据提问”的功能，而一旦软件能够成为数据查询的工具，市场其他参与者也立刻明白了其背后的原因。
选择最智能的模型并将其用于处理湖泊数据这一策略，与那些已有付费服务的平台的发展方向相悖。他们在湖泊数据前添加了语义层，是因为模型在SQL处理方面表现优异，而流畅性虽提升了分歧出现的概率，却并未消除分歧本身。购买另一个辅助工具并不会明确客户的定义，只会增加可能出现分歧的界面。
协议无法定义收入
MCP也出现在这些讨论中，该协议有时会被误认为是某种策略。但实际上它确实具有价值。以作为MCP服务器发布的Fabric数据代理为例，截至文档最后更新时它仍处于预览状态：这表明输入问题的地方不必就是维护逻辑的地方。Qlik及其他厂商也采取了相同方向，为那些从不启动原始工具的助手提供受管控的分析功能。提问界面与逻辑处理界面可以相互分离。
不过，将某协议与特定系统绑定是不明智的，因为协议随时可能被替换。永恒的原则是：意义是一种服务，而聊天机器人则是客户端。
通过MCP暴露混乱的Power BI文件只会让这种混乱转移到远程端。无论在Claude、Copilot还是内部工具中，只要发布了相应的内容，代理仍会绑定到[NS Adj LY %]。
无头 BI 已经经历过这种情况。团队在那些没有文档支持的度量指标之上添加了一个简单的 SQL 接口，当数据出现变化时便将责任推给新的客户端。该协议虽然完成了其功能，但它所承载的不过是带有网络路径的民间传说罢了。
因此，该协议依然只存在于底层架构中：用于查找工具、传递上下文、在进程间进行调用。意义的处理则是单独进行的，通过绑定度量指标、拒绝非法的数据粒度以及应用行级安全机制来实现。即便有了定义，若在财务部门面前无人愿意为其辩护，那这种出色的底层架构依然只是带有 URL 的民间传说而已。
过去的BI讨论集中在应选择哪种工具作为标准。而在客服人员作为数据调用方的背景下，更重要的问题是可信的分析环境应存储于何处，以及哪些调用方可以访问它。报告功能可以保留在某个产品中，而客服人员则从更靠近数据仓库的受管控模型中获取数据，反之亦然。不可行的是让每个调用方都保留一份独立的收入数据副本，然后在数据出现偏差时才表现出惊讶。
仪表板变成了众多调用方之一
曾经，仪表板是唯一的重大用户，但现在情况已不再如此。人们长期以来认为语义模型只属于某一种BI工具：Power BI模型用于生成Power BI报告，LookML模型则用于生成Looks报告。在人类是唯一受众且报告本身就是产品的背景下，这种封装方式是合理的。
如今，一份合同即可同时服务于仪表板、Excel表格、运营应用、辅助系统、聊天功能、智能代理，以及能在指标超出设定范围时自动提交工单的功能。虽然仪表板依然有用，但它们已不再是该模型的核心目的，因为图表仅仅是该定义的一种应用形式而已。
这是个值得欢迎的变化。图表很容易过时，而收入、利润率、入住率及客户流失率等定义则应当保持稳定。一旦这些定义得到妥善管理，下个季度推出的新辅助系统就不必重新开始相关计算，负责排查异常的智能代理也能重复使用周报中所依据的指标。正是这种重复利用带来了实际价值。那些逻辑深埋在可视化指标背后的美观仪表板其实毫无用处，因为可视化元素本身无法被直接调用。
每有一篇评论出现，就有人提出反驳：既然模型能够编写SQL，为何还要继续投入资金，为什么不交给智能体处理呢？智能体越来越能够胜任这项工作。但从业务角度而言，恰恰是这种能力导致了问题。数据获取的成本变得很低，而达成一致的成本却依然很高。十名员工盯着同一个仪表板，即便数据有误也会共享同一个数值；而十个智能体进入仓库后，却会生成十个各自认为正确的结果，而且都带着同样的确定性。
一个简化的实验就能说明这一点。取一个仓库、一个问题以及三种没有共同衡量标准的智能体配置，结果就会得到三个营收数字，以及三个解释为何某个数字更“可靠”的理由。有一种方法因为表名中包含order而使用了预订数据；有一种方法将行粒度与标题粒度混淆，从而重复计算了套件数量；还有一种方法虽然使用了发票日期，更接近财务数据，但仍包含了批发业务的数据。如果把这些结果发布到副总裁的讨论帖中，人们会花一周时间争论聊天机器人的功能，而非数据的定义。
无需合同的低成本接入让更多人，现在则是更多智能体，能够编造出属于自己的“真相”。这也解释了为何随着SQL生成技术的进步，建模反而变得越来越重要。
单一技术栈不够用
下一个需要警惕的陷阱是“纪念品式语义层”：在一个工具中经过认证，却在其他所有工具中沦为民间传说。一个团队可能花费一年时间在大家都引以为傲的BI产品中构建出一个出色的模型，之后却直接将代理程序连接到仓库，理由是仓库才是数据真相的来源。实际上只是模糊性发生了转移而已。仪表板显示的是已确认的收入，代理程序报告的是net_amt，而财务部门则继续使用自己的电子表格。这样一来，组织又多了一种不同的表述方式，却并未获得更多清晰度。
判断方法很简单：如果某个指标的定义无法从仓库传递到BI工具，再传递到代理程序，那就只是标签被重新命名了，矛盾依然存在。
可移植性并不需要第四个平台。关键在于，位于原始文件之外的调用方能够执行相同的操作并得到一致的结果。这种载体可以是所有引擎都支持的仓库原生指标对象、无头指标服务，或是通过查询API或MCP适配器访问的严格管控的语义模型。一个简单的测试就能解决这个问题：修改一次定义，看看所有调用方是否会随之调整。那些保持不变的只是副本而已。
当大部分数据都存储在同一个平台上时，仓库原生指标确实很有吸引力，但也存在一个众所周知的缺陷：定义仅在该平台得到确认，而针对其他仓库或副本的代理则永远无法获取到该定义。联邦式方法试图在各个引擎之间保持统一的含义，但一旦所谓的通用层也变成了带有更美观YAML格式的另一个副本，这种方法就会失效。
一个略显丑陋的便携式度量值，比那个只能由三名开发者才能编译的精美度量值更好，因为智能体不会等待那个文件，它们会四处查询。
适合智能体的模型应具备什么特点
大多数被继承的模型都是为那些已经了解办公室内部消息的人设计的。开发者能理解为何某个集合分析表达式会排除某个渠道，而仅能看到结果的智能体则无法理解。那些带有玩笑性质名称的DAX度量值虽然可作为内部约定，但对试图绑定数据的调用者来说却只是无意义的噪声。有一个实际文件中使用[NS Adj LY %]来表示“经调整的去年净销售额的百分比变化，已扣除批发业务及快闪店相关费用”。只有三个人能理解这个代码，而第四个查看者是智能体，它将NS理解为净销售额后就不再继续解析了。
这份检查清单并无特别之处，不过是传统的商业智能处理方法，只是对疏忽行为会收取更高的代价：
- 明确的名称。使用企业已有的术语，因此
recognized_revenue比NS_Adj更为合适。如果两个团队使用不同的术语，应在模型中选择其中一个，并在描述中将另一个作为别名记录，而非用缩写来掩盖分歧。 - 使用范围说明。明确说明该指标的适用场景，例如注明该指标适合用于董事会汇报，不适用于同店即时数据，且不包含批发业务。有了这样的说明，就能区分确定值与猜测值。
- 明确的关系定义。客户、发票和订阅关系应被明确关联，这样就不会因为两个标识都被称为
cust_id而导致处理错误。
以某零售企业的recognized_revenue为例。其计算公式为发票金额扣除折扣后的净值，按发票日期的会计汇率从交易货币换算而来。计算时依据的是发票日期及销售组织，而非收货地址。该指标不包括员工商店、批发业务、测试订单以及公司间销售。其法定维度为根据订单类型设定的销售组织、产品层级和渠道，而营销领域的最后点击数据则不在统计范围内。该指标由财务总监负责管理，当前版本为上周五提交给董事会的报告所使用的版本。
假设有人询问“通过Instagram实现的销售额”。该指标中并不存在这一维度，因此正确的回应应是拒绝回答或将其转交给营销部门负责的其它标准化指标。那些试图自行解决的人会将相关数据接入最后点击分析表，并给结果加上标签。虽然这种关联在技术上可能是可行的，但它描述的是另一家企业的运营情况。
拒绝回答总比沉默好，而沉默又比自行定义指标要好。团队们不愿编写拒绝回复的内容，因为这样会让演示效果更差，但实际上，无法通过演示解决的问题恰恰反映了真实企业的运作方式。
这里并没有用到任何大型语言模型的技巧。所有工作都依赖于传统的商业智能方法——那些曾经用于构建数据模型并规范数据结构的手段。唯一改变的是使用者：过去粗心大意只会导致出现有人能发现的错误仪表板，而现在则会导致机器以极快的速度做出错误决策。
那些不会消失的工作
如果这种方法可行，部分任务队列确实会缩小。当地区是该指标的合法维度时，客服人员可以处理按地区拆分数据的需求。而添加去年数据的需求则属于时间智能范畴，这类数据要么早已被建模，要么根本无需建模。
说BI团队的工作消失了是不对的，因为工作只是转移了地点。仍然需要有人来判定每个关键绩效指标的含义以及其官方版本所在。还需要有人确定哪些数据关系是正确的、哪些数据源值得信赖、以及哪些情况属于例外。此外，还必须明确谁有权查看哪些数据行、哪些模型具有权威性、如何测试变更，以及如何在审查中体现数据来源与责任归属。
那种工作远没有精心制作的可视化成果有趣，大多数时候发布图表似乎更吸引人。不过，其长期价值其实较为有限。可视化内容可以随时丢弃，而一份能让董事会成员和夜间处理任务的员工都理解的定义才是真正的资产。
今后会减少那些隐含“请做成图形界面”的需求，反而会出现更多要求“请承担立法职能”的情况。那些只想负责制作图表的人可能会觉得这段时期相当于降职；而那些希望数据在经过软件处理后依然保持准确的人，则会发现这些吃力不讨好的工作成了主要任务。
反复出现的故障模式
这些问题总被归类为模型质量问题，在更换模型之前确实有必要先检查一下数据质量。
- 列数据收集器。该代理会获取名称中包含
rev的第一个字段。尽管追踪过程看似很繁忙，但实际上并没有任何指标被调用。 - 私有数据颗粒。每个调用方都会自行选择日期，并且都认为自己正确地回答了“上个月”。
- 维基协议。实际规则写在Confluence页面上，自重组以来就再无人修改过，而模型本身仅有一个标注为“销售”的列注释。
- 堆栈纪念品。唯一的官方认证指标存储在BI文件中，该代理之所以与仓库进行交互，只是因为那是最简单的演示路径。
selling_org限制，而获得了区域经理所能看到的全国总数据。该经理平时使用的周一数据看板本应拒绝此类查询。而代理程序因为绕过了唯一的计数控制机制，显得更为“高效”。如果上述两种情况听起来很熟悉，那么就不应首先考虑使用聊天机器人进行评估。应先明确指标的定义并将其详细信息输入模型，再要求代理程序调用该指标，之后才开始进行测量。
一个用于测试评论功能的简单方法：先查询上个月的收入数据，再进一步核实细节。系统选择了哪一列日期？有哪些排除项？员工购买的商品是否被计入？那些需要自行编造答案的代理人，其实只是拥有访问权限的SQL生成工具而已。
另一个测试方法是修改官方的排除列表，比如将员工购买的商品从认可的收入中剔除，然后查看同一天谁对列表进行了更新。如果仪表板发生了变化而代理人却没有任何反应，那就说明真正的API其实是手工编写的文件，而那个代理人只不过是个旁观者罢了。
还要注意那种“乐于助人”的智能体，它会在经过验证的指标缺少维度时悄悄添加一个关联项。就在那一刻，整个方案就毁了。正确的做法应该是说明该指标没有对应的维度。产品经理们不喜欢这么说，但总比后来不得不撤回发给董事会的邮件要好。
不要从聊天机器人开始
大多数项目都是从那些显而易见的工具选项开始的：选择哪种模型、哪种向量数据库、是否使用MCP协议、需要购买多少个Copilot席位。如果目标是获得关于某家特定公司的可靠信息，那么更直接的切入点会更有效。
在表单软件中，收入应如何定义？哪种客户分类具有权威性？目前毛利率的计算逻辑位于何处：SQL视图、DAX度量值、Qlik表达式、笔记本，还是某个人的记忆中？如果答案是“以上几种”，那就说明核心问题并不在于数据的生成。软件将要使用的接口根本就没有被构建出来。
实际的操作步骤如下：
- 找出争议点。选择两个团队已有分歧的某项指标，无需构建复杂的本体结构。
- 制定规则：包括公式、数据粒度、排除项、负责人以及合法的维度。
- 通过单一的安全查询路径提供数据，供报表和自动化工具使用。
- 添加调用方，此时再为该指标配置辅助工具或自动化代理。
由于没有指向官方收入统计流程的指引，该聊天机器人实际上在宣传一个尚未被明确命名的语义问题。
曾有一支团队需要在下一次指导委员会会议前交付一个规划辅助工具，但在最初的两周里他们故意将这个辅助工具搁置一旁。相关功能被纳入了available_to_promise模块，其规则仅记录在一页纸上。处于质量检测阶段的库存以及损坏的货箱均未被纳入统计范围。打包存储的货物数量仅针对批发订单计算，而在运输途中的货物则要等到收到ASN后才予以统计。这些规则被整合进了仓库系统已有的模型中，对于库存相关问题，该辅助工具只能依据这些指标进行回答，不得使用其他数据。首次演示时的反响较为平淡。到了第二周，大家不再在例会上提及第三个数据指标，这便已算是成功，而且模型供应商也保持不变。
仪表板依然存在。精心设计的可视化图表比聊天气泡更能清晰呈现每周的数据状况。它们已不再是最主要的呈现方式，现在无论是人工查看、报告生成，还是自动流程处理，都必须在相同的上下文中进行，而这些自动流程无法察觉数据是否存在异常。
现有的界面
通过两个官方数字进行的简短汇报就能解释清楚一切。模型本身并没有出现任何值得注意的混淆，混乱的是组织结构，而工作人员则将这种混乱以看似专业的表述呈现出来。
当软件开始使用经过规范的公司数据视图描述时，表格就不再作为界面使用，取而代之的是那些有明确名称的指标。
要求工作人员在处理收入数据时谨慎的提示很快就会消失，留存下来的是一个绝不允许临时重新构建收入数据的模型。
最终被发布的内容就是代理所选择的那样。如果展示原始数据表，就能形成一种业务模式；如果展示命名后的操作，或许最终会选用分析师们已经确定的那个。
那些炫目的工具依然具有吸引力：比如在早上6点就能检测到异常值的辅助系统，或是当服务可用性下降时自动创建工单的代理。但它们只对人类已经确定的相同操作保持“诚实”。
从那些已经引发争议的指标入手，针对它们提出四个详细的问题。为该指标设计一个仪表板和一个代理，其余部分则暂不改动，直到这两个工具使用方能达成一个月的共识之后再逐步扩展功能列表。
相关阅读
- 究竟是什么在驱动神经网络：Python背后的AI编译器 —— 探索模型如何从Python表达式经过计算图、运算符融合、MLIR风格的中间表示，最终转化为CPU、GPU及加速器代码。
- 无需LLM即可实现的人性化数据库查询：基于pgvector和Node.js的PostgreSQL语义搜索 —— 利用pgvector、MiniLM嵌入模型以及Node.js在PostgreSQL中构建基于语义的搜索功能：包括标记、分块、向量、IVFFlat索引、距离运算符以及分数解读方法。