AI 全栈学习地图：造模型、跑模型、用模型的三张图

One System, Three Roles — an Overview of the Three AI Learning Roadmaps

Posted by arganzheng | · 更新于 | 约 18 分钟 · 7.7k 字
AI AI-Infra LLM Agent Roadmap

内容简介

这个博客的技术文章围绕三张学习地图组织：《AI 算法工程师学习地图》、《AI-Infra 工程师学习地图》、《AI 应用工程师学习地图》。每张地图把一个方向的知识分层，说明每层回答什么问题、按什么顺序学、哪些已经写成了系列。本文是三张地图之上的一页总览，回答的是三张地图各自不回答的问题：

为什么是三张而不是一张？三张地图之间怎么分工、在哪里交汇？一个人该从哪一张进入，读到哪里该换到另一张？1

三张地图对应的是同一个系统里的三种角色。一个大模型从数据到用户手里，要被造出来（预训练、后训练、评测）、被跑起来（引擎、集群、平台）、被用起来（检索、工具、编排、产品）。三件事用同一批名词——Python、PyTorch、Transformer、KV cache、LoRA、量化、评测、Agent——但对每个名词的追问方向完全不同。把它们塞进一张地图，结果是每个名词都要讲三遍，或者只讲一遍而对另两种读者是错的。分成三张，每张才能对自己的读者说真话。

三张地图的分工：面向的人、一句话与已写成的系列
地图 面向 一句话 地图分层
AI 算法工程师 造模型的人：能复现论文、设计后训练配方、把模型评测清楚 把模型的效果做上去：为什么这样建模，怎么训、怎么评、怎么证明一次改动是真的变好 八层 + 横切
AI-Infra 跑模型的人：从后端工程师到 PyTorch / vLLM / NCCL 的贡献者 让模型在硬件上跑得快、稳、便宜：每个结构决定在硬件上花多少钱、系统怎么实现，并把训练与推理的迭代周期缩短，让另两类人试得更快 五层 + 横切 + 一个选修
AI 应用工程师 用模型做产品的人：在非确定性组件之上做可靠产品 在模型之上做出可靠的产品：用哪个模型、怎么和检索 / 工具 / 人组合、上线后效果好不好 七层 + 横切 + 选修

一张图：模型的一生与三种工程师

把三张地图放到同一条链上，就是一个模型从数据到用户、再从用户回到数据的循环：

%%{init: {"flowchart": {"wrappingWidth": 260}}}%%
%% 图：模型的一生：三张地图在同一条链上，实线是产物的流动，虚线是需求的回流
flowchart LR
    subgraph ALGO["造模型 · 算法地图"]
        direction TB
        DATA["数据工程<br/>采集 · 去重 · 配比 · tokenizer"]
        PRE["预训练<br/>结构 · scaling law · 配方"]
        POST["后训练<br/>SFT · RL · 蒸馏"]
        EVAL["评测<br/>benchmark · judge · 污染"]
        DATA --> PRE --> POST --> EVAL
    end
    subgraph INFRA["跑模型 · Infra 地图"]
        direction TB
        TRAIN["训练引擎<br/>并行 · checkpoint · 容错"]
        SERVE["推理引擎<br/>调度 · KV · 多卡"]
        PLAT["平台<br/>调度 · 切分 · 网关 · 成本"]
        KERN["kernel 与通信<br/>CUDA · NCCL · RDMA"]
        KERN --> TRAIN
        KERN --> SERVE
        TRAIN --> PLAT
        SERVE --> PLAT
    end
    subgraph APP["用模型 · 应用地图"]
        direction TB
        CTX["上下文<br/>prompt · RAG · memory · 工具"]
        AGENT["编排与运行时<br/>agent 循环 · 状态 · 人在环"]
        PROD["产品与运营<br/>评测 · 成本 · 安全 · 反馈"]
        CTX --> AGENT --> PROD
    end
    EVAL -- "模型权重" --> SERVE
    PRE -. "算力需求" .-> TRAIN
    PLAT -- "模型 API" --> CTX
    PROD -. "线上数据 · bad case · 偏好" .-> DATA

    classDef algo fill:#fff7e0,stroke:#c98a00,stroke-width:1px,color:#222
    classDef infra fill:#eef6ff,stroke:#5b8fd6,stroke-width:1px,color:#222
    classDef app fill:#eefaf0,stroke:#4d9a5c,stroke-width:1px,color:#222
    class DATA,PRE,POST,EVAL algo
    class TRAIN,SERVE,PLAT,KERN infra
    class CTX,AGENT,PROD app
    style ALGO fill:#fffbea,stroke:#c98a00,stroke-width:2px
    style INFRA fill:#f4f8ff,stroke:#5b8fd6,stroke-width:2px
    style APP fill:#f4fbf5,stroke:#4d9a5c,stroke-width:2px

