画一张能帮助评审改动的仓库地图

01 / 用具体问题限制范围

不要从“解释整个项目”开始。可以先问：一篇文章从保存到分类列表，需要经过哪些地方？明确这个动作，探索才有停止点。

优先阅读项目说明、入口、路由和相关存储层。目录名只能作为线索；模块职责需要由实际调用和字段使用来支持。

02 / 为每个边界留下证据

以下是通用的报告结构。路径应替换为实际检查到的文件，而不是直接把示例当成当前仓库事实。

报告模板

# 改动影响图

用户动作：
输入与约束：

入口 → 业务处理 → 存储或外部服务 → 输出

每一段记录：
- 实际文件与函数
- 输入输出字段
- 依赖的约定
- 能观察到结果的检查方式

已确认：
待验证：
超出本次范围：

03 / 追踪变更的消费者

改变一个字段时，要检查谁负责写入、谁负责读取，以及查询、缓存或序列化是否依赖旧格式。只修改最显眼的组件，常常会留下边界不一致。

对于动态加载或配置决定的关系，记录尚未验证的部分。缺少运行配置，并不等于某个服务已经不再使用。

04 / 让地图支持一个决定

最后给出必要变更、可选清理和验证路线。架构分析的价值是缩小不确定性，而不是绘制尽可能大的图。

可以用“仓库架构分析”Skill 辅助组织证据；它默认进行检查与说明，不会因为一张图就自动重构整个仓库。