STATA CLI：我把 Stata 接进了命令行，也接进了 AI 工作流

为什么要做这个工具

我写 stata-cli，不是因为想再造一个 Stata，也不是因为命令行天然高级，而是因为 Stata 明明是很多实证研究者最熟悉的工具，却一直很难进入现代自动化工作流。

做计量、做实证、做政策评估的人都知道，Stata 的优点很直接：语法短，命令稳，结果可信，很多经典流程几行代码就能跑完。问题也同样直接：它太像一个封闭的桌面软件了。

你可以在 Stata 里写 do-file，可以点菜单，可以看日志，但一旦你想把它放进终端、脚本、CI、AI Agent 或者更大的数据流水线里，事情马上变得别扭。

Python 可以这样用：

bash 复制代码

python analysis.py

R 可以这样用：

bash 复制代码

Rscript analysis.R

但很多 Stata 用户的真实工作方式仍然是：打开 GUI，粘贴命令，点运行，复制结果，再发给别人或喂给 AI。

这不是研究者的问题，是工具接口的问题。

到了 AI Agent 已经能自动写代码、跑测试、读日志、修 bug 的今天，如果 Stata 还只能被人手动打开，它就会被挡在自动化流程外面。

所以我做了 stata-cli：让 Stata 可以像 Python、R、Node 一样，从命令行被调用、被组合、被脚本控制，也被 AI 调用。

它到底是什么

一句话说，stata-cli 是一个把 Stata 能力暴露到终端里的命令行工具。

安装之后，你可以直接在 shell 里运行 Stata 代码：

bash 复制代码

pip install stata-cli

bash 复制代码

stata-cli run "display 1+1"

也可以跑一段完整分析：

bash 复制代码

stata-cli run "sysuse auto, clear
regress price mpg weight
predict yhat"

还可以查看数据、查帮助、执行 do-file、导出图表：

bash 复制代码

stata-cli data --if "price>10000"
stata-cli help regress
stata-cli do model.do

这些事情本来 Stata 都能做，stata-cli 做的不是替代 Stata，而是给 Stata 补上一个更适合自动化时代的入口。

为什么是 CLI

我选择做 CLI，不是因为命令行看起来更酷，而是因为 CLI 几乎是人和 AI Agent 都能稳定理解的最小公共接口。

对人来说，CLI 的好处是直接：一行命令对应一个动作，输入和输出都在终端里，能复制，能保存，能写进脚本，也能交给 cron、Makefile、GitHub Actions 或任何自动化工具继续处理。

对 AI Agent 来说，CLI 更重要。大语言模型天然擅长生成文本，而命令行本质上也是文本接口。相比点击 GUI，生成一条明确的命令、读取一段明确的输出、再决定下一步，显然更适合 Agent 工作。

CLI 还有一个被低估的优点：它是可组合的。一个命令的输出可以成为另一个命令的输入，一个分析步骤可以被 shell 脚本串起来，一个 do-file 可以被批量运行。复杂工作流不是靠一个巨大的界面完成，而是靠很多小而稳定的命令拼起来。

它也足够轻。命令行工具不要求用户打开窗口，不要求额外学习一套交互逻辑，也不绑定某个编辑器或平台。只要系统能跑命令，它就能进入你的工作流。

更重要的是，CLI 通常是自描述的。--help、子命令、参数说明，这些东西不只给人看，也给 Agent 看。一个设计得好的 CLI，等于把工具的用法直接暴露给了自动化系统。

这也是为什么 Claude Code 这类工具可以每天通过 CLI 跑大量真实开发流程。不是因为 CLI 古老，而是因为它稳定、明确、可组合、可验证。

所以 stata-cli 不只是"把 Stata 放到终端里"。更准确地说，它是把 Stata 变成一种 Agent 可以调用的工具：命令明确，输出稳定，支持 JSON，行为可预测。

当输出可以结构化，Agent 就不用在一大段日志里猜结果；当命令行为确定，Agent 才能可靠地重复执行；当接口足够轻，Stata 才能真正进入自动化工作流。

我真正想解决的问题

很多工具的问题，不在于功能少，而在于它不能被别的工具稳定调用。

Stata 在统计分析上很成熟，但它长期缺少一个好用的命令行入口。这个缺口在以前只是麻烦，在 AI Agent 出现之后就变成了硬伤。

如果 AI 想帮你做一轮实证分析，它需要能完成几件事：写 Stata 代码，执行 Stata 代码，读取 Stata 输出，根据结果决定下一步。

过去卡住的是第二步和第三步。

stata-cli 的目标就是把这两步打通。

比如 AI 可以直接运行：

bash 复制代码

stata-cli --json run "sysuse auto, clear
summarize price mpg weight"

它拿到的不只是屏幕上的一段文本，而是更容易解析的结构化输出。这样 AI 就可以判断变量是否缺失、回归是否报错、模型是否需要调整，而不是让用户在中间来回复制粘贴。

这件事看起来只是少点几下鼠标，实际改变的是工作流：Stata 从一个需要人盯着操作的软件，变成了一个可以被程序调度的分析引擎。

三个我自己最常用的场景

1. 让 AI 真正跑 Stata，而不是只写 Stata

以前让 AI 帮忙写 Stata 代码，它最多给你一段 do-file。代码能不能跑、结果对不对、报错在哪里，还是要你自己打开 Stata 验证。

有了 stata-cli，AI 可以直接执行它刚写的代码：

bash 复制代码

stata-cli run "sysuse auto, clear
regress price mpg weight
estat vif"

这时 AI 不只是"代码生成器"，而是能进入"写代码---运行---读结果---修改"的闭环。

