Provenote MCP

Notebooklab

这份图示概览是由仓库作者编写的最短文档路径摘要。它并非实时产品录屏。

标准产品路径： messy long context -> structured insight -> note / research thread / draft -> inspectable outcome

这是第一入口。MCP、入门套件、分发页面和推广素材都是有价值的第二圈入口，但它们不应凌驾于产品路径之上。

首先要明确面向 Agent 的核心事实：Notebooklab 教会 Agent 阅读杂乱的 上下文、对其进行结构化、将其转入笔记／研究线索／草稿路径，然后才通过第一方 notebooklab-mcp 服务延续这一成果工作流。公开技能、宿主套件和注册表包 都是围绕该工作台的配套入口，而非产品的根基。

一览

如果你只想在深入阅读前快速了解真实情况，请先看这张 表：

你需要了解的内容	当前答案
产品主张	将杂乱的长上下文转化为结构化洞见和可检查的成果，并将其用于笔记、研究线索和草稿
最快的结果路径	导入一个来源 -> 运行 Auditable Markdown -> 下载一个可检查的结果
首要佐证	快速结果概览和公开佐证页面
仅属第二圈的内容	MCP、宿主套件、公开技能和分发入口
绝不能将其简化成什么	托管式一分钟试用或通用聊天封装

10 秒快速入门

如果你只想快速了解全貌，请从这里开始：

问题	首先打开	原因
“这能处理杂乱的长上下文吗？”	长上下文	这是产品的核心，而非次要用例。
“我能快速得到一个实际结果吗？”	快速获得结果	这是仓库文档中最短的本地验证流程。
“这是实打实的功能，还是只是宣传文案？”	公开证据	这里展示了证据。
“哪些内容目前仍明确不作承诺？”	项目状态	这里说明了边界。

先评估工作台，再评估周边功能。MCP 页面、入门套件、分发包和推广素材固然重要，但它们只是围绕主产品流程的第二层入口。

Notebooklab 为何存在

大多数 AI 笔记工具让生成内容变得容易，却让核实内容来源变得困难。

原始材料又长又乱时，情况会更糟：比如一份超长聊天记录、一篇复制来的论坛帖子、一份会议纪要，或一堆你不想再压缩成一份一次性摘要的网页。

Notebooklab 的设计方向正好相反：

• 将笔记、文档、音频和网页内容集中在一处
• 在长上下文消失于下一轮聊天之前，将其整理成结构化内容
• 搜索并询问这些材料，同时保留来源脉络
• 将高价值的来源处理结果转为可审计的 Markdown，并附带完整性计数器
• 让整个工作流程都有仓库文档记录且可复现

你可以把它想象成：从一堆散乱的研究标签页，转变为一个配有分类抽屉、测量工具和整洁导出通道的工作台。

如果你的问题始于“我有太多杂乱的上下文”，目前仓库文档支持的最佳答案不是再开一个空白聊天框，而是先把长上下文整理成结构化笔记，再转化为可复用的成果对象。

最快获得结果的路径

如果你想先看到一个实际成果，再了解整个工作台，请按以下简短顺序操作：

1. 导入或打开一个来源
2. 打开来源详情界面
3. 运行 Auditable Markdown
4. 下载可供检查的结果

这是目前仓库文档中最短的结果路径。 在这条成果路径清晰之前，MCP、入门套件、播客和分发入口仍属于第二圈。

如果你从杂乱的长上下文开始

目前最佳的入门路径是：

Import the source
-> Run Chat Knowledgeization
-> Inspect the structured insight
-> Continue it as a note or notebook research thread
-> Keep draft work inside the notebook lane

简单来说：先将这堆内容整理到有标签的文件夹中，再决定它们应该放进笔记、当前研究流程，还是笔记本草稿工作流。

在一个工作台中可以做什么