三个方向之间有两条实线和两条虚线。实线是产物的流动：算法侧交出一份权重，Infra 侧把它变成一个模型 API，应用侧在 API 之上做产品。虚线是需求的回流：预训练的算力需求决定了训练引擎要解决什么问题（千卡并行、容错、MFU），线上产品的 bad case 与用户偏好回流成下一轮后训练的数据。

这两条虚线是三张地图不能各自独立的原因。训练引擎的每一个设计决定（为什么按这种方式切分状态、为什么 checkpoint 间隔是这个数）都来自算法侧的一个需求；后训练的每一轮数据（偏好对、失败轨迹、工具调用记录）都来自应用侧的一个产品。一个只读一张地图的人能把自己的那一段做好，但不知道上游为什么这样要求、下游怎样使用自己的产出。三张地图各自的末尾都有一节”与另两张地图的关系”，说的就是这两条虚线。

上下文不同，关注点即不同

在实际AI应用中，你会看到几乎所有的名词都在三张地图上同时出现，但是同一个名词处在不同的上下文，其关注点也不同：

同一个主题，算法地图回答”为什么这样建模、效果如何”，Infra 地图回答”在硬件上花多少钱、系统怎么实现”，应用地图回答”用什么、怎么组合、效果好不好”。

用几个最容易混的名词说明这条规则怎么用：

同一个名词在三张地图里各讲什么
名词 在算法地图里 在 Infra 地图里 在应用地图里
模型 结构、训练、能力：为什么是这个结构，怎么训出来 一个计算对象：参数量、FLOPs、字节数、KV，在硬件上怎么跑 一个组件：API 契约、失效模式、按 token 计费、上下文上限，怎么选型
推理 改变模型或解码过程的方法：量化选哪种、投机解码的草稿模型、KV 压缩 引擎机制：PagedAttention、continuous batching、PD 分离——模型不知道它们存在 一次调用：延迟形态（TTFT / TPOT）、流式、缓存前缀、成本
微调 配方：SFT 数据、LoRA 的秩与目标矩阵、DPO 的 β 账：LoRA 的参数与状态、多 LoRA 服务的 kernel 与调度 决策：何时需要微调而不是 prompt / RAG，数据怎么准备，效果怎么评
评测 模型能力：benchmark 协议、LLM-as-judge 的偏差、污染、pass@k 性能：吞吐、延迟、MFU、有效利用率 应用效果：任务完成率、faithfulness、在线指标、回归
Agent 能力的训练：工具调用数据、多轮 RL、轨迹 RL 后训练的 rollout 基础设施：环境与训练器的共置、权重同步 编排：工具、循环、状态、权限、人在环、harness
成本 按训练算力的账：\(6ND\)、GPU 小时、数据配比换成 epoch 按 GPU 小时的账：分配率、使用率、每百万 token 的成本 按 token 的账：预算、缓存、路由到便宜的模型
数据 决策：配比、质量过滤、去重的阈值、合成数据 实现：tokenization 离线化、流式加载、打包、checkpoint I/O 回流：trace、用户反馈、bad case 怎么变成下一轮数据
安全 对齐与拒答训练 平台层的隔离、多租户与审计 prompt injection、工具权限、PII

一个共享的系列

