我为自己造了个治理 AI 写代码的小工具，后来发现别人早就做了

我有一个自己的个人工具箱项目，放在本地，叫「项目管理工具」。不大，就是一些我自己常用的脚本和小功能，平时维护着玩。前段时间我想给它加几个新模块，就让 AI 帮忙写。

一开始还挺顺的。我跟 AI 说了项目结构，哪些文件能动，哪些不能动，用什么技术栈，代码风格是什么样的。它听懂了，写得也还行。

但聊着聊着，事情开始变得诡异。

大概聊到第三四十轮的时候，我发现 AI 开始「失忆」了。前面明明说过「这个文件是核心配置，别动」，它突然又开始改。我提醒它一次，它道歉，改回去。再过几轮，它又忘了。

我一开始以为是提示词没写好。后来才明白，不是它不想记住，是它的上下文窗口就那么大。几十轮对话之后，最早说的那些约束已经被压缩得稀碎，它根本读不到了。那些我反复强调的「不要改这里」「用这个风格」「注意兼容老版本」，对它来说就像从来没说过一样。

更崩溃的是换 agent 的时候。

有时候一个任务跑太久，或者我想换个思路，就会新开一个 agent 来接手。然后我发现，之前跟上一个 agent 交代了半天的项目背景、约束条件、当前目标，全都得重新说一遍。不然新 agent 一上来就按自己的理解乱写，完全不知道前面的规矩。

就这样来来回回折腾了很久。

项目越来越重。代码里到处都是「临时加的」「先这样用着」「以后再重构」的东西。有些文件我已经不敢动了，因为一动就会连锁崩。有些逻辑连 AI 自己都解释不清，「为什么这里要这样写？」「我也不太确定，可能是之前某次修改留下的」。

到最后，这个项目变成了一座石山。

不是不能用，是没人敢动。包括我自己。每次想加一个功能，AI 写完之后要么破坏老逻辑，要么引入一堆看不懂的补丁。我 review diff 的时候，已经分不清哪些改动是必要的，哪些是 AI 自己发挥的了。

某个深夜，我突然产生了一个念头。

要不，推倒重来吧。

这个念头冒出来的一瞬间，我感受到了一种荒诞的疲惫。我明明一直在「高效开发」，一直在让 AI 帮我写代码，怎么最后走到了要重写整个项目的地步？

那天晚上我一直在思考，问题到底出在哪。

我一开始想得很简单，先把需求都写下来。

不要全靠聊天记录，因为聊天记录真的太不靠谱了。一个项目做几天以后，AI 早期答应过什么、现在到底在改哪个范围、这个任务怎么验收，全部散在对话里。上下文一压缩，很多东西就没了。

最先想到的是 markdown。这个想法很正常，因为 markdown 好写，也能给人看。比如我可以写一个需求列表，写一下当前在做什么，再写一下哪些文件能改，哪些文件不能乱动。公司里做需求也会有单子、有范围、有验收，那 AI 写代码应该也差不多需要这些东西。

试了一段时间后，问题主要有三个。

一个问题是格式会乱。AI 往 markdown 里加东西的时候，每次写法都不一样。今天写成表格，明天写成列表，后天又多加几个标题。刚开始还能看，后面就像几版需求说明拼在一起，想找个准信都费劲。

还有一个问题是读取不稳定。文档一大，AI 不是每次都能把所有内容看完。它有时候只读一部分，然后按那一部分继续写。

最麻烦的是，markdown 只能写规矩，不能让 AI 一定按规矩办。你在文档里写「动手之前先看任务」，但它有时候还是直接开写。流程只写在文档里，约束力不够。

所以我就想，那不如做一个小工具。

这个工具后来叫 ai-board。

我的想法就是，把要做的事都放到一个看板里。一个需求从开始到结束，都要有状态。现在做哪个，改哪些文件，最后怎么验收，都尽量记下来。

这样至少有一个好处，就是你问 AI 「现在在做什么」，它不用去猜聊天记录，而是去看当前任务。它要改文件，也应该先看这个任务说了哪些范围。

