论文写到最后一天，最让人头疼的往往不是字数不够。目录跳页，图表和正文对不上，参考文献查无此文，测试章写得像真的跑过，Word 能打开，转成 PDF 却多出一堆空白页。Codex 几分钟就能生成几千字，可一篇能交付的论文，麻烦全在这些细处。

        今天小编这篇攻略不讨论怎么让 Codex 一口气吐出整篇论文。我们换一种做法，把题目拆成 10 个阶段，每一段都留下能检查的产物。研究问题没定，就不急着写大纲。证据没找到，就不让正文先下结论。测试没运行，就老老实实写成待验证。

        为了讲清整个过程，下面还是以之前我们的范文为例。目标很具体，最后要拿到一份可以继续修改的 DOCX、一份版式稳定的 PDF，以及与正文对应的图表、参考文献和检查记录。

▲ 一篇论文真正进入交付阶段时，封面、目录、正文、图表、引用和文件格式必须同时过关。

01｜先把 Skill 装对

        这次使用的还是之前介绍过的ARS这个仓库，而 academic-research-skills 主仓库面向 Claude Code。Codex 用户需要安装作者提供的 Codex 适配仓库，调用入口是 $academic-research-suite。

        在 Codex 中依次执行下的命令。

codex plugin marketplace add Imbad0202/academic-research-skills-codex --ref main
codex plugin add ars-codex@ars-codex

        安装后新开一个任务，输入 /skills。列表里能找到 academic-research-suite，才算装到了正确位置。如果入口没有出现，先检查仓库地址和插件状态。不要急着把论文题目丢进去，也不要同时安装几套同名 Skill。入口混乱时，后面的提示词写得再细也无济于事。

        这套 Skill 里有研究、论文写作、评审、实验规划和完整论文流程等不同路径。本文要做成 DOCX 与 PDF，因此选择完整论文流程 academic-pipeline。

02｜第一次对话只做立项

        很多论文从第一句话就走偏了。把题目、字数和截止时间一次发过去，模型马上生成一份八章大纲，看上去进展飞快。可它还不知道有没有源码、能不能做实验、采用哪种引文格式，也不知道题目里哪些内容有证据支撑。第一次对话只做 Stage 0。它相当于开工前的材料盘点。把下面这段发给 Codex。

使用 $academic-research-suite 
启动 academic-pipeline。
论文题目：基于 SpringBoot 的助农服务平台系统设计与实现
论文类型：本科毕业论文
目标产物：可编辑 DOCX、最终 PDF、图表、参考文献与检查记录
已有材料：请按实际填写论文模板、开题报告、源码、数据库、问卷、实验记录和已有文献
写作语言：中文
引文格式：按学校模板填写，尚未确定时请标记待确认现在只执行 Stage 0。
先盘点材料，识别缺口和风险，提出需要我回答的问题。
不要写正文，不要假设我已经提供源码或实验数据。
完成后停止，等待我确认。

Codex 接下来应该追问一些很具体的问题。

• 学校有没有固定模板

• 论文是系统设计型，还是包含实证研究

• 源码能否运行，数据库是否完整

• 测试数据来自真实运行，还是只做测试方案

• 需要哪些图，是否有现成原型和截图

• 参考文献的年份、数量和格式有什么要求

• 哪些信息必须匿名处理

        这一步看似没有写一个字的正文，却能提前避开大部分返工。例如没有源码时，后文就不能出现接口响应时间、并发量和测试通过率。没有学校模板时，可以先做通用排版，但最终状态只能写成待适配。材料边界越早说清楚，后面越不容易出现一本正经的虚构。假设你手里暂时只有题目、开题报告和十几篇文献，Stage 0 的结果至少要说清三件事。

当前情况	对论文的影响	接下来的处理
有开题报告，没有最终研究问题	可以沿用选题背景，不能直接照搬旧大纲	先收敛研究问题
有参考文献列表，没有原文	能作为检索入口，暂时不能支撑引用	找原文并核对元数据
没有源码和运行日志	可以写需求与设计，不能声称系统已实现并通过测试	补源码，或把实现与测试标成待验证

如果 Cod出用。

03｜把宽泛题目收成三个能回答的问题

        Stage 1 处理研究问题和证据。《基于 SpringBoot 的助农服务平台系统设计与实现》只是一个题目，还不足以指导写作。可以先把它收成三个问题。

1. 平台需要覆盖哪些真实角色和核心业务流程

2. 系统怎样组织权限、商品、订单与助农信息等模块

