如果 AI 让你写代码的速度反而变慢了，可能不是工具的问题

我最近在带一个 RPA（针对老旧软件的数据录入自动化）的大型项目，最近真的产生了一种很强烈的挫败感：我发现让 AI Agent 从零开始构建复杂功能确实很爽，但一旦涉及到现有庞大代码库的维护，AI 简直就是个灾难。

现在的实际情况是，如果我不把低级别的实现细节（low-level specs）写得极其精确，或者我不提前拆解好现有的代码结构该怎么改，AI 就会开始“自由发挥”。它一旦开始自己做架构设计或逻辑决策，那种细微的逻辑偏差（nuance）就会被无限放大，最后直接导致严重的 Bug 或者直接搞垮 SLA（服务等级协议）。

我总结了一下现在的痛点，大家看看有没有共鸣：

• 编写 Spec 的成本过高： 为了让 AI 不跑偏，我得花大量精力去写那种极其详尽的、保姆级的技术规格说明书。
• 审查成本爆炸： 盯着 AI 生成的代码进行 Review 和评估，比我自己亲手一行行写代码还要累，认知负荷（cognitive demand）简直是指数级上升。
• 决策权的博弈： 信任 Agent 的设计决策 = 埋雷；完全控制 Agent = 失去自动化意义。

我感觉现在的矛盾点在于，我们原本想用 AI 来提效，结果却陷入了“为了用 AI 而不得不做更多前期准备和后期审计”的怪圈。这种从“写代码”转向“写极其精准的指令+高强度 Code Review”的模式，在处理这种逻辑严密、耦合度高的老旧系统时，效率反而不如纯人工。

我不知道是我对 Agent 的掌控力还没到位，还是说在处理这种高复杂度、高确定性要求的业务时，目前的 LLM 逻辑推理能力根本就撑不起这种自动化的幻想。