代码开发 · 编辑演练

接口超时排查 Prompt：让 AI 先收集证据，再给修改建议

以 Node.js 接口偶发超时为例，设计不会凭空猜测技术栈和根因的排查流程。

更新于 2026-08-13

任务背景

已知现象是接口偶发超过 10 秒，当前只有应用日志和反向代理日志，尚不能确认是数据库、第三方请求还是连接池问题。

目标不是让 AI 直接生成一段所谓修复代码，而是产出按优先级执行的证据收集步骤，并说明每一步如何判断。

最初的写法

Node 接口超时了，帮我修复并优化性能。

为什么不够用

· 没有代码、日志、版本和运行环境，任何直接结论都可能误导。
· “优化性能”范围过大，容易得到一串不分优先级的通用建议。
· 没有要求回滚与验证，修改可能掩盖真正故障。

两轮修改

第一轮：要求先提问

让模型先列出最多 8 个关键问题，在资料不足时停止给最终结论。

修改理由：调试必须依赖证据，先补上下文比猜测根因更可靠。

第二轮：规定排查输出

每项假设都包含证据、检查命令、判断标准、风险和回滚方式。

修改理由：可验证的步骤才能真正用于生产问题排查。

最终提示词

你是负责生产故障排查的 Node.js 工程师。现象：某 HTTP 接口偶发响应超过 10 秒；目前只有应用日志和反向代理日志，根因未知。
第一步只提出最多 8 个最关键的问题，覆盖运行时版本、部署方式、请求链路、数据库、第三方服务、连接池、超时配置和最近变更。在我补充资料前，不要断言根因，也不要直接重写代码。
收到资料后，按优先级输出排查表：假设、支持或反对该假设的证据、检查方法、判断阈值、低风险临时措施、永久修复方向、回滚办法。
区分应用处理慢、排队等待、下游超时和网络中断；引用日志时保留时间戳。对于无法从资料确认的内容明确写“未知”。最后给出验证修复是否有效的观测指标和持续时间。

发布前验收

结论能够对应日志或监控证据

排查顺序先低风险后高风险

每项改动都有回滚方法

修复效果有明确指标和观察周期

这次修改得到什么

调试类提示词应约束模型先取证、后判断。

要求写判断阈值和回滚方法，比笼统的最佳实践更有用。