AI 1分钟写800行代码，我花2小时审查：这波亏了吗？

AI 1分钟给我生成了800行代码。我当时就震了——这是什么神仙效率？
然后我花了2小时审查。
这笔账怎么算？咱们程序员最讲究投入产出比，这波操作看起来像是赚了，但仔细一算……好像我才是那个打工人。

---

不是伪代码，不是能跑一版的demo，是正儿八经能上线的Python代码——测试、异常处理、API集成，该有的都有。我当时的感觉就是：卧槽，这什么神仙效率。

AI把功能给你整完了，你去倒杯咖啡回来，代码就在那儿等着你了。这种上帝模式谁不想开？谁还愿意一行一行敲代码啊？

但你以为这就完了？

承诺很丰满，现实很骨感

这就是各种AI编程工具给你画的大饼——Zencoder、vibe-kanban，包括Cursor的部分功能。有个叫Steve Yegge的哥们造了个词叫“氛围编程”（vibe coding）：别管细节，信任AI，让它给你整，你只管把控大局。

听着挺玄乎，用起来确实爽。直到你开始审查代码。

那800行代码，我每行都得看。每个函数、每个边界情况、AI自己脑补的需求假设……

• 验证做对了吗？
• 这代码以后谁维护？
• 是不是把某个业务逻辑漏了？

审查花的时间，比我自己写还长。

最骚的是，审查完我还是心里没底。于是我让另一个AI去审第一个AI写的代码——还真给我挑出问题来了。我改了问题，然后又开始审查：AI改得对不对？

我陷入了三层审查套娃——感觉不像是在写代码，像是在带实习生，而且这实习生你当面沟通不了，只能通过git diff交流。

然后是PR（Pull Request）。我让队友来审查这800行AI代码？他们要么花几个小时审完心里骂娘，要么自己也扔给AI审——到头来我们都在信任机器，不是信任代码。

所以我们还是程序员吗？

这个问题我得问：当AI写代码、AI审代码，我们就负责点个“同意”——这还是编程吗？

或者我们成了自己没写的代码的产品经理？

可能有人会说：没关系啊，AI现在这么强，用就完事了。

我不这么认为。还不是时候。

我经常发现问题：AI漏掉的bug、它不理解的模式、它忽略的边界情况。这种“大爆炸”式交付功能的方式让我很不安。我需要确保AI按照我对问题的理解来构建正确的东西。

而做到这一点的唯一方式，就是认真审查、保持接近代码、真正理解在造什么。

一个Vim老玩家的探索史

我用Vim很多年了。不是那种“ btw我用Vim”的装X党，而是我的手指比WASD更熟悉hjkl的那种。肌肉记忆深到骨子里。

所以当AI编程工具炸场的时候，我有个选择：跟风去用VS Code，或者想办法让AI在我的世界里跑。

说清楚：我坚持用Vim不是因为我固执。 我试过替代方案，我一直在试。

Cursor：吹得最凶，手感最远

Cursor确实猛：真正的AI优先，内联建议和聊天功能像魔法一样。

但问题是：你离代码太远了。你在指挥AI，AI在指挥编辑器。中间隔着层抽象，我信不过。我希望我的手离底层更近一点。

Zed：编辑器不错，workflow碎了

Zed的平衡更好：它以代码为中心，AI工具挂在一旁——你决定什么时候用。这点我喜欢。

但Zed假设你一次只处理一个项目。这直接把我的工作流程干碎了。我生活在tmux里，同时开着3-4个项目，不断切换上下文，把一个终端的输出pipe到另一个终端。Zed不符合这个现实。

Zencoder & vibe-kanban：极致派，离谱到家

然后我走到了另一个极端：完全以AI为中心的工具，比如vibe-kanban和Zencoder。读了Steve Yegge那篇“氛围编程”的文章后，我还真试了这条路。

想法很诱人：别微观管理AI了，信任氛围，让它给你整功能，你只管大局。

这些工具疯得离谱。你描述你想要的，它就把整个功能、测试、API集成全给你整了。感觉盒子里真有个高级程序员。

Zencoder尤其让我惊艳。你感觉自己超强。你快速交付。

但问题是：你离代码的距离荒谬地远。

