Lecture 05：Vercel 的云编译器——框架、消费反馈与 AI Compute

LaTeX 源码 · 观看视频

字段	内容
作者/整理	基于 Guillermo Rauch 访谈、时间戳字幕与 Vercel/Next.js 官方资料整理
来源	Stanford CS153 历史课程上传（当前已 private）
日期	2025 年冬季课程 · 2026 年重写版

\makecscover

来源审计：为什么 AWS 之上仍需要一层平台

这场访谈从一个看似朴素的问题开始：既然 AWS 已经提供计算、存储、网络和数据库，为什么还需要 Vercel？回答不能停在“开发体验更好”。真正的系统问题是：hyperscaler 暴露的是通用 primitives，而应用团队需要的是从产品意图到可运行系统的确定性转换。 当 primitives 数量越来越多，选择、连接、配置、扩缩容和观测本身就形成新的复杂性层。

历史公开视频在 2026 年 8 月 11 日核验时已转为 private；仓库保留官方封面和 931 条时间戳字幕。字幕自动识别把 Vercel、v0、Guillermo 和若干技术名词写错，因此本讲只在上下文和官方文档一致时规范化名称。Black Friday、收入、客户损失和 uptime 等数字视为讲者现场案例，不当作审计数据。

本讲的两个编译/反馈闭环

设计闭环：application intent \(\rightarrow\) framework semantics \(\rightarrow\) platform IR \(\rightarrow\) infrastructure；
运行闭环：traffic \(\rightarrow\) telemetry/metering \(\rightarrow\) developer decision \(\rightarrow\) new immutable deployment。

Vercel 的价值来自同时缩短这两个闭环，而不是隐藏所有技术细节。

先看平台在整个栈中的位置。底层 hyperscaler 解决大规模物理运营，上层框架表达应用结构，平台负责把二者连接成可持续运行的部署系统。

\lecturefigure{01-abstraction-layers.png}{平台层把应用意图编译成对 hyperscaler primitives 的受管使用。}{本地字幕 00:00--03:10；lecture05-diagrams.py 可复现重绘。}

读图：抽象层不是简单“包一层”

有价值的抽象必须压缩决策空间，并提供底层 primitives 做不到的全局不变量，例如每个 commit 对应不可变部署、域名指针可原子切换、框架路由自动变成 edge routing、缓存策略与代码语义一致。若平台只是把 AWS 控制台换皮，它没有创造新的系统能力。

术语消化：四个容易混淆的层次

层次	提供什么	不自动提供什么
Hyperscaler	区域、硬件、网络和通用云服务	针对某个框架的完整应用语义
Cloud primitive	对象存储、函数、队列、数据库等能力	primitives 之间的正确组合与产品默认值
Platform	受管 build、deploy、route、scale、observe	应用业务逻辑与正确产品目标
Framework	路由、rendering、data lifecycle 等结构	跨区域物理基础设施和长期运营

本章小结

平台层存在的理由不是底层云“不够强”，而是通用 primitives 与应用意图之间仍有巨大翻译成本。高价值平台把这段翻译固化为可重复的编译和运营闭环。

失败样板：为什么第一版 Kubernetes 架构不合适

Vercel 的第一版曾把 Kubernetes 当作工作负载运行平台。Kubernetes 本身并非错误；问题在于产品承诺是“每个 Git commit 都成为一个快速、不可变、可分享的部署”。如果直接把 deployment 映射为 pod 或静态资源单元，部署数量会随 commit 增长，而 idle reservation、调度延迟和 scale transition 会破坏单位经济学。

技术可行不等于经济可行

假设一天产生 \(N_d\) 个 preview deployments，每个 deployment 的空闲资源成本为 \(c_{idle}\)，实际执行成本为 \(c_{run}\)，则粗略日成本为

\[ C_{day}=N_d\cdot c_{idle}+\sum_j c_{run,j}. \]

当大部分 preview 很少被访问时，第一项会主导成本。系统必须让“未访问部署”接近零运行成本，同时在第一次请求到来时快速恢复，才能支撑 per-commit product model。

\lecturefigure{02-kubernetes-economics.png}{Per-commit 产品承诺会放大静态资源分配的成本与延迟。}{本地字幕 01:12--01:42、28:50--30:10；概念重绘。}

读图：问题不是 pod，而是映射关系

