为什么要做这个工具我写 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 rundisplay 11也可以跑一段完整分析stata-cli runsysuse auto, clear regress price mpg weight predict yhat还可以查看数据、查帮助、执行 do-file、导出图表stata-cli data--ifprice10000stata-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--jsonrunsysuse auto, clear summarize price mpg weight它拿到的不只是屏幕上的一段文本而是更容易解析的结构化输出。这样 AI 就可以判断变量是否缺失、回归是否报错、模型是否需要调整而不是让用户在中间来回复制粘贴。这件事看起来只是少点几下鼠标实际改变的是工作流Stata 从一个需要人盯着操作的软件变成了一个可以被程序调度的分析引擎。三个我自己最常用的场景1. 让 AI 真正跑 Stata而不是只写 Stata以前让 AI 帮忙写 Stata 代码它最多给你一段 do-file。代码能不能跑、结果对不对、报错在哪里还是要你自己打开 Stata 验证。有了 stata-cliAI 可以直接执行它刚写的代码stata-cli runsysuse auto, clear regress price mpg weight estat vif这时 AI 不只是“代码生成器”而是能进入“写代码—运行—读结果—修改”的闭环。对实证研究来说这个闭环很重要。因为真实分析很少一次写对变量名可能错样本筛选可能漏模型设定可能需要调整回归结果也可能提示你下一步该换方法。2. 批量跑 do-file不再靠手工排队如果你有几十个模型文件传统做法很容易变成机械劳动打开、运行、等结果、看日志、再打开下一个。用命令行之后这件事可以交给 shellforfinmodels/*.do;dostata-clido$fdone这不是炫技而是把重复劳动从人的时间里拿出去。真正有价值的人力应该花在判断模型、解释结果、检查识别策略上而不是盯着软件窗口等它跑完。3. 快速验证一个想法不必启动完整界面很多时候我只是想看一眼变量分布或者验证某个命令是不是能跑并不想打开 Stata GUI。现在可以直接在终端里做stata-cli runsysuse auto, clear histogram price如果代码生成了图stata-cli 会自动把图导出成 PNG并把路径打印出来。这类小体验很容易被低估但它会改变你和工具互动的频率。启动成本越低你越愿意多试几次试得越快分析迭代也越快。守护进程模式解决 Stata 启动慢的问题命令行调用 Stata 最大的现实问题是启动成本。PyStata 每次初始化通常要几秒钟。如果只是偶尔跑一个 do-file这点时间可以接受如果 AI Agent 要连续调用十几次每次都等几秒体验就会断掉。所以我加了守护进程模式stata-cli daemon start启动后PyStata 会常驻后台后续命令会自动路由到这个后台进程stata-cli rundisplay 11在我的测试里简单命令可以从几秒降到几十毫秒级。这个差别不是“快一点”而是从“不适合交互”变成“可以连续调用”。用完之后可以关掉stata-cli daemon stop对 AI Agent 来说守护进程模式尤其关键。因为 Agent 的工作方式不是一次性跑完全部代码而是不断试探、观察、修正、再运行。没有低延迟这个循环就很难顺畅。功能一览需求命令执行一段 Stata 代码stata-cli run ...执行 do-filestata-cli do script.do查看当前数据stata-cli data --if 条件查看 Stata 帮助stata-cli help 命令名自动导出图表检测到图表后导出 PNG中断正在运行的任务stata-cli stop管理守护进程stata-cli daemon start/stop/status输出 JSONstata-cli --json run ...输出精简结果stata-cli --compact run ...从管道读取代码echo “display 1”这些功能的设计原则很简单让 Stata 尽量像一个普通命令行程序能输入能输出能被组合能被自动化系统理解。一个更接近真实使用的例子我现在会这样让 AI 帮我做分析帮我用 auto 数据集做一个 price 对 mpg 和 weight 的回归顺便检查一下多重共线性。AI 可以直接调用stata-cli runsysuse 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 rundisplay 1如果自动检测不到 Stata可以手动设置路径exportSTATA_PATH/Applications/Statastata-cli rundisplay 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 协议GitHubhttps://github.com/ashuiGordon/stata-cliPyPIhttps://pypi.org/project/stata-cli/如果你也经常在 Stata、终端、Python、R、AI Agent 之间来回切换应该能理解这个工具想解决的痛点。我不认为 Stata 需要变成 Python也不认为所有研究者都应该放弃自己熟悉的工具。真正需要改变的是接口好工具应该能被人使用也应该能被其他工具调用。Stata 本身是可靠的分析工具。stata-cli 做的事很小就是给它打开一扇门让它能进入脚本、终端和 AI 工作流。