gap-trap: Turn vibe coding into high quality code（gap-trap：给 Vibe Coding 装上质量门禁）

📅 2026-09-16 | 🏷️ 值得研究的仓库 | ⭐ 146（7 天窗口，2026-09-13 创建）
🔗 原文：https://github.com/pliablepixels/gap-trap

是什么

gap-trap 解决 vibe coding 的经典后遗症：Agent 写码太快，你不再逐行看 diff，质量悄悄滑坡。它在你的仓库里跑一次，读代码、生成贴合该代码库的规则，然后给每条规则配一个「门禁（gate）」——规则被破坏时让提交或 CI 直接挂掉，把「写在提示词里的规矩」变成「机器强制的约束」。

🔍 小白解读

先说几个词

• Vibe coding：跟着感觉让 AI 生成代码、不细看的开发方式。快是真快，翻车也是真翻车。
• 门禁（gate）：卡在提交或 CI 流水线上的自动检查，不合规就亮红灯——像小区门口的闸机，没卡不放行。
• 规则漂移：AI 写的代码慢慢偏离项目约定的过程：重复造已有的轮子、跨层乱调、写「能跑但没用」的测试。
• 契约（contract）：对「这件事只有一种正确做法」的明文约定，比如日志必须走统一入口、配置必须走统一模块。
• 变异测试思想：想证明测试有用？把它放到「旧的、没实现该功能的代码」上跑一遍——如果在旧代码上也能通过，说明这测试什么也证明不了。

这篇到底在说什么

Agent 写的代码出问题，模式惊人地一致：写一个项目里早就存在的辅助函数；因为「抄近路能编译过」就跨越了分层边界；写的测试只断言「代码跑了」而不断言「跑对了」；还有对着你的说明文件「选择性遵守」。这些事没有任何东西在拦——因为规则只是文本，文本没有执行力。gap-trap 的做法分两步：先「审库出规」——扫描代码库，为 HTTP、日志、配置、鉴权这些「只该有一种正确写法」的部位生成一条条契约；再「以规设闸」——每条契约配一个门禁，规则被踩了，提交或 CI 就失败。它还内置几个狠招：一个 CI 任务把每条新测试拿到旧代码上跑，通得过旧代码就判测试无效；给 lint 积压、超 400 行文件这类「已知病灶」设计数器，只许下降不许上涨；把项目踩过的坑写成事实档案，让下一个 Agent 会话不再重学。Node 和 Python 仓库的门禁直接进测试套件，其余语言（Go/Rust/Java/Ruby/.NET/PHP/Swift/C++）用只依赖 git、grep、awk 的 shell 版门禁，基本通吃。

这跟普通人有什么关系

只要你的公司开始用 AI 写代码，质量滑坡就是所有人的事：线上事故、返工成本最终落在整个团队头上。这类工具让「AI 提效」不用以「放宽审查」为代价，普通开发者的代码评审负担反而可能变轻。

为什么值得架构师关注

• 治理模式升级：把规范从「文档 + 评审自觉」迁移到「可执行契约 + CI 门禁」，是 AI 时代工程质量体系的地基改造，gap-trap 给出了低成本起步模板。
• 测试可信度防线：「新测试必须杀得死旧代码」这条 CI 规则，直接封堵 Agent 用「废话测试」刷覆盖率的主要漏洞，可立即搬进任何项目的流水线。
• 落地的现实约束：生成契约的 skill 要求 Opus 级或更强模型（选错契约会让后续所有会话付出代价），说明「规则生成」本身是高价值高成本动作，宜一次性审校、长期复用。

核心内容

• 一次运行完成「读库 → 生成贴合本库的规则 → 每条规则配一个挂提交/CI 的门禁」，Agent 绕不过去。
• 内置四类资产：契约条目（HTTP/日志/配置/鉴权等「唯一正解」部位）、变异式测试门禁（新测试在旧代码上通过即判无效）、病灶计数器（lint 积压、超长文件只降不升）、踩坑事实档案（跨会话传承教训）。
• 语言通吃：Node/Python 门禁进测试套件，其他语言提供仅需 git/grep/awk 的 shell 门禁；附配套 skill 统一 Agent 的文档、提交信息与 PR 风格。
• 定位为 SDD（规格驱动开发）的内环补充；契约生成 skill 需 Opus 级以上模型。
• 发布 3 天 146 星，JavaScript 实现，主打「不用逐行人审，AI 代码依然正确」。

行动建议

值得立即小成本试用：先在 一个非关键仓库跑一次，人工审校它生成的契约（这步最关键），再决定是否推广到主干仓库。同时把「新测试杀旧代码」门禁单独抽出来，哪怕不引入整套工具也值得加进现有 CI。注意事项：shell 门禁依赖 grep/awk 的可移植性、以及契约质量高度依赖首次生成用的模型与人的审校投入。