这套AI新人onboarding方案，两周后他产出超预期，是何原因？

上周，那个实习生小杨找我聊了一次。 他说："老师，我感觉来了两周，学到的东西比我预想的多很多。" 我心里清楚，这不完全是我的功劳。 一个月前他刚来的时候，我脑子里只有一个念头： 我根本没时间带他。 一、一个真实的困境 小杨是校招实习生，Java方向，学过 Spring Boot，写过几个课程作业，理论不差，但没有真实项目经验。 照往常的带法，我应该： 带他熟悉代码库 讲一遍业务背景 分配一个小任务，每天花时间答疑 出了问题一起 debug 问题是，我那段时间正在主导等保三级整改（143个字段，7天），根本抽不出系统性的时间。 以前也带过实习生，常规套路下，前两周基本是我在陪跑，他在消化，产出接近于零，我自己也焦虑。 这次，我决定换一种做法。 让 AI 承担"陪跑"的角色，我只做关键节点的决策。 二、第一步：用 AI 给他设计一张学习地图 以前新人入职，我的做法是：丢一堆文档，说"先看看"。 这次，我先把我们的项目背景、技术栈、小杨的现有能力，整理成一段描述，喂给 Claude： 我有一个实习生，情况如下： - 背景：大三，学过 Java + Spring Boot，写过课程项目，没有生产级项目经验 - 我们的技术栈：Spring Boot 3, MyBatis-Plus, Redis, RabbitMQ, MySQL - 项目类型：B端 SaaS 平台，有复杂的权限体系和业务流程 请帮我设计一套两周的 onboarding 学习计划： 1. 每天的学习重点是什么 2. 用什么方式验证他学会了（不是考试，而是能做出东西） 3. 哪些东西应该自己摸索，哪些应该我来讲 4. 有哪些坑是新人必踩的，可以提前告诉他避开 AI 给出的两周计划，我调整了几个地方，变成了这个版本： 第一周：读懂系统 Day 1-2：环境搭建 + 跑通主流程 验收：能自己发起一个完整的接口调用，从前端到数据库 Day 3-4：读核心模块代码 要求：选一个你觉得最看不懂的模块，写一份"我的理解"文档 验收：我来看这份文档，评估他理解对了几成 Day 5：提 3 个"为什么这么设计"的问题 不要问语法问题，要问设计决策 验收：我来回答，看问题质量 第二周：做一个真实功能 Day 6-8：独立实现一个小需求（我来选） 要求：先出方案，我 approve 之后再写代码 Day 9-10：Code Review + 上测试环境 要求：先过 AI Review，再给我看 这张地图，我花了 20 分钟调整，然后直接发给了小杨。 他看完沉默了一会儿，说："比我预想的要有结构。" 三、第二步：让 AI 替我回答 80% 的问题 新人 onboarding 最累的不是讲课，是回答那些碎片化的问题。 一天下来，七八个问题，有的是环境问题，有的是语法问题，有的是"这段代码为什么这么写"。 每个问题单独看都不难，但打断你的节奏、消耗你的注意力，一天下来你什么都没做成。 我告诉小杨： 遇到问题，先问 AI。 把你的问题、你尝试过的方法、AI 的回答，一起发给我。 如果 AI 回答完你还不明白，或者 AI 的答案你觉得有问题，再来找我。 这个规则，改变了我们的互动方式。 一个真实的记录： 第三天，小杨遇到了一个分页查询 N+1 的问题。 他先问了 AI，AI 解释了 N+1 是什么、给了修改建议。他看完还是有点懵，然后发给我的是： "AI 说要用批量查询替代循环查询，我大概懂了，但我不确定在 MyBatis-Plus 里具体怎么做，AI 给了两种写法，我不知道选哪个。" 这个问题，质量高多了。 他不是在问"N+1 是什么"（AI 已经回答了），而是在问"两种方案我该怎么选"——这是需要判断力的问题，也是我应该回答的问题。 我花了 3 分钟，解释了两种写法的适用场景，他立刻明白了。 两周下来，小杨发给我的问题，80% 都是这种"已经有 AI 答案、但需要我帮他做判断"的问题。 我节省了大量时间，他也学会了一个重要习惯：先独立思考，再寻求帮助。 四、第三步：用 AI 做他的代码 review 第一关 第二周，我给小杨分配了一个真实需求：做一个操作日志模块，记录用户在后台的关键操作，支持按时间和操作类型查询。 不复杂，但涉及注解设计、AOP 拦截、异步写入，刚好是能拉开差距的场景。 规则和我们团队一样：提交给我之前，先过 AI Review，把结论贴到代码注释里。 他交上来的时候，代码里有这么一段注释： /** * AI Review 结论（2026-03-28）： * 1. [严重] 日志写入是同步的，如果日志服务出问题会影响主流程 → 已改为异步 * 2. [中] 操作人信息从参数里取，建议从 SecurityContext 统一获取 → 已修改 * 3. [低] 方法名 saveLog 不够语义化，建议改为 recordOperation → 待确认 * * 我的判断：第3条我觉得两个名字都可以，保留 saveLog，因为和其他模块命名一致。 */ 我看到这段注释的时候，停了一下。 不只是因为他改了 AI 发现的问题。 而是因为他对 AI 的第 3 条意见，给出了自己的判断，并且说明了理由。 他没有照单全收，也没有全部无视。他在思考。 这是我带过的实习生里，第一次在第二周就看到这种状态。 我做的 Review，只补了一个他和 AI 都没发现的地方：AOP 切面在某些特殊情况下会失效的边界条件，这是我们项目特有的坑，不在代码里，只在经验里。 加了这条备注，这个功能上测试环境，一次通过。 五、两周结束时，数据说了什么 两周结束，我做了一个简单的复盘。 小杨的产出： 一份"我对核心模块的理解"文档，质量超出预期（我发现了他漏理解的两处，但整体框架是对的） 3 个设计层面的问题，其中一个触及了我们现有架构的一个真实隐患 一个完整功能，代码质量达到了我们团队"可以上线"的标准 我的投入： 总共和他面对面沟通约 4 小时（以往带一个新人，前两周至少 12 小时） 回答的问题，80% 是"判断类"问题，20% 是"解释类"问题 做了一次有效的代码 Review，时间约 30 分钟 和以往的对比： 以往带新人（前两周）： - 我的投入：12-15 小时 - 新人产出：熟悉了环境，能写简单功能，代码质量一般 - 核心问题：我的时间都花在重复解释上 这次（前两周）： - 我的投入：约 4 小时 - 新人产出：一个可上线功能 + 一份有价值的理解文档 - 核心转变：AI 过滤掉了 80% 的重复问题，我只处理需要判断的部分 六、但有一件事我没想到 第二周结束时，我问小杨：最大的收获是什么？ 他想了一会儿，说： "学会了怎么和 AI 协作。不是让它帮我写代码，而是用它帮我想清楚问题。" 然后他补了一句： "但有时候 AI 说的太有道理了，我差点没自己想就直接用了。那个操作日志的名字，AI 建议改，我第一反应是'AI 说改就改吧'。后来想了想，才发现有自己的理由可以不改。" 这句话让我想到了一件事。 我在这两周里，给了他大量"先问 AI"的任务，但我没有明确告诉他：AI 的答案是参考，不是裁判。 他自己在第二周摸索出来了，但这件事，我本来应该在第一天就讲清楚。 这是我这套方案里，现在还在打磨的一个地方。 七、可以直接用的模板 如果你也要带新人，这套流程可以直接参考。 Prompt 1：生成 onboarding 学习计划 我有一个新人，情况如下： - 背景：[学历/工作经验] - 现有技能：[会什么] - 我们的技术栈：[列出来] - 项目类型：[一句话描述] - 我能给他的时间：每天约 [X] 小时 请帮我设计一套 [两周/一个月] 的 onboarding 计划： 1. 每天的学习重点 2. 如何验收（能做出什么东西，而不是考试） 3. 哪些靠自己摸索，哪些需要 mentor 介入 4. 新人必踩的坑，可以提前告知的 Prompt 2：引导新人问出好问题 给新人的规则（直接发给他）： 遇到问题的处理顺序： 1. 先查文档或自己想 10 分钟 2. 想不出来，问 AI 3. 把"你的问题 + 你尝试过的 + AI 的回答"一起发给我 4. 如果 AI 回答完你还不懂，或者 AI 给了多个方案你不知道选哪个——来找我 不要直接问我你没想过的问题。 Prompt 3：新人代码 Review 的 AI 前置模板 给新人的标准流程： 提交代码前，先把 diff 喂给 AI，用这个 Prompt： "请对以下代码做 Review，重点关注： 1. 潜在 bug（空指针、并发、边界条件） 2. 安全风险 3. 性能问题（N+1、大循环） 4. 代码规范和可维护性 对每个问题说明严重程度和修改建议。" 然后： - AI 发现的问题，说明你的处理决策（修改 or 保留，要说理由） - 把这段记录贴到 PR 描述或代码注释里 - 再提交给 mentor Review 八、写在最后 两周结束，小杨问我下一步要做什么。 我说：继续做真实需求，难度升一档。 他问：还是用这套方法吗？ 我说：框架不变，但有一条你已经应该内化了——AI 是你的参考，判断是你自己的事。 他点了点头，说他明白了。 我觉得他确实明白了。 带新人这件事，难的从来不是"传授知识"。 知识，AI 比我讲得更全，更有条理，更有耐心。 难的是帮他建立判断力——知道什么时候该信 AI，什么时候该质疑，什么时候应该有自己的答案。 这件事，只有人能做。 但 AI 把我从重复解释中解放出来之后，我终于有时间，专门做这件事了。 你带过新人吗？有没有试过用 AI 来帮你设计 onboarding 流程？ 欢迎评论区聊聊。 后端AI实验室 不讲概念，只谈实战 代码开源，每周更新