1. 项目概述：长对话中的记忆管理难题与协同分页方案

如果你和我一样，长期在大型语言模型（LLM）的应用开发一线摸爬滚打，那你一定对“长上下文”又爱又恨。爱的是，它能处理更长的文档、进行更复杂的多轮对话；恨的是，随着对话轮次（我们称之为“对话轮次”）的增加，模型仿佛患上了“健忘症”，要么忘记开头的关键设定，要么在冗长的上下文中迷失方向，生成的内容开始偏离主题或前后矛盾。这背后，本质上是LLM固有的“有限上下文窗口”与人类期望的“无限记忆能力”之间的矛盾。

我最近在为一个客户构建一个复杂的AI客服原型时，就深陷这个泥潭。对话涉及产品咨询、故障排查、方案推荐等多个阶段，往往进行到第20轮以后，AI就开始混淆用户最初提到的产品型号，或者重复询问已经确认过的信息。这不仅仅是用户体验的灾难，更是技术可行性的挑战。我们尝试过各种“土办法”：定期总结对话、将关键信息提取成结构化数据、甚至粗暴地截断历史记录，但效果都不尽如人意，要么丢失了对话的连贯性和情感脉络，要么引入了额外的复杂性和延迟。

正是在这种背景下，“Cooperative Memory Paging with Keyword Bookmarks for Long-Horizon LLM Conversations”这个项目标题引起了我的强烈共鸣。它精准地戳中了当前LLM长对话应用的痛点。拆解来看，它包含了三个核心概念：Cooperative Memory Paging（协同内存分页）、Keyword Bookmarks（关键词书签）和Long-Horizon Conversations（长程对话）。这不像是一个简单的功能描述，更像是一个系统级的架构思路。它借鉴了操作系统内存管理的经典思想——分页，并将其与LLM的推理过程协同起来，再辅以“书签”这种人类友好的导航工具，旨在为LLM构建一个高效、可控的外部记忆系统。

简单来说，这个项目的目标不是无限扩大模型的上下文窗口（这在硬件和算法上成本极高），而是为模型装上一个智能的“外部大脑”。这个大脑能够像我们人类一样，记住对话的要点和脉络，在需要时快速“翻看笔记”，而不是试图把整本书都背下来。接下来，我将结合我的实践经验，深入拆解这个方案背后的设计思路、技术实现细节以及我们可能遇到的坑。

2. 核心设计思路：从操作系统分页到LLM记忆管理

2.1 灵感来源：操作系统的虚拟内存与分页机制

这个方案最巧妙的地方在于其跨学科的灵感借鉴。在计算机科学中，操作系统的虚拟内存和分页机制完美解决了“物理内存有限”与“程序需要大量内存”的矛盾。系统将程序使用的内存地址空间分割成固定大小的“页”，将当前活跃的“页”留在物理内存中，而将不活跃的“页”交换到磁盘上。当程序需要访问不在物理内存中的页时，会触发一个“缺页中断”，操作系统负责将所需的页从磁盘加载回内存。

将这个模型映射到LLM长对话场景：

• 物理内存（RAM）->模型的当前有效上下文窗口。这是模型能“直接看到”并进行推理的文本区域，大小固定（如128K tokens）。
• 虚拟内存地址空间->整个对话历史。这可能非常长，远超上下文窗口限制。
• 磁盘（硬盘）->外部记忆存储。可以是一个向量数据库、一个键值对存储，或者就是一个简单的文本文件。
• 页（Page）->对话片段或语义块。这是方案设计的关键，如何划分“页”直接决定了记忆管理的粒度。

2.2 “协同”的含义：LLM作为分页策略的决策者

在传统操作系统中，分页策略（如LRU最近最少使用）是预定义、硬编码的算法。但在我们的场景中，“Cooperative”一词是灵魂。它意味着LLM本身要参与到分页决策中来。

为什么必须协同？因为对话的记忆重要性不是均匀分布的，也无法用简单的“最近使用”规则来判定。一段在对话早期达成的共识（如“用户想买一台预算5000元以内的笔记本电脑”），其重要性可能贯穿整个对话，即使它很久没有被提及。而一段刚刚发生的寒暄（如“今天天气不错”），可能重要性很低。

因此，协同分页的核心思想是：让LLM在生成回复的同时，也对外部记忆系统的“换入”和“换出”提出建议或直接做出决策。这通常通过以下方式实现：

