要用 AI 将 Bug 报告转成复现步骤，先给模型一个经过脱敏的证据包，让它把报告中的事实与假设分开，并要求输出一份带编号的操作流程，包含环境、前置条件、最少数据、预期结果、实际结果、观察点和明确的未知项。然后由人在受控环境中执行这些步骤。AI 可以整理出一份候选复现方案，但它不能如实地说“这个 Bug 已经复现”。

这是一个范围很窄的文档流程。更宽泛的安全使用 AI 指南介绍了输入边界和人工批准。一旦有人能够复现故障，就可以用另一套 AI 调试流程调查原因和修复方法。不要把这两个阶段合并：看似合理的原因不是复现步骤，精致的流程也不能证明有人实际运行过它。

关键要点：

在改写之前，先保留报告者提供的证据。

把每条陈述标为报告、观察、推断或未知。

明确写出环境、状态、数据和时间安排。

优先使用最小测试用例，而不是冗长的叙述。

在同一个观察点记录预期结果和实际结果。

由人执行、修订并批准最终的复现包。

Bug 报告证据包该如何冻结和脱敏？

一份有用的 Bug 报告可能包含标题、文字描述、表单字段、评论、日志、截图、视频或测试失败信息。收集这些材料，但不要悄悄改写它们。GitHub 把 issue 视为记录工作的地方，并支持结构化的 issue 表单；表单字段可以要求填写复现步骤、预期行为和日志等细节。［1］［2］结构化能改善信息收集，但并不能证明每个字段都准确。

在使用 AI 工具之前，删除或替换密钥、访问令牌、会话 cookie、私钥、个人信息、客户标识、私有源代码、内部主机名和保密日志。遵守所在组织批准的数据处理政策。如果某项材料不能分享给所选工具，就只在本地概括必要的事实，或使用获批的私有环境。保留对原始材料的引用，方便审核者比对转换前后的内容。

建立一份小型收件登记表：

字段	记录内容
报告 ID	稳定的 issue 或工单编号
报告者陈述	确切的主张或简短的引文片段
证据	获批的日志、图片、视频时间点或测试输出
来源时间	事件发生和证据生成的时间
环境	产品、版本、平台、浏览器或运行时
可信类型	报告、直接观察、推断或未知
敏感信息	已删除、已替换、受限或不存在

不要仅仅因为可以获取，就粘贴整个代码库或生产日志。复现通常只需要一小组有区分力的事实，而不是尽可能大的上下文窗口。

怎样把事实、推断和未知分开？

要求 AI 把陈述提取到四列中：报告的事实、直接证据、候选推断和未知。这可以防止语法上的润色把不确定变成确定。例如，“我点击保存后页面卡住了”是报告者的陈述；显示点击动作和卡住状态的视频是直接证据；“是数据库锁导致的”则是一个假设，除非有另外的证据证实。

使用如下提示词：

你只负责整理 Bug 报告，而不是诊断它。

把每条陈述分类为：
1. 用户报告的内容；
2. 附件直接支持的内容；
3. 不得作为事实陈述的推断；或
4. 未知或相互矛盾的内容。

不要编造动作、数值、版本、时间、账户状态、网络条件、原因或复现成功。
每条事实都引用证据 ID。对每个缺失的必填字段，返回相应的问题。

对照原始材料审核提取结果。删除无法追溯到某项材料或陈述的事实。相互矛盾之处——例如两个不同的应用版本——应放进未知项清单，而不是被综合成一个折中值。

明确环境和起始状态

当隐藏的状态不同时，复现就会失败。记录可能改变结果的最小环境描述：

构建、发布、提交或接口版本；
相关时的操作系统、浏览器、运行时或设备类别；
账户角色、功能开关、语言区域、时区和权限；
仅在有证据时记录网络模式或外部依赖的状态；
数据夹具、缓存状态、之前的工作流状态和安装历史；
测试是从全新会话、已知快照，还是现有状态开始。

不要把“最新版本”变成一个版本号，而要请报告者提供实际值。不要从截图边框推断浏览器，从用户名推断账户角色，或从超时推断网络问题。如果某个字段无法获得，就写 unknown，并说明测试者如何获取它。

把前置条件写成可以在第 1 步之前检查的断言。“存在一个名为“示例”的项目，且测试者拥有编辑者权限”比“打开你的项目”更好。当状态的重建成本很高时，引用一个脱敏的夹具或准备流程，而不是嵌入保密数据。

如何用 AI 将 Bug 报告转成复现步骤的原子动作？

每个复现步骤都应描述一个用户或系统动作，并在有用时附上一个观察。避免“正常配置”“再试一次”或“使用该功能”这类含糊的动词。写出证据中的控件、命令、字段、数值或事件的名称。保持报告中的顺序；改变顺序可能让 Bug 消失。

一个好的步骤序列如下：

核实所述的起始状态；
执行一个精确的动作；
当某个中间观察能区分不同分支时，记录下来；
执行下一个动作；
在一个具名的观察点比较预期结果和实际结果；
收集再次运行所需的获批证据。

只有在有依据时，时间和重复次数才写进步骤。如果报告者说问题“有时”出现，不要把它写成“每三次出现一次”。而应定义一个有边界的运行计划，例如尝试十次，并在测试者运行之前把观察到的频率留空。

期望与实际结果应以什么为依据？

预期行为应来自已批准的需求、规格、测试、帮助页面或产品负责人，而不是模型觉得直观的内容。实际行为应描述证据所显示的内容，而不归因。

两者使用同一个观察点：

观察点	预期	实际	证据
选择保存后	出现确认信息，状态变为已保存	在录制的视频片段中，加载图标一直显示	视频 E2，00:18–00:31

