claude-mem：给Claude API加跨会话长期记忆的开源工具

写个给Claude加记忆的开源小工具：claude-mem。最近在折腾AI Agent工作流时，我发现一个很绕不过去的痛点：Claude每次对话都是“无状态”的，它不记得你上次说过什么。你告诉过它的偏好、项目背景、代码规范，换个会话就全忘光了。这就像跟一个专业能力极强但瞬间失忆的专家共事，每聊一次都要重新自我介绍。claude-mem就是为解决这个问题而生的，我给这套工具跑了一个多月，今天把完整的拆解思路、部署细节和踩坑记录都整理出来。

整个工具解决三类人的麻烦：一类是重度使用Claude API做应用的开发者，需要让AI记住用户偏好和长期上下文；一类是日常用Claude协助写代码、写文档的从业者，想让对话体验具备“延续性”；还有一类是想把Claude接入自动化工作流的折腾党，需要跨会话保持状态。下文所有内容基于我实际部署和二次开发的经验，不是官方文档复读，想直接抄作业的可以重点看第三章的部署步骤和第四章的排错清单。

1. 项目定位与整体设计思路

1.1 Claude API的“健忘”困局

用过Claude API的人都有体会：当你创建一个新的对话请求，它不会记得之前会话里共享过的任何信息。即便你昨天刚跟它敲定了某个项目的数据库表结构，今天新开会话说起同一个项目，它依然一脸茫然。这是大模型API的基本工作方式，每次请求都是独立推理，服务端不保存对话历史。

实际开发中，为了让AI表现得有“记忆”，大家通常是把历史对话摘要、用户资料等手动拼进system prompt里。但这么做有几个问题：一是摘要写长了就挤占上下文窗口，写短了又丢失关键信息；二是这些记忆散落在各个业务代码里，没有统一的管理机制；三是人工整理记忆非常低效，项目一多根本维护不过来。

claude-mem这一类工具的定位，就是把“帮助AI记住该记的东西”这件事自动化：在对话过程中自动提取值得长期保存的信息，落地成结构化的记忆文件，在下次会话开始前把相关的记忆重新注入上下文。整个过程对用户基本无感，但对话体验却从“每次都重新认识你”变成了“像老朋友一样接着聊”。

1.2 它怎么做到“记住”这件事

先拆解核心链路，任何记忆增强工具都绕不开四个环节：提取、存储、检索、注入。

提取说的是怎么从对话里找出值得记住的信息。不能把什么都存，那会很快把记忆库撑爆。生存周期长的、对后续对话有高复用价值的信息才值得留：用户偏好、项目背景、技术决策、代码规范、个人身份信息等。claude-mem常用的做法是调用模型本身做一次结构化抽取，让它把对话内容转成一二条高度浓缩的记忆条目。

存储环节解决“记在哪里”的问题。本地文件是最直接的方案，比如JSONL格式逐条追加，或者按日期/项目目录分片存放。好处是透明、可审查、便于二次加工；坏处是数据量大了之后检索效率下降。大多数这类工具初期都用文件存储，跑一段时间再升级到SQLite或者向量数据库。

检索是最见功力的部分。单纯的全文搜索不够聪明，因为用户不会用完全一样的词去描述同一件事。成熟点的实现会用Embedding把记忆条目向量化，查询时把用户的当前问题也向量化，然后取余弦相似度最高的若干条。有的简化实现则用关键词标签做过滤，把候选集缩小后再做排序。

注入环节决定检索出来的记忆如何“进”对话。最常见的方案是把命中的记忆统一拼进system prompt，要求模型在回答时优先参考这些内容。注入量需要控制，一般限制在上下文窗口的10%~20%，太多会稀释模型对本次请求的注意力。部分实现还支持按记忆的重要性排序，只注入最高优先级的那几条。

1.3 工具选型时的关键权衡

我在评估同类工具时，最看重的五个维度是：提取准确率、检索召回率、上下文占用率、多项目隔离能力、自定义扩展空间。你可以在README或者配置示例里看到这些工具在文档中着重描述哪几项，通常那就是它们的差异化优势。

