企业官网建设流程全解析

有段时间我在同一个项目里来回切换 Claude Code 和 Cursor，几乎每天都在重复两件事：换工具之后，把之前做过的技术决策再讲一遍；对着同一个需求，让两个工具分别给出方案，最后设计风格完全对不上。后来我才意识到，问题不在工具本身，而在于这些 AI 编程工具各自为政，彼此之间没有任何“记忆”可以共享。本文就围绕 Itsuki 这个项目展开，它的定位很明确：给 Claude Code、Cursor 以及另外 24 款 AI 工具提供 shared memory（共享记忆）。我会先解释为什么 AI 编程工具需要共享记忆，再拆解这类方案的核心设计，最后给出一套可以直接上手的教学版实现，并演示如何把它接入 Claude Code 和 Cursor。

1. 为什么 AI 编程工具需要“共享记忆”

1.1 一个每天都在发生的场景

假设你在做一个电商后台项目，上午用 Claude Code 完成了订单模块的表结构设计，产出了几个重要结论：订单状态字段用 integer 而不是 string、软删除字段统一叫deleted_at、金额全部用分为单位存储。下午你想用 Cursor 继续写用户模块，结果它完全不认识这些约定。你只好把上午的结论重新粘贴一遍，甚至需要重新澄清“为什么金额不能直接用小数”。

这种重复沟通，表面上看只是浪费时间，实际上还带来两个隐患：一是第二次描述可能和第一次不一致，工具之间会“打架”；二是很多隐性的上下文根本没有被记录下来，比如某个接口为什么这样设计、哪些代码是临时方案不能复用。AI 工具的能力越来越强，但它们的“记性”仍然高度依赖你喂给它的上下文。

1.2 会话隔离与上下文窗口的局限

很多人会把大模型的上下文能力等同于“记忆力”，这其实是两回事。上下文窗口（context window）决定了模型一次能“看到”多少内容，而记忆力则决定了它能不能跨会话、跨工具记住信息。当前主流模型的上下文窗口虽然越来越大，但仍然是有限的，而且对话历史越长，费用和延迟也会同步上升。

更关键的问题在于会话隔离。Claude Code 的一次会话结束之后，如果你想重新打开一个会话继续工作，通常需要显式指定继续对话，或者重新加载项目记忆文件。Cursor 的对话同样不会自动继承你在 Claude Code 里产生的内容。每个工具都有自己的会话历史、自己的规则文件，这些信息被隔离在各自的“孤岛”里。

1.3 多工具切换带来的“记忆断点”

现实中的开发者很少只用一款 AI 工具。有人用 Claude Code 写复杂重构，用 Cursor 做日常补全；有人用不同的工具分别处理前端、后端和运维脚本。这就产生了一个“记忆断点”：工具 A 知道的信息，工具 B 不知道；你今天知道的信息，明天打开新会话时可能又要重新教一遍。

共享记忆要解决的，正是这个断点问题。它的核心思路是：把那些需要在项目中长期保留的知识，比如架构决策、代码规范、数据库约定、踩坑记录，从“对话上下文”中抽离出来，放到一个所有工具都能访问的持久化存储里。这样一来，无论你切到哪款工具，只要它被配置成“先查共享记忆”，就能快速恢复项目背景。

2. 核心概念：shared memory 到底是什么

2.1 先理解“记忆”这个词

我们可以把 AI 编程工具的“记忆”分成三个层级，这样更容易理解。

第一层是会话语境，也就是模型当前对话窗口里看到的内容，短暂且易失，会话结束基本就没了。第二层是项目记忆文件，比如 Claude Code 的CLAUDE.md、Cursor 的规则文件，这些是长期存在于项目里的文本，但每个工具只认自己的格式。第三层才是真正意义上的共享记忆，它是一份独立于任何具体工具的结构化知识库，任何工具都可以通过约定好的方式读取和写入。

第三层和 “shared memory” 在操作系统里的含义不同。操作系统里的共享内存是多个进程之间共享的一段物理内存，强调的是高效数据交换；而 AI 工具领域的 shared memory，更像是一个团队共享的“项目大脑”，以文本为主要载体，强调的是知识在不同智能体之间的复用。

2.2 技术层面的三层记忆

用一张简单的分层图来表示：

会话上下文（短期） —— 当前对话窗口，随时可能丢失 项目记忆文件（中期） —— CLAUDE.md、.cursor/rules 等，工具私有 共享记忆库（长期） —— 结构化、工具无关、可持续积累

