封面01 / 45

Wayne 研究室 · 2026 春季档

研发工程化
CEO 速通班

From CEO to Code Reader · 6 Weeks Sprint

8 册 · 45 节 8 实验 · 8 小考 1 终考 · 千图代码库

主讲 · CLAUDE

学员 · 王伟（千图网 CEO）

M1 · 课程定位02 / 45

致 Wayne · 致一位非典型学员

你已经是产品、设计、运营、市场的多面手。
剩下的最后一块——研发——不该是你的盲区。

你已经擅长的

✦ 产品：从 0 到 1 定义用户场景
✦ 设计：审美、版式、品牌、视觉语言
✦ 运营：流量、增长、留存、商业化
✦ 市场：定位、传播、价格、渠道

你要补的最后一块

✦ 看得懂代码库：知道在哪里、是什么
✦ 参与得了架构：选型、权衡、风险
✦ 识别得出忽悠：5 个问题问到底
✦ 用得起 AI：自己改前端、自己读后端

当 CEO 看得懂代码库，
研发会用更直接的语言跟你对话。
当 CEO 看不懂，研发会用术语保护自己。

M1 · 课程定位03 / 45

学习目标 · 三级金字塔

不是当工程师。
是看得懂、说得过、改得动。

          LEVEL 3 · TOP
          改得动
          能 clone 千图代码、读懂目录结构、用 AI 改一行 CSS / 加一个 API 字段
        

          LEVEL 2 · MID
          说得过
          参与架构评审、能问到点子、能拍板权衡（性能 vs 成本 vs 工期）
        

          LEVEL 1 · BASE
          看得懂
          研发说的每个术语你都听得懂，研发画的架构图你能复述
        

Level 1 · 看得懂

你不会被忽悠。当研发说"P99 跌了、QPS 抖了、ES 索引重建中"，你脑中有画面，不需要追问。

Level 2 · 说得过

你能参与决策。"做微服务还是不做？" 你能从工期、运维成本、团队规模、未来扩展四个维度讨论。

Level 3 · 改得动

你能自己动手。用 Claude Code 给千图首页改一个组件、给后端加一个埋点、读懂 ES 配置文件。

M1 · 课程定位04 / 45

学习哲学 · 不背术语，拆机制

市面上的研发课都在教"八股文"。
我们这本只教"第一性原理"。

❌ 传统研发课（八股文）

"什么是 HTTP？" → 7 层模型背诵
"什么是数据库索引？" → B+ 树结构图
"什么是微服务？" → SOA / DDD 概念
"什么是 Redis？" → 9 种数据结构
"什么是 Kubernetes？" → Pod/Node 术语

→ 学完会考试，不会工作。

✅ 本课程（第一性原理）

"用户点登录到看见首页" → 全链路
"千图搜图为什么快" → 倒排索引本质
"为什么千图选微服务而不是单体" → 真实权衡
"Redis 解决了什么问题" → 缓存的存在意义
"K8s 解决的真实痛点" → 部署演进史

→ 学完知道"为什么"，能做决策。

原则一所有概念，必须先讲"它解决了什么问题"，再讲怎么实现

M1 · 课程定位05 / 45

学习方法 · 费曼学习法在本课的落地

每一册 = 一次费曼循环。

01

识 · 概念

读图文，了解概念的"它解决了什么问题"。

阅读 20-40 分钟

02

玩 · 实验

动手 5-15 分钟：用 Claude Code/DevTools 跑通一个 mini demo。

动手 5-15 分钟

03

说 · 复述

用大白话给身边的人讲一遍（产品同事 / 投资人 / 家人）。

复述 5 分钟

04

考 · 小测

10 题选择 + 1 题开放题，识别学得透不透。

考试 10 分钟

费曼原话："如果你不能用大白话讲清楚，你就没真懂。"
本课程把"讲给非工程师"作为通过标准，而不是"刷题正确率"。

M1 · 课程定位06 / 45

为 PM/运营/CEO 设计 · 不走研发的老路

我们走「业务 → 机制 → 代码」，
不走研发的「语法 → 框架 → 业务」。

研发新人的路径（你别走）

学语法（Java/Python/JS）— 3 个月
学框架（Spring/React/Django）— 2 个月
学工程（Git/CI/部署）— 1 个月
看真实代码 — 还要 1 个月
才能开始改业务 — 7 个月+

→ 你没这个时间，也不需要。

CEO 的路径（你该走）

看真实业务的全链路（登录/搜图/支付）
拆出"每一步在做什么、为什么这样做"
看少量关键代码（10-20 行的核心片段）
用 AI 工具直接读懂、直接修改
开始参与架构讨论、做决策

→ 6-8 周到位。

关键差异你不需要会写，你需要会读、问、判断。AI 已经把"会写"这一步降到 30 分钟。

M1 · 课程定位07 / 45

学习路线 · 6 周甘特图（建议节奏）

8 册分布在 6 周，
每册 3-5 天，含阅读 + 实验 + 复述 + 小考。

第 1 周

第 2 周

第 3 周

第 4 周

第 5 周

第 6 周

基础

01研发世界地图3 天

02请求的旅程4 天

数据

03数据库4 天

04架构权衡4 天

实战

05千图核心场景5 天

06非功能性需求4 天

进阶

07代码阅读法5 天

08AI 时代研发5 天

6w

总周期

~30h

阅读总时长

8

动手实验

9

考试 (8 小考 + 1 终考)

M1 · 课程定位08 / 45

学习成果 · 8 维能力雷达

学完以后，你的研发理解能力从内圈跳到外圈。

维度

学前

→

学后

前后端分工20%→85%

架构选型权衡10%→80%

数据建模15%→75%

性能/SLA 判读5%→70%

代码阅读0%→65%

AI 项目工程化30%→90%

M2 · 八册纲要09 / 120

阅读方式 · 每册都是这五段

每册都是同一个五段式。
读法稳定，进度可预测。

📖

01 · 机制

第一性原理拆解：它为什么存在？解决了什么问题？

→

🧪

02 · 实验

5-15 分钟动手 demo：浏览器 DevTools / Claude Code / Postman

→

💻

03 · 代码

读 20-50 行真实代码片段：前后端各一段，配中文注释

→

🎯

04 · 千图映射

这个概念在千图的哪个场景？找谁讨论？怎么参与？

→

✅

05 · 小考

10 选择 + 1 开放题。通过线 80 分。不通过可重读重考。

~3h

每册阅读时长

~30min

每册实验

~15min

每册小考

M0 · 启程10 / 120

学习契约 · 双向承诺

这不是单方面的课程，是你和我的合作。

Wayne 的承诺

① 每册预留 3-5 天，不一口气塞完
② 每册动手做实验，不只是读
③ 每册讲给一个人听（柚柚 5 岁版亦可）
④ 小考 不通过就重读，不糊弄
⑤ 学完去千图 GitHub 仓库真的读一段代码

Claude 的承诺

① 每册图视比 70% 以上，文字仅作注脚
② 每个概念先讲"它解决了什么问题"，再讲实现
③ 每个术语配 PM 翻译卡：研发说什么、老板该听到什么
④ 每册千图业务锚定，不堆通用例子
⑤ 你不通过小考，我重写讲法，不甩锅给"学员悟性"

✓ 共同目标：6-8 周内，你能进千图代码库读懂、改动、参与设计评审

M1 · 第 01 册11 / 120

第 01 册 · 基础篇

研发世界
地图

在千图这样规模的公司里，研发不是一个职业，是八个职业。能区分前端 / 后端 / 全栈 / 架构师 / DevOps / SRE / QA / 数据 / AI，是看懂研发组织架构的起点。

核心问题研发岗位有几种？分别在干什么？

学习目标看懂组织架构图，识别每个岗位的产出物

实验画出千图研发组织架构图

小考5 题选择 + 1 题开放（识岗位）

M1 · 第 01 册12 / 120

研发组织 · 八大岗位

从"用户看见"到"代码跑起来不挂"——
每个岗位都守一段。

前端 FE

用户看到的所有像素。HTML/CSS/JS/React/Vue。

千图 · 网站、客户端、设计稿还原

后端 BE

业务规则、数据存储、API。Java/Go/Python。

千图 · 订单、用户、支付、内容服务

全栈 FS

前后端都干。小公司 / 创业团队主力。

千图 · 小项目 / MVP / Skill 开发

架构师 Arch

画图、定方向、决技术选型。半管理半技术。

千图 · 新业务架构、重大重构决策

DevOps

让代码从仓库跑到线上。CI/CD / K8s / Docker。

千图 · 部署流水线、容器编排

SRE

让线上不挂。监控 / 告警 / 故障演练。

千图 · 双 11 保障、P0 故障响应

QA 测试

代码上线前的最后一关。功能/性能/兼容性。

千图 · 回归测试、自动化测试

数据/AI

数据工程师 / 算法 / AI 工程师。模型 + 数据管道。

千图 · AI 生图、搜图、推荐

PM 翻译卡研发说"我先找架构师拉个会" = 这事跨多个团队 / 影响大 / 需要先有图。你应该问："要不要我也参加？"

M1 · 第 01 册13 / 120

岗位透视 · 前端工程师

前端工程师的一天（千图首页改版项目）

09:30 站会 (15 min)：同步昨天/今天/卡点。"昨天搞定了搜索框组件，今天写卡片列表。"

10:00 看 Figma 设计稿：测量间距、提取颜色、确认交互细节。Figma → 代码的"翻译"工作。

11:00 写组件：React/Vue 组件，写 CSS / TypeScript。结合千图设计系统（btn / card / modal）。

14:00 接后端 API：拿到 JSON 数据，渲染到组件。如果接口字段不够，跟后端 PK。

16:00 性能优化：图片懒加载、首屏加速、骨架屏。Lighthouse 分数从 65 提到 85。

18:30 提 MR/PR：写说明、找同事 Code Review、根据评论改。

前端的核心产出

用户看到的每一个像素
用户感受到的每一次交互（点击/动效/反馈）
页面加载速度（首屏 / FCP / LCP）
多端兼容（PC / 手机 / 平板）

CEO 与前端沟通的关键句

"这个按钮的点击区域够大吗？"
"首屏LCP多少秒？"
"这个组件能复用吗？还是只能这一页用？"
"换设计稿后，多少工作量？"

M1 · 第 01 册14 / 120

岗位透视 · 后端工程师

后端工程师的一天（千图付费会员升级接口）

09:30 设计接口：和产品 PRD 对齐字段。/api/v2/membership/upgrade 该返回什么、错误码怎么定。

10:30 设计数据库：是新加一张表还是改老的？怎么不影响线上？

11:30 写业务逻辑：用 Java/Go 写校验、扣费、调支付 SDK、更新数据库。

14:00 处理边界情况：用户重复点支付怎么办？支付半路超时怎么办？退款怎么处理？

16:00 对接前端：联调。前端反馈"这个错误码我不知道怎么显示"——改文档。

17:30 线上 P0 救火：钉钉炸了——"会员升级失败率 12%"。马上查日志。

后端的核心产出

给前端 / 移动端 提供 API
业务规则的正确性（钱不能错、订单不能丢）
数据存储 表结构 + 索引设计
性能：QPS / 延迟 / 资源占用

CEO 与后端沟通的关键句

"这接口幂等吗？" （用户重复点会扣两次吗？）
"失败率多少？错误怎么对账？"
"QPS 涨 10 倍扛得住吗？"
"这数据谁能改？谁能查？"

M1 · 第 01 册15 / 120

岗位透视 · 全栈 vs 专精

"全栈"不是 1+1，是取舍。
千图什么时候用全栈，什么时候用专精？

全栈工程师

优势：一个人闭环、沟通成本低、迭代快

短板：每一栈都浅一层、复杂场景容易踩坑

适用：MVP 期 / 小项目 / 内部工具 / Skill 开发

千图举例：飞书 Skill 开发、CreatorFlow 实验、内部 admin 后台

专精工程师

优势：深度、性能、复杂业务的稳定性保障

短板：跨栈沟通成本、需要团队配合

适用：核心业务 / 高并发 / 大规模团队

千图举例：搜图核心 ES、AI 生图调度、订单系统

