OpenAI 跑得快，不靠加班：给 AI 团队装一个“摩擦报警器”
做 AI 项目的人，大概都见过这种场面。
一个提示词优化要找产品确认，一个接口权限要等研发排期，一份数据又卡在法务审核。大家都很忙，也没人摆烂。可两周过去，那个本来半天能解决的问题，还躺在群聊里“持续跟进”。
这不是执行力差。
这是团队里的摩擦没人接。
OpenAI 内部有一个很有意思的做法：员工遇到阻碍时，可以发邮件到 friction@openai.com。它像一个专门收集“组织卡点”的入口。你不需要知道该找哪个部门，也不用硬扛到周会再说。
这个思路很值钱。尤其是做 AI 产品的团队，节奏快、角色杂、变化猛。一个没人处理的小卡点，几天后就可能变成一次项目延期，或者一位关键同事的离职念头。
下面咱们把这套方法拆开，做成一套能落地的团队机制。
什么叫“摩擦”？别把它误当成抱怨
摩擦，不是“我不喜欢这个流程”。
它指的是：一件合理的工作，因为流程、权限、信息或协作方式出了问题，被不合理地拖慢了。
常见场景很具体：
- 你想调用一个模型 API，审批人休假，工单三天没人看。
- 产品经理改了需求，研发、算法、运营拿到的是三个版本。
- 标注数据缺字段，大家在群里 @ 来 @ 去，没有人拥有修复权限。
- 一个 Bug 明明影响付费用户，却因为“优先级评审排到下周”只能干等。
- 新同事入职两周，还没拿到知识库、代码仓库和模型平台权限。
这些事单看都不大。
堆起来，就会把团队拖进“每天都在忙，版本却发不出来”的泥潭。很烦，对吧？
一个好用的摩擦入口，核心是这 4 个零件
别急着注册邮箱、建表单。工具只是外壳，真正有效的是下面这套设计。
1. 一个谁都能用的入口
入口必须足够简单。
可以是一个邮箱，例如 friction@你的公司.com；也可以是飞书群机器人、Slack 工作流、Notion 表单。关键不是长什么样，而是员工遇到问题时，30 秒内能提交。
建议表单只保留 4 个字段：
1. 你被什么事情卡住了？
2. 它影响了什么工作？
3. 你已经尝试过什么？
4. 你希望谁来协助，或希望得到什么决定？
别设计成事故复盘报告。
你想收集的是卡点，不是考员工写作文。字段一多，大家就会想：“算了，忍一忍。”
2. 一个明确的“接球人”
最怕的情况是什么？
你提交了问题，系统自动回复一句“已收到”，然后石沉大海。那这个机制活不过一个月。
需要指定一个摩擦负责人，人数不用多，1 到 3 人就够。这个角色不一定亲自解决全部问题，但必须负责：
- 判断问题属于权限、流程、资源还是跨团队冲突
- 找到真正能拍板的人
- 盯住处理时限
- 把重复出现的问题推成制度修复
小团队可以由 COO、项目负责人或轮值 PM 担任。
如果团队规模超过 50 人，建议建立轮值制度。每周一位负责人值班，避免所有麻烦都压在同一个“老好人”身上。
3. 一套简单的分级规则
所有问题都按同一种速度处理，等于没有规则。
可以直接用这套四级分类：
| 等级 | 判断标准 | 处理目标 | 示例 | | --- | --- | --- | --- | | P0 | 影响线上服务、安全或重大客户 | 1 小时内响应 | 模型接口大面积报错、用户数据权限异常 | | P1 | 阻塞关键项目或多人工作 | 当天响应 | 发布前拿不到生产环境权限 | | P2 | 流程明显低效，但有临时绕法 | 3 个工作日内处理 | 每次数据导出都要人工找三个人签字 | | P3 | 改进建议或体验问题 | 纳入月度治理 | 知识库分类混乱、会议过多 |
这里有个小提醒：
响应，不等于解决。
P0 问题一小时内做不到彻底修好很正常，但必须有人出来说清楚：谁在处理、当前判断是什么、下一次同步时间是几点。
人最怕的不是等，而是不知道有没有人在管。
4. 一个公开的闭环看板
摩擦机制如果只在私下运转，员工很快会失去信任。
建议建一个全员可看的看板，至少展示：
- 问题编号
- 问题摘要
- 当前负责人
- 状态：新提交 / 处理中 / 已解决 / 暂不处理
- 预计完成时间
- 处理结论
涉及薪酬、人事、合规或客户敏感信息的内容，可以隐藏细节，但状态别消失。
看板的作用不是“监督谁慢”。
它是在告诉团队：提问题不会白提。
AI 团队可以直接照抄的工作流
拿飞书、Slack 或 Notion 都能搭。下面是一版轻量流程，10 人到 100 人的团队都能用。
员工提交卡点
↓
摩擦负责人在 4 小时内确认收到
↓
判断等级与归属团队
↓
指定唯一 Owner 和解决期限
↓
同步进展，必要时升级给负责人
↓
关闭问题，并记录根因
↓
每月统计高频问题，改流程而不是反复救火
注意“唯一 Owner”这四个字。
一件事挂了三个负责人，通常等于没有负责人。协作方可以很多，拍板和推进的人只能有一个。
示例：一个模型权限问题，怎么从 5 天压到半天
假设你们在做一个企业知识库问答产品。
算法同学需要开通新的模型推理额度，用于评估 RAG 召回效果。以前的流程是：
算法同学找项目经理
项目经理问研发负责人
研发负责人找平台团队
平台团队要求补工单
工单还要业务负责人审批
一轮下来，评测计划已经往后推了四天。
接入摩擦机制后，可以这样处理：
- 算法同学提交：
评测被模型额度卡住，影响本周版本验收，需要临时增加 200 万 Token 配额。 - 值班负责人判定为 P1。
- 平台团队负责人被指定为 Owner，当天下午给出临时额度。
- 事件关闭前补一条流程修复：对已备案项目，额度申请自动进入平台队列，不再经过业务负责人重复确认。
你看，真正有价值的不是“有人帮忙开了权限”。
而是下次同类需求出现时，团队不必再演一遍找人接球的连续剧。
每周看 3 个指标，别把机制做成许愿池
摩擦入口上线后，不要只盯提交数量。
提交变多，未必是坏事。很多时候，说明大家开始相信这个渠道了。
更值得看的，是这 3 个指标：
平均首次响应时间
从员工提交到有人明确接手，花了多久？
如果这个数字超过 1 个工作日，员工会默认：发了也没用。
平均关闭时间
按 P0、P1、P2 分开看。
别用一个平均数掩盖问题。P0 被拖三天，P3 半天关掉，报表看起来可能还挺漂亮，现实里已经炸锅了。
重复摩擦率
同类问题一个月出现 5 次，别再逐个处理了。
这说明你们缺的不是救火队，而是流程改造。
例如：
- 重复出现“权限申请慢” → 改权限分级和自动授权。
- 重复出现“需求版本混乱” → 强制单一需求源，禁止群聊口头改需求。
- 重复出现“模型成本超预算” → 给项目配置实时成本仪表盘和阈值告警。
容易翻车的 5 个坑
把入口当成匿名吐槽箱
匿名可以保留，尤其涉及管理问题时。但每条反馈都必须落到可验证的事实。
少用：
某部门效率太低。
多用：
过去两周，我提交了 3 次数据权限申请，平均等待 4 天，导致评测任务延期。
事实能处理，情绪只能安抚。
负责人没有权限
如果摩擦负责人只能“帮你转发一下”，那只是高级传声筒。
这个角色需要有升级权限。遇到跨部门扯皮时，能直接拉负责人进来定结论。
只解决单个问题，不修根因
今天给 A 同学开权限，明天给 B 同学开权限，大家看似很勤快，实际上是在给烂流程续命。
每关闭一个 P1 或 P0 问题，都问一句：
下一个人会不会再踩这个坑？
答案是“会”，就必须补流程。
用公开看板羞辱人
看板用来展示问题状态，不是排行榜。
不要写“XX 部门拖延 8 天”。可以写“等待跨部门审批，已升级，预计周三完成”。解决问题比制造敌意重要得多。
允许问题无限期“处理中”
“处理中”是最危险的状态。
每个问题都要有下次更新时间。哪怕暂时无法解决，也要明确写：为什么做不了、谁能决定、何时再评估。
一份可以直接发到群里的提交模板
把下面这段固定在机器人欢迎语或群公告里，够用了：
【摩擦问题提交】
- 我被卡住的事情：
- 具体卡在哪一步：
- 对项目/客户/交付的影响：
- 我已经尝试的办法：
- 希望获得的支持或决定：
- 紧急程度：P0 / P1 / P2 / P3
别要求员工自己准确判断优先级。有人填错没关系，值班负责人会校准。
真正要守住的，是“任何人都可以把阻碍说出来”。
写在最后：快，不是少开会，而是少让人无助
很多团队一说提速，就想到压缩会议、催日报、要求“主人翁意识”。听着就累。
真正拖慢项目的，往往不是大家不努力，而是一个人被卡住后，不知道该找谁，也不知道什么时候能得到答复。
给团队留一个摩擦入口，再配上明确的接球人、时限和公开闭环。你会发现，很多所谓的大公司病，根本不用靠口号治。
把那些没人接的球，一个个接起来。
项目自然就跑快了。🚀
