定期 AI 分诊会议
在你公司的某个角落，有一份从未被审阅的 AI 请求清单。它正在不断变长。没有人负责它。而且每周都在变长。
我在各处都看到这种现象。团队开始试验 AI，请求越积越多——能不能自动化这份报告，能不能总结这些通话，能不能为那件事做个机器人。每一个都落到不同的人手上。每一个都在等待一个永远不会到来的决定。于是这堆积物变成了 AI 落地失败的坟场。
解决办法简单到令人尴尬：一场定期会议。每周三十分钟，每次只有一个议程、一个决定。
为什么没有它请求就会卡住
请求卡住不是因为人们懒惰。它们卡住是因为缺少机制。接收 AI 请求的人既没有批准它的权限，也没有为它出资的预算科目，更没有对“同意”意味着什么的清晰流程。于是他们做出了最自然的选择：什么都不做。而“什么都不做”正是扼杀这一动力的元凶。
请求本身就是瓶颈。每一个得不到决定的试验，都是组织在收集却没有处理的信号。定期会议就是那条处理流水线。
分诊会议存在的理由只有一个：每一个 AI 请求要么在三十分钟内得到决定，要么当场就得到决定。
议程：三个问题，一个决定
会议每周一次，每次三十分钟，每次都按同样的方式运行。过一遍清单。针对每个请求，问三个问题。
它解决的是真实问题吗？不是一个炫酷的问题——而是一个真实的问题。这个请求是否对应着真实存在的成本、周期时间或客户痛点？大多数请求在这里就被否决，这没问题。快速否决正是意义所在。一个在三十秒坦诚评估中就被否决的请求，是不会吞掉团队一个季度的请求。
用现有资源能做到吗？这里就是范围变得真实的地方。那个听起来很大的请求——“自动化我们整个报告流程”——会变成第一步：“自动化周一的销量报告。”几乎每个请求都有一个用现有工具两周内就能交付的 v1 版本。这个问题逼着那个 v1 浮出水面。
谁来负责？这正是整场会议存在的决定。没有负责人的请求只是一个愿望。有负责人的请求才是一个项目。负责人不一定是工程师。负责人是那个感受到痛的人，因为只有他知道这个修复是否真的解决了问题。
三个问题，每个请求一个答案：否决它、启动它，或带个日期搁置它。
谁在会议室里
只有当拥有话语权的人在场时，这场会议才有意义。你需要三个席位。一个能对范围说“不”的人——一位经理或负责人。一个能对投入说“可以”的人——那个会去做或推动完成这件事的人。还有一个能对预算说“可以”的人，哪怕只是小额的许可。如果这场会议连一个两周的试验和一百美元都批不下来，那它就不是决策会议，而是一个讨论小组，而你已经有很多那样的讨论了。
保持紧凑。三十分钟，硬性截止。这场会议应当在效率上让人略感不适。这里发生的是决定，而不是闲聊。
三个月后会发生什么变化
给它九十天，看看那堆积物会怎样。
请求不再无声地消亡——它们会被大声、迅速且有理有据地否决。这是真正的进步，因为一个被告知“不行，因为它没有解决真实问题”的团队会继续前行。而被冷落、沉默的团队则会停止提议。
小的胜利开始交付。这里一个两周的 v1，那里一个两周的 v1。单独看没有一个亮眼。合在一起，它们就是一个谈论 AI 的组织和一个真正使用 AI 的组织之间的差别。
模式也随之浮现。几个月后，你会看到请求开始聚拢——同样的任务不断从不同团队冒出来。那就是你的路线图。那个聚拢点才是你应当认认真真建设的地方，因为那是你现在已经测量过、而不是凭空猜测的需求。
议程里没人写下的那部分
这场会议还有第二项从不写进议程的工作：它告诉整个组织，AI 请求是被认真对待的。当一个团队看到自己的想法在一场真正的会议里、由一位真正的负责人做出了真正的决定，他们就会带来下一个想法。当他们看到请求消失在沉默中，他们就会停止。
采纳是一个循环，而循环需要心跳。定期会议就是那个心跳。三十分钟，三个问题，一个决定，每周如此，没有例外。
那堆积物不必成为坟场。它只需要一位裁判。开始这场会议吧。快速否决，从小处启动，指派负责人，然后让模式告诉你下一步该在哪里建设。这就是整个系统。