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 后续会「记得用户被救援过」，影响最终评分的客观性。

我的决策

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

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

体验收益

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

面临的冲突

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

我的决策

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

• 生成闸门：要求 AI 严格按 JSON 格式输出， 指令里写清楚每一个字段的要求（6 维评分 1–10、总分 0–100、 红榜不超过 5 条、黑榜不超过 3 条）。
• 校验闸门：用一道严格的结构校验 把不合法的数据挡在前端渲染层之外。 字段缺失、评分越界、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 在 LLM 黑盒之上做了三道决策门。节奏门管对话推进速度，策略门管对答案的应对方式，兜底门管失败时不伤害用户。

这三道门一起决定了「OfferPilot 在每一秒到底做什么」。

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

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

短期 · 产品系统化

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

这意味着：复制我的 prompt 只需要 5 分钟，复制整个产品系统需要 2-3 个月。 这是当下我能建立的最实在的壁垒。

中期 · 领域专业度

OfferPilot 真正区别于 ChatGPT 类通用工具的， 不是技术能力，是「产品人懂不懂面试」的判断力。

四阶段对话节奏、STAR 脚手架的认知降级设计、 「教练 vs 评委」的人设取舍， 这些都不是「AI 能做或不能做」的问题， 而是需要同时具备 HCI 用户研究方法论 和 AI 产品工艺才能做出的产品决策。

一个纯工程师不会去想「用户卡壳时的心理摩擦如何降级」； 一个纯设计师不会去做 STAR 标记的评分公平性契约。OfferPilot 的核心壁垒，长在两个学科的交叉点上。

长期 · 数据飞轮

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

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

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

关于用户测试

坦白说，OfferPilot 的正式用户测试还没展开。 这是 case study 里我必须承认的最大空白。

但产品的核心决策并不是凭空想象的。 Origin 里那场我自己用 Gemini + 豆包做的 50 分钟实测， 本质上是一次启发式竞品评估（HCI 学术里叫 autoethnography）： 我把自己作为目标用户，亲历通用 AI 工具失败的具体瞬间， 再反推 OfferPilot 应该在哪些地方做产品级回应。 通用工具失败的位置，正是 OfferPilot 设计要补的位。

下一步要做的事很清楚：

• 招募 3-5 个正在准备 PM / AI PM 求职的朋友试用 OfferPilot
• 记录他们的「被卡壳瞬间」和对复盘报告的真实反应
• 追踪他们之后真实面试的结果，建立「使用 → offer 转化」的初始数据集

这一步还没做。但它会做。

四个 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 之前， 我至少知道了「我应该往这三件事走」。