1. 识别重要性：在每轮对话结束时，让LLM分析当前轮次产生的新内容，判断哪些信息是“需要长期记住的”（如用户偏好、决策结果），哪些是“暂时性、可遗忘的”（如语气词、重复确认）。
2. 主动触发分页：当上下文窗口即将填满时，不是被动地丢弃最旧的信息，而是由LLM根据当前对话的焦点，主动从外部记忆中召回（换入）最相关的历史片段，同时决定将哪些当前上下文中的片段移出（换出）到外部存储。
3. 维护记忆索引：LLM需要帮助建立和维护一个高效的记忆索引，这正是“Keyword Bookmarks”发挥作用的地方。

2.3 关键词书签：为记忆建立可理解的索引

“书签”是一个极其用户友好（同时也是模型友好）的隐喻。想象一下，你读一本很厚的书，会在重要的概念、人物首次出现或关键结论处夹上书签，方便日后快速查找。

Keyword Bookmarks就是为长对话建立的这种索引。它的工作流程通常是：

1. 书签创建：在对话的某些关键节点（例如，话题转换、达成重要结论、用户提供核心需求时），系统（或协同的LLM）会提取一个或一组关键词或短语作为“书签”。例如，当用户说“我的主要需求是编程和偶尔玩《赛博朋克2077》”时，系统可能创建书签[核心需求: 编程， 3A游戏]。
2. 书签关联：这个书签会与创建时间点的对话片段（即一个“内存页”）紧密关联，并存储到外部记忆系统中。
3. 书签检索：当后续对话涉及到相关话题时（例如，用户开始询问显卡性能），系统可以根据当前查询，计算其与所有书签的语义相似度，快速定位到最相关的历史“页”，并将其“换入”上下文窗口。

书签的优势在于：

• 可解释性强：开发者和用户都能理解书签的含义，便于调试和监控记忆系统的行为。
• 检索效率高：相比用整个对话片段去做向量化检索，用简短的书签检索速度更快、成本更低。
• 聚焦核心：强迫系统在信息洪流中识别和标记出真正重要的内容，这是一种信息压缩和提纯。

注意：书签的生成质量至关重要。过于笼统的书签（如“电脑咨询”）会导致检索不准；过于细碎的书签又会造成索引膨胀。在实践中，我们通常会让LLM根据预设的指令来生成书签，例如：“请用3-5个最能代表当前对话转折点或核心信息的关键词或短语，为刚刚这段对话创建一个书签。”

3. 系统架构与核心组件实现

基于以上思路，我们可以勾勒出一个具体的系统架构。这个架构不依赖于某个特定的LLM服务商（如OpenAI或Anthropic），而是提供一种通用的设计模式。

3.1 整体架构图（概念描述）

整个系统可以看作是一个围绕LLM核心的增强型对话引擎，主要包括以下组件：

1. 对话上下文管理器：维护当前的“物理上下文”（即即将发送给LLM的Prompt）。它负责接收用户新消息，并决定最终的上下文构成。
2. 记忆分页调度器：这是系统的“大脑”。它接收来自上下文管理器的请求，依据策略决定是否需要从外部记忆换入数据，或向外部记忆换出数据。
3. 外部记忆存储：存储所有非活跃的对话“页”及其关联的书签。通常包含两部分：
   • 向量存储：用于存储对话片段的嵌入向量，支持基于语义的相似性检索。
   • 元数据/键值存储：存储书签文本、时间戳、对话轮次、片段长度等元信息。
4. 书签生成与检索器：在调度器的指挥下，负责在关键节点生成书签，以及在需要时根据当前对话语义检索最相关的书签和对应的对话页。
5. LLM核心：提供基础的文本生成和理解能力，同时通过特定的Prompt设计，使其具备“协同”能力，即输出对记忆管理的建议。

[用户输入] -> [对话上下文管理器] -> [记忆分页调度器] -> [组装最终Prompt] -> [LLM核心] ^ | | v | [书签生成与检索器] <-> [外部记忆存储] | | +----------------------[LLM回复（含记忆指令）]---------------------------+

3.2 关键数据结构定义

要实现这个系统，首先需要明确几个核心的数据结构。

对话页（Memory Page）：

