Chat 模式是和 AI 最好的交互范式吗?
1分钟看图掌握核心观点👇 图1 VS 图2,您更倾向于哪张图来辅助理解全文呢?欢迎在评论区留言。 我从 GPT-3.5 发布第一个月就开始用 AI,也尝试写过各种demo项目,参与过早期的NextChat开源项目,现在每天都离不开各类AI工具。最近在想一个问题:Chat模式是和AI最好的交互范式吗? 图片来源于 TOP 50 GEN AI WEB PRODUCTS 用ChatGPT的时候,我经常有种感觉:就像在和一个很聪明的朋友聊天。我说一句,它回一句,我们慢慢把问题聊清楚。 这种感觉和用其他AI功能很不一样。比如一些"一键生成"的功能,我点一下,它哗啦啦输出一大堆,我看着就头大。 想了想,发现Chat模式有个特点:你一句,我一句,每次交换的信息都是小块的。 大模型本质上是预测下一个token。它需要基于前面的内容来预测后面的内容。 这让我想到一个角度:Chat模式中,每次用户的一句话,其实都是对AI预测下一段token的调整。 或者用更技术的语言说:每次人的输入都在减少AI理解用户意图的熵。 Chat交互模式: 用户: "我想写个用户管理功能" 每一轮对话,AI对用户意图的理解都更精确一些 从这个观察中,我想到一个概念:意图信息密度匹配。 用户的意图信息密度: ┌─────────────────────┐ │ 具体目标 + 使用场景 │ │ + 个人偏好 + 约束条件 │ └─────────────────────┘ AI理解的意图信息密度: ┌─────────────────────┐ │ 从对话中提取的 │ │ 用户真实意图程度 │ └─────────────────────┘ 当两者匹配度高时,AI输出就符合期望;当差距过大时,AI输出就会偏离预期。 无论是AI理解不了人,还是人不再能够理解AI输出的内容,都不是一个好的体验。 Chat模式的本质就是:它能和AI进行高密度的意图交互。 想到这里,我开始观察其他好用的AI功能,发现它们虽然不是Chat模式,但本质上也在做类似的事情。 我: function calculatePrice( 这也是人一下,AI一下的模式。我写前几个单词,AI预测后面的,我选择是否采纳。整个过程协同密度足够高,每一步都在对齐认知。 会议进行中: (1)我手动记录: [重要决定] 下周发布新功能 [风险点] 数据库性能 [行动项] 张三负责测试 (2)AI同时记录: 完整的会议转录内容 (3)结合阶段: AI基于我的重点标记来组织它记录的详细内容 这个设计很有意思:它没有采取"你一句我一句",而是采取并行理解相同的内容,然后AI往人的理解上靠。 本质也是在减少熵增,拉齐认知,并且以人为主导。 图片来源于granola(www.granola.ai/) 五、为什么一键生成常常让人失望? 对比一下一键生成的模式: 一键生成模式: 用户: "帮我写个电商网站" 问题在于: 观察一些真正好用的AI产品: 它们的共同点:都在用户提供丰富意图上下文的基础上进行AI增强,同时保持人和AI一致性理解。 当然,也有一些场景适合大颗粒度生成: 这些场景的特点是:用户意图相对简单,或者对结果要求不高。 比如飞书的会议总结就是好的应用场景 图片来源于飞书app(feishu.cn) 基于这些观察,我觉得设计AI功能时可以考虑: 从技术发展看,可能的优化方向: 但核心还是:人机意图信息密度匹配。 Chat模式是和AI最好的交互范式吗? 我觉得不是唯一的,但它确实体现了一个重要原则:高密度的意图交互。 好的AI交互设计,本质上都在解决人机意图信息密度匹配问题。Chat模式是一种很好的实现方式,但不是唯一的方式。 关键是要理解你的用户意图有多复杂,然后设计合适密度的交互方式。 这是作者作为重度AI用户的一些观察和思考。 你在用AI时有什么感受?有没有发现其他有趣的交互模式?欢迎交流~! 本文仅分享作者基于个人技术实践的思考和主观观点,不构成决策依据。作者:vivo 互联网项目团队- Ding Junjie
本文从作者使用AI的实践经验出发,探讨了Chat模式作为AI交互范式的特点和优势。作者提出了"意图信息密度匹配"的核心概念,认为好的AI交互设计本质上都在解决人机意图信息密度匹配问题。通过分析Cursor Tab补全、Granola会议笔记等成功案例,以及对比一键生成模式的局限性,文章总结了不同AI交互模式的适用场景和设计原则。作者认为Chat模式虽然不是唯一的最佳交互范式,但它体现了高密度意图交互的重要原则,关键是要根据用户意图的复杂程度设计合适密度的交互方式。


一、Chat 模式为什么让人感觉舒服?
二、从AI的工作原理看Chat模式
AI: "好的,你需要哪些具体功能?增删改查?还是..."
用户: "主要是查询和编辑,要支持分页"
AI: "明白了,你用的是什么技术栈?数据库是..."
用户: "React + Node.js,MongoDB"
AI: "好的,我来帮你写一个基于这个技术栈的用户管理..."三、意图信息密度匹配的概念
四、其他成功的交互模式也有类似特征
4.1 Cursor Tab补全:另一种"你一句我一句"
AI: items: Product[], discount: number): number {
我: ↵ (采纳) const basePrice =
AI: items.reduce((sum, item) => sum + item.price, 0);
我: ↵ (采纳) return basePrice *
AI: (1 - discount);
4.2 Granola会议笔记:并行理解,AI往人靠

AI: [生成大量代码和文档]
用户: [需要花很多时间理解和修改,最后发现根本用不了!!!]六、成功的AI产品/功能都在不断拉齐人和AI的共同认知
七、什么场景适合"一键生成"?
7.1 意图简单明确的场景
7.2 容错度高的场景

八、一些思考
8.1 评估意图复杂度
8.2 选择合适的交互密度
8.3 设计意图校准机制
九、未来的方向
十、回到最初的问题