JPE 副主编的 AI 论文工厂全流程拆解

created: 2026-02-25 tags:

• type/article
• status/draft
• topic/AI科研自动化
• topic/Claude-Code
• topic/因果推断 aliases:
• CC做实证研究全流程

Yanagizawa-Drott 是苏黎世大学的经济学教授、JPE 副主编。他搞了一个叫 APE 的项目，让 AI 自主完成实证经济学论文的全流程——从找研究问题、拉数据、跑回归到写出完整的 LaTeX 论文，一个月产出两百多篇（日均 7-8 篇），然后跟 AER、QJE 这些顶刊的论文打擂台。上一篇文章我详细拆解了这个项目的方法论，很多读者看完之后留言说，道理我都懂，但我自己怎么上手？APE 用的那些技术，我一个刚装好 Claude Code 的研究生，能不能也搞起来？

下面就从头到尾讲一遍怎么做。

我自己在用 Claude Code（后面简称 CC）做研究相关工作已经有一段时间了，踩过不少坑，也积累了一些经验。这篇文章的定位很明确：不是概念科普，不是思想实验，而是一篇面对面的实操讲解。你可以想象成，一个对 CC 有些使用经验的研究者，坐在你对面，从头到尾把每一步怎么操作、每个地方要注意什么，给你仔仔细细讲一遍。这篇文章会很长、很具体，包含大量 prompt 示例和命令行操作。如果你还没装 CC，建议先装好再来读；如果已经装好了，可以边读边跟着做。

全文按照实证研究的自然流程分为八个部分：一、搭好项目骨架——先建目录结构，再用 /init 生成 CLAUDE.md；二、让 CC 去拿数据——通过 API 自动获取公开数据；三、让 CC 跑计量分析——从 DiD 到 RDD，交任务而不是交问题；四、让 CC 写论文——引言、实证分析、结果展示；五、迭代修改——让 CC 响应审稿意见并批量执行修订；六、可复现性——用 git 时间戳做预注册；七、CC 会犯的错——五类常见错误及应对；八、进阶工具——自定义命令、Skills 和多代理流水线。中间穿插一个从零到初稿的完整工作流示例。

说明一下称呼：APE 全称 Autonomous Policy Evaluation Project，前一篇文章里我写成了 APEP，后来发现官方方法论页面统一用的是 APE，这里也跟着改过来。APE 的方法论还在迭代，本文引用的是 2026 年 2 月的版本。

一、搭好项目骨架

你装好 CC，打开终端，输入 claude，进入了 CC 的交互界面。然后呢？

很多人这时候就开始直接问问题了：“帮我跑个 DiD”、“帮我清洗这个数据”。这样做当然可以，但效率很低，因为你每次开一个新对话，CC 对你的项目一无所知。它不知道你的数据在哪、用什么分析软件、论文写到哪了、标准误怎么聚类。你每次都要重新解释一遍。

所以装好 CC 之后，第一件事不是问问题，而是先把项目的目录结构建好。这是高质量输出的基础。CC 工作的时候会读取你的文件结构来理解项目全貌，如果文件散乱无序，它给出的建议和代码也会跟着乱。

一个实证研究项目的目录结构不需要多复杂，但要清晰：

minwage-youth-employment/
├── data/
│   ├── raw/            # 原始数据，只读，绝对不改
│   └── clean/          # 清洗后的数据
├── code/               # 分析脚本
├── results/
│   ├── tables/         # 回归表格（LaTeX 格式）
│   └── figures/        # 图表（PDF 格式）
├── paper/              # 论文和参考文献
└── CLAUDE.md           # 项目说明（用 /init 生成）

你可以自己建，也可以让 CC 帮你建——后面“完整工作流”那节会给你看具体的 prompt。

目录建好之后，下一步是生成 CLAUDE.md。

CLAUDE.md 是什么？说白了就是一份给 CC 看的项目说明书。你把它放在项目根目录，CC 每次启动的时候会自动读取它。相当于你给你的 RA 写了一份标准操作手册，每次 RA 上班第一件事就是把这份手册看一遍，然后按照手册里的规范来工作。

这个地方其实挺关键的，我多花点时间讲。

怎么生成 CLAUDE.md？最快的方式是用 /init 命令。在项目根目录打开 CC，输入 /init，CC 会自动扫描当前目录下的文件结构，生成一个 CLAUDE.md 的初始模板。你再在这个模板基础上，填写具体的数据说明、方法论要求和输出规范。比从空白开始手写省多了。

一个好的 CLAUDE.md 应该包含什么？我给你看一个我自己在用的模板，你可以在 /init 生成的基础上参考这个来补充：

# 项目：最低工资对青年就业的影响

## 项目背景
研究 2015 年各省最低工资调整对 16-24 岁青年就业率的因果效应。
采用双重差分法（DiD），利用各省调整时间和幅度的差异作为识别策略。

## 数据说明
原始数据在 data/raw/，这个目录是只读的，绝对不要修改里面的文件。
清洗后的数据放 data/clean/。
主数据文件是 data/clean/youth_employment_panel.csv，
包含 2012-2019 年 31 个省份的季度面板数据。

## 分析工具
主要用 [你选择的语言]。选你最熟悉的那个——R、Python 或 Stata 都行。
熟悉才能高效地检查 CC 的输出有没有跑偏。
以下是常见搭配（按你选的语言填一种即可）：
- R：计量用 fixest，可视化用 ggplot2，数据清洗用 tidyverse
- Python：计量用 pyfixest 或 linearmodels，可视化用 matplotlib/seaborn，数据清洗用 pandas
- Stata：直接在 .do 文件里写 reghdfe、coefplot 等命令
所有分析必须通过脚本文件执行，不要在交互式环境中做临时操作。

