openclaw类产品场景探究
1.产品场景分析
“Openclaw”产品和传统的llm问答助手的在场景优势上的最大区别是什么,首先场景分类为信息收集型、任务型、生成创作型,这三种类型都可以在场景中进行组合,比如我想全网比价一下xx小区点星巴克抹茶拿铁大杯哪个平台买最便宜,是淘宝闪购还是美团,这就是典型的单一信息收集型。如果我在这个基础上又加上指令,比价完,哪个便宜,帮我下个单,这个就是信息收集+任务型,当然,单纯任务型的场景也是存在的,另外,典型的生成创作类的,比如根据今天天气生成一首歌曲。
同时,场景可以按照频次拆解成单次任务和定时固定执行的任务。
那么从分类和频次维度,“openclaw”类产品到底适合什么呢,笔者体验了redclaw和jvs claw两个比较典型的手机端侧的“openclaw”类产品,比如在信息收集型场景中,“openclaw”类产品和传统的llm问答助手产品最大的差异在本地化部署和基于视觉理解,传统的llm问答助手能够联网搜索,比如进行奶茶价格全网比价,但是无法做的比如用户说,我是个运营,我要每天看我企微信的群聊信息,统计群聊里用户对某个产品的情感偏好、购买意向。而在任务型场景中就更典型了,“openclaw”类产品不仅会想还能做,而传统的llm问答助手只能回复一段文字,告诉你去哪里点,不能真的帮你点奶茶。在生成创作型场景中,目前感觉“openclaw”类产品和传统的llm问答助手产品没有明细区别。
而在场景频次上,“openclaw”类产品单次耗时更多,较会模型更麻烦,用户友好程度距离传统的llm问答助手产品也有较大差距,所以更适合定时固定执行的任务。

“opneclaw”类产品在技术形态上采用本地部署和视觉理解,同时,结合现在“opneclaw”类产品较难溯源逆向定位任务规划和执行错误的特点。
好了,从上述分析,其实我们就可以锁定几个“openclaw”类产品适合的场景关键词:
高价值区:定时固定执行+ 个人账号信息收集 + 跨应用任务执行
延伸区:公开网络信息监控
避免区:单次即时问答、纯内容创作

