AI 会写代码之后，企业还需要什么样的新人？

过去几年，AI Coding 的变化太快了。

从代码补全，到对话式生成，再到 Coding Agent，AI 已经不只是帮工程师补几行代码，而是开始参与需求理解、代码修改、问题定位、测试生成，甚至尝试完成一个相对完整的研发任务。

这让很多学生和年轻工程师都产生了焦虑：既然 AI 已经会写代码了，那企业还需要校招生吗？如果还需要，那企业到底想招什么样的人？会用 Cursor、Claude Code、Copilot，是不是就够了？算法题、项目经验、基础知识，还重要吗？

最近在内部讨论校招生培养时，HR 也正好问到了类似问题。对方问我：在 AI 这个背景下，今年的校招生培养思路应该是什么？可以提供哪些学习工具和方式？

我当时的第一反应是：这件事不能只理解成“给新人上几节 AI 工具课”。

因为 AI 时代真正变化的，不只是工具，而是新人进入工程体系的方式。

过去我们培养新人，通常是让他熟悉业务、熟悉代码、熟悉流程，然后逐步承担需求。这个过程仍然重要。但现在，AI 让新人可以更早接触复杂代码、更快生成实现方案、更快完成某些局部修改。问题也随之变化了。

过去新人最大的门槛，可能是“不会写”。现在 AI 可以帮你写一部分代码，但新的门槛变成了：你是否真的理解需求？你是否知道该给 AI 什么上下文？你是否能判断 AI 写得对不对？你是否能验证结果是否可靠？你是否能把代码从“生成出来”推进到“可交付”？

所以，我越来越觉得，AI 时代企业不是不需要新人，而是会重新定义：什么样的新人值得培养。

很多关于 AI 的讨论，容易走向一个极端判断：AI 会替代初级工程师。

这个判断有一定道理，但不完整。

AI 确实会压缩一部分低价值、重复性的编码工作。过去一些需要花半天到一天完成的样板代码、简单页面、字段调整、文案样式修改，现在 AI 可以在更短时间内完成。对于只会机械执行、只会照着已有模式搬代码的人来说，空间会被明显挤压。

但这并不意味着企业不再需要新人。

企业仍然需要新人，因为组织需要持续补充新鲜血液，需要有人理解业务、参与系统演进、承担工程交付，也需要在真实项目中培养下一代骨干。

真正变化的是，企业对“新人”的期待变了。

过去，一个新人能够比较快地把代码写出来，已经是不错的起点。现在，代码生成本身变得更容易之后，企业会更关注他是否具备一些更底层的能力。

比如，他能不能读懂一个模糊需求背后的真实目标？能不能在不完整的信息里识别风险？能不能判断 AI 生成的代码是否符合业务逻辑？能不能知道哪些地方必须自己确认，而不是直接相信 AI？能不能把一次交付从“写出来”推进到“可上线、可验证、可闭环”？

这也是我觉得最关键的一句话：

AI 会降低编码门槛，但不会降低工程责任。

代码写出来，只是工程交付的一部分。真实的软件研发，还包括需求理解、影响范围判断、技术方案选择、代码 Review、自测、联调、发布、回归、线上风险控制。

这些部分，AI 都可以参与，但责任不会自动转移给 AI。

新人如果只是把 AI 生成的代码复制进项目里，然后觉得“能跑就行”，那不是 AI 时代的新工程师，而是 AI 代码搬运工。

而企业真正想要培养的，不是 AI 代码搬运工。

如果从招聘角度看，我不建议把“会不会使用某个 AI 工具”作为核心标准。

工具变化太快了。今天是 Cursor，明天可能是 Claude Code、Codex，后天可能是公司内部自研的 Coding Agent。一个学生今天会用某个工具，并不代表他未来一定能适应新的研发方式。

所以，会用 AI 是加分项，但不是底层能力。

AI 时代更值得关注的，是候选人有没有在 AI 环境下成长为可靠工程师的潜力。我会更看重几类特质。

AI 时代不是基本功不重要，而是基本功更重要。

这听起来有点反直觉。既然 AI 能写代码，那是不是新人就不用那么重视基础了？

恰恰相反。

因为 AI 能生成代码，所以新人更需要判断代码是否正确。判断力的来源，不是 Prompt 技巧，而是工程基本功。

一个基本功薄弱的人，拿到 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 理解代码、生成思路、比较方案、辅助 Debug、补充测试用例。但他也知道，AI 可能编造 API，可能误解业务，可能修改不该修改的地方，可能给出看似合理但实际有问题的实现。

他不会把 AI 当成权威，而是把 AI 当成一个能力很强、但需要被约束和验证的协作者。

这是 AI 时代非常重要的心态。

如果只能选一个 AI 时代最容易被低估的新人能力，我会选验证意识。

