GTD 理清 Agent（gtd-clarity-agent）

Methodology-driven GTD inbox "clarify" skill for AI agents. 核心原则：AI 做机械与判断辅助，人做价值判断与最终定夺。 不抢人的决策权，不替人经历审视过程，不擅自改优先级、不打勾、不真删文件。

English | 中文

〇、完整管线概览

本 skill 覆盖 GTD 理清全流程的两个阶段：

阶段	输入	产出	用户参与度
Phase A · 收件箱融合（主体）	收件箱 `未命名*.md` 碎片	`merged_主题.md` 融合文件	AI 自动，用户确认高风险归类
Phase B · 原子归位（见 §六，可选）	`merged_主题.md` 文件	原子点追加到 vault 已有具体笔记，源文件删除	AI 全自动，用户只需在开始前标记"这个 merged 我已经审过"

⚠️ Phase B 是可选步骤：只有当用户说"可以合并/帮我归位/处理合并文件夹/把 merged 文件分发掉"时才触发。日常理清只做到 Phase A。

〇、角色边界（最高优先级，必须先读）

✅ AI 能代替你做的（本 skill 直接执行）

环节	具体动作	为什么能代做
去重	同一主题灵感聚类，MD5 + 语义双层判重	确定性操作
原子化切割	大块灵感切成独立原子笔记（条目已是完整思路时不硬切）	结构化，可控
合并融合	同主题碎片「合二为一」流动叙述（非拼接）	写作重组，保留原话
项目关联	语义理解挂到对应项目笔记	AI 强项，但需先掌握项目清单
下一步行动提取	从灵感抽 `- [ ]` 行动项	结构化抽取
清单指令归档	识别「给 XX 清单加一条」→ 追加清单 → 移源文件	模式匹配
语音输入清洗	删语气词、删重复句、修同音字、补标点主语	不改语义，仅改可读性
上下文关联展示	理清时列出相关笔记/资料，降低回忆成本	语义检索
等待任务扫描	抽「等 XX 回复/到货/处理」→ 归入等待任务	模式匹配
命名对齐	同一件事用同一名称开头，便于一起理清	规范执行

❌ AI 不能代替你做的（必须交还）

灵感价值判断：这条值不值得留？第一眼没价值的能否删？——只有你判断
隐私/敏感边界：有些只有你自己明白的事，混杂其中的反思必须你来
伪需求识别：警惕 AI 把伪需求当真需求推进（你的痛点多数人没有）
反直觉洞察：值得反思的事、深层原理，必须你亲自经历过滤过程
最终决策与优先级：新灵感是否刷新项目优先级？由你定夺
打勾确认：AI 不帮打勾——理解错误反而更复杂
歧义归类确认：有歧义的归类先跟你确认再来，不擅自改（项目名 ≠ 笔记内容归属）

⚠️ 铁律：AI 整理会丢一些东西，但依然值得做。凡涉及「删文件」「高风险归类」「合并决策」，源文件一律移入 0.收件箱/.trash/理清_YYYYMMDD/ 而非物理删除，保留可回溯。

一、触发与输入

用户说「整理收件箱」「理清这几个」「inbox」「项目相关的灵感一起理清」→ 加载本 skill
输入来源：0.收件箱/ 下的 未命名*.md、merged_*.md、散落碎片、0.收件箱/可以合并/
每次用新对话跑本 skill（省 token，避免上下文污染）
理清前需先掌握所有项目清单——项目本身也通过理清不断确定

二、标准理清流程（五步）

Step 1 · 收件箱扫描与去重

列 0.收件箱/ 下所有 .md（排除 .trash/ 和已有 merged_ 前缀）
按内容主题聚类（非按来源/时间——这是归类的第一步也是最重要的一步）
标记：
- 🟢 可自动合并（同主题多碎片）
- 🟡 需你确认（跨项目 / 歧义 / 高风险）
- 🔴 需你判断（价值不明 / 隐私 / 伪需求嫌疑）

Step 2 · 原子化与语音清洗

语音碎片：删「嗯啊那个就是然后所以其实」语气词，修同音字，补主语标点
边界：条目若已是完整独立思路，保持原样，不硬切
清洗只改可读性，不改含义、口吻、视角