综上,我们可以将“opneclaw”类产品的核心理念提炼为:
“在确定性中创造价值,在封闭生态中建立连接。”
“确定性” 对应“定时固定执行”:不做天马行空的创作,而是解决用户日程表中那些重复、烦人、但流程相对固定的任务。
“封闭生态” 对应“本地化碎片化信息”:不依赖公开网络信息,而是深入用户手机中一个个数据孤岛(微信、银行App、健康App),扮演连接器的角色。
由此,可以导出三条核心设计原则,用以指导所有功能与迭代:
场景优先于模型:不过度追求模型的通用智能,而是深耕高频、可标准化的“场景包”。成功不取决于“模型多聪明”,而取决于“在100个用户执行‘每周财务汇总’时,能否成功99次”。
可靠性大于惊艳性:用户体验的核心是“放心托付”。一个能100%稳定执行、但功能简单的任务,远胜于功能炫酷但10%会失败的任务。安全、稳定、可预测是生命线。
配置引导取代自然语言理解:鉴于复杂指令理解是当前痛点,应主动降低用户输入的自由度。用“表单向导”、“场景模板”引导用户配置任务,将开放的自然语言输入,转化为结构化的参数(时间、App列表、关键词、输出位置)。这能极大提高任务设置的成功率和用户体验。
2. 用户故事(个人财务健康管理)
|
元素 |
描述 |
|
用户角色 |
都市白领“薇薇”,28岁,月收入2万元,拥有4张信用卡、3个电子钱包,对个人财务健康有管理需求但缺乏时间和系统性方法。 |
|
场景 |
每月1号和15号,需要汇总各账户的消费情况,分析消费结构,为月度预算调整提供依据。目前手动操作需2小时/次。 |
|
当前痛点 |
1. 信息分散:消费记录分布在7个不同金融App中2. 对账繁琐:需逐个登录、截图、记录、计算3. 易遗漏:经常忘记某个账户,导致数据不全4. 无历史对比:手工记录难以进行月度趋势分析 |
|
需求满足标准 |
薇薇设置:“每月1号9:00,自动登录我的招行、建行、支付宝、微信支付、京东白条、花呗、信用卡管家,抓取上月消费总额和分类,生成对比图表,保存到Excel并邮件发我。” |
|
系统实现路径 |
RedClaw定时触发 → 云手机安全环境 → 依次登录7个金融App → 视觉识别账单页面 → OCR提取金额和分类 → 数据清洗与汇总 → 生成Excel和图表 → 邮件发送 → 清理云手机环境 |
3. 模型故事(个人财务助理Agent)
|
元素 |
详细设计 |
|
Agent角色 |
7×24小时个人财务数据管家 |
|
场景 |
定时、自动化地从用户授权的多个金融账户中收集消费数据,进行结构化处理和多维度分析。 |
|
用户目标 |
1. 自动化完成月度财务对账2. 获得可视化的消费结构分析3. 识别异常消费和优化建议 |
|
能力矩阵 |
|
|
数据收集 |
跨7+金融App自动化操作、视觉元素识别、OCR数字提取、异常状态处理 |
|
数据处理 |
数据清洗、分类映射(餐饮、交通、购物等)、金额汇总、同比环比计算 |
|
分析洞察 |
消费结构饼图、月度趋势线、超预算预警、消费习惯分析 |
|
输出交付 |
Excel表格生成、图表制作、邮件自动发送、移动端通知 |
|
工具清单 |
schedule_task, open_finance_app(app_id), recognize_bill_page(), extract_amounts_with_ocr(), categorize_expenses(), generate_excel_with_charts(), send_email_report() |
|
执行流程图 |
<br>开始 → 定时触发 → 循环7个App<br> ↓ ↓<br> 云手机启动 → 登录App → 导航到账单页<br> ↓ ↓<br> 安全验证 → 视觉识别UI元素<br> ↓ ↓<br> OCR提取数据 → 数据验证<br> ↓<br> 所有App完成? → 是 → 数据汇总分析<br> ↓ ↓<br> 否 生成报告<br> ↓ ↓<br> 下一个App 邮件发送+清理<br> |
|
输出要求 |
1. Excel文件:包含各账户原始数据、分类汇总、月度对比表2. 图表:消费结构饼图、月度趋势折线图、分类对比柱状图3. 洞察摘要:关键发现和建议(文本) |
|
约束条件 |
1. 安全性:所有操作在一次性云手机环境,数据不落地,执行后立即销毁2. 准确性:金额识别准确率≥99.5%,分类准确率≥95%3. 性能:单次任务≤15分钟,失败重试≤2次4. 容错:单个App失败不影响整体任务,报告中标注异常 |
4. 用户旅程地图
|
阶段 |
用户行为 |
思考与感受 |
机会点与设计策略 |
|
认知 |
1. 每月手动对账痛苦2. 听说有自动化工具3. 搜索”自动记账工具” |
“太花时间了”“有没有自动化的办法?”“这个RedClaw是什么?” |
内容营销:制作“每月省2小时”案例视频关键词优化:自动化记账、跨App对账 |
|
探索 |
4. 下载RedClaw试用5. 浏览预置场景模板6. 选择”月度财务汇总”模板 |
“看起来有点复杂”“这个模板好像就是我需要的”“要不要试试看?” |
模板化引导:提供清晰的场景模板成功案例展示:显示类似用户的使用成果 |
|
设置 |
7. 配置银行App列表8. 设置执行时间(每月1号9:00)9. 选择输出格式(Excel+邮件) |
“要登录这么多App安全吗?”“时间设什么时候好?”“希望能收到清晰的报告” |
安全透明化:详细说明云手机安全机制智能推荐:推荐最佳执行时间预览功能:展示报告样式预览 |
|
授权 |
10. 授予必要权限11. 首次测试执行12. 查看测试结果 |
“有点担心隐私”“真的能行吗?”“哇,真的自动生成了!” |
权限最小化:仅请求必要权限一键测试:提供快速测试功能即时反馈:测试后立即展示样本报告 |
|
等待 |
13. 设置完成等待第一次自动执行 |
“设置好了,等1号看结果”“会不会忘记执行?” |
确认提醒:发送设置成功通知执行前提醒:提前一天发送提醒 |
|
接收 |
14. 收到邮件报告15. 查看Excel和图表16. 发现消费洞察 |
“准时收到了!”“图表很清晰”“原来外卖花了这么多!” |
多渠道通知:邮件+App推送报告可读性:优化图表设计和洞察摘要行动建议:提供具体的优化建议 |
|
依赖 |
17. 连续使用3个月18. 分享给同事19. 探索其他自动化场景 |
“已经离不开这个工具了”“你也应该试试”“还能自动做什么?” |
忠诚度计划:长期用户专属功能推荐奖励:邀请好友得奖励场景推荐:基于使用历史推荐新场景 |
|
进阶 |
20. 自定义分析维度21. 设置预算预警规则22. 导出年度趋势报告 |
“想看看交通费占比”“超过预算要提醒我”“看看全年变化趋势” |
高级功能引导:渐进式解锁高级功能年度报告:自动生成年度总结报告 |
5. 模型旅程

