我用AI写代码3个月后，80%的工作消失了

去年Q3，我统计了自己写代码的时间分配：找文档占35%，调试占28%，真正写逻辑只有22%。

这个数字让我后背发凉。不是焦虑被AI取代，而是发现我的注意力被切碎成了渣。

从"全栈工程师"到"提示词调度员"

转变发生在一次凌晨的部署。我盯着终端里跳动的报错，突然意识到：过去两小时，我一直在做一件AI能10秒完成的事——把错误日志粘贴到搜索引擎，筛选Stack Overflow答案，试错，再粘贴。

第二天我装了Cursor。第一周很不适应，像从手动挡换到自动挡，脚总去找不存在的离合。但第三周发生了一件事：我让AI重构一个200行的数据处理脚本，它不仅完成了，还指出了我三年前埋的一个竞态条件bug。

我从来没跟它提过这个bug。

现在我的工作流裂成了两块。80%的任务交给Agentic IDE（智能体集成开发环境）：写脚手架、补全测试、迁移依赖、解释遗留代码。20%留在终端：架构决策、性能调优、那些需要"闻"出代码味道的场景。

这个比例不是拍脑袋定的，是三个月试错后的真实统计。

为什么终端UI死不了

有个反直觉的现象：AI编码工具越强大，我反而更珍惜终端的干净。

Agentic IDE像一位话痨的副驾驶，总在猜测我要去哪。好处是省油门，坏处是省掉了"迷路"的过程——而很多关键洞察恰恰来自走错路。上周我排查一个内存泄漏，AI三次给出"合理"但错误的方案。最后是在终端里手动 strace（系统调用追踪），才定位到一个第三方库的隐藏行为。

终端的沉默是一种筛选机制。它逼你明确知道自己要什么，而不是被自动补全牵着走。

我现在的配置是：双屏，左边Agentic IDE跑常规任务，右边终端保持最小化。当左边开始"过度服务"——比如主动建议我用某个我没听过的框架时——我就切到右边，用vim写一段纯文本伪代码，理清思路再回去。

那个被忽视的20%

真正让我警惕的，不是AI能做什么，而是我开始忘记自己能做什么。

上个月团队面试，我问候选人："如果没有任何AI辅助，你怎么调试一个生产环境的死锁？"对方愣了五秒，说"我会让AI分析线程dump"。我追问然后呢？他说"AI会告诉我哪个锁顺序有问题"。

这个回答技术上没错，但缺少了一层：死锁往往只是症状，真正的病灶可能在业务逻辑的设计假设上。AI能定位锁，但读不懂那些没写进代码的上下文——为什么当初要设计这个异步流程？哪个产品经理的 deadline 逼出了这个妥协？

这些藏在代码褶皱里的信息，终端不会告诉你，AI也不会。

我现在刻意保留了一些"低效"习惯：每周至少两小时纯终端编码，不用任何补全；读源码时先手动画调用图，再让AI验证；遇到报错先自己看栈帧，忍住不第一时间粘贴。

这些动作很慢，像是在肌肉萎缩后做复健。但三个月下来，我发现一个变化：当AI给出建议时，我能更快判断它是"对的"还是"看起来对的"。

工具迭代背后的老问题

Agentic IDE和终端的争论，本质是"效率"与"掌控感"的拉锯。这个张力从GUI诞生那天就有了，只是AI把它推到了极端。

我的观察是：新手倾向于把80%押在AI上，因为能快速产出；老手反而收紧到60%甚至更低，预留更多"浪费"时间给深度思考。这不是保守，是对"认知债务"的敏感——今天省下的理解成本，明天会变成调试时的复利利息。

有个细节很有意思。Cursor最近的更新加了"Yolo模式"，AI可以自动执行终端命令。我试过一次，它差点把我本地的数据库删了。现在我的配置是：Yolo模式只开只读权限，写操作必须手动确认。

这个开关的位置设计得很妙——它默认关闭，且每次开启都有警告。产品团队显然知道用户会怎么滥用这个功能，但他们选择不替用户做决定。

这种"有节制的放任"，或许就是下一代工具的设计哲学。

你现在的工作流里，AI占多少比例？有没有某个时刻，你故意关掉了它？