kunchenguid/no-mistakes

如果你已经在用编程 Agent 写代码，并希望它们的产出在交给人审之前先被过滤一遍，这个项目值得看看。但它对工作流的改动不小，不是加个钩子那么简单。

解决什么问题

改完一个分支、push、开 PR，然后在 review 里或 CI 挂了之后才发现漏掉的测试、过时的文档、lint 问题。如果代码是编程 Agent 写的，这些收尾其实落到了 reviewer 头上。no-mistakes 改的是 push 这一步：你不再 git push origin，而是推到本地的 gate 远端；只有 review、测试、文档、lint 全部通过后，分支才会被转发到配置的推送目标。结果是 PR 到达时机械性问题已经处理掉，而不是留给 reviewer 去分诊的初稿。

有什么不同

机制是在你和真实远端之间放一个本地 git 代理。往它推送会起一个一次性 worktree，流水线在你的工作区之外跑，不打断手上的分支；全部检查通过后才转发分支并自动开 PR。发现的问题按类型分开：机械性修复自动应用，涉及意图的则升级给你，在 TUI 里 approve、fix 或 skip。

它比 pre-commit 钩子多做的一点是交互方式。Show HN 讨论里有人问为什么不直接用 pre-commit 钩子，作者回答说当 Agent 找出七个问题而你只在意其中四个、还想补充修复指令时，这种来回在钩子里很难表达（回复）。流水线对 Agent 不挑剔，Claude、Codex、Copilot、Cursor 等可配有序回退；同一流程也做成 /no-mistakes 技能，Agent 可以无头跑任务、过 gate、应用安全修复。代价是你要信任一轮 AI 判定你的改动，而且必须配 Agent：每个 gate 都需要一个能跑的流水线 Agent。

CI 失败处理是设计上最谨慎的地方。流水线会修复，并且只有在能证明修复基于你已审过的那个提交时，才通过受保护的 force-push 重新发布；证明不了一律退回 review，合并冲突的修复因为重写历史也总是走这条路。可以设 ci.revalidate_repairs: true 强制每次 CI 修复都重新审查，代价是每修一次多跑一整轮。

谁值得试

适合经常让 Agent 出分支、想在 Agent 与人工 review 之间加一道闸的开发者，尤其是能接受 approve/fix/skip 交互、愿意在配置里指定默认 Agent 的人。fork 贡献也有路径：origin 指向父仓库，用 fork URL 初始化即可。

如果你只想要提交前的轻量本地检查，或者不打算把编程 Agent 纳入每次 gate，那它不合适。如果团队 review 本来就很细、PR 噪声很少，这轮额外检查未必划算。

使用条件与边界

你需要装好并跑得起来一个受支持的 CLI Agent，配置里写明它和回退顺序；没有这项 gate 跑不起来。安装还会改变远端结构：你推到 gate，由它转发到配置目标，原来的 origin 习惯和脚本要相应调整。

日常维护比安装更要紧。CI 修复可能 force-push，所以才有了那条血缘证明逻辑和重新审查开关；打开重新审查意味着每次修复多一整轮 review。启用前先看配置说明弄清它改了什么。macOS/Linux 上一行命令安装，Windows、Go、Nix 和源码构建见安装指南；首次运行见快速开始。

HotRepo 点评

HotRepo 只记录到 2026-10-25 一次日榜出现，当时 8,947 stars、当天 +18，项目年龄 203 天。这只是单次观察，无法据此判断热度能否持续，也不必从中读出趋势。真正要决定的是：你是否愿意让每次推送都经过 AI 闸门并指定默认 Agent；先确认你的 Agent 在支持列表里，再决定 CI 重新审查怎么配。