企业官网建设流程全解析

用 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 做：伪造实验记录、编造访谈内容、无中生有产生数据、用“看起来合理”的假引用填充参考文献。这些不是效率问题，是底线问题。

2. 动手前先配好环境：Codex、Skill 目录、最小工作区

2.1 Codex 运行方式和首次启动自检

Codex 有命令行工具，也有桌面端和网页端。常见做法是在项目目录里启动命令行，让 Codex 直接读取项目里的文件。这样它能看到数据、脚本和文档，上下文更完整。

拿到工具之后，不要急着跑论文任务。先做一次“空跑测试”：让它读取项目 README 并总结，或者让它列出当前目录的文件结构。这一步如果正常，说明登录、权限、基础读写都通了，再进真实任务。

如果启动就报错，先按这个顺序查：

1. 账号是不是已经登录，登录状态有没有过期。
2. 你当前账号或订阅允许使用哪些模型，模型标识是否写对。
3. 工具版本和项目里使用的配置格式是否匹配。
4. 是否有服务端在维护或限流，看日志里的具体提示，而不是凭经验瞎改配置。

这里最容易犯的错是一报错就改配置文件，结果问题根本不在配置里。先看日志，日志里通常会写明是认证失败、模型不存在还是超时。

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 里我会写这么几条硬性要求：

1. 原始文件只读，清洗后的文件单独输出。
2. 每个清洗步骤都要写日志，比如“删除了 3 个缺失超过 50% 的字段”。
3. 遇到不确定的规则，列出问题让用户决定，不要自动修正。

输出格式应该是两份东西：清洗后的数据文件，和一个清洗报告。报告里写清楚做了什么、为什么做、影响范围。这份报告以后写数据可用性声明时直接能用。

最忌讳的是让 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 准备输入，第一次只跑一条

拿到一篇新论文时，我建议先做一次“单条链路验证”，不直接上全量数据。

准备步骤：

1. 按上一部分的结构建好项目目录。
2. 在 AGENTS.md 里写清楚项目约定。
3. 把 9 个 skill 放进 skills 目录。
4. 放一份小规模样例数据到 data/raw。
5. 下载目标期刊模板到 manuscript 目录。

然后跑一个最小任务：让 Codex 先读 AGENTS.md，列出项目结构，再定位样例数据。如果它能正确描述数据和文件结构，说明工具链就绪。

不要跳过这一层。直接上真实数据时，一旦 Codex 读错文件或路径，后面所有分析都建立在错误基础上。

5.2 按顺序调用 skill，顺序不要乱

全流程调用顺序，我建议固定为：

1. skill-paper-blueprint 拆结构。
2. skill-data-clean 清洗数据。
3. skill-stats 做统计分析。
4. skill-figure-pub 出图表。
5. skill-code-review 审阅分析代码。
6. skill-reproducibility 做可复现性检查。
7. skill-latex-compile 排版。
8. skill-table-consistency 核对一致性。
9. skill-submission-package 汇总投稿材料。

这个顺序的逻辑是：先有结构，再有干净数据，再分析，再画图，再复现，再排版，最后检查一致性。反过来做，比如先排版再清洗数据，前面任何一步改动，后面都要跟着返工。

每个 skill 执行完，先看输出是否符合自检清单，再进下一个。

5.3 每个阶段先定验收标准

在开始跑之前，就把每个阶段的验收标准定下来，避免跑完不知道算不算成功。