【skills分享】task-tracker——以记录卡形式的记忆仓库

你有没有遇到过下面这些情况？

1. 任务跑得好好的，额度却用完了，只能更换模型、账号，或开启新的会话。上下文全部丢失，导致每次进行 vibe coding 时都有额度焦虑；
2. Codex 或其他 coding agent 意外崩溃，上下文没有顺利保留下来；
3. 当前会话变得太长，模型开始降智。想开新的会话接手，却又怕模型不知道任务已经进行到哪一步；
4. 在使唤 AI 的时候，发现有些目标需要修改，但有时候 AI 仍然按照最初的目标继续；
5. 修一个 Bug 已经尝试过多个方向，由于某种原因需要开新会话，AI 却又从头开始排查。

这些情况在短任务里可能不明显，但在持续几天、跨多个会话的任务里非常常见。尤其是像我这样没有传统编程背景、主要依靠 AI 完成开发的人，很难只靠自己一张嘴说清楚之前的任务进度。

所以我越来越觉得，coding agent 除了执行能力，还需要一个可以持续读写的“记忆层”。这个记忆层至少要保存：当前目标、目标修正、已经尝试的方法、失败原因、当前阻塞、上一次操作和已完成的验证。

GitHub 上的记忆类项目

如果你也在寻找 AI agent 的长期记忆、跨会话上下文或 coding agent 交接方案，GitHub 上已经有一些值得关注的开源项目。这里列出几个代表性的记忆方向项目，供大家参考。

比较有代表性的项目包括：gastownhall/beads、rohitg00/agentmemory 和 Gentleman-Programming/engram。它们分别从任务记录、持久化上下文、数据库和搜索等方向探索 coding agent 的长期记忆。项目热度和维护状态会变化，具体功能请以各仓库当前说明为准。

在这里，我要推荐一下自己长期使用的 task-tracker。它更加轻量：不引入额外数据库，也不替代完整的 agent memory 平台。它用一组约定好的记录卡，让 coding agent 在需要时留下并读取任务事实。

我一直在用的 task-tracker

task-tracker 可以理解成一个放在项目里的“任务记忆仓库”。它不承担普通待办清单的职责，也不会保存全部聊天记录，只保留后续工作真正需要的事实：

1. 用户目标和验收标准；
2. 当前状态与下一步责任方；
3. 关键决定和目标修正；
4. 已经尝试过的方法及其结果；
5. 当前阻塞、未验证事项和剩余风险；
6. 发布、数据、权限等高风险操作的授权、验证和回退信息。

它通常只在长任务、跨会话交接、反复排障、并行协作或高风险修改时启用。一次性问答和简单修改不需要为了形式创建任务卡。

一个任务卡就是一个 Markdown 文件。只要你不删除它，AI 甚至会在下一个可能相关的新任务中，回头翻阅已经完成的任务卡，查看它们之间是否存在关联。

它是怎么来的

我的 vibe coding 经历从 Gemini 2.5 Pro 开始。刚开始时，我没有编程基础，也没有亲手编辑代码的经验。说得直白一点，我当时主要就是把想做的东西、遇到的问题和不满意的地方告诉 AI，再观察结果是否符合预期。

task-tracker 最初来自我自己的实际需求，没有套用一套现成的工程方法。当时我用的是 VS Code 的 Cline 插件，一开始使用的是大佬们分享的公益站，这里蹭一点，那里蹭一点，需要经常切换 Key，任务会话也经常被打断、报错。我急需一个使用文件对当前任务进行存档的功能，每次都可以自动保存，下次还能自动读档。所以，我的第一个 skill 诞生了。

后来我在开发中发现，任务一长，AI 还会遗忘早先的决定；程序意外中断、额度不足、需要切换会话或更换模型时，新会话很难知道前面的工作进行到了哪里。

这些丢失的上下文往往正是最重要的部分：一个 Bug 已经尝试过哪些解决方向，用户对任务目标做过哪些修正，上一次操作停在哪一步，还有哪些结果没有验证。于是我提出了最早的任务记录需求，并在一次次真实任务中让 AI 帮我调整它。

后来的迭代也吸收了 Superpowers 给我的一些启发，例如先对齐再执行、用验证证据确认完成、给复杂工作保留检查点，以及让不同阶段可以可靠交接。这些理念经过重新整理，又和我长期使用中遇到的问题结合，逐渐变成现在这个更专注于“持久任务状态”的版本。

我实际遇到并使用它的场景

下面这些场景，我在持续 vibe coding 中反复遇到，也确实用任务记录处理过。

1. 会话中断或模型切换

Codex 崩溃、额度不足，甚至还会出现会话反复报错、无法使用，只有新开一个会话才能正常进行的情况。新会话不应该只能根据当前文件的情况猜测进度。有了任务卡，就能留下当前目标、已完成步骤、上一次操作和明确的下一步，让新会话可以先读记录再继续。

2. Bug 排查重复走旧路

出现 Bug 后，直接把结果丢给 AI 去修，但实际上，具体的根因没办法通过一个简单的表面现象立刻反推出来。一个 Bug 往往需要多轮排查（这里有我产生的另一个 skill，名为 log-first，会按照日志标准进行复现，大大缩小排查范围，本次仅讲述 task-tracker）。task-tracker 会记录已经排查过哪些方向、每次尝试得到什么结果，以及为什么暂时放弃某个方向。这样换会话后，新的 AI 不会把已经失败的方法再做一遍。

3. 需求在过程中不断修正

Vibe coding 的时候很少一开始就把需求想得完整。做着做着，我可能发现目标范围需要缩小，或者交互方式需要改变。任务记录会保留这些修正及其原因，避免 AI 仍然按照最初版本的目标继续实现。

4. 发布和重要修改

当任务涉及发布、权限、数据或其他不可逆操作时，比如我要求部署或者处理高风险内容，每次进行高风险操作时，都需要频繁授权或者调用 auto-review 模型。此时，task-tracker 会记录我在历史任务中已经授权的内容，减少对我的打扰和后续的 Token 浪费。记录卡会写清楚用户授权范围、目标环境、验证结果、失败停止条件和回退方式。

这几类场景共同指向一个问题：AI 需要记住对后续决策真正有用的内容，单纯保存更多文本并不能解决问题。

最后

我把 task-tracker 开源出来，是因为它陪我处理过很多跨会话、反复排障和持续迭代的任务。它适合经常让 AI 做长任务、经常切换会话，或者常常因为上下文丢失而返工的人。需要数据库型记忆系统时，也可以把它作为更轻量的补充方案。

仓库地址：
https://github.com/bu9bye-arch/task-tracker

既然大家都看到这里了，不妨帮我点个 Star，也可以关注、收藏一下我的账号。后续我会继续分享更多和 vibe coding、coding agent 以及 AI 辅助开发相关的文章。

本文章经过AI润色处理