大模型写代码很强？Sonar给出的结论让不少工程师冷静了

大模型已经能一口气生成成千上万行代码，但这真的等于“企业级可用”吗？在这场演讲中，Sonar 的 Prasenjit Sarkar 用评测数据、排行榜和工程实践给 AI 工程师泼了一盆冷水：问题不在“能不能写”，而在“敢不敢用到生产环境”。

一个让人不安的事实：代码写得出来，不等于能上线

Prasenjit Sarkar 一上来就抛出一个很多团队正在回避的问题：今天这些大语言模型生成的代码，真的“enterprise ready”吗？

答案并不乐观。演示中可以看到，大模型确实能在极短时间内生成大量代码——成百上千行函数、复杂的类结构、完整的业务流程。但问题恰恰出在这里：代码量越大，风险也被同步放大。

Sarkar 指出，他们在实际评估中看到的是“mixed quality code”：有的片段结构优雅，有的却隐藏着安全漏洞、逻辑缺陷和难以维护的设计。更麻烦的是，这些问题往往不直观、不报错、不解释。模型给你一个“看起来对”的答案，却很少告诉你为什么这样写、在哪些边界条件下会崩。

这正是企业团队最害怕的地方：不是 bug 本身，而是不可解释性 + 高代码体量的组合，一旦进了主干分支，后期排雷成本极高。

Sonar的做法：别再凭感觉选模型，用评测把幻想戳破

面对“哪个 LLM 更适合写企业代码”这个问题，Sarkar 直接否定了常见做法：不要只看模型名气，也不要只看 Demo。

Sonar 为此搭建了一套系统性的 LLM 代码评估框架，核心思路很工程化：
- 不只看是否“能跑”，而是看正确性、复杂度、缺陷数量
- 把不同模型放在同一基准下对比，而不是各说各话
- 用真实工程视角，而不是学术任务

他们甚至做了一个公开的 leaderboard（sonar.com/leaderboard），把模型在代码生成任务中的表现量化出来。

在演讲中给出的例子是：Gemini 3.1 Pro High 的 correctness 达到 84.17。这个数字本身很亮眼，但 Sarkar 紧接着强调：这并不意味着“它就可以无脑上生产”。因为正确性只是维度之一，复杂度失控、隐藏 bug 的数量同样关键。

这套评测体系的价值不在于“选冠军”，而在于帮团队回答一个更现实的问题：在你的架构和约束下，哪个模型风险最可控。

真正的问题不是模型，而是我们怎么用模型

演讲中有一句话信息量很大：“我们看到的问题，并不只是模型能力，而是使用方式。”

Sarkar 展示的数据里，一个明显趋势是：模型在面对不同复杂度任务时，bug 数量和代码质量波动极大。有些模型在简单任务上表现稳定，一旦进入复杂业务逻辑，就开始生成不符合工程规范的代码。

这意味着什么？

意味着如果你把 LLM 当成“高级实习生”，让它一次性产出完整模块，你大概率会得到一堆技术债；但如果你把它放进一个受控流程里，它的价值才能释放出来。

为此，Sonar 提出了一个 agent-centric development cycle：
- 不是一次生成完
- 而是生成 → 分析 → 验证 → 再生成的循环
- 中间引入自动化代码分析和质量门禁

在这个模式里，大模型不再是“自由发挥的写手”，而是被约束、被审查、被验证的工程参与者。这其实非常符合企业软件开发的现实，也和单纯的 Chat 式 coding 拉开了差距。

这场演讲真正想说的，是给工程团队的一次“降温”

如果你期待这场演讲告诉你“哪个模型最强”，那你可能会失望；但如果你想知道为什么很多 AI 写的代码进不了生产，它的价值就非常大。

Sarkar 的核心立场并不激进：LLMs 已经很强，也会继续变强；但在企业环境中，代码质量、可解释性和可控性永远比“生成速度”重要。

排行榜、评测框架、agent-centric 流程，本质上都是在做一件事：把 LLM 从“魔法工具”拉回到“工程系统的一部分”。

这对整个行业都是一个信号——真正的竞争，不只是模型参数规模，而是谁更懂软件工程的底线。

总结

这场演讲给 AI 从业者的最大启发只有一句话：别再问“大模型能不能写代码”，而要问“我是否有能力控制它写出来的东西”。 如果你在企业环境使用 LLM，下一步不该是换更大的模型，而是建立评测、验证和质量门禁机制。未来真正值钱的，不只是更聪明的模型，而是能把模型 safely 用进生产系统的工程能力。

关键词： 大语言模型， 代码生成， 企业级软件， Sonar， Gemini Pro

事实核查备注： 需要核查：演讲者姓名拼写（Prasenjit Sarkar）、sonar.com/leaderboard 是否为公开页面、Gemini 3.1 Pro High correctness 84.17 的评测指标定义、演讲发布时间与视频发布时间是否一致