Vibe Coding 调试假设日志：让每次排查都能证伪

调试对话很容易形成一种假进展：AI 先说可能是缓存，清缓存无效后改口说可能是竞态，增加等待仍失败，又回到配置问题。每次回答都通顺，却没有一份记录说明哪些解释已经被事实否定。最终代码里留下日志、重试、超时和无关改动，团队仍说不清根因。

假设日志把调试从连续聊天改成一系列可证伪实验。Google SRE 的有效故障排查章节将诊断描述为从系统模型产生假设、再用测试排除原因；关键不是一次猜中，而是每个测试都缩小可能空间。AI 适合帮助生成候选解释和探针，人负责确定优先级、风险与证据标准。

严格分开观察与解释

日志第一栏只写直接观察：“请求在 2 秒客户端超时后结束”“数据库查询仍在 2.4 秒完成”“相同幂等键出现两条记录”。“数据库太慢导致重试”包含因果解释，属于假设。原始观察附查询、时间窗、代码版本、trace ID 或工件位置；不要只保留 AI 的摘要。

第二栏写一个可被推翻的假设。第三栏必须给出预测：如果假设为真，在不改变其他条件时，应看到什么；若为假，又会看到什么。没有差异化预测的句子，例如“可能是网络问题”，还不能进入实验。

H3 假设：客户端超时后重试，而第一次请求仍在提交。
预测：同一业务键的两条请求 trace 时间重叠，且第一条在断连后完成写入。
探针：关联 idempotencyKey，记录服务端开始、commit、cancel 三个事件。
结果：两条 trace 重叠 410ms；第一条在 cancel 后 commit。
状态：supported；下一步验证服务端幂等保护是否缺失。

这段结果支持一个机制，但还不等于最终根因。也许真正缺陷是代理重试策略，也许是服务端没有传播取消。日志用 proposed、testing、rejected、supported、confirmed 区分阶段，只有修复反事实验证完成后才用 confirmed。

一次实验只改变一个诊断变量

为了快，AI 常建议同时关闭缓存、延长超时、串行执行并升级客户端。故障消失后，四个解释都无法确认。每轮选择一个能最大化区分度且风险最低的探针：读已有指标优先于加代码，临时只读日志优先于改变生产行为，隔离环境故障注入优先于在线试错。

所有诊断改动单独成 diff，记录开始前 HEAD 与工作树状态。探针应尽量不改变时序；高频同步日志可能让竞态消失，全面 trace 也可能增加负载。若观测本身有影响，把采样、开销和可能偏差记入日志。Vibe Coding 调试观测设计可用于选择结构化日志与 trace。

实验结果无论支持或反对都保留。rejected 项记录反证和适用条件，例如“在固定响应重放下关闭缓存仍 20/20 失败，因此缓存不是该复现的必要条件”。负面证据能阻止下一个 Agent 重走旧路。W3C PROV 的实体、活动与派生关系提供了可借鉴的思路：结论要能回到输入和产生它的操作，不需要为此部署复杂系统。

给假设排优先级和预算

优先级综合先验可能性、能否解释全部观察、验证成本和变更风险。先检查最近改动、明确错误和共享依赖，但不要把“最近提交”直接当根因。一个假设若只能解释错误率上升，不能解释特定状态残留，应降级或拆分。

为自动调试设置预算，例如同时最多保留五个活跃假设，每个假设最多两次改进探针，连续两轮没有新增证据就暂停写代码。数字是团队策略，不是普遍标准；重点是预先规定停止条件。预算耗尽时输出已知事实、已否定项、剩余假设和下一项需要的人或环境权限，而不是继续随机修补。

Vibe Coding 最小复现应作为日志的固定实验入口。复现条件中途变化时创建新 revision，并注明旧结论是否仍适用。否则某次“修复成功”可能只是 fixture、并发度或依赖版本已经不同。

从支持走到根因确认

确认根因至少需要三步：候选机制能解释全部关键观察；控制该机制会让故障消失；以相反方向重新引入条件会让故障恢复，或有同等强度的历史版本对照。最后再证明候选补丁在不改变复现其他条件时阻断该机制。

日志的最终条目链接原始复现、补丁 diff、修复前后结果、回归测试和剩余风险。Vibe Coding 修复验证与根因闭环负责关闭后半段，编程 Agent 的改动验证门确保测试证据没有被后续编辑污染。

一份好假设日志不追求显得聪明，而追求让任何接手者知道：哪些是事实，哪些只是解释，什么实验区分了它们，哪些路径已经失败。Vibe Coding 提高了生成假设与补丁的速度，日志则保证这份速度不会把团队带进更快的无效循环。

延伸阅读

• Vibe Coding 最小复现
• Vibe Coding 调试观测设计
• AI 辅助调试
• Vibe Coding 修复验证与根因闭环
• 编程 Agent 的改动验证门