• 收集有依据的上下文：引入文本、文件、音频和网页来源，而不是每次会话都从空白聊天框开始。
• 继续聊天前先梳理长上下文：当材料一开始是长篇聊天记录、论坛帖子、会议记录或复制的网页讨论时，使用内置转换功能，例如 Chat Knowledgeization。
• 让结构化结果继续流转：完成长上下文梳理后，将结果继续整理为笔记、笔记本研究线程或笔记本草稿区内容，而不是让洞见就此搁置。
• 以结构化方式搜索和思考：在笔记本、提问／搜索流程、转换功能和模型设置之间切换，无需在互不相连的工具间来回跳转。
• 创建有据可查的输出：当你需要比普通聊天更强的可追溯性时，使用可审计的 Markdown 工作区；或者创建笔记本级草稿和导出包，生成可复用、可交接的成果对象。
• 顺畅交接成果：只需要文本时，下载 Markdown 草稿；需要将指标、主张／章节审查数据、PID 摘要和来源清单上下文一并交付时，则导出内容更丰富的草稿包。
• 突破纯文本工作流：基于同一来源生成适合播客的内容和可复用的转换结果。
• 通过 MCP 将内容接入编码 Agent：通过一方 MCP 服务，向 Claude Code、OpenAI Codex、Cursor 和其他支持 MCP 的宿主开放笔记本、来源、草稿、研究线程和可审计运行记录。
• 通过终端／操作界面运行相同的成果流程：如果你需要检查笔记本成果、生成可审计的 Markdown，或将研究线程交接为草稿，而不想把 MCP 宿主配置当作唯一操作路径，可以使用一方 notebooklab CLI。

如果你只记住一个首次使用规则，请记住这一点：

messy long context
-> structured insight
-> note / seeded research lane / notebook research thread
-> draft-adjacent notebook work

这是产品的核心。MCP 宿主页面排在这条路径之后，而不是之前。

生态边界

可以把这些界面想象成主工作台周围的几个房间：

• 宿主指南是侧门
• CLI 是工具车
• 主工作台仍然是从杂乱上下文通向可复用成果的路径

界面	当前是什么	不是什么
Claude Code / Codex / Cursor / OpenCode 页面	通过第一方 MCP 服务提供由仓库支持的兼容性指南，并在 examples/hosts/ 下提供可公开使用的入门包	官方合作关系、捆绑集成、插件或市场上架
notebooklab CLI	第一方本地操作界面，用于检查成果以及执行 research_thread -> draft -> verify/download 工作流	独立的分发产品线或更名后的 MCP 服务
公开技能界面	现在 public-skills/ 下已有受版本控制、可公开使用的技能包，供特定宿主的提交流程使用	公开技能目录、在线市场上架或宿主专属技能计划背书
OpenClaw	现在 ClawHub 上已有在线技能列表，地址为 https://clawhub.ai/xiaojiou176/notebooklab-mcp-outcome-workflows；兼容 OpenClaw、可公开使用的技能包仍位于 examples/hosts/openclaw 下	与 OpenClaw 的官方合作、供应商背书，或其他所有市场界面均已上线
官方 MCP Registry	现在已有一条通过 websiteUrl 指向仓库自有 MCP 文档/安装界面的 notebooklab-mcp 条目	基于软件包的公开制品、官方宿主市场上架或供应商背书
发布 / 上架 / 域名 / 商标 / 合作关系	外部决策与发布工作	已完成的仓库端事实

如果你想要最简短、同时如实体现这些边界的公开页面，请从 docs/project-status.md 开始。

如果你想要仓库自有的安装制品，而不是只有文字的设置页面，请从 examples/hosts/README.md 开始。该索引指向可公开使用的 Claude Code、Codex、Cursor 和 OpenCode 入门包，以及兼容 OpenClaw 的技能包和 ClawHub 提交包。

如果你想查看供 OpenHands/扩展或 ClawHub 风格提交使用的独立宿主技能文件夹，请从 public-skills/README.md 开始。

如果你想了解完整的声明层级，而不是从分散的宿主页面中自行推断，请参阅 docs/distribution.md。

第二层界面

明确产品路径后，请使用一个第二环页面，而不是按顺序阅读每个宿主、注册表和分发页面。

如果你需要……	首先打开此页面	为什么属于第二环
兼容宿主的 MCP 路径	docs/mcp.md	编码 Agent 的延续使用很重要，但它不是产品核心
已签入仓库的技能包制品	examples/hosts/README.md 和 examples/hosts/packet-index.json	技能包安装体现的是打包事实，并非首要入口
公开声明层级与上架边界	docs/distribution.md	这是事实记录，而不是主要的产品介绍
仍有意不作声明的内容	docs/project-status.md	这是边界页面，而非第一印象
终端/操作员工作流	docs/runbooks/operator-cli.md	工作台介绍明确后，CLI 才是延续使用的界面

这样的顺序是有意安排的：先介绍工作台，再介绍验证路径，最后介绍延续使用的界面。

产品事实边界

常规聊天和提问流程是用于探索和迭代的快捷助手界面。

