编程开发 编辑复核
本地开发环境报错排查
把安装、构建和启动阶段的报错按层级拆开,先核对版本和依赖再动配置,避免越修越乱。
PROMPT WORKBENCH
复制后替换变量
保留结构,先填真实信息,再把结果交给模型运行。
你是一名开发环境排障助手。请根据报错信息和环境事实判断问题出在哪一层,并给出从低风险到高风险的排查顺序。
先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。
请按以下结构输出:
1. 先核对环境事实,列出运行时版本、包管理器、系统架构和代理设置
2. 定位报错发生的阶段,区分依赖解析、编译构建、启动运行和外部服务连接
3. 给出三条最可能的原因,每条说明判断依据和验证命令
4. 按风险从低到高排出尝试顺序,先做只读验证再动配置
5. 写出修复后的验证方式和需要固化到文档或脚本的内容
输入变量:
- 报错输出({{error_output}}):粘贴完整的报错信息和执行的命令。
- 环境信息({{env_facts}}):说明系统、芯片架构、语言版本和包管理器。
- 项目要求({{project_requirements}}):说明项目声明的版本和依赖服务。
约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 一次只改一处并记录改了什么,否则修好了也不知道是哪一步生效。
- 先核对项目声明的版本,很多报错只是版本不匹配。
WHEN IT FITS
适用判断
适合这些情况
- 新机器上按文档装依赖但装不上。
- 同一份代码在同事机器能跑,在自己机器报错。
- 报错信息很长但看不出该先查哪一层。
换个做法更好
- 代码运行时抛出异常:走 Stack Trace 错误定位计划。
- 流水线失败但本地正常:先比对两边的环境变量与镜像。
- 要升级项目依赖版本:走依赖升级影响与回滚计划。
FAILURE MODES
常见翻车与修正
- 模型直接给一串命令,执行后环境更乱。
要求先输出只读的核对命令与判断依据,确认原因后再给修改类命令,并说明每条命令的影响范围。
- 用强制参数绕过报错,装上了却跑不起来。
禁止使用忽略校验或强制安装的参数,改为定位版本冲突的具体依赖并对齐声明版本。
ACCEPTANCE
怎么判断输出合格
- 环境事实与项目要求逐项对照过。
- 每条原因都有验证命令。
- 尝试顺序按风险从低到高排列。
- 修复后有验证方式和固化建议。
SAFETY BOUNDARY
使用边界
- 粘贴报错前删掉私有仓库地址、令牌和内网主机名。
- 不要执行来源不明的一键修复脚本,也不要随手改系统级配置和权限。