用 GitHub Issues 当 TODO 追踪器
执行力低所以一直没法坚持用市面上复杂且割裂感强的 TODO 软件。某天突发奇想，试着把 GitHub Issues 当作自己的 TODO 追踪器后，发现它竟然还不错。
GitHub 随笔 0x24a | 2026-08-20 | 2026-08-20
Rendering...
我是那种执行力巨低，但是不停给自己安排新任务的人。
这种特性让我一直有维护 TODO List 的需求 —— 但很奇怪，从这个想法出现以来，我从来就没有想过使用现有的 TODO List 解决方案，光是想象打开它们的界面就觉得累。它们太复杂了，而且和我平时的工作流完全是两个世界。
### 我最早的方案：一个 Telegram 频道
不想用现成的，那就哪个舒服用哪个吧。
最初的解决方案是开了一个只有自己的 Telegram 频道，想到什么任务就发一条消息。听起来很合理：反正 Telegram 生活中常用，随手就能记，跨平台同步也完全没压力。
但用了一段时间后，它的缺点就很快暴露出来了。
1. **太乱。** 记的 TODO 多了，旧的很快就石沉大海了。听起来像是给自己创建一个 “建 TODO -> 忘掉 -> 建 TODO -> ...” 的恶性循环工作流。
2. **没法跟进进度。** 一件事有了新的进展，除了回复消息来让整个消息流更混乱外，没有任何更好的方式去更新它。
3. **没有优先级系统。** 优先度处理纯靠大脑想到什么做什么。
本质上就是：消息流完全不适合管 TODO。
### 某天突发奇想
没有任何特别的契机。一天写项目开 Issue 的时候突然想到：用 GitHub Issues 管 TODO，怎么样？
乍一看很像什么 nerd final boss 之类的东西，但仔细想了一下，好像还挺合理的。Issues 天生就是一个用来追踪“有什么事情要做”的工具，该有的标题、正文、标签、开关状态都有。而且我本来就一直用 GitHub，不会给日常工作流引入任何新平台。
于是就去试了。
### 我现在的实现方法
新建了一个专门的空仓库，就叫 `todo`。
每一条 TODO 就是一个 Issue。标题尽量写得“信息密集”，让我就算隔了一大段时间也能理解当时在想什么。如果需要更多上下文，就用正文补充，Closed as completed/not planned 也符合我平时做事的态度。
标签系统设计成了很适合自己的二维标签：`priority` 优先度和 `effort` 耗力程度。
命名上稍微 neta 了一下*人类学*的 effort level 命名：`low`、`medium`、`high`、`xhigh` 和 `max`。[^1] 这一整套 workflow 下来，一眼就能知道这个任务的全貌啦。
另外有一个小巧思：GitHub 的标签按照字母顺序排序，且无法覆盖。所以把标签从 `effort:low` 和 `effort:medium` 换成 `effort:00-low` 和 `effort:01-medium` 这样会更舒服。
<details>
<summary>一个预览</summary>
<img src="/attachments/gh-issue-todo-demo.png" alt="使用 GH Issues 管理的多个 TODOs。带有 effort 和 priority 的二维标签。" style="width:75%">
</details>
### 为什么我喜欢它
用下来发现，这个方案对我来说几乎完美无缺。
1. **完美的跨平台。** 市面上的 TODO Tracker 要么要求注册一亿个可疑平台的账号来进行云同步，要么过于麻烦或者根本没有。GitHub 无疑在这方面是优秀的。[^2]
2. **不破坏我的现有工作流。** 这一点对我来说很重要。GitHub 本来就是我日常工作流的一个重要部分，没有任何“在所有设备上都另外下一个 App”的负担。
3. **足够结构化。** 有富文本、有标签系统、能用评论跟进进度。刚刚好卡在“够但不特别多”的 sweet point。
4. **有 API。** 这个算一个加分点。有 API 意味着可以把 TODO 和很多东西集成，虽然我目前还没有这么做，但是有绝对比没有好。[^3]
5. **看起来很 geek。** 听起来不像什么正经理由，但是，呃，对。
### 适合谁
如果你和我一样：天天泡 GitHub 或喜欢它的设计美学、觉得现有的 TODO 追踪器太重或者太割裂、不需要和别人协作管理任务并喜欢自己设计工作流，那这个方案可能值得一试。
但是如果你需要一些听起来很针对 TODO Tracker 特化的功能（例如日历集成），那 GitHub Issues 大概不是你要找的东西。
### 碎碎念
“记 TODO 该用什么”这个问题困扰了我两年多了。从来没想过最后是这个半夜三点钟冒出的想法，会用得这么顺。看来有时，最好的工具还得是“刚好嵌入工作流”的那一个啊。
[^1]: 人类学即 Anthropic, PBC 的直译。我知道这个名字不该翻译但是听起来很好笑。命名参考: https://platform.claude.com/docs/en/build-with-claude/effort
[^2]: 基于云的 App 怎么可能上不了云
[^3]: 无聊的话可以让 Coding Agent 用 GH CLI 规划今天做什么