调试铁律：先 Log 再改码
禁止猜测性修复，修复前回答三个问题，改完声明影响范围
本页解决的问题
先给结论「调试铁律：先 Log 再改码」要解决的关键问题是什么？
禁止猜测性修复，修复前回答三个问题，改完声明影响范围
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
禁止猜测性修复。无法确认根因时，必须先通过 Log、断点或测试脚本验证假设，禁止「试着改一下看看」。后端在终端打详细日志，前端在浏览器 Console 打日志，无论什么问题，第一步都是加 Log。
点击一条路径，观察修复过程。右侧计数器记录轮数和累计改动行数。
猜测性修复 · 战绩
先 Log 再改 · 战绩
规则要求修 Bug 前必须回答三个问题。依次点开三问，全部看完才解锁「开始修复」按钮。
前置调研完成，允许动手。修复完成后还有最后一步：声明影响范围，让人知道该回归测试哪些地方。
禁止 Mock 绕过真实 AI 接口
凡涉及 AI 模型调用的功能，交付前必须确认接口真的能访问。用户没给 API Key 时必须停下来要，禁止硬编码假响应或本地模拟绕过真实调用。Key 到位后先发一次测试请求验证可用性，再继续开发。
单元测试不过，不得交付
核心业务逻辑、API 接口、数据处理函数、边界条件都要覆盖。测试文件统一放 tests/，命名 test_{模块名}.py，Python 项目用 pytest。调试用的临时脚本，用完自行删除。
证据先行。加 Log 的 2 分钟，买断的是猜错三轮的返工和被掩盖的根因。修复后用 ⚡ 影响范围：XXX、YYY、ZZZ 的格式声明影响面，交付前过真实接口和单元测试两道线。
从「核心条款」把感觉变成判断
「禁止猜测性修复。」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「规则要求修 Bug 前必须回答三个问题。依次点开三问，全部看完才解锁「开始修复」按钮」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「证据先行。」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「核心条款」走到「交互演示一 · 同一个 Bug，两条修法」
「核心条款」先把问题落在「禁止猜测性修复。 无法确认根因时，必须先通过 Log、断点或测试脚本验证假设，禁止「试着改一下看看」。后端在终端打详细日志，前端在浏览器 Console 打日志，无论什么问题，第一步都是加 Log」上；到了「交互演示一 · 同一个 Bug，两条修法」，讨论继续推进到「点击一条路径，观察修复过程。右侧计数器记录轮数和累计改动行数」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「核心条款」：禁止猜测性修复。 无法确认根因时，必须先通过 Log、断点或测试脚本验证假设，禁止「试着改一下看看」。后端在终端打详细日志，前端在浏览器 Console 打日志，无论什么问题，第一步都是加 Log
- 「交互演示一 · 同一个 Bug，两条修法」：点击一条路径，观察修复过程。右侧计数器记录轮数和累计改动行数
- 「最后的要点」：证据先行。 加 Log 的 2 分钟，买断的是猜错三轮的返工和被掩盖的根因。修复后用 ⚡ 影响范围：XXX、YYY、ZZZ 的格式声明影响面，交付前过真实接口和单元测试两道线
最后的「最后的要点」把讨论落到「证据先行。 加 Log 的 2 分钟，买断的是猜错三轮的返工和被掩盖的根因。修复后用 ⚡ 影响范围：XXX、YYY、ZZZ 的格式声明影响面，交付前过真实接口和单元测试两道线」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。