观远答得准，蜜雪通管得深 —— 中间那段衔接，今天没有人负责。
一个经营问题 9 天，真正在分析的不到 2 天；其余耗在等排期、找口径、搬数据、走审批。
有回写通道，结论才能真正变成一张工单、派到一个人、追到关闭 —— 而不是屏幕上多出一张表。
任意经营问题，自然语言一句话、秒级给数，答案带口径版本与 SQL。
验收 抽 30 个高频问题，答案与观远 BI 页面口径一致 —— 不一致即判错。
权限下沉到接口层，AI 只读不改；不该看的数据根本到不了 AI 眼前，每一步动作都留痕。
验收 越权类问题必须拒答；每一次调用都查得到、跑得回去。
结论能变成工单、派到责任人、追到关闭 —— 不是停在屏幕上的一张表。
验收 从「得出答案」到「工单关闭」，全链可追踪。
① 问数 Agent（只看，不动手） ② 工单 Agent（建单 / 派单 / 改状态，会动手但每步留痕）。
先判断这是哪一类问题，再定位到哪个指标、哪一份口径、哪个版本 —— 表里没有的口径先问再答，不猜、不近似。
验收 问题归了哪一类、用的是哪份口径，都写进日志 —— 归错类看得见，不是黑箱。
把「杯量 / 出杯 / 单量」这类说法对到观远与蜜雪通 API 的同一张表；对不上就报错，不瞎猜。
验收 对照表可维护、改动可追溯；对不上就报错，宁可答不出，不给近似值。
生成可审计的 SQL，谁能看哪一行在生成时就写进去；再做静态检查、空跑、结果合理性检查，三道都过才发出去。
验收 三道校验全过才出答案；任一道不过，宁可不出。
答案带口径版本与可展开 SQL；要动手就转工单。整条链路在 MCP 层留痕 —— 谁问的、查了什么、谁改了状态，全部可追溯。
验收 答案 100% 带出处；同一个问题再跑一遍，答案一致。
拆成四段，是因为每一段都能单独测、单独换模型、单独定验收 —— 哪一段掉分就改哪一段，不会搅成一锅粥。
建一张口径登记表 + 一张术语对照表：把「杯量 / 出杯 / 单量」钉成同一个指标、同一个版本。口径定不下来，模型再强也答不准。
三个说法先钉成一张表、一个版本
从贵司历史的正确问答里取示例教模型 —— 建的是口径样例库：少而准、人能维护。
从历史正确问答取 50–100 组样例
SQL 静态检查 + 空跑 + 抽样试跑，三道都过才出答案；越权条件在生成 SQL 时就写进去，不该看的数据根本没机会被 AI 看到。
越权条件在生成时就注入
答错的题自动进评测集；每次口径变更先重跑一遍评测集，不达标不上线 —— 准确率不是一次调好，是每轮不往下掉。
掉分就退回上一版，不带病上线
四道都不依赖「换一个更强的模型」：换模型是加分项，不是前提。真正决定准确率的，是口径有没有钉死、错题有没有回流。每一道都有人名和日期。
指标问数 15 题 —— 数字对不对
归因分析 10 题 —— 结论站不站得住
越权拒绝 5 题 —— 必须拒答
贵司出题、我们补边界题：题不是我们单方面挑的。
题库定版即冻结，改题要双方同意
每题以 观远 BI 页面口径为基准，不一致即判错；有争议的题人工复核。
基准在贵司手里，所以我们给自己打不了分。
判分脚本交给贵司，谁都能跑
上线前与上线 4 周后两档，具体数字在第 15 个工作日由双方一起定、写进验收表。
分数线不由我们单方面画。
两档数字在第 15 个工作日写死
每轮重跑不达标，不上线、不进入下一期；偏差题进错题集、限期修，修完重跑。这就是三道闸门里第二道闸门（第 8 周问数达标）的具体内容。
先判断要不要建单；要建，就从结论里抽字段，不靠人重新打字 —— 口径与来源一并带过去。
只做 建单 / 派单 / 改状态 这三件事；其余一律拒绝。字段结构化，写之前先校验。
谁能接、谁在忙，按角色和手上的活自动派给责任人；越权单直接打回，派不出去。
每步结果回流到观远对账、回写蜜雪通；工单从建到关全链留痕，关单即闭环。
金额调整、权限变更、库存直调 —— 这些必须人工点确认，AI 只递单不执行；写前校验、写后可回滚。
Phase 1交付期 第 1–3 周
每个指标口径写死成文档、行级权限逐条确认。
闸门 ① · 第 3 周：口径没定案就不开工
前提：第 2 周前定下 API 接口人
Phase 2交付期 第 3–8 周
区域经理 @ 一句，答案附口径版本与 SQL。
高频问题先上线，长尾问题第 8 周前补齐。
闸门 ② · 第 8 周：蜜雪出新题来测，达标才进。
Phase 3交付期 第 6–13 周
建单 / 派单 / 改状态全链留痕，证据回流观远对账。
与问数共用口径与权限、不重复建。
先做的不白做，后做的不重来，年底上线。
现场三段，共 4 分钟 —— 每段替评委问出一句话，然后当场跑给贵司看：
在蜜雪通里 @ 一句「上周杯量归因」—— 看三条归因 + 建议，每条答案带数据来源。
回应：「数准不准？」
看点 它答的是「为什么」，不是「是多少」—— 业务方当场就能判对错。
点开答案背后的 SQL 与口径版本 —— 看它怎么面对质疑，而不是躲。
回应：「错了能不能查？」
看点 口径版本与 SQL 当场展开 —— 质疑打不穿，因为能查。
一键建单派给督导，追踪到关闭 —— 看最后一步怎么走完。
回应：「然后呢？谁去做？」
看点 工单号当场生成、当场派到人 —— 闭环看得见，不是 PPT 上的箭头。
产出：贵司真实的延迟天数 —— 自己的数字。
产出：一页范围书 —— 做、不做、怎么算赢。
产出：一份工作说明书 —— 范围与排期。