3 为什么要创立该项目

3. 为什么要创立该项目

❓ 要解决的问题

必须面对现实的是，在相当长的时间里，以什么样的方式与用户接触是由端侧开发者（或公司）决定的。在现有的大多数商业模式下，用户本人参与交互是产品价值体现和盈利的基础，比如活跃用户数和广告收入。没有人可以强制要求端侧必须开放足够多的权限，放任在无人介入的情况下完全由 AI 执行操作。

如果 AI 足够聪明，人类确实没必要每次都从首页开始使用产品。因此，我们可以看到人机对话成为下一代的交互主界面几乎已经成为共识。

然而，自然语言表现力的天然缺陷，原本是寄希望于通过设计好的交互来弥补，现在却被对话框取代了。对话框的局限性一下子就暴露出来了：

(1) 光标的指示作用缺失

交互形式从"屏幕+焦点操作"模式转向自然语言模式。传统焦点操作通过键盘、鼠标和触控屏实现，具有精准的指示性。而自然语言交互带来以下影响：

• 丧失指示的精准性：表达和理解的难度增大，歧义增多，我们称之为"光标缺失效应"。

  例如，用户说"删除这个"时，系统难以确定"这个"具体指向哪个对象，而传统界面中鼠标点击可以精确定位。

• 信息表达效率受限：纯粹语音的信息表达效率不高，语音输入的优势主要体现在逐字表达场景。

  例如，当你想放大一个缩略图时，你可能要说"放大"或者打字"放大"，而传统的交互只需要点击一下。

• 语言表达能力的门槛高：自然语言交互对用户的文字表达能力要求很高，制造了人机交互的难度。

  例如，不擅长文字表达的用户可能无法准确描述需求，导致系统理解偏差，而传统界面通过按钮、菜单等视觉元素降低了表达门槛。

• 信息读取效率低：文本流阅读和声音的阅读都不如结构化信息读取效率高。

  例如，系统用语音播报一长串数据列表时，用户需要听完整个列表才能找到目标信息，而传统界面可以通过表格、卡片等结构化形式让用户快速扫描定位。

• 受制于语轮回合：受制于语轮回合的交互，对快速连续性操作不够友好。

  例如，用户需要连续执行多个操作时，必须等待每轮对话完成才能进行下一步，而传统界面可以快速连续点击多个按钮完成批量操作。

(2) 信息碎片泛滥

会话的流式信息结构缺乏条理，并不像传统软件以页面为单元组织信息架构，通过可视化的图形界面构建视觉友好的信息呈现层次。这就会有以下衍生的问题：

• 不同信息难以隔离：在单个会话内连续的信息流很难辨别不同话题的边界，甚至多个完全不相干的话题会混杂在一起。

  例如，用户在一个会话中先询问"帮我查一下明天的天气"，接着又问"上次那个项目进度怎么样了"，然后又问"推荐几本好书"，这些完全不相关的话题混在一起，难以快速定位和回顾。

• 僵尸会话爆炸：当人为通过会话隔离信息时，会话内的信息被折叠在以会话为单位的黑盒内，最终因为可见性低而沦为僵尸会话。

  例如，用户创建了"工作相关"、"学习笔记"、"购物清单"等多个会话，但每个会话中只有零散的几条消息，时间一长这些会话就被遗忘，成为无法有效利用的僵尸会话。

• 无法多维度管理：散落在无数会话中的同类信息组织不起来，因为无法同某个特定维度管理信息。

  例如，用户在不同会话中分别询问过"Python 教程"、"JavaScript 教程"、"React 教程"等学习资源，但无法按照"学习资源"这个维度统一查看和管理，只能逐个会话查找。

• 缺少可指示的对象：信息溶解在文本信息中，当我们需要有所指时，没有具体的对象可指称。

  例如，用户说"把刚才那个方案再优化一下"，但"刚才那个方案"只是文本流中的一段话，没有独立的标识和结构，系统难以精确定位和操作。

(3) 不同终端人机界面差异很大

未来更多终端设备将由 Agent 驱动，通过屏幕、摄像头、麦克风、扬声器等设备与人的知觉对应，完成人机交互。但是，不同终端因为其物理特征本身就有差异，不可能强行使用同样的交互模式。因而在与AI融合上存在难度：

• 媒介断层：当AI反馈的信息结构对终端不友好，那么必然会造成信息表达的缺失或混乱。相反，终端提供的信息结构也不一定是对AI友好的。

  例如，把一段原本为大屏仪表盘设计的复杂数据可视化，直接用语音在智能音箱上"念出来"，用户几乎无法建立整体认知；反过来，智能手表上仅有的一行提示信息，也很难完整承载 AI 期望表达的复杂语义。

