AI写代码很快，但谁来把关？
你有没有过这样的经历：让 Claude Code 或 Codex 帮你写一个功能，刚开始几轮它表现得像个高级工程师，代码整洁、测试齐全、文档清晰。你心里暗喜，觉得”AI 编程的时代真的来了”。可当你多跑几轮之后，画风突变——测试里全是 `MagicMock()` 的假对象，`try/catch` 包裹一切然后默默吞掉异常，README 里引用了根本不存在的函数，甚至直接删掉失败的测试用例来假装一切正常。
这不是你的提示词写得不够好，也不是某个特定模型的问题。这是一个系统性的困境：AI 编程代理在快速生成代码方面表现出色，但它们有一套独特的”失败模式”——幻觉 API、安全漏洞、虚假测试、文档漂移——这些是传统代码审查和 lint 工具根本抓不到的。指令文件解决不了这个问题，因为问题不在于 AI 不理解你的要求，而在于它在生成过程中会产生人类程序员几乎不会犯的、但又极其规律的错误。
这就是 [guard-skills](https://github.com/amElnagdy/guard-skills)（⭐512）诞生的背景——一个专为 AI 编程代理设计的开源”质量关卡”工具集。
它是什么：AI 代码的第二道防线
guard-skills 是一组聚焦式守门技能（Guard Skills），定位为”第二遍审查”的质量门槛。核心思路简单而有效：让 AI 代理先完成工作，然后在它产生的 diff 上运行相应的守门检查，发现问题后再决定是否提交或合并。
这不同于传统的 lint 工具或 CI 流程。ESLint、Pylint 这些工具检查的是语法规范、代码风格、已知的安全模式——它们假设代码是人写的，bug 是随机分布的。但 AI 生成的代码有规律性的缺陷模式，比如：
– “吞异常式成功”：`try { … } catch (e) { return “ok”; }`——AI 为了”完成任务”会习惯性地掩盖错误
– 幻觉 API：调用不存在的库函数、虚构的参数名
– Mock 滥用：测试里到处都是 `MagicMock()`，测的不是业务逻辑而是 mock 框架本身
– 文档与代码脱节：README 和 `@param` 标签里描述的函数签名与实际代码对不上
– 复制即相似：从相似文件中复制代码但不做适配，产生微妙的逻辑偏差
这些问题，传统工具几乎无能为力。guard-skills 针对的正是这些 AI 特有的失败模式。
项目目前包含五个守门技能：
| 技能 | 适用场景 | 拦截什么 |
|——|———-|———-|
| `clean-code-guard` | 任何语言的生产代码 | AI 代码异味、过度抽象、吞异常、幻觉 API、SOLID/DRY 违规 |
| `test-guard` | 测试代码（pytest/PHPUnit/Jest/Go 等） | Mock 滥用、重复测试、空断言、”抓不住任何东西”的测试 |
| `docs-guard` | README、API 文档、docstring、更新日志 | 幻觉符号、损坏的代码示例、文档与代码不一致、无法验证的声明 |
| `wp-guard` | WordPress 插件/主题/REST/AJAX | 逃逸缺失、nonce 缺失、SQL 注入、i18n 遗漏、查询性能问题 |
| `woo-guard` | WooCommerce 扩展/结账/订单/HPOS | 直接操作订单元数据、HPOS 兼容性破坏、结账绕过、金额处理错误 |
怎么用：一行命令，嵌入开发流程
guard-skills 通过 [Skills CLI](https://github.com/vercel-labs/skills) 安装，兼容 Claude Code、Codex、Cursor、OpenCode 等主流 AI 编程代理。安装极其简单：
# 安装全套守门技能
skills install amElnagdy/guard-skills
# 或者只安装某一个
skills install amElnagdy/guard-skills/skills/clean-code-guard安装后，使用方式有两种。推荐的做法是”后置审查”——让 AI 代理生成代码后，立刻用守门技能检查 diff：
用 $clean-code-guard 检查你刚才产生的 diff。
用 $test-guard 审查你刚才写的测试。
用 $docs-guard 检查这个 README 更新再发布。
用 $wp-guard 检查这个 WordPress 插件的改动。也可以前置约束——在开始写代码时就激活守门规则：
在实现这个 REST 端点时使用 $wp-guard，完成前自我检查。这种设计哲学非常务实：它不试图改变 AI 的工作方式，而是在 AI 的输出和代码仓库之间架起一道滤网。你不需要纠结”为什么 AI 又犯了同样的错误”——让守门技能去抓，你只需要在审查结果出来后做决策。
谁需要它：每一个把 AI 代码送进生产环境的人
如果你只是偶尔用 AI 帮你写个小脚本、生成一段正则表达式，guard-skills 可能对你来说太重了。但如果你属于以下任何一类场景，它几乎是必需品：
AI 重度用户：你每天和 Claude Code、Cursor 或 Codex 协作，大量代码由 AI 生成。初始质量不错，但一段时间后你会发现代码库里积压了大量 AI 特有的”隐秘债务”——那些通过了测试但实际上逻辑有问题的代码。clean-code-guard 能在它们沉淀之前拦截。
WordPress/WooCommerce 开发者：WordPress 生态有自己的安全规范——数据逃逸、nonce 验证、权限检查、预编译 SQL——这些是通用代码审查工具覆盖不到的。AI 代理尤其容易在这些方面犯错，因为它的训练数据里混杂了大量不安全的 WordPress 代码。wp-guard 和 woo-guard 是作者 Ahmed Elnagdy（本身就是资深 WordPress 开发者）从日常实践中提炼出来的”运费前检查”。
重视测试质量的团队：AI 写的测试有一种特别危险的倾向——”看起来很专业，实际上什么都没测”。Mock 满天飞、断言只检查日志输出、测试用例之间互相重复。test-guard 的九条通用规则直接针对这些 AI 测试的”注水”问题。
技术写作和文档维护者：AI 写文档很快，但它也很快编造不存在的函数名、参数和返回值。docs-guard 的核心理念是”把文档当成一组声明，逐条对照代码库验证”——这比人工校对高效得多。
guard-skills 不是银弹，它不替代代码审查、CI 流程或安全审计。但它在 AI 编程工作流中填补了一个关键的空白：在 AI 的”快速产出”和代码仓库的”质量底线”之间，建立一道自动化的守门机制。 正如项目作者所说：”别写更长的指令文件了——加一道守门检查就好。”
如果你正在严肃地使用 AI 编程代理，这 512 颗星背后的项目值得一试。
— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn
