最近用 Codex 跑科研论文流程的人明显变多了。原因不复杂Codex 这类智能体工具能一口气完成文献整理、论文框架、初稿撰写、润色、参考文献格式化和投稿信起草而这些工作过去至少占掉论文投稿前一周的时间。这篇文章不讨论概念直接给你一套可以落地的方案——通过自定义 skill 机制把论文写作流程拆成 9 个可复用模块然后从空目录开始逐步操作直到生成一份结构完整、可以按期刊要求投稿的论文初稿。需要先说清楚“速成”的含义实验、数据、方法验证必须是你自己完成的Codex 和 skill 解决的是写作组织、格式规范、语言表达和排版这类流程性问题。它不会替你创造实验数据也不能掩盖不完整的科研结论。本文会覆盖Codex 的安装与登录、skill 的底层机制、9 个论文写作 skill 的逐项编写方法、完整实操流程、第三方模型接入注意事项、资源占用观察和常见故障排查。1. 核心能力速览能力项说明项目类型基于 OpenAI Codex 的科研论文写作自动化流程核心功能文献梳理、论文框架、初稿撰写、润色、参考文献、投稿信、审稿回复主要扩展机制Codex Skill通过在项目中放置 skill 目录和说明文件实现安装方式npm 全局安装 Codex CLI或使用桌面端/VSCode 扩展运行环境需要 Node.js 环境无 GPU 要求不需要独立显卡第三方模型接入可通过配置模型供应商接入 OpenAI 兼容接口如 DeepSeek 官方 API批量能力skill 可复用论文各章节可批量生成API 服务Codex CLI 本身是交互式智能体不直接提供 HTTP 服务适合场景科研写作、论文投稿准备、SCI/SSCI 初稿撰写、学术润色从材料看Codex 安装和 skill 编写是这个流程的两个关键点。安装决定了你能不能跑起来skill 决定了论文产出的质量上限。2. 适用场景与使用边界这套流程适合以下人群研究生和科研人员论文初稿写不出来需要有人帮忙把结果“翻译”成学术语言。投稿前需要统一排版和参考文献格式的人不同期刊要求不同引用格式手动调整成本高。需要反复处理同一类写作任务的课题组把 skill 沉淀下来组内成员可以直接复用。准备回复审稿意见的人response letter 是投稿流程中机械性最强但也最需要条理的部分。不适合的场景包括完全没有实验数据和科研结论期望 AI 直接生成一篇“有效论文”的情况。这不合理也不符合学术规范。涉及未公开数据、保密数据和他人未授权数据的情况。Codex 会将上下文发送到模型接口数据保密性和合规性需要你提前确认。需要保证 100% 引用准确性的场景。AI 生成的参考文献存在编造风险逐条核对作者、年份、卷期和页码是必须步骤。有明确 AI 使用限制的期刊或机构。投稿前务必阅读目标期刊的作者指南确认是否允许 AI 辅助写作并在投稿时按规定声明。合规提示论文写作辅助不改变作者责任。实验设计、数据分析、结果解释和最终定稿必须由作者完成涉及图片、数据、代码复现都要保留原始记录。使用 AI 辅助写作时按期刊要求披露工具名称和使用范围。3. 环境准备与安装启动3.1 环境检查Codex CLI 基于 Node.js 运行安装前先检查有没有 Node.js 环境。未安装的先安装 Node.js安装完成后执行node --version npm --version如果两个命令都能输出版本号说明环境正常。建议 Node.js 版本在 18 以上具体以 Codex 当前版本要求为准。3.2 安装 Codex CLInpm install -g openai/codex安装完成后检查版本codex --version这里要注意Codex 的更新节奏比较快安装后一段时间内如果发现命令行为变化优先查看官方仓库 README 和更新日志不要沿用旧教程里的过时参数。3.3 登录与初始化codex login登录过程会引导你完成 OpenAI 账号授权。完成登录后在项目目录里初始化 Codexcd your-paper-project codex init执行后会生成AGENTS.md文件这个文件的内容会被 Codex 当作项目级上下文可以在这里写明项目目标、语言偏好、输出目录和约束条件。如果是桌面端或 VSCode 扩展安装方式略有差异但核心逻辑一样登录账号后在指定项目目录中创建AGENTS.md然后打开对话窗口开始使用。3.4 准备项目目录建议用下面的目录结构管理论文项目your-paper-project/ ├── AGENTS.md ├── skills/ │ ├── define_problem/ │ │ └── SKILL.md │ ├── litreview/ │ │ └── SKILL.md │ ├── methodology/ │ │ └── SKILL.md │ ├── draft_imrad/ │ │ └── SKILL.md │ ├── polish/ │ │ └── SKILL.md │ ├── references/ │ │ └── SKILL.md │ ├── figures/ │ │ └── SKILL.md │ ├── cover_letter/ │ │ └── SKILL.md │ └── response_letter/ │ └── SKILL.md ├── docs/ ├── data/ └── output/skill 目录结构不要求绝对统一关键是让 Codex 能识别到每个 skill 的说明文件。4. Codex skill 机制与 9 个可复用 skill 清单4.1 skill 到底是什么从热词量和社区讨论密度看skill 机制是目前 Codex 最受关注的能力扩展点。简单来说skill 是一段结构化的技术指令放在项目目录中的skills/skill-name/SKILL.md位置。Codex 在对话中读取到 skill 后会按照文件里的步骤、规则和输出格式执行任务。SKILL.md通常包含两部分YAML frontmatter描述 skill 的名称和作用。正文写明输入要求、处理步骤、输出格式和注意事项。一个最小示例--- name: draft_imrad description: 根据方法、结果和图表信息生成 IMRaD 结构论文初稿。 ---正文部分可以这样写## 功能 生成符合目标期刊结构的论文初稿。 ## 输入要求 用户需要提供摘要、研究方法、结果要点、图表编号和投稿期刊名称。 ## 执行步骤 1. 分析输入内容提取关键信息。 2. 按 IMRaD 结构组织章节。 3. 生成正文保持学术语言风格。 4. 输出初稿到 output/ 目录。 ## 输出格式 Markdown 格式标题层级清晰包含图表占位符。 ## 注意事项 - 不解释没有数据支撑的结论。 - 不生成参考文献列表引用标记为 [x] 留待后处理。这个文件写好后在 Codex 对话中输入类似“使用 draft_imrad skill根据已有摘要和结果生成初稿”的指令就会触发对应流程。4.2 9 个 skill 的整体设计我按论文写作流程拆了 9 个 skill覆盖从选题到投稿的全过程序号skill 名称输入输出解决的核心问题1define_problem研究背景、目标、初步结果研究问题定义、创新点、论文定位开头不知道写什么2litreview文献笔记、摘要列表相关工作总结、研究空白分析文献综述写不系统3methodology实验方案、数据采集过程方法部分标准学术表达方法部分逻辑顺序混乱4draft_imrad摘要、方法、结果、图表完整论文初稿从素材到全稿的衔接5polish初稿润色后英文版本中式英语和表达冗余6references引用信息、目标期刊格式化参考文献列表引文格式不统一7figures图表标题、数据、图注图表说明与版式建议图表信息表达不完整8cover_letter论文摘要、目标期刊投稿信草稿投稿信不会写9response_letter审稿意见、回复草稿结构化逐条回复回复审稿意见漏项乱序---------------实际使用时这 9 个 skill 不一定全部执行。文章创新性充足时可以跳过 define_problem初稿语言没问题时可以跳过 polish。但建议至少把 1、2、4、8 四个 skill 放好因为它们是论文投稿的刚需流程。5. 9 个 skill 逐项拆解编写方法这一节给出每个 skill 的编写要点和核心指令你可以直接照这个模板改成自己课题组的版本。5.1 define_problem研究问题定义这是所有 skill 中使用频率最高的一个。写论文卡在第一段时问题通常不是语言能力而是没有把研究问题和创新点说清楚。SKILL.md 核心内容--- name: define_problem description: 基于研究背景和初步结果提取研究问题、创新点和论文定位。 ---正文执行要点要求用户提供 2 到 3 个背景关键词。要求用户描述一个“现有方法做不到”的痛点。要求用户说明本研究提出的解决思路。按“背景 - 缺口 - 本文方法 - 贡献”四段式输出。实际指令示例使用 define_problem skill帮我写一段 Introduction 开篇。 背景关键词高光谱图像分类小样本。 痛点描述现有深度学习方法在小样本条件下容易过拟合。 本文思路提出了基于特征重标定的轻量网络。 目标期刊IEEE GRSL。预期输出是一段可以放进 Introduction 前三段的学术文本同时附带 3 条可替换的改写方向。5.2 litreview文献综述文献综述的难点在于“综述感”——不是逐篇复述文献而是把相关研究按脉络组织起来。这个 skill 的输入最好是整理过的文献笔记。你可以自己手动整理也可以让 Codex 帮你从原始 PDF 摘录中提炼但必须注明出处。SKILL.md 核心指令--- name: litreview description: 根据文献笔记生成结构化的相关研究综述和研究空白分析。 ---正文要求先把文献按方法类别分组不要按年份罗列。每组内先介绍代表性方法再说明其局限。最后一个段落单独写“研究空白”解释现有方法与本文方法的差异。输出时保留参考文献编号 [1]、[2] 等方便后处理。写这个 skill 时最容易被忽视的是分组能力。如果 Codex 把 20 篇文献分成 5 组每组有明确主题句那综述质量就已经超过了大多数初稿。5.3 methodology方法部分方法部分的问题通常不是“写得不好”而是“顺序不对”。常见顺序是实验数据 - 预处理 - 模型/核心步骤 - 评价指标 - 实现细节。SKILL.md 核心指令--- name: methodology description: 将实验方案组织为标准方法部分强调可复现性表达。 ---正文要求每小节必须有明确的小标题。每个公式或参数都需要有单位。涉及模型结构时按“输入 - 处理单元 - 输出”顺序描述。加入“可复现性检查项”是否提到随机种子、训练轮数、学习率、硬件环境和代码地址。方法部分越接近“别人照做能复现”的标准审稿人越难挑毛病。5.4 draft_imrad论文初稿这是最核心的 skill输入是前面三个 skill 的产出。SKILL.md 核心指令--- name: draft_imrad description: 根据研究方法、结果要点和图表信息生成完整论文初稿。 ---正文要求输出必须包含 Title、Abstract、Introduction、Methods、Results、Discussion、Conclusion。Title 给出 3 个备选长度不同方便选择。Abstract 控制在目标期刊要求内默认 250 词以内。Results 部分只描述数据趋势不做过度解释把解释放到 Discussion。图表使用占位符如[Figure 1 about here]并附一句图注建议。实际使用中draft_imrad 生成的初稿长度可能比较可观。如果一次生成超长内容导致截断可以让 Codex 按章节分次生成先 Methods再 Results最后 Introduction 和 Discussion。5.5 polish学术英语润色这个 skill 的定位是“学术表达优化”不是机器翻译。SKILL.md 核心指令--- name: polish description: 对论文初稿进行学术英语润色降低冗余并提升表达准确性。 ---正文要求保留原意不扩展不删减有效信息。将被动句与主动句的分布调整到学术写作习惯。删除“It is worth noting that”这类空洞引导句换成直接表达。每个长句不超过 35 个单词超出的拆分。输出前给出一份“修改说明”列出主要修改类型。这里有一个容易被忽略的点润色后的文本必须由作者逐句确认。机器润色可能改变细微语义特别是涉及“significant”“promising”这类主观判断词时容易造成过度强调。5.6 references参考文献格式化参考文献格式的处理是纯机械劳动但又是投稿前必须做对的事。SKILL.md 核心指令--- name: references description: 根据目标期刊要求格式化参考文献列表。 ---正文要求用户需要提供目标期刊名和参考文献原始信息。输出格式严格按照期刊 Author Guidelines 的要求。逐条对齐字段作者、年份、标题、期刊缩写、卷、期、页码、DOI。标出缺失字段不要自行猜测补全。必须强调的是这个 skill 只做格式整理不负责验证引文真实性。AI 生成的参考文献存在张冠李戴的可能投稿前必须用数据库逐条核对。5.7 figures图表说明与版式建议图表是审稿人最先看的部分。这个 skill 不负责生成图只负责把图的说明写规范。SKILL.md 核心指令--- name: figures description: 根据图表数据和图注要求生成图表说明及版式建议。 ---正文要求图注包含图编号、简短标题、完整描述、统计显著性标记说明。为每张图提供 2 条版式改进建议例如字体大小、配色、坐标轴单位。检查图内文字是否能在期刊单栏宽度下清晰可读。如果图表数据本身不够清晰这个 skill 不能变出高质量图表。它解决的是“图做得没问题但不会写说明”的问题。5.8 cover_letter投稿信投稿信是编辑对你的第一印象模板化程度很高。SKILL.md 核心指令--- name: cover_letter description: 根据论文摘要和期刊要求生成投稿信草稿。 ---正文要求开头写明稿件题目和投稿期刊。中间用一段话说明论文创新点不超过 100 词。写明本文与目标期刊范围的匹配理由。结尾包含标准声明段原创性、未一稿多投、作者同意。输出三版语气正式版、简洁版、强调应用版。5.9 response_letter审稿意见回复这个 skill 可以帮你把审稿意见拆成逐条回复核心是“答复有依据、修改可追溯”。SKILL.md 核心指令--- name: response_letter description: 将审稿意见组织为逐条回复标明修改位置和修改摘要。 ---正文要求按审稿人编号和意见编号逐条整理。每条回复包括感谢审稿人意见 - 复述我方回应 - 说明修改位置 - 给出修改摘要。对“未修改”的意见必须给出合理理由不能直接说“不同意”。输出修改痕迹对照表方便作者在终稿中核对。回复审稿意见时最容易犯的错误是“只回复判断不展示修改”。这个 skill 会把“修改位置”作为必填项从机制上避免这个问题。6. SCI 论文全流程实操从空目录到可投稿草稿6.1 准备项目与素材以一个实际场景为例。假设你的课题是“基于轻量 Transformer 的高光谱图像分类”已经有了实验结果、训练代码和五张图。现在要生成投稿初稿。先创建项目目录并初始化mkdir hs-paper cd hs-paper codex init在AGENTS.md里写入项目说明# 项目说明 这是一个用于高光谱图像分类论文写作的项目。 目标语言英文。 目标期刊IEEE Transactions on Geoscience and Remote Sensing。 输出目录output/。 写作要求结果部分只描述事实不做主观评价。然后创建skills/目录把第 5 节提到的 9 个 skill 放到对应目录。6.2 素材整理在docs/中准备三类输入文件docs/background.md研究背景和动机。docs/experiment_notes.md实验设置、数据集、对比方法、实验结果的要点。docs/figure_list.md每张图的编号、标题、一句内容描述。建议不要直接扔原始输出日志给 Codex先自己提炼成要点效果会好很多。6.3 执行 define_problem进入 Codex 对话使用 define_problem skill。 背景关键词高光谱图像分类轻量网络Transformer。 痛点描述现有注意力模型计算复杂度高在资源受限平台难以部署。 本文思路设计了一种通道-空间双分支压缩注意力机制。Codex 会读取skills/define_problem/SKILL.md然后输出一段 Introduction 开篇文本。6.4 执行 litreview使用 litreview skill。 文献笔记在 docs/background.md。 请按方法类别分组综述最后指出研究空白。这里要求 Codex 输出带编号引用标注的综述例如 “Chen et al. [1] proposed ...”同时确保每个编号可以在参考文献列表中对应。6.5 执行 draft_imrad 生成初稿使用 draft_imrad skill。 摘要、方法和实验结果要点在 docs/experiment_notes.md图表信息在 docs/figure_list.md。 按目标期刊要求生成完整初稿。生成后检查output/目录。初稿中如果包含[Figure 1 about here]这种占位符这是正常现象下一步用具体图注替换即可。6.6 执行 polish 和 references对初稿执行 polish使用 polish skill优化 output/draft.md 的英文表达。 输出润色稿和修改说明。对参考文献执行 references使用 references skill。 参考文献原始信息在 docs/references_raw.md。 目标期刊 IEEE TGRS按期刊格式输出。6.7 生成投稿辅助材料使用 cover_letter skill根据 output/draft.md 生成投稿信。如果后续收到审稿意见使用 response_letter skill。 审稿意见在 docs/review_comments.md我方的修改草稿在 output/revised_draft.md。 按审稿人编号逐条回复。到这里论文初稿、润色稿、参考文献、投稿信和审稿回复材料全部生成完毕。7. 第三方模型接入与资源占用观察7.1 将 Codex 接入 DeepSeek 或其他 OpenAI 兼容接口“codex接入deepseek”这个搜索热词说明很多人在尝试用第三方模型替代默认模型。这个做法可以降低成本也可以利用特定模型的优势但需要满足一个前提目标模型提供 OpenAI 兼容接口。Codex CLI 的配置文件中可以通过模型供应商机制指定第三方模型。下面是一个通用配置模板字段名会随版本变化使用前先确认当前版本支持的字段# ~/.codex/config.toml model your-model-name model_provider your-provider-id model_providers.your-provider-id { name Your Provider, base_url https://api.example.com/v1, env_key YOUR_API_KEY }配置完成后在终端中用环境变量传入 API Key再启动 Codexexport YOUR_API_KEYsk-xxxx codex如果使用 DeepSeek 官方 API就从 DeepSeek 官方开发者平台获取 API Key创建应用后获取 API 地址替换上面的示例值。要特别注意模型名称必须与目标 API 支持的模型名完全一致大小写和连字符都不能错否则会出现类似 “model is not supported” 的报错。第三方模型接入的原则是只使用官方 API 和官方兼容接口不使用来源不明的中转服务或未授权接口。这样可以避免账号密钥泄露和模型结果不稳定问题。7.2 资源占用观察Codex 是云端模型推理本地不需要 GPU 显存对机器性能要求不高。需要观察的资源主要是Token 消耗每次对话都会消耗大量上下文 token长论文项目尤其明显。生成时长初稿生成比单段润色要慢但整体在可接受范围。本地磁盘占用Codex CLI 和依赖包占用通常不大主要占用是项目素材和输出文件。降低 token 占用的方法每个 skill 单独执行不要把所有任务放在一个超长对话里。输入素材先精简优先给出结论性要点而不是全文。一个 skill 完成后新开一个对话再执行下一个 skill减少历史上下文堆积。这样做的另一个好处是每个环节都有独立的输入输出方便审计修改哪个环节出问题就直接重建那个环节。8. 常见问题与排查问题现象可能原因排查方式解决方案安装时提示权限不足npm 全局目录无写权限查看报错信息中的目录路径使用管理员权限执行或配置 npm 全局路径codex 命令找不到安装失败或 PATH 未配置执行 npm ls -g --depth0重新安装检查 PATH 环境变量登录后无法使用账号权限不足或网络连接问题查看登录状态和错误日志使用受支持的账号类型确认网络能访问对应接口模型提示 not supported模型名称与接口不匹配查看 API 支持模型列表修改 model 字段为接口支持的准确名称第三方接口连接失败Base URL 填错、API Key 无效或服务不稳定用 curl 直接测试接口地址核对官方 API 文档重新配置API 调用报错Key 过期或余额不足检查开发者平台账号状态更新 Key确认余额和配额生成内容被截断上下文过长或输出超限检查输出尾部是否有截断标记分章节生成控制单次任务范围输出结果不相关指令不明确或 skill 文件缺失确认是否执行了对应 skill完善 SKILL.md重新描述任务目标参考文献疑似编造模型生成引用时补全了缺失信息抽查 DOI 和作者用数据库逐条核对参考文献不依赖 AI 引用润色改变原意上下文信息不足对比润色前后版本增加上下文明确要求“保留原意不扩展内容”排查时最有效的方法不是反复重发任务而是先检查输入素材。多数输出质量问题都出在输入信息不完整上。9. 最佳实践与合规写一段能稳定产出高质量论文稿件的技能流程核心不在于 prompt 技巧有多花哨而在于流程管理和输入质量。这里给出几条实践原则每个 skill 都是“独立单元”。不要把所有论文写作要求塞进一个 skill 文件里9 个 skill 的模块化结构更容易维护和迁移。先小范围测试。新写一个 skill 后不要直接用在正式论文上。先用一段 200 词的示例文本跑一遍确认输出格式和风格符合预期再正式使用。输入素材必须人工整理。Codex 在生成论文初稿前需要知道你的实验结论是什么。素材里的错误会直接扩散到成稿中。生成结果必须人工复核。特别是结果部分和方法部分AI 有可能在表达时引入不存在的细节必须逐句核对实验事实。参考文献逐条验证。不要直接使用 AI 生成的参考文献列表投稿前用 Google Scholar、Web of Science、DOI 数据库逐条核对。注意期刊 AI 使用政策。不同期刊对 AI 辅助写作的披露要求不同。投稿前阅读目标期刊的作者指南需要声明就在投稿信中声明。涉及代码和数据开源时提前确认权利。如果论文附带代码仓库确认代码中不包含未授权数据、API Key、内部服务器地址。不要把全稿生成当作一键上稿的按钮。Codex 覆盖了写作层面的 80% 流程但科研结论的准确性和创新性依然完全属于作者。实际操作中我建议把skills/目录做成组内公共资源库。组内成员直接把整个skills/目录拷到自己的论文项目里再根据期刊要求修改AGENTS.md就能复用完整的写作流程。后续可以根据实际投稿反馈不断更新每个 skill 的注意事项形成课题组自己的投稿知识库。对首次尝试的人最值得优先验证的三个环节是draft_imrad 能不能生成结构完整的初稿polish 能不能保持原意地润色英文cover_letter 能不能写出一封像样的投稿信。这三个环节跑通后整套流程就已经进入可用状态。最容易踩的坑则是参考文献编造和 AI 对数据的过度解读这两点一定要靠人工检查兜底。下一步可以扩展的方向包括按具体期刊细分 skill 模板、把投稿信和审稿回复 skill 的指令包装成团队内部工具、或者把 Codex 接入现有的论文管理流程中让每次生成的结果自动归档到项目目录。