对实证研究来说，这个闭环很重要。因为真实分析很少一次写对，变量名可能错，样本筛选可能漏，模型设定可能需要调整，回归结果也可能提示你下一步该换方法。

2. 批量跑 do-file，不再靠手工排队

如果你有几十个模型文件，传统做法很容易变成机械劳动：打开、运行、等结果、看日志、再打开下一个。

用命令行之后，这件事可以交给 shell：

bash 复制代码

for f in models/*.do; do
  stata-cli do "$f"
done

这不是炫技，而是把重复劳动从人的时间里拿出去。

真正有价值的人力应该花在判断模型、解释结果、检查识别策略上，而不是盯着软件窗口等它跑完。

3. 快速验证一个想法，不必启动完整界面

很多时候我只是想看一眼变量分布，或者验证某个命令是不是能跑，并不想打开 Stata GUI。

现在可以直接在终端里做：

bash 复制代码

stata-cli run "sysuse auto, clear
histogram price"

如果代码生成了图，stata-cli 会自动把图导出成 PNG，并把路径打印出来。

这类小体验很容易被低估，但它会改变你和工具互动的频率。启动成本越低，你越愿意多试几次；试得越快，分析迭代也越快。

守护进程模式：解决 Stata 启动慢的问题

命令行调用 Stata 最大的现实问题，是启动成本。

PyStata 每次初始化通常要几秒钟。如果只是偶尔跑一个 do-file，这点时间可以接受；如果 AI Agent 要连续调用十几次，每次都等几秒，体验就会断掉。

所以我加了守护进程模式：

bash 复制代码

stata-cli daemon start

启动后，PyStata 会常驻后台，后续命令会自动路由到这个后台进程：

bash 复制代码

stata-cli run "display 1+1"

在我的测试里，简单命令可以从几秒降到几十毫秒级。这个差别不是"快一点"，而是从"不适合交互"变成"可以连续调用"。

用完之后可以关掉：

bash 复制代码

stata-cli daemon stop

对 AI Agent 来说，守护进程模式尤其关键。因为 Agent 的工作方式不是一次性跑完全部代码，而是不断试探、观察、修正、再运行。没有低延迟，这个循环就很难顺畅。

功能一览

需求	命令
执行一段 Stata 代码	`stata-cli run "..."`
执行 do-file	`stata-cli do script.do`
查看当前数据	`stata-cli data --if "条件"`
查看 Stata 帮助	`stata-cli help 命令名`
自动导出图表	检测到图表后导出 PNG
中断正在运行的任务	`stata-cli stop`
管理守护进程	`stata-cli daemon start/stop/status`
输出 JSON	`stata-cli --json run "..."`
输出精简结果	`stata-cli --compact run "..."`
从管道读取代码	`echo "display 1"

这些功能的设计原则很简单：让 Stata 尽量像一个普通命令行程序，能输入，能输出，能被组合，能被自动化系统理解。

一个更接近真实使用的例子

我现在会这样让 AI 帮我做分析：

帮我用 auto 数据集做一个 price 对 mpg 和 weight 的回归，顺便检查一下多重共线性。

AI 可以直接调用：

bash 复制代码

stata-cli run "sysuse auto, clear
regress price mpg weight
estat vif"

然后它根据输出告诉我：weight 显著，mpg 在这个设定下不显著，VIF 没有明显异常，下一步可以考虑变量变换、加入控制变量，或者检查价格和重量之间的非线性关系。

这里最重要的不是 AI 会说这些话，而是它能基于实际运行结果说这些话。

如果没有命令行接口，AI 只能猜；有了命令行接口，AI 才能验证。

安装和前提

stata-cli 依赖 Stata 自带的 PyStata 接口，所以你的电脑上需要已经安装 Stata 17 或更高版本，并且需要有可用许可证。

推荐用 pip 安装：

bash 复制代码

pip install stata-cli

也可以用 npm 安装：

bash 复制代码

npm install -g stata-cli

安装后先检测 Stata 路径：

bash 复制代码

stata-cli detect

再跑一个最小例子：

bash 复制代码

stata-cli run "display 1"

如果自动检测不到 Stata，可以手动设置路径：

bash 复制代码

export STATA_PATH="/Applications/Stata"
stata-cli run "display 1"

致谢：它不是凭空长出来的

这个项目不是从零开始凭空冒出来的。

stata-cli 是我基于 hanlulong 的开源项目 stata-mcp 进行二次开发得到的命令行工具。原项目把 Stata 接入 MCP 的思路给了我很大启发，也证明了 Stata 完全可以进入 AI 工具链，而不必一直停留在 GUI 时代。

项目地址在这里：

https://github.com/hanlulong/stata-mcp

在这个基础上，我主要把使用入口进一步命令行化，补了更适合日常终端调用、批处理、JSON 输出和守护进程的能力。换句话说，stata-mcp 更像是把 Stata 接到 AI 协议里，stata-cli 则更强调把 Stata 变成一个随手可用的 CLI 工具。

感谢原作者把这个方向开源出来。很多时候，一个开源项目最重要的价值不只是代码本身，而是它把一个原本模糊的可能性变成了可以继续往前走的路径。

开源地址

stata-cli 也是开源项目，使用 MIT 协议：

GitHub：https://github.com/ashuiGordon/stata-cli
PyPI：https://pypi.org/project/stata-cli/

如果你也经常在 Stata、终端、Python、R、AI Agent 之间来回切换，应该能理解这个工具想解决的痛点。

我不认为 Stata 需要变成 Python，也不认为所有研究者都应该放弃自己熟悉的工具。真正需要改变的是接口：好工具应该能被人使用，也应该能被其他工具调用。

Stata 本身是可靠的分析工具。stata-cli 做的事很小，就是给它打开一扇门，让它能进入脚本、终端和 AI 工作流。