Post

AI时代的软件开发方式

Posted Updated
By Liu Zhao
7 min read
AI时代的软件开发方式

开篇 - AI时代的软件开发方式

从 Code Driven 转变为 SDD Driven

Spec-Driven Development

核心思想：

1

系统由规格驱动，而不是由代码驱动

事实：

1.代码生成能力突破

大型模型已经能稳定生成：

  • API
  • CRUD
  • 前后端逻辑
  • 测试代码

2. 代码生产成本接近零

3.Repo级理解能力

AI已经可以理解：

1
2
3

整个代码库结构
跨文件依赖
模块关系

本质影响：控制权上移

越靠近业务与系统设计的位置，掌握的生产控制权越大；越靠近代码执行的位置，控制权越小

1
2
3

传统：代码决定系统。
现在：规格决定系统。
控制权属于：定义规格的人

软件生产从“代码驱动”变成“规格驱动”

生产控制权逐渐上移到：

1
2
3

Spec
Architecture
Product Definition

我们需要做

思维的转变 - 认知

  1. 代码不再是唯一资产
1
2
3
4

  AI时代核心资产：
    Prompt
    Context
    Architecture
  1. 从 Code Writer 变为 Code Director
1

代码不再稀缺，真正稀缺的是：系统定义能力

流程的转变 - 实践

角色分工围绕编码生产，传统软件生产链条：

1

需求 → 设计 → 编码 → 测试 → 发布

Vibecoding模式

1

需求 → 任务定义（Spec） → AI生成 → [验证 + 约束] → 上线

组织的转变 - 组织

组织能力的变化

Spec Engineering（规格工程）

1
2
3
4
5
6
7

组织需要建立：

  系统规格
  模块规格
  任务规格

Spec 质量将直接决定系统质量。

AI 协作能力

1
2
3
4
5
6
7
8
9

团队必须掌握：

  Prompt 设计
  Context 管理
  Agent 编排

需要形成：

  AI开发规范

系统架构能力

当代码生产成本下降后

1
2
3
4
5
6
7
8
9
10

系统质量主要由：

  架构设计
  模块边界
  数据模型

组织需要更多：

  Architect

代码治理能力

1
2
3
4
5
6
7
8
9
10
11
12
13

AI生成代码的风险是：

  代码膨胀
  结构混乱
  重复实现

因此组织必须强化：

  代码库治理

包括：

  模块边界规则、AI修改约束、Repo结构规范

组织结构的变化

传统团队：

1

  PM、TL、Engineers、QA

AI团队：

1

  Product、Architect、AI Engineer、Software Engineer

Product （产品控制）

1
2
3
4
5

决定：产品规格设计
  系统目标
  产品能力
  业务边界

Architect （系统控制）

1
2
3
4
5

决定：系统如何组织
  系统结构
  模块划分
  技术边界

AI Engineer （AI生产控制）

1
2
3
4
5
6

决定：AI如何执行任务
  Prompt设计
  Spec设计
  Context管理
  Agent流程设计

Software Engineer （执行层）：

1
2
3
4

从手写大量代码到系统操作
  验证实现
  修复问题
  维护代码

隐藏角色：AI Champion

AI Champion 是组织 AI 转型的推动者

1
2
3
4

制定AI开发规范
设计Prompt模板
维护Context
培训团队

指标的变化

传统指标：

1
2
3

代码量
需求交付数
缺陷数

新的可能的指标方向： 目前缺乏验证数据，建议团队先用X和Y试点，3个月后复盘

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Spec 质量：
  Spec覆盖率
  Spec完整度
  Spec复用率

AI生产效率：
  AI代码生成比例
  AI任务成功率
  AI修复次数

研发效率：
  需求周期
  任务交付速度
  部署频率

系统稳定性：
  Bug率
  系统可用性
  回滚率

研发资产变化

传统：

1

代码

AI时代：

1
2
3
4

Specs
Context
Prompt
Agent

研发文化变化

传统：

1
2
3
4

工程师英雄主义
复杂代码
高技术门槛
个人能力突出

AI时代：

1
2
3
4

系统工程文化
结构清晰
流程稳定
规范统一

团队规模变化

团队规模变化取决于两个变量：

1
2
3
4
5
6
7

1. 代码生成成熟度（当前约60-80% CRUD/API可自动化）
2. 需求模糊度（清晰需求 vs 探索性产品）

情景A（高成熟+清晰需求）：规模可能缩减30-40%，产出提升50%+
情景B（高成熟+高模糊）：规模不变，但产出结构变化（更多架构师，更少执行层）
情景C（当前多数团队）：规模短期不变，个体产出提升被需求增长吸收

建议团队自行设定试点：选定2个模块，3个月后对比人效数据

企业竞争力变化

从 工程能力 到 AI生产体系 - 更高效驱动AI生产软件

哪些工程可能是反例

1
2
3
4
5
6
7
8
9
10

强合规领域（金融核心系统、医疗设备）：
AI生成代码的审计链条未建立

高频迭代初创产品：
Spec编写成本可能高于直接编码（需求日变）

遗留系统重构：
Context窗口限制导致Repo级理解失效
SDD
SDD
This post is licensed under CC BY 4.0 by the author.