“同一个模型写完代码，再给自己弹个绿勾，这不叫评审。”一位开发者在复盘自己用编程智能体的经历时，把这句话摆在了最前面。他反复撞上同一个坑：代码是它写的，检查也是它做的，最后那个通过的标记，含金量到底有多少？

他的做法是把流程拆开。讨论、构建、验证，三步各自独立，不让同一个环节既当运动员又当裁判。代码写完还要能把源码导出来，自己亲手打开文件看一遍，而不是只信界面上那个勾。任何东西要进主干分支之前，必须有人明确说一声“可以”。

这套流程听起来笨，但指向的问题很实在：智能体出稿快，快到你来不及核对。它生成的代码看起来结构完整、逻辑通顺，绿勾一亮，人很容易就放过去了。可写代码的和打勾的是同一个模型，它对自己产出的判断，天然带着偏向。

围绕这个思路，他在做一个叫 Brainstorm 的工具，定位是一个 BYOK 外壳。所谓 BYOK，就是自带账号——工具本身不卖模型额度，用户拿自己符合条件的账号接进来用。它的流程是：多个 AI 围绕同一个目标先讨论，然后分工、验证，最后交给人来批准。

多 AI 讨论的意义在于，不同模型之间可以互相挑毛病，而不是一个模型自说自话。分工之后，写代码的和验证的不是同一方，绿勾才有点分量。至于最后那道人工批准，是整条链上唯一不能省的一环。

这个工具目前以 Linux 优先。对天天在终端里干活的人来说，这个选择不算意外——编程智能体的主战场本来就在命令行和代码仓库里。

回到那个绿勾。它本身没有错，错的是把它当成了评审结论。智能体可以飞快地起草，可以帮忙跑验证，但给自己打分这件事，还是交给别人来做比较稳妥。