3. 现有材料能支持哪些实现和测试结论，还有哪些只能停留在设计层面

        这三个问题分别牵住需求分析、系统设计和验证边界。之后每一章都应该能回到其中至少一个问题。接着让 Codex 建立一张证据表。

继续执行 Stage 1。
围绕已经确认的研究问题开展检索和材料整理。
请建立证据表，每一行至少包含以下字段。
claim_id准备支持的主张来源题名作者或机构年份原始链接或DOI证据所在页码或章节证据强度核验状态可用于论文的具体位置优先使用论文原文、标准、官方文档和权威机构资料。
找不到原文时标记未核验，不要补写作者、年份或结论。
完成证据表后停止，先让我检查来源。

        这里有一个很实用的判断方法。如果证据表里的一行，只写着一篇文章的标题，却说不出它支持正文里的哪句话，这条资料还不能进入论文。反过来，一段正文如果下了明确结论，却找不到对应的 claim_id，也应该先删掉或降级措辞。

        这样做会慢一点，但能把最常见的文献幻觉挡在正文外面。从这一步开始，建议把阶段产物分别保存。文件名不用照抄，关键是让研究、正文、评审和最终文件彼此分开。

research-contract.md
evidence.csvoutline.md
argument-map.md
chapters/integrity-check.md
peer-review.md
revision-log.md
final-paper.docx
final-paper.pdf

        这样做的好处要到后半程才会显出来。导师指出某个结论缺依据时，你可以先查证据表，再定位章节和修订记录，不必在一份几万字的 Word 里反复搜索。

04｜先画出论文骨架，再动笔写章节

        证据表确认后，才进入 Stage 2。这一阶段别满足于一份只有章节名称的目录。真正有用的大纲，要写清楚每一节准备回答什么问题、使用哪条证据、需要哪张图表、结束时要得到什么结论。可以这样要求 Codex。

进入 Stage 2，先生成详细大纲和论证关系，不写完整正文。
每一节都要列出本节要回答的问题核心主张，
对应的claim_id需要的图表或代码证据可能的反例与限制，
本节结束时应该得到的结论检查相邻章节是否重复，检查每个研究问题是否有对应章节。
大纲完成后停止。

        对这篇助农平台论文，一条比较顺的写作线是从用户与业务场景出发，进入需求分析，再到总体架构、数据设计、模块设计、实现证据、测试与总结。以“订单管理”这一节为例，大纲不能只写一个标题。它至少应该带着下面这张任务卡。

项目	内容
要回答的问题	农户、消费者和管理员分别能对订单做什么
本节主张	订单状态变化受到角色权限与业务规则约束
所需材料	需求说明、用例图、状态变化规则、对应代码或设计稿
计划配图	订单状态图或核心流程图
当前限制	没有运行日志时，只描述设计，不评价响应速度

        有了这张卡，Codex 才知道这一节写到哪里算完成。你也能在动笔前发现材料缺口，而不是用几段泛泛的 SpringBoot 介绍把空白填满。最终成品中的研究框架页，应该让读者一眼看出这些部分怎样连接，而不是摆一张与正文无关的装饰图。

▲ 图里出现的每个模块，都应当在后续章节得到展开。正文里没有解释的框，宁可删掉。

大纲确认后，按章写。一次只写一章，写完就停。

现在只写第 3 章系统需求分析。
严格使用已确认的大纲和证据表。
引用只能来自核验通过的来源。
涉及项目自身的功能、数据和效果时，只能使用我已经提供的材料。
无法确认的内容请标记为待补充，并说明需要什么证据。
本章结束后附上三项内容本章使用的claim_id，
仍然缺少的证据需要我人工确认的判断写完后停止，不要自动进入下一章。

逐章暂停听上去有些笨，却非常适合长论文。你可以在第三章发现角色定义错了，而不是等第七章写完才发现数据库、接口和测试对象全要重做。

05｜图表要来自设计过程，不能在最后补装饰

系统类论文最容易露怯的地方就是配图。架构图、用例图、流程图和数据库关系图如果不够突出，正文写得再流畅也撑不住。比较稳妥的做法，是先让 Codex 输出图的内容清单，再根据源码、数据库或已经确认的设计绘制。每张图在进入论文前，都问四个问题。

• • 图里的对象是否真的在项目中存在

• • 箭头方向是否与调用或数据流一致

• • 图名、编号和正文引用能否一一对应

• • 缩到 A4 页面后，文字还能不能看清

系统架构页既要清楚，也要回答请求怎样进入系统、业务模块怎样拆分、数据保存在哪里。