若每个 immutable deployment 都长期绑定独立 pod，preview 数量和运行资源近似线性增长。更合适的架构会把部署表示为 artifact + metadata，在请求到达时复用共享 runtime、cache 和调度资源。Kubernetes 可以作为底层组件，但不能让产品对象与资源对象一一绑定。

“Kubernetes 太重”不是普遍结论

课堂评价针对 Vercel 当时的超高部署基数、快速 scale-to-zero 和 preview 经济模型。对于长期运行服务、稳定容量和成熟平台团队，Kubernetes 仍可能是合理选择。系统设计应比较 workload shape、控制面规模和单位成本，而不是复述工具偏好。

\teachervoice{Rauch 把这次失败描述得很直接：第一版实现“bleeding money left and right”。高价值 teacher voice 在于，他没有降低“每个 commit 都部署”的产品标准，而是把不合理的体验目标转成新的 scheduler、placement 和 metadata 研究问题。}

本章小结

架构必须服从产品对象的基数与生命周期。Per-commit deployment 需要 artifact-first、shared-runtime 和 fast activation，而不是把每个逻辑部署永久映射成一个静态资源租约。

Framework-Defined Infrastructure：把应用当成高层语言

\term{Framework-Defined Infrastructure}（FDI）把框架约定视为高层语言。框架知道哪些 route 是静态的、哪些需要函数、哪些数据可以缓存、哪些请求需要 middleware；平台在 build time 解析这些语义，生成底层基础设施配置。与 Infrastructure as Code 不同，开发者不直接声明每个云资源，而是声明应用，基础设施成为编译输出。

Cloud compiler 与 intermediate representation

设应用源码为 \(A\)，框架语义抽取器为 \(S_F\)，平台编译器为 \(C_P\)，则部署计划可抽象为

\[ I=C_P\bigl(S_F(A)\bigr), \]

其中 \(S_F(A)\) 不是原始源码，而是 \term{intermediate representation}（IR，中间表示）：route graph、static assets、function boundaries、cache policy、runtime hints 和环境元数据。IR 让平台不必理解每个框架内部实现，只需要稳定的输出契约。

\lecturefigure{03-cloud-compiler.png}{Framework semantics 经过平台 IR 转换为部署计划。}{本地字幕 04:40--06:00；Vercel 官方 Framework-Defined Infrastructure。}

读图：框架为什么能提供比通用 IaC 更多的信息

IaC 知道“创建一个 function”，却未必知道它对应哪个 route、能否静态化、何时 revalidate、是否需要 edge middleware。框架掌握应用语义，平台掌握运行约束；FDI 的优势来自二者在 build time 合并，而不是来自少写几行 YAML。

Build Output API：把框架适配变成 artifact contract

Vercel 的 Build Output API 把编译结果定义为文件系统规范：静态资源、functions、routing 和配置被写成可部署 artifact。这样 Next.js、SvelteKit、Nuxt 或其他框架可以生成共同 IR，平台只需消费标准化输出。它也允许本地 build 后使用 prebuilt deployment，从而把 build 与 deploy 解耦。

\lecturefigure{04-build-output-graph.png}{Build Output 把一个应用拆成可部署的 artifact graph。}{Vercel Build Output API 官方文档；课堂 cloud compiler 比喻。}

编译器抽象带来的四个系统收益

可重复：相同输入和版本生成可审计输出；
可移植：框架通过 artifact contract 接入平台；
可优化：平台可按 route 选择 cache、runtime 和 region；
可回滚：部署对象不可变，流量指针可切回旧版本。

编译器不能推断所有业务意图

平台可以识别 route 和 cache declaration，却不知道库存数据能否陈旧、某个 API 是否需要强一致、失败是否影响收入。FDI 需要 guard rails 和 override；若把错误默认值自动扩散到全球，自动化只会更快地制造事故。

本章小结

FDI 的本质是从框架语义生成平台 IR，再映射为基础设施。Build Output API 把这条编译边界显式化，使框架生态与平台运行时能够独立演化。

ISR 与缓存：把后端工作 materialize 到边缘

电商 Black Friday 的典型瓶颈不是边缘网络，而是 origin/backend 无法承受每个用户都触发动态渲染。Incremental Static Regeneration（ISR）把一次 render 的结果 \term{materialize}（物化）为可缓存 artifact，在 freshness policy 到期或事件触发时重新生成。它改变了负载模型：后端处理“内容变化”，edge 处理“访问次数”。

从 request amplification 到 backend shielding

