项目案例 / 决策把关
Cranary：让证据先于发布决定。
评估一个 R 软件包能否进入发布审阅，不应只看 AI 给出的分数，而应看见可核实的证据、未解决的问题和人的决定。
项目状态：早期实现／研究原型。源码仓库目前未公开；跨版本评分尚未完成充分验证。Cranary 与 CRAN 没有官方隶属关系，也不保证 CRAN 接收。
要解决的问题
通过本地检查的软件包，不一定不存在文档、依赖、可移植性或审阅方面的问题。反过来，噪声较大的规则也可能把合理写法误报为阻塞项。我们需要区分已经确认的问题、值得审阅的风险和真正的未知。
决策把关如何实现
汇集软件包的元数据、源码、测试、文档、本地检查及可用的外部构建结果，同时记录证据来源。
用可复现的检查识别机械性问题。确定性问题不会被 AI 的一句“没问题”覆盖。
本地语义模型可提示文档与实现之间的矛盾、要求审阅或选择拒答，但不能将未解决的问题直接变为通过。
维护者看到证据、不确定性与未解决的问题后决定是否提交。通过筛查不等于 CRAN 保证接收。
可以进入提交审阅，不等于保证被 CRAN 接收。
用真实 R 软件包做基准验证
目标不是制造一个万能软件包评分，而是检验：规则是否抓住了真实问题，修复后是否真的显示改善。
CRAN 当前版本
对照近期 CRAN 检查信息及可比软件包，观察规则是否仍然适用；不能假设所有已接收软件包都完美无缺。
已开展规则对照，仍在持续校准。
CRAN 历史归档版本
把历史源码与当时的检查日志对应起来，寻找可确认的问题与修复前后版本，检验评分是否反映真实修复。
历史源码重建已有基础；大规模跨版本评分仍在推进。
有裁定依据的对照样本
将已确认问题、可信的干净对照，与用于开发规则的样本区分开，考察误拦截、漏判、人工审阅负担及错误放行风险。
基准样本与评分验证还在完善。
跨领域与自我检验
扩展至不同领域的 CRAN 包、受欢迎的 GitHub 软件包，并用 Cranary 自身做 dogfooding，检验规则能否泛化。
持续计划与实施中。
体现的能力
Cranary 展示的不是简单调用 AI，而是将确定性工程、统计验证、本地语义模型与软件发布治理组合成一套可解释、有权限边界的决策系统。