大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
    
 
     
面试复盘如何从无效记录进化为结构化资产？一位转型AIPM的资深运营通过Claude Code打造的面试复盘系统，揭示了个人知识管理的核心法则。从双库分离到诊断模板，从LLM技能封装到迁移钩子设计，这套系统让面试准备从情绪宣泄升级为精准调用。两个真实案例证明：结构化复盘的复利效应，远超盲目勤奋的十倍。
 
    

上一周我连着面了6家，行业跨度挺大：B2B租赁SaaS、AI营销运营、企业知识库、装修行业的AIworkflow岗、Dify重度岗位。白天面、晚上复盘、第二天再投，循环。飞书里攒了十几篇：有的是意识流自述，有的是问题清单加几句反思，有的只写了“答得不好”四个字就没下文。

直到上周一面一家SaaS知识库公司，面试官追问我一句：“你们RAG检索阶段混合排序怎么做的？BM25和向量召回怎么融合，用RRF还是加权分数？阈值怎么定？”我当时只能答出RRF这个名词，具体怎么调阈值、为什么选RRF不选加权，含糊过去了。

回来翻飞书才发现——这道题更早一场面试也被问过，当时也没答好，还专门写过一段反思。两周前写的，两周后又踩一次。

那一刻我坐在桌前愣了半分钟。荒诞。

我做了5年私域运营，做过用户分层、做过SOP，做过90%覆盖率的用户打标系统。现在转AIPM面试，居然管不好我自己的复盘资产。这不是不够努力，是复盘没有产品化。我当时脑子里冒出八个字：”一边在积累，一边在漏水”。

我花了一晚上把6场复盘铺在桌面上横向看，发现自己踩了三个失败模式。

第一个，记完不回看。写复盘时是以“输出”为目的的，写完那一刻仪式感拉满，文档一关就再也没打开。我写过一遍脑子就默认过了。面试官不管你写没写，他只管你答没答出来。

第二个，格式不统一不可检索。有的复盘里”混合检索”写成“hybridsearch”，有的写成“BM25+向量”，有的根本没标题。飞书搜索兜不住。面试前想临时抱佛脚，翻到一半就放弃。

第三个，也是最致命的，没有归因无法改进。我写过“这题答得不好”，但为什么不好？是术语没记牢？是结构混乱？是被追问就崩？没归因，下一次还是一样的坑。

我后来才意识到，这三个问题合在一起，说白了就是一个RAG系统只做了入库没做检索。知识进去了调不出来，等于没进去。

AIPM的视角重新定义这件事，就一句话：面试复盘不是情绪疏导，是数据工程问题——把非结构化经验变成结构化资产，最后做到可检索调用。想清楚这一句，我就知道该干什么了：做产品。

上周我就用ClaudeCode搓出第一版，搓到了凌晨3点反而兴奋的有点睡不着。jsx单文件大概2100行，跑在Claude artifact里。不是什么工程奇迹，就是把想清楚的结构落到代码里。真正值得说的是四个决策。

我一开始想做成一个大库，问题为主，项目作为问题下的tag。搭了一半推翻了。

1. 题库的单位是“题”——面试官问什么、我答了什么、标准答案什么样，按”被问到的概率”组织
2. 素材库的单位是“项目”——我自己在做的知伴AI（一款关系成长陪伴AI助手）有哪些功能可以拆成故事、之前在一家消费品牌做的Dify客服系统怎么从0涨到70%AI处理率、私域用户从2万涨到9万的具体动作。它按“可讲的故事”组织。

一个项目会被切成几十道题的弹药，一道题也可能调用几个项目的片段。硬合并的结果就是哪边都不顺手。分开之后，题库管“答什么”，素材库管“用什么讲”，组装备战包的时候两边各取所需。

这是我改得最多的地方。前两版我把一道题的所有信息堆在一起，读起来像散文。后来逼自己拆成三块：

1. 独立诊断：这题我当时答成了什么样、问题出在哪（术语？结构？深度？）、面试官想听什么。
2. 蜕变示例：对着病因，给一段300-500字的标准回答。不是背诵，是下次张嘴就能表达。
3. 迁移钩子：这道题还能被变形成什么问法，遇到什么关键词应该触发同一段回答。

迁移钩子是灵魂。上周装修行业那场面试官问“你们知识库是怎么分层的”，我脑子里第一反应触发了更早那场“RAG混合检索设计”的钩子，把标准表达改了三个词直接用上。这就是钩子的价值——面试官的问法会变，你的弹药不该变。

这个灵感来自“主仓库和工作分支”。

积累区是所有历史复盘沉淀下来的题库和素材库，慢慢长、永远不删、跨公司通用。

备战区是面一家新公司时临时开的工作台。输入JD，系统从积累区里挑匹配度高的题和素材，拼成一份单场备战包。这份备战包用完即焚——面完之后新的复盘又流回积累区，滋养下一轮。

不分开的后果我试过：备战一家公司时顺手改了题库里的表达，面另一家时发现被改坏了。资产和临时产物混在一起，就像生产环境跟草稿打架。

前三版每次复盘都要手动粘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秒。题库起作用的那一刻我就知道，熬的那个通宵回本了。

1. 然后是坦诚时刻。当我自己想去删某一个项目库的时候，差点不小心删成另外一个项目库了，当场冷汗。第二天早上改成受控state做二次点击确认，删除按钮第一次变红变成“再点一次确认”，第二次才真删。

