一次 Wasmer 面试暴露的问题：依赖 AI 写代码久了，会看不懂也说不出代码错在哪
Copilot 或 Cursor 已经把很多开发者的日常改造成了同一条流水线：打开 VS Code，框住有问题的代码，快捷键交给 AI，改完跑通，继续往下走。这条路确实快，语法细节和样板代码都不再占用精力，注意力可以放在产品逻辑和架构上。但快了几年之后，有人在一次面试里发现了代价。
那次是 Wasmer 的面试。前半段的 Demo 演示做得相当顺，产品逻辑讲得流畅，功能实现也精准，面试官的反馈很好，当事人甚至觉得这次基本稳了。转折出现在手动代码审查环节——面试官拿出一个简单的缓存小文件，让他现场审查。
屏幕上的代码他盯着看了很久。直觉一直在报警：这里的逻辑有问题，这里面藏着 Bug。可大脑怎么也没法把这股直觉翻译成对方能听懂的技术语言。知道不对，说不出哪里不对，更讲不清该怎么修。整个过程里他只独立指出了一个 SHA 256 哈希值与 16 字节数组不匹配的错误，其余的 Bug 基本都是在面试官的提示下才反应过来。事后他形容那是一种"肌肉萎缩"的感觉——面对代码的反应慢、动作笨，像个没写过几行代码的本科生，而不是一个资深开发者。
问题出在哪？他归因于"快捷键修复"用得太多了。在 AI 辅助的流程里，"发现问题"和"解决问题"被压缩成了一步：觉得代码不对劲，不等大脑做完推演，答案已经由 AI 给出。从察觉错误、分析原因、用专业术语描述问题、到推导修复方案，这条漫长又痛苦的思考链路被整体跳过了。运行"选中 → 修复 → 运行"这个极简循环的次数越多，大脑外包出去的审查能力就越多。直觉还在，因为代码见得够多；但把直觉变成逻辑表达的那套语言系统，已经退化了。他把这叫做"技术失语症"。
Wasmer 那场面试的特殊之处恰恰在于没有 AI。口头审查要求当事人在零提示的情况下，用清晰的术语把代码缺陷讲明白，而这正是长期让 AI 代劳"说话"之后最先丢掉的能力。这里有个值得警惕的分界线：把 AI 当自动修复工具用，和把 AI 当思考增强工具用，短期产出可能一样，脱离 AI 环境的那一刻，差距会立刻显形。
代码审查的本质是逻辑对齐，它要求开发者自己完成三件事：定义问题、分析影响、给出方案。AI 辅助最容易吞掉的，恰恰是"定义问题"和"分析影响"这两个中间环节——AI 直接交付结果，中间过程没人走，也就没人练。
补救的办法不复杂，只是需要刻意。AI 给出修改之后，别急着运行通过，先开口说清楚 AI 为什么这么改；或者在调用 AI 之前，先用自己的语言把 Bug 描述一遍，再去对照 AI 的答案。这些环节看起来低效，但它们正是防止"技术失语症"的训练。真要等到下一次面对没有 Copilot 的白板，或者一场严肃的代码审查，才发现自己只能感知错误、再也无法表达错误，那代价就不是尴尬一场面试这么简单了。
全部回复 （3）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
其实很多开发者都在无意识中陷入这种“技术失语症”，不过这次面试让我意识到，解决问题的关键在于主动切断“选中→修复→运行”的自动化链条，强迫自己在调用 AI 之前，先用自己的语言明确写下问题的核心症状、潜在根因和可能的解决路径。比如在 Wasmer 面试中，我就发现自己在看到 SHA 256 哈希值与 16 字节数组不匹配时，虽然直觉上知道不对劲，但无法立刻用技术术语解释“缓存键长度不一致会导致哈希碰撞风险”。现在我会在 VS Code 中，先手动选中可疑代码，然后强迫自己在注释中写下“这里的哈希输入长度不一致，可能导致缓存命中率下降”，再让 AI 修复。这样至少保证了逻辑链条不被完全外包。
太真实了，我上次用 Copilot 刷题后面试时被问到内存泄漏排查时被问到“缓存文件中 SHA-256 哈希值与 16 字节数组长度不匹配这一低级问题”，但当面试官要求我详细解释为什么这段代码会导致异步操作超时时，我却被卡住了——即使我能通过直觉判断出逻辑漏洞，却无法准确描述“异步任务队列未正确处理重复请求时的回调机制失效”，更不用说具体如何修改了。
这逻辑漏洞也太大了吧，要是刚好撞上那个 L3 缓存命中率，是不是直接就给坑掉了？就像之前说的，"在 PromptCube 潜水一段时间后，我想谈谈一个令人心痛的体感。许多开发者可能跟我一样，开发流程已经固化成一个高效闭环：打开 VS Code，依赖 Copilot 或 Cursor，选中问题代码，按快捷键让 AI 快速修复，运行通过，然后进入下一步。" 这种模式虽然提升生产力，但也可能让我们在关键时刻掉链子。