obsidian-diary

name	obsidian-diary
description	将会话内容总结并写入 Obsidian 工作日志或个人日记，管理待办事项。当用户说「记录一下」「保存这个」「记一笔」「总结工作」「更新日志」「写日记」「记录会议」「更新待办」，或会话末尾有多个可记录的事件/结论/决策时，必须加载此技能。工作相关（公司代码开发、方案设计、运维部署、正式会议）用 work 变体；个人方向（技术探索、学习笔记、投资复盘、生活记录、个人开源项目）用 personal 变体。会话末尾有结构化结论、技术选型、部署结果、调研成果时，在结束前主动询问用户是否需要记录。

Obsidian 日记与待办管理

将当前会话的内容总结并写入 Obsidian 日记，同时搜索、更新、新增待办。

日记的目的是给人看的记录，不是 agent 工作日志。它的价值在于几个月后翻回来看还能知道那天发生了什么、为什么做了某个决策。所以必须做两件事：按主题组织（而不是按对话时间顺序平铺），合并相关事件（而不是一条一条回忆 dump）。

重要：日记路径约定

日记文件使用 YYYY/MM/ 双层子目录 组织，不是直接放在日记根目录下。

变体	根目录	子目录	完整路径示例
work	工作日志/	YYYY/MM/	工作日志/2026/05/2026年5月18日星期一.md
personal	个人日记/	YYYY/MM/	个人日记/2026/05/2026年5月18日星期一.md

陷阱： 用 write_file 直接写 个人日记/2026年5月18日星期一.md（平级路径）会创建错误位置的文件。必须先确保 YYYY/MM/ 子目录存在，再写完整路径。用 locate action 获取正确路径后再写入。

变体选择

根据会话内容判断使用哪个变体：

• work → 公司项目、部署运维、代码开发（公司仓库）、正式会议、团队协作
• personal → 个人技术探索、学习笔记、投资、生活记录、个人开源项目/独立仓库维护

边界情况判断

场景	变体	判断依据
公司 Git 仓库的代码开发/运维	work	公司仓库、团队协作、交付物
个人 GitHub 仓库（如 pi-extensions、opencode fork）	personal	独立项目、非公司交付物
下班后学的新技术（与公司项目无关）	personal	个人技能提升
工作相关但属于个人探索性质的原型验证	personal	非交付物、非正式项目
混合内容（同一会话既有工作又有个人）	拆分记录	分别写入两个变体

判断核心：内容是不是公司交付物/团队协作？ 是 → work；否 → personal。不要因涉及代码/Git 操作就自动归 work。

为什么切分？受众和用途不同。 工作日志会被同事和管理层查看（或作为日报素材），需要正式、客观、按子系统组织。个人日记只有自己看，可以更轻松，按自己的兴趣领域组织。混合内容时拆分后分别写入两个变体——投资分析归 personal，线上故障排查归 work。

首次配置

脚本运行前需要配置文件 ~/.config/cnife-skills/obsidian-diary.json。

当脚本输出 CONFIG_MISSING=true 时，执行以下流程：

1. 询问用户每个 vault 的 Obsidian 根目录（本地绝对路径），例如：
   • work vault：/mnt/c/Obsidian
   • personal vault：/mnt/c/Obsidian
2. 其余字段（diary_dir、template、exclude_meta）使用默认值，除非用户明确要求修改
3. 用 Write 工具创建配置文件（先确保目录存在）：

{
  "vaults": {
    "work": {
      "base": "<用户提供的路径>",
      "diary_dir": "工作日志",
      "template": "日志模板.md",
      "exclude_meta": ["AGENTS.md", "任务.md", "日志模板.md"]
    },
    "personal": {
      "base": "<用户提供的路径>",
      "diary_dir": "个人日记",
      "template": "日记模板.md",
      "exclude_meta": ["AGENTS.md"]
    }
  }
}

4. 创建完成后重新运行脚本。

脚本

所有文件系统操作通过 scripts/obsidian-helper.py 完成，脚本路径相对于本 skill 目录。

必须使用 uv 运行（自动管理依赖）：

uv run --script scripts/obsidian-helper.py --vault <work|personal> --action <action>

可用 action：

