我 2026 年每天碰的工具，比两年前少了将近一半。
1. 怎么走到这一步
本科那几年我其实算不上"会写代码"。MATLAB 写得磕磕绊绊。学得相对好的是数学、物理、电磁场那一类——在纸上推公式、靠定性直觉去理解一个系统的那种工作。那些公式后来差不多都还给老师了，剩下来的是"先想清楚再算"的习惯。
真正把代码当一回事，是 2017 年本科毕业那个夏天到美国读 PhD 之后才开始的——在 USC 那几年，我才第一次写真正有规模的代码工程。Python 是我第一个真正必须学会调试的语言。用 Python 的那几年，"编程"这个词对我从"表达方程"慢慢转向了"哄系统跑起来"。前者是一次性的智力工作，后者更像是与一套不完全透明的机制反复打交道——这两种活动表面上都叫写代码，但所需的心力很不一样。
从那以后，整个工具栈的方向只有一个：要敲的键越来越少。2017 到 2023 那几年，我都是自己写代码——学框架、调试各种依赖问题、把环境一遍遍配到能跑起来，是真正"自己写"的时期。2024 年是 AI 第一次实质性进入我工作流的时刻：把代码片段复制粘贴去问 ChatGPT，再加上 GitHub Copilot 的行内提示。AI 是有了，但每一段都得我主动去问、主动去取，工作流的主语仍然是我。2025 年 Cursor 把 AI 整合进了编辑器，建议在我打字时自己浮起来——这一步省掉了切换上下文的成本，但敲键这件事还是我的。到 2026 年切到 Claude Code，逻辑彻底反过来：我描述任务，由它去跑，我做的事变成了审阅而不是组装。这条轨迹没有哪一年是我主动设计的，它只是工具能力在每一年都比上一年高一截，于是我能交出去的事情就多一截。
也是在这条弧线的某一段，ML 框架的细节从我的日常关注里淡出了。以前 PyTorch 的版本、CUDA toolkit 的对应关系、各种环境冲突的解法不至于全背在脑子里，但你必须把它们之间的依赖关系配得严丝合缝，代码才能真正跑起来——这种对齐工作本身就是日常的一部分。现在我基本不想这些事，一部分是因为 agent 帮我挡掉了，但更主要是我的工作位置往上移了：从"调好这个模型"变成"设计 agent 在系统层做什么"。框架细节不是被我刻意忘掉的，是被工作场景挪走了。配环境那种工作，我一点都不怀念。
2. 我每天真正会碰的工具
把"日常用什么"这件事拆开看，会发现自己每天真的会打开的工具其实非常有限。下面这份是当前的完整清单——能合并到一个工具里的就合并了，不需要单独存在的就没有。
- 编辑器：VS Code，用了好几年。
- 终端：VS Code 自带的，最简单的那种。
- 语言：Python，工作上几乎全部。
- 前端：个人项目（包括这个站）用 Next.js，但是 vibe coding 在写——大部分代码是 Claude 敲的。
- 写作：超过几句话的内容都用 Markdown，这篇也是。
- AI 助手：Claude Code。
- 云：Cloudflare 做访客统计；托管平台另算。
- 笔记 / 计划：Apple Notes 抓灵感，Claude Code 整理每日计划。
这份清单短得让我自己也有点意外。我原本的预设是工具会随着工作复杂度上升而扩展——但实际发生的事情正好相反。每多接入一层 AI 能力，原本需要由我自己拼装起来的几个独立工具就被替代或合并掉。如今的工作日里，桌面上不再有那种"为了某一件小事专门打开"的工具，更多的事都被几个核心入口吸收掉了。
3. 被迫迁到 Claude Code，然后就回不去了
从 Cursor 切到 Claude Code 不是我自己选的。2026 年初公司让全员迁过去，我心里其实是有抗拒的——切换工具习惯总要付学习成本，而 Cursor 已经被我用得很顺手。但实际上一周左右就稳定了下来，并且让我意识到，这是比以往任何一次工具迁移都更深刻的一步，因为它不是表层的 UI 变化，而是协作方向的反转。
两者的区别看上去微妙但其实彻底。Cursor 仍然以"我"为主语：我打字、AI 在旁边给下一行的建议、最终接受或拒绝的还是我，工作的节奏由我的击键决定。Claude Code 反过来：我先描述任务和约束，工具去执行，等它完成之后我做的事是审阅而不是组装，工作的节奏由它的运行决定。前一种是带脑子的自动补全，后一种是真正意义上的"委托"。代码究竟是谁写的，这两种模式给出的答案完全不同。
委托一旦发生过几次，就很难再退回到"自动补全"那种循环。我现在已经不愿意切回 IDE 内嵌的 AI——那种"打一个字、等一行建议、再决定要不要接受"的节奏，相比直接把任务整段交出去，慢得让人难以忍受。我以前以为 IDE 里嵌入的 AI 就是工具进化的终点；现在我会把它放在一个被超越掉的中间站位置上。
4. 一个被节奏甩掉的习惯
工具栈变薄不是全然的收益。我最怀念的并不是被我从工作流里抹掉的某一件具体工具——是一个曾经的工作习惯。
我以前坚持手写每日工作日志。从今天的效率视角去看，这件事是低效的：写得慢、查找麻烦、没法重排，内容一旦写下就固定在那一页上。但慢本身就是它的意义所在。手写的节奏强迫我把当下的一件事完整想完——它不允许中途切换，也不鼓励同时打开多条线索。一段连续、不被打断、长度可观的思考时间，在那时候对年轻的我来说几乎是默认的工作状态。
现在的工作日完全不是这样了。我同时打开多个会话、多份文档、多个 agent 任务，必须随时切换上下文，才能让所有线索都不掉到地上。Apple Notes 加 Claude Code 是为这个新状态量身的——录入快、可搜索、可以无限重排，跟得上节奏。但它们服务的是 multitasking 这种新的常态，而不是那种"一段大块时间专注于一件事"的旧节奏。慢工具留不在 multitasking 的工作流里，因为它们跟不上节奏，这件事没有什么解决办法。
如果让我把一个习惯重新塞回这个变薄的栈里，那一定是手写本子。
5. 再往后
我现在在 MiroMind 做 agent 系统，所以"agent 会做更多事"这件事对我没什么悬念——它一定会发生。这个行业里工程师的角色从"写代码的人"变成"使用 agent 的人"，再变成"设计 agent 怎么协作的人"，路径已经相当清晰。我真正在盯的，是另一个安静很多但更关键的问题：当 agent 越跑越快、越跑越精，我能不能继续判断它哪里错了。
审阅 agent 的输出乍看是个比写代码省力的角色——它做苦力，我把关质量。但这里其实藏着一个不太显眼的门槛：要挑出 agent 的错，你必须在那个具体问题上至少比它多懂一点点。而这个差距正在以越来越快的速度被压缩。从"我审 agent 写的代码"，到"我审 agent 写的 evals 系统"，再往后大概是"我审跑 agent 的 evals 系统的另一个 agent"——每往后退一步，自己手里那一份"判断力"在整个流程中的相对稀缺度就更高一点，但能正面应用它的接触面也越来越少。
也是因为这一点，我开始重新看那个被我放下的手写本子。手写所要求的那种慢节奏、单线程、不被打断的思考——以前我把它当成一种被时代淘汰掉的工作方式，现在我开始把它当成对判断力本身的训练。再过几年，身体上的"慢"可能不再是一种默认状态，而是一种需要主动去选择并保护的、相对稀缺的能力。