浏览 AI 知识库
报错时该给 AI 哪些材料，才能得到可验证的修复
只给 AI 一张截断报错图，它只能猜。补齐复现命令、完整堆栈、输入、版本和最近改动，才能把修复从建议变成可验证结论。
沿完整工作流推进
前一阶段的可检查结果，是下一阶段的输入；中间证据不足时停在当前阶段。
同一句 undefined 报错，缺少现场信息就可能有五种答案
报错提问只有一张截断截图：“Cannot read properties of undefined”。AI 给了五种猜测，没人知道运行命令、输入、版本和最近改动。
- 另一环境可以复现
- 完整错误和最近 diff 可用
- 修复用原复现步骤验证
先确认这次任务的起点、边界和交付
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 真实命令 `npm test -- order`；Node 22；完整堆栈指向 `order.test.ts:84`；最近改动为把空数组改成可选字段。 |
| 不能越过的边界 | 复现包只放解决问题所需内容，秘密脱敏；保留完整错误文本和最小复现；预期与实际分开。 |
| 要交付的结果 | 复现包：命令、版本、完整错误和最近改动 |
从“记录最小复现”走到“修复后跑三类验证”
| 当前阶段 | 实际处理 |
|---|---|
| 记录最小复现 | 从干净起点写命令或点击步骤、输入、实际结果和期望结果，确认是否每次发生。 |
| 保存完整错误 | 不要只截最后一行；保留时间、退出码、堆栈、请求 ID、相关日志和首次异常。 |
| 补环境与变化 | 写系统、运行时、依赖、分支、配置来源和最后一次可用版本，列最近实际 diff。 |
| 形成单一根因假设 | 说明证据为何指向某层，以及怎样用最小实验证伪；不要同时改依赖、配置和代码。 |
| 修复后跑三类验证 | 重跑原复现、目标测试和相邻回归，记录前后输出与回滚方式。 |
把‘偶发 500’记录成一次可比较的请求
| 字段 | 示例 | 用途 |
|---|---|---|
| 环境 | Node 22、commit 8f31、staging | 排除版本和环境漂移 |
| 步骤 | POST /reports，body 含 report_id=R-17，连续 20 次 | 确定触发频率和输入 |
| 原始证据 | 时间、请求 ID、完整堆栈和首次异常 | 区分根因层，不只看最后一行 |
| 假设 | 缓存键缺少 tenant_id | 用单一最小实验验证 |
| 修复验证 | 原复现、单元测试、相邻租户回归 | 证明修复未扩大影响 |
请求、ID 和版本为演示数据；真实日志需脱敏并遵守访问权限。
把完整报错现场交给 AI，而不是只发一句‘运行失败’
适合已经能够稳定复现、并保留完整错误和环境信息时。
可复制使用
把完整报错现场交给 AI，而不是只发一句‘运行失败’
我们有一个可复现故障。请做分步诊断，不要一上来列十种猜测、重装依赖或清空缓存。 期望行为/实际行为【】；精确复现步骤【】；完整错误和前后日志【】；系统、版本、运行目录【】；最近一次正常状态【】；已尝试操作【】。 先把事实和未知分开，给最多三个能被证伪的原因，每个原因对应一项低风险检查。每轮只给一个最小命令或操作，并说明预期观察；等我贴结果后再更新判断。修复前不得改变环境；任何命令可能删除文件、改配置、联网或影响共享服务时先停下来说明。
使用范围：适合已经能够稳定复现、并保留完整错误和环境信息时。不要根据错误关键词直接下结论，不虚构命令输出，不先重装或删除环境。
完成后的复现包：命令、版本、完整错误和最近改动
复现包包含命令、版本、最小输入、完整堆栈、期望结果、当前结果、最近 diff 和已尝试项。另一台干净环境能稳定复现，根因锁定缺少默认数组；修复后原用例与空字段回归用例均通过。
为什么“材料很全，AI 仍给出多个不相关修复”还不能交付
材料很全，AI 仍给出多个不相关修复
- 原因
- 没有说明哪个假设已被排除
- 怎么改
- 把每次实验、唯一改动和结果写入时间线，要求下一建议能被单独证伪