北京
```html AI提速之后：摩擦该留还是该削？
写代码这件事，AI确实让它快了很多。但代码写得快，不等于交付变快。越来越多的讨论指向同一个现象：工作量堆到了下游——规划、评审队列、测试、发布审批。PR数量涨上去了，交付日期却几乎没动。
于是很多团队开始找解法，方向出奇一致：把整个交付流程里的摩擦都削掉，让新代码流得更快。问题恰恰出在这里。当一个团队认定自己有速度问题，它很容易把每一处摩擦都当成浪费，而其中一部分摩擦，其实一直在干一件有价值的事。
摩擦得分两种来看。
第一种是意外摩擦，比如配环境、翻文档、跨四个团队追一个权限。这些是纯粹的税，应该清零，没什么好争的。很多工程师被这些事拖成了兼职管理员，本来该用来解决问题的时间，全耗在了启动之前。
第二种是必要摩擦，也就是改动之前那句轻轻的“等等，我们确定要这样吗”。在不少团队的实际经验里，这一小段停顿是最便宜的保险。
用一个水过滤器的比喻可能更好理解。过滤器需要靠摩擦才能拦住东西。摩擦全拿掉，什么都拦不住，水直接流过去；摩擦加太多，水又流不动。干净的水来自两者之间的平衡。
代码评审就是这种摩擦。风险改动是在这里被拦下来的，而不是等用户先发现。
“让常见路径变成最省力的路径”这句话本身没错，错的是当这条常见路径直接穿过一个风险改动、而路上一个减速带都不剩的时候。把摩擦优化干净，通常会把护栏连同官僚流程一起拆掉。这套做法能撑一阵子，你会觉得自己很快，直到第一个带bug的风险改动溜过去，影响到每一个用户。
那怎么判断某处摩擦属于哪一种？这里没有巧妙的框架，落到实处的办法是权衡利弊。看流程里的一个环节时，可以问三个问题：保留这处摩擦有什么好处？去掉它能得到什么？又会失去什么？
拿环境配置走一遍这三个问题：它没什么实际好处，修好它能拿回时间，也不会失去什么。结论很清楚。
再拿一次迁移之前那句“等等，我们确定要这样吗”走一遍：去掉它确实能省一点时间，但同时也失去了唯一一个有人停下来问“这个改动会不会伤到用户”的时刻。
从实践角度看，把AI用得最好的团队，做法是把摩擦放在有风险的地方，其余地方一律削掉。所以在团队删掉流程里的下一个步骤之前，值得先问一句：这一步到底在为你换来什么，没有它你会失去什么。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
