Vibe Coding 最小复现：把模糊故障压缩成可重复实验

“结算页偶尔白屏，帮我修一下”不是一个可执行的调试任务。AI 看见大量代码后会列出路由、缓存、网络、状态管理和浏览器兼容等十几种可能，再顺手修改最像问题的地方。即使页面暂时恢复，也无法知道改动修复了原故障，还是只改变了触发概率。

最小复现的目标不是把示例缩到最短，而是用最少的必要条件稳定产生同一个可识别结果。一份可移交的复现需要删掉无关部分，保留运行所需材料，并确认别人按步骤能看到同一问题；Node.js 项目的官方贡献指南也要求缺陷报告包含可复现代码与尽量详细的信息。对编程 Agent 而言，这个包也是上下文边界，让诊断从阅读猜测变成实验。

先定义“同一个故障”

开始删减前，记录故障指纹：入口动作、首个业务栈帧、错误类型、稳定错误码、最终状态和关键副作用。时间戳、随机请求 ID 与临时端口不是身份；“页面不工作”又太宽。一个可用指纹可以是：“在 POST /checkout 后，reserveInventory 返回成功，但事务以 UniqueConstraint 结束，订单表无记录，预留记录仍存在”。

同时写清期望与实际，不先写根因。原始日志、截图、trace 和响应作为附件，人工描述只是索引。已有调试背景可参考AI 辅助调试，本流程进一步要求每次简化都保持同一指纹。

冻结代码和环境：HEAD、工作树状态、锁文件哈希、运行时版本、操作系统/架构、启动命令、locale、时区、种子、依赖服务版本和脱敏 fixture。若问题只在某浏览器或并发度出现，也把它写成输入。不要上传 .env 或 token；记录变量名、是否设置与秘密版本即可。Vibe Coding 任务上下文包可承载这些事实。

从能复现的完整现场向下删

先在原环境连续触发，确认概率和指纹。若十次只出现一次，就不能把下一次“没出现”当作某个变量无关。提高可控性的方法包括固定数据、关闭无关流量、记录事件顺序、使用虚拟时钟、固定随机种子，以及在隔离环境重放外部响应。

删减采用二分思路，但每次只改变一个维度：去掉无关页面组件、替换一段外部调用、缩小输入、减少数据记录、关闭一个 feature flag。每步保存命令、变更和结果。如果删掉一半后故障仍出现，继续在保留部分缩小；如果消失，把必要条件加回来。不要同时升级依赖、改配置并删代码，否则无法知道哪个变化影响了信号。

一个前端问题可以依次压缩为：完整用户流程、单一路由、最小组件、单个事件处理器、纯函数输入。网络问题则可把远程 API 响应保存为脱敏 fixture，用本地严格 server 重放状态码、header、延迟和响应体。E2E 场景可保留Playwright 端到端测试的 trace，但最终包仍要提供一条从干净环境可执行的命令。

完整比“短”更重要

常见失败是示例只贴报错行，却缺 schema、迁移或调用者；在作者机器上能跑，别人缺少生成文件；为脱敏把关键字段结构删掉；用一个返回成功的 mock 替换真正触发错误的边界。最小复现必须自包含或明确列出不可内嵌依赖及取得方式。

可以建立一份最小目录：README 写前提、运行与期望；fixture 保存脱敏输入；reproduce 脚本只做确定性准备和触发；observed 保存指纹样例。脚本禁止修改生产资源，默认使用临时目录、测试数据库或本地替身。所有生成步骤固定版本，依赖安装遵循项目锁文件。

如果故障依赖真实规模、竞态或硬件，无法压成玩具程序，也不要伪造成功。此时最小单元可以是“最少环境 + 最短触发序列 + 最小观测集”，例如固定两线程事件顺序的测试，或只保留一个特定数据库执行计划。把不可移除条件标成 required，未知条件标成 unknown。

让另一个执行者验收复现包

作者之外的人或隔离 Agent 从干净目录按说明运行，不能使用作者 shell 历史和隐式服务。验收条件包括：一次命令完成准备与触发；实际结果匹配指纹；重复运行不会被上次状态污染；失败时能区分“环境没建好”和“目标 bug 未出现”；包中没有秘密和个人数据。

复现建立后，再进入Vibe Coding 调试假设日志，每个实验只验证一个预测。修复完成时，原复现应先在旧版本稳定失败、在候选版本稳定通过，并转成长期回归测试；验证门见编程 Agent 的改动验证门。

最小复现不是写给 issue 的礼貌附件，而是调试的第一个技术产物。它保留真正触发故障的条件，删除会诱导模型猜测的噪声，并为后面的假设、补丁和回归提供同一把尺。无法复现时，诚实的结论是证据仍不足，而不是让 AI 提交一个“看起来可能有效”的修复。

延伸阅读

• AI 辅助调试
• Vibe Coding 任务上下文包
• Playwright 端到端测试
• Vibe Coding 调试假设日志
• 编程 Agent 的改动验证门