程序员简历的金句，正在被 AI 一句话拆穿

昨天鸭鸭刷到一条让所有写代码的人都该警觉的新闻。

5 月 11 日，36kr 整理了一段 OpenAI Codex 产品负责人 Alexander Embiricos 的公开访谈。他没绕弯子，直接讲了 OpenAI 内部正在发生的事：

在 OpenAI 内部，许多工程师几乎不再打开传统 IDE，而是全天候运行 Codex。开会期间如果没有让 Codex 同步处理任务，反而会被认为是在浪费时间。

读到这里鸭鸭愣了一下，因为他后面还补了一句更狠的：

现在 OpenAI 内部，绝大多数代码都是由 AI 写出来的。

有人说这是行业风向标，OpenAI 怎么干，3 年内全行业就怎么干；有人说自家公司还在让员工背 LeetCode 题库，听完只想笑；也有人在追问一句关键的：那以后简历上还写什么。

但鸭鸭看完想说一个比裁员焦虑更扎人的事：

AI 时代真正稀缺的不是「会写代码」，是「能判断 AI 写的代码哪里有问题」。前者机器越来越便宜，后者越来越贵。OpenAI 内部不开 IDE，就是这两条曲线交叉那一刻的真实写照。

过去十年，程序员简历的金句长这样：精通 Java/Python/Go/C++/Rust 5 种语言，熟练掌握 Spring/MyBatis/Redis 框架，独立完成过 X 万行代码。这些话曾经能让 HR 一眼定位你的硬实力。

但放到 2026 年的 OpenAI 内部，画面变了。

工程师不再「写代码」，工程师在「指挥 AI 写代码 + 审查 AI 写的代码」。Alexander 的原话很直白：「他们的注意力，已经从实现细节，转移到任务拆解、计划评估和结果审查上。」

这背后有四笔账，多数程序员还没算过。

第一，速度账。AI 写代码比人快 10 到 50 倍。同样一个功能模块，工程师写 3 天，Codex 5 分钟交付能跑的版本。差距不在质量，在量级。

第二，一致性账。一个团队 10 个人手写代码，会出 10 种风格、10 种命名习惯、10 种异常处理偏好。10 个人指挥 Codex 写代码，输出会自然趋同。维护成本从「天」降到「分钟」。

第三，全栈账。Alexander 提到一个细节：Codex 团队内部，前端、后端、基础设施的分工正在迅速模糊。原因很简单——AI 跨语言能力够强了，人没必要再为「我是后端，我不写 Java 之外的语言」这种自我设限付出代价。

第四，审查账。这是最被低估的一笔。AI 写代码越快，错误率不会归零，反而会因为人审查不过来而堆积。所以 OpenAI 内部最值钱的能力，不是写代码，是 review。能看出 AI 在哪里偷工减料、哪里调用了错误的 API、哪里把性能藏在了用户看不见的地方。

四笔账加起来，OpenAI 不让工程师写代码不是「赶时髦」，是公司算过的最划算的人力配置：让 AI 干 AI 擅长的事，让人干 AI 干不了的事。

而国内大厂会不会跟？

鸭鸭判断：3 个月内全员推广是夸张，但 12 个月内一定会出现「AI 使用率」纳入晋升评估的公司。事实上微博、昆仑万维、字节、阿里这一年都在这条路上。OpenAI 只是把方向锚定得更激进一点。

那这事儿能怎么办？

鸭鸭说几句实在话。

• 简历别再堆「精通 N 种语言」：3 年前是优势，今天看着像在跟 AI 比速度。改成写「在 X 项目里用 AI 工具把 Y 周期压缩到 Z 天，独立 review 过多少行 AI 代码」，把价值挪到「指挥 + 审查」这一侧。
• 学会高效用 AI，不是会用：「会用 AI」在 2025 年是加分项，2026 年是入场券，2027 年只会是基本盘。真正拉开差距的是「能让 AI 一次产出可用代码」的 prompt 工程能力。
• 重点练 review 能力：你看着 AI 跑出来的 200 行代码，能不能 5 分钟看出哪里有 bug、哪里性能有问题、哪里把异常吃掉了。这个能力 AI 短期内替代不了，也是面试现场最该证明的硬实力。
• 做一个有完成度的项目：Alexander 在访谈里给学生的建议是「去构建高质量的东西。一个有思想、有完成度的项目，比任何标准化简历都更有说服力」。这条话送给所有正在求职的同学。

