AI 2026年5月25日 1 分钟阅读

AI 编码工具各自为战？DecisionNode 用 MCP 打通共享记忆

tinyash 0 条评论

如果你同时使用多个 AI 编码工具（比如 Claude Code、Cursor、Windsurf、Codex CLI），可能遇到过这种情况：在 Claude Code 里定了一个重要的架构决策，切换到 Cursor 后模型完全不知道这个约定，导致生成的代码风格不一致，甚至推翻之前的结构。

这个问题的核心在于：每个 AI 编码工具都有自己的上下文窗口，但它们之间没有任何记忆共享机制。CLAUDE.md、.cursorrules 可以解决部分规则性问题，但对于更灵活的「决策级」知识（为什么选 A 而不是 B、某个限制条件是什么），传统的配置文件就力不从心了。

DecisionNode 刚好解决了这个痛点——它是一个基于 MCP 协议的共享结构化记忆系统，让所有 AI 编码工具共享同一个决策数据库。

DecisionNode 是什么？

DecisionNode 是一个开源 CLI 工具 + MCP 服务器，核心功能只有一句话：把开发过程中的架构决策、约束条件、设计思路以结构化 JSON 形式存储，并通过语义搜索让 AI 在需要时自动检索出来。

项目地址：https://github.com/decisionnode/DecisionNode

它的设计哲学很清晰：决策 ≠ 规则。规则（如”不要提交 .env 文件”）应该放在 CLAUDE.md 里，始终存在于上下文窗口。而决策（如”因为单线程架构，暂时不需要连接池”）只需要在相关场景下被检索即可。

快速上手

安装很简单，一行命令（需要 Node.js 18+）：

npm install -g decisionnode
cd your-project
decide init        # 创建项目存储
decide setup       # 配置 Gemini API Key（免费额度即可）

然后连接到 Claude Code：

claude mcp add decisionnode -s user decide-mcp

其他工具类似：Cursor 用户可以在 .cursor/mcp.json 中添加 same 配置，Windsurf 在 .windsurf/config.json 中配置。

一个决策长什么样？

{
  "id": "backend-007",
  "scope": "Backend",
  "decision": "跳过了 Embedding 数据库的连接池——单写入者场景，未来加同步守护进程时需要重新评估",
  "status": "active",
  "rationale": "当前架构只有一个进程在写入。连接池增加了复杂度但没有可衡量的收益。如果后续加后台同步任务，这个决策需要重新考虑。",
  "constraints": [
    "在没有重新评估之前，不要添加并发写入者"
  ],
  "createdAt": "2026-04-10T09:22:00Z"
}

每个决策包含：范围（scope）、决策内容、状态、理由、约束条件。这些信息通过 Gemini Embedding API 转化为向量，存储在本地的 ~/.decisionnode/vectors.json 中。

实战场景

场景一：跨工具架构一致性

假设你在 Claude Code 中讨论后决定使用 SQLite 作为本地存储方案，记录了这个决策。切换到 Cursor 写新功能时，Cursor 通过 MCP 调用 search_decisions，自动检索到这条记录，就不会提出改用 IndexedDB 的建议。

# 添加决策
decide add -s Storage -d "使用 SQLite 作为本地持久化方案，轻量且零运维"

# 语义搜索（跨工具可用）
decide search "数据库选型"

场景二：团队协作的非同步沟通

即使你是一个人开发，几天后回头继续工作时，decide 记录能让你快速回忆起当时的思路。这比翻看 Git 日志高效得多。

场景三：Ai 行为控制

DecisionNode 提供了 Agent Behavior 配置，可以控制 AI 搜索决策的积极程度：

decide config set behavior strict   # 强制模式：修改代码前必须搜索
decide config set behavior relaxed  # 宽松模式：AI 自行决定何时搜索

默认是 strict，对关键项目建议保持此设置。

值得关注的功能

语义冲突检测：添加新决策时，系统会自动检测与已有决策的相似度（阈值 75%），如果有冲突会发出警告。这让你可以及时发现和合并重复或不一致的决策。

全局决策：像”始终使用 TypeScript strict 模式”这种跨项目约定，可以设为全局（decide add --global），所有项目搜索时都会自动包含。

Web UI：执行 decide ui 会启动一个本地可视化界面（默认 localhost:7788），包含力导向图、UMAP 向量空间投影和决策列表，可以直观地看到决策之间的语义关联。而且当 AI 工具通过 MCP 搜索时，匹配的节点会实时闪烁，像看 AI 在”思考”一样。

最佳实践

  • 粒度适中：每条决策包含一个核心选择 + 理由即可，不要写长篇大论
  • 及时记录：做出架构选择后立刻用 decide add 记录，不要等
  • 定期清理：使用 decide deprecate 标记过期决策，decide clean 清理孤立向量
  • 搭配规则文件：CLAUDE.md 管规则，DecisionNode 管决策，两者互补

局限与注意事项

  • 需要 Node.js 18+ 环境
  • 语义搜索依赖 Gemini API（免费额度足够个人使用，但需要外网访问）
  • 当前版本（v1.x）尚未支持团队共享存储，多个开发者需各自维护本地数据
  • 向量存储是纯 JSON 文件，大量决策后查询性能会下降（官方 roadmap 有计划加入 SQLite backend）

总结

DecisionNode 用 MCP 协议巧妙地将”AI 工具间记忆共享”这个难题转化为一个优雅的解决方案。它不是最炫酷的 AI 工具，但解决了一个真实且高频的痛点——当一个 AI 工具做过的决策，另一个也能知道。对同时使用多种 AI 编码工具的开发者来说，这是一个「用了就回不去」的生产力利器。

AI 工具 开发工具 开源 教程

发表评论

你的邮箱地址不会被公开，带 * 的为必填项。