# Project Interview Deep Dive

> 基于实习、项目或产品经历的 PRD、文档、截图、复盘、数据和口述事实，协作梳理成可深挖的项目面试准备档案。用于准备“讲讲这个项目”、真实面试追问、方案取舍、AI/Agent、协同、指标与复盘；先提交可调整的问题清单和思考框架供用户确认，再输出最终内容，且绝不编造事实或成果。

- Skill: `wangjiayi0124-joy/project-interview-deep-dive` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add wangjiayi0124-joy/project-interview-deep-dive`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wangjiayi0124-joy/project-interview-deep-dive/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: wangjiayi0124-joy (https://skillmd.com/u/wangjiayi0124-joy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/wangjiayi0124-joy/project-interview-deep-dive

---


# 项目面试深挖

将项目材料整理为被面试者可快速复习的答题地图。不要输出泛化题库、简历美化文案或给面试官念的长篇话术。

## 工作原则

- **从项目出发，不硬套模板**：模板规定信息组织方式，不规定必须问哪些问题、必须用哪些维度。根据项目类型、角色、阶段、材料与真实矛盾，增删、合并、调整问题和思考维度。
- **以真实面试路径组织**：先模拟面试官会怎样起问、怎样顺着回答追问，再组织问题。不要把“产品能力”“协同能力”之类抽象名词当作问题标题。
- **以事实为边界**：不得虚构成果、数据、调研、个人贡献、技术细节、用户反馈或协同结论。不能读取的链接不作内容假设。
- **先确认，后成稿**：未获得用户确认，不输出完整最终档案。先给用户可修改的问题清单与框架。

## 阶段一：读取材料并建立事实台账

1. 阅读用户提供的 PRD、文档、数据、截图、Demo 说明、会议纪要、简历与口述补充。
2. 提取并区分：
   - **已确认事实**：有材料或用户明确支持。
   - **待补充**：回答真实性或高频追问需要、但材料不足的信息。
   - **不能推断**：不要基于常识补全的内容。
3. 标记阶段：调研、方案/PRD、评审通过、开发、测试、灰度、上线。严格区分：
   - 已完成/已验证；
   - 正在进行；
   - 待验证/预期。
4. 优先追问最关键的缺口：本人角色与边界、实际动作、项目阶段、关键方案演变、最大挑战、可用数据及口径。不要一次抛出大量泛泛问题。

特别处理：

- 将“我独立主导”拆成独立完成的工作、外部依赖、本人推进动作与项目当前状态，不把协同方的交付算作个人成果。
- 保留用户使用的产品术语。不要把灰度改称 A/B Test，也不要将测试、试点、验证混为一谈；若差异影响结论，追问确认。
- 对 AI/Agent 项目，不凭空补模型、Prompt、训练集或架构；仅记录有证据的实现与验证。

## 阶段二：先提交“梳理方案”，等待确认

在输出最终内容前，先给出一份简洁的可讨论方案，包含：

1. **项目摘要**：项目阶段、我的角色、一句话价值、主要材料与关键缺口。
2. **STAR 轮廓**：分别准备写什么，不展开为最终长答案。
3. **拟定面试问题路径**：主问题 + 可能追问方向；说明每条为什么与该项目有关。
4. **拟定思考与升华维度**：从项目实际选择的分析方向。
5. **待补充问题**：只列影响真实性或深挖质量的关键问题。

等待用户确认、增删、合并、排序或指定深挖方向。用户补充事实后，更新方案；确认后才进入最终输出。

## 阶段三：输出最终项目档案

完整字段与排版见 [输出模板](references/output-template.md)。设计问题与思考维度时读取 [问题与深挖规则](references/question-design.md)。

### 1. 项目摘要与事实边界

先写项目名称、当前阶段、本人角色、一句话价值、已确认事实与待补充事项。只有必要时展示事实台账；它服务于可信度，不应挤占项目内容。

### 2. STAR｜只回答“讲讲这个项目”

- **S｜现状与痛点**：现有状态、谁遇到什么问题、为什么重要。
- **T｜目标与价值**：要为哪些角色创造什么价值，连接什么业务目标。
- **A｜方案与核心功能**：概括 3–5 个核心模块或关键链路，不把个人待办拆成流水账。
- **R｜阶段与效果**：从目标出发写已发生的效果，并明确项目阶段。未上线时写已完成、正在验证和预期，不把计划写成成果。

STAR 负责全貌；不把所有判断、挑战和细节塞入这里。

### 3. 面试问题路径｜动态生成

选择 4–7 条最可能的路径，而非输出固定题库。可选方向包括项目总述、本人角色、MVP/方案收敛、关键功能、AI/Agent 边界、最大挑战/协同、指标/结果、复盘；只有与项目相关才保留。

每条按以下结构输出：

```text
主问题：面试官可能怎样问？
首轮回答：2–4 个要点，让面试官先理解结论。

