哈佛斯坦福教授《经济学AI使用指南》：四条原则与八类失败

设想这样一个场景：你让 AI 把企业财务数据和海关数据 merge 到一起，再跑一个双向固定效应回归。几十秒后，它交回一张表，系数显著，量级合理，代码也顺利跑通了。

但你可能没有注意到，数据合并时有一半观测值悄悄丢失了，固定效应也设错了——本该设在企业层面，却被设在了县级。更可怕的是，面对这两个问题，AI 从头到尾都没有提过一个字。

但凡用过 AI 的人，都或多或少遇到过上面这些情况。这也是 Adrien Matray 在《An AI Guide for Economists》开篇列出的第一个典型失败案例。这份指南的副标题只有三个词：Mindset before tooling，意思是使用工具之前，先要建立正确的心态。

AI 用得好，产出成倍增长；用得不好，错误也会成倍增长。决定差别的关键在于心态，与技术天赋其实关系不大。今天我们把这份指南的九个章节完整过一遍，挑出对经济学实证研究最有用的部分。

Adrien Matray 现任亚特兰大联储研究经济学家兼 Associate Policy Advisor，同时是 CEPR 研究员，博士毕业于 HEC Paris 金融学专业。加入亚特兰大联储之前，他曾在普林斯顿大学、斯坦福商学院和哈佛大学任教。他的研究领域是应用宏观与金融，关注产业政策、贸易融资、资源错配、经济发展与创业等问题，论文发表在 Econometrica、Journal of Finance、JFE、RFS 等期刊上。

这份指南原本是他写给自己的博士生和 pre-doc RA 的上手手册，所以文中时不时会冒出"有问题去找 Adrien""订阅用的是我的账号""请节约 token"之类的提醒。正因为是带着团队踩过坑之后的实战总结，它不讲模型参数，也不卖所谓的十个神级提示词，里面讲的全是纪律。

指南对 AI 的定位是 an over-eager, overconfident, and quietly lazy collaborator——一个过度热情、过度自信，还会在你看不见的地方偷懒的合作者。过度热情和过度自信都好理解：它反应极快，从不犹豫，说对的和说错的都一样笃定。

AI 真正隐蔽的是偷懒，具体有四种表现。

第一，它倾向于给你一个快速的修补，结构上更稳妥的方案往往被它略过。第二，遇到有歧义的地方，它会挑最省力的那种理解。第三，它会声称某些数据表是冗余的，可以通过 join 重建，借此跳过更难的工作，实际上却没有认真核实过。第四，它习惯凭借训练时学到的知识作答，却不主动检查你手头的数据和当前代码的实际情况。

指南里有一个特别好用的识别技巧：你质疑它时，如果它马上认错，说"你说得对，我来实际检查一下"，那就说明它一开始心里就没底，只是在走捷径（是不是让你想到了豆包？）。另一个例子更典型：你问某张数据库表能不能把两份数据连起来，AI 说可以，因为那张表里有 gvkey 字段。单从表结构上看，它说得没错，可等你真去数一下，会发现这个字段只有 3 行有值。

四条核心原则

1. 验证心态，无法验证的就别信

指南列举了三个让经济学者一看就心塞的场景。

场景一：悄无声息的 merge 失败。系数看起来合理，实际上一半观测值被丢掉了，固定效应的层级也用错了。

场景二：样本悄悄缩水。你让它清洗面板数据，它交回一个干净的平衡面板，代价是删掉了所有不完整的 firm-year 观测值，样本少了 40%，对这个取舍却只字未提。

场景三：模型设定对不上。你让它复刻某篇论文的设定，结果量级差不多，但聚类层级错了，漏掉了交互项，样本限制也不一样，乍一看却完全正确。

与之对应的验证清单如下。

场景	必查项
do 文件跑完之后	查看 log 有没有报错，哪怕 AI 说已经跑通；逐步核对观测值数量；检查变量名和路径是否真实存在。
merge 之后	运行 tab _merge；比较前后的样本量；检查 key 是否重复；手动抽查几条记录。
LaTeX 表格	能否正常编译；数字与 Stata 输出是否一致；固定效应标识是否正确；表格能否放在一页之内。
改动任何文件	运行 git diff，看是否只改了你要求的地方，有没有动到你没提到的文件。

2. 独立性原则，生产者不能兼任审查者

同一个对话不能既负责生成又负责验证，因为生成者天然倾向于为自己的输出辩护。

具体做法是，需要验证时，让一个没有参与生成过程的全新上下文来冷读。在 Claude Code / Codex / Workbuddy / Qwen 办公 / 豆包办公里不必手动另开会话，可以直接让它派生出一个独立的 agent 去审查代码，看变量名是否与真实数据一致，merge 是否保留了全部观测值，固定效应和聚类层级是否正确。作者将其比作请合作者帮忙检查初稿：换一个人看，往往能发现自己反复阅读也没注意到的问题。进一步，还可以专门设置一个负责挑错的对抗式审查 agent，专门寻找研究中的漏洞和潜在问题。

