企业官网建设流程全解析

1. 为什么你的 Cursor 聊天记录值得被沉淀成知识库

如果你用 Cursor 或 Claude Code 写过一段时间代码，大概率遇到过这种场景：三周前和 AI 反复讨论过一个鉴权方案，当时敲定了用 JWT 加 refresh token 轮换，还专门聊了为什么不用 session。结果今天新开一个对话，AI 完全不知道这段历史，你又得从头解释一遍项目背景、技术栈、之前的决策。更糟的是，你自己也记不清当时为什么排除了另一个方案。

问题的本质不是 AI 记性差，而是对话记录散落在各个编辑器的本地目录里，没有被结构化。Cursor 的对话存在~/Library/Application Support/Cursor/下，Claude Code 的存在~/.claude/projects/下，格式各不相同，你不可能手动去翻。ai-memory 这个开源工具做的事情就是：直接读这些已有的聊天记录，用 LLM 把里面的决策、约定、待办、架构设计、问题提取成结构化的 Markdown 文件，放在项目的.ai-memory/目录里，git 可追踪、可 review、可检索。

它适合谁？适合长期用 Cursor / Claude Code / Windsurf / Copilot / Codex CLI 做开发、希望把对话里的知识沉淀下来、又不想改自己应用代码的开发者。整个流程零代码改造，一条npx命令就能跑起来。下面我把安装、配置、519 条记忆的批量提取、结果校验和检索验证完整走一遍，你可以直接跟着操作。

2. TaoToken 前置：给 ai-memory 配一个稳定的 LLM 后端

ai-memory 提取记忆时需要调用 LLM 做内容分类和结构化，它默认走 OpenAI 兼容接口。你可以用官方 OpenAI，也可以用兼容 OpenAI 协议的服务。我这边实测下来，用 TaoToken 的 API 接入比较省心，因为它兼容 OpenAI 的/v1/chat/completions协议，ai-memory 只需要改OPENAI_BASE_URL就能对接。

TaoToken 的 API 地址是https://taotoken.net/api，注意这个地址不带任何查询参数。你需要先去控制台创建一个 API Key，然后把它填到 ai-memory 的.env.local里。如果你还没建 Key，可以走这个入口：

创建 API Key：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite

接入文档在这里，里面有 OpenAI 兼容接口的完整说明，包括 base_url 怎么填、模型名怎么写：

接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite

如果你只是想先验证模型能不能正常对话，不想马上写代码，可以用模型对话页面直接试：

模型对话：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite

对于长期用 Cursor / Claude Code 做编码、跑 Agent 的场景，Coding Plan 会更划算，适合高频调用：

Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite

配好 Key 之后，ai-memory 的所有提取请求都会走这个后端。下面进入具体配置。

3. 可复制配置：settings.json 与 config.toml 骨架

ai-memory 的安装不需要全局装，直接用npx跑最新版即可。先在你的项目根目录执行初始化：

npx ai-memory-cli@latest init

这一步会创建.ai-memory/目录和配置文件。初始化完成后，你需要配置 LLM 的接入信息。ai-memory 支持两种配置方式：.env.local环境变量，以及项目级的config.toml。我建议两个都配，.env.local放密钥，config.toml放模型和提取参数。

先建.env.local：

# .env.local OPENAI_API_KEY=你的_TaoToken_API_Key OPENAI_BASE_URL=https://taotoken.net/api/v1

注意OPENAI_BASE_URL要带上/v1，因为 ai-memory 内部走的是 OpenAI 的 chat completions 路径。如果你用的是其他兼容服务，把域名换掉即可，路径保持/v1。

然后是config.toml，放在项目根目录或.ai-memory/下：

# config.toml [llm] model = "gpt-4o-mini" temperature = 0.2 max_tokens = 2048 [extract] # 每个对话分块并行提取的块大小 chunk_size = 4000 # 并行度，机器性能好可以调高 concurrency = 4 # 质量过滤：低于这个字符数的记忆丢弃 min_length = 20 # 是否启用质量过滤器 quality_filter = true [storage] # 记忆输出目录 output_dir = ".ai-memory" # 按作者分目录 by_author = true [editors] # 自动检测已安装的编辑器 auto_detect = true # 显式指定要扫描的编辑器 enabled = ["cursor", "claude-code", "windsurf", "copilot", "codex"]

如果你用的是 Cursor，它本身也有settings.json，但那是编辑器配置，和 ai-memory 无关。ai-memory 读取的是 Cursor 的对话存储目录，不需要改 Cursor 的settings.json。不过如果你想让 Cursor 通过 MCP 直接访问 ai-memory 的记忆，可以在 Cursor 的 MCP 配置里加一段。Cursor 的 MCP 配置在~/.cursor/mcp.json：

{ "mcpServers": { "ai-memory": { "command": "npx", "args": ["ai-memory-cli@latest", "mcp", "serve"], "env": { "OPENAI_API_KEY": "你的_TaoToken_API_Key", "OPENAI_BASE_URL": "https://taotoken.net/api/v1" } } } }

这样 Cursor 就能在对话里直接查询你沉淀的记忆。Claude Code 的配置类似，放在~/.claude/settings.json或项目级.claude/settings.json里，MCP server 的写法一致。

配置完成后，先跑一次list看看能识别到多少对话：

npx ai-memory-cli list

输出会列出所有检测到的对话，带编号、日期、轮数和标题。我这边跑出来是 37 个对话，编号从 1 开始。记住你要提取的编号，下一步用。

