AI 把"写出能跑的代码"从几小时压到几分钟，却没有把"这段代码在什么条件下会错"变得更容易回答。学习策略的失效点就在这里：过去"写得出来"就是掌握的证明，现在写出来不构成任何证据。真正的分水岭变成三件事——你能判断它错了、能说清为什么、能在工具没给答案时自己走完推理。
下面把知识切成三类，用四条标准逐项判定，再落到路径重排、验证手段和时间配比。
1. 变了什么：三种成本同时下移，幅度不同
| 成本项 | 过去 | 现在 | 对学习的挤压 |
|---|---|---|---|
| 写出第一版可运行代码 | 数小时 | 分钟级 | "会写"不再稀缺，练习量被抽走 |
| 检索一个 API 用法 | 几十分钟 | 秒级 | 记忆型知识贬值最快 |
| 格式转换 | 手工，易错 | 一次生成 | 不必投入 |
| 判断并发下会不会错 | 靠经验与踩坑 | 仍然靠经验 | 价值上升 |
| 定位线上故障根因 | 靠证据链 | 仍然靠证据链 | 价值上升 |
**"生成"跌到接近零，"检索"跌到很低，"判断"没有下降。**凡是成本跌到零的环节，继续投入就是在为一个已经免费的东西付费。
工具能在几秒内给你一段 Spring Boot 3.3.x 的 RestClient 调用：
// 这类代码交给工具：签名、参数顺序、异常类型都是文档可查的细节
RestClient client = RestClient.builder()
.baseUrl("http://inventory:8080")
.requestFactory(new JdkClientHttpRequestFactory())
.build();
Stock stock = client.get()
.uri("/api/stock/{sku}", sku)
.retrieve()
.body(Stock.class);
工具不会告诉你：它默认不设连接与读超时；连接复用取决于底层 java.net.http.HttpClient；retrieve() 在 4xx/5xx 抛 RestClientResponseException 子类，异常链要跟着改。文档能补的交给工具，跨组件推理的必须自己拿。
2. 三分类：学深、浅尝、交给工具
| 类别 | 内容 | 学到什么程度 | 怎么验证 |
|---|---|---|---|
| 学深 | 调试推理：现象→假设→证据的闭环 | 不给提示也能列 3 个假设并设计区分实验 | 陌生栈里说出下一步抓什么 |
| 学深 | 系统边界：事务、线程、网络、进程 | 能画出请求穿过的边界及每处一致性代价 | 预判"这里加 @Async 会怎样" |
| 学深 | 故障归因：指标、日志、链路的对齐 | 从一个慢请求定位到资源争用点 | 凭 traceId 串起证据链 |
| 浅尝 | API 细节：签名、参数顺序 | 知道它存在、知道去哪查 | 合上文档能说清大致用法 |
| 浅尝 | 样板代码：CRUD、配置类、DTO 映射 | 能读懂、能改对 | review 不放过映射错误 |
| 浅尝 | 语法糖：Stream、Optional、record | 能识别滥用 | 指出 Optional.get() 的风险 |
| 交工具 | 格式转换、批量重命名、脚本骨架 | 会用、会验收 | 生成物通过编译与测试 |
| 交工具 | 文档初稿、注释补全、变更说明 | 会校对 | 事实无错、术语一致 |
分界线不是知识本身，而是它在你身上的失败模式。同一条"@Transactional 自调用不生效"，只以"记得有这么回事"存在就是浅尝；能在 review 时自动跳出来就是学深。
3. 四条判断标准
| 标准 | 提问 | 判"学深" | 判"交给工具" |
|---|---|---|---|
| 出错代价 | 用错会怎样 | 静默错数据、只在高峰出错、难回滚 | 立即编译或测试失败 |
| 要解释吗 | 评审、复盘里要不要说清 | 要讲取舍和"为什么不选另一个" | 只需贴结果 |
| 会依赖吗 | 长期不用会不会退化 | 会，退化后无法自查 | 不会，查一次就能恢复 |
| 多久过时 | 三年后还成立吗 | 成立（并发、事务、内存模型） | 不成立（框架 API、脚手架） |
四条做成一张可填表，比凭感觉分配时间靠谱：
# 能力矩阵，每季度重填，只记变化项
capability: 事务边界
error_cost: high # 会长出静默脏数据
explain_to_others: true # 评审必须讲清传播行为
dependency_risk: high
decay: slow # 三年内语义不变
verdict: learn-deep
capability: RestClient 用法
error_cost: low # 编译期或启动期暴露
dependency_risk: low
decay: fast # 大版本间仍在调整
verdict: tool
decay 的判据是看它在 JDK 层的锚点：锚在 JMM、TCP、B+ 树、文件系统的衰减慢，锚在框架某个版本的衰减快。前者能摊很多年，后者摊不过一个大版本。
4. 分工变化：review 比 generate 稀缺
生成趋零的结果是候选供给爆炸，瓶颈从产出移到审阅。代码量不再是约束，判断"这段能不能上"的带宽才是。
| 能力 | 看什么 | 训练方式 |
|---|---|---|
| 分类定级 | 改动属于哪类风险：编译、契约、并发、边界、性能 | review 先写一句风险类别，事后对照真实 bug |
| 找反例 | 构造能让它错的最小输入 | 每段新代码补一个边界用例 |
| 影响面预判 | 谁会因为这个改动行为变化 | 动手前用调用图列出受影响方 |
工具给的代码通常"平均值正确"：主路径对，边界含糊。审阅的着力点就在边界：
@Service
public class OrderService {
private final OrderRepository repo;
public OrderService(OrderRepository repo) { this.repo = repo; }
@Transactional
public void createAndNotify(Order order) {
repo.save(order);
}
@Transactional
public void batchCreate(List<Order> orders) {
for (Order o : orders) {
createAndNotify(o); // 自调用：注解在这里不产生新事务
}
}
}
这段能编译、能演示、mock 掉 repo 就能过测试。要问三件事：batchCreate 的实际传播是什么？中途抛异常时前几条已提交了吗？修结构还是修调用方？这三个问题都不在工具的答案范围内。
5. 路径重排：先有可验证的心智模型
顺序不是"学语法→学框架→做项目"，而是先用最小实验建立可验证的模型，再让工具在模型上加速：
| 步骤 | 动作 | 完成标志 |
|---|---|---|
| 1. 观察现象 | 找真实异常：慢请求、丢消息、连接耗尽 | 一句话描述现象，不掺解释 |
| 2. 提假设 | 2–3 个可能机制，各标可区分点 | 每个假设都有"若是它应观察到 X" |
| 3. 最小实验 | 10–30 行代码或一条命令 | 能排除至少一个假设 |
| 4. 工具加速 | 生成实现、补测试、写文档 | 生成物通过你写的验证 |
第 3 步最容易被跳过，代价是拿到一堆没有条件的结论：
// 自调用时 @Transactional 是否生效（JDK 17 + Spring Boot 3.3.x）
@Test
void selfInvocation_shouldNotRollback() {
assertThatThrownBy(() -> service.batchCreate(List.of(o1, o2, o3)))
.isInstanceOf(IllegalStateException.class);
// 关键断言：异常前写入的记录是否还在
assertThat(repo.count()).isNotZero();
}
6. 验证手段：三个"能不能"
| 验证项 | 做法 | 不合格表现 |
|---|---|---|
| 复述原理 | 关掉编辑器，讲机制与失效条件 | 只有结论，没有条件 |
| 预判影响面 | 动手前写下"哪些调用方会变" | 每次靠全量回归兜底 |
| 独立定位 | 给一条失败日志，直接说下一步 | 第一步是把日志贴给工具 |
影响面预判可以练：
$ grep -rn "batchCreate" --include=*.java src/ | grep -v "OrderService.java"
$ git log --oneline -20 -- src/main/java/.../OrderService.java
$ ./gradlew test --tests '*OrderServiceTest' -i | grep -i "batch"
第二条常被低估：高频变动的代码区上下文还在漂移，那里"看起来对"的实现值得多问一句。
7. 时间分配：按职责三档配比
| 角色 | 学深 | 浅尝 | 交工具 | 说明 |
|---|---|---|---|---|
| 业务开发（0–3 年） | 50% | 30% | 20% | 学深集中在调试、事务、并发 |
| 业务开发（3 年以上） | 40% | 25% | 35% | 浅尝面变宽，机械工作外移 |
| 平台 / 基础设施 | 65% | 20% | 15% | 边界与归因是主职 |
| 技术负责人 | 45% | 30% | 25% | 学深是取舍判断与风险定价 |
配比是纠偏工具：交工具持续超 50% 且 review 漏的问题在增加，说明失衡；学深占比高但交付总慢，说明方向选错了——学深要落在实际决策环节，不是落在听起来更硬的题目上。
8. 排错：五个高频坑
| 现象 | 原因 | 处理 |
|---|---|---|
| 工具很熟，系统能力没长 | 学习停在操作层 | 每学一个工具，回答"它替掉了我哪步推理" |
| 把生成的代码当理解 | 跳过最小实验 | 每个结论补一个能证伪它的实验 |
| 记忆碎片化 | 把工具当搜索引擎，一问一答不留结构 | 建概念图，新知识必须挂到已有节点 |
| "跑通了"当"懂了" | 用通过率替代理解度 | 加判据：说出它在什么输入下会错 |
| 学了新框架，旧问题还在 | 追版本特性，回避薄弱环节 | 做一次能力矩阵，只补 high 项 |
第一条最隐蔽：工具用法的曲线平缓，容易产生持续进步的错觉；系统能力有平台期，短期看不到回报。
9. 边界：这套框架管不到的地方
| 场景 | 为什么失效 | 替代做法 |
|---|---|---|
| 刚入门，连"能跑"都做不到 | 没有可验证的模型 | 先补到能写能跑 |
| 极短周期的救火项目 | 没时间做最小实验 | 事后补复盘，把结论沉淀 |
| 完全陌生的领域 | 无法判断工具输出对错 | 先读权威材料建立基线 |
| 强合规场景 | 判断依据需外部可查 | 以规范条文为准 |
| 工具快速演化 | 用法半年即过期 | 只学接口形态，不背内部细节 |
最后一条值得单独说：不要学"某个工具的用法"，要学"工具这一层的抽象"。同一件事在 IDE 补全、CLI agent、CI 自动修复里形态不同，底层"生成→验证→收敛"的循环一样。
10. 自测
- 三种成本里哪一种没有随工具下降？它为什么决定了取舍方向？
- 拿一个具体知识点走一遍四条判断标准，结论和直觉一致吗？
- "自调用导致
@Transactional失效"，在你身上属于哪一类？依据是什么？ - 为什么 review 能力比生成能力更稀缺？什么团队规模下这个判断会反转？
- 最小实验四步里哪一步最容易被跳过？跳过之后得到什么形态的"理解"？
- 你的时间配比和职责匹配吗？用什么信号判断它已经失衡？