让 AI 当测试员：对着正式环境把两个端点了一遍，修了 15 个问题|app|代码|字母|正式环境|测试员|错题本

一、给它的任务二、怎么点三、找到了什么四、它做得好的地方五、还得人来的地方六、如果你也想这么做附：测过的页面长什么样

一个人做产品，最先被牺牲的往往是测试。

拾阶有网页、iOS/Android App、微信小程序三个终端。后端有 850 多个自动化测试，每次提交前都跑；前端每次提交前都过类型检查。但有一类问题，这些检查一个都抓不到：

App 里一句带边框的重点结论，右半句被屏幕切掉了；
错题本里刚做错的题找不到，因为列表只取了前 50 道；
学生收到的测评报告，开头写的是「孩子刚完成一次测评」，那是写给家长的。

接口返回是对的，类型是对的，单元测试是绿的。只有把页面真正打开、用眼睛看，才知道不对。

所以我做了一次以前只敢想想的事：把 iOS App 和微信小程序的「全功能测试」整个交给 Claude Code，对着正式环境，一个页面一个页面地点，发现问题就修，修完再点一遍。

这篇讲它是怎么做的、找到了什么、哪些地方还得人来。

任务说得很直接：用 iOS 模拟器和微信开发者工具，对着正式环境，把 App 和小程序的学生端、家长端所有功能走一遍；发现问题就修，每个问题一个提交；最后出一份测试报告，写清楚测了什么、修了什么、还有什么没修、哪些需要我来做。

还有几条边界，比任务本身更重要：

只用测试账号。 一个学生、一个家长，同一批数据。
改了设置要改回去。 家长管控的每日上限从 120 分钟改成 60 分钟，验证完再改回 120。
不制造垃圾数据。 反馈表单只走到填写那一步，不在正式环境提交，否则会生成一张没人需要处理的工单。
测不了的要说测不了。 模拟器和真机行为不同的地方，标成「需真机确认」，不能写成「通过」。

运行环境 | iOS App: Xcode 模拟器，Release 包 | 微信小程序: 微信开发者工具

构建 | iOS App: 接口指向正式环境 | 微信小程序: 构建时接口同样指向正式环境

自动化 | iOS App: Maestro 点按、输入、横竖屏切换；simctl openurl 走深链 | 微信小程序: miniprogram-automator

判定 | iOS App: 截图逐张看 + 界面树文字比对 | 微信小程序: 页面数据树文字比对 + 截图

「判定」这一行是关键。自动化框架能告诉你「按钮点到了」，但不能告诉你「页面对不对」。所以每一步都留两样东西：一张截图，加上从界面树里导出的文字。截图用来看排版，文字用来比内容。

两个端用同一个账号、同一批数据，逐页对照两件事：功能对不对，以及两端一不一样。第二件事常被忽略，但对用户来说，同一个功能 App 上和小程序上表现不同，本身就是一个 bug。

一共 15 个问题，15 个提交。挑几个有代表性的讲。

右半句被切掉。 讲解里大量用公式框标重点结论，框里其实是一整句中文。App 用 KaTeX 排版，公式不换行，手机屏幕放不下，右半句直接没了；小程序里它是一张图，缩到屏宽以后字小得看不清。已发布的知识点里九成都有这种写法。这个问题的修法上一篇讲过：框里是一句话，就按一句话排。

刚做错的题找不到。 App 的错题本只请求了第一页的 50 道。测试账号「没弄懂」那一栏已经有 75 道，最新做错的那几道恰好排在 50 名以后。网页版有分页，所以一直没人发现 App 少了。

报告写错了对象。 学生做完测评收到一条站内信，内容是「孩子刚完成一次测评……」。这条消息的模板本来是给家长的，学生和家长共用了同一个。

「其他选项错在哪」张冠李戴。 成绩页每道选择题下面有「其他选项为什么错」的解析。测试时发现 B 选项的解析说的是 C 的事。追下去是一个数据脚本的问题：之前为了避免正确答案总落在同一个字母上，写过一个打散选项顺序的脚本。它挪了选项和答案字母，却没有挪按字母存的那份解析。代码修了，已经打散过的数据另写了修复脚本。

设置不回显。 家长如果设过一个不在预设列表里的值，比如 21:30 到次日 06:00 的休息时段，App 管控页里的选项就一个都不亮。家长看到的是「好像什么都没设」。

引导到死路。 学生学习时长用完后会看到休息页，页面说「可以用积分兑换」，还有一个大按钮。但如果家长没开这个功能，点进去只有一句「兑换暂时不可用」。现在先查一下兑换状态：家长开了、今天还能换，才显示按钮；否则只说「跟家长说一声」。

这些问题有一个共同点：每一行代码单独看都是对的。错题本请求接口没错，只是少了分页；消息模板没错，只是用错了人；打散脚本没错，只是少挪了一样东西。它们都卡在「组合起来」这一步，而组合正是单元测试最不擅长的。

耐心。 学生端 20 多个功能点、家长端十几个，每个都要点进去、截图、比对、退出、换另一端再来一遍。这种活人做两个小时就开始走神，它不会。

能顺着现象一路追到根因。 「B 选项的解析说的是 C」，从现象到「打散脚本没挪解析」，中间要查成绩页的接口、题目的数据结构、题库的修改历史。这条链路它能自己走完，并且在报告里写清楚：代码已修，线上数据需要单独跑修复脚本，修复前先在只读模式下预演，打印要改多少条、改成什么样。

两端对照。 它会主动发现「App 的学科页标题是『知识点』，小程序是学科名」这种不一致。不是 bug，但用户会觉得奇怪。

一个问题一个提交。 15 个问题对应 15 个提交，每个提交信息写清楚改了什么、为什么。哪个改动有问题，可以单独回退。

真机。 开发者工具里小程序的 web-view 是 Chromium，真机上是系统的 WebView，全屏、横屏这类行为不一样。报告里这几项标的是「已改进，需真机确认」，而不是「通过」。这个区分非常重要，比多修一个 bug 重要。

判断「该不该修」。 比如家长中心只有孩子卡片，没有学情摘要。这不是 bug，是产品决策。它把这条列在「建议」里，没有自作主张去做。

正式环境的数据。 涉及线上数据的修复，它只写脚本、写清楚执行步骤，不直接改库。写库这一步留给人。

部署。 所有修复都在代码仓库里，不会自己推到线上。