AI 数据分析大纲审阅与逐章写作方案

2026-10-21：本文下列编号和逐章安排保留历史备课语境，不是现行大纲。当前基础篇至第十六章，新增 QM JOIN；时间比较、累计、滚动与 LAG 集中到高级篇，后续章号待定。以总大纲和基础实战大纲为准。

2026-10-20 更新：从第九章起按 Foggy 功能点分章，当前顺序以功能章节规划为准。旧第十章及以后的安排保留作素材，在线接入与高级篇章号待统一顺延。第十章经复审进入后续写作；第十一章基础时间分析已实测、自审待阅，窗口执行问题另记。

审阅日期：2026 年 10 月 14 日；结构更新：2026 年 10 月 17 日。对应总大纲 v7。

采用技术篇 5 章、实战篇 8 章、高级篇 8 章，共 21 章的结构。现有文档与文章可以支撑主体内容；需要新写的重点是 AI 与 CLI 的完整操作过程、Console 与 FAP 的接入教程，以及配套高级分析样例。本文件保存与总大纲 v7 一致的逐章写法，语义 SQL 和统一执行计划后移到高级篇。

课程的主线是：先理解查询为什么容易出错，再理解语义层如何约束执行；随后让 AI 使用 CLI 完成接入、建模和验证，交付浏览器问数；最后处理多来源、分阶段计算与多维分析。

建议调整的内容

需要统一的技术表述

1. 三条查询路线按执行关系介绍。 前一个语义 SQL 面向模型或虚拟表；SQL 入口可解析为内部查询表达或计划，不要求所有产品都会生成一份公开 JSON DSL。v1.0 白皮书第 8.4 节明确区分当前 DSL 能力与 Virtual Semantic SQL 方向。
2. 已有高级教程的宽表达能力与 v2 的结果阶段窄合同分开讲。 QM formula、查询时 calculatedFields、DSL_CTE 的 derive/window_derive 处于不同执行面。某个窗口函数出现在基础教程中，不代表能放进所有 result-stage 合同；应分别按对应 schema 和方言验证。QM 定义、高级分析教程与受治理表达式参考需要配合使用。
3. Compose 与 Memory Grid 的支持范围分别标明。 已有 WWI 商品对比文章使用 Compose full join；Memory Grid v2 的参考却明确不承诺 full outer join，不能把一个入口的能力或限制推广到另一个入口。商品结构案例、Memory Grid 参考。
4. 查询解释注明依据。 DEFINITION 解释定义，RECOMPILED 在当前模型与身份下重新编译。它们不能替代过去某次查询的真实执行记录；FAP 工具调用记录与数据库历史执行证据也分别说明。Runtime API、数字解释案例。
5. 实战入口采用统一版本。 白皮书负责语义契约，实施手册记录指定版本的操作与证据，CLI 帮助和实际 Runtime 能力决定本次命令。旧教程的分页外壳、字段路径、工具名称与 payload 不能跨入口原样复制。能力基线的验证日期为 2026-08-22、Launcher 为 0.1.17；当前引擎 README 示例已到 0.1.18。v3.0仍为草案。

全书怎样写

始终围绕 AI 展开

全书的主目标是建立一个让 AI 能够正确、如实回答用户问数问题的语义层。围绕这个目标，讲清 AI 怎样理解业务问题、选择数据与分析方法、构造查询，再依据实际执行结果回答。SQL、DSL、ETL、CLI 和在线问数入口，都围绕它们在这条链路中的作用展开。

验收分两层：正确，检查问题理解、指标口径、时间、单位、粒度、权限与计算；如实，检查回答是否得到返回结果支持，是否交代范围与限制，是否把未知、无记录、零值和执行失败区分清楚。语义层提供上下文、执行约束和可核对的结果，回答端仍要校验，不能将查询成功等同于答案可靠。

讲解每项机制时，说明 AI 原来需要做什么，机制接手了哪些工作，AI 还需要哪些业务元数据、协议说明或工具反馈，以及怎样验证查询和回答。讨论取舍时，优先分析它对 AI 的理解、生成、执行与纠错带来的影响，再补充必要的工程条件。