如果需要更强的可追溯性，更严格的产品事实路径应通过可审计的 Markdown 和可审计运行来实现，而不能仅依赖常规聊天。

快速获取结果

这条路径以尽早看到结果为目标，而不是全面掌握整个系统。

可以把它看作最快的仓库文档所述本地验证流程，而不是一分钟的托管试用。

简单来说：这是一个 5 到 10 分钟的本地验证流程，不是一分钟的托管试用。

1. 复制本地环境模板，并添加两个快速路径所需的值。

   cp .env.example .env
   

   快速路径所需的值：

   OPEN_NOTEBOOK_ENCRYPTION_KEY=change-me-to-a-secret-string
   GEMINI_API_KEY=your-google-ai-studio-key
   

2. 启动默认本地堆栈。

   docker compose -f ops/compose/docker-compose.yml up -d --build
   

   使用这条 Docker 快速路径时，Compose 会为你注入 SurrealDB 连接默认值和一个经过验证、适用于快速路径的 Gemini 模型。因此，首次查看结果的路径只要求你预先设置加密密钥和 Gemini 密钥。

3. 打开 http://localhost:8502，让应用将你引导至 /sources 工作台，然后创建或导入一个来源，并进入来源详情视图。

4. 运行 Auditable Markdown，生成包含完整性计数器、可供下载的 markdown 报告。

5. 打开一个笔记本并创建 Draft，即可获得可在笔记本级别重复使用的结果，而不是单个来源的产物。

如果需要完整的操作说明，请直接查看 docs/quickstart.md。 如果你想要无需任何设置的托管产品，那么本仓库目前无法提供这种体验。

如果本地堆栈启动后，你更喜欢以终端为先的操作路径，请使用 docs/runbooks/operator-cli.md 中范围精简的一方操作手册。该界面以结果为先，旨在补充而非取代工作台 UI 或 MCP 兼容性页面。

如果想在阅读宿主页面之前了解生态边界，请查看 docs/project-status.md。

运行时清理操作路径

Notebooklab 将磁盘清理视为受管控的操作路径，而不是临时的“删除大文件夹”操作。

• 仓库本地依赖根目录：apps/web/node_modules
  • 此路径是由仓库管理、可重建的依赖树。
  • 它不是共享的机器缓存。
  • 只有通过仓库本地清理约定才允许清除此目录，重建命令为 cd apps/web && npm ci。
• 与仓库相关的机器缓存示例：
  • ${HOME}/.cache/notebooklab/...
  • ${HOME}/.cache/notebooklab/python/uv-cache
  • ${HOME}/.cache/notebooklab/playwright/ms-playwright
  • ${HOME}/.cache/notebooklab/ci-host/npm-cache
  • 这些是仅有的应保留在检出目录之外的仓库专用机器级下载缓存。
  • 入口包装脚本现在会自动运行由仓库管理的机器缓存清理流程，避免陈旧缓存根目录和过大的下载缓存悄然无限累积。
• 仓库本地 CI/运行时残留：
  • .runtime-cache/venv/default
  • .runtime-cache/ci-host/...
  • 这些是由仓库管理的运行时或引导环境，必须留在检出目录内，而不能泄漏到机器级缓存根目录中。
• 共享工具缓存仅供参考：
  • ${HOME}/.cache/uv
  • ${HOME}/.npm
  • ${HOME}/Library/Caches/ms-playwright
  • ${HOME}/Library/Containers/com.docker.docker
  • ${HOME}/.docker
  • 这些缓存与仓库有关，但并非仓库专用，Notebooklab 入口不得自动清除它们。
• Docker 运行时环境：
  • 本地 open-notebook-ci:* 镜像
  • buildx 构建器 / BuildKit 容器
  • docker system df -v 报告的 Docker 构建缓存
  • 这些属于 Docker 操作路径，而非仓库本地的 cleanup_runtime_cache.sh 流程

请使用明确的操作流程：

make cleanup-operator-audit
make cleanup-operator-apply

该操作流程有意拆分为多个部分：

• cleanup_runtime_cache.sh 负责仓库本地运行时/缓存环境
• cleanup_machine_cache.sh 负责 ~/.cache/notebooklab 下其余与仓库相关的下载缓存
• 入口包装脚本（run_uv_managed.sh、run-playwright-managed.sh 和 run_in_consistent_container.sh）会以应用模式调用此机器缓存流程，使仓库专用的外部缓存默认遵守 TTL/容量上限/根目录容量上限策略
• docker-buildx-clean / docker-runtime-audit 负责与仓库相关的 Docker 构建器和镜像环境

