AI 专家门诊无法规模化：当你的核心专家成为发布瓶颈

打开公司里那位上线真实的 AI 功能超过六个月的工程师的日历。数一数那些重复出现的 “30 分钟同步 —— 关于 Agent 的问题” 邀请，那些最终被预定的即时 “能耽误你 15 分钟吗？” Slack 消息，那些被标记为 “可选” 但他们实际上不得不参加的架构评审，以及最初只是周五下午的一个时段、现在却每天吞噬两个小时的 Office Hours。然后看看路线图，追踪哪些功能取决于该工程师尚未做出的决定。两者的交集才是你真正的发布时间表。Jira 看板只是虚构。

这就是 AI Office Hours 瓶颈，它在 2026 年的 AI 组织中是核心承重约束，尽管组织里没人会大声说出来。团队快速扩展了 AI 功能开发 —— 每个产品小组都拿到了模型预算，每个 PM 都学会了写 Prompt —— 然后把每一个 “这个模型对吗”、“这里该不该用 RAG”、“我们的评估设计是否有效”、“为什么缓存命中率很奇怪” 的问题都抛给了唯一那个真正上线过足够多生产环境 AI 功能、能给出答案的工程师。六个月后，那位工程师的日历成了半个路线图的限速试剂，“我需要找他谈 30 分钟” 成了你的事故响应本该明确化的核心升级路径。

组织运行的任何仪表盘都看不见这个瓶颈，因为没有仪表盘是为了发现它而设计的。交付速度看起来不错 —— 各小组都在合并 PR。招聘看起来不错 —— AI 工程师的人数在增加。唯一的信号是定性的：PM 们在说 “我们正在等待 Priya 的评审”，工程师们在分支里做原型却从不提交 PR，因为他们不确定方法是否正确，而 Priya 要到周四才有空，还有当本周第八个人发来 “关于 AI 的小问题” 时 Staff 工程师的眼神。当它出现在交付速度报告中时，专家已经开始写辞职信或已经休假了，而组织发现瓶颈的方式就像你发现承重墙的方式一样：通过拆除它。

一个日历如何成为发布门控

造成这种瓶颈的动力并非恶意或管理不善。这是每个独立小组在整个组织层面的理性行为总和。每个小组都面临同样的情况：他们有一个需要 AI 组件的功能，他们有模型预算，他们有一两个基本可用的 Prompt，以及一两个如果不解决、一旦出错就会导致数月返工的问题。对于这些问题，最廉价的答案就是去问那个已经知道答案的人。对该小组来说最廉价的答案，对组织来说却是最昂贵的，因为同样的逻辑在 14 个小组中同时运行。

对专家而言，他们几乎会对每一个请求说 “好” —— 部分原因是拒绝的社交成本很高，部分原因是问题很有趣，部分原因是他们能预见到不回答的后果：小组交付了错误的东西，三个月后清理烂摊子的任务还是会落在他们头上。于是，日历被填满了。起初是快速的 15 分钟 “同步”，然后是 30 分钟的 “设计评审”，接着是一个 “AI Office Hours” 时段，最初是一个慷慨的举动，现在却成了一个排队到下周的队列。专家不再交付功能，而是开始交付决策。他们自己的路线图项目进度下滑。他们的绩效评估变得很奇怪，因为影响是真实的但难以量化 —— 另一个部门的 PM 的项目能顺利发布，归功于专家在两场会议间隙用 17 分钟做出的决定，而没有任何系统记录这些。

组织架构图说这个人是一个团队的 Staff 或 Principal 工程师。实际的依赖图却说他们是一个人的软性平台团队，为 14 个小组待命，没有 SLA，也没有轮换。这就是日历显示的瓶颈。

每个组织最初尝试的三种错误修复方案

当瓶颈终于浮出水面时 —— 通常是因为专家精疲力竭、休假，或接受了竞争对手开出的那份无法拒绝的、带有 2026 年 LLM 专家溢价（22 万至 28 万美元）的 Offer —— 组织通常会采取以下三种反应之一，而每一种都会让问题变得更糟。

第一种错误修复是 “增加 Office Hours”。逻辑是：如果周五下午的时间段超负荷了，就给专家安排每天的时间段。这从两个方向同时加剧了问题。它鼓励组织将更多问题导向瓶颈（询问的成本刚刚降低了），同时也夺走了专家最后受保护的连续专注时间，而这本应是他们产出产出物（评估套件、内部文档、可复用的 Prompt）的唯一时间，而这些产出物本可以真正消除下一轮问题的中介需求。在执行了三个月的 “增加 Office Hours” 后，队列变得更长，专家的深度工作产出降为零。

第二种错误修复是 “再聘请一位资深 AI 工程师”。在 2026 年的市场环境下，招聘需要四到七个月，当他们入职时，他们无法接手这个瓶颈 —— 他们只能站在旁边，因为现有的所有依赖关系都是通过名字与原来的专家绑定的。PM 会向他们信任的人请教，而不是向组织架构图请教，而且这种信任是无法在日历上转移的。新员工花六个月时间建立与原专家相同的上下文，在此期间，原专家的日历变得更糟，因为新员工也在预约他的时间。