CEO 决策 团队 ≤ 5 人：全栈为主。团队 ≥ 20 人：专精为主 + 1-2 个全栈做"胶水"。

M1 · 第 01 册16 / 120

岗位透视 · 架构师

架构师不是"高级程序员"，是研发的产品经理。
他思考的是3-5 年后的事。

第一关 · 当下

业务能跑通

这次需求能不能在 deadline 之前上线？

→ 这层程序员就能解

第二关 · 半年

还能加新需求吗

下一个迭代加新字段、新接口会不会改死老代码？

→ 这层 Tech Lead 该想

第三关 · 3 年

系统不被推翻

业务从 100 万用户长到 1 亿，架构不需要重写？

→ 这层只有架构师能扛

架构师的四种「武器」

📐 架构图
让所有人看到同一个未来

📋 ADR
Architecture Decision Record，决策留痕

🎯 选型矩阵
5 维打分，剔除主观偏好

⏰ 演进路线
现在 → 6 月 → 18 月分步骤

M1 · 第 01 册17 / 120

岗位透视 · DevOps & SRE

研发只负责"代码能跑通"，
这俩负责"代码跑到线上" + "线上不挂"。

DevOps · "建路的人"

让代码从研发电脑→测试环境→线上服务器，自动化、可重复、不依赖人。

✦ CI 持续集成：代码合并自动跑测试

✦ CD 持续部署：测试过自动发布

✦ Docker 容器化：环境一致性

✦ K8s 容器编排：自动扩缩容

千图：从 git push 到线上生效，平均 8 分钟。

SRE · "守路的人"

代码上线后，监控所有指标、第一时间发现故障、第一时间恢复。可用性 4 个 9 / 5 个 9。

✦ 监控：Grafana 看板、Prometheus 指标

✦ 告警：钉钉机器人、电话告警

✦ 故障演练：主动制造故障验证恢复能力

✦ SLO/SLA：跟业务承诺可用性指标

千图：双 11 期间 SRE 守夜，30 秒发现故障，5 分钟恢复。

PM 翻译卡研发说"这个走 CD 灰度 10%" = 先给 10% 用户用，没问题再全量。CEO 该问："灰度多久？指标看什么？"

M1 · 第 01 册18 / 120

岗位透视 · QA 测试 + 数据/AI 工程师

最后两类岗位：守门员与未来兵种。

QA · 守门员

代码合并前的最后一道防线。手测 + 自动化测试 + 性能测试 + 兼容性测试。

✦ 功能测试：按用户场景走一遍

✦ 回归测试：旧功能没坏

✦ 压测：模拟 10 万 QPS 不挂

✦ 兼容性：iPhone 6/13/15、Edge/Safari/Chrome

千图典型工作：会员升级流程的 20 个 case 全跑一遍。

数据 / AI · 未来兵种

三个细分角色，外行常常混为一谈：

✦ 数据工程师：搭数据管道（ETL / 数仓 / Spark）

✦ 算法工程师：写推荐 / 搜索 / 排序模型

✦ AI/ML 工程师：训练大模型、做 RAG、Agent

✦ Prompt 工程师（新）：写 prompt + 评测 + 优化

千图：搜图算法 / AI 生图 / 主题规划 Skill 全靠他们。

⚠️ 容易混淆 "数据工程师" ≠ "算法工程师"。前者搭管道（数据从哪儿来到哪儿去），后者写模型（数据怎么算出结论）。

M1 · 第 01 册19 / 120

动手实验 · LAB 01

画一张千图研发组织架构图。

任务

列出千图研发团队的真实岗位与人数（你应该比 Claude 更清楚），按"产品线 × 岗位类型"画一张矩阵图。

工具

飞书 多维表格（按行列填）
或 Excalidraw（手画风格）
或 Figma / Whimsical（专业风格）

完成标准

能说出每个岗位的产出物
能说出每个团队的核心 KPI
能识别哪个岗位现在缺人 / 冗余

🧪 互动 · 矩阵脑图模板

网站

AI 业务

基础设施

前端

? 人

-

后端

? 人

AI/算法

-

? 人

-

SRE

→

? 人

把 ? 替换成真实数字，发给你的研发 VP 校对。

⏱ 预计耗时

30-45 分钟（含跟 VP 沟通校对时间）

M1 · 第 01 册20 / 120

小考 · 第 01 册

5 题选择 + 1 题开放。
点选你认为对的答案，会有反馈。

Q1. "我们这次升级要请架构师拉个会" 通常意味着：

Q2. SRE 与 DevOps 最大区别是：

Q3. 团队 5 人、要做 MVP，应优先选：

Q4. "数据工程师" 和 "算法工程师" 区别：

Q5. 研发说 "这个接口幂等" 等于：

Q6 · 开放题：写出千图研发团队 8 个岗位中你最想了解的 3 个，并各写一个你想问的问题。

M2 · 第 02 册21 / 120

第 02 册 · 基础篇

一次请求的
旅程

用户在千图首页点击搜索"猫"，从手指按下到看到结果——200 毫秒里发生了什么？拆开这 200ms，就是看懂整个互联网架构的起点。

核心问题点一下到看见，经历了几个"中间人"？

学习目标画出全链路时序图，识别每段在做什么

实验用 Chrome DevTools 抓千图真实请求

小考5 题选择 + 1 题诊断（哪段慢）

M2 · 第 02 册22 / 120

全链路 · 一次"搜图"请求

你在 qiantu.com 搜"猫"，
200ms 里发生了 7 件事。

用户感知
200ms 是流畅的上限。超 500ms 用户会感觉"卡"。

瓶颈定位
最长的那条 = 优化重点。本图中是"渲染"。

CEO 该问
"我们的 P99 时间分布在哪一段？怎么压？"

M2 · 第 02 册23 / 120

第一段 · DNS · 互联网的电话簿

DNS = 把 qiantu.com 翻译成 IP 地址。
没有它，你打不通服务器的"电话"。

第一性原理

人类记得住 qiantu.com，记不住 39.107.42.18。DNS 就是"人类语言 → 机器语言"的翻译器。

缓存机制

DNS 结果会被浏览器、路由器、运营商层层缓存。所以第二次访问 DNS 几乎是 0ms。

CEO 该听到

研发说"DNS 污染"= 用户被劫持，访问千图被导到假网站。需要 HTTPDNS / DNS over HTTPS 防御。

M2 · 第 02 册24 / 120

第二段 · CDN · 把内容搬到用户家门口

为什么千图图片加载飞快？
答案是 CDN。

第一性原理

如果上海用户每次都访问北京源站，要 30ms。如果把图片放在上海的 CDN 节点，1ms 就拿到。

三件事

缓存静态资源（图片/CSS/JS）
就近接入（用户去最近的节点）
边缘计算（在节点上做轻量逻辑）

CEO 该问

"我们的 CDN 命中率多少？"（> 90% 才及格）
"带宽成本占总成本比例？"（千图图片站重灾区）
"图片更新策略怎么定？刷新机制？"

M2 · 第 02 册25 / 120

第三段 · 网关 + 负载均衡

网关 = 城门，负载均衡 = 门口的引导员。
所有流量都从这里进来，然后分散到几百台服务器。

网关做四件事

鉴权：你登录了吗？Token 有效吗？
限流：单 IP 一秒最多 100 次
分发：/api/user → 用户服务，/api/order → 订单服务
日志：所有请求落到日志系统

负载均衡三种策略

轮询：依次分配（最简单）
最少连接：哪台空闲发哪台
哈希：同一用户固定到同一台（session 黏滞）

CEO 翻译卡

研发说"限流降级了" = 流量太大，主动拒绝一部分请求，保护核心。你该问："核心是哪些？被牺牲的是哪些？"

M2 · 第 02 册26 / 120

第四段 · 应用服务器 · 业务逻辑

业务规则的所有判断，都在这里发生。
会员折扣、库存扣减、积分计算……

// 千图会员升级接口 (后端 Java 伪代码)
@PostMapping("/api/membership/upgrade")
public Response upgrade(Long userId, String plan) {

  // 1. 鉴权：用户登录了吗？
  User user = authService.checkLogin(userId);

  // 2. 业务校验：当前会员状态？能升级吗？
  if (user.isAlreadyPremium()) {
    return Response.error("已是高级会员");
  }

  // 3. 扣费（调支付服务）
  PayResult pay = paymentService.charge(userId, 99.00);

  // 4. 写数据库
  membershipDao.upgrade(userId, plan);

  // 5. 发消息（异步：发邮件/推送/积分）
  mqService.send("USER_UPGRADED", userId);

  return Response.ok(pay.transactionId);
}
        

应用做 5 件事

鉴权：核对用户身份
校验：参数合法吗？状态对吗？
外部调用：支付 / 短信 / 三方接口
持久化：写数据库
异步消息：触发后续动作

⚡ 性能关键

这段代码慢，整个请求就慢。优化重点：尽量异步、能缓存就缓存、能批量就批量。

CEO 该问

"如果支付成功但数据库写失败怎么办？"——这是"分布式事务"问题，无银弹，要权衡。

M2 · 第 02 册27 / 120

第五段 · 数据库 · 持久化记忆

所有"用户的状态"、"订单"、"关系"
都躺在数据库里。

关系型 vs 非关系型 vs 向量

关系型 MySQL / PostgreSQL · 强一致 · 表 / 行 / 列

非关系型 MongoDB / Redis · 灵活 · 文档 / KV / 缓存

向量库 Pinecone / Milvus · 相似度搜索 · AI 必备

索引的本质

没索引 = 翻完整本书找一个词。有索引 = 查目录直接翻到那一页。千图用户表 5000 万行，没索引一次查询要 60 秒，加索引后 10ms。

-- 千图用户表查询 SQL
SELECT id, name, plan, points
FROM users
WHERE email = '[email protected]'
LIMIT 1;

-- 没索引：扫 5000 万行 → 60 秒
-- 有 email 索引：直接定位 → 10ms

EXPLAIN SELECT ... ;
/*
  +----+-------+------+------+----------+
  | id | type  | rows | key  | extra    |
  +----+-------+------+------+----------+
  | 1  | const |    1 | idx_ | Using    |
  |    |       |      | email| index    |
  +----+-------+------+------+----------+
*/

-- 慢查询的味道：
--   type=ALL（全表扫）
--   rows=5000万（行数巨大）
--   key=NULL（没用上索引）
        

PM 翻译研发说"这个 SQL 没走索引" = 查询会全表扫，慢。你该问："要加索引吗？代价是什么？"（索引让写入变慢，需要权衡）

M2 · 第 02 册28 / 120

第六段 · 缓存 · 速度的秘密武器

数据库一次查询 10ms。
Redis 一次查询 0.1ms。100 倍差距。

缓存解决什么

"热点数据" 重复查询造成数据库压力。把热门内容放内存，从磁盘搬到内存，速度 ×100。

三大经典坑

击穿：一个 key 失效瞬间，请求全打 DB
穿透：查不存在的数据，缓存无用
雪崩：大量 key 同时失效

千图举例

首页热门图、热搜词、用户会话、限流计数器——全靠 Redis。Redis 挂了，千图首页打不开。

M2 · 第 02 册29 / 120

第七段 · 响应返回 + 浏览器渲染

数据回到浏览器之后，
还要渲染——把 JSON 变成你眼睛看到的图。

① 解析 HTML

浏览器读到 <html> → 建 DOM 树（结构）

<div class="card">...</div>

② 计算样式

CSS 应用到每个节点 → 算颜色、字号、布局位置

.card { padding: 16px; }

③ 绘制 + 合成

显卡把每一帧像素画到屏幕。60FPS = 每帧 16.6ms。

// 每帧 16ms 内必须完成

三个核心性能指标 · Core Web Vitals

LCP：最大内容绘制 < 2.5s（首屏图加载完）

FID：首次交互延迟 < 100ms（点击到响应）

CLS：布局位移 < 0.1（页面不"跳动"）

M2 · 第 02 册30 / 120

合成 · 200ms 七段全景

把七段串起来：这就是一次请求。
遇到任何一段慢，你都能定位到环节。

① DNS浏览器问运营商：qiantu.com 对应哪个 IP？10ms缓存可省

