招人别再迷信编程题：AI 时代该验什么真本事

这半年我帮几家企业做内训和业务咨询，听过最多的一句苦水就是：人招进来了，履历光鲜，做题很快，但真给个业务问题，就容易卡壳。

不少团队主管提到，过去招人按传统流程走，考算法、白板写二叉树、闭卷写排序，候选人答得很顺，综合评分也高。结果入职第三周，业务线提了个具体需求，比如接某个冷门接口做个自动化归档脚本，或者搭个给运营应急用的内部看板，这人卡了五天，交上来的东西缺漏不少，连基本的异常报错都没考虑。更棘手的是，现在大家普遍使用 AI 辅助编程，有些新员工遇到报错，直接把控制台日志大段复制给大模型，模型给什么就贴什么，程序运行异常时找不出症结，难以推进业务落实。

面试刷题表现好，上手调动工具却不顺畅，交不出能跑、能验收的半成品。这种招聘落差不是个例，在不少技术与数字化团队中都有出现。

问题出在哪？出在我们这套招人题，已经跟当下干活的方式脱节了。

AI 时代招人，别再迷信标准化编程题。现在要验的真本事，主要就三条：能否准确发现并定义真实问题，能否给出清晰的验收标准，以及能否配合 AI 把想法做成可运行的原型并交付。

前段时间有媒体报道提到，大模型厂商 Anthropic 的工程团队在面试中取消了传统的标准编程题。相关团队成员解释过原因：这类题目在当前环境下能提供的有效评估信号正在变弱。

在过去，刷题好通常代表逻辑清晰、基础代码扎实、能投入时间突击。但在大模型大幅降低通用代码编写门槛的背景下，题目完成得工整，有时只表明候选人熟悉常见题型模板，或者针对套路做过专项练习。而这类解法，大模型通常很短时间内就能给出参考实现。

工具能够解题，并不等同于人可以独立处理复杂的实际工作。

实际业务场景中很少有预设好的函数入参、输出和限定复杂度。真实的业务现场通常伴随各种不确定性：需求可能只有一两句初步的想法，上游系统存在不规范的数据，第三方接口文档缺少细节，交付周期通常也比较紧张。在这种情况下，工程师或业务骨干的主要作用不是机械地编写常规语法，而是把模糊的需求理清，梳理结构，合理利用工具辅助推进，并对最终交付的结果负责。

因此，现在不少务实的团队开始转向看原型和过往作品。有人解释过，在基础代码生成门槛降低后，识别真实问题的判断力、对业务场景的理解，以及推动事项落地执行的能力，显得更为重要。

这一点不仅适用于技术岗位，在运营、产品、内容等日常涉及数据或流程交付的团队中同样适用。协同使用 AI 工具并不局限于开发人员。许多岗位在处理数据、梳理工作流程、交付具体成果时，面临类似的要求：能否给工具明确的执行要求，能否严格把关最终的交付质量。

会写代码不稀奇了，稀奇的是会定义任务。怎样才算把任务定义清楚？Google 在官方的提示词策略指南中提到过一些基本原则：任务应当具体，带有清晰的约束条件、输出边界和可验证的目标。你在公司指挥 AI 也好，指挥实习生也好，逻辑一样。自己要什么结果、什么叫合格都说不清，再强的模型也白搭。

为了把考核重点从解题转向实际交付，企业招聘时可以参考这份“三验清单”：

第一，检验问题定义能力。 不直接提供现成的题目框架，而是给出一个具体的业务情境。例如：“客服部门反馈每天有 300 条用户退换货投诉需要人工分类填表，耗费两人半天时间；这是接口文档，这是 20 条样本数据，请问你会如何设计解决方案？” 观察候选人是直接动手写脚本，还是先确认核心前提：分类的准确率要求是多少？异常或缺失数据如何处理？后续是否需要人工复核环节？能主动确认这些问题，通常说明其关注实际应用场景中的完整链条，而非单纯局限于代码实现本身。