共享记忆库处于最底层，负责沉淀最稳定的知识；项目记忆文件负责把共享记忆中的关键部分“翻译”成每个工具能理解的形式；会话上下文则只在当前任务中生效。理解这个分层之后你就会发现，一个设计良好的共享记忆方案，不是要取代 CLAUDE.md 或 Cursor 规则，而是给它们提供统一的知识来源。

2.3 共享记忆与 RAG、向量库的区别

很多人在接触共享记忆时会联想到 RAG（检索增强生成）和向量数据库。它们确实有交集，但侧重点不同。

RAG 更适合处理“大量文档的相似度召回”，比如让 AI 回答某个内部知识库里的问题，输入是海量的、相对松散的文本。共享记忆则更适合处理“少量但高价值的结构化知识”，比如技术决策、接口约定、踩坑经验，这些内容往往只有几百条，但每一条都直接影响代码质量。

在实际工程中，两者可以配合使用。共享记忆负责保存“结论和规范”，向量库负责检索“原始文档和长文本”。如果你刚接触这个概念，建议先不要引入向量库，用 Markdown 文件加目录结构就能解决大部分问题，这也是很多共享记忆方案选择文本文件作为存储载体的原因。

3. Itsuki 的思路：一次写入，多个工具共享

3.1 项目定位

从项目标题 “Itsuki – shared memory for Claude Code, Cursor and 24 other AI tools” 可以看出，它的核心目标是让 Claude Code、Cursor 之外的 24 款 AI 工具都能读取同一份记忆，合计就是 26 款工具。这个定位比较有意思，它没有把自己绑死在某一款编辑器或某一个模型上，而是站在“多工具协作”的视角去解决问题。

Itsuki 面向的核心用户，应该是那些同时使用多款 AI 编程工具的开发者或团队。对于只用一款工具的开发者来说，共享记忆的价值可能还不明显；一旦你开始在不同工具之间切换，或者团队成员分别使用不同工具，统一记忆的价值就会被放大。

3.2 设计核心：一份结构化记忆库

这类共享记忆方案通常会维护一份结构化的记忆库，而不是简单的一个大文本文件。常见的做法是：

• 使用 Markdown 文件保存具体内容，方便人工阅读也方便模型解析。
• 每个记忆条目带元信息，比如主题、标签、更新时间、来源工具。
• 有一个索引文件，让 AI 工具在读取时先扫索引，再按需读取详细内容。

这种设计有一个明显好处：避免把所有记忆一次性塞进上下文窗口。模型每次开工时，只需要先读一个体积很小的index.md，了解项目有哪些记忆主题；当某个主题和当前任务相关时，再去读对应的详细文件。这样既保留了记忆的完整性，又控制了上下文开销。

3.3 工具接入层：让每个模型都知道“先查记忆”

有了记忆库还不够，还需要一种机制让每个工具都知道“开工之前先查共享记忆”。对 Claude Code 来说，这个机制通常是项目根目录的CLAUDE.md；对 Cursor 来说，是.cursor/rules下的规则文件；对其他工具，可能是各自的系统提示词（System Prompt）或配置文件。

接入层做的事情，本质上是一段“记忆使用策略”：什么时候读记忆、读哪个主题、什么时候写记忆、写到哪里。它不关心记忆内部如何存储，只需要约定好路径和格式即可。正因为接入层是轻量的，同一个记忆库才能被多种工具复用。

3.4 为什么要同时兼容这么多工具

兼容 20 多款工具，短期内看起来会增加不少维护成本，但从工程角度看其实是合理的。AI 编程工具迭代非常快，今天流行的编辑器，半年后可能就换了另一款。如果共享记忆只绑定某一种工具，用户切换工具时就要重新搭建整套体系。把记忆层做成工具无关的，相当于给项目知识上了一道“保险”——工具可以换，知识不会丢。

我可以给一个保守的估算：对个人开发者来说，同时维护 2 到 3 款工具的接入配置就够了；对团队来说，这种工具无关的设计更有利于统一规范，避免“用 Cursor 的人记一套约定，用 Claude Code 的人记另一套”。

4. 环境准备与项目结构

4.1 准备条件

这类共享记忆方案的核心是文本文件，因此对运行环境的要求很低。下面是一份参考环境：

• 操作系统：Windows / macOS / Linux 均可，路径语法略有差异。
• Python：3.8 及以上，用于运行教学版 CLI，不需要安装任何第三方依赖。
• AI 工具：Claude Code、Cursor 或其他支持自定义规则/记忆文件的工具。

需要注意的是，版本号需要根据你的实际环境调整，本文示例以“通用可运行”为目标，重点是演示思路。

4.2 记忆目录结构

为了便于理解，我把整个共享记忆的目录结构设计如下：

