Vibe Coding 方法论 · 第 5 节
调试铁律：先 Log 再改码
AI 遇到报错的第一反应是猜一个原因改改看，不行再猜一个。这一节立最核心的一条规矩：禁止猜测性修复。下面两个演示，亲手对比两条修 Bug 路径。
核心条款
禁止猜测性修复。无法确认根因时，必须先通过 Log、断点或测试脚本验证假设，禁止「试着改一下看看」。后端在终端打详细日志，前端在浏览器 Console 打日志，无论什么问题，第一步都是加 Log。
交互演示一 · 同一个 Bug，两条修法
Bug 现场：聊天输入框在中文输入法下，用户按回车确认候选词时，半截拼音被当成消息直接发了出去。
点击一条路径，观察修复过程。右侧计数器记录轮数和累计改动行数。
0
修复轮数
0
累计改动行数
待演示
Bug 状态
猜测性修复 · 战绩
尚未演示
先 Log 再改 · 战绩
尚未演示
交互演示二 · 修复前三问自查器
新 Bug 到达：用户删除一条聊天记录后，会话列表上的未读数没有更新。
规则要求修 Bug 前必须回答三个问题。依次点开三问，全部看完才解锁「开始修复」按钮。
链路是 删除消息 → 更新会话摘要 → 重算未读数 → 推送列表刷新。排查发现「重算未读数」只在收到新消息时触发，删除路径根本没有走到它。只盯着报错点看不到这条链路。
重算时机改动会波及 会话列表、App 角标、多端消息同步 三处。理解上下游依赖再动手，避免按下葫芦起了瓢。规则同时建议：优先启动 SubAgent 并行调研影响范围，确认安全后再修改。
有。「标记已读」和「撤回消息」 走的是同一条更新链路，同样漏了触发重算。同一个坑往往不止一处，这次一起修干净。
前置调研完成，允许动手。修复完成后还有最后一步：声明影响范围，让人知道该回归测试哪些地方。
⚡ 影响范围：会话列表未读数、App 角标、标记已读、撤回消息
交付线 · 两道硬性检查
禁止 Mock 绕过真实 AI 接口
凡涉及 AI 模型调用的功能，交付前必须确认接口真的能访问。用户没给 API Key 时必须停下来要，禁止硬编码假响应或本地模拟绕过真实调用。Key 到位后先发一次测试请求验证可用性，再继续开发。
单元测试不过，不得交付
核心业务逻辑、API 接口、数据处理函数、边界条件都要覆盖。测试文件统一放 tests/，命名 test_{模块名}.py，Python 项目用 pytest。调试用的临时脚本，用完自行删除。
本节要点
证据先行。加 Log 的 2 分钟，买断的是猜错三轮的返工和被掩盖的根因。修复后用 ⚡ 影响范围：XXX、YYY、ZZZ 的格式声明影响面，交付前过真实接口和单元测试两道线。
素材来源：本节内容整理自开源仓库 itshen/xs_vibe_rules 的 rule-opensource.mdc 第八章「调试与日志规范」。