凌晨两点，线上报错。把终端里最后一行 TypeError 截图丢给 DeepSeek，问一句「这是怎么回事」，得到的往往是「可能是某个变量为空」「建议检查数据类型」这类正确但没用的解释。问题不在模型，在于你给它的信息只够它猜。
原文的结论很直接：让 DeepSeek 把堆栈变成修复方案，关键不是让它解释错在哪，而是喂对上下文——贴全堆栈、圈定代码、限制改动范围。三步走完，异常就变成了能直接跑的补丁。
一、只贴最后一行，模型只能猜
报错堆栈（traceback）是从出错那一行，一路回溯到程序入口的调用链，每一帧都写着谁调用了谁、在哪一行炸的。它本身就是一张定位地图。你只给它终点坐标，它当然找不到路。
最常见的错误是只发 KeyError: ‘name’ 这一行。模型不知道你的 user 字典里到底有没有 name 这个键，也不知道这行代码在哪个函数里、被谁调用，于是只能基于训练经验泛泛而谈。
Python 3.11 之后，traceback 会用 ^ 标出具体出错的位置，这行信息一起贴过去，定位会准得多；旧版本没有这个标记，就要靠你把上下文补上。
二、第一步与第二步：贴全堆栈、圈定代码
动手前先做一件事：保留终端里的完整报错，不要手动删行；同时打开出问题的源文件，确认行号对得上。
然后按三步走：
- 复制从 Traceback (most recent call last): 到最后一行的全部内容；
- 圈出你怀疑的那段代码，用注释标一句「问题大概在这附近」；
- 提示词写成：「下面是完整报错和相关代码，请只给最小修复并解释原因。」
一段最小化的报错长这样：Traceback (most recent call last): File “app.py”, line 12, in <module> print(user[“name”]) KeyError: ‘name’。配上 line 12 和那行代码，DeepSeek 立刻知道是字典缺键；只发最后一行，它可能让你去查完全不相干的地方。
圈代码要有个度：用三五个字点出「问题在这」就够了，别把整个文件贴进去。文件太长会冲淡堆栈信息，模型反而抓不住重点。
如果报错来自第三方库，堆栈里会有一长串 site-packages 的帧，同样别删。真正有用的往往是你自己代码和库交界的那两三帧，删掉就找不到交界点了。
三、第三步：只要最小修复，并让它说明原因
第二步做完，还差一句硬约束：只给最小修复、并解释为什么。不加这句，DeepSeek 倾向于重写整段，顺手加一堆你没要的校验、封装和配置读取；改动面一大，引入新 bug 的概率跟着上来。
原文的例子很典型：修复前是 print(user[“name”])，修复后只改一处 print(user.get(“name”, “匿名”))。用 dict.get 带默认值，既消掉崩溃，也不动其他逻辑，这才叫最小改动。
约束可以再具体一点：把「不要重构、不要改函数签名、不要新增依赖」一起写上。要求越明确，它越不会越界。
拿到修复别急着合并。先在本地重跑，确认真的不报了；涉及数据库写入、文件删除的改动，先看清影响范围再动手。如果跑完还是报错，把新的 traceback 接着贴回去，说明「上次的改法没生效」，它通常会自己纠正，比重新开一个对话更连贯。
四、对照表与踩坑清单
把三步和最后一步验证摆在一起，漏掉哪一步、后果是什么，一目了然：
- 贴完整 traceback——漏了，模型只能猜错误；
- 圈定相关代码——漏了，修复泛泛、不对症；
- 要求最小修复加原因——漏了，代码被重写成一堆多余改动；
- 本地重跑验证——漏了，轻信「已修复」，把新问题带上线。
顺序也别乱：先有完整堆栈，再圈代码，最后才谈改法。有人一上来就问「怎么改」，模型连错在哪都不知道，只能给通用建议。
这套方法的价值不在技巧多高明，而在于它可以固化成模板：以后每次求助，都按「完整堆栈 + 相关代码 + 最小修复」三段来写。模板固定了，模型的表现也就稳定了。
本文转载自编程狮（w3cschool.cn） 《DeepSeek 帮读报错堆栈：把异常变成修复方案的 3 步法》，原文链接：https://www.w3cschool.cn/article/73622762.html。版权归原作者所有，如需删除请联系我们。