三张地图有三个系列是共享的。两个是基础：Infra 地图的 01 Python 与 03 PyTorch，它们是算法地图 L1 工具箱的深入篇——L1 讲用法，它们讲机制与实现。一个是核心：《Transformer 与 LLM：结构、实现与算量》（Infra 地图的 04、算法地图的 L4，十三篇分三段）。第一段（01–04）讲结构与实现——Transformer 的每个部件为什么在那里、一个 token 怎么流过它、用 nanoGPT 的 300 行把它写出来训出来，是两类读者共同的起点；第二段（05–09）讲结构从 GPT-2 到 Llama / DeepSeek 的每一处演进为什么发生；第三段（10–13）算”模型作为一个计算对象的成本”——参数量、FLOPs、字节数、KV、通信量——恰好是算法工程师与 Infra 工程师对话的语言：前者从中知道自己的每个结构决定在硬件上花多少钱，后者从中知道要优化什么。它讨论结构、实现与成本表本身；这张表的训练侧——tokenizer、scaling law、数据工程、训练配方——是紧接着它发布的算法地图系列《预训练：从 tokenizer 到训练配方》，不共享：Infra 读者不需要读，算法读者读完 04 接着读。应用工程师读 04 的 KV cache 与多模态两篇，能理解长上下文与图片为什么贵。

一个常见的误分类

三张地图各有一段专门纠正一个误分类，合起来看更清楚：

  • PagedAttention、continuous batching、chunked prefill、PD 分离不是推理算法，是推理引擎的调度与内存管理机制；模型不知道它们的存在，输出分布也不因它们改变。它们属于 Infra 地图。算法侧的推理优化只有改变模型或解码过程的那些。
  • Agent 框架（LangGraph、各家 Agent SDK）与 Agent 产品属于应用地图；Agent 能力的训练——工具调用数据、多轮环境、延后的奖励——属于算法地图的后训练；RL 训练的 rollout 引擎属于 Infra 地图。三张地图上都有”Agent”，说的是三件事。
  • 模型网关在应用地图里是”使用”（接入、路由、fallback），在 Infra 地图里是”建设”（多租户、配额、可观测）。
  • “这个场景该用哪类模型 / 算法”，两张地图都在答，但选的对象不同。应用工程师在现成的模型里选：哪家、多大、prompt / RAG / 长上下文还是微调，判据是任务指标与每次调用的成本；算法工程师在造法里选：什么结构、什么数据、什么训练目标能把这个能力做出来。分界线是要不要产生新的权重——用现成权重解决是应用问题，要训练（哪怕只是 LoRA）是算法问题；”要不要微调”由应用工程师判断，”怎么微调”由算法工程师回答，也就是上表”微调”一行的两格。经典机器学习的场景（分类、排序、异常检测）不能套”新权重”这条线——sklearn 的 fit 也产生参数；这里的分界是决定的对象：从现成模型库里选一个算法、调好超参、接进服务是应用问题，改目标函数、设计特征、决定数据怎么标是算法问题。两条线背后是同一个原则：应用工程师决定”用什么”，算法工程师决定”怎么造”。

从哪一张进入

三张地图各自内部的层是有序的，但三张地图之间没有先后——它们是三个方向，不是三个阶段。进入哪一张由你要做的事决定，而不是由”基础”决定：

不同起点的读者从哪一张地图进入
你是 先读 什么时候翻到另一张
零基础（会编程、数学忘光、没碰过 AI），目标全栈 算法地图 L0 数学 → L1 工具箱（共 14 篇、约 5.5 小时），然后按下面「全栈的一条线」走 那条线把三张地图交织在一起，每一段都标了系列与预计时长；深入篇（01 / 02 / 03）第一遍可以略读
后端工程师，想转 AI 但方向未定 算法地图 L0 → L1（有编程基础的人第一篇过一遍即可，重点是第二篇起的数据科学三剑客与 PyTorch 用法），然后按「全栈的一条线」的第 2、3 段走到 04 系列 到 04 系列读完再定方向：做应用转应用地图，做系统进入 Infra 地图并回头精读 02 / 03，做模型继续第 4 段；深入篇不要一开始就读
后端工程师，想进 AI 基础设施 Infra 地图
  • 读 04 系列时会碰到算法侧的动机
  • 到 07 训练引擎、11 平台时，读算法地图的 L4、L5 知道用户在要什么
  • 做生成模型推理（10）时读 L7
想做模型：后训练、数据、预训练 算法地图
  • 读 L4 时读的就是共享系列
  • 做后训练的 RL 时读 Infra 地图的 09 《RL 后训练基础设施》
  • 做推理效率（L6）时必须读 Infra 08
想用模型做产品 应用地图
  • 读 L1”模型作为组件”时翻 Infra 08 的前两篇，理解 token 计费与延迟形态的来源
  • 读 L3 检索时翻 04 系列的 KV cache 篇，理解长上下文为什么贵
  • 考虑微调时翻算法地图的 L5
