返回思考

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 才可能真正进入产品、设计、验证和测试的工作流。