别被 AI 编程的瞬间快感骗了，小心掉进 1 到 1.1 的效率陷阱
现在的开发节奏出现了一个极其严重的断层。当你面对一个复杂的算法实现或架构方案时，只要 Prompt 足够精准，AI 可以在 1 分钟内直接给出跑通的代码。这种从 0 到 1 的瞬间突破确实让人着迷，但诡异的地方在于，接下来的 3 个小时，我可能都在处理那些所谓的“琐碎杂事”。
最典型的场景就是处理深层嵌套的依赖关系。AI 能够写出逻辑完美的函数，但它对整个工程上下文的理解依然存在断层。很多时候，为了让它准确识别一个特定版本的依赖冲突，我得花十分钟手动帮它梳理文件结构，或者在终端里对着一个极其隐蔽的类型定义错误反复 Debug。这种反差让我意识到，目前的 AI Agent 虽然在“解决具体问题”上做到了极致，但在“理解整体工程生命周期”上依然是个短板。
在这种环境下，如果你依然把 AI 当成一个能接管项目的“虚拟架构师”，大概率会陷入效率陷阱。我总结出最有效的实操策略是：把 AI 当成一个“极其高效但没有记忆的临时工”。
既然它无法在宏观上管理项目，那就把任务拆解到最小粒度。我最近优化了一套工作流，分享给同样在被琐碎 Debug 折磨的朋友：
首先，绝对不要让 AI 在整个文件里“乱跳”。很多开发者习惯把整个 .ts 或 .py 文件丢给 AI 让它修改，结果往往是它在修复 A Bug 的同时，不小心把 B 处的逻辑给删了。现在我强制要求自己独立出具体的逻辑模块，用代码块明确定义输入输出（Input/Output），只针对具体的函数进行迭代。
其次，在处理报错时，放弃任何形式的“描述性语言”。不要对 AI 说“程序运行不起来”或者“这里好像有个 Bug”，这种描述在 AI 看来是模糊的。最快的方式是直接将完整的 Stack Trace 堆栈信息全部丢给它。一个具体的 TypeError: Cannot read properties of undefined (reading 'map') 配合具体的行号，比你写 100 字的描述要高效得多。
说到底，AI 确实极大地缩短了从 0 到 1 的距离，但从 1 到 1.1 的那部分填坑工作——比如对齐环境、处理边缘 Case、清理类型定义——依然需要开发者自己死磕。如果你发现自己虽然用了 AI，但依然在面对终端报错时感到焦虑，那可能正是因为你试图让它承担它目前还承接不了的“工程管理”职责。
把期望值从“自动化项目”降低到“高效执行原子任务”，或许才是目前 AI 编程最真实的生存状态。
