用了一个月的 Claude Code 之后，最终还是取消了 Cursor 的订阅。
我是很早就开始用 Cursor 来辅助编程的，最爱的就是 Tab 补全的能力。
一开始其实是想要保留 Cursor 的，毕竟，Tab 补全实在太好用了。
但是对于 AI 直接修改我的代码，一直都还是不太放心的，毕竟 bug 是 AI 写的，但是锅 AI 是背不了的。
其实起初这些 AI 命令行工具的出现，并没有带给我太多的惊艳，毕竟只是个终端工具，怎么可能比得上编辑器的强大呢？
但是后来机缘巧合之下，我开始重度使用 Claude Code，到现在大概刚好一个月，这期间，其实对于这种终端工具的改观，可谓是非常之大。
首先，它是终端工具，但是这类工具也有非常多的其他形态：
- vscode/cursor 扩展
- Claude Code 电脑客户端
- Claude Code Web 端，pc & mobile
- Claude Mobile App
其中，仅仅是编辑器的扩展，就基本上能够替代 Cursor 除了 Tab 补全的所有能力了。
而 Tab 补全，正是我一直没有退订 Cursor 的原因。
但是，如果一行代码都不需要写了呢？那还需要 Tab 补全吗？
答案显而易见，不写代码，Tab 补全自然就没有什么吸引力了。
但是说实话，真能放心把 coding 全部交给 AI 吗？
我的转折发生在一次技术需求上：给现有的平台做一个问答机器人。
这涉及到：
- 历史对话的管理：CRUD + 前端展示
- token 消耗的统计：CRUD + 前端展示
- 平台知识库的构建和更新：RAG or 提示词注入？
可以说是一个小全栈项目了。
在 Plan Mode 和 AI Battle 多轮之后，鉴于知识库内容不多，最终确定了方案：
不走 RAG 知识库，而是借鉴 Claude Code 中 Skills（按需加载知识）的方案，渐进式的加载我们的知识文档。
也就是首先在系统提示词中注入文档描述和名称，并告知 AI 如果发现问的是某一块的知识，就用工具去读取对应的文档，再注入上下文。
从而完成所谓 Skills 的渐进式披露，也避免所谓的系统提示词爆炸的问题。
在做好计划之后的那一刻，我犹豫了，因为涉及到数据库，前端样式，知识库文档的提取脚本和工具调用的实现。
按照以往的经验，接下来我会一个小步骤一个小步骤的让 AI 来帮我实现。
但是那天，我想了想，干脆切个分支，交给 AI 全部实现吧，反正如果改的太脏了，就抛弃分支重写呗。
索性按下了回车，喝个茶的功夫，代码就生成好了，不能说完全没有 bug，但是基本能用，剩下的都是一些小细节优化。
这是我着实没想到的。
分分钟就完成了，换我自己搞，拖拖拉拉得干好几天，更别提还得一步一步 debug。
也就是这一刻开始，我退订了 Cursor，因为确实没必要写代码了。
沟通方案 -> AI 执行 -> 我验收提出修改意见 -> AI 执行 -> 我验收提出修改意见 -> …..
依次循环。
如果方案不确定，那么 AI 输出确实是不稳定的。
但是在方案明确，只剩执行这个 Action 的时候，AI 绝对是扛把子，效率是人工的百倍都不止。
后来，我又和 AI Battle，讨论了 v0（Vercel 出品的 AI 前端生成工具）的原理，并得到了实现一个 v0 的方案。
这一次，我又选择了让 AI 来实现，只能说，分分钟，一个自己版本的 v0 就有了。
这里面，coding 这个环节，反而成了最轻松的环节。
Battle 方案陆陆续续花了我三天的时间，但是 demo 的产出，就是一杯咖啡的时间。
可以看到，这个工作量，手写的话有多少就不说了。单单只是看相关技术的文档，都要琢磨个几天，更别提实现了。
有一说一，AI 的出现确实极大的提高了程序员的生产力，以前几天才能实现的功能，AI 几下就搞定了。
但是生产力提升的背后，其实也是一种角色转变。
以前写代码，是程序员的核心工作。现在写代码，反而成了最不重要的一环。
真正花时间的，是想清楚要做什么、怎么做、做出来对不对。
也许这才是这一波 AI 浪潮真正在重塑的东西——不是用 AI 替代程序员，而是把程序员从”实现者”变成”决策者”。
作为一个写了好几年代码的人，说实话心情挺复杂的。曾经引以为傲的手速和调试技巧，突然就不那么重要了。但换个角度想，能把精力放在更有价值的思考上，也未尝不是一件好事。
这个趋势，不以任何人的意志为转移，顺势而为，可能才是正确的打开方式。