理性看待AI编程

我们曾经说过，AI协作编程逐渐被接受，以及SDD理念的推出，这背后是以下三点原因推动：

1.代码生成能力突破，大型模型已经能稳定生成：

API
CRUD
前后端逻辑
测试代码

2.代码生产成本接近零

3.Repo级理解能力，AI已经可以理解：

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

同时聒噪的声音也很多，比如：”AI取代研发”，”一些公司只保留初级研发+AI”等等。

现在让我们从三个维度来聊聊，如何理性看待AI编程。

首先有必要认识一下什么是一个工程。

工程的结构：不是线性流程

工程的真实结构

多数人把工程理解成：

需求 → 写代码 → 上线

但真实结构更接近：

[问题建模]
     ↓
[系统结构设计]
     ↓
[实现（代码生成）]
     ↓
[运行态控制]
     ↓
[反馈 → 重新建模]

1. 建模层（Modeling）👉 决定问题是什么

用户行为（是否突发并发）
业务约束（票是否可超卖）
风险模型（是否有攻击）

2. 结构层（Architecture）👉 决定系统如何承载问题

是否需要队列削峰
是否需要缓存
状态如何分布

3. 实现层（Execution）👉 决定功能如何落地

API、数据库、逻辑实现

4. 控制层（Control）👉 决定系统在异常下是否存活

限流、熔断、降级
监控、报警、回滚

5. 反馈 👉 这是闭环的关键 运行态产生的数据、事故、用户行为变化：

修正问题模型（原来对并发的假设是错的）
调整结构设计（这个模块的边界割裂了事务一致性）
甚至推翻原有架构（业务形态已变化）

工程的难度主要不在“构建”，而在“预测 + 控制”

真实的工程你会遇到：

① 非线性

流量 ×2 → 系统压力可能 ×10
错误会放大（重试风暴）

② 涌现性

问题来自“组件之间的交互”
不是单点代码错误

③ 延迟反馈

架构问题往往在上线后才暴露
稳定性问题只有在压力下出现

AI 在工程中发挥了什么作用

AI 擅长的区域

局部的、上下文闭环、确定性的任务，如：

写函数
实现 API
数据处理逻辑

输入明确
输出可验证

有标准答案或可测试

这些特性对应工程中的：

实现层

AI 不擅长的区域

即工程中的不可见部分：建模层 + 结构层 + 控制层

全局一致性
多模块协同、长周期演化

隐含约束
容量、成本、非功能性需求

非线性系统
突发流量、故障传播路径

运行态认知
实际生产环境的复杂性、真实用户行为

为什么很多人会高估AI在工程中的作用，把工程简单理解为编程实现。

人的认知缺陷

1. 可见性偏差

我能看到的 = 重要的
我的工作 = 写代码 = 工程

写代码（可见） → 被高估
架构设计（不可见） → 被低估
稳定性（没出问题） → 被忽略

2. 线性思维偏差

线性思维：投入 ×2 → 产出 ×2

实际情况：小错误 → 系统崩溃，非线性风险不易被察觉

一个典型崩溃链路：

瞬时流量 ↑
→ DB 连接耗尽
→ 请求变慢
→ 用户重试
→ 流量进一步 ↑
→ 服务线程阻塞
→ 整体不可用

这里没有一行代码写错

3. 幸存者偏差

看到：小团队 + AI 做出产品

看不到：大量系统在早期规模下“假性稳定”

4. 经验错位

初级问题定位：代码问题 → 修代码 → 解决

真实情况可能是：系统问题 → 结构问题 → 无法局部修复

站在整个工程角度，实现层最可见、反馈最快，我们把最容易替代的部分当作最重要的部分，AI极大的降低了实现成本，但没有降低系统的复杂度。