为什么 PRD + 设计稿，无法支撑 AI 时代的研发协作？当 AI 开始参与研发流程：产设研协作可能会如何变化？

AI软件研发研发流程需求建模Task IR设计资产

2026-03-17

随着 AI 开始参与软件研发流程，一些变化正在逐渐显现。

在实际推进研发自动化的过程中，我们发现，影响并不只发生在“代码生成”这一层，更早出现在需求、设计与实现之间的协作方式上。

这篇文章基于一次真实的企业实践，尝试讨论一个具体问题：

当执行者开始从人扩展到系统时，
产设研之间的协作，是否需要重新定义？

引言

在过去几年里，AI 在软件研发领域的能力进展非常快。

从最早的代码补全，到现在的 AI Coding Agent，这一变化也在不断加深人们的一个判断：

AI 是否会改变软件开发本身。

与此同时，在代码生成、测试生成以及 UI 构建等方面的能力，已经逐渐成为行业共识。

但在真实企业研发环境中，一个更实际的问题正在出现：

当 AI 开始参与研发流程时，产设研之间应该如何协作？

在传统的软件研发流程中：

产品团队负责需求
设计团队负责交互与视觉
研发团队负责实现

但当 AI 开始参与实现环节时，很多团队会开始思考一个问题：

在 AI 时代，我们各自的角色是什么？

这篇文章尝试从一次真实的企业实践出发，讨论一个更具体的问题：

如果研发流程逐渐自动化，那么需求、设计和实现之间的结构应该如何变化？

一、一个越来越明显的问题：AI 时代产设研如何协作

在大多数互联网公司中，软件研发流程通常类似这样：

plain

PRD
↓
设计稿
↓
研发实现

产品经理编写需求文档（PRD），设计师完成界面和交互设计，研发工程师根据这些信息实现功能。

这种模式已经被验证多年，并且在很多团队中运作良好。

但随着 AI 工具的出现，一些新的变化开始出现。

例如，在很多实际场景中，AI 已经可以参与：

AI 可以生成代码
AI 可以生成测试用例
AI 可以辅助构建 UI

这些能力意味着：

软件研发中的某些执行环节，正在逐渐被自动化。

这也带来了一个新的问题：

如果系统可以参与研发执行，那么研发流程本身是否需要发生变化？

尤其是：

产品团队
设计团队
终端研发团队
平台工具团队

在 AI 时代，都希望能够参与到新的研发体系之中。

因此，一个新的问题开始出现：

产设研之间的协作方式，是否需要重新定义？

二、我们真正想解决的问题：研发流程自动化

在很多关于 AI 编程的实践中，早期的关注点往往集中在“代码生成”这一环节。

但如果从工程视角来看，一个更大的问题其实是：

研发流程是否可以自动化。

软件研发并不仅仅是写代码，它通常包含一整条流程，例如：

plain

需求提出
↓
需求分析
↓
系统设计
↓
功能实现
↓
测试验证
↓
上线发布

如果 AI 只参与其中的“代码实现”环节，那么研发流程的整体结构其实并没有改变。

但如果系统能够逐渐参与更多环节，例如：

需求理解
任务拆解
自动化测试
自动验证

那么研发流程就可能出现一种新的形态：

plain

需求
↓
任务结构
↓
自动化执行
↓
自动验证

在这种情况下，软件工程的核心问题就会发生变化：

系统需要理解需求，而不仅仅是执行代码。

因此，一个更具体的问题开始浮现：
当研发流程逐渐自动化时，
需求、设计与实现之间的协作方式，是否也需要随之改变？

三、执行者正在发生变化

在传统的软件工程中，需求的执行者主要是人。

产品经理描述需求，开发者阅读需求并编写代码。

因此，需求文档通常是为人类阅读而写的。

但当 AI Agent 开始参与研发流程时，执行者开始发生变化。

过去的软件研发结构可以理解为：

plain

需求
↓
开发者理解
↓
代码实现

而在 AI 参与研发的情况下，可能逐渐变成：

plain

需求
↓
系统理解
↓
Agent 执行
↓
代码生成

当执行者从人逐渐扩展到系统时，一个新的问题就出现了：

系统如何理解需求？

自然语言描述对于人类来说是清晰的，但对于自动化系统来说，往往不够具体。

这就意味着：

需求可能需要一种新的表达方式。

当执行者从人逐渐扩展到系统时，一个隐含的问题开始显现：

