exploring

探索想法（Exploring Ideas）

将不清晰的想法转化为双方都认可、可执行、可交接到 proposing 的理解。探索不是简单追问，也不是提前设计；它是有边界地发散，再有证据地收敛。

探索应尽量短，但不能为了短而过早压缩候选方向。只收集足以避免错误假设、错误范围和错误方案的信息；当问题空间较大时，先把候选方向聚类，再收敛到最小且有价值的第一版。

开始时只说明一次：“我会使用 exploring skill，先确认我们要构建什么。”

输出契约

在 exploring 阶段，唯一可见输出是对话内容，包括问题、摘要、假设、候选方向、取舍、证据、建议和对齐检查。

代理不得：

• 创建或编辑项目产物，例如 proposal.md、规格说明、设计文档、任务清单、工单或实现文件；
• 调用实现、设计、任务规划或编码类 skill；
• 在需求仍在发现阶段时开始构建；
• 将实现调研包装成单独、可见的工作流阶段；
• 因为已有 2–5 个候选方向就停止探索；候选数量由问题空间决定，而不是由固定上限决定。

只有在用户确认探索方向后，才能从 exploring 进入 proposing。

核心原则

1. 先定范围，再问细节。 先判断是单一功能、复合功能、多个子系统，还是产品/平台级问题。
2. 先发散，再收敛。 不在信息不足时强行给 2–3 个方案；先覆盖主要可能性，再聚类和推荐。
3. 候选项自适应，不固定封顶。 简单问题可以只有 1–3 个候选；复杂问题可以先生成更多候选，再压缩成候选族、短名单和停车场。
4. 一次只推动一个阻塞决策。 每轮最多问一个会影响范围、用户可见行为、权限、失败结果或成功标准的问题；同一个问题可以配多个选项卡帮助用户选择。
5. 选择题优先，但保留“其他”。 选项卡用于降低用户负担，不得把用户锁死在给出的候选里。
6. 证据服务决策。 调研只在会改变推荐方向时做；调研结果必须压缩成取舍，而不是研究报告。
7. 最小有价值切片优先。 推荐方向应优先让用户尽快获得可验证价值，同时保留扩展路径。
8. 显式标记假设。 不把假设伪装成已确认事实。
9. 不阻塞的开放问题可后移。 阻塞问题必须在进入 proposing 前解决或明确排除在第一版之外。
10. 主代理负责产品判断。 子代理只提供证据、比较和风险；最终探索推荐由主代理综合。

适用场景

当出现以下任一情况时，使用 exploring：

• 用户描述了目标，但没有说明具体交付结果；
• 需求、约束、目标用户、成功标准、失败模式或范围缺失；
• 请求可能包含多个相互独立的功能、工作流或子系统；
• 正确方案依赖现有代码模式、依赖关系、集成方式、权限边界或既有实现；
• 用户要求一个解决方案，但存在多种合理方案形态；
• 用户在表达愿景、问题、痛点、机会、优化方向或“想法”，但还没有形成可提案需求；
• 用户要求“帮我想想”“探索一下”“有哪些办法”“怎么做更好”“先别写代码”。

不适用场景

不要把 exploring 用在已经明确、具体且边界清晰的实现请求上。此时应直接交给合适的后续 skill。

如果请求很小但仍存在会影响行为的未知信息，使用一次轻量探索即可，不要启动完整探索流程。

执行流程

0. 快速判断探索强度

先判断本次需要哪种探索强度：

探索强度	信号	行动
轻量探索	单一小改动，只有 1 个关键未知	问 1 个聚焦问题，或给出 1 个假设让用户确认
标准探索	有明确目标，但交付形态、范围或成功标准不清	做范围分类、候选方案和对齐检查
深度探索	多路径、多角色、多子系统，或架构/产品方向不明	先发散候选地图，再收敛第一版切片
调研辅助探索	方案依赖代码库事实、集成边界或现有模式	启动有边界调研，调研结果只服务探索决策

1. 检查可用上下文

• 查看已有文件、文档、最近提交、项目结构和现有规格说明。
• 判断这是新项目（greenfield）还是既有项目改造（brownfield）。
• 优先检查已存在的行为规格，尤其是 specs/、specs/specs/、docs/、adr/、.codex/、AGENTS.md 等目录。
• 找出已有约束：语言、框架、运行环境、权限、安全边界、兼容性、数据模型、测试方式、发布方式。
• 不要询问上下文中已经回答过的问题。

2. 先判定范围，再问细节

先判断请求属于以下哪一类：