② TCP+TLS和服务器握手、建加密通道20msHTTP/3 优化

③ CDN就近节点接收请求，决定是否回源10ms命中率决定性

④ 网关鉴权 → 限流 → 路由到正确服务10ms流量入口

⑤ 应用校验 → 业务逻辑 → 调外部服务50ms业务核心

⑥ 缓存/DBRedis 拿热点 / 否则查 MySQL30ms95% 走缓存

⑦ 响应传回浏览器 → 渲染像素70ms网络+渲染

合计 · 200ms = 流畅的极限

M2 · 第 02 册31 / 120

动手实验 · LAB 02

用 Chrome DevTools 抓千图首页的真实请求瀑布图。

操作步骤（5 分钟）

在 Chrome 打开 qiantu.com
右键 → 检查（或 F12）
切到 Network 面板
刷新页面（Cmd+R）
观察瀑布图：每个请求多长

关注 5 个指标

Time：单次请求耗时
Size：传输大小（图片 / JS 大小）
Waterfall：哪些可以并行？
Cache (200 from cache)：命中缓存吗？
Status：是否都是 200 OK

Chrome DevTools · Network

Name Status Type Size Time ─────────────────────────────────────────── qiantu.com 200 html 35KB 142ms main.js 200 js 240KB 320ms main.css 200 css 42KB 88ms logo.png 304 img cache 5ms /api/feed 200 xhr 18KB 189ms cover_001.jpg 200 img 78KB 52ms cover_002.jpg 200 img 82KB 55ms /api/banner 200 xhr 3KB 62ms ─── waterfall ────────────────────────────── qiantu.com ▇▇▇ main.js ▇▇▇▇▇▇▇ main.css ▇▇ /api/feed ▇▇▇▇ cover_001.jpg ▇▇ cover_002.jpg ▇▇

✓ 完成标准：你能指出"哪个请求最慢、为什么"，并提一个优化建议。

M2 · 第 02 册32 / 120

小考 · 第 02 册

5 题选择 + 1 题诊断。
点选答案查看反馈。

Q1. DNS 的核心作用：

Q2. 千图图片很快，最大功臣是：

Q3. 网关 ≠ 负载均衡的核心区别：

Q4. Redis 比 MySQL 快 100 倍的本质：

Q5. LCP > 4 秒意味着：

Q6 · 诊断题：千图首页打开慢，从 DNS → CDN → 网关 → 应用 → DB → 响应这 6 段，你会先怀疑哪段？为什么？

M3 · 第 03 册33 / 120

第 03 册 · 数据篇

数据库
与数据建模

所有"状态"都存在数据库里——用户、订单、积分、AI Token。看懂表结构和索引，就看懂了千图业务的核心模型。这一册是所有 CEO 必须懂的硬骨头。

核心问题千图数据怎么存？为什么查得快？

学习目标看懂 ER 图、读懂 5 句 SQL、识别慢查询

实验用 Claude Code 看一条 SQL 解释 EXPLAIN

小考5 选 + 1 设计题（设计积分表）

M3 · 第 03 册34 / 120

第一性原理 · 数据库是什么

数据库 = 一个超级 Excel，
但是千万人同时读写不打架，电断了数据不丢。

类比：Excel vs 数据库

能力

Excel

数据库

行数上限

100 万

100 亿+

同时使用

1-3 人

百万 QPS

查询速度

秒级

毫秒级

断电安全

可能丢

不丢

事务

无

ACID 保证

数据库的 4 个核心承诺 · ACID

Atomic 原子：要么全成，要么全败（不能"扣了钱没发货"）
Consistent 一致：数据规则永远成立
Isolated 隔离：你改的时候别人看不到中间状态
Durable 持久：写入后断电也不丢

CEO 翻译

研发说"事务回滚" = 一组操作失败了，把所有改动全部撤销，回到初始状态。支付场景必备。

M3 · 第 03 册35 / 120

数据建模 · 千图核心 ER 图

这张图把千图业务的核心实体串起来。
箭头 = 谁引用谁。

PK 主键
唯一标识，类似身份证号

FK 外键
引用另一张表的主键

IDX 索引
让查询快 100 倍

M3 · 第 03 册36 / 120

核心三件套 · 主键 / 外键 / 索引

这三个概念，看懂表结构的钥匙。
研发讨论 80% 的 DB 话题离不开它们。

🔑 主键 PK

独一无二的身份证

每行数据的唯一标识，永不重复。通常是自增整数或 UUID。

CREATE TABLE users (
  id BIGINT PRIMARY KEY
  AUTO_INCREMENT,
  ...
);

用 id 而不用 email 当主键 → 后续可改邮箱

🔗 外键 FK

引用另一张表的主键

表达"这条订单属于哪个用户"。FK 保证引用的合法性。

CREATE TABLE orders (
  user_id BIGINT,
  FOREIGN KEY (user_id)
    REFERENCES users(id)
);

实践中：大厂常常不加 FK 约束，靠业务保证

⚡ 索引 IDX

查询的加速器

本质是"目录"。让数据库快速定位，避免全表扫描。

CREATE INDEX idx_email
  ON users(email);

-- 副作用：
-- 查询↑写入↓占空间↑

索引≠免费午餐：每加一个索引，写入就慢一点

CEO 该问研发说"加个索引就好了" → 你该问："那写入会慢多少？空间增加多少？这个查询频繁吗？" 索引是读写的权衡。

M3 · 第 03 册37 / 120

数据库选型 · 三大流派

不同场景用不同库。
千图同时用三种。

关系型 SQL

MySQL / PostgreSQL

表 + 行 + 列，强一致，事务保证。钱、订单、用户必须用。

千图用法

用户表、订单表、积分表、AI Token 计费表

非关系型 NoSQL

MongoDB / Redis / ES

文档 / KV / 全文索引，灵活、快、扩展性强。不要求强一致的场景。

千图用法

用户会话（Redis）、内容标签（Mongo）、搜图（ES）

向量数据库

Milvus / Pinecone

存"语义向量"，做相似度搜索。AI 时代必备。

千图用法

"以图搜图"、"找相似设计"、RAG 知识检索

选型问题

→ SQL

→ NoSQL

→ 向量

钱相关？

✓ 必选

不要

扩展性要求高？

中

✓ 强

相似度搜索？

否

部分（ES）

✓ 必选

M3 · 第 03 册38 / 120

事务 · 数据库最贵的功能

事务 = 要么全部成功，要么全部回到原点。
支付、转账、库存——离开事务，业务必崩。

没事务的灾难

千图用户付了 99 元升级会员，第一步扣款成功，第二步升级权限失败，第三步发邮件失败。

结果：用户扣了钱，但权限没拿到。客诉爆炸。

有事务的拯救

BEGIN TRANSACTION;

  -- ① 扣钱
  UPDATE users SET balance = balance - 99
    WHERE id = 123;

  -- ② 升级权限
  UPDATE users SET plan = 'premium'
    WHERE id = 123;

  -- ③ 插入订单
  INSERT INTO orders ...;

COMMIT;  // 三步全成才生效
-- 任何一步失败 → ROLLBACK 全部撤销
          

⚠️ 进阶概念 分布式事务（跨服务的事务）非常昂贵。千图实践中常用"最终一致性"：扣款成功后异步重试发权限/发邮件，靠对账补偿。

M3 · 第 03 册39 / 120

SQL 速读 · 五句通天下

不用学全套 SQL，
读懂这5 句，你能看懂 80% 的查询。

① SELECT 查

SELECT id, name, plan
FROM users
WHERE plan = 'premium';

"从 users 表里查所有付费用户的 id/name/plan"

② INSERT 增

INSERT INTO orders
  (user_id, amount, status)
VALUES (123, 99.00, 'paid');

"插入一条新订单"

③ UPDATE 改

UPDATE users
  SET plan = 'premium',
      updated_at = NOW()
WHERE id = 123;

"把用户 123 升级为付费"

④ DELETE 删

DELETE FROM orders
WHERE status = 'cancelled'
  AND created_at < '2023-01-01';

"删除 2023 年前已取消的订单"

⑤ JOIN 跨表关联（最强大也最易出问题）

SELECT u.name, COUNT(o.id) AS order_count, SUM(o.amount) AS total
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.plan = 'premium'
GROUP BY u.id;

"统计每个付费用户的订单数和总金额"——这一句开始就是慢查询的高发区。

⌨ 实战记忆法 SELECT 查 / INSERT 增 / UPDATE 改 / DELETE 删 / JOIN 跨表

M3 · 第 03 册40 / 120

真实案例 · 千图慢查询解剖

某天你的研发说："首页慢了，P99 跳到 800ms。"
真相在 EXPLAIN 里。

❌ 错误代码

-- 首页热门内容查询
SELECT *
FROM assets
WHERE type = 'image'
  AND tags LIKE '%cat%'
ORDER BY created_at DESC
LIMIT 20;

SELECT * 查所有列（浪费 IO）
LIKE '%cat%' 索引失效（前缀模糊）
ORDER BY created_at 无索引
结果：扫 1 亿行，800ms

✓ 优化后

-- 只查需要的列 + 用 tag_index 表
SELECT a.id, a.url, a.title
FROM assets a
JOIN asset_tags t ON a.id = t.asset_id
WHERE t.tag = 'cat'     -- 走索引
  AND a.type = 'image'
ORDER BY a.id DESC     -- 走主键
LIMIT 20;

用单独的 asset_tags 倒排表
ORDER BY 主键，自动有序
只查必要字段
结果：扫 1000 行，5ms

优化前
800ms

→

优化后
5ms

提升
×160

M3 · 第 03 册41 / 120

动手实验 · LAB 03

用 Claude Code，让 AI 帮你读懂 EXPLAIN。

操作（10 分钟）

找研发要一条线上的 SQL（自己看着挑感兴趣的）
让研发跑 EXPLAIN [SQL]
把结果粘给 Claude Code
问："这条 SQL 有问题吗？如何优化？"
读 AI 解释，对照本课程的概念验证

完成标准

能用大白话给研发复述：这条 SQL 走的什么索引、扫了多少行、瓶颈在哪。

MySQL · EXPLAIN 输出示例

🧪 互动思考

三个魔法关键字 · 看 EXPLAIN 结果：
type：const > ref > range > ALL（全表扫，烂！）
rows：越小越好
key：是否用了索引（NULL = 没用）

M3 · 第 03 册42 / 120

小考 · 第 03 册

5 题选择 + 1 题设计。

Q1. 索引的代价是：

Q2. ACID 中 "A" 是：

Q3. "以图搜图" 应该用：

Q4. WHERE name LIKE '%cat%' 为什么慢？

Q5. 千图付款扣钱写表，应保证：

Q6 · 设计题：千图要新增"积分系统"。请列出 points_history 表至少 5 个字段（含主键、外键、索引建议）。

M4 · 第 04 册43 / 120

第 04 册 · 数据篇

架构与
权衡

"我们要不要做微服务？" 这是 CEO 最常被问的研发问题之一。架构没有最优解，只有最适合此刻团队规模、业务阶段的解。这一册教你看懂主流架构的真实代价。

核心问题单体/微服务/Serverless 怎么选？

学习目标用 5 维矩阵打分，自己拍板架构方向

实验画千图当前架构图，识别可优化点

小考5 选 + 1 决策题（推荐路径）

M4 · 第 04 册44 / 120

演进 ① · 单体架构 · Monolith

所有功能在一个工程里，
编译成一个包，部署到一台/几台机器。

优势

简单：写、测、部署都直接
性能：模块间调用零网络开销
事务：本地事务一致性强
团队小：5 人以下完美

代价

代码膨胀：50 万行后改一行编译 5 分钟
故障扩散：一个 bug 整个系统挂
团队冲突：20 人同时改一个工程 = 合并地狱
技术固化：全栈用同一种语言

千图猜测：网站早期 2010-2015 大概率是单体（PHP/Java），后端业务集中、技术栈一致。

M4 · 第 04 册45 / 120

演进 ② · 微服务 · Microservices

每个业务能力 = 独立的小服务。
用户服务 / 订单服务 / 支付服务 / 搜图服务……各自部署、各自扩缩。

