HCI

4 篇内容

工程实践知乎 - 鹅厂架构师

AI Native Is All You Need

文章通过美团小团、Figma Config 2026 和米哈游 LPM 三个案例,重新审视 AI Native 的产品形态。作者指出,小团以 LUI 接管传统 GUI 交互链路的效率提升并非绝对,某些浏览和比较过程本身就是产品价值;Figma 则保留 Canvas 并借助 AI 将代码、动画和生成能力引入同一创作空间,说明 AI 不应简单取代原有界面;LPM 从实时反应而非视频生成出发,重新定义虚拟角色的互动方式,让 AI 成为游戏世界运行的基础。文章最终提出 AI Native 的核心不在于加入 AI 功能,而在于追问过去基于旧技术限制的产品结构是否仍然必要,以及 AI 带来了哪些新可能。分析主要从产品设计角度展开,较少涉及具体技术实现,适合思考产品架构和交互范式的读者。

文章以清晰的案例分析展示了 AI Native 的多种产品设计路径,从 LUI 接管交互到保留 Canvas 再到从 AI 能力反向定义产品,为从事 AI 相关产品、架构或人机交互设计的读者提供了可迁移的思考框架。虽然缺乏技术实现细节,但它对产品结构、用户需求和历史妥协的反思具有长期参考价值,可帮助避免盲目跟风“AI 化”。

个人心得知乎 - 鹅厂架构师

AI原生游戏为什么“不好玩”

文章从作者亲身开发多款AI原生游戏的经历出发,反思当前AI游戏“不好玩”的症结:要么保守嫁接传统玩法,要么激进替代导致体验失控。作者引入Paidia(嬉戏)与Ludus(游戏)的区分,指出LLM天然适合作为响应丰富、目标弱化的“玩具”,而非严格规则系统;并通过占卜师游戏等案例说明,设计时应弱化功利目标,强化交互反馈和创造空间。文中进一步分析了LLM不可靠性带来的负面体验,并提出“合法化为世界观”“惊喜奖励”“玩家反制”等设计技巧,将AI的幻觉与失控转化为玩法本身。最后,文章展望AI原生游戏可能回归嬉戏本质,在软件玩具方向上探索更大空间。

本文推荐收录,因为它不是泛泛的产品介绍,而是基于真实AI游戏开发困境,从设计哲学到落地方法提供了连贯的反思。作者提出的“LLM作为玩具”视角,以及将AI不可靠性转化为玩法技巧的策略,对游戏开发者、AI交互应用设计师具有直接可迁移的启发,能够帮助读者在融入LLM时避免常见陷阱,探索更自然的交互形态。

工程实践Blender Developers Blog

New Socket Shapes

这篇文章解释了 Blender 5.0 重设计 Geometry Nodes 端口形状的原因与方案。旧方案用圆形、菱形和带点菱形同时表达“单值”“字段”以及“当前链接状态”,但面对列表、体积网格等新数据结构时信息过载且含义模糊,尤其带点菱形难以理解。新设计改为让形状只表达节点“期望/生成”的数据结构:竖线表示单值,菱形表示字段,圆形表示动态类型,网格/列表形状则对应仍在开发中的新结构。文章还说明了分组输入输出可自动推断并允许覆盖,虚线链接继续表示字段传递,tooltip 用于补充默认值等细节。它承认新方案会丢失部分旧信息,但认为这是为引入 volume grids、lists 以及未来更多节点能力所必须的权衡。

推荐收录,因为文章给出了从旧交互符号到新语义映射的完整设计依据,明确展示了“信息表达能力”与“可扩展性”之间的取舍。对节点编辑器、可视化语义设计和开源产品演进的读者都有直接参考价值,尤其适合做界面符号系统和数据结构表达设计的复盘。

工程实践Stanford Hazy Research

Meerkat and the Path to Foundation Models as a Reliable Software Abstraction

这篇文章提出一个核心判断:随着基础模型进入日常工作流,技术团队需要的不只是模型 API,而是能把非结构化数据、模型输出和人工反馈放在同一界面里的交互式数据系统。作者指出,传统 DataFrame 擅长结构化数据,但面对图片、PDF、网页、音频等对象时,单靠代码既难以验证模型结果,也难以高效标注和迭代。为此他们设计了 Meerkat:一种可存储复杂对象及其向量表示的异构 DataFrame,并通过 Python 内嵌 GUI 让搜索、填充、错误分析等 FM 操作可视化、可交互。文章用艺术图像分析、PDF 信息抽取和图像分类误差分析三个 demo 说明其工作流优势,但整体仍偏系统原型展示,缺少大规模基准和严谨定量评估。

收录价值在于它把“基础模型如何作为软件抽象使用”具体落到数据结构、交互界面和人机协同反馈机制上,而不是停留在概念讨论。适合做 AI 工程、数据工具和交互式系统设计的参考,但也要注意它更像原型与理念展示,缺少完整性能与可扩展性证据。