模型定义、查询规则、协议说明、工具执行和 LLM 的判断职责要分清：不能把模型文件直接等同于 LLM 上下文，也不能把系统执行的约束说成 AI 自己保证。复杂分析从 AI 怎样拆解问题、选择步骤和检查中间结果切入；实战篇继续围绕 AI 配合 CLI 与用户协作展开。

每章自审检查：读者是否看清 AI 在哪里获得信息、作出判断、调用工具；系统接手了哪些规则；最终回答有何依据，遇到歧义、失败或能力边界怎样处理。技术原理与配置细节围绕这些问题取舍。

案例安排

实际写作优先复用已验证模型和查询。技术篇小例子如果从 Chinook 简化，标明是教学简化；WWI 的订单、开票、税额等口径只在相应案例中使用。高级篇不为凑数据源数量强行把所有来源放进一条查询。

三类章节的写作模板

技术篇：一个问题、一组对照、一个机制。 从业务问题开篇，先展示结果或差异，再用小图和有限代码解释。结尾说明何时采用、需要付出什么，以及下一章解决什么。完整属性表放在文档链接中。

实战篇：给 AI 的任务、实际行动与结果核对。 每章给一段能交给 AI 的任务说明，展示关键 CLI 调用和必要 JSON 结果，再解释 AI 如何据此选择下一步。AI 编辑模型或查询文件时，同时展示文件变化；指标含义由人确认。CLI 是运行能力入口，配套 Skill 是操作指导，模型文件是业务定义。

高级篇：阶段输入、输出粒度与适用范围。 先画出分析步骤，明确数据源、字段、匹配键、指标、公式和规模，然后展示 AI 构造计划、CLI 校验和结果复核。正文完成一个能运行的范围，再列出扩展思路。

建议技术章节约 1800 至 3000 字，应用章节约 2200 至 4000 字，高级章节约 2500 至 4500 字。接入细节较多的第 11 章可按同一章拆成两篇文章或两段视频。字数用于控制单次阅读负担，不要求每章等长。

技术篇逐章方案

第 1 章 从自然语言到 SQL

核心问题： AI 怎样把一句话转换成数据库能执行的查询？

正文顺序：

1. 从“某月销售额最高的十个客户”开始，展示一个简单结果表。
2. 给出必要表结构、字段说明与日期范围，展示 AI 生成物理 SQL 的过程。
3. 拆解选择字段、关联、过滤、分组、排序与执行；说明上下文从哪里来。
4. 说明小范围、低歧义、人工复核场景的价值，以及后续复杂业务带来的维护成本。

案例与产物： 一条问题、一个 Schema 小图、一条 SQL、一张结果表。练习是把月份和 Top N 改动一次，观察查询变化。先给出正确基线，第 2 章再引入失败例子。

材料： 自然语言到 DSL 再到 SQL 的案例可用于反向说明物理查询；v1.0 白皮书第 3、7 节用于查询契约与方言背景。

第 2 章 SQL 能执行结果为什么仍可能不对

核心问题： 数据库没有报错，业务为什么仍说数字不对？

正文顺序：

1. 用一个教学反例：发票头金额为 100，关联两条明细后直接累计头金额，得到 200。
2. 解释事实粒度、关联基数，以及订单、发票、日期和税额口径的区别。
3. 对照两条都能执行的 SQL，找出各自回答的实际问题。
4. 说明数据覆盖、身份范围和空结果也会改变答案，强调对照原始记录或已确认报表独立复核；适用人群与路线选择集中在第 5 章。

案例与产物： 错误与正确查询的对照表。练习要求说明差异原因，而不是只把最终数字改对。退款、缺失等反例按实际样例是否包含相应字段选择。

材料： 订单与开票销售额案例、题库通过与业务交付的区别。

第 3 章 语义层的作用与代价

核心问题： 语义层怎样参与查询执行；采用自定义 DSL 后，LLM 还需要哪些协议上下文？

正文顺序：