如果你熟悉LangChain或者LlamaIndex里的Memory模块，可能会问：claude-mem和它们有什么区别？简单说，框架内置的Memory通常是运行时内存态的短期记忆，进程重启就丢；而claude-mem这类工具沉淀的是跨进程、跨会话的长期记忆，相当于给Agent配了一个持续累积的“外置大脑”。从架构角度讲，长期记忆准确的落地形态，就是一个独立的记忆服务，不随主应用的生命周期起落。

我当时选择自建这套方案而不是直接用现成框架的Memory模块，核心原因是可观测性。我想随时打开记忆文件看到它到底记了什么、把哪些内容错误地抽象化了。文件型存储天然具备这种透明性，这也是我后续排查问题的最大抓手。

2. 核心机制深度拆解

2.1 记忆提取：如何从对话中筛出“值得记”的内容

记忆提取是整套机制里最容易翻车的一环。模型往往高估一段对话的价值，把一次性的闲聊当成了长期偏好来记。我实测下来，几类信息是高价值记忆的主流：

第一类是身份与偏好类。比如“我是移动端开发工程师”、“我的项目用Python 3.11”、“我倾向函数式写法”这些话，属于典型的长期稳定信息，对话中只要出现一次，后面大概率还会用到。第二类是项目约束类，像“数据库必须用PostgreSQL”、“API统一走/api/v2前缀”、“禁止用全局变量”这类，直接决定后续所有代码生成的质量，漏记损失很大。第三类是决策记录类，比如“优化性能优先于可读性”、“采用增量迁移而非全量重建”这类带着理由的结论，在后续讨论中如果被翻旧账，模型能给出有依据的解释。

我的方案是让模型在每轮关键节点做出一次“是否值得记住”的二值判断，而不是每一句话都跑一遍抽取。触发时机一般在用户给出明确指令、提供背景信息、或者对之前的回答做出纠正时。判断逻辑用一条结构化指令模板：如果本条消息包含可供未来会话长期参考的事实性信息，且与当前项目的核心上下文相关，则输出为一条记忆；否则输出为空。

实践中容易踩的坑是模型把“情绪反馈”也记进去。比如用户说“这段代码太烂了”，这是对当前内容的评价，不是对该用户代码风格的稳定描述。如果提取阶段不加以甄别，记忆库里会堆满噪声，严重拉低后续检索的命中率。我后面在提取提示词里强行加了一条规则：“只抽取不受单次对话情绪影响的客观事实与偏好”，效果改善明显。

2.2 记忆存储：本地文件方案与结构化设计

存储设计决定了记忆的透明度和扩展性。我用的方案是分层目录加JSONL文件：每个项目一个目录，项目的记忆按时间追加到一个JSONL文件里，每条记录包含以下核心字段：

{ "id": "mem_8f3k2d", "project": "my-blog", "content": "用户偏好使用灰色系配色，强调内容可读性", "category": "preference", "importance": 0.85, "created_at": "2025-06-11T14:22:31+08:00", "last_access_at": "2025-06-12T09:10:02+08:00", "access_count": 3, "source_message_id": "msg_01hx..." }

字段里最关键的是importance和category。importance是0到1的浮点数，代表这条记忆的重要程度，排序时权重很高；category取枚举值：identity、preference、project、decision、technical、user_fact等，方便按类型做筛选。

为什么用JSONL而不是单个JSON数组？因为JSONL天然支持追加写，一行一条记录，磁盘I/O友好，出问题时还能按行定位。处理大规模记忆时也不用手动做分片合并，直接按文件大小做轮转，超了就新开一个文件。我设置了单条内容长度上限为300字符，超过就要求模型压缩后再写入，防止一条超长记忆占据过多检索权重。

需要特别提醒的是，created_at和source_message_id这两个看似不起眼的字段，实际排查问题时作用极大。比如某条错误记忆导致模型反复输出错误方案，你能顺着source_message_id找到是哪轮对话产生了它，再回溯原始上下文，判断是提取错了还是对话本身就误导了模型。

2.3 记忆检索：向量相似度与关键词过滤的配合

检索是决定记忆能不能用起来的关键。刚开始我用的是纯关键词匹配，也就是把记忆条目分词后建倒排索引，按搜索词命中次数排序。效果怎么说呢，能用，但很粗糙。用户问“上次说的那个API鉴权方案”，记忆库里存的是“接口认证使用JWT”，这两句话没有一个字重叠，纯关键词检索直接漏召回。

