动因

好久没更新了，有了 AI 后，感觉干活变得更累了。。。用 AI 干活还有一件挺烦的事，同样的话得反复说。数据放在哪里、变量怎么定义、回归表怎么导出、文章应该用什么语气，换一个对话又得重新交代。有时刚纠正完，下一次它又照着自己的习惯来了。

最近高强度使用 AI 跑数据和写文章，也顺手把这些反复交代的事情整理了一遍，慢慢拼出了一套科研工作流。从本地数据管理、Stata 回归，到文献入库 Zotero、Word 撰写和最后检查，都有对应的规则和 skill。

这篇推文就想聊聊这套工作流怎么搭、平时怎么用。主要面向经常和 Stata、Python、Zotero、Word 打交道的经管类研究者，尤其是还在一边做研究、一边折腾工具的硕士和博士。大家的习惯肯定不一样，下面这些就当作一个参考，有更顺手的办法也欢迎留言讨论。

一、先把干活的工具准备好

这套工作流会涉及几个工具，不过没必要一下子全部装齐。可以先把自己最常用的环节接通，再慢慢往两头扩展。比如平时最头疼的是改 Stata 代码，就先从 Stata 开始；如果文献下载和整理已经占掉很多时间，就先处理 Zotero。

1. AI agent：负责接任务、调用工具

最近用得比较多的是 Codex，下面也主要按这类 agent 的使用方式来讲。Claude Code、WorkBuddy、Trae 等工具也可以按各自的能力接入，具体选哪个，看自己的使用习惯就好。

2. Zotero：把找到的文献管起来

Zotero 是我一直在用的文献管理工具。平时找到一篇文献，可以把条目和 PDF 放进去，再按主题归类。写文章的时候，也方便回头找出处、插入引用。

接上 AI 后，我希望它能把“找到了”后面的事情也处理掉：先看库里有没有这篇，再核对条目信息，放进合适的分类，按需要补上 PDF。否则浏览器里开了一堆标签页，下载文件夹里堆了一堆论文，过几天还是得自己重新找。

3. Git：记录代码和说明文件怎么改过

让 AI 改代码，最怕它改了一大段，自己还没看清就继续往下跑。有 Git 记录版本，至少可以回头比较改动，找回已经提交过的内容。还没提交、也没有备份的文件，就不能指望 Git 帮忙恢复了。

Git 还有一个挺实用的用途：给下一个对话留线索。每完成一轮代码修改，把做了什么、为什么改、验证到了哪一步写清楚。换一个 agent 或重新开对话时，它可以先读项目说明和提交记录，少问几遍“我们之前做到哪里了”。不过提交记录也只能记录已经写下来的事情，当前任务和待办还是要放在项目文档里。

AI 会把代码、配置和必要说明作为版本管理的重点。原始数据和大量运行产出另行管理，没必要都塞进 Git。Word 文件虽然也能保存版本，但正文改动通常没有代码那么容易直接比较。

4. Obsidian：给本地数据配一份说明书

Obsidian 在这里主要用来管理 Markdown 数据文档。每份数据对应一份说明，记录它包含哪些变量、匹配键是什么、覆盖哪些年份、样本有多少，以及数据来源和构造方法。

这样，AI 接到“找一个变量来做回归”的任务时，就可以先读数据目录和说明，确定需要哪份文件，再去读取数据。省得它在电脑里翻箱倒柜，也省得自己隔一段时间就忘记某个 dta 当初是怎么做出来的。

这些说明可以让 AI 帮忙生成，但变量、年份、缺失情况和样本量得从实际数据里核验。

5. VS Code 和 Stata-MCP：把 AI 和 Stata 接起来

VS Code 其实只是我的 Stata-MCP 启动开关。这套工作流主要通过 Stata-MCP 运行 Stata。可以把 MCP 理解成 AI 调用外部工具的接口：AI 写好代码后，通过这个接口把任务交给 Stata，再读取返回的结果。

6. 数据同步和备份：别把所有东西押在一台电脑上

我通常会把数据备份到移动硬盘，也会用百度网盘的同步空间管理文件（OneDrive 也有类似功能）。数据越来越多以后，已经归档、暂时用不上的旧版文件，可以按同步工具的设置释放本地副本，需要时再下载。

