跳到主要内容

5 篇博文 含有标签「team-structure」

查看所有标签

联邦制 AI 团队:为何集中 AI 专业能力反而制造了它本应解决的问题

· 阅读需 11 分钟
Tian Pan
Software Engineer

中央 AI 团队本应是答案。把最优秀的 ML 工程师集中到一个团队,统一工具链,建立治理机制,让产品团队无需深入理解 AI 就能直接消费 AI 能力。这是一个听起来很美的架构——在组织架构图上清晰可见,在董事会演示中无懈可击。然而在实践中,它可靠地生产出一种失败模式,看起来恰恰就像它本要消除的碎片化。

中央 AI 团队变成了瓶颈。产品团队在后面排队等待。它交付的 AI 对每个需要特定功能的领域来说都显得过于通用。构建平台的 ML 工程师不了解产品指标。需要帮助的产品工程师只能靠提工单才能调试 AI 行为。一个 3 个月的试点成功了;一个 9 个月的安全审查把它埋葬了。

2025 年,企业放弃 AI 项目的比率已超过 2024 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。

Eval 瓶颈:你的 Eval 工程师现在就是路线图

· 阅读需 13 分钟
Tian Pan
Software Engineer

你的 AI 路线图的瓶颈不是 GPU 容量、模型可用性或 Prompt 工程的品味。它是那一两个真正懂得如何构建能发现回归(regression)的评估(eval)的工程师的日程表。每个负责功能的产品经理都在他们的队列中。每一次模型升级都在他们的队列中。每一次群体漂移、每一次 Prompt 修改、每一个“这个评审模型(judge)是否仍然校准”的问题,最终都会进入同一个收件箱。而这位工程师在本季度已经说了三次“不,这还没准备好”,两次被否决,眼睁睁看着回归在生产环境中复合增长,现在正在更新他们的 LinkedIn。

这就是评估瓶颈,大多数组织在被咬到之前都意识不到它的存在。到 2025 年为止,显而易见的工作重点是 AI 工程师——招聘 AI 工程师、发布 AI 功能、迭代 Prompt、更换模型。到了 2026 年第一季度,吞吐量问题下移了一层。将 AI 团队人数翻倍的团队发现,增加更多功能工程师并没有让功能发布得更快,因为每个功能仍然需要一个评估(eval),而负责评估的工程师还是那个人。

AI 功能的 RACI 模型:为什么四个绿色仪表盘组合在一起却是一个破碎的产品

· 阅读需 13 分钟
Tian Pan
Software Engineer

一个 AI 功能在周二出现了回归。评估(eval)CI 是绿色的。护栏(guardrail)仪表盘很干净。检索(retrieval)P95 指标正常。模型供应商没有任何故障。然而,支持队列中挤满了用户,他们反映助手“本周感觉变差了”。产品经理(PM)是房间里唯一能说出哪里回归的人,但即便是她也无法告诉你哪个仪表盘能捕获到这个回归。欢迎来到“接缝 Bug”(seam bug)的世界——这种故障中,每个单独的产出物负责人(artifact owner)都能证明自己的部分没问题,但集成后的体验依然是坏的。

这是 AI 功能人员分配方式的必然结果。纸面上的负责人名单看起来很合理:提示词作者负责系统提示词,评估负责人负责离线测试集和 CI 门禁,工具/检索负责人负责函数调用和搜索索引,护栏负责人负责审核和策略过滤器。此外,还有一个模型选择决策,通常游离在这四者之外——有时归属于平台团队,有时归属于最近提交采购单的那个工程师。五个负责人,却没人对“这个功能对用户是否有用”负责。

提示词所有权问题:当康威定律盯上你的 Prompt 时

· 阅读需 13 分钟
Tian Pan
Software Engineer

每个复杂的 AI 产品最终都会产生一个谁也不敢碰的 prompt。它包含三个条件分支,两个在处理客户报告的事故时临时粘贴进去的内联示例,以及一个以 “IMPORTANT:” 开头的句子,后面跟着一段没人记得是谁写的语气指令。这个 prompt 长达 1,400 个 token。最后一次修改它的 PR 是由一名早已转岗的工程师审核的。当新模型发布时,没人敢保证这个 prompt 依然有效。当评估(evals)结果下降时,没人确定是 prompt、模型、检索流水线还是下游工具导致的。这个字符串被四个服务共享。每个团队都有自己的本地覆盖(override),而且这些覆盖都没有文档记录。

这就是 Prompt 所有权问题,它是多团队 AI 工程中讨论最少却最普遍的失效模式。这不只是一个技术问题,而是康威定律(Conway's Law)在 token 层面的体现。一个组织的 prompt 最终会反映出它的组织架构、RACI 缺口和协作成本——而模型并不关心你的 Jira 层级,它只会为同样不在乎这些的终端用户产生不连贯的行为。

AI 工程团队的人员配置:每个功能都有 AI 组件时,谁负责什么

· 阅读需 12 分钟
Tian Pan
Software Engineer

三年前,"AI 团队"意味着一群藏在组织架构角落里的专家,对产品工程师基本不可见。如今,一位金融科技公司的高级软件工程师,周一用微调模型上线欺诈评分功能,周三为客户支持搭建 RAG 管道,周五调试 LLM 延迟问题。专家并没有消失——但"AI 工作"与"产品工程"之间的边界,消失得比几乎所有人预想的都快。

大多数团队的应对方式是把新头衔贴在旧职位描述上,然后宣告完事。这是错误的答案,功能失调很快就会显现:所有权不清、工具重复,以及一个 ML 平台团队把半数时间花在解释"为什么产品团队不能直接调 OpenAI API"上。

本文探讨如何把结构搭对——不是抽象地谈,而是针对大多数工程组织实际经历的 AI 采用阶段。