观远答得准，蜜雪通管得深 —— 中间那段衔接，今天没有人负责。
一个经营问题 9 天，真正在分析的不到 2 天；其余耗在等排期、找口径、搬数据、走审批。
有回写通道，结论才能真正变成一张工单、派到一个人、追到关闭 —— 而不是屏幕上多出一张表。
演示环境（茶饮场景库）真实输出：7 年数据，26 个问题全跑通。
用贵司真实场景当场跑；网络不配合就逐格讲对应关系。
提一个贵司真实问题，我们用同类场景跑同一问。
贵司写的「数据到行动之间的四道断层」—— 我们逐字照读，然后量化它
经营人员需逐系统、逐报表查找数据，流程繁琐、操作复杂，大量时间耗在「找数据」而不是「用数据」，高频问题反复人工查询。
断点 高频问题全靠人工查 —— 规模一大，必然崩。
能力分散、需跳转外部工具；计划执行与效果反馈数据未完全回流，经营经验沉淀在个人，难以规模化复用。
断点 执行没有回声，复盘只能靠记忆。
分析结论靠人记、工单靠人建，从「发现问题」到「解决问题」链条长、易遗漏、难追踪。
断点 结论到不了执行；到了，也没带上上下文。
既有系统多仅做前端入口权限拦截，接口层缺少权限校验 —— 「人来操作」时代够用，一旦由 AI 代操作即为越权漏洞。
断点 权限只拦在门口 —— 人还拦得住，AI 一接手就等于没拦。
其余全是 等排期 · 找口径 · 对数字 · 搬数据 · 走审批 —— 正是贵司写的「链条长、易遗漏、难追踪」。
| 算式：每月问题数 × 单次延迟 × 日成本 × 可挽回比例 × 12 个月 | 保守档 | 中性档 | 激进档 |
|---|---|---|---|
| 每月被延迟拖住的经营问题 | 150 个 | 300 个 | 500 个 |
| 每个问题的决策延迟（对照上一页那 9 天） | 6 天 | 9 天 | 12 天 |
| 延迟一天的代价（损失 + 人力搬运，日化） | 1× | 2× | 3× |
| 闭环后可挽回的比例 | 25% | 35% | 45% |
| 年化价值 | 四个变量里，有两个只有贵司自己能填 | ||
第 7 天算出来的归因是准的、漂亮的。但它到第 9 天变成一条没人看懂的通知 —— 这九天的延迟，一点价值都没有被挽回。
输入问题，输出数字。贵司已经为这一格投过资源了。
终点 屏幕上的一个数字 —— 谁去执行？做完了吗？它答不了。
这五步今天散落在五个系统和三个人之间，无人负责 —— 9 天的延迟，就是它们之间的路。
终点 工单关闭的证据 —— 这才叫「问题被解决」。
任意经营问题，自然语言一句话、秒级给数，答案带口径版本与 SQL。
验收 抽 30 个高频问题，答案与观远 BI 页面口径一致 —— 不一致即判错。
权限下沉到接口层，AI 只读不改；不该看的数据根本到不了 AI 眼前，每一步动作都留痕。
验收 越权类问题必须拒答；每一次调用都查得到、跑得回去。
结论能变成工单、派到责任人、追到关闭 —— 不是停在屏幕上的一张表。
验收 从「得出答案」到「工单关闭」，全链可追踪。
① 问数 Agent（只看，不动手） ② 工单 Agent（建单 / 派单 / 改状态，会动手但每步留痕）。
五步闭环、两个 Agent、知识底座、三道闸门
答案生成了，然后呢？第 4 步把结论变成工单，第 5 步把质疑变回资产 —— 这两步不做，系统越用越脏。
SOP 与口径是少数、人写、常改的活文档，不是海量语料 —— 检索问题不存在；版本与责任人靠治理，不靠向量抽取。全量 GraphRAG 让 LLM 抽三元组，成本 5–10 倍且不可控。
SOP 条款以百计、口径文档以十计，用治理管就够。
知识库自己不管权限 —— 我们在MCP 层强制：谁能问哪类知识、答案带出处与版本、问过必留痕，越权请求直接拒绝。可测，不是承诺。
加盟商问不到直营口径、督导看得到全量 SOP，权限跟角色走，不跟群走。
闸门是写进合同的正式验收点：到点验收、达标才进下一阶段 —— 不达标就停在那里，决定权在蜜雪，不在我们。
查什么：每个指标口径写死成文档（数字从观远哪个数据集来、谁定义）；行级权限逐条确认（谁看哪个区域）。
不通过 → 不开工。带着模糊口径写代码，返工烧的是蜜雪的钱 —— 先把地基钉死。
查什么：问数准确率 ≥ 90% —— 由蜜雪出题盲测，不是我们自测；五类越权渗透 100% 拦截。
不通过 → 限期整改、重测。整改仍不过，项目不进推广阶段。
查什么：纠偏工单 7 日闭环率、店长每周实际使用率 —— 看真实用没用，不看演示。
不通过 → 不推广、不续费。效果没到，项目就停在这里，我们不缠着你要下一单。
五类渗透用例必须 100% 拦截：跨区越权 · 提示词注入 · 绕过前端调接口 · 敏感字段脱敏 · 审计日志完整。
整体架构 · 问数 Agent · 工单 Agent · 数据与模型 · 分期路径
贵司的硬门槛写得很清楚：数据源仅观远、口径统一可溯源、不新建数仓、不重复治理。我们照做。
蜜雪通开放的不是数据源，是工单读写最小集（白名单 + 需求评审）—— 让结论变成工单并追到关闭。
明细与口径都回观远查；我们做的是「问数 → 报告 → 建单 → 回流」的编排、留痕与评测。
先判断这是哪一类问题，再定位到哪个指标、哪一份口径、哪个版本 —— 表里没有的口径先问再答，不猜、不近似。
验收 问题归了哪一类、用的是哪份口径，都写进日志 —— 归错类看得见，不是黑箱。
把「杯量 / 出杯 / 单量」这类说法对到观远与蜜雪通 API 的同一张表；对不上就报错，不瞎猜。
验收 对照表可维护、改动可追溯；对不上就报错，宁可答不出，不给近似值。
生成可审计的 SQL，谁能看哪一行在生成时就写进去；再做静态检查、空跑、结果合理性检查，三道都过才发出去。
验收 三道校验全过才出答案；任一道不过，宁可不出。
答案带口径版本与可展开 SQL；要动手就转工单。整条链路在 MCP 层留痕 —— 谁问的、查了什么、谁改了状态，全部可追溯。
验收 答案 100% 带出处；同一个问题再跑一遍，答案一致。
拆成四段，是因为每一段都能单独测、单独换模型、单独定验收 —— 哪一段掉分就改哪一段，不会搅成一锅粥。
建一张口径登记表 + 一张术语对照表：把「杯量 / 出杯 / 单量」钉成同一个指标、同一个版本。口径定不下来，模型再强也答不准。
三个说法先钉成一张表、一个版本
从贵司历史的正确问答里取示例教模型 —— 建的是口径样例库：少而准、人能维护。
从历史正确问答取 50–100 组样例
SQL 静态检查 + 空跑 + 抽样试跑，三道都过才出答案；越权条件在生成 SQL 时就写进去，不该看的数据根本没机会被 AI 看到。
越权条件在生成时就注入
答错的题自动进评测集；每次口径变更先重跑一遍评测集，不达标不上线 —— 准确率不是一次调好，是每轮不往下掉。
掉分就退回上一版，不带病上线
四道都不依赖「换一个更强的模型」：换模型是加分项，不是前提。真正决定准确率的，是口径有没有钉死、错题有没有回流。每一道都有人名和日期。
指标问数 15 题 —— 数字对不对
归因分析 10 题 —— 结论站不站得住
越权拒绝 5 题 —— 必须拒答
贵司出题、我们补边界题：题不是我们单方面挑的。
题库定版即冻结，改题要双方同意
每题以 观远 BI 页面口径为基准，不一致即判错；有争议的题人工复核。
基准在贵司手里，所以我们给自己打不了分。
判分脚本交给贵司，谁都能跑
上线前与上线 4 周后两档，具体数字在第 15 个工作日由双方一起定、写进验收表。
分数线不由我们单方面画。
两档数字在第 15 个工作日写死
每轮重跑不达标，不上线、不进入下一期；偏差题进错题集、限期修，修完重跑。这就是三道闸门里第二道闸门（第 8 周问数达标）的具体内容。
先判断要不要建单；要建，就从结论里抽字段，不靠人重新打字 —— 口径与来源一并带过去。
只做 建单 / 派单 / 改状态 这三件事；其余一律拒绝。字段结构化，写之前先校验。
谁能接、谁在忙，按角色和手上的活自动派给责任人；越权单直接打回，派不出去。
每步结果回流到观远对账、回写蜜雪通；工单从建到关全链留痕，关单即闭环。
金额调整、权限变更、库存直调 —— 这些必须人工点确认，AI 只递单不执行；写前校验、写后可回滚。
不是入口拦一下，是每一次调用都过鉴权：谁能建什么单、改什么状态，由 MCP 层逐请求校验，越权直接拒绝。
只许建单 / 派单 / 改状态；字段写前校验、写后可回滚，越权数据从未进入模型上下文。
谁建的单、派给谁、改了什么状态、结果是哪条执行证据 —— 全部可审计、可复跑，出事能追到源头。
与问数共用同一套评测集与闸门：工单动作 100% 留痕、五类越权 100% 拦截；不达标不上线。
五类渗透用例必须 100% 拦截：跨区越权 · 提示词注入 · 绕过前端调接口 · 敏感字段脱敏 · 审计日志完整。
意图理解 · NL→SQL · 答案组织 · 工单草拟 —— 都是「把话听懂、把话写好」的认知活， 出错顶多答得不好，不会改坏数据。
权限校验 · 工具调度 · 留痕审计 —— 由 MCP 层确定性执行。 越权数据在 SQL 编译期就被拦掉，从未进入模型上下文。
Phase 1交付期 第 1–3 周
每个指标口径写死成文档、行级权限逐条确认。
闸门 ① · 第 3 周：口径没定案就不开工
前提：第 2 周前定下 API 接口人
Phase 2交付期 第 3–8 周
区域经理 @ 一句，答案附口径版本与 SQL。
高频问题先上线，长尾问题第 8 周前补齐。
闸门 ② · 第 8 周：蜜雪出新题来测，达标才进。
Phase 3交付期 第 6–13 周
建单 / 派单 / 改状态全链留痕，证据回流观远对账。
与问数共用口径与权限、不重复建。
先做的不白做，后做的不重来，年底上线。
先跑一遍真实系统 —— 不是架构图
现场三段，共 4 分钟 —— 每段替评委问出一句话，然后当场跑给贵司看：
在蜜雪通里 @ 一句「上周杯量归因」—— 看三条归因 + 建议，每条答案带数据来源。
回应：「数准不准？」
看点 它答的是「为什么」，不是「是多少」—— 业务方当场就能判对错。
点开答案背后的 SQL 与口径版本 —— 看它怎么面对质疑，而不是躲。
回应：「错了能不能查？」
看点 口径版本与 SQL 当场展开 —— 质疑打不穿，因为能查。
一键建单派给督导，追踪到关闭 —— 看最后一步怎么走完。
回应：「然后呢？谁去做？」
看点 工单号当场生成、当场派到人 —— 闭环看得见，不是 PPT 上的箭头。
9 天延迟继续；一线继续拼 Excel；SOP 继续靠抽查。
代价：每年累积，没有终点。
跨域拼装与执行回写不在其产品边界内 —— 不是不好，是不做这件事。
代价：周期与条件由对方定。
需同时招齐数据 + 后端 + 算法；SOP 语义没人写 —— 招齐人也未必有人敢写。
代价：6–9 个月成型，试错自担。
不碰 T1 问数，不替代观远 —— 只做观远到不了的一百米。
代价：15 个工作日先测，不达预期可停。
多数评审会上赢的是它，不是因为对，是因为它没有必须今天就回答的问题。我们把它写出来，是把「不决定」也变成一个要签字的决定。
产出：贵司真实的延迟天数 —— 自己的数字。
产出：一页范围书 —— 做、不做、怎么算赢。
产出：一份工作说明书 —— 范围与排期。