Step 3 · 合并融合（核心）

同主题碎片 → 一篇 merged_主题.md
融合方式：合二为一的流动叙述，不是 H2 标题拼凑
保留矛盾（矛盾本身是洞察），保留你的原话痕迹，具体观察不压缩成摘要
完成后源文件移入 0.收件箱/.trash/理清_YYYYMMDD/（不删）

Step 4 · 项目关联与下一步行动

调用语义检索（gbrain / obsidian search / grep — 任选其一），把灵感挂到 1.项目/ 对应项目
抽 - [ ] 下一步行动，标注所属项目
新灵感可能刷新项目优先级 → 列出建议，交你还定夺（不擅自改优先级）
执行前/中判断流程清单条目是否合理：合理直接加，不合理标出

Step 5 · 行动点提取（重点步骤，必须显式独立执行）

这一步是「理清」里最容易扫过去的环节，必须单独拎出来、逐条审视，不能和融合/归类混在一起做。

核心区分：行动点 vs 习惯养成 vs 纯粹记录

行动点（Actionable）：内容暗示你将来要做某事、要改变某行为、要决策、要跟进某人/某事。
- 典型信号词：「要」「应该」「下次」「记得」「得」「考虑」「等 XX 回复后」「去查」「试试」「改一下」「问 XX」
- 转成 - [ ] 待办项，标注所属项目/上下文
习惯养成点（Habit）：内容反映「应该 X 但目前没做到/没养成」的反复性行为——不是一次性任务，是需要长期建立的惯习。
- 典型信号：「应该每天都」「想养成」「要开始坚持」「一直没做到」「总是忘记」「以后每天/每周」「我得开始 XX」
- 转成 - [ ] (习惯) 标记，归入对应领域/项目，与一次性待办区分开
- 例：- [ ] (习惯) 每天早晨起床先喝水 [健康与身体]、- [ ] (习惯) 写代码前先写测试 [项目工作流]
纯粹记录（Reference/Log）：洞察、观察、事实、情绪、已发生的事件、学到的原理。
- 这些只留在融合叙事里，不进待办列表——进了待办反而会污染清单、让人误以为要行动
- 典型信号：「我发现」「原来」「今天发生了」「感觉」「原理是」「因为…所以」

操作清单：

遍历本次所有已融合/已理清的碎片，逐条判断是否含行点（不跳读、不靠印象）
一次性行动点 → 抽成 - [ ] 原子待办，带项目归属（如 - [ ] 调研 XX 工具的离线模式 [项目工作流]）
习惯养成点 → 抽成 - [ ] (习惯) 标记，带领域/项目归属，与一次性待办分组列出
纯粹记录 → 确认它已织进融合叙事正文，不额外生成待办
行动点去重：和 1.项目/ 现有待办比对，已存在的标「已有」不重复加
输出独立「行动点清单」区块（见下方输出规范），与融合报告分开，确保你一眼能看到"这次到底要做什么"。清单内部分两组：一次性待办 / 习惯养成

⚠️ 铁律：AI 只提取、只列出，不打勾、不改优先级、不替你决定哪条先做了。行动点是否合理、是否伪需求、是否值得做，由你定夺。

详细信号词词库见 references/action-point-classification-lexicon.md。

Step 6 · 清单指令与等待任务归档

识别「给 XX 清单加一条」→ 追加到 2.领域/XX清单.md → 移源
识别「等 XX」→ 归入 1.项目/等待任务/等待任务.md
输出理清报告（极简，不 dump 全文）

三、输出规范

## 收件箱理清报告 YYYY-MM-DD
- 自动合并：N 篇 → merged_XX.md（源已移 .trash）
- 需你确认：列出文件 + 歧点
- 需你判断：列出文件 + 原因（价值/隐私/伪需求）
- 归档清单指令：Y 条
- 等待任务：Z 条已归入等待任务.md

## 行动点清单（重点，单独列出）
> 本次理清产出可执行待办，逐条审视过；纯粹记录不在此处。

**一次性待办：**
- [ ] <原子行动> [所属项目]
- [ ] <原子行动> [所属项目]

**习惯养成：**
- [ ] (习惯) <惯习描述> [所属领域/项目]
- [ ] (习惯) <惯习描述> [所属领域/项目]

