从“写代码”到“定义问题”：AI 时代开发者的新身份

一、一个正在悄悄发生的变化

前两天和一位做了十二年的后端老友吃饭，他苦笑着说了一句：“我现在一天敲的代码，还不如 Copilot 十分钟生成的多。”

这句话听着像玩笑，但背后是一个正在快速成型的现实：“写代码”这件事，正在从核心技能变成基础动作。

过去，我们评价一个程序员强不强，常常看三样：

1. 能不能快速把需求翻译成代码
2. 能不能写出“优雅又高效”的实现
3. 能不能靠经验少踩坑

而现在，第三点还在，前两点正在被 AI 一点点接管。

于是问题来了：当“写代码”不再是稀缺能力，开发者的价值到底在哪里？

二、AI 把“实现”卷到底，却卷不动“定义问题”

很多人担心：AI 会不会把程序员干掉？

我更愿意换个说法：AI 把“怎么实现”这件事卷到了地板价。

你只要能把需求说清楚：

• “帮我写一个接口，接收 JSON，做校验，落库，返回统一结构”
• “把这个 SQL 改成支持分库分表版本”
• “按这个接口文档，补一套前端调用代码”

AI 基本都能给你一版“能跑的代码”。

但真正卡住人的，往往不是“怎么实现”，而是：

• 这个需求本身是不是合理的？
• 这个字段为什么要这么设计？
• 这个流程里有哪些隐藏的边界情况？
• 这个“看起来简单的功能”，背后涉及多少系统、多少依赖？

AI 能帮你把路铺平，但它不会替你选方向。​

方向怎么选？问题怎么定义？

这才是 AI 时代，开发者真正值钱的地方。

三、从“码农”到“问题设计师”：角色在悄悄换挡

可以把现在的变化简单类比一下：

• 过去：你是“翻译官”
  把产品同学那句“做个类似微信的聊天功能”，一句一句翻译成代码。
• 现在：你更像是“问题设计师”
  你要先和产品、用户一起把那句话拆成：
  • 单聊还是群聊？
  • 消息要不要已读？
  • 离线消息怎么存？
  • 历史记录保留多久？

然后再让 AI 去帮你“写初稿”，你来做审稿、改稿、定稿。

在这个过程中，你的核心价值变成了三件事：

1. 把模糊的需求拆成清晰的问题​
   能写清楚：输入是什么、输出是什么、异常怎么办、性能底线在哪。
2. 对“系统整体”负责，而不是只对“自己那几行代码”负责​
   接口稳不稳？链路通不通？出问题能不能快速定位？
   这些是 AI 不会替你拍板的。
3. 敢对不合理的需求说“不”，并给出更优解​
   不是“你让我写我就写”，而是：
   “这个方案短期爽，长期是坑，我给你一个折中版本。”

四、一个很现实的小场景

假设产品同学丢过来一句：

“给我们加一个‘一键导出所有数据为 Excel’的功能。”

纯“写代码时代”的你可能马上开始查 POI / Excel 库，研究流式导出。​

AI 时代，你可能会先反问几个问题：

• 数据量大概多大？十万行还是一千万行？
• 要不要支持筛选条件？还是真的“所有数据”？
• 导出是同步下载，还是后台任务 + 邮件通知？
• 敏感字段要不要脱敏？

你这几句反问，其实就是在定义问题。

一旦问题定义清楚，让 AI 写实现，只是时间问题。

而如果你跳过这一步直接开干，大概率会收获：

• 一跑就 OOM
• 一导出就锁表
• 一上线就被安全同学找上门

真正决定你价值的，不是你敲得多快，而是你能不能把“一个看起来简单的需求”，拆成一套能落地的方案。

五、写在最后：别只做“会写代码的工具人”

回到开头那句话：

AI 不会取代程序员，但会无情地淘汰“只会写代码、不会定义问题”的那一部分工作方式的。

对还在成长中的我们来说，有几个小建议特别实在：

• 刻意练习“把需求写清楚”的能力
  哪怕是内部小工具，也试着先写一份“伪需求文档”再动手。
• 多问“为什么”和“如果…会怎样”
  为什么要有这个字段？如果数据量翻 100 倍还能不能撑住？
• 把 AI 当成“初级搭档”，而不是“替身”
  让它写初稿，你来做架构、做取舍、做兜底。

当“写代码”这件事越来越便宜，

能把问题想清楚、把系统兜住的人，就会越来越贵。