过去，需求中的不完整信息，可以在开发过程中被不断补全。
但在自动化系统中，这种“隐式补全”能力并不存在。

这意味着：

当前依赖人类理解与补全的协作方式，可能无法直接迁移到以系统为执行者的研发流程中。

四、研发系统可能出现新的分层

如果从系统角度来看研发流程，我们可以将未来的研发系统粗略划分为三层。

第一层是 需求与设计输入层。

这一层包括：

PRD
设计稿
API 文档
业务规则

这些内容描述了系统需要完成什么。

第二层是 任务建模层。

这一层负责将需求转化为系统可以理解的任务结构，例如：

用户行为
系统响应
UI 状态变化
功能约束

在后续实践中，我们将这种结构称为：

Task IR（Task Intermediate Representation）

第三层是 执行层。

这一层由各种能力模块组成，例如：

AI Coding Agent
IDE 工具
自动化测试
自动化验证

整个系统的结构大致可以理解为：

plain

PRD / 设计稿
↓
Task IR
↓
Agent / 工具执行

在这种结构中，Task IR 更像是一个任务调度层。

五、为什么设计资产可能成为未来研发系统的重要输入

在传统研发流程中，设计稿通常被视为一种视觉参考。

设计师完成界面设计之后，开发者根据设计稿实现对应界面。

但如果从系统视角来看，设计稿实际上包含大量结构信息。

例如，在设计工具中，一个页面通常已经包含：

UI 层级结构
组件关系
页面状态
交互流程

以 Figma 为例，一个页面的设计稿往往已经隐含了：

UI hierarchy
component structure
interaction flow

这些信息如果能够被结构化提取，就可以成为研发系统的重要输入。

换句话说，设计稿不仅是视觉表达，也是一种系统结构描述。

在这种情况下，设计资产就不再只是参考资料，而可能成为研发系统的一部分。

从另一个角度看，这种变化也可能意味着设计团队在研发体系中的角色会发生一些变化。

在传统研发流程中，设计稿更多是作为实现参考存在。设计师完成界面与交互设计之后，研发团队再根据设计稿进行实现。

但如果设计资产逐渐成为研发系统的重要输入，那么设计工作的价值也会发生一些变化。

设计不仅是在定义视觉和交互体验，同时也在描述系统结构，例如：

页面层级
组件结构
状态变化
用户操作路径

这些信息如果能够被更结构化地表达，就不仅仅服务于界面实现，也可以成为研发系统理解产品行为的重要依据。

从这个角度看，设计团队不仅在参与产品体验设计，也开始参与研发系统中“行为结构”的表达。

六、需求建模：从自然语言到结构化描述

为了让系统能够参与执行，我们在实践中引入了“需求建模”这一环节，这也成为协作方式变化的一个关键触点。

另一个问题来自需求本身。

大多数 PRD 都是以自然语言形式存在的。

例如，一个需求可能这样描述：

在订单列表页新增筛选条件，并支持点击切换订单状态。

对于产品和研发团队来说，这句话通常已经足够清晰。

但从系统角度来看，这种描述仍然存在一些问题。

例如：

用户操作路径是什么
页面在什么情况下更新
是否需要整页刷新
数据为空时如何展示

这些信息往往隐藏在开发者经验、评审讨论和沟通之中。

如果希望系统能够理解需求并参与执行，这些信息就需要被明确表达。

因此，在需求与实现之间，可能需要一个新的环节：

需求建模（Requirement Modeling）。

需求建模的目标，是将自然语言需求转化为更结构化的描述。

在很多团队中，类似 Task IR 的想法并不是第一次出现。

在过去的软件工程中，也曾出现过多种结构化需求表达方式，例如 DSL、Spec 或模型驱动开发。但这些方式往往难以在通用的软件研发环境中成为主流实践。

一个重要原因是，当时系统能够自动执行的能力仍然有限，大部分工作仍然需要开发者完成。

但在最近几年，一些基础条件正在发生变化：

AI Coding Agent 开始具备生成代码的能力
自动化测试与验证工具越来越成熟
设计工具中的结构信息也越来越丰富

当系统开始具备“执行能力”时，需求结构的重要性就会迅速上升。

换句话说，Task IR 并不是一个全新的概念，而更像是在新的技术条件下，一种重新被激活的工程结构。

当研发系统逐渐具备自动化执行能力时，需求表达方式也可能随之发生变化。

七、Task IR：研发系统中的任务表示

在需求建模之后，我们可以得到一种结构化的任务表示。

在本文中，我们将这种结构称为：