数据没有继续用纯 markdown 存，因为前面已经被 markdown 折腾过了。我用了 JSON 存状态，然后再生成 markdown 给人看。人看的是文档，机器读的是固定结构。

写这个的时候我还加了一些基础保护。写状态文件先写临时文件，再替换正式文件，避免写一半坏掉。多进程同时操作时加锁。事件日志写失败时留兜底文件。

一个管任务的小工具，至少不能把自己的任务状态弄丢。这个要求应该不算高。

但 ai-board 管不住 AI 的所有行为。

它有用的地方，是让每次修改都挂在一个任务下面。你能看到这次为什么改，改了哪些范围，最后有没有验收。这个比只靠聊天记录要强一点。

但它也有很多管不到的地方。

比如它可以在提交代码的时候检查一下，看看这次改的文件有没有跑出任务范围。但它拦的是提交，不是 AI 写文件的那个瞬间。AI 写错文件以后，最后提交时才会被发现。

还有，git 本来就可以跳过检查。你真要绕过去，它也拦不住。这个我觉得没必要装作自己能拦住。

再比如 scope 现在主要看路径。路径上没冲突，不代表业务上没冲突。两个文件可能一个改了接口，一个改了调用，工具看不出来里面的关系。

所以它解决的是任务留痕和范围提醒，不是强制权限控制。你绕过流程，它不会替你兜底。

我写到一半的时候，看到别人推荐了一个叫 GSD 的项目。说它是给 Claude Code 做治理的工具。

我点进去看了一下，它做的事情和我想的方向很像。也是把任务拆开，也是管理 scope，也是希望 AI 不要想到哪里写到哪里。

而且它已经做得很大了。很多贡献者，好几万 star，还有一堆测试和设计文档。

我忙活半天，最后发现别人已经在同一个方向上做了很久。

那一瞬间的感受挺复杂的。有点挫败，「早知道直接用这个算了」。又有点好奇，「那我来看看它做得怎么样」。

我还是装了一下试了试。GSD 确实很完整。它会把事情分成讨论、计划、执行、验证这些阶段，每个阶段都有自己的提示词和 agent。它不是随便写写的项目。

但我用下来觉得它太大了。

命令很多，概念也多，每次带进去的上下文也不少。它能做更多事，但我的需求是让自己的小项目别乱成一团，不一定需要这么大一套东西。

我还拿相近的任务跑过一次。GSD 用的 token 更多，ai-board 少一些。这个数字不能说明 ai-board 更厉害，因为两边干的活不同。一个是工作流系统，一个是本地任务本，直接比不太合适。

如果单纯说成熟度，ai-board 肯定比不过 GSD。

这个没什么好装的。

ai-board 现在就是一个单人写的小工具。测试也主要集中在 CLI 那边。多 agent 的事情基本没怎么管，scope 也只是路径级别。跨机器协作这些更是没有。它现在的问题我自己也都知道。

但是我还是会继续用它，因为它刚好够我用。

我现在不需要特别完整的治理框架。我的需求是每次让 AI 改代码之前，先有个任务，能知道改哪里，能留下记录。工具本身不要太复杂，不要让我为了用工具又学一堆工具本身的东西。

GSD 很强，但我怕的是工具太强以后，我自己反而更容易偷懒。AI 改完代码，我还是要看 diff，还是要知道它到底干了什么。如果最后我还是要认真看，那我就更喜欢一个轻一点的东西。

这可能也是我现在对 AI 写代码的态度。工具可以帮忙，但不能替我负责。

这次造轮子之后，我至少确认了自己的需求。轻量、能留痕、能约束当前任务范围。

我想要的不是一个很大的系统，而是一个能让我别忘事、别乱改、能回头查的小东西。

如果你现在让 AI 写代码也经常写乱，而且连任务状态都没地方放，那 ai-board 可能能帮你先把记录这件事做起来。

如果你要的是很完整的多 agent 流程，那就应该去看 GSD。

1
pipx install ai-board
2
ai-board onboard --init-if-missing