为什么是提 PR，不是自己造一个
起因是想给医学科研做一套 AI 辅助工具。调研完现成方案后我改了主意：这个领域已经有成熟项目在做，我要补的那部分——临床研究的报告规范、期刊的 AI 使用披露政策、中文文献的引用解析——是它明确留了扩展点、但还没人填的位置。自己再造一个壳，不如把这三块填进已经有人用的地方。
于是先开 issue，不直接甩代码：一个总提案说明整体方向和边界，三个子 issue 各自说清楚要改哪个文件、为什么属于核心而不是插件、不做什么。维护者在总提案下逐条给了方向裁定，我再照着开 PR。
三个 PR 分别解决什么
- 医学出版政策与 fail-closed 披露：补充 9 个医学出版政策目标，并把 AI 使用披露从「尽力而为」改成信息不全就停止输出——查不到某个期刊的现行政策时，宁可停下来说查不到，也不输出一份看起来完整、实则可能过期的披露建议。
- 中文文献解析客户端：独立的解析客户端加一份 API 协议文档，是三个里改动最大的一个。
- EQUATOR 报告规范指南：为深度研究模块补 CARE（个案报告）、STARD 2015（诊断准确性）、TRIPOD+AI（预测模型）三份浓缩指南，外加一条按研究设计选规范的路由序列，每一节都标注转述来源，不把原文当成自己的话。
最硬的一处：一个被普遍误解的前提
做中文文献解析时卡住了：拿中文期刊的 DOI 去查，接口一律返回 404。按常识推断是「这些 DOI 有问题」或者「中文文献没进 DOI 体系」。
查下去才发现前提就是错的——DOI 不是一家在管，它由多个注册局共同运营，最常被当成「DOI 数据库」的那一家，只是其中一个注册局。中文期刊的 DOI 注册在另一个机构，自然查不到，但走 DOI 官方的内容协商就能正常解析出元数据。
这条判断是整个 PR 成立的地基：如果我接受了「查不到就是没有」，这个功能根本不会存在。它也不是靠写代码写出来的，是靠一路追问「为什么」追出来的。
多轮对抗式审查
三个 PR 没有一个是一次过的。维护者的审查方式是逐条核对第一手来源和仓库自己的规则：某个政策条目的表述能不能在期刊官网原文里找到、新加的文件有没有违反既有契约、承诺了字母序排列有没有真的做到、测试是不是真在测行为而不是测实现。
每一轮我都拿着他的清单逐条改，然后把修订后的确切 commit 指给他重审，而不是笼统地说「已修复」。三个 PR 分别在 2026-08-01 和 08-02 合并，总提案 issue 被维护者关闭为 completed。
还有一条值得单独说清楚：我另开过一个后续 issue，提议给这套政策补确定性的测试覆盖。维护者认可方向，但那部分最终是他自己实现并合并的，不是我的 PR。写在这里是因为，把别人做的事记在自己账上是最容易发生也最不值得的事。
诚实边界
- 代码实现和逐轮修订都借助 AI 编程工具完成，我负责的是选题、边界判断、来源核验和每一轮修改的取舍。
- 上游项目的 4 万+ star 是这个项目本身的成绩，不是我的。我的部分只有三个 PR 的合并记录。
- 合并不等于这三块从此正确。医学政策会变、期刊要求会更新，真正的维护责任在上游社区。
我从中拿走了什么
比合并记录更有用的是那几轮审查。它逼我把「我觉得应该这样」换成「这个文件的现行规则说应该这样，出处在这里」——这是我在自己项目里很难获得的训练，因为自己的项目没人会这样追问我。