AI 时代，产品设计环节能定义什么

很多人说“AI 会改变产品设计”，但说得太泛，最后容易变成一句空话。

我更关心一个更具体的问题：

AI 时代，产品设计环节到底能定义什么。

如果还停留在传统理解里，产品设计的输出通常是：

• 需求文档
• 原型
• 页面说明
• 流程图

这些当然仍然重要，但已经不够了。

因为当 AI 能参与代码生成、测试补全、接口定义和页面骨架搭建之后，产品设计就不再只是“描述一个要被开发实现的东西”，而是可以直接定义出一部分可执行资产。

换句话说，产品设计的边界正在前移。

它不只是定义“要做什么”，还可以进一步定义：

• 系统该怎么被使用
• 页面怎么被串起来
• 接口怎么长
• 测试怎么验证
• 哪些核心逻辑应该先被固定下来
• 页面骨架怎样先跑通

一、场景和用例描述

这是最基础的一层，也是后面所有定义的起点。

很多项目做不稳，不是因为代码写不出来，而是因为一开始连“这个系统在什么场景下被谁使用、要解决什么问题”都没有描述清楚。

所以产品设计首先仍然要定义：

• 目标用户是谁
• 典型场景是什么
• 用户在什么触发条件下进入流程
• 关键用例有哪些
• 每个用例的成功标准是什么

如果这层没说清楚，后面的页面、接口、测试和代码逻辑都会漂。

但在 AI 时代，这层定义不再只是写给人看的背景材料，而是可以直接成为后续资产的上游输入，比如：

• 用来生成页面流转
• 用来约束接口设计
• 用来生成 E2E 测试骨架
• 用来反向检查页面和逻辑有没有覆盖真实用例

所以场景和用例描述，不再只是 PRD 里的“说明文字”，而是整个系统定义的源头。

二、页面 URL 和跳转关系

传统产品设计很容易只画页面原型，却不去定义页面之间到底怎么组织。

但从工程实现看，页面 URL、路由结构和跳转关系，其实是非常关键的系统骨架。

产品设计完全可以在前期就把这些定义清楚：

• 页面 URL 是什么
• 页面层级怎么组织
• 哪些页面是列表页、详情页、编辑页、结果页
• 页面之间如何跳转
• 哪些跳转需要带参数
• 哪些页面需要支持回跳、分享、深链接

这件事一旦定义清楚，收益很大。

因为这不只是设计问题，也是：

• 前端路由问题
• 用户路径问题
• E2E 测试路径问题
• 数据对象承接问题

一套明确的 URL 和跳转关系，往往比单个页面本身更能决定整个产品是不是顺。

三、OpenAPI 定义

很多团队会把 API 设计放到“开发阶段再说”，但在 AI 时代，这个动作完全可以更早。

因为一旦你已经定义了：

• 场景
• 用例
• 页面
• 页面跳转

那很多接口其实已经呼之欲出了。

这时候产品设计完全可以继续往前一步，直接定义 OpenAPI。

这层定义至少包括：

• API URL pattern
• 请求方法
• 输入参数
• 输出结构
• 错误码和异常返回
• 分页、过滤、排序规则

这里有一个容易被忽略的点：

这里说的不是页面路由，而是 API URL pattern。

也就是说，OpenAPI 的定义不只是数据模型定义，也包括 API 的资源如何组织、路径如何表达、不同对象之间的层级关系如何暴露。

所以如果只定义请求和响应的数据结构，却不去定义 API URL pattern，那么接口契约其实还没有真正定完整。

为什么这件事很重要？

因为 OpenAPI 一旦定义清楚，它就不只是文档，而会立刻变成很多下游资产的源头：

• 前后端联调契约
• mock 数据
• SDK 生成
• agent 可调用工具定义
• 自动化测试基础

也就是说，OpenAPI 不是“开发实现之后顺手补一下”，而可以成为设计阶段就确定下来的系统契约。

更重要的是，一旦 OpenAPI 定义完成，前端很多工作其实就可以继续做下去。

因为前端这时候已经不一定要等真实后端全部完成，完全可以先实现 mock 接口，围绕明确的 API 契约继续推进：

• 页面开发
• 状态流转
• 表单提交流程
• 错误态和空态处理
• 前端测试

这意味着 OpenAPI 在这里的价值，不只是方便后续联调，而是让前端在产品设计阶段之后，就能基于契约继续往前推进工程实现。

四、E2E 测试

很多人会觉得测试属于开发后期，和产品设计无关。

我不这么看。

因为 E2E 测试本质上描述的是：

一个真实用户如何从入口一步一步完成关键用例。

而这件事，和产品设计本来就是强相关的。

产品设计完全可以在设计阶段就定义：

• 核心用户路径
• 每条路径的起点和终点
• 中间关键页面
• 每一步应该看到什么
• 哪一步输入什么
• 哪一步校验什么结果

这些内容稍微结构化一点，就已经非常接近 E2E 测试用例了。

在 AI 时代，这种设计资产甚至可以直接被转成：

• Playwright / Cypress 的测试骨架
• 页面对象模型
• 流程回归测试

但前端测试不应该只理解成“前后端都接好之后再跑的 E2E”。