AI 让代码生成变快，但也让错误更隐蔽。

以前一个新人写代码写得慢，很多问题会暴露在写的过程中。现在 AI 可以很快生成一大段看起来结构完整、命名规范、逻辑顺畅的代码。它越像正确答案，就越容易被人相信。

但真实工程里，“看起来对”远远不够。

你要知道怎么验证它。

比如，一个筛选项改动，不只是页面上多一个输入框。它可能影响查询参数、默认值、分页重置、导出逻辑、URL 状态、权限控制、历史数据兼容。

一个表单字段调整，不只是加一个字段。它可能影响校验、回显、提交、编辑态、只读态、异常提示、接口协议。

一个样式调整，也可能影响不同屏幕、不同数据长度、不同浏览器、不同主题下的表现。

所以，未来新人交付质量的差异，可能不只是谁写得快，而是谁更会验证。

如果面试里问一个候选人：AI 帮你生成了一段代码，你怎么判断它能不能上线？

一个比较浅的回答可能是：我会跑一下，看功能正不正常。

一个更好的回答会包括：我会检查需求目标、修改范围、边界输入、异常分支、历史逻辑、代码规范、测试用例和回归影响。

这两类候选人的差距，会在 AI 时代被放大。

所以，如果学生问我：AI 时代到底应该准备什么？

我的回答不会是：你赶紧学会某个工具的所有技巧。

工具当然要用，而且应该尽早用。不会用 AI 的工程师，未来会越来越吃亏。

但更重要的是，不要把自己训练成“只会问 AI 的人”。

你应该训练的是一套更底层的能力：能把模糊问题讲清楚；能把复杂任务拆开；能给 AI 提供必要上下文；能比较不同方案的代价；能识别 AI 输出里的风险；能设计最小验证集；能在出问题后复盘原因。

这些能力不会因为工具变化而失效。今天你用 Cursor 是这样，明天用 Claude Code 是这样，后天用公司内部 Agent 也是这样。

真正重要的不是熟悉某个工具按钮，而是知道如何借助 AI 完成一次可靠交付。

如果把这些能力放到一张图里，它大概不是“AI 工具能力”单独一层，而是以工程基本功为底座，以问题理解、AI 协作和验证意识为中间能力，最终指向真实工程交付。

讲完招聘，再看培养。

如果企业仍然沿用过去那套方式，只是额外加一节“AI 工具培训”，大概率是不够的。

传统新人培养通常包括：技术培训、业务培训、导师带教、熟悉项目、逐步接需求。这些仍然需要，但在 AI 时代，培养路径应该增加几个新的重点。

我会把 AI 时代的校招生培养目标定义为：培养能够在 AI 环境下完成真实工程交付的新一代工程师。

不是培养“会用 AI 写代码的人”，而是培养能理解问题、组织上下文、驱动 AI 协作、验证结果，并对交付质量负责的人。

对应到能力上，可以分成四类：工程基本功、问题理解能力、AI 协作能力、验证与责任意识。

这四类能力不能只靠讲课建立，必须放到真实任务里训练。

如果让我设计一个轻量版本，我会把培养分成四个阶段。

第一阶段，是 AI 工具认知与安全规范。

这个阶段的目标不是让新人炫技，而是建立正确认知。新人需要知道团队推荐使用哪些 AI 工具，哪些信息不能输入 AI，哪些任务适合交给 AI，哪些任务不能直接交给 AI，AI 生成代码为什么必须经过 Review 和验证。

尤其要建立一个底线：AI 是工程工作台的一部分，不是替你负责的人。

第二阶段，是代码理解与项目熟悉。

新人刚进团队，最缺的其实不是 AI 技巧，而是对真实工程环境的理解。他需要理解项目结构、核心业务链路、组件规范、接口调用、发布流程、历史包袱和常见问题。

AI 在这里可以成为很好的学习助手。新人可以用 AI 辅助理解一个页面、一个组件、一次历史需求、一个线上问题。但最终不能只复制 AI 的总结，而要自己输出理解文档，并接受 Mentor 的确认。

这一步的重点是：用 AI 加速学习，但不让 AI 替代理解。

第三阶段，是低风险任务闭环训练。

不要一开始就让新人承担复杂需求，可以先从文案修改、样式调整、配置项增减、表单字段调整、简单 Bug 修复开始。

但这些小任务不能只是“改完提交”。

每个任务都应该要求新人完成一个闭环复盘：这次需求是什么？修改范围在哪里？我给 AI 提供了哪些上下文？AI 参与了哪些部分？我人工检查了哪些地方？我跑了哪些验证？还有哪些风险？

这个过程看起来多了一点成本，但它会训练新人形成正确习惯：不是 AI 写完就结束，而是理解、执行、验证、复盘形成闭环。

