我 Vibe Coding 了一个 iOS / Flutter 项目的 AI 代码改动检查工具

我用 AI 写代码已经两年多了。

最近两个月，我几乎每天都在真实 iOS 项目中使用 AI 进行协作开发：封装 SDK、迁移旧代码、补 Demo、改使用文档、发 npm 包等。

所以这篇文章不是想讨论"AI 到底会不会写代码"，我现在关心的是另一件事：

text 复制代码

AI 参与真实项目开发以后，怎么让它改完代码还能留下可检查的反馈？

这个工具的灵感来自 sentrux。

我理解 sentrux 这个开源库之后，最受启发的不是某一个具体功能，而是它的设计思路：

text 复制代码

不要只相信 AI 自己说改了什么。
要先观察项目结构和真实改动，再把结果反馈给 AI 和开发者。

这件事放到移动端项目里，非常有价值。

因为 iOS / Flutter 项目里有很多地方不是不能改，而是不能"不知道为什么就被改了"。

比如：

iOS 里的 Podfile、Info.plist、签名配置、权限配置。
Flutter 里的 pubspec.yaml、ios/Runner、android/app。
App 里的登录、支付、订阅、扫脸、结果页、历史记录等核心功能。
为了临时跑通功能留下的测试数据、跳过校验、调试开关、强制解锁。

这些改动不一定会马上让项目编译失败，但如果它们混在一次普通需求修改里，后面排查问题就会很麻烦。

所以我结合最近两个月的 iOS 项目 AI 编程实践，vibe coding 了一个很小的工具：

AI 改代码前先记录项目状态，AI 改完后检查这轮改动有没有明显风险。

项目地址：github.com/lmmzzh/zzh-...

一、我想补上的是 AI 改代码后的检查反馈

我需要的不是另一个代码质量平台，也不是一个能给代码打分的复杂系统。

我想先解决一个很具体的问题：

text 复制代码

AI 这轮到底改了哪些文件？
有没有动到高风险配置？
有没有碰到核心功能？
有没有留下临时代码？
改完以后我应该重点验证什么？

如果这几个问题没人回答，AI 改代码就会变成一次性动作。

它可能真的把功能写出来了，但开发者仍然不知道这轮修改有没有扩大范围。

在移动端项目里，这个风险很明显。

一次看起来普通的页面修改，可能同时改到了订阅、权限、扫脸结果页、历史记录等项目核心功能或者依赖配置。
代码看起来还能跑，但问题已经埋进去了。

zzh-mobile-ai-guard 要做的，就是把这类风险提前摆出来。

二、为什么不是让 AI 自己注意一点

当然可以在提示词里写：

text 复制代码

不要改不相关文件。
不要动核心功能。
不要留下临时代码。

这些提示有用，但不够稳定。

因为提示词约束的是 AI 的行为。

我更想要的是一个能看真实改动的东西。

也就是：

text 复制代码

AI 说它没乱改，不算。
工具扫到它到底改了什么，才算。

所以这个工具没有做成 SDK，SDK 是给 App 运行时用的，比如埋点 SDK、支付 SDK、扫脸 SDK。

但我这个问题发生在开发阶段，它应该是一个命令行工具，而不是塞进 App 包里的运行时依赖。

它也没有只做成某个 AI 工具的 skill，skill 可以提醒 AI 怎么做事，但它不能稳定保存改代码前的状态，也不能脱离某个 AI 工具独立使用。

最后我把它做成了一个 CLI：

bash 复制代码

npm install -g zzh-mobile-ai-guard

日常命令叫：

bash 复制代码

zmg

三、这个工具只让用户记住三个命令

我不想让第一次接入的人先理解一堆概念。

什么 baseline、report、protected path、severity，这些都可以放在工具内部。

用户第一次只需要记住：

bash 复制代码

zmg init
zmg start
zmg check

这三个命令分别对应三件事。

zmg init：给当前项目接入这个工具。

bash 复制代码

zmg init

它会生成：

text 复制代码

.zzh-mobile-ai-guard/
  rules.yml
  baselines/
  reports/

第一次使用不需要先改配置。

zmg start：AI 改代码前，先记录当前项目状态。

bash 复制代码

zmg start

它会记住当前项目里的文本文件、行数、hash、git 分支和 commit。

zmg check：AI 改完后，检查这轮改动有没有明显风险。

bash 复制代码

zmg check

它会给出结论、风险项、建议人工验证项和报告路径。

这个流程很小：

text 复制代码

改前记录 -> AI 修改 -> 改后检查 -> 再决定怎么验证

但这个小流程对我很有用，因为它把"AI 到底改了什么"这件事固定下来了。

四、它会检查什么

现在这个工具主要检查几类问题。

第一类是改动范围。

比如这轮改了多少文件，新增多少行，删除多少行。

如果你只是让 AI 改一个按钮文案，结果它改了二十几个文件，这件事就值得停下来看看。

第二类是高风险文件。

比如：

text 复制代码

Podfile
Info.plist
pubspec.yaml
*.entitlements
AndroidManifest.xml
Xcode 工程文件

这些文件不是不能改，但如果它们被改了，至少应该知道为什么。

第三类是核心功能目录。

比如登录、支付、订阅、扫脸、平台目录等等app的核心功能。

这些地方被改到以后，不能只看编译，还要回到真实功能里验证。

第四类是临时代码。

比如：

text 复制代码

bypass
mockUser
debugOnly
forceUnlock
return true

