一条命令自动清空 Inbox——inbox-triage 让 AI 帮你分拣每一条笔记

🪝

你现在的 Inbox 里有多少条未处理的笔记？

5 条？50 条？还是已经多到你不敢打开看？

我在搭好系统的第 3 周，Inbox 里积压了 73 条笔记。

不是因为我忙，而是因为我每次打开 Inbox，看到那一堆东西，就感到一阵「处理焦虑」——要逐条读、逐条想该放哪、逐条打标签……这件事本身比看一篇新文章花的时间还多。

结果是：我越来越不愿意整理，越来越多地收藏，最终 Inbox 变成了一个「知道有东西但不想打开」的黑洞。

这是知识管理系统的第一道死亡陷阱：Inbox 积压。

inbox-triage 解决的就是这个问题。

一条命令，Codex 帮你处理完 Inbox 里所有积压的笔记——提炼观点、生成摘要、推荐归档、建立关联——你只需要做最后的「确认」，30 秒搞定。

「Inbox 是知识系统的入口。入口畅通，整个系统才能流动；入口堵塞，再好的系统也只是一个更精致的收藏夹坟场。」

🔬 Part 1：inbox-triage 到底在做什么

先把这个 Skill 的工作拆解清楚，你才能理解为什么它能解决 Inbox 积压问题。

inbox-triage 的完整工作流程：

text

Codex 读取 Inbox/ 下所有未处理的笔记
          ↓
对每一条笔记执行以下分析：
  ① 内容类型识别
     文章摘要 / 个人想法 / 书摘 / 工具记录 / 待办事项 / 其他
          ↓
  ② 核心内容提炼
     提炼 1-3 个核心观点（用自己的话，不是照搬原文）
          ↓
  ③ 关联检索
     在全库进行语义搜索，找出最相关的 3-5 篇已有笔记
          ↓
  ④ 归档决策
     判断应该进入 raw/ 的哪个子目录
     （reading/ articles/ thinking/ meetings/ 等）
          ↓
  ⑤ 生成结构化摘要页
     在 raw/ 下创建标准格式的摘要笔记
     含 frontmatter / 核心观点 / 关联链接 / 来源
          ↓
  ⑥ 输出处理清单
     列出本次处理的所有笔记，附上每条的处理决策
     等待你的确认
          ↓
确认后：将原始笔记移入 raw/processed/ 归档

整个过程中，你只做一件事：看「处理清单」，确认或修改 Codex 的决策。

从「打开 Inbox 就焦虑」到「30 秒确认完，Inbox 清空」——这就是 inbox-triage 的核心价值。

⚙️ Part 2：配置 inbox-triage Skill

方式一：直接写在 AGENTS.md 里（推荐新手）

在你的 AGENTS.md「快捷任务定义」模块里加入：

Markdown

## 当我说「处理Inbox」时，你要做：
### 执行步骤
1. 读取 Inbox/ 下所有文件，跳过 processed/ 子文件夹
2. 对每个文件执行以下分析并汇总到一份「处理清单」：
   **内容类型判断**（选一个）
   - 文章摘要：来自外部文章/博客的内容
   - 个人想法：我自己的思考和观点
   - 书摘：来自书籍的内容
   - 工具记录：关于工具使用的笔记
   - 待办：需要行动的事项
   - 会议记录：会议/对话内容

   **核心观点提炼**
   - 用我自己的语言提炼 2-3 个核心观点
   - 不要照搬原文，要「消化后输出」

   **关联检索**
   - 在 wiki/ 和 raw/ 中找 3 篇最相关的已有笔记
   - 用文件名 + 一句话说明关联原因

   **归档建议**
   - 推荐放入 raw/ 的哪个子目录
   - 推荐 2-4 个标签
3. 输出统一的「本次处理清单」，格式如下：
---
📥 Inbox 处理清单 | {{date}}
共处理：X 条笔记
---
文件名：xxx.md
类型：文章摘要
核心观点：
  1. 
  2. 
  3. 
关联笔记：
  - wiki/concepts/xxx 原因：...
  - raw/reading/xxx 原因：...
归档建议：raw/articles/
标签建议：#PKM #知识管理 #效率
---
（重复以上格式，每条笔记一块）
4. 等我回复「确认」后：
   - 在 raw/ 对应目录创建结构化摘要页
   - 将 Inbox 原始文件移至 raw/processed/
   - 输出「执行完成报告」
### 注意事项
- 不要在未确认前修改任何文件
- 如果某条笔记内容太简短（<50字），先问我是否需要处理还是直接删除
- 如果某条笔记明显是「待办」而非「知识」，单独列出，不纳入 raw/ 处理流程

方式二：配置为独立 Skill（推荐进阶用户）

如果你希望 inbox-triage 能定时自动触发，可以将它配置为 Codex 的独立 Skill：

Markdown

