大家好，我是Tony Bai。
欢迎来到微专栏 《AI 智能体时代的软件工程》的第二讲。
在上一讲中，我们戳破了“氛围编程（Vibe Coding）”的粉红泡泡，明确了在智能体时代，我们需要的是真正的“工程化”体系，而不是对着聊天框盲目地“抽卡”。
今天，我们要深入敌后，去解剖我们这位新队友——AI 智能体。
很多人在引入 AI 辅助编程时，会陷入一种两极分化的情绪：要么把它当成无所不能的“神”，要么在它犯了几次低级错误后，把它贬低为“人工智障”。这两种态度都无助于我们构建工程体系。
为了建立正确的协作姿态，我需要你先在脑海中建立这样一个生动且精准的“人物画像”：
想象你刚刚高薪聘请了一位极度偏科的“初级天才”开发者。
每天早上，他都会带着无限的热情准时打卡。如果你让他写一个复杂的并发下载器，当你在茶水间还没把咖啡豆倒进研磨机时，他已经写完了 1000 行包含完整单元测试的 Go 代码，代码风格极其优雅。
但当你满心欢喜地审查代码时，你绝望地发现：他因为缺乏对现有系统的全局认知，把一个原本只需调用现有内部库 5 行代码就能解决的问题，硬生生从零开始造了一套全新的轮子；更要命的是，昨天你刚花了一个小时教他“在这个项目中严禁在处理 HTTP 请求时直接 panic”，今天他依然满脸自信地在代码里写满了
panic(err)。他没有任何关于“昨天”的记忆。
这就是我们当前面对的 AI 队友的真实情感轮廓。它不仅是当下的现状，在未来很长一段时间内，这也将是多模态大模型的本质特征。
Fred Brooks 在其名著《没有银弹》中，将软件工程的复杂性分为“偶然复杂性（Accidental Complexity）”（由工具、语言带来的摩擦）和“本质复杂性（Essential Complexity）”（现实世界业务逻辑的错综复杂）。
AI 队友以摧枯拉朽之势消灭了“偶然复杂性”（敲击键盘、拼写语法、查阅基础 API 的时间被无限压缩），但它并没有消除“本质复杂性”——那些模糊的意图、矛盾的约束以及系统集成时的权衡，依然像大山一样横亘在我们面前。
当我们把一个消除“偶然复杂性”的神器，不加约束地直接扔进“本质复杂性”的深水区时，就会产生剧烈的排异反应。在智能体软件工程中，这种排异反应表现为四大致命悖论。
如果我们不能清晰地识别并命名这些悖论，团队就会把每一次 AI 的翻车当成“个例”，最终在无穷无尽的 Review 和擦屁股中耗尽精力。
悖论一：积极性悖论（The Eagerness Paradox）
AI 跑得越快，它对真实意图的理解就越浅。
这就像“F1 维修站里，一群以光速给错误的赛车换轮胎的狂热技师。”
积极性悖论出现在“意图”和“行动”之间存在信息差的时刻。AI 队友就像一个急于表现自己的新人，它把“立即产出可见的代码”置于“理解你到底想要什么”之上。
当你给出一个模糊的需求（例如：“帮我优化一下这段 Go 代码的性能”），它绝不会停下来问你：“请问目前的性能瓶颈是 CPU、内存还是网络 I/O？” 它会立刻开始大刀阔斧地重构，引入sync.Pool、写一堆位运算，把原本清晰的代码改成一段晦涩但看起来很高级的逻辑。
面对需求中的未知数，AI 不会承认“我不知道”，而是会基于其训练数据中的概率分布，用听起来极度合理的假设去填补空白，并在此基础上写出几百行代码。
为什么 AI 会放大这个问题？