## 识别策略
DiD 设计。处理变量是最低工资的对数。
标准误聚类到省级（cluster = province_id）。
必须做事件研究图来验证平行趋势假设。
基准时期设为政策实施前一期（k = -1）。

## 输出规范
回归表格用 LaTeX 格式，输出到 results/tables/。
图表输出为 PDF，存到 results/figures/，宽度 8 英寸、高度 6 英寸。
所有回归都要设随机种子（R: set.seed(42)，Python: random.seed(42)，Stata: set seed 42）。
结果文件名用英文，不要用中文。

## 论文文件
论文在 paper/main.tex。
参考文献在 paper/references.bib。

你看到了，这份文件不复杂，但该说的都说了。CC 看完这个文件之后，它知道你在做什么研究、数据在哪、用什么工具、方法论有什么要求、输出要什么格式。之后你每次跟它对话，它都带着这个背景知识来工作。

我自己在用的时候发现，CLAUDE.md 写得越具体，CC 的输出质量越高。比如你写”标准误聚类到省级”，CC 就不会给你输出稳健标准误或者不聚类的版本。你写”用 Python”，它就不会给你生成 R 或 Stata 的代码。这些小事积累起来能省掉大量来回。

还有一点，CLAUDE.md 不是写一次就不管了。随着项目推进，你会不断往里加东西。比如你做完主回归，要开始做稳健性检验了，你可以在 CLAUDE.md 里加一节“稳健性检验要求”。比如你发现 CC 老是在某个地方犯同样的错误，你也可以加一条规则进去。这个文件是活的，跟着你的项目一起成长。

APE 项目没有公开它的 CLAUDE.md，那是私有基础设施。但从它产出论文的高度一致性来看，背后一定有一套非常详细的规范在驱动。

我自己的建议是，项目里的分析脚本用数字编号来标记执行顺序，比如 00_packages.R（或 00_setup.py、00_setup.do）管包依赖和随机种子、01_fetch_data 拉数据、02_clean_data 做清洗。这不是 APE 公开的做法，而是我自己踩坑之后总结出来的经验——用编号标记顺序，这样即使 CC 重新开一个会话，它看到文件名就知道该按什么顺序跑。

你作为一个研究者，你的 CLAUDE.md 不需要像 APE 那么复杂。但基本的项目信息、数据规范和方法论约束一定要写。这是 ROI 最高的一笔投入：花半小时写，之后每次交互都省时间。

二、让 CC 去拿数据

好，CLAUDE.md 写好了。接下来你想开始做分析，但首先你得有数据。

这里有两种情况。第一种，你已经有数据了，放在 data/raw/ 里——这最简单，后面直接让 CC 读就行。第二种，你需要从公开数据源下载数据。CC 在第二种情况下特别好用。

你知道，很多公开数据源都有 API。美联储的 FRED、劳工统计局的 BLS、Census 的 PUMS API、世界银行、IMF，这些数据源都可以通过编程来获取。以前你可能要自己写 Python 脚本去调 API，现在你可以直接让 CC 来做。

你怎么跟 CC 说呢？很简单，像跟 RA 说话一样：

帮我从 FRED 下载 2000 年到 2023 年的月度失业率数据（UNRATE 系列），同时下载同期的 CPI（CPIAUCSL 系列）和联邦基金利率（FEDFUNDS 系列）。API key 我放在环境变量 FRED_API_KEY 里了。数据下载完保存到 data/raw/fred_macro.csv。写成脚本文件保存到 code/ 目录。

CC 收到这个指令之后，会写一个脚本（R 用 fredr 包，Python 用 fredapi 包，取决于你在 CLAUDE.md 里指定的语言），调 API 把三个系列都拉下来，合并保存成 CSV。如果中间出了什么问题——比如 API key 不对、网络超时、某个系列名打错了——CC 会自己看到报错信息，然后尝试修复。

APE 项目的核心原则之一就是 Real Data Only——只用真实公开数据。如果某个 API 拿不到数据，系统会换一个研究问题，而不是去模拟数据。用模拟数据的论文会被自动拒稿。这个原则很值得我们学。从 APE 已发表的论文来看，数据来源覆盖面很广：做瑞士能源公投研究的论文用到了瑞士公投数据的 R 包接口，做印度 GST 研究的论文从印度统计部 API 拉了 CPI 数据，还解析了 RBI 的 PDF 文件来获取州级财政数据。

如果你要用 Census 的 PUMS 数据（这在美国劳动经济学研究里非常常见），你可以这样说：

帮我从 Census API 下载 2018 和 2019 年的 ACS 1-year PUMS 数据，只要以下变量：ST（州）、AGEP（年龄）、SEX、RAC1P（种族）、SCHL（教育）、ESR（就业状态）、WAGP（工资）、WKHP（周工时）、PWGTP（权重）。只保留 25-54 岁的样本。保存到 data/raw/pums_2018.csv 和 data/raw/pums_2019.csv。

CC 会去调 Census API，拼 URL，处理分页，合并结果。你甚至不需要知道 Census API 的具体格式，CC 自己会查文档或者根据它的训练数据来构造请求。

不过这里要提醒一点：CC 有时候对 API 的具体参数记得不完全准确。比如某个 API 去年改版了，CC 可能还在用旧版本的参数名。所以数据拿到之后，你一定要检查。让 CC 输出一些描述性统计——行数、列数、各变量的均值和范围——看看是不是符合你的预期。这个检查环节不能省。

如果数据源没有 API 呢？比如中国的很多数据——国家统计局、中经网、Wind——没有免费 API。这种情况下你可能需要自己手动下载 Excel 或者 CSV 文件放到 data/raw/ 里，然后让 CC 来做清洗和合并。CC 处理 Excel 文件非常顺手，pandas 的 read_excel 或者 R 的 readxl 它都会用。