前端自己其实也可以定义很多 UI 测试，而且这些测试既可以基于测试 API，也可以基于真实 API。

比如：

• 组件交互测试
• 页面状态切换测试
• 表单校验测试
• 错误提示和空态测试
• 基于 mock 数据的页面回归测试

也就是说，前端测试在这里至少有两层：

• 一层是前后端联通后的 E2E
• 一层是前端自己可先行推进的 UI 测试

这会让产品设计阶段定义的用例，不只是变成最终的全链路验证，也能更早沉淀成前端自己的可执行测试资产。

所以产品设计不是“先写流程图，测试同学以后再补”，而是可以更进一步：

直接把关键用例定义成可执行的 E2E 测试。

五、六边形 domain 逻辑和测试

这是更值得重视的一层。

很多产品设计停在页面和交互层，但其实很多真正重要的规则，不属于页面，而属于 domain。

比如：

• 一个订单在什么状态下允许取消
• 一个审批流什么条件下能进入下一步
• 一个任务对象什么时候算完成
• 一套报价规则如何计算

这些都不是 UI 逻辑，而是业务逻辑。

如果这些逻辑在设计阶段已经很明确，那完全可以继续前推，直接定义成六边形架构里的 domain 逻辑。

这里关键的不是“先把全部代码写完”，而是把最核心、最稳定、最不应该漂的规则先沉淀出来。

更进一步，这些 domain 逻辑还应该配套测试，并且能直接被代码 import 使用。

这意味着产品设计的输出，不再只是：

• “这里应该这样判断”

而是可以逐步变成：

• 可 import 的 domain rule
• 可运行的 domain test
• 不依赖 UI 的核心业务规则资产

这一步非常关键，因为它把“需求理解”真正压成了可以被程序执行和验证的东西。

六、页面框架，而且要支持 E2E 跑通

很多时候，产品设计做完后，团队虽然有原型，但项目里还没有一个真正能跑的页面骨架。

这会导致两个问题：

• 原型和真实工程脱节
• 后续测试、接口联调和上下文接入都启动得很慢

所以在 AI 时代，产品设计还可以继续定义：

• 页面框架
• 页面基础组件区块
• 路由骨架
• 关键交互占位
• 可以支撑 E2E 跑通的最小页面流

这里的重点不是视觉细节全部到位，而是先把系统骨架搭出来，并且让关键路径能跑通。

一旦这层存在，收益会非常直接：

• E2E 可以更早开始
• 接口 mock 和联调更容易接入
• 后续 UI 细化不容易把主流程搞坏
• AI 也更容易围绕真实工程骨架继续补内容

而且一旦页面框架和 mock 接口已经跑起来，前端其实就已经不只是“等后端”的状态，而是在继续完成真实功能开发。

因为很多前端功能，本来就可以在契约明确后先往前推进，包括：

• 页面结构实现
• 交互流程实现
• 状态管理实现
• UI 测试补全
• 基于 mock API 的页面联调

所以页面框架不是“开发开始之后才有的东西”，而可以成为产品设计阶段就定义并落地的最小可运行资产。

七、为什么说产品设计也可以完成一部分代码逻辑开发

把前面几层合起来看，你会发现一件事：

产品设计现在已经不只是写说明，而是在定义一部分系统本身。

因为一旦你已经定义了：

1. 场景和用例
2. 页面 URL 与跳转关系
3. OpenAPI
4. E2E 测试
5. 六边形 domain 逻辑与测试
6. 可跑通的页面框架

那你其实已经完成了相当一部分“代码逻辑开发”的前置工作，甚至不只是前置工作，而是直接完成了其中一部分本体。

原因很简单：

• OpenAPI 本身就是接口契约代码的源头
• E2E 本身就是可执行测试代码
• domain 逻辑和测试本身就是核心业务代码
• 页面框架本身就是前端工程骨架

这说明产品设计的角色，正在从“提出需求的人”，变成“定义可执行系统规格，并直接产出部分系统资产的人”。

八、真正的变化不是设计替代开发，而是边界重组

这里要避免一个误解。

这并不是说产品设计要替代开发，也不是说设计人员必须自己手写所有代码。

真正的变化是：

在 AI 帮助下，设计和开发之间原来那条很硬的边界，正在被重新组织。

以前常见的流程是：

• 产品写文档
• 设计画原型
• 开发自己翻译成路由、接口、逻辑和测试

现在更合理的流程可以变成：

• 产品设计先定义场景、页面关系、接口契约、关键测试和核心 domain 规则
• AI 和工程一起把这些定义快速落成代码和骨架
• 开发再在此基础上做深化实现、性能优化、异常处理和长期演进

这不是削弱工程，而是让工程的起点更高，也让需求和实现之间的损耗更小。

结语

所以如果问我，AI 时代产品设计环节能定义什么，我会说至少可以定义这六类东西：

1. 场景和用例描述
2. 页面 URL 与跳转关系
3. OpenAPI 定义
4. E2E 测试
5. 六边形 domain 逻辑和测试
6. 支持 E2E 跑通的页面框架

当这些内容被定义清楚，并进一步沉淀成可执行资产后，产品设计就不再只是“写需求”，而是已经开始完成一部分代码逻辑的开发。