# 保存按钮失效：从现象到根因的四步排错

- 定位：技术排错实操
- 面向人群：没有技术基础、希望把 AI 用到真实工作的人
- 课程说明：用一个任务板保存失败的真实案例，演示复现、取证、缩小范围、修复与回归验证。
- 章节数：12

## 01｜点击保存，按钮变灰，任务却没有出现

**屏幕提示：** 开场 · 网站“坏了”

**旁白：** 你在今日任务板输入买牛奶，点击保存，按钮短暂变灰，但列表里没有新增任务。第一反应可能是网站坏了，或者让 AI 把代码重写一遍。先停一下。调试不是猜答案，而是把一个大问题缩小成可以验证的小问题。

## 02｜复现、取证、缩小范围、验证修复

**屏幕提示：** 四步闭环

**旁白：** 我们使用四步闭环。第一，稳定复现，写清环境和步骤。第二，收集原始证据，不只看页面表面。第三，缩小范围，一次验证一个假设。第四，验证修复，既重走原来的失败路径，也检查相邻功能有没有被破坏。

## 03｜把“不能用”改写成操作记录

**屏幕提示：** 第一步 · 稳定复现

**旁白：** 先把现象写成操作记录。环境是 Windows 的 Chrome，本地任务板。步骤是输入买牛奶，点击保存。预期结果是列表新增任务。实际结果是按钮变灰后恢复，列表没有变化。重复三次，结果一致。现在我们有了可以验证的问题。

## 04｜页面没变化，不代表请求没有发生

**屏幕提示：** 第二步 · 看网络请求

**旁白：** 打开浏览器开发者工具的网络面板，再点一次保存。我们看到一个 POST 请求发往 api tasks，状态码是四百。点开响应，服务器明确返回 name is required，也就是缺少 name 字段。页面只是结果，网络响应已经把范围缩小到请求数据。

## 05｜前端发送 title，后端要求 name

**屏幕提示：** 继续取证

**旁白：** 继续看请求负载，前端发送的是 title，值是买牛奶。再看后端校验，它要求 body 里必须有 name。到这里，我们不需要阅读整个系统，已经得到一条完整证据链：按钮触发了请求，请求到达服务器，服务器因为字段名不一致而拒绝。

## 06｜根因假设：前后端字段约定不一致

**屏幕提示：** 第三步 · 验证一个假设

**旁白：** 根因假设是：前端和后端对字段名的约定不一致。最小验证方法是只把请求字段从 title 改成 name，其他代码不动。预期证据也提前写清楚：POST 请求应该返回二零一，列表应该出现买牛奶。一次只改一个变量，才能知道哪项修改真正起作用。

## 07｜只改一行，不顺手重构

**屏幕提示：** 最小修复

**旁白：** 修改差异只有一行：发送的字段从 title 变成 name。没有重写表单，没有更换框架，也没有顺手整理无关代码。小改动更容易验证、更容易回滚，也更容易让别人理解为什么这次修复有效。

## 08｜同样的操作，现在返回 201

**屏幕提示：** 第四步 · 重走失败路径

**旁白：** 保存代码后，重新执行原来的步骤。输入买牛奶，点击保存。网络请求现在返回二零一，响应里有新任务的编号和名称，页面列表也出现了买牛奶。原来的失败路径已经通过，但验证还没有结束。

## 09｜正常一次，不代表修复完成

**屏幕提示：** 回归检查

**旁白：** 还要检查相邻功能。空输入是否仍然被拦截，连续点击会不会重复提交，刷新以后任务是否还在，删除功能有没有被破坏，服务器再次报错时页面是否显示清楚提示。修复一个问题，不能以制造另一个问题为代价。

## 10｜把证据交给 AI，不要只说“网站坏了”

**屏幕提示：** 让 AI 帮你排错

**旁白：** 向 AI 求助时，把环境、复现步骤、预期和实际结果、状态码、响应内容、请求负载和相关代码一起提供。再要求它先判断问题位于哪一层，给出最小验证步骤，不要一次修改多个文件。你提供的证据越准确，AI 越不需要猜。

## 11｜把这次排错变成下次可复用的方法

**屏幕提示：** 沉淀调试记录

**旁白：** 最后留下调试记录：现象是什么，最短复现路径是什么，收集了哪些原始证据，根因如何被验证，修改了什么，回归检查是否通过。这样下次遇到类似问题，你不需要从头猜，也可以把清楚的证据交给同事或 AI。

## 12｜找一个真实报错，完成四步闭环

**屏幕提示：** 跟做练习 · 20 分钟

**旁白：** 现在找一个真实报错，完成四步闭环。写出环境、步骤、预期和实际结果；复制完整错误、状态码和响应；提出一个最小根因假设；一次只改一个变量；最后重走原路径并做回归检查。调试能力的核心，不是记住更多错误，而是让每一个判断都有证据。