[Draft] RFC | Taming Context Chaos - A Proposal for a Graph-driven AI Chat Interface

[cy948]

Introduction

在信息的汪洋中，重新编织思想

大语言模型（LLMs）正以前所未有的速度提供更长的上下文，其日益增长的容量与日渐低廉的成本。 更长的上下文窗口让我们有机会向它输入更多的信息，去挑战更加复杂的难题。 但，我们真的准备好了吗？ 我们或许有过这样的经历：在与 AI 探讨一个复杂问题时，面对海量的文本、无尽的对话分支和 AI 逐渐衰减的记忆，最终，我们和 LLM 一同在信息的海洋中迷失了。

具体而言，我们会遇到这些问题：

• 上下文质量（The Crisis of Context Quality）
  • 污染（Pollution）： 一个微小的幻觉、一处事实错误、或是一段微妙的曲解，就像一滴墨水滴入清水。一旦进入上下文，它就会污染后续所有的推理，导致整个分析建立在错误的基石之上。
  • 干扰（Interference）： 过多无关的上下文进入会对当前关注议题造成干扰，信噪比低。
  • 冲突（Conflict）： 上下文中甚至可能存在冲突或界定不清晰的内容，影响输出结果。
• 上下文视图（The Black Box of Cognition）
  • 迷失方向感 (Loss of Orientation): 在永无止境的聊天记录中，我们很容易忘记“我们是如何走到这一步的？”。重要的假设、关键的转折点，都被淹没在滚动的屏幕中，我们失去了对整个思考过程的“地图”。
  • 结构性缺失 (Absence of Structure): 在线性的对话流里，一个石破天惊的洞见和一个无关紧要的闲聊，在视觉上没有任何区别。所有信息都被压平成一个一维的时间线，我们无法区分主次、建立层次，思想的骨架无处可寻。
  • 连接的不可见性 (Invisible Connections): 最重要的洞见往往产生于不同概念的连接。在线性对话中，一个早期假设与后期结论之间的关键联系，只能脆弱地存在于我们自己的记忆中。我们无法看到、标记或强化这些连接，任由它们被遗忘。

这个“质量”与“认知”的双重危机，导致我们无法真正利用长上下文的力量，反而为其所累。我们认为，在长文本场景下，“模型能力”与“用户 & UI能力”是一个硬币的两面。 我们坚信，解决问题的关键不在于限制信息的输入，而在于重新获得对它的掌控，实现可控的复杂度增长。而掌控信息的关键，不只是用户本身对信息有很好的理解，更是更高效的上下文管理范式，一种能将混乱的线性对话，重塑为清晰思想网络的方法。

Weaver 正是为此而生。它不是一个简单的聊天工具，而是一个思维的编织机。它通过独特的图谱（Graph）结构，让你能驾驭不断增长的上下文复杂度，将混乱的信息『编织』成清晰、可控、且充满力量的思想网络。

Branding 待定，需要讨论

Design Philosophy

Weaver 的一切设计都源于三个核心原则，它们共同构成了我们对以上挑战的回应。

Clarity and Control over Chaos

混乱是创造力的天敌。传统线性对话的“无序性”是混乱的根源：上下文边界模糊，重要观点被噪音淹没。Weaver 通过图谱（Graph）结构，将你的思考过程从一维的线性文本中解放出来，变成一张二维的、可被直观感知的思想地图。

• 节点 (Node) 作为思想容器： 每一个节点都是一个独立的、原子化的上下文单元。它可以是一篇长文、一段灵感，或是一次深度对话的结论。通过 标题、摘要、全文 三层结构，你可以在不同粒度上驾驭信息。
• 边 (Edge) 作为思想脉络： 你可以主动地通过“边”来连接不同的思想节点，建立它们之间明确的、可信的逻辑关系。这种有意识的连接，赋予了上下文前所未有的透明度和可解释性。

在 Weaver 中，你将永远拥有一个“上帝视角”，清晰地知道“我在哪”、“我要去哪”，以及“各个部分是如何关联的”。

Fluid Scaling of Thought

顶级的思考者，都善于在全局战略和局部细节之间自由切换，在宏观与微观间自由穿梭。Weaver 的设计正是为了让这种切换变得如呼吸般自然。

