no-mistakes：git push 前的 AI 代码质检工具

AI 写代码快了，bug 却也翻倍了

自从 AI 编程工具普及，很多开发者都发现一个尴尬的现象：提交历史里塞满了 fix lint、fix typo、fix ci 这类补丁式提交。代码写得确实快了，但夹带 bug 的提交也同步翻倍。

AI 帮你一口气生成一大堆代码，却经常忘了 import、没跑测试、类型对不上，逻辑看起来无懈可击，一跑就炸。到最后你不得不问自己：我到底是在写功能，还是在给 AI 擦屁股？

这背后有一个值得理解的技术根源：GitHub Copilot、Cursor、Claude Code 等 AI 编程工具的底层是大语言模型（LLM），其代码生成基于概率预测，而非真正「理解」程序语义。这意味着 AI 生成的代码在语法层面往往没问题，但在运行时依赖、类型系统约束、项目上下文一致性等方面容易出现隐性错误——代码看起来合理，却与具体项目的规范、依赖版本或业务逻辑不符。这类「语义正确但上下文错误」的问题，恰恰是最难用肉眼发现的一类 bug。

这背后其实有一条 AI 编程的铁律：代码生成速度和 bug 生成速度成正比。写得越快，错误就越隐蔽。以前手写代码，出了 bug 心里大概有数；现在 AI 替你写，你连它错在哪都不知道。

结果就是提交历史越来越脏、PR 质量忽高忽低，review 的人看半天发现全是低级错误。更要命的是，这些问题往往要等 CI 炸了才被发现，然后人肉去修，修完再 push，再炸，再修——陷入无限循环。

no-mistakes 的核心思路：push 前的 AI 质检门

今天要聊的开源项目 no-mistakes，思路非常巧妙。它不替代 Git，不替代 CI，而是精准地卡在 push 之前这个关键节点上。

你不再直接 git push origin，而是改用 git push no-mistakes。这一步会触发三件事：

• 创建隔离的临时工作区：不污染你当前的开发环境；
• 在干净环境里跑完整 AI 审查：包括代码 review、lint 风格检查、单元测试、文档更新检查，能自动修的直接修，需要人判断的才打断你；
• 全部通过后才放行 push：自动创建 PR。

换句话说，你最终看到的每一个 PR，都是已经被 AI 严格审查过的干净产物。这解决的不是「写得快不快」的问题，而是「交付得放不放心」的问题。

三种使用模式，覆盖不同工作习惯

no-mistakes 支持三种使用方式，可以无缝接入不同开发流程：

Git 原生模式

最推荐的日常用法。只需正常敲 git push no-mistakes，完全融入现有的 Git 工作流，几乎没有额外学习成本。这里有一个值得了解的技术细节：Git 支持配置多个 remote 仓库，no-mistakes 实际上是被注册为一个自定义 remote，其背后是一个本地代理进程。代理拦截 push 请求后，在隔离的临时 worktree 中完成所有检查，再通过真实的 origin 推送——这种架构完全无侵入，不修改 Git 本身，不依赖 Git hooks，利用的是 Git 原生的 remote 多目标机制。对于已经养成 Git 习惯的开发者，这是最自然的选择。

CLI 交互模式

直接敲 no-mistakes，它会一步步引导你创建分支、自动提交、自动 push，还带一个 TUI（Terminal User Interface） 交互界面。TUI 是一种在命令行终端中渲染的图形化交互形式，通过字符和颜色码模拟按钮、菜单、进度条等 UI 元素——你可以把它理解为「终端里的 GUI」，兼顾了命令行的效率和图形界面的可读性。适合不想记命令、喜欢向导式操作的人。

Agent 模式

如果你在 AI 编程代理里工作，可以直接敲斜杠命令，比如 /no-mistakes fix login bug，它会自动执行任务、跑验证、修问题，你只负责拍板关键决策。斜杠命令（slash commands）是 Claude Code、Cursor Agent 等 AI 编程代理的标准交互协议，允许用户在对话界面中直接调用外部工具。no-mistakes 支持这一协议，意味着它可以作为 AI Agent 工具链中的一个节点被调用，把代码质检环节直接嵌入 AI 编程的对话流。

底层架构：把 CI 搬到本地并用 AI 武装

从架构上看，no-mistakes 可以理解成一个「Git 代理 + AI 流水线」的组合。

当你执行 git push no-mistakes 时，一个代理层会先拦截这次 push，然后创建一份一次性的工作区副本，在这个副本里按顺序执行一整套检查：

1. Lint 检查
2. 单元测试
3. AI Review
4. 自动修复循环

全部绿灯后，才放行到真正的远程仓库并自动创建 PR。如果某个检查挂了，它会回到 TUI 界面或 Agent 那边，让你决定如何处理。

本质上，它把原本跑在 GitHub 上的 CI 搬到了本地，并用 AI 进行武装——让错误在离开你机器之前就被拦截和修复。这属于软件工程中「左移测试（Shift Left Testing）」理念的实践：越早发现 bug，修复成本越低。传统云端 CI（如 GitHub Actions、GitLab CI）的反馈通常需要数分钟，且每次失败都会产生噪音提交；而本地前置检查将这个反馈循环压缩到了 push 动作本身之前。

真正的价值：守住交付质量的底线

no-mistakes 的价值不在于帮你写代码，而在于守住交付质量的底线。

对比一下两种流程就很清楚：

传统流程：写代码 → push → CI 爆炸 → 人肉修 → 再 push → 再爆炸。

no-mistakes 流程：写代码 → 过 AI 质检门 → 自动修复 → push → PR 干干净净。

它带来的改变是四重的：

• 错误发现从「CI 阶段」提前到「push 之前」；
• 修复方式从「人肉」变成「AI 优先」；
• PR 质量从「开盲盒」变成「稳定输出」；
• Git 历史从「一堆 fix 提交」变成「清晰可读」。

说白了，它不是让你写得更快，而是让你放心地写得更快。

谁最适合用，以及它不是什么

如果你符合以下画像，no-mistakes 很值得一试：

• 日常使用 Claude、Copilot、Cursor 这类 AI 编程工具；
• 团队协作频繁，PR 质量不稳定；
• 经常被 CI 失败搞得心烦。

同时也要认清它的边界。no-mistakes 不是银弹：不是 Git 替代品，不是 CI 替代品，更不是代码生成工具。它就是 push 之前的一道质量防线，一个让你提交代码时心里有底的工具。

一句话总结：no-mistakes 不帮你写代码，它帮你把 AI 写的代码变得更靠谱。

核心要点