prek 多语言 Git 钩子质量检查

痛点：提交前的检查正在拖慢节奏

在多语言仓库里，代码风格、格式化规则和质量门禁往往分散在多个工具链中：Python 用 ruff/black，TypeScript 用 eslint/prettier，Shell 用 shellcheck。这些工具如果靠人工触发，很容易遗漏；如果靠 CI 跑完再修，反馈链太长。pre-commit 框架解决了钩子调度问题，但传统 Python 实现启动慢、磁盘占用高，在大型仓库或多语言项目里体验并不理想。

更现实的问题是：当 Agent 或开发者在本地改完代码准备提交时，缺少一个快速、统一、可复现的本地拦截层。于是风格问题、明显语法错误甚至不合规的变更会直接进入远端，后续再靠 CI 或 review 兜底。

这个技能做了什么

prek 是一个 pre-commit 兼容的钩子运行器，目标是用更低的启动开销执行同样的仓库级钩子配置。它的核心工作方式很直接：

• 复用现有 pre-commit 配置：读取仓库根目录下的 .pre-commit-config.yaml，无需为 prek 单独写一套规则。
• 统一调度多语言钩子：配置里声明的 Python、Node、Go、Shell 等语言的 hook，由 prek 统一拉起并执行。
• 在提交前拦截变更：通过 Git hook 在 git commit 前运行，只检查暂存区中的文件，避免全仓扫描。
• 返回明确退出码：钩子失败时阻止提交，并输出需要修复的文件和工具信息。

对工程团队来说，价值在于把质量门禁前移到本地提交阶段，同时保持团队已有 pre-commit 规则不变。prek 目前已被 CPython、Apache Airflow 等大型项目采用，说明它在多语言、高频率提交场景下具备一定成熟度。

适用边界与注意点

• 需要仓库已有 pre-commit 配置：如果项目从未使用 pre-commit，这个技能无法凭空生成规则。
• 钩子质量取决于配置本身：prek 负责调度和执行，不负责判断规则是否合理。空规则、过严规则或错误挂载的 hook 都会直接影响体验。
• 多语言支持依赖对应运行时：配置里声明的 hook 仍需要目标语言工具链可用，例如 Node hook 需要 node 和 npx。
• 不是 CI 的替代：本地钩子能拦截大部分明显问题，但合并请求、并发构建和依赖审计仍应在 CI 中完成。

简单说，prek 适合那些已经用 pre-commit 管理质量规则，又希望降低本地钩子开销的多语言仓库。它解决的是执行层的性能与兼容性问题，而不是重新发明规则体系。