# Skill: inbox-triage
# 描述：自动处理 Inbox 积压笔记
# 触发：手动调用 或 定时任务（每3天）
## Skill 说明
[以上 AGENTS.md 里的完整步骤]
## 触发条件
- 手动：用户说「处理Inbox」「清理Inbox」「inbox-triage」
- 自动：Inbox/ 下未处理笔记超过 10 条时主动提醒

📋 Part 3：一次真实的 inbox-triage 执行记录

让我展示一次真实的 inbox-triage 是什么样的——

我的 Inbox 里有 6 条笔记，内容如下：

text

Inbox/
├── 2026-07-10-clipper.md     （一篇关于「间歇性禁食」的文章剪藏）
├── 2026-07-11-voice.md       （语音备忘录：关于知识库晋升机制的想法）
├── 2026-07-12-book.md        （《深度工作》的一段书摘）
├── 2026-07-13-idea.md        （一个关于「反馈系统」的随手想法，3句话）
├── 2026-07-14-article.md     （一篇关于「写作系统」的文章摘要）
└── 2026-07-14-todo.md        （买 Obsidian Sync / 更新 AGENTS.md）

我对 Codex 说一句话：

text

处理Inbox

Codex 输出的「处理清单」（节选）：

text

📥 Inbox 处理清单 | 2026-07-15
共处理：6 条笔记（其中1条为待办，单独列出）
---
文件名：2026-07-11-voice.md
类型：个人想法
核心观点：
  1. 知识晋升不应该依赖主观判断，应该依赖使用频率
  2. 被引用次数是衡量笔记价值的客观指标
  3. 「晋升候选」应该是系统自动筛选，不是人工定期回顾
关联笔记：
  - wiki/concepts/知识复利 原因：晋升机制是知识复利的具体实现
  - raw/thinking/note-promotion草稿 原因：同一主题，可合并或互补
  - wiki/methods/PKM工作流总览 原因：晋升是工作流第4步的核心
归档建议：raw/thinking/
标签建议：#PKM #note-promotion #知识晋升
---
文件名：2026-07-14-todo.md
类型：待办（不纳入知识处理流程）
内容：买 Obsidian Sync / 更新 AGENTS.md
建议：移入 daily/2026-07-15.md 的待办区，或告诉我如何处理
---
[...其余4条笔记的处理结果...]
请确认以上处理方案，我将在确认后执行文件操作。

我看了 30 秒，回复：

text

确认。待办那条直接删掉，我已经处理了。

Codex 执行完成，Inbox 清空，raw/ 里多了 5 篇结构化摘要。

整个过程，我花了 45 秒。

🔧 Part 4：进阶配置——让 inbox-triage 更懂你

基础版的 inbox-triage 能解决 80% 的问题。

但如果你想让它更准确、更贴合你的工作场景，以下是 3 个进阶配置：

进阶 1：加入「内容质量过滤」

Markdown

## 质量过滤规则
- 内容少于 100 字：询问我是保留/扩写/删除，不自动处理
- 内容是纯链接没有摘要：提醒我补充摘要再处理
- 内容是他人观点没有我的看法：在摘要页末尾加「待补充：我的看法」

进阶 2：加入「输出目标映射」

Markdown

## 内容-输出方向映射
当判断一篇笔记与以下方向相关时，在摘要页加对应标记：
- 与「个人成长」相关 → 标记 #content-growth
- 与「PKM工具」相关 → 标记 #content-tool
- 与「系统设计」相关 → 标记 #content-system
这些标记在后续 weekly-synthesis 时，用于推荐选题方向。

进阶 3：加入「来源权重」

Markdown

## 来源权重规则
- 来自书籍的内容：提炼后优先推荐晋升到 wiki/
- 来自个人思考的内容：标记为「原创洞见」，优先关注
- 来自社交媒体的内容：降低权重，摘要控制在100字以内

❓ 常见问题

Q1：如果我的 Inbox 有 100 条积压，inbox-triage 一次能处理完吗？

A：建议分批处理，每次 15-20 条。

批量太多，处理清单会变得很长，你反而来不及认真确认。分批的好处是，每次确认的精力是集中的，质量更高。

第一次处理积压，可以这样说：

text

处理 Inbox 里时间最早的 15 条笔记

Q2：Codex 推荐的关联笔记不准怎么办？

A：正常的，尤其在系统建立初期。

关联准确度随时间提升——你的 wiki/ 内容越丰富，语义检索的参考基础越大，推荐越准。

遇到不准的关联，直接告诉 Codex：

text

这个关联不对，实际上这篇笔记和 wiki/xxx 更相关

它会学习并在下次调整。

Q3：处理完的笔记放在 raw/processed/ 还是直接删掉？

A：强烈建议放 processed/，不要删。

原始内容是你的「记忆现场」，有时候摘要提炼了但原文有一些细节没留下来，你会需要回去翻。

processed/ 是归档，不是坟场——它安静地躺着，需要的时候还在。

🔮 下一篇预告

Inbox 清空了，笔记进入 raw/ 了。

但笔记和笔记之间，真的连上了吗？

「Inbox 清空是系统流动的开始，不是终点。信息进来了，下一步是让它开始和已有知识发生反应。」