整理 Looping Data 相关文件至独立文件夹
- 将 looping_data.md、screenshot1.png、screenshot2.png 移至 looping_data/ 文件夹 - 新增推理链分析文稿 looping_data_reasoning_chain.md（原 infer.md） Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>
This commit is contained in:
推理链专家
@@ -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，包括业务问题、分析路径、语义缺口、数据和权限边界、人工确认、经营动作、可沉淀资产。
|
||||
|
||||
|
||||
|
||||
### 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. 业务分析流
|
||||
|
||||
|
||||
|
||||
### 2. 能力建设流
|
||||
|
||||
|
||||
|
||||
## 四、角色如何在 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 沉淀的东西。因此，这一篇主要想先从产品设计上讲清楚几件事。
|
||||
|
||||
|
||||
|
||||
## 一、不做对话框
|
||||
|
||||
动手前我做了三个原型方案：
|
||||
|
||||
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 如何闭环
|
||||
|
||||
做完第一版原型，我发现一个问题：界面上画出来的其实是一条直线。发起、分析、确认、沉淀，从左到右从上到下，走完就结束了。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 的目标：每一次分析，都让下一次分析更可靠、更快、更可治理。
|
||||
|
||||
那产品设计就是几条可以逐步迭代优化的曲线：准确率、可信度起点、资产复用率等等。最终结果出来是什么样呢？请让我留给下一篇文章。
|
||||
@@ -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 的主命题：**每一次分析，都让下一次分析更可靠、更快、更可治理。**
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 3.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.5 MiB |
Reference in New Issue
Block a user