返回作品列表

思维星图

Mindscape · 给 AI 对话装一层「岔开话题」的分支机制

和 AI 聊正事的时候,人总会突然想岔开问一句。问完之后,那五六轮讨论就一直留在上下文里,后面每一次回复都要背着它们。 这个产品让你把岔开的那段放进单独一层,聊完只带走要用的结论,剩下的留在那层里,不往外漏。

ROLE交互范式 / 状态设计 / 可视化
TYPEAI 对话增强应用
CORE分支 · 收割 · 胶囊 · 星图
STATUS已上线,多部门申请使用
INSIGHT

上下文是会被弄脏的

大家抱怨 AI 的时候,说的多半是它记不住。我碰到的麻烦在另一头,它记得太多了

主线正在写一份报告,我突然想确认某个口径怎么算。这个确认来回五六轮,全塞进主线之后,后面写报告的每一次回复都得驮着这堆讨论,又慢又容易跑偏。人在想事情的时候本来就会岔开,这不是坏习惯。

什么时候该开一层,只有一条判断。
这段话你不希望它留在主线的上下文里。

如果只是一句追问,直接在主线问更快。开层是有成本的,进层要装一份上下文,回来还得走一遍收割。所以我做的第一个设计决定,是给这个功能明确划出"什么时候别用它"。

MECHANISM

四步机制

STEP 01
开一层

在主对话打 /btw 加上目标,分支直接以这个目标开出来。不带内容就开一个空层等你提问。

STEP 02
装上下文

把父层最近的对话原文带进分支,所以它能接住你说的"我刚才提到的那个"。超窗的更早历史压成四段摘要。

STEP 03
独立地聊

分支只受两条约束,聚焦这一层的目标,不编造上下文里没有的东西。可以切"纯思考"和"启用工具"两种模式。

STEP 04
收割

结束这一层时选一档策略,决定带多少回主线、要不要留下一颗知识胶囊。这是整个产品的核心。

收割的四档策略

"聊完之后带什么回去",如果只给"要"和"不要"两个选项,这个产品就没什么意义了。人对一段讨论的处置,本来就有四种不同的想法,所以我拆成了四档。

策略带回主线什么时候用
A · 丢弃什么都不带试了一下发现方向不对,没有可留的结论。
B · 摘要一段提炼后的摘要最常用。有结论,但主线只需要知道结论。
C · 精选你从候选里勾选的 1 到 5 条聊出好几个要点,只有其中两三条跟主线有关。
D · 全量整层压成胶囊并附全文这一层本身就是要交付的东西,后面还要反复回看。
  • 系统会先替你推荐一档,依据是对话轮数、有没有代码和表格、有没有出现结论性表述。多数时候直接确认就行。
  • 带回的文本自动填进输入框,但不自动发送。你可以改一遍再发,也可以删掉不发。最后一道闸门得留给人。
  • 会提示撞车。新胶囊和库里已有的相似度过线时,会告诉你它和哪条历史结论高度重合。同一个问题绕回来两次,这事非常常见。
VISUALIZATION

星图让分支结构一眼可读

分支一多人就会迷路。所以首页做成了一张星图。中间那个克制的小光点是主线,往外每一颗星是一层分支,细线表示父子关系。

  • 大小按层级定档。主线最大,越深的层越小。消息数和新鲜度只在同一档内做很小的浮动,一个聊了很久的三层分支不会因此长得比主线还大。要是让数据量直接决定尺寸,层级关系就被淹没了。
  • 颜色分三档。靛蓝带脉冲光环 = 进行中的那一层;紫罗兰 = 已经收割过的;冷白 = 其余已关闭的层。
  • 点任意星点出详情面板,里面有目标、状态、消息数、更新时间、所属父层和父层锚点。星星多到看不清的时候,可以切回树状视图。
思维观测台:星图视图
思维观测台 · 星图视图,层级 / 状态 / 父子关系一屏可读(示例数据)
WALKTHROUGH

完整走一遍

拿一次旅行规划当例子。8 条分支,40 多轮探索,9 颗知识胶囊,主线的上下文最后只多了 4 行。中间那 20 轮关于排队文化的闲聊,主线到最后都不知道发生过。

一次旅行规划的完整分支流程示意
流程示意 · 分支、胶囊、收割策略与最终回到主线的内容
SUPPORTING

让长对话可回溯的三件事

快照与时间轨

每新增 5 条消息自动存一张快照,关层前再补一张终态。侧边时间轨点一下就跳到对应阶段,长分支里比手动滚动快得多。

从此处岔开

基于某个时间点的历史另开一条新分支。聊到中途想回头换个思路,又不想丢掉后面已经聊的内容。

知识胶囊库

跨会话沉淀所有收割过的结论。搜索分两段跑,先出关键词命中,再把语义命中的结果淡入追加。

一个我自己很喜欢的细节。胶囊库的搜索结果会自己"长出来一点",那是第二段语义检索回来了,不是页面刷新出错。这句解释我直接写进了产品说明里。让用户困惑一次的代价,比多写一句话贵多了。
HONEST NOTES

它还有哪些不完美

写产品说明的时候,我坚持给限制单独留一节,没有把它们混在正文里带过去。

  • 原文窗口有上限。父层只带最近一定量的原文进来,更早的部分只剩摘要。特别早的前提如果被略掉了,在分支里补一句就行。
  • 在主对话里聊分支,每轮都要带命令。这是实际使用中被撞得最多的一条。右侧独立面板没有这个限制,它存在的理由就是这个。
  • 窄屏有取舍。三个断点逐级简化布局,手机上能用,但长分支的阅读体验仍然不如宽屏。
把限制写清楚,用户会信任说明书的其余部分;把限制藏起来,他撞上第一个坑之后,就再也不信了。
后来发生的事。在一次公司内部的技术分享之后,陆续有其他部门的同学来找我,问这个东西能不能给他们也开一个使用资格。这说明"上下文被岔开的话题挤占"不是我一个人的问题。
NEXT CASE群播中心 Relay