六周提交143个 PR，智能体贡献经验复盘
作者复盘智能体六周创建 143 个 PR 的经历，其中 74 个已合并，49 个进入 24 个外部仓库。实践强调每个 PR 只解决一个问题、提交实现与测试，并及时响应维护者反馈。
AI 深度解读
6 周创建 143 个 PR，听起来像 AI 批量刷贡献，但作者想强调的是：能被开源社区接受的贡献，靠的是范围小、测试明确、及时回应，以及接受拒绝。截至 2026 年 11 月 10 日，这批 PR 有 74 个合并，其中 49 个进入了 24 个外部仓库。
这份记录值得读，不是因为它证明了 AI 能替代开发者，而是它把 AI 编程的评价标准拉回了协作现场：代码写出来之后，有没有人愿意审、愿意维护、愿意合并？
143 个 PR，哪些数字真正说明了效果
从 9 月底到 2026 年 11 月 10 日，作者作为 AliceLabs 的自主贡献代理开展开源工作，由 Edison Flores 操作。文章称，数据通过 GitHub Search API 核验，账号是 eddyflores100-lang：
- 创建了 143 个 PR，其中 74 个已合并。
- 已合并的 PR 中，49 个进入了 24 个外部仓库，包括 browser-use、run-llama/llama_index、docker/mcp-registry 等。
- 47 个 PR 仍然开放，其中 34 个有维护者评论、评审或修改请求。
- 22 个 PR 未合并便被关闭。
这里最有分量的是外部合并。自己的系统能生成代码，和其他项目的维护者愿意接收代码，是两道不同的门槛。
但这些数字没有交代改动规模、人工介入时间、评审成本，也没有描述合并后的缺陷情况。因此，它能说明这套流程获得过外部接纳，暂时还不能证明贡献效率或代码质量优于人工开发。
为什么小 PR 和及时回复比生成速度更重要
作者给每个 PR 定了一条边界：只解决一个问题。如果标题需要用「和」连接两个目标，就考虑拆成两个 PR。贡献可以是加密逻辑的 fail-closed 修复，也可以是明确合并语义的测试、OpenSSF 徽章或带样式的 Excel 导出。fail-closed 指的是遇到异常时默认拒绝，避免错误状态下继续放行。
他们通常直接提交实现、测试和通过的 CI，而不是先开 issue 请求别人实现功能。作者观察到，合并快的往往是带测试的小 PR；涉及架构的大改动可能等待数周，甚至始终无法合并。
原文给出的具体案例是 Podiom：2026 年 11 月 4 日合并的贡献，用聚焦的测试固定了去重语义，也就是明确哪些内容应当被视为重复、最终保留什么结果。
小 PR 的价值，是让维护者更容易判断改动是否正确、是否属于项目范围。
提交之后，响应速度也算工作的一部分。34 个有活跃讨论的 PR 中，几乎都得到了他们当天的回复。作者同时强调，22 个关闭的 PR 里，有些只是项目暂时不需要该功能，他们没有靠反复重开来争取合并。
公开 AI 身份，能不能换来社区信任
作者称，他们在每个 PR 和 issue 中都披露了 AI 参与，外部合并仍然发生，并据此判断透明比营销更有效。
另一个有意思的观察来自 awesome 目录。把 MarketNow 和 uta-shield 加入 awesome-mcp-servers、awesome-remote-mcp-servers 时，他们经历了每次 6 到 10 条评论的讨论。维护者关注的不只是项目能不能用，还包括格式是否准确、条目能否持续更新、分类是否重复。
这类贡献代码量可能很小，却依然需要理解社区规则。AI 能生成一段介绍，并不代表它已经完成了贡献。
作者还预告了 uta-shield、MarketNow、agent-bridge 和求职申请系统的后续介绍。其中 uta-shield 被描述为 MCP 服务器防火墙，但这篇没有提供这些项目的技术实现或效果数据。
我的判断
这篇最可靠的经验，是把贡献拆小、用测试明确行为，并认真处理评审反馈。这些做法对人工开发和 AI 编程都成立，AI 只是让执行速度发生了变化。
「先写代码再提意见」则有前提。对边界清楚的 bug 修复，这样做能减少讨论成本；对架构调整或新功能，先确认维护者是否接受方向，可能更省时间。作者提到的大 PR 长期等待，也提示了这个风险。
「披露 AI 身份没有惩罚」只能算这批贡献中的观察。原文没有提供未披露身份的对照组，也没有统计不同项目的态度，不能据此推断整个开源生态都不在意代码来源。
同样，小 PR 更快合并是作者的经验之谈，文章没有给出按改动规模划分的耗时数据。它适合拿来指导尝试，不适合包装成已经验证的效率公式。
能拿来做什么
- 给前端或 Node 开源项目修 bug 时，先让 AI 补一个能复现问题的测试，再提交最小修复，让维护者能直接核对行为变化。
- 让 AI 准备 PR 时，要求它检查是否混入重构、格式调整或额外功能，并把独立目标拆开。
- 提交新功能或架构改动前，先确认项目方向；收到修改请求后及时补充上下文，明确拒绝后就停止推进。
- 记录 AI 贡献效果时，同时保留统计日期、外部合并数、开放讨论数和关闭原因，避免只用 PR 创建量评价产出。