每年这个时候，后台都会收到差不多的问题：毕设能不能让 AI 帮忙？

我的看法是：AI 可以帮你整理自己做过的工作，但不能替你编出没做过的工作。

这两件事听起来差不多，答辩的时候差别非常大。

下面是我见过、也帮别人改过的几个典型翻车点，按毕设文档的顺序排。

一、参考文献是编的

这是最常见、也最危险的一个。

让 AI"列 15 篇相关参考文献"，它会很流畅地给你一串作者、刊名、年份、页码，格式还挺像样。

问题是，里面有不少是不存在的。

老师随手去知网搜一下标题，搜不到，这一章基本就没法看了。

正确做法其实很简单：

• 文献自己去知网、百度学术、学校图书馆检索，自己读过、确实用到再放进去
• 格式拿不准，用知网或百度学术的「引用 → GB/T 7714」直接导出，再核对
• AI 只做一件事：帮你把已有的文献整理成统一格式

没有文献的时候，宁可让 AI 给你几个"建议检索关键词"，也别让它直接给文献。

二、论文里写的功能，系统里没有

很多同学是先写论文、后补系统，或者照着别人的论文改。

结果论文里写了"消息推送""数据大屏""智能推荐"，答辩老师说：打开系统演示一下。

然后就尴尬了。

我的建议是反过来：先从自己的代码里把素材提出来，再写论文。

具体提哪些：

• 技术栈和实际版本号，去看 package.json、pom.xml，而不是写"采用最新版 Vue"
• 页面清单，从路由文件、菜单配置里数
• 接口清单，从后端 Controller 里列
• 数据库表，从建表 SQL 或实体类里整理

最后拿"前端页面"和"后端接口"对一遍。有页面没接口、有接口没页面的，要么补上，要么论文里别写。

这一步 AI 很擅长，因为它只是读你的代码，不需要它编任何东西。

三、测试用例全部"通过"

测试章节翻车的样子基本一样：

一张大表，三十条用例，结论一栏整整齐齐全是"通过"，零缺陷。

老师一看就知道这是没跑过的。

真正做过测试的系统，一定发现过问题。比如必填项没校验、重复点击提交了两次、普通用户能访问管理接口。

所以测试章节可以这么写：

• 用例可以让 AI 帮你列：正常流程、必填为空、格式错误、边界值、越权、重复提交
• 「实际结果」和「结论」两列，必须是你自己真的点过、跑过之后填的
• 没跑过的就空着，别先写"通过"
• 发现的 bug 和修复过程写进去，这比"全部通过"更有说服力

性能数据也一样。没测过响应时间，就不要写"响应时间小于 200ms"。

四、截图和数据是假的

有些同学系统没跑起来，就让 AI 画个界面图，或者 P 一张截图。

答辩现场一演示，界面对不上，问题就大了。

截图一定要来自你自己运行的系统。可以让 AI 帮你列一个截图清单：哪个页面、要展示什么状态（列表有数据、弹窗打开、校验提示），然后你自己去截。

另外，截图和代码片段里记得去掉真实的密钥、数据库密码、服务器 IP 和真实用户信息。

五、"降重技巧"

同义词替换、打乱语序、插隐藏字符……这些网上流传的办法，本质上是在骗查重系统。

一方面可能违反学术规范，另一方面改出来的句子往往读不通。

重复率高，根本原因通常是"相关技术"那一章抄了百科、抄了别人的论文。

真正有效的办法是：

• 用自己的系统、自己的数据、自己的截图和测试结果来写
• 技术介绍用自己的话概括，引用的地方标注出处
• 和你的系统无关的大段技术科普，删掉就是了

六、没看学校对 AI 的规定

这一点最容易被忽略。

现在不少学校对"毕业论文能不能用 AI、用到什么程度、要不要声明"有专门的规定，各校要求不一样。

动手之前，先去看一下自己学校、学院的通知，或者直接问指导老师。

答辩时如果被问到"哪些是你自己写的，用了哪些开源组件或 AI 工具"，如实回答。

最终交上去的每一段文字，都应该是你自己审过、改过、能讲清楚的。

最后

总结一下，AI 在毕设里比较合适做的事：

• 从你的代码里提取素材，检查论文和系统是否一致
• 按学校格式整理目录、图表编号、三线表、参考文献格式
• 帮你列测试用例的框架，提醒你漏了哪些场景
• 模拟答辩老师提问，帮你找薄弱点

不合适做的事：编文献、编测试结果、编截图、替你写你自己都讲不清的内容。

上面这些规则，我整理成了一套给 AI 编程工具用的技能说明，包括"先从代码提取素材""测试结果必须真实执行""不编造文献"这些红线，开源在 GitHub 上，仓库名 MsNan/bishe-doc-skills，需要的可以自己搜。

能不能用、怎么用，还是以你们学校的规定为准。