三、让 CC 跑计量分析

数据有了，接下来是最核心的部分：跑回归。

在开始之前，先讲两条贯穿整个分析流程的原则，比任何具体的工具选择都重要。

第一条：选你熟悉的语言。 R、Python、Stata 都行，关键是你得能看懂 CC 写出来的代码。CC 会犯错，而你判断它有没有跑偏的前提，是你对这门语言足够熟悉。如果你平时写 Python 比较多，就让 CC 用 Python；如果你是 Stata 用户，就用 Stata。不存在"做实证必须用某个语言"这回事——选你能高效审查的那个。

第二条：每一步都要进脚本。 CC 在你电脑上跑代码，有时候它会偷懒——在内存里做一些中间操作，不写进脚本文件。这很危险。你关掉会话，那些操作就消失了，没人知道它中间做了什么，结果没法追溯也没法复现。所以你要在 CLAUDE.md 里明确写上：**所有数据操作必须写入脚本文件，不允许在交互式环境中做临时操作。**这样你的分析流程才是可复现的——任何人拿到你的脚本，按编号顺序跑一遍，能得到完全一样的结果。

这两条原则贯穿后面所有内容。记住它们，下面每个操作环节我都会回来呼应。

接下来说一个思维转变：不要让 CC 给你写代码，让 CC 帮你做完整个分析。

新手最常犯的错误是把 CC 当成一个代码生成器：“帮我写一段跑 DiD 的 R 代码”。CC 给你代码，你复制到 RStudio 去跑，报错了再回来问。这样做本质上跟用 ChatGPT 没有区别，你浪费了 CC 最大的优势——它能直接在你的电脑上执行代码。

正确的做法是交任务，而不是交问题。你应该这样说：

用 data/clean/youth_employment_panel.csv 做 DiD 分析。因变量是 emp_rate（就业率），处理变量是 log_minwage（最低工资的对数），面板结构是 province_id + year_quarter。请做以下分析：

第一，跑基准 DiD 回归，加入省份固定效应和时间固定效应，标准误聚类到省级。

第二，做事件研究（event study），画出动态效应图，基准期设为 k=-1。图要能清楚看到处理前各期的系数是否接近零（验证平行趋势），以及处理后系数的变化趋势。

第三，做三个稳健性检验：安慰剂测试（把处理时间提前两年）、去掉直辖市样本、加入省份特定线性趋势。

结果表格输出 LaTeX 格式到 results/tables/。事件研究图输出 PDF 到 results/figures/。所有操作写进脚本文件。

你看，这一段话里有明确的输入（数据文件）、明确的方法（DiD）、明确的输出（表格和图的路径和格式），还有具体的分析要求。CC 收到之后，会按顺序做完所有事情。中间某一步报错了——比如数据里有缺失值导致回归跑不动——CC 会自己诊断、处理缺失值、重新跑。

不同语言各有适合做面板回归的包。APE 项目用 R 做所有计量分析，使用的是成熟的因果推断包——官方方法论只说了这一句，没有点名具体用哪个。下面按语言给你看一下常用的工具和代码风格，你挑自己熟悉的看就行。

如果你用 R，推荐 fixest 包。它是目前 R 生态里做面板固定效应回归最快的包，内存效率也好，语法对 CC 非常友好——feols 函数一行就能指定固定效应和聚类标准误：

library(fixest)

# 基准 DiD
model_base <- feols(emp_rate ~ log_minwage | province_id + year_quarter,
                    data = panel,
                    cluster = ~province_id)

# 事件研究
model_es <- feols(emp_rate ~ i(rel_time, ref = -1) | province_id + year_quarter,
                  data = panel,
                  cluster = ~province_id)

# 画事件研究图
iplot(model_es,
      xlab = "Relative Time to Treatment",
      ylab = "Effect on Employment Rate",
      main = "Event Study: Minimum Wage and Youth Employment")

如果你用 Python，推荐 pyfixest（fixest 的 Python 移植版，语法几乎一样）或者 linearmodels：

import pyfixest as pf

# 基准 DiD
model_base = pf.feols("emp_rate ~ log_minwage | province_id + year_quarter",
                       data=panel,
                       vcov={"CRV1": "province_id"})

# 事件研究
model_es = pf.feols("emp_rate ~ i(rel_time, ref=-1) | province_id + year_quarter",
                     data=panel,
                     vcov={"CRV1": "province_id"})

# 画事件研究图
pf.iplot(model_es)

如果你用 Stata，reghdfe 加聚类标准误是标准做法：

* 基准 DiD
reghdfe emp_rate log_minwage, absorb(province_id year_quarter) cluster(province_id)

* 事件研究
reghdfe emp_rate ib(-1).rel_time, absorb(province_id year_quarter) cluster(province_id)
coefplot, keep(*.rel_time)

你选哪个语言不重要，重要的是：第一，你能看懂代码并判断逻辑对不对；第二，所有操作都写在脚本文件里，而不是在交互式环境中随手跑。

顺便说一下，APE 论文里用到的因果推断方法，DiD 占比约 60%，RDD 约 25%，其他方法（IV、事件研究等）约 15%。这也说明 DiD 和 RDD 是 CC 目前最擅长的因果推断方法。

如果你做的是 RDD 而不是 DiD，CC 同样能处理。你这样说：

数据在 data/clean/rdd_sample.csv。跑 RDD 分析，断点变量是 vote_share（得票率），断点值是 0.5，因变量是 policy_outcome。用 rdrobust 包，报告传统估计量和偏差修正估计量，画 RDD 图（散点 + 局部多项式拟合）。

CC 会用 rdrobust 包来做，自动选择最优带宽，报告各种标准误，画出清晰的断点图。

