AI 编码 Agent 需要编辑反馈机制

大多数 coding agent 的防护规则都是用文字描述的：尽量缩小 diff、优先使用标准库、不要随意添加依赖。这些都是好指令，但它们属于开环指令。一旦 Agent 完成编辑，当前会话还需要一种机制，及时暴露这些偏好是否已被违反。

Ratchet 是一个围绕这一缺口构建的小型开源项目。它的 README 介绍了一组 hooks：检查 Agent 的编辑、进行度量，并将发现的问题反馈到同一个会话中。项目提供了四种模式：advise、guard、strict 和 off，其中 guard 是默认模式。根据项目说明，strict 处理仅适用于被评定为 certain 的发现，并且能否真正执行，还取决于宿主是否遵循返回的决策。

它试图让哪些问题变得可见

文档中列出的 detector 有意聚焦于实际问题：manifest 中新增的依赖、疑似重复的 symbol、只负责转发参数的 wrapper、重复实现平台已有能力的代码、只有一个实现的 abstraction，以及针对新增文件数、新增依赖数和净新增代码行数设置的 budget。

这是审视 Agent 辅助开发的一种实用视角。真正的成本往往并非来自某一个明显错误的决策，而是长时间会话中不断积累的、难以审查的小改动：又引入了一个 package，又增加了一个透传 component，又写了一个其实已用其他名称存在的 helper。

从公开 repository 的结构来看，项目在 hooks/ 下分别组织了 guard hook、读取变更的代码和检测代码；其 package manifest 声明需要 Node.js 20+，并使用 node --test。这只是对源码的观察：我没有安装、配置或运行这个项目。

边界才是重点

Ratchet 的 README 明确说明，这些 detector 使用的是 regex 和 git grep，而不是 type checker。因此，每项发现都应该被视为一条 review 提示，而非对正确性的裁决。这也意味着，它不能取代测试、安全审查或架构判断。

与 grep、LSP 或直接阅读 diff 相比，它的不同之处并不在于拥有更深入的语义理解，而在于触发时机和连续性：检查会在 Agent 完成编辑后运行，项目还会记录面向会话的度量数据，例如 mark 和 ledger。对于已经在使用 coding agent 的团队，这可以把模糊的开发偏好转化为简短、及时的讨论，而且此时变更规模通常还很小。

谁应该考虑使用它？

如果你的团队已经建立了 Agent 工作流，并且反复在 Agent 生成的 diff 中发现依赖膨胀或不必要的 abstraction，那么可以考虑这类工具。如果你需要类型层面的确定性、无法接受 heuristic 带来的误报，或者不想维护 hook 配置，那就不适合使用它。

我会把它作为正式 review 前的一道减速带来评估：先从 advisory 模式开始，观察它发现的问题对你的 repository 是否有价值，同时保留原有的测试和 review gate。不要把 alert 当作证据。

未经测试，也未实际运行。本文基于公开文档和源码检查，不对其性能、准确性或兼容性作任何独立声明。延伸阅读：项目的 README、detector module 和 guard hook。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。