当写代码不再是最耗时间的事情

原创

菠萝.

发布于 2026-09-11 14:39:34

1190

以前做一个功能，大部分时间花在写代码上。

需求拿过来之后，需要自己理解业务、设计方案、查资料、写代码、调试、测试。代码写得快不快，往往直接影响一件事情什么时候能够完成。

现在情况开始发生变化。

AI Coding 工具越来越成熟之后，写代码这件事情本身正在变快。

以前需要几个小时完成的代码，现在可能几十分钟就能有一个可以运行的版本。

但一个有意思的问题也随之出现：

代码写得更快之后，开发工作真的变得更快了吗？

实际工作一段时间之后，会发现并不完全是。

因为写代码只是开发工作中的一部分。

而且很多时候，它甚至已经不是最耗时间的部分。

01 以前，开发慢在哪里？

一个普通需求，大概是这样的：

┌──────────┐
│   需求   │
└────┬─────┘
     ↓
┌──────────┐
│   理解   │
└────┬─────┘
     ↓
┌──────────┐
│ 查代码   │
└────┬─────┘
     ↓
┌──────────┐
│ 设计方案 │
└────┬─────┘
     ↓
┌──────────┐
│  写代码  │
└────┬─────┘
     ↓
┌──────────┐
│   调试   │
└────┬─────┘
     ↓
┌──────────┐
│   测试   │
└────┬─────┘
     ↓
┌──────────┐
│   上线   │
└──────────┘

其中最明显的一段通常是：

设计方案
   │
   ▼
写代码
   │
   ▼
调试

所以过去大家会非常关注：

IDE
代码补全
框架
组件复用
编码速度
Debug 速度

因为这些东西都直接影响代码生产速度。

但 AI 介入之后，情况开始变化。

一个普通的 CRUD 页面，可能从：

以前：

设计
  ↓
写页面
  ↓
写接口
  ↓
写类型
  ↓
写状态
  ↓
调样式
  ↓
调试

变成：

现在：

描述需求
  ↓
AI 生成初版
  ↓
人工修改
  ↓
运行
  ↓
验证

这里真正发生的变化，并不只是：

AI 帮你少写了多少行代码。

而是：

写代码这件事情，在整个开发流程中的占比开始下降。

02 代码变快之后，时间花到哪里去了？

代码写得快了，并不意味着需求可以直接完成。

反而会暴露出另外一些原本没有那么明显的问题。

比如一个看起来很简单的需求：

增加一个用户权限功能。

真正开始做的时候，可能会出现一连串问题：

用户权限
│
├── 哪些用户有权限？
│
├── 权限从哪里来？
│
├── 前端控制还是后端控制？
│
├── 菜单需要控制吗？
│
├── 按钮需要控制吗？
│
├── 接口需要控制吗？
│
├── 权限修改后什么时候生效？
│
└── 历史数据怎么办？

这些问题，AI 可以帮你分析，也可以帮你写代码。

但它不能替你决定：

业务到底应该是什么样。

所以代码生产速度提高之后，人的注意力开始向其他地方移动。

03 从“怎么写”变成“做什么”

这是 AI Coding 带来的一个比较明显的变化。

以前开发者经常面对的问题是：

这段代码怎么实现？

现在越来越多时候面对的问题是：

这个需求到底应该怎么实现？

这两个问题看起来只差几个字，实际上完全不同。

比如：

问题 A：

怎么实现一个搜索框？

这是编码问题。

而：

问题 B：

这个页面到底需不需要搜索？
搜索哪些字段？
实时搜索还是点击搜索？
搜索条件需要保存吗？
搜索结果需要分页吗？

这些已经不是单纯的编码问题了。

AI 可以很好地解决第一类问题。

对于第二类问题，它可以提供建议，但最终还是需要人判断。

所以 AI Coding 之后，开发者的工作更像：

需求
 │
 ▼
理解问题
 │
 ▼
确定方案
 │
 ▼
让 AI 实现
 │
 ▼