Task IR（Task Intermediate Representation）。

Task IR 的目标是描述一个需求在研发系统中的基本结构，例如：

用户行为
系统响应
UI 状态变化
验收标准

与 PRD 不同，Task IR 更接近系统内部使用的一种结构化表达。

它既不是代码，也不是设计稿，而是一种任务结构。

八、一个简单的前端需求示例

举一个简单的前端需求例子。

PRD 中可能这样描述：

在订单列表页新增筛选条件，并支持点击切换订单状态。

对于业务和研发团队来说，这句话通常已经足够清晰。

但如果希望自动化系统能够理解并执行，这个描述仍然不够具体。

例如：

用户操作路径是什么
页面在什么情况下需要更新
列表为空时应该如何展示
是否需要整页刷新

因此，在 Task IR 中，这些信息需要被结构化表达。

例如：

plain

feature: order_list_filter

user_flow:
  - 用户进入订单列表页
  - 点击筛选按钮
  - 选择“待发货”
  - 页面刷新并展示对应数据

acceptance_criteria:
  - 筛选条件默认展示全部
  - 选择“待发货”后仅展示 status=waiting 的订单
  - 状态切换后页面不刷新，仅局部更新列表
  - 列表为空时展示空态组件

在这种结构下，一个需求不再只是文字描述，而是被拆解为一组明确的行为与约束。

在一些情况下，Task IR 的部分结构甚至可以直接从设计资产中推导出来。例如页面结构、组件层级和交互流程，这些信息在设计稿中往往已经存在。

九、从需求到自动化执行

当需求被表示为 Task IR 之后，它就可以被研发系统进一步处理。

例如，一个 Task IR 可以被拆解为多个具体任务：

新增筛选组件
接入订单状态筛选参数
更新列表查询逻辑
实现空态展示组件

这些任务可以由不同能力模块执行，例如：

UI Code Generation
API Integration
Test Generation
自动化验证

在这种模式下，Task IR 更像是研发系统中的一个 调度层。

整个研发流程可能逐渐演变为：

plain

PRD / 设计稿 / API
↓
需求建模
↓
Task IR
↓
Agent 执行
↓
自动化验证

十、研发流程可能正在发生变化

如果从更长的时间尺度来看，软件研发流程可能正在发生一种变化。

过去的软件工程更多关注代码实现。

研发流程通常是：

plain

PRD
↓
开发理解需求
↓
代码实现

而在自动化系统逐渐参与研发之后，流程可能逐渐变成：

plain

PRD / 设计
↓
结构化需求
↓
Task IR
↓
Agent 执行

在这种结构下，软件工程的关注重点可能会发生变化。

团队不再只是关注如何实现代码，而需要思考：

如何表达需求
如何建模系统行为
如何构建可被自动化系统理解的结构

在这种结构下，产设研之间的关系，也可能从“信息传递”，逐渐转向“结构共建”。

结语

在传统的软件研发流程中，需求、设计和实现之间的大量信息依赖人的理解与传递。

PRD 需要开发者解读，设计稿需要工程师还原，测试用例需要人工补充。

这种方式在以人为执行者的研发体系中是合理的。

但当自动化系统开始参与研发流程时，很多信息就需要被更加明确地表达出来。

用户操作路径、系统状态变化、UI 行为约束，这些内容过去往往隐藏在经验和沟通之中。

如果系统需要理解需求，这些信息就需要被结构化表达。

Task IR 可以看作是在当前技术条件下，对这一问题的一种工程化尝试。

它试图在需求与实现之间建立一层新的表示，使需求能够被系统理解、调度和执行。

在这种结构下，PRD、设计稿和 API 文档不再只是人阅读的资料，而逐渐成为研发系统的输入。

如果这种变化继续发展，那么未来的软件工程可能会越来越关注一个问题：

如何表达问题本身。

换句话说，软件工程的核心问题，或许正在从“如何实现代码”，转向“如何表达问题”，
而产设研之间的协作，也正在围绕这种表达方式被重新组织。

而 Task IR，只是这个方向上的一个起点。

此外，在这种变化之下，产设研之间的边界，可能不会消失，但正在变得更加模糊。

不同角色之间的协作，不再依赖彼此之间的“翻译”，而是开始围绕同一套结构表达展开。

如果这种趋势继续发展，那么未来的软件研发中，角色之间的划分，可能不再体现在“产设研”的职能分工上，而更多体现在对系统不同维度的建模能力上。

加载中...

加载评论中...