临近毕业周围同学要么在啃论文要么在拼手速赶系统。我选了条不太一样的路把“AI编程实战”直接当成毕业设计的主题用三个月时间靠 AI 编程工具和一个前后端分离项目把整个开发流程跑完——从需求梳理、数据库设计、接口开发到前端页面、部署上线。这篇文章就是那份迟到的毕业总结。如果你是正准备用 AI 编程做课程设计、毕业设计或个人项目的学生或者已经在用 Claude、Cursor 这类工具但总觉得生成的代码不好用、一改就崩那这篇总结应该能帮你少走不少弯路。我不聊宏大的理论只讲我实际怎么做的、踩了哪些坑、以及哪些经验是真的值得复制的。1. 项目整体设计与思路拆解1.1 为什么选“AI编程实战”作为毕业设计方向学校给的毕业设计方向比较灵活可以选理论研究也可以做工程实践。我本身是计算机相关专业代码基础说不上扎实属于那种能写但写不快、框架用过不少但源码没啃过几行的水平。如果做传统课题大概率是三个月憋一个普通管理系统答辩时被老师问几句设计模式就露怯。选“AI编程实战”这个方向一开始确实有投机心理既然 Claude、Cursor 这些 AI 编程工具已经能生成完整项目那我是不是可以借力做出一个功能更完整、工程化程度更高的系统但真正做完之后我改变了看法——这不是偷懒而是换了一种开发方式。传统的开发流程是“需求 - 编码 - 测试 - 重构”人的精力大部分耗在写重复代码上。AI 编程的流程变成了“需求 - 提示词设计 - 代码生成 - 人工评审 - 修正”我更多的时间花在了想清楚要什么、怎么描述、以及如何验证 AI 给的方案是否靠谱上。这其实是更接近真实工程现场的思维模式。我最终确定做一个“实验室设备预约管理系统”。选这个题有三个考虑第一业务场景真实包含设备管理、预约、审核、统计等模块逻辑复杂度足够撑起一个完整的毕设第二技术上采用前后端分离架构前端用 React 19后端用 Spring Boot 3这套组合在热门技术栈里比较有代表性第三预约系统天然有时段冲突校验、审批状态流转这些业务规则方便展示 AI 在“有约束的业务代码”上的生成能力而不是只会 CRUD。1.2 工具选型AI编程软件到底哪个最顺手这一块是很多同学问得最多的。网上关于“AI编程最厉害三个软件”的讨论有很多但我的体验是没有最强的工具只有最适合当前任务的使用方式。我实际用了三款Claude 负责核心业务逻辑生成Cursor 负责多文件项目级改造VS Code 上的通义灵码插件负责日常补全和简单重构。简单做了个对比工具擅长场景我的使用频率不足Claude理解复杂业务描述、生成完整模块代码、解释报错极高免费额度有限长对话后容易“忘事”Cursor多文件重构、跨文件跳转、Agent自动修改高初次配置稍麻烦对旧项目索引速度慢GitHub Copilot行级补全、写重复性代码中面对复杂需求容易“答非所问”通义灵码中文注释生成、简单CRUD低大任务能力明显弱于前两者我不会告诉你“必须选哪个”但有一个真实经验不要同时开好几个 AI 对话窗口处理同一个模块。我一开始试过在 Claude 里生成代码、在 Cursor 里让它改样式、再用 Copilot 补几个方法结果三个工具各自对代码上下文的理解不一样改出来的版本互相冲突最后乱到只能回滚。后来我固定为“每个功能模块只由一个 AI 工具负责到底”前后的上下文连贯性才变好。2. 核心细节解析与实操要点2.1 需求梳理与数据模型设计先让AI理解业务很多人让 AI 写代码上来就是一句“帮我写一个设备预约系统”生成出来的东西基本没法用。问题不出在 AI而出在需求本身太模糊。我的做法是先把需求写成文档越细越好。比如设备预约模块我列了这些约束用户登录后可以查看设备列表按设备名称、位置、状态筛选预约时须选择使用日期和时间段同一设备同一时间段不能被重复预约预约提交后状态为“待审核”管理员审核通过后才能使用用户可以取消自己的预约取消后时间段自动释放。这些规则看起来简单但直接决定了数据库表怎么设计、接口怎么校验。我把这份需求文档丢给 Claude让它先输出数据库设计而不是直接写代码。它给出的表结构里有一个预约表 reservation关键字段如下CREATE TABLE reservation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 预约用户ID, equipment_id BIGINT NOT NULL COMMENT 设备ID, reserve_date DATE NOT NULL COMMENT 使用日期, start_time TIME NOT NULL COMMENT 开始时间, end_time TIME NOT NULL COMMENT 结束时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审核 1已通过 2已拒绝 3已取消, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_equipment_slot (equipment_id, reserve_date, start_time) );这里有个关键设计唯一索引 uk_equipment_slot直接在数据库层面挡住了“同一设备同一时间段重复预约”的问题比在代码里用 if 判断要可靠得多。这个点是 AI 给出来的但它的价值需要你懂数据库才能判断。如果我不理解唯一索引的作用很可能觉得它多余然后删掉后面就会在并发场景下出 bug。所以我一直跟同学强调AI 编程不是说你就不需要懂技术了而是你需要有“判断 AI 产出是否合理”的能力。数据模型定了之后后面所有接口、页面都跟着这张表走这一层如果歪了后面全是返工。2.2 从零生成后端接口把大任务拆成小任务数据库设计完成之后开始生成后端代码。后端我用的是 Spring Boot 3 MyBatis-Plus MySQL这套组合的好处是约定大于配置AI 训练语料里相关内容特别多生成代码的质量会更高。我拆模块的方式是按业务域拆认证模块、设备模块、预约模块、审核模块。每个模块单独开一次对话单独生成而不是一次性让 AI 生成全部代码。原因很简单大任务一次性生成AI 容易丢失前面已经输出的内容而且出错了很难定位是哪个部分的问题。以预约模块为例我当时的提示词大致是这样的你是资深Java后端工程师。请基于spring boot 3 mybatis-plus 技术栈 为“实验室设备预约系统”生成预约模块的service和controller代码。 业务规则 1. 用户提交预约时校验设备是否存在、状态是否为可预约 2. 同一设备同一时间段已有其他有效预约时拒绝并提示冲突 3. 状态流转为待审核 - 已通过/已拒绝/已取消 4. 只有管理员可以调用审核接口用PreAuthorize控制权限。 要求 - 使用ResultT统一返回结构 - 参数校验用jakarta validation注解 - 关键业务逻辑处写中文注释 - 最终返回完整的、可直接编译的代码。把任务拆到这种颗粒度AI 生成出来的代码基本不用大改就能编译通过。这里还有一个经验要求生成“可直接编译的完整代码”比“给我一个思路”效果要好很多。AI 在生成代码时如果你只给思路它就会输出一堆伪代码或者缺头少尾的片段当你明确要求可编译、可运行它会自己补齐依赖和细节。在接口代码生成完之后我还会让 AI 顺手生成 Controller 层的单元测试。这一步很多同学会忽略但对于毕设来说非常有价值——一是能证明你的代码逻辑正确二是答辩时老师问“你怎么保证代码质量”你可以直接拿测试覆盖率说话。3. 实操过程与核心环节实现3.1 提示词决定 AI 编程上限的关键技能如果说 AI 编程有一个最核心的技能那一定是写提示词。同样一个工具不同人用出来的效果天差地别差距就在提示词上。我总结了一套适合项目开发的提示词模板角色你是[技术领域]资深工程师熟悉[技术栈]。 任务请完成[功能模块]的开发要求[核心功能点1]、[核心功能点2]。 约束使用[框架/规范]需要处理[边界情况]不允许使用[不想要的东西]。 输入现有代码中[相关文件]的内容如下... 期望输出[代码/方案/解释]并给出关键设计说明。这个模板的核心逻辑是给 AI 一个清晰的上下文边界。很多人让 AI 写代码只给一句“写个预约接口”AI 不知道你的项目里是否已有统一返回结构不知道你用什么权限框架不知道你数据库里字段叫什么它只能凭自己的“想象”写一个通用版本然后你再改一遍还不如自己写。我举个反例。一开始我让 AI “写一个取消预约的接口”它返回的是一个普通方法直接把预约记录删除了。但业务上取消预约应该是“把状态改为已取消”同时要校验只能取消自己创建的预约、审核通过的预约不能取消之类。因为我的提示词没说清楚约束AI 就按最简单的方式生成了。后来我把这些规则写进提示词它生成的代码才符合预期。“提示词 低配版产品需求文档”这个类比我觉得很准确。AI 编程不是魔法它是在理解你的需求之后帮你写代码需求表达得越清楚代码质量越高。3.2 Agent 与 Skill让AI自动干活的进阶玩法项目做到中期我开始尝试 Cursor 里的 Agent 模式体验完全不一样。普通模式是你让 AI 写一个文件Agent 模式是它会自己读取项目文件、找到相关代码、修改多个地方、运行命令然后告诉你改了什么。我最常用的是“报错修复”场景。联调阶段经常会遇到控制台抛异常的情况以前是复制报错信息去搜索引擎现在是直接把报错信息丢给 Agent项目运行报错请看下面的异常栈 [在这里粘贴完整日志] 请分析原因检查项目里相关的代码文件给出修复方案并直接修改代码。Agent 会自己去翻代码、定位问题、改完后还会跑一遍测试确认。整个过程比我自己查日志定位快很多尤其是那种“报错在 A 文件实际原因在 B 文件”的跨文件问题。除了 Agent我自己整理了几个常用的 Skill相当于给 AI 装“专业技能包”代码审查 Skill输入一个文件路径AI 会按“安全性、性能、可读性、规范一致性”四个维度输出问题清单接口文档 Skill输入 Controller 类AI 自动生成 OpenAPI 格式的接口文档SQL 迁移脚本 Skill输入实体类变更说明AI 自动生成增量 SQL避免我手写 ALTER TABLE 出错。这些 Skill 本质上就是把重复性的工作流程告诉 AI让它以后再遇到同类任务时自动按高标准执行。用过一段时间之后我的感受是AI 编程的下一个效率增长点不在工具本身而在于你怎么把工作流程沉淀成可复用的 Skill。3.3 前端落地的实践记录前端我用的是 React 19 Vite Ant Design。说实话我对前端不算熟这部分是 AI 帮我最多的地方。我的操作方式是先把后端接口定义好然后让 AI 根据接口文档生成前端调用代码。具体来说我会把 Controller 里的接口签名、请求参数、返回结构复制给 AI然后在提示词里要求根据以下接口定义生成前端 API 调用函数和对应页面组件 接口1POST /api/reservation 参数equipmentId, reserveDate, startTime, endTime 返回{ code: 0, message: success, data: { id: ... } } 要求使用 axios 封装请求处理好 loading 和错误提示页面使用 Ant Design 组件。这样生成的前端代码几乎不用改就能跑起来。但这里我踩了一个坑AI 生成的 React 组件有时候会用到我项目里并不存在的 UI 库版本比如 Ant Design 4 的 API 跑在 5 的环境上导致页面白屏。后来我在提示词里显式写明“项目中使用的是 antd 5.x注意 Modal 的用法是 modal.open 而不是 visible 属性”这类问题基本消失。前端联调阶段还有一个很实用的技巧让 AI 帮我生成 Mock 数据。后端还没写完的接口先用 AI 生成的 Mock 数据让前端跑起来两边并行推进速度拉满。4. 常见问题与排查技巧实录4.1 三个让项目差点崩掉的坑做完这个项目我攒了一批 AI 编程实战中的典型问题挑三个最常见的分享出来。第一个是跨域请求被拦截。前端跑在 5173 端口后端跑在 8080 端口直接请求就会触发 CORS 跨域问题。AI 生成的解决方案是在 Controller 上加 CrossOrigin 注解这确实能解决但只解决了一个接口。后来我让 AI 改成全局配置类实现 WebMvcConfigurer一次性解决所有接口的跨域问题。这个坑属于“AI 能给出方案但方案是不是最优需要你判断”的典型案例。第二个是日期时间字段差 8 小时。预约系统大量使用时间字段前端传一个“2025-06-20 10:00:00”存到数据库就变成了“2025-06-20 02:00:00”。原因很简单JackSon 反序列化时间时没有指定时区默认用了 UTC而数据库用的是本地时区。解决方法是在 application.yml 里配置spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss第三个算是 AI 编程的“特色坑”AI 生成的代码经常有重复实现。比如它可能在工具类里已经写了一个 DateUtils又在某个 Service 里重新写了一遍时间格式化逻辑。代码能跑但维护的时候很痛苦。这种问题没有银弹只能靠人工 review 时留意。4.2 常见问题速查表问题现象可能原因解决方法前端请求跨域报错后端没有配置 CORS新增全局 CORS 配置类不要用 CrossOrigin 一个个加时间字段差8小时Jackson 默认使用 UTC 时区在配置文件中指定 time-zone 和 date-formatAI生成的组件打开白屏UI库版本不匹配在提示词中写明依赖版本检查 package.json修改一个模块后其他模块报错AI 对项目上下文理解有限使用 git 版本管理改动前先提交出错快速回滚AI 生成的代码有重复实现未声明“检查已有工具类”提示词中加入“先检查 util 包中是否已有类似方法”4.3 联调阶段的人工把关我不是全盘信任 AI 生成的代码尤其是在安全相关的地方。比如权限控制AI 可能只加了 PreAuthorize 注解但方法内部没有判断当前用户是否拥有操作权限。这类逻辑漏洞在单元测试里看不出来只有多用户并发操作时才会暴露。我的把关方式是让 AI 生成代码之后再开一个新的对话把同一个文件丢给它做一次“对抗性审查”请找出这段代码中可能存在的权限绕过、参数校验缺失、事务边界问题。这个过程相当于用 AI 去查 AI效果还不错。当然最终负责人还是我自己。答辩的时候老师问“这个功能怎么实现的、有什么问题”你不能说“这是 AI 写的我不知道”。所以我要求自己做到每个核心模块的代码都能讲清楚逻辑每个关键方法都理解它在做什么。这也算是我坚持在每个模块生成后手动通读一遍的原因。5. 毕业总结三个月AI编程实战我收获了什么5.1 重新认识AI编程的能力边界先说 AI 擅长的。它最擅长的是把明确的需求翻译成代码尤其是在后端 CRUD、接口开发、脚本编写这些“模式化”很强的场景AI 几乎是碾压级的效率其次是报错排查给它一段异常栈它能很快定位问题所在并给出修复方案再次是代码解释和测试用例生成对理解别人代码和验证自己代码非常有帮助。但 AI 不擅长的也很明显模糊的业务需求、跨系统的架构权衡、以及对非技术约束的理解。比如“把预约流程设计得更合理一些”这种话AI 给不了有价值的建议因为它不知道你们的实验室实际运作规则、设备维护安排、管理员的审批习惯。所以我的结论是AI 是一个很强的执行者但不是好的产品经理和架构师后两者需要人来当。三个月前我以为 AI 编程会让我变成“甩手掌柜”实际做下来发现完全不是。它确实把我从大量重复编码中解放了出来但也把我推到了一个更高的位置上——我必须更懂业务、更懂设计、更懂如何判断代码质量的优劣。这是一种新的能力要求我觉得可以叫它“AI 协作开发能力”。5.2 给准备用AI编程做项目的同学几点建议如果让我给后来人提建议我会强调这几条第一先学基础再用 AI。零基础直接让 AI 生成整个项目你连报错都看不懂更别提让 AI 修了。我虽然没有成为大牛但至少 Java 语法、SQL、HTTP 这些基础是扎实的这让我能判断 AI 给的代码是否合理。第二花时间把需求文档写好。这是性价比最高的一步。我以前写代码总想快点动手现在反而愿意花更多时间在 ChatGPT 里把需求描述清楚因为提示词写得越细AI 生成的代码需要返工的次数越少。我做过对比一条 50 字的简单指令和一条 300 字带约束的详细指令生成的代码可复用率差距在一倍以上。第三用 Git 管好版本。AI 改代码有时候会改出你没预料到的问题如果没有版本备份改坏了就只能手动一点点找回来。我给自己定的规矩是每次让 AI 做较大改动之前先 git commit 一次改完验证通过再提交一次。这样最多丢一个版本的改动不会伤筋动骨。第四每周安排时间做 review。AI 生成的代码不会自动符合你的编码规范你需要定期重复之前提到的“代码审查 Skill”把项目质量拉回来。毕业设计最后还是要答辩的老师不会因为你用了 AI 就降低要求代码质量最终要过得了自己这关。最后再分享一个小技巧项目收尾阶段可以让 AI 帮你生成部署文档、启动脚本、环境配置说明。我当时让 AI 根据项目的技术栈和依赖输出了一份从零搭建环境的详细文档答辩演示前照着操作一遍省了不少时间。这套“把 AI 当成团队里的全能助理”的思路是我在这次实战中收获的最大经验。