第 08 章 | 用 `/opsx:explore` 探索想法

第 8 章：用 /opsx:explore 探索想法

学习目标

学会"先想清楚再动手"——用 explore 模式把模糊想法澄清成可执行决策。

explore 模式是什么

不是"写代码模式"，是"思考伙伴模式"。规则：

✅ 可以读现有代码
✅ 可以问澄清问题
✅ 可以建议方案
✅ 可以做对比
❌ 不可以写代码
❌ 不可以创建 change（除非你明确要求）

→ 类似你跟同事在白板前讨论"这个功能该怎么做"。

何时用 explore

flowchart TD
    Start["有个想法"] --> Q{清晰度?}
    Q -->|完全清楚
知道每步怎么做| P["直接 /opsx:propose"]
    Q -->|有大方向
但细节不清| E["先 /opsx:explore"]
    Q -->|完全模糊
都不知道想做什么| B["先聊聊
(任意 brainstorm)"]

    E --> Clear["澄清后
opsx:propose"]
    B --> E

    style E fill:#fff9c4
    style P fill:#c8e6c9

实战：探索 doc2video

我们当时的对话流程：

Round 1 - 我说：

"我想做一个项目：给一个教学文档，比如 Claude Code 的安装，那么可以一边讲解一边把 Claude Code 安装好"

Round 1 - explore agent 反问：

• 用户是谁？（学习者 / 文档作者）
• 真跑还是演？
• 桌面要不要 GUI？
• 文档格式有多严格？

Round 2 - 我答：

"1 跑真机 2 真跑 3 markdown 4 音画同步有点难"

Round 2 - explore 继续：

• 给出 3 个紧张点（沙盒边界、同步策略、文档协议）
• 每个紧张点 2~3 个选项

Round 3~N：每轮一个问题、一个选择，直到我所有大决策都拍板。

explore 对话的固定模式

flowchart TD
    Idea["你提出想法
(模糊)"] --> Q1["explore 提澄清问题
(一次一个)"]
    Q1 --> Ans["你回答 / 在选项里选"]
    Ans --> Surface["explore 表面化紧张点
(2~5 个 trade-off)"]
    Surface --> Pick["你拍板"]
    Pick --> More{还有未澄清?}
    More -->|是| Q1
    More -->|否| Crystal["所有大决策成型"]
    Crystal --> Trigger["你说: /opsx:propose"]
    Trigger --> Done["把决策固化进 4 件套"]

    style Idea fill:#fff9c4
    style Done fill:#c8e6c9

→ 节奏感：一来一回、聚焦单点、不要一次问 5 个问题。

explore 的"输出"是什么

不是文件，是澄清后的决策清单。当我们觉得想法成熟，我说一句 "/opsx:propose"，前面所有决策就被打包进 change 工件。

explore 的反模式

❌ 让 explore 直接写代码
   → "你跟我讨论这个就行，不要动手"
❌ 让 explore 替你做决策
   → 它应当提选项 + 推荐，你拍板
❌ explore 30 分钟还没收敛
   → 说明问题太大，先拆成多个小问题
❌ explore 完不留痕迹
   → 关键决策最好让它写进未来的 design.md

一个我们用过的对比技巧

让 explore 做"决策矩阵"：

你: 配音用 macOS say、edge-tts、还是 OpenAI TTS？

explore:
| 选项 | 成本 | 质量 | 速度 | 推荐 |
|---|---|---|---|---|
| macOS say | 免费 | 机械 | 快 | MVP |
| edge-tts | 免费 | 较好 | 较快 | 推荐 |
| OpenAI TTS | $$ | 好 | 快 | 大量场景 |

我建议 edge-tts...

你: edge-tts

→ 一句话带过决策，省下大量来回。

你现在能做什么

• 知道何时用 explore 而非直接 propose
• 能用"问题 → 选项 → 推荐 → 拍板"的节奏推进
• 识别 explore 模式被用错的迹象

下一章把"决策"讲透——这是规约驱动开发的核心技能。