X 热议：Grok Bot 工程师 poteto 称让 Agent 做对抗式代码审查「大多是浪费 token」，主张把 token 花在实证加形式化验证上

核心背景与行业痛点

编码 Agent 写代码越来越快，「谁来审」成了新瓶颈。常见做法是再开几个模型互相挑刺，即多模型对抗式审查，希望用模型多样性抓出 bug。代价是 token：每次审查都要把 diff 和上下文喂给多个强模型。11 月 3 日，poteto（lauren）发帖，自称「也许是暴论」：她现在认为对抗式审查大多是浪费 token。据其 X 与 GitHub 简介，她在 SpaceXSI 做 Grok Bot，是 React Compiler 核心团队成员，曾在 Cursor、Meta、Netflix 工作；她维护的 pstack 是一套给 Cursor、Claude Code 用的工程技能包。

架构亮点与底层机制

被她点名的是 pstack 的 interrogate 技能。按 GitHub cursor/plugins 中公开的 SKILL.md，它为每个配置模型各开一个只读审查者（默认 Claude Opus 5.5 xhigh 与 Grok 4.7 xhigh fast），对分支 diff 做对抗审查，再由主 Agent 把结论分成 Act on、Consider、Noted、Dismissed 四档，不自动改代码。她的替代思路是「实证 + 形式化验证」：用真实运行、测试、复现脚本证明问题，再用形式化方法证明性质成立，而不是让模型就代码本身发表意见。她的原话是，抽象层面的代码审查价值很小，Agent 容易陷在吹毛求疵和 YAGNI（你不会需要它）式建议里。

权威 Benchmark 与实测跑分对比

这是个人经验判断，帖子没有给出对比数据，也没有公开跑分。可查的只有热度：截至抓取约 90.6 万浏览、9227 赞、5538 收藏、668 回复、356 转发、210 引用，高收藏比说明不少开发者想留着参考。她称已让 pstack 少用 interrogate，但抓取时 cursor/plugins 里 pstack 的公开目录 10 月 27 日后没有新提交，改动尚未在这里体现。

开发者实战落地与开箱指南

如果你的 Agent 流水线里有多模型审查，可以先统计它产出的意见有多少真正被采纳、多少是风格类或「将来也许需要」的建议，再决定是否保留。可借鉴的方向是把审查改成「必须带证据」：每条问题都附失败的测试、复现命令或输出，没有运行证据的意见直接丢弃；对关键逻辑补属性测试或形式化规格。想试 pstack 的，可在 Cursor 中运行 /add-plugin pstack，或在 Claude Code 里从 cursor/plugins 市场安装。注意这只是一位工程师的观点，团队应按自己的缺陷数据判断。