若页面在一个 freshness window 中收到 \(R\) 次请求，传统动态渲染需要约 \(R\) 次 origin work；理想 ISR 只需一次生成和一次 revalidation，后端工作量从 \(O(R)\) 接近 \(O(1)\)。真实系统还要处理 stampede、失败回退、区域 cache、tag invalidation 和 stale content。

\lecturefigure{05-isr-cache-loop.png}{ISR 用 materialization 和 revalidation 把重复读取从 backend 移到 edge。}{本地字幕 05:55--07:20；Next.js 官方 ISR 文档。}

读图：比较访问频率与变化频率

ISR 最适合“读很多、写较少、允许明确 freshness”的内容。若数据每次请求都不同，cache 命中率低；若内容绝不能陈旧，就需要同步 origin 或更严格 invalidation。核心问题不是“能否缓存”，而是业务允许什么 consistency contract。

缓存不会让 origin 无限扩展

Cache miss、同时 revalidation、个性化请求和大量不同 key 仍会击穿后端。平台需要 request coalescing、stale-while-revalidate、负载保护和可见的 cache status，开发者也必须理解 cache key 与 invalidation 语义。

\teachervoice{Rauch 的表达很有工程感：云“elastic”不代表任何组件都完美扩展。平台价值之一，是自动组合多级缓存和 materialization，把开发者过去手工管理的 Memcached、worker pool 和横向扩展模式固化为框架能力。}

本章小结

ISR 把访问规模与后端计算解耦，让应用流量更多由 edge artifact 承担。它不是静态化一切，而是显式管理 freshness、materialization 和 revalidation。

Build vs. Buy：差异化边界与全球 control plane

平台公司很容易陷入“既然基础设施重要，就全部自研”的误区。Rauch 的判断相反：AWS 的区域、骨干网、对象存储和物理运营规模难以复制，Vercel 更应该在 application-aware layer 积累差异化。Build vs. Buy 不是技术能力测试，而是资本、时间和学习效应的配置问题。

把自研放在 insight 会复利的位置

上一节已经把 hyperscaler primitives 与 application intent 之间的缺口解释为“编译层问题”；本节进一步回答组织边界：哪些层值得自己掌握，哪些层应该借助成熟供应商。读图时先比较 commodity scale 与 application-aware insight，再判断某项自研是否会持续产生产品知识、控制面能力和单位经济性优势。

\lecturefigure{06-build-vs-buy.png}{复用 commodity scale，在 application-aware layer 建立专用能力。}{本地字幕 07:40--10:30；概念重绘。}

读图：Apple silicon 类比的边界

课堂用 Apple 最终自研芯片类比 vertical integration：只有当某层成为产品体验和长期经济性的核心，且组织拥有足够规模与能力时，向下整合才可能合理。类比不能直接推出 Vercel 应造数据中心；它只说明 build/buy boundary 会随着战略变化移动。

全球 metadata 才是平台差异化

Vercel 更像 application-aware CDN/control plane，而不是 EC2。每个 deployment 是不可变对象；domain binding 是一个可变指针；全球 edge 需要快速获得最新 pointer 和 routing metadata。回滚不需要覆写旧部署，只需把 domain 指针切回已知版本。

\lecturefigure{07-global-metadata.png}{不可变部署与可变 domain pointer 分离了 artifact identity 和流量决策。}{本地字幕 10:00--16:40、33:30--34:05；概念重绘。}

Control plane 与 data plane

\term{control plane} 决定 deployment、domain、routing、policy 和 rollout；\term{data plane} 真正处理用户请求、执行函数和返回 assets。控制面更新必须快速传播，但不应让单点故障中断已知路由；数据面必须在 metadata 短暂陈旧时保持安全行为。

Opinionated platform 的正负面

框架约定提供 guard rails，使平台能推断 routing、cache 和 runtime。代价是部分自由被收敛，非典型 workload 可能需要 escape hatch。一个健康的 opinionated platform 应让常见路径极简，同时保留 artifact contract、标准协议和 override，防止生态锁死。

\lecturefigure{08-opinionated-platform.png}{框架约定为平台创造可优化的结构化表面。}{Vercel FDI 官方材料；本地字幕 13:30--17:15。}

Next.js 不是“把用户锁进 Vercel”的充分证据

框架与平台之间确实存在正反馈和商业利益，但判断 lock-in 应检查开放源码、标准输出、self-host 路径、数据可迁移性和替代成本。讲义讨论 mechanism，不采用“Trojan horse”式情绪标签替代分析。

