教程概述
系列索引: gstack 教程系列
/office-hours 是每个 gstack 冲刺的入口。核心理念：在写任何代码之前彻底理解问题。
你将学到
- ✅ 重新框架产品的六个迫使性问题
- ✅
/office-hours何时触发 - ✅ 苏格拉底式提问工作流
- ✅ 设计文档如何输入到下游技能
- ✅ 真实的重新框架示例
为什么需要 Office Hours？
直接写代码的问题
flowchart LR
A[模糊想法] --> B[AI 写代码]
B --> C[发现误解]
C --> D[重写代码]
D --> E[又一个误解]
E --> F[多次迭代]
style B fill:#ffcccc
style C fill:#ffcccc
style D fill:#ffcccc
gstack 工作流
flowchart TD
A[模糊想法] --> B[/office-hours]
B --> C[六个迫使性问题]
C --> D[产品重新框架]
D --> E[设计文档]
E --> F[/plan-ceo-review]
style B fill:#e1f5ff
style C fill:#e1f5ff
style E fill:#e8f5e9
六个迫使性问题
/office-hours 提出六个迫使清晰的问题：
问题 1：痛点是什么？
目的：找到具体的，而非假设的。
差："我想做一个日历应用"
好："我有 5 个 Google 日历，事件冲突，地点错误，信息陈旧。
每天准备要 30 分钟，结果还是错的。"
问题 2：谁有这个痛点？
目的：精确定义用户。
差："所有人"
好："跨时区管理多个团队的忙碌高管"
问题 3：你尝试过什么？
目的：了解失败的解决方案。
- 手动检查日历（耗时）
- 共享日历（权限问题）
- 日历应用（不能跨提供商聚合）
问题 4：成功是什么样子的？
目的：定义终点状态。
"一个不需要准备的早间简报，准确显示我需要的内容，
在冲突发生前就提醒我。"
问题 5：最窄的切入点是什么？
目的：找到最小的有价值切片。
不是："一个完整的日历管理平台"
而是："一封包含事件、地点和冲突警告的每日邮件"
问题 6：你不做什么？
目的：设定边界。
不做：
- 日历编辑（暂时只读）
- 团队调度功能
- 移动应用（网页优先）
何时触发
/office-hours 在以下情况自动触发：
- 开始新功能 — “我想添加…”
- 从零构建 — “创建一个…”
- 模糊请求 — “我需要一个更好的…”
- 显式调用 — 用户直接调用它
苏格拉底式提问工作流
sequenceDiagram
participant U as 用户
participant AI as AI (office-hours)
participant D as 设计文档
U->>AI: 我想做一个每日简报应用
Note over AI: 问题 1：痛点是什么？
AI->>U: 你要解决什么具体问题？
U->>AI: 多个日历，地点错误...
Note over AI: 问题 2：谁有这个痛点？
AI->>U: 具体是谁遇到这个问题？
U->>AI: 管理多个团队的忙碌高管
Note over AI: 问题 3：你尝试过什么？
AI->>U: 你尝试过什么解决方案？
U->>AI: 手动检查，共享日历...
Note over AI: 问题 4：成功标准
AI->>U: "完成"是什么样子的？
U->>AI: 零准备，早间简报
Note over AI: 问题 5：最窄切入点
AI->>AI: 对框架提出挑战...
AI->>U: 你说"简报应用"但描述的是"参谋长 AI"
AI->>U: 5 个你没意识到自己在描述的能力...
Note over AI: 问题 6：边界
AI->>U: 你明确不做什么？
U->>AI: 不编辑，不团队调度，不移动端
AI->>D: 生成设计文档
D->>U: 设计文档已创建
Note over D: 输入到 /plan-ceo-review
真实示例：每日简报应用
用户输入
我想做一个日历的每日简报应用。
AI 重新框架
我要对你的框架提出挑战。
你说"每日简报应用"，但你实际描述的是一个个人参谋长 AI。
让我提取你暗示的能力：
1. 多日历聚合（Google、Outlook、Apple）
2. 地点智能（行程时间、冲突）
3. 陈旧信息检测（过时的会议室）
4. 冲突预测（双重预约提醒）
5. 准备摘要（每个会议要准备什么）
完整愿景是一个 3 个月的项目。但这是最窄的切入点：
明天发布：一封包含今日事件、地点和冲突警告的简单邮件。
不编辑，不智能，只是聚合。
建议：从切入点开始，从真实使用中学习。
设计文档输出
# 每日简报应用
## 概述
**目标**：将早间日历准备从 30 分钟减少到 0
**用户**：跨多个提供商拥有 5+ 日历的忙碌高管
**最窄切入点**：包含事件、地点、冲突的每日邮件
## 能力（发现）
1. 多日历聚合
2. 地点格式化
3. 冲突检测
4. 邮件发送
## 非目标
- 日历编辑（只读）
- 移动应用（邮件优先）
- 团队功能（个人使用）
## 下一步
→ /plan-ceo-review 进行战略范围挑战
下游技能集成
/office-hours 的设计文档输入到：
| 下游技能 | 使用什么 |
|---|---|
/plan-ceo-review |
用户定义、最窄切入点 |
/plan-eng-review |
能力列表、非目标 |
/plan-design-review |
用户上下文用于 UX 决策 |
flowchart LR
A[/office-hours] --> B[设计文档]
B --> C[/plan-ceo-review]
B --> D[/plan-eng-review]
B --> E[/plan-design-review]
style A fill:#e1f5ff
style B fill:#e8f5e9
最佳实践
给用户
- 具体回答 — 不是"性能要好"而是"延迟低于 100ms"
- 尽早说明约束 — 时间、技术栈、团队规模
- 挑战 AI — “为什么你推荐那个方法？”
- 接受挑战 — 重新框架才是价值所在
AI 配置
office_hours:
question_depth: "medium" # shallow/medium/deep
pushback_style: "socratic" # socratic/direct
design_doc:
detail_level: "standard" # minimal/standard/comprehensive
常见模式
模式 1：用户有解决方案，不是问题
用户："我需要一个带图表的仪表板"
AI：看到图表后你会做出什么不同的决策？
[重新框架：仪表板 → 决策支持系统]
模式 2：用户想建太多
用户："我想要一个像 Notion 的应用"
AI：那是 100 人团队 5 年的项目。
你最需要哪一件事？
[重新框架：Notion 克隆 → 单一用途工具]
模式 3：用户有模糊的成功标准
用户："让它快"
AI：定义"快"：
- 页面加载？（目标：<2s）
- API 响应？（目标：<100ms）
- 数据处理？（目标：10k 记录 <1s）
[重新框架：模糊 → 可衡量]
技能快速参考
| 方面 | 详情 |
|---|---|
| 触发 | 新功能、模糊请求、显式 /office-hours |
| 输出 | 设计文档位于 .project/designs/ |
| 下游 | /plan-ceo-review、/plan-eng-review |
| 核心价值 | 将模糊想法重新框架为清晰需求 |
| 时间 | 典型功能 5-15 分钟 |
总结
/office-hours 是你的产品思考伙伴：
- 六个迫使性问题 — 痛点、用户、尝试、成功、切入点、边界
- 苏格拉底式重新框架 — 挑战框架，提取隐含能力
- 设计文档输出 — 自动输入到下游技能
- 最窄切入点 — 找到最小有价值切片先发布
关键要点
- ✅ 不要跳过产品思考 —— 它能节省 10 倍的返工
- ✅ 接受挑战 —— 重新框架才是价值
- ✅ 从切入点开始 —— 从真实使用中学习
- ✅ 让设计文档流向下游
系列导航：
- ← 上一篇: 教程 1：安装与配置
- → 下一篇: 教程 3：plan-ceo-review — 战略范围挑战
- 返回: 系列索引