> ## Documentation Index
> Fetch the complete documentation index at: https://docs.memorylake.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 记忆最佳实践

> 如何从会话、文档和 Agent 中获得准确、有用的长期记忆

MemoryLake 会自动提取记忆——您无需手工撰写。因此最佳实践的重点不在于*如何写*，而在于*如何把内容喂好*以及*如何让记忆保持诚实*。以下是有效的做法。

## 把内容喂好

### 重要的事实要说清楚

提取擅长捕捉明确的陈述和决策，也会恰当地跳过闲聊。当某件事必须被记住时，请把它直白地说出来：

* ✅ *"记住：Q1 的预算上限是 75K 美元，硬性限制。"*
* ✅ *"我们决定使用 PostgreSQL——JSON 支持更好，而且团队熟悉它。"*
* ⚠️ *"嗯，那就选第二个方案吧我觉得"*——指代含糊的表述提取效果差。请指名道姓。

### 不只说是什么，还要说为什么

带理由的决策比一个孤立的结论要有用得多。*"我们选择 PostgreSQL 而非 MySQL，是为了 JSON 支持和团队的经验积累"*，能让未来的助手回答\*"为什么用 Postgres？"*——而不只是*"用了哪个数据库？"\*

### 上传源文档，不要转述

如果知识存在于某个文件中，请上传该文件。文档内容的解析和索引保真度高于聊天中对它的摘要，而且从中提取的记忆会带有指向真实来源的溯源。

### 更正要说出口

当情况发生变化时，请明确说明——*"发布时间从 10 月 15 日改到了 11 月 1 日"*——而不是只在闲谈中顺带提到新日期。明确的更正会更新旧记忆或将其标为冲突，而不是让两个版本同时生效。

## 作用域划分：杠杆最高的决策

检索的作用域限定在项目内。项目划分得当意味着召回相关；一锅端的项目则意味着噪声。

* **一个上下文一个项目**——按客户、按项目、按生活领域划分。不要建一个巨大的"全部"项目。
* **多客户场景使用按 Agent 的配置**——OpenClaw 插件的按目录 `.memorylake/config.json` 会将每个工作目录固定到各自的项目，因此客户 A 的事实绝不会出现在客户 B 的会话中。参见[编码 Agent](/scenarios/coding-agents)。
* **检索变嘈杂时就拆分**——如果回答开始引用不相关的上下文，说明您的项目很可能覆盖了两个上下文。拆开它。

## 让记忆保持诚实

### 及时审核冲突

冲突是记忆的免疫系统——但前提是有人去消解它们。当助手对某条事实显得不确定时，以及在任何一轮集中更正之后，都请查看项目的**冲突**标签页。在团队中，要确保有人持有消解权限并把这件事当成习惯。

### 用溯源做审计

在相信一条意外的断言之前，先打开该记忆的**来源溯源**——您会清楚看到是哪段会话或哪份文档产生了它。这也是排查助手*为什么*相信某个错误结论的最快方式：找到记忆、溯源，然后编辑或遗忘它。

### 有意识地清理

* **编辑**细节已经偏移的记忆（标题、数字、名称）
* **遗忘**已过时或本就不该被捕获的记忆——删除是永久的，且在所有地方生效
* 不要过度清理：去重和合并已经处理了重复问题；因为*错误*而删除，而不是为了整齐

## 面向团队

* **明确什么该进共享记忆**——决策、政策、客户事实：该进。个人工作笔记：留在个人空间。工作空间边界就是个人记忆与组织记忆的分界线。
* **指派冲突负责人**——没有冲突消解者的项目会悄悄积累过时事实。
* **依靠权限，而不是自觉**——如果只有负责人可以删除记忆，那就从其他角色中移除 `mem_delete`，而不是依赖约定。参见[权限参考](/features/team-collaboration/permission-reference)。

## 面向开发者（API）

* **发送完整的会话轮次**给 add-memory（`infer: true`），让提取来决定什么值得长期保留——预先过滤通常会丢失有助于提升提取质量的上下文。
* **使用 `user_id`**，让记忆归属到正确的终端用户。
* 只有在原样存储一条已经整理好的事实时，才**设置 `infer: false`**。
* **向您的用户开放溯源和遗忘能力**——"你为什么知道这件事？"和"忘掉这个"既能建立信任，也能满足合规要求。
* 如果您的产品会断言事实，请**通过程序检查冲突**——参见[冲突 API](/features/memorylake/api-reference/memories/list-memory-conflicts)。

## 常见误区

| ❌ 误区           | ✅ 应该这样                 |
| -------------- | ---------------------- |
| 用一个巨大的项目装下所有内容 | 一个上下文一个项目；检索才能保持精准     |
| 把文档内容粘贴到聊天里    | 直接上传文档本身               |
| 隐晦地更正事实        | 明确说出更正，让旧记忆被更新或标为冲突    |
| 忽略冲突标签页        | 更正之后去审核；团队中要指派负责人      |
| 为了"清理"而删除记忆    | 只编辑或遗忘错误的内容——合并已经处理了重复 |
| 盲目相信一条奇怪的断言    | 先打开它的来源溯源              |

## 后续步骤

<CardGroup cols={2}>
  <Card title="记忆概览" icon="brain" href="/features/memorylake/memories/overview">
    深入了解提取、检索、溯源与冲突
  </Card>

  <Card title="场景" icon="map" href="/scenarios/personal-ai-memory">
    看这些实践如何端到端落地
  </Card>
</CardGroup>