1. 从第 2 章的重复规则出发，归纳语义模型的业务对象、主键、粒度、维度、属性、指标与关联，沿用销售额定义卡。
2. 给出产品无关的结构化模型示意，解释来源、类型、计算、聚合和关联怎样被系统解析，而不只是被 AI 阅读。
3. 展示源定义到公开字段的对应，以及按当前用户可见范围导出查询元数据的过程；组织为 Markdown、JSON 或工具描述交给 LLM，源文件不直接充当最终上下文。
4. 沿六月客户前三名展示 LLM 根据元数据生成语义请求，引擎根据完整模型完成字段绑定、权限校验、规则展开、关联与聚合规划、SQL 编译；再用平均金额说明计算上下文，用发票金额与商品维度说明字段组合约束。
5. 归纳复用定义、整理查询面和可追溯性的作用；新增问题聚焦自定义 DSL 的适配成本，区分业务元数据与查询协议，说明提示词、工具 Schema、示例及验证题库的作用，并引出语义 SQL。口径确认与模型测试作为共同前提，不再列为语义层特有的主要矛盾。本章不引入 Foggy 或 TM/QM。
6. 简述 ETL 分工和无数仓的起步方式，用客户数量练习收尾。

案例与产物： 销售额定义卡、结构化模型与导出 Markdown 的对照示意、元数据与执行两条支路的流程图、规则展开表；不把示意当作可加载配置。练习是为“客户数量”写明计数对象、去重键和日期口径。

材料： 指标定义与分组维度、业务对象与语义映射、业务定义与 Agent 说明的分工。具体产品比较保留为选读参考，不在概念章展开。

第 4 章 自然语言到 DSL 再到 SQL

核心问题： AI 提交查询意图后，引擎怎样把它落实为物理查询？

正文顺序：

1. 沿用第 3 章产品无关的语义模型与字段，重做第 1 章的问题；补充业务别名、枚举或维度值、相对日期怎样确定。
2. 约定一套最小教学 DSL，把自然语言对应到字段、时间、分组、指标与排序；说明 JSON 只是载体，协议由接入方提供，并对照聚合前后筛选，说明 SUM 不可套用于所有指标。
3. 跟随引擎完成字段校验、业务权限、关联规划、方言编译和执行。
4. 引入一个不可见字段错误，展示结构化诊断如何帮助 AI 修正请求；小结只归纳查询职责，路线判断留到第 5 章。

案例与产物： 一次教学查询过程，含 DSL、等价物理 SQL 和结果。明确 SQL 用于解释规则落地，不冒充真实引擎编译证据；完整产品语法、TM/QM 与工具接入放到实战篇。

材料： v1.0 白皮书第 3、4、6 节、Query DSL 语法参考、完整查询案例。

第 5 章 怎样选择和组织问数方案

核心问题： 什么场景适合直接 Text-to-SQL 或语义层，选定起点后怎样组合系统能力？

正文顺序：

1. 从使用者审查 SQL 与结果的能力、指标复用、多人服务和交付要求判断起点；迁入 SQL 客户端与报表的类比，说明两种方式可并存。
2. 决定采用语义层后，说明已有分析系统、独立语义服务和数据平台语义能力的组合方式。
3. 区分元数据工具、物理 SQL 执行工具与语义查询入口，不把工具接通等同于业务规则已经执行。
4. 用客户变化分析解释多步 Agent 的拆解与中间结果检查，并说明数据与因果解释的边界。
5. 用一个问题和一次追问检查整条链路，结束技术篇；不展开具体产品或 DSL 与语义 SQL 的入口选型。

案例与产物： 路线选择说明、通用组合方式对照表、一次查询与一次追问的检查要点。原平台比较稿保留为选读资料，功能状态沿用原核对日期。

实战篇逐章方案

第六章已完成环境与数据接入，按用户要求暂定；第七章已完成探查与独立基线，按用户要求暂定；第八章建模与查询验证已完成，初稿待审阅，后续章节仍为规划。以实战篇专项大纲中的样例、环境与验收为准。第六至十三章统一使用 Chinook，固定 Codex 桌面端与 PowerShell；第六章合并范围、Foggy 简介与接入，第七章探查，第八章建模并完成首次语义问数。

第 6 章 认识 Foggy，准备第一个问数项目

给 AI 的任务：“先确认音乐商店问数的范围，再检查本机环境，连接 Chinook 副本，列出数据源绑定和可用表；遇到缺项先报告，不擅自切换样例。”