• 宏观构建 (Macro-level Construction): 在图谱视图中，你关注的是概念之间的连接与布局。无论是 One-to-Many 的灵感发散，还是 Many-to-One 的信息聚合，你思考的是整体架构，如同将军在沙盘上排兵布阵。
• 微观探索 (Micro-level Exploration): 当你深入任何一个节点，即可沉浸到其完整的细节中进行深度阅读或对话。完成探索后，你又能瞬间回到宏观视图，而无需担心“迷失在细节里”。

这种能力的解放，意味着你无需再用大脑去“记住”那些繁杂的信息，从而将宝贵的认知资源完全投入到最高层次的创造与推理中。

Human-in-the-Loop

我们坚信，在解决真正复杂的任务时，人类的智慧与判断力不可或缺。相比其他工具试图通过全自动的检索（RAG）来管理上下文，但这些黑盒功能往往导致结果不可控、不透明，因此我们主张有边界的人机协作，在关键内容上手动、显示化地构建可信内容。

Weaver 提倡一种人机混合的上下文管理模式，将最终的决定权交还给你——这位思想的编织者。

• 双层上下文控制： 通过 摘要 (Summary) 和 全文 (Full Context) 的设计，你可以与 AI 共同打造一个高质量、高信噪比的上下文“信源”。在关键推理时，你可以选择仅使用你认可的 摘要，从而构建一个极其干净的环境，引导 AI 进行更高质量的输出。
• 手动编排的自由： 你是上下文的唯一主宰。你可以随时断开某个节点的连接以排除干扰，也可以将两个看似无关的灵感连接起来，创造新的可能性。

我们相信，最深刻的洞见，源于人类有意识的创造。

Stories

用户故事一：从海量信息到一份精准的投资报告 (Many-to-One)

从信息过载到可审计的洞察

场景:
投资分析师 Alex 需整合数十份研报、财报和政策文件 (Many)，撰写一份关于电动汽车市场的投资报告 (One)。她使用 AI 聊天工具，不断“喂”入资料，AI 快速生成了报告草稿。

但在预审会上，总监质疑报告中一个关键结论的依据来源。

痛点：论证的“黑盒”与“血统”危机
Alex 无法回答。在长长的聊天记录里，AI 的结论是所有输入信息的混合体。她无法追溯是哪份资料支撑了这个关键论点，也无法排除其它无关信息造成的“上下文污染”。她的报告看似高效，实则建立在无法验证、不可信的“黑盒推理”之上。

The Weaver Way：

1. 独立容器: 每一份研报、财报都成为一个独立的 资料节点。信息源清晰隔离。
2. 显式连接: Alex 创建一个 结论节点，然后手动地将支撑该结论的几个关键 资料节点 与之连接。这个连接动作本身，就是一次可追溯的论证。
3. 精准推理: AI 在 结论节点 中进行的推理，上下文被严格限定在这些被连接的节点上，信噪比极高。
4. 即时审计: 面对总监的提问，Alex 只需展示图谱。结论与证据之间的连接一目了然，论证路径清晰、可信、可审计。

用户故事二：从一个核心概念到一场失控的创意风暴 (One-to-Many)

从灵感火花到结构化的创意宇宙

场景:
品牌策划 Maya 有一个核心概念“城市绿洲” (One)，她与 AI 在一个聊天窗口里进行头脑风暴，发散出产品命名、包装设计、线下活动等无数创意 (Many)。

但在次日的汇报会上，CEO 问及产品名和线下活动之间的一个关键连接点时，Maya 却卡住了。

痛点：创意的“线性坟场”
那个绝妙的连接点，就埋藏在数百条跳跃、混乱的聊天记录中。Maya 的思维是网状的，但工具却是线性的。所有创意的层级、分支和连接都被“压平”成一条无法导航的时间线，一个充满活力的创意网络，变成了一座无法检索的“灵感坟场”。

The Weaver Way：

1. 中心开花: “城市绿洲”是图谱中心的 核心节点。
2. 结构生长: 产品命名、包装设计、线下活动等都作为 子节点 从核心节点上“生长”出来，形成清晰的树状结构。
3. 连接永存: 那个关键的连接点，不再是一条会被遗忘的消息，而是一根可见的 边，直接连接着 产品命名节点 与 线下活动节点，甚至可以给这条 边 加上标注。
4. 全局地图: 在汇报时，Maya 展示的不再是难以追溯的聊天记录，而是一张思维清晰、连接可见的“创意地图”。她可以随时在宏观结构和微观细节间自由切换。

