AI 不会消除过度工程，只会加速它

过度工程，就是用复杂的方式去解决简单的问题：用微服务做一个落地页，为十个用户上 Kubernetes，流量并不大却按百万请求来设计架构。你用金钱和时间，买下了一个远比问题本身复杂的方案。

激励机制就是这样搭起来的。复杂的方案看着专业，简单的方案看着没做完。没有人因为选了 Kubernetes 被辞退，被辞退的是没考虑扩展性的人。在这种不对称之下，多留一手是理性的，于是开发者都在多留一手。

AI 是从开源代码和文章里学来的，而那里占主导的是大公司的方案：博客是他们写的，框架是他们发布的，风向也是他们定的。但他们面对的问题不一样，数百万用户、数百名开发者、监管要求。

面对「写一个认证」这样的要求，模型给出的是它见得最多的东西：带抽象层和接口的分层结构，以及对你永远不会遇到的场景的处理。对互联网上那个平均需求来说，这是正确答案。只是你的项目并不落在那个平均值里。

过去，复杂是用时间来付账的。写五层抽象要花一周。到第三天前后，人就开始怀疑这些层是不是真的需要。价格本身起到了刹车的作用。

现在同样的五层，一分钟就生成好了。代码读起来通顺，测试通过，功能能跑，表面上一切正常。但复杂的主要代价不在写，而在维护。半年后要在这段代码里改点东西，账单那时才会送来。这是在瞬间、且没有经过自觉决定就背上的技术债。

过度工程唯一的天然刹车消失了。问题不在生成质量：代码可以非常好。问题在于它变得太便宜了。

把 AI 当编辑用

常见的做法是另一种：开发者要求从零生成一个模块，拿到 500 行，直接贴进项目。没有人会去弄清楚哪些是多余的，代码能跑就行。过度工程就是这样，一次生成就进了项目。

把顺序反过来，结果就不同了：

1. 先自己写。三十行，一个简单的 JWT，一个校验函数。代价换来的是：每一行你都懂。
2. 然后交给 AI 去精简。「这是代码。把没有它也照样能跑的部分全部去掉。告诉我哪些可以扔。」
3. 逐条审视建议。有一部分会跑偏，但在这个模式下模型表现更好：找出多余的东西，比凭空想出必要的东西更准。

编辑时有一个参照点，你的代码，以及你对任务的理解。生成时没有参照点，模型就把那个平均值填了进去。

还有两个办法：

• 在提示里加约束。如果要从零生成，就把边界说清楚：「能跑起来的最简单方案。不要框架，不要抽象层。SQLite，一个文件。」
• 项目上下文。「我有 100 个用户，一台十美元的服务器」这句话对答案的影响，比任何措辞上的打磨都大。

那些把 AI 智能体用得最深的公司，在生成周围搭起了一整层约束。

根据公开描述，Stripe 每周有一千多个 pull request 经过 AI 处理。交给智能体的任务定义得很窄：不是「做个功能」，而是严格限定范围的改动。智能体能用的工具是人工挑选的。每一个结果都要经过检查。公司有意牺牲了任务的规模，换取结果的可预测性。

Google、Shopify 和 Airbnb 的架构各不相同，行业里没有统一标准，每家都按自己的风险来搭。共同点在于：把智能体嵌进已有的流程（GitHub、Slack、Linear），并在外面围上检查。

没有一家会把生成结果「照单全收」。价值来自生成外面的那圈框架。

AI 放大的是开发者脑子里本来就有的东西。把事情复杂化的倾向，它几秒钟就能实现；砍掉多余的习惯，同样如此。

「这段代码对这个任务来说太复杂了」，这个判断依然由人来做。AI 只是把它执行得更快。