git push no-mistakes：在代码推到 origin 之前，让 AI 先审一遍

你刚在 Claude Code 里折腾了两个小时。它写了 6 个文件、3 个测试、一个 migration。你扫了一眼 diff，看起来都合理。git push。CI 全绿。代码上线了。

两天后你发现那个 migration 脚本删了一个有三个下游服务依赖的字段。回滚花了一整个下午。

2026 年，这事不是假设。每个重度用过 Coding Agent 的人都经历过。问题不在于 AI 能不能写出好代码，它大部分时候能。问题在于当写代码的人和审代码的人都没有真的读代码的时候，谁来当最后那道关。

no-mistakes 解决的就是这件事。它在你键盘和 origin 之间插了一个 Git 代理，让你把 git push origin 换成 git push no-mistakes。推送不会直接到远程仓库，而是先进一条 AI 驱动的校验流水线：代码审查、测试、文档检查、lint，全过了才放行，顺手帮你开出干净的 PR。翻完它的 422 个 commit 和 Issue 区之后，我的判断是：这个项目踩准了一个被低估的痛点，但现在聊”生产环境必备”还太早。

打动我的，不是它做了什么检查

了解完它的工作原理之后，我最想讲清的不是它”做了什么检查”，而是它”怎么做到不干扰你正常写代码的前提下跑完这些检查的”。这个设计选择决定了它的实用性上限。

核心机制是 disposable worktree。当你 git push no-mistakes 的时候，它在 /tmp 下创建一个用完即弃的工作树，拷贝你的分支到这个隔离环境里跑流水线。你本地 IDE 里的文件、正在改的代码、还没 commit 的修改，完全不受影响。它不是 hook，不是 watchdog，不会在你的进程里拉一条常驻线程。就是那种装了就忘了它在，直到它帮你拦住一个事故的时候才会想起它的工具。

上游是你的工作分支，右边是 disposable worktree。流水线在隔离环境中跑 review、test、docs、lint、push、PR、CI 七个步骤，你的本地工作区纹丝不动。这也是它和传统 pre-commit hook 最根本的区别：hook 卡你，它不卡你。

流水线每一步要么自动通过，要么以一个 finding 停下来等待你的操作。纯机械性的修复自动应用，涉及意图判断的内容升级给你。TUI 界面上每条 finding 三选一：approve、fix、skip。选了 fix，流水线的 AI 会基于你的反馈重新跑该步骤，不是直接覆盖，是迭代修正。这个对待 findings 的审慎态度，在同类工具里并不多见。

agent 兼容度是它和所有 AI 审查工具拉开差距的地方。它不绑定任何一个编程助手。claude、codex、rovodev、opencode、pi、copilot，或者通过 acpx 接 acp 协议的任何 agent，全支持。而且支持有序 fallback 列表，主 agent 挂了自动切下一个。这个设计说明作者不是在做一个”Claude 的插件”，而是在做”任何一种 AI 编程工作流的质量闸门”。

三种触发方式里，/no-mistakes 这个 agent 技能版最对我的胃口。你可以在 Claude Code 里直接用 /no-mistakes implement user auth，它会让 agent 干活、跑完流水线、应用安全修复、把该升级给你的问题列出来。等于你给写代码的 AI 配了一个审代码的 AI。从此 Agent 写代码不再是写完就推的单向管道。

git push no-mistakes 适合你已经 commit 好了想推送的场景。no-mistakes TUI 适合还没 commit、想在交互式向导里一步步来。/no-mistakes agent 技能适合让编程助手从头到尾接管。三种入口，同一套流水线，按你的工作习惯选。

不过有个绕不开的问题。同一个模型写代码，同一个模型审代码，这算不算真正意义上的 review？一个 AI 能指出另一个 AI 的逻辑漏洞吗？从架构层面看，如果你同时给 agent 和 pipeline 用同一个模型后端，审查的独立性确实存疑。这不是 no-mistakes 的缺陷，是所有 LLM-as-reviewer 方案的共性难题。但从实用角度看，它的价值不在”语义审查”而在”流程门禁”：强迫你多看一眼。在这个大家都不敢仔细读 AI 生成的代码的 2026 年，多这一眼，可能就少一次回滚。

跑起来看看

安装出乎意料地简单。官方提供了一键脚本，macOS 和 Linux 上复制粘贴就行。

curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh

Windows 和 go install 的安装方式在文档站里有完整说明。装完在项目根目录跑初始化。

no-mistakes init

这条命令会在 ~/.no-mistakes/repos/ 下创建一个门控仓库，并给 Claude Code 等 agent 装上 /no-mistakes 技能。注意每条命令都来自 README，没有魔法。对于 GitHub fork 贡献模式，初始化时得加 --fork-url 参数指定你自己的 fork 地址。初始化完以后切到工作分支，正常写代码、commit，然后把推送目标从 origin 换成 no-mistakes。

git push no-mistakes

再跑 no-mistakes 打开 TUI 看流水线状态。

每条 finding 展开成可操作的行，状态用颜色区分：绿色已通过，黄色等待你的决定，红色是阻塞项。左右键切换 finding，回车进入详情，交互设计克制实用。所有检查通过后，门控自动把分支推送到配置的目标仓库并开出 PR。