正文顺序与验收：

1. 用一页范围卡确定首批问题、使用者、2012 年练习期间和不能回答的问题；口径细节留第七章用实际数据确认。
2. 将前文的通用概念对应到 Foggy：TM 承载数据映射、关联和指标，QM 组织查询面与公开字段，Runtime 加载执行；CLI 提供操作入口，Skill 指导 AI 使用，不重讲语义层价值。
3. 开发工具固定为 Codex 桌面端与 PowerShell。说明工作目录、给 AI 的任务和关键输出怎么看，再按候选发行组合准备 Java、Launcher、Runtime CLI 与配套两个 Skill。
4. AI 检查就绪与 capabilities，添加和测试独立命名数据源、绑定 chinook Namespace，连接指定 Chinook 副本；不运行内置演示初始化。
5. 列出 11 张业务表，保存实际版本、连接与绑定记录。只验收环境与接入；第八章才建立语义模型并完成首次问数。

材料： 接入与建模 Skill、CLI 操作规则、Chinook 来源与许可。原范围导读保留为写作素材；本次实操正文见第六章初稿，证据见环境与复跑说明。

第 7 章 让 AI 探查 Chinook 并确认业务口径

给 AI 的任务：“探查客户、账单、明细与曲目关系，整理需要人工确认的日期、金额与统计口径。”

正文顺序与验收：

1. 沿用第 6 章数据源，深入检查 Customer、Invoice、InvoiceLine、Track、Genre，必要时小量只读采样。
2. 人确认账单与明细粒度、金额来源、账单日期、账单国家和客户地址的区别；不套用技术篇的分转元或有效状态。
3. 固定 2012 年练习期间，准备独立基线，记录头明细对账与十月、十一月比较的核对方法。
4. 交付表关系与口径清单；ETL 只覆盖必要的日期、空值、单位整理与数据时点，其余表以后按业务问题扩展。

材料： Runtime 数据源操作、CLI 探查规则、开放数据资料。

第 8 章 让 AI 生成语义模型并完成首次问数

给 AI 的任务：“建立账单分析，回答 2012 年账单金额最高的五个客户，验证后再增加明细分析。”

正文顺序与验收：

1. AI 根据已检查的 Schema 和口径编写 TM/QM，先建立账单分析，完成校验、Bundle 登记、刷新与 describe。
2. AI 从自然语言出发，按实际公开字段构造查询，先校验再执行，并对照独立基线回答客户排名。
3. 再增加明细分析，分清两个事实粒度；按内容分类分析使用明细金额，不重复累计账单头。
4. 交付模型、字段与首次问数记录，修正一个字段错误；语法、业务数值和可验证身份范围分别核对。

材料： TM 定义、QM 定义、模型生命周期、认证上下文。

第 9 章 让 AI 正确筛选数据：slice 与 having

1. 用 2012 年美国账单学习 slice 日期与国家筛选，先查询实际值，确认 USA、Canada。
2. 用美加两国、单张金额大于 10 学习 AND、in 和显式 OR 的范围。
3. 用客户全年累计金额大于 20 学习 having，实际对照先筛单张再汇总的差异。
4. 已执行 8 个查询用例，独立核对通过；第九章初稿待用户审阅。实操记录保留真实 CLI 响应与基线。

以下为旧安排素材，后续按功能章节规划调整章号和内容。

第 10 章 用题库校准模型与分析结果

给 AI 的任务：“整理题库，独立建立基线，分别检查固定查询和终端自然语言问答，定位错误并回归。”

正文顺序与验收：

1. 复用已有十二道 Chinook 练习，补空结果、未知字段、日期边界与有条件的身份范围对照。
2. 先用独立 SQL 或逐笔核对建立基线，再检查固定查询与终端 AI 自然语言问答。
3. 按表达、语义定义、数据、权限、执行和回答分类修正，必要时按能力使用查询解释，再回归受影响题目。
4. 同一题库分栏记录固定查询、终端问答和待第 12 章验证的浏览器问答；通过、失败、待澄清与未执行分开。

材料： 题库与调优流程、题库通过案例、结果解释案例、错误诊断草稿。