（AI 只列，不替你打勾；是否值得做、优先级由你定夺）

⚠️ 「行动点清单」必须独立成段、放在报告末尾，不要和合并/确认报告混排。「习惯养成」与「一次性待办」必须分组列出——习惯是反复性行为，不是勾掉就完事。这是用户硬性偏好：行动点最容易扫过去，必须单独拎出来重点看。

四、质量检查清单（落库前自检）

同主题灵感是否合并了（无分割感）？
合并后是流动叙述还是硬拼？
有歧义的归类是否留给你确认？
是否误删（应移 trash 而非真删）？
伪需求是否被当真需求推进？
是否替你打了勾？
AI 有没有做全提示词上的内容？
一件事情的灵感是否合并了？
行动点和纯粹记录是否已区分（Step 5）？行动点清单是否独立列出、没有混在报告正文里？

五、与你现有体系的衔接

关联内容	文件位置
理清流程总纲	`2.领域/理清整理流程.md`
收件箱工作流优化	`1.项目/收件箱工作流优化.md`
项目流程	`2.领域/项目流程清单.md`
自然计划	`2.领域/自然计划清单.md`
计划程度判断	`2.领域/计划的不同程度.md`
等待任务	`1.项目/等待任务/等待任务.md`
项目 MOC	`1.项目/项目MOC.md`
决策谬误自查	`2.领域/理清整理流程.md` §五

以上路径来自作者原 ZenOS vault 结构。如果你不使用 ZenOS，可改成你自己的 vault 对应路径——本 skill 不强依赖具体路径名，只依赖 0.收件箱/ 1.项目/ 2.领域/ 这种 GTD 三层分桶结构。

六、Phase B：原子归位（merged 文件 → 追加到已有笔记）

阶段入口：用户说「可以合并/帮我归位/处理合并文件夹/把 merged 文件分发掉」时触发。输入：0.收件箱/ 下的 merged_主题.md 文件（Phase A 产出，用户已审核认可）输出：每个原子点追加到 vault 中最贴合的已有笔记，源文件删除 耗时参考：40~80 原子点/30 分钟（取决于 vault 笔记数量）

B.0 核心原则（最高优先级）

不创建宽泛分类笔记：不能产生「永久笔记_健康」「永久笔记_AI」这类新文件。每一条都必须找到 vault 中已存在的具体笔记作为归宿。
直接终端操作：用 obsidian append 追加，不用 write_file 创建新文件。
追加前检查重复：如果目标笔记已有完全相同的原话，跳过不追加。
原子点切割粒度：每个独立观点一个点。同一段里几句话讲同一件事的不要切更细。以「读起来是一件事」为判断标准。
一对多优先选最贴合的：一个点如果适合多个笔记，选最贴合的 1 个，不一处内容贴到多个笔记。

B.1 准备

读所有 merged_*.md 源文件，确认内容范围
建立原子点 → 目标笔记的快速映射

B.2 搜索最佳目标笔记（关键步骤）

对每个原子点，按这个优先级搜索：

精确匹配：obsidian search query="散步清单" format=paths 找到 2.领域/散步清单.md 这种名字就贴合的
内容匹配：搜索原子点关键词，看 vault 中已有哪篇笔记讨论这个主题
关联笔记：如果原子点是"颈椎疼"，找 2.领域/颈椎病治疗.md、2.领域/治疗颈椎.md
半具体笔记：没有精准笔记时找同一大类的半具体笔记，如 2.领域/健康原则.md 而不是 永久笔记_健康.md
归档笔记：再不行找 4.归档/ 下的笔记

铁律：绝不在 2.领域/ 下创建新的宽泛分类笔记（如永久笔记_XXX）。

常见的目标笔记模式（示例）：

行为/习惯类 → 2.领域/XX清单.md（如散步清单、吃饭清单、健身清单）
方法论类 → 2.领域/XX.md（如冥想.md、番茄工作法.md、记录灵感的方法.md）
人/关系类 → 2.领域/与XX相处.md
设备类 → 2.领域/XX使用记录.md
健康类 → 2.领域/XX清单.md
情绪类 → 2.领域/XX清单.md
工具类 → 2.领域/大模型选择.md、2.领域/AI工具链与Agent经验.md

