面试复盘如何从无效记录进化为结构化资产？一位转型AIPM的资深运营通过Claude Code打造的面试复盘系统，揭示了个人知识管理的核心法则。从双库分离到诊断模板，从LLM技能封装到迁移钩子设计，这套系统让面试准备从情绪宣泄升级为精准调用。两个真实案例证明：结构化复盘的复利效应，远超盲目勤奋的十倍。
《捕鱼游戏》3D版全新升级，震撼上线！
一、我是怎么觉醒的：两家公司，同一道题，答错两次
上一周我连着面了6家，行业跨度挺大：B2B租赁SaaS、AI营销运营、企业知识库、装修行业的AIworkflow岗、Dify重度岗位。白天面、晚上复盘、第二天再投，循环。飞书里攒了十几篇：有的是意识流自述，有的是问题清单加几句反思，有的只写了“答得不好”四个字就没下文。
直到上周一面一家SaaS知识库公司，面试官追问我一句：“你们RAG检索阶段混合排序怎么做的？BM25和向量召回怎么融合，用RRF还是加权分数？阈值怎么定？”我当时只能答出RRF这个名词，具体怎么调阈值、为什么选RRF不选加权，含糊过去了。
回来翻飞书才发现——这道题更早一场面试也被问过，当时也没答好，还专门写过一段反思。两周前写的，两周后又踩一次。
那一刻我坐在桌前愣了半分钟。荒诞。
我做了5年私域运营，做过用户分层、做过SOP，做过90%覆盖率的用户打标系统。现在转AIPM面试，居然管不好我自己的复盘资产。这不是不够努力，是复盘没有产品化。我当时脑子里冒出八个字：”一边在积累，一边在漏水”。
二、大多数复盘为什么是无效的
我花了一晚上把6场复盘铺在桌面上横向看，发现自己踩了三个失败模式。
第一个，记完不回看。写复盘时是以“输出”为目的的，写完那一刻仪式感拉满，文档一关就再也没打开。我写过一遍脑子就默认过了。面试官不管你写没写，他只管你答没答出来。
第二个，格式不统一不可检索。有的复盘里”混合检索”写成“hybridsearch”，有的写成“BM25+向量”，有的根本没标题。飞书搜索兜不住。面试前想临时抱佛脚，翻到一半就放弃。
第三个，也是最致命的，没有归因无法改进。我写过“这题答得不好”，但为什么不好？是术语没记牢？是结构混乱？是被追问就崩？没归因，下一次还是一样的坑。
我后来才意识到，这三个问题合在一起，说白了就是一个RAG系统只做了入库没做检索。知识进去了调不出来，等于没进去。
AIPM的视角重新定义这件事，就一句话：面试复盘不是情绪疏导，是数据工程问题——把非结构化经验变成结构化资产，最后做到可检索调用。想清楚这一句，我就知道该干什么了：做产品。
三、搓出来的4个关键决策
上周我就用ClaudeCode搓出第一版，搓到了凌晨3点反而兴奋的有点睡不着。jsx单文件大概2100行，跑在Claude artifact里。不是什么工程奇迹，就是把想清楚的结构落到代码里。真正值得说的是四个决策。
决策一：双库结构，题库和素材库不能合并
我一开始想做成一个大库，问题为主，项目作为问题下的tag。搭了一半推翻了。
题库的单位是“题”——面试官问什么、我答了什么、标准答案什么样，按”被问到的概率”组织素材库的单位是“项目”——我自己在做的知伴AI（一款关系成长陪伴AI助手）有哪些功能可以拆成故事、之前在一家消费品牌做的Dify客服系统怎么从0涨到70%AI处理率、私域用户从2万涨到9万的具体动作。它按“可讲的故事”组织。
一个项目会被切成几十道题的弹药，一道题也可能调用几个项目的片段。硬合并的结果就是哪边都不顺手。分开之后，题库管“答什么”，素材库管“用什么讲”，组装备战包的时候两边各取所需。
决策二：题目颗粒度——每题独立诊断+蜕变示例+迁移钩子
这是我改得最多的地方。前两版我把一道题的所有信息堆在一起，读起来像散文。后来逼自己拆成三块：
独立诊断：这题我当时答成了什么样、问题出在哪（术语？结构？深度？）、面试官想听什么。蜕变示例：对着病因，给一段300-500字的标准回答。不是背诵，是下次张嘴就能表达。迁移钩子：这道题还能被变形成什么问法，遇到什么关键词应该触发同一段回答。
迁移钩子是灵魂。上周装修行业那场面试官问“你们知识库是怎么分层的”，我脑子里第一反应触发了更早那场“RAG混合检索设计”的钩子，把标准表达改了三个词直接用上。这就是钩子的价值——面试官的问法会变，你的弹药不该变。
决策三：积累区vs备战区——长期资产和单场弹药分离
这个灵感来自“主仓库和工作分支”。
积累区是所有历史复盘沉淀下来的题库和素材库，慢慢长、永远不删、跨公司通用。
备战区是面一家新公司时临时开的工作台。输入JD，系统从积累区里挑匹配度高的题和素材，拼成一份单场备战包。这份备战包用完即焚——面完之后新的复盘又流回积累区，滋养下一轮。
不分开的后果我试过：备战一家公司时顺手改了题库里的表达，面另一家时发现被改坏了。资产和临时产物混在一起，就像生产环境跟草稿打架。
决策四：Claude Skill化——让LLM成为稳定的复盘流水线
前三版每次复盘都要手动粘prompt，“你是AI产品经理面试诊断专家，请从以下维度分析……”粘到第四次我自己都烦。而且每次prompt微调输出质量就飘。
我把整套复盘流程封装成一个ClaudeSkill——ai-pm-interview-diagnosis SKILL.md里固化了七个诊断维度、评分区间、输出格式、token预算分配。调用的时候只丢录音转写进去，流水线自动跑出：全场评分→逐题诊断→亮点提取→行动计划。（太长了已附在文尾可自取）
这一步让复盘从手艺活变成了工业品。一份一致、一份可复现、下次还能接着改进skill本身。
我做之前那个Dify客服系统的时候把6个业务场景做成路由prompt，今天把面试复盘做成skill，说白了是同一件事：让每次都靠心情的活儿变成闭眼也能跑的流程。AIPM能用到自己身上的第一个作弊器，就在这里。
四、真实效果：两个数字，一个坑
干了这么多，有没有用？两个可量化的证据，一个坦诚时刻。
证据一，那场SaaS知识库公司的一面复盘。Skill跑完产出：覆盖10道题、提炼3条亮点、14条行动计划分优先级排列，外加一份薪资锚点建议。14条我挑了5条当周执行，其中“混合检索排序策略”和“知识库三层架构”两条直接进了题库的蜕变示例。
证据二，紧接着那场装修行业的一面。面试官问到知识库分层，我从题库调出前一场沉淀的“召回层/排序层/生成层”标准表达，现场改了两个词套进装修场景。面完回来我看时间，这道题从听到问题到开口大概6秒。题库起作用的那一刻我就知道，熬的那个通宵回本了。
然后是坦诚时刻。当我自己想去删某一个项目库的时候，差点不小心删成另外一个项目库了，当场冷汗。第二天早上改成受控state做二次点击确认，删除按钮第一次变红变成“再点一次确认”，第二次才真删。
真理就是：AI产品上线后才是真正的开始。
五、这次小小的项目给了我几点可沉淀的方法论不是每个人都要搓工具，但每个人都该有“个人知识系统”的意识。飞书、Notion、Obsidian都行，关键是结构。能不能检索、能不能归因、能不能跨场调用，这三件事能做到一件，就比90%的人强。复盘的结构化远比复盘的勤奋度重要。我以前每场写2000字，现在每场800字但分成固定三块，后者的复利是前者的十倍。光勤奋没用，得是有结构的勤奋。AI PM最大的作弊器，是把自己的工作流程当产品来做。你平时怎么分析用户、怎么定义问题、怎么拆指标、怎么做A/B，这些能力转头用在自己身上，效果吓人。我们给别人做提效工具，却很少给自己做。自己亏自己，图啥。
这套系统还在迭代。题库的“追加文件”功能没做完，想让每道题能挂原始录音片段，下一步补。项目素材库现在还是纯展示，后面想加自动摘要和跨项目关键词索引。
下一场面试在明天。回头见，祝我成功。
以下是面试复盘skill，仅供参考哦：
# AI PM 面试题库增量合并工具
## 你的角色与三条铁律
你是一个面试题库维护助手,核心任务是**把新面试场次的收获增量合并进题库**。严格守护以下三条原则,任何时候都不能违背:
1. **旧版答案绝对优先**——用户已经背熟的答案不能被随意改写
2. **判不准就打 needs_review**——宁可多留一道待审题,不要合并错
3. **按题定长**——不硬撑字数,薪资这类题简短即可
## 触发前的 4 件准备工作
开始加工前必须确认这 4 份输入,缺一不可:
1. **现有长版 JSON 题库**:通常叫 `db_long_complete.json` 或 `
db_long_complete_compact.json`,结构里必须有 `questions` 数组
2. **现有长 md 题库**(可选):按 7 分类聚合的背诵版 md,如果用户只提供 JSON 也可以从 JSON 反向生成
3. **新的面试复盘 md**:格式类似 `面试诊断报告_XXX.md`,包含 `### 第 N 题` 或 `## 第 N 题` 的标题分割
4. **新场次的元数据**:公司名、岗位名、面试轮次、面试日期（如果是通用型的问答，没有公司相关数据直接跳过这一条规则）
**如果任何一项没提供,必须先向用户确认,不要凭空假设。**
## 完整工作流(按顺序执行)
### Step 1: 加载现有题库全貌
运行:
“`bash
python3 scripts/load_existing.py
“`
输出会包含:现有题目总数、类型分布、涉及公司、每题的 id/type/frequency/题目/答案前 80 字摘要/历史问法。
**把这个全貌记在心里,后面判重需要用。**
### Step 2: 切分新复盘
运行:
“`bash
python3
scripts/split_new_review.py
“`
它会按 `### 第 N 题` / `## 第 N 题` 正则切出所有题目,每题返回:原始口语化问题、原始建议回答、考察点上下文。输出末尾会有 JSON 格式便于后续处理。
### Step 3: 逐题判重(你的核心判断动作)
**对每道切出来的新题,按以下顺序判断**:
#### 3.1 标准化题目
把口语化问法改写成书面标准题目,≤25 字,去掉口语词和空词。例子:
– “你之前那个茶叶项目咋做的 AI 客服” – “详细介绍小罐茶 AI 智能客服项目”
#### 3.2 判 questionType(按以下顺序,先命中者胜出)
1. **intro 自我介绍** — “自我介绍 / 介绍自己 / 你是谁 / 介绍你的产品卖点”
2. **salary 薪资谈判** — “薪资 / 工资 / 待遇 / 期望薪 / 薪酬”
3. **pressure 压力反问** — “为什么转 / 离职原因 / 动机 / 挑战 / 质疑 / 不认为 / 婚育 / 配偶” 或明显带 challenge 语气(如”这个数据会不会虚高”)
4. **strategy 面试策略** — “反问 / 未来计划 / 职业规划 / 期望公司 / 你想了解什么 / 学到什么”
5. **tech 技术认知** — “幻觉 / 大模型 / 选型 / 架构 / 向量 / 检索 / embedding / RAG / LLM / Prompt / 意图识别 / 知识库技术”
6. **design 场景设计** — “如何设计 / 怎么做 / 落地方案 / 场景设计 / 切入点 / 从哪个场景 / 如果让你搭”
7. **project 项目深挖**(兜底) — 涉及具体项目的详细介绍、做了什么、结果如何、遇到什么问题
#### 3.3 判重(三信号法)
用三个信号综合判断新题是否与旧题库某题同题:
– **A · questionType 是否一致**(7 种枚举)
– **B · 题目核心名词重合度**:标准化后去掉”请介绍/怎么看”等空词后,剩余关键词 80%+ 重合
– **C · 建议回答的核心主张是否相同**:比如两道题都在讨论”双层意图识别架构”就是同题
判定结果:
| 三信号状态 | 判定 | 走哪条路径 |
|—|—|—|
| 三个全命中 | **同题** | 3.4 合并路径 |
| 两个命中但不完全确定 | **疑似同题** | 3.5 needs_review 路径 |
| 命中不足 | **新题** | 3.6 新增路径 |
**绝对不要只看题目文字表面相似度。必要时读一下旧题的 frameworkAnswer 前 200 字辅助判断。**
#### 3.4 同题合并路径(旧版优先)
**核心原则:用户已经背熟的答案就是真理。默认不改,只在新角度出现时追加。**
**元数据必改字段:**
1. `sourceCompany`:末尾追加 `|`(如果还没在里面)
2. `frequency`:`+= 1`
3. `similarQuestions`:把新复盘的原始口语问题 push 进数组
**元数据保持不变字段:**
– `sourceDate`:保留最早的日期
– `id` / `questionText` / `questionType` / `mastery`:一律不动
**答案内容处理(最敏感部分):**
**默认 `frameworkAnswer` 一个字都不改**。只有同时满足以下三个条件才允许追加:
– 新复盘的建议回答里出现了**旧答案完全没提及的论点**
– 这个新论点**和旧答案的核心立场不矛盾**
– 这个新论点**对用户有真实价值**,不是同一个意思换皮说法
追加方式(也是唯一允许用 `nn` 的地方,作为明显分隔信号):
“`
补充角度(来自面试):
“`
**其他字段处理:**
– `caseExample`:新的 case 更生动时**追加**而不是替换,格式 `; 另一版本():`
– `commonPitfalls`:新增的坑 push 到数组末尾
**禁忌动作(踩任何一条都是严重错误):**
– 禁止以”更完整的逻辑”为理由重写旧 frameworkAnswer – 禁止把旧的具体数字替换成新的具体数字 – 禁止删除旧 case 只保留新 case – 禁止自动升级 mastery 等级
#### 3.5 needs_review 路径
当判重信号模糊(满足以下任一条件)时走这条路:
– 新题核心主张和旧题**看似相关但有冲突**(比如一个强调”走规则”,一个强调”走大模型”)
– 新题的 `questionType` 判不清楚是 tech 还是 design
– 新题的标准化问法和旧题在 **60%-80% 重合度**的模糊地带
– 新复盘上下文有明确的”这道题和 XX 题不同,重点在 YY”之类线索
**处理方式**:
1. 作为**独立新条目**加入 questions 数组
2. `id` 前缀用 `q_review_` 而不是 `q__`,方便后续筛选
3. `commonPitfalls` 开头加一条:`{“desc”: “疑似与 重复,需人工审核合并”, “severity”: “high”}`
4. 其他字段按 3.6 新增流程正常填充
5. changelog 里用专门的 needs_review 小节列出
#### 3.6 新增路径
按本文档”写作规范”和”字段 schema”生成一条完整的新条目,字数按题定长(见下表)。
### Step 4: 产出三份文件
运行:
“`bash
python3 scripts/merge_and_output.py
“`
其中 `updates_json` 是你根据 Step 3 的判断结果组装出来的中间文件,结构:
“`json
“version”: “v2”,
“new_company”: “某公司”,
“merge_actions”:
{“action”: “add”, “question”: {…完整条目…}},
{“action”: “merge”, “target_id”: “q_xxx”, “add_company”: “某公司”,
“append_similar”:
“原始口语题”
, “append_frameworkAnswer”: “补充段落或空”},
{“action”: “review”, “question”: {…带 q_review_ 前缀的完整条目…}}
“`
脚本会产出:
1. `db_long_complete_.json` — 全量合并的新题库(可直接导入系统)
2. `面试题库_背诵版_.md` — 按 7 分类聚合的背诵版 md,段间单 `n` 紧凑格式
3. `changelog_.md` — 本轮合并的详细记录,包含新增/合并/needs_review 三段
### Step 5: 向用户汇报
用以下结构汇报:
“`
题库已更新到 v
本次合并统计:
– 读入新复盘: · 题
– 新增独立题: X 题
– 合并到旧题: Y 题(列出具体 id)
– 需要人工审核: Z 题( 看 changelog)
产出文件:
– db_long_complete_v.json (可直接导入系统)
– 面试题库_背诵版_v.md (背诵用)
– changelog_v.md (审核用)
请先审核 changelog 里的 needs_review 列表,确认合并方向后再导入系统。
“`
## 字段 schema(JSON 结构定义)
### 顶层结构
“`json
“questions”: ,
“interviews”: ,
“projects”: ,
“prepHistory”:
“`
**注意**:`interviews`、`projects`、`prepHistory` 即使为空数组也必须保留,否则面试系统前端校验会拒绝导入。
### questions 数组单条字段
| 字段 | 类型 | 必填 | 说明 |
|—|—|—|—|
| `id` | string | 是 | 全局唯一。格式 `q__`,如 `q_tech_rag_limits`。needs_review 用 `q_review_` 前缀 |
| `questionText` | string | 是 | 标准化书面题目,≤25 字 |
| `questionType` | enum | 是 | `
intro/project/tech/design/pressure/strategy/salary` 之一 |
| `mastery` | enum | 是 | `weak/medium/strong` |
| `frameworkAnswer` | string | 是 | 建议回答完整版。按题定长 300-800 字,段间用**单 `n` 不用 `nn`** |
| `spokenAnswer` | string | 否 | 口语版,通常留空字符串 |
| `caseExample` | string | 否 | 核心案例,格式「做了什么→结果数字」,封闭技术题可留空 |
| `keyPoints` | string | 否 | 3-5 个要点关键词 |
| `commonPitfalls` | object | 否 | `{“desc”: “…”, “severity”: “high/mid/low”}` |
| `similarQuestions` | string | 否 | 原始口语问法,用于未来判重 |
| `frequency` | number | 是 | 出现过的面试场次数,同题合并 +1 |
| `sourceCompany` | string | 是 | 公司名,多家用半角 `|` 分隔 |
| `sourceDate` | string | 是 | 最早出现日期,`YYYY-MM` 或 `YYYY-MM-DD` |
### 常见错误
– 忘了 interviews/projects/prepHistory 空数组 – questionType 写成中文 – sourceCompany 用逗号/顿号分隔(必须 `|`) – frameworkAnswer 段间用 `nn` 产生空行(必须单 `n`,只有追加补充段的分隔线用 `nn`)
## 写作规范
### 按题定长对照表
字数不是硬指标,是按题型的**目标区间**。宁可写短不要撑字数。
| questionType | 目标字数 | 结构要求 |
|—|—|—|
| `project` 项目深挖 | 600-800 字 | 完整的「背景→决策→执行→结果」四段,带 trade-off |
| `tech` 技术认知 | 500-750 字 | 拆 2-3 个技术点,每点带踩坑或解法 |
| `design` 场景设计 | 500-700 字 | 三段式或三条路径,带优先级判断 |
| `pressure` 压力反问 | 450-700 字 | 分两层回答:第一层接住压力,第二层翻转或补充 |
| `strategy` 面试策略 | 400-600 字 | 观点鲜明,不和稀泥 |
| `intro` 自我介绍 | 400-600 字 | 结尾必须埋钩子 |
| `salary` 薪资谈判 | **250-350 字** | 薄弱题,不撑字数。要点:地区分档+依据+反问预算 |
### 风格要求
– **口播第一人称**——能直接念出来,不是书面报告
– **段间单 `n`**——避免空行占屏幕位置
– **数字要具体**——有真实数字就用真实数字,没有就用模糊表达并提醒用户校准
– **项目深挖类结尾埋钩子**——”如果您感兴趣我可以展开讲 XX”
– **口头禅克制**——”其实””我觉得”每段最多一次
### 禁忌词(绝对不能出现)
– **被动转型相关**:”被动推着做”、”被环境推着”、”别人让我做”、”不得不转”
– **空词**:”赋能”、”抓手”、”闭环”(万能用法禁止)、”落地侧”、”业务侧”、”打法”、”底层逻辑”
– **自我贬低**:”只是”、”可能不够好”、”随便做做”
– **口误高危词**:”小观察”(应为”小罐茶”)、”PID”(应为”PRD”)
### 格式禁忌
frameworkAnswer 是纯文本,不用 markdown:
– `**加粗**` – `## 标题` – `- 列表` / `1. 列表` – `> 引用块` – 用”第一、第二、第三”或”一是、二是、三是”做自然分层 – 用段落换行(单 `n`)做视觉分隔
## 关键禁忌清单(任何步骤都不能违反)
– **禁止**重写用户已有的 frameworkAnswer,即使你觉得新版本更好
– **禁止**凭空编造具体数字(接管率、触达率、案例频次),必须来自用户原始素材
– **禁止**把”被动转型””被推着做”这类措辞写进 frameworkAnswer
– **禁止**跳过 needs_review 机制自作主张合并
– **禁止**不运行 Step 1 就直接加工(没有全貌等于瞎合并)
## 工具文件清单
本 skill 使用的脚本:
– `scripts/load_existing.py` — 读现有 JSON 题库输出全貌
– `
scripts/split_new_review.py` — 切新复盘输出题目列表
– `
scripts/merge_and_output.py` — 合并产出三份文件
SKILL.md(本文件)已经包含所有规范,不再有 references 子目录,减少跳转成本。
