Rocketnotes：把 Markdown 笔记库接到 LLM 上的 TypeScript 应用
✨ AI-powered markdown editor - leverage LLMs with your documents - 100% local or in the cloud
秒懂
- 它是什么？
- Rocketnotes 是一个基于 Web 的 Markdown 笔记应用，把聊天、补全、语音转写和代理式归档直接嵌进编辑器。它同时提供云端账号和 Docker 本地模式，后者用 Ollama 把推理留在本机。
- 适合谁用？
- 如果你已经在用 Markdown 记笔记，并且希望检索、补全和归档这些动作由 LLM 完成，同时不想把内容交给第三方 SaaS，Rocketnotes 的 Docker 本地模式值得先跑一遍。反过来，如果你的核心需求只是纯文本编辑加 Git 版本控制，或者你的笔记规模很小、关键词搜索已经够用，引入 Ollama、ChromaDB 和嵌入模型这一整套依赖并不划算。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 146 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是笔记库和模型之间的那段距离
多数 Markdown 编辑器把 AI 做成一个侧边栏：选中一段文字，点一下，结果贴回来。Rocketnotes 的做法不同，README 把它描述为 web-based Markdown note taking app with native AI feature integrations，聊天、文本补全、语音转写、代理式归档都算应用的原生能力，而不是外挂插件。这决定了它的目标用户：已经在用 Markdown 组织知识、并且希望模型能读到全部文档而不是某一段选中文字的人。仓库的 topics 里同时出现 zettelkasten 和 notes-app，说明作者把卡片盒笔记法当作一等公民，而不是附加模板。另一条边界来自它的双语运行形态。README 的 How to use 一节给出两条路径，一条是注册 takeniftynotes.net 的账号当作 Web 或 Electron 应用使用，另一条是 Run it 100% locally with Docker。前者把文档放到 AWS 上，后者用 Ollama 在本机完成推理。这个分叉不是部署细节，而是产品定位本身：它承认有一部分用户不会把笔记交给云端模型。
后端是 Go 加 Python，向量库随部署形态切换
README 的 Tech Stack 一节列出了完整构成。前端是 Angular、TypeScript、Electron；后端是 Go 和 Python；AI 部分用 Langchain 与 Langgraph 编排，向量存储按环境二选一，云端用 S3 Vectors，本地用 ChromaDB；基础设施是 AWS 加 Docker；数据库是 DynamoDB，对象存储是 S3。这个组合透露出一个明确的取舍：本地模式和云端模式并不是同一套代码换一个连接串，向量层本身就是两套实现。嵌入模型在本地走 sentence-transformers，在云端走 S3 Vectors 对应的链路。对使用者的直接后果是，两种模式下语义搜索的召回表现不会完全一致，切换部署形态时不能假定检索结果可复现。代理式归档这条功能最能说明架构意图。README 描述它为一个 AI agent 分析 inbox 里的片段，并把片段归入最相关的既有文档。这类任务需要先检索候选文档、再判断归属、最后写入，正好落在 Langgraph 的图式编排上，而不是一次性的补全调用。换句话说，Rocketnotes 里最像产品的功能，依赖的也是最重的那部分基础设施。
本地模式的启动路径与需要盯住的配置项
README 没有把安装命令直接写在正文里，而是指向 INSTALLATION.md 的 Run with Docker 小节。可以确认的是，本地模式的完整链路是 Docker 加 Ollama，配合 ChromaDB 和 sentence-transformers 完成嵌入与检索，因此环境变量的重点会落在模型服务地址和所选模型名上。多 LLM 支持在 README 的 Features 里写明当前覆盖 OpenAI、Anthropic 和 Together AI，本地模式则通过 Ollama 接入本地权重，两者共用同一套前端交互。开发环境是另一条路径，README 指向 CONTRIBUTING.md 的 Contributing Guide，仓库语言以 TypeScript 为主，但后端同时含 Go 与 Python，所以本地开发环境的搭建成本不能按纯前端项目估算。仓库还提供了若干构建产物通道，README 顶部的徽章显示存在 build-main、deploy、docker-build-and-publish 和 electron-build-and-publish 四条 workflow，说明 Docker 镜像与 Electron 安装包都由 CI 发布，而不是要求使用者自行编译。除此之外的具体命令与配置键，我手上没有 INSTALLATION.md 的正文，无法逐条列出，这一点必须说清楚，不能凭常识补全。
MCP 与 Neovim 插件意味着它接受被别的工具调用
Features 列表里有两条容易被忽略的条目：MCP Server Integration 和 Neovim Plugin。前者把笔记库作为 MCP 暴露出去，供任意 LLM 应用使用；后者把记录动作直接放进 Neovim。这两条放在一起看，说明作者并不指望用户把 Rocketnotes 当作唯一的入口。对已经深度使用编辑器或已有 LLM 客户端的人来说，这个设计比 UI 本身更有价值：知识库可以留在 Rocketnotes 里，调用方换成别的工具。这也带来一个需要自行验证的问题。MCP 集成把笔记库暴露给外部应用，权限边界取决于该 MCP server 的实现方式，而 README 只给了功能条目，没有展开鉴权与范围控制。如果你的笔记包含凭据、客户信息或未公开的代码片段，在把 MCP 接进第三方客户端之前，应当先读源码确认它暴露的是哪一层数据、是否需要额外的访问控制。这是文档目前最薄的一块，也是最需要动手确认的一块。
什么时候它并不合适
最明显的不适配场景是：你只需要一个 Markdown 编辑器。Rocketnotes 的价值集中在语义检索、补全和代理归档上，这三项都要求文档先被切分、嵌入并写入向量库。笔记量小的时候，README 里提到的 content search 已经能覆盖绝大多数查找需求，此时多出来的 Ollama、ChromaDB 和嵌入模型只是额外的运行负担和故障面。第二个边界在本地模式的硬件侧。100% 本地意味着推理在你的机器上完成，模型规模、响应延迟和可用内存之间需要自己权衡，README 没有给出任何硬件门槛，也没有给出性能数据，所以不能假定任何一台开发机都能顺畅运行。第三个边界是数据形态。代理式归档默认你接受 AI 把片段写进既有文档，这是一个会改动正文的自动操作。如果你的笔记有严格的版本控制或审阅流程，让 agent 直接落笔就与流程冲突，需要先确认归档动作是否可撤销、是否留痕。第四点关于成熟度：从发布记录看，v1.0.5 到 v1.0.6 之间隔了近五个月，v1.0.6 到 v1.0.7 只隔六天，这种不规律的节奏说明项目仍在活跃但并非按固定周期推进，把它放进长期关键工作流之前，应当先评估自己能否接受这种维护节奏。
与 Obsidian 加 Copilot 插件的路线差异
最自然的对照是 Obsidian 配合社区 AI 插件。两者的差别不在功能清单，而在依赖归属。Obsidian 的路线是：笔记是磁盘上的本地 Markdown 文件，AI 能力由插件按需引入，向量索引通常也落在本地插件目录里，编辑器本身对模型一无所知。Rocketnotes 的路线是把 AI 编排写进应用主体，Langchain 与 Langgraph 负责流程，向量库是运行时的核心组件而不是可选附件。这个差异带来两个可观察的后果。其一，Rocketnotes 的代理式归档这类多步流程，在插件模型里很难做得同样自然，因为插件通常只拿到当前文件或当前选中内容，而 Rocketnotes 的 agent 需要访问整个文档树来挑选归属目标。其二，Rocketnotes 的部署形态更重，云端模式依赖 AWS 的 Cognito、DynamoDB、S3 与 S3 Vectors 一整套服务，本地模式则要同时跑起 Docker 与 Ollama。如果你要的是零基础设施的本地笔记，Obsidian 那条路更省事；如果你要的是把整个笔记库当作可检索语料、并允许 agent 写入，Rocketnotes 的架构更直接。
许可、维护成本与需要先验证的事
仓库采用 Apache-2.0，README 顶部的徽章也指向这一许可。Apache-2.0 允许商用与修改分发，同时带有署名和变更声明方面的要求，并包含专利授权条款。具体到你的分发形态需要怎么处理 NOTICE 与修改说明，应当交给法务判断，这里只指出许可类型本身不构成障碍。维护成本主要来自三处。模型侧，OpenAI、Anthropic、Together AI 的接口与模型命名会持续变化，本地 Ollama 的模型也需要自行拉取与更新。基础设施侧，云端模式绑定了 Cognito、DynamoDB、S3 与 S3 Vectors，这些服务的计费与配额由使用量决定，笔记库越大，嵌入与检索的开销越明显。数据侧，本地模式下 ChromaDB 的索引是可以重建的派生数据，但重建需要对全部文档重新做嵌入，文档规模上去之后这不是一个可以随手执行的操作，备份策略要围绕这一点设计。最后是版本节奏：最近三个版本分别是 v1.0.5、v1.0.6 和 v1.0.7，其中后两个集中在 2025 年 7 月，升级前值得先看 release notes 里有没有涉及数据格式或向量库结构的变化。
编辑结论
如果你已经在用 Markdown 记笔记，并且希望检索、补全和归档这些动作由 LLM 完成，同时不想把内容交给第三方 SaaS，Rocketnotes 的 Docker 本地模式值得先跑一遍。反过来，如果你的核心需求只是纯文本编辑加 Git 版本控制，或者你的笔记规模很小、关键词搜索已经够用，引入 Ollama、ChromaDB 和嵌入模型这一整套依赖并不划算。动手之前先确认三件事：INSTALLATION.md 里 Docker 模式给出的环境变量清单是否覆盖你选用的模型后端；本地模式下向量库落在哪个卷上，因为 ChromaDB 的数据一旦丢失，语义搜索需要重新对全部文档做嵌入；以及你所在团队对 Apache-2.0 的署名与修改分发要求是否已有既定处理方式。
社区笔记