Add wiki content and .gitignore

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

looping_data/infer_gap_explicitization.md

@@ -0,0 +1,128 @@
+# 《Looping Data》「数据缺口显性化」核心论证推理链
+
+> 用「观点 → 事实 → 逻辑 → 结论」把《如何用 Loop Engineering 建设数据分析智能体》及《Looping Data 落地手记》中关于「数据缺口显性化」的论证骨架还原出来，并对照 GitHub 同类项目的做法，串成一条因果主线。
+>
+> 每条链的**结论**尽量作为下一条的**观点/前提**。
+
+## 串链意图
+
+主线叙事：数据分析智能体最难的不是回答问题，而是**诚实面对自己答不了什么**（链 0–1）→ 作者用「状态机守卫 + 显性标注 + 可信度链」三步把缺口显性化做进领域层（链 2–4）→ 治理约束必须有出口，否则死锁（链 5）→ GitHub 同类项目在五个维度上的对标与差距（链 6–8）→ 缺口显性化是当前开源社区最稀缺的设计模式（收束）。
+
+---
+
+## 链 0（总纲）：数据分析智能体最难的不是回答问题，而是诚实面对「答不了什么」
+
+- **观点:** 数据分析智能体最难的环节不是生成 SQL 或画图，而是当数据/语义/规则/权限不足时，系统能诚实暴露缺口而非假装能算。
+- **事实:**
+  - 作者明确判断：「数据缺口显性化」是最难的一环（第二篇 §四 标题）。
+  - 普通 ChatBI 的核心问题：「系统容易把'不确定'包装成确定结论」（第一篇 §二）。
+  - 三条设计原则中，「缺口显性化」与「任务驱动」「能力沉淀」并列，定义为「系统必须说明哪些问题能够可靠回答，哪些问题因为数据、语义、规则或权限不足不能可靠回答」（第一篇 §一）。
+- **逻辑:** **排除式**推理——如果系统只追求「答对当前问题」，它必然把不确定包装成确定（因为暴露缺口等于承认能力不足，会降低用户信任）；但企业场景中，一个被包装的错误结论比「暂缓执行」危害更大——它驱动错误的经营动作。因此，缺口显性化不是锦上添花，而是可信度的前提。
+- **结论:** 缺口显性化是数据分析智能体从「问数工具」升级为「组织级分析能力」必须攻克的核心难题。(→ 链 1)
+
+---
+
+## 链 1（问题诊断）：缺口之所以难「显性化」，是因为系统天然倾向于隐藏它
+
+- **观点:** 数据缺口之所以难以被显性化，根源在于系统的激励机制与产品设计都在鼓励「给出答案」而非「暴露缺口」。
+- **事实:**
+  - 普通 ChatBI 的五大问题中，第③条直指核心：「系统容易把'不确定'包装成确定结论」（第一篇 §二）。
+  - 指标口径、业务规则、权限边界「经常隐含在人的经验里」——系统没有结构化表达这些边界的机制（第一篇 §二）。
+  - 对话式产品形态加剧了这一问题：「对话适合发起和追问，不适合承载状态」——缺口有长生命周期（可能挂三天等补口径），对话时间线无法表达（第二篇 §一）。
+- **逻辑:** **因果**推理——因为系统以「回答率」为核心指标，暴露缺口等于降低指标；因为对话产品天然不支持长生命周期对象的状态追踪；因为语义/权限边界未被结构化建模——三重因素叠加，系统既无能力、也无动力、也无合适的产品形态来显性化缺口。
+- **结论:** 要让缺口显性化，必须同时解决三个问题：结构化建模缺口、在工作台中（而非对话中）表达缺口、用流程强制暴露缺口。(→ 链 2)
+
+---
+
+## 链 2（机制 · 状态机守卫）：用领域层纯函数强制缺口暴露，绕不过去
+
+- **观点:** 作者把缺口显性化的核心机制设计为状态机守卫——在领域层设置 6 条控制链路，每条都是不可绕过的纯函数，确保存在阻塞性缺口时无法推进到下一阶段。
+- **事实:**
+  - 6 条控制链路：阶段 3 没跑语义检查不能进阶段 4；存在阻塞性缺口不能进阶段 5；没执行分析不能进阶段 6；归因没经过专家评审不能进阶段 7；没生成报告不能进阶段 8；没完成资产沉淀不能完结（第二篇 §四）。
+  - 实现方式：「每个守卫都是领域层的纯函数，绕不过去」（第二篇 §四）。
+  - 协作阶段 3（语义检查）明确列出四类缺口：指标/规则/权限/可信度（第一篇 §四）。
+- **逻辑:** **排除式**推理——如果守卫不是纯函数（可被绕过或跳过），系统就会在「赶进度」的压力下偷偷跳过缺口检查；唯有把守卫做成领域层不可绕过的硬约束，才能确保「存在阻塞性缺口 → 无法推进」这一逻辑必然成立。这是用工程手段解决「激励机制倒逼隐藏缺口」的产品问题。
+- **结论:** 缺口显性化的技术核心是把「能否推进」的判断权交给领域层纯函数，而非依赖模型自觉或人工检查。(→ 链 3)
+
+---
+
+## 链 3（机制 · 显性标注）：被阻塞的 Case 不空着，而是明确告诉你卡在哪、等谁
+
+- **观点:** 状态机守卫解决了「能不能推进」的问题，但用户还需要知道「卡在哪、等谁」——作者的做法是在图表区显性标注「暂缓执行」并列出具体缺口和被分派的角色。
+- **事实:**
+  - 界面表达：「被缺口阻塞的 Case，图表区不是空着，而是显性地标注『暂缓执行』，旁边列出阻塞它的具体缺口和被分派的角色」（第二篇 §四）。
+  - 设计原则：「系统不假装能算，也不偷偷少算，它明确告诉你卡在哪、等谁」（第二篇 §四）。
+  - 协作矩阵中，阶段 3 识别缺口后，阶段 4 由智能体「分派缺口任务，更新 Case 状态」，不同角色（业务专家/数据团队/权限管理员）各有明确分工（第一篇 §四）。
+- **逻辑:** **因果**推理——因为缺口被显性标注，用户看到的不是「系统失败了」而是「系统在等待 X 补 Y」；因为标注包含具体缺口和角色，等待变成了可追踪的协作任务而非黑箱。这让「等待」从负面体验转化为可治理的工作流。
+- **结论:** 显性标注把「系统不能回答」从一种失败信号转化为一种可协作的工作状态。(→ 链 4)
+
+---
+
+## 链 4（机制 · 可信度链）：缺口显性化的副产品是把可信度从形容词变成可追溯的链
+
+- **观点:** 缺口显性化不仅解决了「答不了什么」的问题，还意外带来一个关键收益——让「可信度」从一个贴在结论上的形容词，变成一条可追溯的证据链。
+- **事实:**
+  - 效果描述：「可信度不再是一个贴在结论上的形容词，而是一条可以追溯的链——看到结论的人可以往回查，这个数字经过了语义检查、经过了专家确认、口径版本是哪一个」（第二篇 §四）。
+  - 阶段 6 专家确认环节：「标注可信度，记录修正来源」（第一篇 §四）。
+  - 阶段 8 沉淀：「保留审计记录」（第一篇 §四）。
+- **逻辑:** **因果**推理——因为每个阶段都有不可绕过的守卫，结论必须经过语义检查 → 缺口补齐 → 执行分析 → 专家确认 → 报告生成 → 资产沉淀的完整链路；每一步都留下可追溯的记录，可信度因此从「模型输出的信心指数」变成了「可验证的链式证据」。
+- **结论:** 缺口显性化让可信度从主观判断变成了工程产物——这是它超越「诚实」之外的架构价值。(→ 链 5)
+
+---
+
+## 链 5（设计教训）：每加一条治理约束，都要同时设计它的出口
+
+- **观点:** 作者在实现缺口显性化时踩到了一个死锁 bug，并提炼出一条关键设计规律：治理约束必须有出口，否则系统会卡在某个状态永远无法推进。
+- **事实:**
+  - 死锁案例：第一版中，带挂起归因的 Case 永远卡在阶段 6——涉及权限缺口的归因行在审批通过前挂起，不能被专家评审，也不进报告；但审批可能永远不来（第二篇 §五）。
+  - 设计规律：「每加一条治理约束，都要同时设计它的出口」（第二篇 §五）。
+  - 解决方案：「挂起的归因现在的语义是：Case 可以带着未决问题继续走，未决本身被如实记录」（第二篇 §五）。
+  - 同类设计：权限审批必须指定审批人和脱敏方案，全程审计留痕——「出了问题要能回答『当时是谁、依据什么放行的』」（第二篇 §五）。
+- **逻辑:** **排除式**推理——如果治理约束没有出口，系统就会在「等待审批/等待补缺口/等待专家评审」等节点死锁；因为现实中审批可能被拒绝、缺口可能长期补不上、专家可能应接不暇——所以「一直等不到怎么办」是产品必须回答的问题，不能靠流程图上的「等待审批」一笔带过。
+- **结论:** 缺口显性化不是把路堵死，而是让系统在「带着未决问题继续走」和「如实记录未决」之间找到平衡。(→ 链 6)
+
+---
+
+## 链 6（GitHub 对照 · 缺口显性化）：开源社区中最稀缺的模式——仅两个项目部分涉及
+
+- **观点:** 在 GitHub 近半年的多 Agent 数据分析项目中，「缺口显性化」是最稀缺的设计模式——仅两个项目以不同形式部分涉及，但均未达到 Looping Data 的系统化程度。
+- **事实:**
+  - **rakeshchada/portfolio-autopsy**——用「knowability classification」把每条建议标记为 KNOWABLE / HINDSIGHT / MIXED，显性区分「能从数据中知道的」和「需要事后才知道的」。这是最接近「缺口显性化」的开源实现，但仅作用于结论层面，未贯穿整个分析流程。
+  - **databufflabs/databuff**（343 stars）——在 AIOps 巡检中显性暴露「假正常」状态（如 HTTP 200 隐藏 InsufficientStockException），本质是「数据质量缺口显性化」，但面向基础设施而非业务分析。
+  - **zhongyu09/openchatbi**（604 stars）——Agent 在信息不完整时主动询问用户补充上下文，属于最基本的「缺口暴露」，但无结构化状态机支撑。
+  - 其余项目（Varn1t/EDAgent、ASHHADgit87/AnalyticoGPT 等）均为单通问答或多 Agent 流水线，无显性化缺口机制。
+- **逻辑:** **对照**推理——将 Looping Data 的「状态机守卫 + 显性标注 + 可信度链」与 GitHub 最佳实现对比：portfolio-autopsy 只在结论层做标记，databuff 只在数据质量层做暴露，openchatbi 只做一次性询问。三者均未把缺口显性化做成贯穿全流程的领域层机制。
+- **结论:** 缺口显性化在开源社区中尚属空白——没有项目把它做成状态机守卫 + 全流程显性标注的系统化方案。(→ 链 7)
+
+---
+
+## 链 7（GitHub 对照 · 双循环与能力沉淀）：有记忆机制但无结构化资产复用
+
+- **观点:** GitHub 上多个项目实现了某种形式的「能力沉淀」，但沉淀的内容和方式与 Looping Data 的「结构化资产跨 Case 复用」有本质区别。
+- **事实:**
+  - **claudomat-dev/claudomat-mini**（93 stars）——双文档记忆（Instructions + Observations），Stage 9 复盘将 Observations 提升为 Instructions，跨项目复用。最接近「能力沉淀」，但沉淀的是编码指令而非分析资产。
+  - **portfolio-autopsy**——情景记忆积累历史教训，Agent 胜率从 31% 提升至 59%。沉淀的是策略经验，非结构化资产。
+  - **cyqlelabs/mcp-dual-cycle-reasoner**（9 stars）——case-base 存储 problem/solution/outcome 三元组，语义相似度检索。最接近「案例资产复用」，但面向通用 Agent 而非数据分析。
+  - **datagallery-lab/datafoundry**（307 stars）——「可复用输出和工作区资产」，支持跨会话复用文件。有资产沉淀但无结构化分类。
+  - Looping Data 的资产分类：指标资产、规则资产、模板资产、Skill 资产、案例资产（第一篇 §五），每类有明确示例和复用机制（⟲ 复用 ×N 角标）。
+- **逻辑:** **对照**推理——GitHub 项目的「沉淀」多为通用记忆（指令、策略、案例），而 Looping Data 的「沉淀」是领域结构化的（指标/规则/模板/Skill/案例），且通过「资产带」实现跨 Case 的显性复用。前者是「记住发生了什么」，后者是「沉淀了什么能力、能复用于什么场景」。
+- **结论:** 能力沉淀在开源社区已有多种实现，但「领域结构化 + 跨 Case 显性复用 + 复用计数治理」的组合设计尚未出现。(→ 链 8)
+
+---
+
+## 链 8（GitHub 对照 · 阶段治理与人类在环）：有阶段门控但无分析领域特化
+
+- **观点:** GitHub 上存在多个带阶段门控和人类在环审核的项目，但它们面向的是编码或通用工作流，而非数据分析领域特有的语义检查、归因确认、口径审计。
+- **事实:**
+  - **claudomat-mini**——17 阶段 wave loop + 双评审员门控（Karen 验证 source-claim，Jenny 验证 spec-semantic）。门控最详细，但面向功能开发。
+  - **RedLynx101/Promethean**——四 Agent 流水线（分解→系统选择→编排→治理），每个阶段转换都是人类在环审批门控。有 L0-L5 自主度分级。
+  - **databufflabs/databuff**——7 阶段 AIOps 路线图（See → Collaborate → Inspect → Diagnose → Fix → Predict → Answer），多 Agent 分发。
+  - Looping Data 的 8 阶段：任务发起 → 分析规划 → 语义检查 → 补齐缺口 → 执行分析 → 专家确认 → 管理审阅 → 动作与沉淀（第一篇 §四）。每阶段有明确的角色分工和领域特化检查。
+- **逻辑:** **对照**推理——阶段门控不是新模式，但门控的「内容」决定了价值：claudomat-mini 验证代码正确性，Looping Data 验证语义完整性、归因可信度、口径一致性——后者是数据分析领域特有的治理需求，现有开源项目未覆盖。
+- **结论:** 阶段门控和人类在环在开源社区已有成熟实现，但「数据分析领域特化的语义检查 + 归因确认 + 口径审计」这一组合尚未被任何开源项目系统化实现。(→ 收束)
+
+---
+
+## 收束（回到链 0）
+
+> 数据分析智能体最难的不是回答问题（**链 0**）→ 而是诚实面对「答不了什么」，这需要结构化建模缺口、在工作台中表达缺口、用流程强制暴露缺口（**链 1**）→ 作者用状态机守卫（领域层纯函数）确保缺口无法被绕过（**链 2**）→ 用显性标注把「等待」转化为可协作的工作状态（**链 3**）→ 副产品是把可信度从形容词变成可追溯的证据链（**链 4**）→ 但治理约束必须有出口，否则系统死锁（**链 5**）→ GitHub 上缺口显性化是最稀缺的模式，仅两个项目部分涉及且未系统化（**链 6**）→ 能力沉淀有实现但无领域结构化资产复用（**链 7**）→ 阶段门控有实现但无分析领域特化的语义/归因/口径检查（**链 8**）→ 最终回到链 0：**缺口显性化是数据分析智能体从「问数工具」升级为「组织级分析能力」的核心难题，而 Looping Data 的方案（状态机守卫 + 显性标注 + 可信度链 + 治理出口）在开源社区中尚未出现直接对标实现。**