用户故事三：从用户之声到产品迷途 (Many-to-One-to-Many)

从原始反馈到可验证的解决方案

场景:
产品研究员 Leah 分析了海量用户反馈 (Many)，提炼出核心洞察“UI 过于复杂” (One)，并产出了精美的报告。基于此，团队头脑风暴出“新手模式”等多个解决方案 (Many)。

但在方案评审会上，工程师提出了一个致命问题：“我们如何证明‘新手模式’能解决用户最初抱怨的那些具体问题？”

痛点：断裂的“推理之链”
Leah 无法回答。她的工作流被割裂成两段：第一阶段的“洞察提炼”丢失了原始反馈的丰富细节；第二阶段的“方案设计”则建立在一个被过度概括、失去根基的结论之上。从“具体的用户抱怨”到“具体的解决方案”，最重要的逻辑链条已经断裂。

The Weaver Way：

1. 统一工作台: 从反馈到方案，所有环节都在同一个图谱中完成。
2. 证据链条: 每条用户反馈都是一个 证据节点。Leah 将相关的 证据节点 连接到一个 洞察节点（“UI 复杂”）。
3. 洞察驱动: 团队从 洞察节点 发散出多个 方案节点（“新手模式”）。
4. 端到端可追溯: 面对工程师的质疑，Leah 只需点击 “新手模式”节点，图谱就能高亮显示出它的完整“血统”——它源于哪个洞察，而这个洞察又是由哪些具体的用户抱怨支撑的。推理之链完整、坚固、全程可见。

Comparison

• Flowith: Flowith's interaction is based on a two-dimensional canvas that allows you to simultaneously interact with multiple AI models within a single workspace.

• Refly: Refly is an AI-native content creation platform built on the concept of "Free Canvas". Through multi-threaded conversations, knowledge base integration, context memory, intelligent search.

• Hippo: A prototype that allows users directly interact with the reasoning process before the model generates its final output.

• Free Canvas: 提供自由的画布允许用户去组织概念结点及其关系。

  • 除了 Hippo 外，都提供了自由画布。

• Node Content Granularity: 内容结点的范围。

  • Flowith 和 Refly 以单个对话回合，即 [user, assistant] pair 为一个结点内容。
  • Hippo 对一个 query 进行 decompose ，更为仔细。
  • Weaver : 允许任意个对话回合作为结点内容。

• Context Management: Canvas 的结点间的上下文管理。

  • Flowith, Weaver: 都采用手动管理，但 Flowith 仍然是线性的分支，而 Weaver 会计算连通结点。
  • Refly: 采用 RAG 管理

Challenges

下面以用户的生命周期旅程（User Journey Lifecycle）来组织和划分挑战。我们将用户的生命周期划分为四个关键阶段：

• Phase 1: 初次接触与上手 (The First 5 Minutes) - 从用户听说 Weaver 到第一次成功创建节点和连接。
• Phase 2: 理解核心价值 (The First Hour) - 用户开始理解“掌控上下文”带来的好处，并完成一个简单的任务。
• Phase 3: 深度使用与依赖形成 (The First Week) - 用户开始用 Weaver 解决真实、复杂的问题，图谱规模开始扩大。
• Phase 4: 成为高级用户与产生不满 (The First Month & Beyond) - 用户深度依赖产品，但开始触及其能力边界，并渴望更强大的功能。

Phase 1: 初次接触与上手 (The First 5 Minutes)

在这个阶段，所有努力都应聚焦于降低用户的进入门槛，让他们能以最小的摩擦成本，体验到从 0 到 1 的创造快感。

• 用户心态: “这是个什么东西？看起来有点复杂。让我试试看，如果 5 分钟内搞不懂我就关了。”
• 核心目标: 消除困惑，快速给予正反馈，让用户成功迈出第一步。

此阶段的最高优先级挑战:

