从年初至今, 我的开发工作流经历了一场静默的革命.
起初不过是在浏览器里与各类 ChatBot 闲聊, 直到智谱推出 GLM Coding Plan, 我购买了 Lite 套餐, 并在 VSCode 里装上了 Cline. 从那以后, 一切都变了: 我开始了一场场的探索, 从编辑器到终端, 从 MCP 到自定义 Skill, 我一步步搭建起一套属于自己的开源工作流.
这篇文章, 我想聊聊这套工作流的演变过程 -- AI 究竟在何种程度上改变了我的工作方式, 还有它没能改变什么.
一, 工具链: 开源先行
目前我的工作流的核心工具大致分为三层:
- CLI 层:
Crush或OpenCode - 编辑器层:
Zed与Emacs - 系统层:
Guix
贯穿其中的核心原则是: 开源先行.
1. 编辑器
最初的一切始于 VSCode.
在年初时, 我将主力操作系统系统迁移到了 Guix, 整个生态还在从 NixOS 过渡的过程中, 环境尚未完全稳定.
Cline 作为 VSCode 的 AI 插件, 配合 GLM 的 Coding Plan, 让我第一次体验到了 "vibe coding" 的快感--描述需求, 看着 AI 自动生成代码, 执行命令, 修复错误, 开发流程变得异常流畅, 高效.
随后, 我将主力编辑器切换到了 Zed.
这个决定很大程度上源于个人的所谓 技术审美:
- Zed 基于 Rust, 使用了自研的 UI 框架
- 而 VSCode 确使用了 Electron 框架
我一直认为, Electron 对于 "文本编辑器" 这个场景来说太 "重" 了--它本质上是一个精简版的 Chromium, 带着整个浏览器内核来渲染几个窗口, 未免有些杀鸡用牛刀.
相比之下, Zed 用一门"系统级语言"从头构建, 这种工程态度更符合我的口味. 这也就是我之前提到的一个观点, 即:"编程语言是有使用场景的", 框架也有.
然而现实给了我当头一棒: Zed 在内存占用上压根没比 VSCode 轻多少
或许是我日常打开的代码库规模还不够大, 没能触碰到它的极限优化场景; 又或许, 现代 IDE 的功能复杂度决定了它们终究难逃资源消耗的宿命.
更让我失望的是 Zed 的 AI 集成--尽管它标榜 "AI-Native" (这个不是我编的, 它还真是一直都在与 JetBrains 进行各种合作, 来推动 Coding 相关 Agent 的基础设施建设), 内置的 Agent 功能却相当笨拙, 至少对于我来说, 视觉上的效果也确实是不如之前在用的 Cline.
但它也确实是做出来了不少好东西, 比如说最近推动的 ACP (Agent Client Protocol) 协议规范, 它确实是让其他编辑器能够更加容易地引入 AI Agent (比如说兼容 ACP 协议的 Emacs, NeoVim 插件, 这个太好用了, 直接配置好插件就能够让 Emacs 也接入到我目前的所有 AI 工作流), 还能够在一个界面中管理电脑中安装的所有支持相关协议的 CLI, 对于会话非常多的情况来说是很不错的.
作为编辑器本身, Zed 也足够纯粹, 足够快, 这依然值得肯定, 目前 Zed 的开发也非常积极 (至少相较于 Helix 来说, 它绝对是模范).
将 Zed 作为主力编辑器的过程中, 我逐渐发现了它在 Guix 上的水土不服.
Zed 喜欢直接调用 npm 安装组件 (比如 prettier), 也喜欢下载预编译的二进制文件. 这两点在 Guix 上都是雷区: 前者因为 Guix 的隔离环境而常常失败, 后者则与 Guix 的可复现哲学相冲突--未经 Guix 包管理的二进制文件, 就像往精密机械里撒沙子.
于是我开始转向 Emacs.
这个决定起初只是出于系统兼容性的妥协, 但很快变成了主动拥抱.
最初, 还是因为之前提到的 Zed 的相关问题, 这些在 Guix 上确实是很头痛的, 但是 Guix 的 Emacs 生态建设的非常优秀, 所以我就在考虑要不要迁移.
正好, 我想要测试一下 AI 的能力, 所以就先依靠 AI 做出来了一套 VSCode 布局的 Emacs 配置, 一看效果还不错, 确实看起来挺好的, 所以就开始认真准备迁移工作了.
我全程利用 AI Agent 来配置 Emacs: 本人只提供需求与参考方案, 最常使用的提示词是-- "请参考 VSCode 和 JetBrains 全家桶的操作逻辑". 目标是打磨出一套对鼠标友好, 符合现代 IDE 直觉的 Emacs 配置.
在这个过程中, 我逐渐意识到 Emacs 的真正威力: 它的功能完备程度远超想象, 且在 Guix 上能够获得原生级的, 无缝的体验. 唯一的不适应是操作逻辑--从模态编辑到快捷键体系, 都需要时间磨合.
但有了 AI 辅助, 这个学习曲线被大幅削平了. 我只需要像 AI 不断地提问, 以及提出意见和建议, 他就能够进行对我回答, 对代码库进行修改, 以符合我的直觉, 所以我只需要享受 Emacs 的好处就行了, 剩下的让 AI Agent 来处理就好.
2. CLI 工具
从 GUI 转向终端, 是我工作流的另一次质变.
我一直对闭源设施保持警惕, 因此始终回避 Claude Code (所以我也没用过 JetBrains 的编辑器, IDEA 除外, 但这个我也没有用的很深入). 在寻找开源替代方案时, 我发现了 Qwen CLI, 它在我印象里是基于 Gemini CLI 制作出来的, Gemini CLI 在刚出来的时候确实是造成了不小的轰动, 所以我很相信它的实力.
搭配阿里的 Coding Plan 使用, 开启 YOLO 模式后, AI 就可以在终端里自主执行命令, 读写文件, 迭代代码, 那种"放手让 AI 去干"的体验确实酣畅淋漓.
随后我尝试了 OpenCode 配合 Oh My OpenAgent, 多 Agent 协作的架构相当超前, 也正是从这时起, 我开始格外关注 CLI 工具的 SubAgent 能力--能否让 AI 自主拆分任务, 调用子代理, 成了我评估工具的核心指标.
同时, 当阿里的 Coding Plan 停售并清退 Lite 计划的所有用户时, 我也意识到了: 千万不要把任何东西都押在一家. 避免单点故障的最佳方法, 永远是找到更加开放的平台, 这样即使需要切换模型, 也不会需要大幅度修改目前的所有工作流.
为什么选择 Crush?
Crush 最吸引我的点在于它的实现语言--Go.
当市面上绝大多数 AI CLI 工具都用 TypeScript 堆出来, 更不用说其中的大半部分都堆的毫无意义时, 一个用 Go 编写的客户端显得格外清爽.
它的二进制体积小, 启动快, 资源占用低 (由于 Go 的特性, 它可以做到单文件运行, 简洁优雅), 更难得的是, 它并没有因为轻量而在功能上缩水: SubAgent, MCP Server, Skill 系统一应俱全, 加上一个足够炫酷的 TUI 界面, 恰好击中了我的需求.
但它还是有一定发展前景的, 目前缺少的功能还是很多 (比如说 Agent 体系, 即 Claude code 中可以看到的所谓 Plan 和 Build), 假如这些问题能够解决的话, 那么就可以更上一层楼了.
为什么减少使用 OpenCode?
OpenCode 走的是另一个极端:功能庞大而全面,尤其是配合 Oh My OpenAgent 后,多 Agent 协作的效果令人印象深刻.
但它就是我说的, 使用 TypeScript 堆出来的 CLI 之一, 我认为语言之间还是会有一些 "适用场景" 的, 至少你 JS / TS 就应该在网页场景上好好待着, 在终端内这种环境下, 应该选用一些更加适合接触系统底层等相关环境的语言, 可以是 C / Rust / Go / Python 等等等等, 但我觉得不应该是 TS.
也正因为它依赖多家大模型 API 协同工作, 使用成本也随之水涨船高, 尤其是现在各家 AI 公司都在开始涨价, 连 Copilot Student 都开始砍可用模型了, 成本就更加昂贵了. 最近我在刻意削减各类订阅开支, 以让自己的每月花销达到一个可控水准, 所以 OpenCode 的使用频率便自然下降了.
二, 体验与反思
首先, 我想说: AI 不是魔法,而是杠杆
几个月的深度使用下来, 我有几点格外深刻的体会.
1. AI 的上限, 始终由使用者决定
首先要破除一个迷思: AI 不会读心术. 它只能通过你的描述来理解意图, 执行任务.
因此, AI 产出的质量天花板, 实际上取决于使用者的语言功底与思维清晰度. 观察周围人对 AI 的使用时, 我发现了一个普遍现象: 许多人并不知道如何与现阶段的 AI 协作.
在以前 DeepSeek 大火的时候, 我曾亲眼看到了别人的提示词-- "给我来一份物理试卷". 我震惊了, 但转念一想, 这也正常, 大部分人对于 AI 的理解或者说是期望, 就是来自于科幻作品里那个 "无所不能" 的帮手或者帮凶, 实际上它也不应该叫作 AI, 而更应该叫作 AGI / ASI.
我们离 AGI 还很遥远, 更不用说 ASI 了. 今天的 AI 需要 Harness Engine, Agent 框架来确保其能够正常运作, 需要各种 Tools 来扩展能力边界. 但这里存在一个悖论--如果你根本不知道某种工具或方法的存在, 你又如何要求 AI 使用它呢?
所谓 "AI 自进化" 的叙事, 在我看来多少有些误导, 至少目前还没做到. 即便是像 Hermes Agent 这类标榜"自进化"的框架, 其本质也不过是一套自动化的上下文管理系统: 自动总结历史经验, 转化为领域特定的Skill, 供后续任务调用. 当模型真正需要提升能力时, 仍然需要人类去训练更强大的基座模型.
这些框架让 AI 更"听话", 更能遵循历史经验, 从而减少重复思考, 提升任务效率--它们确实能填补不同模型之间的能力鸿沟, 让较弱的模型通过更好的上下文管理逼近强模型的表现, 但模型本身的能力并不会因此发生质变.
理解这一点至关重要: AI 是杠杆,而非替代品是. 杠杆可以放大你的能力, 也可以放大你的无知.
2. AI 让经典工具焕发新生
如果说 AI 给我最大的惊喜是什么, 那一定是它让我发现了 Emacs 的价值.
在 AI 介入之前, Emacs 给我的印象无非是笨重, 晦涩, 学习曲线陡峭--一个属于上世纪的编辑器化石. 但当 AI 抹平了"理解并使用"的门槛后, Emacs 的优势便一览无余:
- 近乎无限的扩展性: 无论你想得到还是想不到的功能, 几乎都有成熟的插件生态. 即便没有现成方案, 借助 AI 辅助编写 Elisp, 自定义功能也变得触手可及.
- 基础功能的极致打磨: 内置功能的完善程度令人咋舌, 尤其是
Org Mode. 作为笔记与知识管理系统, Org Mode 的灵活性和深度是 Obsidian 等现代工具难以企及的--那种纯文本与结构化数据的完美融合, 那种 Emacs 生态独有的可编程性, 一旦习惯便很难回头.
这个发现让我产生了一个更大的观点: AI 时代,我们更应该深度挖掘既有工具的潜力,而非盲目追逐新玩具.
当 AI 能够帮你驾驭复杂工具时, 那些经过几十年社区打磨的"老古董", 反而可能比层出不穷的新产品更可靠, 更强大.
同样地, 我认为 NixOS 和 Guix 这类强调可复现性 (Reproducibility) 的发行版, 在 AI 时代有着独特的优势:
- 可审计性: 当 AI Agent 需要修改系统配置时, 所有变更都集中在一处 (配置文件仓库), 而非散落在
/etc,.config, systemd 服务等各个角落. 你完全可以审查 AI 到底改了什么. - 原子化回滚: 配置出错? 一条命令回滚到上一个世代, 这种安全感在让 AI 自动操作系统时尤为重要.
- 上下文集中: AI 不需要在庞大的文件系统中漫无目的地搜索, 只需关注声明式配置, 大大降低了上下文消耗的 tokens 数量.
这类发行版过去最大的障碍是 学习成本, 而 AI 恰好能将其降至可接受的范围.
我想象中的 "AI-Native 系统" 并非在现有系统上贴一个 ChatBot (看看 Windows 11 的 Copilot 就知道了, 除了占用任务栏空间, 对系统故障排查, 配置优化几乎毫无帮助), 而是让 AI 真正参与到系统决策中, 同时让用户保留审查与回滚的权力--人机协作, 而非人机替代.
三, 警惕: 不要把灵魂卖给闭源 AI
最后, 我想泼一点冷水.
AI 的高效无可否认, 但绝不能把所有工作重心都押在 AI 身上, 更不能把完整工作流交给 某个闭源的 Agent 框架.
Anthropic 的 Claude Code 确实强大, 但试想一下: 一旦遭遇封号, 限流或政策变更, 所有深度依赖它的工作流都会在瞬间瘫痪. 到那时, 不是你在使用 AI, 而是 AI 在牵着你走.
我认为更健康的姿态是: 持续学习, 以 AI 为辅.
让 AI 处理重复劳动与 boilerplate, 但保持对底层原理的理解: 让 AI 帮你配置 Emacs, 但你自己要知道 init.el 里写了什么; 让 AI 生成代码, 但代码的架构与边界仍由你设计.
AI 是极好的副驾驶, 但方向盘应该始终握在人类手中.
结语
从 VSCode 到 Zed, 从 Cline 到 Crush, 再到如今的 Emacs, 我的工作流演变本质上是一场对"控制权"的追寻 -- 从闭源到开源, 从 GUI 到终端, 从被动接受到主动配置. AI 在这场演变中既是催化剂, 也是试金石: 它放大了好工具的价值, 也暴露了坏架构的脆弱.
这场革命才刚刚开始. 保持好奇,保持警惕,保持学习.