选一个能贯穿系统的具体问题
代码库概览很容易生成，却不一定有用。它可能列出了每个目录，但没有解释真实行为发生在哪里。不妨先选一项功能：假设这是一个虚构的团队应用，问题是“成员邀请是怎样变成正式成员关系的？”
交付物是一份修改前可以核对的简短流程图谱。这是一种调查方法，不是“所有项目几分钟就能理解”的承诺。大型单仓库、生成代码、缺失服务和未记录的集成，都可能留下空白。
探索之前，先划清边界
打开正确的项目目录，说明这次只检查当前检出的代码，不改文件、不装依赖、不启动服务、不访问外部系统。后续可能需要这些操作，但应另行决定。保留未提交的工作，记录调查对应的分支或提交。
仓库可能包含客户资料或密钥。输出应限于相关路径、符号和脱敏示例，不要要求完整打印环境文件或私有配置。除文字说明外，还需要合适的账号和工具权限。
追踪当前代码中的成员邀请流程。
先读项目约定，再读相关源码与测试。
不要编辑文件、安装依赖、运行迁移或启动服务。
找出界面入口、请求处理、权限校验、数据写入，
以及邮件或后台任务等副作用。
每项结论附上支持它的文件路径和符号名。
区分已验证事实、合理推测和待确认问题。
最后列出我最应该先读的三个文件。沿着行为跨过每一层边界
先找到发起邀请的路由或组件，顺着请求进入服务端处理逻辑，再查看数据写入前的权限与输入校验。确认处理函数是直接完成工作，还是交给队列中的后台任务。
再读对应测试。函数名叫 validateInvite，不代表调用方真的调用了它；单元测试通过，也不代表浏览器能访问这条路由。需要追踪调用位置，明确指出缺失的连接。
- 界面：用户从哪里发起操作，发送了什么请求。
- 权限：如何检查组织成员身份和邀请权限。
- 状态：邀请存在哪里，重复或过期令牌怎样处理。
- 副作用：谁发送邮件、安排后台任务或记录审计事件。
- 测试：已有用例覆盖什么，还缺哪些重要情况。
让交接材料对下一个工程师有用
有效结果应指出需要阅读的文件，解释执行顺序，并把不确定性写在对应结论旁边。源码推导与实际运行观察必须分开。如果邮件服务不可用，就明确说未验证，而不是默认邮件会送达。
可以要求补一段修改影响分析：如果改变邀请过期时间，哪些校验、清理任务、界面文案和测试可能受影响？这样，调查结果才能成为小范围修改的起点，而不是一次大重构的借口。
下一步达成一致后，再运行验证
本地预览和测试账号准备好后，第二个任务可以观察浏览器请求，再与源码图谱对照。明确授权这次运行工作，并保留最初的调查结果，让新证据修正或支持之前的判断。
只有需要持久化时，才把确认后的图谱写进团队文档，记录代码版本和检查日期。路由与权限变化后，它可能过时。最终标准很简单：另一个工程师能否根据引用的证据，独立核对同一份解释？