从聊天到待办事项列表的演变
三个月前，我的任务管理仅仅是一个聊天窗口。如果我关闭了标签页，计划也就随之消失了。
如今，它是一个 Postgres 待办事项列表（backlog）。三个不同的 AI Agent——Claude Code、Codex 和 Grok——从中提取工作。它们会标注归属信息，并根据 git 历史记录来关闭任务。
我并不是为了构建一个项目管理系统才这么做的。我只是不断地碰壁。每当我修复一个问题时，新的问题就会随之出现。
我的工作量很大。我运营着一个名为 Nexus 的个人数据平台。我管理着大约 100 个代码仓库。在某一段时间内，我在 35 天内交付了 557,000 行代码。这种工作量击垮了我尝试过的所有规划方法。
以下是我系统的演进过程：
Phase 1: 对话式规划 计划存在于聊天记录中。我会边想边说，产生一个好主意，然后开始构建。
- 问题：聊天结束时，计划就烟消云散了。你无法对它们进行优先级排序，也无法将其交给其他人。
Phase 2: 每个仓库的 TODO 文件 我开始在每个代码仓库中使用 TODO.md 文件。我不再使用简单的清单，而是编写简短的规格说明（specs）。 每个条目包括：
- 状态和日期。
- 触发因素（为什么这变得紧急）。
- 预定步骤（计划）。
- 已知风险。
- 问题：面对 100 个仓库，我缺乏全局视角。我无法在一个地方看到所有需要做的事情。
Phase 3: 操作员待办事项列表 (OB) 我将任务移入了一个 Postgres 数据库。这创建了一个全局队列。 我增加了一个审批环节。只有在我审核后，任务才会真正生效。这可以防止 AI 向待办事项列表中填充垃圾信息。 我使用了状态通道：
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- 问题：我成了瓶颈。我处理这些状态通道的速度不够快。
Phase 4: 多 Agent 执行 现在的待办事项列表是多个 AI Agent 的共享队列。
- 它们使用租约机制（leases），以确保不会同时处理同一个任务。
- 它们使用归属标注（attribution），以便让我知道谁做了什么。
- 它们可以进行工作交接。一个 Agent 可能会发现某个任务无法完成，从而提交一个前置任务。随后，第二个 Agent 可以接手该前置任务，并最终完成原始任务。
教训很简单：你并不需要达到第四阶段才能成功。
如果你想借鉴一点，那就借鉴第二阶段的格式。在编写任务时，请包含状态、触发因素、预定步骤和风险。这无需任何成本，却能改变一切。
最重要的规则是：始终基于事实进行规划。绝不要基于猜测或摘要进行规划。一个基于陈旧数据构建的完美计划，其失败速度会和完全没有计划一样快。
可选学习社区：https://t.me/GyaanSetuAi