1. 从零理解 claude-mem它到底在解决什么问题第一次看到 claude-mem 这个名字很多人会以为它又是一个套壳的对话客户端。其实不是。claude-mem 的核心定位是给 AI 编程助手做一层“长期记忆”的外挂。你可以把它想象成给一个记忆力只有七秒的搭档配了一本随身笔记本——每次对话结束它把关键信息记下来下次开工前它先把笔记本翻一遍再开始干活。这件事为什么重要因为绝大多数 AI 编程工具都有一个通病上下文窗口是有限的会话是隔离的。你今天上午跟它讲清楚了项目用的是什么框架、数据库表结构长什么样、某个模块为什么不能用某个方案到了下午开一个新会话它全忘了。你又得从头解释一遍。一次两次还行次数多了人会烦效率会被拖垮。claude-mem 要解决的就是这个“重复交代背景”的痛点。它适合谁来用三类人收益最明显。第一类是长期维护同一个项目的独立开发者项目周期动辄几个月上下文反复丢失非常折磨人。第二类是团队里负责搭工具链的人需要让 AI 助手在多人协作场景下保持一致的认知。第三类是把 AI 助手当成日常主力工具的重度用户希望它能记住自己的编码习惯、命名偏好、常用命令。我先把话说在前面claude-mem 不是一个开箱即用的成品软件它更像一套“记忆层”的实现思路加配套脚本。你需要理解它的工作机制然后根据自己的工作流去配置。下面我会把它拆开从设计思路讲到落地细节尽量让不同基础的人都能照着做。2. 整体设计思路为什么是“记忆层”而不是“更大的上下文”2.1 上下文窗口不是万能解药很多人第一反应是既然 AI 会忘那就把上下文窗口做大不就行了这个思路有道理但有几个现实问题。第一成本。上下文越长每次请求消耗的 token 越多费用是线性甚至超线性增长的。你不可能每次对话都把整个项目的所有历史塞进去。第二噪声。上下文里塞的东西越多模型越容易被无关信息干扰。你只想让它改一个函数结果它被三个月前的一段废弃讨论带偏了这种情况我遇到过不止一次。第三时效。上下文窗口再大也是“会话级”的。会话一关什么都没了。它解决不了跨会话、跨天的记忆问题。所以 claude-mem 选择了一条更聪明的路不追求单次塞得多而是追求“该记的记住该取的取出来”。这就是记忆层的核心思想——把记忆从上下文里剥离出来做成一个独立的、可持久化的、可按需检索的存储。2.2 记忆层的三个核心动作claude-mem 的工作流可以概括成三个动作写入、存储、检索。写入是在对话过程中识别出“值得记住”的信息。不是所有内容都值得记。比如“你好”“帮我看看这个”这种寒暄和指令记了没意义。真正值得记的是项目用了什么技术栈、某个决策的原因、某个坑的解决方案、用户的偏好设置。存储是把这些信息结构化地保存下来。这里有个关键选择用纯文本还是用结构化数据纯文本简单但检索效率低结构化数据检索快但写入时需要做解析。claude-mem 通常采用“结构化元数据 原始文本”的混合方式兼顾两者。检索是在新会话开始时根据当前任务的相关性把最需要的记忆取出来注入到上下文里。这一步最考验设计因为取多了浪费 token取少了不够用。2.3 为什么不做成“全自动”我见过一些类似工具试图做到完全自动、无感。但实际用下来全自动往往意味着“记了一堆没用的”或者“该记的没记住”。claude-mem 的思路更务实它提供自动化的钩子但保留人工干预的入口。你可以手动标记“这条要记住”也可以手动清理“这条过时了”。这个取舍很重要。记忆这件事本质上是一个“信噪比”问题。全自动很难保证信噪比半自动反而更可靠。就像你记笔记重要的地方自己划重点比让机器猜你要记什么靠谱得多。3. 核心细节解析记忆是怎么被组织和调用的3.1 记忆的分类别把所有东西混在一起claude-mem 在实践中通常把记忆分成几类分开管理。这个分类不是强制的但分开之后检索效率会高很多。记忆类型内容举例生命周期检索优先级项目配置技术栈、目录结构、构建命令长期高决策记录为什么选 A 不选 B中期中问题方案某个报错的解决过程长期高用户偏好命名风格、注释习惯长期中临时上下文当前任务的中间状态短期低分开管理的好处是检索时可以先按类型过滤再按相关性排序。比如你开始一个新任务优先注入“项目配置”和“用户偏好”这两类几乎每次都用得上。“决策记录”和“问题方案”则按需检索。3.2 存储格式的选择JSON 还是 Markdown这是我在配置时纠结最久的一个点。两种格式各有优劣。JSON 的好处是结构化程序读取方便字段清晰。缺点是人工编辑不友好多行文本要转义看久了眼睛疼。Markdown 的好处是可读性强人工维护方便可以直接用编辑器打开改。缺点是解析需要额外处理字段边界不如 JSON 明确。我最后的方案是混合元数据用 JSON正文用 Markdown。每条记忆是一个目录里面有一个meta.json存类型、时间、标签、关联文件还有一个content.md存具体内容。这样程序读元数据做检索人读正文做维护各取所需。{ id: mem_20240115_001, type: decision, tags: [database, orm], created: 2024-01-15T10:30:00, related_files: [src/db/schema.ts], summary: 选择轻量 ORM 而非全功能 ORM 的原因 }对应的content.md就是自由格式的正文可以写清楚背景、选项对比、最终决定和理由。3.3 检索策略关键词还是向量检索这一步常见有两种做法关键词匹配和向量相似度。关键词匹配的优点是快、可控、不需要额外模型。缺点是同义词覆盖差你搜“数据库”可能匹配不到写着“DB”的记忆。向量检索的优点是语义理解好能匹配到意思相近但用词不同的内容。缺点是需要一个嵌入模型多一层依赖而且相似度阈值不好调。claude-mem 的常见实践是先用关键词做粗筛再用向量做精排。粗筛把候选集从几百条降到几十条精排再从几十条里挑出最相关的几条。这样既保证了速度又保证了质量。提示如果你不想引入嵌入模型纯关键词方案也能用但建议给每条记忆多打几个标签用标签来弥补同义词覆盖的不足。3.4 注入时机什么时候把记忆喂给模型记忆检索出来之后什么时候注入也有讲究。一种做法是会话开始时一次性注入。简单但可能注入了一堆当前任务用不上的东西。另一种做法是按需注入每次提问前根据问题检索一次。精准但增加了一次检索开销。我的经验是会话开始时注入“项目配置”和“用户偏好”这类通用记忆具体任务相关的记忆在任务开始时按需注入。这样兼顾了效率和精准度。通用记忆量不大常驻成本可接受任务记忆按需加载避免浪费。4. 实操过程从零搭一套可用的记忆系统4.1 环境准备与目录结构先规划目录。我建议把记忆库放在项目根目录下一个独立的文件夹里跟代码分开方便版本管理和备份。project-root/ ├── src/ ├── .claude-mem/ │ ├── memories/ │ │ ├── mem_001/ │ │ │ ├── meta.json │ │ │ └── content.md │ │ └── mem_002/ │ ├── index.json │ └── config.json └── ...index.json是全局索引存所有记忆的元数据摘要检索时先读它避免遍历所有目录。config.json存配置比如检索条数上限、注入策略等。4.2 写入记忆的触发方式写入有两种触发方式手动和自动。手动写入最简单你直接调用一个脚本把当前对话里值得记的内容写进去。适合重要决策、关键方案这种需要人工把关的内容。自动写入需要挂钩子。常见做法是在对话结束时用一个轻量模型对本次对话做一次摘要提取出候选记忆然后按规则过滤。规则可以包括长度阈值、是否包含特定关键词、是否涉及文件修改等。def extract_memories(conversation): summary summarize(conversation) candidates [] for item in summary: if item[type] in [decision, solution, preference]: if len(item[content]) 50: candidates.append(item) return candidates这段逻辑的意思是先摘要再按类型和长度过滤。类型过滤掉寒暄和指令长度过滤掉太短没信息量的内容。阈值 50 是我试出来的太短了没价值太长了摘要本身成本高。4.3 检索与注入的实现检索的核心是打分排序。我给每条记忆算一个分数分数由几部分组成类型权重、时间衰减、关键词匹配度、标签匹配度。def score_memory(memory, query, now): type_weight {config: 1.0, solution: 0.9, decision: 0.7, preference: 0.6} base type_weight.get(memory[type], 0.5) age_days (now - memory[created]).days decay 0.99 ** age_days keyword_score match_keywords(memory, query) tag_score match_tags(memory, query) return base * decay * (keyword_score tag_score 0.1)这里的0.99 ** age_days是时间衰减意思是每天衰减 1%。为什么是 1%因为记忆的价值衰减是缓慢的太快了会丢掉长期有用的信息太慢了会让过时信息一直占位。1% 对应大约 70 天衰减一半这个节奏我觉得比较合适。注入时取分数最高的 N 条N 默认设 5。为什么是 5因为再多的话注入的 token 量会明显上升而边际收益递减。5 条通常能覆盖大部分场景。4.4 记忆的更新与清理记忆不是写完就不管了。项目在变记忆也要跟着变。更新有两种情况一种是补充比如某个方案后来又踩了新坑追加到原记忆里另一种是覆盖比如技术栈换了旧记忆作废。清理则要定期做。我一般每个月过一遍把明显过时的删掉。也可以设自动规则比如超过 180 天且从未被检索到的记忆标记为待清理。注意清理前一定要备份。我有一次手滑删了一条关键决策记录后来排查问题时怎么都想不起来当初为什么那么设计只能重新推一遍浪费了大半天。5. 常见问题与排查技巧实录5.1 记忆检索不准怎么办这是最常见的问题。表现是明明记过但检索时没被取出来。排查思路分三步。第一步确认记忆确实写进去了去memories目录下找找有没有对应的条目。第二步确认索引更新了index.json里有没有这条。第三步手动跑一次检索看它的分数是多少为什么没进前 N。常见原因是标签打得太少或者关键词和查询用词差异太大。解决办法是补标签或者在写入时让摘要模型多生成几个同义关键词。5.2 注入的记忆干扰了当前任务有时候检索出来的记忆虽然相关但反而让模型跑偏了。比如你在改一个新模块它却一直引用旧模块的设计。这种情况通常是时间衰减没起作用或者类型权重设得不对。可以临时调低“决策记录”的权重让模型更关注当前上下文。另一个办法是给记忆加“作用域”字段标记它适用于哪个模块。检索时先按作用域过滤只取当前模块相关的。5.3 记忆库越来越大检索变慢记忆条数上千之后纯遍历检索会明显变慢。这时候需要建索引。最简单的索引是倒排索引关键词到记忆 ID 的映射。查询时先查倒排索引拿到候选集再对候选集打分。这样把 O(n) 的遍历降到 O(候选集大小)。如果还嫌慢可以上向量索引用近似最近邻算法。但大多数个人项目倒排索引就够了没必要上重型方案。5.4 多人协作时记忆冲突团队用的时候每个人的记忆库如果各自独立会出现认知不一致。A 记的方案和 B 记的方案可能矛盾。解决办法是记忆库纳入版本管理跟代码一起提交。冲突时像解决代码冲突一样解决记忆冲突。另外可以设一个“权威标记”标记哪些记忆是经过确认的哪些是个人草稿。问题可能原因解决方向检索不到标签少、用词差异补标签、加同义词注入干扰权重不当、无作用域调权重、加作用域检索变慢无索引、全遍历建倒排索引多人冲突库独立、无权威标记版本管理、权威标记6. 我踩过的坑和几条实用心得第一个坑是过度记录。刚开始我什么都想记结果记忆库里一堆废话检索时噪声很大。后来我定了个规矩只记“下次还会用到”的信息。判断标准很简单——如果这条信息只对当前这一次对话有用那就不记。第二个坑是忘记更新。有段时间我改用了新的构建工具但记忆里还写着旧的命令结果 AI 助手一直给我生成旧命令我还纳闷怎么不对。从那以后我养成了习惯每次改完项目配置顺手更新对应的记忆条目。第三个心得是摘要要短。每条记忆的摘要控制在 50 字以内正文可以长但摘要必须短。因为检索时先看摘要摘要太长反而影响判断。摘要就像书名正文才是内容。第四个心得是定期回顾。我每周会花十分钟翻一遍最近新增的记忆看看有没有记错的、记重复的。这个习惯帮我省了很多后续排查的时间。最后说一个我觉得最有价值的技巧给记忆加“反例”字段。比如你记了“用方案 A”同时记一句“不要用方案 B因为……”。这样模型不仅知道该怎么做还知道不该怎么做生成结果会更稳。这个字段是我自己加的用下来效果很好推荐你也试试。 1. 从零理解 claude-mem它到底在解决什么问题第一次看到 claude-mem 这个名字很多人会以为它又是一个套壳的对话客户端。其实不是。claude-mem 的核心定位是给 AI 编程助手做一层“长期记忆”的外挂。你可以把它想象成给一个记忆力只有七秒的搭档配了一本随身笔记本——每次对话结束它把关键信息记下来下次开工前它先把笔记本翻一遍再开始干活。这件事为什么重要因为绝大多数 AI 编程工具都有一个通病上下文窗口是有限的会话是隔离的。你今天上午跟它讲清楚了项目用的是什么框架、数据库表结构长什么样、某个模块为什么不能用某个方案到了下午开一个新会话它全忘了。你又得从头解释一遍。一次两次还行次数多了人会烦效率会被拖垮。claude-mem 要解决的就是这个“重复交代背景”的痛点。它适合谁来用三类人收益最明显。第一类是长期维护同一个项目的独立开发者项目周期动辄几个月上下文反复丢失非常折磨人。第二类是团队里负责搭工具链的人需要让 AI 助手在多人协作场景下保持一致的认知。第三类是把 AI 助手当成日常主力工具的重度用户希望它能记住自己的编码习惯、命名偏好、常用命令。我先把话说在前面claude-mem 不是一个开箱即用的成品软件它更像一套“记忆层”的实现思路加配套脚本。你需要理解它的工作机制然后根据自己的工作流去配置。下面我会把它拆开从设计思路讲到落地细节尽量让不同基础的人都能照着做。2. 整体设计思路为什么是“记忆层”而不是“更大的上下文”2.1 上下文窗口不是万能解药很多人第一反应是既然 AI 会忘那就把上下文窗口做大不就行了这个思路有道理但有几个现实问题。第一成本。上下文越长每次请求消耗的 token 越多费用是线性甚至超线性增长的。你不可能每次对话都把整个项目的所有历史塞进去。第二噪声。上下文里塞的东西越多模型越容易被无关信息干扰。你只想让它改一个函数结果它被三个月前的一段废弃讨论带偏了这种情况我遇到过不止一次。第三时效。上下文窗口再大也是“会话级”的。会话一关什么都没了。它解决不了跨会话、跨天的记忆问题。所以 claude-mem 选择了一条更聪明的路不追求单次塞得多而是追求“该记的记住该取的取出来”。这就是记忆层的核心思想——把记忆从上下文里剥离出来做成一个独立的、可持久化的、可按需检索的存储。2.2 记忆层的三个核心动作claude-mem 的工作流可以概括成三个动作写入、存储、检索。写入是在对话过程中识别出“值得记住”的信息。不是所有内容都值得记。比如“你好”“帮我看看这个”这种寒暄和指令记了没意义。真正值得记的是项目用了什么技术栈、某个决策的原因、某个坑的解决方案、用户的偏好设置。存储是把这些信息结构化地保存下来。这里有个关键选择用纯文本还是用结构化数据纯文本简单但检索效率低结构化数据检索快但写入时需要做解析。claude-mem 通常采用“结构化元数据 原始文本”的混合方式兼顾两者。检索是在新会话开始时根据当前任务的相关性把最需要的记忆取出来注入到上下文里。这一步最考验设计因为取多了浪费 token取少了不够用。2.3 为什么不做成“全自动”我见过一些类似工具试图做到完全自动、无感。但实际用下来全自动往往意味着“记了一堆没用的”或者“该记的没记住”。claude-mem 的思路更务实它提供自动化的钩子但保留人工干预的入口。你可以手动标记“这条要记住”也可以手动清理“这条过时了”。这个取舍很重要。记忆这件事本质上是一个“信噪比”问题。全自动很难保证信噪比半自动反而更可靠。就像你记笔记重要的地方自己划重点比让机器猜你要记什么靠谱得多。3. 核心细节解析记忆是怎么被组织和调用的3.1 记忆的分类别把所有东西混在一起claude-mem 在实践中通常把记忆分成几类分开管理。这个分类不是强制的但分开之后检索效率会高很多。记忆类型内容举例生命周期检索优先级项目配置技术栈、目录结构、构建命令长期高决策记录为什么选 A 不选 B中期中问题方案某个报错的解决过程长期高用户偏好命名风格、注释习惯长期中临时上下文当前任务的中间状态短期低分开管理的好处是检索时可以先按类型过滤再按相关性排序。比如你开始一个新任务优先注入“项目配置”和“用户偏好”这两类几乎每次都用得上。“决策记录”和“问题方案”则按需检索。3.2 存储格式的选择JSON 还是 Markdown这是我在配置时纠结最久的一个点。两种格式各有优劣。JSON 的好处是结构化程序读取方便字段清晰。缺点是人工编辑不友好多行文本要转义看久了眼睛疼。Markdown 的好处是可读性强人工维护方便可以直接用编辑器打开改。缺点是解析需要额外处理字段边界不如 JSON 明确。我最后的方案是混合元数据用 JSON正文用 Markdown。每条记忆是一个目录里面有一个meta.json存类型、时间、标签、关联文件还有一个content.md存具体内容。这样程序读元数据做检索人读正文做维护各取所需。{ id: mem_20240115_001, type: decision, tags: [database, orm], created: 2024-01-15T10:30:00, related_files: [src/db/schema.ts], summary: 选择轻量 ORM 而非全功能 ORM 的原因 }对应的content.md就是自由格式的正文可以写清楚背景、选项对比、最终决定和理由。3.3 检索策略关键词还是向量检索这一步常见有两种做法关键词匹配和向量相似度。关键词匹配的优点是快、可控、不需要额外模型。缺点是同义词覆盖差你搜“数据库”可能匹配不到写着“DB”的记忆。向量检索的优点是语义理解好能匹配到意思相近但用词不同的内容。缺点是需要一个嵌入模型多一层依赖而且相似度阈值不好调。claude-mem 的常见实践是先用关键词做粗筛再用向量做精排。粗筛把候选集从几百条降到几十条精排再从几十条里挑出最相关的几条。这样既保证了速度又保证了质量。提示如果你不想引入嵌入模型纯关键词方案也能用但建议给每条记忆多打几个标签用标签来弥补同义词覆盖的不足。3.4 注入时机什么时候把记忆喂给模型记忆检索出来之后什么时候注入也有讲究。一种做法是会话开始时一次性注入。简单但可能注入了一堆当前任务用不上的东西。另一种做法是按需注入每次提问前根据问题检索一次。精准但增加了一次检索开销。我的经验是会话开始时注入“项目配置”和“用户偏好”这类通用记忆具体任务相关的记忆在任务开始时按需注入。这样兼顾了效率和精准度。通用记忆量不大常驻成本可接受任务记忆按需加载避免浪费。4. 实操过程从零搭一套可用的记忆系统4.1 环境准备与目录结构先规划目录。我建议把记忆库放在项目根目录下一个独立的文件夹里跟代码分开方便版本管理和备份。project-root/ ├── src/ ├── .claude-mem/ │ ├── memories/ │ │ ├── mem_001/ │ │ │ ├── meta.json │ │ │ └── content.md │ │ └── mem_002/ │ ├── index.json │ └── config.json └── ...index.json是全局索引存所有记忆的元数据摘要检索时先读它避免遍历所有目录。config.json存配置比如检索条数上限、注入策略等。4.2 写入记忆的触发方式写入有两种触发方式手动和自动。手动写入最简单你直接调用一个脚本把当前对话里值得记的内容写进去。适合重要决策、关键方案这种需要人工把关的内容。自动写入需要挂钩子。常见做法是在对话结束时用一个轻量模型对本次对话做一次摘要提取出候选记忆然后按规则过滤。规则可以包括长度阈值、是否包含特定关键词、是否涉及文件修改等。def extract_memories(conversation): summary summarize(conversation) candidates [] for item in summary: if item[type] in [decision, solution, preference]: if len(item[content]) 50: candidates.append(item) return candidates这段逻辑的意思是先摘要再按类型和长度过滤。类型过滤掉寒暄和指令长度过滤掉太短没信息量的内容。阈值 50 是我试出来的太短了没价值太长了摘要本身成本高。4.3 检索与注入的实现检索的核心是打分排序。我给每条记忆算一个分数分数由几部分组成类型权重、时间衰减、关键词匹配度、标签匹配度。def score_memory(memory, query, now): type_weight {config: 1.0, solution: 0.9, decision: 0.7, preference: 0.6} base type_weight.get(memory[type], 0.5) age_days (now - memory[created]).days decay 0.99 ** age_days keyword_score match_keywords(memory, query) tag_score match_tags(memory, query) return base * decay * (keyword_score tag_score 0.1)这里的0.99 ** age_days是时间衰减意思是每天衰减 1%。为什么是 1%因为记忆的价值衰减是缓慢的太快了会丢掉长期有用的信息太慢了会让过时信息一直占位。1% 对应大约 70 天衰减一半这个节奏我觉得比较合适。注入时取分数最高的 N 条N 默认设 5。为什么是 5因为再多的话注入的 token 量会明显上升而边际收益递减。5 条通常能覆盖大部分场景。4.4 记忆的更新与清理记忆不是写完就不管了。项目在变记忆也要跟着变。更新有两种情况一种是补充比如某个方案后来又踩了新坑追加到原记忆里另一种是覆盖比如技术栈换了旧记忆作废。清理则要定期做。我一般每个月过一遍把明显过时的删掉。也可以设自动规则比如超过 180 天且从未被检索到的记忆标记为待清理。注意清理前一定要备份。我有一次手滑删了一条关键决策记录后来排查问题时怎么都想不起来当初为什么那么设计只能重新推一遍浪费了大半天。5. 常见问题与排查技巧实录5.1 记忆检索不准怎么办这是最常见的问题。表现是明明记过但检索时没被取出来。排查思路分三步。第一步确认记忆确实写进去了去memories目录下找找有没有对应的条目。第二步确认索引更新了index.json里有没有这条。第三步手动跑一次检索看它的分数是多少为什么没进前 N。常见原因是标签打得太少或者关键词和查询用词差异太大。解决办法是补标签或者在写入时让摘要模型多生成几个同义关键词。5.2 注入的记忆干扰了当前任务有时候检索出来的记忆虽然相关但反而让模型跑偏了。比如你在改一个新模块它却一直引用旧模块的设计。这种情况通常是时间衰减没起作用或者类型权重设得不对。可以临时调低“决策记录”的权重让模型更关注当前上下文。另一个办法是给记忆加“作用域”字段标记它适用于哪个模块。检索时先按作用域过滤只取当前模块相关的。5.3 记忆库越来越大检索变慢记忆条数上千之后纯遍历检索会明显变慢。这时候需要建索引。最简单的索引是倒排索引关键词到记忆 ID 的映射。查询时先查倒排索引拿到候选集再对候选集打分。这样把 O(n) 的遍历降到 O(候选集大小)。如果还嫌慢可以上向量索引用近似最近邻算法。但大多数个人项目倒排索引就够了没必要上重型方案。5.4 多人协作时记忆冲突团队用的时候每个人的记忆库如果各自独立会出现认知不一致。A 记的方案和 B 记的方案可能矛盾。解决办法是记忆库纳入版本管理跟代码一起提交。冲突时像解决代码冲突一样解决记忆冲突。另外可以设一个“权威标记”标记哪些记忆是经过确认的哪些是个人草稿。问题可能原因解决方向检索不到标签少、用词差异补标签、加同义词注入干扰权重不当、无作用域调权重、加作用域检索变慢无索引、全遍历建倒排索引多人冲突库独立、无权威标记版本管理、权威标记6. 我踩过的坑和几条实用心得第一个坑是过度记录。刚开始我什么都想记结果记忆库里一堆废话检索时噪声很大。后来我定了个规矩只记“下次还会用到”的信息。判断标准很简单——如果这条信息只对当前这一次对话有用那就不记。第二个坑是忘记更新。有段时间我改用了新的构建工具但记忆里还写着旧的命令结果 AI 助手一直给我生成旧命令我还纳闷怎么不对。从那以后我养成了习惯每次改完项目配置顺手更新对应的记忆条目。第三个心得是摘要要短。每条记忆的摘要控制在 50 字以内正文可以长但摘要必须短。因为检索时先看摘要摘要太长反而影响判断。摘要就像书名正文才是内容。第四个心得是定期回顾。我每周会花十分钟翻一遍最近新增的记忆看看有没有记错的、记重复的。这个习惯帮我省了很多后续排查的时间。最后说一个我觉得最有价值的技巧给记忆加“反例”字段。比如你记了“用方案 A”同时记一句“不要用方案 B因为……”。这样模型不仅知道该怎么做还知道不该怎么做生成结果会更稳。这个字段是我自己加的用下来效果很好推荐你也试试。