使用场景
应用微观经济学研究者(博士生、青年教师、RA)在拿到 WRDS 等受限数据后,用 Stata 跑事件研究等回归,并把结果整理成可投稿的论文表格,同时要保证论文里的数字能被复现。
旧做法是研究者自己维护 do-file、手工拼表,或依赖个人脚本库、同事的代码和通用 LLM 对话来补 Stata/WRDS 细节;这些替代不针对复现审计和出版级表格做端到端约束。
公开材料指向的痛点是:从原始数据到论文表之间的 Stata 脚本、变量构造和表格排版高度手工化,且复现审计往往在审稿或合作者复核时才暴露不一致,返工成本高。这是从产品能力与工作流结构推出的判断,尚无用户抱怨或案例直接佐证。
xOcto 的判断
这是"研究者给 AI 辅助研究上护栏"的样本,洞察真实,但还停留在个人项目阶段。
趋势是学术论文开始要求「数字真能从数据跑出来」。切入做实证经济学的复现审计:期刊投稿前核表、核计算,靠科研经费付咨询,不要做通用论文生成器。
使用理由
为什么用户会选择它
推断:相较自己写 do-file 或问通用 LLM,它把复现审计、LLM 流水线方法、事件研究、WRDS、Stata 和出版级表格封装成可调用的技能,研究者可在同一流程里生成表格并核对数字,减少手工拼表和事后返工这一步;因此正在做实证论文、需要向审稿人或合作者交付可复现结果的研究者会在写作与复核阶段选择它。
还不能轻易下结论的地方
真正值得继续追问的矛盾
① 三个月内是否出现 fork 和真实采用案例——有没有人真的在自己的论文工作流里用它; ② 是否新增技能或更新既有技能(项目还在动说明作者自己还在用); ③ 是否进入知名实验室/课程的推荐清单——学术工具的传播靠口碑背书,不靠榜单
如果你正在做这项工作
值得拆解。推断:相较自己写 do-file 或问通用 LLM,它把复现审计、LLM 流水线方法、事件研究、WRDS、Stata 和出版级表格封装成可调用的技能,研究者可在同一流程里生成表格并核对数字,减少手工拼表和事后返工这一步;因此正在做实证论文、需要向审稿人或合作者交付可复现结果的研究者会在写作与复核阶段选择它。
怎样切入 / 可以借走什么
做 AI 辅助工具时,把"验证"做成显式产品功能而非隐式承诺。 三个动作可以照搬:给每个输出步骤加可复现的检查点(金丝雀测试); 失败时先诊断是输入质量问题还是模型问题,再决定改哪里; 对证据一致性做字节级保证,不给"大概一致"留空间。
证据与风险
未披露。 MIT 开源,无付费服务、无 SaaS、无赞助页。 ① 三个月内是否出现 fork 和真实采用案例——有没有人真的在自己的论文工作流里用它; ② 是否新增技能或更新既有技能(项目还在动说明作者自己还在用); ③ 是否进入知名实验室/课程的推荐清单——学术工具的传播靠口碑背书,不靠榜单