很多团队把真正重要的工作记录放在 Notion，但一旦离开网页界面，资料就会立刻变得难复用。你想做全文检索、写 SQL 查询、把页面按目录导出、给 agent 一个可追踪的知识快照，或者只是想把工作区同步到本地长期保存，都会发现 Notion 原生体验并不擅长这些事。

今天想推荐的 openclaw/notcrawl，就是一个很直接的答案: 它把 Notion 工作区镜像到本地 SQLite 和规范化 Markdown，让内容不再只活在网页 UI 里。项目主页把 SQLite 定义为 canonical archive，把 Markdown 定义为 durable human/agent surface，这个定位我很喜欢，因为它一开始就把“可读”和“可查询”都放进了设计中心。

发布时 GitHub 页面显示项目约 106 stars、10 forks，主语言是 Go，采用 MIT 许可。仓库当前有 149 commits，release 页显示最新版本为 v0.4.0，发布时间是 2026-05-18。

项目概览

属性详情
仓库openclaw/notcrawl
定位本地优先的 Notion 归档与检索工具
Stars约 106
Forks约 10
主要语言Go
许可MIT
最新版本v0.4.0
核心输出SQLite、Markdown、git-share 快照

它解决的不是“抓一份备份”，而是把 Notion 变成可操作的数据层

很多“导出 Notion”的工具，最后只是生成一堆不好维护的 HTML 或零散 Markdown。文件虽然拿到了，但结构不稳定，也很难继续做分析、自动化和增量同步。

notcrawl 的思路更工程化。README 里明确写了三条 ingestion path:

  • desktop: 读取本地 Notion 桌面端缓存的只读快照。
  • api: 通过官方 Notion API 做带限流意识的同步。
  • notion-mcp: 通过预配置的 Codex Notion connector 做定向修补。

这个设计很实用。你不用被迫只选一种入口，而是可以把“本地缓存拿全量轮廓”、“官方 API 补结构化对象”、“MCP 补缺页或缺块”组合起来。对真正长期使用 Notion 的人来说，资料往往不整齐，单一同步路径经常会留下边角问题，三种入口并存反而更接近现实。

SQLite 和 Markdown 双轨输出，是它最值得看的地方

README 里最关键的一句话是: SQLite is the canonical archive. Markdown is the durable human/agent surface.

这其实是在明确区分两类需求。

第一类需求是机器侧。你需要一个稳定、可查询、可维护的本地归档层，所以项目提供 SQLite，并且把它作为真正的 source of truth。README 当前 scope 里还写到了 FTS5、状态命令、活动报告、维护命令以及只读 SQL 访问，这说明作者不是把数据库当成附属缓存，而是真的把它当成主要资产。

第二类需求是人和 agent 侧。团队成员、脚本、AI agent 往往更适合直接读结构化 Markdown，而不是再去解析网页或 API 返回值。notcrawl 会把内容导出成按 workspace、teamspace、page path 组织的规范化 Markdown，同时处理 Unicode-safe 路径。这类细节很重要，因为一旦导出的文件路径不稳定，Git 历史、分享和自动化都会变差。

如果你在做本地知识库、agent context 准备、工作记录长期保存，这种数据库加文本文档的双轨模型要比“只有一个 Web export”强得多。

git-share 模式说明作者考虑了跨机器同步

这个项目不是只停留在“我本机能导出一点文件”。README 里还写了 compressed JSONL git-share snapshots，并提到 git share mode 可以发布规范化快照，让其他机器在不持有 Notion 凭证的前提下订阅这些内容。

我很看重这个点。很多团队的问题并不是“怎么从 Notion 导出一份内容”，而是“怎么把这份内容安全、稳定、低摩擦地分享给别的机器、人或 agent”。如果每一台环境都需要直接连接 Notion、持有 token、重新爬取，你的权限和审计边界会很快变复杂。

notcrawl 给出的路线是把抓取和分享分开。抓取发生在可信环境里，分享出去的是已经规范化的本地快照。对想做 agent retrieval、文档镜像、离线检索或者多机同步的人来说，这个设计比直接让所有工具都接 Notion API 更稳。

它不只是 crawler，还带了一整套本地运维表面

我比较喜欢这种项目: 不只展示核心想法，还把日常可维护性补上。