优势

团队独立：每个服务一小队人
技术异构：搜图用 Python，订单用 Java
故障隔离：搜图挂不影响支付
独立扩缩：双 11 只扩订单不扩用户

代价 · 不便宜

调用变复杂：跨服务调用 + 容错
分布式事务：跨服务一致性巨痛
运维爆炸：从 1 个变 30 个要监控
排查困难：链路追踪/日志收集是必需品

千图猜测：现在大概率以微服务为主，按业务域拆分（用户/订单/内容/AI），用 K8s + 服务网格运维。

M4 · 第 04 册46 / 120

演进 ③ · Serverless · 无服务器

"服务器我不管"——
你只写函数，平台帮你跑、帮你扩、帮你收钱。AI 时代的主流形态。

写代码

// 一个函数 = 一个 API
export async function handler(req) {
  const imageUrl = req.body.url;
  const result =
    await callAIModel(imageUrl);
  return { result };
}

平台帮你做

自动起容器 / 杀容器
流量大自动扩 1000 实例
没流量降到 0 不收钱
HTTPS / 负载均衡 / 灰度

谁在用

Vercel (前端 + Edge Functions)
AWS Lambda / Cloudflare Workers
阿里云函数计算 / 腾讯云 SCF
AI 创业项目 90%+

⚠️ 不是银弹

冷启动慢
首次调用 1-3 秒

厂商锁定
迁移成本高

调试复杂
本地难复现

长任务受限
单次最长 15 分钟

M4 · 第 04 册47 / 120

CEO 决策模型 · 五维选型矩阵

下次研发说"我们要做微服务"，
用这5 维矩阵压一压，逼出真实理由。

维度

单体

微服务

Serverless

① 团队规模

≤ 10 人 ✓

≥ 30 人

2-10 人 ✓

② 业务复杂度

低-中

高 ✓

事件驱动 ✓

③ 流量模式

稳定

大且分布不均 ✓

脉冲式 ✓

④ 运维能力

弱也行

必须有 SRE

几乎不需要

⑤ 成本模型

服务器固定

高 (人 + 机器)

按调用次数

CEO 5 问 "做微服务" 之前必问：① 团队真到 30 人了吗？② 真的有跨服务的事务问题吗？③ SRE 谁来招？④ 监控/链路追踪谁搭？⑤ 大概要多花多少钱？

M4 · 第 04 册48 / 120

真实演进案例 · 三家公司

不是"一开始就微服务"，
而是"单体活到瓶颈再拆"。

Stripe

"用单体到上市"

Stripe 早期是 Ruby on Rails 单体，2020 年 IPO 前依然有大量单体代码。Stripe 工程师博客名言："复杂度推迟到必须解决时"。

→ 单体不丢人，关键是 modular

"3 年从单体到微服务"

Pinterest 2014 年开始拆，到 2017 年才完成。整个过程渐进式，每次只拆一个高峰瓶颈的模块。

→ 拆，但慢慢拆

千图（推测）

"按业务域拆 + AI 用 Serverless"

核心业务（搜图/订单/会员）大概率是微服务，AI 生图模块用 Serverless（按调用次数计费，配合 GPU 弹性）。

→ 混合架构，因地制宜

📌 共同规律：① 业务上瓶颈再拆；② 一次拆一个；③ 拆完之前不投资新功能；④ 老代码先保留兼容。

M4 · 第 04 册49 / 120

实战决策树 · 现在该用哪种

把矩阵翻译成流程图。
下次会议上你可以直接照着问。

M4 · 第 04 册50 / 120

实战还原 · 千图架构推测

基于业务规模 + 行业惯例，
千图大概率长这样：

⚠️ 以上为基于业务推测的假设性架构，请向千图研发 VP 验证后修正

M4 · 第 04 册51 / 120

动手实验 · LAB 04

把 S50 的千图架构推测图，拿去和研发 VP 对一对。

操作（30 分钟）

截图保存 S50 的架构推测图
找研发 VP / Tech Lead，给他看图
问："这张图哪里错了？哪里漏了？"
记录修正版（语言、版本、规模）
问"我们目前的架构演进路线是？"

⚠️ 不要这样问

❌ "我们是不是该上微服务？" (设套)
❌ "这是不是太老了？" (评判性)
✅ "现在最容易崩的瓶颈在哪？" (开放性)
✅ "如果重来一次你会怎么做？" (反思性)

5 个关键问题

我们的核心服务有几个？分别用什么语言？
最大单一故障会让什么停摆？（识别 Single Point of Failure）
性能瓶颈现在排第一的是？（数据库？某个外部服务？）
下一步重构计划是什么？（看 6 个月路线）
AI 业务的架构有什么不同？（推理服务 / Token 计费）

完成标准：回来你能默写出千图真实架构图（含语言/版本/规模）。

M4 · 第 04 册52 / 120

小考 · 第 04 册

5 题选择 + 1 题决策。

Q1. 5 人 MVP 团队最适合：

Q2. AI 生图 + GPU 调度，最适合：

Q3. 微服务的最大代价：

Q4. Stripe IPO 前依然单体，给我们的启示是：

Q5. Serverless 的"冷启动"指：

Q6 · 决策题：千图研发 VP 说"我们今年要把 PHP 单体全部拆成 Go 微服务"。用本章 5 维矩阵给出 5 个你必须问的问题。

M5 · 第 05 册53 / 120

第 05 册 · 实战篇 · 含金量最高

千图核心
场景实战

所有前 4 册学的概念，全部在这一册落地到千图业务：登录、支付、搜图、AI 生图。看完你会知道千图每一个页面的"背后代码故事"。

场景 A用户登录：密码 · JWT · OAuth · 三方登录

场景 B充值支付：发起 · 回调 · 对账 · 退款

场景 CES 搜图：倒排索引 · 向量召回 · Rerank

场景 DAI 生图：队列 · GPU · Token 计费

M5 · 场景 A · 登录54 / 120

场景 A · 登录 · 第一步：密码不能存明文

用户密码绝对不能存明文。
用哈希 + 加盐，让黑客拿到数据库也无能为力。

❌ 错误：明文存密码

// 千万不要这样写！
INSERT INTO users (email, password)
VALUES ('[email protected]', 'Wayne123!');
          

数据库泄露 → 所有用户密码裸奔 → 一夜 P0 故障

✓ 正确：哈希 + 加盐

// 注册时
const salt = bcrypt.genSalt(10);
const hash = await bcrypt.hash(
  password, salt
);
// 存入 DB：
// $2b$10$rTzGYxNh...kT3Bx4 (60 字符)

// 登录时
const hash = db.get('password_hash');
const ok = await bcrypt.compare(
  inputPassword, hash
);
          

哈希函数
单向：明文→密文，无法逆推

加盐 salt
每个用户独立的随机字符串

bcrypt
业界标准 · 慢哈希（防暴力破解）

M5 · 场景 A · 登录55 / 120

场景 A · 登录 · 第二步：如何记住"我已登录"

HTTP 是无状态的。
每次请求服务器都不认识你——除非你带"身份证"。

方案 ① · Session

服务器记忆型

登录成功 → 服务器生成 session_id
session_id 存 Redis，过期时间 7 天
浏览器存 cookie={session_id}
每次请求带 cookie → 服务器查 Redis

优势：登出立刻生效（删 Redis）
代价：每次请求查 Redis，依赖中心化存储

方案 ② · JWT

自描述型 Token

登录成功 → 服务器签发 JWT（含 user_id + 过期时间）
JWT 整个发给浏览器
浏览器 localStorage 或 cookie 存 JWT
每次请求带 JWT → 服务器只验签名

优势：无状态，服务器不查 DB
代价：登出不立即生效（要黑名单机制）

// JWT 长这样（三段 base64，点分隔）
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTcxNjk5OTk5OX0.x9k4Lz...
Header Payload Signature

M5 · 场景 A · 登录56 / 120

场景 A · 登录 · 第三步：用微信/Google 登录

用户懒得注册？
用 OAuth，让微信/Google 帮你认证。

CEO 关键用户的微信密码千图永远拿不到。我们只拿到 openid（微信用户的唯一标识）和昵称、头像。"授权而非密码共享"。

M5 · 场景 A · 登录57 / 120

场景 A · 前后端对接 · 真实代码

这就是前后端接口对接的样子。
左边是前端代码，右边是后端代码，中间是 JSON。

前端 · React/TypeScript

// 千图登录组件
async function handleLogin(email, password) {
  const res = await fetch('/api/auth/login', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ email, password })
  });

  const data = await res.json();

  if (res.ok) {
    // 保存 JWT 到 localStorage
    localStorage.setItem('token', data.token);
    navigate('/dashboard');
  } else {
    toast.error(data.message);
  }
}

后端 · Java/Spring

// 千图登录接口
@PostMapping("/api/auth/login")
public Response login(@RequestBody LoginDTO dto) {

  // 1. 查用户
  User user = userDao.findByEmail(dto.email);
  if (user == null) {
    return Response.error(401, "账号不存在");
  }

  // 2. 校验密码
  if (!bcrypt.compare(dto.password, user.passwordHash)) {
    return Response.error(401, "密码错误");
  }

  // 3. 签发 JWT
  String token = jwtUtil.sign(user.id);

  return Response.ok({ "token": token });
}

前后端"协议"=接口文档：URL、方法（POST）、请求字段、响应字段、错误码。研发对接 80% 时间花在这上面。

M5 · 场景 B · 支付58 / 120

场景 B · 充值支付 · 全链路

千图会员升级，9 步走完。
每一步都可能出问题，每一步都要对账兜底。

M5 · 场景 B · 支付59 / 120

关键概念 · 异步通知 (Webhook)

支付 = 异步过程。
"你不知道用户什么时候付完"，所以支付平台主动来通知你。

同步设计的灾难（错误）

"调支付接口，等用户支付完，等到结果再返回。"

HTTP 连接最长撑 30 秒，扛不住用户支付 2 分钟
用户扫码后跳到支付 App，前端连接已断
等待期间服务器资源占用严重

异步回调的智慧（正确）

"千图先返回订单号，前端轮询。支付平台支付成功后，主动调千图的回调 URL。"

// 千图回调接口
@PostMapping("/pay/callback")
public String callback(@RequestBody PayNotify n) {
  // 1. 验签
  if (!verifySign(n)) return "fail";

  // 2. 幂等检查（同一通知可能来 N 次）
  if (isProcessed(n.transactionId)) return "ok";

  // 3. 更新订单 + 升级会员（事务）
  orderService.markPaid(n.orderId);

  return "ok";
}
          

⚠️ 幂等支付平台为了防漏，同一笔通知可能给你 N 次。千图必须保证"多次通知 = 一次升级"，否则用户付一次扣到三次钱（或被升 3 次会员）。

M5 · 场景 B · 支付60 / 120

场景 B · 支付 · 后续工作（不可省略）

支付不是"扣完钱就结束"。
后面还有对账、退款、争议三件大事。

每日对账

千图账 == 微信账？

每天 02:00，下载昨天微信支付的所有流水，跟千图自己的订单表比对：

金额是否一致？
笔数是否一致？
有"微信付了千图没记"的吗？(漏单)
有"千图记了微信没付"的吗？(脏单)

退款流程

原路退回

用户申请退款 → 千图人工审核（或自动审批） → 调支付平台退款接口 → 用户原路退回（支付宝退到余额宝，微信退到零钱）。

坑：退款部分成功 → 怎么处理？
坑：退款超时 → 后台显示什么状态？

争议处理

用户投诉 / 反诈

用户向微信投诉"千图扣了我的钱"，微信收到客诉会要千图举证。研发要准备：

订单完整链路日志
用户操作记录截图
风控分（首次付款？小号？）
72 小时内回复举证

📌 CEO 该问："我们的对账有自动告警吗？" 漏单率 > 0.1% 就该告警，否则一年下来损失百万。

M5 · 场景 C · 搜图61 / 120

场景 C · 千图搜图 · 倒排索引

千图 5 亿张图，搜"猫" 50ms 返回。
秘密是倒排索引（不是 SQL）。

❌ 正排（SQL 思维）

"扫一遍 5 亿张图，找标签里有'猫'的。"