• 挑战1: “空白画布”的瘫痪效应 (Top Priority)
  • 原因: 这是用户流失的第一个筛子。如果用户打开应用后不知所措，他们会立即关闭。
  • 解决方案焦点: 设计清晰的首次使用引导 (Onboarding)，提供预设模板，确保“双击创建节点”等核心操作极其显眼和直观。
• 挑战2: 学习曲线与认知负荷 (基础部分)
  • 原因: 即使用户创建了节点，如果 UI 术语（如“摘要”、“全文”）和界面布局令人费解，他们也会放弃。
  • 解决方案焦点: 简化 UI，用最平实的语言，确保核心概念（节点是容器，边是关系）不言自明。
• 挑战3: 基础画布交互
  • 原因: 如果连最基本的平移、缩放都感觉卡顿或不合直觉，用户会立刻判定这个产品“很粗糙”。
  • 解决方案焦点: 确保画布导航流畅、响应迅速。

Phase 2: 理解核心价值 (The First Hour)

这个阶段的目标是让用户亲身体验到“为什么我需要一个图谱”，而不仅仅是“如何使用一个图谱”。

• 用户心态: “OK，我会用了。现在让我看看它到底比普通的 ChatGPT 强在哪？它能帮我解决什么实际问题？”
• 核心目标: 清晰地展示产品的核心价值主张 (UVP)，让用户体验到“Aha! Moment”。

此阶段的最高优先级挑战:

• 挑战1: 聊天时的上下文可见性 (Top Priority)
  • 原因: 这是 Weaver 的“魔法时刻”。当用户在一个节点里聊天，并能清晰地看到是哪些其他节点在为这次对话提供上下文时，他们才会真正理解“可控、可追溯的推理”意味着什么。
  • 解决方案焦点: 设计一个极其清晰的上下文来源指示器，让用户在聊天时就能直观地管理和感知上下文。
• 挑战2: 宏观与微观的流畅切换
  • 原因: 在体验了聊天后，用户需要返回宏观视图。这个切换过程必须平滑，否则会产生强烈的割裂感，破坏“流体思考”的体验。
  • 解决方案焦点: 优化从节点详情到画布的过渡动画和焦点保持。
• 挑战3: 基础工作流融合 (输入)
  • 原因: 用户会开始尝试将自己的资料（如复制一段文字）放入 Weaver。这个过程必须简单。
  • 解决方案焦点: 实现智能粘贴（粘贴文本自动创建节点）等功能，减少手动操作。

Phase 3: 深度使用与依赖形成 (The First Week)

这个阶段要证明 Weaver 不仅是一个新奇的玩具，更是一个能处理严肃、复杂工作的生产力工具。

• 用户心态: “这工具太棒了！我要用它来搞定我那个复杂的报告/项目/研究。我的节点越来越多了……”
• 核心目标: 确保产品能够承载真实世界的复杂度，成为用户不可或缺的“第二大脑”。

此阶段的最高优先级挑战:

• 挑战1: 图谱的可读性与可扩展性危机 (Top Priority)
  • 原因: 当节点数量庞大，“意大利面”问题就会出现，Clarity and Control 的承诺会受到严峻考验。这是决定用户能否长期使用的关键。
  • 解决方案焦点: 优化自动布局算法、节点分组/折叠、小地图 (Minimap)、强大的搜索和筛选功能。
• 挑战2: Graph2text 、Graph 上下文的智能构建
  • 原因: 用户构建了复杂的图谱后，最终的目的是产出成果。如果 LLM 无法理解用户所看到的图谱的内容和关系，那么产品的价值链就是断裂的。
  • 解决方案焦点: 更好的 Graph 降维方法， Prompt / Context Engineering 。
• 挑战3: 工作流自动化集成
  • 原因：用户很可能陷入大量的重复结点工作中，例如重复地将一篇文章输入结点，然后进行总结，检验。
  • 解决方案焦点: 适度引入工作流编排自动化。
  • 意义： 将项目引向更庞大，更真实的 Working Bench 中。这里面甚至可能 Humman in the Loop 的 DeepResearch 产品？

Phase 4: 成为高级用户与产生不满 (The First Month & Beyond)

在这个阶段，产品的重点从“可用”转向“强大”和“生态化”，开始构建真正的竞争壁垒。

• 用户心态: “我已经离不开 Weaver 了，但它在 XXX 方面做得还不够好。如果能支持多人协作/自动整理/……就好了。”
• 核心目标: 留住核心用户，拓展产品边界，构建护城河。

