00. 序言:算法工程师的架构师之路
读完这篇你能:
- 在脑子里建立一张"分层架构心智地图",遇到任何技术名词都能定位它属于哪一层、解决什么问题
- 知道这 10 篇文章每一篇点亮地图的哪一格、什么顺序读
- 制定自己的 90 天学习计划
前置知识:会写 Python、调过 LLM API、跑过 Jupyter notebook
预计用时:45 分钟阅读(不含后续动手)
0. 这个系列解决什么问题
你已经能做这件事:
# 在 Jupyter notebook 里
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4-turbo",
messages=[{"role": "user", "content": "总结一下..."}]
)
print(response.choices[0].message.content)
这是脚本,不是产品。
当你的老板说"这个不错,给公司内部 100 个人用",你面临的问题:
| 问题 | 你现在的状态 | 需要学什么 |
|---|---|---|
| 100 个人同时调,怎么不挂? | 单机脚本扛不住 | Web 服务、并发、异步 |
| 用户数据存哪里? | 内存里,关机就没 | 数据库、持久化 |
| 怎么让访问变快? | 每次都重新算 | 缓存、CDN |
| 谁能看什么数据? | 没考虑过 | 认证、权限 |
| 代码怎么上线? | 在我笔记本上 | Docker、CI/CD、部署 |
| 出错了怎么发现? | 用户来告诉我 | 可观测性、监控 |
| 用的人多了怎么办? | 不知道 | 负载均衡、扩展 |
| LLM 偶尔瞎说怎么办? | 没办法 | Guardrails、人审 |
| 成本怎么控制? | OpenAI 直接扣我卡 | Token 经济、成本治理 |
这 9 个问题,就是本系列 9 篇实战教程(加本篇共 10 篇)要解决的。
但开始一个个学之前,先在脑子里画一张架构地图。否则你学了一堆名词,遇到新问题还是不知道该抓哪个。
1. 为什么算法工程师必须学前端后端
你可能觉得:"我是做算法的,这些让后端工程师做不就行了?"
在 LLM 时代,这个想法是错的。三个原因:
原因 1:LLM 应用是"算法 + 工程"的深度耦合
传统软件里,算法和工程是分开的——算法团队训模型出 API,工程团队调 API 做产品。
LLM 应用不是这样。你的 prompt 影响响应时间(影响架构)、影响成本(影响运维)、影响准确率(影响护栏设计)。这些决策不能甩给后端工程师做,因为他们不懂 LLM。
你必须是那个既懂算法又懂工程的人,否则你做的 Demo 永远停在 Demo。
原因 2:Vibe Coding 让"一个人做完整产品"成为可能
Cursor、Claude Code、Windsurf 这些工具,让算法工程师能独立写前后端代码。但工具能帮你写代码,不能帮你做架构决策。
你必须知道:
- 为什么用 Postgres 不用 MongoDB?
- 为什么要加 Redis 缓存?
- 为什么要用 Docker?
- 为什么 LLM 调用要异步?
- 什么时候要上 K8s,什么时候 Cloud Run 就够?
这些"为什么"是架构师的认知,工具替不了。
原因 3:市场需求在变
2026 年的招聘市场:
- 纯算法岗位在缩(模型供应商越来越强,自研需求减少)
- "AI 应用工程师"岗位在涨(需要把 LLM 做成产品的人)
- 这类岗位要求既懂 LLM 又懂全栈
会算法 + 会工程的人,薪资比只会算法的高 30-50%。
2. 分层架构心智模型(必须先建立这张地图)
学具体技术之前,先在脑子里画一张"架构分层图"。这张图是你所有技术决策的锚点——遇到新名词,先问"它属于哪一层、解决哪一层的问题",这样就不会被五花八门的技术栈淹没。
一个能扛百万日活的 LLM 应用,从上到下可以拆成 6 层。每一层解决一个明确的问题,层与层之间通过标准协议通信。
┌─────────────────────────────────────┐
用户 ─────────▶ │ 1. 接入层 │ DNS、CDN、负载均衡、HTTPS、VPC、WAF
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 2. 应用层 │ FastAPI、gRPC、JWT、RBAC、流式、护栏
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 3. 数据层 │ Postgres、Redis、ES、S3、向量库
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 4. 协调层 │ ZooKeeper、Nacos、Kafka、分布式锁
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 5. 部署层 │ Docker、K8s、CI/CD、Terraform、Helm
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 6. 可观测层 │ Prometheus、Grafana、ELK、OpenTelemetry
└─────────────────────────────────────┘
心智模型的使用方式:
- 遇到新名词先归类:看到 "Kafka" → 它在协调层,解决"异步解耦"问题
- 遇到问题先定位层:"接口慢" → 先看是接入层(网络)、应用层(代码)、还是数据层(查询)
- 做技术选型先看层:同层的技术往往可以互换(Postgres ↔ MySQL、Redis ↔ Memcached),不同层不能互换
- 读别人架构按层拆:任何复杂系统都能往这 6 层上套,瞬间看清骨架
第 1 层:接入层——用户怎么找到你、请求怎么进来
这层解决的问题:全球任意地点的用户,怎么把请求送到你的服务器,又快又稳。
| 技术 | 解决什么问题 | 什么时候用 | 本系列哪儿讲 |
|---|---|---|---|
| DNS(Route53、阿里云 DNS) | 域名 → IP 的翻译 | 有域名就要配 | 不展开,假设你会 |
| CDN(Cloudflare、阿里云 CDN) | 就近返回静态资源,加速用户访问 | 有静态资源(JS/CSS/图片/视频)必加 | 07. 规模化架构 |
| 负载均衡(Nginx、ALB、HAProxy) | 把流量分发到多台机器 | 一台扛不住时,流量入口必备 | 07. 规模化架构 |
| HTTPS / TLS 证书 | 加密传输,防中间人 | 生产环境强制开 | 05. 容器化与部署 |
| VPC / 私有网络 | 隔离内网,只暴露必要端口 | 上云必配,数据库不放公网 | 05. 容器化与部署 |
| WAF(Web Application Firewall) | 拦恶意请求(SQL 注入、CC 攻击) | 有公网暴露 + 有预算时 | 不展开 |
算法工程师类比:接入层像"DataLoader"——把数据从磁盘正确、快速地送到 GPU。
第 2 层:应用层——你的业务代码
这层解决的问题:收到请求后,怎么处理、怎么调用 LLM、怎么返回结果。
| 技术 | 解决什么问题 | 什么时候用 | 本系列哪儿讲 |
|---|---|---|---|
| Web 框架(FastAPI、Flask、Django) | 处理 HTTP 请求、路由、参数校验 | Python 后端必备 | 01. Web 基础、04. Web 服务 |
| REST API | 简单的 CRUD 接口约定 | 默认选择,90% 场景 | 01. Web 基础 |
| GraphQL | 客户端自定义查询字段 | 前端要按需取数、嵌套资源 | 不深入 |
| gRPC | 高性能 RPC,二进制协议,跨语言 | 内部服务间调用、低延迟场景 | 07. 规模化架构 |
| WebSocket | 双向实时通信 | 聊天、协同编辑、推送 | 04. Web 服务 |
| SSE / 流式响应 | 服务端单向推送(LLM 边生成边返回) | ChatGPT 式输出 | 04. Web 服务 |
| JWT | 无状态认证 token | 前后端分离、移动端 | 04. Web 服务 |
| OAuth 2.0 | 第三方登录(Google、微信) | 接入第三方账号 | 04. Web 服务 |
| RBAC / ABAC | 角色/属性级权限控制 | 多租户、多角色系统 | 04. Web 服务 |
| 限流(slowapi、Sentinel) | 防止单用户打垮系统 | 公网 API 必加 | 04. Web 服务 |
| Guardrails(NeMo Guardrails) | LLM 输入/输出安全检查 | LLM 应用必备 | 08. 可靠性与护栏 |
算法工程师类比:应用层像"模型 forward 函数"——接收输入,调用底层(数据库/LLM),返回输出。
第 3 层:数据层——数据存哪里、怎么查得快
这层解决的问题:数据持久化、快速查询、不同数据用不同存储。
| 技术 | 解决什么问题 | 什么时候用 | 本系列哪儿讲 |
|---|---|---|---|
| PostgreSQL / MySQL | 结构化业务数据、强一致、事务 | 用户、订单、配置等核心数据 | 02. 数据库 |
| Redis | 内存缓存、低延迟 | 热数据、session、限流计数 | 03. 缓存与存储 |
| Elasticsearch / OpenSearch | 全文检索、复杂多维查询 | 日志搜索、商品搜索、模糊匹配 | 06. 可观测性(日志场景) |
| MongoDB | 文档型存储、schema 灵活 | 非结构化数据、原型快速迭代 | 不深入,优先 Postgres |
| S3 / OSS / MinIO | 海量文件、图片、视频 | 用户上传、模型权重、备份 | 03. 缓存与存储 |
| pgvector / Qdrant / Milvus | 向量相似度检索 | RAG、语义搜索、推荐 | 03. 缓存与存储 |
| 冷热数据隔离 | 热数据放 Redis/SSD,冷数据归档 S3 | 数据量大、查询频率不均 | 07. 规模化架构 |
| 读写分离 | 主库写、从库读,分摊压力 | 读多写少、并发高 | 07. 规模化架构 |
| 分片(Sharding) | 把数据水平切分到多库 | 单库扛不住(千万级+行) | 07. 规模化架构 |
算法工程师类比:数据层像"数据集 + index"——怎么存、怎么快速取,直接决定训练效率。
第 4 层:协调层——多机器怎么协同
这层解决的问题:从单机到多机后,服务之间怎么发现彼此、怎么通信、怎么避免冲突。
| 技术 | 解决什么问题 | 什么时候用 | 本系列哪儿讲 |
|---|---|---|---|
| ZooKeeper | 分布式协调、选主、配置同步 | 老牌组件,Kafka/K8s 早期依赖 | 07. 规模化架构(认知层) |
| etcd | 强一致 KV 存储、服务发现 | K8s 底层用,常用于自建分布式 | 07. 规模化架构(认知层) |
| Consul | 服务发现 + 健康检查 + KV | 微服务架构常用 | 07. 规模化架构(认知层) |
| Nacos | 注册中心 + 动态配置中心 | 阿里系常用,动态改配置不重启 | 07. 规模化架构(认知层) |
| Apollo | 配置中心(携程开源) | 多环境配置管理 | 07. 规模化架构(认知层) |
| Kafka | 高吞吐消息队列 | 日志收集、事件流、异步解耦 | 07. 规模化架构 |
| RabbitMQ / RocketMQ | 任务队列、可靠投递 | 异步任务、订单流程 | 07. 规模化架构 |
| Celery | Python 异步任务框架 | LLM 长任务、定时任务 | 04. Web 服务 |
| Redis RedLock / ZooKeeper 锁 | 分布式锁 | 多实例操作同一资源防冲突 | 07. 规模化架构 |
算法工程师类比:协调层像"分布式训练里的 AllReduce / NCCL"——多张卡之间怎么同步、怎么避免冲突。
第 5 层:部署层——代码怎么跑在生产
这层解决的问题:把开发机上的代码,稳定、可复现、可回退地跑在生产服务器上。
| 技术 | 解决什么问题 | 什么时候用 | 本系列哪儿讲 |
|---|---|---|---|
| Docker | 打包代码 + 环境,可复现运行 | 所有应用必容器化 | 05. 容器化与部署 |
| docker-compose | 多容器本地编排 | 本地开发、小规模部署 | 05. 容器化与部署 |
| Kubernetes(K8s) | 大规模容器编排、自愈、扩缩容 | 百台机器以上、复杂微服务 | 07. 规模化架构 |
| CI/CD(GitHub Actions、Jenkins、GitLab CI) | push 即自动测试 + 部署 | 所有项目必加 | 05. 容器化与部署 |
| Cloud Run / Fly.io / Vercel | 托管型 serverless 容器 | 个人项目、小团队首选 | 05. 容器化与部署 |
| Terraform / Pulumi | 用代码管理基础设施(IaC) | 多环境、多资源管理 | 07. 规模化架构(认知层) |
| Helm | K8s 应用包管理 | K8s 上部署复杂应用 | 不深入 |
| Istio / Linkerd(Service Mesh) | 微服务间 mTLS、流量治理 | 大规模微服务(进阶) | 07. 规模化架构(认知层) |
算法工程师类比:部署层像"训练框架的 launch 脚本"——怎么把模型、数据、依赖打包起来在集群上跑。
第 6 层:可观测层——系统的"眼睛"
这层解决的问题:系统跑起来后,你怎么知道它健不健康、出了问题怎么定位。
| 技术 | 解决什么问题 | 什么时候用 | 本系列哪儿讲 |
|---|---|---|---|
| Prometheus | 指标采集(QPS、延迟、错误率) | 指标监控标配 | 06. 可观测性 |
| Grafana | 指标可视化面板 | 配 Prometheus 用 | 06. 可观测性 |
| ELK(Elasticsearch + Logstash + Kibana) | 日志采集 + 搜索 + 展示 | 大规模日志检索 | 06. 可观测性 |
| Loki | 轻量级日志系统(替代 ES) | 中小项目、成本敏感 | 06. 可观测性 |
| OpenTelemetry | 分布式追踪标准 | 微服务必加 | 06. 可观测性 |
| Jaeger / Zipkin | trace 可视化 | 排查跨服务慢请求 | 06. 可观测性 |
| Langfuse / LangSmith | LLM 专属 trace、prompt 记录 | LLM 应用必备 | 06. 可观测性、09. LLM 工程 |
| SLO / Error Budget | 定义"够用"的可用性 | 严肃项目必加 | 06. 可观测性 |
| 告警(PagerDuty、企业微信、飞书) | 异常时通知到人 | 所有生产项目必加 | 06. 可观测性 |
算法工程师类比:可观测层像"训练日志 + TensorBoard + W&B"——loss 曲线、metrics、alert,让你随时知道训练状态。
这张图怎么用(三个典型场景)
场景 1:老板说"我们的应用慢"
不要立刻去优化代码。先定位是哪一层慢:
- 接入层:用 Chrome DevTools 看网络面板,TTFB(首字节时间)是不是太高 → CDN / DNS / LB
- 应用层:看 trace,看 LLM 调用还是业务逻辑慢 → 代码优化、加缓存、异步化
- 数据层:看 SQL
EXPLAIN,是不是全表扫 → 加索引、加 Redis - 协调层:消息队列是不是堆积 → 加消费者、扩容
- 可观测层:看 Grafana 哪条曲线异常 → 锁定故障时间窗
场景 2:面试官问"你的 LLM 应用架构是什么"
按层从上到下讲,30 秒讲完:
"接入层用 Cloudflare + Nginx LB;应用层 FastAPI + JWT + 流式 SSE;数据层 Postgres 存业务数据、Redis 做缓存、pgvector 做 RAG、S3 存文件;协调层用 Celery + Redis broker 跑异步任务;部署层 Docker + Cloud Run + GitHub Actions;可观测层用 Grafana Cloud + Langfuse 做 trace。"
条理清晰,这是架构师的表达方式。
场景 3:有人跟你说"我们用 Nacos"
你立刻知道:Nacos 在协调层,做服务发现 + 动态配置。然后你可以追问:
- "你们服务发现用 Nacos 还是 K8s Service?"(同层替代方案)
- "配置热更新是 push 还是 pull?"(具体实现细节)
- "和 ZooKeeper 比,为什么选 Nacos?"(选型理由)
这就是"脑子里有图景"的价值——遇到任何名词都能定位、能追问、能判断。
3. 学习路径 vs 架构分层的关系
注意:学习路径和架构分层是两个维度,不要混淆:
- 架构分层:从上到下,描述系统的物理组成(接入→应用→数据→协调→部署→可观测)
- 学习路径:从简单到复杂,描述你的认知顺序(Web 基础→数据库→缓存→部署→监控→...)
为什么不按架构分层从上到下学?
因为接入层(CDN、LB)在你没有应用之前没意义,而协调层(ZooKeeper、Kafka)在你只有单机时也用不上。学习路径要倒着来——先有应用,再优化存储,再容器化,再监控,最后才能讨论负载均衡和分布式协调。
本系列的 10 篇文章按"学习路径"组织,但每一篇开头都标注**"对应架构的哪一层"**,让你始终知道自己在点亮心智地图的哪一格。
| 本系列篇 | 对应架构层 | 主要技术 |
|---|---|---|
| 01. Web 基础 | 应用层(入门) | HTTP、FastAPI、REST |
| 02. 数据库 | 数据层(核心) | PostgreSQL、SQLModel |
| 03. 缓存与存储 | 数据层(扩展) | Redis、S3、pgvector |
| 04. Web 服务 | 应用层(进阶) | JWT、RBAC、SSE、限流 |
| 05. 容器化与部署 | 部署层 + 接入层(基础) | Docker、Cloud Run、CI/CD、HTTPS |
| 06. 可观测性 | 可观测层 | Prometheus、Grafana、ELK、OTel |
| 07. 规模化架构 | 接入层 + 协调层 + 部署层(进阶) | CDN、LB、K8s、Kafka、Nacos |
| 08. 可靠性与护栏 | 应用层(可靠性) | Guardrails、人审、回退 |
| 09. LLM 应用工程 | 应用层(LLM 专属) | Token 治理、Eval、Prompt 版本 |
不覆盖的(超出本系列范围):
- 前端深入:React/Vue/Next.js 的完整学习。本系列只讲后端为主,前端够用就行。
- 机器学习理论:假设你已经懂。
- DevOps 深入:K8s 高级 Operator、Service Mesh 数据面、多集群联邦等。
- 安全深入:渗透测试、密码学、零信任架构。
- 网络深入:BGP、SDN、TCP 内部机制。
4. 90 天学习路径
按周拆分。每周 5-10 小时学习时间,90 天学完。
第 1-2 周:Web 基础(应用层入门)
- 读完 01. Web 应用基础
- 动手:用 FastAPI 写 3 个不同的 API(增删改查)
- 进阶:读 FastAPI 官方教程的"Tutorial"部分
第 3-4 周:数据层
- 读完 02. 数据库与持久化 和 03. 缓存与对象存储
- 动手:给一个 LLM 应用加上完整的存储层(Postgres + Redis + S3 + pgvector)
- 进阶:读《SQL in 10 Minutes》
第 5-6 周:服务层进阶
- 读完 04. Web 服务开发
- 动手:把前面的应用升级成有认证、权限、流式的完整服务
- 进阶:读 FastAPI 高级文档(OAuth2、中间件)
第 7-8 周:部署上线
- 读完 05. 容器化与部署
- 动手:把应用部署到 Cloud Run,绑域名,配 HTTPS
- 进阶:学 Docker 官方教程
第 9-10 周:可观测性
- 读完 06. 可观测性与 SRE
- 动手:接 Grafana Cloud,配监控告警
- 进阶:读 Google SRE 书前三章
第 11-12 周:规模化与协调
- 读完 07. 规模化架构
- 动手:画一张你自己应用的架构图,标注每个组件属于哪一层
- 进阶:读《Designing Data-Intensive Applications》第 1、5、6 章
第 13 周:可靠性
- 读完 08. 可靠性与护栏
- 动手:给应用加 guardrails 和人审
第 13-14 周:LLM 工程
- 读完 09. LLM 应用工程
- 动手:搭 Eval 体系,Prompt 版本管理
第 15-16 周(缓冲 + 综合项目)
- 用前面学的所有知识,从零做一个完整的 LLM 应用
- 目标:能扛 1000 日活的真实应用
- 包括:前端 + 后端 + 数据库 + 部署 + 监控 + 护栏 + Eval
5. 你需要装的工具
开始前,先装好这些(顺序不重要):
必装
| 工具 | 用途 | 安装方式 |
|---|---|---|
| Python 3.11+ | 写后端 | brew install python 或官网下载 |
| Node.js 18+ | 写前端、跑工具 | brew install node 或 nvm |
| Docker Desktop | 容器化 | 官网下载 |
| Git | 版本控制 | brew install git |
| VS Code | 编辑器 | 官网下载 |
| Postman 或 Insomnia | API 测试 | 官网下载 |
必装的 Python 包
pip install fastapi uvicorn httpx pydantic sqlmodel alembic redis boto3 openai anthropic
必装的 VS Code 插件
- Python(Microsoft)
- Pylance
- Docker(Microsoft)
- Database Client(cweijan)
- REST Client(Huachao Mao)
- GitLens
账号注册
- GitHub——代码托管 + CI/CD
- OpenAI / Anthropic——LLM API(充值至少 $10)
- Google Cloud——部署 Cloud Run(新用户有 $300 免费额度)
- Cloudflare——CDN + DNS
6. 学习资源
必读书
| 书 | 为什么读 | 优先级 |
|---|---|---|
| 《Designing Data-Intensive Applications》 Martin Kleppmann | 数据系统的圣经,本系列的理论基础 | ★★★★★ |
| 《System Design Interview》 Alex Xu | 系统设计图解,图多易读 | ★★★★ |
| 《Site Reliability Engineering》 Google | 运维圣经,免费在线 | ★★★★ |
| 《Designing Machine Learning Systems》 Chip Huyen | ML 生产系统 | ★★★★ |
| 《Refactoring UI》 | 前端设计入门(工程师视角) | ★★★ |
必看博客
- ByteByteGo(Alex Xu)— 系统设计图解
- Chip Huyen — ML 生产
- Simon Willison — LLM 应用实战
- Eugene Yan — ML Eval
- Martin Kleppmann — 分布式系统
- Honeycomb Charity Majors — 可观测性
必看视频
- MIT 6.824 Distributed Systems — 分布式系统经典课
- DDIA Reading Club — DDIA 中文共读
- Honeypot — 程序员纪录片
必装的实践工具(边用边学)
| 类别 | 工具 |
|---|---|
| API 开发 | FastAPI、Pydantic |
| 数据库 | PostgreSQL、SQLModel、Alembic |
| 缓存 | Redis |
| 对象存储 | MinIO(本地 S3)、boto3 |
| 向量库 | pgvector、Qdrant |
| 容器 | Docker、docker-compose |
| 部署 | Cloud Run、Fly.io |
| CI/CD | GitHub Actions |
| 监控 | Grafana Cloud、Langfuse |
| Trace | OpenTelemetry、LangSmith |
| Eval | promptfoo、DeepEval |
| IaC | Terraform |
7. 怎么用这个系列
推荐方式
- 按顺序读:01 → 02 → ... → 09。后篇引用前篇代码。
- 边读边动手:每篇都有"实战"章节,必须跟着敲代码。
- 做完检查清单:每篇末尾有 checklist,全部勾选才算掌握。
- 做综合项目:90 天最后 2 周,从零做一个完整应用。
- 回看分层地图:每读完一篇,回到本篇第 2 节,在分层图上"点亮"对应那一格。
加速方式(如果你有部分基础)
- 先读每篇的"核心概念"和"检查清单"。
- 觉得简单就跳到下一篇。
- 只在"实战"和"踩坑"停下来细看。
跳读方式(如果你只想解决具体问题)
直接看目录,跳到你需要的篇。比如:
- "怎么部署 LLM 应用?" → 05. 容器化与部署
- "怎么做 Eval?" → 09. LLM 应用工程
- "怎么加监控?" → 06. 可观测性
- "什么是 Nacos / Kafka?" → 07. 规模化架构
8. 一些学习心态
心态 1:不要追求"全懂"
6 层架构、每层五六个技术,每个都深入够你学一年。本系列给你的是**"够用"的水平**——能独立做出一个能跑、能扛小规模流量的 LLM 应用。
够用 → 上线 → 踩坑 → 补漏 → 进阶,这是最快的路径。
心态 2:动手比看更重要
读 100 篇文章 < 自己写 1 个应用。
每篇的"实战"章节,必须自己敲一遍。看代码和自己写代码是两种不同的学习。
心态 3:接受"先用再懂"
第一次用 Docker,你不需要懂容器原理。能用就行。
用了 10 次,你会自然想"为什么这么设计"。这时候再去读原理,效率最高。
先会做,再求懂。
心态 4:善用 AI 工具
用 Cursor / Claude Code 辅助学习:
- 让 AI 解释你看不懂的代码
- 让 AI 帮你 debug
- 让 AI 给你出练习题
- 但不要让 AI 替你思考架构决策
心态 5:始终回到分层地图
学到任何新技术,问自己三个问题:
- 它在哪一层?(接入 / 应用 / 数据 / 协调 / 部署 / 可观测)
- 它解决什么问题?(为什么需要它)
- 同层还有什么替代品?(选型对比)
三个问题答得出来,这个技术你才算"懂了"。
9. 开始之前的一个小测试
用下面 5 个问题自测,看看你的起点:
- 你能解释 HTTP GET 和 POST 的区别吗?
- 你知道 SQL 的 JOIN 是干嘛的吗?
- 你用过 Docker 吗?能说出 image 和 container 的区别?
- 你写过 async/await 吗?
- 你部署过任何 Web 应用吗(哪怕 hello world)?
结果:
- 0-1 个"是":你是纯算法背景,从 01 篇开始,完整学。
- 2-3 个"是":你有部分基础,可以快速过 01-03,重点看 04 之后。
- 4-5 个"是":你已经具备基本工程能力,这个系列可能对你来说偏基础,直接看你感兴趣的篇。
10. 下一步
准备好了?开始 01. Web 应用基础。
记住:这个系列的终点不是"读完 10 篇文章",而是**"你能独立做一个能扛百万日活的 LLM 应用,并且脑子里有一张清晰的架构分层图"**。
读完只是开始。真正学会,要靠你自己动手做出来。
最后一句话:算法工程师 + 架构师能力 = AI 时代最稀缺的人才。这条路值得走。