最近半年，我越来越频繁地使用 Cursor、Claude Code、Codex 这类 AI 工具开发 Java 项目。
有一个现象让我印象特别深。
以前大家讨论 AI 编程，关注的是：

• AI 会不会写代码
• AI 能不能写复杂系统
• AI 会不会取代程序员

但实际使用下来，我发现这些问题正在慢慢失去讨论价值。
因为现在的大模型已经足够强了。
真正的问题开始变成：

AI 当然能做出来，但它要付出多大的代价？

---

AI 已经很强了，真的很强

先说结论。
我并不认为现在的 AI 不会写代码。
恰恰相反。
如果只是实现功能，现在的大模型已经强得超出很多人的预期。
给它一个存在多年历史包袱的项目：

• 多套编码规范
• 命名不统一
• 缺少文档
• 大量复制粘贴
• Mapper + XML
• DTO、VO、Entity 多层转换

它依然有很大概率最终把需求做出来。

很多时候我甚至觉得：

AI 对垃圾代码的容忍度，比新人程序员还高。

新人可能看几分钟就放弃了。
AI 不会。
它会一直读。
一直分析。
一直推断。
最终把功能完成。
所以今天的问题已经不是：

AI 能不能完成需求。

而是：

AI 需要花多少成本完成需求。

---

AI 最大的成本，不是生成代码

很多人觉得 Token 主要消耗在生成代码上。
实际上并不是。
真正消耗资源的往往是：

读代码
↓
恢复上下文
↓
理解规则
↓
生成代码
↓
验证
↓
修正

尤其是在大型项目里。
一个看起来很简单的需求：

给用户查询增加状态条件

真正修改的代码可能只有：

.eq(User::getStatus, status)

一行。
但 AI 为了找到这一行，可能需要：

• 阅读 Controller
• 阅读 Service
• 阅读 Mapper
• 阅读 XML
• 阅读 DTO
• 阅读分页逻辑
• 阅读权限逻辑
• 阅读租户逻辑

最终消耗的大部分 Token，并不是写代码，而是在理解代码。

---

以前的 AI 靠猜，现在的 AI 靠理解

这里有一个很有意思的变化。
很多人认为：

模型越来越强，这些问题迟早会消失。

但我越来越怀疑这一点。
因为高智能模型和低智能模型的工作方式其实不一样。
低智能模型：

不知道
↓
直接猜

高智能模型：

不知道
↓
先查
↓
继续查
↓
理解
↓
验证
↓
再修改

模型越聪明，往往越不愿意瞎猜。
这当然是好事。
错误率降低了。
编译失败变少了。
但问题也来了。
它开始疯狂读取上下文。

---

猜测成本在下降，理解成本在上升

过去我们担心的是：

AI 会不会猜错。

未来更值得关注的问题可能是：

AI 为了写对，到底需要理解多少东西。

例如下面这段代码：

userMapper.listByStatus(status);

一个能力较弱的模型可能直接猜：

userMapper.selectActiveUsers();

然后编译失败。
能力更强的模型则会：

• 搜索 Mapper
• 搜索 XML
• 搜索调用链
• 搜索 DTO
• 搜索相似实现

确认以后再修改。
准确率提高了。
但成本也提高了。
因此未来 AI 编程的瓶颈可能不再是：

如何让 AI 少猜一次。

而是：

如何让 AI 少读十个文件。

---

为什么有的项目特别费 Token

我发现一个现象。

同样一个需求。

有些项目 AI 一次完成。

有些项目 AI 要修改三四轮。

差别往往不在模型。

而在代码结构。

例如下面两种情况。

场景一

一个查询涉及：

Controller
↓
Service
↓
Mapper
↓
XML
↓
DTO
↓
VO

AI 必须不断恢复上下文。

---

场景二

查询逻辑集中在局部：

List<User> users = DB.Pojo.select(User.class)
    .eq(User::getStatus, status)
    .orderByDesc(User::getCreateTime)
    .queryBeanList();

表、条件、排序、返回值全部可见。

AI 基本不需要跨文件分析。

两种写法都能完成需求。

但理解成本完全不同。

---

AI 时代可能会出现新的评价标准

过去评价框架，我们关注：

• 性能
• 扩展性
• 学习成本
• SQL 控制能力
• 生态成熟度

这些依然重要。

但 AI 参与开发以后，我觉得还应该增加一个维度：

完成同一个需求，需要消耗多少上下文成本。

例如：

指标	项目A	项目B
阅读文件数	3	25
修改轮次	1	4
编译次数	1	5
Token消耗	2万	15万
最终结果	成功	成功

结果一样。

成本却可能相差数倍。

---

AI 不怕复杂，它怕隐含规则

很多人觉得 AI 需要简单项目。

其实未必。

AI 不怕复杂。

AI 怕的是规则藏得太深。

例如：

• 方法命名依赖团队约定
• SQL 分散在多个文件
• 多套历史写法并存
• 返回值需要跳转查看
• 业务规则隐藏在配置里

这些东西人类开发者可以靠经验补齐。

AI 只能靠理解。

而理解是有成本的。

---

最后

AI 已经强大到能够在很多混乱的系统里完成任务。

未来优秀框架和优秀代码的竞争，可能不再是谁能让 AI 做出来。

而是谁能让 AI：

• 少读文件
• 少恢复上下文
• 少理解隐含规则
• 少修改几轮
• 更快一次完成

因为对于 Agent 来说：

一次完成

和：

五次修正后完成

结果一样。
但成本完全不同。
后面我准备做一些真实实验：

• 同一个需求在不同 ORM 风格下的 Token 消耗
• AI 修改数据库代码需要读取多少文件
• 不同代码结构下的修改轮次对比
• 编译失败次数对比

看看哪些代码结构，真的更适合 AI 时代的软件开发。
如果你也在用 AI 写代码，欢迎留言交流。