1. 从一条产线说起为什么AI编程和PLC会被放在一起聊前阵子跟几个做工业自动化的老朋友吃饭席间有个干了十五年PLC的工程师突然冒出一句“你们发现没有现在搞AI编程的那帮人走的路子跟咱们当年搞PLC简直一模一样。”桌上几个人愣了一下然后越聊越觉得这话有道理。我回去之后把AI编程助手、AI Agent、代码生成工具这些近两年的热门方向重新捋了一遍发现这个类比不是随口一说而是切中了当前AI编程领域几个非常核心的痛点。PLC也就是可编程逻辑控制器在工业现场已经跑了几十年。它的核心逻辑是什么是把一套确定性的控制流程用结构化文本、梯形图或者功能块图表达出来然后交给一个稳定可靠的运行时去执行。工程师不需要关心底层寄存器怎么分配、扫描周期怎么调度只需要把逻辑写对剩下的交给PLC的运行时环境。这套思路支撑了现代工业自动化的整个底座。再看今天的AI编程尤其是那些主打“从零开始能用”的AI编程助手和AI Agent工具它们在做的事情本质上也是同一件事把人的意图翻译成机器能执行的指令然后在一个受控的环境里跑起来。区别在于PLC翻译的是控制逻辑AI编程翻译的是业务逻辑。但两者面临的核心矛盾惊人地相似——如何让非确定性的人类意图变成确定性的机器执行。这个标题“AI编程正在重走PLC的路”说的就是这件事。它不是一个技术对比文章而是一个行业观察AI编程正在从“炫技阶段”进入“工程化阶段”而PLC几十年的工程化经验恰好是一面镜子。这篇文章适合所有正在用AI编程工具写代码的人、正在做AI编程产品的人以及那些从工业自动化转过来看AI编程的人。我会从结构化文本、Zero、MoonBit这些关键词切入把这条“重走的路”拆开来讲清楚。2. 结构化文本AI编程和PLC共享的底层语言观2.1 为什么结构化文本是两者的交汇点先说说结构化文本。在PLC的世界里结构化文本是一种高级编程语言语法上接近Pascal或者C但它被设计出来的目的非常明确用人类可读的方式描述控制逻辑然后由编译器翻译成PLC能执行的指令。西门子的SCL、汇川PLC的Codesys环境、三菱的ST语言本质上都是结构化文本的不同实现。AI编程领域最近频繁出现“结构化文本”这个词原因在于大语言模型生成代码时最大的问题不是“写不出来”而是“写出来的东西结构不稳定”。你让AI写一个函数它可能给你三种不同的写法变量命名风格不一致错误处理逻辑时有时无。这在个人项目里还能忍但在团队协作或者生产环境里就是灾难。PLC行业几十年前就解决了这个问题。它的做法是用严格的结构化文本规范约束代码形态用统一的运行时环境保证执行一致性。你在博途里写SCL变量声明区、逻辑执行区、注释区都有明确的格式要求编译器会强制检查类型匹配和语法规范。这套约束看起来死板但它换来了极高的可维护性和可预测性。AI编程正在往这个方向走。你看现在那些AI编程助手比如Cursor、Windsurf、VS Code Copilot它们生成代码时越来越强调“结构化输出”。不是随便给你一段代码就完事而是按照函数签名、参数类型、返回值、异常处理这样的结构来组织。这跟PLC的结构化文本思路是一致的先定结构再填逻辑。2.2 结构化文本在AI编程中的具体落地方式具体到实操层面AI编程工具怎么实现结构化文本输出我拿一个实际场景来说。假设你要让AI帮你生成一个数据处理的管道函数早期的大模型可能会直接给你一段Python代码变量名可能是data、result、temp这种错误处理可能就一个try-except包住全部。但现在更成熟的做法是你先给AI一个结构化的模板比如def process_data( input_path: str, output_path: str, batch_size: int 1000, error_handler: Callable None ) - ProcessingResult: 处理指定路径的数据文件按批次写入输出路径。 Args: input_path: 输入文件路径 output_path: 输出文件路径 batch_size: 每批处理条数 error_handler: 自定义错误处理函数 Returns: ProcessingResult: 包含成功条数、失败条数和错误详情 # 逻辑实现区 pass你把这样的结构给AI它填充逻辑的准确率会大幅提升。这跟PLC工程师在SCL里先定义好功能块的输入输出引脚再写内部逻辑是一个道理。结构先行逻辑后填这是PLC几十年验证过的工程方法现在被AI编程领域重新发现了。注意结构化文本不是让AI自由发挥而是给AI一个“填坑”的框架。你给的框架越清晰AI填出来的东西越靠谱。这一点在PLC编程里是常识在AI编程里正在成为常识。2.3 从梯形图到提示词表达方式的演进与回归PLC编程有五种标准语言梯形图、功能块图、顺序功能图、指令表和结构化文本。其中梯形图最直观像电路图一样适合逻辑简单的场景结构化文本最灵活适合复杂算法和数据处理。AI编程的表达方式也在经历类似的演进。最早的AI编程就是“你写注释它补代码”相当于梯形图级别的直观操作。后来发展到“你写提示词它生成整个模块”相当于功能块图。现在最前沿的AI Agent比如那些能自主规划、执行、调试的智能体已经开始要求你用结构化的方式描述任务包括输入输出定义、约束条件、验收标准这已经非常接近结构化文本的思维了。我试过用AI Agent做一个数据清洗任务一开始只给了一句“帮我清洗这个CSV文件”结果它生成的代码跑不通因为没定义清楚“清洗”的标准是什么。后来我改成结构化描述输入是什么格式、输出要满足什么条件、缺失值怎么处理、异常值怎么判定它一次就生成可用的代码。这个体验跟当年从梯形图转到结构化文本的感觉一模一样——表达越结构化执行越确定。3. Zero和MoonBitAI编程的“运行时环境”意识觉醒3.1 Zero在AI编程语境下的含义热搜词里有个“Zero”还有“zerotool zero width detector”。在AI编程的讨论中Zero通常指代几种不同的东西。一种是“从零开始”的AI编程也就是不依赖现有代码库完全由AI生成项目骨架。另一种是Zero-shot编程即不给示例直接让AI根据描述生成代码。还有一种是指某些具体的工具或框架名字里带Zero。但不管哪种含义Zero这个词在AI编程领域的流行反映了一个共同诉求降低启动成本让AI从零搭建可运行的系统。这跟PLC的“从零开始”编程很像。一个PLC项目从零开始你需要先组态硬件、定义变量表、写功能块、调试通信最后下载到PLC运行。AI编程从零开始你需要定义项目结构、生成代码、配置依赖、跑通测试。问题在于PLC的“从零开始”有明确的工程规范你知道第一步做什么、第二步做什么。AI编程的“从零开始”目前还很混乱不同工具、不同模型、不同提示词出来的结果千差万别。这就是为什么“从零开始能用的AI编程”会成为热搜词——大家都在找那个能稳定从零搭建项目的方案。3.2 MoonBit带来的启示AI编程需要自己的“运行时”MoonBit是一个国产的编程语言和工具链最近在AI编程圈子里被频繁提及。它的特点是什么它提供了一套完整的工具链包括编译器、构建系统、包管理器、IDE支持而且对AI生成代码有专门的优化。换句话说MoonBit在设计之初就考虑了“AI会大量生成代码”这个场景。这跟PLC的运行时环境思路非常接近。PLC为什么稳定因为它的运行时环境是专门为控制逻辑设计的你写的代码只能在那个环境里跑环境保证了执行的一致性和可靠性。MoonBit在尝试做的事情是为AI生成的代码提供一个受控的运行时环境让AI写出来的东西有地方跑、跑得稳、出了问题能定位。我实际用MoonBit跑过几个AI生成的模块感受最深的是它的错误提示非常清晰。AI生成的代码如果有类型不匹配或者逻辑漏洞MoonBit的编译器会给出具体的行号和原因而不是像某些动态语言那样跑起来才报错。这种“编译期就把问题拦住”的思路跟PLC编程中“下载前先编译检查”的流程如出一辙。3.3 AI编程工具大比拼背后的运行时缺失热搜词里还有“AI编程助手大比拼Cursor、Windsurf、VS Code Copilot和Trae谁才是你的神队友”。这些工具我都深度用过各有优劣。Cursor的补全和重构很强Windsurf的Agent模式适合多文件操作Copilot跟VS Code的集成最顺滑Trae在某些场景下的中文理解更好。但它们有一个共同的短板没有统一的运行时环境。你在Cursor里生成的代码拿到Windsurf里可能跑不通因为依赖版本或者环境配置不一样。这就像你在一台西门子PLC上写的程序直接拷到三菱PLC上肯定跑不了因为运行时环境不同。PLC行业解决这个问题的方式是标准化。IEC 61131-3标准规定了PLC编程语言的语法和语义不同厂商的PLC只要遵循这个标准代码就有一定的可移植性。AI编程目前还没有这样的标准每个工具、每个模型都在用自己的方式生成代码导致“AI写的代码”成了一个黑盒。提示如果你正在用多个AI编程工具建议建立一个统一的代码规范和依赖管理流程。比如用pyproject.toml或者package.json锁定依赖版本用pre-commit钩子做代码格式检查。这相当于给AI编程搭一个简易的“运行时环境”能省掉很多跨工具迁移的麻烦。4. AI Agent与PLC编程自主性与确定性的平衡术4.1 AI Agent在编程中的角色定位AI Agent是近两年AI编程领域最热的方向之一。跟传统的代码补全不同AI Agent能自主规划任务、调用工具、执行代码、根据结果调整策略。你给它一个目标比如“把这个项目的测试覆盖率提到80%”它会自己分析代码、生成测试用例、运行测试、根据失败结果修改用例直到达标。这个过程跟PLC的自动控制逻辑有相似之处。PLC控制一个产线也是给定目标比如“保持液位在50%”然后通过传感器读取当前值、跟目标值比较、调整阀门开度、再读取、再调整形成一个闭环。AI Agent的“感知-决策-执行-反馈”循环本质上就是一个软件层面的闭环控制。但PLC的闭环控制是确定性的给定相同的输入永远得到相同的输出。AI Agent的闭环控制是非确定性的同样的任务今天跑和明天跑可能得到不同的结果。这就是AI编程“重走PLC的路”需要解决的核心矛盾——如何在保持AI自主性的同时引入PLC级别的确定性。4.2 从PLC的扫描周期看AI Agent的执行循环PLC有一个核心概念叫“扫描周期”读取输入、执行程序、更新输出循环往复每个周期的时间是固定的通常在毫秒级。这个固定周期保证了控制的实时性和确定性。AI Agent的执行循环目前没有固定周期。它可能花几秒钟分析任务花几分钟生成代码花更长时间运行测试。这个时间不确定性在编程场景下还能接受但如果AI Agent要控制真实的物理设备比如机械臂或者产线时间不确定性就是致命的。热搜词里有“plc管理六轴机械臂伺服”和“plc控制一拖三软启动器”这些都是对实时性要求极高的场景。AI Agent目前还进不了这些场景因为它的执行循环太慢、太不确定。但反过来想如果AI Agent能借鉴PLC的扫描周期设计把任务拆解成固定周期的子任务每个周期内完成确定性的操作那它就能进入更多实时场景。我试过用AI Agent做一个定时数据采集任务一开始它每次采集的间隔都不固定因为它在两次采集之间做了太多“思考”。后来我改成让它先规划好采集逻辑生成一个固定间隔的采集脚本然后让脚本自己去跑。这其实就是把AI Agent的“思考”和“执行”分离思考阶段可以慢执行阶段必须快且确定。这个思路跟PLC的“离线编程、在线执行”是一样的。4.3 AI PLC代码生成的实际案例热搜词里有“ai plc代码生成”和“ai plc编程”说明已经有人在尝试用AI生成PLC代码了。我实际测试过几个方案用大模型生成结构化文本格式的PLC程序比如西门子的SCL或者汇川Codesys的ST代码。效果怎么说呢对于简单的逻辑比如电机正反转、星三角降压启动、抢答器控制AI生成的代码基本可用逻辑正确语法也符合规范。但对于复杂的非标项目比如多轴联动、模拟量闭环控制、通信协议处理AI生成的代码就需要大量人工修改。问题出在哪里PLC编程不仅仅是写逻辑还要考虑硬件组态、IO映射、通信配置、安全互锁。AI目前只能处理逻辑部分硬件相关的配置它看不到也摸不着。这跟AI编程在通用软件领域的困境一样AI能写函数但搞不定整个系统的集成。不过有一个方向值得关注AI生成PLC代码的“模板化”思路。你先把一个标准的PLC项目模板给AI包括硬件组态文件、变量表、通信配置然后让AI在模板基础上填充逻辑。这样生成的代码可用性会高很多。这跟前面说的结构化文本思路是一致的——先给结构再填逻辑。5. 实操用AI编程工具搭建一个“PLC风格”的项目骨架5.1 项目结构设计借鉴PLC的工程化组织方式说了这么多理论来点实际的。我拿一个数据采集和处理的Python项目为例展示怎么用AI编程工具搭建一个“PLC风格”的项目骨架。所谓PLC风格就是结构清晰、职责分明、执行确定。PLC项目的典型结构是这样的硬件组态、变量定义、功能块、主程序、通信配置。对应到Python项目我设计成这样project/ ├── config/ # 相当于硬件组态 │ ├── settings.yaml │ └── logging.yaml ├── models/ # 相当于变量定义 │ ├── schemas.py │ └── types.py ├── blocks/ # 相当于功能块 │ ├── data_reader.py │ ├── data_cleaner.py │ └── data_writer.py ├── main.py # 相当于主程序 └── tests/ # 相当于调试和验证 ├── test_reader.py └── test_cleaner.py这个结构看起来简单但它强制你把代码分成“配置”、“定义”、“功能”、“执行”四个层次。AI在生成代码时你告诉它每个文件放什么它就不会把所有的逻辑都塞到一个文件里。5.2 用AI生成功能块代码的具体步骤第一步先定义变量和类型。在models/types.py里用AI生成数据模型from dataclasses import dataclass from datetime import datetime from typing import Optional dataclass class SensorReading: sensor_id: str timestamp: datetime value: float unit: str status: str normal dataclass class ProcessingResult: total_count: int success_count: int error_count: int errors: list[str]给AI的提示词可以这样写“生成一个Python dataclass表示传感器读数包含传感器ID、时间戳、数值、单位、状态五个字段状态默认值为normal。”这个提示词的结构化程度很高AI生成的代码基本不需要修改。第二步生成功能块。在blocks/data_reader.py里让AI生成读取数据的函数。提示词要包含输入输出定义和异常处理要求def read_sensor_data( source_path: str, batch_size: int 100 ) - list[SensorReading]: 从指定路径读取传感器数据。 Args: source_path: 数据文件路径支持CSV和JSON格式 batch_size: 每批读取条数 Returns: list[SensorReading]: 传感器读数列表 Raises: FileNotFoundError: 文件不存在 ValueError: 数据格式错误 # AI填充逻辑 pass第三步生成主程序。在main.py里让AI把功能块串联起来def main(): config load_config(config/settings.yaml) readings read_sensor_data(config[source_path]) cleaned clean_data(readings) result write_data(cleaned, config[output_path]) logger.info(f处理完成: {result.success_count}/{result.total_count})这个流程跟PLC编程的“组态-定义-编程-调试”四步法完全对应。你不需要一次性让AI生成所有代码而是分步骤、分模块地生成每一步都有明确的输入输出定义。5.3 参数计算与选择以批处理大小为例PLC编程里经常需要计算参数比如PID控制的比例系数、滤波器的截止频率、通信的超时时间。AI编程同样需要参数计算只是很多人忽略了这一步。拿批处理大小来说。假设你要处理一个10GB的CSV文件内存只有8GB批处理大小设多少合适简单计算10GB除以8GB至少需要2批但考虑到内存还要留给操作系统和其他进程实际可用内存可能只有6GB。所以批处理大小应该按6GB来算10GB除以6GB约等于1.67向上取整为2批每批5GB。但5GB的数据加载到内存后经过解析和转换实际占用可能翻倍所以更安全的做法是每批2GB分5批处理。这个计算过程看起来简单但很多AI生成的代码直接用一个固定的batch_size1000完全不考虑实际数据量和内存限制。你在给AI提示词的时候应该把计算过程也写进去“数据文件约10GB可用内存6GB解析后内存占用约为原始数据的2倍请计算合适的批处理大小并生成代码。”注意AI不会主动帮你算这些参数它只会按照你给的数字生成代码。参数计算是人的工作不是AI的工作。这一点在PLC编程里是常识在AI编程里经常被忽略。6. 常见问题与排查技巧实录6.1 AI生成代码跑不通的典型原因用AI编程工具时间长了你会发现代码跑不通的原因就那么几类。我整理了一个速查表按出现频率从高到低排列问题类型典型表现排查方法解决思路依赖缺失ModuleNotFoundError检查requirements.txt或pyproject.toml让AI生成依赖列表手动核对版本类型不匹配TypeError或AttributeError检查变量定义和使用处用类型注解约束AI生成范围路径错误FileNotFoundError打印当前工作目录和文件路径用绝对路径或pathlib处理逻辑漏洞结果不符合预期加日志分步验证把大函数拆成小函数逐个验证并发问题偶发失败难以复现检查共享资源访问加锁或改用消息队列这张表里的问题PLC编程里也都会遇到只是表现形式不同。依赖缺失相当于PLC的固件版本不匹配类型不匹配相当于IO信号类型配错路径错误相当于通信地址写错。排查思路是一样的先定位问题范围再逐步缩小最后验证修复。6.2 提示词工程的“梯形图思维”很多人写AI编程提示词喜欢写一大段自然语言描述。这种方式对于简单任务还行对于复杂任务就容易失控。我推荐用“梯形图思维”来写提示词把任务拆成一个个条件-动作对像梯形图的每一行一样。比如你要让AI生成一个数据校验函数不要写“帮我写一个校验函数检查数据是否合法”而是写成结构化的条件列表任务生成数据校验函数 输入SensorReading对象 校验规则 1. 如果sensor_id为空返回错误传感器ID不能为空 2. 如果timestamp早于2020-01-01返回错误时间戳过早 3. 如果value小于-100或大于1000返回错误数值超出范围 4. 如果unit不在[C, F, K]中返回错误单位不支持 5. 所有校验通过返回None 输出错误信息字符串或None这种提示词方式跟梯形图的“条件-动作”结构完全一致AI理解起来准确率极高。我实测下来用这种方式生成的校验函数一次通过率在90%以上而自然语言描述的通过率只有60%左右。6.3 从PLC调试中学到的AI编程调试技巧PLC调试有几个经典方法强制输出、单步执行、监控变量、分段排查。这些方法在AI编程调试中同样适用。强制输出相当于在代码里加print或者logger把中间结果打出来看。单步执行相当于用调试器逐行运行看每一步的变量值。监控变量相当于用watch窗口或者日志记录关键变量的变化。分段排查相当于把程序分成几段每段单独测试。我特别想说的是“分段排查”。AI生成的代码往往是一个大函数里面几十行逻辑。跑不通的时候你很难一眼看出问题在哪。我的做法是让AI把大函数拆成几个小函数每个小函数只做一件事然后逐个测试。这跟PLC编程里把复杂逻辑拆成多个功能块是一样的道理。拆开之后问题定位时间能从半小时缩短到五分钟。提示让AI拆函数的提示词可以这样写“把这个函数拆成三个子函数第一个负责数据读取第二个负责数据转换第三个负责数据写入。每个子函数不超过20行有明确的输入输出。”7. 工具选型AI编程助手在“PLC风格”项目中的适配度7.1 主流AI编程工具对比热搜词里提到了Cursor、Windsurf、VS Code Copilot和Trae。我在“PLC风格”项目里都试过下面是对比工具结构化生成能力多文件操作运行时集成适合场景Cursor强中等弱单文件重构、代码补全Windsurf中等强中等多文件Agent任务VS Code Copilot中等弱强日常编码、快速补全Trae中等中等弱中文场景、教学用途“结构化生成能力”指的是按照你给定的模板生成代码的能力。“多文件操作”指的是同时修改多个文件的能力。“运行时集成”指的是跟运行环境、调试器的集成程度。如果你要做的是“PLC风格”的项目也就是结构清晰、模块分明的项目Windsurf的多文件操作能力最有用因为它能同时修改models/、blocks/和main.py保持整体一致性。如果你只是写单个功能块Cursor的补全和重构更强。7.2 免费AI编程方案的可行性热搜词里有“免费的ai编程写代码”和“deepseek的api和c知道的ai编程哪个好用”。免费方案我试过不少说几个实际感受。DeepSeek的API在代码生成上表现不错尤其是中文提示词的理解很到位。但它的上下文长度有限生成大项目时容易“忘掉”前面的定义。C知道CSDN的AI编程助手在中文技术社区的场景下还行但生成代码的质量参差不齐。免费方案最大的问题是不稳定。今天能用的提示词明天可能就生成不出同样的结果。如果你只是做实验或者学习免费方案够用。但如果是生产项目建议还是用付费方案至少保证生成结果的一致性。7.3 从PLC工具链看AI编程工具的未来PLC的工具链非常成熟西门子有博途汇川有Codesys三菱有GX Works。这些工具集成了编程、编译、调试、仿真、下载所有功能工程师在一个环境里完成所有工作。AI编程工具目前还处于“单点突破”阶段每个工具只做一件事。Cursor做补全Windsurf做AgentCopilot做集成。未来大概率会走向整合出现一个“AI编程的博途”——集成了代码生成、结构检查、运行时管理、调试监控的完整环境。MoonBit在这方面走得比较靠前它的工具链已经包含了编译器、构建系统、包管理器和IDE支持。虽然它还不是专门的AI编程工具但它的设计思路值得关注。8. 从PLC的非标项目实战看AI编程的落地路径8.1 非标项目的核心挑战需求不确定PLC非标项目最大的特点是需求不确定。客户今天说要控制三台电机明天可能改成五台。今天说用西门子PLC明天可能换成汇川。这种不确定性对编程提出了很高的要求代码要能快速适应变化。AI编程面临同样的挑战。业务需求变化快今天要加一个字段明天要改一个流程。AI生成的代码如果结构不好改起来比手写还麻烦。所以“PLC风格”的项目结构在AI编程里特别重要——结构清晰的项目AI改起来也清晰。我做过一个对比实验同样的需求变更在一个结构混乱的项目里AI改了五处代码引入了三个新bug在一个结构清晰的项目里AI只改了两处代码没有引入新bug。差距就在于结构。8.2 从“一拖三软启动器”看AI编程的模块化思维热搜词里有“plc控制软启动器一拖三”和“plc软启动器一拖三接线实物”。一拖三的意思是一个软启动器轮流启动三台电机。这个场景的核心逻辑是同一时间只能有一台电机在启动三台电机按顺序轮换。这个逻辑用PLC实现就是一个状态机等待状态、电机1启动、电机2启动、电机3启动、循环。每个状态有明确的进入条件、执行动作、退出条件。这种状态机思维在AI编程里同样适用。比如你要用AI生成一个任务调度器不要让它直接写调度逻辑而是先让它生成一个状态机框架from enum import Enum class TaskState(Enum): IDLE idle RUNNING running PAUSED paused COMPLETED completed ERROR error class TaskScheduler: def __init__(self): self.state TaskState.IDLE self.current_task None def transition(self, new_state: TaskState): # 状态转换逻辑 pass def run(self): # 主循环 pass有了这个框架AI填充具体逻辑时就不会跑偏。这跟PLC编程里先画状态转移图、再写代码的流程是一样的。8.3 AI编程在工业场景的边界必须承认AI编程目前还进不了工业控制的核心场景。PLC控制机械臂、控制产线、控制安全互锁这些场景对实时性、确定性、可靠性的要求AI编程还达不到。但AI编程可以在工业场景的外围发挥作用生成数据采集脚本、生成报表工具、生成监控界面、生成测试用例。这些场景对实时性要求不高但对开发效率要求高正好是AI编程的强项。我个人的判断是AI编程和PLC的关系不是替代而是互补。PLC守住实时控制的核心AI编程负责外围的数字化工具。两者之间的桥梁是结构化文本——PLC用结构化文本写控制逻辑AI编程用结构化文本生成外围工具数据格式统一了集成就顺了。9. 我个人在实际操作中的体会踩过几次坑之后我最大的体会是AI编程工具再强也替代不了你对项目结构的思考。你可以让AI写函数、写类、写测试但项目怎么分层、模块怎么划分、接口怎么定义这些必须你自己想清楚。想清楚了AI是你的加速器想不清楚AI是你的放大器——放大混乱。另一个体会是PLC行业积累的工程化经验对AI编程有直接的借鉴价值。结构化文本、状态机、扫描周期、功能块、变量表这些概念在AI编程里都能找到对应物。如果你有PLC背景转AI编程会有一种“似曾相识”的感觉。如果你没有PLC背景花点时间了解一下PLC的编程思想对用好AI编程工具会有帮助。最后分享一个小技巧每次让AI生成代码之前先花两分钟写一个结构化的提示词把输入、输出、约束、异常处理都列清楚。这两分钟的投入能省掉后面二十分钟的调试时间。这个习惯我从PLC编程里带过来在AI编程里同样有效。
AI编程正在重走PLC的路：从结构化文本到运行时环境
1. 从一条产线说起为什么AI编程和PLC会被放在一起聊前阵子跟几个做工业自动化的老朋友吃饭席间有个干了十五年PLC的工程师突然冒出一句“你们发现没有现在搞AI编程的那帮人走的路子跟咱们当年搞PLC简直一模一样。”桌上几个人愣了一下然后越聊越觉得这话有道理。我回去之后把AI编程助手、AI Agent、代码生成工具这些近两年的热门方向重新捋了一遍发现这个类比不是随口一说而是切中了当前AI编程领域几个非常核心的痛点。PLC也就是可编程逻辑控制器在工业现场已经跑了几十年。它的核心逻辑是什么是把一套确定性的控制流程用结构化文本、梯形图或者功能块图表达出来然后交给一个稳定可靠的运行时去执行。工程师不需要关心底层寄存器怎么分配、扫描周期怎么调度只需要把逻辑写对剩下的交给PLC的运行时环境。这套思路支撑了现代工业自动化的整个底座。再看今天的AI编程尤其是那些主打“从零开始能用”的AI编程助手和AI Agent工具它们在做的事情本质上也是同一件事把人的意图翻译成机器能执行的指令然后在一个受控的环境里跑起来。区别在于PLC翻译的是控制逻辑AI编程翻译的是业务逻辑。但两者面临的核心矛盾惊人地相似——如何让非确定性的人类意图变成确定性的机器执行。这个标题“AI编程正在重走PLC的路”说的就是这件事。它不是一个技术对比文章而是一个行业观察AI编程正在从“炫技阶段”进入“工程化阶段”而PLC几十年的工程化经验恰好是一面镜子。这篇文章适合所有正在用AI编程工具写代码的人、正在做AI编程产品的人以及那些从工业自动化转过来看AI编程的人。我会从结构化文本、Zero、MoonBit这些关键词切入把这条“重走的路”拆开来讲清楚。2. 结构化文本AI编程和PLC共享的底层语言观2.1 为什么结构化文本是两者的交汇点先说说结构化文本。在PLC的世界里结构化文本是一种高级编程语言语法上接近Pascal或者C但它被设计出来的目的非常明确用人类可读的方式描述控制逻辑然后由编译器翻译成PLC能执行的指令。西门子的SCL、汇川PLC的Codesys环境、三菱的ST语言本质上都是结构化文本的不同实现。AI编程领域最近频繁出现“结构化文本”这个词原因在于大语言模型生成代码时最大的问题不是“写不出来”而是“写出来的东西结构不稳定”。你让AI写一个函数它可能给你三种不同的写法变量命名风格不一致错误处理逻辑时有时无。这在个人项目里还能忍但在团队协作或者生产环境里就是灾难。PLC行业几十年前就解决了这个问题。它的做法是用严格的结构化文本规范约束代码形态用统一的运行时环境保证执行一致性。你在博途里写SCL变量声明区、逻辑执行区、注释区都有明确的格式要求编译器会强制检查类型匹配和语法规范。这套约束看起来死板但它换来了极高的可维护性和可预测性。AI编程正在往这个方向走。你看现在那些AI编程助手比如Cursor、Windsurf、VS Code Copilot它们生成代码时越来越强调“结构化输出”。不是随便给你一段代码就完事而是按照函数签名、参数类型、返回值、异常处理这样的结构来组织。这跟PLC的结构化文本思路是一致的先定结构再填逻辑。2.2 结构化文本在AI编程中的具体落地方式具体到实操层面AI编程工具怎么实现结构化文本输出我拿一个实际场景来说。假设你要让AI帮你生成一个数据处理的管道函数早期的大模型可能会直接给你一段Python代码变量名可能是data、result、temp这种错误处理可能就一个try-except包住全部。但现在更成熟的做法是你先给AI一个结构化的模板比如def process_data( input_path: str, output_path: str, batch_size: int 1000, error_handler: Callable None ) - ProcessingResult: 处理指定路径的数据文件按批次写入输出路径。 Args: input_path: 输入文件路径 output_path: 输出文件路径 batch_size: 每批处理条数 error_handler: 自定义错误处理函数 Returns: ProcessingResult: 包含成功条数、失败条数和错误详情 # 逻辑实现区 pass你把这样的结构给AI它填充逻辑的准确率会大幅提升。这跟PLC工程师在SCL里先定义好功能块的输入输出引脚再写内部逻辑是一个道理。结构先行逻辑后填这是PLC几十年验证过的工程方法现在被AI编程领域重新发现了。注意结构化文本不是让AI自由发挥而是给AI一个“填坑”的框架。你给的框架越清晰AI填出来的东西越靠谱。这一点在PLC编程里是常识在AI编程里正在成为常识。2.3 从梯形图到提示词表达方式的演进与回归PLC编程有五种标准语言梯形图、功能块图、顺序功能图、指令表和结构化文本。其中梯形图最直观像电路图一样适合逻辑简单的场景结构化文本最灵活适合复杂算法和数据处理。AI编程的表达方式也在经历类似的演进。最早的AI编程就是“你写注释它补代码”相当于梯形图级别的直观操作。后来发展到“你写提示词它生成整个模块”相当于功能块图。现在最前沿的AI Agent比如那些能自主规划、执行、调试的智能体已经开始要求你用结构化的方式描述任务包括输入输出定义、约束条件、验收标准这已经非常接近结构化文本的思维了。我试过用AI Agent做一个数据清洗任务一开始只给了一句“帮我清洗这个CSV文件”结果它生成的代码跑不通因为没定义清楚“清洗”的标准是什么。后来我改成结构化描述输入是什么格式、输出要满足什么条件、缺失值怎么处理、异常值怎么判定它一次就生成可用的代码。这个体验跟当年从梯形图转到结构化文本的感觉一模一样——表达越结构化执行越确定。3. Zero和MoonBitAI编程的“运行时环境”意识觉醒3.1 Zero在AI编程语境下的含义热搜词里有个“Zero”还有“zerotool zero width detector”。在AI编程的讨论中Zero通常指代几种不同的东西。一种是“从零开始”的AI编程也就是不依赖现有代码库完全由AI生成项目骨架。另一种是Zero-shot编程即不给示例直接让AI根据描述生成代码。还有一种是指某些具体的工具或框架名字里带Zero。但不管哪种含义Zero这个词在AI编程领域的流行反映了一个共同诉求降低启动成本让AI从零搭建可运行的系统。这跟PLC的“从零开始”编程很像。一个PLC项目从零开始你需要先组态硬件、定义变量表、写功能块、调试通信最后下载到PLC运行。AI编程从零开始你需要定义项目结构、生成代码、配置依赖、跑通测试。问题在于PLC的“从零开始”有明确的工程规范你知道第一步做什么、第二步做什么。AI编程的“从零开始”目前还很混乱不同工具、不同模型、不同提示词出来的结果千差万别。这就是为什么“从零开始能用的AI编程”会成为热搜词——大家都在找那个能稳定从零搭建项目的方案。3.2 MoonBit带来的启示AI编程需要自己的“运行时”MoonBit是一个国产的编程语言和工具链最近在AI编程圈子里被频繁提及。它的特点是什么它提供了一套完整的工具链包括编译器、构建系统、包管理器、IDE支持而且对AI生成代码有专门的优化。换句话说MoonBit在设计之初就考虑了“AI会大量生成代码”这个场景。这跟PLC的运行时环境思路非常接近。PLC为什么稳定因为它的运行时环境是专门为控制逻辑设计的你写的代码只能在那个环境里跑环境保证了执行的一致性和可靠性。MoonBit在尝试做的事情是为AI生成的代码提供一个受控的运行时环境让AI写出来的东西有地方跑、跑得稳、出了问题能定位。我实际用MoonBit跑过几个AI生成的模块感受最深的是它的错误提示非常清晰。AI生成的代码如果有类型不匹配或者逻辑漏洞MoonBit的编译器会给出具体的行号和原因而不是像某些动态语言那样跑起来才报错。这种“编译期就把问题拦住”的思路跟PLC编程中“下载前先编译检查”的流程如出一辙。3.3 AI编程工具大比拼背后的运行时缺失热搜词里还有“AI编程助手大比拼Cursor、Windsurf、VS Code Copilot和Trae谁才是你的神队友”。这些工具我都深度用过各有优劣。Cursor的补全和重构很强Windsurf的Agent模式适合多文件操作Copilot跟VS Code的集成最顺滑Trae在某些场景下的中文理解更好。但它们有一个共同的短板没有统一的运行时环境。你在Cursor里生成的代码拿到Windsurf里可能跑不通因为依赖版本或者环境配置不一样。这就像你在一台西门子PLC上写的程序直接拷到三菱PLC上肯定跑不了因为运行时环境不同。PLC行业解决这个问题的方式是标准化。IEC 61131-3标准规定了PLC编程语言的语法和语义不同厂商的PLC只要遵循这个标准代码就有一定的可移植性。AI编程目前还没有这样的标准每个工具、每个模型都在用自己的方式生成代码导致“AI写的代码”成了一个黑盒。提示如果你正在用多个AI编程工具建议建立一个统一的代码规范和依赖管理流程。比如用pyproject.toml或者package.json锁定依赖版本用pre-commit钩子做代码格式检查。这相当于给AI编程搭一个简易的“运行时环境”能省掉很多跨工具迁移的麻烦。4. AI Agent与PLC编程自主性与确定性的平衡术4.1 AI Agent在编程中的角色定位AI Agent是近两年AI编程领域最热的方向之一。跟传统的代码补全不同AI Agent能自主规划任务、调用工具、执行代码、根据结果调整策略。你给它一个目标比如“把这个项目的测试覆盖率提到80%”它会自己分析代码、生成测试用例、运行测试、根据失败结果修改用例直到达标。这个过程跟PLC的自动控制逻辑有相似之处。PLC控制一个产线也是给定目标比如“保持液位在50%”然后通过传感器读取当前值、跟目标值比较、调整阀门开度、再读取、再调整形成一个闭环。AI Agent的“感知-决策-执行-反馈”循环本质上就是一个软件层面的闭环控制。但PLC的闭环控制是确定性的给定相同的输入永远得到相同的输出。AI Agent的闭环控制是非确定性的同样的任务今天跑和明天跑可能得到不同的结果。这就是AI编程“重走PLC的路”需要解决的核心矛盾——如何在保持AI自主性的同时引入PLC级别的确定性。4.2 从PLC的扫描周期看AI Agent的执行循环PLC有一个核心概念叫“扫描周期”读取输入、执行程序、更新输出循环往复每个周期的时间是固定的通常在毫秒级。这个固定周期保证了控制的实时性和确定性。AI Agent的执行循环目前没有固定周期。它可能花几秒钟分析任务花几分钟生成代码花更长时间运行测试。这个时间不确定性在编程场景下还能接受但如果AI Agent要控制真实的物理设备比如机械臂或者产线时间不确定性就是致命的。热搜词里有“plc管理六轴机械臂伺服”和“plc控制一拖三软启动器”这些都是对实时性要求极高的场景。AI Agent目前还进不了这些场景因为它的执行循环太慢、太不确定。但反过来想如果AI Agent能借鉴PLC的扫描周期设计把任务拆解成固定周期的子任务每个周期内完成确定性的操作那它就能进入更多实时场景。我试过用AI Agent做一个定时数据采集任务一开始它每次采集的间隔都不固定因为它在两次采集之间做了太多“思考”。后来我改成让它先规划好采集逻辑生成一个固定间隔的采集脚本然后让脚本自己去跑。这其实就是把AI Agent的“思考”和“执行”分离思考阶段可以慢执行阶段必须快且确定。这个思路跟PLC的“离线编程、在线执行”是一样的。4.3 AI PLC代码生成的实际案例热搜词里有“ai plc代码生成”和“ai plc编程”说明已经有人在尝试用AI生成PLC代码了。我实际测试过几个方案用大模型生成结构化文本格式的PLC程序比如西门子的SCL或者汇川Codesys的ST代码。效果怎么说呢对于简单的逻辑比如电机正反转、星三角降压启动、抢答器控制AI生成的代码基本可用逻辑正确语法也符合规范。但对于复杂的非标项目比如多轴联动、模拟量闭环控制、通信协议处理AI生成的代码就需要大量人工修改。问题出在哪里PLC编程不仅仅是写逻辑还要考虑硬件组态、IO映射、通信配置、安全互锁。AI目前只能处理逻辑部分硬件相关的配置它看不到也摸不着。这跟AI编程在通用软件领域的困境一样AI能写函数但搞不定整个系统的集成。不过有一个方向值得关注AI生成PLC代码的“模板化”思路。你先把一个标准的PLC项目模板给AI包括硬件组态文件、变量表、通信配置然后让AI在模板基础上填充逻辑。这样生成的代码可用性会高很多。这跟前面说的结构化文本思路是一致的——先给结构再填逻辑。5. 实操用AI编程工具搭建一个“PLC风格”的项目骨架5.1 项目结构设计借鉴PLC的工程化组织方式说了这么多理论来点实际的。我拿一个数据采集和处理的Python项目为例展示怎么用AI编程工具搭建一个“PLC风格”的项目骨架。所谓PLC风格就是结构清晰、职责分明、执行确定。PLC项目的典型结构是这样的硬件组态、变量定义、功能块、主程序、通信配置。对应到Python项目我设计成这样project/ ├── config/ # 相当于硬件组态 │ ├── settings.yaml │ └── logging.yaml ├── models/ # 相当于变量定义 │ ├── schemas.py │ └── types.py ├── blocks/ # 相当于功能块 │ ├── data_reader.py │ ├── data_cleaner.py │ └── data_writer.py ├── main.py # 相当于主程序 └── tests/ # 相当于调试和验证 ├── test_reader.py └── test_cleaner.py这个结构看起来简单但它强制你把代码分成“配置”、“定义”、“功能”、“执行”四个层次。AI在生成代码时你告诉它每个文件放什么它就不会把所有的逻辑都塞到一个文件里。5.2 用AI生成功能块代码的具体步骤第一步先定义变量和类型。在models/types.py里用AI生成数据模型from dataclasses import dataclass from datetime import datetime from typing import Optional dataclass class SensorReading: sensor_id: str timestamp: datetime value: float unit: str status: str normal dataclass class ProcessingResult: total_count: int success_count: int error_count: int errors: list[str]给AI的提示词可以这样写“生成一个Python dataclass表示传感器读数包含传感器ID、时间戳、数值、单位、状态五个字段状态默认值为normal。”这个提示词的结构化程度很高AI生成的代码基本不需要修改。第二步生成功能块。在blocks/data_reader.py里让AI生成读取数据的函数。提示词要包含输入输出定义和异常处理要求def read_sensor_data( source_path: str, batch_size: int 100 ) - list[SensorReading]: 从指定路径读取传感器数据。 Args: source_path: 数据文件路径支持CSV和JSON格式 batch_size: 每批读取条数 Returns: list[SensorReading]: 传感器读数列表 Raises: FileNotFoundError: 文件不存在 ValueError: 数据格式错误 # AI填充逻辑 pass第三步生成主程序。在main.py里让AI把功能块串联起来def main(): config load_config(config/settings.yaml) readings read_sensor_data(config[source_path]) cleaned clean_data(readings) result write_data(cleaned, config[output_path]) logger.info(f处理完成: {result.success_count}/{result.total_count})这个流程跟PLC编程的“组态-定义-编程-调试”四步法完全对应。你不需要一次性让AI生成所有代码而是分步骤、分模块地生成每一步都有明确的输入输出定义。5.3 参数计算与选择以批处理大小为例PLC编程里经常需要计算参数比如PID控制的比例系数、滤波器的截止频率、通信的超时时间。AI编程同样需要参数计算只是很多人忽略了这一步。拿批处理大小来说。假设你要处理一个10GB的CSV文件内存只有8GB批处理大小设多少合适简单计算10GB除以8GB至少需要2批但考虑到内存还要留给操作系统和其他进程实际可用内存可能只有6GB。所以批处理大小应该按6GB来算10GB除以6GB约等于1.67向上取整为2批每批5GB。但5GB的数据加载到内存后经过解析和转换实际占用可能翻倍所以更安全的做法是每批2GB分5批处理。这个计算过程看起来简单但很多AI生成的代码直接用一个固定的batch_size1000完全不考虑实际数据量和内存限制。你在给AI提示词的时候应该把计算过程也写进去“数据文件约10GB可用内存6GB解析后内存占用约为原始数据的2倍请计算合适的批处理大小并生成代码。”注意AI不会主动帮你算这些参数它只会按照你给的数字生成代码。参数计算是人的工作不是AI的工作。这一点在PLC编程里是常识在AI编程里经常被忽略。6. 常见问题与排查技巧实录6.1 AI生成代码跑不通的典型原因用AI编程工具时间长了你会发现代码跑不通的原因就那么几类。我整理了一个速查表按出现频率从高到低排列问题类型典型表现排查方法解决思路依赖缺失ModuleNotFoundError检查requirements.txt或pyproject.toml让AI生成依赖列表手动核对版本类型不匹配TypeError或AttributeError检查变量定义和使用处用类型注解约束AI生成范围路径错误FileNotFoundError打印当前工作目录和文件路径用绝对路径或pathlib处理逻辑漏洞结果不符合预期加日志分步验证把大函数拆成小函数逐个验证并发问题偶发失败难以复现检查共享资源访问加锁或改用消息队列这张表里的问题PLC编程里也都会遇到只是表现形式不同。依赖缺失相当于PLC的固件版本不匹配类型不匹配相当于IO信号类型配错路径错误相当于通信地址写错。排查思路是一样的先定位问题范围再逐步缩小最后验证修复。6.2 提示词工程的“梯形图思维”很多人写AI编程提示词喜欢写一大段自然语言描述。这种方式对于简单任务还行对于复杂任务就容易失控。我推荐用“梯形图思维”来写提示词把任务拆成一个个条件-动作对像梯形图的每一行一样。比如你要让AI生成一个数据校验函数不要写“帮我写一个校验函数检查数据是否合法”而是写成结构化的条件列表任务生成数据校验函数 输入SensorReading对象 校验规则 1. 如果sensor_id为空返回错误传感器ID不能为空 2. 如果timestamp早于2020-01-01返回错误时间戳过早 3. 如果value小于-100或大于1000返回错误数值超出范围 4. 如果unit不在[C, F, K]中返回错误单位不支持 5. 所有校验通过返回None 输出错误信息字符串或None这种提示词方式跟梯形图的“条件-动作”结构完全一致AI理解起来准确率极高。我实测下来用这种方式生成的校验函数一次通过率在90%以上而自然语言描述的通过率只有60%左右。6.3 从PLC调试中学到的AI编程调试技巧PLC调试有几个经典方法强制输出、单步执行、监控变量、分段排查。这些方法在AI编程调试中同样适用。强制输出相当于在代码里加print或者logger把中间结果打出来看。单步执行相当于用调试器逐行运行看每一步的变量值。监控变量相当于用watch窗口或者日志记录关键变量的变化。分段排查相当于把程序分成几段每段单独测试。我特别想说的是“分段排查”。AI生成的代码往往是一个大函数里面几十行逻辑。跑不通的时候你很难一眼看出问题在哪。我的做法是让AI把大函数拆成几个小函数每个小函数只做一件事然后逐个测试。这跟PLC编程里把复杂逻辑拆成多个功能块是一样的道理。拆开之后问题定位时间能从半小时缩短到五分钟。提示让AI拆函数的提示词可以这样写“把这个函数拆成三个子函数第一个负责数据读取第二个负责数据转换第三个负责数据写入。每个子函数不超过20行有明确的输入输出。”7. 工具选型AI编程助手在“PLC风格”项目中的适配度7.1 主流AI编程工具对比热搜词里提到了Cursor、Windsurf、VS Code Copilot和Trae。我在“PLC风格”项目里都试过下面是对比工具结构化生成能力多文件操作运行时集成适合场景Cursor强中等弱单文件重构、代码补全Windsurf中等强中等多文件Agent任务VS Code Copilot中等弱强日常编码、快速补全Trae中等中等弱中文场景、教学用途“结构化生成能力”指的是按照你给定的模板生成代码的能力。“多文件操作”指的是同时修改多个文件的能力。“运行时集成”指的是跟运行环境、调试器的集成程度。如果你要做的是“PLC风格”的项目也就是结构清晰、模块分明的项目Windsurf的多文件操作能力最有用因为它能同时修改models/、blocks/和main.py保持整体一致性。如果你只是写单个功能块Cursor的补全和重构更强。7.2 免费AI编程方案的可行性热搜词里有“免费的ai编程写代码”和“deepseek的api和c知道的ai编程哪个好用”。免费方案我试过不少说几个实际感受。DeepSeek的API在代码生成上表现不错尤其是中文提示词的理解很到位。但它的上下文长度有限生成大项目时容易“忘掉”前面的定义。C知道CSDN的AI编程助手在中文技术社区的场景下还行但生成代码的质量参差不齐。免费方案最大的问题是不稳定。今天能用的提示词明天可能就生成不出同样的结果。如果你只是做实验或者学习免费方案够用。但如果是生产项目建议还是用付费方案至少保证生成结果的一致性。7.3 从PLC工具链看AI编程工具的未来PLC的工具链非常成熟西门子有博途汇川有Codesys三菱有GX Works。这些工具集成了编程、编译、调试、仿真、下载所有功能工程师在一个环境里完成所有工作。AI编程工具目前还处于“单点突破”阶段每个工具只做一件事。Cursor做补全Windsurf做AgentCopilot做集成。未来大概率会走向整合出现一个“AI编程的博途”——集成了代码生成、结构检查、运行时管理、调试监控的完整环境。MoonBit在这方面走得比较靠前它的工具链已经包含了编译器、构建系统、包管理器和IDE支持。虽然它还不是专门的AI编程工具但它的设计思路值得关注。8. 从PLC的非标项目实战看AI编程的落地路径8.1 非标项目的核心挑战需求不确定PLC非标项目最大的特点是需求不确定。客户今天说要控制三台电机明天可能改成五台。今天说用西门子PLC明天可能换成汇川。这种不确定性对编程提出了很高的要求代码要能快速适应变化。AI编程面临同样的挑战。业务需求变化快今天要加一个字段明天要改一个流程。AI生成的代码如果结构不好改起来比手写还麻烦。所以“PLC风格”的项目结构在AI编程里特别重要——结构清晰的项目AI改起来也清晰。我做过一个对比实验同样的需求变更在一个结构混乱的项目里AI改了五处代码引入了三个新bug在一个结构清晰的项目里AI只改了两处代码没有引入新bug。差距就在于结构。8.2 从“一拖三软启动器”看AI编程的模块化思维热搜词里有“plc控制软启动器一拖三”和“plc软启动器一拖三接线实物”。一拖三的意思是一个软启动器轮流启动三台电机。这个场景的核心逻辑是同一时间只能有一台电机在启动三台电机按顺序轮换。这个逻辑用PLC实现就是一个状态机等待状态、电机1启动、电机2启动、电机3启动、循环。每个状态有明确的进入条件、执行动作、退出条件。这种状态机思维在AI编程里同样适用。比如你要用AI生成一个任务调度器不要让它直接写调度逻辑而是先让它生成一个状态机框架from enum import Enum class TaskState(Enum): IDLE idle RUNNING running PAUSED paused COMPLETED completed ERROR error class TaskScheduler: def __init__(self): self.state TaskState.IDLE self.current_task None def transition(self, new_state: TaskState): # 状态转换逻辑 pass def run(self): # 主循环 pass有了这个框架AI填充具体逻辑时就不会跑偏。这跟PLC编程里先画状态转移图、再写代码的流程是一样的。8.3 AI编程在工业场景的边界必须承认AI编程目前还进不了工业控制的核心场景。PLC控制机械臂、控制产线、控制安全互锁这些场景对实时性、确定性、可靠性的要求AI编程还达不到。但AI编程可以在工业场景的外围发挥作用生成数据采集脚本、生成报表工具、生成监控界面、生成测试用例。这些场景对实时性要求不高但对开发效率要求高正好是AI编程的强项。我个人的判断是AI编程和PLC的关系不是替代而是互补。PLC守住实时控制的核心AI编程负责外围的数字化工具。两者之间的桥梁是结构化文本——PLC用结构化文本写控制逻辑AI编程用结构化文本生成外围工具数据格式统一了集成就顺了。9. 我个人在实际操作中的体会踩过几次坑之后我最大的体会是AI编程工具再强也替代不了你对项目结构的思考。你可以让AI写函数、写类、写测试但项目怎么分层、模块怎么划分、接口怎么定义这些必须你自己想清楚。想清楚了AI是你的加速器想不清楚AI是你的放大器——放大混乱。另一个体会是PLC行业积累的工程化经验对AI编程有直接的借鉴价值。结构化文本、状态机、扫描周期、功能块、变量表这些概念在AI编程里都能找到对应物。如果你有PLC背景转AI编程会有一种“似曾相识”的感觉。如果你没有PLC背景花点时间了解一下PLC的编程思想对用好AI编程工具会有帮助。最后分享一个小技巧每次让AI生成代码之前先花两分钟写一个结构化的提示词把输入、输出、约束、异常处理都列清楚。这两分钟的投入能省掉后面二十分钟的调试时间。这个习惯我从PLC编程里带过来在AI编程里同样有效。