\teachervoice{课堂没有把 Vercel 与 AWS 描述成零和竞争。AWS 提供可信的 hyperscale primitives，Vercel 把尚未迁移到云的应用通过更高层模型接入这些 primitives。平台之间既竞争价值份额，也可能互相扩大市场。}

本章小结

Build vs. Buy 应围绕差异化和学习复利；Vercel 的专用能力集中在 framework compiler、global metadata、routing 和 developer loop，而不是重复 hyperscaler 的物理规模。

Consumption economics：把资源影响反馈给开发者

云和 AI 都在走向 consumption-based pricing。问题不只是“按量收费是否便宜”，而是计量能否成为开发者的 \term{fitness function}：某次 query、render、model call 或 data transfer 消耗了什么资源，是否影响其他 workload，开发者能否据此优化。

Honest metering 与可归因资源

若计费维度为 \(u_i\)，单价为 \(p_i\)，账单为

\[ B=\sum_i u_i p_i. \]

公式本身不难；困难在于 \(u_i\) 是否与开发者操作可对应。一个昂贵 join 若只表现为“数据库整体变慢、账单整体上升”，反馈很差；若系统能指出该 operation 的读取、CPU、内存和延迟影响，开发者才能决定加索引、缓存、拆查询或接受成本。

\lecturefigure{09-consumption-feedback.png}{消费计量只有进入开发决策闭环时才产生工程价值。}{本地字幕 20:00--22:40；概念重绘。}

读图：价格信号必须和质量信号一起看

只显示费用会诱导过度优化；只显示延迟会隐藏资源浪费。理想界面同时展示 request volume、latency、error、cache hit、CPU/memory、transfer 和 spend，并关联 deployment version。开发者优化的是单位业务结果的成本，而不是单个指标最小化。

Noisy workload 与隔离

课堂用数据库作类比，真正要表达的是 workload attribution：共享系统中某个昂贵操作可能拖慢邻居，却没有清晰计量。讲义不把 PostgreSQL 或 DynamoDB 绝对分类为“坏/好系统”，而是比较具体配置能否提供 workload isolation、horizontal scaling 和 operation-level evidence。

\lecturefigure{10-workload-isolation.png}{资源隔离和 operation-level accounting 让性能与成本可解释。}{本地字幕 20:30--22:35；概念重绘。}

消费计费可能把平台低效转嫁给用户

按量收费不天然公平。如果平台 runtime 浪费 CPU、cache 策略低效或计量维度不可解释，用户会为平台问题买单。供应商需要公开计量语义、提供优化建议，并让用户区分业务增长与系统回归。

本章小结

Consumption economics 的核心是 attribution。资源、价格和服务质量必须映射回具体 operation 和 deployment，才能形成工程反馈，而不是月底才出现的不可解释账单。

Telemetry 与 Spend Control：可见不等于可控

上一章说明 consumption economics 必须落实到 operation-level attribution；但“能计量”还没有回答异常发生时谁来行动。本章把近实时 telemetry 与 spend controls 连成闭环：前者把部署变化映射到 latency、error、resource 和费用，后者决定越过阈值后通知、触发 webhook、降级还是暂停。核心不是拥有更多 dashboard，而是用可解释信号做出与业务价值相称的控制决策。

把 deploy、latency、error 和 spend 放在同一时间线

本节先建立可观测性的因果顺序：一次 deployment 改变了代码与配置，随后才可能改变性能、错误率、资源消耗和账单。读图时不要把四条独立曲线并排观看，而要沿同一版本时间线追问“哪次变化造成了什么后果”，并区分业务流量增长、应用回归与平台计量变化。

\lecturefigure{11-telemetry-loop.png}{Telemetry 应把版本变化与资源、性能和费用后果关联起来。}{本地字幕 22:50--23:45；概念重绘。}

读图：为什么 telemetry 自身也是昂贵基础设施

高基数 labels、分钟级账单、跨区域日志和长保留期都会增加存储与查询成本。平台收费的一部分确实是在维护这套反馈基础设施。用户应明确哪些信号需要实时、哪些可采样、哪些必须长期保留用于审计。

Soft cap 与 hard cap 的目标不同

Soft cap 通过通知或 webhook 促使人和自动化采取行动，但流量继续服务；hard cap 在阈值后暂停，限制最坏支出，却可能切断正在产生收入的业务。当前 Vercel Spend Management 文档还明确指出检查并非连续，暂停可能在越过阈值数分钟后发生，因此 hard cap 也不是精确断路器。

