用户又发来一张截图，问我为什么 n8n 工作流报错。截图里是典型的 JSON 解析错误，红字堆栈，背景是密密麻麻的节点连线。我盯着那张图看了十秒，突然意识到一件事：我他妈为什么还要看这个？
直接复制截图，扔进 GPT-4o 的聊天框。指令就一行：“分析这张截图里的报错信息，给出可能的原因和解决步骤。” 三秒钟后，回复来了。它准确地识别出错误发生在“Parse JSON”节点，指出输入的文本可能不是有效的 JSON，建议用户先用“HTTP Request”节点测试一下原始返回数据，或者检查 API 响应头里是不是带了奇怪的字符。甚至，它还圈出了截图里那个容易被忽略的“Raw”按钮，说可以点开看看原始数据格式。
这感觉，就像你吭哧吭哧用螺丝刀拧了半天，旁边递过来一把电动起子。还不是普通的起子，是带激光瞄准、自动扭矩调节的那种。
过去两年，我所有的“技术支持”流程本质上都是信息翻译：用户用自然语言描述问题（往往还描述不清）-> 我脑补出可能的场景 -> 我要求用户提供更多信息（日志、截图、配置）-> 我根据这些信息定位技术栈 -> 我给出解决方案。这个链条里，最耗能、最易错的环节，就是第一步和第二步的转换。用户说“点不动”，可能是前端 JS 报错，可能是后端 API 500，也可能是他鼠标坏了。现在，链条被砍掉了。问题载体（截图）直接对接解决方案生成器（AI）。用户不需要学习“如何向技术支持提问”，他只需要会截屏。
这直接动摇了软件交付的根基。我们写文档、做引导、设计错误提示语，终极目标不就是让用户在不打扰我们的情况下自己解决问题吗？但文档永远追不上软件迭代的速度，错误提示再友好，用户也可能看不懂“TypeError: Cannot read property ‘length’ of undefined”到底什么意思。现在，答案很简单：让 AI 去看。让 AI 去读那个堆栈，去识别截图里的 UI 元素，去结合它海量的代码库知识和常见问题模式，直接生成 actionable 的指令。
我立刻开始测试边界。扔给它一张模糊的手机拍摄的电脑屏幕照片，光线很差还有反光。它居然能识别出那是 VS Code 的终端，报的是 Python 的 ModuleNotFoundError，并且建议用户检查虚拟环境是否激活，或者用 pip list 看看包是不是真的装上了。扔给它一张微信聊天记录的截图（当然隐去了敏感信息），里面用户抱怨小程序白屏。它能从只言片语里推测可能是域名没配置，或者 SSL 证书问题，并给出了登录微信公众平台后台检查的步骤。
当然，它远非万能。遇到完全自定义的、非标准错误码的 ERP 系统截图，它就只能泛泛而谈。截图如果只截了一部分，缺少关键上下文，它也会瞎猜。但它的“视力”和理解力，已经足够覆盖 80% 的、重复性的、基于常见开发工具和框架的“小白问题”。这 80%，恰恰是消耗掉我这类所谓“技术布道者”或“实战教练”最多日常精力的部分。
我开始重构我的产品交付包。以前，一个自动化工具卖出去，附赠一份 PDF 说明书、一个答疑群、我每周几个小时的专属答疑时间。现在，我在工具里嵌入一个指令：遇到任何问题，截图，发到某个指定的 ChatGPT 对话链接。我提前在那个对话里预设好了上下文，告诉 AI 这个工具的技术栈（比如，这是基于 n8n 的，调用 OpenAI 和爬虫），它的常见配置错误点。然后，把这条链接给用户。相当于我训练了一个 24 小时在线的、精通我这个特定产品的、第一级技术支持机器人。
解放出来的时间干什么？去处理那剩下的 20% 真正复杂、需要深度调试和架构权衡的问题。或者，干脆去开发更需要创造力的新东西。这种分工的变化是静默但深刻的。AI 不是替代了我，而是把我从“人肉错误代码词典”和“重复性问答机器”的角色中拔了出来，逼我去往更上游、更需要人类直觉和判断力的地方走。
也有一种隐隐的恐慌。我过去赖以生存的“技能”，很大一部分就是快速定位和解决这些琐碎报错的能力。这种能力建立在经年累月踩坑的基础上，形成了一种近乎本能的“模式匹配”。现在，一个刚出炉的模型，看一眼截图，模式匹配的速度和广度就碾压我十年的积累。我得重新审视，什么才是未来五年里，不会被轻易“视觉理解”和“代码分析”所替代的硬核价值。
也许，是如何设计出更少出错、更符合直觉的软件本身。也许是更复杂的、涉及多方利益和模糊需求的业务逻辑梳理。也许是 AI 工具链本身的搭建和调优——就像我现在正在做的。教会 AI 如何更好地帮助用户，这成了一个递归的、更有意思的游戏。
用户又发来一张新截图。这次是 n8n 的节点配置界面，他问我某个下拉选项该怎么选。我笑了笑，把同样的截图，转发给了那个我调教好的 GPT 对话。
