即刻App年轻人的同好社区
下载
21 年油管博主 sentdex 上传了一个视频，使用 AI 而非 3D 渲染，实现连续帧输出，玩了一段模拟GTA
当时，和朋友们比较务虚的进行了以下讨论：
「如果将人类的视觉需求分为两类：一类是信息需求，例如查看报表、地图和书籍；另一类是感官需求，如游戏和电影（并非指它们没有信息，而是指它们选择以视觉图像代替文字的部分，主要为了提供感官刺激）
对于信息类图像，必需要确保信息的准确呈现。在这种情况下，利用 AI 生成图像所消耗的算力永远大于使用基于规则的、非AI的程序进行渲染。
然而，感官类需求与此不同，其核心在于欺骗感官而非信息的绝对还原。尽管传统的 3D 渲染技术也在利用这一点（如烘焙贴图等），但整体上还是在通过引入更多的物理计算（如光追）来提高真实感，也就是说目标是再造一个真实世界。这种方案下（不考虑优化）每提高一点真实感，算力消耗都会成倍增加。导致许多算力并未直接呈现在视觉效果上，被“浪费”了
相较之下，AI 视觉生成在实现感官欺骗这个目标上更为直接。虽然在 sentdex 的示例中，AI 消耗的算力足以让传统 3D 引擎渲染出更好的画面，但未来某一天可能会反过来」
时间回到现在，相同硬件下 Stable Diffusion 之类的模型已经能比传统光追 3D 渲染器更快地生成具有相同真实感的单帧图片。尽管在可控性和视频抖动等方面仍存在问题亟待解决，但我们那时讨论的「未来某天」似乎已经经悄无声息的过去了
当时，和朋友们比较务虚的进行了以下讨论：
「如果将人类的视觉需求分为两类：一类是信息需求，例如查看报表、地图和书籍；另一类是感官需求，如游戏和电影（并非指它们没有信息，而是指它们选择以视觉图像代替文字的部分，主要为了提供感官刺激）
对于信息类图像，必需要确保信息的准确呈现。在这种情况下，利用 AI 生成图像所消耗的算力永远大于使用基于规则的、非AI的程序进行渲染。
然而，感官类需求与此不同，其核心在于欺骗感官而非信息的绝对还原。尽管传统的 3D 渲染技术也在利用这一点（如烘焙贴图等），但整体上还是在通过引入更多的物理计算（如光追）来提高真实感，也就是说目标是再造一个真实世界。这种方案下（不考虑优化）每提高一点真实感，算力消耗都会成倍增加。导致许多算力并未直接呈现在视觉效果上，被“浪费”了
相较之下，AI 视觉生成在实现感官欺骗这个目标上更为直接。虽然在 sentdex 的示例中，AI 消耗的算力足以让传统 3D 引擎渲染出更好的画面，但未来某一天可能会反过来」
时间回到现在，相同硬件下 Stable Diffusion 之类的模型已经能比传统光追 3D 渲染器更快地生成具有相同真实感的单帧图片。尽管在可控性和视频抖动等方面仍存在问题亟待解决，但我们那时讨论的「未来某天」似乎已经经悄无声息的过去了
00:45
7 10
🌞 早上讨论到不同应用分别集成 Copilot 冗余显而易见，更合理的做法是不同应用接入同一个 Copilot，让自然语言指令可以跨应用执行；🌛 到了晚上 ChatGPT plugin 方案就公布了。这些天真是日新月异，内容只要稍微在草稿箱里躺躺就显得过时
敖特_Aute: 可以看到近期LLM对传统App的改造，几乎都是给App加Copilot的模式：「弹一个窗，展示一个聊天机器人，用户可以通过与之对话来完成软件操作」 包括但不限于Office、Github、Bing、ChatPDF 等等 关于这种改造为什么不是粗暴的短期胶水方案，我另行展开，本条先假设其就是某种最佳实践 这里要讨论的是，为什么要每个App都去各自加上一个界面大差不差的Copilot？ 好处是对自身软件有着完全的数据访问权限，可以达成一些针对性更高的操作 但其中的冗余也显而易见 并且，更大的问题是当前的LLM已经完全有能力理解跨App交互的指令，却无法进行执行 例如「请帮我把Allen在微信群提到的头显加入淘宝购物车」这样一条自然语言指令，微信的Copilot不能完成我的请求，淘宝的Copilot也同样不行（虽然这两个Copilot目前还不存在😛 如何解决这一问题，或许有两种方案： 一是通过云，但这要求我们使用的所有App都来自一家巨头，或它们都接入同一个云 二是通过端，操作系统层的Copilot能力开放，App可选择主动适配，也可以通过系统级的GUI识别、用户事件模拟，来被动接入 既然云与端的方案都要App厂商进行接入或适配，而端的方案还能通过GUI识别（读屏）、用户事件模拟等技术对没有接入的App做降级兼容。再考虑到现在各家App大厂的林立现状，端的方案极有可能最终胜出 从端的视角，苹果的多端互通、快捷指令、视障辅助功能、SwiftUI等都可以算是已经做好准备的基建 无论是视障辅助功能的界面的识别；还是通过LLM自然语言转结构化数据的能力，解决操作复杂学习成本高问题后的快捷指令，在端方案下都将发挥出巨大价值 这也是为什么我认为在本轮LLM热潮中苹果看上去有些掉队，但其实还握着一张绝佳船票的理由 注：上文的云与端并不是指AI运行在哪里，而是指这个跨应用串联的流程执行的地方 讨论可微：aute_wechat
6 11
可以看到近期LLM对传统App的改造，几乎都是给App加Copilot的模式：「弹一个窗，展示一个聊天机器人，用户可以通过与之对话来完成软件操作」
包括但不限于Office、Github、Bing、ChatPDF 等等
关于这种改造为什么不是粗暴的短期胶水方案，我另行展开，本条先假设其就是某种最佳实践
这里要讨论的是，为什么要每个App都去各自加上一个界面大差不差的Copilot？
好处是对自身软件有着完全的数据访问权限，可以达成一些针对性更高的操作
但其中的冗余也显而易见
并且，更大的问题是当前的LLM已经完全有能力理解跨App交互的指令，却无法进行执行
例如「请帮我把Allen在微信群提到的头显加入淘宝购物车」这样一条自然语言指令，微信的Copilot不能完成我的请求，淘宝的Copilot也同样不行（虽然这两个Copilot目前还不存在😛
如何解决这一问题，或许有两种方案：
一是通过云，但这要求我们使用的所有App都来自一家巨头，或它们都接入同一个云
二是通过端，操作系统层的Copilot能力开放，App可选择主动适配，也可以通过系统级的GUI识别、用户事件模拟，来被动接入
既然云与端的方案都要App厂商进行接入或适配，而端的方案还能通过GUI识别（读屏）、用户事件模拟等技术对没有接入的App做降级兼容。再考虑到现在各家App大厂的林立现状，端的方案极有可能最终胜出
从端的视角，苹果的多端互通、快捷指令、视障辅助功能、SwiftUI等都可以算是已经做好准备的基建
无论是视障辅助功能的界面的识别；还是通过LLM自然语言转结构化数据的能力，解决操作复杂学习成本高问题后的快捷指令，在端方案下都将发挥出巨大价值
这也是为什么我认为在本轮LLM热潮中苹果看上去有些掉队，但其实还握着一张绝佳船票的理由
注：上文的云与端并不是指AI运行在哪里，而是指这个跨应用串联的流程执行的地方
讨论可微：aute_wechat
包括但不限于Office、Github、Bing、ChatPDF 等等
关于这种改造为什么不是粗暴的短期胶水方案，我另行展开，本条先假设其就是某种最佳实践
这里要讨论的是，为什么要每个App都去各自加上一个界面大差不差的Copilot？
好处是对自身软件有着完全的数据访问权限，可以达成一些针对性更高的操作
但其中的冗余也显而易见
并且，更大的问题是当前的LLM已经完全有能力理解跨App交互的指令，却无法进行执行
例如「请帮我把Allen在微信群提到的头显加入淘宝购物车」这样一条自然语言指令，微信的Copilot不能完成我的请求，淘宝的Copilot也同样不行（虽然这两个Copilot目前还不存在😛
如何解决这一问题，或许有两种方案：
一是通过云，但这要求我们使用的所有App都来自一家巨头，或它们都接入同一个云
二是通过端，操作系统层的Copilot能力开放，App可选择主动适配，也可以通过系统级的GUI识别、用户事件模拟，来被动接入
既然云与端的方案都要App厂商进行接入或适配，而端的方案还能通过GUI识别（读屏）、用户事件模拟等技术对没有接入的App做降级兼容。再考虑到现在各家App大厂的林立现状，端的方案极有可能最终胜出
从端的视角，苹果的多端互通、快捷指令、视障辅助功能、SwiftUI等都可以算是已经做好准备的基建
无论是视障辅助功能的界面的识别；还是通过LLM自然语言转结构化数据的能力，解决操作复杂学习成本高问题后的快捷指令，在端方案下都将发挥出巨大价值
这也是为什么我认为在本轮LLM热潮中苹果看上去有些掉队，但其实还握着一张绝佳船票的理由
注：上文的云与端并不是指AI运行在哪里，而是指这个跨应用串联的流程执行的地方
讨论可微：aute_wechat
48 1035
只要视觉仍然是人类获取信息的最主要方式，GUI 就不会失去在各种人机接口中的主导地位，某种意义上 AI 与GUI并不在一个层，之间的关系不是取代而是混合。
但混合了AI的GUI复杂也好，简洁也罢，却并不能成为世界是否还需要这么多产品经理的判断依据。与其说古典产品经理基于GUI，不如说古典产品经理基于非AI时代，AI才是那个关键的变量。
至于界面是否由手机承载，在没有更好的随身显示设备出现之前，我想是的，即便手机所承载的界面可能会同今天发生巨大变化。
另外想要补充的是，为什么上文中用［GUI］而不是原Po中的［人机交互界面］，因为［界面］不仅仅是一个具象的、视觉的［面］，我们通过什么与机器交互，什么就是人机界面，可以是声音，可以触觉，也可以是自然语言对话AI等等。interface ：界面；接口
但混合了AI的GUI复杂也好，简洁也罢，却并不能成为世界是否还需要这么多产品经理的判断依据。与其说古典产品经理基于GUI，不如说古典产品经理基于非AI时代，AI才是那个关键的变量。
至于界面是否由手机承载，在没有更好的随身显示设备出现之前，我想是的，即便手机所承载的界面可能会同今天发生巨大变化。
另外想要补充的是，为什么上文中用［GUI］而不是原Po中的［人机交互界面］，因为［界面］不仅仅是一个具象的、视觉的［面］，我们通过什么与机器交互，什么就是人机界面，可以是声音，可以触觉，也可以是自然语言对话AI等等。interface ：界面；接口
春溪: AI产品一定需要视觉吗？一定需要一个界面吗？或者说这个界面需要极其复杂吗？ 如果视觉不可缺失，那么AI产品的人机交互依然是由手机承载吗？
2 10
延伸一下 GPT 是三个界面：
1.自然语言到自然语言（例：翻译
2.自然语言到结构化数据（例：控制智能家居
3.结构化数据到自然语言（例：分析一个CSV
其实还有第四个：结构化数据到结构化数据。但由于这个是一次性的，在首次执行之后就可以固化下来，所以拿掉
这里的一次性指，由于界面两边都是结构化的，所以对于GPT而言，它所需要做的只是在两者间首次映射的时候生成转换规则的代码，之后的再次映射都是规则代码的执行，而不需要GPT介入了
1.自然语言到自然语言（例：翻译
2.自然语言到结构化数据（例：控制智能家居
3.结构化数据到自然语言（例：分析一个CSV
其实还有第四个：结构化数据到结构化数据。但由于这个是一次性的，在首次执行之后就可以固化下来，所以拿掉
这里的一次性指，由于界面两边都是结构化的，所以对于GPT而言，它所需要做的只是在两者间首次映射的时候生成转换规则的代码，之后的再次映射都是规则代码的执行，而不需要GPT介入了
原动态已删除
2 01
关于 2 我认为，只要视觉仍然是人类获取信息的最主要方式，GUI 就不会失去在各种人机接口中的主导地位。
以即刻为例。对于不熟悉即可的用户来说，如果他们无法看到界面，在面对孤零零的「输入框」时只会感到无所适从，不知道自己可以输入哪些指令。但在 GUI 下，就不存在这样的问题，所有能做的都被呈现在界面上，你只需按需点击即可。即使是对于熟悉的用户来说，「输入“告诉我即友今天都发了哪些动态”」和「点击动态图标后在时间线随意滑动」，相对于后者，前者都太耗时，心智负担太重了。
当然，这并不否认以 GPT 为代表的大语言模型所推动的 LUI 发展将会给人机交互带来深刻变革，只是表达对 GUI 重要性的一些看法，以及为什么它不会沦为只剩一个输入框。 //@波克波克比: CLI到GUI再到NUI，历史不会重复，但是会押韵～
以即刻为例。对于不熟悉即可的用户来说，如果他们无法看到界面，在面对孤零零的「输入框」时只会感到无所适从，不知道自己可以输入哪些指令。但在 GUI 下，就不存在这样的问题，所有能做的都被呈现在界面上，你只需按需点击即可。即使是对于熟悉的用户来说，「输入“告诉我即友今天都发了哪些动态”」和「点击动态图标后在时间线随意滑动」，相对于后者，前者都太耗时，心智负担太重了。
当然，这并不否认以 GPT 为代表的大语言模型所推动的 LUI 发展将会给人机交互带来深刻变革，只是表达对 GUI 重要性的一些看法，以及为什么它不会沦为只剩一个输入框。 //@波克波克比: CLI到GUI再到NUI，历史不会重复，但是会押韵～
SUKIII: 关于AI可能如何变革编程和人机交互行业的两个猜想： ⌨️编程： 未来将进入自然语言编程时代，工程师不再需要学习那么多编程语言，只需要像对话一样描述需求，就可以完成研发。 💻人机交互： 现在的人机交互是基于图形语言，我们需要让用户学习大量的界面、图标、操作按钮。而未来，人机界面只需要精简到一个输入框即可。
2 13
这个Demo是当时为了在公司内讲课准备的，作为工具网站上线还有很多需要完善。由于最核心的部分只是一段Prompt而已，各位有能力访问 GPT 的即友可以尝试自己组织一下提示词，一定能达到相同的效果，也因为这样我也没有把这个工具做完上线的计划（如果各位即友对GPT调用相关的工程实践感兴趣的话，可以看看发在评论区视频，是我前些天给南京的产品经理社群做的分享的录屏 //@泛函: 哇这个超级有用诶！可以分享个链接🔗嘛？
泛函: 又发现了一个好玩的小工具，叫作 chatmind，可以像操作 chatGPT 一样，用文本生成思维导图。 我目前探索出来的场景就是做读书笔记，之前没有这玩意的时候，每次用思维导图做读书笔记前，还得把目录抄一遍， 现在可以直接用文字生成大纲了。 下图是我输入“《运筹学》目录大纲”生成的结果，准确率看样子不低。 网址链接🔗：https://www.chatmind.tech/
2 10