• AI不够掌握终端特性：人类为了增强表现力，在复杂语境中或者要表达复杂逻辑时，常常使用多个软件和终端配合演示。而AI似乎还只会"说"。

  例如，产品经理讲方案时，会一边放投影片、一边在白板上画结构图、再配合 Demo 页面点击操作；而当前的 AI 往往只能用一段长文本或一串语音来解释，很难利用投屏、标注、动画等终端能力来增强表达。

• 虚拟与现实的鸿沟：目前的AI所使用的语境（或上下文）是基于预设和记忆的知识，而真实场景下的语境往往是动态的、与现实环境相关。

  例如，AI 可以"记住"用户的个人资料和历史对话，却很难实时感知用户此刻坐在会议室、正在翻看哪一页纸质文件、指向哪一块实体展板，从而无法像真人助手一样基于现场情境做出自然的指示和补充。

💡 改善思路和目标

以往产品经理最主要的工作就是设计易学易用的界面和操作动线。而在 AI 加持下，用户不需要再学习软件的交互界面和操作逻辑，AI 有能力根据用户的问题和指令只提供给用户用户必要的信息，用户也只需要做最少的介入操作。

但是只要用户本人介入，就存在交互友好性、准确性和效率的问题。Interactive Conversation Protocol 正是在人机接触时发挥作用：

增强自然语言的意义表现力（人 → AI）

这里说增强意义的表现力，指的是针对自然语言做增强。弥补以上提到的问题（光标指示的缺失、信息碎片泛滥和不同终端的人机界面的差异）。至少可以对原始自然语言做以下加工：

• 针对表述信息做标记：在需要做特别处理的信息上做标记，这里所说的特别处理包括采用结构化信息、组装界面、运行辅助程序等等。你可以想象成在一段文字上通过圈点来做笔记。标记的形式上我们参考 Markdown，使用特殊的字符表示特定含义，而辅助功能的解释和触发参考 Java 开发中的注解原理。通过这种方式，我们可以在原有的阐述性内容中补充说话的语气、指出什么是重点、什么需要特殊的展现形式、什么需要做前置操作（如认证是本人才可见）。

  例如，用户说"帮我整理下这周的待办"，在句子里对日期、优先级、负责人做轻量标记，AI 就可以直接生成一个可勾选的待办清单，而不是只返回一段描述性的文字。

• 增加语境信息：将必要的虚拟的信息和现实环境补充到叙述的信息中，以便于重现说话者的真实处境。传统的交互界面，往往在界面中预置了可选的上下文信息，以便于从用户简单的点击中就能捕获用户的准确意图，而自然语言如果要完整地描述上下文需要组织冗长的文字。通过在协议中补充时间、地点、设备状态、参与者身份等语境信息，AI 可以更精准地理解"此时此地"的真实语义。

  例如，用户只说"在附近订一家Marry喜欢的餐厅"，则补充定位、预算偏好和历史订单等作为语境信息。语境信息的应用很广泛，我们之后还会专门就场景进行讨论。

• 转译成标准中间语言：在对原始信息加工后（添加了注解和语境信息）后，为了能够完整且准确地进行解读，必然需要一个约定好的数据标识系统。为了适应所有终端的表现力，这个标识系统可以建立在 JSON 的规范上，提供约定好的参数表和结构体。这样以来，各个接收端的 AI 可以调动所有可用的终端展现最大化的表现力，重现表达者的完整意义。

  例如，一句"把这段话发给项目群并让大家在今天下班前确认"最终被转译成一个包含消息体、接收人列表、截止时间、确认按钮配置的标准 JSON 结构，聊天工具、Web 后台或移动 App 都可以据此渲染出各自适配的界面。

按需定制界面（AI → 人）

我们的前提是人们会更喜欢通过"说"与AI交互，这是最接近于人的沟通方式。因此，人们会越来越觉得通过点击寻找自己需要的功能界面太麻烦。而人们需要的信息也好，界面也好都是应该被直接推到用户"眼前"。为了有这样的效果，在接收端应该有一定的解读能力：

• 解读中间语言：由于中间语言是 JSON 格式，所有接收端都可以读取到完整的语义，至少不会在信息接收上产生断层。

  例如，同一份"报销单审核请求"的中间语言数据，桌面端可以渲染为带有表格和附件预览的大屏界面，手机端只展示关键信息和两个按钮（通过/退回），而智能音箱可以用语音念出摘要并等待语音确认。

