个体提效不等于组织提效
AI 让编码变快，端到端交付却没变快：中位数在降，P85 纹丝不动。交付周期里真正膨胀的是等待——用四步把组织摩擦治理出来。
AI Coding 用起来之后，工程师个人产出明显提升，但端到端交付周期的收益没兑现：交付周期中位数在改善，P85 却顽固地停在三个双周迭代以上。这不是 AI 没用，是瓶颈换了位置——AI 加快了价值创造，组织摩擦原封不动，而后者才是周期的大头。
读完你能回答：
- 为什么只看中位数会误判组织健康？
- 四步治理（可见、可信、定位、挖掘）各自解决什么？
- AI 和 PM 在摩擦治理里怎么分工？
编码快了，交付为什么没快
先把公式摆出来：交付周期 = 价值创造时间 + 组织摩擦时间。组织效率等于前者除以两者之和 tencent-pm-friction。摩擦——等待排期、资源协调、跨团队协同、联调等待、Bug 返工——不集中在某个环节，而是随需求流转在各阶段之间悄悄累积。四个真实交付案例的共同点：真正编码的时间很短，绝大部分周期耗在协作上。
所以只看中位数会误判。中位数改善说明「顺的任务更快了」；P85 不动说明「卡住的任务照样卡」。治理的靶子是长尾，而长尾里藏的正是组织摩擦——这也是 AI 产品看对指标 在交付侧的镜像：量结果不量动作，看长尾不只看中位数。
四步：可见、可信、定位、挖掘
治理不能从「多开会多催办」开始，得从让流程可观测开始 tencent-pm-friction：
| 步骤 | 做什么 | 为什么是前提 |
|---|---|---|
| ① 数据可见 | 对交付流程标准化建模：统一阶段、责任角色、交付条件，拆到「一个任务一个责任主体」 | 组织运行不可观测，治理就没有对象 |
| ② 数据可信 | 状态流转从人工汇报转为系统事件推断：任务状态变化、评审完成、测试流转、发布节点自动驱动 | AI 基于错误数据做分析，结论全是噪声 |
| ③ 异常定位 | AI 持续巡检：阶段等待超时、需求长期未流转、资源负荷异常、单点依赖风险 | 人从事后翻日志，变成收到主动告警 |
| ④ 瓶颈挖掘 | 双周 / 月度维度分析 Lead Time、等待时长、质量趋势、风险分布 | 从解决单个问题，转向优化整个交付系统 |
顺序不能跳。数据不可见就谈异常定位，是让 AI 对着空气巡检；数据不可信就谈瓶颈挖掘，是用错误口径做决策。
AI 发现问题，PM 决定怎么治
分工原则一句话：AI 负责态势感知与问题曝光，PM 负责判断原因、决定调配、推动解决 tencent-pm-friction。AI 的长处是持续盯住几百个任务的等待与流转，把「哪个需求卡了 12 天、卡在哪个阶段」呈现在你面前；判断「为什么卡、要不要插队、找谁解」，仍然是人的事。
PM 的角色因此从「过程管理」（任务有没有人做、节点有没有延期）转向「效率治理」（持续发现并消除过程摩擦）——从推进队列里的单个任务，变成治理队列本身。配套可以沉淀几类 PM-Skills：工作流与自动化规则治理、晨间快照加晚间复盘的健康巡检、只做结构化呈现不替代决策的智能排期。
治理后的样子
腾讯健康四个月的实测数据 tencent-pm-friction：中位交付周期 19 天 → 9 天；P85 从 52 天 → 23 天；可预测性（P85 与中位数的差距）从 33 天收窄到 15 天；30 天以上长尾占比 35% → 7%，60 天以上从 11% → 0；问题发现从事后一两周提前到风险出现后 1–3 天。
注意这些数字的结构：中位数降了一半，长尾几乎被砍光。个体提效（编码变快）通常只能改善中位数；把 P85 和长尾压下去的，是摩擦治理本身。两件事都要做，但别把前者的成绩当成后者的证据。