obsidian-diary

name	obsidian-diary
description	将会话内容按主题聚合写入 Obsidian 工作日志或个人日记，并管理待办。当用户说「记录一下」「写日记」「更新待办」等要求记录时，或在会话末尾出现结构化结论/部署完成/调研成果时加载此技能，主动询问用户是否记录。
metadata	{"internal":true}

Obsidian 日记与待办管理

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

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

不可违反的约束

以下规则必须严格遵守，不因任何工作流步骤或上下文而改变。

事实边界

只写会话/工具输出中有明确证据的内容。禁止添加虚构细节：不要写"根据习惯""顺手翻了翻""一般来说""按我的经验""社区也掉过坑"等会话未提供的信息。日记是真实记录，不是润色后的故事。

人称规则：涉及用户的感受、偏好、评价时，如果用户没有亲口说，不要替用户写。（✅ "记录一下" -> 用户说的。❌ "这是用户最介意的痛点" -> 用户没这么说。）不确定时只写客观事实，不写第三人称心理描述。

路径约定

路径格式：{日记目录}/YYYY/MM/YYYY年M月D日星期X.md。关键约束：目录用纯数字（2026/05/），只有文件名含中文日期字符。完整对照表和常见错误见 references/diary-rules.md。

陷阱：用 write_file 直接写平级路径会创建错误位置的文件。先用 uv run --script scripts/obsidian-helper.py --vault <变体> 查看 DIARY_PATH 后再写入。

变体选择

⚡ 用户指定优先：如果用户明确说了「记工作日志」「写个人日记」「记录到 personal」「更新工作日志」等变体指示，直接遵从用户的选择，不要用下面的判断规则覆盖。变体判断表只在用户没有明确指定时使用。

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

• 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 时，脚本会打印完整配置示例（含 base/diary_dir/template/exclude_meta 字段）。执行以下流程：

1. 询问用户每个 vault 的 Obsidian 根目录（本地绝对路径）
2. 按脚本打印的示例结构创建配置文件（base 字段填入用户提供的路径，其余字段用默认值，除非用户明确要求修改）
3. 创建完成后重新运行脚本

脚本

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

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

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

先读后写

即使今天日记已存在，也要先运行脚本获取当日全文，用 patch 追加而非 write_file 覆盖。

主动检查与询问

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

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

询问格式：

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

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

工作流

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

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

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

• 路径信息：DIARY_PATH、DATE
• TODOS：近期未完成待办（14 天）
• RECENT：最近 2-3 篇日记的前 30 行摘要（了解近期上下文和写作风格）
• TODAY：今日日记全文

日记不存在时脚本会自动从模板创建。

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

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

2a. 列举所有 distinct topics

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

2b. 聚合归域

把语义相近的 topic 合并为同一个主题域。判断依据：这些事是否属于同一个目的或领域？ 聚合示例（好/坏对照）见 references/diary-rules.md 的 personal/work 变体好例子。

合并规则

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

2c. 检查今日日记已有内容（来自步骤 1 的 TODAY 输出）

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

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

2d. 排序

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

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

3a. 提取内容

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

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

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

3b. 写入方式

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

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

示例：

# context 输出显示今日日记已有章节：
# Genos Reg Server
## 生产环境故障排查与修复
## IGV 可视化 Access forbidden 修复
# 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

步骤 3d：写入前强制门禁

动笔之前，在心里打好草稿，逐项检查以下 3 个 blocker。任一 blocker 不通过 -> 必须先修正草稿再写入文件：

Blocker	检查项	不通过则
① 事实虚构	每条 bullet 是否能追溯到会话中的具体对话或工具输出？不要写"根据习惯""随手""一般来说"等无来源内容	删除虚构内容
② 结构散乱	是按主题域聚合而非按时间流程平铺？新内容是否塞进了今日日记已有章节？	重新聚合主题
③ 流程噪音	是否混入了 agent 操作日志（Git 提交、验证流程、开发阶段标记、AGENTS.md 规则沉淀、配置文件路径、发布部署操作）？	删除噪音，只保留人的结论和决策

步骤 4：确认（须附门禁报告）

门禁未通过时不得确认。全部通过后，在内容摘要之前加一行门禁报告：

自检：事实✅ 结构✅ 噪音✅

新增的日记条目：
...

⚠️ 门禁报告只出现在确认摘要中，不要写入日记正文。

内容摘要：

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

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

Obsidian 待办状态

使用 Tasks 插件标准状态：

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

可选状态（按需使用）：

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

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

内容注意事项

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

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