我们自己也有点没想到
去年接了个工业自动化项目，给一家做食品包装机的小工厂写PLC控制程序。客户要求用ST语言（结构化文本）和梯形图混合编程。这活儿不大，但很挑人——懂PLC的工程师不擅长写代码，懂代码的工程师没见过PLC。我们想着先用大模型试试。
内部投票，三个工程师都觉得GPT-4是稳妥选择。毕竟它对话流畅，通用能力强，犯错少。另一个选项是DeepSeek-Coder，那时刚开源不久，名声主要在代码补全上。我犹豫了两天。最后决定两个都测，各写一段完整的PLC控制逻辑：判断输送带速度，当物料堵塞时启动反转，同时输出报警信号。
结果挺打脸。
GPT-4生成的代码语法没毛病，但逻辑有问题——它把“反转”的时间写成了一个固定值5秒，不管堵塞是否解除。DeepSeek-Coder生成的代码里加了一个传感器反馈循环，判断堵塞消失才停止反转。这个细节工业工程师一眼就知道是常识，但大模型很少能主动做出来。
那天晚上我坐在办公室，盯着两段代码看了很久。不是GPT-4不好，而是在这个小众领域里，DeepSeek的泛化反而更实在。它训练数据里可能包含了更多工业代码，或者模型结构对形式语言更敏感。我不确定具体原因，但结果摆在那里。
成本这件事，说重要也重要，说不重要也不重要
DeepSeek-Coder的成本在当时大概是GPT-4-turbo的1/30。这个数字我们算过好几遍，以为是算错了。但真正打动我们的不是价格，而是私有化部署。
工业客户对数据特别敏感。食品包装机的控制逻辑涉及配方参数、生产节拍、甚至客户自己的工艺know-how。他们拒绝任何云端推理，要求所有数据留在厂内服务器。GPT-4的API做不到。DeepSeek-Coder可以在本地跑，一个8卡H800就能承载绝大部分推理请求。
但别误会——便宜和私有化只是“必要条件”，不是“选它”的理由。如果DeepSeek生成的代码质量差，白送也不会用。真正让我们做决定的是那个传感器反馈的细节。
后来我们又测了几个场景：工控组态软件脚本、MODBUS通信协议解析、甚至某个老式PLC的汇编指令。DeepSeek在70%的案例里表现比GPT-4好。不是说GPT-4差，而是工业代码生成这件事，大模型们都在半斤八两之间，而DeepSeek刚好在这个窄带上更有特色。
我不敢说它是“最佳方案”
项目交付后，有朋友问我：那以后你们都用DeepSeek了？我说不一定。因为紧接着我们就在另一个项目里换回了GPT-4——那个项目需要生成大量自然语言文档，比如设备操作说明书、故障排查指南。DeepSeek在这类任务上明显弱一档，逻辑跳步、偶尔重复，还需要反复调prompt。
所以这件事没有“全面替代”。就像工具箱里，螺丝刀和钳子各有用途。我写这封信也不是为了证明DeepSeek更好，只是想记录一个真实的选择过程：我们在某个具体场景里，因为一个具体的技术理由（工业逻辑的泛化）加上一个具体的商业理由（私有化部署），选了非主流的方案。
可能6个月后，又出现新模型，这个选择会被推翻。但今天，这个经验值我认了。如果你也在做工业自动化的代码生成，建议自己跑一跑对比测试，别只看榜单。榜单上GPT-4遥遥领先，但现实里那些没人注意的边角场景，恰好是另一批模型的生存缝隙。
这封信写完了。下一封可能又是另一个打脸的故事。