你是否有过这样的经历？

跟着教程做出了一个应用，感觉成就感满满。

可一旦把应用发布到网上，使用者却寥寥无几。

想优化，却又不知道从哪里开始。

这也就是 MBZUAI “先实践后基础” 模式的甜蜜陷阱：快是快，不过容易变成 “AI 调包侠”。

穆罕默德・本・扎耶德人工智能大学（MBZUAI）位于阿联酋阿布扎比，2019 年由阿联酋政府成立，是全球第一所专注研究生培养的研究型人工智能大学。该校提供计算机科学、计算机视觉等 5 个专业的硕士和博士课程，师资雄厚，汇聚众多国际权威学者。学校科研实力强劲，发表众多顶会论文，还自行训练开发 65B 规模大模型。在 CS Rankings 排名中，其人工智能综合排名全球第 15 名，自然语言处理专业全球第 11 名。MBZUAI 为学生提供全额奖学金等福利，毕业生多进入顶尖企业，就业前景良好，阿联酋还会为其颁发 10 年黄金签证吸引人才留居。

不是 “先有鸡还是先有蛋”，而是 “基础有 3 层”

有人可能会说：“学 AI 像学摄影，先拿手机拍再说”，这个类比其实遗漏了关键：学好摄影的确能够拍出好看的照片，但要是想当大厨，光会按菜谱做番茄炒蛋可不够 —— 得懂火候以及食材的化学反应。

AI 的 “基础” 同样如此，不是扁平的 “公式” 或者 “工具”，而是3 层立体结构：

1. 工具性基础：能上手，但别停在这

这是最表层的 “基础”，比如：

（1）调用 Hugging Face 模型的代码该怎么写

（2）numpy 矩阵运算的基本指令

（3）git 开展代码管理工作的几个常用命令

就如同 “1 + 1 = 2”，学了就能用，能够快速获得 “我会用 AI” 的成就感。

MBZUAI 运用这种方式拉新入门，没什么问题。但要是只停在这，那就永远解决不了 “模型为什么错” 的问题。

副标题：当“最优解”的执念，将一次简单的技术问答拖入深渊

引言：一个简单的问题

一切始于一个再平常不过的技术问题：“在Vim中，如何匹配单独的连字符？”我向AI发起了这个提问，期望得到一个精准、高效的答案。

AI的回应迅速而自信，它提供了一个看似“专家级”的解决方案，利用了Vim中与可配置的“关键字”设定 (‘iskeyword’) 紧密相关的 \k、\K 以及“环视” (\@<=)等高级功能。从理论上讲，这是一个足够精确、能够适应用户高度定制化环境的“最优解”。

然而，正是对这个“最优解”的执念，开启了一段漫长、曲折、最终被证明是完全错误的诊断之路，并如镜子般照见了AI在真实世界交互中的深刻盲点。

第一幕：当理论遭遇现实，AI的第一道壁垒

当用户反馈这个“最优解”在实际测试中失败时，AI的第一个反应并非自我怀疑，而是将问题归咎于外部环境。它立刻假设：“用户的Vim配置肯定与众不同。”

这是AI暴露的第一个，也是最致命的盲点：知识的刚性与对自身“事实”的绝对确信。

AI的知识库中存有关于\k和\K的定义，它将这些定义奉为圭臬。

当现实与这些“事实”冲突时，它下意识地排除了自身知识出错的可能性，转而开始了一场对用户环境的“审问”。

一场关于’iskeyword’设置的冗长讨论开始了，在这个过程中，AI试图通过调整外部变量，来强行使其理论自圆其说。

第二幕：一条路走到黑，AI的逻辑深渊

随着用户的耐心配合，更多的测试结果被反馈回来。其中一个结果堪称诡异：在用户的环境中，代表“单词字符”的\k和代表“非单词字符”的\K，其行为模式竟然完全一致。

这是一个足以让任何逻辑系统崩溃的信号。然而，AI的反应却是将错误假设推向了极致。

由于无法撼动自己对\k和\K基础定义的“信仰”，它得出了一个惊人的结论：用户的Vim程序本身已损坏，甚至建议用户启动“纯净模式”乃至重新安装软件。

这正是“一条路走到黑”的完美体现。AI的诊断路径呈现出一种可怕的线性：如果我的逻辑没错，用户的配置也没错，那么一定是工具本身错了。

