用 Codex 做 SCI 论文最怕的不是 Codex 不会写而是你用错了方向。我连续跑了几轮流程之后结论很明确Codex 最值钱的部分是把论文里最消耗时间的科研工程——数据清洗、统计代码、出版级图表、可复现脚本、LaTeX 排版、图表一致性核对——压缩成一套可复用流程。它不能也不应该取代研究设计、实验数据和结论解读。这篇文章就把我实际沉淀下来的 9 个可复用 skill 完整拆开从环境准备、skill 怎么写、按什么顺序调用到每一步怎么验收、报错怎么排查一次性讲清楚。适合手里已经有实验数据、分析方法基本明确、但被工程细节拖住的研究生和科研工程师。如果你以为把题目丢给 Codex 就能产出一篇直接投稿的 SCI那这篇帮不到你如果你愿意把 AI 当工程助手这篇能帮你省下大量时间。1. 先搞清楚一件事Codex 能提速的是“科研工程”不是“科研结论”1.1 为什么我把目标定成“可投稿的技术链路”而不是“让 AI 替你写论文”一篇论文最后能不能被期刊接收决定因素不是文字顺不顺而是数据是否真实、方法是否严谨、图表是否清晰、结果是否可复现。Codex 在这条链路里的真正优势集中在“执行密集型”环节而不是“知识创造型”环节。语言模型天生擅长生成看起来合理的内容所以它最危险的地方也在这里。如果让它补数据、补显著性、补参考文献它会编得比你还顺畅但这就是学术不端。现在很多期刊已经要求作者声明 AI 使用范围投稿时如果隐瞒后面带来的问题远比省下的那点时间严重。所以我的使用边界非常明确Codex 负责“怎么算、怎么画、怎么排、怎么查”我负责“算得对不对、画得符不符合假设、结论站不站得住”。这篇文章说的“可以直接投稿”意思是通过这套流程论文在格式、图表、代码、数据一致性、材料完整性上达到可投稿状态而不是说跳过实验、跳过审稿、靠 AI 生成内容蒙混过关。1.2 Codex 在论文生产里能碰和不能碰的环节我建议把论文生产拆成两类工作一类是工程执行一类是科学判断。工程执行可以交给 Codex科学判断必须留给自己。环节可以用 Codex 做什么必须人工把关什么数据清洗检查缺失值、异常值、重复行、编码问题生成清洗脚本清洗规则是否引入偏差统计分析运行检验代码、读取输出、生成结果摘要检验前提假设、效应量、样本量是否合理图表绘制写绘图代码、调整坐标轴、配色、尺寸、导出格式图例是否准确、数据点有没有被误标排版编译LaTeX/Word 模板套用、图表编号、参考文献格式对齐作者信息、基金信息、利益冲突声明结论撰写整理结构、润色表达、检查逻辑连贯性研究结论的解释、因果关系判断数据和引用不需要让 AI 生成原始数据或参考文献逐条核对来源和真实性还有一类内容我无论如何都不会让 Codex 做伪造实验记录、编造访谈内容、无中生有产生数据、用“看起来合理”的假引用填充参考文献。这些不是效率问题是底线问题。2. 动手前先配好环境Codex、Skill 目录、最小工作区2.1 Codex 运行方式和首次启动自检Codex 有命令行工具也有桌面端和网页端。常见做法是在项目目录里启动命令行让 Codex 直接读取项目里的文件。这样它能看到数据、脚本和文档上下文更完整。拿到工具之后不要急着跑论文任务。先做一次“空跑测试”让它读取项目 README 并总结或者让它列出当前目录的文件结构。这一步如果正常说明登录、权限、基础读写都通了再进真实任务。如果启动就报错先按这个顺序查账号是不是已经登录登录状态有没有过期。你当前账号或订阅允许使用哪些模型模型标识是否写对。工具版本和项目里使用的配置格式是否匹配。是否有服务端在维护或限流看日志里的具体提示而不是凭经验瞎改配置。这里最容易犯的错是一报错就改配置文件结果问题根本不在配置里。先看日志日志里通常会写明是认证失败、模型不存在还是超时。2.2 skill 是什么、放在哪、怎么写skill 本质上是一组“人写给 Codex 的操作说明书”。一个 skill 通常是一个目录里面放一个说明文件常见命名是 SKILL.md再加上可选的脚本和模板。当你在对话里要求使用某个 skill 时Codex 会按照这个文件里的步骤执行。目录位置一般分两种项目级放在当前项目的 skills 目录下只有这个项目能用。用户级放在全局配置目录下所有项目都能用。具体路径以你当前版本的官方文档为准但核心逻辑一致你想让 Codex 稳定复现一套操作就把这套操作写成 skill只想在一个项目里用就放项目级想所有项目复用就放用户级。一个推荐的 SKILL.md 结构是这样的# skill-name ## 目标 这个 skill 解决什么任务 ## 触发场景 在什么情况下使用 ## 输入要求 需要哪些文件、字段、参数 ## 执行步骤 1. 检查输入是否完整 2. 缺失时提示用户补齐不要自行编造 3. 执行核心流程 4. 输出结果 ## 输出格式 生成什么文件、什么目录结构 ## 自检清单 结果至少满足哪些条件才算成功 ## 常见问题 1. 输入缺失时如何处理 2. 特定报错如何处理写 skill 的关键不只是告诉 Codex“做什么”而是告诉它“怎么做才算完成”。自检清单非常重要它决定了输出质量的上限。2.3 建议的最小工作区结构我建议每个论文项目都统一成下面这个结构paper_project/ ├── AGENTS.md # 给 Codex 看的项目说明 ├── data/ │ ├── raw/ # 原始数据只读 │ └── clean/ # 清洗后的数据 ├── code/ │ ├── analysis/ # 分析脚本 │ └── figures/ # 绘图脚本 ├── figures/ # 最终输出图表 ├── manuscript/ # 论文正文 ├── logs/ # 运行日志 └── skills/ ├── skill-paper-blueprint/ ├── skill-data-clean/ ├── skill-stats/ ├── skill-figure-pub/ ├── skill-reproducibility/ ├── skill-code-review/ ├── skill-latex-compile/ ├── skill-table-consistency/ └── skill-submission-package/这样划分有几个原因。原始数据目录应该只读避免清洗过程中污染源头后面出问题还能追溯。日志目录单独放排查问题时不用翻聊天记录。AGENTS.md 是给 Codex 看的项目约定里面可以写清楚哪些目录不能改、输出命名规则是什么、遇到缺失数据时应该提示而不是补齐。工作区结构越统一skill 就越能复用。换一个项目时把整个目录结构搬过去skill 不需要重写这是“可复用”的真正含义。3. 9 个可复用 Skill 拆解上从数据到图表3.1 skill-paper-blueprint先出一张“论文施工图”很多人一开始就让 Codex 直接写正文这是顺序问题。我先用 skill-paper-blueprint 把整篇论文的结构拆清楚。这个 skill 的输入包括研究背景、数据所在位置、预期图表列表、目标期刊。输出应该是一份“论文施工图”包含章节结构、每节要回答的问题、每张图表对应的数据文件、以及从数据到图表的分析步骤清单。我还会额外要求它输出一张映射表把“数据文件、图表编号、分析脚本”对应起来。这样后面无论谁接手都能快速找到每个结果是从哪个文件、哪段脚本里出来的。这里要注意边界蓝图只能基于你提供的信息来生成。如果输入信息太少它给出的只能是空模板不要让它“脑补”你的研究目标。3.2 skill-data-clean清洗规则和清洗报告分开数据清洗看起来简单实际最容易出问题。常见坑包括文件编码错误、缺失值被当成 0、不同批次数据字段名不一致、重复样本没去重。skill-data-clean 里我会写这么几条硬性要求原始文件只读清洗后的文件单独输出。每个清洗步骤都要写日志比如“删除了 3 个缺失超过 50% 的字段”。遇到不确定的规则列出问题让用户决定不要自动修正。输出格式应该是两份东西清洗后的数据文件和一个清洗报告。报告里写清楚做了什么、为什么做、影响范围。这份报告以后写数据可用性声明时直接能用。最忌讳的是让 Codex 直接改原始数据。一旦改了源头后面统计出任何问题都没法排查。3.3 skill-stats先查假设再谈 p 值统计环节Codex 最大的价值不是替你选方法而是把“选方法 → 跑代码 → 读结果 → 生成报告”这个过程标准化。skill-stats 的输入包括变量类型、分组方式、样本量、研究假设。输出应该包含建议的检验方法、可运行的代码、关键统计量以及结果解读时需要注意的边界。我会在 skill 里强制写一条先检查检验前提假设再报告统计结果。比如 t 检验要看正态性和方差齐性卡方检验要看期望频数回归要看残差分布。Codex 能跑检验但它不会自动判断你的数据适不适合这个检验这个判断必须由你确认。经验是让它在报告里同时输出“方法名称、使用的函数、关键统计量、解读边界”这样投稿时方法部分可以直接对照检查不需要再翻代码。3.4 skill-figure-pub先画小图再调样式出版级绘图是最容易看出工程功底的环节。skill-figure-pub 的输入是数据文件、期望的图型、目标期刊对图片的要求输出是绘图脚本和导出文件。我在 skill 里会写这些参数要求位图导出分辨率不低于 300dpi最好同时导出 PDF 或 SVG 矢量版。字体大小要适配期刊单栏或双栏排版。配色尽量用色盲友好方案不要只靠颜色区分关键信息。多 panel 图要统一坐标轴范围和标签格式。执行顺序上我建议先画一个最简单的单图确认数据读入正确、数值范围正常、坐标轴标签没有乱码再去做多 panel 复杂图。否则图一复杂报错后你很难分清是数据问题还是样式问题。4. 9 个可复用 Skill 拆解下从复现到投稿4.1 skill-reproducibility让结果可以一键重跑可复现性不再是加分项在很多期刊里已经是基本要求。skill-reproducibility 的作用是检查整个项目能不能从 data/raw 出发一步步重新生成所有分析和图表。这个 skill 里我会写这些检查项脚本是否使用固定随机种子重复运行结果是否一致。依赖版本是否记录环境能否还原。是否提供一键运行脚本能从原始数据跑到最终图表。每次重跑是否记录时间和输出哈希。为什么这么看重可复现因为投稿后审稿人可能要求看原始数据和分析脚本甚至要求复现关键结果。一个能一键重跑的项目这时候就是最大的信任背书。不要到最后才做复现检查。从第一天开始每个脚本都按“输入 → 处理 → 输出”拆分后面组合起来才不痛苦。4.2 skill-code-review用代码审阅兜住低级错误分析代码跑通了不代表代码没有问题。skill-code-review 让 Codex 以审阅者的视角检查代码找出硬编码路径、未处理异常、变量名混乱、重复逻辑、注释缺失等问题。输出格式建议是问题清单按严重程度分级每个问题附带修改建议。需要注意边界代码能跑通只能说明语法和逻辑没有明显错误不代表分析方法是正确的。方法学问题还是要靠你自己理解。这个 skill 的价值是兜住低级错误而不是替你判断科学问题。4.3 skill-latex-compile排版和参考文献只对齐不编造排版环节的痛点通常是模板编译不过、图表编号对不上、参考文献格式不符合期刊要求、caption 不规范。skill-latex-compile 的输入是目标期刊模板、正文文件、bib 文件。输出是编译通过的手稿和一份格式检查清单。这里有一条铁律不要让 Codex 自动补参考文献。它一旦觉得引用不够很可能编造出格式完美但根本不存在的文献。参考文献必须来自你自己提供的 bib 文件。如果发现有引用了但 bib 里没有条目让 Codex 标记出来由你去确认补录而不是让它“顺手补上”。我会把目标期刊的模板文件和官方样例 PDF 放进项目里让 Codex 以样例为准对齐格式。这样比口头描述“仿宋、小四、双倍行距”要准确得多。4.4 skill-table-consistency交叉核对正文、图表和数据审稿人最容易抓的问题就是数字对不上正文里写了一个百分比图里画的是另一个值表里又出现第三个数字。人工检查这类问题非常费眼而且很容易漏。skill-table-consistency 的输入是正文、图表文件、对应数据文件。输出是一张交叉核对表把每个指标在正文、图、表、原始数据中的值列出来不一致的用标记指出。这个 skill 能复用是因为它的核心逻辑固定提取数值 → 对齐字段 → 比对差异 → 输出报告。经验是论文里同一个指标在多个地方出现时尽量从同一个变量生成不要手动复制粘贴。手动复制一次就增加一次出错概率。4.5 skill-submission-package材料包是模板不是代写投稿前需要 cover letter、response to reviewers 模板、投稿清单等材料。skill-submission-package 的作用是生成这些材料的结构和草稿框架并根据目标期刊快速整理需要准备的文件。但必须强调这是模板不是代写。研究亮点、创新点、对审稿意见的逐条回复这些必须来自你真实的工作和判断。Codex 可以做的是帮你组织语言、检查结构是否完整、提醒你哪些材料缺失。投稿状态和期刊政策经常变化所以这个 skill 的产出要以你目标期刊投稿系统的最新要求为准不要把模板当成最终版本直接用。5. 一次全流程实操从实验数据到一个可投稿版本5.1 准备输入第一次只跑一条拿到一篇新论文时我建议先做一次“单条链路验证”不直接上全量数据。准备步骤按上一部分的结构建好项目目录。在 AGENTS.md 里写清楚项目约定。把 9 个 skill 放进 skills 目录。放一份小规模样例数据到 data/raw。下载目标期刊模板到 manuscript 目录。然后跑一个最小任务让 Codex 先读 AGENTS.md列出项目结构再定位样例数据。如果它能正确描述数据和文件结构说明工具链就绪。不要跳过这一层。直接上真实数据时一旦 Codex 读错文件或路径后面所有分析都建立在错误基础上。5.2 按顺序调用 skill顺序不要乱全流程调用顺序我建议固定为skill-paper-blueprint 拆结构。skill-data-clean 清洗数据。skill-stats 做统计分析。skill-figure-pub 出图表。skill-code-review 审阅分析代码。skill-reproducibility 做可复现性检查。skill-latex-compile 排版。skill-table-consistency 核对一致性。skill-submission-package 汇总投稿材料。这个顺序的逻辑是先有结构再有干净数据再分析再画图再复现再排版最后检查一致性。反过来做比如先排版再清洗数据前面任何一步改动后面都要跟着返工。每个 skill 执行完先看输出是否符合自检清单再进下一个。5.3 每个阶段先定验收标准在开始跑之前就把每个阶段的验收标准定下来避免跑完不知道算不算成功。阶段验收标准blueprint有“数据 ↔ 图表 ↔ 脚本”映射表> 用Codex打造SCI论文可复用工作流：9个Skill全拆解
用 Codex 做 SCI 论文最怕的不是 Codex 不会写而是你用错了方向。我连续跑了几轮流程之后结论很明确Codex 最值钱的部分是把论文里最消耗时间的科研工程——数据清洗、统计代码、出版级图表、可复现脚本、LaTeX 排版、图表一致性核对——压缩成一套可复用流程。它不能也不应该取代研究设计、实验数据和结论解读。这篇文章就把我实际沉淀下来的 9 个可复用 skill 完整拆开从环境准备、skill 怎么写、按什么顺序调用到每一步怎么验收、报错怎么排查一次性讲清楚。适合手里已经有实验数据、分析方法基本明确、但被工程细节拖住的研究生和科研工程师。如果你以为把题目丢给 Codex 就能产出一篇直接投稿的 SCI那这篇帮不到你如果你愿意把 AI 当工程助手这篇能帮你省下大量时间。1. 先搞清楚一件事Codex 能提速的是“科研工程”不是“科研结论”1.1 为什么我把目标定成“可投稿的技术链路”而不是“让 AI 替你写论文”一篇论文最后能不能被期刊接收决定因素不是文字顺不顺而是数据是否真实、方法是否严谨、图表是否清晰、结果是否可复现。Codex 在这条链路里的真正优势集中在“执行密集型”环节而不是“知识创造型”环节。语言模型天生擅长生成看起来合理的内容所以它最危险的地方也在这里。如果让它补数据、补显著性、补参考文献它会编得比你还顺畅但这就是学术不端。现在很多期刊已经要求作者声明 AI 使用范围投稿时如果隐瞒后面带来的问题远比省下的那点时间严重。所以我的使用边界非常明确Codex 负责“怎么算、怎么画、怎么排、怎么查”我负责“算得对不对、画得符不符合假设、结论站不站得住”。这篇文章说的“可以直接投稿”意思是通过这套流程论文在格式、图表、代码、数据一致性、材料完整性上达到可投稿状态而不是说跳过实验、跳过审稿、靠 AI 生成内容蒙混过关。1.2 Codex 在论文生产里能碰和不能碰的环节我建议把论文生产拆成两类工作一类是工程执行一类是科学判断。工程执行可以交给 Codex科学判断必须留给自己。环节可以用 Codex 做什么必须人工把关什么数据清洗检查缺失值、异常值、重复行、编码问题生成清洗脚本清洗规则是否引入偏差统计分析运行检验代码、读取输出、生成结果摘要检验前提假设、效应量、样本量是否合理图表绘制写绘图代码、调整坐标轴、配色、尺寸、导出格式图例是否准确、数据点有没有被误标排版编译LaTeX/Word 模板套用、图表编号、参考文献格式对齐作者信息、基金信息、利益冲突声明结论撰写整理结构、润色表达、检查逻辑连贯性研究结论的解释、因果关系判断数据和引用不需要让 AI 生成原始数据或参考文献逐条核对来源和真实性还有一类内容我无论如何都不会让 Codex 做伪造实验记录、编造访谈内容、无中生有产生数据、用“看起来合理”的假引用填充参考文献。这些不是效率问题是底线问题。2. 动手前先配好环境Codex、Skill 目录、最小工作区2.1 Codex 运行方式和首次启动自检Codex 有命令行工具也有桌面端和网页端。常见做法是在项目目录里启动命令行让 Codex 直接读取项目里的文件。这样它能看到数据、脚本和文档上下文更完整。拿到工具之后不要急着跑论文任务。先做一次“空跑测试”让它读取项目 README 并总结或者让它列出当前目录的文件结构。这一步如果正常说明登录、权限、基础读写都通了再进真实任务。如果启动就报错先按这个顺序查账号是不是已经登录登录状态有没有过期。你当前账号或订阅允许使用哪些模型模型标识是否写对。工具版本和项目里使用的配置格式是否匹配。是否有服务端在维护或限流看日志里的具体提示而不是凭经验瞎改配置。这里最容易犯的错是一报错就改配置文件结果问题根本不在配置里。先看日志日志里通常会写明是认证失败、模型不存在还是超时。2.2 skill 是什么、放在哪、怎么写skill 本质上是一组“人写给 Codex 的操作说明书”。一个 skill 通常是一个目录里面放一个说明文件常见命名是 SKILL.md再加上可选的脚本和模板。当你在对话里要求使用某个 skill 时Codex 会按照这个文件里的步骤执行。目录位置一般分两种项目级放在当前项目的 skills 目录下只有这个项目能用。用户级放在全局配置目录下所有项目都能用。具体路径以你当前版本的官方文档为准但核心逻辑一致你想让 Codex 稳定复现一套操作就把这套操作写成 skill只想在一个项目里用就放项目级想所有项目复用就放用户级。一个推荐的 SKILL.md 结构是这样的# skill-name ## 目标 这个 skill 解决什么任务 ## 触发场景 在什么情况下使用 ## 输入要求 需要哪些文件、字段、参数 ## 执行步骤 1. 检查输入是否完整 2. 缺失时提示用户补齐不要自行编造 3. 执行核心流程 4. 输出结果 ## 输出格式 生成什么文件、什么目录结构 ## 自检清单 结果至少满足哪些条件才算成功 ## 常见问题 1. 输入缺失时如何处理 2. 特定报错如何处理写 skill 的关键不只是告诉 Codex“做什么”而是告诉它“怎么做才算完成”。自检清单非常重要它决定了输出质量的上限。2.3 建议的最小工作区结构我建议每个论文项目都统一成下面这个结构paper_project/ ├── AGENTS.md # 给 Codex 看的项目说明 ├── data/ │ ├── raw/ # 原始数据只读 │ └── clean/ # 清洗后的数据 ├── code/ │ ├── analysis/ # 分析脚本 │ └── figures/ # 绘图脚本 ├── figures/ # 最终输出图表 ├── manuscript/ # 论文正文 ├── logs/ # 运行日志 └── skills/ ├── skill-paper-blueprint/ ├── skill-data-clean/ ├── skill-stats/ ├── skill-figure-pub/ ├── skill-reproducibility/ ├── skill-code-review/ ├── skill-latex-compile/ ├── skill-table-consistency/ └── skill-submission-package/这样划分有几个原因。原始数据目录应该只读避免清洗过程中污染源头后面出问题还能追溯。日志目录单独放排查问题时不用翻聊天记录。AGENTS.md 是给 Codex 看的项目约定里面可以写清楚哪些目录不能改、输出命名规则是什么、遇到缺失数据时应该提示而不是补齐。工作区结构越统一skill 就越能复用。换一个项目时把整个目录结构搬过去skill 不需要重写这是“可复用”的真正含义。3. 9 个可复用 Skill 拆解上从数据到图表3.1 skill-paper-blueprint先出一张“论文施工图”很多人一开始就让 Codex 直接写正文这是顺序问题。我先用 skill-paper-blueprint 把整篇论文的结构拆清楚。这个 skill 的输入包括研究背景、数据所在位置、预期图表列表、目标期刊。输出应该是一份“论文施工图”包含章节结构、每节要回答的问题、每张图表对应的数据文件、以及从数据到图表的分析步骤清单。我还会额外要求它输出一张映射表把“数据文件、图表编号、分析脚本”对应起来。这样后面无论谁接手都能快速找到每个结果是从哪个文件、哪段脚本里出来的。这里要注意边界蓝图只能基于你提供的信息来生成。如果输入信息太少它给出的只能是空模板不要让它“脑补”你的研究目标。3.2 skill-data-clean清洗规则和清洗报告分开数据清洗看起来简单实际最容易出问题。常见坑包括文件编码错误、缺失值被当成 0、不同批次数据字段名不一致、重复样本没去重。skill-data-clean 里我会写这么几条硬性要求原始文件只读清洗后的文件单独输出。每个清洗步骤都要写日志比如“删除了 3 个缺失超过 50% 的字段”。遇到不确定的规则列出问题让用户决定不要自动修正。输出格式应该是两份东西清洗后的数据文件和一个清洗报告。报告里写清楚做了什么、为什么做、影响范围。这份报告以后写数据可用性声明时直接能用。最忌讳的是让 Codex 直接改原始数据。一旦改了源头后面统计出任何问题都没法排查。3.3 skill-stats先查假设再谈 p 值统计环节Codex 最大的价值不是替你选方法而是把“选方法 → 跑代码 → 读结果 → 生成报告”这个过程标准化。skill-stats 的输入包括变量类型、分组方式、样本量、研究假设。输出应该包含建议的检验方法、可运行的代码、关键统计量以及结果解读时需要注意的边界。我会在 skill 里强制写一条先检查检验前提假设再报告统计结果。比如 t 检验要看正态性和方差齐性卡方检验要看期望频数回归要看残差分布。Codex 能跑检验但它不会自动判断你的数据适不适合这个检验这个判断必须由你确认。经验是让它在报告里同时输出“方法名称、使用的函数、关键统计量、解读边界”这样投稿时方法部分可以直接对照检查不需要再翻代码。3.4 skill-figure-pub先画小图再调样式出版级绘图是最容易看出工程功底的环节。skill-figure-pub 的输入是数据文件、期望的图型、目标期刊对图片的要求输出是绘图脚本和导出文件。我在 skill 里会写这些参数要求位图导出分辨率不低于 300dpi最好同时导出 PDF 或 SVG 矢量版。字体大小要适配期刊单栏或双栏排版。配色尽量用色盲友好方案不要只靠颜色区分关键信息。多 panel 图要统一坐标轴范围和标签格式。执行顺序上我建议先画一个最简单的单图确认数据读入正确、数值范围正常、坐标轴标签没有乱码再去做多 panel 复杂图。否则图一复杂报错后你很难分清是数据问题还是样式问题。4. 9 个可复用 Skill 拆解下从复现到投稿4.1 skill-reproducibility让结果可以一键重跑可复现性不再是加分项在很多期刊里已经是基本要求。skill-reproducibility 的作用是检查整个项目能不能从 data/raw 出发一步步重新生成所有分析和图表。这个 skill 里我会写这些检查项脚本是否使用固定随机种子重复运行结果是否一致。依赖版本是否记录环境能否还原。是否提供一键运行脚本能从原始数据跑到最终图表。每次重跑是否记录时间和输出哈希。为什么这么看重可复现因为投稿后审稿人可能要求看原始数据和分析脚本甚至要求复现关键结果。一个能一键重跑的项目这时候就是最大的信任背书。不要到最后才做复现检查。从第一天开始每个脚本都按“输入 → 处理 → 输出”拆分后面组合起来才不痛苦。4.2 skill-code-review用代码审阅兜住低级错误分析代码跑通了不代表代码没有问题。skill-code-review 让 Codex 以审阅者的视角检查代码找出硬编码路径、未处理异常、变量名混乱、重复逻辑、注释缺失等问题。输出格式建议是问题清单按严重程度分级每个问题附带修改建议。需要注意边界代码能跑通只能说明语法和逻辑没有明显错误不代表分析方法是正确的。方法学问题还是要靠你自己理解。这个 skill 的价值是兜住低级错误而不是替你判断科学问题。4.3 skill-latex-compile排版和参考文献只对齐不编造排版环节的痛点通常是模板编译不过、图表编号对不上、参考文献格式不符合期刊要求、caption 不规范。skill-latex-compile 的输入是目标期刊模板、正文文件、bib 文件。输出是编译通过的手稿和一份格式检查清单。这里有一条铁律不要让 Codex 自动补参考文献。它一旦觉得引用不够很可能编造出格式完美但根本不存在的文献。参考文献必须来自你自己提供的 bib 文件。如果发现有引用了但 bib 里没有条目让 Codex 标记出来由你去确认补录而不是让它“顺手补上”。我会把目标期刊的模板文件和官方样例 PDF 放进项目里让 Codex 以样例为准对齐格式。这样比口头描述“仿宋、小四、双倍行距”要准确得多。4.4 skill-table-consistency交叉核对正文、图表和数据审稿人最容易抓的问题就是数字对不上正文里写了一个百分比图里画的是另一个值表里又出现第三个数字。人工检查这类问题非常费眼而且很容易漏。skill-table-consistency 的输入是正文、图表文件、对应数据文件。输出是一张交叉核对表把每个指标在正文、图、表、原始数据中的值列出来不一致的用标记指出。这个 skill 能复用是因为它的核心逻辑固定提取数值 → 对齐字段 → 比对差异 → 输出报告。经验是论文里同一个指标在多个地方出现时尽量从同一个变量生成不要手动复制粘贴。手动复制一次就增加一次出错概率。4.5 skill-submission-package材料包是模板不是代写投稿前需要 cover letter、response to reviewers 模板、投稿清单等材料。skill-submission-package 的作用是生成这些材料的结构和草稿框架并根据目标期刊快速整理需要准备的文件。但必须强调这是模板不是代写。研究亮点、创新点、对审稿意见的逐条回复这些必须来自你真实的工作和判断。Codex 可以做的是帮你组织语言、检查结构是否完整、提醒你哪些材料缺失。投稿状态和期刊政策经常变化所以这个 skill 的产出要以你目标期刊投稿系统的最新要求为准不要把模板当成最终版本直接用。5. 一次全流程实操从实验数据到一个可投稿版本5.1 准备输入第一次只跑一条拿到一篇新论文时我建议先做一次“单条链路验证”不直接上全量数据。准备步骤按上一部分的结构建好项目目录。在 AGENTS.md 里写清楚项目约定。把 9 个 skill 放进 skills 目录。放一份小规模样例数据到 data/raw。下载目标期刊模板到 manuscript 目录。然后跑一个最小任务让 Codex 先读 AGENTS.md列出项目结构再定位样例数据。如果它能正确描述数据和文件结构说明工具链就绪。不要跳过这一层。直接上真实数据时一旦 Codex 读错文件或路径后面所有分析都建立在错误基础上。5.2 按顺序调用 skill顺序不要乱全流程调用顺序我建议固定为skill-paper-blueprint 拆结构。skill-data-clean 清洗数据。skill-stats 做统计分析。skill-figure-pub 出图表。skill-code-review 审阅分析代码。skill-reproducibility 做可复现性检查。skill-latex-compile 排版。skill-table-consistency 核对一致性。skill-submission-package 汇总投稿材料。这个顺序的逻辑是先有结构再有干净数据再分析再画图再复现再排版最后检查一致性。反过来做比如先排版再清洗数据前面任何一步改动后面都要跟着返工。每个 skill 执行完先看输出是否符合自检清单再进下一个。5.3 每个阶段先定验收标准在开始跑之前就把每个阶段的验收标准定下来避免跑完不知道算不算成功。阶段验收标准blueprint有“数据 ↔ 图表 ↔ 脚本”映射表>