当 AI 成了那个特别自信但总改不对的同事

一个 tkinter 程序在 Windows 上跑得好好的到了 Ubuntu 上一闪而过。我把错误日志丢给 AI它给了我 4 次根因分析 修复方案每次看起来都很有道理每次都修不好。最后我上网搜了 5 分钟找到了真正的答案。背景我写了一个用 Python tkinter 做 GUI 的知识库搜索工具PyInstaller 打包成单文件。Windows 上一切正常放到 Ubuntu 上运行./KnowledgeSearchTool窗口一闪而过终端输出X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 139 (RENDER) Minor opcode of failed request: 20 (RenderAddGlyphs) Serial number of failed request: 712 Current serial number in output stream: 727Python 层没有任何异常日志显示程序启动完毕、缓存加载成功但 X11 协议层崩了窗口直接销毁。我把错误日志贴给 AI“Ubuntu 下面报这个错帮我分析一下。”AI 的四次诊断全错第 1 次字体是 Microsoft YaHeiAI 扫描了源码发现 GUI 代码里硬编码了 20 处font(Microsoft YaHei, ...)根因Ubuntu 上没有微软雅黑字体tkinter 创建控件时遇到未知字体名触发内部错误窗口创建过程中异常退出。方案创建_font_utils.py跨平台字体选择——Windows 用微软雅黑Linux 用 Noto Sans CJK SC。我照做了重新打包运行——依然崩。第 2 次Noto Sans CJK 没装根因上次改的字体Noto Sans CJK SC如果系统没装tkinter 的 fontconfig 解析会失败X11 渲染层直接崩溃。方案Linux 字体改为sans-serif——fontconfig 会自动回退没装 CJK 字体也不崩。我照做了重新打包——依然崩。第 3 次sans-serif 也被 fontconfig 坑了根因sans-serif虽然是通用别名但 tkinter 交给 fontconfig 解析后如果系统里某个 CJK 字体的字形表损坏或超大 glyph 超出 X11 协议限制RenderAddGlyphs就会报BadLength。方案改用TkDefaultFont——tkinter 内置默认字体完全不走 fontconfig稳定可靠。代价是 Linux 上中文可能不太好看。我照做了重新打包——依然崩。三次下来从字体名不存在到字体文件损坏到fontconfig 解析链路AI 的分析一次比一次深入改动的代码也越来越底层。但结果全是零。第 4 次我上网搜了 5 分钟这时候我突然想到AI 从头到尾都是从源码推理出来的它没有真的在 Ubuntu 上跑过这个程序。它不知道到底是什么 tm 的 glyph 触发了 X11 协议限制。我打开浏览器把RenderAddGlyphs BadLength输进去。第一条结果就指出了答案emoji 字符的 glyph 在某些字体中超过 X11 协议最大请求长度65535 字节。我的程序里确实有 emoji帮助文本里的右键菜单里的 在浏览器打开和 复制 URL解决方案sudoaptinstallunifont重打包运行——窗口正常显示了。复盘AI 为什么会连错三次问题不在 AI “不够聪明”而在它的工作方式有结构性缺陷1. 不会做实验AI 从头到尾没有建议过你直接在 Ubuntu 上跑python main.py看看 stderr 有没有更多信息。它全程只做了一件事——读源码 → 推测原因 → 出修复方案。这是 AI 和人类工程师之间最根本的区别。一个合格的工程师遇到 X11 协议层错误第一反应是在目标环境上复现一下看看是不是必现的换个终端、换个窗口管理器试试搜一下错误码AI 跳过了所有这些步骤直奔我分析了下代码问题出在……2. 错误归因的锚定效应AI 看到RenderAddGlyphs第一反应是字体渲染问题 → 字体名不对。这个初始假设一旦建立后面两次诊断都在同一个方向上深挖——换字体、换解析器、绕 fontconfig——而不是停下来想想有没有可能是 glyph 数据本身的问题而不是字体选择的问题就像一个医生看到发烧就认定是感冒换了三种感冒药没用也没想起来可能是肺炎。3. 不知道X11 emoji这个经典组合这是纯知识边界问题。如果你知道BadLengthRenderAddGlyphs tkinter/emacs/URxvt 这个组合在 Linux 桌面圈是个老牌问题了第一时间就会想到 emoji。AI 的训练数据里显然缺少这类X11 协议限制的实践知识。反过来说这正是搜索引擎比 AI 强的地方——搜索不推理它直接把人类解决过同样问题的记录返还给你。4. 说得太自信三次诊断每一次都是根因xxx方案创建 xxx改成 xxx措辞斩钉截铁分析层层递进但三次全错。AI 最危险的地方不是它会犯错而是它犯错时和正确时看起来一模一样。教训对 AI 使用者AI 擅长已知模式的代码生成不擅长未知领域的故障诊断。遇到非常见错误先搜一下别让 AI 带着你在错误方向上一路狂奔。要求 AI 先验证再修改。可以让它先写个最小复现脚本在目标环境跑一下而不是直接改项目代码。看 AI 的置信度信号。如果它反复在同一个框架内打转换字体→换字体→换字体说明它卡住了需要引入新信息。对 AI 工具本身应该内置建议用户先在目标环境运行诊断命令的意识遇到 X11/Wayland 等图形协议层错误时应提示用户搜索错误码连续两次同方向修复失败后应主动承认不确定性建议换思路终局的修改清单折腾了一圈最终改动其实很小文件改动src/gui/_font_utils.py新建——跨平台字体选择保留了虽然字体名不是根因但对可移植性有益src/gui/main_window.py硬编码Microsoft YaHei→get_font()调用src/gui/search_panel.py同上build_linux.spechiddenimports补上src.gui._font_utilsREADME.md/README_EXTERNAL.mdUbuntu 依赖加上unifont真正解决崩溃的那一行代码不是我改的任何一行——是用户执行的sudoaptinstallunifont后记这篇文章不是要贬低 AI。相反如果你把它当成一个特别能写代码但不会实际动手调试的初级工程师它的表现其实很真实——有理论基础、分析有逻辑、代码写得快但缺实战经验。问题的关键是你不能把它当成全知全能的专家。它是个工具用得好是利器盲信就是灾难。