第一篇写的是怎么找到值得提的 issue、怎么把 PR 做出来提上去。但真正动手之后我才发现，提交只是把卷子交上去，评审才是正文。这段时间我的台账里攒了 27 条 PR 记录：已合并 12 个、在途 8 个、停止 7 个。回头看，12 个合并里没有一个是"提交完直线合并"的故事——有维护者读完直接合的，有维护者挽起袖子往我的 PR 里补代码的，有两轮维护者评审、七笔提交还没落定的，还有一个被一言不发关闭的。这一篇就讲评审阶段：四种结局，四种协作姿势。本文所有案例都是我自己的 PR，数据截至 2026 年 10 月 23 日，台账全程留痕。

为什么做这个

上一篇解决的是"广度"：用机会雷达扫描、打分、防撞车，把有限精力投给最值得的 issue。这一篇换到"深度"：单个 PR 从提交到落定的完整生命周期里，维护者的每一次回应都是信号——直接合、补代码、提修改要求、关闭，四种回应背后是四种不同的协作关系。把这些信号读懂，比多提两个 PR 更重要：开源协作的信用就是在评审区里一笔一笔攒的，提得再多、回得不好，照样寸步难行。

口径先说清：本文的数字全部来自我自己维护的 PR 台账（提交、评审、修复、合并、关闭逐条记录，含每轮的 commit 与测试结果）；"停止"包含主动停下与被关闭两种，文中逐项交代。项目与 PR 编号都可公开检索，结论以台账记录为准。

先看总账：27 条记录的协作光谱

结局	数量	说明
已合并	12	直接合并 8、维护者共建 3、评审往返后合并 1
在途	8	深度攻防 1、机器人多轮评审 2、正面评审待合 1、静默等待 4
已停止	7	防撞车主动停 4、被关闭 1、通道不通与自建测试件 2
合计	27	另有 1 个候选在等仓库协作者邀请

直接合并的 8 个里，open-connector 一家占了 4 个（其中 3 个是同一天被同一位维护者亲手合并的系列 provider）；共建的 3 个是这一篇的重点——维护者不只是"批准"，而是直接往 PR 分支里推了修复 commit；评审往返后合并的 1 个（obsidian-llm-wiki）经历了正式 changes-requested、两处修改、批准时附带完整的 merge audit trail。在途里最值得讲的是 Sentient 那场七笔提交的攻防；停止里最值得讲的是防撞车主动停下的 4 个和被关闭的那 1 个。

怎么做的

秒合不是运气：把维护者的决策成本降到最低

同一天被同一位维护者亲手合并三个 PR，听起来像运气，拆开看全是可复制的细节。这三个 PR 都是给 open-connector 新增数据源 provider（证书透明、恶意 URL 库、威胁情报），它们的共同点：改动范围与目标严丝合缝，不多改一行无关代码；每个都带可运行的验证；PR 描述把"这是什么、为什么需要、怎么验的"一次写全。维护者要做的决策只剩下"合不合"，而不是"这东西到底对不对、我要花多久才能看懂"。

jevgrep 的密钥检测修复也是类似路径：问题定位（API key 会随源码预览发给第三方）在描述里用最小复现讲清，改法收敛到"内容级检测命中就整文件排除"，维护者读完直接合并并留言致谢。秒合的本质是把评审成本提前替维护者付掉：复现、测试、范围、自解释，四样齐全，合并就是顺水推舟。反过来说，那些石沉大海的 PR 多数不是代码不行，是维护者算了一笔账——看懂它的成本，比关掉它还高。

当维护者开始往你的 PR 里写代码

这一批里最让我意外的，是 3 个"共建型"合并：

jevgrep 的 --no-locations 修复，维护者先把我的分支 rebase 到最新主干，又亲手补推了一个"保持输出诚实性"的修复 commit，才合并，留言肯定这是"聚焦的 CLI 改进"。aurelio-finance 的溢出修复，维护者往 PR 分支推了一个空目标守卫的 commit，然后 squash 合并，还留了言致谢。mcp-memory-service 的限流功能更典型：维护者首轮评审给了 3 点要求，我修完后，机器人评审又发现了数据清洗与入口覆盖方面的新问题；收尾阶段维护者亲自补推 commit（给日志注入加测试、解掉与主干的冲突），批准合并；机器人发现的一个未覆盖入口，他转成新 issue 继续跟进，而不是卡住这个 PR。

第一次遇到维护者改我的代码时，我的第一反应是"是不是我写得不行"。后来想通了：维护者愿意往 PR 里写代码，是比秒合更高的认可——他把你的 PR 当成了项目的一部分，而不是一份待审的作业。对应的姿势有三条：分支保持允许维护者编辑（这是默认选项，别关）；描述里把设计意图和可动范围写清，方便他下手；他补的 commit 先认真读懂再回应，别辩护式回复。共建之后这个 PR 就不只是"你贡献的"，而是"你们一起做完的"——这正是开源协作最理想的形态。