真理就是：AI产品上线后才是真正的开始。

1. 不是每个人都要搓工具，但每个人都该有“个人知识系统”的意识。飞书、Notion、Obsidian都行，关键是结构。能不能检索、能不能归因、能不能跨场调用，这三件事能做到一件，就比90%的人强。
2. 复盘的结构化远比复盘的勤奋度重要。我以前每场写2000字，现在每场800字但分成固定三块，后者的复利是前者的十倍。光勤奋没用，得是有结构的勤奋。
3. 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 <现有json路径>

“

输出会包含:现有题目总数、类型分布、涉及公司、每题的 id/type/frequency/题目/答案前 80 字摘要/历史问法。

把这个全貌记在心里,后面判重需要用。

—

Step 2: 切分新复盘

运行:

“bash

python3 scripts/split_new_review.py <新复盘md路径>

“

它会按 第 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 一个字都不改。只有同时满足以下三个条件才允许追加:

– 新复盘的建议回答里出现了旧答案完全没提及的论点

– 这个新论点和旧答案的核心立场不矛盾

– 这个新论点对用户有真实价值,不是同一个意思换皮说法

追加方式(也是唯一允许用 `

的地方,作为明显分隔信号):

“

<旧 frameworkanswer="" 原文="">

补充角度(来自 <新公司名> 面试):

<新论点段落,100-300 字="">

“

其他字段处理:

–caseExample:新的 case 更生动时追加而不是替换,格式 <旧 case=""> ; 另一版本( <新公司> ): <新 case="">

–commonPitfalls:新增的坑 push 到数组末尾

禁忌动作(踩任何一条都是严重错误):

– ❌ 禁止以”更完整的逻辑”为理由重写旧 frameworkAnswer

– ❌ 禁止把旧的具体数字替换成新的具体数字

– ❌ 禁止删除旧 case 只保留新 case

– ❌ 禁止自动升级 mastery 等级

# 3.5 needs_review 路径

当判重信号模糊(满足以下任一条件)时走这条路:

– 新题核心主张和旧题看似相关但有冲突(比如一个强调”走规则”,一个强调”走大模型”)

– 新题的questionType判不清楚是 tech 还是 design

– 新题的标准化问法和旧题在 60%-80% 重合度的模糊地带

– 新复盘上下文有明确的”这道题和 XX 题不同,重点在 YY”之类线索

处理方式:

1. 作为独立新条目加入 questions 数组

2.id前缀用qreview而不是q ,方便后续筛选

3.commonPitfalls开头加一条:{“desc”: “疑似与 <旧题 id=""> 重复,需人工审核合并”, “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”: “review”, “question”: {…带 qreview 前缀的完整条目…}}

]

}

“

脚本会产出:

1.db_longcomplete .json — 全量合并的新题库(可直接导入系统)

2.面试题库背诵版 .md — 按 7 分类聚合的背诵版 md,段间单 紧凑格式

3.changelog_ .md — 本轮合并的详细记录,包含新增/合并/needs_review 三段

—

Step 5: 向用户汇报

用以下结构汇报:

“

✓ 题库已更新到 v

本次合并统计:

– 读入新复盘: <公司名> · <题数> 题

– 新增独立题: X 题

– 合并到旧题: Y 题(列出具体 id)

– 需要人工审核: Z 题(⚠️ 看 changelog)

产出文件:

– db_long_complete_v .json (可直接导入系统)

– 面试题库_背诵版_v .md (背诵用)

– changelog_v .md (审核用)

⚠️ 请先审核 changelog 里的 needsreview 列表,确认合并方向后再导入系统。

“

—

字段 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 字,段间用单 不用

|

|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 段间用

产生空行(必须单 ,只有追加补充段的分隔线用

)

—

写作规范

按题定长对照表

字数不是硬指标,是按题型的目标区间。宁可写短不要撑字数。

| 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 字 | 薄弱题,不撑字数。要点:地区分档+依据+反问预算 |

风格要求

– 口播第一人称——能直接念出来,不是书面报告

– 段间单 ——避免空行占屏幕位置

– 数字要具体——有真实数字就用真实数字,没有就用模糊表达并提醒用户校准

– 项目深挖类结尾埋钩子——”如果您感兴趣我可以展开讲 XX”

– 口头禅克制——”其实””我觉得”每段最多一次

禁忌词(绝对不能出现)

– 被动转型相关:”被动推着做”、”被环境推着”、”别人让我做”、”不得不转”

– 空词:”赋能”、”抓手”、”闭环”(万能用法禁止)、”落地侧”、”业务侧”、”打法”、”底层逻辑”

– 自我贬低:”只是”、”可能不够好”、”随便做做”

– 口误高危词:”小观察”(应为”小罐茶”)、”PID”(应为”PRD”)

格式禁忌

frameworkAnswer 是纯文本,不用 markdown:

– ❌加粗

– ❌ 标题

– ❌- 列表/1. 列表

– ❌> 引用块

– ✅ 用”第一、第二、第三”或”一是、二是、三是”做自然分层

– ✅ 用段落换行(单 )做视觉分隔

—

关键禁忌清单(任何步骤都不能违反)

– 禁止重写用户已有的 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 子目录,减少跳转成本。