如果预期行为没有权威来源，就标为“报告者的预期”并请求确认。如果实际结果有变化，就记录每一种观察到的变体，而不是只挑最严重的一种。

怎样的测试用例才算最小？

MDN 建议在报告浏览器问题时提供一个最小的独立测试用例，因为删除无关代码能让缺陷更容易被隔离和分享。［3］最小并不意味着人为造作，而是指剩下的每一项输入都是触发所观察结果的必要条件。

用 AI 提出一个缩减队列，而不是宣布缩减已经成功：

用合成夹具替换生产记录；
一次删除一个无关的字段、插件、扩展或请求；
在保持顺序的前提下缩短动作序列；
隔离一个账户角色、语言区域或配置；
把长脚本转换成最小的获批片段；
保留一个预期不会出现故障的对照用例。

每一次缩减都必须由人运行。把它标为 retained、removed 或 not tested，并保存观察到的结果。绝不要发布包含有效凭据、私有端点、真实客户记录或应受限制的漏洞利用细节的最小用例。

增加观察点和运行矩阵

当一个流程指出要观察什么、而不预设原因时，之后的调试会更容易。有用的观察点包括可见的状态变化、状态码、安全的日志事件、队列计数、数据库夹具状态或测试断言。只纳入测试者获授权访问的信号。

当证据表明存在环境边界时，建立一个小型矩阵：

变量	对照	候选变体	结果
版本	上一个获批构建	报告中的构建	未运行
角色	查看者	编辑者	未运行
数据	空的合成记录	最小填充记录	未运行

AI 可以建议有区分力的比较，但初始结果必须保持“未运行”。避免建立包含所有浏览器、地区、账户和设备的失控矩阵。从证据支持的变量开始，只有在结果证明有必要时才扩展。

未知项与复现置信度怎么记录？

Mozilla 的 Bug 撰写指南强调清晰的步骤、实际结果和预期结果。［4］在 AI 参与时，再增加两个特别有用的字段：未知项登记表和置信度标签。

使用描述证据、而非模型确定程度的置信度定义：

**草稿：**根据一份报告整理；没有独立运行。
**候选：**字段完整到足以进行受控运行。
**已观察一次：**一名获授权的测试者复现了所述结果一次。
**可重复：**在有记录的环境中，结果达到了预先定义的运行门槛。
**未复现：**计划中的运行已完成，但没有出现报告的结果。
**受阻：**缺少必需的环境、数据、权限或材料。

不要让 AI 给出“已观察一次”或“可重复”的状态。这些状态需要有记录的人工或自动化执行证据。语言模型再高的置信度分数也无关紧要。

可复制的复现包模板

# 复现包

- 报告 ID：
- 范围：
- 环境与精确版本：
- 起始状态：
- 获批的合成夹具：
- 前置条件：
- 已知的未知项或冲突：

## 步骤
1. [动作]
   - 观察：
2. [动作]
   - 观察：

## 结果
- 观察点：
- 预期结果及依据：
- 报告的实际结果及证据：
- 复现状态：草稿
- 运行次数 / 门槛：

## 证据
- 证据 ID、时间戳和脱敏后的位置：

## 交接
- 测试者：
- 环境负责人：
- 下一项决定：
- 人工批准：

要求模型只填写证据登记表所支持的字段。要求输出保留空字段，并按证据 ID 列出引用。然后把每个已填写的字段与来源对照。

运行并批准 Bug 复现包

在安全、获授权的环境中执行候选方案。记录确切的版本、时间戳、夹具标识、步骤偏差和获批的观察。如果测试者不得不临场发挥，就更新流程，并从定义好的起始状态重新运行。不要在一次成功运行之后悄悄修改步骤；那会破坏审计线索。

当一位具名审核者确认该复现包要么在定义的门槛下可重复，要么在定义的测试下未复现，要么因为某个具体原因受阻时，它就退出了这个流程。根因假设、补丁和回归测试属于下一个流程。需要检查生成的主张时，使用 AI 事实核查方法；范围稳定之后设计测试，请使用 AI 生成测试指南。

常见问题

AI 能直接替我复现 Bug 吗？

它可以整理证据并起草流程。只有在连接到获授权的环境和工具链时，它才能执行测试；即便如此，确立结果的也是有记录的运行，而不是文字。

原报告信息不完整怎么办？

把缺失的字段保留为未知项，并生成有针对性的问题。不要为了让模板看起来完整而编造版本、动作、账户状态或预期结果。

是否应加入截图或视频？

在获批且有用时使用，但要加上时间戳和文字说明。删除个人或保密信息，也不要把视觉背景当作隐藏状态的证据。

要运行多少次才算可重复？

在测试之前，根据影响、成本和预期的间歇程度定义一个门槛。记录所有尝试和环境；没有通用的数字。

复现和诊断有什么区别？

复现是在已知条件下确立一个可重复的观察结果。诊断是评估关于它为何发生的假设。把这两类主张和批准分开。

AI 能制作最小用例吗？

它可以建议缩减方式和合成夹具。每一次缩减都必须由人或获授权的测试系统运行，并确认故障仍然存在。

如何处理敏感日志？

使用获批的存储和工具，尽量缩短摘录，删去密钥和个人数据，并在政策允许时保留对原始日志的受限引用。

何时可以转入调试？

当复现结果、环境、证据和未知项都足够明确，让调查者无需改写历史就能评估假设时，就可以转入调试。

来源

Sources checked 2026 年 8 月 29 日。

GitHub Docs, “Quickstart for GitHub Issues” — https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/quickstart
GitHub Docs, “Syntax for GitHub's form schema” — https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
MDN Web Docs, “How to file a bug” — https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs
Mozilla Bugzilla, “Bug Writing Guidelines” — https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html

如何用 AI 将 Bug 报告转成复现步骤，不猜根因也不虚构结果