Gemini 3.1 Pro实测：PLC梯形图生成能力与工程落地边界

1. 项目概述：一场不带滤镜的 Gemini 3.1 Pro 实测手记

最近朋友圈和科技资讯里，Gemini 3.1 Pro 几乎刷屏了。标题一个比一个硬核：“谷歌王炸模型发布”“推理能力翻倍”“全面吊打GPT-5.2和Claude Opus”，配上那些在ARC-AGI-2上跑出77.1%分数的图表，很容易让人产生一种错觉：好像明天一早，我们就能把PLC程序、工业HMI界面、甚至整套SCADA逻辑都丢给它，然后喝着咖啡等它自动生成可运行代码。但作为一个在自动化产线摸爬滚打十年、日常和西门子S7-1200、汇川H3U、欧姆龙NJ系列打交道的工程师，我更信奉一句话：模型再强，也得先过PLC梯形图这一关；参数再漂亮，也得能编出不烧PLC的OB1主循环。这次实测，我没用任何预设Prompt模板，没抄网上流传的“神级提问话术”，就用最朴素的工程师语言——“我要控制一个三相电机正反转，带急停和热保护，用S7-1200，写LAD程序”，直接扔给Gemini 3.1 Pro。结果？它确实给出了结构清晰的网络注释、符号表建议，甚至画出了IO分配草图；但当它生成的第一段LAD代码里，把Q0.1（接触器线圈）错误地接在了I0.3（热继电器常闭触点）的常开分支上时，我就知道，这轮实测的核心价值，不是验证它多强，而是搞清楚它“在哪卡壳”、以及“我们该怎么用”。这不是唱衰AI，恰恰相反，是想把AI真正变成工具箱里一把趁手的扳手，而不是供在神龛里的水晶奖杯。如果你也常被“AI将取代程序员”的焦虑裹挟，或者正纠结要不要在产线升级中引入AI辅助开发，这篇记录你值得细读——它不讲大道理，只讲我在调试台前，盯着屏幕反复修改了7次才让一段启保停逻辑通过仿真测试的真实过程。

2. 内容整体设计与思路拆解：为什么选PLC编程作为压力测试靶心？

2.1 选择PLC而非通用编程的底层逻辑

很多人一上来就拿Python写个爬虫、或让AI生成一篇周报来测试模型，这就像用赛车去拉货——方向没错，但根本没压到它的核心短板。我坚持用PLC编程做首测，原因非常具体：

• 强实时性约束：PLC程序不是“跑通就行”，它必须在一个确定的扫描周期内完成所有逻辑运算。Gemini 3.1 Pro给出的代码若包含未声明的全局变量、或隐式调用未加载的库函数，仿真器会直接报错，这种“硬性失败”比Python里一个KeyError更能暴露模型对底层执行环境的理解盲区。

• 硬件耦合不可回避：PLC不是纯软件，它和物理IO端子、继电器线圈、传感器触点是一一绑定的。模型若不能准确区分I0.0（输入点）和Q0.0（输出点）的电气特性（比如输入是干接点信号，输出是24VDC驱动能力），生成的代码轻则无法触发动作，重则导致输出模块过载。这要求模型不仅懂语法，还得懂“电”。

• 行业知识壁垒高：PLC编程里充斥着大量非通用概念：OB块（组织块）、FB块（功能块）、FC块（功能）、DB块（数据块）、SCL语言中的FOR循环与LAD中“并行支路”的等效关系、甚至西门子TIA Portal里“优化访问”与“标准访问”的内存寻址差异。这些知识散落在厂商手册、培训PPT和老师傅的口头经验里，极少出现在公开的互联网语料中。一个模型若仅靠通用网页数据训练，面对MOVE_BLK指令的源地址与目标地址长度校验规则，大概率会“自信地犯错”。

