基于Codex Skill的科研论文写作自动化：从空目录到可投稿初稿

最近用 Codex 跑科研论文流程的人明显变多了。原因不复杂：Codex 这类智能体工具能一口气完成文献整理、论文框架、初稿撰写、润色、参考文献格式化和投稿信起草，而这些工作过去至少占掉论文投稿前一周的时间。这篇文章不讨论概念，直接给你一套可以落地的方案——通过自定义 skill 机制，把论文写作流程拆成 9 个可复用模块，然后从空目录开始逐步操作，直到生成一份结构完整、可以按期刊要求投稿的论文初稿。

需要先说清楚“速成”的含义：实验、数据、方法验证必须是你自己完成的，Codex 和 skill 解决的是写作组织、格式规范、语言表达和排版这类流程性问题。它不会替你创造实验数据，也不能掩盖不完整的科研结论。

本文会覆盖：Codex 的安装与登录、skill 的底层机制、9 个论文写作 skill 的逐项编写方法、完整实操流程、第三方模型接入注意事项、资源占用观察和常见故障排查。

1. 核心能力速览

从材料看，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 CLI

npm install -g @openai/codex

安装完成后检查版本：

codex --version

这里要注意：Codex 的更新节奏比较快，安装后一段时间内如果发现命令行为变化，优先查看官方仓库 README 和更新日志，不要沿用旧教程里的过时参数。

3.3 登录与初始化

codex login

登录过程会引导你完成 OpenAI 账号授权。完成登录后，在项目目录里初始化 Codex：

cd 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，覆盖从选题到投稿的全过程：

实际使用时，这 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，再启动 Codex：

export YOUR_API_KEY=sk-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. 常见问题与排查

排查时最有效的方法不是反复重发任务，而是先检查输入素材。多数输出质量问题都出在输入信息不完整上。

9. 最佳实践与合规

写一段能稳定产出高质量论文稿件的技能流程，核心不在于 prompt 技巧有多花哨，而在于流程管理和输入质量。这里给出几条实践原则：

1. 每个 skill 都是“独立单元”。不要把所有论文写作要求塞进一个 skill 文件里，9 个 skill 的模块化结构更容易维护和迁移。
2. 先小范围测试。新写一个 skill 后，不要直接用在正式论文上。先用一段 200 词的示例文本跑一遍，确认输出格式和风格符合预期再正式使用。
3. 输入素材必须人工整理。Codex 在生成论文初稿前，需要知道你的实验结论是什么。素材里的错误会直接扩散到成稿中。
4. 生成结果必须人工复核。特别是结果部分和方法部分，AI 有可能在表达时引入不存在的细节，必须逐句核对实验事实。
5. 参考文献逐条验证。不要直接使用 AI 生成的参考文献列表，投稿前用 Google Scholar、Web of Science、DOI 数据库逐条核对。
6. 注意期刊 AI 使用政策。不同期刊对 AI 辅助写作的披露要求不同。投稿前阅读目标期刊的作者指南，需要声明就在投稿信中声明。
7. 涉及代码和数据开源时，提前确认权利。如果论文附带代码仓库，确认代码中不包含未授权数据、API Key、内部服务器地址。
8. 不要把全稿生成当作一键上稿的按钮。Codex 覆盖了写作层面的 80% 流程，但科研结论的准确性和创新性依然完全属于作者。

实际操作中，我建议把skills/目录做成组内公共资源库。组内成员直接把整个skills/目录拷到自己的论文项目里，再根据期刊要求修改AGENTS.md，就能复用完整的写作流程。后续可以根据实际投稿反馈不断更新每个 skill 的注意事项，形成课题组自己的投稿知识库。

对首次尝试的人，最值得优先验证的三个环节是：draft_imrad 能不能生成结构完整的初稿，polish 能不能保持原意地润色英文，cover_letter 能不能写出一封像样的投稿信。这三个环节跑通后，整套流程就已经进入可用状态。最容易踩的坑则是参考文献编造和 AI 对数据的过度解读，这两点一定要靠人工检查兜底。

下一步可以扩展的方向包括：按具体期刊细分 skill 模板、把投稿信和审稿回复 skill 的指令包装成团队内部工具、或者把 Codex 接入现有的论文管理流程中，让每次生成的结果自动归档到项目目录。