\lecturefigure{12-spend-controls.png}{Soft control 保护学习与连续性，hard control 保护最坏支出。}{本地字幕 23:40--24:50；Vercel Spend Management 官方文档。}

预算阈值应来自业务函数

可把 hard-stop 决策粗略写为：当继续服务的预期损失

\[ L_{continue}=P(\text{abuse})\cdot C_{abuse}+C_{runaway} \]

超过暂停造成的

\[ L_{pause}=R_{lost}+C_{recovery}+C_{trust} \]

时才暂停。这里 \(R_{lost}\) 是丢失收入，\(C_{trust}\) 是用户信任损失。实际系统需要多级限流、attack detection 和人工升级，而不是只设一个金额。

Hard cap 不是实时安全边界

计量、汇总、阈值判断和暂停传播都存在延迟。对高风险 AI endpoint，还应使用 request rate limit、per-user quota、model budget、circuit breaker 和 abuse monitoring，不能只依赖月底预算。

\teachervoice{课堂案例中，客户因 hard cap 在高流量时停止服务而损失收入。无论数字是否精确，结论很清楚：成本控制必须理解业务价值。Soft cap 用于学习，hard cap 用于不可接受风险；两者不能互换。}

本章小结

Telemetry 提供因果线索，Spend Control 提供行动。有效系统要把性能、成本、业务价值和执行延迟共同纳入阈值设计。

AI Compute Density：长等待请求改变 serverless 假设

传统 web request 追求短延迟：CPU 执行、数据库返回、快速结束。AI 应用常调用外部 model provider，streaming 数十秒甚至数分钟；这段时间本地 CPU 可能空闲。如果仍为每个请求独占完整实例，就会产生巨大浪费。课堂预告的 compute 产品后来演化为 Fluid Compute；当前官方资料强调复用 warm instances、并发处理、active CPU 和更长执行生命周期。

CPU-bound 与 I/O-bound 必须分开调度

\term{CPU-bound} 请求的大部分时间在本地计算，过度并发会争抢 CPU；\term{I/O-bound} 请求的大部分时间等待网络、数据库或模型，适度并发可以在等待间隙复用 CPU。定义请求 \(j\) 的 active CPU time 为 \(a_j\)，wall time 为 \(w_j\)，则等待比例约为

\[ r_j=1-\frac{a_j}{w_j}. \]

\(r_j\) 高的 workload 更适合安全 multiplex；\(r_j\) 低则更需要 scale-out 和资源隔离。

\lecturefigure{13-compute-density.png}{AI workload 要按 CPU activity 和 I/O wait 选择 scale-out 或并发复用。}{本地字幕 24:50--28:10；Vercel 当前 Fluid Compute 官方资料。}

读图：compute density 不等于无上限并发

I/O-bound 请求仍占用内存、socket、file descriptor、stream buffer 和 event-loop capacity。并发上限必须由 latency SLO、memory、downstream quota 和 noisy-neighbor test 决定。调度器需要观察真实 active CPU 和 wait profile，而不是只按请求数扩容。

课堂预告与当前产品不能混为一谈

访谈只描述了“根据 CPU-bound / I/O-bound profile 智能提高 compute density”的方向。Fluid Compute 后续加入的 active-CPU billing、warm instance reuse、longer execution 和 background work 是当前官方产品描述，不应倒写成 2025 课堂已经完整实现的细节。

\teachervoice{Rauch 的优先级是性能：不能因为某客户突然流行，就让 noisy neighbor 降低其他客户质量。Compute density 的目标不是单纯压成本，而是在保持隔离和延迟标准下减少 idle waste，并把 capacity tuning 从客户手中移到平台。}

本章小结

AI 把 web workload 从短 CPU burst 推向长等待和 streaming。调度器需要区分 active compute 与 I/O wait，在不破坏隔离的前提下复用 warm capacity。

v0 与 AI-native development：产品约束制造研究问题

v0 把自然语言想法转换为可运行前端，并逐步扩展到 full-stack application。课堂时点的早期版本使用 GPT-3.5 Turbo，原生 function calling 还不成熟，团队必须构建 bespoke tool invocation。这个历史说明：AI 产品不是简单调用模型 API，而是模型、工具、framework knowledge、preview deployment 和用户反馈的联合系统。