project-root/ ├── .itsuki/ │ ├── index.md # 记忆索引，记录所有主题与最近更新 │ ├── meta.json # 元信息，记录来源工具与最后更新时间 │ └── topics/ │ ├── architecture.md # 架构与模块设计 │ ├── database.md # 数据库约定 │ ├── conventions.md # 代码规范 │ └── decisions.md # 技术决策记录 ├── CLAUDE.md # Claude Code 记忆接入文件 ├── .cursor/ │ └── rules/ │ └── shared-memory.mdc # Cursor 规则接入文件 └── other source files...

.itsuki是共享记忆的主体，建议纳入版本控制；CLAUDE.md和.cursor/rules只负责“告诉工具去读哪份记忆”，本身不存储业务知识。

4.3 文件格式约定

每个主题文件内部建议统一格式。以decisions.md为例：

# 技术决策记录 ## 2025-06-15：订单金额存储单位 - 来源：claude-code - 状态：已确认 - 内容：金额统一用整数分存储，禁止用浮点小数。 ## 2025-06-16：软删除字段命名 - 来源：cursor - 状态：已确认 - 内容：所有表统一使用 deleted_at 字段，类型为 nullable timestamp。

每条记录包含日期、来源、状态和内容四部分。来源字段在多工具协作时特别有用，可以追踪这条知识是由哪个工具沉淀下来的。索引文件则只需要记录主题名和一句话摘要，让 AI 工具能够快速决定是否需要读取完整文件。

5. 动手实现一个共享记忆 CLI（教学版）

下面给出一个简化版共享记忆 CLI，用于理解核心机制。它不是 Itsuki 的官方源码，而是我在实际项目中常用的最小实现思路。你完全可以在它基础上扩展。

5.1 完整代码

#!/usr/bin/env python3 """ itsuki_demo.py - 教学版共享记忆 CLI 用法示例: python itsuki_demo.py init python itsuki_demo.py store "金额统一用整数分存储" --topic decisions --source claude-code python itsuki_demo.py get decisions python itsuki_demo.py list """ import argparse import json from datetime import datetime, timezone from pathlib import Path MEMORY_DIR = Path(".itsuki") TOPICS_DIR = MEMORY_DIR / "topics" INDEX_FILE = MEMORY_DIR / "index.md" META_FILE = MEMORY_DIR / "meta.json" def ensure_init(): """确保记忆目录和基础文件存在。""" TOPICS_DIR.mkdir(parents=True, exist_ok=True) if not INDEX_FILE.exists(): INDEX_FILE.write_text("# Shared Memory Index\n\n", encoding="utf-8") if not META_FILE.exists(): META_FILE.write_text("{}", encoding="utf-8") def cmd_init(): ensure_init() print(f"[ok] 已初始化共享记忆: {MEMORY_DIR}") def cmd_store(text: str, topic: str, source: str): ensure_init() topic_file = TOPICS_DIR / f"{topic}.md" now = datetime.now(timezone.utc).isoformat(timespec="seconds") # 追加写入主题文件 entry = f"\n- {now} [{source}]: {text}\n" with open(topic_file, "a", encoding="utf-8") as f: f.write(entry) # 同步追加索引，生产环境建议做去重和摘要更新 with open(INDEX_FILE, "a", encoding="utf-8") as f: f.write(f"- {topic}: {text[:60]}\n") # 更新元信息 meta = json.loads(META_FILE.read_text(encoding="utf-8") or "{}") meta["updated_at"] = now tools = meta.setdefault("tools", []) if source and source not in tools: tools.append(source) META_FILE.write_text( json.dumps(meta, ensure_ascii=False, indent=2), encoding="utf-8" ) print(f"[ok] 记忆已写入 topic={topic}") def cmd_get(topic: str): topic_file = TOPICS_DIR / f"{topic}.md" if not topic_file.exists(): print(f"[warn] 找不到主题: {topic}") return print(topic_file.read_text(encoding="utf-8")) def cmd_list(): ensure_init() for path in sorted(TOPICS_DIR.glob("*.md")): print(f"- {path.stem}: {path.stat().st_size} bytes") def main(): parser = argparse.ArgumentParser(description="共享记忆教学版 CLI") sub = parser.add_subparsers(dest="command", required=True) sub.add_parser("init", help="初始化记忆目录") store_p = sub.add_parser("store", help="写入一条记忆") store_p.add_argument("text", help="记忆内容") store_p.add_argument("--topic", default="general", help="主题文件名") store_p.add_argument("--source", default="manual", help="来源工具") get_p = sub.add_parser("get", help="读取某个主题的全部记忆") get_p.add_argument("topic") sub.add_parser("list", help="列出所有主题") args = parser.parse_args() if args.command == "init": cmd_init() elif args.command == "store": cmd_store(args.text, args.topic, args.source) elif args.command == "get": cmd_get(args.topic) elif args.command == "list": cmd_list() if __name__ == "__main__": main()