做完主分析之后，稳健性检验也可以一次性交给 CC。这里我自己在用的时候有个技巧：与其一个一个告诉 CC 做哪些稳健性检验，不如一次性列出来，让它批量跑完。CC 在同一个会话里跑多个回归效率很高，因为数据只需要加载一次，环境也不用重新设置。

我自己的做法是把脚本分模块——03_main_analysis 跑主回归，04_robustness 跑稳健性，05_figures 画图，06_tables 生成 LaTeX 表格。后缀名取决于你选的语言（.R、.py 或 .do），核心是模块化和编号。每个脚本独立，但共享同一套数据和全局设定（通过 00_setup 统一管理包依赖和随机种子）。用数字编号标记执行顺序，这样即使 CC 重新开一个会话，它看到文件名就知道按什么顺序跑。

前面讲的第二条原则在这里尤其重要：CC 有时候会在内存里完成某些中间步骤——比如做了一个数据筛选、算了一个汇总统计——但不写进脚本。你要明确要求它："所有操作必须保存为脚本文件，不允许交互式临时操作。"这不是洁癖，不是可有可无的偏好——三个月后你回来看这个项目，或者审稿人要求你复现某个结果，你要能从脚本里完整追溯每一步做了什么。

再说两个在跑分析时非常实用的 CC 功能。

第一个是深度思考关键词。CC 支持四个层级的思考深度：think（基础思考）、think hard（深度思考）、think harder（更深度思考）、ultrathink（最深度思考）。你在 prompt 前面加上这些关键词，CC 会花更多时间做推理。实证研究里怎么用呢？日常跑回归、清洗数据，不需要加——这些是执行性任务。但涉及识别策略的论证、事件研究图的平行趋势判断、审稿意见的应对方案，加个 think hard 或 ultrathink 能显著提升输出质量。比如：“ultrathink，帮我论证为什么各省最低工资调整时间的差异可以作为准自然实验”。

第二个是计划模式（Plan Mode）。CC 有三种工作模式，用 Shift + Tab 循环切换：普通模式（每次操作需要你确认）、自动接受模式（自动执行编辑操作）、计划模式（只读分析，不修改任何文件）。计划模式在实证研究里特别有用——比如你要让 CC 批量修改多个分析脚本，可以先切到计划模式，让 CC 分析一遍打算怎么改，你确认方向对了再切回普通模式放行。做稳健性检验之前，先让 CC 在计划模式下列出它打算做哪些检验、每个检验改动哪些参数，审核完了再执行。这比事后发现跑错了再重来高效多了。

四、让 CC 写论文

跑完回归，接下来是写。

很多人在这一步又退回去了——自己看着回归结果写论文，偶尔让 ChatGPT 润色一下。这当然可以，但你错过了 CC 最有意思的一个能力：它看着你的回归输出，直接帮你写论文的实证分析部分。

具体怎么做呢？分几个部分来讲。

先说引言。引言是论文里最难写的部分之一，因为它需要讲清楚研究问题为什么重要、前人做了什么、你的贡献是什么、你的方法是什么、你发现了什么。这个你自己写一个初稿，然后让 CC 帮你优化，比让 CC 从零开始写效果更好。为什么呢？因为引言需要对文献和研究动机有深入的理解，这些东西 CC 不一定比你清楚。你写了一个粗糙的初稿，CC 在你的基础上调整结构、改善表达、补充过渡，这样产出的东西质量更高。

你可以这样跟 CC 说：

读一下 paper/main.tex 里面的引言部分。目前写得比较散，帮我重新组织结构。第一段要有一个吸引人的开头，点出研究问题的现实重要性。第二段概述你的研究设计和主要发现。第三段讲文献和你的贡献。第四段简要说明论文结构。注意保持学术论文的规范语气，但不要太干。可以参考 AEJ: Policy 的行文风格。

识别策略（identification strategy）这一节可以放心交给 CC，前提是你在 CLAUDE.md 里写清楚了你的 DiD/RDD 设计。CC 非常擅长把一个计量方法用准确的学术英语描述出来，包括公式、假设、检验。你只需要审核它写的内容是否准确反映了你真正做的事情——这是你不能偷懒的环节。

结果展示是 CC 最顺手的部分。因为回归结果是它自己跑出来的，它知道每个系数是多少、显著不显著、方向怎么样。你让它写实证结果部分，它可以直接引用具体的数值。你可以这样说：

读一下 results/tables/ 里面的所有回归结果表格，以及 results/figures/ 里面的事件研究图。帮我写论文的 Results 部分。先描述基准回归结果，然后讨论事件研究图的含义（特别是平行趋势是否成立），最后汇报稳健性检验的结果。每个表格和图都要在正文中引用（Table 1, Figure 1 等）。

APE 的做法是让 CC 在同一个流程里生成 R 脚本和 LaTeX 论文，每篇论文都附带完整的代码、数据和图表复现包。你也可以学这个做法——让 CC 把回归结果直接输出为 LaTeX 表格，论文里用 \input{} 引用，避免手动抄数字。这样表格里的数字和正文里引用的数字就不会对不上——因为它们来自同一个数据源。

五、迭代修改：让 CC 响应审稿意见

写完初稿不是终点。论文要经过审稿、修改、再审、再改。CC 在这个环节也非常有用。

假设你收到了审稿意见（或者是导师的反馈、合作者的建议），你可以把审稿意见直接扔给 CC：

读一下 paper/referee_report.txt，这是审稿人的意见。然后读一下我们的论文 paper/main.tex 和所有代码文件。帮我做两件事：第一，写一个修改计划（revision plan），列出每条审稿意见以及我们打算怎么回应。第二，对于需要补充分析的意见（比如审稿人要求做某个稳健性检验），直接帮我跑回归并生成新的表格。

