1. 从“螺丝钉”到“AI原住民”：校招生培养的范式转移
最近和几个大厂的朋友聊天，话题总绕不开“校招生”。大家普遍的感觉是，现在的校招生，尤其是技术岗的，和五年前、十年前我们那会儿，完全不是一个物种了。以前我们入职，导师扔过来一本《Effective Java》或者《Unix环境高级编程》，再给个内部wiki链接，自己吭哧吭哧啃一个月，能跑通一个简单的服务就算入门了。现在的校招生呢？他们可能还没毕业，就已经用AI工具链重构过几个开源项目，对GPT-4、Claude 3、Cursor、Spring AI这些名字如数家珍，甚至自己动手搭过AI Agent的工作流。
这背后是一个根本性的变化：我们正在从“信息时代”的程序员培养，转向“AI时代”的工程师培养。过去，培养的核心是“知识的传递”和“规范的习得”——教你公司用什么框架、代码规范怎么写、发布流程怎么走。但现在，AI大模型正在成为新的“基础设施”和“认知伙伴”，它极大地改变了知识获取、问题解决和代码生产的效率与路径。一个熟练使用AI编程工具的校招生，其生产力在特定场景下可能远超一个仅靠记忆和经验的中级工程师。
因此，“AI时代如何培养校招生”这个问题的答案，不再是简单地优化原有的导师制、培训课程，而是需要一场系统性的范式转移。培养目标要从“熟练的代码执行者”转向“会提问、善协作、能定义问题的AI增强型问题解决者”。这意味着，我们培养的每一个环节——从入职引导、技术赋能到项目实战——都需要被重新审视和设计。这篇文章，我想结合我最近在团队里的一些实践和观察，聊聊在这个新范式下，我们具体可以做些什么。
2. 认知对齐：首先，管理者需要更新自己的“操作系统”
在讨论具体培养方法前，我认为最关键的一步，是团队管理者或导师自身认知的升级。如果带人的导师自己还对AI工具持怀疑态度，或者仅停留在“ChatGPT就是个高级搜索引擎”的认知层面，那么后续的所有培养动作都可能走形。
2.1 正视AI带来的“能力平权”与“经验贬值”
我们必须承认，AI在某些方面实现了“能力平权”。一个校招生通过精准的Prompt工程和上下文管理，可以让AI生成出结构清晰、甚至包含一些最佳实践的代码草案。这在过去，是需要多年项目历练才能形成的“手感”。同时，一些基于记忆和模式匹配的“经验价值”正在快速贬值。比如，记住某个复杂API的所有参数，或者手动编写一个标准的CRUD控制器，这些工作的壁垒正在被AI极大地削平。
作为管理者，我们的心态要从“我懂得比你多，所以我来教你”，部分转变为“我比你更懂业务、更懂权衡、更懂在复杂系统中做决策，我们一起来探索如何用AI更好地解决业务问题”。这是一种从“权威传授”到“协同探索”的转变。
2.2 亲自下场，成为AI工具的深度用户
你无法指导你不了解的东西。我强烈建议每一位需要带校招生的技术骨干或管理者，至少深度使用1-2款AI编程工具（如Cursor、Github Copilot、通义灵码等），并尝试用AI辅助完成一些日常工作，比如写设计文档、审查代码、生成测试用例、排查复杂日志。
只有你自己用过，你才能：
- 建立合理的预期：知道AI擅长什么（生成模板代码、解释代码、重构建议）、不擅长什么（复杂的业务逻辑设计、对模糊需求的澄清、跨多个系统的架构决策）。
- 识别“AI幻觉”：能一眼看出AI生成的代码中那些看似合理实则错误的“一本正经的胡说八道”，并知道如何引导校招生去验证和排查。
- 积累实战经验：形成自己的一套“人机协作”工作流和Prompt技巧，这些才是你能传授给校招生的、最有价值的“软性知识”。
举个例子，我要求团队里的导师们，在给校招生布置第一个任务前，自己先用AI工具尝试完成一遍。这个过程不是为了得到完美答案，而是为了预判校招生可能遇到的坑：AI可能会给出哪种过时的依赖版本？生成的代码是否符合我们项目的代码规范？哪些业务逻辑是AI绝对无法凭空生成的，必须由人来补充？有了这些预判，指导就会更有针对性。
3. 重塑入职引导：从“知识灌输”到“环境配置与思维建立”
传统的入职引导，往往是一周的公司文化培训，加上厚厚的技术栈文档。在AI时代，这套流程的效率太低了。我们应该把入职初期的时间，重点花在以下几件事上：
3.1 配置“AI增强型”开发环境
入职第一天，除了拉代码、配环境，应该增加一个核心环节：帮助校招生配置好他的“AI副驾驶”。
- 工具链统一与授权：明确团队推荐或允许使用的AI工具列表（如公司采购的Copilot企业版、允许使用的特定大模型API），并协助完成安装、账号配置和权限申请。避免校招生因为信息不对称，去使用一些存在安全、合规风险的第三方工具。
- 上下文工程初始化：指导校招生如何为AI工具“注入”公司/项目背景。这比看文档高效十倍。例如：
- 将项目的技术架构图、核心领域术语表、代码仓库的README，作为上下文提供给AI。
- 编写一个项目专用的“System Prompt”，告诉AI：“你现在是一个为[XX公司XX项目]工作的助手。我们主要使用Java 17和Spring Boot 3框架，数据库是MySQL，代码规范遵循阿里规约，日志使用SLF4J+Logback。请用中文回答，代码中不要使用
System.out.println。”
- 内部知识库的AI化接入：如果公司有内部Wiki、设计文档库，探索是否能通过RAG（检索增强生成）技术，让校招生能直接向AI提问关于内部系统的问题，而不是在海量文档中盲目搜索。
3.2 建立“批判性使用AI”的思维模式
在工具配置好的同时，必须立刻植入正确的使用观念。我会在入职培训中明确强调：
- AI是副驾驶，不是自动驾驶：生成的任何代码、方案，你必须理解、审查并为其最终质量负责。你不能对AI说“给我实现一个支付系统”，然后就直接提交代码。
- 验证是强制步骤：AI生成的代码，必须运行、必须结合单元测试验证、必须进行Code Review。对于关键算法或逻辑，要能独立解释其工作原理。
- 提问的质量决定答案的质量：花时间学习如何提出好的问题（Prompt Engineering）。模糊的问题只能得到模糊甚至错误的答案。要练习将大问题拆解成具体的、可被AI执行的小任务。
- 安全意识：严禁向公共AI模型粘贴公司源代码、敏感配置、内部数据和个人信息。明确数据安全的红线。
我们可以设计一个简单的实操练习：给校招生一个简单的业务需求（比如“用户注册”），要求他们先用AI生成一个代码草稿，然后自己手动补充业务校验、异常处理、日志打印，最后对比两者的差异，并写出审查报告。这个练习能快速建立“人机协作”的真实体感。
4. 项目实战培养：在真实迭代中训练“定义问题”的能力
度过了引导期，校招生会进入项目组参与实际开发。过去的培养，可能侧重于“如何实现一个功能”。而在AI时代，我们应该更侧重于“如何定义清楚一个功能”，以及“如何拆解和验收一个由AI辅助实现的功能”。
4.1 任务拆解：从“实现”到“描述”
导师给校招生派活的方式需要改变。以前可能会说：“小王，你去把用户订单列表查询接口实现一下，按时间倒序，支持分页。” 现在，更有效的派活方式是：“小王，我们需要一个用户订单列表查询接口。这是相关的数据库表结构。请你先思考并向我澄清以下几个问题：1. 这个接口的调用方是谁？前端需要哪些字段？2. 除了时间倒序和分页，还有没有其他过滤条件（如订单状态）？3. 预期的数据量级是多少？是否需要考虑性能优化？4. 想清楚后，请你用文字清晰地描述这个接口的输入、输出、业务规则和边界条件，然后我们可以讨论。”
这个过程中，校招生需要动用他的业务理解能力、沟通能力和逻辑思维，去把一个模糊的需求“定义”清楚。这个“定义”的产出物，本身就是一份优质的Prompt，可以用来驱动AI进行辅助编码。导师的价值，就在于引导他完成这个“定义”的过程，并评审其完整性。
4.2 Code Review 重点转移：从“语法细节”到“逻辑与架构”
当校招生提交的代码中，有相当一部分由AI生成时，Code Review的关注点必须调整。
- 减少对“样式”的过度关注：如果团队有完善的代码格式化工具（Prettier, Checkstyle），那么花大量时间在缩进、命名风格上的争论会减少。AI可以很好地遵循这些规则。
- 聚焦于“为什么”：Review时要多问：“这段逻辑为什么这样设计？”“如果输入异常数据，这里会怎么处理？”“这个实现和我们系统的其他模块是如何协作的？”“这里为什么选择A方案而不是B方案？” 目的是迫使校招生深入理解业务和架构，而不是仅仅当一个代码的“搬运工”。
- 审查“AI缝合怪”：警惕代码中出现风格迥异、逻辑断裂的段落，这可能是校招生简单拼接了多个AI生成片段的结果。Review时要指出这种“缝合”痕迹，并要求其对整体逻辑流进行梳理和重构，保证代码的内聚性。
- 将“AI幻觉”作为教学案例：如果发现代码中存在因AI幻觉导致的问题，不要简单地指正。可以把它变成一个教学时刻：“你看，AI在这里生成了一个
deprecated的方法，我们来一起查一下官方文档，看看现在推荐的做法是什么。” 这个过程能极大地提升校招生的信息甄别和验证能力。
4.3 设立“AI工具专项挑战”
为了主动提升校招生运用AI解决问题的能力，可以在常规开发任务外，设立一些小的专项挑战。例如：
- “遗留代码理解与重构”：给出一段复杂的、文档缺失的遗留代码，要求使用AI辅助分析其功能，并给出重构建议和测试用例。
- “技术方案调研”：给出一个技术选型问题（如“如何实现一个分布式环境下的幂等性保障”），要求使用AI辅助收集资料、对比方案，并输出一份带有个人分析的简短报告。
- “自动化脚本编写”：针对一个重复性的手动操作（如日志分析、数据统计），要求使用AI生成自动化脚本。
这些挑战的目标不是产出生产级代码，而是锻炼他们“将问题转化为AI可理解任务”以及“对AI输出进行批判性整合”的能力。
5. 能力模型重构：评估什么，就得到什么
传统的校招生能力评估，可能侧重于代码量、任务完成速度、Bug数量。在AI时代，这套评估标准会失灵——一个善于使用AI的校招生，可能代码量很大但原创性低；任务完成很快，但可能埋下了理解上的隐患。
我们需要重构能力评估模型，将以下维度纳入重点考察范围：
5.1 问题分析与定义能力
- 需求澄清：能否主动识别需求中的模糊点，并通过提问和沟通将其具体化？
- 拆解能力：能否将一个复杂问题，拆解成一系列可由AI或自己逐步解决的子任务？
- 边界思考：能否考虑到异常场景、性能瓶颈、安全风险等非功能性需求？
5.2 AI工具的有效使用能力
- Prompt工程：提出的问题是否精准、清晰、包含必要上下文？能否通过多轮对话引导AI逼近最优解？
- 结果验证与调试：是否建立了对AI输出的系统化验证流程？能否快速定位AI生成代码中的错误或不足？
- 工作流整合：是否形成了高效的、个性化的“人机协作”工作流？能否将AI工具无缝嵌入到需求理解、设计、编码、测试、调试的全流程中？
5.3 批判性思维与深度学习能力
- 超越复制粘贴：是否满足于AI给出的第一个答案？是否会主动追问“为什么”、“还有没有更好的方法”？
- 溯源与探究：对于AI提到的概念、库、方法，是否会主动查阅官方文档、源码或权威资料进行深度理解？
- 知识体系构建：能否将AI提供的碎片化信息，整合进自己系统化的知识框架中，而不是留下一个个孤立的“答案点”？
5.4 协作与沟通能力
- “AI生成”的透明化：在技术讨论和代码评审中，能否清晰地说明哪些部分由AI辅助生成，自己的核心贡献和决策点在哪里？
- 经验分享：是否乐于分享自己使用AI工具的心得、发现的优质Prompt或遇到的坑？
在季度或年度考核时，我们可以通过案例答辩的形式来评估这些能力。例如，让校招生复盘一个他完成的任务，重点讲述：1. 他是如何理解和拆解需求的；2. 在哪个环节、如何使用AI工具，遇到了什么困难；3. 他对最终方案的技术决策是如何思考的。通过他的讲述，我们能更清晰地看到其思维过程和能力成长。
6. 文化氛围营造：打造学习型团队，而非“AI竞赛场”
最后，也是最重要的，是整个团队文化氛围的营造。引入AI工具后，要避免两个极端：一是保守排斥，二是盲目崇拜。更要避免形成一种“唯AI论”的暗地竞赛，比谁生成的代码快，而不是比谁解决的问题好。
- 倡导“透明协作”文化：在团队内公开讨论AI的使用，鼓励大家在设计评审、代码评审中分享AI提供的思路和方案（无论是被采纳的还是被否决的）。设立一个共享的Prompt库或经验分享频道，让大家积累的“如何让AI更好地理解我们的业务”的经验能够流动起来。
- 导师的角色进化：导师不再是唯一的知识来源，而是进化为“思维教练”和“质量守门员”。他们的核心职责是引导思考、启发探究、把关最终产出的业务合理性与系统稳健性。团队需要为导师提供培训，帮助他们适应这个新角色。
- 鼓励“深度思考”：在周会、技术分享中，留出时间讨论那些AI目前不擅长解决的问题，比如复杂的业务建模、跨系统架构权衡、人性化的用户体验设计等。强调人的不可替代性在于其创造力、同理心和系统思维。
- 管理预期，关注成长：明确告诉校招生，公司引入AI工具是为了让他们如虎添翼，而不是为了替代他们。公司的长期价值，依然寄托于他们个人综合能力的成长。减少他们对“被AI取代”的焦虑，将他们的注意力引导到如何利用AI实现更高阶的成长上来。
培养AI时代的校招生，本质上是一场关于“人的价值”再定义的探索。技术工具在变，但培养的初心不变：那就是激发潜能、陪伴成长，帮助每一个年轻人从校园人转变为能够创造真实价值的职业人。只不过，我们现在需要更新地图和装备，在这场新的旅途中，和他们一同成为“AI原住民”。这条路没有标准答案，以上也只是我们团队现阶段的一些实践和思考，肯定存在不足，也欢迎大家一起交流探讨。