这个脚本只依赖 Python 标准库，核心逻辑可以拆成三块：ensure_init负责初始化目录，cmd_store负责把一条记忆追加到对应的主题文件并同步索引，cmd_get和cmd_list负责读取。我特意把目录结构固定为.itsuki，这样后续接入 Claude Code 和 Cursor 时，路径约定完全一致。

5.2 运行演示

在项目根目录依次执行：

python itsuki_demo.py init python itsuki_demo.py store "金额统一用整数分存储，禁止使用浮点小数" --topic decisions --source claude-code python itsuki_demo.py store "软删除字段统一命名为 deleted_at" --topic conventions --source cursor python itsuki_demo.py list python itsuki_demo.py get decisions

预期输出大致如下：

[ok] 已初始化共享记忆: .itsuki [ok] 记忆已写入 topic=decisions [ok] 记忆已写入 topic=conventions - conventions: 136 bytes - decisions: 148 bytes - 2025-06-15T08:30:00+00:00 [claude-code]: 金额统一用整数分存储，禁止使用浮点小数

到这里，你已经拥有一个可用的共享记忆库。接下来要做的，就是让 AI 工具在开工时主动读取它。

5.3 这个示例代码的局限

必须说明，教学版代码在生产环境直接使用会暴露几个问题：一是并发写入没有加锁，多工具同时写入可能互相覆盖；二是索引文件只追加不去重，时间长了会膨胀；三是没有权限控制，任何进程都能修改记忆内容。实际项目建议引入文件锁、原子写入和定期归档机制，同时限制写权限，只允许受信任的调用方写入。

6. 接入 Claude Code 与 Cursor

6.1 接入 Claude Code：通过 CLAUDE.md 加载记忆

在项目根目录新建或编辑CLAUDE.md，写入如下内容：

# 项目共享记忆使用说明 开始重要改动前，请先完成以下步骤： 1. 阅读项目根目录下 `.itsuki/index.md`，了解已有记忆主题。 2. 如果存在与当前任务相关的主题，阅读 `.itsuki/topics/` 下对应的完整文件。 3. 当对话中产生了新的架构决策、API 约定或踩坑结论时， 提醒开发者执行下面的命令写入记忆： python itsuki_demo.py store "这里填写记忆内容" --topic decisions --source claude-code

这样做的原理是：Claude Code 在启动时会自动读取项目根目录的CLAUDE.md，把它作为系统级上下文的一部分。只要这个文件在项目里，Claude Code 每次进入项目都会知道“先查共享记忆”。如果你的环境允许 Agent 直接执行 shell 命令，也可以把第 3 步改成让模型自动调用 CLI 写入，但建议先经过开发者确认，避免误写。

6.2 接入 Cursor：通过项目规则文件

在.cursor/rules/目录下新建shared-memory.mdc，内容如下：

--- description: 修改代码前先查询共享记忆 globs: ["**/*"] alwaysApply: true --- 在开始编码前，请先查看项目根目录下 `.itsuki/index.md`。 如果存在与当前任务相关的主题文件，请阅读 `.itsuki/topics/` 下对应内容。 只有在明确需要记录新的决策时才建议写入记忆，不要随意覆盖已有内容。 提示：规则正文支持中文描述，便于团队统一使用。

Cursor 会通过.cursor/rules目录加载项目级规则，.mdc文件支持在开头用 frontmatter 声明描述、匹配范围和是否始终生效。不同版本的 Cursor 对这些字段的支持略有差别，如果遇到规则不生效，优先检查字段名和文件路径。如果你的 Cursor 版本比较旧，也可以使用项目根目录的.cursorrules文件，效果类似。

6.3 多工具协作的真实效果

接入完成之后，协作流程会变成这样：

• 上午用 Claude Code 讨论数据库表设计，确定了金额字段用整数分存储，开发者执行store命令写入共享记忆。
• 下午打开 Cursor 继续写用户模块。Cursor 加载规则文件后，先读取.itsuki/index.md，发现decisions主题存在，于是读取完整内容，自动遵守“金额用整数分”的约定。
• 下次再切回 Claude Code 时，因为CLAUDE.md同样指向共享记忆，它也无需重新询问这些背景。