第二，检验可运行的原型交付能力。 允许候选人借助 AI 工具，在 60 到 90 分钟内完成一个最小可行原型（MVP），不苛求代码格式处处完美，重点看原型是否可用。 无论是一个简短的命令行程序，还是一个基础的交互界面，只要能输入测试数据、输出有效结果，并且主流程能够跑通，就说明候选人具备整合资源并把想法落实到程序上的工程能力。能够交付可用原型的人，入职后通常能较快协助团队处理具体任务；若过度纠结方案图样而迟迟无法运行，推进效率往往会受到影响。

第三，检验关键环节的审查与纠错能力。 可以给候选人一段由大模型生成的、看似规范但包含业务逻辑漏洞或安全问题的代码，由其进行代码审查；或者在其制作的原型中输入极端边界数据。 重点观察候选人能否发现潜在问题，能否说明模型输出产生偏差的原因，以及在实际生产环境中会设置哪些防范机制。使用工具仅是基础，能够发现工具输出中的漏洞并做好兜底核验，才是解决实际问题的核心所在。

这套考核思路，同样可以为求职者和内容创作者准备个人展示材料提供参考。

在求职或寻找业务合作时，可以减少简历中“熟练掌握某种语法”或“完成若干习题”等相对泛化的表述，改为展示三到五个实际完成的项目或工具作品。 这些作品不必规模庞大。例如自己借助工具编写的一个浏览器插件，用于解决特定网页批量导出数据的重复工作；或者一个结合在线表格与 API 搭建的周报自动汇总流程。在展示时，清晰陈述三项内容：

1. 最初遇到了什么具体的业务或操作问题；
2. 怎样拆解处理步骤，并配合工具分阶段做出原型；
3. 过程中遇到了哪些报错或错误输出，采取了什么方法排查并保证运行结果稳定。 清晰呈现这几点，招聘负责人能够直观评估候选人的实际解决问题能力，往往比做对几道标准算法题更能体现岗位匹配度。

此外，企业在组织员工技能内训时，也可以适当调整培训重心。

不必花费过多精力让员工记诵固定、复杂的提问模板，诸如设定特定身份等表面形式，在具体业务开发中产生的实际作用相对有限。

企业内训更需要强化的是流程拆解与质量检验意识：如何把部门的大目标拆分成输入清晰、输出明确的具体小模块；如何为工具生成的方案设计测试边界；如何在业务流中建立质量把控防线。当交付与验收标准得到明确落实，工具才能真正成为提高日常效率的手段；若缺少清晰的验收机制，工具的使用反而容易引入未经验证的内容与低效代码。

招聘考核方式的演变，并非意味着基础代码不再重要，而是基础代码逐渐成为生产过程中的基础材料。真正把控设计要求、设定质检标准并对最终交付负责的人，在实际工作中始终具备更高的价值。

---

常见问题

Q1：完全取消编程题，会不会招进来基础特别差、连基本语法都不会的南郭先生？ 不会，因为“三验清单”里的要求其实比死记硬背语法更苛刻。让候选人当场操作、带工具跑通一个可运行的原型，并在关键环节挑错，这本身就需要扎实的代码阅读能力和系统感知力。只会纸上谈兵、完全不懂底层逻辑的人，根本驾驭不了大模型的输出，稍微遇到一点报错或者上下文缺失就会当场卡壳。

Q2：非技术岗（比如运营、市场、HR）在面试里怎么体现这种「人机协同」与验收能力？ 非技术岗同样可以用作品说话。比如在面试中展示你用大模型搭建的自动化舆情监控表，或者展示你如何把一个模糊的活动文案策划拆解为多轮结构化输出指令，并附带你人工修正、筛选、优化的对照记录。重点不是展示技术含量，而是展示你把控质量标准、用工具提效并交付可量化结果的能力。

Q3：小团队资源有限，没有时间安排 90 分钟现场做原型，怎么做低成本考察？ 可以采取“异步小任务”或直接“聊过往项目细节”。如果不想占用面试时间做题，可以让候选人提前提供一个公开的个人小项目地址，面试时花 20 分钟做深度复盘：让他屏幕共享演示一遍运行过程，并随机挑一段核心逻辑问他：“如果这里的数据量突然扩大十倍，你会怎么改这个脚本？当时为什么选这个方案？”能清晰复述权衡过程的，骗不了人。

相关课程AI赋能工匠创新：生成式AI实战与岗位效率倍增查看课程 →