AI、Vim与心流的幻觉

最近，我在工作中越来越多地运用人工智能——而且这一趋势正逐渐成为整个行业的一种普遍期待： 编写更多代码、交付更多功能、更快地发布产品。 你有没有想过，这让我想起了什么？Vim。

我来解释一下，别担心。

我喜欢Vim，甚至多到可以写出“关于编辑的书”， 也足以用Vim来撰写这篇文章。我相信，你一定遇到过那些对Vim或Emacs配置情有独钟的同事； 说不定你本人也属于这样的人。

然而，大多数人对Vim的误解在于：它并不是为了追求速度。 虽然它未必能让你变得更快（尽管确实能），但它真正做的是让你始终沉浸在创作的状态中。 它让文本编辑变得更加轻松——不用再费劲地四处寻找鼠标，也不必把箭头键按住整整三秒半。 你只需轻轻一击，就能删除一句话；或者替换括号内的文本，又或者干脆把括号替换成引号。 在这样的状态下，你无需中断编辑，大脑也能腾出空间，专注于手头的任务。

从表面上看，AI工具似乎也是这样运作的。 它们承诺与Vim所实现的同样效果：减少操作中的摩擦，提升创作流畅度，让你的大脑得以解放， 去思考那些更难、更复杂的任务。而有时，它们的确做到了！ 我曾多次遇到这样的场景：一位AI助手帮助我跳过繁琐的前期搭建步骤，直接切入有趣的架构问题。 这样的体验，真的非常棒！

不过，我认为，AI与Vim之间的差异，恰恰解释了当前工程师们所感受到的诸多不适。

深度问题

当我使用Vim时，输出完全由我掌控。 每一次按键、每一个动作、每一条编辑——都是我意图的直接体现。 Vim是一款透明的工具：它只会按照我的指令行事，绝不会多做任何额外的处理。 它的技能门槛和上限都相当高，但这种关系是坦诚而真实的。 只要学会一种新动作，我就能理解它的作用，并且永远都能预测它的行为。 这里不存在任何“幻觉”——ci) 总会将括号内的文本进行修改。它不会因为误解了上下文，而偶尔将整段文字都改掉。

相比之下，AI工具与操作者的关系则截然不同。 它们的输出看起来像你的作品，读起来也像你的语言，而且无疑比你第一次输入时要更加精致、 更加完美。然而，这些输出却并非你意图的直接映射。 有时候，它们只是微弱的近似；有时候，它们的错误却微妙得让人难以察觉，直到某个隐藏的漏洞被暴露于生产环境后， 你才恍然大悟。

这正是我所说的“深度问题”。当我使用Vim时，没有人能仅凭阅读我的代码， 就判断出我是用Vim、VS Code，还是用Notepad写下的。 在最终的产物中，这个工具几乎隐形无迹。 而这其实再好不过——甚至可以说，这正是它的优点所在：因为输出的质量，依然完全取决于我本人。 我对问题的理解、我对代码库的经验、我对边缘情况的判断、我创造出优雅代码的能力——所有这些因素， 都会在最终的产品中清晰可见，无论我当初是用哪种编辑器来完成这段代码。

而AI则完全颠覆了这一局面：在最终的产物中，工具的痕迹显而易见——它塑造了输出的风格、 结构和精致度——但操作者的技能水平却变得无形无影。 结果，每一段代码、每一份拉取请求，都显得同样游刃有余、能力出众。 你无法从一次拉取请求中分辨出，作者是花了三十分钟精心引导AI处理边缘情况， 还是仅仅在第一个建议上直接点击“接受”。

这其实是个巨大的问题。因为在过去，一个糟糕的拉取请求很容易被一眼识破。 很多时候，一位初级工程师会通过不遵循样式指南或既定规范来给你“提示”，而这些“提示”往往会在不经意间泄露你的意图， 最终让你发现一个严重的bug，或是遗漏了一个关键的边界情况。

然而，AI生成的输出总是显得格外精致、格外完美。 我们因此失去了一项至关重要的指标——一项能让工程领域充满成就感的“触手可及”的感觉。 如今，每一行代码、每一份拉取请求，都成了嫌疑对象。 而这样的状态，实在令人疲惫不堪。

“完成”与“正确”之间的差距

