work-ally 0.2.0-alpha.1

package/docs/planning/SPEC-user-barrier-reduction-and-activation.md

@@ -0,0 +1,832 @@
+# User Barrier Reduction And Activation
+
+更新时间：2026-03-14  
+状态：Draft / Ready for discussion
+
+## 1. 这份 spec 在解决什么
+
+这份 spec 解决的不是某一个按钮、某一份文档、某一个接入点。
+
+它要解决的是一个更上位的问题：
+
+> `work-ally` 如何从“工程上已经能用”进化到“普通内部同事也能低成本理解、低成本启动、低成本获得第一次真实价值”的产品。
+
+换句话说，这份 spec 要把三件事一次性捋清楚：
+
+1. **是什么**：我们要优化的不是单点功能，而是整条用户体验链路
+2. **为什么**：当前真正阻塞内部推广的，不是能力不足，而是门槛过高
+3. **如何做**：围绕主路径，把入口承接、首次激活、状态理解、失败恢复收成一个统一方案
+
+这份文档是这条专项的**唯一主 spec**。
+
+桌面控制、飞书接入闭环、配套文档合同，都应被视为这份主 spec 的章节，不再拆成平级主线文档。
+
+## 2. 金字塔式结论
+
+先给结论。
+
+### 2.1 总判断
+
+`work-ally` 当前已经完成了大部分**能力层**，但还没有完成足够强的**激活层**、**理解层**与**信任层**。
+
+因此，当前降低使用门槛的真正重点不是继续堆新能力，而是：
+
+1. 让用户更快进入正确上下文
+2. 让用户更快走到第一次真实价值
+3. 让用户在失败时知道卡在哪里、下一步做什么
+4. 让日常使用不再要求用户记住内部概念和命令语义
+
+### 2.2 对优先级的影响
+
+如果站在“降低用户使用门槛”的目标上看，当前最重要的不是功能面再扩，而是三条主线：
+
+1. **桌面控制壳**：吃掉命令行、cwd、项目作用域这些理解成本
+2. **用户准入闭环**：吃掉从零到首次可用之间的外部准备与回填成本
+3. **状态与异常透明化**：吃掉“我不知道现在发生了什么”的不确定成本
+
+### 2.3 Feishu 只是其中一个重要子问题
+
+飞书应用申请、机器人开通、权限配置、发布与凭据回填，确实是一个重要门槛。
+
+但它只是“用户准入闭环”里的一个子问题，不等于整个专项。
+
+更准确的定义是：
+
+> 我们要系统性降低用户从“知道这个产品”到“稳定用起来”之间的学习成本、切换成本和诊断成本。
+
+## 3. 第一性原理
+
+### 3.1 用户真正想买的不是命令，也不是架构
+
+用户并不是为了学习这些东西而来：
+
+- `ally setup`
+- `ally start`
+- current working directory
+- assistant desk
+- runtime host
+- 飞书开放平台
+- allowlist
+- supervisor
+
+用户真正想完成的任务只有一句话：
+
+> 让一个可信的 assistant 在我的项目语境里稳定开始干活，并且我能随时看懂它的当前状态。
+
+### 3.2 所有不直接服务这句话的理解成本，默认都应由产品吸收
+
+如果用户为了达成上面那句话，不得不先学习一堆中间概念，那说明产品还没有把复杂性吃干净。
+
+这并不意味着内部不允许复杂。
+
+它意味着：
+
+- 内部可以有 desk、registry、runtime、bridge、channel lock
+- 但外部默认不应要求用户先理解这些概念，才能开始获得价值
+
+### 3.3 低门槛产品的本质不是“功能少”，而是“价值近”
+
+一个产品是否低门槛，不取决于它有多少功能，而取决于：
+
+- 用户离第一次价值有多远
+- 每一步是否都可理解
+- 用户是否知道下一步
+- 出错时是否知道回哪一层修
+
+## 4. 我们用什么方法看这个问题
+
+这条 spec 默认结合四套方法一起判断。
+
+### 4.1 第一性原理
+
+先问：
+
+- 用户真正想完成什么任务
+- 哪些步骤只是系统偶然性，而不是用户目标的一部分
+- 哪些复杂性必须存在，哪些复杂性只是没有被产品吸收
+
+### 4.2 系统思维
+
+把用户使用门槛拆成一个完整系统，而不是只看某个表层抱怨。
+
+门槛往往来自四类环节叠加：
+
+1. 准入
+2. 激活
+3. 日常使用
+4. 失败恢复
+
+只优化其中一层，不足以真正降低门槛。
+
+### 4.3 JTBD
+
+我们不按功能看，而按任务看。
+
+用户不是“想配置一个 assistant”；用户是：
+
+- 想把项目接上一个可工作的助手
+- 想让这个助手在飞书里能被自己随时叫到
+- 想在状态不正常时知道问题出在哪里
+- 想在日常使用时不要被内部概念打断
+
+### 4.4 金字塔原理
+
+先收最高层结论，再回到支撑结构。
+
+所以这份 spec 先回答三件事：
+
+1. **我们已经做了什么**
+2. **还需要做什么**
+3. **我们应当做什么**
+
+然后再把每个结论展开成：
+
+- 用户问题
+- 产品动作
+- 结果判断
+- 验收口径
+
+## 5. 业界方法给我们的启发
+
+### 5.1 onboarding 不应优化为“完成教程”，而应优化为“到达价值”
+
+如果 onboarding 完成了，但用户还没获得真实价值，那只是流程做完了，不代表产品真的被激活。
+
+套到 `work-ally` 上，意味着：
+
+- “用户填完配置”不等于成功
+- “桌面端向导走完”不等于成功
+- 真正成功是：用户已经在自己的项目语境里，和 assistant 完成第一轮真实可用对话
+
+### 5.2 time-to-value 要尽可能短
+
+对 `work-ally` 来说，应该追求的不是“教程讲得很全”，而是：
+
+- 用户最快多久能发出第一条有效消息
+- 用户最快多久能拿到第一条真正有帮助的回复
+
+### 5.3 checklist 必须围绕结果，而不是围绕功能罗列
+
+一个好的 checklist 应该帮助用户回答：
+
+- 我现在做到哪一步了
+- 下一步最重要的是什么
+- 完成后我会得到什么结果
+
+### 5.4 progressive disclosure 是必要原则
+
+用户第一屏只应该看到完成当前任务所必需的信息。
+
+更深的解释、日志、内部状态、可选配置应在需要时再展开。
+
+## 6. 用户与使用场景
+
+### 6.1 第一优先级用户
+
+- 内部同事
+- 不熟命令行
+- 不理解 `work-ally` 内部架构
+- 希望快速体验一个“可工作的项目助手”
+
+### 6.2 第二优先级用户
+
+- 产品同事 / 管理者
+- 需要演示、验收、判断当前项目能否正常使用
+- 希望快速看懂“现在是什么状态，下一步是什么”
+
+### 6.3 第三优先级用户
+
+- 工程同事
+- 需要联调、排障、理解更深一层状态
+- 仍会保留 CLI 与日志等能力
+
+### 6.4 关键使用场景
+
+1. **首次体验**
+   - 用户第一次把某个项目接入 `work-ally`
+2. **日常进入**
+   - 用户再次打开某个项目，想快速知道是否可用
+3. **基础管理**
+   - 用户想换 assistant、改 persona、看绑定关系
+4. **异常恢复**
+   - 用户发现“它没反应”或“启动失败”，需要知道回哪一层修
+
+## 7. 当前用户门槛到底高在哪
+
+从用户视角看，今天的主要门槛不是单一问题，而是五类成本叠加。
+
+### 7.1 理解成本
+
+用户要先理解：
+
+- 为什么要先选项目
+- 为什么项目和 assistant 是绑定关系
+- 为什么必须在某个目录里执行命令
+- 为什么需要飞书应用与机器人
+- 为什么 `ally start` 失败不一定是本地代码问题
+
+### 7.2 操作成本
+
+用户当前仍要承担一些偏工程化动作：
+
+- 进入正确目录
+- 记住 setup/start/status/logs 的语义
+- 手工打开配置文件回填凭据
+- 自己判断某一步是不是已经完成
+
+### 7.3 上下文切换成本
+
+用户会在多个系统之间来回切换：
+
+- 项目目录
+- 命令行
+- 飞书开放平台
+- 飞书聊天窗口
+- 文档/排障说明
+
+产品还没有把这些切换收成一条顺滑路径。
+
+### 7.4 诊断成本
+
+失败时用户仍然容易问：
+
+- 是我没配对吗
+- 是飞书没准备好吗
+- 是权限不够吗
+- 是应用没发布吗
+- 是 runtime 没起来吗
+- 是群聊本来就没开通吗
+
+### 7.5 信任成本
+
+如果用户不知道当前到底：
+
+- 正在运行
+- 正在等待他
+- 已经失败
+- 已经恢复
+- 其实已经结束
+
+那他就很难真正信任这个产品。
+
+## 8. 我们已经做了什么
+
+### 8.1 能力层已经很强
+
+我们已经有：
+
+- assistant desk 模型
+- 项目绑定 assistant
+- `ally setup / start / stop / status / logs`
+- Feishu 私聊主闭环
+- 最小群聊显式触发
+- runtime 托管与恢复
+- nightly memory digest
+- 基础排障、状态、日志能力
+
+这意味着问题已经不是“产品还不能用”。
+
+### 8.2 一部分信任层已经开始建立
+
+我们已经做了几件很关键的事：
+
+- `ally start` 会对飞书发消息能力做探测
+- 当入口不可用时，不再假装启动成功
+- 处理中、等待审批、等待补充、任务结束等语义开始可见
+- 排障文档已经能区分部分失败类型
+
+### 8.3 一部分复杂性已经被中间层吃掉
+
+例如：
+
+- runtime 端口自动管理
+- trusted scope 自动收敛
+- assistant desk 自动初始化
+- 一部分审批噪音已经开始收敛
+
+### 8.4 已经做出的正确产品判断
+
+1. `ally start` 要诚实失败，不能假装启动成功
+2. 命令行不能继续被视为普通同事的默认主入口
+3. 用户不应被迫学习 `work-ally` 的内部实现概念
+4. 中间层必须继续吃掉复杂性，而不是把复杂性直接抛给用户
+
+## 9. 还需要做什么
+
+### 9.1 缺激活层
+
+我们还没有一条足够完整的“从零到首次可用”路径。
+
+用户需要的其实是一条 activation chain：
+
+1. 选项目
+2. 准备外部入口
+3. 回填必要信息
+4. 验证能否启动
+5. 完成第一次真实对话
+
+### 9.2 缺理解层
+
+用户仍需要自己建立很多内部心智模型。
+
+比如：
+
+- “项目作用域”该怎么理解
+- “绑定 assistant”对自己意味着什么
+- “persona 管理”该去哪里做
+- “当前不可用”属于系统状态还是配置没完成
+
+### 9.3 缺恢复层
+
+用户失败后还不够容易回到正确步骤。
+
+### 9.4 缺统一的主路径设计
+
+现在很多材料都是分散正确，但没有组成统一主路径。
+
+表现为：
+
+- 文档各自正确，但入口顺序不清晰
+- 状态有了，但没有统一承接面
+- 快速开始、排障、飞书外部步骤之间缺少合同
+
+## 10. 我们应当做什么
+
+这里不是松散 backlog，而是明确的产品行动主线。
+
+### 10.1 第一主线：把桌面控制壳做成“主承接面”
+
+桌面控制壳的价值，不是“把命令换成按钮”。
+
+它真正的职责是：
+
+- 让用户先选项目，再进入正确上下文
+- 让用户看见当前绑定关系与当前状态
+- 让 setup、回填、启动、状态、基础管理形成连续面
+- 让用户不需要先理解 cwd、命令和内部目录
+
+### 10.2 第二主线：把准入闭环正式产品化
+
+我们需要把：
+
+- 外部平台准备
+- 配套文档
+- 凭据回填
+- 本地验证
+- 失败归因
+
+串成单一路径。
+
+### 10.3 第三主线：把状态和异常语义继续收紧
+
+因此需要继续推进：
+
+- session presence / state visibility
+- middleware exception visibility
+- supervised start boundary
+- approval autonomy / safe defaults
+
+### 10.4 第四主线：重新组织产品文档分工
+
+更合理的分工应是：
+
+- quickstart：从已具备最小前提开始讲
+- 配套文档：讲外部平台如何准备
+- 排障文档：讲异常分支如何修
+- 桌面端：讲现在卡在哪、下一步做什么
+
+## 11. 用户生命周期视角下的完整闭环
+
+完整生命周期至少应分六段。
+
+### 11.1 Discover
+
+用户知道这个产品能做什么。
+
+### 11.2 Prepare
+
+用户准备外部条件与本地条件。
+
+### 11.3 Connect
+
+用户选项目、绑 assistant、回填凭据。
+
+### 11.4 Validate
+
+系统验证能否真正工作。
+
+### 11.5 Use
+
+用户进入日常使用。
+
+### 11.6 Recover
+
+用户在异常时恢复。
+
+## 12. 产品行动框架
+
+### 12.1 主线一：入口承接
+
+用户问题：
+
+- 我应该从哪里开始
+- 我现在操作的是哪个项目
+- 我不想先学命令行
+
+产品动作：
+
+- 提供桌面控制壳作为普通用户默认入口
+- 首屏明确以“项目”为主上下文，而不是以命令或目录为主
+- 最近项目、绑定关系、运行状态必须一眼可见
+
+结果判断：
+
+- 用户能在 10 秒内知道自己应该进哪个项目
+- 用户不需要先理解 cwd 与 CLI 语义
+
+### 12.2 主线二：首次激活
+
+用户问题：
+
+- 我离第一次可用还差什么
+- 我应该先去哪里做外部准备
+- 做完之后回到哪里继续
+
+产品动作：
+
+- 提供准入 checklist
+- 明确外部平台文档入口
+- 提供凭据回填入口与验证动作
+- 把失败归因回落到具体步骤
+
+结果判断：
+
+- 用户能在首次路径里完成从外部准备到本地启动的闭环
+- 工程同学不需要大量陪跑首次体验
+
+### 12.3 主线三：日常可见
+
+用户问题：
+
+- 现在能不能用
+- 正在运行还是已经停了
+- 这个项目现在绑定的是谁
+
+产品动作：
+
+- 首页和项目页都必须先给“结论态”
+- 状态要先说是否可用，再允许用户下钻细节
+- persona、绑定、运行控制要形成最小连续面
+
+### 12.4 主线四：失败恢复
+
+用户问题：
+
+- 为什么失败
+- 我要回到哪一步修
+- 修完后怎么重新验证
+
+产品动作：
+
+- 建立失败类型到下一步动作的映射
+- 在桌面端直接展示阻塞原因与建议动作
+- 排障文档只承接更深层解释，不承担首层归因责任
+
+### 12.5 主线五：信任建立
+
+用户问题：
+
+- 它现在是在干活、在等我，还是已经挂了
+- 刚才那条消息到底有没有被处理
+
+产品动作：
+
+- 继续收紧 session presence、异常透明化、恢复语义
+- 中间层不允许再出现“内部知道，用户无感”的异常路径
+- 审批和等待都要变成显式状态，而不是靠用户猜
+
+## 13. 主线一：桌面控制壳
+
+### 13.1 是什么
+
+一个围绕“项目选择 -> assistant 绑定 -> 运行状态 -> 最小管理”设计的本地轻量控制壳。
+
+### 13.2 为什么做
+
+因为当前命令行、cwd、项目作用域语义，对普通用户仍然是明显门槛。
+
+### 13.3 如何做
+
+桌面端必须承接：
+
+- 选择项目
+- 查看当前绑定 assistant
+- 查看运行状态
+- 提供 setup / start / stop / restart / status / logs 的图形化入口
+- 提供最小 persona 管理入口
+
+同时要坚持边界：
+
+- 它是轻量控制壳，不是厚平台
+- 它包住既有 `ally` 能力，不重写产品内核
+- 首屏优先给结论，再允许下钻
+
+## 14. 主线二：用户准入闭环
+
+### 14.1 是什么
+
+一条把“外部平台准备”与“本地 assistant 启动验证”串成单一路径的 activation 闭环。
+
+### 14.2 为什么做
+
+因为真正阻塞首次体验的，不只是本地 setup，还有更早的一段外部准备路径。
+
+### 14.3 如何做
+
+这条闭环应被明确拆成四层：
+
+1. `资格与前提`
+   - 这个人能不能开始，是否需要管理员协作
+2. `外部平台准备`
+   - 应用、机器人、权限、事件、发布、可用范围
+3. `本地回填与启动`
+   - 项目选择、assistant 绑定、凭据回填、验证启动
+4. `验证与恢复`
+   - 失败归因到飞书侧还是本地侧，并给出下一步
+
+### 14.4 桌面端需要承接什么
+
+1. 识别一个项目是否已经完成最小准入
+2. 用清晰状态展示当前卡在哪一层
+3. 给出外部平台文档入口
+4. 提供回填位置
+5. 提供“验证并启动”动作
+6. 在失败时展示明确归因与下一步
+
+## 15. 主线二的状态模型
+
+如果没有清晰状态模型，桌面端就会只剩一堆按钮和文本。
+
+### 15.1 建议的高层状态
+
+1. `not_started`
+2. `needs_external_setup`
+3. `waiting_for_credentials`
+4. `ready_to_validate`
+5. `blocked_by_feishu`
+6. `blocked_locally`
+7. `activated`
+
+### 15.2 每个状态必须回答的三个问题
+
+1. 现在处于什么阶段
+2. 下一步该做什么
+3. 完成后会得到什么结果
+
+### 15.3 不应直接暴露给普通用户的低层状态
+
+这些状态可以存在于实现层，但不应直接变成用户首层文案：
+
+- websocket closed
+- sdk reconnecting
+- channel lock pending
+- supervisor pid changed
+
+## 16. 主线二的外部平台闭环
+
+这里先用“外部平台”做总称，当前最关键的实例是飞书。
+
+### 16.1 用户视角的真实任务
+
+1. 我想选一个项目开始试用 `work-ally`
+2. 我想知道这个项目当前是否已经具备外部入口
+3. 如果没有，我想知道应该去外部平台做什么
+4. 我想完成应用、机器人、权限、事件相关配置
+5. 我想把必要信息带回桌面端工具里
+6. 我想一键验证当前配置是否足够启动
+7. 如果失败，我想知道具体卡在哪一步
+8. 如果成功，我想立刻进入首次对话体验
+
+### 16.2 飞书是当前最关键的实例
+
+飞书侧至少要覆盖：
+
+- 创建企业自建应用
+- 开启机器人能力
+- 配置最小必要权限
+- 配置消息接收 / 事件相关能力
+- 完成发布、审核、可用范围设置
+- 取得 `App ID / App Secret`
+
+### 16.3 `ally start` 的边界必须保留
+
+如果飞书就是对外入口，而应用还不能发消息，那么它就不应被宣称为“已启动”。
+
+所以准入闭环不是放松门槛，而是把门槛解释清楚、前置可见、失败可恢复。
+
+## 17. 主线二的配套文档合同
+
+外部平台闭环不能只靠桌面端，必须有一份配套文档承接外部动作。
+
+### 17.1 这份文档的职责
+
+它不是开放平台百科，而是一张操作地图。
+
+它必须回答：
+
+1. 我现在为什么要做这件事
+2. 我自己能不能做，还是要找管理员
+3. 如果我自己能做，第一步去哪里
+4. 如果我不能做，应该把什么发给管理员
+5. 做完后我需要带回 `work-ally` 的是什么
+6. 如果桌面端报错，我该回文档的哪一段
+
+### 17.2 文档的建议结构
+
+1. 这份文档帮你完成什么
+2. 先判断你走哪条路径
+3. 自助版步骤
+4. 管理员协作版步骤
+5. 桌面端回填说明
+6. 常见阻塞与回跳地图
+
+### 17.3 文档和桌面端的映射合同
+
+如果桌面端要求用户回填：
+
+- `App ID`
+- `App Secret`
+
+那么文档必须明确告诉用户：
+
+- 到哪里拿
+- 如何辨认
+- 回到桌面端填哪个位置
+
+如果桌面端提示：
+
+- 需要完成飞书侧准备
+- 等待回填凭据
+- 飞书应用不可用
+- 本地验证失败
+
+那么文档都必须有明确对应章节。
+
+## 18. 文档分工合同
+
+### 18.1 `docs/user-quickstart.md`
+
+职责：
+
+- 面向已经具备最小前提的用户
+- 从项目接入、本地 setup、启动开始讲
+
+### 18.2 配套文档
+
+职责：
+
+- 解释外部平台准备
+- 说明谁可以自己操作，谁需要管理员协作
+- 告诉用户做完后回填什么
+
+### 18.3 `docs/troubleshooting.md`
+
+职责：
+
+- 承接更深层的异常说明
+- 为已经知道自己卡在哪一层的人提供更深入判断
+
+### 18.4 桌面端
+
+职责：
+
+- 作为主承接面，显示当前卡在哪
+- 给出下一步动作
+- 串联文档、回填、验证与运行状态
+
+## 19. 用户视角的理想主路径
+
+1. 打开产品
+2. 选择或确认目标项目
+3. 看到当前项目是否已经具备 assistant 与渠道入口
+4. 若未具备，系统明确告诉我先做什么
+5. 若需要外部准备，系统给我准确入口和回填目标
+6. 我完成外部准备后，回来填最少信息
+7. 我点击验证并启动
+8. 系统明确告诉我是否已可用
+9. 可用后我立刻进入首次对话
+10. 之后我能随时回来看状态、启动停止、处理异常
+
+## 20. 我们真正应该优化的不是“流程完成率”，而是“首次可用率”
+
+对 `work-ally` 而言，当前更合理的核心指标不是：
+
+- 有多少人看完 quickstart
+- 有多少人填完 config
+- 有多少人点完 setup wizard
+
+而是：
+
+- 有多少人成功完成首次真实对话
+- 从开始到首次真实对话用了多久
+- 卡住的人主要卡在哪一步
+- 卡住后是否知道下一步
+
+## 21. 建议建立的产品衡量口径
+
+### 21.1 北极星口径
+
+`Time to First Usable Reply`
+
+定义：
+
+- 从用户进入产品主路径开始
+- 到 assistant 在目标项目语境里完成第一条真实有用回复为止
+
+### 21.2 辅助口径
+
+1. `Activation Success Rate`
+2. `Blocked Step Distribution`
+3. `Recovery Success Rate`
+4. `Help Dependence Rate`
+
+## 22. 当前建议的产品排序
+
+如果只从“降低用户使用门槛”这个目标来排序，当前建议是：
+
+1. **桌面控制**
+2. **用户准入闭环**
+3. **状态与异常透明化继续收口**
+4. **内部重构**
+5. **Claude 支持**
+
+## 23. V1 应该明确交付什么
+
+1. 一份明确的总 spec，用来指导后续所有“降门槛”子专题
+2. 桌面控制壳承接首次接入、项目选择、状态查看与基础管理
+3. 准入闭环能够覆盖飞书侧准备、回填、验证与阻塞归因
+4. 快速开始文档、外部平台文档、排障文档与桌面端之间形成明确分工
+5. 用户可以在不学习命令行主路径的前提下完成首次可用体验
+
+## 24. 对工程与产品的边界要求
+
+### 24.1 产品必须坚持的边界
+
+1. 不把 CLI 内部模型直接暴露给普通用户
+2. 不为了“灵活”而把主路径重新做复杂
+3. 不因为做 GUI 就重写一套产品内核
+4. 不用抽象报错替代具体下一步
+
+### 24.2 可以留给工程自己决策的部分
+
+1. 桌面端技术栈
+2. 具体组件组织方式
+3. 状态刷新机制
+4. 日志拉取策略
+5. 视觉风格与交互细节
+
+## 25. 验收问题
+
+如果未来要判断这个专项是否真的成立，至少应该问下面这些问题：
+
+1. 一个第一次接触 `work-ally` 的内部同事，是否能在 10 秒内知道自己下一步该做什么
+2. 一个不会命令行的人，是否能在桌面端完成首次接入并走到第一次真实对话
+3. 用户失败时，是否能快速知道问题属于外部平台侧、本地侧，还是运行状态侧
+4. 用户日常使用时，是否还需要记住 cwd、命令和内部目录结构
+5. 工程同学是否明显减少了“远程陪跑首次体验”的人工负担
+
+## 26. 已知边界
+
+### 26.1 这不是“零学习成本”
+
+任何产品都不可能绝对零学习。
+
+### 26.2 这也不是“所有复杂性都做成 GUI”
+
+真正要做的是：
+
+- 把主路径做简单
+- 把高级能力留给需要的人
+- 用 progressive disclosure 保持克制
+
+### 26.3 这不是否定 CLI
+
+CLI 仍然是工程维护者和自动化流程的重要入口。
+
+但它不应继续被当成普通内部同事的默认主入口。
+
+## 27. 待定问题
+
+1. 桌面端第一版是否需要 machine scope 摘要页
+2. 配套文档是否要拆成“自助版”和“管理员协作版”两块明确入口
+3. 私聊首次可用与群聊首次可用是否需要明确分成两条 checklist
+4. 是否需要在桌面端保留一个“复制给管理员”的标准说明模板
+5. 是否需要为首次体验建立最小埋点或人工记录口径
+
+## 28. 最终结论
+
+如果今天从产品视角回答“我们已经做了什么、还需要做什么、应当做什么”，最准确的总结是：
+
+- **我们已经做了什么**：把 `work-ally` 的能力层做得相当扎实，开始建立部分状态语义与信任边界。
+- **我们还需要做什么**：把激活层、理解层、恢复层真正产品化，不再让用户自己拼接主路径。
+- **我们应当做什么**：围绕桌面控制、准入闭环、状态透明化三条主线继续收敛，让产品从“工程上成立”真正走向“普通用户也能低成本用起来”。