此阶段的最高优先级挑战:

• 挑战1: AI 辅助的图谱管理 (Top Priority)
  • 原因: 高级用户追求极致的效率。他们会厌倦所有事情都亲力亲为，渴望 AI 能成为更主动的伙伴，探索 AI 自动化的边界，重新寻找 Humman in the Loop 的平衡点。
  • 解决方案焦点: 开发智能节点建议、创建，关系发现等功能（类似 GNN 任务？），从“手动编织”向“人机协同编织”进化。
• 挑战2: 工作流的割裂与融合 (深度集成)
  • 原因: 用户的痛点会从应用内部转移到应用与外部生态的连接上。例如在上面我们提到类似 Notion 这类的 Knowledge Base 是一个更长期的知识存储，检索方案。 如果能连接到 Notion 这类 KB， 将推进存储推理一体发展。
  • 解决方案焦点: 与 Notion、Obsidian 等工具的深度集成，提供 API。
• 挑战3: 协作与网络效应
  • 原因: 许多复杂的工作是团队完成的。缺乏协作能力会成为用户流向 Figma、Miro 等竞品的直接原因。
  • 解决方案焦点: 开发多人实时协作功能。

RoadMap

• 短期 (Phase 1-2): 聚焦于核心体验和价值传递，确保产品能活下来。
• 中期 (Phase 3): 聚焦于可扩展性和生产力，确保产品能留住用户。
• 长期 (Phase 4): 聚焦于效率、生态和协作，确保产品能持续成长并建立壁垒。

PoC

• ✨Client DB
• 🚧 Working Branch

在左侧栏最下方的按钮进入，或在初始化完成后访问 /graph

Quick Start

• 可视化图谱视图 (Graph View)
  • 画布导航:
    • 移动: 按住鼠标中键拖动。
    • 缩放: 滚动鼠标滚轮。
  • 节点管理:
    • 快速创建: 在画布任意位置双击左键。
    • 精确创建: 右键画布，选择 创建 ChatNode 或 创建 TextNode。
    • 批量选择: 按住 Shift 并框选。
    • 删除: 选中节点或边后，按 Del 键。
  • 自动布局:
    • 右键画布，选择 整理视图，可一键排版。
• 节点系统 (The Node System)
  • 内容编辑:
    • 直接点击标题进行重命名。
    • 单击节点打开详情面板，编辑 Full Context 和 Summary。
  • 上下文控制:
    • 在详情面板中，使用开关控制该节点是否在推理中默认使用 Summary。
  • 节点连接:
    • 从结点左右两侧的 ⭕ 连接点拖拽至目标节点即可建立连接。

---

Feedback & Iteration

• 视图： 并不是所有 Branch 都是必要展示的，存在局部重要全局不重要的 Branch，类似 Agent Threads ； 同时也有全局重要的 Main Branch，代表事情解决的推进。
• 交互： Canvas 产品的 OnBoarding 难度问题。
• 下一步： 改变思路，从如何用视图表达当前的 ChatList 开始，从根本上解决这两个问题。
  • 通过更好的 TreeView 设计提升视图表现
  • 借鉴 Affine 这样的无缝切换，降低 OnBoarding 成本。

10/26

• 也许这个过程的概念抽象，会与 DeepResearch Agent, DRA 中的 Challenge 相关
• 在 Memory Management 中， 也类似 DRA

10/28

• 也许两个 Standpoint :
  • User Intention / Sub Task are obscure?
  • Task resolving is not promising, need branching & backtracking?
• Modeling 过程 MDP

[ONLY-yours]

分支对话 -> 通过 flow 拖拽这个很不错

这样子还能解决现在无法在分支对话下方无法再开分支的问题

[cy948]

对的，如果 ChatList 能有选中 message 的话，甚至可以设计将当前一个对话结点“裂变”出子结点，实现类似 cherry-pick 的效果。

[MapleEve]

可视化拖拽可以，不过 one - many 感觉说的有点太抽象了，应用方向很多

[cy948]

嗯， 不过现在的可视化和 OnBoarding 还是做的不够好，下周会迭代一版不同方向的，欢迎佬到时候来试试更加自然的版本。 😋