一个故事，三个切面
公司、产品、技术，本质是同一件事：把企业的业务变成 AI 能理解的语言。
圆周率
以本体论为基座的 AI 公司——让 AI 读懂你的企业。
零售大脑
一支为你工作的分析团队——洞察归你，苦工归它。
π本体
可执行企业本体——让 AI 用企业认可的对象与关系，理解、分析并证明经营结论。
先回答问题、快速取数；再往下做归因下钻、异常检测、预测分析；最后给出一条有逻辑的经营建议。
一条对话，把数据问成生意。每一个数字，都有出处；每一个结论，都经得起追问。
回答问题 · 快速取数
「上周华东区毛利率是多少？」几秒回数，每个数字带系统签发的凭证，可当场回验。
归因下钻
「为什么低了 1.8 个点？」按品类 × 渠道 × 门店层层拆，锁定主因——分项和总体对得上账。
异常检测
不等你问，持续盯着销售、毛利、库存；发现异常自动立案，先判真假，再查原因。
预测分析
「照这个卖法，这批货多久卖完、会剩多少？」按当前动销推演，给出区间和依据，不给拍脑袋的数。
经营建议
最后落到动作：调谁的货、补多少、什么时点——每条建议带测算，经得起继续追问。
能力是一条递进链，不是五个功能模块——问到哪一层，它答到哪一层。
一次完整的调查
经营异象 = bug，立假设 = 猜问题在哪，三道关 = 测试——红了就换方向再查，全绿才交付动作。
把问题定准，把风险量出来
渠道报的「完成 92%」是发货口径，终端激活口径只有 68%——三个部门拿的本来不是同一个数；按各区域实际到店周对齐后，缺口从 32 修正为 28 个点，问题成立。
问题藏在哪
按区域 × 渠道类型 × 配置三维交叉：华东拖累最大、商场授权店明显落后、中配 256G 集中——指向 华东 × 商场授权店 × 中配 256G。
三个说法，加一个谁都没说的
铺货晚 ✓ 不够、竞品抢声量 ✓、「终端根本没在卖新款」✗→✓ 翻案——老款返利每台多 50 元导购主推清库，新款主推色断货 17 天、定价高 ✗ 排除。
交付的不是报告，是三刀动作
新老款返利一周内拉平、新款加 30 元；老款 3.1 万台切到以旧换新 + 电商专供，再压一个月多贬约 ¥380 万；主推色先调拨 4000 台再追单 1.8 万台。
证据链不断
「返利改了，压在渠道里的老款怎么办？」——两条清库路径各算一遍：以旧换新通道 6 周清完、贬值 4.2%；电商专供 3 周清完、贬值 7.5%。
演示很惊艳，三个月后没人用了
不是企业不想要 AI 分析——是被它错过一次之后，再没人敢在重要场合引用它的数。
「这个 2.3 哪来的？」
AI 报了句「华东区毛利率下滑 2.3 个百分点」，CFO 追问出处，没人答得上来——从这一刻起，这套系统在这家公司就死了。
错数字，藏在你不知道的地方
让 AI 直接对着数据库查询，它会「高高兴兴地给你一个错数字」——而你不知道是哪一个。
各拿一版「正确」的数吵架
数字本身没错，但含税口径、可比范围、能不能加总弄错了——这种错藏得最深，发现时决策已经做完。
该问的是：错的那些去哪了？
让分析 AI，像 coding agent 一样工作
代码世界靠「测试」让 AI 敢交代码；我们为经营分析造了同样的装置——问得合法、数有出处、话不越界，每一步的裁判都独立于 AI。
口径即法律
不能加总的数不会被硬加；语义不对的问题根本不会被执行——裁决发生在算之前，错数没有出生的机会。拒绝带处方，每次都说清改哪里才问得对。
规则只有一份：AI 问答、报表、接口走同一套裁决。数字凭证制
取数那一刻就签发凭证并留档证据——数值、单位、口径、时点。凭证是系统造的，AI 伪造不出来；台账独立于 AI，损坏了对不上号，系统自己先报。
任何人、任何时候，指着报告里任何一个数，当场重查留档证据。逐句核验制
最隐蔽的幻觉是数字全对、话说过头。报告发出前，每句话里的每个数字，沿独立于 AI 的通道回到证据台账重新比对——核不过，发不出来。
叙述不得越过证据；核不过就降级，不硬撑。三道关全过，才配的口吻——每个数带凭证，可当场回验。
标明依据几项证据的分析判断——有据，但未到结论级。
只提议、不定论——证据不够时，它明说，不会用流畅的话掩盖不确定。
它为什么懂你的生意
不是把 AI 接到数据库上，而是先为你的企业建一个业务本体（Ontology）——AI 看到的不再是表和字段，而是生意本身。AI 问答、报表、权限，共用同一份本体。
只读接入
对接现有数仓与业务库，只读接入，一行不动，不建第二套数据真源。
款 · 店 · 仓 · 渠道 · 会员
关系不靠画——同购、替代、带动，从每一笔购物篮事实里按需算出来。
属性 · 状态 · 指标
每条声明有来源、有 owner；「口径即法律」的法律条文，就住在这一层。
拆解 · 归因 · 推演 · 异常检测
注册在本体上的算子，输出自带证据与阈值出处——不是提示词。
不让 AI 写 SQL，让它走一条受治理的路
只讲对你有用的部分：每个设计，都对应它替你挡住的一种错。
不是让 AI 连库写 SQL
行业常见：AI 自由生成 SQL → 直连数据库，口径可能错、数据可能编、权限可能越，只能靠提示词约束 AI 的自觉。我们：AI 只能调用登记过的能力（单一入口，标准 MCP 协议）→ 业务本体校验口径与权限 → 问题先体检再执行 → 三道关判决。
正确性做成系统不变量，不靠提示词约束 AI 的自觉。一个数字的一生
声明口径 → 问题体检（★ 不能加的数算前就拒 · ★ 拒绝带改法）→ 执行取数 → ★ 签发凭证（每个数带出生证）→ ★ 机器回验（不是 AI 说「核过了」）→ 结论判决（话不越过证据）→ 开口。
★ ＝ 2026-08 全球架构对表中，公开技术面上查无对应物的设计；四项联动完全独有。四项核心机制
全球公开技术面上查无完整对应物的四项设计，各自是一条可验证的性质：不合法的查询在执行前被拒，拒绝自带修复动作；每个数可按原查询、以你的权限回放核验；每句结论过五档判决，越界即降级；归因必须对账、有界、可证，对照组由声明策略派生。
把治理从资料侧推进到出口侧：声明 → 准入 → 引用 → 回放 → 判决，一条闭环。不动你现有的系统
零售大脑是加在现有数据体系上的一层，不要求建第二套数据真源；整套系统部署在你自己的环境里。
接入数据
对接现有数仓与业务库，只读接入，不改动任何现有链路。
建模业务本体
把对象、关系、属性、状态、指标、口径建模一次——重活由我们交付，这一步同时完成全公司口径的统一。
从最痛的场景试点
选一两个高价值场景起步，用你真实的经营问题验收，再逐步铺开。