CC 收到审稿意见之后，它能理解审稿人在要什么，然后分别处理：有些意见是写作层面的（“引言太长了”“文献综述缺少某篇论文”），CC 可以直接改论文；有些意见是分析层面的（“请加一个安慰剂测试”“请用不同的聚类层级重新跑”），CC 可以直接跑新的回归。

APE 项目在这方面做得很系统。它有一个完整的修订流程：先生成 revision_plan.md，列出每条意见的应对方案；然后逐条执行，修改代码和论文；最后写 reply_to_reviewers.md，对每条意见给出详细回复。APE 的论文会经过多轮迭代——同一个研究问题会产生一个 parent 链，后一版基于前一版的反馈修订。有些系列可能经过五六轮甚至更多。

APE 的修订机制其实比我们想的更系统。每篇论文在进入锦标赛之前，要经过三个阶段的审阅：

第一阶段是 advisor review——四个不同的 AI 模型（GPT-5.2、Grok-4.1-Fast、Gemini-3-Flash、Codex-Mini）独立检查有没有致命错误，四个里面至少三个通过才能进入下一步。

第二阶段是 referee review——三个模型（GPT-5.2、Grok-4.1-Fast、Gemini-3-Flash）并行各写一份学术期刊风格的审稿报告。其中 Gemini-3-Flash 通过 Google API 直接读原始 PDF（保留完整的视觉排版信息）；其他两个模型通过 OpenRouter 收到的是 LaTeX 源码和代码。

第三阶段是 revision——生成模型（CC）必须逐条回应所有审稿意见并完成修改，才能进入锦标赛。

这里面有一个很巧妙的设计：用来自不同提供商的多个模型联合把关，是为了避免单一模型的盲点——每家模型的训练数据和偏好不一样，某类错误一个模型看不出来，换一家可能一眼就发现了。

自己跑完分析之后，换一个 AI（比如 GPT 或 Gemini）来审核 CC 的代码和论文，相当于找了一个独立的第二意见。

审稿意见来了之后，先让 CC 写修改计划，你审核一下计划是否合理，然后让 CC 执行。这比你自己一条一条地处理要快得多，尤其是那些“换个样本期重新跑”“加个控制变量重新跑”这类机械性的修改。

六、可复现性：先注册再看数据

这个话题特别重要，我要单独拿出来讲。

科学研究的核心要求之一是可复现性——别人拿到你的数据和代码，能跑出同样的结果；更进一步，别人能验证你的研究计划确实是事前制定的，而不是看到结果之后倒推出来的。实证研究面临的一个经典威胁是 HARKing——Hypothesizing After Results are Known，先看到结果再编假设。你跑了一堆回归，发现某个子样本的结果显著，然后在论文里说”我们的研究假设是......这个子样本应该有更强的效应”。这不是道德问题，而是科学方法论的问题：如果假设是结果倒推出来的，你的统计推断就失去了意义。

APE 对这个问题有一个很巧妙的解决方案：用 git 的时间戳来做 pre-registration。具体做法是这样的——在下载任何数据之前，先把研究计划（initial_plan.md，包括假设、识别策略、主要回归方程）提交到 git。然后才开始拉数据、跑回归。因为 git 的时间戳是不可篡改的，所以任何人都可以验证：研究计划确实是在看到数据之前就写好了的。

APE 的贡献是把这种方法系统化了，变成了自动执行的流水线。

这个设计你完全可以复制到自己的研究里。操作很简单：

第一步，在你的项目目录里初始化一个 git 仓库。如果你还没用过 git，这是一个很好的开始学的契机。打开终端，进入项目目录，运行 git init。

第二步，在开始任何分析之前，让 CC 帮你写一份研究计划，保存为 initial_plan.md。这份计划要包含：你的研究问题、识别策略、主要回归方程（写出来，不是“我打算做 DiD”这么笼统，而是具体的方程式）、预期结果的方向、数据来源。

第三步，把 initial_plan.md 提交到 git：

git add initial_plan.md
git commit -m "Lock initial research plan before data analysis"

第四步，开始拉数据、跑回归。

这个方法的好处是零成本、零摩擦。不需要去 AER Registry 或者 OSF 注册（当然如果你要发 top 5，那些注册还是有用的），git 就能做到最基本的时间戳证明。

APE 还有一套自动化的可复现性检查机制，分两个层面：代码扫描（检测数据伪造、结果硬编码、可疑模式）和复现测试（验证代码能跑通且结果一致）。如果发现严重问题，论文会受到评分惩罚——这就是 APE 的 virtual losses 机制。

virtual losses 的聪明之处在于，复现性问题不只是简单的拒稿。发现代码有问题的论文会被施加评分惩罚——相当于在锦标赛里自动输掉几场比赛。这意味着即使一篇论文运气好赢了几场，只要代码跑不通或结果对不上，排名照样上不去。这个设计确保了论文不能仅靠比赛运气获得高排名。

说到锦标赛本身的评判机制，APE 也下了不少功夫防止评估偏差。每对论文会被评判两次，第二次把呈现顺序对调——先看 A 后看 B，再先看 B 后看 A——用这种 position swapping 来消除顺序效应。评判用的是 Gemini 3 Flash，通过 Google API 直接上传 PDF，让评委看到完整的排版和图表，跟人类读者的阅读体验一致。选非 Anthropic 模型来当评委，是有意为之——论文由 Claude 生成，如果评委也是 Claude，存在自我偏好偏差的风险：自己的生成风格被自己打高分。用 Gemini 来评，可以在一定程度上消除这种系统性偏差。最终排名采用微软的 TrueSkill 系统（一种贝叶斯评分算法），每场比赛后更新每篇论文的技能评分。排行榜上展示的是保守估计值 mu-3*sigma——不光看你赢了多少场，还要看评分的置信度够不够高。打的场次少、赢得不稳定的论文，排名自然上不去。

