Offerpilot

在做 Offerpilot 之前，我用 Gemini 和豆包做过一场字节跳动 AI PM 岗的模拟面试。 50 分钟下来，体验并不好。

三个不踏实的瞬间

那个晚上的关键时刻

用完这两个工具之后，我的第一反应是：「是我太菜了吗？」而不是：「这个工具有问题。」

那一刻，我自己就是那个被工具伤到的用户。

“真正卡住用户的不是模型能力，是产品没在模型不可控的输出之上做工艺。

Offerpilot 的三个核心决策，就是为了让下一个用户不必经历我那一晚的不踏实。

Offerpilot 是一个面向 PM / UX / HCI 应届与转岗候选人的 AI 模拟面试教练。它由三屏构成： Setup（填资料、上传简历）、 Interview（多轮对话 + STAR 脚手架）、 Report（雷达图 + 红黑榜 + 答案重构）。

核心人设是「懂大厂逻辑的温和引导者」，资深业务 Leader 与产品教练的混合体。它不是一个 chat 套壳，而是一套把面试官的隐性经验显式编码进 system prompt 的产品系统。

面临的冲突

AI 模型本质上是慢的、不可控的、容易跑题的。如果等模型把整段回答全部生成完再展示，用户从点击到看到第一个字要等 8–15 秒，会以为系统卡死了；但如果让模型完全自主决定问什么、问几轮，实测它会「上来就抛最难的题」打击信心，或者「在同一个问题上追问八轮」消耗耐心。

更深层的冲突是：用户对 AI 的信任成本远高于对真人。一次模糊体验，用户就会归因为「AI 不行」。

我的决策

把问题拆成两层来解：用「流式输出」解决"速度感"，用「四阶段对话框架」解决"结构感"。

• 速度感：让模型边生成边推送，前端用打字机动效逐字渲染。用户看到第一个字的时间从 8 秒压到 800 毫秒。
• 结构感：在给 AI 的指令里硬编码四个阶段（ 破冰 → 简历深挖 → 场景实战 → 反问），并规定每阶段最多问几轮。每条 AI 消息前面都带一个「阶段·主题」前缀，前端拿这个前缀渲染成顶部的进度条。

体验收益

用户的节奏从「输入 → 等待 → 输入 → 等待」切换成「全程都在交互」，和真人面试的节奏拉齐。顶部的阶段进度条还能消解一个隐性焦虑：「AI 会不会一直没完没了地问下去？」

“「阶段·主题」前缀不光是进度指示，它还在帮候选人看懂问题意图：候选人在被问的过程中就意识到「这是在考察我的项目深度」。

面临的冲突

最朴素的「提示」方案是：用户说「我不会，给我点提示」， AI 在对话里回一段 STAR 框架的文字解释。这有两个隐性问题：

• 认知降级失败：用户看完一段文字提示，依然不知道"在哪里填什么"，焦虑并没有真正缓解。
• 评分公平性污染：提示一旦进入对话历史， AI 后续会「记得用户被救援过」，影响最终评分的客观性。

我的决策

做一个「会答题的卡片」，三件事同时解决：

• 把提示变成可填的表单卡片：用户点「给我点提示」，对话流里直接出现一张 STAR 脚手架卡片，把 S / T / A / R 四个字段做成可输入的表单。「我不会」的瞬间被重构为「我只要往四个格子里填东西」。
• 每个字段独立的微提示：每个格子右上角有一个按钮，点一下就调用 AI 生成针对这个字段的一句话提示。提示长度限制在 200 字以内，并且准备了一套兜底文案，万一 AI 返回空内容也不破坏体验。
• 评分公平性的显式契约：用户提交卡片后，系统会在写回对话历史时加一个隐藏标记。 AI 在收到这个标记时被告知：「候选人借助了脚手架，不扣分，但可以在后续追问中验证答案的真实性」。

体验收益

心理摩擦从「我不会，怎么办」的模糊焦虑，变成「填四个格子」的可操作任务。评分公平性被显式写进契约，候选人心理上才真正敢于使用这条求助通路。

面临的冲突

复盘报告是产品的核心交付物，必须稳定地渲染成雷达图、红黑榜、STAR 重构卡片。任何字段缺失、格式不合法、评分越界都会让前端显示空白，等同于「产品没干活」。但要求 AI 严格按格式输出，又会牺牲它本可以写得更「教练味」的自由表达。

我的决策

设三道闸门 + 一层拟人化兜底，让失败也像产品体验：

• 生成闸门：要求 AI 严格按 JSON 格式输出，指令里写清楚每一个字段的要求（6 维评分 1–10、总分 0–100、红榜不超过 5 条、黑榜不超过 3 条）。
• 校验闸门：用 Zod schema 做结构校验，把不合法的数据挡在前端渲染层之外。字段缺失、评分越界、JSON 不合法，直接判失败、自动重试一次。
• 体验闸门：失败不暴露技术错误，包装成「教练正在重新组织语言」的 ErrorState，一键重试。整个报告生成是异步触发的：用户点「结束」后立即跳转到复盘页，看到的是「面试官正在回看对话」的过渡动画，不阻塞页面切换。

体验收益

复盘页 100% 可渲染，杜绝了「AI 写了一长串但图表是空的」。失败被包装成符合「教练」人设的语言，技术错误不会被翻译成情感伤害。

面临的冲突

