omh-deep-interview

OMH 深度访谈 — 通过对话梳理需求规范

适用场景

• 目标模糊、需求不明确，或可能有多种解读
• 对非简单工作进行规划（omh-ralplan）或实施之前
• 用户说：“深度访谈”“需求”“我们应该构建什么”“帮我理清思路”
• omh-ralplan 判定目标过于模糊，无法制定计划
• 你不确定用户真正想要什么
• **不熟悉领域：**如果目标需要具备某个陌生领域的外部知识，建议先运行 omh-deep-research 收集背景信息，然后根据已确认的报告继续访谈。

不适用场景

• 目标已经非常清晰且范围明确
• 此项目的 .omh/specs/ 中已有已确认的规范
• 用户明确表示希望跳过需求收集
• 显而易见的简单单文件修改

前置条件

• 能与用户进行对话（此技能需要提问并获取回答）
• 对 .omh/ 目录具有写入权限，以保存状态和规范文件

流程

按顺序执行以下阶段。此技能通过与用户对话以及写入文件来保存状态并输出规范。

阶段 0：检查现有状态

开始新的访谈之前：

1. 列出所有进行中的访谈：

   listed = omh_state(action="list_instances", mode="interview")
   

   每个条目都包含 instance_id（访谈 ID）和 active 标记。 如果 omh_state 不可用，则手动 glob .omh/state/interview--*.json。
