前置条件#

1. 滴答清单有官方 CLI，可以很方便地通过官方接口操作清单。
2. Hermes 支持通过终端一次性下发任务。

滴答清单的结构是「清单 — 分组 — 任务」，三者层层包含，左边的包含右边的，其中分组是可选的。一个任务包含标题、描述、时间、提醒时间等信息，也包含创建时间和修改时间。

思路#

先建一个「AI 打工」清单，里面分出三个分组：任务输入、ask 队列、结果返回。剩下的就是具体流程。

1. 任务检测：滴答清单的 CLI 如果请求太频繁，既可能被封号，对服务器也不友好，所以需要合理设计请求间隔。我的设计是：人工作的时间段每 30 分钟检测一次，凌晨 3:00–7:00 这种我基本都在睡觉的时间段则降低频率。同时可以记录任务出现的时间，以时间为横轴、任务出现频次为纵轴画柱状图，再拟合一下，得到更贴合自己作息的检测规则。另外还要考虑用户的编辑需求：光靠上面的检测还不够，会碰到这种情况——你刚建好任务，过一会儿想改描述，任务却已经执行完了。所以要引入冷却机制。滴答清单的 CLI 可以拿到任务的创建时间和修改时间，于是可以这样设计：检测时如果发现某个任务的创建时间或修改时间距当前不足 5 分钟，就跳过不处理，并额外安排一次 10 分钟后的检测——只有在队列里还没有 10 分钟后的检测任务时才添加，避免重复堆积。

2. ask 分组：有些复杂任务我们描述不清，或者任务本身需要人工确认，又或者模型直接出了故障，这时就轮到 ask 分组了。AI 在执行任务时如果出错、需要权限请求，或者碰到需要你确认的地方，都可以在 ask 分组里建一个任务。我们对这个任务做出修改，就等同于回答了它的问题。

3. 结果返回：这个很自然，AI 完成任务后，就在结果返回分组里建一个任务，任务描述就是 AI 的工作成果。同时，结果返回分组里的每个任务都带一个子任务，比如「提出修改」：我们只需修改子任务的内容并完成它，AI 就会按我们的要求返工。

细节优化#

• 通知系统：因为有 ask 这种情况，越早处理 ask 就能越早拿到结果。结果返回这一环，复杂调研任务可能产出大量文字，不应该全塞进滴答清单的任务描述里：一来这样不太合适，二来读起来也不方便——产出内容可能是 markdown，还要配图配表，而滴答清单并不适合当阅读工具。这两个问题的解法都是通知系统，我设计了两套：实时通知与存储通知，也就是 ntfy 和 email。ntfy 是一个开源通知方案，效果类似微信这类聊天软件的通知；邮箱自然不用说，还能存较大的附件，直接把 PDF 发到邮箱就能阅读。

• 阅读系统：虽然可以用邮箱发送文件来阅读，但也不是那么方便。我发现这是一个做 callback 的好机会：我之前部署了 FreshRSS，只要把结果放进 RSS 就好了，读起来也方便。只需要写段代码自动生成 feed.xml，让 RSS 阅读器读取就行。

流程图#

flowchart TD
    A["任务输入：写清调研目标和要求"] --> B["最后修改后静置 5 分钟"]
    B --> C{"信息够用吗？"}
    C -- 否 --> D["ASK 队列：集中提问"]
    D --> E["在回答区填写答案，不勾选完成"]
    E --> B
    C -- 是 --> F["执行调研"]
    F --> G{"执行成功吗？"}
    G -- 否 --> H["恢复 ASK：说明问题和已保存内容"]
    H --> I["确认如何继续"]
    I --> F
    G -- 是 --> J["结果返回：摘要、正文和报告位置"]
    J --> K{"符合自动 RSS 条件吗？"}
    K -- 是 --> L["Markdown 进入 RSS 发布队列"]
    K -- 否 --> M["出现“发布到 RSS”子任务"]
    M --> N["勾选后发布当前完成版"]
    J --> O{"需要返工吗？"}
    O -- 是 --> P["编辑“需要修改请在这里编辑”子任务"]
    P --> B

效果图#