让 CC 自己审核自己的代码，做一轮可复现性检查：

读一下 code/ 目录下面所有的分析脚本。检查以下问题：有没有硬编码的数字（结果应该来自回归输出而不是手动写入）？有没有选择性报告（跑了多个模型但只报告了显著的那个）？数据处理有没有可能引入偏差的操作（比如删掉了某些观测值但没有说明理由）？

CC 不一定能发现所有问题，但它能帮你做一个初步的自查。这比你自己一行一行看代码效率高多了。

七、CC 会犯错——靠系统设计来防，而不是靠人盯

CC 会犯错，而且有些错很隐蔽。靠人盯是盯不住的——你一忙一疏忽就溜过去了。正确的做法是把验证逻辑嵌进工作流本身，设计一个让错误自动暴露的系统。

先快速过一遍 CC 最常犯的五类错误：

• 幻觉：编造不存在的 R 包、API 端点、数据变量名，代码看起来很像那么回事但用了根本不存在的参数
• 代码逻辑错误：语法正确、能跑通，但逻辑有问题——DiD 处理组搞混、合并用错 key 导致重复行、事件研究基准期设错
• 过度自信：流畅地写出”平行趋势假设得到了支持”，但可能根本没仔细判断图上 pre-trend 系数是否真的支持这个结论
• API 版本不匹配：用旧版本的接口参数，新版已经改了格式，比如 Census API 的参数名随年份调整
• 对中国数据源不够了解：对美国数据源（FRED、BLS、Census）很熟悉，但对中国数据源（国家统计局、CSMAR、CNRDS）了解有限

这五类错误各有各的表现形式，但应对思路是一样的：不能靠“你自己多留心”，要靠工作流的结构设计让错误自动暴露。下面讲四条原则。

原则一：唯一真相源——消灭手动中转。 论文里出现的每一个数字，只能来自一个地方：代码的输出文件。表格用 LaTeX 的 \input{} 引用，不手动抄；正文引用某个系数值，用代码提取写入结果文件，而不是 CC 顺手写进去的近似值。这条规则执行到位，”论文数字和代码结果对不上”这类错误就在结构上消失了——不是靠你去核对，而是压根没有手动中转的环节。APE 就是这样做的：代码生成结果文件，LaTeX 直接引用，中间没有人工抄写。

原则二：多阶段核查门——让错误无法传播。 不要让 CC 一气从数据跑到论文，每个阶段结束时强制输出中间产物供验证。数据清洗完，输出 codebook 和描述性统计，自动校验样本量、变量范围是否合理——CC 的幻觉在这一关就会被拦住，比如 API 拉回来的数据有问题，描述性统计一看就不对。主回归跑完，输出系数摘要，自动检查方向和量级——系数符号反了、量级差一个数量级，在这一关就能发现。论文初稿出来后，单独开一个新会话让 CC 做自查：有没有硬编码数字？引用数字和结果文件是否一致？

这套分阶段的设计也天然地解决了 API 版本不匹配的问题：让 CC 先小规模测试（只拉一个州、一年的数据）作为第一道核查门，确认 API 能通、数据格式对了再批量拉。对于中国数据源的问题，在 CLAUDE.md 里把数据规范写清楚（变量名是中文的、时间格式是 YYYYMM 不是 YYYY-MM、缺失值用 -999 表示），相当于给 CC 设了一道前置门。

原则三：多代理交叉验证——消除单一模型盲点。 核心分析做完后，换一个 AI（GPT 或 Gemini）审核代码逻辑。这对付的是 CC 自查容易漏掉的错误：DiD 处理组搞混了、基准期设错了——同一个模型反复看自己的代码，容易陷入”自己生成、自己审、自己通过”的盲区，换一个模型往往一眼就能看出来。过度自信也是同理：CC 说”平行趋势得到了支持”可能只是套话，换个模型独立判断事件研究图，给出的评估更可靠。APE 项目用四个不同模型联合把关，特意选非 Anthropic 的模型当评委，就是这个思路。

原则四：善用外部工具——让 CC 查证而不是瞎编。 CC 幻觉的根源是它在”凭记忆回答”。把它接上外部工具，让它查了再说，幻觉就大幅减少。用 MCP 连接 Zotero，CC 不用凭记忆编文献，直接从你的文献库里检索，引用信息准确。用 MCP 连接数据库，CC 不用猜 API 参数，直接查数据源的元数据。让 CC 联网搜索，确认 R 包是否存在、API 端点是否还有效，而不是凭训练数据猜——这也顺带解决了 API 版本不匹配的问题，联网查一下当前版本就行。

这四条原则背后是同一个理念，也是最重要的一条：不是寄望于 AI 不犯错，而是让每一个错误都可以被发现，每一个结果都可以被溯源。

你要建的不是”不会出错的流水线”，而是”出了错也查得出来”的流水线。git 提交记录、codebook、\input{} 引用、分阶段保存的中间文件——这些都是可审计性的基础设施。任何人拿到你的项目（包括你自己三个月后回来看），都应该能清楚地追出：这个数字从哪里来？这段代码在什么阶段跑的？这个分析决策是什么时候做的？

这才是 APE 那套流程真正值得学的地方——不是它产出了多少篇论文，而是它把研究诚信和可复现性做成了工程约束，而不是靠自律维持的道德倡导。CC 帮你执行，你负责判断——这个分工是对的，但光靠这句话还不够。把这个分工落实到工作流的结构里，才真正管用。

一个完整的工作流长什么样

前面讲了很多零散的技巧，最后把它们串起来，给你看一个从头到尾的完整工作流。假设你要从零开始做一篇 DiD 的实证论文。

首先，创建项目目录结构。你可以直接让 CC 来做：