这类代码有时候是为了临时验证，但如果它们跟着正式提交出去，风险就很高。

五、报告不能只说"有风险"

我最开始只需要工具告诉我：

text 复制代码

这里有风险。

后来发现还不够，因为真正看报告时，我还会继续问：

text 复制代码

为什么这个文件有风险？
如果它就是本轮目标，这个风险能不能接受？
如果它不是本轮目标，应该怎么办？
接下来应该验证什么？

所以我给报告加了风险解释。

比如改到了 Podfile，报告里会写：

text 复制代码

[high] Podfile：本轮改动触碰了高风险配置文件。

为什么要看：
这个文件会影响 iOS 依赖安装和编译结果。

什么情况下可以接受：
如果本轮目标就是调整 iOS 依赖，可以接受。

如果不是本轮目标：
如果本轮没有要求改依赖，先确认是不是 AI 顺手改动，必要时拆出去或回退。

建议验证：
重新执行 pod install，并编译 iOS 项目。

这个变化对我来说很关键，因为它不是单纯报警，它是在帮我判断：

text 复制代码

这个风险是不是本轮应该出现的风险。

如果是，那继续验证；如果不是，那先别急着提交。

六、为什么要有 `--strict`

普通的 zmg check 是提醒模式，就算发现风险，它也只是把风险列出来，不会直接让命令失败。

这样对第一次使用的人比较友好，但如果我想把它放进本地 Git Hook，提交前自动拦一下，就需要更强一点的模式。

所以现在有：

bash 复制代码

zmg check --strict

它的规则是：

没有中高风险，正常通过。
有 medium 或 high 风险，命令返回失败。
失败前仍然会生成完整报告。

这样就可以做本地提交前检查。

比如 pre-commit 里可以写：

bash 复制代码

#!/usr/bin/env bash
set -e

if ! command -v zmg >/dev/null 2>&1; then
  echo "zmg is not installed. Run: npm install -g zzh-mobile-ai-guard"
  exit 1
fi

zmg check --strict

我现在只做本地 Git Hook，没有急着做 CI。

原因也很简单，这个工具当前最有价值的地方，是本地 AI 改代码前后的对比。

CI 里如果只是干净拉一份代码，然后连续跑：

bash 复制代码

zmg start
zmg check

意义不大。

以后如果要做 CI，应该专门设计 PR diff 模式，而不是直接把本地流程搬上去。

七、怎么让 AI 配合使用

如果你在 Codex CLI、Claude Code、Cursor 里改代码，可以直接告诉 AI：

text 复制代码

本轮改代码前，请先在项目根目录运行 zmg start。

改完代码后，请运行 zmg check。

如果 zmg check 报告风险，请先说明：
1. 哪些风险属于本轮目标。
2. 哪些风险可能是误改。
3. 哪些文件需要我人工验证。
4. 完整报告路径在哪里。

不要把 zmg check 通过当成编译通过或业务功能验证通过。

我在仓库里也放了这份说明：

text 复制代码

docs/ai-usage.md
docs/ai-usage.zh-CN.md

这段提示的重点不是让 AI 多跑一个命令，重点是让 AI 改完以后，必须把检查结果解释清楚。

如果有风险，它要说明哪些是本轮目标内的风险，哪些可能是错误修改。

这样我才知道下一步该继续验证，还是先回退一部分改动。

八、它不能替代什么

这个工具的能力边界必须说清楚：

它不能证明代码能编译。
它不能证明业务功能正确。
它不能替代真机验证。
它也不能理解需求到底有没有实现对。

它现在做的是：

text 复制代码

检查 AI 这轮改动有没有明显风险。

所以如果 zmg check 通过，只能说明：

text 复制代码

没有发现明显的改动范围和结构风险。

不能说明：

text 复制代码

功能一定没问题。

移动端项目还是要继续编译、测试、真机验证，这个工具只是把"提交前先看一眼有没有越界"这件事固定下来。

九、如果你想试一下

安装：

bash 复制代码

npm install -g zzh-mobile-ai-guard

在项目根目录运行：

bash 复制代码

zmg init
zmg start

然后让 AI 改代码。

改完后运行：

bash 复制代码

zmg check

如果你想在本地提交前拦住中高风险：

bash 复制代码

zmg check --strict

GitHub 地址：

github.com/lmmzzh/zzh-...

目前它更适合 iOS / Flutter 项目。

如果你的项目里也有不希望 AI 在无明确目标时改动的配置文件、权限文件、平台目录或核心功能目录，可以试一下。

十、最后

AI 改代码、写代码现在已经是家常便饭了。

我现在更关心的，是它改完以后，我能不能快速知道：

text 复制代码

这次改动有没有超出目标？
有没有动到不该动的地方？
有没有留下临时代码？
接下来应该重点验证什么？

zzh-mobile-ai-guard 只是一个很小的工具，但它帮我把 AI 改代码后的第一轮检查固定了下来。

对真实项目来说，这种改完就检查的习惯，比单纯相信提示词更可靠。

我 Vibe Coding 了一个 iOS / Flutter 项目的 AI 代码改动检查工具

一、我想补上的是 AI 改代码后的检查反馈

二、为什么不是让 AI 自己注意一点

三、这个工具只让用户记住三个命令

四、它会检查什么

五、报告不能只说"有风险"

六、为什么要有 --strict

七、怎么让 AI 配合使用

八、它不能替代什么

九、如果你想试一下

十、最后

六、为什么要有 `--strict`