详细执行步骤表格
|
阶段 |
步骤序号 |
步骤名称 |
详细描述 |
工具/技术 |
成功标准 |
失败处理 |
|
1. 触发与启动 |
1.1 |
定时器触发 |
每月1号上午9:00准时触发任务 |
schedule_task |
触发时间误差<1分钟 |
延迟触发机制 |
|
1.2 |
身份验证 |
验证任务执行权限和用户身份 |
OAuth2.0/JWT |
身份验证通过 |
记录失败,通知用户 |
|
|
1.3 |
启动云环境 |
启动一次性云手机安全沙箱 |
云手机技术 |
云环境启动<30秒 |
重试最多3次 |
|
|
2. 循环处理App |
2.1 |
打开第一个App |
启动目标金融App |
open_app(“招商银行”) |
App成功启动 |
跳过此App,记录异常 |
|
2.2 |
登录检查 |
检查是否已登录 |
check_login_state() |
返回登录状态 |
触发安全登录流程 |
|
|
2.3 |
导航到账单页 |
模拟点击进入账单页面 |
click_by_text(“账单”) |
到达目标页面 |
尝试备选导航路径 |
|
|
2.4 |
视觉识别 |
识别页面UI元素布局 |
UI_Recognition_Model |
识别准确率>95% |
使用备用识别方案 |
|
|
2.5 |
OCR提取 |
提取金额和分类文本 |
OCR_Engine |
金额识别准确率>99% |
人工标注训练数据 |
|
|
2.6 |
数据验证 |
验证数据逻辑一致性 |
data_validation() |
通过所有验证规则 |
标记为异常数据 |
|
|
2.7 |
临时存储 |
将数据存入临时数据库 |
store_temp_data() |
存储成功 |
记录存储失败 |
|
|
2.8 |
循环判断 |
是否还有下一个App |
has_next_app() |
正确处理所有App |
跳过错过的App |
|
|
3. 数据处理 |
3.1 |
数据清洗 |
去除重复、错误记录 |
data_cleaning() |
数据质量评分>90 |
人工审核标记 |
|
3.2 |
分类映射 |
映射到统一分类体系 |
category_mapping() |
映射准确率>95% |
建立映射规则库 |
|
|
3.3 |
计算汇总 |
计算总额、分类占比等 |
calculate_summary() |
计算无逻辑错误 |
双重计算验证 |
|
|
3.4 |
趋势分析 |
对比历史数据趋势 |
trend_analysis() |
发现有效洞察 |
标记为无显著趋势 |
|
|
3.5 |
异常检测 |
识别异常消费模式 |
anomaly_detection() |
发现真实异常 |
降低误报率 |
|
|
4. 报告生成 |
4.1 |
生成Excel |
创建结构化数据表格 |
generate_excel() |
表格格式正确 |
生成CSV备选 |
|
4.2 |
创建图表 |
生成饼图、折线图、柱图 |
create_charts() |
图表清晰美观 |
使用默认样式 |
|
|
4.3 |
撰写摘要 |
生成文本分析报告 |
generate_summary() |
报告有实用洞察 |
使用模板化报告 |
|
|
4.4 |
整合报告 |
组合所有输出为最终报告 |
compile_report() |
报告完整一致 |
分部件发送 |
|
|
5. 交付结果 |
5.1 |
发送邮件 |
将报告通过邮件发送 |
send_email() |
邮件发送成功 |
重试发送 |
|
5.2 |
推送通知 |
App内推送任务完成通知 |
push_notification() |
通知到达用户 |
邮件备份通知 |
|
|
5.3 |
保存副本 |
云端保存报告副本 |
save_backup() |
保存成功 |
本地临时保存 |
|
|
6. 清理与记录 |
6.1 |
清理环境 |
销毁云手机和临时数据 |
cleanup_environment() |
无数据残留 |
强制清理机制 |
|
6.2 |
记录日志 |
记录完整执行日志 |
log_execution() |
日志包含关键信息 |
最小化日志记录 |
|
|
6.3 |
更新状态 |
更新任务执行状态 |
update_task_status() |
状态准确更新 |
手动状态修正 |
|
|
6.4 |
触发监控 |
触发监控和告警检查 |
trigger_monitoring() |
监控覆盖全流程 |
定期手动检查 |
异常处理流程
开始异常处理├── 错误类型识别
│ ├── 网络错误 → 等待重试(最多3次)
│ ├── 界面变化 → 使用备用识别方案
│ ├── 登录失败 → 触发二次验证
│ ├── 数据异常 → 标记并继续执行
│ └── 系统错误 → 告警人工介入
│
├── 影响范围评估
│ ├── 单个App失败 → 跳过继续执行
│ ├── 核心步骤失败 → 部分成功处理
│ └── 关键系统失败 → 全任务中止
│
└── 恢复策略选择
├── 立即重试 → 针对瞬时错误
├── 降级执行 → 使用简化方案
├── 跳过步骤 → 放弃非关键步骤
└── 人工处理 → 记录待人工处理
(注:用户故事、模型故事、用户旅程、模型旅程都是ai生成的,仅作为示例说明前面的分析场景,正确性和完整性有缺陷)
夜雨聆风