AI生成代码的真正难题：谁来验证、谁来负责

最近，一档技术访谈节目的内容在社交平台上被反复转发。其中最扎心的一句，被网友浓缩成了这样一句话：“资深开发人员宁愿退休，也不愿处理 AI 生成的代码。”严格说，这并非受访者的原话，更像是情绪的提炼。但它能病毒式传播，恰恰说明它戳中了当下无数一线开发者的真实处境：关于 AI 写代码的争论，早已跨过“它能不能生成代码”的阶段——真正的问题变成了：生成之后，谁来验证、谁来理解、谁来为系统长期运行的后果负责。

说这句话的人值得被认真对待。有网友评论：他写系统代码的年头，比大多数 AI 工程师的年龄还长。这位从上世纪八十年代起亲手设计了一门系统级编程语言、并推动其标准化四十余年的老工程师，在访谈中直言：“AI 生成的代码更臃肿，有更多 bug 和安全漏洞，而且很难验证。”当这样背景的人说“验证才是真正的问题”时，这不是对新事物的保守抵触，而是几十年里一次次目睹系统出错、却难以追溯到问题源头之后，沉淀下来的经验判断。

一、争议焦点已经转移：从“生成能力”到“验证成本”

过去几年的讨论大多停留在“AI 能不能写出可运行的代码”。今天这个问题基本有了答案：只要上下文给足，大模型完全可以产出语法正确、逻辑大体自洽的实现。但“能运行”与“值得信任”之间，隔着一整条工程鸿沟。受访者对生成代码的概括相当直白，三点都可以拆开看：

• 更臃肿：为了“通用与稳妥”，模型倾向堆叠防御性代码、引入多余的抽象层与重复实现；代码量膨胀之后，理解成本与维护面积同步上升。
• 缺陷与安全漏洞密度更高：生成本质上是对训练分布的采样，安全史上“曾经常见”的写法，会被稳定地再次采样出来。
• 难以验证：这些代码没有经过人类“设计—推敲—取舍”的过程，评审时缺少可追问的意图链，你很难回答“它为什么这样写、换个写法会怎样”。

三者叠加指向同一个结论：AI 把“写出代码”的成本压到近乎为零，却把成本整体转移到了“确认代码正确”上。对生产系统而言，验证恰恰是最不能压缩的环节。这笔账不会消失，只会在系统运行的某个深夜里连本带利地兑现——可以称之为“验证债”。

二、为什么 AI 复刻的是“旧代码”：训练数据的路径依赖

更根本的制约来自训练数据。大模型的能力建立在海量存量代码之上，而这些代码横跨数十年的工程史，混杂着大量过时 API、已被证明有风险的模式、特定历史条件下的性能假设。受访者的表述相当精辟：“模型用旧代码训练，生成的代码是在模仿旧代码，得到旧的性能和旧的 bug。”

这意味着你拿到的，很可能是“语法上的新项目、语义上的旧系统”。示意性地看一段典型的生成代码：

# 示意代码：每一行都"眼熟"，却埋着三个典型隐患
def load_user(user_id):
    conn = open_database()                 # ① 未处理连接失败
    rows = query(conn, "id=" + user_id)    # ② 直接拼接外部输入，存在注入风险
    return rows[0]                         # ③ 空结果直接越界

这段代码的可怕之处不在于错误有多隐蔽，恰恰在于它“太像教科书”：正因为眼熟，评审时反而最容易被放过。而注入、越界、未处理失败，恰好都是几十年安全史里被反复教育过的旧教训。模型不是不知道这些教训，而是训练分布里旧写法的浓度足够高，采样就会稳定地回到旧习惯上。

三、从内存安全谈起：缺陷来自使用模式，而模型正是使用模式的放大器

访谈里还有一句颇具争议的判断：90% 以上的内存安全漏洞并非语言本身的缺陷，而是“人们写的是老派风格的代码”。暂且不论这个比例，这个观察揭示了一个层次更深的机制：安全漏洞主要来自使用模式，而不是工具本身。

任何一门演化了四十年的系统级语言，都会长出远比当年安全的现代用法——更严格的类型、自动化的资源管理、显式的错误传播、边界检查。语言设计者能做的是提供更安全的工具，却无法禁止使用者沿用几十年前的习惯。而大模型是什么？是“使用模式”的采集器与复制器。人类工程师改掉一个旧习惯，需要十几年行业教育与一次次事故复盘；而以旧代码为养料的模型，天然就是旧习惯的放大器。所以“验证才是真正的问题”并非保守的抱怨，而是这个机制的必然推论：当缺陷的主要来源是使用模式，而生成机制又专门复刻使用模式时，验证的担子只会更重，不会更轻。

四、四十年语言演化的方法论，条条指向 AI 工具的引入方式

这场访谈并不只谈 AI，也系统回顾了一门主流系统语言四十余年的演进与标准化历程。有趣的是，这些历史经验几乎每一条都能映射到“团队如何引入 AI 编程工具”上。