产品经理 / 技术负责人 应用地图的 L1、L7、场景轴 需要判断”自建还是用 API”时读 Infra 地图的 08（一个推理服务的成本形态）、11 的交付层（网关、多租户与成本）与算法地图的 L5 概念层
不确定方向，想先建立全貌 本文 → 三张地图的”内容简介”与”两张图” 三张地图的开头各有一张架构图和一张学习路径表，加起来两小时能读完；再挑一张深入

三张地图有一块共同的前置：Python；算法与 Infra 两张还共同要求 PyTorch。算法地图的 L1 工具箱（六篇）讲用法——Python 使用层、数据科学三剑客、PyTorch 使用层、Hugging Face、GPU 直觉；Infra 地图的 01 Python 与 03 PyTorch 讲机制与实现，它们是 L1 的深入篇、两张地图共享，紧接 L1 发布。应用地图只假设后端工程基础与 Python，不要求 PyTorch——它的主线是模型 API、协议与模式，只在走到”要不要微调”（应用地图翻算法地图 L5）时才用得上。一个从零开始的人，算法地图的 L0 → L1 是三条路都用得上的地基，01 与 03 按需再读——算法与应用方向不需要读到 Dispatcher 与 Autograd 引擎那么深。

全栈的一条线

如果目标不是某一个方向，而是把三张地图都走一遍，推荐的顺序是把三张地图交织而不是逐张读完。时长按每分钟 450 字估算，是通读一遍的量，不含动手：

