GTD 理清 Agent（gtd-clarity-agent）
Methodology-driven GTD inbox "clarify" skill for AI agents. 核心原则：AI 做机械与判断辅助，人做价值判断与最终定夺。 不抢人的决策权，不替人经历审视过程，不擅自改优先级、不打勾、不真删文件。
〇、完整管线概览
本 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。