TL;DR: AI 正在降低简历、代码和项目原型的制作成本，但招聘真正需要的不是更多材料，而是更可靠的能力判断。简历可以被优化，Demo 可以被快速拼装，自动筛选也可以处理海量申请；然而，这些变化并没有消除求职者与企业之间的信息不对称，反而可能让双方更难识别真实能力。与其继续堆叠材料和过滤规则，不如把注意力放到工程决策、问题排查、长期项目演进以及真实业务反馈上。
一、当求职和招聘都开始自动化
如果你最近关注技术招聘，可能会发现一个有些矛盾的现象：求职者能够更快地完成简历、项目介绍和技术面试准备，企业也能更快地处理大量申请。但这并不意味着找到合适的人变得容易了。
问题在于，双方节省下来的时间，并没有全部转化为更高的匹配效率。
过去，针对一个具体岗位修改简历，需要花时间理解职位要求，再从自己的项目经历中挑选合适的内容。如今，求职者可以把岗位描述交给大模型，让它提取关键词、调整项目表述，甚至重新组织整份简历。配合自动化脚本，批量搜索和投递岗位也不再困难。
这些工具确实有价值。它们降低了求职过程中的重复劳动，让一些不擅长写作、但具备实际技术能力的人，更容易把自己的经历表达清楚。
问题出在另一面：当每个人都能低成本地生成一份看起来高度匹配的简历时，这份简历还能提供多少额外信息？
一份简历写得专业，可能说明候选人有不错的表达能力，也可能只是说明他善于使用工具。项目介绍写得完整，可能来自真实的工程经验，也可能来自对公开资料的整理和重新包装。
招聘方看到的材料越来越完整，却未必因此更了解候选人。
企业面对的情况也类似。ATS、关键词匹配和大模型筛选，可以帮助招聘人员处理大量申请，减少重复劳动。但这些系统通常依赖简历中可提取的信息。当大量简历都经过针对性优化，原本用于区分候选人的关键词就可能失去区分度。
于是，双方进入了一个循环：
- 求职者发现普通简历难以获得关注，于是更加精细地优化材料。
- 企业发现申请数量增加、简历越来越相似，于是加强自动筛选。
- 筛选规则逐渐成为求职者优化材料的目标。
- 求职者继续调整表达，以适应新的规则。
每一方都在试图提高效率，但双方的行动叠加起来，不一定会让招聘更有效率。
这里真正发生的变化，不是所有流程的成本都归零了，而是制造信息和处理信息变得更便宜，验证信息却没有同步变便宜。
这也是理解 AI 时代招聘困境的一个更合适的起点。
二、为什么招聘市场会出现“柠檬问题”
经济学中有一个经典概念：柠檬市场（Lemon Market）。
它讨论的是一种信息不对称的交易环境：买方很难判断商品的真实质量，因此不愿意为无法验证的质量支付更高价格。优质商品的卖方如果觉得自己的商品被低估，就可能退出市场。随着优质供给减少，买方的判断会变得更加困难，市场质量也可能进一步下降。
技术招聘与这个模型有相似之处。
企业购买的不是一份简历，而是候选人未来解决问题、承担责任和交付结果的能力。但在招聘阶段，这些能力很难被直接观察。企业只能通过简历、学历、工作经历、代码仓库、技术面试等间接信号进行判断。
这些信号一直都不完美。AI 的变化在于，它进一步降低了其中一些信号的生产成本。
1. 简历越来越像，但候选人的能力并没有因此趋同
假设一家企业招聘一名有工作流引擎经验的工程师。
过去，候选人可能会写自己参与过任务调度、状态管理或异常恢复。企业需要从这些描述中推断，他到底负责了什么、理解到了什么程度。
现在，候选人可以让模型根据职位要求，重新组织项目经历，突出并发控制、故障恢复、系统可靠性等关键词。
这样的简历不一定是假的。它也可能让真实经历表达得更准确。
但对招聘方来说，问题仍然存在：两个候选人的简历都写着“设计了可靠的任务调度机制”，他们实际承担的工作可能完全不同。一个人可能负责了核心架构设计，另一个人可能只修改过几个配置参数。
如果简历上的表述越来越容易趋同，企业就不能再把表述的完整程度当成能力强弱的可靠依据。
2. 当筛选成本有限时，企业会更依赖容易执行的规则
招聘人员的时间有限。一份岗位收到大量申请时，企业不可能逐一深入分析每个人的技术经历。
因此，企业倾向于使用容易执行的筛选条件：学历、工作年限、公司背景、技术关键词，以及是否具备某些明确的项目经验。
这些条件并非毫无价值。在一些岗位上，相关经验和基础要求确实能够帮助缩小范围。
问题在于，当这些指标被当成能力的替代品，而不是初步判断的依据时，筛选就容易走向机械化。
例如，一个真正理解分布式系统、但没有知名公司经历的工程师，可能在初筛阶段就被排除；另一个擅长整理项目经历、熟悉面试套路的人，却可能因为材料更符合预期而获得机会。
这不是说学历和履历没有参考价值，而是说它们只能解释能力的一部分。
当企业过度依赖这些容易量化的指标时，筛选过程可能同时产生两种损失：漏掉有能力的人，也让部分不具备相应能力的人进入后续环节。
3. 优质候选人可能逐渐减少对公开投递的依赖
如果公开投递长期无法提供合理的反馈，求职者就会调整自己的策略。
有人转向熟人内推，有人通过开源社区和技术交流建立联系，也有人直接寻找业务负责人，展示自己解决具体问题的能力。
这些方式并不天然优于公开招聘，但它们提供了简历之外的补充信息：推荐人的判断、长期交流中的表现，以及候选人是否真正理解自己做过的项目。
对企业来说，这些信息有时比一份经过反复润色的简历更有帮助。
由此，招聘可能出现一种倾向：公开渠道继续承担大量申请的入口功能，而更有把握的候选人识别，越来越依赖定向寻访、内部推荐和已有的专业关系。
这与柠檬市场模型有相似之处，但不能简单地说整个招聘市场已经变成了柠檬市场。不同岗位、不同企业和不同招聘渠道的情况并不相同。
更准确的说法是：当企业难以区分候选人的真实能力时，招聘就更容易依赖那些成本较低、但未必能准确反映能力的指标。
AI 让这个问题变得更加突出。
三、开源项目也不再是充分的能力证明
当简历的可信度受到质疑时，一个很自然的想法是：少看简历，多看代码。
对于技术岗位，这个方向有道理。
代码仓库能够展示一个人写过什么、解决过什么问题，也可以让其他开发者检查实现方式。相比只有几行描述的项目经历，公开代码至少提供了更多可以核对的材料。
但代码仓库并不能直接等同于开发者的能力。
原因并不复杂：项目的制作成本正在下降，而一个项目的完成程度、作者的实际贡献和作者对系统的理解，本来就是三件不同的事。
1. 能运行的项目，不一定意味着理解系统
借助大模型和现成框架，开发者可以在很短的时间内搭建一个功能完整的原型。
一个带有登录、数据展示、模型调用和基础管理功能的应用，可能只需要少量人工编排，就能在演示环境中运行。
这对原型验证和产品开发是好事。没有必要为了证明一个想法可行，就把大量时间花在重复的基础工作上。
但如果招聘方试图通过这个项目判断候选人的工程能力，就需要继续追问：
- 项目为什么采用当前的架构？
- 哪些部分是候选人独立完成的，哪些部分来自现成框架或生成工具？
- 如果流量、数据规模或业务约束发生变化，当前设计会遇到什么问题？
- 系统出现故障时，候选人知道从哪里开始排查吗？
- 如果重新设计一次，哪些决策会保留，哪些会调整？
项目能够运行，只能证明某条执行路径可以工作。它不能单独证明作者理解系统的边界，也不能证明作者能够在条件变化时继续维护它。
2. 提交记录同样需要结合上下文判断
公开仓库还提供了另一类信号：提交历史。
一个持续演进的项目，往往能够留下需求变化、缺陷修复、接口调整和设计重构的痕迹。与只展示最终结果相比，这些记录更有机会说明项目是如何形成的。
但提交数量、提交频率和提交热力图，本身也不是可靠的能力指标。
提交可以被拆分、合并或自动生成。项目可以从现有仓库复制，再经过修改后重新发布。一个人也可能参与了大量提交，却没有负责核心设计。
因此，不能因为某个仓库有连续的提交记录，就认定它代表真实而深入的工程实践。
真正值得关注的是提交之间的关系。
为什么需要这次修改？它解决了什么问题？修改前后的行为有什么区别？有没有测试覆盖？新方案引入了哪些代价？后续是否又因为新的问题调整过设计？
如果候选人能够解释这些变化，并且代码、讨论记录和实际行为能够相互印证，那么项目就提供了比最终截图更有价值的证据。
反过来，如果候选人只能介绍功能，却无法解释关键实现，仓库再漂亮，也很难说明他对系统有足够深入的理解。
3. 公开影响力不能直接换算成工程能力
Star 数、下载量、用户数量和社区讨论，能够说明一个项目获得了怎样的关注。
但这些指标受到很多因素影响：项目发布的时间、宣传渠道、产品定位、作者已有的影响力，以及项目是否恰好满足了某个热门需求。
一个实用的小工具可能只有少量用户，却经过了细致的错误处理和长期维护。另一个项目可能获得大量关注，但核心功能仍然依赖外部服务，或者只适用于演示场景。
这不意味着公开影响力没有价值，而是应该先明确：它究竟证明了什么。
用户反馈可以证明项目解决了一部分真实需求；持续维护可以说明作者愿意承担长期责任；代码和设计讨论可以帮助判断技术深度。这些证据各有侧重，不能被简单地压缩成一个数字。
所以，开源项目依然值得看，只是不能再把“有项目”“有提交”或“有影响力”当成结论。
代码仓库应该是进一步验证能力的入口，而不是能力本身的证明。
四、比最终成果更有价值的，是工程决策的来龙去脉
如果简历和项目都可能经过工具包装，技术招聘应该看什么？
我的看法是：除了最终产出，还应该关注工程决策是如何形成的，以及开发者如何处理那些没有标准答案的问题。
这并不是因为工程过程天然无法伪造，而是因为理解一个复杂系统的形成过程，通常需要比复述项目介绍更多的知识。
对于涉及状态管理、任务调度、异常恢复和外部服务集成的系统，尤其如此。
1. 从功能演示转向问题与约束
以工作流引擎为例。
一个简单的 Demo 可能展示多个节点如何连接、任务如何执行，以及执行结果如何显示。这足以说明产品的基本交互和执行路径是可行的。
但当流程数量增加、任务开始并发执行，或者节点依赖外部服务时，问题就不再只是界面能否运行。
例如：
- 流程图中的节点越来越多，画布渲染和交互是否会受到影响？
- 节点执行失败后，重试会不会重复产生副作用？
- 两个任务同时修改同一份状态时，系统如何处理冲突？
- 流程中断后恢复执行，如何确定哪些节点已经完成，哪些节点需要重新执行？
- 用户修改流程定义后，正在运行的任务应该使用旧版本还是新版本？
- 如果外部服务已经完成操作，但本地还没有记录结果，系统如何避免重复执行？
这些问题没有一个适用于所有系统的统一答案。
例如，重试可以提高任务完成的概率，但如果外部操作不具备幂等性，重试也可能造成重复扣款、重复发送消息或重复创建资源。
把所有执行状态都写入数据库，可能让恢复机制更容易理解，却也会增加存储和协调开销。缓存可以降低读取成本，但又会引入失效和一致性问题。
真正的工程工作，就是在具体约束下决定哪些问题必须解决、哪些代价可以接受，以及如何让这些决定在系统运行中得到验证。
2. DAG 状态机的问题，不止是把节点连接起来
DAG，即有向无环图，常用于描述任务之间的依赖关系。它能够帮助系统判断任务的执行顺序，但一个可视化的 DAG 并不自动构成可靠的工作流引擎。
在实际设计中，至少需要区分三个层面：
图结构。 节点和边定义了任务依赖关系。系统需要识别非法依赖，并在执行前验证图结构是否满足要求。
执行调度。 即使图结构合法，任务也可能因为资源限制、外部服务延迟或并发冲突而无法按预期完成。调度器需要决定哪些任务可以启动、何时重试，以及如何处理失败。
状态持久化与恢复。 任务执行到一半时，进程可能退出，机器可能重启，外部服务也可能返回不确定的结果。系统必须明确哪些状态已经可靠保存，以及恢复时如何继续执行。
这三个层面相互影响，却不能混为一谈。
例如，拓扑排序可以帮助确定合法的执行顺序，但它并不能解决所有运行时问题。即使静态图没有环，任务之间通过外部资源、回调或动态生成的依赖关系，仍然可能形成复杂的等待关系。
同样，保存了节点状态也不代表恢复机制一定正确。系统还需要考虑状态写入与外部操作之间的时序，以及恢复时重复执行的风险。
如果候选人曾经设计或维护过这样的系统，那么比起让他复述 DAG 的定义，更有价值的问题是：他如何区分图结构错误、调度问题和状态恢复问题？为什么选择当前的状态模型？发生不确定的失败时，系统的行为是什么？
这些问题能够帮助面试官了解候选人的思考过程，也让候选人有机会说明自己的真实贡献。
3. 性能问题和异常处理更能体现设计取舍
以流程画布为例，随着节点和边的数量增加，渲染、布局计算和交互更新都可能成为性能瓶颈。
一种方案是减少不必要的重渲染，另一种方案是对大量节点进行分层展示或虚拟化处理。不同方案的实现成本、交互体验和维护复杂度并不相同。
又比如，断点续跑需要保存执行状态。状态记录得太少，系统可能无法判断任务中断前究竟完成了什么；记录得太细，则可能增加存储成本、写入压力和状态迁移的复杂度。
这些都不是靠一个漂亮的架构图就能回答的问题。
在技术面试中，可以让候选人描述一个自己真正处理过的问题：
- 当时的系统是什么状态？
- 最初的方案为什么不够用？
- 如何定位问题，而不是直接猜测原因？
- 考虑过哪些替代方案？
- 最终选择的方案解决了什么，又留下了什么限制？
这里不必要求候选人把每个细节都记得一清二楚。真实项目可能跨越很长时间，很多实现也会随着业务变化而被替换。
更值得观察的是，他能否区分事实、推断和记忆；能否解释设计决策背后的约束；以及当发现原来的判断不再成立时，是否愿意修正自己的方案。
这些能力比背出某种架构模式的定义更接近实际工程工作。
五、如何更合理地评估 AI 时代的工程师
如果企业继续只依赖简历关键词，或者反过来只看 GitHub 仓库，都很难完整判断候选人的能力。
更可行的方式，是组合几类成本适当、相互补充的证据。
1. 先用简历缩小范围，不要用简历代替判断
简历仍然有用。它可以帮助招聘方了解候选人的工作经历、技术方向和项目范围。
但简历筛选应该优先确认必要条件，而不是试图从措辞中推断所有能力。
如果岗位真正需要的是分布式任务调度经验，就应该尽量明确需要处理的实际问题，而不是无限增加技术关键词。候选人没有使用过某个特定工具，不一定意味着他不理解背后的原理；候选人写出了所有关键词，也不意味着他具备相应的实践能力。
对自动筛选系统来说，同样应该明确它的用途和局限。它适合协助整理信息、发现明显的条件不匹配，却不应该在缺少验证的情况下，被当成判断复杂工程能力的最终依据。
2. 让候选人解释自己做过的事情
在进入技术面试后，可以选择候选人参与过的一个具体项目，围绕真实的设计决策展开讨论。
不要只问“你用了什么技术”，还要问“为什么这样做”。
例如，候选人说自己实现了任务重试机制，面试官可以继续问：重试间隔如何决定？哪些错误可以重试？如何处理重复执行？如果外部请求超时，但服务端其实已经完成操作，系统应该怎么处理？
问题不需要刻意刁钻，也不必覆盖所有技术细节。重点是从候选人的实际工作出发，逐步了解他是否理解实现的边界。
对于借助 AI 完成项目的候选人，也没有必要把使用 AI 本身当成负面因素。更值得关注的是，他能否验证生成的实现，能否发现其中的问题，以及是否清楚自己交付的系统在什么条件下成立。
3. 设计与真实工作接近的现场任务
现场工程任务可以提供另一类证据，但前提是任务设计合理。
与其让候选人在限定时间内从零写出一个完整项目，不如给出一段有明确问题的代码、一份存在缺陷的设计，或者一个规模适当的故障场景。
例如，可以提供一个简单的工作流调度器，要求候选人分析任务失败后的重试行为，并讨论如何避免重复执行。也可以给出一段状态恢复逻辑，让候选人指出可能的数据一致性问题。
这类任务更接近实际工程中的阅读、分析和修改工作，也能减少对纯粹编码速度的依赖。
当然，现场表现同样不是完美的判断依据。候选人可能受到时间压力、陌生环境或题目背景不清晰的影响。面试官也可能因为个人偏好，对某种解法产生不必要的倾向。
因此，任务应当有明确的评价标准，关注问题分析、技术取舍和验证方法，而不是只看最终答案是否与预期完全一致。
4. 把长期记录作为补充证据
如果候选人有公开项目，可以进一步查看提交历史、Issue、代码评审和版本演进。
但不应该要求所有工程师都必须拥有高星项目或活跃的开源账号。许多有价值的工程工作发生在企业内部，受保密协议和业务权限限制，并不适合公开展示。
对于无法公开的项目，候选人可以在不泄露敏感信息的前提下，介绍系统面临的约束、自己的职责、遇到的问题以及最终做出的取舍。
长期记录的价值在于提供上下文，而不是制造新的门槛。
一个持续演进的开源项目，可能比一次性的 Demo 提供更多信息；但一个认真维护内部系统、能够清楚解释设计决策的工程师，也不应该因为缺少公开仓库而被低估。
5. 通过多种证据交叉验证，而不是寻找单一的“完美信号”
没有任何一种材料能够独立证明一个人的全部能力。
简历能提供经历线索，代码能够展示实现，提交历史能够补充演进过程，现场任务可以观察即时分析能力，工作讨论则能够揭示候选人如何理解业务约束。
这些证据之间如果相互吻合，判断就会更有把握。如果它们之间存在明显矛盾，也值得进一步了解原因，而不是立即得出结论。
这种方式可能比纯自动化筛选花费更多时间，但它不需要对每位候选人进行同等深度的审查。企业可以先用低成本方式筛选基本条件，再对进入后续环节的人进行更有针对性的验证。
对求职者来说，策略也不应该只是继续优化简历、增加项目数量或追求提交记录的连续性。
更值得投入的，是做一些自己真正理解、能够解释设计选择、并愿意持续维护的工作。项目不一定要大，也不一定要获得大量关注。重要的是，当别人询问它为什么这样设计、遇到过什么问题、哪些地方还不够好时，你能够给出具体而诚实的回答。
结语：AI 降低了生产成本，但没有消除判断成本
AI 让简历更容易写，让代码更容易生成，也让原型开发变得更快。这些变化本身没有问题。
真正需要调整的是我们对这些产物的理解。
一份简历不应该因为写得漂亮就被视为能力证明；一个代码仓库不应该因为功能齐全就被视为工程经验的证明；一段连续的提交历史，也不应该因为看起来真实就自动获得更高的信用。
同样，企业部署了自动筛选系统，也不代表它已经解决了人才识别问题。
在信息生产越来越便宜的环境里，招聘双方更需要明确自己究竟在验证什么。企业需要从候选人的经历和作品中寻找可核实的证据，而不是把容易量化的指标当成能力本身。求职者则需要能够说明自己做过什么、为什么这样做，以及自己如何处理那些没有标准答案的问题。
这并不意味着简历、代码和自动化工具会失去价值。它们依然是有效的工作工具，也依然能够提供有用的信息。只是它们的价值，需要放回具体的上下文中理解。
当越来越多的成果可以被快速生成时，真正重要的不是成果看起来有多完整，而是我们能否判断它解决了什么问题、在什么条件下成立，以及谁真正理解并承担了它的后果。
关于作者
郭强（GuoBug），Product Engineer，关注平台工程与业务增长。目前主要研究 AI 工作流编排、DAG 状态机与确定性系统架构。
开源项目与主页：https://github.com/GuoBug · https://guobug.github.io
欢迎交流工作流引擎架构、拓扑调度与低门槛开发体验。