要不是有编译器 大模型编程一样是笑话

寂静回声

编程是一种形式化语言，拥有严格、二元化的规则。如果大模型 “幻觉” 了一个函数名，或者漏掉了一个分号，编译器会立刻捕捉到错误。
而在机械设计等非 IT 领域，其 “语法” 就是灵活的自然语言。
大模型完全可以用完美的语法陈述一个彻头彻尾的谎言，而没有任何 “机械编译器” 来抛出报错信息。

IT编程可即时验证，而非依赖“权威感”。
复制代码到 IDE，点击运行，几秒内就能知道能否编译、能否跑通、输出结果是否符合预期国。
哪怕是逻辑问题，写几个测试用例就能快速验证。
但是光有一个编译器也不够，编程语言的特点，比如语法、语义、执行逻辑，由语言规范、运行时环境严格定义，对错有绝对、无歧义的边界也是非常重要的约束。去掉了自然语言的模糊性。

编译器能做的，仅仅是验证代码的语法正确性、基础语义合法性，它无法验证代码的逻辑是否正确、性能是否达标、是否存在安全隐患。比如你让大模型写一个加法函数，它给你写成了乘法，编译器不会报任何错误，但运行结果完全不符合预期 —— 这个错误，依然需要你通过「输入输出的结果比对」来验证，而非编译器。
但哪怕只有这一点，也已经和机械设计问题拉开了巨大差距：
对于编程，哪怕你完全不懂代码，也能通过 “复制到 IDE 里能不能跑通”，快速完成最基础的对错判断；
对于机械设计问题，哪怕是最基础的事实对错，你都需要具备对应的领域知识，或花费极高的成本去查证，否则根本无法分辨。

但是不要神话大模型，很多新手用大模型生成代码时，也一样会被 “糊弄”。
大模型会编造不存在的库、API、参数，甚至写出语法完全错误、根本无法编译的代码。
生成的代码能跑通，但存在内存泄漏、SQL 注入、越权访问等安全隐患，或边界条件处理缺失、性能极差、可维护性为零。
针对复杂系统架构、算法设计，给出看似合理但完全无法落地的方案，新手同样无法分辨。
只是这些问题，有明确的、低成本的方式可以快速验证，而非 IT 问题的 “糊弄”，普通人几乎没有低成本的验证手段。
比如针对零件热处理的方案设计，是否合理，总不能真去实践吧，那成本可高了。就得需要自己懂，去验证是否合理。

所以有人是得了便宜卖乖，忽略行业特点在那装逼。