7. Stata、Python 和 Word：完成分析和交付

回归和结果导出主要交给 Stata，Python 则负责一些配套工作，比如处理文件、生成数据说明、提取和编辑文档。最后形成的稿件和回归表，还是放到 Word 里继续调整。

Python 环境可以用 Anaconda、conda 或 uv 等工具管理，按已有习惯来就好。环境搭好后，把实际使用的环境和依赖记录到 AGENTS.md，避免 AI 每次执行任务都临时安装一套东西，也方便以后重新运行。

二、工具接好了，还得告诉 AI 怎么干活

这部分内容是我让 Codex 根据自己理解生成的关于我的工作流介绍，整体来看它基本能把我目前设定的约定和限制梳理清楚。

工具负责执行，规则决定它执行时应该遵守什么。比如同样是“帮我整理数据”，AI 可以给出很多种做法：改名、合并、去重、生成新变量，甚至顺手删掉它认为没用的文件。哪些能做、按什么口径做，得提前写清楚。

这里用到两类文件：AGENTS.md 和 skill。前者记录全局或项目约定，后者记录某类任务的具体方法。skill 通常以 SKILL.md 为入口，必要时再配上参考文件和脚本。规则本身不会凭空增加工具能力，运行 Stata、操作浏览器或编辑 Word，仍然需要相应的连接和环境。

下面这张图可以先看个大概：

1. AGENTS.md：先把共同约定写下来

有些要求几乎每个任务都会用到，比如默认用中文、保留已有改动、不要随便覆盖文件、完成后说明改了什么。这些放在全局 AGENTS.md 里，比每次复制一段提示词方便。

项目里的具体设定则放在项目自己的说明或 AGENTS.md 中：数据在哪里、变量怎么定义、样本怎么筛选、固定效应和聚类怎么设。否则把某篇文章的设定写成全局默认，下一篇文章也照着跑，就很容易出问题。

全局规则不用写成一本操作手册。通用要求留在这里，具体怎么跑回归、怎么检查 Word，交给对应的 skill。

2. my-data-management：先把数据和文档理清楚

这个 skill 负责数据入库、分类、命名、归档、指标构造，以及配套说明的生成。

收到一份新数据后，先确认来源、覆盖期间、观测层级和匹配键，再决定放在哪里、叫什么名字。如果涉及旧数据替换，就先归档旧版，按确认的口径重新处理，最后核验输出并更新说明。

查询已有数据时，则先看目录和文档，文档不足再读数据本体；遇到云占位文件，先停在读取之前。这样既能少翻文件，也能避免为了查一个变量，意外把一大批归档数据拉回本地。

还有一条挺实用：如果数据说明是脚本生成的，就修改生成脚本或配置后重新生成。直接手改说明，下次重建时又会被覆盖。

3. my-stata-skill：按既定口径写代码、跑回归

这个 skill 管 Stata 的代码风格、数据处理、模型运行和结果导出。平时常用的命令、变量处理习惯、表格格式，都可以整理进去。

比如让 AI 跑一个基准回归，它要先读取项目设定，借助 my-data-management 搜索本地数据库相关变量，确认解释变量、被解释变量、控制变量、固定效应和聚类层级，再写代码。运行后检查实际输出，按约定保存估计结果、补充统计量，并导出 Word 表格。

报错的时候，可以让 AI 查当前命令的帮助和已有错误记录，但不能为了让代码跑通，悄悄换一个模型或删掉一批样本。跑通了以后，还得知道跑的究竟是不是原来要估计的东西。

4. my-zotero-management：把文献入库这段接起来

这个 skill 负责 Zotero 导入、查重、分类和补 PDF，也记录浏览器和具体站点的操作方法。

大致顺序是：先查本地库，已有条目就处理分类或附件；没有才继续找来源，核对标题、作者、年份和 DOI，再导入。遇到需要登录或没有访问权限的页面，也要按实际情况处理，不能假装已经拿到了全文。入库后还要回查条目和附件。浏览器弹出“保存成功”，不一定代表保存到了正确的条目下面。

至于 Word 里的 Zotero 引用域，放在写作 skill 的引用模块里处理。文献已经进入 Zotero，和正文引用还能正常联动，是两件需要分别检查的事。

