长期记忆存起来容易，用户看不见也管不了。记忆一旦不可见，就会累积错误信息并持续污染后续对话——模型出错时没有纠正入口，错误就永久留存。
我在 yun-claude 的记忆设计中遇到的问题正是这个。聊天系统能自动从对话抽取持久要点并入库，但页面还是传统的卡片列表，看不出记忆的类型、重要性、使用频次。更严重的是，用户无法编辑或删除那些被错误标记的记忆。所以这次升级的核心不是加一个炫彩的可视化，而是把记忆管理变成一个真正可用的信息工作台。
表格优先，而不是星河优先
设计的第一个决策是：主界面用表格承载记忆列表，不用星河画布作主体交互。
这听起来反直觉。当初考虑过让星河画布成为核心——节点按重要性大小分布、按创建时间环形排列、搜索命中时高亮。视觉上是漂亮的，也更有"知识宇宙沉淀"的产品感。但约束改变了这个选择：
第一，信息密度。表格一屏可以显示 10-20 条记忆的核心属性（标题、类型、重要性、标签、创建时间），并支持排序和筛选。星河画布要展示相同的信息量，就必须让节点变小、缩放调整、甚至分屏展示——交互成本陡升。而用户——AI agent 的主人——需要快速浏览和定位记忆，不是浏览艺术装置。
第二，编辑成本。星河上的节点编辑通常要额外打开面板或弹窗。如果记忆管理的主要工作是"检查是否有错记、删除重复、调整分类"，那星河就不是最优方案。对比之下，表格 + 右侧详情面板的结构让用户可以同时看到列表和正在编辑的项目，没有上下文切换。
第三，用户规模。当前 yun-claude 没有真实用户，推断单个用户的记忆条数会比较少（几十到几百）。在这个规模下，表格就足够快了，不必依赖图形加速或向量索引的复杂优化。如果将来规模增大再考虑换方案。
所以最终设计是：表格为主工作台，右侧详情面板负责编辑与整理，星系可视化只作为辅助视图（后续可选）。这不是缺乏视觉想象力，而是对工作流的务实权衡。代价是产品感稍弱，但可用性强得多。
五类语义记忆与设计令牌
为了让记忆可见可管，将长期记忆分成五类：
- 核心记忆（CORE）：与用户身份、核心项目、重要约束直接相关。模型在每轮对话发送前都应该检索。
- 常驻记忆（PERMANENT）：用户的工作背景、技术栈偏好、团队结构等长期背景。
- 临时记忆（TEMPORARY）：短期的任务进度、当前问题、临时约束。生命周期短。
- 知识星云（KNOWLEDGE）：用户分享的文档要点、API 文档摘录、最佳实践。主要用于 RAG 增强。
- 其他（OTHER）：模型无法明确分类或用户手动标记的记忆。
每一类的关键差异是生命周期和召回策略。核心记忆应该高频被注入 prompt，临时记忆应该自动清理，知识类应该被 RAG 系统共同使用。
为了在视觉上强化这个分类，为每类配置了一个独立的语义色：
| 类型 | 颜色 | 用途 |
|---|---|---|
| 核心 | Amber-500 | 节点、筛选按钮、卡片左边线 |
| 常驻 | Sky-500 | 节点、筛选按钮、卡片左边线 |
| 临时 | Teal-500 | 节点、筛选按钮、卡片左边线 |
| 知识 | Violet-500 | 节点、筛选按钮、卡片左边线 |
| 其他 | Slate-500 | 节点、筛选按钮、卡片左边线 |
关键的设计决策是：颜色不只是装饰，而是结构的一部分。在表格、筛选条、详情面板的边线上，用户都能看到同一个颜色，强化类型认知。这样的一致性是可信的信息工作台的标志——用户一眼知道哪条记忆是核心、哪条是临时。
颜色值不是散落在各个组件里的魔法数字，而是集中在一个 memoryStyles.ts 文件中管理。任何需要记忆类型颜色的地方都从这里引用。这样改一个颜色时不必跨多个文件搜索替换，也不会出现同类型在不同地方显示不同色的尴尬局面。
记忆模型与后端约束
后端为每条记忆增加了结构化字段：
title：节点或列表行的标题，从正文前 18 个字符生成type：五类之一importance：1-100 的重要性分值，决定节点大小和列表排序tags：字符串数组，最多 8 个标签lastUsedAt：最近被召回的时间usedCount：被召回次数metadata：扩展字段，保存来源会话、模型、抽取动作等
当模型抽取记忆时，输出包含这些结构化字段。服务端必须做兜底和校验：type 非法时改为 OTHER、importance 超范围时裁剪、tags 去重去空白最多保留 8 个。如果抽取失败，仍然保存正文并用默认字段（importance=50, type=OTHER）。
这些默认值的设计是为了降级优雅。即便结构化抽取失败，记忆也不会丢失，只是分类不精准——这是可以接受的，因为用户随后可以手动调整。
搜索、筛选与编辑
用户在表格上方有一个搜索框和类型筛选条。搜索时调用后端的语义搜索接口，命中的记忆在表格中高亮，并自动选中最高相关性的一条，打开右侧详情面板。语义搜索基于向量数据库的余弦相似度匹配——记忆文本被嵌入为 4096 维向量，查询时也转换为向量并与库内存储按相似度排序召回，只返回分值达到阈值（≥0.3）的结果。这样的匹配比关键词搜索精准度高，也支持语义近似的记忆关联（比如"TypeScript 后端"和"TS 服务端"会被认为相关）。搜索失败时保留当前星河状态并 toast 提示，不中断工作流。
筛选可以按五类过滤，清除筛选则回到全量视图。如果当前选中的记忆被筛选隐藏了，系统会自动选中可见记忆中最高重要性的那一条；如果没有可见记忆，则关闭详情面板显示空状态。
详情面板里，用户可以编辑标题、正文、类型、标签和重要性。编辑表单使用产品内设计，不弹浏览器原生弹窗。保存后立即更新列表和节点（如果有星河视图的话）。这样用户修改一条记忆时，不必刷新页面或等待后台同步，改动立刻可见。
删除是另一个关键能力。必须让用户能删除被错误标记的记忆，否则错误就成了永久污染源。删除按钮放在详情面板的危险操作区，点击后需确认。删除成功后，该条记忆从表格和星河中消失，列表自动选中下一条（如果有的话）。
星河与移动端降级
虽然主界面是表格，但在设计中保留了星河作为可视化补充。桌面端在表格下方或侧边可以显示一个小星图，让用户看到记忆的空间分布——核心记忆聚在中心，临时记忆分散在外围。星河上的节点与表格关联：点击表格行时，星河也高亮对应节点；点击星河节点时，表格定位到对应行。
但星河不是强制项。第一版的实现可能不包含完整星河，而是先确保表格工作台完整可用。星河可以作为后续的增强——用户如果觉得需要可视化辅助，才加上去。
移动端设计上，星河更是不现实（屏幕太小）。所以移动端完全降级为列表视图，点击列表项后通过底部抽屉显示详情和编辑表单。搜索和类型 tabs 放在顶部，保持核心交互可用。这样既避免了表格在手机上的横向溢出，也保证了可用性。
节点布局与稳定性
如果星河要实现，一个重要的设计细节是：节点位置必须稳定。即便刷新页面或重新打开应用，同一批记忆应该保持相同的位置，这样用户才能形成空间记忆——"核心记忆总在中心，临时的在右上角"。
这意味着节点位置不能是随机的实时布局，也不能用物理模拟（那会每次都算不同的位置）。用 createdAt 字段参与布局计算，保证确定性：同一条记忆的创建时间固定了，它在环形排列中的角度也就固定了。结合 importance 决定距离中心的远近，位置就完全由数据驱动，刷新后毫厘不差。
一致性与可维护性
这个设计的关键约束是一致性。如果记忆在表格中是 Amber-500（核心），那在星河、筛选、详情面板的边线上也必须是 Amber-500。任何拆散这个一致性的修改都会破坏用户的心智模型。
所以在设计系统里明确了这一点：新增或调整记忆类型视觉时，先更新设计文档里的语义色板和 memoryStyles.ts，再在各组件中引用，不允许组件各自复制色值。这样的约束看似严苛，但它保证了长期的可维护性——下次要改颜色时，只需改一个文件。
代价与权衡
这个设计的代价是什么？
第一，视觉冲击力比不上星河优先。表格是务实的设计，不够"黑科技"感。如果产品定位是"AI 记忆系统"要卖视觉冲击，这个方案会显得保守。
第二，星河的潜力没有完全释放。放弃了复杂的关系推理、自由漫游、力导向布局这些"高级"可视化特性，原因就是表格工作台不需要它们，而加上去反而添加复杂度。
第三，设计系统的维护成本提高了。一致性的要求意味着每次改动都要考虑全局影响。但这其实是长期收益——减少了 bug 和不一致的可能。
这些代价对 yun-claude 是可以接受的，因为当前用户还不多，重点是让产品可用，而不是炫技。如果将来用户规模上升，数百条甚至千条记忆的管理场景出现，表格 + 星河的混合界面可能不够，那时再考虑更激进的可视化方案。现在，信息工作台的优先级明确高于视觉体验。
■