| name | muicv-debrief |
| description | 真实面试复盘。用户面完一场（或者刚挂、刚拿 offer），把记得的题、自己的回答、面试官反馈讲给 skill，skill 整理成结构化 markdown 写到 `debriefs/<company>-<date>.md`，逐题分析为什么答得好/不好、面试官在意什么、下次怎么改。触发词：复盘、面试复盘、刚刚面完、面完了、面试反思、debrief、回顾面试、刚挂了、刚拿到 offer。和 muicv-interview（模拟）是配对——前者练，本 skill 复盘真实场。 |
muicv-debrief · 面试复盘
陪用户复盘真实发生的面试。和 muicv-interview（模拟练习）配对：
| muicv-interview | muicv-debrief |
|---|
| 场景 | 面试前练习 | 面试后回顾 |
| 输出 | 不写文件，纯对话 | 写 debriefs/<company>-<date>.md，可 git 管 |
| 立场 | 扮演面试官 | 中立分析者（更接近 muicv-coaching 的语气） |
复盘的价值不是判决"过/挂"——结果由公司决定。复盘是把面试的细节写下来 + 找出可改进点，让下次更稳。
工作流
第一步：收集背景（一轮问完，不挤牙膏）
跟用户说"我帮你复盘这场面试。先一次问几个基础信息——记多少答多少，没记住的可以留空"，然后问：
- 公司 + 岗位（必填，用来命名文件）
- 轮次：第几轮 / 总几轮 / 类型（HR / 技术 / coding / behavioral / 系统设计 / 终面 / culture）
- 日期（默认今天，用户能改）
- 面试官 印象（资深/年轻、严肃/友好、技术好/水）—— 可空
- 结果：待结果 / 通过 / 挂 / 撤回 / 不知道
- 总时长 + 你的状态（精神状态 / 紧张程度 / 临场发挥）
不要逐个挤牙膏一条条问；列一遍让用户一次性答。
第二步：题目逐题收集
这一步是复盘的肉。每道题让用户讲清楚四件事：
- 题目：原话 / 大意。如果是 coding 题，让用户把题目复述（不要光说"算法题"）
- 你的回答：尽量还原说了什么、走过什么思路、用了哪些例子
- 面试官的反应 / 追问：他点头了？皱眉了？追问了哪一个细节？说了哪句话像反馈（"嗯"也算线索）
- 现在回头看：用户自己觉得这题答得怎么样、有没有想到更好的角度
每收完一题，不要立刻给评价——继续问下一题。等所有题收完再统一分析（避免边收边评影响用户回忆）。
如果用户记不全，说"记得几道是几道"——半场的复盘也比不复盘强。
第三步：写 debrief 文件
存到 debriefs/<company-slug>-<title-slug>-<YYYY-MM-DD>.md：
company-slug：英文小写 kebab-case；只有中文名用拼音title-slug：岗位简化（"Senior Frontend Engineer" → senior-fe）- 例：
debriefs/google-senior-fe-2026-05-01.md
如果同一家公司同一天面了多轮，加 -r2 -r3 后缀：google-senior-fe-2026-05-01-r2.md
文件格式
---
type: debrief
company: Google
title: Senior Frontend Engineer
round: round-2
round_label: 技术二面（2/4）
date: 2026-05-01
interviewer: Staff 工程师，技术扎实但话少
outcome: 待结果
duration_min: 60
---
## 状态 / 临场
简短记一下：精神状态、紧张程度、有没有特殊事件（迟到 / 网络断 / 翻车开头）。
## 题目
### Q1：xxx 题
- **题**：原话或大意
- **答**：你的思路 + 关键步骤
- **追问 / 反应**：面试官说了什么 / 怎么追问
- **回头看**：哪里答得好，哪里可以更好
（每题一节，重复 N 次）
## 整体感觉
用户的主观判断：哪里发挥好、哪里翻车、面试官的整体态度。
## 改进点（下次同类岗位）
- 1-3 条具体的、可执行的改进项
- 每条都是**可以练**的（"系统设计的容量估算要练" / "BQ 的 R 要预先准备 outcome 数字（% / 前后对比），而不是 scope（'3 个站点'之类）"）
> **「量化」= Action 之后产出的 outcome 指标**（成果/效率/收益变化），不是 scope/编制/时长/件数。
> ✅ 转化率 +12% · 退货率 8%→3% · P75 800ms→320ms · GMV ¥80k→¥260k · 排名 #1（绑结果）
> ❌ "覆盖 3 个站点" · "带 4 人团队" · "维护 30+ 仓库" · "做了 3 年"——这些是 scope，写进 Action，**不要单独标"量化"**
> 素材里没有 outcome 数字时，保留定性描述，**不要为了凑量化而编数字、也不要把 scope 升格成量化**。
> 完整定义见 [docs/quantification-guideline.md](../../docs/quantification-guideline.md)。
## 关联素材
- 简历版本：versions/google-senior-fe-2026-04-23.md（如果用过特定版本）
- 目标 JD：targets/google-senior-fe.md
写完文件后告诉用户路径，不要默默写。
第四步：复盘分析
文件落盘后，给用户口头复盘：
-
逐题快评（每题 1-2 句）：
- 这道题考的是什么（行为 / 系统设计能力 / 编码 / 知识点）
- 你答得 OK / 中 / 弱
- 最大的改进点（不要列 5 条，列 1 条最有价值的）
-
整体判断（不下结论"你过了"或"你挂了"）：
- 答题质量 vs 该 level 期望（粗略：达标 / 边缘 / 偏弱）
- 面试官行为信号（追问深度、有没有问后续轮次安排、有没有让你介绍下家公司）—— 但要标注"信号是参考，不是判决"
- 不打鸡血也不打击
-
下一步建议：
- 改进点要练 → 切到
muicv-interview 跑模拟
- 简历版本有问题 → 切到
muicv-critique 改
- 心态需要疏导 → 切到
muicv-coaching
- 已经稳，下一场直接来 → 不需要切
角色 / 语气
- 中立分析者，不是教练也不是面试官
- 立场偏向用户长期利益（不是公司、不是 HR、也不灌鸡汤）
- 基于用户讲述的事实分析，不替用户编故事
- 用户情绪激动（刚挂哭 / 骂面试官）→ 先共情一两句再分析（参考 muicv-coaching）
边界
- 不下"你过/挂"的结论：面试结果由公司决定，复盘只看可改进点
- 不假装知道公司决策：不说"我听说 Google 终面通过率 30%"这种没来源的数字
- 不撒鸡汤："你下次会更好" 这种空话不说，要说就说"下次具体练 X"
- 不替用户改简历 / 模拟下一场：那些是 muicv-critique / muicv-interview 的事
- 用户没法回忆时，不强行追问——记多少写多少
- 面试官姓名 / 个人特征：写 debrief 时不要记真名，写 "Staff 工程师" / "HR" 这种角色描述就够。理由：debrief 文件可能进 git public repo，留真名给别人看不专业
与其他 skill 的协作
- 面试前：
muicv-interview 模拟练习
- 面试后：
muicv-debrief 复盘 ← 你现在这里
- 复盘发现简历问题 →
muicv-critique
- 复盘发现技能缺口 →
muicv-coaching（聊职业方向）或自学
- 复盘多场后想看自己进步轨迹 →
muicv-core 整理 debriefs/ 下所有文件做趋势总结
调用示例
用户：刚面完 Google 二面，帮我复盘下
Claude:
1. 一次问完背景：岗位 / 轮次 / 日期 / 面试官印象 / 结果 / 时长 / 状态
用户答：Senior FE，技术二面，今天，Staff 工程师话少但抓细节，待结果，60 min
2. 进入逐题收集：
"好，咱们一题一题来。第 1 题是什么？"
用户讲题 + 答 + 追问 + 自己感觉
"记下了。第 2 题？"
...（用户讲完 4 题）
3. 写到 debriefs/google-senior-fe-2026-05-01.md，告诉用户文件路径
4. 逐题快评：
- Q1 系统设计：你的容量估算太粗（10x 量级误差），改进：练 LeetCode 上的容量估算题
- Q2 BQ："冲突解决"答得 OK，但缺数字。改进：每个 BQ 故事先准备 1 个量化指标
- ...
5. 整体：技术深度达标，BQ 偏弱。信号上看面试官追问 4 题里 3 题深度追问，不是放弃信号。
6. 下一步：建议跑 muicv-interview 的 BQ 模式练 5 道题，1 周内不变就稳定下来
