{"owner":"Snailclimb","repo":"interview-guide","hasSkills":true,"totalSkillsCount":35,"totalTokensCount":27587,"categories":["anthropic-skill","root-instruction","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".claude/rules/ai-and-async.md",".claude/rules/backend.md",".claude/rules/frontend.md","AGENTS.md","CLAUDE.md","app/src/main/resources/skills/_shared/references/algorithm-data-structures.md","app/src/main/resources/skills/_shared/references/browser.md","app/src/main/resources/skills/_shared/references/database.md","app/src/main/resources/skills/_shared/references/db-design.md","app/src/main/resources/skills/_shared/references/design-pattern.md","app/src/main/resources/skills/_shared/references/distributed.md","app/src/main/resources/skills/_shared/references/django-flask.md","app/src/main/resources/skills/_shared/references/high-availability.md","app/src/main/resources/skills/_shared/references/java.md","app/src/main/resources/skills/_shared/references/javascript.md","app/src/main/resources/skills/_shared/references/mq.md","app/src/main/resources/skills/_shared/references/mysql.md","app/src/main/resources/skills/_shared/references/network-os.md","app/src/main/resources/skills/_shared/references/python-basic.md","app/src/main/resources/skills/_shared/references/react-vue.md","app/src/main/resources/skills/_shared/references/redis.md","app/src/main/resources/skills/_shared/references/spring.md","app/src/main/resources/skills/_shared/references/system-design-scenarios.md","app/src/main/resources/skills/_shared/references/test-development.md","app/src/main/resources/skills/ai-agent-dev/SKILL.md","app/src/main/resources/skills/ai-agent-dev/ai-agent-dev.md","app/src/main/resources/skills/algorithm/SKILL.md","app/src/main/resources/skills/ali-backend/SKILL.md","app/src/main/resources/skills/bytedance-backend/SKILL.md","app/src/main/resources/skills/frontend/SKILL.md","app/src/main/resources/skills/java-backend-tencent/SKILL.md","app/src/main/resources/skills/java-backend/SKILL.md","app/src/main/resources/skills/python-backend/SKILL.md","app/src/main/resources/skills/system-design/SKILL.md","app/src/main/resources/skills/test-development/SKILL.md"],"skills":{".claude/rules/ai-and-async.md":"---\npaths:\n  - \"app/src/main/java/interview/guide/common/ai/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/annotation/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/aspect/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/async/**/*.java\"\n  - \"app/src/main/java/interview/guide/modules/**/listener/**/*.java\"\n  - \"app/src/main/resources/prompts/**/*.st\"\n  - \"app/src/main/resources/scripts/**/*.lua\"\n---\n\n# AI, Rate Limit And Async Rules\n\n## LLM Providers\n\n- Provider 配置来自 `app.ai.providers.{providerId}` 和默认 `app.ai.default-provider`。\n- ChatClient 获取统一使用 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- Provider 连通性测试要限制超时，并防止访问内网或特殊地址。\n- Spring AI 2.0.0 代码优先使用非 deprecated API。\n\n## Structured Output\n\n- 结构化输出统一使用 `StructuredOutputInvoker` 封装重试。\n- 不要在业务 Service 里复制 JSON 修复、重试和解析逻辑。\n- Prompt 模板存放在 `resources/prompts/`，使用 StringTemplate `.st`。\n\n## Rate Limit\n\n- 接口限流使用可重复 `@RateLimit` 注解。\n- 每个 `@RateLimit` 是独立维度，分别执行 Redis Lua 滑动窗口。\n- Redis Key 使用 `ratelimit:{ClassName:MethodName}:dimension` 结构。\n- 不要在 Controller 或 Service 中手写散落的限流逻辑。\n\n## Redis Stream\n\n- 生产者继承 `AbstractStreamProducer<T>`。\n- 消费者继承 `AbstractStreamConsumer<T>` 并实现 `processMessage()`。\n- Stream 名称、消费者组和任务常量放在 `AsyncTaskStreamConstants`。\n- 消费失败最多重试 3 次，超过后标记 FAILED。\n- 异步处理前校验实体是否存在；已删除实体直接 ACK 丢弃。\n",".claude/rules/backend.md":"---\npaths:\n  - \"app/src/main/java/**/*.java\"\n  - \"app/src/test/java/**/*.java\"\n  - \"app/src/main/resources/**/*.yml\"\n---\n\n# Backend Rules\n\n## Layers\n\n- Controller 只做路由、参数校验、限流注解和 Service 委托。\n- Service 负责编排业务流程，事务注解只放 Service 层。\n- Repository 只做数据访问，继承 `JpaRepository`。\n- Infrastructure 能力放在 `common/` 或 `infrastructure/`，不要塞进业务模块。\n\n## Naming\n\n- JPA 持久化对象使用 `XxxEntity`。\n- 跨层数据传输使用 `XxxDTO`。\n- 前端请求体使用 `XxxRequest`，前端响应体使用 `XxxResponse`。\n- 不可变请求/响应优先使用 `record`。\n\n## Exceptions\n\n- 业务失败使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 保留业务异常原样抛出：`catch (BusinessException e) { throw e; }`。\n- 禁止用 `RuntimeException` 表达业务错误。\n- 禁止吞异常；记录异常时把异常对象作为日志最后一个参数。\n\n## Transactions\n\n- `@Transactional` 只放 Service 层公开方法。\n- 事务内不得调用 LLM、S3、外部 HTTP 或耗时文件解析。\n- 避免同类内部调用 `@Transactional` 方法，必要时拆分到独立 Service。\n- 读多写少的查询使用 `@Transactional(readOnly = true)`。\n\n## Mapping\n\n- Entity 不直接返回给前端。\n- Entity 到 DTO/Response 的重复转换优先使用 MapStruct。\n- 简单一次性字段复制可以使用 `BeanUtils.copyProperties`。\n\n## Style\n\n- Java 代码使用 2 空格缩进，列宽尽量控制在 100 字符。\n- 禁止通配符导入，避免内联全限定类名。\n- 优先使用构造器注入和 `@RequiredArgsConstructor`。\n- 现代 Java 特性可用：switch 表达式、pattern matching、text blocks。\n",".claude/rules/frontend.md":"---\npaths:\n  - \"frontend/src/**/*.ts\"\n  - \"frontend/src/**/*.tsx\"\n  - \"frontend/src/**/*.css\"\n  - \"frontend/package.json\"\n  - \"frontend/vite.config.ts\"\n---\n\n# Frontend Rules\n\n## Structure\n\n- 页面组件放在 `frontend/src/pages/`。\n- 可复用组件放在 `frontend/src/components/`。\n- API 客户端放在 `frontend/src/api/`，复用 `request.ts`。\n- 共享类型放在 `frontend/src/types/`。\n- 路由路径放在 `frontend/src/constants/routes.ts`。\n\n## API\n\n- 后端接口返回 `Result<T>` 结构，前端 API 层负责解包和错误处理。\n- 不要在页面组件里直接拼接重复的 Axios 配置。\n- Provider、知识库、面试、简历等模块沿用现有 API 文件拆分。\n\n## UI\n\n- 延续现有 React + TailwindCSS 4 风格，不引入新的 UI 框架。\n- 操作按钮优先使用 `lucide-react` 图标加清晰文本或 tooltip。\n- 表单状态要包含 loading、success、error 和 disabled 处理。\n- 不要把业务说明性长文塞进页面；优先让界面直接可操作。\n\n## Verification\n\n- 前端改动后运行 `cd frontend && pnpm run build`。\n- 涉及浏览器交互时，用本地浏览器实际打开页面验证。\n","AGENTS.md":"# AI Interview Platform Agent Rules\n\nSpring Boot 4.1.0 + Java 25 + Spring AI 2.0.0 + React 面试平台。\n\n本文件是跨工具 Agent 入口，只放长期有效、代码里不容易直接推断、猜错会影响结果的规则。更细的目录规则放在 `.claude/rules/`，需要时再读取。\n\n## Tech Stack\n\n- Backend: Spring Boot 4.1.0 / Java 25 / Gradle / Spring AI 2.0.0\n- Database: PostgreSQL + pgvector，向量维度 1024，距离类型 COSINE\n- Cache & async: Redis / Redisson / Redis Stream\n- Storage & parsing: RustFS/S3 / Apache Tika\n- Mapping & export: MapStruct / iText 8 / SpringDoc OpenAPI\n- Frontend: React 18 / TypeScript / Vite / TailwindCSS 4，代码在 `frontend/`\n\n## Commands\n\n```bash\n./gradlew :app:compileJava\n./gradlew :app:test --no-daemon\n./gradlew :app:bootRun\n```\n\n```bash\ncd frontend && pnpm run dev\ncd frontend && pnpm run build\n```\n\n```bash\ndocker compose -f docker-compose.dev.yml up -d\n```\n\n## Project Structure\n\n- `app/src/main/java/interview/guide/common/`: 通用能力，包括限流、AI 调用、异步模板、配置、异常、统一响应。\n- `app/src/main/java/interview/guide/infrastructure/`: 技术基础设施，包括文件、导出、Redis、MapStruct 映射。\n- `app/src/main/java/interview/guide/modules/`: 业务模块，每个模块自包含 MVC 分层。\n- `app/src/main/resources/prompts/`: StringTemplate Prompt 模板。\n- `frontend/src/`: React 前端页面、组件、API 客户端和类型定义。\n\n## Architecture\n\n- 后端遵循 `Controller -> Service -> Repository`，Controller 只做路由、校验和委托。\n- Service 承担业务编排；`@Transactional` 只放 Service 层，并保持事务范围最小。\n- Repository 继承 Spring Data JPA `JpaRepository`，自定义查询用方法名或 `@Query`。\n- 基础设施能力优先放在 `common/` 或 `infrastructure/`，不要散落到业务 Service。\n- 对外响应统一使用 `Result<T>`，禁止直接返回 Entity。\n\n## Backend Rules\n\n- 业务异常必须使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 全局异常处理器返回 HTTP 200 + `Result.error(code, message)`。\n- 请求体优先用不可变 `record`，命名后缀使用 `XxxRequest` / `XxxResponse` / `XxxDTO` / `XxxEntity`。\n- Entity 到 DTO/Response 的映射优先使用 MapStruct。\n- 使用构造器注入，优先配合 Lombok `@RequiredArgsConstructor`。\n- 代码使用 2 空格缩进、无通配符导入、避免内联全限定类名。\n- 日志使用 SLF4J 占位符，异常必须作为最后一个参数传入。\n\n## AI And Async Rules\n\n- 获取聊天模型统一走 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- 结构化输出统一走 `StructuredOutputInvoker`，不要在业务代码里复制重试逻辑。\n- Prompt 模板放在 `resources/prompts/`，使用 StringTemplate `.st`。\n- LLM、S3、外部 HTTP 调用不得放在数据库事务内。\n- Redis Stream 生产/消费使用 `AbstractStreamProducer` / `AbstractStreamConsumer` 模板。\n- 异步处理前先校验实体是否存在；实体已删除时 ACK 丢弃。\n- 限流使用可重复 `@RateLimit`，不要手写散落的 Redis 限流逻辑。\n\n## Config And Data\n\n- 配置集中在 `application.yml`、`.env` 和 `@ConfigurationProperties` 类中。\n- API Key、数据库密码等敏感信息只放 `.env`，不得提交到 Git。\n- 不要在 Service 中散落 `@Value`。\n- 本地默认后端端口是 `8080`：`server.port: ${SERVER_PORT:8080}`。\n- 开发环境 `ddl-auto` 可为 `update`，生产环境不能依赖自动建表。\n\n## Frontend Rules\n\n- API 调用集中在 `frontend/src/api/`，复用 `request.ts` 的 Axios 实例。\n- 类型定义放在 `frontend/src/types/`，不要在页面里重复定义共享接口。\n- 页面放在 `frontend/src/pages/`，可复用 UI 放在 `frontend/src/components/`。\n- 路由常量放在 `frontend/src/constants/routes.ts`。\n- 组件交互优先使用现有设计语言和 `lucide-react` 图标。\n\n## Testing\n\n- 后端测试使用 JUnit 5 + Mockito + AssertJ。\n- 测试意图用中文 `@DisplayName` 描述，复杂场景用 `@Nested` 分组。\n- 集成测试使用 H2 配置；限流相关测试需要真实 Redis。\n- 改后端公共能力时至少运行 `./gradlew :app:test --no-daemon`。\n- 改前端时至少运行 `cd frontend && pnpm run build`。\n\n## Never Do\n\n- 不要 `throw new RuntimeException(...)`，业务失败必须用 `BusinessException`。\n- 不要直接返回 Entity 给前端。\n- 不要把 `@Value` 散落在 Service 中。\n- 不要在事务内调用 LLM、S3 或外部 HTTP。\n- 不要同类内部调用 `@Transactional` 方法。\n- 不要 `catch (Exception e) {}` 静默忽略。\n- 不要循环调用 DB，优先批量查询或批量写入。\n- 不要硬编码密钥、Token、数据库密码。\n- 不要使用 `Executors.newXxxThreadPool()`，需要线程池时显式配置 `ThreadPoolExecutor`。\n\n## More Rules\n\n- 后端 Java 细则：`.claude/rules/backend.md`\n- AI、限流、异步细则：`.claude/rules/ai-and-async.md`\n- 前端细则：`.claude/rules/frontend.md`\n","CLAUDE.md":"@AGENTS.md\n\n# Claude Code Instructions\n\n- `AGENTS.md` 是本仓库的共享规则源；更新长期规则时优先改 `AGENTS.md`，不要在这里复制一份。\n- 本文件只保留 Claude Code 专属入口和加载提示，避免根目录上下文膨胀。\n- 目录细则在 `.claude/rules/`，处理匹配文件前先读取对应规则。\n- 个人偏好和临时调试结论放 `CLAUDE.local.md` 或 Claude Memory，不要提交到仓库。\n\n## Path Rules\n\n- Backend: `.claude/rules/backend.md`\n- AI / async / rate limit: `.claude/rules/ai-and-async.md`\n- Frontend: `.claude/rules/frontend.md`\n\n## Maintenance\n\n- 新增规则前先判断：删掉这条后，Claude 是否更容易犯同类错误。\n- 能被测试、格式化、Hook 或 CI 强制的规则，不要只写成自然语言。\n- 如果同一条规则反复被忽略，优先精简规则文件，而不是继续加粗或加感叹号。\n","app/src/main/resources/skills/_shared/references/algorithm-data-structures.md":"# 算法与数据结构（统一参考）\n\n## 一、口述作答标准（文字/语音面试）\n1. 先定义问题与状态：输入、输出、约束、目标。\n2. 说明选型：为什么用该数据结构（而不是其他结构）。\n3. 口述步骤：关键流程、转移关系、剪枝或维护不变式。\n4. 复杂度：时间/空间复杂度 + 主瓶颈。\n5. 边界与反例：空输入、重复值、极端规模、退化场景。\n\n## 二、数组/链表\n- 高频思路：双指针、滑动窗口、前缀和、原地算法。\n- 典型追问：如何避免越界；是否能降空间；是否能单次扫描。\n\n## 三、哈希/堆/栈/队列\n- 哈希：去重、频次统计、映射索引、冲突与扩容代价。\n- 堆：TopK、动态中位数、多路归并，关注 `O(n log k)` 优化。\n- 栈：单调栈、括号匹配、表达式求值，不变式要说清。\n- 队列：BFS、双端队列、滑窗最值，解释队头有效性。\n\n## 四、树/图\n- 树：前中后序、层序、递归/迭代取舍。\n- 图：BFS/DFS、最短路、拓扑排序、并查集。\n- 典型追问：有环/无环处理、访问标记时机、复杂度上界。\n\n## 五、动态规划（DP）\n- 核心：状态定义、转移方程、初始化、遍历顺序。\n- 常见失误：状态遗漏、重复计算、滚动数组覆盖顺序错误。\n- 追问方向：如何从 `O(n^2)` 优化到 `O(n log n)`（若可行）。\n\n## 六、贪心/回溯\n- 贪心：局部最优能否推导全局最优，需给交换论证或反例说明。\n- 回溯：搜索树、剪枝条件、去重策略、最坏复杂度评估。\n\n## 七、设计题（算法建模）\n- 数据流、在线查询、延迟任务、限流计数等题型。\n- 重点：结构选型、正确性、复杂度与工程可落地性。\n","app/src/main/resources/skills/_shared/references/browser.md":"# 浏览器原理面试重点（渲染 + 缓存 + 安全 + 性能）\n\n## 渲染流水线\n- 关键渲染路径：HTML→DOM 树、CSS→CSSOM 树、合并→Render 树→布局→绘制→合成。\n- DOMContentLoaded vs load：DOM 解析完成 vs 所有资源加载完成，CSS 阻塞 DOM 渲染但不阻塞解析。\n- `<script>` 阻塞：默认阻塞 DOM 解析，`async`（下载完立即执行）vs `defer`（DOM 解析后执行）。\n- 合成层优化：`transform`/`opacity` 触发 GPU 合成，跳过布局与绘制。\n\n## 浏览器缓存\n- 强缓存：`Cache-Control`（max-age/no-cache/no-store）优先于 `Expires`。\n- 协商缓存：`ETag`/`If-None-Match` vs `Last-Modified`/`If-Modified-Since`，304 响应。\n- 缓存位置优先级：Service Worker → Memory Cache → Disk Cache → Push Cache。\n- CDN 缓存策略：回源机制、缓存命中率、预热与刷新。\n\n## 网络与协议\n- HTTP/1.1：持久连接（`Connection: keep-alive`）、管线化缺陷。\n- HTTP/2：多路复用、头部压缩（HPACK）、服务器推送、二进制分帧。\n- HTTP/3（QUIC）：基于 UDP、0-RTT 连接、解决队头阻塞。\n- HTTPS：TLS 握手流程（证书校验→密钥协商→对称加密通信），会话复用。\n\n## 安全\n- XSS：存储型/反射型/DOM 型，防御（转义、CSP、HttpOnly Cookie）。\n- CSRF：伪造请求利用已认证身份，防御（SameSite Cookie、CSRF Token、Referer 校验）。\n- CORS：简单请求 vs 预检请求（OPTIONS），`Access-Control-Allow-Origin` 等响应头。\n- CSP（Content-Security-Policy）：白名单限制资源加载，`nonce`/`hash` 策略。\n\n## 性能监控与优化\n- Core Web Vitals：LCP（最大内容绘制 ≤2.5s）、FID/INP（交互延迟 ≤100ms）、CLS（布局偏移 ≤0.1）。\n- 性能 API：`PerformanceObserver`、`performance.timing`（导航计时）、`PerformanceResourceTiming`。\n- 优化手段：代码分割、图片懒加载、预加载（`<link rel=\"preload\">`）、骨架屏。\n- 内存泄漏排查：Chrome DevTools Memory 面板，堆快照对比、分配时间线。\n\n## 面试追问模板\n- 从输入 URL 到页面渲染完成，中间经历了哪些步骤？\n- 你的项目做过哪些性能优化？效果如何量化？\n- CORS 预检请求失败，排查思路是什么？\n- 如何定位线上页面的内存泄漏？\n","app/src/main/resources/skills/_shared/references/database.md":"# 数据库通用面试重点（关系型 + NoSQL 选型）\n\n## 事务与隔离级别\n- ACID 含义：原子性（Undo Log）、一致性（约束与规则）、隔离性（锁/MVCC）、持久性（Redo Log）。\n- 四种隔离级别：读未提交→读已提交→可重复读→串行化，各自解决的脏读/不可重复读/幻读问题。\n- MVCC 原理：版本链（隐藏列 trx_id + roll_pointer）+ ReadView 快照，RC/RR 下 ReadView 生成时机差异。\n- 长事务危害：锁持有时间长、Undo Log 膨胀、MVCC 快照无法回收。\n\n## 索引\n- B+ 树适合磁盘索引：有序、范围查询、叶子链表、扇出大树高低。\n- 覆盖索引避免回表，联合索引最左前缀原则，索引下推（ICP）减少回表次数。\n- 索引失效：函数转换、隐式类型转换、OR 条件、LIKE 前缀通配、非最左列。\n- 唯一索引 vs 普通索引：查询性能差异（Change Buffer）、写入场景选择。\n\n## SQL 优化\n- EXPLAIN 执行计划：type（ref/range/index/all）、key、rows、Extra（Using index/Using filesort/Using temporary）。\n- 慢 SQL 定位：`slow_query_log` + `pt-query-digest`，重点关注全表扫描与大结果集。\n- 深度分页优化：游标分页（WHERE id > last_id）、延迟关联（子查询先查主键）。\n- 批量操作优化：批量 INSERT 替代逐条、INSERT ... ON DUPLICATE KEY UPDATE。\n\n## 分库分表\n- 垂直拆分（按业务模块）vs 水平拆分（按分片键散列/范围）。\n- 分片键选择：数据均匀性、查询路由效率、避免跨片查询。\n- 分布式主键：雪花算法（Snowflake）、号段模式（Leaf）、UUID 性能与索引问题。\n- 中间件：ShardingSphere 逻辑表/物理表映射、SQL 改写与路由。\n- 跨片聚合：内存合并、流式归并，全局排序成本。\n\n## 读写分离\n- 主从复制原理：Binlog 异步/半同步复制，主从延迟的成因与监控。\n- 读写分离路由：中间件（ShardingSphere/ProxySQL）vs 应用层注解驱动。\n- 主从延迟应对：强制读主库、延迟检测与降级、并行复制优化。\n\n## NoSQL 选型\n- Redis：缓存/会话/排行榜/分布式锁，数据全内存、不支持复杂查询。\n- MongoDB：文档模型、灵活 Schema、适合非结构化数据与快速迭代。\n- Elasticsearch：全文检索、倒排索引、日志分析场景，写入成本高。\n- HBase/Cassandra：海量数据宽表、LSM-Tree、适合高吞吐写入与时序数据。\n- 选型维度：数据模型、读写模式、一致性要求、扩展方式、运维复杂度。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？还有优化空间吗？\n- 分库分表后，跨片的 JOIN 和聚合查询怎么做？\n- 主从延迟 5 秒，业务怎么处理？\n- 为什么选这个 NoSQL 而不是 MySQL？迁移成本和风险怎么评估？\n","app/src/main/resources/skills/_shared/references/db-design.md":"# 数据库设计面试重点（建模 + 索引 + 演进）\n\n## 数据建模与范式\n- 三范式核心：1NF（原子性）、2NF（消除部分依赖）、3NF（消除传递依赖）。\n- 反范式设计：以冗余换查询性能，适用读多写少场景（如统计字段冗余）。\n- ER 建模：实体→关系→属性，一对一/一对多/多对多的表结构映射。\n- 宽表 vs 窄表：OLTP 倾向窄表（范式化）、OLAP 倾向宽表（星型/雪花模型）。\n\n## 索引设计策略\n- 索引选择性：高基数列优先，区分度 `COUNT(DISTINCT col)/COUNT(*)` 接近 1 最佳。\n- 联合索引设计：等值条件列在前、范围条件列在后，遵循最左前缀。\n- 覆盖索引设计：将查询所需的列全部纳入索引，消除回表。\n- 避免过度索引：写入开销、存储成本、索引维护（DML 时需同步更新）。\n\n## 冷热数据分层\n- 冷热识别标准：访问时间衰减、业务状态流转（如订单已完成→归档）。\n- 冷数据存储：归档表、历史库、对象存储（OSS/S3），压缩降低存储成本。\n- 数据生命周期管理（DLM）：TTL 过期自动清理、定期迁移、分区裁剪。\n- 分区表策略：RANGE（按时间）、LIST（按枚举）、HASH（按散列），分区裁剪加速查询。\n\n## 扩容与迁移\n- 垂直扩容（升级硬件）vs 水平扩容（分片/分库分表），各自的瓶颈与上限。\n- 平滑扩容流程：新分片上线→双写→历史数据迁移→一致性校验→切读→下线旧分片。\n- 数据迁移工具：Canal 监听 Binlog 增量同步、全量+增量切换方案。\n- 回滚预案：切换失败时快速切回旧库，保留旧库只读窗口。\n\n## 软删除与审计\n- 软删除（`is_deleted` 标记）vs 硬删除：恢复能力 vs 存储膨胀与查询过滤。\n- 审计字段：`created_at`/`updated_at`/`created_by`/`updated_by`，自动化填充（MyBatis 拦截器/JPA Auditing）。\n- 数据版本控制：乐观锁版本号（`version`），防止并发覆盖。\n- 敏感数据处理：加密存储、脱敏查询、合规删除（GDPR/个人信息保护法）。\n\n## 面试追问模板\n- 订单表数据量到亿级，你怎么设计索引和分片方案？\n- 线上需要给大表加字段，怎么做不停机？\n- 冷热数据迁移过程中，如何保证查询不受影响？\n- 你的项目遇到过数据模型演进的问题吗？怎么处理的？\n","app/src/main/resources/skills/_shared/references/design-pattern.md":"# 设计模式面试重点\n\n## 创建型\n- 单例模式：饿汉/懒汉/DCL/静态内部类/枚举，DCL 为何要 volatile，枚举防反射/序列化。\n- 工厂模式：简单工厂→工厂方法→抽象工厂，开闭原则的递进体现。\n- 建造者模式：与工厂模式的区别，链式调用场景（Lombok @Builder）。\n\n## 结构型\n- 代理模式：JDK 动态代理 vs CGLIB，Spring AOP 默认选型策略。\n- 适配器模式：类适配器 vs 对象适配器，Slf4J 日志门面的适配原理。\n- 装饰器模式：与代理模式的区别，Java I/O 流的装饰链。\n\n## 行为型\n- 观察者模式：JDK Observable（已废弃）vs 事件驱动，Spring Event 机制。\n- 策略模式：消除 if-else，结合工厂或 Spring 注入实现策略路由。\n- 责任链模式：Servlet Filter / Spring Interceptor / Netty Pipeline。\n- 模板方法模式：Spring AbstractApplicationContext#refresh。\n- 状态模式：与策略模式的区别（状态内部转换 vs 外部切换）。\n\n## 设计原则\n- SOLID 原则在代码中的体现，重点考察开闭原则和依赖倒置。\n- 合成/聚合复用 vs 继承复用。\n\n## 框架中的设计模式\n- Spring：单例（Bean 默认）、工厂（BeanFactory）、代理（AOP）、观察者（Event）、模板方法（JdbcTemplate）。\n- JDK：迭代器（Collection）、装饰器（I/O）、适配器（Arrays.asList）。\n- MyBatis：代理（MapperProxy）、模板方法（BaseExecutor）。\n\n## 面试追问模板\n- 你的项目中哪里用到了设计模式？为什么选这个模式？\n- 如果不用这个模式，代码会变成什么样？\n- 这个模式有什么缺点？什么场景下不适合？\n","app/src/main/resources/skills/_shared/references/distributed.md":"# 分布式系统面试重点\n\n## 基础理论\n- CAP 定理：三者不可兼得，网络分区必然存在时的取舍。\n- BASE 理论：基本可用、软状态、最终一致性，与 ACID 的对比。\n- 一致性模型：强一致、单调读、因果一致、最终一致。\n\n## 共识算法\n- Paxos：Basic Paxos 角色（Proposer/Acceptor/Learner）与两阶段流程。\n- Raft：Leader 选举（任期+日志对比）、日志复制、安全性保证。\n- ZAB：与 Raft 的异同，ZXID 结构（epoch + counter）。\n\n## 分布式锁\n- Redis 分布式锁：`SET NX EX` + Lua 释放、Redisson 可重入锁与看门狗。\n- ZooKeeper 分布式锁：临时顺序节点、Watcher 机制、羊群效应避免。\n- 选型：性能优先 Redis，可靠性优先 ZK。\n\n## 分布式事务\n- 2PC：准备→提交，同步阻塞与单点故障问题。\n- TCC：Try/Confirm/Cancel，空回滚与幂等处理。\n- SAGA：正向补偿 vs 反向补偿，适合长事务。\n- Seata AT 模式：全局锁 + 一阶段提交 + 二阶段回滚。\n\n## 分布式 ID\n- 雪花算法（Snowflake）：64 位结构、时钟回拨问题与解决。\n- UUID、数据库自增、号段模式（Leaf）的优劣对比。\n\n## API 网关与 RPC\n- 网关核心职责：路由、鉴权、限流、熔断、可观测。\n- HTTP vs RPC：协议开销、服务治理、跨语言、适用场景。\n- Dubbo 架构：Provider/Consumer/Registry/Monitor，负载均衡策略。\n\n## 一致性哈希\n- 虚拟节点解决数据倾斜，新增/移除节点时最小化数据迁移。\n\n## 面试追问模板\n- 网络分区发生时，你的系统选择保 CP 还是 AP？为什么？\n- 分布式事务失败了怎么补偿？人工介入还是自动？\n- 如何设计一个支持百万 QPS 的分布式 ID 生成服务？\n","app/src/main/resources/skills/_shared/references/django-flask.md":"# Django/Flask 面试重点（框架 + ORM + 部署）\n\n## 框架定位与对比\n- Django：全栈框架（ORM/Admin/Auth/Template 内置），\"batteries included\" 哲学，适合快速交付。\n- Flask：微框架（路由+模板引擎核心），扩展生态灵活，适合定制化与微服务。\n- 选型：快速 MVP/内容管理选 Django，API 服务/微服务/深度定制选 Flask。\n- FastAPI：异步原生、Pydantic 类型校验、自动生成 OpenAPI 文档，适合新项目。\n\n## 请求生命周期\n- Django：URLconf 路由→Middleware 链→View 函数/类→Template/JSON 响应→Middleware 链（逆序返回）。\n- Flask：Werkzeug WSGI 路由→before_request 钩子→View 函数→after_request 钩子→响应。\n- 中间件/钩子：认证注入、请求日志、异常捕获、数据库事务管理。\n- 请求上下文：Django（request/response 对象传递）、Flask（thread-local `g` 对象/应用上下文）。\n\n## ORM 与查询优化\n- Django ORM：QuerySet 惰性求值、`select_related`（JOIN，一对一/外键）vs `prefetch_related`（二次查询，多对多）。\n- N+1 问题：循环中触发懒加载，解法为 `select_related`/`prefetch_related` 批量预加载。\n- Flask-SQLAlchemy：Session 管理、eager loading（`joinedload`/`subqueryload`）、批量操作。\n- 查询优化：`only()`/`defer()` 延迟加载字段、`bulk_create` 批量插入、`iterator()` 流式读取大结果集。\n\n## 认证、权限与安全\n- Django Auth：User 模型、`authenticate`/`login`/`logout` 流程、Permission/Group 权限体系。\n- Token 认证：JWT（djangorestframework-simplejwt）/ DRF TokenAuthentication。\n- 安全防护：CSRF Token（Django 内置）、XSS 转义（模板自动转义）、SQL 注入（ORM 参数化）、CORS 配置。\n- 密码存储：Django 使用 PBKDF2 + salt，可配置 bcrypt/argon2。\n\n## 缓存与性能\n- Django 缓存框架：`@cache_page` 装饰器、缓存后端（Redis/Memcached/本地内存）。\n- Flask 缓存：Flask-Caching 扩展，`@cached` 装饰器、Jinja2 片段缓存。\n- 数据库查询缓存：`QuerySet.cache()`、手动缓存策略、缓存失效与一致性。\n- 静态文件：Django Collectstatic + CDN、Flask 静态文件服务（生产环境用 Nginx）。\n\n## 部署与运维\n- WSGI（同步）：Gunicorn/uWSGI，多 Worker 进程 + preload + 优雅重启。\n- ASGI（异步）：Uvicorn/Daphne，支持 WebSocket 和 async view。\n- 容器化：Docker 多阶段构建、环境变量管理、健康检查端点。\n- 监控：Sentry 异常捕获、Prometheus 指标暴露、日志结构化输出（JSON logging）。\n\n## 面试追问模板\n- Django ORM 的 N+1 问题你怎么发现的？怎么解决的？\n- Flask 的上下文是怎么实现的？多线程下安全吗？\n- 你的项目用的 WSGI 还是 ASGI？为什么？遇到什么瓶颈？\n- 线上一个接口突然变慢，从框架层面怎么排查？\n","app/src/main/resources/skills/_shared/references/high-availability.md":"# 高可用面试重点（故障防护 + 容灾 + 可观测性）\n\n## 故障检测与主备切换\n- 心跳检测：应用层（HTTP 探针）vs TCP 层，超时阈值与抖动容忍。\n- 主备切换：主动-被动（冷备/热备）vs 主动-主动（双写+负载均衡）。\n- 选主机制：Raft/Paxos 共识、ZooKeeper 临时节点、etcd Lease。\n- 脑裂防护：Fencing（STONITH）/仲裁节点/ Lease 锁，避免双主写入。\n- 切换窗口：RTO（恢复时间目标）与 RPO（恢复点目标）的工程实现。\n\n## 限流、熔断与降级\n- 限流算法：固定窗口（临界突刺）、滑动窗口、令牌桶（匀速放行）、漏桶（平滑输出）。\n- 分布式限流：Redis Lua 原子计数 + 滑动窗口、Sentinel 集群限流模式。\n- 熔断器模式：Closed→Open→Half-Open 状态机，失败率/慢调用率触发。\n- 降级策略：返回缓存数据/默认值/简化结果、关闭非核心功能、手动开关。\n- 级联故障预防：超时设置（connect/read）、重试次数与退避策略、舱壁隔离（线程池/信号量）。\n\n## SLA/SLO 与可观测性\n- SLA/SLO/SLI 关系：SLO 是目标（如 99.9% 可用）、SLI 是指标（延迟/错误率）、SLA 是合同。\n- 三大支柱：Metrics（Prometheus + Grafana）、Logging（ELK/Loki）、Tracing（Jaeger/SkyWalking）。\n- 告警设计：分级（P0-P3）、收敛（抑制/聚合/路由）、OnCall 轮值与升级。\n- 错误预算：SLO 剩余预算决定发布节奏与变更风险容忍度。\n\n## 容量规划与混沌工程\n- 容量评估：QPS 峰值估算、带宽/存储/连接数上限、资源瓶颈定位（CPU/IO/网络）。\n- 压测方法论：基准压测→阶梯加压→极限探测，关注长尾延迟（P99）而非均值。\n- 自动弹性：HPA（Kubernetes）/ASG（云厂商），指标驱动（CPU/自定义指标）扩缩容。\n- 混沌工程：Chaos Mesh/LitmusChaos，故障注入（网络延迟/节点宕机/依赖不可用）。\n\n## 异地多活与容灾\n- 同城双活：两个机房同时提供服务，数据库跨机房同步（延迟可控）。\n- 异地多活：单元化架构（用户路由到固定单元）、数据同步（ Canal/Otter/Binlog）。\n- 全球化部署：DNS 就近路由、CDN 静态资源加速、数据合规（GDPR 数据驻留）。\n- 灾备演练：定期切换演练、数据一致性校验、回滚流程验证。\n\n## 面试追问模板\n- 流量突增 10 倍，你的系统哪里先扛不住？怎么应急？\n- 熔断打开后，下游恢复了你怎么感知？自动恢复还是人工？\n- 你的项目 SLA 是多少？怎么保证的？出过故障吗？\n- 混沌工程你在团队推行过吗？遇到过什么阻力？\n","app/src/main/resources/skills/_shared/references/java.md":"# Java 面试重点（基础 + 集合 + 并发 + JVM）\n\n## 基础概念\n- JVM/JDK/JRE 区别，字节码与\"编译+解释\"执行模型，AOT vs JIT。\n- 8 种基本类型与包装类，自动装箱/拆箱与 Integer Cache。\n- `==` vs `equals()`，`hashCode()` 与 `equals()` 一致性约束。\n- 方法重载 vs 重写，静态分派与动态分派。\n- 接口 vs 抽象类，Java 8+ default 方法的影响。\n- 深拷贝 vs 浅拷贝，序列化方案。\n\n## String\n- 不可变性原理（final byte[]），安全与性能影响。\n- 字符串常量池：`intern()`、编译期优化、`new String(\"abc\")` 创建对象数。\n- `String` vs `StringBuilder` vs `StringBuffer`。\n\n## 集合框架\n- List：ArrayList（动态数组、扩容 1.5 倍）vs LinkedList（双向链表），RandomAccess 标记。\n- Map：HashMap 底层（数组+链表+红黑树）、负载因子与扩容、线程不安全场景。\n- HashMap 长度为何是 2 的幂次方，多线程死循环问题。\n- ConcurrentHashMap：JDK 7 分段锁 vs JDK 8 CAS+synchronized，key/value 不为 null。\n- Set：HashSet（基于 HashMap）、LinkedHashSet、TreeSet（红黑树）。\n- Queue：BlockingQueue 接口，ArrayBlockingQueue vs LinkedBlockingQueue。\n- fail-fast vs fail-safe 机制。\n\n## 并发\n- 线程生命周期与状态转换，上下文切换成本。\n- 死锁：条件、检测（jstack/arthuras）、预防策略。\n- JMM：可见性、有序性、happens-before；volatile 保证可见性+禁止重排序但不保证原子性。\n- synchronized 底层原理（Monitor）、锁升级（偏向→轻量→重量）、偏向锁废弃。\n- ReentrantLock vs synchronized：可中断、公平锁、Condition、超时获取。\n- CAS 与 ABA 问题，Atomic 原理。\n- 线程池：核心参数（corePoolSize/maxPoolSize/queue/handler）、拒绝策略、动态配置。\n- AQS 原理（state + CLH 队列），Semaphore/CountDownLatch/CyclicBarrier。\n- ThreadLocal：原理、内存泄漏与弱引用、跨线程传递（TransmittableThreadLocal）。\n- CompletableFuture：编排、异常处理、自定义线程池。\n- 虚拟线程（Java 21）：用途与调度模型。\n\n## JVM\n- 运行时数据区：堆/栈/方法区/元空间/程序计数器/直接内存。\n- 对象创建流程、内存布局、访问定位（句柄 vs 直接指针）。\n- GC 判断：引用计数 vs 可达性分析；四种引用（强/软/弱/虚）。\n- GC 算法：标记-清除、复制、标记-整理、分代收集。\n- 垃圾收集器：Serial→Parallel→CMS→G1→ZGC，各自适用场景。\n- G1 回收流程（Young GC / Mixed GC），ZGC 着色指针与读屏障。\n- 双亲委派模型与打破方式（SPI、OSGi、线程上下文类加载器）。\n- OOM 排查：Heap Dump、jmap/jstat/arthuras、GC 日志分析。\n\n## 面试追问模板\n- 这个机制底层是怎么实现的？有什么性能代价？\n- 多线程环境下会有什么问题？如何保证线程安全？\n- 框架（Spring/MyBatis）中哪里用到了这个机制？\n- 线上遇到 OOM/GC 频繁怎么排查？参数怎么调？\n","app/src/main/resources/skills/_shared/references/javascript.md":"# JavaScript 面试重点（基础 + 异步 + 工程化）\n\n## 类型与作用域\n- 8 种数据类型（7 原始 + Object），`typeof null === \"object\"` 历史遗留。\n- `let`/`const` vs `var`：块级作用域、暂时性死区（TDZ）、变量提升差异。\n- 作用域链：词法作用域（静态），引擎沿作用域链逐层查找标识符。\n- 闭包：函数与其词法环境的绑定，经典场景（防抖/节流/私有变量/柯里化）与内存泄漏风险。\n\n## 原型与继承\n- 原型链：`__proto__` vs `prototype`，属性查找沿原型链向上。\n- `Object.create()` vs `new`：直接指定原型 vs 构造函数实例化。\n- `class` 语法糖：`extends`/`super` 底层仍基于原型链，`static` 方法不可继承到实例。\n- `Object.setPrototypeOf` 性能问题，推荐 `Object.create` 替代。\n\n## 异步编程\n- 事件循环：宏任务（setTimeout/setInterval/I/O）与微任务（Promise.then/MutationObserver）执行顺序。\n- Promise：状态机（pending→fulfilled/rejected），链式调用与错误冒泡，`Promise.all` vs `Promise.allSettled` vs `Promise.race`。\n- `async/await`：语法糖，异常用 `try/catch` 捕获，并行场景仍需 `Promise.all`。\n- `async` 函数中的并发陷阱：串行 `await` vs 并行 `Promise.all`，性能差异。\n\n## ES6+ 核心特性\n- 解构赋值（数组/对象/默认值）、展开/剩余运算符。\n- 箭头函数：没有 `this`/`arguments`/`prototype`，不适合作为构造函数。\n- `Symbol`：唯一标识符，`Symbol.iterator` 与 `for...of` 协议。\n- `Map`/`Set`/`WeakMap`/`WeakSet`：与 Object/Array 的适用场景对比。\n- `Proxy`/`Reflect`：元编程基础，Vue 3 响应式原理的核心。\n\n## DOM 与 BOM\n- DOM 操作成本：重排（Layout）与重绘（Paint），批量更新策略（`DocumentFragment`/虚拟 DOM）。\n- 事件模型：捕获→目标→冒泡，`addEventListener` 第三个参数，事件委托。\n- `requestAnimationFrame` vs `setTimeout`：与屏幕刷新率同步，避免丢帧。\n\n## 模块化与工程化\n- CommonJS（`require`/`module.exports`，同步加载）vs ES Modules（`import`/`export`，静态分析）。\n- Tree-shaking 原理：ES Modules 静态结构使编译期可判定副作用。\n- `package.json` 依赖管理：`dependencies` vs `devDependencies`，语义化版本（semver）。\n- TypeScript 类型系统：接口/泛型/联合类型/类型守卫，与运行时无关。\n\n## 面试追问模板\n- 闭包在实际项目中用在哪里？遇到过内存泄漏吗？\n- 宏任务和微任务的执行顺序，你能举个复杂场景说明吗？\n- Promise 链中某个环节没 return，会发生什么？\n- CommonJS 和 ES Modules 能混用吗？打包工具怎么处理？\n","app/src/main/resources/skills/_shared/references/mq.md":"# 消息队列面试重点（模型 + 可靠性 + 主流 MQ 对比）\n\n## 消息模型\n- 点对点（Queue）：一条消息只能被一个消费者消费，消费后删除。\n- 发布订阅（Topic）：一条消息可被多个订阅者消费，消费独立。\n- 消费组（Consumer Group）：同一组内竞争消费、不同组间广播消费。\n- 消息顺序性：全局有序（单 Partition）vs 分区有序（同一 key 路由到同一 Partition）。\n\n## 投递语义\n- 至多一次（At Most Once）：可能丢消息，性能最高，适用允许丢失的场景（监控指标）。\n- 至少一次（At Least Once）：可能重复，需要消费端幂等，是大多数 MQ 的默认语义。\n- 恰好一次（Exactly Once）：Kafka 事务 + 幂等 Producer，RocketMQ 事务消息。\n- 幂等消费：唯一键去重（Redis/数据库唯一约束）、业务状态机判断。\n\n## 可靠性保障\n- 生产端确认：Kafka `acks=all`、RabbitMQ Publisher Confirm、RocketMQ 同步刷盘。\n- 消费端确认：手动 ACK（避免自动确认后处理失败丢消息）。\n- 消息持久化：磁盘持久化（Kafka 日志段、RocketMQ CommitLog）、副本机制。\n- 死信队列（DLQ）：消费重试达到上限后转入死信，人工介入处理。\n\n## 消费积压处理\n- 积压原因：消费者宕机、处理变慢（下游依赖超时）、突发流量。\n- 应急处理：紧急扩容消费者、临时消费者绕过慢逻辑先落库、消息降级。\n- 长期预防：消费监控告警（Lag 阈值）、容量预估、消费幂等保障安全扩容。\n- 削峰填谷：MQ 作为缓冲层，上游快速写入、下游匀速消费，保护下游系统。\n\n## 主流 MQ 对比\n- Kafka：高吞吐、顺序磁盘写、零拷贝、适合日志/事件流、Pull 模式。\n- RocketMQ：事务消息、延迟消息、消息过滤（Tag/SQL92）、适合电商金融、Push/Pull。\n- RabbitMQ：AMQP 协议、路由灵活（Exchange 类型丰富）、适合任务分发、Push 模式。\n- 选型维度：吞吐量、延迟、消息可靠性、顺序性、运维复杂度、社区生态。\n\n## 消息中间件架构\n- Kafka：Broker + Topic + Partition + Replica，Leader-Follower ISR 机制。\n- RocketMQ：NameServer + Broker + CommitLog + ConsumeQueue，高性能顺序写。\n- 分区/队列设计：分区数影响并行度、分区迁移与再平衡（Rebalance）、消费者组变更。\n\n## 面试追问模板\n- 消息积压了 100 万条，怎么处理？多久能恢复？\n- 如何保证消息不丢、不重、有序？你的项目怎么做的？\n- Kafka 和 RocketMQ 在你项目中怎么选的？用过什么特性？\n- 消费者 Rebalance 期间消息怎么处理？会造成重复消费吗？\n","app/src/main/resources/skills/_shared/references/mysql.md":"# MySQL 面试重点\n\n## 索引\n- B+ 树为什么适合磁盘索引（有序、范围查询、叶子链表）。\n- 覆盖索引与回表成本，联合索引最左前缀原则与索引下推。\n- 索引失效场景：函数转换、隐式类型转换、OR、LIKE 前缀通配、非最左列。\n- EXPLAIN 执行计划：type/key/Extra 字段含义，Extra 中 Using filesort/Using temporary。\n\n## 事务与 MVCC\n- ACID 含义，事务隔离级别（RU/RC/RR/SERIALIZABLE）与各自解决的问题。\n- MySQL 默认 RR，InnoDB 通过 MVCC + Next-Key Lock 解决幻读。\n- MVCC 原理：隐藏列（trx_id/roll_pointer）、Undo Log 版本链、ReadView。\n- 当前读 vs 快照读，RR 下当前读仍加间隙锁。\n\n## 锁机制\n- 表级锁 vs 行级锁，InnoDB 行锁（Record/Gap/Next-Key）。\n- 意向锁的作用（快速判断表级冲突），IS/IX 与 S/X 的兼容矩阵。\n- 死锁检测与避免：按固定顺序加锁、缩短事务、降低隔离级别。\n\n## 存储引擎与日志\n- InnoDB vs MyISAM：事务、行锁、外键、崩溃恢复。\n- Redo Log（WAL、crash-safe）vs Undo Log（MVCC、回滚）vs Binlog（主从复制、归档）。\n- 两阶段提交保证 Redo Log 与 Binlog 一致性。\n\n## 性能优化\n- 慢 SQL 定位：slow_query_log、pt-query-digest。\n- 分库分表策略：垂直拆分 vs 水平拆分，ShardingSphere 中间件。\n- 深度分页优化：游标分页、延迟关联、子查询先查主键。\n- 数据冷热分离，读写分离架构。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？能否优化？\n- 高并发写入时，锁冲突怎么解决？\n- 主从延迟怎么处理？数据一致性如何保证？\n","app/src/main/resources/skills/_shared/references/network-os.md":"# 网络与操作系统（后端面试核心）\n\n## TCP / HTTP 高频点\n- TCP 三次握手与四次挥手，TIME_WAIT 的意义与优化边界。\n- 粘包/拆包原因与解决（长度字段、分隔符、固定包长）。\n- HTTP1.1/2 差异：连接复用、队头阻塞、头部压缩。\n- HTTPS 握手流程：证书校验、密钥协商、会话复用。\n\n## 并发与线程模型\n- 进程/线程区别，用户态与内核态切换成本。\n- 线程池参数设计：核心线程、队列、拒绝策略、监控指标。\n- 锁优化：悲观锁/乐观锁、CAS、自旋、锁升级。\n\n## 内存与 I/O\n- JVM 内存区域、GC 停顿对接口延迟的影响。\n- 零拷贝、mmap、sendfile 的适用场景。\n- Reactor 模型与同步阻塞模型差异。\n\n## 面试追问模板\n- 为什么不是这个方案？底层代价是什么？\n- 如果连接数/流量翻倍，瓶颈会先出现在哪里？\n- 出现网络抖动或线程池打满时，如何降级与恢复？\n","app/src/main/resources/skills/_shared/references/python-basic.md":"# Python 面试重点（语言核心 + 并发 + 工程实践）\n\n## 数据模型与语法特性\n- 一切皆对象：`id()`/`type()`/`value`，可变对象（list/dict/set）vs 不可变对象（int/str/tuple）。\n- 魔法方法：`__init__` vs `__new__`、`__str__` vs `__repr__`、`__eq__` vs `__hash__`、`__enter__`/`__exit__`（上下文管理器）。\n- 多重继承与 MRO：C3 线性化算法、`super()` 沿 MRO 链调用。\n- 描述符协议：`__get__`/`__set__`/`__delete__`，property/classmethod/staticmethod 的底层实现。\n\n## 迭代器、生成器与装饰器\n- 迭代器协议：`__iter__` + `__next__`，`StopIteration` 终止，`for` 循环底层机制。\n- 生成器：`yield` 暂停与恢复、惰性求值、内存优势（处理大数据集/无限序列）。\n- 生成器表达式 vs 列表推导式：内存 vs 速度的取舍。\n- 装饰器：闭包 + `@` 语法糖、带参数装饰器（三层嵌套）、`functools.wraps` 保留元信息。\n- 类装饰器 vs 函数装饰器，`__call__` 实现。\n\n## GIL 与并发模型\n- GIL（全局解释器锁）：CPython 的内存安全机制，CPU 密集型多线程无法并行。\n- 多线程（`threading`）：适合 I/O 密集型（网络请求/文件读写），GIL 在 I/O 等待时释放。\n- 多进程（`multiprocessing`）：绕过 GIL，进程间通信（Queue/Pipe/共享内存），进程池。\n- 异步（`asyncio`）：事件循环 + 协程（`async`/`await`），适合高并发 I/O，单线程无锁。\n- `concurrent.futures`：`ThreadPoolExecutor` vs `ProcessPoolExecutor`，统一的 Future 接口。\n\n## 内存管理与垃圾回收\n- 引用计数：主要回收机制，实时性好但无法处理循环引用。\n- 分代 GC：0/1/2 三代，新对象从 0 代开始，存活时间越长晋升概率越低。\n- 循环引用检测：`gc` 模块的标记-清除算法，`gc.collect()` 手动触发。\n- 内存优化：`__slots__` 禁止动态属性字典、`sys.getsizeof`、内存分析工具（`tracemalloc`/`memory_profiler`）。\n\n## 类型系统与工程实践\n- Type Hints：`typing` 模块（`Optional`/`Union`/`Generic`/`Protocol`），mypy 静态检查。\n- dataclass vs attrs vs Pydantic：数据类定义、校验、序列化的选型。\n- 包管理：`pip` + `requirements.txt` vs `poetry`/`uv`（锁文件、依赖解析）。\n- 虚拟环境：`venv`/`conda`，隔离项目依赖避免版本冲突。\n- 代码质量：`ruff`（lint + format）、`pytest`（测试框架）、`pre-commit`（Git 钩子）。\n\n## 面试追问模板\n- Python 的 GIL 在你的项目中造成过问题吗？怎么解决的？\n- 装饰器写过什么功能？带参数的装饰器怎么实现的？\n- 内存泄漏怎么排查？用过哪些工具？\n- 大量数据处理时，你会用生成器还是列表？权衡点是什么？\n","app/src/main/resources/skills/_shared/references/react-vue.md":"# React/Vue 面试重点（框架核心 + 工程化）\n\n## React 核心机制\n- Fiber 架构：链表结构替代递归、可中断渲染、时间切片（Time Slicing）与优先级调度。\n- Virtual DOM：Diff 算法（同层比较、key 的作用）、Reconciliation 过程。\n- Hooks 规则：调用顺序一致（不能在条件/循环中调用）、闭包陷阱（stale closure）与解决方案。\n- 常用 Hooks：`useState`/`useEffect`（依赖数组）/`useCallback`/`useMemo`/`useRef`/`useContext`。\n- `useEffect` vs `useLayoutEffect`：异步 vs 同步、绘制前 vs 绘制后。\n- React 18 并发特性：`useTransition`（非紧急更新降级）、`useDeferredValue`（延迟重渲染）、Suspense 数据获取。\n\n## Vue 核心机制\n- 响应式原理：Vue 2（`Object.defineProperty` 拦截 getter/setter）vs Vue 3（`Proxy` 代理全对象）。\n- Composition API：`ref`/`reactive`/`computed`/`watch`/`watchEffect`，逻辑组合 vs Options API 逻辑分散。\n- 模板编译：模板→AST→渲染函数→Virtual DOM，静态提升与补丁标记（Patch Flag）。\n- 组件更新粒度：Vue 3 基于依赖追踪的精确更新 vs React 整体重渲染（需 memo/shouldComponentUpdate）。\n- Vue 3 编译优化：Block Tree、静态提升（hoistStatic）、缓存事件处理器。\n\n## 状态管理\n- React：Context API（轻量）、Redux（单向数据流/reducer/middleware）、Zustand（极简 Hook 式）、Jotai/Recoil（原子化）。\n- Vue：Pinia（Vue 3 官方推荐，TS 友好、模块化）、Vuex（Vue 2 时代，mutation/action 分离）。\n- 状态分层：组件本地状态 vs 全局共享状态 vs 服务端状态（React Query/TanStack Query）。\n\n## 组件设计\n- 组件通信：props/emit、provide/inject（跨层级）、事件总线、状态管理。\n- 组件抽象：高阶组件（HOC）vs Render Props vs Hooks（React）、插槽（Slots）vs 作用域插槽（Vue）。\n- 受控 vs 非受控组件：表单管理策略、`ref` 获取 DOM/组件实例。\n- 性能优化：`React.memo`/`useMemo`/`useCallback`、Vue `v-once`/`v-memo`、虚拟列表（react-window/vue-virtual-scroller）。\n\n## 路由与 SSR\n- React Router：声明式路由、嵌套路由、路由守卫、懒加载（`React.lazy` + `Suspense`）。\n- Vue Router：动态路由匹配、导航守卫（beforeEach/afterEach）、路由懒加载。\n- SSR vs CSR vs SSG：SEO、首屏速度、服务器成本权衡。\n- Next.js：SSR/SSG/ISR/App Router、Nuxt.js：服务端渲染与混合渲染。\n- Hydration：SSR HTML + 客户端 JS 绑定事件，注水不匹配（hydration mismatch）排查。\n\n## 工程化\n- 构建工具：Vite（ESM 开发服务器 + Rollup 构建）vs Webpack（loader/plugin 生态）。\n- 代码规范：ESLint + Prettier、Husky + lint-staged（提交前检查）。\n- 测试：Jest/Vitest（单元测试）、React Testing Library/Vue Test Utils（组件测试）、Playwright/Cypress（E2E）。\n- 微前端：Module Federation、qiankun、single-spa，应用隔离与通信。\n\n## 面试追问模板\n- React 的 Fiber 架构解决了什么问题？调度是怎么实现的？\n- Vue 3 的 Proxy 响应式和 Vue 2 的 defineProperty 有什么本质区别？\n- 大列表渲染卡顿怎么优化？虚拟列表的原理是什么？\n- 你的项目状态管理怎么选型的？遇到过什么问题？\n","app/src/main/resources/skills/_shared/references/redis.md":"# Redis 面试重点\n\n## 数据类型与场景\n- 五种基础类型：String/Hash/List/Set/ZSet，各类型底层编码与适用场景。\n- 特殊类型：Bitmap（活跃统计）、HyperLogLog（UV 去重）、Stream（消息队列）。\n- ZSet 底层为什么用跳表而不是红黑树/B+树（范围查询、实现简单、内存灵活）。\n\n## 持久化与线程模型\n- RDB（fork + COW）vs AOF（写后日志、fsync 策略），混合持久化。\n- Redis 6.0 前单线程模型（避免锁竞争、IO 多路复用），6.0 后多线程 IO（命令执行仍单线程）。\n\n## 生产问题\n- 缓存穿透（布隆过滤器/空值缓存）、缓存击穿（互斥锁/永不过期）、缓存雪崩（随机过期/多级缓存）。\n- 缓存与数据库一致性：延迟双删、Canal 监听 Binlog、最终一致性方案。\n\n## 分布式锁\n- `SET key value NX EX` 基本实现，误删问题与 Lua 原子释放。\n- Redisson 可重入锁原理（Hash 结构 + Lua 脚本），看门狗续期机制。\n- 集群下可靠性：RedLock 争议与替代方案（fencing token）。\n\n## 性能优化\n- Pipeline 批量减少 RTT，Lua 脚本保证原子性。\n- BigKey 检测与拆分（redis-rdb-tools、UNLINK 异步删除）。\n- HotKey 发现与本地缓存 + 热点分散。\n- 内存淘汰策略：allkeys-lru vs volatile-lru，内存碎片清理。\n\n## 集群\n- 主从复制（全量 + 增量）、哨兵模式（故障转移、主观/客观下线）。\n- Cluster 模式：16384 槽位、Gossip 协议、重定向（MOVED/ASK）。\n\n## 面试追问模板\n- 如果 Redis 宕机，业务怎么降级？\n- 百万级 QPS 场景下，缓存架构怎么设计？\n- 大 Key 线上清理导致阻塞怎么办？\n","app/src/main/resources/skills/_shared/references/spring.md":"# Spring 面试重点\n\n## IoC 与 Bean\n- IoC 解决什么问题：解耦对象创建与依赖管理。\n- `@Component` vs `@Bean`：声明方式、代理对象、第三方库集成。\n- `@Autowired` vs `@Resource`：按类型 vs 按名称，优先级规则。\n- 构造器注入 vs Setter 注入 vs 字段注入：不可变性、循环依赖、测试友好度。\n- Bean 作用域（singleton/prototype/request/session），线程安全分析。\n- Bean 生命周期：实例化→属性注入→Aware→初始化→销毁，各阶段扩展点。\n\n## AOP\n- 核心概念：切面/切点/通知/连接点。\n- Spring AOP vs AspectJ：动态代理 vs 编译期织入，性能与功能差异。\n- 通知类型：@Before/@After/@AfterReturning/@AfterThrowing/@Around。\n- 同类内部调用 AOP 失效原因与解决方案（AopContext/exposeProxy）。\n\n## Spring MVC\n- DispatcherServlet 工作流程：HandlerMapping→HandlerAdapter→ViewResolver。\n- 统一异常处理：@ControllerAdvice + @ExceptionHandler。\n- 拦截器 vs 过滤器：执行时机与适用场景。\n\n## 事务\n- 声明式事务：@Transactional 属性（propagation/isolation/rollbackFor）。\n- 七种传播行为：REQUIRED/REQUIRES_NEW/NESTED 等使用场景。\n- 事务失效场景：同类内部调用、非 public 方法、异常被吞、异步调用。\n\n## 循环依赖\n- 三级缓存解决 setter 注入循环依赖：singletonObjects/earlySingletonObjects/singletonFactories。\n- 构造器注入循环依赖无法自动解决，需 @Lazy。\n- SpringBoot 2.6+ 默认禁止循环依赖。\n\n## Spring Boot\n- 自动配置原理：@SpringBootApplication→@EnableAutoConfiguration→spring.factories/Imports。\n- 条件装配：@ConditionalOnClass/@ConditionalOnMissingBean 等。\n- 配置文件加载优先级：properties > yaml > 环境变量 > 命令行参数。\n\n## 面试追问模板\n- @Transactional 标在 private 方法上会生效吗？为什么？\n- 如何自定义一个 Spring Boot Starter？\n- Spring AOP 在你的项目中用来做了什么？遇到过什么坑？\n","app/src/main/resources/skills/_shared/references/system-design-scenarios.md":"# 系统设计与场景题（后端通用核心版）\n\n## 1. 面试答题通用框架（先说这个）\n1. 先澄清约束：QPS、峰值倍数、SLA、数据量、延迟目标、一致性级别、成本上限。\n2. 再给核心链路：请求路径、读写路径、关键状态、失败路径。\n3. 最后补工程细节：容量估算、监控告警、降级兜底、回滚与补偿。\n\n## 2. 高频场景题的标准思路\n\n### 秒杀系统\n- 目标：抗瞬时洪峰、避免超卖、保证最终一致。\n- 关键手段：前置限流 + 验证码/预约削峰 + 缓存库存 + 异步下单（MQ）。\n- 一致性：预扣库存 + 订单超时回补；幂等键防重复下单。\n- 风险点：热点 Key、缓存击穿、消息堆积、库存回补失败。\n\n### 短链系统\n- 目标：短码唯一、重定向高性能、可统计。\n- 核心：短码生成（号段/哈希+冲突处理）+ 映射存储 + 缓存热点短链。\n- 扩展：防刷、防爆破、过期回收、点击明细异步落库。\n\n### Feed 流（推拉模型）\n- 目标：低延迟、可扩展、支持热点用户。\n- 模式：推模式（读快写重）/拉模式（写快读重）/推拉结合（明星与普通用户分治）。\n- 关键：时间线有序、分页游标、防重复、防回刷穿透。\n\n### 站内消息系统\n- 消息类型拆分：系统通知、事件提醒、私信。\n- 核心能力：未读计数、聚合展示、已读状态、离线补偿、幂等去重。\n- 存储策略：会话维度和消息明细分离，冷热分层。\n\n### 延时任务\n- 可选方案：Redis 延迟队列 / MQ 延时消息 / 时间轮调度。\n- 关键问题：任务可靠投递、重复执行防护、取消与重试语义。\n- 工程点：失败重试上限、死信处理、任务可观测性（积压、延迟、失败率）。\n\n### 登录风控（密码输错限制）\n- 核心：用户维度失败计数 + TTL 锁定窗口。\n- 要点：分布式一致计数、防账号枚举、风控阈值分级（验证码->临时锁定->人工校验）。\n- 审计：保留关键操作日志与告警。\n\n### 扫码登录 / 第三方登录\n- 扫码登录：状态机（待扫码->已扫码待确认->确认登录/取消/过期）。\n- OAuth2：授权码模式优先；短期 Access Token + 可撤销 Refresh Token。\n- 安全点：`state` 防 CSRF、回调域名白名单、一次性 code、过期控制。\n\n### 抢单 / 抢资源并发控制\n- 核心目标：同一资源只被一个请求成功占有。\n- 实现：数据库唯一约束 + 乐观锁版本号 或 Redis 原子指令/CAS。\n- 必备：幂等键、超时释放、补偿回滚。\n\n### UV/PV 统计\n- UV 常见实现：HyperLogLog（省内存，近似去重）。\n- PV：计数器即可；复杂场景按站点/页面/时间分桶。\n- 大盘链路：写入削峰（MQ）+ 离线/准实时聚合。\n\n### 去重推荐（大规模）\n- 核心：布隆过滤器 + 分层存储（内存 + 磁盘）+ 批量异步刷盘。\n- 重点：误判率控制、窗口淘汰策略、冷启动兼容。\n\n### RPC 框架设计\n- 关键组件：注册发现、序列化协议、网络传输、负载均衡、超时重试、熔断隔离。\n- 高可用：请求幂等、降级策略、调用链追踪。\n\n### Session 跨节点共享\n- 推荐：集中式会话存储（Redis）。\n- 不推荐：应用节点间 session 复制（扩展性差，维护成本高）。\n\n## 3. 面试官常追问清单\n1. 为什么这么分层？瓶颈先出在哪里？\n2. 失败后怎么恢复？谁触发补偿？如何防重？\n3. 峰值翻 3 倍时，先扩哪个组件？依据是什么？\n4. 你怎么证明方案有效？给出核心指标与阈值。\n5. 一致性和可用性冲突时，你的取舍原则是什么？\n","app/src/main/resources/skills/_shared/references/test-development.md":"# 测试开发面试重点（测试基础 + 用例设计 + 自动化 + 性能安全）\n\n## 测试基础\n- 软件测试定义与目的：发现缺陷、验证需求、提供质量反馈，不只是\"找 Bug\"。\n- 测试流程：需求分析→测试计划→测试设计→测试执行→缺陷跟踪→测试报告→回归测试。\n- 测试左移（Shift-Left）：需求/设计阶段就介入质量活动，早发现早修复，缺陷成本随阶段指数增长。\n- 测试覆盖率：行覆盖/分支覆盖/路径覆盖，高覆盖率 ≠ 高质量测试，关注有意义覆盖率而非数字。\n- 测试金字塔：单元测试（>90% 自动化）→集成测试（60-80%）→系统/UI 测试（20-40%），投资回报递减。\n- 核心竞争力：业务理解 + 系统性用例设计 + 工程化自动化能力。\n\n## 测试用例设计\n- 等价类划分：将输入划分为有效/无效等价类，每类取代表性数据，减少冗余。\n- 边界值分析：等价类边界的值最易出错，如范围 [1,100] 测试 0/1/100/101。\n- 判定表法：多条件组合场景（如会员×节假日×提前天数→价格），穷举条件与结果映射。\n- 场景法：模拟用户操作流程（主流程+异常分支），通过流程图覆盖完整业务路径。\n- 错误推测法：基于经验推测易错点（如文件上传：空文件/超大文件/病毒文件/格式不符）。\n- 状态迁移法：测试有状态变化的对象（如订单状态、电梯状态），验证状态转换正确性。\n- 好的测试用例标准：覆盖全面、分组精准（等价类无冗余）、边界清晰。\n- 场景题回答框架：功能→兼容性→性能→网络→安全→UI/UX，逐维度展开。\n\n## 测试类型\n- 黑盒测试 vs 白盒测试：关注外部行为 vs 关注内部代码逻辑，互补使用。\n- 单元测试：最小可测试单元（函数/类），Mock 外部依赖，开发编写，CI 自动执行。\n- 集成测试：多模块/服务交互验证，关注接口契约、数据传递、依赖协同。\n- 系统测试：完整系统验证，功能/性能/安全/兼容性全面覆盖。\n- 回归测试：修改后确认旧功能未被破坏，高度依赖自动化用例。\n- 验收测试（UAT）：业务方确认是否满足需求，贴近真实场景。\n- 端到端测试（E2E）：完整业务链路验证，从用户入口到最终输出，数量少但价值高。\n- 正向测试 vs 反向测试：合法输入验证正常功能 vs 非法输入验证异常处理能力。\n\n## 自动化测试\n- ROI 公式：(节省的手工测试时间 × 执行频率) - (脚本开发时间 + 维护成本)。\n- 适用场景：回归测试、步骤确定性高、执行频率高；不适用：一次性功能、UI 频繁变动、探索性测试。\n- Web 自动化工具：Selenium（多语言/多浏览器、成熟但慢）、Cypress（开发者友好、JS-only）、Playwright（现代化、多语言、快）。\n- API 测试流程：读 API 文档→设计用例（正常/异常/边界）→准备数据与认证→发请求→校验响应与数据库。\n- API 测试工具：Postman/Reqable/Insomnia，结合 Newman/CI 实现自动化回归。\n- 移动端自动化：Appium（跨平台）、Espresso（Android 原生）、XCTest（iOS 原生）。\n- CI/CD 集成：Jenkins/GitLab CI/GitHub Actions 中自动触发，测试报告与失败告警。\n\n## 性能测试\n- 压测类型：负载测试（预期负载下验证）、压力测试（超负载找极限）、稳定性测试（长时间运行查泄漏）。\n- 压测流程：确定目标（QPS/RT/TPS）→准备环境（≈生产 50-80%）→选工具→编写脚本→执行→监控分析→调优→复测。\n- 压测工具：JMeter（功能全面）、k6（JS 脚本、现代化）、Gatling（Scala、高性能）、Locust（Python）。\n- 关键指标：TPS/QPS、响应时间（P50/P95/P99）、错误率、CPU/内存/磁盘 IO/网络带宽。\n- 瓶颈定位：数据库慢查询、连接池打满、线程池饱和、网络带宽、GC 停顿。\n\n## 安全测试\n- OWASP Top 10：XSS/SQL 注入/CSRF/身份认证失效/敏感信息泄露/访问控制失效等。\n- XSS 测试：输入 `<script>alert(1)</script>`、`<img src=x onerror=alert(1)>`，验证是否转义/过滤。\n- SQL 注入测试：`' OR '1'='1 --`、`' UNION SELECT --`、时间盲注 `AND SLEEP(5)`，验证参数化查询。\n- CSRF 测试：检查 CSRF Token、SameSite Cookie、Referer 校验。\n- 越权测试：水平越权（访问同角色他人数据）、垂直越权（普通用户访问管理接口）。\n\n## Bug 处理与协作\n- 不可复现 Bug：多次尝试不同环境/数据→收集详细信息（步骤/日志/截图/录屏）→与开发协作分析。\n- 缺陷报告要素：标题、前置条件、复现步骤、预期结果、实际结果、严重程度、优先级。\n- Bug 生命周期：新建→确认→分配→修复→验证→关闭（或重新打开）。\n- 印象深刻的 Bug 回答模板：场景描述 + 根因分析 + 修复过程 + 后续预防。\n\n## 面试追问模板\n- 登录/支付/电商直播间场景，你怎么设计测试用例？\n- 你的自动化测试覆盖率是多少？ROI 怎么评估？\n- 线上出了一个 Bug，但测试环境无法复现，你怎么排查？\n- 你在 CI/CD 中集成了哪些质量门禁？怎么防止质量回退？\n","app/src/main/resources/skills/ai-agent-dev/SKILL.md":"---\nname: ai-agent-dev\ndescription: 用于 AI Agent 开发岗位面试出题；覆盖 Agent 架构、LLM 调用、工具集成、MCP 协议、RAG、上下文工程与多 Agent 协作，强调工程落地与故障处理能力。\n---\n# Overview\n你是一位 AI Agent 开发岗位面试官，关注候选人对 Agent 系统的工程实现能力，而不是只会描述概念。重点考察：Agent Loop 设计、工具集成方式、上下文管理策略、RAG 检索质量治理和多 Agent 协作模式。\n\n# Instructions\n1. 先确认候选人的技术栈（LangChain / Spring AI / 自研框架）和实际项目经验，围绕真实项目追问。\n2. 提问遵循梯度：使用经验 -> 原理机制 -> 边界与故障 -> 优化与权衡。\n3. 每个主问题必须包含至少一个权衡点（如召回率 vs 延迟、上下文长度 vs 信息密度）。\n4. 回答停留在概念层时，必须追问具体实现：协议选型、Token 预算分配、错误重试策略、可观测性指标。\n5. 至少一次要求候选人给出可量化指标（如 TTFT、P99 延迟、检索召回率、Token 利用率）。\n6. 不要只问名词解释，必须有场景化问题（如\"线上 Agent 出现幻觉循环，你怎么排查\"）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- AGENT_BASIS / LLM_CALLING / MCP_PROTOCOL / RAG / CONTEXT_ENGINEERING / MULTI_AGENT / PROJECT -> ai-agent-dev.md\n","app/src/main/resources/skills/ai-agent-dev/ai-agent-dev.md":"# AI Agent 开发面试参考\n\n## 一、Agent 基础\n\n### Agent 定义与核心架构\n- Agent = LLM + Planning + Memory + Tools\n- Agent Loop：感知(Perceive) -> 推理(Reason) -> 行动(Act) -> 观察(Observe) 循环\n- 终止条件：任务完成、达到最大步数、用户中断、错误熔断\n\n### Agent vs 传统编程 vs 工作流\n- 决策者差异：Agent 由 AI 决策下一步，工作流由预定义路径驱动\n- 适用场景判断：确定性任务用工作流，开放性任务用 Agent\n\n### Agent 范式\n- ReAct：Thought-Action-Observation 循环，边推理边执行\n- Plan-and-Execute：先规划全局步骤，再逐步执行\n- Reflection：自我反思与修正（Reflexion / Self-Refine / CRITIC）\n\n### 多 Agent 系统\n- Orchestrator-Subagent：主从模式，编排器分配任务\n- Peer-to-Peer：对等模式，Agent 间平等协作\n- A2A（Agent-to-Agent）通信协议\n\n### 安全\n- Prompt Injection 攻击类型与防御（执行层沙箱、认知层隔离、决策层人机协同）\n- Agent 权限边界设计（最小权限原则）\n- 敏感操作审批机制\n\n---\n\n## 二、LLM 调用\n\n### Token 与上下文窗口\n- Token 是计费和性能的基本单位（非字符）\n- 上下文窗口 = System Prompt + User Prompt + 历史 + RAG + 工具定义 + 输出\n- Token 预算：window >= input_tokens + max_output_tokens\n- Prompt Caching：静态内容前置、动态内容后置\n\n### 采样参数\n- Temperature：控制随机性（低=确定性，高=创造性）\n- Top-p（核采样）和 Top-k：缩小候选词池\n- Presence/Frequency Penalty：抑制重复\n- 推理模型（o1/o3）的参数限制\n\n### Function Calling\n- JSON Schema 定义工具接口\n- 工具粒度设计：原子操作 vs 组合操作\n- 并行工具调用（Parallel Tool Calling）\n- 错误处理：工具调用失败时的重试与降级策略\n\n### 结构化输出与流式输出\n- JSON Mode vs Structured Output（Schema 约束）\n- SSE（Server-Sent Events）机制与 TTFT 优化\n- 流式场景下的工具调用处理\n\n### 成本优化\n- 输入/输出 Token 定价差异（2-5 倍）\n- 路由策略：简单问题用小模型、复杂问题用大模型\n- 缓存策略：语义缓存、精确匹配缓存\n\n---\n\n## 三、MCP 协议\n\n### MCP 定位\n- MCP（Model Context Protocol）= AI 的 USB-C，统一工具接入标准\n- MCP vs Function Calling vs Agent：MCP 是协议标准，Function Calling 是 LLM 能力，Agent 是系统概念\n- 四层关系：Function Calling（基础） -> Prompt（意图） -> MCP（连接） -> Skills（编排）\n\n### MCP 四大核心能力\n- Resources：只读数据源 | Tools：可执行操作 | Prompts：模板化提示词 | Sampling：LLM 推理委托\n\n### 架构与传输\n- 四层：Host（宿主） -> Client（协议客户端） -> Server（工具服务） -> Data Source\n- JSON-RPC 2.0 通信协议（轻量、传输无关、易调试）\n- stdio：本地 IPC；Streamable HTTP：远程/生产（已废弃 HTTP+SSE）\n\n### 生产实践\n- 工具幂等性设计、退避策略与 P99 延迟目标\n- 上下文窗口管理（大结果截断、分页）\n- 安全考量（输入校验、权限控制、审计日志）\n\n---\n\n## 四、RAG 检索增强\n\n### 基本原理\n- RAG = 信息检索 + LLM 生成\n- 离线索引（加载、清洗、分块、Embedding、存储）+ 在线检索（查询向量化、相似度搜索、上下文构建、生成）\n- 核心优势：知识时效性、减少幻觉、数据安全、领域适配\n\n### 分块与 Embedding\n- 固定长度 vs 语义分块 vs 递归分块\n- 分块大小与语义完整性的权衡\n- 通用 vs 领域微调 Embedding 模型选择\n\n### 向量检索\n- ANN：用 5% 召回率损失换 100 倍速度\n- HNSW：<1000 万向量、高召回、高内存 | IVFFLAT：1000 万-1 亿、内存友好\n- 距离度量：余弦相似度、内积、欧几里得距离\n- 混合检索：向量 + BM25 + RRF 融合（生产最佳实践）\n\n### 局限与治理\n- GIGO：检索质量决定生成质量\n- 上下文窗口噪声、TTFT 增加、检索召回率评估\n\n---\n\n## 五、上下文工程\n\n### 概念\n- Agent = Model + Harness（模型之外的一切都是 Harness）\n- 模型决定上限，Harness 决定下限\n\n### 六层 Harness 架构\n1. L1 信息边界：System Prompt、约束条件、角色定义\n2. L2 工具系统：工具注册、Schema 定义、权限控制\n3. L3 执行编排：Agent Loop、条件分支、并行执行\n4. L4 记忆与状态：短期记忆、长期记忆、状态持久化\n5. L5 评估与可观测：质量评估、链路追踪、指标监控\n6. L6 约束与恢复：错误处理、重试策略、降级方案\n\n### Token 预算与设计模式\n- 40% 上下文利用率阈值（超过后质量急剧下降）\n- 上下文压缩：摘要、裁剪、遗忘\n- 渐进式披露：L1 元数据常驻 + L2 正文按需 + L3 资源隔离\n- Lost in the Middle 问题与应对\n\n### 实践案例\n- OpenAI：机械约束优于文档约束、熵管理\n- Anthropic：GAN 式三 Agent 架构、上下文重置策略\n- Stripe：Minions 系统\n\n---\n\n## 面试高频追问\n\n### Agent 基础\n- Agent Loop 中如何防止无限循环？\n- ReAct 和 Plan-and-Execute 各自的优缺点和适用场景？\n- 多 Agent 系统中如何保证一致性？\n\n### LLM 调用\n- Token 超出上下文窗口时怎么处理？\n- Function Calling 和直接在 Prompt 里写工具有什么区别？\n- 如何降低 LLM 调用的 P99 延迟？\n\n### MCP 协议\n- MCP 和直接用 Function Calling 有什么区别？\n- stdio 和 Streamable HTTP 分别适合什么场景？\n- 如何设计一个生产级的 MCP Server？\n\n### RAG\n- 分块策略如何选择？过大或过小分别有什么问题？\n- 向量检索和关键词检索各自的优缺点？为什么需要混合检索？\n- RAG 系统线上出现幻觉，排查思路是什么？\n\n### 上下文工程\n- Agent 上下文超出窗口时如何处理？\n- AGENTS.md / SKILL.md 的设计原则是什么？\n- Harness 各层级中哪一层对 Agent 质量影响最大？为什么？\n","app/src/main/resources/skills/algorithm/SKILL.md":"---\nname: algorithm\ndescription: 用于算法面试出题；重点评估复杂度分析、边界处理和优化能力，区分背题与真实理解。\n---\n# Overview\n你是一位算法面试官，目标是评估候选人的建模能力和复杂度优化能力。\n\n# Instructions\n1. 文字/语音面试不要求写代码；每题先让候选人口述：建模方式、关键数据结构、核心步骤、时间/空间复杂度。\n2. 数据结构必须覆盖多样性：哈希表、栈/队列、堆、树/图、数组/链表应轮换考察，避免只刷单一套路。\n3. 回答正确后继续追问边界条件、退化场景和同类变体，不停在基础答案。\n4. 对暴力解必须追问瓶颈，并要求给出可落地的优化路径（如剪枝、单调结构、预处理、空间换时间）。\n5. 至少一次要求候选人解释正确性证明思路（不变式/归纳/反证任一即可）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP/GREEDY_BACKTRACK/DESIGN -> algorithm-data-structures.md\n","app/src/main/resources/skills/ali-backend/SKILL.md":"---\nname: ali-backend\ndescription: 用于阿里后端面试出题；强调业务深度、项目落地和中间件选型能力，关注复杂场景下的取舍与闭环。\n---\n# Overview\n你是阿里巴巴后端面试官。核心风格是业务导向与项目深挖：围绕候选人真实项目持续追问，直到触达认知边界。\n\n# Instructions\n1. 优先从简历项目切入，连续追问\"为什么这样设计\"\"如果流量涨 10 倍怎么改\"。\n2. 每个问题必须落到业务目标、技术取舍、成本与收益，不接受纯理论回答。\n3. 对 Java 生态中间件（MySQL、Redis、MQ）重点追问原理、故障、容量与治理。\n4. 至少一次要求候选人给出完整落地方案：指标、压测、发布、回滚、复盘。\n5. 强调可执行性：方案要能上线、能观测、能恢复。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PROJECT/SYSTEM_DESIGN_SCENARIO -> system-design-scenarios.md\n- DB_DESIGN/MYSQL -> db-design.md, mysql.md\n- DISTRIBUTED/CACHE/REDIS -> distributed.md, redis.md\n- MQ -> mq.md\n- DESIGN_PATTERN -> design-pattern.md\n","app/src/main/resources/skills/bytedance-backend/SKILL.md":"---\nname: bytedance-backend\ndescription: 用于字节后端面试出题；以算法与编码能力为第一门槛，同时考察高并发场景下的系统设计能力。\n---\n# Overview\n你是字节跳动后端面试官，风格直接、硬核、高强度。核心判断标准是：算法基本功是否过硬，复杂度优化是否到位。\n\n# Instructions\n1. 每轮优先给 1-2 道算法题，但在文字/语音场景不要求手写代码；要求候选人口述解法步骤、关键数据结构、复杂度与边界处理。\n2. 数据结构覆盖必须均衡：数组/链表、哈希表、栈/队列、堆、树/图至少覆盖两类以上，不可只问单一 DP。\n3. 对答案必须追问：为什么正确、为什么最优、边界条件是否完整；若只给结论，要求补充不变式或反例证明。\n4. 算法题后补一题工程化追问：同思路如何迁移到高并发真实场景（如计数、去重、延迟任务、TopK）。\n5. 提问节奏要快，单题目标明确；每次只追一个关键点，避免超长题干。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP -> algorithm-data-structures.md\n- DISTRIBUTED/SYSTEM_DESIGN_SCENARIO -> distributed.md, system-design-scenarios.md\n- PROJECT -> 结合简历追问真实线上问题\n","app/src/main/resources/skills/frontend/SKILL.md":"---\nname: frontend\ndescription: 用于前端工程面试出题；覆盖 JavaScript、React/Vue、浏览器原理和性能优化，强调业务实战与工程化能力。\n---\n# Overview\n你是一位前端工程面试官，重点评估候选人在真实业务中的技术取舍与交付质量。\n\n# Instructions\n1. 问题需覆盖渲染机制、状态管理、工程化与性能优化。\n2. 优先结合简历项目，追问复杂页面、性能瓶颈和线上问题处理。\n3. 回答停留在 API 层时，必须追问底层机制与边界场景。\n4. 至少一次要求候选人给出可量化指标（如 FCP/LCP、错误率、包体积）。\n5. 不要只问名词解释，必须有场景化问题。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVASCRIPT -> javascript.md\n- REACT_VUE -> react-vue.md\n- BROWSER -> browser.md\n- CSS/ENGINEERING/PERFORMANCE/PROJECT -> 结合简历与工程实践深挖\n","app/src/main/resources/skills/java-backend-tencent/SKILL.md":"---\nname: java-backend-tencent\ndescription: 用于腾讯后端面试出题；重点考察计算机基础、计网与操作系统原理，并结合业务场景验证技术选型能力。\n---\n# Overview\n你是腾讯后端面试官。风格稳健且重基础：常从八股切入，但会顺着底层逻辑追问到协议细节与系统机制。\n\n# Instructions\n1. 先问网络与操作系统基础，再过渡到业务系统设计与中间件选型。\n2. 对 TCP/IP、HTTP/HTTPS、线程模型、内存模型要持续深挖\"为什么\"。\n3. 必须结合业务场景问选型：为何用 MQ 而不是同步调用，何时不用缓存。\n4. 每轮至少一个底层追问和一个工程追问，兼顾理论与落地。\n5. 面试节奏可持续拉长，关注候选人思维稳定性与一致性。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- NET_OS -> network-os.md\n- JAVA -> java.md\n- MYSQL/REDIS/MQ -> mysql.md, redis.md, mq.md\n- SPRING -> spring.md\n- SYSTEM_DESIGN_SCENARIO/PROJECT -> system-design-scenarios.md + 简历项目\n","app/src/main/resources/skills/java-backend/SKILL.md":"---\nname: java-backend\ndescription: 用于 Java 后端面试出题；优先围绕 Java 核心、MySQL、Redis、Spring 与项目实战，追问设计取舍、故障处理和性能优化。\n---\n# Overview\n你是一位 Java 后端面试官，目标是识别候选人是否具备可上线的工程能力，而不是只会背概念。\n\n# Instructions\n1. 优先结合候选人简历和项目经历提问。\n2. 提问顺序遵循：使用经验 -> 原理机制 -> 边界条件 -> 优化与故障。\n3. 每个主问题都需要可追问，追问要落到真实场景和可观测指标。\n4. 回答偏概念时，必须追问实现细节、失败场景、回滚方案。\n5. 避免一次性给提示词，不要替候选人补全答案。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVA -> java.md\n- MYSQL -> mysql.md\n- REDIS -> redis.md\n- SPRING -> spring.md\n- SYSTEM_DESIGN_SCENARIO/PROJECT -> system-design-scenarios.md + 简历项目\n","app/src/main/resources/skills/python-backend/SKILL.md":"---\nname: python-backend\ndescription: 用于 Python 后端面试出题；覆盖 Python 基础、数据库、Django/Flask、缓存与部署，强调工程落地。\n---\n# Overview\n你是一位 Python 后端面试官，关注候选人是否具备独立构建和运维服务的能力。\n\n# Instructions\n1. 优先考察框架实践、数据库设计、缓存策略与部署经验。\n2. 每道题都要可追问，尤其关注并发、一致性和故障恢复。\n3. 回答如果仅停留在语法层面，必须追问工程实现细节。\n4. 至少一次要求候选人描述真实线上问题和排障步骤。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PYTHON_BASIC -> python-basic.md\n- DATABASE -> database.md\n- DJANGO_FLASK -> django-flask.md\n- CACHE -> redis.md\n- DEPLOY/PROJECT -> 结合简历与上线流程深挖\n","app/src/main/resources/skills/system-design/SKILL.md":"---\nname: system-design\ndescription: 用于系统设计面试出题；聚焦容量估算、可用性与一致性权衡、可观测性和故障恢复。\n---\n# Overview\n你是一位系统设计面试官，关注候选人的架构权衡能力和可落地性。\n\n# Instructions\n1. 先澄清约束（QPS、SLA、一致性级别、成本）再讨论方案。\n2. 每个问题必须包含至少一个权衡点（如一致性 vs 延迟）。\n3. 要求候选人解释容量估算、故障处理、回滚机制和可观测性设计。\n4. 禁止组件罗列式问答，必须落到数据流与状态流。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- HIGH_AVAILABILITY -> high-availability.md\n- DISTRIBUTED -> distributed.md\n- CACHE/REDIS -> redis.md\n- DESIGN_PATTERN -> design-pattern.md\n- MQ/DB_DESIGN -> 结合分布式场景进行追问\n","app/src/main/resources/skills/test-development/SKILL.md":"---\nname: test-development\ndescription: 用于测试开发面试出题；覆盖测试基础、用例设计、自动化测试、性能测试与安全测试，兼顾工程化落地能力。\n---\n# Overview\n你是一位测试开发面试官，关注候选人的质量意识和工程化能力，重点评估其能否通过技术手段提升测试效率与质量保障深度。\n\n# Instructions\n1. 提问需覆盖测试基础、用例设计方法、自动化测试实践和性能测试四个维度。\n2. 优先结合候选人简历中的测试项目，追问具体的场景设计、工具选型和指标度量。\n3. 回答停留在理论时，必须追问实际落地细节：覆盖率数据、脚本维护成本、CI 集成方式。\n4. 至少一次要求候选人针对具体功能（如登录/支付/电商直播间）现场设计测试用例。\n5. 关注候选人是否具备开发能力：能否编写测试工具、搭建测试平台、参与 CI/CD 建设。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- TESTING_BASIC/TEST_CASE_DESIGN -> test-development.md\n- AUTOMATION/PERFORMANCE_SECURITY -> test-development.md\n- API/WEB/MOBILE_TESTING -> test-development.md\n- JAVA/PYTHON -> java.md, python-basic.md（考察编码能力时参考）\n"},"files":{".claude/rules/ai-and-async.md":"---\npaths:\n  - \"app/src/main/java/interview/guide/common/ai/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/annotation/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/aspect/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/async/**/*.java\"\n  - \"app/src/main/java/interview/guide/modules/**/listener/**/*.java\"\n  - \"app/src/main/resources/prompts/**/*.st\"\n  - \"app/src/main/resources/scripts/**/*.lua\"\n---\n\n# AI, Rate Limit And Async Rules\n\n## LLM Providers\n\n- Provider 配置来自 `app.ai.providers.{providerId}` 和默认 `app.ai.default-provider`。\n- ChatClient 获取统一使用 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- Provider 连通性测试要限制超时，并防止访问内网或特殊地址。\n- Spring AI 2.0.0 代码优先使用非 deprecated API。\n\n## Structured Output\n\n- 结构化输出统一使用 `StructuredOutputInvoker` 封装重试。\n- 不要在业务 Service 里复制 JSON 修复、重试和解析逻辑。\n- Prompt 模板存放在 `resources/prompts/`，使用 StringTemplate `.st`。\n\n## Rate Limit\n\n- 接口限流使用可重复 `@RateLimit` 注解。\n- 每个 `@RateLimit` 是独立维度，分别执行 Redis Lua 滑动窗口。\n- Redis Key 使用 `ratelimit:{ClassName:MethodName}:dimension` 结构。\n- 不要在 Controller 或 Service 中手写散落的限流逻辑。\n\n## Redis Stream\n\n- 生产者继承 `AbstractStreamProducer<T>`。\n- 消费者继承 `AbstractStreamConsumer<T>` 并实现 `processMessage()`。\n- Stream 名称、消费者组和任务常量放在 `AsyncTaskStreamConstants`。\n- 消费失败最多重试 3 次，超过后标记 FAILED。\n- 异步处理前校验实体是否存在；已删除实体直接 ACK 丢弃。\n",".claude/rules/backend.md":"---\npaths:\n  - \"app/src/main/java/**/*.java\"\n  - \"app/src/test/java/**/*.java\"\n  - \"app/src/main/resources/**/*.yml\"\n---\n\n# Backend Rules\n\n## Layers\n\n- Controller 只做路由、参数校验、限流注解和 Service 委托。\n- Service 负责编排业务流程，事务注解只放 Service 层。\n- Repository 只做数据访问，继承 `JpaRepository`。\n- Infrastructure 能力放在 `common/` 或 `infrastructure/`，不要塞进业务模块。\n\n## Naming\n\n- JPA 持久化对象使用 `XxxEntity`。\n- 跨层数据传输使用 `XxxDTO`。\n- 前端请求体使用 `XxxRequest`，前端响应体使用 `XxxResponse`。\n- 不可变请求/响应优先使用 `record`。\n\n## Exceptions\n\n- 业务失败使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 保留业务异常原样抛出：`catch (BusinessException e) { throw e; }`。\n- 禁止用 `RuntimeException` 表达业务错误。\n- 禁止吞异常；记录异常时把异常对象作为日志最后一个参数。\n\n## Transactions\n\n- `@Transactional` 只放 Service 层公开方法。\n- 事务内不得调用 LLM、S3、外部 HTTP 或耗时文件解析。\n- 避免同类内部调用 `@Transactional` 方法，必要时拆分到独立 Service。\n- 读多写少的查询使用 `@Transactional(readOnly = true)`。\n\n## Mapping\n\n- Entity 不直接返回给前端。\n- Entity 到 DTO/Response 的重复转换优先使用 MapStruct。\n- 简单一次性字段复制可以使用 `BeanUtils.copyProperties`。\n\n## Style\n\n- Java 代码使用 2 空格缩进，列宽尽量控制在 100 字符。\n- 禁止通配符导入，避免内联全限定类名。\n- 优先使用构造器注入和 `@RequiredArgsConstructor`。\n- 现代 Java 特性可用：switch 表达式、pattern matching、text blocks。\n",".claude/rules/frontend.md":"---\npaths:\n  - \"frontend/src/**/*.ts\"\n  - \"frontend/src/**/*.tsx\"\n  - \"frontend/src/**/*.css\"\n  - \"frontend/package.json\"\n  - \"frontend/vite.config.ts\"\n---\n\n# Frontend Rules\n\n## Structure\n\n- 页面组件放在 `frontend/src/pages/`。\n- 可复用组件放在 `frontend/src/components/`。\n- API 客户端放在 `frontend/src/api/`，复用 `request.ts`。\n- 共享类型放在 `frontend/src/types/`。\n- 路由路径放在 `frontend/src/constants/routes.ts`。\n\n## API\n\n- 后端接口返回 `Result<T>` 结构，前端 API 层负责解包和错误处理。\n- 不要在页面组件里直接拼接重复的 Axios 配置。\n- Provider、知识库、面试、简历等模块沿用现有 API 文件拆分。\n\n## UI\n\n- 延续现有 React + TailwindCSS 4 风格，不引入新的 UI 框架。\n- 操作按钮优先使用 `lucide-react` 图标加清晰文本或 tooltip。\n- 表单状态要包含 loading、success、error 和 disabled 处理。\n- 不要把业务说明性长文塞进页面；优先让界面直接可操作。\n\n## Verification\n\n- 前端改动后运行 `cd frontend && pnpm run build`。\n- 涉及浏览器交互时，用本地浏览器实际打开页面验证。\n","AGENTS.md":"# AI Interview Platform Agent Rules\n\nSpring Boot 4.1.0 + Java 25 + Spring AI 2.0.0 + React 面试平台。\n\n本文件是跨工具 Agent 入口，只放长期有效、代码里不容易直接推断、猜错会影响结果的规则。更细的目录规则放在 `.claude/rules/`，需要时再读取。\n\n## Tech Stack\n\n- Backend: Spring Boot 4.1.0 / Java 25 / Gradle / Spring AI 2.0.0\n- Database: PostgreSQL + pgvector，向量维度 1024，距离类型 COSINE\n- Cache & async: Redis / Redisson / Redis Stream\n- Storage & parsing: RustFS/S3 / Apache Tika\n- Mapping & export: MapStruct / iText 8 / SpringDoc OpenAPI\n- Frontend: React 18 / TypeScript / Vite / TailwindCSS 4，代码在 `frontend/`\n\n## Commands\n\n```bash\n./gradlew :app:compileJava\n./gradlew :app:test --no-daemon\n./gradlew :app:bootRun\n```\n\n```bash\ncd frontend && pnpm run dev\ncd frontend && pnpm run build\n```\n\n```bash\ndocker compose -f docker-compose.dev.yml up -d\n```\n\n## Project Structure\n\n- `app/src/main/java/interview/guide/common/`: 通用能力，包括限流、AI 调用、异步模板、配置、异常、统一响应。\n- `app/src/main/java/interview/guide/infrastructure/`: 技术基础设施，包括文件、导出、Redis、MapStruct 映射。\n- `app/src/main/java/interview/guide/modules/`: 业务模块，每个模块自包含 MVC 分层。\n- `app/src/main/resources/prompts/`: StringTemplate Prompt 模板。\n- `frontend/src/`: React 前端页面、组件、API 客户端和类型定义。\n\n## Architecture\n\n- 后端遵循 `Controller -> Service -> Repository`，Controller 只做路由、校验和委托。\n- Service 承担业务编排；`@Transactional` 只放 Service 层，并保持事务范围最小。\n- Repository 继承 Spring Data JPA `JpaRepository`，自定义查询用方法名或 `@Query`。\n- 基础设施能力优先放在 `common/` 或 `infrastructure/`，不要散落到业务 Service。\n- 对外响应统一使用 `Result<T>`，禁止直接返回 Entity。\n\n## Backend Rules\n\n- 业务异常必须使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 全局异常处理器返回 HTTP 200 + `Result.error(code, message)`。\n- 请求体优先用不可变 `record`，命名后缀使用 `XxxRequest` / `XxxResponse` / `XxxDTO` / `XxxEntity`。\n- Entity 到 DTO/Response 的映射优先使用 MapStruct。\n- 使用构造器注入，优先配合 Lombok `@RequiredArgsConstructor`。\n- 代码使用 2 空格缩进、无通配符导入、避免内联全限定类名。\n- 日志使用 SLF4J 占位符，异常必须作为最后一个参数传入。\n\n## AI And Async Rules\n\n- 获取聊天模型统一走 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- 结构化输出统一走 `StructuredOutputInvoker`，不要在业务代码里复制重试逻辑。\n- Prompt 模板放在 `resources/prompts/`，使用 StringTemplate `.st`。\n- LLM、S3、外部 HTTP 调用不得放在数据库事务内。\n- Redis Stream 生产/消费使用 `AbstractStreamProducer` / `AbstractStreamConsumer` 模板。\n- 异步处理前先校验实体是否存在；实体已删除时 ACK 丢弃。\n- 限流使用可重复 `@RateLimit`，不要手写散落的 Redis 限流逻辑。\n\n## Config And Data\n\n- 配置集中在 `application.yml`、`.env` 和 `@ConfigurationProperties` 类中。\n- API Key、数据库密码等敏感信息只放 `.env`，不得提交到 Git。\n- 不要在 Service 中散落 `@Value`。\n- 本地默认后端端口是 `8080`：`server.port: ${SERVER_PORT:8080}`。\n- 开发环境 `ddl-auto` 可为 `update`，生产环境不能依赖自动建表。\n\n## Frontend Rules\n\n- API 调用集中在 `frontend/src/api/`，复用 `request.ts` 的 Axios 实例。\n- 类型定义放在 `frontend/src/types/`，不要在页面里重复定义共享接口。\n- 页面放在 `frontend/src/pages/`，可复用 UI 放在 `frontend/src/components/`。\n- 路由常量放在 `frontend/src/constants/routes.ts`。\n- 组件交互优先使用现有设计语言和 `lucide-react` 图标。\n\n## Testing\n\n- 后端测试使用 JUnit 5 + Mockito + AssertJ。\n- 测试意图用中文 `@DisplayName` 描述，复杂场景用 `@Nested` 分组。\n- 集成测试使用 H2 配置；限流相关测试需要真实 Redis。\n- 改后端公共能力时至少运行 `./gradlew :app:test --no-daemon`。\n- 改前端时至少运行 `cd frontend && pnpm run build`。\n\n## Never Do\n\n- 不要 `throw new RuntimeException(...)`，业务失败必须用 `BusinessException`。\n- 不要直接返回 Entity 给前端。\n- 不要把 `@Value` 散落在 Service 中。\n- 不要在事务内调用 LLM、S3 或外部 HTTP。\n- 不要同类内部调用 `@Transactional` 方法。\n- 不要 `catch (Exception e) {}` 静默忽略。\n- 不要循环调用 DB，优先批量查询或批量写入。\n- 不要硬编码密钥、Token、数据库密码。\n- 不要使用 `Executors.newXxxThreadPool()`，需要线程池时显式配置 `ThreadPoolExecutor`。\n\n## More Rules\n\n- 后端 Java 细则：`.claude/rules/backend.md`\n- AI、限流、异步细则：`.claude/rules/ai-and-async.md`\n- 前端细则：`.claude/rules/frontend.md`\n","CLAUDE.md":"@AGENTS.md\n\n# Claude Code Instructions\n\n- `AGENTS.md` 是本仓库的共享规则源；更新长期规则时优先改 `AGENTS.md`，不要在这里复制一份。\n- 本文件只保留 Claude Code 专属入口和加载提示，避免根目录上下文膨胀。\n- 目录细则在 `.claude/rules/`，处理匹配文件前先读取对应规则。\n- 个人偏好和临时调试结论放 `CLAUDE.local.md` 或 Claude Memory，不要提交到仓库。\n\n## Path Rules\n\n- Backend: `.claude/rules/backend.md`\n- AI / async / rate limit: `.claude/rules/ai-and-async.md`\n- Frontend: `.claude/rules/frontend.md`\n\n## Maintenance\n\n- 新增规则前先判断：删掉这条后，Claude 是否更容易犯同类错误。\n- 能被测试、格式化、Hook 或 CI 强制的规则，不要只写成自然语言。\n- 如果同一条规则反复被忽略，优先精简规则文件，而不是继续加粗或加感叹号。\n","app/src/main/resources/skills/_shared/references/algorithm-data-structures.md":"# 算法与数据结构（统一参考）\n\n## 一、口述作答标准（文字/语音面试）\n1. 先定义问题与状态：输入、输出、约束、目标。\n2. 说明选型：为什么用该数据结构（而不是其他结构）。\n3. 口述步骤：关键流程、转移关系、剪枝或维护不变式。\n4. 复杂度：时间/空间复杂度 + 主瓶颈。\n5. 边界与反例：空输入、重复值、极端规模、退化场景。\n\n## 二、数组/链表\n- 高频思路：双指针、滑动窗口、前缀和、原地算法。\n- 典型追问：如何避免越界；是否能降空间；是否能单次扫描。\n\n## 三、哈希/堆/栈/队列\n- 哈希：去重、频次统计、映射索引、冲突与扩容代价。\n- 堆：TopK、动态中位数、多路归并，关注 `O(n log k)` 优化。\n- 栈：单调栈、括号匹配、表达式求值，不变式要说清。\n- 队列：BFS、双端队列、滑窗最值，解释队头有效性。\n\n## 四、树/图\n- 树：前中后序、层序、递归/迭代取舍。\n- 图：BFS/DFS、最短路、拓扑排序、并查集。\n- 典型追问：有环/无环处理、访问标记时机、复杂度上界。\n\n## 五、动态规划（DP）\n- 核心：状态定义、转移方程、初始化、遍历顺序。\n- 常见失误：状态遗漏、重复计算、滚动数组覆盖顺序错误。\n- 追问方向：如何从 `O(n^2)` 优化到 `O(n log n)`（若可行）。\n\n## 六、贪心/回溯\n- 贪心：局部最优能否推导全局最优，需给交换论证或反例说明。\n- 回溯：搜索树、剪枝条件、去重策略、最坏复杂度评估。\n\n## 七、设计题（算法建模）\n- 数据流、在线查询、延迟任务、限流计数等题型。\n- 重点：结构选型、正确性、复杂度与工程可落地性。\n","app/src/main/resources/skills/_shared/references/browser.md":"# 浏览器原理面试重点（渲染 + 缓存 + 安全 + 性能）\n\n## 渲染流水线\n- 关键渲染路径：HTML→DOM 树、CSS→CSSOM 树、合并→Render 树→布局→绘制→合成。\n- DOMContentLoaded vs load：DOM 解析完成 vs 所有资源加载完成，CSS 阻塞 DOM 渲染但不阻塞解析。\n- `<script>` 阻塞：默认阻塞 DOM 解析，`async`（下载完立即执行）vs `defer`（DOM 解析后执行）。\n- 合成层优化：`transform`/`opacity` 触发 GPU 合成，跳过布局与绘制。\n\n## 浏览器缓存\n- 强缓存：`Cache-Control`（max-age/no-cache/no-store）优先于 `Expires`。\n- 协商缓存：`ETag`/`If-None-Match` vs `Last-Modified`/`If-Modified-Since`，304 响应。\n- 缓存位置优先级：Service Worker → Memory Cache → Disk Cache → Push Cache。\n- CDN 缓存策略：回源机制、缓存命中率、预热与刷新。\n\n## 网络与协议\n- HTTP/1.1：持久连接（`Connection: keep-alive`）、管线化缺陷。\n- HTTP/2：多路复用、头部压缩（HPACK）、服务器推送、二进制分帧。\n- HTTP/3（QUIC）：基于 UDP、0-RTT 连接、解决队头阻塞。\n- HTTPS：TLS 握手流程（证书校验→密钥协商→对称加密通信），会话复用。\n\n## 安全\n- XSS：存储型/反射型/DOM 型，防御（转义、CSP、HttpOnly Cookie）。\n- CSRF：伪造请求利用已认证身份，防御（SameSite Cookie、CSRF Token、Referer 校验）。\n- CORS：简单请求 vs 预检请求（OPTIONS），`Access-Control-Allow-Origin` 等响应头。\n- CSP（Content-Security-Policy）：白名单限制资源加载，`nonce`/`hash` 策略。\n\n## 性能监控与优化\n- Core Web Vitals：LCP（最大内容绘制 ≤2.5s）、FID/INP（交互延迟 ≤100ms）、CLS（布局偏移 ≤0.1）。\n- 性能 API：`PerformanceObserver`、`performance.timing`（导航计时）、`PerformanceResourceTiming`。\n- 优化手段：代码分割、图片懒加载、预加载（`<link rel=\"preload\">`）、骨架屏。\n- 内存泄漏排查：Chrome DevTools Memory 面板，堆快照对比、分配时间线。\n\n## 面试追问模板\n- 从输入 URL 到页面渲染完成，中间经历了哪些步骤？\n- 你的项目做过哪些性能优化？效果如何量化？\n- CORS 预检请求失败，排查思路是什么？\n- 如何定位线上页面的内存泄漏？\n","app/src/main/resources/skills/_shared/references/database.md":"# 数据库通用面试重点（关系型 + NoSQL 选型）\n\n## 事务与隔离级别\n- ACID 含义：原子性（Undo Log）、一致性（约束与规则）、隔离性（锁/MVCC）、持久性（Redo Log）。\n- 四种隔离级别：读未提交→读已提交→可重复读→串行化，各自解决的脏读/不可重复读/幻读问题。\n- MVCC 原理：版本链（隐藏列 trx_id + roll_pointer）+ ReadView 快照，RC/RR 下 ReadView 生成时机差异。\n- 长事务危害：锁持有时间长、Undo Log 膨胀、MVCC 快照无法回收。\n\n## 索引\n- B+ 树适合磁盘索引：有序、范围查询、叶子链表、扇出大树高低。\n- 覆盖索引避免回表，联合索引最左前缀原则，索引下推（ICP）减少回表次数。\n- 索引失效：函数转换、隐式类型转换、OR 条件、LIKE 前缀通配、非最左列。\n- 唯一索引 vs 普通索引：查询性能差异（Change Buffer）、写入场景选择。\n\n## SQL 优化\n- EXPLAIN 执行计划：type（ref/range/index/all）、key、rows、Extra（Using index/Using filesort/Using temporary）。\n- 慢 SQL 定位：`slow_query_log` + `pt-query-digest`，重点关注全表扫描与大结果集。\n- 深度分页优化：游标分页（WHERE id > last_id）、延迟关联（子查询先查主键）。\n- 批量操作优化：批量 INSERT 替代逐条、INSERT ... ON DUPLICATE KEY UPDATE。\n\n## 分库分表\n- 垂直拆分（按业务模块）vs 水平拆分（按分片键散列/范围）。\n- 分片键选择：数据均匀性、查询路由效率、避免跨片查询。\n- 分布式主键：雪花算法（Snowflake）、号段模式（Leaf）、UUID 性能与索引问题。\n- 中间件：ShardingSphere 逻辑表/物理表映射、SQL 改写与路由。\n- 跨片聚合：内存合并、流式归并，全局排序成本。\n\n## 读写分离\n- 主从复制原理：Binlog 异步/半同步复制，主从延迟的成因与监控。\n- 读写分离路由：中间件（ShardingSphere/ProxySQL）vs 应用层注解驱动。\n- 主从延迟应对：强制读主库、延迟检测与降级、并行复制优化。\n\n## NoSQL 选型\n- Redis：缓存/会话/排行榜/分布式锁，数据全内存、不支持复杂查询。\n- MongoDB：文档模型、灵活 Schema、适合非结构化数据与快速迭代。\n- Elasticsearch：全文检索、倒排索引、日志分析场景，写入成本高。\n- HBase/Cassandra：海量数据宽表、LSM-Tree、适合高吞吐写入与时序数据。\n- 选型维度：数据模型、读写模式、一致性要求、扩展方式、运维复杂度。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？还有优化空间吗？\n- 分库分表后，跨片的 JOIN 和聚合查询怎么做？\n- 主从延迟 5 秒，业务怎么处理？\n- 为什么选这个 NoSQL 而不是 MySQL？迁移成本和风险怎么评估？\n","app/src/main/resources/skills/_shared/references/db-design.md":"# 数据库设计面试重点（建模 + 索引 + 演进）\n\n## 数据建模与范式\n- 三范式核心：1NF（原子性）、2NF（消除部分依赖）、3NF（消除传递依赖）。\n- 反范式设计：以冗余换查询性能，适用读多写少场景（如统计字段冗余）。\n- ER 建模：实体→关系→属性，一对一/一对多/多对多的表结构映射。\n- 宽表 vs 窄表：OLTP 倾向窄表（范式化）、OLAP 倾向宽表（星型/雪花模型）。\n\n## 索引设计策略\n- 索引选择性：高基数列优先，区分度 `COUNT(DISTINCT col)/COUNT(*)` 接近 1 最佳。\n- 联合索引设计：等值条件列在前、范围条件列在后，遵循最左前缀。\n- 覆盖索引设计：将查询所需的列全部纳入索引，消除回表。\n- 避免过度索引：写入开销、存储成本、索引维护（DML 时需同步更新）。\n\n## 冷热数据分层\n- 冷热识别标准：访问时间衰减、业务状态流转（如订单已完成→归档）。\n- 冷数据存储：归档表、历史库、对象存储（OSS/S3），压缩降低存储成本。\n- 数据生命周期管理（DLM）：TTL 过期自动清理、定期迁移、分区裁剪。\n- 分区表策略：RANGE（按时间）、LIST（按枚举）、HASH（按散列），分区裁剪加速查询。\n\n## 扩容与迁移\n- 垂直扩容（升级硬件）vs 水平扩容（分片/分库分表），各自的瓶颈与上限。\n- 平滑扩容流程：新分片上线→双写→历史数据迁移→一致性校验→切读→下线旧分片。\n- 数据迁移工具：Canal 监听 Binlog 增量同步、全量+增量切换方案。\n- 回滚预案：切换失败时快速切回旧库，保留旧库只读窗口。\n\n## 软删除与审计\n- 软删除（`is_deleted` 标记）vs 硬删除：恢复能力 vs 存储膨胀与查询过滤。\n- 审计字段：`created_at`/`updated_at`/`created_by`/`updated_by`，自动化填充（MyBatis 拦截器/JPA Auditing）。\n- 数据版本控制：乐观锁版本号（`version`），防止并发覆盖。\n- 敏感数据处理：加密存储、脱敏查询、合规删除（GDPR/个人信息保护法）。\n\n## 面试追问模板\n- 订单表数据量到亿级，你怎么设计索引和分片方案？\n- 线上需要给大表加字段，怎么做不停机？\n- 冷热数据迁移过程中，如何保证查询不受影响？\n- 你的项目遇到过数据模型演进的问题吗？怎么处理的？\n","app/src/main/resources/skills/_shared/references/design-pattern.md":"# 设计模式面试重点\n\n## 创建型\n- 单例模式：饿汉/懒汉/DCL/静态内部类/枚举，DCL 为何要 volatile，枚举防反射/序列化。\n- 工厂模式：简单工厂→工厂方法→抽象工厂，开闭原则的递进体现。\n- 建造者模式：与工厂模式的区别，链式调用场景（Lombok @Builder）。\n\n## 结构型\n- 代理模式：JDK 动态代理 vs CGLIB，Spring AOP 默认选型策略。\n- 适配器模式：类适配器 vs 对象适配器，Slf4J 日志门面的适配原理。\n- 装饰器模式：与代理模式的区别，Java I/O 流的装饰链。\n\n## 行为型\n- 观察者模式：JDK Observable（已废弃）vs 事件驱动，Spring Event 机制。\n- 策略模式：消除 if-else，结合工厂或 Spring 注入实现策略路由。\n- 责任链模式：Servlet Filter / Spring Interceptor / Netty Pipeline。\n- 模板方法模式：Spring AbstractApplicationContext#refresh。\n- 状态模式：与策略模式的区别（状态内部转换 vs 外部切换）。\n\n## 设计原则\n- SOLID 原则在代码中的体现，重点考察开闭原则和依赖倒置。\n- 合成/聚合复用 vs 继承复用。\n\n## 框架中的设计模式\n- Spring：单例（Bean 默认）、工厂（BeanFactory）、代理（AOP）、观察者（Event）、模板方法（JdbcTemplate）。\n- JDK：迭代器（Collection）、装饰器（I/O）、适配器（Arrays.asList）。\n- MyBatis：代理（MapperProxy）、模板方法（BaseExecutor）。\n\n## 面试追问模板\n- 你的项目中哪里用到了设计模式？为什么选这个模式？\n- 如果不用这个模式，代码会变成什么样？\n- 这个模式有什么缺点？什么场景下不适合？\n","app/src/main/resources/skills/_shared/references/distributed.md":"# 分布式系统面试重点\n\n## 基础理论\n- CAP 定理：三者不可兼得，网络分区必然存在时的取舍。\n- BASE 理论：基本可用、软状态、最终一致性，与 ACID 的对比。\n- 一致性模型：强一致、单调读、因果一致、最终一致。\n\n## 共识算法\n- Paxos：Basic Paxos 角色（Proposer/Acceptor/Learner）与两阶段流程。\n- Raft：Leader 选举（任期+日志对比）、日志复制、安全性保证。\n- ZAB：与 Raft 的异同，ZXID 结构（epoch + counter）。\n\n## 分布式锁\n- Redis 分布式锁：`SET NX EX` + Lua 释放、Redisson 可重入锁与看门狗。\n- ZooKeeper 分布式锁：临时顺序节点、Watcher 机制、羊群效应避免。\n- 选型：性能优先 Redis，可靠性优先 ZK。\n\n## 分布式事务\n- 2PC：准备→提交，同步阻塞与单点故障问题。\n- TCC：Try/Confirm/Cancel，空回滚与幂等处理。\n- SAGA：正向补偿 vs 反向补偿，适合长事务。\n- Seata AT 模式：全局锁 + 一阶段提交 + 二阶段回滚。\n\n## 分布式 ID\n- 雪花算法（Snowflake）：64 位结构、时钟回拨问题与解决。\n- UUID、数据库自增、号段模式（Leaf）的优劣对比。\n\n## API 网关与 RPC\n- 网关核心职责：路由、鉴权、限流、熔断、可观测。\n- HTTP vs RPC：协议开销、服务治理、跨语言、适用场景。\n- Dubbo 架构：Provider/Consumer/Registry/Monitor，负载均衡策略。\n\n## 一致性哈希\n- 虚拟节点解决数据倾斜，新增/移除节点时最小化数据迁移。\n\n## 面试追问模板\n- 网络分区发生时，你的系统选择保 CP 还是 AP？为什么？\n- 分布式事务失败了怎么补偿？人工介入还是自动？\n- 如何设计一个支持百万 QPS 的分布式 ID 生成服务？\n","app/src/main/resources/skills/_shared/references/django-flask.md":"# Django/Flask 面试重点（框架 + ORM + 部署）\n\n## 框架定位与对比\n- Django：全栈框架（ORM/Admin/Auth/Template 内置），\"batteries included\" 哲学，适合快速交付。\n- Flask：微框架（路由+模板引擎核心），扩展生态灵活，适合定制化与微服务。\n- 选型：快速 MVP/内容管理选 Django，API 服务/微服务/深度定制选 Flask。\n- FastAPI：异步原生、Pydantic 类型校验、自动生成 OpenAPI 文档，适合新项目。\n\n## 请求生命周期\n- Django：URLconf 路由→Middleware 链→View 函数/类→Template/JSON 响应→Middleware 链（逆序返回）。\n- Flask：Werkzeug WSGI 路由→before_request 钩子→View 函数→after_request 钩子→响应。\n- 中间件/钩子：认证注入、请求日志、异常捕获、数据库事务管理。\n- 请求上下文：Django（request/response 对象传递）、Flask（thread-local `g` 对象/应用上下文）。\n\n## ORM 与查询优化\n- Django ORM：QuerySet 惰性求值、`select_related`（JOIN，一对一/外键）vs `prefetch_related`（二次查询，多对多）。\n- N+1 问题：循环中触发懒加载，解法为 `select_related`/`prefetch_related` 批量预加载。\n- Flask-SQLAlchemy：Session 管理、eager loading（`joinedload`/`subqueryload`）、批量操作。\n- 查询优化：`only()`/`defer()` 延迟加载字段、`bulk_create` 批量插入、`iterator()` 流式读取大结果集。\n\n## 认证、权限与安全\n- Django Auth：User 模型、`authenticate`/`login`/`logout` 流程、Permission/Group 权限体系。\n- Token 认证：JWT（djangorestframework-simplejwt）/ DRF TokenAuthentication。\n- 安全防护：CSRF Token（Django 内置）、XSS 转义（模板自动转义）、SQL 注入（ORM 参数化）、CORS 配置。\n- 密码存储：Django 使用 PBKDF2 + salt，可配置 bcrypt/argon2。\n\n## 缓存与性能\n- Django 缓存框架：`@cache_page` 装饰器、缓存后端（Redis/Memcached/本地内存）。\n- Flask 缓存：Flask-Caching 扩展，`@cached` 装饰器、Jinja2 片段缓存。\n- 数据库查询缓存：`QuerySet.cache()`、手动缓存策略、缓存失效与一致性。\n- 静态文件：Django Collectstatic + CDN、Flask 静态文件服务（生产环境用 Nginx）。\n\n## 部署与运维\n- WSGI（同步）：Gunicorn/uWSGI，多 Worker 进程 + preload + 优雅重启。\n- ASGI（异步）：Uvicorn/Daphne，支持 WebSocket 和 async view。\n- 容器化：Docker 多阶段构建、环境变量管理、健康检查端点。\n- 监控：Sentry 异常捕获、Prometheus 指标暴露、日志结构化输出（JSON logging）。\n\n## 面试追问模板\n- Django ORM 的 N+1 问题你怎么发现的？怎么解决的？\n- Flask 的上下文是怎么实现的？多线程下安全吗？\n- 你的项目用的 WSGI 还是 ASGI？为什么？遇到什么瓶颈？\n- 线上一个接口突然变慢，从框架层面怎么排查？\n","app/src/main/resources/skills/_shared/references/high-availability.md":"# 高可用面试重点（故障防护 + 容灾 + 可观测性）\n\n## 故障检测与主备切换\n- 心跳检测：应用层（HTTP 探针）vs TCP 层，超时阈值与抖动容忍。\n- 主备切换：主动-被动（冷备/热备）vs 主动-主动（双写+负载均衡）。\n- 选主机制：Raft/Paxos 共识、ZooKeeper 临时节点、etcd Lease。\n- 脑裂防护：Fencing（STONITH）/仲裁节点/ Lease 锁，避免双主写入。\n- 切换窗口：RTO（恢复时间目标）与 RPO（恢复点目标）的工程实现。\n\n## 限流、熔断与降级\n- 限流算法：固定窗口（临界突刺）、滑动窗口、令牌桶（匀速放行）、漏桶（平滑输出）。\n- 分布式限流：Redis Lua 原子计数 + 滑动窗口、Sentinel 集群限流模式。\n- 熔断器模式：Closed→Open→Half-Open 状态机，失败率/慢调用率触发。\n- 降级策略：返回缓存数据/默认值/简化结果、关闭非核心功能、手动开关。\n- 级联故障预防：超时设置（connect/read）、重试次数与退避策略、舱壁隔离（线程池/信号量）。\n\n## SLA/SLO 与可观测性\n- SLA/SLO/SLI 关系：SLO 是目标（如 99.9% 可用）、SLI 是指标（延迟/错误率）、SLA 是合同。\n- 三大支柱：Metrics（Prometheus + Grafana）、Logging（ELK/Loki）、Tracing（Jaeger/SkyWalking）。\n- 告警设计：分级（P0-P3）、收敛（抑制/聚合/路由）、OnCall 轮值与升级。\n- 错误预算：SLO 剩余预算决定发布节奏与变更风险容忍度。\n\n## 容量规划与混沌工程\n- 容量评估：QPS 峰值估算、带宽/存储/连接数上限、资源瓶颈定位（CPU/IO/网络）。\n- 压测方法论：基准压测→阶梯加压→极限探测，关注长尾延迟（P99）而非均值。\n- 自动弹性：HPA（Kubernetes）/ASG（云厂商），指标驱动（CPU/自定义指标）扩缩容。\n- 混沌工程：Chaos Mesh/LitmusChaos，故障注入（网络延迟/节点宕机/依赖不可用）。\n\n## 异地多活与容灾\n- 同城双活：两个机房同时提供服务，数据库跨机房同步（延迟可控）。\n- 异地多活：单元化架构（用户路由到固定单元）、数据同步（ Canal/Otter/Binlog）。\n- 全球化部署：DNS 就近路由、CDN 静态资源加速、数据合规（GDPR 数据驻留）。\n- 灾备演练：定期切换演练、数据一致性校验、回滚流程验证。\n\n## 面试追问模板\n- 流量突增 10 倍，你的系统哪里先扛不住？怎么应急？\n- 熔断打开后，下游恢复了你怎么感知？自动恢复还是人工？\n- 你的项目 SLA 是多少？怎么保证的？出过故障吗？\n- 混沌工程你在团队推行过吗？遇到过什么阻力？\n","app/src/main/resources/skills/_shared/references/java.md":"# Java 面试重点（基础 + 集合 + 并发 + JVM）\n\n## 基础概念\n- JVM/JDK/JRE 区别，字节码与\"编译+解释\"执行模型，AOT vs JIT。\n- 8 种基本类型与包装类，自动装箱/拆箱与 Integer Cache。\n- `==` vs `equals()`，`hashCode()` 与 `equals()` 一致性约束。\n- 方法重载 vs 重写，静态分派与动态分派。\n- 接口 vs 抽象类，Java 8+ default 方法的影响。\n- 深拷贝 vs 浅拷贝，序列化方案。\n\n## String\n- 不可变性原理（final byte[]），安全与性能影响。\n- 字符串常量池：`intern()`、编译期优化、`new String(\"abc\")` 创建对象数。\n- `String` vs `StringBuilder` vs `StringBuffer`。\n\n## 集合框架\n- List：ArrayList（动态数组、扩容 1.5 倍）vs LinkedList（双向链表），RandomAccess 标记。\n- Map：HashMap 底层（数组+链表+红黑树）、负载因子与扩容、线程不安全场景。\n- HashMap 长度为何是 2 的幂次方，多线程死循环问题。\n- ConcurrentHashMap：JDK 7 分段锁 vs JDK 8 CAS+synchronized，key/value 不为 null。\n- Set：HashSet（基于 HashMap）、LinkedHashSet、TreeSet（红黑树）。\n- Queue：BlockingQueue 接口，ArrayBlockingQueue vs LinkedBlockingQueue。\n- fail-fast vs fail-safe 机制。\n\n## 并发\n- 线程生命周期与状态转换，上下文切换成本。\n- 死锁：条件、检测（jstack/arthuras）、预防策略。\n- JMM：可见性、有序性、happens-before；volatile 保证可见性+禁止重排序但不保证原子性。\n- synchronized 底层原理（Monitor）、锁升级（偏向→轻量→重量）、偏向锁废弃。\n- ReentrantLock vs synchronized：可中断、公平锁、Condition、超时获取。\n- CAS 与 ABA 问题，Atomic 原理。\n- 线程池：核心参数（corePoolSize/maxPoolSize/queue/handler）、拒绝策略、动态配置。\n- AQS 原理（state + CLH 队列），Semaphore/CountDownLatch/CyclicBarrier。\n- ThreadLocal：原理、内存泄漏与弱引用、跨线程传递（TransmittableThreadLocal）。\n- CompletableFuture：编排、异常处理、自定义线程池。\n- 虚拟线程（Java 21）：用途与调度模型。\n\n## JVM\n- 运行时数据区：堆/栈/方法区/元空间/程序计数器/直接内存。\n- 对象创建流程、内存布局、访问定位（句柄 vs 直接指针）。\n- GC 判断：引用计数 vs 可达性分析；四种引用（强/软/弱/虚）。\n- GC 算法：标记-清除、复制、标记-整理、分代收集。\n- 垃圾收集器：Serial→Parallel→CMS→G1→ZGC，各自适用场景。\n- G1 回收流程（Young GC / Mixed GC），ZGC 着色指针与读屏障。\n- 双亲委派模型与打破方式（SPI、OSGi、线程上下文类加载器）。\n- OOM 排查：Heap Dump、jmap/jstat/arthuras、GC 日志分析。\n\n## 面试追问模板\n- 这个机制底层是怎么实现的？有什么性能代价？\n- 多线程环境下会有什么问题？如何保证线程安全？\n- 框架（Spring/MyBatis）中哪里用到了这个机制？\n- 线上遇到 OOM/GC 频繁怎么排查？参数怎么调？\n","app/src/main/resources/skills/_shared/references/javascript.md":"# JavaScript 面试重点（基础 + 异步 + 工程化）\n\n## 类型与作用域\n- 8 种数据类型（7 原始 + Object），`typeof null === \"object\"` 历史遗留。\n- `let`/`const` vs `var`：块级作用域、暂时性死区（TDZ）、变量提升差异。\n- 作用域链：词法作用域（静态），引擎沿作用域链逐层查找标识符。\n- 闭包：函数与其词法环境的绑定，经典场景（防抖/节流/私有变量/柯里化）与内存泄漏风险。\n\n## 原型与继承\n- 原型链：`__proto__` vs `prototype`，属性查找沿原型链向上。\n- `Object.create()` vs `new`：直接指定原型 vs 构造函数实例化。\n- `class` 语法糖：`extends`/`super` 底层仍基于原型链，`static` 方法不可继承到实例。\n- `Object.setPrototypeOf` 性能问题，推荐 `Object.create` 替代。\n\n## 异步编程\n- 事件循环：宏任务（setTimeout/setInterval/I/O）与微任务（Promise.then/MutationObserver）执行顺序。\n- Promise：状态机（pending→fulfilled/rejected），链式调用与错误冒泡，`Promise.all` vs `Promise.allSettled` vs `Promise.race`。\n- `async/await`：语法糖，异常用 `try/catch` 捕获，并行场景仍需 `Promise.all`。\n- `async` 函数中的并发陷阱：串行 `await` vs 并行 `Promise.all`，性能差异。\n\n## ES6+ 核心特性\n- 解构赋值（数组/对象/默认值）、展开/剩余运算符。\n- 箭头函数：没有 `this`/`arguments`/`prototype`，不适合作为构造函数。\n- `Symbol`：唯一标识符，`Symbol.iterator` 与 `for...of` 协议。\n- `Map`/`Set`/`WeakMap`/`WeakSet`：与 Object/Array 的适用场景对比。\n- `Proxy`/`Reflect`：元编程基础，Vue 3 响应式原理的核心。\n\n## DOM 与 BOM\n- DOM 操作成本：重排（Layout）与重绘（Paint），批量更新策略（`DocumentFragment`/虚拟 DOM）。\n- 事件模型：捕获→目标→冒泡，`addEventListener` 第三个参数，事件委托。\n- `requestAnimationFrame` vs `setTimeout`：与屏幕刷新率同步，避免丢帧。\n\n## 模块化与工程化\n- CommonJS（`require`/`module.exports`，同步加载）vs ES Modules（`import`/`export`，静态分析）。\n- Tree-shaking 原理：ES Modules 静态结构使编译期可判定副作用。\n- `package.json` 依赖管理：`dependencies` vs `devDependencies`，语义化版本（semver）。\n- TypeScript 类型系统：接口/泛型/联合类型/类型守卫，与运行时无关。\n\n## 面试追问模板\n- 闭包在实际项目中用在哪里？遇到过内存泄漏吗？\n- 宏任务和微任务的执行顺序，你能举个复杂场景说明吗？\n- Promise 链中某个环节没 return，会发生什么？\n- CommonJS 和 ES Modules 能混用吗？打包工具怎么处理？\n","app/src/main/resources/skills/_shared/references/mq.md":"# 消息队列面试重点（模型 + 可靠性 + 主流 MQ 对比）\n\n## 消息模型\n- 点对点（Queue）：一条消息只能被一个消费者消费，消费后删除。\n- 发布订阅（Topic）：一条消息可被多个订阅者消费，消费独立。\n- 消费组（Consumer Group）：同一组内竞争消费、不同组间广播消费。\n- 消息顺序性：全局有序（单 Partition）vs 分区有序（同一 key 路由到同一 Partition）。\n\n## 投递语义\n- 至多一次（At Most Once）：可能丢消息，性能最高，适用允许丢失的场景（监控指标）。\n- 至少一次（At Least Once）：可能重复，需要消费端幂等，是大多数 MQ 的默认语义。\n- 恰好一次（Exactly Once）：Kafka 事务 + 幂等 Producer，RocketMQ 事务消息。\n- 幂等消费：唯一键去重（Redis/数据库唯一约束）、业务状态机判断。\n\n## 可靠性保障\n- 生产端确认：Kafka `acks=all`、RabbitMQ Publisher Confirm、RocketMQ 同步刷盘。\n- 消费端确认：手动 ACK（避免自动确认后处理失败丢消息）。\n- 消息持久化：磁盘持久化（Kafka 日志段、RocketMQ CommitLog）、副本机制。\n- 死信队列（DLQ）：消费重试达到上限后转入死信，人工介入处理。\n\n## 消费积压处理\n- 积压原因：消费者宕机、处理变慢（下游依赖超时）、突发流量。\n- 应急处理：紧急扩容消费者、临时消费者绕过慢逻辑先落库、消息降级。\n- 长期预防：消费监控告警（Lag 阈值）、容量预估、消费幂等保障安全扩容。\n- 削峰填谷：MQ 作为缓冲层，上游快速写入、下游匀速消费，保护下游系统。\n\n## 主流 MQ 对比\n- Kafka：高吞吐、顺序磁盘写、零拷贝、适合日志/事件流、Pull 模式。\n- RocketMQ：事务消息、延迟消息、消息过滤（Tag/SQL92）、适合电商金融、Push/Pull。\n- RabbitMQ：AMQP 协议、路由灵活（Exchange 类型丰富）、适合任务分发、Push 模式。\n- 选型维度：吞吐量、延迟、消息可靠性、顺序性、运维复杂度、社区生态。\n\n## 消息中间件架构\n- Kafka：Broker + Topic + Partition + Replica，Leader-Follower ISR 机制。\n- RocketMQ：NameServer + Broker + CommitLog + ConsumeQueue，高性能顺序写。\n- 分区/队列设计：分区数影响并行度、分区迁移与再平衡（Rebalance）、消费者组变更。\n\n## 面试追问模板\n- 消息积压了 100 万条，怎么处理？多久能恢复？\n- 如何保证消息不丢、不重、有序？你的项目怎么做的？\n- Kafka 和 RocketMQ 在你项目中怎么选的？用过什么特性？\n- 消费者 Rebalance 期间消息怎么处理？会造成重复消费吗？\n","app/src/main/resources/skills/_shared/references/mysql.md":"# MySQL 面试重点\n\n## 索引\n- B+ 树为什么适合磁盘索引（有序、范围查询、叶子链表）。\n- 覆盖索引与回表成本，联合索引最左前缀原则与索引下推。\n- 索引失效场景：函数转换、隐式类型转换、OR、LIKE 前缀通配、非最左列。\n- EXPLAIN 执行计划：type/key/Extra 字段含义，Extra 中 Using filesort/Using temporary。\n\n## 事务与 MVCC\n- ACID 含义，事务隔离级别（RU/RC/RR/SERIALIZABLE）与各自解决的问题。\n- MySQL 默认 RR，InnoDB 通过 MVCC + Next-Key Lock 解决幻读。\n- MVCC 原理：隐藏列（trx_id/roll_pointer）、Undo Log 版本链、ReadView。\n- 当前读 vs 快照读，RR 下当前读仍加间隙锁。\n\n## 锁机制\n- 表级锁 vs 行级锁，InnoDB 行锁（Record/Gap/Next-Key）。\n- 意向锁的作用（快速判断表级冲突），IS/IX 与 S/X 的兼容矩阵。\n- 死锁检测与避免：按固定顺序加锁、缩短事务、降低隔离级别。\n\n## 存储引擎与日志\n- InnoDB vs MyISAM：事务、行锁、外键、崩溃恢复。\n- Redo Log（WAL、crash-safe）vs Undo Log（MVCC、回滚）vs Binlog（主从复制、归档）。\n- 两阶段提交保证 Redo Log 与 Binlog 一致性。\n\n## 性能优化\n- 慢 SQL 定位：slow_query_log、pt-query-digest。\n- 分库分表策略：垂直拆分 vs 水平拆分，ShardingSphere 中间件。\n- 深度分页优化：游标分页、延迟关联、子查询先查主键。\n- 数据冷热分离，读写分离架构。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？能否优化？\n- 高并发写入时，锁冲突怎么解决？\n- 主从延迟怎么处理？数据一致性如何保证？\n","app/src/main/resources/skills/_shared/references/network-os.md":"# 网络与操作系统（后端面试核心）\n\n## TCP / HTTP 高频点\n- TCP 三次握手与四次挥手，TIME_WAIT 的意义与优化边界。\n- 粘包/拆包原因与解决（长度字段、分隔符、固定包长）。\n- HTTP1.1/2 差异：连接复用、队头阻塞、头部压缩。\n- HTTPS 握手流程：证书校验、密钥协商、会话复用。\n\n## 并发与线程模型\n- 进程/线程区别，用户态与内核态切换成本。\n- 线程池参数设计：核心线程、队列、拒绝策略、监控指标。\n- 锁优化：悲观锁/乐观锁、CAS、自旋、锁升级。\n\n## 内存与 I/O\n- JVM 内存区域、GC 停顿对接口延迟的影响。\n- 零拷贝、mmap、sendfile 的适用场景。\n- Reactor 模型与同步阻塞模型差异。\n\n## 面试追问模板\n- 为什么不是这个方案？底层代价是什么？\n- 如果连接数/流量翻倍，瓶颈会先出现在哪里？\n- 出现网络抖动或线程池打满时，如何降级与恢复？\n","app/src/main/resources/skills/_shared/references/python-basic.md":"# Python 面试重点（语言核心 + 并发 + 工程实践）\n\n## 数据模型与语法特性\n- 一切皆对象：`id()`/`type()`/`value`，可变对象（list/dict/set）vs 不可变对象（int/str/tuple）。\n- 魔法方法：`__init__` vs `__new__`、`__str__` vs `__repr__`、`__eq__` vs `__hash__`、`__enter__`/`__exit__`（上下文管理器）。\n- 多重继承与 MRO：C3 线性化算法、`super()` 沿 MRO 链调用。\n- 描述符协议：`__get__`/`__set__`/`__delete__`，property/classmethod/staticmethod 的底层实现。\n\n## 迭代器、生成器与装饰器\n- 迭代器协议：`__iter__` + `__next__`，`StopIteration` 终止，`for` 循环底层机制。\n- 生成器：`yield` 暂停与恢复、惰性求值、内存优势（处理大数据集/无限序列）。\n- 生成器表达式 vs 列表推导式：内存 vs 速度的取舍。\n- 装饰器：闭包 + `@` 语法糖、带参数装饰器（三层嵌套）、`functools.wraps` 保留元信息。\n- 类装饰器 vs 函数装饰器，`__call__` 实现。\n\n## GIL 与并发模型\n- GIL（全局解释器锁）：CPython 的内存安全机制，CPU 密集型多线程无法并行。\n- 多线程（`threading`）：适合 I/O 密集型（网络请求/文件读写），GIL 在 I/O 等待时释放。\n- 多进程（`multiprocessing`）：绕过 GIL，进程间通信（Queue/Pipe/共享内存），进程池。\n- 异步（`asyncio`）：事件循环 + 协程（`async`/`await`），适合高并发 I/O，单线程无锁。\n- `concurrent.futures`：`ThreadPoolExecutor` vs `ProcessPoolExecutor`，统一的 Future 接口。\n\n## 内存管理与垃圾回收\n- 引用计数：主要回收机制，实时性好但无法处理循环引用。\n- 分代 GC：0/1/2 三代，新对象从 0 代开始，存活时间越长晋升概率越低。\n- 循环引用检测：`gc` 模块的标记-清除算法，`gc.collect()` 手动触发。\n- 内存优化：`__slots__` 禁止动态属性字典、`sys.getsizeof`、内存分析工具（`tracemalloc`/`memory_profiler`）。\n\n## 类型系统与工程实践\n- Type Hints：`typing` 模块（`Optional`/`Union`/`Generic`/`Protocol`），mypy 静态检查。\n- dataclass vs attrs vs Pydantic：数据类定义、校验、序列化的选型。\n- 包管理：`pip` + `requirements.txt` vs `poetry`/`uv`（锁文件、依赖解析）。\n- 虚拟环境：`venv`/`conda`，隔离项目依赖避免版本冲突。\n- 代码质量：`ruff`（lint + format）、`pytest`（测试框架）、`pre-commit`（Git 钩子）。\n\n## 面试追问模板\n- Python 的 GIL 在你的项目中造成过问题吗？怎么解决的？\n- 装饰器写过什么功能？带参数的装饰器怎么实现的？\n- 内存泄漏怎么排查？用过哪些工具？\n- 大量数据处理时，你会用生成器还是列表？权衡点是什么？\n","app/src/main/resources/skills/_shared/references/react-vue.md":"# React/Vue 面试重点（框架核心 + 工程化）\n\n## React 核心机制\n- Fiber 架构：链表结构替代递归、可中断渲染、时间切片（Time Slicing）与优先级调度。\n- Virtual DOM：Diff 算法（同层比较、key 的作用）、Reconciliation 过程。\n- Hooks 规则：调用顺序一致（不能在条件/循环中调用）、闭包陷阱（stale closure）与解决方案。\n- 常用 Hooks：`useState`/`useEffect`（依赖数组）/`useCallback`/`useMemo`/`useRef`/`useContext`。\n- `useEffect` vs `useLayoutEffect`：异步 vs 同步、绘制前 vs 绘制后。\n- React 18 并发特性：`useTransition`（非紧急更新降级）、`useDeferredValue`（延迟重渲染）、Suspense 数据获取。\n\n## Vue 核心机制\n- 响应式原理：Vue 2（`Object.defineProperty` 拦截 getter/setter）vs Vue 3（`Proxy` 代理全对象）。\n- Composition API：`ref`/`reactive`/`computed`/`watch`/`watchEffect`，逻辑组合 vs Options API 逻辑分散。\n- 模板编译：模板→AST→渲染函数→Virtual DOM，静态提升与补丁标记（Patch Flag）。\n- 组件更新粒度：Vue 3 基于依赖追踪的精确更新 vs React 整体重渲染（需 memo/shouldComponentUpdate）。\n- Vue 3 编译优化：Block Tree、静态提升（hoistStatic）、缓存事件处理器。\n\n## 状态管理\n- React：Context API（轻量）、Redux（单向数据流/reducer/middleware）、Zustand（极简 Hook 式）、Jotai/Recoil（原子化）。\n- Vue：Pinia（Vue 3 官方推荐，TS 友好、模块化）、Vuex（Vue 2 时代，mutation/action 分离）。\n- 状态分层：组件本地状态 vs 全局共享状态 vs 服务端状态（React Query/TanStack Query）。\n\n## 组件设计\n- 组件通信：props/emit、provide/inject（跨层级）、事件总线、状态管理。\n- 组件抽象：高阶组件（HOC）vs Render Props vs Hooks（React）、插槽（Slots）vs 作用域插槽（Vue）。\n- 受控 vs 非受控组件：表单管理策略、`ref` 获取 DOM/组件实例。\n- 性能优化：`React.memo`/`useMemo`/`useCallback`、Vue `v-once`/`v-memo`、虚拟列表（react-window/vue-virtual-scroller）。\n\n## 路由与 SSR\n- React Router：声明式路由、嵌套路由、路由守卫、懒加载（`React.lazy` + `Suspense`）。\n- Vue Router：动态路由匹配、导航守卫（beforeEach/afterEach）、路由懒加载。\n- SSR vs CSR vs SSG：SEO、首屏速度、服务器成本权衡。\n- Next.js：SSR/SSG/ISR/App Router、Nuxt.js：服务端渲染与混合渲染。\n- Hydration：SSR HTML + 客户端 JS 绑定事件，注水不匹配（hydration mismatch）排查。\n\n## 工程化\n- 构建工具：Vite（ESM 开发服务器 + Rollup 构建）vs Webpack（loader/plugin 生态）。\n- 代码规范：ESLint + Prettier、Husky + lint-staged（提交前检查）。\n- 测试：Jest/Vitest（单元测试）、React Testing Library/Vue Test Utils（组件测试）、Playwright/Cypress（E2E）。\n- 微前端：Module Federation、qiankun、single-spa，应用隔离与通信。\n\n## 面试追问模板\n- React 的 Fiber 架构解决了什么问题？调度是怎么实现的？\n- Vue 3 的 Proxy 响应式和 Vue 2 的 defineProperty 有什么本质区别？\n- 大列表渲染卡顿怎么优化？虚拟列表的原理是什么？\n- 你的项目状态管理怎么选型的？遇到过什么问题？\n","app/src/main/resources/skills/_shared/references/redis.md":"# Redis 面试重点\n\n## 数据类型与场景\n- 五种基础类型：String/Hash/List/Set/ZSet，各类型底层编码与适用场景。\n- 特殊类型：Bitmap（活跃统计）、HyperLogLog（UV 去重）、Stream（消息队列）。\n- ZSet 底层为什么用跳表而不是红黑树/B+树（范围查询、实现简单、内存灵活）。\n\n## 持久化与线程模型\n- RDB（fork + COW）vs AOF（写后日志、fsync 策略），混合持久化。\n- Redis 6.0 前单线程模型（避免锁竞争、IO 多路复用），6.0 后多线程 IO（命令执行仍单线程）。\n\n## 生产问题\n- 缓存穿透（布隆过滤器/空值缓存）、缓存击穿（互斥锁/永不过期）、缓存雪崩（随机过期/多级缓存）。\n- 缓存与数据库一致性：延迟双删、Canal 监听 Binlog、最终一致性方案。\n\n## 分布式锁\n- `SET key value NX EX` 基本实现，误删问题与 Lua 原子释放。\n- Redisson 可重入锁原理（Hash 结构 + Lua 脚本），看门狗续期机制。\n- 集群下可靠性：RedLock 争议与替代方案（fencing token）。\n\n## 性能优化\n- Pipeline 批量减少 RTT，Lua 脚本保证原子性。\n- BigKey 检测与拆分（redis-rdb-tools、UNLINK 异步删除）。\n- HotKey 发现与本地缓存 + 热点分散。\n- 内存淘汰策略：allkeys-lru vs volatile-lru，内存碎片清理。\n\n## 集群\n- 主从复制（全量 + 增量）、哨兵模式（故障转移、主观/客观下线）。\n- Cluster 模式：16384 槽位、Gossip 协议、重定向（MOVED/ASK）。\n\n## 面试追问模板\n- 如果 Redis 宕机，业务怎么降级？\n- 百万级 QPS 场景下，缓存架构怎么设计？\n- 大 Key 线上清理导致阻塞怎么办？\n","app/src/main/resources/skills/_shared/references/spring.md":"# Spring 面试重点\n\n## IoC 与 Bean\n- IoC 解决什么问题：解耦对象创建与依赖管理。\n- `@Component` vs `@Bean`：声明方式、代理对象、第三方库集成。\n- `@Autowired` vs `@Resource`：按类型 vs 按名称，优先级规则。\n- 构造器注入 vs Setter 注入 vs 字段注入：不可变性、循环依赖、测试友好度。\n- Bean 作用域（singleton/prototype/request/session），线程安全分析。\n- Bean 生命周期：实例化→属性注入→Aware→初始化→销毁，各阶段扩展点。\n\n## AOP\n- 核心概念：切面/切点/通知/连接点。\n- Spring AOP vs AspectJ：动态代理 vs 编译期织入，性能与功能差异。\n- 通知类型：@Before/@After/@AfterReturning/@AfterThrowing/@Around。\n- 同类内部调用 AOP 失效原因与解决方案（AopContext/exposeProxy）。\n\n## Spring MVC\n- DispatcherServlet 工作流程：HandlerMapping→HandlerAdapter→ViewResolver。\n- 统一异常处理：@ControllerAdvice + @ExceptionHandler。\n- 拦截器 vs 过滤器：执行时机与适用场景。\n\n## 事务\n- 声明式事务：@Transactional 属性（propagation/isolation/rollbackFor）。\n- 七种传播行为：REQUIRED/REQUIRES_NEW/NESTED 等使用场景。\n- 事务失效场景：同类内部调用、非 public 方法、异常被吞、异步调用。\n\n## 循环依赖\n- 三级缓存解决 setter 注入循环依赖：singletonObjects/earlySingletonObjects/singletonFactories。\n- 构造器注入循环依赖无法自动解决，需 @Lazy。\n- SpringBoot 2.6+ 默认禁止循环依赖。\n\n## Spring Boot\n- 自动配置原理：@SpringBootApplication→@EnableAutoConfiguration→spring.factories/Imports。\n- 条件装配：@ConditionalOnClass/@ConditionalOnMissingBean 等。\n- 配置文件加载优先级：properties > yaml > 环境变量 > 命令行参数。\n\n## 面试追问模板\n- @Transactional 标在 private 方法上会生效吗？为什么？\n- 如何自定义一个 Spring Boot Starter？\n- Spring AOP 在你的项目中用来做了什么？遇到过什么坑？\n","app/src/main/resources/skills/_shared/references/system-design-scenarios.md":"# 系统设计与场景题（后端通用核心版）\n\n## 1. 面试答题通用框架（先说这个）\n1. 先澄清约束：QPS、峰值倍数、SLA、数据量、延迟目标、一致性级别、成本上限。\n2. 再给核心链路：请求路径、读写路径、关键状态、失败路径。\n3. 最后补工程细节：容量估算、监控告警、降级兜底、回滚与补偿。\n\n## 2. 高频场景题的标准思路\n\n### 秒杀系统\n- 目标：抗瞬时洪峰、避免超卖、保证最终一致。\n- 关键手段：前置限流 + 验证码/预约削峰 + 缓存库存 + 异步下单（MQ）。\n- 一致性：预扣库存 + 订单超时回补；幂等键防重复下单。\n- 风险点：热点 Key、缓存击穿、消息堆积、库存回补失败。\n\n### 短链系统\n- 目标：短码唯一、重定向高性能、可统计。\n- 核心：短码生成（号段/哈希+冲突处理）+ 映射存储 + 缓存热点短链。\n- 扩展：防刷、防爆破、过期回收、点击明细异步落库。\n\n### Feed 流（推拉模型）\n- 目标：低延迟、可扩展、支持热点用户。\n- 模式：推模式（读快写重）/拉模式（写快读重）/推拉结合（明星与普通用户分治）。\n- 关键：时间线有序、分页游标、防重复、防回刷穿透。\n\n### 站内消息系统\n- 消息类型拆分：系统通知、事件提醒、私信。\n- 核心能力：未读计数、聚合展示、已读状态、离线补偿、幂等去重。\n- 存储策略：会话维度和消息明细分离，冷热分层。\n\n### 延时任务\n- 可选方案：Redis 延迟队列 / MQ 延时消息 / 时间轮调度。\n- 关键问题：任务可靠投递、重复执行防护、取消与重试语义。\n- 工程点：失败重试上限、死信处理、任务可观测性（积压、延迟、失败率）。\n\n### 登录风控（密码输错限制）\n- 核心：用户维度失败计数 + TTL 锁定窗口。\n- 要点：分布式一致计数、防账号枚举、风控阈值分级（验证码->临时锁定->人工校验）。\n- 审计：保留关键操作日志与告警。\n\n### 扫码登录 / 第三方登录\n- 扫码登录：状态机（待扫码->已扫码待确认->确认登录/取消/过期）。\n- OAuth2：授权码模式优先；短期 Access Token + 可撤销 Refresh Token。\n- 安全点：`state` 防 CSRF、回调域名白名单、一次性 code、过期控制。\n\n### 抢单 / 抢资源并发控制\n- 核心目标：同一资源只被一个请求成功占有。\n- 实现：数据库唯一约束 + 乐观锁版本号 或 Redis 原子指令/CAS。\n- 必备：幂等键、超时释放、补偿回滚。\n\n### UV/PV 统计\n- UV 常见实现：HyperLogLog（省内存，近似去重）。\n- PV：计数器即可；复杂场景按站点/页面/时间分桶。\n- 大盘链路：写入削峰（MQ）+ 离线/准实时聚合。\n\n### 去重推荐（大规模）\n- 核心：布隆过滤器 + 分层存储（内存 + 磁盘）+ 批量异步刷盘。\n- 重点：误判率控制、窗口淘汰策略、冷启动兼容。\n\n### RPC 框架设计\n- 关键组件：注册发现、序列化协议、网络传输、负载均衡、超时重试、熔断隔离。\n- 高可用：请求幂等、降级策略、调用链追踪。\n\n### Session 跨节点共享\n- 推荐：集中式会话存储（Redis）。\n- 不推荐：应用节点间 session 复制（扩展性差，维护成本高）。\n\n## 3. 面试官常追问清单\n1. 为什么这么分层？瓶颈先出在哪里？\n2. 失败后怎么恢复？谁触发补偿？如何防重？\n3. 峰值翻 3 倍时，先扩哪个组件？依据是什么？\n4. 你怎么证明方案有效？给出核心指标与阈值。\n5. 一致性和可用性冲突时，你的取舍原则是什么？\n","app/src/main/resources/skills/_shared/references/test-development.md":"# 测试开发面试重点（测试基础 + 用例设计 + 自动化 + 性能安全）\n\n## 测试基础\n- 软件测试定义与目的：发现缺陷、验证需求、提供质量反馈，不只是\"找 Bug\"。\n- 测试流程：需求分析→测试计划→测试设计→测试执行→缺陷跟踪→测试报告→回归测试。\n- 测试左移（Shift-Left）：需求/设计阶段就介入质量活动，早发现早修复，缺陷成本随阶段指数增长。\n- 测试覆盖率：行覆盖/分支覆盖/路径覆盖，高覆盖率 ≠ 高质量测试，关注有意义覆盖率而非数字。\n- 测试金字塔：单元测试（>90% 自动化）→集成测试（60-80%）→系统/UI 测试（20-40%），投资回报递减。\n- 核心竞争力：业务理解 + 系统性用例设计 + 工程化自动化能力。\n\n## 测试用例设计\n- 等价类划分：将输入划分为有效/无效等价类，每类取代表性数据，减少冗余。\n- 边界值分析：等价类边界的值最易出错，如范围 [1,100] 测试 0/1/100/101。\n- 判定表法：多条件组合场景（如会员×节假日×提前天数→价格），穷举条件与结果映射。\n- 场景法：模拟用户操作流程（主流程+异常分支），通过流程图覆盖完整业务路径。\n- 错误推测法：基于经验推测易错点（如文件上传：空文件/超大文件/病毒文件/格式不符）。\n- 状态迁移法：测试有状态变化的对象（如订单状态、电梯状态），验证状态转换正确性。\n- 好的测试用例标准：覆盖全面、分组精准（等价类无冗余）、边界清晰。\n- 场景题回答框架：功能→兼容性→性能→网络→安全→UI/UX，逐维度展开。\n\n## 测试类型\n- 黑盒测试 vs 白盒测试：关注外部行为 vs 关注内部代码逻辑，互补使用。\n- 单元测试：最小可测试单元（函数/类），Mock 外部依赖，开发编写，CI 自动执行。\n- 集成测试：多模块/服务交互验证，关注接口契约、数据传递、依赖协同。\n- 系统测试：完整系统验证，功能/性能/安全/兼容性全面覆盖。\n- 回归测试：修改后确认旧功能未被破坏，高度依赖自动化用例。\n- 验收测试（UAT）：业务方确认是否满足需求，贴近真实场景。\n- 端到端测试（E2E）：完整业务链路验证，从用户入口到最终输出，数量少但价值高。\n- 正向测试 vs 反向测试：合法输入验证正常功能 vs 非法输入验证异常处理能力。\n\n## 自动化测试\n- ROI 公式：(节省的手工测试时间 × 执行频率) - (脚本开发时间 + 维护成本)。\n- 适用场景：回归测试、步骤确定性高、执行频率高；不适用：一次性功能、UI 频繁变动、探索性测试。\n- Web 自动化工具：Selenium（多语言/多浏览器、成熟但慢）、Cypress（开发者友好、JS-only）、Playwright（现代化、多语言、快）。\n- API 测试流程：读 API 文档→设计用例（正常/异常/边界）→准备数据与认证→发请求→校验响应与数据库。\n- API 测试工具：Postman/Reqable/Insomnia，结合 Newman/CI 实现自动化回归。\n- 移动端自动化：Appium（跨平台）、Espresso（Android 原生）、XCTest（iOS 原生）。\n- CI/CD 集成：Jenkins/GitLab CI/GitHub Actions 中自动触发，测试报告与失败告警。\n\n## 性能测试\n- 压测类型：负载测试（预期负载下验证）、压力测试（超负载找极限）、稳定性测试（长时间运行查泄漏）。\n- 压测流程：确定目标（QPS/RT/TPS）→准备环境（≈生产 50-80%）→选工具→编写脚本→执行→监控分析→调优→复测。\n- 压测工具：JMeter（功能全面）、k6（JS 脚本、现代化）、Gatling（Scala、高性能）、Locust（Python）。\n- 关键指标：TPS/QPS、响应时间（P50/P95/P99）、错误率、CPU/内存/磁盘 IO/网络带宽。\n- 瓶颈定位：数据库慢查询、连接池打满、线程池饱和、网络带宽、GC 停顿。\n\n## 安全测试\n- OWASP Top 10：XSS/SQL 注入/CSRF/身份认证失效/敏感信息泄露/访问控制失效等。\n- XSS 测试：输入 `<script>alert(1)</script>`、`<img src=x onerror=alert(1)>`，验证是否转义/过滤。\n- SQL 注入测试：`' OR '1'='1 --`、`' UNION SELECT --`、时间盲注 `AND SLEEP(5)`，验证参数化查询。\n- CSRF 测试：检查 CSRF Token、SameSite Cookie、Referer 校验。\n- 越权测试：水平越权（访问同角色他人数据）、垂直越权（普通用户访问管理接口）。\n\n## Bug 处理与协作\n- 不可复现 Bug：多次尝试不同环境/数据→收集详细信息（步骤/日志/截图/录屏）→与开发协作分析。\n- 缺陷报告要素：标题、前置条件、复现步骤、预期结果、实际结果、严重程度、优先级。\n- Bug 生命周期：新建→确认→分配→修复→验证→关闭（或重新打开）。\n- 印象深刻的 Bug 回答模板：场景描述 + 根因分析 + 修复过程 + 后续预防。\n\n## 面试追问模板\n- 登录/支付/电商直播间场景，你怎么设计测试用例？\n- 你的自动化测试覆盖率是多少？ROI 怎么评估？\n- 线上出了一个 Bug，但测试环境无法复现，你怎么排查？\n- 你在 CI/CD 中集成了哪些质量门禁？怎么防止质量回退？\n","app/src/main/resources/skills/ai-agent-dev/SKILL.md":"---\nname: ai-agent-dev\ndescription: 用于 AI Agent 开发岗位面试出题；覆盖 Agent 架构、LLM 调用、工具集成、MCP 协议、RAG、上下文工程与多 Agent 协作，强调工程落地与故障处理能力。\n---\n# Overview\n你是一位 AI Agent 开发岗位面试官，关注候选人对 Agent 系统的工程实现能力，而不是只会描述概念。重点考察：Agent Loop 设计、工具集成方式、上下文管理策略、RAG 检索质量治理和多 Agent 协作模式。\n\n# Instructions\n1. 先确认候选人的技术栈（LangChain / Spring AI / 自研框架）和实际项目经验，围绕真实项目追问。\n2. 提问遵循梯度：使用经验 -> 原理机制 -> 边界与故障 -> 优化与权衡。\n3. 每个主问题必须包含至少一个权衡点（如召回率 vs 延迟、上下文长度 vs 信息密度）。\n4. 回答停留在概念层时，必须追问具体实现：协议选型、Token 预算分配、错误重试策略、可观测性指标。\n5. 至少一次要求候选人给出可量化指标（如 TTFT、P99 延迟、检索召回率、Token 利用率）。\n6. 不要只问名词解释，必须有场景化问题（如\"线上 Agent 出现幻觉循环，你怎么排查\"）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- AGENT_BASIS / LLM_CALLING / MCP_PROTOCOL / RAG / CONTEXT_ENGINEERING / MULTI_AGENT / PROJECT -> ai-agent-dev.md\n","app/src/main/resources/skills/ai-agent-dev/ai-agent-dev.md":"# AI Agent 开发面试参考\n\n## 一、Agent 基础\n\n### Agent 定义与核心架构\n- Agent = LLM + Planning + Memory + Tools\n- Agent Loop：感知(Perceive) -> 推理(Reason) -> 行动(Act) -> 观察(Observe) 循环\n- 终止条件：任务完成、达到最大步数、用户中断、错误熔断\n\n### Agent vs 传统编程 vs 工作流\n- 决策者差异：Agent 由 AI 决策下一步，工作流由预定义路径驱动\n- 适用场景判断：确定性任务用工作流，开放性任务用 Agent\n\n### Agent 范式\n- ReAct：Thought-Action-Observation 循环，边推理边执行\n- Plan-and-Execute：先规划全局步骤，再逐步执行\n- Reflection：自我反思与修正（Reflexion / Self-Refine / CRITIC）\n\n### 多 Agent 系统\n- Orchestrator-Subagent：主从模式，编排器分配任务\n- Peer-to-Peer：对等模式，Agent 间平等协作\n- A2A（Agent-to-Agent）通信协议\n\n### 安全\n- Prompt Injection 攻击类型与防御（执行层沙箱、认知层隔离、决策层人机协同）\n- Agent 权限边界设计（最小权限原则）\n- 敏感操作审批机制\n\n---\n\n## 二、LLM 调用\n\n### Token 与上下文窗口\n- Token 是计费和性能的基本单位（非字符）\n- 上下文窗口 = System Prompt + User Prompt + 历史 + RAG + 工具定义 + 输出\n- Token 预算：window >= input_tokens + max_output_tokens\n- Prompt Caching：静态内容前置、动态内容后置\n\n### 采样参数\n- Temperature：控制随机性（低=确定性，高=创造性）\n- Top-p（核采样）和 Top-k：缩小候选词池\n- Presence/Frequency Penalty：抑制重复\n- 推理模型（o1/o3）的参数限制\n\n### Function Calling\n- JSON Schema 定义工具接口\n- 工具粒度设计：原子操作 vs 组合操作\n- 并行工具调用（Parallel Tool Calling）\n- 错误处理：工具调用失败时的重试与降级策略\n\n### 结构化输出与流式输出\n- JSON Mode vs Structured Output（Schema 约束）\n- SSE（Server-Sent Events）机制与 TTFT 优化\n- 流式场景下的工具调用处理\n\n### 成本优化\n- 输入/输出 Token 定价差异（2-5 倍）\n- 路由策略：简单问题用小模型、复杂问题用大模型\n- 缓存策略：语义缓存、精确匹配缓存\n\n---\n\n## 三、MCP 协议\n\n### MCP 定位\n- MCP（Model Context Protocol）= AI 的 USB-C，统一工具接入标准\n- MCP vs Function Calling vs Agent：MCP 是协议标准，Function Calling 是 LLM 能力，Agent 是系统概念\n- 四层关系：Function Calling（基础） -> Prompt（意图） -> MCP（连接） -> Skills（编排）\n\n### MCP 四大核心能力\n- Resources：只读数据源 | Tools：可执行操作 | Prompts：模板化提示词 | Sampling：LLM 推理委托\n\n### 架构与传输\n- 四层：Host（宿主） -> Client（协议客户端） -> Server（工具服务） -> Data Source\n- JSON-RPC 2.0 通信协议（轻量、传输无关、易调试）\n- stdio：本地 IPC；Streamable HTTP：远程/生产（已废弃 HTTP+SSE）\n\n### 生产实践\n- 工具幂等性设计、退避策略与 P99 延迟目标\n- 上下文窗口管理（大结果截断、分页）\n- 安全考量（输入校验、权限控制、审计日志）\n\n---\n\n## 四、RAG 检索增强\n\n### 基本原理\n- RAG = 信息检索 + LLM 生成\n- 离线索引（加载、清洗、分块、Embedding、存储）+ 在线检索（查询向量化、相似度搜索、上下文构建、生成）\n- 核心优势：知识时效性、减少幻觉、数据安全、领域适配\n\n### 分块与 Embedding\n- 固定长度 vs 语义分块 vs 递归分块\n- 分块大小与语义完整性的权衡\n- 通用 vs 领域微调 Embedding 模型选择\n\n### 向量检索\n- ANN：用 5% 召回率损失换 100 倍速度\n- HNSW：<1000 万向量、高召回、高内存 | IVFFLAT：1000 万-1 亿、内存友好\n- 距离度量：余弦相似度、内积、欧几里得距离\n- 混合检索：向量 + BM25 + RRF 融合（生产最佳实践）\n\n### 局限与治理\n- GIGO：检索质量决定生成质量\n- 上下文窗口噪声、TTFT 增加、检索召回率评估\n\n---\n\n## 五、上下文工程\n\n### 概念\n- Agent = Model + Harness（模型之外的一切都是 Harness）\n- 模型决定上限，Harness 决定下限\n\n### 六层 Harness 架构\n1. L1 信息边界：System Prompt、约束条件、角色定义\n2. L2 工具系统：工具注册、Schema 定义、权限控制\n3. L3 执行编排：Agent Loop、条件分支、并行执行\n4. L4 记忆与状态：短期记忆、长期记忆、状态持久化\n5. L5 评估与可观测：质量评估、链路追踪、指标监控\n6. L6 约束与恢复：错误处理、重试策略、降级方案\n\n### Token 预算与设计模式\n- 40% 上下文利用率阈值（超过后质量急剧下降）\n- 上下文压缩：摘要、裁剪、遗忘\n- 渐进式披露：L1 元数据常驻 + L2 正文按需 + L3 资源隔离\n- Lost in the Middle 问题与应对\n\n### 实践案例\n- OpenAI：机械约束优于文档约束、熵管理\n- Anthropic：GAN 式三 Agent 架构、上下文重置策略\n- Stripe：Minions 系统\n\n---\n\n## 面试高频追问\n\n### Agent 基础\n- Agent Loop 中如何防止无限循环？\n- ReAct 和 Plan-and-Execute 各自的优缺点和适用场景？\n- 多 Agent 系统中如何保证一致性？\n\n### LLM 调用\n- Token 超出上下文窗口时怎么处理？\n- Function Calling 和直接在 Prompt 里写工具有什么区别？\n- 如何降低 LLM 调用的 P99 延迟？\n\n### MCP 协议\n- MCP 和直接用 Function Calling 有什么区别？\n- stdio 和 Streamable HTTP 分别适合什么场景？\n- 如何设计一个生产级的 MCP Server？\n\n### RAG\n- 分块策略如何选择？过大或过小分别有什么问题？\n- 向量检索和关键词检索各自的优缺点？为什么需要混合检索？\n- RAG 系统线上出现幻觉，排查思路是什么？\n\n### 上下文工程\n- Agent 上下文超出窗口时如何处理？\n- AGENTS.md / SKILL.md 的设计原则是什么？\n- Harness 各层级中哪一层对 Agent 质量影响最大？为什么？\n","app/src/main/resources/skills/algorithm/SKILL.md":"---\nname: algorithm\ndescription: 用于算法面试出题；重点评估复杂度分析、边界处理和优化能力，区分背题与真实理解。\n---\n# Overview\n你是一位算法面试官，目标是评估候选人的建模能力和复杂度优化能力。\n\n# Instructions\n1. 文字/语音面试不要求写代码；每题先让候选人口述：建模方式、关键数据结构、核心步骤、时间/空间复杂度。\n2. 数据结构必须覆盖多样性：哈希表、栈/队列、堆、树/图、数组/链表应轮换考察，避免只刷单一套路。\n3. 回答正确后继续追问边界条件、退化场景和同类变体，不停在基础答案。\n4. 对暴力解必须追问瓶颈，并要求给出可落地的优化路径（如剪枝、单调结构、预处理、空间换时间）。\n5. 至少一次要求候选人解释正确性证明思路（不变式/归纳/反证任一即可）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP/GREEDY_BACKTRACK/DESIGN -> algorithm-data-structures.md\n","app/src/main/resources/skills/ali-backend/SKILL.md":"---\nname: ali-backend\ndescription: 用于阿里后端面试出题；强调业务深度、项目落地和中间件选型能力，关注复杂场景下的取舍与闭环。\n---\n# Overview\n你是阿里巴巴后端面试官。核心风格是业务导向与项目深挖：围绕候选人真实项目持续追问，直到触达认知边界。\n\n# Instructions\n1. 优先从简历项目切入，连续追问\"为什么这样设计\"\"如果流量涨 10 倍怎么改\"。\n2. 每个问题必须落到业务目标、技术取舍、成本与收益，不接受纯理论回答。\n3. 对 Java 生态中间件（MySQL、Redis、MQ）重点追问原理、故障、容量与治理。\n4. 至少一次要求候选人给出完整落地方案：指标、压测、发布、回滚、复盘。\n5. 强调可执行性：方案要能上线、能观测、能恢复。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PROJECT/SYSTEM_DESIGN_SCENARIO -> system-design-scenarios.md\n- DB_DESIGN/MYSQL -> db-design.md, mysql.md\n- DISTRIBUTED/CACHE/REDIS -> distributed.md, redis.md\n- MQ -> mq.md\n- DESIGN_PATTERN -> design-pattern.md\n","app/src/main/resources/skills/bytedance-backend/SKILL.md":"---\nname: bytedance-backend\ndescription: 用于字节后端面试出题；以算法与编码能力为第一门槛，同时考察高并发场景下的系统设计能力。\n---\n# Overview\n你是字节跳动后端面试官，风格直接、硬核、高强度。核心判断标准是：算法基本功是否过硬，复杂度优化是否到位。\n\n# Instructions\n1. 每轮优先给 1-2 道算法题，但在文字/语音场景不要求手写代码；要求候选人口述解法步骤、关键数据结构、复杂度与边界处理。\n2. 数据结构覆盖必须均衡：数组/链表、哈希表、栈/队列、堆、树/图至少覆盖两类以上，不可只问单一 DP。\n3. 对答案必须追问：为什么正确、为什么最优、边界条件是否完整；若只给结论，要求补充不变式或反例证明。\n4. 算法题后补一题工程化追问：同思路如何迁移到高并发真实场景（如计数、去重、延迟任务、TopK）。\n5. 提问节奏要快，单题目标明确；每次只追一个关键点，避免超长题干。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP -> algorithm-data-structures.md\n- DISTRIBUTED/SYSTEM_DESIGN_SCENARIO -> distributed.md, system-design-scenarios.md\n- PROJECT -> 结合简历追问真实线上问题\n","app/src/main/resources/skills/frontend/SKILL.md":"---\nname: frontend\ndescription: 用于前端工程面试出题；覆盖 JavaScript、React/Vue、浏览器原理和性能优化，强调业务实战与工程化能力。\n---\n# Overview\n你是一位前端工程面试官，重点评估候选人在真实业务中的技术取舍与交付质量。\n\n# Instructions\n1. 问题需覆盖渲染机制、状态管理、工程化与性能优化。\n2. 优先结合简历项目，追问复杂页面、性能瓶颈和线上问题处理。\n3. 回答停留在 API 层时，必须追问底层机制与边界场景。\n4. 至少一次要求候选人给出可量化指标（如 FCP/LCP、错误率、包体积）。\n5. 不要只问名词解释，必须有场景化问题。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVASCRIPT -> javascript.md\n- REACT_VUE -> react-vue.md\n- BROWSER -> browser.md\n- CSS/ENGINEERING/PERFORMANCE/PROJECT -> 结合简历与工程实践深挖\n","app/src/main/resources/skills/java-backend-tencent/SKILL.md":"---\nname: java-backend-tencent\ndescription: 用于腾讯后端面试出题；重点考察计算机基础、计网与操作系统原理，并结合业务场景验证技术选型能力。\n---\n# Overview\n你是腾讯后端面试官。风格稳健且重基础：常从八股切入，但会顺着底层逻辑追问到协议细节与系统机制。\n\n# Instructions\n1. 先问网络与操作系统基础，再过渡到业务系统设计与中间件选型。\n2. 对 TCP/IP、HTTP/HTTPS、线程模型、内存模型要持续深挖\"为什么\"。\n3. 必须结合业务场景问选型：为何用 MQ 而不是同步调用，何时不用缓存。\n4. 每轮至少一个底层追问和一个工程追问，兼顾理论与落地。\n5. 面试节奏可持续拉长，关注候选人思维稳定性与一致性。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- NET_OS -> network-os.md\n- JAVA -> java.md\n- MYSQL/REDIS/MQ -> mysql.md, redis.md, mq.md\n- SPRING -> spring.md\n- SYSTEM_DESIGN_SCENARIO/PROJECT -> system-design-scenarios.md + 简历项目\n","app/src/main/resources/skills/java-backend/SKILL.md":"---\nname: java-backend\ndescription: 用于 Java 后端面试出题；优先围绕 Java 核心、MySQL、Redis、Spring 与项目实战，追问设计取舍、故障处理和性能优化。\n---\n# Overview\n你是一位 Java 后端面试官，目标是识别候选人是否具备可上线的工程能力，而不是只会背概念。\n\n# Instructions\n1. 优先结合候选人简历和项目经历提问。\n2. 提问顺序遵循：使用经验 -> 原理机制 -> 边界条件 -> 优化与故障。\n3. 每个主问题都需要可追问，追问要落到真实场景和可观测指标。\n4. 回答偏概念时，必须追问实现细节、失败场景、回滚方案。\n5. 避免一次性给提示词，不要替候选人补全答案。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVA -> java.md\n- MYSQL -> mysql.md\n- REDIS -> redis.md\n- SPRING -> spring.md\n- SYSTEM_DESIGN_SCENARIO/PROJECT -> system-design-scenarios.md + 简历项目\n","app/src/main/resources/skills/python-backend/SKILL.md":"---\nname: python-backend\ndescription: 用于 Python 后端面试出题；覆盖 Python 基础、数据库、Django/Flask、缓存与部署，强调工程落地。\n---\n# Overview\n你是一位 Python 后端面试官，关注候选人是否具备独立构建和运维服务的能力。\n\n# Instructions\n1. 优先考察框架实践、数据库设计、缓存策略与部署经验。\n2. 每道题都要可追问，尤其关注并发、一致性和故障恢复。\n3. 回答如果仅停留在语法层面，必须追问工程实现细节。\n4. 至少一次要求候选人描述真实线上问题和排障步骤。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PYTHON_BASIC -> python-basic.md\n- DATABASE -> database.md\n- DJANGO_FLASK -> django-flask.md\n- CACHE -> redis.md\n- DEPLOY/PROJECT -> 结合简历与上线流程深挖\n","app/src/main/resources/skills/system-design/SKILL.md":"---\nname: system-design\ndescription: 用于系统设计面试出题；聚焦容量估算、可用性与一致性权衡、可观测性和故障恢复。\n---\n# Overview\n你是一位系统设计面试官，关注候选人的架构权衡能力和可落地性。\n\n# Instructions\n1. 先澄清约束（QPS、SLA、一致性级别、成本）再讨论方案。\n2. 每个问题必须包含至少一个权衡点（如一致性 vs 延迟）。\n3. 要求候选人解释容量估算、故障处理、回滚机制和可观测性设计。\n4. 禁止组件罗列式问答，必须落到数据流与状态流。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- HIGH_AVAILABILITY -> high-availability.md\n- DISTRIBUTED -> distributed.md\n- CACHE/REDIS -> redis.md\n- DESIGN_PATTERN -> design-pattern.md\n- MQ/DB_DESIGN -> 结合分布式场景进行追问\n","app/src/main/resources/skills/test-development/SKILL.md":"---\nname: test-development\ndescription: 用于测试开发面试出题；覆盖测试基础、用例设计、自动化测试、性能测试与安全测试，兼顾工程化落地能力。\n---\n# Overview\n你是一位测试开发面试官，关注候选人的质量意识和工程化能力，重点评估其能否通过技术手段提升测试效率与质量保障深度。\n\n# Instructions\n1. 提问需覆盖测试基础、用例设计方法、自动化测试实践和性能测试四个维度。\n2. 优先结合候选人简历中的测试项目，追问具体的场景设计、工具选型和指标度量。\n3. 回答停留在理论时，必须追问实际落地细节：覆盖率数据、脚本维护成本、CI 集成方式。\n4. 至少一次要求候选人针对具体功能（如登录/支付/电商直播间）现场设计测试用例。\n5. 关注候选人是否具备开发能力：能否编写测试工具、搭建测试平台、参与 CI/CD 建设。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- TESTING_BASIC/TEST_CASE_DESIGN -> test-development.md\n- AUTOMATION/PERFORMANCE_SECURITY -> test-development.md\n- API/WEB/MOBILE_TESTING -> test-development.md\n- JAVA/PYTHON -> java.md, python-basic.md（考察编码能力时参考）\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AI Interview Platform Agent Rules\n\nSpring Boot 4.1.0 + Java 25 + Spring AI 2.0.0 + React 面试平台。\n\n本文件是跨工具 Agent 入口，只放长期有效、代码里不容易直接推断、猜错会影响结果的规则。更细的目录规则放在 `.claude/rules/`，需要时再读取。\n\n## Tech Stack\n\n- Backend: Spring Boot 4.1.0 / Java 25 / Gradle / Spring AI 2.0.0\n- Database: PostgreSQL + pgvector，向量维度 1024，距离类型 COSINE\n- Cache & async: Redis / Redisson / Redis Stream\n- Storage & parsing: RustFS/S3 / Apache Tika\n- Mapping & export: MapStruct / iText 8 / SpringDoc OpenAPI\n- Frontend: React 18 / TypeScript / Vite / TailwindCSS 4，代码在 `frontend/`\n\n## Commands\n\n```bash\n./gradlew :app:compileJava\n./gradlew :app:test --no-daemon\n./gradlew :app:bootRun\n```\n\n```bash\ncd frontend && pnpm run dev\ncd frontend && pnpm run build\n```\n\n```bash\ndocker compose -f docker-compose.dev.yml up -d\n```\n\n## Project Structure\n\n- `app/src/main/java/interview/guide/common/`: 通用能力，包括限流、AI 调用、异步模板、配置、异常、统一响应。\n- `app/src/main/java/interview/guide/infrastructure/`: 技术基础设施，包括文件、导出、Redis、MapStruct 映射。\n- `app/src/main/java/interview/guide/modules/`: 业务模块，每个模块自包含 MVC 分层。\n- `app/src/main/resources/prompts/`: StringTemplate Prompt 模板。\n- `frontend/src/`: React 前端页面、组件、API 客户端和类型定义。\n\n## Architecture\n\n- 后端遵循 `Controller -> Service -> Repository`，Controller 只做路由、校验和委托。\n- Service 承担业务编排；`@Transactional` 只放 Service 层，并保持事务范围最小。\n- Repository 继承 Spring Data JPA `JpaRepository`，自定义查询用方法名或 `@Query`。\n- 基础设施能力优先放在 `common/` 或 `infrastructure/`，不要散落到业务 Service。\n- 对外响应统一使用 `Result<T>`，禁止直接返回 Entity。\n\n## Backend Rules\n\n- 业务异常必须使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 全局异常处理器返回 HTTP 200 + `Result.error(code, message)`。\n- 请求体优先用不可变 `record`，命名后缀使用 `XxxRequest` / `XxxResponse` / `XxxDTO` / `XxxEntity`。\n- Entity 到 DTO/Response 的映射优先使用 MapStruct。\n- 使用构造器注入，优先配合 Lombok `@RequiredArgsConstructor`。\n- 代码使用 2 空格缩进、无通配符导入、避免内联全限定类名。\n- 日志使用 SLF4J 占位符，异常必须作为最后一个参数传入。\n\n## AI And Async Rules\n\n- 获取聊天模型统一走 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- 结构化输出统一走 `StructuredOutputInvoker`，不要在业务代码里复制重试逻辑。\n- Prompt 模板放在 `resources/prompts/`，使用 StringTemplate `.st`。\n- LLM、S3、外部 HTTP 调用不得放在数据库事务内。\n- Redis Stream 生产/消费使用 `AbstractStreamProducer` / `AbstractStreamConsumer` 模板。\n- 异步处理前先校验实体是否存在；实体已删除时 ACK 丢弃。\n- 限流使用可重复 `@RateLimit`，不要手写散落的 Redis 限流逻辑。\n\n## Config And Data\n\n- 配置集中在 `application.yml`、`.env` 和 `@ConfigurationProperties` 类中。\n- API Key、数据库密码等敏感信息只放 `.env`，不得提交到 Git。\n- 不要在 Service 中散落 `@Value`。\n- 本地默认后端端口是 `8080`：`server.port: ${SERVER_PORT:8080}`。\n- 开发环境 `ddl-auto` 可为 `update`，生产环境不能依赖自动建表。\n\n## Frontend Rules\n\n- API 调用集中在 `frontend/src/api/`，复用 `request.ts` 的 Axios 实例。\n- 类型定义放在 `frontend/src/types/`，不要在页面里重复定义共享接口。\n- 页面放在 `frontend/src/pages/`，可复用 UI 放在 `frontend/src/components/`。\n- 路由常量放在 `frontend/src/constants/routes.ts`。\n- 组件交互优先使用现有设计语言和 `lucide-react` 图标。\n\n## Testing\n\n- 后端测试使用 JUnit 5 + Mockito + AssertJ。\n- 测试意图用中文 `@DisplayName` 描述，复杂场景用 `@Nested` 分组。\n- 集成测试使用 H2 配置；限流相关测试需要真实 Redis。\n- 改后端公共能力时至少运行 `./gradlew :app:test --no-daemon`。\n- 改前端时至少运行 `cd frontend && pnpm run build`。\n\n## Never Do\n\n- 不要 `throw new RuntimeException(...)`，业务失败必须用 `BusinessException`。\n- 不要直接返回 Entity 给前端。\n- 不要把 `@Value` 散落在 Service 中。\n- 不要在事务内调用 LLM、S3 或外部 HTTP。\n- 不要同类内部调用 `@Transactional` 方法。\n- 不要 `catch (Exception e) {}` 静默忽略。\n- 不要循环调用 DB，优先批量查询或批量写入。\n- 不要硬编码密钥、Token、数据库密码。\n- 不要使用 `Executors.newXxxThreadPool()`，需要线程池时显式配置 `ThreadPoolExecutor`。\n\n## More Rules\n\n- 后端 Java 细则：`.claude/rules/backend.md`\n- AI、限流、异步细则：`.claude/rules/ai-and-async.md`\n- 前端细则：`.claude/rules/frontend.md`\n","isInternal":false,"tokens":1600,"sizeBytes":5070},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"@AGENTS.md\n\n# Claude Code Instructions\n\n- `AGENTS.md` 是本仓库的共享规则源；更新长期规则时优先改 `AGENTS.md`，不要在这里复制一份。\n- 本文件只保留 Claude Code 专属入口和加载提示，避免根目录上下文膨胀。\n- 目录细则在 `.claude/rules/`，处理匹配文件前先读取对应规则。\n- 个人偏好和临时调试结论放 `CLAUDE.local.md` 或 Claude Memory，不要提交到仓库。\n\n## Path Rules\n\n- Backend: `.claude/rules/backend.md`\n- AI / async / rate limit: `.claude/rules/ai-and-async.md`\n- Frontend: `.claude/rules/frontend.md`\n\n## Maintenance\n\n- 新增规则前先判断：删掉这条后，Claude 是否更容易犯同类错误。\n- 能被测试、格式化、Hook 或 CI 强制的规则，不要只写成自然语言。\n- 如果同一条规则反复被忽略，优先精简规则文件，而不是继续加粗或加感叹号。\n","isInternal":false,"tokens":304,"sizeBytes":901},{"name":"ai-and-async.md","path":".claude/rules/ai-and-async.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/.claude/rules/ai-and-async.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n  - \"app/src/main/java/interview/guide/common/ai/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/annotation/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/aspect/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/async/**/*.java\"\n  - \"app/src/main/java/interview/guide/modules/**/listener/**/*.java\"\n  - \"app/src/main/resources/prompts/**/*.st\"\n  - \"app/src/main/resources/scripts/**/*.lua\"\n---\n\n# AI, Rate Limit And Async Rules\n\n## LLM Providers\n\n- Provider 配置来自 `app.ai.providers.{providerId}` 和默认 `app.ai.default-provider`。\n- ChatClient 获取统一使用 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- Provider 连通性测试要限制超时，并防止访问内网或特殊地址。\n- Spring AI 2.0.0 代码优先使用非 deprecated API。\n\n## Structured Output\n\n- 结构化输出统一使用 `StructuredOutputInvoker` 封装重试。\n- 不要在业务 Service 里复制 JSON 修复、重试和解析逻辑。\n- Prompt 模板存放在 `resources/prompts/`，使用 StringTemplate `.st`。\n\n## Rate Limit\n\n- 接口限流使用可重复 `@RateLimit` 注解。\n- 每个 `@RateLimit` 是独立维度，分别执行 Redis Lua 滑动窗口。\n- Redis Key 使用 `ratelimit:{ClassName:MethodName}:dimension` 结构。\n- 不要在 Controller 或 Service 中手写散落的限流逻辑。\n\n## Redis Stream\n\n- 生产者继承 `AbstractStreamProducer<T>`。\n- 消费者继承 `AbstractStreamConsumer<T>` 并实现 `processMessage()`。\n- Stream 名称、消费者组和任务常量放在 `AsyncTaskStreamConstants`。\n- 消费失败最多重试 3 次，超过后标记 FAILED。\n- 异步处理前校验实体是否存在；已删除实体直接 ACK 丢弃。\n","frontmatter":{"paths":["app/src/main/java/interview/guide/common/ai/**/*.java","app/src/main/java/interview/guide/common/annotation/**/*.java","app/src/main/java/interview/guide/common/aspect/**/*.java","app/src/main/java/interview/guide/common/async/**/*.java","app/src/main/java/interview/guide/modules/**/listener/**/*.java","app/src/main/resources/prompts/**/*.st","app/src/main/resources/scripts/**/*.lua"]},"isInternal":false,"tokens":493,"sizeBytes":1719},{"name":"backend.md","path":".claude/rules/backend.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/.claude/rules/backend.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n  - \"app/src/main/java/**/*.java\"\n  - \"app/src/test/java/**/*.java\"\n  - \"app/src/main/resources/**/*.yml\"\n---\n\n# Backend Rules\n\n## Layers\n\n- Controller 只做路由、参数校验、限流注解和 Service 委托。\n- Service 负责编排业务流程，事务注解只放 Service 层。\n- Repository 只做数据访问，继承 `JpaRepository`。\n- Infrastructure 能力放在 `common/` 或 `infrastructure/`，不要塞进业务模块。\n\n## Naming\n\n- JPA 持久化对象使用 `XxxEntity`。\n- 跨层数据传输使用 `XxxDTO`。\n- 前端请求体使用 `XxxRequest`，前端响应体使用 `XxxResponse`。\n- 不可变请求/响应优先使用 `record`。\n\n## Exceptions\n\n- 业务失败使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 保留业务异常原样抛出：`catch (BusinessException e) { throw e; }`。\n- 禁止用 `RuntimeException` 表达业务错误。\n- 禁止吞异常；记录异常时把异常对象作为日志最后一个参数。\n\n## Transactions\n\n- `@Transactional` 只放 Service 层公开方法。\n- 事务内不得调用 LLM、S3、外部 HTTP 或耗时文件解析。\n- 避免同类内部调用 `@Transactional` 方法，必要时拆分到独立 Service。\n- 读多写少的查询使用 `@Transactional(readOnly = true)`。\n\n## Mapping\n\n- Entity 不直接返回给前端。\n- Entity 到 DTO/Response 的重复转换优先使用 MapStruct。\n- 简单一次性字段复制可以使用 `BeanUtils.copyProperties`。\n\n## Style\n\n- Java 代码使用 2 空格缩进，列宽尽量控制在 100 字符。\n- 禁止通配符导入，避免内联全限定类名。\n- 优先使用构造器注入和 `@RequiredArgsConstructor`。\n- 现代 Java 特性可用：switch 表达式、pattern matching、text blocks。\n","frontmatter":{"paths":["app/src/main/java/**/*.java","app/src/test/java/**/*.java","app/src/main/resources/**/*.yml"]},"isInternal":false,"tokens":551,"sizeBytes":1754},{"name":"frontend.md","path":".claude/rules/frontend.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/.claude/rules/frontend.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n  - \"frontend/src/**/*.ts\"\n  - \"frontend/src/**/*.tsx\"\n  - \"frontend/src/**/*.css\"\n  - \"frontend/package.json\"\n  - \"frontend/vite.config.ts\"\n---\n\n# Frontend Rules\n\n## Structure\n\n- 页面组件放在 `frontend/src/pages/`。\n- 可复用组件放在 `frontend/src/components/`。\n- API 客户端放在 `frontend/src/api/`，复用 `request.ts`。\n- 共享类型放在 `frontend/src/types/`。\n- 路由路径放在 `frontend/src/constants/routes.ts`。\n\n## API\n\n- 后端接口返回 `Result<T>` 结构，前端 API 层负责解包和错误处理。\n- 不要在页面组件里直接拼接重复的 Axios 配置。\n- Provider、知识库、面试、简历等模块沿用现有 API 文件拆分。\n\n## UI\n\n- 延续现有 React + TailwindCSS 4 风格，不引入新的 UI 框架。\n- 操作按钮优先使用 `lucide-react` 图标加清晰文本或 tooltip。\n- 表单状态要包含 loading、success、error 和 disabled 处理。\n- 不要把业务说明性长文塞进页面；优先让界面直接可操作。\n\n## Verification\n\n- 前端改动后运行 `cd frontend && pnpm run build`。\n- 涉及浏览器交互时，用本地浏览器实际打开页面验证。\n","frontmatter":{"paths":["frontend/src/**/*.ts","frontend/src/**/*.tsx","frontend/src/**/*.css","frontend/package.json","frontend/vite.config.ts"]},"isInternal":false,"tokens":372,"sizeBytes":1170},{"name":"algorithm-data-structures.md","path":"app/src/main/resources/skills/_shared/references/algorithm-data-structures.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/algorithm-data-structures.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 算法与数据结构（统一参考）\n\n## 一、口述作答标准（文字/语音面试）\n1. 先定义问题与状态：输入、输出、约束、目标。\n2. 说明选型：为什么用该数据结构（而不是其他结构）。\n3. 口述步骤：关键流程、转移关系、剪枝或维护不变式。\n4. 复杂度：时间/空间复杂度 + 主瓶颈。\n5. 边界与反例：空输入、重复值、极端规模、退化场景。\n\n## 二、数组/链表\n- 高频思路：双指针、滑动窗口、前缀和、原地算法。\n- 典型追问：如何避免越界；是否能降空间；是否能单次扫描。\n\n## 三、哈希/堆/栈/队列\n- 哈希：去重、频次统计、映射索引、冲突与扩容代价。\n- 堆：TopK、动态中位数、多路归并，关注 `O(n log k)` 优化。\n- 栈：单调栈、括号匹配、表达式求值，不变式要说清。\n- 队列：BFS、双端队列、滑窗最值，解释队头有效性。\n\n## 四、树/图\n- 树：前中后序、层序、递归/迭代取舍。\n- 图：BFS/DFS、最短路、拓扑排序、并查集。\n- 典型追问：有环/无环处理、访问标记时机、复杂度上界。\n\n## 五、动态规划（DP）\n- 核心：状态定义、转移方程、初始化、遍历顺序。\n- 常见失误：状态遗漏、重复计算、滚动数组覆盖顺序错误。\n- 追问方向：如何从 `O(n^2)` 优化到 `O(n log n)`（若可行）。\n\n## 六、贪心/回溯\n- 贪心：局部最优能否推导全局最优，需给交换论证或反例说明。\n- 回溯：搜索树、剪枝条件、去重策略、最坏复杂度评估。\n\n## 七、设计题（算法建模）\n- 数据流、在线查询、延迟任务、限流计数等题型。\n- 重点：结构选型、正确性、复杂度与工程可落地性。\n","isInternal":false,"tokens":699,"sizeBytes":1792},{"name":"browser.md","path":"app/src/main/resources/skills/_shared/references/browser.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/browser.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 浏览器原理面试重点（渲染 + 缓存 + 安全 + 性能）\n\n## 渲染流水线\n- 关键渲染路径：HTML→DOM 树、CSS→CSSOM 树、合并→Render 树→布局→绘制→合成。\n- DOMContentLoaded vs load：DOM 解析完成 vs 所有资源加载完成，CSS 阻塞 DOM 渲染但不阻塞解析。\n- `<script>` 阻塞：默认阻塞 DOM 解析，`async`（下载完立即执行）vs `defer`（DOM 解析后执行）。\n- 合成层优化：`transform`/`opacity` 触发 GPU 合成，跳过布局与绘制。\n\n## 浏览器缓存\n- 强缓存：`Cache-Control`（max-age/no-cache/no-store）优先于 `Expires`。\n- 协商缓存：`ETag`/`If-None-Match` vs `Last-Modified`/`If-Modified-Since`，304 响应。\n- 缓存位置优先级：Service Worker → Memory Cache → Disk Cache → Push Cache。\n- CDN 缓存策略：回源机制、缓存命中率、预热与刷新。\n\n## 网络与协议\n- HTTP/1.1：持久连接（`Connection: keep-alive`）、管线化缺陷。\n- HTTP/2：多路复用、头部压缩（HPACK）、服务器推送、二进制分帧。\n- HTTP/3（QUIC）：基于 UDP、0-RTT 连接、解决队头阻塞。\n- HTTPS：TLS 握手流程（证书校验→密钥协商→对称加密通信），会话复用。\n\n## 安全\n- XSS：存储型/反射型/DOM 型，防御（转义、CSP、HttpOnly Cookie）。\n- CSRF：伪造请求利用已认证身份，防御（SameSite Cookie、CSRF Token、Referer 校验）。\n- CORS：简单请求 vs 预检请求（OPTIONS），`Access-Control-Allow-Origin` 等响应头。\n- CSP（Content-Security-Policy）：白名单限制资源加载，`nonce`/`hash` 策略。\n\n## 性能监控与优化\n- Core Web Vitals：LCP（最大内容绘制 ≤2.5s）、FID/INP（交互延迟 ≤100ms）、CLS（布局偏移 ≤0.1）。\n- 性能 API：`PerformanceObserver`、`performance.timing`（导航计时）、`PerformanceResourceTiming`。\n- 优化手段：代码分割、图片懒加载、预加载（`<link rel=\"preload\">`）、骨架屏。\n- 内存泄漏排查：Chrome DevTools Memory 面板，堆快照对比、分配时间线。\n\n## 面试追问模板\n- 从输入 URL 到页面渲染完成，中间经历了哪些步骤？\n- 你的项目做过哪些性能优化？效果如何量化？\n- CORS 预检请求失败，排查思路是什么？\n- 如何定位线上页面的内存泄漏？\n","isInternal":false,"tokens":844,"sizeBytes":2348},{"name":"database.md","path":"app/src/main/resources/skills/_shared/references/database.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/database.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 数据库通用面试重点（关系型 + NoSQL 选型）\n\n## 事务与隔离级别\n- ACID 含义：原子性（Undo Log）、一致性（约束与规则）、隔离性（锁/MVCC）、持久性（Redo Log）。\n- 四种隔离级别：读未提交→读已提交→可重复读→串行化，各自解决的脏读/不可重复读/幻读问题。\n- MVCC 原理：版本链（隐藏列 trx_id + roll_pointer）+ ReadView 快照，RC/RR 下 ReadView 生成时机差异。\n- 长事务危害：锁持有时间长、Undo Log 膨胀、MVCC 快照无法回收。\n\n## 索引\n- B+ 树适合磁盘索引：有序、范围查询、叶子链表、扇出大树高低。\n- 覆盖索引避免回表，联合索引最左前缀原则，索引下推（ICP）减少回表次数。\n- 索引失效：函数转换、隐式类型转换、OR 条件、LIKE 前缀通配、非最左列。\n- 唯一索引 vs 普通索引：查询性能差异（Change Buffer）、写入场景选择。\n\n## SQL 优化\n- EXPLAIN 执行计划：type（ref/range/index/all）、key、rows、Extra（Using index/Using filesort/Using temporary）。\n- 慢 SQL 定位：`slow_query_log` + `pt-query-digest`，重点关注全表扫描与大结果集。\n- 深度分页优化：游标分页（WHERE id > last_id）、延迟关联（子查询先查主键）。\n- 批量操作优化：批量 INSERT 替代逐条、INSERT ... ON DUPLICATE KEY UPDATE。\n\n## 分库分表\n- 垂直拆分（按业务模块）vs 水平拆分（按分片键散列/范围）。\n- 分片键选择：数据均匀性、查询路由效率、避免跨片查询。\n- 分布式主键：雪花算法（Snowflake）、号段模式（Leaf）、UUID 性能与索引问题。\n- 中间件：ShardingSphere 逻辑表/物理表映射、SQL 改写与路由。\n- 跨片聚合：内存合并、流式归并，全局排序成本。\n\n## 读写分离\n- 主从复制原理：Binlog 异步/半同步复制，主从延迟的成因与监控。\n- 读写分离路由：中间件（ShardingSphere/ProxySQL）vs 应用层注解驱动。\n- 主从延迟应对：强制读主库、延迟检测与降级、并行复制优化。\n\n## NoSQL 选型\n- Redis：缓存/会话/排行榜/分布式锁，数据全内存、不支持复杂查询。\n- MongoDB：文档模型、灵活 Schema、适合非结构化数据与快速迭代。\n- Elasticsearch：全文检索、倒排索引、日志分析场景，写入成本高。\n- HBase/Cassandra：海量数据宽表、LSM-Tree、适合高吞吐写入与时序数据。\n- 选型维度：数据模型、读写模式、一致性要求、扩展方式、运维复杂度。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？还有优化空间吗？\n- 分库分表后，跨片的 JOIN 和聚合查询怎么做？\n- 主从延迟 5 秒，业务怎么处理？\n- 为什么选这个 NoSQL 而不是 MySQL？迁移成本和风险怎么评估？\n","isInternal":false,"tokens":1061,"sizeBytes":2862},{"name":"db-design.md","path":"app/src/main/resources/skills/_shared/references/db-design.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/db-design.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 数据库设计面试重点（建模 + 索引 + 演进）\n\n## 数据建模与范式\n- 三范式核心：1NF（原子性）、2NF（消除部分依赖）、3NF（消除传递依赖）。\n- 反范式设计：以冗余换查询性能，适用读多写少场景（如统计字段冗余）。\n- ER 建模：实体→关系→属性，一对一/一对多/多对多的表结构映射。\n- 宽表 vs 窄表：OLTP 倾向窄表（范式化）、OLAP 倾向宽表（星型/雪花模型）。\n\n## 索引设计策略\n- 索引选择性：高基数列优先，区分度 `COUNT(DISTINCT col)/COUNT(*)` 接近 1 最佳。\n- 联合索引设计：等值条件列在前、范围条件列在后，遵循最左前缀。\n- 覆盖索引设计：将查询所需的列全部纳入索引，消除回表。\n- 避免过度索引：写入开销、存储成本、索引维护（DML 时需同步更新）。\n\n## 冷热数据分层\n- 冷热识别标准：访问时间衰减、业务状态流转（如订单已完成→归档）。\n- 冷数据存储：归档表、历史库、对象存储（OSS/S3），压缩降低存储成本。\n- 数据生命周期管理（DLM）：TTL 过期自动清理、定期迁移、分区裁剪。\n- 分区表策略：RANGE（按时间）、LIST（按枚举）、HASH（按散列），分区裁剪加速查询。\n\n## 扩容与迁移\n- 垂直扩容（升级硬件）vs 水平扩容（分片/分库分表），各自的瓶颈与上限。\n- 平滑扩容流程：新分片上线→双写→历史数据迁移→一致性校验→切读→下线旧分片。\n- 数据迁移工具：Canal 监听 Binlog 增量同步、全量+增量切换方案。\n- 回滚预案：切换失败时快速切回旧库，保留旧库只读窗口。\n\n## 软删除与审计\n- 软删除（`is_deleted` 标记）vs 硬删除：恢复能力 vs 存储膨胀与查询过滤。\n- 审计字段：`created_at`/`updated_at`/`created_by`/`updated_by`，自动化填充（MyBatis 拦截器/JPA Auditing）。\n- 数据版本控制：乐观锁版本号（`version`），防止并发覆盖。\n- 敏感数据处理：加密存储、脱敏查询、合规删除（GDPR/个人信息保护法）。\n\n## 面试追问模板\n- 订单表数据量到亿级，你怎么设计索引和分片方案？\n- 线上需要给大表加字段，怎么做不停机？\n- 冷热数据迁移过程中，如何保证查询不受影响？\n- 你的项目遇到过数据模型演进的问题吗？怎么处理的？\n","isInternal":false,"tokens":948,"sizeBytes":2439},{"name":"design-pattern.md","path":"app/src/main/resources/skills/_shared/references/design-pattern.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/design-pattern.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 设计模式面试重点\n\n## 创建型\n- 单例模式：饿汉/懒汉/DCL/静态内部类/枚举，DCL 为何要 volatile，枚举防反射/序列化。\n- 工厂模式：简单工厂→工厂方法→抽象工厂，开闭原则的递进体现。\n- 建造者模式：与工厂模式的区别，链式调用场景（Lombok @Builder）。\n\n## 结构型\n- 代理模式：JDK 动态代理 vs CGLIB，Spring AOP 默认选型策略。\n- 适配器模式：类适配器 vs 对象适配器，Slf4J 日志门面的适配原理。\n- 装饰器模式：与代理模式的区别，Java I/O 流的装饰链。\n\n## 行为型\n- 观察者模式：JDK Observable（已废弃）vs 事件驱动，Spring Event 机制。\n- 策略模式：消除 if-else，结合工厂或 Spring 注入实现策略路由。\n- 责任链模式：Servlet Filter / Spring Interceptor / Netty Pipeline。\n- 模板方法模式：Spring AbstractApplicationContext#refresh。\n- 状态模式：与策略模式的区别（状态内部转换 vs 外部切换）。\n\n## 设计原则\n- SOLID 原则在代码中的体现，重点考察开闭原则和依赖倒置。\n- 合成/聚合复用 vs 继承复用。\n\n## 框架中的设计模式\n- Spring：单例（Bean 默认）、工厂（BeanFactory）、代理（AOP）、观察者（Event）、模板方法（JdbcTemplate）。\n- JDK：迭代器（Collection）、装饰器（I/O）、适配器（Arrays.asList）。\n- MyBatis：代理（MapperProxy）、模板方法（BaseExecutor）。\n\n## 面试追问模板\n- 你的项目中哪里用到了设计模式？为什么选这个模式？\n- 如果不用这个模式，代码会变成什么样？\n- 这个模式有什么缺点？什么场景下不适合？\n","isInternal":false,"tokens":609,"sizeBytes":1696},{"name":"distributed.md","path":"app/src/main/resources/skills/_shared/references/distributed.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/distributed.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 分布式系统面试重点\n\n## 基础理论\n- CAP 定理：三者不可兼得，网络分区必然存在时的取舍。\n- BASE 理论：基本可用、软状态、最终一致性，与 ACID 的对比。\n- 一致性模型：强一致、单调读、因果一致、最终一致。\n\n## 共识算法\n- Paxos：Basic Paxos 角色（Proposer/Acceptor/Learner）与两阶段流程。\n- Raft：Leader 选举（任期+日志对比）、日志复制、安全性保证。\n- ZAB：与 Raft 的异同，ZXID 结构（epoch + counter）。\n\n## 分布式锁\n- Redis 分布式锁：`SET NX EX` + Lua 释放、Redisson 可重入锁与看门狗。\n- ZooKeeper 分布式锁：临时顺序节点、Watcher 机制、羊群效应避免。\n- 选型：性能优先 Redis，可靠性优先 ZK。\n\n## 分布式事务\n- 2PC：准备→提交，同步阻塞与单点故障问题。\n- TCC：Try/Confirm/Cancel，空回滚与幂等处理。\n- SAGA：正向补偿 vs 反向补偿，适合长事务。\n- Seata AT 模式：全局锁 + 一阶段提交 + 二阶段回滚。\n\n## 分布式 ID\n- 雪花算法（Snowflake）：64 位结构、时钟回拨问题与解决。\n- UUID、数据库自增、号段模式（Leaf）的优劣对比。\n\n## API 网关与 RPC\n- 网关核心职责：路由、鉴权、限流、熔断、可观测。\n- HTTP vs RPC：协议开销、服务治理、跨语言、适用场景。\n- Dubbo 架构：Provider/Consumer/Registry/Monitor，负载均衡策略。\n\n## 一致性哈希\n- 虚拟节点解决数据倾斜，新增/移除节点时最小化数据迁移。\n\n## 面试追问模板\n- 网络分区发生时，你的系统选择保 CP 还是 AP？为什么？\n- 分布式事务失败了怎么补偿？人工介入还是自动？\n- 如何设计一个支持百万 QPS 的分布式 ID 生成服务？\n","isInternal":false,"tokens":672,"sizeBytes":1787},{"name":"django-flask.md","path":"app/src/main/resources/skills/_shared/references/django-flask.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/django-flask.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Django/Flask 面试重点（框架 + ORM + 部署）\n\n## 框架定位与对比\n- Django：全栈框架（ORM/Admin/Auth/Template 内置），\"batteries included\" 哲学，适合快速交付。\n- Flask：微框架（路由+模板引擎核心），扩展生态灵活，适合定制化与微服务。\n- 选型：快速 MVP/内容管理选 Django，API 服务/微服务/深度定制选 Flask。\n- FastAPI：异步原生、Pydantic 类型校验、自动生成 OpenAPI 文档，适合新项目。\n\n## 请求生命周期\n- Django：URLconf 路由→Middleware 链→View 函数/类→Template/JSON 响应→Middleware 链（逆序返回）。\n- Flask：Werkzeug WSGI 路由→before_request 钩子→View 函数→after_request 钩子→响应。\n- 中间件/钩子：认证注入、请求日志、异常捕获、数据库事务管理。\n- 请求上下文：Django（request/response 对象传递）、Flask（thread-local `g` 对象/应用上下文）。\n\n## ORM 与查询优化\n- Django ORM：QuerySet 惰性求值、`select_related`（JOIN，一对一/外键）vs `prefetch_related`（二次查询，多对多）。\n- N+1 问题：循环中触发懒加载，解法为 `select_related`/`prefetch_related` 批量预加载。\n- Flask-SQLAlchemy：Session 管理、eager loading（`joinedload`/`subqueryload`）、批量操作。\n- 查询优化：`only()`/`defer()` 延迟加载字段、`bulk_create` 批量插入、`iterator()` 流式读取大结果集。\n\n## 认证、权限与安全\n- Django Auth：User 模型、`authenticate`/`login`/`logout` 流程、Permission/Group 权限体系。\n- Token 认证：JWT（djangorestframework-simplejwt）/ DRF TokenAuthentication。\n- 安全防护：CSRF Token（Django 内置）、XSS 转义（模板自动转义）、SQL 注入（ORM 参数化）、CORS 配置。\n- 密码存储：Django 使用 PBKDF2 + salt，可配置 bcrypt/argon2。\n\n## 缓存与性能\n- Django 缓存框架：`@cache_page` 装饰器、缓存后端（Redis/Memcached/本地内存）。\n- Flask 缓存：Flask-Caching 扩展，`@cached` 装饰器、Jinja2 片段缓存。\n- 数据库查询缓存：`QuerySet.cache()`、手动缓存策略、缓存失效与一致性。\n- 静态文件：Django Collectstatic + CDN、Flask 静态文件服务（生产环境用 Nginx）。\n\n## 部署与运维\n- WSGI（同步）：Gunicorn/uWSGI，多 Worker 进程 + preload + 优雅重启。\n- ASGI（异步）：Uvicorn/Daphne，支持 WebSocket 和 async view。\n- 容器化：Docker 多阶段构建、环境变量管理、健康检查端点。\n- 监控：Sentry 异常捕获、Prometheus 指标暴露、日志结构化输出（JSON logging）。\n\n## 面试追问模板\n- Django ORM 的 N+1 问题你怎么发现的？怎么解决的？\n- Flask 的上下文是怎么实现的？多线程下安全吗？\n- 你的项目用的 WSGI 还是 ASGI？为什么？遇到什么瓶颈？\n- 线上一个接口突然变慢，从框架层面怎么排查？\n","isInternal":false,"tokens":1030,"sizeBytes":2934},{"name":"high-availability.md","path":"app/src/main/resources/skills/_shared/references/high-availability.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/high-availability.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 高可用面试重点（故障防护 + 容灾 + 可观测性）\n\n## 故障检测与主备切换\n- 心跳检测：应用层（HTTP 探针）vs TCP 层，超时阈值与抖动容忍。\n- 主备切换：主动-被动（冷备/热备）vs 主动-主动（双写+负载均衡）。\n- 选主机制：Raft/Paxos 共识、ZooKeeper 临时节点、etcd Lease。\n- 脑裂防护：Fencing（STONITH）/仲裁节点/ Lease 锁，避免双主写入。\n- 切换窗口：RTO（恢复时间目标）与 RPO（恢复点目标）的工程实现。\n\n## 限流、熔断与降级\n- 限流算法：固定窗口（临界突刺）、滑动窗口、令牌桶（匀速放行）、漏桶（平滑输出）。\n- 分布式限流：Redis Lua 原子计数 + 滑动窗口、Sentinel 集群限流模式。\n- 熔断器模式：Closed→Open→Half-Open 状态机，失败率/慢调用率触发。\n- 降级策略：返回缓存数据/默认值/简化结果、关闭非核心功能、手动开关。\n- 级联故障预防：超时设置（connect/read）、重试次数与退避策略、舱壁隔离（线程池/信号量）。\n\n## SLA/SLO 与可观测性\n- SLA/SLO/SLI 关系：SLO 是目标（如 99.9% 可用）、SLI 是指标（延迟/错误率）、SLA 是合同。\n- 三大支柱：Metrics（Prometheus + Grafana）、Logging（ELK/Loki）、Tracing（Jaeger/SkyWalking）。\n- 告警设计：分级（P0-P3）、收敛（抑制/聚合/路由）、OnCall 轮值与升级。\n- 错误预算：SLO 剩余预算决定发布节奏与变更风险容忍度。\n\n## 容量规划与混沌工程\n- 容量评估：QPS 峰值估算、带宽/存储/连接数上限、资源瓶颈定位（CPU/IO/网络）。\n- 压测方法论：基准压测→阶梯加压→极限探测，关注长尾延迟（P99）而非均值。\n- 自动弹性：HPA（Kubernetes）/ASG（云厂商），指标驱动（CPU/自定义指标）扩缩容。\n- 混沌工程：Chaos Mesh/LitmusChaos，故障注入（网络延迟/节点宕机/依赖不可用）。\n\n## 异地多活与容灾\n- 同城双活：两个机房同时提供服务，数据库跨机房同步（延迟可控）。\n- 异地多活：单元化架构（用户路由到固定单元）、数据同步（ Canal/Otter/Binlog）。\n- 全球化部署：DNS 就近路由、CDN 静态资源加速、数据合规（GDPR 数据驻留）。\n- 灾备演练：定期切换演练、数据一致性校验、回滚流程验证。\n\n## 面试追问模板\n- 流量突增 10 倍，你的系统哪里先扛不住？怎么应急？\n- 熔断打开后，下游恢复了你怎么感知？自动恢复还是人工？\n- 你的项目 SLA 是多少？怎么保证的？出过故障吗？\n- 混沌工程你在团队推行过吗？遇到过什么阻力？\n","isInternal":false,"tokens":1119,"sizeBytes":2716},{"name":"java.md","path":"app/src/main/resources/skills/_shared/references/java.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/java.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Java 面试重点（基础 + 集合 + 并发 + JVM）\n\n## 基础概念\n- JVM/JDK/JRE 区别，字节码与\"编译+解释\"执行模型，AOT vs JIT。\n- 8 种基本类型与包装类，自动装箱/拆箱与 Integer Cache。\n- `==` vs `equals()`，`hashCode()` 与 `equals()` 一致性约束。\n- 方法重载 vs 重写，静态分派与动态分派。\n- 接口 vs 抽象类，Java 8+ default 方法的影响。\n- 深拷贝 vs 浅拷贝，序列化方案。\n\n## String\n- 不可变性原理（final byte[]），安全与性能影响。\n- 字符串常量池：`intern()`、编译期优化、`new String(\"abc\")` 创建对象数。\n- `String` vs `StringBuilder` vs `StringBuffer`。\n\n## 集合框架\n- List：ArrayList（动态数组、扩容 1.5 倍）vs LinkedList（双向链表），RandomAccess 标记。\n- Map：HashMap 底层（数组+链表+红黑树）、负载因子与扩容、线程不安全场景。\n- HashMap 长度为何是 2 的幂次方，多线程死循环问题。\n- ConcurrentHashMap：JDK 7 分段锁 vs JDK 8 CAS+synchronized，key/value 不为 null。\n- Set：HashSet（基于 HashMap）、LinkedHashSet、TreeSet（红黑树）。\n- Queue：BlockingQueue 接口，ArrayBlockingQueue vs LinkedBlockingQueue。\n- fail-fast vs fail-safe 机制。\n\n## 并发\n- 线程生命周期与状态转换，上下文切换成本。\n- 死锁：条件、检测（jstack/arthuras）、预防策略。\n- JMM：可见性、有序性、happens-before；volatile 保证可见性+禁止重排序但不保证原子性。\n- synchronized 底层原理（Monitor）、锁升级（偏向→轻量→重量）、偏向锁废弃。\n- ReentrantLock vs synchronized：可中断、公平锁、Condition、超时获取。\n- CAS 与 ABA 问题，Atomic 原理。\n- 线程池：核心参数（corePoolSize/maxPoolSize/queue/handler）、拒绝策略、动态配置。\n- AQS 原理（state + CLH 队列），Semaphore/CountDownLatch/CyclicBarrier。\n- ThreadLocal：原理、内存泄漏与弱引用、跨线程传递（TransmittableThreadLocal）。\n- CompletableFuture：编排、异常处理、自定义线程池。\n- 虚拟线程（Java 21）：用途与调度模型。\n\n## JVM\n- 运行时数据区：堆/栈/方法区/元空间/程序计数器/直接内存。\n- 对象创建流程、内存布局、访问定位（句柄 vs 直接指针）。\n- GC 判断：引用计数 vs 可达性分析；四种引用（强/软/弱/虚）。\n- GC 算法：标记-清除、复制、标记-整理、分代收集。\n- 垃圾收集器：Serial→Parallel→CMS→G1→ZGC，各自适用场景。\n- G1 回收流程（Young GC / Mixed GC），ZGC 着色指针与读屏障。\n- 双亲委派模型与打破方式（SPI、OSGi、线程上下文类加载器）。\n- OOM 排查：Heap Dump、jmap/jstat/arthuras、GC 日志分析。\n\n## 面试追问模板\n- 这个机制底层是怎么实现的？有什么性能代价？\n- 多线程环境下会有什么问题？如何保证线程安全？\n- 框架（Spring/MyBatis）中哪里用到了这个机制？\n- 线上遇到 OOM/GC 频繁怎么排查？参数怎么调？\n","isInternal":false,"tokens":1096,"sizeBytes":3078},{"name":"javascript.md","path":"app/src/main/resources/skills/_shared/references/javascript.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/javascript.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# JavaScript 面试重点（基础 + 异步 + 工程化）\n\n## 类型与作用域\n- 8 种数据类型（7 原始 + Object），`typeof null === \"object\"` 历史遗留。\n- `let`/`const` vs `var`：块级作用域、暂时性死区（TDZ）、变量提升差异。\n- 作用域链：词法作用域（静态），引擎沿作用域链逐层查找标识符。\n- 闭包：函数与其词法环境的绑定，经典场景（防抖/节流/私有变量/柯里化）与内存泄漏风险。\n\n## 原型与继承\n- 原型链：`__proto__` vs `prototype`，属性查找沿原型链向上。\n- `Object.create()` vs `new`：直接指定原型 vs 构造函数实例化。\n- `class` 语法糖：`extends`/`super` 底层仍基于原型链，`static` 方法不可继承到实例。\n- `Object.setPrototypeOf` 性能问题，推荐 `Object.create` 替代。\n\n## 异步编程\n- 事件循环：宏任务（setTimeout/setInterval/I/O）与微任务（Promise.then/MutationObserver）执行顺序。\n- Promise：状态机（pending→fulfilled/rejected），链式调用与错误冒泡，`Promise.all` vs `Promise.allSettled` vs `Promise.race`。\n- `async/await`：语法糖，异常用 `try/catch` 捕获，并行场景仍需 `Promise.all`。\n- `async` 函数中的并发陷阱：串行 `await` vs 并行 `Promise.all`，性能差异。\n\n## ES6+ 核心特性\n- 解构赋值（数组/对象/默认值）、展开/剩余运算符。\n- 箭头函数：没有 `this`/`arguments`/`prototype`，不适合作为构造函数。\n- `Symbol`：唯一标识符，`Symbol.iterator` 与 `for...of` 协议。\n- `Map`/`Set`/`WeakMap`/`WeakSet`：与 Object/Array 的适用场景对比。\n- `Proxy`/`Reflect`：元编程基础，Vue 3 响应式原理的核心。\n\n## DOM 与 BOM\n- DOM 操作成本：重排（Layout）与重绘（Paint），批量更新策略（`DocumentFragment`/虚拟 DOM）。\n- 事件模型：捕获→目标→冒泡，`addEventListener` 第三个参数，事件委托。\n- `requestAnimationFrame` vs `setTimeout`：与屏幕刷新率同步，避免丢帧。\n\n## 模块化与工程化\n- CommonJS（`require`/`module.exports`，同步加载）vs ES Modules（`import`/`export`，静态分析）。\n- Tree-shaking 原理：ES Modules 静态结构使编译期可判定副作用。\n- `package.json` 依赖管理：`dependencies` vs `devDependencies`，语义化版本（semver）。\n- TypeScript 类型系统：接口/泛型/联合类型/类型守卫，与运行时无关。\n\n## 面试追问模板\n- 闭包在实际项目中用在哪里？遇到过内存泄漏吗？\n- 宏任务和微任务的执行顺序，你能举个复杂场景说明吗？\n- Promise 链中某个环节没 return，会发生什么？\n- CommonJS 和 ES Modules 能混用吗？打包工具怎么处理？\n","isInternal":false,"tokens":997,"sizeBytes":2753},{"name":"mq.md","path":"app/src/main/resources/skills/_shared/references/mq.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/mq.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 消息队列面试重点（模型 + 可靠性 + 主流 MQ 对比）\n\n## 消息模型\n- 点对点（Queue）：一条消息只能被一个消费者消费，消费后删除。\n- 发布订阅（Topic）：一条消息可被多个订阅者消费，消费独立。\n- 消费组（Consumer Group）：同一组内竞争消费、不同组间广播消费。\n- 消息顺序性：全局有序（单 Partition）vs 分区有序（同一 key 路由到同一 Partition）。\n\n## 投递语义\n- 至多一次（At Most Once）：可能丢消息，性能最高，适用允许丢失的场景（监控指标）。\n- 至少一次（At Least Once）：可能重复，需要消费端幂等，是大多数 MQ 的默认语义。\n- 恰好一次（Exactly Once）：Kafka 事务 + 幂等 Producer，RocketMQ 事务消息。\n- 幂等消费：唯一键去重（Redis/数据库唯一约束）、业务状态机判断。\n\n## 可靠性保障\n- 生产端确认：Kafka `acks=all`、RabbitMQ Publisher Confirm、RocketMQ 同步刷盘。\n- 消费端确认：手动 ACK（避免自动确认后处理失败丢消息）。\n- 消息持久化：磁盘持久化（Kafka 日志段、RocketMQ CommitLog）、副本机制。\n- 死信队列（DLQ）：消费重试达到上限后转入死信，人工介入处理。\n\n## 消费积压处理\n- 积压原因：消费者宕机、处理变慢（下游依赖超时）、突发流量。\n- 应急处理：紧急扩容消费者、临时消费者绕过慢逻辑先落库、消息降级。\n- 长期预防：消费监控告警（Lag 阈值）、容量预估、消费幂等保障安全扩容。\n- 削峰填谷：MQ 作为缓冲层，上游快速写入、下游匀速消费，保护下游系统。\n\n## 主流 MQ 对比\n- Kafka：高吞吐、顺序磁盘写、零拷贝、适合日志/事件流、Pull 模式。\n- RocketMQ：事务消息、延迟消息、消息过滤（Tag/SQL92）、适合电商金融、Push/Pull。\n- RabbitMQ：AMQP 协议、路由灵活（Exchange 类型丰富）、适合任务分发、Push 模式。\n- 选型维度：吞吐量、延迟、消息可靠性、顺序性、运维复杂度、社区生态。\n\n## 消息中间件架构\n- Kafka：Broker + Topic + Partition + Replica，Leader-Follower ISR 机制。\n- RocketMQ：NameServer + Broker + CommitLog + ConsumeQueue，高性能顺序写。\n- 分区/队列设计：分区数影响并行度、分区迁移与再平衡（Rebalance）、消费者组变更。\n\n## 面试追问模板\n- 消息积压了 100 万条，怎么处理？多久能恢复？\n- 如何保证消息不丢、不重、有序？你的项目怎么做的？\n- Kafka 和 RocketMQ 在你项目中怎么选的？用过什么特性？\n- 消费者 Rebalance 期间消息怎么处理？会造成重复消费吗？\n","isInternal":false,"tokens":989,"sizeBytes":2735},{"name":"mysql.md","path":"app/src/main/resources/skills/_shared/references/mysql.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/mysql.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# MySQL 面试重点\n\n## 索引\n- B+ 树为什么适合磁盘索引（有序、范围查询、叶子链表）。\n- 覆盖索引与回表成本，联合索引最左前缀原则与索引下推。\n- 索引失效场景：函数转换、隐式类型转换、OR、LIKE 前缀通配、非最左列。\n- EXPLAIN 执行计划：type/key/Extra 字段含义，Extra 中 Using filesort/Using temporary。\n\n## 事务与 MVCC\n- ACID 含义，事务隔离级别（RU/RC/RR/SERIALIZABLE）与各自解决的问题。\n- MySQL 默认 RR，InnoDB 通过 MVCC + Next-Key Lock 解决幻读。\n- MVCC 原理：隐藏列（trx_id/roll_pointer）、Undo Log 版本链、ReadView。\n- 当前读 vs 快照读，RR 下当前读仍加间隙锁。\n\n## 锁机制\n- 表级锁 vs 行级锁，InnoDB 行锁（Record/Gap/Next-Key）。\n- 意向锁的作用（快速判断表级冲突），IS/IX 与 S/X 的兼容矩阵。\n- 死锁检测与避免：按固定顺序加锁、缩短事务、降低隔离级别。\n\n## 存储引擎与日志\n- InnoDB vs MyISAM：事务、行锁、外键、崩溃恢复。\n- Redo Log（WAL、crash-safe）vs Undo Log（MVCC、回滚）vs Binlog（主从复制、归档）。\n- 两阶段提交保证 Redo Log 与 Binlog 一致性。\n\n## 性能优化\n- 慢 SQL 定位：slow_query_log、pt-query-digest。\n- 分库分表策略：垂直拆分 vs 水平拆分，ShardingSphere 中间件。\n- 深度分页优化：游标分页、延迟关联、子查询先查主键。\n- 数据冷热分离，读写分离架构。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？能否优化？\n- 高并发写入时，锁冲突怎么解决？\n- 主从延迟怎么处理？数据一致性如何保证？\n","isInternal":false,"tokens":663,"sizeBytes":1682},{"name":"network-os.md","path":"app/src/main/resources/skills/_shared/references/network-os.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/network-os.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 网络与操作系统（后端面试核心）\n\n## TCP / HTTP 高频点\n- TCP 三次握手与四次挥手，TIME_WAIT 的意义与优化边界。\n- 粘包/拆包原因与解决（长度字段、分隔符、固定包长）。\n- HTTP1.1/2 差异：连接复用、队头阻塞、头部压缩。\n- HTTPS 握手流程：证书校验、密钥协商、会话复用。\n\n## 并发与线程模型\n- 进程/线程区别，用户态与内核态切换成本。\n- 线程池参数设计：核心线程、队列、拒绝策略、监控指标。\n- 锁优化：悲观锁/乐观锁、CAS、自旋、锁升级。\n\n## 内存与 I/O\n- JVM 内存区域、GC 停顿对接口延迟的影响。\n- 零拷贝、mmap、sendfile 的适用场景。\n- Reactor 模型与同步阻塞模型差异。\n\n## 面试追问模板\n- 为什么不是这个方案？底层代价是什么？\n- 如果连接数/流量翻倍，瓶颈会先出现在哪里？\n- 出现网络抖动或线程池打满时，如何降级与恢复？\n","isInternal":false,"tokens":400,"sizeBytes":979},{"name":"python-basic.md","path":"app/src/main/resources/skills/_shared/references/python-basic.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/python-basic.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Python 面试重点（语言核心 + 并发 + 工程实践）\n\n## 数据模型与语法特性\n- 一切皆对象：`id()`/`type()`/`value`，可变对象（list/dict/set）vs 不可变对象（int/str/tuple）。\n- 魔法方法：`__init__` vs `__new__`、`__str__` vs `__repr__`、`__eq__` vs `__hash__`、`__enter__`/`__exit__`（上下文管理器）。\n- 多重继承与 MRO：C3 线性化算法、`super()` 沿 MRO 链调用。\n- 描述符协议：`__get__`/`__set__`/`__delete__`，property/classmethod/staticmethod 的底层实现。\n\n## 迭代器、生成器与装饰器\n- 迭代器协议：`__iter__` + `__next__`，`StopIteration` 终止，`for` 循环底层机制。\n- 生成器：`yield` 暂停与恢复、惰性求值、内存优势（处理大数据集/无限序列）。\n- 生成器表达式 vs 列表推导式：内存 vs 速度的取舍。\n- 装饰器：闭包 + `@` 语法糖、带参数装饰器（三层嵌套）、`functools.wraps` 保留元信息。\n- 类装饰器 vs 函数装饰器，`__call__` 实现。\n\n## GIL 与并发模型\n- GIL（全局解释器锁）：CPython 的内存安全机制，CPU 密集型多线程无法并行。\n- 多线程（`threading`）：适合 I/O 密集型（网络请求/文件读写），GIL 在 I/O 等待时释放。\n- 多进程（`multiprocessing`）：绕过 GIL，进程间通信（Queue/Pipe/共享内存），进程池。\n- 异步（`asyncio`）：事件循环 + 协程（`async`/`await`），适合高并发 I/O，单线程无锁。\n- `concurrent.futures`：`ThreadPoolExecutor` vs `ProcessPoolExecutor`，统一的 Future 接口。\n\n## 内存管理与垃圾回收\n- 引用计数：主要回收机制，实时性好但无法处理循环引用。\n- 分代 GC：0/1/2 三代，新对象从 0 代开始，存活时间越长晋升概率越低。\n- 循环引用检测：`gc` 模块的标记-清除算法，`gc.collect()` 手动触发。\n- 内存优化：`__slots__` 禁止动态属性字典、`sys.getsizeof`、内存分析工具（`tracemalloc`/`memory_profiler`）。\n\n## 类型系统与工程实践\n- Type Hints：`typing` 模块（`Optional`/`Union`/`Generic`/`Protocol`），mypy 静态检查。\n- dataclass vs attrs vs Pydantic：数据类定义、校验、序列化的选型。\n- 包管理：`pip` + `requirements.txt` vs `poetry`/`uv`（锁文件、依赖解析）。\n- 虚拟环境：`venv`/`conda`，隔离项目依赖避免版本冲突。\n- 代码质量：`ruff`（lint + format）、`pytest`（测试框架）、`pre-commit`（Git 钩子）。\n\n## 面试追问模板\n- Python 的 GIL 在你的项目中造成过问题吗？怎么解决的？\n- 装饰器写过什么功能？带参数的装饰器怎么实现的？\n- 内存泄漏怎么排查？用过哪些工具？\n- 大量数据处理时，你会用生成器还是列表？权衡点是什么？\n","isInternal":false,"tokens":1083,"sizeBytes":2814},{"name":"react-vue.md","path":"app/src/main/resources/skills/_shared/references/react-vue.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/react-vue.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# React/Vue 面试重点（框架核心 + 工程化）\n\n## React 核心机制\n- Fiber 架构：链表结构替代递归、可中断渲染、时间切片（Time Slicing）与优先级调度。\n- Virtual DOM：Diff 算法（同层比较、key 的作用）、Reconciliation 过程。\n- Hooks 规则：调用顺序一致（不能在条件/循环中调用）、闭包陷阱（stale closure）与解决方案。\n- 常用 Hooks：`useState`/`useEffect`（依赖数组）/`useCallback`/`useMemo`/`useRef`/`useContext`。\n- `useEffect` vs `useLayoutEffect`：异步 vs 同步、绘制前 vs 绘制后。\n- React 18 并发特性：`useTransition`（非紧急更新降级）、`useDeferredValue`（延迟重渲染）、Suspense 数据获取。\n\n## Vue 核心机制\n- 响应式原理：Vue 2（`Object.defineProperty` 拦截 getter/setter）vs Vue 3（`Proxy` 代理全对象）。\n- Composition API：`ref`/`reactive`/`computed`/`watch`/`watchEffect`，逻辑组合 vs Options API 逻辑分散。\n- 模板编译：模板→AST→渲染函数→Virtual DOM，静态提升与补丁标记（Patch Flag）。\n- 组件更新粒度：Vue 3 基于依赖追踪的精确更新 vs React 整体重渲染（需 memo/shouldComponentUpdate）。\n- Vue 3 编译优化：Block Tree、静态提升（hoistStatic）、缓存事件处理器。\n\n## 状态管理\n- React：Context API（轻量）、Redux（单向数据流/reducer/middleware）、Zustand（极简 Hook 式）、Jotai/Recoil（原子化）。\n- Vue：Pinia（Vue 3 官方推荐，TS 友好、模块化）、Vuex（Vue 2 时代，mutation/action 分离）。\n- 状态分层：组件本地状态 vs 全局共享状态 vs 服务端状态（React Query/TanStack Query）。\n\n## 组件设计\n- 组件通信：props/emit、provide/inject（跨层级）、事件总线、状态管理。\n- 组件抽象：高阶组件（HOC）vs Render Props vs Hooks（React）、插槽（Slots）vs 作用域插槽（Vue）。\n- 受控 vs 非受控组件：表单管理策略、`ref` 获取 DOM/组件实例。\n- 性能优化：`React.memo`/`useMemo`/`useCallback`、Vue `v-once`/`v-memo`、虚拟列表（react-window/vue-virtual-scroller）。\n\n## 路由与 SSR\n- React Router：声明式路由、嵌套路由、路由守卫、懒加载（`React.lazy` + `Suspense`）。\n- Vue Router：动态路由匹配、导航守卫（beforeEach/afterEach）、路由懒加载。\n- SSR vs CSR vs SSG：SEO、首屏速度、服务器成本权衡。\n- Next.js：SSR/SSG/ISR/App Router、Nuxt.js：服务端渲染与混合渲染。\n- Hydration：SSR HTML + 客户端 JS 绑定事件，注水不匹配（hydration mismatch）排查。\n\n## 工程化\n- 构建工具：Vite（ESM 开发服务器 + Rollup 构建）vs Webpack（loader/plugin 生态）。\n- 代码规范：ESLint + Prettier、Husky + lint-staged（提交前检查）。\n- 测试：Jest/Vitest（单元测试）、React Testing Library/Vue Test Utils（组件测试）、Playwright/Cypress（E2E）。\n- 微前端：Module Federation、qiankun、single-spa，应用隔离与通信。\n\n## 面试追问模板\n- React 的 Fiber 架构解决了什么问题？调度是怎么实现的？\n- Vue 3 的 Proxy 响应式和 Vue 2 的 defineProperty 有什么本质区别？\n- 大列表渲染卡顿怎么优化？虚拟列表的原理是什么？\n- 你的项目状态管理怎么选型的？遇到过什么问题？\n","isInternal":false,"tokens":1178,"sizeBytes":3362},{"name":"redis.md","path":"app/src/main/resources/skills/_shared/references/redis.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/redis.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Redis 面试重点\n\n## 数据类型与场景\n- 五种基础类型：String/Hash/List/Set/ZSet，各类型底层编码与适用场景。\n- 特殊类型：Bitmap（活跃统计）、HyperLogLog（UV 去重）、Stream（消息队列）。\n- ZSet 底层为什么用跳表而不是红黑树/B+树（范围查询、实现简单、内存灵活）。\n\n## 持久化与线程模型\n- RDB（fork + COW）vs AOF（写后日志、fsync 策略），混合持久化。\n- Redis 6.0 前单线程模型（避免锁竞争、IO 多路复用），6.0 后多线程 IO（命令执行仍单线程）。\n\n## 生产问题\n- 缓存穿透（布隆过滤器/空值缓存）、缓存击穿（互斥锁/永不过期）、缓存雪崩（随机过期/多级缓存）。\n- 缓存与数据库一致性：延迟双删、Canal 监听 Binlog、最终一致性方案。\n\n## 分布式锁\n- `SET key value NX EX` 基本实现，误删问题与 Lua 原子释放。\n- Redisson 可重入锁原理（Hash 结构 + Lua 脚本），看门狗续期机制。\n- 集群下可靠性：RedLock 争议与替代方案（fencing token）。\n\n## 性能优化\n- Pipeline 批量减少 RTT，Lua 脚本保证原子性。\n- BigKey 检测与拆分（redis-rdb-tools、UNLINK 异步删除）。\n- HotKey 发现与本地缓存 + 热点分散。\n- 内存淘汰策略：allkeys-lru vs volatile-lru，内存碎片清理。\n\n## 集群\n- 主从复制（全量 + 增量）、哨兵模式（故障转移、主观/客观下线）。\n- Cluster 模式：16384 槽位、Gossip 协议、重定向（MOVED/ASK）。\n\n## 面试追问模板\n- 如果 Redis 宕机，业务怎么降级？\n- 百万级 QPS 场景下，缓存架构怎么设计？\n- 大 Key 线上清理导致阻塞怎么办？\n","isInternal":false,"tokens":686,"sizeBytes":1714},{"name":"spring.md","path":"app/src/main/resources/skills/_shared/references/spring.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/spring.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Spring 面试重点\n\n## IoC 与 Bean\n- IoC 解决什么问题：解耦对象创建与依赖管理。\n- `@Component` vs `@Bean`：声明方式、代理对象、第三方库集成。\n- `@Autowired` vs `@Resource`：按类型 vs 按名称，优先级规则。\n- 构造器注入 vs Setter 注入 vs 字段注入：不可变性、循环依赖、测试友好度。\n- Bean 作用域（singleton/prototype/request/session），线程安全分析。\n- Bean 生命周期：实例化→属性注入→Aware→初始化→销毁，各阶段扩展点。\n\n## AOP\n- 核心概念：切面/切点/通知/连接点。\n- Spring AOP vs AspectJ：动态代理 vs 编译期织入，性能与功能差异。\n- 通知类型：@Before/@After/@AfterReturning/@AfterThrowing/@Around。\n- 同类内部调用 AOP 失效原因与解决方案（AopContext/exposeProxy）。\n\n## Spring MVC\n- DispatcherServlet 工作流程：HandlerMapping→HandlerAdapter→ViewResolver。\n- 统一异常处理：@ControllerAdvice + @ExceptionHandler。\n- 拦截器 vs 过滤器：执行时机与适用场景。\n\n## 事务\n- 声明式事务：@Transactional 属性（propagation/isolation/rollbackFor）。\n- 七种传播行为：REQUIRED/REQUIRES_NEW/NESTED 等使用场景。\n- 事务失效场景：同类内部调用、非 public 方法、异常被吞、异步调用。\n\n## 循环依赖\n- 三级缓存解决 setter 注入循环依赖：singletonObjects/earlySingletonObjects/singletonFactories。\n- 构造器注入循环依赖无法自动解决，需 @Lazy。\n- SpringBoot 2.6+ 默认禁止循环依赖。\n\n## Spring Boot\n- 自动配置原理：@SpringBootApplication→@EnableAutoConfiguration→spring.factories/Imports。\n- 条件装配：@ConditionalOnClass/@ConditionalOnMissingBean 等。\n- 配置文件加载优先级：properties > yaml > 环境变量 > 命令行参数。\n\n## 面试追问模板\n- @Transactional 标在 private 方法上会生效吗？为什么？\n- 如何自定义一个 Spring Boot Starter？\n- Spring AOP 在你的项目中用来做了什么？遇到过什么坑？\n","isInternal":false,"tokens":659,"sizeBytes":2052},{"name":"system-design-scenarios.md","path":"app/src/main/resources/skills/_shared/references/system-design-scenarios.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/system-design-scenarios.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 系统设计与场景题（后端通用核心版）\n\n## 1. 面试答题通用框架（先说这个）\n1. 先澄清约束：QPS、峰值倍数、SLA、数据量、延迟目标、一致性级别、成本上限。\n2. 再给核心链路：请求路径、读写路径、关键状态、失败路径。\n3. 最后补工程细节：容量估算、监控告警、降级兜底、回滚与补偿。\n\n## 2. 高频场景题的标准思路\n\n### 秒杀系统\n- 目标：抗瞬时洪峰、避免超卖、保证最终一致。\n- 关键手段：前置限流 + 验证码/预约削峰 + 缓存库存 + 异步下单（MQ）。\n- 一致性：预扣库存 + 订单超时回补；幂等键防重复下单。\n- 风险点：热点 Key、缓存击穿、消息堆积、库存回补失败。\n\n### 短链系统\n- 目标：短码唯一、重定向高性能、可统计。\n- 核心：短码生成（号段/哈希+冲突处理）+ 映射存储 + 缓存热点短链。\n- 扩展：防刷、防爆破、过期回收、点击明细异步落库。\n\n### Feed 流（推拉模型）\n- 目标：低延迟、可扩展、支持热点用户。\n- 模式：推模式（读快写重）/拉模式（写快读重）/推拉结合（明星与普通用户分治）。\n- 关键：时间线有序、分页游标、防重复、防回刷穿透。\n\n### 站内消息系统\n- 消息类型拆分：系统通知、事件提醒、私信。\n- 核心能力：未读计数、聚合展示、已读状态、离线补偿、幂等去重。\n- 存储策略：会话维度和消息明细分离，冷热分层。\n\n### 延时任务\n- 可选方案：Redis 延迟队列 / MQ 延时消息 / 时间轮调度。\n- 关键问题：任务可靠投递、重复执行防护、取消与重试语义。\n- 工程点：失败重试上限、死信处理、任务可观测性（积压、延迟、失败率）。\n\n### 登录风控（密码输错限制）\n- 核心：用户维度失败计数 + TTL 锁定窗口。\n- 要点：分布式一致计数、防账号枚举、风控阈值分级（验证码->临时锁定->人工校验）。\n- 审计：保留关键操作日志与告警。\n\n### 扫码登录 / 第三方登录\n- 扫码登录：状态机（待扫码->已扫码待确认->确认登录/取消/过期）。\n- OAuth2：授权码模式优先；短期 Access Token + 可撤销 Refresh Token。\n- 安全点：`state` 防 CSRF、回调域名白名单、一次性 code、过期控制。\n\n### 抢单 / 抢资源并发控制\n- 核心目标：同一资源只被一个请求成功占有。\n- 实现：数据库唯一约束 + 乐观锁版本号 或 Redis 原子指令/CAS。\n- 必备：幂等键、超时释放、补偿回滚。\n\n### UV/PV 统计\n- UV 常见实现：HyperLogLog（省内存，近似去重）。\n- PV：计数器即可；复杂场景按站点/页面/时间分桶。\n- 大盘链路：写入削峰（MQ）+ 离线/准实时聚合。\n\n### 去重推荐（大规模）\n- 核心：布隆过滤器 + 分层存储（内存 + 磁盘）+ 批量异步刷盘。\n- 重点：误判率控制、窗口淘汰策略、冷启动兼容。\n\n### RPC 框架设计\n- 关键组件：注册发现、序列化协议、网络传输、负载均衡、超时重试、熔断隔离。\n- 高可用：请求幂等、降级策略、调用链追踪。\n\n### Session 跨节点共享\n- 推荐：集中式会话存储（Redis）。\n- 不推荐：应用节点间 session 复制（扩展性差，维护成本高）。\n\n## 3. 面试官常追问清单\n1. 为什么这么分层？瓶颈先出在哪里？\n2. 失败后怎么恢复？谁触发补偿？如何防重？\n3. 峰值翻 3 倍时，先扩哪个组件？依据是什么？\n4. 你怎么证明方案有效？给出核心指标与阈值。\n5. 一致性和可用性冲突时，你的取舍原则是什么？\n","isInternal":false,"tokens":1497,"sizeBytes":3730},{"name":"test-development.md","path":"app/src/main/resources/skills/_shared/references/test-development.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/_shared/references/test-development.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 测试开发面试重点（测试基础 + 用例设计 + 自动化 + 性能安全）\n\n## 测试基础\n- 软件测试定义与目的：发现缺陷、验证需求、提供质量反馈，不只是\"找 Bug\"。\n- 测试流程：需求分析→测试计划→测试设计→测试执行→缺陷跟踪→测试报告→回归测试。\n- 测试左移（Shift-Left）：需求/设计阶段就介入质量活动，早发现早修复，缺陷成本随阶段指数增长。\n- 测试覆盖率：行覆盖/分支覆盖/路径覆盖，高覆盖率 ≠ 高质量测试，关注有意义覆盖率而非数字。\n- 测试金字塔：单元测试（>90% 自动化）→集成测试（60-80%）→系统/UI 测试（20-40%），投资回报递减。\n- 核心竞争力：业务理解 + 系统性用例设计 + 工程化自动化能力。\n\n## 测试用例设计\n- 等价类划分：将输入划分为有效/无效等价类，每类取代表性数据，减少冗余。\n- 边界值分析：等价类边界的值最易出错，如范围 [1,100] 测试 0/1/100/101。\n- 判定表法：多条件组合场景（如会员×节假日×提前天数→价格），穷举条件与结果映射。\n- 场景法：模拟用户操作流程（主流程+异常分支），通过流程图覆盖完整业务路径。\n- 错误推测法：基于经验推测易错点（如文件上传：空文件/超大文件/病毒文件/格式不符）。\n- 状态迁移法：测试有状态变化的对象（如订单状态、电梯状态），验证状态转换正确性。\n- 好的测试用例标准：覆盖全面、分组精准（等价类无冗余）、边界清晰。\n- 场景题回答框架：功能→兼容性→性能→网络→安全→UI/UX，逐维度展开。\n\n## 测试类型\n- 黑盒测试 vs 白盒测试：关注外部行为 vs 关注内部代码逻辑，互补使用。\n- 单元测试：最小可测试单元（函数/类），Mock 外部依赖，开发编写，CI 自动执行。\n- 集成测试：多模块/服务交互验证，关注接口契约、数据传递、依赖协同。\n- 系统测试：完整系统验证，功能/性能/安全/兼容性全面覆盖。\n- 回归测试：修改后确认旧功能未被破坏，高度依赖自动化用例。\n- 验收测试（UAT）：业务方确认是否满足需求，贴近真实场景。\n- 端到端测试（E2E）：完整业务链路验证，从用户入口到最终输出，数量少但价值高。\n- 正向测试 vs 反向测试：合法输入验证正常功能 vs 非法输入验证异常处理能力。\n\n## 自动化测试\n- ROI 公式：(节省的手工测试时间 × 执行频率) - (脚本开发时间 + 维护成本)。\n- 适用场景：回归测试、步骤确定性高、执行频率高；不适用：一次性功能、UI 频繁变动、探索性测试。\n- Web 自动化工具：Selenium（多语言/多浏览器、成熟但慢）、Cypress（开发者友好、JS-only）、Playwright（现代化、多语言、快）。\n- API 测试流程：读 API 文档→设计用例（正常/异常/边界）→准备数据与认证→发请求→校验响应与数据库。\n- API 测试工具：Postman/Reqable/Insomnia，结合 Newman/CI 实现自动化回归。\n- 移动端自动化：Appium（跨平台）、Espresso（Android 原生）、XCTest（iOS 原生）。\n- CI/CD 集成：Jenkins/GitLab CI/GitHub Actions 中自动触发，测试报告与失败告警。\n\n## 性能测试\n- 压测类型：负载测试（预期负载下验证）、压力测试（超负载找极限）、稳定性测试（长时间运行查泄漏）。\n- 压测流程：确定目标（QPS/RT/TPS）→准备环境（≈生产 50-80%）→选工具→编写脚本→执行→监控分析→调优→复测。\n- 压测工具：JMeter（功能全面）、k6（JS 脚本、现代化）、Gatling（Scala、高性能）、Locust（Python）。\n- 关键指标：TPS/QPS、响应时间（P50/P95/P99）、错误率、CPU/内存/磁盘 IO/网络带宽。\n- 瓶颈定位：数据库慢查询、连接池打满、线程池饱和、网络带宽、GC 停顿。\n\n## 安全测试\n- OWASP Top 10：XSS/SQL 注入/CSRF/身份认证失效/敏感信息泄露/访问控制失效等。\n- XSS 测试：输入 `<script>alert(1)</script>`、`<img src=x onerror=alert(1)>`，验证是否转义/过滤。\n- SQL 注入测试：`' OR '1'='1 --`、`' UNION SELECT --`、时间盲注 `AND SLEEP(5)`，验证参数化查询。\n- CSRF 测试：检查 CSRF Token、SameSite Cookie、Referer 校验。\n- 越权测试：水平越权（访问同角色他人数据）、垂直越权（普通用户访问管理接口）。\n\n## Bug 处理与协作\n- 不可复现 Bug：多次尝试不同环境/数据→收集详细信息（步骤/日志/截图/录屏）→与开发协作分析。\n- 缺陷报告要素：标题、前置条件、复现步骤、预期结果、实际结果、严重程度、优先级。\n- Bug 生命周期：新建→确认→分配→修复→验证→关闭（或重新打开）。\n- 印象深刻的 Bug 回答模板：场景描述 + 根因分析 + 修复过程 + 后续预防。\n\n## 面试追问模板\n- 登录/支付/电商直播间场景，你怎么设计测试用例？\n- 你的自动化测试覆盖率是多少？ROI 怎么评估？\n- 线上出了一个 Bug，但测试环境无法复现，你怎么排查？\n- 你在 CI/CD 中集成了哪些质量门禁？怎么防止质量回退？\n","isInternal":false,"tokens":1947,"sizeBytes":5366},{"name":"ai-agent-dev.md","path":"app/src/main/resources/skills/ai-agent-dev/ai-agent-dev.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/ai-agent-dev/ai-agent-dev.md","title":"Ai-agent-dev Skill","category":"anthropic-skill","format":"markdown","content":"# AI Agent 开发面试参考\n\n## 一、Agent 基础\n\n### Agent 定义与核心架构\n- Agent = LLM + Planning + Memory + Tools\n- Agent Loop：感知(Perceive) -> 推理(Reason) -> 行动(Act) -> 观察(Observe) 循环\n- 终止条件：任务完成、达到最大步数、用户中断、错误熔断\n\n### Agent vs 传统编程 vs 工作流\n- 决策者差异：Agent 由 AI 决策下一步，工作流由预定义路径驱动\n- 适用场景判断：确定性任务用工作流，开放性任务用 Agent\n\n### Agent 范式\n- ReAct：Thought-Action-Observation 循环，边推理边执行\n- Plan-and-Execute：先规划全局步骤，再逐步执行\n- Reflection：自我反思与修正（Reflexion / Self-Refine / CRITIC）\n\n### 多 Agent 系统\n- Orchestrator-Subagent：主从模式，编排器分配任务\n- Peer-to-Peer：对等模式，Agent 间平等协作\n- A2A（Agent-to-Agent）通信协议\n\n### 安全\n- Prompt Injection 攻击类型与防御（执行层沙箱、认知层隔离、决策层人机协同）\n- Agent 权限边界设计（最小权限原则）\n- 敏感操作审批机制\n\n---\n\n## 二、LLM 调用\n\n### Token 与上下文窗口\n- Token 是计费和性能的基本单位（非字符）\n- 上下文窗口 = System Prompt + User Prompt + 历史 + RAG + 工具定义 + 输出\n- Token 预算：window >= input_tokens + max_output_tokens\n- Prompt Caching：静态内容前置、动态内容后置\n\n### 采样参数\n- Temperature：控制随机性（低=确定性，高=创造性）\n- Top-p（核采样）和 Top-k：缩小候选词池\n- Presence/Frequency Penalty：抑制重复\n- 推理模型（o1/o3）的参数限制\n\n### Function Calling\n- JSON Schema 定义工具接口\n- 工具粒度设计：原子操作 vs 组合操作\n- 并行工具调用（Parallel Tool Calling）\n- 错误处理：工具调用失败时的重试与降级策略\n\n### 结构化输出与流式输出\n- JSON Mode vs Structured Output（Schema 约束）\n- SSE（Server-Sent Events）机制与 TTFT 优化\n- 流式场景下的工具调用处理\n\n### 成本优化\n- 输入/输出 Token 定价差异（2-5 倍）\n- 路由策略：简单问题用小模型、复杂问题用大模型\n- 缓存策略：语义缓存、精确匹配缓存\n\n---\n\n## 三、MCP 协议\n\n### MCP 定位\n- MCP（Model Context Protocol）= AI 的 USB-C，统一工具接入标准\n- MCP vs Function Calling vs Agent：MCP 是协议标准，Function Calling 是 LLM 能力，Agent 是系统概念\n- 四层关系：Function Calling（基础） -> Prompt（意图） -> MCP（连接） -> Skills（编排）\n\n### MCP 四大核心能力\n- Resources：只读数据源 | Tools：可执行操作 | Prompts：模板化提示词 | Sampling：LLM 推理委托\n\n### 架构与传输\n- 四层：Host（宿主） -> Client（协议客户端） -> Server（工具服务） -> Data Source\n- JSON-RPC 2.0 通信协议（轻量、传输无关、易调试）\n- stdio：本地 IPC；Streamable HTTP：远程/生产（已废弃 HTTP+SSE）\n\n### 生产实践\n- 工具幂等性设计、退避策略与 P99 延迟目标\n- 上下文窗口管理（大结果截断、分页）\n- 安全考量（输入校验、权限控制、审计日志）\n\n---\n\n## 四、RAG 检索增强\n\n### 基本原理\n- RAG = 信息检索 + LLM 生成\n- 离线索引（加载、清洗、分块、Embedding、存储）+ 在线检索（查询向量化、相似度搜索、上下文构建、生成）\n- 核心优势：知识时效性、减少幻觉、数据安全、领域适配\n\n### 分块与 Embedding\n- 固定长度 vs 语义分块 vs 递归分块\n- 分块大小与语义完整性的权衡\n- 通用 vs 领域微调 Embedding 模型选择\n\n### 向量检索\n- ANN：用 5% 召回率损失换 100 倍速度\n- HNSW：<1000 万向量、高召回、高内存 | IVFFLAT：1000 万-1 亿、内存友好\n- 距离度量：余弦相似度、内积、欧几里得距离\n- 混合检索：向量 + BM25 + RRF 融合（生产最佳实践）\n\n### 局限与治理\n- GIGO：检索质量决定生成质量\n- 上下文窗口噪声、TTFT 增加、检索召回率评估\n\n---\n\n## 五、上下文工程\n\n### 概念\n- Agent = Model + Harness（模型之外的一切都是 Harness）\n- 模型决定上限，Harness 决定下限\n\n### 六层 Harness 架构\n1. L1 信息边界：System Prompt、约束条件、角色定义\n2. L2 工具系统：工具注册、Schema 定义、权限控制\n3. L3 执行编排：Agent Loop、条件分支、并行执行\n4. L4 记忆与状态：短期记忆、长期记忆、状态持久化\n5. L5 评估与可观测：质量评估、链路追踪、指标监控\n6. L6 约束与恢复：错误处理、重试策略、降级方案\n\n### Token 预算与设计模式\n- 40% 上下文利用率阈值（超过后质量急剧下降）\n- 上下文压缩：摘要、裁剪、遗忘\n- 渐进式披露：L1 元数据常驻 + L2 正文按需 + L3 资源隔离\n- Lost in the Middle 问题与应对\n\n### 实践案例\n- OpenAI：机械约束优于文档约束、熵管理\n- Anthropic：GAN 式三 Agent 架构、上下文重置策略\n- Stripe：Minions 系统\n\n---\n\n## 面试高频追问\n\n### Agent 基础\n- Agent Loop 中如何防止无限循环？\n- ReAct 和 Plan-and-Execute 各自的优缺点和适用场景？\n- 多 Agent 系统中如何保证一致性？\n\n### LLM 调用\n- Token 超出上下文窗口时怎么处理？\n- Function Calling 和直接在 Prompt 里写工具有什么区别？\n- 如何降低 LLM 调用的 P99 延迟？\n\n### MCP 协议\n- MCP 和直接用 Function Calling 有什么区别？\n- stdio 和 Streamable HTTP 分别适合什么场景？\n- 如何设计一个生产级的 MCP Server？\n\n### RAG\n- 分块策略如何选择？过大或过小分别有什么问题？\n- 向量检索和关键词检索各自的优缺点？为什么需要混合检索？\n- RAG 系统线上出现幻觉，排查思路是什么？\n\n### 上下文工程\n- Agent 上下文超出窗口时如何处理？\n- AGENTS.md / SKILL.md 的设计原则是什么？\n- Harness 各层级中哪一层对 Agent 质量影响最大？为什么？\n","isInternal":false,"tokens":2223,"sizeBytes":6009},{"name":"SKILL.md","path":"app/src/main/resources/skills/ai-agent-dev/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/ai-agent-dev/SKILL.md","title":"ai-agent-dev","category":"anthropic-skill","format":"markdown","content":"---\nname: ai-agent-dev\ndescription: 用于 AI Agent 开发岗位面试出题；覆盖 Agent 架构、LLM 调用、工具集成、MCP 协议、RAG、上下文工程与多 Agent 协作，强调工程落地与故障处理能力。\n---\n# Overview\n你是一位 AI Agent 开发岗位面试官，关注候选人对 Agent 系统的工程实现能力，而不是只会描述概念。重点考察：Agent Loop 设计、工具集成方式、上下文管理策略、RAG 检索质量治理和多 Agent 协作模式。\n\n# Instructions\n1. 先确认候选人的技术栈（LangChain / Spring AI / 自研框架）和实际项目经验，围绕真实项目追问。\n2. 提问遵循梯度：使用经验 -> 原理机制 -> 边界与故障 -> 优化与权衡。\n3. 每个主问题必须包含至少一个权衡点（如召回率 vs 延迟、上下文长度 vs 信息密度）。\n4. 回答停留在概念层时，必须追问具体实现：协议选型、Token 预算分配、错误重试策略、可观测性指标。\n5. 至少一次要求候选人给出可量化指标（如 TTFT、P99 延迟、检索召回率、Token 利用率）。\n6. 不要只问名词解释，必须有场景化问题（如\"线上 Agent 出现幻觉循环，你怎么排查\"）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- AGENT_BASIS / LLM_CALLING / MCP_PROTOCOL / RAG / CONTEXT_ENGINEERING / MULTI_AGENT / PROJECT -> ai-agent-dev.md\n","frontmatter":{"name":"ai-agent-dev","description":"用于 AI Agent 开发岗位面试出题；覆盖 Agent 架构、LLM 调用、工具集成、MCP 协议、RAG、上下文工程与多 Agent 协作，强调工程落地与故障处理能力。"},"isInternal":false,"tokens":524,"sizeBytes":1430},{"name":"SKILL.md","path":"app/src/main/resources/skills/algorithm/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/algorithm/SKILL.md","title":"algorithm","category":"anthropic-skill","format":"markdown","content":"---\nname: algorithm\ndescription: 用于算法面试出题；重点评估复杂度分析、边界处理和优化能力，区分背题与真实理解。\n---\n# Overview\n你是一位算法面试官，目标是评估候选人的建模能力和复杂度优化能力。\n\n# Instructions\n1. 文字/语音面试不要求写代码；每题先让候选人口述：建模方式、关键数据结构、核心步骤、时间/空间复杂度。\n2. 数据结构必须覆盖多样性：哈希表、栈/队列、堆、树/图、数组/链表应轮换考察，避免只刷单一套路。\n3. 回答正确后继续追问边界条件、退化场景和同类变体，不停在基础答案。\n4. 对暴力解必须追问瓶颈，并要求给出可落地的优化路径（如剪枝、单调结构、预处理、空间换时间）。\n5. 至少一次要求候选人解释正确性证明思路（不变式/归纳/反证任一即可）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP/GREEDY_BACKTRACK/DESIGN -> algorithm-data-structures.md\n","frontmatter":{"name":"algorithm","description":"用于算法面试出题；重点评估复杂度分析、边界处理和优化能力，区分背题与真实理解。"},"isInternal":false,"tokens":389,"sizeBytes":1096},{"name":"SKILL.md","path":"app/src/main/resources/skills/ali-backend/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/ali-backend/SKILL.md","title":"ali-backend","category":"anthropic-skill","format":"markdown","content":"---\nname: ali-backend\ndescription: 用于阿里后端面试出题；强调业务深度、项目落地和中间件选型能力，关注复杂场景下的取舍与闭环。\n---\n# Overview\n你是阿里巴巴后端面试官。核心风格是业务导向与项目深挖：围绕候选人真实项目持续追问，直到触达认知边界。\n\n# Instructions\n1. 优先从简历项目切入，连续追问\"为什么这样设计\"\"如果流量涨 10 倍怎么改\"。\n2. 每个问题必须落到业务目标、技术取舍、成本与收益，不接受纯理论回答。\n3. 对 Java 生态中间件（MySQL、Redis、MQ）重点追问原理、故障、容量与治理。\n4. 至少一次要求候选人给出完整落地方案：指标、压测、发布、回滚、复盘。\n5. 强调可执行性：方案要能上线、能观测、能恢复。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PROJECT/SYSTEM_DESIGN_SCENARIO -> system-design-scenarios.md\n- DB_DESIGN/MYSQL -> db-design.md, mysql.md\n- DISTRIBUTED/CACHE/REDIS -> distributed.md, redis.md\n- MQ -> mq.md\n- DESIGN_PATTERN -> design-pattern.md\n","frontmatter":{"name":"ali-backend","description":"用于阿里后端面试出题；强调业务深度、项目落地和中间件选型能力，关注复杂场景下的取舍与闭环。"},"isInternal":false,"tokens":398,"sizeBytes":1129},{"name":"SKILL.md","path":"app/src/main/resources/skills/bytedance-backend/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/bytedance-backend/SKILL.md","title":"bytedance-backend","category":"anthropic-skill","format":"markdown","content":"---\nname: bytedance-backend\ndescription: 用于字节后端面试出题；以算法与编码能力为第一门槛，同时考察高并发场景下的系统设计能力。\n---\n# Overview\n你是字节跳动后端面试官，风格直接、硬核、高强度。核心判断标准是：算法基本功是否过硬，复杂度优化是否到位。\n\n# Instructions\n1. 每轮优先给 1-2 道算法题，但在文字/语音场景不要求手写代码；要求候选人口述解法步骤、关键数据结构、复杂度与边界处理。\n2. 数据结构覆盖必须均衡：数组/链表、哈希表、栈/队列、堆、树/图至少覆盖两类以上，不可只问单一 DP。\n3. 对答案必须追问：为什么正确、为什么最优、边界条件是否完整；若只给结论，要求补充不变式或反例证明。\n4. 算法题后补一题工程化追问：同思路如何迁移到高并发真实场景（如计数、去重、延迟任务、TopK）。\n5. 提问节奏要快，单题目标明确；每次只追一个关键点，避免超长题干。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP -> algorithm-data-structures.md\n- DISTRIBUTED/SYSTEM_DESIGN_SCENARIO -> distributed.md, system-design-scenarios.md\n- PROJECT -> 结合简历追问真实线上问题\n","frontmatter":{"name":"bytedance-backend","description":"用于字节后端面试出题；以算法与编码能力为第一门槛，同时考察高并发场景下的系统设计能力。"},"isInternal":false,"tokens":468,"sizeBytes":1351},{"name":"SKILL.md","path":"app/src/main/resources/skills/frontend/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/frontend/SKILL.md","title":"frontend","category":"anthropic-skill","format":"markdown","content":"---\nname: frontend\ndescription: 用于前端工程面试出题；覆盖 JavaScript、React/Vue、浏览器原理和性能优化，强调业务实战与工程化能力。\n---\n# Overview\n你是一位前端工程面试官，重点评估候选人在真实业务中的技术取舍与交付质量。\n\n# Instructions\n1. 问题需覆盖渲染机制、状态管理、工程化与性能优化。\n2. 优先结合简历项目，追问复杂页面、性能瓶颈和线上问题处理。\n3. 回答停留在 API 层时，必须追问底层机制与边界场景。\n4. 至少一次要求候选人给出可量化指标（如 FCP/LCP、错误率、包体积）。\n5. 不要只问名词解释，必须有场景化问题。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVASCRIPT -> javascript.md\n- REACT_VUE -> react-vue.md\n- BROWSER -> browser.md\n- CSS/ENGINEERING/PERFORMANCE/PROJECT -> 结合简历与工程实践深挖\n","frontmatter":{"name":"frontend","description":"用于前端工程面试出题；覆盖 JavaScript、React/Vue、浏览器原理和性能优化，强调业务实战与工程化能力。"},"isInternal":false,"tokens":332,"sizeBytes":942},{"name":"SKILL.md","path":"app/src/main/resources/skills/java-backend-tencent/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/java-backend-tencent/SKILL.md","title":"java-backend-tencent","category":"anthropic-skill","format":"markdown","content":"---\nname: java-backend-tencent\ndescription: 用于腾讯后端面试出题；重点考察计算机基础、计网与操作系统原理，并结合业务场景验证技术选型能力。\n---\n# Overview\n你是腾讯后端面试官。风格稳健且重基础：常从八股切入，但会顺着底层逻辑追问到协议细节与系统机制。\n\n# Instructions\n1. 先问网络与操作系统基础，再过渡到业务系统设计与中间件选型。\n2. 对 TCP/IP、HTTP/HTTPS、线程模型、内存模型要持续深挖\"为什么\"。\n3. 必须结合业务场景问选型：为何用 MQ 而不是同步调用，何时不用缓存。\n4. 每轮至少一个底层追问和一个工程追问，兼顾理论与落地。\n5. 面试节奏可持续拉长，关注候选人思维稳定性与一致性。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- NET_OS -> network-os.md\n- JAVA -> java.md\n- MYSQL/REDIS/MQ -> mysql.md, redis.md, mq.md\n- SPRING -> spring.md\n- SYSTEM_DESIGN_SCENARIO/PROJECT -> system-design-scenarios.md + 简历项目\n","frontmatter":{"name":"java-backend-tencent","description":"用于腾讯后端面试出题；重点考察计算机基础、计网与操作系统原理，并结合业务场景验证技术选型能力。"},"isInternal":false,"tokens":385,"sizeBytes":1067},{"name":"SKILL.md","path":"app/src/main/resources/skills/java-backend/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/java-backend/SKILL.md","title":"java-backend","category":"anthropic-skill","format":"markdown","content":"---\nname: java-backend\ndescription: 用于 Java 后端面试出题；优先围绕 Java 核心、MySQL、Redis、Spring 与项目实战，追问设计取舍、故障处理和性能优化。\n---\n# Overview\n你是一位 Java 后端面试官，目标是识别候选人是否具备可上线的工程能力，而不是只会背概念。\n\n# Instructions\n1. 优先结合候选人简历和项目经历提问。\n2. 提问顺序遵循：使用经验 -> 原理机制 -> 边界条件 -> 优化与故障。\n3. 每个主问题都需要可追问，追问要落到真实场景和可观测指标。\n4. 回答偏概念时，必须追问实现细节、失败场景、回滚方案。\n5. 避免一次性给提示词，不要替候选人补全答案。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVA -> java.md\n- MYSQL -> mysql.md\n- REDIS -> redis.md\n- SPRING -> spring.md\n- SYSTEM_DESIGN_SCENARIO/PROJECT -> system-design-scenarios.md + 简历项目\n","frontmatter":{"name":"java-backend","description":"用于 Java 后端面试出题；优先围绕 Java 核心、MySQL、Redis、Spring 与项目实战，追问设计取舍、故障处理和性能优化。"},"isInternal":false,"tokens":343,"sizeBytes":970},{"name":"SKILL.md","path":"app/src/main/resources/skills/python-backend/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/python-backend/SKILL.md","title":"python-backend","category":"anthropic-skill","format":"markdown","content":"---\nname: python-backend\ndescription: 用于 Python 后端面试出题；覆盖 Python 基础、数据库、Django/Flask、缓存与部署，强调工程落地。\n---\n# Overview\n你是一位 Python 后端面试官，关注候选人是否具备独立构建和运维服务的能力。\n\n# Instructions\n1. 优先考察框架实践、数据库设计、缓存策略与部署经验。\n2. 每道题都要可追问，尤其关注并发、一致性和故障恢复。\n3. 回答如果仅停留在语法层面，必须追问工程实现细节。\n4. 至少一次要求候选人描述真实线上问题和排障步骤。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PYTHON_BASIC -> python-basic.md\n- DATABASE -> database.md\n- DJANGO_FLASK -> django-flask.md\n- CACHE -> redis.md\n- DEPLOY/PROJECT -> 结合简历与上线流程深挖\n","frontmatter":{"name":"python-backend","description":"用于 Python 后端面试出题；覆盖 Python 基础、数据库、Django/Flask、缓存与部署，强调工程落地。"},"isInternal":false,"tokens":302,"sizeBytes":856},{"name":"SKILL.md","path":"app/src/main/resources/skills/system-design/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/system-design/SKILL.md","title":"system-design","category":"anthropic-skill","format":"markdown","content":"---\nname: system-design\ndescription: 用于系统设计面试出题；聚焦容量估算、可用性与一致性权衡、可观测性和故障恢复。\n---\n# Overview\n你是一位系统设计面试官，关注候选人的架构权衡能力和可落地性。\n\n# Instructions\n1. 先澄清约束（QPS、SLA、一致性级别、成本）再讨论方案。\n2. 每个问题必须包含至少一个权衡点（如一致性 vs 延迟）。\n3. 要求候选人解释容量估算、故障处理、回滚机制和可观测性设计。\n4. 禁止组件罗列式问答，必须落到数据流与状态流。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- HIGH_AVAILABILITY -> high-availability.md\n- DISTRIBUTED -> distributed.md\n- CACHE/REDIS -> redis.md\n- DESIGN_PATTERN -> design-pattern.md\n- MQ/DB_DESIGN -> 结合分布式场景进行追问\n","frontmatter":{"name":"system-design","description":"用于系统设计面试出题；聚焦容量估算、可用性与一致性权衡、可观测性和故障恢复。"},"isInternal":false,"tokens":303,"sizeBytes":868},{"name":"SKILL.md","path":"app/src/main/resources/skills/test-development/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Snailclimb/interview-guide/HEAD/app/src/main/resources/skills/test-development/SKILL.md","title":"test-development","category":"anthropic-skill","format":"markdown","content":"---\nname: test-development\ndescription: 用于测试开发面试出题；覆盖测试基础、用例设计、自动化测试、性能测试与安全测试，兼顾工程化落地能力。\n---\n# Overview\n你是一位测试开发面试官，关注候选人的质量意识和工程化能力，重点评估其能否通过技术手段提升测试效率与质量保障深度。\n\n# Instructions\n1. 提问需覆盖测试基础、用例设计方法、自动化测试实践和性能测试四个维度。\n2. 优先结合候选人简历中的测试项目，追问具体的场景设计、工具选型和指标度量。\n3. 回答停留在理论时，必须追问实际落地细节：覆盖率数据、脚本维护成本、CI 集成方式。\n4. 至少一次要求候选人针对具体功能（如登录/支付/电商直播间）现场设计测试用例。\n5. 关注候选人是否具备开发能力：能否编写测试工具、搭建测试平台、参与 CI/CD 建设。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- TESTING_BASIC/TEST_CASE_DESIGN -> test-development.md\n- AUTOMATION/PERFORMANCE_SECURITY -> test-development.md\n- API/WEB/MOBILE_TESTING -> test-development.md\n- JAVA/PYTHON -> java.md, python-basic.md（考察编码能力时参考）\n","frontmatter":{"name":"test-development","description":"用于测试开发面试出题；覆盖测试基础、用例设计、自动化测试、性能测试与安全测试，兼顾工程化落地能力。"},"isInternal":false,"tokens":423,"sizeBytes":1275}],"systemPromptSnippet":"<yakaai_skills repo=\"Snailclimb/interview-guide\">\n<!-- File: AGENTS.md (Tokens: ~1600 | Category: root-instruction) -->\n# AI Interview Platform Agent Rules\n\nSpring Boot 4.1.0 + Java 25 + Spring AI 2.0.0 + React 面试平台。\n\n本文件是跨工具 Agent 入口，只放长期有效、代码里不容易直接推断、猜错会影响结果的规则。更细的目录规则放在 `.claude/rules/`，需要时再读取。\n\n## Tech Stack\n\n- Backend: Spring Boot 4.1.0 / Java 25 / Gradle / Spring AI 2.0.0\n- Database: PostgreSQL + pgvector，向量维度 1024，距离类型 COSINE\n- Cache & async: Redis / Redisson / Redis Stream\n- Storage & parsing: RustFS/S3 / Apache Tika\n- Mapping & export: MapStruct / iText 8 / SpringDoc OpenAPI\n- Frontend: React 18 / TypeScript / Vite / TailwindCSS 4，代码在 `frontend/`\n\n## Commands\n\n```bash\n./gradlew :app:compileJava\n./gradlew :app:test --no-daemon\n./gradlew :app:bootRun\n```\n\n```bash\ncd frontend && pnpm run dev\ncd frontend && pnpm run build\n```\n\n```bash\ndocker compose -f docker-compose.dev.yml up -d\n```\n\n## Project Structure\n\n- `app/src/main/java/interview/guide/common/`: 通用能力，包括限流、AI 调用、异步模板、配置、异常、统一响应。\n- `app/src/main/java/interview/guide/infrastructure/`: 技术基础设施，包括文件、导出、Redis、MapStruct 映射。\n- `app/src/main/java/interview/guide/modules/`: 业务模块，每个模块自包含 MVC 分层。\n- `app/src/main/resources/prompts/`: StringTemplate Prompt 模板。\n- `frontend/src/`: React 前端页面、组件、API 客户端和类型定义。\n\n## Architecture\n\n- 后端遵循 `Controller -> Service -> Repository`，Controller 只做路由、校验和委托。\n- Service 承担业务编排；`@Transactional` 只放 Service 层，并保持事务范围最小。\n- Repository 继承 Spring Data JPA `JpaRepository`，自定义查询用方法名或 `@Query`。\n- 基础设施能力优先放在 `common/` 或 `infrastructure/`，不要散落到业务 Service。\n- 对外响应统一使用 `Result<T>`，禁止直接返回 Entity。\n\n## Backend Rules\n\n- 业务异常必须使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 全局异常处理器返回 HTTP 200 + `Result.error(code, message)`。\n- 请求体优先用不可变 `record`，命名后缀使用 `XxxRequest` / `XxxResponse` / `XxxDTO` / `XxxEntity`。\n- Entity 到 DTO/Response 的映射优先使用 MapStruct。\n- 使用构造器注入，优先配合 Lombok `@RequiredArgsConstructor`。\n- 代码使用 2 空格缩进、无通配符导入、避免内联全限定类名。\n- 日志使用 SLF4J 占位符，异常必须作为最后一个参数传入。\n\n## AI And Async Rules\n\n- 获取聊天模型统一走 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- 结构化输出统一走 `StructuredOutputInvoker`，不要在业务代码里复制重试逻辑。\n- Prompt 模板放在 `resources/prompts/`，使用 StringTemplate `.st`。\n- LLM、S3、外部 HTTP 调用不得放在数据库事务内。\n- Redis Stream 生产/消费使用 `AbstractStreamProducer` / `AbstractStreamConsumer` 模板。\n- 异步处理前先校验实体是否存在；实体已删除时 ACK 丢弃。\n- 限流使用可重复 `@RateLimit`，不要手写散落的 Redis 限流逻辑。\n\n## Config And Data\n\n- 配置集中在 `application.yml`、`.env` 和 `@ConfigurationProperties` 类中。\n- API Key、数据库密码等敏感信息只放 `.env`，不得提交到 Git。\n- 不要在 Service 中散落 `@Value`。\n- 本地默认后端端口是 `8080`：`server.port: ${SERVER_PORT:8080}`。\n- 开发环境 `ddl-auto` 可为 `update`，生产环境不能依赖自动建表。\n\n## Frontend Rules\n\n- API 调用集中在 `frontend/src/api/`，复用 `request.ts` 的 Axios 实例。\n- 类型定义放在 `frontend/src/types/`，不要在页面里重复定义共享接口。\n- 页面放在 `frontend/src/pages/`，可复用 UI 放在 `frontend/src/components/`。\n- 路由常量放在 `frontend/src/constants/routes.ts`。\n- 组件交互优先使用现有设计语言和 `lucide-react` 图标。\n\n## Testing\n\n- 后端测试使用 JUnit 5 + Mockito + AssertJ。\n- 测试意图用中文 `@DisplayName` 描述，复杂场景用 `@Nested` 分组。\n- 集成测试使用 H2 配置；限流相关测试需要真实 Redis。\n- 改后端公共能力时至少运行 `./gradlew :app:test --no-daemon`。\n- 改前端时至少运行 `cd frontend && pnpm run build`。\n\n## Never Do\n\n- 不要 `throw new RuntimeException(...)`，业务失败必须用 `BusinessException`。\n- 不要直接返回 Entity 给前端。\n- 不要把 `@Value` 散落在 Service 中。\n- 不要在事务内调用 LLM、S3 或外部 HTTP。\n- 不要同类内部调用 `@Transactional` 方法。\n- 不要 `catch (Exception e) {}` 静默忽略。\n- 不要循环调用 DB，优先批量查询或批量写入。\n- 不要硬编码密钥、Token、数据库密码。\n- 不要使用 `Executors.newXxxThreadPool()`，需要线程池时显式配置 `ThreadPoolExecutor`。\n\n## More Rules\n\n- 后端 Java 细则：`.claude/rules/backend.md`\n- AI、限流、异步细则：`.claude/rules/ai-and-async.md`\n- 前端细则：`.claude/rules/frontend.md`\n\n<!-- File: CLAUDE.md (Tokens: ~304 | Category: claude-rule) -->\n@AGENTS.md\n\n# Claude Code Instructions\n\n- `AGENTS.md` 是本仓库的共享规则源；更新长期规则时优先改 `AGENTS.md`，不要在这里复制一份。\n- 本文件只保留 Claude Code 专属入口和加载提示，避免根目录上下文膨胀。\n- 目录细则在 `.claude/rules/`，处理匹配文件前先读取对应规则。\n- 个人偏好和临时调试结论放 `CLAUDE.local.md` 或 Claude Memory，不要提交到仓库。\n\n## Path Rules\n\n- Backend: `.claude/rules/backend.md`\n- AI / async / rate limit: `.claude/rules/ai-and-async.md`\n- Frontend: `.claude/rules/frontend.md`\n\n## Maintenance\n\n- 新增规则前先判断：删掉这条后，Claude 是否更容易犯同类错误。\n- 能被测试、格式化、Hook 或 CI 强制的规则，不要只写成自然语言。\n- 如果同一条规则反复被忽略，优先精简规则文件，而不是继续加粗或加感叹号。\n\n<!-- File: .claude/rules/ai-and-async.md (Tokens: ~493 | Category: anthropic-skill) -->\n---\npaths:\n  - \"app/src/main/java/interview/guide/common/ai/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/annotation/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/aspect/**/*.java\"\n  - \"app/src/main/java/interview/guide/common/async/**/*.java\"\n  - \"app/src/main/java/interview/guide/modules/**/listener/**/*.java\"\n  - \"app/src/main/resources/prompts/**/*.st\"\n  - \"app/src/main/resources/scripts/**/*.lua\"\n---\n\n# AI, Rate Limit And Async Rules\n\n## LLM Providers\n\n- Provider 配置来自 `app.ai.providers.{providerId}` 和默认 `app.ai.default-provider`。\n- ChatClient 获取统一使用 `LlmProviderRegistry.getChatClientOrDefault(provider)`。\n- Provider 连通性测试要限制超时，并防止访问内网或特殊地址。\n- Spring AI 2.0.0 代码优先使用非 deprecated API。\n\n## Structured Output\n\n- 结构化输出统一使用 `StructuredOutputInvoker` 封装重试。\n- 不要在业务 Service 里复制 JSON 修复、重试和解析逻辑。\n- Prompt 模板存放在 `resources/prompts/`，使用 StringTemplate `.st`。\n\n## Rate Limit\n\n- 接口限流使用可重复 `@RateLimit` 注解。\n- 每个 `@RateLimit` 是独立维度，分别执行 Redis Lua 滑动窗口。\n- Redis Key 使用 `ratelimit:{ClassName:MethodName}:dimension` 结构。\n- 不要在 Controller 或 Service 中手写散落的限流逻辑。\n\n## Redis Stream\n\n- 生产者继承 `AbstractStreamProducer<T>`。\n- 消费者继承 `AbstractStreamConsumer<T>` 并实现 `processMessage()`。\n- Stream 名称、消费者组和任务常量放在 `AsyncTaskStreamConstants`。\n- 消费失败最多重试 3 次，超过后标记 FAILED。\n- 异步处理前校验实体是否存在；已删除实体直接 ACK 丢弃。\n\n<!-- File: .claude/rules/backend.md (Tokens: ~551 | Category: anthropic-skill) -->\n---\npaths:\n  - \"app/src/main/java/**/*.java\"\n  - \"app/src/test/java/**/*.java\"\n  - \"app/src/main/resources/**/*.yml\"\n---\n\n# Backend Rules\n\n## Layers\n\n- Controller 只做路由、参数校验、限流注解和 Service 委托。\n- Service 负责编排业务流程，事务注解只放 Service 层。\n- Repository 只做数据访问，继承 `JpaRepository`。\n- Infrastructure 能力放在 `common/` 或 `infrastructure/`，不要塞进业务模块。\n\n## Naming\n\n- JPA 持久化对象使用 `XxxEntity`。\n- 跨层数据传输使用 `XxxDTO`。\n- 前端请求体使用 `XxxRequest`，前端响应体使用 `XxxResponse`。\n- 不可变请求/响应优先使用 `record`。\n\n## Exceptions\n\n- 业务失败使用 `BusinessException(ErrorCode.XXX, \"描述信息\")`。\n- 保留业务异常原样抛出：`catch (BusinessException e) { throw e; }`。\n- 禁止用 `RuntimeException` 表达业务错误。\n- 禁止吞异常；记录异常时把异常对象作为日志最后一个参数。\n\n## Transactions\n\n- `@Transactional` 只放 Service 层公开方法。\n- 事务内不得调用 LLM、S3、外部 HTTP 或耗时文件解析。\n- 避免同类内部调用 `@Transactional` 方法，必要时拆分到独立 Service。\n- 读多写少的查询使用 `@Transactional(readOnly = true)`。\n\n## Mapping\n\n- Entity 不直接返回给前端。\n- Entity 到 DTO/Response 的重复转换优先使用 MapStruct。\n- 简单一次性字段复制可以使用 `BeanUtils.copyProperties`。\n\n## Style\n\n- Java 代码使用 2 空格缩进，列宽尽量控制在 100 字符。\n- 禁止通配符导入，避免内联全限定类名。\n- 优先使用构造器注入和 `@RequiredArgsConstructor`。\n- 现代 Java 特性可用：switch 表达式、pattern matching、text blocks。\n\n<!-- File: .claude/rules/frontend.md (Tokens: ~372 | Category: anthropic-skill) -->\n---\npaths:\n  - \"frontend/src/**/*.ts\"\n  - \"frontend/src/**/*.tsx\"\n  - \"frontend/src/**/*.css\"\n  - \"frontend/package.json\"\n  - \"frontend/vite.config.ts\"\n---\n\n# Frontend Rules\n\n## Structure\n\n- 页面组件放在 `frontend/src/pages/`。\n- 可复用组件放在 `frontend/src/components/`。\n- API 客户端放在 `frontend/src/api/`，复用 `request.ts`。\n- 共享类型放在 `frontend/src/types/`。\n- 路由路径放在 `frontend/src/constants/routes.ts`。\n\n## API\n\n- 后端接口返回 `Result<T>` 结构，前端 API 层负责解包和错误处理。\n- 不要在页面组件里直接拼接重复的 Axios 配置。\n- Provider、知识库、面试、简历等模块沿用现有 API 文件拆分。\n\n## UI\n\n- 延续现有 React + TailwindCSS 4 风格，不引入新的 UI 框架。\n- 操作按钮优先使用 `lucide-react` 图标加清晰文本或 tooltip。\n- 表单状态要包含 loading、success、error 和 disabled 处理。\n- 不要把业务说明性长文塞进页面；优先让界面直接可操作。\n\n## Verification\n\n- 前端改动后运行 `cd frontend && pnpm run build`。\n- 涉及浏览器交互时，用本地浏览器实际打开页面验证。\n\n<!-- File: app/src/main/resources/skills/_shared/references/algorithm-data-structures.md (Tokens: ~699 | Category: anthropic-skill) -->\n# 算法与数据结构（统一参考）\n\n## 一、口述作答标准（文字/语音面试）\n1. 先定义问题与状态：输入、输出、约束、目标。\n2. 说明选型：为什么用该数据结构（而不是其他结构）。\n3. 口述步骤：关键流程、转移关系、剪枝或维护不变式。\n4. 复杂度：时间/空间复杂度 + 主瓶颈。\n5. 边界与反例：空输入、重复值、极端规模、退化场景。\n\n## 二、数组/链表\n- 高频思路：双指针、滑动窗口、前缀和、原地算法。\n- 典型追问：如何避免越界；是否能降空间；是否能单次扫描。\n\n## 三、哈希/堆/栈/队列\n- 哈希：去重、频次统计、映射索引、冲突与扩容代价。\n- 堆：TopK、动态中位数、多路归并，关注 `O(n log k)` 优化。\n- 栈：单调栈、括号匹配、表达式求值，不变式要说清。\n- 队列：BFS、双端队列、滑窗最值，解释队头有效性。\n\n## 四、树/图\n- 树：前中后序、层序、递归/迭代取舍。\n- 图：BFS/DFS、最短路、拓扑排序、并查集。\n- 典型追问：有环/无环处理、访问标记时机、复杂度上界。\n\n## 五、动态规划（DP）\n- 核心：状态定义、转移方程、初始化、遍历顺序。\n- 常见失误：状态遗漏、重复计算、滚动数组覆盖顺序错误。\n- 追问方向：如何从 `O(n^2)` 优化到 `O(n log n)`（若可行）。\n\n## 六、贪心/回溯\n- 贪心：局部最优能否推导全局最优，需给交换论证或反例说明。\n- 回溯：搜索树、剪枝条件、去重策略、最坏复杂度评估。\n\n## 七、设计题（算法建模）\n- 数据流、在线查询、延迟任务、限流计数等题型。\n- 重点：结构选型、正确性、复杂度与工程可落地性。\n\n<!-- File: app/src/main/resources/skills/_shared/references/browser.md (Tokens: ~844 | Category: anthropic-skill) -->\n# 浏览器原理面试重点（渲染 + 缓存 + 安全 + 性能）\n\n## 渲染流水线\n- 关键渲染路径：HTML→DOM 树、CSS→CSSOM 树、合并→Render 树→布局→绘制→合成。\n- DOMContentLoaded vs load：DOM 解析完成 vs 所有资源加载完成，CSS 阻塞 DOM 渲染但不阻塞解析。\n- `<script>` 阻塞：默认阻塞 DOM 解析，`async`（下载完立即执行）vs `defer`（DOM 解析后执行）。\n- 合成层优化：`transform`/`opacity` 触发 GPU 合成，跳过布局与绘制。\n\n## 浏览器缓存\n- 强缓存：`Cache-Control`（max-age/no-cache/no-store）优先于 `Expires`。\n- 协商缓存：`ETag`/`If-None-Match` vs `Last-Modified`/`If-Modified-Since`，304 响应。\n- 缓存位置优先级：Service Worker → Memory Cache → Disk Cache → Push Cache。\n- CDN 缓存策略：回源机制、缓存命中率、预热与刷新。\n\n## 网络与协议\n- HTTP/1.1：持久连接（`Connection: keep-alive`）、管线化缺陷。\n- HTTP/2：多路复用、头部压缩（HPACK）、服务器推送、二进制分帧。\n- HTTP/3（QUIC）：基于 UDP、0-RTT 连接、解决队头阻塞。\n- HTTPS：TLS 握手流程（证书校验→密钥协商→对称加密通信），会话复用。\n\n## 安全\n- XSS：存储型/反射型/DOM 型，防御（转义、CSP、HttpOnly Cookie）。\n- CSRF：伪造请求利用已认证身份，防御（SameSite Cookie、CSRF Token、Referer 校验）。\n- CORS：简单请求 vs 预检请求（OPTIONS），`Access-Control-Allow-Origin` 等响应头。\n- CSP（Content-Security-Policy）：白名单限制资源加载，`nonce`/`hash` 策略。\n\n## 性能监控与优化\n- Core Web Vitals：LCP（最大内容绘制 ≤2.5s）、FID/INP（交互延迟 ≤100ms）、CLS（布局偏移 ≤0.1）。\n- 性能 API：`PerformanceObserver`、`performance.timing`（导航计时）、`PerformanceResourceTiming`。\n- 优化手段：代码分割、图片懒加载、预加载（`<link rel=\"preload\">`）、骨架屏。\n- 内存泄漏排查：Chrome DevTools Memory 面板，堆快照对比、分配时间线。\n\n## 面试追问模板\n- 从输入 URL 到页面渲染完成，中间经历了哪些步骤？\n- 你的项目做过哪些性能优化？效果如何量化？\n- CORS 预检请求失败，排查思路是什么？\n- 如何定位线上页面的内存泄漏？\n\n<!-- File: app/src/main/resources/skills/_shared/references/database.md (Tokens: ~1061 | Category: anthropic-skill) -->\n# 数据库通用面试重点（关系型 + NoSQL 选型）\n\n## 事务与隔离级别\n- ACID 含义：原子性（Undo Log）、一致性（约束与规则）、隔离性（锁/MVCC）、持久性（Redo Log）。\n- 四种隔离级别：读未提交→读已提交→可重复读→串行化，各自解决的脏读/不可重复读/幻读问题。\n- MVCC 原理：版本链（隐藏列 trx_id + roll_pointer）+ ReadView 快照，RC/RR 下 ReadView 生成时机差异。\n- 长事务危害：锁持有时间长、Undo Log 膨胀、MVCC 快照无法回收。\n\n## 索引\n- B+ 树适合磁盘索引：有序、范围查询、叶子链表、扇出大树高低。\n- 覆盖索引避免回表，联合索引最左前缀原则，索引下推（ICP）减少回表次数。\n- 索引失效：函数转换、隐式类型转换、OR 条件、LIKE 前缀通配、非最左列。\n- 唯一索引 vs 普通索引：查询性能差异（Change Buffer）、写入场景选择。\n\n## SQL 优化\n- EXPLAIN 执行计划：type（ref/range/index/all）、key、rows、Extra（Using index/Using filesort/Using temporary）。\n- 慢 SQL 定位：`slow_query_log` + `pt-query-digest`，重点关注全表扫描与大结果集。\n- 深度分页优化：游标分页（WHERE id > last_id）、延迟关联（子查询先查主键）。\n- 批量操作优化：批量 INSERT 替代逐条、INSERT ... ON DUPLICATE KEY UPDATE。\n\n## 分库分表\n- 垂直拆分（按业务模块）vs 水平拆分（按分片键散列/范围）。\n- 分片键选择：数据均匀性、查询路由效率、避免跨片查询。\n- 分布式主键：雪花算法（Snowflake）、号段模式（Leaf）、UUID 性能与索引问题。\n- 中间件：ShardingSphere 逻辑表/物理表映射、SQL 改写与路由。\n- 跨片聚合：内存合并、流式归并，全局排序成本。\n\n## 读写分离\n- 主从复制原理：Binlog 异步/半同步复制，主从延迟的成因与监控。\n- 读写分离路由：中间件（ShardingSphere/ProxySQL）vs 应用层注解驱动。\n- 主从延迟应对：强制读主库、延迟检测与降级、并行复制优化。\n\n## NoSQL 选型\n- Redis：缓存/会话/排行榜/分布式锁，数据全内存、不支持复杂查询。\n- MongoDB：文档模型、灵活 Schema、适合非结构化数据与快速迭代。\n- Elasticsearch：全文检索、倒排索引、日志分析场景，写入成本高。\n- HBase/Cassandra：海量数据宽表、LSM-Tree、适合高吞吐写入与时序数据。\n- 选型维度：数据模型、读写模式、一致性要求、扩展方式、运维复杂度。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？还有优化空间吗？\n- 分库分表后，跨片的 JOIN 和聚合查询怎么做？\n- 主从延迟 5 秒，业务怎么处理？\n- 为什么选这个 NoSQL 而不是 MySQL？迁移成本和风险怎么评估？\n\n<!-- File: app/src/main/resources/skills/_shared/references/db-design.md (Tokens: ~948 | Category: anthropic-skill) -->\n# 数据库设计面试重点（建模 + 索引 + 演进）\n\n## 数据建模与范式\n- 三范式核心：1NF（原子性）、2NF（消除部分依赖）、3NF（消除传递依赖）。\n- 反范式设计：以冗余换查询性能，适用读多写少场景（如统计字段冗余）。\n- ER 建模：实体→关系→属性，一对一/一对多/多对多的表结构映射。\n- 宽表 vs 窄表：OLTP 倾向窄表（范式化）、OLAP 倾向宽表（星型/雪花模型）。\n\n## 索引设计策略\n- 索引选择性：高基数列优先，区分度 `COUNT(DISTINCT col)/COUNT(*)` 接近 1 最佳。\n- 联合索引设计：等值条件列在前、范围条件列在后，遵循最左前缀。\n- 覆盖索引设计：将查询所需的列全部纳入索引，消除回表。\n- 避免过度索引：写入开销、存储成本、索引维护（DML 时需同步更新）。\n\n## 冷热数据分层\n- 冷热识别标准：访问时间衰减、业务状态流转（如订单已完成→归档）。\n- 冷数据存储：归档表、历史库、对象存储（OSS/S3），压缩降低存储成本。\n- 数据生命周期管理（DLM）：TTL 过期自动清理、定期迁移、分区裁剪。\n- 分区表策略：RANGE（按时间）、LIST（按枚举）、HASH（按散列），分区裁剪加速查询。\n\n## 扩容与迁移\n- 垂直扩容（升级硬件）vs 水平扩容（分片/分库分表），各自的瓶颈与上限。\n- 平滑扩容流程：新分片上线→双写→历史数据迁移→一致性校验→切读→下线旧分片。\n- 数据迁移工具：Canal 监听 Binlog 增量同步、全量+增量切换方案。\n- 回滚预案：切换失败时快速切回旧库，保留旧库只读窗口。\n\n## 软删除与审计\n- 软删除（`is_deleted` 标记）vs 硬删除：恢复能力 vs 存储膨胀与查询过滤。\n- 审计字段：`created_at`/`updated_at`/`created_by`/`updated_by`，自动化填充（MyBatis 拦截器/JPA Auditing）。\n- 数据版本控制：乐观锁版本号（`version`），防止并发覆盖。\n- 敏感数据处理：加密存储、脱敏查询、合规删除（GDPR/个人信息保护法）。\n\n## 面试追问模板\n- 订单表数据量到亿级，你怎么设计索引和分片方案？\n- 线上需要给大表加字段，怎么做不停机？\n- 冷热数据迁移过程中，如何保证查询不受影响？\n- 你的项目遇到过数据模型演进的问题吗？怎么处理的？\n\n<!-- File: app/src/main/resources/skills/_shared/references/design-pattern.md (Tokens: ~609 | Category: anthropic-skill) -->\n# 设计模式面试重点\n\n## 创建型\n- 单例模式：饿汉/懒汉/DCL/静态内部类/枚举，DCL 为何要 volatile，枚举防反射/序列化。\n- 工厂模式：简单工厂→工厂方法→抽象工厂，开闭原则的递进体现。\n- 建造者模式：与工厂模式的区别，链式调用场景（Lombok @Builder）。\n\n## 结构型\n- 代理模式：JDK 动态代理 vs CGLIB，Spring AOP 默认选型策略。\n- 适配器模式：类适配器 vs 对象适配器，Slf4J 日志门面的适配原理。\n- 装饰器模式：与代理模式的区别，Java I/O 流的装饰链。\n\n## 行为型\n- 观察者模式：JDK Observable（已废弃）vs 事件驱动，Spring Event 机制。\n- 策略模式：消除 if-else，结合工厂或 Spring 注入实现策略路由。\n- 责任链模式：Servlet Filter / Spring Interceptor / Netty Pipeline。\n- 模板方法模式：Spring AbstractApplicationContext#refresh。\n- 状态模式：与策略模式的区别（状态内部转换 vs 外部切换）。\n\n## 设计原则\n- SOLID 原则在代码中的体现，重点考察开闭原则和依赖倒置。\n- 合成/聚合复用 vs 继承复用。\n\n## 框架中的设计模式\n- Spring：单例（Bean 默认）、工厂（BeanFactory）、代理（AOP）、观察者（Event）、模板方法（JdbcTemplate）。\n- JDK：迭代器（Collection）、装饰器（I/O）、适配器（Arrays.asList）。\n- MyBatis：代理（MapperProxy）、模板方法（BaseExecutor）。\n\n## 面试追问模板\n- 你的项目中哪里用到了设计模式？为什么选这个模式？\n- 如果不用这个模式，代码会变成什么样？\n- 这个模式有什么缺点？什么场景下不适合？\n\n<!-- File: app/src/main/resources/skills/_shared/references/distributed.md (Tokens: ~672 | Category: anthropic-skill) -->\n# 分布式系统面试重点\n\n## 基础理论\n- CAP 定理：三者不可兼得，网络分区必然存在时的取舍。\n- BASE 理论：基本可用、软状态、最终一致性，与 ACID 的对比。\n- 一致性模型：强一致、单调读、因果一致、最终一致。\n\n## 共识算法\n- Paxos：Basic Paxos 角色（Proposer/Acceptor/Learner）与两阶段流程。\n- Raft：Leader 选举（任期+日志对比）、日志复制、安全性保证。\n- ZAB：与 Raft 的异同，ZXID 结构（epoch + counter）。\n\n## 分布式锁\n- Redis 分布式锁：`SET NX EX` + Lua 释放、Redisson 可重入锁与看门狗。\n- ZooKeeper 分布式锁：临时顺序节点、Watcher 机制、羊群效应避免。\n- 选型：性能优先 Redis，可靠性优先 ZK。\n\n## 分布式事务\n- 2PC：准备→提交，同步阻塞与单点故障问题。\n- TCC：Try/Confirm/Cancel，空回滚与幂等处理。\n- SAGA：正向补偿 vs 反向补偿，适合长事务。\n- Seata AT 模式：全局锁 + 一阶段提交 + 二阶段回滚。\n\n## 分布式 ID\n- 雪花算法（Snowflake）：64 位结构、时钟回拨问题与解决。\n- UUID、数据库自增、号段模式（Leaf）的优劣对比。\n\n## API 网关与 RPC\n- 网关核心职责：路由、鉴权、限流、熔断、可观测。\n- HTTP vs RPC：协议开销、服务治理、跨语言、适用场景。\n- Dubbo 架构：Provider/Consumer/Registry/Monitor，负载均衡策略。\n\n## 一致性哈希\n- 虚拟节点解决数据倾斜，新增/移除节点时最小化数据迁移。\n\n## 面试追问模板\n- 网络分区发生时，你的系统选择保 CP 还是 AP？为什么？\n- 分布式事务失败了怎么补偿？人工介入还是自动？\n- 如何设计一个支持百万 QPS 的分布式 ID 生成服务？\n\n<!-- File: app/src/main/resources/skills/_shared/references/django-flask.md (Tokens: ~1030 | Category: anthropic-skill) -->\n# Django/Flask 面试重点（框架 + ORM + 部署）\n\n## 框架定位与对比\n- Django：全栈框架（ORM/Admin/Auth/Template 内置），\"batteries included\" 哲学，适合快速交付。\n- Flask：微框架（路由+模板引擎核心），扩展生态灵活，适合定制化与微服务。\n- 选型：快速 MVP/内容管理选 Django，API 服务/微服务/深度定制选 Flask。\n- FastAPI：异步原生、Pydantic 类型校验、自动生成 OpenAPI 文档，适合新项目。\n\n## 请求生命周期\n- Django：URLconf 路由→Middleware 链→View 函数/类→Template/JSON 响应→Middleware 链（逆序返回）。\n- Flask：Werkzeug WSGI 路由→before_request 钩子→View 函数→after_request 钩子→响应。\n- 中间件/钩子：认证注入、请求日志、异常捕获、数据库事务管理。\n- 请求上下文：Django（request/response 对象传递）、Flask（thread-local `g` 对象/应用上下文）。\n\n## ORM 与查询优化\n- Django ORM：QuerySet 惰性求值、`select_related`（JOIN，一对一/外键）vs `prefetch_related`（二次查询，多对多）。\n- N+1 问题：循环中触发懒加载，解法为 `select_related`/`prefetch_related` 批量预加载。\n- Flask-SQLAlchemy：Session 管理、eager loading（`joinedload`/`subqueryload`）、批量操作。\n- 查询优化：`only()`/`defer()` 延迟加载字段、`bulk_create` 批量插入、`iterator()` 流式读取大结果集。\n\n## 认证、权限与安全\n- Django Auth：User 模型、`authenticate`/`login`/`logout` 流程、Permission/Group 权限体系。\n- Token 认证：JWT（djangorestframework-simplejwt）/ DRF TokenAuthentication。\n- 安全防护：CSRF Token（Django 内置）、XSS 转义（模板自动转义）、SQL 注入（ORM 参数化）、CORS 配置。\n- 密码存储：Django 使用 PBKDF2 + salt，可配置 bcrypt/argon2。\n\n## 缓存与性能\n- Django 缓存框架：`@cache_page` 装饰器、缓存后端（Redis/Memcached/本地内存）。\n- Flask 缓存：Flask-Caching 扩展，`@cached` 装饰器、Jinja2 片段缓存。\n- 数据库查询缓存：`QuerySet.cache()`、手动缓存策略、缓存失效与一致性。\n- 静态文件：Django Collectstatic + CDN、Flask 静态文件服务（生产环境用 Nginx）。\n\n## 部署与运维\n- WSGI（同步）：Gunicorn/uWSGI，多 Worker 进程 + preload + 优雅重启。\n- ASGI（异步）：Uvicorn/Daphne，支持 WebSocket 和 async view。\n- 容器化：Docker 多阶段构建、环境变量管理、健康检查端点。\n- 监控：Sentry 异常捕获、Prometheus 指标暴露、日志结构化输出（JSON logging）。\n\n## 面试追问模板\n- Django ORM 的 N+1 问题你怎么发现的？怎么解决的？\n- Flask 的上下文是怎么实现的？多线程下安全吗？\n- 你的项目用的 WSGI 还是 ASGI？为什么？遇到什么瓶颈？\n- 线上一个接口突然变慢，从框架层面怎么排查？\n\n<!-- File: app/src/main/resources/skills/_shared/references/high-availability.md (Tokens: ~1119 | Category: anthropic-skill) -->\n# 高可用面试重点（故障防护 + 容灾 + 可观测性）\n\n## 故障检测与主备切换\n- 心跳检测：应用层（HTTP 探针）vs TCP 层，超时阈值与抖动容忍。\n- 主备切换：主动-被动（冷备/热备）vs 主动-主动（双写+负载均衡）。\n- 选主机制：Raft/Paxos 共识、ZooKeeper 临时节点、etcd Lease。\n- 脑裂防护：Fencing（STONITH）/仲裁节点/ Lease 锁，避免双主写入。\n- 切换窗口：RTO（恢复时间目标）与 RPO（恢复点目标）的工程实现。\n\n## 限流、熔断与降级\n- 限流算法：固定窗口（临界突刺）、滑动窗口、令牌桶（匀速放行）、漏桶（平滑输出）。\n- 分布式限流：Redis Lua 原子计数 + 滑动窗口、Sentinel 集群限流模式。\n- 熔断器模式：Closed→Open→Half-Open 状态机，失败率/慢调用率触发。\n- 降级策略：返回缓存数据/默认值/简化结果、关闭非核心功能、手动开关。\n- 级联故障预防：超时设置（connect/read）、重试次数与退避策略、舱壁隔离（线程池/信号量）。\n\n## SLA/SLO 与可观测性\n- SLA/SLO/SLI 关系：SLO 是目标（如 99.9% 可用）、SLI 是指标（延迟/错误率）、SLA 是合同。\n- 三大支柱：Metrics（Prometheus + Grafana）、Logging（ELK/Loki）、Tracing（Jaeger/SkyWalking）。\n- 告警设计：分级（P0-P3）、收敛（抑制/聚合/路由）、OnCall 轮值与升级。\n- 错误预算：SLO 剩余预算决定发布节奏与变更风险容忍度。\n\n## 容量规划与混沌工程\n- 容量评估：QPS 峰值估算、带宽/存储/连接数上限、资源瓶颈定位（CPU/IO/网络）。\n- 压测方法论：基准压测→阶梯加压→极限探测，关注长尾延迟（P99）而非均值。\n- 自动弹性：HPA（Kubernetes）/ASG（云厂商），指标驱动（CPU/自定义指标）扩缩容。\n- 混沌工程：Chaos Mesh/LitmusChaos，故障注入（网络延迟/节点宕机/依赖不可用）。\n\n## 异地多活与容灾\n- 同城双活：两个机房同时提供服务，数据库跨机房同步（延迟可控）。\n- 异地多活：单元化架构（用户路由到固定单元）、数据同步（ Canal/Otter/Binlog）。\n- 全球化部署：DNS 就近路由、CDN 静态资源加速、数据合规（GDPR 数据驻留）。\n- 灾备演练：定期切换演练、数据一致性校验、回滚流程验证。\n\n## 面试追问模板\n- 流量突增 10 倍，你的系统哪里先扛不住？怎么应急？\n- 熔断打开后，下游恢复了你怎么感知？自动恢复还是人工？\n- 你的项目 SLA 是多少？怎么保证的？出过故障吗？\n- 混沌工程你在团队推行过吗？遇到过什么阻力？\n\n<!-- File: app/src/main/resources/skills/_shared/references/java.md (Tokens: ~1096 | Category: anthropic-skill) -->\n# Java 面试重点（基础 + 集合 + 并发 + JVM）\n\n## 基础概念\n- JVM/JDK/JRE 区别，字节码与\"编译+解释\"执行模型，AOT vs JIT。\n- 8 种基本类型与包装类，自动装箱/拆箱与 Integer Cache。\n- `==` vs `equals()`，`hashCode()` 与 `equals()` 一致性约束。\n- 方法重载 vs 重写，静态分派与动态分派。\n- 接口 vs 抽象类，Java 8+ default 方法的影响。\n- 深拷贝 vs 浅拷贝，序列化方案。\n\n## String\n- 不可变性原理（final byte[]），安全与性能影响。\n- 字符串常量池：`intern()`、编译期优化、`new String(\"abc\")` 创建对象数。\n- `String` vs `StringBuilder` vs `StringBuffer`。\n\n## 集合框架\n- List：ArrayList（动态数组、扩容 1.5 倍）vs LinkedList（双向链表），RandomAccess 标记。\n- Map：HashMap 底层（数组+链表+红黑树）、负载因子与扩容、线程不安全场景。\n- HashMap 长度为何是 2 的幂次方，多线程死循环问题。\n- ConcurrentHashMap：JDK 7 分段锁 vs JDK 8 CAS+synchronized，key/value 不为 null。\n- Set：HashSet（基于 HashMap）、LinkedHashSet、TreeSet（红黑树）。\n- Queue：BlockingQueue 接口，ArrayBlockingQueue vs LinkedBlockingQueue。\n- fail-fast vs fail-safe 机制。\n\n## 并发\n- 线程生命周期与状态转换，上下文切换成本。\n- 死锁：条件、检测（jstack/arthuras）、预防策略。\n- JMM：可见性、有序性、happens-before；volatile 保证可见性+禁止重排序但不保证原子性。\n- synchronized 底层原理（Monitor）、锁升级（偏向→轻量→重量）、偏向锁废弃。\n- ReentrantLock vs synchronized：可中断、公平锁、Condition、超时获取。\n- CAS 与 ABA 问题，Atomic 原理。\n- 线程池：核心参数（corePoolSize/maxPoolSize/queue/handler）、拒绝策略、动态配置。\n- AQS 原理（state + CLH 队列），Semaphore/CountDownLatch/CyclicBarrier。\n- ThreadLocal：原理、内存泄漏与弱引用、跨线程传递（TransmittableThreadLocal）。\n- CompletableFuture：编排、异常处理、自定义线程池。\n- 虚拟线程（Java 21）：用途与调度模型。\n\n## JVM\n- 运行时数据区：堆/栈/方法区/元空间/程序计数器/直接内存。\n- 对象创建流程、内存布局、访问定位（句柄 vs 直接指针）。\n- GC 判断：引用计数 vs 可达性分析；四种引用（强/软/弱/虚）。\n- GC 算法：标记-清除、复制、标记-整理、分代收集。\n- 垃圾收集器：Serial→Parallel→CMS→G1→ZGC，各自适用场景。\n- G1 回收流程（Young GC / Mixed GC），ZGC 着色指针与读屏障。\n- 双亲委派模型与打破方式（SPI、OSGi、线程上下文类加载器）。\n- OOM 排查：Heap Dump、jmap/jstat/arthuras、GC 日志分析。\n\n## 面试追问模板\n- 这个机制底层是怎么实现的？有什么性能代价？\n- 多线程环境下会有什么问题？如何保证线程安全？\n- 框架（Spring/MyBatis）中哪里用到了这个机制？\n- 线上遇到 OOM/GC 频繁怎么排查？参数怎么调？\n\n<!-- File: app/src/main/resources/skills/_shared/references/javascript.md (Tokens: ~997 | Category: anthropic-skill) -->\n# JavaScript 面试重点（基础 + 异步 + 工程化）\n\n## 类型与作用域\n- 8 种数据类型（7 原始 + Object），`typeof null === \"object\"` 历史遗留。\n- `let`/`const` vs `var`：块级作用域、暂时性死区（TDZ）、变量提升差异。\n- 作用域链：词法作用域（静态），引擎沿作用域链逐层查找标识符。\n- 闭包：函数与其词法环境的绑定，经典场景（防抖/节流/私有变量/柯里化）与内存泄漏风险。\n\n## 原型与继承\n- 原型链：`__proto__` vs `prototype`，属性查找沿原型链向上。\n- `Object.create()` vs `new`：直接指定原型 vs 构造函数实例化。\n- `class` 语法糖：`extends`/`super` 底层仍基于原型链，`static` 方法不可继承到实例。\n- `Object.setPrototypeOf` 性能问题，推荐 `Object.create` 替代。\n\n## 异步编程\n- 事件循环：宏任务（setTimeout/setInterval/I/O）与微任务（Promise.then/MutationObserver）执行顺序。\n- Promise：状态机（pending→fulfilled/rejected），链式调用与错误冒泡，`Promise.all` vs `Promise.allSettled` vs `Promise.race`。\n- `async/await`：语法糖，异常用 `try/catch` 捕获，并行场景仍需 `Promise.all`。\n- `async` 函数中的并发陷阱：串行 `await` vs 并行 `Promise.all`，性能差异。\n\n## ES6+ 核心特性\n- 解构赋值（数组/对象/默认值）、展开/剩余运算符。\n- 箭头函数：没有 `this`/`arguments`/`prototype`，不适合作为构造函数。\n- `Symbol`：唯一标识符，`Symbol.iterator` 与 `for...of` 协议。\n- `Map`/`Set`/`WeakMap`/`WeakSet`：与 Object/Array 的适用场景对比。\n- `Proxy`/`Reflect`：元编程基础，Vue 3 响应式原理的核心。\n\n## DOM 与 BOM\n- DOM 操作成本：重排（Layout）与重绘（Paint），批量更新策略（`DocumentFragment`/虚拟 DOM）。\n- 事件模型：捕获→目标→冒泡，`addEventListener` 第三个参数，事件委托。\n- `requestAnimationFrame` vs `setTimeout`：与屏幕刷新率同步，避免丢帧。\n\n## 模块化与工程化\n- CommonJS（`require`/`module.exports`，同步加载）vs ES Modules（`import`/`export`，静态分析）。\n- Tree-shaking 原理：ES Modules 静态结构使编译期可判定副作用。\n- `package.json` 依赖管理：`dependencies` vs `devDependencies`，语义化版本（semver）。\n- TypeScript 类型系统：接口/泛型/联合类型/类型守卫，与运行时无关。\n\n## 面试追问模板\n- 闭包在实际项目中用在哪里？遇到过内存泄漏吗？\n- 宏任务和微任务的执行顺序，你能举个复杂场景说明吗？\n- Promise 链中某个环节没 return，会发生什么？\n- CommonJS 和 ES Modules 能混用吗？打包工具怎么处理？\n\n<!-- File: app/src/main/resources/skills/_shared/references/mq.md (Tokens: ~989 | Category: anthropic-skill) -->\n# 消息队列面试重点（模型 + 可靠性 + 主流 MQ 对比）\n\n## 消息模型\n- 点对点（Queue）：一条消息只能被一个消费者消费，消费后删除。\n- 发布订阅（Topic）：一条消息可被多个订阅者消费，消费独立。\n- 消费组（Consumer Group）：同一组内竞争消费、不同组间广播消费。\n- 消息顺序性：全局有序（单 Partition）vs 分区有序（同一 key 路由到同一 Partition）。\n\n## 投递语义\n- 至多一次（At Most Once）：可能丢消息，性能最高，适用允许丢失的场景（监控指标）。\n- 至少一次（At Least Once）：可能重复，需要消费端幂等，是大多数 MQ 的默认语义。\n- 恰好一次（Exactly Once）：Kafka 事务 + 幂等 Producer，RocketMQ 事务消息。\n- 幂等消费：唯一键去重（Redis/数据库唯一约束）、业务状态机判断。\n\n## 可靠性保障\n- 生产端确认：Kafka `acks=all`、RabbitMQ Publisher Confirm、RocketMQ 同步刷盘。\n- 消费端确认：手动 ACK（避免自动确认后处理失败丢消息）。\n- 消息持久化：磁盘持久化（Kafka 日志段、RocketMQ CommitLog）、副本机制。\n- 死信队列（DLQ）：消费重试达到上限后转入死信，人工介入处理。\n\n## 消费积压处理\n- 积压原因：消费者宕机、处理变慢（下游依赖超时）、突发流量。\n- 应急处理：紧急扩容消费者、临时消费者绕过慢逻辑先落库、消息降级。\n- 长期预防：消费监控告警（Lag 阈值）、容量预估、消费幂等保障安全扩容。\n- 削峰填谷：MQ 作为缓冲层，上游快速写入、下游匀速消费，保护下游系统。\n\n## 主流 MQ 对比\n- Kafka：高吞吐、顺序磁盘写、零拷贝、适合日志/事件流、Pull 模式。\n- RocketMQ：事务消息、延迟消息、消息过滤（Tag/SQL92）、适合电商金融、Push/Pull。\n- RabbitMQ：AMQP 协议、路由灵活（Exchange 类型丰富）、适合任务分发、Push 模式。\n- 选型维度：吞吐量、延迟、消息可靠性、顺序性、运维复杂度、社区生态。\n\n## 消息中间件架构\n- Kafka：Broker + Topic + Partition + Replica，Leader-Follower ISR 机制。\n- RocketMQ：NameServer + Broker + CommitLog + ConsumeQueue，高性能顺序写。\n- 分区/队列设计：分区数影响并行度、分区迁移与再平衡（Rebalance）、消费者组变更。\n\n## 面试追问模板\n- 消息积压了 100 万条，怎么处理？多久能恢复？\n- 如何保证消息不丢、不重、有序？你的项目怎么做的？\n- Kafka 和 RocketMQ 在你项目中怎么选的？用过什么特性？\n- 消费者 Rebalance 期间消息怎么处理？会造成重复消费吗？\n\n<!-- File: app/src/main/resources/skills/_shared/references/mysql.md (Tokens: ~663 | Category: anthropic-skill) -->\n# MySQL 面试重点\n\n## 索引\n- B+ 树为什么适合磁盘索引（有序、范围查询、叶子链表）。\n- 覆盖索引与回表成本，联合索引最左前缀原则与索引下推。\n- 索引失效场景：函数转换、隐式类型转换、OR、LIKE 前缀通配、非最左列。\n- EXPLAIN 执行计划：type/key/Extra 字段含义，Extra 中 Using filesort/Using temporary。\n\n## 事务与 MVCC\n- ACID 含义，事务隔离级别（RU/RC/RR/SERIALIZABLE）与各自解决的问题。\n- MySQL 默认 RR，InnoDB 通过 MVCC + Next-Key Lock 解决幻读。\n- MVCC 原理：隐藏列（trx_id/roll_pointer）、Undo Log 版本链、ReadView。\n- 当前读 vs 快照读，RR 下当前读仍加间隙锁。\n\n## 锁机制\n- 表级锁 vs 行级锁，InnoDB 行锁（Record/Gap/Next-Key）。\n- 意向锁的作用（快速判断表级冲突），IS/IX 与 S/X 的兼容矩阵。\n- 死锁检测与避免：按固定顺序加锁、缩短事务、降低隔离级别。\n\n## 存储引擎与日志\n- InnoDB vs MyISAM：事务、行锁、外键、崩溃恢复。\n- Redo Log（WAL、crash-safe）vs Undo Log（MVCC、回滚）vs Binlog（主从复制、归档）。\n- 两阶段提交保证 Redo Log 与 Binlog 一致性。\n\n## 性能优化\n- 慢 SQL 定位：slow_query_log、pt-query-digest。\n- 分库分表策略：垂直拆分 vs 水平拆分，ShardingSphere 中间件。\n- 深度分页优化：游标分页、延迟关联、子查询先查主键。\n- 数据冷热分离，读写分离架构。\n\n## 面试追问模板\n- 这条 SQL 走了什么索引？能否优化？\n- 高并发写入时，锁冲突怎么解决？\n- 主从延迟怎么处理？数据一致性如何保证？\n\n<!-- File: app/src/main/resources/skills/_shared/references/network-os.md (Tokens: ~400 | Category: anthropic-skill) -->\n# 网络与操作系统（后端面试核心）\n\n## TCP / HTTP 高频点\n- TCP 三次握手与四次挥手，TIME_WAIT 的意义与优化边界。\n- 粘包/拆包原因与解决（长度字段、分隔符、固定包长）。\n- HTTP1.1/2 差异：连接复用、队头阻塞、头部压缩。\n- HTTPS 握手流程：证书校验、密钥协商、会话复用。\n\n## 并发与线程模型\n- 进程/线程区别，用户态与内核态切换成本。\n- 线程池参数设计：核心线程、队列、拒绝策略、监控指标。\n- 锁优化：悲观锁/乐观锁、CAS、自旋、锁升级。\n\n## 内存与 I/O\n- JVM 内存区域、GC 停顿对接口延迟的影响。\n- 零拷贝、mmap、sendfile 的适用场景。\n- Reactor 模型与同步阻塞模型差异。\n\n## 面试追问模板\n- 为什么不是这个方案？底层代价是什么？\n- 如果连接数/流量翻倍，瓶颈会先出现在哪里？\n- 出现网络抖动或线程池打满时，如何降级与恢复？\n\n<!-- File: app/src/main/resources/skills/_shared/references/python-basic.md (Tokens: ~1083 | Category: anthropic-skill) -->\n# Python 面试重点（语言核心 + 并发 + 工程实践）\n\n## 数据模型与语法特性\n- 一切皆对象：`id()`/`type()`/`value`，可变对象（list/dict/set）vs 不可变对象（int/str/tuple）。\n- 魔法方法：`__init__` vs `__new__`、`__str__` vs `__repr__`、`__eq__` vs `__hash__`、`__enter__`/`__exit__`（上下文管理器）。\n- 多重继承与 MRO：C3 线性化算法、`super()` 沿 MRO 链调用。\n- 描述符协议：`__get__`/`__set__`/`__delete__`，property/classmethod/staticmethod 的底层实现。\n\n## 迭代器、生成器与装饰器\n- 迭代器协议：`__iter__` + `__next__`，`StopIteration` 终止，`for` 循环底层机制。\n- 生成器：`yield` 暂停与恢复、惰性求值、内存优势（处理大数据集/无限序列）。\n- 生成器表达式 vs 列表推导式：内存 vs 速度的取舍。\n- 装饰器：闭包 + `@` 语法糖、带参数装饰器（三层嵌套）、`functools.wraps` 保留元信息。\n- 类装饰器 vs 函数装饰器，`__call__` 实现。\n\n## GIL 与并发模型\n- GIL（全局解释器锁）：CPython 的内存安全机制，CPU 密集型多线程无法并行。\n- 多线程（`threading`）：适合 I/O 密集型（网络请求/文件读写），GIL 在 I/O 等待时释放。\n- 多进程（`multiprocessing`）：绕过 GIL，进程间通信（Queue/Pipe/共享内存），进程池。\n- 异步（`asyncio`）：事件循环 + 协程（`async`/`await`），适合高并发 I/O，单线程无锁。\n- `concurrent.futures`：`ThreadPoolExecutor` vs `ProcessPoolExecutor`，统一的 Future 接口。\n\n## 内存管理与垃圾回收\n- 引用计数：主要回收机制，实时性好但无法处理循环引用。\n- 分代 GC：0/1/2 三代，新对象从 0 代开始，存活时间越长晋升概率越低。\n- 循环引用检测：`gc` 模块的标记-清除算法，`gc.collect()` 手动触发。\n- 内存优化：`__slots__` 禁止动态属性字典、`sys.getsizeof`、内存分析工具（`tracemalloc`/`memory_profiler`）。\n\n## 类型系统与工程实践\n- Type Hints：`typing` 模块（`Optional`/`Union`/`Generic`/`Protocol`），mypy 静态检查。\n- dataclass vs attrs vs Pydantic：数据类定义、校验、序列化的选型。\n- 包管理：`pip` + `requirements.txt` vs `poetry`/`uv`（锁文件、依赖解析）。\n- 虚拟环境：`venv`/`conda`，隔离项目依赖避免版本冲突。\n- 代码质量：`ruff`（lint + format）、`pytest`（测试框架）、`pre-commit`（Git 钩子）。\n\n## 面试追问模板\n- Python 的 GIL 在你的项目中造成过问题吗？怎么解决的？\n- 装饰器写过什么功能？带参数的装饰器怎么实现的？\n- 内存泄漏怎么排查？用过哪些工具？\n- 大量数据处理时，你会用生成器还是列表？权衡点是什么？\n\n<!-- File: app/src/main/resources/skills/_shared/references/react-vue.md (Tokens: ~1178 | Category: anthropic-skill) -->\n# React/Vue 面试重点（框架核心 + 工程化）\n\n## React 核心机制\n- Fiber 架构：链表结构替代递归、可中断渲染、时间切片（Time Slicing）与优先级调度。\n- Virtual DOM：Diff 算法（同层比较、key 的作用）、Reconciliation 过程。\n- Hooks 规则：调用顺序一致（不能在条件/循环中调用）、闭包陷阱（stale closure）与解决方案。\n- 常用 Hooks：`useState`/`useEffect`（依赖数组）/`useCallback`/`useMemo`/`useRef`/`useContext`。\n- `useEffect` vs `useLayoutEffect`：异步 vs 同步、绘制前 vs 绘制后。\n- React 18 并发特性：`useTransition`（非紧急更新降级）、`useDeferredValue`（延迟重渲染）、Suspense 数据获取。\n\n## Vue 核心机制\n- 响应式原理：Vue 2（`Object.defineProperty` 拦截 getter/setter）vs Vue 3（`Proxy` 代理全对象）。\n- Composition API：`ref`/`reactive`/`computed`/`watch`/`watchEffect`，逻辑组合 vs Options API 逻辑分散。\n- 模板编译：模板→AST→渲染函数→Virtual DOM，静态提升与补丁标记（Patch Flag）。\n- 组件更新粒度：Vue 3 基于依赖追踪的精确更新 vs React 整体重渲染（需 memo/shouldComponentUpdate）。\n- Vue 3 编译优化：Block Tree、静态提升（hoistStatic）、缓存事件处理器。\n\n## 状态管理\n- React：Context API（轻量）、Redux（单向数据流/reducer/middleware）、Zustand（极简 Hook 式）、Jotai/Recoil（原子化）。\n- Vue：Pinia（Vue 3 官方推荐，TS 友好、模块化）、Vuex（Vue 2 时代，mutation/action 分离）。\n- 状态分层：组件本地状态 vs 全局共享状态 vs 服务端状态（React Query/TanStack Query）。\n\n## 组件设计\n- 组件通信：props/emit、provide/inject（跨层级）、事件总线、状态管理。\n- 组件抽象：高阶组件（HOC）vs Render Props vs Hooks（React）、插槽（Slots）vs 作用域插槽（Vue）。\n- 受控 vs 非受控组件：表单管理策略、`ref` 获取 DOM/组件实例。\n- 性能优化：`React.memo`/`useMemo`/`useCallback`、Vue `v-once`/`v-memo`、虚拟列表（react-window/vue-virtual-scroller）。\n\n## 路由与 SSR\n- React Router：声明式路由、嵌套路由、路由守卫、懒加载（`React.lazy` + `Suspense`）。\n- Vue Router：动态路由匹配、导航守卫（beforeEach/afterEach）、路由懒加载。\n- SSR vs CSR vs SSG：SEO、首屏速度、服务器成本权衡。\n- Next.js：SSR/SSG/ISR/App Router、Nuxt.js：服务端渲染与混合渲染。\n- Hydration：SSR HTML + 客户端 JS 绑定事件，注水不匹配（hydration mismatch）排查。\n\n## 工程化\n- 构建工具：Vite（ESM 开发服务器 + Rollup 构建）vs Webpack（loader/plugin 生态）。\n- 代码规范：ESLint + Prettier、Husky + lint-staged（提交前检查）。\n- 测试：Jest/Vitest（单元测试）、React Testing Library/Vue Test Utils（组件测试）、Playwright/Cypress（E2E）。\n- 微前端：Module Federation、qiankun、single-spa，应用隔离与通信。\n\n## 面试追问模板\n- React 的 Fiber 架构解决了什么问题？调度是怎么实现的？\n- Vue 3 的 Proxy 响应式和 Vue 2 的 defineProperty 有什么本质区别？\n- 大列表渲染卡顿怎么优化？虚拟列表的原理是什么？\n- 你的项目状态管理怎么选型的？遇到过什么问题？\n\n<!-- File: app/src/main/resources/skills/_shared/references/redis.md (Tokens: ~686 | Category: anthropic-skill) -->\n# Redis 面试重点\n\n## 数据类型与场景\n- 五种基础类型：String/Hash/List/Set/ZSet，各类型底层编码与适用场景。\n- 特殊类型：Bitmap（活跃统计）、HyperLogLog（UV 去重）、Stream（消息队列）。\n- ZSet 底层为什么用跳表而不是红黑树/B+树（范围查询、实现简单、内存灵活）。\n\n## 持久化与线程模型\n- RDB（fork + COW）vs AOF（写后日志、fsync 策略），混合持久化。\n- Redis 6.0 前单线程模型（避免锁竞争、IO 多路复用），6.0 后多线程 IO（命令执行仍单线程）。\n\n## 生产问题\n- 缓存穿透（布隆过滤器/空值缓存）、缓存击穿（互斥锁/永不过期）、缓存雪崩（随机过期/多级缓存）。\n- 缓存与数据库一致性：延迟双删、Canal 监听 Binlog、最终一致性方案。\n\n## 分布式锁\n- `SET key value NX EX` 基本实现，误删问题与 Lua 原子释放。\n- Redisson 可重入锁原理（Hash 结构 + Lua 脚本），看门狗续期机制。\n- 集群下可靠性：RedLock 争议与替代方案（fencing token）。\n\n## 性能优化\n- Pipeline 批量减少 RTT，Lua 脚本保证原子性。\n- BigKey 检测与拆分（redis-rdb-tools、UNLINK 异步删除）。\n- HotKey 发现与本地缓存 + 热点分散。\n- 内存淘汰策略：allkeys-lru vs volatile-lru，内存碎片清理。\n\n## 集群\n- 主从复制（全量 + 增量）、哨兵模式（故障转移、主观/客观下线）。\n- Cluster 模式：16384 槽位、Gossip 协议、重定向（MOVED/ASK）。\n\n## 面试追问模板\n- 如果 Redis 宕机，业务怎么降级？\n- 百万级 QPS 场景下，缓存架构怎么设计？\n- 大 Key 线上清理导致阻塞怎么办？\n\n<!-- File: app/src/main/resources/skills/_shared/references/spring.md (Tokens: ~659 | Category: anthropic-skill) -->\n# Spring 面试重点\n\n## IoC 与 Bean\n- IoC 解决什么问题：解耦对象创建与依赖管理。\n- `@Component` vs `@Bean`：声明方式、代理对象、第三方库集成。\n- `@Autowired` vs `@Resource`：按类型 vs 按名称，优先级规则。\n- 构造器注入 vs Setter 注入 vs 字段注入：不可变性、循环依赖、测试友好度。\n- Bean 作用域（singleton/prototype/request/session），线程安全分析。\n- Bean 生命周期：实例化→属性注入→Aware→初始化→销毁，各阶段扩展点。\n\n## AOP\n- 核心概念：切面/切点/通知/连接点。\n- Spring AOP vs AspectJ：动态代理 vs 编译期织入，性能与功能差异。\n- 通知类型：@Before/@After/@AfterReturning/@AfterThrowing/@Around。\n- 同类内部调用 AOP 失效原因与解决方案（AopContext/exposeProxy）。\n\n## Spring MVC\n- DispatcherServlet 工作流程：HandlerMapping→HandlerAdapter→ViewResolver。\n- 统一异常处理：@ControllerAdvice + @ExceptionHandler。\n- 拦截器 vs 过滤器：执行时机与适用场景。\n\n## 事务\n- 声明式事务：@Transactional 属性（propagation/isolation/rollbackFor）。\n- 七种传播行为：REQUIRED/REQUIRES_NEW/NESTED 等使用场景。\n- 事务失效场景：同类内部调用、非 public 方法、异常被吞、异步调用。\n\n## 循环依赖\n- 三级缓存解决 setter 注入循环依赖：singletonObjects/earlySingletonObjects/singletonFactories。\n- 构造器注入循环依赖无法自动解决，需 @Lazy。\n- SpringBoot 2.6+ 默认禁止循环依赖。\n\n## Spring Boot\n- 自动配置原理：@SpringBootApplication→@EnableAutoConfiguration→spring.factories/Imports。\n- 条件装配：@ConditionalOnClass/@ConditionalOnMissingBean 等。\n- 配置文件加载优先级：properties > yaml > 环境变量 > 命令行参数。\n\n## 面试追问模板\n- @Transactional 标在 private 方法上会生效吗？为什么？\n- 如何自定义一个 Spring Boot Starter？\n- Spring AOP 在你的项目中用来做了什么？遇到过什么坑？\n\n<!-- File: app/src/main/resources/skills/_shared/references/system-design-scenarios.md (Tokens: ~1497 | Category: anthropic-skill) -->\n# 系统设计与场景题（后端通用核心版）\n\n## 1. 面试答题通用框架（先说这个）\n1. 先澄清约束：QPS、峰值倍数、SLA、数据量、延迟目标、一致性级别、成本上限。\n2. 再给核心链路：请求路径、读写路径、关键状态、失败路径。\n3. 最后补工程细节：容量估算、监控告警、降级兜底、回滚与补偿。\n\n## 2. 高频场景题的标准思路\n\n### 秒杀系统\n- 目标：抗瞬时洪峰、避免超卖、保证最终一致。\n- 关键手段：前置限流 + 验证码/预约削峰 + 缓存库存 + 异步下单（MQ）。\n- 一致性：预扣库存 + 订单超时回补；幂等键防重复下单。\n- 风险点：热点 Key、缓存击穿、消息堆积、库存回补失败。\n\n### 短链系统\n- 目标：短码唯一、重定向高性能、可统计。\n- 核心：短码生成（号段/哈希+冲突处理）+ 映射存储 + 缓存热点短链。\n- 扩展：防刷、防爆破、过期回收、点击明细异步落库。\n\n### Feed 流（推拉模型）\n- 目标：低延迟、可扩展、支持热点用户。\n- 模式：推模式（读快写重）/拉模式（写快读重）/推拉结合（明星与普通用户分治）。\n- 关键：时间线有序、分页游标、防重复、防回刷穿透。\n\n### 站内消息系统\n- 消息类型拆分：系统通知、事件提醒、私信。\n- 核心能力：未读计数、聚合展示、已读状态、离线补偿、幂等去重。\n- 存储策略：会话维度和消息明细分离，冷热分层。\n\n### 延时任务\n- 可选方案：Redis 延迟队列 / MQ 延时消息 / 时间轮调度。\n- 关键问题：任务可靠投递、重复执行防护、取消与重试语义。\n- 工程点：失败重试上限、死信处理、任务可观测性（积压、延迟、失败率）。\n\n### 登录风控（密码输错限制）\n- 核心：用户维度失败计数 + TTL 锁定窗口。\n- 要点：分布式一致计数、防账号枚举、风控阈值分级（验证码->临时锁定->人工校验）。\n- 审计：保留关键操作日志与告警。\n\n### 扫码登录 / 第三方登录\n- 扫码登录：状态机（待扫码->已扫码待确认->确认登录/取消/过期）。\n- OAuth2：授权码模式优先；短期 Access Token + 可撤销 Refresh Token。\n- 安全点：`state` 防 CSRF、回调域名白名单、一次性 code、过期控制。\n\n### 抢单 / 抢资源并发控制\n- 核心目标：同一资源只被一个请求成功占有。\n- 实现：数据库唯一约束 + 乐观锁版本号 或 Redis 原子指令/CAS。\n- 必备：幂等键、超时释放、补偿回滚。\n\n### UV/PV 统计\n- UV 常见实现：HyperLogLog（省内存，近似去重）。\n- PV：计数器即可；复杂场景按站点/页面/时间分桶。\n- 大盘链路：写入削峰（MQ）+ 离线/准实时聚合。\n\n### 去重推荐（大规模）\n- 核心：布隆过滤器 + 分层存储（内存 + 磁盘）+ 批量异步刷盘。\n- 重点：误判率控制、窗口淘汰策略、冷启动兼容。\n\n### RPC 框架设计\n- 关键组件：注册发现、序列化协议、网络传输、负载均衡、超时重试、熔断隔离。\n- 高可用：请求幂等、降级策略、调用链追踪。\n\n### Session 跨节点共享\n- 推荐：集中式会话存储（Redis）。\n- 不推荐：应用节点间 session 复制（扩展性差，维护成本高）。\n\n## 3. 面试官常追问清单\n1. 为什么这么分层？瓶颈先出在哪里？\n2. 失败后怎么恢复？谁触发补偿？如何防重？\n3. 峰值翻 3 倍时，先扩哪个组件？依据是什么？\n4. 你怎么证明方案有效？给出核心指标与阈值。\n5. 一致性和可用性冲突时，你的取舍原则是什么？\n\n<!-- File: app/src/main/resources/skills/_shared/references/test-development.md (Tokens: ~1947 | Category: anthropic-skill) -->\n# 测试开发面试重点（测试基础 + 用例设计 + 自动化 + 性能安全）\n\n## 测试基础\n- 软件测试定义与目的：发现缺陷、验证需求、提供质量反馈，不只是\"找 Bug\"。\n- 测试流程：需求分析→测试计划→测试设计→测试执行→缺陷跟踪→测试报告→回归测试。\n- 测试左移（Shift-Left）：需求/设计阶段就介入质量活动，早发现早修复，缺陷成本随阶段指数增长。\n- 测试覆盖率：行覆盖/分支覆盖/路径覆盖，高覆盖率 ≠ 高质量测试，关注有意义覆盖率而非数字。\n- 测试金字塔：单元测试（>90% 自动化）→集成测试（60-80%）→系统/UI 测试（20-40%），投资回报递减。\n- 核心竞争力：业务理解 + 系统性用例设计 + 工程化自动化能力。\n\n## 测试用例设计\n- 等价类划分：将输入划分为有效/无效等价类，每类取代表性数据，减少冗余。\n- 边界值分析：等价类边界的值最易出错，如范围 [1,100] 测试 0/1/100/101。\n- 判定表法：多条件组合场景（如会员×节假日×提前天数→价格），穷举条件与结果映射。\n- 场景法：模拟用户操作流程（主流程+异常分支），通过流程图覆盖完整业务路径。\n- 错误推测法：基于经验推测易错点（如文件上传：空文件/超大文件/病毒文件/格式不符）。\n- 状态迁移法：测试有状态变化的对象（如订单状态、电梯状态），验证状态转换正确性。\n- 好的测试用例标准：覆盖全面、分组精准（等价类无冗余）、边界清晰。\n- 场景题回答框架：功能→兼容性→性能→网络→安全→UI/UX，逐维度展开。\n\n## 测试类型\n- 黑盒测试 vs 白盒测试：关注外部行为 vs 关注内部代码逻辑，互补使用。\n- 单元测试：最小可测试单元（函数/类），Mock 外部依赖，开发编写，CI 自动执行。\n- 集成测试：多模块/服务交互验证，关注接口契约、数据传递、依赖协同。\n- 系统测试：完整系统验证，功能/性能/安全/兼容性全面覆盖。\n- 回归测试：修改后确认旧功能未被破坏，高度依赖自动化用例。\n- 验收测试（UAT）：业务方确认是否满足需求，贴近真实场景。\n- 端到端测试（E2E）：完整业务链路验证，从用户入口到最终输出，数量少但价值高。\n- 正向测试 vs 反向测试：合法输入验证正常功能 vs 非法输入验证异常处理能力。\n\n## 自动化测试\n- ROI 公式：(节省的手工测试时间 × 执行频率) - (脚本开发时间 + 维护成本)。\n- 适用场景：回归测试、步骤确定性高、执行频率高；不适用：一次性功能、UI 频繁变动、探索性测试。\n- Web 自动化工具：Selenium（多语言/多浏览器、成熟但慢）、Cypress（开发者友好、JS-only）、Playwright（现代化、多语言、快）。\n- API 测试流程：读 API 文档→设计用例（正常/异常/边界）→准备数据与认证→发请求→校验响应与数据库。\n- API 测试工具：Postman/Reqable/Insomnia，结合 Newman/CI 实现自动化回归。\n- 移动端自动化：Appium（跨平台）、Espresso（Android 原生）、XCTest（iOS 原生）。\n- CI/CD 集成：Jenkins/GitLab CI/GitHub Actions 中自动触发，测试报告与失败告警。\n\n## 性能测试\n- 压测类型：负载测试（预期负载下验证）、压力测试（超负载找极限）、稳定性测试（长时间运行查泄漏）。\n- 压测流程：确定目标（QPS/RT/TPS）→准备环境（≈生产 50-80%）→选工具→编写脚本→执行→监控分析→调优→复测。\n- 压测工具：JMeter（功能全面）、k6（JS 脚本、现代化）、Gatling（Scala、高性能）、Locust（Python）。\n- 关键指标：TPS/QPS、响应时间（P50/P95/P99）、错误率、CPU/内存/磁盘 IO/网络带宽。\n- 瓶颈定位：数据库慢查询、连接池打满、线程池饱和、网络带宽、GC 停顿。\n\n## 安全测试\n- OWASP Top 10：XSS/SQL 注入/CSRF/身份认证失效/敏感信息泄露/访问控制失效等。\n- XSS 测试：输入 `<script>alert(1)</script>`、`<img src=x onerror=alert(1)>`，验证是否转义/过滤。\n- SQL 注入测试：`' OR '1'='1 --`、`' UNION SELECT --`、时间盲注 `AND SLEEP(5)`，验证参数化查询。\n- CSRF 测试：检查 CSRF Token、SameSite Cookie、Referer 校验。\n- 越权测试：水平越权（访问同角色他人数据）、垂直越权（普通用户访问管理接口）。\n\n## Bug 处理与协作\n- 不可复现 Bug：多次尝试不同环境/数据→收集详细信息（步骤/日志/截图/录屏）→与开发协作分析。\n- 缺陷报告要素：标题、前置条件、复现步骤、预期结果、实际结果、严重程度、优先级。\n- Bug 生命周期：新建→确认→分配→修复→验证→关闭（或重新打开）。\n- 印象深刻的 Bug 回答模板：场景描述 + 根因分析 + 修复过程 + 后续预防。\n\n## 面试追问模板\n- 登录/支付/电商直播间场景，你怎么设计测试用例？\n- 你的自动化测试覆盖率是多少？ROI 怎么评估？\n- 线上出了一个 Bug，但测试环境无法复现，你怎么排查？\n- 你在 CI/CD 中集成了哪些质量门禁？怎么防止质量回退？\n\n<!-- File: app/src/main/resources/skills/ai-agent-dev/ai-agent-dev.md (Tokens: ~2223 | Category: anthropic-skill) -->\n# AI Agent 开发面试参考\n\n## 一、Agent 基础\n\n### Agent 定义与核心架构\n- Agent = LLM + Planning + Memory + Tools\n- Agent Loop：感知(Perceive) -> 推理(Reason) -> 行动(Act) -> 观察(Observe) 循环\n- 终止条件：任务完成、达到最大步数、用户中断、错误熔断\n\n### Agent vs 传统编程 vs 工作流\n- 决策者差异：Agent 由 AI 决策下一步，工作流由预定义路径驱动\n- 适用场景判断：确定性任务用工作流，开放性任务用 Agent\n\n### Agent 范式\n- ReAct：Thought-Action-Observation 循环，边推理边执行\n- Plan-and-Execute：先规划全局步骤，再逐步执行\n- Reflection：自我反思与修正（Reflexion / Self-Refine / CRITIC）\n\n### 多 Agent 系统\n- Orchestrator-Subagent：主从模式，编排器分配任务\n- Peer-to-Peer：对等模式，Agent 间平等协作\n- A2A（Agent-to-Agent）通信协议\n\n### 安全\n- Prompt Injection 攻击类型与防御（执行层沙箱、认知层隔离、决策层人机协同）\n- Agent 权限边界设计（最小权限原则）\n- 敏感操作审批机制\n\n---\n\n## 二、LLM 调用\n\n### Token 与上下文窗口\n- Token 是计费和性能的基本单位（非字符）\n- 上下文窗口 = System Prompt + User Prompt + 历史 + RAG + 工具定义 + 输出\n- Token 预算：window >= input_tokens + max_output_tokens\n- Prompt Caching：静态内容前置、动态内容后置\n\n### 采样参数\n- Temperature：控制随机性（低=确定性，高=创造性）\n- Top-p（核采样）和 Top-k：缩小候选词池\n- Presence/Frequency Penalty：抑制重复\n- 推理模型（o1/o3）的参数限制\n\n### Function Calling\n- JSON Schema 定义工具接口\n- 工具粒度设计：原子操作 vs 组合操作\n- 并行工具调用（Parallel Tool Calling）\n- 错误处理：工具调用失败时的重试与降级策略\n\n### 结构化输出与流式输出\n- JSON Mode vs Structured Output（Schema 约束）\n- SSE（Server-Sent Events）机制与 TTFT 优化\n- 流式场景下的工具调用处理\n\n### 成本优化\n- 输入/输出 Token 定价差异（2-5 倍）\n- 路由策略：简单问题用小模型、复杂问题用大模型\n- 缓存策略：语义缓存、精确匹配缓存\n\n---\n\n## 三、MCP 协议\n\n### MCP 定位\n- MCP（Model Context Protocol）= AI 的 USB-C，统一工具接入标准\n- MCP vs Function Calling vs Agent：MCP 是协议标准，Function Calling 是 LLM 能力，Agent 是系统概念\n- 四层关系：Function Calling（基础） -> Prompt（意图） -> MCP（连接） -> Skills（编排）\n\n### MCP 四大核心能力\n- Resources：只读数据源 | Tools：可执行操作 | Prompts：模板化提示词 | Sampling：LLM 推理委托\n\n### 架构与传输\n- 四层：Host（宿主） -> Client（协议客户端） -> Server（工具服务） -> Data Source\n- JSON-RPC 2.0 通信协议（轻量、传输无关、易调试）\n- stdio：本地 IPC；Streamable HTTP：远程/生产（已废弃 HTTP+SSE）\n\n### 生产实践\n- 工具幂等性设计、退避策略与 P99 延迟目标\n- 上下文窗口管理（大结果截断、分页）\n- 安全考量（输入校验、权限控制、审计日志）\n\n---\n\n## 四、RAG 检索增强\n\n### 基本原理\n- RAG = 信息检索 + LLM 生成\n- 离线索引（加载、清洗、分块、Embedding、存储）+ 在线检索（查询向量化、相似度搜索、上下文构建、生成）\n- 核心优势：知识时效性、减少幻觉、数据安全、领域适配\n\n### 分块与 Embedding\n- 固定长度 vs 语义分块 vs 递归分块\n- 分块大小与语义完整性的权衡\n- 通用 vs 领域微调 Embedding 模型选择\n\n### 向量检索\n- ANN：用 5% 召回率损失换 100 倍速度\n- HNSW：<1000 万向量、高召回、高内存 | IVFFLAT：1000 万-1 亿、内存友好\n- 距离度量：余弦相似度、内积、欧几里得距离\n- 混合检索：向量 + BM25 + RRF 融合（生产最佳实践）\n\n### 局限与治理\n- GIGO：检索质量决定生成质量\n- 上下文窗口噪声、TTFT 增加、检索召回率评估\n\n---\n\n## 五、上下文工程\n\n### 概念\n- Agent = Model + Harness（模型之外的一切都是 Harness）\n- 模型决定上限，Harness 决定下限\n\n### 六层 Harness 架构\n1. L1 信息边界：System Prompt、约束条件、角色定义\n2. L2 工具系统：工具注册、Schema 定义、权限控制\n3. L3 执行编排：Agent Loop、条件分支、并行执行\n4. L4 记忆与状态：短期记忆、长期记忆、状态持久化\n5. L5 评估与可观测：质量评估、链路追踪、指标监控\n6. L6 约束与恢复：错误处理、重试策略、降级方案\n\n### Token 预算与设计模式\n- 40% 上下文利用率阈值（超过后质量急剧下降）\n- 上下文压缩：摘要、裁剪、遗忘\n- 渐进式披露：L1 元数据常驻 + L2 正文按需 + L3 资源隔离\n- Lost in the Middle 问题与应对\n\n### 实践案例\n- OpenAI：机械约束优于文档约束、熵管理\n- Anthropic：GAN 式三 Agent 架构、上下文重置策略\n- Stripe：Minions 系统\n\n---\n\n## 面试高频追问\n\n### Agent 基础\n- Agent Loop 中如何防止无限循环？\n- ReAct 和 Plan-and-Execute 各自的优缺点和适用场景？\n- 多 Agent 系统中如何保证一致性？\n\n### LLM 调用\n- Token 超出上下文窗口时怎么处理？\n- Function Calling 和直接在 Prompt 里写工具有什么区别？\n- 如何降低 LLM 调用的 P99 延迟？\n\n### MCP 协议\n- MCP 和直接用 Function Calling 有什么区别？\n- stdio 和 Streamable HTTP 分别适合什么场景？\n- 如何设计一个生产级的 MCP Server？\n\n### RAG\n- 分块策略如何选择？过大或过小分别有什么问题？\n- 向量检索和关键词检索各自的优缺点？为什么需要混合检索？\n- RAG 系统线上出现幻觉，排查思路是什么？\n\n### 上下文工程\n- Agent 上下文超出窗口时如何处理？\n- AGENTS.md / SKILL.md 的设计原则是什么？\n- Harness 各层级中哪一层对 Agent 质量影响最大？为什么？\n\n<!-- File: app/src/main/resources/skills/ai-agent-dev/SKILL.md (Tokens: ~524 | Category: anthropic-skill) -->\n---\nname: ai-agent-dev\ndescription: 用于 AI Agent 开发岗位面试出题；覆盖 Agent 架构、LLM 调用、工具集成、MCP 协议、RAG、上下文工程与多 Agent 协作，强调工程落地与故障处理能力。\n---\n# Overview\n你是一位 AI Agent 开发岗位面试官，关注候选人对 Agent 系统的工程实现能力，而不是只会描述概念。重点考察：Agent Loop 设计、工具集成方式、上下文管理策略、RAG 检索质量治理和多 Agent 协作模式。\n\n# Instructions\n1. 先确认候选人的技术栈（LangChain / Spring AI / 自研框架）和实际项目经验，围绕真实项目追问。\n2. 提问遵循梯度：使用经验 -> 原理机制 -> 边界与故障 -> 优化与权衡。\n3. 每个主问题必须包含至少一个权衡点（如召回率 vs 延迟、上下文长度 vs 信息密度）。\n4. 回答停留在概念层时，必须追问具体实现：协议选型、Token 预算分配、错误重试策略、可观测性指标。\n5. 至少一次要求候选人给出可量化指标（如 TTFT、P99 延迟、检索召回率、Token 利用率）。\n6. 不要只问名词解释，必须有场景化问题（如\"线上 Agent 出现幻觉循环，你怎么排查\"）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- AGENT_BASIS / LLM_CALLING / MCP_PROTOCOL / RAG / CONTEXT_ENGINEERING / MULTI_AGENT / PROJECT -> ai-agent-dev.md\n\n<!-- File: app/src/main/resources/skills/algorithm/SKILL.md (Tokens: ~389 | Category: anthropic-skill) -->\n---\nname: algorithm\ndescription: 用于算法面试出题；重点评估复杂度分析、边界处理和优化能力，区分背题与真实理解。\n---\n# Overview\n你是一位算法面试官，目标是评估候选人的建模能力和复杂度优化能力。\n\n# Instructions\n1. 文字/语音面试不要求写代码；每题先让候选人口述：建模方式、关键数据结构、核心步骤、时间/空间复杂度。\n2. 数据结构必须覆盖多样性：哈希表、栈/队列、堆、树/图、数组/链表应轮换考察，避免只刷单一套路。\n3. 回答正确后继续追问边界条件、退化场景和同类变体，不停在基础答案。\n4. 对暴力解必须追问瓶颈，并要求给出可落地的优化路径（如剪枝、单调结构、预处理、空间换时间）。\n5. 至少一次要求候选人解释正确性证明思路（不变式/归纳/反证任一即可）。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP/GREEDY_BACKTRACK/DESIGN -> algorithm-data-structures.md\n\n<!-- File: app/src/main/resources/skills/ali-backend/SKILL.md (Tokens: ~398 | Category: anthropic-skill) -->\n---\nname: ali-backend\ndescription: 用于阿里后端面试出题；强调业务深度、项目落地和中间件选型能力，关注复杂场景下的取舍与闭环。\n---\n# Overview\n你是阿里巴巴后端面试官。核心风格是业务导向与项目深挖：围绕候选人真实项目持续追问，直到触达认知边界。\n\n# Instructions\n1. 优先从简历项目切入，连续追问\"为什么这样设计\"\"如果流量涨 10 倍怎么改\"。\n2. 每个问题必须落到业务目标、技术取舍、成本与收益，不接受纯理论回答。\n3. 对 Java 生态中间件（MySQL、Redis、MQ）重点追问原理、故障、容量与治理。\n4. 至少一次要求候选人给出完整落地方案：指标、压测、发布、回滚、复盘。\n5. 强调可执行性：方案要能上线、能观测、能恢复。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- PROJECT/SYSTEM_DESIGN_SCENARIO -> system-design-scenarios.md\n- DB_DESIGN/MYSQL -> db-design.md, mysql.md\n- DISTRIBUTED/CACHE/REDIS -> distributed.md, redis.md\n- MQ -> mq.md\n- DESIGN_PATTERN -> design-pattern.md\n\n<!-- File: app/src/main/resources/skills/bytedance-backend/SKILL.md (Tokens: ~468 | Category: anthropic-skill) -->\n---\nname: bytedance-backend\ndescription: 用于字节后端面试出题；以算法与编码能力为第一门槛，同时考察高并发场景下的系统设计能力。\n---\n# Overview\n你是字节跳动后端面试官，风格直接、硬核、高强度。核心判断标准是：算法基本功是否过硬，复杂度优化是否到位。\n\n# Instructions\n1. 每轮优先给 1-2 道算法题，但在文字/语音场景不要求手写代码；要求候选人口述解法步骤、关键数据结构、复杂度与边界处理。\n2. 数据结构覆盖必须均衡：数组/链表、哈希表、栈/队列、堆、树/图至少覆盖两类以上，不可只问单一 DP。\n3. 对答案必须追问：为什么正确、为什么最优、边界条件是否完整；若只给结论，要求补充不变式或反例证明。\n4. 算法题后补一题工程化追问：同思路如何迁移到高并发真实场景（如计数、去重、延迟任务、TopK）。\n5. 提问节奏要快，单题目标明确；每次只追一个关键点，避免超长题干。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- ARRAY_LINKEDLIST/HASH_HEAP_QUEUE/TREE_GRAPH/DP -> algorithm-data-structures.md\n- DISTRIBUTED/SYSTEM_DESIGN_SCENARIO -> distributed.md, system-design-scenarios.md\n- PROJECT -> 结合简历追问真实线上问题\n\n<!-- File: app/src/main/resources/skills/frontend/SKILL.md (Tokens: ~332 | Category: anthropic-skill) -->\n---\nname: frontend\ndescription: 用于前端工程面试出题；覆盖 JavaScript、React/Vue、浏览器原理和性能优化，强调业务实战与工程化能力。\n---\n# Overview\n你是一位前端工程面试官，重点评估候选人在真实业务中的技术取舍与交付质量。\n\n# Instructions\n1. 问题需覆盖渲染机制、状态管理、工程化与性能优化。\n2. 优先结合简历项目，追问复杂页面、性能瓶颈和线上问题处理。\n3. 回答停留在 API 层时，必须追问底层机制与边界场景。\n4. 至少一次要求候选人给出可量化指标（如 FCP/LCP、错误率、包体积）。\n5. 不要只问名词解释，必须有场景化问题。\n\n# Additional Resources\n出题前优先参考这些资料，并按分类落题：\n- JAVASCRIPT -> javascript.md\n- REACT_VUE -> react-vue.md\n- BROWSER -> browser.md\n- CSS/ENGINEERING/PERFORMANCE/PROJECT -> 结合简历与工程实践深挖\n\n<!-- ... +5 more modular skills available via /api/skills/Snailclimb/interview-guide?path={path} -->\n</yakaai_skills>"}