我成了计算机的导盲犬
I'm a seeing-eye dog for a computer
我是机器人代码的编写者，在2026年，我也开始让LLM帮我写代码。虽然LLM的无限耐心能缓解枯燥的编程工作，但在调试机器人时，可视化才是金标准。我原本希望让LLM利用其图像编码器和MCP服务器自动完成调试循环，让我能腾出手去抢休息室的剩披萨。但现实很骨感：LLM缺乏对真实机器人运作的理解，且控制GUI工具的效率极低。我花30分钟等来的往往是一个错误的答案。最终，我不得不亲自操作调试器，截图告诉LLM它错得有多离谱。我意识到，目前我更像是一只为计算机指路的导盲犬，而非被它替代的程序员。
让LLM做你想做的事，这比在网上跟人争辩要愉快得多，毕竟争辩六句后你就会发现对方根本不会思考。
HN 评论区
95- dwedge
> 我过去常在互联网上跟人争论，大概六轮回复后，你就会意识到对方根本不具备思考能力。
他意识到了当下的困境，却没意识到自己其实是在和机器人农场以及为此专门雇佣的团队争论——他们的任务就是散布绝望、挑起争端并制造互动。
大约十年前，我就在 Twitter 的热门话题中注意到了这种现象。对手并非因为观点不同而显得愚蠢，而是他们的说话方式同时表现出“聪明”与“愚蠢”，这种矛盾是我在真人身上从未见过的，这让我意识到账号背后很可能是不同的人或机器人。
如果我在十年前就意识到了，那这种现象至少已经存在了十五年。他并没有比这些人高明，他只是掉进了他们的陷阱。
- onion2k
我告诉初级/中级开发者的一条首要原则就是：“光靠读代码是调不出 bug 的。”我们所有人对代码如何运行都有一个心理模型，而这个模型通常有点偏差。Bug 就是这些偏差在现实中的体现。当你阅读代码时，一切都会经过你心理模型的过滤，这让你对“为何会发生意外情况”视而不见。要想调试问题，你必须能让系统进入 bug 发生时的状态，从而观察其成因。
LLM 通常只能通过你提示词中提供的信息来“阅读”代码进行调试。文章中的图片是一个元提示（meta-prompt）——提示词来自于 AI 用来“理解”红色圆圈标注的视觉模型。这行不通。要想成功调试出问题所在，它需要更完善的系统状态信息。比如，是否向它解释过“架子（shelf）”？图片中的对比度或缺少阴影是否干扰了视觉模型？为什么图片里没有“盖子（lid）”？诸如此类。
LLM 很聪明，但它们不是魔法。把它们当成天真的初级开发者对待。提供足够关于系统状态的数据，让它们能真正理解问题。
- hspeiser
我完全理解这一点。我曾参与过机器人手部的工作，5.6 和 Fable 5 在帮我进行任何视觉调试方面几乎毫无用处。
我发现真正超级有用的是让模型生成一个交互式 3D 查看器，我可以在其中移动、高亮或涂色（直接在几何体上进行软体涂色来标记问题，不同颜色代表不同的故障）。这提供了一种更好的方式来传达物理关系和位置，而这些信息在带标签的截图中很难表达清楚。
这当然仍然需要大量手动工作，所以“导盲犬”的描述确实很贴切。但我发现，在提供几个带有额外上下文的示例后，模型处理问题的能力会显著提升，变得真正有用。
- beklein
稍微跑题一下，但我非常喜欢作者主项目落地页（https://rerun.io/）上的那个小机器人。
我通常谴责“鼠标劫持”（mouse hijacking），但这个实现我可以原谅。
- Fr0styMatt88
我发现 LLM 在某种特定类型的调试上特别糟糕，虽然我也说不清具体是哪一种。
当代码可以被直接查看并与已知 bug 模式进行匹配时，比如“找出这段代码里的 bug