后来我跑了Embedding模型做语义检索，把每条记忆转成向量，查询时也转成向量，再算余弦相似度。效果确实好了一个档次，同义表述能正确关联，但代价是多了模型推理开销和向量存储。折中方案是两层召回：先用关键词过滤拉出一个宽候选集，再用向量相似度做精排序。这样既保住了运行速度，又避免了纯关键词的漏召回问题。

对于跑在本地的小体量记忆库（万条以下），直接用向量检索也行，一次性加载到内存也就几MB的量。如果记忆库膨胀到十万条以上，就必须引入向量数据库了。常见的选择是SQLite加sqlite-vss插件，或者干脆上Chroma这种外部服务。我的经验是前期别上太重的依赖，文件加内存向量检索足够撑过第一版，等数据量真实起来再迁移也不迟。

检索结果的剪裁同样重要。一次查询可能召回几十条记忆，但注入上下文的总预算只有两千字。需要按两个维度做筛选：一是时间衰减，太久没有访问的记忆适当降权；二是重要性权重，importance高的优先保留。最终注入量控制在检索命中的前10条以内，超出部分宁可舍弃也不要硬塞。

2.4 记忆注入：如何让它“变成”模型的一部分

记忆注入做不好，会惹出大麻烦。最浅显的错误是把检索到的记忆一股脑堆在system prompt末尾，模型确实能看到，但它并不知道这些记忆和当前问题的关联度。尤其当记忆内容与当前对话发生冲突时，模型会陷入混乱，甚至前后矛盾。

我采用的做法是给记忆包一层“临时知识”的结构化描述，示例格式如下：

你正在与用户对话。以下是你在历史会话中了解到的关于此用户/项目的信息，你可以参考但不必在回复中复述： [1] (身份) 用户是全栈工程师，前端React，后端Go [2] (偏好) 用户偏好Table驱动的测试风格 [3] (决策) 项目日期格式化统一使用UTC时间存储，展示层再转换当地时间

这层结构让模型清楚认知到“这些是额外的参考资料”，而不是当前指令的一部分，最大程度减少记忆对指令遵循度的干扰。测试下来，有这层包装和没有，模型在长对话末尾的指令连贯性有明显差别。

注入时机也分两种：一种是在每轮请求前都做检索注入，适合记忆实时性要求高的场景；另一种是只在开场时注入一次，后续对话不再检索。前者体验更顺滑，但请求链路变长；后者省资源，但对中途出现的关联话题无能为力。追求极致体验的做法是做个轻量判断：在当前消息里出现记忆库中某个高权重关键词时才触发补充检索。这个优化留给想深挖的同学。

3. 实操部署与应用配置

3.1 安装与环境准备

部署claude-mem这类工具的第一步，是准备好一套干净的环境。我的运行环境是macOS + Node.js 18.16 + Python 3.11，两边都有依赖：Node端主要负责与Claude交互和文件IO，Python端负责跑Embedding模型。如果只用纯关键词检索，Python端可以省掉，但建议还是配上，后面语义检索迟早用得上。

# 拉取代码并安装依赖 git clone https://github.com/your-repo/claude-mem.git cd claude-mem npm install # 配置环境变量 cp .env.example .env # 编辑 .env，填入ANTHROPIC_API_KEY，并指定记忆存储根目录

ANTHROPIC_API_KEY从Anthropic控制台获取，注意环境变量里别写死版本号，因为SDK升级频繁，写死容易在后续更新时报错。记忆存储根目录我建议放在~/.claude-mem/下，权限设为700，因为里面存的是用户对话的提炼信息，涉及隐私的几率不低。

工作目录准备好后，跑一下自检命令看看核心依赖是否都装好了：

node claude-mem --doctor

--doctor命令会依次检查API Key是否有效、记忆目录是否可写、Embedding模型是否能正常加载。这一步全绿了再往下走，不然调试的时候容易漏排查。

3.2 配置项详解与推荐参数

配置文件里最有讲究的几项：MEMORY_EXTRACT_TRIGGER、MEMORY_MAX_ITEMS_PER_SESSION、MEMORY_INJECT_LIMIT、MEMORY_CHUNK_SIZE。

MEMORY_EXTRACT_TRIGGER控制什么时机触发记忆提取。推荐设为both：用户消息和助手回复都检查，用户消息侧重提取偏好和事实，助手回复侧重提取确认过的决策和约定。设为user_only会漏掉模型在回复中主动确认的重要信息。

