Stan对比：一次项目复盘
Stan对比最有价值的不是列功能表，而是看真实项目里怎么取舍。我拿一个教育测评小项目复盘：同一批学生成绩数据，我们试过brms、PyMC和手写Stan，最后为什么留下Stan，过程比结论更有参考性。
Q1：这个案例到底要解决什么问题？
数据很普通：12所学校，约900名学生，两次测验成绩，还有班级、性别、家庭背景几个变量。客户不只想知道“某个因素有没有影响”，还想知道学校之间差异有多大，以及小学校样本少时估计该不该收缩。
这类问题天然适合层级贝叶斯模型。普通回归会把学校效应估得很散，小样本学校尤其不稳；完全汇总又会抹掉学校差异。我们要的是介于两者之间的部分池化。
Q2：一开始为什么没有直接手写Stan？
项目早期我们先用brms。原因很现实：公式写起来快，随机截距、随机斜率几行就能跑，客户还在改变量口径，没必要一开始就写底层代码。brms生成的结果也方便做初版图表。
但到第二版，问题来了：客户希望成绩增长的误差方差按学校类型变化，还要加入一个自定义的稳健似然。brms能做一部分，但公式开始变得拧巴，生成代码也不好查。
Q3：PyMC在这个Stan对比里输在哪？
PyMC版本我们也搭了。优点是Python数据处理接得顺，ArviZ图很好用，团队里工程同事更愿意看。小模型跑得也没问题。
真正卡住的是可交付性。统计同事想审模型，工程同事想复现环境，客户那边有人用R。PyMC模型嵌在Python脚本里，依赖版本要锁得更细。Stan的.stan文件单独摆出来，反而更像一份可审计文档。
Q4：手写Stan带来了什么变化？
手写Stan后，我们把数据、参数、生成量分得很清楚。学校层级效应、学生层级协变量、预测分布都在一个模型文件里。后验预测检查也放进generated quantities，报告里直接用模拟分布对比真实成绩。
中途遇到过divergence，最后靠两件事解决：连续变量标准化，学校效应用非中心化参数化。采样时间比最初brms版本略长，但诊断更稳，模型修改也更可控。
Q5：这次对比给后来项目留下什么规则？
我的规则变成了这样：探索阶段用brms快跑，工程和Python生态强时试PyMC，模型一旦进入交付、审计、长期维护，就评估是否切到Stan。不是Stan永远最好，而是它在“复杂模型要讲清楚”这件事上很占便宜。
这个Stan对比案例里，最终选择Stan不是因为它最省事，而是因为它让模型假设、诊断和复现都更透明。对严肃统计项目来说，透明度本身就是生产力。
常见问题
真实项目里Stan和brms怎么分工？
brms适合快速试公式、做基线模型；Stan适合自定义似然、复杂生成量、需要长期维护和审计的模型。两者不是敌人，很多项目会先brms后Stan。
Stan对比PyMC最大的差别是什么？
Stan更像独立建模语言，模型文件清晰可复用；PyMC更贴近Python生态，工程整合舒服。选谁主要看团队和交付场景。
小数据项目有必要用Stan吗？
如果只是算均值差异，没必要；如果小数据还涉及层级结构、先验知识和不确定性表达，Stan反而很适合。