AI写它。AI组织它。你像经理审PR一样审diff。但我对AI没那么信任。它写的每一行，我都得重新审。符合标准吗？可维护吗？边界情况漏了吗？审查开销是实打实的。

我意识到： 我还是得详细审查代码，确保功能往正确的方向走。“信任氛围”听着解放，实际上我做了更多认知工作的审查，比开发时盯着它还要多。

我找到了中间地带：AI是副驾驶，我是司机

所以我找到了一个平衡点：和AI小步结对编程。 AI干大部分活。我监督，让它别跑偏。我实时纠偏，而不是事后审一堆diff。

我发现最好的方式还是Neovim + tmux：AI在一个窗格，代码在另一个，不断来回交流。

我不再用以前的方式写代码了。以前我会打开文件，想问题，然后输入。现在？我开个worktree，在终端窗格里打开AI，而不是逐个字符敲。

但我保持接近。我监督。我实时纠偏。

AI干重活。我思考。这不是纯氛围编程，也不是单独编程。它是协作的，我保持足够接近，能及早发现问题。工具不同。媒介相同：终端。

终端里的AI：多种工具，一个workflow

真正的转变不是找个完美的插件。而是搭个workflow，让我不离开终端就能用任何适合任务的AI工具。

有段时间我试了各种方法：分割buffer里的Claude Code，tmux窗格里的Codex，在不同终端窗口间跳换来手动管理不同工具。我没坚持任何特定设置。

最近，我找到了一个相当理想的位置： 我用sidekick.nvim做接口层。它让我在不同AI代理间切换。但实践中？我主要默认Claude Code。它的规则和配置现在很强，而且我公司付了钱，为啥不用？

这就是终端workflow的真正优势：你需要的时候，灵活性就在那儿。 想测新模型？切进来。想要对代码的第二意见？任务中途切代理。但你不会被强迫不断上下文切换。你可以适应有效的方法，只在有意义时切换。

我一直在用的一个workflow技巧： 用一个AI工具实现功能，然后用另一个不同的工具审查或测试。你会得到不那么偏见的第二意见。如果模型A写了代码，模型B标了你也担心的问题，你就知道它是真的。如果模型B说“看着不错”，你就更有信心了。这像结对编程，但第二个程序员是完全不同的智能。

“最好”的AI模型一直在变。Claude Code今天占主导，但这每小时都在变。被锁在一个工具意味着你总在追。在终端里，切换是微不足道的。

为什么终端才是真香

Neovim在StackOverflow 2024开发者调查里得分83%，成为最受钦佩的IDE，尽管VS Code最常用，占59%。这个差距告诉你点什么。用Vim的人不只是容忍它。他们热爱它。而且这不是斯德哥尔摩综合征。

以下是让我留在这儿的原因。

双手不离键盘，心流就不中断

当我手从不离开键盘，我保持心流。每次伸手摸鼠标，都有个微决策：光标在哪儿？我在点啥？我点偏了吗？那些中断会复合。不光是几秒的事，是心理开销。

想找个文件？sf调出Telescope。搜索所有东西？sg进行实时grep。在Vim分割、tmux窗格甚至tmux窗口间导航？Ctrl+h/j/k/l无缝处理所有这些。用worktree和AI准备好开始新任务？at。切换浮动终端？;。

没有鼠标。没有侧边栏。没有菜单搜索。只有肌肉记忆。

我用的AI工具（Claude Code、Codex、OpenCode）适合这个。我不上下文切换到浏览器或单独应用。我用键绑定在分割窗格里调用它们。一切都在一个地方。

速度不是打字快。是从不停止。

终端是工具箱，不是单一工具

终端不是一个工具。它是可组合的。想处理API的JSON？pipe到jq。转换文件路径？sed或awk。在50个文件上跑命令？find | xargs。编码时监控日志？tail -f分割tmux。

当你把AI加到这种可组合性，事情就疯了。

我可以在一个窗格里提示Claude Code，看着它在另一个窗格写代码，把测试runner的输出pipe过来，grep结果，把错误喂回给AI。所有这些不离开终端。所有可脚本化。所有可重现。

