在代码规范方面，团队最担心的问题往往不是开发者写出糟糕的代码，而是这些不合规的代码在无人察觉的情况下悄然合并进主分支。MiMo Code 提供了一种巧妙的解决方案：它不会直接阻止你按下 git commit 的确认键，但会在你提交之前，预先铺设一道精密的合规筛选网。换句话说，它并非“卡死”你的操作，而是帮你在提交前全面“过一遍筛子”。

具体如何筛选？主要分为两条路径：一条是通过 GitLab Webhook 实现 Merge Request 级别的自动审查，另一条则是在本地开发环境中直接执行 lint、test、diff 等命令，在编码的日常循环中及时发现并修复不合规的内容。

GitLab Webhook 集成：MR 阶段的自动审查

如果你将 MiMo Code 部署到 CI/CD 流水线中，它便能与 AI-Codereview-GitLab 这类工具协同工作。这套系统会监听 GitLab 的 Merge Request 或 Push 事件，一旦有代码变更，就会调用大模型对变更部分进行静态分析，并将分析结果以 Note 的形式直接写入 MR 页面。

请注意，MiMo Code 本身并非审查引擎，但它能扮演“审查发起者”的角色。例如，你可以直接用自然语言下达指令：“检查本次提交是否符合团队的 ESLint 规则”，它便会自动拉取 diff、运行 lint 命令、解析报错信息、生成修复建议，甚至帮你编写好修正补丁并提交。

• 需要提前将 GitLab webhook 指向审查服务地址
• MiMo Code 能够读取 MR 的 commit SHA 和文件变更列表，精确定位需要审查的代码范围
• 审查结果会附带具体行号、问题类型（例如“未定义变量”“缩进错误”），以及修复示例

本地预检：写代码阶段的规范约束

再来看本地开发场景。MiMo Code 在终端中运行时，天然具备干预代码风格、结构和逻辑的能力。它不会等到你提交时才跳出来叫停，而是在“写→测→改→提”的整个流程中持续施加约束：

• 新建或修改文件前后，自动执行 prettier --check 或 eslint --no-warn，判断当前项目代码是否满足规范
• 代码生成结束后，强制运行 git diff --cached，并结合模型理解判断是否存在潜在坏味道——比如重复逻辑、硬编码或未处理的异常
• 支持绑定自定义 hook 脚本，例如在 compose 模式下执行 ./scripts/verify-format.sh
• 一旦检测到不合规内容，流程会暂停，并给出可操作的修复指令（如“请运行 npm run format 后再继续”）

换句话说，它就像在你指尖旁边站着一位耐心的质检员，不会直接掀翻桌子，但会清晰地告诉你哪里有问题、应该如何改正。

基于 Goal 停止条件的合规性终审

MiMo Code 有一个非常核心的设计：允许用户使用自然语言定义“停止条件”。例如，你可以设定：“所有 ESLint 错误已修复，且单元测试全部通过”。此时，系统会启用一个独立的验证器（Verifier）模型，严格比对实际执行结果与你设定的目标：

• Verifier 不参与编码过程，只读取完整的对话历史以及实际命令输出——包括 lint 报错、test 失败日志
• 如果发现 ESLint 仍有 warning，或者代码中隐藏了 // eslint-disable-next-line 这类绕过操作，它会明确指出差距，并拒绝终止
• 只有当所有规范检查项都返回 success，并且 git status 显示 clean，才视为任务完成

这才是真正的“自动过滤”：它并非简单地运行一个脚本，而是让模型自主判断是否真正达到了合规要求。

权限与安全边界：可控执行是第一原则

当然，自动审查的前提是可控。MiMo Code 默认没有 root 权限，不会擅自修改生产配置。所有审查操作都限制在用户当前工作目录下，每次写入前还会显示 diff 预览。建议的做法：

• 在 .mimo/config.json 中明确禁用高危命令（例如 rm -rf、chmod 777）
• 为 lint 工具指定严格的配置路径（如 --config ./eslintrc.prod.js）
• 首次使用时开启 dry-run 模式，先观察它对格式违规的响应，再放心全量运行

一句话概括：MiMo Code 不是来给你添堵的，而是帮你把规范问题在提交之前解决掉。只要条件设置清楚、权限管理严格，它就能成为一个相当靠谱的代码合规把关人。