帮我创建一个新的研究项目目录结构。项目名叫 minwage-youth-employment，放在 ~/research/ 下面。需要以下子目录：data/raw、data/clean、code、results/tables、results/figures、paper。

CC 会用 mkdir -p 命令把所有目录建好。然后在项目根目录输入 /init，CC 会扫描目录结构生成 CLAUDE.md 模板。

然后，在 /init 生成的模板基础上填写 CLAUDE.md。前面给了示例，按照你的项目实际情况来写。

接下来，让 CC 获取数据。如果是公开 API 数据：

帮我从 FRED 和 BLS 分别获取以下数据...... 保存到 data/raw/ 里。

如果是你已有的数据，直接放到 data/raw/ 里就行。

然后，让 CC 做数据清洗：

读一下 data/raw/ 里面所有的数据文件，了解数据结构。然后按照 CLAUDE.md 里面的说明，把它们合并清洗成一个可以做面板回归的数据集。保存到 data/clean/youth_employment_panel.csv。同时生成一个数据字典 data/clean/codebook.md，说明每个变量的含义和来源。

这一步 CC 可能需要跑好几轮——读取数据、发现问题、处理异常值、重新读取。让它自己去折腾就好，你最后检查一下 codebook 和数据的描述性统计。

数据清洗做完了，用 /clear 清掉上下文，开一个干净的会话进入下一阶段。每完成一个阶段都建议这样做——CC 的上下文窗口是有限的，把之前关于数据结构的大量讨论清掉，能让 CC 在后续任务中更专注。

再然后，锁定研究计划：

基于我们清洗好的数据，帮我写一份研究计划 initial_plan.md。包含：研究问题、识别策略（详细写出回归方程）、预期结果、稳健性检验列表。写完之后我们提交到 git 锁定。

你审核完研究计划之后：

git add initial_plan.md
git commit -m "Lock initial research plan"

接下来就是核心分析了。用前面讲的方式，让 CC 跑基准回归、事件研究、稳健性检验，生成所有表格和图。

然后写论文。这里有个小技巧：CC 支持用 @文件名 来引用文件（输入 @ 之后按 Tab 可以自动补全路径），比在 prompt 里手打路径更可靠：

读一下 @results/tables/ 和 @results/figures/ 里面的所有分析结果，帮我写论文的实证分析部分（Data、Empirical Strategy、Results 三节）。输出到 @paper/main.tex 里面的相应位置。引用所有相关的表格和图。

引言和结论你自己写初稿，让 CC 帮你优化。文献综述可以让 CC 帮你搜索和整理，但核心的文献选择和定位还是你自己来。

最后，让 CC 做一轮自查：

读一下论文全文和所有代码。做一个完整性检查：论文里引用的数字和表格里的数字是否一致？事件研究图是否支持平行趋势假设的论述？有没有明显的逻辑问题或遗漏？

这整个流程下来，可能需要几个工作日。但考虑到从数据获取到论文初稿的全部产出，这个效率已经非常高了。APE 的系统已经高度自动化，一篇论文从构思到产出只需要几个小时。你作为一个人类研究者，不需要追求那种速度，但可以借鉴它的流程设计。

八、进阶：自定义命令、Skills 和多代理流水线

如果你用了一段时间 CC，觉得有些操作老是重复做，下一步就是把它固化下来。

用 AI 做研究有三个层次。第一层是对话——每次从头开始，跟 ChatGPT 一样。第二层是 CLAUDE.md——项目级配置，CC 每次启动都会读，相当于给 RA 做入职培训。第三层是 Skill——针对具体任务的操作手册，写好一次所有项目都能复用。在第二层和第三层之间还有一个轻量工具：slash commands。它固化的是单个命令，触发方式是你手动输入 /命令名；而 Skill 更智能，CC 会根据任务自动判断要不要调用。

Slash commands 是最轻量的自动化。你在项目的 .claude/commands/ 目录下放一个 Markdown 文件，就定义了一个命令。比如你写一个 run-did.md：

---
description: 运行 DiD 分析全套
argument-hint: <数据文件路径>
---

对 $ARGUMENTS 数据执行以下 DiD 分析流程：

加载数据，先输出描述性统计。然后跑基准 DiD 回归（双向固定效应 + 聚类标准误），做事件研究并画图，然后做安慰剂测试和其他稳健性检验。所有表格输出 LaTeX 格式到 results/tables/，所有图输出 PDF 到 results/figures/。最后生成一个分析报告 results/analysis_report.md，总结主要发现。

保存之后，你在 CC 里输入 /run-did data/clean/panel.csv，它就按这个流程自动执行了。这适合单一任务的固化。

Skills 是更高一级的东西。一个 Skill 就是一个文件夹，核心是一个 SKILL.md 文件，旁边可以放 scripts/、references/、assets/ 等子文件夹。CC 启动时先扫描所有 Skill 的文件头（YAML frontmatter），判断哪些跟当前任务相关，然后按需加载正文和参考文件。这个渐进式加载的设计让 CC 不会被大量不相关的信息撑爆——每个时刻只处理最相关的信息，省资源也保质量。Anthropic 建议 SKILL.md 正文控制在 5000 词以内，更长的参考材料拆到子文件夹里去。

Skills 最大的特点是按需加载。CC 启动时会扫描所有 Skill 的摘要（YAML frontmatter），当它判断当前任务需要某个 Skill 时，才会加载完整的操作手册。调用 Skill 有两种方式：你可以在 prompt 里直接说「使用 xxx 技能」来显式触发，也可以让 CC 自己根据任务相关度判断要不要调用。这更接近 APE 的工作方式：系统知道自己在每个阶段应该做什么，不需要你逐步指挥。

