1. 项目概述从碎片化对话到结构化知识库的进化如果你和我一样每天花大量时间在 Cursor、Claude Code 这类 AI 编程编辑器里和模型对话那你一定遇到过这个痛点那些在聊天中敲定的架构决策、达成的编码约定、记录的技术要点就像沙滩上的字迹一次刷新、一次换机或者一个新同事加入项目它们就消失得无影无踪。我们的大脑不是数据库不可能记住三个月前为什么选择 PostgreSQL 而不是 MySQL或者上周和 AI 讨论的那个精巧的 OAuth 桥接模式具体是怎么设计的。更糟糕的是当你想在全新的对话中继续之前的工作时要么得手动翻找冗长的历史记录要么就得重新解释一遍上下文浪费宝贵的 token 和精力。ai-memory这个工具就是为了解决这个“AI 对话失忆症”而生的。它的核心目标非常明确将你与 AI 编程助手如 Cursor, Claude Code, Windsurf, VS Code Copilot的对话历史自动提取、结构化并保存成一个可搜索、可版本控制Git的 Markdown 知识库。简单来说它给你的 AI 对话装上了“记忆外挂”让那些宝贵的思维火花和决策过程不再是一次性的消耗品而是能沉淀下来、随时调用的团队资产。我第一次接触这个项目时就被它的设计理念打动了。它不是一个复杂的、需要你改变工作流的庞然大物而是一个轻巧的 CLI 工具用npx就能直接运行。你不需要搭建服务器不需要复杂的配置它直接读取你本地编辑器存储的对话文件利用大语言模型LLM的智能从中提炼出“决策”、“架构”、“约定”、“待办事项”和“问题”这几类关键信息然后以清晰的结构保存下来。最妙的是所有这些产出都是纯 Markdown 文件你可以直接git add和git commit让知识库的演进和代码的演进同步完美融入现有的开发流程。注意ai-memory本身不存储你的对话历史它只是一个处理工具。你的原始对话数据仍然安全地留在本地编辑器目录中。它只是读取、分析并生成新的、结构化的衍生文件。2. 核心价值与工作流设计为什么你需要它在深入技术细节之前我们先来拆解一下ai-memory到底能为你和你的团队带来什么。这不仅仅是“又多了一个工具”而是对现有 AI 辅助编程工作流的一次效率革命。2.1 告别“上下文丢失”实现“对话永续”想象一个典型场景你在 Cursor 里花了两个小时和 AI 一起设计了一个微服务的认证模块讨论了 JWT 和 Session 的优劣最终决定采用 OAuth 2.0 授权码模式并敲定了几个关键的接口命名规范。对话结束你心满意足。一周后你需要修改这个模块或者一个新同事要接手这部分工作。怎么办要么你凭记忆复述很可能遗漏细节要么对方从头到尾翻看可能长达上百条的聊天记录效率极低。ai-memory的context命令就是为了这个场景设计的。运行npx ai-memory-cli context --copy它会瞬间无需调用 LLM扫描你知识库中所有未解决的记忆决策、待办等生成一个精炼的上下文提示块并复制到你的剪贴板。你可以直接将其粘贴到一个全新的 Cursor 或 Claude Code 对话中。这个提示块会清晰地列出“关键决策请遵循无需重新讨论”、“编码约定请始终遵循”和“活跃的待办事项”。AI 助手基于这个上下文与你对话仿佛之前的对话从未中断。实测下来这通常能减少 90% 以上的 token 消耗因为你不再需要把历史记录重新喂给模型。2.2 构建团队共享的“项目记忆体”在团队协作中知识传递的成本很高。A 同学踩过的坑、总结的最佳实践B 同学可能完全不知道导致重复犯错。ai-memory天生支持多用户。它会根据 Git 配置或系统用户名自动识别作者并将每个人提取的记忆存放在.ai-memory/{作者名}/的独立子目录下。这样当 Alice 运行extract后她的决策会保存在.ai-memory/alice/decisions/里Bob 的则保存在.ai-memory/bob/decisions/里。团队 leader 或任何成员可以通过npx ai-memory-cli summary --all-authors生成一份包含所有人记忆的项目总览SUMMARY.md。更强大的是rules命令可以扫描所有人的“约定”conventions自动生成一个统一的.cursor/rules/ai-memory-conventions.mdc文件。一旦将这个规则文件放入项目Cursor 编辑器会在所有后续的 AI 交互中自动应用这些约定确保团队代码风格和模式的一致性。这形成了一个完美的闭环从分散的对话中提取共识再将共识固化为自动化执行的规则。2.3 实现知识的“主动沉淀”与“精准检索”我们的大脑擅长创造但不擅长记忆。ai-memory充当了你的“第二大脑”负责记忆。watch模式是这一理念的极致体现只需运行npx ai-memory-cli watch它就会在后台默默监控你所有已配置的编辑器Cursor, Claude Code等的对话文件。一旦检测到有新对话或现有对话被更新它会自动触发提取流程。你完全无需手动干预知识就在你编码讨论的过程中被自动沉淀下来。当知识库积累到一定规模如何快速找到所需信息search命令提供了强大的混合搜索能力。它不仅仅是关键词匹配还集成了语义搜索需要配置嵌入模型。例如你搜索“数据库选型”它不仅能找到标题或内容里含有“PostgreSQL”、“MySQL”的文档还能找到那些讨论了“数据持久化方案”、“存储引擎对比”的相关记忆即使它们没有直接出现“数据库”这个词。搜索时还可以按类型、作者、解决状态进行过滤让你在海量记忆中迅速定位。3. 环境准备与快速上手理论说了这么多是时候动手了。ai-memory的入门门槛极低我们一步步来。3.1 基础环境要求首先确保你的系统满足两个基本条件Node.js 环境版本需要 18。建议使用 Node.js 22 或更高版本因为新版本能提供更丰富的功能例如从 Cursor 或 Windsurf 的本地数据库中提取更准确的对话标题。如果你的版本在 18 到 20 之间功能完全正常只是标题可能取自对话的第一条消息。大语言模型LLM接入能力ai-memory的核心“提取”功能需要 LLM 来分析对话。你有三种选择云端 API需要任何一个 OpenAI 兼容的 API 密钥如 OpenAI 官方、Azure OpenAI、或各类兼容 OpenAI 接口的代理服务。这是最方便的方式。本地模型Ollama在本地运行 Ollama下载模型如llama3.2无需网络和 API 费用数据完全本地处理隐私性最好。本地模型LM Studio同样在本地运行 LM Studio 并提供兼容 OpenAI 的 API 接口。对于绝大多数开发者我推荐从云端 API 开始体验最流畅。我们以配置 OpenAI API 为例。3.2 五分钟快速启动打开你的终端跟随以下步骤第一步设置 API 密钥在终端中设置环境变量。你可以将其添加到 shell 配置文件如~/.zshrc或~/.bashrc中永久生效但为了快速测试可以直接在终端运行export OPENAI_API_KEY你的-sk-...密钥或者使用ai-memory更推荐的环境变量名它与ai-review-pipeline项目共享配置export AI_REVIEW_API_KEY你的-sk-...密钥ai-memory会优先使用AI_REVIEW_API_KEY其次是OPENAI_API_KEY。第二步进行首次知识提取进入你的任意一个项目目录最好是正在使用 Cursor 或 Claude Code 进行开发的项目运行npx ai-memory-cli extract第一次运行会花费一些时间因为它需要自动探测你系统上已安装的 AI 编辑器Cursor, Claude Code 等并定位其对话存储路径。读取所有历史对话。调用 LLM 对每段对话进行分析提取结构化知识。将提取结果保存到项目根目录下的.ai-memory/文件夹中。完成后你会看到类似这样的输出列出了提取到的记忆数量[ai-memory] Found 47 conversations across 2 sources. [ai-memory] Extracting memories... (this may take a minute) [ai-memory] ✅ Extracted 12 memories (5 decisions, 3 conventions, 2 todos, 2 architecture) [ai-memory] Memories written to .ai-memory/第三步立即体验核心功能现在你的知识库已经初步建立。尝试几个命令来感受它的威力搜索npx ai-memory-cli search 认证或npx ai-memory-cli search auth快速找到所有与认证相关的讨论。生成上下文npx ai-memory-cli context --copy生成一个包含所有未解决记忆的摘要并复制到剪贴板。打开一个新的 Cursor 聊天窗口直接粘贴进去看看 AI 是如何“继承”上下文的。生成团队规则npx ai-memory-cli rules它会扫描提取出的所有“约定”生成一个 Cursor Rules 文件。查看生成的.cursor/rules/ai-memory-conventions.mdc你会发现里面已经包含了你们团队在对话中形成的代码规范。第四步纳入版本控制git add .ai-memory/ .cursor/rules/ git commit -m “chore: 初始化 ai-memory 知识库与团队规则”至此一个可搜索、可共享、可版本化的项目知识库就搭建完成了。日常使用中你只需要在完成一段有意义的对话后运行npx ai-memory-cli extract --incremental来增量更新即可。4. 核心命令深度解析与实战技巧了解了基本流程我们来深入每一个核心命令看看它们在不同场景下的高级用法和那些“说明书”里不会写的实操细节。4.1extract智能提取的艺术与优化extract是引擎它的配置和策略直接影响知识库的质量。基础与增量提取npx ai-memory-cli extract全量提取所有探测到的对话。首次运行或需要重建索引时使用。npx ai-memory-cli extract --incremental这是日常最常用的命令。它只处理自上次提取以来新增或修改过的对话速度极快。我习惯在关闭编辑器前运行一下就像“保存”对话记忆一样。精准提取与过滤当项目历史很长时你可能只想处理特定对话。npx ai-memory-cli list先列出所有可用的对话每个都有编号和标题。npx ai-memory-cli extract --pick 3仅提取列表中的第 3 个对话。npx ai-memory-cli extract --pick 1,4,7提取第 1、4、7 个对话。npx ai-memory-cli extract --since “3 days ago”只提取最近 3 天的对话非常适合周报或复盘。npx ai-memory-cli extract --type decision,todo只提取“决策”和“待办”类型的记忆忽略架构、约定等。实操心得与避坑指南对话质量决定提取质量LLM 是从你的对话文本中提取信息。如果对话本身含糊、零散提取结果也会不理想。在与 AI 交流时尽量用清晰的语句总结结论例如“决策我们将采用 X 方案因为 Y 原因。” 这能极大提升提取准确率。善用--dry-run预览在不确定提取效果或想了解 LLM 会如何处理某段对话时使用npx ai-memory-cli extract --pick N --dry-run。它不会写入文件但会在控制台打印出 LLM 的提取结果Raw Output让你可以评估和调整。处理“过时”记忆有时早期的决策会被推翻。ai-memory提供了resolve命令来标记记忆为“已解决”。但更根本的方法是在提取时使用--since或--pick进行聚焦避免无关的历史对话污染当前的知识库。定期使用search查看旧记忆并用resolve清理是保持知识库清洁的好习惯。作者识别问题ai-memory按--author参数 配置文件author字段 git config user.name 系统用户名的优先级确定作者。在团队环境中确保每个人的 Git 用户名配置正确是关键否则所有记忆可能会被归到同一个作者名下。如果出问题可以在提取时显式指定--author “张三”。4.2search与context知识检索与上下文复现这是知识库价值兑现的关键环节。search从关键词到语义的混合搜索基础的搜索很简单npx ai-memory-cli search “OAuth”。但其高级功能非常强大类型过滤npx ai-memory-cli search “error” --type issue只搜索“问题”类型的记忆。作者过滤npx ai-memory-cli search “设计” --author alice只看 Alice 的设计决策。包含已解决的默认搜索会排除已标记为resolved的记忆。使用--include-resolved可以强制包含它们这在回顾历史时有用。JSON 输出--json参数将结果以 JSON 格式输出便于与其他脚本或工具集成例如构建自动化报告。context打造无缝的对话连续性context命令生成的提示块结构清晰是 AI 理解的绝佳格式。其核心选项--topic “支付模块”只生成与特定主题相关的记忆使得上下文极其聚焦。--recent 7只包含最近 7 天内创建的未解决记忆适合短期工作的延续。--summarize这个选项非常有用。它会额外调用一次 LLM将提取出的记忆列表压缩成一段连贯、精炼的叙述性摘要而不是简单的列表。这能进一步节省 token并提供更好的可读性。例如它会将“决策A用A。决策B用B。” 总结为“本项目在架构上主要做出了两个关键决策一是采用A方案处理X二是采用B方案处理Y。”。--all-authors在团队协作中如果你想基于整个团队的知识来开始一段新对话这个选项必不可少。一个实战工作流示例 假设你正在开发一个“优惠券系统”昨天和 AI 讨论了很久。今天你想继续。npx ai-memory-cli extract --incremental更新昨晚对话的记忆npx ai-memory-cli context --topic “优惠券系统” --copy打开新的 Cursor 对话粘贴上下文。直接问“基于以上上下文我们昨天讨论的优惠码批量生成接口你建议的数据库索引具体是什么字段” 你会发现AI 能准确回忆起昨天的讨论细节仿佛对话从未中断。4.3rules从对话约定到自动化规则这是ai-memory最具创新性的功能之一。很多团队都有编码规范但很难让 AI 助手始终遵守。rules命令通过分析历史对话中反复出现或被明确声明的“约定”conventions自动生成 Cursor 编辑器能直接识别的.mdc规则文件。运行与效果 运行npx ai-memory-cli rules后会在.cursor/rules/目录下生成ai-memory-conventions.mdc。这个文件的内容可能类似# 项目编码约定 (自动从对话历史提取) - **命名**组件使用 PascalCase函数使用 camelCase。 - **错误处理**所有异步函数必须使用 try/catch 包裹并记录错误日志。 - **API 设计**RESTful 端点使用复数名词例如 /api/users。 - **状态管理**在此项目中禁止直接使用 useState 管理全局状态必须使用 Zustand。当你或任何队友在项目中打开 Cursor 并开始与 AI 对话时这些规则会自动生效。AI 在生成代码建议时会倾向于遵循这些约定极大地提升了代码一致性。注意事项约定提取的准确性规则生成依赖于extract命令对“convention”类型记忆的提取。这要求你在对话中相对明确地表达约定。像“我们以后都这么写吧”、“这个命名风格保持统一”这样的语句被识别为约定的概率较高。规则的合并与冲突如果项目中原先就有.cursor/rules/下的其他.mdc文件ai-memory生成的文件会与之共存。Cursor 会读取所有规则。如果存在冲突可能需要手动调整。ai-memory目前不会覆盖或合并现有规则文件。团队规则使用--all-authors参数可以聚合所有团队成员的约定生成一份统一的团队规则文件。4.4watch与dashboard自动化与可视化watch设置后即忘记的自动化运行npx ai-memory-cli watch后它就变成了一个后台守护进程。它会监听 Cursor、Claude Code 等编辑器对话文件的变更通过文件系统事件。每当你结束一段有意义的对话并保存后ai-memory会在几秒内自动触发提取无需你手动执行任何命令。控制台会实时输出日志告诉你它检测到了哪个对话提取出了什么类型的记忆。这对于追求极致流畅体验的开发者来说是终极选择。只需在开始一天工作前启动它然后忘掉它知识就在后台自动沉淀。dashboard图形化探索你的知识库命令行虽然强大但视觉化浏览有时更直观。运行npx ai-memory-cli dashboard它会启动一个本地 Web 服务器默认http://localhost:3141在浏览器中打开一个仪表盘。这个仪表盘提供了概览记忆总数、类型分布、作者贡献、近期活动时间线。记忆浏览器一个可实时搜索、过滤按类型、作者、状态的表格界面点击可查看记忆详情。知识图谱一个基于 D3.js 的交互式力导向图。记忆作为节点颜色代表类型如果它们来自同一对话或共享关键词则用边连接。这能帮你直观地发现不同决策或主题之间的关联是探索性检索的利器。导出功能支持将整个知识库导出为 JSON或导出为 Obsidian 笔记库格式包含 YAML Frontmatter方便你迁移到其他知识管理系统。5. 高级配置与集成方案当基础功能满足需求后你可以通过配置和环境变量来定制ai-memory并将其集成到更复杂的自动化流程中。5.1 配置文件详解运行npx ai-memory-cli init会在.ai-memory/下生成一个.config.json模板。你也可以手动创建。一个完整的配置示例如下{ “sources”: { “cursor”: { “enabled”: true, “projectName”: “my-awesome-project” // 可选如果多个 Cursor 项目指定一个 }, “claudeCode”: { “enabled”: true }, “windsurf”: { “enabled”: false }, // 暂时禁用 Windsurf “copilot”: { “enabled”: false } // 暂时禁用 VS Code Copilot }, “extract”: { “types”: [“decision”, “architecture”, “convention”, “todo”, “issue”], “ignoreConversations”: [“some-uuid-1234”], // 跳过特定对话例如测试对话 “minConversationLength”: 3 // 忽略消息数少于3条的极短对话 }, “output”: { “dir”: “.ai-memory”, “summaryFile”: “SUMMARY.md”, “language”: “zh” // 输出摘要的语言支持 “zh” 或 “en” }, “model”: “”, // 留空自动选择或指定如 “gpt-4o” “author”: “” // 留空自动检测或写死一个作者名 }关键配置项解读sources按需启用或禁用数据源。如果你只用 Cursor可以把其他的关掉加快扫描速度。extract.ignoreConversations非常实用。有时我们会和 AI 进行一些无关紧要的闲聊或测试这些对话的 UUID 可以通过list --json命令获取然后加入这个列表避免它们污染知识库。output.language设置为“zh”后summary命令生成的摘要和部分 UI 提示会使用中文对中文团队更友好。model通常不需要设置ai-memory会根据你的 API 密钥和环境自动选择性价比高的模型如gpt-4o-mini。如果你有特定需求例如需要更强的推理能力可以在这里指定gpt-4o等模型。5.2 本地 LLM 集成Ollama 与 LM Studio出于成本、速度或隐私考虑你可能希望使用本地模型。ai-memory对此提供了开箱即用的支持。使用 Ollama安装并启动 Ollama参见 ollama.ai 。拉取一个合适的模型例如用于文本生成的llama3.2和用于语义搜索嵌入的nomic-embed-textollama pull llama3.2 ollama pull nomic-embed-text # 可选用于增强搜索设置环境变量然后运行extractexport OLLAMA_HOSThttp://localhost:11434 export OLLAMA_MODELllama3.2 npx ai-memory-cli extract如果设置了OLLAMA_EMBEDDING_MODELsearch命令的语义搜索功能将启用。使用 LM Studio启动 LM Studio加载一个模型并确保其“本地服务器”功能已开启通常默认在http://localhost:1234/v1。设置环境变量指向 LM Studio 的服务器export LM_STUDIO_BASE_URLhttp://localhost:1234/v1 export LM_STUDIO_MODEL你加载的模型名称 npx ai-memory-cli extract提示云端 API 密钥的优先级高于本地 LLM 配置。如果你同时设置了OPENAI_API_KEY和OLLAMA_HOSTai-memory会优先使用云端 API。如果想强制使用本地模型请取消设置unset云端 API 相关的环境变量。5.3 MCP 服务器集成让 AI 助手拥有“记忆”能力模型上下文协议MCP是让 AI 编辑器如 Cursor, Claude Code安全访问外部工具和数据的标准。ai-memory可以作为 MCP 服务器运行这意味着你的 AI 助手能在对话过程中直接读写你的知识库无需你手动运行 CLI 命令。配置方法 对于Cursor编辑或创建项目根目录下的.cursor/mcp.json文件{ “mcpServers”: { “ai-memory”: { “command”: “npx”, “args”: [“ai-memory-cli”, “serve”] } } }对于Claude Code编辑~/.claude/claude_desktop_config.json文件添加类似的配置。配置后的能力飞跃 配置并重启编辑器后AI 助手将获得几个强大的新工具remember在对话中你可以直接告诉 AI“请记住这个决定我们使用 UUID v7 作为主键。” AI 会调用此工具将这条信息作为一条“决策”记忆存储到你的知识库中。这是真正的“对话中实时沉淀”。recallAI 可以主动或应你要求搜索知识库。例如你问“我们之前关于错误处理是怎么决定的” AI 会调用recall工具进行语义搜索找到相关记忆并引用。search_memories更高级的搜索工具支持按类型、作者过滤。project-context资源当你在项目内开启新对话时AI 会自动获得由ai-memory提供的项目上下文无需你手动粘贴context命令的输出。实测体验集成 MCP 后工作流变得无比自然。你和 AI 的对话成了一个“有记忆”的协作过程。重要的结论会被自动归档需要时又能被瞬间召回。这极大地减少了上下文切换的成本让 AI 真正成为了一个拥有长期记忆的结对编程伙伴。5.4 CI/CD 集成自动化知识库同步对于团队项目你可以将ai-memory的提取过程集成到 CI持续集成流水线中确保知识库随着代码的每次合并自动更新。以下是一个 GitHub Actions 工作流的示例.github/workflows/update-memory.ymlname: Update AI Memory on: push: branches: [ main, develop ] schedule: - cron: ‘0 2 * * *’ # 每天凌晨2点运行一次捕获可能漏掉的更新 jobs: update-memory: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 # 获取完整历史确保 .ai-memory 历史可追溯 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: ‘20’ - name: Extract AI memories incrementally run: npx ai-memory-cli extract --incremental --json env: AI_REVIEW_API_KEY: ${{ secrets.AI_REVIEW_API_KEY }} # 在仓库Settings/Secrets中配置 # 或者使用 OPENAI_API_KEY - name: Generate Cursor Rules run: npx ai-memory-cli rules --all-authors - name: Commit and push if changes run: | git config user.name “github-actions[bot]” git config user.email “github-actions[bot]users.noreply.github.com” git add .ai-memory/ .cursor/rules/ if git diff --staged --quiet; then echo “No changes to commit.” else git commit -m “chore(ci): auto-update ai-memory knowledge base [skip ci]” git push fi这个工作流会在每次推送到主分支或开发分支以及每天凌晨自动运行。它执行增量提取、生成团队规则并将变更自动提交回仓库。这样团队所有成员通过git pull就能获得最新的集体知识。重要安全提示在 CI 中使用的 API 密钥务必通过仓库的 Secrets 功能设置切勿明文写在 YAML 文件中。对于开源项目可以考虑使用无需 API 密钥的本地模型模式如通过自托管 Runner 运行 Ollama但这对 CI 机器的配置要求较高。6. 典型问题排查与实战心得即使工具设计得再完善在实际使用中总会遇到一些“坑”。以下是我在长期使用ai-memory过程中总结的常见问题及其解决方案以及一些提升效率的心得。6.1 常见问题速查表问题现象可能原因解决方案运行extract提示 “No conversations found”1. 编辑器对话存储路径未被正确探测。2. 你不在一个有效的项目目录中对于 Cursor。3. 对应数据源在配置中被禁用。1. 运行npx ai-memory-cli init检查探测到的路径。2. 确保在 Cursor 打开的项目根目录下运行。3. 检查.ai-memory/.config.json中的sources配置。提取出的记忆内容空洞或错误很多1. 对话本身质量不高缺乏明确结论。2. 使用的 LLM 模型能力不足如用了太小的本地模型。3. 对话语言与模型不匹配如中文对话用了英文模型。1. 改进与 AI 的对话方式明确标注决策点。2. 尝试更换更强的模型如从gpt-3.5-turbo切换到gpt-4o-mini。3. 在对话中尽量使用模型擅长的语言或尝试设置output.language。search结果不相关1. 纯关键词匹配的局限性。2. 语义搜索未启用或嵌入模型不合适。1. 尝试更具体的关键词组合。2. 确保已配置嵌入模型如设置OLLAMA_EMBEDDING_MODEL或云端嵌入 API并运行npx ai-memory-cli reindex重建索引。MCP 服务器连接失败1.npx路径问题或网络问题。2. Cursor/Claude Code 配置错误。3.ai-memory版本与编辑器兼容性问题。1. 尝试在配置中使用node和脚本的绝对路径。2. 仔细检查 JSON 配置格式确保无语法错误。3. 查看编辑器日志或使用npx ai-memory-cli serve --debug手动启动服务器查看输出。团队协作时summary --all-authors看不到队友的记忆队友的.ai-memory/{作者名}/目录未提交到 Git或提交后你未拉取最新。确保团队有共识将.ai-memory/目录除了.state.json纳入版本控制并定期同步。运行速度很慢1. 历史对话非常多首次全量提取慢。2. 网络延迟高使用云端 API。3. 本地模型性能瓶颈。1. 首次提取耐心等待后续使用--incremental会很快。2. 考虑使用本地模型或更换 API 提供商。3. 使用--pick或--since限制提取范围。生成的 Cursor Rules 不符合预期对话中提取出的“约定”记忆太少或质量不高。在对话中更明确地定义约定例如“约定本项目所有 React 组件文件使用.tsx扩展名。” 然后重新运行extract和rules。6.2 提升提取质量的“心法”结构化你的对话当你和 AI 讨论出一个重要结论时养成用清晰标记总结的习惯。例如**决策** 采用 Server-Sent Events 实现实时通知因为我们需要简单的单向数据流。**待办** [ ] 编写用户删除功能的单元测试。**约定** 所有 API 响应包装在{ data: ..., error: null }结构中。这样的结构会被 LLM 轻易识别并准确分类。定期“修剪”知识库知识库不是只增不减的。使用resolve命令标记已完成的待办、已过时的决策。定期运行search --include-resolved回顾已解决的记忆考虑是否可以直接删除对应的 Markdown 文件以保持知识库的简洁和时效性。利用“项目”维度如果你在多个不同的项目中使用 Cursorai-memory会识别不同的项目路径。确保你在正确的项目目录下运行命令这样提取的记忆才会归入正确的.ai-memory知识库避免交叉污染。备份与迁移.ai-memory/目录下的所有 Markdown 文件都是纯文本迁移极其方便。整个目录复制到新项目即可。但注意.ai-memory/.state.json文件记录了提取状态是机器相关的不应纳入 Git 或进行迁移应添加到.gitignore。在新环境首次运行extract时如果发现已有 Markdown 文件但状态文件缺失它会智能地跳过已存在的文件避免重复处理。6.3 关于隐私与安全的思考ai-memory处理的是你本地的对话数据这是一个需要严肃对待的隐私问题。本地处理优先最安全的方式是使用本地 LLMOllama/LM Studio。你的对话数据永远不会离开你的机器。云端 API 的风险如果你使用 OpenAI 等云端 API你的对话内容会被发送到服务提供商的服务器。请确保你发送的内容不包含敏感信息密码、密钥、未公开的商业逻辑等。对于高度敏感的项目强烈建议使用本地模型。Git 提交前的审查由于记忆文件会被提交到 Git在团队协作中务必在git add前检查.ai-memory/下的文件内容确保没有意外泄露个人隐私或敏感信息。可以考虑将.ai-memory/目录的变更审查纳入团队的 Code Review 流程。ai-memory从一个简单的想法——不让 AI 对话的智慧流失——发展成一个功能丰富的开发者效率工具其核心价值在于它无缝地融入了现有工作流。它没有试图创造一个新的、封闭的知识管理平台而是巧妙地利用 Git 和 Markdown 这些开发者最熟悉的工具在对话历史和项目代码之间架起了一座坚固的桥梁。无论是个人用于对抗遗忘还是团队用于固化共识、传承知识它都提供了一个优雅而高效的解决方案。