• context — 一次调用返回所有上下文（路径 + 规则 + 待办 + 近期摘要 + 今日日记大纲）
• locate — 获取今日日记路径、模板路径、存在状态
• create — 确保今日日记存在，不存在则从模板创建
• todos — 扫描近期日志，列出未完成待办
• recent — 列出近期修改的日志文件（支持 --limit N 限制数量）
• read — 读取指定文件或今日日记

注意事项（必须先读）

• 必须加载本 skill 后才能写日记。直接 write_file/patch 会绕过 context 步骤，丢失 DIARY_EXISTS 状态，极可能覆盖已有内容。
• 先读后写：即使今天日记已存在，也要先 context 获取当日内容摘要和大纲，用 patch 追加而非 write_file 覆盖。

主动检查与询问

在以下时机主动询问用户是否需要记录，不要自行写入：

1. 会话末尾出现结束信号：用户说「差不多了」「先这样」「收尾吧」「没别的事了」等
2. 会话中有明确的结构化产出：技术选型结论、部署完成、调研报告
3. 用户已完成主要任务，处于收尾阶段

询问格式：

• 能判断内容性质时：「要我把这次（工作/学习）记录到（工作/个人）日记吗？」
• 没有上下文无法判断时：「今天的内容需要记到日记吗？是工作相关的还是个人的？」

为什么是询问而不是直接写？用户对日记内容有掌控欲——什么语气、记什么、不记什么，只有用户自己知道。主动询问是"推一把"和"不越权"的平衡。

如果没有会话上下文（例如在空会话或新对话中被调用），先问用户今天做了什么，再提议记录。

工作流

步骤 1：收集上下文（1 次调用）

uv run --script scripts/obsidian-helper.py --vault <变体> --action context

输出包含五个段落，一次拿齐：

• 路径信息：DIARY_PATH、DIARY_EXISTS、DATE
• RULES：对应变体的格式规则（自动从 references 文件读取）
• TODOS：近期未完成待办（14 天）
• RECENT：最近 2-3 篇日记的前 30 行摘要（了解近期上下文和写作风格）
• TODAY：今日日记完整内容，含大纲和内容摘要

如果 DIARY_EXISTS=false，脚本会自动从模板创建后再读取。

步骤 2：主题识别与聚合（最重要的步骤）

这是区分「流水账」和「好日记」的关键。不要直接按对话时间顺序写——先做主题分析。

2a. 列举所有 distinct topics

扫描整个会话（包括工具输出），列出所有独立的主题。例如今天的会话如果包含 install daisy → 分析中创智领 → 跑红利筛选 → 分析三只持仓 → CouchDB 部署 → Git 备份 → SMB 备份，第一轮清单是 7 个 topic。

2b. 聚合归域

把语义相近的 topic 合并为同一个主题域。判断依据：这些事是否属于同一个目的或领域？

散落的 topic	聚合后的主题域	理由
daisy 安装 / 中创智领分析 / 红利筛选 / 三只持仓分析	金融研究	都属于"用 daisy 做证券分析"这个会话目标
CouchDB 架构评估 / 阿里云部署 / 踩坑记录 / 客户端配置	Obsidian 同步方案部署	都属于"LiveSync + CouchDB 落地"
Git 备份 / Hermes SMB 备份 / cron 一览	基础设施配置	都属于"备份和自动化"

合并规则：

• 同一主题域的多个事件合并为 1 个 # 标题，其下用子 bullet 展开
• 每个子 bullet 1-2 行，只写结论和关键数据，不要展开细节
• 明显不同域的事件不能硬塞在一起（daisy 技能本身是金融研究的一部分，但 CouchDB 部署就不是）

2c. 检查今日日记大纲（来自步骤 1 的 ## 大纲）

新内容能塞进已有章节的，不新开一段。 例如今天继续做投资分析，而日记里已经有 # 金融研究 段落，就在那个段落追加新 bullet，不要另起 # 金融研究（续）。

没找到对应章节的 → 创建新的一级标题，插入到日记末尾（待办块之后）。

2d. 排序

同一篇日记内，按重要性排序主题——通常工作/分析类在前、配置类在后。个人日记可以参考：投入时间多的 > 产出多的 > 顺手做的。

步骤 3：提取关键事件并写入

3a. 提取内容

每个主题域内，从会话中识别关键事件，每个事件 1-2 行：

