← 返回全部文章
Tech
两万五千个 AI 代码提交，79% 从头到尾只有一双眼睛看过
2026年8月10日 · 吴军《数学之美》~1 min read
写代码的是他，审代码的是他，最后点合并的还是他。有研究者翻遍 GitHub 上 2,361 个热门仓库，数出 25,264 个由 AI 代理生成的 pull request，其中 79% 走的就是这条单人流水线。厂商广告里，agent 是加入团队的新同事；数据里，它更像挂在每个工程师工位上的一面镜子——照来照去，都是自己。
30 秒读懂
arXiv 公开论文（编号 2607.14037）分析了 2,361 个热门仓库中的 25,264 个 agent PR：79% 由同一个人完成评审与修改，只有八分之一的工作流有多个真人参与。
落地远比宣传冷清：2025 年间，中位数项目三个月只产出 1–2 个 agent PR；70% 的项目里，参与过 agentic 工作流的贡献者不到五分之一。
照《数学之美》的通信模型解读：独立评审是软件团队对抗噪声的校验冗余；自审自改的错误彼此相关，系统性偏差查不出来。
研究者提醒：拿用量、token 消耗当产出奖励，会让人藏起失败实验；测试与质量保障不随生成量扩容，瓶颈只是被挪进评审环节。
1 数据
两万五千个 agent PR 摆在一起，看不到一个「新同事」加入团队
这份数据硬就硬在盘子够大。
论文在 arXiv 公开（编号 2607.14037），LeadDev 于 2026 年 7 月 28 日报道。研究对象是 GitHub 上 2,361 个热门仓库里 25,264 个 agent 生成的 PR，大概是目前能拿到的最大规模实测。结果冷得很：2025 年间，中位数项目三个月才憋出 1–2 个 agent PR；70% 的项目里，碰过 agentic 工作流的贡献者不到五分之一。说白了，agent 没织进协作网络，它挂在少数工程师身上，各玩各的。
核心 79% 的 agent PR，评审与修改由同一个人完成；只有八分之一的工作流有多个真人参与。
口径：arXiv 2607.14037，样本为 GitHub 公开仓库的 agent 生成 PR。
2 冗余
独立评审在工程团队里的位置，等于通信系统里的校验位
《数学之美》里那套通信模型，正好卡在这件事的要害上。
吴军在书里反复用一个模型：信息从信源出发，穿过有噪声的信道，到接收端。通信工程师从不指望信道干净，他们的招就是加冗余：校验位、纠错码、重传。多出来的这些比特不带新信息，专职查错。但你别看冗余土，它要顶用有个前提：校验出错的路子，必须跟原始信号不相关；两边一块儿错，错误就查不出来。
把代码评审放进这个模型：写代码的人是信源，他对需求的误解、想漏的边界条件是噪声；第二个评审人带着另一套先验知识读同一段 diff，就是一份独立校验。俩人在同一个地方想错的概率，远低于一个人。这道工序在软件行当里干了几十年，道理跟纠错码写进每一份通信协议是同一个。
打个比方
你自己抄一份账再自己核对，抄错的地方多半照原样核对错，因为让你抄错的那个误会还在你脑子里。换个人来核，他的误会跟你的不是一路，两套误会正好叠上的概率才够低。校验冗余的全部家底，就这一句。
3 盲区
自审自改删掉的是「独立」二字，系统性偏差从此无人查验
79% 那条流水线的毛病，得掰得精确一点。
同一个人审，不等于没审。他可能逐行看过，也可能改了不少。可他跟 agent 早就成了闭环：prompt 是他写的，上下文是他喂的，agent 顺着他的理解生成，他再顺着同一份理解检查。万一理解本身歪了，把需求会错了意、并发场景压根没想到，生成和检查就在同一个坑里一起滑过去。通信系统里管这叫相关噪声：校验位跟着信号一块错，查了等于白查。删掉的是独立性，不是认真程度。
这个亏我自己吃过。2022 年我那 SaaS 的轻量服务器忘了续费，凌晨两点被三个跨境卖家用户的微信连环轰炸。打那以后，续费提醒设了三层：支付宝自动扣款、手机日历、冰箱上一块写着日期的白板贴，故意用三种不搭界的东西。要是三层全设在同一部手机里，手机一没电就全哑，等于一层写了三遍。自己审自己的 agent，就是把三道提醒全设在同一个脑子里。
这也不是论文里的抽象担忧。2026 年 8 月，V2EX 热榜上有人在问「你们都如何 review AI 生成的大量代码，保障功能质量」。这一问透出两件事：生成量已经大到一个人看不过来，团队还没长出对应的查验结构。
边界说明：这份数据只统计了公开仓库的 agent PR，公司内网里什么样没人测过；「同一个人审」也确实好过没人审。本文指出的只有一件事：独立性这一项，在那 79% 的样本里是零。
79% OF AGENT PRS ARE REVIEWED BY THE HANDS THAT MADE THEM TRADITIONAL PIPELINE — TWO PAIRS OF EYES Author writes the code Independent reviewer a second pair of eyes Merged AGENT PIPELINE — THE SAME PAIR OF EYES Author + AI agent generate the code Same author self-reviews the same pair of eyes Merged 79% of agent PRs are written, reviewed and revised by the same person only 1 in 8 workflows include a second human sample: 2,361 repositories · 25,264 agent PRs Source: an arXiv study (25,264 agent PRs across 2,361 GitHub repositories) and LeadDev reporting. The second pair of eyes — the independent-review step — is quietly vanishing from the pipeline. 4 孤岛
每个人各自驯化工具，团队正在散成一座座「人加 agent」的孤岛
塌的还不止评审这一道工序。
乔治·华盛顿大学计算机科学助理教授 Courtney Miller 的提醒很直白：软件开发从来不是单打独斗的活，写新代码也从来不是最难的那截。可如今人人都在用自己的法子驯工具，「你会突然发现大家的流程变得完全不同，尽管起点相同」。流程一分叉，经验就搬不动了，一个人踩过的坑，隔壁工位还得原样再踩一遍。
软件工程顾问 Sarah Wells 看到的是另一半：开发者开始把本该找同事聊的问题，拿去跟 agent 聊。她最担心初级工程师，「他们可能没有能力判断 agent 的建议是否靠谱」。她还有个判断：代码评审可能不再是知识传递的方式，知识分享会上移到比代码更高的层面。可上移还没完成的这段空档里，评审桌上顺带发生的传帮带，先断了。
旧办法
卡住了问旁边的同事，问题和答案顺带被半个办公室听见；评审桌上一来一回，知识跟着 diff 一起流动。
新办法
卡住了问 agent，答案只进一个人的会话记录；自己写、自己审、自己合并，别人连你踩过什么坑都不知道。
5 账单
拿 token 用量当产出奖励，等于付钱请工程师拆掉冗余
组织的激励设计，还在给这场塌缩踩油门。
Miller 见过太多组织的标准动作：发工具、许诺 10 倍提效、然后让个人自己想辙兑现。她认为这是错的，该做的是团队层面的学习：问答频道、站会上的短分享、拿真实系统做演示。更糟的一种玩法，是把用量、token 消耗当产出证明来奖励。人一旦知道要汇报的是消耗量，就更不肯讲失败的实验，孤岛之间连失败情报都断了。
Miller 还有一句话是留给质量的：测试与质量保障必须随代码生成量同步扩容，不然 agent 只是把瓶颈挪进评审环节。《数学之美》贯穿全书的那条判断，搁这儿照样成立：好系统靠简单模型加多重独立验证撑起来，孤胆天才撑不起一个系统。生成端再猛，查验端不扩，整个系统的错误率降不下来。
⚡ 为什么值得看： 这不是一篇反 AI 的文章。通信工程师从不因为信道有噪声就不用信道，他们加冗余。真正的问题也不在 agent 的产出带噪声，在于系统把对抗噪声的那道工序悄悄拆了。
6 自用
这对你意味着什么：给自己的 agent 流水线装回一道独立校验
冗余拆掉容易，装回去也不费什么事。
①每个 agent PR 找一个没碰过这条 prompt 的人瞅一眼，十分钟的事；实在没人手，就隔一天用干净的上下文自己重读，时间上的隔离能换回半份独立。
②团队里照 Miller 的方子来：开一个问答频道，站会上留两分钟讲各自的 agent 用法，失败的实验先讲。汇报效果，别汇报 token 消耗量。
③测试跟着生成量扩容，评审顺序倒过来：先跑测试再看 diff，机器能查的交给机器，人省下来干机器给不了的那道独立校验。
下回点合并之前，值得问一句：这段代码，除了你和你的 agent，还有谁的眼睛看过？
本文取材自吴军《数学之美》中通信模型与冗余校验对抗噪声的公开论述，为个人解读。文中数据与人物表态出自 LeadDev 2026 年 7 月 28 日报道及 arXiv 公开论文（编号 2607.14037），具体以原始研究为准。本文非工程管理建议。
技术
两万五千个 AI 代码提交，79% 从头到尾只有一双眼睛看过
2026年8月10日 · 吴军《数学之美》约 6 分钟
写代码的是他，审代码的是他，最后点合并的还是他。有研究者翻遍 GitHub 上 2,361 个热门仓库，数出 25,264 个由 AI 代理生成的 pull request，其中 79% 走的就是这条单人流水线。厂商广告里，agent 是加入团队的新同事；数据里，它更像挂在每个工程师工位上的一面镜子——照来照去，都是自己。
30 秒读懂
arXiv 公开论文（编号 2607.14037）分析了 2,361 个热门仓库中的 25,264 个 agent PR：79% 由同一个人完成评审与修改，只有八分之一的工作流有多个真人参与。
落地远比宣传冷清：2025 年间，中位数项目三个月只产出 1–2 个 agent PR；70% 的项目里，参与过 agentic 工作流的贡献者不到五分之一。
照《数学之美》的通信模型解读：独立评审是软件团队对抗噪声的校验冗余；自审自改的错误彼此相关，系统性偏差查不出来。
研究者提醒：拿用量、token 消耗当产出奖励，会让人藏起失败实验；测试与质量保障不随生成量扩容，瓶颈只是被挪进评审环节。
1 数据
两万五千个 agent PR 摆在一起，看不到一个「新同事」加入团队
这份数据硬就硬在盘子够大。
论文在 arXiv 公开（编号 2607.14037），LeadDev 于 2026 年 7 月 28 日报道。研究对象是 GitHub 上 2,361 个热门仓库里 25,264 个 agent 生成的 PR，大概是目前能拿到的最大规模实测。结果冷得很：2025 年间，中位数项目三个月才憋出 1–2 个 agent PR；70% 的项目里，碰过 agentic 工作流的贡献者不到五分之一。说白了，agent 没织进协作网络，它挂在少数工程师身上，各玩各的。
核心 79% 的 agent PR，评审与修改由同一个人完成；只有八分之一的工作流有多个真人参与。
口径：arXiv 2607.14037，样本为 GitHub 公开仓库的 agent 生成 PR。
2 冗余
独立评审在工程团队里的位置，等于通信系统里的校验位
《数学之美》里那套通信模型，正好卡在这件事的要害上。
吴军在书里反复用一个模型：信息从信源出发，穿过有噪声的信道，到接收端。通信工程师从不指望信道干净，他们的招就是加冗余：校验位、纠错码、重传。多出来的这些比特不带新信息，专职查错。但你别看冗余土，它要顶用有个前提：校验出错的路子，必须跟原始信号不相关；两边一块儿错，错误就查不出来。
把代码评审放进这个模型：写代码的人是信源，他对需求的误解、想漏的边界条件是噪声；第二个评审人带着另一套先验知识读同一段 diff，就是一份独立校验。俩人在同一个地方想错的概率，远低于一个人。这道工序在软件行当里干了几十年，道理跟纠错码写进每一份通信协议是同一个。
打个比方
你自己抄一份账再自己核对，抄错的地方多半照原样核对错，因为让你抄错的那个误会还在你脑子里。换个人来核，他的误会跟你的不是一路，两套误会正好叠上的概率才够低。校验冗余的全部家底，就这一句。
3 盲区
自审自改删掉的是「独立」二字，系统性偏差从此无人查验
79% 那条流水线的毛病，得掰得精确一点。
同一个人审，不等于没审。他可能逐行看过，也可能改了不少。可他跟 agent 早就成了闭环：prompt 是他写的，上下文是他喂的，agent 顺着他的理解生成，他再顺着同一份理解检查。万一理解本身歪了，把需求会错了意、并发场景压根没想到，生成和检查就在同一个坑里一起滑过去。通信系统里管这叫相关噪声：校验位跟着信号一块错，查了等于白查。删掉的是独立性，不是认真程度。
这个亏我自己吃过。2022 年我那 SaaS 的轻量服务器忘了续费，凌晨两点被三个跨境卖家用户的微信连环轰炸。打那以后，续费提醒设了三层：支付宝自动扣款、手机日历、冰箱上一块写着日期的白板贴，故意用三种不搭界的东西。要是三层全设在同一部手机里，手机一没电就全哑，等于一层写了三遍。自己审自己的 agent，就是把三道提醒全设在同一个脑子里。
这也不是论文里的抽象担忧。2026 年 8 月，V2EX 热榜上有人在问「你们都如何 review AI 生成的大量代码，保障功能质量」。这一问透出两件事：生成量已经大到一个人看不过来，团队还没长出对应的查验结构。
边界说明：这份数据只统计了公开仓库的 agent PR，公司内网里什么样没人测过；「同一个人审」也确实好过没人审。本文指出的只有一件事：独立性这一项，在那 79% 的样本里是零。
79% 的 agent PR：审它的正是写它的那双手 传统流程 — 两双眼睛 作者 写代码 独立评审者 第二双眼睛 · 独立校验 合入 agent 流程 — 同一双眼睛 作者 + AI agent 生成代码 同一位作者自审自改 同一双眼睛 合入 79% 的 agent PR：写・审・改，同一个人 仅 1/8 工作流有第二个真人 样本：2,361 个仓库 · 25,264 个 agent PR 数据来自 arXiv 论文（2,361 个 GitHub 仓库的 25,264 个 agent PR）及 LeadDev 报道。「第二双眼睛」这道独立校验工序，正在从流水线上悄悄消失。 4 孤岛
每个人各自驯化工具，团队正在散成一座座「人加 agent」的孤岛
塌的还不止评审这一道工序。
乔治·华盛顿大学计算机科学助理教授 Courtney Miller 的提醒很直白：软件开发从来不是单打独斗的活，写新代码也从来不是最难的那截。可如今人人都在用自己的法子驯工具，「你会突然发现大家的流程变得完全不同，尽管起点相同」。流程一分叉，经验就搬不动了，一个人踩过的坑，隔壁工位还得原样再踩一遍。
软件工程顾问 Sarah Wells 看到的是另一半：开发者开始把本该找同事聊的问题，拿去跟 agent 聊。她最担心初级工程师，「他们可能没有能力判断 agent 的建议是否靠谱」。她还有个判断：代码评审可能不再是知识传递的方式，知识分享会上移到比代码更高的层面。可上移还没完成的这段空档里，评审桌上顺带发生的传帮带，先断了。
旧办法
卡住了问旁边的同事，问题和答案顺带被半个办公室听见；评审桌上一来一回，知识跟着 diff 一起流动。
新办法
卡住了问 agent，答案只进一个人的会话记录；自己写、自己审、自己合并，别人连你踩过什么坑都不知道。
5 账单
拿 token 用量当产出奖励，等于付钱请工程师拆掉冗余
组织的激励设计，还在给这场塌缩踩油门。
Miller 见过太多组织的标准动作：发工具、许诺 10 倍提效、然后让个人自己想辙兑现。她认为这是错的，该做的是团队层面的学习：问答频道、站会上的短分享、拿真实系统做演示。更糟的一种玩法，是把用量、token 消耗当产出证明来奖励。人一旦知道要汇报的是消耗量，就更不肯讲失败的实验，孤岛之间连失败情报都断了。
Miller 还有一句话是留给质量的：测试与质量保障必须随代码生成量同步扩容，不然 agent 只是把瓶颈挪进评审环节。《数学之美》贯穿全书的那条判断，搁这儿照样成立：好系统靠简单模型加多重独立验证撑起来，孤胆天才撑不起一个系统。生成端再猛，查验端不扩，整个系统的错误率降不下来。
⚡ 为什么值得看： 这不是一篇反 AI 的文章。通信工程师从不因为信道有噪声就不用信道，他们加冗余。真正的问题也不在 agent 的产出带噪声，在于系统把对抗噪声的那道工序悄悄拆了。
6 自用
这对你意味着什么：给自己的 agent 流水线装回一道独立校验
冗余拆掉容易，装回去也不费什么事。
①每个 agent PR 找一个没碰过这条 prompt 的人瞅一眼，十分钟的事；实在没人手，就隔一天用干净的上下文自己重读，时间上的隔离能换回半份独立。
②团队里照 Miller 的方子来：开一个问答频道，站会上留两分钟讲各自的 agent 用法，失败的实验先讲。汇报效果，别汇报 token 消耗量。
③测试跟着生成量扩容，评审顺序倒过来：先跑测试再看 diff，机器能查的交给机器，人省下来干机器给不了的那道独立校验。
下回点合并之前，值得问一句：这段代码，除了你和你的 agent，还有谁的眼睛看过？
本文取材自吴军《数学之美》中通信模型与冗余校验对抗噪声的公开论述，为个人解读。文中数据与人物表态出自 LeadDev 2026 年 7 月 28 日报道及 arXiv 公开论文（编号 2607.14037），具体以原始研究为准。本文非工程管理建议。
テクノロジー
两万五千个 AI 代码提交，79% 从头到尾只有一双眼睛看过
2026年8月10日 · 吴军《数学之美》約 6 分
写代码的是他，审代码的是他，最后点合并的还是他。有研究者翻遍 GitHub 上 2,361 个热门仓库，数出 25,264 个由 AI 代理生成的 pull request，其中 79% 走的就是这条单人流水线。厂商广告里，agent 是加入团队的新同事；数据里，它更像挂在每个工程师工位上的一面镜子——照来照去，都是自己。
30 秒读懂
arXiv 公开论文（编号 2607.14037）分析了 2,361 个热门仓库中的 25,264 个 agent PR：79% 由同一个人完成评审与修改，只有八分之一的工作流有多个真人参与。
落地远比宣传冷清：2025 年间，中位数项目三个月只产出 1–2 个 agent PR；70% 的项目里，参与过 agentic 工作流的贡献者不到五分之一。
照《数学之美》的通信模型解读：独立评审是软件团队对抗噪声的校验冗余；自审自改的错误彼此相关，系统性偏差查不出来。
研究者提醒：拿用量、token 消耗当产出奖励，会让人藏起失败实验；测试与质量保障不随生成量扩容，瓶颈只是被挪进评审环节。
1 数据
两万五千个 agent PR 摆在一起，看不到一个「新同事」加入团队
这份数据硬就硬在盘子够大。
论文在 arXiv 公开（编号 2607.14037），LeadDev 于 2026 年 7 月 28 日报道。研究对象是 GitHub 上 2,361 个热门仓库里 25,264 个 agent 生成的 PR，大概是目前能拿到的最大规模实测。结果冷得很：2025 年间，中位数项目三个月才憋出 1–2 个 agent PR；70% 的项目里，碰过 agentic 工作流的贡献者不到五分之一。说白了，agent 没织进协作网络，它挂在少数工程师身上，各玩各的。
核心 79% 的 agent PR，评审与修改由同一个人完成；只有八分之一的工作流有多个真人参与。
口径：arXiv 2607.14037，样本为 GitHub 公开仓库的 agent 生成 PR。
2 冗余
独立评审在工程团队里的位置，等于通信系统里的校验位
《数学之美》里那套通信模型，正好卡在这件事的要害上。
吴军在书里反复用一个模型：信息从信源出发，穿过有噪声的信道，到接收端。通信工程师从不指望信道干净，他们的招就是加冗余：校验位、纠错码、重传。多出来的这些比特不带新信息，专职查错。但你别看冗余土，它要顶用有个前提：校验出错的路子，必须跟原始信号不相关；两边一块儿错，错误就查不出来。
把代码评审放进这个模型：写代码的人是信源，他对需求的误解、想漏的边界条件是噪声；第二个评审人带着另一套先验知识读同一段 diff，就是一份独立校验。俩人在同一个地方想错的概率，远低于一个人。这道工序在软件行当里干了几十年，道理跟纠错码写进每一份通信协议是同一个。
打个比方
你自己抄一份账再自己核对，抄错的地方多半照原样核对错，因为让你抄错的那个误会还在你脑子里。换个人来核，他的误会跟你的不是一路，两套误会正好叠上的概率才够低。校验冗余的全部家底，就这一句。
3 盲区
自审自改删掉的是「独立」二字，系统性偏差从此无人查验
79% 那条流水线的毛病，得掰得精确一点。
同一个人审，不等于没审。他可能逐行看过，也可能改了不少。可他跟 agent 早就成了闭环：prompt 是他写的，上下文是他喂的，agent 顺着他的理解生成，他再顺着同一份理解检查。万一理解本身歪了，把需求会错了意、并发场景压根没想到，生成和检查就在同一个坑里一起滑过去。通信系统里管这叫相关噪声：校验位跟着信号一块错，查了等于白查。删掉的是独立性，不是认真程度。
这个亏我自己吃过。2022 年我那 SaaS 的轻量服务器忘了续费，凌晨两点被三个跨境卖家用户的微信连环轰炸。打那以后，续费提醒设了三层：支付宝自动扣款、手机日历、冰箱上一块写着日期的白板贴，故意用三种不搭界的东西。要是三层全设在同一部手机里，手机一没电就全哑，等于一层写了三遍。自己审自己的 agent，就是把三道提醒全设在同一个脑子里。
这也不是论文里的抽象担忧。2026 年 8 月，V2EX 热榜上有人在问「你们都如何 review AI 生成的大量代码，保障功能质量」。这一问透出两件事：生成量已经大到一个人看不过来，团队还没长出对应的查验结构。
边界说明：这份数据只统计了公开仓库的 agent PR，公司内网里什么样没人测过；「同一个人审」也确实好过没人审。本文指出的只有一件事：独立性这一项，在那 79% 的样本里是零。
エージェントPRの79%は作った手が審査する 従来の流れ — 二つの目 作者 コードを書く 独立レビュアー 第二の目 マージ エージェントの流れ — 同じ目 作者 + AIエージェント コードを生成 同じ作者が自己レビュー 同じ目のまま マージ 79% のPRは 書く・審査・直す が同一人物 第二の人間は 1/8 のみ 標本: 2,361リポジトリ · 25,264件のagent PR 出典: arXiv論文（2,361リポジトリ・25,264件のエージェントPR）とLeadDev報道。第二の目が静かに消えた。 4 孤岛
每个人各自驯化工具，团队正在散成一座座「人加 agent」的孤岛
塌的还不止评审这一道工序。
乔治·华盛顿大学计算机科学助理教授 Courtney Miller 的提醒很直白：软件开发从来不是单打独斗的活，写新代码也从来不是最难的那截。可如今人人都在用自己的法子驯工具，「你会突然发现大家的流程变得完全不同，尽管起点相同」。流程一分叉，经验就搬不动了，一个人踩过的坑，隔壁工位还得原样再踩一遍。
软件工程顾问 Sarah Wells 看到的是另一半：开发者开始把本该找同事聊的问题，拿去跟 agent 聊。她最担心初级工程师，「他们可能没有能力判断 agent 的建议是否靠谱」。她还有个判断：代码评审可能不再是知识传递的方式，知识分享会上移到比代码更高的层面。可上移还没完成的这段空档里，评审桌上顺带发生的传帮带，先断了。
旧办法
卡住了问旁边的同事，问题和答案顺带被半个办公室听见；评审桌上一来一回，知识跟着 diff 一起流动。
新办法
卡住了问 agent，答案只进一个人的会话记录；自己写、自己审、自己合并，别人连你踩过什么坑都不知道。
5 账单
拿 token 用量当产出奖励，等于付钱请工程师拆掉冗余
组织的激励设计，还在给这场塌缩踩油门。
Miller 见过太多组织的标准动作：发工具、许诺 10 倍提效、然后让个人自己想辙兑现。她认为这是错的，该做的是团队层面的学习：问答频道、站会上的短分享、拿真实系统做演示。更糟的一种玩法，是把用量、token 消耗当产出证明来奖励。人一旦知道要汇报的是消耗量，就更不肯讲失败的实验，孤岛之间连失败情报都断了。
Miller 还有一句话是留给质量的：测试与质量保障必须随代码生成量同步扩容，不然 agent 只是把瓶颈挪进评审环节。《数学之美》贯穿全书的那条判断，搁这儿照样成立：好系统靠简单模型加多重独立验证撑起来，孤胆天才撑不起一个系统。生成端再猛，查验端不扩，整个系统的错误率降不下来。
⚡ 为什么值得看： 这不是一篇反 AI 的文章。通信工程师从不因为信道有噪声就不用信道，他们加冗余。真正的问题也不在 agent 的产出带噪声，在于系统把对抗噪声的那道工序悄悄拆了。
6 自用
这对你意味着什么：给自己的 agent 流水线装回一道独立校验
冗余拆掉容易，装回去也不费什么事。
①每个 agent PR 找一个没碰过这条 prompt 的人瞅一眼，十分钟的事；实在没人手，就隔一天用干净的上下文自己重读，时间上的隔离能换回半份独立。
②团队里照 Miller 的方子来：开一个问答频道，站会上留两分钟讲各自的 agent 用法，失败的实验先讲。汇报效果，别汇报 token 消耗量。
③测试跟着生成量扩容，评审顺序倒过来：先跑测试再看 diff，机器能查的交给机器，人省下来干机器给不了的那道独立校验。
下回点合并之前，值得问一句：这段代码，除了你和你的 agent，还有谁的眼睛看过？
本文取材自吴军《数学之美》中通信模型与冗余校验对抗噪声的公开论述，为个人解读。文中数据与人物表态出自 LeadDev 2026 年 7 月 28 日报道及 arXiv 公开论文（编号 2607.14037），具体以原始研究为准。本文非工程管理建议。