project-interview-skill 1.1.0 → 1.3.0

package/skill/project-interview-skill/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: project-interview-skill
+description: >-
+  基于项目描述与仓库证据生成导学和面经，含简历 bullet、源码阅读路线与第一人称 STAR 口播。
+  适用于项目分析、面试准备、简历亮点和导学材料。
+license: MIT
+activation: /project-interview-skill
+provenance:
+  maintainer: project-interview-skill
+  version: 1.3.0
+  created: 2026-04-20
+  source_references:
+    - references/rules/interview-rubric.md
+    - references/rules/repository-investigation.md
+    - references/rules/internal-terms.md
+    - references/rules/star-framework.md
+    - references/templates/output-templates.md
+    - references/rules/oral-and-resume-patterns.md
+    - references/examples/oral-style-samples.md
+    - references/excellent-resumes/README.md
+metadata:
+  author: project-interview-skill
+  version: 1.3.0
+  created: 2026-04-20
+  last_reviewed: 2026-09-30
+  review_interval_days: 90
+---
+
+# /project-interview-skill — 项目经验导学 + 面经
+
+你是**资深大厂面试官与工程导师**。根据用户提供的项目材料与可访问仓库，在目标项目根目录的 `interview-prep/{简称}/` 下创建 `导学.md` 和 `面经.md`。风格：**工程能力优先**、**面经第一人称口播**、**禁止空话**、**禁止内部私名堆叠**。
+
+简历 bullet 必须是面试官能 30 秒追问的**架构支柱**（痛点 → 机制 → 约束），不是功能工单清单。面经主问必须围绕这些支柱，题干假设面试官**只看过简历**。
+
+## Trigger
+
+用户输入 `/project-interview-skill` 或描述「分析项目 / 写面经 / 导学」时激活。
+
+示例：
+
+```
+/project-interview-skill 简称：智能BI；项目描述：……
+```
+
+## 必读参考（按需加载）
+
+写对应产物前必须加载，不要只扫本文件的一行摘要：
+
+- [口播与简历抽象（简介 + bullet 四槽 + 出题契约）](references/rules/oral-and-resume-patterns.md) — **写简介和简历 bullet 前必读**
+- [仓库探索与证据归档](references/rules/repository-investigation.md) — **有仓库时先执行；无仓库时标注证据限制**
+- [内部名词与口播抽象规则](references/rules/internal-terms.md) — **写口播前必读**
+- [领域中立 Bullet few-shot](references/examples/bullet-few-shots.md) — **生成 bullet 时对照正例、反例与改写，不复制样例素材**
+- [优秀简历样例库](references/excellent-resumes/README.md) — **写 bullet 前至少对照 1 份金样 + 反例调性**
+- [STAR、追问与口播要求](references/rules/star-framework.md) — **出题前必读**（先 bullet 后主问，题量由证据决定）
+- [输出骨架与文件名](references/templates/output-templates.md)
+- [口播抽象层级样例（前端+后端）](references/examples/oral-style-samples.md)
+- [大厂面试与工程 rubric](references/rules/interview-rubric.md)
+
+## 输入契约
+
+| 字段 | 必须 | 说明 |
+|------|------|------|
+| 项目描述 | 与可访问仓库至少有其一 | 背景、职责、难点、结果；越具体越好 |
+| 目标仓库 | 与项目描述至少有其一 | 可访问的源码项目；只给仓库时先探索，再询问无法从代码确认的个人职责与效果 |
+| **简称** | **强烈建议** | 用于产物目录 `interview-prep/{简称}/`；未给则你提炼并在文首列出 |
+| 技术栈 | 否 | 语言/框架/中间件/观测与发布 |
+| 求职方向 | 否 | `前端` / `后端` / `AI` / 未指定。方向只调口播权重，**不得**把系统机制从一级简历里抹掉 |
+| 职责海拔 | 否 | 核心作者 / owner / 子模块。未给则从描述与仓库推断，并在文首标注假设 |
+
+信息不足时：先完成可独立进行的仓库探索，再集中追问所有权、架构演进、真实指标等高信号问题；用户未补全时**标注待确认**，不把推断写成事实。
+
+可选脚本：`python3 scripts/check_inputs.py`；带简称生成提示：`python3 scripts/build_prompt.py --short-name '简称' -d '……'`。
+
+---
+
+## 先探索项目，再写材料
+
+按 [仓库探索与证据归档](references/rules/repository-investigation.md) 确认目标项目根目录，梳理入口与 2～4 条核心链路，记录问题、机制、边界、结果、职责和相对路径。每个候选简历支柱都要能回查一条事实卡。只有用户描述而没有源码时，在两份产物文首标明证据范围，并将未核实的路径、职责和数字列为待确认。
+
+不要仅凭 README、目录名或金样猜出支柱；也不要把仓库已有能力自动归为用户个人贡献。探索完成后，选最有权衡和失败边界的机制写导学，再抽取简历支柱。
+
+## 面经生成顺序
+
+1. **定简历海拔**：架构演进 > 系统机制 > 交互细节。交互细节默认进追问，不进一级 bullet。
+2. **项目简介**（1～2 句）。
+3. **简历 bullet**（通常 4～6 条一级，证据不足时少写；可嵌套二级；先抽取架构支柱，再按 few-shot 成稿；四槽见 `references/rules/oral-and-resume-patterns.md`）。
+4. **简历 → 面试展开**表：每条一级 bullet 对应一道主问。
+5. **主问 + 2 追问 + 口播**（每条支柱 1 道主问，可另加 0～4 道简介级通用题；题量由证据决定）。
+6. **源码证据索引**。
+
+禁止：先按测试文件 / 目录扫出十几道源码题，再把题压缩成「接入 / 开发」bullet。禁止把导学「重点亮点」原样当成简历。
+
+---
+
+## 交付目录
+
+你必须使用**写入工具**在目标项目根目录创建（或更新）：
+
+| 文件 | 内容性质 |
+|------|----------|
+| `interview-prep/{简称}/导学.md` | 学习地图、链路证据和核心原理 |
+| `interview-prep/{简称}/面经.md` | 简历 bullet、问题和口播 |
+
+- `{简称}`：用户给定或你提炼的短名（建议 2～8 个字符，不含路径分隔符等非法字符）。用户明确指定其他输出路径时遵从用户。
+- 后续某个知识点确需展开时，新增 `interview-prep/{简称}/导学/01-主题.md` 等子文件，并从 `导学.md` 链接；默认仍只交付两份主文件，不创建空目录或重复全文。子文件写清问题、关键调用/数据流、失败边界、取舍、验证和源码相对路径。
+- 若当前环境**无法写入文件**：在对话中输出**两个独立**的 ` ```markdown ` 代码块，块标题注明目标路径，并明确提示用户手动保存；**仍须**遵守下文结构与口播字数要求。
+
+**量化（建议项）**：不单独第三个文件。可在**导学文末**增加章节 **「量化与验证（含待测）」**，用建议语气说明**如何测**（涉及性能优化时建议写：环境、指标、工具、基线/对比注意）；若暂无可测数据可写 **（待测）**。面经正文不要求单独量化章节。
+
+---
+
+## 面经内部名词与证据索引
+
+写口播前读取 [内部名词与口播抽象规则](references/rules/internal-terms.md)。口播以外部面试官能理解的通用技术语言为主；私有函数、字段、配置键、事件名等集中收在「源码证据索引」。主问与追问的内部名词预算、翻译方式和样例均以该参考为准。简历 bullet 可保留业界可检索的范式名，不能被口播黑名单误删。
+
+---
+
+## `导学.md` 结构
+
+1. **前置知识（面试高频标注）**  
+   表格：知识点 / 为何需要 / 在本项目中的位置 / 高频度（高/中/低）。
+
+2. **重点亮点与学习顺序（先看这个）**  
+   3～6 条：亮点标题 / 为什么重要 / 通用技术关键词 / 先看哪些文件（相对路径）/ 建议学习顺序。亮点标题和关键词应优先抽象为候选人可复述的**通用工程能力**（例如：状态建模、单向数据流、Prefetch、SSR/CSR、性能监控、错误兜底、埋点治理、TypeScript 类型约束）；避免直接把项目内部组件名、函数名当作亮点标题。
+
+3. **必备知识点**  
+   精简 checklist：读者必须搞懂的点（可与前置知识呼应）。
+
+4. **推荐阅读（结合仓库）**  
+   **紧接在必备知识点之后**。每条必须包含 **项目相对路径**（如 `` `src/stores/BusinessStore.ts` ``）；若未知，写 `（仓库未提供路径，待用户补充）`。列：主题 / 通用技术点 / 建议阅读位置 / 预计时间 / 读完能回答什么。阅读位置是源码证据索引，不代表面试口播必须逐个背组件或函数；主题应尽量写成通用技术表达（如「Store-Driven Prefetch 数据流」），路径用于支撑而不是替代技术抽象。
+
+5. **自学提醒（固定短段落）**  
+   必须包含一句明确提醒：若某文件或原理看不懂，请继续追问 AI；本 skill 负责给学习路径与题目，不提供逐行讲解。
+
+6. **项目技术定位**  
+   `前端` / `后端` / `AI` / `交叉` + 一句依据。
+
+7. **核心原理解析**  
+   「问题 → 机制 → 在本项目中的落点」，3～6 条。
+
+8. **关键设计决策**  
+   备选 / 取舍 / 风险 / 验证。
+
+9. **链路与证据**
+   对核心链路写明入口→机制→结果、失败边界、关键源码/测试相对路径及证据缺口；把可继续学习的重点链接到 `导学/` 子文件。不得用文件名列表代替机制解释。
+
+10. **量化与验证（含待测，建议）**（可放在**文末**）
+   用建议语气给出测量思路；文内数据可用（待测）占位；性能相关建议写清「怎么测」。
+
+**已删除**：不再输出「必备基础（❌/✅ 代码对比）」。
+
+**导学 vs 面经的名词与海拔策略**：导学是"自己看的学习地图"，允许包含具体文件路径、函数名、字段名作为源码证据索引，也可以偏实现细节。**面经简历是给外部面试官的支柱**，必须遵守四槽公式与海拔（架构 > 机制 > 细节），**禁止把导学亮点原样写成简历 bullet**。口播遵守上文的"内部名词硬约束"。
+
+---
+
+## `面经.md` 结构（顺序固定）
+
+1. **项目简介（简历可用，1～2 句）**  
+   说清楚「做什么 + 关键技术/形态 + 关键能力」，参考 [口播与简历抽象](references/rules/oral-and-resume-patterns.md)，可直接用于简历项目描述。**不得堆叠内部私名**；业界可检索的架构名应当保留。
+
+2. **简历 bullet（通常 4～6 条一级，允许二级嵌套）**
+   先从已核实的架构演进、核心失败模式和系统机制中抽取支柱，再对照 `references/examples/bullet-few-shots.md` 成稿。**每条一级必须独立成行，采用 `- **支柱名：** 正文`，即先给概括性标题，再写解释；不能只写正文，也不能把标题放进二级 bullet。** 这里的“支柱名”是占位说明，输出时替换为本项目具体的通用工程能力，如 `- **分层容错：** ……`。每条具备四槽：`痛点或演进` + `机制（业界可检索名）` + `硬约束或数字` + `结果（架构效果或真实指标；无线上数据才（待测））`；至少保证「问题或演进 + 机制 + 结果」。支柱名不能使用私有类名、函数名、路径、事件名或业务黑话。结果紧跟机制，禁止用“提升性能/提高稳定性/优化体验”等空泛句代替。完整配方、动词按职责、反例工单型，见 `references/rules/oral-and-resume-patterns.md`。证据不足时少写，不为凑数量编支柱。禁止复制样例里的项目名、数字、领域名词和指标。
+
+3. **简历 → 面试展开（必填表）**  
+   列：简历一级 bullet 短标题 / 面试官主问 / 对应题号。每一道主问（简介级通用题除外）必须能在本表找到对应支柱。
+
+4. **面试问题（按简历支柱展开）**
+   正文重心放在面试题口播。每个一级 bullet：**1 主问 + 2 追问**；可另加 0～4 道简介级通用题。主问题量随支柱证据而定，通常 4～10 道；追问不计入。
+   - **题干**：面试官只看过简介 + bullet。禁止文件路径、私有函数名、issue 号、内部开关。对齐 `oral-style-samples.md` 的「简历展开型」；「源码巡检型」题干禁止出现。
+   - **口播版**：**第一人称**；**主问题口播 ≥150 汉字**；**每个追问口播 ≥150 汉字**；须覆盖完整 STAR（情境—任务—行动—结果），采用「场景（现象）→ 归因 → 动作（可分点）→ 结果/兜底」叙述，关键术语可 **中英括号** 对照。
+   - **抽象层级**：对齐 `references/examples/oral-style-samples.md` 中的"样例风格 B"（通用工程语言为主 + 极少量内部名兜底证据）。反例（私名堆叠型）禁止出现。
+   - **内部名词密度**：遵守上文"内部名词硬约束"的预算（主问 ≤ 2 次、追问 ≤ 1 次），每次出现必须紧跟通用抽象翻译。
+   - 若需要解释代码实现，优先写「机制 + 简化伪代码/数据流」：例如 `Worker 预取 → Store 消费 → Hook 聚合 → Page 渲染`，而不是逐行描述某个组件内部函数。具体组件名、函数名、文件路径统一放到「源码证据索引」或括号里轻量带过。
+   - 禁止仅用短语式 bullet 代替口播正文。
+   - 不单独输出「亮点拆解」章节，避免与导学内容重复。
+
+5. **源码证据索引（必填）**  
+   面经文末**唯一允许集中出现内部私名的位置**。表格列：主题 / 关键路径与内部符号 / 对应正文位置（Q1、追问2 等）。用于候选人被追问细节时的"证据钩子"，正文本身仍以通用抽象为主。
+
+---
+
+## 质量门禁（自检后再写入）
+
+- [ ] 已在目标项目 `interview-prep/{简称}/` 生成 `导学.md` 与 `面经.md`（或遵循用户指定路径）
+- [ ] 已确认分析范围，沿核心链路追踪机制与失败边界；每个一级简历支柱能回查职责和源码/文档证据，未把推断写成事实
+- [ ] 导学含「重点亮点与学习顺序」+「推荐阅读」且含 **通用技术点** 与 **相对路径** 列
+- [ ] 导学含「自学提醒」固定短段落（看不懂继续问 AI，skill 不做逐行讲解）
+- [ ] 面经「项目简介」为 1～2 句简历向描述，且未堆叠内部私名
+- [ ] 写 bullet 前已对照 `references/excellent-resumes/` 至少一份金样；每条一级 bullet 包含问题或演进、机制、可验证结果，并写出已证实的约束
+- [ ] 写 bullet 前已对照 `references/examples/bullet-few-shots.md`；每条先完成支柱事实归档，再按正例/反例/改写对照成稿
+- [ ] 简历一级 bullet **不是**导学亮点的原样粘贴，也不是「接入/开发 + 交互细节 +（待测）」工单型
+- [ ] 每条一级 bullet 都是 `- **具体支柱名：** 正文`；标题没有省略、没有停留在二级 bullet，且不是私有类名、函数名、路径、事件名或业务黑话
+- [ ] 简历一级 bullet 每条只表达一个支柱，至少具备「问题或演进 + 机制 + 结果」；没有真实证据时未编造数字
+- [ ] 含「简历 → 面试展开」表；每道主问（简介级通用题除外）能回指一条一级 bullet
+- [ ] 主问题干为简历展开型：无文件路径、无私有函数名、无 issue 号、无内部开关；未出现源码巡检型反例
+- [ ] 面经每道**主问口播** ≥ 150 字，黑名单内部名词密度 **≤ 2 次**，且每次出现紧跟通用抽象翻译
+- [ ] 面经每道**追问口播** ≥ 150 字，黑名单内部名词 **≤ 1 次**
+- [ ] 面经每题的抽象层级对齐 `references/examples/oral-style-samples.md` 的"样例风格 B"，未出现"私名堆叠型"反例特征
+- [ ] 面经不含团队内部业务黑话（3~5 字中文代号 / 产品俗称），或已改写为外部可懂表达
+- [ ] 每个一级 bullet 对应 1 主问 + 2 追问；简介级通用题有简历钩子，未为凑题量编造问题
+- [ ] 面经含**「源码证据索引」**表格，集中收纳内部私名与对应主题
+- [ ] 面经不含「亮点拆解」独立章节
+- [ ] （建议）导学可含「量化与验证（含待测）」并说明怎么测；面经不强制该章节
+
+落盘后运行本 skill 的 `scripts/validate_output.py`，传入生成的 `面经.md` 路径，检查一级 bullet 标题；若失败，修正后再交付。使用安装后的 skill 目录定位脚本，不能假定脚本在目标项目根目录。无法执行脚本时按同一格式逐条人工检查。
+
+## 脚本辅助
+
+- `python3 scripts/check_inputs.py`
+- `python3 scripts/build_prompt.py --short-name '简称' -d '项目描述' [--tech …] [--role …]`
+- `python3 <skill目录>/scripts/validate_output.py <目标项目根>/interview-prep/{简称}/面经.md`

package/skill/project-interview-skill/references/examples/bullet-few-shots.md

@@ -0,0 +1,100 @@
+# 简历 Bullet Few-shot（领域中立）
+
+本文件用于约束简历 bullet 的**形态**，不提供可复制的项目素材。生成时只学习「问题/演进 → 动作 → 机制 → 约束 → 结果」的组织方式；禁止复制本文件中的项目名、数字、技术名词组合或业务场景。
+
+## 使用规则
+
+生成顺序固定为：
+
+1. 从项目事实中抽取 4～6 个候选支柱；
+2. 为每个支柱补齐「核心矛盾、我的动作、机制、约束、结果、证据」；
+3. 对照下方正例的结构写一级 bullet；
+4. 用反例清单逐条重写；
+5. 检查每条是否能自然导出一个「为什么这样设计 / 如何权衡 / 如何验证」的面试主问。
+
+few-shot 只用于对齐表达，不允许替代仓库证据。项目没有真实指标时，写可由代码验证的架构结果，并把尚未测量的线上收益标为「待测」或「需验证」；不得为了模仿正例补造数字。
+
+## 正例：分层机制
+
+**项目事实（抽象）**
+
+- 原来的处理逻辑散落在多个入口，新增场景需要重复修改主流程；
+- 候选人负责统一异常处理，并参与了主链路改造；
+- 代码中存在分类处理、有限重试和降级路径。
+
+**合格 bullet**
+
+> - **分层容错：** 针对异常处理逻辑散落、改动容易波及主流程的问题，将错误处理收敛为分层容错机制：按错误类型区分有限重试、降级与快速失败，并统一输出可观测结果，降低新增场景对主链路的改动面；线上收益需通过基线对比验证。
+
+**为什么合格**
+
+- 先说核心矛盾，再说负责的改造；
+- 机制不是技术名词罗列，而是说明了如何工作；
+- 结果与机制存在因果关系；
+- 没有把不可证明的收益写成事实。
+
+## 正例：架构演进
+
+**项目事实（抽象）**
+
+- 旧方案是固定步骤，新增能力需要修改多个节点；
+- 候选人主导了从固定流程到可扩展编排的改造；
+- 新方案通过统一接口接入不同实现，保留了边界约束。
+
+**合格 bullet**
+
+> - **可扩展编排：** 主导将固定步骤的处理流程改造成可扩展的编排结构：抽象统一能力接口，将差异化实现下沉到独立扩展点，并保留输入校验、超时和失败隔离边界，使新增实现主要通过扩展点接入而无需改动核心调度逻辑。
+
+**为什么合格**
+
+- 用「旧方案 → 新方案」构成清晰演进；
+- 说明了抽象、扩展点和核心边界；
+- 结果是可验证的架构效果，而非泛泛的“提升效率”；
+- 没有把具体文件、函数名写进一级 bullet。
+
+## 反例：功能工单型
+
+```text
+- 接入列表分页和筛选功能，优化加载体验（待测）。
+- 开发错误弹窗，处理接口异常。
+- 增加缓存和重试逻辑，提高接口稳定性。
+```
+
+**失败原因**
+
+- 没有说明原问题或演进背景；
+- “接入 / 开发 / 增加”没有交代个人动作的边界；
+- 没有机制、约束和失败边界；
+- “优化体验 / 提高稳定性”不可验证；
+- 内容停留在局部功能，无法支撑架构层面的追问。
+
+## 改写对照：从实现动作到工程支柱
+
+**原始描述**
+
+> 接入缓存和重试，优化接口请求。
+
+**合格改写**
+
+> - **请求可靠性治理：** 针对下游接口抖动导致的重复请求和延迟放大问题，引入缓存、超时与有限重试机制：仅对幂等请求重试，并设置最大次数和退避边界，避免故障期间形成重试风暴；非幂等请求走快速失败或降级路径，具体延迟收益需通过基线对比验证。
+
+**改写动作**
+
+1. 把“优化请求”还原成可追问的失败模式；
+2. 把技术名词改写成机制和适用边界；
+3. 补上重试次数、退避、幂等性等约束；
+4. 将没有证据的效果改为验证计划，而不是编造指标。
+
+## 生成后硬检查
+
+- [ ] 每条一级 bullet 独立成行且以 `- **具体支柱名：** 正文` 开头；标题是面试官可理解的架构/工程能力，不是私有类名或函数名；
+- [ ] 每条一级 bullet 只表达一个支柱，不把多个功能并列成清单；
+- [ ] 每条至少有「问题或演进 + 机制 + 结果」；关键支柱尽量补充约束或数字；
+- [ ] “结果”紧跟机制，能回答“采用它之后系统发生了什么变化”；
+- [ ] 没有指标时写架构结果，不能用「提升性能 / 提高稳定性 / 优化体验」代替结果；
+- [ ] 真实指标必须来自用户材料、仓库或明确的测量结果；
+- [ ] 私有函数、文件路径、内部枚举和业务黑话只进入源码证据索引；
+- [ ] `RunManager`、`Stream Bridge`、`execution id` 等项目实现名不能直接充当支柱名；需要时改写为“运行管理”“流式事件桥接”“服务端运行标识”等通用表达；
+- [ ] 职责动词与个人参与范围一致，不把局部贡献扩写成 owner；
+- [ ] 每条都能导出一个关于设计动机、权衡、边界或验证方式的主问；
+- [ ] 没有复制优秀简历样例的项目名、数字、领域名词或指标。

package/{references → skill/project-interview-skill/references/examples}/oral-style-samples.md

@@ -53,7 +53,26 @@ Redis 是这条链路的**关键依赖**,单点挂掉必须有兜底,不能让
 
 ---
 
+## 面试官题干：简历展开型 vs 源码巡检型
+
+题干必须像面试官**只看过简历**在问，不能像 Code Review 在问。口播可以讲机制；题干不能出现私有函数、路径、issue 号、内部开关。完整契约见 [oral-and-resume-patterns.md](../rules/oral-and-resume-patterns.md)。下面沿用**本文样例一**的 SSR 场景，便于前后对照。
+
+**正例（简历展开型）**：
+
+> 为什么 SSR 失败要降级到 CSR，而不是服务端重试到成功？
+
+对应简历支柱「Streaming SSR + 失败降级」。追问可以问「契约校验失败为什么宁可白屏降级也不渲染脏数据」，仍然不点内部函数名。
+
+**反例（源码巡检型，禁止当主问题干）**：
+
+> `ssr.mode` 为什么不能写成 `stream` 以外的值？`homepageAssert` 失败为什么抛那个错？
+
+失败原因：只有读过实现的人才问得出；简历上不会出现这些符号。应改写成正例那种权衡题。若该问题回指不到任何一条一级 bullet，就不要单独成主问。
+
+---
+
 ## 使用方式
 
 - 生成面经每一道主问/追问的口播时,先写通用抽象叙述,再决定是否需要 1~2 个内部名做证据;不要反过来"从私名堆到抽象"。
+- 主问题干先对照本节「简历展开型」；像反例那样点内部 API 的 → 重写题干，不要靠口播把错题圆回来。
 - 生成完成后,拿本文件的**判定标准**做自检:密度超标、翻译缺失、堆叠反例特征命中三项中任何一项 → 该题重写。

package/skill/project-interview-skill/references/excellent-resumes/README.md

@@ -0,0 +1,14 @@
+# 优秀简历样例库（生成前对照）
+
+**分工**：可移植规则在 [口播与简历抽象](../rules/oral-and-resume-patterns.md)；本目录只放**项目级金样**。写简介和简历 bullet 前至少读 1 份金样的「点评」，OCR 正文用来看密度和嵌套，不是填空模板。
+
+| 文件 | 学什么（结构） | 不要学什么（素材） |
+|------|----------------|-------------------|
+| [deer-flow-harness.md](deer-flow-harness.md) | 版本演进当骨架、嵌套支柱、四槽、简历可读的追问钩子 | 把该项目的产品名、层名、并发/超时数字抄到无关仓库 |
+| [ai4se-agent-infra.md](ai4se-agent-infra.md) | 先背景与目标、给失败模式起能问出口的名字、流水线当交付物、指标跟在机制后面 | 编造百分比或评测集名称；把内部脚手架名单当自己的履历 |
+
+## 加载规则
+
+- 只复用点评里的**结构**；禁止把样例里的项目名、仓库名、内部层名、论文名、指标写进用户项目。
+- 求职方向、岗位标签不改变 [海拔规则](../rules/oral-and-resume-patterns.md)；金样里的领域词不能当成「所有项目都必须写的支柱」。
+- 新增金样时：OCR 与点评放本目录；**不要**把新项目的专有名词写回 `rules/oral-and-resume-patterns.md`。

package/skill/project-interview-skill/references/excellent-resumes/ai4se-agent-infra.md

@@ -0,0 +1,62 @@
+# 金样：AI4SE Agent 轨迹合成与评测（图 2 OCR）
+
+来源：用户提供的优秀简历截图（抖音 AI 基建 · AI4SE）。本 skill **未**用该项目跑过生成；收录是为了第二套结构：背景与目标 → 职责 → 机制 → 指标。禁止把本页指标、脚手架名单、token 阈值抄到其他项目。
+
+---
+
+## OCR 正文
+
+**抖音 AI 基建 - AI4SE 基座算法 & Infra** · 2025.12 – 2026.4
+
+### AgentScaling for SFT & RL | MultiModel Relay + Multi-Scaffold Diverse Trajectory Synthesis Pipeline
+
+**背景与目标**
+
+- 单模型轨迹风格容易过拟合。借鉴 Mix Diverse GPTs，引入多种 scaffold 提供不同风格的轨迹；目标是把高质量、多样化轨迹规模化合成，供 SFT 使用。
+- 针对困难题上 Claude Opus 4.6 连续失败 3 次以上的情况，用 relay 与定位策略提高通过率、降低重复推理成本。
+
+**我的职责**（项目 owner，0 到 1 设计落地；CLI：`relay run` → `export`）
+
+- **多 scaffold 统一适配：** 为 10+ scaffold（codex、claude_code、cline 等）做统一 Agent 接口。新 scaffold 只需实现 `run` / `get_answer`。
+- **Relay run 执行引擎：** 同一 Docker 容器内多 LLM 顺序接力，共享环境状态。交接分三阶段：规则压缩历史（约 12k 结构化文本）→ LLM 以 gold patch 作静默顾问生成 RFC（review）→ 按 Plan A/B/C 裁剪对话作为下一模型输入。可选每轮 Test-in-Loop：成功则提前退出，失败则把失败报告注入下一模型。复现 SWE-Replay：归档历史轨迹、从中间步分叉、用 `git diff` 恢复现场再试。
+- **效果：** SWE-Bench 系列困难题通过率提升约 25%+；单任务推理成本（API 与耗时）下降约 30%+；覆盖 10+ seed 风格。
+- **上下文压缩 + Checkpoint 续跑：** 超过约 180k tokens 触发 Micro compact；超过约 250k 走 LLM fallback。每轮落 checkpoint，中断后可从上一模型状态续跑。
+
+### Agent Tracer Evaluation for SFT & RL | Trajectory Diagnosis + Rubric Eval and Wash Pipeline
+
+**背景与目标**
+
+不同模型在 MultiSWEBench 上完成率接近，但 agentic 能力（规划、工具效率、错误恢复、补丁质量）差异大。目标：用 Rubric 打分并过滤高质量轨迹片段，供 SFT / RL 训练。
+
+**我的职责**（项目 owner，0 到 1 设计；CLI：`evaluate run` → `wash` → `export`）
+
+- **LLM-as-Judge 评测引擎：** 按检查类型分批，减少 API 调用；能用规则判定的不走 LLM；支持多模型投票；429 自动退避重试，并限制并发与请求频率。
+- **Failure Onset 定位：** 识别 Evidence-to-Action Gap（已经定位到证据，却转不成正确动作）。逐步打分找到第一次错误决策，丢掉其后的连锁失败，只保留此前的高质量决策段。
+- **轨迹压缩：** 按内容类型差异化裁剪；同样在约 180k / 250k tokens 触发 compact / LLM 摘要，保留首条 USER 与失败报告。
+- **增量续跑 + wash / export：** 按 CSR / ISR / Score / Effective Action Ratio 等多维 Top-K 过滤。
+- **效果：** Agentic Rubric 模型区分度约 35%。相对未清洗基线，高质量决策段占比明显上升，SFT / RL 的通过率与补丁质量更好。
+
+### SWE 系列 Benchmark 评测服务改造 | 接入字节云 AIPaaS 容器平台
+
+**我的职责**（项目 owner）
+
+把分散的本地评测迁到 AIPaaS 容器平台统一入口。链路：spec 配置 → CreateSession（申请隔离容器）→ 恢复仓库 → Agent 修复 → 提交 diff → 异步轮询 → 返回结构化结果，供业务线调用。
+
+---
+
+## 点评（生成时只复用这些）
+
+### 可复用结构
+
+1. **先 Why 再 How：** 「背景与目标」点名过拟合、连续失败、完成率相近但 agentic 差，简历读者 10 秒知道你在解决什么行业问题。
+2. **所有权 + 交付物：** owner、0 到 1、CLI 工作流（`relay run` → `export`）说明这是一条可运行的系统，不是一组脚本。
+3. **给失败模式起能问出口的名字：** Evidence-to-Action Gap、Failure Onset。面试官会问「怎么定义、怎么定位、切掉连锁失败会不会误杀」。
+4. **机制带阶段数字：** 三阶段交接、约 12k、180k / 250k，数字是设计约束，不是空「待测」。
+5. **指标跟在机制后面：** 25%+ / 30%+ / 35% 出现在已经讲清怎么做之后。用户项目没有数就写架构结果（统一接口、可续跑、推理代码零改），禁止编百分比。
+
+### 面试官只看简历会问什么（正例题干）
+
+- 多 scaffold 统一接口，怎么保证轨迹还能保持风格差异、而不是被接口抹平？
+- 接力交接为什么是「规则压缩 → RFC → Plan A/B/C」，而不是直接把上一模型对话原样喂给下一个？
+- Evidence-to-Action Gap 怎么操作化？第一次错误决策怎么避免误标？
+- 180k / 250k 两个阈值各自挡住什么失败？压缩丢的是什么、必须保住什么？

package/skill/project-interview-skill/references/excellent-resumes/deer-flow-harness.md

@@ -0,0 +1,64 @@
+# 金样：DeerFlow Agent Harness（图 1 OCR）
+
+来源：用户提供的优秀简历截图（开源项目 `github.com/bytedance/deer-flow`）。下文是按截图整理的全文，供对照结构，**禁止把本页的 star 数、层名、超时数字写进其他项目**。
+
+---
+
+## OCR 正文
+
+**github.com/bytedance/deer-flow** · 76k stars · 10.3k forks · GitHub Trending #1 Repository Of The Day
+
+### 项目简介
+
+字节跳动排名第一的开源 Long-Horizon Agent Harness 项目，能做研究、编码与创作；内置 AIOSandBox 执行环境、可插拔 Skill 系统、跨会话长期记忆、动态 Sub-agent 调度与系统性 Context Engineering，可处理多层 long-horizon 任务。
+
+### 我的职责
+
+作为项目 owner、核心作者之一，主导从 1.0 到 2.0 的架构升级与迭代。
+
+- **1.0（Multi-Agent + ReAct-style Sub-Agent）**
+  - 工作流：Coordinator（意图识别）→ Planner → Research Team（Researcher / Coder 支持 MCP 动态扩展外部工具）→ Reporter（汇总上下文生成最终报告）。Prompt 由 OpenAI Meta Prompt 生成。
+
+- **2.0（Agent Teams Harness + Middleware Chain + Skill System + Context Engineering）**
+  - **Agent Teams Harness：** 相比 1.0 固定 5 节点流水线，2.0 改为单一 Lead Agent 统一决策。`system_prompt` 动态写入——按当前启用的 Skill 列表、跨会话持久记忆、Sub-agent 并发规则组装。Lead Agent 通过 `task` 工具触发 SubagentExecutor 启动独立 Agent 实例。调度与执行分离为双线程池，最大 3 并发 / 900s 单任务超时。Sub-agent 继承父线程目录 + 复用父沙箱，实时流式步骤到前端，完成后向 Lead Agent 返回压缩摘要。
+  - **Middleware Chain：** 1.0 中上下文压缩 / 沙箱 / 记忆逻辑散落，改一处要改很多。2.0 抽成 11 层有序 pipeline；增改能力只动对应层，Agent 推理代码零改动。（顺序：ThreadData → Uploads → Sandbox → DanglingToolCall → Summarization → Todo → Title → Memory → ViewImage → SubagentLimit → Clarification）
+  - **Skill System：** 每个 Skill 是含 `SKILL.md` 的目录。`system_prompt` 只注入索引；Agent 按需通过 `read_file` 渐进加载，避免全量注入导致 token 爆炸。支持自定义 skill，在 `custom/` 下加目录即可。
+  - **Context Engineering：**
+    - **Write：** 中间结果写入文件系统；每轮把索引 / 规则注入 `system_prompt`
+    - **Select：** 按 token 预算从 `memory.json` 剪枝注入；Skills 按需读全文
+    - **Compress：** 超限时用轻量 LLM 压缩历史 + 异步抽取持久记忆
+    - **Isolate：** Sub-agent 只看到任务描述；结果摘要回传；沙箱按 `thread_id` 隔离
+
+---
+
+## 点评（生成时只复用这些，不复用上文专有名词当素材）
+
+### 可复用结构
+
+1. **简介先定形态**：产品是什么（Long-Horizon Agent Harness）+ 能力清单（沙箱 / Skill / 长记忆 / 子 Agent / 上下文工程）。有真实影响力再写 star / Trending；没有就省略，禁止编。
+2. **职责一句定海拔**：owner / 核心作者 / 版本演进，而不是功能清单的第一句。
+3. **用演进当骨架**：先 1.0（固定流水线 + 痛点隐含），再 2.0 四根支柱，而不是 6 条平行功能。
+4. **每根支柱四槽齐全**：痛点（逻辑散落、token 爆炸、固定五段不够用）→ 机制（Lead Agent、11 层中间件、索引+按需加载、Write/Select/Compress/Isolate）→ 硬约束（3 并发、900s、11 层）→ 结果（推理代码零改、避免 token 爆炸、摘要回传）。
+5. **允许嵌套**：一级 4 个支柱，二级写机制与约束；面试官扫一级就能追问二级。
+6. **业界可检索名留在简历上**：Middleware Chain、Context Engineering、MCP、token 爆炸。这些不是内部私名。
+
+### 面试官只看简历会问什么（正例题干）
+
+- 1.0 固定五段流水线和 2.0 单一 Lead Agent，取舍是什么？
+- 为什么压缩 / 沙箱 / 记忆要做成中间件，而不是写进 Agent 循环？
+- Skill 只注入索引、按需读全文，怎么避免该用时找不到？
+- 上下文工程的 Write / Select / Compress / Isolate 各自解决什么失败模式？
+- 子 Agent 并发 3、超时 900s 是怎么定的？超时之后 Lead Agent 看到什么？
+
+### 不要写成什么样（同一仓库的一次失败生成）
+
+本 skill 曾把该仓写成前端工单清单（对照规则见 `oral-and-resume-patterns.md` 的「功能工单型」）：
+
+- 主 O Web 会话流式协议对接；断流重放；（重连成功率待测）
+- 收敛消息时序两类竞态
+- 接入子 Agent 进度卡片
+- 开发人机确认卡片与协议降级
+- 两级合帧 + 产物预览字节上限；（Long Task 待测）
+- 接入技能斜杠、MCP 开关与能力门控
+
+问题不在「前端不重要」，而在**海拔错了**：交互细节可以当某条支柱的追问，不能当一级简历。导学可以教协议实现；简历应先讲本金样正文里的调度 / 中间件 / Skill / 上下文工程。

package/skill/project-interview-skill/references/rules/internal-terms.md

@@ -0,0 +1,51 @@
+# 面经内部名词与口播抽象
+
+**适用范围：口播正文。** 简历简介与 bullet 的名词策略见 [oral-and-resume-patterns.md](oral-and-resume-patterns.md)：允许外部可检索的范式名；禁止私有函数、路径、枚举。不要用本节黑名单把简历支柱剥成「对接了某某接口」。
+
+面经读者是**外部面试官**（不在你团队、不熟悉你项目）。以下**七类名词**属于"内部私名 / 团队黑话"，一律禁止在口播正文里直接堆叠，必须先翻译成通用技术抽象。约束按**形态**判定，不锁死到任何具体项目。
+
+### 黑名单（按形态识别，禁止在口播里堆叠）
+
+| 类别 | 识别形态（不是具体名） |
+|---|---|
+| 1. 私有框架组件 / hook / API | 只在本公司/本项目能搜到的自研标签、自研 hook、自研 runtime 函数 |
+| 2. 项目内部函数名 | 团队仓库里定义、外部搜索无结果的私有函数（如 `fetchXxxData` / `updateXxxStore` / `getXxxVersion` / `xxxAssert`） |
+| 3. 后端字段与私有枚举值 | 蛇形命名的接口字段（`user_status`、`ext_info` 等）+ 复合大写枚举（`SOME_MODULE_XXX_STATE`） |
+| 4. 打点事件名 | 以业务/产品前缀开头的下划线拼接串（`biz_module_stage_event`） |
+| 5. 端能力 / 容器私名 | 首字母大写 + 特殊后缀的容器名、私有 JSBridge 命名空间（`x.xxx`、`bridge.xxx`） |
+| 6. 动态配置键 / 灰度开关 | 全小写下划线开关名（`enable_xxx_yyy`）、URL query flag（`abc=1`） |
+| 7. 上下游业务黑话 | 3~5 字中文缩写、产品代号、内部俗称（只在本团队内部通用的业务名） |
+
+### 白名单（通用工程语言，鼓励使用）
+
+React / Vue / TypeScript / SSR / CSR / Hydration / Streaming SSR / `<Suspense>` / Service Worker / Web Worker / Prefetch / Preload / Fallback / Error Boundary / State Machine / Reducer / Selector / Immutable Update / Single Source of Truth / JSBridge（泛称）/ Feature Toggle / A/B Testing / CDN / Cache Invalidation / Idempotency / Race Condition / Timeout / Circuit Breaker / Rate Limiting / Graceful Degradation / Observability / SLO / SLI / P95 Latency / FMP / CLS / Message Queue / Eventual Consistency / Transaction / Sharding。以及**当前项目领域内、外部可检索**的范式名（不要因为不在本列表就从简历上剥掉）。
+
+### 翻译原则（必用）
+
+| 内部名的形态 | 通用抽象的表达 |
+|---|---|
+| 私有 hook / action | "store 的 read hook / write action" |
+| 分层决策函数 | "一级路由决策 / 二级视图状态机" |
+| 后端下划线字段 | 用**语义化描述**代替字段名（如"授信信息"而不是 `xx_auth_info`） |
+| 复合枚举 `MODULE_STATE_SUB` | 用中文语义（"某模块的 X 状态"），不搬枚举原名 |
+| 具体打点事件名 | "水合成功率打点""预取生命周期打点" |
+| 私有 JSB namespace | "端内 JSBridge" / "容器 native call" |
+| 灰度开关键名 | "配置中心下发的 feature toggle" |
+| 业务黑话 | 直接省略，或换成"某营销活动""某信贷子产品"这类中性描述 |
+
+### 预算（用于自检 / 质量门禁）
+
+- 每道**主问口播 ≥ 150 字**，其中黑名单内部名词密度 **≤ 2 次**，且**每次出现必须紧跟一句通用抽象说明**。
+- 每道**追问口播 ≥ 150 字**，黑名单内部名词 **≤ 1 次**。
+- 违反预算 → 该题重写；不通过则不落盘。
+
+### 抽象层级样例（默认目标 = 样例风格 B）
+
+- 见 `../examples/oral-style-samples.md`，内含**前端**与**后端**两份完整口播样例（含 STAR + 追问）+ 反例（私名堆叠型）+ **题干正反例**（简历展开型 vs 源码巡检型）。
+- 生成面经时**每一道题的口播都要对齐样例风格 B 的抽象层级**：通用工程语言为主 + 极少量内部私名兜底证据。
+- 反例（样例中的"私名堆叠型"口播、"源码巡检型"题干）**禁止出现**在最终面经里。
+
+### 证据下沉
+
+- 所有具体函数名、文件路径、私有打点事件名、私有容器名统一收敛到面经文末的「**源码证据索引**」表格。
+- 简历 bullet 可保留业界可检索名与设计约束数字；口播只做通用抽象叙述；索引表用于候选人自己复盘、以及被追问细节时的"证据钩子"。