最近几个月，我开始越来越多地使用 AI 参与日常开发，起初我以为变化最大的会是 Coding

但真正用了一段时间后，我发现最大的变化其实发生在研发流程——一个我们过去习以为常、现在却开始处处「别扭」的地方

一、旧流程为什么开始别扭

一个让我一直觉得别扭的问题

我们团队的研发流程和大多数技术团队差不多：

1	需求评审 -> 技术方案设计 -> 技术方案评审 -> 开发 -> 测试 -> 上线

过去，这套流程跑得很顺，但在引入 AI 之后，我们很自然地开始让 AI 根据需求直接生成 Spec（实现规范）进行开发。这时不出意外的话，很快就遇到了一个尴尬的情况～

就是 AI 生成的 Spec 非常的详细，详细到了包含 DTO、数据库字段、SQL、Mapper、API、Migration、Unit Test，甚至每个字段的命名和类型

这时候，当我们拿着这份 Spec 去评审时，就会有些奇怪…，因为评审会上，大家真正关心的问题是：

整体业务流程是否合理？
服务之间如何交互？
数据应该归属于哪个系统？
为什么用 MQ 而不是 RPC？
为什么新增一张表，而不是修改已有表？

几乎没有人会讨论 refund_reason 字段是 VARCHAR(100) 还是 VARCHAR(255)

于是，我们可能会做一件更别扭的事：先让 AI 生成一份极详细的 Spec，再让 AI 把这份 Spec 「翻译」成传统技术方案模版的文档，以供评审

后来我意识到：问题不在于 Spec 写得不好，而在于我们还在用 AI 出现之前的研发流程，去套一个 AI 出现之后的协作方式

为什么传统研发流程长这样？

这里我想避免一种粗暴的说法：「以前的流程过时了」，事实上，在那个时代，它是最优解

因为以前研发中最昂贵的阶段是开发：

需求分析：20%
技术方案：20%
开发：60%

开发往往要持续几周。技术方案存在的最大目的，就是尽可能减少开发过程中需要思考的问题。因此方案会越来越详细，把表结构、接口定义、SQL、异常处理等都提前设计好，让开发人员可以快速实现

在那个「人写代码、人沟通、人实现」的年代，这完全是合理的

二、AI 真正改变的是什么

AI 改变的不是开发本身，而是价值分布

AI 出现后，情况开始变化。

现在我经历的需求节奏越来越像：

需求分析：40%
架构设计：30%
AI Coding：10%
验证：20%

开发不再是最耗时的环节。很多时候，一个下午 AI 就能完成 80% 的代码。真正耗时的地方变成了：如何让 AI 理解正确的问题

研发流程的重心，不可避免地前移了

传统技术方案里，其实混合了两件完全不同的事

后来我重新翻阅了很多技术方案，发现它们里面实际上混合了两类完全不同的信息

第一类：设计决策（Decision）

为什么采用事件驱动？
为什么拆分新的服务？
为什么需要最终一致性？
为什么新增退款表？

这些回答的问题是：为什么这样设计？

第二类：实现细节（Implementation）

DTO
Mapper
SQL
字段、索引
Migration

这些回答的问题是：具体怎么实现？

以前，这两部分放在一起完全没问题，因为开发人员既需要理解设计，也需要照着实现。但 AI 出现以后，它们开始服务于完全不同的对象

我认为它们应该正式分离

现在我越来越倾向于把它们拆成两份文档。

第一份：Architecture（给人）

回答：为什么这样设计？

内容会包括：

概览
业务流程
系统上下文
数据模型（逻辑模型）
架构决策记录（ADR）
风险

它关注的是系统边界、数据流、服务交互、一致性、性能、风险，而不是字段

第二份：Spec（给 AI）

回答：如何实现？

包含：

Task
DTO
API
表结构
Migration
Unit Test
Coding Constraint

Spec 的读者不是人，而是 AI。因此，它越详细越好，而且不需要拿去逐行评审

三、面向 AI 的研发流程应该长什么样

研发流程也应该跟着改变

基于这个分离，我重新设计了一版更符合 AI 协作方式的研发流程：

PRD
    ↓
Architecture Draft（AI 协助生成）
    ↓
Architecture Review（团队评审）
    ↓
Architecture Freeze
    ↓
AI 生成 Spec
    ↓
AI Coding
    ↓
AI Self Review
    ↓
Human Review
    ↓
Automated Verification
    ↓
Release

整个变化可以用一句话概括：人负责决策，AI 负责实现

Architecture 到底应该由谁写？

这是最近我观点变化最大的地方。以前我会说：让 AI 根据 PRD 自动生成 Architecture

但现在我觉得这个说法不准确，Architecture 不应该是 AI 凭空创造出来的，而应该是 AI 帮助团队逐步形成的

举个例子：

需求是「增加退款」

AI 的第一件事，不应该是直接开始写文档，而是开始提问：

是否支持部分退款？
是否允许重复提交？
库存什么时候释放？
是否需要审批？
是否采用事件驱动？
支付失败如何处理？

这些问题，其实就是开发应该首先要做的事。而 AI 的价值，不在于替我们写文档，而在于帮助团队发现自己还没思考到的问题，逐步逼近一个更可靠的设计决策

Architecture Review 未来真正评审什么？

我认为，未来的技术评审会越来越像 Architecture Decision Review。

讨论的问题会变成：

为什么采用 MQ？
为什么用 Saga？
为什么拆服务？
为什么新增表？
为什么选择最终一致性？

而不再是：

DTO 有没有字段遗漏？
SQL 要不要加一个索引？
字段长度是多少？

因为这些问题，已经属于 Spec 的范畴

Spec 不应该再成为评审对象

Spec 内容过于详细，同时里面大部分内容 AI 都可以随时重新生成。所以真正应该被评审、被挑战、被冻结的，是 Architecture

一旦 Architecture 冻结，Spec 完全可以自动生成。甚至，以后 Spec 可以不再维护，每次需要时重新生成就好

Code Review 也会发生变化

以前的 Code Review 更多关注：

命名
代码风格
重复代码
if/else 逻辑

未来，这些 AI 都可以完成。

Code Review 会越来越关注：

是否符合 Architecture？
是否遗漏了业务场景？
是否违背了 ADR？
是否影响了已有流程？

Review 的对象，从「代码写成什么样」，逐渐变成「设计是否被正确实现」

四、未来的研发分层与核心角色

真正重要的，可能是 Architecture Agent

现在很多人都在讨论 Coding Agent。

但我越来越觉得，真正重要的可能不是它，而是 Architecture Agent。

它负责：

阅读 PRD
提出关键问题
发现遗漏
整理 Architecture
输出 ADR
最终生成 Spec

Coding，只是它下游的一个环节

一个新的研发分层

经过这段时间的思考，我更愿意把 AI 时代的软件研发分成三层：

1	Decision Layer（人） --> Specification Layer（人 + AI） --> Execution Layer（AI）

Decision Layer 决定：为什么这样设计
Specification Layer 决定：AI 应该如何实现
Execution Layer 负责：将 Spec 转换为代码

这三层对应不同的职责，也对应不同的参与者

写在最后

我并不认为传统研发流程已经失效。它是在「开发成本最高」的时代形成的最佳实践。而今天，AI 正在让开发逐渐变成成本最低的环节

因此，真正需要重新设计的不是 Coding，而是整个研发流程

也许未来的软件工程，不再围绕「如何写代码」展开，而是围绕：如何形成正确的工程决策，并准确表达给 AI，这才是真正意义上的 AI Native Software Engineering

个人网页

AI 时代，重新思考研发流程：为什么我们需要把「决策」和「实现」分开