README 里的 quick start 和 commands 已经能看出它并不只是“抓完就算了”。它提供：

  • doctor 检查配置、SQLite、桌面缓存和 token；
  • status 输出归档数量、上次同步时间以及数据库体积；
  • report 汇总最近页面、数据库、space 和 comment 活动；
  • maintain 重建 FTS、优化索引并可执行 VACUUM；
  • tui 做终端内快速浏览；
  • 多个 --json 控制面接口，方便 launcher、automation 和 CI 使用。

这很像一个真正会被长期运行的小系统，而不是一次性脚本。尤其 metadata --json、status --json、doctor --json、check-update --json 这些控制面输出，对自动化来说很有价值。你可以把它接进巡检任务、定时同步、CI smoke check，或者别的本地工具链里。

Notion MCP 接入方式很有意思，但边界也要看清

我觉得 notion-mcp 是这个项目最有辨识度的一部分。README 说明它会通过预配置的 Codex Notion connector 做 targeted repair，而不是声称自己可以完全枚举整个工作区。没有 --page 或 --query 时，它主要针对本地桌面缓存里没有正文、缺少引用 block，或 API block sync 未完成的页面做补抓。

这种定位是合理的。MCP 在这里不是主同步层，而是补洞层。这样既能利用已连接 app 的能力，又不会把整个系统设计成强依赖外部会话。

配置示例里还能看到一些关键边界：

  • auth_path 指向 ~/.codex/auth.json
  • base_url 指向 ChatGPT apps gateway
  • connector_id 单独配置
  • max_pages 可限制抓取规模

README 还特别强调 Notion MCP mode 是 read-only and targeted，只在请求时读取 Codex bearer credential，不持久化它，并且会在落盘前移除 signed URL credentials。对涉及私有知识库的工具来说，这种“能力有边界、秘密不出库”的说明非常必要。

release 和分发流程也有可借鉴的地方

如果你喜欢看一个项目是否真的准备好给别人用，分发文档通常很说明问题。

docs/distribution.md 写得比较扎实。notcrawl 通过 GitHub Releases、Homebrew tap，以及可选的 Cloudsmith APT/RPM 仓库分发。发布前的本地检查除了 go test 和 go build，还要求跑 metadata --json、status --json、doctor --json、check-update --json 和 tui --json --limit 10 这类控制面 smoke checks。CI 也会做依赖验证、gofmt、go vet、测试、GoReleaser snapshot build 和 CodeQL。

这说明作者在意的不是“能不能编译通过”，而是“作为一个本地工具，它对外暴露的控制界面是否还能稳定工作”。这种发布标准很适合工具类项目学习。

最新 release v0.4.0 的说明不长，但能看出项目在持续修细节，例如修复 Markdown 导出路径里的 UTF-8 截断问题。对归档工具来说，这类文件路径和编码修复往往比 flashy feature 更重要，因为它直接关系到历史是否稳定、Git diff 是否干净、跨平台是否可靠。

适合什么人看

我觉得 notcrawl 特别适合几类人。

第一类，是把 Notion 当作长期工作操作台，但又不想把知识完全锁在网页里的个人开发者或小团队。你可能想把内容带到本地搜索、脚本、备份和版本控制里。

第二类，是在给 AI agent 准备可读上下文的人。很多知识库最缺的不是“内容有没有”，而是“能不能稳定地落成 agent 愿意读、也便于审计的文本和数据库”。notcrawl 在这点上非常明确。

第三类，是喜欢本地优先软件的人。它不是再造一个远程知识平台，而是把数据先拿回本地，再围绕本地资产做检索、浏览、导出和分享。

需要注意的边界

当然，它也不是万能的。

如果你只想偶尔从 Notion 导出一页文章，notcrawl 可能比简单 exporter 更重。它的价值在持续同步、本地归档、结构化检索和多出口复用，而不是一次性下载。

另外，README 已经把 notion-mcp 的实验性讲得很清楚。它依赖外部 connector 和 gateway 合约，未来可能变化，所以把它当成补洞和修复通道更合理，不要把整个知识基础设施都押在这一条链路上。

小结

openclaw/notcrawl 真正有意思的地方，不是“它能抓 Notion”，而是它把 Notion 内容转换成了更适合长期使用的本地资产: SQLite 做 canonical archive，Markdown 做 human/agent surface，再加上 git-share、TUI、JSON 控制面和可审计的发布流程，把一份网页里的知识变成可搜索、可查询、可同步、可自动化的工作底座。

如果你最近正好在想“怎么把 Notion 从一个网页工具，变成开发工作流里真正能复用的数据层”，这个项目很值得放进观察列表。