真实成果，而非只谈定位

这是当前仓库中最快的具体验证路径：

证据路径	输入	输出	可检查内容
可审计 Markdown	从文本、文件、音频或网页内容导入的一个来源	可下载的 Markdown 报告	面向覆盖度的完整性计数器，以及直接下载 Markdown 的路径
笔记草稿	多个关联到笔记的来源	可下载的笔记级 Markdown 草稿及导出包	草稿版本、章节/主张检查、导出包，以及笔记结果状态

该路径背后的当前 UI 和 API 证据已公开：

• 工作台提供 可审计 Markdown 面板，其中包含 运行 和 下载 Markdown 操作
• 面板会显示 覆盖率、缺失、重复、未引用主张、未知 PID 和 未分类
• API 通过同一工作流公开可审计运行路由

如需查看支持这些声明的文件和路由证据，请从 docs/proof.md 开始。

如需固定且可复现的本地验证流程，请使用公开验证包。

脱敏结果格式

# Auditable Markdown Report

## Source
- title: Example imported source
- lane: auditable markdown

## Integrity Counters
- coverage_rate: 0.98
- missing_count: 0
- duplicate_count: 0
- uncited_claims_count: 0

## Output
- downloadable markdown report
- inspectable sections and claims
- stronger traceability than a plain chat reply

这是经过脱敏的结果格式，并非复制的用户产物。该路径的具体产品证据位于当前 UI 面板和可审计运行 API 环境中。

人们为何青睐 Notebooklab

• 你想要的是有仓库文档支撑的工作台，而不是又一个单一聊天面板。Notebooklab 已在同一个仓库界面中整合了来源、笔记本、搜索、转换、播客和可审计的输出通道。
• 你重视有来源依据、能留下凭据的写作。相比笼统的“AI 笔记”，可审计的 Markdown 通道更具吸引力，因为它引导人们查看可检查的输出，而不只是生成的文本。
• 你想要一个值得反复访问的仓库，而不是只图一时新鲜。版本发布、变更日志、证明页面和文档让你更容易持续追踪可见的进展。
• 你想要一个真正面向公众的产品界面分支。来源信息仍然重要，但当前的支持、评审和维护边界都限定在仓库内，并且有文档说明。

为什么持续关注 Notebooklab

• 仓库展示了可验证的依据，而不只是路线图上的描述。README、证明页面、变更日志、发布说明以及议题／讨论的分流方式共同构成了公开的证据层。
• 产品形态早已不止于单一功能试验。目前的功能涵盖内容收集、搜索、研究线程、笔记本、转换、播客、来源问答和可审计的输出。
• 当前分支的边界已明确说明。这让进展更容易解读，因为支持、评审和维护责任不再被上游的模糊性所掩盖。

看证据，而非凭感觉

如果你想先看证据再做决定，请从这里开始：

你想核实的内容	查看位置
产品功能不止一个聊天界面	docs/proof.md
快速获得实际结果的方法	docs/quickstart.md
如何通过编码 Agent 使用它	docs/mcp.md
当前范围和就绪状态的边界	docs/project-status.md
当前版本的发布情况	CHANGELOG.md 和 GitHub Releases
运行时架构	docs/architecture.md
支持与安全边界	SUPPORT.md 和 SECURITY.md

发布信息的可见性只是一个公开信号，并不能自动证明最新发布事件中的构建和资源集没有问题。

按目标浏览文档

如果你的目标是……	从这里开始	然后深入了解……
评估 Notebooklab 是否值得关注	README.md	docs/proof.md、docs/faq.md
快速获得第一个可见结果	docs/quickstart.md	docs/installation.md、docs/configuration.md
通过 MCP 将其连接到编码 Agent	docs/mcp.md	docs/integrations/claude-code.md、docs/integrations/codex.md、docs/integrations/cursor.md、docs/integrations/opencode.md
了解以具体成果为先的使用场景	docs/use-cases/long-context-to-structured-notes.md	docs/use-cases/source-grounded-ai-research.md、docs/use-cases/ai-notes-with-receipts.md、docs/use-cases/source-grounded-drafts.md、docs/use-cases/source-to-verified-draft.md
了解系统结构	docs/architecture.md	services/api/main.py、apps/web/src/components/layout/AppSidebar.tsx
安全地参与贡献	CONTRIBUTING.md	docs/development.md、MAINTAINERS.md
了解当前的命名和领域边界	docs/brand-domain.md	docs/faq.md、docs/mcp.md