• 动态构建消息界面：根据完整的语境和注解，选择交互最为友好的方案，动态地拼装一个有信息层次的交互界面（当然也可以忽略与终端不适配的注解）。这个界面不一定是只读的多模态信息，也可以是一个可以交互的小程序体。

  例如，当 AI 理解到"这是一次信息收集"时，可以自动在聊天界面中插入一个可填写的小表单卡片，而不是让用户在纯文本中逐条回答问题。

• 重现语境：有能力指示或支配语境中的一些元素。这通常需要调动多个应用或终端设备。我们已经看到，可以通过眼镜上的摄像头重现第一视角，通过伴飞无人机充当第三视角，利用投影或者 VR 图标指向实物上的某个位置……等等。

  例如，在远程设备维修场景中，AI 可以一边在工程师眼前的 AR 视野中高亮需要拆卸的螺丝位置，一边在大屏上同步显示电路图和步骤说明，让"语境"在多个终端之间被共同重现出来。

❗️❗️ 特别说明：中间语言真的必要么

很多人都认为其实不需要中间语言，一般有两个理由：

（1）长远来看，AGI 有"察言观色"的能力，然后理解用户的隐含意图。并不需要为了让 AI 更好地理解，人为地对自然语言做多余的加工。

（2）设计对人友好的交互界面未来也是 AGI 的本分，甚至在每一次互动中 AI 都可能会针对性设计一个可运行的交互界面。因此，更加不需要把 AI 的话再翻译成某个中间语言。

我们最终仍然在 iFay 的体系中设计了 ICP 协议，我们有以下 3 个顾虑，并且认为短期内很难解决，因而选择设计一个注解式的中间语言：

（1）AI 对环境的掌控力没那么大

一般人会把人跟 AI 的交互类比为一个人跟助理的沟通。认为一个聪明的助理会为了达到好的沟通效果主动调整环境的条件，比如光线不够的时候会主动打开灯；在文件重要的地方做记号。但是助理的权限和能力并不总是可以做所有事，比如大楼突然停电了，没办法播放演示文稿。

因此，一个更稳妥的做法是准备好所有的必要资料，展示的事随机应变（或者说交给物业的管理者）。这就像我们带上所有资料去见客户，至于客户有没有会议室，能不能播放演示文稿，还是要看纸质报告，由对方决定。

（2）AI 跟人可能没那么亲近

因为 AI 对环境掌控力有限，以至于 AI 在很多情况下实际上并没有真的读懂人的意思。就好像你指着幻灯片上的一组数据问 AI："这数据是什么意思？" 其实 AI 并不知道你指在哪里。理想状况下，这个时候就需要动作捕捉设备将这个信息告诉 AI。你还可以想象另一个场景，老板开闭门会议，开完后跟助理说："跟进一下会议决议。" 这时候助理实际上并没有获得第一手信息，而是经过会议记录员整理的会议纪要。会议纪要就类似中间语言加工后的信息。

因此，很多时候人明示的信息本身就不足以做判断。这个时候就需要补充语境的信息，但这并不是某个特定 AI 的职权。

（3）可能根本就没有万能的 AGI

未来 AI 一定会遇到跟人类社会一样的分工问题。会存在个体的 AI（类似 iFay），也会存在具有社会公共职能的 AI（类似 coFay）。他们之间必然会产生权限边界。

我们很难预测在未来的 AI 生态里，AI 的职责是仅对提供的（系统输入的）信息做处理，还是 AI 也要负责主动的去收集更多的"言外之意"。

所以我们选择稳妥的做法，我们假设 AI 只对已获知的信息做处理。只不过这个信息每次都走一个加工流程，这个加工动作可能是某个软件、终端设备或者 AI 完成的。这也是现在工程技术方案中很成熟的做法，比如使用浏览器访问网站，服务端能够获知一部分用户的上下文信息。

🌟 愿景

ICP（Interactive Conversation Protocol） 旨在构建一种跨人机的中间语言形态，实现人机之间的高效、准确、丰富的双向沟通：

人 → 机器：全面复刻表达意义和语境

• 尽可能全面地捕获人表达的意义和语境
• 将自然语言和交互意图转化为机器可准确理解的结构化要素
• 保留交互的精准性和上下文信息

机器 → 人：动态组装可交互方式

• 将概念注解与当前语境融合
• 根据设备能力和用户偏好，动态组装最适合的交互方式
• 支持多知觉信息呈现（文本、语音、视觉、触觉、嗅觉等）