最后说一句鸭鸭看完这条访谈之后的判断：

「精通 N 种语言」这种简历金句，本质是工业化时代的劳动力定价方式。AI 时代的定价不看你掌握多少工具，看你能不能让一群 AI 帮你交付高质量结果。前者拼写得快，后者拼判得准。

下次面试官再问你「你简历上写精通几种语言」，可以淡淡接一句：「比起几种语言，我更想聊聊我让 AI 审查过多少行代码。」

定价权，从那一刻起就在你手上。

大家公司有把 AI 写代码占比写进绩效或晋升标准吗？看到这种政策你的第一反应是什么？评论区聊聊～

……

今天鸭鸭和大家分享一道 AI 大模型面试题。

【如何将已有的应用转换成 MCP 服务？ 】

回答重点

把现有应用转成 MCP 服务，核心就是把应用里的功能封装成标准化的 MCP 工具，再通过 MCP Server 暴露出去让大模型能调用。

整个转换流程分这几步：

1）梳理功能模块，把应用里需要暴露给外部的能力挑出来，比如 API 接口、数据查询、文件处理这些

2）创建独立的 MCP 服务，跟原有业务服务隔离开，通过 HTTP API 或者 SDK 跟业务服务通信

3）导入 MCP 依赖，Java 用 spring-ai-mcp，Python、TypeScript 等语言参考官方 SDK

4）定义工具描述，包括功能说明、入参字段及描述、返回值字段及描述，这些信息会被大模型用来理解什么时候该调用这个工具

5）实现 MCP Server，按照 MCP 协议规范构建服务端，负责接收 MCP 客户端请求、路由到对应功能模块、返回结果

扩展知识

为什么要用 MCP

传统 LLM 应用接入外部工具特别痛苦。每接一个新数据源或者新 API，就得写一套适配代码，模型调用逻辑、参数解析、错误处理全得自己搞。接个 10 个工具，代码里就是 10 套不同的集成逻辑，维护成本直线上升。

MCP 协议就是为了解决这个问题。它定义了一套标准化的通信规范，大模型通过统一的方式发现和调用外部能力，不管底层是数据库查询还是第三方 API，对模型来说接口都一样。

MCP 的三大核心概念

MCP 把外部能力抽象成三种类型：

1）Tools 是可执行的操作，比如发邮件、查数据库、调第三方 API。模型判断需要执行某个动作时会调用 Tool

2）Resources 是只读的数据源，比如配置文件、文档内容、数据库表结构。模型需要获取上下文信息时会读取 Resource

3）Prompts 是预定义的提示模板，比如代码审查模板、文档生成模板。让模型按照固定格式处理特定任务

实际开发中用得最多的是 Tools，因为大部分场景都是让模型触发某个操作。

实际案例

MCP 现在已经有不少落地应用了。Claude Desktop 通过 MCP 实现了本地文件系统的读写，高德地图用 MCP 提供位置查询和路线规划，支付宝通过 MCP 暴露收单支付能力。

Spring AI 生态里有个 MCP Marketplace，里面已经有几十个现成的 MCP Server 可以直接用，覆盖了文件操作、数据库访问、搜索引擎这些常见场景。

安全性考量

MCP 在设计上就考虑了安全问题。实际的工具调用全部封装在 MCP Server 内部，大模型本身接触不到敏感数据和业务系统。这层隔离降低了直接暴露内部系统的风险，出问题也好排查，就在 MCP Server 这一层做审计和权限控制就行。

篇幅有限，更多 AI 大模型 相关面试题可以进入面试鸭进行查阅。