这个流程不需要任何复杂的服务端部署，只需要一个项目内目录、一个 Python 脚本和三段配置文本。对于大多数中小型项目，这样的透明度和可控性反而比黑盒数据库方案更合适。

7. 常见问题与排查思路

7.1 常见问题速查表

7.2 模型名称不被识别

很多开发者会把 Claude Code 接入第三方模型服务，这时经常会遇到类似 “deepseek-v4-pro is not a model this version of claude code recognizes” 的报错。绝大多数情况下，这不是 Claude Code 本身的问题，而是配置中的模型 ID 与当前模型服务返回的模型列表不一致。

排查时可以按下面几步来做：

1. 检查配置中填写的模型 ID 是否完整、拼写是否正确。
2. 到模型服务提供方的控制台查看当前支持的模型列表，确认版本号是否已更新。
3. 修改配置后重启对应工具，再执行一次简单的对话测试。

需要提醒的是，模型服务更新很快，模型改名、下线、新增版本都很常见。建议不要把模型 ID 写死在文档里，而是以你当前环境的实际配置为准。

7.3 529 错误

如果你在使用 Claude Code 时遇到529状态码，这通常是服务过载或配额限制导致的。处理思路是：先检查 API 额度是否充足，再降低请求频率，稍后重试。如果团队并发请求很多，考虑错峰使用。这个错误和共享记忆本身没有直接关系，但多工具同时高频调用时更容易触发，所以放在这里一并说明。

7.4 Cursor 规则不生效

Cursor 的规则加载有一个常见误区：修改规则文件后，正在运行的对话不会立刻感知，因为规则是在对话开始时加载的。遇到这种情况，先确认文件路径是否为.cursor/rules/shared-memory.mdc，再检查globs是否覆盖了当前文件类型。如果都没问题，重启编辑器或新开一个对话再测试。

8. 共享记忆的最佳实践

8.1 记忆分层：稳定的放前面，临时的放后面

共享记忆内部也要分层。架构决策、代码规范这类长期稳定的内容，应该放在固定的主题文件里，并设置更高的修改门槛；临时的疑问、待办事项、实验性结论，可以放在单独的临时主题中，定期清理。不要把所有内容混在一个文件里，否则模型读取时会把重要信息“淹没”在大量噪声中。

8.2 明确“写记忆”的触发时机

写记忆比读记忆更需要节制。我给自己定的触发时机是四类：架构或技术选型确定；API 合约发生变化；定位到某个坑的根本原因；团队约定需要统一执行。其他内容，比如一次性的调试过程，不值得写入共享记忆。你可以在接入规则中明确告诉 AI 工具：只有符合这四类条件的内容才建议记录，避免模型过度写入。

8.3 把记忆目录纳入版本控制

.itsuki目录应该像普通代码一样纳入 Git 管理。这样做有三个好处：一是记忆变更可以被 review，避免错误信息污染项目知识；二是可以回滚，某次写入错误时能快速恢复；三是团队成员可以通过 Pull Request 共同维护记忆，让“项目大脑”真正变成团队资产。

8.4 权限与安全边界

共享记忆本质上是一个可以被所有工具读取的文本目录，因此必须注意安全边界。首先，任何密钥、Token、客户隐私数据都不应写入记忆，必要时可以在写入脚本中加关键词过滤；其次，不要让 AI 工具无条件自动写入，至少保留人工确认的环节；最后，如果项目有严格的合规要求，不要把所有记忆都同步给每一个工具，而是按工具粒度控制读取范围。这里的原则是“最小权限”：需要多少，给多少。

9. 总结与下一步学习路线

到这一步，你已经理解了共享记忆要解决的核心问题：会话隔离、上下文窗口限制、多工具切换带来的知识断点。也掌握了一套最小实现：用.itsuki目录存记忆，用 Python CLI 写入和读取，通过CLAUDE.md和 Cursor 规则文件让不同工具都能访问同一份知识。

接下来可以按这个顺序继续深入：先在自己的个人项目里把上述流程跑一遍，验证多工具协作的效果；然后把记忆分层和写入门槛规则完善，让 AI 工具“少写精写”；再考虑为记忆库增加检索能力，比如按标签过滤、按日期归档；如果项目知识量很大，再研究如何结合向量检索。至于 Itsuki 这类成熟项目，可以持续关注它的更新，把它的设计思路和本文的教学模型对照着看，理解会更深。

最后给你一个实在的建议：共享记忆的价值，只有在长期维护下才能体现出来。不要第一天把所有规范都写进去，而是在每个重要决策发生时顺手记录一条。先用起来，再慢慢优化，比一开始就设计一个庞大体系可靠得多。