项目面试文档沉淀
目标
把仓库中的分散事实转化为一套自包含、可追溯、能应对连续追问的面试资料。最终资料必须让读者在不访问源码的情况下讲清业务、架构、关键设计、个人贡献和演进思路，同时不得泄露源码或编造生产事实。
开始时先说明正在使用本 Skill。默认在仓库现有文档体系内工作；已有同类目录时原地审查和更新，不另建平行版本。
工作流
1. 确认任务边界
- 读取适用的
AGENTS.md、贡献规范和保密要求。 - 判断任务是首次生成、局部补充还是整体审查。只要求审查时不擅自修改；明确要求生成或优化时直接实施。
- 确认目标岗位、面试阶段、用户最想强化的能力和可用准备时间。上下文已给出时不要重复询问。
- 保留经仓库验证且有助于理解的真实系统名、表名、类名和状态名；删除密钥、内网地址、客户数据和无面试价值的内部标识。
2. 建立事实底稿
先取证，后写叙事。使用 rg、rg --files、构建清单、配置、迁移脚本、业务实现、测试和 Git 历史建立项目事实表。
为结论区分证据等级：
F：源码、配置、DDL、测试或 Git 可直接验证的当前事实；R：由多个事实推导出的解释，写明依据；P：面向追问的演进方案，不得伪装成已上线能力；U：仍待本人确认的经历、生产数据或团队决策。
首次生成、整体重构或仓库复杂时，完整读取 证据与调研规范。
3. 还原项目心智模型
先回答：
- 项目解决什么业务问题，服务哪些角色；
- 系统边界、上下游、部署单元和数据所有权是什么；
- 核心对象、状态、不变量和关键链路是什么；
- 正常、失败、重试、补偿和人工处置怎样运行；
- 哪些代码体现了真正的约束、取舍或复杂度；
- 当前实现的适用边界是什么，规模或需求变化后哪里先失效。
不要把框架或组件名称直接当作亮点。每个候选设计都按“场景 → 约束/风险 → 当前机制 → 取舍 → 失败边界 → 验证 → 演进”分析。
4. 实际调研当前面试与行业关注点
完整生成或大幅更新时必须进行当期调研，不能只依赖模型记忆。局部文字修改、用户明确禁止联网或已有近期且适用的调研证据时可以跳过，并说明原因。
根据目标岗位和代码技术画像动态设计查询。优先覆盖：
- 小红书、牛客等一手面试复盘；
- 用户指定的知乎、力扣、公司或岗位渠道；
- 与候选技术主题对应的官方文档、标准、论文或厂商技术资料；
- 必要时的大厂公开技术文章和高质量工程实践。
搜索词从“目标岗位 + 项目类型 + 代码中出现的机制 + 可能的追问方式”组合产生，不预设 Java、后端或某家公司。记录平台、日期、查询词、样本类型和可迁移追问；严格满足用户指定的平台和最低搜索次数。
面经决定“可能怎样问”，权威资料校准“机制怎样回答”，仓库事实决定“本项目实际怎样做”。外部材料不得反向篡改项目事实。
5. 动态确定高价值主题
不要执行固定技术清单。先从四类信号生成候选主题：
- 代码信号：核心依赖、数据模型、状态变化、异步边界、协议、并发点、性能敏感路径、权限、安全、测试和运维机制；
- 项目信号：最难的业务约束、事故或缺陷风险、关键取舍、规模瓶颈、个人投入最深的部分；
- 面试信号：当前目标岗位反复出现的项目深挖、基础原理、系统设计和反事实问题；
- 用户信号：简历定位、薄弱项、希望展示的技术能力和可投入时间。
按以下维度筛选主题：仓库证据强度、项目核心程度、个人参与度、当前面试价值、可连续追问深度、与其他主题的非重复性。只深入高价值交集，低相关通用知识不为凑内容而写。
候选可能来自数据库与分布式系统，也可能来自 JVM/语言机制、API 与协议、前端状态与性能、Agent/RAG/模型评测、搜索推荐、数据工程、安全权限、云原生、可观测性、测试工程或领域建模。列表仅用于启发，不能作为必查目录。
仓库未使用某项技术时，只有在它与现有架构相邻、调研显示面试中很可能被作为反事实追问，或用户明确要求时才讨论“为什么没用、何时需要”。禁止为了技术含量批量补写未使用组件。
6. 从 Git 提炼个人贡献
使用 git shortlog、git log --all --author、git show --stat、git log --numstat 和必要的 diff 确认提交主题、代码/测试/配置改动及时间线。
把零散提交按可解释的能力闭环聚类，不逐条抄到简历。允许调整叙事层级和顺序，但不能把团队成果、未知上线效果或未参与设计写成个人事实。Git 的证明边界见 证据与调研规范。
7. 设计自适应文档结构
完成主题筛选后再决定文件数量、名称和职责。完整读取 文档蓝图，根据项目复杂度选择合并或拆分：
- 始终提供一个人类阅读入口，说明项目、文档地图、阅读路线和事实边界；
- 通常提供一个
AGENT-*.md，让后续 AI 快速恢复术语、证据、个人贡献和待确认项； - 其余文档围绕本项目实际形成的主题簇命名，不强制采用 01～05，也不预设 Redis、MQ 或数据库专章；
- 一个主题只设一个主文档，其他位置仅保留摘要和链接；
- 没有独立职责的学习计划、面经汇总或技术百科不单独建文档。
代码示例只使用为解释机制重新编写的最小示意代码或脱敏伪代码，不复制完整业务实现。
8. 写简历、项目介绍和追问
简历保留 3～4 个高层亮点，采用“做了什么 + 解决什么问题/风险 + 如何验证”的结构。没有可靠证据时不写百分比、QPS、日单量等数字。
只写该项目的 30～45 秒精简介绍和 2～3 分钟展开介绍，不补自我介绍上下文。详细机制放在基于所选主题生成的连续追问中。重点回答必须落回项目，并包含取舍、边界、替代方案和验证方法。
9. 人工审查和收敛
不依赖通用审计脚本；逐份进行语义审查：
- 能否脱离仓库独立解释项目；
- 主题是否来自真实代码、项目难点、用户目标或当期调研；
- 当前实现、合理推断、未来方案和待确认事实是否分明；
- 个人贡献、简历成稿、项目介绍和追问答案是否一致；
- 是否遗漏项目独有亮点，或塞入与项目无关的热门技术；
- 是否存在重复章节、失效链接、空占位符、源码泄露或敏感信息；
- 每个重点是否有证据、取舍、边界和可执行验证方法。
交付要求
- 说明调研范围、主题选择依据和最终文档职责。
- 明确仍需用户确认的
U类事实。 - 汇报实际执行的事实、链接和结构检查。
- 不自行提交或推送；只有用户明确同意后才执行 Git 操作。