复现步骤
Reproduction Steps也常被叫作：复现路径怎么重现重现步骤
「我说这里有问题，他说他那边是好的，然后就没结果了。」
复现步骤 Reproduction Steps
一串谁照着做都会看到同一个结果的操作，是「有问题」和「已修好」的共同裁判。
复现步骤是排查问题的地基。没有它，你和 AI 会各说各话：你说「点了没反应」，它说「代码逻辑是对的」——两句都不假，因为你们在说不同的场景。
一份能用的复现步骤要有四段：从哪开始、做了什么、看到了什么、本来该看到什么。 少了第四段，最常见的后果是它「修」出一个你没要的行为，然后说已修复。
它还有一个被低估的用途：验收修复。 修 bug 类任务的唯一有效验收，就是照着原来那串步骤再走一遍，确认问题不再出现。凡是没有复现步骤的「已修复」，都只是「改了一些看起来相关的代码」。
最难的是偶发问题。这时别放弃精确性，改为记录边界条件：什么网络、什么账号、第几次操作、多长时间之后。偶发不等于随机，它通常有条件，只是你还没找到。
长什么样 真实可交互，不是截图
「有时候会报错」
「页面卡住了」
2. 进设置页，昵称改成空
3. 点保存
看到：白屏，控制台红字 xxx
预期：提示「昵称不能为空」
右边这份任何人照着做都会得到同一个结果——这就是它能当裁判的原因。
拆开看，里面有这几块
-
1
起点 Given
从哪个页面、什么账号、什么数据状态开始。
-
2
操作 Steps
编号的动作，具体到点哪个按钮、填什么内容。
-
3
实际结果 Actual
你真的看到了什么，包括报错原文和截图。
-
4
预期结果 Expected
本来该发生什么。缺这一段，修复方向会跑偏。
-
5
环境 Environment
浏览器、手机还是电脑、线上还是本地。同一个操作在不同环境结果常常不同。
容易搞混？这样区分
什么时候用得上
四段一起给：起点、操作、看到什么、预期什么。比写一百字描述有用。
照原步骤再走一遍。这是唯一有效的验收方式。
记边界条件：第几次、多久之后、什么网络、什么账号。偶发通常有条件。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
这个问题的复现步骤如下，请先按这个步骤理解问题，不要直接改代码： 【环境】[浏览器/手机、线上还是本地、什么账号] 【步骤】 1. [从哪开始] 2. [做了什么] 3. [做了什么] 【实际看到】[原样描述，报错原文贴全，不要概括] 【预期应该】[本来该发生什么] 请先回答两个问题，我确认之后你再动手： 1. 按这个步骤，问题发生在哪一步、哪个环节？ 2. 你判断的原因是什么，依据是什么？ 改完之后，请照着上面同一串步骤再走一遍，告诉我第 3 步现在实际看到什么。
「先回答再动手」这一步能挡掉最常见的浪费：AI 直接改一处看起来相关的代码，问题没解决，但你已经很难判断它到底动了什么。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「主路径」这层：真实用户的正常操作能走通，不靠特殊参数。
要亲眼看到这些，才算数
- 让另一个人（或另一台设备）照着你的步骤走一遍，得到同样结果。做不到，说明步骤还不够具体。
- 修复后照原来那串步骤再走一遍，确认问题不再出现——不是走一个类似的流程。
- 确认预期结果写了，且修完之后的行为就是那个预期，而不是另一种「也说得通」的行为。
- 顺手确认相邻功能没被改坏（把正常的那条路径也走一遍）。
它常这么糊弄你
- 「已修复」——但从没复现过原问题。没复现过就不可能确认修好了。
- 「我这边测试是正常的」——环境不同。要问清他走的是哪一串步骤、在哪个环境。
- 改完之后换了一套新步骤来演示成功，绕开了原来那条会出错的路径。
- 把报错原文概括成「有个报错」。报错原文里往往直接写着答案。
复现步骤能验到「主路径」层：你亲手按真实用户的操作走通了。
考考你 选一个你觉得对的
AI 说「已修复保存失败的问题」。最有效的验收方式是？
修复类任务的验收对象是原问题，所以必须走原路径。B 需要你懂代码且仍看不出运行时行为；C 是让被验证方自证；D 换了场景，很可能绕开了真正出错的那条分支——这也是最常见的假修复。