科技赛道里，AI总是最热闹的话题。大前天Claude Code砸了程序员的饭碗，前天Codex压过Claude Code实现逆袭，昨天Andrej Karpathy提出llm-wiki颠覆了知识管理，今天HTML又把markdown掀翻，来个昨日再现。文章、图文、视频，无不精美，铺天盖地。
我每次看完都有一种奇妙的悬浮感。
不是内容不好——紧跟热点话题，节奏鲜活明快，视觉引人入胜。但它们几乎清一色以 ChatGPT、Claude、Gemini 为主角。在国内，这三家的工具大多数人根本没有条件正常使用。拿它们当默认前提，高呼改变工作方式、改变人生，这个“改变”飘在半空，落不到地。它们总在说工具能做什么，却不怎么说具体解决什么问题。而不少观众也很难一下子觉察到，自己生活或工作里的哪个问题，其实可以借助AI改善。
这类内容的逻辑是追着工具跑的。工具一更新，内容就重来一遍。观众也跟着折腾一遍，最后解决了什么真实的问题，不好说。
我有一个具体的小问题
我现实中一个比较主要的业务是做自动售货机，核心工作是拓展点位——选址、谈合同、处理客情、推进落地。每一个点位从线索到机器装好，中间有很多节点，每个节点的结果都不一样，后续的路径也不一样。
比如去一个点位勘察，结果可能是：
- 适合放机器 → 沟通商务条件
- 暂时不合适但有潜力 → 加入跟进池，一个月后复访
- 明确不适合 → 记录原因，关闭线索
这种”一个情况，多条路”的结构，在传统任务管理工具里需要时时手动更新。
OmniFocus 很强大，但也有局限
我早年买了 OmniFocus。它是一款非常成熟的任务管理工具，GTD 体系很完整，视角、标签、延迟、截止日期……功能强大，我用了很多年。
但对于我的实际问题，它有着局限——它没有分支判断。
任务或线性，或树状，但没有”如果 A 发生执行 X，如果 B 发生执行 Y”这种逻辑。而我的工作里，这种情况每天都在发生。每次现场情况明朗之后，我都要手动回到系统里，补充新的“下一步动作”，改写项目结构。
时间久了，结果就是：维护任务系统本身成了一件费力气的事情。 系统的目的是减少认知负担，结果它自己变成了负担。
我一度想放弃 OmniFocus，换一个更简单的工具。但简单的工具似乎又撑不住我的业务量。
换一个思路，我负责写文档，AI批量生成任务
OmniFocus 有一套相对完善的本地自动化机制，基于 JavaScript，可以通过脚本批量创建任务、修改项目结构、设置各种属性。以前我没怎么用过，但它给了我一个新的想法：
如果我不在 app 里手动输入任务，而是先写一份任务清单文档，再让 AI 去调用接口批量生成呢？
具体做法是这样的：
- 我用一个普通文档，把近期的项目、任务都完整写清楚——包括主线任务，也包括可能的分支节点和各条分支下的子任务。
- 把这份文档发给 AI。
- AI 解析文档，生成对应的 OmniFocus 脚本，通过 URL Scheme 或 Omni Automation 接口，把整个任务结构批量写入 OmniFocus。
这样做的好处是：我只需要按需写清楚任务清单，而不是在 app 界面里一条一条点。 改流程的时候无需全部推倒重来，在现有基础之上简单修改即可。
让AI创建插件，让分支判断自动化
文档能解决批量创建的问题，但还有一个更核心的问题没解决：运行时的分支判断。
我把需求说给 AI，AI 帮我写了两个配套使用的 OmniFocus 插件，分别负责”写入规则”和”执行决策”。
插件一：写入分支规则（write-branch-rules）
这个插件用来提前定义一个决策任务有哪些可能的走向。选中一个任务运行它，会弹出一个表单，列出同项目里所有其他任务，我勾选哪些任务是这个决策节点的”后续分支”。也可以在这里直接新建任务，或者标记”无后续（关停项目）”。
确认后，插件把规则以纯文本格式写进这个任务的备注里，大概长这样：
评估XX项目（决策任务）
适合放机器→@沟通商务条件
暂时搁置→@一个月后复访
明确放弃→无后续规则存在备注里，插件存在iCloud里，Mac和iOS设备都可以用。
插件二：推进分支（advance-branch）
这个插件在现场决策已经明朗之后用。选中那个决策任务运行插件，插件读取备注里的规则，把所有分支选项列成复选框，让我勾选实际发生的情况（支持单选或多选）。
确认后，插件自动完成一连串操作：把决策任务标记为已完成，给选中的分支任务解除“等待”标签（让它们变为可执行状态），按需创建新任务，然后把没选中的那些 @引用任务 直接从项目里删除。如果选了”无后续”，整个项目会被标记为非活跃。
整个过程我只需要做一个判断：当下的情况是哪条路。剩下的清理和激活，插件来处理。
这两个插件是迭代出来的，最初分支规则需要在app中手动输入；后来让AI直接把规则在生成任务时直接写进任务备注，插件只负责解析和执行，才变得通用。现在用到的是 v3.2，已经比较稳定。
两个插件加在一起，基本上把”分支维护”这件事从我的日常操作里摘出去了。我在系统里做的是决策，不是维护。
用够用的工具产出够用的结果
这套方案里，我用了两个工具，在这里说一下，因为选型也是实际问题的一部分。
Agent 编排用的是 Hermes，AI 用的是 DeepSeek。
选这两个的原因很简单：都是国内可以正常访问和调用的，API 成本在可接受范围内，效果对我这个场景来说足够用。我没有用最贵的模型，也没有用最新的工具——我用的是能解决问题的工具。
这个思路本身也是这篇文章想说的一部分。
AI应该帮助人解决具体的问题
AI 自媒体有一个隐性的叙事逻辑：工具越新越好，功能越多越强，谁用了最新的模型谁就走在了前面。
我不这么看。
AI 真正有价值的地方，不是它有多少功能，而是它能不能解决你手边那个具体的、让你头疼的问题。
我的问题是任务管理系统的维护成本太高。AI 帮我把这个成本降下来了——通过写脚本、写插件、解析我的文档、生成我需要的结构。这个过程里，我没有使用任何”最新”的东西，DeepSeek 不是最强的模型，Hermes 也不是最热门的 Agent 框架。
但它有效。
很多人陷在”学习新工具”的循环里出不来：刚搞懂 ChatGPT，Claude 出了新版本；刚配好 Cursor，Copilot 又更新了；刚建好知识库，又有人说新的 RAG 方案更好……
这种循环消耗的是真实的时间和精力，换来的是一种”我在进步”的幻觉。
不如回过头来想一个问题：现实里最让我烦的那件事，AI 能不能帮我解决？
从那里出发，再去找工具，找方法。大概率你不需要最新的，你需要的是合适的。想清楚自己真实的需求是什么，找到解决问题的思路，再用实际情况不断校准AI的走向——我想，这是我们和AI协作比较好的方式。