从 prompt 到运行中的应用

前面的 compute-density 讨论关注请求如何高效运行；这里转向 AI application 的生成与验证闭环。本节回答的不是“模型能否写出一段 JSX”，而是一个 prompt 怎样经过 tool invocation、framework-aware code generation、build、preview 和 human feedback 变成可交互产品。读图时应把 preview environment 看成 verifier，而不是单纯的发布终点。

\lecturefigure{14-v0-loop.png}{v0 把生成代码、工具调用、preview URL 和用户反馈连接成产品闭环。}{本地字幕 30:15--31:55；概念重绘。}

读图：运行环境为什么是 coding agent 的 verifier

代码看起来合理不等于能 build、render 和交互。Preview deployment 提供可执行反馈：编译是否通过、页面是否可访问、视觉和行为是否符合要求。Agent 需要把 build log、browser result 和用户修改重新送回生成循环。

Fast growth 不是 architecture proof

课堂提到 v0 的快速增长，只能说明需求信号强，不能证明单位经济学、长期 retention 或生成质量已经解决。AI 产品仍需要任务分布、成功率、修复轮数、token cost、latency 和用户留存等长期指标。

\teachervoice{Rauch 把“设定不合理的高标准”当作研究方法：如果目标只是把现有 workflow 自动化，团队可能不会遇到 novel problem；若要求每个 prompt 都快速变成可运行系统，tool calling、sandbox、preview 和 feedback 就会成为新的研究基础设施。}

本章小结

v0 的系统单元不是一个 completion，而是 prompt--tool--code--preview--feedback 循环。产品约束可以创造研究问题，但必须用运行证据验证，而不是只展示生成文本。

Immutable MVP、Gossip 与 Day 1/100/1000

Vercel 的早期 MVP 极窄：一个 API/CLI 调用返回不可变 deployment URL。底层系统起初可能过度配置且昂贵，但这个接口足以验证用户是否真正想要“部署即 URL”。Rauch 将 immutable data structures、IPFS content identity 和 gossip propagation 作为灵感来源，随后用实际需求驱动内部重构。

先验证 idea-market fit，再优化内部实现

\term{immutable deployment} 指部署内容一旦生成便不原地修改；新版本创建新 identity。\term{gossip protocol} 让节点互相传播 metadata，最终在全球副本间收敛。Domain 指针可以变化，deployment artifact 保持不变，从而获得可追溯 preview、原子 promote 和快速 rollback。

\lecturefigure{15-immutable-mvp.png}{一个窄 API/CLI 把 artifact identity、metadata propagation 和 URL 连接起来。}{本地字幕 32:50--35:55；概念重绘。}

读图：MVP 可以内部低效，但外部契约要正确

早期系统可以 over-provision，只要成本可承受且产品信号值得验证；但若外部 API 把可变服务器状态暴露给用户，后续很难迁移。优秀 MVP 选择一个未来仍成立的稳定抽象，再逐步替换内部实现。

Day 1、Day 100、Day 1000 是三种不同验收

上一小节说明 MVP 可以暂时内部低效，但外部契约必须长期正确；接下来需要用时间尺度检验这个契约是否真的吸收了复杂度。Day 1 检查 onboarding 和第一印象；Day 100 检查项目增长后平台是否泄漏复杂性；Day 1000 检查 uptime、恢复、成本和组织信任。许多开发工具只优化 Day 1 demo，却把长期状态、依赖和运维负担交还给用户，因此成熟度不能只由首次部署速度衡量。

\lecturefigure{16-day-maturity.png}{基础设施产品必须分别通过采用、复杂度吸收和长期运营测试。}{本地字幕 36:00--37:05；概念重绘。}

Day 1/100/1000 验收问题

Day 1：新人能否在不了解底层细节时安全部署？
Day 100：route、team、environment 和数据依赖增加后，默认模型是否仍清晰？
Day 1000：升级、事故、人员流动和供应商变化时，系统能否恢复并保持可审计？

不可变部署不等于不可变数据

代码和 assets 可以 immutable，数据库、队列和外部系统仍会变化。Rollback application version 可能遇到 schema incompatibility。平台需要 migration policy、backward-compatible contract 和 data recovery，不能把 Git 式体验机械套在所有状态上。

本章小结

好的 MVP 固定正确的外部抽象，允许内部暂时低效；好的基础设施产品则继续通过 Day 100 和 Day 1000，吸收项目复杂度并保持运营信任。

