最近我常常在想，在这场 AI 喧闹中，我们得到了什么，又将失去什么。

年初那会儿，一直想写一篇博客介绍我的工作流，例如 tmux + fish shell + nvim + git worktree —— 题目甚至都想好了，叫作 打造我的 AI 工作流 云云。恰逢赶项目进度，一时没有闲暇，拖至现在。现在已经没有写的必要了。

AI 发展迅速，Vibe Coding 的接入点越来越成熟。年初那会许多程序员都在叫嚣“CLI 正在杀死一切”，有人出来解释 Claude Code 以 CLI 的形式出现是多么正确，甚至同事告诉我运营也在用 Claude Code CLI 了 —— 我也不想苟同。这无非是程序员的自我狂欢，再加上领域外的人（非 IT 的技术人员）无奈被迫接受的结果而已。AI 要迈向更广阔的市场，终究绕不开 GUI。流畅的交互和好看的界面，缺一不可。事实胜于雄辩，Claude、Codex、OpenCode，都在做 GUI，而且越来越好；DeepSeek GUI 听说不是官方出品，但我试用下来也觉得很不错。Cmux 之类的产品正在“杀死” tmux。
我知道 GUI 一定会来，没承想会那么快。所以“打造我的 AI 工作流”不用写了。即使我一直痴迷于在 terminal 中搅动风云，还是不得不承认，这套“满清的遗老遗少”也该进入博物馆了……

过去两个月几乎没有写过一行代码。年初领导找我谈话，说他过去一年没有写过代码，全程 vibe，我还记得当时有多吃惊。后来公司支持使用 Claude Opus 模型后，转眼自己也如此。起初我越来越觉得这样的工作没意思，过去写代码的快乐荡然无存。与此同时，我对代码库越发不了解。尽管在努力阅读 AI 写的代码，但是越来越吃力。当一个组的同事都在 Vibe 时，代码归属在哪个文件、依赖哪些调用链、配置、状态和 Go 中的 context.Context，变化越来越快。在几次排查问题时，我发现记忆里的关键字检索不到对应代码了。我意识到，一旦把代码库的主权交给 AI，就再也要不回来了。这是无法改变的事实。那么项目的后续维护怎么办？期待以后更强大的 AI 出现。Opus 4.6 留下的坑让 4.7 去填；4.7 的坑让 4.8 去填。

交付出去的系统，其稳定性也没有以前的足量把握。外行爱看热闹，在看了许多“程序员即将失业”的宣传后，不写代码的人认为写代码从此不过尔尔，于是开发工期一再被压缩。我再也读不完 AI 写的代码。好几次事后才发现 AI 的实现离谱 —— 本该查询 DB 获取内容，却在代码里直接返回了写死的字面量。在网上看到网友也有类似遭遇：应该获取当前时间，结果代码里写死了某个日期；系统运行到 6 月，程序就会因此故障。即使我们有更快的交付速度，但我们对外交付的，是一个越来越不稳定的系统。

一面是系统越来越不稳定，一面是工作越来越累。“压缩工期”常常不是说把两周的工作量压进一周做交付，而是把四周的工作量压进两周。从数学角度，看起来好像比例没有改变，可在现实中，有多少事是线性关系呢？更多的需求量，带来了更多的上下文切换，尽管许多需求早早让 AI Vibe 好了，但是许多验证还是得亲力亲为，或者依赖其他组的对接。总有无法避免的“耽搁”，由于 AI 很擅长全仓库修改代码，pending 期的代码容易遇到冲突，解决冲突后又要重新验证。代码从开发到发布，中间的损耗变大了不少。

兴趣是在转变的。前面提到我对写代码不再有兴趣，但慢慢兴趣转移到了构建上。最初还只是让 AI 给我构建命令行工具，让我执行命令更快。后面让 AI 给我写 app：写了一个管理订阅的移动端 app，确实因此发现过去浪费了不少钱；写了一个 scratchpad 桌面 app，以前总是用 Sublime，但一直觉得差点意思，没有那么顺手。还有很多 idea，后续想一一落地。这大概是我真正得到的东西：把一个念头变成工具的距离，被压缩到了前所未有的程度。现在最美好的，莫过于 Vibe 自己的专属应用。很有些以前玩 nvim、emacs 的感觉。只不过这种做法，是在浪费整个地球级的资源。毕竟在一定程度上，许多人做的是“垃圾应用”，纯粹是在浪费 token。

当下 AI 还没有聪明到替代我们，可是我已经有些力竭与迷茫。当然也在努力寻找与 AI 共处的答案。Vibe 以后，我们确实得到了一种前所未有的构建能力，也失去了一部分曾经熟悉的确定感。希望以后的自己，可以更从容地站在这两者之间。