夜雨聆风我已经卸载 VS Code 有一年了
目前还保留了 Cursor，但打开它的时间已经不到 1%。
不是转行了。这 2 个月我写的代码比以前更多 —— 只不过不是我在写。
我现在的日常是：用 gstack 的 office-hours skill 想清楚要做什么，让 Claude Code 去做，然后验收结果。整个过程中，没有一秒钟需要打开代码编辑器。
你可能觉得这是某种极端主义行为艺术。不是。这是我试过之后，再也回不去的工作方式。
编辑器是一个过时的假设
所有代码编辑器 —— 无论是 VS Code、Vim、Emacs、JetBrains 全家桶还是曾经大火的 Cursor —— 它们的设计原点都是同一个假设：
人需要高效地编辑文本文件。
语法高亮是为了让人更快地读代码。自动补全是为了让人更快地写代码。多光标、Vim 键位、Snippet、重构快捷键 —— 全是在优化同一个动作：人手动修改字符。
过去四十年，编辑器的进化方向始终是：让这个动作更快、更准、更舒服。
但如果这个动作本身正在消失呢？
Cursor 看起来像是革命者。它把 AI 塞进了编辑器，你可以在代码旁边跟 AI 对话，让它帮你改代码。很酷。但仔细看，它的交互模式没有变：人盯着代码，AI 在旁边递工具。 司机还是你，AI 只是升级了导航系统。
问题不是导航系统不够好。问题是你不需要当司机了。
范式转移：从辅助驾驶到自动驾驶
过去 3 年，AI 编程的主流叙事是「AI 辅助开发」—— 人写代码，AI 加速。Copilot 补全半行，Cursor 改一段函数，ChatGPT 帮你解释一段看不懂的逻辑。本质上，你还是那个操纵代码的人，AI 是你的加速器。
这是旧范式。它的天花板就是人的天花板。
新范式完全不同：AI 写代码，人做决策。
你不再告诉 AI「把第 42 行的 forEach 改成 map」，而是告诉它「用户在弱网环境下播放歌曲会卡顿，定位根因并修复」。它自己去读代码，自己找到问题在哪，自己改 5 个文件里的 12 处代码，自己跑测试验证，然后把结果给你看。
你做什么？你审方案。你判断修复方向对不对。你验收结果。
这三件事，没有一件需要你打开一个代码编辑器。
我的工作流：Obsidian + gstack + Claude Code
说说我现在实际怎么干活。一个功能从想法到上线，经过三个阶段：想清楚、审清楚、做出来。对应三个工具，没有一个是代码编辑器。
Obsidian：大脑
Obsidian 是一个 Markdown 笔记工具。它不认识代码，没有语法高亮，没有终端，没有 Git 面板。这恰恰是它的优势。
打开 Obsidian，你的注意力自然在「想清楚」上。打开编辑器，你的注意力自动被拉到「改代码」上。 工具塑造思维。
我在 Obsidian 里做三件事：
一、定原则。 项目的目标、核心架构、设计原则 —— 这些东西应该是稳定的，不会随着每次迭代而剧烈变化。我提前写好，放在 Obsidian 里。AI 后续做任何方案设计时，这些原则就是它的护栏。不是每次都跟 AI 从头解释「我们这个项目追求什么」，而是让它自己去读。方向对了，细节才有意义。
二、管理 Spec。 每一次迭代的需求、方案、决策过程，全部以 Spec 形式沉淀在 Obsidian 里。这等于给 AI 加装了项目记忆。三个月前做过什么、为什么当时选了方案 A 而不是方案 B、上次踩了什么坑 —— AI 不需要你口头复述，它自己去翻。项目越复杂、迭代越多，这个记忆的价值越大。没有它，每次开新会话就像和一个失忆的人合作。
三、管理知识。 调研过的技术方案、收藏的优秀文章、竞品分析、架构参考。这些东西放在编辑器旁边的注释里会被淹没，放在 Obsidian 里是可以检索、链接、长期积累的知识资产。需要的时候丢给 AI 做参考，比你口头描述「我之前看过一篇文章说……」靠谱一万倍。
gstack：参谋部
Obsidian 里写出来的是原始想法，但想法和可执行的方案之间有巨大的鸿沟。过去这段路靠人脑硬扛 —— 自己做产品分析、自己想架构、自己评估风险。现在我用 gstack 来填这个鸿沟。
gstack 是 YC CEO Garry Tan 开源的一套 Claude Code skill 集合，本质上是把一个完整工程团队的决策流程变成了可复用的命令。我重度使用其中三个：
/office-hours —— 产品推演。 我把一个模糊的想法丢给它，它不会直接开始写方案。它会像一个严厉的产品合伙人一样反问你：用户到底在什么场景下遇到了什么问题？现在他们怎么解决的？你的方案比现状好在哪里？最窄的切入点是什么？这一轮对话下来，很多「我觉得应该做」的功能会被打回去，剩下的需求会变得极其锐利。
/plan-ceo-review —— 方向审查。 Spec 初稿写好之后，这个 skill 会站在 CEO 视角重新审视：这个方案够不够大胆？有没有想过十倍好的版本？前提假设对不对？哪些地方在做渐进式改良，而本该做范式突破？它不是让你盲目扩大范围，而是确保你不会因为思维惯性而把方案做小了。
/plan-eng-review —— 工程审查。 方向确认后，这个 skill 会像一个资深架构师一样过一遍实施方案：数据怎么流的？边界条件覆盖了吗？性能瓶颈在哪？测试策略是什么？哪些地方会在半年后变成技术债？它会把方案里的模糊地带全部暴露出来，逼你在写第一行代码之前就把工程细节想透。
三轮审查完，出来的不再是「想法」，而是一份经过产品、战略、工程三重验证的实施方案。 这个过程全程在终端里完成，不需要拉三个会议、找三波人 review。一个人，三条命令，半小时。
Claude Code：双手
经过 gstack 审查的方案交给 Claude Code，它跑在终端里。没有 GUI，没有文件树，没有 tab 栏。这不是简陋，是它根本不需要这些。
执行流程是这样的：
我把经过三轮审查的技术方案交给 Claude Code 它先出一个实施 Plan —— 要改哪些文件、每个文件的改动方向、风险点 - 我审 Plan。
这是我最核心的工作。方向对不对？有没有遗漏？会不会引入副作用？ Plan 通过后，它开始写代码。一次可以改 20 个文件，比我手动写快 100 倍 改完自动跑构建、跑验证 我 review diff，确认结果，提交
注意这里有一个关键变化：因为 Spec 已经经过 gstack 三轮打磨，Claude Code 拿到的不是模糊指令，而是精确方案。 它的 Plan 质量和代码质量会显著提升，需要我干预的地方大幅减少。这就是前期在「想清楚」上投入的回报。
整个过程中我没有打开过编辑器。 我不需要看到文件树，不需要在 tab 之间切换，不需要手动跳转到某个函数定义。我需要做的判断 —— 方案对不对、改动合不合理、有没有遗漏 —— 在终端里看 Plan 和 diff 比在编辑器里逐文件浏览更聚焦、更高效。
为什么 Cursor 不是答案
有人会说：Cursor 也能做到这些啊，Agent 模式也能让 AI 自己改代码。
表面上是的。但有一个本质区别：Cursor 是「更好的编辑器」，而我已经不需要编辑器了。
编辑器的 UI 设计有一种隐性引力。当你面对一个打开了代码文件的界面，你的本能是去看代码细节 —— 这个变量命名对不对？这个缩进是不是歪了？这段逻辑能不能优化？
这些事情不是不重要，但它们不应该占据你的主要注意力。它们是 AI 应该处理的事。
当你打开编辑器，你被锁在实现层。当你打开 Obsidian，你自然在决策层。
这不是意志力的问题，是环境设计的问题。你在酒吧里比在图书馆里更容易喝酒，不是因为你自制力差，是因为环境在引导你的行为。
编辑器引导你去「改代码」。但你最该做的事是「想清楚」。
反驳几个常见质疑
"不看代码怎么 review？"
首先，人不应该逐行看代码。Code review 本身就应该是另一个 Agent 做的事。比如让 OpenAI 的模型独立审查 Claude 写的代码 —— 用一个 AI 去审另一个 AI，比人肉 review 更快、覆盖面更广、还不会因为疲劳而漏掉细节。
你真正要看的是什么？是 Agent 审完之后给你的结论：哪些地方有风险、哪些改动需要你做判断。如果一定要看代码细节，终端里 git diff 就够了，只显示改动和上下文，信噪比比编辑器里打开整个文件高得多。
"复杂调试怎么办？"
Claude Code 可以自己读错误日志、分析调用栈、构造复现步骤、定位根因、提出修复方案。我的工作是确认它的分析是否正确、修复方向是否合理。这个过程中我需要的是清晰的思考，不是一个带断点功能的 IDE。
"这不就是 vibe coding？"
恰恰相反。
Vibe coding 是你含糊地描述一下想要什么，让 AI 随便写，然后祈祷它能跑起来。那是放弃控制。
我做的恰恰相反：写严格的 Spec、定义明确的规则、审查每一个 Plan、验收每一次 diff。控制力不是下降了，是转移了 —— 从「我控制每一行代码怎么写」变成「我控制整个系统往什么方向走」。
前者是微观控制，后者是宏观控制。后者更难，也更有价值。
而且，因为 Spec 是唯一的控制手段，你会被迫把需求想得极其清楚。反而比以前一边写代码一边想的模式更严谨。
觉得麻烦？说明你的 「AI 基建」 还没建好
如果你试了 Claude Code 之后的感受是「调试好麻烦」「测试验证好别扭」「还是得打开编辑器才踏实」——
这不说明编辑器是必要的，这说明 你为 AI 创造的工作环境还不够完善。
换句话说，你的马具(harness)没装好。
什么是 harness engineering？OpenAI 专门写了一篇文章讲这件事（感兴趣可以去看：Harness Engineering）。核心思想是：AI agent 的能力上限，不取决于模型本身，而取决于你给它搭建的脚手架 —— 规则、约束、工具链、验证流程。
举个例子。如果你让 Claude Code 改完代码，你自己手动去检查有没有问题 —— 那你当然觉得离不开编辑器，因为你还在用人肉方式做验证。
但正确的做法是：把验证流程也交给它。
构建命令写进项目配置，AI 改完代码自己跑构建。测试脚本准备好，AI 自己跑测试验证。代码规范写进 CLAUDE.md，AI 自己检查是否符合约束。错误日志的格式统一了，AI 自己能读懂并定位问题。
你的工作不是帮 AI 做这些事，而是建好环境让 AI 自己完成整个闭环。
这和传统开发的思路完全不同。传统开发里，你优化的是自己的效率 —— 装更多插件、背更多快捷键、配更顺手的 IDE。现在你应该优化的是 AI 的效率 —— 给它更清晰的规则、更完善的工具链、更自动化的验证流程。
想不开的人会觉得「怎么还要我去搭环境，我直接打开编辑器自己写不是更快？」
这就像早期用 CI/CD 的人也被质疑过：「写那些 pipeline 配置的时间，我都手动部署好几次了。」是的，第一次搭建的成本更高。但搭好之后，所有后续工作都在这个 harness 上以 AI 的速度运行，而不是以你的手速运行。
每一次你忍不住打开编辑器手动干预，都应该反过来问自己：这个环节为什么 AI 不能自己完成？我的 harness 缺了什么？ 然后把那块补上。
这才是正确的投资方向。不是回到编辑器，是把「为 AI 搭的基建」做得更完善，让自己离编辑器越来越远。
这不是预测，是已经发生的事
我不是在告诉你「未来某天编辑器会消失」。我是在告诉你：我现在就不用了，而且回不去了。
偶尔因为某些原因打开 VS Code，感觉像是从自动挡车里下来，被塞进了一辆手动挡 —— 我为什么要在这里手动找文件、手动跳转、手动改字符？
我再说一个更激进的判断：一年内，程序员 —— 特指那些核心工作是「写代码」的人 —— 这个岗位会减少 99%。
不是说软件行业会萎缩，不是说技术岗位会消失，而是「写代码」这个动作作为一个人的主要职责，将不再成立。
就像「打字员」曾经是一个正式职业。不是打字这件事消失了，是每个人都会打字之后，专门靠打字吃饭的岗位就没了。写代码也一样 —— 当 AI 写代码的速度、质量和可靠性都超过人的时候，「写代码」就不再是一种专业技能，而是一种基础设施。
留下来的是什么？是能定义问题的人，是能做架构决策的人，是能判断方案好坏的人，是能让 AI 高效运转的人。这些人今天叫程序员，明天可能叫别的名字，但他们的工作内容已经和「写代码」没有多大关系了。
编辑器的消失只是这个大趋势的一个缩影。当核心动作不再是写代码时，为写代码而生的工具自然会退场。
你的 Vim 配置越精致，你的 VS Code 插件装得越多，你的 Cursor 快捷键背得越熟 —— 你可能越难接受这件事。
但沉没成本不是继续的理由。
试试看：一周不打开代码编辑器，所有的编程工作都在终端 + 笔记工具里完成。然后问问自己，你真正离不开的，是编辑器，还是习惯。
观点总结
编程范式已经转移：AI 写代码，人做决策。编辑器是上一个范式的产物。 觉得离不开代码编辑器，不是编辑器必要，是你的 AI 基建还没建好。 一年内，以「写代码」为核心职责的岗位会减少 99%。留下来的是定义问题和驱动 AI 的人。
