招全栈工程师时，别只看年限：AI 编程工具正在拉开真实差距

招全栈工程师，最容易踩的坑，就是盯着“3 年经验”这几个字。

你会发现，候选人简历写得都挺像：

• React / Vue
• Node.js / Java / Python
• MySQL、Redis
• Docker、Nginx、Linux
• 做过后台、商城、管理系统

一聊实战，差距就冒出来了。

有人接到一个陌生仓库，半小时能跑起来、找到关键模块、列出改造方案；有人光是配环境就卡一上午。有人遇到报错，会带着上下文让 AI 协助定位；也有人还在复制报错信息，丢进搜索引擎里祈祷答案刚好对得上。

这不是“会不会用工具”这么简单。背后反映的是：这个人有没有现代化的问题解决能力。

一个扎心现象：很多全栈开发还没进入 AI 协作工作流

现在去筛全栈候选人，会看到一种很割裂的情况。

一部分人已经把 Claude Code、Codex、Cursor、GitHub Copilot 之类的工具放进日常开发流程：

• 用 AI 快速读陌生项目
• 让 AI 生成接口草稿和类型定义
• 补单元测试、边界测试
• 分析复杂 SQL 和慢查询
• 排查日志里的异常链路
• 做代码审查前的自检
• 把模糊需求拆成开发任务

另一部分人还停留在“AI 帮我补几行代码”的阶段，甚至完全不用。

更尴尬的是，有些人只会依赖某一个功能较浅的插件。工具给出的代码能跑就直接提交，没验证、没追问、没理解。这样的人不是在用 AI，是在把 bug 的生产速度调高。

真正成熟的开发者，会把 AI 当成一个反应极快、需要严格复核的初级搭档。

为什么 AI 工具使用情况，能看出工程师的水平？

因为全栈开发的难点，从来不只是“把页面和接口写出来”。

真正耗时间的场景，往往长这样：

产品说：这个订单页偶发白屏，用户量大时才出现。你今晚能查出来吗？

或者：

接手一个两年前的项目，文档没有，环境没人会配，明天要加一个支付渠道。

又或者：

一个接口平均 300ms，活动一来飙到 8 秒。老板只问一句：为什么？

这时候，背 API 文档没什么用。你需要的是一套排查和推进的方法。

会用 AI 编程工具的人，通常有几个明显特征：

1. 能把模糊问题说清楚

他不会只输入一句：

帮我修复这个 bug

而是会整理上下文：

这是一个 Node.js + Prisma 的订单服务。
问题：高并发下偶发重复扣库存。
已知现象：同一个 sku 在 2 秒内出现两条库存流水。
相关代码如下。
请分析可能的并发窗口，并给出数据库层和应用层两套修复方案。
要求：不能引入分布式锁，保留现有事务结构。

你看，重点不在提示词写得花不花。

重点是他知道该提供哪些信息，知道限制条件是什么，也知道答案要落在哪个工程层面。

2. 知道怎么验证 AI 的答案

AI 说“加个锁”很轻松。

问题是：锁加在哪里？锁粒度多大？失败后会不会死锁？多实例部署时还管用吗？事务回滚时怎么办？

靠谱的人会继续追问，会看源码，会补测试，会压测。

他不会把 AI 输出当结论，而是当作一个待验证的方案。

3. 把时间花在真正值钱的地方

手写一个普通 CRUD 页面，当然能证明你会写代码。

可一个有经验的工程师，没必要每天都把时间烧在重复劳动上。

AI 可以帮你起接口骨架、生成 DTO、补 Mock 数据、写测试初稿。你该盯住的，是业务边界、异常流程、性能瓶颈和可维护性。

说白了，能早点下班一小时的人，不一定是摸鱼高手，可能只是没在重复造轮子。

面试怎么问，才能筛出真会用的人？

别问：

你会不会用 Claude Code？

这种题没价值。对方说“会”，你也无法判断深浅。

换成场景题，效果立刻不一样。

场景一：接手陌生项目

你可以问：

给你一个前后端分离项目，缺少文档，启动还报错。你拿到仓库后的前 60 分钟会做什么？AI 工具会在哪些环节介入？

靠谱回答通常会提到：

• 先看 README、环境变量、Docker 配置、依赖版本
• 跑起前端和后端，记录完整错误信息
• 查看目录结构、路由入口、数据库模型、核心业务模块
• 让 AI 梳理模块关系，但会自己核对关键链路
• 先明确“项目能跑”的最低目标，再处理功能问题
• 输出一份风险清单，而不是闷头改代码

如果对方回答是“丢给 AI 分析一下”，基本就到头了。

场景二：线上故障排查

可以继续问：

某个接口偶发 500，日志里只有 Cannot read properties of undefined。你会如何让 AI 帮忙，又如何避免它瞎猜？

期待听到这些动作：

• 提供脱敏后的堆栈、相关代码、请求参数样本
• 补充发生频率、用户行为、部署版本、时间范围
• 要求 AI 列出假设，并按证据强弱排序
• 为每个假设设计验证手段
• 加日志、复现请求、检查空值分支和异步时序
• 修复后补回归测试，避免下次再炸

能讲到这里，说明他不是“会问 AI”，而是会做工程排障。

