面试官问"AI能写80%代码了，公司为什么还需要你？"——我把这个问题拆成了三层信号

面试官问"AI能写80%代码了，公司为什么还需要你？"------我把这个问题拆成了三层信号

热榜话题：面试官问你："AI 能写 80% 的代码了，公司为什么还需要你？"（491 阅读）

引言：这不是一道面试题，是一道信号题

金九银十的面试季，这个问题被问到的频率高得离谱。第一次听到时，我的反应和大多数人一样------先愣住，然后试图用"AI 写的不安全""AI 不懂业务"之类的套话搪塞过去。

但面到第 5 家、第 10 家之后，我意识到这道题的真正考点根本不是"AI 有什么缺陷"。面试官想听的，是你有没有把 AI 当成一个信号系统来理解------它能输出什么信号、不能输出什么信号、以及当信号被污染时你怎么兜底。

这篇文章，我把这个问题拆成了三层信号，每一层都对应一个真实踩过的坑。

第一层：AI 输出的代码是"结果信号"，不是"过程信号"

AI 能给你一段能跑的代码，这是结果信号。但它不会告诉你：

这段代码在边界条件下会不会崩
它引用的第三方库有没有已知 CVE
它生成的正则表达式在面对恶意输入时会不会 ReDoS

结果信号可以被伪造，过程信号才能被审计。

去年我们团队接了一个需求：给后台管理系统加一个"导出 Excel"功能。AI 三秒生成了基于 xlsx 库的导出代码，本地跑通，测试通过，上线。

三天后，生产环境内存告警。排查后发现 AI 生成的代码把整个数据表一次性读进内存再写入 Excel，数据量一大直接 OOM。AI 没告诉你的是，xlsx 库的 writeFile 是同步阻塞的，大数据量应该用流式写入。

typescript 复制代码

// AI 生成的版本（结果信号：能跑，但埋雷）
import * as XLSX from 'xlsx';
function exportExcel(data: any[]) {
  const ws = XLSX.utils.json_to_sheet(data);  // 一次性全量加载
  const wb = XLSX.utils.book_new();
  XLSX.utils.book_append_sheet(wb, ws, 'Sheet1');
  XLSX.writeFile(wb, 'export.xlsx');           // 同步阻塞，大数据量 OOM
}

// 过程信号审计后的版本（流式写入，内存可控）
import { Workbook } from 'exceljs';
import { createWriteStream } from 'fs';

async function exportExcelStreaming(data: any[], filePath: string) {
  const workbook = new Workbook();
  const worksheet = workbook.addWorksheet('Sheet1');
  
  // 先写表头（过程信号： schema 约束）
  worksheet.columns = [
    { header: 'ID', key: 'id', width: 10 },
    { header: 'Name', key: 'name', width: 30 },
  ];
  
  // 流式逐行写入（过程信号：内存边界可控）
  for (const row of data) {
    worksheet.addRow(row);
  }
  
  await workbook.xlsx.write(createWriteStream(filePath));
}

面试官真正想问的是：当 AI 给你一个"看起来对"的结果时，你用什么机制验证它的过程是对的？

我的答案是三层验证：

静态审计：ESLint + TypeScript 严格模式 + 自定义规则（比如禁止同步文件操作）
动态边界：单元测试必须覆盖空数组、单条、万条、特殊字符四种边界
运行时监控：内存/CPU 基线告警，异常波动自动回滚

第二层：AI 的"上下文信号"是有衰减曲线的

很多人以为给 AI 丢一个 200 行的 prompt，它就能记住所有约束。事实是：AI 的注意力是衰减的，prompt 中间部分的约束最容易被忽略。

我们做过一个实验：在 prompt 的开头、中间、结尾分别插入三条等价的约束（"所有 API 返回必须包含 trace_id"）。让 AI 生成 10 个接口，统计约束遵守率：

约束位置	遵守率
prompt 开头	90%
prompt 中间	40%
prompt 结尾	85%

这个实验让我重新理解了"AI 能写 80% 代码"这句话------它写的 80% 可能是对的，但剩下的 20% 错误分布不是均匀的，而是集中在 prompt 中间被衰减掉的约束上。

所以我的做法是：把不可妥协的约束从 prompt 里抽出来，变成代码层面的强制检查。

typescript 复制代码

// 不是写在 prompt 里让 AI "尽量遵守"，而是写成运行时断言
function apiResponseGuard<T>(response: ApiResponse<T>): asserts response is ApiResponse<T> & { trace_id: string } {
  if (!response.trace_id || typeof response.trace_id !== 'string') {
    throw new ApiContractError('trace_id is required in all API responses');
  }
}

// 每个接口出口统一调用
app.use((req, res, next) => {
  const originalJson = res.json.bind(res);
  res.json = (body) => {
    apiResponseGuard(body);  // 运行时强制检查，AI 漏了直接抛错
    return originalJson(body);
  };
  next();
});

面试官想听的第二层信号是：你知道 AI 的注意力边界在哪里，并且你把关键约束下沉到了工具层，而不是依赖 AI 的记忆力。

第三层：AI 不会为你的"判断信号"负责

这是最容易被忽略的一层。AI 可以生成代码，但它不会为你的技术决策背锅。

举个例子：AI 建议你"用 Redis 做分布式锁"。它甚至能给你一段看起来没问题的 Redlock 实现。但它不会告诉你：

你们的 Redis 是单实例还是集群？
集群模式下 Redlock 的时钟漂移问题怎么解？
如果业务允许短暂的锁失效，是不是直接用数据库乐观锁更简单？

这些不是代码问题，是判断问题。判断需要上下文，而上下文只有你知道。

typescript 复制代码

// AI 给的 Redlock（结果信号：代码层面"正确"）
// 但它不会问你：你们的 Redis 是集群吗？时钟同步吗？

// 我的判断过程（信号提取）：
// 1. 业务场景：库存扣减，允许极少量超卖（信号：不需要强一致）
// 2. 基础设施：单实例 Redis，无集群（信号：Redlock 过度设计）
// 3. 团队能力：熟悉数据库，不熟悉 Redis 运维（信号：技术债风险）
// 4. 结论：用数据库乐观锁，代码多 5 行，心智负担少 80%

async function deductStock(productId: string, quantity: number) {
  const result = await db.product.updateMany({
    where: {
      id: productId,
      stock: { gte: quantity },  // 乐观锁：库存足够才扣
    },
    data: {
      stock: { decrement: quantity },
    },
  });
  
  if (result.count === 0) {
    throw new InsufficientStockError('库存不足或并发冲突');
  }
}

面试官的第三层信号是：当 AI 给出一个技术方案时，你能不能从业务上下文、基础设施、团队能力三个维度做判断，而不是无脑采纳？

总结：公司需要的不是"会写代码的人"，是"会验证信号的人"

回到最初的问题："AI 能写 80% 的代码了，公司为什么还需要你？"

我的答案现在变得很清晰：

AI 输出结果信号，我审计过程信号
AI 的注意力会衰减，我把关键约束下沉到工具层
AI 不给判断信号，我在业务上下文里做技术决策

这三层信号，构成了 AI 时代工程师的护城河。不是"我会写代码而 AI 不会"，而是我知道什么时候该信 AI、什么时候该质疑 AI、以及质疑的时候用什么工具和方法。

如果你也在准备面试，不妨把这个问题准备成三层信号的框架。不是为了背答案，而是为了让自己真的想清楚：在 AI 能写 80% 代码的世界里，你的 20% 价值到底锚定在哪里。

本文基于真实面试经历与技术实践整理，欢迎讨论。