写在前面
用 AI 写代码之后，交付速度上去了，但代码质量的最后一关仍然要人来扛——做 Code Review 的同学会越来越累，而「这段代码到底有没有问题」这件事，反而比以前更关键。
我们团队在用 AI 辅助 CR（思路可参考我之前的掘金文章），这次想把它嵌进日常提交习惯：不是等合并前才集中救火，而是每次 commit / merge 都能触发一轮检查；同时尽量靠流程而不是靠自觉，避免「说了要做 CR、忙起来就跳过」。
直接全上企业 CI/CD 也能做，但往往已经承载编译、测试、安全扫描等一堆任务，再叠一层会显得重。于是我们做了一个折中：在本地 commit / merge 时自动拉起 Cursor Agent 做 CR 的扩展，并已上架插件市场。
如果你关心「怎么把规范落到每次提交上」「AI CR 有哪些边界」，下文按目标 → 原理 → 使用 → 踩坑与经验展开。
我们想达成的两个标准
| 标准 | 含义 |
|---|---|
| 提交即反馈 | 同学在 commit / merge 时能触发 CR，尽快看到 AI 对本次改动的意见，避免堆到最后大改。 |
| 流程自动化 | 规范建在流程上，减少「靠人提醒」；与 CI 解耦一层，先让本地钩子 + IDE把 CR 变成默认动作。 |
扩展在做什么：Git Hook + Cursor Agent
核心思路是利用 Git 的 hook，识别 commit、merge 等操作；触发时在 Cursor 里打开 Agent 对话框，并写入与 CR 相关的提示词。
默认会把：
- 本次 commit 涉及的代码变更；
- 团队约定的 CR 规范（需与下文命令、文档配套）；
- 你自定义的需求背景（可选）；
一并作为 prompt 输入，再执行 AI CR。
Cursor插件市场可直接下载
github源码：github.com/ApolloNaco/…
安装与启用：别忘记 post-commit hook
从市场安装后，按扩展提示完成 post-commit hook 的安装，否则「提交后自动拉起」这一环不会生效。
写小需求、临时不想跑自动 CR 时，可以在扩展里关闭，避免打扰。
配置项：和团队规范对齐
Ctrl + ,（Mac 为 Cmd + ,）打开设置，搜索 AutoCR，可看到与行为相关的选项。
常见能力包括：
- 排除不需要 CR 的文件（减少噪音）；
- 触发 CR 的最小行数（避免无意义的小改动也跑一轮）；
- 触发时实际发送的命令。
示例命令形态（需与你们维护好的 CR 规范文档配合，规范说明见：掘金 · 相关文章）：
/review [commit-hash] -o --dir [outputDir]
背景信息：让 CR 更贴业务
CR 时如果缺少上下文，AI 容易「说得对但没用」。扩展里支持补充用户 / 需求背景，便于模型理解「这次改动在解决什么问题」。
经验与边界：AI CR 不是银弹
结合我们现在的用法，有三点想坦诚说清楚。
1. 单 Agent 不够稳，多视角交叉更靠谱
AI CR 不能保证 100% 发现问题，也不能保证每条意见都靠谱。我们的做法是拆成多个 CR Agent，从不同角度扫：
- 性能；
- 明显 bug；
- 安全；
- 业务逻辑与边界。
多路交叉，提高「被揪出来」的概率，但仍然是概率，不是证明。
2. 控制单次 CR 的体量：小块、高频
实践上建议每次只 CR 一个小模块，单次改动量级上不要超过约 400 行（可按团队习惯微调）。这样：
- AI 更容易聚焦；
- 人工也能在模块粒度上确认「思路和设计是否走偏」。
若一口气堆到几千行再 CR，规范或架构上的问题往往已经积重难返，同学改起来痛苦，Review 也无从下手。小块提交 + 小块 CR，和 AI 写代码的节奏更匹配。
有条件时，CR 角色也建议交叉：至少包含作者 + 两位 Reviewer 视角（其中可部分由 AI 辅助），避免单点盲区。
3. 把「漏网之鱼」变成系统的养料
团队里真实发生过的缺陷、AI 没扫出来的坑，建议结构化记录下来（可做简单埋点或问题库），持续反哺 prompt、规则和检查清单。系统是在真实失败案例上慢慢变准的，而不是一次配置就一劳永逸。
结语
AI 把「写代码」变快了，质量保障反而要更工程化：把 CR 嵌进 commit / merge、用配置把噪音和成本控制住、用多 Agent 与小块改动降低盲区——插件解决的是习惯与入口，真正的标准仍在你们的规范、用例和人工判断里。
欢迎在评论区交流你们在 AI CR、Git Hook 或 Cursor 工作流上的做法；若后续有版本更新或配套文档，我会尽量在正文里同步链接。
本文基于团队实践整理，插件能力与 Cursor / 市场政策以官方为准。