这与 J. Anthony Cookson 在香港科技大学短期课程中讲到的 AI pre-mortem 一脉相承，也就是赶在审稿人之前，先用 AI 找出识别策略中的漏洞。当然，AI 也可能把一些根本不存在的问题当成错误指出来。这时，就需要依靠自己的专业知识进行判断，筛掉这些误报。

3. 自动化原则，让纠错产生复利

规则很简单：第一，同一件事纠正过三次，就把它写成永久规则；第二，每次对话开头都要重复的指令，想办法让它自动加载；第三，总是连在一起做的三步以上的流程，就做成一条命令。

规则的载体是项目里的 CLAUDE.md 文件，Claude Code / Codex / Workbuddy / Qwen 办公 / 豆包办公每次开始对话时都会自动读取它。作者举了自己设定的两条规则作为例子：一是 PDF 中的表格绝不能跨页拆开，二是图表中统一使用国家全称，不使用 ISO3 代码。这些要求只需明确写一次，之后就不用反复提醒 AI 了。

指南把这个过程画成了一条自动化阶梯。

第 1 周：手动纠正，比如反复告诉它变量名叫 UNRATE，不叫 unemployment_rate。

第 2 周：发现自己总在纠正同样的事，就把它写进 CLAUDE.md，这类纠正从此消失。

第 2 个月：把反复执行的多步流程做成 skill，一条斜杠命令就能搞定。

从第 3 个月起：整套配置已经为你量身定制，接手新任务也能很快上手。

对于实际使用中几个容易踩的坑，指南也给出了相当细致的说明。

配置分两层。全局的 ~/.claude/CLAUDE.md 写的是"我是谁、我一贯怎么工作"，项目里的 CLAUDE.md 写的是这个项目的数据、变量，以及哪些文件不许动。两者冲突时，项目文件优先。所以，项目配置里一句"中间表使用 ISO3 简写"，就可能悄悄覆盖掉你的全局规则，连最终表格也跟着变了。建议每次新建项目配置时，开一个新对话，让它对照两份文件找出冲突。

不要把 ~/.claude/ 放进 Dropbox。作者说这是最常见的配置错误，它不会直接报错，表现出来的是时灵时不灵，AI 会突然变笨，忘记规则，或者用错误的方式运行 Stata。需要跨机器同步时，请用 GitHub 加软链接。

规则要具体，能够验证。少写"写好 Stata 代码""小心处理数据"这类笼统的要求，要写成"除非另有说明，标准误一律聚类在企业层面""任何 merge 之后都要报告匹配与未匹配的数量"。

篇幅控制在 500 行以内。配置文件太长，AI 会像赶时间的助手一样跳着读，越靠后的规则越容易被忽略。重要的规则放在最上面，每个月让它帮你精简一次。

4. 一个会话只做一件事

对话越长，AI 越容易出问题。它可能忘记早先的指令，前后说法不一致，甚至反复提出你已经否决过的建议。指南给出的经验法则是，对话超过 30 到 40 轮左右，就可以考虑开启新会话。完成一项任务后及时切换，如果发现回答质量明显下降，也应及时重开。

开启新会话不意味着丢掉已有进度。一个简单的交接办法是，在结束当前对话前，让 AI 生成一份简短的 Markdown 总结，写清楚目前进展、已经完成的工作和接下来需要做的事情。将这份总结粘贴到新会话中，就能接着往下做。指南还介绍了几个常用命令：/clear 用于清空当前对话，/compact 用于压缩上下文，/context 则用于查看上下文的使用情况。

还有一个省 token 的小技巧：同一份 PDF 如果要反复参考，第一次就把它转成 Markdown 保存下来，以后直接让 AI 读 Markdown 文件，省得每次都重新解析 PDF。

核心工作流：计划之后是审查、执行与验证

作者称，这是整份指南中最重要的一页。AI 执行得很快，人很容易跳过计划，直接让它动手。但两种做法的差别，往往要到最后才能看出来。

跳过计划，起步快，收尾慢。代码很快跑通了，结果却出了错，接下来还得花一两个小时排查和调试。

先做计划，前期花 10 分钟审查计划、纠正问题，后续执行就会顺畅得多，需要调试的地方也少得多。

有几个做法值得直接照搬。

先问可行性。复杂任务开始之前，先问它做这件事需要什么，是否可行，还缺什么。作者举过一个例子：一问才发现，分类任务所需的关键变量根本不在数据集里。