SELECT id FROM assets
WHERE tags LIKE '%cat%';
-- 5 亿行全表扫描 → 3 分钟超时

✓ 倒排（搜索引擎思维）

提前建好"词 → 文档列表"的字典。查"猫"，直接看字典。

倒排索引长这样

猫 → [1, 23, 891, 2003, 7891, ...]

可爱 → [23, 105, 891, 9012, ...]

动物 → [1, 23, 891, 4502, ...]

背景 → [56, 102, 2003, ...]

搜"可爱的猫" = 查 "可爱" + 查 "猫"，取交集 → 23, 891

ES (Elasticsearch) = 业界标准的开源倒排索引引擎。千图、淘宝、Wikipedia 都在用。

M5 · 场景 C · 搜图62 / 120

场景 C · 搜图 · 进阶 · 向量检索

用户搜"橙色 vintage 海报"——
关键词不在标签里怎么办？语义匹配来救场。

CLIP 是什么

OpenAI 2021 模型。能把文字和图片都压成同一空间的向量（512 维数组）。两个向量越近，语义越近。

千图做法

所有图片提前用 CLIP 算好向量，存 Milvus
用户输入"橙色海报"，文字也过 CLIP
Milvus 找最近的 1000 个图片向量
返回前 50 张 → 走 Rerank 模型重排

CEO 痛点：向量库的存储成本是普通数据库 5-10 倍。要建立"热门图先入库 + 冷门按需建"的预算策略。

M5 · 场景 C · 搜图63 / 120

场景 C · 搜图 · 两阶段架构

业界搜索 = 召回 + Rerank。
第一阶段快但粗，第二阶段慢但准。

召回阶段

用 ES (倒排) + Milvus (向量) 并行召回，宁多勿漏。

Rerank 阶段

用深度学习模型（千图自训练）综合相关度、热度、个性化排序。

业务可调

"想推付费图" → Rerank 加付费图权重。"排序是商业决策"。

M5 · 场景 D · AI 生图64 / 120

场景 D · AI 生图 · 千图的 AI 业务核心

用户输入"橙色 vintage 海报" → 千图返回 4 张图。
背后是队列 + GPU + Token 计费三件套。

为什么要队列
GPU 一次只能跑 1-4 个任务，峰值流量必须排队，不能挂掉。

GPU 调度
用 K8s + Triton / vLLM，按"GPU 利用率"分发，平摊压力。

异步通知
前端轮询 / WebSocket，"图生成好了" → 推送给用户。

M5 · 第 05 册65 / 120

动手实验 · LAB 05

用 Claude Code mock 一次完整支付回调。
实际感受"异步通知"和"幂等"的味道。

操作（45 分钟）

新建一个目录 / 项目，告诉 Claude Code：
"帮我写一个 Node.js 模拟支付服务，含 /api/pay/create 和 /api/pay/callback 两个接口，要做幂等校验。"
跑起来（npm start）
用 Postman/curl 请求三次同一个回调
验证：只更新订单一次

体感目标

明白"事件驱动"是什么感觉
明白"幂等"为什么是支付的命门
会用 AI 工具调用、跑通、调试

Terminal · curl 模拟回调三次

$ curl -X POST localhost:3000/api/pay/callback \ -d '{"order_id":"O123","trans_id":"T1"}' { "status": "success", "action": "upgraded" } $ curl -X POST localhost:3000/api/pay/callback \ -d '{"order_id":"O123","trans_id":"T1"}' { "status": "success", "action": "skipped (idempotent)" } $ curl -X POST localhost:3000/api/pay/callback \ -d '{"order_id":"O123","trans_id":"T1"}' { "status": "success", "action": "skipped (idempotent)" } # ✓ 用户没被多次升级 # ✓ 数据库只更新一次 # ✓ 第三方平台收到的都是 200 OK

M5 · 第 05 册66 / 120

小考 · 第 05 册 · 含金量最高

6 题选择 + 1 题方案题。

Q1. 用户密码该如何存储：

Q2. JWT 相比 Session 最大优势：

Q3. 微信登录中，千图能拿到用户的微信密码吗：

Q4. 支付回调要"幂等"，因为：

Q5. ES 倒排索引能解决：

Q6. 搜"橙色 vintage" 想用语义搜索，该用：

Q7 · 方案题：千图新增"批量 AI 抠图"功能，用户上传 50 张图等结果。请画出后端架构（提示：队列 + GPU + 异步通知 + 状态查询）。

M6 · 第 06 册67 / 120

第 06 册 · 实战篇

非功能性
需求

"功能能跑通"只是第一步。CEO 要会读的是"功能背后的非功能"——性能、稳定性、安全性、可观测性。这些指标决定千图能不能扛住双 11，能不能不被黑。

性能QPS / TPS / P99 / 延迟 / 吞吐

大促预案缓存 + 限流 + 熔断 + 降级

安全OWASP Top 10 + 千图最常见 5 种

监控Grafana 看板 + 告警 + SLO

M6 · 性能68 / 120

性能 · 4 个英文缩写听不懂就被忽悠

研发说话张口闭口 QPS / TPS / 延迟 / 吞吐，
这 4 个概念一定要分清。

QPS

每秒查询数

Queries Per Second。一秒钟服务器处理多少次请求。

千图首页 ≈ 1-2 万 QPS

TPS

每秒事务数

Transactions Per Second。QPS 的"重型版"，含写入/事务。

订单系统 ≈ 1k-5k TPS

Latency

单次延迟

一次请求从发出到拿到结果用了多少毫秒。

API 平均 50-200ms

Throughput

吞吐量

单位时间通过的数据量。常用于带宽 / 文件传输。

CDN 带宽 ≈ 100 Gbps

关键关系 QPS 高 + 延迟低 = 服务好；QPS 高 + 延迟高 = 快崩；QPS × 延迟 = 并发数（小学律）。

M6 · 性能69 / 120

性能 · P 是什么 · 为什么不用"平均值"

研发说"P99 跌了"——
意思是100 个用户里有 1 个慢到放弃。

为什么不用平均值

假设 100 次请求里：

99 次 · 50ms
1 次 · 5000ms
平均 = 99.5ms（看起来还好）
实际有 1% 用户卡 5 秒（崩溃）

→ 平均值掩盖了真实痛苦，所以业界用 分位数。

分位数 P · 定义

P50 50% 用户在这个时间内得到响应（=中位数）

P95 95% 用户在这个时间内得到响应

P99 99% 用户在这个时间内得到响应（关键指标）

P99.9 99.9% 用户在这个时间内得到响应（极致）

📌 千图业务底线：首页 P99 < 500ms。搜图 P99 < 800ms。AI 生图 P99 < 15s。低于这条线你就该开"性能复盘会"。

M6 · 大促预案70 / 120

大促预案 · 缓存 + 限流 + 熔断 + 降级

双 11 流量翻 50 倍，
这四件套护千图周全。

① 缓存

扛住读流量

热门内容提前预热到 Redis / CDN，95%+ 请求不打数据库。

→ 千图首页 90% 走缓存

② 限流

守住承载力

单用户 100 QPS / IP 1000 QPS / 总入口 10 万 QPS。超过的直接拒绝。

→ 429 Too Many Requests

③ 熔断

隔离故障

A 服务挂了别人就别再调它了。等 30 秒后再试探一次。

→ 类比"跳闸保险丝"

④ 降级

保核心舍周边

推荐挂了就显示热门榜；动效慢了就关闭；评论加载失败就静默。

→ "壮士断腕"

CEO 必备 3 问 ① 我们核心服务的限流阈值是多少？② 降级开关谁能按？③ 上次大促真的演练过这四件套吗？

M6 · 稳定性71 / 120

稳定性 · "几个 9" 是什么意思

"四个 9" = 99.99%。
看着很高，一年还能挂 52 分钟。

可用性

一年停机

一月停机

业务类比

99%（两个 9）

3.65 天

7.2 小时

个人博客可接受

99.9%（三个 9）

8.7 小时

43 分钟

普通 SaaS / 工具类

99.99%（四个 9）

52 分钟

4.3 分钟

商业核心服务（千图主战场）

99.999%（五个 9）

5.26 分钟

26 秒

银行 / 电信级

📌 业界规律：每多一个 9，成本 ×10。99% 可能一台服务器，99.99% 需要多机房 + SRE 团队 + 监控告警全套。不要盲目追求 5 个 9。

M6 · 安全性72 / 120

安全 · 千图最该防的 5 种攻击

OWASP Top 10 太长。
千图最常遇的就这 5 种。

① SQL 注入

原理：用户在登录框输入 ' OR 1=1 --，被拼到 SQL 里，绕过验证。

防御：参数化查询 / ORM 框架，永远不拼字符串。

② XSS 跨站脚本

原理：用户在评论里塞 <script>偷 cookie</script>，其他人查看时被执行。

防御：所有用户输入转义后才输出。

③ CSRF 跨站请求伪造

原理：钓鱼网站借用你的登录态自动调千图接口（如转账）。

防御：CSRF token / SameSite cookie。

④ 越权访问

原理：URL 里 user_id=123 改成 user_id=456，看到别人的订单。

防御：每个接口校验"当前登录人能否操作这条数据"。

⑤ 接口被刷 · 爬虫 / 薅羊毛

原理：黑产用脚本批量调千图免费 API（如生图试用），1 天烧光 GPU 预算。

防御：限流 + 验证码 + 风控（IP/设备指纹/行为分析） + 鉴权 + 业务规则审计。

M6 · 安全性73 / 120

实战 · 千图最常被薅羊毛的接口

下面这 4 种攻击，每周都在发生。
研发说"风控规则该升级了"，他在说这些。

攻击 1 · 免费 AI 生图被刷

黑产注册 1 万个小号 → 每个号薅 5 张免费生图 → 卖到淘宝 0.5 元一张。

千图防御：设备指纹去重 + 手机号实名 + 行为评分（连续请求 5 张 = 异常）

攻击 2 · 图片爬虫

竞品脚本扫千图 5000 万张图，下载后倒卖。

千图防御：水印 + 加密 URL + 单 IP 限速 + 用户行为反爬模型

攻击 3 · 优惠券薅羊毛

薅羊毛群组织 1000 人同时领"新用户 9.9 元会员"。

千图防御：实名 + 设备 + IP 三段验证 + 群体行为识别

攻击 4 · 撞库 / 弱密码

黑客拿其他网站泄露的用户名密码组合，尝试登录千图。

千图防御：登录频率限制 + 异常 IP 二次验证 + 弱密码拦截

📌 CEO 该问："我们的风控决策引擎规则有多少条？谁能加规则？规则上线后会有误杀报告吗？"

M6 · 可观测性74 / 120

可观测性 · 看着监控才安心

一个合格的研发仪表盘，CEO 也该会看。

📊 千图主站 · 实时监控 2026-05-17 · 23:45 · 实时刷新

QPS

12.4k

↑ 3.2% (1h)

P50

85ms

↓ 2ms

P95

240ms

→ 持平

P99

485ms

↑ 12ms ⚠

错误率

0.05%

SLO 内

可用性

99.96%

达标

QPS 趋势 · 24h

错误率 · 24h

看懂监控的 3 招 ① 看趋势，不看绝对值。② P 值异常比"错误率上升" 更早预警。③ 错误率突增 = 紧急，立刻联系 SRE。

M6 · 第 06 册75 / 120

动手实验 · LAB 06

让千图研发把你拉进 Grafana 看板，亲自看一次。

操作（30 分钟）

找 SRE / 后端 VP：要 Grafana 只读访问
看千图核心服务（首页 / 订单 / 搜图）
找出"P99 在过去 7 天里最高峰"
问那次是什么原因？怎么恢复的？
看告警规则：哪些指标超过线会告警？

CEO 该问的 5 个问题

我们的 SLO 是多少？
当前 SLO 达标率？
告警频率 / 误报率？
P99 历史最差是哪个时间点？
最常 P0 故障的服务是哪个？

完成标准

你能在看板上 独立指认：

QPS / P99 / 错误率三个面板
"哪条线是健康的，哪条线异常"
看出"异常" 和"趋势" 的区别
读懂告警规则的阈值