实测中容易踩的几个地方：

• 初始化需要每个项目单独执行，不是全局配置。在五个项目里用就得跑五次 no-mistakes init，没有批量模式。
• --fork-url 参数的位置不太显眼，文档里得多翻一会才能找到正确的参数名。如果你用 GitHub fork 工作流，这是个必配项。
• 首次运行流水线要下载 agent 后端，比如 claude CLI。网络受限的环境可能会卡几分钟，而且没有进度条，你只能干等。

都是小问题，但在快速开始的体验上确实扣了些分。

什么时候用，什么时候别用

如果你每天用 Claude Code 或 Codex 产出几十个 PR，no-mistakes 的投入产出比很高。装完就能跑，没有月度账单，没有 SaaS 隐私顾虑，审查走你自己的 agent 后端。

但团队如果已经有 CodeRabbit 或 Greptile 的成熟部署，它不是替代品。它的定位更靠前，在 pre-push 环节而非 post-PR 环节。两者可以共存，不能互换。

不适合的情况也很明确。你是改一行 commit 直接 git push -f 的习惯型选手？它帮不了你，你得先接受”push 前需要被审查”这个前提。另外，如果你的 agent 后端不稳定或不想为审查额外消耗 API 额度，这个工具的额外成本可能不值得。

话说回来，GitHub 上有人评论说”no-mistakes 是 2026 年最让人想立刻装上的工具”。这句话有夸大的成分，但它反映了一个真实的情绪：AI 代码审查不是可选项了，是怎么做的问题。

社区怎么样了

项目太新，很多指标看起来单薄，但某一个维度上非常亮眼。

一个维护者扛下 422 个 commit 和近乎每日一版的发布节奏，这个效率不太常见。翻发布日志，每个版本都有明确的 feature、bug fix、chore 分类，没有那种改了个 typo 就发一版的纯刷号行为。从代码质量和工作节奏看，作者不是在做一个 side project，是在认真推一个产品。

社区讨论方面，项目在 GitHub Trending 上多次上榜，6 月底曾单周涨 2,200+ Stars。中文技术社区有几篇分析文章，观点基本一致：踩准了 AI 代码质量的痛点，实用性强。Discord 社区人数还在积累中。英文社区的 Reddit 和 HackerNews 讨论相对少，项目毕竟才三个月。

上线三个月，没有看到严重质量投诉的 Issue。以这个迭代速度和单人维护的配置，目前最大的风险不是代码质量，是维护者 burnout。如果 kunchenguid 被拉走半个月，项目的节奏可能骤降。不过数据好看不等于能用得顺手，这个项目到底值不值得放进你的日常流程？

值不值得跟

聊完了社区现状，现在该回答核心问题了。到底值不值得在你的工作流里给它一个位置？我的判断分两档。

如果你已经是 Coding Agent 的重度用户，装。理由不是它完美，是它的成本极低。一行安装命令，零配置，不需要为审查付费，不依赖第三方 SaaS。就算只拦住一次 migration 删错字段的事故，也值回票价了。在 AI 编程工具还没内置 pre-push 审查的当下，no-mistakes 是一个设计得恰到好处的缺口填充。

如果你只是偶尔用 Agent 帮忙补几行代码，观望。

关注两个指标：一是维护者节奏能不能维持，二是是否出现更多社区贡献者。

Bus factor = 1 的项目不适合过早纳入工作流依赖。在你决定用它之前，还得想清楚一个问题：你信不信任 AI 去审 AI 写的代码。它审出来的 finding，你大概率还是会逐条看一遍。所以它本质上不是帮你省时间，是强迫你多了一个环节，停下来看看 AI 到底写出了什么。

翻完 Issue 区之后的感受是矛盾的。

一方面它的设计思路全对了：非阻塞、用完即弃的工作树、agent 无关的架构，全是正确的技术决策。

另一方面它在做一个时间窗口很窄的产品。如果六个月后 Claude Code 自己内置了 pre-push review，no-mistakes 还会有多少独立生存空间？目前来看，它的差异化不在于功能，在于独立性。一个不绑定任何 agent 的审查网关，在 agent 碎片化的 2026 年，反而是它的护城河。

但这个判断今天有效，半年后不一定。想跟的话，最好的姿势是先用起来，而不是等它成熟。这类工具的价值不在于功能完善，在于你愿意把它接进工作流的那一刻。

资源地址

话说回来，不管怎么看数据、翻 Issue，最终决定装不装的是你自己的使用习惯。所以最后一句话：别纠结了，先试试。

先装，再决定要不要跟

如果你每天在用 Coding Agent 产出代码，装 no-mistakes 只需要一行命令和一次 init。就算你觉得 AI 审 AI 这件事逻辑上有问题，先跑一次流水线看看它给你的代码提了什么。不喜欢就删掉门控，没有任何残留。

如果你还在观望，把它的 GitHub 仓库 star 了，等 bus factor 改善或者 Claude Code 的审查功能表态之后再决定。这个项目的价值窗口可能只有半年到一年，但如果你是这个窗口里重度使用 Agent 的人，半年足够拦下很多次回滚了。