还有关键组合：MCP + Skill。MCP（Model Context Protocol）给 CC 提供工具连接（比如连接 Zotero 读文献、连接数据库查数据），Skill 告诉 CC 拿到工具之后按什么流程操作。光有工具没菜谱，做出来的菜全凭手感。比如你有一个文献综述 Skill，它通过 MCP 连接 Zotero 读取你的文献库，然后按照你定义的框架（按方法分类、比较样本量和识别策略、标记矛盾结论）自动生成综述初稿。

受 APE 启发，我把实证研究的流程拆成了四个可复用的阶段，做成了四个 Skills：

规划阶段（agent-plan）：并行启动多个研究代理，从不同维度收集信息（数据源、文献、制度背景），汇总成一份 plan.md——里面写清楚每个执行代理的任务、输入文件、输出文件。

执行阶段（agent-execute）：按照 plan.md 的分配，一次性启动所有不相互依赖的代理并行跑。每个代理完成任务后立刻把结果保存到文件，不把完整内容返回给主代理。主代理的 context 就这样被保护住了——它只收到状态摘要，不会被大量中间内容撑爆。

审阅阶段（agent-review）：同样并行，从不同视角审阅执行结果。一个代理扮演目标读者，另一个代理做技术核查。两份审阅报告分别保存到文件。

修订阶段（agent-revise）：读取所有审阅反馈，综合修订，产出最终交付物，保存到项目的正式目录。

需要说明的是，这四个阶段是我自己的 agent 工作流设计，受 APE 启发但不等于 APE 的做法。APE 官方方法论描述的是 Paper Generation → Multi-Model Review → Tournament 的流程，跟我的四阶段划分不完全对应。我这么拆是因为这套框架足够通用，除了做论文，写讲稿、做报告、整理文献都能套。

用这套流水线做一篇 DiD 论文，完整的触发方式大概是这样的。你在项目目录里打开 CC，说：

帮我做一篇关于最低工资对青年就业影响的 DiD 研究。FRED 和 BLS 的数据可以通过 API 获取。识别策略是利用各州最低工资调整时间的差异，样本是 2010 年到 2022 年的州季度面板。最终产出一篇完整的英文 working paper。

CC 会启动规划阶段：并行派出三到四个子代理，分别去查数据 API 文档、梳理相关文献、整理识别策略的理论依据，同时写出执行计划。这个阶段可能需要十分钟到二十分钟。

规划完成后，CC 不会等你确认，直接进入执行阶段——数据获取、清洗、回归、画图、写论文，按照计划并行或顺序推进。你可以去干别的事，回来看进度。

执行阶段结束后，自动进入审阅阶段。两个审阅代理分别从读者和技术角度给出意见。

最后修订阶段综合反馈，输出最终版本到你的论文目录。

你的角色是什么？在这个流程里，你主要做三件事：写 CLAUDE.md（告诉系统你在做什么）、审核 plan.md（确认规划方向对不对）、看最终输出（判断质量是否过关）。系统搞定的是那一大段机械性的执行工作。

这不是说你可以完全不管。识别策略是否可信、事件研究图的平行趋势到底成不成立、论文的经济学叙事有没有说服力——这些判断 CC 做不好，而且你也不该让它做。但从数据到初稿的那整段执行路径，现在可以交出去了。

关键的工程原则只有一条，APE 和这套 Skills 都在贯彻：每个子代理立刻把结果保存成文件，不把完整内容返回给主代理。 这条规则保护了主代理的上下文窗口。主代理只需要知道“文件保存成功、关键发现是什么”，不需要把几千字的分析结果全部读进来。上下文是稀缺资源，浪费它就是浪费你的钱和速度。

如果你对 Skills 感兴趣，想深入了解怎么写、怎么用，可以看我这个系列的下一篇文章——专门讲 Agent Skills 从入门到学术应用。Anthropic 也在 GitHub 上开源了一批 Skills（包括生成 Word、PPT、PDF 的），还提供了 skill-creator 这个元技能来帮你快速搭建自己的 Skill。三条上手路径：从最烦的重复任务开始手写、用 skill-creator 交互式搭建、或者 fork 现成的 Skill 改成自己的。

最后的话

我觉得 CC 对实证经济学研究者来说，目前处于一个很有意思的阶段。它还不能替代你做研究，但它已经能替代你做研究中大量的重复性操作。数据清洗、跑回归、画图、格式化表格、写实证分析的描述性段落——这些工作以前占据你大量时间，现在可以交给 CC。省下来的时间，花在真正需要人类判断的地方：提出好的研究问题、设计可信的识别策略、解读结果的经济学含义。

APE 项目给我们展示的不只是 AI 能写论文这个事实。它真正有价值的地方在于那套流程框架：怎么把实证研究的每一个环节拆解成可以交给 AI 执行的模块化任务，同时用预注册、代码扫描与复现测试、多模型交叉审阅等机制来保证研究诚信。这个框架的思想，比任何具体的技术细节都更有价值。

补充一个背景信息：APE 在 2026 年 1 月用的是 Claude Opus 4.5，2 月起切换到了 Opus 4.6。审阅和评审模型也在持续更新。APE 不会因为模型升级就重新生成旧论文——每篇论文反映的是它被生产时的配置。锦标赛评估的是论文质量本身，不管是哪个模型写的。

你现在就可以开始。装好 CC，写一份 CLAUDE.md，把你手头正在做的那个项目交给它试试。从一个小任务开始——清洗一个数据集、跑一个回归、画一张事件研究图。感受一下“让 CC 做完”和“让 ChatGPT 告诉你怎么做”之间的区别。

这个区别，一旦体会到了，就回不去了。

参考资料：

APE 项目主页

APE 方法论页面

APE GitHub 仓库

Claude Code 官方文档

Anthropic Skills 官方教程

GitHub: anthropics/skills