事件类型	记录要点
实现了功能	功能名称 + 核心特性 + 关键技术决策
调研了方案	调研对象 + 结论 + 选型判断（为什么选 A 不选 B）
修复了问题	问题 + 根因 + 修复方式
做了决策	决策内容 + 理由 + 放弃的替代方案
部署/配置	环境 + 关键参数 + 验证结果

为什么只写 1-2 行？日记是索引，不是完整文档。 详细配置、代码片段、完整对话记录在独立文件里，日记只写结论和 links。几个月后翻回来看，看到一行就能想起当天做了什么；细节可以通过 link 或搜索找回。

3b. 写入方式

使用 Edit（patch）工具直接编辑日记文件：

1. 根据步骤 2d 确定每个主题的插入位置
2. 已有章节 → 找到该章节末尾插入新 bullet
3. 新章节 → 在日记末尾（待办块之后、其他已有章节之前或之后，按排序决定）插入 # 标题 + 内容

示例：

# context 输出显示：
## 大纲
6: # Genos Reg Server
8: ## 生产环境故障排查与修复
17: ## IGV 可视化 Access forbidden 修复
24: # OneReason Backend

# 新内容（Genos 部署记录）的第 6 行后有 # Genos Reg Server，应在第 17 行之前插入
# 新主题如 # CouchDB 同步部署 → 在文件末尾追加

更新已有段落（补充、修正、状态变更）：

• 只修改与本次会话相关的段落
• 不修改无关内容
• 合并重复而非追加——如果今天已经记过"daisy 技能安装"，补充结果时修改那条，不另起一行

更新历史待办：将对应文件中的 - [ ] 改为 - [x]，添加 ✅ YYYY-MM-DD，同时在今日日记添加 Obsidian 链接：

- [x] 任务描述 ✅ 2026-04-19  完成于 [[2026年4月15日星期三##任务标题]]

为什么加日期？因为 Tasks 插件按完成日期查询。 不加日期的话，回看时只知道"做过"，不知道什么时候做的，无法做周/月回顾。

3c. 新增待办

本次会话产生的新待办，添加到今日日记末尾：

• 格式：- [ ] 描述
• 有计划日期时添加 📅 YYYY-MM-DD

步骤 4：确认

输出本次写入/更新的内容摘要：

• 新增的日记条目（按主题分组展示）
• 更新的待办（状态变化 + 链接）
• 新增的待办

如果本次没有实质性内容，询问用户是否仍要写入。

AI 噪音过滤

禁止写入以下内容：

禁止项	为什么禁止
验证流程（"N 轮最终验证 APPROVE""XX 个测试用例全部通过"）	这些是开发过程中的中间状态，不是产出。结果是"功能交付"而非"N 轮验证"
提交/推送操作（"已提交并推送到 XX 分支"）	Git 操作是工具行为，不是人的工作成果。只写"功能上线"或"MR 已创建"
AI agent 产物（"沉淀 N 条规则到 AGENTS.md"）	AGENTS.md 是模型间的通信协议，不是人的知识产出
开发阶段标记（Wave 1/2/3、"骨架创建"、"模块创建"）	阶段标记是开发过程中的临时分类，不是最终结果。直接写做了什么
配置文件路径、代码片段	细节在代码仓库里，日记只写结论和选型判断

只写： 做了什么 + 核心特性/关键决策 + 关键结果。保留有价值的信息：人名、技术选型判断（含被否的方案）、关键数据。

Obsidian 待办状态

使用 Tasks 插件标准状态：

标记	状态	用途
[ ]	待办	未完成的任务
[x]	已完成	完成的任务，末尾加 ✅ YYYY-MM-DD
[-]	已取消	不再需要的任务，末尾加 ❌ YYYY-MM-DD

可选状态（按需使用）：

• [/] 进行中 — 已开始但未完成
• [>] 延期 — 推迟到以后
• [!] 重要 — 高优先级
• [?] 疑问 — 需要确认
• [h] 搁置 — 等待外部条件

跨文件引用已完成待办时，使用 Obsidian 链接：[[日期文件名#任务标题]]

内容注意事项

个人日记中涉及成人/R18 内容时使用隐喻和省略，不要直白描写。

只针对 R18 内容做隐晦化处理，不限制其他内容。