老A拆局第二篇：

AI Coding 真正改变的，不只是写代码。

而是软件开发的分工。

距离上一篇已经过去了很久，最近一直在出差，感谢还在关注的朋友们。

这两年，关于 AI Coding 的讨论很容易走向两个极端。

一种说：

程序员快被 AI 替代了。

另一种说：

AI 写的代码质量一般，最多就是高级补全。

我觉得都太粗糙。

更接近现实的变化是：

AI 会让“写代码”越来越便宜。

但会让“定义问题、设计流程、验证结果”越来越值钱。

代码生成速度会越来越快。

但软件能不能交付。

能不能维护。

能不能长期演进。

最后看的还是工程能力。

01｜提效是真的，问题也是真的

AI Agent 对开发的帮助已经很明显。

它能帮你读陌生代码，能生成样板代码，能解释报错，能补测试，能做一部分重复劳动。

一个熟练开发者，用好 Claude、Cursor、Codex 这类工具，效率提升是能感受到的。

但另一面也很真实。

AI 能很快写出一段“看起来能跑”的代码。

可这段代码未必真的好。

可能边界不全。

可能异常处理很弱。

可能重复逻辑很多。

可能短期能跑，长期难维护。

更麻烦的是：

很多 AI Coding 还停留在“个人提效”阶段。

对团队协作、工程规范、系统一致性的帮助，还远远不够。

所以问题不在于 AI 能不能写代码。

它当然能。

真正的问题是：

生成代码的速度，不等于软件交付的效率。

当代码越来越容易生成，真正稀缺的东西反而变了。

需求表达。

系统边界。

测试验证。

架构约束。

工程治理。

这些东西，开始变得更重要。

02｜AI Coding 正在经历四个阶段

我把 AI Coding 粗略分成四个阶段。

第一阶段：外部知识库

最早大家怎么用？

把代码复制到 ChatGPT。

让它解释、修改、生成一段。

再贴回 IDE。

这种方式门槛低。

但上下文割裂。

项目结构、依赖关系、历史约束，它都不一定知道。

所以经常是：

看起来答得不错。

一放进项目，编译不过。

第二阶段：IDE 副驾驶

后来是 Copilot、Cursor 这类形态。

AI 进入开发环境。

能看当前文件。

能补全代码。

能基于局部上下文修改。

这个阶段已经明显提效。

但它仍然偏“被动”。

你问一句，它答一句。

你让它改一个点，它改一个点。

它未必真正理解整个系统。

第三阶段：工作流智能体

再往后，就不是让 AI 改某个文件了。

而是给它一个任务：

读取项目。

规划步骤。

修改代码。

运行测试。

根据错误继续修。

这个阶段的关键，已经不是“模型会不会写代码”。

而是你有没有给它：

角色。

边界。

规则。

工具权限。

验证标准。

第四阶段：自主软件工程师

理想状态下，AI 可以根据标准需求文档。

端到端完成开发、测试、修复和交付。

但现实是：

一句话需求远远不够。

真正能驱动 AI 自主开发的，不是灵感。

而是清晰的 PRD。

明确的验收标准。

稳定的技术约束。

可运行的测试样例。

完整的工程上下文。

所以你会发现：

AI Coding 越往后走，越不像聊天。

越像一套工程系统。

03｜程序员的价值会迁移

以前，很多开发时间花在编码实现上。

需求沟通、设计、测试、验证、文档，经常被压缩。

但如果越来越多代码由 AI 生成，开发者的工作重心就会迁移。

程序员不再只是代码生产者。

会越来越像三种角色的混合体。

1. 意图定义者

把模糊需求拆成 AI 能理解、能执行、能验证的任务。

别只说：

“帮我做个登录。”

而要说清楚：

支持哪些登录方式？

失败场景有哪些？

安全边界在哪里？

验收标准是什么？

2. 规范设计者