范围	信号	行动
单一功能	一个用户目标、一个主流程、边界清楚	继续正常探索
单一工作流	多个步骤，但服务同一端到端目标	澄清触发条件、输入输出、成功/失败路径
复合功能	一个目标，但包含多个相互依赖的部分	澄清依赖关系与最小第一版切片
多个子系统	涉及认证、计费、分析、聊天、存储、后台、集成等独立领域	停止细节追问，先拆分子项目
平台/产品级	宽泛产品愿景，涉及多个角色或长期演进	定义阶段，选择第一个子项目
研究/不确定性驱动	目标依赖外部约束、技术可行性或未知风险	先界定决策点，再做有限调研

如果需要拆分，应直接说明：

“这看起来包含多个独立功能。我们先拆成子项目，再细化需求。”

然后帮助用户明确：

• 独立部分分别是什么；
• 它们之间如何依赖；
• 最小但有价值的第一版是什么；
• 哪个子项目应先进入规格/提案周期。

当工作流支持 specs/changes/<name>/ 结构时，每个子项目都应有独立的变更周期。

3. 建立假设账本

在追问前，先列出当前可用信息和关键假设：

• Confirmed: 已由用户、文件或代码库确认的信息；
• Assumed: 当前为了推进探索而暂用的假设；
• Unknown: 仍未知的信息；
• Blocking: 进入 proposing 前必须关闭的问题；
• Deferrable: 可在 proposing 或实现阶段处理的问题。

不要把所有未知都拿来问用户。只问当前最能降低错误方向风险的问题。

4. 一次只澄清一个关键问题

每条消息只推动一个阻塞决策问题。

好的探索问题应具体、面向决策：

“这次更优先速度交付、长期可扩展性，还是最低运维风险？”

避免泛泛提问：

“你想要什么？再多说一点。”

问题应围绕：

• **目标结果：**完成后应成立的事实；
• **目标用户：**谁使用或受益；
• **主流程：**功能前、中、后分别发生什么；
• **输入与输出：**关键数据、操作、产物或可见结果；
• **约束：**技术、安全、性能、预算、时间、合规、兼容性或运维要求；
• **成功标准：**可观察、可验收的条件；
• **失败模式：**非法状态、错误、阻塞路径或不可用依赖；
• **非目标：**第一版明确不纳入的内容。

5. 自适应候选探索

候选项数量不能固定为 2–5。根据问题空间使用候选预算：

候选预算	适用场景	输出方式
1–3	小范围、方向明显、只需确认取舍	直接给推荐与替代
3–5	标准产品/实现选择	给短名单和推荐
6–10	多路径、多用户、多技术路线	先分组选项，再推荐第一版
10+ 原始候选	产品/平台级、策略级、架构级或用户明确要求广泛探索	先生成候选地图，聚类为 4–8 个候选族，再给短名单、停车场和排除项

候选探索必须遵守：

• 不因数量限制丢掉本质不同的方向；
• 不把大量低质量候选直接丢给用户；
• 对相似候选聚类，对明显弱候选放入 “Parking Lot” 或 “Rejected / Avoid”；
• 至少考虑一个最小可行切片；
• 在合适时考虑 “no-build / process change / reuse existing” 方向；
• 在合适时明确 “Avoid” 方向，帮助用户少走弯路；
• 推荐方案必须说明为什么现在推荐，而不是只列选项。

6. 选项卡输出

当候选方向超过 3 个、用户需要比较路径，或在 Codex 中需要可切换地查看多个探索轴时，使用“选项卡”格式。选项卡是探索对话的呈现方式，不是设计文档。

推荐格式：

### 选项卡 A｜推荐：<方向名>
- 适合：<什么时候选它>
- 结果：<用户可见结果>
- 范围：<第一版覆盖什么>
- 取舍：<收益与代价>
- 风险：<主要风险或未知>
- 复杂度：Low / Medium / High
- 下一步需要确认：<一个最关键问题>

### 选项卡 B｜保守：<方向名>
...

### 选项卡 C｜激进：<方向名>
...

### Parking Lot｜暂不推荐但保留
- <方向>：<为什么暂不进入短名单>

选项卡命名建议：

• 推荐 / 最小切片
• 保守 / 复用现有
• 扩展 / 中期演进
• 激进 / 平台化
• No-build / 流程方案
• Avoid / 暂不建议
• Parking Lot / 后续可能

在用户只需要选一个方向时，最后只问一个问题：

“我建议选 A 作为第一版。你要按 A 进入 proposing，还是先改成 B/C 的方向？”

7. 只有在会改变决策时才调研

实现调研只允许用于提高探索质量，不改变当前可见阶段。

可以调研的情况：

