4.2 从「写代码」到「定义问题」：一次真实的能力迁移

这一节是我最想跟同行聊的部分。它是这轮 AI 浪潮里对工程师最实质的冲击，也是最实在的机会。

一个具体的变化

五年前我的典型工作日：

现在：

变化的核心是：我的产出从「代码」变成了「规格 + 判断」。

写 200 行 CRUD 从 2 小时变成 10 分钟。但决定这 200 行该长什么样（表结构、接口边界、错误处理策略、幂等设计）依然需要你花 30 分钟想。

于是：瓶颈从"实现"转移到了"定义"。

这是我们团队最真实的教训。同一个需求「做一个用户积分系统」：

描述 A：「做一个用户积分系统」→ 拿到一个能加减分的单表实现，没有并发控制、没有流水、没有过期策略。本质是重写。
描述 B：「积分账户 + 流水双表；加减分必须在一个事务里；必须有幂等键防止重复入账；积分有有效期（默认 12 个月，可配置）；提供余额查询和流水查询两个接口；并发场景用乐观锁」→ 拿到的东西 80% 能用。

差别不在代码能力，在定义能力。 而定义能力，恰恰是资深工程师最值钱的东西。

一个写得好的规格，不只是这一次的输入——它可以直接变成：

规格是资产，代码是消耗品。 这句话我越想越对。

表设计：
- 表名 / 字段 / 类型 / 约束 / 索引 / 为什么需要这个索引
- 边界情况：空值、超长、并发、重复提交各怎么处理

接口设计：
- 方法 / 路径 / 入参（含类型与校验规则）/ 出参 / 错误码
- 幂等性：是否幂等，如何实现
- 权限：谁能调
- 超时与重试策略

这个任务完成的标准是：
1）功能上：<具体行为>
2）边界上：<空数据/超大数据/并发/网络失败各表现如何>
3）质量上：<性能/日志/错误提示>
4）不做的事：<明确排除的范围>

第 4 条「不做的事」是最容易被忽略、但最能省时间的——它直接防住了范围蔓延。

这个方案的风险：
- 数据风险：<会不会丢数据、能不能回滚>
- 并发风险：<竞态条件>
- 依赖风险：<外部服务挂了怎么办>
- 运维风险：<怎么监控、怎么告警、怎么排查>
- 不可逆点：<哪一步做了就回不去了>

写完风险清单，你会发现有些方案的"不可逆点"多到不该做——这就是提前发现的价值。

很多人以为 AI 会抹平水平差距。实际相反：能定义问题的人拿到大量高质量产出，不能定义问题的人拿到大量需要返工的产出。 差距被放大了。

现在人人都能生成代码。能判断这段代码在生产环境会不会出事的人，价值反而上升。

AI 能写模块，但决定系统怎么切分、边界在哪、怎么演进——这些需要全局视野和历史经验，是它最弱的地方。

以前写规格文档是「可选项」，现在它是你和 AI 之间的接口协议。写不清楚，你就拿不到好结果。这个变化对不爱写文档的工程师是个真实的挑战。

AI 不会让工程师失业，但它会让「只会执行」的工程师失去议价能力。

这不是威胁，是提醒。从今天开始，把每一次和 AI 协作都当成一次"定义能力"的训练。

延伸阅读：本站《WorkBuddy 桌面端使用指南》→「实践七：零代码制作本地应用」「实践八：自我进化—创建自己的 Skills」。