新同事入职第一周，最常做的事是等权限。
代码仓库要申请，数据表要审批，测试环境不知道找谁，文档里写的命令已经过期。三天以后，他终于把项目跑起来，发现还缺一个只有老同事电脑里才有的配置文件。
这时候，别说三周做一个 AI 分析助手，三周能把本地环境配明白，已经算适应得不错。
所以我看到 Lyft 的案例时，最先注意的不是“新工程师三周把分析助手做进生产”，而是另一个问题：他们给新人准备了怎样一条路，才让这件事成为可能？
三周不是一个人的速度
Lyft 分享的项目叫 ARIA，Analytics & Rides Intelligence Assistant。它让用户用自然语言做内部分析与出行数据探索。
项目由新工程师作为入职任务推进，从第一天走到生产环境。Data Engineering Weekly 对这篇案例的概括里，特意点出几项不太适合做发布会标题的工作：身份认证、可观测性、状态管理和流式响应。
这恰恰是重点。
一个新人能在三周内交付，不意味着他在三周里独自发明了所有东西。更可能的情况是，组织已经把许多公共问题做成了可复用的路：
- 登录和权限有现成接入方式；
- 服务部署有标准模板；
- 日志、指标和追踪默认可用；
- 数据访问有明确边界；
- 内部文档能让陌生人按步骤走通；
- 遇到问题时，知道应该找哪个团队。
个人速度只是露在水面上的部分。水下是平台、文档和组织习惯。
一个好入职项目，应该同时检验两边
很多团队给新人安排的第一个任务，要么太轻，要么太险。
太轻的是改一个文案、补一个字段，做完以后新人仍然不知道系统怎么运转。太险的是直接接手核心链路，所有人都希望他“快速成长”，其实只是把缺文档的债交给一个还不认识人的同事。
一个好的入职项目，应该同时检验两边：
一边检验新人能否理解问题、做出选择、交付结果；另一边检验平台和团队是否真的允许一个陌生人完成这些动作。
如果新人卡在权限申请，说明权限路径不清楚；卡在本地环境，说明开发体验有问题；卡在发布，说明生产路径只存在于某个人脑子里；卡在数据口径，说明语义没有被写下来。
这些卡点不该只记在新人的试用期评价里。它们也是团队自己的体检报告。
从 Demo 到生产，最慢的通常不是模型
做一个分析助手的 Demo 并不难。
接一个模型，提供几张表，生成 SQL，再把结果画成图。只要问题控制得好，半天就能有一个像样的页面。
生产环境会问另外一些问题：
- 用户是谁，能看哪些数据？
- 一次提问触发了哪些 SQL 和工具调用？
- 对话中途断开，任务状态放在哪里？
- 查询失败后重试几次，费用算给谁？
- 结果是一边生成一边展示，还是等全部完成？
- 模型、Prompt 或数据表变化后，旧问题还能不能复现？
- 错误答案由谁收到反馈，怎么追到原因？
这些问题没有一个能靠更长的 Prompt 自动解决。
它们需要公共认证、日志追踪、任务状态、数据网关、测试集和发布规范。也正因为这些底层工作已经存在，新人才能把时间花在项目本身，而不是每层重新挖一条沟。
文档真正的考试，是新人能不能照着做完
不少团队文档很多。
有架构图，有接口说明，有三年前某次分享留下的 PPT。可当新人要完成一个具体任务时，他仍然需要在群里问：“测试环境地址是哪个？”“这个 token 去哪里申请？”“上线要找谁审批？”
文档数量和可用性不是一回事。
真正有用的文档，应该围绕动作组织：
- 如何在本地运行；
- 如何拿到最小权限；
- 如何接入公共组件；
- 如何验证结果；
- 如何部署和回滚；
- 出错时去哪里看、找谁处理。
而且最好由刚入职的人来验证。老同事读文档时会自动补全缺失步骤，新人不会。他卡住的地方，通常就是文档真正缺的地方。
对普通数据从业者，这个案例还有另一层启发
我们聊 AI 项目时，容易把个人竞争力理解成“会不会 LangGraph”“能不能写 Prompt”“有没有做过 Agent”。
这些当然有用，但生产项目更需要另一种能力：能不能识别并接上现有系统。
一个成熟工程师进入新团队后，不会什么都从头写。他会先找认证怎么接、日志怎么打、任务状态放哪、数据权限谁负责、发布模板在哪里。发现缺口时，他会把缺口写清楚，而不是悄悄在自己的服务里再造一份。
面试里如果要讲类似项目，也不要只说模型、框架和准确率。可以按这五层讲：
- 用户问题是什么；
- 接入了哪些已有平台能力；
- 哪些地方原来没有路；
- 如何验证生产可用；
- 最后给团队留下了什么可复用的东西。
这比“我三周做了一个 Agent”更能说明你真的把东西送进过生产。
判断团队 AI 能力，不妨看一个新人要走多久
以后再听到某家公司“三周上线 AI 项目”，先别急着佩服模型和个人英雄。
问问那三周里，有多少路是现成的：权限、环境、数据、部署、日志、测试和责任边界。
如果每个项目都要从头申请、从头解释、从头接入，那么一次快速上线可能只是几个人拼命的结果，很难复制。
如果一个新同事能沿着文档和公共组件走到生产，遇到缺口还能把它补成下一位新人可用的路，这才是团队真正的速度。
三周做出一个分析助手，表面上是在考新人。
往下看，其实是在考这家公司有没有把路铺好。
我叫石头，在数据行业里摸爬滚打了十几年，见过太多人把个人拼命当成团队效率。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：Lyft Engineering：From Day 1 to Production — Building Lyft’s Analytics & Rides Intelligence Assistant as Onboarding Project · Data Engineering Weekly #278
