夜雨聆风QUOTE
AI 最强的地方，不一定是重新发明轮子，而是让已有的轮子快速变成你真正需要的东西。
—— 小王
大家好，我是小王。这里是小王思考日志，专注制造业数字化系统落地。
最近，我用 CodeBuddy + DeepSeek V4 Pro 做了一个 OPC UA Server 节点扫描工具。功能不复杂：连接 Server、扫描节点、提取 Variable、生成完整变量路径、导出表格。
但真正值得记录的，不是工具本身，而是我在开发过程中对“AI 编程应该怎么用”发生的一次认知转变。
一开始我想的是：怎么把 Prompt 写得足够详细，让 AI 从零把整个软件做出来？做到后来，我发现真正该问的是——为什么一定要让 AI 从零写？
本文看点
01
OPEN
一、一个只有六个字的需求
做 OPC UA 数据采集时，总得先搞清楚 Server 里到底有哪些变量。手工一层层展开节点树、整理 NodeId 和 DataType，效率不高。所以我想要个小工具：输入 Server 地址，自动连接、扫描 Address Space，把 Variable 节点整理成 Objects/PLC01/DB01/Temperature 这样的完整路径，输出 Path、NodeId、BrowseName、DisplayName、DataType，最后导出成表格。
需求压缩到最小，其实只有六个字：连接、扫描、导出。
02
CORE
二、第一个想法：让 AI 从零写
最自然的思路就是 Prompt Driven Development——只要我把需求描述得足够清楚，AI 就能把整个软件搭出来。于是我不断补充 Prompt：OPC UA Client、Endpoint 配置、Node Browser、Variable Scanner、Excel Export、日志、项目管理……需求越写越多，甚至开始规划一个包含 OPC UA、Modbus、MQTT 的“工业数据工具箱”。
后来回头看，我发现一个典型问题：我原本只想解决“连接、扫描、导出”，最后却差点开始设计一个工业数据采集平台。
03
INSIGHT
三、AI 最先做出来的，恰恰不是最重要的
AI 最擅长快速生成页面、按钮、输入框、表格、项目目录、Service 类。不一会儿就能看到一个“像软件”的东西，让人产生“是不是完成 70% 了”的错觉。
但真正连上 OPC UA Server 后才发现远没这么简单。Endpoint、Session、Namespace、NodeId、NodeClass、SecurityPolicy、Certificate……即使只做节点扫描，也得面对：节点动辄上万、层级格外深、不同厂家 Server 结构不同、某些节点属性读取失败、网络超时、单个节点异常不能拖垮整个扫描任务。
我逐渐意识到：UI 能运行，不代表工具真的能用。 工业协议工具的价值不在按钮画得多漂亮，而在通讯是否可靠、扫描是否完整、异常是否可控。
界面很好看，但是功能测不通。
04
IMPACT
四、我犯的第二个错误：用更长的 Prompt 解决复杂度
当 AI 生成的代码不够稳定时，我本能地觉得“是 Prompt 还不够详细”，于是继续补充项目结构、模块拆分、异常处理、接口定义。Prompt 越来越长，效果确实有改善。
但后来我发现：Prompt 能帮 AI 理解需求，却替代不了一个成熟的 OPC UA 协议栈。 对于成熟工业协议，问题往往不是“怎么把 Prompt 写得更好”，而是“GitHub 上是不是已经有人解决了”。
05
ACTION
五、真正的转折：先找 GitHub
项目中途我改了路线，不再问“怎么让 CodeBuddy 把 OPC UA 写好”，而是问“有没有成熟的 OPC UA 开源项目能当技术底座”。调研了 node-opcua、OPC Foundation UA-.NETStandard、opcua-asyncio 等，最终选定 opcua-asyncio 2.0.1。
路线从“需求 → AI 从零实现底层 → 不断调试”，变成“需求 → 搜索成熟开源 → 运行验证 → 确定底座 → AI 阅读已有项目 → 针对需求二次开发”。
06
CLOSING
六、从“实现 OPC UA”变成“利用 OPC UA”
选了 opcua-asyncio 之后，问题突然简单了。Server 连接、Session、Browse、属性读取这些底层都有成熟能力，我不需要让 AI 重新发明一遍。我真正要处理的只剩：从哪个节点开始扫、怎么递归、哪些 NodeClass 要输出、怎么构造路径、单节点失败怎么隔离、最后怎么导 Excel。
开发任务从“实现 OPC UA”变成了“利用 OPC UA 完成我的业务需求”。这时候 AI 编程进入了它最舒服的区域。
07
NEXT
七、AI 真正发挥价值的三类任务
基于已有项目后，CodeBuddy + DeepSeek V4 Pro 在三类任务上效率极高：
第一是读代码——快速理解项目入口、Client 怎么建、Node API 怎么调、哪里适合加扫描逻辑，比从头读快一大截。
第二是边界明确的业务代码——递归扫描、路径拼接、NodeClass 过滤、属性提取、异常捕获、Excel 导出。这些目标明确、输入输出明确的任务，AI 表现极好。
第三是重复性的工程活——数据结构、字段映射、日志、UI 表格、文件输出，不是没技术含量，是太耗时间，交给 AI 正合适。
08
FOCUS
八、同一个 AI，前后效果为什么差这么多
有意思的是，我前后用的都是 CodeBuddy + DeepSeek V4 Pro，但体验完全不同。
第一阶段把 AI 当“从零开发者”，它得同时负责架构、协议、业务、UI，不确定性极高。第二阶段把 AI 当“成熟项目上的二次开发助手”，底层 OPC UA 由成熟库解决，AI 只需理解现有 API 再完成定制需求。
组合变成了：成熟 Library 负责协议正确性，AI 负责业务定制，人负责需求判断和最终验证。 这个组合明显更稳定。
09
SIGNAL
九、重新理解 AI 编程
以前我的想象是“我提需求，AI 写整个软件”。现在更倾向于另一种模式：成熟项目解决 80%，AI 帮我完成最后 20%。
别小看这 20%。决定一个通用开源项目能不能变成“我的工具”的，恰恰是最后这部分——业务逻辑、交互方式、字段结构、导入导出、异常处理、现场适配。这“最后一公里”以前要开发者花几天，现在 AI 大幅压缩了成本。
AI 最强的地方，不一定是重新发明轮子，而是让已有的轮子快速变成你真正需要的东西。
10
VIEW
十、一套可以复制到 Modbus、MQTT 的方法
做完 OPC UA，我发现这套方法不局限于此。下次做 Modbus TCP 寄存器扫描工具，第一反应不该是“让 AI 从 TCP Socket 开始写”，而应该是：明确需求 → 找 pymodbus 等成熟项目 → 验证读取能力 → 确定底座 → 让 AI 开发 Scanner → 加 UI 和 Excel 导入导出。MQTT、串口、数据库采集，本质上都能复制。
我给自己总结了新的 SOP：
先定义最小闭环——只回答输入、核心处理、输出三个问题
先去 GitHub 找轮子——看活跃度、License、文档、示例、二次开发难度
先把原项目跑起来——确认核心能力能工作再改，否则出了问题分不清是原项目还是 AI 修改
让 AI 先理解，不要先改——先分析结构、找入口、梳理调用关系
把任务拆小——不要“帮我开发完整工具”，拆成连接、扫描、递归、识别、拼路径、导出等小任务
最后必须真实验证——验证能不能连真实 Server、节点有没有漏扫、异常节点会不会拖垮任务。工业软件最终裁判是实际环境，不是 AI 说“已完成”
11
MODEL
写在最后
以前做软件常说“不要重复造轮子”。到了 AI 编程时代，这句话反而更关键了。因为 AI 太容易让“造一个轮子”看起来不难——几句话一个项目就生成了，页面能打开、按钮能点、代码写了几千行，于是我们容易忘记：生成代码的成本降低了，但验证复杂系统是否正确的成本，并没有同步归零。
所以现在再让我开始类似项目，我不会先问“怎么写更强的 Prompt 让 AI 从零做出来”，我会先问“这个世界上已经有哪些成熟能力，可以让我直接站上去”。
这是这次 OPC UA 项目给我最大的启发：不要首先思考如何让 AI 从零写，而要首先思考有哪些成熟能力能直接复用，再让 AI 帮我完成剩下的部分。
AI 让写代码越来越廉价，但真正稀缺的，正在变成——知道什么不应该自己写。
我是小王，一个深耕制造业数字化的项目经理。
#OPCUA #AI编程 #CodeBuddy #工业数据采集 #SCADA #开源