AI时代，我们到底该怎样培养校招生？

最近看了腾讯云架构师合肥同盟周老师写的一篇关于 AI 时代校招生培养的文章（https://cloud.tencent.com/developer/article/2717501），很有感触。

文章讨论的并不是一个简单的培训问题，而是一个越来越现实的组织问题：

当 AI 已经进入研发流程，校招生还应该像过去一样，先花几个月学习基础、熟悉项目，再慢慢进入实战吗？

还是应该借助 AI，尽快让新人参与项目、产生价值？

这两个选择，看起来都有道理。

过去培养校招生，通常讲究循序渐进。

先补基础知识，熟悉开发规范，阅读项目代码，再从简单功能和低风险任务开始，逐步接触核心业务。

这种方式不一定快，但相对稳妥。

现在，环境已经发生了变化。

AI 编码助手、智能问答、测试生成、代码审查、知识库检索，正在快速进入研发流程。

团队的交付速度变快了，公司对效率的要求也更高了。

在这样的背景下，如果一名校招生进入公司几个月，还只是学习、看文档、熟悉代码，很多管理者难免会产生疑问：

既然已经有了 AI为什么培养周期还是这么长？

新人能不能更快进入项目？

培养投入什么时候才能转化成实际产出？

但问题是，如果只是把 AI 工具交给新人，再把项目任务压给他，情况可能更加危险。

代码可能很快写出来了，接口也能跑通，测试看起来也补齐了。

可一旦继续追问：

为什么这样设计？

这个方案有什么风险？

异常情况下会发生什么？

数据错了怎么处理？

线上出了问题应该先看哪里？

很多新人未必能够真正回答。

因为表面上是新人完成了任务，实际上可能只是 AI 帮他拼出了一个答案。

周老师的文章让我重新思考一件事：

AI时代，我们到底是在培养工程师，还是在培养一批会调用AI的人？

AI把新人变快了，也把能力问题藏起来了

过去，一个新人基础不扎实，很容易暴露出来。

代码写不出来，报错解决不了，接口不会调，数据库不会设计。

不会就是不会，问题看得见，也比较容易针对性培养。

现在不一样了。

AI可以生成代码，可以解释错误，可以补测试，也可以写技术方案。

一个人能力不足，不一定会立刻表现为“做不出来”。

更多时候，它会表现为一种假象：

需求完成了，但说不清业务逻辑；

代码提交了，但看不出潜在风险；

问题修复了，却不知道真正原因；

测试生成了，却不知道是否覆盖关键场景；

方案写得很完整，却没有真正理解其中的取舍。

这其实比不会写代码更值得警惕。

不会写可以学。

但一个人如果不知道自己不会，甚至把 AI 给出的答案直接当成正确答案，后面的风险会更大。

AI降低了编码门槛，但并没有降低工程门槛。

真正的工程能力，从来不只是把代码写出来。

还包括理解业务、拆解问题、设计边界、控制风险、验证结果，并对最终交付负责。

这些能力，AI可以辅助却无法替人承担。

图片

不能只看新人完成了多少需求

在交付压力之下，团队很容易用完成了多少需求来判断新人是否成长。

今天修一个问题，明天加一个接口，后天改一个页面。

从任务数量来看，新人似乎很快进入了状态。

但几个月以后，团队可能会发现：

他做过不少需求，却没有建立完整的能力结构。

他熟悉的是某几个页面、几个接口和几段代码，却不了解系统为什么这样设计。

他可以借助 AI 完成任务，却不能独立判断方案是否合理。

他看起来一直在产出，但一旦离开 AI 或离开导师，就很难独立解决复杂问题。

所以，评价校招生不能只看做了多少事情，还要看他有没有发生几种变化：

是否越来越能独立拆解问题；

是否开始理解系统背后的设计逻辑；

是否知道哪些内容可以交给 AI，哪些判断必须由人完成；

是否能识别 AI 给出的错误答案；

是否开始具备对结果负责的意识。

如果这些能力没有成长，所谓的快速上手，很可能只是让新人更早进入重复劳动。

AI时代，更不能放弃基本功

一种常见观点是，AI已经能写代码了，新人没有必要再花大量时间学习基础。

