AI 助手越顺手，我们越不认识机器

unix.foo 6 月 26 日刊发的一篇文章，开头不是谈 AI 大趋势，而是谈 1990 年代玩电脑游戏。

那时想让一款游戏跑起来，可能要改 autoexec.bat，做启动盘，调声卡 IRQ。中断号配错，游戏就没声音。调制解调器拨号时的尖叫声，也会把连接过程直接摊在用户面前。

今天的体验反过来了。你对 ChatGPT 或 GitHub Copilot 说出需求，系统会尽量给答案、补代码、道歉、重试。机器变得顺从，摩擦被抹平。

这篇文章有意思的地方，不是怀旧，也不是说年轻一代“不懂电脑”。它更像是在提醒一件事：知识还在，但人与机器通过失败建立的熟悉感，正在减少。

只有会让你失败的东西，才可能被你真正认识。

90 年代电脑用阻力逼人学习

MS-DOS 和早期 Windows 时代，个人电脑不是一个默认可用的黑盒。很多操作今天看很笨，但当时用户绕不过去。

游戏需要常规内存。声卡要选 IRQ。启动盘要自己做。跳线、配置文件、驱动冲突，都会让机器停在那里。

这种体验低效，也很烦。但它有一个副产品：用户会被迫看见机制。你不懂一点底层规则，就无法继续。

对比放在今天，变化很清楚：

这里的重点不是“以前更好”。以前的电脑确实难用，很多麻烦本该被产品消灭。

问题在于，摩擦消失以后，一种关系也跟着变少了。你不再知道机器会在哪里掉链子，也不再需要记住一次错误为什么发生。

能力没有消失，消失的是熟悉

关于 AI 工具，常见担忧是“以后没人会修底层系统”。这个说法太重，也不够准。

技术能力没有简单消失。开源社区、官方文档、问答网站和模型训练语料，让知识比过去更容易被检索、复制和解释。很多人今天解决问题的速度，确实比过去快。

ChatGPT 在 2022 年 11 月发布后，自然语言成了调用计算能力的新入口。GitHub Copilot 也把代码补全变成许多开发者的日常动作。少写样板代码，少查重复文档，少在低价值问题上耗时间，这些收益都是真实的。

但原文区分了两件事：competence 和 acquaintance。

competence 是能力。你知道怎么做，能完成任务，能调用工具。acquaintance 是熟悉，是你和一个系统打过交道、吃过亏、改过错之后形成的亲历关系。

AI 可以解释“调制解调器如何握手”。但它不会让多数用户真的听懂一次拨号失败前，那段异常声响意味着什么。

这不是知识贫乏，而是距离变远。你知道更多答案，却未必更认识机器。

对经历过早期个人电脑和互联网的技术读者，这个变化会有一点别扭。很多人的技术直觉，来自早年被配置文件、网络连接、驱动冲突折磨出来的经验。现在带新人，不能默认他们也走过这段路。

更实际的做法，是把“失败现场”留进训练里。比如让新人看日志，手动复现 bug，解释一次回滚原因，而不是只让 AI 给出修复建议。

对关注 AI 改变人机关系的科技从业者，判断标准也要调整。不要只看工具答得快不快，还要看它是否留下可审计的过程。能不能看见改了什么、为什么改、风险在哪里，比一次漂亮回答更重要。

真正该观察的是工具还让不让人看见机制

最受影响的不是普通消费者。普通用户没有义务理解每一层协议，也不该为了使用服务去学习底层机制。

受影响更深的是开发者、技术教育者和依赖自动化工具的团队。他们需要效率，也需要判断力。两者会发生拉扯。

开发者团队可以继续用 AI 提速，但最好把几件事变成硬流程：关键代码必须人工复核，测试不能省，生成代码要能追踪来源和修改记录。否则，“能跑就行”会慢慢变成默认标准。

技术教育者也不能只教提示词。命令行、日志、手动排错、版本回退，这些东西不够顺滑，却能训练判断。学生至少要见过系统如何失败，才知道工具给出的答案哪里可能有坑。

这里也有现实约束。不是每个团队都有时间做完整复盘，也不是每门课都能塞进底层训练。AI 工具带来的效率收益太直接，很多组织不会为了抽象的“理解机器”主动降速。

所以更可行的观察点，不是“用不用 AI”，而是看三个变量：

这不是要求产品故意变难。便利不是罪。

真正的问题是，专业场景不能只追求顺从。工具越会替人兜底，人越要主动保留一点摩擦。否则能力看似还在，熟悉感已经空了。

原文结尾写到调制解调器连接声：拨号音、嘶声、静电噪声，直到两台机器终于谈妥。

今天的电脑可以立刻、完美地播放这段录音。它不需要用户理解自己为什么能做到。这是现代计算的胜利，也是它留下的缺口。