OpenClaw+ollama-QwQ-32B搭建个人知识库：从收集到生成

1. 为什么需要自动化知识管理

作为一个每天要处理大量技术资料的研究者，我发现自己陷入了一个怪圈：收藏的文章越来越多，但真正消化吸收的内容却越来越少。浏览器书签栏堆满了"稍后阅读"的标签，Notion里散落着各种未整理的片段。直到某天搜索一个明明记得收藏过的解决方案时，花了半小时却一无所获——这种挫败感让我决定用技术手段解决知识管理问题。

传统的手动整理方式有三个致命缺陷：时间成本高（阅读+摘要+归档至少30分钟/篇）、执行不连贯（收藏和整理往往间隔数日）、结构不一致（不同时期的笔记格式各异）。而OpenClaw+ollama的组合恰好能解决这些问题：前者提供自动化执行能力，后者负责内容理解与摘要生成。经过两周的实践，我的个人知识库终于实现了从"信息坟墓"到"思维外脑"的转变。

2. 技术栈选型与准备

2.1 核心组件分工

在这个自动化方案中，每个组件都有不可替代的作用：

• OpenClaw 作为"数字员工"，负责执行所有操作流程：抓取网页内容、调用模型接口、操作Notion数据库。它的鼠标键盘操控和浏览器自动化能力，使得处理非API友好的网站成为可能。
• ollama-QwQ-32B 扮演"内容分析师"，完成文本摘要、关键词提取、知识关联等认知型任务。选择32B版本是因为在测试中发现，它对技术文档的语义理解明显优于小参数版本。
• Notion 作为"知识中枢"，提供结构化的存储和检索界面。其灵活的database属性和API支持，非常适合作为知识库的载体。

2.2 环境配置要点

在MacBook Pro(M1, 16GB)上的具体配置过程：

# 安装OpenClaw核心组件
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --mode=Advanced

# 部署ollama模型服务
ollama pull qwq:32b
ollama serve --port 11434

配置OpenClaw连接本地模型时，需要特别注意~/.openclaw/openclaw.json中的这段配置：

{
  "models": {
    "providers": {
      "local-ollama": {
        "baseUrl": "http://localhost:11434",
        "api": "openai-completions",
        "models": [
          {
            "id": "qwq-32b",
            "name": "Local QwQ-32B",
            "contextWindow": 32768
          }
        ]
      }
    }
  }
}

验证服务是否联通时，可以用这个测试命令：

openclaw models test qwq-32b -p "请用一句话说明量子计算的优势"

3. 构建自动化知识流水线

3.1 流程设计与技术实现

整个系统的工作流像一条数字生产线：

1. 信息捕获阶段：通过浏览器插件将目标页面保存到指定Chrome书签文件夹（我命名为"待处理"）
2. 内容提取阶段：OpenClaw每天02:00自动：
   • 打开Chrome并加载书签
   • 逐个访问"待处理"文件夹中的链接
   • 使用document.body.innerText获取正文内容
3. 知识加工阶段：内容发送给ollama处理，获取：
   • 技术要点摘要（200字左右）
   • 5个关键词标签
   • 相关知识点联想
4. 存储入库阶段：通过Notion API创建包含完整元数据的页面：
   • 原始URL和抓取时间
   • 结构化摘要内容
   • 自动生成的分类标签

这个流程最精妙的部分在于异常处理机制。当遇到付费墙或登录限制时，系统会：

• 保存页面截图到本地
• 记录拦截元素特征（如弹窗class）
• 通过飞书通知我人工介入

3.2 核心技能开发

实现上述功能主要依赖两个自定义Skill：

1. 网页内容提取器(web-extractor)

async function extractMainContent(page) {
  const selectors = ['article', '.post-content', 'main'];
  for (const sel of selectors) {
    const element = await page.$(sel);
    if (element) {
      return await element.evaluate(el => el.innerText);
    }
  }
  return await page.evaluate(() => document.body.innerText);
}

2. 智能摘要生成器(summarizer) 通过设计特定的prompt模板，显著提升摘要质量：

你是一位技术专家助理，请为以下内容生成结构化摘要：
1. 核心观点（不超过50字）
2. 关键技术（3-5个术语）
3. 创新点（与既有方案对比）
4. 潜在应用场景

待处理内容：{{CONTENT}}

4. 实践中的挑战与解决方案

4.1 内容质量波动问题

初期直接使用网页全文会导致ollama处理效果不稳定。通过A/B测试发现，预处理策略对最终效果影响巨大：

• 最佳实践：先移除导航栏/页脚/广告（通过DOM选择器），再提取正文
• 备用方案：当无法识别正文区域时，使用Readability.js算法净化内容
• 特殊情况：对于PDF/PPT等文档，先转换为文本再处理

4.2 Notion字段映射难题

Notion database需要预定义字段结构，而不同来源的内容特征各异。我的解决方案是：

1. 建立弹性字段体系：
   • 必填字段：标题、来源、摘要
   • 可选字段：代码示例、图表说明、参考文献
2. 使用ollama自动判断内容类型：

   def detect_content_type(text):
       if 'def ' in text and '\n' in text: return 'code'
       if any(word in text for word in ['实验','结果']): return 'research'
       return 'article'
   

4.3 长期运行的稳定性

7×24小时运行的系统需要特别注意：

• 内存管理：配置OpenClaw每处理5个页面后自动重启浏览器实例
• 失败重试：对网络错误实施指数退避重试机制
• 结果验证：添加摘要质量检查步骤（如关键词数量验证）

5. 效果评估与使用建议

经过一个月的运行，这个系统已经帮我处理了287篇技术文章，Notion知识库的检索效率提升了约3倍。几个意外收获：

• 通过关键词关联发现了多个跨领域的技术相似性
• 自动生成的"每周知识简报"成为团队内部的技术风向标
• ollama在持续训练中展现出对个人偏好的适应能力

对于想要复现这个方案的朋友，我的实用建议是：

1. 从小规模开始：先用20-30篇文章测试流程稳定性
2. 设计校验机制：初期每天人工抽查10%的处理结果
3. 渐进式复杂化：先实现基础摘要，再逐步添加思维导图等高级功能
4. 注意token消耗：32B模型处理长文档时成本较高，可设置单篇字数上限

这个项目的真正价值不在于技术本身，而在于它改变了我的知识获取方式。现在每次遇到有价值的内容，我知道它会被妥善地消化、吸收、归档，最终成为随时可调用的思维资产。这种确定性，或许就是技术给我们最好的礼物。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。