GitHub 开源: https://github.com/experdot/pointer [MIT]
在此前的一篇文章中，我从用户视角提出了 AI 聊天应用的十条改进建议。那篇文章是对现有工具不足之处的归纳和设想。此后，我借助 AI 辅助编程工具，着手将这些设想付诸实践，开发了一款名为 Pointer 的桌面端聊天应用。
经过一段时间的持续迭代和日常使用，我对许多功能细节有了更具体的认识，也有了更多的思考。
本文将这些思考和实践重新整理为二十个功能要点。为了便于阅读，我将它们按照内在关联分为五个部分：会话的组织与管理、对话的浏览与导航、对话的分支与协作、内容的输出与分享、数据的流通与边界。每个部分侧重解决一类问题，各功能之间也存在相互依存的关系，文中会加以说明。
随着使用频率的增加，会话数量会迅速膨胀。如何让用户在大量会话中保持秩序感，是最基本也最容易被忽视的问题。
当前主流 AI 聊天应用的会话列表，大多采用按时间倒序排列的线性结构。这种设计在会话数量较少时尚可应对，但当会话积累到一定规模后，线性列表便难以承载有效的信息组织。
在 Pointer 的设计中，我参考了 VS Code 文件资源管理器的交互模式，采用了树形文件夹结构。用户可以按主题、项目或任何自定义维度创建文件夹和子文件夹，将会话归入其中。这种分类方式的好处在于：它将组织信息的主动权交给了用户，而非强制依赖时间线。
在具体实现上，文件夹还应支持一键清空、批量删除、整体导出等操作。这些批量能力在日常维护中不可或缺——例如，将一批临时性的问答集中放入某个文件夹，用完后一次性清理，既不影响其他内容，也避免了逐条删除的繁琐。
标签页是一种广泛使用的界面模式，用户对其交互逻辑已经非常熟悉。在聊天应用中引入标签页，可以让用户将当前正在关注的若干会话固定在视野范围内，起到临时置顶的作用。
与侧边栏中的会话列表不同，标签页强调的是"当前工作集"的概念。用户可以同时打开多个会话的标签页，在它们之间快速切换。当某个阶段的工作完成后，通过"关闭其他"或"关闭所有"标签页来清理视图，保持界面的整洁。
这种机制在一定程度上也弱化了传统"置顶"功能的必要性——标签页的固定本身就是一种更灵活、更临时的置顶。
在实际使用中，用户常常需要对对话中的某些关键内容进行标记。星标功能作用于消息级别：当某条回复包含了特别有用的信息时，用户可以为其打上星标。
星标的核心意义在于定位。在一段包含数十轮问答的长对话中，真正关键的信息可能只集中在其中几条回复里。没有标记机制的话，用户每次回顾都需要从头翻阅，逐条辨认。而有了星标，这些关键节点就像书中的书签一样被固定下来，用户可以直接跳转到标记位置（见第 5 条"消息导航"），大幅减少无效的滚动和搜索。
如果说星标解决的是"在对话中快速找到重要内容"的问题，那么收藏（或称"笔记"）解决的则是"将有价值的内容从对话中沉淀下来"的问题。
收藏作用于更高的层面。它允许用户将某些内容摘录出来，脱离原始对话的上下文，作为独立的条目保存和管理。这更接近于个人知识库的功能，适合保存那些具有长期参考价值的片段——例如一段精炼的技术总结、一个值得反复使用的提示词模板，或者一段特别满意的 AI 回答。
星标与收藏的定位不同，互为补充。星标是对话内部的导航工具，收藏则是跨对话的知识沉淀机制。两者结合使用，能够让用户在高效浏览的同时，逐步积累起自己的知识库。
当单个会话中的对话轮次增多、回复篇幅增长时，如何在大量内容中高效浏览和定位，就成为直接影响使用体验的问题。
AI 的回复通常篇幅较长，尤其是涉及代码、列表或详细分析的场景。当对话轮次累积后，页面会变得非常冗长，用户在回顾上下文时不得不反复滚动，阅读的连续性因此被打断。
消息折叠功能可以有效缓解这一问题。它允许将某条回复收起为摘要状态，仅显示开头几行，需要时再展开查看全文。在此基础上，如果能够提供"仅折叠 AI 消息"的选项，效果会更好——用户可以快速浏览自己的提问脉络，迅速回忆起对话的推进逻辑，再有针对性地展开某条具体的回复。
在长对话中，快速定位是一项基本需求。应用至少应提供以下几种导航方式：
这些导航能力看似简单，但它们共同决定了用户在长对话中的操作效率。
全局检索的目标是在所有会话中搜索特定内容。在实现过程中，我发现检索本身的性能并非首要难点，更大的挑战在于结果的交互设计。
当关键词命中大量结果时，如果简单地以列表形式铺开，用户会面对一个冗长且缺乏结构的结果页，体验很差。一个可行的方案是：将检索结果按会话进行分组，每组默认折叠，仅显示会话标题和命中数量。用户可以逐一展开感兴趣的会话分组，查看其中的具体匹配项。这种分层展示的方式，能够在结果数量较大时依然保持界面的可读性。
与全局检索相对应，会话内检索的作用范围限定在当前打开的单个对话中。这是一个基础但不可或缺的功能，类似于浏览器中的页面内查找。在基于 Web 技术栈构建的聊天应用中，这个功能往往可以直接借助浏览器的原生能力来实现，实现成本较低，但带来的便利性很高。
AI 对话的一个独特之处在于，用户经常需要从同一个节点出发尝试不同的提问策略，或者让不同的模型处理同一个问题。这就要求工具在对话结构和模型调度上提供足够的灵活性。
消息分支允许用户基于对话中的某个节点，衍生出不同的后续路径。例如，对同一个问题尝试不同的提问方式，或者在 AI 给出回答后，从该节点出发探索多个后续方向。每条路径独立存在，互不干扰，用户可以自由地在分支之间切换。
这个功能的价值在于，它将对话从线性的、不可撤回的单一路径，扩展为可探索的树形结构。用户不再需要为了尝试另一种提问方式而放弃当前的对话进展。
市面上已有部分应用支持消息分支，但在交互细节上——如分支的可视化、切换的便捷性、分支历史的管理——仍有较大的改进空间。这也是我决定自行实现这一功能的主要原因。
不同的大语言模型在不同任务上各有所长。在实际使用中，用户有时需要在同一个对话中比较不同模型的表现，以判断哪个模型更适合当前的任务。
动态切换模型的功能允许用户在对话的任意轮次更换所使用的模型。这个功能与消息分支存在天然的配合关系：当用户在某个节点切换模型重新生成回复时，系统自动为其创建一个新的分支。这样，不同模型的回答被保留在各自的分支中，方便用户进行直观的对比和选择。
大语言模型的响应速度有时并不理想，尤其在使用推理能力较强的模型时，等待时间可能较长。在等待的过程中，用户往往已经想好了接下来要问的问题，却不得不等当前回复完成后才能发送。
消息等待队列解决的就是这个问题。它允许用户在 AI 尚未回复时继续发送新的消息，系统会将这些消息缓存起来，按顺序依次处理。用户甚至可以在发送完所有问题后暂时离开，稍后再回来查看全部结果。
这个功能的核心价值在于，它将用户从"等待-发送-等待"的同步节奏中解放出来，使得思考和提问的过程可以连续进行，不被模型的响应速度所打断。
在阅读 AI 回复的过程中，用户经常会对其中的某个词语、某句话产生进一步追问的需求。传统的做法是手动选中文字、复制、粘贴到输入框，再补充自己的问题。这个流程虽然可行，但操作步骤较多，容易打断思考的连续性。
右键引用功能简化了这一过程：选中文字后，通过右键菜单点击"引用"，选中的内容会被自动填入输入框，用户只需补充自己的问题即可发送。这个改进本身很小，但在高频使用的场景下，它能够显著减少操作摩擦，让追问变得更加自然。
与右键引用类似，但指向不同的使用意图。有时用户在阅读 AI 回复时，发现其中提到了一个值得深入探讨的概念或话题，但这个话题与当前对话的主题已经有所偏离。如果在当前对话中继续追问，会导致话题混杂；如果手动新建会话再复制内容，又不够便捷。
右键新建对话功能允许用户选中相关内容后，通过右键菜单直接以此为起点创建一个新的会话。新会话中会保留一个溯源标记，标示其内容来自哪个原始对话。这样，用户既可以就新话题展开独立的深入讨论，又不会失去与原始上下文之间的关联。
AI 生成的内容在聊天界面中通常具有良好的呈现效果，但当用户需要将这些内容输出到外部环境时——无论是分享给他人还是留作参考——往往会遇到格式丢失和操作繁琐的问题。
将对话导出为图片是目前最常见的分享方式。相比复制文本（Markdown 格式在多数即时通讯工具中会丢失），图片能够完整保留代码高亮、表格结构和排版样式。
在实践中，一个值得注意的细节是图片尺寸的适配。AI 对话的内容往往较长，生成的图片也随之很长。如果宽度过大，用户在手机端查看时需要反复缩放才能看清文字，体验很差。因此，图片导出功能应当提供尺寸选择器，允许用户根据分享的目标平台选择合适的宽度——例如适合手机竖屏查看的窄长图。
AI 经常以表格形式呈现结构化信息。在需要将表格内容复制到外部使用时，支持多种格式是必要的：Markdown 格式适合粘贴到支持渲染的编辑器中，CSV 格式方便导入电子表格工具，图片格式则用于直接分享。
在移动端场景下，表格还面临一个额外的挑战：横向空间有限，多列表格的图片在手机上阅读体验很差。一个实用的解决思路是提供"降维"选项——将横向展开的多列表格转换为纵向排列的表单记录格式，每条记录占据完整的宽度。这种转换虽然牺牲了表格的紧凑性，但在窄屏设备上的可读性会大幅提升。
前面四个部分讨论的是功能层面的具体需求。这一部分关注的是更底层的问题：数据如何在不同平台之间流动，以及产品在功能边界上应当做出怎样的取舍。在功能不断膨胀的环境下，做加法是容易的，做减法才需要判断力。一款产品不仅要清楚自己做什么，也要清楚自己不做什么。以下五条中，前两条关于数据的流通，后三条关于边界的坚守。
导入导出功能的核心要求是：用户能够以结构化的格式完整地导出自己的数据，并在需要时将其恢复。这里的"结构化"意味着，导出文件中不仅包含对话内容本身，还应保留消息的时间戳、角色标识、分支结构、模型信息等元数据，以确保数据在还原时的完整性。
在此基础上，还有一个容易被忽略的细节：导入导出应当支持选择性操作。用户往往只需要导出或导入某几个特定的会话，而非全量数据。同时，设置、会话、收藏等不同类型的数据也应当被区分对待，允许用户按需选择，而不是将所有内容捆绑在一起。
与上一条关注的是自身数据的导入导出不同，这一条针对的是跨平台的数据迁移。当用户从其他 AI 聊天平台转向新的工具时，已有的对话历史是一项重要的资产。如果新工具能够直接导入这些历史记录，会极大地降低迁移成本。
理想情况下，应用应当尽可能兼容市面上主流 AI 聊天平台的导出格式。当然，各平台的数据结构差异较大，完全兼容的工作量不小。但即便只是支持几个最常用平台的导入，也能为用户提供实际的帮助。
MCP（Model Context Protocol）是一种允许模型调用外部工具的协议。然而，在聊天应用的场景下，引入 MCP 意味着应用需要与外部服务进行交互，这会引入新的安全攻击面。
在 Pointer 的设计中，我选择不支持 MCP。原因很简单：对于一款定位为纯文本聊天工具的应用而言，用户发送的内容可能涉及私密的思考和敏感的信息。在这种场景下，任何与外部系统的交互通道都会增加数据泄露的风险，而这种风险与产品"保护用户隐私"的核心承诺相矛盾。
同样出于产品定位的考量，Pointer 不支持音频、视频等多模态内容的处理。多模态能力在很多场景下很有用——但是一款产品不可能在所有方向上同时做到优秀。
聊天应用的核心体验在于文本交互的流畅性和深度。如果在此基础上叠加多模态功能，不仅会增加界面和交互的复杂度，也会分散有限的开发精力。保持专注，将文本聊天这一件事做到足够好，是更务实的选择。
联网搜索功能允许模型在回答时实时检索互联网信息。这个功能的实用性毋庸置疑，但它伴随着一个无法回避的隐私问题：一旦启用联网搜索，用户的对话内容——或至少是从中提取的搜索关键词——就有可能被传递给第三方搜索引擎。
可能有人会指出，API 提供商本身也存在数据风险，这一点确实如此。但这并不构成继续增加风险暴露面的理由。在安全设计中，每减少一个潜在的泄露通道，整体风险就降低一分。
也有人会建议，可以提供一个开关，将选择权交给用户。但对于高度敏感的用户而言，一个可以被意外开启的功能——无论是由于操作失误还是程序缺陷——本身就是一种焦虑来源。从彻底消除这种焦虑的角度出发，最稳妥的方案是从产品层面根本不提供这个功能。
上述三条"说不"，并非意味着这些功能没有价值，而是说它们不应该存在于每一款产品中。当某项能力与产品的核心定位——隐私、专注、安全——产生冲突时，选择放弃需要的不是技术能力，而是对产品边界的清醒认知。不同的产品可以有不同的侧重，用户也应当拥有选择的空间。
以上二十个功能要点，涵盖了从会话组织到内容输出、从交互细节到设计取舍的多个层面。它们共同指向一个目标：将 AI 聊天工具从一个简单的问答界面，打磨为一个值得用户长期依赖的、体验完整的个人工具。
回顾这些要点，可以将它们背后的设计理念归纳为三条：
这些实践中的思考和体会，或许能为有类似需求的开发者或用户提供一些参考。
GitHub 开源: https://github.com/experdot/pointer [MIT]
前序文章：AI 聊天应用的十条改进建议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。