夜雨聆风如果看完上一篇，你只想先学一个 skill，那我会建议先学 /office-hours。
原因很简单。
很多项目不是死在“做不出来”，而是死在“从一开始就在解错的问题”。
而 /office-hours 做的，正是把这个最容易被跳过、但又最致命的阶段，强行拉回桌面上。
它的价值不在于“陪你想想点子”，而在于：在你开始实现之前，先逼你把问题定义清楚。
所谓的效率：把 3 个小时的事情 1 小时做完。
真正的效率：花 5 分钟决定是否要做，做什么
为什么我觉得很多人第一次就会用错它
第一次接触 gstack，很容易这样走：
先让 agent 帮我搭个项目 先把登录、首页、数据库建起来 或者直接上 /plan-eng-review
这些动作当然都能做。
但顺序往往是错的。
因为只要问题本身还没说清楚，后面做得越快，偏得也越快。
你以为你在推进，其实你只是在高效率地把一个模糊想法，包装成一个更复杂的错误方向。
这就是为什么 gstack 的文档会把 /office-hours 放在非常靠前的位置。它不是热身动作，也不是可有可无的 brainstorm，它是后面很多 skill 的起点。
/office-hours 到底在做什么
一句话讲清楚：
它是一个“问题定义器”，不是一个“代码生成器”。
而且这不是我自己的理解，repo 里对它有一个非常硬的约束：
不写代码 不 scaffold 项目 不进入实现 只产出 design doc
这点非常重要。
因为很多 AI 工具一旦接到一个想法，会天然滑向实现层：先建页面、先列表结构、先搭表、先写 API。
但 /office-hours 刻意把这条路切断了。
它会先问：
你到底想解决什么问题？ 这个问题谁最痛？ 他们现在怎么凑合着解决？ 最小可成立的切口是什么？ 你说的是一个功能，还是其实在说另一个更大的产品？
也就是说，它不是顺着你的表述往下接，而是先检查你的表述本身是不是站得住。
它最有价值的一点：会重写你的问题，而不是迎合你的问题
repo 文档里有一个很好的例子。
有人一开始说，自己想做一个“给日历用的 daily briefing app”。
这听起来已经很具体了，对吧？
普通 agent 很可能会马上开始想：
日历怎么接 Google Calendar 首页怎么展示每天日程 briefing 卡片怎么布局 需要哪些数据库表
但 /office-hours 没这么走。
它先追问对方真正的痛点：多账号日历信息过期、会前准备资料质量低、地点信息经常错、很多事情要靠人肉追。
最后它给出的结论不是“你在做一个 briefing app”，而是：
你真正描述的，是一个 personal chief of staff AI。
这个重写非常关键。
因为一旦问题被重写，后面的产品边界、实现优先级、最小切口，都会跟着变。
这就是 /office-hours 和普通 brainstorm 最大的区别。
它不是陪你把想法说得更顺，而是试图把你真正要做的东西，从你嘴里的第一版表述里挖出来。
它不是只会问问题，而是有一套明确流程
/office-hours 不是“随便聊几轮”。它背后有一条很清楚的流程。
第一步：先判断你现在属于哪种模式
它上来会先问你的目标是什么。
然后把你路由到两种模式之一：
Startup modeBuilder mode
这个区分很重要，因为它决定了它接下来怎么问你。
Startup mode：如果你是在做创业或内部创业
这时候它不会跟你轻松 brainstorm，而是会直接上硬问题。
它的核心是六个 forcing questions，问的不是“这个 idea 听起来酷不酷”，而是：
有没有真实需求，而不是只有兴趣 用户现在用什么 workaround 在解决这个问题 最需要这个产品的是哪个具体的人 最小可付费的 wedge 是什么 你有没有真的观察过用户行为，而不是只听过反馈 三年后世界变化了，这个产品会更重要还是更不重要
你会发现，这六个问题有一个共同点：它们都在逼你从“概念”退回到“现实”。
不是看愿景讲得多大，而是看有没有真实的人、真实行为、真实代价。
Builder mode：如果你是在做 side project、hackathon、开源、学习
它的语气会变，但不是变敷衍，而是换一套判断逻辑。
这时候它更关心的是：
这个东西最酷的版本是什么 做成什么样别人会说“这个有意思” 最快多久能做出一个你能自己用、也能拿去分享的版本 市面上最像它的东西是什么，你到底哪里不一样 如果时间无限，你心里那个 10x 版本是什么
也就是说，Builder mode 不是拷问商业成立性，而是帮助你更快找到一个值得做、值得展示的版本。
这也是我很喜欢这个 skill 的地方：它没有假装所有项目都必须按创业逻辑来审视。
它中间还会做两件事：挑战 premise，给出方案分叉
很多人以为 /office-hours 就是“问完问题，写个总结”。
不是。
它中间还有两个很关键的动作。
1. Premise challenge
它会把你刚才说过的话，整理成几条产品前提，再让你确认。
比如：
这个产品真正的价值是不是不在底层数据，而在上面的 intelligence layer 当前最窄的切口是不是某一个特定工作流 某个能力到底是 nice to have，还是第一版就必须有
这一步的意义在于，很多讨论在聊天时看似一致，真正写进文档时却并不成立。
/office-hours 会先把这些 premise 拉出来，逼你看一遍，再往下走。
2. Alternatives generation
它不会只给一个方向，而是会给你 2 到 3 条具体路径。
而且不是抽象大词，是相对可落地的方案分叉，比如：
最窄切口先跑通 先做关系数据层，再做上层体验 直接做全景版本
更重要的是，它会给出 effort 对比，并推荐一个更适合作为第一步的方案。
所以 /office-hours 的产出不是“你这个 idea 不错”，而是：
你到底在做什么 这个判断成立的依据是什么 有哪几条路可走 为什么现在更应该走哪一条
它最重要的产出，不是聊天记录，而是 design doc
这是第二个必须讲清楚的地方。
/office-hours 的真正产出，不是对话本身，而是一份 design doc。
这份文档会被写到 ~/.gstack/projects/ 下面，并且会进入后面的 skill 流程里。
也就是说，后面的：
/plan-ceo-review/plan-eng-review
都不是从零开始，而是会接着这份 design doc 往下走。
这就是为什么我说 /office-hours 不是热身。
它是在给后面的所有动作打底。
更细一点说，这份文档里通常会包含：
问题定义 当前状态和现实替代方案 目标用户与最小切口 关键 premise 方案分叉 推荐路径 开放问题 成功标准 下一步动作
同一分支上如果你多次跑 /office-hours，它甚至还会形成一条设计演进链，而不是每次都像重新开一个新世界。
什么时候一定要先跑 /office-hours
如果你有下面这些状态，我会建议直接先用它：
你能说出一堆功能，但说不清最先该做哪一个 你总在讲“平台”，却说不清第一步最小切口是什么 你说得出 idea，但说不清到底是谁最痛 你觉得自己方向大致对，但越想越虚 你想做一个 side project，但不知道怎样才能最快做出一个“值得展示”的版本
说白了，只要你现在卡的不是“怎么实现”，而是“到底该做什么”，那 /office-hours 就很适合先上。
什么场景不一定要用它
它不是万能起手式。
下面这些场景，就不一定需要先跑 /office-hours：
你是在修一个已经定位清楚的 bug 你只是在改一个很明确的小需求 你已经有一份成熟的 design doc，只是在做局部实现 你处理的是纯工程基础设施问题，问题定义本身并不模糊
这里的判断标准很简单：
如果问题已经非常清楚，继续做问题定义的收益就会下降。
这时候你更应该去的是 /plan-eng-review、/investigate、/review 这类下游 skill。
最小使用方法，其实非常简单
真要上手，反而没那么复杂。
你基本只需要做四件事：
直接输入 /office-hours认真回答它最开始关于“你的目标是什么”的问题 不要急着催它写代码，重点看它怎么重写问题、怎么挑战 premise 最后认真看它写出来的 design doc
如果这份 design doc 你自己都觉得更清楚了，下一步再进入：
/plan-ceo-review：继续挑战产品方向和 scope/plan-eng-review：把方案压成可实现、可测试、可交付的工程计划
这才是顺的。
为什么我会说，这是 gstack 里最值得先讲清楚的 skill
因为它解决的是一个非常基础、但又非常常见的问题：
很多人以为自己缺的是实现速度，实际上缺的是问题定义能力。
AI 把实现的门槛拉低之后，这个问题只会变得更明显。
以前你因为写得慢，错得也慢；现在你写得很快，错得也更快。
所以 /office-hours 的意义，不只是“让你想清楚一点”。
它是在 AI 时代把一个老问题重新摆到了台面上：
在你把几十小时、几百小时扔进实现之前，你最好先确认自己到底在做什么。
这一步看起来最不性感，但它恰恰最值钱。
下一篇，我会接着写方案阶段。
因为问题定义清楚之后，也还不能立刻开写。gstack 在这个阶段给的不是一个 review，而是四件套：/plan-ceo-review、/plan-eng-review、/plan-design-review、/design-consultation。