我反而觉得，恰恰因为 AI 能快速生成代码，基础能力才更加重要。

没有数据库基础的人，看不出一条 SQL 为什么可能拖垮系统。

没有并发意识的人，不知道一段正常运行的代码，在高峰期为什么会产生重复数据。

不理解事务的人，不知道为什么一个业务操作只执行了一半。

不熟悉安全规范的人，可能会把 AI 生成的权限逻辑直接放进生产环境。

不了解业务的人，更无法判断一段代码虽然可以运行，却已经违背了真实业务规则。

AI能够给出答案，但它不会替企业承担损失。

未来真正拉开工程师差距的，可能不再是谁写代码更快，而是谁能够更快判断：

这段代码能不能用；

这个方案会带来什么代价；

这个答案建立在哪些假设之上；

这个结果是否真的解决了业务问题。

所以，AI时代不是不要基本功，而是不能再用过去低效率的方式培养基本功。

图片

培养方式要从先学后做变成边做边长

过去培养新人，通常是先学习，再实践。

先把基础知识学完，把项目熟悉清楚，再逐步进入真实项目。

今天更现实的方式，是让学习和项目同时发生。

新人入职后，不需要先花几个月把所有知识学完。

可以先用较短时间，集中补齐与当前项目最相关的基础能力：

如何启动项目；

如何阅读代码；

如何提交和评审代码；

如何设计接口；

如何操作数据库；

如何写测试；

如何看日志；

如何使用 AI；

如何判断 AI 输出是否可信。

这一阶段不追求大而全，也不要求新人一开始就把所有底层原理研究透彻。

但有一个原则：每一个知识点，都要和真实项目连接起来。

学习数据库，就去看项目中的真实表结构。

学习接口，就去分析一个真实调用链。

学习日志，就去复盘一个历史故障。

学习测试，就给现有模块补充测试用例。

学习 AI，就用真实需求练习如何拆解、提问、验证和修正。

学习不能只是听课、看文档和记笔记。

每学完一个内容，最好能够给团队留下一个可复用的成果。

可能是一份项目启动指南，一张业务流程图，一份模块说明，一组测试用例，或者一条常见问题记录。

这样新人的学习过程，本身也在为团队创造价值。

不要随手给新人分任务，要设计任务

很多团队带新人时不是没有任务，而是没有设计过任务。

项目里有什么活，就临时分给新人什么活。

有的任务过于复杂，新人只能依赖导师和 AI 硬着完成。

有的任务过于边缘，做了几个月，也没有真正接触业务和系统核心。

真正适合新人的任务，应该具备几个特点：

边界清晰，出现问题时风险可控；

结果可验证，不依赖模糊判断；

与真实业务相关，而不是孤立练习；

每一个任务都对应一项明确能力。

第一个任务，可以是修复一个低风险缺陷，训练代码阅读和问题定位。

第二个任务，可以是增加一个简单接口，训练需求理解、数据处理和测试意识。

第三个任务，可以是改造一个已有功能，训练对历史逻辑和兼容性的理解。

再往后，可以让新人参与一次联调、一次上线、一次非紧急线上问题排查。

任务不是越多越好。

重要的是，每完成一个任务，新人都能多掌握一种解决问题的方法。

如果新人只是不断完成需求，却没有形成自己的方法，做再多任务也只是重复劳动。

图片

导师不应该包办一切

校招生人数一多，传统的一对一师徒制很容易失效。

导师自己也有项目、有交付、有会议，不可能每天投入大量时间，逐个解决新人的所有问题。

真正可持续的方式，是把导师从重复答疑中解放出来。

环境搭建、代码规范、分支流程、常见报错，这些内容应该逐步沉淀到知识库、任务库和标准文档中。

新人之间也可以先讨论、先互助，再把解决不了的问题提交给导师。

导师真正应该出现的地方，是几个关键节点：

第一次理解需求时；

第一次设计技术方案时；

第一次提交完整代码时；

第一次参与上线时；

第一次处理线上问题时；

第一次进行完整复盘时。

这些节点，决定了新人以后如何理解工程、如何判断问题、如何形成工作习惯。

好的导师，不是新人问什么就直接给出答案。

