麦睿菱AI实践 01|AI会写代码,员工为何还在等专家
AI 能写方案、写代码以后,企业更该关心一个问题:员工能否把原本要等专家接手的工作先推进一段。发账号只是开始,专业方法、数据和工具要一起准备好。这样员工才能带着现场事实比较结果,专家也能少花时间反复补材料。

如果客户在测量现场提出一个新要求:原来的指标只给出一圈内的最大波动,客户还想知道,这圈里究竟起伏了一次,还是两次。现场工程师接下来能做什么?
工程师听懂了,设备也采到了数据。如果他只能把文件发回公司,等专家问清条件,再找开发改程序,工作就要经历一轮又一轮交接。第一轮回复到了,客户又补充一个装夹差异,前面的核对还得再做一次。
专家为什么总在重复了解现场
从“测出一个数”到“回答客户的问题”,中间有许多选择。客户准备用这个指标做什么决定?两次数据的基准、单位和采集条件是否相同?曲线出现差异时,应该先查装夹、重测,还是调整指标定义?
这些信息分散在不同人手里。现场工程师知道刚才发生了什么,专家知道哪些变化会影响结论。问题每转述一次,就可能丢掉一项条件;专家每接手一次,又要把条件重新拼起来。
于是,一部分看起来像“专家不够用”的问题,实际消耗在重复恢复现场上。如果交接方式没变,新增专家也得反复补齐这些材料。
AI 可以先帮忙补齐这些材料。助手按既有方法追问缺失条件,取得获准使用的数据,完成常规对照,并把不能解释的差异连同依据交给专家。至于差异是否具有工程意义、候选指标能否用于验收,仍需相应的专业判断。
企业提供支持时,也要把岗位权限和接手责任安排清楚。例如,员工可以比较两次数据,设备参数的修改仍由具备权限的人员确认。方法、资源和接手人都明确,员工才知道自己可以推进到哪里。
公司应当把可用的帮助送到员工手里
资料在哪里,哪段计算可以复用,工具需要什么权限,这些工作如果仍由员工逐项摸索,集成和核验的负担就落在了现场。
麦睿菱从事精密测量设备制造[4],也是 MEASIX 软件套件的发布方。MEASIX 希望支持的,是由公司先把这些准备做好,再交给员工使用。围绕一项真实任务,公司预先准备可以使用的工具、整理过的方法、相应的数据访问范围,以及配置好的助手。如图1,员工带入现场事实,使用这些支持推进获准的工作,有价值的新发现再交给专业团队判断。

图1|公司准备支持,员工推进任务,专业团队验证和整理有用的改法
以曲线比较为例,助手应当知道先核对哪些条件,能找到约定的计算工具,并在资料不全时停下来追问。企业提供的工作说明,可以按 Skill 这样的方式组织:把适用条件、步骤、检查点和必要的示例放在一起,供助手按任务使用。[1] 专业团队用约定样本核对算法,再请同岗位员工按说明复现;确认适用条件和维护人后,才在这个范围内复用。
当助手能结合当前结果选择查资料、调用工具或向人补问,通常就会被称为智能体,也就是 Agent。模型之外的工具、指令与运行过程,决定了它能否实际推进工作。[2] 对使用者来说,更重要的问题是:这次任务缺哪项材料,助手能完成哪一步,遇到什么情况该请谁加入。
这也是 MEASIX 产品分工的出发点。枢策 Orchelm 是企业智能体治理与协同平台,用来组织和发布企业准备的模型、工具与助手配置;领航 Pilot 是内置完整智能体能力的移动应用,能在移动端组织多步任务、调用获准工具,让员工带入现场事实并使用企业准备的支持。[3] 小睿是贯穿套件的统一助手形象与交互角色。企业通过部署和授权,把可用的工具与方法配置给相应岗位。
移动端的任务组织与公司的专业准备要相互配合,员工才能从当前问题继续,而不必逐项寻找资料和接手人。
员工可以参与改进方法
共用的方法能让现场的差异更容易被看见。读取数据、核对单位、运行已有算法,不必每次重来。员工因此能把注意力放在真正变化的地方:客户为什么提出新指标,原方法在哪种条件下不够用,新旧结果分别解释了什么。
设想原来的指标只反映曲线的最高点与最低点之差。两条曲线的这个数值相同,其中一条每圈起伏一次,另一条每圈起伏两次。客户关心周期性差异,原来的数就回答不了他的问题。
如果现场员工可以调出两次原始数据,核对条件,再使用获准的工具比较候选指标,他交给专家的就不再只有一句“客户想增加功能”,而是一个可以讨论的问题:原指标丢掉了什么信息,候选方法补充了什么,还存在哪些解释不清的情况。
员工贡献对客户用途和现场变化的理解,专业团队补上测量定义、算法检验与适用边界。双方围绕同一份可核查的材料合作:专家据此检查定义和算法,员工则能指出结果是否回答了客户的问题。
一次探索结束后,企业还要作出选择。有些改法只适合当前客户,保留完整记录就够了;有些值得经过验证、整理和维护,更新为员工下次能调用的方法和工具。下一位员工再遇到相近需求时,就可以从已经确认的部分继续。
哪一项工作值得先试
这种做法也有成本。整理方法、准备样本、维护工具和安排专家核验,都需要投入。对于一年只发生一次、条件高度特殊的问题,直接请专家处理可能更合算。对于步骤固定、计算确定的工作,常规软件或确定性算法也可能是更简单的选择。[2]
更适合起步的任务,往往同时具备几项条件:需求会反复出现;员工掌握重要的现场事实;企业已经有一些可用方法和工具;结果能够通过样本、对照或复测核查。客户测量指标的调整,就可以从这些条件逐项检查。
试点时,可以选出一组有代表性的真实任务,在相近难度和同样质量要求下,看员工能否完成更多有证据支持的步骤。同时记录准备、核验和维护所用的工时,避免只看到现场节省的时间。除了助手的使用次数,还应记录:
-
员工独立推进到了哪一步,哪些决定仍由专家承担
-
专家有多少时间花在补材料,多少时间用在判断新问题
-
一项要求经过多少轮往返,才得到可以核查的结果
-
换一位具备同等岗位资格的同事,能否按保留材料复现
其他岗位也可按同样方式检查:哪些准备适合集中提供,哪些事实必须由当事人补齐,什么结果才允许交付。
选第一项试点时,先说清想让哪一类员工得到什么支持、多完成哪一段工作。再用下一次相近需求检查:他能否更快取得依据,专家是否少做了重复准备,最终结果能否复核。
参考阅读
[1] Agent Skills:格式规范
[2] Anthropic:Building effective agents
[3] MEASIX:枢策 Orchelm、领航 Pilot与关于 MEASIX
[4] 麦睿菱:公司简介
特别授权:敏捷开发(SCRUM)系列文章特授权上海火速转载使用并应用到研发项目“火速智卓-用心连接企业员工的微信企业号应用平台”的管理中。 小规模研发团队的敏捷开发(SCRUM)全集
JQuery+FlexiGrid+asp.net完美解决方案-开源项目dotNetFlexGrid,构建快速的Ajax应用程序[官网][下载]。
浙公网安备 33010602011771号