第 11 章 通过 Analytics Console 接入 FAP

给 AI 的任务：“把已验证的 Chinook 语义模型接入 Console 与 FAP，分别检查页面、绑定和查询回调。”

正文顺序与验收：

1. 沿用 Chinook 与已验证的语义模型，按 Launcher manifest 启用内置 Console，不另起前端开发环境。
2. 增加 FAP 教学 Workspace、AI 模型与 Provider、服务端授权和回调绑定；页面可访问与 FAP 可用分别确认。
3. 准备问数 Skill、Capability 和 Function 材料，经 FAP 宿主管理入口发布并核对修订，导出不等于发布。
4. 配置问数空间，在新会话完成模型发现与一条真实查询回调；记录环境、配置和回调证据。

材料： Console README、FAP 发布说明。

第 12 章 在浏览器里在线问数与连续追问

给 AI 的任务：“用同一题库在浏览器提问并连续追问，检查时间、口径、范围和依据。”

正文顺序与验收：

1. 用第 10 章的同一题库测试浏览器与 FAP，不拿终端 AI 的结果代替在线验收。
2. 从账单总额追问客户、国家、内容分类和时间，检查实际工具调用、语义模型选择与上下文。
3. 检验含糊问题、超范围请求、空结果和可验证身份下的数据范围差异；没有执行条件的案例记为待验。
4. 保存新会话和回调证据，形成可回答范围、常见问法和核对方法的一页用户指南。

材料： Console 会话与回调说明、题库通过与在线交付的区别。

第 13 章 交付一个完整分析项目并持续维护

给 AI 的任务：“将 Chinook 项目整理成可交接的练习包，检查重启恢复，并演示语义定义变更后的三层回归。”

正文顺序与验收：

1. 沿用 Chinook 贯穿案例，交付数据来源与许可、版本配置、语义模型、查询、题库、在线入口和复跑说明。
2. 重启后核对数据源绑定和语义模型恢复，复跑代表问题，不把临时会话成功当成可交接。
3. 用一次已确认的语义定义调整，分别回归固定查询、终端 AI 与浏览器问答。
4. 交付沿用同一 Chinook 案例；生产发布和高级分析另行组织。

材料： 直接使用 OLTP 发票明细的案例、模型生命周期、运维手册。

高级篇逐章方案

以高级篇专项大纲为案例和验收依据。WWI 使用 OLTP 业务数据，保留 Codex 与 PowerShell 的协作方式；SQL Server 等环境在实际进入本篇时单独核对。本轮只规划，不搭建。

第 14 章 从 WWI 扩展到异构数据

核心问题： 数据不是标准关系表时，怎样准备成可分析对象？

正文顺序：

1. 从 WWI 限定的销售、开票、客户与商品范围开始，重新确认订单与开票、税额、日期及头明细粒度；核对 SQL Server、驱动与 Runtime 支持，再比较关系表、Mongo 文档、目标文件和日志。
2. Mongo 讲类型、嵌套、数组、缺失与聚合；按实际 addon 和部署路径建立一个最小模型。
3. Excel/CSV 讲表头、单位、日期、重复键与版本，选定文件整理后导入分析表的练习路径。
4. 日志讲解析、事件标识、时间与去重，整理为事件明细再建模。
5. 用一张表说明原始来源、准备方式、执行适配器、可用 CLI 能力与刷新机制。

案例与产物： AI 为 WWI 整理一个教学目标文件和一份短事件日志，形成结构检查与模型验证记录；Mongo 可单列实验。数据库支持多种方言不等于存在 Excel/日志原生查询连接器；每条路径按实际支持讲解。

材料： TM 物理来源与扩展类型、Mongo 模板历史文章、当前扩展 SPI。早期 .ms 模板文章只作背景，不直接代替当前 Mongo TM/QM 操作教程。

第 15 章 多来源语义对齐与 Compose Memory Grid

建议替换原标题。核心问题： 两个结果可以直接放在一起比较吗，谁负责组合？

正文顺序：