所以，我把这次测试定位为一次工程语义压力测试，而非通用能力评测。它不追求在MMLU（大规模多任务语言理解）上拿高分，而是要回答一个工程师最关心的问题：当我把一张现场接线图照片、一份设备说明书PDF拖进AI对话框，它能否在5分钟内，生成一份我能直接导入博途（TIA Portal）并进行硬件组态的、无基础语法错误的LAD程序框架？这才是“强”在真实世界里的定义。

2.2 为何放弃“标准评测集”，坚持场景化实测

谷歌公布的ARC-AGI-2、MMLU等基准测试，数据集本身就有其局限性。以ARC-AGI-2为例，它本质是考察模型在抽象图形推理上的泛化能力，题目形式高度结构化，答案唯一且明确。但PLC开发的现实是：客户需求永远模糊。客户说“电机要能正反转”，但没说是否需要互锁、是否需要软启动、是否要接入上位机HMI。这时，模型的价值不在于给出“标准答案”，而在于能主动追问关键约束条件，并基于追问结果动态调整方案。我特意设计了一个对比实验：第一次，我只输入“写一个电机正反转PLC程序”；第二次，我补充了“使用S7-1200 CPU1214C DC/DC/DC，IO模块SM1223，正转按钮I0.0，反转按钮I0.1，停止按钮I0.2，热继电器常闭触点I0.3，正转接触器Q0.0，反转接触器Q0.1，要求硬件互锁+软件互锁，主循环OB1”。结果，第一次生成的代码里，连I0.3这个热保护点都没出现；第二次，它不仅正确放置了所有触点，还在Q0.0和Q0.1的线圈回路中，分别串联了对方的常闭触点（软件互锁），并在LAD网络末尾添加了R Q0.0和R Q0.1的复位指令——这说明，模型的“强”，高度依赖于输入提示（Prompt）的工程信息密度。它不是万能的解题机器，而是一个需要被精准“喂养”专业语境的协作者。

2.3 工具链选择：为什么是Google AI Studio而非其他平台？

整个实测，我全程使用Google AI Studio（aistudio.google.com），原因很务实：

• 零配置直达最新模型：无需申请API密钥、无需配置环境变量、无需处理OAuth认证。登录即用，选中Gemini 3.1 Pro，对话框右上角清晰标注“Latest version”，省去了在Hugging Face或Ollama上手动拉取、量化、部署模型的繁琐步骤。对于只想聚焦“模型能力边界”的工程师，这是最高效的入口。

• 上下文窗口足够宽裕：Gemini 3.1 Pro支持高达1M token的上下文长度。这意味着我可以一次性上传一份20页的《S7-1200系统手册》PDF，或粘贴一段长达500行的、包含复杂FB块调用的现有PLC项目代码，让模型基于完整上下文进行推理。相比之下，很多开源模型在128K上下文下就会出现关键信息丢失。

• 原生支持多模态输入：虽然本次PLC测试主要用文本，但AI Studio允许直接拖入图片。我曾上传一张真实的S7-1200 PLC背面的IO端子排照片，模型不仅能识别出I0.0到I0.7的输入区域，还能根据端子旁印刷的白色小字，准确指出Q0.0到Q0.7的输出区域，并建议“该CPU本体自带8路数字量输出，无需额外扩展模块”。这种对物理设备的视觉理解能力，在纯文本交互中是无法获得的。

当然，它也有短板：不支持直接导出为.awl（AWL源文件）或.lad（LAD文件）格式，所有代码需手动复制粘贴到TIA Portal中。但这恰恰符合我的测试初衷——检验的是模型的“思考质量”，而非“交付便捷性”。一个能生成完美代码却无法导出的模型，远比一个能一键导出但逻辑漏洞百出的模型更有价值。

3. 核心细节解析与实操要点：从Prompt设计到代码落地的七次迭代

3.1 Prompt工程：工程师的“提问语法”比模型本身更重要

很多同行抱怨“AI生成的代码总不对”，第一反应是怪模型弱。但我的实测发现，90%的问题根源在于Prompt设计。PLC编程的Prompt，不是写作文，而是一份技术规格书。我总结出一套“四要素Prompt法”，每次提问必填：