第三种错误修复是 “停止提问 —— 你们自己解决”。精疲力竭的专家宣布取消 Office Hours，并告诉各小组去阅读文档。问题并没有停止被提出；只是不再向专家提出。它们被那些不知道答案的人回答了，六周后组织发现两个小组选择了相同的错误嵌入（embedding）模型，三个小组构建了平行的评估框架，而一个小组交付了一个网关无法授权的 tool-call schema。瓶颈从日历转移到了事故评审，而代价不是支付在时间上，而是支付在生产环境中。

为什么这种瓶颈带有鲜明的 AI 特征

每个工程团队都经历过“资深工程师成为瓶颈”的时刻。让 2026 年的 AI 版本变得格外危险的原因，是 AI 功能与传统代码相比，在迭代速度和可逆性特征上的显著差异。

后端服务中的架构决策失误虽然代价高昂，但是可观测的：它会体现在延迟、内存占用或运维报警中。这种错误也是可逆的，代价是重构——代码即产出物，而产出物是可以重写的。而 AI 功能中的架构决策失误，制定时成本极低，发现时却代价巨大。错误的 Embedding 模型可能通过演示环节，却在两个月后才被发现无法处理长尾场景。错误的评估准则可能会误判一次性能退化，导致生产环境用户比仪表盘提前三周发现问题。错误的 Prompt 结构看起来没问题，直到 Prompt 缓存抖动（prompt-cache thrash）导致利润缩减了 30%。错误的代价被推迟到了几个月之后，而支付这些代价的人往往并不是当初做决策的人。因此，专家在决策前的评审所带来的边际价值确实很高——远高于传统代码决策——而组织本能地将所有 AI 问题都推给专家，在量化逻辑上是正确的，即便这种人员配置模式难以为继。

这就是为什么“停止提问”并不是一个听起来那么好的答案。这些问题问得没错。组织已经正确地意识到，AI 决策的逆向成本远高于决策成本。缺失的不是停止提问的纪律，而是一种不终止于单一日程表的解答能力。

将临时性专业知识转化为平台产出

解决办法不是扩展专家本人，而是将专家在 15 分钟交谈中产出的内容——如模型选择依据、Prompt 模式、评估设计模板、需要避免的反面模式——转化为平台产出，让其他工程师无需预约会议即可使用。这就是应用于 AI 的平台工程策略：将专家的专业知识视为内部平台的原型，并投入工程时间将其产品化。

具体来说，这意味着有意识地从同步回答转向异步产出。在每次答疑时间（office hours）结束后，专家（或嵌入的工程师）都要写下答案——不是作为会议记录，而是作为可索引的内部文档，并按照提问的原样进行表述，这样下一个搜索该问题的人就能真正找到它。在两个季度内，专家的日程表应该成为解答新颖问题的地方，而不是反复回答旧问题的地方。

这还意味着要建立起专家一直以来在代劳的平台层。建立评估工具集（Eval harnesses），让 PM 主导的小组无需评估工程师审核即可自行扩展。建立经过批准的模型“黄金路径”，明确标注“核心功能用这个，批处理用那个，实验用另一个”，而无需逐项功能进行咨询。建立一个模型版本固定库，正确处理回滚语义，这样每当供应商更新模型权重时，就不必呼叫专家了。建立一个内部 Prompt 注册表，配合评审流程，将专家作为最终评审人，而非第一道审核关口。这种投入是实打实的——需要 6 到 12 个月的专注平台建设——但其单位经济效益是明确的：每一个平台产出都能从专家的日程表中永久移除一类问题，而该产出的边际成本将在多年省下的 15 分钟会议中得到摊销。

另一半解决办法在于人员配置模式。传统平台团队目标中的 1:15 到 1:20 比例并不适用于 AI。AI 问题更密集、错误成本更高，且随着模型和工具格局的变化，其涉及领域每月都在变动。在组织大规模投入 AI 的第一年，AI 平台与赋能工程师与 AI 功能工程师的比例应接近 1:4 到 1:6，待平台产出成熟后，再降至 1:8 到 1:10。从第一天起就按传统比例配置人员的组织，会在一个季度后再次遭遇答疑瓶颈，因为平台团队本身将变成专家日程表的一个缩减版。

每个 AI 组织本季度都该进行的日程审计

调取你组织中最高级 AI 工程师过去 60 天的会议数据。为每个会议贴上标签：是推进了他们自己的路线图，还是回答了别人的问题。这个比例就是你的瓶颈严重程度。如果他们超过 40% 的时间都在回答问题，那么你实际上已经拥有了一个“单人软性平台团队”，无论你是否给它定名，你都在为此付出代价。

然后观察会议取消的模式。仍在回答每个问题的专家是显性问题。而那些开始拒绝会议、为了“寻找专注时间”而去咖啡馆办公、并在 6 小时后才用一句话回复 Slack 线程的专家，则是更响亮的警号——他们即将通过离职来不再担任你的瓶颈，而日程表就是辞职信正在起草的先行指标。

这里的准则是像对待数据库或安全专家那样对待 AI 专业知识：将其视为一种必须按比例配置人员、产品化为平台、并防止其被自发地引流到单一日程表的职能。做到这一点的团队会发现，他们原以为受限于模型能力的 AI 功能路线图，实际上受限于有多少工程师能正确回答“这种方法对吗”。而没能做到的团队会在 6 个月后的离职面谈中发现同样的道理。