用 AI 跑代码跑得太快，反而让我陷入了“过度工程”的死循环

很多公司现在推 AI 提效，老板看的是交付速度，但实际操作的人会发现一个很诡异的现象：代码写得太快、太全了，反而成了负担。我最近在公司里用 Kiro 写代码、用 Claude 做 Review，效率确实起飞了，但我也掉进了一个坑——就是我明明打算写个临时方案，结果 AI 帮我把它做成了“生产级”标准，最后我花在 Review 和确认这些冗余细节上的时间，比写代码本身还长。

为什么 AI 帮我把临时代码写成了过度工程

我之前在做一个内部小工具，只是为了验证一下技术栈能不能跑通，在文件夹里明确标注了 [THROWAWAY]（丢弃用），心里预设只花两小时搞定。结果 Kiro 自动帮我补全了字节一致性测试，精准锁定了所有依赖版本，甚至写了一个带漂移检测的同步脚本。

最绝的是，我把代码扔给 Claude Review，它不仅没说多此一举，反而觉得这些优化很专业。我当时也觉得挺好，就给通过了。结果就是，一个本该被删掉的临时模块，最后被我以“生产级”的标准给部署上线了。

这就是现在的痛点：AI 不会累，它永远在追求“更完整”、“更严谨”。但作为人类，我们的注意力是有限的。当你习惯了点“Approve”的时候，你其实在潜意识里接受了 AI 带来的所有冗余。在这种环境下，如果你没有一个明确的“停止标准”，你会被 AI 卷到精疲力竭。

尝试用 Satisficing 策略来强制停止

为了不被 AI 卷死，我试着把一个经济学概念 Satisficing（满意化）引入到开发流程里。简单说，就是不要追求“最优解”，而是在达到“足够好”的标准时立刻止损。

我在实际操作中把这个过程拆成了三步，建议大家在用 Agent 协作时也试试：

1. 在 Prompt 里明确定义“足够好”的标准。
不要只说“写一个登录模块”，要说“写一个能跑通登录流程的简单 Demo，不需要考虑多语言、不需要写复杂的异常处理，只要能进入主页就行”。
2. 拿到第一个满足条件的方案就停下。
不要尝试让 AI “再优化一下”或者“看看有没有更优雅的写法”，除非这个点直接影响性能。
3. 强制进入下一个任务。

我之前尝试过一个配置，在给 Kiro 下指令时加上一段限制，效果还行：

# 任务约束配置
constraint:
  max_complexity: "low"
  avoid_over_engineering: true
  stop_condition: "functional_minimum"
  review_focus: "logic_correctness_only" # 明确告诉 Reviewer 不要纠结于代码优雅度

实际操作中的体感差异

• 之前： 提交一个需求 → AI 给出超完备方案 → 我花 1 小时 Review 那些我其实不需要的优化 → 陷入“既然这么完美，那我得把它维护好”的心理负担 → 疲惫。
• 现在： 设定一个底线 → AI 给出能跑通的方案 → 检查核心逻辑 → 直接部署 → 结束。

这种切换最难的地方在于克服“追求完美”的心理。在公司环境下，很多人习惯把代码写得漂亮来证明自己的价值，但现在 AI 一个人就能把代码写到极其漂亮，这种竞争已经没有意义了。

现在的核心竞争力不再是谁能写出最严谨的代码，而是谁能决定哪些地方【不需要】严谨。如果你发现自己每天在 Review AI 生成的冗余代码，建议直接在 Prompt 里砍掉那些不必要的细节，把时间留给真正的架构思考，而不是在 AI 制造的“完美陷阱”里打转。