▲ 这类图最值得检查的是连线和边界。框画得整齐，不代表关系一定正确。

        如果项目有源码，可以让 Codex 读取控制器、服务层、实体类和配置，再生成待确认的架构说明。随后由你对照代码逐项确认。

        如果项目没有源码，就把这一章写成设计方案。不要出现“系统已经实现”“接口运行稳定”之类的完成式表达。设计稿和运行证据是两回事。

06｜测试章分两条路走

        论文写到测试章，最危险的诱惑是让模型补一张全绿的测试表。这里必须分情况处理。有源码、有运行环境，也有测试数据，就让 Codex 协助制定测试计划、执行允许执行的命令、保存原始输出，再根据日志写结果。表里的每个通过状态都要能回到一次真实运行。

        没有这些材料，就只写测试目标、测试用例、前置条件、操作步骤和预期结果。实际结果、通过率、响应时间全部留空或标成待实测。可以直接使用下面这段。

请处理测试章节。
先判断我提供的材料能否支持真实测试。
如果可以，先给出测试计划，等我确认后再执行，并保留原始日志。
如果不可以，只生成测试用例和预期结果。
禁止编造测试通过率、响应时间、并发量、用户反馈和性能提升。、
所有未运行项目统一标记为待实测。

        一张写着待实测的表，可能没有那么漂亮，但它不会把论文带进更大的麻烦。测试用例也要留出证据位置。下面这个结构可以直接交给 Codex，再根据项目修改。

用例	前置条件	操作步骤	预期结果	实际结果	运行证据
消费者取消待付款订单	用户已登录，订单处于待付款	打开订单详情并确认取消	状态变为已取消，库存按业务规则处理	待实测	待补日志或截图

        最后两列故意分开。实际结果只记录观察到的现象，运行证据保存日志、截图、测试报告或可复现命令。这样即使后面改了结论，也知道应该重新检查哪份材料。

▲ 测试章节应让读者分清测试设计、预期结果和真实运行结果。三者不能混写。

07｜初稿写完，先别急着导出 Word

完整论文流程在初稿后安排了一次完整性检查，也就是 Stage 2.5。这一轮先查硬伤。

• 参考文献能否找到原文

• 引用位置是否真的支持当前句子

• 数字、比例和效果描述有没有出处

• 图表编号是否连续，正文是否都引用过

• 摘要、结论和正文有没有互相矛盾

• 设计方案是否被写成已经实现

• 待实测内容是否偷偷变成了测试通过

把任务写得具体一些，Codex 的检查结果才不会只剩“结构完整、逻辑清晰”这种空话。

进入 Stage 2.5，执行完整性检查。
逐条检查文献存在性、引用支持关系、数字来源、图表引用、章节一致性和实验真实性。
每个问题都要给出所在章节、原句、问题类型、风险等级和修改建议。
无法核验的条目保留为未验证。
不要因为文档已经成形就默认通过。
完成后停止，等待我决定是否进入评审。

        检查通过后，再进入 Stage 3 评审。这里要把 Codex 当成一位挑毛病的评阅人，让它分别看研究问题、论证、证据、方法、图表、格式和学术诚信。评审意见进入 Stage 4 修订。每改一项，都记录修改位置、修改前的问题、修改后的文本和验证方式。随后用 Stage 3' 复审，仍有大问题就继续 Stage 4'。最后的 Stage 4.5 再从头通读一次。

        这几轮看起来重复，分工其实很清楚。第一次检查负责找事实和结构上的硬伤，评审负责判断论文是否说服人，复审负责确认问题真的被修掉，最后一次检查则防止修改一个地方又弄坏另一个地方。修订记录也别只写“已修改”。一条合格的记录应该能让别人复查。

问题位置	发现的问题	修改动作	验证方式
第 6 章测试结果	把预期效果写成真实结果	改为待实测，删除通过率	对照测试日志与证据表
图 4-2 系统架构	图中模块名与正文不一致	统一名称并重写图注	搜索全文模块名，人工看图
参考文献条目	DOI 可打开，但作者信息不一致	回到出版方页面更正	再查元数据与正文引用

        这样的记录不会让论文自动变好，却能阻止同一个问题在几轮修改中反复出现。

08｜把 AI 使用边界写进论文

        Codex 可以帮助检索、整理、改写、检查和排版，作者仍然要为数据、引用和结论负责。如果学校或期刊要求披露生成式 AI 的使用情况，就如实写清楚使用环节、人工复核方式，以及工具没有参与的部分。不要写成广告，也不要用一句“仅用于润色”掩盖实际参与范围。

