这篇内容最值得看的地方，是它把视角直接抬到了组织层。Mike Spitz 没沿着“工程师配上 AI 之后效率更高”这条熟悉叙事往下讲，他干脆换了问题本身，从“如何让工程师产出更多”切到“如何让 agent 在组织里跑得更快”。问题一换，站会、Sprint Planning、Retrospective、代码评审分工、QA 流程，后面基本都会跟着重写。
这场 talk 的标题就很挑衅，Agents Don't Do Standups。标题乍看像一句传播语，往里听才发现他不是在玩概念，他是在复盘一次很完整的组织实验。
PFF 做了一个三个月 case study。同一套代码库、同一批客户场景，一边是两位 heavily agent-assisted 的工程师，一边是十人传统团队。最后的结果很夸张，但又不是那种一听就像营销稿的夸张。
他说，两个人那组可以做到一天五次 deploy，十人组大概是五天一次 deploy。如果按 ticket 数量和复杂度混合衡量产出，前者大概是后者的 10 倍。更重要的是，客户满意度没有掉，还到了 8.6/10，比他们过去七分多的水平更高。
这些数字当然会让人先警惕，因为小团队天生就更快，这个他自己也承认。但这场分享最值得记的，不是“2 个人打 10 个人”的戏剧效果，重点在于他把组织瓶颈换了一个问法之后，整个工程流程为什么会跟着塌陷重组。
一、先承认“工程师不再是唯一瓶颈”
Mike 说得非常直白。过去软件工程这一套 Agile、Scrum、各种 perk、本质上都在围绕一个默认前提运转：工程师是瓶颈。
所以公司会想尽办法优化工程师：
- 更好的协作流程
- 更密的需求拆分
- 更清晰的估时
- 更舒服的环境
- 更完整的项目管理链路
这些东西在“人是主要吞吐瓶颈”的时代是成立的。
但一旦 coding agent 真开始接管大量实现工作，问题就会变。组织再继续围着“人怎么更快”设计，很多动作会慢慢失去意义。真正拖慢速度的，开始变成：
- spec 写得够不够清楚
- design doc 有没有把边界说死
- skills 有没有把组织自己的工程习惯编码进去
- QA 和 ticket 状态能不能自动流转
- 工程师是不是还在把时间浪费在命名、格式、状态同步、重复解释这类低价值协调上
这也是他那句核心改写的分量所在：
不要再问怎么让工程师更快，改问怎么让 agent 更快。
这个视角一旦切过去，很多以前默认合理的流程，看上去就会突然变得累赘。
二、这场实验说明的，是“协调成本被整个拿掉了一层”
如果只是说“工程师用了 AI，所以写代码快了”，这没多新。
但 Mike 的分享里更有意思的部分，是两人组不只在编码层更快，在组织协作层也少了很多历史包袱。原来两个人都要被卡三个月的项目，其中一个人在一个月内就被解放出来，开始去做别的功能。这个变化很重要，因为它意味着吞吐不只是线性提速，开始出现复利。
以前两个人都被锁在同一个项目里，三个月后才一起出来。
现在一个人更早做完，于是更早进入下一轮产出。
组织层面变快的地方，不在单次 coding，而在阻塞时间变短了，任务切换成本在下降，协调链路也被削薄了。
这也解释了为什么他们最后最看重的不是 PR 数，也不是代码行数。
他说得很对，PR 多不代表价值高，代码多更不代表价值高。最后他们还是得回到客户是不是满意。对一个产品组织来说，这才是最终度量。
这个口径我很认同。因为很多“AI 提效”案例最后都容易陷进工程自嗨，觉得 deploy 更频繁、PR 更多、实验更密就是胜利。但如果产品感受变差，或者用户并不买账，那只是更快地产出噪音。
PFF 这次至少给出一个更扎实的信号，速度上来之后，外部体验没有塌。
三、Scrum 没活下来，因为原流程解决的瓶颈已经换了
这场 talk 传播性最强的地方，就是那句 “Scrum did not survive.”
这话很容易被断章取义，听成一种姿态，好像“看吧，AI 来了，项目管理都没用了”。但 Mike 的意思没那么简单。
他不是先讨厌 Scrum，再找 AI 给自己背书。相反，他是在新的交付现实里，重新追问每一个流程动作还有没有必要存在。
他们最后保留下来的东西非常少：
- 每隔一天一次 huddle
- 半小时到一小时
- 工程、产品、设计一起快速过最近做了什么
- 争取尽快把 MVP 扔到生产环境拿反馈
除此之外，很多熟悉的 ceremony 都被拿掉了。
1）Sprint Planning 被拿掉
原因很直接，估时失去意义了。
如果 bottleneck 已经不再主要是人工编码时长，那大家再花一小时围着 ticket 做传统估算，价值会迅速缩水。甚至他还顺手说了句挺现实的话，以后真需要估的可能不是工时，可能是 token 成本。
这话挺扎心，但也很真实。
2）Daily Standup 被拿掉
因为 ticket 状态已经和 PR 状态自动联动：
- 开 PR，自动 in progress
- 进入 review，自动更新
- merge 后，自动 close
以前这些也不是不能做，但需要人维护。现在这部分状态同步完全可以从“口头汇报”退化成“系统事实映射”。
3）Sprint Refinement 被吸进 Spec + LDD 流程
他们把很多原来在 refinement 才慢慢磨出来的东西，前置到了 spec 和 lightweight design doc 里。等 LDD 通过以后，再自动拆 ticket，而且 ticket 结构会尽量避免互相阻塞。
4）Retrospective 被弱化
这点会有争议，但他给的替代指标是客户满意度和常规交付指标。如果有问题，工程师立即提，不等 sprint 尾声统一发言。
我不觉得这套东西适合所有团队照抄，但它至少说明一件事：很多流程不是神圣的，它们只是某个时代的补丁。瓶颈换了，补丁就应该重算。
四、他们的新主流程，其实很像一条围绕 agent 设计的生产线
Mike 后面有个比喻挺好，他说要把 engineering lifecycle 看成 factory。
这个比喻虽然有点工业化，但很适合解释他们的做法。因为他的核心思想就是：把工程交付拆成一组可组合的小动作，然后把这些动作尽可能编码成 deterministic、verifiable、可复用的 skills。
他们现在的主链路大概是这样：
- 先有 spec
- agent 反过来 interview 人，帮你把 spec 问清楚
- agent 基于既有风格生成 lightweight design doc
- 团队对 LDD 给反馈
- 自动生成 tickets
- 再往后生成 PR
- merge 后自动部署到 staging
- 拉起 QA agent，对照 acceptance criteria 做验收
- 后续还计划让 agent 对未满足的 acceptance criteria 自动开修复 PR
如果真按这个思路继续走，组织会慢慢出现一个很明显的变化：人类不再手工推动流程前进，会更多停在关键节点提供判断、约束和验收。
这就跟传统“人负责一切推进，系统只是记录状态”的模式很不一样了。
五、代码评审没有消失，但分工被重新切开了
这部分我觉得特别实用。
他们没有把 code review 整体扔给 agent，也没有死守“所有 review 还是得人来”。他们做的是拆层。
agent 负责什么？
- 命名
- 风格
- 格式
- 那些工程师最不爱收到、也最容易带情绪的低层次意见
工程师负责什么？
- system design
- 关键架构判断
- 真正影响系统走向的决策
这套分法很聪明。因为很多 review 摩擦，本来就不是来自系统设计，更多来自“为什么这个变量又这么命名”“为什么这个风格不统一”。这些事情交给 agent，反而能把人类讨论空间留给更值得讨论的部分。
而且他还提了一个很容易被忽略的点，agent review 可以顺手把情绪因素抽走。工程师不会再因为一些风格意见产生额外心理负担，团队沟通也更干净。
这个分法我觉得比“AI review 全包”靠谱得多。
六、他们筛的，不只是“更会写代码的人”
Mike 说得最狠的一段，是关于人。
他说，不是每个人都能开跑车。
这句话不太政治正确，但他表达的问题很实际。AI 时代并不会平均放大所有工程师。相反，它会放大某一类人：
- 好奇
- 会追根究底
- 遇到不懂的东西愿意自己拆开看
- 不依赖超细颗粒度指令也能往前推进
而那种强依赖超明确 spec、只能在高确定性输入下稳定产出的人，可能会更难适应。
这点很多团队不愿意明说，但我觉得他讲得对。因为 agent-assisted engineering 并不是把人类从思考里解放出来，它更像是把“写代码的体力活”往外挪，然后逼着工程师往前站，承担更高密度的判断、拆解和控制责任。
所以他不建议一上来就全员铺开，也不建议给所有人发一个 Claude Code 或 Codex 再办一次 hackathon，就当完成转型。
这是个特别值得记的提醒。
很多组织失败，不是工具不行，是把 adoption 想得太轻。每个工程团队的习惯、代码风格、抽象偏好、容错边界都不一样。你不先从最强那批工程师开始，把模式跑通、把技能沉淀、把 guardrails 立好，后面铺量只会把混乱放大。
七、他们最强的地方，也许不在 Agent，而在“把组织经验编码成了 Skills”
这场分享背后还有一层更深的东西，他们没有把 agent 当成一个万能黑盒，反而一直在把组织自己的工程习惯编码进去。
比如他们提到：
- LDD 会参考团队过去怎么写 design doc
- API 设计会贯彻特定模式，比如 service repository pattern
- trunk-based development 对应 feature flag 这些都可以做成专门 skill
- ticket 拆分会显式标记阻塞关系
这意味着什么？
这意味着组织不是在“借一个很强的通用 agent 干活”。他们是在把自己的工程文化、设计偏好、约束模式、代码习惯，慢慢固化成 agent 能调用的执行件。
这一步特别关键。
因为如果没有这一层，agent 最终只会生成“平均意义上合理”的东西，也就是那种一看就像 AI 做出来的通用实现。Mike 也提到了这个问题，很多产物会有一种“这明显像 Claude Code 搓出来的味道”。
所以你想把结果做得像自己公司的产品，而不是像某个通用模型的默认审美，就必须让工程团队继续花时间把产品感、品牌感、设计一致性拉回来。
这也说明，AI 没有在消灭工程文化，它是在逼工程文化把自己显式化。
八、QA Agent 这条线，比“写代码 agent”更值得继续盯
他提到的另一条线我也很在意，就是 QA agent。
现在他们的做法是：
- PR merge 后自动部署到 staging
- 拉起 QA agent
- 它去读 tickets 和 acceptance criteria
- 然后按这些标准验收
- 如果没过，标记失败项
- 未来希望 agent 直接基于失败项自动创建修复 PR
如果这套闭环能站住，意义其实很大。
因为它不只是“AI 帮忙写代码”，它已经开始参与定义、执行、回收和修复整个交付闭环。
一旦这个链跑通，组织里很多原来只能靠人盯着的流程，会逐步变成系统自驱。
当然，这种自驱能不能稳住，前提还是 acceptance criteria 足够清楚，guardrails 足够严，环境边界足够可控。不然 self-heal 很容易变成 self-break。
但方向上，我觉得这是比“生成代码更炫”更值得盯的部分。因为真正决定组织吞吐的，从来不只是写出第一版代码，后面怎么被验证、怎么被纠偏、怎么持续回流，同样重要。
九、这场 talk 最后留下来的，是“工程组织要围着新的瓶颈重画”
我看完最大的感受是，Mike 讲的不是 AI 神话，更像一种很冷静的组织再设计。
他没有说工程师不重要，也没有说流程都该砍掉，更没有说所有团队都该明天停掉 Scrum。相反，他一直在强调几件很朴素的事：
- 先从最强工程师开始
- 慢慢铺
- 先挑非关键系统试
- guardrails 先立好
- skills 必须贴合自己团队的工程习惯
- 不要盲目复用带有强烈他人软件观点的现成技能
这些判断让我觉得这场 talk 是可信的。因为它不是在卖一个工具，它是在描述一个组织怎样适应新的生产现实。
如果把这场分享压成一句话，我会记成这样：
下一代工程组织的竞争，不只看谁先接入 coding agent，更看谁先把 spec、设计、评审、状态流转、QA 和工程文化重新围着 agent 组织起来。
PFF 这次 case study 还不能证明这套东西能无限放大到所有团队，但它已经足够说明一件事：很多工程流程之所以还活着，只是因为过去的人类瓶颈还在。现在瓶颈开始移动了，组织图纸也该跟着改了。
附：视频信息
- 视频来源：https://www.youtube.com/watch?v=VMemhtlsoNk
- 演讲标题：Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF
- 频道：AI Engineer