我用 AI 做了一个完整的 Java 求职训练平台，从想法到落地竟然没手写代码！

最近我完整做了一个 AI 项目项目名叫AI Interview Coach。这是一个面向 Java 求职场景的训练平台核心目标不是做一个简单的聊天问答 Demo而是把 “画像、题单、训练、点评、报告、沉淀” 串成一条完整链路让用户可以按照更贴近真实求职训练的方式去使用。项目已经开源开源地址https://gitee.com/xiaohan666777/aicodeing?sourceheader_my_projects这个项目的技术栈如下后端Spring Boot 3、Spring Security、JWT、Spring AI Alibaba、MySQL、Redis、RabbitMQ、Quartz、Swagger前端Vue 3、Vite联调与验证Playwright、浏览器自动化、截图回归很多人一提到 AI Coding第一反应往往是“无非就是让 AI 帮忙写几个页面、补几个接口而已。”但这次我完整做完一个项目之后最大的感受反而是AI 最厉害的地方不只是帮你省掉敲代码的时间而是当你的业务流程足够清晰时它真的可以帮你把一个完整系统快速搭起来。这篇文章我不想写成 “我接了个模型接口然后做了个页面” 的流水账。我更想复盘的是一个 AI Coding 项目怎么从 “AI 能生成代码”走到 “系统真的能跑、能用、能扩展”。一、项目简介我做的不是聊天 Demo而是一条完整训练链路这次我做的项目叫AI Interview Coach定位不是一个简单的聊天问答工具而是一套面向Java 求职训练场景的平台。它不是 “问一题答一题” 的普通对话产品而是一条完整训练链路画像设置 - 题单配置 - 一次性生成整套题 - 集中作答 - 统一点评 - 按需生成深度报告 - 错题/趋势/计划沉淀这条链路的目标很明确先理解用户是谁、准备什么方向再生成更贴近用户背景的训练内容让用户专注完成整场训练最后集中复盘和沉淀结果二、为什么我没有把它做成 “AI 聊天页面”在做这个项目之前我看过不少 “AI 面试” 类产品。很多产品看起来很聪明但真正用起来总会暴露出一些很典型的问题。比如一上来就开始提问完全不关心用户准备投什么岗位不关心项目经历和技术方向题目过于泛每答一题都要等 AI 再生成下一题体验很卡答题、点评、总结全堆在一个页面里注意力被不断打断一场训练结束后没有结果沉淀下一次训练又像重新开始这些问题表面看像是模型能力不够但后面我越来越觉得真正的问题往往不是模型而是业务流程没有设计清楚。所以我在做这个平台时先定下了一个原则不要让 AI 到处冒出来要让 AI 只出现在真正需要它的地方。这也是为什么我最后做出来的不是一个 “功能很多” 的系统而是一条比较清晰的训练主线。用户进入系统后不是面对一堆功能菜单而是顺着一个完整流程往下走先明确背景和目标再开始训练再统一复盘最后才进入更深入的分析和沉淀。从产品体验上看这一点其实比 “多接一个模型能力” 更重要。三、训练开始前我先做了 “画像设置”这个设计我后面越来越确定而且几乎没有再动过。因为如果系统不知道用户要准备什么岗位、技术方向偏什么、做过什么项目、哪里强、哪里弱那后面生成出来的题目和建议大概率都会变得很空。这种 “没有上下文的智能”看起来像个 AI实际上很难真正服务训练场景。所以在正式开始训练前我先设计了一个画像设置环节。它的作用不是让用户去填一大堆表单而是把真正会影响训练效果的信息提前整理好比如用户背景概况项目经历岗位目标技术方向目标公司类型重点想补的知识内容这样做之后后面的题目生成就不再是 “随机出几道 Java 面试题”而是会更贴近用户自己的求职方向。比如同样是 Java 岗位有人偏后端基础有人更强调项目表达有人更在意Redis、MySQL、JVM有人更希望训练 “项目深挖” 和 “场景题”系统只有先理解这些差异后面的训练才会更像 “针对你” 的训练而不是泛泛而谈的通用问答。所以在这个平台里画像并不是一个附属页面而是整个训练链路的输入起点。它的价值不在于 “信息填得多”而在于让后面的 AI 结果真正建立在上下文之上。四、我没有采用 “答一题生成一题” 的模式一开始我其实也试过更常见的交互方式用户答完一题AI 再继续出下一题同时顺手做点评。这种模式看起来很自然也很像聊天但实际跑起来之后我很快发现它有两个明显问题。1. 慢因为每完成一题系统都要重新调用模型生成反馈、组织内容、再返回下一题。只要链路稍微一长页面就会有明显等待感。2. 打断感很强用户明明正在组织自己的回答结果每答完一题就被系统打断一次。这种体验其实不太像真实面试反而更像 “做一半停一半” 的碎片化对话。后来我把流程彻底改掉了训练开始前一次性生成整套题训练结束后再统一生成整场点评这个改动看起来只是产品交互调整但实际影响非常大。一方面答题阶段变得更流畅了。用户不需要反复等待 AI也不会在训练过程中不断被打断。另一方面后端链路也变简单了不再需要把每一道题都做成一条同步阻塞流程。这次调整也让我很清楚地意识到一件事很多看起来像性能问题的问题本质上其实不是性能问题而是流程设计出了问题。当流程本身不合理的时候你再怎么做 loading、再怎么优化提示文案提升都很有限。反过来当主流程顺了很多原本让人头疼的问题会自然消失。五、答题、点评、报告为什么一定要拆开这个点我一开始也走过弯路。最早我以为如果能一边答题一边看到点评系统会显得更智能。但实际用下来之后我发现这并不是一个真正提升体验的设计。因为用户在答题的时候需要的是一种比较专注的状态。这个时候他更关心的是怎么表达怎么组织语言怎么把自己的项目和知识点说清楚而用户在看点评的时候心态已经变成了复盘和分析他需要的是从结果里找问题看差距想下一步怎么改这两种状态并不适合混在一起。所以我最后把整个流程拆成了三个阶段第一阶段只负责答题第二阶段统一承接整场点评第三阶段再进入更深入的报告分析这样拆开之后整个系统的节奏一下就变清楚了。用户在答题时只管输出系统不要打断他用户在复盘时只管分析信息也可以集中呈现更重的深度报告则放到后一步按需触发这其实不是简单的页面拆分而是把 “训练” 和 “分析” 彻底区分成了两个动作。一旦这样处理整条链路的逻辑就顺很多后面的错题沉淀、成长分析和训练计划也都有了自然的承接位置。六、深度报告为什么不适合默认自动生成现在很多 AI 产品都喜欢在用户完成一个动作之后立刻生成一大段长报告看起来很高级。但这种设计放到真实训练场景里未必合理。因为不是每一场训练都值得做深度分析。有时候用户只是想快速练一轮基础题看看自己的表达状态有时候他可能只是想刷几道题找感觉。这种情况下如果系统每次都强行生成一份很重的深度报告反而会拖慢主流程也会增加很多不必要的等待。所以我在这里做了一个很明确的取舍深度报告不默认生成而是由用户在看完集中点评之后按需触发。这样设计之后好处很明显。一方面主流程更轻了。用户完成一场训练之后可以很快先拿到整体反馈。另一方面真正需要深入分析的时候再去触发深度报告这时候无论是心理预期还是使用场景都会更匹配。而且从系统实现上讲深度报告本身就不只是 “再让模型多写一段总结”。它往往还会结合当前训练结果、知识点表现、错题情况和后续推荐方向去做更深的加工。所以这一步天然更适合做成异步流程而不是强塞进主请求里。七、后端架构上我更关心 “训练链路” 而不是 “三层模板”如果只用一句话来概括这个项目的后端我会说它是一个单体应用但真正核心不是 Controller、Service、Repository 这种教科书式分层而是围绕训练主链路做业务编排。比如用户创建一场训练时后端做的并不只是保存一条记录。它会先把当前场景下的训练上下文固化下来包括岗位方向简历摘要项目亮点训练目标题单类型题量focusAreas然后结合这些信息做一轮轻量检索增强接着再调用 AI 生成整套题单最后把题目和会话状态一起落到数据库里。同样用户完成训练之后系统也不是简单地 “拿答案喂给模型然后返回一段话”。它会先校验作答是否完整把整套问答整理成稳定结构再进行统一点评最后把单题反馈、综合评分、基础报告等结果拆回业务系统里我后来越来越觉得AI 应用开发和普通 CRUD 项目最大的区别之一就在这里真正重要的不是 “调了哪个模型接口”而是你怎么把输入上下文整理干净再把模型输出结构化地接回系统里。这一步如果做得乱后面再多能力都会很难维护。而一旦上下文、职责边界和状态流转整理清楚整个系统会稳定很多。八、技术选型上我更关心 “它到底解决了什么问题”这次项目虽然技术栈不算少但我一直在提醒自己一件事每一个技术都要回答它在这里到底解决了什么问题。Spring Boot 3它让我可以比较自然地把鉴权、AI 接入、数据库、调度和消息能力整合在一起。对于当前这个体量的项目来说单体应用已经足够而且可维护性会比过早拆微服务更好。Spring Security JWT解决的是登录态和用户上下文绑定的问题。因为这个系统不是匿名体验页而是一个有画像、有训练历史、有个人结果沉淀的平台所以身份体系是基础。MySQL承担的是核心结构化数据存储。训练会话、题目、回答、报告、计划这些数据本质上都很适合关系型数据库来管理。Redis在当前阶段没有被我用得特别重主要承担一些轻量缓存职责比如知识检索结果缓存和高频读场景加速。我不太希望为了 “技术栈丰富” 而强行堆中间件。RabbitMQ承担了更真实的异步任务职责尤其是在深度报告这种更重的后处理流程里它不是摆设而是真正在把重任务从主链路中剥离出来。Quartz作用相对没那么显眼但我还是把它保留了下来。因为训练提醒、复盘任务生成、计划推进这些能力天然需要时间驱动的执行方式。它虽然不是当前最亮眼的部分但对于后续演进是有意义的。Spring AI Alibaba DashScope这是整个项目中最核心的 AI 接入层。整套题单生成、整场点评和报告输出都是围绕这部分能力展开的。Swagger它的价值不只是 “方便调接口”更重要的是把系统边界清楚地展示出来。页面一多、接口一多如果没有统一文档系统会很快失控。九、这次 AI Coding 最有价值的地方不是 “帮我写代码”而是改变了开发方式回头看这次开发过程我觉得最有价值的地方不是 “AI 帮我省了多少打字时间”而是它改变了我推进项目的方式。以前做项目很多想法停留在脑子里是因为从想法变成代码实现成本很高。但现在有了 AI 之后第一版系统可以非常快地被铺出来。页面、接口、文档、联调代码很多东西都能迅速成型。可真正决定项目质量的从来不是 “第一版出来得有多快”而是后面你怎么继续收敛。这个项目里AI 帮我做得最多的事情包括快速搭前后端初版批量修改页面结构调整接口契约重构部分流程补文档和联调验证但真正让系统从 “能跑” 变成 “好用” 的依然是人工做的那些判断哪些流程要保留哪些流程应该删掉哪些页面职责必须拆开哪些字段有价值哪些只是看起来很完整哪些兼容逻辑应该停止修补直接重写所以我现在越来越认可一句话AI 负责高速实现人负责定义问题、控制边界、做取舍、验结果。真正的能力不在于让 AI 写出多少代码而在于你能不能把 AI 写出来的系统收敛成一个逻辑成立、体验顺滑的产品。十、做完这个项目后我总结了几条很实用的经验1. 想减少模型幻觉最有效的办法不是不断提醒它 “不要乱编”而是把上下文尽量结构化。当你给它的是清晰场景、明确目标和有限输出范围时结果通常会稳定很多。2. 给 AI 下任务时少说 “做个功能”多说 “现在用户在哪个状态接下来应该发生什么什么不能发生”很多时候模型不是不会写而是在猜你真正想要的业务。3. 不要太迷信第一版代码AI 特别擅长快速把东西推到一个 “看起来差不多” 的状态但从 “差不多” 到 “真的能用”中间通常还隔着不少重构和取舍。4. 尽量让 AI 产出可验证的结果比如明确 DTO、接口、状态枚举、页面流程而不是只输出一大段看起来很懂的设计说明。因为只有可验证才容易真正落地。5. 要敢删 AI 写出来的代码这件事非常重要。AI 写得快所以更容易堆出很多 “先留着吧” 的冗余逻辑。可一旦这些逻辑开始影响后续维护最好的方式往往不是继续补而是直接删掉重来。十一、总结做完这个项目之后我越来越确定一件事AI Coding 真正厉害的地方不是帮你省掉了多少敲键盘的时间而是它把 “做一个完整系统” 这件事的门槛拉低了。但与此同时它对开发者的要求其实更高了。因为现在最容易得到的已经不是代码而是一堆代码。真正稀缺的是把这些代码收敛成一条合理链路的能力。这个项目对我来说最大的价值也正在这里。它让我验证了一件事AI 确实可以支撑一个完整系统的快速开发但只有当业务逻辑足够清晰、架构边界足够明确时AI 才会真正成为放大器而不是混乱的加速器。所以如果你也在做 AI 项目我现在更想建议你少问一句“这个模型还能不能更强一点”多问一句“这个系统的流程到底顺不顺”很多时候后一个问题才是真正决定项目质量的关键。