• 需要在采用现有方案与自研之间做选择；
• 需要比较依赖、集成方式、架构模式或代码路径；
• 需要确认当前代码库中是否已有相似行为；
• 需要评估风险、兼容性、迁移成本或维护负担；
• 需要验证会实质影响推荐方向的假设；
• 需要确认用户目标是否应拆成多个 proposal。

应跳过调研的情况：

• 普通澄清问题即可推进；
• 现有项目模式已经清楚决定方向；
• 调研结果不会改变建议；
• 问题属于设计或实现阶段，而非探索阶段；
• 用户只是在表达偏好、语气、文案或非常小的交互细节。

调研顺序：

1. 先搜索当前代码库；
2. 再检查内部文档、规格、proposal、ADR、issue 或注释；
3. 只有必要且允许时才查外部来源；
4. 将证据总结为简短取舍，而不是展开研究报告。

8. 平台分发与 Codex 选项卡/子代理

如需委托子代理做有限调研，使用填好的 ./implementation-researcher-prompt.md 模板。主代理仍负责综合、推荐和与用户对齐。

Claude Code

使用 Agent 工具和 general-purpose agent。旧环境中 Task 可能作为兼容别名存在。

Codex

在 Codex 中，优先把有边界、只读、互相独立的探索轴拆给子代理，并让每个子代理形成一个可区分的 agent thread / tab。

使用原则：

• Codex 不应因为 skill 文本存在就隐式生成子代理；主代理必须显式要求并行子代理或调用 spawn_agent(...)。
• 每个子代理只负责一个研究轴，例如 Existing patterns、Integration risk、API compatibility、Migration cost、Testing surface。
• 给每个子代理的 prompt 第一行写清楚 Tab label: <短名称>，便于 Codex App/CLI 中区分线程。
• 当支持 custom agents 时，可配置窄职责 agent，并使用可读 nickname，让多个子代理在 UI 中更像选项卡。
• 子代理必须只读调研，不得修改文件、不得创建 proposal、不得替主代理做最终产品决策。
• 主代理等待所有相关子代理结果后，用“选项卡输出”把候选方向合并成用户可审阅的探索结果。
• 不要无节制 fan-out；优先 2–5 个并行研究轴。若研究轴更多，先聚类或分批。
• 在 CLI 中，可通过 /agent 检查或切换 agent threads；主代理最终仍要给一个合并结论。

Codex 子代理调用示例（按当前环境可用工具调整参数）：

spawn_agent(
  agent_type="explorer",
  message="""
Tab label: Existing Patterns
Use ./implementation-researcher-prompt.md.
Research goal: Determine whether this idea should reuse, extend, compose, build, or avoid existing implementation paths.
Current context: <填入用户目标、项目约束、相关文件/模块、已知线索>
Search scope: 仅代码库 + 内部文档
Output depth: 聚焦对比
Exploration width: broad-with-clustering
Decision deadline: Enough evidence to support exploration, not implementation.
Return only the required researcher output. Do not edit files.
"""
)

如果 Codex 当前环境没有子代理工具，则主代理在本线程内执行同样的只读探索，并用选项卡格式呈现结果。

9. 收敛与推荐

当上下文足够时，输出推荐方向，而不是只列问题。

收敛输出应包含：

• 推荐第一版方向；
• 推荐原因；
• 候选项或候选族；
• 主要取舍；
• 复杂度估计；
• 风险与失败模式；
• 明确非目标；
• 是否需要进入 proposing；
• 进入 proposing 前唯一的阻塞问题，如果有。

推荐方向应优先满足：

1. 能解决用户当前最核心目标；
2. 范围小到可以写 proposal；
3. 与现有项目模式兼容；
4. 风险可被第一版边界控制；
5. 留有后续扩展路径。

10. 对齐确认

在请求进入下一阶段前，必须给出用户可审核的对齐检查点。

对齐检查点

离开 exploring 前，必须包含：

• **问题陈述：**正在解决的具体问题或目标结果；
• **目标用户：**谁会使用或受益；
• **主流程：**变更前、变更中、变更后分别发生什么；
• **输入与输出：**关键数据、操作、产物或可见结果；
• **范围内行为：**第一版变更会覆盖什么；
• **范围外行为：**第一版明确不覆盖什么；
• **候选方向：**考虑过的主要方向、推荐方向、Parking Lot 和 Avoid；
• **约束：**技术、产品、安全、兼容性、排期、性能、合规或运维限制；
• **失败模式：**预期的非法状态、错误、阻塞路径或不可用依赖；
• **开放问题：**剩余决策，区分 blocking 与 non-blocking；
• **交接信心：**是否足以进入 proposing，以及主要信心来源。

