语之溪
刚接触一个不熟悉的业务模块时，最先遇到的通常不是某一行代码不会写，而是不知道这个模块为什么存在、数据从哪里来、最后又流向哪里。
这时候可以让 AI 帮忙整理代码和问题，但不能把一个陌生模块直接丢给它，然后期待得到完整而准确的结论。没有业务背景，代码中的类名和方法名很容易被解释成另一种意思。
先确认模块的边界
面对陌生代码，我会先尝试回答几个问题：
- 这个模块处理什么业务对象；
- 谁会调用它；
- 输入参数从哪里来；
- 处理结果会被谁继续使用；
- 哪些状态或权限会影响处理过程。
如果这些问题还没有答案，就先不要急着让 AI 解释每个方法。可以先从入口、接口、服务类和数据访问位置开始，把模块的大致边界画出来。
请求入口
-> 参数校验
-> 业务服务
-> 数据访问
-> 状态变化
-> 返回结果这只是通用的阅读顺序，不对应某个内部项目的真实结构。它的作用是先建立一张粗略地图，再去理解具体代码。
给 AI 的上下文要足够小
一次放入大量代码，并不一定能得到更好的回答。代码太多时，真正需要解释的部分反而容易被淹没。
我会优先提供：
- 当前类或方法的职责；
- 被调用的方法签名；
- 相关参数和返回值；
- 一小段关键逻辑；
- 自己已经确认的业务背景；
- 具体想弄清楚的问题。
比如，不要只问“这段 Java 代码是什么意思”，而是说明“这是一个处理某类业务记录的服务方法，我想知道它在哪些条件下改变状态，以及返回结果会影响什么”。这样得到的回答更容易围绕问题展开。
当然，业务背景必须使用脱敏后的抽象描述，不能把真实客户、内部地址、账号或业务数据直接交给外部服务。
先让 AI 解释，再自己回到代码
AI 可以帮忙把一段代码拆开说明，也可以列出可能的调用关系。但这些内容只能作为阅读的辅助线索。
提出具体问题
-> AI 整理代码关系
-> 回到入口和调用方确认
-> 对照实体、数据库和状态定义
-> 记录确认后的理解如果 AI 说某个字段表示一种状态，我还需要回到代码中搜索它的赋值和判断位置。如果 AI 说某个方法一定会被某个接口调用，也要从实际调用方确认，而不是因为解释听起来合理就接受。
一个脱敏的状态流转示例
业务模块经常会有类似的状态变化。下面是一个通用示例，用来说明阅读代码时可以关注哪些条件：
public String nextStatus(String currentStatus, boolean approved) {
if ("DRAFT".equals(currentStatus)) {
return approved ? "PUBLISHED" : "REJECTED";
}
return currentStatus;
}看到这样的代码，可以继续确认：谁有权传入 approved，退回之后是否允许重新提交，已经发布的记录能不能再次修改，状态变化是否需要记录操作人和时间。
代码只表达了一部分规则，真正的业务含义还在调用方、权限判断、数据模型和流程约束里。这个示例是通用代码，不代表某个工作系统中的实际实现。
AI 可能会把猜测说得很肯定
陌生业务模块最容易出现的问题，是把推测误认为事实。类名、变量名和注释可以提供线索，但它们不一定完整，也不一定和实际行为完全一致。
因此，我会把 AI 的回答分成三种：
- 已经能从代码和配置中确认的内容；
- 需要继续搜索调用关系才能确认的内容；
- 仅根据命名和常见模式推测的内容。
第三类只能当作排查方向，不能直接写进模块说明，更不能据此修改业务逻辑。
理解业务比理解语法更重要
Java 语法、框架注解和常见设计模式可以通过资料快速补充，但一个业务模块真正难理解的部分，通常是它为什么这样处理数据，以及某个状态变化会影响哪些后续流程。
AI 可以帮助我减少查资料和整理代码的时间，但它不能替我获得项目上下文。最终仍然要自己确认入口、数据、权限、状态和结果之间的关系。
让 AI 帮我理解陌生业务模块，比较合适的方式不是让它替我读完整个项目，而是先由自己划定问题，再让它解释局部内容，最后回到代码和业务规则中验证。这样得到的理解速度可能更快，但结论仍然必须建立在可以追溯的代码和资料上。