与编码 Agent 搭配使用

Notebooklab 提供了第一方 MCP 服务，让你能够将 Web 工作台中使用的同类成果对象带入编码 Agent 宿主。

如果你要解决的问题是杂乱的长上下文，请先从长上下文开始；当你想将这些成果对象带入宿主时，再回到这里。

当前公开支持的组合：

• 通过 MCP 将 Notebooklab 与 Claude Code 搭配使用
• 通过 MCP 将 Notebooklab 与 OpenAI Codex 搭配使用
• 通过 MCP 将 Notebooklab 与 Cursor 搭配使用
• 通过 MCP 将 Notebooklab 与 OpenCode 搭配使用

当前边界：

• 这是一个兼容性接口，并非与供应商的官方合作
• 使用供应商名称是为了说明目标宿主
• 产品核心仍是 Notebooklab 可审计、以来源为依据的成果流程，而非 MCP 控制平面本身

如果你想了解 MCP 概览，请从 docs/mcp.md 开始，然后选择与你的 Agent 运行时相匹配的宿主专属页面。

如果你想要已纳入版本控制的入门资源，而不只是配置页面，请直接前往 examples/hosts/README.md。该索引提供可公开使用的 Claude Code、Codex、Cursor 和 OpenCode 入门资源包，以及兼容 OpenClaw 的资源包和 ClawHub 提交包。

产品界面一览

当前主要工作台涵盖：

• 收集：来源和笔记本
• 处理：提问/搜索和转换
• 创作：播客、笔记本草稿和可审计的 Markdown
• 管理：模型、设置、高级控制和仓库本地治理

最适合与不太适合的情况

如果你想要以下功能，Notebooklab 会很适合你：

• 将笔记、文档、音频和网络来源转换为可检查的 Markdown 输出
• 使用有仓库文档记录的研究工作台，而不是依赖托管式 SaaS
• 评估类似 NotebookLM 的界面，它已包含笔记本、搜索、播客和可审计的输出路径
• 关注一个公开发布证明界面、发布界面和维护边界的仓库

如果你想要以下功能，Notebooklab 可能不太适合你：

• 无需本地运行环境或 Docker 的零配置托管产品
• 当前默认支持多提供商运行环境
• 小巧、用途单一的摘要工具或仅用于导出的实用工具
• 隐藏分支来源，或模糊当前由谁负责支持和审查的仓库

品牌与沿革

Notebooklab 是此仓库的公开品牌。

此仓库是对上游 Open Notebook 项目的深度产品化分支。

上游沿革对于溯源仍然重要，但当前的支持、审查、发布和协作界面仅限于此检出版本的仓库。

这意味着以下两点可以同时成立：

• Notebooklab 是人们应该记住的品牌
• 上游沿革仍应属于证据层，而非标题

仓库本地的维护和信任边界由 NOTICE.md、MAINTAINERS.md、SUPPORT.md、SECURITY.md 和 CONTRIBUTING.md 确立。

本地清理操作员路径

当磁盘空间压力来自本地 Docker 构建器和仓库本地的可重建内容时， 请使用一条明确的操作路径，而不是猜测哪个命令负责哪个 部分：

make cleanup-operator-dry-run
make cleanup-operator-rebuildable
make cleanup-operator-aggressive

这种划分是有意为之：

• docker-buildx-clean 负责处理本地 Buildx／构建器残留
• tooling/scripts/ops/cleanup_runtime_cache.sh 负责处理仓库本地的运行时和可重建部分
• apps/web/node_modules 仍是仓库本地可重建的依赖根目录，而非机器缓存
• 与仓库相关的机器缓存仍需先审查，不会由仓库自动化程序自动清除；其范围仅限下载缓存

社区

• 问题和产品讨论：GitHub Discussions
• 可复现的 Bug 和范围明确的改进：GitHub Issues
• 贡献流程：CONTRIBUTING.md
• 支持边界：SUPPORT.md
• 安全问题报告：SECURITY.md
• 协作行为准则：CODE_OF_CONDUCT.md
• 当前审查分派：CODEOWNERS
• 维护和溯源：NOTICE.md 和 MAINTAINERS.md

许可证

此分支继续依据上游许可证分发相关材料，详见 LICENSE。