个人任务管理的AI化：以Claude Code会话为中枢的捕获与执行工作流

个人任务管理的AI化：以Claude Code会话为中枢的捕获与执行工作流

几个月前我在听《How I AI》播客，嘉宾聊到一个让我停下来回放的观点：现代知识工作者最大的效率损耗不在执行，而在”捕获到执行”之间的摩擦。一个任务从脑子里冒出来，到真正被处理，中间要经历多少次转移——记在纸上、扔进收件箱、粘贴到Notion、再打开来看——每次转移都有信息衰减，都有认知负担。我当时就想：既然我的主要工作已经在Claude Code里发生，为什么不让它直接成为任务管理的中枢？

问题在哪里

我用Obsidian做知识库已经两年多了。它很好，但我发现一个结构性问题：Obsidian是一个”归档型”工具，适合存放已经消化过的知识，不适合作为任务的第一落点。每次我有一个想法或任务冒出来，打开Obsidian意味着我要决定”这条记录应该放在哪个文件夹、打什么标签”，这个决策成本在任务高频出现时会变成持续的摩擦。更根本的问题是：Obsidian里的任务和我实际执行任务的环境（Claude Code会话）是分离的，我需要在两个地方同步状态，这本身就是一种重复劳动。

所以我的问题不是”要不要用AI管理任务”，而是”捕获发生在哪里、执行发生在哪里、两者如何不脱节”。

我现在怎么做

现在的工作流分三层。第一层是捕获：所有任务的第一落点是Claude Code的对话框。我不会打开任何其他工具，直接对话，用自然语言描述任务。这看起来很简单，但关键在于：我让Claude在每次会话开始时读取一个active_tasks.yaml文件，这个文件记录了上一次会话结束时未完成的任务和当前状态。捕获动作就是告诉Claude”新增一条：X”，它更新文件，不需要我做任何格式化决策。

第二层是整理。这里我做了一个取舍——我不让AI帮我”分类”任务，因为分类是一个消耗注意力的决策，而且分类系统一旦建立就有维护成本。我让AI做的是优先级判断和依赖关系梳理：这个任务现在能执行吗？它依赖什么前置条件？执行它需要哪些上下文？这些是机械可计算的，AI做比我做更省力，而且更准确，因为它有完整的任务历史。

第三层是执行。这是这套工作流真正的杠杆点：当一个任务被从YAML文件里取出来执行，Claude已经有了完整的上下文——之前为什么记录这条任务、当时的决策背景、相关的代码或文件。我不需要重新回忆，不需要”加载上下文”，直接继续。这种连续性是传统任务管理工具无法提供的，因为它们只记录任务本身，不记录任务的执行上下文。

具体的工具选择

核心只有两个：Claude Code和一个YAML文件。YAML而不是Markdown，是因为YAML有结构，Claude读写时不容易出现格式错误；比JSON更易于人工检查。文件路径固定，每次会话通过系统提示或会话开头的Read操作加载。我没有用任何任务管理SaaS，没有Notion数据库，没有Linear——不是因为这些工具不好，而是因为它们都在Claude Code执行环境之外，会产生上下文切换成本。

有一个反直觉的选择：我没有建立”每日回顾”习惯。传统GTD方法强调定期回顾，但在AI化工作流里，“回顾”是自动发生的——每次打开新会话，Claude读取active_tasks.yaml，自动汇报进行中的任务状态。我不需要刻意安排回顾时间，因为上下文恢复已经内嵌在工作流启动动作里。

可复用的原则

回顾这套工作流，我提炼出三条可复用的判断标准。第一，捕获工具应该是执行工具，而不是另一个归档工具——任务在哪里被执行，就在哪里被捕获，减少跨工具状态同步。第二，AI做结构化判断，人做价值判断——优先级算法、依赖关系、上下文关联，这些交给AI；“这件事值不值得做”，这个判断留给自己。第三，工作流的价值不在于”记录了多少任务”，而在于”减少了多少从记录到执行的摩擦”——如果一套系统让你花更多时间管理任务而不是执行任务，就是过度设计。

这套方案不适合所有人。如果你的工作不以代码或文本为主，如果你需要和团队共享任务状态，或者你已经有一套运转良好的系统，没有必要为了”AI化”而重构。但如果你和我一样，主要工作发生在命令行和AI对话里，且一直被”任务在哪里、上下文在哪里”的摩擦困扰，这个方向值得尝试。

如果你在构建AI工程团队，欢迎参考我们开源的 Synapse 框架。Synapse 是一套以Claude Code为中枢的Multi-Agent协作体系，涵盖任务捕获、执行链管理、跨会话状态恢复和自动化编排，本文描述的个人工作流是其中的一个子集。框架地址：github.com/lysanderlj/Synapse-Mini