%%{init: {"flowchart": {"wrappingWidth": 420}}}%%
%% 图：全栈的一条线：六段主线与按需进入的深入篇
flowchart TB
    S1["`**1 算法基础**
L0 数学 8 篇 ≈ 3h
L1 工具箱 6 篇 ≈ 2.5h`"]
    S2["`**深入篇（按需分支）**
01 Python 9 篇 ≈ 14h
02 C++ 9 篇 ≈ 33h
03 PyTorch 10 篇 ≈ 15h`"]
    S3["`**2 两代基础**
L2 经典 ML 10 篇 ≈ 4h
L3 深度学习 6 篇 ≈ 3h`"]
    S4["`**3 共享的核心**
04 Transformer 与 LLM 13 篇 ≈ 18h
预训练 5 篇 ≈ 5h`"]
    S5["`**4 造模型**
后训练 8 篇 ≈ 6h · 横切 1 篇
L6 / L7 按方向 ≈ 4h + 7h`"]
    S6["`**5 跑模型**
Infra 05–12 八个系列 ≈ 133h`"]
    S7["`**6 用模型**
应用地图 L1–L7 共 47 篇 ≈ 18h
L1 模型作为组件 6 篇 ≈ 3.5h · L2 上下文工程 6 篇 ≈ 2.5h · L3 检索 7 篇 ≈ 2.5h · L4 Agent 与 harness 9 篇 ≈ 3.5h · L5 评测与可观测 7 篇 ≈ 2h · L6 生产化与运营 7 篇 ≈ 2.5h · L7 产品与体验 5 篇 ≈ 1.5h`"]
    S1 --> S3 --> S4 --> S5 --> S6 --> S7
    S4 -. "做 Infra、改框架时精读；\n01 / 03 可在 L1 后先读总纲的「第一遍怎么读」" .-> S2
    S2 -.-> S6

    classDef algo fill:#fff7e0,stroke:#c98a00,stroke-width:1px,color:#222
    classDef infra fill:#eef6ff,stroke:#5b8fd6,stroke-width:1px,color:#222
    classDef app fill:#eefaf0,stroke:#4d9a5c,stroke-width:1px,color:#222
    classDef shared fill:#f3eefc,stroke:#8a6bd1,stroke-width:1px,color:#222
    classDef deep fill:#f3eefc,stroke:#8a6bd1,stroke-width:1px,color:#222,stroke-dasharray:5 3
    class S1,S3,S5 algo
    class S2 deep
    class S4 shared
    class S6 infra
    class S7 app

黄色是算法地图、紫色是两张地图共享、蓝色是 Infra、绿色是应用。实线是主线，六段；虚线框是深入篇，不在主线上，按需进入。六段的内容：

  1. 算法基础：L0 数学、L1 工具箱——从零开始的地基，三条路都用得上。一个会编程但数学忘光的后端工程师，从这里进入不需要任何前置。
  2. 两代基础：算法地图 L2 经典机器学习、L3 深度学习基础——用 Python / NumPy / PyTorch 把”学习”与”反向传播”亲手跑出来，全部在 CPU 上。
  3. 共享的核心：04 系列——先手搓一个 GPT（01–04），再看结构怎么演进（05–09），最后算成本（10–13），两张地图在这里会合；接着读预训练 5 篇。到这里，一个大模型从 token 进到 token 出的每一步都能写出来、也能算账了。
  4. 造模型：后训练八篇——SFT、偏好、在线与离线 RL、推理模型、Agent RL、蒸馏、评测；横切的实验方法论；L6 高效推理与 L7 多模态按方向选。
  5. 跑模型：Infra 05–11——kernel、通信、训练引擎、推理引擎、RL 后训练系统、扩散模型推理、平台；再加 12 开源贡献（贡献者路径，只做部署运维可跳过）。这一段的量与前四段之和相当，先按各总纲的「第一遍怎么读」走。
  6. 用模型：应用地图 L1–L7——组件观、上下文、检索、Agent、评测、运营、产品。

深入篇（Infra 01 Python、02 C++、03 PyTorch）不在主线上。它们合计 60 多小时，是整张图里最重的一块，早先的版本把它放在第 1 段之后——一个刚学完矩阵乘法的读者接着面对 33 小时的 C++ 模板与 Dispatcher，是这条线上最劝退的一段，也是不必要的：第 2、3、4 段用 PyTorch 的用法就够了，01 / 03 讲的是它的机制与实现。进入的时机是：决定做 Infra（第 5 段之前，02 / 03 是 05–08 的前置）、要改框架或写扩展、或者第 3 段算账时想知道”这行代码底下到底发生了什么”。方向明确做应用的读者可以完全不读 02。01 与 03 的总纲各有一节「第一遍怎么读」，在第 1 段之后翻一遍即可。

本博客文章的发布顺序与这条线大致一致：三张地图先发（算法、Infra、应用），然后 L0 / L1、Python / C++ / PyTorch、L2 / L3、共享的 04、后训练、Infra 系统各系列，应用地图的系列在最后。差别只有一处：深入篇（Python / C++ / PyTorch）紧接 L1 发布，却不在这条线的主线上——按发布时间从头读的人，读完 L1 先跳过它们、按上面说的时机再回来，读到的就是这条线。发布顺序是写作的顺序，不是必须遵守的学习顺序；上面的读者表按方向给的入口才是。

三张地图共有的写法

三张地图和它们下面的系列共用几条约定，读的时候知道这些约定能省时间：

每张地图两张图。 一张描述系统怎么叠起来（Infra 的架构视图、算法的模型生命周期、应用的架构视图），一张描述人怎么进入它（学习路径）。两张图的层不重合——架构上的一层可能对应学习上的三层，反过来也是——混在一起是很多学习计划失败的原因。每张地图都有一节”两张图的叠加”把它们对上。

每层回答一个问题。 学习路径表里每一层都写成一个问句（”梯度怎么流？为什么深了就难训？”“模型这一步该看到什么？”）。问句是这一层的验收标准：能回答就是学会了，不能回答就回去读。

推导 → 算账 → 与真实系统对照。 系列文章的每一章大体按这个顺序走：先从定义推出结论（中间步骤不省），再用一个真实模型或真实集群的数字把它算出来，再指出它在 PyTorch / vLLM / 某篇技术报告里的形态。数字分三类并明确标注：理论下界或估算、公开论文与报告里的数字、本地实测的数字。三类不混用。

开头提问，脚注作答，再考一遍。 每篇文章开头有一个粗体的核心问题（常由两三个小问组成），每个小问后面挂一个脚注编号，答案在文末逐条给出、并链到讲它的那一章——读完再点编号核对，读之前先别看。小结之后是一节「自测」——三到五道有确定答案的题，答案各自折叠，先自己答、再展开对。这是检验”读懂了”最便宜的办法；答不上来就回到对应的章。两张地图上已发布的 142 篇系列文章全部按这个格式整理过。每个系列的最后另有一篇「系列总结与通关自测」：把整个系列压成一张表逐篇回顾、拎出贯穿各篇的线与常见误区，再给三段式自测——十道判断与计算、五道跨篇综合、若干道面试题——检验的是”几篇能不能连起来用”。下文与三张地图里的篇数与时长都指正文，不含这一篇。

系列自治，地图说依赖。 每个系列都能单独读懂，正文里保留理解它所需的最小知识集；系列之间的先后关系只在地图里说明。所以从任何一个系列进入都可以，但按地图给的顺序读会少走回头路。

边界写在末尾。 每张地图、每个系列的末尾都有一节”边界与说明”：主线是什么、替代品在哪里提及、什么不在地图上、版本基线是什么。这一节决定了地图在什么范围内为自己的说法负责。

现状与更新

三张地图的写作现状
地图 已写 待写
AI-Infra 十二个系列共 110 篇、约 210 小时：Python 9（14h）、C++ 9（33h）、PyTorch 10（15h）、Transformer 与 LLM 13（18h）、GPU kernel 10（21h）、通信 8（20h）、大规模训练 8（22h）、vLLM 14（17h）、RL 后训练基础设施 8（8h）、扩散模型推理基础设施 9（13h）、平台 8（21h）、开源贡献 4（9h） 选修《ML 编译器内部》13 篇（16h）已成，2026-11-21 起发布
AI 算法工程师 专属 58 篇、约 35 小时：L0 数学 8（3h），L1 工具箱 6（2.5h，深入篇共享 Infra 01、03），L2 经典机器学习 10（4h），L3 深度学习基础 6（3h），L4 共享 04 系列 + 预训练 4（4h），L5 后训练 8（6h），L6 高效推理与压缩 6（4h），L7 多模态 9（7h），横切实验方法论 1（1h） —
AI 应用工程师 地图本身（含场景轴与三个 harness 案例）；L1 模型作为组件 6（3.5h）、L2 Prompt 与上下文工程 6（2.5h）、L3 检索与知识接入 7（2.5h）、L4 工具、Agent 与 harness 9（3.5h）、L5 评测、可观测与可追溯 7（2h）、L6 生产化与运营 7（2.5h）、L7 产品与体验 5（1.5h） 七个系列已齐

三张地图会随文章的增加更新”已有的文章与系列”一节，也会随领域变化更新层的内容——算法地图的”版本与时效”一节说了这件事：2023 年的主线是 SFT + PPO，2024 年是 DPO 一族，2025 年是可验证奖励的 RL，地图列出的是当前的主线并会随之更新，不变的是结构。

三张地图都开着评论与划线评论。哪一层的问句你回答不上来、哪一段推导跳步了、哪一个数字对不上，划出来说一句，是这组文章改进的主要来源。

  1. 三张地图对应同一个系统里的三种角色——造模型（预训练、后训练、评测）、跑模型（引擎、集群、平台）、用模型（检索、工具、编排、产品）。它们用同一批名词（PyTorch、KV cache、LoRA、量化、评测、Agent），但对每个名词的追问方向不同，塞进一张地图就得每个名词讲三遍或对两类读者说错话。分工见上表：算法地图负责「效果做上去」、Infra 地图负责「跑得快、稳、便宜」、应用地图负责「在模型之上做可靠产品」；交汇点是共享的 Python / PyTorch / Transformer 系列（算法与 Infra 共享 01 / 03 / 04）、推理优化（算法侧改模型与解码，Infra 侧改调度与内存）、模型网关（应用侧用、Infra 侧建）。进入方式按身份：造模型的人从算法地图、后端 / 系统工程师从 Infra 地图、做产品的人从应用地图；读到「这个结构在硬件上花多少」换到 Infra，读到「这个指标怎么证明变好」换到算法，读到「上线后用户怎么用」换到应用——正文「怎么用这三张地图」一节给出了各身份的切换点。 ↩

这篇对你有用？

本文由 arganzheng 创作，采用 CC BY 4.0 许可协议。在保留原文作者、署名以及完整原文链接（https://arganzheng.life/ai-fullstack-learning-roadmap.html）的前提下，欢迎各种形式的转载、翻译或商业引用。

YOU MIGHT ALSO LIKE

COMMENTS

评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。

OUTLINE

    没有匹配的标题

    ×