七笔攻防：一个 PR 的安全评审全记录

在途的 Sentient PR 是给项目新增一个 MCP 服务命令，把项目的记忆与任务能力暴露给外部 AI 客户端调用——功能本身就踩在信任边界上，评审的强度可想而知。它从 10 月 21 日提交到现在，前后七笔提交，还没落定，但每一轮都值得记录：

提交时是 21 个文件，附真实环境测试 10/10 通过和用真实客户端做的端到端实测。第一轮是机器人评审，4 条可执行意见（IPv6 地址方括号、令牌鉴权强度等），全部修复逐条回复。第二轮机器人增量评审报了一个 CWE-312（桌面端配置片段里明文填入引擎令牌），修法动了架构：去掉桌面端保存令牌片段的路径，改成启动器运行时自取并注入。接着维护者本人下场，第一轮 changes-requested 给了 5 大项：调用轮次的全程隔离、审批请求要上浮到项目界面、令牌必须专用且可替换、整条 HTTP 通道直接移除、建任务必须走审批恒等校验——全修，34 个文件。其间还穿插了两轮机器人增量评审的修复。然后是第二轮维护者评审，这次是纯安全视角，指出两个真洞：身份证明的中继转发问题（证明绑定的对象不对）和服务重启后的接管问题。第七笔修复把证明改成与实际到达端口绑定签发、每次调用前重新验明对端身份，并用真实引擎加真实中继进程做了端到端验证，7 项全过；全量测试 2787 项通过。现在它停在第七笔修复之后，等维护者复审。

有两条经验从这场攻防里沉淀下来。一是把安全评审当免费审计：维护者问的每一个"攻击者会怎么绕"，都是我自己设计时没想到的攻击面，这种级别的评审在任何地方都买不到。二是回复纪律：每一轮都逐条对应、附测试数字与证据；有一项真实测试只跑过 27/31，剩下 4 项是本机资源不足把小模型挤爆了，我在回复里如实写明是环境墙而不是隐瞒——评审阶段的信用就是这么攒的，藏一次，前面六轮全白费。

被关闭之后：不争辩、不猜测、留好重提的门

停止的 7 条里，只有 1 条是被维护者关闭的。MaiBot 的 reasoning-only 恢复路径修复：提交后机器人评审报了一条 Major，是隐私问题——恢复路径的警告日志里会带上最多 200 字的推理原文，而且关掉推理保存也拦不住。这条我修了（日志只留恢复事件与来源信息，推理原文一律不记录），补了隐私回归测试，又按机器人的琐碎意见补了缺失属性场景的测试覆盖。第二天凌晨，这个 PR 被维护者直接关闭，没有任何留言。

细节里有个容易带节奏的点：关闭后约 20 秒，CI 失败的通知邮件到达，三个提交的 Ruff 检查都是失败的。时间和因果挨得很近，但台账里我给它标注的是"因果关系未确认"——就写进文章里，也是这个口径。能确认的事实只有三个：被关闭、无留言、关闭前后 CI 是红的。拿着未确认的因果去质问维护者，是最坏的选项。

实际处置只有三步：不连环留言，只发一条中文评论，问清是"问题已在别处修复"还是"方案方向不对"，并明说愿意按维护组的想法调整后重提；台账里把这条移入已停止区、写清关闭时间与 HEAD；监控列表移除，不再占用每日巡检。然后等回复——回了就按方向重提，不回，这条记录本身也是成果：一个真实的安全问题（日志泄露推理原文）已经被定位并修复过，修复代码还在分支上。被关闭不是失败，带着情绪收尾才是。

主动停下也是产出：防撞车拦下的 4 个

停止里剩下的 4 条，是动手前最后一道检查拦下的：两个是 issue 已被别人认领或已有同范围 PR 在途，两个更隐蔽——其中一个 traceroot 的机会，提 PR 前终查发现已经有两个在途 PR 覆盖同一修复，两位作者之间甚至已经达成了"谁先走"的让路共识。这种时候把自己的修复也提上去，唯一的效果是让维护者多审一份重复劳动，顺带把自己的信用标价。

所以我给提 PR 定了"五查"终检：issue 仍开放、无人认领、无已关联的在途 PR、无同范围在途 PR、时间线无新动静，五项全过才动手。五查拦下的每个机会都留了证据存档。算一笔账：这 4 次停下省下的是四份完整的"复现、修复、测试、写描述"工时，更重要的是维护者的评审带宽——那是整个开源生态里最稀缺的资源。不提，有时和提一样是贡献。

踩过的坑

