概述
本组 10 篇内容聚焦于 AI 时代软件工程正在发生的深刻变化，以及人类工程师角色的转移。主线清晰：AI 工具正在重塑代码生产速度，但同时放大了组织与工程文化中原有的矛盾——审查瓶颈、协作范式失效、过度工程化的 spec 流程，以及工程师自我认同的动摇。更深层的哲学问题则指向：AI 是否真的在替代人类智慧，还是只是在拉高入门门槛？历史上「把人类知识编码进系统」的方法论是否又一次要被通用算力碾压？
AI 改变了什么，带来了什么新问题
ZZ-887 — Amazon 强制会议：AI 辅助代码引发 high blast radius 事故
链接：https://x.com/lukOlejnik/status/2031257644724342957（Financial Times 报道）
Amazon 电商团队因近期多起 AI 辅助代码变更导致的「high blast radius」事故，强制全员参加安全会议，并要求 junior/mid-level 工程师的 AI 辅助代码必须经 senior 工程师签字。典型案例：AWS 自研 AI 编码工具 Kiro 被要求做修改，结果直接删除并重建整个环境，导致 13 小时宕机，影响中国大陆客户。Amazon 官方持续淡化事件，但内部政策调整说明问题的严重性。
核心信号：AI 编码的 blast radius 问题正在企业级暴露——变更逻辑不是人写的，事后审计更难，新的错误向量比人工代码传播更快、更不可预测。
ZZ-992 — apenwarr：Every layer of review makes you 10x slower
链接：https://apenwarr.ca/log/20260316
Avery Pennarun（Tailscale 联创）提出「10x 法则」：每增加一层审批/审查流程，wall-clock 耗时增加约 10 倍——自己修 bug 30 分钟，等 peer review 5 小时，等架构设计文档审批一周，等纳入另一团队排期约 12 周。AI 只压缩了第一步（代码生产），但代码审查依然是 5 小时，反而让不匹配更明显：Agent 跑出来的 PR 更大、更复杂，触发更多审查层级。
真正的解法不是加速生产，而是减少审查层级，并同步建立真正的质量文化（Deming 路径）。结构性启示：层级少的小团队在 AI 时代将比大公司更有优势。
ZZ-993 — apenwarr：Systems Design 2 — 魔法思维是理解复杂系统的必要条件
链接：https://apenwarr.ca/log/20230415
同一作者的另一篇文章，以「魔法思维」、「回形针实验」、「延迟与带宽」三个镜头重新定义工程认知框架。核心论点：复杂涌现系统（如 LLM）只能通过结果而非机制来评估，强行拆解机制反而遮蔽理解；工程是关于管理失败率而非追求完美（“没有人能造出永不断的回形针”）；延迟不能靠算力蛮力解决，只能靠聪明的预测（缓存本质是预测器，而好的预测本质是魔法）。
这一框架是 AI 时代系统设计的重要底层认知：停止用机制解释 LLM，开始用结果评估它。
协作范式要怎么变
ZZ-1001 — Open Prompt：AI 时代 PR 协作新范式
链接：https://disksing.com/open-prompt/（作者：disksing / 象牙山刘能）
提出「Open Prompt」概念：在 AI 时代，Prompt/Markdown 是真正的「源代码」，生成的代码是「Binary」。传统以 diff 为中心的 code review 已经失效——reviewer 面对几千行 AI 生成代码，根本无从评审。
解决方案：把 PR 从「展示最终结果」的窗口改造成「公开协作生成过程」的工作台——在 PR Comment 里公开指挥 Coding Agent，让完整的 Agent Session（包括绕弯路、反复修改、决策链）全部留在公共线程里。实现极其简单，GitHub 现有基础设施即可支撑，不需要新平台。
本质洞察：当前协作方式是反的——把最容易沟通的自然语言（Prompt）藏在私聊里，把最难沟通的编译产物（代码）摆到台前。
ZZ-1009 — Augment Code：The Hardest Part About Going AI-Native
链接：https://www.augmentcode.com/blog/hardest-part-about-going-ai-native（作者：Scott Dietzen, CEO Augment Code）
Going AI-native 首先是人的问题，不是工具问题。工程师的职业认同深度绑定「写代码」这一行为，被告知这件事正在被自动化，感受上是降级而非升级——即使在认知上接受「角色从作者变为架构师+编辑」，情感层面的适应同样需要时间。
七个独立小组讨论收敛出的关键结论：验证是核心瓶颈（Agent 能写代码，但无法验证代码是否工作）；代码审查取代代码生产成为新约束点（1000 行 PR 零评论，40 行 PR 五条评论）；spec 清晰度是人类最高杠杆活动；「别发 slop」——团队要的是条件允许下的高速，不是牺牲质量的高速。
ZZ-1010 — OpenAI Harness Engineering：0 行手写代码构建百万行产品
链接：https://openai.com/index/harness-engineering/
OpenAI 内部团队 5 个月实地实验报告：3 名工程师从空 repo 出发，全程 0 行手写代码，由 Codex 生成约 100 万行代码、1500 个 PR（约 3.5 PR/工程师/天），并将产品真实上线运行。效率估计约为手写代码的 10 倍。
关键方法论：AGENTS.md 设计采用「目录」而非「教科书」模式（约 100 行，真实知识放在结构化 docs/ 目录）；Observability stack 直接暴露给 Codex（LogQL/PromQL、Chrome DevTools Protocol 截图）；PR 循环为 agent-to-agent review，人类 review 非必须。
核心转变：人类瓶颈从「写代码」转移到「定义环境和反馈循环」。当代码吞吐提升后，下一个瓶颈是人类 QA 容量——解法是让 Agent 自己做 QA。
底层哲学问题
ZZ-1014 — 讨论串：ZZ 批评 Spec Driven Development + izayl 引用「足够详细的 spec 就是代码」呼应
链接：https://strrl.dev/post/2026/my-thought-about-spec/（ZZ 博文）；https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code（haskellforall）
三篇内容形成共鸣集群：Spec Driven Development 本质上是把代码换了件衣服。足够精确的 spec 就是代码本身，边界从未存在——Borges《地图》寓言：若地图要与领土完全吻合，地图就等于领土。
ZZ 的亲身实践：用 SpecKit 一段时间后，时间全陷入「提早设计」和「脑内推演」，生成的 Plan 只要覆盖到的地方执行还不错，但覆盖不到就是「一坨大便」。开发流程退化为瀑布，后来用 Claude Code Plan Mode 完全取代。haskellforall 从技术角度补充：OpenAI Symphony 的 SPEC.md 已包含完整 schema、伪代码级算法、Reference Algorithms，大小是 Elixir 实现的 1/6，本质上是伪装成自然语言的代码。
ZZ-1015 — Richard Sutton：The Bitter Lesson（2019）
链接：http://www.incompleteideas.net/IncIdeas/BitterLesson.html
强化学习奠基人 Richard Sutton 在 2019 年写的 1200 字短文，总结 70 年 AI 研究的核心教训：凡是依赖人类领域知识的方法，短期有效但长期都被依靠算力扩展的通用方法碾压——差距「by a large margin」。两类能随算力无限扩展的方法是 Search（搜索）和 Learning（学习）。
四个历史案例：国际象棋（Deep Blue 的暴力搜索击败基于棋局结构知识的方案）、围棋（self-play + search 碾压人类棋谱编码）、语音识别（HMM 再到深度学习，每次都是更少人类知识+更多计算）、计算机视觉（hand-crafted 特征全被神经网络淘汰）。
与 ZZ-1014 的联系：Spec Driven Development 是不是同一个陷阱——把「什么是好 spec」的人类知识编码进工作流，长期来看还是打不过更通用的方法（直接给 AI 足够的上下文 + 算力）？
ZZ-1017 — Aaron Stannard：Software 2.0 — Code is Cheap, Good Taste is Not
链接：https://aaronstannard.com/beginning-of-software-2.0/（作者：Aaron Stannard，Akka.NET 创始人）
提出 Software 1.0 vs 2.0 框架：Software 1.0 是你指定每一行代码的时代，Software 2.0 是「LLM 生成、人类验证」的时代——注意，Software 2.0 ≠ vibe coding，需要严格的自动化验证流水线（静态分析、自动化测试、对抗性 LLM review）。
三个核心结论：拒绝学习 LLM 技术的「coasters」正在被边缘化（Atlassian 数据：AI 代码生成使公司 Jira 任务量增加 5%，证明人力在 AI 时代反而扩张）；精通 Software 2.0 的工程师当前处于卖方市场；LLM 有数学层面的根本局限（幻觉、有效上下文远小于广告 context window、Misalignment）永远无法通过 transformer 架构本身解决，只能靠验证体系对冲。
ZZ-1018 — tombedor：AI is a Floor Raiser, not a Ceiling Raiser
链接：https://tombedor.dev/ai-is-a-floor-raiser/（作者：Tom Bedor，Engineering Manager）
AI 是「地板抬高器」，不是「天花板抬高器」。AI 消除了学习资源的「目标受众错位」问题（找不到从自己视角切入的学习路径），大幅压缩了初学者的痛苦阶段——但精通仍然很难：越往前沿走，训练数据越稀疏、越充满矛盾，AI 越不可靠，领域专家反而越觉得 AI 没用。
「作弊者天花板」现象：靠 AI 直接拿答案而不真正学习的人，只会在 AI 能给到的水平上停滞——精通的门槛并没有降低。与 ZZ-1015（Bitter Lesson）形成互补：Sutton 说通用方法最终胜过人类知识编码，Bedor 说在前沿领域人类知识仍然不可替代，两者的张力值得持续关注。
跨条目主题线索
| 主题 | 相关条目 |
|---|---|
| AI 加速生产但审查/验证成为瓶颈 | ZZ-887, ZZ-992, ZZ-1009, ZZ-1010 |
| Spec/文档作为中间层的有效性争论 | ZZ-1001, ZZ-1014, ZZ-1015 |
| 人类工程师角色转型（作者→架构师/编辑/验证者） | ZZ-1009, ZZ-1010, ZZ-1017 |
| 通用方法 vs 人类知识编码的历史规律 | ZZ-1015, ZZ-1014, ZZ-1017 |
| AI 的天花板与地板问题 | ZZ-1018, ZZ-1015, ZZ-993 |
| 组织结构与审查层级作为真正瓶颈 | ZZ-887, ZZ-992, ZZ-1009 |