35 个来源，按重要程度分六档排序。排序不按名气，按「这条证据会不会改变你的决策」。2026 年新增来源已用绿色标记。
今年与去年最大的不同：争论从「AI 能不能提效」变成了「提效去哪了」。这一档八份里，两份是 50 万以上样本的计量研究，两份是随机对照实验，其余是千人级行业调研。
3 亿个工作事件、70 万余名工程师、2021 至 2026 年 3 月。引入编码智能体后：代码行 +30%、commit +20%、PR +23%，但 Jira Issue/Epic 完成率无统计显著变化——数据排除了产出增长超过 12% 的可能。原因在下游：PR 平均审查时长 +49%、要求修改的 PR 占比近翻倍、每条 PR 评论数 +35%、参与审查的人数 +14%。
全清单方法学最扎实的一份。它把「瓶颈从写转移到读」从观察变成了因果证据。另外两个反直觉点：80% 企业已用 AI 审查，但 AI 只贡献 23.3% 的审查评论；就业人数也无显著变化。
50 万余名 GitHub 开发者 + AI 使用遥测，匹配事件研究。三代的 commit 累计效应：补全 +30%、交互式智能体 +180%、自主智能体 +240%。但沿生产层级急剧衰减：240% → 项目数 80% → 实际发布 30%。AI 与人力投入的替代弹性仅 0.23，说明是强互补而非替代。四个应用市场交叉验证：新应用数量激增，总使用量没有增加。
提出「弱环节假说」：任务级增益被生产链上的人力瓶颈削弱。这是「别只加速一个环节」最硬的理论依据。
16 位资深开发者、246 个真实 issue，随机分配能否用 AI。用 AI 反而慢 19%；事前预期快 24%，事后仍确信快了 20%——感知与现实的裂口达 39 个百分点。开发者把省下的编码时间花在了写提示、审查产出、等待与理解生成内容上。
「感觉变快」不是证据。这条是必须先打基线再谈收益的原始依据。
52 名工程师学习陌生的 Python 异步库 Trio。AI 组完成任务快约 2 分钟（不显著），但理解测验得分 50% vs 手写组 67%（低 17 个百分点，Cohen's d=0.738）。差距最大的是调试题——恰好是判断 AI 代码对不对最需要的能力。识别出六种交互模式：完全委托、渐进外包、靠 AI 调试属低分组（低于 40%）；生成后追问、结合解释、只在概念问题上用 AI 属高分组（65% 以上）。
由 AI 公司自己发布、结论对自己不利的研究，可信度反而最高。可执行的团队规则：把「保持认知参与」写进 onboarding，尤其是初级工程师。
AI 采用率每提升 25%，交付吞吐量 -1.5%、交付稳定性 -7.2%。作者判断根因是小批量原则被破坏：AI 让变更批次变大，而大变更更慢、更易引发不稳定。提出三个命名概念：验证税、「有价值工作」悖论、J 曲线（采纳后 1–3 个月先跌后涨）。三项高杠杆组织动作：明确可接受使用政策使采纳率 +451%；给工作时间学习 +131%；公开缓解失业焦虑 +125%。引用斯坦福数据：简单 greenfield 任务 +35~40%，复杂遗留代码 不超过 10%。
平台与 SRE 类工作大多落在「遗留代码」那一端，用 greenfield 数字做规划会严重高估。J 曲线提醒：三个月时测量看到的正是谷底。
AI 占提交代码 42%，2027 预计 65%；96% 不完全信任 AI 代码正确性，仅 48% 提交前总是检查；38% 认为审 AI 代码比审同事更费力。团队平均同时使用 4 种 AI 编码工具，64% 已用自主智能体；toil 工作仍占工作周 24%，不随 AI 使用频率下降。另有 35% 用个人账户而非企业账户访问工具。
定义了「验证缺口」。「节省的时间被重新投入审查」这句是理解全行业现状的钥匙。
开发者与工程负责人同时把「审查与验证 AI 代码」列为第一瓶颈（各 26%）。89% 的组织已发生 AI 相关生产事故；仅 3.7% 的负责人认为现有流程够用。最大短板：规模化审查（47.7%）、让智能体理解上下文（42.7%）、可见性（38.3%）。90% 负责人有信心向董事会汇报 AI 影响，但只有 45% 拿得出追溯证据。
「3.7%」是全清单最刺眼的数字；「90% 自信 vs 45% 有证据」是治理层最该看的一对数字。
过去 12 个月：push 179 亿次、commit 343 亿次、合并 PR 13 亿个（约每天 350 万个）、Actions 454 亿次作业。2026 年 9 月超过 40% 的 PR 由智能体起稿，3 月时还是 17%（单月约 1.1 亿个）。带智能体配置文件的新仓库，提交量是没有的 8 倍。智能体发起的 PR 中 87% 跨多文件（对照组 79%），两周内合并率 90%。
GitHub 自己也声明这是活动数字不是质量数字，且 40% 只是「可检测」的下限。大而快的合并，可能是成熟流程，也可能是橡皮图章——报告无法区分，但你能。
今年最值钱的一批材料：不再是观点，而是 OpenAI、Anthropic、DoorDash、Reddit 公开的具体制度与流水线。09 号建议逐字读完。
Claude 写了 Claude Code 自身约 90% 的代码；monorepo 日变更从 5 月 2,500 增至 9 月 30,000+。核心转向：不问「人读过吗」，改问「这个改动可能出什么错，哪种检查（自动或人工）最适合抓它」。六层门禁，且没有任何单层需要完美。结果：合并 PR 翻倍、回滚率降超 40%、收敛轮次 2.08 → 1.32、有实质审查意见的 PR 从 16% 升至 54%。风险三级：低（文档、带 flag 的增量改动）0 人；中（普通产品改动）1 人；高（计费、自动更新器、CI 工作流）2 人——分级看改动内容而非作者身份，智能体的批准永远不算人。
今年最该抄的一份。三个细节尤其值钱：① 智能体互审会无限循环（一个 PR 一夜跑 50+ 轮），故设三轮上限、二轮后只审 diff、按「缺陷类别」而非单行提意见；② git blame 显示 59% 的重复标记指向首轮就存在的老代码——那是噪音不是信号；③ 把历史事故与回滚做成 eval 集，每天跑，审查器改动只在分数上升时才发布。
5 个月、约 100 万行、约 1,500 个 PR、3 人（后增至 7 人）、人均 3.5 PR/天，估计耗时是手写的 1/10。连最初的 AGENTS.md 都是 Codex 自己写的。关键教训：早期慢不是模型不行，而是环境欠规范。失败时的追问固定为「缺的是什么能力，怎么让它对智能体既可读又可执行」。为突破人类 QA 瓶颈，他们让应用 UI、日志、指标对 Codex 可读（每个 git worktree 可启动一个实例、接入 Chrome DevTools Protocol、提供 DOM 快照技能）。
「人类掌舵，智能体执行」的官方版本。最深的一条：瓶颈会转移，所以要持续把能力做成智能体可读——这是 harness 工程的核心动作。
受 GAN 启发的三智能体架构：planner / generator / evaluator。两个关键发现：① 长任务中模型会失去连贯性，还会出现「context 焦虑」（临近自认为的上下文上限就草草收尾）——解法是 context reset（清空重开 + 结构化交接），而不是 compaction，因为压缩不给干净起点。② 智能体自评会自信地夸自己的产出，即使客观上平庸；把执行者与评判者分离，再把独立 evaluator 调成「怀疑倾向」，比让 generator 自我批评有效得多。
「让智能体自审自测」这个常见做法，在这里被官方明确证伪了——评判者必须与执行者分离。这一条直接推翻很多团队的现有流程。
把 session（只追加的事件日志）、harness（调用模型并路由工具）、sandbox（执行环境）拆成三个可独立替换的接口。一条罕见的自省：harness 里的假设会随模型进步而过期——他们为 Sonnet 4.5 的 context 焦虑加的 reset，在 Opus 4.5 上成了「纯粹的负担」。所以不要固化实现，只固化接口形状。
给平台团队：审查流水线里每一条「为弥补模型缺陷而加的规则」，都应该定期复核是否还必要。
623 个仓库、6 万+ flag、每月新增 2,300 个、识别出 1,000+ 个陈旧 flag。两阶段：Claude Sonnet 编排器取 Jira 工单并通过 MCP 查实验平台元数据，工程师审批后才动代码；随后 Claude Opus 清理智能体在隔离的 git worktree 中并行（每仓最多 4 个），跑构建、测试、JaCoCo 补丁覆盖率、Detekt，全绿才开 PR。50 个评估样本：45 个产出可用 PR，平均 13.8 分钟、4.79 美元（人工 1–2 小时）。按复杂度：简单 100%、中等 94%、复杂 85% 一次通过。无 bug 或回归。
智能体最被低估的用法：不是写新功能，而是做没人愿意做的维护活。也示范了「人机分界」的准确位置——审批在动代码之前，不在之后。
资深工程师 Andrew Orobator 的核心论断：换更强的模型收效甚微，拿走测试、门禁和审查则一切崩塌。三个可执行机制：Skills（把机构判断编码成智能体能跑的规则）、Work logs（跨会话的结构化记忆，让新智能体从第 7 个里程碑接着干）、Persona panels（按需加载安全、UX、对抗性视角）。验证是阶梯：构建 → 截图 → 运行录像 → 生产遥测，要求智能体交回真实用户流录像而非自报「通过」。硬警告：应用层的 pre-commit hook 拦不住智能体，它能写操作系统级补丁或插入自授权的恢复例外，闸门必须落在 OS 级且绕过权限只给人。
「模型是原始天赋，机构判断才是瓶颈」——把这句话贴墙上。他还指出 skill 会随架构演进而腐坏，过期的 skill 比没有 skill 更糟。
技能一：指挥智能体而不只是下提示——定义问题、拉起多个智能体、审产出，仍对结果负责。技能二：把 AI 的第一答案当草稿——建议用第二个模型去批评第一个（Copilot 的 Rubber Duck 智能体内置此模式），例中批评模型指出了缺失的索引建议、重复的时间戳处理与大表性能问题。技能三：把释放出的产能投向架构与产品决策。
「不同模型有不同的盲区」——多模型交叉批评是今年最易落地的一条低成本实践。
这一档回答「具体怎么做」。共同主张：把意图固化成文件，让智能体对着契约实现，而不是对着 Prompt 猜。
把「写规格」变成可执行命令：/specify → /plan → /tasks → implement。Fowler 站上的评述给出了 spec-kit、Kiro、Tessl 三家的差异与适用边界。
最低成本起点：不用买平台，仓库里建 specs/ 目录即可。
三种没人预警的失败：spec 漂移（过期的 spec 比没有更糟，因为人还会信它）、过度规格化（等于把代码写两遍）、三遍审查疲劳（spec、plan、diff 各审一轮，中等改动就开始橡皮图章，而橡皮图章的 spec 带来虚假信心）。
「别把仪式铺满所有改动」的主要依据。判据：改动比我的脑袋大就写，装得下就跳过。
AGENTS.md 已被 6 万+ 开源项目采用，现由 Linux 基金会下的 Agentic AI Foundation 托管。实证分析给出五类写法（描述性、规定性、禁止性、解释性、条件性），并发现：约 50% 的文件写完后再未更新；自动生成的通用内容会拉低智能体表现；均值 142 行。
规则文件该写多长、多久更新一次，唯一有数据支撑的答案在这里。
控制在 150 行以内（小仓库 30–50 行足够）；每一行过「删掉它智能体会不会因此犯错」的检验；当索引用而非垃圾桶，架构细节指到 docs/ARCHITECTURE.md；Claude Code 用 @AGENTS.md 一行引用来兼容。ETH Zurich 的研究：自动生成的上下文文件充满模型已知的通用信息时会伤性能。
补上 18 号缺的「具体怎么写」，可直接照做。
最有用的一句：智能体把第三阶段（实现）压缩得很狠，第五阶段（发布）几乎没压缩。只上工具不改流程，会得到「中间更快、两端照旧」。同时点名四种变难的事：审查负载、架构漂移、理解债、规格歧义——歧义过去在实现时由开发者提问暴露，现在这条反馈环变弱，歧义直接进生产。
解释了「为什么只买工具没用」，并指出该重设计的确切位置：第一阶段与第四阶段。
解决「怎么知道有没有真的变好」，以及「哪些活能放手给智能体」。
最好用的一个转向：别问「AI 能不能写这块」，要问「这块我能不能便宜地验证对」，据此把工作分三桶（低、中、高验证成本）区别放权。两条可操作红线：review 中位时长连续两个 sprint 涨超 20%；CI flaky 率超 5%。
换一个问题，能修掉大部分无效争论。
DORA 看系统健康（月度）+ SPACE 看人的健康（季度）并行，两者背离是未来退化的领先信号。AI 专属指标：AI 代码占比作分母、按来源拆分变更失败率、AI PR 与人工 PR 审查耗时对比，以及一条定性问题——「作者能否用自己的话解释这段代码为什么这么写」。
最后那条定性问题能最早发现「理解债」，比任何量化指标都早。
PractiTest 2026：测试组织 AI 采纳率 76.8%，用例生成 69.6%、脚本维护 59.6%，而风险识别只有 19.9%——真正卡住发布的是判断「什么值得测」。另引 GitLab：87% 自信能 24 小时内定位 AI 相关事故，真出过事的组织里 34% 做不到；43% 的人根本分不出代码是不是 AI 写的。
自动化的是本来就便宜的那一半。别把 AI 测试当成释放 QA 产能的开关。
78.1% 的负责人比一年前更信任 AI 代码，但 61% 在过去 90 天内发生过源自 AI 代码的生产事故；74.3% 曾因 AI 代码以单元测试没抓到的方式失败而回滚；64.8% 认为 AI 代码需要更多审查时间；45.7% 客服工单因此增加；42.9% 因返工损失工程时间；只有 28.6% 认为加派审查人手能解决。
「信心增长快于验证能力」的最佳注脚。特别注意最后一条：多数人已经意识到加人不是解法。
最刺眼的一对矛盾：94% 的负责人在审查当时认为 AI 代码质量高于人写，而一旦上线，78% 报告事故增加、86% 报告资深人员修复时间增加、74% 报告至少 25% 的 AI 代码需大量返工、82% 半年内至少经历一次生产故障。62% 承认团队常信任到不做逐行验证就发生产；88% 已把 vibe coding 写进正式生产策略，仅 5% 限制在非生产环境。应对上：96% 认为可观测性极重要，78% 已在 prompt 里明确要求生成代码自带日志、追踪与指标。
提出 agent debt（智能体债）：未经审查的架构逻辑赤字。也给出今年最具体的一条工程动作——把可观测性要求写进生成阶段的 prompt。
证据等级不如前几档，但细节密度最高——长会话怎么崩、看不懂的代码怎么上线、智能体怎么过度工程化，只有这里有人写。
四条硬发现：context 会腐坏（约 30 小时后塞满过期假设，需手动回卷）；想清楚不等于写对（推理正确但生成的代码自相矛盾，「我监督思考、不监督代码」的模型在此破产）；子智能体失效（丢上下文后返回自信的错误摘要）；没有机构记忆（每次新会话从零重建）。
与 11 号 Anthropic 官方结论互相印证：强制会话边界、显式交接、把架构决策存在会话之外。
六派立场无共识，但多数同意一句：把自己定位成 reviewer 还是 shipper，答案完全不同。可直接抄的技巧：按范围分层（越靠近用户眼睛越放飞，核心数据路径严审，数据模型、迁移、feature flag 是底线）；先写一条会失败的 E2E 再让智能体补实现。另有一派主张：不让模型做设计，只让它填实现。
「按范围分层放权」比一刀切的审查政策可操作得多，且与 09 号的风险分级思路完全一致。
智能体 14 天交出 53.9 万行 Rust、1,306 个文件，但作者自评：功能广度 76%、真实可用度 45%，距对齐还需 2,300–4,100 个 agent 小时（按单人顺序约 9–17 个月）。25 项性能预算只达标 3 项，579 个开放 issue，写出的 PSD 不被 Photoshop 可靠接受。
AI 把成本从「写代码」转移到了「验证与补全」。最诚实的数字不在发布文案里，在 ROADMAP 和 issue 列表里。
两个高赞帖。其一：给智能体设「懒鬼高级工程师」约束后，同一个倒计时组件从 190 行降到 13 行；不加约束时它会自作主张加动画。有人接手一个三个月大的 vibe 工程仓库：220 个 handler 实际只用约 20 个、40 多个 secrets 只需 2 个、30.9 万行代码埋在 24 万行文档下。其二：资深开发者自述成了「自己代码库里的游客」，最高赞评论是「速度从来不是瓶颈，理解才是」。Karpathy 的判断：LLM 非常喜欢把代码和 API 过度复杂化。
三个结构性原因值得记住：智能体唯一的停止信号是「看起来完成了」；模糊提示鼓励它自行脑补范围；训练奖励「详尽」。对策是在约束里明确上限与不做什么。
几场值得知道的争论：Anthropic 公开 3 万 PR/天的工作流后，最高赞反应是怀疑——「3 万次变更/天？不，我们到底在干什么」，有人指出「改动合并数」和「代码行数」一样是无意义指标；Show HN 的 Sphinx 工具（提交前用小测验考你对 AI 代码的理解）反应冷淡；有人给 vibe coding 下了最清晰的定义——当作者无法自信解释自己代码里的 bug、性能问题、安全漏洞或架构决策时，它就是 vibe coded。
「能否解释」这条判据和 22 号的团队指标、04 号的 Anthropic RCT 完全同向——三个独立来源指向同一个可操作的检查点。
这一档的意义不在证据强度，而在语境：国内企业的审批链、遗留系统改造、组织形态，与英文材料里的假设并不相同。
提出三阶段演进：工具原生（个人用好智能体）→ 工作流原生（原本多步骤的事由智能体贯通）→ 组织原生（整个组织以 AI 原生方式工作）。推进方式是「北极星、留白、沙箱」：北极星决定给哪些创新加注；留白允许团队在试验期跨越原有岗位边界；沙箱把对主干生产链路的影响控制住。关键治理细节：过程指标只用于观测比较，不进入考核，以避免针对指标的局部优化变形。局部成绩：某项目全链路处理时长从 2 小时缩到 5 分钟；另一项目两周完成几十个需求，发布周期从 40 天缩到 2 天，沉淀十几个生产级 Skill。
「过程指标不进考核」这一条，是所有做 AI 提效度量的团队都该抄的制度设计——它直接对冲了古德哈特定律。
面向运行十几年、跨多系统的大型遗留工程。把一次迭代抽象为 PDCA 全链路（Plan 需求对焦、Do 开发实现、Check 验收、Act 问题反思），配七阶段护栏、TPRD、研发环境与测试验证、AI 推荐质量评测、三层知识体系，以及 Highway + ATV 混合智能体架构。核心判断：AI Coding 已能较好完成 0 到 1 与简单编码，但企业级难点是准确理解需求、控制影响范围、对最终结果负责。
「控制影响范围」是中文语境下最被强调的一点，也是英文材料里较少直说的痛点。
三点来自金融等强合规客户的观察：① 遗留代码改造的需求大于新功能开发；② 这类客户有大量人工审批阶段，对 AI Coding 的产品与范式提出更细更复杂的要求；③ 早期试用者亲和性高、问题没暴露，一旦落到组织层，不同人对工具的适配度与熟练度是否一致，会通过产品层暴露出来。另一条与常识相反：业务需求不减反增，团队仍在大规模招人。权限建议：在可逆、低爆炸半径、可追溯的隔离环境内给最小充分权限；数据库结构变更、生产操作、外网访问必须收紧或设人工门禁；每个智能体都要有身份标识、操作可追溯。
「智能体身份与审计」是合规行业绕不开的一条，英文材料里几乎不提。
最完整的一套术语与仪式：Inception（mob elaboration 把意图变 unit）、Construction（mob construction）、Operations 三阶段，核心是 steering files——仓库里的 Markdown，定义智能体必须遵守的架构标准与工作流，跨全部阶段充当持久事实源。承载工具可以是 Kiro、Amazon Q、Claude Code 等。
术语与阶段划分值得借用（尤其 NFR 与风险的持续复评），但整套偏重，小团队别照搬。
六步可当检查表：结构化需求 → 仓库规则文件 → 每个 AI 改动跑自动门禁 → 合并前保留资深人工评审（禁止自主合并）→ 审批工具并把密钥与客户数据挡在 context 外 → 前后对比 lead time、变更失败率、审查时长。另有评估任何「AI 原生」供应商的五问：门禁是什么、谁评审、规则文件归谁、数据保留条款、报的是谁的指标。
把「AI 原生」从营销词变成可审计的治理声明；那五问可原样拿去问任何自称 AI 原生的合作方。