1. 迭代成长，而不是一步到位。“先做到你能做到的最好，然后观察哪些有效、哪些无效，修复问题，再重复——这门语言就是这样成长起来的。”复杂系统的演化没有蓝图，只有循环。引入 AI 工具同样应该小范围试点、设定度量、观察效果、修复问题、再扩大范围；指望一次性建成“全自动开发流水线”的团队，最终收获的往往是一笔失控的验证债。

2. 先加固根基，警惕功能堆砌。“必须先确保它不是一堆随机功能的堆砌，因为那就是 complexity。”对 AI 工具链同样成立：关键从来不是接入多少模型、生成得多快，而是架构规范、评审流程、测试体系这套“根基”是否先立住。根基不牢，生成速度越快，系统腐烂越快。

3. 不要妥协你的测试。这是访谈中被着重强调的一条：“不要妥协你的测试，这非常危险。”在生成成本趋近于零的时代，测试与评审是最后的质量闸门。任何“因为代码是 AI 写的，测试可以简化一点”的念头，本质上都是在拿生产环境做随机实验。

4. 高层说“必须做”，不一定对。技术决策的裁判应当是度量数据与一线反馈，而不是愿景与压力。

访谈里还有两处耐人寻味的注脚。一处是：为解决一个技术分歧，标准制定者曾在两家老牌硬件巨头的工程团队之间来回斡旋，最终促成折中方案写入标准；多年后双方都承认，他们实际采用的是两套方案的组合。另一处是：这门语言三年的营销预算只有 5000 美元，而同期某竞品语言的营销投入“比它全部开发费用还多”。前者说明好的工程结果是验证与融合出来的，不是天才方案一步到位的；后者说明一项技术能活四十年，靠的不是声量，而是被反复验证过的可靠。这两点，恰好也是当下 AI 热潮最缺的两味清醒剂。

五、砍掉初级程序员：一个结构性的隐患

整场访谈中最容易被略过、却可能影响最深远的，是关于人才结构的反问。不少企业的算盘是：AI 能干的活，就不再需要初级程序员——“人数太多，成本太高”。受访者的回应很直接：把初级程序员都砍了，将来又从哪里去找资深程序员？

资深工程师不是凭空长出来的，他们是在一次次真实故障的排查、复盘、重构中，被“验证的痛苦”训练出来的。如果行业系统性停止这种训练，会出现两个后果：其一，断层——五年十年后，没有人具备接手并验证复杂系统的能力，而这恰恰是 AI 时代最需要的能力；其二，失衡——团队里只剩下擅长“生成”的人，却没有擅长“确认”的人，系统复杂度一旦上升，整体效率会断崖式衰减。换句话说，AI 时代最稀缺的不是“会写代码的人”，而是“能判断代码对不对的人”——而后者的培养周期，恰恰最长。

六、给个人与团队的落地建议

1. 学“不同的语言”，而不是“更多的语言”。访谈中有个对个人成长极有价值的建议：重要的不是学哪些语言，而是获得语言中蕴含的思想；应该去学和当前所用语言不同的语言。背后的逻辑是：判断力来自对设计空间的整体理解。只在一个技术栈里打转的人没有参照系，无法判断一段生成代码“好还是不好”。去接触类型系统、并发模型、内存模型、错误处理范式都截然不同的语言，理解它们各自的取舍，“验证直觉”才会真正成形。

2. 把 AI 当“初稿生成器”，不当“终审”。生成之后的评审、测试、验证一个都不能少，反而要更严。可直接落地一份 AI 代码评审清单：

□ 外部输入是否全部校验（空值/长度/编码/越界）
□ 失败与异常路径是否处理完整，资源是否释放
□ 是否引入了不必要的依赖、抽象或重复实现
□ 是否复用了过时 API 或已知有风险的写法
□ 关键路径是否有测试覆盖
□ 日志与监控埋点是否保留，支持线上追踪

尤其对于运行在百度智能云等云平台之上的生产系统，日志、监控、告警这类可观测性能力是“事后验证”的生命线——AI 生成的代码若丢掉了这些埋点，再精巧也难以安全投产。

3. 用度量决定工具的边界。延续“观察哪些有效、哪些无效”的思路，团队应持续跟踪缺陷率、返工率、评审耗时、线上故障数等指标，用数据划定 AI 工具的适用边界，而不是用热情划定。

4. 保留“理解—修改—验证”的闭环。让初级工程师即便在 AI 辅助之下，也必须经历读懂代码、亲手修改、亲自验证的完整过程；让资深工程师的隐性经验（哪里容易坏、如何定位）通过评审与复盘制度化地传承下去。生成可以外包，理解不能外包。

七、结语

“资深开发人员宁愿退休，也不愿处理 AI 生成的代码”——这句转述之所以能击中行业，是因为它替一个群体说出了焦虑：当代码的生成成本趋近于零，验证、理解与承担责任的能力就成了真正的稀缺品。

AI 不该被拒绝，它确实能实打实地提升局部效率。但如果一个行业把“生成”当作全部，把“验证”当作成本，用速度的快感去交换质量的根基，那么最终为旧性能、旧缺陷、旧习惯买单的，仍然是系统本身，以及守在系统旁边的人。

先做到你能做到的最好，观察哪些有效、哪些无效，修复问题，再重复——无论是长成一门语言，还是接纳一类新工具，这大概都是最朴素、也最有效的路径。