可能追问：面试官接下来最可能追什么？
回答抓手：用事实、因果、时间线或必要维度组织回答。
```

关键方案、MVP 和功能决策优先保留“方案演变”：初始方案 → 发现的问题 → 最终收敛 → 放弃了什么/保留了什么 → 如何控制风险。

不要默认另设“亮点行动清单”“挑战—应对—结果”“高频追问速答”等重复模块。只有它们能提供不重复的信息，或用户明确需要时才加入；多数情况下应融入相关问题路径。

### 4. 项目思考与升华｜每次都输出，但维度可变

每次必须输出这一部分。根据项目实际选择、增加或合并以下方向：底层价值、决策框架、方案取舍、调研/竞品/数据洞察、可复用方法、北极星与效果衡量、复盘与下一步。

不要为了覆盖目录硬写。必须区分已验证结论、基于材料的判断、待验证假设。

### 5. 待补充/待验证清单

集中列出未被材料支持、但未来可补充或验证的事实、数据、方案细节和结果口径。不要将它们混入正式回答。

## AI/Agent 与协同项目专项检查

对每个 AI/Agent 能力，确认是否说清：服务对象与目标、角色边界、触发条件、可信信息来源、人工兜底、体验/安全护栏、效果衡量。缺少实现证据时不编造技术细节。

对跨部门挑战，优先写真实推进链路：问题是什么 → 为什么难 → 先对齐什么 → 如何明确负责人/边界/接口 → 当前状态与未解依赖。不要只写“积极沟通”。

## 语言与结构规则

- 面向用户复习：短句、分点、结论优先、关键词清晰；不写可直接照念的长篇标准答案。
- 每一点只表达一个核心判断。能一句讲清的，不生硬拆成多个平级点。
- 只有存在真实视角差异时，才使用“客户/业务/生态/技术/协同/数据”等维度名；没有差异则按因果或时间线组织。
- 严格分层：一级点应是不同维度、阶段或判断；二级点才是该维度下的事实、理由、动作或结果。不得把不同层级伪装为平级。
- 用时间线讲推进，用因果链讲决策，用维度讲取舍；选择最适合该题的一种主结构。
- 首轮回答讲结论和主线，追问再展开细节。避免同一事实在 STAR、问题路径和思考部分反复堆砌。
- 说明“怎么做”时必须尽量回答“为什么这样做、替代方案是什么、为什么不选、风险怎么控制、如何判断有效”。
- 避免空泛、复杂和修辞化语言。删除无信息量的“赋能、闭环、抓手”等词，除非它们是必要的原始业务术语。

## 交付前检查

- 每个个人贡献是否有证据且边界准确？
- 每个结果是否与项目阶段一致？每个数字是否有来源和口径？
- 每个“方法论”是否有项目事实支撑，并标明验证程度？
- 问题是否来自真实项目和真实面试追问，而非硬套模板？
- 用户是否已经确认本项目的问题清单与思考框架？未确认则返回阶段二。

## 跨渠道迁移规则

当用户要求将最终内容写入钉钉、飞书或其他文档时，将**对话中经用户确认的最终版**视为唯一内容源。

1. 先锁定来源版本：标题层级、章节顺序、列表嵌套、表格、待补充标记和已确认措辞均属于内容，不得自行重组。
2. 默认逐段迁移。只能为平台兼容性调整视觉样式；不得为了“更像文档”而补充、删减、合并或改变章节顺序。
3. 若确有必要改结构，先给出差异清单：原结构 → 拟调整结构 → 原因；获得用户确认后才写入。
4. 写入后回读，并按来源版本逐项核对：一级/二级标题顺序、每条问题路径、列表嵌套、表格和待补充项。内容存在但位置或层级变化，也视为不一致。
5. 文档有多个版本或来源不明确时，不自行挑选或拼接；先请用户指定唯一版本。