# Extract Project Interview Knowledge

> 从项目源码、测试、CI、发布记录和事故证据中提炼可复核的面试知识文档。当用户要求把一个项目、合并请求、设计决策或故障复盘整理成面试题、回答框架、项目亮点或教学型知识库时使用。

- Skill: `forsakesoul/extract-project-interview-knowledge` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add forsakesoul/extract-project-interview-knowledge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/forsakesoul/extract-project-interview-knowledge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: forsakesoul (https://skillmd.com/u/forsakesoul)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/forsakesoul/extract-project-interview-knowledge

---


# 提炼项目面试知识

把已经实现或真实发生的工程工作整理成可追问、可核对的面试知识。输出是教学与面试叙事，不是现状文档、功能规格或代码审查；默认只修改目标知识库中的文档，不修改源项目实现，不 commit、push 或发布。

## 1. 固定输入

确定源项目、目标知识库、范围（项目/MR/决策/事故）和基线。将分支、Tag 或 MR HEAD 解析为完整 commit SHA，记录源工作区与目标工作区已有修改并保留它们。

分别读取两个仓库的 `AGENTS.md`、文档入口、索引/catalog 规则和验证命令。用户未指定目标结构时，先查找已有项目知识、相邻主题和仓库模板；能补现有主题时不新建重复章节。

完成标准：源事实绑定不可变 SHA，输出位置与仓库原生接入方式明确，现有用户改动已区分。

## 2. 追踪真实工程链路

从用户入口或故障症状沿真实调用链阅读相关源码、测试、类型/schema、CI、部署/发布文档和必要 Git 历史。按业务 seam、关键决策或故障根因聚类，不按目录或语言机械分章，也不预设章节数量。

给每项重要主张标记证据等级：

- `Source`：当前基线源码、类型、schema 或配置直接证明。
- `Test`：自动化测试证明指定 interface；只说明测试实际覆盖的范围。
- `CI`：Pipeline/Job 证明构建或自动化在该 snapshot 运行。
- `Deployment`：Tag、镜像、清单或环境版本证明交付身份。
- `Runtime`：真实环境、浏览器、日志或用户验收证明运行行为。
- `Inference`：证据支持但未直接验证的推断。
- `Unknown`：现有材料无法确定。

Source、Test、CI、Deployment 和 Runtime 不能互相替代。历史记录只用于定位，容易漂移的结论必须回到当前基线核对。

完成标准：每个主题都能指出核心矛盾、真实 interface、关键不变量、错误模式和证据边界。

## 3. 选择值得写的主题

优先保留能产生有效追问的内容：

- 一个真实工程矛盾及其约束；
- 为什么把 seam 放在这里，而不是逐调用点修补；
- 安全、并发、恢复、兼容、性能或发布不变量；
- 失败尝试如何暴露根因，最终方案怎样验证；
- 可迁移到其他项目的判断方法，以及不能泛化的边界。

跳过目录导览、依赖清单、提交流水账、没有证据的项目包装和只会背答案的术语堆砌。敏感实现脱敏后若失去技术价值，则不公开该主题。

## 4. 写项目索引和主题文档

复用目标仓库现有模板和语气。没有模板时，每篇主题至少包含：

```text
面试定位
项目事实与基线
核心矛盾
链路或设计
源码锚点
验证与证据边界
可出题方向
回答框架
边界、权衡与反思
```

源码锚点使用稳定格式 `repo@SHA:path::symbol`；同时写明符号承担什么责任，不只罗列行号。事故主题还应包含触发条件、根因链、错误恢复、回归检查和仍未验证的风险。

回答框架给出思考顺序和证据，不生成夸大影响的标准答案。区分“当前实现”“历史背景”“被拒绝方案”和“未来可能方向”，不得从最终代码编造当时的设计理由。

项目索引按业务链路组织主题并提供一行定位。普通 Markdown 已能被仓库自动发现时，不新增第二套 catalog、路由或生成脚本；只有目标仓库现有规则要求时才更新原生索引。

## 5. 脱敏与所有权

- 删除内部域名、账号、人员、Token、Cookie、Secret、可重放 URL、真实业务数据和个人绝对路径。
- 公开文档中的项目名、角色名或架构细节若本身不公开，改成不损失技术含义的通用名称；无法安全泛化时停止并报告。
- 跨仓主题在拥有该契约的项目保留完整说明，消费方只写自身视角并链接权威来源，避免两份可独立漂移的全文。
- 不读取或复制未授权的私有聊天、原始日志和生产数据；使用脱敏摘要与源码事实。

## 6. 验证

逐项检查：

- 所有 `repo@SHA:path::symbol` 在对应基线可解析，正文与符号责任一致；
- Markdown 相对链接、项目索引和主题文件一一对应；
- 目标仓库原生 catalog/content 测试、lint 或 build 按影响范围通过；
- `git diff --check` 通过，最终变更只包含获准的知识文档与必要原生索引；
- 没有敏感值、内部链接、个人路径或把未执行 Runtime 验收写成已验证。

最终报告源基线、创建/更新主题、实际验证、未执行环境、Inference/Unknown 和已有工作区修改。除非用户明确授权，不提交或发布。