1. 确认客户或商品键、月粒度、单位、刷新时间、目标版本与缺失处理。
2. 从两个已聚合的结果开始，解释 source Join 与结果 Join，以及跨模型与跨数据源的区别。
3. AI 描述两个模型，生成 Compose 计划，通过 CLI validate/preview/execute 核对。
4. 介绍 Memory Grid 的 bounded handle、资源限制、对齐合同与证据，按选定实现准备独立小例子。
5. 比较先导入统一存储、模型查询后组合和支持的结果集对齐，写明本例采用哪条路径。

案例与产物： WWI 月度开票实际与教学目标对照，含匹配率、缺失键和粒度检查。第一版文件目标可导入同一分析库；多种原始来源不因此被描述为已经实现任意跨库联邦查询。

材料： Compose 配置式手册、客户下降 Compose 案例、Memory Grid 参考。

第 16 章 CTE 与受治理的分阶段分析

建议微调标题。核心问题： 先汇总后计算再筛选，为什么需要明确阶段？

正文顺序：

1. 先给输入输出图：aggregate → derive → 可选 window_derive → postSlice → 排序截断。
2. 用 SQL CTE 解释分阶段思路，再讲 DSL_CTE 的结构化计划及其校验。
3. AI 按当前能力构造计划，逐阶段核对字段、alias、分组和输出。
4. 用差额、比率、累计贡献或已支持排名讲结果阶段公式，明确分母为零与排序并列的行为。
5. 演示一个缺失 alias 或不支持表达式的错误，再解释跨模型对齐为何需要前章的组合路径。

案例与产物： 首例用 WWI 单模型客户贡献或销售差额，保存阶段计划与复核表。两期客户下降文章中的 Compose 脚本可用来说明任务拆解，但不能改名后直接当作 DSL_CTE 样例。

材料： DSL_CTE 参考、受治理表达式参考、v2.0 白皮书第 4、5 节。

第 17 章 高级多维与层级分析

核心问题： 维度增多、层级变深以后，汇总与下钻如何仍然对得上？

正文顺序：

1. 从客户 × 月份 × 商品类目解释多维分析与固定业务粒度。
2. 分别讲嵌套维度路径、父子层级及闭包关系，用小型独立层级数据补足练习。
3. AI 生成 Pivot 请求，查看行列轴、指标矩阵、轴窗口和 contract 信息。
4. 验证小计、总计、父级占比与派生指标，说明比例通常不能直接累加。
5. 按已支持路径下钻，逐层检查明细回加；时间窗口与 Pivot 组合按所选 schema 分步处理。

案例与产物： WWI 客户、月份与商品分析的一份透视结果、一张层级关系图和下钻核对表。引擎支持的树轴范围与 Console 实际展示分别说明；不把完整交互式 BI 透视体验作为本章默认交付。

材料： Query DSL 的 Pivot 定义、父子维度教程、Pivot v2 参考、商品下钻对账案例。

第 18 章 语义 SQL 与虚拟业务表

核心问题： LLM 保留 SQL 写法时，语义层怎样继续落实同一套业务规则？

正文顺序：

1. 定义由语义模型提供的虚拟业务表，列出允许使用的维度和指标。
2. 用同一问题写一段语义 SQL，明确它查询的不是物理数据库表。
3. 解释解析 AST、绑定模型与字段、确定聚合语义、转换查询表达及编译的过程。
4. 明确支持的 SQL 范围、失败诊断与等价改写条件，不重复第 4 章的字段错误处理；结合分阶段与多维分析经验讨论入口取舍。

案例与产物： 语义 SQL 与对应 DSL 的教学对照，以及一段转换流程图。保持产品无关，不在正文引入厂商专用语法；复杂指标回扣第 3 章，并结合第 16、17 章的案例解释表达差异。

材料： v1.0 白皮书第 8.4 节、Cube Semantic SQL 官方解释。

第 19 章 SQL 与 DSL 怎样进入统一执行计划

建议替换原标题。核心问题： 输入语法不同，怎样复用同一套业务含义和执行规则？

正文顺序：