5. my-writing-skill：让文章沿着自己的习惯往下写

这个 skill 记录论文写作中的措辞、结构、变量定义、结果解释、表注和 Word 格式要求。中英文可以分开维护，避免 AI 把英文句式直接搬进中文里。

写结果部分时，先看已经核验的表格和变量口径，再组织文字。系数方向、显著性、样本和统计量都要对应；证据只能支持到哪里，就写到哪里。

润色时则尽量保留原意和证据强度。尤其是已经人工调整过的 Word，局部修改就改局部，不要一言不合把整篇稿子重新生成一遍，弄丢公式、表格或引用域。

6. my-doc-check：写完以后单独检查

文稿到了检查阶段，可以明确调用这个 skill，检查格式、结构、引用和前后一致性。它默认输出独立报告，方便自己决定哪些地方要改，也避免检查着检查着就把原稿改了。

检查时先读全文和文档结构，核对标题层级、变量名称、表号、数字、公式和引用。只有需要确认分页、裁切或对象显示时，再看相应页面；如果要求完整视觉验收，就按那个范围检查。

这里也得区分“内容检查”和“实际显示”。提取出来的文字没有问题，不代表 Word 里的公式、浮动对象和引用域一定显示正常。检查报告应该说清楚看了什么、哪些还需要在 Word 中确认。

7. pref：少重复几遍同样的话

前面这些规则用久了，肯定会发现需要调整的地方。pref 就负责在明确调用时，把本次任务里确认的、可以复用的偏好整理到合适的位置。

比如某条要求适用于所有项目，就放全局规则；只和 Stata 有关，就放 Stata skill；只属于当前论文，就留在项目里。已经有同样的要求，就合并或落实，不再追加一条意思差不多的规则。

它也不会因为你这次说“这张表保留四位小数”，就默认以后所有表格都这么做。临时要求和长期习惯得分清楚，否则规则越来越多，AI 反而越来越不知道该听哪一条。

8. 其他辅助 skill：需要的时候再用

除了上面几个主要环节，还有一些工具适合按任务调用：

• • markitdown：把 PDF、Office 等文件转换成 Markdown，方便读取和整理。转换后缺失的公式、表格和脚注，仍然要回原文件确认。
• • web-access：需要联网检索、读取网页或操作浏览器时使用。本地材料足够，就不用为了一个简单任务先开一堆网页。
• • humanizer：处理过度整齐、套话太多的表达，让文字更自然，同时保留原意。
• • academic-research-suite：用于研究设计、文献综述、学术评审等任务，帮助系统地梳理问题和证据。

这些 skill 不用每次全部加载。任务做到哪一段，就读取那一段需要的规则和参考材料。

三、我工作流的常用环节

下面是一些日常对话，部分内容只是示例，以自己习惯为主即可。

1. 数据入库环节

我：

入库 D:/path/to/data.dta

AI：

我将使用 my-data-management 技能，先核对来源、数据结构和本地文件状态，再按现有分类规则完成入库和文档更新。

……

已入库：2001—2025 年，39,726 条记录，5,079 家公司。

• • 处理数据：已按分类和命名规则保存。
• • 数据说明：已补充变量定义、来源和参考文献，更新数据库导航。

原始文件另行保留，未筛选、缩尾或补零。公司年度键唯一，全量来源值及缺失位置一致，来源内部公式核验通过。相关代码、配置和文档已分别提交。

2. 变量构造环节

我：

构造指标 X 并入库

AI：

我会使用 my-data-management，先读取项目中的指标定义和数据说明，确认所需变量、匹配键及时间口径，再完成构造；涉及 Stata 代码时，同时使用 my-stata-skill。

……

指标 X 已构造完成，交付内容包括：

• • 指标数据：保留企业、年份、来源字段和新构造变量。
• • 构造代码：从输入数据到最终指标的处理步骤可重新运行。
• • 指标说明：记录定义、单位、覆盖范围、缺失值处理和来源。

已检查匹配键、合并情况及缺失分布，并按原定义独立复算，与输出一致。构造过程中未擅自补零、去重或改变样本口径。

3. 回归分析环节

