一屏红字，你只复制了第一行。
前两篇讲的是「读懂」，从这一篇开始讲「修好」。
先说一个几乎所有新手都干过的动作：
程序跑挂了，屏幕上刷出一大片红字。你眯着眼睛看了两秒，鼠标一划，复制了最上面那一行，丢给 AI，问：
“这个错怎么解决？”
然后 AI 给了你一个答案。你照着改，红字消失了。
三天后，同一个地方，换了个姿势又炸了。
这就是”贴报错”最大的陷阱：你以为你在修 bug，其实你只是在让红字消失。
这一篇就讲三件事：一屏红字里哪几行是宝贝、哪几行是噪音；只贴报错为什么常拿不到正解、还差哪几样东西；以及怎么判断 AI 给的是真修好还是假修好。
一、先破个误区：错误信息不是”报警”，是”证词”
很多人对报错的心理是：这玩意儿是来骂我的。
所以看到红字，第一反应是躲——赶紧让它消失。
换个视角：错误信息是程序留给你的一份证词。
它老老实实交代了三件事：
- 发生了什么类型的问题（是找不到东西？还是类型不对？还是权限不够？）
- 是在哪一行、哪个文件出的事
- 出事的时候，那些变量是什么值
这三件事，就是破案的全部线索。
你把证词只念了第一句就合上，当然破不了案。
二、错误栈怎么读：三步定位法
所谓「错误栈」（也叫堆栈、调用栈、traceback），就是那一大坨看起来像天书的东西。
它其实是一张路径图：程序从哪儿出发，一路调用了谁，最后在哪儿摔倒了。
新手觉得它可怕，是因为里面大部分文件名你根本没见过——那些都是库和框架内部的文件。
记住三步，就能读懂九成的错误栈。
第一步：找”错误类型 + 错误消息”这一行
这是整段报错的核心。
不同语言位置不一样：
- Python：在最后一行（比如
KeyError: 'user_id'） - JavaScript / Node：通常在第一行（比如
TypeError: Cannot read properties of undefined） - Java / C#：在第一行（比如
NullPointerException）
这一行告诉你”是什么错”。
第二步：从栈里找出你自己的文件名
这一步是最关键的，也是最多人漏掉的。
那一大坨路径里，绝大部分长这样：
at node_modules/xxx/lib/index.js:412
at /usr/lib/python3.11/site-packages/yyy/core.py:88
凡是路径里带 node_modules、site-packages、vendor、dist、lib 这些字眼的，基本都不是你的代码。
你要找的是带着你自己项目文件名的那一行——比如 app.py、main.js、UserService.java。
那一行，才是你真正要看的地方。
小技巧： 如果栈里出现了好几行你自己的文件，取离错误最近的那一行（Python 看最下面那个，JS 看最上面那个）。
第三步：看错误消息里的”具体值”
好的报错会把出事时的实际值写出来：
KeyError: 'user_id'—— 说明它去找一个叫user_id的东西，没找着Cannot read properties of undefined (reading 'name')—— 说明某个东西是空的，你还想从它身上拿name
这一步回答的是”为什么”。
三、贴报错四件套：错、码、做、境
现在到了最实用的部分。
只贴报错，AI 的回答准确率大概只有五成。
你要给它四样东西，我把它叫「贴报错四件套」：
| 件 | 内容 | 一句话 |
|---|---|---|
| 错 | 完整报错原文 | 从头到尾，别截断，别转述 |
| 码 | 出错那段代码 | 报错指到的那一行及其上下文 |
| 做 | 你做了什么才触发的 | 点了什么、传了什么参数 |
| 境 | 环境信息 | 语言版本、框架版本、怎么运行的 |
逐个说清楚为什么。
「错」：完整原文，不要转述
最要命的一个坏习惯是用自己的话描述报错：
❌ “它说什么找不到什么东西”
AI 收到这句话，只能靠猜。
✅ 直接把整段红字，从第一个字符复制到最后一个字符，原封不动贴进去。
你觉得看不懂的那部分，恰恰可能是 AI 最需要的部分。
「码」：贴出错那一行的前后文
只贴报错指到的那一行是不够的。
那一行是结果，原因往往在它上面几行。
建议贴出错行前后各 10～20 行，或者干脆把整个函数贴进去。
如果这段代码依赖别的地方传过来的数据，把数据长什么样也说一句。
「做」：复现动作
这一条最容易被忽略，但价值极高。
“我在页面上点了’提交’按钮，表单里手机号那一栏是空的，然后就报了这个错。”
这一句话，直接把排查范围从”整个项目”缩小到”表单提交 + 空值处理”。
很多时候，AI 靠这一句就能直接猜中根因。
「境」：环境信息
同样一行代码，在不同版本下的行为可能完全不同。
至少说清楚：什么语言、什么框架、大概什么版本、在哪儿跑的（本地/服务器/浏览器）。
四、最大的坑：红字消失 ≠ 问题解决
AI 有一个很强的倾向：它会优先给你”能让报错消失”的方案，而不一定是”能让问题不再发生”的方案。
下面这三种改法，都是典型的”假修好”：
假修好一：把错误吞掉
给你套一层 try / catch（或者 try / except），把报错捂住不让它冒出来。
红字确实没了。但那段逻辑其实根本没跑成功，只是你看不见了。
后果是：数据没存进去，你还以为存了。
假修好二：加个判空绕过去
比如报错是”某个值是空的”，AI 给你加一句”如果为空就跳过”。
问题是：它为什么会是空的？
如果它本来就允许为空，那这么改是对的； 如果它本该有值却没有，那真正的 bug 在更上游——你只是把症状挡住了。
假修好三：强行转类型
报错说类型不对，AI 给你强制转一下。
这跟上面同理：类型为什么会不对？ 这才是要问的。
所以，AI 给完修改方案后，你必须追问三句话。
我把它叫「修完必问三句」：
- 这个错的根本原因是什么？ 请从触发到报错，按顺序讲一遍。
- 你这个改法是治标还是治本？ 如果是治标，治本该怎么改？
- 项目里还有没有别的地方，可能犯同样的错？
第三句尤其值钱。一个 bug 出现的地方，往往不止一处。
五、按错误类型分档，问法不一样
不是所有报错都要走完整套流程。先分个档，省时间。
第一档：一眼错（30 秒解决）
拼写错了、少个括号、变量名写错、忘了导入。
这类错误消息通常很直白，AI 几乎不会答错。
直接贴报错 + 那一行代码就够了，不用四件套。
第二档：环境错（最烦人的一档）
装不上、跑不起来、版本冲突、路径找不到。
这一档的特点是：代码本身没问题，问题在外面。
贴的时候一定要重点给「境」：操作系统、语言版本、安装命令、完整的安装日志。
提示：这一档特别容易踩到”网上抄的方案是别人环境下的”。让 AI 明确告诉你每条命令是干什么的，别闭眼执行。
第三档：隐蔽错（要走完整流程）
程序跑得好好的，某个特定条件下才炸。
这一档必须上四件套，而且「做」这一项最关键——你要说清楚什么情况下会出、什么情况下不出。
“输入正常数据没问题，一旦名字里带空格就报错。”
这一句话的价值，超过一百行代码。
六、还有一招：让 AI 教你自己看
如果你想真的进步，而不是每次都当伸手党，加一句话就行：
“修改之后，请再告诉我：以后遇到同类报错，我自己该怎么一眼看出问题在哪？”
AI 会给你一套”识别特征”。
积累十几条，你会发现大部分报错你自己扫一眼就知道原因了。
提示词模板盒子
以下模板可直接复制使用，把【】里的内容换成你自己的。
模板 71-1：贴报错四件套（万能主模板）
我遇到一个报错，需要你帮我定位并修复。
【① 错 —— 完整报错原文】
（从头到尾原封不动粘贴，不要删改、不要转述）
【② 码 —— 出错的代码】
（报错指向的那一行，及前后各 15 行；能贴整个函数更好）
【③ 做 —— 我是怎么触发的】
我做了：（例如：在页面点了"提交"按钮）
当时的输入是：（例如：手机号那栏是空的）
什么情况下不会出现：（例如：填了手机号就正常）
【④ 境 —— 环境信息】
语言/框架： 版本： 运行方式：（本地/服务器/浏览器） 操作系统：
请按以下顺序回答：
1. 这个报错的中文意思是什么（大白话）
2. 根本原因是什么，从触发到报错完整讲一遍
3. 给出修改后的完整代码，标出改动了哪几处
4. 说明这是治标还是治本
我是编程新手，请不要用没解释过的术语。
▸ 环境类报错：在「④ 境」里重点给操作系统、语言版本、安装命令和完整安装日志，并让 AI 说明每条命令是干什么的、别闭眼执行（原模板 71-4）。 ▸ 偶发 bug（时好时坏）：在「③ 做」里写清”什么情况下会出现、什么情况下不会、多久出现一次”，附上报错原文和相关代码，让 AI 按可能性列原因并给验证动作（原模板 71-5）。
模板 71-2：读懂错误栈（看不懂那一坨时用）
下面是一段报错的完整堆栈信息，我看不懂。
请帮我拆解：
① 错误类型和错误消息是哪一行？中文意思是什么？
② 这一坨里，哪几行是我自己的代码，哪几行是库/框架内部的？分别列出来。
③ 我应该重点看哪一行？为什么？
④ 从这段信息能推测出，出事时哪个变量是什么值？
报错原文：
【粘贴完整报错】
模板 71-3：修完必问三句（防假修好）
关于你刚才给的修改方案，我要确认三件事：
① 这个 bug 的根本原因到底是什么？
请从"用户做了什么"开始，一步步讲到"为什么会报错"。
② 你的改法是治标还是治本？
如果只是让报错不再出现、但根因还在，请明说，
并告诉我治本应该怎么改。
③ 我的项目里，还有没有别的地方可能犯同样的错？
请告诉我该用什么关键词去搜索排查。
▸ 顺便学会自己看：修好后加一句——”以后遇到同类报错，我自己该怎么一眼看出问题在哪？”让 AI 给你一套识别特征，抄进笔记（原模板 71-6）。
速查：一屏红字，先看这三处
| 步 | 看什么 | 回答什么 |
|---|---|---|
| ① | 错误类型 + 消息（Python 看最后一行，JS/Java 看第一行） | 是什么错 |
| ② | 栈里带你自己文件名的那一行 | 错在哪 |
| ③ | 消息里出现的具体值 / 变量名 | 为什么 |
路径里带
node_modules、site-packages、vendor、dist的，一律先跳过。
速查：三档报错，投入不一样
| 档 | 典型表现 | 该怎么贴 |
|---|---|---|
| 一眼错 | 拼写、括号、忘导入 | 报错 + 那一行，30 秒搞定 |
| 环境错 | 装不上、跑不起、版本冲突 | 重点给「境」+ 完整安装日志 |
| 隐蔽错 | 平时正常，特定条件才炸 | 上全套四件套，重点写「做」 |
最后
这一篇的核心，压缩成一句话：
红字消失，不代表 bug 修好了。
判断标准只有一条——你能不能说清”它原本为什么会变成那个值”。
说得清，是真修好；说不清，只是把问题往后拖了几天。
而要说得清，前提是你给了 AI 足够的证词：错、码、做、境。
下篇预告
第72篇《让 AI 定位逻辑错误——没有红字也能查》。 下一篇讲更难的：程序跑得欢、结果却不对，一个红字都没有——不报错的 bug，才是真正吃时间的那一类。我们下篇见。