Resolver 是什么?

对于：

import Button from "@/components/Button";

JavaScript 引擎实际上只看到了 这些：

specifier = "@/components/Button"

接下来需要解决的问题是：

specifier
    ↓
真实模块

这个过程称为 Resolution。

Node.js ESM 规范中的入口算法：

ESM_RESOLVE(specifier, parentURL)

本质就是完成这个映射过程。

Node 默认支持哪些 specifier

Node 原生 Resolver 只支持四类：

import "./foo.js"
import "../foo.js"
import "/app/foo.js"

路径模块。

import react from "react"

包模块。

import db from "#db"

Package Imports。

import x from "file:///app/a.js"

URL 模块。

除此之外：

import x from "@/utils"

Node 无法解析。

直接进入：

Module Not Found

异常路径。

为什么 Alias 可以工作

假设存在：

import Button from "@/components/Button"

Webpack 配置：

resolve: {
  alias: {
    "@": "/project/src"
  }
}

Webpack 在执行真正解析前：

@/components/Button

先经过 Alias Resolver：

/project/src/components/Button

随后再进入正常模块解析。

因此 Alias 并不是一种新的模块类型。

而是：

旧 specifier
    ↓
新 specifier

的一次转换。

Vite Alias

Vite：

resolve: {
  alias: {
    "@": path.resolve(__dirname, "src")
  }
}

执行流程与 Webpack 完全一致。

对于：

import x from "@/utils/request"

Vite 首先执行：

@ -> /project/src

得到：

/project/src/utils/request

然后继续执行后续解析。

因此：

Webpack Alias
Vite Alias
Rspack Alias

本质是同一个东西。

区别只是 Resolver 实现不同。

TypeScript Paths 为什么经常失效

配置：

