notebooklm

notebooklm 技能概览

notebooklm 是做什么的

notebooklm 技能可以让 Claude Code 查询你的 Google NotebookLM 笔记本，并基于你上传的文档返回答案。它特别适合需要有来源依据的研究、内部文档检索，或者只想围绕文档本身作答、又不想单独搭建 RAG 技术栈的人。

适合谁安装

如果你已经在使用 Claude Code，并且把 NotebookLM 当作知识库，同时希望通过浏览器自动化来处理笔记本查询、笔记本管理和认证流程，那么就适合安装这个 notebooklm 技能。它尤其适合那些引用准确性和降低幻觉比发散式头脑风暴更重要的工作流。

先了解主要取舍

这不是一个通用的提示词模板。这个技能依赖本地 Claude Code、浏览器自动化和 Google NotebookLM 的会话处理，所以更适合能够接受安装和登录步骤、但希望换来 NotebookLM 里有依据的回答，而不是模型记忆或网页搜索结果的团队。

如何使用 notebooklm 技能

安装环境与前置条件

安装 notebooklm 时，要在本地 Claude Code 环境中使用这个技能，而不是在 Web UI 里。这个仓库包含 Python 脚本和一个 requirements.txt，需要独立环境支持，同时还依赖基于 Chrome 的浏览器自动化。如果你卡在认证或浏览器配置上，先解决这些问题，再考虑扩大使用范围。

如何正确调用 notebooklm

一个高质量的 notebooklm 使用提示词，应该明确写出笔记本、任务和输出形式。例如：“使用 notebooklm 总结这个笔记本里的政策变更，并引用相关来源段落”，或者“让我的 NotebookLM 笔记本返回实施步骤，并输出简短清单”。如果你只说“帮我查文档”，这个技能就只能自己猜范围。

先读哪些文件

先看 SKILL.md，然后阅读 references/usage_patterns.md、references/api_reference.md 和 references/troubleshooting.md。如果你要新增笔记本或排查认证问题，再看 AUTHENTICATION.md，以及 scripts/ 里的脚本，尤其是 run.py、ask_question.py 和 notebook_manager.py。

更稳定产出的实用工作流

这个仓库的流程更偏向“一次问一个问题”，需要时再追问。新增笔记本时，先通过结果了解它的内容，再据此命名和描述它。查询时，尽可能附上笔记本 URL 或笔记本 ID，并明确你要的是摘要、事实检索，还是行动项提取。

notebooklm 技能常见问题

notebooklm 和普通提示词一样吗？

不一样。普通提示词可能依赖模型记忆或泛化推理，而 notebooklm 的设计目标是从你上传的 NotebookLM 来源中检索答案。这让它更适合有文档依据的工作，但也意味着结果完全取决于笔记本里实际有什么。

notebooklm 不适合做什么？

当你需要广泛的网页研究、离线文件解析，或者无法使用浏览器自动化的工作流时，不要用 notebooklm。它也不适合想要“零配置聊天体验”的场景，因为认证和本地浏览器访问本来就是工作流的一部分。

notebooklm 适合新手吗？

如果你能按几个明确步骤操作，而且手头已经有可查询的 NotebookLM 笔记本，那么它是适合新手的。相比直接聊天提示词，它没那么轻松，但这个仓库提供了直接可用的脚本、故障排查指引，以及清晰的 run.py 包装层，可以减少环境配置失误。

它适合 Workflow Automation 吗？

适合，notebooklm for Workflow Automation 在工作流起点就是整理好的文档、研究包或存放在 NotebookLM 里的知识库时尤其合适。但它不太适合高频大规模自动化，因为浏览器会话、认证状态和笔记本结构都可能成为瓶颈。

如何改进 notebooklm 技能

给它更好的笔记本上下文

质量提升最大的地方，是把笔记本范围说清楚。不要只说“总结一下这个”，而要说“总结这个产品发布笔记本，重点看截止时间、负责人和未解决风险”。提示词越能明确你真正需要做出的决策，技能就越不需要猜测意图。

用结构化输入管理笔记本

如果你要新增内容，不要把名称、描述和主题写得含糊。更好的 notebooklm 指引输入应该包括：笔记本 URL、1 句用途说明、3-5 个主题标签，以及这个笔记本是用于参考、分析，还是持续更新。这样能改善库的组织，也更利于后续检索。

注意常见失败模式

最常见的问题是认证状态漂移、用了错误的脚本路径，或者问题范围对笔记本内容来说太宽。如果答案看起来不完整，先检查笔记本里是否真的包含所需来源、是否用了 python scripts/run.py ...，以及问题是否需要缩小范围或追加一轮追问。

在第一轮答案后继续迭代

把第一轮回复当作来源核对，而不是最终稿。如果它已经接近目标但还不够可执行，就用更窄的请求继续收敛：要求具体段落、对比，或者清单。对于 notebooklm，通常最好的结果不是一次性问到底，而是先得到一个有依据的答案，再用一次有针对性的追问，逼模型带着更明确的目标重新阅读同一批来源。