00 使用说明 · 事实校正 · 阅读路线（先看这篇）
本目录是为字节跳动面试准备的 shatangAI 项目深挖材料。 全部内容基于仓库源码逐行核对（
/Users/binhy/Binhy-Projects/shatangAI），带文件名的技术事实可以直接在 IDE 里验证。 一条纪律贯穿全篇：代码里有的照实说，代码里没有的一律不编；效果类数字一律标注"无基线"。
一、文件清单与用途
| 文件 | 对应简历 bullet | 用途 | 优先级 |
|---|---|---|---|
01-项目口述介绍-多版本.md | 全部 | 30 秒 / 2 分钟 / 5 分钟 / 10 分钟四版口述稿 + 数字卡 + vibecoding 坦白话术 + 雷区清单 + 反问清单 | ⭐⭐⭐ 必背 |
02-架构全景与一次生成的完整时序.md | 全部 | 白板架构图、部署拓扑、数据模型、一次生成的四阶段时序、选型理由表 | ⭐⭐⭐ 白板必用 |
03-简历四条主线拆解.md | ①②③④ | 逐条核对简历 → 代码事实 → 你的贡献 → 60 秒回答；末尾附简历修改版 | ⭐⭐⭐ 先读这篇 |
04-任务队列与状态机深挖问答.md | ② | 22 个 Q：队列拆分、jobId 三个坑、状态机与条件更新、幂等三层、恢复的启动/周期差异、自管链路误杀、轮询超时、并发收尾抢占 | ⭐⭐⭐ 你的主场 |
05-多供应商与多段一致性深挖问答.md | ① | 18 个 Q：6 家供应商与唯一通道、Provider 抽象退化、能力表、四层一致性、段三态机与指纹复用、自研 ffmpeg 拼接的坑、14 种生成方式、提示词工程 | ⭐⭐⭐ |
06-积分计费与支付深挖问答.md | ②④ | 22 个 Q：三表模型、两套冻结语义、部分唯一索引、行锁与隔离级别、双余额拆分、对账五类异常、支付四层幂等、关单风险、鉴权与 SECRET_KEY | ⭐⭐⭐ |
07-前端架构与管理后台深挖问答.md | ③ | 24 个 Q：技术栈实测、状态管理分工、请求层、进度条伪随机、上传三条链路、管理后台、类型共享真相、工程质量 | ⭐⭐ |
08-基础设施与部署深挖问答.md | ④ | 部署架构、发布脚本、配置与密钥、存储抽象、数据库与迁移、备份容灾为零、可观测性缺口 | ⭐⭐ |
09-生产事故与踩坑故事集.md | 全部 | 10 个 STAR 故事（假 DDoS、68 小时悬挂、重复扣费 370 分、2.6 秒收 75 积分、OSS 误删事故（4 次）…）+ 小坑清单 | ⭐⭐⭐ 弹药库 |
10-压力面与简历修正话术.md | 全部 | MySQL 怎么补救、十类压力问题、三条保命话术、反问与收尾 | ⭐⭐⭐ 防守必读 |
11-白板手写题与设计题.md | — | 手写题（并发池、退避重试、限流、分布式锁、LRU、抢占收尾、状态守卫 SQL、分页）+ SQL 题 + 系统设计题 | ⭐⭐ 字节常考 |
12-速背卡片.md | — | 考前 30 分钟只看这篇：90 秒主线、12 个数字、十个必答、六个缺陷、雷区表、三个锚点 | ⭐⭐⭐ |
13-代码地图与事实索引.md | — | 按主题的文件索引 + 30 秒复查脚本 + 作者归属 + 文档陷阱清单 | ⭐⭐ 抽查用 |
二、3 天冲刺路线
Day 1 —— 建立主干（约 3 小时）
- 读
03（四条主线拆解）。先搞清楚哪条能讲硬、哪条必须修正——这决定你面试的基调。 - 读
01的事实底盘与归属表；把「2 分钟版」念出声录音，听哪里卡壳。 - 读
01第八节（vibecoding 话术）——这段必答，练到自然。 - 背
12的 12 个数字卡（注意都要能说出"所以呢"）。
Day 2 —— 深挖两块硬骨头（约 4 小时） 5. 精读 04（队列与状态机）：Q3（为什么拆两条队列）、Q4（jobId 三坑）、Q7（条件更新）、Q9（并发收尾）、Q12–Q13（恢复与自管链路）。这五个是主动加分点。 6. 精读 06（钱）：Q3（两套冻结语义）、Q5（部分唯一索引）、Q7（流水表 ON CONFLICT 空转）、Q9（对账五口径）、Q17（鉴权与 SECRET_KEY）。 7. 读 05 的 Q1、Q5、Q15——"唯一通道"和"首尾帧降级"是两条最容易被问穿的事实，必须能主动说。 8. 读 09 的故事 1、2、3（假 DDoS / 68 小时 / 重复扣费），练成能讲 2 分钟。
Day 3 —— 模拟与收口（约 3 小时） 9. 对着白板默画 02 第一节架构图，同步讲 5 分钟。 10. 随机念简历的一条 bullet，即时展开 60 秒（每条都要能展开）。 11. 只读 12，把「六个缺陷」练成"一句缺陷 + 一句影响 + 一句修法"。 12. 睡前读 10 的反问与收尾话术。
三、事实校正表（这是本套材料最重要的部分）
简历上有 7 处与代码不符。面试官问到就是必答，问到之前不要主动全倒（除了第 1 条建议主动更正）。
| # | 简历/文档说法 | 代码事实 | 严重度 | 处理 |
|---|---|---|---|---|
| 1 | 后端 MySQL | PostgreSQL 17（pg 驱动，无 mysql2；大量 PG 专有语法：原生 ENUM、JSONB、TIMESTAMPTZ、部分唯一索引、plpgsql 触发器）。MySQL 只存在于 2026-04-23~05-13 约三周、且只是 flag 门控的账号侧 | 🔴 必答 | 主动更正，话术见 10 第一节 |
| 2 | "引用计数保护" | 无计数式实现；真身是 oss_key_in_use()（跨 12+ 张表的存在性判定）+ DB 触发器 + 唯一约束 + 30 天延迟删除。代码里 refCount 只用于"参考图数量" | 🟠 表述失真 | 改成"引用存在性保护"，见 06 Q21 |
| 3 | "Docker Compose 一键部署" | compose 只有 PG + Redis，无 app service、无 Dockerfile；应用是 pm2 + tsx + nginx + 自研发布脚本 | 🟠 | 改成"基础设施容器化 + pm2/nginx + 发布脚本"，见 08 |
| 4 | "集成 6+ 供应商" | 历史接入 6 家，当前新任务只走腾讯云 VOD 1 家（resolveProvider() 恒等） | 🟠 | 表述改为"历史接入 6 家 / 当前使用 1 家"，见 05 Q1 |
| 5 | "统一 BullMQ 队列调度" | 9 条队列真实；但 video-generate 只有恢复逻辑在用，主流链路是"路由直接调供应商 + 进轮询队列"，另有 3 条链路内存自管 | 🟡 | 说"统一的任务队列与轮询调度"，见 05 Q13 |
| 6 | "TypeScript 全栈统一类型安全" | "统一 TS"成立；但根与 backend strict: false，后端 54 个文件 @ts-nocheck；类型共享靠 9 份 JSON + 手工镜像 + 测试读源码断言，无编译期约束 | 🟡 | 降级表述为"类型强度分层"，见 03 ③ |
| 7 | "微信支付" | 只有 V3 Native 扫码（无 JSAPI/H5/小程序/APP）；另有支付宝预下单。支付退款与上游对账未实现 | 🟡 | 主动补范围，见 06 Q15/Q16 |
另外三处"文档陷阱"（别拿它们当依据）：README.md 写 MySQL、ARCH.md 写"App.tsx 10k 行 / 无自动化测试 / 类型零错误"、CHORE.md 写"51 个文件全量迁移零错误"、docs/architecture/provider-integration-guide.md 写"默认 kuaizi / MYNEW_PREFER 灰度开关"——全部过期。13 最后一节列了完整清单。
四、你的真实贡献边界（背下来，用来划界）
你主导（可以讲硬）
- 任务崩溃恢复与巡检：
taskRecovery.ts（14/33 提交）、creditRecovery.ts（3/9） - 视频任务提交 Worker 与轮询队列：
videoWorker.ts（10/19）、videoPollQueue.ts（你引入 BullMQ 轮询） - 积分冻结内核：
userCreditsStore.ts（11/45），credit_holds表迁移 1/1 全是你写的 - 微信支付客户端：
wxpayClient.ts（2/2）、微信扫码登录：wechatOAuth.ts（1/1） - 限流（用户名维度配额）、身份解析中间件
- OSS 生命周期、分销/邀请码、前端 App.tsx 拆分为 page + hook 架构
同事主导（只讲"我读过、能讲清设计"，主动划界）
- 脚本库一键生成的分段生产 Worker：
productionWorker.ts（你 0/35） - 模型与定价目录：
modelCatalog.ts（你 0/30） - 视频编辑器编排、标准复刻的收尾实现
【备注讲解】主动划界是加分不是减分。面试官最怕"讲得流畅、一问细节就露馅"；你明确说"这块是同事写的，我从恢复侧参与"，他反而更愿意相信你自己负责的那部分。
五、三个记忆锚点（任何问题都能往回收）
- 提交与轮询分离 —— 队列的并发度必须匹配任务的资源占用模型。
- 部分唯一索引防重复扣费 —— 用数据库约束而不是应用层判断来兜住不变式。
- 权威状态在服务端，不在浏览器 —— 一次 68 小时事故换来的结论。
六、保命三条（背到脱口而出）
- 真不会的细节 → 「这一层我没做到源码级。我知道的边界是 X，回去我会先看 Y。」（绝不硬编）
- 效果数字 → 「我没有可信基线，所以不编数字——但我可以说清怎么设计评估、瓶颈在哪。」
- 质疑 AI 生成 → 「是 AI 辅助。我把住的是设计决策和验证责任：轮询超时、部分唯一索引、恢复逻辑的启动/周期差异，这些是从踩坑里长出来的判断。」
七、材料的事实边界（避免误用）
- 技术机制、常量、默认值、文件名均来自源码核对，可以放心引用。
- 没有线上流量数据、没有压测、没有 P99/QPS/用户量——
09和10都把这些列为"不能编的数字"。 - 行号会漂移：本套材料以符号名（函数名/常量名/表名）为主要引用方式，行号仅作辅助。面试前用
13的"30 秒复查脚本"抽查一遍。 - 两处无法从仓库判定的事实（务必上服务器确认）：
LEGACY_HEADER_AUTH的生产取值 —— 决定X-Login-User裸头能否被伪造；SECRET_KEY的生产取值 —— 若仍是硬编码默认值，等于存在完整的 JWT 伪造绕过。
- 本套材料基于某一次代码快照（HEAD
17440c78，2026-09-18）。