第 4 课 · 从 MVP 到可扩展的 AI 代码审查产品
课程目标：
理解当前这个 AI Code Reviewer 的 MVP 边界；
学会如何通过“改 DTO + 改 Prompt + 改前端”来扩展能力；
知道如何在不推翻现有架构的前提下，换模型 / 加功能。
一、本课整体视图：我们已经拥有了什么？
经过前三节课，我们已经有了一个可以跑在本机上的“最小可用” AI 代码审查产品：
前端：
一个整合了输入区、审查结果、优化后代码的单页界面；
基本的 loading、错误提示、按钮禁用等交互细节；
后端：
清晰的 Controller / ReviewService / AIReviewService 分层；
使用 DTO 承接 AI 审查结果，使用 Prompt 约束 JSON 返回；
使用数据库记录审查历史（评分、问题列表、完成时间等）。
本节课，我们不再从头讲代码，而是站在“产品演进”的视角，看一看这个 MVP 如何升级。
二、典型扩展场景概览
几个你在真实项目中很可能会遇到的扩展需求：
增加新的审查维度 比如希望 AI 在返回结果里，单独给出“设计层面的建议”；
支持多语言审查 不止 Java，还想支持 JavaScript / Python / Go；
增强历史记录和报表 想看到“过去一周所有审查记录的平均分、问题分布”；
更换或增加模型提供方 比如在内网换成本地部署的大模型，或者做多模型对比。
本节我们挑其中两类做拆解：
“加字段”的小扩展；
“换模型”的架构层面思考。
三、场景一：增加一个 designSuggestions 字段
目标：让 AI 在返回结果里，额外给出一段“架构设计/模块拆分层面”的建议。
1. 修改 DTO：后端的数据结构
在 ReviewDto.ReviewResult 和 ReviewDto.ReviewResponse 中新增字段：
private String designSuggestions;在实体
Review中，可以选择：先不落库，只在本次响应中返回；
或者新增一个 TEXT 字段专门存这段建议，方便后续做查询和分析。
2. 修改 Prompt：告诉 AI 多返回一个字段
在 AIReviewService 的 REVIEW_PROMPT_TEMPLATE 里：
- 在 JSON 模板中新增：
"designSuggestions": "从架构设计、模块拆分、命名等更高层次给出的 1-3 条建议"在“注意事项”里强调：
这个字段必须是字符串；
内容尽量精炼、可执行。
3. 修改解析逻辑与前端展示
在
parseResponse中，从 JSON 里取出designSuggestions字段，赋值到ReviewResult；在
toResponse中传递到ReviewResponse；前端：
在右侧审查结果区域加一个卡片，标题比如叫“设计层面建议”；
直接展示
designSuggestions这段文本即可。
小结： 这一整条链路是：
改 DTO → 改 Prompt → 改解析 → 改前端，这是 AI 产品演进中最常见的一条改动路径。
四、场景二：支持多语言审查
目标：让同一个审查器支持 Java / JavaScript / Python 等多种语言。
1. 前端：增加语言选择控件
在
App.vue里增加一个下拉框或单选按钮：选项包括
Java、JavaScript、Python...；双向绑定到一个
language变量；调用
quickReview时，把language作为参数传给后端。
2. 后端：传递 language 到 Prompt
在 AIReviewService.reviewCode(code, language) 中：
- 在 Prompt 里用
%s插入语言说明，例如：
你是一位资深的 %s 代码审查专家。或者在“审查维度”部分加一条：
针对不同语言的典型坑（比如 JavaScript 的隐式类型转换、Python 的可变默认参数等）。
3. 类型与展示
DTO 层已经有
language字段，无需大改；前端可以把当前语言显示在“审查结果”卡片上，提醒用户当前是在审查什么语言。
小结： 有了清晰的 DTO + Prompt 模板，多语言本质上就是多一个
language参数 + Prompt 的一处文案调整。
五、本课技术亮点与爆点
亮点 1：用“一条演进路径”讲清 AI 产品升级方法论
我们通过“加一个 designSuggestions 字段”这个例子，串起了一条完整链路：
从需求出发：需要更高层次的设计建议；
到 DTO：新增字段承载；
到 Prompt：告诉 AI 按新字段返回；
到解析和前端展示：让用户真正看到。
爆点： 你可以把这条链路直接迁移到自己的项目里——哪怕换成别的业务字段，本质步骤是一样的。
亮点 2：架构上为“换模型”提前留好了位置
我们在第二课讲过：AIReviewService 是单独一层；
这意味着当你要从通义千问换成本地大模型时，可以：
保持
ReviewService和 DTO 基本不变；在
AIReviewService里换掉 WebClient 调用和解析逻辑即可。爆点： 对公司来说，这种架构可以显著降低“换模型”的试错成本——技术选型不用一锤定音，可以先用云模型验证，再平滑切到自研或私有化模型。
亮点 3：MVP 不等于一次性代码，而是可演进的骨架
现在这个项目已经具备了一个 AI 产品的“基本骨架”：
明确的分层；
结构化的结果承载；
可以逐步扩展的 Prompt；
能积累数据的审查历史。
你可以在此基础上陆续加：
用户体系和权限控制；
审查结果统计报表；
针对不同代码库的“项目级规则”等。
爆点： 本系列不是一个“玩具 Demo”，而是一个可以继续打磨、真正上线给团队用的起点。
六、本课课后练习
练习 1：自己加一个字段 模仿
designSuggestions的例子，给结果加一个你想要的字段，比如testSuggestions（单测建议），完整走一遍 DTO + Prompt + 解析 + 前端展示的链路。练习 2：尝试支持另一门语言（进阶） 在前端加一个
JavaScript选项，后端 Prompt 中把角色从“Java 代码审查专家”改成“JavaScript 代码审查专家”，然后找一段 JS 代码试跑一次，观察效果。练习 3：思考你的团队版本（思考题） 回到你所在的团队，想一想：
如果要在团队内部上线一个 AI 代码审查工具，你会优先支持哪些语言？
你会增加哪些字段或审查维度？
你会在哪里接入这个工具（IDE 插件、CI 流水线、还是网页）？