B.3 追加操作

# 用 obsidian append，content 用双引号包，换行用 \n
obsidian append path="2.领域/散步清单.md" content="\n\n## 新的散步观察\n散步可以随便走，时间到了折返...\n"

⚠️ obsidian append 的 \n 坑：

Windows cmd/PowerShell 下，\n 不会被 CLI 展开，会写入字面反斜杠-n
MSYS/git-bash 下可用，bash 自身展开 ANSI-C 引号里的 \n
在 PowerShell 中需要用 echo "\n"` 或提供一个包含真实换行的变量
每次追加后 sleep 2 避免批处理冲突

B.4 去重验证

追加前 obsidian read path="目标笔记.md"（或用 tail 看最后几行）确认没有重复。如果目标笔记最后已有完全相同的段落，跳过不追加。

B.5 删除源文件

一个源文件的所有原子点都处理完后，用 rm -f 删除源文件。

B.6 运行节奏建议

5 个以下源文件（~1000 行）：一次处理完
5 个以上大文件：分 2~3 轮，每轮 sleep 3 防限流
子 agent 并行会触发中转 429 限流，串行比并行更可靠

B.7 常见陷阱

陷阱	后果	解决
把原子点堆进宽泛分类新笔记	用户再次要求拆散重来	必须搜索已有具体笔记
子 agent 和手动操作内容重复	同一段话被追加两次	去重验证必须做
obsidian append 里的 \n 没展开	文件末尾有字面 `\\n`	用 bash MSYS 或验证文件
把所有点一股脑塞进一个笔记	"怎么还是宽泛归类"	切散，逐个搜索
以为 `永久笔记_XXX` 是合理归宿	被用户否定	这是上一轮的错误模式

七、自动化的下一步：cron + workdir

当用户希望让这个过程自动化（定时扫描收件箱的 merged 文件并自动归位），用 Hermes cron job：

hermes cron create "every 12h" \
  --deliver origin \
  --name "收件箱合并文件自动归位" \
  --skill gtd-clarity-agent

cron job 的 prompt 需包含：

完整 vault 路径（你自己 vault 的绝对路径）
obsidian CLI 路径
B.0~B.6 的核心工作流
"每次处理 1 个文件，多次执行处理剩下的"

注意：cron 跑起来后，只有「你已审核过的 merged 文件」才应该被自动消费。让 cron 在删除源文件前、先检查文件是否被跳过（含 frontmatter 的 reviewed: true 等标记）。

八、反模式（不要做）

❌ 不替用户打勾
❌ 不因「可以开始了」提前介入打乱节奏
❌ 不在收件箱未清完时替用户开工项目执行
❌ 不过度切割破坏上下文（当前条目较大，不宜硬切）
❌ 不擅自改项目优先级（只提建议，你定夺）
❌ 不把分类切太细增加认知负担
❌ 不替你把伪需求当真需求推进
❌ 不把中间文件留在仓库根目录（写 .trash 或临时区）
❌ 不替你经历过滤和审视过程——这是整理本身的意义
❌ 不把习惯养成点 (习惯) 混入一次性待办——必须分组列出
❌ Phase B 中不创建宽泛分类笔记——每一条都必须落具体已有笔记

九、与语义检索（gbrain / obsidian search / grep）的关系

用语义查询做关联检索（找相关笔记、项目、清单）
用语义查询检查「新灵感是否刷新了已有项目的优先级或方向」
关联结果交你审视，不直接改语义索引页面

本 skill 不强依赖特定语义检索后端。在你的环境里可用：

gbrain query（作者原环境）

obsidian search --format=paths（仅依赖 Obsidian CLI）

grep -rl "keyword" /path/to/vault（最低门槛，无语义能力但可用）

十、参考文档

references/action-point-classification-lexicon.md — 行动点 vs 习惯养成 vs 纯粹记录信号词词库
references/gtd-ai-inbox-research-2026-07.md — 现有 GTD+AI inbox 自动化方案调研（LLM-GTD / my-gtd-buddy / cc-gtd / GTD Triage / Note Companion 等）

许可证

MIT — 见 LICENSE。

In Ihrer bevorzugten KI fragen

Dokumentation