首页/ 信息优化方案

# 📊 信息优化方案

基于全部项目文档的交叉分析，汇总优化建议并制定可执行方案

## 执行概要

#### 核心发现：文档完善但范围过大，需要聚焦

当前 9 份文档覆盖了架构、能力（36 MCP Tool）、5 阶段路线图（28 周）、55 个开发任务、安全分析、维护优化和 PM 审查。 核心问题：计划覆盖 10 大类能力 × 4 个平台 × 远程桌面 × AI 操控 = 个人开发者 2-3 年工作量。
PM 审查明确建议：Phase 1 严格控制范围，只做「通过聊天通道控制一台 Windows 设备」（2 周 MVP）。 远程桌面、Android、AI 操控全部推到后续阶段。

## 跨文档问题汇总

以下问题在 maintenance、pm-review、security 三份文档中被反复提及，按严重程度排列。

# | 问题 | 来源 | 严重度 | 影响
--- | --- | --- | --- | ---
1 | 范围过大 — 36 Tool × 4 平台 × 远程桌面 × AI 操控 | PM 审查 P0 | 致命 | 28 周计划不可行，个人开发者需要 2-3 年
2 | 无测试策略 — 36 MCP Tool × 多平台无任何测试 | 维护 P0 | 致命 | 回归问题无法发现，质量无保障
3 | 无错误恢复 — 网络断开/Gateway 重启/设备休眠无处理 | 维护 P0 | 致命 | 远程场景下错误是常态，无恢复则不可用
4 | 无用户验证 — 设计大量功能但未验证用户需求 | PM 审查 P0 | 致命 | 可能做了没人用的功能
5 | 外部依赖风险 — OpenClaw 是核心依赖，API 可能变更 | PM 审查 P0 | 致命 | OpenClaw 变更可能导致全部重写
6 | 跨平台 UI 自动化 — 三套 API 各平台独立实现 | 维护 P0 / 安全分析 | 严重 | AI 操控能力开发成本极高
7 | 无日志与可观测性 — 远程设备出问题无法排查 | 维护 P1 | 严重 | 远程调试黑盒，运维困难
8 | 无配置管理 — 客户端配置无统一方案 | 维护 P1 | 严重 | 多设备配置混乱
9 | 无 CI/CD — 手动打包多平台耗时易错 | 维护 P1 | 严重 | 发布效率低，容易出错
10 | 无里程碑验收标准 — 没有明确的"完成"定义 | PM 审查 P1 | 严重 | 进度无法衡量

## 安全风险摘要

#### 🔴 命令注入

exec MCP Tool 暴露命令执行，AI 被 prompt injection 可能执行恶意命令。缓解：allowlist + approval + 沙箱。

#### 🔴 未授权远程桌面

屏幕推流 + 键鼠直通 = 完全控制。缓解：Gateway auth token + Tailscale 加密 + 被控端确认。

#### 🔴 Prompt Injection

不受信内容携带恶意指令操纵 AI。缓解：旗舰模型 + reader agent 预处理 + approval。

## 文档层面优化（本次已实施）

优化项 | 状态 | 说明
--- | --- | ---
flow/index.html CSS 路径修复 | ✅ 已完成 | style.css → ../style.css，与其他子页面一致
flow/index.html 导航链接修复 | ✅ 已完成 | 所有链接添加 ../ 前缀，与其他页面一致
新建信息优化方案页面 | ✅ 已完成 | 本页面，汇总所有跨文档优化建议
文档迁移到 VitePress | P2 后续 | 手写 HTML → Markdown + VitePress，改样式一次生效（已在 maintenance 中标记）

## 建议行动计划

### 🔴 立即行动（本周）

#### 1. 采纳 PM 审查建议：砍范围

将 roadmap Phase 1 从 4 周缩减为 2 周 MVP：只做 exec + file_list 两个 Tool，只支持 Windows，只通过 Telegram 通道。

⏱ 预计 2 小时（改文档）

#### 2. 定义 Phase 1 验收标准

Telegram 发 "dir C:\Users" → 收到目录列表。只有这一个验收用例通过才算 Phase 1 完成。

⏱ 预计 30 分钟

### 🟡 短期行动（Phase 1 开发中）

#### 3. 加入错误恢复

WS 自动重连（指数退避 1s→2s→4s→...→60s）、请求超时 + 重试（已在架构文档中规划，需在代码中落实）。

⏱ 随开发进行

#### 4. 加入基础日志

用 pino 做结构化日志，客户端日志通过 WS 上报 Gateway（已在 maintenance 中规划）。

⏱ 随开发进行

#### 5. 锁定 OpenClaw 版本

在 package.json 锁定 OpenClaw 版本号，所有交互封装在适配层（PM 审查建议）。

⏱ 开发第一天

### 🔵 中期行动（Phase 1 完成后）

#### 6. 用户验证

Phase 1 交付后自己用 2 周，记录哪些功能真正用到。根据实际使用调整 Phase 2 优先级。

⏱ Phase 1 + 2 周

#### 7. 搭建 CI/CD

GitHub Actions：push tag → 自动构建 Windows + Linux。Tauri updater 自动更新。

⏱ Phase 2 初期

#### 8. 文档迁移到 VitePress

将 9 个手写 HTML 页面迁移为 Markdown，使用 VitePress 构建。改样式一次生效，支持搜索。

⏱ Phase 2 期间

## MVP 范围对比

当前 Plan（范围过大） Phase 1（4 周）：10 个 MCP Tool
Phase 2（6 周）：Android + 远程控制
Phase 3（6 周）：桌面客户端 + AI 操控
Phase 4（6 周）：IoT + 智能家居
Phase 5（6 周）：安全加固 + 发布
总计：28 周（实际需 2-3 年）
→
建议 MVP 路径 Phase 1（2 周）：2 个 Tool + Windows + Telegram
Phase 2（4 周）：扩展到 10 个 Tool + 多通道
Phase 3（6 周）：多设备 + CLI 客户端
之后：根据用户反馈决定优先级
总计：12 周拿到可用产品

## 关键结论

#### ✅ 架构设计合理

OpenClaw Gateway + MCP Server 客户端 的架构是可行的。安全分析确认整体可行，风险可控。

#### ✅ 文档覆盖全面

9 份文档覆盖了架构、能力、路线图、安全、维护、PM 审查，对个人项目来说文档质量很高。

#### ❌ 范围必须砍

当前 5 阶段 28 周计划对个人开发者不现实。采纳 PM 审查建议，Phase 1 只做最小 MVP。

#### ❌ 先验证再扩展

没有用户验证的前提下设计大量功能是危险的。Phase 1 交付后必须先自己使用验证。