4. 519 条记忆批量提取与校验

先做一次小范围提取，确认链路通。选两个对话，比如编号 3 和 2：

npx ai-memory-cli extract --pick 3,2

工具会自动检测所有已安装的 AI 编辑器，然后对每个对话分块并行提取。提取过程中你会看到进度输出，每个对话会显示分块数和已完成的块。提取完成后，终端会打印统计：

architecture: 117 | decision: 170 | todo: 128 | issue: 102 | convention: 2 质量过滤器去掉了 22 条低质量内容（3 条太短、16 条内容模糊、3 条 TODO 被决策条目覆盖） 保留率 96%

两个对话提取出 519 条记忆，这个量级说明对话内容很密集。如果你要提取全部对话，直接跑：

npx ai-memory-cli extract

如果只想处理新增的对话，用增量模式：

npx ai-memory-cli extract --incremental

提取结果存在.ai-memory/{author}/{type}/下，每条记忆是一个独立的 Markdown 文件。你可以直接ls看目录结构：

ls .ai-memory/

校验提取结果，我一般做三件事。第一，看文件数量是否和终端统计一致：

find .ai-memory -name "*.md" | wc -l

第二，随机打开几条记忆，检查内容是否完整、分类是否正确。比如打开一条 decision 类型的：

cat .ai-memory/你的用户名/decision/某条记忆.md

每条记忆的 Markdown 头部会有元信息，包括来源对话 ID、提取时间、类型、置信度。第三，用recall做检索验证：

npx ai-memory-cli recall "OAuth"

这个命令会查询所有和 OAuth 相关的决策，并展示它们在 git 历史中每一次修改的完整轨迹。如果你之前用 git 提交过.ai-memory/目录，recall 能追到每次变更。这一步很关键，它验证了记忆不只是被提取出来，还能被检索到。

再跑一次可视化 Dashboard 看全局：

npx ai-memory-cli dashboard

浏览器打开http://localhost:3141，Conversations 页面会显示每个对话产出了多少记忆，按类型分布。Overview 页面显示 519 条总记忆的类型分布、时间线、作者分组。点击右上角可以一键复制 CLI 命令，在新会话里加载这段上下文。

5. 本篇常见错排查

报错一：OPENAI_API_KEY未设置或 401。检查.env.local是否在项目根目录，变量名是否是OPENAI_API_KEY。如果你用的是 TaoToken，确认 Key 没有多余空格，OPENAI_BASE_URL是否带了/v1。401 通常是 Key 无效或 base_url 路径不对。

报错二：list命令识别不到对话。先确认你的编辑器确实有对话记录。Cursor 的对话在~/Library/Application Support/Cursor/（macOS），Claude Code 在~/.claude/projects/。如果目录存在但识别不到，检查config.toml里的enabled列表是否包含你用的编辑器。Windows 上路径不同，Cursor 在%APPDATA%\Cursor\下。

报错三：提取到一半卡住或超时。大概率是并发度太高或单块太大。把config.toml里的concurrency调到 2，chunk_size调到 2000，再重试。如果用的是本地 Ollama，模型加载慢也会导致超时，换小模型或调大超时时间。

报错四：提取出的记忆质量差、大量模糊条目。检查quality_filter是否开启，min_length是否设得太低。如果对话本身很短、信息密度低，提取质量自然差。建议只提取那些轮数多、有明确决策的对话，用--pick指定编号，不要无脑全量提取。

报错五：recall查不到内容。确认.ai-memory/目录下有对应的 Markdown 文件，且文件没有被.gitignore排除。recall 是基于文件内容检索的，如果文件不存在或为空，自然查不到。另外确认你查询的关键词在记忆内容里确实出现过，大小写敏感。

报错六：Dashboard 打不开或端口被占用。默认端口 3141，如果被占用，可以用--port指定其他端口：

npx ai-memory-cli dashboard --port 3142

6. 把记忆接回你的编码工作流

提取只是第一步，真正有价值的是把记忆接回日常编码。ai-memory 提供了几个命令做这件事。

生成AGENTS.md规则文件，让 Cursor、Claude Code、Windsurf、Copilot、Codex CLI 都能自动读取：

npx ai-memory-cli rules --target agents-md

这个文件会把提取出的决策和约定汇总成 AI 可读的规则，打开新对话时 AI 自动读取，不需要你再手动解释背景。如果你只用 Cursor，也可以生成 Cursor Rules：

npx ai-memory-cli rules --target cursor

续接上下文，把最近的记忆复制到剪贴板，粘贴给新会话：

npx ai-memory-cli context --copy

只加载某一个对话的记忆：

npx ai-memory-cli context --source-id e0ef3946 --copy

自动定时提取，注册每天 09:00 自动跑：

npx ai-memory-cli init --schedule

取消定时：

npx ai-memory-cli init --unschedule

关联 git 提交，扫描最近 commit，自动把实现了哪条记忆的提交链接过去：

npx ai-memory-cli link

这套流程跑通之后，你的 Cursor / Claude Code 对话就不再是一次性的，而是会持续沉淀成 git 里可追踪的 Markdown 知识库。新会话开始时，AI 读AGENTS.md就能拿到之前的决策和约定，你省下的是每次重新解释背景的时间。如果你也在用 Cursor 或 Claude Code 做开发，建议先从两个对话的提取开始试，确认质量后再全量跑。