Cursor做不到这个。你不能把Cursor的输出pipe给grep。你不能脚本它在循环里跑。它是个黑盒。终端是乐高积木，AI只是另一块。

性能：你真的能感觉到

VS Code和Cursor是Electron应用。它们底层跑一个完整Chromium浏览器。Neovim是C写的。它立即打开，用大概50MB RAM，从不滞后。

当我启动10个带Neovim和AI工具的tmux标签，我的系统几乎不眨眼。试着开10个VS Code窗口，听听你风扇尖叫。

我随时处理5到10个worktree。每个都是独立环境。如果每个占500MB RAM还要3秒加载，我workflow就崩了。Neovim和tmux？即时、轻量、快。

我的设置就是代码

我整个开发环境是git repo里600行dotfile。新机器？clone它，跑个脚本，我两分钟内恢复运行。相同的键绑定、相同的插件、相同的别名、相同的AI集成。

GUI工具让你同步设置，但你对它们配置系统听天由命。对于终端工具，设置就是代码。你能版本控制它、diff它、审查它、共享它。我能在全新VM上比VS Code安装更快地重造我整个workflow。

这些工具有持久力

Vim 1991年出的。Neovim 2014年。tmux 2007年。它们比编程语言、框架、公司活得长。它们会比Cursor活得长。它们会比Zed活得长。它们甚至可能比JavaScript活得长。

我建立的肌肉记忆、键绑定、workflow模式：它们10年内仍然相关。Cursor会吗？也许。可能不会。学Vim是复合投资。GUI工具是赌公司保持偿付能力。

控制的梯度

这是我怎么想这个谱系的：

完全控制（传统Vim）

你写每个字符。你思考每个问题。慢，但你知道确切发生了什么。

AI辅助（我当前设置）

你指导解决方案。AI加速执行。你保持接近代码。你构建时审查，不是之后。你手动执行琐碎操作，而不是把所有事都问代理。

AI优先（Cursor、Zed）

AI建议，你接受/拒绝。快，但你更多是反应而不是创造。

AI中心（Zencoder、vibe-kanban）

AI构建，你审查diff。最快，但你是你没写的代码的产品经理。

现在，AI辅助是理想点。我获得速度不失去控制。我保持我心流。我信任输出，因为写的时候我在那儿。

但我会诚实：这可能不会持续。

AI在写代码和审代码方面都变得惊人地好。它正在捕捉我漏的bug。它在标我忽略的模式。如果AI审查变得和人工审查一样可靠，保持亲力亲为的论点就弱了。

我们可能过渡到AI中心，不管我们喜不喜欢。问题是：在“保持接近代码”变成怀旧而不是务实之前，我还有多久？

目前，我留在终端。但我在观察。

诚实的不确定性

这个workflow让我感到掌控。我知道我代码在哪儿，它怎么到那儿的，每一步发生了什么。我不是看着AI在后台造东西并希望它做对了。我在指导它，它进行时审查，保持接近工作。

这种控制很重要。目前。

但如果我说我对这是未来有信心，那我就在撒谎。AI以荒谬速度变好。它已经捕捉我漏的bug。它在写花我几个小时的代码，只需几分钟。它在审我工作并发现我忽略的模式。

在某个点，保持亲力亲为的论点不再务实，而是变成怀旧。可能我们已经到了，我只是不想承认。

我一直在测试AI优先的工具。Zencoder、vibe-kanban、Cursor。不是因为我认为它们更差，而是因为我想知道终端workflow何时不再是个明智选择，而是变成固执。

可能这发生在下周。可能它已经发生了，我只是看慢。AI中心的开发可能不是遥远未来。它可能是现在，而我坚持一个让我舒服的workflow。

今天，我留在终端。对我来说它更快。它适合我思维方式。它让我以感觉对的方式接近代码。

但明天？谁知道。

终端中心的workflow现在对我来说是赢家。但我在观察差距缩小。当它缩小时，我可能切换。不是因为我想，而是因为那将是显而易见的动作。

在那之前，我继续按at，让AI做重活，而我保持驾驶。

---

我是个还在用终端的程序员，AI是工具，不是主人。

你呢？你的AI编程workflow长啥样？欢迎在云栈社区的开发者广场一起交流讨论。

---