1. 为什么我把课设从“做完交差”变成了“一套可复用提示词”先说点实在的。很多人的课程设计是这么做的拿到题目上网搜一圈找个差不多的源码改改数据库结构照搬页面换换颜色写完报告交上去任务完成。这套流程我大一的时候也走过说实话能学到的东西非常有限而且做得特别心虚——答辩的时候老师随便问一个“你为什么这样设计表结构”就卡壳了。做“蓝动记”这个项目的时候我逼自己换了种思路。当时手头的事情比较多除了这门课的课设还在帮导师做个小系统同时准备着实习面试。时间紧张代码要是从零手写一个月都未必能写完可要是纯抄又过不了自己心里那关。后来琢磨出一个办法把自己的需求想清楚拆细写成一整套条理化的开发提示词再基于这套提示词去生成前后端代码、数据库脚本和接口文档。我只需要做审核、修改、适配这三件事效率一下子提了好几倍。结果是这套进销存系统我只用了两个星期就完成了主体功能连课设报告里的架构图、流程图、表结构说明都是顺着提示词的输出整理出来的。更关键的是我手里攒下了一个通用性很强的提示词模板之后接其他项目改改业务描述、调调字段定义就能直接复用。说白了这事的价值不在于“用AI写出了课设”而在于把“你心里清楚要做什么”这个模糊状态转化成“机器也能理解并执行的精准需求描述”。这种能力工作中比敲几千行代码值钱得多。这篇文章就把完整思路、提示词模板、踩过的坑和实际效果全部展开从项目拆解到技术选型再到复用方法一次性说清楚。2. MVP版的进销存到底该切哪些功能进来进销存在UML图里能画出一大堆采购管理、销售管理、库存管理、应收应付、报表统计、权限管理、多仓库、批次序列号、生产组装……真全做出来那不是课设是ERP。MVP的原则是把核心业务跑通砍掉一切“没有也能活”的部分。“蓝动记”这个名字很简单定位就是一个中小型贸易商行的进销存工具所以第一期MVP我划定了几条硬边界只做单仓库不做多仓调拨和多级库存商品不做批次和序列号管理只按SKU计库存数量不做复杂财务模块应收应付先砍掉只记录进价和售价不做审批流入库单审核直接用“确认入库”这个动作实现权限只区分管理员和普通操作员不再细化到按钮级别这样切完之后核心模块就非常清晰了。2.1 明确的角色划分与页面路径系统里只有两种角色。管理员能看全部菜单包括商品管理、入库管理、出库管理、库存查询、供应商管理以及操作员账号的开设普通操作员只负责日常录单、出库和查库存不碰基础数据的增删改。页面路径也按操作习惯来设计不是照搬教科书上的模块树。登录之后先进“工作台”工作台上有三块今日入库笔数、今日出库笔数、低库存商品预警这个对于MVP来说体验提升非常明显。左侧菜单有条理地排开核心操作不需要超过三跳。2.2 数据模型的边界怎么定数据库是进销存的命根子。表结构设计得好不好直接决定后续加功能的时候是轻松扩展还是推翻重来。MVP阶段我设计了这几张核心表表名作用关键字段users用户表id, username, password, role, created_atsuppliers供应商表id, name, contact, phone, addressproducts商品表id, sku, name, category, spec, unit, price_in, price_out, stock, min_stockstock_in入库单表id, supplier_id, operator_id, total_amount, status, in_date, remarkstock_in_item入库单明细表id, stock_in_id, product_id, quantity, price, amountstock_out出库单表id, customer_id, operator_id, total_amount, status, out_date, remarkstock_out_item出库单明细表id, stock_out_id, product_id, quantity, price, amount注意一个细节库存没有单独建表而是直接冗余在products表的stock字段里。这在严格的ERP设计里“不标准”因为缺乏流水可追溯但MVP阶段这样做完全合理——每次出入库操作都在事务里同步更新stock字段库存查询就变得极快连join都不用。如果要追溯历史也有办法后续加一张stock_log流水表就能解决。这就是MVP的取舍先保证核心流程跑顺再把审计跟踪补上。2.3 入库出库的核心业务流程入库的流程是操作员先创建入库单选择供应商然后一行行添加商品明细商品下拉选择自动带出当前进价数量手动填确认无误后点“确认入库”。此时做两件事写入入库单主表和明细表同时把商品的stock字段加上对应数量。这张单子从此变成历史记录不能再改。出库的流程对称创建出库单选客户MVP里客户可以用一个简单的customer字段存文本但为了规范我建了一张customers表后面标题里有需要再加先预留添加商品明细时系统自动显示当前库存如果填写数量大于库存直接在前端拦截并提示“库存不足当前可用库存为XX”确认出库后扣减库存。这样一套流程走下来最简单的进销存闭环就已经成立了进货多了库存卖货少了库存每一笔出入库都有单据可查。3. 技术选型JSPServlet被吐槽了这么多年为什么我还用它说到技术选型这是我在开发之前就认真纠结过的。一开始考虑过Spring Boot Vue前后端分离也考虑过Spring Boot Thymeleaf甚至连照着B站教程做一套若依脚手架改改的念头都有过。但最后压下来选了JSP Servlet MySQL这套“老古董”。做这个选择有三层考虑下面详细说清楚就不只是“课设要用”这么一个理由了。3.1 教学验收的角度能说清楚的才是自己的课设答辩和真实项目最大的不同在于老师会追问你实现细节。用Spring Boot Vue项目结构一大半是框架帮你拉好的依赖包几百个你连每个注解的原理都讲不全答辩的时候特别容易被问穿。JSP Servlet就非常直白。Servlet处理请求、设置参数、转发页面JSP负责把数据渲染成HTML请求从浏览器发出到Tomcat再到Servlet再到JSP再响应的完整链路每一环都能讲清楚。Filter做登录拦截和编码处理Listener在启动时初始化数据源JDBC从DriverManager到PreparedStatement到ResultSet这条路子对于课设而言是“能亲手讲明白每一行代码在干什么”的路线。这不是说框架不好。工作里我完全支持直接用Spring Boot但课设的场景很特殊——它更考察你对Web基础原理的理解而不是对框架生态的熟悉程度。3.2 资源约束下的实际可操作性JSP Servlet技术栈非常轻。一台普通笔记本JDK Tomcat MySQL IDEA四样东西装好就能跑不依赖Maven复杂依赖解析不依赖Node环境不用考虑跨域、打包和部署问题。直接把Web项目放进Tomcat的webapps目录启动Tomcat浏览器打开localhost:8080完事。这对小组协作也很友好导出war包就部署完成。有些同学的电脑配置一般开一个IDEA再开一个Android Studio已经卡得不行了再让他跑前端工程、后端工程、Node服务几个进程分分钟崩溃。3.3 性能面其实够用“JSP慢”“Servlet老”这些话说了很多年但得看场景。一个课程设计级别的进销存最多几十个并发用户JSP的预编译、Servlet的单实例多线程模型、JDBC连接池复用这套组合足够应付。在实际测试中我用JMeter模拟了50个并发用户同时查询库存列表平均响应时间在120ms左右完全在可接受范围内。真正会拖慢JSP项目的往往是没做连接池、频繁创建数据库连接、或者SQL写得稀烂。这几个坑避开了性能根本不是问题。3.4 如果换成现代技术栈提示词该怎么改松绑说一句提示词这套方法论同样适用于Spring Boot Vue组合。如果是Spring Boot Vue前后端分离的项目提示词里的“修改index.jsp”就得改成“修改前端router对应的Vue组件调用后端的/api/inventory接口”。但核心提示词不变角色定义、项目概述、技术栈、表结构JSON、模块功能描述、接口参数约定。这套骨架在哪个技术栈里都能复用只是描述侧重点不同。4. 整套项目提示词从零到一手把手搭出来既然核心是“可复用开发提示词”那这套提示词本身才是这篇文章最大的交付物。一步步说明它的写法、内容和用法。我习惯把提示词分两层顶层是项目主提示词一次对话开始时喂给AI用来锁定整个项目的方向和约束第二层是功能点提示词每开发一个模块时单独发起聚焦在单个功能上。这样能避免主线被细节带偏也方便增量开发。4.1 项目主提示词模板可直接复制的第一版你是一名经验丰富的Java Web全栈工程师专注于JSP Servlet MySQL技术栈的项目开发。 现在需要开发一套进销存管理系统MVP版本系统名称“蓝动记”。项目背景某小型贸易商行需要一套内部使用的进销存管理系统用于管理商品信息、供应商信息、采购入库、销售出库以及实时库存查询。硬性约束如下技术栈固定为JSP Servlet MySQL 8.0部署在Tomcat 9上。不使用任何第三方框架不引入Maven所有jar包手动导入到WEB-INF/lib目录包括mysql-connector-java、gson等。用户角色分为管理员和普通操作员管理员拥有全部功能权限操作员只能进行出入库操作和库存查询。数据库使用UTF-8编码数据库名为landongji。页面风格要求简洁清晰使用纯HTML CSS实现不引入Bootstrap等前端框架或者引入根据项目需要说明原因。请求路径统一以.do结尾如 /login.do, /product/list.do, /stock/in.do。所有对数据库的操作必须使用PreparedStatement严禁字符串拼接SQL。每个Servlet建议采用继承HttpServlet并重写doGet和doPost的方式action类型通过隐藏字段或路径区分。项目完成后提供数据库建表SQL脚本、Web目录结构、部署说明。这个主提示词的信息密度决定了AI输出质量的40%。技术栈约束一定要写死角色权限要写清楚路径风格要统一这样才能保证AI生成的不同模块之间不会出现“各自为政”的问题。4.2 表结构提示词的写法细节表结构是进销存系统的关键AI理解业务的关键信息来源。不能只说“帮我建几张表”要让AI理解业务语义和完整字段。我实际的提示词是这样组织的基于以下业务规则设计MySQL 8.0建表SQL要求所有表使用InnoDB引擎编码utf8mb4。用户表id主键自增、用户名唯一、密码MD5加密存储、角色admin/operator、创建时间。供应商表id、供应商名称、联系人、联系电话、地址、备注。商品表id、SKU编码唯一、商品名称、分类、规格、单位、进货价、销售价、当前库存数量、最低库存预警值、创建时间。入库单主表id、入库单号格式RK年月日四位序号、供应商id、操作员id、总金额、入库时间、备注。入库单明细表id、入库单主表id、商品id、进货数量、进货单价、行金额。出库单主表id、出库单号格式CK年月日四位序号、客户名称、操作员id、总金额、出库时间、备注。出库单明细表id、出库单主表id、商品id、销售数量、销售单价、行金额。额外要求在商品表的插入语句中预置至少10种常见商品数据供应商预置5条数据方便测试。这里把入库单号、出库单号的生成规则写清楚非常重要AI生成的代码里面就能直接实现单号生成器逻辑不用后补。4.3 功能模块提示词的分工写法进销存功能模块比较多最合理的做法是一个模块一个提示词每个模块的提示词都遵循统一的格式。下面拿“入库功能”作为示例【功能模块】采购入库 【业务描述】操作员登录系统后点击“入库管理”进入入库单列表页点击“新增入库单”选择供应商填写入库备注然后添加多条商品明细每行包括商品选择、数量、进货单价前端实时计算行金额和总金额。点击“确认入库”后系统完成二件事一是将入库单主表和明细数据写入数据库二是在同一个事务中更新对应商品的库存数量库存 库存 入库数量。 【约束条件】未登录用户访问该页面时跳转到登录页。操作员的ID从当前登录Session中获取不允许前端传入。商品下拉框的数据来自商品表中所有商品展示格式为“SKU - 商品名当前库存”。入库单号在Controller层使用日期格式加当天序号生成序号从数据库查最大单号的后四位加一。提交到Servlet的参数无论是主表字段还是明细字段均以JSON格式提交由后端解析。所有入库操作需要事务控制任一步失败则整体回滚。 【涉及页面】stock_in_list.jsp入库单列表stock_in_add.jsp新增入库单页面StockInListServlet, StockInAddServlet, StockInSaveServlet信息量越大生成的代码越精确尤其是约束条件这条直接决定AI生成的后端代码能不能和你前面的模块接上。4.4 提示词里的“提交与验收清单”这是我在第二版提示词里加上的也是最有用的改进之一。在完成了所有模块的开发提示词之后追加一段全部功能开发完成后请执行以下自检清单检查是否所有的Servlet路径都以.do结尾并且和JSP页面中的form action和超链接一致。检查数据库连接是否有泄漏风险每一个PreparedStatement、ResultSet、Connection是否在finally块或try-with-resources中关闭。检查登录Filter是否对除login.do、静态CSS/JS以外的请求都做了拦截。检查入库和出库操作是否都开启了事务。检查库存不足时系统是否有提示。检查页面上的按钮录入员不应看到用户管理按钮。有了这个“验收清单”AI生成完代码后会自动做一轮自查很多小bug在萌芽期就被消灭了。这一步帮我节省了大量的联调时间。5. 跑通后的真实效果和优化经验5.1 基线版本的实测结果我的基线版本基于这套提示词生成后做了一些人工调整最终的运行效果如下项目结构Java源码约12个Servlet、5个工具类、8个JSP页面、JDBC工具类1个功能完整度登录权限、商品CRUD、供应商CRUD、入库操作、出库操作、库存查询、低库存预警、出入库历史记录全部跑通数据库8张表预置测试数据20条部署耗时从零到浏览器能访问约10分钟在Tomcat 9 MySQL 8.0的环境下实测没有任何404或500错误基本达到当天拿给老师看demo也不慌的程度。5.2 优化一密码加密不能直接用MD5提示词里最初写的是“密码MD5加密存储”后来仔细想了下MD5毕竟不安全作为一个在博客里分享的方案不能误导别人。所以在第二版我改成了加盐的SHA-256。具体做法是每个用户有一个随机盐值存入数据库时拼接后的字符进行哈希。同样是十几行代码的事安全系数天差地别。建议你自己做的时候也这样写就算课设也一样好习惯从早期养成。5.3 优化二商品下拉框的可用性体验最初生成的下拉框直接把所有商品的SKU和名称拼成一个超长的option列表当你拥有上百个商品时这个下拉框就崩溃了——一是长到找不到想要的那一项二是一次性渲染几百个DOM节点会让页面卡顿。我在修改的时候给商品选择框加了一个搜索过滤功能输入关键字时通过AJAX请求过滤后端接口只返回匹配的商品。这个小改进让录入效率提升了一大截实际操作体验直线上升。5.4 优化三数据库连接池替换提示词的第一步生成的是“JDBC工具类直接使用DriverManager.getConnection”。这在MVP阶段能用但是每次请求都要创建和销毁连接数据库压力比较大我也提到过这个问题。后来我把JDBC工具类替换成了Alibaba Druid连接池pom里换成druid的jar写一个DruidUtil工具类读取配置文件然后在Servlet里把原来通过JDBCUtil.getConnection()的调用换成DruidUtil.getConnection()。具体的改法很简单给一个参考的Java代码public class DruidUtil { private static DataSource dataSource; static { try (InputStream in DruidUtil.class.getClassLoader().getResourceAsStream(druid.properties)) { Properties props new Properties(); props.load(in); dataSource DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } }对应的druid.properties文件driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/landongji?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai usernameroot password你的密码 initialSize5 maxActive20 minIdle5 maxWait5000替换之后高并发下数据库连接稳定性大幅提升同时因为连接池本身是Druid还能直接在页面上访问/druid/index.html查看SQL监控和慢查询记录联调和定位问题都方便得多。5.5 踩过的坑提示词生成了代码但事务控制缺失第一次按提示词生成的“入库保存”功能让我印象极深。它会先插入主表再插入明细表最后更新商品库存。前两步被一个Connection对象包在了一个事务里看似没什么问题但到了“第三步更新库存”——那个Connection居然重新调用了一次getConnection()跟前面的事务完全不是一个连接库存更新的失败不会导致前面两张表的数据回滚。排查了很久才定位到这个问题后来我在提示词的“功能模块约束条件”里明确加了一条整个功能中从创建连接、开启事务到最终提交或回滚所有数据库操作必须使用同一个Connection对象。事务范围内禁止重新获取连接。加了这个限制之后AI生成的代码里事务控制就老实多了。这个教训也让我意识到提示词的本质不是“越模糊越有创意”而是“越精确越可靠”。6. 提示词复用把“蓝动记”模板改成其他系统的完整过程说了这么多这篇文章的主标题里有个词很关键“可复用”。所以这部分专门讲一下当你已经拥有“蓝动记”的这套提示词之后下个项目怎么快速改出来。比如你现在要做一个“图书馆管理系统”需求是图书管理、读者管理、借书、还书、逾期查询。这个大方向套用同一套提示词只需要做四个步骤的替换。6.1 第一步替换项目概述和技术栈描述把主提示词里的“小型贸易商行需要一套内部使用的进销存管理系统”替换成“高校图书馆需要一套图书借阅管理系统”。技术栈不需要变还是JSPServletMySQL。6.2 第二步替换表结构提示词把“供应商”换成“出版社”把“商品”换成“图书”把“入库单”换成“采购入库/新书入库”把“出库单”换成“借书单/还书单”。核心的关联逻辑不变图书表对应商品表、出版社表对应供应商表、借书单表对应出库单一类。属性需要增加的在表结构提示词里补上即可比如图书的ISBN、作者、馆藏位置这些字段直接写进JSON或建表SQL里。6.3 第三步替换功能模块描述把“入库管理”的描述改成“新书到馆后批量入库选择出版社录入书名、ISBN、价格、数量确认入库后馆藏数量对应增加”把“出库管理”改成“读者借书登记输入读者证号选择要借的图书点击确认后对应图书的馆藏数量减一”。约束条件、路径规则、事务规则、权限管理都不动。6.4 第四步替换验收清单的相关描述把“检查库存不足时系统是否有提示”改成“检查馆藏数量为0时借书操作是否有明确提示”把“检查入库和出库操作是否都开启了事务”改成“检查借书和还书操作是否都开启了事务”。整个替换过程熟练的情况下不超过两小时换完就能拥有一个结构清晰、代码风格统一的新系统。这就是“可复用开发提示词”的杠杆价值。第一次做“蓝动记”可能花了两个星期第二次做“图书馆管理系统”可能只需要两三天这个效率提升是肉眼可见的。7. 一些关于学习和开发的私人建议曾经有一个学弟问我“用提示词做课设是不是有点不劳而获”我当时回答他如果直接拿着AI生成的代码交上去那确实是不劳而获但如果你把它当成一个“高水平的结对编程伙伴”自己拿着需求文档逐条拆解验证每段代码是否真的满足需求自己调试、自己改bug这就是正经的工程方法。用这套提示词开发的整个过程里我做的最多的事其实不是让AI写代码而是让它解释为什么这么写、能不能换个写法、这个边界有没有处理。AI的回答能补充我的盲区但决策权始终在我手上。这才是“AI辅助开发”的正确姿势。如果你准备复刻这套做法我给几个实操建议提示词不是一次成型的。写第一版的时候你可能根本不知道要写什么约束没关系先写个大概让AI生成第一版跑起来看问题然后反哺回提示词。我的那一版约束条件第5条“提交到Servlet的参数以JSON格式提交”就是因为第一次生成的form表单提交是普通参数格式后来改统一了才加进去的。建议每一轮对话有独立的专注主题。不要在一轮对话里又要设计表、又要建页面、又要写Servlet。把项目拆成“表结构设计”、“登录注册”、“商品管理”、“入库功能”、“出库功能”、“库存查询”等独立任务每个任务一轮对话生成完就测测完再开下一轮。这样万一出问题定位也快。数据库设计是底线一定自己把关。AI生成表结构会倾向于“每个业务概念都给一张表”有时候会多出很多冗余表你需要根据MVP原则自己删掉不需要的表。表结构一旦定下来后续生成的功能模块代码都围绕它转改起来最贵。版本管理别偷懒。哪怕是一个人开发也建议从第一天就初始化一个Git仓库。每跑通一个模块就提交一次多模块联调搞砸了还能回来。课设最怕的是什么代码改到一半找不到原来的可用版本只能从头再来。我在实际操作中最深的体会是提示词开发最关键的能力不是打字也不是会“魔法咒语”而是把模糊需求变明确的能力。你越能清晰地描述你的业务、边界、约束和验收标准AI的输出质量就越高你拿到手里的半成品也就越接近可用状态。这种能力不挑技术栈、不挑领域几乎是可以迁移到任何工作场景里的元能力。蓝动记这个项目的代码和提示词我目前都归档在本地Git仓库里。后续如果有精力会把其中通用性最强的提示词部分整理成一个更通用的模板放到自己的专栏里方便有需要的人直接取用。这个项目的最大意义不是代码本身——毕竟进销存源码网上多得是——而是“如何一步步拆解需求、设计边界、沉淀工具最终提高自己产出效率”的完整方法论。最后分享一个这段时间最深的感受技术圈永远在变今天流行的框架明天可能就被替代但“把问题想清楚、把需求写明白、把边界定好”这件事永远不会过时。工具是放大器而真正决定产出质量的始终是使用工具的人脑子里有没有那张清晰的蓝图。