放弃精耕细作式的编程吧
是时候放弃那种精耕细作式的写代码方式了。
我们更应该站在宏观的、高阶的、更广阔的视角来审视整个项目：最根本的目标是什么？为了达成目标，我们真正需要什么？而不是纠结于某一处技术细节该如何实现——这类问题，已经可以交给 AI 来协助解决。
若仍执着于事无巨细地掌控每一行代码，即使用上 AI，能带来的提升也相当有限。无非是从挥锄头换成了开拖拉机，效率或许能提升五倍、十倍，但本质上我们依然在「耕地」，而不是「想清楚要种什么、怎么收成」。我们只是换了一件更趁手的工具，却没有换一种角色：从执行者，变成能看见更大图景、设定更高目标的人。
接触 Vibe Coding 的过程
2022 年下半年，我在 GitHub 上了解到 Copilot。在 VS Code 里启用之后，光是「光标后自动补全代码」这一项能力，在当时就让我很受震撼。
在此之前，一旦遇到不熟悉的内容或需要查资料，就不得不把注意力从编辑器切到浏览器，整个写代码的过程不断在「打断 → 恢复 → 再打断 → 再恢复」里循环，非常消耗精力。这种模式贯穿了我 2022 年之前几乎所有的编程时光。但 Copilot 能做的有限：它只能在光标之后做顺序补全，无法在任意位置跳转补全，实际带来的效率提升并不算大。
到了 2024 年下半年，我开始用 Cursor，才意识到局面已经不一样了：
- 我们或许已经不再需要「面向搜索引擎编程」。
- 大部分写代码的步骤可以在编辑器里完成——写好函数签名或 TODO，按 Tab 就能续写。
- 遇到真正棘手的问题，打开 Chat，把你想做的事说清楚，Cursor 也能帮你完成一大部分。
那时我强烈地觉得：不能再沿用过去那套写代码和工作的方式了，得做点不一样的事。于是换了城市、换了工作，来到北京，开启了一段新旅程。
一度停止思考
在新公司，我很快投入到 Sandbox 相关的基建里：从镜像构建、Sandbox 调度，到和云厂商的对接与协同，很多环节都由我推进落地。
当模型训练、产品上线等事情都压在同一段时间里时，就有一种连轴转的感觉——每天早上醒来都在想今天又要 Rush 什么，这种状态持续了相当长一段时间。
表面上看产出很多、节奏很快，但后遗症也很明显：
- 很多事都不得不以「冲刺」的节奏完成。
- 往往一件事还没做到自己满意，就要立刻切换上下文去做另一件。
在这种节奏下，很难留出时间做充分的设计与规划，也很难在结束时做收尾、整理和归纳。这种连轴转，让我一度陷入「没空思考」的状态，现在回想起来仍有些后怕。再加上 Vibe Coding 类工具用得很猛，这种状态带来的混乱只会更剧烈。
AI 生成的内容往往需要审阅，尤其在 2025 年上半年使用 Cursor 的那段「混沌期」：当时用得上头，觉得可以把工作大量交给它，不必再逐行审视。
结果就是：它给你的东西看起来符合预期，其实是虚假的繁荣。当你越来越依赖它，会不自觉地膨胀，觉得什么都能做、什么都能实现，但最终都会付出代价：
- 可维护性变差；
- 功能与预期不符；
- 对项目整体代码的理解变浅。
这不是 Vibe Coding 或工具的问题，而是使用方式的问题——也就是我自己的问题。我仍然试图把所有事都装在自己脑子里，却又没有真正花时间思考，这本身就很矛盾。但那一阵子，我确实长期处于这种状态，这也是我后来想要改变的地方。
不要停止思考
从 2026 年开始，手头的事逐渐收束、更聚焦了一些，不再被各种杂事推着连轴转，终于有一点喘息的空间可以用来思考、总结，看看自己的工作方式是否需要调整。
也正是在这时，我明显感觉到：新一代的 coding agent 和之前的「AI 编辑器」已经不一样了。可以把它当成一位水平相当的 peer engineer，用来交流想法、请教实现。在得到清晰的需求描述之后，它们往往能做得很好，并且已经具备一定的 code review 能力——能指出潜在问题并给出改进建议，也能结合项目上下文给出更贴合的方案。
以前我们总嫌工具效率不够，现在工具已经上了一个台阶；真正卡住产出的，往往是我们自己：如何把需求梳理清楚、描述清楚，成了瓶颈。
所以：放弃像匠人那样对每一行代码精雕细琢的执念吧。我们或许该从「建筑工人」转向「建筑师」——用更宏观的视角去观察、审视和思考整个软件产品。放弃我们曾“擅长”和“引以为傲”的「手艺」，把具体实现交给 Agent 吧，它们更快也更好。
Handtyping 不重要了，代码实现也不重要了，最重要的是：不要停止思考。