工程团队引入AI后仍保留旧流程，作者列出本季度应砍掉的11项做法

大多数工程组织都引入了 AI，却保留了为更慢时代建立的仪式。以下是本季度应当退役的十一件事，以及替代方案。

大多数工程组织在过去一年里采用了 AI 工具，其他一切照旧。站会照开，sprint 照常收尾，速度图表照常呈给管理层，PRD 照旧冗长，PR 审查照旧以统一深度进行，手动 QA 照旧对每次变更执行，工程招聘的职位描述也还是老一套。

这才是大多数 AI 采用效果不佳的真正原因。工具不是瓶颈，pre-AI 时代积累下来的流程才是。你保留的每一个仪式、角色、报告和产物，都假设人类是吞吐量的约束。Agent 打破了这个假设，流程却没有收到通知。

以下是本季度应当砍掉的十一件具体事项。不必一次全砍，也不必全砍，但这是给一个想让 AI 采用不止于速度提升的团队列出的认真退役候选清单。每一项都说明：它原本是干什么的、为什么现在代价高昂、以及用什么替代。

Sprint 是为缓慢、昂贵的人工执行而设的协调仪式。两周窗口让团队批量规划，并根据学到的东西重新规划。这两项职能在 AI 原生执行下都不成立。规划需要锚定在交付周期长于一个 sprint 的成果上。重新规划需要持续进行，而不是批量处理。

替代方案是成果周期：以四到六周为一个单元，锚定一个具体成果，内部持续流动，结束时做成果复盘。Sprint 退役，工作节奏更好，管理层向上汇报的故事也更清晰。

站会用于暴露阻塞点，并让团队了解彼此的工作。AI 原生系统在这两件事上做得更好。阻塞点会在工作中自然浮现，因为状态在工作所运行的系统中可见。了解彼此的工作，更适合用异步的日终帖来完成（三行：我做了什么、我学到了什么、我接下来接什么），它会作为可搜索的上下文留存下来。

上午 9 点的站会要花掉整个团队三十分钟外加上下文切换。异步节奏是每人两分钟、异步进行，并产生一份团队一个月后还能搜索的书面记录。换掉它。

故事点是用一种脱离人时的单位来估算工作的尝试。即便在人时是约束的时候，它也运作得并不完美。当 agent 用零头时间完成实现、而变异性落在规格质量上时，它完全不起作用。

现在真正重要的估算单位是风险：这个变更有多可逆、结果有多未知、验证有多难。应当用风险分级取代故事点。变更分为低风险、中风险、高风险。这就是团队需要的唯一粒度。

速度衡量吞吐量。在 AI 原生团队中，吞吐量不是有用的首要指标，因为它可以在系统变差的同时上升。团队可以交付更多 PR，同时变更失败率攀升、事故率累积。速度会告诉你这个故事的前半段，却对后半段保持沉默。

替代方案是以变更失败率作为首要指标，速度作为次要信号。一个 CFR 上升且速度上升的团队，比一个速度持平且 CFR 下降的团队状况更差。当前向管理层展示速度却不展示 CFR 的惯例，是一种管理层汇报失职。本季度修正它。

每一份 AI 采用演示文稿的第一页都展示许可证数量：“我们向 200 名工程师推广了 Copilot。”这个指标毫无意义。工具访问权限不产生成果。从 AI 采用中获得持久回报的团队，不是许可证最多的那些，而是上下文基础设施最深、agent 可读的测试套件最干净、审查流程适配得最好的那些。

用成熟度信号取代许可证数量：上下文层的完整度、测试套件的 agent 就绪度、审查流程的风险分级、agent 工单关闭率。这些才是真正推动成果的东西。许可证数量是虚荣指标，就把它当虚荣指标对待。

传统规则是每个 PR 至少一次审查，有时两次，不管改了什么。在 PR 数量受人类生产速度约束时，这说得通。它撑不过 AI 原生的 PR 数量，因为审查者无法对十倍量的变更付出同等注意力。

替代方案是风险分级审查。通过全部自动化检查的低风险 PR 走更轻的审查，有时在冷却窗口后自动合并。高风险 PR 获得深度审查。资深工程师的注意力按风险分配，而不是按队列顺序分配。做得好这一点的团队会发现，他们的资深工程师在做更多架构工作、更少审查工作。团队的整体审查深度在重要的地方上升，在不重要的地方下降。

一份包含上下文层维护、agent 技术栈归属、验证基础设施，外加人员管理、辅导、招聘和利益相关方同步的 EM 工作，是一份工作装了两份职责。大多数 EM 两件事都做得很糟，因为两件事都做好，超出一个人应被期望承担的负荷。

替代方案是拆分角色：EM 负责人员和交付，Engineering Lead 负责技术深度和 agent 技术栈。两人向同一位经理汇报，在领导层桌上有同等席位。这一拆分最多付出一次晋升的代价，却能解锁目前没人有时间去做的技术领导工作。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）