职业与研究：在真实系统中制造 novel constraints

学生问 Rauch 是否后悔过早进入工业界而没有走传统研究路线。他的回答不是“工业优于学术”，而是自己在公司里参与 scheduler、placement、load balancer、metadata store 等研究型工作。真实产品可以提供高规模、强约束和即时反馈；但他也承认过多 DIY 会杀死 startup。

Applied research 的三个必要条件

问题包含现有方法不能满足的明确 constraint；
团队能构建实验、测量和失败反馈，而不是只写生产补丁；
研究结果能回到产品指标，同时保留可复用知识和系统边界。

“自己写一遍”不是默认教育路线

重写 React、Kubernetes 或 scheduler 可以建立深层理解，也可能浪费公司 runway。应选择与核心差异化直接相关、现成方案无法满足约束的层；其余部分优先复用，并通过源码阅读、实验和故障演练学习。

\teachervoice{课堂真正有张力的地方是两句话同时成立：too much DIY can kill you；unreasonable standards can create novel research. 成熟判断不在“全部买”或“全部造”，而在知道哪个约束值得用组织生命去解决。}

本章小结

工业系统可以成为研究环境，但前提是问题约束、实验反馈和产品价值清晰。Build vs. Buy 同样适用于个人学习：深挖关键层，复用非关键层。

总结与延伸

核心结论

十二条可迁移结论

Hyperscaler primitives 与 application intent 之间仍需要编译层。
抽象必须创造新不变量，而不是只给控制台换皮。
产品对象的基数和生命周期决定资源映射是否经济。
FDI 用框架语义生成 IR，再映射为 routing、cache 和 functions。
ISR 按内容变化频率而非访问频率消耗 origin compute。
Build vs. Buy 应把自研放在 insight 会复利的差异化层。
Immutable deployment 与可变 pointer 让 preview、promote 和 rollback 可组合。
Consumption pricing 只有可归因时才成为开发者反馈信号。
Telemetry 要把版本、性能、错误和 spend 放在同一时间线。
Soft cap 保护学习与连续性，hard cap 保护最坏支出但可能中断业务。
AI workload 要区分 active CPU 与 I/O wait，compute density 不能靠固定 pod 数。
Day 1 获得采用，Day 100 吸收复杂度，Day 1000 赢得运营信任。

实践作业：设计一个 framework-aware AI deployment platform

选择一个 AI web application，例如多模型聊天、coding agent、文档分析或生成式电商页面，完成以下设计：

定义 framework 能提供的应用语义，以及平台无法自动推断的业务约束；
设计 Build Output / IR，列出 assets、functions、routes、cache、tools 和 policies；
给出 immutable deployment、domain pointer、preview 和 rollback 模型；
将请求分为 CPU-bound、I/O-bound、streaming 和 background 四类，设计 capacity policy；
设计 telemetry schema，把 deployment version、latency、error、model token、CPU、memory 和 spend 关联起来；
设计 soft/hard controls，说明阈值、执行延迟、业务连续性和 abuse handling；
分别写出 Day 1、Day 100、Day 1000 的验收测试。

验收标准

高质量方案不会只写“用 serverless 自动扩缩容”。它应说明 framework intent 如何进入 IR，调度器如何区分 active compute 与 wait，成本如何归因到 operation，hard control 如何避免误伤，以及 rollback 遇到 stateful dependency 时如何处理。

拓展阅读

Vercel, Framework-Defined Infrastructure。
Vercel, Announcing the Build Output API 与 Build Output API v3。
Vercel, Life of a Vercel request: Application-aware routing。
Next.js, Incremental Static Regeneration。
Vercel, Introducing Fluid Compute 与 current documentation。
Vercel, Spend Management 与 Observability。
v0, Documentation。

建议阅读路线

先读 FDI 与 Build Output API，画出“源码—框架语义—IR—部署”的编译边界；再读 request routing 与 ISR，追踪一个请求怎样命中 metadata、cache、function 和 origin。随后阅读 Spend Management 与 Observability，把监控项映射到课堂的 consumption feedback。最后阅读 Fluid Compute，并用 active CPU / wall time 比例解释为什么 AI request 改变了 serverless 的调度目标。阅读每个官方页面时，统一记录输入契约、生成或管理的资源、可观测信号、失败/回滚路径，以及当前版本与历史课堂的差异；若页面没有明确 failure mode，再主动补写可能的控制面、数据面和计量风险。