screen-usecase

评估并处理用户提供的 OpenClaw 用例来源。

$ARGUMENTS — 用例来源（URL、推文链接、文章描述，或用户粘贴的内容）

---

工作流总览

输入来源 → 深度研究 → 三条收录标准评估 → 依赖验证 → 决策
                                                    ↓
                                            通过 → 撰写用例 → 自审 → 提交 PR
                                            不通过 → 输出评估报告 + 改进建议

---

Phase 1: 深度研究

1.1 获取主源内容

根据来源类型选择获取方式：

来源类型	获取方式
博客/文章 URL	WebFetch 获取全文
推文/X 链接	WebFetch（可能失败）→ 请用户粘贴内容
GitHub 仓库	DeepWiki read_wiki_structure + ask_question
用户粘贴内容	直接分析

提取清单（必须从主源中明确获得，缺一不可）：

• 具体配置示例（JSON/YAML/Markdown）
• 实际执行步骤或命令
• 产出证据（截图、日志、成本数据、性能指标）
• 作者/团队信息

缺少任一项，在评估中标注为"证据不足"。

1.2 多源验证

至少找到 2 个独立来源，使用 WebSearch + GitHub CLI 并行搜索：

搜索策略（并行启动 3 个 Agent）：
Agent 1: WebSearch 搜索中文社区（CSDN、知乎、V2EX、53AI）
Agent 2: WebSearch 搜索英文社区（Reddit、HN、X/Twitter、Dev.to）
Agent 3: GitHub 搜索相关仓库 + 代码（gh search repos / gh search code）

对每个来源记录：

字段	要求
URL	完整链接
类型	官方文档 / 开源仓库 / 社区实践 / 内容聚合
独立性	是否与主源独立（转载/翻译不算独立）
证据级别	有代码 → 实测 / 有步骤无产出 → 教程 / 仅描述 → 概念

1.3 依赖验证

对用例涉及的每个关键技术依赖，检查是否有稳定的开源支撑：

# 搜索相关 SDK/工具
gh search repos "{依赖关键词}" --sort stars --limit 10

# 检查具体仓库
gh api repos/{owner}/{repo} --jq '.stargazers_count, .pushed_at, .archived, .license.spdx_id'

判定标准：

Stars	判定	处理方式
1000+ 且活跃维护	可推荐	在用例中作为推荐方案
500-999 且活跃	可提及	标注"社区项目，自行评估风险"
<500 或已归档	不推荐	不在用例中引用，或标注"无成熟开源方案"

对于无开源 SDK 的平台（如国内电商平台 API）：

• 检查官方开发者门户是否提供 SDK
• 检查 API 准入要求（是否需要企业资质）
• 在用例中如实说明现状，不回避

---

Phase 2: 收录标准评估

对照 CONTRIBUTING.md 的三条收录标准逐项打分：

评估卡片模板

## 用例评估：[用例名称]

### 1. 真实跑通
- 是否有端到端执行证据？[是/否/部分]
- 证据类型：[代码仓库 / 配置截图 / 日志输出 / 成本数据 / PoC 报告]
- 证据链完整度：[完整 / 有缺口 / 仅概念]
- 得分：[通过 / 有条件通过 / 不通过]

### 2. 多源验证
- 独立来源数量：[N 个]
- 来源 1：[URL] — [类型] — [证据级别]
- 来源 2：[URL] — [类型] — [证据级别]
- 得分：[通过 / 有条件通过 / 不通过]

### 3. 可操作
- 是否有可复制的配置/提示词？[是/否]
- 读者照做能否复现？[能 / 需适配 / 不能]
- 关键依赖是否可获取？[全部可获取 / 部分受限 / 主要受限]
- 得分：[通过 / 有条件通过 / 不通过]

### 综合判定
- 结论：[适合收录 / 有条件收录 / 不适合收录]
- 理由：[一句话]
- 如果"有条件"：需要补充什么？