用途：stepback 用于在调试陷入反复失败时强制“退一步”，从症状级修补转向架构级排查。核心原则是：如果同一类问题已尝试 2 次以上修复，很可能只是在修补症状，应停止、拉远视角、研究架构。
触发时机：同一错误在“修复”后再次出现；修复 A 引出错误 B、再引出错误 C 的级联；本地正常但部署后失败；多个组件被同一底层原因破坏；修复感觉像打地鼠。也建议在主动改动部署配置、构建流水线、基础设施、平台级中间件/路由/认证，或修改 next.config.js、vercel.json、Dockerfile、CI/CD 前触发。
执行步骤：1）停止并盘点本次会话中每次修复尝试，列出所针对症状、结果、所依赖假设，以表格呈现；2）寻找共同线索，问“所有这些症状共享哪个系统”，关注共享基础设施、共享配置、共享假设；3）研究架构，使用 Perplexity 研究代理执行三条查询，分别针对共享症状模式的常见原因、平台/框架部署问题、本地正常生产失败的错误模式，此步为强制；4）优先测试最广假设，例如不问“/api/revalidate 是否工作”，而问“生产环境是否有任何 API 路由工作”；5）向用户呈现症状级修复与架构级修复的对比、工作量比较与建议，由用户决定。
限制与说明：资料未提供安装命令、价格、平台支持范围或具体集成方式。该技能强调不要假设重构总是更好，有时打补丁确实正确；同时提供“局外人测试”，即假设自己是新顾问，追问与标准配置的差异、全新安装会是什么样、哪些自定义可能引发问题。资料中的真实案例显示，5 次修复均属真实问题但非根因，最终发现 next.config.js 中 outputFileTracingRoot 指向硬编码本地路径，导致 Vercel 构建时静默生成零个 serverless 函数。