为什么要做这个工具
我写 stata-cli,不是因为想再造一个 Stata,也不是因为命令行天然高级,而是因为 Stata 明明是很多实证研究者最熟悉的工具,却一直很难进入现代自动化工作流。
做计量、做实证、做政策评估的人都知道,Stata 的优点很直接:语法短,命令稳,结果可信,很多经典流程几行代码就能跑完。问题也同样直接:它太像一个封闭的桌面软件了。
你可以在 Stata 里写 do-file,可以点菜单,可以看日志,但一旦你想把它放进终端、脚本、CI、AI Agent 或者更大的数据流水线里,事情马上变得别扭。
Python 可以这样用:
python analysis.pyR 可以这样用:
Rscript analysis.R但很多 Stata 用户的真实工作方式仍然是:打开 GUI,粘贴命令,点运行,复制结果,再发给别人或喂给 AI。
这不是研究者的问题,是工具接口的问题。
到了 AI Agent 已经能自动写代码、跑测试、读日志、修 bug 的今天,如果 Stata 还只能被人手动打开,它就会被挡在自动化流程外面。
所以我做了stata-cli:让 Stata 可以像 Python、R、Node 一样,从命令行被调用、被组合、被脚本控制,也被 AI 调用。
它到底是什么
一句话说,stata-cli 是一个把 Stata 能力暴露到终端里的命令行工具。
安装之后,你可以直接在 shell 里运行 Stata 代码:
pipinstallstata-clistata-cli run"display 1+1"也可以跑一段完整分析:
stata-cli run"sysuse auto, clear regress price mpg weight predict yhat"还可以查看数据、查帮助、执行 do-file、导出图表:
stata-cli data--if"price>10000"stata-clihelpregress stata-clidomodel.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 可以直接运行:
stata-cli--jsonrun"sysuse auto, clear summarize price mpg weight"它拿到的不只是屏幕上的一段文本,而是更容易解析的结构化输出。这样 AI 就可以判断变量是否缺失、回归是否报错、模型是否需要调整,而不是让用户在中间来回复制粘贴。
这件事看起来只是少点几下鼠标,实际改变的是工作流:Stata 从一个需要人盯着操作的软件,变成了一个可以被程序调度的分析引擎。
三个我自己最常用的场景
1. 让 AI 真正跑 Stata,而不是只写 Stata
以前让 AI 帮忙写 Stata 代码,它最多给你一段 do-file。代码能不能跑、结果对不对、报错在哪里,还是要你自己打开 Stata 验证。
有了 stata-cli,AI 可以直接执行它刚写的代码:
stata-cli run"sysuse auto, clear regress price mpg weight estat vif"这时 AI 不只是“代码生成器”,而是能进入“写代码—运行—读结果—修改”的闭环。
对实证研究来说,这个闭环很重要。因为真实分析很少一次写对,变量名可能错,样本筛选可能漏,模型设定可能需要调整,回归结果也可能提示你下一步该换方法。
2. 批量跑 do-file,不再靠手工排队
如果你有几十个模型文件,传统做法很容易变成机械劳动:打开、运行、等结果、看日志、再打开下一个。
用命令行之后,这件事可以交给 shell:
forfinmodels/*.do;dostata-clido"$f"done这不是炫技,而是把重复劳动从人的时间里拿出去。
真正有价值的人力应该花在判断模型、解释结果、检查识别策略上,而不是盯着软件窗口等它跑完。
3. 快速验证一个想法,不必启动完整界面
很多时候我只是想看一眼变量分布,或者验证某个命令是不是能跑,并不想打开 Stata GUI。
现在可以直接在终端里做:
stata-cli run"sysuse auto, clear histogram price"如果代码生成了图,stata-cli 会自动把图导出成 PNG,并把路径打印出来。
这类小体验很容易被低估,但它会改变你和工具互动的频率。启动成本越低,你越愿意多试几次;试得越快,分析迭代也越快。
守护进程模式:解决 Stata 启动慢的问题
命令行调用 Stata 最大的现实问题,是启动成本。
PyStata 每次初始化通常要几秒钟。如果只是偶尔跑一个 do-file,这点时间可以接受;如果 AI Agent 要连续调用十几次,每次都等几秒,体验就会断掉。
所以我加了守护进程模式:
stata-cli daemon start启动后,PyStata 会常驻后台,后续命令会自动路由到这个后台进程:
stata-cli run"display 1+1"在我的测试里,简单命令可以从几秒降到几十毫秒级。这个差别不是“快一点”,而是从“不适合交互”变成“可以连续调用”。
用完之后可以关掉:
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 可以直接调用:
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 安装:
pipinstallstata-cli也可以用 npm 安装:
npminstall-gstata-cli安装后先检测 Stata 路径:
stata-cli detect再跑一个最小例子:
stata-cli run"display 1"如果自动检测不到 Stata,可以手动设置路径:
exportSTATA_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 工作流。