▲ 披露的重点是责任边界。哪些内容由工具协助，哪些证据由作者核验，应当写得清楚。

        还有一条底线很容易被忽略。Codex 可以帮你设计实验，整理已有结果，甚至在允许的环境里运行代码。它无法替你证明数据来自真实对象，也无法替你承担伦理审查、知情同意和学术责任。只要这条边界没有证据，就别让句子越过去。

09｜Stage 5 才开始做 DOCX 和 PDF

        正文、引用、图表和检查记录都稳定以后，再进入 Stage 5。这一阶段建议先生成可编辑的 DOCX，再生成 PDF。两份文件都要保留，因为后续还可能根据导师意见改字，也可能需要一份版式固定的提交件。

进入 Stage 5，生成最终交付文件。
输出一份可编辑 DOCX 和一份 PDF。
应用我提供的学校模板与引文格式。
保持标题层级、图表编号、交叉引用、页眉页脚和参考文献一致。
同时给出一份最终检查清单。
如果目录域需要在 Word 中手动更新，请明确提醒。
如果模板、字体或转换环境尚未验证，请标记待处理，不要宣布完成。

        文件生成后，先做机器检查。

• DOCX 与 PDF 能否正常打开

• 页数是否异常，是否出现空白页

• 图片是否全部嵌入

• 表格是否越过页边距

• 标题层级能否生成目录

• PDF 里的文字能否选择和搜索

        然后一定要人工翻页。封面信息有没有错，目录页码是否更新，图题会不会跑到下一页，流程图是否被裁切，表格能不能在手机和电脑上看清，长链接有没有冲出页面，这些问题很难只靠文本检查发现。参考文献页尤其值得单独看。条目数量对得上，只能说明没有明显丢失。作者、年份、刊名、卷期、页码、DOI 和引用格式仍要逐项复核。

▲ 参考文献进入最终 PDF 后，还要检查换行、悬挂缩进、长链接和著录信息。

10｜最后用这张表决定能不能交

到这里，10 个阶段已经走完。为了方便照着执行，可以把它们收成一张操作卡。

阶段	你要做的事	通过后应留下的产物
Stage 0	盘点材料，确认题目、模板、数据与真实性边界	任务单、缺口清单、风险项
Stage 1	收敛研究问题，检索并核验来源	研究问题、证据表、来源记录
Stage 2	做大纲与论证关系，逐章写作	大纲、章节稿、图表清单
Stage 2.5	检查引用、数字、图表和实现证据	完整性问题清单
Stage 3	以评阅人视角挑问题	分级评审意见
Stage 4	按问题逐项修改	修订记录与新稿
Stage 3'	复查关键问题是否解决	复审结论
Stage 4'	处理剩余问题	第二轮修订记录
Stage 4.5	全文回归检查	最终问题清单
Stage 5	生成并验收 DOCX 与 PDF	可编辑稿、提交稿、验收清单

提交前，再回答六个问题。

1. 每一条引用都能回到原文吗

2. 每一个数据和效果结论都有真实依据吗

3. 图表与正文、源码或设计材料一致吗

4. 测试章能分清已运行和待实测吗

5. DOCX 与 PDF 都经过人工翻页吗

6. 学校模板、匿名要求和 AI 使用规定都确认了吗

        只要其中一项答不上来，就把状态写成待补充，回到对应阶段。论文已经生成文件，不等于论文已经可以提交。Codex 在这套流程里最有价值的地方，是替你维持一条很长的工作链。它记住研究问题，整理来源，逐章推进，追踪评审意见，也提醒你哪些地方还缺证据。

        第一次尝试时，不用急着跑完全部阶段。先装好 Skill，用自己的题目完成 Stage 0。把材料缺口看清楚，再决定这篇论文下一步究竟该检索、该写作，还是该回去补源码和数据。这一步做对了，后面的 DOCX 和 PDF 才有可能成为论文成品，而不只是两份看起来很完整的文件。

如果你想先把项目跑起来

        这套 Codex 流程适合愿意管理本地材料、逐阶段确认、保留检查记录的人。好处是每一步都能停下来复查，第一次配置也会多花一点时间。

        如果你眼下卡在选题、开题、综述或初稿整理，暂时不想处理 Skill 安装和命令行，可以先用 千笔-AIWritePaper 把题目、目录和已有材料整理成一版可继续修改的初稿。拿到初稿以后，再把题目、目录、引用列表和正文交给 Codex，从 Stage 0 重新盘点材料，接着跑 Stage 2.5 的完整性检查。

        两套工具可以接在同一条流程里。AIWritePaper 先把项目推到可以继续修改的状态，Codex 再检查来源、修改记录和最终文件。引用、数据、实验和提交责任仍然要由作者确认。