一个传统软件团队用 AI 写项目代码的真实复盘
我们用智能体生成了一整套项目代码，开发同事却从头改了一遍。这篇文章不复盘具体产品，复盘我们对"模型 vs 智能体"这件事的认知变化——包括一个被忽略的数学事实，和上线之后才暴露的另一个瓶颈。
先说一个让团队有点不爽的事实。
前段时间，我们用智能体生成了一整套项目代码——需求拆解、契约设计、接口文档、后端 Service、前端 API，模块齐全，目录规范，编译通过。
然后我们把它交给了开发同事。
开发同事打开 IDEA，装上 AI 编程插件，从头到尾检查、修正、收尾了一遍。
我们生产的，是一套"结构完整的代码"，不是一套"能直接跑的代码"。
这件事逼着我们把一个问题想清楚了：
用 AI 做软件开发，到底是模型更重要，还是智能体（工具链）更重要？
写这篇文章，把我们的真实账本摊开。
一、先把问题问对：这不是二选一
我的结论先放这儿：
· 模型 = 单步能力上限。一次调用写出来的代码质量、推理深度、长上下文一致性。
· 智能体（工具链） = 把单步能力兑换成"交付物"的工程层。上下文管理、任务拆解、验证闭环、失败重试、领域知识沉淀。
一个是发动机，一个是变速箱 + 底盘 + 导航。
马力大不代表车能到目的地——但发动机太弱，路书再对也白搭。
关键在于：什么时候，谁的权重更大？
答案不在"哪个更强"，而在这件事正处在哪个阶段。
二、一个被忽略的数学事实：链条越长，差距越致命
这里有个残酷的数学。
假设 AI 每一步的正确率是p，一个任务要连续做n步，那整条链走通的概率大约是pⁿ。
看明白了吗？
单步正确率从 95% 提到 99%，看着只差 4 个百分点。但在 200 步的链条上，这是0% 和 13%的区别——差几个数量级。
一个真实项目有多少步？我们手上一个中等规模的 Java 后端：200 多个类，19 个业务域，横跨 Entity、DTO、VO、Query、Mapper、Service、Controller 七层。
这大约是几千个决策点的链条。
所以"AI 生成的代码跑不起来"，不是因为它某一步写得很烂，而是因为它有几千次机会累积小错误。
这也直接解释了另一件事：为什么大项目必须有人或强模型收尾。
不是智能体不行，是链条太长。
在生成期，模型是被严重低估的那一方。
三、我们做的那套"工程化"，到底管什么？
我们在智能体这边做了不少事：契约先行、模块拆分、编译兜底、跨模块字段对齐……
这些有用吗？非常有用。但要搞清楚它们管的是哪一段：
我们搭的那套东西，本质是一台"完成度机器"——它保证 19 个业务域的文件都被生成了、目录结构对、接口定义一致、编译能过。
但每个函数体写得对不对，它管不了。
更扎心的是：当模型不够强时，智能体放大的其实是错误——让错误变得更规模化、更整齐、更不容易被发现。
反过来也一样：既然生成期的胜负手是模型，就更不该拿一个模型干所有事。契约设计、跨模块对齐、编译错误的根因分析，交给最强的模型；样板代码、DTO、注释、文档，交给便宜的——把贵的能力花在刀刃上。
四、另一个问题：代码上线之后
这里要先把一件事说清楚，因为它特别容易被混：
前面讲的是生成期，那是模型的地盘。
而把团队时间真正吃掉最多的，是维护期。
系统跑起来之后，难的不是"从零写一个新功能"，而是细节的调整和完善：加个字段、改个校验规则、对一下前后端接口、修一个只有跑起来才暴露的问题。
这个阶段有个很现实的约束：跑在服务器上的智能体，用不上了。
因为改完要编译、要热部署、要断点调试、要立刻看见效果——AI 必须长在 IDE 里。所以真正的主力，变成了 IDE 里的 AI 编程插件（它本身就是一种智能体）。
但用下来，它有个很具体的表现：
每次让它改点小东西，它都要先"检索并构建很长时间的上下文"。
为什么？我把它拆开：
- 后端是分层架构。改一个字段，牵扯 Entity → Query → DTO → VO → Mapper.xml → Service → Controller，少说 6~8 个文件
- 按关键词搜索，命中一堆同名类（光 Query 就 19 个、VO 有 47 个）
- 接口对接要同时拿前后端两套上下文，检索量翻倍
- 项目里没有任何"地图"，AI 只能靠一轮轮搜索 + 读文件，自己把这条链摸索出来
结论很清楚：维护期的瓶颈不是"生成能力"，是"定位能力"。
它不缺写代码的手，缺的是知道该改哪些文件。
（维护期具体怎么解，是另一个话题了——它跟"模型还是智能体"这个问题无关，这里就不展开了）
五、回到最初的问题
所以，模型重要还是智能体重要？
我的答案是：
如果你问我，团队的钱和时间该往哪投，我会给一个判断句：
因为模型是别人的，会一直变强、一直变便宜；而你沉淀的领域规范、项目契约、验收标准，才是自己真正的资产。
最后
写这篇不是要争个高下。
AI 编程走到今天，真正拉开差距的，早就不是"你用了哪个模型"，而是：
你有没有分清：此刻的瓶颈，到底是"写不对"，还是"找不到"。
写不对，去换更强的模型。
找不到，去把上下文和地图做出来。
模型负责它擅长的，智能体负责它擅长的，人负责做判断。
这才是 AI 编程在传统软件项目里，真正能落地的样子。