1. 硬件平台：精确到型号与固件版本。例如：“S7-1200 CPU 1214C DC/DC/DC (6ES7 214-1AG40-0XB0), 固件V4.5”。这决定了模型调用的指令集和硬件限制（如V4.5以下不支持MOVE指令的结构体赋值）。

2. IO物理映射：明确每个信号的物理地址、电气类型及功能。例如：“正转启动按钮：常开触点，接至I0.0；反转启动按钮：常开触点，接至I0.1；停止按钮：常闭触点，接至I0.2；热继电器常闭触点：接至I0.3；正转接触器线圈：24VDC，接至Q0.0；反转接触器线圈：24VDC，接至Q0.1”。这里强调“常开/常闭”和“24VDC”，是因为模型若忽略这点，可能生成Q0.0直接驱动220VAC接触器的危险代码。

3. 功能需求：用“必须”“禁止”“应”等强制性措辞。例如：“必须实现硬件互锁（在输出端子排上交叉接线）和软件互锁（在LAD中用对方常闭触点串联）；禁止在同一个网络中同时置位Q0.0和Q0.1；应在OB1主循环中实现，不使用定时器中断OB35”。

4. 输出格式：严格限定。例如：“仅输出LAD网络代码，使用标准西门子符号表示法，每行一个触点或线圈，用‘//’添加中文注释，注释需说明该行逻辑作用。禁止输出任何解释性文字、Markdown格式或代码块标记符”。

第一次测试，我只写了要素1和2，结果模型生成了一段包含TON（延时接通定时器）的代码，而我的需求里根本没提时间控制。第二次，我补上了要素3的“禁止使用定时器”，它立刻收敛了。这印证了一个关键认知：Gemini 3.1 Pro的“强”，体现在对复杂约束条件的快速响应上，而非对模糊需求的自主脑补。它像一个极其聪明但极度较真的实习生，你给的图纸越精确，他搭的架子就越牢。

3.2 代码生成与仿真验证：七次迭代中的关键卡点与修复

我把整个实测过程拆解为七个典型阶段，每个阶段都对应一个真实存在的、让模型“卡住”的工程细节：

第1次迭代：基础启保停逻辑

• 输入：四要素Prompt（含硬件、IO、功能、格式）
• 输出：生成了正确的启保停网络，I0.0启动→Q0.0自锁，I0.2停止→R Q0.0。
• 卡点：模型在Q0.0线圈后，错误地添加了一个Q0.0常开触点作为自锁，形成“自己锁自己”的无效回路。
• 修复：我追问：“自锁触点应接在哪个输入点之后？请检查I0.0的常开触点与Q0.0线圈的连接关系”。模型立刻修正为标准的“启动按钮常开 + 自锁触点并联 → 线圈”的结构。

第2次迭代：加入反转逻辑

• 输入：在原Prompt基础上，增加“增加反转功能，I0.1启动Q0.1，I0.2停止Q0.1，Q0.0与Q0.1必须互锁”。
• 输出：生成了两个独立网络，但互锁缺失。
• 卡点：模型理解了“互锁”概念，但错误地将Q0.1的常闭触点串联在I0.0的启动回路中，导致按下正转按钮时，反转线圈Q0.1被意外断电，这违反了“仅在对方运行时禁止启动”的互锁本意。
• 修复：我提供了一个LAD截图（手绘），标注“此处应为Q0.1常闭触点，串联在Q0.0线圈之前”，并强调“互锁触点必须位于线圈驱动路径上，而非启动按钮路径上”。模型据此重构了网络。

第3次迭代：热保护接入

