工业机器人编程是个很特殊的行当。工程师用ABB RAPID专有语言写代码，在RobotStudio里看着机器人动，确认没问题再部署到客户现场。项目大多不是从零写，而是拿以前的程序改，如重命名变量、挪个位置、把路径反过来……单看每一步都很简单，但架不住多，而且特别容易出错。然后就有软件开发者号称AI智能体已经可以自己读文件、写代码、跑命令、检查修改，但问题是他们大多在隔离环境或测试台上评估，缺少工程师在闭环中的真实使用证据。所以，为了搞清楚AI智能体到底能帮机器人工程师干多少活，工程师团队决定亲自上场。

来自德国的帕绍大学的研究团队和机器人自动化公司AKE在项目里做了一场真实测试：让4个机器人工程师（人均7-14年经验），用同一个本地部署的AI智能体，去完成6类真实的工作任务。

 

1.实验怎么做？

1）资源约束：AKE工程师用ABB RAPID编程，在RobotStudio虚拟站里开发测试，再部署到客户现场。客户代码和数据都是机密，不能用云端大模型，只有一台单H100 GPU的本地服务器，公司也没资源自己训练模型，只能用公开模型和现成框架。（这基本就是很多预算有限、数据敏感的中小公司的真实处境。）

2）技术方案：终端版Claude Code当智能体（开箱即用，能读写文件、执行命令、自查修改），配上通过Ollama本地部署的GPT-OSS 120B开源模型。

3）六类任务：全部来自真实项目，工作量估计30到60分钟：

·重构与扩展——复制现有例程、小改（比如变量重命名）、在正确位置调用。

·写文档——按公司模板填系统信息、坐标系、工具、流程和运动例程说明。

·调试——在一个模块里找出并修好8个隐蔽错误（2个语法错、6个语义错）。

·路径反转——给正向运动序列，实现反向序列，可能还得改运动类型、增删动作。

·轨迹矩阵生成——只给坐标，从零生成两两位置之间的正反向运动路径。

·3D堆叠——编程让机器人堆电池，要算偏移、还要规划高效顺序（团队负责人认为最难）。

4）实验设计：4位工程师采用AB/BA交叉的方式。第一天A组上午不用智能体、下午用，B组反过来；第二天互换。每个任务记录时间、问卷、项目备份和聊天记录，任务限时，由团队负责人按功能性、代码质量、可读性打分（1到5分），再用自动验证器查是否符合公司编程规范。期间用2天来集中观测，观测日间隔八周。

中间还改了一版配置：第一天给了三个要手动调用的技能（改变量名、加偏移、反转运动），结果几乎没人用。第二天改成自动加载项目上下文，把ABB RAPID参考手册、任务说明和项目规则文件都喂给智能体，让它不用人喊就能拿到领域知识。

2.实验结果：AI智能体几乎全面落后

1）智能体的任务完成率：很差

第一天：12个任务，用智能体只完成3个，不用智能体完成9个。

第二天：9个任务，用智能体只完成1个，不用智能体完成5个。

在大多数任务上，工程师用智能体比不用智能体更耗时，只有少数任务上花的时间一样多。

2）质量：多数任务上AI智能体做的更差

第一天平均分：

→功能性1.7（用智能体）比2.3（不用智能体）

→代码质量1.8（用智能体）比2.5（不用智能体）

→可读性2.1（用智能体）对2.8（不用智能体）

→自动验证器在智能体方案里查出25处规范违规，不用智能体却只有11处违规。

→调试任务上，用智能体，剩7个逻辑错误加2个语法错误；不用智能体，只剩5个逻辑错误加0个语法错误。

唯一亮点：重复性任务干得不错