场景三：让候选人现场审 AI 代码

这个特别好用。

提前准备一段看起来没问题、实际藏着坑的 AI 生成代码，例如库存扣减：

async function reduceStock(skuId: string, count: number) {
  const product = await db.product.findUnique({ where: { skuId } });

  if (product.stock < count) {
    throw new Error('库存不足');
  }

  await db.product.update({
    where: { skuId },
    data: { stock: product.stock - count }
  });
}

问他：这段代码能上生产吗？

有经验的人会很快指出：

• 查询库存和扣减库存不是原子操作
• 并发请求会超卖
• product 可能为空
• count 缺少合法性校验
• 错误类型和日志策略不清楚
• 应该考虑条件更新、事务或乐观锁

这比让他手写算法题真实多了。

面试评分表：别把“用了什么工具”当唯一标准

工具会更新，方法论才更耐用。

可以用下面这张简单评分表做参考：

| 观察项 | 较弱表现 | 较强表现 | | --- | --- | --- | | AI 使用方式 | 只让 AI 补代码 | 用 AI 拆问题、读仓库、写测试、做排查 | | 上下文能力 | 问题描述模糊 | 能给出代码、日志、约束和预期结果 | | 代码判断力 | AI 写什么就信什么 | 主动审查边界、并发、安全、性能问题 | | 工程意识 | 只关注功能跑通 | 关注测试、监控、回滚、兼容和维护成本 | | 学习能力 | 死守熟悉工具 | 能快速迁移到新工具和新工作流 |

这里有个底线：不会某个具体产品，不该直接淘汰。

有人因为网络、公司合规、数据安全要求，确实用不了某些海外服务。问题不在于他有没有某个账号，而在于他是否理解 AI 辅助开发的基本方法，能不能在可用工具里建立有效工作流。

只会喊“这个不能用，所以我不用 AI”，那就有点可惜了。工具受限可以理解，思路停摆不行。

给全栈开发者的实战工作流

如果你也想把 AI 编程工具真正用起来，别一上来就让它“帮我做完整项目”。十有八九会收获一坨包装精美的技术债。

照这个流程练，比较稳。

需求到任务拆分

把产品需求贴进去前，先自己补齐这几件事：

• 用户是谁
• 触发条件是什么
• 正常流程怎么走
• 失败时怎么处理
• 哪些数据需要落库
• 哪些字段涉及权限或隐私

再让 AI 输出任务拆分和风险点。

代码前先让 AI 找盲区

比如你准备做“优惠券核销”，可以问：

请列出优惠券核销接口常见的边界条件。
场景包括：重复提交、过期券、并发核销、用户身份校验、订单取消后的补偿。
按严重程度排序，并给出测试用例建议。

这一步很值钱。很多线上事故，根本不是代码写错，而是开发时压根没想到那个场景。

编码时让 AI 做重复活

适合交给 AI 的活包括：

• 创建基础接口和类型定义
• 写表单校验规则
• 生成单元测试初稿
• 补 API 文档
• 写迁移脚本草稿
• 把重复逻辑抽成工具函数

涉及支付、权限、删除数据、库存、金额计算时，必须自己主导。别把公司账本交给一个会一本正经胡说八道的助手。

提交前做一次“反向审查”

把改动丢给 AI，明确要求它挑刺：

请以资深代码审查者的视角检查这次改动。
重点检查：空值、并发、权限绕过、SQL 注入、事务边界、错误处理、性能退化和向后兼容。
不要夸代码，只列出风险和修改建议。

注意，“不要夸代码”这句很有用。很多工具默认太客气，像个只会鼓掌的实习生。

常见坑：AI 用得越勤，越要防这几件事 ⚠️

把敏感信息直接贴进去

生产数据库连接串、用户手机号、身份证、密钥、内部业务数据，都别直接扔给外部模型。

该脱敏就脱敏。该走企业版和私有部署，就别为了省几分钟给自己埋雷。

一次性让 AI 改半个仓库

改动范围越大，越难审。

更稳的方式是：一次只处理一个模块、一个函数或一组明确测试。每一步都能运行、能对比、能回滚。

把“能运行”误判成“没问题”

能运行只是及格线。

权限有没有漏洞？并发会不会出事？异常会不会吞掉？数据库会不会被慢查询拖垮？这些才是生产环境真正会打人的地方。

迷信某一个工具

Claude Code、Codex、Cursor、Copilot，甚至本地模型，各有适合的场景。

别把“我只用某某”当成技术立场。开发是解决问题，不是给工具站队。

招聘真正该找的人

一个值得招的全栈工程师，不需要把每个 AI 工具玩出花。

你要找的是这样的人：

• 遇到陌生问题不慌，能快速建立排查路径
• 知道 AI 能做什么，也知道它会在哪儿翻车
• 能把复杂任务拆小，一步步推进
• 会验证，会留痕，会补测试
• 不拿工具当借口，也不把工具当神仙

技术栈会变，编辑器会变，模型名字更是几个月就换一茬。

但一个人是否愿意更新自己的工作方式，很难伪装。

面试时多给真实场景，少背八股。你筛出来的，才更可能是那个能在项目快崩时把事情接住的人。