前言
在上一篇文章中，我们已经借助提示词生成了架构图、模块图和依赖图三个视图，对项目有了一个整体性的认知。
在实际的迭代开发中，多数场景是围绕某个接口进行改造，或者为某张表增加新字段。这就要求我们必须清楚接口与数据模型之间的关系——接口是门面，直接暴露业务能力；数据模型则是根基，决定了数据如何存储和流转。把这两层之间的关联理清，后续的修改才会稳妥、高效。
[图片上传失败...(image-f5b8e0-1780454852197)]
一、生成实体类关系图
想让 AI 准确画出实体类之间的关系，需要注意下面三个关键点：
- 三源对照：Entity、DTO 与建表 SQL 一起看
实际项目中的数据模型常常分布在三个层面：Java 层的 Entity、传输层的 DTO，以及数据库层的建表 SQL。它们不完全一致是常态，例如 Entity 中的某些内部字段不会暴露在 DTO 里，而 DTO 又可能组合了多个 Entity 的字段。因此，要引导 AI 把这三类定义放在一起对照：以数据库模型为准，Entity 和 DTO 作为参照，这样才能把实体间的真实映射关系梳理清楚。 - 标注“主键、外键、枚举值”三类硬信息
主键、外键和枚举值是数据模型中最硬的约束。主键告诉你如何唯一定位一条记录，外键决定了表与表之间的关联路径，枚举则限定了某些字段的取值范围（例如 Prompt 的状态、Experiment 的运行状态）。在做功能改造时，这三处是最容易踩坑的地方：一旦忽略某个外键关联，可能导致数据不一致；枚举值的增删如果没有同步更新，逻辑就会出错。让 AI 明确标出这些信息，等于为后续修改装上了“防错护栏”。 - 同时输出 Markdown 说明与 ER 图
让 AI 不仅生成一张 ER 图，还要产出一份配套的 Markdown 文字说明。Markdown 表格适合精确定位某个表有哪些字段、类型和含义，查找起来一目了然；ER 图则适合从整体上把握多个表之间的关联方式，通过连线快速看出“一对多”“多对多”关系。两者结合，既能微观查询，又能宏观理解。
er 图.png
二、生成 REST 接口清单
生成接口清单时，同样有几个要点可以帮你拿到一份结构清晰、实用性强的结果：
- 按模块分组，提升可读性
一个项目少则十几、多则上百个接口，零散的列表难以快速定位。让 AI 按照模块（例如用户模块、订单模块、实验模块等）对接口进行分组，同一业务域的接口聚合在一起，可读性会显著增强，不同职责的开发者也能各取所需。 - 列明返回类型和主要入参，详情留给实体关系图
在接口清单中，只需列出每个接口的返回类型和核心入参即可，不必展示每个字段的详细定义。这样清单保持简洁，便于快速扫描；至于字段级别的完整细节，完全可以放到实体类关系图中承载，避免信息重复和臃肿。 - 注意 AI 可能遗漏模块，需要 Review
AI 在生成时有时会因为数据提取不完整而漏掉个别模块。因此在得到清单后，一定要对照项目实际结构进行一次 Review，补齐缺失的部分，确保覆盖所有接口。 - 区分对外接口与内部接口
接口的调用场景不同，设计要求和鉴权方式往往也不同。可以要求 AI 标明每个接口是对外（例如供前端或 SDK 调用），还是对内的服务间调用。这样在生成文档或者做权限治理时，就能更有针对性地处理。
接口列表.png