class MemoryPage: def __init__(self): self.page_id: str = uuid.uuid4().hex # 唯一标识 self.content: str = "" # 该页存储的实际对话文本 self.tokens: int = 0 # 该页内容的token数量 self.start_turn: int = 0 # 起始对话轮次 self.end_turn: int = 0 # 结束对话轮次 self.bookmarks: List[Bookmark] = [] # 关联的书签列表 self.embedding: List[float] = None # 内容向量（可选，用于备用检索） self.last_accessed: float = time.time() # 最后访问时间（用于类LRU策略） self.importance_score: float = 0.5 # 重要性评分，由LLM协同生成

书签（Bookmark）：

class Bookmark: def __init__(self): self.keywords: List[str] = [] # 关键词列表，如 [“预算”， “编程”， “显卡”] self.description: str = "" # 可读的描述，如 “用户明确了预算上限和核心用途” self.created_at: float = time.time() self.source_page_id: str = "" # 关联的MemoryPage ID self.embedding: List[float] = None # 书签文本的向量，用于快速检索

上下文窗口状态（Context Window State）： 这个对象实时跟踪当前“物理内存”的使用情况。

class ContextWindowState: def __init__(self, max_tokens: int): self.max_tokens = max_tokens self.active_pages: List[MemoryPage] = [] # 当前在上下文中的页 self.current_tokens: int = 0 # 已使用的token数 # 其他用于调度策略的元数据...

3.3 协同分页调度算法详解

调度器是系统的核心。一个基础的协同调度算法流程如下：

1. 接收新消息：用户输入新消息U_new。
2. 检查容量：计算U_new+ 当前所有active_pages的token数 + 系统Prompt的token数。如果预计超出max_tokens，触发分页决策。
3. 决策换出（Eviction）：
   • 协同模式：将当前active_pages的元信息（如id、摘要、重要性评分）和U_new一起，构造一个特殊的Prompt给LLM。例如：“当前上下文中有以下对话片段[A,B,C]。新问题是‘...’。为了给新对话腾出空间，请根据新问题的相关性，对片段[A,B,C]进行排序，最不相关的排在前面。只输出排序后的片段ID列表。”
   • LLM返回排序：得到类似[C, A, B]的列表。这意味着C最不相关。
   • 执行换出：将C从active_pages移除，写回外部存储，并更新其last_accessed。
4. 决策换入（Retrieval）：
   • 基于书签检索：以U_new为查询，计算其与外部存储中所有书签向量的相似度。
   • 获取候选页：取出相似度最高的前K个书签关联的MemoryPage。
   • 协同过滤：同样，可以将候选页的摘要和U_new交给LLM判断：“新问题是‘...’。以下哪个历史片段对回答这个问题最有用？只输出最相关片段的ID。” 这可以避免向量检索的“语义漂移”问题。
   • 执行换入：将选中的页加入active_pages。
5. 组装最终上下文：将剩余的active_pages内容、换入的页内容、系统指令和U_new，按时间或逻辑顺序组装成最终的Prompt，发送给LLM生成回复。
6. 事后记忆更新：
   • 生成新页：将本轮完整的交互（用户输入+AI回复）作为一个新的MemoryPage暂存。
   • 评估并生成书签：使用LLM判断这个新页是否值得创建书签。Prompt如：“请判断以下对话是否包含需要长期记忆的关键信息（如用户偏好、重要决定、事实变更）。如果是，请生成2-4个关键词作为书签。如果否，输出‘NO’。” 如果得到关键词，则创建Bookmark并与新页关联，存入外部存储。

实操心得：在第三步的“协同换出”中，直接让LLM排序多个片段可能消耗较多token且不稳定。一个更高效的实践是让LLM进行“二元决策”。Prompt可以设计为：“当前上下文有片段[A]。新问题是[Q]。为了容纳新问题，是否可以将片段[A]移出上下文？请只回答‘是’或‘否’。” 然后遍历所有活跃页，将那些被标记为“是”的页移出。这降低了LLM的决策复杂度。

4. 实操部署与工程化挑战

理论很美好，但把这套系统跑起来，会遇到一系列工程上的“魔鬼细节”。下面我结合一个简化版的实现流程，谈谈关键步骤和避坑指南。

4.1 技术栈选型与搭建

一个可行的技术栈组合如下：