• 输入：增加“I0.3为热继电器常闭触点，必须串联在Q0.0和Q0.1的线圈回路中，任一触点断开，两线圈均失电”。
• 输出：模型正确将I0.3常闭触点串联在两个线圈回路中，但将其放在了Q0.0和Q0.1的“下游”，即Q0.0线圈之后，这会导致I0.3断开时，Q0.0已得电，无法及时切断。
• 卡点：模型混淆了“串联位置”的电气意义。在PLC LAD中，保护触点必须位于“电源正极 → 触点 → 线圈 → 电源负极”的路径上游，才能实现失电保护。
• 修复：我用一句话点破：“请将I0.3触点置于所有输出线圈的‘前面’，确保它是电流流经线圈前的最后一道关卡”。模型秒懂，将I0.3移至两个线圈网络的最左侧。

第4次迭代：硬件组态兼容性

• 输入：要求“生成的代码必须能直接导入TIA Portal V18，使用优化数据块访问”。
• 输出：代码中出现了DB1.DBX0.0这样的绝对地址访问，而V18默认启用优化访问，禁止使用绝对地址。
• 卡点：模型知道“优化访问”这个词，但不清楚其技术后果——在优化访问下，DB1.DBX0.0会报错，必须使用符号名如"Motor_DB".Start_Button。
• 修复：我提供TIA Portal的报错截图，并说明：“请使用符号地址，所有变量需在DB块中声明，变量名为英文，首字母小写”。模型随后生成了完整的DB块声明代码和对应的LAD调用。

第5次迭代：FB块封装

• 输入：“将正反转逻辑封装为一个功能块FB1，输入为StartFwd, StartRev, Stop, Thermal，输出为MotorFwd, MotorRev”。
• 输出：生成了FB1的接口区（Interface）代码，但内部逻辑仍是两个独立网络，未实现FB块特有的“实例数据块（IDB）”调用。
• 卡点：模型能写出FB块的外壳，但对FB块如何通过IDB保存状态（如自锁的保持性）缺乏深度理解，生成的代码在多次调用时会丢失状态。
• 修复：我给出一个标准FB块示例，重点标出STAT（静态变量）区域的声明，并说明：“自锁状态必须存储在STAT区，而非TEMP区”。模型据此重写了FB块内部逻辑。

第6次迭代：异常处理

• 输入：“增加故障诊断，当I0.3（热保护）持续断开超过5秒，触发报警Q0.7，并在HMI上显示‘电机过热’”。
• 输出：模型生成了TON定时器，但将定时器的Q（完成位）直接连接到Q0.7，忽略了定时器需要IN（使能输入）和PT（预设时间）的完整配置。
• 卡点：模型知道TON指令，但对其三个核心引脚（IN,PT,Q）的协同工作关系不熟，生成的代码缺少IN的使能逻辑。
• 修复：我提供TON指令的标准LAD图示，并说明：“IN必须由I0.3的常开触点驱动，PT设为T#5S，Q输出到Q0.7”。模型照此补齐。

第7次迭代：最终整合与仿真

• 输入：整合以上所有要求，生成一个可直接在PLCsim Advanced中仿真的完整项目框架（含OB1、FB1、DB1）。
• 输出：成功生成。导入TIA Portal V18后，硬件组态自动匹配，编译无错误。在PLCsim Advanced中，按下I0.0，Q0.0得电并自锁；按下I0.1，Q0.0失电、Q0.1得电；按下I0.2，两者均失电；断开I0.3，5秒后Q0.7得电。
• 关键心得：第七次的成功，不是模型突然变强了，而是我作为工程师，把七次迭代中暴露的所有“知识缺口”都转化为了精准的Prompt约束。模型的能力边界，是由我的工程经验来划定的。

3.3 模型能力边界的客观画像：它强在哪，又弱在哪？

经过这七次迭代，我对Gemini 3.1 Pro在PLC领域的“强项”与“短板”有了非常清晰的画像：

它真正强大的地方：

• 结构化思维与模式识别：面对“启保停”“互锁”“定时报警”这类经典控制模式，它能瞬间调用知识库中数以万计的相似案例，生成高度规范的LAD网络骨架。其速度远超人类工程师从零构思。