验证结果
 │
 ├── 不符合预期
 │       │
 │       ▼
 │     调整
 │       │
 │       └──────┐
 │              ▼
 └─────────── 再次验证
                │
                ▼
               完成

代码只是中间的一环。

04 AI 让试错变得更“便宜”

这是 AI Coding 另外一个比较实际的变化。

以前有些方案不会轻易尝试。

因为尝试一个方案意味着：

设计
 ↓
写代码
 ↓
调试
 ↓
测试
 ↓
验证

可能半天就过去了。

如果最后发现方案不合适，成本比较高。

所以开发过程中经常会出现：

“这个方案虽然不太好，但是先这么做吧。”

AI 出现之后，情况会发生变化。

如果一个方案只需要几十分钟就可以做出一个版本，那么就可以：

方案 A
 │
 ├── 快速实现
 │
 └── 不合适
       │
       ▼
方案 B
 │
 ├── 快速实现
 │
 └── 比较
       │
       ▼
方案 C
 │
 ├── 快速实现
 │
 └── 验证

所以：

AI 降低的不只是编码成本，还有试错成本。

以前更倾向于：

先想清楚
    ↓
再开始做

以后可能越来越多变成：

先做一个出来
    ↓
快速验证
    ↓
发现问题
    ↓
继续调整

这其实是在改变开发方式本身。

05 代码越容易生成，代码也越容易变多

这里又有一个很现实的问题。

以前写代码比较贵，所以很多事情会认真考虑：

这个抽象有没有必要？
这个功能是不是必须做？
这个组件要不要复用？
这个逻辑应该放在哪里？

现在可能变成：

“让 AI 帮我加一下。”

成本非常低。

于是很容易出现：

代码增加
   ↓
功能增加
   ↓
文件增加
   ↓
依赖增加
   ↓
复杂度增加
   ↓
维护成本增加

最后发现：

功能确实越来越多，但项目也越来越难维护。

所以 AI 降低了代码生产成本，却不会自动降低软件复杂度。

甚至在使用方式不合理的情况下，可能加快技术债产生的速度。

06 真正稀缺的，可能不是代码，而是判断

如果代码越来越容易生成，那么什么东西会变得更重要？

可能是：

问题理解
    +
方案判断
    +
代码判断
    +
风险判断
    +
结果判断

具体来说：

问题理解
└── 用户真正需要解决什么？

方案判断
└── AI 给出的几个方案，哪个更合理？

代码判断
└── 生成的代码能不能进入项目？

风险判断
└── 哪些地方可能出问题？

结果判断
└── 这个功能到底算不算完成？

这些事情有一个共同点：

它们都不是简单的代码生成。

AI 可以参与，但很难完全替代人的判断。

07 开发者之间的差距，也可能发生变化

以前一个开发者的效率，很大程度取决于：

熟悉多少技术
      +
写代码多快
      +
Debug 多快

以后这个公式可能发生变化：

开发效率
    │
    ├── 问题理解
    ├── 任务拆解
    ├── AI 使用能力
    ├── 技术判断
    └── 验证能力

于是可能出现一个比较有意思的情况。

两个开发者使用同一个 AI：

开发者 A

开发者
   ↓
AI
   ↓
生成代码
   ↓
修改
   ↓
完成

另一个开发者可能是：

开发者 B

开发者
   ↓
分析问题
   ↓
拆分任务
   ↓
AI
   ↓
生成方案
   ↓
多次尝试
   ↓
运行验证
   ↓
Review
   ↓
继续修改
   ↓
完成

两个人使用的是同一个模型。

最后结果却可能完全不同。

所以 AI 并没有把开发者之间的差距消除。

某种程度上，它只是改变了差距产生的地方。

08 团队也会受到影响

如果一个开发者可以借助 AI 完成更多事情，那么团队的协作方式也会发生变化。

以前一个需求可能是：

产品
 │
 ▼
设计
 │
 ▼
前端
 │
 ▼
后端
 │
 ▼
测试

每一个环节都需要等待前一个环节完成。

