让 AI 当测试员：对着正式环境把两个端点了一遍，修了 15 个问题

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

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

拾阶有网页、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，是产品决策。它把这条列在「建议」里，没有自作主张去做。

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

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

1. 边界先于任务。 用哪个账号、能改什么、改了要不要改回来、什么不能在正式环境做，先说清楚。
2. 证据要留下来。 每一步都有截图和文字，报告里每个「通过」都能追溯。
3. 区分「通过」和「需确认」。 测试工具的局限要如实写进结论，不能为了好看合并成「通过」。
4. 一个问题一个提交。 测试中修 bug 很容易越修越多、混成一团，拆开以后才能单独回退。
5. 报告要写给下一个人看。 修了什么、没修什么、为什么没修、需要谁做什么，四块缺一不可。

App 的成绩与解析页。得分、对错数、用时、掌握度，下面是逐题解析，「其他选项为什么错」就在这里。

拾阶 App：成绩与解析

小程序的错题本，分成「该复习」「没弄懂」「已弄懂」三栏。App 那边漏掉的分页，就出在同一个页面上。

拾阶小程序：错题本

家长管控页。那个不回显的休息时段，就是在这一页上发现的。

拾阶 App：家长管控

下一篇讲另一个只有真用起来才会暴露的问题：老师上传 20MB 以上的视频总是失败，查到最后，问题根本不在大小限制上。