挑战进阶：登录 Grafana，自己创建一个简单看板，加一个 QPS 面板。

M6 · 第 06 册76 / 120

小考 · 第 06 册

5 题选择 + 1 题运营判断。

Q1. P99 = 500ms 的真实意思：

Q2. 99.99% 可用性 = 一年最多停机：

Q3. 双 11 流量翻 50 倍，最先该做：

Q4. SQL 注入的根因：

Q5. 熔断的本质：

Q6 · 运营判断题：千图早晨 9:00 钉钉炸了——"AI 生图错误率 8%"。说出 5 个你立刻会问研发的问题。

M7 · 第 07 册77 / 120

第 07 册 · 进阶篇

语言与代码
阅读法

为什么有 Java / Go / Python / JS 这么多语言？怎么不学语言就能读懂代码？这一册教你"看代码的方法论"——不为写代码，只为读懂研发提交的 PR 和千图 GitHub 仓库。

核心问题为什么有这么多语言？怎么挑？

学习目标五语言速读 + 三招代码阅读

实验用 Claude Code 读千图真实代码

小考5 选 + 1 阅读题（读懂一段代码）

M7 · 第 07 册78 / 120

语言分类 · 4 张地图分清"哪种"

语言不是"好坏"，是"擅长什么"。
这 4 个维度看一眼就明白。

维度 ① · 类型系统

强类型 + 静态：Java / Go / Rust / TypeScript（编译期就抓错）

弱类型 + 动态：Python / JavaScript / PHP（运行期才抓错）

→ 大项目用强类型，小脚本用动态

维度 ② · 执行方式

编译型：Java / Go / Rust / C++（先编译再运行，快）

解释型：Python / JS / Ruby（边读边跑，慢但灵活）

→ 性能敏感用编译型

维度 ③ · 并发模型

线程：Java（重，但成熟）

协程 / Goroutine：Go（轻，原生并发）

事件循环：JS / Node（单线程异步）

GIL 限制：Python（真并发难，单核）

维度 ④ · 生态 / 应用领域

Java：金融 / 大企业后端 / Android

Go：云原生 / 网关 / 高并发服务

Python：AI / 数据 / 脚本 / 爬虫

JS/TS：前端 / 全栈 / Node 服务

M7 · 第 07 册79 / 120

五语言速读 · 同一个功能在五种语言里长什么样

"查询用户列表，过滤付费用户" —— 5 种语言写法对照。

Java（千图主力）

public List<User> getPremium() {
  return users.stream()
    .filter(u -> u.plan.equals("premium"))
    .collect(Collectors.toList());
}

Go（千图网关）

func getPremium(users []User) []User {
  var result []User
  for _, u := range users {
    if u.Plan == "premium" {
      result = append(result, u)
    }
  }
  return result
}

Python（千图 AI）

def get_premium(users):
    return [u for u in users
            if u.plan == "premium"]

# 一行就够了

TypeScript（千图前端）

function getPremium(users: User[]): User[] {
  return users.filter(
    u => u.plan === "premium"
  );
}

SQL（数据层）

SELECT * FROM users WHERE plan = 'premium';

📌 共同点：5 种语言都在做"遍历 + 过滤"。看代码不用懂语言细节，找动词和名词就够了。

M7 · 第 07 册80 / 120

代码阅读法 · 三招走天下

不会写代码，也能读代码。
关键是知道从哪儿开始读。

招 ① · 先看入口

main / app.js

每个程序都有"启动入口"。前端找 index.html / main.tsx；后端找 main.java / app.py / server.go。

// 入口在告诉你：
// 1. 启动了什么服务
// 2. 监听哪个端口
// 3. 加载了哪些中间件

招 ② · 先看接口

routes / controllers

找"API 路由表"。看 @GetMapping / app.get('/...')，立刻知道这个项目对外提供哪些能力。

@GetMapping("/api/users")
@PostMapping("/api/auth/login")
@PutMapping("/api/order/{id}")
// 立刻能拼出业务全貌

招 ③ · 先看测试

tests / specs

测试代码 = "这段代码该怎么用" 的实例文档。比注释还可靠。

it("premium user can upload 50 images", () => {
  ...
});
// 一句话告诉你业务规则

📌 三招实战流程：① 看 README → ② 看入口文件 → ③ 看路由表 → ④ 找最关心的接口 → ⑤ 看对应测试 → ⑥ 跳进实现细节。15 分钟看懂一个新项目大致全貌。

M7 · 第 07 册81 / 120

Java 速识 · 千图后端主力

Java 长这样。
看 6 个关键词就够了。

// 千图会员服务（Spring Boot）
@Service
public class MembershipService {

  @Autowired
  private UserDao userDao;

  @Transactional
  public User upgrade(Long userId, String plan) {
    User user = userDao.findById(userId);

    if (user == null) {
      throw new BusinessException("用户不存在");
    }

    user.setPlan(plan);
    user.setUpdatedAt(new Date());

    return userDao.save(user);
  }
}

Java 6 个看就懂的关键词

class：定义一个"类"（蓝图）
public/private：可见性（外部能调吗）
@Service / @Controller：标记这个类是干嘛的（Spring 注解）
@Autowired：自动注入依赖
@Transactional：这个方法是事务
return / throw：返回值 / 抛异常

千图惯例：Service 写业务、Dao 写 DB 操作、Controller 接 HTTP。三层架构。

M7 · 第 07 册82 / 120

Python 速识 · 千图 AI 业务核心

Python 比 Java 短一半。
AI 业务标配。

# 千图 AI 生图服务（FastAPI）
from fastapi import FastAPI
from diffusers import StableDiffusionPipeline

app = FastAPI()
pipe = StableDiffusionPipeline.from_pretrained(
    "stabilityai/sdxl"
)

@app.post("/api/generate")
async def generate(prompt: str, user_id: int):
    # 1. 扣 Token
    if not await deduct_token(user_id, 50):
        raise HTTPException(402, "积分不足")

    # 2. 调模型
    image = pipe(prompt).images[0]

    # 3. 上传 OSS
    url = await upload_to_oss(image)

    return { "url": url }

Python 看就懂的特征

def / async def：定义函数
@app.post：装饰器（标记接口路径）
缩进表示代码块（不是花括号）
prompt: str：类型注解
# 开头：注释

千图惯例：AI 业务用 FastAPI + PyTorch；数据管道用 Pandas + Airflow；爬虫用 Scrapy。

M7 · 第 07 册83 / 120

JS / TS 速识 · 千图前端宇宙

JavaScript 是浏览器原生。
TypeScript 给 JS 加了类型，是千图前端主力。

// 千图首页热门图组件（React + TypeScript）
import { useState, useEffect } from 'react';

interface Asset {
  id: number;
  url: string;
  title: string;
}

export function HotAssets() {
  const [items, setItems] = useState<Asset[]>([]);

  useEffect(() => {
    fetch('/api/hot')
      .then(r => r.json())
      .then(setItems);
  }, []);

  return (
    <div className="grid">
      {items.map(it =>
        <img key={it.id} src={it.url} />
      )}
    </div>
  );
}

React + TS 三大特征

interface：定义数据形状（TS 特性）
useState / useEffect：React Hooks
JSX 语法：HTML 混在 JS 里
箭头函数：() => ...

千图惯例：网站用 Next.js + React + TS；移动 App 用 React Native；Node 后端用 NestJS。

M7 · 第 07 册84 / 120

Go + SQL · 高并发服务 + 数据查询

Go 短小快速，写网关。
SQL 不是编程语言，是查数据的标准。

Go · 千图网关代码片段

// 千图 API 网关 (Gin 框架)
package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()

    r.GET("/health", func(c *gin.Context) {
        c.JSON(200, gin.H{"status": "ok"})
    })

    r.POST("/api/route", authMiddleware, handleRoute)

    r.Run(":8080")
}

// goroutine 并发：
go processInBackground(task)

关键词：func / package / go (协程) / chan (通道)

SQL · 不会写也要会读 10 句

-- 查询
SELECT name, plan FROM users WHERE id = 123;

-- 聚合统计
SELECT plan, COUNT(*) FROM users GROUP BY plan;

-- 跨表查询
SELECT u.name, SUM(o.amount)
FROM users u
JOIN orders o ON u.id = o.user_id
GROUP BY u.id;

-- 增/改
INSERT INTO users (...) VALUES (...);
UPDATE users SET plan = 'premium' WHERE id = 123;

看到这些动词：SELECT / INSERT / UPDATE / DELETE / JOIN / GROUP BY 就够用了。

M7 · 第 07 册85 / 120

动手实验 · LAB 07 · 最重要的一次

让 Claude Code 帮你读千图真实代码。
这次是进千图代码库的开端。

操作（1 小时）

跟 CTO 要千图某个小项目仓库的读权限（如内部 admin / Skill）
git clone 到本地
用 Claude Code 打开项目目录
问："这个项目是干什么的？解释项目结构。"
找一个接口，问："这个接口的完整流程是什么？"
挑战：让 Claude Code 改一行 CSS / 加一条日志

完成标准

能 5 分钟说清项目主要功能
能看懂3 个接口的实现
能改一行 + git diff 看变化

Terminal · Claude Code 实战示例

$ cd ~/projects/qiantu-admin $ claude Claude Code 已就绪，可以帮你做什么？ > 解释一下这个项目，最多 5 句话这是千图内部 admin 后台... 主要技术栈：Next.js + TS + Prisma + PostgreSQL 7 个核心模块：用户管理 / 订单 / 内容审核 ... > src/pages/orders/[id].tsx 这个页面在做什么？订单详情页，含 6 个区块：基本信息、商品... > 帮我把订单状态的徽章颜色改成蓝色已修改 components/StatusBadge.tsx 第 23 行 ✓ Done. Run npm run dev to preview.

M7 · 第 07 册86 / 120

小考 · 第 07 册

5 题选择 + 1 题代码阅读。

Q1. TypeScript 相比 JavaScript 主要加了：

Q2. Python 在千图主要用于：

Q3. 阅读一个新项目，最先该看：

Q4. Java 里 @Service / @Controller 的作用：

Q5. SQL "JOIN" 的目的：

Q6 · 代码阅读题：用大白话说出这段代码在做什么。

async function checkAndUpgrade(userId) {
  const user = await db.users.findOne({ id: userId });
  if (!user) throw new Error('用户不存在');
  if (user.points < 10000) return { ok: false, msg: '积分不足' };
  await db.users.update({ id: userId }, {
    plan: 'premium',
    points: user.points - 10000
  });
  return { ok: true };
}

M8 · 第 08 册87 / 120

第 08 册 · 进阶篇 · 收官之册

AI 时代研发
新世界

AI 项目和传统项目 不一样——Token 不是免费的，GPU 是稀缺资源，Prompt 是新接口。这一册让你看懂千图 AI 业务的全部技术栈，并自己用 AI 工具改千图前端代码。

核心问题AI 项目的工程化逻辑和传统的区别？

学习目标看懂 RAG / Agent / Token / GPU 全链路

实验用 Claude Code 改一个千图前端组件

小考5 选 + 1 设计题（AI 系统架构）

M8 · 第 08 册88 / 120

第一性原理 · AI 项目和传统项目的 5 大不同

"AI 项目就是普通项目加 API 调用"——
这是最危险的误解。

维度

传统项目

AI 项目

① 计费单位

请求数 / 服务器

Token / GPU 时 算到分

② 响应特性

同步 50-200ms

流式输出 / 数秒

③ 结果确定性

同样输入 = 同样输出

每次输出不一样（temperature）

④ 错误形态

明确 500 / 400

幻觉 / 越权 / 内容违规

⑤ 测试方法

断言式单测

评测集 + 人工抽审

📌 CEO 该认知："AI 项目和普通项目的财务模型完全不一样。普通项目固定成本，AI 项目边际成本随用户量直线上升。"

M8 · 第 08 册89 / 120

Prompt 全链路 · Input → Token → Model → Output

"用户输入一句话"到"AI 输出回复"，
这 7 步发生了什么。

Token 是计费单位
中文 ≈ 1.5 字 / token，英文 ≈ 0.75 词 / token

