career-ops interview/debrief 技能深度解析：真实面试后的 9 步复盘闭环与下一轮准备情报

本篇文章围绕 career-ops 开源项目（基于 AI 编程 CLI 的求职工作流系统）中可复用面试技能族之一的 interview/debrief（Debrief pós-entrevista，面试后复盘） 展开。该技能定义在 modes/pt/interview/debrief.md（巴西葡萄牙语版），其英文规范版见 modes/interview/debrief.md。读完本文，你将掌握：在真实面试结束后如何系统化采集问答、逐题做诚实评估、把结果写回 question bank / story bank / 职位专属准备文件，并通过结构化会话转录（session transcript）为下游分析模式留下机器可读数据——最终把每一轮面试都变成下一轮的确定性优势。

技能定位与何时执行

在 career-ops 中，modes/ 目录是整套系统的"大脑"：每个 Markdown 文件定义一条工作流，由所接入的 AI 编码 CLI（如 Claude Code、Codex、OpenCode 等）读取并执行，路由表见 AGENTS.md 的 Skill Modes 一节——其中明确写着 "Wants to debrief after a real interview and close gaps" 映射到 interview/debrief（AGENTS.md）。

面试相关的能力被抽成三个可复用技能，集中放在 modes/pt/interview/（葡萄牙语市场版）与 modes/interview/（英文规范版），目录说明见 modes/pt/interview/README.md：

技能	文件	使用时机
面试准备规划器	plan.md	有职位描述与面试日期时，排出分时间块的准备计划
模拟面试官	practice.md	做模拟提问并给出结构化反馈
面试后复盘	debrief.md	真实面试之后，关闭缺口、更新 question bank

这三个文件彼此衔接：practice 在模拟中暴露缺口，plan 在面试前按缺口分配时间，而 debrief 在真实面试后回收实证数据、反哺 question bank 与 story bank，从而让下一次 plan / practice 更有据可依（三者架构关系可对照 modes/README.md 中对 interview/ 子目录的说明）。

什么时候运行本技能

原文档明确列出了三类触发时机，要点在于"趁记忆新鲜、趁信息闭环"：

• 真实面试结束后立即运行（趁记忆最清晰时）；
• 在接到 recruiter 电话、并带来了流程新信息之后；
• 当候选人得知下一轮的形式与面试官时——这会让 step 6 的预测有了具体对象。

核心原则是：记忆随时间快速衰减，"几个小时内，具体问题和反应就会被遗忘"，因此原文档要求当天完成复盘。

输入：技能运行前需要读入与收集什么

