4 Agent 工作流
这一讲是全课的落点。前三讲铺好了地基——最小的 Stata 入口、notebook 里的 AI 补全、对话式 AI 与执行型 Agent 的分工。现在我们把「规划 → 执行 → 审查」放进一个真实的项目里跑一遍。
4.1 一切从项目文件夹开始
Agent 之所以能接管一份工作，前提是这份工作被组织成了一个规范的项目文件夹。本课演示用的 demo/ 就是这样一个文件夹，大致结构是：
demo/
├── README.md # 任务说明书：目标、数据说明、分析要求、验收标准
├── data/ # 三个 CSV 数据文件
├── code/ # 分析脚本（由 Agent 生成）
├── outputs/ # 结果：表格、图形、report
└── ...README.md 就是第 3 讲讲的任务说明书：它告诉 Agent 数据是什么、要做什么分析、结果要以什么形式交付。数据放在 data/、代码放在 code/、结果放在 outputs/——分门别类，Agent 和人都不会迷路。
4.2 一个循环：计划 → 确认 → 执行 → 检查
拿到项目后，正确的节奏不是「一句话让它跑通」，而是一个可以反复迭代的循环。
计划→确认→执行→检查↺
第一步，让它先给计划，别急着改。 进入 demo/ 文件夹启动 Claude Code 或 Codex，第一条指令是：
请阅读 README.md 和 data/ 下的数据，先给出一份研究计划，
说明你打算怎么清洗数据、跑哪些模型、输出什么结果。先不要动手改文件。第二步，人来确认和补充。 看它的计划对不对、有没有漏。确认时可以补充具体要求（例如”关键变量要缩尾”“回归表要同时报 TWFE 和现代 DID 估计量”），让计划更贴合意图。这一步是「人在环」的关键——你在把关方向，而不是把方向也交出去。
第三步，确认后再让它执行。 计划敲定，让它按计划清洗数据、写脚本、跑模型、生成结果。一份写得清楚的任务说明书，能让这一步尽量一次到位。
第四步，检查产出。 跑完不等于做对了。检查有三个抓手：
- 看它改了什么（
diff）：Agent 说改了哪些文件，逐一核对，别只看它的文字总结。 - 看 log：Stata 的运行日志里有没有报错、有没有被
capture悄悄吞掉的错误。学会看 log，比追求”不报错”更重要。 - 核对结果：表格里的系数、样本量、图形是否合理，能不能对得上数据。
发现问题，就带着具体反馈回到第一步，再走一轮。这个「计划 → 确认 → 执行 → 检查」的循环，才是 AI 辅助实证的真正工作方式。
4.3 几个必会的 Claude Code 操作
要顺畅地跑完上面这个循环，有几个 Claude Code 的操作值得先形成肌肉记忆（Codex 的对应操作类似）：
- 文件夹即工作区：在项目文件夹里打开终端、输入
claude就地启动，它就以当前文件夹为工作区。新项目可用/init生成CLAUDE.md——这是每次启动都会自动读取的「项目记忆」，把项目背景、文件夹用途、工作规则写在里面。 - 三个高频前缀：
@引用文件（如@README.md 开始第一步）、#把一条规则永久写进记忆、!直接执行 shell 命令（如! git status）。 - 权限模式（
Shift+Tab循环切换）：计划模式只读不写、先出方案；自动接受直接执行文件编辑；默认模式每步征求同意。推荐节奏——复杂任务先切计划模式、方案确认后切自动接受、敏感改动再切回默认。（部分 Windows 版本Shift+Tab会跳过计划模式，可直接输入/plan。） - 两个救命键：
Esc打断正在跑的任务（已完成部分保留）；连按两次Esc打开「回退」菜单，把代码和对话恢复到之前的检查点。开工前先git init，与Esc Esc双保险。 - 上下文管理：对话越长越容易”犯糊涂”（上下文快满了，且每轮都更费 token）。
/context看占用、/compact压缩历史、/clear清空重开一个话题；真正要长期记住的规则用#写进CLAUDE.md，别指望对话历史。
不要只看 AI 的解释，要看它实际改了什么——每轮花半分钟核对 diff，是成本最低的质量保险。
4.4 为什么要看那张对照表
demo 的点睛之笔，是一张 TWFE vs csdid / jwdid vs 模拟真值的对照表。因为 demo 的数据是模拟生成的，所以真值是已知的。把传统的双向固定效应（TWFE）估计量、现代交叠 DID 估计量、以及真值放在一起对照，谁离真值近、谁偏得多，一目了然。这张表自己会说明：为什么在交叠处理的场景下，值得学新的 DID 方法。（方法本身的展开，见暑期班与延伸阅读。）