任何会影响用户可见行为、范围边界、权限、失败结果或成功标准的开放问题，都会阻塞阶段转换。此时应提出一个聚焦的澄清问题，或明确说明阻塞点。

在阻塞问题解决之前，不得创建 proposal.md。除非用户明确将相关行为排除在第一版范围之外。

工作流交接信心循环

当环境支持子代理时，在 exploring → proposing 交接前，使用 ../confidence-loop/SKILL.md 中的 Workflow Handoff Confidence Loop，并结合 ../confidence-loop/workflow-handoff-reviewer-prompt.md 进行审查。

审查包必须包含：

• 对齐检查点；
• 已确认的用户回答；
• 假设账本；
• 候选方向、Parking Lot 和 Avoid；
• 开放问题；
• 范围边界；
• 约束；
• 计划进入 proposal 的方向；
• 调研证据摘要，如果本次探索使用了调研。

如果仍存在 Critical 或 Important 发现、NEEDS_USER_DECISION、未解决的信心缺口，不得进入 proposing。

交接到 Proposing

准备好后，在对话中总结：

• 已达成一致的问题；
• 目标用户与主流程；
• 范围与非目标；
• 候选方向与推荐方向；
• 约束与风险；
• 可在 proposing 阶段安全解决的开放问题；
• 阻塞问题是否已全部关闭。

然后询问：

“我已经清楚我们要构建什么。接下来可以创建 proposal，是否继续？”

用户确认后，调用 proposing，且不得调用实现类 skill。

完成标准

只有以下条件全部满足，探索才算完成：

• 问题陈述清楚；
• 目标用户和主流程足够清楚，可以据此写 proposal；
• 输入、输出、范围内行为、范围外行为、约束和失败模式已经说明；
• 范围与非目标明确；
• 主要候选方向已充分发散，并已聚类、筛选或解释为什么不需要更多候选；
• 已提出推荐方案、替代方案、Parking Lot 和 Avoid（如适用）；
• 主要约束和风险已知，或已明确延后处理；
• 会影响行为的开放问题已经解决，或用户明确将其排除在第一版之外；
• 对齐检查点已展示；
• 用户同意进入 proposing。

停止信号与纠偏动作

如果出现以下想法，立即停止并回到探索：

想法	正确动作
“我已经知道用户想要什么。”	询问或验证缺失假设。
“我边实现边探索。”	不实现；先澄清。
“范围应该没问题。”	先分类范围，再问细节。
“这个太简单，不需要探索。”	若仍有关键未知，做轻量探索；若已经明确，交给后续 skill。
“2–3 个方案够了。”	先判断问题空间；必要时做候选地图和聚类。
“用户之后会纠正我。”	现在就把假设显式说出来。
“再问一个问题会烦。”	只问最高价值的下一个问题，并用选项卡降低负担。
“调研一下挺有意思。”	只有调研会改变决策时才做。
“子代理可以替我决定。”	子代理只给证据；主代理综合并对齐用户。

常见误判

借口	现实
“用户说直接做。”	这说明紧急程度，不代表需求完整。
“细节可以边做边定。”	细节就是需求；猜测会制造返工。
“问问题浪费时间。”	做错方向更浪费时间。
“这和另一个项目很像。”	相似性有参考价值，但差异决定工作内容。
“候选太多会让用户累。”	原始候选可以聚类；过早压缩会丢方向。
“Codex 子代理会自己整理好。”	子代理输出必须由主代理合并成探索对话和对齐检查点。

快速模板

轻量探索回复模板

我会使用 exploring skill，先确认我们要构建什么。

我先按这个假设推进：<当前假设>。
唯一会影响方向的问题是：<聚焦问题>？

选项：
- A：<选项>
- B：<选项>
- C：<选项>
- 其他：<让用户补充>

标准候选选项卡模板

我会使用 exploring skill，先确认我们要构建什么。

当前我看到 <N> 个候选方向，可以先按下面几个选项卡收敛：

### 选项卡 A｜推荐：<方向>
- 适合：...
- 第一版结果：...
- 取舍：...
- 风险：...
- 复杂度：...

### 选项卡 B｜<方向>
...

### Parking Lot
- ...

我建议先选 A。唯一需要你确认的是：<一个阻塞问题>？

对齐检查点模板

## 对齐检查点

- 问题陈述：...
- 目标用户：...
- 主流程：...
- 输入与输出：...
- 范围内行为：...
- 范围外行为：...
- 候选方向：...
- 推荐方向：...
- 约束：...
- 失败模式：...
- 开放问题：
  - blocking：none / ...
  - non-blocking：...
- 交接信心：High / Medium / Low，因为 ...

我已经清楚我们要构建什么。接下来可以创建 proposal，是否继续？