用 AI 读陌生代码：先沿一条数据路径建立理解
打开一个陌生项目，先让 AI“解释整个仓库”，常会得到完整而笼统的架构介绍。真正要修一个小问题时，却仍然不知道入口在哪里。作者建议从一条具体数据路径开始：什么进入程序，经过哪些判断，最后在哪里产生结果。
AI生成概念配图
先选一个读代码的问题
GitHub 官方指南介绍了用 Copilot 探索项目、概括文件和解释选定代码行的方法。这些能力可以辅助阅读，但生成的说明仍应对照源码核实。本文的路径追踪法是作者的实践建议，不代表工具已完整读取仓库，也不代表自然语言解释经过运行验证。
设想一个虚构的发票导出项目，当前问题是“为什么有些发票没有出现在导出文件里”。先找命令入口、处理参数的位置和输出文件的写入点。暂时不必研究界面主题或部署脚本，除非它们真的影响这条路径。
让 AI 画出最小调用清单
假设源码显示，入口先读取日期参数，再调用查询函数，随后过滤状态，最后交给导出函数。可以请 AI 用文字列出“入口、读取、过滤、输出”四步，并为每一步指出相关文件与函数。遇到尚未打开的函数，只写待查看，不根据名字补出实现。
输入从哪里来：命令参数、配置文件，还是数据库记录。
途中改变了什么：日期解析、默认值、状态过滤与字段转换。
输出到哪里去：返回值、文件、数据库或外部服务。
提前结束的地方：校验失败、空结果、异常处理和提前返回。
这个清单并不要求展示整个项目的所有连接。目标是让你知道下一份该读哪个文件，以及读它是为了回答哪个问题。若 AI 只说“这里进行业务逻辑处理”，继续追问具体条件和结果，不必立即扩大到全项目。
拿一个具体记录走一遍
虚构案例中，记录甲的日期在范围内、状态为已确认；记录乙日期同样符合，但状态为草稿。若源码明确只保留已确认记录，乙被排除就有了可核查的解释。再看边界：截止日期当天是否包含，时区在哪里确定，空状态怎样处理。每个答案都要回到实际条件，不能用行业惯例代替代码。
也要观察函数是否改变传入的数据。某个函数名字像“整理”，却可能原地删除字段；另一个函数返回失败值，上层却继续写文件。让 AI 说明这些副作用与错误传播，比逐行翻译语法更接近你真正想理解的行为。
可直接复用的阅读模板
本轮只帮助我理解这条行为，不修改代码。请从指定入口追踪一个具体输入，到最终输出为止。列出经过的函数、关键分支、数据变化、副作用和提前返回。每个判断指出源码位置；没有读到的依赖标为未知。先给最短路径，再列出为回答当前问题必须补读的文件，不凭函数名猜实现。
把阅读结论与运行证据分开
当路径看清后，可以选择项目现有的小测试，或在隔离的测试环境中使用虚构数据核对理解。静态阅读认为会发生什么，与实际运行观察到什么，应分别记录。不要为了验证一句解释，直接运行可能发邮件、写生产数据或启动外部任务的脚本。
若解释与结果不一致，先检查实际加载的配置、调用路径和依赖版本，再回到相关分支。旧注释、函数名称和文档都可能落后于实现。最后保留一份简短阅读笔记：入口、关键条件、结果位置、仍未确认的问题。下一次进入项目，就能从具体路径继续，而不是重新读一份空泛概述。