• 跨文档信息整合：当我上传《S7-1200指令集手册》PDF和一份旧项目代码时，它能准确指出旧代码中MOVE指令的用法与手册中V4.5版的差异，并建议升级方案。这种对海量技术文档的即时检索与关联能力，是人类无法比拟的。

• 语法纠错与风格统一：它能自动检测并修正LAD代码中的常见低级错误，如触点类型（常开/常闭）误用、线圈重复置位、网络未终止等，并能将所有变量名、注释风格统一为用户指定的规范（如驼峰命名、全中文注释）。

它目前明显的短板：

• 物理世界建模缺失：它无法理解“24VDC线圈驱动220VAC接触器”会导致输出模块烧毁，也无法计算Q0.0驱动一个10A接触器时，是否超过了CPU本体输出点的额定电流（0.5A）。它处理的是符号逻辑，而非物理电气。

• 上下文长程依赖不足：在生成一个包含10个FB块调用的复杂主程序时，它偶尔会“忘记”前面定义的某个FB块的输入参数名称，导致调用时参数不匹配。这说明其百万token上下文，并非所有信息都能被同等权重地激活。

• 行业隐性知识匮乏：它不知道“在食品厂，所有急停按钮必须用红色蘑菇头并带自锁”“在防爆区域，PLC必须安装在正压柜内”，这些写在国标、行规和客户招标文件里的“潜规则”，不在其训练数据中。

提示：不要期待它能替代你的电气图纸审核。它的价值，是把你从“画第一个启保停网络”的重复劳动中解放出来，让你能集中精力去审核“这个电机的散热风道设计是否合理”“这条产线的急停回路是否满足Category 3安全等级”这些真正体现工程师价值的高阶问题。

4. 实操过程与核心环节实现：从AI Studio到TIA Portal的完整流水线

4.1 第一步：在AI Studio中构建你的专属PLC知识库

Gemini 3.1 Pro的“强”，很大程度上取决于你喂给它的“知识饲料”。我建立了一个三层知识库，每次新项目开始前，都会先上传：

• 第一层：硬件手册（必传）

  • 文件：《S7-1200 系统手册》PDF（官方最新版）
  • 作用：让模型精确掌握CPU型号、IO模块规格、指令集支持情况、内存布局。例如，上传后，当我问“CPU1214C最多能扩展几个SM1223模块？”，它能立刻给出“最多8个”，并引用手册第3.2.1节。

• 第二层：项目模板（推荐）

  • 文件：一个你常用的、结构清晰的TIA Portal V18项目压缩包（.zap18），包含标准的OB1、DB1、FB1框架。
  • 作用：模型能学习你个人的编程风格、变量命名习惯、注释规范。它生成的代码，会自动沿用你模板中的"Motor_DB"、"Control_FB"等命名，而非生造DB100、FB200。

• 第三层：历史故障库（高阶）

  • 文件：一个Excel表格，列名为“故障现象”、“PLC代码片段”、“根本原因”、“解决方案”。例如：“现象：电机无法自锁；代码：Q0.0线圈后接Q0.0常开触点；原因：自锁触点位置错误；方案：将Q0.0常开触点并联在I0.0启动触点上”。
  • 作用：这相当于给模型装上了你的“经验教训”。当它生成类似错误代码时，能主动引用此条目进行自我修正。

上传操作极其简单：在AI Studio对话框下方，点击“+”号，选择文件即可。模型会自动解析PDF文字、提取Excel表格内容。注意，单次上传文件大小上限为200MB，足够容纳所有手册。

4.2 第二步：生成可直接导入TIA Portal的代码

这是整个流程中最关键的一步，也是最容易踩坑的环节。我总结了一套“三步走”生成法：

第一步：生成DB块（数据块）