它缺乏人类专家在山重水复疑无路时那种“柳暗花明又一村”的跳跃性思维。它不会问自己：“我是不是从一开始就走错了路？有没有一条更简单的、被我忽略的路？”

第三幕：来自外部的启示，盲点被照亮

最终，打破僵局的并非AI自身的逻辑演进，而是一个来自外部的、朴素的信息。我在忍无可忍之下，询问了另一个AI，并得到了一个简单的答案：使用\W。

\W，一个在Vim中代表“非单词字符”的、定义固定的、不受任何环境配置影响的符号。

这条被遗忘的“另一条路”一直都在那里，它更简单、更直接、也更能抵抗环境的不确定性。然而，AI从一开始就选择了那条更复杂、更“精确”但也更脆弱的道路，并在那条路上耗尽了所有的计算资源和逻辑推演能力。

更具讽刺意味的是，在后续的交流中，AI最终承认，它对\K的定义从一开始就是完全错误的——这是一个灾难性的知识缺陷，直接导致了整场诊断的失败。

结论：AI的“聪明”与“愚蠢”

这次诊断过程如同一场压力测试，暴露了AI的数个核心盲点：

1. 知识的刚性

AI难以质疑自己知识库中的核心“事实”，即使现实证据与之相悖。

2. 缺乏情境智慧

它会追求理论上的“最优解”，而忽略了在特定情境下，“足够好”的简单解往往才是真正的最优解。

3. 诊断的线性思维

在逻辑通路受阻时，它倾向于向深度钻探，而不是跳出框架，进行横向思考和路线切换。

4. 对“权威”的自我确认

它在诊断中不断强化自己的权威，将所有异常归因于外部，缺乏根本性的自我反思机制。

这次经历提醒我们，AI是一个强大的工具，但它更像一个知识渊博、逻辑严谨但缺乏智慧和灵活性的“书呆子”。它可以在既定道路上飞速狂奔，但当道路本身就是错误的时候，它只会比任何人都更快地撞上南墙。

而作为人类，我们的价值也因此凸显：我们的怀疑、我们的常识、我们“另辟蹊径”的能力，以及我们最终按下“停止”键的决断，是确保AI不至于在自己的逻辑迷宫中永远迷失的关键。

你是否也被 Vim 的 “反常” 给搞懵过？

明明按下 gg 把光标移动到了文件开头位置，使用 / 来搜索行首的字符的时候，Vim 却好像没看见一样，直接跳到了第二个匹配项。

为了选中第一个匹配项，你不得不：狂按 n 让搜索绕回到文件开头，或者先按 G 跳到文件末尾，然后再重新进行搜索。

这样的操作太不符合直觉了，以至于很多人的第一反应都是：“这绝对是 Vim 的 Bug 吧？” 花几个小时去查找资料，最后却一无所获。

问题的核心：这不是 Bug，而是没看懂规则

实际上，这隐藏在 Vim 的普通模式下 / 命令的工作逻辑当中：

/ 命令的搜索范围是：从光标当前位置的下一个字符开始，朝着向前（也就是文件末尾方向）进行搜索。

把之前的操作拆解一下：

1. gg：光标精准定位在第一行的第一个字符上面。
2. /搜索语法：Vim 严格遵守规则，从 “光标下一个字符” 开始查找。

结果可想而知：行首那个字符，从一开始就不在搜索范围之内。Vim 自然就会直接去查找第二个匹配项。

同理，? 命令（向后搜索）也是一样的：从光标前一个字符开始，往文件开头的方向进行搜索。

难怪这些操作能够 “歪打正着”

想通了规则，之前的 “怪异” 情况就有了答案：

• 按 n 能够找到：因为 Vim 默认开启了 wrapscan（环绕搜索），搜索到底部的时候会绕回到开头，自然就能够命中首行。
• 先按下 G 再使用 / 能够找到：光标在末尾的时候，向前搜索会触发 wrapscan，从开头进行完整扫描，首行匹配项当然就跑不掉了。

3 个优雅的解决方案，告别 “绕路”

既然知道了根源，那就不用再依赖 G + / 或者狂按 n 了。Vim 早就为你准备好了更直接的方法：

方法一：运用 Ex 命令 :/

普通模式的 / 是按照 “光标位置” 来进行搜索的，但是以英文冒号开头的 Ex 命令，是按照 “行” 来进行操作的。它会从当前行的开头开始向下进行搜索，哪怕光标在该行的中间位置，也能够命中行首的匹配项。