8.8 KiB
Obsidian 知识库维护技能 - 实施计划
目标: 构建可扩展的多源内容知识库维护系统,支持B站/YouTube/知乎/本地Markdown汇入Obsidian 方法: 模块化架构 + 源适配器模式 + 主题聚合机制 预估总时间: ~4-6小时(可并行)
多代理并行模型分配策略
统一使用最强模型:kimi-coding/k2p5
追求代码质量和AI分析能力,不节省token
| Checkpoint | 任务类型 | 模型 |
|---|---|---|
| Checkpoint 1-2 | 项目脚手架、数据模型 | kimi-coding/k2p5 |
| Checkpoint 3 | B站适配器开发 | kimi-coding/k2p5 |
| Checkpoint 4 | 内容处理管道 | kimi-coding/k2p5 |
| Checkpoint 5 | CLI命令实现 | kimi-coding/k2p5 |
| Checkpoint 6-7 | 模板与测试 | kimi-coding/k2p5 |
实现方式:
# 所有子任务统一使用最强模型
sessions_spawn({
"task": "...",
"model": "kimi-coding/k2p5",
"runTimeoutSeconds": 600
})
Checkpoint 1: 项目脚手架与配置 (~30min)
-
Task 1.1: 重命名/创建技能目录
skills/obsidian-kb/- Action: 基于现有
bilibili-obsidian迁移或新建结构 - Verify:
skills/obsidian-kb/存在且包含SKILL.md
- Action: 基于现有
-
Task 1.2: 创建技能元数据文件
SKILL.md- Action: 编写技能描述、命令列表、使用说明
- Verify: 包含所有命令:
/kb-subscribe,/kb-inbox,/kb-process,/kb-skip,/kb-status,/kb-search
-
Task 1.3: 创建项目结构
obsidian-kb/ ├── src/ │ ├── __init__.py │ ├── cli.py # 命令行入口 │ ├── config.py # 配置管理 │ ├── models.py # 统一元数据模型 │ ├── pipeline.py # 内容处理管道 │ ├── storage.py # 本地存储/Inbox管理 │ ├── git_sync.py # Git同步 │ └── sources/ │ ├── __init__.py │ ├── base.py # 源适配器基类 │ ├── bilibili.py # B站适配器 │ ├── youtube.py # YouTube适配器 (placeholder) │ ├── zhihu.py # 知乎适配器 (placeholder) │ └── local.py # 本地Markdown扫描 │ └── templates/ │ ├── light_video.md │ ├── tutorial_video.md │ ├── article.md │ └── topic_index.md # 主题聚合页模板 ├── tests/ └── requirements.txt- Verify: 目录结构完整
-
Task 1.4: 创建配置模板
config.yaml.example- Action: 定义所有配置项(API keys, Git repo, 路径等)
- Verify: 包含: kimi_api_key, git_repo, git_token, obsidian_path, quality_threshold
Checkpoint 2: 核心数据模型与存储 (~40min)
-
Task 2.1: 实现
models.py- 统一元数据模型- Action: 定义 Content 类,包含所有核心字段和 source_meta 扩展
- Verify: 可以通过单元测试创建 Content 对象,序列化/反序列化正常
-
Task 2.2: 实现
storage.py- Inbox/Topics存储管理- Action:
- Inbox 队列管理(CRUD操作)
- Topics 目录结构管理
- 主题聚合页检测(相似度>阈值时归入同一主题)
- Verify: 可以: 添加候选到Inbox、移动到Topics、检测主题相似度
- Action:
-
Task 2.3: 实现
git_sync.py- Git自动同步- Action:
- 检测文件变更
- 自动生成commit message
- 执行commit + push
- Verify: 创建测试文件后能自动commit到指定repo
- Action:
Checkpoint 3: 源适配器基类与B站实现 (~60min)
-
Task 3.1: 实现
sources/base.py- 源适配器基类- Action: 定义抽象基类 SourceAdapter,包含3个抽象方法
- Verify: 无法直接实例化,子类必须实现所有方法
-
Task 3.2: 实现
sources/bilibili.py- B站适配器- Action:
- fetch_new(): 获取收藏夹/UP主动态
- extract_content(): 从URL提取元数据
- get_transcript(): 获取字幕/AI生成摘要
- Verify: 可以成功获取公开收藏夹内容,提取字幕
- Action:
-
Task 3.3: 实现
sources/local.py- 本地Markdown扫描- Action: 扫描指定目录的Markdown文件,提取元数据
- Verify: 能识别本地MD文件的YAML frontmatter
-
Task 3.4: 创建源注册表
sources/__init__.py- Action: SourceRegistry,支持动态注册新适配器
- Verify: 可以通过名称获取对应适配器实例
Checkpoint 4: 内容处理管道 (~50min)
-
Task 4.1: 实现轻量扫描阶段
- Action:
- 调用AI生成一句话摘要
- 提取关键词
- 质量评分(0-10)
- Verify: 输入视频URL,输出包含摘要、关键词、评分的Content对象
- Action:
-
Task 4.2: 实现深度分析阶段
- Action: 根据内容类型选择分析策略,生成结构化数据
- Verify: 短视频输出轻量结构,长教程输出详细时间轴
-
Task 4.3: 实现自适应模板系统
- Action: 创建模板渲染器,根据content_type和duration选择模板
- Verify: 不同类型内容渲染出不同格式的Markdown
-
Task 4.4: 实现主题聚合检测
- Action: AI对比新内容与现有Topics,计算相似度,建议聚合
- Verify: 相似内容能被正确归入同一主题目录
-
Task 4.5: 实现
pipeline.py- 整合所有阶段- Action: 编排完整流程: 轻量扫描→入库→深度分析→生成笔记→Git同步
- Verify: 端到端测试通过
Checkpoint 5: CLI命令实现 (~40min)
-
Task 5.1: 实现
/kb-subscribe命令- Action: 支持订阅B站收藏夹、UP主、YouTube频道等
- Verify: 可以添加订阅,存储到配置文件
-
Task 5.2: 实现
/kb-inbox命令- Action: 显示待处理候选列表,带摘要和评分
- Verify: 可以列出Inbox中的内容,格式清晰
-
Task 5.3: 实现
/kb-process命令- Action: 处理指定ID或全部确认的内容
- Verify: 可以深度分析并生成笔记
-
Task 5.4: 实现
/kb-skip命令- Action: 跳过指定内容,记录跳过原因
- Verify: 内容从Inbox移除,可选记录原因
-
Task 5.5: 实现
/kb-status命令- Action: 显示同步状态、Inbox数量、今日处理量
- Verify: 输出包含Git状态、Inbox统计
-
Task 5.6: 实现
/kb-search命令- Action: 搜索已处理的笔记(标题、标签、内容)
- Verify: 能根据关键词返回相关笔记列表
Checkpoint 6: 模板与文档 (~30min)
-
Task 6.1: 创建所有Markdown模板
- Action:
- light_video.md
- tutorial_video.md
- article.md
- topic_index.md
- Verify: 模板包含所有变量占位符,渲染测试通过
- Action:
-
Task 6.2: 完善
SKILL.md使用文档- Action: 更新完整的使用说明、配置指南、示例
- Verify: 新用户能根据文档独立完成配置和使用
-
Task 6.3: 创建
README.md- Action: 项目介绍、功能特性、安装说明
- Verify: 包含架构图、快速开始、命令参考
Checkpoint 7: 测试与验证 (~30min)
-
Task 7.1: 编写单元测试
- Action: 测试核心模块: models, storage, pipeline
- Verify:
pytest全部通过
-
Task 7.2: 集成测试
- Action: 端到端测试: 订阅→爬取→分析→生成→同步
- Verify: 完整流程在测试环境跑通
-
Task 7.3: 手动验证
- Action: 实际处理1-2个B站视频,检查输出
- Verify: Markdown格式正确,Git同步正常,Obsidian可读
Verification Criteria
- 所有Checkpoints完成
- 可以订阅B站收藏夹并获取新内容
- Inbox预览功能正常,显示摘要和评分
- 确认处理后生成格式正确的Markdown
- 相似内容自动归入同一主题
- Git自动同步工作正常
- 代码通过基本测试
- 文档完整可理解
执行选项
选项1: 单代理(本会话)
- 我按顺序执行所有任务
- 每个Checkpoint完成后汇报进度
- 使用
kimi-coding/k2p5模型 - 适合:需要频繁确认、逐步调整方向
选项2: 多代理并行(推荐)
- 同时启动多个子代理并行工作:
| 代理 | Checkpoint | 任务 | 模型 |
|---|---|---|---|
| 代理A | 1-2 | 项目基础 + 数据模型 | kimi-coding/k2p5 |
| 代理B | 3 | B站适配器 | kimi-coding/k2p5 |
| 代理C | 4 | 内容处理管道 | kimi-coding/k2p5 |
| 代理D | 5 | CLI命令 | kimi-coding/k2p5 |
| 代理E | 6-7 | 模板 + 测试 | kimi-coding/k2p5 |
- 最后我来集成所有模块
- 优势: 速度最快,全部用最强模型保证质量
推荐: 选项2(多代理并行)
你选择哪种执行方式?