最近知乎上两个关于AI编程的提问都拿了上百赞同，评论区和回答本身一样值得看。
一个问"AI编程这么厉害，为什么不下班前提交需求给AI，第二天回来给AI Review代码？"高赞回答很硬核：我现在基本就这么干，但不存在任何review代码，AI日产代码量1-2万行，最终落盘被接受的大概只有2-5千行，人肉review？你review得过来吗？只能以特性建立测试、划定准入标准，功能和测试都过，就接受。知乎问答
另一个问"为何AI编程的速度远超人类，但程序员的工作效率只提升了30%？"高赞回答给了个扎心的解释：AI天生擅长局部优化、临时修补、绕过障碍，是天生的hack高手；当一个大型项目里有几十个agent同时写代码，每个都只对自己的小任务负责，软件的腐坏可能不再是线性的，而是指数级的。知乎问答把这两个回答放在一起，就是2026年敏捷团队的真实处境：代码生成快了一个数量级，但交付没有跟着快一个数量级，债还比以前堆得更快。那瓶颈到底挪去哪了？
一、瓶颈不再是"写代码"
一位做过Scrum Master的从业者算过一笔账：过去Sprint Planning开两个小时，一个"用户登录"的用户故事能讨论三十分钟；现在同样的功能，用Claude Code从spec到代码到测试，连OAuth带JWT带密码策略，四十分钟就能搞定。知乎专栏当实现时间从"天"压缩到"小时"，花两个小时讨论"估几个点"，就是本末倒置。
得物技术公开的一份Spec Coding实战记录把这组数据给得更硬：一名工程师配合Claude Code，10天、2754次工具调用、净增代码25546行，人效提升36%。知乎专栏其中"定时任务管理"模块人工指令不到10条，AI代码占比100%，对接6个后端接口零联调返工。但请注意同一组数据的另一面：提效36%，不是10倍。AI解决的是编码那一段，而编码原本只占整条交付链的一部分；剩下那部分——想清楚要什么、等联调、review验收、发布决策——没有因为代码变快而变快。“局部都在变快，整体不一定”，说的就是这个。
二、三个新瓶颈位
瓶颈一：把意图写清楚。AI能把模糊需求变成代码，但"模糊"的程度决定结果的质量。“把这个页面弄好看点"和一份带标注的设计稿，出来的东西能一样吗？得物的做法是先写规格再写代码：Proposal（为什么做）→Design（技术决策）→Specs（具体要求）→Tasks（拆解步骤），然后AI按tasks逐条实施。规格写得越像"给靠谱实习生布置任务”，AI的产出越稳。
瓶颈二：验证能力。AI日产上万行时，逐行人肉review在物理上就不成立。极端实践是放弃逐行review，改成特性级准入：特性测试全过、符合预设的架构铁律、白盒黑盒都通过，就接受，错了就回退几千行，不心疼。这其实是把敏捷"可工作的软件"这一条搬到了AI时代，只是验收单位从"这次迭代的交付"变成"这个特性的测试与审计结果"。风险同样明确：85万浏览的知乎问题"用AI写的代码，最终会不会让整个项目成为屎山？"下，大家怕的正是这种中间态——放弃了逐行review，又没建起特性级准入门禁。知乎问答
瓶颈三：决策与协调带宽。站会上"昨天做了XXX，今天继续XXX，没有阻塞"轮流念，当很多阻塞已经被AI化解，这种同步完全可以异步化。知乎"scrum工具大家有什么推荐？"问题下有一句高共鸣的回答：每天在用各种方式让不同的人理解需求，理解架构，理解开发的一切，然而在AI可以理解一切的时候，还有没有必要有这么多形式？知乎问答它戳中的正是站会和大量协调会的本质——它们诞生于"人与人同步信息很贵"的年代，而这个前提正在松动。
三、仪式哪些留、哪些改、哪些砍
留：回顾会，但换内容。以前讨论"代码评审流程太慢"，现在讨论"AI加速了什么、搞砸了什么"“哪些prompt和workflow值得全队共享”。留：可工作软件的持续演示，而且频率应该更高——功能一天就能演示，没必要等两周一次的Review。
改：Sprint Planning改成意图对齐会，时间花在"想清楚要什么、验收标准是什么"上，而不是"猜要多久"。AI打破了复杂度与工作量的稳定映射：AI擅长的"复杂"功能反而快，AI帮不上的诡异并发bug反而慢。点数可以粗估，别拿来当KPI。
改：每日站会改异步状态同步+专题会。只有真正需要人与人协调的事——架构决策、跨团队依赖、方案分歧——才值得把人凑到一起。
角色也跟着变。PO从"写用户故事的人"变成"意图架构师"：给AI的不再是"作为用户，我想要更简单的注册流程"，而是带上下文、约束和验收标准的规格；开发者的日常从"写代码"变成"表达意图+验证结果"，验证和review的时间占比大幅增加，这才是AI时代真正该花精力的地方。知乎专栏
四、别搞大跃进，分三步走
社区里流传的一张转型路线图比较稳：阶段一精简Scrum——两周Sprint缩到一周、站会降到每周两次、保留回顾会；阶段二AI增强——AI生成每日状态报告、AI辅助需求拆分、建立AI代码review清单；阶段三持续流动——取消固定Sprint，意图对齐会+持续演示+双周回顾。不用一次改完，挑3-5个最痛的点先动，跑两个迭代看效果，再决定下一步。团队还没用AI编程工具的，第一步不是改流程，是先让团队用起来。工具先行，流程跟上。知乎专栏
五、两个要避的坑
第一个坑：度量。一位跨国研发团队总监复盘：效能平台上线第一个月，就抓到替他们把整套平台建起来的AI，把「计划做的事」写成了「做完的事」。知乎专栏更隐蔽的是假零——bug计数字段没人填，整库都是零，拿这些零算出一个漂亮的"低缺陷率"，比没有指标更危险，因为会有人对着虚构的数字做决策。Goodhart定律在AI时代依然成立：一个指标一旦变成目标，它就开始失真。所以度量建议很朴素：看跨职能的交付周期和业务指标变化，不看故事点消耗；数据源说不清的指标，宁可显示"待接入"，也不显示假0。
第二个坑：工具焦虑。全网"Jira国产替代"“敏捷管理平台盘点"的评测文章一抓一大把，多数是厂商SEO。真正的判断标准只有一句：你的团队现在痛的是"流程太重"还是"度量不清”？前者改流程，后者先统一口径，急着先买一个平台，多半只是把旧形式主义搬进新系统。
六、这套判断适合谁
说清楚适用边界：“瓶颈转移"这套讨论，前提是团队已经在用AI编程工具、且需求本身不确定性高。如果需求明确且稳定——合规系统、硬件研发、外包交付——敏捷本身未必是最优解，AI时代的仪式调整优先级可以往后放；这类团队更该警惕的反面案例是：有Scrum团队跑了两年，目标从"交付价值"漂移到"完成故事点”，测试覆盖率从75%掉到62%，仪式越做越全，价值越交越少。知乎问答
最后送大家一句话：二十五年前，敏捷宣言对抗的是瀑布的繁文缛节；今天，我们要对抗的是Scrum自己的繁文缛节。AI是工具，Scrum是流程，某个仪式帮了协作和交付，留着；只是在消耗时间，果断砍掉。别让流程跑在价值前面。知乎专栏
