AI 产品
发布时间 2026.06.05
一切都从约束开始
AI 原生工具的难点,常常不在于先沉淀资产或统一视觉,而在于先理解约束。产品框架、功能含义、交互边界没有被理解,设计、验证、测试都会很难控住。
Thesis
AI 原生工具要先理解约束,再去做结果。设计、验证、测试都一样:产品框架、功能含义、交互边界和定位没搞清楚,AI 的输出就很难可控。
想 AI 原生设计软件时,我经常觉得很多讨论的优先级有点倒了。
大家很容易先聊资产沉淀、视觉统一、组件库、品牌风格。这些当然重要,但它们更像渐进积累出来的东西,未必是第一天最痛的地方。
更早出现的问题,其实是 AI 做出来的东西能不能被控制。好不好看当然重要,但它有没有在正确的框架里做正确的事,更早决定能不能用。
Argument
设计不是孤立发生的。设计跟着功能走,功能跟着产品框架走,而产品框架又是在长期迭代里一点点长出来的。
所以一个设计工具如果只理解视觉,很快就会碰到边界。它能生成一个漂亮界面,但不一定知道这个页面在产品里承担什么角色;它能整理一组组件,但不一定知道哪些组件代表关键流程,哪些只是局部表达。
所以资产沉淀和视觉统一通常不是最开始的根问题。资产可以慢慢积累,视觉也可以通过规范和反馈逐步统一。但如果 AI 不理解约束,它每一次生成都可能偏离产品结构。
约束会把创造力落到正确位置。
对 AI 原生设计软件来说,至少要理解这些约束:产品框架、功能目标、交互含义、页面定位、用户状态、业务规则、权限边界和已有实现。
产品框架决定这个东西属于哪一层。它是入口、流程、配置、结果页,还是审核节点。功能目标决定页面要帮用户完成什么。交互含义决定一个按钮、一个状态、一个空页面到底在表达什么。
如果这些东西没有被理解,AI 就只能根据表层相似性做设计。它会把设计当成画面,看不到画面背后的产品结构。
好的设计工具必定要对框架有最完整的认知。它不仅要知道有哪些页面和组件,还要知道它们在产品中的含义、交互关系和定位。
这会改变工具的评价标准。过去我们常问一个设计工具能不能画得更快、做得更美、协作更顺。未来还要问:它能不能知道哪些地方不能乱动,哪些地方必须继承,哪些地方可以发散,哪些地方需要先问清楚。
一旦这样看,设计只是一个例子。
验证也是从约束开始。AI 不能随机挑几个问题问用户,它要知道这个功能要验证的假设是什么,哪些反馈能证明它成立,哪些反馈只是噪音。
测试也是从约束开始。AI 不能只多跑几条用例,它要知道系统不允许出现什么状态,哪些路径必须稳定,哪些边界条件一旦破掉会造成真实损失。
AI 原生工具不能只会生成。它要能理解约束、维护约束、在约束里行动,也要能在约束不清楚时停下来。
Model
上游约束
产品框架
决定页面、流程和能力属于哪一层
功能目标
决定用户到底要完成什么
业务规则
决定哪些状态、权限和边界不能被破坏
中间含义
交互含义
按钮、状态、反馈各自代表什么
页面定位
入口、配置、执行、结果、审核的差别
已有实现
设计必须接住组件、代码和历史决策
下游产出
设计
不是画面,而是结构的表达
验证
围绕假设,而不是随机收集反馈
测试
保护边界,而不是堆更多用例
AI 原生工具如果不理解约束,产出越快,偏离也可能越快。可控性来自上游框架、功能目标和交互含义被系统理解。
Implications
- ·AI 原生设计软件的第一优先级,不应该只放在资产沉淀上,还要建立产品框架和约束理解能力。
- ·视觉统一会在资产积累后逐步发生,但可控性必须更早发生。否则每次生成都可能成为一次结构偏移。
- ·验证和测试也要从约束出发。AI 需要知道要验证什么假设、保护什么边界,不能只做更多动作。
- ·好的 AI 工具应该能区分哪里可以创造,哪里必须继承,哪里需要先问人确认。
Closing
一切都从约束开始。没有约束,AI 只是更快地产出;理解约束,AI 才可能进入产品、设计、验证和测试的真实工作流。