| >node -v npm -v 确认环境后，执行全局安装： npm install -g @openai/codex codex --version
具体安装包名称和安装命令要以官方 README 为准，这里展示的是通用安装思路。如果安装失败，优先检查 Node.js 版本是否过低、npm 镜像是否正常、是否缺少系统编译工具。 安装后需要认证。常见方式是准备一个合法的 API key： export OPENAI_API_KEY="你的合法密钥"
不要把这个 key 写进项目目录、不要提交到 Git。生产环境应该使用密钥管理服务或 CI 变量注入。如果你是组织用户，需要按组织的访问方式配置认证。 如果使用兼容 OpenAI SDK 的模型服务，可以在 Codex 配置文件中为模型 provider 声明 base_url 和模型名。这类配置属于正常的模型接入方式，但前提是你拥有合法访问权限。模型必须支持工具调用，否则 skill 加载会不稳定。如果运行时出现"the 'gpt-5.6-sol' model is not supported"一类提示，通常是模型名称或 provider 配置与当前 Codex 版本不匹配，需要回到配置中核对，而不是继续执行任务。 2.2 初始化科研 skill 工程目录推荐在论文项目根目录下建立如下结构： paper-project/ ├── AGENTS.md ├── skills/ │ ├── literature-review/SKILL.md │ ├── research-design/SKILL.md │ ├──># 项目约定 - 本项目用于 SCI 论文投稿前的数据分析和稿件整理。 - 原始数据只允许读取 data/raw 目录，不允许修改。 - 所有生成脚本写入 code 目录。 - 分析结果写入 results 目录。 - 生成稿件写入 manuscript 目录。 - 任何 AI 生成内容都需要人工复核后再进入 submission 目录。
skills目录下每个 skill 一个子目录，目录名就是 skill 名。SKILL.md是这个 skill 的指令文件。建议为每个 skill 再增加README.md记录设计原因和参数说明，但这并不是必须的。
2.3 编写第一个可加载 skill：格式检查以format-check为例，先写一个最小可用的SKILL.md： --- name: format-check description: 检查 manuscript 目录中的稿件是否满足常见投稿格式要求。 version: 1.0.0 --- # format-check ## 输入 - 稿件路径：manuscript/paper.md - 期刊要求文件：target-journal.txt ## 检查项 1. 标题、摘要、关键词是否存在。 2. 正文是否包含引言、方法、结果、讨论四个部分。 3. 图表编号是否连续，是否在正文中被引用。 4. 参考文献格式是否与目标期刊要求一致。 5. 缩写是否在首次出现时给出全称。 6. 是否缺少伦理声明、利益冲突、数据可用性声明。 7. 正文字数是否超过期刊限制。 ## 输出 - 生成 submission/format-check-report.md。 - 按严重程度列出问题，严重问题标记为 blocking，建议问题标记为 suggestion。 ## 约束 - 只检查文件，不修改稿件内容。 - 涉及字数统计时，需要排除参考文献、图表标题和声明部分。
description字段非常关键。Codex 会根据 description 判断何时加载这个 skill。描述越具体，越不容易误触发。代码块里的“输入”“输出”“约束”是给模型的执行规范，内容越可验证越好。
2.4 验证 skill 是否被正确加载在项目根目录运行： cd paper-project codex "运行 format-check skill，检查 manuscript/paper.md"
观察 Codex 是否提到读取了skills/format-check/SKILL.md。如果没有任何反应，可以先用一条更直接的指令验证： codex "这个项目里有哪些 skill？逐个说明作用。"
如果列不出来，优先检查三处：skill 文件名和目录名是否一致，SKILL.md的 frontmatter 是否完整，当前 Codex 版本是否支持自定义 skill 加载。不要带着一个未验证的 skill 进入正式流程，否则后面所有自动化假设都会失效。 3. 9 个可复用 skill 的落地实现3.1 文献检索 skill：把研究问题变成检索方案文献综述不是让 AI 直接写“某某领域已有大量研究”。更可靠的做法是让 AI 生成可执行的检索方案。literature-review的SKILL.md可以这样设计： --- name: literature-review description: 根据研究主题生成 PubMed、Web of Science、Scopus 可用的检索式，并输出文献筛选计划。 version: 1.0.0 --- # literature-review ## 输入 - 研究主题文件：instructions/study-topic.md ## 任务 1. 把研究主题拆解为 PICOS 结构。 2. 为每个数据库生成检索式，使用主题词和自由词组合。 3. 给出纳入和排除标准。 4. 输出去重和筛选流程。 ## 输出 - 生成 results/literature-search-plan.md。 - 检索式必须包含布尔逻辑、括号和字段标记。 ## 约束 - 不编造文献。如果模型记忆中的文献无法核对，必须标记为“待人工核对”。 - 最终文献列表必须由人工在真实数据库中执行检索后填入。
执行方式： echo "研究主题：某干预对某疾病结局的影响" > instructions/study-topic.md codex "读取 instructions/study-topic.md，运行 literature-review skill"
验证产出时，重点看检索式是否能直接在 PubMed 中执行，筛选标准是否可以被另一个学生重复判断。AI 在这里最有用的部分是生成布尔式组合和 PICOS 拆解，而不是替你决定哪些文献重要。 3.2 统计分析与图表 skill：让数据产出可复现结果>import pandas as pd from scipy import stats df = pd.read_csv("data/raw/exp.csv") desc = df.groupby("group")["score"].describe() desc.to_csv("results/analysis/descriptive_stats.csv") # 正态性检验，决定后续使用参数检验还是非参数检验 stat, p = stats.shapiro(df["score"]) print(f"Shapiro-Wilk p = {p:.4f}") group_a = df.loc[df["group"] == "A", "score"] group_b = df.loc[df["group"] == "B", "score"] # 如果两组正态且方差齐，使用独立样本 t 检验，否则使用 Mann-Whitney U 检验 t_stat, p_value = stats.ttest_ind(group_a, group_b, equal_var=True) print(f"t = {t_stat:.3f}, p = {p_value:.4f}")
把这段代码放到code/analysis.py，然后运行： python code/analysis.py
这个流程的关键是：先检验数据分布，再选择检验方法；不能跳过正态性检验直接跑 t 检验。>import matplotlib.pyplot as plt import pandas as pd plt.rcParams.update({ "font.size": 9, "axes.titlesize": 10, "figure.dpi": 300, }) df = pd.read_csv("data/raw/exp.csv") fig, ax = plt.subplots() df.boxplot(column="score", by="group", ax=ax) ax.set_xlabel("Group") ax.set_ylabel("Score") fig.savefig("figures/score_by_group.pdf", bbox_inches="tight") 图片规范建议用表格记录： | 检查项 | 常见要求 | 说明 |
|---|
| 格式 | PDF、TIFF 或 EPS | 避免投稿后出现位图模糊 | | 分辨率 | 300 dpi 以上 | 印刷需要更高分辨率 | | 字体 | 统一字体、7-10 pt | 图内文字不宜过大或过小 | | 配色 | 考虑黑白打印 | 不要只依赖颜色区分分组 | | 图注 | 独立于图片 | 投稿时图注通常单独提交 |
3.3 论文写作与润色 skill：从草稿到期刊语言paper-writing的设计重点是防幻觉。它不能凭空生成方法，而是必须基于项目里的实验记录。一个推荐结构：
--- name: paper-writing description: 基于实验记录和结果文件生成 IMRaD 结构的稿件章节。 version: 1.0.0 --- # paper-writing ## 输入 - notes/experiment-notes.md - results/key-numbers.md - target-journal.txt ## 输出 - manuscript/methods.md - manuscript/results.md - manuscript/introduction.md - manuscript/discussion.md ## 约束 - methods 只能复述 notes 中已经出现的实验参数。 - results 中的数字必须与 results/key-numbers.md 一致。 - discussion 中区分“数据支持的解释”和“推测”，推测部分必须明确标注。
先准备两个输入文件：notes/experiment-notes.md记录真实实验步骤，results/key-numbers.md记录关键结果数字。然后执行： codex "运行 paper-writing skill，生成稿件章节到 manuscript 目录"
完成后，人工检查方法部分是否有 notes 中不存在的参数。AI 很容易补上“室温静置 30 分钟”这类细节，但如果实验记录里没有写，就必须删除。 abstract-polish聚焦摘要润色。它适合把已经写好的摘要压缩到目标期刊字数，并检查 background、methods、results、conclusion 四要素是否齐全。示例输入可以是：
目标字数：250 当前摘要：...
skill 的输出应该是修改后的摘要和修改说明。这里不要使用“AI 摘要看起来更高级就直接替换”的思路，作者必须逐句对照原意是否改变。 3.4 投稿材料 skill：Cover Letter 与审稿回复cover-letter的SKILL.md可以要求输出以下结构：
--- name: cover-letter description: 根据稿件亮点和目标期刊要求生成投稿 Cover Letter 草稿。 version: 1.0.0 --- # cover-letter ## 输入 - 稿件摘要：manuscript/abstract.md - 目标期刊说明：target-journal.txt - 通讯作者信息：notes/author-info.md ## 输出 - 生成 submission/cover-letter.md ## 内容要求 1. 问候编辑，使用期刊允许的称呼。 2. 一句话说明研究主题和创新点。 3. 说明为什么适合该期刊，而不是泛泛说“影响力高”。 4. 声明稿件原创性、无利益冲突、所有作者已审阅。 5. 提供通讯作者联系方式。 ## 约束 - 不使用夸大措辞，例如“首次”“重大突破”必须有证据支撑。
reviewer-response用于返修阶段。它要求读取审稿意见，输出逐条回复文档。一个可复用的表格结构如下：
| 审稿意见编号 | 问题摘要 | 修改位置 | 修改说明 | 是否完成 | | --- | --- | --- | --- | --- | | R1-1 | 样本量较小 | 方法、讨论 | 补充局限性分析 | 已完成 | | R1-2 | 缺少稳定性实验 | 待补充 | 需要补做实验 | 未完成，计划 2 周内完成 |
reviewer-response的最大价值是让回复结构清晰、逐条闭环。但它不能代替作者判断是否真的需要补实验。如果审稿人要求补充数据，而实验室没有做，AI 不能替你编造“我们补充了实验”。这一点必须写进 skill 的约束。
3.5 参数说明与 skill 维护方式编写SKILL.md时，常用字段可以做一张速查表： | 字段 | 作用 | 写好建议 |
|---|
| name | skill 标识 | 用小写连字符，和目录名一致 | | description | 决定何时加载 | 写清输入条件和任务边界 | | version | 版本管理 | 修改规则后递增版本号 | | 输入 | 前置条件 | 写清文件路径和格式 | | 输出 | 交付物 | 写清目录和文件格式 | | 约束 | 防幻觉和防误操作 | 每条都可验证 | | 检查点 | 执行后的自检方式 | 给命令或文件内容示例 |
不要每次使用都临时改SKILL.md。要改就记录变更原因，放进 Git 提交信息。skill 是给团队复用的资产，不是个人聊天记录。 4. 全流程实操：从数据到投稿前检查的一次完整运行4.1 阶段一：用文献 skill 整理研究背景先建立instructions/study-topic.md，写入研究主题和背景。然后执行： codex "读取 instructions/study-topic.md，运行 literature-review skill"
验证results/literature-search-plan.md中是否包含 PICOS 拆解、数据库检索式、纳入排除标准。人工拿到检索式后，去 PubMed 或其他数据库执行，把确认有效的文献整理到results/references-filtered.md。 这一步常见的错误是：示例中使用了模型记忆中的文献，但作者没有核对，导致参考文献不存在或卷期错误。所以literature-review的约束必须写明“最终文献列表以真实检索结果为准”。 4.2 阶段二：用数据分析 skill 生成统计结果准备好data/raw/exp.csv，运行： codex "运行>python code/analysis.py
确认输出结果与 skill 生成时描述的一致。之后运行figure-plotskill： codex "运行 figure-plot skill，基于 results/analysis/descriptive_stats.csv 生成图片"
人工检查图片分辨率、颜色、坐标轴单位和图注。这一阶段最容易出现的问题是数据清洗过程没有被记录。如果 AI 在分析时删除了缺失值或离群点，必须在脚本中明确写入，不能默默处理。 4.3 阶段三：用写作 skill 生成初稿并润色建立manuscript目录，先准备好notes/experiment-notes.md和results/key-numbers.md。运行： codex "运行 paper-writing skill，生成稿件章节到 manuscript 目录"
生成后，作者逐章阅读。尤其检查 methods 是否包含实验记录之外的参数，results 里的数字是否与统计输出一致。然后运行abstract-polish： codex "运行 abstract-polish skill，把 manuscript/abstract.md 压缩到目标期刊字数"
润色后，对比原摘要，确认没有改变核心结论。这里有一个建议：不要让 AI 把“可能相关”改成“显著相关”，语言润色不等于夸大结论。 4.4 阶段四：投稿前格式与合规检查运行format-check： codex "运行 format-check skill，检查 manuscript/paper.md"
读取submission/format-check-report.md，逐项修复问题。随后用 Git 检查文件变更： git status git diff --stat git diff data/raw/
确认原始数据没有被 AI 修改。最后人工补全投稿声明：作者贡献、利益冲突、数据可用性、AI 辅助工具使用声明。这些内容必须由作者填写，不能交给 skill 自动生成后直接提交。 5. 运行中的常见问题与排查路径5.1 skill 没有被 Codex 识别现象是运行codex "运行 xxx skill"后，Codex 表示不知道这个 skill，或完全忽略指令直接回答。 排查顺序： - 当前目录是否在项目根目录，是否正确使用绝对或相对路径。
skills/xxx/SKILL.md文件是否存在，目录名是否与 skill name 一致。- frontmatter 是否完整，
description是否明确。 - 使用的 Codex 版本是否支持自定义 skill 加载。
- 模型是否支持工具调用。
可以先执行： codex "列出项目中的所有 skill 文件"
如果列不出来，手动指定文件路径再试一次。不要为了绕过问题就改用无 skill 的长提示词，这样会失去可复用性。 5.2 模型返回格式错误或截断现象是生成的SKILL.md不完整，或分析报告写到一半被截断，代码块缺少结尾。 可能原因：上下文太长、输出 token 限制、输入文件过大、模型版本差异。解决方案： - 把大文件拆成小段，一次只处理一个章节。
- 要求 Codex 把完整代码写入
.py文件，不要只在终端展示。 - 在 skill 约束中明确“输出必须完整落盘，若失败则说明原因”。
预防方式是在AGENTS.md中写：长文档写入文件，回复中只给摘要和下一步计划。 5.3 文件路径与权限问题现象是生成的脚本运行时报FileNotFoundError或权限不足。 排查时先看路径基准。Codex 工作目录通常是项目根目录，但有时候它可能会写出相对路径和脚本运行目录不一致。建议所有 skill 输出统一使用相对项目根目录的路径，并在生成脚本时先判断os.path.exists： from pathlib import Path data_path = Path("data/raw/exp.csv") if not data_path.exists(): raise SystemExit("数据文件不存在，请检查路径")
权限方面，确保当前用户对results、figures、submission目录有写权限。如果使用容器或远程服务，还要检查挂载目录是否可写。 5.4 输出质量不稳定时的降级策略同一个 skill 在不同模型、不同上下文下可能产生差异。要控制质量，可以几种手段并行： - 在
SKILL.md中提供少量示例输出，让 Codex 照格式执行。 - 要求 Codex 先列出执行计划，得到用户确认后再开始。
- 把“必须基于文件事实”写进约束，禁止它补造参数。
- 对于高风险任务，人工先写好模板结构，只让 AI 填空。
如果一次运行结果不理想，不要反复重试生成，而是先检查输入文件是否完整、约束是否清晰。质量不稳定很多时候是任务拆得太粗。 6. 生产环境建议：从个人草稿到团队科研流水线6.1 把 skill 变成团队共享模板个人使用 skill 是效率提升，团队使用 skill 则是流程标准化。建议把skills/目录纳入 Git 仓库，并让所有成员基于同一个模板开发。修改 skill 时走合并请求，评审重点不是代码，而是任务边界和防幻觉约束。 每个 skill 目录中再放一个CHANGELOG.md，记录版本变更。例如“v1.1.0：增加期刊格式检查项”。这能避免成员之间出现“我用的是旧版 skill，所以输出不一样”的问题。 6.2 版本管理与可复现性论文可复现性不只包含数据和代码，也包括 AI 辅助工具的版本、模型和 skill。建议在项目根目录维护submission/reproducibility.md，记录： - 数据文件来源和下载时间。
- 分析脚本运行环境，包括 Python 版本和依赖包版本。
- Codex 版本和模型名称。
- 使用的 skill 版本。
- 关键文件的 Git commit 哈希。
命令执行时间也建议记录。比如运行完成后执行： echo "analysis completed $(date -Iseconds)" >> results/analysis/run.log
这工具化和流水线化的意义在于：即使三个月后返修，你仍然能回答“当时的统计结果是如何得出的”。 6.3 投稿前人工复核清单无论 skill 写得多完整，投稿前都必须由作者逐项确认： | 检查项 | 人工确认方式 | 是否通过 |
|---|
| 原始数据未被修改 | 用 Git diff 检查 data/raw 目录 | | 统计方法与方法部分一致 | 对比脚本和 manuscript 方法段落 | | 所有结果数字可溯源 | 用结果文件反查脚本输出 | | 参考文献真实可查 | 在数据库中抽查关键文献 | | 图片符合期刊要求 | 检查分辨率、字体、图注 | | 审稿回复如实反映修改 | 与修改稿逐条对照 | | AI 使用已声明 | 按目标期刊政策填写 | | 利益冲突和作者贡献已声 | 由通讯作者确认 |
这个清单可以直接放进submission/final-checklist.md作为仓库文件，每项由负责人填写并签名。 6.4 下一步扩展方向当 9 个 skill 在单个论文项目中跑通后，可以继续扩展： - 将
format-check接入持续集成流程，每次提交稿件都自动生成检查报告。 - 为不同目标期刊建立不同 skill 变体，例如
format-check-nature-family、format-check-elsevier，把期刊要求固化。 - 把
>
需要专业的网站建设服务？
联系我们获取免费的网站建设咨询和方案报价，让我们帮助您实现业务目标
立即咨询
|