把测试用例写成它一定会执行的自检流程
在这次迭代里，我踩了一个很典型的坑：
我以为自己已经在测试用例文件开头写清楚了「修完要自己过一遍所有 case」，但 AI 实际上并没有严格执行这一条。直到某个 bug 被我自己手动点到，才发现——原来我和 AI 对“这句话”的理解是不一样的。
这篇文章就专门拆开聊这一点：
为什么 AI 会“忽略”看起来很合理的用例说明？
我们应该怎么写测试用例 / 规则，才能让 AI 几乎不可能跳过自检？
一、问题的起点：一句「修完重新过一遍 case」为什么不生效？
我在 __tests__/test_main.txt 顶部写了类似这样一句话：
验证如下 case，如有错误，修复它。修复后重新过一遍 case，确保功能无异常。
从人的视角看，这很自然：
- 明确表达了「要整体过一遍用例」；
- 也强调了「修完要再重新检查」。
但实际执行中，AI 的行为是这样的：
- 当我指出「某个功能不对」时，它会优先去看那一块的代码，分析、修改；
- 修改完，会检查刚刚这个点是否 OK；
- 但不会自动回到整个
__tests__/test_main.txt，从头把所有 case 再跑一遍。
于是就出现了一个现象：
- 局部 bug 修了；
- 别的用例对应的逻辑，可能因为这次修改被影响，但 AI 并没有意识到要「重新回归」。
这不是 AI「偷懒」，而是我们给的信息在它的优先级体系里，只被当成“背景描述”，而不是“需要立刻执行的具体流程”。
二、AI 的视角：什么样的文字会被当成「必须执行的动作」？
大致可以这么理解：
- 背景描述：
- “修完后要重新过一遍 case”；
- “保持数据一致性很重要”；
- “请注意 xx 场景也要考虑”；
- 这些更像「价值观」与「注意事项」，AI 会参考，但不会每次都主动展开成一个 checklist。
- 明确指令 / 流程：
- “现在按 1~3 步执行：1）打开文件；2）逐条检查；3）不通过就修改”；
- “只要看到 @tests/test_main.txt 就进入自检模式”；
- “修改任意一处代码，都必须从 1.1 重新检查所有用例”；
- 这种就会被当作操作规程，在具体决策里优先执行。
人类工程师在脑子里有「隐含上下文」：
我们看到一句「修完重新过一遍 case」，会自动补全为一个完整的操作流程；
但 AI 不会隐式扩展这么多，它只会在需要时、按任务驱动地「用到哪条信息就读哪条信息」。
所以，如果希望它「必定执行自检」，就要把我们的期望写成显式、机械的流程规则。
三、把期望写成流程指令：一个更“机器友好”的版本
假设我们要在 __tests__/test_main.txt 顶部写一段「总则」，原来的写法是：
验证如下 case，如有错误，修复它。修复后重新过一遍 case，确保功能无异常。
更适合 AI 的写法，可以改成类似这样：
【自检总则（必须执行）】
- 对下方每一条用例（含所有大标题与子场景），AI 必须遵守以下流程：
1）先逐条阅读当前项目实现代码，自行判断是否满足该用例；
2）如果发现实现与用例不一致，必须先修改相关代码，再回到该用例重新自检；
3）只要在检查任意用例时修改过代码，修改完成后必须从 1.1 开始，按顺序再次检查所有用例；
4）不得仅检查用户当前提到的单个用例，而忽略本文件中其他已列出的用例。
这里有几个关键点：
- “必须执行”
明确强调这是硬性规则，而不是建议。 - 流程拆成 1）2）3）
便于 AI 在内部构造 checklist，并逐步完成。 - 触发条件 & 重复执行条件写清楚
「只要修改过任意用例相关代码，就要从 1.1 重新检查」——这是一个非常强的回归约束。
这样的写法，AI 在看到时更容易把它当成「要遵守的流程」，而不是轻量的背景信息。
四、用「触发规则」把自检变成一个模式
除了总则之外，还可以再加一段「触发规则」，告诉 AI 什么时候要开启这个自检模式。
例如，在文件末尾写：
【执行触发规则】
- 当用户在对话中出现以下任意行为时，AI 必须立即进入“用例自检模式”：
1）在消息中提到本文件路径或别名（例如：@__tests__/test_main.txt）；
2）在消息中显式要求“按照用例自检”、“对照测试用例检查”等类似表述。
- 进入“用例自检模式”后，AI 的执行顺序必须为：
1）从 1.1 开始，按顺序逐条阅读并检查所有用例；
2）对每一条用例，先判断现有实现是否满足；如不满足，先修改代码，再回到该用例复核；
3）任一用例修改过代码后，自当前用例结束起，重新从 1.1 依次复查全部用例；
4）在结束本轮会话前，总结哪些用例被触发了代码修改，以及最终是否全部通过。
这样，当我在对话里只打一句：
@__tests__/test_main.txt
AI 就会「意识到」：
哦，现在不是随便看看这个文件，而是需要开启一整套自检流程。
五、在每条用例前加上「执行要求」标签
对于关键用例（比如跨页面统计一致性、数据恢复、删除最后一题后的返回路径等），可以在用例标题下加一条「执行要求」，进一步强调它的重要性。
示例（以 1.2 顺序练习恢复题号为例）：
1.2【顺序练习恢复题号】
【执行要求】
- AI 在修改与“顺序练习页”、“题目列表加载”、“题号索引恢复”相关的任何代码后，必须重新完整执行本用例，确认行为与期望一致。
- 如修改会影响公共题库与地区题库两类场景，必须分别验证两类场景的行为。
这样做有几个好处：
- 你自己在人工回归时，一眼就能看出哪些是「高优先级用例」；
- AI 在阅读用例时，会明确知道「哪些代码改动需要重新验证这条用例」。
六、一个完整的「AI 友好测试用例文件」骨架示例
下面给出一个简化版骨架，你可以按自己项目实际内容替换标题和场景描述。
【自检总则（必须执行）】
- 对下方每一条用例（含所有大标题与子场景），AI 必须遵守以下流程：
1）先逐条阅读当前项目实现代码，自行判断是否满足该用例；
2）如果发现实现与用例不一致，必须先修改相关代码，再回到该用例重新自检；
3）只要在检查任意用例时修改过代码，修改完成后必须从 1.1 开始，按顺序再次检查所有用例；
4）不得仅检查用户当前提到的单个用例，而忽略本文件中其他已列出的用例。
--------------------------------
1.1【错题集 / 收藏集移除最后一题后的返回路径】
【执行要求】
- AI 在修改与“错题集”、“收藏集”、“页面返回逻辑”相关的任何代码后，必须重新完整执行本用例的所有子场景（A/B/C/D）。
场景A：地区题库-错题集
步骤：
1）在地区页选择一个城市，进入该城市的「错题」练习模式；
2）确保该错题集只有 1 道题目；
3）答对该题目，并选择「移出错题集」。
期望：
- 题目成功移出错题集；
- 页面自动返回到「地区页」的 Tab。
场景B：……（略）
--------------------------------
1.2【顺序练习恢复题号】
【执行要求】
- AI 在修改与“顺序练习页”、“题目异步加载”、“题号索引存储与恢复”相关的任何代码后，必须重新完整执行本用例的所有子场景（A/B），并确认行为与期望完全一致。
场景A：公共题库
……
场景B：地区题库（大题库，题目异步加载）
……
--------------------------------
1.3【首页 / 地区页统计与子页面实际数据一致性】
【执行要求】
- 只要统计相关代码、存储结构或计算逻辑有改动，AI 必须重新执行本用例。
- 包含以下统计项：已答题数 / 错题数 / 收藏数 / 考试记录次数 / 智能复习待复习题目数。
场景A：公共题库
……
场景B：地区题库
……
--------------------------------
【执行触发规则】
- 当用户在对话中出现以下任意行为时，AI 必须立即进入“用例自检模式”：
1）在消息中提到本文件路径或别名（例如：@__tests__/test_main.txt）；
2）在消息中显式要求“按照用例自检”、“对照测试用例检查”等类似表述。
- 进入“用例自检模式”后，AI 的执行顺序必须为：
1）从 1.1 开始，按顺序逐条阅读并检查所有用例；
2）对每一条用例，先判断现有实现是否满足；如不满足，先修改代码，再回到该用例复核；
3）任一用例修改过代码后，自当前用例结束起，重新从 1.1 依次复查全部用例；
4）在结束本轮会话前，总结哪些用例被触发了代码修改，以及最终是否全部通过。
你可以把上面这个骨架，直接套用到自己的项目，用来规范：
- 自己的人肉回归操作；
- 以及 AI 的自检行为。
七、实际使用建议：日常迭代中怎么配合这套规则？
结合我这次迭代的实际踩坑经验，总结几个小建议：
-
在每次大改前，先快速过一眼用例文件
看看有哪些「强约束用例」会被波及，比如跨页面统计、一致性校验、异步加载场景等。 -
在和 AI 对话时，主动引用用例文件路径
比如：本次改动会影响顺序练习、错题集和智能复习，请你严格按 @__tests__/test_main.txt 里的自检总则和所有用例做一遍自检。 -
当你发现一个没被检测出来的 bug 时，立刻把它写进用例文件
并按上文的方式加上明确的「执行要求」，防止下次再踩同一个坑。 -
把「自检总则」当作团队协作契约
不只是给 AI 用，人类同事也可以直接按照这份用例文件做回归，这样大家的检查口径才是一致的。
八、总结：让 AI 变成靠谱同事，而不是聪明实习生
这次经历给我的直观感受是：
- 如果只给 AI「目标」和「背景期望」：
它会像一个很聪明、很主动的实习生，能帮你解决眼前的大多数问题，但对「隐含规矩」不够敏感。 - 如果再给它「明确的流程规则和触发条件」：
它就会更像一个靠谱的工程同事，不仅能修当前的 bug，还能主动做回归、自检和总结。
所以，当你下次在项目里写测试用例或者协作说明时，可以尝试：
- 少一点「模糊的期望」（比如“修完要过一遍 case”）；
- 多一点「具体的流程和约束」（比如“修改任一用例相关代码后，必须从 1.1 重新检查所有用例”）。
你会发现，同样一句话，对人类和对 AI 的说法，其实应该是不一样的。
把这层差异考虑进去，AI 才能真正成为你开发流程中可靠的一环，而不是一个时不时“漏检”的助手。