MEMORY_MAX_ITEMS_PER_SESSION限制单次会话最多写多少条记忆。设太大会让存储疯涨，设太小又记不住东西。我的建议是8~12条，按一次深度对话产出的有效信息量来看，10条已经非常充裕。

MEMORY_INJECT_LIMIT决定每次注入几条记忆。结合上下文窗口，推荐值3~8条。超过8条，模型处理长上下文的能力会明显下降，尤其在配合工具调用的时候。可参考以下标定表：

MEMORY_CHUNK_SIZE控制单条记忆最大长度。推荐设为200~300字符，太长会挤占注入预算，太短又丢了细节。模型提取时如果发现内容超过上限，要强制改写压缩，而不是截断，截断会切断关键语义。

3.3 与Claude API的集成接入方式

部署完独立命令行还不够，真正要把记忆用起来，还得把它和你的Claude调用链路串起来。最通用的接入方式是在你的API封装层加一个中间件：请求发出前先查记忆、做注入，拿到响应后再扫记忆、做提取。

import { ClaudeMem } from "claude-mem"; const claudeMem = new ClaudeMem({ projectDir: "~/dev/projects/my-blog", injectLimit: 5 }); async function chatWithMemory(messages: Message[]) { // 1. 检索：把当前问题转成查询，拿到相关记忆 const memoryContext = await claudeMem.retrieve(messages[messages.length - 1].content); // 2. 注入：将记忆追加到系统消息 const fullMessages = [ { role: "system", content: buildSystemPrompt(memoryContext) }, ...messages ]; // 3. 改写：调用Claude API const response = await claudeClient.createMessage(fullMessages); // 4. 提取：把新产生的值得记住的信息写入记忆库 await claudeMem.remember(messages, response); return response; }

这个封装逻辑看起来直白，但有几个细节值得强调。检索时传入的查询内容不能是整个消息数组，否则查询文本过长会稀释向量语义；只取最后一条用户消息就够了。remember方法里的messages参数也不能传全部历史消息，传太长会消耗大量token做提取，传当前这次新增的用户消息和助手回复即可。

对于用Claude Code命令行工具的场景，集成的层级略有不同：Claude Code本身没有暴露官方的记忆注入API，通用的做法是配置hooks，在PreToolUse或PostToolUse时机执行自定义脚本，脚本内部调用claude-mem的CLI接口做检索或写入。这种转发方式能跑通，但命令执行有延迟，整体链路会比纯API集成多出几百毫秒。实测在可接受范围内。

3.4 真实场景跑一轮：从配置到生效

看具体操作更直观。我以搭建一个个人博客项目为例，演示从零到记忆生效的完整链路。

第一步，初始化项目记忆目录：

node claude-mem init --project my-blog

这一步会在~/.claude-mem/projects/my-blog/下生成memories.jsonl和config.json骨架，同时建立索引子目录。

第二步，运行一段带记忆的对话。启动你的集成应用后，第一轮对话我输入：

“我的博客打算用灰色系主题，强调阅读体验，技术栈想用Astro配Tailwind，文章格式统一用Markdown。”

模型回复确认了方案细节。这一轮的对话结束后，memories.jsonl里被写入几条记忆，例如：

{"content":"博客项目使用灰色系主题配色，强调阅读体验","category":"preference","importance":0.85} {"content":"博客技术栈选型为Astro + Tailwind CSS","category":"project","importance":0.92} {"content":"博客文章统一使用Markdown格式编写","category":"technical","importance":0.75}

第三步，隔几天新开一个会话，提问“我博客的配色和技术栈当时是怎么定的”。检索模块召回上述记忆，注入到system prompt，模型回答出“你当时定的灰色系主题和Astro加Tailwind方案”。此时如果你在CLI里执行node claude-mem query --keyword "配色"，也能直接看到带权重的相关记忆列表。

整个链路走通之后，后续每轮对话的记忆都会自动累积，你需要关注的核心指标就变成两个：记忆库里有没有混进错误信息，注入时有没有选到不相关的记忆。下面一节专门说这些问题怎么排查。

4. 常见问题与排查技巧实录

4.1 记忆提取偏差：记了不该记的，漏了该记的

提到最多的现象就是“它记了一堆没用的，真正关键的却漏掉了”。排查记忆提取偏差，第一步要打开记忆文件看实际存了什么。很多时候你会发现模型把中间过程的对话细节当成了稳定偏好，比如用户在调试时说“这里先不处理异常”，被记成了“项目不处理异常”，语义直接漂移。

修复这个问题要从提取提示词下手。我调整后的核心指令是增加“如果内容仅在当前任务中有效，但未来不会再复用，则不记录”的反向约束。同时我要求模型在提取前先做“稳定性判断”：这条信息在3个月后还会重要吗？如果答案是否定的，就不记。实测这个约束把记忆库噪声降低了一半以上。

还有一类值得注意的是纠正性提取。当用户明确说“不对，不是这样”并给出修正时，提取模块应该记录的是修正后的最终版本，而不是把修正前和修正后的信息都写进去。结构化层面可以做一层覆盖逻辑：同一主题下新记忆写入时，自动把旧的同分类冲突记录标记为superseded，检索时直接过滤掉。

4.2 检索召回不准：相关记忆没有被正确找到

只要记忆条目超过几百条，召回不准的问题就会浮出水面。最常见的原因是关键词检索和语义检索之间的框定差异。用户问“那个深色的设计还记得吗”，记忆库里存的是“深灰配色方案”，关键词“设计”匹配不到“配色”，但语义上两者确实相关。这种情况要让路向量检索，或者增加同义词扩展。

还有一种容易被忽视的情况是记忆分词导致召回错乱。比如记忆里是“React Native”，用户只搜“RN”，召回结果完全不相关。解决思路是建立一份领域同义词表，检索时先做一次查询词扩展，把缩写和全称对应上。这个工作一开始嫌麻烦，但项目多了以后，每条扩展规则都在实打实提升命中率。

定位召回问题时，我强烈建议给检索模块加一个debug模式，把每次查询命中的记忆、对应的相似度分数、排序后的得分一起打印到日志里。这样你一眼就能看出是向量分数普遍偏低导致什么都排不上来，还是某几条记忆的分数异常偏高把其他真正相关的挤掉了。

4.3 记忆膨胀与上下文污染

很多人在使用几个月后都会遇到一个尴尬场景：记忆库越来越大，检索出的条数没变，但每条记忆都越来越长。更糟的是，注入的记忆总是在AI生成代码时冒出来，明明这次在聊部署脚本，它非要参考“配色偏好”那条记忆。这就是上下文污染。

控制记忆膨胀要从两个层面同时下手。存储层设定过期策略：长时间未访问的记忆定期降权，甚至归档到冷存储；写入层完善分类过滤，特定类型的记忆只允许被特定场景的查询检索出来。比如preference类记忆默认只在高频“偏好类”查询时注入，而不是每次聊什么都带上。

我把分类过滤在检索阶段落成了一段简单的过滤器：

def filter_memories(candidates, query_context): # 根据当前会话的类型，决定允许注入哪些分类 allowed_categories = query_context.get("allowed_memory_categories") if allowed_categories: return [m for m in candidates if m["category"] in allowed_categories] return candidates

会话类型从哪里来？最简单的方式是从项目配置里写死，比如你的博客项目默认只注入preference和project类记忆，代码项目默认只注入technical和decision类。灵活性和安全性之间，我建议先保安全。

4.4 数据安全与隐私保护

记忆文件里存的是对话中提炼出的用户信息，一旦泄露就是完整的一套用户画像。因此，我在存储层面做了两层保护：一是目录权限收紧，.claude-mem目录权限设为700；二是敏感信息模糊化，在提取阶段就要求模型不记录API密钥、密码、手机号等字段，发现疑似敏感内容直接标记type: "sensitive_discard"不落盘。

实际执行时，提取指令的设置非常关键。要让模型识别哪些算敏感字段，需要在提示词里给出清晰的枚举，而不是泛泛说“不要记录敏感信息”。我目前用的枚举是：护照/身份证号、完整银行卡号、密码/私钥、家庭住址、未经同意的个人健康信息。凡命中这些类型的，一律代替为占位符[REDACTED]，再判断是否还有保留必要。

需要补充的心态是：本地记忆方案图的是可控，不是绝对安全。如果你的应用部署在多人协作的服务器上，建议再加一层SQLite加密或者干脆把记忆目录放进加密磁盘镜像里。真涉及企业级敏感数据的，别自己做，直接用云上的托管Key-Value服务带加密的更省心。

4.5 性能调优：让记忆模块不拖慢主链路

记忆模块挂进对话链路后，一个肉眼可见的影响是首字响应延迟变高了。多了一次检索和一次提取，整体耗时增加约200~800毫秒。对实时性要求高的场景，这挺要命。优化手段有几种排列组合：

第一，检索侧加缓存。同一个项目短时间内反复查询相似问题，可以按查询文本哈希结果做内存缓存，命中直接返回，省去向量计算的开销。缓存时间设5分钟就够，太长会导致新写入的记忆无法及时参与召回。

第二，提取侧做异步化。对话响应返回给用户后，提取操作放到后台队列里执行，用户无感。但要防止提取任务堆积，加一个消息队列做背压控制，队列超过100条时丢弃优先级最低的任务。

第三，减少每次检索送入模型的内容。如果用了LLM做精排序，要控制输入长度。精排序时只输入候选记忆的content字段，不要输入整个JSON对象，否则token消耗和无用信息都会变大。

调优时不要一口气全上，先加缓存，观察延迟变化，再加异步化，要确保每一步的效果可衡量。性能优化做得再花哨，最后还是要回到“记忆是真的有用”这个前提上。如果检索到的记忆对答案质量没有可感知的提升，那这块延迟就是纯浪费，不如不做。

5. 扩展思路与后续玩法

5.1 多项目支持与记忆隔离

跑多个项目时，最忌讳的是把不同项目的记忆混在一个池子里。项目A的数据库选型是PostgreSQL，项目B用的MongoDB，如果记忆混淆，AI给的建议就会自相矛盾。我现在用的方案是严格按项目目录隔离，查询时也强制绑定项目ID，绝不跨项目检索。你可以在初始化时用--project参数区分，也可以在配置里按目录自动识别项目名。

跨项目共享的少量通用知识怎么办？单独开一个global项目目录，把那些跨项目都成立的原则性内容放进去，检索时全球项目命中记录和当前项目的记录一起返回。这个设计既保留了隔离性，又避免了重复存储通用偏好。

5.2 从单机记忆到团队共享

一个人用记忆和团队用记忆，完全是两种场景。团队场景下，记忆文件如果还躺在某人的笔记本里，别人根本用不上。一个可行的演进是部署一个中心化的记忆服务，项目成员启动对话时统一从服务拉取记忆，写入时经过服务端做去重和合并。

这种架构的收益很明显：新人加入项目时，给他们的Claude装上团队记忆，瞬间就能继承项目所有的历史决策上下文。代价是需要运维一个服务，并且要设计好权限和审计机制。目前开源方案里大多没有现成的团队模式，二次开发是免不了的路。我个人建议先跑通单机全流程，再考虑把存储层抽成API服务，前端和CLI不动，改动量会小很多。

5.3 记忆可视化与管理界面

命令行工具用久了，会发现一个问题：记忆文件里存了一堆东西，但你很难快速直观地看到这个项目记住了哪些人、哪些偏好、哪些决策。我现在给记忆模块加了一个简易的可视化面板，按分类和重要性展示记忆条目，支持直接删除和修改某条记忆。这个小功能别看简单，实际价值很高。记忆自动提取再准，也需要人工审计的入口。

如果你不想自己开发界面，更轻量的做法是定期导出记忆文件到Markdown，用文档工具做检索和归档。导出格式建议按项目分文件，每个文件里按分类分节，这样团队里的人不装任何工具也能直接看。我现在的习惯是每周导出一份快照，放在项目文档仓库里，既是备份，也是可阅读的项目记忆档案。

最后说一点个人使用体验：这类工具的核心价值不在“技术多新”，而在“长期使用的复利效应”。刚开始用的一两周，你可能觉得记忆注入的效果不明显，甚至有时候还能感觉到它记错东西带来的拖累。但运行超过一个月，记忆库积累了足够的优质条目之后，对话体验会有一个肉眼可见的跃升。我自己的项目里，现在AI对我的偏好判断准确度相当高，很多需求描述都省去了背景铺陈，直接说重点它也能接得住。如果你正在被“每次对话都要重新交代背景”折磨，不妨把这套思路自己在项目里跑起来。