AI写PLC分几级？五级能力模型划分从代码生成到工程智能体

1. 先从一个翻车场景说起代码生成了并不等于会干活前阵子半夜一个朋友在微信群里发了张截图语气难掩兴奋AI生成的三菱FX系列电机启保停程序梯形图清清楚楚指令也规范编译零报错。下面还跟了一句——AI马上要干掉PLC工程师了。群里好几个搞电气的都点了赞。我当时没泼冷水第二天把这程序拉进GX Works、下载到实训箱上试了一下。按下启动按钮接触器正常吸合松开后自保也有效。看起来确实没问题但等我模拟急停和热继电器过载的工况时问题全暴露了程序里只处理了启动和停止两个按钮急停信号根本没单独接入逻辑热继电器辅助触点居然被AI默认并进了停止回路而不是做硬互锁的外部保护。对老电工来说这种接法在某些设备上是可能出安全事故的。这个例子特别典型。AI确实能生成语法上完整的PLC程序但语法正确和能上设备干活中间隔着一整个工程维度硬件接线方式、安全规范、工艺时序、异常分支、地址规划、扫描周期影响、通信组态……每一项都会让一段看起来完美的代码在真实设备上翻车。但问题还出在另一个层面——现在业内对AI能不能写PLC程序的评价几乎两极分化。你用AI写一段电机启保停觉得AI已经很强了我拿AI去生成一套西门子S7-1200的PID温控逻辑发现它连该用PID_Compact还是PID_3Step都判断不了于是觉得AI纯属玩具。两个人的结论都来自真实体验放在一起却完全相反根源在于缺少一个统一的标尺。RealPLC这次正式提出的PLC Coding五级能力模型想解决的就是这个语言不统一的问题。它把AI在PLC领域的能力从L1到L5做了一个分层定义核心观点很直接AI能生成PLC代码只是最基础的L1往上的每一级能力和门槛都会出现数量级的变化。这篇文章我想结合自己实际测试和用AI辅助做项目的过程把这个模型掰开揉碎讲一讲也顺便聊聊它对普通电气工程师意味着什么。2. PLC Coding五级能力模型从代码生成到工程控制的完整进化链先说结论这五级不是随意划分的每一级的跃迁本质上都是AI对工程对象的理解深度的跃迁。代码只是表面载体真正决定级别的是AI能不能理解硬件、能不能理解工艺、能不能理解设备整个生命周期里发生的一切。先看一个五级总览表后面再逐级拆。级别名称核心能力工程理解程度当前成熟度L1代码生成器根据明确指令输出语法正确的程序片段只理解指令→代码的映射已实现通用大模型均可达L2模块化开发助手开发可复用的FB/FC理解接口设计支持多重实例调用理解程序内部的结构化组织部分实现需人工强引导L3工程级协作者理解硬件组态、符号表、全局数据块、跨模块交互生成符合完整项目约束的代码理解一个PLC项目的全貌探索阶段存在明显瓶颈L4调试与优化者在线监控变量、分析趋势、辅助PID整定、定位故障、优化扫描周期理解设备运行时的动态状态未落地受限于闭环数据通道L5自主工程智能体从需求规格书到硬件选型、程序开发、仿真验证、现场调试、竣工文档全流程独立完成具备控制工程师的全生命周期思维远未实现属于方向性定义这套模型有几个地方我觉得设计得很准。第一它没有把代码生成的准确率当成最重要的衡量指标因为那只是L1的核心。第二它把硬件上下文项目上下文运行时上下文按层级分布每一级对应一种对工程对象的建模能力。第三它明确把调试优化放在了L4比写完整项目代码的L3还要高一级——这个定位很符合真实工程逻辑因为在现场干过的人都知道能让设备稳定跑起来的人比能写出一堆语法正确代码的人值钱得多。从L1到L5眼界的维度也完全不同。L1只看单段代码L2看程序内部结构L3看整个PLC项目L4看运行中的设备L5看的是整个工程生命周期。这也是为什么RealPLC会说AI写PLC程序只能算L1——大多数人现在体验到的AI辅助编程恰恰停留在最底层。3. 逐级拆解每一级到底能做到什么程度3.1 L1只有一个动作把需求翻译成代码片段L1是当前所有通用对话式AI天然具备的能力。你说用三菱FX3U写一段电机启保停程序它很快就能给你一段指令表或者梯形图逻辑。语法基本正确常用的X0、X1、Y0这类地址也能猜个大概编译基本能过。但你稍微多测几个场景L1的边界就露出来了。我实际用市面上的主流大模型测试过几个基础场景比较有代表性的问题是热继电器过载保护应该怎么接入程序。AI给我的答案五花八门有给常闭触点串进停止回路的有给常开触点并在输出线圈上的很少有几个能明确提出过载保护通常需要在硬接线上串入接触器控制回路程序里只做状态监视和故障保持。这个区别就是有没有工程安全意识的分水岭。另一个问题是地址规划。AI经常会把输入输出地址写得非常随意比如把急停放在X2把启动放在X3但实际设备上急停接的是X0。L1的AI不会主动问你你的硬件接线是什么样的它只会按照最常见的猜测生成代码。在你的需求和实际硬件恰好吻合时它表现得很聪明一旦出现偏差它就变成一个很自信的胡编器。我个人的判断是L1的本质就是个高级翻译器它把人类语言翻译成PLC编程语言但对PLC所连接的物理世界没有概念。它不知道接触器线圈需要并联RC吸收回路不知道开关电源的地要处理不知道输出点接感性负载要考虑续流。这些知识不在L1的评价范围内但恰恰是PLC工程师真正值钱的地方。3.2 L2的关键跃迁从写代码到设计功能块L2比L1高一级的地方在于AI开始理解程序不只是ROI一条线执行完就结束的东西它需要被组织、被封装、被复用。举个例子你让AI做西门子S7-1200的程序要求写一个FB用来控制电机启停然后在OB1里调用三次分别控制三台电机并且把三台电机对应的输入输出作为FB的接口参数传入。这种需求L1级别的AI基本做不好——它会写出一个能控制单台电机的FB但调用时要么把地址写死要么形参实参对应不上甚至可能告诉你西门子的FB不支持多重背景数据块。而L2级别的AI可以理解多重实例的概念知道每次调用都要分配独立的背景DB否则内部数据会互相覆盖。这里多说一句热词里那个西门子PLC多重实例。很多刚接触结构化编程的工程师会困惑为什么要在FB里调用另一个FB直接全局调用不行吗其实多重实例的核心价值在于数据隔离和资源优化——多个背景实例可以共享一块数据存储区域而不是每个实例各自占用一个全局DB。对于大型项目来说这种区别直接关系到内存占用和程序的维护效率。AI如果能正确理解并生成多重实例相关的代码说明它对PLC程序结构化的理解已经进入了L2水平。但L2有一个很现实的限制AI依然高度依赖用户的详细描述。你得告诉它电机数量、输入地址、输出地址、保护逻辑要求、是否有急停、是否有故障复位。如果用户描述不完整AI不会主动去追问——它通常只会按照最合理的默认假设生成代码。所以L2阶段的人机关系是AI提供方案人提供上下文相当于你雇了一个基础不错但完全没现场经验的实习生必须把需求讲到位他才能把活干对。3.3 L3的分水岭真正接管一个PLC项目的上下文L3是绝大多数初级PLC工程师正处的位置也是AI目前最难过的一道坎。L3的核心能力是什么不是写一段代码而是理解一个完整的PLC项目包含什么。这几个字背后的工作量非常大硬件组态里有哪些模块、每个模块的IO地址范围是多少、符号表里有哪些变量、全局DB里存了什么数据、哪些功能块之间需要共享数据、通信协议怎么配置、远程IO从站挂在哪个网段、探测不到设备时程序该怎么处理……这些都在项目上下文的范畴里。以热词里那个非常典型的场景来说西门子PLC与3台变频器的三段速控制。这个题目看起来不难但它根本不是三段独立的启保停程序拼在一起。真正的工程设计需要先回答一串问题变频器是端子控制还是通信控制三段速是用三个DO点分别对应三种速度频率还是用两个DO点做二进制编码输出正反转是否需要变频器故障信号是接到PLC的数字量输入还是通过通信报文读取加减速时间和频率值存放在哪里操作员能不能在触摸屏上修改这些问题任何一个L1级别的AI都无从下手因为它们背后是硬件选型、电气图纸、工艺需求三者的综合权衡。比如我第一次给一个水处理项目做这类控制时为了省IO就是用2个DO输出做3段速编码外部接三个继电器再去变频器的多功能端子。如果我直接把这个需求丢给AI而不告诉它只能用两个DO它大概率会生成三个独立的频率选择输出——代码逻辑没错但硬件上根本不够用。反过来如果AI真的能基于项目描述建立完整的上下文模型知道当前这个项目的硬件组态和符号表知道哪些地址已经被占用知道变频器的控制方式那么它生成的代码就不再是一段正确代码而是一个正确的项目零件。这个跨越非常重要也是RealPLC把它定义为L3的原因。当前的大模型还做不到核心原因不是模型智商不够而是它们压根没有接入TIA Portal、GX Works这些IDE的工具链拿不到项目级的结构化数据。3.4 L4是从写程序的人变成调试设备的人L3管把程序写对L4管让设备稳定跑起来这中间差的是一整个现场调试能力。调试是什么是你把程序下载进PLC发现电机启动后抖动然后你要判断是接触器的问题、程序扫描周期的问题、还是急停回路接触不良是你看着趋势图里的温度曲线超调30%要决定是调低P值还是加微分限幅是三台变频器同时启动时总闸跳了你要分析是不是启动时序没做错峰。这些东西没有代码语法可查全凭对设备运行状态的实时理解。案例特别典型的是热词里的三菱PLC如何自整定PID参数。很多工程师觉得PID整定就是给一组好用的参数实际上PID参数严重依赖现场对象的特性。同样是100度的温度控制如果是一个热惯性很大的烘箱P要调得很小、积分时间拉长还要加微分抑制超调如果是一个响应很快的电加热水槽P可以大一些积分时间也要短。AI如果只停留在代码生成层面它能给你的是PID指令的调用模板比如FX3U里PID指令的操作数怎么填、采样时间怎么设、PID结果去哪里读但它给不了一组真正能用的P、I、D数值——因为它看不到你的温度曲线。L4要求AI能访问PLC运行时数据能监控变量变化能在一轮又一轮的参数调整中观察响应、对比效果、迭代方案。这已经不是语言模型生成代码的问题了而是一个闭环控制问题。AI需要长出一双眼睛——要么通过在线连接直接读取PLC变量要么通过仿真模型获得系统响应。当前市面上几乎没有产品做到这一点这也是为什么我把L4当作AI从离线工具变成在线伙伴的分水岭。顺便说一句很多人以为PID自整定就是自动给出参数值其实三菱FX系列自带的PID指令本身就有自整定功能通过指定动作方向等参数但工程上真正好用的自整定是临界比例度法或阶跃响应法——让系统先出现等幅振荡读临界增益和临界周期再按公式折算PID参数。这个过程需要对变量趋势做持续采样分析恰好是L4最典型的能力场景。3.5 L5是完整工程闭环无法速成L5的定义很宏大从需求规格书开始完成硬件选型、电气原理图设计、PLC程序开发、HMI画面组态、仿真验证、现场调试、验收报告、运维手册的全流程并且在多个项目中持续积累经验、优化控制策略。这已经不是一个会写PLC程序的AI了而是一个真正的控制工程师。它既要有扎实的电气基础知识选断路器、算负载、选传感器量程又要有工艺理解能力这罐体是干嘛的、反应温度区间是多少、搅拌转速变化对反应的影响还要有现场沟通能力甲方说不行你调一下试试时能快速定位问题方向。我目前不认为L5在可预见的未来能完全实现原因有三个。第一工程领域的know-how高度隐性化很多经验根本写不进文档只在老师傅的脑子里和多年的现场直觉里AI没有学习这些知识的语料第二企业数据孤岛严重每家工厂的工艺参数、故障记录、调试报告都是私有数据就算AI需要这些数据来迭代也没有一个机制能低成本地获取第三责任边界问题——一套完全由AI设计并调试的生产线出了事故谁能承担这个责任这不仅是技术问题也是工程伦理和法律问题。但把L5当作一个方向性定义非常有价值它告诉我们AI在PLC领域的终极形态是什么也帮我们看清了现在每个工具处在什么位置。4. 用热词里的真实场景告诉你各级差距究竟有多大光讲模型太抽象了我直接从热搜和热词里挑几个典型场景来分析。这些词不是随便火的它们恰恰反映了PLC从业者每天真正会遇到的问题。先看这个西门子PLC与3台变频器的三段速控制电路详解。我之前接过的某个小型送料项目就是这个结构一台S7-1200控制三台变频器每台变频器有三个固定速度档位通过PLC数字量输出点控制变频器多功能端子切换。当时为了省柜内空间和IO模块方案改成了每个变频器只用两个DO点通过二进制的组合表达三个速度档00停止、01低速、10中速、11高速。编码逻辑简单但程序里要在DO输出之前做一次二进制译码映射同时还得考虑变频器故障信号的汇总接入——三台变频器的故障继电器触点串联成一个DI点任何一个变频器报故障PLC都能收到信号。这种工程结构放到AI五级模型里看差别特别明显。L1的AI看到三段速控制会非常自然地生成三个独立的M0.0、M0.1、M0.2控制三个Q点输出每个Q点对应一个速度。逻辑上说得通可惜不是我的硬件结构。要让它生成基于两个Q点二进制组合的程序它就得先理解硬件约束——这已经是L3的上下文建模范畴了。而且这类项目还要考虑变速瞬间会不会导致机械冲击正反转切换需不需要先停稳再启动启动时三台变频器要不要错峰这类工艺时序问题那就更需要L3以上的工程经验了。再看第二个热词西门子PLC多重实例。多重实例是个非常典型的L2知识。它牵扯到FB/FB嵌套调用、背景数据块共享、局部变量与全局变量的区别。我测试过让AI解释多重实例的概念大多数模型都能说得头头是道但让AI实际生成一段使用多重实例的代码经常出现的问题包括背景DB声明方式不对、INOUT参数和TEMP变量混用、嵌套FB时没有正确声明Static区域。这说明AI的纸上知识和实际编程能力之间还有明显缝隙L2的成熟度并没有我们想象中那么高。第三个场景是三菱PLC的PID自整定。我见过很多工程师第一反应是AI帮我算PID参数。实际上AI目前能做的仅仅是告诉你PID指令的格式、参数地址的排布、采样时间怎么设、输出值怎么限幅。做不做得了自整定做不到因为它看不到实时曲线无法判断有没有超调、振荡周期是多长、稳态误差是否存在。这个场景恰好把L4的运行时数据访问能力和之前所有层级的差距拉得很清晰——代码写得再多没有反馈闭环就只能盲调。从这三个场景能看出一个共性AI在PLC领域的能力停滞在哪一级不取决于它背了多少手册而取决于它能否拿到对应级别需要的工程上下文。没有硬件信息它只能L1没有结构化编程的交互训练它到不了L2拿不到项目符号表和硬件组态L3永远在及格线徘徊没有运行时数据L4无从谈起。5. 当前主流AI在PLC领域实测到底停在哪个级别这一节我不想空谈直接把我的实测结果列出来。测试对象包括几款主流通用大模型和一些号称AI编程助手AI PLC代码生成的垂直工具测试任务覆盖了热词里出现频率比较高的几个方向。测试任务涉及级别实测表现用三菱FX3U写电机启保停程序L1很好指令正确能编译但缺少急停/过载保护逻辑生成西门子S7-1200的多重实例FB调用L2及格线边缘结构对细节经常错背景DB声明和TEMP变量使用编写C#与西门子PLC通信S7协议的上位机代码L1~L2优秀因为这类代码在开源社区极多AI训练语料非常充足生成一个完整项目的符号表和变量规划L3很差经常编造不存在的地址无法结合IO模块数量做地址分配根据触摸屏需求生成HMI报警文本和变量映射L3一般文本类任务可以但涉及协议变量映射时容易出错解释一段复杂梯形图的执行逻辑并定位潜在隐患L2尚可能看懂逻辑但对扫描顺序和多线圈问题的敏感度不足辅助PID整定根据响应曲线给参数建议L4完全不达标它无法读取曲线数据只能给教科书式的建议结论很明确当前一流大模型在实际PLC场景中的稳定水平大致在L1到L2的中间地带。它在标准代码生成和公版逻辑解释这两类任务上表现最好因为训练语料里类似内容最多一旦进入地址规划硬件约束感知项目级上下文这些场景性能就急剧下降。有一个容易被忽略的点是训练语料的结构偏差。互联网上关于西门子S7-1200的PID_Compact调用三菱FX系列RS指令做MODBUS通信的教程和示例代码非常多所以AI在这些高度标准化、高度通用的知识点上表现很好。但真正有价值的工业项目代码通常不会公开发布AI根本没见过这就注定了它的上限被锁死在通用知识区间内。热词里还有unity与西门子PLC通信C#和西门子PLC通讯这类应用需求AI表现非常好也印证了这一点——上位机通信是软件开发者扎堆分享代码的领域AI学的样本足够多。但学过的内容多和具备工程能力完全是两回事。我做了一个专门测试给它一个西门子S7-1200的项目情境包含一个数字量输入模块、一个数字量输出模块、一个模拟量输入模块要求它规划出完整的IO地址表、符号表并写一个与硬件配置匹配的电机启停和温度采集程序。结果AI给出的地址表直接和实际模块地址冲突SM1000这种编造的模块地址都冒出来了。这说明它没有真正理解PLC项目里每个地址背后对应一个物理通道这件事。这个差距要弥补靠的不是更大的模型而是让AI真正的接入工程数据源。6. 在你的PLC开发工作流里AI现在能怎么用虽然AI离L3还很远但完全否定它的价值也是不对的。关键是要清楚地知道它擅长什么、不擅长什么然后把它安排在合适的位置上。我现在用AI辅助做PLC项目的固定套路是这四个方向供你参考。第一个标准代码生成与速查。需要写MODBUS RTU通信初始化程序、需要查某条PID指令的操作数格式、需要生成一段CRC16校验代码——这种事丢给AI效率极高。它给出的版本可能不是最优的但作为起点要比从零翻手册快很多。我一般会要求它同时输出该指令的典型应用场景、参数含义、常见错误排查三个维度把它当一个人肉搜索引擎加初级编程员用。第二个代码review。把AI当成一个没下过现场的同事让它检查一段代码看有没有明显的数据类型不匹配、变量未声明、输出线圈在不同网络里被重复赋值这类问题。它对语法层面问题的嗅觉很准但你要在输入里先告诉它不要考虑硬件约束只做静态逻辑检查这样它能集中精力发现逻辑漏洞。如果你发现它找出来的问题全是无关痛痒的格式问题说明这段代码逻辑上真没什么大毛病。第三个文档生成和注释补全。PLC项目最烦的事情之一就是写说明文档。我会把写好的程序块贴给AI让它生成功能描述、输入输出说明、调用逻辑、维护注意事项这几段文字然后自己审一遍改一改。这项工作不需要AI理解设备现场只需要它理解程序本身正好落在它的舒适区里。第四个上位机通信代码。热词里LabVIEW与松下PLC串口通讯unity与西门子PLC通信C#与西门子PLC通讯这类任务AI完成度非常高。因为这些是IT与OT交叉领域代码样本极多而且通信逻辑相对标准化。可以说在边缘接口开发这件事上AI已经能帮你省掉一半以上的时间。但有两类任务我现在坚决不让AI碰。第一类是涉及安全逻辑的程序比如急停回路、安全门联锁、光栅保护第二类是涉及工艺参数计算和时序协调的核心逻辑。这两类任务接管者的一个错误可能直接造成设备损坏或人身事故AI现在的可靠性撑不起这个责任。如果你想用它做初稿必须加一个硬性检查清单自己逐项对照。我自己常用的检查项是这些急停、限位、安全门是否都为硬件硬接线保护且程序内做了互锁所有输入输出地址是否与硬件组态符号表一致有没有AI编造的地址模拟量通道的量程、数据类型、工程量转换系数是否正确通信协议帧格式、从站地址、奇偶校验位是否符合手册是否考虑了上电初始化、故障复位、停机状态下的输出清零功能块调用的背景数据块是否独立是否发生了数据覆盖程序扫描周期内有没有多个网络对同一个线圈输出赋值这套清单救过我很多次。有一次AI生成的一段S7-1200程序里同一个Q点在不同OB里被输出了两遍编译和下载都没报错但实际运行时输出状态不可控——这种坑完全是程序结构问题靠静态检查根本发现不了必须有在工程现场干过的经验才能意识到。分享一个我目前用着还算顺手的prompt模板核心是尽可能把上下文信息一次给足而不是让AI反复猜请帮我编写一个西门子S7-1200CPU 1214C DC/DC/DC的FB功能块功能如下功能控制一台三相异步电机的启停支持本地/远程模式切换输入启动按钮I0.0常开、停止按钮I0.1常闭、远程启动命令M0.0、远程停止命令M0.1、热继电器状态I0.2常闭输出电机接触器Q0.0要求本地/远程信号为高时禁止启动停止优先级最高热继电器动作后输出锁定直到复位按钮I0.3触发背景数据块命名DB_Motor1请生成FB内部梯形图描述或SCL代码并在OB1中给出调用示例 注意不考虑通信仅做单机逻辑。请先列出你理解的地址分配表再写程序。用了这种模板之后AI生成的代码质量明显提升因为它终于能在一开始就构建出这个项目里有哪些变量、哪些是输入、哪些是输出的上下文模型——虽然这个模型只局限于你喂给它的信息但至少它不再凭空乱编了。7. 从AI写PLC到AI做工程还有哪些断点要打通说了这么多最后把眼光放远一点。如果AI真的要往L3、L4走有几个断点不打通就永远只能停留在辅助工具的位置。第一个断点是符号表和硬件组态的双向同步。现在AI不认识你的硬件组态不认识你的符号表它只能在文字层面碰运气。如果TIA Portal的Openness接口、GX Works的工程文件解析能力能向AI工具开放让AI直接读取项目里的模块配置和变量地址那L3的突破就有了基础底座。不是让AI从零去学一个项目而是让AI直接看到项目本身。这一层打通之后AI至少能回答这个项目里I4.0被占用了没有Q2.3接到了什么负载这类基础问题而不是靠猜。第二个断点是运行时数据的访问闭环。L4要求AI能看到设备运行时的变量趋势这就要求PLC在运行时把数据同步给AI服务——走OPC UA、走S7协议直连、走边缘网关都行。一旦这个通道打开AI就能基于真实的阶跃响应曲线给PID整定建议能根据故障发生前后的变量序列辅助排查问题能在电机电流异常增大时提前预警。这个方向已经有一些工业互联网平台在做了只是目前大多停留在数据可视化层面还没到AI根据数据行动的阶段。第三个断点是工艺知识的结构化沉淀。每一条产线都有自己的工艺逻辑AI想要做L5的自主工程必须先积累这个车间的反应釜升温速率通常是多少这个厂的水泵启停最少间隔时间是多久这样的工艺事实。这些东西不在任何标准手册里存在于企业自己的运行数据和师傅的经验中。没有一套机制去采集、清洗、标注这些知识AI对工艺的理解就永远是空的。现在行业内大家都在讲数据中台但真正把工艺know-how做成AI可用语料的案例还非常少这恰恰是把会写程序的AI升级成会干工程的AI最值钱的方向。第四个断点是工业软件生态的开放性。CODESYS、TIA Portal、GX Works这些开发环境目前对第三方的集成支持程度参差不齐。如果AI要真正成为IDE里的一个原生能力而不是外挂一个聊天窗口就需要这些工具厂商开放工程文件格式和组态数据接口。TIA Portal的Openness已经开了个口子但相对整个PLC市场来说还远远不够。这已经不单纯是AI技术问题了而是整个工业软件生态的工程方式问题。对普通工程师来说这套五级模型还有另一层价值它可以当一面镜子照出你自己的能力处在什么位置。如果一个人只会根据别人的电路图写对应的程序那他做的其实是L1级别的活这类工作确实更容易被AI冲击如果他能独立完成一个小型项目的硬件选型、程序架构、现场调试那他已经站在L3的位置如果他能根据设备运行状态反推工艺问题、优化控制策略那他已经是L4级别的人了。AI现在能替代的主要是L1的重复劳动而L3以上所需要的现场判断力、工艺理解力、责任承担能力在很长一段时间里仍然是工程师真正的护城河。我自己这几年带过不少新人最大的感受是工具一直在变从继电器逻辑到PLC从梯形图到SCL现在又来了AI——但真正拉开人与人差距的从来不是你会用哪个版本的工具而是你能不能在设备出问题时快速判断出问题出在硬件、程序、通信还是工艺上。AI暂时抢不走这个能力但它会加速淘汰那些只会按图索骥、不肯理解工程本质的人。趁现在多去现场待一待多看点设备实际运行的样子这比焦虑AI会不会取代我有用得多。