• LLM API：选择任何支持长上下文和function calling（或结构化输出）的模型，如GPT-4 Turbo、Claude 3系列。结构化输出对解析LLM的“协同指令”至关重要。
• 向量数据库：用于存储和检索书签向量。轻量级可选ChromaDB、FAISS，生产环境可以考虑Qdrant、Weaviate或Pinecone。
• 元数据存储：简单的场景可以用SQLite或Redis。复杂场景需要记录完整的对话图谱，可以用Neo4j这样的图数据库，但大多数情况下一个关系型数据库（PostgreSQL）足够了。
• 应用框架：FastAPI或LangChain。LangChain提供了很多记忆相关的抽象，但为了深度定制“协同分页”逻辑，我倾向于用FastAPI从头构建，控制感更强。

4.2 核心流程代码拆解

我们聚焦于最核心的“处理一轮对话”函数。

import asyncio from typing import List, Optional from your_llm_client import LLMClient from your_vector_store import VectorStore from your_metadata_store import MetadataStore class CooperativeMemorySystem: def __init__(self, llm_client: LLMClient, vector_store: VectorStore, meta_store: MetadataStore, ctx_window_size: int = 128000): self.llm = llm_client self.vector_store = vector_store self.meta_store = meta_store self.ctx_window = ContextWindowState(ctx_window_size) self.system_prompt = "你是一个有帮助的助手，并且拥有一个外部记忆系统。在回复时，如果需要记忆系统执行操作，请遵循指定格式。" async def process_turn(self, user_input: str, conversation_id: str) -> str: """处理一轮用户输入，返回AI回复""" # 1. 检查并执行分页（换出） await self._manage_context_size(user_input) # 2. 基于当前输入检索相关记忆（换入） relevant_pages = await self._retrieve_relevant_pages(user_input) for page in relevant_pages: if page.page_id not in [p.page_id for p in self.ctx_window.active_pages]: if self._can_add_page(page): self.ctx_window.active_pages.append(page) self.ctx_window.current_tokens += page.tokens # 3. 组装最终Prompt final_context = self._assemble_context(user_input) # 4. 调用LLM，获取包含可能“记忆指令”的回复 llm_response = await self.llm.chat_completion(final_context) # 5. 解析回复，提取显式的记忆操作指令（如果LLM被设计为可以输出指令） memory_ops = self._parse_memory_operations(llm_response) if memory_ops: await self._execute_memory_operations(memory_ops, conversation_id, user_input, llm_response) # 6. 将本轮交互创建为新页，并评估是否生成书签 new_page = await self._create_new_page(conversation_id, user_input, llm_response) await self._evaluate_and_create_bookmark(new_page) # 7. 返回纯文本回复给用户 return self._extract_final_response(llm_response) async def _manage_context_size(self, new_input: str): """协同分页：换出决策""" estimated_new_tokens = count_tokens(new_input) + 500 # 预留系统指令等token if self.ctx_window.current_tokens + estimated_new_tokens > self.ctx_window.max_tokens: # 需要腾出空间 pages_to_evict = [] for page in self.ctx_window.active_pages: # 协同决策：询问LLM该页是否可移出 decision_prompt = f""" 背景：你正在处理一个长对话。当前上下文包含一个历史片段： 片段内容：[{page.content[:500]}...] // 截取前500字符 用户的新问题是：{new_input} 问题：为了回答新问题，这个历史片段是必须保留在上下文中，还是可以暂时移出到外部记忆？ 请只回答一个词：必须保留 或 可以移出。 """ decision = await self.llm.chat_completion(decision_prompt) if "可以移出" in decision: pages_to_evict.append(page) # 如果已经腾出足够空间，可以提前终止循环 if self._will_have_enough_space_after_eviction(pages_to_evict, estimated_new_tokens): break # 执行换出 for page in pages_to_evict: await self._evict_page(page) async def _retrieve_relevant_pages(self, query: str) -> List[MemoryPage]: """基于书签检索相关页""" # 将查询向量化 query_embedding = await self.llm.get_embedding(query) # 从向量库检索相似书签 similar_bookmarks = await self.vector_store.search_similar(query_embedding, top_k=5) # 获取书签关联的页 page_ids = [bm.source_page_id for bm in similar_bookmarks] relevant_pages = await self.meta_store.get_pages_by_ids(page_ids) # 可选：协同过滤，让LLM从候选页中挑出最相关的1-2个 if len(relevant_pages) > 1: filtered_pages = await self._cooperative_filter(query, relevant_pages) return filtered_pages return relevant_pages async def _evaluate_and_create_bookmark(self, page: MemoryPage): """评估新页并生成书签""" evaluation_prompt = f""" 请评估以下对话轮次是否包含需要长期记忆的关键信息（如用户偏好、重要决定、任务目标变更、关键事实）。 对话内容： 用户：{page.user_part} 助手：{page.assistant_part} 如果包含，请提取2-4个核心关键词或短语作为记忆书签。 如果不包含，请输出“NO”。 输出格式：如果有关键信息，直接输出关键词，用逗号分隔。如果没有，输出NO。 """ result = await self.llm.chat_completion(evaluation_prompt) if result.strip() != "NO": keywords = [kw.strip() for kw in result.split(",")] bookmark = Bookmark(keywords=keywords, source_page_id=page.page_id) # 存储书签和其向量 bookmark.embedding = await self.llm.get_embedding(" ".join(keywords)) await self.vector_store.add_bookmark(bookmark) await self.meta_store.save_bookmark(bookmark)

