开发时顺手准备好排障上下文

趁上下文还在手边，留下排障入口

开发时，你已经知道哪个请求能触发某条路由、它使用哪个数据库。如果这些信息只留在临时终端命令或未保存的连接表单里，出故障时可能还得重新整理。平时顺手保存，就能给下一次排查留下起点。

Unfour 将 API 请求、服务器访问和数据库连接放在一起，用于后端排障。提前保存的价值很具体：请求失败时，可以直接检查运行行为，而不必先找回之前用过的 URL、数据库或主机。

这些时机可能相隔几天，也可能相隔几周。从今天用得上的请求或连接开始，等后端发展到相应阶段再补充其他入口。

保存用来调用它的请求，以及值得反复检查的输入。例如，开发创建订单的路由时，留下你反复发送的创建订单请求。其他常用 endpoint 可用后再逐步添加，不必先整理完整 API 目录。

保存这个后端实际使用的数据库连接。检查请求是否写入预期记录时，就能回到同一个数据库。只有 API 和数据库上下文的本地后端，也已经有了实用的排障入口。

有了实际需要检查的主机，再保存 SSH 连接。以后故障需要服务器证据时，可以从这里查看应用日志。尚未部署时，不需要提前准备 SSH 连接。

复用时顺手维护这些上下文：请求输入变了就更新请求，服务迁移了就更新连接。目标是留下几个自己熟悉、确实可用的入口，而不是完成一次配置任务。

假设创建订单的请求后来返回错误。打开已保存的请求，确认 API、服务器和数据库都属于本次排查的目标。保存的连接提供入口，当前的请求、日志和数据提供证据。

重放触发故障的输入，查看相关应用日志，再查询涉及的数据记录。修改代码后，重放原始请求并检查结果状态。哪些证据有关联、修复是否有效，仍然需要你判断；已有上下文省去的是排查开始前重新拼凑入口的工作。

作为可选扩展，Codex 或 Cursor 可以通过 MCP，在你允许的访问范围内复用同一套运行时上下文。