对比
AI4Kanban vs.
GitHub Issues
不是替代品，而是给另一个瓶颈准备的另一件工具。GitHub Issues 是一份共享、持久、公开的权威记录；ai4kanban 是一块私有、本地、为智能体而生的工作台。看你真正卡在哪里再挑。
你仓库里的纯 Markdown。智能体手边那块飞快的本地草稿板。
一个藏在 API 后面的数据库。共享、公开的权威记录。
那为什么不直接用 GitHub Issues？
可以啊。ai4kanban 做的事，几乎都能用 GitHub Issues 加上 gh CLI 或一个 GitHub MCP server 做到。区别在于代价。
同一件事放到 GitHub Issues 上，意味着更多噪音、更多来回、更多 token、更高延迟，还得更用力地提示才能让智能体愿意去用它。ai4kanban 拿 GitHub 的覆盖面换本地的速度；而对一个驱动着智能体单干的人来说，稀缺的通常正是速度。
AI4Kanban vs. GitHub Issues
十四个维度。 表示明确胜出；横杠表示这是一处有意的取舍，只看你需要什么。ai4kanban 拿下速度与本地化那几行；GitHub Issues 拿下规模与协作那几行。
你仓库里的纯 Markdown，存在 git 里。
GitHub 的数据库，藏在 API 后面。
能，不过是磁盘上的文件而已。
不能，需要网络和鉴权。
原生文件工具：Read、Grep、Glob。
gh CLI 或 MCP 往返调用。
低：grep 只返回命中的那几行。
高：JSON 载荷加上工具 schema。
本地磁盘，基本瞬时。
每次调用一趟网络往返。
一句话：一个技能文件加一个小脚本。
账号、鉴权令牌、MCP 配置。
没有，看板跟着仓库走。
只活在 GitHub 上。
刻意做得极简：优先级 + 工作量，单干需要的就这些。
标签、里程碑、指派人、项目板，为协调团队而生。
没有，两个人同时加 #1894 就撞号了。
编号由服务端分配，团队用着安全。
只留下会影响下一个任务的决定：某个想法为什么被否、什么已经交付。所以智能体总是往前提，不会重做已完成或已死掉的活。
完整保留评论历史和编辑记录，一条都不丢。
任务项全部打勾后归档这个任务。
关联的 PR 和 CI 会自动关闭 issue。
grep：板子小的时候很快，长大了就难受。
带索引的全文搜索和保存好的过滤器。
可以，但只能提交 Markdown，没有轻量的提单方式。
任何人都能提单、评论、点表情，不用提交代码。
每张卡都留在仓库里可见，只有记忆中枢会被精简到只剩要点。
公开且可链接，是开源世界的默认选择。
各自赢在哪里
谁也不是绝对更好。ai4kanban 是为一个智能体跑得快而优化的；GitHub Issues 是为一群人保持同步而优化的。
AI4Kanban
省 token，快得没有感觉
不用 MCP，不走网络。智能体是在 grep 本地 Markdown，而不是翻一个远程 API 的分页：token 更少、延迟更低，任务做到一半也不会碰上要刷新的鉴权。
智能体是真的会用
智能体不太愿意去搜 GitHub Issues，它们默认就伸手去拿文件系统工具。Markdown 看板正好长在它们已经站着的地方，提示更少，编造出来的任务状态也更少。
离线，而且是你的
git 里的纯文件。飞机上能用，GitHub 挂了也能用。不依赖 SaaS，没有厂商锁定，克隆一下仓库，整块看板就跟着你走了。
为“提新任务”调过的记忆
它记的是会影响下一个任务的决定：某个想法为什么被否、什么已经交付、离目标还差多少。所以智能体总是往前提，不会重做已完成的活，也不会重提你砍掉的东西。
GitHub Issues
为团队而生
服务端分配编号、并发编辑安全、能指派人。ai4kanban 没有数据库，两个人可能同时造出 #1894 而撞车。
透明与触达
公开且可链接，外部贡献者能提单、评论、点表情。当开放比纯粹的速度更重要时，这里才是对的家。
全部上下文，永久保留
ai4kanban 是刻意做压缩的，归档的卡会缩成一行。在 GitHub 上，每一条评论、每一次编辑、每一个交叉链接都原样留着。
深度集成
PR 自动关闭、提交链接、项目板、标签、里程碑，还有一整个第三方工具生态和能撑住规模的索引搜索。
智能体为什么偏爱文件
真正的差别，要等智能体动手干活时才显出来。问同一句话：“找出我那些高优先级的未完成任务”，两条路径几乎毫无相似之处。
而且这笔账会越滚越大。每一次“接下来做什么？”、每一次归档、每一次看板检查，在 GitHub Issues 上都要交一遍往返税。而模型只要有得选，就会悄悄绕开那个远程工具，转头去找文件。
你该用哪一个？
这些情况选 ai4kanban
- 你一个人干，或者只有一两个彼此信任的搭档。
- 你是在终端里通过智能体推进工作的。
- 比起留档，你更在乎往前走。
- 你想让看板待在 git 里，能离线，能带走。
这些情况选 GitHub Issues
- 你在公开构建，透明度很重要。
- 多个人会同时改动待办列表。
- 你很依赖 PR/CI 关联、项目板和里程碑。
- 你需要外部贡献者能提单、能讨论。
它们其实不算竞争对手。GitHub Issues 是共享的权威记录；ai4kanban 是智能体手边那块飞快的本地草稿板。如果你的瓶颈是人和人之间的协调，用 GitHub Issues。如果瓶颈是你和智能体一起的产出速度，用 ai4kanban。
不少独立开发者两个都用：GitHub Issues 当公开的跟踪器，ai4kanban 当智能体每天打交道的私有工作面。