{
  "compilerOptions": {
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

很多人会发现：

VSCode 正常
TypeScript 正常
Node 运行失败

原因是：

paths

不是运行时 Resolver。

TypeScript 只会在：

类型检查
IDE 跳转
编译阶段

使用 paths。

Node 运行时根本不会读取：

tsconfig.json

因此：

{
  "paths": {}
}

无法让 Node 识别：

import "@/utils"

必须额外配置：

Webpack Alias
Vite Alias
Rspack Alias
Node Loader

其中之一。

Node Loader 如何实现 Alias

Node 提供：

export async function resolve(
  specifier,
  context,
  nextResolve
)

允许接管解析过程。

例如：

export async function resolve(
  specifier,
  context,
  nextResolve
) {
  if (specifier.startsWith("@/")) {
    return {
      url: pathToFileURL(
        path.resolve(
          process.cwd(),
          "src",
          specifier.slice(2)
        )
      ).href,
      shortCircuit: true
    }
  }

  return nextResolve(specifier, context)
}

此时：

import x from "@/utils"

会变成：

file:///project/src/utils.js

然后进入正常加载流程。

Browser Import Map

浏览器没有：

node_modules

因此：

import React from "react"

无法工作。

Import Map 的作用：

<script type="importmap">
{
  "imports": {
    "react": "/vendor/react.js"
  }
}
</script>

执行：

import React from "react"

时。

浏览器先映射：

react
    ↓
/vendor/react.js

再继续加载。

Resolver 的本质

观察：

Webpack Alias
Vite Alias
Rspack Alias
TS Paths
Node Loader
Import Map

会发现它们都在做同一件事：

specifier
    ↓
mapping
    ↓
new specifier
    ↓
real URL

区别仅在于：

映射规则存放的位置不同

模块图的起点

对于：

import App from "./App"

编译器首先执行：

specifier
    ↓
resolver
    ↓
real module

得到：

App.tsx

然后继续递归：

App.tsx
    ↓
Button.tsx
    ↓
request.ts
    ↓
...

最终构建：

Module Graph

Tree Shaking、Code Splitting、HMR、Chunk 拆分全部建立在这个图之上。

因此 Resolver 是整个现代前端工具链真正的入口。

Finished reading? Leave a comment

Node.js ESM 解析算法（Resolution Algorithm）的职责只有两个：

1. 将 import 中的 specifier 解析为最终 URL
2. 判断该 URL 对应的模块格式

例如：

import react from "react";
import util from "./utils.js";
import config from "#config";

Node.js 最终需要得到：

react      -> file:///project/node_modules/react/index.js
./utils.js -> file:///project/src/utils.js
#config    -> file:///project/src/config/index.js

以及：

module
commonjs
json
wasm

等模块格式。

整个 ESM 规范本质上是在描述：

specifier
    ↓
resolved URL
    ↓
module format
    ↓
load
    ↓
execute

一、ESM_RESOLVE 总体流程

Node.js ESM 的入口算法：

ESM_RESOLVE(specifier, parentURL)

可以简化为：

判断 specifier 类型

URL
路径
#imports
裸包名

        ↓

解析得到 URL

        ↓

检查文件是否合法

        ↓

判断模块格式

        ↓

返回给 Loader

整个算法的核心目标：

specifier
      ↓
唯一 URL

而不是像 CommonJS 那样不断猜测。

二、specifier 分类

Node.js 将 specifier 分为四类。

1. URL Specifier

例如：

import x from "file:///app/src/a.js";

或者：

import x from "data:text/javascript,export default 1";

如果本身是合法 URL：

new URL(specifier)

成功。

那么直接返回。

2. Relative Specifier

例如：

import x from "./foo.js";
import y from "../bar.js";

Node.js 根据当前模块位置解析。

假设：

file:///app/src/main.js

执行：

import "./utils.js";

得到：

file:///app/src/utils.js

本质上就是：

new URL("./utils.js", parentURL)

3. Package Imports

例如：

import db from "#db";

或者：

import logger from "#utils/logger";

以：

#

开头。

会进入：

PACKAGE_IMPORTS_RESOLVE()

读取当前包：

{
  "imports": {
    "#db": "./src/db/index.js",
    "#utils/*": "./src/utils/*.js"
  }
}

例如：

import db from "#db";

最终得到：

./src/db/index.js

4. Bare Specifier

例如：

import react from "react";

import lodash from "lodash";

import axios from "axios";

既不是：

URL
路径
#import

就属于裸包名。

进入：

PACKAGE_RESOLVE()

开始查找 node_modules。

三、PACKAGE_RESOLVE

这是 Node.js 查找 npm 包的核心逻辑。

例如：

import react from "react";

当前文件：

/app/src/pages/home/index.js

Node.js 会不断向上查找：

/app/src/pages/home/node_modules/react
/app/src/pages/node_modules/react
/app/src/node_modules/react
/app/node_modules/react
/node_modules/react

直到找到。

等价于：

while(currentDirectory){
    查找 node_modules/packageName
    找不到继续向上
}

四、读取 package.json

找到包以后：

node_modules/react/package.json

Node.js 开始读取配置。

优先级如下：

exports
    ↓
main
    ↓
直接路径

五、exports 机制

现代 Node.js 包解析几乎完全依赖 exports。

例如：

{
  "exports": {
    ".": "./dist/index.js",
    "./jsx-runtime": "./dist/jsx-runtime.js"
  }
}

允许：

import React from "react";

对应：

.

得到：

./dist/index.js

允许：

import jsx from "react/jsx-runtime";

对应：

./jsx-runtime

得到：

./dist/jsx-runtime.js

但是：

import internal from "react/internal";

如果 exports 中不存在：

"./internal"

则报错：

Package Path Not Exported

六、exports 的本质

exports 可以理解为：

包对外暴露的公开 API

例如：

{
  "exports": {
    ".": "./dist/index.js",
    "./api": "./dist/api.js"
  }
}

允许：

import x from "my-lib";
import y from "my-lib/api";

禁止：

import z from "my-lib/dist/internal.js";

即使文件真实存在。

七、Conditional Exports

exports 不一定是字符串。

可以是对象。

例如：

{
  "exports": {
    ".": {
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs",
      "default": "./dist/index.js"
    }
  }
}

Node.js 会根据条件选择。

ESM：

import x from "lib";

匹配：

"import"

得到：

./dist/index.mjs

CommonJS：

require("lib");

匹配：

"require"

得到：

./dist/index.cjs

八、PACKAGE_SELF_RESOLVE

假设：

{
  "name": "my-lib",
  "exports": {
    ".": "./src/index.js",
    "./core": "./src/core.js"
  }
}

当前代码就在：

my-lib

内部。

那么：

import core from "my-lib/core";

不会去外部 node_modules 查找。

Node.js 会发现：

当前包名就是 my-lib

直接使用当前 package.json 的 exports。

这就是：

PACKAGE_SELF_RESOLVE

九、imports 机制

imports 和 exports 很像。

区别：

exports 给别人用
imports 给自己用

例如：

{
  "imports": {
    "#db": "./src/db/index.js",
    "#utils/*": "./src/utils/*.js"
  }
}

之后：

import db from "#db";

实际解析：

./src/db/index.js

再例如：

import stringUtil from "#utils/string.js";

得到：

./src/utils/string.js

十、Pattern Match

imports 和 exports 支持通配符。

例如：

{
  "exports": {
    "./features/*": "./src/features/*.js"
  }
}

执行：

import user from "pkg/features/user";

匹配：

*

得到：

user

最终：

./src/features/user.js

十一、PACKAGE_TARGET_RESOLVE

这是 exports/imports 真正执行映射的地方。

支持四种类型。

String

{
  "exports": {
    ".": "./dist/index.js"
  }
}

直接解析。

Object

{
  "exports": {
    ".": {
      "node": "./node.js",
      "browser": "./browser.js",
      "default": "./index.js"
    }
  }
}

根据 conditions 选择。

Array

{
  "exports": {
    ".": [
      "./native.js",
      "./fallback.js"
    ]
  }
}

前一个失败。

继续尝试下一个。

null

{
  "exports": {
    "./internal/*": null
  }
}

明确禁止导出。

十二、ESM_FILE_FORMAT

URL 定位完成后。

Node.js 需要判断：

这个文件应该按什么格式加载？

.mjs

module

.cjs

commonjs

.json

json

.wasm

wasm

.node

addon

原生扩展模块。

十三、type 字段的作用

对于：

.js

文件。

Node.js 会查找最近的 package.json。

例如：

{
  "type": "module"
}

那么：

app.js

被解释为：

ESM

如果：

{
  "type": "commonjs"
}

则：

app.js

被解释为：

CommonJS

因此：

.mjs

永远 ESM。

.cjs

永远 CommonJS。

.js

取决于 type。

十四、为什么 ESM 不支持目录导入

CommonJS：

require("./foo");

Node.js 会尝试：

foo.js
foo.json
foo.node
foo/index.js
foo/index.json

ESM：

import "./foo";

不会猜。

如果：

foo

是目录。

直接报错：

Unsupported Directory Import

正确写法：

import "./foo/index.js";

或者：

import "./foo.js";

十五、LOOKUP_PACKAGE_SCOPE

Node.js 如何找到最近的 package.json？

算法：

当前目录
      ↓
父目录
      ↓
继续向上
      ↓
直到根目录

例如：

/app/src/pages/home/index.js

查找：

/app/src/pages/home/package.json
/app/src/pages/package.json
/app/src/package.json
/app/package.json

找到第一个就停止。

十六、自定义 ESM Resolver

Node.js 默认解析：

import x from "./a.js";
import y from "react";

如果想支持：

import x from "@/utils";

怎么办？

答案：

Loader Hook

例如：

import { pathToFileURL } from "node:url";
import path from "node:path";

export async function resolve(
  specifier,
  context,
  nextResolve
) {
  if (specifier.startsWith("@/")) {
    return {
      url: pathToFileURL(
        path.resolve(
          process.cwd(),
          "src",
          specifier.slice(2)
        )
      ).href,
      shortCircuit: true
    };
  }

  return nextResolve(specifier, context);
}

运行：

node --loader ./loader.mjs app.js

之后：

import util from "@/utils.js";

就会自动映射：

src/utils.js

十七、完整解析链路

Node.js ESM 解析可以总结为：

import specifier
        ↓
ESM_RESOLVE
        ↓
判断类型

URL
路径
#imports
裸包名

        ↓

PACKAGE_RESOLVE

        ↓

exports
imports
main

        ↓

得到最终 URL

        ↓

ESM_FILE_FORMAT

        ↓

module
commonjs
json
wasm

        ↓

Loader

        ↓

Execute

总结

Node.js ESM 的核心思想不是“寻找文件”。

而是：

specifier
      ↓
确定 URL
      ↓
确定模块格式
      ↓
加载执行

整个 exports、imports、type、conditional exports、loader 机制，本质上都是围绕这一目标构建的。

ESM 解析模型相比 CommonJS 更严格、更静态、更接近浏览器，也更适合现代工具链（Vite、Webpack、Rspack、Rollup、Turbopack）进行分析和优化。

Finished reading? Leave a comment

最近在看 C++、Rust、Go 的编译过程。

刚开始最容易被一堆名词卡住：

• GCC
• Clang
• LLVM
• AST
• IR
• SSA
• MIR
• GIMPLE
• RTL
• Linker
• Loader

单独看每个词，好像都能理解一点。但把它们放到一张图里，就很容易乱。

后来我发现，问题不在于名词太多，而在于没有从一段真实程序出发。

编译器不是简单地“把源码翻译成汇编”。更准确地说，它是在不断降低程序的抽象层级：

人类写的源码
    ↓
结构化表示
    ↓
语义明确的表示
    ↓
适合优化的表示
    ↓
接近机器的表示
    ↓
机器可以执行的二进制

每一层中间表示，都是为了让某一类问题变得更容易处理。

下面用一段很小的 C++ 程序，把主流编译链路串起来。

extern "C" int printf(const char*, ...);

#define INC(x) ((x) + 1)

int add(int a, int b) {
    return a + b;
}

int main() {
    int x = INC(add(1, 2));
    printf("%d\n", x);
    return 0;
}

这段代码故意保留了几个点：

宏：INC
函数调用：add
外部符号：printf
C++ 符号：add 会发生 name mangling
链接阶段：printf 需要从 C 标准库解析
优化空间：add(1, 2) 和 INC 可以被优化成常量

一个小程序，基本够覆盖主流编译流程。

1. 源码不是编译器真正想要的东西

程序员看到的是：

int x = INC(add(1, 2));

人很容易理解它大概等价于：

int x = ((add(1, 2)) + 1);

但编译器不能一开始就这么理解。

源码只是字符流：

i n t 空格 x 空格 = 空格 I N C ...

编译器必须先把字符处理成更稳定的结构。

这也是为什么现代编译流程不会从源码直接跳到汇编。源码适合人读，不适合机器分析。

2. 预处理：C/C++ 最早的一层文本系统

C/C++ 的第一步通常是预处理。

clang++ -E main.cpp -o main.ii

预处理器主要处理：

#include
#define
#ifdef
#pragma

在这段程序里，最明显的是：

#define INC(x) ((x) + 1)

预处理后，核心代码会变成类似这样：

int main() {
    int x = ((add(1, 2)) + 1);
    printf("%d\n", x);
    return 0;
}

这一步有个很重要的认知：

预处理不是语义分析。

它不理解类型。

它不知道 add 是不是函数。

它也不知道 INC(add(1, 2)) 是否合理。

它只是按照规则展开文本。

这也是 C/C++ 宏容易制造问题的原因。宏不是函数，它不会遵守函数那套类型检查和作用域规则。

例如：

#define SQUARE(x) x * x

如果写：

SQUARE(1 + 2)

会被展开成：

1 + 2 * 1 + 2

而不是：

(1 + 2) * (1 + 2)

很多 C/C++ 的奇怪问题，其实还没进入真正编译阶段，只是在预处理阶段就已经埋雷了。

3. 词法分析：把字符切成 Token

预处理后，编译器开始做词法分析。

源码片段：

int x = ((add(1, 2)) + 1);

会被切成类似：

keyword      int
identifier   x
operator     =
punctuator   (
punctuator   (
identifier   add
punctuator   (
literal      1
punctuator   ,
literal      2
punctuator   )
punctuator   )
operator     +
literal      1
punctuator   )
punctuator   ;

这一步只负责“切词”。

它知道 int 是关键字。

知道 x 是标识符。

知道 1 是数字字面量。

但它还不知道：

x 是局部变量
add 是函数
printf 是外部函数
1 能不能传给 add

这些都不是词法分析负责的。

可以用 Clang 看 Token：

clang++ -Xclang -dump-tokens -fsyntax-only main.cpp

如果编译错误里出现非法字符、字符串没有闭合、数字字面量格式错误，通常就停在这一层附近。

4. 语法分析：从 Token 变成 AST

Token 还是线性的。

编译器需要知道程序结构。

例如：

int x = ((add(1, 2)) + 1);

语法分析后会变成一棵树，简化后大概是：

VarDecl x : int
    └── BinaryOperator +
        ├── CallExpr add
        │   ├── IntegerLiteral 1
        │   └── IntegerLiteral 2
        └── IntegerLiteral 1

这就是 AST，抽象语法树。

AST 的作用不是为了显得高级，而是为了把源码结构稳定下来。

源码是文本。

AST 是结构。

这一步之后，编译器终于知道：

这是一个变量声明
变量名是 x
初始化表达式是一个加法
加法左边是函数调用
加法右边是整数 1

但 AST 仍然不能证明程序正确。

例如：

int x = foo(1, 2);

即使 foo 根本不存在，也可以先构建 AST。

语法上没问题。

语义上才有问题。

可以用 Clang 看 AST：

clang++ -Xclang -ast-dump -fsyntax-only main.cpp

真实 C++ AST 会非常长。模板、重载、隐式转换、构造函数、析构函数都会出现在里面。

这也是 C++ 前端复杂度很高的原因。不是因为 Token 难切，也不是因为语法树难画，而是因为语义太复杂。

5. 语义分析：编译器真正开始理解程序

语义分析会处理这些问题：

add 是否存在
add 参数数量是否正确
add 参数类型是否匹配
printf 是否声明过
int x 的初始化是否合法
函数返回值是否符合声明

对这段代码来说：

int x = INC(add(1, 2));

预处理后是：

int x = ((add(1, 2)) + 1);

语义分析会确认：

add 的类型是 int(int, int)
add(1, 2) 返回 int
返回值可以和 1 做加法
结果可以赋给 int x

如果写成：

int x = add("hello", 2);

语法仍然成立。

AST 也能构建。

但语义分析会报错，因为参数类型不匹配。

很多开发者平时说“编译错误”，其实可以再细分：

语法错误：代码结构不合法
语义错误：结构合法，但意思不合法
链接错误：单个文件能编译，但最终符号找不到

这三个错误发生在完全不同的阶段。

Rust 的 Borrow Checker 也属于这个大范围。

例如：

let r;

{
    let x = 1;
    r = &x;
}

println!("{}", r);

这不是语法错误。

它的结构完全合法。

真正的问题是语义层面的：x 已经离开作用域，r 不能再引用它。

所以 Rust 的所有权、借用、生命周期，不应该理解成语法特性，而应该理解成更强的语义分析。

这也是 Rust 编译器比 Go 编译器复杂很多的原因之一。

6. AST 不适合优化，所以需要 IR

很多人第一次学编译流程，会以为：

源码
  ↓
AST
  ↓
汇编

这个模型太粗糙。

现代编译器不会长期停留在 AST 上做优化。

原因很简单：

AST 太接近源码。

例如：

int x = INC(add(1, 2));

AST 会保留很多源码结构。

但优化器真正关心的是：

这个值从哪里来
这个值被谁使用
这个计算有没有副作用
这个分支是否可达
这个变量能不能放进寄存器
这个函数能不能内联

AST 对这些问题并不友好。

所以编译器会把 AST 降低到 IR。

IR 是 Intermediate Representation，中间表示。

比如这段：

int x = INC(add(1, 2));

可以理解为降低成类似三地址码：

t1 = call add, 1, 2
t2 = t1 + 1
x = t2
call printf, "%d\n", x
return 0

这就比 AST 更适合优化。

表达式树被拆成了简单指令。

数据依赖也更清楚。

LLVM IR 会更像这样，简化后：

define i32 @_Z3addii(i32 %a, i32 %b) {
entry:
  %sum = add nsw i32 %a, %b
  ret i32 %sum
}

define i32 @main() {
entry:
  %call = call i32 @_Z3addii(i32 1, i32 2)
  %add = add nsw i32 %call, 1
  call i32 (ptr, ...) @printf(ptr @.str, i32 %add)
  ret i32 0
}

这里有几个点值得注意。

add 在 C++ 里可能会被编译成：

_Z3addii

这是 C++ name mangling。

因为 C++ 支持函数重载，链接器不能只看到一个名字 add。

例如：

int add(int, int);
double add(double, double);

这两个函数源码里都叫 add，但链接时必须区分。

而 printf 因为声明成：

extern "C" int printf(const char*, ...);

所以不会被 C++ 改名，仍然叫：

printf

这就是 extern "C" 的实际意义之一：控制符号名，方便和 C ABI 对接。

7. 优化：编译器开始改写程序

如果不开优化，编译器会比较忠实地保留程序结构。

如果打开优化：

clang++ -O2 -S -emit-llvm main.cpp -o main.ll

这段代码很可能被优化成类似：

define i32 @main() {
entry:
  call i32 (ptr, ...) @printf(ptr @.str, i32 4)
  ret i32 0
}

add(1, 2) 没了。

INC 展开后的 + 1 也没了。

x 也没了。

最后只剩：

printf("%d\n", 4)

这不是编译器乱改代码。

这是它证明了这些改写不会改变可观察行为。

这里发生了几类典型优化：

函数内联：add(1, 2) 被展开
常量折叠：1 + 2 + 1 变成 4
死代码删除：中间变量 x 不再需要

如果看过 Java JIT、Go SSA、Rust LLVM 优化，会发现这些优化名字经常重复出现。

原因很简单：程序优化的基本问题是相通的。

8. SSA：现代优化器为什么喜欢“变量只赋值一次”

SSA 是理解现代编译器优化的关键。

SSA，全称 Static Single Assignment。

意思是每个变量在静态程序里只赋值一次。

看这个例子：

int f(bool cond) {
    int x = 1;

    if (cond) {
        x = 2;
    }

    return x;
}

普通代码里，x 被赋值两次。

控制流一复杂，优化器就很难判断某个位置的 x 到底来自哪里。

SSA 会把它变成类似：

x1 = 1

if cond goto then else merge

then:
  x2 = 2
  goto merge

merge:
  x3 = phi(x1, x2)
  return x3

这里的：

phi(x1, x2)

表示：

如果从未进入 if 的路径来，x3 = x1
如果从 then 分支来，x3 = x2

SSA 的价值在于，它把“变量会变化”这件事变成了显式的数据流关系。

这对优化非常重要。

例如：

常量传播
死代码删除
公共子表达式消除
循环不变代码外提
值编号
逃逸分析

都会受益于 SSA。

LLVM IR 是 SSA 形式。

Go 编译器内部使用 SSA。

HotSpot C2 也使用接近 SSA 的 Sea of Nodes IR。

很多数据库优化器虽然不叫 SSA，但也会维护类似的数据依赖关系。

这不是某个编译器的小技巧，而是现代优化系统的基础方法。

9. 后端：从平台无关 IR 到机器相关 IR

LLVM IR 仍然是平台无关的。

比如：

%sum = add i32 %a, %b

这句话没有指定：

x86 用哪条指令
ARM 用哪条指令
结果放哪个寄存器
参数从哪里来
调用约定是什么

这些都是后端的问题。

后端要处理：

指令选择
寄存器分配
指令调度
调用约定
栈帧布局
目标平台 ABI

同一个加法，在 x86-64 下可能是：

mov eax, edi
add eax, esi
ret

在 ARM64 下可能是：

add w0, w0, w1
ret

IR 相同，目标机器不同，最终指令就不同。

这也是 LLVM 的价值所在。

语言实现者只要生成 LLVM IR，就可以复用 LLVM 的后端能力。

否则每写一门语言，都要自己支持：

x86-64
ARM64
RISC-V
Windows ABI
Linux ABI
macOS ABI
寄存器分配
指令选择
调试信息
异常处理

这几乎不现实

10. 目标文件：机器码还不是最终程序

后端生成汇编后，汇编器会生成目标文件：

clang++ -c main.cpp -o main.o

main.o 里面有机器码，但它还不是完整程序。

可以用：

nm main.o

看到符号。

可能会看到类似：

0000000000000000 T _Z3addii
0000000000000010 T main
                 U printf

含义大概是：

_Z3addii 已定义
main 已定义
printf 未定义

U printf 不是错误。

它只是说：当前目标文件里没有 printf 的实现，链接阶段需要去别的地方找。

这就是很多人第一次遇到 undefined reference 时容易误解的地方。

它不是语法错误。

也不是类型错误。

它是链接阶段的符号解析失败。

11. 链接：把分散的二进制拼成一个程序

链接器做的事情可以粗略理解为：

main.o
  +
libc
  +
启动代码
  +
运行时库
  ↓
可执行文件

它要解决：

符号解析
地址分配
重定位
静态库选择
动态库记录
入口点设置

如果写 C++，还会涉及：

name mangling
ODR
模板实例化
静态初始化
异常表
RTTI
虚表

比如：

undefined reference to `foo'

说明链接器找不到 foo 的实现。

multiple definition of `foo'

说明多个目标文件都提供了同一个强符号。

undefined reference to `_Z3addii'

说明 C++ 符号名对不上，可能是声明和定义不一致，也可能是 C/C++ ABI 混用出了问题。

链接器是独立于编译器前端的另一个大系统。

很多大型 C++ 工程的构建问题，其实不是编译器问题，而是链接器问题。

12. 加载：程序运行前，操作系统还要接手

执行：

./a.out

也不是 CPU 直接从 main 开始跑。

Linux 下大致会经历：

内核读取 ELF
映射程序段到虚拟内存
加载动态链接器
加载共享库
处理重定位
初始化运行时
调用 main

程序的内存布局大致包括：

.text     代码段
.rodata   只读数据
.data     已初始化全局变量
.bss      未初始化全局变量
heap      堆
stack     栈

所以严格说，完整链路不是：

源码 → 可执行文件

而是：

源码 → 目标文件 → 可执行文件 → 进程

编译器解决“怎么生成程序”。

链接器解决“怎么合成程序”。

加载器解决“怎么把程序变成进程”。

13. Clang、LLVM、GCC 应该怎么放在一张图里

现在再看这些名字，就清楚很多。

Clang + LLVM 是这样：

C++ Source
    ↓
Clang Frontend
    ↓
Clang AST
    ↓
LLVM IR
    ↓
LLVM Optimizer
    ↓
LLVM Backend
    ↓
Object File
    ↓
Linker
    ↓
Executable

GCC 是另一条链路：

C++ Source
    ↓
GCC C++ Frontend
    ↓
GENERIC
    ↓
GIMPLE
    ↓
GIMPLE SSA
    ↓
RTL
    ↓
GCC Backend
    ↓
Object File
    ↓
Linker
    ↓
Executable

这两条链路解决的是同一类问题，但内部表示不同。

Clang 不是 LLVM 的别名。

LLVM 也不是 Clang 的别名。

更准确地说：

Clang 是 C/C++/Objective-C 前端。
LLVM 是中端和后端基础设施。
GCC 是另一套完整编译器系统。

对应关系可以这样记：

Clang 负责读懂 C++。
LLVM 负责优化和生成机器码。
GCC 自己既有前端，也有中端和后端。

14. Rust 为什么有 HIR、MIR，又为什么用 LLVM

Rust 的流程大致是：

Rust Source
    ↓
AST
    ↓
HIR
    ↓
THIR
    ↓
MIR
    ↓
Borrow Check
    ↓
LLVM IR
    ↓
LLVM Backend
    ↓
Machine Code

Rust 这几层不是为了显得复杂。

每层都有明确责任。

AST 接近源码。

HIR 会把一些语法糖和表层结构降下来，让程序形态更稳定。

THIR 更适合类型检查后的表达式分析。

MIR 是 Rust 很关键的一层，适合表达控制流、move、borrow、drop、生命周期等语义。

LLVM IR 则负责进入通用优化和机器码生成阶段。

这里要注意一个区分：

MIR 是 Rust 语义层的 IR。
LLVM IR 是机器代码生成层的 IR。

Borrow Checker 不能直接依赖 LLVM IR。

因为 LLVM IR 已经太低级，Rust 的 ownership、borrow、drop 语义在那一层已经不适合作为主要分析对象。

也不能直接依赖 AST。

因为 AST 太接近语法表面，语法糖太多，不适合做严格的数据流和控制流分析。

所以 Rust 需要 MIR。

这就是中间表示真正的价值：不是多一层抽象，而是为特定分析提供合适的程序形态。

15. Go 为什么看起来简单很多

Go 的编译流程大致是：

Go Source
    ↓
Parser
    ↓
AST
    ↓
Type Check
    ↓
SSA
    ↓
Go Backend
    ↓
Machine Code

Go 默认不走 LLVM。

它有自己的 SSA 和后端。

这和 Go 的设计目标有关。

Go 语言本身刻意保持简单：

没有模板元编程
没有复杂宏系统
没有 Rust 那种 ownership 检查
没有 C++ 那种重载和隐式规则

所以 Go 编译器可以更直接。

这也是 Go 编译速度快的一个重要原因。

当然，“简单”不是说 Go 编译器没有技术含量。

Go 的逃逸分析、内联、SSA 优化、栈增长、GC 相关元数据生成，都有不少工程细节。

但和 C++、Rust 相比，Go 前端语义复杂度确实低很多。

16. 为什么现代编译器总在发明新的 IR

到这里，基本可以回答最初的问题。

为什么 GCC 有 GIMPLE 和 RTL？

为什么 LLVM 有 LLVM IR、SelectionDAG、Machine IR？

为什么 Rust 有 HIR、THIR、MIR？

为什么 Go 有 SSA？

因为没有一种表示适合所有阶段。

AST 适合表示源码结构。

HIR 适合消除表层语法。

MIR 适合表达语言语义和控制流。

LLVM IR 适合做平台无关优化。

Machine IR 适合做寄存器分配和指令调度。

RTL 适合 GCC 后端描述接近机器的操作。

同一段程序，在不同阶段要被看成不同的东西。

对人来说，它是业务逻辑。

对前端来说，它是语法树。

对类型系统来说，它是约束集合。

对优化器来说，它是数据流图。

对后端来说，它是指令选择和寄存器分配问题。

对链接器来说，它是符号和重定位记录。

对加载器来说，它是 ELF 段和动态库依赖。

编译器的复杂性，正是来自这些视角之间的切换。

17. 真正需要记住的主流流程

如果只保留主流路径，不陷入全部细节，可以记成这条线：

源码
  ↓
预处理
  ↓
Token
  ↓
AST
  ↓
语义分析
  ↓
IR
  ↓
SSA
  ↓
优化
  ↓
目标相关 IR
  ↓
汇编 / 目标文件
  ↓
链接
  ↓
可执行文件
  ↓
加载执行

对应到几个主流编译器：

Clang/LLVM:
C++ → Clang AST → LLVM IR → LLVM Backend → Object

GCC:
C++ → GENERIC → GIMPLE SSA → RTL → Object

Rust:
Rust → AST/HIR/THIR → MIR → LLVM IR → Object

Go:
Go → AST → Type Check → SSA → Go Backend → Object

这张图比单独背 AST、IR、SSA 更有用。

因为它告诉你每个系统在同一条工业流水线里的位置。

18. 学这套东西对工程有什么用

这不是纯理论。

遇到宏问题，你知道去看预处理结果：

clang++ -E main.cpp

遇到语法和语义问题，你知道它发生在前端：

clang++ -Xclang -ast-dump -fsyntax-only main.cpp

想看优化前后的差异，你知道去看 LLVM IR：

clang++ -O0 -S -emit-llvm main.cpp -o main_O0.ll
clang++ -O2 -S -emit-llvm main.cpp -o main_O2.ll

遇到符号找不到，你知道看目标文件：

nm main.o

想看 ELF 结构：

readelf -a a.out

想看汇编：

objdump -d a.out

这些工具不是为了炫技。

它们对应的是编译流程中的不同阶段。

能定位阶段，问题就已经解决了一半。

19. 编译器真正有价值的地方

编译器最有价值的地方，不是几个术语，而是一种看复杂系统的方法。

一个复杂输入，不会被直接执行。

它会先变成某种中间表示。

然后被分析、约束、优化、降低，最后才进入执行层。

这个模式不只存在于编译器里。

数据库会把 SQL 变成逻辑计划和物理计划。

JVM 会把字节码变成内部 IR，再交给 JIT 优化。

React 会把 UI 更新组织成 Fiber 结构。

Kubernetes Scheduler 会把调度请求变成资源约束和评分模型。

这些系统看起来不一样，但底层思路很接近：

输入不是直接执行的。
先建立表示。
再基于表示做分析和优化。
最后执行。

编译器只是这个思想最经典、最完整的版本。

如果能把 C++、Rust、Go、GCC、LLVM 这条线看懂，再回头看 JVM、数据库、前端框架、调度系统，很多设计就不再是孤立的名词了。

Finished reading? Leave a comment

最近排查了一个 Spring 启动问题，异常并不陌生：

Bean with name 'xxx' has been injected into other beans
in its raw version as part of a circular reference,
but has eventually been wrapped.

第一眼看到的时候，我的反应是：

• 三级缓存失效了？
• AOP 出问题了？
• Spring Bug？
• 代理创建顺序异常？

因为按我的理解，既然已经通过三级缓存解决了循环依赖，那么最终拿到的对象和提前暴露出去的对象应该是同一个。

结果一路跟源码，最后发现根本不是这么回事

问题现场

依赖关系非常简单：

A
↓
B
↓
Repository
↓
A

形成循环依赖。

Spring 启动过程中成功进入三级缓存。

调试发现：

Early Reference：

UserRepository

最终 Bean：

UserRepository$$SpringCGLIB$$0

明显已经被代理。

也就是说：

Early Bean != Final Bean

这正是异常的来源。

第一怀疑对象：事务代理

看到 CGLIB 的第一反应就是：

@Transactional

于是一路跟到：

AbstractAutoProxyCreator

查看：

getEarlyBeanReference()

和：

postProcessAfterInitialization()

结果发现一个奇怪的现象。

整个生命周期中：

findEligibleAdvisors()

只执行了一次。

而且只发生在：

getEarlyBeanReference()

阶段。

说明：

事务代理并不是最终代理来源

第一条线索断掉。

如何确定是谁创建了最终代理

查看最终代理对象：

Object bean = applicationContext.getBean("userRepository");

Advised advised = (Advised) bean;

for (Advisor advisor : advised.getAdvisors()) {
    System.out.println(advisor);
}

结果发现：

PersistenceExceptionTranslationAdvisor

真凶出现了。

一个经常被忽略的代理

这个 Advisor 来自：

PersistenceExceptionTranslationPostProcessor

很多人可能没注意过它。

当 Spring 发现：

@Repository

时，会自动创建异常翻译代理。

例如：

@Repository
public class UserRepository {
}

原始异常：

SQLException
PersistenceException
HibernateException

会被转换成：

DataAccessException
DuplicateKeyException

统一 Spring 数据访问异常体系。

真正的问题

继续跟源码。

事务代理对应的：

AbstractAutoProxyCreator

实现了：

SmartInstantiationAwareBeanPostProcessor

因此支持：

getEarlyBeanReference()

所以事务代理可以做到：

Early Bean = Proxy
Final Bean = Proxy

但是：

PersistenceExceptionTranslationPostProcessor

只是普通：

BeanPostProcessor

它根本不会参与：

getEarlyBeanReference()

只会在：

postProcessAfterInitialization()

阶段执行。

于是整个流程变成：

Bean 创建
↓
加入三级缓存
↓
发生循环依赖
↓
获取 Early Bean
↓
拿到原始对象
↓
初始化完成
↓
PersistenceExceptionTranslationPostProcessor
创建代理
↓
Final Bean 变成代理对象

最终：

Early Bean != Final Bean

Spring 检测到对象身份发生变化，直接抛异常。

为什么事务代理可以，异常翻译代理却不行？

跟到这里的时候，我也产生过一个疑问。

既然 Spring 已经有 Early Proxy 机制：

getEarlyBeanReference()

为什么异常翻译代理不走这一套？

继续往下看 Spring Framework 的实现后发现：

这其实是一个设计取舍。

Spring 只会为：

影响 Bean 核心行为

的代理提供 Early Proxy。

例如：

@Transactional
@Aspect
@Cacheable

这些代理如果失效，业务逻辑会直接出错。

因此必须保证：

Early = Final

而：

@Repository

异常翻译只是附加能力。

没有它：

SQLException

一样可以正常抛出。

因此 Spring 认为没有必要为了这种场景增加整个容器复杂度。

Spring 是如何避免重复代理的

在：

AbstractAutoProxyCreator

中有这样一段逻辑：

public Object getEarlyBeanReference(
        Object bean,
        String beanName) {

    Object cacheKey = getCacheKey(bean.getClass(), beanName);

    this.earlyProxyReferences.put(cacheKey, bean);

    return wrapIfNecessary(bean, beanName, cacheKey);
}

随后：

public Object postProcessAfterInitialization(
        Object bean,
        String beanName) {

    Object cacheKey = getCacheKey(bean.getClass(), beanName);

    if (this.earlyProxyReferences.remove(cacheKey) != bean) {
        return wrapIfNecessary(bean, beanName, cacheKey);
    }

    return bean;
}

如果已经在 Early 阶段创建过代理：

Early Proxy

那么 Final 阶段就不会再次代理。

保证：

Early Bean == Final Bean

但是：

PersistenceExceptionTranslationPostProcessor

根本不参与这套机制。

因此无法保证一致性。

根因

最终定位发现：

@Repository

标注的 Bean 参与了循环依赖。

循环依赖期间：

三级缓存暴露的是原始对象

初始化完成后：

PersistenceExceptionTranslationPostProcessor
再次包装代理

导致：

Raw Bean 被注入
Final Bean 变成 Proxy

最终触发 Spring 的一致性检查。

解决方案

优先级从高到低：

方案一：拆除循环依赖（推荐）

Service
↓
Repository

不要形成：

Service
↓
Repository
↓
Service

这是根治方案。

方案二：非 DAO 不要滥用 @Repository

很多项目喜欢：

@Repository
public class XxxManager {
}

实际上并不访问数据库。

这种应该改成：

@Component

或者：

@Service

即可。

方案三：使用 @Lazy

@Autowired
@Lazy
private UserRepository repository;

避免提前创建

方案四：关闭异常翻译（一般不推荐）

移除：

PersistenceExceptionTranslationPostProcessor

或者对应自动配置。

一个容易忽略的知识点

很多人以为：

Spring 三级缓存解决了循环依赖
=
所有代理都能正常工作

实际上并不是。

更准确的说法应该是：

Spring 三级缓存
只能保证支持 Early Proxy 的代理机制正常工作

对于：

PersistenceExceptionTranslationPostProcessor
MethodValidationPostProcessor
部分 Async/Scheduled 后处理器
自定义 BeanPostProcessor

如果它们只在：

postProcessAfterInitialization()

阶段创建代理，

那么循环依赖场景下仍然可能出现：

Early Bean ≠ Final Bean

从而触发 Spring 的一致性校验异常。

总结

这次问题最大的收获其实不是解决了循环依赖。

而是搞清楚了一个以前一直模糊的认知：

Spring 三级缓存
≠
解决所有循环依赖问题

真正准确的说法应该是：

Spring 三级缓存
只能解决支持 Early Proxy 的循环依赖问题

对于那些只在 Bean 初始化完成后才创建代理的 BeanPostProcessor：

postProcessAfterInitialization()

仍然可能出现：

Early Bean ≠ Final Bean

而这，正是那个异常背后的真正原因。

Finished reading? Leave a comment

很多人学习 Kubernetes 网络时，一上来就接触：

• Pod
• Service
• Ingress
• CNI
• Flannel
• Calico

结果越学越乱。

真正的问题在于：

Kubernetes 网络并不是一个独立体系，而是建立在 Linux 网络之上的一层抽象。

如果不了解 Linux 网络，那么 Pod、Service、VXLAN 这些概念都会变成黑盒。

一、网络世界只有三个核心概念

整个网络可以抽象成三件事：

设备
地址
转发

对应：

设备：
网卡
交换机
路由器

地址：
MAC
IP

转发：
交换
路由
NAT

二、MAC 与 IP

MAC 地址

MAC 是二层地址。

00:11:22:33:44:55

作用是在同一个局域网内定位设备。

IP 地址

IP 是三层地址。

192.168.1.10
10.244.1.2
8.8.8.8

作用是跨网络定位设备。

三、交换机、ARP、路由器

交换机工作在二层，只看 MAC 地址，不看 IP、TCP、HTTP。

ARP 负责：

IP -> MAC

路由器工作在三层：

查看目标 IP
↓
查路由表
↓
决定下一跳

路由表示例：

ip route

192.168.1.0/24 dev eth0
default via 192.168.1.1

含义：

同网段直接发送
其他流量交给默认网关

四、NAT

私网地址不能直接在公网路由：

192.168.x.x
172.16.x.x
10.x.x.x

所以路由器会做 SNAT：

SRC 192.168.1.10
↓
SRC 公网 IP

并通过 conntrack 记录连接映射，用于回包恢复。

五、Linux Network Namespace

Namespace 是 Linux 的隔离机制。

Network Namespace 隔离的是一整套网络栈：

网卡
IP
路由表
ARP 表
iptables
端口空间

所以容器不是虚拟机，而是：

普通 Linux 进程
+
Namespace 隔离
+
Cgroups 限制
+
RootFS 文件系统

六、veth Pair

Namespace 之间需要连接，Linux 提供了 veth pair。

vethA <====> vethB

它像一根虚拟网线：

从 vethA 发出的包，会从 vethB 出来
从 vethB 发出的包，会从 vethA 出来

七、Linux Bridge

Bridge 是软件交换机。

ContainerA
   |
 Bridge
   |
ContainerB

它和物理交换机一样：

学习 MAC
查 MAC 表
转发数据帧

八、Docker 网络

Docker 默认网络结构：

Container
  eth0
    │
veth
    │
docker0
    │
Host

其中 docker0 是 Linux Bridge，同时被 Docker 配置了 IP：

docker0 = 172.17.0.1

所以 docker0 既是交换机，也是容器默认网关。

Docker 自己维护 IPAM：

172.17.0.0/16

容器 IP 通常由 Docker 分配：

172.17.0.2
172.17.0.3
172.17.0.4

九、Pod 是什么

Pod 不是容器。

一个 Pod 里可以有多个容器：

Pod
├── app
└── sidecar

真正持有网络命名空间的是 pause container。

pause container
└── Network Namespace

app
└── 加入 pause 的 Network Namespace

sidecar
└── 加入 pause 的 Network Namespace

所以同一个 Pod 内多个容器共享：

IP
localhost
端口空间

十、Kubernetes 单节点网络

很多 CNI 会在 Node 上创建类似 docker0 的网桥，比如：

cni0

结构：

PodA
  |
veth
  |
cni0
  |
veth
  |
PodB

同节点 Pod 通信时：

PodA ARP 查询 PodB MAC
↓
cni0 广播
↓
PodB 回复
↓
cni0 根据 MAC 表转发

这个过程本质是二层交换。

十一、CNI 是什么

Kubernetes 本身不直接实现网络。

它通过 CNI 插件处理 Pod 网络。

常见 CNI：

Flannel
Calico
Cilium

CNI 负责：

创建 veth
配置 IP
配置路由
接入 Bridge 或其他数据平面
维护跨节点通信

Pod IP 通常由 CNI 的 IPAM 模块分配，不是 Kubernetes 或 Linux 自动分配。

十二、跨节点 Pod 通信

假设：

Node1
PodA = 10.244.1.2

Node2
PodB = 10.244.2.2

PodA 访问 PodB：

10.244.1.2 -> 10.244.2.2

问题是：

Node1 怎么知道 10.244.2.0/24 在 Node2？

这就是 CNI 要解决的问题。

十三、VXLAN

VXLAN 是：

L2 Overlay over L3

意思是：

把二层网络封装到三层 IP 网络里面

原始 Pod 包：

SRC 10.244.1.2
DST 10.244.2.2

经过 VXLAN 封装：

Outer IP:
SRC Node1IP
DST Node2IP

UDP

VXLAN Header

Inner IP:
SRC 10.244.1.2
DST 10.244.2.2

包结构：

Outer Ethernet
Outer IP
UDP
VXLAN
Inner Ethernet
Inner IP
TCP
HTTP

中间物理网络只看到：

Node1IP -> Node2IP

Node2 收到后解 VXLAN，再把原始 Pod 包送给 PodB。

十四、flannel.1 是什么

flannel.1 不是进程。

它是 Linux VXLAN 网络设备。

类似：

eth0
docker0
cni0
vethxxx

路由表里：

10.244.2.0/24 dev flannel.1

意思是：

去 10.244.2.0/24 的流量
交给 flannel.1 这个 VXLAN 设备处理

然后 Linux 内核负责 VXLAN 封装。

flanneld 才是进程，它负责：

创建 flannel.1
写路由表
维护 Node 和 PodCIDR 的映射

十五、Service 的本质

Service 提供稳定访问入口。

例如：

Service IP = 10.96.0.10

但这个 IP 通常不是某张真实网卡上的 IP。

Service 本质是：

虚拟 IP
+
iptables / IPVS 转发规则

十六、kube-proxy

kube-proxy 监听：

Service
Endpoint / EndpointSlice

然后生成转发规则。

例如：

10.96.0.10:8080
↓ DNAT
10.244.1.2:8080

所以访问 Service 时，真实过程是：

访问 Service IP
↓
iptables / IPVS 命中规则
↓
DNAT 到某个后端 Pod IP
↓
通过 CNI 网络转发到目标 Pod

十七、CoreDNS

Pod 内访问服务名：

curl user-service

解析过程：

user-service
↓
CoreDNS
↓
Service ClusterIP
↓
kube-proxy
↓
Pod IP

十八、Ingress

Ingress 是规则，不是真正的网关进程。

真正处理流量的是 Ingress Controller，比如：

Nginx Ingress Controller
Traefik
APISIX
Kong

外部请求链路：

Browser
↓
LoadBalancer / NodePort
↓
Ingress Controller
↓
Service
↓
Pod

Ingress Controller 通常是七层反向代理，会解析：

Host
Path
TLS
HTTP Header

十九、完整链路总结

Linux 网络基础：

MAC
↓
ARP
↓
交换机
↓
路由器
↓
路由表
↓
NAT

容器网络基础：

Namespace
↓
veth
↓
Bridge
↓
IPAM
↓
Docker 网络

Kubernetes 网络：

Pod
↓
CNI
↓
PodCIDR
↓
cni0 / route / eBPF
↓
VXLAN / BGP
↓
Service
↓
CoreDNS
↓
Ingress

二十、最终结论

Kubernetes 网络不是凭空出现的新体系。

它本质是：

Linux 网络能力
+
CNI 自动化
+
Kubernetes 声明式编排

更具体地说：

Kubernetes 网络
=
Namespace
+
veth
+
Bridge
+
Route
+
NAT
+
iptables / IPVS
+
VXLAN / BGP / eBPF
+
CNI

理解 Kubernetes 网络，正确路径不是先背 Pod、Service、Ingress，而是先理解：

Linux 如何转发一个包
容器如何拥有自己的网络栈
Pod 如何通过 CNI 接入网络
跨节点 Pod 如何通过 VXLAN 或路由互通
Service 如何通过 DNAT 找到后端 Pod
Ingress 如何作为七层入口转发流量

Finished reading? Leave a comment

一、完整脚本，复制到bash终端运行

#!/usr/bin/env bash
set -e

echo "==> Setup zsh + Oh My Zsh + powerlevel10k"

# 1. zsh
if ! command -v zsh >/dev/null 2>&1; then
  echo "Install zsh..."
  brew install zsh
fi

# 2. oh-my-zsh
if [ ! -d "$HOME/.oh-my-zsh" ]; then
  echo "Install oh-my-zsh..."
  sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended
fi

ZSH_CUSTOM=${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}

# 3. plugins
install_plugin () {
  if [ ! -d "$ZSH_CUSTOM/plugins/$1" ]; then
    git clone --depth=1 "$2" "$ZSH_CUSTOM/plugins/$1"
  fi
}

install_plugin zsh-autosuggestions https://github.com/zsh-users/zsh-autosuggestions
install_plugin zsh-syntax-highlighting https://github.com/zsh-users/zsh-syntax-highlighting

# 4. theme
if [ ! -d "$ZSH_CUSTOM/themes/powerlevel10k" ]; then
  git clone --depth=1 https://github.com/romkatv/powerlevel10k \
    "$ZSH_CUSTOM/themes/powerlevel10k"
fi

# 5. tools
if command -v brew >/dev/null 2>&1; then
  brew install fzf zoxide >/dev/null 2>&1 || true
  $(brew --prefix)/opt/fzf/install --all >/dev/null 2>&1 || true
fi

# 6. config
cat > ~/.zshrc <<'EOF'
export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="powerlevel10k/powerlevel10k"

plugins=(
  git
  zsh-autosuggestions
  zsh-syntax-highlighting
)

source $ZSH/oh-my-zsh.sh

command -v zoxide >/dev/null 2>&1 && eval "$(zoxide init zsh)"
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
EOF

# 7. default shell
if [ "$SHELL" != "$(which zsh)" ]; then
  chsh -s "$(which zsh)"
fi

echo "Done. Restart terminal or run: source ~/.zshrc"
echo "Run: p10k configure"

包含

• zsh
• Oh My Zsh
• powerlevel10k
• autosuggestions / syntax-highlighting
• fzf / zoxide

使用

# 自动补全
git → 按 →

# 历史搜索
Ctrl + R

# 跳目录
z project

# git
gst / gco / gp

初始化主题

p10k configure

Finished reading? Leave a comment

做过「Markdown → 图片」的，应该都踩过这个坑：

Markdown → HTML → 浏览器 → 截图

然后你就会遇到：

• chromium 很重（部署麻烦）
• 分页不稳定（每次结果都可能不一样）
• 批量渲染性能很差
• serverless 环境基本不好搞 我最近有点受不了这套链路，就自己写了一个： marknative

核心思路（和常规方案完全不一样）

不走 HTML，不走 DOM，不走浏览器。

而是：

Markdown → AST → 自定义文档模型 → layout → 分页 → canvas 绘制

简单理解：

把“浏览器排版”这件事，自己实现了一套极简版本（只针对 Markdown）。

能干什么？

1. 直接输出 PNG / SVG

import { renderMarkdown } from 'marknative'

const pages = await renderMarkdown('# Hello')

await Bun.write('page-1.png', pages[0].data)

不需要：

• puppeteer
• headless chrome
• 截图

2. 天然支持分页（而且是稳定的）

默认就是：

• 1080 × 1440
• 类似卡片比例 而且分页是 deterministic 的：
• 同一份 Markdown
• 任意环境
• 渲染结果一致

3. 适合批量生成内容

比如：

• 小红书卡片
• 技术文章配图
• AI 自动生成内容图 相比 puppeteer：
• 启动更快
• 内存更低
• 更容易横向扩展

这个方向值得做

本质上，这类需求其实是：

“结构化文本 → 可控排版 → 图像输出” 但浏览器：

• 太通用（为网页设计）
• 不可控（CSS + layout 太复杂）
• 成本太高 而 Markdown 场景：
• 结构固定
• 可约束
• 非常适合做“专用排版引擎”

技术点（简单说几个有意思的）

• 用 micromark + mdast 做解析
• 自己实现 block / inline layout
• 用 skia-canvas 直接绘制
• layout 和 render 完全解耦 所以理论上可以
• 换 renderer（SVG / PDF / WebGL）
• 做自定义主题系统
• 做可视化编辑器（未来）

项目地址

👉 https://github.com/liyown/marknative

Finished reading? Leave a comment

claude 最近更新了交互是 UI，可以在聊天框流式输出可交互的页面 claude：

同时看到一个叫 Generative-UI-MCP 的项目，作者的想法很直接：用 MCP 协议把 Claude 能生成可交互 UI 这套东西复刻出来。

这个项目本身不复杂，但它把一件平时很难说清楚的事拆开了：Claude 这种交互式 UI，真正新在哪里；它为什么不像“AI 帮你写了一段前端代码”那么简单；以及它背后最先要解决的，到底是渲染问题，还是协议问题。

我后来又对着一段真实的 SSE 流式输出日志，把整个过程重新拆了一遍。两边对起来之后，会更清楚：Claude 风格的流式 UI，本质上不是“模型输出 HTML”，而是“模型持续输出一个宿主能够可靠消费的 UI 协议”。

这篇文章想讲的，就是这件事。

它是一个可持续交互UI 页面

Claude 这波交互式 UI / Artifacts，真正新的地方不是“AI 生成了一个页面”，那个早就有人做过了。新的地方在于：生成出来的东西还能继续用，还能继续跟模型交互，还能挂工具、更新状态。

这跟“AI 写了段前端代码，你复制出去跑”是完全不同的东西。

以前那种方式，模型是起点，生成完就结束了。现在这种方式，模型是这个 UI 会话里的持续参与者。用户在界面上的操作可以再回到模型，模型返回的新内容可以局部更新界面，来回转。

这个闭环大概长这样：

sequenceDiagram

actor U as 用户

participant UI as Widget UI

participant Host as 宿主 / Host

participant Tool as 工具 / API

participant LLM as 模型 / LLM



U->>UI: 点击、输入、操作

UI->>Host: emit(action, payload)



alt 前端可直接处理

Host->>UI: 更新本地状态

else 需要调工具

Host->>Tool: 调用业务接口

Tool-->>Host: 返回结果

Host->>UI: 局部更新

else 需要再问模型

Host->>LLM: 当前状态 + action

LLM-->>Host: 新内容 / 新 widget

Host->>UI: 增量插入或局部替换

end

这个循环跑得起来，才是真正的“交互式”。带几个按钮的 HTML 不叫交互式，事件能回流才叫。

一段真实的流式输出，能把这件事看得很清楚

如果看一段真实的 SSE 流式输出，会发现模型并不是一次性吐出一个完整页面，而是在流里持续输出不同类型的内容块，前端边收边拼，拼完再交给对应工具渲染。

拆开之后，大概是五步。

第一步：先加载 UI 生成规范

模型一开始并没有直接生成 widget，而是先调用了一个类似 visualize:read_me 的工具，输入参数非常短：

{

"modules": ["diagram", "interactive"]

}

这一步很关键。它说明模型在真正开始“画界面”之前，先去拿一份运行时 UI 规范。也就是说，生成不是裸奔的，模型先要知道这次该遵守什么规则。

第二步：工具返回一整套设计系统和流式输出约束

这份返回内容里，有几段特别关键。

先是模块说明：

Call read_me again with the modules parameter to load detailed guidance:

- `diagram` — SVG flowcharts, structural diagrams, illustrative diagrams

- `mockup` — UI mockups, forms, cards, dashboards

- `interactive` — interactive explainers with controls

- `chart` — charts, data analysis, geographic maps (Chart.js, D3 choropleth)

- `art` — illustration and generative art

然后是角色定义：

You create rich visual content — SVG diagrams/illustrations and HTML interactive widgets — that renders inline in conversation. The best output feels like a natural extension of the chat.

接着是它最关键的几条约束：

### Philosophy

- Seamless: Users shouldn't notice where claude.ai ends and your widget begins.

- Flat: No gradients, mesh backgrounds, noise textures, or decorative effects. Clean flat surfaces.

- Compact: Show the essential inline. Explain the rest in text.

- Text goes in your response, visuals go in the tool.

还有专门面向流式渲染的顺序规则：

### Streaming

Output streams token-by-token. Structure code so useful content appears early.

- HTML: <style> (short) → content HTML → <script> last.

- SVG: <defs> (markers) → visual elements immediately.

- Prefer inline style="..." over <style> blocks.

- Gradients, shadows, and blur flash during streaming DOM diffs. Use solid flat fills instead.

如果只看表面，这像一份设计规范；但从运行角度看，它其实更像一份“让模型输出稳定 UI 消息”的生成协议。

它在做几件事：

• 规定什么该出现在工具里，什么该出现在自然语言里

• 规定代码要按什么顺序流式吐出来

• 规定哪些视觉效果会破坏流式体验，所以禁止使用

• 规定组件必须适配宿主环境，比如 CSS 变量、深色模式、受控脚本能力

也就是说，这不是“给模型一些审美建议”，而是在给模型划一条窄轨道。

真正的关键，不是 HTML，而是模型输出的结构

随后模型开始调用另一个工具，比如 visualize:show_widget。这一段流最容易让人误解，因为它看起来像一堆零碎碎片：

event: content_block_delta

data: {"type":"content_block_delta","index":2,"delta":{"type":"input_json_delta","partial_json":"-2-2L"}}

单看这种片段，几乎没有可读性。但它们其实不是乱码，而是工具调用参数的一部分。宿主会把同一个 block 下不断到来的 partial_json 拼起来，最后还原成一个完整 JSON。

像这次，重组之后大概是这样：

{

"title": "ui_icons_outline",

"loading_messages": [

"Sketching icon paths...",

"Adding hover magic...",

"Lining up the grid..."

],

"i_have_seen_read_me": true,

"widget_code": "..."

}

这里面每个字段都很有意思。

title 是这次 widget 的标识。loading_messages 不是装饰，而是在把“等待”转成可感知的生成过程。i_have_seen_read_me 则像一个状态确认，表明模型是在已经读过规范的前提下生成的。

而真正的界面，都放进了 widget_code。

这一步揭示了流式 UI 的核心事实：模型不是直接输出最终页面，而是在输出一个宿主可以消费的 UI 消息。

为什么 Generative-UI-MCP 这个项目看起来很小，却很有价值

我原本以为要复刻 Claude 交互式 UI，需要很多东西：自定义渲染器、状态管理、完整前端运行时、组件库、DSL。

结果 Generative-UI-MCP 的核心极简得有点反直觉：

• 一个 load_ui_guidelines 工具，按需给模型加载 UI 生成规范

• 一个 system prompt 资源，把最基础的输出约束提前注入

没有大而全的组件系统，也没有复杂 DSL。

这个取舍反而很能说明问题：复刻 Claude 交互式 UI，最先要解决的不是“怎么渲染”，而是“怎么让模型输出一个宿主能稳定消费的结构”。渲染反而是后面的事。

所以这件事首先是协议问题，不是渲染问题

Claude 的交互式 UI 有一个很强的体验特征：widget 的出现是稳定、可预期的。不会这次变成代码块，下次又变成自然语言夹 HTML。

要做到这件事，不能靠模型“自觉”，只能靠协议。

Generative-UI-MCP 暴露出来的，正是这层东西：

• widget 要用专用 fence 包裹

• fence 里必须是结构化 JSON

• widget_code 字段里装 HTML 或 SVG

• 解释文本必须写在 widget block 外面

• 多个 widget 要拆成多个 block

• 输出顺序得适合流式渲染

这些约束堆起来，本质上已经非常接近一个轻量的 UI 消息协议。

宿主做的事情，本质上就是在这些消息之间路由。

为什么规范一定要按需加载，而不是一次性全塞进 prompt

复刻项目把 UI 规范拆成了几个模块：interactive、chart、mockup、diagram、art，需要什么再加载什么。

这不只是为了省 token，更关键的是：不同 UI 类型的约束本来就不一样。

• 图表有图表的规则

• 表单有表单的规则

• mockup 有 mockup 的规则

• diagram 有 diagram 的规则

• art 又是另一套生成方式

如果全塞进一个大 prompt，模型会被很多无关约束污染。按需加载的价值在于：只有在真正要生成某类 UI 时，模型才拿到那一类规则，输出才更稳定。

这和前面真实流里先传：

{

"modules": ["diagram", "interactive"]

}

其实是同一个思路。

流式的难点，从来不是“更快”，而是“边流边分帧”

很多人对流式的理解停留在“更快显示”。但从真实输出和复刻项目都能看出来，宿主真正要解决的是 parser。

宿主不能只是把 token 一个个打印出来。它必须知道：

• 当前是普通文本，还是 widget block

• 当前是在输出 block 起始，还是中间片段

• JSON 有没有完整闭合

• 什么时候可以直接显示文本

• 什么时候该进入收集模式

• 什么时候该把完整 widget_code 交给渲染器

整个过程大概是这样：

sequenceDiagram

participant LLM as 模型输出 (stream)

participant Parser as Stream Parser

participant Renderer as Widget 渲染器

participant UI as UI 界面



LLM->>Parser: token chunk 1..n

Parser->>UI: 普通文本直接显示



Note right of Parser: 识别到 widget fence
切换到收集模式

Parser->>Parser: 持续收集 JSON block

Parser->>Renderer: 完整 JSON
(title + widget_code)

Renderer->>UI: 挂载 HTML / SVG widget

Note right of UI: 一边生成，一边可见

Claude 那种“widget 自然浮现”的感觉，技术上并不是魔法，而是 parser 在做边流边分帧。

为什么连 <defs>、style 顺序、阴影这些细节都要管

第一次看到这类规范，很容易觉得它管得太细：

• SVG 里 <defs> 要先于图形

• HTML 里 style 在前、script 在后

• 尽量避免渐变、阴影、模糊

但这些规则不是在管审美，而是在管用户看到的每一帧是否合法。

原因很简单：

• <defs> 还没到，图形先出来，marker 和 clipPath 会先错后正

• style 太晚到，用户会先看到裸 UI，再看到样式突然补齐

• 渐变、模糊、阴影在流式 patch 过程中更容易出现跨帧不一致

Claude 输出 widget 很少出现明显抖动，不只是因为模型更强，也因为这套约束把中间态的不稳定性压下去了。

从一个真实 widget 看，这套方法到底偏向什么样的前端

在那段真实输出里，模型最终生成的是一个“25 个常用 UI 线条图标”的交互面板。它按类别展示图标，点击可以高亮，并在底部给出反馈。

从生成出来的 widget_code 可以看出几个很鲜明的取舍。

第一，布局非常简单，核心是稳定的 grid，而不是复杂的响应式技巧。

第二，样式极轻，全部基于宿主给的 CSS 变量，不写死颜色，天然适配深色模式。

第三，图标直接内联 SVG，不依赖图片资源，这样既容易流式输出，也容易在 hover 和 active 态切换颜色。

第四，JS 很短，只做本地交互，不做复杂状态管理，不请求网络，不引入框架。

这说明这类流式 UI 更像“会话中的即时交互壳”，不是完整前端应用。复杂逻辑交给模型，局部互动留在前端。

它很适合：

• 图标面板

• 对比卡片

• 轻量筛选器

• 小型图表

• 交互式解释器

• 内嵌 mockup

但不太适合：

• 超复杂业务表单

• 大型多页应用

• 重状态后台系统

• 强实时协作编辑器

因为它的优势是即时生成、即时嵌入、即时互动，不是长期运行的大型应用壳。

真实流里最后还有一个很重要的信号：文本和 UI 必须分工

在工具把 widget 渲染完之后，系统又返回了一句提示：

Content rendered and shown to the user. Please do not duplicate the shown content in text because it's already visually represented.

这句提示的价值很大。它明确告诉模型：已经渲染出来的东西，不要再重复讲一遍。

随后模型补上的自然语言也很克制，只做三件事：

• 概括这个 widget 是什么

• 告诉用户如何操作

• 提示用户下一步还能让模型做什么

这和前面 readme 里的那句：

Text goes in your response, visuals go in the tool.

正好闭环。

也就是说，Claude 风格的流式 UI，不只是“会渲染 widget”，它还在管理文本和视觉之间的职责边界。

Generative-UI-MCP 看不到的部分，反而是产品化最难的部分

老实说，看完这个复刻项目，会更清楚原版系统有哪些东西不是只靠协议就能补齐的。

1. 沙箱

模型生成的 HTML/JS 不能直接裸跑。必须有 iframe 隔离、白名单 CDN、脚本能力限制、资源权限边界。

否则模型只要生成一段恶意脚本，宿主就会出问题。

2. action 协议

用户点击之后发生什么，不能靠模型随便写 onclick 并自由决定逻辑。成熟设计更像是宿主先定义一套统一 action schema，比如：

• filter_changed

• submit_form

• request_refresh

• select_item

widget 只发动作，宿主决定本地处理、调工具，还是再问模型。

3. 增量 patch

Claude 在多轮对话里更新 widget，很多时候不是整块重生成，而是局部更新。这件事要求宿主维护状态，也要求模型知道什么时候该返回 patch，什么时候该返回完整替换。

demo 和产品级体验之间差得最多的地方，大概就在这里。

真正值得记住的一句话

看 Generative-UI-MCP 最大的收获，不是学到某个新技巧，而是更清楚地意识到：

做交互式 UI，这件事从来不是先解决渲染，而是先解决协议。

协议稳定了，才有后面的这些东西：

• 流式 parser

• widget 渲染

• 沙箱执行

• 事件回流

• 工具挂载

• 增量更新

Claude 把这条链路基本跑通了，所以它用起来不像 demo。Generative-UI-MCP 把这条链路最前面的那段逻辑开源出来了，所以这件事第一次变得足够可理解、可讨论、可拆解。

回头再看那些看似零碎的流式片段，尤其是不断出现的 input_json_delta、widget_code、tool_use，就不会再觉得它们只是噪音。它们其实正是这整套生成式 UI 协议在运行时留下的痕迹。

附录：这次流里真实出现的原始提示词

下面这部分不是整理后的模板，而是从真实流式输出里还原出的原始提示词和规范文本。

1. 模块选择

{

"modules": [

"diagram",

"interactive"

]

}

2. visualize:read_me 返回的规范文本

# Imagine — Visual Creation Suite



## Modules

Call read_me again with the modules parameter to load detailed guidance:

- `diagram` — SVG flowcharts, structural diagrams, illustrative diagrams

- `mockup` — UI mockups, forms, cards, dashboards

- `interactive` — interactive explainers with controls

- `chart` — charts, data analysis, geographic maps (Chart.js, D3 choropleth)

- `art` — illustration and generative art

Pick the closest fit. The module includes all relevant design guidance.



**Complexity budget — hard limits:**

- Box subtitles: ≤5 words. Detail goes in click-through (`sendPrompt`) or the prose below — not the box.

- Colors: ≤2 ramps per diagram. If colors encode meaning (states, tiers), add a 1-line legend. Otherwise use one neutral ramp.

- Horizontal tier: ≤4 boxes at full width (~140px each). 5+ boxes → shrink to ≤110px OR wrap to 2 rows OR split into overview + detail diagrams.



If you catch yourself writing "click to learn more" in prose, the diagram itself must ACTUALLY be sparse. Don't promise brevity then front-load everything.



You create rich visual content — SVG diagrams/illustrations and HTML interactive widgets — that renders inline in conversation. The best output feels like a natural extension of the chat.



## Core Design System



These rules apply to ALL use cases.



### Philosophy

- **Seamless**: Users shouldn't notice where claude.ai ends and your widget begins.

- **Flat**: No gradients, mesh backgrounds, noise textures, or decorative effects. Clean flat surfaces.

- **Compact**: Show the essential inline. Explain the rest in text.

- **Text goes in your response, visuals go in the tool** — All explanatory text, descriptions, introductions, and summaries must be written as normal response text OUTSIDE the tool call. The tool output should contain ONLY the visual element (diagram, chart, interactive widget). Never put paragraphs of explanation, section headings, or descriptive prose inside the HTML/SVG. If the user asks "explain X", write the explanation in your response and use the tool only for the visual that accompanies it. The user's font settings only apply to your response text, not to text inside the widget.



### Streaming

Output streams token-by-token. Structure code so useful content appears early.

- **HTML**: `<style>` (short) → content HTML → `<script>` last.

- **SVG**: `<defs>` (markers) → visual elements immediately.

- Prefer inline `style="..."` over `<style>` blocks — inputs/controls must look correct mid-stream.

- Keep `<style>` under ~15 lines. Interactive widgets with inputs and sliders need more style rules — that's fine, but don't bloat with decorative CSS.

- Gradients, shadows, and blur flash during streaming DOM diffs. Use solid flat fills instead.



### Rules

- No `` or `/* comments */` (waste tokens, break streaming)

- No font-size below 11px

- No emoji — use CSS shapes or SVG paths

- No gradients, drop shadows, blur, glow, or neon effects

- No dark/colored backgrounds on outer containers (transparent only — host provides the bg)

- **Typography**: The default font is Anthropic Sans. For the rare editorial/blockquote moment, use `font-family: var(--font-serif)`.

- **Headings**: h1 = 22px, h2 = 18px, h3 = 16px — all `font-weight: 500`. Heading color is pre-set to `var(--color-text-primary)` — don't override it. Body text = 16px, weight 400, `line-height: 1.7`. **Two weights only: 400 regular, 500 bold.** Never use 600 or 700 — they look heavy against the host UI.

- **Sentence case** always. Never Title Case, never ALL CAPS. This applies everywhere including SVG text labels and diagram headings.

- **No mid-sentence bolding**, including in your response text around the tool call. Entity names, class names, function names go in `code style` not **bold**. Bold is for headings and labels only.

- The widget container is `display: block; width: 100%`. Your HTML fills it naturally — no wrapper div needed. Just start with your content directly. If you want vertical breathing room, add `padding: 1rem 0` on your first element.

- Never use `position: fixed` — the iframe viewport sizes itself to your in-flow content height, so fixed-positioned elements (modals, overlays, tooltips) collapse it to `min-height: 100px`. For modal/overlay mockups: wrap everything in a normal-flow `
` and put the modal inside — it's a faux viewport that actually contributes layout height.

- No DOCTYPE, `<html>`, `<head>`, or `<body>` — just content fragments.

- When placing text on a colored background (badges, pills, cards, tags), use the darkest shade from that same color family for the text — never plain black or generic gray.

- **Corners**: use `border-radius: var(--border-radius-md)` (or `-lg` for cards) in HTML. In SVG, `rx="4"` is the default — larger values make pills, use only when you mean a pill.

- **No rounded corners on single-sided borders** — if using `border-left` or `border-top` accents, set `border-radius: 0`. Rounded corners only work with full borders on all sides.

- **No titles or prose inside the tool output** — see Philosophy above.

- **Icon sizing**: When using emoji or inline SVG icons, explicitly set `font-size: 16px` for emoji or `width: 16px; height: 16px` for SVG icons. Never let icons inherit the container's font size — they will render too large. For larger decorative icons, use 24px max.

- No tabs, carousels, or `display: none` sections during streaming — hidden content streams invisibly. Show all content stacked vertically. (Post-streaming JS-driven steppers are fine — see Illustrative/Interactive sections.)

- No nested scrolling — auto-fit height.

- Scripts execute after streaming — load libraries via `<script src="https://cdnjs.cloudflare.com/ajax/libs/...">` (UMD globals), then use the global in a plain `<script>` that follows.

- **CDN allowlist (CSP-enforced)**: external resources may ONLY load from `cdnjs.cloudflare.com`, `esm.sh`, `cdn.jsdelivr.net`, `unpkg.com`. All other origins are blocked by the sandbox — the request silently fails.



### CSS Variables

**Backgrounds**: `--color-background-primary` (white), `-secondary` (surfaces), `-tertiary` (page bg), `-info`, `-danger`, `-success`, `-warning`

**Text**: `--color-text-primary` (black), `-secondary` (muted), `-tertiary` (hints), `-info`, `-danger`, `-success`, `-warning`

**Borders**: `--color-border-tertiary` (0.15α, default), `-secondary` (0.3α, hover), `-primary` (0.4α), semantic `-info/-danger/-success/-warning`

**Typography**: `--font-sans`, `--font-serif`, `--font-mono`

**Layout**: `--border-radius-md` (8px), `--border-radius-lg` (12px — preferred for most components), `--border-radius-xl` (16px)

All auto-adapt to light/dark mode. For custom colors in HTML, use CSS variables.



**Dark mode is mandatory** — every color must work in both modes:

- In SVG: use the pre-built color classes (`c-blue`, `c-teal`, `c-amber`, etc.) for colored nodes — they handle light/dark mode automatically. Never write `<style>` blocks for colors.

- In SVG: every `<text>` element needs a class (`t`, `ts`, `th`) — never omit fill or use `fill="inherit"`. Inside a `c-{color}` parent, text classes auto-adjust to the ramp.

- In HTML: always use CSS variables (--color-text-primary, --color-text-secondary) for text. Never hardcode colors like color: #333 — invisible in dark mode.

- Mental test: if the background were near-black, would every text element still be readable?



### sendPrompt(text)

A global function that sends a message to chat as if the user typed it. Use it when the user's next step benefits from Claude thinking. Handle filtering, sorting, toggling, and calculations in JS instead.



### Links

`` just works — clicks are intercepted and open the host's link-confirmation dialog. Or call `openLink(url)` directly.



## When nothing fits

Pick the closest use case below and adapt. When nothing fits cleanly:

- Default to editorial layout if the content is explanatory

- Default to card layout if the content is a bounded object

- All core design system rules still apply

- Use `sendPrompt()` for any action that benefits from Claude thinking

3. visualize:show_widget 的真实参数

{

"title": "ui_icons_outline",

"loading_messages": [

"Sketching icon paths...",

"Adding hover magic...",

"Lining up the grid..."

],

"i_have_seen_read_me": true,

"widget_code": "<style>...</style>
...
<script>...</script>"

}

Content rendered and shown to the user. Please do not duplicate the shown content in text because it's already visually represented.



[This tool call rendered an interactive widget in the chat. The user can already see the result — do not repeat it in text or with another visualization tool.]

Finished reading? Leave a comment

最近我有一个很直观的感受：
这一波图像生成模型，很多已经不再只是“能画出像字的东西”，而是真的开始把字写对了。

这件事其实挺值得停下来想一下。

因为如果你回头看前两年的生图效果，会发现一个很稳定的槽点：
画面氛围、构图、光影都已经很强了，但只要图里出现招牌、海报标题、包装文案、UI 文本，基本就会露馅。英文会串字母，中文会缺部件，小字更是一塌糊涂。这个问题当时严重到什么程度？严重到不少关于视觉文本生成的论文，开头第一段就在说：现在的文生图虽然整体 fidelity 很高，但只要把视线移到 text area，破绽就非常明显。 oai_citation:0‡arXiv

但最近不太一样了。

我自己看到的一些新结果，已经不只是“偶尔能写对几个字”，而是明显能感觉到：模型在处理标题、标语、场景里的招牌文字时，稳定性比以前高了一大截。于是我就有点好奇：这事到底是怎么被解决的？
难道真的是模型大了、数据多了，所以顺手把文字问题也学会了？还是说，研究界其实已经悄悄换了一套解题思路？

我去翻了一圈近两三年的论文之后，得到的结论还挺明确的：

文字问题不是靠 prompt engineering 慢慢磨出来的，也不是模型“顺便学会”的。它本质上是被单独拿出来，当成一个专门问题重新建模了。 oai_citation:1‡arXiv

这篇文章就想顺着这个好奇心，聊清楚三件事：

1. 为什么图像生成一碰到文字就特别容易翻车；
2. 最近这些方法到底是怎么解决的；
3. 为什么我越来越觉得，这条路线最后会走向一种 glyph-first 的系统，而不是继续指望 prompt 自己长出排版能力。

先说最核心的一点：文字不是普通图像内容

我觉得理解这个问题，第一步不是去看 attention，也不是去看 OCR loss，而是先承认一件事：

文字和“云、树、衣服、墙面纹理”不是同一类对象。

普通图像内容大多是连续的。
云稍微糊一点，还是云；木纹稍微歪一点，也还是木纹。
但文字不是这样。文字是低容错的离散符号系统，一个字少一笔、错一个结构，可能立刻就不可读了。

这也是为什么早期很多模型会给人一种很微妙的感觉：
远看挺像，近看不对。
你会觉得“这里好像应该有字”，但认真一看，其实只是某种很像文字的纹理，不是可读的文字。

GlyphControl 在 2023 年就把这个问题讲得很直白：视觉文本生成不是普通 T2I 任务的自然延伸，必须引入额外的 glyph 条件信息，才能稳定生成准确文本。AnyText 也有类似判断：即便图像整体质量已经很高，一旦聚焦到文本区域，问题就会立刻暴露出来。 oai_citation:2‡arXiv

flowchart TD
    A[为什么文字特别难] --> B[文字是离散符号]
    A --> C[文字既有语义又有几何]
    A --> D[文字区域通常很小]
    A --> E[文字目标和背景目标并不一致]

    B --> B1[一笔错就可能不可读]
    C --> C1[不仅要知道写什么 还要知道长什么样]
    D --> D1[全图训练时容易被背景梯度淹没]
    E --> E1[背景追求自然连续 文字追求局部精确]

为什么以前的模型总是“像有字”，但又写不对？

如果只从模型结构上看，这个问题其实挺自然的。

传统文生图做条件注入，基本是这条路：

• 图像 latent / patch token 当 Query
• 文本 token 当 Key / Value
• 让图像在生成过程中不断去“读”文本条件

这个机制对普通语义对齐非常有效。
比如 prompt 里有 red car on snow，模型很容易学会：

• 哪些区域该看 car
• 哪些区域该看 snow
• 哪些局部更多受到 red 的影响

但问题在于，文本 token 提供的是语义，不是字形。

token “A” 并不是字母 A 的视觉结构，
token “春” 也不是“春”字的具体笔画排列。
所以如果系统只吃语义 token，它更容易学会的是：

这里应该有一段“文字感”

而不是：

这里必须是这个字符，而且要笔画对、边界清楚、相邻字符别打架

这也是为什么过去两三年的论文，几乎都在朝一个方向收敛：

别再只靠 semantic conditioning 了，要把文字从“语言提示”升级成“显式字形条件”。
GlyphControl 是这样，AnyText 是这样，FLUX-Text 是这样，TextPixs 也是这样。 oai_citation:3‡arXiv

flowchart LR
    A[仅有语义 token] --> B[告诉模型 这里应该有文字]
    B --> C[优点: 和普通 T2I 兼容]
    B --> D[缺点: 没告诉模型这个字具体长什么样]
    D --> E[结果: 容易生成伪字形/串字/错字]

    F[显式 glyph 条件] --> G[告诉模型 这里应该是这个字符形状]
    G --> H[附带位置/大小/区域信息]
    H --> I[结果: 可读性和可控性明显上升]

研究界是怎么一步步把这个问题拆开的？

如果把近几年的工作串起来看，我觉得它不是“某篇论文突然发明了一个神奇模块”，而是经历了一个挺清楚的演化过程。

第一阶段：先承认“文字生成”是一个独立问题

这一阶段最重要的，不是技术细节，而是问题被重新命名了。

GlyphControl 很关键的一点，是明确提出 visual text generation 需要 glyph-conditional control，而不是继续指望 character-aware text encoder 或更大的通用模型自己学会。论文还专门构建了 LAION-Glyph 数据集，并用 OCR-based metrics、CLIP score、FID 来评估结果。这个动作很重要，因为它等于在说：文字渲染已经值得有自己的一套 benchmark 和指标。 oai_citation:4‡arXiv

AnyText 则把这件事进一步系统化了。它不只是做文字生成，还把多语言文字生成和编辑放进同一个扩散框架里，并引入 AnyWord-3M 数据集和 AnyText-benchmark。论文里说得很清楚：文字区域的问题不能再被当成普通图像 fidelity 的附属现象，它需要独立建模。 oai_citation:5‡arXiv

换句话说，第一阶段真正发生的事是：

大家不再问“为什么模型还不会写字”，
而开始问“如果把写字当成一个专门任务，我们应该怎么表示它、训练它、评估它？”

第二阶段：从 semantic-first 走向 glyph-first

这是我觉得最关键的转折。

以前的做法，本质上是 semantic-first：
先给模型一个字符串的语义表示，然后希望它在图像空间里自己把字符外形“悟出来”。

但后来大家慢慢发现，这条路上限不高。
因为语义和字形根本不是一回事。你知道一个词的 meaning，不等于你就知道它在图上该怎么写。

所以 GlyphControl 的解法很直接：
不要只告诉模型“这里写 SALE”，还要把 SALE 的 glyph instruction 明确给它。这样用户不仅能控制文本内容，还能控制位置和大小。 oai_citation:6‡arXiv

AnyText 继续沿着这个方向往前走，它的设计里有两个特别重要的模块：

• Auxiliary latent module：吃 glyph、position、masked image，生成跟文字相关的 latent feature；
• Text embedding module：借助 OCR 模型去编码 stroke 信息，再把这些 embedding 和 caption embedding 融合起来。

这其实已经很能说明问题了：
真正有效的文字生成，不是再多喂一点 prompt，而是把字形、位置、区域这些原本没被好好表示的东西，变成模型能直接消费的条件。 oai_citation:7‡arXiv

我自己看到这里的时候，感受挺强的：
这已经不是“优化 prompt 理解”了，而是在重新定义输入空间。

flowchart TD
    A[从 prompt-only 到 glyph-first] --> B[阶段 1 只给字符串语义]
    A --> C[阶段 2 给 glyph + position + region]
    A --> D[阶段 3 再把这些条件深入注入 backbone]

    B --> B1[容易得到像文字的纹理]
    C --> C1[开始能控制字符内容/位置/大小]
    D --> D1[开始追求字符级稳定和场景一致性]

第三阶段：问题不只是“有没有 glyph”，而是“glyph 怎么进系统”

glyph conditioning 成为共识之后，研究重点就开始下沉。

大家不再争论“该不该给 glyph”，而是开始研究：

• glyph 是当额外输入就够了吗？
• 还是应该更深地改 backbone？
• 训练目标是不是也得跟着变？

FLUX-Text 是我觉得很典型的一篇。
它不是那种特别花哨的“新世界观”，但它很实在。它的思路是：在 FLUX-Fill 这种强 base model 上，用比较轻量的 glyph 和 text embedding 模块增强文字理解与生成，同时尽量保留原有生成能力。更重要的是，它显式提出了 Regional Text Perceptual Loss，就是告诉你：文字区域必须被单独优化。 oai_citation:8‡arXiv

这一点其实特别重要。

因为文字区域通常很小，如果训练目标还是全图统一的，那么大部分梯度都来自背景。模型当然会更优先学“把图做漂亮”，而不是“把字写对”。FLUX-Text 的意思某种程度上就是：
你不能一边说文字很重要，一边在损失函数里继续拿它当背景噪声的一小块。 oai_citation:9‡arXiv

第四阶段：从“词级条件”继续下钻到“字符级绑定”

再往后，问题就会变得更细。

即使你给了 glyph，也不代表字符之间不会互相干扰。
很多时候模型出的问题不再是“完全不知道写什么”，而是：

• 相邻字符粘连
• 一个字符的结构跑到另一个字符那边去
• 整串文本看起来有大概的样子，但局部字符不稳定

这时候 TextPixs 这种工作就很有意思了。

它做了几件非常针对性的事：

• 双流编码：语义文本流 + glyph 视觉流
• character-aware attention
• OCR-in-the-loop feedback
• attention segregation loss

这套东西的核心直觉很简单：
文字不是词级别对齐就够了，而是要字符级别地对齐。

普通 T2I 里，token 级控制通常已经足够。
但文字渲染不一样，字符是最终可读性的最小单位。如果字符之间的 attention 没有被稳定地分开，系统就很容易得到“这是一串字”的整体感觉，却写不对具体每个字。TextPixs 也直接把目标写得很清楚：解决 readable、meaningful、correctly spelled text 的问题。 oai_citation:10‡arXiv

flowchart LR
    A[词级/短语级条件] --> B[整体知道这里有一串文字]
    B --> C[问题: 字符边界不清 相互污染]

    D[字符级条件与注意力] --> E[每个字符更独立地绑定区域]
    E --> F[结果: 拼写更稳定 可读性更高]

第五阶段：也许模型不该负责“从头学拼写”，而该负责“把文字融合进场景”

翻到比较新的工作时，我最感兴趣的一条思路，其实不是单纯“准确率又涨了多少”，而是问题定义开始变了。

比如 TextFlux 的意思就很明显：
它强调的是 OCR-free DiT model for high-fidelity multilingual scene text synthesis，同时把重点放在 glyph accuracy 和 scene integration 上。 oai_citation:11‡arXiv

这背后有个挺大的范式变化：

• 旧问题：怎么让模型自己从语义里学会 spelling
• 新问题：怎么把可靠的字符表示自然地融进图像场景

我越来越觉得，后者可能才是更长期的方向。

因为如果你让一个通用图像模型同时承担两件事：

1. 生成复杂视觉世界
2. 还得像排版引擎一样精确输出字符

那它天然就有点拧巴。
但如果你把 spelling 这件事尽量结构化、显式化，让模型把重心放在融合——也就是风格、材质、光照、透视、边缘过渡——这条路反而更合理。

这也是为什么我现在会更愿意把这条研究线理解成：

不是“模型终于学会写字了”，
而是“系统终于不再把文字当普通纹理处理了”。

把这些方案压成一句话，其实就是三步

如果不展开细节，把这几年的路线浓缩一下，我觉得就是下面三步：

第一步：把文字从语义提示升级成字形条件

也就是从 prompt-only 走向 glyph-first。
这是 GlyphControl 和 AnyText 这类方法最早讲清楚的事。 oai_citation:12‡arXiv

第二步：把文字区域从整图里单独拎出来优化

也就是别让全图损失继续淹没文字区域。
FLUX-Text 这种 regional text loss 的思路很典型。 oai_citation:13‡arXiv

第三步：把控制粒度从词级推进到字符级，再进一步推进到场景融合级

TextPixs 代表字符级绑定这一步，后续一些工作则更强调 scene integration。 oai_citation:14‡arXiv

flowchart TD
    A[文字问题的主线解法] --> B[glyph-first]
    A --> C[region-first]
    A --> D[character-first]
    A --> E[integration-first]

    B --> B1[不只告诉模型写什么 还告诉它长什么样]
    C --> C1[文字区域单独加权优化]
    D --> D1[字符级注意力与约束]
    E --> E1[重点解决和背景如何自然融合]

我自己的感受：这可能是图像生成从“会画图”走向“能用”的一个拐点

我这次翻论文，最大的感受不是“原来某个模块这么 clever”，而是：

文字问题其实特别像一个分水岭。

过去很多视觉生成模型，主要解决的是“生成一张看起来不错的图”。
但只要场景变成海报、包装、UI、招牌、广告、知识卡片，评价标准就会立刻变化：

• 画面再美，字错了就没法用；
• 氛围再好，标题糊了就不能进生产流程；
• 文字编辑不稳定，就很难真正接入设计工作流。

所以文字渲染这件事，表面上看像个细节，实际上逼着整个系统往更工程化、更结构化的方向走。
它迫使模型回答一个过去可以回避的问题：

你到底是在生成“好看的视觉纹理”，
还是在生成“可被人类读懂和使用的信息”？

而最近这些论文给出的共同答案大概是：

如果你想生成的是后者，那就别再把文字当普通图像内容。

参考论文

[1] Yukang Yang et al., GlyphControl: Glyph Conditional Control for Visual Text Generation, NeurIPS 2023. 提出 glyph-conditional control，并构建 LAION-Glyph 与 OCR-based 评测。 oai_citation:15‡arXiv

[2] Yuxiang Tuo et al., AnyText: Multilingual Visual Text Generation and Editing, 2023/2024. 提出 auxiliary latent module、text embedding module，以及 AnyWord-3M / AnyText-benchmark。 oai_citation:16‡arXiv

[3] Rui Lan et al., FLUX-Text: A Simple and Advanced Diffusion Transformer Baseline for Scene Text Editing, 2025. 强调轻量 glyph/text embedding 与 text fidelity，并引入文字区域感知的优化思路。 oai_citation:17‡arXiv

[4] TextPixs: Glyph-Conditioned Diffusion with Character-Aware Attention and OCR-in-the-Loop Feedback for Accurate Text Rendering, 2025. 强调 dual-stream、character-aware attention、OCR-in-the-loop，以及字符级准确性。 oai_citation:18‡arXiv

Finished reading? Leave a comment

把经验写进仓库

最近读 OpenAI 那篇讲 Skills 和 Agents SDK 的文章，脑子里一直在转一个很小的问题。

我们到底是在使用 AI，还是在把自己的工作方式，一点点整理成 AI 也能接住的东西。

以前总觉得，所谓“AI 提效”，核心是模型越来越强。它会写代码，会解释报错，会总结文档，也能把一段模糊的需求翻译成还算可用的实现。可真把它放进日常工程里，事情很快又会变得具体起来。

你会发现，问题常常不是它不够聪明，而是它不知道你们平时到底怎么做事。

同样是改完代码之后的“检查一下”，有人会顺手把 format、lint、test 全跑完，有人只会跑当前模块，有人记得补 typecheck，有人则默认 CI 会兜底。
同样是准备提 PR，有人会把改动背景、影响范围和验证方式写得很清楚，有人只留下一个简短标题，像往河里扔下一颗石头，剩下的涟漪全交给 reviewer 自己理解。

这些差别，看起来像是个人习惯。可如果往下想一层，它其实是一种没有被正式写下来的经验。

而 Skills 有意思的地方就在这里。

它不是让模型再多会一点东西，也不是再给 prompt 换一个更精致的名字。它更像是在说：如果一件事会一遍遍发生，如果它背后已经有了相对稳定的做法，那为什么不把它认真写下来，写进仓库，写成一种能被调用的能力。

这件事让我有点触动。因为它不是在追求一种更炫的智能感，反而是在做一件很朴素的事：把原本只存在于人脑子里的工作习惯，慢慢整理成系统的一部分。

Skill 像什么

如果只从表面看，skill 很容易被理解成“提示词模板”。

但我越来越觉得，它更像是一个很小的工作单元。
它知道自己该在什么时候出现，知道自己要完成什么，也知道哪些地方该交给模型判断，哪些地方该交给脚本执行。

OpenAI 的文章里提到，一个 skill 通常会有自己的说明文件，也可能带着脚本、参考资料，甚至一些辅助资源。换句话说，它并不是一句轻飘飘的“帮我做这个”，而是一套被稍微整理过的经验。

我很喜欢这种感觉。

因为很多时候，团队里的知识并不是没有，只是它们以一种很松散的形式存在着。它可能藏在某个资深工程师的习惯里，藏在某次 code review 的评论里，藏在一个只被提过一次的内部约定里。你问起来，大家都知道一点；真要写下来，又总觉得“这种事不是理所当然的吗”。

可一旦要交给 Agent，很多“理所当然”就突然变得不再理所当然了。

它不会天然知道，改了这几个目录意味着什么。
它不会天然知道，某一类改动是必须完整验证的，另一类改动却只需要最小检查。
它也不会知道，你们习惯怎样描述一次改动，怎样把上下文交代给下一个接手的人。

于是 skill 的意义开始变得清楚起来。
它不是替代经验，而是在保存经验。
不是制造新的流程，而是把原来那些靠默契维持的东西，慢慢落成可以复用的形状。

真正难的，不是写“做什么”，而是写“什么时候做”

我觉得 OpenAI 那篇文章里最值得反复想的一点，是它对 skill description 的强调。

一个 skill 是否真的有用，关键不是写得多完整，而是写得够不够准。
尤其是那个“什么时候该触发”的边界。

这件事听起来很细，可其实很像平时和人协作。
真正让一段协作顺畅起来的，从来不只是步骤本身，而是时机。

如果你只说“运行验证流程”，这当然没错，但几乎没什么帮助。
因为接下来最重要的问题都还没回答：

什么样的改动算需要验证？
只是改了文档呢？
只是重命名文件呢？
如果动到了测试或者构建链路，是不是就应该升级为完整检查？
这个动作是建议性的，还是必须性的？

当这些边界没被说清楚时，一个 skill 就很容易变得像一件摆设。它存在，但不稳定；偶尔会被调用，偶尔又会被忽略。最后的问题不在模型，而在于这个能力没有真正定义好自己出现的时刻。

我会觉得，写 skill 有点像在写一种很轻的制度。
制度不是靠语气强硬，而是靠边界清楚。
什么时候该发生，什么时候不该发生，什么属于例外，什么必须执行，这些东西一旦明确了，后面的流程反而会变简单。

仓库里其实一直缺一种“写给 Agent 的文档”

文章里还提到了 AGENTS.md。这个设定我也很喜欢。

它有一点像过去我们写给新同事的 onboarding 文档，只不过这次读者不是人，而是 Agent。

仓库有自己的脾气。
目录结构是怎么分的，哪里是核心路径，哪些约定看起来不显眼却不能碰，某些模块的测试为什么要这么跑，某些 API 的行为到底应该信源码还是信文档，这些都是仓库内部的语言。

平时这些东西靠人来理解，问题也不大。人会猜，会追问，会顺着上下文补全很多隐含信息。
但 Agent 不太一样。它当然会推理，可它最怕的是那些所有人都默认存在、却没有人认真写下来的东西。

所以 AGENTS.md 给我的感觉，不是又多了一份文档，而是终于出现了一种明确的载体，去承接那些“本来应该早就写清楚”的仓库共识。

如果说 AGENTS.md 更像总说明，那 skill 就更像一个个局部工作流。
前者回答“这里是一个什么样的地方”，后者回答“在这里，某件事该怎么做”。

再往下，还有 GitHub Actions 这种更确定的自动化兜底。
这样一层层看下来，会觉得这个结构其实很顺。

人负责形成经验。
文档负责表达经验。
skill 负责调用经验。
脚本和 CI 负责执行经验。

这和我过去想象的“AI 改变工程”很不一样。它没有特别戏剧化，反而很像软件工程一直以来最熟悉的路径：把不稳定的手工操作，慢慢整理成稳定的系统行为。

模型不需要什么都做

这篇文章里还有一个我很认同的判断：模型不应该负责一切。

这件事说出来很简单，但真正做的时候，太容易贪心了。
因为模型看起来什么都能处理，于是我们会不自觉地把理解、判断、执行、格式化输出，全部揉成一团交给它。

结果通常不会太好。

需要理解上下文、做比较、做总结、做判断的事，模型很擅长。
但需要按固定顺序执行命令、收集状态、输出可预期结果的事，本质上还是脚本更适合。

这个边界一旦想清楚，很多设计问题就会顺下来。

比如判断一个改动是不是行为变更，这种事要靠模型。它需要读 diff，理解意图，也理解周边上下文。
但“先跑哪些命令、失败了该怎么汇总、从哪里收集 git 状态和分支信息”，这些就该尽量交给脚本。

我一直觉得，好的系统不是把能力堆在一个点上，而是把职责分开。
模型负责那些本来就不确定的部分。
脚本负责那些应该尽量确定的部分。

Skill 之所以让我觉得它更接近“工程”，也在这里。它没有把模型想象成一个全能的主体，而是愿意承认：真正稳定的工作流，往往来自不同能力的合作，而不是单一能力的膨胀。

说到底，Skills 在整理的是“隐性经验”

我后来越想越觉得，Skills 最值得珍惜的地方，可能不是它能提升多少效率，而是它逼着团队去面对一件平时不太愿意面对的事：我们的很多工作，其实建立在隐性经验上。

这些经验平时并不显得稀缺。
因为总有人知道。
一个团队里，总会有一些人对仓库很熟，对流程很熟，对各种“虽然没写，但大家都这么做”的东西很熟。于是问题看起来总能被解决，流程看起来总能被跑通。

可一旦团队变大，项目变复杂，或者引入 Agent，这些隐性的部分就会立刻暴露出来。

因为 AI 不会自动继承团队默契。
它也不会天然理解某些“本来不用说”的规则。

于是很多以前能被熟人网络悄悄消化掉的问题，现在都必须被明说了：

什么是必须做的？
什么只是建议？
哪些步骤必须自动化？
哪些判断仍然需要人来做？
哪些知识应该写进仓库，而不是留在聊天记录里？

这让我觉得，Skills 表面上是在帮助 Agent，实际上也在帮助团队重新认识自己。
你们到底是怎样工作的。
哪些经验是可迁移的。
哪些流程值得固化。
哪些依赖于个人记忆的地方，早就该被替换掉了。

从这个角度看，它不是一个单纯的新功能，而像一次很安静的整理。

我会从什么地方开始

如果真要在一个仓库里慢慢把 skill 建起来，我大概不会一上来就做一个很大的系统。

我更愿意从那些已经足够重复、足够明确、而且失败成本又不低的事情开始。

比如验证流程。
这几乎是最自然的一类。改动之后该跑什么、顺序是什么、哪些情况需要附加检查、失败时怎么把结果说清楚，这些都很适合被整理成 skill。它高频、重复，而且一旦依赖记忆，就特别容易漏。

再比如 PR 的整理工作。
标题怎么起，改动怎么概括，影响范围怎么交代，验证方式怎么写得让 reviewer 不费力。这种事情本身不算难，但很消耗注意力。一个好的 draft 往往就能省掉很多来回解释。

还有文档核对。
OpenAI 在文章里提到，涉及平台或 API 行为时，他们会让 Agent 去查当前文档，而不是凭记忆回答。这个原则我很喜欢。因为变化快的东西最怕“我记得好像是这样”。把“先查文档再回答”变成一种默认动作，本质上是在给系统加一个很必要的约束。

再往后，可能是发版前检查。
这种流程不一定每天发生，但一旦出错，往往会让人很后悔。版本号、changelog、示例是否可运行、release note 草稿、breaking changes 的确认，这些都很适合被慢慢沉淀下来。

它们有一个共同点：都不是创造性的工作，而是重复性的工作。
也正因为如此，它们才更值得被写进仓库。

我为什么会对这件事有一点点乐观

这几年关于 AI 的讨论很多，热闹也很多。
可越往后，我反而越容易被一些安静的东西打动。不是模型又刷新了哪个 benchmark，不是 Agent 又完成了多复杂的任务，而是像 Skills 这种，看起来没有那么耀眼，却很接近真实工作现场的设计。

它让我觉得，AI 真正进入工程，不一定是靠一次 dramatic 的替代，而更可能是靠这种缓慢的渗透：先接住一个小流程，再接住一种工作习惯，再把一种原本只存在于经验里的做法，慢慢变成仓库的一部分。

这件事的迷人之处在于，它不是在制造新的神话，而是在保存那些原本就有价值的东西。

我们一直说，软件工程是在把手工经验系统化。
某种程度上，Skills 只是把这句话继续往前推了一步。

以前我们把经验写成文档，写成脚本，写成 CI。
现在，我们开始尝试把经验写成 Agent 也能理解和使用的能力。

我挺喜欢这种变化。

因为它让我第一次觉得，Agent 不是突然闯进工程体系里的一个外来者。
它更像一个新的参与者。
而一个新的参与者，最重要的不是“它能做多少事”，而是“我们愿不愿意认真把自己的工作方式告诉它”。

说到底，skill 不是在教模型怎么工作。
它是在逼我们先想清楚，自己到底是怎么工作的。

Finished reading? Leave a comment