我：

按 研究设计.docx 跑基准回归和稳健性检验，告诉我哪些结果可以写进正文

AI：

我会先用 markitdown读取 研究设计.docx 的内容，核对项目设定，确认模型、样本与导出要求，再运行回归并读取实际结果。

……

基准回归和指定的稳健性检验已运行完成。

• • 回归代码：已保存本次模型和导出步骤。
• • Word 表格：包含系数、标准误、样本量及固定效应标识。
• • 结果说明：

……

4. Zotero 文献入库环节

我：

把这几篇文献放进 Zotero 对应的分类，先查重，已有的不要重复导入，能拿到 PDF 的也一起补上。

AI：

我会使用 My Zotero Management 技能，核对文章信息和库内重复项后导入 Zotero。

……

已确认文章是 Acemoglu 与 Robinson 的《Culture, Institutions, and Social Equilibria: A Framework》（JEL，2025），库内未发现重复项。我会保存出版商元数据和全文 PDF，并归入“理论基础与经典文献”。

……（然后 AI 去操作我的谷歌浏览器模拟点击 Zotero Connector 导入文献）

已导入 Zotero：Culture, Institutions, and Social Equilibria: A Framework，Acemoglu 与 Robinson，JEL（2025）。

• • 已保存并核验 56 页全文 PDF。
• • 已归入“2_主题库 → 00_理论基础与经典文献”。
• • 回查确认仅有一个匹配条目。

5. 初稿撰写环节

我：

根据已有回归结果，帮我写一下初稿研究设计和结果部分

AI：

我会使用 my-writing-skill，先读取当前稿件、变量定义和回归表，再按你的写作习惯补充结果分析。

……

研究设计和结果分析部分已写入 XXXX-20261004.docx。

本次已完成正文与文档结构核对；Word 中的实际分页和引用联动仍需在对应环境中确认。

6. 格式检查环节

我：

@my-doc-check D:/path/to/file

AI：

我会使用 my-doc-check 阅读全文，按指定范围检查格式、引用与一致性，并单独输出中文报告。

……

全文检查已完成，报告已另行保存，原稿未修改。

报告按问题位置列出依据和建议，区分已确认问题与待核实事项，覆盖标题层级、编号、表注、变量名称及文献引用对应关系。

本次完成文字和文档结构检查，未进行逐页视觉验收。需要在 Word 中确认的公式显示、分页或引用联动，已在报告中标明。

7. 调整偏好环节

我：

@pref 你在写论文的时候不要把第三方数据来源名称写到变量数据来源和定义中，应该看到这个数据背后的真实来源，比如 CSMAR 、CNRDS 、国家统计局、地区统计年鉴、企业年报文本等等

AI：

我会按 pref 流程保存这条写作规则：数据库文档记录获取渠道，论文的变量来源与定义填写有证据支持的底层来源；底层来源不明时保留待核实，不自行推定。

……

已更新规则，中英文论文统一执行：

• • 论文的数据来源、变量定义和表注：写已核实的底层真实来源，如 CSMAR、CNRDS、国家统计局、地区统计年鉴、企业年报文本。
• • 第三方名称及文件名后缀：仅用于数据库内部追溯，不带入论文，如马克数据网、众鲤数据网、数据皮皮侠等。
• • 底层来源不明时先核实，不猜写来源；第三方现成指标也不写成作者自行计算。

已修改写作规则，并在数据管理规则加入对应引用。

四、可以从哪里开始？

不用先收集几十个 skill。可以先挑一件自己经常让 AI 做、又经常需要返工的事，把要求写下来，跑一遍，再根据实际问题补规则。

比如经常要改 Stata 代码，就先整理代码风格、模型设定、结果导出和核验要求。这个环节稳定后，再补数据说明和项目记录；用到文献和写作时，再接 Zotero 和 Word。

现成的 skill 可以拿来参考，但涉及自己的数据、命令和写作习惯，还是要逐项调整。尤其不要直接把别人项目里的变量、路径和模型当成默认设定。

折腾这套东西，前期确实有点费时间。希望用久以后，反复解释和找文件能少一些，留下更多时间去想研究问题、检查结果。至于能不能真的早点下班，还得继续观察。。。