debrief 并不是凭空生成建议，而是围绕候选人的真实经历与既有素材运作。原文档列出了 9 类输入，其中多处指向 career-ops 的用户层文件（关于"用户层文件从不被系统自动改写、gitignore 之外由用户维护"的分层约定，见 AGENTS.md 中的 User Layer 列表，interview-prep/* 属于其中）：

1. 候选人的复盘口述——问了哪些问题、他是怎么答的、感觉哪里强哪里弱；
2. 面试官姓名与职位——用于指导下一轮预测；
3. 本轮结果（若已知）——moved forward / rejected / pending；
4. 下一轮细节（若已知）——形式、面试官、时间线；
5. interview-prep/question-bank.md（question bank，通常首次使用时由本技能创建）——用真实数据更新；
6. interview-prep/story-bank.md（story bank）——如有新故事浮现则补充；
7. CV 文件 cv.md 与 article-digest.md（如存在）——把建议回答锚定在真实经历上；
8. interview-prep/retracted-claims.md（如存在）——硬性红线：即使候选人在真实面试里说过的被撤回主张（retracted claim），也绝不能在建议回答中再次使用；
9. 职位专属准备文件——追加复盘笔记。

一句话总结输入策略：复盘永远以候选人的真实产出文件为准绳，不引入任何编造主张。

面试相关文件约定

career-ops 中候选人的面试数据约定存放在根目录的 interview-prep/ 下（该目录属用户层），面试技能族遵循的"标准文件集"（在 modes/pt/interview/README.md 的 "Convenções de arquivos" 一节列出）包括：

• cv.md——经历与证明点的真相源；
• article-digest.md——portfolio 的浓缩证明点（可选）；
• config/profile.yml 与 modes/_profile.md——候选人画像与叙事（后者为个人定制层，详见 modes/pt/_shared.md）；
• interview-prep/story-bank.md——累积的 STAR+R 故事；
• interview-prep/question-bank.md——带缺口追踪的题库（首次使用时创建）；
• interview-prep/interview-prep-guide.md——通用面试原则（可选）；
• interview-prep/{company}-{role}.md——职位专属准备文件；
• interview-prep/retracted-claims.md——被撤回主张的登记表，格式为：**"[claim]"** ([context]). Reason: [one-line reason + correct framing if applicable].

Step 1 —— 采集：这一轮到底问了什么

复盘的第一件事是把"问过什么"完整捞出来，而不是急着下结论。原文档给出的采集方法是：

让候选人按顺序（若可能）列出他记得的所有问题。不要给出选项提示——先让他自由回忆。

对每个记录下来的问题，追问三件事：他说了什么？面试官如何反应（积极信号 / 中性 / 反驳 / 快速跳过）？他当时感觉自信还是不确定？

当记忆不完整时，用定向问题引导（原文给出的三个探针）：

• "有没有哪道题让你措手不及？"
• "有没有哪道题你希望当时换一种答法？"
• "面试官有没有对某个点追着问——这通常意味着他想要更多？"

值得一提的是：英文规范版 modes/interview/debrief.md 在此步骤之上增加了一条转录路径——如果候选人有本轮完整转录稿（Zoom / Teams / Google Meet 自动转录或粘贴文本），就直接以转录稿为数据源而不是靠口头回忆，并显式打上 input_source: transcript 标记（回忆路径则标记为 input_source: recall）。该标记会一路携带到 Step 9，决定会话转录是"重建"还是"轻规范化保存原稿"。葡萄牙语版虽未包含此分支，但这一设计能帮助理解该技能族的可扩展方向。

Step 1b —— 核查被矛盾的事实（英文规范版）

另一个值得了解的扩展（同样只在英文规范版中出现）：采集过程中，将口述内容与职位准备文件中已有的事实性断言做对照。关键区分是：面试暴露的"新信息"走追加流程（对应 Step 4/5/8）；但如果面试内容直接矛盾了准备文件已断言的具体事实（地点、薪酬区间、团队规模、汇报线、技术栈等），就要就地更正原文，而不是在文件下方追加一条注记。更正的写法是"删除线 + 修正"以保留 diff 中的历史痕迹，例如：

~~Metro Hall, on-site~~ **Metro Hall — hybrid** (confirmed on the {date} call)

同时，若原行带 [inferred from JD] 之类的推断标记，而面试恰好确认或纠正了它，则解除标记并把来源改为面试本身。

Step 2 —— 逐题诚实评估

采集之后，对每一道题产出一份结构化评估，原文档给出了固定模板（下文为葡萄牙语版原文结构，字段标题为英文以保持与英文规范版一致）：

**Q: [pergunta]**
- What was said: [resumo da resposta dele]
- What landed: [o que foi bom — seja específico]
- What was missing: [lacuna — termo técnico preciso, resultado ausente, sem reflection, etc.]
- Correct/complete answer: [o que a resposta completa deveria incluir]
- Status: ✅ Strong / 🟡 Solid / 🔴 Gap

写作基调被反复强调为直接：如果候选人漏掉了题目真正测试的核心概念，就直说；如果某道答得确实漂亮，也直说。原因是："debrief 是价值最高的学习时刻——含糊其辞会浪费它。" 这里的 ✅ / 🟡 / 🔴 状态不是给人看的装饰，而是后面 Step 3/4 与 interview/plan 读取的数据：真实面试中暴露的 🔴 缺口是"已被证实的短板"，优先级高于任何推断出来的风险。

Step 3 —— 更新 question bank

把本轮每题的状态同步回题库文件（即上面约定的 interview-prep/question-bank.md）：

• 根据真实表现把题目状态更新为 ✅ / 🟡 / 🔴；
• 从复盘结果补充缺口笔记；
• 加入本轮新出现、但题库里还没有的题。

若题库文件尚不存在，就用本场面试的问题作为种子创建它——这正是 modes/pt/interview/README.md 中"question bank 首次使用时创建"约定的具体落点。更新后的题库会反过来驱动下一次 interview/plan：任何标记 🔴 的题目都会在分块计划里获得一个专属时间块（见 modes/pt/interview/plan.md 的 Step 3）。

Step 4 —— 关闭缺口

对每个 🔴 缺口，逐一执行"一缺口一修正"的闭环，而不是抛出一整份学习计划：

1. 讲清正确回答——清晰、简洁，在合适时给一个已解出的例子（代码、计算或示意图）；
2. 尽可能接回真实故事——"你其实在 [story bank 中已有故事] 里有这段经历——看可以怎么用它"；
3. 写进职位专属准备文件，放在名为 "Gaps to Close Before Round N" 的章节下；
4. 如果该缺口是一条可复用的通用原则（不局限于这一家职位），再追加到 interview-prep/interview-prep-guide.md（若候选人维护该文件）。

值得注意的是，即便本技能要讲正确答案，也不允许把编造的主张塞进候选人的嘴：正确/完整答案可以借助领域通用知识，但任何涉及个人的主张或指标，必须来自候选人亲口所述、cv.md、article-digest.md 或 story bank。这与 modes/pt/_shared.md 中"关键词只能改写、绝不能虚构"的全局护栏一致，也与 AGENTS.md 对 story-bank 派生文件溯源的要求相呼应。

Step 5 —— 提炼新故事

真实面试常常会暴露出候选人此前没准备过的故事。若候选人在某个回答里描述了一段尚未正式化的经历，原文档给出了标准话术：

"Você mencionou [X] na sua resposta — parece que isso poderia virar uma história STAR+R completa. Quer montá-la agora enquanto está fresca?"

若同意，就以 STAR+R 结构（Situation, Task, Action, Result, Reflection）把它完整搭建起来，并追加到 interview-prep/story-bank.md。趁热打铁的原因是：记忆窗口稍纵即逝，此刻构建的 Reflection 质量远高于事后补写。

Step 6 —— 下一轮情报

当候选人已知道下一轮形式时，利用本轮做预测与排优先级：

1. 预测可能的题目，依据三个方面：下一轮面试官的职位（例如资深实践者 → 核心技能深度与设计题；跨职能平级 → 协作与领域边界；高管 → 战略与商业影响）；本轮已覆盖的内容（下一轮通常"钻得更深"而不是"铺得更宽"）；本轮面试官表现出最大兴趣的点。
2. 给所有预测打上 [inferred] 标签——绝不把预测题包装成来自真实候选人或内部人士的消息。
3. 建立下一轮准备优先级清单——按缺口严重度与"被考到的概率"双重排序。
4. 建议运行 interview/plan，把下一轮细节喂给准备规划器，生成完整的准备计划（衔接 modes/pt/interview/plan.md）。

这一步把"复盘"从回顾性工具转成了前瞻性武器：每一轮面试的产出，是下一轮更精准的输入。

Step 7 —— 成功概率评估（可选）

如果候选人主动要求一个诚实的"胜算"读数，基于四个维度评估，并且诚实优先：

• 缺口的数量与严重度（基础领域的 🔴 风险高于进阶主题上的 🔴）；
• 面试官信号（给出了具体的下一轮细节 = 积极；含糊 = 中性；通话很短 = 风险）；
• 职位契合度（经验年限、领域匹配、地点）；
• 差异化因素（候选人说出了多数候选人说不出的话）。

原文档的判断标准是：一个带清晰推理过程的概率区间，远比虚假的自信有用。

Step 8 —— 保存复盘记录

把本轮复盘追加到职位专属文件 interview-prep/{company-slug}-{role-slug}.md，使用如下模板（此为原文档完整结构，实践时逐字段填写）：

## Round [N] Debrief — [YYYY-MM-DD]

**Interviewer:** [nome, cargo]
**Round type:** [screening / technical / design-case-study / behavioral]
**Outcome:** [pending / moved forward / rejected]

### Questions Asked
[lista]

### Gaps Identified
[lista com respostas corretas]

### Next Round
**Format:** [se souber]
**Interviewers:** [se souber]
**Priority prep:** [3 principais tópicos a fechar antes da próxima rodada]

### Process Intel (recruiter / HM screens — omit if not applicable)
**Comp discussed:** [sim / não — se sim, o que foi dito e o que foi ancorado]
**Timeline:** [quaisquer datas ou prazos mencionados]
**Other candidates:** [se revelado]
**Next steps:** [o que o entrevistador disse que acontece a seguir e até quando]

模板特意区分了"Questions Asked / Gaps Identified / Next Round / Process Intel"四段：其中 Process Intel 段只适用于 recruiter 或 hiring manager 的筛选轮，记录薪酬是否被提及、时间线、其他候选人以及下一步动作。该文件也承接 Step 1b 的"就地更正"，保证一个职位只有一份持续演进的事实源。

Step 9 —— 写机器可读的会话转录

复盘的最后一步是把整轮会话落成机器可读转录，写入 interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md。原文档指出：这是给下游分析模式使用的结构化记录；带说话人标签的轮次让消费方无需重新推断"谁在说话"即可单独读取任一侧内容。完整契约定义在 interview-prep/sessions/README.md，格式如下：

---
company: [company]
role: [role]
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
date: YYYY-MM-DD
interviewer_role: [role, if known]
source: debrief
---

## Q1
**Interviewer:** [pergunta como foi feita]
<!-- competency: tag[, tag...] -->
**Candidate:** [resposta como foi dada / reconstruída neste debrief]

## Q2
...

转录有五条硬规则：

• 把本轮类型映射到枚举（recruiter 筛选 → screen，hiring manager 筛选 → hiring-manager，技术深挖 → technical，design/case study → system-design）；
• 给每条回答打标签：紧挨着每条 **Candidate:** 行的上一行写 <!-- competency: tag[, tag...] -->，用 lowercase-kebab-case、多能力用逗号分隔（如 system-design、people-leadership、incident-response）；标签是自由文本，选"这道题真正测的能力"——因为 Step 2 已经评估过，直接引用评估结果即可；
• 忠实重建候选人回合：用 Step 1 里候选人实际汇报的说法，而不是理想化答案；Step 2 的 "correct/complete answer" 属于 debrief 文件，永远不进转录——转录记录"发生了什么"，不是"该怎么答"；
• source: debrief 标记来源；
• 会话文件落在 gitignore 目录中（真实姓名/公司从不进入版本控制，interview-prep/sessions/README.md 明确说明该目录只跟踪 README 与 .gitkeep），因此可以不加删改地直写。

这些转录不是死数据：career-ops 的 weekly-digest.mjs 会读取 interview-prep/sessions/*.md（默认当前 ISO 周），按公司汇总每轮进展、统计反复出现的 competency 标签，并从 question bank 里聚合反复出现的 🔴 缺口（见 AGENTS.md 对该脚本用途的说明）——这正是 Step 3 严格维护状态、Step 9 规范打标签的意义所在。模拟面试技能 interview/practice 也会以同样的契约（source: practice）写会话转录，两类来源共享同一份下游消费格式。

规则红线：复盘的行为边界

原文档在末尾给出了十条纪律，其中多数是 career-ops 全局"不虚构、用户授权优先"价值观在面试场景的具体化：

• 当天复盘——细节记忆衰减极快，几小时内具体问题和反应就会被遗忘；
• 不要粉饰缺口——出于客气把 🔴 叫成 🟡，它会在下一轮原样出现；
• 绝不把编造的主张放进候选人嘴里——正确/完整回答可借用领域通识，但任何个人主张或指标必须来自他所说的、cv.md、article-digest.md 或 story bank；
• 被撤回主张是硬性红线——只要主张出现在 interview-prep/retracted-claims.md，即使候选人在真实面试说过，也绝不建议使用；应提示："Essa alegação está na sua lista de retiradas — não é defensável sob pressão. Aqui está uma versão que não depende dela."；
• 登记新的撤回——若复盘暴露出候选人在真实面试用过、且他现在也同意不可辩护的主张，提议追加到 retracted-claims，格式为 **"[claim]"** ([context]). Reason: [one-line reason + correct framing if applicable].；
• 显式提取词汇缺口——若候选人用了含糊词而存在精确术语，把它记入 interview-prep/interview-prep-guide.md 的词汇章节（若维护）;
• 一缺口一修正——不要用一整份学习计划压垮候选人，优先 1–2 个最可能被下一轮考到的；
• 为答得好的部分庆祝——复盘不只讲缺口，点出亮点能强化正确行为并建立下一轮信心。

三技能联动：debrief 在面试闭环中的位置

把视角拉回技能族整体，debrief 是"真实数据回流"的关键节点：

1. interview/plan 排准备计划时，question bank 中 🔴 的历史缺口拥有最高优先级——而这些 🔴 正是上一次 debrief（或 practice 模拟反馈）写入的；
2. interview/practice 用真实公司题库出题时，同样会更新 question bank 状态并写 source: practice 的会话转录；
3. 真实面试后运行 interview/debrief，Step 6 又建议回头调用 interview/plan 准备下一轮。

也就是说，career-ops 把"面试"本身变成了一条可积累的数据管线：模拟与复盘共享 question bank / story bank / sessions 契约，而状态标记（✅🟡🔴）与机器可读转录是不同环节之间交换的货币。 只要严格照 modes/pt/interview/debrief.md 的九步执行，每一轮被"浪费"的面试都会转化为下一轮可检索、可引用、可量化的准备优势。