产品设计总览

这组文档不是“功能宣传册”，而是 ETOS LLM Studio 的产品设计说明书。

目标很直接：

• 让第一次接触 ETOS 的人，不看 Swift 代码也能知道这个产品到底怎么运作。
• 让已经在用 ETOS 的人，知道哪些能力是显式设计，哪些只是默认策略。
• 让外部协作者能理解 Daily Pulse、记忆、世界书、MCP、快捷指令这些模块之间的边界。

ETOS 不是单纯的聊天壳

ETOS 的核心不是“接一个模型 API 然后把文本显示出来”，而是把下面几件事放进同一个原生客户端里：

• 聊天本身：多提供商、多模型、多模态、请求参数细调。
• 上下文系统：全局提示词、会话话题提示词、增强提示词、长期记忆、跨会话摘要、用户画像、世界书。
• 主动能力：Daily Pulse 会在你还没开口之前，先给出今天值得聊什么。
• 工具能力：内置工具、MCP、快捷指令、Skills、沙盒文件工具统一进入同一套治理逻辑。
• 双端体验：iPhone 负责完整配置与管理，Apple Watch 负责快速访问、提醒和轻量继续聊。

四个设计原则

1. 可解释

ETOS 尽量避免“模型突然变聪明了，但你不知道它看了什么”。

所以它把上下文拆成明确层次：

• 全局提示词负责长期身份与总规则。
• 话题提示词负责当前会话的主题约束。
• 增强提示词负责本轮自动化附加 instruction。
• 记忆、会话摘要、用户画像负责补充长期与跨会话背景。
• 世界书负责规则化、可触发的定向注入。

你可以逐层开关，而不是接受一个黑箱。

2. 主动，但低打扰

Daily Pulse 的目的不是“替代聊天”，而是解决很多人每天打开 App 时根本不知道该问什么的问题。

因此它采用的是：

• 每天一组卡片，而不是无限滚动的信息流。
• 反馈驱动，而不是强制推荐。
• 本地持久化与本地提醒，而不是依赖云端账号推送。
• best-effort 的晨间送达，而不是承诺必达的服务器任务。

3. 工具可控，而不是越多越好

ETOS 不把“工具数量”当卖点，而把“当前会话到底暴露了哪些工具”当成更重要的事情。

工具中心里至少有两层状态：

• 配置上是否启用。
• 这个会话里是否真的可用。

这两个状态经常不同，因为还会受到审批策略、是否被世界书隔离、服务器是否选中用于聊天、单个工具是否被禁用等条件影响。

4. 双端分工，而不是单端移植

iPhone 和 Apple Watch 不是把同一个界面缩放一下。

大致分工是：

• iPhone：提供商配置、工具治理、世界书编辑、记忆管理、导入导出、调试与反馈。
• Watch：查看提醒、快速发起会话、继续 Daily Pulse、语音或短文本输入。

这也是为什么 ETOS 会把很多复杂策略下沉到共享层，而不是写死在某个页面里。

系统结构图

用户输入 / Daily Pulse / 外部工具结果
              │
              ▼
        ChatService 请求编排
              │
    ┌─────────┼─────────┐
    │         │         │
    ▼         ▼         ▼
 提示词层   记忆层    世界书层
    │         │         │
    └─────────┴─────────┘
              │
              ▼
        工具暴露与审批
              │
              ▼
          模型请求发送
              │
              ▼
      响应、摘要、画像、反馈回写

该先读哪一页

• 想知道一条消息发出去前到底拼了哪些东西：读 提示词与上下文拼装
• 想知道 Daily Pulse 为什么能“主动推荐”：读 Daily Pulse 设计原理
• 想知道记忆、会话摘要、用户画像各自负责什么：读 记忆、会话摘要与用户画像
• 想知道世界书为什么会影响工具可用性：读 世界书与工具治理

先讲一个总判断

如果只把 ETOS 当聊天壳来理解，你会觉得很多入口很分散。

但如果把它理解成一个“原生 AI 工作台”，这些设计就会顺很多：

• 聊天页负责执行。
• 设置页负责治理。
• Daily Pulse 负责主动发现。
• 记忆与世界书负责长期上下文。
• 工具中心负责能力暴露和风险控制。