looping_data/looping_data.md

@@ -0,0 +1,250 @@
+# Looping Data 文章合集
+
+> 来源：子凡AI（微信公众号），作者：子凡
+>
+> - 原文1：https://mp.weixin.qq.com/s/SWCjMsUW98H0_Xdkg1vFGg
+> - 原文2：https://mp.weixin.qq.com/s/gtH8FQv_0DVJH2rE6v5abw
+
+---
+
+# 第一篇：如何用 Loop Engineering 建设数据分析智能体
+
+## 零、产品目标
+
+> 从一次性问答，演进为可复用、可治理、可沉淀的组织级分析能力。
+
+## 一、Loop Engineering 是什么
+
+Loop Engineering 不是一个单纯的技术架构，而是一种围绕真实任务持续建设系统能力的产品与工程方法。它关注的不是一次回答是否漂亮，而是系统能否在每一次任务中完成：
+
+```
+执行 → 反馈 → 修正 → 沉淀 → 复用
+```
+
+对数据分析智能体来说，loop 的对象不是单条聊天消息，而是一个完整的 Analysis Case，包括业务问题、分析路径、语义缺口、数据和权限边界、人工确认、经营动作、可沉淀资产。
+
+![Loop Engineering 核心循环](screenshot1.png)
+
+### 1. 核心定义
+
+Loop Engineering 是一种让系统在真实业务任务中持续进化的方法。它不是先建设一个大而全的系统，再等待用户使用；而是从一个具体任务开始，边分析、边发现缺口、边补齐能力、边沉淀资产。因此，系统每完成一次任务，都应该回答三个问题：
+
+- 这次任务解决了什么问题？
+- 这次任务暴露了什么缺口？
+- 这次任务沉淀了什么能力？
+
+### 2. 一句话理解
+
+普通智能体是：
+
+> 用户问一次，系统答一次。
+
+基于 Loop Engineering 的智能体是：
+
+> 用户问一次，系统不仅回答，还发现自己缺什么、补什么、沉淀什么。
+
+它的目标不是替代分析师，而是把组织里的分析经验、指标口径、业务规则、判断过程和行动机制持续工程化。
+
+### 3. 三条设计原则
+
+#### 任务驱动
+
+从真实业务问题出发，而不是先做大而全的数据治理或语义建模。
+
+#### 缺口显性化
+
+系统必须说明哪些问题能够可靠回答，哪些问题因为数据、语义、规则或权限不足不能可靠回答。
+
+#### 能力沉淀
+
+每次分析结束后，都应沉淀指标、规则、模板、Skill、案例和行动复盘。
+
+## 二、为什么用 Loop 理念解决数据分析智能体问题
+
+数据分析智能体真正难的不是生成 SQL 或画图，而是如何在企业复杂语义、权限边界和业务判断中持续可靠地工作。
+
+### 1. 普通 ChatBI / 数据问答的问题
+
+普通 ChatBI 往往解决的是"能不能回答当前问题"。但在企业场景中，真正影响可信度的是这些问题：
+
+1. 只回答当前问题，分析经验无法沉淀；
+2. 指标口径、业务规则、权限边界经常隐含在人的经验里；
+3. 系统容易把"不确定"包装成确定结论；
+4. 数据分析结果和经营动作脱节；
+5. 每次复杂分析都像一次重新开始的项目。
+
+这些问题会导致数据分析智能体停留在"问数工具"层面，很难成为组织级分析能力。
+
+### 2. Loop Engineering 的解决方式
+
+Loop Engineering 不是让智能体一次性变得无所不能，而是让它在真实任务中持续进化。具体来说，它通过以下方式解决问题：
+
+1. 先检查语义、数据、规则、权限和可信度，再执行分析；
+2. 把缺口分派给业务专家、数据团队、语义管理员和权限管理员；
+3. 让专家确认关键归因，让管理者把建议转成行动；
+4. 把结果沉淀为下一次可复用的指标、规则、模板和 Skill。
+
+### 3. 关键变化
+
+#### 从问答到能力建设
+
+分析结果不是终点，系统能力提升才是闭环终点。
+
+#### 从黑箱到可治理
+
+每个结论都要能看到数据来源、统计口径、权限范围和确认记录。
+
+#### 从个人经验到组织资产
+
+专家修正、业务规则和行动复盘被结构化保存，形成组织级分析能力。
+
+## 三、Loop Engineering 总流程
+
+Loop Engineering 在数据分析智能体中的完整过程，可以拆成两条相互嵌套的线：这两条线不是分开的，而是在同一个 Analysis Case 中循环发生。
+
+### 1. 业务分析流
+
+![业务分析流](screenshot2.png)
+
+### 2. 能力建设流
+
+![能力建设流](screenshot2.png)
+
+## 四、角色如何在 Workspace 中协作
+
+每个分析任务都是一个 Analysis Case。智能体负责拆解和编排，不同角色围绕缺口、结论和资产进行协作。协作过程不是围绕聊天消息展开，而是围绕三个对象展开：
+
+| 阶段 | 业务提问者 | 数据分析智能体 | 数据分析师 | 业务专家 | 数据/语义团队 | 权限管理员 | 管理者 |
+|------|-----------|--------------|-----------|---------|-------------|-----------|-------|
+| 1. 任务发起 | 创建 Analysis Case，填写对象/时间/问题 | 解析业务问题，生成任务理解卡 | 补充初始背景 | | | | |
+| 2. 分析规划 | 确认或修改任务理解 | 生成分析路径，拆解指标与归因链路 | 审查分析路径，调整图表表达 | | | | |
+| 3. 语义检查 | | 检查语义缺口：指标/规则/权限/可信度；判断是否阻塞分析 | | 识别业务规则缺失 | 识别数据和口径缺失 | 识别权限不足 | |
+| 4. 补齐缺口 | | 分派缺口任务，更新 Case 状态；调整分析范围 | | 提供补充材料 | 补充业务解释，提交候选规则 | 接入字段/审核口径，处理数据质量 | 授权/脱敏/审计 | |
+| 5. 执行分析 | 查看初步结果 | 调用数据与工具，生成图表/归因/建议 | 复核分析逻辑 | 确认数据可用性 | | | |
+| 6. 专家确认 | 确认是否满足问题 | 标注可信度，记录修正来源 | 确认图表和表达 | 确认/修正/驳回归因，沉淀候选规则 | 审核候选规则 | | |
+| 7. 管理审阅 | 选择生成报告 | 生成报告草稿，形成建议动作 | 润色分析材料 | | | | 确认建议可行性，审阅摘要判断优先级 |
+| 8. 动作与沉淀 | 查看最终输出 | 沉淀候选资产，更新 Skill/案例库 | 保存分析模板 | 确认规则复用范围 | 发布正式语义规则 | 保留审计记录 | 转为行动项，分派负责人 |
+
+图例：蓝色底表示智能体编排；橙色底表示语义缺口；绿色底表示确认、规则发布、资产沉淀或行动形成；红色底表示权限、脱敏与审计。
+
+## 五、最终沉淀的资产
+
+Loop 的价值在于，每次分析结束后，系统不仅留下报告，还留下下一次可复用的能力。
+
+| 资产类型 | 示例 |
+|---------|------|
+| **指标资产** | 吞吐量、单吨利润、预算完成率、租库成本率、客户贡献度 |
+| **规则资产** | 异常阈值、业务归因规则、口径切换规则、可信校验规则 |
+| **模板资产** | 经营分析模板、利润归因模板、客户结构分析模板、会议材料模板 |
+| **Skill 资产** | 利润归因 Skill、量价分析 Skill、预算偏差分析 Skill |
+| **案例资产** | 专家修正记录、典型经营问题、行动项复盘、历史分析 Case |
+
+目标：每一次分析，都让下一次分析更可靠、更快、更可治理。
+
+## 六、产品设计总结
+
+基于 Loop Engineering 的数据分析智能体，不应被设计成"问一句答一句"的 ChatBI。它应被设计成一个企业级分析工作台。这个工作台围绕 Analysis Case 组织多角色协作：
+
+- 围绕 Semantic Gap 驱动语义建设。
+- 围绕 Human Review 沉淀专家判断。
+- 围绕 Action Item 推动经营动作。
+- 围绕 Analysis Asset 持续复用能力。
+
+最终目标是：
+
+> 每一次分析，都让下一次分析更可靠、更快、更可治理。
+
+---
+---
+
+# 第二篇：（二）Looping Data 落地手记：数据分析智能体的产品设计
+
+## 前言
+
+上一篇《如何用 Loop Engineering 建设数据分析智能体》讲的是方法论：数据分析智能体不该是一句一答的 ChatBI，而应该围绕 Analysis Case 组织多角色协作，每次分析都沉淀能力。之后，我开始用 Fable 5 对其进行设计与实现。目前从一个单文件 HTML 原型到跑通工作台整个闭环：建 Case、语义检查、补缺口、分析、专家确认、报告、行动项、资产沉淀，再到下一个 Case 复用上一个 Case 沉淀的东西。因此，这一篇主要想先从产品设计上讲清楚几件事。
+
+![Looping Data 产品截图](screenshot1.png)
+
+## 一、不做对话框
+
+动手前我做了三个原型方案：
+
+1. **方案 A：三栏 Case 工作台**。左栏 Case 列表，中栏 Case 详情，右栏协作对象。
+2. **方案 B：Loop 流水线看板**。八个阶段横向排开，Case 像卡片一样在泳道里流动。
+3. **方案 C：对话即编排**。左边聊天，右边实时生成分析画布，最接近现在主流 AI 产品的形态。
+
+C 是最先被淘汰的，原因是**对话是好的入口，但却是个很差的工作台**。一个 Analysis Case 里有理解卡、缺口清单、图表、归因链、确认记录、行动项，这些对象的生命周期长短不一。缺口可能挂三天等数据团队补口径，行动项可能在 Case 完结后才被管理者认领。如果把它们都塞进一条对话时间线，第三天你就找不到第一天的东西了。对话适合发起和追问，不适合承载状态。
+
+B 虽然清晰把 Loop 的「阶段流转」过程展现了出来，但用户真正关心的是「这个问题分析得怎么样了」，而不是「卡片现在在第几列」。阶段是骨架，不是内容。
+
+最后定的方案是 **A 的三栏结构**，加上 B 里我唯一舍不得的东西：一条横贯底部的资产带。
+
+## 二、两条 Looping 主线
+
+Looping Data 有两条相互嵌套的线：**业务分析流**（这次问题怎么解决）和**能力建设流**（系统这次沉淀了什么）。这个嵌套关系，体现在产品上是：
+
+- **主体三栏**承载业务分析流，右栏放的是协作中的三类对象：缺口、确认、行动项。
+- **底部横向带**承载能力建设流，独占资产这一类对象。
+
+资产带放底部这个决定我有些犹豫，它吃掉了约 110 像素的高度，而且大部分时间用户的注意力不在那里。但我最后留下它，有两个理由：
+
+1. **资产的积累是横跨阶段的**。阶段 4 补缺口时产生候选规则，阶段 8 才正式发布，横向的进度条天然表达了这种时间上的累积，右栏的竖列表做不到。
+2. **常设可见**。中栏怎么滚动，资产带都在。这在反复使用后会形成一种产品心智：每次分析都在沉淀东西。这个心智恰好就是 Looping Data 产品想传达的核心主张。
+
+同时，空间代价用一个收起开关兜底。小屏幕上收起来，不影响主流程。
+
+![Looping Data 产品截图](screenshot2.png)
+
+## 三、Looping 如何闭环
+
+做完第一版原型，我发现一个问题：界面上画出来的其实是一条直线。发起、分析、确认、沉淀，从左到右从上到下，走完就结束了。Looping 在哪？
+
+因此我继续补了四个功能：
+
+1. **资产带切成两段**。左段是「⟲ 复用 · 来自历史 Case」，右段是「◆ 沉淀 · 供未来 Case 复用」。资产从案例 N 的输出段流进案例 N+1 的输入。
+2. **完结的 Case 顶部放一张「Loop 三问复盘卡」**，回答上一篇提出的三个问题：这次解决了什么、暴露了什么缺口、沉淀了什么能力。还有一行量化的循环收益，比如这次分析比上次同类分析快了多少、可信度起点高了多少。
+3. **凡是引用了已沉淀资产的地方，打一个绿色的小标**：⟲ 沉淀来自 XX Skill，都带上出处。
+4. **资产库里已发布的资产带「⟲ 复用 ×N」的角标**。资产被用过几次，是它价值的直接证据，也是治理时判断该不该继续维护它的依据。
+
+BTW：谁能告诉我 AI 设计的数据样例为什么永远是华东区
+
+这四项加上之后，产品才算完整了。
+
+## 四、数据缺口显性化
+
+「数据缺口显性化」是最难的一环。我的做法是把它做进状态机。领域层有一条控制链路：
+
+- 阶段 3 没跑语义检查不能进阶段 4
+- 存在阻塞性缺口不能进阶段 5
+- 没执行分析不能进阶段 6
+- 归因没经过专家评审不能进阶段 7
+- 没生成报告不能进阶段 8
+- 没完成资产沉淀不能完结
+
+每个守卫都是领域层的纯函数，绕不过去。界面上对应的表达是：被缺口阻塞的 Case，图表区不是空着，而是显性地标注「暂缓执行」，旁边列出阻塞它的具体缺口和被分派的角色。系统不假装能算，也不偷偷少算，它明确告诉你卡在哪、等谁。
+
+这样做有个额外的好处：**可信度不再是一个贴在结论上的形容词，而是一条可以追溯的链**。看到结论的人可以往回查，这个数字经过了语义检查、经过了专家确认、口径版本是哪一个。
+
+## 五、治理要留出口
+
+做权限审批时，我加了「挂起归因」：涉及权限缺口的归因行，在审批通过前挂起，不能被专家评审，也不进报告。逻辑上很正确，权限没批的数据当然不该出现在结论里。
+
+但第一版实现里，一个带挂起归因的 Case 会永远卡在阶段 6：不能评审，也不能推进，死锁。
+
+我的教训不在这个 bug 本身，而在它揭示的设计规律：**每加一条治理约束，都要同时设计它的出口**。审批可能被拒绝，缺口可能长期补不上，专家可能应接不暇。流程图上画「等待审批」很容易，但产品必须回答「一直等不到怎么办」。
+
+挂起的归因现在有明确的语义：Case 可以带着未决问题继续走，未决本身被如实记录。同样的思路也用在权限审批上：审批必须指定审批人和脱敏方案，全程审计留痕。不是因为流程爱好，而是因为分析结论会驱动经营动作，出了问题要能回答「当时是谁、依据什么放行的」。
+
+## 六、智能是不是地基
+
+最后说一个架构层面的设计决定，它对产品设计的影响比看起来大。
+
+Looping Data 里所有需要「智能」的地方，一共**六处**：任务理解、语义检查、分析引擎、报告组装、资产沉淀、复用匹配。这个结构也让「智能做得好不好」变成一个可以独立度量的问题：如果系统是模型判断和业务逻辑绞在一起，一次分析结果你是没法知道是模型判断错了，还是数据来源或业务分析错了。
+
+这样，我下一步的计划是：搭一个智能体集群，六个角色智能体扮演提问者、分析师、专家、语义团队、权限管理员和管理者，然后用公开的分析类 Benchmark 测试：例如，InfiAgent-DABench 的 257 道数据分析题，加上横跨 18 个行业领域的 LongTableBench，逐题驱动整个生命周期。
+
+## 七、最后
+
+上一篇的结尾写过 Looping Data 的目标：每一次分析，都让下一次分析更可靠、更快、更可治理。
+
+那产品设计就是几条可以逐步迭代优化的曲线：准确率、可信度起点、资产复用率等等。最终结果出来是什么样呢？请让我留给下一篇文章。