前三个 trade-off 都在服务一类用户：愿意花 3 分钟填资料、上传简历、做完整面试的「真实候选人」。但 Offerpilot 还有另一类用户：评估者。HR、面试我的人、同行、想试一下产品的人。对他们来说，Setup 不是路径，是路障。

错误的解法是把 Setup 简化、降低候选人体验质量；也错误的是放任评估者在 Setup 流失，让产品永远缺一个「真实可玩」的入口。

我的决策

做一个独立的「演示模式」路径：不破坏主流程，只为评估者开一个零摩擦的旁门。

• Setup 页加一个低调的「Try Demo」入口
• 点击后跳过填表，预填一份模拟数据（字节 TikTok Shop AI PM 岗位 + 模拟简历）
• 进入 Interview 页后自动播放 2-3 轮对话，带 typewriter 动效，让评估者看见 AI 如何递进追问
• 播放结束自动跳转 Report 页，呈现预生成的完整复盘（雷达图 + 红黑榜 + STAR 重构）
• 任何阶段都可以「停下来，自己继续」，演示不剥夺控制权

体验收益

评估者从「想了解 → 实际看完产品全貌」的认知成本从 3 分钟 + 心理摩擦压到 30 秒 + 零摩擦。 portfolio 上从此不需要 Product Hero 截图：产品本身就是最好的展示。

这件事对我个人的价值更大。它让我意识到「只有一类用户」是一个习惯性的思维盲区。真实产品几乎从来没有只有一类用户，看到第二类、第三类用户存在并为他们做差异化设计，才是从「做出产品」到「做对产品」的分水岭。

做 Offerpilot 的过程中，我一直在问自己一个问题：如果它只是一个「prompt 写得很好」的工具，那它没有壁垒。 Prompt 可以被任何人在 5 分钟内复制。 AI 产品真正的护城河，从来不在 prompt 这一层。

所以我对 Offerpilot 的护城河演进有 3 个判断。

短期 · 产品系统化

Offerpilot 不是「一个 prompt 解决所有问题」，而是五层整合：prompt + 状态机 + GenUI 脚手架 + 报告 schema 校验 + 拟人化兜底。这五层之间是相互依赖的： STAR 脚手架只在状态机判断「用户卡壳」时触发； schema 校验失败时，拟人化兜底立刻接管；整个对话节奏由阶段 budget 控制。

这意味着：复制我的 prompt 只需要 5 分钟，复制我的产品却并不容易。这是当下我能建立的最实在的壁垒。

中期 · 领域专业度

Offerpilot 和通用 ChatGPT 的差别，不在于「能不能生成面试问题」，而在于它知不知道一轮面试该怎么往下走。

什么时候追问项目细节，什么时候停下来帮候选人补 STAR，什么时候继续施压，什么时候该收束，这些判断都不能只靠一句 prompt 解决。

所以中期真正要积累的，是一套面试教练的判断库：不同岗位怎么问，哪些回答算空，哪些细节值得追，以及评分时怎么把扣分点和候选人的原话对应起来。

长期 · 数据飞轮

面试场景有一个独特优势：结果是可验证的。用户用 Offerpilot 准备完，最终在真实面试里通没通过、拿没拿到 offer，是一个明确的 ground truth 信号。

积累一定用户量后，Offerpilot 会拥有一份其他工具没有的数据集：「应届生回答模式 → offer 转化率」。这份数据可以反过来微调评分模型、优化提问策略，形成不可被通用 AI 工具复制的飞轮。

这是 Offerpilot 想走的路径：不是更好的 prompt，是更深的产品。

四个 Trade-off 里最弱的一个

诚实说，第一个 trade-off（速度焦虑 vs 对话结构）是最容易被复制的。流式输出已经是 AI 产品的工业标准，任何团队两天就能做出来；四阶段框架 + round budget 这部分有产品判断，但拆开看每条单独都不构成门槛。

回头看，trade-off 1 的真正价值不在传输技术或 UI，而是「把面试官的隐性节奏经验显式编码」这一判断本身。但作为 case study 里展示的护城河，它的辨识度确实最低。如果重写护城河叙事，我会把它从「核心决策」降级为「基础设施」，把笔墨更多投入到 trade-off 2 和 3，那两条才真正长在 HCI 方法论的交叉点上。

如果重做

我最想动手改的，是 Interview 页左侧的简历显示。现在它只是一块静态的「已上传简历」文本。但我最初的设想是：当 AI 面试官追问简历中的某段经历时，对应的句子在左侧自动高亮。

这是一个能让候选人在被问的瞬间「立刻知道 AI 在追问哪里」的认知锚点。它代表 Offerpilot 下一层的工艺提升：从「单向文字对话」走向「同步可视化的双向引用」。这件事我没在 v1 做出来，是 case study 里我自己最不甘心的地方。

这个项目让我对「AI PM」的理解变了什么

做 Offerpilot 之前，我对 AI PM 的理解大致是：定好产品方向 → 做调研 → 把产品落地。

做完之后，我觉得这个理解只对了三分之一。真实的 AI 产品工作里：

• 讲好故事比「调研充分」更难。让别人在 30 秒内 get 到产品的不可替代性，是核心生存技能
• 商业化价值比「产品落地」更难。一个不能解释清楚用户付费意愿和 ROI 闭环的 AI 产品没有未来
• 技术壁垒比「产品方向」更难。 prompt 写得好不是壁垒；整合产品系统、积累垂直领域数据、建立评估闭环，这些才是

我对这三件事的理解依然模糊。但相比做 Offerpilot 之前，我至少知道了「我应该往这三件事走」。