返回首页

关于
FydeOS AI LogoFydeOS LogoAI
是如何诞生的

2023-12-06 22:01:00 | 前端开发 分享创造 

CleanShot 2024-10-07 at 19.24.11@2x.png

0x0 为什么要做这个项目

项目的初衷是为了让用户可以更加自然地控制操作系统，能够使用自然语言与系统进行交互。例如，通过语音或文本与系统对话，控制软件、查找信息，甚至快速解答工作中的各种问题。

我们希望打造一个 AI 助手，能够深入系统，随时响应用户的需求，不论是简单的任务还是复杂的系统操作。这种 AI 驱动的交互方式将使得人们与操作系统的交互更加自然和高效。用户不仅可以进行简单的提问和操作，还可以让 AI 在更复杂的场景中提供支持，例如系统设置和跨应用操作。

CleanShot 2024-10-07 at 19.24.38@2x.png

0x1 路线图

为了实现这一目标，我们制定了几条明确的开发路线：

  • 替代系统内置的搜索条：将传统的搜索框替换为智能助手，提供更加灵活和自然的提问方式，通过语音或文本直接与系统对话，摆脱传统的静态搜索体验。
  • 独立的 AI 应用程序：提供一个独立的 AI 应用，用户可以在其中保存对话历史，进行深入交互，并且可以针对不同的问题进行持续追问，帮助用户记录工作进度和问题的解决方案。
  • CCC（Control + C + C 快捷键）交互集成：实现用户在选中文本或文件后，能够直接交由 AI 处理和提问，配合系统的无障碍功能，实现更直观的交互体验，让用户可以更加高效地完成信息查找和处理。
  • 系统文档和代码的整理与交互：通过将系统文档和源码整合形成知识图谱，利用 AI 来辅助用户理解和操作。这需要进行 RAG（检索增强生成）和 Agent 的开发，使得 AI 不仅能处理用户的直接提问，还能主动建议下一步操作。

0x2 实现步骤

替换系统搜索条

在 MVP 的第一阶段，我们的目标是替换系统的主菜单搜索条。用户可以直接在主菜单内输入自然语言提问，系统会将用户的输入跳转至 AI 界面进行回答（一次性提问），或者用户可以选择打开完整的 AI 应用，进行持续的对话和历史记录保存。在这个阶段， 实际上是一个「套壳 GPT」的 AI 工具，但它已经为用户提供了更智能的搜索体验，使得操作系统的使用更加直观和高效。

CleanShot 2024-10-07 at 19.32.26.png

CCC（Control + C + C）集成与悬浮窗

第二阶段的目标是通过监听用户按下Control + C + C快捷键，将剪贴板中的最新内容直接发送给 AI 处理。在这个阶段，AI 被集成为系统的悬浮窗，使得用户可以随时利用 AI。

CleanShot 2024-10-07 at 19.33.15.gif

在 Chromium OS 中，由于缺乏传统的 X11 窗口系统，无法方便地自定义窗口，这使得实现悬浮窗变得非常困难。然而，我们最终发现可以继承和复用系统剪贴板管理（通过 Search 键 + Q 弹出的浮窗）的代码逻辑来实现悬浮窗，这使得我们能够顺利实现所需的功能。最终，我们选择使用SWA（System Web App）来实现这一功能。SWA 类似于一个独立的浏览器窗口，具有独立的协议（例如 ai-app://），类似于每个 Chromium 浏览器插件都有一个chrome-extension://这样的协议 Url。因此，所有通过这个应用程序打开的窗口在系统看来都是同源的标签页（尽管实际情况更复杂，但这样解释也足够准确）。窗口之间可以通过BroadcastChannel进行通信。而 SWA 应用本身可以通过 C++ 进行逻辑扩展，类似于对 Chromium 进行二次开发，可以将系统原生功能与 JavaScript 交互。

SWA 的逻辑架构如下：

  • SWA 本身主体的更新跟随系统更新（要被编译到系统中），所以我们需要在 SWA 的页面上使用WebView来展示内容，WebView 的内容可以随时更新，以便灵活适应用户的需求和改进用户体验。
  • 系统层面的 SWA 应用，通过 C++ 层逻辑向页面注入 JS-Bridge，使得 SWA 的页面可以直接调用系统功能。
  • SWA 本身的 Web 页面可以通过 WebView 显示独立的 Web 项目，使用 postMessage 与 SWA 进行通信。