我刚刚读到了伊万·图尔科维奇那篇精彩的人工智能让写代码变得更容易。 这让做工程师变得更难了（感谢Ben的分享），并且完全同意他的核心观点： 从“完成”到“正确”之间的差距正在不断扩大，而且还在以惊人的速度加剧。

你知道最让人恼火的是什么吗？当你的项目经理能在下午就完成一个原型，并且还指望你在周五之前把那个原型“全部完成”。 或者，如果他们当天心情特别好，甚至希望“全部完成”这个词能被理解为“当天就搞定”——当然， 我的项目经理都很棒，而且幸运的是，他们从不这么干。

不过说实话，我并不怪他们。这个原型看起来很棒：它拥有真实的数据，能够顺利通过“快乐路径”， 甚至还带有一个加载 spinner。它看起来就像一款产品。 如果我还能用AI工具在短短两小时内完成这个项目——那么，对于一名全职工程师来说， 把它完整地做完，又有多难呢？

当然，答案是：最后的10%工作，往往占了90%的精力。 边缘情况、错误处理、验证、无障碍设计、安全性、高负载性能、与现有系统的集成、 可观测性——这些环节在原型中根本无处可见，而AI工具尤其擅长产出那些完全缺乏这些要素的作品。 原型的完成度远未达到90%，它看起来“不错”，却只完成了90%。

当然，这其中也包含着教育的成分——我们需要明白，表面的精致与结构上的扎实之间有着本质的区别。但这里还有更深层次的问题，而单纯依靠教育，往往难以彻底解决。

同理心的鸿沟

我的朋友兼同事萨拉说得比我更好：我们真的需要学习同理心。

她指的是这样一件事：当项目经理只需利用AI在下午就能快速搭建出一个可用的原型时， 他们开始相信——哪怕是在潜意识里——自己已经真正理解了工程工作的内涵。 当工程师借助AI生成面向用户的文档时，他们也开始认为，技术撰稿人的工作其实很简单。 当设计师使用AI来编写前端代码时，他们不禁疑惑：为什么团队还需要专门的前端工程师？

而这些人都没有错——他们所经历的一切，的确如此。 项目经理真的造出了一个可用的原型；工程师真的完成了合格的文档； 然而，他们得出的结论——“自己完成了对方的工作”，并因此认为这项工作“轻而易举”——其实是完全错误的。

说到萨拉，她是一名资深用户体验研究员，确切地说，她是“萨拉博士”。 我有幸参与了一篇研究论文的撰写，我用AI来整理自己的贡献内容，而我为此感到无比自豪——因为这些内容看起来和我多年来阅读的无数研究论文中所看到的完全一致。 萨拉仔细翻阅了我的贡献，对她而言，我简直太了不起了。 然而，当她坐下来认真阅读我的文字时，却不得不从头开始重新撰写我“贡献”的几乎所有内容。

AI让每个人都有了一种近乎表面化的参与能力，几乎可以胜任任何领域或任何角色。 而这种表面化的能力，恰恰是最危险的一种——因为它往往伴随着浅薄的理解和满心的自信。 现代知识型岗位的工作，往往可以通过其输出来衡量。 技术撰稿人凭借他们所撰写的文档，设计师凭借他们的原型草图，软件工程师则凭借他们的代码。 然而，这些成果本身，并非每个岗位的核心技能。 技术撰稿人擅长将复杂的概念拆解成大多数人能够理解并内化的内容； 设计师则具备敏锐的直觉，能够洞察人们的行为方式以及他们与各种事物互动的方式； 而软件工程师则擅长解决问题。AI工具却无法做到这些。

未来的路，不是要对AI生成的贡献加以限制或视而不见，而是要培养组织内部的同理心——真正理解： 每个专业领域都有其外人难以察觉的深度； 而一台能够让你在他人领域中完成作品的工具，并不意味着你真正理解了那个领域。

当然，这个问题由来已久：自软件诞生之初，工程师就一直低估设计师； 项目经理也同样低估工程师。然而，AI却为这场争论添上了新的燃料，让每个人都觉得自己仿佛是一位全能的“通用型人才”。

那么，我们究竟该怎么做？

我不想再成为那个写下又一篇“AI正在毁掉一切……”的人。