这段时间写论文，我越来越明显地感觉到一件事：AI 确实能把论文写作的效率拉高很多，但它不是那种“你什么都不干，然后它替你变出一篇论文”的东西。
尤其是软件开发类、系统设计类、毕业设计类论文，如果没有真实项目、没有开发记录、没有自己的判断，直接让 AI 生成全文，最后很容易得到一篇“看起来很完整，但细节全是空的”的文章。读起来很顺，仔细一看又经不起问。
所以我更愿意把 AI 当成一个协作工具：它负责调研、整理、归纳、扩写和润色；而我负责提供真实材料、确认方向、判断取舍和最终把关。
下面这套流程，就是我觉得比较适合普通学生使用的 AI 协作论文写作工作流。
第一步：先用 Gemini 做前期调研 (或类似产品)
论文第一章通常是绪论，一般会写研究背景、当前现状、存在问题、发展趋势和研究意义。
这一部分很适合先用 Gemini 的 Deep Research / Deep Search 模式来做资料调研。它的好处是可以围绕一个主题进行比较系统的资料搜索，而且通常会带上来源和引用信息，后续整理参考文献也会方便很多。
我一般会让它围绕这些方向调研：
这个研究领域为什么重要
当前行业或技术发展到了什么阶段
国内外有没有类似研究或应用
目前还存在哪些问题
后续可能有哪些发展趋势
哪些资料可以作为论文引用
但这里要注意，Gemini 调研出来的东西只是“素材”，不是可以直接粘进论文的正文。它给你的内容往往比较宽泛，需要你结合自己的论文题目、项目背景和学校要求重新筛选、整合和改写。
这一步比较理想的产出是：一份绪论素材文档，一份参考文献候选清单，以及若干可以支撑研究背景和研究现状的资料来源。
第二步：把自己的项目先整理清楚
如果你的论文是软件开发类的，那么正文后面大概率会写需求分析、系统设计、系统实现、系统测试这些内容。
这些内容千万不要让 AI 凭空编。它必须来自你的真实项目。
这一阶段可以用 Claude Code、Cursor、Trae、Gemini CLI 之类的 Agent 工具，让它们帮你对项目进行整理。比如让它读取项目代码、任务文档、开发笔记，然后总结：
项目已经完成了哪些功能
哪些功能原本计划做，但最后没有完成
系统有哪些核心模块
每个模块大概负责什么
用了哪些技术栈
数据库是怎么设计的
哪些 Bug 或技术问题比较值得写进论文
哪些文档可以支撑后续章节
如果你之前有任务文档，也可以让 Agent 做对比：原计划是什么，实际完成了什么，哪些地方发生了调整。这样整理出来的“已完成 + 未完成”清单，在写论文的时候非常有用。
我比较推荐单独维护一份开发记录索引表，类似这样：
时间
文档/记录
类型
主要内容
可用于论文位置
2026-xx-xx
架构设计记录
系统设计
系统整体结构、模块关系
第三章或第四章
2026-xx-xx
数据库设计文档
数据库设计
数据表、字段、关系
系统设计章节
2026-xx-xx
功能开发记录
系统实现
某个模块的实现过程
系统实现章节
2026-xx-xx
Bug 修复记录
测试优化
问题原因和修复方式
系统测试章节
这个表的意义不只是“方便写论文”，更重要的是防止 AI 写着写着开始乱编。只要你给它的材料足够真实，它生成出来的内容就会更贴近项目本身。
第三步：不要急着写正文，先确认大纲
很多人一上来就让 AI 写第一章、第二章、第三章，其实这样很容易后面推翻重来。
我更建议先把大纲定下来。
可以让 Agent 基于前面整理出来的项目文档，先生成一版论文大纲。这个大纲最好包括：
每一章写什么
每一节解决什么问题
哪些内容来自项目资料
哪些地方需要补图
哪些地方需要表格
哪些内容需要再和导师确认
大纲出来之后，不要马上开始写正文。先自己看一遍逻辑是否顺，再拿去和导师沟通。比较稳的方式是：你、导师、AI 三方一起参与大纲确认。
你负责说明项目真实情况，导师负责把关论文结构和学术规范，AI 负责帮助整理表达和补充结构。这样最后确定的大纲，会比自己硬憋或者让 AI 单独生成更可靠。
软件开发类论文的常见结构大概是：
绪论
相关技术介绍
系统需求分析
系统设计
系统实现
系统测试
总结与展望
当然，具体怎么写还是要看学校模板和导师要求。
第四步：按章节迭代，而不是一次性生成全文
大纲确认后，就可以开始写正文了。
我的建议是：一章一章写，甚至一节一节写。不要一次性让 AI 生成整篇论文。
比较好用的循环是这样的：
选定一个章节或小节。
把大纲、项目资料、开发记录、写作要求一起给 AI。
让 AI 生成初版。
自己检查事实、逻辑和表达。
补充缺失材料，删掉不准确内容。
再让 AI 优化语言和结构。
根据正文需要补图、补表或补说明。
这一步的核心不是“生成”，而是“迭代”。AI 第一版通常只是一个起点，真正能不能变成论文内容，要看你后面怎么改。
比如写系统实现章节时，不要只给 AI 一个标题“用户管理模块实现”。你应该把真实的功能点、页面逻辑、接口设计、数据库字段、关键代码思路都给它。这样它写出来才不会变成泛泛而谈的模板文。
第五步：图表要跟着正文一起整理
论文里常见的图表包括系统架构图、功能模块图、业务流程图、数据库 E-R 图、接口说明表、测试用例表等。
我不建议等全文写完再统一补图。更好的方式是写到哪里，就顺手判断这里需不需要图表。
比如：
写系统设计时，可以补系统架构图和模块结构图
写数据库设计时，可以补 E-R 图和核心数据表
写系统实现时，可以补功能流程图或页面截图
写系统测试时，可以补测试用例表和测试结果表
AI 在这里可以帮你判断“哪里适合放图，哪里适合放表”，也可以帮你写图表前后的说明文字。但图表内容本身仍然要来自真实项目，不能让 AI 随便编字段、编接口、编测试结果。
第六步：全文都要围绕真实开发记录
整个写作过程中，有一个原则很重要：论文内容尽量围绕开发记录展开。
尤其是这些内容，最好都能从真实资料里找到依据：
系统实现了什么功能
每个模块的职责是什么
技术选型为什么这样做
数据库表为什么这样设计
接口和页面之间如何对应
测试过程中发现过什么问题
项目最后还存在哪些不足
如果已有文档写得比较粗糙，可以让 AI 帮你优化。如果文档缺失，就先把事实补上，再让 AI 整理成论文语言。
说白了，AI 最适合做的是“把已有材料整理好”，而不是“凭空替你创造项目经历”。
我最后总结的一套流程
可以把整个过程压缩成下面这张表：
阶段
主要任务
推荐工具
关键产出
资料调研
调研背景、现状、趋势和参考文献
Gemini Deep Research / Deep Search
绪论素材、参考文献候选
项目整理
梳理功能、模块、技术栈和开发记录
Claude Code、Cursor、Trae、Gemini CLI 等
功能清单、开发记录索引表
大纲确认
根据资料生成并调整论文结构
Agent + 人工判断 + 导师意见
最终论文大纲
分章写作
按章节生成初稿并人工修改
各类写作型 AI 工具
章节初稿、优化稿
图表补充
整理图、表、截图和说明文字
AI 辅助 + 项目真实材料
架构图、流程图、测试表等
全文优化
统一风格、检查逻辑和补充细节
AI 辅助 + 人工审阅
定稿前版本
写在最后
AI 确实能让论文写作快很多，尤其是在调研、整理、扩写和润色这些环节上。但它不能代替你做项目，也不能代替你判断内容是否真实。
我觉得比较健康的方式是：把 AI 当作一个效率很高的协作者，而不是代写工具。
你负责真实经历、项目判断和最终把关；AI 负责把这些材料整理得更清楚、更规范、更像论文。这样写出来的东西，才不会只是“看起来像论文”，而是真的能对应到你做过的项目。
不过也要提醒一下：由于论文中有不少内容会经过 AI 润色，最后检测 AIGC 率时难免可能偏高。我自己也整理了两个用于降低 AIGC 痕迹、优化论文表达的 skill，这里就不过多展开了。
如果一个人想完全不参与项目、不整理资料、不做判断，只想让 AI 直接生成一篇论文，那这套流程可能不适合他。
但如果你本来就做了项目，只是苦于资料太散、表达太慢、大纲不好组织，那么这套工作流还是挺值得试试的。