最近 Mole 发布到了 1.13.0。我顺手看了一下项目：110,947 行产品 Swift 代码、72,999 行测试代码，还有 3347 个 XCTest。测试代码大约是产品代码的 66%，远多于以前在公司写业务、有 QA 保障时的比例。

我一直有个观点：AI 写的代码应该交给 AI 来测试。人负责决定什么值得测、边界放在哪里，而不是手动重复验证。

第一个版本能跑以后，我就开始和 AI 讨论架构、分层和同类抽象，把什么东西应该放在哪里、哪些边界不能碰写进文档，后面再跟着项目一起改。

我目前最依赖的还是单测。Mole 1.0 只有 56 个 XCTest，到 1.13 已经有 3347 个。数量只是顺手统计的结果，我更关心那些容易想当然的情况有没有被测到：扫描结束后文件又变了、进程检查失败、命令返回成功但 App 根本没更新、旧任务很晚才回来覆盖新结果。正常情况不难测，麻烦的是那些看起来成功，实际上已经错了的情况。

每次修 Bug，我也会尽量多留一点东西：一个能让旧代码失败的回归测试，一次同类路径排查，再把当时为什么这么改写进 Rules。到 1.13 时，Mole 已经有 1000 多个以 fix 开头的提交。很多测试和规则，都是用户真实踩过一次以后留下来的经验。

Rules 负责记住功能边界和历史原因，Skills 负责把重复检查自动跑起来。规则多了很费上下文，我就按模块拆开，只在改到相关代码时加载，不需要每次从头解释。

另一个很有用的办法，是少做一些没有实际用途的功能。AI 加一个设置项、兼容分支或者后台监听太容易了，真正留在项目里的却是状态和维护成本。所以 Mole 尽量不增加常驻开销，不扩大特权面，有合理默认值就不继续堆设置项。如无必要，勿增实体。

测试变绿以后也还没有结束。本地代码、Git 提交、签名安装包、线上文件和用户真正收到的更新，我会分开确认。执行可以交给 AI，我负责把卡点放在合适的位置，拿到明确结果以后才让它继续。

手写代码的乐趣少了一些，好在看着这套系统越来越听话，也弥补了一点纯 AI Coding 的无聊。

#AI #独立开发 #产品工程师 #macOS #Mole