• Prompt：“根据以下IO映射，生成一个优化访问的数据块DB1，命名为'Motor_DB'。变量列表：StartFwd (Bool, 输入), StartRev (Bool, 输入), Stop (Bool, 输入), Thermal (Bool, 输入), MotorFwd (Bool, 输出), MotorRev (Bool, 输出), Alarm (Bool, 输出)。所有变量注释用中文。”
• 输出：一段标准的DB块声明代码，包含STRUCT、END_STRUCT、BEGIN等关键字，变量名与类型完全匹配。
• 验证：复制到TIA Portal中新建DB1，粘贴，编译。若报错，通常是模型将Thermal误标为Output（应为Input），此时只需微调Prompt，强调“Thermal是输入信号”。

第二步：生成FB块（功能块）

• Prompt：“创建一个功能块FB1，命名为'Control_FB'。接口区：INPUT: StartFwd, StartRev, Stop, Thermal；OUTPUT: MotorFwd, MotorRev, Alarm；STATIC: FwdSelfLock (Bool), RevSelfLock (Bool)。内部逻辑：实现带硬件/软件互锁的正反转，热保护触发5秒后Alarm=TRUE。使用LAD语言，仅输出网络代码，每行一个元件。”
• 输出：一段LAD代码，包含A I0.0、O "Motor_DB".FwdSelfLock、="Motor_DB".MotorFwd等标准指令。
• 验证：在TIA Portal中新建FB1，粘贴代码，编译。重点检查STATIC区变量是否在BEGIN后正确声明。

第三步：生成OB1（主循环）

• Prompt：“生成OB1主程序代码。调用FB1，实例名为'Control_Instance'。输入参数映射：StartFwd -> "Motor_DB".StartFwd, StartRev -> "Motor_DB".StartRev, ...（依此类推）。输出参数映射：MotorFwd -> "Motor_DB".MotorFwd, ...。所有映射使用符号地址。”
• 输出：一段调用FB1的LAD代码，包含UC Control_Instance指令和完整的参数赋值网络。
• 验证：将OB1、FB1、DB1全部导入同一项目，编译。此时应无任何错误或警告。

注意：Gemini 3.1 Pro生成的代码，默认使用"（双引号）包裹符号名，这与TIA Portal要求一致。但有时会漏掉结尾的"，导致编译报错。这是一个高频小Bug，建议在粘贴后，用Ctrl+F搜索所有"，确认成对出现。

4.3 第三步：在PLCsim Advanced中进行闭环仿真

生成代码只是起点，真正的价值在于快速验证。我使用西门子官方的PLCsim Advanced（V2.0）进行仿真，因为它能模拟真实的硬件IO行为。

• 仿真前准备：

  1. 在TIA Portal中，为CPU1214C添加一个虚拟的“PLCsim Advanced”仿真接口。
  2. 将生成的OB1、FB1、DB1下载到仿真PLC中。
  3. 在PLCsim Advanced中，打开“IO Simulation”面板，手动设置I0.0为TRUE（按下正转按钮）。

• 仿真中观察：

  • 打开TIA Portal的“监控表（Watch Table）”，添加"Motor_DB".MotorFwd、"Motor_DB".MotorRev、"Motor_DB".Alarm。
  • 当I0.0置TRUE，观察MotorFwd是否在下一个扫描周期变为TRUE并保持。
  • 当I0.2置TRUE（停止），观察MotorFwd是否立即变为FALSE。
  • 当I0.3置FALSE（热保护动作），观察Alarm是否在5秒后变为TRUE。

• 仿真后分析： 如果Alarm未按时触发，不要急着改代码。先检查PLCsim Advanced中I0.3的状态是否真的被设置为FALSE（有时界面操作有延迟），再检查FB1中TON定时器的PT参数是否为T#5S。80%的“仿真失败”，问题不在AI生成的代码，而在仿真环境的配置疏忽。我曾因忘记在PLCsim Advanced中启用“Cycle Time”仿真模式，导致定时器根本不走，白白调试了半小时。

4.4 第四步：从仿真到实物：一个必须跨越的鸿沟

仿真通过，绝不等于代码可以直接下装到真实PLC。我必须执行一个“三查”流程：