4.3 性能优化与成本控制

这是一个计算密集型和API调用密集型的方案，必须考虑优化。

1. Token消耗与延迟：每一次“协同决策”都意味着额外的LLM API调用。这会显著增加成本和响应延迟。
   • 优化策略：
     • 批量决策：不要为每一个MemoryPage单独调用LLM做换出决策。可以将所有活跃页的摘要列表一次性发给LLM，让它选出N个最不相关的。
     • 设置阈值：不要每轮都进行完整的协同分页。可以设置一个“高水位线”（例如，上下文使用率达到85%）和“低水位线”（60%）。只有当超过高水位线时才触发换出，并且换出到低水位线就停止。这减少了不必要的操作。
     • 缓存决策：对于某些类型的对话片段（如问候语、确认语句），其“可移出性”是明确的。可以建立一个规则缓存，优先应用规则，规则无法判断时再求助LLM。
2. 向量检索的准确性：书签检索可能不准，导致换入了不相关的历史。
   • 优化策略：
     • 混合检索：结合关键词（书签）检索和语义（整个片段）检索。先用书签快速筛选，再用片段向量精排。
     • 重排序：将检索到的Top K个结果，再用一个更小、更快的模型（或交叉编码器）进行精排，提升相关性。
3. 记忆一致性与冲突：当同一个事实在不同轮次被更新时（如用户先说预算5000，后改为8000），系统需要能处理这种冲突。
   • 优化策略：
     • 版本化或时间戳：为每个MemoryPage存储创建时间。当检索到多个相关但信息可能冲突的页时，优先采用时间最新的。
     • 事实融合：在更复杂的系统中，可以引入一个“事实核查”或“信息融合”步骤，让LLM主动识别并解决冲突。

5. 评估方法与常见问题排查

如何判断你的协同分页系统是否真的有效，而不是增加了无谓的复杂性？以下是一些可量化的评估维度和常见问题。

5.1 核心评估指标

1. 对话一致性：设计多轮对话测试集，在关键节点故意询问之前提到过的信息（如“我一开始说的预算是多少？”）。计算模型回答正确的比例。
2. 上下文利用率：监控平均每轮对话中，从外部记忆换入的信息token数占总上下文token数的比例。这个比例在一个健康系统中应该保持在一个稳定、非零的水平，证明系统在动态利用历史。
3. 冗余度：检查模型是否因为记忆系统混乱而重复提问或重复提供相同信息。
4. 用户满意度：进行A/B测试，一组使用带记忆系统的智能体，另一组使用标准的有限上下文窗口智能体，收集用户的主观评分。
5. 成本与延迟：记录平均每轮对话的LLM总调用次数、总消耗token数和端到端响应时间。与基线（例如，简单的滑动窗口或定期总结）进行对比。

5.2 常见问题与排查清单

在实际部署中，你可能会遇到以下典型问题：

5.3 调试与监控建议

构建这样一个系统，强大的调试和监控能力是必须的。