1. 对照一段语义 SQL、一份 Query DSL 和一个简化逻辑计划。
2. 将流程拆为输入解析、字段绑定、语义校验、规划、物理编译与执行。
3. 分清单次语义查询 DSL、分阶段分析 DSL、CLI/API 的请求外壳和内部 IR，不在此引入私有引擎术语。
4. 比较 SQL 输入的熟悉度与 DSL 的结构约束，讨论维护编译器和支持矩阵的成本。

案例与产物： 双入口汇入计划的示意图，外加同一金额口径的等价查询表。双入口属于通用架构讲解，不用具体产品的内部表示证明其已提供稳定语义 SQL 入口。

材料： v1.0 白皮书第 8.4 节、Compose 配置式手册开头的 IR 说明。

第 20 章 多源分析的性能与一致性

核心问题： 查询变慢或数字变旧时，怎样知道该优化哪一层？

正文顺序：

1. 固定一个问题与数据范围，测量源查询、组合、输出的时间和规模。
2. 优先缩小扫描范围、下推聚合并限制中间结果，再讨论缓存与预聚合。
3. 展示一种命中预聚合与一种不命中的查询，核对原始结果及刷新水位。
4. 比较各源快照、缓存 TTL、历史修改与目标版本，解释答案的时点。
5. 说明权限、Namespace 和模型变化时，缓存与结果身份必须随之区分。

案例与产物： 固定查询的性能和一致性对照表。预聚合是可选优化，不自动创建维护全部汇总数据。旧缓存教程的简化 key 不能作为多用户隔离方案；采用当前模型生命周期与 cache 实现规则。

材料： 预聚合能力参考、缓存教程、当前运行时与模型生命周期。

第 21 章 完成一个 WWI 多数据源高级案例

给 AI 的任务示例：“对照 WWI 开票销售事实与这份教学月度目标文件，计算客户目标达成；说明差额、来源时点与缺失匹配，提供分阶段查询和可核对的多维结果。”

正文顺序：

1. 明确销售与目标的业务定义、月粒度、匹配键和目标版本。
2. AI 完成文件准备与语义建模，先分别验证两个来源的汇总。
3. 选择实际支持的 Compose/结果对齐路径，核对匹配和差额，再引入受支持的分阶段计算。
4. 多维结果与前面的汇总复核；完成 CLI 验收后，再把已支持能力放进 FAP 在线案例。
5. 保存参数、步骤、模型、查询、验收基线和用户问法，结尾说明如何复用同类分析。

案例与产物： 一套 WWI 销售目标达成分析包，含数据准备、模型、查询计划、对账与在线问数记录。Mongo 或日志作为第二轮扩展，围绕明确问题加入；事实差异不能单独证明销售变化的真实原因。

拓展阅读： Experience Recipe 可以解释高频分析方案如何沉淀、发现与复用；首轮先保存可复现模板。当前 CLI 与 FAP 是否提供 Recipe 的完整使用入口另按实际能力确认，不预设一条不存在的发布命令。

材料： Memory Grid 目标达成合同、DSL_CTE 参考、Experience Recipe 参考、商品结构案例的事实与原因边界。

素材准备与写作顺序

技术篇与第六章按用户要求暂定；第七章按用户要求暂定，第八章已实测、自审，待用户审阅，第九章按当前稿进入后续写作；第十章经复审进入后续写作；第十一章基础时间分析已实测、自审待阅；第十二章以后尚未执行。第六章合并范围、Foggy 简介和环境接入，第七章探查，第八章建模与首次问数，开发工具固定为 Codex 桌面端与 PowerShell。第 18、19 章保留为高级专题草稿，在分阶段和多维案例验证后扩充。Console 与 FAP 的教程随实际接入结果写作。

技术篇按当前稿暂定，进入实操后先做第 6 至 10 章的运行样例，把实测结果回填应用教材。第 11、12 章接入跑通后完成在线教材，再组织第 13 章与高级篇。文章和视频共用同一份任务、模型与验收结果，避免形成两套口径。

本次审阅使用本地文档仓库提交 08bef58bbd4cef8e5d1b57bfa9753a5a4f06b44c 的相关白皮书、模型参考和实施手册，以及现有文章、CLI Skill 与 Console 发布说明。所列实践步骤是后续教程的写作与验收方案；当前已完成的是材料审阅，未将旧案例记录当作新环境的实测结果。