looping_data/looping_data_reasoning_chain.md

@@ -0,0 +1,121 @@
+# 《Looping Data》核心论证推理链
+
+> 用「观点 → 事实 → 逻辑 → 结论」把《如何用 Loop Engineering 建设数据分析智能体》及《Looping Data 落地手记》的核心内容串成一条因果主线。
+> 每条链的**结论**尽量作为下一条的**观点/前提**。
+
+## 串链意图
+
+主线叙事：数据分析智能体的真正难题不在技术问答，而在企业复杂环境中的**持续可信**（链 0–1）→ Loop Engineering 用"缺口显性化 + 能力沉淀"替代一次性回答（链 2–3）→ 产品必须用 Analysis Case 承载多角色协作而非对话框（链 4–5）→ 闭环要靠资产跨 Case 流动来实现（链 6–7）→ 智能应解耦为六个可独立度量的模块（链 8）→ 最终目标是组织级分析能力的持续进化（收束）。
+
+---
+
+## 链 0（总纲）：数据分析智能体需要从"一次性问答"进化为"持续进化的组织能力"
+
+- **观点:** 数据分析智能体的核心价值不是单次回答是否漂亮，而是能否在每次任务中持续暴露缺口、补齐能力、沉淀资产，让组织级分析能力不断进化。
+- **事实:**
+  - 产品目标定义："从一次性问答，演进为可复用、可治理、可沉淀的组织级分析能力"（第一篇 §零）。
+  - Loop Engineering 的完整循环：执行 → 反馈 → 修正 → 沉淀 → 复用（第一篇 §一）。
+  - 最终目标陈述："每一次分析，都让下一次分析更可靠、更快、更可治理"（第一篇 §六 / 第二篇 §七）。
+- **逻辑:** **排除式**推理——智能体的价值若仅停留在"答对当前问题"，它就无法积累经验、无法跨 Case 复用、无法形成组织记忆；这恰恰是企业从"问数工具"升级为"分析能力"所不可能绕过的路径。
+- **结论:** 因此，构建数据分析智能体的正确范式不是让模型一次性变强，而是设计一个让系统在每次任务中自我进化的机制。(→ 链 1)
+
+---
+
+## 链 1（问题诊断）：普通 ChatBI 的根本缺陷是把"回答当前问题"当成终点
+
+- **观点:** 普通 ChatBI / 数据问答系统之所以无法成为组织级分析能力，根源在于它们把"回答当前问题"当成终点，而非把"发现并补齐能力缺口"当成闭环。
+- **事实:**
+  - 五大问题清单：① 只回答当前问题，分析经验无法沉淀；② 指标口径、业务规则、权限边界隐含在人的经验里；③ 系统容易把"不确定"包装成确定结论；④ 分析结果和经营动作脱节；⑤ 每次复杂分析都像重新开始的项目（第一篇 §二）。
+  - 结果定位："这些问题会导致数据分析智能体停留在'问数工具'层面，很难成为组织级分析能力"（第一篇 §二）。
+- **逻辑:** **因果**推理——因为系统只处理单点问答，它既没有机制让本次发现被下次复用（问题①），也没有机制暴露自身的语义/数据/权限不足（问题②③），更没有把分析结果连接到经营行为（问题④），所以每次任务都无法让系统本身变强，只能重复劳动。
+- **结论:** 真正影响企业可信度的不是"能不能回答当前问题"，而是系统能否"在回答的同时暴露并补齐自身缺口"。(→ 链 2)
+
+---
+
+## 链 2（方案提出）：Loop Engineering 的核心机制是"缺口显性化 + 能力沉淀"双循环
+
+- **观点:** Loop Engineering 让数据分析智能体从"一次性回答"进化的关键机制，是把"缺口显性化"和"能力沉淀"确立为每次任务的必答项。
+- **事实:**
+  - 三个必答问题：这次任务解决了什么问题？暴露了什么缺口？沉淀了什么能力？（第一篇 §一）
+  - 三条设计原则：任务驱动（不从大而全出发）、缺口显性化（必须说明哪些因数据/语义/规则/权限不足不能答）、能力沉淀（每次分析后沉淀指标/规则/模板/Skill/案例）（第一篇 §一）。
+  - 普通智能体与 Loop Engineering 智能体的对照：前者"用户问一次，系统答一次"；后者"用户问一次，系统不仅回答，还发现自己缺什么、补什么、沉淀什么"（第一篇 §一）。
+- **逻辑:** **对照**推理——将 Loop Engineering 与传统问答式智能体并置，前者把"发现缺口并沉淀能力"显式嵌入循环，而后者完全缺失这一环；正是这一差异决定了系统能否跨任务进化。
+- **结论:** Loop Engineering 的核心不是技术架构，而是一种让系统**在真实任务中持续发现并补齐自身缺口**的产品-工程方法。(→ 链 3)
+
+---
+
+## 链 3（机制展开）：双循环嵌套——业务分析流与能力建设流在同一 Analysis Case 中循环
+
+- **观点:** Loop Engineering 的闭环由两条相互嵌套的流实现：业务分析流（这次问题怎么解决）和能力建设流（系统这次沉淀了什么），二者围绕同一个 Analysis Case 循环发生。
+- **事实:**
+  - 两条线的定义：业务分析流 + 能力建设流，"不是分开的，而是在同一个 Analysis Case 中循环发生"（第一篇 §三）。
+  - 八个协作阶段：任务发起 → 分析规划 → 语义检查 → 补齐缺口 → 执行分析 → 专家确认 → 管理审阅 → 动作与沉淀（第一篇 §四）。
+  - 关键变化定义："分析结果不是终点，系统能力提升才是闭环终点"（第一篇 §三）。
+  - 关键变化：从问答到能力建设、从黑箱到可治理、从个人经验到组织资产（第一篇 §三）。
+- **逻辑:** **因果**推理——因为每条线回答不同的问题（本次解题 vs 能力进化），将它们嵌套在同一 Case 中，使得"解题"的过程必然触发"发现缺口 → 补齐 → 沉淀"的能力建设链；两条线互为因果——解题越深，暴露的缺口越多，沉淀的能力越丰富，反过来又使下一次解题更可靠。
+- **结论:** 闭环的实现依赖于把"解题"和"能力建设"紧耦合进同一个工作对象（Analysis Case），而非分开的两个系统。(→ 链 4)
+
+---
+
+## 链 4（产品形态）：Analysis Case 必须承载多角色协作，对话不是合适的工作台
+
+- **观点:** Analysis Case 包含理解卡、缺口清单、图表、归因链、确认记录、行动项等多种长生命周期对象，对话时间线无法承载这些对象的协作需求，必须用工作台而非对话框来组织。
+- **事实:**
+  - 三个原型淘汰实验：方案 C（对话即编排）最先被淘汰，原因是"对话是好的入口，但却是个很差的工作台"；方案 B（看板）清晰但用户关心的是"分析得怎么样"而非"在第几列"；最终选定方案 A（三栏工作台）+ 底部资产带（第二篇 §一）。
+  - 对话不适用的具体原因："缺口可能挂三天等数据团队补口径，行动项可能在 Case 完结后才被管理者认领。如果把它们都塞进一条对话时间线，第三天你就找不到第一天的东西了"（第二篇 §一）。
+- **逻辑:** **排除式**推理——对话只能承载线性的即时消息流，而 Analysis Case 中的对象具有异构生命周期（有的几小时，有的跨天甚至跨 Case 完结后），对话无法同时表达这些时间尺度；因此对话只能作为入口和追问手段，不能作为工作台的承载结构。
+- **结论:** 数据分析智能体的产品形态必须是围绕 Analysis Case 的**多角色协作工作台**，而非围绕聊天消息的对话框。(→ 链 5)
+
+---
+
+## 链 5（协作机制）：可信度不再是一个形容词，而是一条可追溯的链
+
+- **观点:** Loop Engineering 的可信度保障不是靠模型自信地"包装确定结论"，而是靠语义检查、专家确认、权限审计形成一条可追溯的链路。
+- **事实:**
+  - 缺口状态机：阶段 3 没跑语义检查不能进阶段 4；存在阻塞性缺口不能进阶段 5；没执行分析不能进阶段 6；归因没经过专家评审不能进阶段 7；没生成报告不能进阶段 8；没完成资产沉淀不能完结（第二篇 §四）。
+  - 守卫实现："每个守卫都是领域层的纯函数，绕不过去"（第二篇 §四）。
+  - 可信度效果："看到结论的人可以往回查，这个数字经过了语义检查、经过了专家确认、口径版本是哪一个"（第二篇 §四）。
+- **逻辑:** **因果**推理——因为每个阶段都有不可绕过的守卫（纯函数），结论必须经过语义检查 → 专家确认 → 报告生成 → 资产沉淀的链路才成立；这使得可信度由"模型输出的形容词"变成了"可验证的链式证据"。
+- **结论:** 治理的可信度来自流程的强制可追溯性，而非模型输出的信心指数。(→ 链 6)
+
+---
+
+## 链 6（闭环实现）：Looping 的闭环靠资产在案例 N 与案例 N+1 之间跨 Case 流动来实现
+
+- **观点:** 第一版原型之所以"界面上画出来的其实是一条直线"，是因为只有单 Case 内的线性流程，没有跨 Case 的资产流动；真正的 Looping 闭环需要让案例 N 沉淀的资产成为案例 N+1 的输入。
+- **事实:**
+  - 第一版问题："发起、分析、确认、沉淀，从左到右从上到下，走完就结束了。Looping 在哪？"（第二篇 §三）
+  - 四个补丁功能：① 资产带切成两段（"⟲ 复用 · 来自历史 Case" 和 "◆ 沉淀 · 供未来 Case 复用"）；② 完结 Case 顶部的"Loop 三问复盘卡"；③ 引用已沉淀资产处打绿色小标（⟲ 沉淀来自 XX Skill）；④ 已发布资产带"⟲ 复用 ×N"角标（第二篇 §三）。
+  - 核心机制："资产从案例 N 的输出段流进案例 N+1 的输入"（第二篇 §三）。
+- **逻辑:** **因果**推理——因为没有跨 Case 的资产流转，第一版只是直线流程；加入复用段/沉淀段、复盘卡、出处标注、复用计数四个功能后，案例 N 的输出成了案例 N+1 的输入，系统每次分析都在为下次积累能力，Looping 才真正实现。
+- **结论:** 闭环的本质不是单 Case 内的阶段流转，而是**资产在案例序列中的跨 Case 复用与增值**。(→ 链 7)
+
+---
+
+## 链 7（产品心智）：设计要传达"每次分析都在沉淀东西"的核心主张
+
+- **观点:** 底部资产带的设计决策不仅解决功能问题，更要建立一种产品心智——让用户直观感受到"每次分析都在沉淀东西"。
+- **事实:**
+  - 设计犹豫：资产带吃掉约 110 像素高度，且大部分时间用户注意力不在那里（第二篇 §二）。
+  - 保留的两个理由：① 资产的积累横跨阶段（阶段 4 产生候选规则，阶段 8 才正式发布，横向进度条天然表达时间累积）；② 常设可见，中栏怎么滚动资产带都在，形成"每次分析都在沉淀东西"的心智（第二篇 §二）。
+  - 兜底方案：小屏幕上可收起，不影响主流程（第二篇 §二）。
+- **逻辑:** **权衡**推理——牺牲 110 像素的空间代价来换取一个常设可见的产品心智是划算的，因为该心智恰好是 Looping Data 作为产品想传达的核心主张（能力持续积累）；同时空间代价通过收起开关被兜底，不构成硬伤。
+- **结论:** 产品设计的最终目标是让用户内化"每次分析都在让下一次分析更可靠、更快、更可治理"这一信念。(→ 链 8)
+
+---
+
+## 链 8（架构决策）：智能体应解耦为六个独立智能模块，使"智能做得好不好"可被独立度量
+
+- **观点:** 将 Looping Data 中所有"智能"需求解耦为六个独立模块（任务理解、语义检查、分析引擎、报告组装、资产沉淀、复用匹配），使模型判断与业务逻辑分离，让"智能做得好不好"成为一个可独立度量的问题。
+- **事实:**
+  - 六处智能需求："任务理解、语义检查、分析引擎、报告组装、资产沉淀、复用匹配"（第二篇 §六）。
+  - 解耦动机："如果系统是模型判断和业务逻辑绞在一起，一次分析结果你是没法知道是模型判断错了，还是数据来源或业务分析错了"（第二篇 §六）。
+  - 下一步计划：搭智能体集群，六个角色智能体扮演提问者/分析师/专家/语义团队/权限管理员/管理者，用公开 Benchmark（InfiAgent-DABench 257 题 + LongTableBench 跨 18 个行业领域）逐题驱动整个生命周期（第二篇 §六）。
+- **逻辑:** **因果**推理——因为智能与业务逻辑耦合时，错误归因变得困难（不知是模型错了还是数据/分析错了）；解耦为六个独立模块后，每一处的智能表现可以独立测试和评估，形成可迭代的改进闭环。
+- **结论:** 智能体的架构设计应把"智能"内聚为少量可独立度量的模块，而非让模型判断与业务逻辑纠缠在一起。(→ 收束)
+
+---
+
+## 收束（回到链 0）
+
+> 数据分析智能体的真正难题不在技术问答（**链 1**）→ 而在企业复杂环境中持续可信，这要求用"缺口显性化 + 能力沉淀"替代一次性回答（**链 2–3**）→ 产品必须用 Analysis Case 工作台承载多角色协作而非对话框（**链 4**）→ 可信度来自可追溯的治理链而非模型自信（**链 5**）→ 闭环靠资产在案例序列间跨 Case 流动实现（**链 6**）→ 设计要让用户内化"每次分析都在沉淀能力"的心智（**链 7**）→ 智能应解耦为六个独立模块以便独立度量和迭代（**链 8**）→ 最终实现链 0 的主命题：**每一次分析，都让下一次分析更可靠、更快、更可治理。**