1. 全链路日志：记录每一轮对话的完整状态，包括：用户输入、检索到的书签列表、换入/换出的页ID、组装后的Prompt（前N个token）、LLM的原始回复、生成的新书签。这些日志是排查问题的黄金资料。
2. 可视化仪表盘：开发一个简单的内部看板，实时展示：
   • 当前上下文窗口中的页及其摘要。
   • 外部记忆存储中的书签云图。
   • 最近N轮对话的检索命中率、token消耗趋势。
3. 回归测试集：建立一套标准的多轮对话测试用例，定期（例如每天）运行，确保核心的记忆保持能力没有因代码更新而退化。

6. 进阶思考与模式扩展

基本的协同分页系统搭建起来后，我们可以在此基础上探索更高级的模式，使其更智能、更高效。

6.1 从“分页”到“记忆图谱”

当前方案中，记忆页是相对独立的片段。更高级的模式是构建一个对话记忆图谱。在这个图谱中：

• 节点：可以是实体（人物、产品、概念）、事件（用户做出的决定）、主张（用户表达的观点）。
• 边：表示节点之间的关系，如“属于”、“导致”、“否定”、“更新”。
• 书签：可以升级为指向图谱中特定节点或子图的入口。

当需要检索时，系统不再仅仅是做向量相似性匹配，而是可以进行图谱查询。例如，用户问“我之前看中的那款电脑的显卡，和后来你推荐的相比怎么样？”，系统可以定位到“电脑A”和“电脑B”两个实体节点，以及它们各自的“显卡”属性边，然后自动组织对比信息换入上下文。这需要更复杂的NLP信息抽取和知识图谱构建技术，但代表了更结构化、更精准的记忆方向。

6.2 分层记忆与摘要链

另一种思路是引入分层记忆。将记忆分为几个层次：

• 工作记忆：即当前的上下文窗口，存放最相关、最活跃的对话内容。
• 短期记忆：外部存储中的原始对话“页”，保存了较近期的、较详细的交互记录。
• 长期记忆：通过对短期记忆的定期摘要和压缩形成的更凝练的知识。例如，每10轮对话，就用LLM生成一个阶段性摘要。这个摘要本身也可以被索引和检索。

这形成了“摘要链”模式。当对话进行到第50轮时，要回忆第5轮的内容，系统可能先检索到第1-10轮的摘要，发现相关后，再根据摘要中的指引，去短期记忆中定位具体的对话页。这大大降低了检索的复杂度和噪声。

6.3 用户显式记忆交互

“协同”不仅可以是与AI的协同，也可以是和用户的协同。我们可以提供简单的界面，让用户对记忆系统进行显式操作：

• 手动打书签：用户可以在对话中标记某条信息为“重要”，系统则强制为此创建高权重的书签。
• 记忆回顾与修正：用户可以询问“你都记住了什么？”，系统展示当前记忆的关键书签或摘要。用户可以说“关于预算的那条信息错了，应该是8000”，系统则能够修正对应的记忆节点。
• 记忆遗忘：用户可以要求“忘记我们刚才讨论的XX话题”，系统则可以将相关主题的记忆页标记为过期或删除。

这种设计将记忆系统从一个黑盒变成了一个用户可理解、可管理的工具，极大地提升了透明度和可控性。

在我自己的项目实践中，从最简单的滑动窗口，到定期总结，再到引入向量检索的简单记忆，最后到设计这种协同分页系统，每一步都伴随着对LLM能力边界和交互本质的更深理解。这套方案的核心价值不在于用了多炫酷的算法，而在于它承认了LLM的“记忆缺陷”，并以一种系统化的、人机协同的方式去弥补它。它不是一个一劳永逸的解决方案，而是一个需要精心调校的框架。你需要根据自己应用场景的对话特点（是开放闲聊还是任务导向？是信息查询还是创意生成？），去调整分页的粒度、书签生成的策略、协同决策的频率。

最深的体会是，平衡是关键：在记忆的完整性、检索的准确性、系统的响应速度和实现的复杂性之间找到那个最佳平衡点。开始时不妨从最简单的规则（如固定长度的滑动窗口+基于最后一句的向量检索）做起，逐步引入“协同”和“书签”这些更智能的元素，并通过扎实的评估和数据来驱动迭代。记住，一个好的记忆系统，应该像一位得力的助手，默默地在后台整理好所有的谈话要点，在你需要时，恰到好处地递上那张正确的便签，而不是在你思考时，不断地把整本笔记本摊开在你面前。