2. 如果存在进行中的访谈，告知用户：“项目‘{project_name}’有一个正在进行的访谈（id={id}）。要继续、重新开始，还是放弃？”
3. 如果要继续：omh_state(action="read", mode="interview", instance_id="{id}") — 阅读各轮摘要以重建上下文
4. 如果要放弃：omh_state(action="write", mode="interview", instance_id="{id}", data={...status: "abandoned"})，然后使用一个新的 ID 进入阶段 1
5. 如果未找到进行中的状态：进入阶段 1
6. 允许同时进行针对不同项目的多个访谈；不要阻止。
7. 检查现有研究背景（omh-deep-research 标记）： 如果 .omh/research/*-report.md 中存在任何带有 frontmatter status: confirmed 的文件，请告知用户该报告可作为访谈背景 （例如：“我看到一份关于‘{topic}’的已确认研究报告，位于 {path} — 要我将其作为背景信息纳入吗？”）。不要自动加载；由用户决定。

阶段 1：开场

以两个问题开始访谈：

1. 项目描述：“请用 2-3 句话描述你想构建什么。核心想法是什么？”
2. 从零开始还是基于现有项目：“这是一个从零开始的新项目，还是要在现有代码库或系统中开展工作？”

然后：

• 生成一个访谈 ID：di-{YYYYMMDD}-{short_random}（例如，di-20260407-x7k）
• 请用户提供一个简短的项目名称（用于文件名）
• 在 .omh/state/interview--{id}.json 创建状态文件（引擎会根据 instance_id="{id}" 推导该文件名），其中包含：
  • 将所有覆盖维度设为 HIGH
  • 根据用户的回答，将 type 设为 greenfield 或 brownfield
  • 对于从零开始的项目，将 existing_context 覆盖度设为 N/A
  • 第 0 轮摘要，记录开场问题的回答
• 告知用户：“明白了。我最多会提问 5 轮，以明确需求。如果你觉得已经涵盖所需内容，随时可以说‘够了’。”

阶段 2：访谈循环

最多进行 5 轮（如果用户要求，可扩展至 10 轮）。每轮：

步骤 1 — 选择要探究的维度

比较各维度的覆盖度分档。选择歧义最大的维度作为目标。 当多个维度处于同一分档时，使用权重打破平局：

• 从零开始构建：目标（0.40）> 约束（0.30）= 成功标准（0.30）
• 基于现有项目改进：目标（0.35）> 约束（0.25）= 成功标准（0.25）> 现有上下文（0.15）

加载 references/scoring-rubric.md，查看详细的分档定义和示例。

步骤 2 — 提出问题

提出一个针对所选维度的主要问题。问题应具体，并以用户已经告诉你的内容为依据。不要提泛泛的问题——要参考用户之前的回答。

好：“你提到这是一个供个人使用的命令行工具。如果运行时没有配置任何任务，会发生什么——应该创建一个默认列表、显示错误，还是采取其他做法？”

不好：“你的约束是什么？”

如果用户的回答不明确、自相矛盾或引出了新问题，可以进行 1-2 次简短追问。如果回答已经清楚，就不要强行追问。

步骤 3 — 自适应提问（如陷入僵局）

如果某个维度连续 2 轮或以上作为目标，但仍未脱离当前分档，请改变提问方式：

• 尝试从完全不同的角度提问
• 举出一个具体示例并询问“这样对吗？或者你会做哪些调整？”
• 询问是什么妨碍了明确判断：“是什么让这件事难以确定？”
• 请用户定义他们一直在模糊使用的某个具体术语

步骤 4 — 更新覆盖度

处理完用户的回答后，重新评估目标维度的覆盖度分档。 使用 references/scoring-rubric.md 中的评分标准。采取保守判断——如有疑问，保留当前分档，而不要过早降低分档。

步骤 5 — 更新状态

更新访谈状态（轮次递增、添加摘要、更新覆盖度）：

omh_state(action="write", mode="interview", instance_id="{id}", data={...updated state with new round...})

每轮摘要：最多约 200 个词——记录了解到的内容，而非完整对话。

步骤 6 — 展示覆盖度并询问是否继续

向用户展示当前进展：

Coverage after round {N}:
  Goal:             [MEDIUM]  →  Some clarity, but scope needs bounding
  Constraints:      [LOW]     →  Mostly clear, data format TBD
  Success Criteria: [HIGH]    →  Need testable criteria
  Existing Context: [N/A]     →  Greenfield project

然后询问：“想继续完善，还是这些信息已经足够开始着手了？”

• 如果用户说继续：进入下一轮
• 如果用户说够了/完成了/就这样：进入阶段 3
• 如果已达到第 5 轮：“我们已经进行了 5 轮。想继续（最多再进行 10 轮），还是根据现有内容生成规格说明？”
• 如果已达到第 10 轮：自动进入阶段 3

是否退出始终由用户决定。绝不要根据覆盖度分数自动终止。

阶段 3：生成规格说明

用户确认退出（或达到最大轮数）后：

1. 加载 templates/spec-template.md
2. 根据状态文件中累计的各轮摘要，综合整理出一份规格说明
3. 填写模板的每个部分：
   • 目标：综合针对目标维度的各轮内容
   • 约束：综合以约束为重点的各轮内容
   • 成功标准：必须具体且可测试——如果某项标准无法验证，请在“待解决问题”中标出
   • 现有上下文：仅适用于基于现有项目改进；综合以现有上下文为重点的各轮内容
   • 假设：用户明确陈述或暗示、但尚未验证的内容
   • 待解决问题：覆盖度仍为 HIGH 或 MEDIUM 的所有事项——这些问题尚未解决
4. 设置 YAML frontmatter：
   • status: draft
   • coverage：当前分档值
   • rounds_completed：已完成的总轮数
5. 写入 .omh/specs/{project-name}-spec.md
6. 更新状态：spec_file = 规格说明文件路径

阶段 4：确认

向用户展示完整的规范草案并询问：

“这是我拟定的规范。请审阅。你可以：

• 确认——我会将其定稿，后续技能（ralplan、autopilot）将使用它
• 请求修改——告诉我需要调整的内容，我会提出后续问题
• 放弃——丢弃该规范并结束访谈”

处理每种回复：

确认时：

• 更新规范的 frontmatter：status: confirmed
• 更新状态：status: confirmed
• 告诉用户：“规范已确认并保存至 {path}。现在可以使用 omh-ralplan 根据此规范创建实施计划。”

请求修改时：

• 针对用户希望修改的具体章节提出有针对性的后续问题
• 重新生成规范
• 返回确认提示

放弃时：

• 删除规范文件
• 更新状态：status: abandoned
• 告诉用户访谈已放弃

只有 status: confirmed 的规范才会被后续技能视为有效。

阶段 5：日志记录

在整个访谈期间，将结构化事件写入 .omh/logs/interview-{id}.log：

2026-04-07T06:30:00Z STARTED interview_id=di-20260407-x7k project=my-project type=greenfield
2026-04-07T06:31:15Z ROUND round=1 dimension=goal coverage_change=goal:HIGH→MEDIUM
2026-04-07T06:33:42Z ROUND round=2 dimension=constraints coverage_change=constraints:HIGH→LOW
2026-04-07T06:35:00Z USER_EXIT round=3 reason=user_confirmed
2026-04-07T06:35:30Z SPEC_GENERATED path=.omh/specs/my-project-spec.md status=draft
2026-04-07T06:36:00Z SPEC_CONFIRMED path=.omh/specs/my-project-spec.md

仅记录事件和决策，不要记录对话内容。

Sentinel 约定

后续技能通过检查符合以下条件的文件，来检测已完成的访谈： .omh/specs/*-spec.md 文件的 YAML frontmatter 中包含 status: confirmed。

• omh-ralplan：如果存在已确认的规范，就将其用作 Planner 子 Agent 的目标／规范输入，而不是让用户描述目标。
• omh-autopilot：如果存在已确认的规范，就完全跳过阶段 0（需求）。

状态管理

状态文件：.omh/state/interview--{id}.json（引擎路径；将 instance_id="{id}" 传给 omh_state）

完整架构请参阅 references/state-schema.md。

关键规则：

• 每次访谈都是一个由其 ID 标识的独立实例；允许在不同项目上并行进行访谈
• 状态中保存每轮摘要（每轮最多约 200 个单词），而非完整转录
• 完成后仍会保留状态（用于审计追踪）
• 恢复访谈时难免会有信息损失——每轮摘要有助于重建上下文，但会丢失原始对话中的细节

注意事项

• 切勿根据评分自动终止。 覆盖度分档是用于确定问题方向的启发式参考。始终由用户决定何时结束。
• 不要存储完整转录。 每轮摘要可保持状态精简，并遵守恢复时的上下文窗口限制。请接受恢复结果只是近似而非完全还原。
• 询问是否为棕地项目，不要自动检测。 检查 package.json 等文件并不可靠，也显得冒昧。让用户告知你。
• 每个项目只能有一个进行中的访谈。 每次访谈使用新的 instance_id。如果同一项目已有进行中的访谈，应先询问用户是要恢复还是放弃，再使用相同 ID 启动并行访谈。
• 规范必须经过确认。 草案规范不能作为后续技能的有效输入。用户必须明确确认。
• 不要提泛泛的问题。 应结合用户先前的回答。“你有哪些限制？”这种问法太敷衍。“你提到这是在 Linux 上供个人使用的——还需要支持其他平台吗？”这种问法才有帮助。
• 谨慎评估覆盖度。 如有疑问，保持当前分档。多问一个问题，也好过过早判定某个维度已明确。