| name | story-bank |
| description | Mines the candidate's real experience into a reusable story bank — fact-based story cards with sourced numbers, repackaged per role type. Use when the user wants to organize their projects and achievements for interviews, says 整理项目经历 / 挖掘亮点 / 经历库 / 这段经历怎么讲 / 同一个项目怎么对不同岗位讲, or when interview-script lacks material to write from. Do NOT use for company research (use job-intel) or final verbatim answers (use interview-script). |
| license | MIT |
| metadata | {"author":"Yunyue Li","version":"0.1.0"} |
story-bank · 经历库
把候选人的真实经历挖成结构化经历卡，存进工作台根目录 story-bank.md。核心思想：事实底座只有一份，包装角度随岗位变。同一个项目，对 AI 产品岗讲模型选型和效果验证，对增长岗讲漏斗和 ROI，对投资岗讲市场判断——讲的是同一件事的不同切面，数字永远同一套。
挖掘流程
1. 先读再问
读 profile.md、已有 story-bank.md、目标岗位的 intel.md（知道往什么方向挖）。简历上已有的信息不要再问。
2. 引导倾倒（elicitation）
让用户对着一段经历自由讲（语音转文字、随手打字都行），用这组问题往深挖，一次问 2-3 个，别一次全抛：
- 这件事最初的烂摊子是什么样？你接手时数字是多少？
- 你做了什么别人没做的决定？当时反对的声音是什么？
- 结果的数字是多少？这个数字从哪份报表/哪次复盘来的？（出处必须问到）
- 中间最险的一次是什么？差点怎么砸？
- 如果重来一遍，你会改哪一步？（失败反思题的素材）
- 这件事之后，别人/组织因为你留下了什么（流程、标准、被复用的方法）？
挖掘判断：一段经历值得成卡的标准是「有决策、有数字、有反差」。只有职责描述没有决策的经历，合并进别的卡或不立卡。
3. 写卡
每张卡一个 ## 经历卡：<名字> 区块，格式严格遵守（控制台按此解析）：
## 经历卡：<项目名>
**时间**：<机构/场景> · <起止，如 2024.05 – 2025.01，或 2026.04 – 至今>
**事实底座**（数字必须带出处）
| 事实 | 数字/结论 | 出处 |
|------|-----------|------|
| 改造后收入增量 | +8% | 2025 Q3 复盘报告 |
| 验证方式 | A/B 实验 28 天 | 实验平台记录 |
**一句话版**：自我介绍里一笔带过的说法（≤40 字）。
**按岗包装**
| 岗位类型 | 讲什么角度 | 别讲什么 |
|----------|-----------|----------|
| AI 产品 | 意图识别准确率怎么从 35% 做到 50% | 内部审批流程 |
| 增长/商业化 | 收入结构和 ROI 怎么算 | 技术实现细节 |
**可被追问点**
- 数字出处会被挖：答法要点
- 反事实（如果不做会怎样）：答法要点
写卡纪律：
**时间** 行可选但建议填：机构/场景 + 起止，控制台据此显示卡片时间锚并支持「按时间」排序。期间必须与简历一致，记不清就只写年份或留空，别编精确月份。- 禁止编造。用户没给的数字不写；用户记不清的数字标「待核：用户回忆约为 X」。每个数字都要带出处，给不出准确数字就用定性说法（「显著提升」），不硬填一个数。
- 角度可以换，事实不能变形：包装表里的「讲什么角度」是选择讲哪部分真相，禁止把 6 倍写成 10 倍这种「包装」。
4. 缺口反馈
对照目标岗位 intel.md 的匹配表：哪些 JD 要求没有任何经历卡能接 → 列出来，和用户确认是真没有（逐字稿里要正面回应缺口）还是没挖到（继续挖）。
产出后
汇报：新增/更新了哪几张卡、哪些数字还待核出处、对目标岗位还缺什么经历素材。下一步通常是 interview-script。
