Error To Fix — 需要修复的错误

错误修复（Error to Fix） 当用户（1）粘贴编程错误消息、堆栈跟踪或异常，并询问出了什么问题时。 （2）用户说“这个错误意味着什么”、“为什么会坏”、“如何修复”或“如何解决这个错误”。 （3）用户粘贴一个 bug 描述，并要求进行根因分析和解决方案。 核心位置 这个技能解决了特定的问题：错误消息是神秘的——用户需要对错误的简单语言解释和如何修复它。 这个技能不是： 代码重写工具——它解释并建议修复，不会重写整个文件。 调试环境——它分析报告的错误，不会运行代码。 部署工具——它不修复生产问题，只提供建议。 这个技能仅在以下情况下激活： 错误消息或堆栈跟踪 + 解释/修复意图都存在。 模式 /error-to-fix 默认模式。分析错误并提供解释、根因和修复建议。 何时使用：用户粘贴一个错误并希望了解和解决它。 /error-to-fix/root-cause 关注底层系统级别的原因，而不仅仅是立即的症状。 何时使用：用户希望更深入地了解超出表面级别的修复。 /error-to-fix/prevent 建议模式和实践以防止此错误再次发生。 何时使用：用户处于审查或学习环境中，希望长期避免错误。 执行步骤 步骤 1 — 解析错误 接收错误输入（粘贴文本、堆栈跟踪、截图文本） 检测错误类型： SyntaxError：Python/JavaScript 解析失败——通常是输入错误或缺少令牌 RuntimeError/Exception：代码运行但崩溃——检查类型、导入、空引用 ImportError / ModuleNotFoundError：缺少或错误命名的依赖 ConnectionError / Timeout：网络、数据库或 API 连接问题 PermissionError / AccessDenied：文件或资源权限问题 AssertionError / 测试失败：行为不匹配预期结果 自定义错误：用户代码或库的非标准错误 从错误中提取关键标识符： 错误类型名称（回溯或错误类中的第一个单词） 文件路径和行号（错误发生的位置） 变量/状态值在故障点 如果存在版本信息（库版本、Python/Node 版本） 步骤 2 — 确定根因 对于每个识别的错误类型： 错误类型 常见根因 快速诊断 SyntaxError 缺少 )、：或 } 检查行号和周围行 ModuleNotFoundError 导入中的输入错误、缺少包 pip 安装 / npm 安装 TypeError 传递给函数的错误类型 检查实际类型与预期类型 ReferenceError 在赋值前使用变量 检查变量初始化 ConnectionError 错误的 URL、防火墙、服务关闭 验证 URL 和网络访问 ImportError 循环导入、错误路径 检查 __init__.py 和导入顺序 ValueError 无效的参数值 检查值与允许的范围 KeyError 缺少字典键 检查键是否存在 步骤 3 — 提供解释 结构每个响应为： 发生了什么（一句话）：错误的简单语言描述 为什么发生了：根因——错误实际上在告诉你什么 如何修复：具体的、可执行的步骤，必要时带有代码 如何防止：避免此错误的实践或模式 步骤 4 — 验证 错误类型被正确识别 根因是具体的，而不是通用的（“某些东西出了问题”） 修复适用于确切的错误——而不是类似的但不同的错误 没有代码更改会与用户现有的代码相矛盾或撤消 强制规则 不要 不要在错误消息不明确时猜测根因——使用错误消息中说的话 不要提供需要安装包或修改用户未提及的文件的修复 不要超出最小修复范围更改用户的代码逻辑 不要在未解释的情况下将错误驳回为“不是问题” 要 在解释中引用具体的错误消息 提供最小的、有针对性的修复——而不是整个文件的重写 区分快速修复和适当的架构解决方案 当错误单独不足以诊断时，要求相关的代码片段 质量标准 一个好的输出： 错误类型被正确识别和命名 根因是具体的，并解释了为什么在这种情况下发生了错误 修复是最小的，并直接解决了原因 预防提示是可执行的，并与错误类型相关 一个坏的输出： “某些东西出了问题”作为解释 修复需要更改代码库的无关部分 根因与错误消息中所述相矛盾 当错误不明确时，提供 5 个可能的原因 好与坏的例子 场景 坏输出 好输出 Python TypeError “类型错误发生” “TypeError：list.append 期望 str，得到 int —— 在输入周围添加 str() 转换” Node ModuleNotFoundError “模块缺失” “ModuleNotFoundError：'requests' 不在 requirements.txt 中 —— 运行 pip 安装 requests”