在悬浮的工具条中，我们实际上需要两个部分，一个是主输入框，用户可以在其中输入或显示复制的内容或文件。主输入框在识别内容后，会调用不同的功能逻辑，在下方的功能区显示相应的界面。最理想的做法是使用两个 WebView，一个用于主输入框，另一个用于功能区，由 C++ 进行通信和交互。主输入框（实际上就是悬浮窗的主体程序）可以控制下方功能区的生命周期，从而实现更灵活的功能调用和管理。

然而，初期开发时，为了降低成本，我们选择使用一个 WebView，其中包含一个主输入框和一个iframe以实现与用户的交互。主输入框控制整体逻辑，而 iframe 则负责具体的插件调用和内容处理。主输入框和 iframe 之间通过 postMessage 进行通信。我们编写了一个 JS SDK 来提供通信功能，使得 iframe 内的页面也可以调用系统的功能，从而实现系统与插件的紧密结合。通过这种设计，我们能够以较低的开发成本实现基本的功能，同时为后续的扩展奠定基础。

0x3 插件化

CleanShot 2024-10-07 at 19.39.51.png

的核心是插件化架构。所有功能都基于插件开发，每个插件就像一个独立的应用，只是最终在中集成显示。这种插件化的设计使得可以灵活地扩展新功能，用户可以通过插件处理文本、文件等输入。

最理想的插件打包方式是将每个插件打包为一个独立文件，用户只需将文件复制到系统中即可完成安装。然而，由于初期的开发成本限制，我们选择将插件以 PWA 形式进行开发，利用浏览器的缓存和更新机制来保存插件。这样，插件的开发和更新变得更加灵活，同时也减轻了用户安装和使用的复杂度。通过内置的「功能配置」这个插件，用户只需复制插件 URL，系统就会自动识别并开始安装，进一步简化了插件的安装过程。

10

插件的配置信息存储在 PWA 的manifest.json中，并添加了一些额外的属性。例如，一个用于 Base64 编码和解码的部分插件配置如下：

"matches": [
    {
      "name": "Base64 编码",
      "type": "code",
      "content": "*"
    },
    {
      "name": "Base64 解码",
      "type": "regexp",
      "content": "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"
    }
  ]

通过这种配置，主输入框可以在内容变化后自动匹配相应的插件和功能，供用户选择调用。这种动态的匹配机制使得用户的操作体验更加流畅，同时能够有效减少用户在复杂任务中的操作步骤。

0x4 数据存储

数据存储同样采用渐进式策略。我们定义了一套 store 接口，接口中包括 set、get 等方法。在初期版本中，使用localforage（基于IndexedDB）实现这些接口，通过不同的分区模拟轻量级的 NoSQL 数据库，用于存储需要的数据。未来如果可以直接使用本地磁盘进行存储，可以通过实现相同接口无损替换。

数据大致分为以下几部分：

  • 应用设置项：例如用户偏好、API Key 等。
  • 对话记录：保存用户通过 App 进行的对话和插件交互的记录，方便后续查阅。用户可以在任何时候查看这些对话，以便追踪问题的解决进度。
  • 插件安装信息：包括插件的关键字、匹配方式、logo 等。这样，系统可以在用户需要时快速匹配到相应的插件，提升用户体验。
  • 每个插件独立的存储空间：每个插件有单独的存储，用于保存插件内部的配置信息，由 JS SDK 提供存储接口，插件可以自由地使用这些接口进行数据的增删改查。

所有数据都可以进行序列化，并通过的云服务进行同步，用户更换设备后可以快速恢复自己原有的 AI 工具集和配置。这种云同步功能极大提升了用户的体验，使得用户在不同设备间切换时不会丢失自己的偏好和历史数据。

0x5 总结

我们希望从一个简单的搜索条替代品逐渐演进为一个全面集成的智能助手。通过插件化架构和系统级的交互方式，让为用户提供了自然语言的无缝体验。尽管在开发过程中面临了一些技术和成本的限制，但通过系统化的设计和合理的技术取舍，我们实现了 MVP 版本的核心功能，也为未来的扩展打下了坚实的基础。

未来，我们计划进一步丰富的插件生态，使其能够支持更多的场景和需求，例如跨应用的协同操作、对系统设置的深度集成控制以及通过学习用户行为来主动提供建议。我们的最终目标是打造一个真正能够理解用户需求的智能助手，使得 FydeOS 在使用体验上达到新的高度。

0xFFF 展望

在这里附上我们对的想象，看一下我们制作的「Introducing the inaugural AI-native operating system: FydeOS with FydeOS AI.」