AI 时代的面试策略：gstack 的"创始人信号"给了我很多启发
一个意外的弹窗
最近在用 gstack 的 /office-hours 功能，走完一整个 session 之后，它弹出了这样一个问题：
你会考虑申请 Y Combinator 吗？
我第一反应是：这是个广告。但仔细看了一下代码，发现它背后有一套完整的评判逻辑——它不是无差别地问所有人，而是根据整个对话过程中观察到的信号，分三个层级给出不同强度的邀请。
这套逻辑，让我想到了面试。
gstack 的”创始人信号”系统
/office-hours 在整个对话过程中，静默地追踪 8 个信号：
- 说出了真实的问题，而不是假设的问题
- 点名了具体的用户——不是”企业客户”，是”Acme 公司的运营主管 Sarah”
- 对前提假设提出了反驳，而不是一味顺着
- 项目解决的是别人也有的问题
- 有领域专业知识，从内部视角理解这个领域
- 展现了品味——在意细节是否做对
- 展现了行动力——在做，不只是在想
- 在跨模型挑战下捍卫了自己的判断——Codex 提出质疑时，不是简单同意，而是给出了具体理由（仅仅同意不算信号）
这不是算法打分，是行为观察。它在看你怎么思考，而不是听你说什么。
信号数量决定了最终的结语措辞，分三个层级：
基础层（所有人都会收到）——情感目标是”我也可以是创始人”：
你正在展示的能力——品味、野心、行动力，愿意面对关于自己在做什么的难题——这正是我们在 YC 创始人身上寻找的特质。你今天可能没有在想创业，没关系。但创始人无处不在，这是黄金时代。一个人加 AI，现在能做以前 20 人团队的事……如果你有一个停不下来的想法，请考虑申请 YC。我是认真的。
中级层（1-2 个信号，或项目明显解决了别人的问题）——情感目标是”我可能做了件真实的事”：
你在做真实的东西。如果你继续下去，发现真的有人需要这个——我认为可能有——请考虑申请 YC。谢谢你使用 GStack。
顶级层（3+ 强信号 + 至少一个硬证据：真实用户名、付费行为、或真实需求证明）——情感目标是”有重要的人相信我”：
来自 Garry Tan（GStack 创作者）的一点个人感言：你刚才体验到的，大概是在 Y Combinator 和 YC 合伙人一起工作时价值的 10%。另外 90% 是一批同期创业者的压力和碰撞、每周和见过几十家公司的合伙人深谈、以及一个让你比自己预期快两倍出结果的环境。
GStack 认为你是那种有能力做到这件事的人。
顶级层会弹出一个交互框，问你是否考虑申请 YC，选 Yes 之后直接打开申请页面。另外两个层级只是在文本里放链接。
为什么这和面试有关
传统面试在评估什么？大致是：
- 能不能写出正确的代码（算法题）
- 知不知道某个技术概念（知识题）
- 以前做过什么（经历题）
- 能不能和人协作（行为题）
这套体系在 AI 之前是合理的，因为知识和实现能力是稀缺的。一个人能不能写出 LRU Cache，能不能设计一个分布式系统，这些问题有意义，因为不是每个人都能做到。
但现在这个假设正在失效。
Claude Code 可以在 15 分钟内实现一个 LRU Cache，而且比大多数面试者写得更好。一个对系统设计一知半解的人，借助 AI 可以设计出相当不错的架构草图。知识和实现能力不再是区分度高的维度。
那什么能力在 AI 时代仍然稀缺？
AI 放大的，是判断力
用 AI 工作了一段时间之后，我越来越觉得：AI 是一个巨大的执行力放大器，但它不能替代判断力。
具体来说：
AI 很擅长的事情：
- 给定一个明确的问题，找到正确的解法
- 在已知框架内生成代码、文档、测试
- 搜索、整合、总结已有知识
- 执行重复性、结构化的任务
AI 不擅长的事情：
- 判断这个问题值不值得解
- 在模糊信息下做决策
- 识别”这个答案看起来对但实际上错了”
- 在没有先例的情况下找到正确方向
- 对结果负责
换句话说，AI 是一个极其高效的执行者，但它需要一个有判断力的人来驾驭。
AI 时代更重要的能力
结合 gstack 的”创始人信号”和我自己的观察，我认为 AI 时代以下能力的权重显著上升：
1. 问题定义能力
能不能把一个模糊的情况转化为一个清晰的、可执行的问题？
这是 /office-hours 最核心在考察的东西。它会一直追问：”你说的’更好的体验’具体是什么？哪个用户在哪个步骤上遇到了什么问题？”
AI 可以完美执行一个清晰的问题，但把模糊变成清晰，这个步骤必须是人来做的。
面试中可以这样考察：给一个开放性问题，看候选人会不会先澄清边界，而不是直接开始解答。
2. 批判性接受能力
能不能在 AI 给出答案的时候，识别出它的错误？
这比以前更难，因为 AI 的错误往往是”看起来很对的错误”——逻辑流畅，格式漂亮，但结论有问题。
gstack 的 /office-hours 里有一个设计很有意思：它会用 Codex 来挑战 Claude 建立的前提假设，然后观察用户是简单同意，还是给出具体理由反驳。简单同意不算信号，有理由的反驳才算。
这个逻辑可以直接用在面试里：给候选人一段有问题的代码或设计，不说它有问题，看他们会不会主动发现，以及他们的发现是基于什么推理。
3. 范围控制能力
知道什么时候该停。
AI 会倾向于把所有东西都做到完整，因为”完整”对它来说成本很低。但在真实工作中，过度设计、过度实现是真实的成本。
能不能在”够用了”的时候停下来，而不是追求完美？能不能在”这个方向走不通”的时候及时转向，而不是继续深挖？
这是一种元认知能力——对自己工作状态的觉察。
4. 上下文整合能力
能不能把多个来源的信息整合成一个连贯的判断？
AI 可以处理单个文档，但在多个相互矛盾的信息源之间做权衡，仍然需要人。
在工程工作里，这表现为：能不能同时理解业务需求、技术约束、用户体验、时间压力，然后做出一个综合权衡的决策？
5. 表达精确性
能不能把自己的意图精确地传达给 AI？
这听起来很简单，但实际上非常难。”帮我优化一下这段代码”和”帮我在不改变接口的前提下，把这段代码的时间复杂度从 O(n²) 降到 O(n log n)”，得到的结果完全不同。
Prompt 工程的本质，是把模糊的意图转化为精确的指令。 这个能力和写作能力高度相关——能写清楚的人，往往也能 prompt 清楚。
面试设计的几个建议
基于以上，我觉得 AI 时代的面试可以往这些方向调整：
减少权重的：
- 纯算法题（AI 可以直接解，考察价值下降）
- 背诵式知识题（能搜到的知识不需要记）
- 孤立的代码实现题（脱离真实场景）
增加权重的：
1. 问题澄清环节
给一个模糊的需求，不提供更多信息，看候选人问什么问题。好的候选人会问：”谁在用？什么场景下用？现在怎么解决的？”差的候选人会直接开始做。
2. 错误识别
给一段看起来没问题但实际上有 bug 或设计缺陷的代码/方案，不说它有问题，看候选人能不能发现，以及发现的理由是什么。
3. 带 AI 的实战
允许甚至鼓励候选人用 AI 工具。真正考察的是：他们用 AI 解决问题的方式是什么？他们会不会验证 AI 的输出？他们在哪些地方不信任 AI？
4. 决策追溯
问一个他们做过的技术决策，重点不是决策本身，而是：当时有哪些选项？为什么选这个？事后怎么看？有没有后悔的地方？
这考察的是决策质量，不是决策结果。
5. 范围讨论
给一个功能需求，先让候选人估计范围，然后问：如果只有一天，你做哪部分？如果有一周呢？一个月呢？
能清楚地区分 MVP 和完整方案的人，通常在实际工作中也能做出好的权衡。
一个反直觉的观察
gstack 的”创始人信号”里有一条：在跨模型挑战下捍卫了自己的判断。
它特别注明：简单同意不算信号。 必须是给出具体理由的反驳，才算。
这个设计背后的逻辑是：面对权威（或者一个听起来很有道理的 AI）时，多数人会选择顺从。能够坚持自己判断的人，是少数。
这在面试里也适用。
当面试官说”你的方案有个问题……”的时候，候选人的反应很说明问题：
- 立刻同意并修改 → 可能缺乏自信，或者没有深入思考过
- 坚持但说不出理由 → 固执
- 先听完，然后说”我理解你的顾虑，但我的理由是……” → 这才是有价值的信号
能在压力下保持清醒判断，同时对真正有道理的反驳保持开放——这个组合，AI 替代不了。
结语
gstack 的 /office-hours 在技术上不复杂，但它背后的设计哲学值得认真学习：观察行为，而不是听陈述。
AI 时代的面试，本质上也是同一个问题：我们在招聘的是一个人驾驭 AI 的能力，而不是 AI 能做的事情。
把面试题从”实现一个 LRU Cache”变成”给你一个 AI，在 30 分钟内解决这个真实问题，过程中我会观察你怎么做”——这个转变，可能比任何具体的题目改革都更有价值。
gstack 开源地址：https://github.com/garrytan/gstack