定义目录结构、接口约束、错误处理、测试标准和交付边界。

AI 可以写代码。

但谁来告诉它什么叫“好代码”？

谁来告诉它哪些地方不能动？

谁来告诉它历史包袱在哪里？

这就是工程师的价值。

3. 流程编排者

让 AI 按步骤工作。

而不是让它自由发挥。

先理解需求。

再写测试。

再实现。

再跑验证。

再根据结果修复。

最后由人做设计审查。

这才是比较稳的 AI Coding。

所以，我不认为 AI 会消灭程序员。

但它会改变一个问题：

以前拼的是谁更会写代码。

以后拼的是谁更会定义问题、约束 AI、验证结果。

04｜越是 AI 时代，测试越重要

以前很多团队不爱写测试。

觉得慢。

觉得麻烦。

觉得收益不明显。

但 AI Coding 会让测试重新变得重要。

原因很简单：

当代码是 AI 生成的。

人类更需要一个稳定机制判断它是否符合预期。

否则只能靠肉眼审查大量代码。

低效。

也不可靠。

一个更稳的流程应该是：

先定义测试场景

再生成单元测试

让测试先失败

再让 AI 写实现

用测试结果驱动修复

最后由人审查结构和边界

这其实不是新概念。

它回到了软件工程基本功：

先定义正确性，再追求实现速度。

设计模式也会重新变重要。

不是为了炫技。

而是为了隔离变化。

人写稳定框架。

AI 写可替换实现。

接口、策略、适配、模板方法，这些东西会重新变得有价值。

因为它们能把 AI 生成代码关在可控边界里。

换句话说：

AI 时代不是不需要架构。

反而更需要架构。

05｜从 Vibe Coding 到 Agent Engineering

现在很多 AI Coding 的问题，本质上是缺乏约束。

用户给一句模糊需求。

AI 写一堆过程式代码。

看起来完成了功能。

实际上边界不清、重复代码多、异常处理弱。

这类做法，我更愿意叫它：

Vibe Coding。

凭感觉写。

凭感觉改。

凭感觉觉得“差不多了”。

它适合快速原型。

但不适合长期系统。

更成熟的方向，是 Agent Engineering。

也就是把 AI 当成一个可编排的工程执行者。

给它角色。

给它上下文。

给它输出格式。

给它测试标准。

给它工具权限。

同时也给它边界。

未来 AI Coding 的竞争，不只是模型能力竞争。

更是工作流、上下文、评测、权限、成本和稳定性的竞争。

06｜我为什么做 SDC

这也是我做开源项目SDC - Spec-Driven Coding的原因。

它想解决的问题很直接：

不要让 AI Coding 停留在一句话需求后的自由发挥。

而是把开发过程收敛成一个可追溯闭环：

spec -> plan -> tasks -> apply -> check -> archive

在 SDC 里，需求会先被拆成场景、规则和验收标准。

任务会被切成可验证的薄切片。

执行过程中会保留设计、测试、审查和归档证据。

它不是为了让 AI 写得更多。

而是为了让 AI 在更清楚的边界里写得更稳。

如果你也在尝试把 AI Coding 从个人提效工具，推进到团队可复用、可验证、可沉淀的工程流程。

可以看看这个项目：

https://github.com/ruanjianershu/spec-driven-coding

最后

AI Coding 的下一阶段，拼的不只是模型。

而是谁能把模型稳定地接进真实工作流里。

最后总结四句话：

🔹 AI 写代码，不等于软件能交付

🔹 代码生成越快，需求和验证越重要

🔹 程序员不会消失，但价值会迁移

🔹 真正稀缺的，是工程判断力

我是老A。

以后，我们继续拆。

如果你觉得这篇文章有价值，欢迎关注 + 星标「老A拆局」。

每周我们一起拆解技术、AI、支付与管理的底层逻辑。

也欢迎转发给你身边正在使用 AI Coding 的朋友。