按钮点了没反应，怎样从证据开始排查？

网页上的“保存”按钮点了没有反应，原因可能在页面脚本、网络请求、账号权限，也可能涉及其他环节。第一次看到这个现象，先说“系统被攻击了”，或者直接断定“浏览器坏了”，都超出了目前掌握的信息。

一个实用的起点是：先写清观察到什么，再列出几种能够检验的解释。随后从不会破坏现场、成本较低的检查开始；如果结果不支持原来的判断，就继续调整方向。

解释少一些，不等于忽略证据

奥卡姆剃刀（Occam’s Razor）常被概括为“不要无必要地增加假设”。放到排查中，它的前提是：几个解释都能与现有证据相容，而且解释能力相近。这时，可以先考虑额外假设较少的解释。

它不是一条“简单答案一定正确”的规则。假如日志已经显示异常登录或未经授权的请求，就不能因为“刷新页面更简单”而忽视这些迹象。必要的安全处置和证据保留，应该按实际情况执行。

以下是假设的测试环境：页面能够打开，但点击保存后没有看到成功提示。现在还不知道数据是否保存，也不知道问题发生在哪一层。可以先把候选解释和检查方式写下来：

这些都只是待验证的可能性。网络记录没有出现请求，可以让你继续检查页面交互，但不自动证明是哪一行脚本出错；收到失败响应也要看实际返回和服务日志，不能仅凭状态码猜出全部原因。

特别要注意，“没有成功提示”不等于“没有保存”。在再次点击或重新提交前，先查看记录列表或详情，确认数据是否已经写入。结果不明时连续点击，可能把一次排查变成重复提交。

优先检查网址、网络连接、页面提示和服务状态，通常容易开始，也不需要先改动业务数据。但“先查”只是一种顺序，不是给某个原因判定更高真实性。若低成本检查没有解释现象，就根据新证据继续查看权限、服务日志或其他必要环节。

记录结果时，可以写“当前账号访问正常；点击后有请求；服务器返回错误；保存状态待确认”。这比“应该是网络问题”更方便下一位接手的人判断。日志中若有账号、令牌或客户资料，分享之前应遮盖不必要的信息。

把已观察到的事实和可以使用的检查条件告诉 AI，请它列出多种解释与低风险的验证方法。下面的提示可以按实际情况修改：

这是测试环境中已经观察到的现象：[填写事实和时间]。请列出可能解释、每个解释需要满足的前提，以及不修改数据的检查方法。区分已证实、推测和未知；不要假定保存失败，不要执行删除、重试提交或修改配置。如果出现异常安全迹象，请指出需要进一步核查的证据。

AI 给出的检查步骤也需要按当前环境核对。完成一项检查，就把实际结果补进去，再决定下一步；如果新证据与原假设冲突，保留记录并改变方向。