使用 Plan 模式。在这种模式下，AI 只制定计划，不直接执行。审查计划时，要重点检查几个方面：它是否正确理解了任务，文件路径和变量名是否准确，有没有擅自加入你没要求的操作，以及执行方案依赖哪些尚未明确说明的假设。

让 AI 主动提问。在计划阶段，AI 可能会询问样本限制、变量定义等细节。这些都属于研究决策，应当由你来决定，不能让 AI 自行采用默认设置。

执行前满足三个条件：第一，计划中的每一步都已核实；第二，任务范围明确，你知道 AI 将创建或修改哪些文件；第三，操作可以撤回，相关改动已经提交（commit）或做好备份。只要有一项不满足，就应退回计划阶段，继续检查和完善。

纠错要具体。别只说"不对，再来一遍"，要明确指出"merge 丢掉了 40% 的观测值，请改用 1:m merge，以 firm_id 为键，保留 master 中的全部观测值"。

指南用 FRED 的月度失业率数据 UNRATE.csv 完整演示了这个循环。其中预设的错误，恰恰就是 AI 在计划里想当然地把变量名写成了 unemployment_rate。

AI 的八种典型失败

失败类型	经济学研究中的典型表现
幻觉	编造变量名（实际变量是 rev，却写成 log_revenue）、文件路径、Stata 命令选项，甚至文献引用。
偷懒取巧	声称某些数据表是冗余的，可以跳过下载；被追问后才承认自己根本没有核实。
凭记忆而非实际检查	仅凭数据库表结构就断言某个字段可用，却没有检查该字段实际有多少条非缺失观测。
擅自扩大任务范围	让它增加一个控制变量，它却顺手修改样本限制、删掉交互项，甚至把 areg 换成 reghdfe。结果系数变了，你却不知道究竟是哪一步导致的。
上下文退化	对话过长后，忘记早先的指令、前后自相矛盾，甚至重复提出已经被否决的建议。
自信地犯专业错误	推荐错误的聚类标准误层级，或提出无法解决内生性问题的识别策略，却依然表现得十分笃定。
悄悄改变数据处理方式	合并数据时丢弃观测值，擅自更改 merge 类型或样本范围，却没有明确报告这些变化。
配置文件膨胀	CLAUDE.md 越写越长，规则堆积在文件深处，重要要求难以被发现和执行。

其中，第六类错误最难防范，因为识别它需要扎实的领域知识。指南给出的判断标准很直接：如果换成自己亲手做，你会做出同样的选择吗？如果心里没底，就先停下来，查阅文献或向同行请教。

用作者的话说，AI 可以协助你完成计量分析，却无法替代你自己的计量判断。

作者团队常用的 skills 主要包括以下几条：

/audit-paper：论文全面审校，查错别字、语法、行文、结构，乃至 AI 写作痕迹。

/simulate-referee：模拟一位编辑加两位审稿人的同行评审。

/lit-review-verify：逐条抽取论断与引用的配对，核查被引文献是否真的支持该论断。

/audit-code：系统审查 Stata do-file 中的宏定义、路径、一致性和未使用变量。

/review-plan：对计划做结构化压力测试。

/pdf-chunker、/compile-latex、/overleaf 等文档工具。

落地清单：明天就能开始做的八件事

一、建立精简的规则文件。CLAUDE.md 初始只写 3 到 5 条核心规则。同一个错误每被纠正两次，就把相应的教训补充为一条规则。

二、先计划，再执行。每项任务都先让 AI 制定计划，逐条审查并确认无误后，再开始执行。

三、执行前后都检查代码。修改前先提交一次 Git commit，保留可恢复的版本；执行后检查 git diff，确认实际改动与预期一致。

四、让独立上下文负责验证。不要让编写代码的同一会话直接审查自己的成果。另开一个会话，独立检查代码、数据处理过程和回归结果。

五、持续追踪样本量 N。每一步数据处理后都要记录样本量，凡是样本发生变化，都必须查明原因并作出合理解释。

六、不要把计量判断外包给 AI。识别策略、内生性处理、固定效应设定和标准误聚类层级等关键决策，必须由研究者自己把关。

七、一个会话只做一件事。对话达到 30 至 40 轮左右时，及时整理进度、完成交接并开启新会话，避免上下文过长导致指令遗忘和判断失误。

八、保护敏感数据。不要将敏感数据上传给未经授权的 AI 工具。使用前应确认工具的数据处理方式、访问权限和所在机构的相关规定。

下面是一份按照中国微观数据的使用习惯改写的项目 CLAUDE.md 示例，供大家参考。

指南原文可在 https://adrienmatray-ai.com 查阅。文中提到的这些专门针对经济金融商学的 skills，包含执行步骤、检查清单、脚本调用、质量控制规则和交付要求。如果你想获取更多经济学实证研究与 AI 工具结合的资源，可以在云栈社区找到相关的讨论与共享内容。