轨迹矩阵生成这个任务，在第一天用智能体后效果可媲美不用智能体，第二天效果超过不用智能体。第二天工程师用智能体15分钟做完，第一天他不用智能体花了18分钟。这说明，当工程师能精确说清要什么后，剩下的敲代码任务最适合给智能体。而且第二天用了智能体后的代码质量、可读性和规范遵守度都在提升（违规从25处降到16处，无违规方案从2/10提升到5/8）。研究者认为，这是因为工程师在学习，智能体配置也在改，也有自己的学习曲线。

3.AI智能体为什么没效果？来自五个原因

第一，什么都丢给了智能体。工程师把所有活都交出去，连加个逗号都要它做，结果智能体反复重写大段代码甚至整个模块，对话越拖越长，后期甚至开始胡编，偏离了本来正确的中间结果。这一点符合大模型在长对话时性能退化的规律，因为两天都是这样，改配置也没解决。

第二，把智能体当聊天机器人。工程师习惯了聊天式AI，介绍里讲了怎么调用技能，也几乎没人用（只有在任务4用了一次）。

第三，看不见机器人怎么动。机器人工程靠的是在仿真环境里目视确认运动，而智能体只能看代码，看不到虚拟站。这种空间感的缺失，是生成代码功能不佳的重要原因，未来也许能通过MCP服务器和RobotStudio深度集成来补。

第四，低估了终端界面的冲击。工程师平时用RobotStudio这类图形工具，第一天都觉得终端又新又难用，但是到第二天已经没人再提了。这恰恰提醒我们，短期测试很容易把"新手期的不顺手"误判成"工具不行"。

第五，经验结构很反直觉。第二天唯一用智能体完成任务的，是AI经验最丰富的人；机器人经验最丰富的人，在第二个观测日时发现他用智能体反而一个任务都没完成；几乎不用智能体的，两天都没完成，也是对智能体最失望的人。这说明决定成败的是AI经验，不是机器人工程经验。（不过四位都是至少7年经验的资深工程师，这个结论不能直接推广到新手。）

4.给想落地AI智能体的公司三条建议

1）要培训怎么用，而不是给个新工具。工程师需要学会什么时候交给智能体、什么时候自己改、什么时候开新对话。对此要有专门培训和练习，还要留出适应期。

2）从合适的任务起步。重复、定义明确的生成任务（轨迹矩阵、文档草稿）比需要空间理解的任务更适合打头阵，让工程师先在智能体完成度好的任务上建立手感。

3）把上下文配好。参考手册和编程规范应该通过项目上下文自动提供给智能体，而不是靠人手动调用。这项改动在此实验里确实提升了规范遵守度，也让"缺少ABB文档"从问题清单里消失了。

5.对研究人员的启示

·孤立任务的基准测不出真实使用效果，要在闭环里和工程师一起评估。

·要纵向研究采用过程：实验里两个集中观测日只是两个快照，却已经能看到明显的学习效应。学习曲线多长、用法会不会变、生产力最终能不能超过不用智能体的情况，都需要更长时间去观察。

·要报告智能体配置：看起来很小的配置差异（手动调技能 vs 自动加载上下文）就能影响结果，研究应该把这些细节写清楚，方便比较。

6.结语

实验最出乎意料的地方在于：智能体恰恰在我们以为它最擅长的任务上表现最差。小范围、孤立的代码修改能力，并不能自动迁移到真实项目里需要规划、组合大量修改的大任务，就算能迁移，也不等于比经验丰富的工程师更高效。不过生产力是随着培训和经验移动的，人在学习，配置也在学习。智能体也不是即插即用的生产力按钮，而是一场需要培训、领域适配和时间投入的组织变革。

因此，对于想在机密环境里用AI智能体的中小公司来说，技术上其实完全可行，有本地部署、开源模型、现成框架就够了。真正门槛不在技术，而在于人和配置。

 

说明：1.文章参考公开报道并借助AI工具进行整理和分析，如有不妥之处欢迎指正。2.部分市场数据基于行业估算、发布以及官方报道，具体精确数据请以权威机构为准。3.欢迎长期追踪边缘AI的朋友一起探讨。