用 AI 做产品设计,关键不是让 AI 画图或写代码,而是把 AI 放进产品运行过程里承担任务,并把自己的判断标准写成 AI 能读的上下文。
AI根据立正公开的文章和视频整理,不是他本人回复。重要的判断,请回到出处核对。
先分清 AI 是帮你造,还是在产品里干活
材料里的观点用 Cursor 写代码、让 AI 生成设计稿,都属于开发阶段帮忙,用户打开产品时 AI 并没有参与理解、判断和行动,这不算 AI 产品。真正的分界是:用户使用时,AI 有没有在系统内部承担一部分任务执行。一个邮件助手哪怕代码简单,只要它会读上下文、判断意图、生成回复、调用接口、等用户确认再发送,就已经有了 AI 运行时的参与。判断成熟度可以顺着问:AI 只是回答,还是能基于上下文回答、调用工具、嵌入固定流程、决定下一步、循环执行并纠错、带记忆和权限、主动触发。产品设计时先想清楚你要它停在哪一层,再决定界面和流程怎么搭1。
把隐性判断写成 AI 能读的上下文
材料里的观点AI 产出总是差点意思,往往不是模型不行,而是它不知道你的标准。品牌调性、审美偏好、受众画像、过往取舍这些都在你脑子里,从没被写成 AI 能读的格式。做法是先文档化:把风格偏好、判断原则、验收标准写下来,再针对每个具体任务精选最相关的背景,而不是把所有东西都塞进去。给指令时定义结果而不是遥控步骤,说清做到什么算对。这个过程本身有价值,很多人写文档时才发现自己的标准从没被真正想清楚过2。
第一版是拿来发现问题的,不是拿来交付的
材料里的观点在开始之前,产品只是一个名词,它把几百个关于信息、权限、状态、用户预期的决定压缩成一个看起来边界清晰的东西。计划发生在压缩后的世界里,真正的工作发生在解压后的现实里。很多正确的决定在看到错误版本之前根本不存在:先看到页面才知道信息顺序不对,先用过才知道哪些数据不该占主要位置。所以 AI 把写代码的成本压低后,值得先做一版能跑的东西,用它来暴露你原本想不到的问题,而不是指望一次做对。Demo 只需要展示那一刻是对的,产品要在现实变化中一直是对的3。
这些材料讲的是判断框架和原则,没有给出针对具体产品类型的设计步骤,实际落地还要结合你的产品形态。
出处
- 1AI产品的六个层次
讲清 AI 辅助开发与 AI 在产品运行时工作的区别,是理解这个问题的起点。
- 2AI 用得好的人与普通人的5个差距,和背后具体技术原因|非技术岗位版
解释为什么 AI 产出总差点意思,以及把隐性判断显性化的具体做法。
- 3Don't build: 看清demo和production之间的鸿沟
说明第一版的作用和 demo 与产品的差距,帮你调整对迭代的预期。
你也有想问的?
卡住的时候,问问立正:回答只从立正讲过、写过的东西里来,每一段都能点回原文。
问类似的问题也可以接着问:
别人还问了
- 什么场景/团队/项目用MCP/Skills什么时候不用
MCP 和 Skills 不是按场景二选一,而是先看结果、再看它是否真省 context:官方 MCP/CLI 简单但结果杂乱、几轮就撑满窗口时,才值得自己做成 Skill。
- 什么是创意?创意也是对现有元素的组合排列吗?是的话,在这种情况下,怎么判断一个点子是否是真正创新的创意?最后如何获得创意?
创意可以看成对现有元素的重新组合,但判断它是否真创新,要看它是否解决了一个此前没被满足的真实需求;获得创意的路径是靠近真实问题、快速交给现实修正,而不是坐在房间里凭空想点子。
- 如何能找到building的第一个东西
先做一个能跑通的最小版本,用它来发现你原本看不见的需求;building 是习惯,不是一次学会的知识。
- 想做的事情太多,身边的噪音也太多,害怕选择了一条路放弃了别的东西,什么都想抓住,到头来什么都做不好。ai时代日新月异,该如何保持well informed,同时找到并且坚定自己的conviction
先分清哪些是决定方向的层级、哪些只是执行方法,再把“保持知情”当成筛选信息的能力而非追新;信念感来自对底层逻辑的理解,不是靠意志硬撑。
- 如何有效的整合和利用数据?
整合数据的关键不是把数据堆在一起,而是先建立对业务、产品和用户的正确心智模型,再用实验检验每个改动,让数据回答它真正能回答的那部分决策。
- Ai平权下,资源更值钱,那么学习知识的目的是什么
AI让知识本身不再稀缺,学习的目的从「记住答案」转向「能判断、能行动、能交换」——用行动和思考引领求知,而不是先囤知识。