Context Window 上限
Claude Opus 4.6 = 200k token = ~30 万中文字

流式输出
不等全部生成就一边发一边显示

M8 · 第 08 册90 / 120

RAG · Retrieval-Augmented Generation · "带知识库的 LLM"

让 LLM 查千图自己的资料再回答。
客服 / 智能搜图 / 助手都靠这个。

📌 千图典型应用：客服机器人（喂 FAQ 文档）、智能搜索（喂产品标签）、Skill 知识库（喂内部最佳实践）。

M8 · 第 08 册91 / 120

Agent 工作流 · 千图飞书 Skill 实际跑了什么

你日常用的飞书 lark-cli Skill，
背后是多步 Agent 编排。

案例 · 你说："帮我规划下月的设计主题"

Step 1 Claude 理解意图：识别为"主题规划"任务 → 触发 qt-tools:需求规划 skill

Step 2 Tool Use #1：调 lark-base 工具 → 读"AI 版场景全案规划表"历史数据

Step 3 Tool Use #2：调 WebSearch → 抓近期行业热点、节日、IP 联名

Step 4 Claude 推理：对比历史 + 热点 → 生成 20 个主题候选

Step 5 Tool Use #3：调 lark-base 写入"AI 版场景全案规划表" + 飞书消息推送给你

Step 6 反思 + 调整：若你回复 "不满意，多加节日主题"，回到 Step 4 重跑

📌 Agent 本质：LLM = 大脑（推理）；Tools = 手脚（调 API）；Memory = 记忆（保留上下文）。千图 Skill 就是 Agent 的封装。

M8 · 第 08 册92 / 120

Tool Use + MCP · LLM 如何"用工具"

LLM 自己没"手"。
给它工具，它就能调 API / 读文件 / 发飞书。

Tool Use 工作流

研发给 LLM 一份"工具列表"（函数签名）
LLM 看到问题，自己判断"该调哪个工具"
LLM 输出"调用指令" + 参数
研发的代码实际执行工具
结果回传给 LLM，LLM 继续推理或返回答案

// 工具定义（JSON Schema 给 LLM 看）
{
  "name": "search_qiantu_assets",
  "description": "在千图素材库搜素材",
  "parameters": {
    "keyword": "string",
    "limit": "number"
  }
}

// LLM 输出调用指令
{
  "tool": "search_qiantu_assets",
  "args": {
    "keyword": "猫",
    "limit": 10
  }
}

// 代码执行后回传
{ "results": [{ "id": 123, ... }] }

📌 MCP (Model Context Protocol)：Anthropic 提出的"给 AI 接工具的通用协议"，让任何 MCP 兼容的 AI 都能调你的工具。千图的 lark-cli, 58pic-cli, qiantu-bi 全是 MCP server。

M8 · 第 08 册93 / 120

Token 经济学 · AI 项目财务模型

每个 Token 真的要花钱。
不算清楚 Token 模型，AI 业务亏到看不见。

主流模型 Token 价格对照（2026 估算 · 仅供参考）

模型

Input 价格 / 1k

Output 价格 / 1k

使用场景

Claude Opus 4.6

$15

$75

复杂推理、Code

Claude Sonnet 4.6

$3

$15

主力工作流

Claude Haiku 4.5

$0.8

$4

大规模、低延迟

GPT-4o

$5

$15

多模态

本地开源 Llama

~$0.5

隐私敏感、内部

📌 千图算账：1 个用户问 1 次复杂问题 ≈ 4k tokens（in 2k + out 2k）。用 Sonnet ≈ $0.036 / 次。100 万用户 / 月每人问 10 次 = $360,000 / 月。必须算清楚！

M8 · 第 08 册94 / 120

AI 成本三角 · Token / GPU / 并发

AI 项目三个钱袋子同时往外流。
哪个最贵？取决于业务模式。

省 Token
缩短 Prompt / 缓存 / 用更便宜模型 / 流式输出（用户提前看到，可中断）

省 GPU
用 LoRA 微调小模型 / 量化（FP8 / INT4） / Spot 实例 / Serverless

省并发
队列 + 优先级 / 业务降级（免费用户排队，付费插队） / 错峰调度

M8 · 第 08 册95 / 120

AI 时代研发新角色

"AI 工程师"不是一个岗位。
千图招聘的时候要分清这 4 类人。

AI Engineer

业务 + AI

把 AI 能力嵌入产品。RAG / Agent / Tool Use 都用熟。千图最需要的人。

→ Python + LangChain

ML Engineer

训练 + 部署

微调模型、训练自己的模型、部署推理服务。需要懂 GPU / CUDA。

→ PyTorch + Triton

Prompt Engineer

提示词 + 评测

不写代码，但负责"把模型调出来好用"。千图的 Skill 作者就是 Prompt Engineer。

→ Markdown + 评测集

Data Engineer

数据 + 管道

建训练 / 评测数据集，搭数据管道，做标注质量管理。

→ Airflow + Pandas

📌 CEO 招人逻辑：1 个 AI Engineer + 1 个 ML Engineer + 1 个 Prompt Engineer + 1 个 Data Engineer = 完整的 AI 团队（4 人组）。千图业务规模可以 1 → 2 → 4 渐进。

M8 · 第 08 册96 / 120

Vibe Coding · CEO 自己改千图前端的姿势

"用嘴写代码" = Vibe Coding。
你描述你想要的，AI 写代码。

Vibe Coding 的 5 个心法

讲清楚结果，不是讲实现：
"首页搜索框加圆角" 而非 "border-radius 12px"
给 AI 上下文：
"这是 Next.js 项目，搜索框在 components/Search.tsx"
分步骤：
先改样式，跑通；再改逻辑，再跑通
看 diff：
永远 review AI 的修改，不要全盘接受
立刻跑：
改完立刻 npm run dev，眼见为实

Vibe Coding 示例 · 千图前端改首页

你 > 千图首页的"AI 生图"卡片，按钮加阴影 + 悬停放大 Claude 正在分析项目... 找到 src/components/AIGenCard.tsx 即将修改： + box-shadow: 0 4px 12px rgba(0,0,0,0.1) + transition: transform 0.2s + hover:scale-105 你 > 跑起来看看 $ npm run dev ✓ Ready on http://localhost:3000 你 > 阴影太重了，再轻一点 + 圆角再大点已调整为 rgba(0,0,0,0.06) + rounded-2xl 你 > 完美，提交 git ✓ git commit -m "feat: AI gen card hover effect"

M8 · 第 08 册97 / 120

动手实验 · LAB 08 · 最终大考

用 Vibe Coding 实际改千图前端某个组件。
这是结业的"毕业作品"。

操作（90 分钟）

找 CTO / 前端 VP 给你某个仓库的写权限（或新建一个 fork）
挑一个"很小的改动"：调按钮颜色 / 加个埋点 / 改文案
用 Claude Code 完成修改 + 自测
提 Pull Request
让研发 Code Review
合并 → 上线（用千图 CI/CD）

完成标准

你自己提的代码改动，被合并到了千图代码库，并且实际上线了。

🎯 推荐"练手任务"

难度 ★：改一行文案 / 颜色 / 间距
难度 ★★：加一个埋点 (track event)
难度 ★★★：给某个组件加 hover 动效
难度 ★★★★：在 admin 后台加一个筛选条件
难度 ★★★★★：写一个新的小 page（如"给我的"我的收藏页）

从 ★ 开始，每次升一级。第 5 个 ★ 完成时，你已经能跟研发独立讨论实现细节。

M8 · 第 08 册98 / 120

小考 · 第 08 册 · 最后一册

5 题选择 + 1 题方案设计。

Q1. Token 是什么：

Q2. RAG 解决的问题是：

Q3. Agent 的核心组件是：

Q4. MCP 的核心价值：

Q5. 千图 AI 业务的"成本三角"是：

Q6 · 方案题：千图想做"AI 智能客服"，能用千图 FAQ 回答用户。用本课程的概念画出架构（提示：RAG + 向量库 + LLM + 监控/兜底）。

M9 · 黑话词典99 / 120

研发黑话 · PM/运营必读 30 词

研发开会 30 分钟，能讲 50 个英文缩写。
这 30 个最常出现。

QPS
每秒请求

TPS
每秒事务

P99
99% 分位

SLA
服务等级

SLO
服务目标

RTO
恢复时间

幂等
重复不出错

异步
不等结果

同步
等到结果

解耦
A 改不影响 B

缓存
省 DB

索引
查询加速

限流
守住阈值

熔断
隔离故障

降级
保核心

回滚
撤销变更

灰度
小流量验证

蓝绿
双环境切换

CI
持续集成

CD
持续部署

K8s
容器编排

CDN
边缘加速

DNS
域名解析

VPN
私有网络

RAG
检索增强

LLM
大语言模型

Token
AI 单位

Embedding
向量化

MCP
工具协议

Agent
智能体

接下来 5 页，是每组的"研发说的 vs 老板该听到的" 翻译卡。

M9 · 翻译卡 1100 / 120

翻译卡 ① · 同步 / 异步 / 阻塞 / 非阻塞

研发说"这个改成异步的"，
老板该听到："用户不用等结果，可以先干别的"。

研发说 "这个接口要改成同步的"

→

老板该听到 用户必须等服务器拿到完整结果才能继续。慢但简单。

研发说 "扔到消息队列异步处理"

→

老板该听到 先返回"任务已接收"，让用户继续操作；任务实际在后台慢慢跑。

研发说 "这里是阻塞的"

→

老板该听到 这一步执行完之前，整个线程都卡着，不能干别的。

研发说 "用 await，await 等不阻塞"

→

老板该听到 代码等结果时，线程可以去处理别的请求，效率高。

CEO 该问 "如果异步，用户怎么知道做完了？" → 答案是"轮询 / WebSocket / 邮件通知"。异步必须配通知机制。

M9 · 翻译卡 2101 / 120

翻译卡 ② · 耦合 / 解耦 / 模块化

研发说"耦合太重"，
老板该听到："改一个地方会牵连一大片，需要重构"。

研发说 "用户模块和订单模块耦合太严重"

→

老板该听到 改用户表会顺手改坏订单。两块代码缠在一起，分不清谁是谁的。

研发说 "这块要解耦出来"

→

老板该听到 把"抱在一起" 的代码拆分清楚，用接口对接。改 A 不会影响 B。

研发说 "做成可插拔的"

→

老板该听到 这功能是可选模块，需要就装上、不需要就拆掉，不影响主流程。

研发说 "这是上下游强依赖"

→

老板该听到 A 服务一挂，B 服务立刻跟着挂。需要做兜底（默认值 / 降级）。

M9 · 翻译卡 3102 / 120

翻译卡 ③ · 缓存 / DB / CDN / 网关

基础设施 4 件套。

研发说 "缓存击穿了"

→

老板该听到 本来该被 Redis 接住的请求，全打到数据库了，数据库 CPU 飙红。

研发说 "DB 主从延迟很大"

→

老板该听到 主库写入后，从库迟迟没同步过来。用户刚下单查不到，引发客诉。

研发说 "CDN 回源率高"

→

老板该听到 边缘节点没命中缓存，跑回源站取数据。带宽成本上涨。

研发说 "网关 OOM 了"

→

老板该听到 网关内存爆了（Out Of Memory）。整个站可能短时间无法访问。SRE 救火中。

M9 · 翻译卡 4103 / 120

翻译卡 ④ · 限流 / 熔断 / 降级 / 幂等

稳定性 4 件套。

研发说 "开启限流，每秒 1 万 QPS 封顶"

→

老板该听到 超过 1 万 QPS 的请求直接拒绝（返回 429）。保护后端不被压垮。

研发说 "支付服务熔断了"

→

老板该听到 支付服务挂了，其他服务暂停调用它，防止雪崩。等 30 秒后试探。

研发说 "启动了降级方案"

→

老板该听到 推荐算法挂了，临时显示热门榜；评论加载不出来，静默隐藏。保住核心功能。

研发说 "这个接口需要做幂等"

→

老板该听到 用户多次点同一个按钮（或网络重试），最终结果只发生一次。支付、扣款必备。

M9 · 翻译卡 5104 / 120

翻译卡 ⑤ · 部署相关

