跳到主要内容

AI 与自动化：把增强能力放在内容之上

一、AI 不是主数据模型​

Folo 的 AI 能力出现在摘要、翻译、AI Chat、推荐和部分应用工具里，但数据库和 UI 仍以 Feed/Entry/用户操作为主。这个顺序很重要：AI 是对内容的派生解释，不应成为阅读产品唯一的真相来源。

二、AI Chat 的本地数据模型​

数据库包含 ai_chat_sessions 和 ai_chat_messages：

  • Session 有 chatId、标题、创建/更新时间、是否本地；
  • Message 有 role、status、finishedAt、metadata、messageParts；
  • messageParts 保存 UIMessage 的复杂分片，可表达工具调用、reasoning 和富文本；
  • message 按 chat、创建时间和状态建立索引。

它不是简单的 messages: string[]，因为流式响应有生命周期：pending → streaming → completed/error。把状态和 parts 持久化，才能在应用重启后恢复部分对话或诊断失败。

三、流式 AI 的控制流​

与普通请求相比，流式 AI 需要处理取消、页面切换、重复提交、网络断开和部分结果。把消息状态写入 Store/DB，可以让这些状态不被某个 React 组件的生命周期吞掉。

四、摘要与翻译的产品化路线​

摘要/翻译都可以抽象成同一条任务链：

  1. 读取 Entry 原文或 Readability 正文；
  2. 选择目标语言和用户/服务配置；
  3. 调用 AI/服务端；
  4. 解析结构化结果；
  5. 按 entryId + language 写入本地缓存；
  6. 更新 UI，并允许失败回退。

如果未来要增加“改写”“关键点”“问答”，最好延续这种“能力 + 版本化缓存”的模型，而不是在 Entry 表继续添加越来越多的 nullable 字段。

五、AI 工具与权限​

Renderer package 以 devDependency 形式接入 @folo-services/ai-tools，说明部分 AI 工具可能在应用开发/构建边界中按需挂载。工具执行必须明确：

  • 工具是本地只读，还是会产生远端副作用；
  • 能否接触用户私有订阅、未读和账户信息；
  • 结果是否可以持久化；
  • 用户是否能取消、重试或删除。

对于 AI，最危险的不是模型回答错误，而是模型拥有不透明的副作用。权限、工具名和结果状态应沿用 Folo 原有的 Store/Action/认证边界，而不是在 prompt 中“约定”安全。

六、自动化不等于后台脚本​

Folo 的后台能力还包括推送、播放器、OTA、同步和通知。它们有共同特征：运行时间可能超过一个页面，且需要在前台/后台、网络变化、账号切换时继续工作。

适合的结构是：

触发器（用户动作 / 定时 / 推送 / 生命周期）
  -> controller/service
  -> Store action + durable record
  -> UI selector / notification / retry

不要让自动化直接操作组件 state，否则应用切后台或页面卸载时，任务没有可观察的状态。

七、AI 设计的四条原则​

  • 可降级：没有 AI 结果时仍能阅读原文；
  • 可追踪：保留 pending/streaming/error 和 trace 信息；
  • 可复现：记录语言、输入来源和必要的模型/版本元数据；
  • 可撤销：工具副作用通过明确的 Action 和权限执行。