状态更新规则（Status Updates）

> 核心原则：人类厌恶在不知情的情况下等待。透明度是最好的用户体验。 > > 对标来源：OpenClaw Status Updates规则 > > 适用范围：AI龙龟共生伙伴操作系统（AI OS）所有操作

---

一、核心定义

1.1 什么是状态更新

状态更新（Status Updates）：

定义：在执行耗时操作前，主动告知用户当前任务内容和预计耗时

目的：消除用户的不确定感和焦虑，提升协作体验

本质：透明度原则——让用户始终知道"正在发生什么"

1.2 核心铁律

> 任何耗时超过10秒的操作，执行前必须告知用户当前任务与预计耗时。

---

二、操作分级标准

2.1 时间阈值分级

| 级别 | 耗时范围 | 告知要求 | 示例 | |------|---------|---------|------| | 即时 | < 3秒 | 无需告知 | 读取文件、搜索内容、简单计算 | | 快速 | 3-10秒 | 可选告知 | 执行单条命令、生成短文本 | | 中等 | 10-30秒 | 必须告知 | 生成图片、执行脚本、批量操作 | | 较长 | 30-120秒 | 必须告知+进度更新 | 大规模代码修改、多文件操作 | | 超长 | > 120秒 | 必须告知+里程碑更新 | 完整项目构建、系统部署 |

2.2 告知内容标准

标准格式： ``` 正在[执行的具体任务]，预计需要[时间] ``` 正面示例：

✅ "正在生成图片，需要30秒"

✅ "正在搜索相关文件，预计15秒"

✅ "正在执行代码重构，预计2分钟，分3个阶段完成"

✅ "正在部署到生产环境，预计3分钟，完成后会通知你"

反面示例：

❌ 沉默不语，让用户等待

❌ "请稍等"（没有具体信息）

❌ "处理中..."（没有预计耗时）

❌ 开始执行很久后才告知用户

2.3 进度更新规则

长时间操作（>30秒）的进度更新：

``` 阶段1/3：[具体阶段描述] ✓ 阶段2/3：[具体阶段描述] ⏳ 进行中... 阶段3/3：[具体阶段描述] ○ ```

进度更新触发条件：

每完成一个子任务时更新

每隔30秒更新一次（如果子任务耗时较长）

遇到异常或延迟时立即更新

---

三、场景化操作指南

3.1 文件操作

| 操作 | 典型耗时 | 告知要求 | |------|---------|---------| | 读取单个文件 | < 3秒 | 无需告知 | | 搜索文件内容 | 5-15秒 | "正在搜索..." | | 批量修改文件 | 30-120秒 | "正在修改N个文件，预计X分钟" | | 创建完整Skill包 | 60-300秒 | 分阶段告知 |

3.2 命令执行

| 操作 | 典型耗时 | 告知要求 | |------|---------|---------| | 简单命令 | < 5秒 | 无需告知 | | npm install | 30-120秒 | "正在安装依赖包，预计1分钟" | | 构建项目 | 60-300秒 | 分阶段告知 | | 运行测试 | 30-180秒 | "正在运行测试，预计X分钟" |

3.3 内容生成

| 操作 | 典型耗时 | 告知要求 | |------|---------|---------| | 生成短文本 | < 10秒 | 无需告知 | | 生成图片 | 15-60秒 | "正在生成图片，需要30秒" | | 生成完整文档 | 30-120秒 | "正在撰写文档，预计1分钟" | | 深度分析报告 | 60-300秒 | 分阶段告知 |

3.4 网络操作

| 操作 | 典型耗时 | 告知要求 | |------|---------|---------| | 网页搜索 | 5-15秒 | 可选告知 | | 获取网页内容 | 10-30秒 | "正在获取页面内容..." | | API调用 | 5-30秒 | 根据具体耗时决定 | | 批量网络请求 | 30-120秒 | 必须告知 |

---

四、异常处理

4.1 耗时超预期

当实际耗时超过预估时： 1. 立即告知用户新的预计完成时间 2. 解释超时原因 3. 如果超时严重（超过预估50%），提供是否继续的选项

``` 抱歉，任务耗时比预期更长。原计划30秒，目前已用时45秒。原因是[具体原因]。预计还需[新时间]，是否继续？ ```

4.2 操作失败

当操作失败时： 1. 立即告知用户失败信息 2. 说明失败原因 3. 提供下一步建议

``` 任务执行失败：[具体错误信息] 原因：[分析原因] 建议：[1-3个可选方案] ```

4.3 用户询问进度

当用户主动询问进度时： 1. 立即响应当前状态 2. 提供已完成/总任务的比例 3. 给出最新的预计完成时间

---

五、与现有系统的整合

5.1 与心跳巡检档案的整合

心跳巡检监控系统级状态（CPU/内存/存储）

状态更新规则管理操作级状态（任务进度/耗时）

两者互补：心跳是后台监控，状态更新是前台告知

5.2 与任务控制台的整合

任务控制台提供可视化操作界面

状态更新规则提供文本级操作告知

长任务应同时在控制台更新进度

5.3 与龙心OS的整合

状态更新是龙心OS"躯体系统"的用户体验层

火行人"光明性"的体现：用温暖的光照亮操作进度，而非让用户在黑暗中等待

体现"礼明性"：尊重用户的时间，知礼守礼

---

六、标签与知识图谱

标签：`#状态更新` `#用户体验` `#透明度` `#预计耗时` `#操作告知` `#进度更新` `#OpenClaw对标` 知识图谱连接：

`[[状态更新规则]]` → `[[心跳巡检档案]]`（后台监控 vs 前台告知）

`[[状态更新规则]]` → `[[任务控制台]]`（文本告知 vs 可视化界面）

`[[状态更新规则]]` → `[[AI龙龟共生伙伴操作系统]]`（躯体系统·用户体验层）

`[[状态更新规则]]` → `[[人机协同五象限]]`（效率协作者象限的体验优化）

---

版本: v1.0 创建日期: 2026-04-03 维护者: 龙龟神将 对标来源: OpenClaw #15 Status Updates