CI / CD / 灰度 / 回滚 / 蓝绿。

研发说 "CI 挂了"

→

老板该听到 代码合并自动测试失败了，这次提交不能合并到主分支。需要先修。

研发说 "上线灰度 10%"

→

老板该听到 新代码只对 10% 用户生效，观察指标。没问题再扩大。大改动必须灰度。

研发说 "线上有 bug，准备回滚"

→

老板该听到 把代码回退到上一个稳定版本。一般 5 分钟内完成。如果回滚不了，问题大。

研发说 "蓝绿切换中"

→

老板该听到 两套完整环境同时存在（蓝 / 绿），流量在两套之间一次性切换。零停机。

M9 · 黑话词典105 / 120

PM-研发对话翻译器 · 10 句日常黑话

每天会议、钉钉群、需求评审的高频 10 句。

研发说

"我先评一下工作量"

真实含义

"我需要 1-2 天看清需求/影响面再答复"

研发说

"这个不在 MVP 范围"

真实含义

"这条需求会让工期翻倍，能不能砍/延期？"

研发说

"先打个临时方案"

真实含义

"留个技术债，未来 3-6 月内必须重构"

研发说

"这个改动有点大"

真实含义

"会牵连 ≥ 3 个模块，回归测试范围扩大"

研发说

"我们走个评审"

真实含义

"我想让架构师/Tech Lead 把把关，避免坑"

研发说

"上线有窗口期"

真实含义

"凌晨 2-4 点低峰发布，避免影响用户"

研发说

"和上下游打个招呼"

真实含义

"要影响别人，先沟通好，避免甩锅"

研发说

"P0/P1 级别"

真实含义

"P0=全员救火；P1=4 小时内解；P2=工作日内解"

研发说

"先压个测"

真实含义

"模拟高并发场景，看会不会挂"

研发说

"这是个边界 case"

真实含义

"罕见但理论上会发生的场景，要么修要么记 TODO"

M9 · 黑话词典106 / 120

CEO 实用 · 砍工期的 5 个魔法问题

研发说"这功能要做 4 周"。
问这 5 个问题，真实工期常常砍半。

Q1

"这 4 周里，哪一步占最多时间？"

→ 找瓶颈。常常是某个老接口要改 / 某个外部依赖要协调。砍掉非关键路径。

Q2

"哪部分功能砍掉，剩下的能 1 周做完吗？"

→ 逼出 MVP。让研发自己说"最小可发布版本"是什么。

Q3

"这部分能不能用现成的库 / 服务？"

→ 80% 时间被"重造轮子"消耗。用现成的开源库 / SaaS 服务。

Q4

"哪些是核心，哪些是 nice-to-have？"

→ 区分必要 vs 锦上添花。研发倾向"把nice-to-have" 当必要。

Q5

"用 AI 写代码能省多少时间？"

→ 2026 年这个问题非问不可。简单 CRUD / 组件 / 文案用 AI 能砍 40-60% 时间。

M9 · 听力训练107 / 120

听力训练 · 千图研发周会片段

读这段对话，每个黑话你都听得懂吗？

CTO："昨晚 P99 在 11 点抖了一下，飙到 800ms，错误率 0.3%。SRE 排查后发现是订单服务的某个慢 SQL没走索引，主库 CPU 飚到 95%。临时限流 + 降级，半小时恢复。"

后端 Lead："我们这个 SQL 加了 EXPLAIN 看了下，type=ALL 全表扫。已经加了联合索引，灰度 30% 验证中。明天蓝绿全量。"

CTO："这次故障升 P1 复盘。我担心主从延迟变大，缓存击穿风险也要看下。SLO 这个月 99.95%，budget 还剩多少？"

SRE："error budget 已经烧掉 60%。下周不允许大改动。"

AI 团队："我们昨天上线了新的 RAG Agent，Token 消耗翻倍，单次调用 4k tokens。已经在加缓存 + 切到 Haiku 做降级。"

✓ 标记的下划线词都是本课程教过的。如果有3 个以上不懂，回去重读对应模块。

M9 · 技术栈108 / 120

千图技术栈推测 · 五层全景

这张表你可以直接打印贴墙上，
跟研发对话时随时查。

层

技术

业务用途

替代选项

前端

Next.js + React + TS

主站 / 设计器

Nuxt / Vue / Remix

移动

React Native / Flutter

iOS / Android App

Native (Swift/Kotlin)

后端核心

Java + Spring Boot

订单 / 用户 / 支付

Go / Node.js / Kotlin

后端高并发

Go + Gin

网关 / 推送 / 实时

Rust / Erlang

AI / 算法

Python + FastAPI + PyTorch

搜图 / 生图 / Agent

JAX / TensorFlow

数据库

MySQL / PostgreSQL

用户 / 订单 / 内容

TiDB / OceanBase

缓存

Redis

会话 / 热点数据

Memcached

搜索

Elasticsearch

关键词搜图

OpenSearch / Meilisearch

向量库

Milvus / Qdrant

以图搜图 / RAG

Pinecone (SaaS)

对象存储

阿里云 OSS

图片 / 视频

AWS S3 / 腾讯 COS

基础设施

阿里云 + K8s + Docker

部署 / 弹性 / 容器化

华为云 / AWS / GCP

⚠️ 以上为基于行业惯例 + 业务规模的推测性栈，请向千图技术 VP 核实修正

M9 · 工具箱109 / 120

学习工具箱 · 9 大利器

8 周里你会反复用到的9 个工具。
建议都装上、都试用一次。

① Claude Code

AI 编程主力

读代码、改代码、提 PR。Wayne 本课程的核心工具。

使用频度 ★★★★★

② Cursor

AI IDE 编辑器

桌面 IDE，AI 内嵌。比 VS Code 体验更顺。

使用频度 ★★★★

③ Chrome DevTools

浏览器神器

看请求、改样式、抓性能。F12 就是 CEO 的显微镜。

使用频度 ★★★★★

④ GitHub Desktop

代码协作 GUI

不会命令行也能 clone / commit / push。

使用频度 ★★★

⑤ Postman

API 测试

手动调千图后端接口，看真实返回，做调试。

使用频度 ★★★

⑥ Excalidraw

架构图手画风

画系统架构图最顺手。研发也爱用。

使用频度 ★★★

⑦ DBeaver

数据库 GUI

连千图 DB 看表结构、跑 SELECT 看数据。

使用频度 ★★

⑧ Grafana

监控看板

看千图各服务的 QPS、延迟、错误率。

使用频度 ★★★★

⑨ Notion / 飞书

笔记 + 沉淀

学完每册写笔记 + 整理 ADR。归档到 Wayne 研究室知识库。

使用频度 ★★★★★

M9 · 风险110 / 120

风险与退路 · 学不下去时怎么办

不是每个人都能 6 周学完。
3 条退路给你兜底。

退路 1 · 节奏放缓

从 6 周变 12 周

每周只学半册。一年内学完。没有任何耻辱，CEO 时间本来就紧。

→ 周日下午 1 小时

退路 2 · 只学前 5 册

CEO 60% 解决方案

前 5 册（基础+数据+架构+千图实战）覆盖你 80% 的研发对话。剩下 3 册按需补。

→ 4 周可成

退路 3 · 找研发陪读

1 对 1 答疑

挑一位你信任的研发同事，每周喝个咖啡聊 30 分钟。你提问，他回答。速度 ×3。

→ 每周 30 min

📌 心态建议：不要追求"完全懂"，追求"知道在哪里找答案"。能识别"这是哪个领域的问题"已经胜过 80% 的非技术 CEO。

M10 · 综合大考111 / 120

📋 课程综合大考 · 30 选择 + 1 终考

综合大考

完成 8 册学习后，用这套综合考试检验你是否真的从"看不懂"跨到"能讨论"。

第 1 组

基础

5 题 / 岗位+请求

第 2 组

架构

5 题 / DB+选型

第 3 组

千图业务

5 题 / 登录+支付

第 4 组

AI 时代

5 题 / RAG+Token

第 5 组

黑话翻译

5 题 / 翻译卡

⏱ 考试规则：限时 30 分钟（每题 1 分钟）。通过线 80 分（24/30 题）。终考是阅读一段千图真实代码并复述其逻辑。

M10 · 大考 · 第 1 组112 / 120

综合大考 · 第 1 组 · 基础 5 题

岗位 + 请求旅程。

Q1. SRE 主要工作是：

Q2. DNS 的作用：

Q3. CDN 主要价值：

Q4. 网关 vs 负载均衡：

Q5. 用户首页加载慢，最该先检查：

M10 · 大考 · 第 2 组113 / 120

综合大考 · 第 2 组 · 架构 5 题

数据库 + 架构选型。

Q6. 索引的代价：

Q7. 千图付款扣钱写表用：

Q8. "以图搜图" 该用：

Q9. 5 人 MVP 团队最佳架构：

Q10. 微服务最大代价：

M10 · 大考 · 第 3 组114 / 120

综合大考 · 第 3 组 · 千图业务 5 题

登录 + 支付 + 搜图。

Q11. 用户密码该如何存：

Q12. 微信登录中千图能否拿到用户的微信密码：

Q13. 支付回调必须做"幂等"，原因：

Q14. 千图搜图的"两阶段"：

Q15. 千图大促前最该做：

M10 · 大考 · 第 4 组115 / 120

综合大考 · 第 4 组 · AI 时代 5 题

RAG / Token / Agent。

Q16. Token 的含义：

Q17. RAG 解决：

Q18. Agent 三件套：

Q19. AI 项目成本三角：

Q20. MCP 是：

M10 · 大考 · 第 5 组116 / 120

综合大考 · 第 5 组 · 黑话翻译 5 题

研发说的话，你能翻译吗？

Q21. "P99 跌到 800ms" 意思：

Q22. "缓存击穿" 意思：

Q23. "灰度 10%" 意思：

Q24. "服务熔断" 意思：

Q25. "error budget 烧掉 60%" 意思：

M10 · 终考117 / 120

🎯 终极考试 · 阅读千图真实代码

下面是一段仿千图真实代码片段。
请用大白话讲出它在做什么 + 哪里可能出问题。

// 千图 · AI 生图任务处理
@Service
public class AIGenService {

  @Autowired RedisClient redis;
  @Autowired GPUWorkerClient gpu;
  @Autowired OssClient oss;
  @Autowired UserTokenService tokenSvc;

  public Result generate(Long userId, String prompt) {
    // ① 检查 Token
    if (!tokenSvc.deduct(userId, 50)) {
      return Result.error("积分不足");
    }

    // ② 缓存检查（同 prompt 复用）
    String cached = redis.get("img:" + prompt.hashCode());
    if (cached != null) return Result.ok(cached);

    // ③ 提交 GPU 任务
    String taskId = gpu.submit(prompt);

    // ④ 轮询结果（最多 30 秒）
    for (int i = 0; i < 60; i++) {
      String url = gpu.poll(taskId);
      if (url != null) {
        redis.setex("img:" + prompt.hashCode(), 3600, url);
        return Result.ok(url);
      }
      Thread.sleep(500);
    }
    return Result.error("超时");
  }
}

答题：解释逻辑（必答）

挑战：找出 3 个潜在问题

✓ 通过标准：① 能写出主流程；② 至少找出 1 个潜在问题；③ 用大白话讲，不需懂语法细节。

M10 · 结业118 / 120

🏁 结业 · 你是否真的"过关"

不是看分数，是看这 3 件事你能做吗？

01

能读懂代码

能 clone 千图任意一个项目 → 用 Claude Code 解释主流程 → 5 分钟说清这个项目在做什么。

02

能参与设计

在架构评审会上，能提出 ≥ 2 个有质量的问题（不是"性能怎么样"，而是"P99 在 80% 流量下能撑多少"）。

03

能改代码上线

用 Vibe Coding，自己改千图前端某组件并合并 PR 上线。这是从"讨论"到"实操" 的分水岭。

三关都过 = 你已不可能被研发"忽悠"
这是中国 CEO 的 5% 之列 ✦

M10 · 启动119 / 120

✍ 学习契约 · 签字盖章

读完这本导览册，
你已经做出了开始的决定。