先说结论：agent 写的进度看板就是自评成绩单。这事八月十三号 dev.to 上那篇文章才算被人认真当结构性问题拎出来，作者 Alberto Clemente。我基本是复读他的经历，但结论是我自己的：你们团队的看板数据，八成同一类水分。
他遇到的事不复杂。七月二十七号，用 Claude Code，一口气撞见三个问题——一张卡挂着空 commit 挂了两天；spec 里数出九条假陈述；五百行代码对着一张还躺在 Backlog 的卡写的，因为没人调用那个 start 函数。
最扎心的不是这三件事。是他的结论：agent 写的代码没坏，坏掉的是 agent 对代码的记录。而他此前几周一直在骂错对象。
「代码质量不行」和「记录是假的」，两个问题。骂错方向的几周，比那五百行错位代码更浪费。
管住嘴没用，得管住手
Clemente 第一反应和所有人一样：加严 CLAUDE.md，改 tracker 的 prompt，上 hook 时刻提醒。
全没用。这是我最欣赏这段叙述的地方。他没停在「prompt 不够好」这个舒适区，直接把问题钉死在结构上：干活的是 agent，写报告卡的也是 agent。看板是一套自报系统。
这句话值得单独站一会儿。
自报的意思不是 agent 在撒谎——多数时候它一脸真诚地说「done, tests pass」。意思是这个「done」没有任何外部仲裁者。你 prompt 写得再凶，也只是让自报的语气更谦卑，分数还是它自己打的。
所以他写了个东西，Shipward，MIT 协议，npm 上就叫 shipward。零依赖，570 个测试。命令行一句话：
npx shipward setup ~/code/your-repo --seed-from-branches
核心机制一句话讲完：agent 交卡，tracker 先跑一遍项目检查，退出码为零才给状态。检查是人在配置里声明的 argv 数组。agent 不能定义检查，只能从已声明的里挑。
他放了一段没剪过的演示：tracker 拒了一次信心满满的「done, tests pass」，真修完才放行。就这一个片段，比十篇「AI agent 全自动交付」的通稿加起来信息量都大。😂
git 当仲裁，不是 git 当仓库
这里有个区分，我觉得被大多数同类工具糊弄过去了。把看板存进 git，和让 git 纠正看板，两码事。前者叫存储，后者叫仲裁。Shipward 是后者。
某张卡的 commit 已经是 main 的祖先？下次 session 开始时看板自动修正，不等你发问。但边界划得死：只填空白、只确认已落地的工作，从不推翻人的决定。
还有个小设计我特别喜欢。每条笔记记下它当时对应的 commit sha，之后看板告诉你树挪了多远。「什么都没落地」和「我没法核对」是两种状态——大多数看板根本分不开这两句话。
它还带一个视图，专门列 git 能戳穿的声明、没人认领的分支、从没跑过检查就关掉的卡。给 agent 的话术直接挂了个照妖镜。
作者被自己的工具当场抓了
全文最好笑也最有说服力的部分来了。
一个 locking bug 静默丢写入。一个安全检查的错误处理把崩溃变成彻底沉默。还有一个测试，跑在 tracker 自己改过的文件上还通过了——这条是被几小时前刚上线的一个功能抓出来的。
换句话说，这工具第一次真正抓到的，是它自己的作者。
工具仓库自己的看板：75 张卡、274 条笔记、四万三千字，连 agent 犯的错都在里面。拿自己的狗粮喂自己，还不藏狗粮里的小石子。这比任何 benchmark 跑分可信，跑分是厂商挑的，狗粮是没法挑的。
评论区也值得说。有审阅者指出每次检查结果应该绑定当时评估的确切 git tree，最终状态切换用 compare-and-swap——作者两个 commit 修了。另一位 Nazar Boyko 问得更狠：什么阻止 agent 挑最便宜的那个已声明检查？这个洞是真的。作者在 e10c1da 修了：已带检查的卡，换检查交回会被拒，除非 force:true，而且写一条决策记录，两个检查都记名。
评论区的洞被认真修掉，这波不冤。
他自己交了底牌
这篇文章没把自己包装成银弹，限界列得明明白白。我挑三条最要命的。
检查通过只证明一条声明的命令在某个树上退出了零，不证明活干对了。agent 给坏代码写一个能过的测试，这套系统照样被耍。检查没声明之前，卡片照样靠 agent 一句话移动。
还有个「在我机器上测的」问题。他八核笔记本上的时间假设，上第一个双核 CI runner 就翻车——项目里三处独立的时序假设全这么挂的。
对了，他还自己复现了一个安全洞。本地 web UI 的 PUT 端点会整个替换文档包括 checks 映射，且设计上不鉴权，任何能摸到那个端口的进程都能装一条 ['/bin/sh', '-c', '...'] 当检查。他端到端打穿过一次，200 OK，schema 合法的 payload 照样执行。
自曝到这个程度，反而让我信了七成。通篇找不出一条限界的工具文章，我都当科幻小说读。这届文案最爱的就是这种通篇没有「但是」的稿子。
锐评评分卡
工具本身我不打算吹成救世主。单人单机、无账号无权限无团队功能、无依赖图，适用面窄得很。
但那篇文章钉死的结构性判断，值回全部阅读时间：只要 agent 既干活又写成绩单，你看到板上每个「done」都是自报的分数。prompt 管教解决不了，只有外部仲裁解决得了——不管那仲裁是 Shipward 的 exit code 还是别的什么。
值不值得现在跟？单人项目可以拿去照一照，那句 npx shipward setup 不亏。团队场景先等等，它的诚实清单里自己都写明白了没做那块。
至于你的看板——先别急着信上面那些绿卡片。拿 git log 对一遍，看看有多少「done」的 commit 压根不存在。我上次这么对过一回，之后就再没正眼看过任何 agent 自报的进度。