"我让 AI 做的那个功能，到底有没有做？" —— 给 AI 加一个可视化 backlog

"我让 AI 做的那个功能，到底有没有做？" ------ 给 AI 加一个可视化 backlog

写了 56 个 markdown 文档来"管理"AI，结果发现 AI 根本不会自己维护这些文档的状态。我自己不去维护，文档就在烂掉。后来我做了 aming-claw 解决这个问题------这是第一篇拆解文章。

一个我反复踩的坑

我已经在很努力地"管理" AI 了。

这是我 aming-claw 项目的 docs/dev/ 目录------56 个 markdown 文件，全是和 AI 协作产出的工程文档：

proposal-* 是每个新方案的立项书
review-* 是每次方案评审记录
handoff-* 是 session 之间的状态交接
还有 plan-、optimization-、interface-、manual-fix-......

每个文件都带日期，每天都在长。两个月下来一千多页 markdown。原以为这样下次新 session AI 自己会回头看,我自己也能查。

但绕不开一个问题:AI 不会自己维护这些文档的状态。

proposal-graph-state-reconcile-and-chain-governance-modes.md 里立的方案,最终落地了吗?哪个 commit 实现的?现在还有效吗?
handoff-2026-05-10-dashboard-semantic-hash-queue.md 里交接的工作,下一个 session 真的接上了吗?
18 个 proposal 里,哪些已经实现、哪些被推翻、哪些还活着?翻 git log 一条条比对?

我自己不去维护,文档就在烂掉。AI 不会主动维护,因为它每个新 session 只看自己上下文里那点工作区,56 个老文档进不来。

聊得越多、写得越多,文档和代码的距离越远,最后你既不敢信文档,也来不及读代码。

为什么会这样

不是 AI 不努力,是结构性问题:

文档是死文本 ------ markdown 没有状态机,"TODO" 不会自己变成 "DONE","决定 X" 不会自动失效
AI 上下文有边界 ------ 它每次只看局部工作区,老文档根本进不来;进不来就维护不了
文档和代码之间没有可追溯的连接 ------ 一条 TODO 对应哪个函数?做完之后哪个 commit 实现的?人脑记不住,AI 不去查

GitHub issue / Notion / Linear 也解决不了 ------ AI 看不见它们,等于不存在。

核心矛盾是:人想要"事情的全局状态",AI 只能看到"局部的此刻"。 中间需要一个活的、可追溯的、AI 能读能写的项目状态层 ------ 文档不是这个东西。

aming-claw 怎么做

我给 aming-claw 加了一个独立的 backlog 数据库 ------ 它和 event ledger、code graph 是平级的一等公民,有自己的 schema、自己的状态机、自己的查询接口。不是写到 markdown 里、不是嵌在代码注释里、不是依赖外部 issue tracker。

它存什么:每条 backlog 是一个独立的记录(todo / decision / constraint),带状态、带优先级、带来源 session、带关联代码引用(函数名 / 文件路径),AI 通过 MCP 可以直接读写。

工作流是这样:

1. 你说的事 → 自动进图,不再进死文档

Chat 里说:

"记一下:UserService 的登录限流要加 retry-after"

或 "决定:用 Redis 而不是内存做缓存"

aming-claw 的 MCP server 接到这句话,不是写进 markdown,而是直接落进 backlog 数据库,自动关联到对应的代码位置:

yaml 复制代码

关联代码: UserService.login   # 函数名或文件路径
类型:    todo | decision | constraint
状态:    proposed
优先级:   P1
来源:    本次 session ID
时间戳:   2026-05-16T10:23:45Z

Markdown 是死文本,backlog 数据库是活状态------有 schema、有索引、有状态机、AI 能直接读写。这是关键区别。

2. Dashboard 里立刻看到

打开 aming-claw dashboard,左侧 backlog 列表多了一条。点击 → 右侧直接跳到 UserService.login 函数的代码位置(通过 vscode:// 协议),状态 chip 可以手动改。

3. 状态机自动流转

bash 复制代码

proposed → in_progress → done(commit hash) → verified

in_progress ------ AI 开始改了
done ------ commit 落地,自动绑 hash
verified ------ 你 review 后确认看过

每个状态切换都写进 event ledger ------几月几号哪个 session 提出来的、哪个 commit 实现的、谁 verify 的,全部可追溯。

4. AI 下次会自己回头检查

下次你在 chat 里问:

"上次提的那个 Codex 插件 Windows 安装 bug 修了没?"

AI 通过 MCP 直接读 aming-claw backlog,返回:

makefile 复制代码

状态:       FIXED, P0
修复 commit: 0ad8c7e
修复时间:    2 天前
改动文件:    agent/plugin_installer.py (line 455)
改动说明:    用 callable replacement 替代原来的 regex pattern

不用翻 git log,不用问别人,不用怀疑。

注意一个关键点 :AI 不是从对话历史里"回忆"这个 bug ------ 它是通过 MCP 实时查 aming-claw 的 backlog 数据库 。所以哪怕这是三个月前提的、十个 session 之前的事,AI 现在依然能给出准确的当前状态 + 完整的 commit 追溯。

这就是和 markdown 文档最本质的区别:文档是死文本,backlog 是活状态。

这只是开始

回到开头那张 docs/dev/ 的截图 ------ 56 个 markdown,没人知道哪个还活着。再看 dashboard 截图 ------ 每条 backlog 都有状态、有 commit、有改动位置。

区别不在工具好不好,而在信息有没有状态。

Backlog 解决的是"我提过的需求做没做",但 AI 协作的坑远不止这一个:

痛点	下一篇会写
AI 改了一个函数,10 个调用点全部 break	代码图 + 影响分析
AI 改了不该改的核心代码	governance hints
AI 这周到底改了哪些地方	event ledger
AI 每个新 session 都从零开始	项目记忆层

这些我会在接下来的文章里一个一个拆开写。

关于 aming-claw

GitHub :github.com/amingclawde... 已开源
B 站 :@阿明 in_AI 看视频版
下一篇:AI 改一处崩一片 ------ 给代码加一张图

如果你也在 AI 协作里被"提过的需求做没做"困扰,欢迎 star + issue + 拍砖。