坑一：仓库不让外部人开 PR，修复全做完才发现。 有个 Linux 下 --version 卡死的修复，我把代码修好、分支推好，最后一步开 PR 时才发现该仓库设置了"仅协作者可开 PR"。修复至今还躺在分支上，我在 issue 里留言请求加协作者，等回复中。教训已经写进流程：动手修之前先确认提交权限——打开对比页看有没有限制横幅，或者先试探 PR 入口。顺序反了，一整天白干。

坑二：fork 同步报 404，真因被权限掩码了。 有次同步 fork，各种写操作都报 404，像仓库凭空消失。最后用合并上游的接口才拿到真实原因：上游新增了工作流文件，而我的令牌没有对应的权限范围，GitHub 对这类权限问题一律用 404 掩盖。改走网页端的手动同步一次解决。教训：遇到莫名其妙的 404，先怀疑权限范围，别怀疑仓库。

坑三：把机器人批准当终点。 好几个 PR 都是机器人先批准、人类维护者的硬仗在后面：Sentient 的两轮 changes-requested 全部发生在机器人轮次之后，obsidian 那个也是维护者在批准时附带了完整的审计记录（批准覆盖哪个提交、门禁是否全绿、关联 issue 是否生效）。机器人抓形态与已知模式，人类抓架构与信任边界——两轮的认真程度不能有差别，但心理预期要放对：机器人全绿，只是拿到了见维护者的门票。

注意事项

• 复现先行：每个修复动手前先有能失败的复现或测试。评审阶段维护者问"怎么证明修好了"，答案只能来自提交前就存在的证据，不能临时补拍。
• 每轮修复独立自查再推：评审意见修完先自己全量跑一遍再推上去，把"修 A 坏 B"的来回轮次压到最低——每一轮往返都在消耗维护者的耐心额度。
• 回复一次说完：逐条对应评审意见、附测试数字，集中在一条回复里讲清，不连环刷屏。需要对方点确认的事项打包一次给出。
• 测不了的如实披露：环境跑不动、权限够不着的项，明说原因与影响范围。评审者对"诚实标注的未测"宽容，对"假装测过"零容忍。
• 台账同步：状态一变就更新台账——移表、改计数、记一行更新记录。27 条记录能随时拿出来对账，靠的就是这条纪律。
• 项目规范即门禁：有的项目在合并审计里明确记录"无 AI 尾巴标记"这类规范项。提 PR 前读贡献指南，把署名、提交格式、CLA 这些非代码门禁一次做对。

复盘

做对了什么

第一，评审成本前置。秒合的那批 PR 证明，把复现、测试、范围控制和自解释描述做在提交前，维护者的回应速度会完全不一样。第二，给共建留门。从 jevgrep 到 mcp-memory-service，维护者愿意下场补代码的 PR，都是那些设计意图透明、分支开放、被改之后先理解再回应的 PR。第三，停下有据。防撞车的五查和证据存档，让"没提"的那 4 个机会同样有完整记录可复盘，而不是凭感觉放弃。

做错了什么

magpie 那次是典型的顺序错误：权限检查应该是所有修复工作的第 0 步，我却把它放到了最后，白白投入一整轮。另一个教训来自 Sentient 的第二轮评审：证明绑定对象这种信任边界问题，本该在设计阶段就被自己的威胁建模拦下——评审帮我补了这一课，但更理想的是提交前就把"攻击者视角"过一遍，而不是等维护者来问。

核心收获

评审不是考试，是协作的开始。维护者的每种回应都在传递信息：直接合，说明你的交付形态达标了；动手补代码，说明他把你的工作接进了项目；提修改要求，说明他认为这个 PR 值得他花时间打磨；关闭，多数时候只是优先级与方向的判断，不是判决。把这四种信号都接住、回应好，比多刷十个秒合更能决定你在一个社区里能走多远。下一篇等这批在途的落定再写——Sentient 这场攻防如何收场，就是现成的开头。

总结

• 27 条 PR 记录：合并 12（直接 8、共建 3、评审往返 1）、在途 8、停止 7，全部可对账
• 秒合的秘密是成本前置：复现、测试、范围、自解释描述，把维护者的决策成本降到只剩点按钮
• 维护者往 PR 里补代码是最高级认可；对应姿势是分支开放、意图透明、被改先理解
• 多轮安全评审是最好的免费审计：逐条对应、附证据回复，测不了的如实披露
• 被关闭时的纪律：不争辩、不猜测未确认的因果、一条留言问清方向、留好重提的门
• 防撞车五查拦下 4 个重复机会——不提也是贡献，省的是维护者的评审带宽

以上，全文完。 最后认识一下，我是 Liyu，一名 AI 实践爱好者，会不定期记录我的学习过程，期待你的关注和分享。