第四阶段，才是真实需求加 Mentor Review。

当新人进入真实业务需求时，导师不需要全程手把手，但要在关键节点把关。

比如需求理解 Review，看新人是否理解目标、边界和影响范围。任务拆解 Review，看新人是否能把需求拆成合理步骤。AI 协作 Review，看新人是否给了 AI 足够上下文，是否控制了修改范围。代码 Review，看实现是否符合团队规范，有没有不必要改动。验证 Review，看新人是否完成自测、回归和风险确认。最后再做一次上线后复盘，看这次任务中哪些经验可以沉淀。

这样的培养方式，目标不是让新人永远依赖导师，而是让他逐步从“需要别人定义任务”，成长为“能独立理解、组织、执行和验证任务”。

AI 时代新人培养，还有一个很重要的变化：不能只依赖导师口口相传。

很多团队里，新人上手慢，并不是因为他不努力，而是因为大量关键知识都散落在老同学脑子里、历史代码里、群聊记录里、文档角落里。

比如，这个项目为什么这样分层？这个组件为什么不能随便改？这个接口有哪些历史兼容？这个页面有哪些业务例外？哪些问题以前踩过坑？哪些发布流程必须注意？

过去这些知识主要靠新人不断问人、翻代码、试错。现在，我们有机会把它们沉淀成更结构化的项目知识库。

这个知识库不只是给新人看的，也可以给 AI 消费。

它可以包括项目结构说明、核心业务链路、组件使用规范、接口约定、发布流程、常见问题 FAQ、历史典型需求、常见 Bug 排查路径。

当新人和 AI 都基于同一套知识工作时，新人的学习效率会提升，导师的重复答疑压力也会下降，团队经验也更容易沉淀。

这件事往后看，甚至可以进一步演化成 Agent 或 Skill 可以消费的项目知识包。

也就是说，新人培养不再只是“人带人”，而是“人、AI、知识库、真实任务”共同组成一套成长环境。

如果这篇文章是写给学生和应届生，我最想说的是：不要因为 AI 会写代码，就放弃基本功，也不要因为 AI 很强，就以为自己只要学会 Prompt 就够了。

你不必因为 AI 会写代码就否定自己，也不必急着把简历包装成“AI 工程师”。更重要的是，你要证明自己不是只能完成课堂项目，而是具备进入真实工程环境后持续成长的潜力。

你真正应该准备的，是几种更长期有效的能力。

第一，继续扎实写代码，也要训练自己读代码。很多真实工作不是从零写一个项目，而是在一个已有系统里理解、修改和维护。

第二，训练自己把模糊问题讲清楚。做项目时不要只说“我实现了一个功能”，而要能说明需求是什么，边界是什么，为什么这样设计。

第三，尽早使用 AI，但不要盲信 AI。你可以让 AI 帮你解释代码、生成方案、补测试、查问题，但最后要自己判断。

第四，每次做项目都要说清楚你怎么验证。很多学生简历里写了功能，但很少讲怎么确认它是对的。AI 时代，验证会变成很重要的差异点。

第五，练习复盘。不要只展示成功结果，也要讲清楚中间遇到什么问题，走过什么弯路，最后如何修正。

这些能力听起来没有“精通某某 AI 工具”那么亮眼，但它们更接近企业真正想要的人。

AI 会不会让校招生更难？

某种程度上会。因为一部分过去由新人承担的低复杂度编码任务，会被 AI 压缩。企业对新人的期待，也会变得更高。

但这不等于新人没有机会。相反，AI 也会让一部分新人更快成长。

过去一个新人可能要花很长时间才能读懂复杂项目，现在他可以借助 AI 更快理解代码结构。

过去一个新人可能不敢碰陌生模块，现在他可以让 AI 帮他梳理调用链和历史实现。

过去一个新人可能很难独立完成完整需求，现在他可以在 Mentor 的把关下，借助 AI 更快跑完理解、实现、验证的闭环。

区别在于，他不能把 AI 当成替自己负责的人。

未来值得培养的新人，不是“会用 AI 写代码的人”，而是“能借助 AI 更快成长，并对结果进行判断、验证和闭环的人”。

企业也不是不需要新人，而是会更快看出：谁只是在复制 AI 的输出；谁真正具备工程判断；谁能把 AI 变成自己的能力放大器；谁能在真实工程环境中可靠交付。

所以，AI 会写代码之后，企业还需要什么样的新人？

我的答案是：需要基本功扎实、学习斜率高、能理解问题、对 AI 开放但不迷信 AI、有验证意识、能复盘，也能完成交付闭环的人。

换句话说，企业需要的不是 AI 时代的代码搬运工，而是下一代能够驾驭 AI 的工程师。