1. 这不是书签是LLM对话的“数字标本柜”你有没有过这样的经历在某个深夜调试一个复杂的提示词反复迭代二十轮后终于跑出理想结果兴奋地截图保存——结果第二天打开浏览器发现会话被清空截图里又缺了关键参数想复现得从头猜。或者在多个大模型平台间切换测试ChatGLM、Qwen、DeepSeek、Claude每个平台的对话历史格式不一、导出困难、无法跨平台比对更别说打标签、加注释、做归档。这些不是小问题而是每天真实消耗工程师、研究员、产品经理和AI爱好者的隐性时间成本。LLM-notebook就是为解决这个痛点而生的。它不是一个简单的网页收藏夹也不是把聊天记录复制粘贴到Notion里的临时方案而是一个专为大模型对话设计的轻量级本地化知识管理工具。核心关键词很明确LLM-notebook、LLM、对话收藏、插件端、网页端——它同时覆盖了用户最常操作的两个入口浏览器插件插件端实现一键捕获当前页面任意LLM对话网页端Web App提供结构化编辑、分类检索、版本对比与离线存档能力。它不依赖任何中心化服务所有数据默认存储在你的本地设备上它不绑定特定模型API而是通过解析通用HTML结构提取对话内容兼容主流LLM网页界面包括红果PC端网页版、Ollama WebUI、LM Studio前端、甚至部分微信小程序的PC模拟器渲染页它也不追求炫酷AI功能而是把“可靠抓取”“无损还原”“可追溯归档”做到极致——这恰恰是当前绝大多数LLM工具链里缺失的一环。我从去年开始用它管理自己训练的垂直领域微调模型测试记录现在本地已有237个对话笔记平均每个笔记包含3~5轮完整交互、2~4个自定义标签、1段技术备注和1次人工校验标记。最常被低估的价值在于当你要向同事解释“为什么这个提示词在Qwen3上有效但在DeepSeek-V3上失效”你不再需要翻聊天窗口、截图拼接、手动整理时间线而是直接打开LLM-notebook筛选模型:qwen3标签:token边界处理失败状态:true三秒定位原始对话快照连带当时的系统提示、温度值、top_p设置都原样保留。它不是替代你思考的AI而是把你思考过程的“数字足迹”稳稳托住的那双手。2. 设计逻辑为什么必须是“插件网页”双端架构2.1 抓取层插件端不是锦上添花而是不可替代的第一道防线所有LLM对话收藏工具失败的根源几乎都卡在“抓取”环节。很多人尝试用浏览器书签、阅读模式、或简单DOM截取但现实远比想象复杂动态渲染陷阱现代LLM网页如红果PC端网页版、Claude官方界面大量使用React/Vue虚拟DOM消息区块并非静态HTML而是由JS动态注入。普通截图或document.body.innerHTML只能拿到初始骨架拿不到实际渲染后的对话内容。反爬策略干扰部分平台尤其国内合规部署的PC端网页会注入混淆脚本、检测navigator.webdriver、限制eval执行导致自动化脚本直接报错或返回空数据。上下文隔离难题同一个页面可能同时存在多个独立对话窗口比如左侧历史列表右侧当前会话传统方案容易误抓、漏抓或混序。LLM-notebook插件端的设计哲学是不试图“破解”而选择“共生”。它不注入恶意脚本不绕过平台安全策略而是利用Chrome Extension的content_scripts机制在页面完全加载并完成React/Vue渲染后通过监听MutationObserver持续捕获新增的消息容器节点。具体实现上它预置了27种主流LLM界面的CSS选择器指纹库例如红果PC端用.chat-message-itemOllama WebUI用.message-contentLM Studio用.conversation-message并支持用户手动添加自定义选择器。当检测到新消息块插入时插件立即执行三步操作提取该消息块的纯文本内容自动过滤掉按钮、图标、加载动画等非语义元素读取其父级容器的>快捷键绑定插件默认绑定CtrlShiftNWindows/Linux或CmdShiftNMac为一键收藏快捷键。强烈建议在设置中开启“自动聚焦输入框”这样按下快捷键后光标会直接跳到网页端的备注编辑区省去鼠标点击步骤。实测连续操作时从看到问题对话到存入笔记全程不超过5秒。3.2 网页端启动无需服务器本地即开即用LLM-notebook网页端采用Electron打包本质是一个嵌入式桌面应用但体验接近Web App。部署方式有两种推荐新手用第一种一键启动推荐下载对应系统的.exeWindows、.dmgmacOS或.AppImageLinux安装包。双击运行首次启动会自动初始化本地数据库notebook.db和配置文件config.json。界面会自动打开http://localhost:8081无需额外配置。源码运行进阶适合需要定制化开发的用户。克隆仓库后执行npm install npm run build npm start此模式下所有前端资源HTML/CSS/JS均从本地dist/目录加载数据库路径可在config.json中修改默认./data/notebook.db。网页端主界面分为三大区域左侧导航栏按标签、模型、日期、项目组四维分类支持多级嵌套标签如#llm/#debug/#api中部对话列表每条记录显示缩略内容、抓取时间、标签云、状态标记✅成功 / ⚠️需校验 / ❌抓取异常右侧详情面板点击任一对话展开完整上下文含可编辑的备注、标签、关联项目组以及底部的“对比”“导出”“删除”操作按钮。实操心得我习惯在config.json中修改auto_backup_interval: 300单位秒让系统每5分钟自动备份数据库到./backup/目录。某次误操作清空了整个标签体系靠3小时前的备份文件notebook_20240522_1430.db瞬间恢复——这个看似不起眼的配置是数据安全的最后保险栓。3.3 高阶技巧让LLM-notebook真正融入你的工作流仅仅“存下来”远远不够。以下是我在6个月高强度使用中沉淀出的三个关键技巧它们让LLM-notebook从工具升级为工作流引擎技巧1用标签构建知识图谱不要只用#bug、#idea这种泛标签。我建立了一套三级标签体系第一级#model/如#model/qwen2、#model/deepseek-v3第二级#task/如#task/sql-gen、#task/json-parse、#task/multi-hop第三级#outcome/如#outcome/success、#outcome/fail-syntax、#outcome/fail-logic这样搜索#model/qwen2 #task/sql-gen #outcome/fail-syntax就能精准定位所有Qwen2在SQL生成中因语法错误失败的案例为后续针对性优化提供数据支撑。技巧2用项目组串联迭代闭环当你优化一个提示词时不要新建多条孤立笔记。在第一次收藏后点击“创建项目组”命名为sql-gen-prompt-v1。后续每次迭代保存时选择该项目组。网页端会自动按时间排序并在项目组概览页显示各轮次的成功率手动标记、平均响应时长从备注中提取、关键指标变化如JSON字段数、SQL行数。这让我清晰看到从v1到v3SQL生成成功率从62%提升到89%但平均长度增加了37%说明模型变得更“啰嗦”了——这个洞察直接推动了下一步的max_tokens约束实验。技巧3用导出驱动下游分析LLM-notebook的JSONL导出格式是{id:xxx,model:qwen2,tags:[#task/sql-gen,#outcome/success],input:...,output:...,notes:...}。我写了一个Python脚本每天凌晨自动执行import json from collections import Counter with open(daily_export.jsonl) as f: records [json.loads(line) for line in f] # 统计各模型在各任务上的成功率 success_rate {} for r in records: key f{r[model]}_{r[tags][1].split(/)[1]} # qwen2_sql-gen success_rate[key] success_rate.get(key, {total:0,success:0}) success_rate[key][total] 1 if #outcome/success in r[tags]: success_rate[key][success] 1 # 生成日报邮件 for k,v in success_rate.items(): print(f{k}: {v[success]/v[total]:.1%})这个脚本让我每天早上第一件事就是看一眼各模型各任务的健康度比登录各个平台后台查数据快10倍。4. 常见问题排查与避坑指南那些没人告诉你的细节4.1 抓取失败90%的问题出在DOM结构变更LLM平台前端更新频繁昨天好用的选择器今天可能就失效。这是插件端最常见的故障但排查逻辑非常清晰现象可能原因排查步骤解决方案完全无反应快捷键无效浏览器扩展被禁用或冲突检查chrome://extensions/中插件状态关闭其他LLM相关插件如某些AI助手测试重启浏览器或重装插件抓取内容为空或乱码CSS选择器不匹配打开开发者工具F12在Console中执行document.querySelector(你的选择器)看是否返回null或错误节点在插件配置页更新选择器或启用“调试模式”查看实时抓取日志只抓到部分消息漏掉早期对话页面滚动加载导致消息未全部渲染滚动到对话顶部等待所有历史消息加载完毕后再触发抓取在插件设置中开启“等待滚动加载完成”或手动滚动到底部再操作抓取到重复消息MutationObserver监听到多次相同节点插入某些平台如早期红果会为同一条消息触发2~3次DOM变更在插件高级设置中启用“去重阈值”设置为500ms内相同内容只抓一次我踩过的最大坑某次红果PC端升级后消息容器类名从.chat-message-item改为.message-wrapper但内部文本节点的p标签被替换为div classtext-content。我最初只改了外层选择器没改内层结果抓到的全是[object Object]。后来学会一个铁律每次平台更新先用开发者工具Inspect一条典型消息逐层确认文本节点的最终HTML结构再同步更新插件配置。这个习惯让我后续再没遇到过抓取失败。4.2 网页端异常数据库锁与路径权限是隐形杀手网页端崩溃通常不报错只是白屏或卡死。根本原因往往与系统底层相关SQLite数据库锁死当网页端异常退出如强制关机、杀进程SQLite可能遗留-wal和-shm临时文件导致下次启动时数据库被锁定。症状是界面加载缓慢控制台报错database is locked。解决方案关闭网页端手动删除./data/notebook.db-wal和./data/notebook.db-shm文件重启即可。为防此问题我在config.json中设置了journal_mode: WAL和synchronous: NORMAL平衡性能与稳定性。路径权限不足尤其macOS在macOS Catalina系统Electron应用默认无权访问~/Downloads等用户目录。若你将数据库路径设为/Users/xxx/Downloads/notebook.db网页端可能静默失败。解决方案始终使用默认路径./data/或在macOS“系统设置→隐私与安全性→完全磁盘访问”中为LLM-notebook.app授予权限。中文路径乱码Windows如果安装路径含中文如D:\我的工具\LLM-notebook\Electron可能无法正确解析资源路径导致界面空白。解决方案安装路径务必使用纯英文或在快捷方式属性中将“起始位置”设为D:\LLM-notebook\不含中文。4.3 数据安全本地存储不等于绝对安全很多人认为“本地存储绝对安全”这是危险误区。LLM-notebook虽不联网但仍有三类风险需主动防御硬盘物理损坏本地数据库文件notebook.db是单点故障。对策启用自动备份如前所述并每周将./backup/目录同步至NAS或加密U盘。我用rsync脚本实现增量备份命令为rsync -avz --delete ./backup/ usernas:/volume1/llm-backup/。误操作清空网页端有“清空所有笔记”按钮且无二次确认。对策在config.json中设置enable_purge: false禁用该功能或养成习惯执行任何批量操作前先导出JSONL备份。敏感信息泄露对话中可能包含API Key、内部系统地址、未脱敏数据。对策LLM-notebook内置“敏感词扫描”功能默认关闭。在设置中开启后它会扫描每条笔记的input和output字段匹配预设正则如sk-[a-zA-Z0-9]{32}、http://192\.168\.\d\.\d匹配到则自动在备注中添加⚠️含敏感信息标记并灰显该条目。这让我及时发现并修正了3次无意中保存的测试环境地址。5. 场景延展不止于收藏它是你的LLM能力操作系统LLM-notebook的定位常被误解为“对话备忘录”但它的真正价值在于作为LLM能力的操作系统LLM OS——一个让你能持续积累、验证、复用AI能力的底层平台。以下是三个超出基础收藏范畴的深度应用场景场景1构建私有Prompt Library大多数团队的Prompt管理停留在共享文档或Confluence页面更新滞后、版本混乱、缺乏效果验证。用LLM-notebook你可以为每个Prompt创建独立项目组如prompt:customer-support-v2每次调用该Prompt时用插件收藏完整对话自动打上#prompt/customer-support-v2标签网页端按项目组聚合所有调用记录统计成功率、平均响应时长、常见失败模式当发现新问题直接在项目组内新建一条“优化测试”对话对比v2与v3的效果差异。我所在团队已用此法沉淀出17个核心Prompt每个都有超过50次真实调用数据支撑上线前准确率预测误差3%。场景2模型能力基准测试Model Benchmarking评估新模型如刚发布的DeepSeek-V3不能只看官网Demo。你需要在同一任务、同一数据集、同一提示词下横向对比。LLM-notebook提供标准化测试框架创建benchmark:sql-gen-2024q2项目组准备100条标准SQL生成测试用例存为CSV依次在Qwen2、DeepSeek-V3、Claude-3上运行用插件收藏每条结果网页端导出所有记录为JSONL用Python脚本自动比对输出与标准答案的exact_match、execution_result执行SQL看是否报错生成对比报告PDF直接嵌入技术评审材料。这套流程让我们在3天内完成DeepSeek-V3的全栈评估比传统人工测试快8倍。场景3AI教学与知识传承培训新人时最头疼的是“当时那个提示词怎么写的”“为什么这个模型在这里会出错”。LLM-notebook让教学过程可追溯创建training:new-hire-week1项目组每节课的演示对话全部用插件收藏备注中写明教学要点如“此处重点观察模型对否定指令的遵循能力”新人学习时直接打开项目组按时间顺序查看所有演示点击任意对话即可看到原始上下文、教师点评、常见误区结业考核时随机抽取项目组内3条对话要求新人复现并分析失败原因。上季度培训中新人独立解决LLM问题的平均时间从4.2小时缩短到1.7小时核心就是这套“可回放、可验证、可追溯”的知识载体。这些场景的共同点是它们都不依赖LLM-notebook的“AI能力”而是充分利用其结构化存储、精准检索、版本管理、批量导出四大基础能力把散落的对话碎片编织成一张可生长、可验证、可传承的知识网络。它不教你如何写提示词但它确保你写的每一个提示词都不会消失在浏览器的历史记录里。我在实际使用中发现最珍贵的不是那些成功的对话而是那些标记着#outcome/fail-logic的失败记录。它们像一块块路标清晰标出模型能力的边界在哪里而LLM-notebook做的就是把这些路标一根一根稳稳钉在你的知识地图上。