而是不断追问：

你为什么这样判断？

还有没有其他可能？

这个方案的风险在哪里？

你准备怎么验证？

上线失败以后怎么处理？

导师的价值，不是替新人解决问题，而是帮助新人建立解决问题的框架。

不应该禁止AI，而应该让使用AI变得透明

有人担心新人依赖 AI，于是希望限制甚至禁止校招生使用 AI。

这种方式并不现实。

AI已经逐渐成为研发基础设施。

刻意不让新人使用 AI，就像过去不让工程师使用搜索引擎一样，最终只会让培养脱离真实工作环境。

问题不在于是否使用 AI，而在于怎样使用。

生成代码初稿、解释框架用法、补充测试、整理文档、辅助分析错误，这些场景完全可以使用 AI。

但涉及核心业务规则、资金权限、用户隐私、生产数据修改、系统架构和线上事故判断时，必须更加谨慎。

更重要的是，新人不能只提交 AI 生成的结果。

他还应该能够说明：

我让 AI 解决的具体问题是什么；

AI 的回答依赖哪些假设；

哪些地方可能存在错误；

我是如何验证的；

测试是否覆盖了关键风险；

最终结果是否符合真实业务规则。

只要不能解释、不能验证、不能承担责任，这段代码就不应该轻易进入正式环境。

企业可以接受新人借助 AI 提升效率，但不能接受新人把责任也交给 AI。

真正需要培养的，是判断力

AI时代，很多技能的价值都在发生变化。

过去，我们更加关注一个人能不能熟练写出代码。

今天，代码生成的成本正在快速下降，真正稀缺的是判断力。

能不能判断需求背后的真实问题；

能不能判断一个方案是否过度设计；

能不能判断 AI 的答案是否可靠；

能不能判断哪些风险必须提前处理；

能不能判断什么时候继续独立排查，什么时候应该及时求助。

这些能力无法靠一场培训获得，也无法靠看几份文档形成。

它只能在一次次真实任务中，通过选择、验证、犯错和复盘慢慢建立。

所以，企业要设计的，不应该只是一套校招生培训课程。

更应该是一条判断力不断升级的成长路径。

一个月后，新人应该能够独立启动项目、理解基本流程、完成低风险任务。

三个月后，应该能够独立完成中低复杂度需求，设计基本测试，定位常见问题。

六个月后，应该能够负责一个小模块，完成从需求理解、方案设计、开发测试到上线复盘的完整闭环。

到了这个阶段，我们才能说，一名新人正在真正从执行者走向工程师。

企业最终要建设的，是一套人才培养系统

过去带新人，更多依赖某个导师是否认真、是否有经验。

导师能力强，新人成长快。

导师项目忙，新人就只能自己摸索。

这种方式无法规模化，也无法复制。

站在技术管理者的角度，校招生培养最终必须从个人行为，变成组织能力。

把高频问题沉淀成知识库；

把合适的项目任务沉淀成任务库；

把关键能力沉淀成考核标准；

把导师经验沉淀成带教方法；

把新人踩过的坑沉淀成团队案例。

每一届新人进入公司，都不应该重新从零开始。

每一届新人完成培养，也应该给下一届留下一些东西。

当培养过程可以重复、可以衡量、可以持续优化时，公司才真正拥有了人才培养能力。

否则，企业只是不断招聘新人，再不断依赖少数骨干，用个人时间把新人带出来。

写在最后

看完周老师的文章，我最大的感受是：

AI让新人更容易完成任务，但完成任务不等于形成能力。

企业既不能因为担心风险，就让校招生长期停留在学习阶段；也不能为了追求短期效率，把新人直接交给 AI。

真正合理的方式，是让新人尽早进入真实项目，但不是毫无准备地进入；让新人充分使用 AI，但不是毫无判断地使用；让导师减少日常干预，但必须守住关键节点。

最终要培养的，不是一个写代码速度更快的人。

而是一个面对复杂问题时，能够独立思考、合理使用 AI、验证结果，并愿意对最终交付负责的人。

AI可以帮助新人更快进入项目。

但一个人能不能真正成长为工程师，最终取决于他有没有形成自己的判断。

这件事，AI替代不了。