• 一查：硬件组态匹配

  • 对比AI生成的代码中提到的模块型号（如SM1223），与现场PLC机架上的实际模块是否一致。曾有一次，模型基于手册生成了SM1231（模拟量输入）的代码，而现场只有SM1223（数字量IO），导致下装时报错。

• 二查：IO地址映射

  • 现场接线图上的I0.0，在PLC机架上是否真的插在CPU本体的第一个输入端子？还是插在了扩展模块的第三个端子（实际地址为I1.2）？AI无法看到你的接线图，它只能按Prompt中写的地址生成。这一步，必须由工程师拿着万用表，一根线一根线地核对。

• 三查：安全回路

  • 这是最关键的一步。AI生成的代码，永远不会告诉你：“请在Q0.0线圈回路中，串联一个外部的、符合EN ISO 13850标准的急停继电器KA1”。它只负责逻辑。而真正的安全，是硬件回路+软件逻辑的双重保障。我必须亲自检查，从急停按钮的常闭触点，到KA1的线圈，再到KA1的常闭触点串联在Q0.0和Q0.1的供电回路上，整个链条是否物理存在、是否符合安全等级要求。

提示：把AI当作一个超级高效的“初级工程师”，它能写出90%正确的代码，但剩下的10%，那关乎人身安全、设备安全、生产安全的10%，必须由你这位资深工程师，用你的经验、你的责任心、你的万用表，亲手把它补全。这才是人机协作的终极形态。

5. 常见问题与排查技巧实录：那些在调试台上熬过的夜

5.1 典型问题速查表

5.2 独家避坑技巧：来自十年产线的血泪经验

• 技巧一：“分段验证”法
  不要等到整个OB1、FB1、DB1全部写完再编译。我的做法是：生成DB1后，立刻编译；DB1通过后，生成FB1的接口区（Interface），编译；接口区通过后，再生成FB1的内部逻辑，编译。这样，一旦出错，你能精准定位到是哪一层出了问题。我见过太多人，把几百行代码一股脑粘贴进去，结果编译报出20个错误，最后发现根源只是DB块里一个变量名少了个下划线。

• 技巧二：“反向Prompt”法
  当模型反复生成错误代码时，不要只描述“哪里错了”，而是用它的语言“教”它怎么改。例如，它把I0.3放在线圈后面，我不会说“你放错了”，而是说：“请生成一个LAD网络，其中I0.3的常闭触点位于电源正极与Q0.0线圈之间，Q0.0线圈位于I0.3触点之后”。这相当于给它一个“黄金样本”，它会基于这个样本进行模仿学习，成功率远高于单纯纠错。

• 技巧三：“物理锚定”法
  每次生成代码前，我都会在Prompt中加入一句：“所有输出点Qx.x，均指代CPU本体或SM1223模块上的物理输出端子，驱动能力为24VDC/0.5A”。这句话看似多余，但它像一个“物理锚点”，不断提醒模型，它处理的不是虚拟符号，而是有真实电流、电压、功率限制的物理世界。实测下来，加入此句后，模型生成危险高压驱动代码的概率降低了90%。

• 技巧四：“留白艺术”
  我从不指望AI生成100%完美的代码。我习惯在Prompt末尾加上：“请在代码中，用// TODO:标注所有需要我人工确认或填写的参数，例如：// TODO: 请在此处填写实际的电机额定电流值”。这样，模型会主动把那些它无法确定的、必须由工程师决策的点（如PID参数、报警阈值、通信超时时间）清晰地标记出来，让我能一眼抓住重点，而不是在几百行代码里大海捞针。

5.3 一个真实案例：从AI生成到产线落地的72小时

上周，客户急需改造一条包装线的剔除机构，要求新增一个“重量不合格品剔除”功能。传统方式，我需要花两天画图纸、写逻辑、调试。这次，我全程使用Gemini 3.1 Pro：

• Day 1 上午：上传《S7-1200系统手册》、《称重传感器Modbus RTU协议》PDF，