用 AI 做毕设，需求应该怎么写

不要只写题目

下面这种需求太模糊：

帮我做一个 Spring Boot + Vue 的图书管理系统，要有登录、增删改查和后台。

它缺少角色、流程、字段、权限和验收标准。AI 只能按通用模板猜。

更好的写法

可以这样描述：

我想做一个高校图书借阅管理系统，技术栈用 Spring Boot + Vue + MySQL。系统有学生、管理员两个角色。学生可以注册登录、搜索图书、查看详情、提交借阅申请、查看借阅记录和归还状态。管理员可以维护图书分类、录入图书、审核借阅申请、登记归还、查看逾期记录和统计借阅排行。需要生成前后端源码、数据库表、测试账号和运行文档。

这个版本明显更适合生成，因为它给出了边界。

需求模板

你可以按这个结构写：

项目题目：
技术栈倾向：
用户角色：
核心功能：
页面清单：
数据对象：
权限规则：
需要的统计或报表：
本地运行要求：
论文或答辩关注点：

如果暂时写不完整，也可以先和 AI 聊题目，让 AI 反问你缺失的信息。智码方舟的对话流程会把聊天内容提取成结构化需求，再进入生成任务。

页面清单比功能名更重要

“用户管理”这种功能名太粗。更实用的写法是：

• 用户列表页：分页、搜索、启用、禁用。

• 用户详情页：查看基本信息和关联记录。

• 新增用户弹窗：填写账号、手机号、角色。

• 个人中心页：修改昵称和密码。

页面清单能直接影响前端路由、组件和接口数量。

数据对象要提前列

哪怕你不会设计数据库，也应该列出业务对象：

• 用户

• 角色

• 图书

• 分类

• 借阅记录

• 归还记录

• 公告

AI 可以帮你补字段，但对象最好由你确认。因为对象代表业务范围，范围错了，代码再完整也不符合题目。

少写空泛要求

“界面美观”“功能完善”“代码规范”这些可以写，但不能只写这些。更明确的要求是：

• 使用后台管理布局。

• 列表页要有搜索和分页。

• 表单要有必填校验。

• 后端接口要返回统一响应格式。

• README 要写清启动命令和测试账号。

坏需求和好需求对比

坏需求通常长这样：

我要做一个校园二手交易平台，前后端分离，功能完善，界面美观，代码规范。

这段话的问题是没有边界。AI 不知道你要不要订单、要不要支付、要不要聊天、要不要管理员审核，也不知道学生和管理员分别能做什么。

好一点的需求可以这样写：

我要做一个校园二手交易平台，用 Vue + Spring Boot + MySQL。普通学生可以注册登录、发布商品、上传商品图片、搜索商品、收藏商品、发起下单、给卖家留言。管理员可以审核商品、管理分类、处理举报、查看商品和订单统计。平台不做真实支付，只记录订单状态。需要生成前后端源码、数据库表、测试账号和运行文档。

这个版本仍然不复杂，但已经告诉 AI 哪些功能必须做，哪些功能明确不做。尤其是“不做真实支付”这种排除项很重要，它能避免生成过重的支付流程。

可以主动写排除项

需求文档里不只写“要什么”，也要写“不要什么”。例如：

• 不需要真实支付，只模拟订单状态。

• 不需要接短信验证码，注册时用普通账号密码。

• 不需要复杂权限系统，只区分普通用户和管理员。

• 不需要移动端 App，只做 Web 页面。

• 不需要部署到公网，只要求本地可运行。

排除项能减少 AI 过度发挥，也能让生成结果更适合毕设范围。

给 AI 的输入不必一次完美

如果你一开始只能写出题目，也没关系。可以先发题目，让 AI 追问你：

• 有哪些用户角色？

• 需要哪些核心功能？

• 老师有没有指定技术栈？

• 数据库用 MySQL 还是其他？

• 是否需要论文或报告？

• 是否有学校模板要求？

智码方舟的对话流程本来就是先帮你把需求聊清楚，再提取结构化需求。关键是不要在需求还很模糊时直接进入完整生成。

最后确认一次验收标准

生成前建议写 5 到 8 条验收标准。比如图书借阅系统可以写：

• 学生能搜索图书并提交借阅申请。

• 管理员能审核借阅申请。

• 审核通过后借阅记录状态变化。

• 学生能查看自己的借阅记录。

• 管理员能查看逾期记录。

• 系统能按分类统计图书数量。

• README 中包含测试账号和启动命令。

验收标准是后面检查结果的依据。没有验收标准，就很容易陷入“感觉不太对，但不知道哪里不对”。

不同题目的需求侧重点

不同类型的毕设，需求重点不一样。

管理系统类项目要重点写角色、权限、列表、表单、审核、统计。比如宿舍报修、图书借阅、学生成绩、课程报名。

交易平台类项目要重点写商品、订单、收藏、留言、评价、审核、状态流转。比如校园二手交易、农产品商城、图书交换平台。

内容平台类项目要重点写发布、分类、评论、审核、搜索、推荐或浏览统计。比如博客系统、资讯平台、校园论坛。

预约类项目要重点写时间段、资源、预约冲突、取消规则、审核和提醒。比如实验室预约、场地预约、医生预约。

先判断题目类型，再写需求，会比从空白文档开始更容易。

需求写完后怎么检查

可以用“三个能不能”判断：

• 能不能画出页面菜单？

• 能不能画出数据库表？

• 能不能演示一条完整流程？

如果页面菜单画不出来，说明功能边界不清楚。如果数据库表画不出来，说明业务对象不清楚。如果完整流程走不出来，说明项目主线不清楚。

这三个问题都能回答，再生成项目会稳很多。

小结

好的 AI 毕设需求不是文学描述，而是交付说明。你越能写清角色、页面、数据和验收标准，生成出来的项目越接近能演示、能修改、能答辩的状态。