核心用法
openclaw-office-hours 是一款模拟 Y Combinator Office Hours 风格的产品咨询型技能，核心价值在于在写代码之前重构问题定义。它通过六个阶段的结构化对话，帮助用户区分"感兴趣"与"真实需求"，避免盲目投入开发。
技能启动后，首先识别用户目标类型（Startup/内部项目 vs 黑客马拉松/开源/学习等），自动切换两种模式：
- Startup模式：采用YC风格的"逼问式诊断"，六个核心问题逐层深入——需求真相、现状替代方案、绝对具体的用户画像、最小付费切入点、用户观察中的意外发现、以及未来适应性判断
- Builder模式：转为协作式设计伙伴，聚焦愉悦感、最快可演示路径和自我问题解决
完成诊断后，技能会强制生成2-3种实现方案（必须包含"最小可行"与"理想架构"两种极端），最终输出结构化设计文档（Startup版含需求证据、现状工作流、成功标准；Builder版侧重"酷"的因素与下一步行动），并以信号反射式结束语完成交接。
显著优点
1. 方法论权威性：直接移植YC数十年验证的创业者辅导框架，将"具体性是唯一货币""兴趣不是需求""现状是真正的竞争对手"等经典原则转化为可执行的操作流程
2. 模式智能适配：自动识别用户场景，对Startup创始人使用尖锐追问防止自我欺骗，对Builder给予生成性支持保持探索热情，避免一刀切的咨询方式
3. 强制方案对比：阶段4强制要求至少2种、建议3种实现路径，打破"只有一个正确答案"的思维定式，尤其强制包含"最小可行"与"理想架构"的极端对比
4. 文档资产沉淀：输出符合工程规范的设计文档模板，可直接进入项目版本管理，成为团队协作的单一事实来源
5. 风险前置暴露：通过"前提挑战"阶段主动质疑"这是正确的问题吗""如果不做会怎样"，在项目早期识别方向性错误
潜在缺点与局限性
1. 语言与文化适配：虽然支持5种语言，但YC风格以直接、尖锐著称，在东亚商业文化中可能被感知为冒犯，用户需调整语气或心理准备
2. 执行依赖度极高：技能仅提供对话框架，六个问题的深度追问完全依赖用户配合。若用户回避具体性、用抽象概念回应，诊断效果将大幅衰减
3. 领域覆盖盲区：对硬件创业、合规密集型行业（医疗、金融）、B2G（政府客户）等场景，YC的软件/SaaS基因可能产生方法论错位
4. 无法替代真实用户访谈：技能追问的是"创始人声称的认知"，而非真实用户数据。若创始人从未接触用户，技能会放大而非纠正这一错误
5. 模板化输出风险：设计文档的结构性可能让用户产生"已完成验证"的错觉，忽视实际的市场测试
适合的目标群体
核心用户：
- 首次创业的早期创始人（Pre-product至有用户无付费阶段）
- 企业内部创新项目负责人，需要在内部汇报前厘清产品逻辑
- hackathon 参赛者，需在48小时内确定可演示的MVP范围
- 独立开发者启动副项目前，验证"为自己构建"的直觉是否具备外部需求
不适用场景：
- 已有付费客户、进入规模化阶段的产品优化
- 纯技术研究或无明确交付物的探索项目
- 需要深度行业know-how的垂直领域（如特定合规要求的金融基础设施）
使用风险
常规性能风险：
- 低。纯Markdown文档型技能，无外部API调用、无代码执行、无依赖项。启动与运行仅消耗对话token，无计算资源风险。
数据与隐私风险：
- 技能会建议读取项目中的CLAUDE.md、TODOS.md等文档及Git历史以理解上下文，但不会主动写入文件。用户需注意：若项目中包含敏感信息（未脱敏的客户数据、硬编码密钥），在对话中披露将暴露在对话历史中
依赖与维护风险：
- 低。无外部依赖，MIT-0许可证允许自由修改。但来源为T3级个人开发者（x-rayluan），无公开GitHub仓库可审计，长期维护存在不确定性
方法论误用风险：
- 关键风险：技能输出的是"结构化假设"而非"验证事实"。用户可能将生成的设计文档误认为已验证的路线图，跳过实际的用户访谈与MVP测试
- 建议 mitigation：在技能输出的"成功标准"部分，强制要求包含"本周内可完成的用户验证行动"，而非仅技术交付物
文化冲突风险：
- Startup模式的尖锐追问风格可能在团队使用中引发防御反应，建议在1:1场景或明确告知风格预期的环境下使用