连尤雨溪都看不懂 AI 写的代码了，我们该怎么办？

框架作者看不懂自己框架的代码了

今天刷到尤雨溪（Evan You）发的一段话：

大意是：他让 AI 去做一个非常复杂的 Vue 框架级 feature，一开始页面直接崩了，还以为 Opus 4.6 终于到极限了。没想到指导它启动服务器、用 Playwright 调试之后，居然修好了。他仔细看了一下实现，有些部分理解起来都很费劲——感觉有一天，“看不懂 Vue”这个梗可能真的会成真。

这段话的冲击力在于——说这话的人是 Vue 的创造者。他对 Vue 的理解深度，全世界大概没几个人能比。如果连他看 AI 写的 Vue 代码都觉得吃力，那我们普通开发者呢？

你真的在看 AI 写的代码吗？

这让我想到一个更现实的问题：有多少人会仔细看 AI 写的代码？

说实话，我自己用 Claude Code 写代码的时候，review 的程度取决于场景：

• 核心业务逻辑：会仔细看，因为出了 bug 要自己背
• 工具脚本、一次性任务：粗略扫一眼，能跑就行
• 样板代码、配置文件：基本不看，信任 AI 的输出

我猜大部分人和我差不多。甚至随着对 AI 的信任逐渐建立，“粗略扫一眼”的范围会越来越大，“仔细看”的范围会越来越小。

这不是偷懒——这是人类面对效率工具的自然反应。就像你不会去看编译器生成的汇编代码一样，当 AI 生成的代码持续可靠运行时，逐行审查的动力自然就消失了。

正在发生的三个趋势

第一，AI 的代码风格和人不一样。

人写代码会考虑可读性、团队规范、代码审查时好不好解释。AI 不需要。它优化的是”正确性”和”完整性”，不是”人类读起来舒服”。所以 AI 写出来的代码经常结构上没问题，但读起来就是不太对劲——就像读一篇语法完美但没有灵魂的文章。

第二，复杂度在升级。

尤雨溪的例子特别说明问题。他让 AI 做的是框架级的 feature，不是写个组件、调个接口。AI 已经能在这个层面上工作了，而且它的方案可能涉及你没想过的实现路径。当解决方案本身就超出你的认知范围时，“看懂”就变成了一个奢侈的目标。

第三，调试方式在改变。

注意尤雨溪的工作流：AI 写代码 → 页面崩了 → 引导 AI 用 Playwright 调试 → 修好了。整个过程中，人的角色不是”写代码”或者”读代码”，而是引导 AI 用正确的方式验证和修复。这已经是一种完全不同的工作模式了。

我们到底该怎么办？

我不觉得”坚持看懂每一行代码”是一个可持续的策略。代码量在爆炸，AI 的输出速度远超人类的阅读速度。但完全不看也不行——至少现阶段不行。

我觉得比较务实的做法是：

1. 把精力花在边界上，而不是实现细节上。

你不需要理解 AI 写的每一行代码，但你需要理解它做了什么、输入输出是什么、会影响哪些部分。就像你不需要看懂第三方库的源码，但要知道它的 API 和副作用。

2. 投资测试，而不是代码审查。

与其花时间逐行读代码，不如花时间写好测试。测试能自动验证行为是否正确，不依赖你”看懂”实现。尤雨溪用 Playwright 调试就是这个思路——用运行结果来验证，而不是用肉眼来审核。

3. 学会”对话式调试”。

当 AI 写的代码出问题时，最高效的方式往往不是自己去读代码找 bug，而是描述问题让 AI 去修。这听起来像是在”放弃”，但其实是一种新的技能——你需要准确描述问题、提供正确的上下文、引导 AI 往正确的方向走。

4. 守住架构层面的理解。

实现细节可以交给 AI，但系统的整体架构、模块之间的关系、数据流向——这些你必须清楚。因为当 AI 在某个模块里写出了”正确但不合理”的代码时，只有理解全局的人才能发现问题。

这不是新问题

回想一下，这种焦虑其实不新鲜。

• 汇编程序员曾经看不惯 C 编译器生成的代码
• C 程序员曾经觉得 Java 的自动内存管理不可信
• 后端开发曾经觉得 ORM 生成的 SQL 不够优化

每一次抽象层的提升，都伴随着”失去控制感”的焦虑。但最终，大多数人选择了信任抽象、聚焦在更高层面的问题上。

AI 写代码可能就是下一次抽象层的跃升。不同的是，这次跃升的幅度可能比以往任何一次都大。当 Vue 的创造者都承认自己看不太懂 AI 的实现时，我们也许正在见证一个转折点。

写在最后

我不确定”大部分代码人类看不懂”这一天什么时候会完全到来。也许是明年，也许是五年后。但方向已经很清楚了。

与其焦虑，不如早点适应。把自己从”写代码的人”变成”驾驭 AI 写代码的人”——这个转变，越早开始越好。

毕竟，连尤雨溪都开始这样工作了。