AI 并不会直接消灭这些角色。

但它可能让很多环节之间的等待时间减少。

例如：

设计还没完全确定
        │
        ▼
    AI + 开发
        │
        ▼
     先做原型

或者：

后端接口还没完成
        │
        ▼
      AI
        │
        ▼
    生成 Mock
        │
        ▼
     前端先开发

再比如：

测试用例还没准备
        │
        ▼
      AI
        │
        ▼
生成基础测试

于是团队可以更早开始并行做事情。

这可能比：

“AI 帮程序员写代码。”

本身更加重要。

因为它影响的是：

整个开发流程的节奏。

09 公司看到的，也不再只是“开发效率”

假设一个团队使用 AI 之后：

以前：

1 个月
   ↓
10 个需求

变成：

现在：

1 个月
   ↓
20 个需求

公司真正需要考虑的问题就不只是：

“开发效率提高了多少？”

而是：

为什么可以做更多事情？

可能是：

开发更快
    +
试错更便宜
    +
原型更快
    +
测试更快
    +
文档更快
    +
信息获取更快

最后变成：

同样的人
   ↓
承担更多事情
   ↓
产品迭代更快
   ↓
尝试更多方案
   ↓
更快验证市场

所以 AI 对公司的影响，可能并不是简单的：

少招几个程序员。

更现实的变化可能是：

同样规模的团队，可以承担以前更大的工作范围。

10 效率提高之后，工作量也可能增加

这里又会出现一个很现实的问题。

如果以前一个需求需要三天，现在只需要一天。

公司很可能不会因此让剩下的两天空出来。

而是：

以前：

3 天
 │
 └── 1 个需求


现在：

第 1 天 ──→ 需求 A
第 2 天 ──→ 需求 B
第 3 天 ──→ 需求 C

于是：

效率提高，不一定意味着工作减少。

有时候恰恰相反。

因为生产能力提高以后，组织能够承载的需求量也会提高。

这可能是 AI 对个人工作方式影响最大的地方之一。

以前限制团队的是：

“做不出来。”

以后可能越来越多变成：

“到底应该做什么？”

11 AI 正在改变工作的边界

过去一个开发者接到一个需求，通常会关注：

我需要改哪些代码？

现在可能需要关注：

这个问题是什么？
       ↓
有哪些方案？
       ↓
AI 可以帮我做什么？
       ↓
哪些事情应该交给 AI？
       ↓
哪些事情必须自己判断？
       ↓
怎么验证结果？

工作的边界开始从“写代码”向外扩张。

一个开发者可能需要了解：

产品
设计
测试
数据
部署
业务
AI

但这并不意味着每个人都需要成为全栈。

更准确地说：

一个人需要能够理解更多环节，然后利用 AI 完成其中的一部分。

12 写代码变快以后，真正重要的问题反而变了

以前我们经常问：

怎么让开发者写代码更快？

现在这个问题正在变成：

怎么让一个人
把一件事情完整地做出来？

这两个问题的区别很大。

前者关注：

Code

后者关注：

Problem
   ↓
Solution
   ↓
Execution
   ↓
Validation

AI 正在把其中越来越多的执行环节变得便宜。

那么人的注意力自然会更多地集中到：

理解问题
    ↓
判断方向
    ↓
做出取舍
    ↓
承担结果

结语

AI Coding 最直接的变化当然是：

写代码更快了。

但如果只看到这一点，其实低估了它带来的变化。

当代码生产成本不断下降之后，整个开发流程的重心也会慢慢移动。

以前我们花大量时间解决：

“怎么把它写出来？”

以后可能会花更多时间解决：

“到底应该做什么？”

代码只是软件开发的一部分。

当这一部分越来越便宜之后，真正稀缺的东西就会逐渐显现出来：

问题、判断、经验，以及对最终结果负责的能力。

也许这才是 AI Coding 对开发工作的一个更实际的影响。

不是让人停止写代码。

而是让：

写代码在一件完整的事情里，占据越来越小的比重。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

人工智能