这个claude code 插件问得问题就是投资人要问的

一个叫 /office-hours 的命令，在你写第一行代码之前，先把你逼进 YC 路演现场。

最近 YC 的总裁 Garry Tan 开源了一个叫 gstack 的工具——他用 Claude Code 写代码时的完整工具链。数据有点夸张：60 天写了超过 60 万行生产代码，最近 7 天 14 万行新增、362 个 commit。

GitHub 上线 48 小时，突破 1 万 star，一周内超过 3.3 万 star、4000 个 fork，登上 Product Hunt 当日榜首。

这个工具有很多功能，比如 /review（像 Staff Engineer 一样审查代码）、/qa（真实打开 Chrome 浏览器跑测试）、/ship（一键推 PR）。

但我最想聊的，是一个叫 /office-hours 的命令。

因为它问的问题，和投资人要问的，几乎一模一样。

/office-hours 是什么？

字面意思是”答疑时间”。

在 YC，Office Hours 是创始人和合伙人面对面坐下来、把你的想法彻底拷问一遍的环节。不是鼓励你，是质问你。

gstack 的 /office-hours 做的是同样的事——只不过你的”合伙人”是 Claude。

它的定位非常清晰：在你写第一行代码之前运行。

官方的描述是：当你描述一个新产品想法、或者在探索某件事情是否值得去做的时候，主动触发它。先过 /office-hours，再去写代码。

它会问你什么？

这里有两个模式。

创始人模式（Founder Mode），给的是 6 个”强迫性问题”——这 6 个问题，是从 YC 合伙人评估产品的方式中提炼出来的：

1. 需求现实性
   
   ：真的有人需要这个吗？不是”可能会有人”，是真的有。
2. 现状调研
   
   ：人们现在怎么解决这个问题？为什么现有方案不够好？
3. 极致具体性
   
   ：你能不能说出一个具体的人名，一个真实存在的用户，他有这个痛点？
4. 最窄切入点
   
   ：你能把范围缩到最小，先验证最核心的假设吗？
5. 观察与惊喜
   
   ：你有没有发现什么让你觉得”这个地方好奇怪，没人做过”的事情？
6. 未来适配性
   
   ：五年后这个产品还有意义吗？

这些问题，是故意让你不舒服的。

官方文档里直接说了：“If you can’t name a specific human who needs your product, that’s the most important thing to learn before writing any code.”（如果你说不出一个具体的人名，这就是你在写任何代码之前最该搞清楚的事。）

建造者模式（Builder Mode），给的是另一套——适合黑客马拉松、副业项目、开源项目、或者单纯想玩：Claude 变成一个热情的协作者，帮你找到这个想法最酷的版本。”这个东西能让人说’哇’吗？””最快能分享出去的路径是什么？”问题是发散的，而不是审讯式的。

两个模式都会在最后生成一份设计文档，保存在 ~/.gstack/projects/ 目录下。

这份文档不只是留存，它是后续整个流程的输入：

/office-hours → /plan-ceo-review → /plan-eng-review → 写代码 → /review → /qa → /ship → /retro

也就是说，/office-hours 的产出，会被下一个命令 /plan-ceo-review（用 CEO 视角挑战你的优先级）直接读取，再往后是 /plan-eng-review（锁定技术架构）。

整个软件开发流水线，从”想法是否值得做”开始，是完整打通的。

我对比了一下 YC 官方的 Startup School 课程里反复强调的东西，和 /office-hours 的 6 个问题几乎逐条对应：

1. “Talk to users”（找真实用户）→ 极致具体性
2. “Do things that don’t scale”（先找到最小切入）→ 最窄切入点
3. “What problem are you solving”（现状调研）→ 需求现实性 + 现状调研
4. “Why now”（为什么是现在）→ 未来适配性 + 观察与惊喜

这不是巧合。这就是 Garry Tan 把他在 YC 做了十几年的产品判断，蒸馏成了一组 prompt。

投资人在 Demo Day 之前要 Office Hours，问的是这些。你在写代码之前，现在也可以先被问这些。

假设你想做一个”日历摘要 App”。

你打开 Claude Code，输入 /office-hours，描述你的想法。

Claude 不会立刻开始写代码。它会问你：

“你能说出一个具体的人，他现在每天花时间在整理日历摘要这件事上吗？他是谁？他用什么方式现在解决这个问题？”

你可能一下子答不上来。

这就是重点。

文档里举的例子是这样的：你说你要做”日历摘要 App”，Claude 可能会反问你：”你说的是日历摘要，但你真正在做的，其实是一个个人 AI 参谋。”

这种重新定义问题的方式，就是好的 Office Hours 该做的事。

有人批评 gstack 说：”这不就是一堆 Markdown 文件里的提示词吗？”

是的，就是这样。

但问题是：这些提示词，是从一个真实跑通了的软件工厂里提炼出来的。Garry Tan 用这套流程，一个人，60 天写了 60 万行代码，其中 35% 是测试代码。

这不是理论，是已经跑通的实践。

/office-hours 的价值不在于它有多”智能”，而在于它强制你在动手之前先停下来想清楚。大多数工程师，包括我，最容易犯的错误就是：想法一来就开始写代码，写了一半才发现问题设错了。

这个插件把 YC 合伙人的追问变成了一个仪式：先过这一关，再开始建造。

最扎心的是，如果gstack觉得你的项目没前途，会直接告诉你：不要做了，浪费时间~

https://github.com/garrytan/gstack