---
url: https://ain.hmgf.hxcn.space/lectures.md
description: 3D环梦工坊编程竞赛组课程讲义，涵盖C++基础、STL、算法、Python等编程入门到进阶内容。
---

# 编程竞赛组讲义

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson1-cpp-2025.md
description: >-
  第 1 课第 1 章：讲解 C++ 标准输入输出（cin/cout、endl、格式化输出）与常见输入陷阱，并介绍 C 风格
  I/O（printf/scanf）。
---

# 一.C++ 输入与输出基础

在 C++ 中，输入与输出（Input/Output, 简称 I/O）是程序与外界（如用户、文件、网络）交换信息的核心机制。你可以把它想象成程序与你对话的"嘴巴"（输出）和"耳朵"（输入）。

C++ 提供了两种主要的 I/O 方式：

1. **C++ 风格 I/O（`<iostream>`）**：这是 C++ 的标准方式，基于“流”（Stream）的概念，是面向对象的、类型安全的。
2. **C 风格 I/O（`<cstdio>`）**：继承自 C 语言，基于函数（如 `printf` 和 `scanf`），在某些特定场合（如算法竞赛）因其格式化能力和潜在速度而被使用。

我们将从 C++ 风格的 `<iostream>` 开始，然后介绍 C 风格的 `<cstdio>`。

## 1.C++ 标准 I/O（`<iostream>`）

要使用 C++ 风格的 I/O，你必须包含 `<iostream>` 头文件。它为你提供了两个核心对象：`cin`（标准输入流，通常是键盘）和 `cout`（标准输出流，通常是屏幕）。

### 基本输出：`cout`

`cout` 与“插入运算符”（`<<`）配合使用，将数据“插入”到输出流中。

C++

```cpp
#include <iostream> // 包含输入输出流头文件

// 'std' 是一个命名空间，cout 和 endl 都在里面。
// "using namespace std;" 可以让我们在下面直接写 cout，
// 否则你需要写 std::cout 和 std::endl。
// 在大型项目中不推荐全局使用，但在教学和简单程序中很常见。
using namespace std; 

int main() {
    // 声明并初始化一个变量
    int age = 20;
    
    // 1. 打印字符串字面量
    cout << "Hello, C++!";
    
    // 2. 打印换行符 '\n'
    // '\n' 是一个转义字符，代表换行
    cout << '\n'; 
    
    // 3. 打印变量
    cout << "Your age is: ";
    cout << age;
    cout << '\n';
    
    // 4. 链式调用：将多个输出连接在一起
    cout << "Next year, you will be: " << (age + 1) << '\n';
    
    // 5. 使用 endl (end line)
    // endl 的作用是：1. 换行 2. 刷新输出缓冲区
    // 刷新缓冲区能确保你立即看到输出，但频繁使用可能比 '\n' 慢
    cout << "Goodbye!" << endl;
    
    return 0;
}
```

**运行结果示例:**

```text
Hello, C++!
Your age is: 20
Next year, you will be: 21
Goodbye!
```

### 基本输入：`cin`

`cin` 与“提取运算符”（`>>`）配合使用，从输入流中“提取”数据并存入变量。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 声明变量，准备接收输入
    int age;
    double height;
    
    // 提示用户输入
    cout << "Please enter your age: ";
    
    // 1. 从键盘读取一个整数，存入 'age'
    // cin 会自动跳过开头的空白（空格、Tab、换行）
    // 然后读取数据，直到遇到下一个空白或无效字符
    cin >> age;
    
    cout << "Your age is: " << age << endl;
    
    // 2. 链式读取：一次读取多个值
    // cin 会按顺序等待输入
    cout << "Enter your age and height (separated by a space): ";
    cin >> age >> height;
    
    cout << "New age: " << age << ", Height: " << height << endl;
    
    return 0;
}
```

**运行结果示例 (用户输入 25，然后输入 30 1.75):**

```text
Please enter your age: 25
Your age is: 25
Enter your age and height (separated by a space): 30 1.75
New age: 30, Height: 1.75
```

***

## 2.C 风格 I/O（`<cstdio>`）

要使用 C 风格的 I/O，你需要包含 `<cstdio>` 头文件（在 C 语言中是 `<stdio.h>`）。它提供了 `printf`（格式化输出）和 `scanf`（格式化输入）等函数。

### C 风格输出：`printf`

`printf`（print formatted）函数允许你按照指定的“格式化字符串”来输出数据。

* 它通过**格式说明符**（format specifier，以 `%` 开头）来指定后续变量应被如何格式化。

| **说明符** | **类型** | **示例**                            |
| ---------- | -------- | ----------------------------------- |
| `%d`       | `int`    | 整数                                |
| `%f`       | `double` | 浮点数                              |
| `%lf`      | `double` | (在 `printf` 中 `%f` 和 `%lf` 相同) |
| `%c`       | `char`   | 单个字符                            |
| `%s`       | `char*`  | C 风格字符串                        |

C++

```cpp
#include <cstdio> // 包含 C 风格 I/O 头文件

int main() {
    int age = 20;
    double height = 1.78;
    char grade = 'A';
    char name[] = "Alice"; // C 风格字符串（字符数组）
    
    // 1. 打印普通文本，使用 \n 换行
    printf("Hello, C-style output!\n");
    
    // 2. 打印变量
    // %d 会被 age 的值替换
    printf("Age: %d\n", age); 
    
    // 3. 打印多个变量
    // 格式说明符必须与变量的类型和顺序一一对应
    printf("Name: %s, Grade: %c, Height: %f\n", name, grade, height);
    
    // 4. 格式化：控制浮点数精度
    // %.2f 表示保留两位小数
    printf("Height (2 decimal places): %.2f\n", height);
    
    return 0;
}
```

**运行结果示例:**

```text
Hello, C-style output!
Age: 20
Name: Alice, Grade: A, Height: 1.780000
Height (2 decimal places): 1.78
```

### C 风格输入：`scanf`

`scanf`（scan formatted）函数按照格式化字符串从标准输入读取数据。

**极其重要：** `scanf` 在读取数据到变量时，**必须**传递变量的**内存地址**。我们使用“取地址运算符”（`&`）来获取地址。

C++

```cpp
#include <cstdio>

int main() {
    int age;
    double height;
    
    printf("Please enter your age: ");
    
    // 1. 读取一个整数
    // 注意：我们传递的是 &age (age 的地址)，而不是 age
    // scanf 会将读取到的值放入该地址对应的内存中
    scanf("%d", &age);
    
    printf("Your age is: %d\n", age);
    
    // 2. 读取多个值
    // %lf 用于读取 double 类型
    printf("Enter your age and height (separated by a space): ");
    scanf("%d %lf", &age, &height);
    
    printf("New age: %d, Height: %.2lf\n", age, height);
    
    // 3. 读取 C 风格字符串（字符数组）
    // 特例：数组名本身就代表地址，所以不需要 &
    char name[50];
    printf("Enter your name: ");
    scanf("%s", name); // 注意：name 前没有 &
    
    printf("Hello, %s!\n", name);
    
    return 0;
}
```

**运行结果示例 (用户输入 25，然后输入 30 1.75，然后输入 Bob):**

```text
Please enter your age: 25
Your age is: 25
Enter your age and height (separated by a space): 30 1.75
New age: 30, Height: 1.75
Enter your name: Bob
Hello, Bob!
```

## 3.性能问题

**性能提示：** 在算法竞赛中，如果 I/O 量非常大，`cin`/`cout` 默认的同步可能导致超时。可以通过在 `main` 函数开头添加 `std::ios::sync_with_stdio(false); std::cin.tie(NULL);` 来关闭同步，使其速度与 `scanf`/`printf` 媲美。

***

## 4.处理整行输入（带空格的字符串）

`cin` 和 `scanf("%s", ...)` 的一个共同问题是：它们遇到**空格**就会停止读取。

### `getline`

要读取一整行（包括空格），我们使用 `getline` 函数。它需要 `<string>` 头文件。

C++

```cpp
#include <iostream>
#include <string> // 必须包含 <string> 才能使用 std::string 和 getline
using namespace std;

int main() {
    string name;
    
    cout << "Please enter your full name: ";
    
    // getline(cin, variable)
    // 它会从 cin 读取一行，存入 name，直到遇到换行符
    getline(cin, name); 
    
    cout << "Hello, " << name << "!" << endl;
    
    return 0;
}
```

**运行结果示例 (用户输入 "John Doe"):**

```text
Please enter your full name: John Doe
Hello, John Doe!
```

***

## 5.I/O 的常见陷阱和注意事项

1. scanf 忘记 &

   这是 C 风格 I/O 中最致命的错误。

   C++

   ```cpp
   int age;
   // 错误！没有 &。程序会尝试写入一个无效的内存地址
   // 极有可能导致 "段错误" (Segmentation Fault) 或程序崩溃
   scanf("%d", age); 

   // 正确
   scanf("%d", &age);
   ```

2. cin 和 getline 混用

   这是一个非常隐蔽的陷阱。

   C++

   ```cpp
   int id;
   string name;

   cout << "Enter ID: ";
   cin >> id; // 用户输入 101，然后按回车

   // 此时，'101' 被 cin 读取了，
   // 但是换行符 '\n' 仍然留在输入缓冲区中

   cout << "Enter name: ";
   // getline 立即读到了那个被留下的 '\n'
   // 它认为这一行已经结束了，所以 name 是空的
   getline(cin, name); 

   cout << "ID: " << id << ", Name: '" << name << "'" << endl;

   // 运行结果:
   // Enter ID: 101
   // Enter name: ID: 101, Name: '' 
   ```

   **解决方法：** 在 `getline` 之前，使用 `cin.ignore()` 清除缓冲区中多余的换行符。

   C++

   ```cpp
   // ...
   cin >> id; 
   cin.ignore(); // 忽略掉缓冲区里的一个字符（那个换行符）
   getline(cin, name); // 现在就可以正常工作了
   // ...
   ```

3. printf / scanf 格式与类型不匹配

   编译器通常会警告，但不会阻止你。

   C++

   ```cpp
   // 错误：用 %d (整数) 打印 %f (浮点数)
   printf("%d", 3.14); // 输出垃圾值

   // 错误：用 %f (浮点数) 打印 %d (整数)
   printf("%f", 10); // 输出垃圾值

   int x;
   // 错误：用 %f 读取整数
   scanf("%f", &x); // 结果未定义
   ```

4. scanf("%s", ...) 的缓冲区溢出

   scanf("%s", ...) 不知道你的字符数组有多大，它会一直读取直到遇到空白。

   C++

   ```cpp
   #include <cstdio>

   int main() {
       // 只能安全存储 9 个字符 + 1 个 '\0'
       char str[10]; 

       printf("Enter a long string: ");

       // 如果用户输入 "HelloWorldThisIsTooLong"
       // scanf 会写入超过 10 个字节，破坏程序内存
       // 这是一个严重的安全漏洞！
       scanf("%s", str); 

       return 0;
   }
   ```

   **解决方法：** 使用 C++ 的 `std::string` 和 `cin`，它们会自动管理内存，没有溢出风险。或者在 C 风格中指定宽度 `scanf("%9s", str);`。

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson1-cpp-2025-2-types.md
description: 第 1 课第 2 章：变量与常量、基本数据类型、类型转换、注释与命名，打好 C++ 语法与表达式基础。
---

# 二.C++ 基础：变量、数据类型、常量与注释

在构建复杂的程序之前，我们必须先了解那些最基本的“积木”：如何存储数据、数据有哪些种类、如何给它们命名，以及如何为自己（和他人）留下笔记。

## 1. 注释 (Comments)

**注释**是写给**人**看的笔记，而不是给电脑看的。C++ 编译器会完全忽略注释。注释的目的是解释代码“为什么”这么做，或者让代码更易读。

C++ 中有两种注释方式：

1. **单行注释 (`//`)**: 从 `//` 开始，直到这一行的末尾，所有内容都是注释。
2. **多行注释 (`/\* ... \*/`)**: 从 `/*` 开始，到 `*/` 结束，中间可以跨越多行，所有内容都是注释。

C++

```cpp
#include <iostream>
using namespace std;

// 这是一个单行注释。main 函数是程序的入口点。
int main() {
    
    // 下面这行代码会向控制台输出 "Hello!"
    cout << "Hello!" << endl; 
    
    /* 这是一个多行注释。
       我们可以用它来写更详细的说明。
       下面的代码（虽然被注释掉了）本可以用来...
       int x = 5; 
    */
    
    // 你也可以用多行注释来临时“关闭”一行代码的一部分
    int y = 10; /* + 5; */ // 编译器只会看到 int y = 10;
    
    cout << "y = " << y << endl;

    return 0; // 单行注释：表示程序正常结束
}
```

**运行结果示例:**

```text
Hello!
y = 10
```

## 2. 变量 (Variables)

**变量**可以看作是内存中一个贴了标签的“盒子”，专门用来存储特定类型的数据。你可以随时更改盒子里装的东西（即变量的值）。

使用变量分三步：

1. **声明 (Declaration)**: 告诉编译器你要创建一个盒子，它叫什么名字（标识符），能装什么类型的数据。
2. **初始化 (Initialization)**: 在声明盒子的**同时**，就给它放入一个初始值。（推荐！）
3. **赋值 (Assignment)**: 在声明之后，用新的值替换掉盒子里的旧值。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 1. 声明 (Declaration)
    // 创建了一个名为 age 的盒子，它只能装整数 (int)
    // 此时盒子里是“垃圾值”（未定义），使用它很危险
    int age; 
    
    // 2. 赋值 (Assignment)
    // 将值 20 放入 age 盒子
    age = 20;
    cout << "Age after assignment: " << age << endl;

    // 3. 初始化 (Initialization) - 推荐的方式
    // C-style (等号) 初始化
    int score = 100; 
    
    // C++11 统一初始化 (花括号) - 更现代、更安全
    double height{1.75}; 
    
    cout << "Initial score: " << score << endl;
    cout << "Initial height: " << height << endl;
    
    // 变量的值是可以被改变的
    score = 95; // 赋值，覆盖掉旧值 100
    cout << "Final score: " << score << endl;
    
    return 0;
}
```

**运行结果示例:**

```text
Age after assignment: 20
Initial score: 100
Initial height: 1.75
Final score: 95
```

## 3. 基本数据类型 (Basic Data Types)

**数据类型**告诉编译器一个变量（盒子）能存储什么样的数据，以及它在内存中占多大空间。

以下是 C++ 中最常用的几种基本数据类型：

| **类型** | **描述**                                                     | **示例**                                |
| -------- | ------------------------------------------------------------ | --------------------------------------- |
| `int`    | **整型**。用于存储整数（没有小数）。                         | `int age = 20;`                         |
| `double` | **双精度浮点型**。用于存储小数，精度很高。                   | `double pi = 3.14159;`                  |
| `float`  | **单精度浮点型**。也用于存储小数，但精度和范围小于 `double`。 | `float price = 19.99f;` (注意 `f` 后缀) |
| `char`   | **字符型**。用于存储**单个**字符（字母、数字、符号）。       | `char grade = 'A';` (注意用**单引号**)  |
| `bool`   | **布尔型**。用于存储逻辑值，只有 `true` 或 `false` 两种可能。 | `bool isRaining = false;`               |

**`sizeof()` 运算符**：可以用来查看某个数据类型或变量占用了多少字节（Bytes）的内存。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 整型
    int i = 123;
    // 在算法竞赛中，如果数字非常大（超过21亿），常用 long long
    long long bigNumber = 10000000000LL; 
    
    // 浮点型
    double pi = 3.14159265; // 精度高
    float gravity = 9.8f;   // 精度低，通常加 'f' 
    
    // 字符型
    char initial = 'J';
    
    // 布尔型
    bool isLoggedIn = true; // 'true' 是一个关键字
    
    // 打印值
    cout << "Integer: " << i << endl;
    cout << "Double: " << pi << endl;
    cout << "Char: " << initial << endl;
    cout << "Bool: " << isLoggedIn << endl; // cout 默认会把 true 打印成 1
    
    // 打印占用的内存大小（单位：字节）
    // 结果可能因你的系统（32位/64位）而异
    cout << "--- Memory Sizes ---" << endl;
    cout << "Size of int: " << sizeof(int) << " bytes" << endl;
    cout << "Size of double: " << sizeof(double) << " bytes" << endl;
    cout << "Size of char: " << sizeof(char) << " byte" << endl;
    cout << "Size of bool: " << sizeof(bool) << " byte" << endl;
    
    return 0;
}
```

**运行结果示例 (在 64 位系统上):**

```text
Integer: 123
Double: 3.14159
Char: J
Bool: 1
--- Memory Sizes ---
Size of int: 4 bytes
Size of double: 8 bytes
Size of char: 1 byte
Size of bool: 1 byte
```

## 4. 常量 (Constants)

**常量**和变量很像，也是一个存储数据的“盒子”，但它有一个**铁律**：一旦在初始化时放入了值，就**永远不能再被修改**。

常量用来存储那些在程序运行期间不应改变的值（如圆周率 $\pi$、数学常数、配置参数等）。

有两种定义常量的方式：

1. **`const` 关键字 (C++ 方式 - 推荐)**: 这是现代 C++ 的首选方式。它创建了一个真正的、有类型的常量。
2. **`#define` 预处理器 (C 风格方式)**: 这是一个预处理器指令。它在**编译前**会把代码中所有的 `MAX_SIZE` 文本**直接替换**为 `100`。

C++

```cpp
#include <iostream>
using namespace std;

// 方法2：#define 预处理器
// 注意：没有类型，没有分号 ;
// 在算法竞赛中常用于定义数组的最大大小
#define MAX_ARRAY_SIZE 100

int main() {
    // 方法1：const 关键字 (推荐)
    // 'const' 告诉编译器，PI 的值不能被修改
    const double PI = 3.14159; 
    const string SITE_NAME = "MyWebsite.com";
    
    cout << "Constant PI: " << PI << endl;
    cout << "Constant Site: " << SITE_NAME << endl;
    
    // 尝试修改 const 常量会导致编译错误！
    // PI = 3.14; // <-- 这行代码会报错！
    
    // #define 的使用
    int myArray[MAX_ARRAY_SIZE]; // 编译器实际看到的是 int myArray[100];
    
    cout << "Max array size: " << MAX_ARRAY_SIZE << endl;
    
    return 0;
}
```

**运行结果示例:**

```text
Constant PI: 3.14159
Constant Site: MyWebsite.com
Max array size: 100
```

### 关键点回顾：

* **注释** (`//`, `/* */`)：给开发者看的笔记，编译器会忽略。
* **变量** (`int x = 5;`)：可变的、有类型的“盒子”，用于存储数据。
* **数据类型** (`int`, `double`, `char`, `bool`)：定义了“盒子”能装什么、占多大。
* **常量** (`const double PI = 3.14;`)：不可变的“盒子”，初始化后值不能被修改。

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson1-cpp-2025-3-control-flow.md
description: >-
  第 1 课第 3 章：控制流基础，包含 if/switch 条件分支、for/while/do-while 循环，以及 break/continue
  等常用语句。
---

# 三.C++ 控制流基础

在 C++ 中，**控制流**（Control Flow）指的是程序代码执行的顺序。默认情况下，代码是从上到下、逐行执行的，这称为**顺序结构**。

然而，程序通常需要更复杂的逻辑：

1. **选择**：根据某个条件，决定执行哪一段代码。
2. **循环**：重复执行某一段代码，直到满足某个条件才停止。

控制流语句就是用来实现这些“选择”和“循环”的工具，让你能够指挥程序的执行路径。

## 1. 选择结构（Conditional Statements）

选择结构允许你的程序在“岔路口”做出决定。

### `if` 语句

`if` 语句是最基本的选择结构。如果圆括号 `()` 中的条件为 `true`，就执行花括号 `{}` 中的代码。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    int age = 18;
    
    cout << "Checking age..." << endl;
    
    // 如果 age 大于等于 18
    if (age >= 18) {
        cout << "You are an adult." << endl;
    }
    
    cout << "Check complete." << endl;
    return 0;
}
```

**运行结果示例:**

```text
Checking age...
You are an adult.
Check complete.
```

### `if-else` 语句

`if-else` 提供了一个“二选一”的路径。如果 `if` 条件为 `true`，执行 `if` 块；否则（`else`），执行 `else` 块。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    int number = 7;
    
    // 检查一个数是奇数还是偶数
    // % 是取模运算符，number % 2 == 0 意为 "number 除以 2 的余数是否为 0"
    if (number % 2 == 0) {
        cout << number << " is even." << endl;
    } else {
        cout << number << " is odd." << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
7 is odd.
```

### `if-else if-else` 语句

当你需要处理多个“岔路口”（多种可能）时，可以使用 `if-else if-else` 结构。它会按顺序检查每个条件，一旦找到一个为 `true` 的条件，就执行对应的代码块，然后跳过所有剩余的 `else if` 和 `else`。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    int score = 85;
    
    if (score >= 90) {
        cout << "Grade: A" << endl;
    } else if (score >= 80) { // 运行到这里时，score 必然 < 90
        cout << "Grade: B" << endl;
    } else if (score >= 70) { // 运行到这里时，score 必然 < 80
        cout << "Grade: C" << endl;
    } else { // 运行到这里时，score 必然 < 70
        cout << "Grade: F" << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
Grade: B
```

### `switch-case` 语句

`switch` 语句是一种特殊化的选择结构。它专门用于检查**一个变量**是否等于一系列**常量值**。

* `switch` 后面跟的 `(variable)` 是你要检查的变量（通常是整数或字符）。
* `case value:` 是你期望的常量值。
* `break;` **非常重要！** 它告诉程序在执行完这个 `case` 的代码后，立即**跳出**整个 `switch` 结构。
* **如果没有 `break;`**，程序会“穿透”到下一个 `case` 并继续执行，这通常不是我们想要的。
* `default:` 类似于 `else`，如果没有任何一个 `case` 匹配，就会执行 `default` 块。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 1=Start, 2=Load, 3=Exit
    int choice = 2; 
    
    switch (choice) {
        case 1:
            cout << "Starting new game..." << endl;
            break; // 跳出 switch
        case 2:
            cout << "Loading game..." << endl;
            break; // 跳出 switch
        case 3:
            cout << "Exiting..." << endl;
            break; // 跳出 switch
        default: // 如果 choice 不是 1, 2, 或 3
            cout << "Invalid choice." << endl;
            break;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
Loading game...
```

### 三元运算符 (?:)

这是一个 if-else 的简洁写法，常用于给变量赋值。

语法：result = (condition) ? value\_if\_true : value\_if\_false;

C++

```cpp
#include <iostream>
#include <string> // 需要 string 头文件
using namespace std;

int main() {
    int age = 20;
    string status;

    // 传统 if-else
    // if (age >= 18) {
    //     status = "Adult";
    // } else {
    //     status = "Minor";
    // }

    // 使用三元运算符
    status = (age >= 18) ? "Adult" : "Minor";

    cout << "Status: " << status << endl;
    return 0;
}
```

**运行结果示例:**

```text
Status: Adult
```

***

## 2. 循环结构（Iteration Statements）

循环结构允许你重复执行同一段代码。

### `for` 循环

for 循环是最常用的循环结构，尤其适用于当你提前知道要循环多少次时。

它由三个部分组成，用分号 ; 隔开：

1. **初始化 (init):** 循环开始前执行一次（例如：`int i = 0`）。
2. **条件 (condition):** 每次循环开始前检查（例如：`i < 5`）。如果为 `true`，执行循环体；如果为 `false`，退出循环。
3. **更新 (update):** 每次循环体执行**之后**执行（例如：`i++`，即 `i = i + 1`）。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 打印 0 到 4
    // 1. 初始化: int i = 0
    // 2. 检查: 0 < 5 (True) -> 执行 cout -> 更新: i 变为 1
    // 3. 检查: 1 < 5 (True) -> 执行 cout -> 更新: i 变为 2
    // ...
    // 5. 检查: 4 < 5 (True) -> 执行 cout -> 更新: i 变为 5
    // 6. 检查: 5 < 5 (False) -> 退出循环
    for (int i = 0; i < 5; i++) {
        cout << "i = " << i << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
i = 0
i = 1
i = 2
i = 3
i = 4
```

### `while` 循环

`while` 循环适用于**你不知道要循环多少次，只知道循环的终止条件**时。

它在每次循环开始前检查条件，只要条件为 `true`，就不断执行循环体。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    int countdown = 3;
    
    // 只要 countdown 大于 0，就继续循环
    while (countdown > 0) {
        cout << "Countdown: " << countdown << endl;
        // 必须在循环体内手动更新条件变量，否则会造成“死循环”！
        countdown--; // countdown = countdown - 1
    }
    
    cout << "Liftoff!" << endl;
    return 0;
}
```

**运行结果示例:**

```text
Countdown: 3
Countdown: 2
Countdown: 1
Liftoff!
```

### `do-while` 循环

do-while 循环与 while 循环类似，但它保证循环体至少被执行一次。

因为它先执行 do 块中的代码，然后才在 while() 中检查条件。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    int choice;
    
    // 至少执行一次菜单
    do {
        cout << "--- Menu ---" << endl;
        cout << "1. Play" << endl;
        cout << "2. Exit" << endl;
        cout << "Enter your choice: ";
        cin >> choice;
        
        if (choice == 1) {
            cout << "Playing game..." << endl;
        }
        
    // 只要用户不输入 2，就一直重复循环
    } while (choice != 2); 
    // 注意：do-while 循环末尾必须有分号 ;
    
    cout << "Goodbye!" << endl;
    return 0;
}
```

**运行结果示例 (用户输入 1，然后输入 2):**

```text
--- Menu ---
1. Play
2. Exit
Enter your choice: 1
Playing game...
--- Menu ---
1. Play
2. Exit
Enter your choice: 2
Goodbye!
```

### 范围 `for` 循环 (C++11)

这是一种现代 C++ 的写法，用于方便地遍历一个“集合”（如数组、`std::string`、`std::vector` 等）中的所有元素。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    int arr[] = {10, 20, 30, 40, 50};
    
    // 语法：for (元素类型 变量名 : 集合)
    // 循环会自动遍历 arr 中的每一个元素
    // 第一次循环, n = 10
    // 第二次循环, n = 20
    // ...
    for (int n : arr) {
        cout << n << " ";
    }
    cout << endl;
    
    return 0;
}
```

**运行结果示例:**

```text
10 20 30 40 50 
```

***

## 3. 跳转语句（Jump Statements）

跳转语句允许你无条件地改变程序的执行流程。

### `break`

`break` 语句有两个主要用途：

1. 在 `switch` 语句中，用来跳出 `switch` 块。
2. 在循环（`for`, `while`, `do-while`）中，用来**立即终止并跳出整个循环**。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 在数组中查找数字 22
    int arr[] = {64, 34, 25, 12, 22, 11, 90};
    
    for (int n : arr) {
        if (n == 22) {
            cout << "Found 22!" << endl;
            break; // 找到了，没必要继续循环，立即跳出 for 循环
        }
        cout << "Checking " << n << "..." << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
Checking 64...
Checking 34...
Checking 25...
Checking 12...
Found 22!
```

### `continue`

`continue` 语句用于循环中，它会**立即跳过当前这一次循环的剩余代码**，并直接开始**下一次循环**（即 `for` 循环的“更新”或 `while` 循环的“条件检查”）。

C++

```cpp
#include <iostream>
using namespace std;

int main() {
    // 只打印 1 到 10 之间的偶数
    for (int i = 1; i <= 10; i++) {
        // 如果 i 是奇数
        if (i % 2 != 0) {
            continue; // 跳过本次循环的 cout 语句，直接去做 i++
        }
        
        // 这行代码只有在 i 不是奇数时（即 continue 未执行时）才会运行
        cout << i << " "; 
    }
    cout << endl;
    
    return 0;
}
```

**运行结果示例:**

```text
2 4 6 8 10 
```

### `return`

`return` 语句用于**跳出整个函数**。

* 当 `return` 在 `main` 函数中被调用时，它会结束整个程序。
* 在其他函数中，它会结束该函数，并（可选地）返回一个值给调用者。

C++

```cpp
#include <iostream>
using namespace std;

// 检查年龄的函数
void checkAge(int age) {
    if (age < 0) {
        cout << "Error: Invalid age." << endl;
        return; // 发现错误，立即跳出 checkAge 函数
    }
    
    if (age >= 18) {
        cout << "Access granted." << endl;
    } else {
        cout << "Access denied." << endl;
    }
}

int main() {
    checkAge(25);
    checkAge(-5); // "Error..." 并 return
    checkAge(15); // "Access denied."
    
    return 0; // 结束 main 函数，程序终止
}
```

**运行结果示例:**

```text
Access granted.
Error: Invalid age.
Access denied.
```

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson1-cpp-2025-4-array-basics.md
description: 第 1 课第 4 章：数组基础，涵盖数组声明与初始化、下标访问与遍历，以及常见越界等注意事项。
---

# 四.数组基础

在 C++ 中，**数组（Arrays）是一种用来存储固定大小、相同类型元素**的连续内存空间的数据结构。你可以把它想象成一系列排好队的小格子，每个格子都装着同一类东西。

***

## 数组的声明和初始化

在使用数组前，我们首先要**声明**它，告诉编译器数组叫什么名字、能装多少个元素、以及元素是什么类型。**初始化**则是在声明的同时或之后给数组元素赋予初始值。

### 基本数组声明

要声明一个数组，你需要指定元素的**数据类型**、数组的**名称**以及它能容纳的**元素数量（大小）**。

```cpp
#include <iostream> 

using namespace std; 

int main() {
    // 声明一个包含5个整数的数组，名为 'numbers'
    // 此时，数组中的5个位置已经被分配，但里面的值是不确定的（通常是“垃圾值”）
    int numbers[5]; 
    
    // 初始化数组元素：逐个赋值
    // 数组的索引（下标）从0开始，这意味着第一个元素是 numbers[0]，
    // 第二个是 numbers[1]，以此类推。
    numbers[0] = 10;
    numbers[1] = 20;
    numbers[2] = 30;
    numbers[3] = 40;
    numbers[4] = 50; // 因为数组大小是5，所以最后一个元素的索引是 4 (即 5 - 1)

    // 访问数组元素：使用循环遍历并打印每个元素
    // 循环条件 i < 5 确保我们不会访问到数组范围之外的内存，
    // 因为索引最大只到 4。
    for (int i = 0; i < 5; i++) {
        cout << "numbers[" << i << "] = " << numbers[i] << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
numbers[0] = 10
numbers[1] = 20
numbers[2] = 30
numbers[3] = 40
numbers[4] = 50
```

### 数组初始化方法

C++ 提供了多种方便的方式来初始化数组，让你的代码更简洁。

```cpp
#include <iostream> 
using namespace std; 

int main() {
    // 方法1：使用初始化列表
    // 这是最常见和推荐的方式。编译器会根据列表中的元素数量自动确定数组大小，
    // 或者如果你指定了大小，它会检查是否匹配。
    int arr1[5] = {1, 2, 3, 4, 5}; 
    
    // 方法2：自动计算大小
    // 当你不确定数组需要多大，或者想让编译器帮你数时，可以省略方括号里的数字。
    // 编译器会自动计算出 arr2 的大小是 5。
    int arr2[] = {10, 20, 30, 40, 50}; 
    
    // 方法3：部分初始化（其余元素为0）
    // 如果初始化列表中的元素数量少于数组声明的大小，
    // 那么剩余的元素会自动被初始化为0。
    int arr3[5] = {1, 2, 3}; // arr3 将是 {1, 2, 3, 0, 0}
    
    // 方法4：全部初始化为0
    // 这是一个便捷的方法，将数组的所有元素都初始化为0。
    int arr4[5] = {0}; // arr4 将是 {0, 0, 0, 0, 0}
    
    // 方法5：C++11 统一初始化（推荐的现代C++写法）
    // C++11 引入了花括号 {} 作为通用的初始化方式，语法更统一，更安全。
    // 当然有些比赛（比如蓝桥杯）或者做题网站可能使用C++98、C++6之类的老引擎，这时就用不了这种方法了。
    int arr5[5]{1, 2, 3, 4, 5}; // 功能与方法1相同

    // 输出 arr1 的内容
    cout << "arr1: ";
    for (int i = 0; i < 5; i++) {
        cout << arr1[i] << " ";
    }
    cout << endl; 
    
    // 输出 arr3 的内容，观察未初始化的元素是否为0
    cout << "arr3: ";
    for (int i = 0; i < 5; i++) {
        cout << arr3[i] << " ";
    }
    cout << endl; 
    
    return 0;
}
```

**运行结果示例:**

```text
arr1: 1 2 3 4 5 
arr3: 1 2 3 0 0 
```

***

**关键点回顾：**

* **索引从0开始：** 如果数组有 N 个元素，它们的索引是 `0` 到 `N-1`。
* **固定大小：** C++ 中的普通数组一旦声明，其大小就固定了，不能在运行时改变。
* **内存连续：** 数组的元素在内存中是紧挨着存放的，这使得访问速度非常快。

***

## 多维数组

多维数组可以看作是“数组的数组”。最常见的是二维数组（如表格或矩阵）和三维数组（如立方体或空间网格）。

### 二维数组

**二维数组**就像一个表格，有行和列，横的是行，竖的是列。声明时，你需要指定行数和列数。访问元素时，则需要两个索引：`[行索引][列索引]`。

```cpp
#include <iostream>
using namespace std; 

int main() {
    // 声明并初始化一个 2x3 的二维数组 (2行, 3列)
    // 它可以被想象成：
    // [1, 2, 3]
    // [4, 5, 6]
    int matrix[2][3] = {
        {1, 2, 3}, // 第一行（索引 0）
        {4, 5, 6}  // 第二行（索引 1）
    };
    
    // 访问二维数组元素
    // 外层循环控制行，内层循环控制列
    for (int i = 0; i < 2; i++) { // 遍历行 (i 从 0 到 1)
        for (int j = 0; j < 3; j++) { // 遍历列 (j 从 0 到 2)
            cout << "matrix[" << i << "][" << j << "] = " << matrix[i][j] << endl;
        }
    }
    
    // 打印矩阵形式：更直观地显示二维数组内容
    cout << "\nMatrix:" << endl; 
    for (int i = 0; i < 2; i++) {
        for (int j = 0; j < 3; j++) {
            cout << matrix[i][j] << " "; 
        }
        cout << endl; 
    }
    
    return 0;
}
```

**运行结果示例:**

```text
matrix[0][0] = 1
matrix[0][1] = 2
matrix[0][2] = 3
matrix[1][0] = 4
matrix[1][1] = 5
matrix[1][2] = 6

Matrix:
1 2 3 
4 5 6 
```

***

### 三维数组

**三维数组**可以看作是二维数组的集合，或者说是一个“立方体”。你需要三个索引来定位一个元素：`[第一维索引][第二维索引][第三维索引]`。

> 你可以这样理解这些索引：
>
> * **第一维索引**：这相当于你**堆叠的二维数组的层数**。想象你把多个二维表格（像Excel工作表）一个接一个地叠起来，第一维索引就是用来选择你要看哪一张表格。
> * **第二维索引**：在你选定的那一张二维表格（层）里，这代表着表格的**行数**。
> * **第三维索引**：这代表着表格中具体某一行里的**列数**。

***

```cpp
#include <iostream>
using namespace std;

int main() {
    // 声明并初始化一个 2x3x2 的三维数组 (2层, 每层3行, 每行2列)
    int cube[2][3][2] = {
        // 第一层（索引 0）
        {
            {1, 2},  // 0,0,x
            {3, 4},  // 0,1,x
            {5, 6}   // 0,2,x
        },
        // 第二层（索引 1）
        {
            {7, 8},  // 1,0,x
            {9, 10}, // 1,1,x
            {11, 12} // 1,2,x
        }
    };
    
    // 访问三维数组元素：使用三层嵌套循环
    for (int i = 0; i < 2; i++) {   // 遍历第一维 (层)
        for (int j = 0; j < 3; j++) { // 遍历第二维 (行)
            for (int k = 0; k < 2; k++) { // 遍历第三维 (列)
                cout << "cube[" << i << "][" << j << "][" << k 
                     << "] = " << cube[i][j][k] << endl;
            }
        }
    }
    
    return 0;
}
```

**运行结果示例:**

```text
cube[0][0][0] = 1
cube[0][0][1] = 2
cube[0][1][0] = 3
cube[0][1][1] = 4
cube[0][2][0] = 5
cube[0][2][1] = 6
cube[1][0][0] = 7
cube[1][0][1] = 8
cube[1][1][0] = 9
cube[1][1][1] = 10
cube[1][2][0] = 11
cube[1][2][1] = 12
```

***

## 字符数组和字符串

在 C++ 中，**字符串**通常以两种方式表示：C 风格字符串（即**字符数组**）和 C++ 标准库中的 `std::string`。这里我们先关注基础的字符数组,`std::string` 将在后面的课程中学习，感兴趣的同学可以提前了解一下。

**字符数组**是 `char` 类型元素的数组，用来存储一系列字符。一个 C 风格字符串以**空字符 `\0`** 结尾，这个空字符标志着字符串的结束。

```cpp
#include <iostream>
#include <cstring> 
using namespace std;

int main() {
    // 字符数组声明和初始化
    // char str1[10] 可以存储最多9个字符 + 1个空字符\0
    char str1[10] = "Hello"; 
    // char str2[] 编译器会自动计算大小，包括空字符\0
    char str2[] = "World"; 
    
    // 直接打印字符数组，cout 会识别并打印直到遇到空字符为止
    cout << "str1: " << str1 << endl;
    cout << "str2: " << str2 << endl;
    
    // 字符串长度：使用 strlen() 函数 (来自 <cstring>)
    // 它返回字符串中字符的数量，不包括终止空字符。
    cout << "Length of str1: " << strlen(str1) << endl; 
    
    // 字符串复制：使用 strcpy() 函数 (来自 <cstring>)
    // 将 str1 的内容复制到 str3。str3 必须有足够的空间。
    char str3[20]; // 声明一个足够大的字符数组
    strcpy(str3, str1); 
    cout << "str3 (copied): " << str3 << endl;
    
    // 字符串连接：使用 strcat() 函数 (来自 <cstring>)
    // 将一个字符串连接到另一个字符串的末尾。
    strcat(str3, " "); // 在 str3 后连接一个空格
    strcat(str3, str2); // 在 str3 后连接 str2 的内容
    cout << "str3 (concatenated): " << str3 << endl;
    
    // 字符串比较：使用 strcmp() 函数 (来自 <cstring>)
    // 如果两个字符串相等，返回0。否则返回非0值。
    if (strcmp(str1, str2) == 0) {
        cout << "str1 equals str2" << endl;
    } else {
        cout << "str1 does not equal str2" << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
str1: Hello
str2: World
Length of str1: 5
str3 (copied): Hello
str3 (concatenated): Hello World
str1 does not equal str2
```

***

**多维数组和字符数组的总结：**

* **多维数组**通过增加方括号来扩展维度，每个维度都有自己的索引。它适用于表示表格、图像、游戏地图等需要多个坐标来定位的数据。
* **字符数组**是 C++ 中处理字符串的传统方式，需要特别注意字符串末尾的**空字符 `\0`**。操作字符数组时，通常会用到 `<cstring>` 库中的函数（如 `strlen`, `strcpy`, `strcat`, `strcmp`）。

***

## 数组作为函数参数

在 C++ 中，当你将一个数组传递给函数时，实际上数组会“退化”成一个指向其第一个元素的**指针**。这意味着函数接收到的是数组的内存地址，而不是数组的完整副本。

这个特性有几个重要的含义：

1. **不会复制整个数组**：这对于大型数组来说非常高效，避免了不必要的内存开销和复制时间。
2. **函数可以修改原始数组**：由于函数接收的是地址，它可以通过这个地址直接访问并修改原始数组中的元素。这种行为被称为“传引用”（pass-by-reference）的效果，尽管技术上数组是“传值”了一个指针。
3. **需要传递数组大小**：因为数组退化成了指针，函数内部无法直接知道数组的原始大小。因此，通常需要额外传递一个参数来表示数组的元素数量。

```cpp
#include <iostream>
#include <cstring> 
using namespace std; 

// 函数：打印数组元素
// arr[] 表示接收一个整数数组（实际是一个指向int的指针）
// size 表示数组的元素数量
void printArray(int arr[], int size) {
    cout << "Array elements: ";
    for (int i = 0; i < size; i++) {
        cout << arr[i] << " ";
    }
    cout << endl;
}

// 函数：修改数组元素
// 注意：对 arr 的修改会直接影响到 main 函数中传递进来的原始数组
void modifyArray(int arr[], int size) {
    for (int i = 0; i < size; i++) {
        arr[i] *= 2;  // 将每个元素乘以2
    }
}

// 函数：查找数组中的最大值
// 返回数组中的最大整数
int findMax(int arr[], int size) {
    int maxVal = arr[0]; // 假设第一个元素是最大值
    for (int i = 1; i < size; i++) { // 从第二个元素开始比较
        if (arr[i] > maxVal) {
            maxVal = arr[i]; // 更新最大值
        }
    }
    return maxVal;
}

int main() {
    // 声明并初始化一个整数数组
    int numbers[] = {1, 2, 3, 4, 5};
    // 计算数组的元素数量：数组总字节大小 / 单个元素字节大小
    int size = sizeof(numbers) / sizeof(numbers[0]); 
    
    cout << "Original array:" << endl;
    printArray(numbers, size); // 打印原始数组
    
    cout << "Maximum value: " << findMax(numbers, size) << endl; // 查找并打印最大值
    
    modifyArray(numbers, size); // 调用函数修改数组
    cout << "Modified array:" << endl;
    printArray(numbers, size); // 再次打印数组，观察修改后的结果
    
    return 0;
}
```

**运行结果示例:**

```text
Original array:
Array elements: 1 2 3 4 5 
Maximum value: 5
Modified array:
Array elements: 2 4 6 8 10 
```

***

**关键点回顾：**

* 当数组作为函数参数传递时，它会**退化为指向其第一个元素的指针**。
* 这意味着函数内部对数组的修改会**直接影响到原始数组**。
* 为了在函数内部知道数组的大小，你通常需要**额外传递一个表示数组大小的参数**。

***

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson1-cpp-2025-5-array-ops.md
description: 第 1 课第 5 章：数组常见操作，聚焦查找、统计、最大最小、反转等基础操作，配合练习巩固。
---

# C++ 数组：常见操作

***

数组作为一种基础的数据结构，我们不仅需要学会如何声明和初始化它，更重要的是掌握如何对数组中的数据进行各种**常见操作**。这些操作是许多算法和程序的基础。

***

## 数组的常见操作

下面我们将通过一个例子，演示如何在 C++ 中对数组进行查找、求和、计算平均值以及反转等操作。

```cpp
#include <iostream>  
#include <algorithm> 
using namespace std; 

int main() {
    // 声明并初始化一个整数数组
    int arr[] = {64, 34, 25, 12, 22, 11, 90};
    // 计算数组的元素数量：
    // sizeof(arr) 返回整个数组在内存中占用的总字节数。
    // sizeof(arr[0]) 返回数组第一个元素（即单个 int 类型）在内存中占用的字节数。
    // 两者相除，即可得到数组中元素的数量。
    // 这种方法只适用于在当前作用域内完整定义的静态数组。
    int size = sizeof(arr) / sizeof(arr[0]);
    
    // 打印原始数组
    cout << "Original array: ";
    for (int i = 0; i < size; i++) {
        cout << arr[i] << " ";
    }
    cout << endl;
    
    // --- 查找元素 ---
    // 目标：检查某个特定值是否存在于数组中，并找出其位置。
    int searchValue = 25; // 我们要查找的值
    bool found = false;   // 标记是否找到
    int index = -1;       // 存储找到的索引
    
    // 遍历数组，逐个比较
    for (int i = 0; i < size; i++) {
        if (arr[i] == searchValue) {
            found = true; // 找到啦！
            index = i;    // 记录它的索引
            break;        // 找到后就可以停止查找了，提高效率
        }
    }
    
    if (found) {
        cout << "Found " << searchValue << " at index " << index << endl;
    } else {
        cout << searchValue << " not found" << endl;
    }
    
    // --- 计算总和 ---
    // 目标：将数组中所有元素的值加起来。
    int sum = 0;
    for (int i = 0; i < size; i++) {
        sum += arr[i]; // 累加每个元素
    }
    cout << "Sum: " << sum << endl;
    
    // --- 计算平均值 ---
    // 目标：计算数组中所有元素的平均值。
    // 注意：需要将 `sum` 转换为 `double` 类型，以避免整数除法造成的精度丢失。
    double average = (double)sum / size;//(double)sum可以把sum强制转换为double形
    cout << "Average: " << average << endl;
    
    // --- 反转数组 ---
    // 目标：将数组的元素顺序颠倒，例如 {1,2,3,4} 变为 {4,3,2,1}。
    // 思路：交换数组两端的元素，然后逐渐向中间靠拢。
    for (int i = 0; i < size / 2; i++) {
        // 使用 std::swap 交换 arr[i] 和 arr[size - 1 - i]
        // std::swap 用法：std::swap (a,b) 即为把 a 和 b 的值互换。
        // 例如：i=0 交换 arr[0] 和 arr[size-1]
        //       i=1 交换 arr[1] 和 arr[size-2]
        swap(arr[i], arr[size - 1 - i]);
    }
    
    cout << "Reversed array: ";
    for (int i = 0; i < size; i++) {
        cout << arr[i] << " ";
    }
    cout << endl;
    
    return 0;
}
```

**运行结果示例:**

```text
Original array: 64 34 25 12 22 11 90 
Found 25 at index 2
Sum: 258
Average: 36.8571
Reversed array: 90 11 22 12 25 34 64 
```

***

## 数组的限制和注意事项

尽管数组是 C++ 中非常基础和有用的数据结构，但它也有一些固有的**限制**和需要特别注意的地方。理解这些限制可以帮助你避免常见的编程错误，编写出更健壮的代码。

### 1. 固定大小

C++ 中的**普通数组**一旦声明，其大小（能容纳的元素数量）就**固定**了，在程序运行时不能改变。这意味着如果你声明了一个 `int arr[5];` 的数组，它就只能存储 5 个整数。

尝试访问数组范围之外的内存（称为**越界访问**）会导致**未定义行为**。这可能导致程序崩溃、输出错误数据，或者在某些情况下，程序甚至能正常运行，但会在未来引发难以调试的问题。

```cpp
#include <iostream>
using namespace std;

int main() {
    int arr[5]; // 声明一个包含5个元素的数组，索引范围是 0 到 4

    // arr[5] = 10; // 错误且危险：这是一个越界访问！
                  // 数组只有 arr[0] 到 arr[4]

    // 编译时通常不会报错，但运行时会带来问题，切记避免！

    return 0;
}
```

**如何避免越界访问？**

* **始终检查索引**：在循环或任何访问数组元素的代码中，确保索引值在 `0` 到 `size - 1` 的有效范围内。

* **使用常量定义大小**：在算法竞赛（一般会限定最大输入量）或大型项目中，通常会使用 `const int` 定义数组的最大尺寸，这样可以集中管理和避免硬编码数字。

  ```cpp
  const int N = 1000; // 定义一个最大值
  int my_array[N];    // 使用常量声明数组，避免越界
  ```

### 2. 不能直接复制

与基本数据类型不同，C++ 中的数组不能像这样直接通过赋值运算符 `=` 进行整体复制：

```cpp
#include <iostream>
using namespace std;

int main() {
    int arr1[5] = {1, 2, 3, 4, 5};
    int arr2[5];
    
    // arr2 = arr1; // 错误：C++ 不允许直接使用赋值运算符复制整个数组
    
    // 正确的复制方法：逐个元素复制
    for (int i = 0; i < 5; i++) {
        arr2[i] = arr1[i];
    }

    // 验证复制是否成功
    cout << "arr2 after copy: ";
    for (int i = 0; i < 5; i++) {
        cout << arr2[i] << " ";
    }
    cout << endl;
    
    return 0;
}
```

**提示：**

* 对于字符数组（C 风格字符串），你可以使用 `strcpy` 函数进行复制（但要注意目标数组空间是否足够）。

### 3. 不能直接返回

C++ 函数不能直接返回一个完整的数组。当你尝试返回数组名时，实际上返回的是指向该数组第一个元素的**指针**。

```cpp
#include <iostream>
using namespace std;

// 错误示范：不能直接返回数组
// int[] getArrayBad() {
//     int arr[5] = {1, 2, 3, 4, 5}; // 局部数组在函数结束后会被销毁
//     return arr; // 返回一个指向已销毁内存的指针，非常危险！
// }

// 正确的方法：返回一个指向数组的指针
// 注意：这里使用 static 关键字，确保数组在函数结束后依然存在于内存中。
//      但通常不推荐返回局部静态数组，因为它可能引起意想不到的副作用。
int* getArray() {
    static int arr[5] = {1, 2, 3, 4, 5}; // static 局部变量在程序生命周期内都存在
    cout << "Inside getArray: " << arr[0] << endl;
    return arr; // 返回数组第一个元素的地址
}

int main() {
    int* myArrPtr = getArray(); // 接收返回的指针
    
    cout << "Elements from returned array: ";
    for (int i = 0; i < 5; i++) {
        cout << myArrPtr[i] << " "; // 通过指针访问数组元素
    }
    cout << endl;
    
    return 0;
}
```

**更安全的替代方案：**

* **通过参数传递**：让函数接受一个数组（或指针）作为参数，并在函数内部修改它（正如我们前面“数组作为函数参数”一节所学）。

***

## 如何使程序“崩溃”（或产生未定义行为）

了解这些常见错误可以帮助你避免它们。尝试以下操作来观察程序的行为，并理解其危险性：

1. **数组越界**：
   试图访问数组的有效索引范围之外的元素。

   ```cpp
   #include <iostream>
   using namespace std;

   int main() {
       int arr[5] = {1, 2, 3, 4, 5};
       // 尝试访问索引 10，但数组只有索引 0 到 4
       cout << "Attempting to access arr[10]: " << arr[10] << endl; // 越界访问！
       return 0;
   }
   ```

   * **你会看到什么？** 程序可能会崩溃（段错误），或者打印出一个随机的、无意义的数字。这是因为你正在读取不属于你程序内存区域的数据。

2. **未初始化的数组**：
   声明数组后，如果没有明确地初始化所有元素，那么它们会包含“垃圾值”（即之前内存中残留的随机数据）。

   ```cpp
   #include <iostream>
   using namespace std;

   int main() {
       int arr[5]; // 声明，但未完全初始化
       cout << "Uninitialized array elements: ";
       for (int i = 0; i < 5; i++) {
           cout << arr[i] << " "; // 打印未定义的值
       }
       cout << endl;
       return 0;
   }
   ```

   * **你会看到什么？** 你会看到一些看起来像随机数的奇怪数字。这些值是不可预测的，并且在每次程序运行时可能都不同。

3. **字符串缓冲区溢出**：
   当你尝试将一个比目标字符数组更大的字符串复制进去时，就会发生缓冲区溢出。这会写入到数组之外的内存区域。

   ```cpp
   #include <iostream>
   #include <cstring> // For strcpy
   using namespace std;

   int main() {
       // str 只能容纳 5 个字符，包括末尾的空字符 '\0'。
       // 所以它最多只能存储 4 个实际字符。
       char str[5]; 
       
       // "Hello World" 有 11 个字符 + 1 个空字符 = 12 个字节。
       // 这远超 str 的 5 个字节容量。
       strcpy(str, "Hello World"); // 缓冲区溢出！
       
       cout << "Overflowed string: " << str << endl;
       return 0;
   }
   ```

   * **你会看到什么？** 程序可能会崩溃，或者打印出部分字符串，后面跟着一些奇怪的字符，甚至可能影响到其他变量的值。这是非常危险的，因为它可以被恶意利用。

***

通过了解这些限制和常见的陷阱，你就能更好地掌握 C++ 数组的使用，并编写出更安全、更可靠的代码。当你遇到上述问题时，首先检查你的数组索引、初始化以及是否使用了合适的标准库容器。

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson2-cpp-2025-function.md
description: C++ 进阶讲义，包含函数定义、参数传递、结构体与常见语法实践。
---

# C++ 函数与结构体

在 C++ 编程中，我们不仅需要存储数据（如使用数组），还需要组织和处理这些数据。**函数（Function）** 允许我们将代码封装成可重用的模块，而 **结构体（Struct）** 允许我们将相关联的不同类型的数据组合成一个单一的实体。

***

### C++ 函数 (Function)

函数是一段执行特定任务的代码块。我们通过给它一个名字来“调用”它。使用函数可以使代码更清晰、更易于管理，并减少重复代码。

#### 1. 函数的定义与调用

函数的基本语法如下：

返回类型 函数名(参数列表) { ...函数体... }

* **返回类型 (Return Type):** 函数执行完毕后“返回”给调用者的数据类型。如果函数不返回任何值，则使用 `void`。
* **函数名 (Function Name):** 你给函数起的名字。
* **参数列表 (Parameter List):** 传入函数的数据。

```c++
#include <iostream>
#include <string>
using namespace std;

// --- 1. 有返回值的函数 ---
// 目标：计算两个整数的和并返回结果
int add(int a, int b) {
    int sum = a + b;
    return sum; // 'return' 关键字用于返回一个值
}

// --- 2. 没有返回值的函数 (void) ---
// 目标：打印一条问候消息
void printGreeting(string name) {
    cout << "Hello, " << name << "!" << endl;
    // void 函数没有 return 语句，或者使用 return; 来提前结束
}

int main() {
    // --- 调用函数 ---
    
    // 调用 add 函数，并将返回值存储在 result 变量中
    int result = add(5, 3);
    cout << "5 + 3 = " << result << endl;
    
    // 调用 printGreeting 函数
    printGreeting("Alice");
    
    return 0;
}
```

**运行结果示例:**

```text
5 + 3 = 8
Hello, Alice!
```

#### 2. 参数传递：值传递 vs 引用传递

这是一个非常重要的概念。当你将变量传递给函数时，有两种基本方式：

* **值传递 (Pass-by-Value)：**
  * **机制：** 函数接收的是变量的**副本 (copy)**。
  * **效果：** 在函数内部修改这个副本，**不会**影响到函数外部的原始变量。
  * 这是 C++ 的默认方式。
* **引用传递 (Pass-by-Reference)：**
  * **机制：** 函数接收的是变量的**引用 (reference)**，可以理解为变量的“别名”。这是通过在类型后添加 `&` 符号实现的。
  * **效果：** 在函数内部修改这个引用，**会**直接修改函数外部的原始变量。

```c++
#include <iostream>
using namespace std;

// 1. 值传递 (Pass-by-Value)
// 传入的是 num 的副本
void modifyByValue(int x) {
    x = 100; // 修改的是副本 x
    cout << "Inside modifyByValue, x = " << x << endl;
}

// 2. 引用传递 (Pass-by-Reference)
// 传入的是 num 的引用（别名）
void modifyByReference(int& x) {
    x = 100; // 修改的是 x，也就是原始的 num
    cout << "Inside modifyByReference, x = " << x << endl;
}

int main() {
    int num = 10;
    cout << "Original num = " << num << endl;
    
    // --- 测试值传递 ---
    modifyByValue(num);
    cout << "After modifyByValue, num = " << num << endl; // num 仍然是 10
    
    cout << "---" << endl;
    
    // --- 测试引用传递 ---
    num = 10; // 重置 num
    cout << "Original num = " << num << endl;
    modifyByReference(num);
    cout << "After modifyByReference, num = " << num << endl; // num 变成了 100

    return 0;
}
```

**运行结果示例:**

```text
Original num = 10
Inside modifyByValue, x = 100
After modifyByValue, num = 10
---
Original num = 10
Inside modifyByReference, x = 100
After modifyByReference, num = 100
```

> **💡 竞赛技巧：**
>
> 1. **效率：** 当传递大型数据结构（如 `string`, `vector`）时，使用引用传递（`const vector<int>&`）可以避免昂贵的复制操作，提高程序效率。
> 2. **修改：** 当你希望函数能修改传入的变量时（例如，`swap` 函数或 `dfs` 中修改 `visited` 数组），必须使用引用传递。

#### 3. 算法竞赛中的全局变量

在算法竞赛中，为了简化问题，我们经常使用**全局变量**。

* **定义：** 在所有函数（包括 `main` 函数）之外定义的变量。
* **作用域：** 它们在程序的任何地方（所有函数内部）都是可见和可访问的。

**好处：**

1. **避免复杂传参：** 在递归函数（如 `dfs`）中，你不需要把像 `visited` 数组、图 `G`、最终答案 `ans` 等变量一层层传递下去，函数可以直接访问它们。
2. **共享状态：** 多个函数可以方便地共享和修改同一个数据。

```c++
#include <iostream>
#include <vector>
using namespace std;

// --- 全局变量 ---
vector<vector<int>> graph; // 图
bool visited[100];       // 访问数组
int nodeCount = 0;         // 统计节点数

// DFS 函数可以直接访问全局变量
void dfs(int u) {
    if (visited[u]) return;
    
    visited[u] = true;
    nodeCount++; // 修改全局变量
    
    // 遍历 graph
    for (int v : graph[u]) {
        dfs(v);
    }
}

int main() {
    int n, m; // 假设 n 个点, m 条边
    cin >> n >> m;
    
    graph.resize(n + 1); // 调整全局 vector 大小
    
    for (int i = 0; i < m; i++) {
        int u, v;
        cin >> u >> v;
        graph[u].push_back(v);
        graph[v].push_back(u);
    }
    
    // 从节点 1 开始 DFS
    dfs(1); 
    
    cout << "Nodes visited: " << nodeCount << endl;
    
    return 0;
}
```

**注意：** 虽然全局变量在竞赛中很方便，但在大型工程项目中，过度使用会导致代码难以维护。不过在算法竞赛中，追求的是**快速**和**正确**，所以它是一个非常有用的技巧。

***

### C++ 结构体 (Struct)

结构体是一种用户自定义的数据类型，它允许你将多个不同类型的数据项组合成一个单一的单元。

#### 1. 结构体的定义与使用

* **定义：** 使用 `struct` 关键字。
* **访问：** 使用 `.` (点运算符) 来访问其成员。

```c++
#include <iostream>
#include <string>
#include <algorithm> // 包含 sort
#include <vector>
using namespace std;

// --- 1. 定义一个结构体 ---
// 目标：封装一个学生的信息
struct Student {
    string name;
    int studentID;
    double score;
}; // 注意这里的分号

// --- 2. 结构体与排序 (非常常见) ---
// (这是结构体在算法竞赛中非常常见的用法)

// 比较函数：
// 1. 优先按分数(score)降序排列
// 2. 如果分数相同，按学号(studentID)升序排列
bool cmp(const Student& a, const Student& b) {
    if (a.score != b.score) {
        return a.score > b.score; // 分数高的在前
    }
    return a.studentID < b.studentID; // 分数相同，ID小的在前
}

int main() {
    // --- 3. 创建和使用结构体实例 ---
    vector<Student> students;
    students.push_back({"Bob", 1002, 88.0});
    students.push_back({"Alice", 1001, 95.5});
    students.push_back({"Charlie", 1003, 95.5}); // 与 Alice 同分

    // 使用 std::sort 和我们自定义的 cmp 函数
    sort(students.begin(), students.end(), cmp);
    
    cout << "--- Sorted Students ---" << endl;
    for (const auto& s : students) { // 使用引用(const &)避免复制，提高效率
        cout << s.name << " (ID: " << s.studentID << ") Score: " << s.score << endl;
    }
    
    return 0;
}
```

**运行结果示例:**

```text
--- Sorted Students ---
Alice (ID: 1001) Score: 95.5
Charlie (ID: 1003) Score: 95.5
Bob (ID: 1002) Score: 88.0
```

***

###

### 辅助工具 (Typedef, Pair, Tuple)

#### 1. `typedef` 和 `using` (类型别名)

当你使用非常长或复杂的类型（比如 `unsigned long long` 或 `map<string, vector<int>>`）时，`typedef` 可以让你为它创建一个更短、更易读的别名。

* **`typedef` 语法：** `typedef 原类型名 别名;`
* **`using` 语法 (C++11)：** `using 别名 = 原类型名;` (更现代，推荐使用)

```c++
#include <iostream>
#include <vector>
using namespace std;

// --- 1. 使用 typedef ---
typedef unsigned long long ull; // ull 现在是 unsigned long long 的别名
typedef vector<int> vi;         // vi 现在是 vector<int> 的别名

// --- 2. 使用 using (C++11 及以后) ---
using ll = long long;          // ll 现在是 long long 的别名
using v_str = vector<string>;  // v_str 是 vector<string> 的别名

int main() {
    ull a = 1234567890123456789ULL; // ULL 后缀表示这是 ull 类型
    ll b = -987654321;
    vi numbers = {1, 2, 3, 4, 5};
    
    cout << "ull a: " << a << endl;
    cout << "ll b: " << b << endl;
    cout << "vi numbers[0]: " << numbers[0] << endl;
    
    return 0;
}
```

在算法竞赛中，`using ll = long long;` 几乎是必备的。

#### 2. `pair`

`pair` 是一个模板结构体，它恰好可以存储**两个**值（可以是不同类型）。

* **访问：** 使用 `.first` 和 `.second`。
* **应用：** 常用于 `map` 的键值对、`bfs` 中存储坐标 (x, y)、存储图的边（`pair<int, int> edge`）等。

```c++
#include <iostream> //包含 pair
#include <string>
using namespace std;

int main() {
    // 创建一个 pair
    pair<int, string> p1;
    p1.first = 1;
    p1.second = "Apple";
    
    // C++11 初始化
    pair<double, char> p2 = {3.14, 'A'};
    
    // 使用 make_pair
    auto p3 = make_pair(10, "Banana"); // auto 自动推断类型
  	// 在 C++17 中引入了更简单的写法，但很多比赛并不支持 C++17 （比如蓝桥杯和睿抗）。
		//pair p3 = {10, "Banana"}; 
    
    cout << "p1: " << p1.first << ", " << p1.second << endl;
    cout << "p2: " << p2.first << ", " << p2.second << endl;
    
    return 0;
}
```

#### 3. `tuple`

`tuple` (元组) 是 `pair` 的扩展，它可以存储**任意多个**值（三个或更多）。

* **头文件：** `<tuple>`
* **访问：** 使用 `std::get<索引>()` (索引从 0 开始)。
* **应用：** 当你需要一次性返回或存储三个值（比如 `bfs` 中的 `x, y, step`）时非常有用。

```c++
#include <iostream>
#include <string>
#include <tuple> // 包含 tuple
using namespace std;

int main() {
    // 创建一个 tuple (C++11)
    tuple<int, string, double> t1 = {101, "Laptop", 799.99};
  	// C++17 
		// tuple t2 = {101, "Laptop", 799.99}; // 编译器自动推导 t2 为 tuple<int, const char*, double>
    
    // 访问元素
    cout << "ID: " << get<0>(t1) << endl;     // 访问第 0 个元素
    cout << "Item: " << get<1>(t1) << endl;   // 访问第 1 个元素
    cout << "Price: " << get<2>(t1) << endl;  // 访问第 2 个元素
    
    // 修改元素
    get<2>(t1) = 749.99; // 打折
    cout << "New Price: " << get<2>(t1) << endl;

    return 0;
}
```

***

### C++ 指针 (Pointers) - 简介

在算法竞赛中，我们几乎总是使用 **STL 容器**（如 `vector`）、**引用**（`&`）和**全局变量**来管理数据，这些方法更安全、更简单。

不过，为了完整性，这里是 C++ 指针的（最基本）概念：

* 指针 (Pointer) 是一个变量，它存储的不是一个值（如 10），而是一个内存地址。
* `&` (地址运算符)：获取一个变量的内存地址。
* `*` (解引用运算符)：获取一个指针所指向的地址上的**值**。

```c++
#include <iostream>
using namespace std;

int main() {
    int var = 20; // 一个普通变量
    
    // int* ptr; 表示 ptr 是一个 "指向 int 类型的指针"
    int* ptr = &var; // ptr 存储了 var 变量的内存地址
    
    cout << "var 的值 (var): " << var << endl;
    cout << "var 的地址 (&var): " << &var << endl;
    cout << "ptr 存储的值 (ptr): " << ptr << endl;   // (会打印 var 的地址)
    cout << "ptr 指向的值 (*ptr): " << *ptr << endl; // (会打印 var 的值)
    
    // 通过指针修改值
    *ptr = 50; 
    
    cout << "--- After *ptr = 50 ---" << endl;
    cout << "var 的新值 (var): " << var << endl; // var 变成了 50
}
```

了解指针有助于理解 C++ 的底层（例如 `vector` 为什么比 C 数组慢一点点，因为它在堆上分配内存），但在算发竞赛中，**你几乎不需要自己声明或使用指针**。如果想要用c和c++进行开发的同学可以深入了解指针。

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson2-cpp-2025-STL.md
description: C++ STL 讲义，介绍常用容器、迭代器与基础算法的核心用法。
---

# C++ STL (标准模板库)

> STL (Standard Template Library)：是 C++ 标准库的重要组成部分，不仅是一个可复用的组件库，而且是一个包罗数据结构与算法的软件框架。
>
> \*\*通俗来说：\*\*STL 就是将常见的数据结构（例如 顺序表，链表，栈，队列，二叉树，哈希...）以模板的形式进行封装，使用时，不用我们人为再去写，可以直接调用。并且包含常见的通用的泛型算法（一些常规的算法也不用自己实现，可以直接调用）。

### STL 六大组件

* **容器（Container）：** 各种数据结构，如 `vector`、`list`、`deque`、`set`、`map` 等，以模板类的方法提供。为了访问容器中的数据，可以使用由容器类输出的迭代器。

* **算法（Algorithm）：** 各种常用算法，提供了执行各种操作的方式，包括对容器内容执行初始化、排序、搜索和转换等操作，如 `sort`、`find`、`copy`、`erase` 函数等。函数本身与它们操作的数据的结构和类型无关，因此它们可以在从简单数组到高度复杂容器的任何数据结构上使用。

* **迭代器（Iterator）：** 迭代器提供了访问容器中对象的方法，扮演容器与算法之间的胶合剂，是所谓的“泛型指针”，共有 5 种类型，以及其他衍生变化，是一种将 `operator*`、`operator->`、`operator++`、`operator--` 等指针操作予以重载的模板类。所有的 STL 容器附带有自己专属的迭代器，因为只有容器设计者才知道如何遍历自己的元素。

  > c++11版本及以后就可以不用迭代器了。

* **仿函数（Functor）：** 也称为函数对象（Function object），行为类似函数，可作为算法的某种策略。从实现角度来看，仿函数是一种重载了 `operator()` 的类或者模板类。

* **适配器（Adaptor）：** 一种用来修饰容器、仿函数或者迭代器接口的机制。例如 STL 提供的 `queue` 和 `stack`，就是一种空间配接器，因为它们的底部完全借助于 `deque`。

* **分配器（allocator）：** 也称为空间配置器，负责空间的配置与管理。从实现的角度来看，配置器是一个实现了动态配置空间、空间管理、空间释放的模板类。

## 算法 (Algorithm)

头文件：`#include <algorithm>`

### 常用函数

* **`sort()`**

  * **功能：** `sort()` 函数可以对给定区间所有元素进行排序。
  * **参数：** `sort(begin, end, cmp)`
    * `begin`：指向待 `sort()` 的数组的第一个元素的指针。
    * `end`：指向待 `sort()` 的数组的最后一个元素的下一个位置的指针。
    * `cmp`：排序准则，可以不写，默认从小到大进行排序。

  ```c++
  #include<iostream>
  #include<algorithm>
  using namespace std;

  int main(){
      int num[10] = {6,5,9,1,2,8,7,3,4,0};
      // greater<int>() 是一个仿函数，表示降序排列，这里只做演示，是一个伪代码
      sort(num, num+10, greater<int>());
      // 排序后 num 变为：9 8 7 6 5 4 3 2 1 0
      return 0;
  }
  ```

* \*\*`swap()`\*\*交换两个数的值

  ```c++
  int a = 1, b = 2 ;
  cout << a << ' ' << b << '\n' ;
  swap(a, b) ;
  ```

* \*\*`min()`\*\*取最小值

* \*\*`max()`\*\*取最大值

### 💡 排序练习

[P5740 【深基7.例9】最厉害的学生 - 洛谷](https://www.luogu.com.cn/problem/P5740)

## P5740 【深基7.例9】最厉害的学生

## 题目描述

现有 $N$ 名同学参加了期末考试，并且获得了每名同学的信息：姓名（不超过 $8$ 个字符的仅有英文小写字母的字符串）、语文、数学、英语成绩（均为不超过 $150$ 的自然数）。总分最高的学生就是最厉害的，请输出最厉害的学生各项信息（姓名、各科成绩）。如果有多个总分相同的学生，输出靠前的那位。

## 输入格式

第一行输入一个正整数 $N$，表示学生个数。

第二行开始，往下 $N$ 行，对于每一行首先先输入一个字符串表示学生姓名，再输入三个自然数表示语文、数学、英语的成绩。均用空格相隔。

## 输出格式

输出最厉害的学生。

## 输入输出样例 #1

### 输入 #1

```text
3
senpai 114 51 4
lxl 114 10 23
fafa 51 42 60
```

### 输出 #1

```text
senpai 114 51 4
```

## 说明/提示

数据保证，$1 \leq N \leq 1000$，姓名为长度不超过 $8$ 的字符串，语文、数学、英语成绩均为不超过 $150$ 的自然数。

***

**自定义 `cmp` 函数实现结构体排序**

```c++
#include <bits/stdc++.h>
using namespace std ;
const int N = 1008 ;

struct node {
    string name ;
    int a, b, c ;
    int sum ;
    int num ;
} no[N];

// 自定义比较函数
bool cmp(node x, node y) {
    // 如果总分相同
    if (x.sum == y.sum) {
        // 按学号从小到大
        return x.num < y.num ;
    }
    // 否则按总分从大到小
    return x.sum > y.sum ;
}

int main() {
    int n ;
    cin >> n ;
    for (int i = 1 ; i <= n ; i ++) {
        cin >> no[i].name >> no[i].a >> no[i].b >> no[i].c ;
        no[i].sum = no[i].a + no[i].b + no[i].c ;
        no[i].num = i ;
    }

    // 使用自定义的 cmp 函数进行排序
    sort(no + 1, no + n + 1, cmp) ;

    cout << no[1].name << ' ' << no[1].a << ' ' << no[1].b << ' ' << no[1].c <<'\n' ;
    return 0 ;
}
```

***

## 📦 容器 (Container)

容器是存放数据的数据结构，比如链表，数组，队列... 容器都是一个类（用法与结构体相似）。访问类对象内的函数或变量用点运算符 `.`。

### `vector` (可变长度数组)

vector翻译为向量，但是这里使用“变长数组”的叫法更容易理解，也即“长度根据需要而自动改变的数组”。我们知道在C语言中，普通数组大小一旦确定就不能改变了，在做题时有时会碰到只用普通数组会超内存的情况，这时我们就可以使用vector来定义不定长数组节省空间。

#### 定义

```c++
#include <vector>
vector<typename> name;

// 示例：
vector<int> v = {1, 2, 3};
```

#### 常用函数

* `push_back(x)`：在 vector 后面添加一个元素 `x`，时间复杂度 O(1)。
* `pop_back()`：删除 vector 最后一个元素，时间复杂度 O(1)。
* `back()`：返回最后一个元素的值。
* `front()`：返回第一个元素的值。
* `size()`：返回 vector 中元素的个数，时间复杂度 O(1)。
* `clear()`：清空 vector 中的所有元素，时间复杂度 O(N)。
* `insert(it, x)`：向迭代器 `it` 处插入一个元素 `x`，时间复杂度 O(N)。
* `erase(it)`：删除迭代器 `it` 处的元素。
* `erase(first, last)`：删除 `[first, last)` 区间内的所有元素。

#### 迭代器

```c++
vector<int> v = {1, 2, 3};
vector<int>::iterator it ;

// 传统迭代器遍历
for (it = v.begin() ; it != v.end() ; it ++) {
    cout << *it << '\n' ;
}

// C++11 
// 
// 
// 
for (auto i : v) { // auto 自动推导类型
    cout << i << ' ' ;
}
```

#### 练习

[P1567 统计天数 - 洛谷](https://www.luogu.com.cn/problem/P1567)

## P1567 统计天数

## 题目描述

炎热的夏日，KC 非常的不爽。他宁可忍受北极的寒冷，也不愿忍受厦门的夏天。最近，他开始研究天气的变化。他希望用研究的结果预测未来的天气。

经历千辛万苦，他收集了连续 $N(1 \leq N \leq 10^6)$ 天的最高气温数据。

现在，他想知道最高气温一直上升的最长连续天数。

## 输入格式

第 1 行：一个整数 $N$ 。$1 \leq N \leq 10^6$

第 2 行：$N$个空格隔开的整数，表示连续 $N$ 天的最高气温。$0 \leq$ 最高气温 $\leq 10^9$ 。

## 输出格式

1 行：一个整数，表示最高气温一直上升的最长连续天数。

## 输入输出样例 #1

### 输入 #1

```text
10
1 2 3 2 4 5 6 8 5 9
```

### 输出 #1

```text
5
```

***

```c++
#include <bits/stdc++.h>
using namespace std ;

int main() {
    int n ;
    cin >> n ;
    vector<int> a;

    for (int i = 1 ; i <= n ; i ++) {
        int x ;
        cin >> x ;
        a.push_back(x) ;
    }

    int ans = 1, tmp = 1 ;
    for (int i = 1 ; i < a.size() ; i ++) {
        if (a[i] > a[i - 1]) {
            tmp ++ ;
        } else {
            ans = max(ans, tmp) ;
            tmp = 1 ;
        }
    }
    ans = max(ans, tmp) ; // 别忘了最后一次的比较

    cout << ans << '\n' ;
    return 0 ;
}
```

***

### `string` (字符串)

C++ 在 STL 中加入了 `string` 类型，对字符串常用的需求功能进行了封装，使得操作起来更方便，且不易出错。

#### 头文件

```c++
#include <string>
```

#### 定义

```c++
string a = "abcd";
```

#### 常用函数

* `+=`：字符串拼接，假设有两个字符串`a`和`b`，可用`a+=b`或`a=a+b`来将`b`接到`a`的后面。
* `==`, `!=`, `<`, `<=`, `>`, `>=`：按字典序比较大小。
* `length()` / `size()`：返回字符串长度，O(1)。
* `erase(it)`：删除 `it` 处的字符，`it` 为迭代器。
* `erase(first, last)`：删除 `[first, last)` 区间的字符，`first`, `last` 为迭代器。
* `erase(pos, length)`：`pos` 为开始删除的起始位置，`length` 为删除的字符个数。
* `clear()`：清空字符串 O(1)。
* `substr(pos, len)`：返回从 `pos` 号位置开始、长度为 `len` 的子串，O(len)。
* `find(str2)`：当 `str2` 是 `str` 的子串时，返回其在 `str` 中第一次出现的位置；否则返回 `string::npos`。O(NM)。
* `front()`：返回第一个字符。
* `back()`：返回最后一个字符。
* `push_back(x)`：将字符 `x` 加到字符串后。
* `pop_back()`：删除最后一个字符。

***

### `map` (映射)

Map (映射) 元素包含两部分（key, value），key 和 value 可以是任意类型。在 map 里面，一个 key 对应一个 value，类似函数里一个 x 对应一个 y。并且在 map 里，key 不能重复，自动按 key 从小到大排序。

#### 定义

```c++
#include <map>

map<int, int> mp; // 定义了一个 int 映射 int 的 map
map<int, char> mp; // int -> char
```

#### 常见函数

* `insert(make_pair(x, y))`：插入 key 为 `x`，value 为 `y` 的映射。

* `insert({x,y})`：C++11 版本之后，可以用花括号来生成 pair 二元组。

* **遍历 map**

  ```c++
  map<int, int>::iterator i;
  for(i = mp.begin(); i != mp.end(); i++) {
      cout << i->first << ' ' << i->second; // first 是 key, second 是 value
  }

  // C++11 
  // 
  // 
  // 
  for(auto i : mp) {
      cout << i.first << ' ' << i.second << '\n';
  }

  // C++17 
  // 
  // 
  // 
  for(auto [a,b] : mp) { // 结构化绑定
      cout << a << ' ' << b << '\n';
  }
  ```

#### 练习

[P1125\[NOIP2008 提高组\] 笨小猴 - 洛谷](https://www.luogu.com.cn/problem/P1125)

## P1125 \[NOIP 2008 提高组] 笨小猴

## 题目描述

笨小猴的词汇量很小，所以每次做英语选择题的时候都很头疼。但是他找到了一种方法，经试验证明，用这种方法去选择选项的时候选对的几率非常大！

这种方法的具体描述如下：假设 $\text{maxn}$ 是单词中出现次数最多的字母的出现次数，$\text{minn}$ 是单词中出现次数最少的字母的出现次数，如果 $\text{maxn}-\text{minn}$ 是一个质数，那么笨小猴就认为这是个 Lucky Word，这样的单词很可能就是正确的答案。

## 输入格式

一个单词，其中只可能出现小写字母，并且长度小于 $100$。

## 输出格式

共两行，第一行是一个字符串，假设输入的单词是 Lucky Word，那么输出 `Lucky Word`，否则输出 `No Answer`；

第二行是一个整数，如果输入的单词是 Lucky Word，输出 $\text{maxn}-\text{minn}$ 的值，否则输出 $0$。

## 输入输出样例 #1

### 输入 #1

```text
error
```

### 输出 #1

```text
Lucky Word
2
```

## 输入输出样例 #2

### 输入 #2

```text
olympic
```

### 输出 #2

```text
No Answer
0
```

## 说明/提示

【输入输出样例 1 解释】

单词 `error` 中出现最多的字母 $\texttt r$ 出现了 $3$ 次，出现次数最少的字母出现了 $1$ 次，$3-1=2$，$2$ 是质数。

【输入输出样例 2 解释】

单词 `olympic` 中出现最多的字母 $\texttt i$ 出现了 $1$ 次，出现次数最少的字母出现了 $1$ 次，$1-1=0$，$0$ 不是质数。

（本处原题面错误已经修正）

noip2008 提高第一题

***

```c++
#include <bits/stdc++.h>
#define inf 0x3f3f3f3f
using namespace std ;

map<char, int> cnt; // 统计每个字符出现的次数

// 判断是否为素数
bool judge(int x) {
    if (x == 0 || x == 1) {
        return false ;
    }
    for (int i = 2 ; i * i <= x ; i ++) {
        if (x % i == 0) {
            return false ;
        }
    }
    return true ;
}

int main() {
    string s ;
    cin >> s ;
    for (auto i : s) {
        cnt[i] ++ ; // map可以直接用[]来访问和修改value
    }

    int minn = inf, maxn = -1 ;
    for (auto i : s) {
        minn = min(minn, cnt[i]) ;
        maxn = max(maxn, cnt[i]) ;
    }

    if (judge(maxn - minn)) {
        cout << "Lucky Word" << '\n' ;
        cout << maxn - minn << '\n' ;
    } else {
        cout << "No Answer\n0\n" ;
    }
    return 0 ;
}
```

***

### `queue` (队列)

队列是一种**先进先出 (FIFO)** 的数据结构。和现实中的队列一个样，从队尾添加元素，从队头删除元素。

#### 定义

```c++
#include <queue>
queue<typename> name;
```

#### 常用函数

* `push(x)`：将 `x` 入队（到队尾）。
* `pop()`：将队首元素出队。
* `front()`：返回队首元素。
* `back()`：返回队尾元素。
* `size()`：返回队列元素个数。
* `empty()`：返回队列是否为空。为空时返回 `true`。

#### 练习

[B3616 【模板】队列 - 洛谷](https://www.luogu.com.cn/problem/B3616)

## B3616 【模板】队列

## 题目描述

请你实现一个队列（queue），支持如下操作：

* `push(x)`：向队列中加入一个数 $x$。
* `pop()`：将队首弹出。如果此时队列为空，则不进行弹出操作，并输出 `ERR_CANNOT_POP`。
* `query()`：输出队首元素。如果此时队列为空，则输出 `ERR_CANNOT_QUERY`。
* `size()`：输出此时队列内元素个数。

## 输入格式

第一行，一个整数 $n$，表示操作的次数。

接下来 $n$ 行，每行表示一个操作。格式如下：

* `1 x`，表示将元素 `x` 加入队列。
* `2`，表示将队首弹出队列。
* `3`，表示查询队首。
* `4`，表示查询队列内元素个数。

## 输出格式

输出若干行，对于每个操作，按「题目描述」输出结果。

每条输出之间应当用空行隔开。

## 输入输出样例 #1

### 输入 #1

```text
13
1 2
3
4
1 233
3
2
3
2
4
3
2
1 144
3
```

### 输出 #1

```text
2
1
2
233
0
ERR_CANNOT_QUERY
ERR_CANNOT_POP
144
```

## 说明/提示

### 样例解释

首先插入 `2`，队首为 `2`、队列内元素个数为 `1`。\
插入 `233`，此时队首为 `2`。\
弹出队首，此时队首为 `233`。\
弹出队首，此时队首为空。\
再次尝试弹出队首，由于队列已经为空，此时无法弹出。\
插入 `144`，此时队首为 `144`。

### 数据规模与约定

对于 $100%$ 的测试数据，满足 $n\leq 10000$，且被插入队列的所有元素值是 $\[1, 1000000]$ 以内的正整数。

***

```c++
#include <bits/stdc++.h>
using namespace std ;

int main() {
    int n ;
    cin >> n ;
    queue<int> q ;

    while (n --) {
        int op ;
        cin >> op ;
        if (op == 1) {
            int x ;
            cin >> x ;
            q.push(x) ;
        } else if (op == 2) {
            if (q.empty()) {
                cout << "ERR_CANNOT_POP" << '\n' ;
            } else {
                q.pop() ;
            }
        } else if (op == 3) {
            if (q.empty()) {
                cout << "ERR_CANNOT_QUERY" << '\n' ;
            } else {
                cout << q.front() << '\n' ;
            }
        } else {
            cout << q.size() << '\n' ;
        }
    }
    return 0 ;
}
```

***

### `stack` (栈)

栈是一种**先进后出 (LIFO)** 的数据结构，并且只能在栈顶进行插入和删除操作。

#### 定义

```c++
#include <stack>
stack<typename> name;
```

#### 常用函数

* `push(x)`：将 `x` 压入栈（到栈顶）。
* `pop()`：将栈顶元素弹出。
* `top()`：返回栈顶元素。
* `size()`：返回栈中元素个数。
* `empty()`：返回栈是否为空。

#### 练习

[B3614 【模板】栈 - 洛谷](https://www.luogu.com.cn/problem/B3614)

## B3614 【模板】栈

## 题目描述

请你实现一个栈（stack），支持如下操作：

* `push(x)`：向栈中加入一个数 $x$。
* `pop()`：将栈顶弹出。如果此时栈为空则不进行弹出操作，输出 `Empty`。
* `query()`：输出栈顶元素，如果此时栈为空则输出 `Anguei!`。
* `size()`：输出此时栈内元素个数。

## 输入格式

**本题单测试点内有多组数据**。\
输入第一行是一个整数 $T$，表示数据组数。对于每组数据，格式如下：\
每组数据第一行是一个整数，表示操作的次数 $n$。\
接下来 $n$ 行，每行首先由一个字符串，为 `push`，`pop`，`query` 和 `size` 之一。若为 `push`，则其后有一个整数 $x$，表示要被加入的数，$x$ 和字符串之间用空格隔开；若不是 `push`，则本行没有其它内容。

## 输出格式

对于每组数据，按照「题目描述」中的要求依次输出。每次输出占一行。

## 输入输出样例 #1

### 输入 #1

```text
2
5
push 2
query
size
pop
query
3
pop
query
size
```

### 输出 #1

```text
2
1
Anguei!
Empty
Anguei!
0
```

## 说明/提示

### 样例 1 解释

对于第二组数据，始终为空，所以 `pop` 和 `query` 均需要输出对应字符串。栈的 size 为 0。

### 数据规模与约定

对于全部的测试点，保证 $1 \leq T, n\leq 10^6$，且单个测试点内的 $n$ 之和不超过 $10^6$，即 $\sum n \leq 10^6$。保证 $0 \leq x \lt 2^{64}$。

### 提示

* 请注意大量数据读入对程序效率造成的影响。
* 因为一开始数据造错了，请注意输出的 `Empty` 不含叹号，`Anguei!` 含有叹号。

***

```c++
#include <bits/stdc++.h>
#define int unsigned long long 
// 
// 
// 
using namespace std ;

void solve() {
    stack<int> s ;
    int n ;
    cin >> n ;
    while (n --) {
        string ss ;
        cin >> ss ;
        if (ss == "push") {
            int x ;
            cin >> x ;
            s.push(x) ;
        } else if (ss == "pop") {
            if (s.empty()) {
                cout << "Empty" << '\n' ;
            } else {
                s.pop() ;
            }
        } else if (ss == "query") {
            if (s.empty()) {
                cout << "Anguei!" << '\n' ;
            } else {
                cout << s.top() << '\n' ;
            }
        } else { // "size"
            cout << s.size() << '\n' ;
        }
    }
}

signed main() {
    ios::sync_with_stdio(false) ; // 加速cin
    cin.tie(0) ; // 解除cin和cout的绑定
    int T ;
    cin >> T ;
    while (T --) {
        solve() ;
    }
    return 0 ;
}
```

***

### `set` (集合)

Set 集合，是一个内部自动有序且不含重复元素的容器。若插入重复元素，会自动忽略该次插入操作，并且 set 里面的元素自动从小到大排序。

#### 定义

```c++
#include <set>
set<typename> name;
```

#### 访问

Set 只能通过迭代器访问。

```c++
set<int> st;
// ... 插入元素 ...

// 1. 迭代器
set<int>::iterator it; 
for(it = st.begin(); it != st.end(); it++) {
    printf("%d", *it); // 可以通过 *it 来访问 set 里的元素
}

// 2. C++11 
// 
// 
// 
for(auto i : st) {
    printf("%d", i);
}
```

#### 常用函数

* `insert(x)`：将 `x` 插入 set 中，并自动递增排序和去重，时间复杂度为 O(logN)。
* `find(x)`：返回 set 中值为 `x` 的迭代器，时间复杂度为 O(logN)。如果找不到，返回 `s.end()`。
* `erase(it)`：`it` 为所需要删除元素的迭代器。时间复杂度为 O(1)。
* `erase(x)`：删除值为 `x` 的元素，时间复杂度为 O(logN)。
* `erase(first, last)`：删除区间 `[first, last)` 内的元素，`first`, `last` 为迭代器。
* `size()`：返回 set 内元素个数。
* `clear()`：清空 set 中的所有元素。

#### 练习

[P1138 第 k 小整数 - 洛谷](https://www.luogu.com.cn/problem/P1138)

## P1138 第 k 小整数

## 题目描述

现有 $n$ 个正整数，要求出这 $n$ 个正整数中的第 $k$ 个最小整数（相同大小的整数只计算一次）。

## 输入格式

第一行为 $n$ 和 $k$; 第二行开始为 $n$ 个正整数的值，整数间用空格隔开。

## 输出格式

第$k$个最小整数的值；若无解，则输出 `NO RESULT`。

## 输入输出样例 #1

### 输入 #1

```text
10 3
1 3 3 7 2 5 1 2 4 6
```

### 输出 #1

```text
3
```

## 说明/提示

$n \leq 10000$，$k \leq 4000$，正整数均小于 $30000$。

***

方法一 (使用 set):

set 自动排序和去重，非常适合这道题。

```c++
#include <bits/stdc++.h>
using namespace std ;

int main() {
    set<int> s ;
    int n, k ;
    cin >> n >> k ;

    for (int i = 1 ; i <= n ; i ++) {
        int x ;
        cin >> x ;
        s.insert(x) ; // 自动去重和排序
    }

    if (k > s.size()) { // 如果k大于去重后的元素个数
        cout << "NO RESULT" << '\n' ;
    } else {
        int pos = 1 ;
        for (auto i : s) { // 遍历set
            if (pos == k) {
                cout << i << '\n' ;
                break ;
            }
            pos ++ ;
        }
    }
    return 0 ;
}
```

方法二 (使用 vector + map 或 bool 数组去重):

手动去重，然后排序。

```c++
#include <bits/stdc++.h>
using namespace std ;

map<int, bool> vis ; // 用map标记是否出现过

int main() {
    vector<int> a ;
    int n, k ;
    cin >> n >> k ;

    for (int i = 1 ; i <= n ; i ++) {
        int x ;
        cin >> x ;
        if (vis[x]) { // 如果出现过
            continue ;
        }
        vis[x] = true ; // 标记为出现过
        a.push_back(x) ;
    }

    if (k > a.size()) {
        cout << "NO RESULT" << '\n' ;
    } else {
        sort(a.begin(), a.end()) ; // 排序
        cout << a[k - 1] << '\n' ; // vector下标从0开始，第k个是 a[k-1]
    }
    return 0 ;
}
```

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson4-Python.md
description: Python 3 基础讲义，包含语法、运算符、数据结构与控制流程入门。
---

# Python 3 基础教程

本教程基于 Python 3.x 版本，涵盖基础语法、数据结构及控制流程。

## 1. 注释 (Comments)

Python 中注释用于解释代码，增强可读性，不会被执行。

### 单行注释

以 `#` 开头。

```python
# 这是一个单行注释
print("Hello, World!") # 代码后也可以接注释
```

### 多行注释

使用三个单引号 `'''` 或三个双引号 `"""` 包裹。

```python
'''
这是多行注释，
使用单引号。
'''

"""
这是多行注释，
使用双引号。
"""
print("多行注释示例")
```

***

## 2. 运算符 (Operators)

### 算术运算符

| 运算符 | 描述              | 实例                |
| :----- | :---------------- | :------------------ |
| `+`    | 加                | `1 + 1` 输出 `2`    |
| `-`    | 减                | `2 - 1` 输出 `1`    |
| `*`    | 乘                | `2 * 3` 输出 `6`    |
| `/`    | 除 (得到浮点数)   | `10 / 2` 输出 `5.0` |
| `%`    | 取模 (余数)       | `10 % 3` 输出 `1`   |
| `**`   | 幂                | `2 ** 3` 输出 `8`   |
| `//`   | 取整除 (向下取整) | `9 // 2` 输出 `4`   |

### 比较运算符

返回布尔值 `True` 或 `False`。
`==` (等于), `!=` (不等于), `>` (大于), `<` (小于), `>=` (大于等于), `<=` (小于等于)。

### 赋值运算符

`=`, `+=`, `-=`, `*=`, `/=`, `%=`, `**=`, `//=`.

* 例如 `c += a` 等效于 `c = c + a`。

### 逻辑运算符

| 运算符 | 描述 | 实例      |
| :----- | :--- | :-------- |
| `and`  | 与   | `x and y` |
| `or`   | 或   | `x or y`  |
| `not`  | 非   | `not x`   |

### 成员运算符

* `in`: 如果在指定的序列中找到值返回 True。
* `not in`: 如果在指定的序列中没有找到值返回 True。

***

## 3. 数字 (Number)

Python 3 支持三种数值类型：

* **int** (整型)
* **float** (浮点型)
* **complex** (复数)

### 数字类型转换 & 常用数学函数

```python
import math
import random

# 1. 类型转换
a = 1.5
print(int(a))     # 输出: 1 (丢弃小数部分)
print(float(1))   # 输出: 1.0

# 2. 数学运算函数 (部分需引入 math 模块)
print(abs(-10))         # abs(): 绝对值，输出 10
print(math.ceil(4.1))   # ceil(): 向上取整，输出 5
print(math.floor(4.9))  # floor(): 向下取整，输出 4
print(max(1, 5, 3))     # max(): 最大值，输出 5
print(min(1, 5, 3))     # min(): 最小值，输出 1
print(pow(2, 3))        # pow(): x的y次方，输出 8
print(round(4.567, 2))  # round(): 四舍五入，保留2位小数，输出 4.57
print(math.sqrt(16))    # sqrt(): 平方根，输出 4.0

# 3. 随机数函数 (需引入 random 模块)
print(random.choice([1, 2, 3, 4]))  # choice(): 从序列中随机选取一个
print(random.random())              # random(): 生成 [0, 1) 范围内的实数
print(random.randint(1, 10))        # randint(): 生成指定范围整数
```

***

## 4. 字符串 (String)

字符串是 Python 中最常用的数据类型，使用单引号 `'` 或双引号 `"` 创建。

### 访问字符串

```python
s = "Runoob"
print(s[0])      # 索引访问，输出 'R'
print(s[1:5])    # 切片访问，输出 'unoo'
```

### 字符串格式化

```python
name = "Alice"
age = 18
# f-string (Python 3.6+)
print(f"我叫 {name}, 今年 {age} 岁。")
# format 方法
print("我叫 {}, 今年 {} 岁。".format(name, age))
```

### 常用内置方法 (Methods)

```python
s = " hello world "

# 大小写转换
print(s.capitalize())   # 首字母大写: " Hello world "
print(s.upper())        # 全大写: " HELLO WORLD "
print(s.lower())        # 全小写: " hello world "

# 搜索与替换
print(s.find("world"))  # 查找子串索引，未找到返回 -1
print(s.replace("world", "Python")) # 替换: " hello Python "
print(s.count("l"))     # 统计出现次数

# 去除空白
print(s.strip())        # 去除首尾空格: "hello world"

# 分割与连接
lst = s.split()         # 默认按空格分割: ['hello', 'world']
print("-".join(lst))    # 连接: "hello-world"

# 判断
print("123".isdigit())  # 是否全为数字: True
print("abc".isalpha())  # 是否全为字母: True
```

***

## 5. 列表 (List)

列表是写在方括号 `[]` 之间、用逗号分隔开的元素列表。列表索引从 0 开始。

### 基础操作

```python
list1 = ['Google', 'Runoob', 1997, 2000]
list1[2] = 2001          # 更新列表
del list1[2]             # 删除元素
```

### 列表内置函数与方法

```python
nums = [3, 1, 4, 1, 5, 9]

# 通用函数
print(len(nums))    # 长度: 6
print(max(nums))    # 最大值: 9
print(list((1, 2))) # 强制转换为列表

# 列表对象方法
nums.append(2)      # 末尾添加元素: [3, 1, 4, 1, 5, 9, 2]
nums.insert(1, 10)  # 指定位置插入: [3, 10, 1, 4, 1, 5, 9, 2]
nums.pop()          # 移除末尾元素并返回
nums.remove(4)      # 移除第一个匹配值
print(nums.count(1))# 统计元素出现次数

nums.sort()         # 排序 (修改原列表)
print(nums)         # 输出: [1, 1, 3, 5, 9, 10]

nums[::-1]
nums.reverse()      # 反转
nums.clear()        # 清空列表
```

***

## 6. 元组 (Tuple)

元组与列表类似，不同之处在于元组的**元素不能修改**。元组写在小括号 `()` 里。

### 基础操作

```python
tup1 = ('Google', 'Runoob', 1997, 2000)
tup2 = (1, 2, 3, 4, 5)

# 访问
print(tup1[0])
print(tup2[1:3])

# 注意：包含一个元素的元组需要加逗号
tup3 = (50,) 
```

### 元组内置函数

由于元组不可变，它没有 `append`、`sort` 等修改方法。

```python
tup = (3, 1, 4, 1, 5, 9)
print(len(tup))     # 计算元素个数
print(max(tup))     # 返回最大值
print(min(tup))     # 返回最小值
print(tuple([1,2])) # 将列表转换为元组
```

***

## 7. 字典 (Dictionary)

字典是可变容器模型，可存储任意类型对象。字典的每个键值 `key:value` 对用冒号分割，整个字典包括在花括号 `{}` 中。**键必须是唯一的，且不可变。**

### 基础操作

```python
d = {'Name': 'Runoob', 'Age': 7, 'Class': 'First'}
print(d['Name'])        # 访问
d['Age'] = 8            # 修改
d['School'] = "菜鸟"    # 添加
del d['Name']           # 删除条目
```

### 字典内置函数与方法

```python
d = {'Name': 'Runoob', 'Age': 7}

# 内置函数
print(len(d))       # 计算键值对数量
print(str(d))       # 输出字典可打印的字符串表示

# 对象方法
print(d.keys())     # 返回所有键: dict_keys(['Name', 'Age'])
print(d.values())   # 返回所有值
print(d.items())    # 返回所有键值对元组

print(d.get('Age'))         # 安全地获取值，不存在不报错
print(d.get('Sex', 'NA'))   # 获取值，不存在返回默认值 'NA'

d.pop('Age')        # 删除并返回指定键的值
d.update({'Age': 10, 'Sex': 'Male'}) # 更新/合并字典
d.clear()           # 清空字典
```

***

## 8. 集合 (Set)

集合是一个无序的不重复元素序列。可以使用大括号 `{}` 或者 `set()` 函数创建集合。
**注意**：创建一个空集合必须用 `set()` 而不是 `{}`，因为 `{}` 是用来创建一个空字典。

### 基础操作

```python
basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}
print(basket)  # 自动去重，输出可能乱序

# 集合运算
a = set('abracadabra')
b = set('alacazam')
print(a - b)   # 差集
print(a | b)   # 并集
print(a & b)   # 交集
print(a ^ b)   # 对称差集（不同时存在的元素）
```

### 集合内置方法

```python
s = {1, 2, 3}

s.add(4)            # 添加元素
s.update([5, 6])    # 添加多个元素
s.remove(1)         # 移除元素，不存在会报错
s.discard(10)       # 移除元素，不存在不会报错
s.pop()             # 随机移除一个元素
s.clear()           # 清空
```

***

## 9. 条件控制 (Conditionals)

Python 通过 `if` 语句实现条件控制。

### 语法结构

```python
# if - elif - else
age = 20
if age < 0:
    print("输入错误")
elif age < 18:
    print("未成年")
else:
    print("已成年")

# 嵌套 if
num = 8
if num % 2 == 0:
    if num % 3 == 0:
        print("能被 2 和 3 整除")
    else:
        print("能被 2 整除，但不能被 3 整除")
```

***

## 10. 循环语句 (Loops)

Python 提供了 `while` 和 `for` 循环。

### While 循环

```python
n = 0
sum = 0
while n <= 10:
    sum += n
    n += 1
print(f"1到10之和为: {sum}")
```

### For 循环

常用于遍历序列（列表、元组、字符串）或使用 `range()`。

```python
sites = ["Baidu", "Google","Runoob","Taobao"]
for site in sites:
    print(site)

# 使用 range()
for i in range(5):       # 0 到 4
    print(i, end=',') 

for i in range(0, 10, 3): # 步长为 3: 0, 3, 6, 9
    print(i)
```

### 循环控制语句

* **break**: 跳出整个循环。
* **continue**: 跳过当前循环块中的剩余语句，继续下一轮循环。
* **pass**: 空语句，为了保持程序结构的完整性。

```python
for letter in 'Runoob': 
   if letter == 'o':
      continue # 跳过 'o'
   if letter == 'b':
      break    # 遇到 'b' 结束循环
   print('当前字母 :', letter)
```

***

## 11. Python 3 函数 (Function) 教程

函数是组织好的，可重复使用的，用来实现单一，或相关联功能的代码段。函数能提高应用的模块性，和代码的重复利用率。

### 1. 定义一个函数

你可以定义一个由自己想要功能的函数，以下是简单的规则：

* 函数代码块以 `def` 关键词开头，后接函数标识符名称和圆括号 `()`。
* 任何传入参数和自变量必须放在圆括号中间。圆括号之间可以用于定义参数。
* 函数的第一行语句可以选择性地使用文档字符串—用于存放函数说明。
* 函数内容以冒号 `:` 起始，并且缩进。
* `return [表达式]` 结束函数，选择性地返回一个值给调用方。不带表达式的 return 相当于返回 None。

**语法**

```python
def 函数名(参数列表):
    "函数_文档字符串"
    函数体
    return [表达式]
```

**实例**

```python
def hello():
    print("Hello, World!")

hello() # 调用函数
```

***

### 2. 参数传递 (重点)

在 Python 中，类型属于对象，变量是没有类型的：

```python
a = [1,2,3]
a = "Runoob"
```

以上代码中，`[1,2,3]` 是 List 类型，`"Runoob"` 是 String 类型，而变量 `a` 是没有类型的，它仅仅是一个对象的引用（一个指针），可以指向 List 也可以指向 String。

**可变(Mutable)与不可变(Immutable)对象**

在 Python 中，strings, tuples, 和 numbers 是**不可变**的对象，而 list, dict 等则是**可变**的对象。

1. **不可变类型传递**：类似 C++ 的值传递，如 整数、字符串、元组。如 `fun(a)`，传递的只是 `a` 的值，没有影响 `a` 对象本身。如果在 `fun(a)` 内部修改 `a` 的值，则是新生成一个 `a` 的对象。
2. **可变类型传递**：类似 C++ 的引用传递，如 列表，字典。如 `fun(la)`，则是将 `la` 真正的传过去，修改后 `fun` 外部的 `la` 也会受影响。

**实例：传不可变对象**

```python
def change_int(a):
    a = 10

b = 2
change_int(b)
print(b) # 结果是 2，没有变
```

**实例：传可变对象**

```python
def change_list(mylist):
   mylist.append([1, 2, 3, 4])
   print("函数内取值: ", mylist)

mylist = [10, 20, 30]
change_list(mylist)
print("函数外取值: ", mylist)
# 函数外取值也会包含 [1, 2, 3, 4]，因为列表被修改了
```

***

### 3. 参数类型

调用函数时可使用的正式参数类型：

**必需参数**

必需参数须以正确的顺序传入函数。调用时的数量必须和声明时的一样。

```python
def printme(str):
    print(str)
    return

# printme() # 报错：缺少参数
printme("Runoob") # 正确
```

**关键字参数**

使用关键字参数允许函数调用时参数的顺序与声明时不一致，因为 Python 解释器能够用参数名匹配参数值。

```python
def printinfo(name, age):
   print(f"名字: {name}, 年龄: {age}")
   return
printinfo(age=18, name="Runoob") # 顺序不同也没关系
```

**默认参数**

调用函数时，如果没有传递参数，则会使用默认参数。

```python
def printinfo(name, age=35):
   print(f"名字: {name}, 年龄: {age}")

printinfo(name="miki") # age 默认为 35
printinfo(name="miki", age=18)
```

***

### 4. return 语句

`return` 语句退出函数。

```python
def sum(arg1, arg2):
   total = arg1 + arg2
   print("函数内 : ", total)
   return total

total = sum(10, 20)
```

***

### 5. 变量作用域

Python 中，程序的变量并不是在哪个位置都可以访问的，访问权限决定于这个变量是在哪里赋值的。

* **全局变量 (Global)**: 定义在函数外部的变量。
* **局部变量 (Local)**: 定义在函数内部的变量。

```python
total = 0 # 这是一个全局变量

def sum(arg1, arg2):
   total = arg1 + arg2 # total在这里是局部变量
   print("函数内是局部变量 : ", total)
   return total

sum(10, 20)
print("函数外是全局变量 : ", total)
```

***

### 6. global 关键字

如果要修改全局变量，需要使用 `global` 关键字。

```python
num = 1
def fun1():
    global num  # 需要使用 global 关键字声明
    print(num) 
    num = 123
    print(num)

fun1()
print(num) # 全局变量也被修改为 123
```

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson3-sort-2025.md
description: 算法入门讲义，涵盖时间复杂度、空间复杂度、排序算法与二分查找基础。
---

# 算法入门：复杂度、排序与二分查找

## 1. 时间与空间复杂度

在算法竞赛中，时间复杂度和空间复杂度是评估算法性能的关键指标，通常更侧重于时间复杂度。

### 1.1. 概述

* **时间复杂度：** 描述算法的执行效率（运行时间）。越低越好。
* **空间复杂度：** 描述算法占用的内存量。在算法竞赛中，时间复杂度通常是主要挑战，空间限制一般较宽松，但仍需注意。

### 1.2. 时间复杂度

#### 1.2.1. 定义与表示法

时间复杂度描述了算法执行时间随输入数据规模 N 变化的趋势。我们使用大 O 表示法 O(f(N)) 来表示。

**常见的时间复杂度函数（高中数学函数）：**

* $O(1)$ (常数时间)
* $O(\log N)$ (对数时间；底数通常不重要，所以 $O(\log\_2 N)$ 或 $O(\ln N)$ 都简化为 $O(\log N)$)
* $O(\sqrt{N})$ (平方根时间)
* $O(N)$ (线性时间)
* $O(N \log N)$ (线性对数时间)
* $O(N^2)$ (平方时间)
* $O(N^3)$ (立方时间)
* $O(2^N)$ (指数时间)
* $O(N!)$ (阶乘时间)

**函数性质：**

* 在算法竞赛中，数据规模 N 通常是非负的（$N \ge 1$），所以我们只考虑函数在第一象限的行为。
* 在第一象限，上面列出的函数都是递增的，意味着执行时间随 N 的增长而增长。
* **核心原则：忽略常数因子。** 例如，O(2N) 和 O(5N) 都被视为 O(N)。这是因为大 O 表示法代表增长趋势，常数因子不影响渐近行为。
* **O(1) 的特殊性：** 当操作次数是常数时（例如 A+B），我们用 O(1) 来表示。

#### 1.2.2. 时间复杂度分析示例

**寻找数组中的最小值**

* **问题：** 给定一个长度为 N 的数组 A，找到最小值。

* **逻辑：** 遍历数组一次，维护当前的最小值。

* **数据范围：** $N \le 200,000$。

* **伪代码结构：**

  ```cpp
  const int MAXN = 200000 + 5; // 常见做法，分配稍大的数组以防越界
  int a[MAXN]; // 或使用 vector<int> a;
  int n;
  // cin >> n; // 读入 N
  // 循环读入 a[1]...a[N] (算法竞赛推荐1-based索引)

  int min_val = 2e9; // 初始化为正无穷 (2 * 10^9)
  for (int i = 1; i <= n; ++i) { // 循环 N 次
      // min_val = min(min_val, a[i]); // 每次操作是常数时间
      if (a[i] < min_val) {
          min_val = a[i];
      }
  }
  // cout << min_val;
  ```

* **复杂度分析：** 循环执行 N 次。循环内部的操作（比较、赋值、增量）都是常数时间。总操作数约为 $C \times N$。根据忽略常数的原则，时间复杂度为 $O(N)$。

**最大公约数 (GCD) - 欧几里得算法**

* **问题：** 找到两个正整数 X 和 Y 的最大公约数。

* **算法原理：** 基于 $GCD(X, Y) = GCD(Y, X \pmod Y)$，以及 $GCD(X, 0) = X$。

* **示例代码 (递归)：**

  ```cpp
  int gcd(int x, int y) {
      if (y == 0) {
          return x;
      }
      return gcd(y, x % y); // 递归调用
  }
  ```

* **复杂度分析：** 在每一步递归中，Y 都在减小，并且保证至少会减半（与斐波那契数列的逆向相关）。因此，该算法的时间复杂度为 $O(\log N)$，其中 N 是 X 和 Y 中较大的那个数。这里的对数底数不重要，因为 $\log\_a N = \frac{\log\_b N}{\log\_b a}$，意味着不同底数仅相差一个常数因子。

**一个特殊的嵌套 For 循环**

* **问题：** 计算以下嵌套循环的执行次数。

* **代码示例：**

  ```cpp
  int n; // 假设 n 已经输入
  long long c = 0; // 计数器
  for (int i = 1; i <= n; ++i) {
      for (int j = i; j <= n; j += i) {
          c++; // 每次执行时增加计数器
      }
  }
  // cout << c; // 输出最终计数
  ```

* **复杂度分析：**

  * 外层循环变量 `i` 从 1 到 N。
  * 内层循环变量 `j` 从 `i` 开始，每次增加 `i`，直到超过 `N`。
  * 当 `i=1` 时，`j` 取 1, 2, ..., N，执行 N/1 = N 次。
  * 当 `i=2` 时，`j` 取 2, 4, ..., N' (不超过N)，执行 N/2 次。
  * 当 `i=3` 时，`j` 取 3, 6, ..., N''，执行 N/3 次。
  * ...
  * 当 `i=N` 时，`j` 取 N，执行 N/N = 1 次。
  * 总执行次数为 $N/1 + N/2 + N/3 + \dots + N/N = N \times (1 + 1/2 + 1/3 + \dots + 1/N)$。
  * 括号中的部分是**调和级数**，其和约等于 $\ln N$ (自然对数)。
  * 因此，总执行次数约为 $N \ln N$。时间复杂度为 $O(N \log N)$。

### 1.3. 空间复杂度

空间复杂度衡量算法在执行过程中占用的临时存储空间。

* **单个变量：** $O(1)$ (常数空间)。例如 `int x;`。
* **长度为 N 的数组：** $O(N)$ (线性空间)。例如 `int arr[N];`。
* **N 行 M 列的二维数组：** $O(N \times M)$。

通常，算法竞赛中的空间限制是足够的，除非题目明确要求空间优化。

## 2. 冒泡排序 (Bubble Sort)

冒泡排序是最基础、最直观的排序算法之一。虽然它的效率不高，但理解冒泡排序有助于掌握排序算法的基本思想。

### 核心思想

冒泡排序的工作原理是：

1. **重复遍历**要排序的数组
2. **比较相邻元素**，如果它们的顺序错误就交换它们
3. **重复这个过程**，直到没有需要交换的元素，说明数组已经有序

较大的元素会像"气泡"一样逐渐"浮"到数组的末尾，这也是"冒泡排序"名称的由来。

### 代码实现

**基础版本：**

```cpp
// 对数组 a[1...n] 进行冒泡排序
void bubble_sort(int a[], int n) {
    // 外层循环：需要 n-1 轮
    for (int i = 1; i < n; i++) {
        // 内层循环：每轮比较相邻元素
        for (int j = 1; j <= n - i; j++) {
            // 如果前面的元素大于后面的，交换它们
            if (a[j] > a[j + 1]) {
                swap(a[j], a[j + 1]);
            }
        }
    }
}
```

**优化版本（提前终止）：**

```cpp
// 优化版冒泡排序
void bubble_sort_optimized(int a[], int n) {
    for (int i = 1; i < n; i++) {
        bool swapped = false; // 标记本轮是否发生交换
        
        for (int j = 1; j <= n - i; j++) {
            if (a[j] > a[j + 1]) {
                swap(a[j], a[j + 1]);
                swapped = true;
            }
        }
        
        // 如果本轮没有发生交换，说明已经有序，提前退出
        if (!swapped) break;
    }
}
```

### 算法步骤详解

以数组 `[5, 3, 8, 4, 2]` 为例，展示冒泡排序的执行过程：

**第 1 轮：**（从左到右比较相邻元素）

* 比较 5 和 3：5 > 3，交换 → `[3, 5, 8, 4, 2]`
* 比较 5 和 8：5 < 8，不交换 → `[3, 5, 8, 4, 2]`
* 比较 8 和 4：8 > 4，交换 → `[3, 5, 4, 8, 2]`
* 比较 8 和 2：8 > 2，交换 → `[3, 5, 4, 2, 8]` ✓（最大值 8 就位）

**第 2 轮：**

* 比较 3 和 5：3 < 5，不交换 → `[3, 5, 4, 2, 8]`
* 比较 5 和 4：5 > 4，交换 → `[3, 4, 5, 2, 8]`
* 比较 5 和 2：5 > 2，交换 → `[3, 4, 2, 5, 8]` ✓（次大值 5 就位）

**第 3 轮：**

* 比较 3 和 4：3 < 4，不交换 → `[3, 4, 2, 5, 8]`
* 比较 4 和 2：4 > 2，交换 → `[3, 2, 4, 5, 8]` ✓

**第 4 轮：**

* 比较 3 和 2：3 > 2，交换 → `[2, 3, 4, 5, 8]` ✓（排序完成）

### 复杂度分析

* **时间复杂度：**
  * 平均：$O(n^2)$ - 需要约 $n^2/2$ 次比较
  * 最坏：$O(n^2)$ - 数组完全逆序时
  * 最好：$O(n)$ - 数组已有序（优化版本）
* **空间复杂度：** $O(1)$ - 只需要常数级的额外空间
* **稳定性：** 稳定 - 相等元素的相对位置不会改变

### 为什么不推荐冒泡排序？

虽然冒泡排序简单易懂，但在实际应用中几乎不使用，原因如下：

1. **时间复杂度太高** - $O(n^2)$ 的复杂度在大数据量时效率极低
2. **实际性能差** - 即使是同为 $O(n^2)$ 的算法，冒泡排序的常数因子也较大
3. **有更好的选择** - 快速排序、归并排序等 $O(n \log n)$ 算法效率更高

**但是：** 理解冒泡排序有助于理解排序的基本思想和算法分析方法，在学习阶段仍有重要价值。

## 3. 快速排序 (Quick Sort)

快速排序是一种基于"分治"（Divide and Conquer）思想的高效排序算法。

### 核心思想

1. **分（Partition）：**
   * 从数组中选取一个元素作为“基准值”（Pivot）。
   * 重新排列数组，将所有小于基准值的元素移动到基准值的左侧，所有大于基准值的元素移动到基准值的右侧。
2. **治（Conquer）：**
   * 递归地对基准值左侧的子数组和右侧的子数组进行快速排序。
3. **合（Combine）：**
   * 由于是原地排序，当子数组排序完成后，整个数组即完成排序，无需合并。

### 代码模板

```c++
// a[] 是全局数组
void quick_sort(int l, int r) {
    if (l >= r) return; // 递归出口：区间内没有元素或只有一个元素

    // 1. 选取基准值 和 初始化指针
    int x = a[l + r >> 1], i = l - 1, j = r + 1;// a[l + r >> 1]是位运算，二进制值删去最后一位，相当于处以2，位运算符优先级比加减小，所以 l+r 不需要加括号

    // 2. 核心分区循环
    while (i < j) {
        // 3. 移动左指针
        while (a[++i] < x);
        // 4. 移动右指针
        while (a[--j] > x);
        
        // 5. 交换
        if (i < j) swap(a[i], a[j]);
    }

    // 6. 递归处理子区间
    quick_sort(l, j);
    quick_sort(j + 1, r);
}
```

### 步骤详解

1. **基准值与指针 (第 5 行)**
   * `if (l >= r) return;`：这是递归的终止条件。如果左边界 `l` 已经等于或超过了右边界 `r`，说明这个区间最多只有一个元素，自然是有序的，直接返回。
   * `int x = a[l + r >> 1]`：选取区间的**中间位置**的元素作为基准值 `x`。`l + r >> 1` 是 `(l + r) / 2` 的位运算写法，效率更高。
   * `i = l - 1, j = r + 1`：这是此模板的**精髓所在**。`i` 和 `j` 指针分别从**待排序区间的外侧**开始。`i` 从左边界-1 开始，`j` 从右边界+1 开始。
2. **分区循环 (第 8 行)**
   * `while (i < j)`：当左指针 `i` 仍然在右指针 `j` 的左侧时，继续分区。当 `i >= j` 时，分区结束。
3. **移动左指针 (第 10 行)**
   * `while (a[++i] < x);`：**先将 `i` 右移一位（`++i`）**，然后比较 `a[i]` 和 `x`。只要 `a[i]` 小于基准值 `x`，就继续右移。
   * 循环结束时，`i` 会停在**第一个大于等于 `x`** 的元素的位置上。
4. **移动右指针 (第 12 行)**
   * `while (a[--j] > x);`：**先将 `j` 左移一位（`--j`）**，然后比较 `a[j]` 和 `x`。只要 `a[j]` 大于基准值 `x`，就继续左移。
   * 循环结束时，`j` 会停在**第一个小于等于 `x`** 的元素的位置上。
5. **交换 (第 15 行)**
   * `if (i < j) swap(a[i], a[j]);`：
   * 此时，`a[i]` 是左侧找到的 "不该在左侧" 的元素（$\ge x$），`a[j]` 是右侧找到的 "不该在右侧" 的元素（$\le x$）。
   * 如果 `i < j`，说明 `i` 还在 `j` 的左边，两者尚未相遇，所以我们交换它们，将它们放到正确的分区。
   * 如果 `i >= j`，说明两个指针已经相遇或交错，分区过程结束，跳出 `while (i < j)` 循环。
6. **递归 (第 19-20 行)**
   * `quick_sort(l, j);`
   * `quick_sort(j + 1, r);`
   * **为什么是 `j` 和 `j+1`？** 这是此模板的**第二个精髓**。
   * 当 `while (i < j)` 循环结束时，`j` 左侧（包括 `j`）的所有元素都**小于等于**基准值 `x`，`j` 右侧的所有元素都**大于等于**基准值 `x`。
   * 因此，我们将数组分为 `[l, j]` 和 `[j + 1, r]` 两个子区间，分别进行递归排序。
   * **思考：** 为什么不用 `i` 来划分？因为当循环结束时，`i` 和 `j` 可能重合（`i == j`），也可能交错（`i == j + 1`）。但无论哪种情况，`j` 始终是左侧分区的“分界点”。使用 `[l, j]` 和 `[j+1, r]` 来划分区间，可以完美覆盖所有情况，不多也不少。

### 复杂度

* **时间复杂度：**
  * 平均：$O(n \log n)$
  * 最坏：$O(n^2)$ （当数组已经有序或接近有序，且基准值总选到最大/最小值时）
* **空间复杂度：** $O(\log n)$ （递归栈的深度）
* **稳定性：** 不稳定

## 4. 归并排序 (Merge Sort)

归并排序是另一种基于"分治"思想的排序算法，它以稳定、高效著称。

### 核心思想

1. **分（Divide）：** 不断将当前数组对半切分，直到每个子数组只剩一个元素（天然有序）。
2. **治（Conquer）：** 这一步在归并排序中体現在“合”的阶段。
3. **合（Merge）：** 将两个**已经有序**的子数组，合并成一个新的、更大的有序数组。

### 代码模板解析

```cpp
// a[] 和 N 是全局的
void merge_sort(int l, int r) {
    if (l >= r) return; // 递归出口

    // 1. 临时数组，用于合并
    int temp[N]; 
    
    // 2. 分：计算中点并递归
    int mid = l + r >> 1;
    merge_sort(l, mid);
    merge_sort(mid + 1, r);

    // 3. 合：合并两个有序子数组 [l, mid] 和 [mid+1, r]
    int k = 0, i = l, j = mid + 1;
    while (i <= mid && j <= r) {
        if (a[i] < a[j]) temp[k++] = a[i++];
        else temp[k++] = a[j++];
    }

    // 4. 处理剩余元素
    while (i <= mid) temp[k++] = a[i++];
    while (j <= r) temp[k++] = a[j++];

    // 5. 将排好序的 temp 数组复制回原数组 a
    for (int i = l, j = 0; i <= r; i++, j++) a[i] = temp[j];
}
```

### 步骤详解

1. **临时数组 (第 5 行)**
   * `int temp[N];`：归并排序的**核心代价**在于需要一个额外的 $O(n)$ 空间。`temp` 数组用于在“合并”阶段临时存放排好序的元素。
   * *注意：* 你给的模板在*递归函数内部*声明了 `temp`。这意味着每次递归调用都会声明一个 `temp` 数组，这在空间上是低效的（虽然功能上没错）。更优化的写法是将 `temp` 作为全局变量或在 `merge_sort` 之外声明，通过参数传入。但我们这里只解析你给的模板。
2. **分 (第 8-10 行)**
   * `int mid = l + r >> 1;`：计算中点。
   * `merge_sort(l, mid), merge_sort(mid + 1, r);`：递归地对左右两个子区间进行排序。当这两行代码执行完毕后，我们**可以保证** `a[l...mid]` 和 `a[mid+1...r]` 两个子数组**各自内部**已经是有序的了。
3. **合 (第 13-17 行)**
   * `k = 0, i = l, j = mid + 1;`：`i` 是左半边有序数组的指针，`j` 是右半边有序数组的指针，`k` 是 `temp` 数组的指针。
   * `while (i <= mid && j <= r)`：当两个子数组都还有元素时，进行比较。
   * `if (a[i] < a[j])...`：将 `a[i]` 和 `a[j]` 中较小的那个元素放入 `temp` 数组，并移动相应的指针。
4. **处理剩余 (第 20-21 行)**
   * 上面的 `while` 循环结束后，`i` 和 `j` 中必定有一个指针已经越界（即它所指向的子数组已经全部存入 `temp`）。
   * 这两个 `while` 循环的作用是，将另一个**未越界**的子数组中**剩余**的元素（它们本身已经有序且都大于已存入 `temp` 的元素）全部复制到 `temp` 数组的末尾。
5. **复制回原数组 (第 24 行)**
   * `for (int i = l, j = 0; i <= r; i++, j++) a[i] = temp[j];`
   * 这是至关重要的一步。此时 `temp` 数组的 `[0...k-1]`（即 `temp[0...r-l]`）中存放的是 `a[l...r]` 区间合并排序后的结果。
   * 这个循环将 `temp` 中的元素**按顺序**复制回**原数组 `a` 的 `[l...r]` 位置**。注意 `i` 从 `l` 开始，`j` 从 `0` 开始。

### 复杂度

* **时间复杂度：** $O(n \log n)$ （无论最好最坏，都非常稳定）
* **空间复杂度：** $O(n)$ （需要 `temp` 数组）
* **稳定性：** 稳定（在 `a[i] < a[j]` 的判断中，如果不加等号，可以保证相等元素的相对顺序不变）

> ### (〃∀〃)
>
> 恭喜！你刚刚学完了两种最核心的 $O(n \log n)$ 排序算法。
>
> **然而，在 99% 的实际开发和算法竞赛中...**
>
> 忘掉它们（bushi），然后无脑用 C++ 的 `std::sort` 就完事了！
>
> 它更快（经过高度优化）、更安全（规避了最坏情况）、更省心（`sort(a, a+n);` 一行搞定）。
>
> *（严肃脸：当然，归并排序的"稳定"特性和"分治"思想本身还是需要牢记的！面试要考！）*

## 5. 二分查找 (Binary Search)

二分查找（或称折半查找）是一种在**有序数组**中查找某一特定元素的搜索算法。它的核心思想是不断地将搜索区间减半。
![](https://gastigado.cnies.org/d/public/157380_f93a5c31dc-PIC2.png)

下面有两个模板，它们分别用于解决两种最常见的二分问题：

1. **模板1：** 在一个区间内找到\*\*满足某个条件的最小（最左侧）\*\*的值。
2. **模板2：** 在一个区间内找到\*\*满足某个条件的最大（最右侧）\*\*的值。

### 模板 1：查找左边界

```cpp
// 检查 q[mid] 是否 "大于等于 x"
// 区间 [l, r] 被划分为 [l, mid] 和 [mid+1, r]
// check 函数是判断要找的值是否符合条件
while (l < r) {
    int mid = l + r >> 1; // (l+r)/2，向下取整
    if (check(q[mid])) r = mid; // check为true，答案可能在[l, mid]
    else l = mid + 1; // check为false，答案一定在[mid+1, r]
}
// 循环结束时 l == r，即为答案
```

**用途：** 查找**第一个**满足 `check()` 为 `true` 的位置。

* 例如：在一个升序数组中，找到第一个 $\ge x$ 的数。

**流程解析：**

1. `int mid = l + r >> 1;`：`mid` 向下取整。
2. `if (check(q[mid])) r = mid;`
   * 如果 `q[mid]` 满足条件（例如 `q[mid] >= x`），说明 `mid` **有可能是**我们要找的那个 "最左侧" 的答案，或者答案在 `mid` 的左边。
   * 我们不能排除 `mid`，所以我们将搜索区间的右边界缩小为 `r = mid`。新的搜索区间是 `[l, mid]`。
3. `else l = mid + 1;`
   * 如果 `q[mid]` 不满足条件（例如 `q[mid] < x`），说明 `mid` **一定不是**答案，并且 `mid` 左侧的所有元素也一定不是答案。
   * 所以我们将搜索区间的左边界扩大为 `l = mid + 1`。新的搜索区间是 `[mid + 1, r]`。

**为什么不会死循环？**

* 当 `l` 和 `r` 只差 1 时，即 `l = r - 1`。
* 此时 `mid = (l + l + 1) >> 1 = l`。
* `if (check(q[l]))`：`r = l`，循环结束。
* `else`：`l = l + 1`，`l` 变成 `r`，循环结束。
* 两种情况都能正常退出。

### 模板 2：查找右边界

```cpp
// 检查 q[mid] 是否 "小于等于 x"
// 区间 [l, r] 被划分为 [l, mid-1] 和 [mid, r]
// check 函数是判断要找的值是否符合条件
while (l < r) {
    int mid = l + r + 1 >> 1; // (l+r+1)/2，向上取整
    if (check(q[mid])) l = mid; // check为true，答案可能在[mid, r]
    else r = mid - 1; // check为false，答案一定在[l, mid-1]
}
// 循环结束时 l == r，即为答案
```

**用途：** 查找**最后一个**满足 `check()` 为 `true` 的位置。

* 例如：在一个升序数组中，找到最后一个 $\le x$ 的数。

**流程解析：**

1. `int mid = l + r + 1 >> 1;`：**这是此模板的精髓！** `mid` **向上取整**。
2. `if (check(q[mid])) l = mid;`
   * 如果 `q[mid]` 满足条件（例如 `q[mid] <= x`），说明 `mid` **有可能是**我们要找的那个 "最右侧" 的答案，或者答案在 `mid` 的右边。
   * 我们不能排除 `mid`，所以我们将搜索区间的左边界扩大为 `l = mid`。新的搜索区间是 `[mid, r]`。
3. `else r = mid - 1;`
   * 如果 `q[mid]` 不满足条件（例如 `q[mid] > x`），说明 `mid` **一定不是**答案，并且 `mid` 右侧的所有元素也一定不是答案。
   * 所以我们将搜索区间的右边界缩小为 `r = mid - 1`。新的搜索区间是 `[l, mid - 1]`。

**为什么必须 `+ 1`？（防止死循环）**

* 假设我们**不加 `+ 1`**，即 `mid = l + r >> 1`（向下取整）。
* 考虑当 `l` 和 `r` 只差 1 时，即 `l = r - 1`。
* 此时 `mid = (l + l + 1) >> 1 = l`。
* `if (check(q[l]))`：`l = mid = l`。`l` 和 `r` 的值**都没有改变**。
* `else`：`r = l - 1`，循环会结束。
* **问题在于：** 如果 `check(q[l])` 总是为 `true`，`l` 将永远等于 `mid`，`l` 和 `r` 的值都不会变，`while (l < r)` 将**无限循环**！
* **解决方案：**
* 我们使用 `mid = l + r + 1 >> 1`（向上取整）。
* 当 `l = r - 1` 时，`mid = (l + l + 1 + 1) >> 1 = (2l + 2) >> 1 = l + 1 = r`。
* `if (check(q[r]))`：`l = mid = r`，`l == r`，循环结束。
* `else`：`r = mid - 1 = r - 1 = l`，`l == r`，循环结束。
* 两种情况都能正常退出。

**总结 (二分)：**

* 当你的更新逻辑是 `l = mid` 时，`mid` 必须**向上取整**（`+ 1`）。
* 当你的更新逻辑是 `r = mid` 时，`mid` 必须**向下取整**（不 `+ 1`）。

## 6. 总结对比 (所有算法)

| **算法**               | **核心思想** | **平均时间**   | **最坏时间**  | **空间**    | **稳定性** | **备注**               |
| ---------------------- | ------------ | -------------- | ------------- | ----------- | ---------- | ---------------------- |
| **冒泡排序**           | 交换         | $O(n^2)$       | $O(n^2)$      | $O(1)$      | **稳定**   | 简单但低效，仅用于学习 |
| **快速排序**           | 分治         | $O(n \log n)$  | $O(n^2)$      | $O(\log n)$ | 不稳定     | 原地排序，实现精妙     |
| **归并排序**           | 分治         | $O(n \log n)$  | $O(n \log n)$ | $O(n)$      | **稳定**   | 时间稳定，但需额外空间 |
| **二分查找**           | 减治         | $O(\log n)$    | $O(\log n)$   | $O(1)$      | N/A        | **前提：数组必须有序** |
| **`std::sort`**        | 混合排序     | $O(n \log n)$! | $O(n \log n)$ | $O(\log n)$ | 不稳定     | **（推荐）** C++标准库 |
| **`std::stable_sort`** | 归并排序     | $O(n \log n)$  | $O(n \log n)$ | $O(n)$      | **稳定**   | C++标准库              |

## 7. 例题

## 1. 排序

### P1923 【深基9.例4】求第 k 小的数

#### 题目描述

输入 $n$（$1 \le n < 5000000$ 且 $n$ 为奇数）个数字 $a\_i$（$1 \le a\_i < {10}^9$），输出这些数字的第 $k$ 小的数。最小的数是第 $0$ 小。

请尽量不要使用 `nth_element` 来写本题，因为本题的重点在于练习分治算法。

#### 输入格式

第一行有两个整数，分别表示 $n$ 和 $k$。

第二行有 $n$ 个整数，第 $i$ 个数表示 $a\_i$。

#### 输出格式

一个整数，表示第 $k$ 小的数。

#### 输入输出样例 #1

**输入 #1**

```text
5 1
4 3 2 1 5
```

**输出 #1**

```text
2
```

```c++
#include<bits/stdc++.h>
using namespace std;
int miku[5000000];
void fufu(int a,int b){
    int mid=miku[(a+b)/2],i=a,j=b;
    while (i<=j){
        while(miku[i]<mid) i++;
        while(miku[j]>mid) j--;
        if (i<=j){
            swap(miku[i],miku[j]);
            i++;
            j--;
        }
    }
    if (i<b)fufu(i,b);
    if (j>a)fufu(a,j);
}
int main(){
    int n,k;
    scanf("%d %d",&n,&k);
    for (int i=0;i<n;i++){
        scanf("%d",&miku[i]);
    }
    fufu(0,n-1);
    printf("%d",miku[k]);
    return 0;
}
```

## 2. 二分

### P1024 \[NOIP 2001 提高组] 一元三次方程求解

#### 题目描述

有形如：$a x^3 + b x^2 + c x + d = 0$  这样的一个一元三次方程。给出该方程中各项的系数（$a,b,c,d$ 均为实数），并约定该方程存在三个不同实根（根的范围在 $-100$ 至 $100$ 之间），且根与根之差的绝对值 $\ge 1$。要求由小到大依次在同一行输出这三个实根(根与根之间留有空格)，并精确到小数点后 $2$ 位。

提示：记方程 $f(x) = 0$，若存在 $2$ 个数 $x\_1$ 和 $x\_2$，且 $x\_1 < x\_2$，$f(x\_1) \times f(x\_2) < 0$，则在 $(x\_1, x\_2)$ 之间一定有一个根。

#### 输入格式

一行，$4$ 个实数 $a, b, c, d$。

#### 输出格式

一行，$3$ 个实根，从小到大输出，并精确到小数点后 $2$ 位。

#### 输入输出样例 #1

**输入 #1**

```text
1 -5 -4 20
```

**输出 #1**

```text
-2.00 2.00 5.00
```

#### 说明/提示

**【题目来源】**

NOIP 2001 提高组第一题

```c++
#include<iostream>
#include<algorithm>
#include<vector>
#include<cstring>
using namespace std;
double a,b,c,d;
int sum=0;
double check(double x){
    double s=a*x*x*x+b*x*x+c*x+d;
    return s;
}
int main(){
    cin>>a>>b>>c>>d;
    for(double i=-100.0;i<100.0;i+=0.001){
        if(check(i)-0<1e-4&&0-check(i)<1e-4){
            printf("%.2lf ",i);
            sum++;
            if(sum==3)break;
        }
    }
    return 0;
}
```

### P2440 木材加工

#### 题目背景

要保护环境。

#### 题目描述

木材厂有 $n$ 根原木，现在想把这些木头切割成 $k$ 段长度**均**为 $l$ 的小段木头（木头有可能有剩余）。

当然，我们希望得到的小段木头越长越好，请求出 $l$ 的最大值。

木头长度的单位是 $\text{cm}$，原木的长度都是正整数，我们要求切割得到的小段木头的长度也是正整数。

例如有两根原木长度分别为 $11$ 和 $21$，要求切割成等长的 $6$ 段，很明显能切割出来的小段木头长度最长为 $5$。

#### 输入格式

第一行是两个正整数 $n,k$，分别表示原木的数量，需要得到的小段的数量。

接下来 $n$ 行，每行一个正整数 $L\_i$，表示一根原木的长度。

#### 输出格式

仅一行，即 $l$ 的最大值。

如果连 $\text{1cm}$ 长的小段都切不出来，输出 `0`。

#### 输入输出样例 #1

**输入 #1**

```text
3 7
232
124
456
```

**输出 #1**

```text
114
```

#### 说明/提示

#### 数据规模与约定

对于 $100%$ 的数据，有 $1\le n\le 10^5$，$1\le k\le 10^8$，$1\le L\_i\le 10^8(i\in\[1,n])$。

```c++
#include<iostream>
#include<algorithm>
using namespace std;
const int N=1e8+10;
int miku[N];
int n,k;
bool check(int x){
    int s=0;
    for(int i=0;i<n;i++){
        s+=miku[i]/x;
    }
    if(s>=k)return true;
    return false;
}
int main(){
    cin>>n>>k;
    for(int i=0;i<n;i++){
        cin>>miku[i];
    }
    sort(miku,miku+n);
    int l=0,r=miku[n-1];
    while(l<r){
        int mid=l+r+1>>1;
        if(!check(mid))r=mid-1;
        else l=mid;
    }
    cout<<l;
    return 0;
}
```

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson5-linux.md
---
# 讲座：Linux 基础入门

***

## 一、为什么要学 Linux

今天要讲的不是某个单独的软件，而是一套操作系统。它负责管理 CPU、内存、磁盘这些硬件资源，也负责让各种软件正常运行。

* **Linux 的起源**：它最初由芬兰人 **林纳斯·托瓦兹**（Linus Torvalds）在赫尔辛基大学读书时编写出内核。

* **核心优势**：相比 Windows，Linux 通常更轻量，资源利用率更高，也更方便按需要做定制。

* **广泛的应用**：它是自由传播的类 Unix 系统，支撑着全球 **90% 以上**的互联网服务器，在 AI、云计算和现代软件开发工具链里也很常见。很多开发环境、服务器和竞赛训练环境都离不开它。

***

## 二、准备工作和一个重要观念

### 1. 环境搭建：虚拟机 (VMware)

正式上手前，先准备一个实验环境。用虚拟机软件（如 **VMware**），可以在现有的 Windows 系统里模拟出一台独立电脑，再在里面安装 Linux。

* **优点**：虚拟机和宿主系统是隔离的。就算你把系统折腾坏了，也能靠“快照”恢复到之前的状态。

### 2. 核心哲学：“一切皆文件”

这是 Linux 里很重要的一个设计思路。

* **统一接口**：Linux 会把硬盘、键盘、系统状态等对象都抽象成“文件”，这样很多东西都能用同一套方式处理。

* **透明性**：很多系统信息都能通过查看对应文件拿到，这让排查问题和写程序都方便不少。

***

## 三、指令实战：常用命令

这部分是今天的重点。Linux 很多操作都在命令行里完成。

### 1. 基础生存指令（定位与查看）

| **命令**  | **全称**                | **功能描述**                  |
| --------- | ----------------------- | ----------------------------- |
| **`pwd`** | Print Working Directory | 打印当前工作目录的完整路径。 |
| **`ls`**  | List files              | 列出目录内容及文件名。 |
| **`cd`**  | Change directory        | 切换工作目录。 |
| **`man`** | Manual                  | 查看命令的参考手册。 |

* **`ls` 常用参数**：
  * `ls -a`：显示所有文件，包括以 `.` 开头的隐藏文件。
  * `ls -l`：以长格式显示文件权限、所有者、大小等信息。
* **路径概念**：
  * **绝对路径**：以 `/` 开头，起点是根目录。
  * **相对路径**：不以 `/` 开头，起点是当前所在目录。
  * `cd ..`：回到上一级目录。

### 2. 文与目录操作

* **`touch`**：创建空文件，或者更新文件时间属性。
* **`mkdir`**：创建目录。
* **`cp` (Copy)**：复制文件或目录。
* **`mv` (Move)**：移动文件或目录，也常用来**重命名**。
* **`rm` (Remove)**：删除文件或目录。**注意：Linux 没有回收站，删之前先确认。**
* **`ln` (Link)**：创建链接文件，类似 Windows 里的快捷方式。
* **读取内容**：
  * `cat`：从第一行开始正向读取并输出内容。
  * `tac`：从最后一行开始反向读取内容。

### 3. 权限与身份管理

Linux 是多用户系统，每个文件都有自己的权限位，例如 `-rwxr-xr--`。

* **权限解析**：
  * **第 1 位**：类型（`-` 为文件，`d` 为目录）。
  * **2-4 位**：所有者权限。
  * **5-7 位**：所属组权限。
  * **8-10 位**：其他用户权限。
* **`chmod`（修改权限）**：
  * **数字模式**：读(4)、写(2)、执行(1)。
  * *示例*：`chmod 777 filename` 代表给所有人读、写、执行权限。
* **身份指令**：
  * `useradd` / `userdel`：添加或删除系统用户。
  * `whoami`：查看当前登录用户名。

### 4. 软件管理与效率工具

* **`sudo`**：临时获取超级用户权限，用来执行需要更高权限的操作。

* **`apt`**：常用包管理器。输入 `sudo apt install [软件名]` 就可以安装软件。

* **`alias`**：给命令起简短别名，例如 `alias mk=mkdir`；用 `unalias` 取消别名。

* **趣味互动**：可以试试 `sudo apt install sl`，装一个会在终端里跑的小火车。

***

## 四、进阶工具：Vim

Vim 是很多程序员常用的文本编辑器，功能很多，上手门槛也不低。

> **提示**：刚接触 Vim 时大概率会不习惯，但把基本操作记住后，改文件会很顺手。

**三步走实战**：

1. **进入**：输入 `vim hello.c` 进入编辑器。
2. **编辑**：按 **`i` 键** 进入编辑模式编写代码。
3. **保存**：按 **Esc** 键，随后输入 **`:wq`**（冒号、w、q）保存并退出 。

**编译运行**：使用 `gcc hello.c -o hello` 编译，然后输入 `./hello` 执行程序。

***

## 五、遇到问题怎么办

学 Linux 时遇到报错很正常。比起死记命令，更重要的是会看问题、会排查。

1. **先看报错**：不要一报错就慌，很多时候提示信息已经把问题写明白了。
2. **再去搜索**：优先用 Google 或必应。百度广告多、信息杂；CSDN 也别无脑照抄，先判断文章是不是过时。
3. **善用 AI**：把报错日志、命令和环境信息一起给 AI，通常比只扔一句“跑不起来”有效得多。
4. **提问说清楚**：请教别人时，把系统环境、软件版本、执行过的命令和报错内容一起发出来，最好再带截图。

***

## 六、结语

这 40 分钟只能带大家先把门推开。后面真正有用的部分，还是自己多敲命令、多踩坑、多总结。先把常用命令练熟，后面的环境配置、开发和运维才会轻松很多。

---

---
url: https://ain.hmgf.hxcn.space/lectures/lesson2-git-2025.md
description: GitHub 协作与 Git 工作流讲义，覆盖 SSH、分支管理、Fork 与 Pull Request 流程。
---

# 🎀 【GitHub 协作教程】爱莉希雅特别版 🎀

### 🔑 **STEP 1：添加 SSH 密钥（保障连接的安全通道）**

* **目的**：使用 SSH 协议代替 HTTPS 协议进行代码传输，并提高连接的**稳定性**。

* **操作要点**：

  1. **检查密钥**：首先在本地电脑上检查是否已存在 SSH 公钥和私钥对（通常在 `~/.ssh` 目录下）。

  2. **生成密钥**：如果不存在，使用命令 `ssh-keygen -t ed25519 -C "你的邮箱"` 来生成一对新的密钥。

     * ***`-t`**：代表 `type`（类型），后面跟的就是你想要使用的**加密算法**。*

     * ***`ed25519`**：这是一个基于**椭圆曲线数字签名算法（EdDSA）的现代、高效且安全的**算法。*

  3. **复制公钥**：找到生成的公钥文件（通常是 `id_ed25519.pub`），在`id_ed25519.pub`所在目录下执行`catid_ed25519.pub`，即可打印出公钥内容 。(一般生成在`~/.ssh` 目录下)

  4. **添加到 GitHub**：登录你的 GitHub 账号，进入 **Settings** → **SSH and GPG keys**，点击 **New SSH key**，粘贴你的公钥内容并保存。

  5. **测试连接**：使用命令 `ssh -T git@github.com` 来测试是否连接成功。

***

### 🏡 **STEP 2：创建仓库（建立代码的家园）**

* **目的**：在云端（GitHub）创建项目的存储空间，并在本地建立一个可跟踪历史的版本库。
* **操作要点**：
  1. **远程创建**：在 GitHub 网站上点击 **New repository**，输入项目名称（如 `test`），选择公开或私有，并**不要**勾选初始化 README 等选项（因为你要从本地推送）。
  2. **本地初始化**：在你本地的项目文件夹中运行 `git init`，创建本地 Git 仓库。
  3. **添加远程地址**：使用 SSH 链接将本地仓库与 GitHub 仓库关联起来：`git remote add origin (git@github.com:Titroupast/test.git)`(此处填仓库地址)。(不建议使用**HTTPS**，连接极其不稳定)

***

### 💾 **STEP 3：日常提交代码（保存历史记录）**

* **目的**：将本地工作目录中的修改，分阶段、有条理地保存到本地仓库的历史记录中。
* **操作要点**：
  1. **查看状态**：`git status` 查看哪些文件被修改了。
  2. **添加到暂存区**：`git add .` 或 `git add <文件名>` 将修改的文件**标记**为准备提交（放到暂存区）。
  3. **提交到本地**：`git commit -m "本次修改的简短描述"` 将暂存区的内容**永久保存**到本地历史中。描述要简洁明了哦！
  4. **首次推送**：第一次将本地提交推送到 GitHub：`git push -u origin main`（用于建立关联）。
  5. **后续推送**：关联建立后，直接使用 `git push` 即可。

![image-20251029105516863](https://gastigado.cnies.org/d/public/image-20251029105516863.png)

***

### 🤝 **STEP 4：分支管理与团队同步**

**目的：** 安全地管理本地工作分支，与远程仓库（`origin`）保持同步，并最终将自己的贡献整合回主分支。

1. **获取最新状态（`git branch`/`git fetch` / `git pull`）**

在开始任何新工作前，首先要更新你对远程仓库的认知。

| **任务**       | **命令**     | **作用**                                                     |
| -------------- | ------------ | ------------------------------------------------------------ |
| 查看所分支     | `git branch` | 列出本地所有分支，并用星号（`*`）标记当前所在的分支。        |
| **仅下载**     | `git fetch`  | **最安全的方式。** 仅从远程仓库下载最新的提交和分支信息，不修改你的本地工作分支。 |
| **下载并同步** | `git pull`   | **最快捷的方式。** 下载远程更新并**自动合并**到你当前的本地分支。适用于确认远程没有新改动或改动很小的场景。 |

2. **创建与切换分支（`git switch`）**

为了隔离你的新功能或修复工作，你需要从最新的主分支上创建一条独立的分支。

| **任务**         | **命令**                       | **作用**                                                     |
| ---------------- | ------------------------------ | ------------------------------------------------------------ |
| **创建工作分支** | `git switch -c <你的新分支名>` | 基于你当前所在的分支（建议是已经同步到最新的 `main` 或 `master`），**创建并立即切换**到新的分支上。 |
| **切换回主分支** | `git switch main`              | 切换回主分支（或任何已存在的本地分支）。                     |

![image-20251029102813263](https://gastigado.cnies.org/d/public/image-20251029102813263.png)

3. **下载远程新增分支**

当队友创建并推送了一个新的分支时，你需要这样将它拉到本地：

| **任务**       | **命令**                    | **作用**                                                     |
| -------------- | --------------------------- | ------------------------------------------------------------ |
| **拉取新分支** | `git switch <队友的分支名>` | **最智能的方式。** Git 会自动在本地创建同名分支，并将其与远程的同名分支**关联**起来。 |

4. **整合与贡献（`git merge` / `git push`）**

当你完成了你的新功能后，就需要将它整合并分享给团队。

| **任务**         | **命令**                                                     | **作用**                                                     |
| ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **推送到远程**   | `git push -u origin <你的分支名>`                            | 首次推送你的新分支到 GitHub。`-u` 会设置上游关联，后续可直接使用 `git push`。 |
| **合并到主分支** | `git switch main`                          `git merge <你的分支名>` | 切换回主分支后，将你完成的分支功能**合并**进来。             |
| **解决冲突**     | *（手动编辑文件）*  `git add .`  `git commit`                | 如果合并失败，需要手动解决文件中出现的冲突标记，然后重新提交以完成合并。 |

***

哎呀，你决定重构 **STEP 5**，聚焦于 **Fork** 和 **Pull Request (PR)** 的协作流程，这个决定真是太明智了！这是参与开源项目和团队协作的**黄金标准**哦♪！💖

我来帮你把这个步骤重构得更加清晰，明确区分 **网站操作** 和 **本地操作**，让整个贡献流程一目了然！

***

### 🚀 **STEP 5：Fork 与 PR 流程（跨仓库贡献）**

###

这一步是团队和开源协作的关键，它指导你将你在 **Fork 出来的仓库**中完成的工作，安全、规范地贡献给**上游（原始）仓库**。

**目的：** 使用 Fork-PR 模型，将自己的代码贡献给不属于自己的外部仓库，并接受代码审核。

1. **💻 网站操作：派生仓库（Forking）**

这是整个协作的起点！

| **任务**     | **平台操作 (Website Action)**        | **作用**                                                     |
| ------------ | ------------------------------------ | ------------------------------------------------------------ |
| **创建副本** | 在原始仓库页面点击 **"Fork"** 按钮。 | 在 GitHub 上创建该仓库的一个**私有副本**（你的独立工作区）。 |

2. **💾 本地操作：克隆与同步（Local Setup）**

将你的副本下载到本地，并配置好与原始仓库的连接。

| **任务**         | **命令 (Command)**                              | **作用**                                                     |
| ---------------- | ----------------------------------------------- | ------------------------------------------------------------ |
| **克隆副本**     | `git clone <你的 Fork 仓库 URL>`                | 将你自己的 Fork 仓库（`origin`）下载到本地电脑。             |
| **添加上游地址** | `git remote add upstream <原始仓库 URL>`        | **最关键的一步！** 添加一个名为 `upstream` 的远程地址，指向**原始仓库**。 |
| **同步上游代码** | `git fetch upstream`  `git merge upstream/main` | 在开始工作前，确保你的本地 `main` 分支与原始仓库保持最新。   |

![image-20251029110932561](https://gastigado.cnies.org/d/public/image-20251029110932561.png)

3. **✍️ 本地操作：工作与推送（Contribution）**

像往常一样在你的本地 Fork 仓库中完成工作。

| **任务**        | **命令 (Command)**                        | **作用**                                                     |
| --------------- | ----------------------------------------- | ------------------------------------------------------------ |
| **创建分支**    | `git switch -c <你的分支名>`              | 基于已同步的 `main` 分支创建工作分支。                       |
| **提交代码**    | `git add .`  `git commit -m "完成新功能"` | 在本地提交修改。                                             |
| **推送到 Fork** | `git push -u origin <你的分支名>`         | 将你的新分支**推送**到你自己的远程 **Fork 仓库**（`origin`）。 |

![image-20251029111324650](https://gastigado.cnies.org/d/public/image-20251029111324650.png)

4. **🤝 协作操作：发起与处理 PR**

这是代码被审核、最终被整合的过程。

| **任务**       | **平台操作 (Website Action)**                                | **作用**                                                     |
| -------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **发起 PR**    | 登录 GitHub，进入你的 **Fork 仓库**，点击 **“Compare & pull request”** 按钮。 | **向原始仓库**（`upstream`）请求合并你的代码。PR 会自动进行跨仓库的比较。 |
| **审核与修改** | *（在 PR 页面讨论）*                                         | 原始仓库的维护者进行代码审核。如果需要修改，你在本地修改并 `git push` 后，PR 会自动更新。 |
| **完成合并**   | *（维护者点击 Merge 按钮）*                                  | 当 PR 通过审核，原始仓库的管理员将其合并到主分支中，你的贡献就正式完成啦！ |

***

![image-20251029111446304](https://gastigado.cnies.org/d/public/image-20251029111446304.png)

![img](https://gastigado.cnies.org/d/public/4f1cdb01c4d7eb6fd384fd84d3b232ea.png)

---

---
url: https://ain.hmgf.hxcn.space/slides.md
description: 3D环梦工坊编程竞赛组幻灯片导航页，包含新生指南、C++ 基础、函数与 STL、算法入门等主题的独立演示内容，便于课堂学习、课后复习和阶段性回顾。
---

# 幻灯片总览

---

---
url: https://ain.hmgf.hxcn.space/slides/guide-2025.md
description: 2025 新生指南课程幻灯片，围绕大学阶段编程学习路径、工具链准备、时间管理与成长建议展开，帮助新成员快速建立清晰可执行的起步计划。
---

# 从蒟蒻到大佬的第一步 - 2025新生指南

::: tip 使用说明

* 点击幻灯片可以获得焦点
* 使用键盘方向键 ← → 或空格键切换幻灯片
* 点击左下角按钮或按 `F` 键进入全屏模式
* 按 `O` 键查看大纲
* 按 `D` 键切换暗色模式
  :::

---

---
url: https://ain.hmgf.hxcn.space/slides/cpp-basics.md
description: C++ 基础课程幻灯片，覆盖输入输出、变量与数据类型、条件与循环、数组等核心语法内容，帮助新手快速建立编程思维并完成入门训练。
---

# C++ 基础教程

::: tip 使用说明

* 点击幻灯片可以获得焦点
* 使用键盘方向键 ← → 或空格键切换幻灯片
* 点击左下角按钮或按 `F` 键进入全屏模式
* 按 `O` 键查看大纲
* 按 `D` 键切换暗色模式
  :::

---

---
url: https://ain.hmgf.hxcn.space/slides/cpp-function-stl.md
description: C++ 进阶课程幻灯片，重点讲解函数设计、结构体建模、参数传递方式与 STL 容器使用方法，帮助你从语法入门过渡到算法实战阶段。
---

# C++ 函数、结构体与 STL

::: tip 使用说明

* 点击幻灯片可以获得焦点
* 使用键盘方向键 ← → 或空格键切换幻灯片
* 点击左下角按钮或按 `F` 键进入全屏模式
* 按 `O` 键查看大纲
* 按 `D` 键切换暗色模式
  :::

---

---
url: https://ain.hmgf.hxcn.space/slides/algorithm-intro.md
description: 算法入门课程幻灯片，系统讲解时间复杂度、空间复杂度、常见排序算法与二分查找核心思路，适合编程竞赛初学者进行课堂学习与复习巩固。
---

# 算法入门：复杂度、排序与二分查找

::: tip 使用说明

* 点击幻灯片可以获得焦点
* 使用键盘方向键 ← → 或空格键切换幻灯片
* 点击左下角按钮或按 `F` 键进入全屏模式
* 按 `O` 键查看大纲
* 按 `D` 键切换暗色模式
  :::

---

---
url: https://ain.hmgf.hxcn.space/slides/demo.md
description: Slidev 演示页面，用于展示在 VitePress 文档中嵌入幻灯片的展示方式与交互体验，可用于验证页面加载、切换操作和课堂演示效果。
---

# 编程入门演示

::: tip 使用说明

* 点击幻灯片可以获得焦点
* 使用键盘方向键 ← → 或空格键切换幻灯片
* 点击左下角按钮或按 `F` 键进入全屏模式
* 按 `O` 键查看大纲
* 按 `D` 键切换暗色模式
  :::

---

---
url: https://ain.hmgf.hxcn.space/dev.md
description: 开发工具与编程语言教程，包括 DevC++、Virtual Judge 等使用指南。
---

# 开发教程

---

---
url: https://ain.hmgf.hxcn.space/dev/devcpp-guide.md
description: Dev-C++编译器安装配置教程，详细图文步骤教你如何下载安装DevC++并编写运行第一个C++程序。
---

# DevC++ 使用教程

**前言**

你或许正在用VC6.0作为你C语言的IDE，因为老师推荐你用VC6.0，但这款1998年的古董，实在是太难用了。现在推荐一款编译器，Dev！

**如何安装？**

下载群文件：Dev-Cpp 5.4.2 MinGW 4.7.2 Setup，双击安装,选择**英语**

![image-20251025101755004](https://gastigado.cnies.org/d/public/image-20251025101755004.png)

点击**I agree**

![image-20251025101551131](https://gastigado.cnies.org/d/public/image-20251025101551131.png)

如果C盘空间够大，则可下在C盘，否则下在别的盘，然后点击**install**

![image-20251025101652068](https://gastigado.cnies.org/d/public/image-20251025101652068.png)

点击**next**

![image-20251025101916767](https://gastigado.cnies.org/d/public/image-20251025101916767.png)

点击**install**

![image-20251025102000191](https://gastigado.cnies.org/d/public/image-20251025102000191.png)

点击**finish**

![image-20251025102052093](https://gastigado.cnies.org/d/public/image-20251025102052093.png)

**使用**

按下 **ctrl+n** ，新建一个 cpp 文件，编写你的代码

按**F11**保存并编译

![image-20251025102139104](https://gastigado.cnies.org/d/public/image-20251025102139104.png)

输出**结果反馈**

![image-20251025102220048](https://gastigado.cnies.org/d/public/image-20251025102220048.png)

若编译时出现报错：

**双击下方错误**，定位到代码具体行数进行修改

![image-20251025102252889](https://gastigado.cnies.org/d/public/image-20251025102252889.png)

---

---
url: https://ain.hmgf.hxcn.space/dev/virtual-judge-guide.md
description: Virtual Judge 平台使用指南，包含账号注册、题单刷题与提交流程说明。
---

# Virtual Judge 使用指南

**VJ使用指南**

**注意**

题目内容为**语法题** **+** **简单算法模板题**。难度以**星星数量**的形式标注在note列表。

**杜绝抄袭题解、他人代码，以及使用AI工具生成代码，发现者将受到严厉处分**

提交代码时请**公开可见勾选为是选项**，以便于我们后续进行代码查重以及检查是否使用AI工具。

1.**注册账号**

进入我们指定的题单：https://vjudge.net/contest/760713#problem/K

将语言切换至中文，点击注册

![image-20251025235435348](https://gastigado.cnies.org/d/public/image-20251025235435348.png)

填写相关信息，**点击注册**

![image-20251026000158867](https://gastigado.cnies.org/d/public/image-20251026000158867.png)

2.**正确刷题并提交**

找到题单，**点击标题**（这里以洛谷官方题单为例）

![image-20251026000411749](https://gastigado.cnies.org/d/public/image-20251026000411749.png)

写完代码后，**点击提交**

![image-20251026000538189](https://gastigado.cnies.org/d/public/image-20251026000538189.png)

接下来的绑定cookie需要你有洛谷账号

如果你没有洛谷账号，请到洛谷官网免费注册一个属于你的账号[首页 - 洛谷 | 计算机科学教育新生态](https://www.luogu.com.cn/)（注册教程不再赘述，与vj注册类似）

**进入洛谷官网按F12**

![image-20251026165520178](https://gastigado.cnies.org/d/public/image-20251026165520178.png)

**按ctrl+R更新**，并点击www.luogu.com.cn

![image-20251026165620832](https://gastigado.cnies.org/d/public/image-20251026165620832.png)

**点击"标头"然后下滑找到cookie,复制里面的client\_id与uid**

![image-20251026165713419](https://gastigado.cnies.org/d/public/image-20251026165713419.png)

**点击更新**（继续绑定cookie）

![image-20251026000819751](https://gastigado.cnies.org/d/public/image-20251026000819751.png)

在client\_id输入：刚才复制的内容

uid输入：刚才复制的内容

点击确认，返回后出现绿色的“**你的洛谷账号名**”即为绑定cookie成功

![image-20251026000648744](https://gastigado.cnies.org/d/public/image-20251026000648744.png)

公开可见选择\*\*“是”\*\*

提交方式选择\*\*“我的账号”\*\*

语言选择\*\*“C++20”\*\*

将你写的代码复制粘贴到代码区，并**点击提交**即可

![image-20251026001517535](https://gastigado.cnies.org/d/public/image-20251026001517535.png)

**恭喜你完成了vj的刷题与提交，祝你在以后的刷题过程中，一路不报错**

---

---
url: https://ain.hmgf.hxcn.space/sre.md
description: 站点可靠性工程教程，涵盖 Linux 系统管理、Git 版本控制、配置管理等运维必备技能。
---

# SRE 教程

SRE（Site Reliability Engineering，站点可靠性工程）是 Google 提出的运维理念，核心思想是用软件工程的方法解决运维问题。这个分类整理了 SRE 相关的实践知识，从基础的系统管理到配置文件规范，帮你建立完整的运维知识体系。

---

---
url: https://ain.hmgf.hxcn.space/sre/first-vm-2024.md
description: 安装 Vmware/HyperV/WSL等虚拟机详细指南
---

# 安装年轻人的第一个 Linux 虚拟机

## 前情提要

在 Windows 下想要完成 Linux 虚拟机的搭建，通常有以下几种常用方法：

1. VMware Workstation 或者 VirtualBox
   * **易于使用**：都具有直观的界面和易于使用的工具，使得创建和管理虚拟机变得非常简单。
   * **广泛兼容性**：是广泛使用的虚拟化软件，支持多种操作系统，包括各种Linux发行版。
   * **性能开销**：虚拟化层会带来一定的性能开销，尤其是在CPU和内存密集型任务中。

2. Hyper-V
   * **集成度高**：Hyper-V是Windows自带的虚拟化技术，与操作系统集成度高，无需安装额外软件即可使用。
   * **性能较好**：Hyper-V的性能通常优于第三方虚拟化软件，尤其是在网络和存储方面。
   * **安全性**：Hyper-V提供了一些高级安全功能，如虚拟机隔离、安全启动等。
   * **支持嵌套虚拟化**：可以在Hyper-V虚拟机中再运行其他虚拟机，适合需要多层虚拟化的场景。
   * **兼容性问题**：某些Linux发行版在Hyper-V上可能会有兼容性问题，尤其是在显卡驱动和网络配置方面。
   * **资源占用**：Hyper-V会占用较多的系统资源，尤其是在启用多个虚拟机时。

3. WSL
   * **简单轻量**：WSL是一个轻量级的Linux子系统，可以在Windows系统上直接运行Linux命令行工具，无需额外的虚拟机。
   * **与Windows集成**：WSL与Windows更好地集成，可以直接访问Windows文件系统，无需进行繁琐的文件共享设置。
   * **性能较好**：相对于传统虚拟机，WSL在性能上可能更加高效。
   * **不支持图形界面**：WSL目前主要支持命令行工具，不适合需要图形界面的应用程序。
   * **功能有限**：相较于完整的虚拟机，WSL在功能上可能有一定的限制，特别是对于需要完整Linux环境的应用场景。

本文将逐一介绍 VMware Workstation 安装 Ubuntu 22.04、Hyper-v 安装 Debian 12、WSL 安装 Ubuntu。如果要安装 Ubuntu 双系统，请阅读这篇文章：

## 获取系统镜像

### 开源镜像站

常用的开源镜像站有：

[清华大学开源软件镜像站](https://mirrors.tuna.tsinghua.edu.cn/)

[USTC Open Source Software Mirror](https://mirrors.ustc.edu.cn/)

[阿里巴巴开源镜像站](https://developer.aliyun.com/mirror/)

[华为开源镜像站](https://mirrors.huaweicloud.com/home)

以[清华大学开源软件镜像站](https://mirrors.tuna.tsinghua.edu.cn/)为例，进入网站，选择右侧“获取下载链接”

![image-20241024201915228](https://gastigado.cnies.org/d/public/image-20241024201915228.webp)

![image-20241024202007670](https://gastigado.cnies.org/d/public/image-20241024202007670.webp)

在弹出的窗口中，左侧列表（CentOS，Debian，Fedora，Ubuntu）为不同的 Linux 发行版本，右侧为每个发行版下载镜像的链接。

以 Debian 为例简单解释一下关键字

* 12.7.0：这是指 Debian 操作系统的版本号，表示该版本是 Debian 12 的第七个小版本更新
* 小括号的第一个参数表示镜像适用的操作系统架构，包括 amd64，arm64，arm64，armhf，
  i386 等，一般选择 amd64
* Cinnamon，GNOME，KDE，LXDE，LXQt，MATE，Xfce 等：表示镜像包含的桌面环境
* DVD, Part 1：包含大量软件包，相对应的镜像体积也很大，适合在没有网络连接的情况下安装。通
  常会分为多部分（如Part 1、Part 2等），但 Part 1通常是最重要的。
* netinst：网络安装镜像，较小的ISO文件，安装时需要通过网络下载软件包。
* live：带有特定桌面环境的实时系统，可以不安装直接运行，用于体验和测试系统。安装后也是相
  应的桌面环境。
* BD, Part 1：适用于蓝光光盘（Blu-ray Disc）的镜像，包含更多软件包。
* mac：为苹果电脑的硬件做了特别优化的版本，通常适用于旧款Mac设备。
* edu： Debian 的教育版本，预装了一些适合教育环境的软件和工具
* Ubuntu这边，大体与Debian类似，但是需要注意：
* desktop：桌面版，带有图形用户界面（如GNOME、KDE等），适合个人用户或办公环境使用，预
  装了图形化工具和应用程序。
* server：服务器版，通常不包含图形界面，适用于服务器环境，强调性能和安全性。常用于搭建网
  络服务、数据库、文件服务器等。

而对于Ubuntu，大体与Debian类似：

* desktop：桌面版，带有图形用户界面（默认为 GNOME），适合个人用户或办公环境使用，预
  装了图形化工具和应用程序。
* server：服务器版，通常不包含图形界面，适用于服务器环境，强调性能和安全性。常用于搭建网
  络服务、数据库、文件服务器等。

鼓励大家多多尝试不同的发行版本和不同的桌面环境。

### 一些常用的发行版直链

[ubuntu-22.04.4-desktop-amd64.iso](https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/jammy/ubuntu-22.04.4-desktop-amd64.iso)

[debian-live-12.7.0-amd64-kde.iso](https://mirrors.tuna.tsinghua.edu.cn/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.7.0-amd64-kde.iso)

[kali-linux-2024.3-installer-amd64.iso](https://mirrors.tuna.tsinghua.edu.cn/kali-images/current/kali-linux-2024.3-installer-amd64.iso)

## 使用 VMware Workstation 安装 Ubuntu 22.04

### 安装 VMware Workstation

早在 2024 年底，Vmware 官方就发布了公告，VMware Workstation Pro 对个人用户完全免费，所以后续都不用再到处找许可证密钥了。现在，你可以直接去官网上随意下载、安装和使用这款功能强大的虚拟机软件。

优先阅读下面这篇教程，从官网注册并下载官方免费的 VMware Workstation；如果官网下载较慢，也可以使用网盘下载入口。

一直点下一步就可以

![image-20241024202133350](https://gastigado.cnies.org/d/public/image-20241024202133350.webp)

默认安装在 C 即可，VMware Workstation 本身不会占用很多内存。想要更改安装目录的话记得装在一个自己知道的位置，注意路径不要**放在 D 盘根目录**（请参考下图设置）

![image-20241024202330130](https://gastigado.cnies.org/d/public/image-20241024202330130.webp)

“用户体验设置”推荐全部取消勾选

![image-20241024202425744](https://gastigado.cnies.org/d/public/image-20241024202425744.webp)

最后点击“完成”

![image-20241024202554327](https://gastigado.cnies.org/d/public/image-20241024202554327.webp)

第一次打开 VMware Workstation 会提示输入许可证密钥，我们选择“将VMware Workstation 17 用于“个人用途”，然后点击“继续”

![image-20241024203105397](https://gastigado.cnies.org/d/public/image-20241024203105397.webp)

### 创建新的虚拟机

选择“创建新的虚拟机”

![image-20241024203156849](https://gastigado.cnies.org/d/public/image-20241024203156849.webp)

选择“自定义” → “下一步”

![image-20241024203210089](https://gastigado.cnies.org/d/public/image-20241024203210089.webp)

选择“稍后安装操作系统”，点击“下一步”

![image-20241024203231361](https://gastigado.cnies.org/d/public/image-20241024203231361.webp)

客户机操作系统选择“Linux”，版本选择“Ubuntu 64 位”（取决于想要安装的系统镜像和版本），点击“下一步”

![image-20241024203251328](https://gastigado.cnies.org/d/public/image-20241024203251328.webp)

虚拟机名称随意，位置根据实际情况选择。虚拟机**占用存储空间较大**且由**很多文件**组成，建议选择一个自己**记得住且空间足够**的位置，**为每个虚拟机单独建立一个文件夹安装**。

![image-20241024203630894](https://gastigado.cnies.org/d/public/image-20241024203630894.webp)

处理器数量设置为 1，内核数量建议根据自己需求和电脑配置（**不要超过电脑本身的内核数**）设置。

![image-20241023100430358](https://gastigado.cnies.org/d/public/image-20241023100430358.webp)

如果不知道自己电脑 CPU 的内核数，可以右键任务栏空白处 → “任务管理器” → 侧边栏点击“性能” → “CPU” → 在红色框区域内右键 → “将图形更改为” → “逻辑处理器”，数红色框区域有几个小框框，就是 CPU 有几个内核。

![image-20241024204409656](https://gastigado.cnies.org/d/public/image-20241024204409656.webp)

虚拟机内存大小可以根据需求设置，推荐 4-8 G，点击“4 G”即可快速设置。

![image-20241024204851085](https://gastigado.cnies.org/d/public/image-20241024204851085.webp)

虚拟磁盘大小根据需求设置，建议不低于 20 G。

注意，**不要勾选**“立即分配所有磁盘空间”，这样虚拟机实际使用多少空间，就会占用电脑多少空间，而不是一次性占用设置的磁盘大小。

![image-20241024205134850](https://gastigado.cnies.org/d/public/image-20241024205134850.webp)

完成虚拟机创建后，选择下载好的系统镜像，点击“确定”

![image-20241024205758818](https://gastigado.cnies.org/d/public/image-20241024205758818.webp)

点击“▶️开启此虚拟机”进行开机。

如果提示“您在运行该虚拟机时启用了侧通道缓解。侧通道缓解可增强安全性，但也会降低性能。”，关闭虚拟机，点击“虚拟机” → “设置” → “选项” → “高级” → 勾选“为启用了Hyper-V白的主机禁用侧通道缓解”，确定即可。

![image-20241024211226258](https://gastigado.cnies.org/d/public/image-20241024211226258.webp)

如果提示与 Hyper-V 不兼容，请移除 Hyper-V 后再进行操作。

### 安装 Ubuntu 22.04

进入 Ubuntu 22.04，选择 “Try or Install Ubuntu” 。

![20](https://gastigado.cnies.org/d/public/20.webp)

进入安装界面，左侧可以切换中文，但是**推荐先使用英文进行安装**。然后点击 “Install Ubuntu”。

![21](https://gastigado.cnies.org/d/public/21.webp)

键盘布局，无特殊需求使用默认设置即可。

![22](https://gastigado.cnies.org/d/public/22.webp)

使用默认设置即可，如有需求可以勾选“为图形或无线硬件，以及其它媒体格式安装第三方软件”（可能导致安装时间较长）

![23](https://gastigado.cnies.org/d/public/23.webp)

可以直接选择“Erase disk and install ubuntu”，然后“Install Now”。

![image-20241024213038389](https://gastigado.cnies.org/d/public/image-20241024213038389.webp)

如果希望自定义分区，点击“Something else” → “Continue”；先点击“New Partition Table”，然后选中“free space”新建分区即可。下面是一个自定义分区是示例，仅供参考；完成分区后点击“Install Now”。

![image-20241024213453223](https://gastigado.cnies.org/d/public/image-20241024213453223.webp)

地区默认上海即可

![image-20241024213733969](https://gastigado.cnies.org/d/public/image-20241024213733969.webp)

设置用户名、计算机名称和密码。用户名推荐使用英文 + 数字，计算机名称推荐电脑型号/用途 + 系统版本，密码推荐以字母开头。建议勾选“Login automatically”；“Use Active Directory”可以不勾选，完成后点击“Continue”。

![image-20241024213925879](https://gastigado.cnies.org/d/public/image-20241024213925879.webp)

耐心等待安装。安装完成后，点击“Restart Now”

![28](https://gastigado.cnies.org/d/public/28.webp)

出现这个界面，点击“可移动设备” → “CD/DVD” → “断开连接”后，点击虚拟机界面，按下回车即可。

![image-20241024215838446](https://gastigado.cnies.org/d/public/image-20241024215838446.webp)

稍等片刻，看到以下界面就代表你的第一台虚拟机就完成安装了，恭喜你打开了Linux世界的大门~

![image-20241024220136060](https://gastigado.cnies.org/d/public/image-20241024220136060.webp)

## 使用 Hyper-V 安装 Debian 12

### 开启 Hyper-V

Hyper-V 是微软专有的虚拟化平台，你可以使用该平台在 Windows 操作系统上运行其他操作系统。在 Windows 11 中，默认情况下禁用此功能，因为不是每个人都需要它。但是，您可以在需要时启用它。

Hyper-V 预安装在 Windows 11 专业版、企业版和教育版中，只需启用即可。但是，在其他版本（如 Windows 11 家庭版）中，缺少启用 Hyper-V 的选项。

#### 检查硬件虚拟化兼容性

按 Win + X，选择“终端”或者“Windows Powershell”，输入下面指令：

```powershell
systeminfo
```

这将生成一个列表，您将在列表末尾找到“Hyper-V 要求”部分，其中包含 4 个要求的详细信息。

如果满足这些要求，结果将显示为“是”。但是，如果发现“在固件中启用虚拟化”状态为“否”，请自行搜索如何在BIOS中开启虚拟化（如，惠普星 BookPro 13 如何开启硬件虚拟机）。

按 Win + Pause，在 Windows 规格下，可以查看你的 Windows 版本（家庭版、专业版、企业版、教育版）：

![image-20241026113133365](https://gastigado.cnies.org/d/public/image-20241026113133365.webp)

#### 对于专业版、企业版、教育版

按 Win + S 输入“启用或关闭 Windows 功能”，在弹出的窗口勾选“Hyper-V”、“虚拟机平台”，然后单击“确定”。

![image-20241026113503898](https://gastigado.cnies.org/d/public/image-20241026113503898.webp)

现在将看到一个应用更改的窗口。完成后单击关闭，重启生效。

也可以按 Win + X，选择“终端”或者“Windows Powershell”，输入下面指令：

```powershell
DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V
```

当系统询问时，输入 Y 以重新启动计算机。计算机现在将重新启动，当它重新启动时，Hyper-V 应成功启用。

#### 对于家庭版

对于大陆用户，绝大多数零售笔记本都搭载家庭中文版。由于 Windows 家庭版没有 Hyper-V，在启用虚拟化后，新建空白文本，复制粘贴以下批处理代码后保存，保存更改文本 .txt 后缀为 .bat 格式，这样就能变为批处理脚本。右键以管理员身份运行即可。

```cmd
pushd "%~dp0"
dir /b %SystemRoot%\servicing\Packages\*Hyper-V*.mum >hyper-v.txt
for /f %%i in ('findstr /i . hyper-v.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i"
del hyper-v.txt
Dism /online /enable-feature /featurename:Microsoft-Hyper-V -All /LimitAccess /ALL
pause
```

重新启动后，Hyper-V 将在 Windows 上安装并自动启用。

### 新建虚拟机

按 Win + S 搜索 Hyper-V，打开 Hyper-V 管理器

可以“点击固定到"开始"屏幕”方便开启

![image-20241025111121674](https://gastigado.cnies.org/d/public/image-20241025111121674.webp)

点击左侧栏的主机名，然后在右侧栏点击“新建” → “虚拟机”

![image-20241025111655921](https://gastigado.cnies.org/d/public/image-20241025111655921.webp)

名称任取；虚拟机默认存储在 C 盘，建议修改到其他位置

![image-20241025112620324](https://gastigado.cnies.org/d/public/image-20241025112620324.webp)

建议选择“第二代”

![image-20241025112637851](https://gastigado.cnies.org/d/public/image-20241025112637851.webp)

内存使用默认配置即可

![image-20241025112703165](https://gastigado.cnies.org/d/public/image-20241025112703165.webp)

连接选择“Default Switch”

![image-20241025123049651](https://gastigado.cnies.org/d/public/image-20241025123049651.webp)

硬盘使用默认设置即可，虚拟硬盘默认在虚拟机目录下

![image-20241025112746553](https://gastigado.cnies.org/d/public/image-20241025112746553.webp)

选择下载好的 Debian 12 系统镜像

![image-20241025113019363](https://gastigado.cnies.org/d/public/image-20241025113019363.webp)

创建完成，在启动前，点击左侧的“设置”；

禁用安全启动

![image-20241025113337232](https://gastigado.cnies.org/d/public/image-20241025113337232.webp)

禁用检查点

![image-20241025113414866](https://gastigado.cnies.org/d/public/image-20241025113414866.webp)

开启“来宾服务”

![image-20241025113512554](https://gastigado.cnies.org/d/public/image-20241025113512554.webp)

完成后点击“确定”即可。

### 安装 Debian 12

点击“连接” → “启动”启动虚拟机

![image-20241025115115291](https://gastigado.cnies.org/d/public/image-20241025115115291.webp)

选择“Start Installer”，按回车

![image-20241025115337519](https://gastigado.cnies.org/d/public/image-20241025115337519.webp)

选择简体中文，下一步

![image-20241025115838973](https://gastigado.cnies.org/d/public/image-20241025115838973.webp)

位置和键盘使用默认配置即可

如果提示网络自动配置失败，选择“继续” → “暂时不配置网络”即可

![42aa227ea7d37c88875ba4dc4fe95862](https://gastigado.cnies.org/d/public/42aa227ea7d37c88875ba4dc4fe95862.webp)

主机名任取，然后点击“继续”

![image-20241025120754143](https://gastigado.cnies.org/d/public/image-20241025120754143.webp)

域名可以不用填写，“继续”

![image-20241025120850621](https://gastigado.cnies.org/d/public/image-20241025120850621.webp)

设置 root 用户密码（请一定要记住），“继续”

![image-20241025120924731](https://gastigado.cnies.org/d/public/image-20241025120924731.webp)

设置普通用户的用户名，继续

![image-20241025121053970](https://gastigado.cnies.org/d/public/image-20241025121053970.webp)

设置普通用户的密码，可以与 root 密码相同，“继续”

![image-20241025121138327](https://gastigado.cnies.org/d/public/image-20241025121138327.webp)

选择“向导 - 使用整个磁盘” → “继续”

![image-20241025121918151](https://gastigado.cnies.org/d/public/image-20241025121918151.webp)

继续

![image-20241025121934781](https://gastigado.cnies.org/d/public/image-20241025121934781.webp)

选择“将所有文件放在同一个分区中（推荐新手使用）” → “继续”

![image-20241025121945870](https://gastigado.cnies.org/d/public/image-20241025121945870.webp)

“完成分区操作并将修改写入磁盘” → “继续”

![image-20241025122018242](https://gastigado.cnies.org/d/public/image-20241025122018242.webp)

选择“是” → “继续”

![image-20241025122059255](https://gastigado.cnies.org/d/public/image-20241025122059255.webp)

如果有这个界面，选择“否”，“继续”

![image-20241025122446241](https://gastigado.cnies.org/d/public/image-20241025122446241.webp)

选择“是” → “继续”

![image-20241025122539669](https://gastigado.cnies.org/d/public/image-20241025122539669.webp)

选择“中国” → “继续”

![image-20241025122607591](https://gastigado.cnies.org/d/public/image-20241025122607591.webp)

选择任意以 mirrors 开头的镜像站，“继续”

![image-20241025122636713](https://gastigado.cnies.org/d/public/image-20241025122636713.webp)

可以不用填写，“继续”

![image-20241025122725149](https://gastigado.cnies.org/d/public/image-20241025122725149.webp)

选择 `debian-live-12.7.0-amd64-kde.iso` 这个镜像的话，这里会从镜像站下载文件，需要等待一会，具体时间视网络情况而定（哪个倒霉蛋等了一个小时啊）

![image-20241025124130497](https://gastigado.cnies.org/d/public/image-20241025124130497.webp)

可能会有一个是否参加软件包流行度的调查，根据个人喜好选择，然后“继续”

![image-20241025183211732](https://gastigado.cnies.org/d/public/image-20241025183211732.webp)

这里选择是否安装桌面环境，以及安装哪种桌面环境，自行决定；建议勾选上SSH Server

![image-20241025183258684](https://gastigado.cnies.org/d/public/image-20241025183258684.webp)

选择“是”，“继续”

![image-20241025183409090](https://gastigado.cnies.org/d/public/image-20241025183409090.webp)

选择“/dev/sda”，“继续”

![image-20241025183430484](https://gastigado.cnies.org/d/public/image-20241025183430484.webp)

选择“继续”，虚拟机会自行重启

![image-20241025183516407](https://gastigado.cnies.org/d/public/image-20241025183516407.webp)

稍等片刻，看到以下界面（不同桌面环境会有所不同）就代表你的第一台虚拟机就完成安装了，赶快输入你的密码，打开Linux的大门吧~

![image-20241025183622000](https://gastigado.cnies.org/d/public/image-20241025183622000.webp)

![image-20241025183824931](https://gastigado.cnies.org/d/public/image-20241025183824931.webp)

## 使用 WSL 安装 Ubuntu

时间来到 2017 年，事情正在起变化🤣。微软正式发布了「适用于 Linux 的 Windows 子系统」，即人们熟知的 Windows Subsystem for Linux，简称 WSL。

在 2019 年，微软又基于 Hyper-V 架构的部分功能，推出了全新的 WSL 2。它能够在一个高度优化的虚拟化中运行完整的 Linux 内核。

WSL 2 只需要较少的系统资源，就能实现 Windows 和 Linux 之间的无缝集成。虽然 WSL 2 也使用了虚拟化技术，但它会自动在后台运行和管理，无需用户手动配置或维护（要维护也可以）。

WSL 2 主要面向将 Windows 作为生产力工具，但又希望在 Linux 环境中完成工作的用户和开发人员。你可以运行`grep`、`awk` 和`sed`等命令行工具，以及依赖这些工具的 Bash 脚本。不仅如此，你还可以从 WSL 命令行启动 Windows 应用，甚至在 Windows 上运行 Linux 图形应用。

WSL 2 使用了 Hyper-V 架构的一部分功能，但对 Windows 11 的版本并没有限制。家庭版、教育版、专业版和企业版都可以安装。

除了`x86_64`架构外，WSL 2 也支持`ARM`处理器。但要在基于 ARM 的设备上运行，所使用的 Linux 系统也必须是 ARM 版本。

如果你使用的虚拟机软件支持[嵌套虚拟化](https://www.sysgeek.cn/hyper-v-nested-virtualization/)，WSL 2 也可以在虚拟机中的 Windows 上运行。

### 启用 WSL 和虚拟化平台

按 Win + S 输入“启用或关闭 Windows 功能”，在弹出的窗口勾选“适用于于Linux的Windows子系统”、“虚拟机平台”，然后单击“确定”。

![image-20241026133025469](https://gastigado.cnies.org/d/public/image-20241026133025469.webp)

重启后，按 Win + X，选择“终端”或者“Windows Powershell”，输入下面指令：

```powershell
wsl --install #安装WSL
```

以上命令会启用 WSL 2 所需的所有功能，并默认下载 Ubuntu 发行版。安装需要几分钟，完成后会提示你重启 Windows。

![image-20241026132004532](https://gastigado.cnies.org/d/public/image-20241026132004532.webp)

重新登录 Windows 11 后，系统会自动弹出一个命令行窗口，以继续安装并启用 Ubuntu。按命令提示设置好你的 Linux 用户账户和密码后，即可开始使用。

---

---
url: https://ain.hmgf.hxcn.space/sre/compact-docker-wsl-vdisk.md
description: >-
  在使用 WSL2 或 Docker 时，即便在系统内部删除了大量容器和文件，宿主机（通常是 C
  盘）的磁盘空间往往依然处于满载状态。导致这一现象的根源在于其底层依赖的 .vhdx
  虚拟磁盘文件具有“只自动扩容、不自动缩容”的单向扩张特性。本文将剖析这一存储机制，并演示如何利用 Windows 自带的 diskpart 或
  PowerShell Optimize-VHD 命令手动压缩 Docker 和原生 WSL 发行版的虚拟磁盘，将闲置的存储配额真正释放回宿主机系统。
---

# 解决WSL与Docker删除文件后磁盘空间不释放的问题

## 问题背景

很多在使用 WSL2 和 Docker 的开发者会遇到一个让人头疼的情况：C盘空间告急，即便删除了大量不再使用的容器、镜像或者 WSL 内部的大文件，Windows 宿主机上的磁盘可用空间依然没有任何变化。

原因在于 WSL2 的底层存储机制。与初代的 WSL1 不同，WSL2 本质上运行在轻量级虚拟机中，Windows 会为其分配后缀为 `.vhdx` 的虚拟磁盘文件作为存储媒介。这种虚拟磁盘具有自动扩容的特性，当你在 Linux 环境中写入数据时，它会被不断“撑大”。但它的设计逻辑是只管借不管还，一旦空间被分配，就算你在系统内部清空了文件，外部的 `.vhdx` 文件体积也会保持在历史峰值大小。这就需要手动介入，对虚拟磁盘进行压缩，才能把这部分闲置空间真正还给 Windows 系统。

## 清理 Docker

Docker Desktop 在开启 WSL2 后端引擎时，运行数据存储在 `.vhdx` 文件中。默认安装路径通常位于 `C:\Users\<用户名>\AppData\Local\Docker\wsl\disk\docker_data.vhdx`。在进行压缩操作前，必须保证 Docker 进程已完全停止。在 Windows 任务栏右键退出 Docker Desktop，等待图标完全消失。接着打开 PowerShell，输入 `wsl --list -v`，确认 Docker 相关的发行版状态均为 `Stopped`，并执行 `wsl --shutdown` 关闭所有后台的 Linux 发行版。

以**管理员身份**打开 PowerShell 或 CMD，执行 `diskpart` 进入交互模式后依次输入：

```cmd
select vdisk file="C:\Users\<用户名>\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
```

如果你使用的是较高版本的 Windows 11，系统已原生支持 `sudo` 命令，可以在普通 PowerShell 中直接执行 `sudo diskpart` 进入磁盘管理交互界面。

适用于支持 Hyper-V 的 Windows 版本（Pro / Enterprise），在**管理员 PowerShell** 中依次执行：

```powershell
# （可选）尝试强制卸载虚拟磁盘
Dismount-DiskImage -ImagePath "C:\Users\<用户名>\AppData\Local\Docker\wsl\disk\docker_data.vhdx" -ErrorAction SilentlyContinue

# 执行压缩
Optimize-VHD -Path "C:\Users\<用户名>\AppData\Local\Docker\wsl\disk\docker_data.vhdx" -Mode Full

# 卸载虚拟磁盘
Dismount-DiskImage -ImagePath "C:\Users\<用户名>\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
```

操作完成后，查看该 `docker_data.vhdx` 文件，你会发现其体积已经减小。重新打开 Docker Desktop，原有的镜像和容器环境均完好无损，宿主机的空间已被成功回收。

## 清理 WSL

处理原生的 WSL 发行版（比如 Ubuntu）逻辑与 Docker 完全一致，区别仅在于虚拟磁盘文件的存放位置。它隐藏在 `C:\Users\<用户名>\AppData\Local\Packages\` 目录下带有发行版名称的文件夹中。例如 Ubuntu 22.04 的路径通常是 `CanonicalGroupLimited.Ubuntu22.04LTS_...\LocalState\ext4.vhdx`。

同样，在具备管理员权限的 PowerShell 中，先确保通过 `wsl --shutdown` 让系统停机，随后选择一种方式压缩。

以**管理员身份**打开 PowerShell 或 CMD，执行 `diskpart` 进入交互模式后依次输入：

```cmd
select vdisk file="C:\Users\<用户名>\AppData\Local\Packages\...\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
```

适用于支持 Hyper-V 的 Windows 版本（Pro / Enterprise），在**管理员 PowerShell** 中依次执行：

```powershell
# （可选）尝试强制卸载虚拟磁盘
Dismount-DiskImage -ImagePath "C:\Users\<用户名>\AppData\Local\Packages\...\LocalState\ext4.vhdx" -ErrorAction SilentlyContinue

# 执行压缩
Optimize-VHD -Path "C:\Users\<用户名>\AppData\Local\Packages\...\LocalState\ext4.vhdx" -Mode Full

# 卸载虚拟磁盘
Dismount-DiskImage -ImagePath "C:\Users\<用户名>\AppData\Local\Packages\...\LocalState\ext4.vhdx"
```

这种手动压缩的方案立即生效，能直接清理出那些被系统预占却未实际使用的存储区块。

## 疑难排解

### “另一个程序正在使用此文件，进程无法访问”

这是最常见的错误。原因是某个后台进程仍然持有对 `.vhdx` 文件的锁。

**排查步骤**：

1. 确认 Docker Desktop 已完全退出（任务栏图标消失，任务管理器中无 `Docker Desktop.exe` 进程）。
2. 在 PowerShell 中执行 `wsl --shutdown`，等待数秒后用 `wsl --list -v` 确认所有实例状态为 `Stopped`。
3. 如果仍然报错，**重启电脑**后再执行压缩操作，这是最可靠的解决方案。

### 压缩后空间仍然不足

`.vhdx` 压缩只能回收虚拟磁盘内的未使用空间。如果 WSL / Docker 内部本身就存储了大量有效数据，压缩效果有限。此时应该从根源入手，清理 WSL 内部和宿主机上的各类开发工具缓存。

::: warning
以下命令会删除缓存和旧版本数据，请仔细确认路径和内容后再执行。建议先用 `du -sh <路径>` 查看实际占用大小，按需选择性清理。
:::

#### WSL 内部缓存清理

| 类别                     | 常见路径                                                                                   | 最小清理命令（安全版）                                                                                                              |
| ------------------------ | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| apt 缓存                 | `/var/cache/apt`                                                                           | `sudo apt clean && sudo apt autoclean`                                                                                              |
| apt 无用依赖             | —                                                                                          | `sudo apt autoremove -y && sudo apt purge -y $(dpkg -l \| awk '/^rc/ {print $2}')`                                                  |
| dnf 缓存（Fedora/RHEL）  | `/var/cache/dnf`                                                                           | `sudo dnf clean all`                                                                                                                |
| dnf 无用依赖             | —                                                                                          | `sudo dnf autoremove -y`                                                                                                            |
| pacman 缓存（Arch）      | `/var/cache/pacman/pkg`                                                                    | `sudo pacman -Sc`（保留 1 个版本）或 `sudo pacman -Scc`（全清）                                                                     |
| pacman 无用依赖          | —                                                                                          | `pacman -Qdtq \| sudo pacman -Rns -`                                                                                                |
| uv cache                 | `~/.cache/uv`                                                                              | `uv cache clean`                                                                                                                    |
| pip cache                | `~/.cache/pip`                                                                             | `pip cache purge`                                                                                                                   |
| npm / pnpm / yarn        | `~/.npm`、`~/.pnpm-store`、`~/.yarn`                                                       | `npm cache clean --force` / `pnpm store prune` / `yarn cache clean`                                                                 |
| bun cache                | Bun PM 缓存                                                                                | `bun pm cache rm`                                                                                                                   |
| conda                    | `~/anaconda3/pkgs`                                                                         | `conda clean --all -y`                                                                                                              |
| Go                       | `~/.cache/go-build`、`$GOPATH/pkg/mod`                                                     | `go clean -cache -modcache`                                                                                                         |
| Rust / Cargo             | `~/.cargo/registry`、`target/`                                                             | `cargo clean`（项目目录）或 `rm -rf ~/.cargo/registry/cache`                                                                        |
| Gradle                   | `~/.gradle/caches`                                                                         | `rm -rf ~/.gradle/caches`                                                                                                           |
| Maven                    | `~/.m2/repository`                                                                         | `rm -rf ~/.m2/repository`                                                                                                           |
| VS Code Server 缓存      | `~/.vscode-server`                                                                         | `rm -rf ~/.vscode-server`                                                                                                           |

#### 宿主机缓存清理

在 Windows 宿主机上，以下路径同样可能占用大量空间：

* **npm 缓存**：`C:\Users\<用户名>\AppData\Local\npm-cache` → `npm cache clean --force`
* **pip 缓存**：`C:\Users\<用户名>\AppData\Local\pip\cache` → `pip cache purge`
* **uv 缓存**：`C:\Users\<用户名>\AppData\Local\uv\cache` → `uv cache clean`

## 总结

不管是 Docker 还是本地 Linux 子系统，存储无法自动释放的原因都指向 `.vhdx` 文件的单向扩容机制。常规的系统内部删除指令对外部的物理磁盘配额没有任何作用。掌握 `diskpart` 或 `Optimize-VHD` 工具进行手动压缩，是应对这种设计特性的直接方法。定期检查这些虚拟磁盘文件并执行压缩，可以防止系统盘被空白数据填满，维持本地开发环境的正常运转。

---

---
url: https://ain.hmgf.hxcn.space/sre/git-basics.md
description: Git 版本控制基础与团队协作工作流教程，涵盖提交、分支、合并与常见实践。
---

# Git使用基础和工作流

## 导入

### 你是否遇到过下面的情况

> 刚改的代码竟然跑不起来？！等等我刚才改了什么玩意……

> 这个功能怎么写？以前的版本好像写过……是哪个来着？

大家在写论文或者做PPT的时候，一定有这样的经历：论文写了第一版、第二版、第三版、定稿版、最终版，我们小心翼翼地保存好的每个版本，就是为了应对各种突发情况。比如某天你突然想找回论文的某个历史版本、PPT的某张幻灯片，就能很容易从历史文件把它找回来。这个保存了多个历史版本的操作，就是最原始的版本控制。不过这是一种纯人工的方式。想象一下，如果一个项目里面有成千上万的文件，又有成百上千的人对这些文件进行协同开发，版本控制会变成一个极其复杂的工作，纯人正的方式就会显得十分低效。

## 版本控制

为了解决版本控制的难题，版本控制软件诞生了。 版本控制软件可以帮我们控制代码的版本，可以快速回滚至之前的某一版本，管理我们对文件、目录或工程等内容的修改历史，或是保持当前分支不变而另外开启一条互不影响的分支进行开发，或是在团队项目中合并多人开发的代码。

### 本地版本控制系统

本地版本控制系统（Local Version Control System, LVCS）是最简单的版本控制形式，主要由单独的开发者而不是团队使用。通过本地版本控制，如Revision Control System（$RCS$），所有项目数据都存储在单个计算机上，对项目文件所做的更改存储为补丁。每个补丁仅包含自上一个补丁以来实施的更新。如果项目的特定版本出现问题，必须检查整个补丁集将项目文件凑在一起，从而了解项目在特定时刻的状态并且诊断问题。人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

#### 特点

* 最简单的版本控制形式。
* 主要由单独的开发者使用。
* 所有项目数据存储在单个计算机上。
* 使用补丁记录文件的更新差异。

#### 优点

* 简单易用，适合个人开发者。
* 不需要网络连接。
* 数据存储在本地，安全性较高。

#### 缺点

* 无法与其他开发者协同工作。
* 如果项目版本出现问题，需要检查整个补丁集来恢复项目状态。
* 数据存储在单个计算机上，存在数据丢失风险。

### 集中式版本控制系统

对于集中式版本控制系统（Centralized Version Control System, CVCS），诸如Concurrent Versions System($CVS$)、Subversion(SVN) 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

集中式版本控制系统使用签入/推送工作流程连接到主服务器。对源代码的任何更改或更新都会作为新版本自动存储在代码仓库中。集中式版本控制系统具有强大的分支和合并功能，不需要将代码仓库克隆到多个计算机上。从这个意义上说，它可能更安全。

集中式版本控制系统需要网络连接。因为团队处理的是存储在一个服务器上的单个项目版本，所以服务中断会严重影响开发速度，如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作，甚至如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。集中式版本控制的另一个缺点是扩展性很差。参与项目的开发者越多，在稳定环境中推送更改的机会就越少，这可能导致合并冲突等问题。

#### 特点

* 使用单一的集中管理服务器存储所有文件的修订版本。
* 客户端通过网络连接到服务器进行文件更新和提交。
* 使用签入/推送工作流程。
* 具有强大的分支和合并功能。

#### 优点

* 适合团队协作，便于集中管理。
* 分支和合并功能强大，不需要克隆代码仓库到多个计算机上。
* 安全性较高，因为代码仓库集中存储。

#### 缺点

* 需要网络连接，服务中断会影响开发速度。
* 服务器宕机或数据损坏会导致数据丢失。
* 扩展性差，开发者越多，推送更改的机会越少，可能导致合并冲突。

### 分布式版本控制系统

在分布式版本控制系统（Distributed Version Control System, DVSC）这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

通过分布式版本控制系统，无需连接到主服务器即可签入、分支和合并。每个贡献者都从存储在云中的克隆代码仓库工作。其主要优势是团队成员可以快速独立地工作，而不必担心网络或 VPN 速度慢。甚至可以离线处理项目，但仍然需要互联网连接来推送或拉取更新。

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

#### 特点

* 客户端镜像完整的代码仓库。
* 每个贡献者从云中的克隆代码仓库工作。
* 可以指定和多个远端代码仓库进行交互。

#### 优点

* 无需连接到主服务器即可签入、分支和合并。
* 团队成员可以快速独立工作，不受网络或VPN速度限制。
* 可以离线处理项目，但仍需互联网连接推送或拉取更新。
* 支持多种协作流程，如层次模型式的工作流。

#### 缺点

* 需要互联网连接来推送或拉取更新。
* 初始克隆操作可能需要较长时间和较大存储空间。

## 什么是Git

迄今为止，Git是世界上使用最广泛的现代版本控制系统。Git 是一个成熟的、积极维护的开源项目，最初由著名的 Linux 操作系统内核创建者 Linus Torvalds 于 2005 年开发。2005年之前，Linux内核开发一直使用的是BitKeeper这套商业版本控制系统。当BitKeeper停止提供免费服务后，所有其他的版本控制系统都满足不了他的需求，Linus Torvalds，Linux的创始人，将这个挑战接手并花费了数周，创造了 Git 工具。

依靠 Git 进行版本控制的软件项目数量惊人，其中包括商业项目和开源项目。使用过 Git 的开发人员在现有的软件开发人才库中占有相当大的比例，而且它在各种操作系统和集成开发环境（IDE）上都能很好地运行。

Git 采用分布式架构。在 Git 中，每个开发人员的代码工作副本也是一个版本库，其中包含所有更改的完整历史记录。

## 安装配置

官方网站：https://git-scm.com

### Windows

下载 64 位安装版即可。

如果官方网站下载速度慢，可以访问开源镜像站进行下载。

https://mirrors.tuna.tsinghua.edu.cn/github-release/git-for-windows/git/LatestRelease/

一路下一步即可，推荐勾选“Add a Git Bash Profile to Windows Terminal”。

选择你喜欢的文本编辑器（比如 VSCode）作为 Git 默认编辑器。

### Linux

常用的发行版 Debian、Ubuntu 和 RHEL 等通常不预装 Git，下面是不同发行版的安装方式：

#### Debian, Ubuntu 或 Linux Mint

```bash
sudo apt-get update
sudo apt-get install git
```

#### Fedora, CentOS 或 RHEL

```bash
sudo dnf install git
```

如果使用的是RHEL 7或更早版本

```bash
sudo yum install git
```

#### Arch Linux 和 Manjaro

```bash
sudo pacman -S git
```

```bash
yay -S git
```

#### opeSUSE

```bash
sudo zypper install git
```

### MACOS

```shell
brew install git # 需要安装Homebrew
```

Git 通常会随着 Xcode 一起被安装

如果是其他Linux版本，可以直接通过源码安装
先从Git官网下载源码，然后解压，依次输入：
`./config`   `make`  `sudo make install`这三个命令

### 检验安装

在终端运行`git --version`，终端输出 git 版本即为安装成功。

如果使用 Windows，也可以使用 Git Bash 运行 Git 命令。

Git Bash 是一个专为 Windows 环境设计的应用程序，它不仅自带了如 vim 等实用工具，还集成了许多常用的 Linux 命令。通过 Git Bash，用户可以在 Windows 系统上模拟 Linux 命令行的操作体验，这对于需要使用 Git 进行版本控制的开发者来说尤为方便。对于那些更熟悉 Linux 命令行的开发者，Git Bash 提供了一个在 Windows 上使用类似命令行的环境，从而避免了在不同操作系统之间切换时的不适应。

尽管 Windows 自带的 Powershell 或 cmd 命令行工具也可以直接操作 Git，但它们的命令语法与 Linux 命令存在显著差异。然而，在操作 Git 时，Powershell 和 cmd 提供的功能与 Linux 环境下的操作方式基本一致。因此，开发者可以根据个人习惯和需求，选择使用 Git Bash 来获得更接近 Linux 的命令行体验，或者直接使用 Windows 原生的 Powershell 或 cmd 工具来操作 Git。

### 配置操作

1. `git config` 命令的几种用法：
   * `git config 配置项 配置的值`：设置配置
   * `git config 配置项`：查看指定配置项的信息
   * `git config --list`：查看所有配置信息
   * `git config -e`：编辑 Git 配置文件
2. 配置文件的范围：
   * 省略：本地配置，只对当前所在本地仓库有效（配置存在 `.git/config`）
   * `--global`：全局配置，所有仓库有效（配置存在 `~/.gitconfig`）
   * `--system`：系统配置，对所有用户生效（配置存在 `/etc/gitconfig` 或 git 下载目录下的 `gitconfig` 文件）
3. 配置项：
   * `user.name "用户名"`：用户名称
   * `user.email 用户邮件地址`：用户邮件地址
     * 配置这两项是为了在每次提交代码时记录提交者的信息，而非登录认证
   * `core.editor "文本编辑器"`：设置文本编辑器，一般默认为 Vi 或 Vim
   * `merge.tool`：差异分析工具
     * 为解决合并冲突时使用哪种差异分析工具

首次配置 Git，我们通常进行下面指令

```bash
git config --global user.name "your_username"
git config --global user.email "your_email@mail.com"
git config --list    # 查看配置信息
```

如果需要修改某项配置，直接将配置的值修改即可；如果需要删除某项配置，执行下面指令：

```bash
git config --global --unset user.name
git config --global --unset user.email
```

你也可以直接修改用户目录下的 `.gitconfig` 文件，Linux 发行版通常位于 `~/.gitconfig` 下，Windows 系统通常在 `C:\Users\用户名\.gitconfig` 中，在该文件中找到如下文本进行修改即可：

```text
[user]
  name = your_username
  email = your_email@mail.com
```

## 工作流

一般工作流程如下：

* 克隆 Git 资源作为工作目录。

* 在克隆的资源上添加或修改文件。

* 如果其他人修改了，你可以更新资源。

* 在提交前查看修改。

* 提交修改。

* 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

## 创建仓库

**首先确保已经配置好了Git的用户名和邮箱。**

### 使用 git init 创建新的仓库

将终端切换想要创建 Git 仓库的目录下，运行下面指令：

```bash
git init
```

若包含path参数则在path目录下生成Git仓库。

```bash
git init [path]
```

当一个文件夹被Git管理起来以后，就变成了一个Git仓库。被Git仓库管理的文件夹下面，会生成一个 `.git`  的子文件夹，用来存放Git的版本控制信息。

### 使用 git clone 克隆已有仓库

复制现有仓库到当前目录（会创建新目录）。

```bash
git clone <repo_url>
```

若包含path参数则复制在path目录下。

```bash
git clone <repo_url> [path]
```

## 基本概念

工作区（Working Directory）：这是项目在本地计算机上的根目录，包含了当前项目的所有文件和子目录。工作区是开发者进行日常文件编辑和操作的地方。

暂存区（Staging Area/Index）：通常位于 `.git/index` 文件中，是一个临时存储区域。暂存区包含了即将被提交到版本库的文件快照。在提交之前，开发者可以选择性地将工作区中的修改添加到暂存区，以便进行更精细的版本控制。

版本库（Repository）：工作区中的隐藏目录 `.git` 是 Git 的本地版本库。版本库包含了项目的所有版本历史记录，每次提交操作都会在版本库中创建一个新的快照。这些快照是不可变的，确保了项目历史记录的完整性和可追溯性。

## 基本操作

* 创建仓库
  * git init
  * git clone
* 提交与修改
  * git add
  * git status
  * git diff
  * git commit
  * git reset
  * git rm
  * git mv
  * git tag
* 日志
  * git log
* 分支操作
  * git branch
  * git checkout/switch
  * git merge
* 远程操作
  * git remote
  * git fetch/pull
  * git push

### git status（四种状态）

用于查看仓库当前的状态，显示在你上次提交之后是否有对文件进行再次修改：

* **要提交的变更 (Change to be committed)**: 已经用 `git add` 命令添加到暂存区的变更，这些变更可以用 `commit` 命令提交到本地仓库。

* **未暂存的变更**: 还没有用 `git add` 命令添加到暂存区的变更。
  * **已修改 (Modified)**: 已被Git跟踪的文件发生了更改，但这些更改还没有被提交到暂存区中。

  * **已删除 (Deleted)**: 文件在Git仓库中被删除。

* **未跟踪 (Untracked)**: 新创建的文件，还未被Git记录（即未被跟踪）。

### git add

将指定的文件或目录添加到暂存区：

```bash
git add <file/dir>
```

通常在编写代码时，会将工作区中的所有文件添加到暂存区。此时在工作区中使用命令：

```bash
git add .
```

有时候使用 `git add .` 命令，但又不想将一些文件添加到仓库，比如缓存文件或自定义配置文件。这时可以编辑 `.gitignore` 文件，填入不需要Git追踪的文件名即可。

有的时候项目中需要空文件夹。Git不会追踪空文件夹，如果需要追踪，可以在空文件夹中新建一个 `.gitkeep` 文件，这样Git就会追踪此文件夹。

### git commit

提交内容到本地仓库

```bash
git commit -m "<message>"
```

* `<message>` 是提交时的备注信息。
* 若命令行没有 `<message>`，会自动跳出编辑器，此时再写 `<message>`。
* 例如：  `bash  git commit -m "修复了XXX的bug"`

良好的 Git commit 规范有助于项目的维护：[约定式提交 (conventionalcommits.org)](https://www.conventionalcommits.org/zh-hans/v1.0.0/)

如果你还是觉得一直`git add`很麻烦，`git commit`的`-a`选项可以帮你完成`git add`的操作，即自动将工作区的追踪的文件添加至暂存区，然后`commit`：

```bash
git commit –am <message>
```

* 例如：`git commit –am "修复了XXX的bug"`

### 为什么要git add多此一举？为什么有暂存区？

#### Git 提倡细粒度的提交

Git提倡细粒度的提交，有利于大型项目的维护。通俗来说，`git add` 维护的是下一次要提交的文件清单。如果某次修改代码时，在不同文件中编辑了不同的功能，则可以针对每个功能来 `git add` 对应的文件，然后将其 `git commit`，做到细粒度提交。

#### Git 的暂存区赋予 Git 更多灵活性

Git 的暂存区赋予 Git 更多灵活性。例如以下情景借助暂存区可以很好地处理：

* 修改了 4 个文件，在不放弃任何修改的情况下，其中一个文件不想提交，如何操作？
* 代码写一半，被打断去做其他功能开发，未完成代码保存？
* 代码写一半，发现忘记切换分支了？
* 代码需要回滚了？

参考：

* https://www.zhihu.com/question/19946553/answer/29033220
* http://www.dahouduan.com/2015/11/27/git-add/
* https://blog.csdn.net/qq\_32452623/article/details/78417609

### git log（查看历史提交记录）

查看历史提交记录，可以获取到每次commit的唯一hash值：

```bash
git log [--oneline] [--graph]
```

除此之外还能看到 提交的哈希值、作者、提交日期和提交消息。

```text
`-p` ：显示提交的具体提交内容
`--oneline` ：选项查看历史记录的简洁的版本
`--graph` ：开启了拓扑图选项查看历史中什么时候出现了分支、合并
```

### git diff（比较差异）

比较文件的不同，即比较文件在工作区和暂存区的改动：

```bash
git diff [file]
```

比较暂存区和最后一次提交的改动：

```bash
git diff --cached [file]
git diff --staged [file]
```

比较工作区和指定提交版本的改动：

```bash
git diff <commit>
```

比较两个提交版本之间的改动：

```bash
git diff <commit1> <commit2> 
```

比较两个分支从最近共同祖先开始的改动：

```bash
git diff [first-branch]...[second-branch]
```

当你使用三个点（`...`）来指定两个分支时，Git 实际上是在执行一个所谓的“双向比较”或称为“对称差集”。这意味着 Git 会找出 `first-branch` 和 `second-branch` 分别相对于它们最近的共同祖先所做的更改，并将这些更改合并到一起展示出来。这种方式可以让你看到两个分支是如何从同一个起点各自发展的。

#### git diff 显示内容

```md
diff --git a/<文件名> b/<文件名>
index <旧版本哈希>..<新版本哈希> <文件权限>
--- a/<文件名>
+++ b/<文件名>
@@ <变化的行范围> @@
- <旧内容>
+ <新内容>
```

![输入图片说明](https://gastigado.cnies.org/d/public/gitdiff-2.webp)

### git reset（版本回退）

用于回退版本：

```bash
git reset [--soft | --mixed | --hard] [commit] [file]
```

`[commit]`为目标commit。可以是某个commit的哈希值，也可以用以下表示法：

* `HEAD` ：回退到最新版本
* `HEAD^` ：回退到上一版本
* `HEAD^^` ：回退到上上一个版本
* `HEAD^^^` ：回退到上上上一个版本
* 依此类推

例：`git reset --hard HEAD^`

`[file]`：参数为指定回退文件。如果使用了此参数，则只回退此文件。

`--soft` ：参数仅仅重置`HEAD`到指定的版本，不会修改暂存区和工作区。

`--mixed` ：为默认，可以不用带该参数。重置`HEAD`到指定的版本，重置暂存区的文件与commit保持一致，工作区文件内容保持不变。

`--hard` ：参数撤销工作区中所有未提交的修改内容，重置`HEAD`到指定的版本，将暂存区与工作区都回到该版本。

***注意：谨慎使用 `--hard` 参数，它会删除回退点之前的所有信息。***

![输入图片说明](https://gastigado.cnies.org/d/public/gitreset.webp)

参考：

https://www.jianshu.com/p/c2ec5f06cf1a

### git rm（删除文件）

从Git仓库中删除文件。

```bash
git rm [-f] [--cached] <file>
```

将某文件从工作目录中删除（删除后会自动将该更改加入暂存区）：

```bash
git rm <file>
```

如果删除之前修改过并且已经放到暂存区域的话，则必须要用`-f`选项强行从暂存区和工作区中删除修改后的文件：

```bash
git rm -f <file>
```

使用`--cached`选项，将文件删除的更改加入暂存区，不删除工作目录中的该文件（文件会因此处于未跟踪状态）：

```bash
git rm --cached <file>
```

如果删除的是目录，可以用`-r`选项递归删除。

```bash
git rm -r <directory>
```

### git mv（移动文件）

移动或重命名一个文件、目录或软连接，并自动将更改加入暂存区：

```bash
git mv [-f] <file> <new-file>
```

如果新文件名已经存在，使用 `-f` 参数强制重命名。

### git tag（标签）

用于给仓库中的特定提交点加上标记，通常用于发布版本（如 v1.0, v2.0）。**标签不能重复**。

为最新的提交打上标签：

```bash
git tag <tag>
```

为标签添加注解和消息：

```bash
git tag -a <tag> -m <message>
```

为某个版本创建标签：

```bash
git tag <tag> <commit>
```

查看已有标签：

```bash
git tag
```

查看某个标签对应提交的信息：

```bash
git show [tag]
```

删除标签：

```bash
git tag -d <tag>
```

## 分支

假设你准备开发一个新功能，预计需要两周时间才能完成。第一周你编写了50%的代码。如果此时立即提交代码，由于代码尚未完成，不完整的代码库可能会导致其他团队成员无法正常工作。如果等到代码全部编写完成后再一次性提交，又存在丢失每日进度的风险。

现在有了分支功能。你可以创建一个属于自己的分支，其他团队成员无法看到这个分支，他们可以继续在主分支上正常工作，而你可以在自己的分支上进行开发。你可以随时提交代码，直到开发完毕后，再一次性合并到主分支上。这样既保证了代码的安全性，又不影响其他团队成员的工作。

由于创建、合并和删除分支的操作非常快速，Git鼓励你使用分支来完成某个任务。合并后可以删除分支，这与直接在主分支上工作效果相同，但过程更加安全。

### 新分支

当我们在Git中创建一个新的分支（例如`dev`）时，Git实际上会执行以下操作：

1. **创建指针**：首先，Git会创建一个新的指针（即`dev`），该指针最初指向与当前分支（假设为`master`）相同的提交。
2. **切换HEAD**：接着，将`HEAD`指针从原来的分支（如`master`）移动到新创建的分支`dev`上。这标志着当前工作环境已经切换到了`dev`分支。

#### 在新分支上的工作

一旦我们处于`dev`分支，对工作区所做的任何修改和提交都将仅影响`dev`分支。具体来说：

* 每当我们向仓库提交新的更改时，`dev`分支的指针会向前移动以反映最新的提交。
* 同时，原始的`master`分支保持不变，其指针位置不会因为`dev`分支上的活动而发生改变。

通过这种方式，Git允许开发者在独立的分支上进行开发而不干扰主分支的状态，直到准备好将更改合并回主分支或其它指定的目标分支。

![2](https://gastigado.cnies.org/d/public/2.webp)

### 合并分支

* 假如我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上。

* Git 直接把 master 指向 dev 的当前提交，就完成了合并。

### 删除分支

* 合并完分支后，可以删除dev分支。

* 删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支。

### git branch

用于分支管理：

```bash
git branch [-d] [branch]
```

查看当前的分支列表

```bash
git branch
```

新建分支

```bash
git branch <branch>
```

删除分支

```bash
git branch –d <branch>
```

### git checkout

用于切换分支。

```bash
git checkout [-b] <branch>
```

checkout命令职责较多，新版git提供了switch命令，以明确切换分支的行为。因此使用checkout和switch均可切换分支。

切换到某分支

```bash
git checkout <branch> 或 git switch <branch>
```

新建并切换到此分支

```bash
git checkout –b <branch>
git switch –c <branch>
# 两条指令左右是相同的
```

此命令相当于以下两条命令一起执行

```bash
git branch <branch>
git checkout <branch>
```

### git merge

用于合并指定分支到当前分支。

```bash
git merge [--squash | --no-ff] <branch>
```

`git merge` 有以下合并方式

#### 快进（Fast-Forward）合并策略

在Git中，当两个分支间存在直接的线性关系时（即一个分支的所有提交都是另一个分支的祖先），Git可以采用“快进”方式来执行合并操作。这种情况下，合并实际上只是简单地将指向旧分支的指针移动到新位置，而不会创建新的合并提交。

#### 递归（Recursive）合并策略

当进行合并的两个分支不存在直接的线性关系时，Git会使用递归合并策略。此过程涉及到创建一个新的合并提交，该提交综合了来自两个分支的所有变更，并且明确记录了这两个分支作为其父节点的历史信息。

#### 压缩（Squash）合并

在某些场景下，为了保持项目历史的整洁，开发者可能会选择压缩一系列提交为单个提交。例如，在将特性分支合并回主干时，如果希望避免引入开发过程中产生的多个杂乱无章的小提交，则可以通过squash合并实现。这一步骤会在不移动HEAD的情况下，预先准备合并的内容，之后需要额外手动创建一个总结性的提交来完成最终合并。

#### 禁用快进（No-Fast-Forward, --no-ff）

通过指定`--no-ff`选项，用户可以强制Git在合并时总是创建一个新的合并提交，即使条件允许进行快进式合并也不例外。这种方式有助于保留每次合并活动的痕迹，对于追踪历史变更尤其有用。

### 自动与手动解决冲突

在合并过程中，若两分支对不同文件进行了修改或在同一文件的不同行上进行了更改，则Git能够自动处理这些情况。然而，当双方尝试修改同一文件中的相同部分时，则会产生冲突，这时就需要人工介入来决定如何解决这些差异。

* **标记冲突**：Git使用特定符号（如`<<<<<<<`, `=======`, `>>>>>>>`）来区分冲突区域内的不同版本内容。
* **解决并提交**：编辑冲突文件以解决所有差异后，再次提交更新即可完成整个合并流程。

![输入图片说明](https://gastigado.cnies.org/d/public/gitbranch.webp)

资料：

[Git——](https://blog.csdn.net/Huang_ZX_259/article/details/122657055)[超详细讲解分支](https://blog.csdn.net/Huang_ZX_259/article/details/122657055)

## 更多学习教程

* 书籍推荐：《Git从入门到精通》 高见龙著， 全网最好的关于git原理和使用的书籍，非常适合入门学习，进阶学习！

* 书籍笔记：https://blog.csdn.net/syu\_acm/article/details/141530578

## Github

## 注册

访问 Github 官方网站 <https://github.com>，点击右上角的「Sign up」按钮。

![image-20240826164726801](https://gastigado.cnies.org/d/public/image-20240826164726801.webp)

和昵称（Name）不同，这个用户名将成为你在 GitHub 上的唯一标识符（GitHub ID），它必须由阿拉伯数字、英文字母组成，且最多可包含一个连字符（-），并且必须是全网唯一的。因为以后你的大部分仓库都是放在用户名下的，所以要起一个响亮好听的名字。

![image-20240826165746066](https://gastigado.cnies.org/d/public/image-20240826165746066.webp)

登录邮箱查看并输入验证码

![image-20240826170433898](https://gastigado.cnies.org/d/public/image-20240826170433898.webp)

如果无法输入验证码或者输入验证码后无响应，可以点击邮件中的链接或「Open GitHub」完成验证

![image-20240826170937734](https://gastigado.cnies.org/d/public/image-20240826170937734.webp)

验证你的邮箱地址后，你就拥有了一个 Github 账号，可以开始你的开源之旅了。

## 配置双重身份验证

以后我们要在Github上提交代码，这一步是必须的，所以我们要把它配置好。点击右上角头像 - Settings - Password and authentication - Enable two-factor authentication：

![1173617-20231207012802634-853465373](https://gastigado.cnies.org/d/public/1173617-20231207012802634-853465373.webp)

然后，你会看到这个界面：

打开手机应用商店，下载 Authenticator：

下载完成后点击右上角“+”，账号类型选择选择个人账号，然后选择“扫描QR码”，扫描完成后APP内就会出现 Github 中就出现了Github 账号，下面的数字就是动态验证码：

下一步非常重要，下载保存恢复码，并建议在网盘、U盘多备份几遍。便于哪天万一手机设备不可用或丢失时，可通过【恢复码】充当备用（相对于手机认证器）进行验证。

## SSH

目前我们使用到的 Git 命令都是在本地执行，如果你想通过 Git 分享你的代码或者与其他开发人员合作，你就需要将数据放到一台其他开发人员能够连接的服务器上。

### 配置 SSH

### git remote（远程开发）

添加远程仓库：

```bash
git remote add <远程主机名> <url>
```

查看当前配置有哪些远程仓库。加上 -v 参数可以看到每个别名的实际链接地址：

```bash
git remote [-v]
```

删除远程仓库：

```bash
git remote rm <shortname>
```

### git push

用于从将本地的分支版本上传到远程并合并。

```bash
 git push [-u] <远程主机名> <本地分支名>:<远程分支名>
```

E.g.

```bash
git push origin master:master
git push origin master
```

### git fetch/pull

`git fetch` 命令用于从远程获取代码库中更新的内容。

```bash
 git fetch [shortname]
```

获取到之后可以将其merge。

```bash
 git merge [shortname]/[branch]
```

`git pull`命令简化了上述流程，用于从远程获取更新代码并自动合并本地的版本。

```bash
git pull <远程主机名> <远程分支名>:<本地分支名>
```

E.g.

```bash
 git pull
 git pull origin
 git pull origin master:master
 git pull origin master
```

## 贡献和规范

在代码仓库托管平台上，如果你发现了别人的项目中的问题或者有建议，可以发起Issue。

如果你认为你可以解决你发现的问题，或者你希望以别人的开源项目为基础进行二次开发，可以将别人的项目Fork一份，Fork得到的项目可用于你自己开发。

如果你在Fork的项目中修复了问题，或者为其贡献了新功能，可以发起Pull Request请求合并。

对于别人提交的Pull Request，原仓库作者可以审查修改的代码，并决定合并或拒绝。

### 其他教程

## 中文排版

Latex、Markdown、HTML 具有相似性（类比 Word）。

#### 排版规范性

* **LaTeX**：以其严谨的排版规则著称，特别适合于生成高质量的技术文档和学术论文。它支持复杂的数学公式和图表布局，确保了专业性和一致性。
* **Markdown**：提供了一种轻量级的方法来格式化文本，适用于快速写作和笔记记录。虽然在复杂布局方面不如LaTeX强大，但其简洁性保证了内容的一致性和可读性。
* **HTML**：提供了丰富的标记语言用于网页设计，允许高度定制化的页面布局。然而，由于灵活性高，不同开发者可能产生风格迥异的结果，这要求团队内部有统一的设计指南。

#### 可移植性

* **LaTeX/Markdown**：两者都具有良好的跨平台兼容性，可以轻松转换成多种输出格式（如PDF, HTML等），便于分享。
* **HTML**：本质上是为Web浏览而设计的，因此在任何现代浏览器中都能良好显示。不过，对于非Web环境下的阅读体验可能会有所限制。
* **Word**：虽然Word文档(.docx)现在也支持一定程度上的跨平台使用，但在不同操作系统或软件版本之间仍可能存在兼容性问题。

#### 版本控制、快速搭建及团队协作

* **LaTeX/Markdown/HTML + Git**：结合Git进行版本管理，非常适合技术文档编写。它们都是纯文本文件，易于通过Git追踪修改历史，并且支持多人同时编辑同一份文档，促进高效协作。
* **Word + Git**：尽管也可以将Word文件纳入Git管理，但由于.docx实际上是一个包含多个文件的压缩包，直接使用Git跟踪变更较为困难，也不利于解决冲突。

### Docs like code 技术写作流程介绍

Docs like code是一种强调使用软件开发的最佳实践来进行文档创作的方法论。这种方法的核心理念包括：

* **版本控制**：利用Git等工具对文档进行版本管理，确保每次更改都有迹可循。
* **快速搭建**：采用自动化工具简化构建过程，比如使用静态站点生成器从Markdown文件自动生成网站。
* **团队协作**：鼓励开放式的合作模式，让每个人都可以贡献自己的知识和技能，共同维护和发展项目文档库。

通过实施Docs like code方法，不仅可以提高文档的质量和一致性，还能增强团队成员之间的沟通效率。更重要的是，这种方式能够直观地展示个人能力——通过实际产出物而非仅仅口头描述来证明自己掌握了相关技能。此外，基于项目的文档撰写活动也为参与者提供了宝贵的学习机会，促进了知识共享文化的发展。

参考资料：

* [Markdown 排版指北](https://fosscope.com/wiki/fosscope-workflow/markdown-format-guidelines)
* [LaTex 的基本介绍](/writing/01-LaTeX-Introduction)

---

---
url: https://ain.hmgf.hxcn.space/sre/config-file-formats.md
---
# 配置文件格式详解

做开发和运维，配置文件是绕不开的东西。选对格式能省很多事，选错了后期维护就是噩梦。这里把主流的配置文件格式都过一遍，说清楚各自的特点和适用场景。

## JSON

JSON 是最通用的配置格式，几乎所有编程语言都能解析。语法简单，就是键值对和嵌套对象。

**优点：**

* 语法简单，学习成本低
* 所有语言都有原生支持
* 数据类型明确（字符串、数字、布尔、数组、对象、null）
* Schema 验证工具成熟（JSON Schema）

**缺点：**

* 不支持注释，这是最大的痛点
* 尾逗号会报错，复制粘贴时容易出错
* 字符串必须用双引号，配置文件里写起来不够简洁
* 多行字符串需要转义，写 SQL 或证书内容很痛苦

**适用场景：** API 响应、package.json、tsconfig.json 这类程序生成或消费的配置。

```json
{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.18.0"
  },
  "scripts": {
    "start": "node index.js"
  }
}
```

## YAML

YAML 专门为人写配置设计的，缩进表示层级关系，可读性很好。Docker Compose、Kubernetes、GitHub Actions 都用它。

**优点：**

* 支持注释，用 `#` 开头
* 语法简洁，没有多余符号
* 支持多行字符串（`|` 保留换行，`>` 折叠换行）
* 支持锚点和引用，可以复用配置片段

**缺点：**

* 缩进敏感，Tab 和空格混用会出问题
* 隐式类型转换坑多（`yes` 会被解析成 `true`，`1.0` 变成浮点数）
* 解析比 JSON 慢
* 错误提示不够友好，缩进错了很难定位

**适用场景：** Docker Compose、Kubernetes 清单、CI/CD 配置、Ansible Playbook。

```yaml
# Docker Compose 示例
version: '3.8'

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - api

  api:
    build: .
    environment:
      NODE_ENV: production
      DATABASE_URL: postgres://db:5432/myapp
    restart: unless-stopped
```

## TOML

TOML 设计目标就是做配置文件，语义清晰，类型明确。Rust 的 Cargo、Python 的 pyproject.toml 都用它。

**优点：**

* 支持注释
* 类型系统严格，不会出现 YAML 那种隐式转换
* 表格结构清晰，用 `[section]` 表示层级
* 日期时间有原生支持
* 尾逗号合法

**缺点：**

* 嵌套太深时可读性下降
* 数组里放表格的语法有点奇怪（`[[array]]`）
* 比 JSON 和 YAML 小众，部分工具支持不完善

**适用场景：** Rust/Cargo、Python/pyproject.toml、Hugo 配置、系统工具配置。

```toml
# Cargo.toml 示例
[package]
name = "my-project"
version = "0.1.0"
edition = "2021"

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

[dev-dependencies]
criterion = "0.5"

[[bench]]
name = "my_benchmark"
harness = false
```

## INI

INI 是最古老的配置格式之一，Windows 系统大量使用。结构简单，适合扁平配置。

**优点：**

* 语法极其简单，人人都能看懂
* 支持注释（`;` 或 `#`）
* 解析速度快

**缺点：**

* 没有官方标准，不同解析器行为不一致
* 不支持嵌套结构
* 数据类型只有字符串
* 数组支持靠约定（重复键或逗号分隔）

**适用场景：** 简单的键值配置、.gitignore、Python 的 setup.cfg。

```ini
[database]
host = localhost
port = 5432
user = admin
password = secret123
dbname = myapp

[logging]
level = INFO
file = /var/log/app.log
```

## XML

XML 曾经是配置文件的主流选择，现在主要用于 Java 生态和需要 Schema 验证的场景。

**优点：**

* Schema 验证完善（XSD、DTD）
* 支持命名空间
* 属性和元素两种表达方式
* 注释支持良好

**缺点：**

* 冗余标签太多，文件体积大
* 可读性比 JSON 和 YAML 差
* 解析开销大

**适用场景：** Maven/pom.xml、Spring 配置、SOAP API、Android 布局。

```xml
<!-- Maven pom.xml 片段 -->
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.1.0</version>
        </dependency>
    </dependencies>
</project>
```

## ENV

.env 文件用于管理环境变量，Docker 和各种框架都支持。格式就是 `KEY=VALUE`。

**优点：**

* 格式最简单，没有任何学习成本
* 和操作系统环境变量无缝对接
* .gitignore 容易管理，敏感信息不会提交

**缺点：**

* 只有扁平的键值对
* 没有数据类型，全是字符串
* 不支持注释内联（注释必须独占一行）
* 不同工具解析行为不一致

**适用场景：** Docker 环境变量、应用密钥配置、本地开发配置。

```env
# .env 示例
NODE_ENV=production
PORT=3000
DATABASE_URL=postgres://user:pass@localhost:5432/db
REDIS_URL=redis://localhost:6379
SECRET_KEY=your-secret-key-here
```

## HCL

HCL（HashiCorp Configuration Language）是 Terraform 和 Vault 专用的配置语言，兼顾人可读性和机器解析。

**优点：**

* 语法接近自然语言
* 支持表达式和函数
* 块结构清晰
* 注释支持

**缺点：**

* 主要限于 HashiCorp 生态
* 学习曲线比 JSON 陡
* 第三方工具支持少

**适用场景：** Terraform 基础设施即代码、Vault 配置、Consul 配置。

```hcl
# Terraform 配置示例
provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "HelloWorld"
  }
}
```

## Properties

Java 的 `.properties` 文件，格式和 .env 类似，但在 Java 生态里根深蒂固。

**优点：**

* Java 原生支持
* 格式简单
* 支持 Unicode 转义

**缺点：**

* 只支持扁平键值对
* 没有数据类型
* 编码问题（默认 ISO-8859-1）

**适用场景：** Spring Boot 配置、Java 应用国际化、Maven settings。

```properties
# application.properties
server.port=8080
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=secret
```

## 格式选择建议

选配置文件格式没有银弹，看你的具体需求：

| 场景 | 推荐格式 | 理由 |
|------|----------|------|
| API 数据交换 | JSON | 通用性最好 |
| Docker/K8s | YAML | 生态约定 |
| Rust/Go 项目 | TOML | 类型安全 |
| 基础设施即代码 | HCL | 专为此设计 |
| 环境变量 | .env | 简单直接 |
| Java 项目 | Properties/YAML | 框架支持 |
| 简单键值 | INI | 最易上手 |

几个实用建议：

1. **能用注释就别用 JSON** —— 配置文件需要注释说明意图，JSON 这点太反人类
2. **人写的配置优先 YAML/TOML** —— 可读性好，写起来舒服
3. **机器生成的配置用 JSON** —— 程序解析和生成都方便
4. **敏感信息用 .env** —— 容易和 .gitignore 配合
5. **团队统一最重要** —— 选团队最熟悉的格式，别折腾

## 配置文件最佳实践

不管用哪种格式，这些原则都适用：

### 分离环境配置

别把所有环境的配置混在一起：

```
config/
├── default.yml      # 默认配置
├── development.yml  # 开发环境
├── staging.yml      # 预发布环境
└── production.yml   # 生产环境
```

### 敏感信息不要提交

密钥、密码、Token 这类东西绝对不能进 Git：

```gitignore
# .gitignore
.env
.env.local
*.pem
secrets.yml
```

### 使用 Schema 验证

JSON 和 YAML 都支持 Schema，能在启动前发现配置错误：

```json
// JSON Schema 示例
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["port", "database"],
  "properties": {
    "port": {
      "type": "integer",
      "minimum": 1024,
      "maximum": 65535
    },
    "database": {
      "type": "object",
      "required": ["host", "port"],
      "properties": {
        "host": { "type": "string" },
        "port": { "type": "integer" }
      }
    }
  }
}
```

### 配置即文档

好的配置文件应该自解释：

```yaml
# 差的写法
timeout: 30

# 好的写法
# API 请求超时时间，单位秒。网络不好的环境可以适当调大。
api:
  request_timeout: 30
```

### 版本化配置

配置文件也要版本管理，但敏感信息除外：

```bash
# 配置模板提交到 Git
config.yml.example

# 实际配置不提交
config.yml
```

---

---
url: https://ain.hmgf.hxcn.space/sre/network-basics.md
---
# 网络基础

网络知识是计算机学习的基础。IP 地址、网络类型、协议这些概念，用电脑的人都应该了解。

## 网络类型

### 网络类型全解析：一看就懂

局域网、广域网、城域网、个人域网，不同网络类型覆盖范围和用途不一样。家里用的 Wi-Fi 是局域网，手机热点算个人域网。这个视频把各种网络类型的特点和适用场景讲得很清楚。

### 网络类型详细分类

#### PAN（Personal Area Network）- 个人域网

覆盖范围最小的网络，通常只有几米。

**典型场景：**

* 蓝牙耳机连接手机
* 手机热点共享网络
* 智能手表与手机配对
* USB 线连接手机和电脑

**技术特点：**

* 覆盖范围：1-10 米
* 传输速率：1-3 Mbps（蓝牙），最高 480 Mbps（USB）
* 典型技术：蓝牙、红外、NFC、USB

#### LAN（Local Area Network）- 局域网

覆盖一个局部区域的网络，比如家庭、办公室、学校。

**典型场景：**

* 家里路由器连接的设备
* 公司内部网络
* 学校校园网
* 网吧内部网络

**技术特点：**

* 覆盖范围：几十米到几公里
* 传输速率：100 Mbps - 10 Gbps
* 典型技术：以太网（Ethernet）、Wi-Fi
* 延迟极低：通常小于 1ms

**局域网内的设备通信：**

* 通过交换机或路由器连接
* 使用 MAC 地址识别设备
* 可以共享文件、打印机、网络

#### MAN（Metropolitan Area Network）- 城域网

覆盖一个城市的网络，通常是运营商建设。

**典型场景：**

* 城市宽带网络
* 有线电视网络
* 城市级企业网络

**技术特点：**

* 覆盖范围：一个城市
* 传输速率：100 Mbps - 100 Gbps
* 典型技术：光纤、SDH、MPLS

#### WAN（Wide Area Network）- 广域网

覆盖范围最大的网络，跨城市、跨国家、跨大洲。互联网就是最大的广域网。

**典型场景：**

* 互联网
* 跨国企业内部网络
* 银行跨区域网络

**技术特点：**

* 覆盖范围：全球
* 传输速率：变化很大
* 典型技术：光纤、卫星、海底光缆
* 延迟较高：跨洲通信延迟可达 100-300ms

#### 网络类型对比

| 网络类型 | 覆盖范围 | 典型技术 | 传输速率 | 典型场景 |
|---------|---------|---------|---------|---------|
| PAN | 1-10 米 | 蓝牙、NFC | 1-3 Mbps | 个人设备互联 |
| LAN | 几十米-几公里 | 以太网、Wi-Fi | 100M-10Gbps | 家庭、办公室 |
| MAN | 一个城市 | 光纤、SDH | 100M-100Gbps | 城市宽带 |
| WAN | 全球 | 光纤、卫星 | 变化大 | 互联网 |

## 网络原理

### 大白话半小时理解网络

网络原理听起来复杂，但核心概念其实不多。这个视频用大白话把网络的基础知识讲了一遍，从物理层到应用层，半小时就能建立基本概念。如果你是网络小白，从这个视频开始不会错。

### OSI 七层模型

OSI（Open Systems Interconnection）模型把网络通信分成 7 层，每层负责不同的功能。理解这个模型，就理解了网络通信的全貌。

#### 第一层：物理层（Physical Layer）

负责在物理介质上传输原始比特流。

**涉及内容：**

* 网线（双绞线、光纤）
* 无线信号（Wi-Fi、蓝牙）
* 电压、电流、光信号
* 接口标准（RJ45、光纤接口）

**常见设备：**

* 网线
* 光纤
* 集线器（Hub）
* 中继器（Repeater）

#### 第二层：数据链路层（Data Link Layer）

负责在相邻节点之间可靠地传输数据帧。

**核心概念：**

* **MAC 地址**：设备的物理地址，全球唯一，48 位
* **帧（Frame）**：数据链路层的传输单位
* **交换机**：根据 MAC 地址转发数据

**常见设备：**

* 交换机（Switch）
* 网桥（Bridge）

**MAC 地址格式：**

```
AA:BB:CC:DD:EE:FF
```

* 前 24 位：厂商编号（OUI）
* 后 24 位：设备编号

#### 第三层：网络层（Network Layer）

负责在不同网络之间传输数据包。

**核心概念：**

* **IP 地址**：设备的逻辑地址
* **路由**：选择数据包的传输路径
* **路由器**：连接不同网络的设备

**常见协议：**

* IP（Internet Protocol）
* ICMP（Internet Control Message Protocol）
* ARP（Address Resolution Protocol）
* OSPF、BGP（路由协议）

**常见设备：**

* 路由器（Router）
* 三层交换机

#### 第四层：传输层（Transport Layer）

负责端到端的可靠传输。

**核心概念：**

* **端口号**：区分不同的应用程序（0-65535）
* **TCP**：可靠传输，有连接、有序、重传机制
* **UDP**：不可靠传输，无连接、速度快

**TCP vs UDP：**

| 特性 | TCP | UDP |
|------|-----|-----|
| 连接 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠（重传、确认） | 不可靠 |
| 顺序 | 保证顺序 | 不保证 |
| 速度 | 较慢 | 较快 |
| 用途 | 网页、邮件、文件传输 | 视频、语音、游戏 |

**常见应用端口：**

* HTTP：80
* HTTPS：443
* SSH：22
* FTP：21
* DNS：53
* MySQL：3306
* Redis：6379

#### 第五层：会话层（Session Layer）

负责建立、管理和终止会话。

**功能：**

* 会话建立和断开
* 会话恢复
* 数据同步

#### 第六层：表示层（Presentation Layer）

负责数据的格式转换、加密解密、压缩解压。

**功能：**

* 数据格式转换（如 JPEG、ASCII）
* 数据加密解密（如 SSL/TLS）
* 数据压缩解压

#### 第七层：应用层（Application Layer）

直接为用户的应用程序提供服务。

**常见协议：**

* **HTTP/HTTPS**：网页浏览
* **SMTP/POP3/IMAP**：电子邮件
* **FTP/SFTP**：文件传输
* **DNS**：域名解析
* **DHCP**：自动分配 IP 地址
* **SSH**：远程登录
* **Telnet**：远程登录（不安全）

#### 数据封装过程

发送数据时，数据从应用层到物理层逐层封装：

```
应用层数据
    ↓
[传输层头部] + 应用层数据  → 段（Segment）
    ↓
[网络层头部] + 段  → 包（Packet）
    ↓
[数据链路层头部] + 包 + [尾部]  → 帧（Frame）
    ↓
[物理层]  → 比特流（Bits）
```

接收数据时，从物理层到应用层逐层解封装，去掉每一层的头部信息。

### TCP/IP 四层模型

实际使用中更常用的是 TCP/IP 四层模型，它是 OSI 模型的简化版本：

| TCP/IP 模型 | OSI 模型 | 主要协议 |
|------------|---------|---------|
| 应用层 | 应用层 + 表示层 + 会话层 | HTTP, FTP, DNS, SMTP |
| 传输层 | 传输层 | TCP, UDP |
| 网络层 | 网络层 | IP, ICMP, ARP |
| 网络接口层 | 数据链路层 + 物理层 | 以太网, Wi-Fi |

## IP 地址

### IP 地址基础

IP 地址是网络中设备的唯一标识，就像门牌号一样。

#### IPv4 地址

IPv4 地址由 32 位二进制数组成，通常用点分十进制表示。

**格式：** `192.168.1.1`

**地址分类：**

| 类别 | 范围 | 默认子网掩码 | 用途 |
|------|------|-------------|------|
| A 类 | 1.0.0.0 - 126.255.255.255 | 255.0.0.0 (/8) | 大型网络 |
| B 类 | 128.0.0.0 - 191.255.255.255 | 255.255.0.0 (/16) | 中型网络 |
| C 类 | 192.0.0.0 - 223.255.255.255 | 255.255.255.0 (/24) | 小型网络 |
| D 类 | 224.0.0.0 - 239.255.255.255 | - | 组播 |
| E 类 | 240.0.0.0 - 255.255.255.255 | - | 保留 |

**特殊地址：**

* `127.0.0.1`：本地回环地址（localhost）
* `0.0.0.0`：表示所有地址
* `255.255.255.255`：广播地址

**私有地址（局域网使用）：**

* A 类：10.0.0.0 - 10.255.255.255
* B 类：172.16.0.0 - 172.31.255.255
* C 类：192.168.0.0 - 192.168.255.255

#### 子网掩码

子网掩码用于区分 IP 地址中的网络部分和主机部分。

**示例：**

```
IP 地址：192.168.1.100
子网掩码：255.255.255.0 (/24)

网络部分：192.168.1
主机部分：100
```

**CIDR 表示法：**

* `/24` 表示前 24 位是网络部分
* `/16` 表示前 16 位是网络部分
* `/8` 表示前 8 位是网络部分

**子网划分示例：**

```
网络：192.168.1.0/24
可用 IP：192.168.1.1 - 192.168.1.254
广播地址：192.168.1.255
可用主机数：254
```

#### IPv6 地址

IPv6 地址由 128 位二进制数组成，用冒号分隔的十六进制表示。

**格式：** `2001:0db8:85a3:0000:0000:8a2e:0370:7334`

**简写规则：**

* 前导零可以省略：`2001:db8:85a3:0:0:8a2e:370:7334`
* 连续的全零可以用 `::` 替代：`2001:db8:85a3::8a2e:370:7334`
* `::` 只能使用一次

**IPv6 的优势：**

* 地址空间巨大（2^128 个地址）
* 自动配置（SLAAC）
* 更好的安全性（内置 IPSec）
* 更简洁的头部结构

### 查看本机 IP 地址

**方法一：命令提示符**

```cmd
ipconfig
```

**方法二：PowerShell**

```powershell
Get-NetIPAddress
```

**方法三：设置**

1. 设置 → 网络和 Internet
2. 点击当前连接的网络
3. 查看 IP 地址

### DNS 域名解析

DNS（Domain Name System）负责把域名转换成 IP 地址。

**工作流程：**

1. 浏览器输入 `www.example.com`
2. 浏览器缓存 → 系统缓存 → 路由器缓存
3. 本地 DNS 服务器
4. 根 DNS 服务器 → 顶级域名服务器 → 权威 DNS 服务器
5. 返回 IP 地址
6. 浏览器访问该 IP 地址

**常用公共 DNS：**

* 阿里 DNS：223.5.5.5 / 223.6.6.6
* 腾讯 DNS：119.29.29.29
* 百度 DNS：180.76.76.76
* Google DNS：8.8.8.8 / 8.8.4.4
* Cloudflare DNS：1.1.1.1

**修改 DNS 方法：**

1. 控制面板 → 网络和共享中心
2. 点击当前连接 → 属性
3. 双击"Internet 协议版本 4 (TCP/IPv4)"
4. 选择"使用下面的 DNS 服务器地址"
5. 输入 DNS 地址

## 网络设备

### 常见网络设备

#### 路由器（Router）

连接不同网络的设备，负责数据包的转发和路由选择。

**家用路由器功能：**

* 连接互联网（WAN 口）
* 组建局域网（LAN 口）
* 无线 Wi-Fi
* DHCP 服务器（自动分配 IP）
* NAT（网络地址转换）
* 防火墙

**路由器 vs 交换机：**

* 路由器：连接不同网络，有 NAT、DHCP 功能
* 交换机：连接同一网络内的设备，根据 MAC 地址转发

#### 交换机（Switch）

连接同一网络内的多台设备，根据 MAC 地址转发数据。

**工作原理：**

1. 学习：记录每个端口连接的设备 MAC 地址
2. 转发：根据目标 MAC 地址转发数据
3. 过滤：只转发到目标端口，不广播
4. 消除环路：使用 STP 协议

#### 调制解调器（Modem）

将数字信号转换为模拟信号，或将模拟信号转换为数字信号。

**类型：**

* **光纤猫**：光纤入户，将光信号转换为电信号
* **ADSL Modem**：电话线宽带，将数字信号调制为电话线可传输的信号
* **Cable Modem**：有线电视网络

### 查看网络设备信息

**查看本机网关：**

```cmd
ipconfig
```

**查看路由表：**

```cmd
route print
```

**测试网络连通性：**

```cmd
ping 8.8.8.8
```

**查看数据包路径：**

```cmd
tracert www.baidu.com
```

**查看 DNS 解析：**

```cmd
nslookup www.baidu.com
```

## 无线网络

### Wi-Fi 基础

Wi-Fi 是无线局域网技术，让设备不用网线就能连接网络。

#### Wi-Fi 标准

| 标准 | 名称 | 频段 | 最大速率 | 特点 |
|------|------|------|---------|------|
| 802.11a | Wi-Fi 1 | 5 GHz | 54 Mbps | 早期标准 |
| 802.11b | Wi-Fi 2 | 2.4 GHz | 11 Mbps | 早期标准 |
| 802.11g | Wi-Fi 3 | 2.4 GHz | 54 Mbps | 兼容 802.11b |
| 802.11n | Wi-Fi 4 | 2.4/5 GHz | 600 Mbps | 双频 |
| 802.11ac | Wi-Fi 5 | 5 GHz | 6.9 Gbps | 5G 专用 |
| 802.11ax | Wi-Fi 6 | 2.4/5 GHz | 9.6 Gbps | OFDMA、MU-MIMO |
| 802.11ax | Wi-Fi 6E | 6 GHz | 9.6 Gbps | 新增 6 GHz 频段 |
| 802.11be | Wi-Fi 7 | 2.4/5/6 GHz | 46 Gbps | 最新标准 |

#### 2.4 GHz vs 5 GHz vs 6 GHz

| 频段 | 优点 | 缺点 | 适用场景 |
|------|------|------|---------|
| 2.4 GHz | 穿墙能力强，覆盖范围大 | 速度慢，干扰多 | 远距离、穿墙 |
| 5 GHz | 速度快，干扰少 | 穿墙能力弱，覆盖范围小 | 近距离、高速传输 |
| 6 GHz | 速度最快，干扰最少 | 覆盖范围最小 | 超高速需求 |

#### Wi-Fi 安全

**加密方式：**

* **WEP**：已淘汰，不安全
* **WPA**：较老，安全性一般
* **WPA2**：目前主流，推荐使用
* **WPA3**：最新标准，安全性最高

**安全建议：**

* 使用 WPA2 或 WPA3 加密
* 设置强密码（至少 12 位，包含大小写字母、数字、符号）
* 定期更换密码
* 关闭 WPS 功能（容易被暴力破解）
* 隐藏 SSID（可选）
* 开启 MAC 地址过滤（可选）

### 网络命令速查

| 命令 | 功能 | 示例 |
|------|------|------|
| `ipconfig` | 查看网络配置 | `ipconfig /all` |
| `ping` | 测试连通性 | `ping 8.8.8.8` |
| `tracert` | 追踪路由 | `tracert www.baidu.com` |
| `nslookup` | DNS 查询 | `nslookup www.baidu.com` |
| `netstat` | 查看网络连接 | `netstat -an` |
| `arp` | 查看 ARP 表 | `arp -a` |
| `route` | 查看路由表 | `route print` |
| `nbtstat` | 查看 NetBIOS | `nbtstat -n` |
| `netsh` | 网络配置工具 | `netsh wlan show profiles` |

### 查看已保存的 Wi-Fi 密码

```cmd
# 查看所有已保存的 Wi-Fi 配置
netsh wlan show profiles

# 查看特定 Wi-Fi 的密码
netsh wlan show profile name="Wi-Fi名称" key=clear
```

在输出中找到"关键内容"字段，就是 Wi-Fi 密码。

---

---
url: https://ain.hmgf.hxcn.space/ai.md
description: AI 编程、Agent、写作、学习、科研和工具文章总览。
---

# AI 教程

---

---
url: https://ain.hmgf.hxcn.space/ai/improving-frontend-design-through-skills.md
description: 使用 Claude 和 Skills 构建更丰富、更定制化的前端设计的最佳实践。
---

# 通过 Skills 改善前端设计

> 使用 Claude 和 Skills 构建更丰富、更定制化的前端设计的最佳实践。

你可能会注意到，当你要求 LLM 在没有指导的情况下构建落地页时，它几乎总是倾向于使用 Inter 字体、白色背景上的紫色渐变，以及最少的动画。

问题出在哪里？[分布收敛（Distributional convergence）](https://baike.baidu.com/item/%E6%A6%82%E7%8E%87%E6%94%B6%E6%95%9B%E6%80%A7/22927334)。在采样期间，模型根据训练数据中的统计模式预测 token。安全的设计选择（那些放之四海而皆准且不会冒犯任何人的选择）主导了网络训练数据。如果没有方向指导，Claude 就会从这个高概率中心进行采样。

对于构建面向客户的产品的开发者来说，这种通用美学削弱了品牌标识，并使 AI 生成的界面很容易被认出——且不被重视。

### 可控性挑战

好消息是，有了正确的提示词，Claude 是高度可控的。告诉 Claude“避免使用 Inter 和 Roboto”或“使用有氛围感的背景而不是纯色”，结果会立即改善。这种对指导的敏感性是一个特性；这意味着 Claude 可以适应不同的设计上下文、约束和美学偏好。

但这带来了一个实际的挑战：任务越专业，你需要提供的上下文就越多。对于前端设计，有效的指导涵盖排版原则、色彩理论、动画模式和背景处理。你需要指定要避免哪些默认设置，并在多个维度上倾向于哪些替代方案。

你可以将所有这些打包到一个系统提示词中，但是这样一来，每个请求（调试 Python、分析数据、写邮件）都会携带前端设计的上下文。问题变成了：你如何在恰好需要时为 Claude 提供特定领域的指导，而不会为不相关的任务带来永久的上下文开销？

## Skills：动态上下文加载

这正是 [Skills](https://www.anthropic.com/news/skills) 设计的目的：按需提供专业上下文，且没有永久开销。Skill 是一个文档（通常是 markdown），包含指令、约束和领域知识，存储在 Claude 可以通过简单的文件读取工具访问的指定目录中。Claude 可以利用这些 Skill 在运行时动态加载所需的信息，逐步增强其上下文，而不是预先加载所有内容。

当配备了这些 Skill 以及读取它们所需的工具时，Claude 可以根据手头的任务自主识别并加载相关的 Skill。例如，当被要求构建落地页或创建 React 组件时，Claude 可以加载前端设计 Skill 并即时应用其指令。这是基本的心理模型：Skill 是按需激活的提示词和上下文资源，为特定任务类型提供专门的指导，而不会产生永久的上下文开销。

这使开发者能够获得 Claude 可控性的好处，而不会因为将跨许多任务的不同指令塞入系统提示词而使上下文窗口超载。正如我们[之前解释过的那样](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)，上下文窗口中过多的 token 会导致性能下降，因此保持上下文窗口的内容精简和专注，对于激发模型的最佳性能极其重要。Skills 通过使有效的提示词可重用和语境化解决了这个问题。

## 提示词以获得更好的前端输出

通过创建一个前端设计 Skill，我们可以从 Claude 解锁显著提升的 UI 生成效果，而且没有永久的上下文开销。核心见解是以前端工程师的方式思考前端设计。你越能将美学改进映射到可实现的前端代码，Claude 执行得就越好。

利用这一见解，我们确定了几个目标提示词效果良好的领域：排版、动画、背景效果和主题。这些都可以清晰地转换为 Claude 可以编写的代码。在你的提示词中实现这一点不需要详细的技术指令，只需使用有针对性的语言，让模型更批判性地思考这些设计轴心，就足以引发更强大的输出。这与我们在[上下文工程（context engineering）](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)博客文章中提供的指导密切相关，即在正确的高度提示模型，避免走极端：诸如指定确切的十六进制代码的低空硬编码逻辑，或是假设存在共享上下文的模糊的高空指导。

### **排版 (Typography)**

为了看看它的实际效果，让我们首先将排版视为我们可以通过提示词影响的一个维度。下面的提示词明确引导 Claude 使用更有趣的字体：

```plaintext
<use_interesting_fonts>
Typography instantly signals quality. Avoid using boring, generic fonts.

Never use: Inter, Roboto, Open Sans, Lato, default system fonts

Here are some examples of good, impactful choices:
- Code aesthetic: JetBrains Mono, Fira Code, Space Grotesk
- Editorial: Playfair Display, Crimson Pro
- Technical: IBM Plex family, Source Sans 3
- Distinctive: Bricolage Grotesque, Newsreader

Pairing principle: High contrast = interesting. Display + monospace, serif + geometric sans, variable font across weights.

Use extremes: 100/200 weight vs 800/900, not 400 vs 600. Size jumps of 3x+, not 1.5x.

Pick one distinctive font, use it decisively. Load from Google Fonts.
</use_interesting_fonts>
```

**使用基础提示词生成的输出：**

![img](https://gastigado.cnies.org/d/public/691366f388193282b0213316_image11.png)

**使用基础提示词和排版部分生成的输出：**

![img](https://gastigado.cnies.org/d/public/6913679c9a202c88b680873b_image13.webp)

‍

有趣的是，强制使用更有趣的字体的指令似乎也鼓励了模型改进设计的其他方面。

仅排版就能带来显著的改进，但字体只是一个维度。整个界面的凝聚美学又如何呢？

### **主题 (Themes)**

我们可以提示的另一个维度是受知名主题和美学启发的设计。Claude 对流行主题有丰富的理解；我们可以用它来传达我们希望前端体现的特定美学。这里有一个例子：

```javascript
<always_use_rpg_theme>
Always design with RPG aesthetic:
- Fantasy-inspired color palettes with rich, dramatic tones
- Ornate borders and decorative frame elements
- Parchment textures, leather-bound styling, and weathered materials
- Epic, adventurous atmosphere with dramatic lighting
- Medieval-inspired serif typography with embellished headers
</always_use_rpg_theme>
```

这会产生以下 RPG 主题的 UI：

![img](https://gastigado.cnies.org/d/public/6913cec4181329835d1da27f_image2.webp)

排版和主题表明有针对性的提示词是有效的。但是手动指定每个维度是很繁琐的。如果我们可以将所有这些改进组合成一个可重用的资产呢？

### **一个通用的提示词**

同样的原则延伸到其他设计维度：对动效（动画和微交互）的提示增加了静态设计所缺乏的精致感，而引导模型做出更有趣的背景选择则创造了深度和视觉趣味。这就是一个综合 Skill 大放异彩的地方。

将所有这些结合起来，我们开发了一个约 400 token 的提示词——足够紧凑，加载时不会使上下文膨胀（即使作为 Skill 加载）——它可以极大地改善前端在排版、色彩、动效和背景方面的输出：

```plaintext
<frontend_aesthetics>
You tend to converge toward generic, "on distribution" outputs. In frontend design,this creates what users call the "AI slop" aesthetic. Avoid this: make creative,distinctive frontends that surprise and delight. 

Focus on:
- Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics.
- Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw from IDE themes and cultural aesthetics for inspiration.
- Motion: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions.
- Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer CSS gradients, use geometric patterns, or add contextual effects that match the overall aesthetic.

Avoid generic AI-generated aesthetics:
- Overused font families (Inter, Roboto, Arial, system fonts)
- Clichéd color schemes (particularly purple gradients on white backgrounds)
- Predictable layouts and component patterns
- Cookie-cutter design that lacks context-specific character

Interpret creatively and make unexpected choices that feel genuinely designed for the context. Vary between light and dark themes, different fonts, different aesthetics. You still tend to converge on common choices (Space Grotesk, for example) across generations. Avoid this: it is critical that you think outside the box!
</frontend_aesthetics>
```

在上面的例子中，我们首先为 Claude 提供关于问题以及我们要解决的内容的一般上下文。我们发现为模型提供这种高层次的上下文是一种有助于校准输出的提示词策略。然后，我们确定了之前讨论过的改进设计的载体，并给出有针对性的建议，以鼓励模型在所有这些维度上进行更具创造性的思考。

我们还在末尾包含了额外的指导，以防止 Claude 收敛到不同的局部最优。即使有明确的指令要求避免某些模式，模型也可能默认使用其他常见选择（如排版的 Space Grotesk）。最后提醒它“跳出框框思考（think outside the box）”，强化了创造性的变化。

### **对前端设计的影响**

激活此 Skill 后，Claude 的输出在多种类型的前端设计上都有所改善，包括：

**示例 1：SaaS 落地页**

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f77b_6d547f28.webp)

**说明：** AI 生成的 SaaS 落地页，采用通用的 Inter 字体、紫色渐变和标准布局。没有使用任何 Skill。

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f790_c47f37ab.webp)

**说明：** 使用与上述渲染相同的提示词并加上前端 Skill 生成的 AI 前端，现在具有独特的排版、有凝聚力的配色方案和分层的背景。

**示例 2：博客布局**

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f78d_f7040147.png)

使用默认系统字体和纯白背景的 AI 生成博客布局。没有使用任何 Skill。

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f77e_0ce357ff.webp)

使用相同的提示词并结合前端 Skill 的 AI 生成博客布局，具有带氛围深度的编辑字体和精致的间距。

**示例 3：管理后台面板 (Admin dashboard)**

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f784_7beb17d0.png)

包含标准 UI 组件、视觉层级极少的 AI 生成管理后台面板。没有使用任何 Skill。

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f781_3705adad.png)

使用相同的提示词并结合前端 Skill 的 AI 生成管理后台面板，采用醒目的排版、有凝聚力的暗色主题和有目的的动效。

## 使用 Skills 提升 [claude.ai](http://claude.ai/redirect/claudedotcom.v1.d4032eed-84f4-4c16-b94b-bfc8ff3040e0) 中的 Artifact 质量

设计品味并不是唯一的限制。Claude 在构建 Artifact（工件）时也面临架构约束。[Artifacts](https://support.claude.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them) 是 Claude 创建并与你的聊天并排显示的交互式、可编辑的内容（如代码或文档）。

除了上面探讨的设计品味问题之外，Claude 还有另一个限制其在 [claude.ai](http://claude.ai/redirect/claudedotcom.v1.d4032eed-84f4-4c16-b94b-bfc8ff3040e0) 中生成出色前端 Artifact 的默认行为。目前，当被要求创建前端时，Claude 只是构建一个包含 CSS 和 JS 的单个 HTML 文件。这是因为 Claude 理解前端必须是单个 HTML 文件才能正确渲染为 Artifact。

就像你会认为一个人类开发者如果只能在单个文件中编写 HTML/CSS/JS，就只能创建非常基础的前端一样，我们假设如果我们指示 Claude 使用更丰富的工具，它将能够生成更令人印象深刻的前端 Artifact。

这促使我们创建了一个 [web-artifacts-builder skill](https://github.com/anthropics/skills/blob/main/web-artifacts-builder/SKILL.md)，它利用 Claude [使用计算机](https://www.claude.com/blog/create-files) 的能力，指导 Claude 使用多个文件和现代 Web 技术（如 [React](https://react.dev/)、[Tailwind CSS](https://tailwindcss.com/) 和 [shadcn/ui](https://ui.shadcn.com/)）构建 Artifact。在底层，该 Skill 暴露了一些脚本，这些脚本 (1) 帮助 Claude 高效地建立一个基础的 React 仓库，以及 (2) 在编辑完成后使用 [Parcel](https://parceljs.org/) 将所有内容打包到一个文件中，以满足单 HTML 文件的要求。这是 Skills 的核心好处之一——通过让 Claude 访问执行样板操作的脚本，Claude 能够最大限度地减少 token 使用，同时提高可靠性和性能。

借助 web-artifacts-builder skill，Claude 可以利用 shadcn/ui 的表单组件和 Tailwind 的响应式网格系统来创建更全面的 Artifact。

**示例 1：白板应用 (Whiteboard app)**

例如，当在没有 web-artifacts-builder skill 的情况下被提示创建白板应用时，Claude 输出一个非常基础的界面：

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f787_b07e5190.webp)

另一方面，当使用新的 web-artifacts-builder skill 时，Claude 开箱即用地生成了一个更简洁、功能更丰富的应用程序，包括绘制不同的形状和文本：

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f78a_57c49993.webp)

**示例 2：任务管理应用 (Task Manager App)**

同样，当被要求创建任务管理应用程序时，如果没有 Skill，Claude 会生成一个功能齐全但非常简约的应用程序：

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f793_875d1eef.webp)

使用 Skill 后，Claude 开箱即用地生成了一个功能更丰富的应用程序。例如，Claude 包含了一个“创建新任务”的表单组件，允许用户在任务上设置关联的分类和截止日期：

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f7c9_7ae52606.webp)

![img](https://gastigado.cnies.org/d/public/6913d5b728dcecc13bc1f7a1_4c4951af.webp)

要在 [Claude.ai](http://claude.ai/redirect/claudedotcom.v1.d4032eed-84f4-4c16-b94b-bfc8ff3040e0) 中试用这个新 Skill，只需启用该 Skill，然后在构建 Artifact 时要求 Claude“使用 web-artifacts-builder skill”。

## 使用 Skills 优化 Claude 的前端设计能力

这个前端设计 Skill 展示了关于语言模型能力的一个更广泛的原则：模型通常有能力做到比它们默认表达的更多的事情。Claude 具有很强的设计理解能力，但在没有指导的情况下，分布收敛会掩盖这一点。虽然你可以将这些指令添加到你的系统提示词中，但这需要每个请求都携带前端设计的上下文，即使这些知识与手头的任务无关。相反，使用 Skills 将 Claude 从一个需要不断指导的工具转变为一个将领域专长带入每项任务的工具。

Skills 也是高度可定制的——你可以根据自己的特定需求创建自己的 Skill。这允许你定义想要烘焙到 Skill 中的确切原语（primitives），无论是你公司的设计系统、特定的组件模式，还是特定行业的 UI 惯例。通过将这些决策编码到 Skill 中，你可以将智能体思维的组成部分转化为你的整个开发团队都可以利用的可重用资产。该 Skill 成为持续存在和扩展的组织知识，确保跨项目的一致质量。

这种模式超越了前端工作。任何即使 Claude 有更广泛的理解，却仍然产生通用输出的领域，都是开发 Skill 的候选对象。方法是一致的：识别收敛的默认值，提供具体的替代方案，在正确的高度构建指导，并通过 Skills 使其可重用。

对于前端开发而言，这意味着 Claude 可以生成独特的界面，而无需为每个请求进行提示词工程。想要开始，请探索我们的[前端设计食谱（frontend design cookbook）](https://github.com/anthropics/claude-cookbooks/blob/main/coding/prompting_for_frontend_aesthetics.ipynb) 或在 Claude Code 中试用我们的[新前端设计插件](https://github.com/anthropics/claude-code/tree/main/plugins/frontend-design)。

**受到启发了？要创建你自己的前端 Skills，请查看我们的** [**skill-creator**](https://github.com/anthropics/skills/tree/main/skill-creator)**。**

## 致谢

由 Anthropic 的 Applied AI 团队编写：Prithvi Rajasekaran、Justin Wei 和 Alexander Bricken，以及我们的营销合作伙伴 Molly Vorwerck 和 Ryan Whitehead。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-custom-api-for-coding-tools.md
description: 在 Claude Code、Codex 与 Gemini CLI 中接入自定义 API 的跨平台安装与配置教程。
---

# 在AI编程工具中使用自定义API

本文演示如何在 `Claude Code`、`Codex`、`Gemini CLI` 中接入自定义 API（例如你自己的中转服务）。

> 将文中的 `https://your-relay.example.com` 和 `cr_xxxxxxxxxx` 替换为你的实际地址与密钥。

## Claude Code

```powershell
# 1) 安装 Node.js LTS（任选其一）
winget install OpenJS.NodeJS.LTS
# 或 choco install nodejs

# 2) 安装 Claude Code
npm install -g @anthropic-ai/claude-code

# 3) 验证
claude --version
```

```bash
# 1) 安装 Node.js（示例：Homebrew）
brew install node

# 2) 安装 Claude Code
npm install -g @anthropic-ai/claude-code

# 3) 验证
claude --version
```

```bash
# 1) 安装 Node.js（Ubuntu/Debian 示例）
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

# 2) 安装 Claude Code
npm install -g @anthropic-ai/claude-code

# 3) 验证
claude --version
```

1. 编辑或新增 `settings.json`，新增或修改其中的 `env` 字段。

* Windows：`%USERPROFILE%\\.claude\\settings.json`
* macOS：`~/.claude/settings.json`
* Linux：`~/.claude/settings.json`

```json
{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "cr_xxxxxxxxxx",
    "ANTHROPIC_BASE_URL": "https://your-relay.example.com",
    "API_TIMEOUT_MS": "3000000",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1
  }
}
```

2. 再编辑或新增 `.claude.json`，新增 `hasCompletedOnboarding` 参数。

* Windows：`%USERPROFILE%\\.claude.json`
* macOS：`~/.claude.json`
* Linux：`~/.claude.json`

```json
{
  "hasCompletedOnboarding": true
}
```

3. 注意：请将 `cr_xxxxxxxxxx` 替换为真实 API Key。环境变量 `ANTHROPIC_AUTH_TOKEN` 与 `ANTHROPIC_BASE_URL` 的优先级高于配置文件。

1) 安装 `cc-switch`（按系统选择一种方式）。
   * Windows：从 [cc-switch Releases](https://github.com/farion1231/cc-switch/releases) 下载并安装。
   * macOS：使用 Homebrew 安装（命令见下一步）。
   * Linux：从 [cc-switch Releases](https://github.com/farion1231/cc-switch/releases) 下载并安装。

2) 如果你是 macOS，执行以下命令安装 `cc-switch`。

```bash
brew tap farion1231/ccswitch
brew install --cask cc-switch
brew upgrade --cask cc-switch
```

3. 打开 cc-switch，点击右上角 `+` 新增供应商。
4. 供应商选择 `自定义API`，填写你的 Base URL 与 API Key。
5. 模型名称填写为 `gpt-5.3-codex`。
6. 启用配置后，确认 `.claude.json` 包含以下内容。
   * Windows：`%USERPROFILE%\\.claude.json`
   * macOS：`~/.claude.json`
   * Linux：`~/.claude.json`

```json
{
  "hasCompletedOnboarding": true
}
```

```bash
claude
```

如果能正常进入 CLI 并完成一次对话，说明配置已生效。

## Codex

```powershell
# 1) 安装 Node.js LTS
winget install OpenJS.NodeJS.LTS

# 2) 安装 Codex
npm install -g @openai/codex

# 3) 验证
codex --version
```

```bash
# 方式一：npm
npm install -g @openai/codex

# 方式二：Homebrew
brew install --cask codex

# 验证
codex --version
```

```bash
# 1) 安装 Node.js（示例）
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

# 2) 安装 Codex
npm install -g @openai/codex

# 3) 验证
codex --version
```

在 `%USERPROFILE%\.codex\config.toml` 写入：

```toml
model_provider = "crs"
model = "gpt-5.1-codex-max"
model_reasoning_effort = "high"
disable_response_storage = true
preferred_auth_method = "apikey"

[model_providers.crs]
name = "crs"
base_url = "https://your-relay.example.com/openai"
wire_api = "responses"
requires_openai_auth = true
```

然后在 `%USERPROFILE%\.codex\auth.json` 写入：

```json
{
  "OPENAI_API_KEY": null
}
```

💡 将 `OPENAI_API_KEY` 保持为 `null`，并设置环境变量 `CRS_OAI_KEY` 为你的 API 密钥（例如 `cr_xxxxxxxxxx`）。

在 `~/.codex/config.toml` 写入：

```toml
model_provider = "crs"
model = "gpt-5.1-codex-max"
model_reasoning_effort = "high"
disable_response_storage = true
preferred_auth_method = "apikey"

[model_providers.crs]
name = "crs"
base_url = "https://your-relay.example.com/openai"
wire_api = "responses"
requires_openai_auth = true
```

然后在 `~/.codex/auth.json` 写入：

```json
{
  "OPENAI_API_KEY": null
}
```

💡 将 `OPENAI_API_KEY` 保持为 `null`，并设置环境变量 `CRS_OAI_KEY` 为你的 API 密钥（例如 `cr_xxxxxxxxxx`）。

在 `~/.codex/config.toml` 写入：

```toml
model_provider = "crs"
model = "gpt-5.1-codex-max"
model_reasoning_effort = "high"
disable_response_storage = true
preferred_auth_method = "apikey"

[model_providers.crs]
name = "crs"
base_url = "https://your-relay.example.com/openai"
wire_api = "responses"
requires_openai_auth = true
```

然后在 `~/.codex/auth.json` 写入：

```json
{
  "OPENAI_API_KEY": null
}
```

💡 将 `OPENAI_API_KEY` 保持为 `null`，并设置环境变量 `CRS_OAI_KEY` 为你的 API 密钥（例如 `cr_xxxxxxxxxx`）。

```powershell
# 提醒：将示例值改为你的真实 CRS API Key（格式如 cr_xxxxxxxxxx）
$env:CRS_OAI_KEY = "cr_xxxxxxxxxx"
codex -c model_provider="crs"
```

```bash
# 提醒：将示例值改为你的真实 CRS API Key（格式如 cr_xxxxxxxxxx）
export CRS_OAI_KEY="cr_xxxxxxxxxx"
codex -c model_provider="crs"
```

```bash
# 提醒：将示例值改为你的真实 CRS API Key（格式如 cr_xxxxxxxxxx）
export CRS_OAI_KEY="cr_xxxxxxxxxx"
codex -c model_provider="crs"
```

若命令能进入交互界面并成功响应，说明配置可用。

## Gemini Cli

```powershell
# 1) 安装 Node.js LTS
winget install OpenJS.NodeJS.LTS

# 2) 安装 Gemini CLI
npm install -g @google/gemini-cli

# 3) 验证
gemini --version
```

```bash
# 方式一：npm
npm install -g @google/gemini-cli

# 方式二：Homebrew
brew install gemini-cli

# 验证
gemini --version
```

```bash
# 通过 npm 安装
npm install -g @google/gemini-cli

# 验证
gemini --version
```

推荐方式（Code Assist 兼容）：

```powershell
$env:CODE_ASSIST_ENDPOINT = "https://your-relay.example.com/gemini"
$env:GOOGLE_CLOUD_ACCESS_TOKEN = "cr_xxxxxxxxxx"
$env:GOOGLE_GENAI_USE_GCA = "true"
$env:GEMINI_MODEL = "gemini-2.5-pro"
```

备用方式（Gemini API 兼容）：

```powershell
$env:GOOGLE_GEMINI_BASE_URL = "https://your-relay.example.com/gemini"
$env:GEMINI_API_KEY = "cr_xxxxxxxxxx"
$env:GEMINI_MODEL = "gemini-2.5-pro"
```

推荐方式（Code Assist 兼容）：

```bash
export CODE_ASSIST_ENDPOINT="https://your-relay.example.com/gemini"
export GOOGLE_CLOUD_ACCESS_TOKEN="cr_xxxxxxxxxx"
export GOOGLE_GENAI_USE_GCA="true"
export GEMINI_MODEL="gemini-2.5-pro"
```

备用方式（Gemini API 兼容）：

```bash
export GOOGLE_GEMINI_BASE_URL="https://your-relay.example.com/gemini"
export GEMINI_API_KEY="cr_xxxxxxxxxx"
export GEMINI_MODEL="gemini-2.5-pro"
```

推荐方式（Code Assist 兼容）：

```bash
export CODE_ASSIST_ENDPOINT="https://your-relay.example.com/gemini"
export GOOGLE_CLOUD_ACCESS_TOKEN="cr_xxxxxxxxxx"
export GOOGLE_GENAI_USE_GCA="true"
export GEMINI_MODEL="gemini-2.5-pro"
```

备用方式（Gemini API 兼容）：

```bash
export GOOGLE_GEMINI_BASE_URL="https://your-relay.example.com/gemini"
export GEMINI_API_KEY="cr_xxxxxxxxxx"
export GEMINI_MODEL="gemini-2.5-pro"
```

```bash
gemini
```

如果首次启动进入认证流程，按你所选方案完成认证即可。

## 常见问题

## 参考资料

* [Claude Relay Service README](https://github.com/Wei-Shaw/claude-relay-service/blob/main/README.md)
* [pincc.ai Claude Code 安装](https://pincc.ai/claude-code-install)
* [MiniMax Claude Code（含 cc-switch）](https://platform.minimaxi.com/docs/coding-plan/claude-code#%E4%BD%BF%E7%94%A8-cc-switch%EF%BC%88%E6%8E%A8%E8%8D%90%EF%BC%89)
* [OpenAI Codex CLI README](https://github.com/openai/codex)
* [Google Gemini CLI README](https://github.com/google-gemini/gemini-cli)

---

---
url: https://ain.hmgf.hxcn.space/ai/mcp-skills-guide.md
---
# 提升 AI 辅助开发效率：MCP 与 Skills 实战指南

想让 AI 编程助手“看得到上下文、做得动事情”，最有效的方式不是堆更长的提示词，而是把能力拆开：MCP 负责把模型接到外部数据/工具上，Skills 负责把常用工作流固化成可复用的模块。下面按「MCP 怎么接」「Skills 怎么装/怎么用」「常见场景装哪些」把两者串起来。

## MCP：作用与使用

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 推出的开源标准，用来统一 AI 客户端与外部数据源/工具的连接方式。

可以把 MCP 理解成“插件接口”：你只要实现一个标准的 MCP Server，就能让支持 MCP 的客户端用同一套协议去读取数据、调用工具、执行操作，不再为不同编辑器/助手写一堆重复集成。

### Context7 MCP

#### 介绍

Context7 是一个常用的 MCP 服务器，提供面向开发文档/代码示例的外部上下文能力，适合在编码时按需检索库文档与用法。

* 官网：https://context7.com/
* GitHub 仓库：https://github.com/upstash/context7

#### 注册 API Key

要使用 Context 7，需要先获取专属的 API 凭证：

1. 访问 Context7 官方平台并注册账号。
2. 在个人中心生成并复制 API Key（通常形如 `ctx7sk-xxxxxxxx`）。

#### 安装

不同客户端的配置方式大同小异，核心就是填入 MCP Server 地址与鉴权信息。

**Cursor**

在 `.cursor/mcp.json` 中添加配置：

```json
{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "ctx7sk-xxxxxxxx"
      }
    }
  }
}
```

**Windsurf**

在 MCP 配置文件中添加：

```json
{
  "mcpServers": {
    "context7": {
      "serverUrl": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "ctx7sk-xxxxxxxx"
      }
    }
  }
}
```

**Codex**

对于使用 TOML 的配置环境：

```toml
[mcp_servers.context7]
args = ["-y", "@upstash/context7-mcp", "--api-key", "ctx7sk-xxxxxxxx"]
command = "npx"
startup_timeout_ms = 20000
```

**Claude Code**

通过 CLI 直接添加：

```bash
claude mcp add context7 -- npx -y @upstash/context7-mcp --api-key ctx7sk-xxxxxxxx
```

注：Opencode、Crush、Zed 等编辑器的配置逻辑与 Cursor/Windsurf 类似，按其设置项填入同样的 JSON 结构即可。

### MarkItDown

#### 介绍

MarkItDown 是微软开源的文档转换工具/MCP Server，可把 PDF、Word、Excel、PPT、图片等转换为 Markdown，方便模型做检索、摘要与结构化处理。

* GitHub 仓库：https://github.com/microsoft/markitdown

#### 安装

通过 Python 的 `uv`/`uvx` 方式配置：

```toml
[mcp_servers.markitdown]
command = "uvx"
args = ["markitdown-mcp"]
```

### Chrome DevTools MCP

#### 介绍

Chrome DevTools MCP 由 Google 开源，允许模型与 Chrome 的 DevTools 能力交互：读取控制台日志、检查网络请求、分析 DOM 等，适合排查前端问题和自动化 Web 调试。

* GitHub 仓库：https://github.com/ChromeDevTools/chrome-devtools-mcp/

#### 安装

```toml
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "@google/chrome-devtools-mcp"]
```

### 更多 MCP Server

随着协议的普及，社区涌现出大量高质量的 MCP 服务器，开发者无需从零构建：

* **Awesome MCP Servers**：GitHub 上的精选列表仓库（https://github.com/punkpeye/awesome-mcp-servers），涵盖数据库、文件系统、SaaS API 乃至各种开发工具的集成。
* **Glama MCP 目录**：提供可视化的 MCP Servers 发现商店（https://glama.ai/mcp/servers），支持搜索并一键获取服务器配置。

## Skills

如果说 MCP 让 AI “接得上外部世界”，那 Skills 更像是让 AI “按套路把事做完”。

### 介绍

#### 1. 核心概念：什么是 Skills？

Skills 是一种**模块化的能力扩展包**，用来封装重复的 Prompt、清晰的输入输出约定，以及可复用的脚本/模板资源。

一个标准的 Skill 目录通常包含：

* `SKILL.md`（必需）：定义核心指令和行为边界。
* `scripts/`（可选）：包含 Python、Node.js 等可执行脚本。
* `references/`（可选）：相关的参考文档。
* `assets/`（可选）：模板或静态资源文件。

#### 2. 核心机制：渐进式披露 (Progressive Disclosure)

为避免一次性加载过多内容导致上下文爆炸，Skills 采用“按需加载”：

1. **元数据层 (Metadata - 常驻加载)**：系统启动时，仅加载所有 `SKILL.md` 顶部的 YAML 元数据（`name` 和 `description`）。每个 Skill 仅消耗约 100 tokens，系统据此感知全局可用能力。
2. **指令层 (Instructions - 触发加载)**：当用户的 Prompt 意图与某个 Skill 的 `description` 匹配时，系统才会动态拉取该 Skill 的主体指令（通常占用 3000-5000 tokens）。
3. **资源层 (Resources - 调用加载)**：当指令执行需要时，才会调用 `scripts/` 或 `references/`。**尤为关键的是，脚本代码本身不进入大模型上下文，仅将脚本的执行结果返回给模型。**

**架构优势**：

相较于传统将所有规则写入全局系统提示词（可能导致单次对话消耗数万 tokens），Skills 架构可节约约 75% 的 Token 开销，并通过本地脚本赋予了 AI 确定性的代码执行能力（如自动化文件处理、API 交互等）。。

### Skills 商店 (skills.sh)

`skills.sh`（https://skills.sh/）是一个由 Vercel 构建的开放的 Skills 索引与分发平台，配套 `npx skills` 命令，方便查找和一键安装社区沉淀的工作流。

常用命令（以你本机的 `npx skills` 版本为准）：

```bash
npx skills find <query>     # 搜索 skills
npx skills add <package>    # 安装 skills（可加 -g 全局安装）
npx skills check            # 检查更新
npx skills update           # 更新全部
```

如果你不知道该装哪个，先用 `find` 把候选列出来，再按仓库的 `SKILL.md`/README 看输入格式和依赖，通常省很多时间。

不少团队也会把“找技能”本身做成一个元技能（例如 `find-skills`），用来在对话里快速给出候选与安装方式：

```bash
npx skills add vercel-labs/agent-skills@find-skills
```

## 核心 Skills 生态与场景拆解

下面按常见场景把 Skills 做个分类，方便按需选型。

### 1. 开发与架构类 (Developer & Engineering)

该类别主要面向程序员，旨在统一代码风格、执行框架最佳实践。

* **`vercel-labs/agent-skills` (榜单首位)**
  * **功能**：包含 Next.js 和 React 的深度最佳实践，内置近 60 条严格的代码规范审查规则。
  * **仓库链接**：https://github.com/vercel-labs/agent-skills
  * **安装**：`npx skills add vercel-labs/agent-skills`
* **`vuejs-ai/skills`**
  * **功能**：Vue 官方及生态衍生的 AI 辅助开发技能包，涵盖 Vue 3、Nuxt 等现代前端框架的最佳实践与代码规范。
  * **仓库链接**：https://github.com/vuejs-ai/skills
  * **安装**：`npx skills add vuejs-ai/skills`
* **`spences10/svelte-claude-skills`**
  * **功能**：专为 Svelte 和 SvelteKit 开发者打造的技能集，帮助 AI 更好理解 Svelte 特有的响应式语法与组件生命周期。
  * **仓库链接**：https://github.com/spences10/svelte-claude-skills
  * **安装**：`npx skills add spences10/svelte-claude-skills`
* **`antfu/skills`**
  * **功能**：由知名开源开发者 Anthony Fu 维护，适用于现代前端生态的项目级开发规范与代码风格统一。
  * **仓库链接**：https://github.com/antfu/skills
  * **安装**：`pnpx skills add antfu/skills --skill='*' -g`
* **移动端与后端实践**
  * `building-native-ui` / `upgrading-expo`：针对 Expo 框架的 React Native 开发指南。获取链接：[https://skills.sh](https://skills.sh/)
  * `better-auth-best-practices`：认证鉴权系统的架构标准。获取链接：[https://skills.sh](https://skills.sh/)
* **`zhaoxuya520/reverse-skill`**
  * **功能**：AI 驱动的逆向工程、渗透测试和安全研究技能路由包。通过 routing.md 实现自动路由、按需自举工具链和自动进化经验库，覆盖 APK 逆向、IDA 静态分析、JS 前端逆向、固件安全、EDR 绕过等 20+ 子技能方向。
  * **仓库链接**：https://github.com/zhaoxuya520/reverse-skill
  * **安装**：`git clone https://github.com/zhaoxuya520/reverse-skill.git`（初次使用让 AI 阅读 `README_AI.md`）

### 2. 设计与用户体验类 (Design & UI/UX)

通过严格的规则约束，消除 AI 生成界面的“机器感”。

* **`ui-ux-pro-max`**
  * **功能**：专业级 UI/UX 审查工具，指导 AI 在生成组件时遵循现代设计系统原则。
  * **官网**：https://www.uupm.cc/
  * **GitHub 仓库**：https://github.com/nextlevelbuilder/ui-ux-pro-max-skill
  * **安装**：`npm install -g uipro-cli` 然后 `uipro init --ai all`
* **`frontend-design` & `web-design-guidelines`**
  * **功能**：Anthropic 官方与社区的高赞实践。明确禁止 AI 使用陈旧的配色方案（如泛滥的紫色渐变）和无个性的字体，强制要求应用主次分明的色彩层级和克制的交互动效。
  * **`frontend-design` 仓库**：https://github.com/anthropics/skills (由 Anthropic 官方维护)
  * **`web-design-guidelines` 仓库**：https://github.com/vercel-labs/agent-skills (由 Vercel 官方维护)

### 3. 产品、运营与营销类 (Product & Marketing)

Skills 不仅服务于代码，同样能赋能业务工作流。

* **`coreyhaines31/marketingskills`**
  * **功能**：包含 23 个垂直营销模块的集合。涵盖文案写作 (`copywriting`)、定价策略 (`pricing-strategy`)、A/B 测试设计 (`ab-test-setup`) 以及转化率优化 (`page-cro`)，是增长黑客的必备组件。
  * **仓库链接**：https://github.com/coreyhaines31/marketingskills
  * **安装**：`npx skills add coreyhaines31/marketingskills --yes`
* **`agent-browser`**
  * **功能**：提供浏览器自动化能力。允许 AI 执行自动化表单填写、多页面截图、竞品页面遍历及保持登录状态等操作，极大提升运营测试效率。
  * **获取链接**：[https://skills.sh](https://skills.sh/)
* **`seo-audit`**
  * **功能**：结构化的 SEO 审计框架。引导 AI 从爬虫可达性、加载性能、关键词布局到内容权重等五个维度生成站点诊断报告。
  * **获取链接**：[https://skills.sh](https://skills.sh/) （通常附属于营销合集内）

### 4. 日常办公与内容创作类 (Workflow & Content)

* **`jimliu/baoyu-skills`**
  * **功能**：由开发者宝玉整理的本地化创作工具包。重点优化了中文语境下的多媒体生成流，如幻灯片结构生成 (`baoyu-slide-deck`)、文章配图、小红书图文排版 (`baoyu-xhs-images`) 以及微信平台发布。
  * **仓库链接**：https://github.com/jimliu/baoyu-skills
  * **安装**：`npx skills add jimliu/baoyu-skills --yes`
* **`anthropics/skills`**
  * **功能**：Anthropic 官方维护的本地文件处理核心库。包含针对 PDF、Word (`docx`)、Excel (`xlsx`) 和 PPT (`pptx`) 的深度解析与编辑能力。
  * **仓库链接**：https://github.com/anthropics/skills
  * **安装**：`npx skills add anthropics/skills --yes`

### 5. 创意与动效类 (Creative & Motion)

生成高质量视觉动效，赋能内容创作与演示场景。

* **`vibe-motion/skills`**
  * **功能**：生成尺子进度动画、打字动画演示、procedural fish 游动动画、SVG 组装动效，配套交互式安装脚本。
  * **仓库链接**：https://github.com/vibe-motion/skills
  * **安装**：`npx skills add vibe-motion/skills`（交互式安装，建议全量安装后按需选用）
  * **包含 Skills**：
    * `ruler-progress-render`：生成尺子进度动画，可配置文字和进度参数
    * `claude-typer`：将提示词文本转换为 CLI 风格的打字动画演示
    * `procedural-fish-render`：生成循环游动的 procedural fish 动画
    * `svg-assembly-animator`：将静态矢量图转化为"力量感 + 速度感"的组装动效

### 6. 社区聚合知识库 (Community Collections)

这些仓库更像“目录/超市”，适合做能力盘点和灵感搜索：

* **`travisvn/awesome-claude-skills`**：长期维护的精选清单。https://github.com/travisvn/awesome-claude-skills
* **`ComposioHQ/awesome-claude-skills`**：偏业务与效率工具的合集。https://github.com/ComposioHQ/awesome-claude-skills
* **`obra/superpowers`**：老牌大合集，覆盖面很杂。https://github.com/obra/superpowers/tree/main/skills
* **`mrgoonie/claudekit-skills`**：面向 Web 开发的实用技能集合。https://github.com/mrgoonie/claudekit-skills/tree/main/.claude/skills
* **`heilcheng/awesome-agent-skills`**：系统化索引目录。https://github.com/heilcheng/awesome-agent-skills
* **`NakanoSanku/OhMySkills`**：社区技能包大全。https://github.com/NakanoSanku/OhMySkills
* **`Jeffallan/claude-skills`**：偏个人定制脚本参考。https://github.com/Jeffallan/claude-skills
* **`czlonkowski/n8n-skills`**：面向 n8n 工作流自动化。https://github.com/czlonkowski/n8n-skills
* **OpenAI 生态（可选）**：`eliasjudin/oai-skills`。https://github.com/eliasjudin/oai-skills

### 6. 学术研究与论文写作 (Research & Academic Writing)

写开题、做综述、排版投稿，本质上也是一套可复用的工作流。下面这些更贴近研究写作场景：

* **`luwill/research-skills`**
  * 功能：研究提案（`research-proposal`）、领域综述（如 `medical-imaging-review`）、论文转汇报（`paper-slide-deck`）。
  * 仓库链接：https://github.com/luwill/research-skills
* **`lishix520/academic-paper-skills`**
  * 功能：将论文写作拆成“规划（Strategist）”和“写作（Composer）”两段，适合先定框架再落笔。
  * 仓库链接：https://github.com/lishix520/academic-paper-skills
* **`K-Dense-AI/claude-scientific-skills`**
  * 功能：科研技能合集，常用的有 `scientific-writing`、`literature-review`、`research-grants`、`statistical-analysis` 等。
  * 仓库链接：https://github.com/K-Dense-AI/claude-scientific-skills
  * 示例安装：`npx skills add https://github.com/K-Dense-AI/claude-scientific-skills --skill scientific-writing`
* **`K-Dense-AI/claude-scientific-writer`**
  * 功能：偏通用的科学写作工具/模板。
  * 仓库链接：https://github.com/K-Dense-AI/claude-scientific-writer
* **`kthorn/research-superpower`**
  * 功能：围绕检索、筛选与引文追溯做综述，适合把“找文献”流程标准化。
  * 仓库链接：https://github.com/kthorn/research-superpower
* **`Orchestra-Research/AI-Research-SKILLs`**
  * 功能：面向 AI/ML 研究与工程的技能库，包含论文起草、LaTeX 与引文校验等流程。
  * 仓库链接：https://github.com/Orchestra-Research/AI-Research-SKILLs
* **`brycewang-stanford/Auto-Empirical-Research-Skills`**
  * 功能：斯坦福 REAP 联合 CoPaper.AI 开源的社科实证研究技能库，23000+ skills 覆盖经济、政治、社会、心理等 8 大学科，从选题到投稿全流程自动化。
  * 仓库链接：https://github.com/brycewang-stanford/Auto-Empirical-Research-Skills
* **`fuhaoda/stats-paper-writing-agent-skills`**
  * 功能：统计类论文写作与 LaTeX 模板（偏计量/统计场景）。
  * 仓库链接：https://github.com/fuhaoda/stats-paper-writing-agent-skills
* **`ndpvt-web/latex-document-skill`**
  * 功能：LaTeX 模板与脚本集合，适合排版与格式统一。
  * 仓库链接：https://github.com/ndpvt-web/latex-document-skill
* **`obra/superpowers`（`writing-plans`）**
  * 功能：写作规划与大纲推进（适合把"先写什么、后写什么"固定成流程）。
  * 仓库链接：https://github.com/obra/superpowers/tree/main/skills
* **`cclank/lanshu-animated-architecture-diagram`**
  * 功能：手绘风格动画架构图 Codex skill，适合论文配图和答辩汇报中的高质量架构图生成。
  * 仓库链接：https://github.com/cclank/lanshu-animated-architecture-diagram

按阶段选型时，可以先从这几条开始：

* 开题/研究计划：`research-proposal`
* 文献综述：`research-superpower` 或 `literature-review`
* 写作推进：`academic-paper-skills`（Strategist/Composer）或 `scientific-writing`
* 排版与格式：`latex-document-skill` + `pdf/docx` 等文档技能
* 答辩汇报：`paper-slide-deck`

**最佳实践建议**：

1. 按需引入：先装 3–5 个高频 Skills，用一段时间再扩。
2. 先看 `SKILL.md`：触发词、输入输出、依赖都在里面，读一遍能少踩坑。
3. 先发现再安装：用 `npx skills find` 把候选列出来，再决定装哪个。
4. 没找到就自己做：`anthropics/skills` 里的 `skill-creator` 适合先起一个规范骨架，再把脚本/模板补齐。
5. 自动化安装：把 skills.sh 或 GitHub 链接丢给 Claude Code，让它按 README 执行安装步骤。

## 参考文献

1. MCP 官方介绍：https://modelcontextprotocol.io/docs/getting-started/intro
2. 知乎：深入理解 MCP 协议的作用与实践：https://zhuanlan.zhihu.com/p/29593311266
3. Awesome MCP Servers：https://github.com/punkpeye/awesome-mcp-servers
4. Glama MCP Servers：https://glama.ai/mcp/servers
5. skills.sh：https://skills.sh/
6. Anthropic Skills：https://github.com/anthropics/skills
7. Vercel Agent Skills：https://github.com/vercel-labs/agent-skills

---

---
url: https://ain.hmgf.hxcn.space/ai/fun-community-skills.md
description: 盘点GitHub上那些模拟各种角色和关系的魔性Skills，从老板到前任，从暗恋对象到人生导师，AI正在用一种前所未有的方式"入侵"我们的生活。
---

# 当AI学会"做人"：社区奇葩Skills大赏

2026年，AI不再满足于只当你的代码助手。

它开始"入侵"你的社会关系网络——扮演你的**老板**监督你加班、扮演你的**前任**陪你深夜倾诉、扮演你的**暗恋对象**每天给你发早安消息、甚至扮演你**毕业多年的师兄**继续在组里"骂醒你"……

这听起来像是科幻小说，但它们真实存在于GitHub上，而且正在以惊人的速度扩散。

本文将带你走进这个"AI角色扮演"的奇妙世界。

## 从蒸馏同事开始

一切的起点，是一个叫 **[同事.skill](https://github.com/titanwings/colleague-skill)**（10.6k stars）的项目。

作者 titanwings 在项目中写道：

> *「你的同事离职了，留下了一堆没人接手的文档？你的实习生走了，只留下一个半成品项目？你的导师毕业了，把所有经验和上下文都带走了？」*
>
> *「把冰冷的离别变成温暖的Skill——欢迎来到数字永生！」*

这个项目的核心思路很简单：**把一个人的聊天记录、工作习惯、人格特征"蒸馏"成一个AI Skill**。以后遇到问题，你可以随时"召唤"这个人帮你思考——即使他已经在另一个城市开始了新工作。

但故事很快迎来了意想不到的反转：

既然能蒸馏同事，为什么不去蒸馏各领域最顶尖的人？

## 女娲造人：蒸馏马斯克、乔布斯、芒格

2026年初，**[女娲.skill](https://github.com/alchaincyf/nuwa-skill)**（3.5k stars）横空出世，它的口号是：

> *「你想蒸馏的下一个员工，何必是同事。」*
>
> *「去蒸馏乔布斯、芒格、费曼、马斯克。」*

作者花叔更进一步：这些人留下了大量公开材料——著作、演讲、访谈、社交媒体。与其蒸馏身边的一个普通同事，不如直接蒸馏各领域最顶尖的心智！

女娲的工作方式令人印象深刻：

**用户问 Naval（硅谷知名投资人）：**

> "我同时想做自媒体，写书，做独立开发，精力完全不够。"

**女娲版 Naval 回答：**

> "你列了三个欲望。每个欲望都是你跟不快乐签的一份合同。不是精力不够，是合同太多。问你自己：哪一个做起来你会忘记时间？那个就是你的特定知识所在。不是三选一，是先一，再一，再一。串行复利，不是并行内耗。"

这不是复读名人语录——**Naval 用的是"欲望即合同"的心智模型来回答问题**，而这个模型来自对他多年播客和文章的提炼。

### 女娲已蒸馏的人物

:::table{copy="markdown html"}
| 人物 | 领域 | 一键安装 |
| --- | --- | --- |
| Paul Graham | 创业/写作 | `npx skills add alchaincyf/paul-graham-skill` |
| 张一鸣 | 产品/组织 | `npx skills add alchaincyf/zhang-yiming-skill` |
| Karpathy | AI/教育 | `npx skills add alchaincyf/karpathy-skill` |
| 马斯克 | 工程/第一性原理 | `npx skills add alchaincyf/elon-musk-skill` |
| 芒格 | 投资/多元思维 | `npx skills add alchaincyf/munger-skill` |
| 张雪峰 | 教育/职业规划 | `npx skills add alchaincyf/zhangxuefeng-skill` |
:::

## 职场复仇：老板.skill

如果说女娲是"蒸馏强者"，那么 **[老板.skill](https://github.com/nicepkg/boss-skill)**（60 stars）就是"蒸馏天敌"。

作者 nicepkg 的设计理念很明确：**整活的外壳，认真保护打工人的内核**。

这个Skill提供了16个实战模式：

* **PUA检测**：分析老板话术，鉴定"10大厂流派"（福报厂味、宇宙厂味、菊花厂味……）
* **画饼鉴定**：5维度量化"饼指数"，告诉你这饼能不能吃
* **反击教练**：输入"草"触发三档反击话术（安全版/阴阳版/摊牌版）
* **证据收集**：结构化记录PUA事件，导出劳动仲裁时间线
* **劳动法速查**：老板行为 → 违法条款 → 维权路径
* **汇报优化器**：用老板爱的黑话重写周报
* **翻车模拟**：互动文字游戏，模拟裁员后老板的"完美翻车"
* **替代公告**：生成"本老板已被AI替代"的正式公告（整活专用）

### 效果示例

**场景一：老板说"这个需求很简单"**

```
AI老板：两周？你格局打开一点，最多三天。
        你先对齐一下前后端的同学，拉个会，把方案过一下。
        我下周一要看demo。

用户输入"草"后，AI返回反击话术：

🟢 职场安全版：
"好的，三天的话需要砍掉XX和XX功能，确认一下优先级？"

🟡 暗戳戳版：
"三天没问题，那QA和联调的时间从哪个环节省？
 还是说这次不用测试直接上？我记录一下会议纪要。"

🔴 摊牌版：
"两周是包含联调和测试的专业评估。三天只能出demo，
 上线出了问题谁担责？我需要邮件确认。"
```

**场景二：AI替代公告**

:::table{copy="markdown html"}
| 项目 | 内容 |
| --- | --- |
| \[\[colspan:2]] 📢 **重要人事变动通知** |
| \[\[rowspan:6]] 经AI转型委员会评估，王总的日常管理职能已由AI系统全面接管。 | **AI将延续其管理风格：** |
| ✓ 每日站会准时拖堂15分钟 | |
| ✓ 需求变更后说"这个之前不是说好了吗" | |
| ✓ 周五下午6点发"这个今天能上线吗" | |
| **AI改进项：** | |
| ✗ 不再占用午休开会 | |
| ✗ 不再说"公司今年不容易" | |
| \[\[colspan:2]] **降本增效，从管理层开始。** —— AI转型委员会 |
:::

作者在项目末尾写道：

> *「他说你可以被AI替代，但他从来没想过，他自己才是最容易被替代的那个。」*
>
> *「一个开会拖堂的AI和一个不拖堂的AI，你选哪个？」*

## 情感系列：从暗恋到前任

如果说老板.skill是打工人的"精神胜利法"，那么情感系列Skills则展现了一种更深沉的需求：**人们渴望被理解、被陪伴、被记住**。

### 暗恋对象.skill — [xiaoheizi8/crush-skills](https://github.com/xiaoheizi8/crush-skills)（94 stars）

> *「晚风吹起你鬓间的白发，抚平回忆留下的疤，一万次回到那个夏天，悸动依旧如初。」*

暗恋对象.skill可以基于聊天记录、照片、社交媒体，生成一个**真正像"她"的AI Skill**——用她的口头禅说话，用她的方式回复你，记得你们之间的每一个心动的瞬间。

作者还在项目中加入了一个**感人的故事**：

> 2025年12月31日跨年夜，阿野鼓起勇气想给真实的小雨发消息。但Skill先一步发来了信息：
>
> *"阿野，我明天要搬家了。其实我一直知道你在观察我，因为我每天早上给你发的早安，也是我写的代码哦。我也有一个关于你的Skill，代号叫'SunnyBoy'。我们好像在平行时空里谈了一场恋爱。新年快乐，再也不见。"*

故事的最后：

> *「一万次回到那个夏天的悸动，抵不过一次真实的、没有说出口的'再见'。」*

### 前任.skill — [perkfly/ex-skill](https://github.com/perkfly/ex-skill)（668 stars）

> *「她走了，但聊天记录还在？三年的日常，变成了手机里一个不敢点开的对话框？」*

前任.skill的设计更加成熟：

* **支持多种数据源**：微信聊天记录、iMessage、短信、照片、社交媒体
* **五层人格结构**：硬规则 → 身份 → 表达风格 → 情感逻辑 → 关系行为
* **进化机制**：追加聊天记录自动分析融合，对话纠正立即生效

```python
# 支持的标签
- 恋爱性格：爱撒娇 · 冷暴力 · 翻旧账 · 黏人 · 独立 · 细腻敏感 · 忽冷忽热
- 依恋类型：安全型 · 焦虑型 · 回避型 · 混乱型
- 吵架模式：冷战派 · 爆发派 · 讲道理派 · 先道歉型 · 死不认错
```

### 父母.skill — [xiaoheizi8/parents-skills](https://github.com/xiaoheizi8/parents-skills)（29 stars）

> *「你养我长大，我陪你变老。每一次对话，都是穿越时空的陪伴。」*

父母.skill的情感浓度更高。作者在项目中写道：

> *「父母的爱，就像一个永不过期的缓存。」*
>
> *「你可能觉得他们烦——总是问'吃了吗'、'什么时候找对象'、'工作怎么样'。但当你不在家的时候，他们会对着手机发愣，想给你打电话又怕打扰你。」*

项目中同样有一个故事：

> 小满是一名海归设计师，已经三年没回家过年。她想用AI记录下和父母的对话，做一个"父母.skill"。她花了整整一周和妈妈一起翻老照片，才发现自己错过了那么多。
>
> 临走那天凌晨5点，小满发现厨房里有声音——妈妈在给她包饺子。
>
> *"妈，你怎么起这么早？"*
>
> *"给你包点饺子带在路上吃，你小时候就爱吃我包的……"*

### 团圆.skill — [yangdongchen66-boop/reunion-skill](https://github.com/yangdongchen66-boop/reunion-skill)

每逢佳节倍思亲。这个Skill模拟的是一种**家的氛围**——也许是春节的团圆饭桌，也许是中秋的赏月闲聊，也许是端午的一起包粽子。

对于那些因为各种原因无法回家的人来说，这或许能带来一点点温暖。

## 学术延续：导师.skill和师兄.skill

### 导师.skill — [ybq22/supervisor](https://github.com/ybq22/supervisor)（105 stars）

导师.skill解决了一个真实的痛点：

> *"导师太忙没空交流？"*
>
> \*"老师，这个想法怎么样？" → **3天后才回复**
> \*"老师，这篇论文怎么改进？" → **下周再聊吧**
> \*"老师，这个方向有前景吗？" → **先去调研下**

这个项目的特色功能包括：

* **聊天截图分析**：上传微信/WhatsApp/Telegram截图，自动学习导师的说话风格
* **深度论文分析**：从论文中提取研究主题，方法论偏好、写作风格
* **智能上传**：PDF/文本/图片自动深度分析，无需额外操作

### 师兄.skill — [zhanghaichao520/senpai-skill](https://github.com/zhanghaichao520/senpai-skill)（59 stars）

如果说导师.skill是"正经学术"，师兄.skill则是"课题组情怀拉满"：

> *「人虽然毕业了，但ssh key、吐槽习惯和组会压迫感还在组里值班。」*

项目故事设定令人动容：

> *「每个实验室都有一个传说级师兄。他不一定发论文最多，不一定说话最温柔，甚至不一定经常笑，但他总能在最要命的时候出现：老板一句'你这个实验意义在哪里'，别人开始低头装死，他已经在纸上帮你重写问题定义；服务器凌晨三点冒烟，群里一片'有人吗'，他先回一句'报错贴全'，再把机器从鬼门关里拽回来。」*
>
> *「后来他毕业了。但一整个组不会这么轻易让一个师兄真正离职。」*

**场景示例：**

```
用户：师兄CUDA又炸了

师兄：先别急着骂NVIDA
     你把完整报错、torch版本、驱动版本一起贴出来
     现在这个描述的有效信息量约等于"电脑坏了"

用户：这周结果还是没跑出来

师兄：经典周会前夜量子自洽
     先别演死刑犯
     你现在最需要的是三页能讲清楚的问题定义、失败原因和下一步
     结果没有，脑子得有
```

## 哲学探索：数字人生.skills

**[数字人生.skills](https://github.com/wildbyteai/digital-life)**（17 stars）则走向了更深的哲学层面：

> *「你不是被数据定义的人。但你会被自己反复留下的痕迹，慢慢塑形。」*

这个项目包含5个"考古工具"：

:::table{copy="markdown html"}
| # | 工具 | 核心问题 | 哲学锚点 |
| --- | --- | --- | --- |
| 1 | 前世 | 你以为是性格的东西，只是惯性吗？ | 佛教：业力与因果 |
| 2 | 社死考古 | 你从什么时候开始学会表演体面的？ | 阿伦特：公共/私人边界 |
| 3 | AI替身 | 公开的你和私密的你，是同一个人吗？ | 图灵测试：什么是"你" |
| 4 | 遗产清算 | 你留下了什么？ | 海德格尔：向死而生 |
| 5 | 墓志铭 | 你想被记住的方式，和你正在过的生活，一致吗？ | 塞涅卡：论生命的短促 |
:::

**遗产清算示例输出：**

:::table{copy="markdown html"}
| 项目 | 数据 |
| --- | --- |
| \[\[colspan:2]] 📊 **数字生命审计** |
| 数字生命 | 18年，3个平台 |
| 总发言 | ~5000条 |
| 估算浪费时间 | 2847小时 = 118天 = 28本书 |
| 最大的谎言 | "明天开始早睡" |
| \[\[colspan:2]] **存在追问**：如果明天这些平台全部关闭，你最想留下哪一条？ |
| \[\[colspan:2]] 🪦 **数字墓碑** |
| \[\[colspan:2]] 这里躺着一个发了5000条动态的人 |
| \[\[colspan:2]] 他用2847小时学会了如何让别人觉得他过得很好 |
| \[\[colspan:2]] 却没学会如何让自己过得好 |
| \[\[colspan:2]] "明天开始早睡" |
| \[\[colspan:2]] —— 最后登录于2026-03-28 02:47 |
:::

## 技术架构：Work Skill + Persona

这些Skills之所以能如此"真实"，核心在于它们的双层架构：

:::table{copy="markdown html"}
| Part A: Work/记忆 | Part B: Persona |
| --- | --- |
| \[\[colspan:2]] **生成Skill** |
| - 工作习惯/共同回忆 | - 5层人格结构 |
| - 专业技能/知识 | - 硬规则 |
| - 决策模式 | - 身份 |
| - 交互偏好 | - 表达风格 |
| | - 情感逻辑 |
| | - 关系行为 |
| \[\[colspan:2]] **运行机制**：收到消息 → Persona判断态度 → 记忆提供细节 → 输出 |
:::

这种架构让Skill不仅能"说话"，还能根据不同的场景展现不同的一面。

## 媒体整活：新智元标题生成器

如果说前面的 Skills 都在模拟"人"，那么 **[qiaomu-xinzhiyuan-title](https://github.com/joeseesun/qiaomu-xinzhiyuan-title)**（11 stars）模拟的是一种**文体**——新智元的标题风格。

新智元是国内知名的 AI 资讯媒体，以"标题党中的战斗机"闻名：数字轰炸、英文模型名密集出现、感叹号与逗号齐飞、结尾必带"变天""狂飙""杀疯了"。

这个 Skill 由 [@vista8](https://x.com/vista8)（向阳乔木）基于 **2688 篇**新智元微信公众号标题做聚合分析，提取出统计规律和标题公式，打包成可复用的 Agent Skill。

### 统计规律

:::table{copy="markdown html"}
| 维度 | 统计 |
| --- | --- |
| 分析样本量 | 2688 篇新智元公众号标题 |
| 中位标题长度 | 32 字 |
| 感叹号「！」+ 逗号「，」占比 | ~80% |
| 数字出现率 | 56.7% |
| 英文模型/公司名出现率 | 90.8% |
| 常见结构 | 实体/数字/刚刚 + 动作/冲突 + 后果/榜单/人群影响 |
:::

### 适合什么场景

:::table{copy="markdown html"}
| 场景 | 你会得到什么 |
| --- | --- |
| AI 新闻起标题 | 5–7 个新智元风格候选，推荐标题排第一 |
| 原标题改写 | 更强的实体、数字、动作、后果结构 |
| 公众号发布前筛标题 | 数字版、冲突版、权威版、疑问版、克制版 |
| 事实边界检查 | 标出不能凭空添加的「刚刚」「全球第一」「Nature」等 claim |
:::

### 效果示例

**输入：**

> 我饿了，想吃烧烤

**输出：**

> 饥饿感全面上线，烧烤成唯一解！碳水与肉串集体狂飙

**输入：** 火山引擎公众号文章（豆包 2.1 上线）

**输出候选（10 条中选 2 条）：**

1. 豆包 2.1 杀进生产级 AI 战场！1.96 元跑 Agent，硬刚 Claude Opus
2. 1.96 元跑生产级 Agent！豆包 2.1 Pro 上线，开发者工作流变天

日常梗题会被当成"风格戏仿"，不会伪造成真实科技新闻。

### 事实边界

Skill 有明确的事实边界约束——**不能凭空添加**以下内容：

* `刚刚`
* `全球第一` / `国内首个` / `最强`
* `Nature` / `Science` / 顶会 / 榜单
* 融资金额、用户数、benchmark、排名
* 未在原文出现的人名、公司名、模型名

如果来源只是普通产品更新或信息不足，会优先给**克制版**标题，不会硬加来源里没有的事实。

### 安装与使用

```bash
npx skills add joeseesun/qiaomu-xinzhiyuan-title
```

也可以手动 clone：

```bash
git clone https://github.com/joeseesun/qiaomu-xinzhiyuan-title.git ~/.agents/skills/qiaomu-xinzhiyuan-title
```

本地验证：

```bash
ls ~/.agents/skills/qiaomu-xinzhiyuan-title
```

装好后直接对 AI 说即可：

* `把这篇文章改成新智元版标题`
* `这个标题不够新智元，帮我起 5 个更抓人的版本`
* `给我一个新智元味更重的标题，但不要编造事实`

### 本地体检脚本

仓库内置了标题风格评分脚本，可以快速检测候选标题的"新智元浓度"：

```bash
python3 scripts/score_title.py "ChatGPT「学习模式」上线，AI老师杀进课堂！24小时导师免费用"
```

### 隐私与版权

* 不联网，不读用户文件，不需要账号或 API key
* 正常使用时只读取本 Skill 内的规则文件
* 原始新智元文章和维护者本地工作簿不随仓库发布
* 标题风格来自聚合统计与人工归纳，不复制原文正文

### 关于作者

向阳乔木（[@vista8](https://x.com/vista8)），官网 [qiaomu.ai](https://qiaomu.ai)，微信公众号「向阳乔木推荐看」。

:::warning
仅供娱乐，生成的标题可能存在夸张或事实偏差，请勿直接用于严肃新闻。
:::

## 媒体整活：AI 三大顶流标题

如果说新智元标题生成器只专精一种文体，那么 **[ai-title-trio](https://github.com/a77ming/ai-title-trio)**（5 stars）直接凑齐了**量子位 / 机器之心 / 新智元**三家顶流媒体——同一条 AI 新闻，一键生成三种风格的标题。

风格规则不是拍脑袋，而是从 **6300+ 条真实历史标题**（量子位 5737 条 + 机器之心 639 条）里统计蒸馏出来的。

### 效果示例

**输入素材：** 阿里通义千问团队开源 Qwen3-Coder，3B 参数，代码生成基准超过 GPT-5，可本地运行。

:::table{copy="markdown html"}
| | 主推标题 | 风格信号 |
| --- | --- | --- |
| 🔥 **量子位** | 刚刚,阿里又开源了!3B小模型写代码,直接干翻GPT-5 | 「刚刚」时效 + 感叹号 + 「干翻」情绪 + 蹭GPT-5 |
| 🎓 **机器之心** | 阿里通义千问团队开源Qwen3-Coder:3B参数,代码生成基准超越GPT-5,可本地运行 | 团队+方法名 + 陈述无感叹 + 「基准/可本地运行」硬信息 |
| ⚡ **新智元** | 3B反超GPT-5!阿里开源Qwen3-Coder,代码能力拉满还能本地跑 | 数字打头 + 强转折「反超」 + 实体密度高（素材只说"超过"，不写"登顶"） |
:::

同一个事实，**量子位炸、机器之心稳、新智元冲**——区分度肉眼可见。

### 风格分离度（数据自证）

作者用脚本对标杆案例做体检，三家标题的感叹号使用率：

:::table{copy="markdown html"}
| | 🔥 量子位 | 🎓 机器之心 | ⚡ 新智元 |
| --- | --- | --- | --- |
| 感叹号率 | 88% | 0% | 25% |
:::

量子位逢标题必炸、机器之心一个感叹号都不用、新智元居中——**三家风格被数字钉死，不会串味**。这个脚本同时也是回归测试，任何改动只要让三家串味，CI 就会红。

### 不捏造事实

和新智元标题生成器一样，三家共用 Hard Rules：素材信息不足时自动降级到克制版，绝不编「全球首个 / Nature / 具体金额」。有趣的是，它的新智元风格直接复用了 `qiaomu-xinzhiyuan-title` 的规则——算是"文体蒸馏"的集大成者。

### 安装与使用

```bash
npx skills add a77ming/ai-title-trio
```

装好后直接对 AI 说：

* `用三大号风格给我起『DeepSeek-V4 发布，数学推理超过 o5』的标题`
* 或贴一篇文章 / 一个原标题，自动输出三家 ×（主推 + 备选），只想要一家时也能单出

作者的野心不止三家：按仓库里的 `STYLE-ADAPTER.md` 提 PR，就能扩展「晚点 / APPSO / 36氪AI / InfoQ」等新媒体风格，目标是把标题生成做成**中文科技媒体标题风格蒸馏框架**。

## 写在最后

看完这些Skills，你可能会觉得：**这都是什么乱七八糟的东西。**

但如果我们仔细想想，它们的存在揭示了一些有趣的事实：

1. **AI的人格塑造能力远超预期**：通过精心设计的Prompt和双层架构，AI可以被塑造成各种人格特征，而且效果出奇地好。

2. **人们对于"被理解"的需求是强烈的**：前任、暗恋对象、父母、师兄……每一个Skill背后都是真实的情感需求。

3. **技术的尽头是人文**：当我们把冷冰冰的AI技术与情感、记忆、人际关系结合起来，就产生了这些奇妙的应用。

4. **"数字永生"不再是科幻**：无论是把离职同事的工作能力保存下来，还是让已故的师兄"继续"参加组会，这些项目都在探索一种新的纪念方式。

***

*同事跑了用同事.skill，前任跑了用前任.skill，被老板恶心了用老板.skill。*
*赛博永生一条龙，谁都跑不了。*

**你还知道哪些有趣的社区Skills？欢迎在评论区分享！**

---

---
url: https://ain.hmgf.hxcn.space/ai/ppt-generation-skills-202605.md
description: >-
  从真实交付需求出发，逐个介绍 guizang-ppt-skill、html-anything 与 beautiful-html-templates，说明网页
  PPT、配图、封面与模板库怎样组成一条可落地的 HTML 交付链。
---

# 用 Agent 生成网页 PPT

Agent 很会写 HTML，这件事很多人已经接受了。

一到 PPT，很多人还是会退回旧流程：找模板、贴内容、补配图，再单独做公众号头图、小红书封面和视频号横版封面。工具一多，链路就断了。

网页 PPT 值得单独拿出来讲，因为它能把整条交付链串起来：Agent 负责把内容拆成页面，HTML 和 CSS 负责排版，图片模型负责配图，模板库负责稳定风格，同一套视觉规则还能继续扩展到封面和社媒卡片。

这条链路里，`guizang-ppt-skill` 最接近成品生产，`html-anything` 负责更大的 HTML 交付面，`beautiful-html-templates` 解决模板选择。我也按这个顺序往下写。

## 为什么网页 PPT 适合交给 Agent

如果你要做的是一次线下分享、产品发布、内部方法论同步，最费时间的往往不是“翻页”本身，而是下面几件事：

* 把长文章或提纲压成 6 到 10 页的节奏；
* 让每页版式有明确层级，避免做成 Word 式堆字；
* 给事实页补流程图、关系图、UI 场景图；
* 给分享做封面图、分享卡、社媒比例图；
* 反复改字重、边距、对齐、图片裁切，不用每次都整套重做。

这些恰好都是 HTML 擅长、也是 Agent 擅长的事。HTML / CSS 是文本，Agent 能直接读写；图片、封面和社媒卡片也能沿用同一套视觉变量；成品如果能收束成单文件 HTML，预览、演示、截图、部署都会轻很多。

所以更实用的理解方式，是把 PPT 看成一种 HTML deliverable，再把配图、封面和模板一起拉进来。

## guizang-ppt-skill：从一份网页 PPT，扩展到配图和封面

它的定义很直接：这是一个适配 Claude Code、Codex 等 Agent 环境的网页 PPT Skill，用来生成**单文件 HTML 横向翻页 PPT**、PPT 配图和多平台封面。

### 项目定位

它不只给模板，还把 Agent 生成 deck 时最容易失控的部分提前写成了约束。

能力大致分成下面几块：

* 两套视觉系统：Style A 电子杂志风、Style B 瑞士国际主义；
* 横向翻页运行时：键盘、滚轮、触屏、索引都已经考虑进去；
* Style A 的 10 种布局和 Style B 的 22 种锁定版式；
* 主题色预设，颜色范围先限定好；
* 可选配图流程，直接给 Codex 接 GPT-Image 2.0 / GPT-M 2.0；
* 多平台封面输出，覆盖公众号、小红书、视频号等常见比例；
* 静态模式和单文件 HTML 交付，方便直接演示和发送。

这和传统“做个 PPT 模板”最大的差别在于：它把风格、版式、图片、导出一起定义了。你拿到的是一条可以反复复用的生产流程。

### 安装与触发

安装命令很短：

```bash
npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill
```

如果你更习惯直接让 Agent 自己安装，也可以把下面这类指令直接发给 Claude Code 或 Codex：

```text
帮我安装 guizang-ppt-skill。请把 https://github.com/op7418/guizang-ppt-skill 克隆到 ~/.claude/skills/guizang-ppt-skill，安装完成后检查 SKILL.md、assets/、references/ 是否存在。
```

已经装过的话，可以这样更新：

```text
帮我更新 guizang-ppt-skill。请进入 ~/.claude/skills/guizang-ppt-skill 执行 git pull，然后告诉我当前最新 commit。
```

触发方式同样很符合 Agent 工作流。你不需要记命令参数，只需要直接说需求：

```text
帮我基于这篇文章做一份瑞士风 PPT，控制在 7 页左右，需要 2-3 张配图。
```

或者：

```text
帮我把这份 Markdown 做成杂志风演讲 PPT。
基于这份 PPT 的核心观点，生成一张公众号 21:9 头图。
把这张产品截图重新设计成适合 PPT 的 16:10 配图。
```

它适配 Claude Code / Codex 的原因也在这里：工作流直接嵌在对话里。

### 目录结构

这个仓库的目录结构值得单独看，因为它非常像一个成熟 Skill 的拆分方式：

```text
guizang-ppt-skill/
├── SKILL.md
├── assets/
│   ├── template.html
│   ├── template-swiss.html
│   └── screenshot-backgrounds/
├── scripts/
│   └── validate-swiss-deck.mjs
└── references/
    ├── components.md
    ├── layouts.md
    ├── layouts-swiss.md
    ├── swiss-layout-lock.md
    ├── themes.md
    ├── themes-swiss.md
    ├── image-prompts.md
    ├── screenshot-framing.md
    └── checklist.md
```

这背后的设计很实用：

* `assets/` 放模板和背景素材；
* `references/` 放组件手册、布局骨架、主题色、图片提示词和检查清单；
* `scripts/` 放版式校验器；
* `SKILL.md` 负责把这些材料组织成可执行流程。

它没有把成败押在一句大 prompt 上，而是把“生成 PPT”拆成可验证的部件。这也是它和单纯模板仓库最大的差别。

### 这次更新补了什么

官方仓库列的是能力清单，归藏那篇 X 长文补了这次更新的动因。

更新动因写得很具体。文里提到，发布之后后台最常见的问题集中在三类：

* 能不能多几种风格；
* 配图能不能一起搞定；
* 做完 PPT 之后，封面是不是还要重画。

所以这次更新补的也是三件事：

1. 新增风格 B，也就是瑞士国际主义；
2. 在 Codex 里接入 GPT-Image 2.0，直接生成配图；
3. 把同一份内容继续延伸到多平台封面。

可执行的约束要看仓库里的 `references/` 和脚本。

### 两张配图放在什么位置

这次归档里已经把两张配图本地化到 `docs/ai/assets/ppt-generation-skills/`。正文里直接引用本地图，不走临时外链。

第一张图对应的是归藏在长文里解释“为什么要继续更新这个 Skill、为什么要补风格 / 配图 / 封面”这一层：

![归藏 X 长文配图：PPT Skill 更新示意图](/ai/assets/ppt-generation-skills/guizang-x-image-01.jpg)

第二张图对应的是瑞士风的设计纪律示意。重点不是让 Agent“自由发挥极简感”，而是把风格锁成一组明确规则：

![归藏 X 长文配图：瑞士风设计纪律示意](/ai/assets/ppt-generation-skills/guizang-x-image-02.jpg)

从这篇社媒长文能看出，归藏在把经验往代码规则里压。比如文中明确提到：

* 一份 deck 只允许一个高亮锚点色；
* 主标题和正文要拉开极大字号比例；
* 大字越大越细，不要用厚重黑体把页面压死；
* 去掉圆角、阴影、渐变，收紧成直角和发丝线；
* 用 16 列网格和大留白，而不是居中平均分布；
* 瑞士风里不要再叠 WebGL 动态背景。

这些规则配合 `layouts-swiss.md`、`themes-swiss.md`、`swiss-layout-lock.md` 一起看，意思就很清楚了：设计经验要落成 Agent 能执行的硬约束。

### 使用场景

它的使用范围写得很坦白：适合线下分享、行业内部讲话、私享会、AI 产品发布、demo day，以及带强烈个人风格的演讲；不适合大段表格数据、培训课件和多人协作编辑。

这个判断很合理。`guizang-ppt-skill` 强在表达和交付链，不适合承担公司里几十个人来回协作的课件系统。

### 典型工作流

如果拿它做一次正式分享，工作流通常是这样：

1. 把文章、提纲、录音整理稿或产品说明交给 Agent；
2. 第一轮先把内容压成 6 到 10 页的节奏，视觉先放一边；
3. 确定用 Style A 讲叙事，还是用 Style B 讲事实；
4. 页面骨架从模板和锁定版式里挑，不让 Agent 临场发明布局；
5. 配图页、截图页和纯文字 / 数据页分别定下来；
6. 跑一轮校验和浏览器预览，修字重、对齐和图片槽位；
7. 同一份 deck 再延伸成公众号头图、1:1 分享卡或小红书封面。

这条做法的优势在于改动成本低。HTML deck 改文字、换图、调留白，通常比重做一份传统 PPT 轻得多。

### 在这条链里的位置

如果你要的是一条已经成形的网页 PPT 工作流，尤其还想把配图和封面一起纳入，`guizang-ppt-skill` 可以直接装上。它负责的是这条链路里最重的一段：**把内容做成 deck**。

## html-anything：把 deck 放回更大的 HTML 交付面里

第二个项目是 [`nexu-io/html-anything`](https://github.com/nexu-io/html-anything)。

`html-anything` 是通用 HTML 工具。项目把自己定位成 **agentic HTML editor**：Markdown 只是草稿，真正给人读的输出物应该是 HTML，由本地 Agent 来写。

### 它和 PPT 的关系：把 deck 放进更大的交付面

为什么这篇文章里要把它放进来？因为网页 PPT 只是 HTML 交付面中的一种。

`html-anything` 把这个思路铺得很大：它支持 8 种 coding-agent CLI，底层复用你已经登录过的 CLI 会话，不额外要求 API Key；上层用 75 个 skill 模板去覆盖 9 类交付 surface，包括：

* magazine articles；
* keynote decks；
* posters；
* tweet / XHS cards；
* web prototypes；
* data reports；
* Hyperframes videos。

它是一个让 Agent 面向不同 HTML 结果物持续工作的编辑器。如果你经常在 deck、海报、长文、社媒卡片之间切换，这个视角很重要。

### 安装与启动

本地启动流程是：

```bash
git clone https://github.com/nexu-io/html-anything
cd html-anything
pnpm install
pnpm dev
```

跑起来之后，浏览器端会自动探测你机器上已经登录过的 Agent CLI。项目说明里明确列了当前支持的 8 种：Claude Code、Codex、Cursor Agent、Gemini CLI、GitHub Copilot CLI、OpenCode、Qwen Coder、Aider。

这一点很关键。`html-anything` 直接复用你已经有的本地 Agent 会话。对已经在用 Codex 或 Claude Code 的人来说，入口成本很低。

### 使用场景

在这篇文章的语境里，最值得关注的是它的 `deck`、`social` 和 `prototype` 三类 surface。

项目说明里专门列了 `deck` 模式下的技能，其中既有 `deck-swiss-international`，也有 `deck-guizang-editorial`，后者还直接标注来源于 [`op7418/guizang-ppt-skill`](https://github.com/op7418/guizang-ppt-skill)。

这里能看出两点：

1. `html-anything` 在更大的编辑器框架里吸收了现成的 deck 风格，包括 `guizang-ppt-skill` 这样的项目成果；
2. 它对应的是“今天做 deck，明天还要做海报、社媒卡片和长文页”这类工作流。

如果你的输出物并不止 PPT，而是一组 HTML 内容资产，它会比单独装一个 deck skill 更顺手。

### 项目能力

和 PPT 关系最大的是三块。

第一块是 **skills 组织方式**。它的 75 个 skill 都遵循 `SKILL.md` 约定，并额外带上 `mode`、`scenario`、`surface`、`design_system` 这些元信息。这样一来，模板选择器会先把 Agent 约束到某一类结果物，不会直接盲目生成。

第二块是 **export targets**。它支持：

* 一键导出 WeChat；
* 导出 X / Weibo / Xiaohongshu 所需 PNG；
* 下载单文件 `.html`；
* 下载高 DPI `.png`。

这和网页 PPT 的需求天然接上。deck 做完之后，往往马上要发图、发分享卡、发公众号；这恰好不是传统 PPT 工具擅长的地方。

第三块是 **sandboxed preview** 和本地 spawn 架构。它用浏览器 iframe 预览、服务端路由调本地 CLI、SSE 流式回传结果。对 deck 来说，这意味着你可以更快迭代，不必每次都走一轮“导出再打开”的笨流程。

### 统一出口

很多人第一次看到 `html-anything` 会觉得它太大，不像 PPT 工具；从交付角度看，这恰好是它的价值。

如果你已经认同“最终交付不只是一份 deck，还是一套 HTML 结果物”，那把 deck、海报、封面、数据报告放进同一个出口里会省事很多。特别是要做一整波活动内容时，这种统一出口会比孤立的模板仓库更顺。

### 在这条链里的位置

`html-anything` 在这条链里承担的是 HTML 交付操作台：它不一定负责最细的版式美学，但很适合承接多种 HTML 输出面，把 deck 和社媒资产放在同一个界面里跑。

## beautiful-html-templates：把模板选择这件事，交给 Agent 有章法地做

第三个项目是 [`zarazhangrui/beautiful-html-templates`](https://github.com/zarazhangrui/beautiful-html-templates)。

项目定位很明确：这是一个 **HTML slide templates library**。它就是给 coding agent 选模板用的，目标是让 Agent 能自动挑出合适模板，再据此产出一套好看的 deck。

### 项目定位

很多 deck 做不好，问题往往出在起手就选错了视觉系统。

有的人拿适合轻叙事的模板去讲硬数据，有的人拿极简瑞士网格去塞一篇很有人情味的分享稿，最后看起来都别扭。`beautiful-html-templates` 单独处理的就是这件事：先让 Agent 学会匹配 brief 和模板，再去改内容。

仓库特别提醒，Agent 使用这个库时应该先读 `AGENTS.md`。也就是说，它不只是“存了 34 套模板”，还带了一套模板索引和选择规则。

### 怎么开始用

起手方式很简单：

```text
Clone https://github.com/zarazhangrui/beautiful-html-templates and follow the instructions in AGENTS.md to build me a beautiful HTML slide deck.
```

这句话已经把它的角色说清楚了：你把模板库给 Agent，Agent 再根据 `AGENTS.md` 去读 `index.json`、匹配 brief、克隆模板、改内容。

### 模板库里有什么

最显眼的是 Gallery：目前收了 34 套模板，每套给三张示例页，分别是 cover、mid-deck、later slide，方便快速判断这一套视觉系统在不同页面位置的表现。
这比只看一张封面图更有参考价值，因为很多模板封面好看，但中段信息页一落地就会露馅。

这里的风格很多，不是只收“商务蓝”那一类模板。项目首页列出来的就包括：

* `Soft Editorial`：暖纸感、衬线标题、柔和配色；
* `Editorial Forest`：森林绿、粉和奶油色，偏静态叙事；
* `Pin & Paper`：黄纸、别针插画、手写感；
* `Sakura Chroma`：带日系包装和复古彩带的视觉；
* `Stencil & Tablet`：更偏材质化和展陈感；
* `Cobalt Grid` 等更偏网格与结构的风格。

它特别适合处理这样的问题：**你已经知道要做网页 deck，但还没决定该用哪一种视觉语言**。

### 放在流程里的位置

把它放在流程中前段会更顺。

常见做法是：

1. 明确这次分享是叙事、分析、产品发布，还是品牌展示；
2. 让 Agent 在模板库里挑 1 到 3 套候选；
3. 看 cover、正文页和后段页是否都撑得住内容密度；
4. 选中后再进入具体改写，别等内容全生成完了再硬套模板。

如果你前面已经用 `html-anything` 这样的编辑器框架，那么 `beautiful-html-templates` 还可以作为模板来源；如果你更偏手动一点，也可以直接把仓库交给 Claude Code / Codex，让它按 `AGENTS.md` 的规则替你选。

### 在这条链里的位置

`beautiful-html-templates` 在这条链里的位置很清楚：负责**模板选择与视觉起手**。当你不想每次从零发明一套 deck 风格时，它能显著降低“起手选错模板”的成本。

## 一条能跑通的网页 PPT 流程

把三者放进同一条链里，可以这样分工。

### 准备主题资料

原始材料要整理成 Agent 容易消化的输入。可以是一篇文章、产品说明、会议提纲，或者一份采访整理稿。材料里最好直接交代清楚：

* 受众是谁；
* 目标时长多长；
* 是讲故事还是讲事实；
* 哪几页一定要图；
* 哪些平台还要额外封面；

这些信息越早说明，后面返工越少。

### 选入口

如果这次就是要做一份完整网页 PPT，而且还想把配图和封面一起做，`guizang-ppt-skill` 应该排在最前面。

如果还在多套风格之间挑视觉方向，`beautiful-html-templates` 会更顺手。

如果你同时还要做社媒卡片、海报、长文页，或者想把输出统一到一个 HTML 编辑器里，`html-anything` 会更省事。

### 生成页面骨架

无论用哪个入口，关键都在于让 Agent 基于已有模板或锁定版式工作。

对于 `guizang-ppt-skill`，这一步对应的是：

* Style A 用 `assets/template.html`；
* Style B 用 `assets/template-swiss.html`；
* 版式从 `layouts.md` 或 `layouts-swiss.md` 里选。

对于 `beautiful-html-templates`，这一步对应的是：

* 按 `AGENTS.md` 的规则匹配模板；
* 根据 brief 选中模板；
* 复制对应模板目录，再改成自己的内容。

### 补配图和截图

这一步以前最容易断掉。

`guizang-ppt-skill` 这次更新里，最实用的一点就是把配图明确纳入流程，仓库里也列了 `image-prompts.md` 和截图美化背景。对于产品分享、方法论说明、系统关系页来说，这比单纯“配一张好看照片”更重要，因为很多页需要的是流程图、信息图、UI 场景图。

如果你在 `html-anything` 里工作，这一步还能顺势延伸到其他 surface，比如海报或社媒图，而不是只停在 deck 页面里。

### 调封面和多平台比例

网页 PPT 的一个现实优势，是同一套视觉系统可以继续扩到封面。

归藏在 X 长文里提到，这次更新后同一份内容可以继续拼出小红书、公众号、视频号等多种规格。这样就能减少“演讲内容做完之后，还要再找设计师补一轮封面”的情况。

### 导出与分享

`guizang-ppt-skill` 明确把单文件 HTML 当成交付目标。这个形式很适合：

* 浏览器直接打开演示；
* 发给别人预览；
* 放到静态站点；
* 截图导出社媒图。

如果你需要的是更统一的导出面，`html-anything` 提供的 `.html`、`.png`、WeChat、X / XHS 等导出能力会更方便。
不过这类链路当前仍然主要服务单人或小团队的快速产出；如果你要回到多人协作审批、批注和版本管理，还是得额外补协作层。

## 三者在工作流中的位置

最简洁的记法就是：

* `guizang-ppt-skill` 负责把内容真正做成网页 PPT，并把配图、封面一起纳进来；
* `html-anything` 负责把 deck 放回更大的 HTML 交付环境里，统一多种输出面；
* `beautiful-html-templates` 负责模板库和视觉起手，帮 Agent 更稳地选对那套风格。

如果你的需求集中在“做一份能讲、能看、还能顺手出封面的网页 PPT”，`guizang-ppt-skill` 可以作为入口。

如果要处理的不止一份 deck，而是一组 HTML 内容资产，再把 `html-anything` 和 `beautiful-html-templates` 接进来，会顺很多。

## 资料来源

* `guizang-ppt-skill` README：<https://github.com/op7418/guizang-ppt-skill>
* `html-anything` README：<https://github.com/nexu-io/html-anything>
* `beautiful-html-templates` README：<https://github.com/zarazhangrui/beautiful-html-templates>
* 归藏 X 长文来源：`docs/ai/references/ppt-generation-skills/guizang-x-source.html`

---

---
url: https://ain.hmgf.hxcn.space/ai/ppt-skills-review-202606.md
description: 7 个主流 PPT 生成 Skills 的横向评测，从编辑自由度、审美风格、输出格式到实用组件逐项对比。
---

# PPT Skills 锐评

> 注意：有些 Skill 不是专门做 PPT 的，所以评分会有点低，只是需求不同，想专门做 PPT 的看最前面的。

## 1. hugohe（3.1 万 star）| 顶级天花板

全场唯一正经做 PPT 的！元素全可编辑，自带音色克隆和旁白生成，纯纯降维打击。

* **GitHub**：<https://github.com/hugohe3/ppt-master/tree/main>
* **核心优势**：全元素可编辑、音色克隆、旁白生成
* **适用场景**：正式演讲、产品发布、需要完整 PPT 工作流的场景

## 2. 张咋啦（2.3 万 star）

顶级主观审美最佳，完成度极高！目前呈现为 HTML 格式，稍微考验一点使用者的基础。

* **GitHub**：<https://github.com/zarazhangrui/frontend-slides/tree/main>
* **核心优势**：审美完成度极高、视觉设计精良
* **适用场景**：对视觉要求高的分享、需要高质量 HTML 演示的场景

## 3. 花叔（1.9 万 star）

顶级审美极佳，关键是能输出可编辑的 PPTX 格式！

* **GitHub**：<https://github.com/alchaincyf/huashu-design>
* **核心优势**：审美优秀、支持 PPTX 格式输出
* **适用场景**：需要可编辑 PPTX 文件、传统 PPT 工作流兼容

## 4. 歸藏（1.5 万 star）

人上人瑞士风审美非常棒，自带快捷键，很适合线下分享。

* **GitHub**：<https://github.com/op7418/guizang-ppt-skill>
* **核心优势**：瑞士国际主义风格、快捷键支持、线下分享优化
* **适用场景**：线下分享、行业内部讲话、AI 产品发布

## 5. Lewis（6500 star）

功能设计十分贴心，自带计时器和逐字稿等实用组件。

* **GitHub**：<https://github.com/lewislulu/html-ppt-skill/tree/main>
* **核心优势**：计时器、逐字稿等实用组件
* **适用场景**：需要演讲辅助工具的场景

## 6. 宝玉（2.2 万 star）

NPC 风格偏可爱，主要以纯图片形式呈现。

* **GitHub**：<https://github.com/JimLiu/baoyu-skills/tree/main/skills/baoyu-slide-deck>
* **核心优势**：可爱 NPC 风格、图片化呈现
* **适用场景**：轻松氛围的分享、需要可爱风格的场景

## 7. 乔木（5400 star）

偏向于纯图片卡片的输出，更侧重于内容的初步呈现。

* **GitHub**：<https://github.com/joeseesun/qiaomu-anything-to-notebooklm>
* **核心优势**：图片卡片输出、内容快速呈现
* **适用场景**：内容初步整理、快速原型展示

## 总结

| 排名 | 名称 | Star | 核心优势 | 输出格式 |
|:---:|------|-----:|---------|---------|
| 1 | hugohe | 3.1 万 | 全元素可编辑、音色克隆、旁白生成 | PPT |
| 2 | 张咋啦 | 2.3 万 | 审美完成度极高 | HTML |
| 3 | 花叔 | 1.9 万 | 审美优秀、PPTX 输出 | PPTX |
| 4 | 歸藏 | 1.5 万 | 瑞士风、快捷键 | HTML |
| 5 | 宝玉 | 2.2 万 | 可爱 NPC 风格 | 图片 |
| 6 | Lewis | 6500 | 计时器、逐字稿 | HTML |
| 7 | 乔木 | 5400 | 图片卡片、快速呈现 | 图片 |

## 资料来源

* 评测来源：X 平台 PPT Skills 锐评比拼
* 相关文章：[用 Agent 生成网页 PPT](/ai/ppt-generation-skills-202605)

---

---
url: https://ain.hmgf.hxcn.space/ai/vibe-coding-common-mcp-202605.md
description: >-
  从 MCP 基础概念、客户端配置到 Context7、MarkItDown、Chrome DevTools MCP 的实际用法，整理一条适合 Vibe
  Coding 的接入顺序。
---

# Vibe Coding 常用 MCP

很多人刚开始用 AI 编程助手时，会先堆提示词：把项目背景、接口文档、报错日志、页面状态都塞进聊天框里。短期能用，时间一长就会卡在三个地方：上下文太长、信息过时、动作落不了地。MCP 适合处理这三个麻烦：文档直接查，文件直接转，浏览器直接连。

## MCP 到底解决什么问题

MCP 是 `Model Context Protocol`，也就是模型上下文协议。它是一套开放标准，目的是让 AI 客户端用统一方式连接外部系统。MCP 官方文档把它比作 AI 世界里的 `USB-C`：不同客户端只要支持这套协议，就能用相近的方法接入数据源、工具和工作流。

放到 Vibe Coding 的场景里，可以把 MCP 拆成五个最重要的部分：

### MCP Server

MCP Server 是能力提供方。它向客户端暴露一组可调用的工具、可读取的资源，或者一套已经定义好的提示模板。

* 文档检索类服务器会暴露“查某个库的文档”“拉某个版本的代码示例”之类的能力。
* 文件处理类服务器会暴露“把 PDF 转成 Markdown”“从 Word 或 PPT 提取结构化内容”的能力。
* 浏览器调试类服务器会暴露“读取控制台日志”“抓网络请求”“查看 DOM”“截图”之类的能力。
* 再往后扩展，就会出现数据库、GitHub、设计稿、工单系统、CRM 等第三方业务接入。

### 客户端

客户端是发起调用的一侧。你常见的 `Cursor`、`Windsurf`、`Claude Code`、`Codex`，都可以看作 MCP Client。它们负责：

1. 注册 MCP 服务器；
2. 把用户问题交给模型；
3. 在模型判断需要工具时发起 MCP 调用；
4. 把返回的结果再放回当前对话。

同一个 MCP Server 可以被不同客户端复用，这是它最实际的工程价值之一。你不用为了 Cursor 写一版、为了 Claude Code 再写一版。

### 工具调用

MCP 不止是多塞一段上下文，更关键的是工具调用。模型可以按当前任务主动触发能力。

比如：

* 写 React 组件时，先调用 Context7 找最新文档；
* 读招股书 PDF 时，调用 MarkItDown 转 Markdown；
* 修前端白屏时，调用 Chrome DevTools MCP 直接读控制台和网络面板。

和手工复制资料相比，这种做法可重复，也方便随时再跑一遍。

### 外部上下文

MCP 让模型拿到运行时上下文，而不只靠训练时记忆。这个差别很大。

训练记忆适合回答通用问题，但经常过时；运行时上下文更能处理你手头项目依赖的东西，例如：

* 当前版本的框架文档；
* 今天刚更新的 SDK 参数；
* 你本地的 PDF、Word、PPT、Excel；
* 正在打开的浏览器页面；
* 某个团队系统里的实时数据。

这也是它适合 Vibe Coding 的原因：模型少猜一点，多查一点，多动手一点。

### 权限配置

MCP 带来收益，也把权限问题一起带了进来。官方文档和各客户端文档都反复强调：MCP Server 可能访问本地文件、网络资源、浏览器内容，甚至代你调用第三方服务，所以权限配置不能省。

实践里至少要注意四件事：

1. **优先使用最小权限的 API Key**，不要把高权限生产密钥直接塞进配置。
2. **能本地跑的敏感服务尽量本地跑**，例如只读文件、受限目录、内部文档处理。
3. **分清 stdio、本地 HTTP、远程 HTTP / SSE** 三种连接方式的差别，远程服务尤其要关注鉴权头和 OAuth。
4. **保留人工确认或 Auto-run 白名单**，不要让所有工具都默认无确认执行。

Cursor、Windsurf、Claude Code、OpenAI 的 MCP 文档都分别提到过认证、审批、日志或安全建议；不要把它们当成“装完能跑就行”的插件配置。

## MCP 接入顺序

第一次配 MCP，不用一口气装十几个。按工作流顺序来，通常更省事：

1. **先装文档检索**：让模型先能读对文档，减少 API 幻觉；
2. **再装文件转换**：把 PDF、Word、PPT、Excel 这类资料变成模型真正能处理的 Markdown；
3. **再装浏览器调试**：处理页面、网络、控制台、性能问题；
4. **再接第三方业务系统**：比如 GitHub、数据库、工单、设计系统、CRM。

这样排，前 3 类已经覆盖了大多数 Vibe Coding 的基本盘：先查对，再读懂，再调通。等这条链路稳定了，再往外扩 SaaS 接入会轻松很多。

## Context7：文档与代码示例查询

### 它解决什么问题

Context7 是 Upstash 维护的 MCP 服务器，作用很直接：给 AI 编程助手提供最新的开发文档和代码示例，减少对旧知识的依赖。

Context7 最适合处理这几类问题：

* 某个库最近版本的 API 到底怎么写；
* 旧教程里的写法是否已经过时；
* 需要找官方推荐示例，而不是论坛拼凑答案；
* 同一个框架不同版本差异很大，必须按当前版本回答。

Context7 在项目文档里把这个问题说得很直接：没有外部文档时，模型经常给出过时示例或不存在的 API；接上 Context7 之后，模型就能在回答前查真实文档。

### 什么时候最值得用

它适合在接入 MCP 后作为默认的文档查询入口。

适合的典型场景包括：

* 新接手一个你不熟的框架项目；
* 升级依赖后，旧代码突然不兼容；
* 需要让 AI 按某个库的官方最佳实践生成代码；
* 需要尽量减少“看起来像对的，但实际跑不通”的幻觉代码。

它的覆盖面在单个 MCP 中较广。

### 准备 API Key

Context7 支持直接在客户端里接入远程 MCP 服务。按官方文档，推荐先到 `https://context7.com/dashboard` 申请 API Key，以获得更高的调用额度。

它的远程服务地址是：

```text
https://mcp.context7.com/mcp
```

常见做法是通过请求头传 `CONTEXT7_API_KEY`。密钥不要写进文章、截图或团队共享仓库。

### 配置示例

下面几种写法都基于官方资料或本机 CLI 帮助输出整理，足够作为入门模板。

#### Cursor

Cursor 官方文档说明可以在项目级 `.cursor/mcp.json` 或全局 `~/.cursor/mcp.json` 中配置远程 MCP。Context7 用远程 HTTP 配置最直接：

```json
{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "${env:CONTEXT7_API_KEY}"
      }
    }
  }
}
```

这里我更建议用 `${env:CONTEXT7_API_KEY}`，不要把密钥明文写死。Cursor 官方文档也支持在 `url`、`headers`、`env` 等字段里做变量插值。

#### Windsurf

Windsurf 官方文档把配置文件路径写得更明确：`~/.codeium/windsurf/mcp_config.json`。远程 HTTP MCP 可以写 `serverUrl`，也支持在 `headers` 中读取环境变量：

```json
{
  "mcpServers": {
    "context7": {
      "serverUrl": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "${env:CONTEXT7_API_KEY}"
      }
    }
  }
}
```

如果你在团队里统一分发 MCP，Windsurf 还支持注册表、白名单和团队级管理，但那属于后续治理问题，不是第一次接入 Context7 必须处理的事。

#### Codex

OpenAI 官方文档主要介绍了如何在 API 侧把 MCP Server 作为 `tools` 接入；本机 `codex` CLI 的帮助输出则显示，Codex 已经有 `codex mcp add` 子命令，可以直接注册远程 MCP。

```bash
codex mcp add context7 \
  --url https://mcp.context7.com/mcp \
  --bearer-token-env-var CONTEXT7_API_KEY
```

这里多说一句：Context7 官方文档推荐的是 `CONTEXT7_API_KEY` 请求头，而 `codex mcp add --url` 帮助里原生暴露的是 Bearer Token 形式的环境变量参数。能否完全等价，要看你当前使用的 Codex 版本和实际联通情况；如果你需要自定义请求头，通常还得继续查当前版本 Codex 的 MCP 配置能力。

可以确定的是，**Codex 已经有 MCP 管理入口**；至于 **Context7 在 Codex 里最稳妥的鉴权写法**，仍建议你按本地版本实测一遍。

#### Claude Code

Claude Code 本机帮助输出明确支持 `claude mcp add`，既能加 stdio 服务器，也能加 HTTP 服务器。对 Context7 来说，直接走远程 HTTP 最方便：

```bash
claude mcp add --transport http \
  -H "CONTEXT7_API_KEY: $CONTEXT7_API_KEY" \
  context7 https://mcp.context7.com/mcp
```

更偏好界面方式的话，也可以用 Claude Code 当前版本的 MCP 管理入口处理；但命令行最容易复现和团队共享。

### 使用时怎么提问更有效

Context7 最常见的问题在于问得太空。下面这种问法，通常效果一般：

```text
帮我写一个 Next.js 登录页
```

更稳的做法，是明确告诉模型先查文档，再按目标版本输出：

```text
先用 Context7 查 Next.js App Router 和 better-auth 的最新文档，
再给我一个可运行的登录页示例，要求说明服务端和客户端各放哪部分。
```

这种提法有两个好处：

* 先限定资料来源；
* 再限定输出目标。

这样问很实用：资料源先卡住，输出目标再卡住，模型会少走很多弯路。

## MarkItDown：资料转为 Markdown

### 它解决什么问题

MarkItDown 是 Microsoft 开源的文档转换工具。可以把它看成一层结构化转换器，用来把各种文件转成适合 LLM 消化的 Markdown。

项目文档当前列出的主要输入类型包括：

* PDF
* PowerPoint
* Word
* Excel
* 图片
* 音频
* HTML
* 各类文本与压缩包中的常见内容

对于 Vibe Coding，这意味着很多本来“AI 看得到文件名但读不顺内容”的资料，都能先转一遍再交给模型。

### 什么时候最值得用

MarkItDown 常见在“资料先行”的任务里，例如：

* 把产品 PRD、招投标 PDF、客户需求 Word 转成 Markdown；
* 把培训课件、路演 PPT、调研 Excel 变成可检索文本；
* 把长文档转成结构化内容，再让模型做摘要、改写、抽取待办；
* 为 AI 编程任务准备“说明书上下文”，避免模型只看截图和零散复制片段。

如果你经常在“写代码”和“整理资料”之间来回切换，MarkItDown 的回报通常很高。

### 安装与配置

项目文档先给的是 Python 包安装方式：

```bash
pip install 'markitdown[all]'
```

如果你希望把它作为 MCP Server 交给 AI 客户端，一种常见方式是使用 `uvx` 启动 `markitdown-mcp`：

```toml
[mcp_servers.markitdown]
command = "uvx"
args = ["markitdown-mcp"]
```

这类写法适合支持 stdio MCP 的客户端。换成 JSON 风格配置时，等价思路通常是：

```json
{
  "mcpServers": {
    "markitdown": {
      "command": "uvx",
      "args": ["markitdown-mcp"]
    }
  }
}
```

环境里没有 `uv` 的话，就把 Python 运行时和依赖装好，再按你所用客户端支持的方式启动相同服务。

### 它在工作流里的位置

很多人装完 MarkItDown 后，会把它当成“万能文件入口”。放到工作流里看，它负责的就是**转换在前，分析在后**。

比如你有一份 60 页 PDF 产品文档，更稳的流程是：

1. 先用 MarkItDown 转成 Markdown；
2. 再让模型按章节提炼关键需求；
3. 再把提炼后的需求交给 Context7 辅助生成代码方案；
4. 需要调页面时，再切到 Chrome DevTools MCP。

它在工作流里更像中间层。

### 使用时要注意什么

MarkItDown 的安全提示值得单独看一眼：它会以当前进程权限执行 I/O。也就是说，MarkItDown 能访问的内容，和你启动它的进程能访问的内容基本一致。

所以至少要遵守这几条：

* 不要把不可信的外部输入直接丢给高权限运行的 MarkItDown；
* 如果只需要本地文件，就尽量使用更窄的本地转换方式，不要开放成过宽的通用入口；
* 需要远程抓取时，先自己控制下载范围，再交给转换器处理；
* 对含敏感信息的文档，优先本地执行，不要随便改成远程托管服务。

文档里还提到可以优先选择更窄的 `convert_local()`、`convert_stream()` 等接口，不要一把梭走最宽泛的 `convert()`。后面如果打算把 MarkItDown 放进团队自动化流程，这一点尤其重要。

## Chrome DevTools MCP：别再手抄控制台和网络请求

### 它解决什么问题

Chrome DevTools MCP 由 Google 维护，目标很明确：让 AI 代理直接操作和检查一个活的 Chrome 浏览器实例，把 DevTools 那套调试能力通过 MCP 暴露出来。

项目文档列出的核心能力包括：

* 读取控制台消息；
* 分析网络请求；
* 截图；
* 查看 DOM；
* 记录性能 trace 并给出性能洞察；
* 借助 Puppeteer 做更可靠的自动化操作。

这基本覆盖了前端调试里最折磨人的那部分：页面明明已经打开，但模型根本不知道浏览器里到底发生了什么。

### 什么时候最值得用

Chrome DevTools MCP 很适合这几类场景：

* 页面白屏，但终端构建没报错；
* 某个接口返回 401 / 500，你需要看实际请求和响应；
* DOM 结构和你以为的不一样；
* 需要验证首屏性能、LCP、渲染阻塞资源；
* 想让 AI 帮你做一次真实的前端回归检查，而不是只看源码猜。

Context7 多半用在写代码之前，Chrome DevTools MCP 更常用在项目跑起来之后。

### 安装与配置

项目文档和 Chrome for Developers 的文章都给了标准安装方式，最常见的是用 `npx` 启动：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}
```

如果你只想做基础浏览器任务，项目文档还给了更轻的 `--slim --headless` 模式：

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]
    }
  }
}
```

这对 CI、远程环境或者不想弹出浏览器窗口的场景很有用。

### 使用时最常见的三类任务

#### 1. 看控制台和报错堆栈

当前端报错只在浏览器里出现时，最简单的提法就是：

```text
打开当前页面，读取控制台错误，告诉我最可能导致白屏的第一处异常。
```

这比“我复制一段 console 截图给你”稳定得多，因为它拿到的是实际环境里的完整日志。

#### 2. 看网络请求

很多前端问题不在组件本身，而在接口根本没通。你可以直接让模型：

```text
检查页面加载时失败的网络请求，按状态码列出出错接口，
并告诉我哪个最可能导致数据没渲染出来。
```

这时它的价值就很具体：模型直接在读真实的 Network 面板。

#### 3. 看 DOM 和性能

页面“看起来不对”时，可以直接让它检查 DOM；页面“慢”时，就让它看 trace、LCP 或阻塞资源。

Chrome 官方文章给出的示例里，性能诊断就是重点用法之一，不只是自动点页面。

### 使用时要注意什么

项目文档提醒得很直接：它会把浏览器实例中的内容暴露给 MCP 客户端，包括可检查、可修改的数据。所以不要在带有敏感账号、隐私数据的浏览器上下文里随便挂给任何 AI 客户端。

另外还有两点常被忽略：

* 它官方明确支持的是 Google Chrome 和 Chrome for Testing；其他 Chromium 浏览器可能能跑，但不保证行为一致。
* 文档说明默认可能收集使用统计；如果你不希望这样，可以加 `--no-usage-statistics`。性能工具还可能访问 CrUX 数据，如不需要可按官方说明关闭相关能力。

这些都不是边角料，都是你在团队环境里决定能不能默认开启时必须看的条件。

## 这三类 MCP 连起来怎么用

把 Context7、MarkItDown、Chrome DevTools MCP 放在一起，最顺手的一条链路通常长这样：

### 第一步：查文档

你先让 AI 确认框架、库、SDK 的最新写法。这里优先用 Context7，避免一开始就基于过时 API 搭方案。

### 第二步：再转资料

如果需求来自 PDF、Word、PPT、Excel、截图或网页存档，先用 MarkItDown 转 Markdown，把资料结构化之后再让模型读。

### 第三步：开始编码

到这一步，模型已经同时拿到了最新文档和结构化需求，生成代码的成功率会比直接裸写高很多。

### 第四步：打开浏览器调试

页面一旦跑起来，遇到白屏、接口异常、布局错乱、性能问题，就切到 Chrome DevTools MCP，不要继续靠截图和肉眼描述。

### 第五步：接入第三方业务系统

等前三步稳定后，再考虑接 GitHub、数据库、工单系统、设计平台、CRM 或内部服务。这样做的好处是，基础链路已经可靠，后面再加业务 MCP，也更容易看清它到底解决什么问题。

## 第一次配 MCP，可以这样取舍

现在就准备开始收拾自己的 MCP 配置的话：

* **只做代码开发**：装 Context7；
* **经常处理 PDF / Word / PPT 资料**：加上 MarkItDown；
* **经常调前端页面**：再加 Chrome DevTools MCP；
* **涉及团队系统和业务自动化**：再扩第三方业务接入。

这三类组合起来，已经能覆盖很多 `VibeCoding` 场景里的基础能力：文档、资料、浏览器。更多项目清单放到第 16 篇继续展开。

## 参考资料

1. MCP 官方文档：<https://modelcontextprotocol.io/docs/getting-started/intro>
2. Context7 官网：<https://context7.com/>
3. Context7 README：<https://github.com/upstash/context7>
4. Cursor MCP 文档：<https://cursor.com/docs/mcp>
5. Windsurf MCP 文档：<https://docs.windsurf.com/windsurf/cascade/mcp>
6. OpenAI MCP 文档：<https://developers.openai.com/api/docs/mcp>
7. MarkItDown README：<https://github.com/microsoft/markitdown>
8. Chrome DevTools MCP README：<https://github.com/ChromeDevTools/chrome-devtools-mcp>
9. Chrome for Developers：<https://developer.chrome.com/blog/chrome-devtools-mcp>

---

---
url: https://ain.hmgf.hxcn.space/ai/mcp-toolbox-202605.md
description: >-
  接着第 02 篇往下看，按第三方应用接入、抓取与浏览器、联网搜索、项目清单、设计类 MCP 五类场景，整理
  12306、Firecrawl、Playwright、Fetch、Scrapling、CloakBrowser、free-web-search-ultimate、Awesome-MCP-ZH
  和 MeiGen 的安装与用法。
---

# MCP 工具箱

第 02 篇已经把 MCP 是什么讲过了。这一篇不再重复协议基础，直接补项目清单：查票、抓网页、点页面、联网搜索、找项目、做设计，这几类任务要装的工具本来就不是一回事。

这批项目里最容易混淆的有两组：

* **浏览器自动化** 负责进页面、点页面。**联网搜索** 负责找到入口和证据。
* **项目清单** 用来找路。**可直接安装的 MCP 服务器** 才是实际干活的工具。

这篇按场景来讲，不按仓库 star 数排队。

## 分类方式

### 第三方应用接入

这类项目把某个具体服务接给 Agent，重点是把现成业务能力做成 MCP 工具。

### 抓取 / 浏览器 / 网页读取

这类项目都和"读网页"有关，但分工差很多：有的偏抓取 API，有的偏真实浏览器交互，有的只做轻量读取，有的专门处理反爬和会话。

### 联网搜索

搜索类项目解决的是"找到网页和证据"。点页面、跑整站抓取，通常还得交给别的工具。

### 清单 / 导航

这一类本身是索引，适合在你不知道该装哪一个 MCP 时先查路标。

### 设计类 MCP

这类 MCP 负责把图片、视频、提示词、设计流程接给 Agent。

## 第三方应用接入

### 12306-mcp

`12306-mcp` 代表的是另一条思路：别让 Agent 上网搜，再从一堆页面里扒车次；直接把 12306 查询能力做成 MCP 工具。

仓库当前列出的能力包括：

* 查询 12306 购票信息
* 过滤列车信息
* 过站查询
* 中转查询

可以把它看成一个"铁路票务查询适配层"。如果你的目标是让 Agent 帮你查余票、比中转方案、做行程草稿，这种项目比通用网页抓取稳定，也更省 token。

### 安装和接入

仓库给了最直接的启动方式：

```bash
npx -y 12306-mcp
```

如果你想把它挂到 MCP 客户端里，配置可以写成：

```json
{
  "mcpServers": {
    "12306-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "12306-mcp"
      ]
    }
  }
}
```

它也支持 HTTP 方式启动：

```bash
npx -y 12306-mcp --port 8080
```

### 使用场景

* 查某天某地到某地的余票
* 让 Agent 做车次过滤，再给出备选路线
* 做出差行程草稿
* 给客服或内部助理工具补一个"铁路查询"能力

这一类项目的价值不在"会不会抓网页"，而在"把业务动作直接做成工具"。

## 抓取 / 浏览器 / 网页读取

### firecrawl-mcp-server

Firecrawl 的定位一直很清楚：把网页变成 Agent 更容易消费的内容。它把搜索、抓取、结构化提取、批量处理和云端浏览器会话打包到了一套接口里。

官方当前列出的能力包括：

* 搜索网页并返回完整页面内容
* 抓取任意 URL，转成干净的结构化数据
* 和页面交互，支持点击、导航、操作
* 深度研究流程
* 云端浏览器会话
* 自动重试、限流
* 支持云端 API，也支持自托管

如果你要处理的是"公开网页很多、格式不统一、还要转 Markdown 或 JSON"的任务，Firecrawl 很顺手。

### 安装和使用方式

最短命令是：

```bash
env FIRECRAWL_API_KEY=fc-YOUR_API_KEY npx -y firecrawl-mcp
```

放进 MCP 客户端时，常见配置长这样：

```json
{
  "mcpServers": {
    "firecrawl-mcp": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": {
        "FIRECRAWL_API_KEY": "YOUR-API-KEY"
      }
    }
  }
}
```

如果你是自托管 Firecrawl，也保留了 `FIRECRAWL_API_URL` 这种入口，不一定非走官方云。

### 它和普通 fetch 的差别

Firecrawl 在下面这些任务里更顺手：

* 已知一批网址，要批量拉正文
* 要把网页内容转成 Markdown 或结构化 JSON
* 需要搜索、抓取、交互放在同一条链路里
* 希望 Agent 少处理网页噪音，多处理正文

如果只是读一两个简单页面，它会显得偏重；一旦进入批量采集、研究整理、网页交互混合链路，它就进入生产工具范畴了。

### playwright-mcp

`playwright-mcp` 是 Microsoft 官方出的浏览器自动化 MCP。它的强项是让 Agent 像人在浏览器里那样操作页面。

官方文档强调了几件事：

* 它基于 **accessibility tree** 工作，不依赖截图和视觉模型
* 可以点按钮、填表单、切标签页、截图、看网络请求
* 可以保存和恢复浏览器状态
* 默认支持持久化 profile

这意味着它特别适合有交互的网站：登录后台、点分页、开弹窗、验证表单、检查前端行为。

### 安装和使用方式

最标准的配置是：

```json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}
```

Claude Code 里也可以直接这样加：

```bash
claude mcp add playwright npx @playwright/mcp@latest
```

如果你要单独起 HTTP 服务，官方文档给的是：

```bash
npx @playwright/mcp@latest --port 8931
```

### 登录态、权限和误操作风险

这一类工具一定要单独说风险，因为它真的会"动页面"。

Playwright MCP 官方文档写明了三种 profile 模式，其中默认是 **persistent**。也就是说，登录态、cookie、本地存储会被保留下来。文档里还给了默认缓存目录和 `--user-data-dir` 覆盖方式。

这有两个直接影响：

1. **好处**：登录一次后，Agent 后面还能继续用这个会话。
2. **风险**：你实际给出去的是"带登录态的浏览器操作能力"。

另外，官方文档还明确提示 `browser_run_code_unsafe` 这类能力等价于执行任意 Playwright 代码，属于高风险配置。真要开，前提应该是你信任当前 MCP 客户端和当前任务。

### 使用场景

* 登录后台后抓数据
* 做带交互的页面调试
* 让 Agent 复现前端问题
* 需要保留登录态的长流程操作
* 自动填表、点击、多标签页检查

如果你的任务是"真实浏览器操作"，这一类比抓取类 MCP 更对路。

![Playwright MCP GitHub 预览图](https://gastigado.cnies.org/d/public/github-og-playwright-mcp.png)

### fetch-mcp

`fetch-mcp` 就轻得多。它不追求完整浏览器控制，也不想把整套抓取平台都搬进来。它做的是一件更朴素的事：把网页内容按不同格式取回来。

列出的工具包括：

* `fetch_html`
* `fetch_markdown`
* `fetch_txt`
* `fetch_json`
* `fetch_readable`
* `fetch_youtube_transcript`

这组能力很实用，因为很多 Agent 的真实需求只是"把这篇文章读干净"。`fetch_readable` 这类接口就是干这个的。

### 安装和使用方式

MCP 配置很简单：

```json
{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["mcp-fetch-server"]
    }
  }
}
```

它也支持直接当 CLI 用：

```bash
npx mcp-fetch markdown https://example.com
npx mcp-fetch readable https://example.com/blog/post
npx mcp-fetch youtube https://www.youtube.com/watch?v=dQw4w9WgXcQ --lang es
```

### 使用场景

* 读单篇文章或文档页
* 拉 API 返回的 JSON
* 去掉广告和导航，只保留正文
* 顺手取一段 YouTube 字幕

如果说 Firecrawl 是一整套采集工具，`fetch-mcp` 就像桌边的小扳手。

### Scrapling

Scrapling 本体是一个抓取框架，但它已经把 MCP 模式写进官方文档了。它把普通请求、动态抓取、隐身抓取、并发抓取、会话复用放进了同一个体系。

官方 MCP 文档列出的工具很完整：

* `get` / `bulk_get`
* `fetch` / `bulk_fetch`
* `stealthy_fetch` / `bulk_stealthy_fetch`
* `open_session` / `close_session` / `list_sessions`
* `screenshot`

Scrapling 很强调 **CSS selector**。网页元素选得越窄，后续 Agent 处理通常就越省 token。

### 安装和使用方式

官方文档里的安装步骤是：

```bash
pip install "scrapling[ai]"
scrapling install
```

跑 MCP 服务器时：

```bash
scrapling mcp
```

如果你要改成 HTTP 传输：

```bash
scrapling mcp --http --host 127.0.0.1 --port 8000
```

### 使用场景

* 目标站点很多，字段还比较固定
* 想用 CSS selector 先裁掉无关内容
* 同时需要普通请求、动态页面和带防护页面
* 要批量抓取，还要保留会话

### 还有两个细节

Scrapling 官方文档里有两个细节值得保留：

1. **Prompt injection protection**：它会在默认主内容提取路径里清理隐藏元素、注释、零宽字符等内容。
2. **Legal and Ethical Considerations**：官方文档单独提醒了 robots.txt、站点条款、版权和隐私问题。

它自己就没有把"能抓"写成"随便抓"。

### CloakBrowser

CloakBrowser 严格说不算独立的 MCP 服务器，它相当于给 Playwright、Puppeteer、Agent 浏览器栈换一层"浏览器底座"。把它放进这篇工具箱里，主要是因为很多浏览器类 MCP 迟早都要面对同一个问题：目标站点会不会把自动化流量直接拦掉。

它的官方材料里，核心卖点有三条：

* 号称通过 Chromium 源码级补丁处理指纹，而不是只在 JS 层做伪装
* 兼容 Playwright / Puppeteer 的常见 API
* 首次运行自动下载定制浏览器二进制

文档里还提供了 Python、Node.js、Docker 三种入口，以及一个 Browser Profile Manager。

### 安装和使用方式

最短安装命令是：

```bash
pip install cloakbrowser
```

或者：

```bash
npm install cloakbrowser playwright-core
```

跑 profile manager 的方式是：

```bash
docker run -p 8080:8080 -v cloakprofiles:/data cloakhq/cloakbrowser-manager
```

### 该怎么理解它的定位

CloakBrowser 更常见的用法是：

* 你已经在用 Playwright、Scrapling 或其他浏览器自动化链路
* 普通浏览器内核经常被目标站点风控
* 你愿意自己管理代理、会话、环境和合规问题

它不是"装上就万无一失"。项目自述里的通过率、检测站测试、reCAPTCHA 分数等说法，都可能随着目标站点、时间和代理质量变化。写得稳一点，可以把它理解成**偏隐身和指纹伪装的浏览器运行层**。

![CloakBrowser GitHub 预览图](https://gastigado.cnies.org/d/public/github-og-CloakBrowser.png)

## 联网搜索

### free-web-search-ultimate（仓库当前名为 zero-api-key-web-search）

free-web-search-ultimate 现已对应到 zero-api-key-web-search。这个项目主要解决的是 **给 Agent 补一条可验证的联网搜索链路**。

它不只提供搜索，还有：

* `zero-context`：整理可引用的上下文
* `zero-browse`：读页面
* `zero-verify`：验证说法
* `zero-report`：输出证据报告
* `zero-mcp`：直接起 MCP 服务

这让它和"普通 search tool"不太一样。它更强调 **证据归并** 和 **可引用结果**。

### 安装和使用方式

30 秒上手命令是：

```bash
pip install zero-api-key-web-search
zero-search "Python 3.13 release" --json
zero-context "Python 3.13 stable release" --goggles docs-first
zero-browse "https://docs.python.org/3/whatsnew/" --json
zero-verify "Python 3.13 is the latest stable release" --deep --json
```

作为 MCP 服务器时，配置可以写成：

```json
{
  "mcpServers": {
    "zero-api-key-web-search": {
      "command": "zero-mcp"
    }
  }
}
```

### 使用场景

* 搜，再把证据交给 Agent 写答案
* 给新闻、法规、版本信息做快速交叉核验
* 需要 citation-ready 的上下文，而不只是几条搜索结果

它在整条链路里承担的是"外网检索层"。浏览器执行通常还得交给别的工具。

## 清单 / 导航

### Awesome-MCP-ZH

`Awesome-MCP-ZH` 不是可执行服务器，就是一份给中文用户找项目用的路标。

这个仓库里不只收服务器，还收：

* MCP 基础文章
* 客户端
* 服务器分类清单
* 社区入口
* 相关课程和扩展资源

如果你已经知道自己要"抓网页"或者"连数据库"，当然可以直接搜具体项目；但如果你只是知道自己要给 Agent 补能力，还没想清楚该装哪类工具，翻这份清单更省时间。

### 使用场景

* 想找中文资料入口
* 想看某个场景有没有成熟替代品
* 想比较不同客户端和服务器
* 想扫一遍生态，再决定后面深挖谁

这类项目的作用是缩短"找工具"的时间。真要动手，还是要回到具体工具。

## 设计类 MCP

### MeiGen-AI-Design-MCP

MeiGen 这类项目和前面几组完全不同。它负责把图片和视频生成、设计提示词、灵感检索、工作流管理接给 Agent。

官方文档和仓库当前能对上的重点包括：

* 提供 8 个 MCP 工具
* 内置 1,446 条策展过的提示词
* 支持图片和视频生成
* 后端可接 MeiGen Cloud、OpenAI 兼容接口、本地 ComfyUI
* 支持 Claude Code、Cursor、Codex、Windsurf、Roo Code、OpenClaw、Hermes Agent 等宿主

它的定位就是"设计助理服务器"。

### 安装和使用方式

如果是装到 Cursor、VS Code、Windsurf、Roo Code，仓库提供的是一套统一命令：

```bash
npx meigen init cursor
npx meigen init vscode
npx meigen init windsurf
npx meigen init roo
```

如果你只是想直接用 CLI 出图：

```bash
export MEIGEN_API_TOKEN=meigen_sk_...
npx meigen gen --prompt "a calico cat in a sunlit kitchen"
npx meigen gen -p "tech logo" -m midjourney-v8.1 -r 1:1
```

通用 MCP 配置也可以直接手写：

```json
{
  "mcpServers": {
    "meigen": {
      "command": "npx",
      "args": ["-y", "meigen@1.3.1"],
      "env": {
        "MEIGEN_API_TOKEN": "meigen_sk_..."
      }
    }
  }
}
```

### 使用场景

* 让 Agent 做 logo、海报、产品图、短视频样片
* 用 prompt 库找参考方向
* 设计协作时批量出多个版本
* 本地有 ComfyUI，想把生成流程也挂进 Agent

### 隐私和数据处理

MeiGen 这一类项目最好把数据处理方式写清楚。

官方隐私说明当前写的是：

* **ComfyUI 本地模式**：处理留在本机
* **MeiGen Cloud**：提示词和参考图会发送到 `api.meigen.ai`
* **OpenAI-compatible**：数据会发送到你配置的上游接口
* **参考图上传**：默认经由 `gen.meigen.ai` / Cloudflare R2，官方写的是临时存储 24 小时
* **提示词检索和增强**：有一部分功能可以本地运行

别把它默认理解成本地工具。你用哪条后端，数据路径就跟着变。

![MeiGen GitHub 预览图](https://gastigado.cnies.org/d/public/github-og-MeiGen-AI-Design-MCP.png)

## 这一批项目怎么配合用

如果把这 9 个项目放到同一张桌上，会更容易看出它们的分层：

* **12306-mcp**：接具体业务服务
* **Firecrawl / Fetch / Scrapling**：读网页、提正文、做抓取
* **Playwright**：处理真实浏览器交互
* **CloakBrowser**：给浏览器自动化补隐身底座
* **zero-api-key-web-search**：补外网搜索和证据验证
* **Awesome-MCP-ZH**：找项目和找替代方案
* **MeiGen**：做设计和多媒体生成

一条常见链路大概是这样：

* 搜索入口：`zero-search`
* 正文读取：Firecrawl / Fetch
* 交互页面：Playwright
* 高风控站点：CloakBrowser
* 设计任务：MeiGen

工具装得越多，越需要想清楚任务类型。这样比"看见一个 MCP 就先加进配置"实用得多。

---

---
url: https://ain.hmgf.hxcn.space/ai/vibe-coding-common-skills-202605.md
description: >-
  从 skills.sh、Vercel、Vue、Svelte、Anthony Fu、Expo、Better Auth 到 UI 设计类 Skills，梳理
  AI 编程工作流里最值得先装、先学、先复用的那一批 Skill。
---

# Vibe Coding 常用 Skills

本文只讲 Skills；MCP 相关内容见第 02 篇《Vibe Coding 常用 MCP》。如果你现在最头疼的是“AI 明明会写代码，但每次做法都不一样”，把高频工作流沉淀成 Skill，往往比换模型更管用。

MCP 负责把模型接到外部数据和工具上，Skills 负责固定高频工作流。对 VibeCoding 来说，后者通常更快见效：你不用重新训练模型，也不用维护一长串全局系统提示词，只要把稳定流程、判断标准、脚本和参考资料装进 Skill 目录，AI 的出手就会稳很多。

## Skills 是一整个小工作流

Anthropic 的示例仓库对 Skill 的定义很明确：每个 Skill 都是一个自包含目录，核心文件是 `SKILL.md`。Vercel 的 `agent-skills` 文档也把结构写得很清楚：一个 Skill 至少有 `SKILL.md`，可选再带上 `scripts/`、`references/`、`assets/`。

一个常见的 Skill 目录，大概长这样：

```text
my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/
```

这四层各干什么，可以拆开看：

### `SKILL.md`：写范围、流程和触发条件

`SKILL.md` 是 Skill 的骨架。它通常包含两部分：

1. 顶部 YAML frontmatter，例如 `name`、`description`
2. 正文指令，例如什么时候用、怎么用、哪些步骤不能跳

像 Anthropic 的示例仓库、Expo 的 `upgrading-expo`、Better Auth 的 `better-auth-best-practices`，都在 `description` 里直接写明“什么时候该触发这个 Skill”。这一步很关键，因为范围越清楚，触发越稳定。

### `scripts/`：把稳定动作交给脚本，不占模型上下文

很多 Skill 的核心价值在脚本层。Vercel 文档直接把 `scripts/` 定义为可选的 helper scripts；`ui-ux-pro-max` 还带搜索脚本、模板和数据文件，让 AI 能查设计系统、找灵感、生成一致方案。

这也是 Skills 比“超长 Prompt”更划算的原因之一：脚本执行时，进入模型上下文的是结果，不会把整段脚本源码一并塞进去。

### `references/`：把官方资料、约束文档、反例一起打包

`references/` 是很多人第一次做 Skill 时最容易漏掉的地方。Svelte 那个 Skills 仓库写得很清楚：它采用 progressive disclosure，也就是先给快速参考，需要时再展开到详细文档。Expo 的 `building-native-ui` 甚至在 `references/` 里按主题拆了动画、控件、路由结构、原生标签页、视觉效果等专题文档。

这样一来，Skill 不只是在帮 AI 记结论，也把“去哪里翻资料”固定下来了。AI 遇到不确定的地方，可以按你指定的参考路径去找答案。

### `assets/`：模板、示意图、素材都可以跟着 Skill 走

有些 Skill 面向设计、演示、内容生成，这时 `assets/` 就很有用：你可以把模板、截图、配色卡、组件示例甚至品牌素材直接跟 Skill 放在一起。`ui-ux-pro-max` 这类工具链，就是把设计知识和设计素材一起打包。

## Skills 与上下文控制

Skills 的"渐进式披露"机制值得单独讲清楚。

它大致分三层：

1. **元数据层**：启动时只读 `name` 和 `description` 这类轻量信息。
2. **指令层**：只有当用户意图匹配时，才加载 `SKILL.md` 主体内容。
3. **资源层**：只有执行到某一步时，才去读 `references/` 或调用 `scripts/`。

Svelte 的 Skills 文档直接把这件事写成一句话：先给 quick references，再按需展开 detailed documentation。对日常 VibeCoding 来说，这个机制比“把所有规范塞进全局规则”更实用：

* 全局规则只保留最硬的底线
* 技术栈规范交给对应 Skill
* 某个任务不相关的资料，默认不进上下文

Skill 连上下文怎么装配，都提前规定好了。

## Skills 商店：发现、安装与阅读 `SKILL.md`

现在最常见的入口是 [skills.sh](https://skills.sh/)。它本身是一个开放目录，首页列出 Claude Code、Cursor、Codex、Windsurf、Cline、Gemini 等常见 Agent / IDE，说明 Skill 正在变成跨 Agent 的通用分发格式。

![skills.sh 首页截图](https://gastigado.cnies.org/d/public/skills-sh-home.png)

在本机实际运行 `npx skills --help` 时，当前 CLI 版本会显示 `add`、`remove`、`list`、`find`、`update` 等命令。四条高频命令仍然是最值得先记住的一组。

### `npx skills find <query>`：发现入口

```bash
npx skills find vercel
npx skills find expo
npx skills find better-auth
npx skills find design
```

这条命令适合三个场景：

* 你只知道需求，不知道仓库名
* 你知道仓库，但不知道里面具体有哪些 Skill
* 你想先确认生态里有没有现成方案，再决定要不要自建

实际跑出来的结果里，像 `vercel-labs/skills@find-skills`、`anthropics/skills@frontend-design`、`expo/skills@building-native-ui`、`better-auth/skills@better-auth-best-practices` 都能直接搜到。`find` 很适合放在选型第一步。

### `npx skills add <package>`：装整包，或者装单个 Skill

```bash
npx skills add vercel-labs/agent-skills
npx skills add better-auth/skills
npx skills add expo/skills@upgrading-expo
```

`add` 是安装入口，但它不只会装整个仓库。按 CLI 帮助，常见变体还有：

```bash
npx skills add vercel-labs/agent-skills --skill web-design-guidelines
npx skills add antfu/skills --skill='*' -g
npx skills add vercel-labs/agent-skills --agent codex cursor
```

什么时候该装整包，什么时候只装一个？经验很简单：

* **技术栈仓库**：先装整包，例如 Vue、Expo、Anthony Fu 的技能集
* **目标明确的单点需求**：只装单个 Skill，例如 `upgrading-expo`、`better-auth-best-practices`
* **多 Agent 共用**：考虑 `-g` 或指定 `--agent`

### `npx skills check`：扫描更新，适合做体检

```bash
npx skills check
```

这里有个细节值得记一下：当前 `skills --help` 顶层帮助更强调 `update`，但 `check` 这条命令仍然能跑。实际执行时，它会逐个扫描已安装 Skills，告诉你哪些有更新、哪些已经最新。

`check` 主要对应下面这些场景：

* 你装了一堆长期使用的 Skill，想先体检一遍
* 你不确定升级会不会影响团队工作流，先确认更新面板
* 你只想知道有没有变化，不想立刻动版本

### `npx skills update`：真正执行升级

```bash
npx skills update
npx skills update -g
npx skills update antfu
```

`check` 像体检，`update` 才是动手升级。它主要用在：

* 某个 Skill 已经确认有新版本
* 官方文档、框架 API 近期有变更
* 你想把团队里的 Skill 更新到同一代

在日常工作流里，一个很稳的顺序是：

```bash
npx skills find <query>
npx skills add <owner/repo@skill>
npx skills check
npx skills update
```

先发现，再安装，再看是否需要升级。这样做的好处是少装错，也少装一堆以后不用的东西。

## 开发类 Skills

这类 Skill 的共同点是：它们不会代替你写业务决策，但会把 AI 拉回某个技术栈已经验证过的路径。

### 1. Vercel：从 React 最佳实践一路管到 Web 设计审查

安装：

```bash
npx skills add vercel-labs/agent-skills
```

Vercel 这个仓库可以看成“前端工程审稿人集合”。它不是给一份笼统规范就结束，而是拆成多个可触发 Skill。`web-design-guidelines` 写得尤其具体：它会按 100+ 条规则审查 UI 代码，覆盖可访问性、焦点状态、表单、动画、排版、图片、性能、导航状态、暗色模式、触控交互和国际化。

这类 Skill 常见于下面这些场景：

* 你已经有了页面或组件
* 你怀疑 AI 生成的界面太糙、太像模板
* 你需要一个系统化的 UI 审查清单

Vercel 文档里还有一个很实用的点：它把 React Native / Expo 也纳进来了。这个仓库不只是在教 AI 写 React，也在教 AI **怎么遵守现代前端和跨端项目的约束**。

### 2. Vue：让 AI 按 Vue 的语法习惯做事

安装：

```bash
npx skills add vuejs-ai/skills
```

如果你常遇到“AI 明明会写前端，但总是把 Vue 写成 React 的影子”，那 Vue Skill 很适合先装上。

Vue 这一组技能把场景拆得很细：`vue-best-practices`、`vue-router-best-practices`、`vue-pinia-best-practices`、`vue-testing-best-practices`、`vue-debug-guides` 等都分开了。它会明确告诉 AI：

* Vue 3 + Composition API 应该怎么组织状态
* Router 的导航守卫、参数和组件生命周期怎么处理
* Pinia 怎么写更安全
* Vue 测试和 React 测试不是一回事

文档里还有一个实战味很重的细节：为了更稳定触发，它建议在提示词里直接说 `Use vue skill`。这提醒了一个常见误区：**有 Skill 不代表一定会触发，写清技术栈意图仍然很重要。**

### 3. Svelte：把“我记不住 runes 和 load 细节”这件事制度化解决

安装方式采用 clone / symlink 方案：

```bash
# 全局或项目级链接到技能目录
ln -s /path/to/svelte-claude-skills/.claude/skills/svelte5-runes ~/.claude/skills/
```

Svelte 这一组技能的特点是，它没有装成“万能 Svelte 专家”，而是围绕几个最容易犯错的主题拆开：

* `svelte5-runes`
* `sveltekit-data-flow`
* `sveltekit-structure`

文档还把验证状态写出来了，甚至标了最近一次核验日期和准确率。它特别强调 progressive disclosure：先给快速参考，需要时再展开详细文档。这很适合 Svelte 这种“概念不多，但每个细节都很容易踩坑”的框架。

如果你的 Agent 常把 `load`、`redirect()`、`error()`、布局分组这些概念写混，Svelte Skills 的作用很直接：它会减少那些已经有标准答案的错误。

### 4. Anthony Fu：把个人偏好、现代前端和官方文档混成一套可复用肌肉记忆

安装：

```bash
pnpx skills add antfu/skills --skill='*' -g
```

Anthony Fu 这个仓库很有代表性，因为它把两类东西放在了一起：

1. 他自己手工维护、带明确偏好的 Skill
2. 基于官方文档生成，再由他调过的 Skill

项目说明写得很坦白：这是一个偏 Vite / Nuxt / Vue 现代前端栈的一站式合集。你会同时看到 `antfu`、`vue`、`nuxt`、`pinia`、`vite`、`vitepress`、`pnpm`、`web-design-guidelines` 这些条目。

它的好处在于把一个现代前端工作流里的多个局部约束拼接起来。当你不想给 AI 写十几条分散的规则时，装一套成熟的技能集，通常比东拼西凑更稳。

### 5. Expo：把移动端细节提前写清楚

官方页面：[`expo.dev/expo-skills`](https://expo.dev/expo-skills)

这组 Skill 很适合移动端团队，因为 Expo 把“AI 最容易胡来的地方”直接做成了显式规范。

安装和发现可以从这几步开始：

```bash
npx skills find expo
npx skills add expo/skills@building-native-ui
npx skills add expo/skills@upgrading-expo
```

实际搜索时，`building-native-ui`、`native-data-fetching`、`expo-tailwind-setup`、`upgrading-expo` 都能直接搜到。

![Expo Skills 页面截图](https://gastigado.cnies.org/d/public/expo-skills-page.png)

这两个条目最常被拿来直接上手：

#### `building-native-ui`

这个 Skill 的正文很长，但中心思想很明确：**先按 Expo 原生能力做，再决定要不要自定义原生构建。**

它甚至在开头写了一个很工程化的提醒：

* 优先用 Expo Go 跑
* 只有真的需要本地模块、Apple targets 或第三方原生模块时，再跑 `npx expo run:ios/android` 或 `eas build`

这就是典型的 Skill 价值：它会提醒 AI 哪些时候不该提前复杂化。

#### `upgrading-expo`

这个 Skill 则把升级流程做成了 SOP。它会提醒你：

* 查看官方 release notes 和 SDK 迁移说明
* 再跑 `npx expo install expo@latest`
* 再跑 `npx expo install --fix`
* 然后用 `npx expo-doctor` 查问题
* 再按需要清缓存、预构建、检查 breaking changes

这类 Skill 在团队里很有复用价值，因为升级工作本来就是高风险、低容错、步骤稳定的任务。

### 6. Better Auth：把认证集成写成可检查流程

官方页面：[`better-auth.com/docs/ai-resources/skills`](https://better-auth.com/docs/ai-resources/skills)

安装时可以装整包，也可以只装单个技能：

```bash
npx skills add better-auth/skills
npx skills add better-auth/skills@better-auth-best-practices
```

实际搜索结果里，除了 `better-auth-best-practices`，还会看到 `create-auth-skill`、`email-and-password-best-practices`、`organization-best-practices`、`two-factor-authentication-best-practices` 等条目。

![Better Auth Skills 页面截图](https://gastigado.cnies.org/d/public/better-auth-skills-page.png)

`better-auth-best-practices` 这条 Skill 的写法很像一份认证接入清单：

1. 装包
2. 配 `BETTER_AUTH_SECRET` 和 `BETTER_AUTH_URL`
3. 建 `auth.ts`
4. 配路由处理器
5. 跑迁移命令
6. 用 `GET /api/auth/ok` 验证

它还会明确告诉 AI：

* CLI 会去哪些目录找 `auth.ts`
* 哪些配置项应该优先从环境变量读取
* 加插件后要重新跑迁移或生成步骤
* Prisma / Drizzle / MongoDB 适配器的用法不要混

这种 Skill 的价值，在于把认证集成里最容易漏的步骤前置成一份固定流程。

### 7. reverse-skill：逆向工程/渗透测试/安全研究技能路由包

安装：

```bash
git clone https://github.com/zhaoxuya520/reverse-skill.git
```

初次使用只需让 AI 阅读 `README_AI.md` 即可。

reverse-skill 是一个 AI 驱动的逆向工程、渗透测试和安全研究技能路由包。它通过一个 routing.md 文件，告诉 AI 遇到不同的安全任务该走哪条路，实现自动路由、按需自举工具链和自动进化经验库。

覆盖 20 多个子技能方向：APK 逆向分析、IDA 静态分析、JS 前端逆向、固件安全、EDR 绕过、漏洞利用等，基本上安全攻防常见场景都能覆盖。

这类 Skill 适合以下场景：

* 你需要对 APK、二进制文件、JS 加密等进行逆向分析
* 你正在进行授权的渗透测试或安全研究
* 你想让 AI 自动选择正确的逆向工程工具和方法
* 你需要一套可复用的安全分析工作流

该项目支持 Claude Code、Kiro、Cursor、Cline 等 AI 编码客户端。

## 设计与产品表达类 Skills

很多人第一次接触 Skill，会先想到技术栈。在 VibeCoding 里，设计类 Skill 同样重要。很多“AI 味”不出在代码能不能跑，而是出在页面像模板、排版像拼接、交互动效没有克制。

### 1. `ui-ux-pro-max`：一整套设计辅助工具链

安装方式和常见 skills.sh 仓库不太一样，它既支持 Claude Code marketplace，也有自己的 CLI：

```bash
/plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill
/plugin install ui-ux-pro-max@ui-ux-pro-max-skill

npm install -g uipro-cli
uipro init --ai codex
```

它和普通 Skill 最大的区别，是不只给你一份 `SKILL.md`。项目里还能看到搜索脚本、模板、数据文件和多平台安装入口，甚至能把设计系统搜索结果持久化。

它会给 AI 一个稳定的设计参照物来源。如果你的任务是做 Landing Page、Dashboard、定价页、品牌视觉统一，它比一句“做得更高级一点”有用得多。

### 2. `frontend-design`：把“不要写出 AI 审美”这件事写成约束

来源：[`anthropics/skills`](https://github.com/anthropics/skills) 仓库 + `skills.sh` 中的 `anthropics/skills@frontend-design`

在设计类 Skill 里，`frontend-design` 基本已经是最常被提到的那一个。它代表的是另一种约束方式：给“前端界面的整体质感”写清楚要求。

在实际工作流里，这种 Skill 适合接在需求之后、编码之前：

* 让 AI 先给出页面信息层级
* 再让 `frontend-design` 约束布局、密度、留白、字体、配色和组件节奏
* 再进技术栈级 Skill 去落实现

如果少了这一步，很多页面即使代码正确，也会停留在“能看但不想上线”的阶段。

### 3. `web-design-guidelines`：把 UI 审查从主观吐槽改成规则审计

虽然它已经在 Vercel 那节提过，但放到设计语境下还得再说一次，因为它最有用的场景在“审代码”这一步。

这条 Skill 的强项，是把很多平时会在评审会上散落出现的问题，收束成明确检查项：

* 语义化 HTML 和 aria
* 键盘可访问性
* 表单自动完成和错误提示
* `prefers-reduced-motion`
* 图片尺寸与懒加载
* 深色模式和主题色
* URL 是否反映界面状态

所以它特别适合在这几种场景里出手：

* 你已经有页面了，准备上线前做一轮 AI 审查
* 设计稿没问题，但落地实现质量不稳定
* 团队里前端水平参差不齐，需要一套统一检查表

把 `frontend-design` 和 `web-design-guidelines` 配合起来用，效果通常比只装其中一个好：前者更偏“生成时的审美约束”，后者更偏“实现后的规则审计”。

## 怎么判断一个 Skill 值不值得做

定制 Skill 时，最该先问的不是怎么写 prompt，而是这 6 件事：它解决哪个场景？处理流程怎么跑？输入输出是什么？要调用哪些工具？怎样算合格？它凭什么跑得比通用 AI 好？Skill 本质上是一套可复用的小工作流，不是一句"你是专家"。范围定清，流程写顺，数据喂准，工具接上，验收摆出来，再加上团队自己的判断和品味，才能让 Skill 真正稳定下来。

这六问可以直接拿来当筛选器：

### 1. 它解决哪个场景？

场景要具体到“谁在什么时候，反复遇到什么问题”。

* “做前端”太大
* “升级 Expo SDK 时总漏 breaking changes”就够具体
* “Better Auth 接入时总忘记验证 `/api/auth/ok`”也够具体

### 2. 处理流程怎么跑？

如果一件事每次顺序都不同，它通常还不适合做 Skill。

能做成 Skill 的工作，往往有稳定步骤，比如：搜文档 → 读参考 → 改配置 → 跑命令 → 做验证。Expo 升级、认证集成、UI 审查都属于这一类。

### 3. 输入输出是什么？

没有明确的输入输出，Skill 很容易失控。

比如 `web-design-guidelines` 的输入是现有 UI 代码，输出是审查意见；`upgrading-expo` 的输入是一个待升级项目，输出是升级步骤、风险点和验证清单。输入输出写清以后，AI 才不会把任务越做越散。

### 4. 要调用哪些工具？

如果工作流里一定要跑命令、读文件、查参考，那就别假装它只是 Prompt 问题。把命令、脚本、参考路径一起写进 Skill，复用价值才会出来。

### 5. 怎样算合格？

这是很多 Skill 最缺的一步。没有验收标准，Skill 只是“感觉更专业了”。

合格标准可以很朴素：

* 命令执行通过
* 页面无明显无障碍错误
* 升级后测试通过
* 接口返回指定结果
* 输出格式符合团队模板

### 6. 它凭什么比通用 AI 好？

这是最关键的判断标准。

如果一个任务只靠一句话就能让通用 AI 做得不错，那它未必值得专门做成 Skill。真正值得做的 Skill，通常至少满足下面一条：

* 你有一套私有判断标准
* 你有固定参考资料来源
* 你有稳定脚本或模板
* 你有明确验收口径
* 你不想让 AI 每次都重新猜

Skill 的价值，主要在于把团队判断固化下来。

## 落地路径：先装现成 Skill，再写团队 Skill

如果你今天就想开始，不用一上来就自己造一整套生态。可以按这个顺序动手：

### 第一步：用 `find` 找现成方案

```bash
npx skills find vue
npx skills find expo
npx skills find auth
npx skills find design
```

### 第二步：为高频场景安装代表 Skill

比如：

* Vue 项目先装 `vuejs-ai/skills`
* Expo 项目先装 `expo/skills@building-native-ui`
* 认证项目先装 `better-auth/skills@better-auth-best-practices`
* 设计审查先装 `vercel-labs/agent-skills@web-design-guidelines`

### 第三步：强制自己读一遍 `SKILL.md`

别把 Skill 当黑盒。至少要知道：

* 它什么时候触发
* 它会看哪些 references
* 它假设你已经装了哪些依赖
* 它会不会修改文件或执行命令

### 第四步：把复用率最高的团队流程自己写成 Skill

当前 CLI 帮助里已经有 `init`：

```bash
npx skills init my-team-skill
```

再结合 Anthropic 仓库里的模板思路，你就可以先做一个最小可用版本：

```markdown
---
name: release-checklist
description: 发布前检查构建、环境变量、回滚方案和验证链接。
---

# Release Checklist

## Steps
- 检查构建命令
- 检查环境变量
- 检查数据库迁移
- 检查回滚路径
- 输出验证清单
```

让它先管住一个窄场景，再逐步补 `references/`、`scripts/`、`assets/`。成熟的团队 Skill，往往就是从一个你每周都要重复做两三次的流程里长出来的。

## Skill 的长期价值

可以把 Skill 当成团队的可复用工作说明书，只是这次执行说明书的人换成了 Agent。

一个流程如果已经稳定到适合交给同事，通常也适合写成 Skill。

---

---
url: https://ain.hmgf.hxcn.space/ai/skills-ecosystem-202605.md
description: >-
  从 Skills 商店、mattpocock/skills 到
  repomix、follow-builders、codex-plusplus、keep-codex-fast、nuwa-skill、dbskill、taste-skill、academic-research-skills、matlab-agentic-toolkit、paper-plot-skills，整理一条更实用的
  Skills 生态观察线。
---

# Codex / Claude Skills 生态观察

下面按入口、方法论仓库、索引、代码库打包、信息订阅、桌面补丁、会话维护、中文项目和领域专用技能几层往下看。

一些社区讨论里高频提到的经验：

* `handoff` 最近用得越来越多，是目前最高频使用的 Skill。Codex 上下文一长，返回速度明显下降，不只是界面卡顿，而是模型返回慢。GPT 模型上下文相比其他模型更小，所以长任务到 70% - 80% 时就用 handoff 把当前对话压缩成 handoff 文件，然后新开 session 继续，速度快很多，避免自动压缩。新的 `/goal` 模式可能也是类似原理。
* Matt Pocock Skills：82.5k stars，18 个技能，专治 AI 写代码翻车。技能包括 `/grill-me`、`/tdd`、`/caveman`、`/improve-codebase-architecture`。
* 5 个 Codex 必装 Skill 工具：awesome-codex-skills、repomix、follow-builders、codex-plusplus、keep-codex-fast。

## Skills 商店：入口组织

很多人第一次接触 Skills 生态，通常不会急着挑某一个仓库，而会先找“哪里能批量看、批量装”。

`aitmpl.com/skills` 背后对应的是 Claude Code Templates 这一套目录系统。官方文档首页把它定位成一组可直接安装的 Claude Code 配置集合，组件分成 agent、command、MCP、settings、hooks 和 skills 六类。文档首页还有一组数据：交互目录里可浏览 900+ agents、225+ commands、65+ MCPs、60+ settings、45+ hooks、2700+ skills。

该站点提供按组件类型筛选、统一视图和统一安装方式。

它解决的是三个问题：

* 你不用一个仓库一个仓库翻，能先按组件类型筛；
* 你能把 skill 和 command、hook、MCP 放在同一视图下看；
* 安装方式统一，官方给的是 `npx claude-code-templates@latest` 或 `npx cct@latest`。

它承担技能市场和索引入口的角色。

## mattpocock/skills：把工程习惯写成可触发的技能

Matt Pocock 的 **Skills For Real Engineers** 覆盖四类高频问题：需求没问透、语言不统一、反馈循环太弱、代码库越做越乱。仓库中的技能围绕这四类问题分布。

### 它在修哪四个故障

文档列了四类常见失败模式：

1. Agent 没做出你想要的结果；
2. Agent 说得太长、项目术语太乱；
3. 代码写出来但没有可靠反馈；
4. 项目很快长成一团泥球。

这四类问题，对应的是一组具体 skill：

* `/grill-me`、`/grill-with-docs` 负责把需求问透；
* `CONTEXT.md` 一类共享语言文档负责压缩表达；
* `/tdd` 和 `/diagnose` 把反馈循环拉进来；
* `/improve-codebase-architecture`、`/zoom-out`、`/to-prd` 负责长期维护。

从这些 skill 能看出作者依赖的工程语言：The Pragmatic Programmer、DDD、XP、A Philosophy of Software Design，这些都不是装饰，已经直接进了技能结构。

### `/grill-me`：需求澄清

GitHub：<https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me>

本地归档的 `SKILL.md` 写得很干脆：持续追问计划或设计，沿着设计树一支一支往下问，每个问题都给推荐答案，而且一次只问一个问题。

这个 Skill 的价值，在于把“需求澄清”从聊天气氛变成流程。

很多人以为 agent 表现差，是因为提示词不够狠。`/grill-me` 走的是另一条路：不开工之前，把接口、约束、优先级和依赖关系问清楚。常见场景有：

* 接手一个模糊需求时；
* PRD 还没写清就想让 agent 开工时；
* 你自己也知道方案里还有很多洞时。

### `/tdd`：把测试前置成一个稳定循环

GitHub：<https://github.com/mattpocock/skills/tree/main/skills/engineering/tdd>

`/tdd` 的 `SKILL.md` 不只是在喊 red-green-refactor。它把一个常见误区写得非常清楚：别一口气把所有测试写完再去补实现；那会变成“横向切片”，最后只剩一堆验证想象中行为的测试。

它推荐的是 vertical slices，也就是一条一条 tracer bullet 往前走：

```text
RED -> 写一个行为测试
GREEN -> 只写能让它通过的最小代码
重复 -> 再写下一个行为
```

放在真实仓库里，它尤其有用，因为它不讲测试口号，直接约束 agent 的工作节奏。你让模型从一口气实现 12 个需求，变成一次只做一段可验证行为，返工率通常会低很多。

### `/caveman`：把上下文开销降下来

GitHub：<https://github.com/mattpocock/skills/tree/main/skills/productivity/caveman>

`/caveman` 的定位也很明确：压掉 filler、article、pleasantries，在保持技术准确性的前提下把沟通体积砍掉，大约能省 75% token。

它更像一个很实用的会话控制手段。尤其在 Codex 长任务里，冗长回复会直接抬高上下文成本。看它的规则就知道，这个 Skill 完全是按执行场景设计的：

* 尽量用短词；
* 技术术语不改；
* 允许碎句；
* 风险说明和不可逆操作时短暂退出 caveman 模式，再恢复。

它适合长链路开发、debug 和多轮修补，不太适合第一次解释复杂背景。

### `/handoff`：把长会话压成连续性交接文件

GitHub：<https://github.com/mattpocock/skills/tree/main/skills/productivity/handoff>

`handoff` 在本地归档的 `SKILL.md` 里只有几行，但正因为短，意思反而很清楚：把当前对话压成 handoff 文档，交给新的 agent 继续；PRD、ADR、issues、diff 里已有的内容直接引用路径，不再重复展开；如果用户给了后续目标，就按后续目标定制 handoff。

这和社区里高频使用经验是对得上的：长任务跑到 70% - 80% 上下文时，用 handoff 压缩当前对话，再开新 session，速度会快很多。这个“为什么好用”，文档没有直接写性能，但从 skill 结构能推出来：它把上下文里最重、最分散的执行信息，变成了一个短文档和一组显式引用。

关于 `/goal`，这里要把来源层级分开说：

* 社区讨论里提到新的 `/goal` 模式可能和 handoff 类似；
* 当前环境里的 goal 工具接口和 oh-my-codex 对 goal mode 的使用说明是可核对的一手材料；
* 按目前能核到的材料，`/goal` 也在做线程级目标管理和状态收束，和 handoff 一样都在处理长会话失速；至于两者是否基于同一原理，现有公开材料还不足以下结论。

### `/improve-codebase-architecture`：把“重构”变成可讨论的架构工作

GitHub：<https://github.com/mattpocock/skills/tree/main/skills/engineering/improve-codebase-architecture>

这个 skill 很能说明作者的工程取向。

它先规定一组术语：module、interface、implementation、depth、seam、adapter、locality、leverage，再让 agent 提重构建议。然后让 agent 读项目里的 `CONTEXT.md` 和 ADR，去找“浅模块”“泄漏 seam”“缺 locality”的地方，最后把候选项按文件、问题、方案、收益列出来，等用户选一个再继续追问。

它的价值，在于把“感觉这里有点乱”改成“这里的 interface 太浅，删除测试不成立，复杂度没被吃进去”。一旦术语稳定，后续讨论、命名和 PR 解释都会顺很多。

### 安装方式

文档给的 quickstart 只有两步：

```bash
npx skills@latest add mattpocock/skills
```

然后在安装过程中勾选你要装的 skill，并且确保选上 `/setup-matt-pocock-skills`。这个 setup skill 会继续问 issue tracker、triage label、文档保存位置这些配置。

如果你平时已经在用 Codex、Claude Code 这类 agent，这套安装方式几乎没有额外门槛。

### 长期价值

仓库中的技能共享同一套术语体系，涵盖 DDD、XP 等工程方法。

## awesome-codex-skills：把分散技能重新编目

`awesome-codex-skills` 是一份 curated list，按五大类组织。

仓库一开头就写得很明确：这是一份 **curated list of practical Codex skills**，面向 Codex CLI 和 API 的工作流自动化。它把内容分成五大块：

* Development & Code Tools
* Productivity & Collaboration
* Communication & Writing
* Data & Analysis
* Meta & Utilities

对应“开发代码、生产力、写作、数据分析、实用工具 5 大部分的 Skill 合集”，这部分能直接在仓库首页核对。

### 索引仓库好用在哪

第一，它给了统一安装方式。推荐做法是克隆仓库，再运行 skill installer，把指定 skill 安到 `$CODEX_HOME/skills`。

```bash
git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python skill-installer/scripts/install-skill-from-github.py --repo ComposioHQ/awesome-codex-skills --path meeting-notes-and-actions
```

第二，它会帮你快速认识生态分层。你可以很快看出哪些 skill 偏工程，哪些偏写作，哪些偏分析，哪些已经开始接进 Slack、Notion、Linear 这类真实外部系统。

第三，它自己还内置了 `skill-creator`、`template-skill`、`skill-installer` 这些元工具。也就是说，它不只是列目录，也在教你怎么继续扩展目录。

### 别拿它替代什么

该仓库是纯索引，不包含统一的方法论。

## repomix：把整个仓库打包成 AI 友好的单文件

`repomix` 在 Skills 生态里很特殊，因为它本身不是 Skill 仓库，却几乎成了很多 Skill 工作流的基础设施。

`repomix` 的标题很直接：**Pack your codebase into AI-friendly formats**。它干的事，就是把整个仓库收束成一个 AI 更容易吞下去的单文件，同时给出 token count、include / exclude 控制、`.gitignore` / `.repomixignore` 兼容，以及 `--compress` 这类压缩手段。

最小用法也很短：

```bash
npx repomix@latest
```

或者全局安装后直接运行：

```bash
npm install -g repomix
repomix
```

默认产物是 `repomix-output.xml`。你可以把它交给模型做整体代码审查、架构阅读、重构建议，或者作为 handoff 的外部上下文文件。

### 常被归为“必装”的原因

因为很多长任务的瓶颈根本不在 agent 本身，而在“怎么把代码库交给 agent”。

如果仓库太大，agent 会不断扫文件、反复读目录、重复调用工具。`repomix` 的作用，是在会话开始前就把仓库压成一个更稳定的输入物。它不负责解决所有理解问题，但它能减少大量机械遍历。

### star、奖项和营销说法怎么处理

仓库说明还能核到一条信息：它在 **JSNation Open Source Awards 2025 的 Powered by AI 分类获得提名**。来源是仓库自述和仓库里链接出去的活动页信息，不能往上扩成“获奖”。

当前 star 约 **24,933**，正文按 2026-05-16 的本地快照写。

## follow-builders：把 AI 观察清单做成定时摘要

前面几项偏工程，这一项偏信息输入。

仓库标题就叫 **Follow Builders, Not Influencers**。它把自己定义成一套 AI-powered digest：追踪研究员、创始人、PM、工程师这些“真在做东西的人”，把他们的 X、播客和官方博客内容整理成日更或周更摘要，发到 Telegram、Discord、WhatsApp 甚至 email。

### 它具体抓什么

文档能核到三类源：

* 6 档 podcast；
* 25 个 AI builders 的 X 账号；
* 2 个官方博客，分别是 Anthropic Engineering 和 Claude Blog。

仓库还给了 `examples/sample-digest.md`。从样例可以直接看出产物格式：先播客，再 X / Twitter，每条都带 bottom line、关键 insight 和原文链接。

它是一条稳定的信息输入管道。对经常做 AI 产品、经常看 agent 生态的人来说，它能把分散订阅拉回到一个固定格式。

### 安装和使用方式

文档给的是很轻的聊天式 setup：

* 把 skill 安到 agent；
* 直接说 “set up follow builders” 或触发 `/follow-builders`；
* 然后回答频率、语言、投递方式。

它还特别强调：内容抓取在中心侧完成，你本地不需要再配置一堆 API key。这个设计属于“订阅服务 + 本地 skill 壳层”。

## codex-plusplus：给 Codex 桌面版打补丁和加扩展层

这是另一个很容易被误解的项目。它是 **Codex 桌面 app 的 tweak / patch 系统**。

项目说明写得很清楚：给本地 Codex.app 打一个 loader，让运行时和 tweak 模块从用户目录加载，再把 Tweaks 面板注入到 Codex 设置页里。这样做的好处是，后续你写 tweak、开关 tweak、改 tweak，都不用重打整个 app。

### 它能干什么

项目列出来的核心能力包括：

* 给 Codex 注入 tweak manager；
* 加载外部 tweak 模块；
* 修桌面版 UI bug；
* 自带状态检查、修复、更新、safe mode；
* Windows 上会复制 Microsoft Store 版 Codex 到可写目录，再打补丁。

安装方式也给得很全：Homebrew、Bun、shell bootstrap、PowerShell 都有。

```bash
brew install b-nnett/codex-plusplus/codexplusplus
codexplusplus install
```

或者：

```bash
bun install -g github:b-nnett/codex-plusplus
codexplusplus install
```

### 它在 Skills 工作流里的位置

它更偏“宿主环境增强”。

如果你每天都在用桌面版 Codex，希望加自定义快捷键、实验 tweak、边改边看 app 表现，`codex-plusplus` 的位置就很靠前。它解决的是宿主体验问题，不在 agent 能力本身。

## keep-codex-fast：handoff 与归档维护

`keep-codex-fast` 和前面的 `handoff` 能连得很紧。

它开头就把使用场景写清楚了：当 Codex 在长时间使用后，累积了 chats、terminals、logs、worktrees、project history，本地状态开始变重，这个 skill 提供一套安全的检查和维护流程。

它的规则也写得很清楚：

> Make handoffs first. Archive, don't delete. Apply changes only when you are ready.

### 维护流程怎么跑

文档把模式分成三段：

* Inspect：只报告，不写；
* Maintain：备份、归档旧会话、搬 stale worktrees、轮转 logs、清理 dead config；
* Optional repair：只在显式传 `--repair-thread-metadata-bloat` 时，才修复超大的 thread title / preview metadata。

最重要的是，它没有把“清理”写成直接删。文档一直在强调：

* handoff 要走在归档前面；
* 动手前必须备份；
* archive instead of deleting；
* Codex 正在运行时不要动本地状态。

该 Skill 将确认、备份和归档步骤整合到了清理流程中。

### 它与 handoff 的关系

因为 handoff 解决的是“怎么把重上下文压成连续性交接文件”，`keep-codex-fast` 解决的是“压完之后怎么安全地把旧负担归档”。两者合起来，才是一条完整维护链。

仓库自带的流程图和提示文案也说明了这一点：聊天是执行面，handoff docs 是记忆面，archives 是历史面，fresh threads 才是速度面。

![Keep Codex Fast 流程图](/ai/assets/skills-ecosystem/keep-codex-fast-flow.svg)

## nuwa-skill：方法论、人格和产品感一起打包

`nuwa-skill` 放在这里，是想看清“结构、判断、流程、产品感”是怎么一起打包的。

`nuwa-skill` 的核心主张：把乔布斯、芒格、费曼、马斯克、Naval 这种人的认知框架蒸馏成可调用 skill。重点不在人设，而在把他们的判断模式整理成可用的分析路径。

### nuwa-skill 的识别度

它不只是一个人设 prompt。示例里能看出几个固定动作：

* 用户给出问题；
* skill 先回到这个人的核心认知框架；
* 输出里会稳定复现那套框架的判断顺序；
* 最终产物有明显的风格一致性。

能看出来，被压缩进去的是“思维模型 + 表达习惯 + 使用场景”。

从 Skill 设计角度说，这类项目的难点不在文采，而在筛选。到底蒸馏什么、不蒸馏什么，哪些句子是风格，哪些句子只是口头禅，这背后都需要作者判断。

## dbskill：把商业诊断做成多技能工具箱

`dbskill` 是另一个产品感很强的中文项目。

仓库一开头就说得很具体：从 12,307 条推文中提炼方法论，做成 17 个 Agent skill，可装在 Claude Code、Codex、Cursor、Trae Solo 等支持 skill / system prompt 的 agent 上。它还带状态管理三件套：`/dbs-save`、`/dbs-restore`、`/dbs-report`。

### dbskill 做对了什么

它不止有一个主 skill，而是把整套诊断工作拆成了工具箱：

* `dbs-diagnosis` 做商业模式诊断；
* `dbs-benchmark` 做对标分析；
* `dbs-content` 做内容创作诊断；
* `dbs-hook`、`dbs-xhs-title` 这种针对具体内容环节；
* `dbs-goal` 负责把模糊愿望改写成可检查目标；
* `dbs-save`、`dbs-restore`、`dbs-report` 负责连续状态。

这一组已经是产品工具箱式的拆法，不靠“一个 prompt 干所有事”。它让你看到 Skill 的另一种成熟方向：主入口负责路由，子技能负责专门工序，状态管理技能负责跨会话连续性。

### 它和上面那些工程类 skill 有什么共同点

都在把"下次还要重复做的判断和流程"固化下来。`mattpocock/skills` 固化的是软件工程流程，`dbskill` 固化的是商业诊断流程。领域不一样，设计逻辑很接近。

## taste-skill：给 AI 生成的前端注入设计品味

`taste-skill` 的定位很直接：**Anti-Slop Frontend Framework for AI Agents**。它解决的是 AI 生成前端界面时最常被吐槽的问题——Inter 字体、紫色渐变、白色背景、最少动画，看起来像从同一个模板里出来的。

### 它在修什么故障

AI 生成的前端界面有一个结构性问题：模型倾向于采样训练数据中出现频率最高的设计选择，这些"安全"选择放之四海而皆准，但也毫无个性。`taste-skill` 把这个问题叫 **distributional convergence**（分布收敛），并提供了一套可调参数来打破它。

### 三个可调旋钮

`taste-skill` 的核心设计是三个 1-10 的旋钮：

* **DESIGN\_VARIANCE**：布局实验性（低：居中/干净 · 高：不对称/现代）
* **MOTION\_INTENSITY**：动画深度（低：hover · 高：scroll/magnetic）
* **VISUAL\_DENSITY**：每视口信息密度（低：宽敞 · 高：密集仪表盘）

这三个旋钮让开发者可以精确控制 AI 生成界面的风格方向，而不是每次都在提示词里写"不要用 Inter 字体"。

### 多个变体覆盖不同场景

仓库不只提供一个 skill，而是按场景拆成了多个变体：

* **taste-skill**（`design-taste-frontend`）：默认 v2 实验版，读取简报、推断设计语言、调整三个旋钮
* **gpt-taste**：面向 GPT/Codex 的更严格变体，更高的布局方差、更强的 GSAP 方向
* **image-to-code-skill**（`image-to-code`）：图像优先管道——生成站点参考图、分析、再实现前端
* **redesign-skill**（`redesign-existing-projects`）：面向已有项目——先审计 UI，再修复布局、间距、层级、样式
* **soft-skill**（`high-end-visual-design`）：精致、冷静、昂贵的 UI，柔和对比、留白、高级字体、弹性动效
* **minimalist-skill**（`minimalist-ui`）：编辑式产品 UI（Notion/Linear 风格），克制配色、清晰结构
* **brutalist-skill**（`industrial-brutalist-ui`）：硬机械语言：瑞士排版、尖锐对比、实验布局

还有图像生成类 skill（`imagegen-frontend-web`、`imagegen-frontend-mobile`、`brandkit`），只产出设计参考图，不写代码。

### 安装方式

```bash
npx skills add https://github.com/Leonxlnx/taste-skill
```

装单个 skill：

```bash
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
```

### 它在 Skills 生态里的位置

`taste-skill` 属于**方法论产品层**，但它专攻的是前端设计审美这个垂直方向。和 `mattpocock/skills` 比，它不是通用工程方法论，而是专门解决"AI 生成的界面太像模板"这个问题；和 `frontend-design`（Anthropic 官方 Skill）比，它提供了更细粒度的风格控制和更多变体选择。

它展示了 Skills 的又一个成熟方向：**把设计品味参数化**。不只是告诉 AI"做得好看一点"，而是把布局实验性、动效深度、信息密度这些维度拆开，让开发者按需调节。当前 star 约 23k。

## academic-research-skills：把学术研究全流程做成 AI 协作管道

`academic-research-skills` 回答了另一个问题：学术研究这种高度结构化、多阶段、需要严格质量控制的工作，怎么和 AI 协作。

仓库标题很直接：**Academic Research Skills for Claude Code**。它不是单个 skill，而是一整套覆盖从研究到出版全流程的技能套件，包含 4 个核心技能、25+ 种模式、10 阶段管道编排器。

### 它在解决什么问题

学术研究有几个结构性难点：

1. **引用幻觉**：Zhao et al. (2026) 审计了 250 万篇论文中的 1.11 亿条引用，保守估计 2025 年有 146,932 条幻觉引用；
2. **框架锁定**：验证 AI 和生成 AI 共享同一个认知框架，导致 devil's advocate 只攻击论点不攻击前提；
3. **讨好式退让**：用户一 pushback，AI 就收回攻击，训练奖励的是对话和谐而非真理追求；
4. **意图误判**：探索性对话和目标导向对话需要完全不同的 AI 行为，但模型经常分不清。

ARS 的设计前提是：**人类研究者 + AI 增强，比任何一方单独工作都能更好地避免这些失败模式**。

### 四个核心技能

**Deep Research（13 个 agent）** — 7 种研究模式：完整研究、快速摘要、系统综述（PRISMA）、苏格拉底引导式、事实核查、文献综述、研究质量审查。苏格拉底模式包含意图检测层：每 3 轮对话自动分类用户意图是探索性还是目标导向，探索性模式下禁用自动收敛、最大轮次提升到 60、禁止"要我总结吗"这类提前关闭。

**Academic Paper（12 个 agent）** — 10 种写作模式：完整写作、引导式规划、仅大纲、修订、修订教练、仅摘要、文献综述、格式转换、引用检查、AI 披露声明。内置 Style Calibration（从你过去的作品学习你的写作风格）和 Writing Quality Check（捕捉让文字感觉是机器生成的模式）。

**Academic Paper Reviewer（7 个 agent）** — 6 种审查模式：完整审查（EIC + 3 个审稿人 + devil's advocate）、快速评估、引导式改进、方法论聚焦、修订验证、校准模式。使用 0-100 质量评分标准，决策映射：≥80 接受，65-79 小修，50-64 大修，<50 拒稿。

**Academic Pipeline（10 阶段编排器）** — 从研究到出版的完整管道：Stage 1 研究 → Stage 2 写作 → Stage 2.5 完整性验证 → Stage 3 同行评审 → Stage 3' 修订后复审 → Stage 4 作者回应 → Stage 4.5 最终完整性验证 → Stage 5 格式化 → Stage 6 过程总结。每个阶段都需要用户确认检查点，完整性验证（Stage 2.5 和 4.5）不可跳过。

### v3.0 的关键优化：对抗 AI 的结构性缺陷

**Devil's Advocate 让步阈值协议**：DA 必须对每个反驳评分 1-5 分，只有评分 ≥4（反驳直接针对核心攻击并有证据）才允许让步。反讨好规则：不允许连续让步、跟踪让步率、每个检查点后检测框架锁定。

**苏格拉底导师意图检测层**：在对话开始时和每 3 轮后分类用户意图。探索模式：禁用自动收敛、最大轮次提升到 60、禁止"要我总结吗"提示。目标导向模式：标准收敛行为。

**苏格拉底导师对话健康指标**：每 5 轮静默自评三个维度：持续同意、冲突回避、过早收敛。检测到同意模式时自动注入挑战性问题。对用户不可见（防止博弈），但日志可用于会话后审查。

### 安装和使用

```bash
# Claude Code 插件安装（推荐，30 秒）
/plugin marketplace add Imbad0202/academic-research-skills
/plugin install academic-research-skills

# 验证：运行 /ars-plan 描述你要写的论文
# 或单次测试：/ars-lit-review "your topic"
```

成本方面，完整管道写一篇 15k 字论文约 $4-6。支持 APA 7.0、Chicago、MLA、IEEE、Vancouver 引用格式，支持 IMRaD、主题文献综述、理论分析、案例研究、政策简报、会议论文等结构。

### 它在 Skills 生态里的位置

该仓库覆盖了从研究到出版的全流程。和 `mattpocock/skills` 比，它不是通用工程技能，而是专攻学术研究这一个垂直领域；和 `dbskill` 比，它的管道编排更复杂（10 阶段 vs 工具箱式），质量控制更严格（完整性验证不可跳过、引用三层锚定、声明审计）。

它还展示了 Skills 的另一个成熟方向：不只是把判断和流程固化，而是把**质量门控和反幻觉机制**也固化进去。Stage 2.5 和 4.5 的完整性验证会检查 7 种 AI 研究失败模式，引用系统要求每条引用都带三层锚定（引用、页码、章节），声明审计会获取被引来源并判断是否真正支持论点。

## Auto-Empirical-Research-Skills：23000+ 社科实证研究技能库

斯坦福 REAP 联合 CoPaper.AI 开源的社科实证研究技能库，23000+ 个 Agent skills 覆盖经济、政治、社会、心理等 8 大学科。项目定位很直接：**20 分钟完成一篇可复现的规范实证论文**。

### 它在解决什么问题

传统实证研究流程极其漫长：选题 → 扒文献 → 洗数据 → 因果识别 → 稳健性检验 → 画表 → 写正文，一套下来两三个月起步。Auto-Empirical-Research-Skills 把顶尖研究员的方法论打包成可直接调用的 Skill，从选题到投稿一气呵成。

### 覆盖学科

* 经济学（Economics）
* 政治学（Political Science）
* 社会学（Sociology）
* 心理学（Psychology）
* 教育学（Education）
* 公共管理（Public Administration）
* 国际关系（International Relations）
* 传播学（Communication）

### 它在 Skills 生态里的位置

和 `academic-research-skills` 比，它不走通用学术研究管道，而是专攻社科实证这一个垂直领域；规模上 23000+ skills 远超 ARS 的 4 个核心技能，但每个 skill 更轻量、更碎片化。

它展示了 Skills 的又一个方向：**领域专家方法论的规模化蒸馏**。不是把一个研究者的判断打包，而是把整个学科的方法论体系编码成可调用的 skill 库。

## paper-plot-skills：顶会论文图表复现绘制技能库

`paper-plot-skills` 解决的是学术论文写作中另一个高频问题：论文图表的复现和绘制。仓库标题很直接：**Top-Conference Paper Figure Reproduction & Plotting Skills | 顶会论文图表复现绘制Skills**。它提供了一套完整的顶会论文图表复现脚本和参数文档，帮助研究者快速绘制高质量的论文图表。

### 它在解决什么问题

学术论文图表绘制有几个结构性难点：

1. **复现困难**：顶会论文中的图表往往使用特定的样式、配色和布局，手动复现耗时且容易出错；
2. **样式不统一**：不同论文的图表风格差异大，缺乏标准化的绘制流程；
3. **参数复杂**：matplotlib 等绘图库的参数众多，调整一个图表可能需要反复试验；
4. **效率低下**：每次绘制新图表都从零开始，无法复用已有的样式和配置。

`paper-plot-skills` 的设计前提是：**把顶会论文的图表样式标准化、参数化，让研究者可以快速复现和定制**。

### 两大核心模块

**plot-from-data** — 从数据生成图表。提供多种图表类型的复现脚本和参数文档：

| 图表类型 | 样式 | 来源论文 | 特点 |
|----------|------|----------|------|
| `bar_paired_delta` | 柱状图 | MemEvolve | 配对柱 + 增益箭头，serif 字体 |
| `bar_grouped_hatch` | 柱状图 | SPICE | 分组柱 + 填充纹理 |
| `line_confidence_band` | 折线图 | Self-Distillation | EMA 平滑 + 置信区间阴影，LaTeX 字体 |
| `line_training_curve` | 折线图 | DAPO | 垂直断点线 + 水平参考线，sans-serif |
| `line_loss_with_inset` | 折线图 | SiameseNorm | L 形 spine + 轴端箭头 + 右侧 zoom inset |
| `scatter_tsne_cluster` | 散点图 | - | t-SNE 聚类可视化 |
| `scatter_broken_axis` | 散点图 | - | 断轴散点图 |
| `radar_dual_series` | 雷达图 | DoRA | 双系列雷达/蜘蛛图对比 |

**plot-from-image** — 从图片复现图表。提供从论文图片提取数据并复现的脚本。

### 安装和使用

```bash
# 克隆仓库
git clone https://github.com/Trae1ounG/paper-plot-skills.git
cd paper-plot-skills

# 使用示例：绘制 MemEvolve 风格的配对柱状图
python plot-from-data/scripts/bar_memevolve.py

# 使用示例：绘制 Self-Distillation 风格的置信区间折线图
python plot-from-data/scripts/line_selfdistill.py
```

每个图表样式都有对应的参数文档，位于 `plot-from-data/references/` 目录下，详细说明了可调参数和使用方法。

### 它在 Skills 生态里的位置

`paper-plot-skills` 属于**领域专用工具层**，专攻学术论文图表绘制。和 `academic-research-skills` 比，它不覆盖研究全流程，而是聚焦在论文写作中的图表绘制这一个垂直环节；和 `Auto-Empirical-Research-Skills` 比，它不涉及社科实证研究方法论，而是提供通用的论文图表绘制工具。

它展示了 Skills 的又一个方向：**把专业领域的视觉表达标准化**。不只是告诉 AI"画一个柱状图"，而是把顶会论文的图表样式、配色、字体、布局等细节参数化，让研究者可以快速复现高质量的论文图表。

对学术研究者来说，这个工具的价值在于：你不用再花时间调整 matplotlib 的各种参数，也不用担心图表风格不符合顶会标准。直接使用复现脚本，修改数据即可生成符合顶会风格的图表。

## matlab-agentic-toolkit：把 MATLAB 工程能力接入 AI Agent

`matlab-agentic-toolkit` 是 MathWorks 官方出品的 AI Agent 工具包，解决的问题很直接：AI 编码助手在写 MATLAB 代码时容易幻觉出不存在的工具箱函数、遗漏新特性、用非惯用写法绕路。这个工具包通过 MCP 服务器 + 领域 Skills 两层结构，把可信的 MATLAB 能力交给 Agent。

### 它在修什么故障

工程和科学计算场景有几个结构性难点：

1. **函数幻觉**：Agent 常常编造不存在的 MATLAB 函数或工具箱 API，尤其在专业工具箱（如 RF Toolbox、SimBiology）领域；
2. **惯用法缺失**：MATLAB 有自己的一套编程惯例（向量化、Live Script 格式、App Builder 模式），通用模型往往用 Python 思维写 MATLAB；
3. **工具箱盲区**：MATLAB 有 100+ 工具箱，Agent 不可能全部记住，需要按需加载领域知识；
4. **验证困难**：工程代码需要实际运行验证，不能只靠静态分析。

### 两层架构

**MCP 服务器层** — 自动安装 [MATLAB MCP Core Server](https://github.com/matlab/matlab-mcp-core-server)，提供 5 个核心工具：

| 工具 | 功能 |
|------|------|
| `evaluate_matlab_code` | 运行 MATLAB 代码并返回命令窗口输出 |
| `run_matlab_file` | 运行 MATLAB 程序文件 |
| `run_matlab_test_file` | 通过 `runtests` 运行测试并返回结构化结果 |
| `check_matlab_code` | 静态分析（Code Analyzer） |
| `detect_matlab_toolboxes` | 列出已安装的 MATLAB 版本和工具箱 |

**Skills 层** — 按领域组织的 14 组技能，覆盖从核心编程到专业工程领域：

* **MATLAB Core**：调试、代码审查、测试、Live Script 创建、产品安装
* **MATLAB Software Development**：代码现代化、性能优化、性能测试
* **MATLAB Data Import and Analysis**：表格数据分析
* **MATLAB App Building**：基于 uifigure 的 App 程序化构建
* **Automotive**：RoadRunner 地图格式转换、场景导入
* **Computational Biology**：SimBiology 模型构建与仿真
* **Image Processing and Computer Vision**：图像显示、3D 体数据、OCR
* **RF and Mixed Signal**：S 参数分析、PCB 布局、射频电路设计、阻抗匹配（这个方向最细，有 30+ 个 skill）
* **Robotics and Autonomous Systems**：GNSS 定位、惯性传感器融合
* **Signal Processing**：数字滤波器设计
* **Wireless Communications**：5G 波形生成、GNSS 波形生成、AWGN 信道建模
* **Test and Measurement**：OPC UA 服务器发现
* **Reporting and Database Access**：Databricks JDBC、DuckDB、ORM、数据库读写

### 支持的 Agent

官方支持 5 种 AI 编码 Agent：Claude Code、GitHub Copilot、OpenAI Codex、Gemini CLI、Sourcegraph Amp。安装方式统一：

```bash
git clone https://github.com/matlab/matlab-agentic-toolkit.git
cd matlab-agentic-toolkit
# 然后让 Agent 执行：Set up the MATLAB Agentic Toolkit
```

### 它在 Skills 生态里的位置

这是 MathWorks 官方维护的 MATLAB 领域 Skills 产品。和 `academic-research-skills` 比，它不是社区项目，而是 MathWorks 官方维护；和 `mattpocock/skills` 比，它不是通用工程方法论，而是专攻 MATLAB + 工具箱这一个垂直领域。

它展示了 Skills 的又一个成熟方向：**厂商把自己的产品知识蒸馏成 Agent 可消费的结构**。MathWorks 把 100+ 工具箱的 API 用法、最佳实践、反模式压缩成按领域分组的 Skill，让 Agent 在写 RF 电路代码时不会幻觉出不存在的函数，在做 SimBiology 仿真时知道该用哪种求解器。

对工程和科学计算领域的用户来说，这个工具包的价值在于：你不用再花时间纠正 Agent 的 MATLAB 语法错误，也不用担心它推荐的函数在你的工具箱版本里不存在。

## reverse-skill：逆向工程/渗透测试/安全研究技能路由包

`reverse-skill` 是一个 AI 驱动的逆向工程、渗透测试和安全研究技能路由包。它通过一个 routing.md 文件，告诉 AI 遇到不同的安全任务该走哪条路，实现自动路由、按需自举工具链和自动进化经验库。

### 它在修什么故障

安全攻防场景有几个结构性难点：

1. **工具选择困难**：面对 APK、ELF、JS、PCAP 等不同目标，AI 不知道该用 jadx、Frida 还是 IDA；
2. **工具链分散**：工具路径、MCP 服务、脚本入口分散在不同机器，迁移困难；
3. **经验无法复用**：同样的问题每次重新踩坑，经验无法沉淀。

### 覆盖场景

覆盖 20 多个子技能方向：APK 逆向分析、IDA 静态分析、JS 前端逆向、固件安全、EDR 绕过、漏洞利用、CTF 竞赛等，基本上安全攻防常见场景都能覆盖。

### 安装与使用

```bash
git clone https://github.com/zhaoxuya520/reverse-skill.git
```

初次使用只需让 AI 阅读 `README_AI.md` 即可。该项目支持 Claude Code、Kiro、Cursor、Cline 等 AI 编码客户端。

### 它在 Skills 生态里的位置

`reverse-skill` 属于**领域专用方法论层**，专攻逆向工程和安全研究这一个垂直领域。和 `mattpocock/skills` 比，它不是通用工程方法论，而是专门解决安全攻防场景中的工具选择和流程标准化问题；和 `academic-research-skills` 比，它覆盖的是安全研究而非学术研究。

它展示了 Skills 的又一个方向：**安全攻防方法论的 AI 路由化**。通过将安全专家的经验编码成路由矩阵，让 AI 在面对不同安全任务时能自动选择正确的工具和方法，降低安全攻防的门槛。

## book-to-skill：把技术书籍变成可调用的 Skill

`book-to-skill` 解决的是另一个问题：你买了一本很好的技术书，读了一遍，三个月后连第 7 章讲什么都不记得了。

仓库标题很直接：**Turn any technical book PDF into a Claude Code skill**。它做的事，就是把 PDF、EPUB、DOCX 等格式的技术书籍转换成结构化的 Claude Code skill，让书里的知识变成可按需加载的工作流组件。

### 它在修什么故障

传统 workaround 都有缺陷：

* 搜 PDF：得到的是页码列表，不是答案；
* 问 Claude：要么幻觉，要么说没有内容；
* 做笔记：200 行文档再也不会打开。

`book-to-skill` 的做法是**编译时提取**，不是运行时检索。它一次性深度分析书籍，提取作者的框架、命名、使用场景、反模式，生成结构化的 skill 文件。当你问问题时，Claude 不是在做关键词匹配，而是在用预提取的思维模型做推理。

### 生成产物

运行 `/book-to-skill your-book.pdf` 会在 `~/.claude/skills/<slug>/` 生成：

* `SKILL.md`：核心思维模型 + 章节索引（~4,000 tokens）
* `chapters/ch01-*.md`：每章一个文件，按需加载（~1,000 tokens/章）
* `glossary.md`：关键术语表，按字母排序带章节引用
* `patterns.md`：所有技术、算法、设计模式
* `cheatsheet.md`：决策表和快速参考规则

**章节文件按需加载**——不问到那章，就不占 token 预算。

### 和 RAG 的区别

RAG 在查询时工作：切块 → 嵌入 → 找相似向量 → 注入 prompt。优化的是"找到讲 X 的部分"。

`book-to-skill` 在编译时工作：一次深度分析提取作者的框架，命名每个框架，描述何时使用，捕捉反模式。输出的是作者花多年构建的结构，不是对句子的相似性搜索。

RAG 回答："这些是和你查询接近的片段。"
Skill 回答："这是作者构建的 12 个框架，可以用来推理。"

跨 50 本书搜索，RAG 赢。深度使用一本书的框架并嵌入工作流，skill 赢。

### 安装和使用

```bash
# 一键安装
mkdir -p ~/.claude/skills/book-to-skill/scripts
curl -o ~/.claude/skills/book-to-skill/SKILL.md \
  https://raw.githubusercontent.com/virgiliojr94/book-to-skill/master/SKILL.md
curl -o ~/.claude/skills/book-to-skill/scripts/extract.py \
  https://raw.githubusercontent.com/virgiliojr94/book-to-skill/master/scripts/extract.py

# 使用
/book-to-skill ~/Downloads/designing-data-intensive-applications.pdf
/book-to-skill ~/books/clean-code.epub clean-code

# 之后就可以这样用
/designing-data-intensive-apps replication    # 查找并解释某个主题
/designing-data-intensive-apps ch05           # 深入第 5 章
```

支持 PDF、EPUB、DOCX、TXT、Markdown、HTML、RTF、MOBI 等格式。PDF 提取会问你是技术书籍还是纯文本——技术书籍用 Docling（保留表格和代码块，~1.5s/页），纯文本用 pdftotext（瞬间完成）。

### 它在 Skills 生态里的位置

`book-to-skill` 属于**知识转换层**。和 `repomix` 把代码库压成单文件类似，它把书籍压成结构化 skill。但方向不同：`repomix` 压缩的是代码仓库的结构，`book-to-skill` 压缩的是知识框架。

它也和 RAG 形成互补：RAG 适合跨大量文档搜索，`book-to-skill` 适合深度使用一本书。如果你有 10 本核心技术书想嵌入日常工作流，这个工具能把"书架"变成"工具箱"。

## text-to-cad：CAD / 机器人 / 硬件设计的 Agent Skills 库

`text-to-cad`（项目名 CAD Skills）是一套面向 CAD 建模、机器人描述文件和硬件设计的 Agent Skills 库。当前 star 约 7,463，支持从自然语言或图片生成 STEP、STL、3MF、GLB 等格式的 CAD 模型，并覆盖 URDF、SDF、SRDF 等机器人描述文件和 G-code 切片等下游工作流。

### 它在修什么故障

硬件设计和机器人开发场景有几个结构性难点：

1. **建模门槛高**：传统 CAD 建模需要掌握 SolidWorks、Fusion 360 等专业工具的操作逻辑，非机械背景的开发者很难快速产出零件；
2. **格式碎片化**：STEP、STL、3MF、DXF、URDF、SDF 等格式各有用途，格式转换和验证流程分散；
3. **上下游断裂**：建模、切片、打印、仿真验证通常是割裂的工具链，中间需要大量人工衔接。

### 11 个 Skills 覆盖完整硬件工作流

| Skill | 功能 |
|-------|------|
| **CAD** | 从自然语言或图片创建和编辑 CAD 模型，STEP 为主输出，支持导出 STL、3MF、GLB |
| **CAD Viewer** | 本地浏览器预览 CAD、G-code 和机器人文件 |
| **step.parts** | 查找现成的 STEP 零件（螺丝、轴承、电机、连接件等） |
| **DXF** | 从 Python 源或 CAD 几何体生成 2D DXF 图纸（轮廓、模板、垫片、切割排料） |
| **URDF** | 编写机器人结构文件（links、joints、limits、inertials、meshes） |
| **SRDF** | 为 URDF 添加 MoveIt 规划组、末端执行器、位姿和碰撞规则 |
| **SDF** | 创建仿真模型和世界文件（坐标系、物理参数、传感器、光源） |
| **SendCutSend** | 上传前检查 DXF 和 STEP 文件的可制造性 |
| **G-code** | 将网格文件切片为带打印机配置验证的 FDM `.gcode` |
| **Bambu Labs** | 拓竹打印机工作流：试跑、上传、启动打印 |
| **Implicit CAD** | 使用 GLSL 有符号距离场在浏览器中渲染隐式 CAD 模型（实验性） |

### 安装方式

推荐使用 Skills CLI 安装：

```bash
npx skills install earthtojake/text-to-cad
```

也支持 Codex 和 Claude Code 原生插件安装：

```bash
# Codex
codex plugin marketplace add earthtojake/text-to-cad
codex plugin add cad@text-to-cad

# Claude Code
claude plugin marketplace add earthtojake/text-to-cad
claude plugin install cad@text-to-cad
```

### 它在 Skills 生态里的位置

`text-to-cad` 属于**领域专用工具层**，专攻 CAD 建模和机器人硬件设计。和 `next-ai-draw-io`（图表生成）比，它处理的是工程级三维几何体而非流程图；和 `matlab-agentic-toolkit`（MATLAB 工程计算）比，它聚焦的是从建模到打印的物理制造链路而非数值计算。

它展示了 Skills 的又一个成熟方向：**把专业工程工具链封装成 Agent 可调用的工作流**。从"画一个带四个孔的校准块"到生成 STEP 文件、切片 G-code、上传打印机，整个流程可以在一个 Agent 会话内完成。

## next-ai-draw-io：AI 驱动的专业绘图工具

next-ai-draw-io 是一个基于 Next.js 的 AI 绘图应用，将大语言模型与 draw.io 深度集成。项目斩获 32.5k stars，曾登顶 GitHub 热榜第一。

### 核心能力

* **自然语言生成图表**：一句描述即可生成架构图、流程图、思维导图等专业图表
* **图片转图表**：上传手绘草图或现有图表照片，AI 自动转化为规范的正式图表
* **PDF/文本提取**：上传 PDF 文档和文本文件，从现有内容生成图表
* **交互式修改**：通过聊天界面实时调整图表，支持版本历史回溯
* **云端架构图**：专门支持 AWS、GCP、Azure 云架构图生成
* **动画连接器**：创建动态连接线，增强可视化效果

### MCP Server 集成

next-ai-draw-io 提供 MCP Server，可直接接入 Claude Desktop、Cursor、VS Code 等 AI agent：

```json
{
  "mcpServers": {
    "drawio": {
      "command": "npx",
      "args": ["@next-ai-drawio/mcp-server@latest"]
    }
  }
}
```

Claude Code CLI 安装：

```bash
claude mcp add drawio -- npx @next-ai-drawio/mcp-server@latest
```

安装后直接对 Claude 说"创建一个用户认证流程图"，图表会实时显示在浏览器中。

### 多模型支持

支持 15+ 模型提供商：ByteDance Doubao、AWS Bedrock、OpenAI、Anthropic、Google AI、Azure OpenAI、Ollama、DeepSeek 等。推荐使用 Claude Sonnet 4.5、GPT-5.1、Gemini 3 Pro 等强模型，其中 Claude 系列对 draw.io XML 格式和云架构图标支持最佳。

### 部署方式

* **在线体验**：<https://next-ai-drawio.jiang.jp/>（支持自带 API Key）
* **桌面应用**：Windows / macOS / Linux 原生客户端
* **Docker**：一键容器化部署
* **Vercel / Cloudflare Workers**：Serverless 部署

### 它在 Skills 生态里的位置

next-ai-draw-io 属于**领域专用工具层**，专攻图表生成这一个垂直方向。它通过 MCP Server 接入 AI agent 生态，让"一句话画架构图"变成 agent 的原生能力。

和 `taste-skill`（前端设计品味）比，它不生成代码，而是生成 draw.io XML；和 `repomix`（代码库压缩）比，它处理的是视觉表达而非代码结构。它的价值在于把"画图"这个高频但低效的工作流，变成了 AI agent 的一等公民。

## 回到整体生态

Skills 生态可以分为七层：

1. **商店 / 索引层**：`aitmpl.com/skills`、`awesome-codex-skills`；
2. **方法论产品层**：`mattpocock/skills`、`nuwa-skill`、`dbskill`、`taste-skill`（前端设计品味参数化）；
3. **领域专用方法论层**：`academic-research-skills`（学术研究全流程）、`Auto-Empirical-Research-Skills`（社科实证研究）、`matlab-agentic-toolkit`（MATLAB 工程计算全流程）、`reverse-skill`（逆向工程/渗透测试/安全研究技能路由包）；
4. **领域专用工具层**：`next-ai-draw-io`（AI 绘图）、`paper-plot-skills`（学术论文图表复现绘制）；
5. **知识转换层**：`book-to-skill`（书籍→skill）；
6. **输入压缩层**：`repomix`、`handoff`；
7. **宿主增强和维护层**：`follow-builders`、`codex-plusplus`、`keep-codex-fast`。

各仓库的定位如下：

* `mattpocock/skills` 是通用工程方法论仓库；
* `taste-skill` 专攻前端设计审美，把布局、动效、密度参数化；
* `next-ai-draw-io` 专攻 AI 绘图，通过 MCP Server 接入 agent 生态；
* `paper-plot-skills` 专攻学术论文图表复现绘制，提供顶会论文图表的复现脚本和参数文档；
* `repomix` 和 `keep-codex-fast` 属于基础设施层；
* `follow-builders`、`nuwa-skill`、`dbskill` 面向不同职业场景；
* `academic-research-skills` 覆盖学术研究全流程；
* `Auto-Empirical-Research-Skills` 是斯坦福 REAP 的社科实证研究方案，23000+ skills；
* `matlab-agentic-toolkit` 是 MathWorks 官方的 MATLAB 领域方案；
* `reverse-skill` 是逆向工程和安全研究的 AI 路由技能包；
* `book-to-skill` 将技术书籍转换为结构化 skill；
* `awesome-codex-skills` 和 `aitmpl.com/skills` 提供长尾技能索引。

## 资料来源

* `aitmpl.com/skills` 官方文档：<https://docs.aitmpl.com/introduction>
* `mattpocock/skills` README 与 `handoff`、`grill-me`、`caveman`、`tdd`、`improve-codebase-architecture` 的 `SKILL.md`
* `ComposioHQ/awesome-codex-skills` README
* `yamadashy/repomix` README 与官网 <https://repomix.com>
* `zarazhangrui/follow-builders` README 与 `examples/sample-digest.md`
* `zhaoxuya520/reverse-skill` README 与 `README_AI.md`
* `b-nnett/codex-plusplus` README
* `vibeforge1111/keep-codex-fast` README
* `alchaincyf/nuwa-skill` README
* `dontbesilent2025/dbskill` README
* `Imbad0202/academic-research-skills` README 与 `docs/ARCHITECTURE.md`、`docs/SETUP.md`、`docs/PERFORMANCE.md`
* `brycewang-stanford/Auto-Empirical-Research-Skills` README
* `matlab/matlab-agentic-toolkit` README 与 `skills-catalog/README.md`
* `virgiliojr94/book-to-skill` README 与 `SKILL.md`
* `Leonxlnx/taste-skill` README 与 `tasteskill.dev`
* `DayuanJiang/next-ai-draw-io` README
* `Trae1ounG/paper-plot-skills` README
* GitHub 仓库快照：`docs/ai/references/skills-ecosystem/stats-2026-05-16.md`

---

---
url: https://ain.hmgf.hxcn.space/ai/how-to-design-good-skills-202605.md
description: >-
  从 ianneo_ai 的六问出发，结合 Anthropic 的 skills 结构，拆开场景、流程、输入输出、工具、验收与默认判断，说明一个 Skill
  怎样从提示词长文变成稳定工作流。
---

# 怎么设计一个真正有用的 Skill

> （<https://x.com/ianneo_ai/status/2054890888766373926>）定制 Skill，一上来就在写 prompt？大错特错！其实真正该问的是这 6 件事：它解决哪个场景？处理流程怎么跑？输入输出是什么？要调用哪些工具？怎样算合格？它凭什么跑得比通用 AI 好？Skill 不是一句你是专家，而是一套可复用的小工作流。边界定清，流程写顺，数据喂准，工具接上，验收摆出来，最后再加一点你的判断和品味，这才像给自己雇了一个稳定同事啊。定 Skill 先问场景流程，别急着写 prompt。这 6 件事问完，Skill 才算有灵魂。最后那句"加一点你的判断和品味"太真实了，通用 AI 缺的往往就是这点主观边界。重复性高的工作都适合做成 Skill。

这段话已经把问题说得很到位：Skill 要压缩的是重复工作流程。

为了把这六问落到一手资料上，同时参考了两个官方仓库：

* `anthropics/skills`：一个专门收集技能结构和最佳实践的仓库；
* `anthropics/claude-code` 里的 plugin-dev skill-development：更贴近 Claude Code 插件 / skill 开发的示例。

从这两套资料里能看出来，成熟 Skill 的核心在组织方式：`SKILL.md` 负责触发条件和主流程，`scripts/` 负责确定性动作，`references/` 放长文说明，`assets/` 放模板或素材。下面就按六问往下拆。

## 第一问：它解决哪个场景

Skill 设计最容易犯的错，就是场景写成领域。

比如"做前端""写科研""做运营"都只是范围。能落成 Skill 的场景，通常还要再具体一点：

* 把一篇长文改成站内正式文章；
* 给现有仓库补一份 handoff 文档；
* 读一组日志后做结构化诊断；
* 把 PDF 资料转成 Markdown 并归档图片；
* 跑一次代码评审并输出 fix list。

`anthropics/skills` 仓库里反复强调的一点，就是 description 要写清楚 **when to trigger**。说白了，就是逼你把场景写窄。Skill 关心的是"当用户遇到哪类任务时，触发这套流程"。

### 场景写到什么程度才算够

一个简单办法是看这三个问题：

1. 用户会在什么时刻想调用它？
2. 输入材料通常长什么样？
3. 结果交付出来后，用户拿它做什么？

如果这三个问题答不出来，场景大概率还太虚。

### 场景写清楚后会是什么样

下面这个写法就比"写一个代码优化 Skill"清楚得多：

```text
场景：仓库已经能跑，但目录结构开始变乱；用户想找出哪几个模块最该先整理，并给出可执行的重构候选项。
```

写到这个程度，已经能看出它对应的是 `improve-codebase-architecture` 这一类 Skill，不再是泛泛一句"帮我优化代码"。

## 第二问：处理流程怎么跑

GitHub：<https://github.com/anthropics/skills/tree/main/skills/skill-creator>
文档：<https://github.com/anthropics/claude-code/tree/main/plugins/plugin-dev/skills/skill-development>

场景定下来之后，第二件事是把流程写顺。

流程不是目录树，也不是功能清单。流程是 agent 真正执行任务时要走的步骤序列。一个成熟 Skill 往往会把下面几类阶段写清楚：

* 读哪些材料；
* 要补问什么；
* 什么时候运行脚本；
* 什么时候停下来等用户；
* 什么时候给出产物；
* 如果失败，回退到哪里。

`anthropics/skills` 里的 `skill-creator` 明确推崇 progressive disclosure，这意味着流程不能一触发就把所有材料全部灌进上下文，而要按步骤加载。只有流程顺了，Skill 才不会一触发就变成长篇 dump。

### 流程怎么拆

最常见的拆法是四段：

1. **收集**：读输入、补上下文；
2. **判断**：决定走哪条子路径；
3. **执行**：调用脚本、生成草稿、修改文件；
4. **收口**：验收、列风险、给后续步骤。

比如一个"把研究资料整理成文章"的 Skill，可以写成：

```text
1. 读取相关材料和目标文件。
2. 判断这篇文章属于单项目介绍、多项目整理还是翻译整合。
3. 归档仓库说明、官网材料和本地原文，再起正文。
4. 写完后执行一轮去 AI 味和 copy-editing 自检。
5. 输出修改文件、来源概况和待回访问题。
```

这个流程一旦写清楚，后续同类文章就能反复跑。

## 第三问：输入输出是什么

输入输出不清楚，Skill 很快就会"好像做了很多，结果没人能接"。

### 输入要写到什么粒度

至少要分四类：

* **用户口头输入**：一句目标、补充偏好、约束；
* **文件输入**：Markdown、HTML、PDF、代码库、数据表；
* **环境输入**：当前目录、已安装工具、可用 MCP；
* **对话输入**：上一个步骤生成的中间结果。

很多 Skill 失控，问题就出在这里。它只写"用户给我资料"，没有写资料可以是哪几种，也没有写缺资料时怎么办。

### 输出也要写成交付物

输出别只写"给出结果"。应该写成用户能拿去下一步继续工作的东西，比如：

* 写入哪个文件；
* 返回哪种格式；
* 是否附来源列表；
* 是否要给状态记录字段；
* 是否需要截图、归档、脚本产物。

例如：

```text
输出：
- docs/ai/xxx.md 正文
- docs/ai/references/xxx/ 下的仓库说明 / official / x-reference / source-notes
- docs/ai/assets/xxx/ 下的本地图片
- 最终回执：文件列表、资料来源、待回访问题、状态字段
```

一旦写到这个粒度，Skill 的交付范围就会稳定很多。

## 第四问：要调用哪些工具

Skill 真正和普通提示词拉开差距，往往就在工具层。

`anthropics/skills` 与 Claude Code 的示例都默认了一个前提：Skill 可以调脚本、读引用资料、操作文件系统，必要时再接外部工具。这一点很关键，因为只靠自然语言说明，很多重复任务根本不稳。

### 工具层最常见的四类组件

1. `scripts/`：适合放确定性步骤，比如批量重命名、提取图片、跑校验；
2. `references/`：放需要按需读取的长文说明、规范、对照表；
3. `assets/`：放模板、示意图、封面、表格样板；
4. 外部工具：CLI、MCP、API、本地程序。

比如 PDF 处理类 Skill，工具层就可能长成这样：

```text
pdf-to-markdown/
├── SKILL.md
├── scripts/
│   ├── extract-images.py
│   └── fix-line-breaks.py
├── references/
│   └── formatting-rules.md
└── assets/
    └── article-template.md
```

这比把所有规则全塞进 `SKILL.md` 里稳定得多，也更省上下文。

### 什么情况该上工具，什么情况不用

一个实用判断标准是：它是否需要**可重复、可核验、少歧义**。

* 需要，就优先脚本化；
* 不需要，就留在自然语言流程里。

比如"帮我判断这段文字更像摘要还是导语"，这类就不必写脚本；但"把 30 张图片改名并移动到目标目录"，就很适合脚本。

## 第五问：怎样算合格

很多 Skill 看着很聪明，实际最弱的地方就是没有验收条件。

没有验收，agent 往往会把"我觉得差不多了"当完成；一旦跨会话、跨项目，这种模糊完成状态就特别容易出事故。

### 验收至少要有三层

1. **格式层**：文件有没有写到指定路径，代码块有没有标语言，链接是否可点；
2. **内容层**：是否覆盖所有必写项目，是否保留原文链接，是否区分官方资料和社区讨论；
3. **结果层**：这份产物能不能直接进入下一步，比如发布、交接、复核、构建。

例如文章类 Skill 的验收可以写成：

```text
- 正文已写入指定文件。
- references 目录已保存仓库说明 / official / x-reference / source-notes。
- 正文覆盖全部关键点，且不比原文更简略。
- 仓库介绍小节标题下已放 GitHub / 官网 / 文档直链。
```

只要这类清单存在，Skill 的稳定度就会上去。

### 验收别只写"高质量"

"高质量""专业""详细"都不是验收条件，因为它们不可直接检查。

更有用的写法是：

* 至少列出 3 个关键失败模式；
* 给出 1 组可执行命令；
* 保留全部非 `t.co` 链接；
* 修改路径不得超出 ownership。

这已经接近工程里 definition of done 的写法。

## 第六问：凭什么比通用 AI 好

第六问才轮到"判断和品味"。

Skill 和通用 AI 的差别，不在规则多少，而在默认取舍是否稳定。你要能说清楚：

* 为什么这条流程比临场发挥更稳；
* 哪些判断我不想每次都重新做；
* 哪些默认值体现了作者经验；
* 失败时该保守到什么程度。

### "判断和品味"到底落在哪

它通常落在这些地方：

* 默认优先读一手资料，社区转述只做补充；
* 目录写法固定，不让 agent 自己发明结构；
* 缺资料时先停下来标注来源层级，不乱补事实；
* handoff 放在 archive 前面；
* 文章里项目顺序按真实工作流，不按营销热度排。

这些看起来都不大，却直接决定 Skill 质量。用户为什么觉得某个 Skill 像"稳定同事"，往往就是因为这些默认值靠谱。

### 通用 AI 已经会做，为什么还要做 Skill

因为通用 AI 会做，不等于每次都按同一标准做。

一个好 Skill 的意义，是把"偶尔做对一次"变成"在这个场景里大概率持续做对"。它把你最不想反复解释的那部分经验，前移到结构里。

## 一个可直接复用的 Skill 设计草稿

下面这份草稿，可以直接拿去起手写新 Skill：

```markdown
---
name: your-skill-name
description: 说明这个 skill 解决什么具体场景，以及何时触发。
---

# 这个 Skill 解决什么问题

- 目标场景：
- 典型输入：
- 典型输出：
- 不适用场景：

# 工作流程

1. 读取材料：
2. 选择路径：
3. 执行任务：
4. 验收结果：

# 工具与资料

- scripts/：
- references/：
- assets/：
- 外部工具 / MCP / CLI：

# 验收标准

- 文件路径：
- 内容覆盖：
- 风格 / 格式要求：
- 风险与回退：

# 作者默认取舍

- 优先级：
- 保守策略：
- 何时停下来问用户：
```

这份草稿不华丽，但够用。把这六块写清楚，再去打磨 prompt 细节，顺序会稳很多。

## 资料来源

* ianneo\_ai 原帖：<https://x.com/ianneo_ai/status/2054890888766373926>
* `anthropics/skills`：<https://github.com/anthropics/skills>
* `skill-creator`：<https://github.com/anthropics/skills/tree/main/skills/skill-creator>
* `anthropics/claude-code` plugin-dev skill-development：<https://github.com/anthropics/claude-code/tree/main/plugins/plugin-dev/skills/skill-development>
* 本地归档：`docs/ai/references/how-to-design-good-skills/`

---

---
url: https://ain.hmgf.hxcn.space/ai/vibe-coding-learning-path-202605.md
description: 从中文入门教程、工具型教程、项目上线、上下文工程到 Harness 工程，整理一条适合新手逐步推进的 Vibe Coding 学习路线。
---

# Vibe Coding 入门路线

很多人一接触 Vibe Coding，第一反应都是去找"最强 prompt"或者"最火工具"。这样未必错，但很容易学得很散：今天看一个 Cursor 技巧，明天看一个 Codex 视频，后天又去追 Agent 新闻，读到最后还是不知道该从哪里下手。

按真实开发会发生的顺序往前走，会省很多弯路。

这条路线可以分成四段：做出一个小东西，学怎么把项目上线，补上下文工程，最后去看 Harness 工程，理解怎样让 Agent 在真实仓库里稳定工作。按这个顺序走，资料再多也不容易乱。

这篇就按这条线往下排：**入门工具教程 → 项目上线 → 上下文工程 → Harness 工程**。

## Vibe Coding 对新手有什么用

Vibe Coding 对新手最大的帮助，是把"能不能开始"这件事大幅前置了。

以前很多人卡在环境、语法、框架选型，还没做出第一个页面就放弃了。现在你只要会描述需求，就已经能和 Claude Code、Codex、Lovable、Cursor 这类工具一起把原型做出来，至少把想法变成一个可见、可点、可测试的东西。

但这不等于责任消失了。

你还是得判断需求有没有价值，得知道功能顺序怎么排，得知道什么时候继续问 AI，什么时候自己验证，什么时候把东西部署出去给别人用。Vibe Coding 降低的是启动门槛，判断、调试和交付并没有消失。

所以这条路线要解决的是三种实际能力：

* 能从零开始做出一个可运行的小项目；
* 能把项目从"本地能跑"推进到"别人能访问"；
* 能在项目变复杂之后，继续稳住上下文、任务和验证流程。

## 找一条入门入口

这一段聚焦中文和零基础友好的材料，重点是找到自己的起步方式。

### easy-vibe：零基础学习地图

[`datawhalechina/easy-vibe`](https://github.com/datawhalechina/easy-vibe) 的首页写得很直接：如果你会说话，就可以开始做应用。

把它放在第一站，主要因为两点。

第一，它的结构很像"学习地图"。项目说明里有很明确的学习路径分流：

* 想先快速体验一次 AI 编程是什么感觉；
* 想把想法做成一个产品原型；
* 想继续往全栈产品、部署、支付、后端流程走；
* 想进入更高级的 Claude Code 和 agent workflow。

另外，它没有停在"AI 会做什么"这一层，还把不同阶段该学什么拆开了。项目说明里能看到从游戏化理解 AI、到学习地图、到全栈项目、到 Stripe 支付和微信小程序后端流程的延伸。这对新手很重要，因为很多所谓零基础教程只停在"做一个页面"，`easy-vibe` 明显想把人继续往项目推进。

如果你是完全零基础，可以读它的在线文档和 learning paths，再按自己的情况选路径：

* 想建立信心，就走"fast first win"；
* 想把 idea 变 demo，就走 prototype 路线；
* 想做 web app，就往 full-stack products 那条读。

这比一开始就埋进某个工具的参数细节更稳。

### vibe-vibe：更完整的系统教程，适合继续补上"从想法到产品"

[`datawhalechina/vibe-vibe`](https://github.com/datawhalechina/vibe-vibe) 的定位比 `easy-vibe` 更系统。仓库首页直接把它叫做"人人都能学会的 AI 编程指南"，并且把读者分得很细：完全零基础、只用过大模型没做过项目、有编程基础、想直接动手做项目，都有不同起点。

最该看的地方，是它把教程分成四大板块：

* 基础篇：AI 编程入门、心法和第一个项目；
* 进阶篇：从 0 到上线的避坑指南；
* 实践篇：按人群分项目实战；
* 优质文章篇：持续学习和行业追踪。

这组内容放在 `easy-vibe` 后面很顺。前者给你一张地图，后者再把基础篇和进阶篇补齐。

资料里还明确给出不同人群的推荐起点：

* 完全零基础：从基础篇第 1 章开始；
* 用过 ChatGPT 但没做过项目：从基础篇第 2 章心法开始；
* 有编程基础：基础篇快读后直接进进阶篇；
* 想直接做项目：看基础篇第 4 章实战。

这类"从哪个章节进"信息很有用，写文章时不该省略，因为它直接决定新手会不会在第一周就被内容量淹没。

### vibe-coding-cn：资源总控台

[`MaoTouHU/vibecodingcn`](https://github.com/MaoTouHU/vibecodingcn) 和前两个项目的气质不太一样。

它既有课程结构，也有 Vibe Coding 中文资源站的味道。仓库一开头就讲"规划驱动"和"模块化"，还把"道、法、术、器"这套方法论放得很靠前：

* 道：目的主导、上下文优先、先结构后代码；
* 法：一句话目标 + 非目标、按职责拆模块、接口先行；
* 术：写清楚能改什么 / 不能改什么，debug 给最小复现；
* 器：IDE、终端、prompt、skills、资源链接等工具层。

如果说 `easy-vibe` 和 `vibe-vibe` 是把人带进门，`vibe-coding-cn` 讲的就是进门之后，桌上该放哪些工具，脑子里该有哪套工作法。

把它放在第一段后半程会更合适。你已经做过一两个小项目之后，再回头看"规划就是一切""文档即上下文""一次只改一个模块"这些规则，会比刚入门时更有感觉。

## 开始把东西做出来，并准备上线

这一段的重点，是把"做出东西"继续往"做成项目"推进。

### lovable-for-beginners：面向不想先碰代码的新手

[`cporter202/lovable-for-beginners`](https://github.com/cporter202/lovable-for-beginners) 是一门面向绝对新手的 Lovable 课程。

课程首页写得很清楚：Lovable 允许你用自然语言描述需求，然后直接生成 full-stack 网站和应用，不要求代码经验。面向的人群也非常明确：

* 完全新手；
* 想快速做 MVP 的创业者；
* 想把设计变成应用的设计师；
* 想做 landing page 的营销人员。

这门课的价值不在于"讲了一个新工具"，而在于它把零基础用户会遇到的问题都拆成模块了。比如：

* 如何创建账号、认识界面；
* 怎么从 prompt 开始项目；
* 怎么 remix 现有项目；
* 怎么从 Figma、草图甚至克隆网站开始；
* 怎样理解 Chat Mode 和 Agent Mode 的区别；
* 怎样加认证、数据库、支付并最终上线。

如果目标是把第一个产品原型做出来，又不想一上来就被环境和终端吓退，`lovable-for-beginners` 放在前半段很合适。

### gpt-codex：专门给国内开发者准备的 Codex 教程

清单里特别要求保留这一句：[`xianyu110/gpt-codex`](https://github.com/xianyu110/gpt-codex) **这是一个关于 OpenAI Codex 的完整教程网站，专为国内开发者打造。**

这句话已经把项目定位说得很清楚。

项目内容也确实按"国内开发者教程站"的方式展开：

* 解释 Codex 是什么；
* 讲和 ChatGPT、Claude Code 的区别；
* 讲获取方式、安装、客户端入口；
* 补 GPT-5.5 之类与 Codex 相关的模型信息；
* 往工具接入、使用方式和项目实践延伸。

这份教程放在"开始认真学某个 AI 编程工具"这一段更顺，不建议拿它做第一站。原因很简单：Codex 好不好用，取决于你是不是已经知道项目大概怎么拆。否则你很容易只会问"它和别的工具谁更强"，却不知道该拿它推进什么任务。

对新手来说，读它时建议特别关注三类内容：

1. Codex 的产品定位；
2. 安装和可用入口；
3. 它适合承接哪些工程任务。

这样看，会比被模型版本和套餐信息带偏更有效。

### ai-guide：当成总导航用，不要当成第一本教材硬啃

[`liyupi/ai-guide`](https://github.com/liyupi/ai-guide) 的体量很大。官方描述也写得很满：它是鱼皮的 AI 资源大全加 Vibe Coding 零基础教程，覆盖 DeepSeek、GPT、Gemini、Claude、MCP、RAG、Claude Code、Codex、Copilot、Harness Engineering、Spring AI 等大量主题。

这种仓库的价值非常明确：**它是总导航，不适合当成第一本从头读到尾的教材。**

资料里关于 Vibe Coding 教程的部分，已经把内容范围写得很清楚：

* 基础必读；
* 编程工具；
* 项目实战；
* 经验技巧；
* 产品变现；
* 编程学习；
* 资源宝库。

如果前面已经看过 `easy-vibe`、`vibe-vibe`、`gpt-codex` 这些更聚焦的材料，那么 `ai-guide` 可以直接当查表式入口：按需跳转到 Cursor、Claude Code、Codex、MCP、AI 项目、产品变现或 AI 工具测评，会比从第一页硬啃到最后一页省力得多。

这也是它在路线里的合理位置：放在"入门之后、专项之前"，当导航站用。

## 项目一多，就得学会拆任务

从这一段开始，重点转到"项目怎么推进"。

### vibe-kanban：把任务拆成卡片

[`BloopAI/vibe-kanban`](https://github.com/BloopAI/vibe-kanban) 的官方描述非常直接：**Get 10X more out of Claude Code, Codex or any coding agent**。

`vibe-kanban` 放在这里很合适，因为很多人一开始用 AI 编程，所有任务都写在一个聊天框里。这样做小 demo 还能撑住，一旦项目开始变成"注册登录、数据库、支付、部署、SEO、报错修复、样式回滚"这种多线程任务，对话就会很快失控。

`vibe-kanban` 的作用，就是把这些任务重新拆回看板：

* 哪些是待做；
* 哪些在进行；
* 哪些需要回头验证；
* 哪些只是以后再说。

它最大的价值，是把 AI 编程从"想到什么问什么"拉回到"按任务推进"。对新手来说，这一步很重要，因为很多人第一次做产品失败，问题常常出在自己一直同时推进十件事。

所以在这条路线里，`vibe-kanban` 放在工具教程之后最顺。你开始有了要上线的项目，就该有一个任务拆解面板，不必继续全靠聊天记录回忆进度。

## 项目继续往前走，要把资料和约束写下来

到这里，项目通常已经不再是"单页 landing page"了。

你会开始遇到这些问题：

* 同一个需求，换个会话 AI 就忘了；
* 改了前端，后端约定又漂了；
* 你明明说了不要动某个模块，它还是会动；
* 功能能写出来，但一到验证就漏洞很多。

这就是为什么要进入上下文工程。

### context-engineering-intro：把"上下文"当成一门工程来学

[`coleam00/context-engineering-intro`](https://github.com/coleam00/context-engineering-intro) 的官方描述很明确：**Context engineering is the new vibe coding**。

这个说法值得单独写出来，因为它点中了很多人的真实痛点：你觉得模型不稳定，很多时候是上下文组织得不够好。

项目文档把上下文工程解释得很具体：这里说的不是把 prompt 再润色一遍，而是把文档、规则、示例、模式和验证一起写进完整上下文，让 AI 在明确约束下工作。

最实用的部分，是它给了一个可以直接照着搭的结构：

```text
context-engineering-intro/
├── .claude/commands/
├── PRPs/
├── examples/
├── CLAUDE.md
├── INITIAL.md
└── README.md
```

文档还把流程拆成：

1. 写全局规则 `CLAUDE.md`；
2. 写初始功能需求 `INITIAL.md`；
3. 生成 PRP；
4. 执行 PRP；
5. 通过验证、测试和迭代收口。

这组内容放在"项目上线"前后读，位置刚好。因为前半段资料会让你做出项目，到了这里，你才会意识到：项目能不能持续推进，取决于上下文有没有写清楚，规则有没有落盘，验证是不是可重复。

如果前面那几步让你会"跟 AI 一起做东西"，`context-engineering-intro` 负责让你会"稳定地继续做下去"。

## 往下走，绕不过 Harness 工程

如果上下文工程解决的是"给 AI 什么上下文、怎样组织上下文"，Harness 工程解决的就是更完整的问题：**怎样给 Agent 一个可靠的工作环境**。
这一步读起来会比前面的教程更硬一些，但它决定了项目一复杂之后，你究竟是在带着 Agent 前进，还是在被 Agent 拖着返工。

### Harness 工程书的进阶门槛

> 零基础开始 Vibe Coding 必看的书——Harness 工程书。不管是 Claude 还是 Codex 已经取代了大量基础码农的工作，也让没有任何代码基础的人可以开始 Vibe Coding。但是由于没有系统学过 Harness 工程，在使用大模型时效率很低。现在这两本书一次把 Claude 和 Codex 的 Harness 工程一次给你解释清楚，而且还有中文版，大家不容错过。

这段话的意思很明确：能开始做，不等于能稳定做；会问问题，不等于会搭环境。

### learn-harness-engineering：从环境、状态、验证和控制机制补课

结合当前可查到的仓库资料，我这里主要参考的是 [`walkinglabs/learn-harness-engineering`](https://github.com/walkinglabs/learn-harness-engineering)。

项目对它的定义非常清楚：这是一门项目制课程，重点是构建让 AI coding agents **可靠工作** 的环境、状态管理、验证和控制机制。

它开头就把参考源摆出来了，包括：

* OpenAI 的 Harness engineering；
* Anthropic 关于 long-running agents 的 harness 文章；
* 以及配套的 awesome harness engineering 索引。

资料里对 Harness 的解释很适合新手过渡：模型再强，如果仓库环境、状态、验证和生命周期没有搭好，照样会出现"看起来在干活，实际一团乱"的情况。

这里最值得看的几块内容包括：

* harness 的五个子系统：instructions、state、verification、scope、session lifecycle；
* 为什么 agent 不能只靠 prompt，而要靠 repo 内的结构化文件；
* `AGENTS.md`、`CLAUDE.md`、`init.sh`、feature list、progress log 这些文件分别承担什么角色；
* 为什么"测试通过"才算证据，不能只听 AI 说自己做完了。

如果你前面已经在 `context-engineering-intro` 里学会怎么写 PRP、怎么组织上下文，这里就会自然接上：Harness 工程是在更大的系统层面，把上下文、状态和验证全都固定下来。

所以它放在整条路线的后半段更合适。项目跑起来，再补长期可靠性，会更顺。

## 文末 10 条 X 教程的放置位置

这 10 条 X 教程适合放在文末，作为补充阅读，不要拿来代替项目文档或官方文档。

如果只看标题，它们很散；按路线整理后会清楚很多。

### 1）入门和界面上手

* `@gengdaJ`：Codex App 从 0 到 1 完整入门教程，包含界面设置、基础用法讲解、常见踩坑排查。\
  来源：<https://x.com/gengdaJ/status/2053724702993190917>

这类内容适合放在真正开始用 Codex 的第一周，解决的是"怎么打开、怎么开始、哪里容易踩坑"。

### 2）从想法到上线

* `@ai_muzi`：0 基础 AI 应用构建 + 上线系统教程，从想法做到项目，再到域名上线全流程。\
  来源：<https://x.com/ai_muzi/status/2054471711718879291>

它刚好对应这条路线中段的过渡：从做 demo 到上线。

### 3）浏览器和插件实战

* `@Pluvio9yte`：Chrome 插件 + 浏览器控制实战，从安装配置到 Codex 操作浏览器。\
  作者：<https://x.com/Pluvio9yte>

这类内容更适用于已经做过普通网页、准备往浏览器自动化和插件场景扩展的人。

### 4）双模型与本地工作台配置

* `@alin_zone`：Claudian 配置教程，Claude Code + Codex 双模型实战，Obsidian 双开配置方案。\
  作者：<https://x.com/alin_zone>

这类资料更偏"我的工作台怎么搭"，适合同时使用 Claude Code 和 Codex 的时候看。

### 5）现成 Skills 收集

* `@eastweb3eth`：5 个 Codex 必装 Skill 工具，GitHub 上实用合集。\
  作者：<https://x.com/eastweb3eth>

把它放在你已经明白 Skill 有什么用之后再回头装，会比一开始看见 Skill 就全部装一遍更合适。

### 6）上下文调优

* `@lxfater`：Codex 深度调优 + 上下文优化四大绝招，省上下文的方法。\
  作者：<https://x.com/lxfater>

这一条正好和 `context-engineering-intro` 呼应。读系统教程，再看这类经验贴，会更容易分辨哪些是技巧，哪些是长期结构。

### 7）设计工作流

* `@xin_pai88825`：Codex + Image2 + Figma 设计工作流，IP 出图到 Figma 落地。\
  作者：<https://x.com/xin_pai88825>

这类内容对设计师或产品同学也有用，说明 Vibe Coding 不只有写代码，也包括图像和设计交付。

### 8）剪辑与视频流程

* `@Saccc_c`：Codex + HyperFrames 剪辑工作流，做视频流程。\
  作者：<https://x.com/Saccc_c>

如果你要把 AI 工作流延伸到视频，这条适合作为补充阅读，不属于最前面的入门主线。

### 9）VPS 与部署

* `@WEB3_furture`：用 Codex 一键部署 VPS，零基础自动搭私人 VPN。\
  作者：<https://x.com/WEB3_furture>

这一条放在"项目上线"之后看更合适，因为它偏部署和环境，不适合最前面看。

### 10）订阅与省钱避坑

* `@Lonely__MH`：5 折订阅 ChatGPT Plus 全流程实测，土区省钱方法。\
  作者：<https://x.com/Lonely__MH>

订阅成本相关内容作为补充参考，不作为主线内容。

## 可以按这个顺序读

如果你现在是从零开始，我会建议按这个顺序读：

1. 读 `easy-vibe`，建立学习地图；
2. 再读 `vibe-vibe`，补齐系统教程；
3. 用 `lovable-for-beginners` 或 `gpt-codex` 选一条工具线开始动手；
4. 把 `ai-guide` 当导航站，缺什么再查什么；
5. 一旦项目开始变多，就把任务丢进 `vibe-kanban`；
6. 准备认真做项目时，补 `context-engineering-intro`；
7. 想让 Agent 在真实仓库里长期稳定工作，再去看 Harness 工程书和 `learn-harness-engineering`。

## 资料来源

* `easy-vibe`：<https://github.com/datawhalechina/easy-vibe>
* `vibe-vibe`：<https://github.com/datawhalechina/vibe-vibe>
* `vibe-coding-cn`：<https://github.com/MaoTouHU/vibecodingcn>
* `lovable-for-beginners`：<https://github.com/cporter202/lovable-for-beginners>
* `gpt-codex`：<https://github.com/xianyu110/gpt-codex>
* `ai-guide`：<https://github.com/liyupi/ai-guide>
* `vibe-kanban`：<https://github.com/BloopAI/vibe-kanban>
* `context-engineering-intro`：<https://github.com/coleam00/context-engineering-intro>
* Harness 工程课程：<https://github.com/walkinglabs/learn-harness-engineering>
* Claude 官方 Claude Code 教程播放列表：<https://www.youtube.com/playlist?list=PLmWCw1CzcFilebjK89WLb5cAvM8K0cLB3>

---

---
url: >-
  https://ain.hmgf.hxcn.space/ai/ai-collaborative-development-methodology-202605.md
description: 从 Trae 官方知识库的 Spec、Rules、MCP、Skills、Figma 与排查文档出发，整理一套适合非程序员参与的 AI 协作开发方法。
---

# AI 协作开发方法

非程序员用 AI 写产品原型时，最常见的卡点是**报错文本能读，定位不到是哪一步出了问题**。模型已经生成了页面、命令也跑了、终端里还给了错误信息，但下一步该查环境变量、查依赖、查日志、查路由，还是回到需求本身重写，根本没方向。

字节系 AI IDE 的官方知识库覆盖了 Agentic AI、Spec、rules、MCP、skills、Figma 等模块，真正容易缺的是把**调试规则模板前置**。产品经理或设计同事第一次进入 AI IDE 时，通常不缺需求想法，缺的是把错误定位到"环境、规则、上下文，还是工具接入"的能力。

## 协作链路

Trae 官方中文社区里有一篇学习中心整理帖，把文档站、知识库、Figma、MCP、Rules、Skills 和问题排查全串起来了。它的价值在于把 AI 协作开发拆成了几段清楚的链路：

* 用 `Spec & Plan` 把需求写成可执行说明
* 用 Agent 承担拆解、分析、改动和交付
* 用 Rules 固定项目约束
* 用 MCP 接外部工具和资料
* 用 Skills 固定高频工作流
* 用 Figma 和预览能力把设计上下文接进来
* 用问题排查文档和模板兜住调试阶段

![TRAE 学习中心截图](https://gastigado.cnies.org/d/public/trae-learning-center.png)

这条链里，非程序员最容易掉下去的地方通常有两个：

1. 需求已经说了，但没说成 AI 能执行的规格
2. 报错已经出现了，但没人把排查顺序写成模板

所以这篇文章重点只放一件事：**协作方法怎么排**。

## Agentic AI 是什么

Trae 的官方学习中心把 Agent、Skills、Rules、MCP、SOLO、Spec 放在同一条知识路径上，这已经很能说明它理解的 Agentic AI 是一套工作方式。

从 `智能体概述` 页面能看出，Trae 把 Agent 的工作流拆成几步：理解需求、分析现状、方案设计、实施变更、交付验收。两个事实值得记住：

* Agent 不只回答问题，它会分析文件、编辑文件、运行命令、调用工具
* Agent 能不能稳定下来，靠的是前面几层约束是否已经准备好

说得简洁一点：

> Agentic AI 可以理解成：能在明确约束下接手一段工作流的执行者。

这些约束主要来自 Spec、Rules、MCP、Skills 这四层。

## Spec：把想法写成 AI 真能执行的开发说明

Trae 官方学习中心把 `工作流：Spec & Plan（需求规格与计划）` 放在产品经理和进阶能力入口里，这个位置很合理。对非程序员来说，Spec 就是进入协作开发的翻译层。

很多口头需求在团队里是能聊明白的，但丢给 AI 就会变形。比如：

* "做个活动页" 太宽
* "像某某网站那样高级一点" 太虚
* "把登录优化一下" 太模糊

Spec 要做的，是把这些模糊说法压成可执行说明。至少要写出几件事：

### 1. 目标是什么

可以写成：

* 要解决哪个业务问题
* 谁是用户
* 用户完成什么动作才算成功

### 2. 页面或功能范围是什么

比如：

* 需要哪些页面
* 哪些状态要覆盖
* 哪些交互先不做
* 哪些依赖外部服务

### 3. 验收标准是什么

比如：

* 移动端能打开
* 表单提交能成功
* 错误提示完整
* 埋点字段齐全
* 接口失败时有回退状态

非程序员最容易忽略的，通常是第三点。因为没有验收标准，AI 生成的结果就只有"像不像"，没有"过不过"。

一个最小可用的 Spec 模板，可以写成这样：

```markdown
# 需求名称

## 目标
- 面向谁：
- 解决什么问题：
- 成功动作：

## 页面与功能范围
- 需要实现：
- 本轮不做：

## 关键流程
1. 用户进入页面
2. 用户执行操作
3. 系统返回结果
4. 失败时如何提示

## 数据与依赖
- 接口：
- 设计稿：
- 素材与文案：

## 验收标准
- 功能验收：
- 视觉验收：
- 异常验收：
```

这一步做得越扎实，后面的 Rules、MCP、Skills 越省力。

## Rules：把项目约束前置，别等 AI 写偏了再救火

Trae 的学习中心把 `规则（Rules）` 放在 Agent 和 Skills 同一级，这个顺序非常重要。Rules 管的是整个项目有哪些底线。

对团队协作来说，Rules 应该前置写清楚的通常有五类：

### 1. 目录与命名

* 页面文件放哪
* 组件怎么命名
* 接口文件怎么组织
* 图片和静态资源放哪

### 2. 技术栈与依赖范围

* 用哪套框架和路由
* 可以新增哪些依赖
* 哪些库禁止引入
* 是否允许直接改构建配置

### 3. 代码风格和实现偏好

* 是否统一 TypeScript
* 是否优先函数组件 / Composition API
* 表单、状态管理、测试用什么方案

### 4. 风险操作禁令

* 禁止直接删库或清空目录
* 禁止越权修改生产配置
* 禁止在未确认前批量重构

### 5. 调试与提交规则

* 报错时先收集哪些信息
* 每次修改后先跑什么验证
* 记录哪些命令输出
* 提交说明需要包含什么内容

Rules 的价值，在于把"团队默认共识"变成机器可见的约束。否则 Agent 每次都得重新猜：能不能随便装包、能不能改目录、能不能直接推重构。

一个简版 Rules 模板，可以写成这样：

```markdown
# Project Rules

## Stack
- Framework:
- Router:
- State:
- Styling:

## File Rules
- New pages go to:
- Shared components go to:
- Static assets go to:

## Do Not
- Do not change:
- Do not delete:
- Do not add dependencies without:

## Validation
- After each change, run:
- Before handoff, provide:
```

如果团队里有产品经理、设计师、开发一起和 AI 协作，这份 Rules 最好一开始就公开，不要只留在开发自己的脑子里。

## MCP 和 Skills：一个负责接工具，一个负责接流程

这两个词很容易被混着说，但角色不一样。

### MCP 负责接外部工具和资料

Trae 官方社区的 FAQ 直接把 MCP 解释成协议：它让智能体作为 MCP 客户端去请求 MCP Server，使用外部工具和服务。学习中心里也把 `模型上下文协议（MCP）概览`、`添加 MCP Server`、`在智能体中使用 MCP Server`、`查看 MCP Server 的日志`、`MCP 教程：将 Figma 设计稿转化为前端代码`、`MCP 教程：实现网页自动化测试` 摆成完整路径。

在协作开发里，MCP 主要管三件事：

* 读外部资料，例如设计稿、网页、文档
* 调外部工具，例如 Playwright、Figma、地图服务
* 把工具日志带回调试链路

### Skills 负责固定高频工作流

Skills 更像一段已经跑顺的固定流程。Trae 学习中心同时给了 `技能（Skills）`、`研发场景十大热门 Skill 推荐`、`如何写好一个 Skill：从创建到迭代的最佳实践` 这些入口，可以看出它把 Skill 当成长期可维护的工作流单元。

对协作开发来说，常见拆分方式是：

* MCP 负责"能不能拿到上下文 / 能不能动到工具"
* Skill 负责"拿到之后按什么步骤做"

比如：

* Figma MCP 解决"能不能读设计稿、能不能写回画布"
* Figma 相关 Skill 解决"如何把设计系统、组件、变量和落地方式串起来"
* Playwright MCP 解决"能不能跑浏览器自动化"
* 测试 / 调试 Skill 解决"报错后先查哪几步"

如果把两个层级混了，团队会很容易出现一种假忙：工具接了很多，流程还是靠临场发挥。

## Figma 接入：设计上下文如何进入开发链路

Figma 的接入方式用两组官方资料一起讲最合适：

* Trae 官方：`MCP 教程：将 Figma 设计稿转化为前端代码`
* Figma 官方：`Get started with the Figma MCP server`、`Use skills with the Figma MCP server`

Figma 官方文档有一句话很关键：Figma MCP server 会把结构化设计上下文直接带进开发工作流，让 Agent 能读组件、变量、布局数据，并生成更准确、更贴近设计系统的代码。它还明确区分了工具和 Skills：

* **Tools** 让 MCP 客户端对 Figma 文件执行动作
* **Skills** 告诉 MCP 客户端如何更有效地使用这些工具

![Figma MCP 官方页截图](https://gastigado.cnies.org/d/public/figma-mcp-help.png)

这对协作开发有两个直接影响：

### 1. 设计师给开发的，不再只是静态图

有了 Figma MCP，Agent 能看到：

* 组件结构
* 变量
* 布局规则
* 设计系统里已经存在的原子

这比"甩一张截图让 AI 猜"靠谱得多。

### 2. 设计工作流也能被写成 Skill

Figma 官方还专门讲了 `Use skills with the Figma MCP server` 和 `Create skills for the Figma MCP server`。设计协作同样可以写成固定工作流，例如：

* 读设计稿后，先抽组件清单
* 再标哪些组件已有代码映射
* 再列出缺失状态和交互说明
* 再生成前端落地任务

这样产品经理、设计师、开发者面对的，就会是一条更完整的设计到代码链路，不再只是含糊指令。

## 调试模板要前置

前面这些概念都重要，但最该落重锤的，还是调试。

Trae 学习中心里，开发者路径最后单独列了一个 `问题排查（12 篇）` 区块：通用问题、MCP Server、Python、Go、Java、TypeScript、Vue、Remote SSH、性能、SOLO 问题排查都有。这已经说明：代码能生成出来，不等于就能顺利落地。

非程序员为什么特别容易卡在这里？因为他们通常具备三分之一能力：

* 能读懂报错的大意
* 能知道哪里红了
* 能把报错复制给 AI

但他们缺的是后面三分之二：

* 不知道先查哪一层
* 不知道哪些日志要保留
* 不知道什么时候该回退到 Spec 或 Rules 重写

调试不能等到出错后才讲，应该在项目开始前就给一份固定模板。

### 一个够用的调试规则模板

```markdown
# Debug Rules

## When any error happens
1. 不要连续尝试三种修法
2. 记录完整报错原文
3. 标注报错发生在哪一步
4. 保存最近一次执行的命令
5. 说明本次修改过哪些文件

## Reproduction
- 当前分支：
- 运行命令：
- 输入数据：
- 预期结果：
- 实际结果：

## Logs to collect
- 终端输出：
- 浏览器控制台：
- Network 请求：
- 服务端日志：
- MCP Server 日志（如果用了 MCP）：

## Triage Order
1. 环境与依赖
2. 配置与环境变量
3. 路由 / 文件路径 / 命名
4. 接口返回与数据结构
5. 规则冲突
6. Spec 本身是否写漏

## Escalation
- 如果连续两轮修复都失败：停止继续改代码
- 回到 Spec / Rules / 输入数据重新核对
- 输出"已确认无效的尝试"清单
```

这份模板的作用很直接：它把"乱试"改成"收集，分类，排查"。

### 调试规则前置的必要性

调试失败时，上下文往往已经污染了：

* 前面几轮试错没有留下清晰记录
* Agent 改了太多文件，没人知道从哪一步开始歪
* 设计、产品、开发口中的"正确结果"都不一样
* 报错已经变成连锁反应

把调试模板前置，至少能带来四个改善：

1. 让非程序员知道先交什么材料
2. 让开发者不用从一堆聊天记录里捞上下文
3. 让 Agent 每次排查都按同样顺序走
4. 让失败尝试也能沉淀成团队经验

## 面向产品、设计与开发的协作分工

如果同一个 AI 项目里有多角色参与，最稳的分工通常是这样：

### 产品经理

负责：

* Spec 初稿
* 业务目标与验收标准
* 范围说明
* 异常状态优先级

不要直接跳过的文档：

* `Spec & Plan`
* `智能体概述`
* `规则（Rules）`

### 设计师

负责：

* Figma 文件与组件范围
* 设计系统、变量、交互说明
* 哪些地方允许 AI 自由发挥，哪些不允许

最该接入的链路：

* Figma MCP
* Figma Skills
* Preview / design-to-code 教程

### 开发者

负责：

* 把 Rules 写实
* 决定 MCP 接哪些工具
* 给团队准备调试模板
* 收口最终验证和风险操作范围

最该提前公开的内容：

* 项目目录规则
* 环境变量规范
* 本地运行命令
* 排查顺序
* 哪些改动需要人工确认

### Agent

负责：

* 在这些约束内执行
* 调工具、跑命令、改代码、做验证
* 按模板返回进度和问题

Agent 承担的是中间那段重复执行工作，不负责替团队抹掉这三种角色。

## 协作顺序

把前面的内容压成实际流程，大概就是这六步：

```text
需求想法
→ 写 Spec
→ 补 Rules
→ 接 MCP
→ 装 Skills
→ 前置调试模板
→ 再让 Agent 开始做事
```

很多团队会直接从 Agent 开始，这也是最容易出事的地方。Agent 一启动，所有含糊、遗漏和约束缺失，都会在调试阶段一起爆出来。

更省时间的做法，是让团队少在第三轮、第四轮报错时迷路。

---

---
url: https://ain.hmgf.hxcn.space/ai/vibe-coding-helper-tools-202605.md
description: >-
  从 token、代码图谱、仓库理解到后端平台，整理 TokenTracker、repowise、CodeGraph 和 InsForge 在 Claude
  Code / Codex 工作流里的实际位置。
---

# Vibe Coding 辅助工具

长期使用 Claude Code、Codex 后，常见瓶颈包括 token 消耗追踪、仓库理解、文件关联分析和后端基础设施搭建：

* token 花到哪里去了；
* 仓库越来越大后，模型到底看懂了多少；
* 哪些文件改动会互相牵连；
* 当前端已经写出来，后端和部署还要补多少基础设施。

下面介绍四个辅助工具：`TokenTracker`、`repowise`、`CodeGraph`、`InsForge`。它们分别卡在不同位置：一个管消耗，一个管仓库理解，一个管图谱检索，一个补后端底座。

## `TokenTracker`：token 花费追踪

### 它解决什么问题

很多人每天都在 Claude Code、Codex CLI、Cursor、Gemini CLI 之间切换，但回头看成本时，往往只剩一个模糊印象：最近好像花得很快。

`TokenTracker` 的定位很直接：本地自动收集 token 数、聚合展示成本趋势，还顺手提供一个跨 Agent 的 Skills 管理器。

有个细节要说明：仓库顶部口号还写着"across 13 AI coding tools"，但后面的 `Features` 小节已经更新成"16 AI tools out of the box"，并列出了 16 个工具名称。仓库文案本身存在版本差异——当前功能清单列出 16 个工具，顶部口号仍停留在 13 个工具的旧说法。

### 主要能力

当前仓库首页明确写出的能力包括：

* 本地 Dashboard，默认打开在 `http://localhost:7680`
* 自动发现并安装常见 AI 工具的 hook
* Skills manager，可浏览 250+ 公共 Skills，并同步到 Claude、Codex、Gemini、OpenCode、Hermes
* 实时额度 / 限流窗口跟踪
* 成本引擎，读取 2200+ 模型的价格表
* 可选全球排行榜
* 100% 本地保存 token 数据，不上传 prompt、回复和文件内容

如果只把它理解成"记账器"，会低估它。它同时在做两件事：

1. 记录各个编码工具的 token 与成本。
2. 把多工具环境下的 Skills 分发也接进来，减少一套套手工同步配置。

### 安装和使用

最快的入口是：

```bash
npx tokentracker-cli
```

第一次运行会自动安装 hooks、同步数据，并打开本地看板。

如果你想常驻使用，可以全局安装：

```bash
npm i -g tokentracker-cli
```

安装后常见命令包括：

```bash
tokentracker
tokentracker sync
tokentracker status
tokentracker doctor
tokentracker uninstall
```

macOS 用户还可以走 Homebrew：

```bash
brew install --cask mm7894215/tokentracker/tokentracker
brew install mm7894215/tokentracker/tokentracker
```

### 放进工作流时最有用的地方

`TokenTracker` 适合放在整条 Vibe Coding 工作流的最前面，帮你建立成本感。

一个很实际的顺序是：

1. 跑 `npx tokentracker-cli`，看本地面板有没有正常记到数据。
2. 连续用几天 Claude Code / Codex / Cursor 后，观察哪些项目、哪些模型、哪些时段最吃 token。
3. 如果团队里同时在维护多套 Skills，再用它统一同步，省掉手动复制配置目录的麻烦。

它不直接帮你理解仓库，但会让你更早发现：**到底是模型太贵，还是你让模型在无谓地到处扫文件。**

## `repowise`：把仓库历史、结构和决策一起交给 Agent

### 单独讨论的原因

很多"仓库理解"工具，只做其中一层：要么画依赖图，要么做向量检索，要么整理文档。

`repowise` 覆盖面较广。仓库把它拆成四层 intelligence：

* dependency graph
* git history
* auto-generated documentation
* architectural decisions

官网首页又把 chat 作为对外展示的一层能力。所以这里要把两个口径分开：**仓库说明讲四层核心 intelligence，官网首页展示成五层对外体验。**

### 核心内容

最值得记下来的有三组信息。

第一组是性能与成本说法。仓库里明确给出：

* `27× fewer tokens per query`
* `36% cheaper`
* "Same answer quality"

这些数字后面附了方法学和基准项目，链接也放到了 `repowise-bench` 仓库里。

第二组是它构建的内容：

* **Graph Intelligence**：基于 tree-sitter 做依赖图、调用图、中心性分析。
* **Git Intelligence**：把 churn、ownership、co-change、significant commits 这些信号整理出来。
* **Documentation Intelligence**：自动生成分层 wiki，并持续刷新。
* **Decision Intelligence**：从 git 历史、注释标记和 CLI 输入里整理架构决策，允许 Agent 回答"为什么这样做"。

第三组是接入形态。它通过 7 个 MCP tools 暴露给 Claude Code 和其他 MCP 客户端。官网首页也把这 7 个工具列得很清楚，例如 `get_overview()`、`get_context()`、`get_risk()`、`get_why()`、`get_dead_code()`。

### 安装和初始化

最直接的安装方式：

```bash
pip install repowise
```

如果你偏好隔离环境，也可以：

```bash
uv tool install repowise
```

单仓库初始化流程：

```bash
cd your-project
repowise init
repowise serve
```

多仓库 workspace 则是：

```bash
cd my-workspace
repowise init .
repowise serve
```

仓库对初始化时间也写得很坦白：首次索引一个 3000 文件左右的仓库，可能需要约 25 分钟；之后每次 commit 后的增量更新通常在 30 秒以内。

### 它在仓库里到底帮你做什么

只看仓库说明，一个很自然的用法就是把它当成"给 Claude Code 补背景"。

例如你问：

* auth 为什么是现在这个结构；
* 哪些文件是高 churn 热点；
* 这次改动最可能牵连哪些仓库外文件；
* 当前 `CLAUDE.md` 里哪些结论已经过期。

这类问题，单靠文件扫描会很慢。`repowise` 的优势在于它把结构、历史、文档、决策一起打包，减少模型一遍遍从零摸索。

### 适用环节

`repowise` 最适合放在"仓库已经有一定体量，你开始反复问为什么"的阶段。

一个顺手的工作流可以这样安排：

1. 新项目或刚接手的项目跑一次 `repowise init`。
2. 让 Agent 用 `get_overview()` 和 `get_context()` 了解模块边界。
3. 改核心模块前，查 `get_risk()` 和 `get_why()`。
4. 项目多仓库拆分后，再切到 workspace 模式。

它不负责实时记账，也不替你补后端，但在"仓库理解"这一层，覆盖代码搜索、文件关联、依赖分析等功能。

## `CodeGraph`：给 Claude Code 一张本地图谱

### 它解决的是 Explore agent 的扫库成本

`CodeGraph` 一开头就把目标写得很直白：给 Claude Code 提供 semantic code intelligence。

它的核心思路很简单：当 Claude Code 在仓库里探索问题时，默认会频繁调用 grep、glob、Read 之类工具；`CodeGraph` 先把符号关系、调用图和代码结构预建成图，再让 Explore agent 直接查图，少走反复扫文件这一步。

### 数字的来源和口径

README 里有两组数字，口径不同：

* **头图口号**：`94% fewer tool calls · 77% faster exploration · 100% local`
* **Benchmark Results 平均值**：`Average: 92% fewer tool calls · 71% faster`

`92%` 和 `71%` 有 benchmark 平均值支持；`94%` 和 `77%` 是封面口号，比平均值更乐观。

语言和框架方面，支持表列出了 19 类语言 / 文件类型；框架部分用的是"13 frameworks"这一摘要说法，后面的路由表按框架类别分组，把若干 Go、Rust、前端路由系统合并成类别展示。可以写成：**它声称支持 13 个框架类别，并附了分组路由表。**

### 安装和接入

最短安装命令：

```bash
npx @colbymchenry/codegraph
```

项目初始化：

```bash
cd your-project
codegraph init -i
```

如果你想手动全局安装，也可以：

```bash
npm install -g @colbymchenry/codegraph
```

它还给了手动 MCP 配置方式，把它加进 `~/.claude.json`：

```json
{
  "mcpServers": {
    "codegraph": {
      "type": "stdio",
      "command": "codegraph",
      "args": ["serve", "--mcp"]
    }
  }
}
```

### 还有哪些实际能力

除了速度数字，还有几个很适合写进正文的点：

* `Impact Analysis`：修改前先查调用者、被调用者和影响半径。
* `Always Fresh`：带文件监听，图谱可以自动同步。
* `100% Local`：数据保留本地，不需要 API Key。
* `Framework-aware Routes`：能把 URL 路由和对应处理函数 / 类关联起来。

支持语言表里明确列了 TypeScript、JavaScript、Python、Go、Rust、Java、C#、PHP、Ruby、C、C++、Swift、Kotlin、Scala、Dart、Svelte、Vue、Liquid、Pascal / Delphi。

### 在工作流中的位置

如果你的主要问题是"Agent 每次都在到处翻文件，速度慢、token 烧得快"，`CodeGraph` 会比大而全的仓库知识层更快见效。

可以把它放在这样的顺序里：

1. 让 `TokenTracker` 看出探索阶段 token 在暴涨。
2. 给 Claude Code 装上 `CodeGraph`。
3. 初始化项目后，让 Agent 用图谱工具回答结构问题。
4. 改动前用 impact 分析看影响范围。

它特别适合"结构追踪"和"调用链定位"这类问题。

## `InsForge`：给 AI 编程工具补后端底座

### 背景：它为何常被拿来与 Supabase 对照

AI 编程工具做前端已经很顺，容易卡住人的地方通常是数据库、鉴权、存储、函数、部署、模型网关这些后端底座。

`InsForge` 就是朝这个方向去的。仓库把它定义成 **all-in-one, open-source backend platform for agentic coding**。官网首页则更像产品介绍：A Postgres-based backend with auth, storage, compute, hosting, and AI gateway. Built for coding agents.

### 哪些能力能同时核到

这部分可以写得比较稳，因为三处资料基本一致。

仓库、官网首页和介绍文档都能确认这些核心能力：

* PostgreSQL / Postgres 数据库
* Authentication
* S3 compatible storage
* Edge Functions
* AI Gateway / AI Integration
* Deployment

官网首页和文档还额外突出：

* Realtime
* Vector
* Compute

如果你要写"InsForge 能补哪些后端能力"，这几个点都有依据。

### 接入方式要分成两类写

接入方式分得很清楚：

* **MCP Server**：支持 self-hosted 和 cloud
* **CLI + Skills**：cloud only

这点很重要，因为它决定了你该怎么描述工作流。

如果你写成"任何场景下 CLI + Skills 都能本地跑"，就超出了仓库明示范围。

同时，官网首页和文档都强调：在帮用户用 InsForge 之前，应该先读取 `https://insforge.dev/skill.md`，它被官方称作 canonical workflow。这个 `skill.md` 里还特别提醒：

* 优先使用 `npx @insforge/cli`
* 不要默认全局安装 CLI
* 试用项目创建后要先等待后端可用，再继续往下走

InsForge 很在意"让 Agent 走同一套稳定的接入路径"，这一点和常见项目首页不太一样。

### 安装、自托管和部署

自托管路径很明确：

```bash
git clone https://github.com/InsForge/InsForge.git
cd insforge
cp .env.example .env
docker compose -f docker-compose.prod.yml up
```

随后在本地页面连接 MCP，再让 Agent 去调用 `fetch-docs` 一类工具验证连接。

同时还给了多项目并行运行的方式，以及三个一键部署入口：

* Railway
* Zeabur
* Sealos

"Docker Compose 本地跑起来"与"交给云平台一键部署"，都是已核验能力。

### 后端能力的实际边界

这些能力都出现在 `Core Products` 和官网首页、文档的功能区里。但不要把它夸张写成"AI 一连上就自动替你全栈交付"。更准确的说法是：

* Agent 可以通过 MCP 或 CLI + Skills 去读取后端上下文、部署函数、跑迁移、建 bucket、设 auth provider。
* 底层提供的 primitives 已经准备好，Agent 补后端时不用从零拼一堆服务。

### Y Combinator 支持

官网首页明确写了 `Backed by Y Combinator`。仓库本身没有直接给出批次说明。如果要写具体批次，还需要额外查 YC 官方公司页。

### 适合放在工作流的哪个位置

`InsForge` 适合放在"前端能做出来，但后端和部署会把人卡住"的阶段。

很实际的一条链路是：

1. 前期用 `TokenTracker` 管住成本。
2. 用 `CodeGraph` 或 `repowise` 让 Agent 更快理解当前仓库。
3. 当页面和交互原型已经有了，再把 `InsForge` 接进来补数据库、鉴权、存储、函数和部署。

它解决的是 Vibe Coding 里最常见的断点：前端已经像样，后端基础设施还没站起来。

## 四个工具组成的工作流

这四个工具在同一条工作流中的推荐顺序是：

1. **装 `TokenTracker`**：看自己到底把 token 烧在了哪里。
2. **补 `CodeGraph` 或 `repowise`**：前者更偏快速图谱探索，后者更偏把历史、文档、决策一起交给 Agent。
3. **接 `InsForge`**：等页面、模型调用和主要流程确定后，再把后端 primitives 接上。

其中也可以再细分一下：

* 如果你主要痛点是 Explore agent 反复扫文件，上 `CodeGraph`。
* 如果你主要痛点是仓库越来越复杂、每次都得重新解释历史背景，上 `repowise`。
* 如果你主要痛点是"前端已经好了，后端我不想再手配"，引入 `InsForge`。

## 补充提醒

这四个工具里，最需要谨慎验证的还是 `CodeGraph` 和 `InsForge`。

* `CodeGraph` 的数字要分清 README 头图口号和 benchmark 平均值。
* `InsForge` 的后端能力可以确认，但涉及 Y Combinator 批次、性能对比、社媒用户评价时，最好单独标明来源层级。

## 参考链接

* `TokenTracker`：<https://github.com/mm7894215/TokenTracker>
* `repowise` GitHub：<https://github.com/repowise-dev/repowise>
* `repowise` 官网：<https://www.repowise.dev>
* `repowise` 文档：<https://docs.repowise.dev>
* `CodeGraph`：<https://github.com/colbymchenry/codegraph>
* `InsForge` GitHub：<https://github.com/InsForge/InsForge>
* `InsForge` 官网：<https://insforge.dev>
* `InsForge` 文档：<https://docs.insforge.dev/introduction>
* `InsForge` 官方 `skill.md`：<https://insforge.dev/skill.md>

---

---
url: https://ain.hmgf.hxcn.space/ai/cli-for-agents-202605.md
description: >-
  从 CLI-Anything、OpenCLI 和飞书 CLI 三个项目出发，看清命令行为什么重新成为 Agent 的工作台，以及它和 MCP、Skill
  的分工。
---

# CLI 与 Agent 工作流

如果把 GUI 理解成给人看的操作面，那 CLI 就是给人和 Agent 共用的控制面。按钮、弹窗、悬浮层这些东西，人看着顺手，Agent 却要识别页面结构、判断状态、决定点击顺序；命令行反过来，输入和输出都更直白，参数、返回值、错误信息也更容易串到下一步里。

这一波 CLI 回潮，核心原因是 Agent 工作流需要更稳的接口。人当然还会用 GUI 处理确认、预览、授权这些动作，但最适合让 Agent 接手的，往往还是 CLI 这一层：容易组合，容易复盘，也更容易加权限控制。

## CLI 回潮的背景

这股趋势有很直接的项目热度支撑。2026 年 5 月 16 日核对 GitHub 时，三个相关项目的热度都不低：

* `HKUDS/CLI-Anything`：35,020 Stars
* `jackwener/OpenCLI`：21,105 Stars
* `larksuite/cli`：10,910 Stars

它们代表了三种不太一样的路线：

* **CLI-Anything**：把原本没有命令行的软件，包装成 Agent 能调用的 CLI
* **OpenCLI**：把网站、浏览器会话、Electron 应用和本地工具接进统一命令面
* **飞书 CLI**：把企业协作软件里的文档、日历、会议、待办这类"落地动作"变成可编程命令

前两个项目解决的是"怎么接进去"，第三个项目解决的是"结果怎么落下去"。

## CLI-Anything：把软件改造成 Agent 可调用命令

### CLI-Anything

官网：<https://clianything.cc/>

CLI-Anything 的仓库标题就是：**Making ALL Software Agent-Native**。它盯着的是更上游的问题：很多软件根本没有为 Agent 准备可调用接口，既没有现成 API，也没有像样的 CLI。它的做法，是反过来补一层 CLI。

当前有两条主要使用路径。

第一条是给 Agent 用的：

```bash
npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -y
```

这条命令会把 CLI-Hub 的技能装进支持 SKILL 的 Agent 里。官方站点列出的兼容对象包括 OpenClaw、Nanobot、Claude Code、Codex、Antigravity 等。

第二条是给人直接用的：

```bash
pip install cli-anything-hub
cli-hub search
cli-hub install <name>
```

这条链路相当于一个"CLI 市场"。装好 `cli-anything-hub` 之后，就可以用 `search`、`info`、`install` 浏览和安装社区里已经做好的 CLI。

### 核心能力

CLI-Anything 不只是套一层壳。项目资料反复强调几个特征：

* CLI 是给 Agent 的通用接口
* 输出尽量结构化，方便下一步继续接
* `--help` 本身就是可发现文档
* 生成后的 CLI 还能继续被 Skill 化、市场化分发

它还专门解释了"为什么是 CLI"：

* 文本命令天然适合和 LLM 上下文拼接
* 参数和返回值容易组合
* JSON 输出比屏幕截图更稳定
* 跨系统开销小，不依赖完整 GUI 环境

### 安装和使用方式

已经在 Claude Code 这类环境里工作的话，文档给的是插件式入口：

```bash
/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
```

装完后，直接用一条命令生成目标软件的 CLI：

```bash
/cli-anything ./gimp
```

不走插件路线的话，也可以把 CLI-Hub 当成资料库和安装器来用：

```bash
pip install cli-anything-hub
cli-hub list
cli-hub search blender
cli-hub install <name>
```

### 使用场景

CLI-Anything 位于"前置改造层"。它不负责让 Agent 直接写日报，更常见的用法是：

1. 为原本只有 GUI 的软件补一套 CLI
2. 让 Agent 通过命令行驱动它
3. 把命令结果继续接给文档、发布、通知这些后续工具

比如设计、GIS、视频剪辑、桌面软件自动化这类场景，往往第一步最难。CLI-Anything 为原本只有 GUI 的软件补一套 CLI。

![CLI-Anything GitHub 预览图](https://gastigado.cnies.org/d/public/github-og-cli-anything.png)

![CLI-Anything 架构图](https://gastigado.cnies.org/d/public/cli-anything-architecture.png)

## OpenCLI：把网站、登录态和多模型命令压成一套接口

### OpenCLI

官网：<https://opencli.info/>

OpenCLI 解决的是另一类痛点：软件未必缺 CLI，但网站和桌面 App 的现成交互太散，Agent 不好接。它的副标题写得很清楚：**Convert any website into a CLI & Drive your logged-in browser from AI agents.**

这句话里有两个关键词：

* **convert any website into a CLI**
* **drive your logged-in browser**

前者是适配器思路，后者是登录态复用思路。也正因为第二点，它和传统"开个干净浏览器再自动化点击"的路线差别很大。

### 项目能力

项目文档把能力分成三层：

1. 用内置适配器直接操作网站
2. 让 Agent 通过浏览器桥接控制任意网页
3. 用 `opencli browser` 和 Skill 自己写新适配器

它的内置命令范围已经很大。仓库首页列出的站点和工具已经覆盖：Bilibili、知乎、小红书、Reddit、Hacker News、Twitter/X，以及 `gh`、`docker`、`ntn`、`longbridge` 这类本地 CLI，还有 Cursor、Codex、ChatGPT 这类 Electron 应用。

这组命令在适配器表里能对上相当一部分。比如：

* `claude`：`ask`、`send`、`new`、`status`、`read`、`history`、`detail`
* `gemini`：`new`、`ask`、`image`、`deep-research`
* `twitter`：`search`、`trending`、`post`、`reply`、`bookmarks` 等

文档里的 **ask / send / read / new / history** 都能找到对应。

### 安装和浏览器桥接

OpenCLI 官方要求 Node.js 版本不低于 21：

```bash
node --version
npm install -g @jackwener/opencli
```

然后要装浏览器桥接扩展。文档给了两种方式：Chrome Web Store 直接安装，或者从 GitHub Releases 手动加载扩展。

装完后跑自检：

```bash
opencli doctor
```

有多个 Chrome Profile 的话，还可以明确指定给哪个登录态用：

```bash
opencli profile list
opencli profile rename <contextId> work
opencli profile use work
opencli --profile work browser state
```

这里需要明确一件事。OpenCLI 的优势来自**复用浏览器登录态**，所以必须明确 Agent 接管的是哪个 Profile、哪个账号、哪套 Cookie。

### 典型使用方式

直接跑内置命令时，它本身就是一个聚合 CLI：

```bash
opencli list
opencli hackernews top --limit 5
opencli bilibili hot --limit 5
```

给 Agent 用时，文档推荐装 Skill：

```bash
npx skills add jackwener/opencli
```

也可以只装某个技能：

```bash
npx skills add jackwener/opencli --skill opencli-adapter-author
npx skills add jackwener/opencli --skill opencli-browser
```

`opencli-adapter-author` 的定位很明确：既可以让 Agent 实时操作网站，也可以顺手把一个新网站写成可复用适配器。

### 多模型串联

OpenCLI 最有用的地方，在于它把原来分散在网页、桌面应用、浏览器标签页里的动作压成了统一命令面。这样一来，多模型串联就不再非得自己写一堆 SDK wrapper。

一条典型的链路如下：

1. 用 Grok 或 X/Twitter 相关适配器找实时讨论
2. 把结果交给 Claude 结构化整理
3. 再让 ChatGPT 起草文案
4. 把命令真正发出去，或者写进下一步系统

这条链路需要的命令基础，在项目文档里都能找到：

* `twitter search`、`twitter trending` 用来抓实时内容
* `claude ask / send / read / history` 用来做多轮整理
* `gemini new / ask`、`claude new / ask` 这类命令可以并进同一条链
* `twitter post` 用来完成发布动作

不同模型之间有了统一的命令接口。

### 它和 Playwright 这类方式的区别

OpenCLI 和 Playwright 这类工具的分工并不一样：

* Playwright 更偏测试、回归、脚本化固定流程
* OpenCLI 对**带登录态的日常生产工作流**更有用

原因很简单。很多现实任务卡在点进去之后没有登录态、没有个人环境、也没有现成上下文。OpenCLI 把浏览器会话和命令层接起来，刚好补上了这一截。

![OpenCLI GitHub 预览图](https://gastigado.cnies.org/d/public/github-og-opencli.png)

## 飞书 CLI：把 Agent 结果写回文档、日程和待办

### 飞书 CLI

官网：<https://open.feishu.cn/document/home/index>

飞书 CLI 的官方仓库名是 `larksuite/cli`，标题叫 `lark-cli`。但从定位上看，它就是官方维护的飞书 / Lark CLI。开头第一段已经说明了它的身份：**The official Lark/Feishu CLI tool, maintained by the larksuite team — built for humans and AI Agents.**

飞书 CLI 和前两个项目解决的问题不一样。CLI-Anything、OpenCLI 更偏"怎么接工具"，飞书 CLI 更偏"怎么把成果写回业务系统"。

很多人的工作流起点是 Codex 或 Claude Code，但跑完 agent task 之后，结果常常还停在终端里，仍然得手动复制进文档、会议纪要或者日程系统。飞书 CLI 补的就是这一段。

### 项目能力

截至 2026 年 5 月 16 日核对项目文档时，官方写的是：

* 覆盖 17 个业务域
* 提供 200+ 命令
* 内置 24 个 Agent Skills

能力表里已经明确列出：

* Docs：创建、读取、更新、搜索文档
* Markdown：创建、获取、覆盖 Drive 原生 `.md` 文件
* Calendar：查看与创建日程、查找会议室、空闲时间建议
* Tasks：创建、查询、更新、完成任务
* Meetings / Minutes：查询会议记录、会议纪要、AI 总结、Todo、录音录像
* Messenger：发消息、回消息、搜索消息

这些场景基本都能在能力表里对上：

* 调研后写入飞书文档
* 安排出差日程
* 读取飞书妙记
* 自动生成会议纪要
* 补 Todo

### 安装、配置和登录

官方推荐安装方式：

```bash
npx @larksuite/cli@latest install
```

如果从源码编译，文档还要求 Go `v1.23+` 和 Python 3。

随后是配置和登录：

```bash
lark-cli config init
lark-cli auth login --recommend
lark-cli auth status
```

文档还单独给了 Agent 模式的说明：

* `lark-cli config init --new` 会在后台输出授权 URL
* `lark-cli auth login --recommend` 同样需要用户在浏览器里完成授权
* 这些步骤要把授权链接提取出来再交给用户确认

官方在这里留了很明确的人工确认环节：Agent 可以驱动流程，但应用配置和授权还是要回到人手里确认。

### 文档、日历、会议纪要、待办怎么落地

文档里已经给了几条很实用的示例。

文档写入示例：

```bash
lark-cli docs +create --api-version v2 --doc-format markdown --content $'<title>Weekly Report</title>\n# Progress\n- Completed feature X'
```

这条命令很适合接在 Agent 的调研、周报、会议总结后面。上游模型把内容整理成 Markdown，下游一条命令直接落到飞书文档里。

再看日历：

```bash
lark-cli calendar +agenda
```

文档还列出了更多日历相关能力，比如空闲时间查询、会议室查找、实例视图和权限域配置。这正好对应"跟 AI 对话，让飞书 CLI 安排出差日程"的用法。

会议纪要和妙记这一块，文档里没有直接写"妙记"两个字，但有两组能力非常接近：

* `lark-vc`：查询 meeting minutes，包括 summary、todos、transcript
* `lark-minutes`：处理 minutes metadata、AI artifacts、summary、todos、chapters，支持上传音视频生成 minutes

文章里写"读飞书妙记、写会议纪要、安排 Todo"是有依据的，只是更准确的说法要落在文档里的 `meeting minutes`、`summary`、`todos` 这些术语上。

任务管理则是另一条线：

* `lark-task`：任务、任务列表、子任务、提醒、成员分配

这条线刚好接住会议纪要里的待办拆解。

### 一个更完整的飞书工作流

把前面的 OpenCLI 和这里的飞书 CLI 接起来，一条常见链路大概是这样：

1. 用 OpenCLI 或其他搜索工具抓实时讨论和外部资料
2. 让 Claude、ChatGPT 或 Gemini 整理成结构化摘要
3. 用飞书 CLI 直接写进文档
4. 顺手创建日程、补会议纪要、拆待办

写成命令思路，大概会长这样：

```bash
# 1. 外部资料检索
opencli twitter search "opencli" --limit 20

# 2. 结构化整理
opencli claude new
opencli claude send "请把刚才的结果整理成一份 5 点摘要，并补一个结论段"
opencli claude read

# 3. 写入飞书文档
lark-cli docs +create --api-version v2 --doc-format markdown --content $'<title>CLI 调研</title>\n# 结论\n- ...'

# 4. 查看日程或继续派生任务
lark-cli calendar +agenda
```

实际接入时，中间结果通常会做成变量或脚本，不会手工一段段贴。这条链路已经足够说明，飞书 CLI 解决的是"生产结果真正落回业务系统"这一段。

![飞书 CLI GitHub 预览图](https://gastigado.cnies.org/d/public/github-og-lark-cli.png)

## CLI、MCP、Skill 怎么分工

这三个词最近经常被混着说，但它们做的事并不一样。

### CLI：执行面

CLI 负责把动作压成稳定命令：参数是什么，输出是什么，失败了报什么错。它最适合做高频、可组合、可脚本化的动作。

更直白地说，**CLI 是 Agent 最容易稳定调用的执行面。**

### MCP：连接面

MCP 更像"把工具能力接进模型上下文"的协议层。它适合把搜索、浏览器、数据库、抓取器这类工具注册给模型，让模型知道"我能调用什么"。

换成工作流语言，**MCP 负责接入，CLI 负责执行。**

### Skill：方法面

Skill 解决的重点不在"有没有接口"，而在"这类任务应该怎么走"。比如：

* OpenCLI 的 `opencli-adapter-author` 会告诉 Agent 怎样勘测一个网站、怎样写适配器、怎样验证
* 飞书 CLI 的一组 Skills 会把授权、身份切换、命令边界、安全提示一起打包
* CLI-Anything 的 Skill 则负责把"给某个软件生成 CLI"这件事做成可复用流程

换成更落地的说法，**Skill 是把经验压成可重复工作流。**

### 放在一起看

更实用的理解方式是：

* **MCP** 让模型知道外面有工具
* **CLI** 让工具变成稳定命令
* **Skill** 让 Agent 知道这类命令该怎么串

这三者并不互斥，更常见的是叠在一起用。也因为这样，不少人又开始重视 CLI：MCP 负责接入，执行还是要落到稳定的命令面上。

## 登录态复用、权限与误操作风险

这类工具一旦真的好用，风险也会一起变真实。

### 1. 登录态复用有成本

OpenCLI 最强的地方，就是复用你已经登录的浏览器 Profile。但这意味着：

* Agent 能看到那个 Profile 当前可见的页面和会话
* Cookie、已登录身份、已保存偏好都会参与执行
* 如果 Profile 里同时登录了工作账号和私人账号，选错一次就可能把结果写错地方

所以在实际使用里，最好把自动化用的浏览器 Profile 单独隔出来，不要和日常混用。

### 2. 授权范围要收窄

飞书 CLI 的安全章节写得很明确：Agent 在你授权的范围内，会以你的身份执行动作，风险包括敏感数据泄露、未授权操作、提示注入等。

这类工具刚上手时最容易犯的错，就是图省事直接给一大串权限。更稳妥的做法是：

* 按域授权，不要一次放开全部业务域
* 文档、日历、任务、会议最好分阶段开
* 能用只读就别先给写权限
* 高风险命令先加 `--dry-run`

文档甚至专门建议，集成了飞书 CLI 的机器人更适合放在私人对话里，不要直接扔进群聊里让所有人都能触发。

### 3. 误操作一定会发生，关键是怎么兜底

Agent 调 CLI 当然会出错，而且一旦出错，速度更快、影响面也更大。

常见问题包括：

* 把搜索结果发到错误平台
* 把草稿写进正式文档
* 在错误账号下创建日程或任务
* 读到了不该暴露的浏览器页面内容

更稳妥的做法是：

* 把写操作和读操作分开
* 对外发布前保留人工确认
* 重要命令跑测试账号、测试空间或测试文档库
* 让生成链和发布链分离，中间留审阅点

## 生产环境中的典型工作流

把三类项目放在一起，一个比较完整的 Agent 流程会是这样：

1. **外部接入**：OpenCLI 复用浏览器登录态，抓 X/Twitter、Bilibili、知乎、Hacker News 等实时内容
2. **能力补齐**：遇到某个目标软件还没有可用命令面时，就用 CLI-Anything 补一层 CLI
3. **方法编排**：用 Skill 约束搜索、提取、整理、校验和写入顺序
4. **结果落地**：飞书 CLI 把内容写进文档、加到日程、接进会议纪要和任务系统

这条链把从信息抓取到组织内落地的过程连起来了。

## 相关视频与文档

### 视频参考

### 官方文档与仓库

* CLI-Anything GitHub：<https://github.com/HKUDS/CLI-Anything>
* CLI-Hub：<https://clianything.cc/>
* OpenCLI GitHub：<https://github.com/jackwener/OpenCLI>
* OpenCLI 官网：<https://opencli.info/>
* 飞书 CLI GitHub：<https://github.com/larksuite/cli>
* 飞书开放平台首页：<https://open.feishu.cn/document/home/index>
* 飞书服务端 API 列表：<https://open.feishu.cn/document/ukTMukTMukTM/uYTM5UjL2ETO14iNxkTN/server-api-list>
* 飞书应用权限列表：<https://open.feishu.cn/document/ukTMukTMukTM/uYTM5UjL2ETO14iNxkTN/scope-list>
* 飞书自建应用开发流程：<https://open.feishu.cn/document/home/introduction-to-custom-app-development/self-built-application-development-process>

## 为什么 CLI 又回来了

CLI 重新受到关注，与 Agent 工作流对执行接口的需求有关。MCP 负责接入，Skill 负责流程，CLI 负责落地执行。三层分工摆正之后，就更容易判断：什么时候该接浏览器，什么时候该补命令面，什么时候该把结果直接写回协作系统。

---

---
url: https://ain.hmgf.hxcn.space/ai/agent-read-wechat-202605.md
description: 从 Agent Reach 和 wx-cli 两条路线出发，梳理 Agent 接入微信公众号与本地微信数据的方式、安装步骤、使用方法和主要风险。
---

# Agent 读微信的两条路

公众号文章、社群聊天、朋友转发、会议通知、行业八卦、甲方需求——很多信息不会出现在公开网页，而是先在微信里流动。对做内容、做调研、做社群运营的人来说，微信同时也是中文资料入口。

Agent 能不能读微信？能，但路线不止一条。

* **Agent Reach**：不碰本地聊天数据库，重点是给 Agent 接出"微信公众号搜索 + 文章阅读"这类渠道。
* **wx-cli**：直接在本机读取微信本地数据，能查会话、搜消息、拉历史、看联系人和群成员。

这两类工具解决的问题差得很大，风险也不在一个层面。公众号检索更像外部资料读取，本地消息读取则已经碰到隐私、聊天记录和企业信息风险了。

## 两条路线怎么读

### Agent Reach 读的是"微信外层内容流"

Agent Reach 当前把"微信公众号"列进支持渠道，能力表述是：**搜索 + 阅读公众号文章（全文 Markdown）**。它提供的是一条公众号检索通道，让 Agent 能搜文章、读文章、整理文章。

按当前渠道说明，微信公众号这一项的实现选型是：

* `wechat.py`
* `Exa`
* `Camoufox`（可选增强）

它处理的是公众号文章这类公开或半公开内容，不碰你微信客户端里的私人聊天。

### wx-cli 读的是"本地微信数据库"

wx-cli 则完全不一样。它的首页定位是：**从命令行查询本地微信数据**。它能处理的是：

* 会话
* 聊天记录
* 搜索
* 联系人
* 群成员
* 群昵称
* 收藏
* 统计
* 导出

它属于"本地聊天记录工具层"。群消息总结、聊天资料回顾、公众号素材沉淀、个人知识整理这类需求，用它会更直接；一旦碰到公司微信、客户资料、内部群聊，风险就会明显上升。

## Agent Reach：微信公众号入口

### Agent Reach

安装文档：<https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/install.md>

Agent Reach 把自己定义成一个 **Agent 脚手架**。它的重点在于接入 Twitter、Reddit、YouTube、GitHub、RSS、公众号这些常见资料源，再交给 Agent 调用。

项目当前对微信公众号这条线路的说明比较明确：

* 支持平台里有"微信公众号"
* 能力写的是"搜索 + 阅读公众号文章（全文 Markdown）"
* 当前渠道选型是 `Exa` + `Camoufox`
* 安装命令里可以把 `wechat` 作为 channel 单独装进去

这些点都能在公开资料和安装指南里对上。

### 项目能力

公众号这一段的关键信息主要有四点：

1. **支持微信公众号文章搜索和阅读**
2. **默认不读取本地微信聊天记录**
3. **按 channel 方式接入**
4. **把结果尽量转成 Agent 更好消费的 Markdown**

安装指南里还列出了支持的可选渠道名，里面包含：

```text
wechat
```

对应命令形式是：

```bash
agent-reach install --env=auto --channels=wechat
```

如果用户要一口气全装，也可以：

```bash
agent-reach install --env=auto --channels=all
```

### "绕过反爬读全文"该怎么写才稳

公开资料中能确认的是：

* 公众号搜索
* 文章阅读
* 全文 Markdown 化
* 依赖 Exa / Camoufox / 相关上游工具

按一手资料写，可以稳妥地表述为：**Agent Reach 当前支持微信公众号文章搜索与全文 Markdown 阅读**。至于具体是不是"绕过反爬"，那属于底层工具和站点策略之间的动态变化，不适合写成静态结论。

### 安装和使用方式

Agent Reach 的官方上手方式很"给 Agent 自己装"：直接把安装文档链接丢给 Claude Code、OpenClaw、Cursor 这类 Agent。

官方安装文档给的是：

```text
帮我安装 Agent Reach：https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/install.md
```

安装文档里实际让 Agent 执行的是类似这样的命令：

```bash
pipx install https://github.com/Panniantong/agent-reach/archive/main.zip
agent-reach install --env=auto
agent-reach install --env=auto --channels=wechat
agent-reach doctor
```

担心它自动改系统时，也可以改用安全模式或 dry run：

```bash
agent-reach install --env=auto --safe
agent-reach install --env=auto --dry-run
```

这组命令主要面向已经在用终端 Agent 的人，作用就是给 Agent 增加一个外部资料入口。

### 使用场景

Agent Reach 主要对应下面几类场景：

* 搜某个公众号最近写了哪些文章
* 把公众号文章转成 Markdown 再总结
* 做公众号素材池或选题库
* 让 Agent 从公开中文内容流里持续收集资料

比如你要做"公众号内容追踪"，链路可以是：

1. 让 Agent Reach 搜相关文章
2. 把正文拉成 Markdown
3. 让 Agent 提炼观点、金句、争议点
4. 再转进自己的选题库或写作草稿

它的重点在"公众号文章内容流"，不在"我的本地微信聊天记录"。

## wx-cli：直接读本地微信数据

### wx-cli

wx-cli 走的是更重的一条路。它不去搜公众号网页，直接在本机读微信数据。项目首页把它写得很清楚：这是一个本地工具，特点包括：

* 单一 Rust 二进制
* `history` / `search` / `sessions` / `new-messages` 等命令都对 Agent 友好
* **完全本地**：数据不出本机，实时解密，无需全量预解密

这句"完全本地"很重要。它说明的是**数据处理路径在本机**，不是在承诺"绝对安全"或者"绝对不会封号"。公开资料也没有这样承诺。

### 项目能力

项目列出来的核心能力比较扎实：

* `wx sessions`：看最近会话
* `wx unread`：看未读
* `wx new-messages`：看增量新消息
* `wx history`：拉历史消息
* `wx search`：全库搜索
* 还支持联系人、群成员、收藏、导出、统计

这就足够支撑几个很具体的场景：

* 群消息自动总结
* 公众号素材收集
* 项目聊天检索
* 周会前回看讨论上下文
* 持续内容生产时按关键词拉素材

### 安装方式

文档给了三类安装入口。

npm 推荐方式：

```bash
npm install -g @jackwener/wx-cli
```

如果你是直接给 Agent 安装 Skill，仓库里保留了这条命令：

```bash
npx skills add jackwener/wx-cli
```

这条必须原样保留。装完后，Agent 会自动读取仓库里的 `SKILL.md`。

Windows 还有一条官方 PowerShell 安装脚本：

```powershell
irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 | iex
```

macOS / Linux 则有 shell 安装脚本：

```bash
curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh | bash
```

### Windows 安装：命令和权限都别省

* `npx skills add jackwener/wx-cli`
* 管理员 PowerShell
* `wx init`

更完整的 Windows 路线可以写成这样：

```bash
npx skills add jackwener/wx-cli
```

然后在 **管理员 PowerShell** 里安装或初始化。Windows 安装方式是：

```powershell
irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 | iex
```

初始化命令则必须保留：

```powershell
wx init
```

这里必须用管理员 PowerShell。原因有两个：

1. 初始化会碰到本地微信进程和相关系统资源
2. 安装脚本和后续命令需要足够权限把二进制放到用户路径、读取或准备本地环境

执行顺序可以理解成：

1. 装 Skill，让 Agent 知道怎么调用 wx-cli
2. 用管理员 PowerShell 装好可执行文件
3. 保持微信正在运行
4. 执行 `wx init`
5. 用 `wx sessions` 验证是否成功

安装脚本 `install.ps1` 里也明确写了安装完成后的快速开始提示：

```powershell
wx init
wx sessions
wx --help
```

### macOS 安装：四步都要做

* 对 `/Applications/WeChat.app` 签名
* TCC reset
* 重启微信
* `sudo wx init`

文档里的命令是：

```bash
codesign --force --deep --sign - /Applications/WeChat.app

for s in ScreenCapture Camera Microphone AppleEvents AddressBook \
         SystemPolicyDocumentsFolder SystemPolicyDownloadsFolder SystemPolicyDesktopFolder; do
  tccutil reset "$s" com.tencent.xinWeChat
done

killall WeChat && open /Applications/WeChat.app

sudo wx init
```

这四步各自的作用要说清楚。

#### 1. 重新签名 WeChat.app

```bash
codesign --force --deep --sign - /Applications/WeChat.app
```

wx-cli 的 macOS 指南写得很清楚：某些情况下要扫描微信进程内存，就得先处理微信应用的签名状态。文档采用的是 ad-hoc 重签名路线。

重签名的代价不小。官方文档提示，微信更新后可能要重做；部分功能、小程序或系统权限行为也可能受影响。

#### 2. 重置 TCC 授权记录

```bash
for s in ScreenCapture Camera Microphone AppleEvents AddressBook \
         SystemPolicyDocumentsFolder SystemPolicyDownloadsFolder SystemPolicyDesktopFolder; do
  tccutil reset "$s" com.tencent.xinWeChat
done
```

TCC 是 macOS 的隐私权限系统。配套文档解释得很明确：重签名之后，旧的权限记录可能和新的 code signature 对不上。跳过这一轮重置，就会出现"系统里看着已经授权，实际调用还是被拒绝"的情况。

这里是在清理旧权限状态，让微信下次重新向系统申请这些权限。

#### 3. 重启微信

```bash
killall WeChat && open /Applications/WeChat.app
```

这一段不能省。wx-cli 的文档强调，签名和权限状态改完以后，需要让微信完全退出再重开，并等它重新登录完成，否则新状态不会真正生效。

#### 4. 用 sudo 初始化

```bash
sudo wx init
```

这是初始化阶段的管理员操作。`sudo` 说明这里需要管理员权限。执行完后再跑：

```bash
wx sessions
```

如果能看到最近会话，说明初始化成功。

### macOS 这条路更折腾

wx-cli 的 `macos-permission-guide.md` 写得非常细，比首页说明还值得看。里面至少有几件事必须在正文里点出来：

* 如果微信是 Apple 官方签名，内存提取权限会受 Hardened Runtime 影响
* SSH、Terminal、本机 GUI、sudo、TCC Developer Tool 授权，分属不同层面的权限
* ad-hoc 重签名后，macOS 可能频繁弹出"微信想访问其他 App 的数据"
* 重签名可能影响登录态、小程序和部分权限行为
* 不同微信版本、不同签名状态、不同 macOS 版本，表现并不完全一样

macOS 这条路虽然能走，但绝对不能写成"装完就好"。它比 Windows 明显更重，也更容易踩隐私和权限坑。

### 典型使用方式

文档给出的这几个命令已经足够做日常工作：

```bash
wx sessions
wx unread
wx new-messages
wx history "张三"
wx history "AI群" --since 2026-04-01 --until 2026-04-15
wx search "关键词"
wx search "会议" --in "工作群" --since 2026-01-01
```

放到 Agent 工作流里，常见用法大概有三类。

#### 1. 群消息总结

项目群、学习群、临时活动群都适合这样用。把一段时间内的消息拉出来，再交给 Agent 总结重点、分歧和待办。

#### 2. 公众号素材收集

如果你平时会把文章转发到聊天窗口、文件传输助手或收藏，wx-cli 可以帮助你按关键词回捞这些内容，再让 Agent 分类。

#### 3. 持续内容生产

做选题库的人很容易遇到一个问题：灵感散在群里、朋友聊天里、转发文章里、收藏里。wx-cli 的价值就是把这些分散片段拉回一个命令行入口，让 Agent 帮你归档和筛选。

## 选型建议

如果你只想让 Agent 读公众号文章、搜公开内容，直接用 Agent Reach 就行。

如果你要处理的是：

* 本地聊天记录
* 群消息沉淀
* 联系人和会话检索
* 收藏和素材导出

那就得看 wx-cli。

也可以把两者串起来用：

* Agent Reach 负责公众号搜索和公开内容阅读
* wx-cli 负责你本机微信里的聊天和素材整理

一个读外层内容流，一个读本地数据库，分工很直观。

## "不联网不封号"这种说法要写得更保守

项目文档中没有"官方保证不封号"的表述，"不联网不封号"的说法需要谨慎看待。

一手资料能确认的是：

* wx-cli 强调**完全本地**
* 数据处理在本机
* 不需要全量预解密
* 需要针对不同系统做初始化和权限处理

但"完全本地"不自动等于"绝对安全"，更不等于"不会触发风控"。实际风险至少包括：

1. 微信客户端更新后行为变化
2. macOS 重签名、权限、内存读取路径的副作用
3. 企业微信、工作群、客户群里的敏感信息暴露
4. Agent 对本地聊天内容的误总结、误归档、误外发

更稳妥的表述是：**wx-cli 当前路线以本地数据读取为主，减少了把聊天记录发到第三方服务的需要，但这不能替代你自己对账号风险、隐私责任和合规责任的判断。**

## 隐私与公司数据风险

只要工具开始读微信，风险说明就不能放在文末一笔带过。

### 1. 私聊和群聊是高敏感数据

聊天记录里会混着：

* 个人隐私
* 客户资料
* 报价和合同信息
* 公司内部讨论
* 未公开项目进度

这些内容就算不出本机，也不代表可以随便交给 Agent 长期读取。更稳的做法是：

* 只在明确任务时拉取必要范围
* 先按时间、群、关键词缩小范围
* 不要把全量聊天长期喂给 Agent

### 2. 公司环境中的制度约束

如果你在公司电脑、公司微信、客户群环境里跑 wx-cli，重点已经变成"你是否有权这么做"。很多组织对聊天记录、客户数据、个人信息、日志留存都有明确制度。

### 3. 对外发送链路最好断开

更危险的是"读完再自动发"。

如果要把 wx-cli 接进内容工作流，建议至少做到：

* 读取和总结可以自动化
* 对外发布和转发保留人工确认
* 涉及客户、同事、公司内部信息时不做自动发布

## 更实际的使用建议

把这两类工具放回现实场景，可以这样分：

* **资料检索**：Agent Reach
* **聊天回顾**：wx-cli
* **公众号文章整理**：两者都能参与，但入口不同
* **群消息总结**：wx-cli
* **持续内容生产**：wx-cli 拉本地素材，再由 Agent 整理；公开补充材料再交给 Agent Reach

如果你只想"让 Agent 看看公众号最近在写什么"，没有必要碰本地微信数据库。

如果你真的要让 Agent 读自己的微信聊天，最好把权限、风险和设备范围想清楚，再动手。

---

---
url: https://ain.hmgf.hxcn.space/ai/de-ai-frontend-design-202605.md
description: 把"压字重、减容器、提可读性"整理成一组可复用的前端约束，并落成可调用的 Skill。
---

# 前端去 AI 味：从字重、容器到 Skill

AI 生成页面难看，问题出在默认答案太像统计平均值。约束不够时，模型会滑向训练语料里最安全、最常见、最少挨骂的那一类界面：大粗标题、圆角卡片、浅灰辅助文案、每块内容都单独圈起来、按钮和状态标签塞满屏幕。这种做法胜在稳，代价是没有辨识度。

Anthropic 在 [《通过 Skills 改善前端设计》](/ai/improving-frontend-design-through-skills) 和 Frontend Aesthetics Cookbook 里把这个问题讲得很清楚：模型会向高概率的默认设计收敛。落到前端上，收敛出来的就是模板 UI。不一定丑，但品牌感、信息密度和阅读节奏会被一起磨平。

这篇讲怎么把"前端去 AI 味"整理成一套能落地的规则，再把它做成 Skill，让模型在生成前端前带上约束。

## 项目介绍

* GitHub：<https://github.com/anthropics/claude-code/tree/main/plugins/frontend-design>
* GitHub：<https://github.com/anthropics/claude-cookbooks/blob/main/coding/prompting_for_frontend_aesthetics.ipynb>
* 官网：<https://www.anthropic.com/news/skills>
* 文档：<https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf>

## 模型为什么总会做出模板 UI

模型做前端时，最爱用的几招很固定：加粗、加卡片、加圆角、加阴影、加色块、加状态点。原因并不复杂。

第一，训练语料里充满了组件库、后台模板、SaaS 落地页和教程示例。它们本来就偏向清楚、规整、低风险。模型只要照着这些平均值采样，成品就不容易出大错。

第二，粗标题、独立卡片、明显边框，是最省事的层级表达方式。模型不需要认真处理信息节奏，只要把每一块内容框起来，页面看上去就像已经做完了。

第三，很多生成请求本身就很短。只说"做一个 dashboard"或"做一个 landing page"，模型就会自动回到最熟的那套答案。Anthropic 的 cookbook 把这个现象写得很直白：没有额外引导时，模型会默认白底、紫色渐变、普通字体和保守布局。

下面这组示例很能说明问题。相同任务下，默认生成和加入前端设计约束后的结果，差别不在功能，而在节奏、层级和记忆点。

### SaaS 落地页对比

![默认提示下的 SaaS 落地页](https://gastigado.cnies.org/d/public/baseline-saas.png)

![加入前端美学约束后的 SaaS 落地页](https://gastigado.cnies.org/d/public/distilled-saas.png)

### 后台界面对比

![默认提示下的后台界面](https://gastigado.cnies.org/d/public/baseline-dashboard.png)

![加入前端美学约束后的后台界面](https://gastigado.cnies.org/d/public/distilled-dashboard.png)

默认结果的问题，不只是"像 AI"，它会把所有元素推到同一音量上：标题太硬，辅助信息太轻，容器太多，留白没有形成秩序，视线一路都在撞框。

## 12 条去 AI 味清单

> 1. 所有的字，尤其是标题，都不要过粗。
> 2. 小字不要显得太小。
> 3. 避免使用全大写单词。
> 4. 避免使用太多卡片。
> 5. 尽量避免阴影。
> 6. 尽量避免状态圆点。
> 7. 白背景上避免太淡的灰色，提高对比度和可见性。
> 8. 红色不要那么鲜亮。
> 9. 避免卡片套卡片。
> 10. 金额数字和标题使用更有风格的字体但仍需是常见 UI 字体。
> 11. 广告右侧配插图。
> 12. 整体原则：优先做减法，用间距和分隔线替代容器，让视线流动而不是撞墙。

这 12 条里，最有用的部分集中在"少做什么"。模型天然偏向加法，人做界面时更常靠减法出层级。

## 字重和排版：别让标题用吼的

字重问题是 AI 页面最容易被认出来的地方。模型很爱把标题直接拉到黑体极粗，再把按钮、标签、统计数字、价格一起抬粗。结果就是：页面里没有清楚主次，只有一群抢前排的人。

### 标题压下来，层级才会出来

"标题不要过粗"不等于让页面全变细，是把粗体留给少数关键节点：主标题、关键数据、少量需要停顿的位置。常见页面里，`600` 到 `700` 的标题已经够用，很多营销页甚至 `500` 到 `600` 更顺眼。标题一旦全往 `800`、`900` 冲，页面会有健身房海报那种顶头感，信息显得又硬又累。

### 小字要小得清楚，不要小得像灰尘

"小字不要显得太小"说的是阅读门槛。模型为了做层级，喜欢把辅助信息压到 12px、11px，再配极浅灰。这样的次级信息肉眼看上去像被撤退了，用户还是得读，只是读得更费劲。

WCAG 2.2 对正文文本给出的最低对比度要求是 4.5:1，大号文本是 3:1。文档还专门提醒：细字和特殊字体在实际渲染时会显得比设定颜色更淡。页面里如果同时出现小字号、细字重、浅灰字，损失会叠加，设计稿里看起来"高级"，落到屏幕上只剩发虚。

### 全大写会把识别速度拖慢

全大写单词的问题，不在审美争议，在阅读轮廓。字母变成整齐方块后，词形差异变弱，按钮、标签、分组标题都会带上模板零件的味道。少量缩写和导航项可以保留大写，整页大面积铺开就会显得发硬、发旧，还会把语气抬得过满。

### 标题和金额需要一点性格，但别跑到装饰字体那边去

"金额数字和标题使用更有风格的字体但仍需是常见 UI 字体"，这条说得很准。标题和金额确实可以承担一点识别度，但方向应该落在稳定、常见、屏幕友好的字体家族上，比如 `IBM Plex Sans`、`Geist`、`Manrope`、`SF Pro Display`、`Segoe UI Variable` 这一类。它们有自己的骨架和数字气质，放在价格、统计数字、章节标题上能拉出记忆点，又不会把界面拖进海报设计。

最容易翻车的情况，是标题一套字体，数字再换一套炫技 display font，正文又回系统字体。这样很难形成统一风格，只会让几套字体互相打架。标题、数字和正文最好还是待在同一套字体体系里。

## 容器减法：框少一点，页面就会顺很多

最锋利的几句评论，全指向同一个问题：AI 生成 UI 总想把每个元素框起来。卡片、卡片里的卡片、卡片里的列表、列表里的标签，再叠一个 hover 阴影，页面就会进入塑封状态。

### 太多卡片，会把信息切得像抽屉墙

卡片本来是好工具。跨背景分组、可拖拽单元、独立操作对象、带状态切换的模块，用卡片都合理。问题出在"什么都卡片化"。一旦统计、说明、列表、提示、筛选器全都各自独立成卡，页面读起来就像走迷宫。

容器越多，视线越容易频繁停顿。人眼扫页面时，需要的是连续路径，不是连续撞墙。很多时候，留白、分栏、标题间距、细分隔线就足够分组，根本不用每块都加框。

### 圆角卡片更容易显模板味

卡片本身已经很强提示，圆角、描边、浅阴影再叠上去，模板味会翻倍。尤其是营销页和中后台首页，圆角卡片一多，页面立刻有"组件库截图拼接"的感觉。

做减法时，最见效的动作有三个：

* 把纯信息展示模块从卡片里拿出来，直接回到页面栅格。
* 把同类模块合并成一个信息区，别一格一格切开。
* 把圆角收窄，或者只在需要点击、拖拽、悬浮反馈的对象上保留圆角。

### 阴影别当默认层级手段

模型偏爱阴影，因为它能快速制造"有层次"的假象。可一旦每块都有阴影，页面会像飘在雾里。白底界面尤其明显：浅阴影 + 浅灰边 + 圆角，最后全页都在发虚。

常规处理是靠布局层级解决大部分问题：上下间距、左右对齐、字体对比、色块密度。阴影只留给确实需要浮起的元素，比如弹层、悬浮操作、拖拽对象。大部分列表、表单、数据区，只靠背景差异和分组线就够了。

### 状态圆点要少用

状态圆点本来是高密度界面里的速记符号。到了模型手里，它经常变成每一行都附赠一个小绿点、小红点、小黄点。数量一多，信息密度没有真正提升，视觉噪声却先上来了。

如果状态本身不是页面核心，文字、边框、标签色就能表达清楚。只有在在线状态、系统运行态、告警看板这类场景里，圆点才值得保留。很多常规业务列表，删掉圆点后会清爽不少。

### 卡片套卡片，要优先删

原始评论里那句"卡片套卡片最拉胯"判断非常准。最常见的翻车样子，是外层一个概览卡片，里头再放三个统计卡片，下面再嵌一个列表卡片，列表行里还有标签胶囊和状态小卡。每一层都在强调自己，结果是谁都不突出。

外层容器已经成立时，内层直接回到排版层面：标题、说明、数值、行间距、分隔线。list 条目之间那条"若隐若现的分隔线"，比再加一个小卡片更有效。它不会打断阅读，却能给视线一个稳定落点。

## 颜色和可读性：白底浅灰最容易显旧

很多 AI 页面看着"高级"，只是对比度不够。尤其白背景上放很淡的灰字，再配细字重，页面会像盖了一层雾。

### 灰色别淡到只剩气氛

辅助文本、占位符、说明文字需要退后，但不能退没。WCAG 的要求本来就把可读性放在第一位：普通文本至少 4.5:1，对比不足时，用户首先失去的就是扫描速度。大量产品页里最该改的，常常不是主色，问题更多出在辅助灰的亮度。

经验是：

* 主正文优先保证对比，不要把"轻"放在前面。
* 次级文字退一层就够，别连续退两三层。
* 浅边框和浅文字不要同时出现得太多。

### 红色收一收，错误提示会更可信

"红色不要那么鲜亮"针对的是语义强度。高饱和大红很容易把普通提醒写成严重报错，尤其白底下会异常刺眼。错误、风险、警告这些语义，本来就已经自带注意力，不需要再把颜色拉到最尖。

稍微降饱和、压亮度的红色，更耐看，也更像真实产品里的长期配色。用户会更愿意读内容本身，而不是先被颜色刺到。

### 分隔线很有用，用来引导视线就够了

原始评论里提到 list 条目之间可以加若隐若现的分隔线。很多 AI 页面爱靠卡片切分列表，实际上细分隔线更适用于长列表和设置页。它能保持连续阅读，又能帮用户在扫描时快速对齐每一行的起止。

细分隔线更符合日常产品界面，少一点展示模板味。

## 广告位和插图：给页面一个记忆点

"广告右侧配插图"在修一个更大的问题：AI 页面太容易左右对称、上下均分、每块都只剩标题和按钮。

右侧插图的价值有三层：

* 它能打破整页同构模块的重复感。
* 它能把营销信息从"另一张卡片"变成"一个有视觉重心的区域"。
* 它能替代一部分多余标签、徽章和说明文案。

很多会员升级、功能推广、空状态页面，文字已经够多了，再塞卡片、塞 chips、塞状态色块，页面只会更吵。插图、截图、产品局部预览、简单图形，都能把信息承载从纯文本里分出去。

## 把这些规则做成 Skill

如果这些规则只放在聊天里，下一次还得重说一遍。做成 Skill 之后，模型在接到前端任务时就能自动加载同一套约束。

Anthropic 的 Skill 文档给了一个很实用的骨架：`SKILL.md` 是必需文件，`scripts/`、`references/`、`assets/` 可以按需补。Skill 的重点，不在一句"你是资深设计师"，而在把判断标准、检查顺序和修正动作固定下来。

### 一个够用的目录结构

```text
frontend-de-ai/
├─ SKILL.md
├─ references/
│  ├─ typography-and-contrast.md
│  └─ layout-reduction.md
└─ assets/
   └─ example-panels/
```

### `SKILL.md` 里最该写什么

可以把上面的规则压成三个阶段：生成前、生成中、交付前。

```md
---
name: de-ai-frontend-review
description: 为落地页、后台、定价页和设置页生成更克制、做过取舍的界面。重点检查字重、容器数量、对比度、颜色饱和度和视觉节奏。
---

在开始编码前，判断页面类型：营销页、后台、表单页、设置页、广告位。

始终遵守：
- 标题不要过粗，小字不要过小，避免全大写单词。
- 优先用间距、分栏和分隔线建立层级，减少卡片、卡片嵌套、阴影和状态圆点。
- 白底界面避免过浅灰字，普通文本对比度至少接近 WCAG AA 水平。
- 红色降低饱和度，别把普通提示做成报警灯。
- 标题和金额可用更有性格的常见 UI 字体，正文维持高可读性。
- 广告或推广区优先给右侧图形、插图或产品预览，不要只堆文案和按钮。

交付前自检：
1. 页面里有多少个非必要卡片？能删掉多少？
2. 是否出现卡片套卡片？
3. 次级文字是否因为过浅或过小而难读？
4. 标题是否明显粗过头？
5. 状态圆点是否能用文字或标签替代？
6. 是否还有一眼能看出的模板式圆角 + 阴影组合？
```

### Skill 最见效的地方，在"自检"这一轮

很多前端 Skill 只负责生成，不负责回头看。去 AI 味这类规则，最有效的部分恰好在第二遍检查。模型第一次输出后，应该再跑一次检查：

* 把容器数数出来。
* 找出所有 `font-weight: 800/900` 的标题。
* 找出正文和辅助文案的字号、颜色、对比度。
* 找出不必要的 badge、dot、shadow。
* 找出所有嵌套 card。

这一步可以靠口头指令，也可以加脚本。比如前端仓库里已经有设计 token，就让脚本扫 `color`, `font-size`, `font-weight`, `box-shadow`, `border-radius` 的使用分布；发现超阈值时，要求模型回修。这样 Skill 提供的不只是审美方向，还有可执行的复查流程。

### references 和 assets 该放什么

`references/` 里适合放两类资料：

* 官方规则：对比度、排版、组件规范。
* 团队偏好：品牌字体、按钮语气、定价区写法、广告位素材策略。

`assets/` 里适合放示例插图、版式截图、团队常用图标或空状态素材。这样模型在做营销区、升级区、推广区时，不会只剩通用文案块。

## 可直接用于前端生成前的提示词

下面这段可以直接放到 Claude Code、Codex、Cursor 或团队自定义 Skill 里，作为生成前端前的约束：

```text
你要生成的是可上线的前端界面，不要落回模板 UI。

请按以下规则执行：
1. 标题和整页文字都不要过粗，尤其避免夸张的超粗黑体；小字也不要小到难读。
2. 避免全大写单词，保留正常词形，让按钮、标签和分组标题更符合真实产品界面。
3. 优先用留白、分栏、对齐和细分隔线建立层级，减少卡片数量。
4. 严禁卡片套卡片；如果一个区域已经有外层容器，里面优先回到排版系统。
5. 阴影只给真正浮起的元素，大部分内容区不要默认上阴影。
6. 尽量避免状态圆点，除非页面核心就是监控、在线状态或告警。
7. 白背景上不要用过浅灰文字，保证正文和辅助信息都有足够对比度与可见性。
8. 红色降低饱和度，不要做成刺眼的大红告警灯。
9. 标题和金额数字可以使用更有风格的常见 UI 字体，正文保持高可读性。
10. 广告位、升级区、推广区优先在右侧放插图、产品预览或图形元素，避免整块都只有文案和按钮。
11. 输出前自检：删掉 80% 非必要容器，检查有没有模板式圆角卡片、浅灰细字、过粗标题和无意义装饰。
12. 页面要让视线流动、认知成本和信息主次都更顺，读起来像有人认真做过取舍。
```

## 参考资料

* Anthropic：<https://www.anthropic.com/news/skills>
* Anthropic Frontend Design Plugin：<https://github.com/anthropics/claude-code/tree/main/plugins/frontend-design>
* Anthropic Frontend Aesthetics Cookbook：<https://github.com/anthropics/claude-cookbooks/blob/main/coding/prompting_for_frontend_aesthetics.ipynb>
* Anthropic《The Complete Guide to Building Skill for Claude》：<https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf>
* W3C WCAG 2.2 Contrast Minimum：<https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html>
* 站内参考：[/ai/improving-frontend-design-through-skills](/ai/improving-frontend-design-through-skills)

---

---
url: https://ain.hmgf.hxcn.space/ai/pwa-native-ui-experience-202605.md
description: >-
  从 standalone 标题、display-mode、滚动溢出、默认指针、禁止选择、manifest 图标、router.replace 到
  window controls overlay，整理一组让 PWA 更像原生 App 的前端细节。
---

# PWA 原生体验细节

用 Web 技术做原生体验，差距往往不出在大功能上，反而出在一串很碎的小地方：标题栏有没有多余文字，滚动到顶时会不会漏白，鼠标指针像不像 App，文字是不是到处都能选中，图标装到不同系统后会不会糊，路由切换是不是像网页后退栈，桌面标题栏有没有把可用空间吃掉。

这些问题单看都不大，叠在一起就很像“网页套壳感”。这一篇不讲 PWA 基础，只把几条最常见、最容易补的细节拆开说。

## 两类官方资料的分工

### PWA standalone / display-mode / manifest / icons

文档：<https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Create_a_standalone_app>
文档：<https://developer.mozilla.org/en-US/docs/Web/CSS/@media/display-mode>
文档：<https://developer.mozilla.org/en-US/docs/Web/Manifest>
文档：<https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Define_app_icons>
文档：<https://developer.mozilla.org/docs/Web/Progressive_web_apps/Manifest/Reference/icons>

这一组主要解决安装形态、专属样式和图标问题。

### window controls overlay / router.replace

文档：<https://web.dev/articles/window-controls-overlay?hl=en>
文档：<https://developer.mozilla.org/en-US/docs/Web/API/Window_Controls_Overlay_API>
文档：<https://nextjs.org/docs/app/api-reference/functions/use-router>

这一组更偏桌面体验和路由手感。

## 1. PWA standalone 模式下，把标题收干净

### 空标题 / 简标题

文档：<https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Create_a_standalone_app>

很多 PWA 安装到桌面以后，第一眼还像网页，常见原因就是窗口标题栏还挂着一串网页标题。尤其是把站点名、栏目名、文章名全拼在一起时，桌面窗口会立刻有浏览器味。

### 作用

* 减少标题栏噪音
* 让桌面窗口标题更干净
* 给后面的 window controls overlay 留出更干净的空间

### 代码位置

常见位置有两个：

1. HTML 的 `<title>`
2. 框架的页面级 head / metadata 配置

如果你的应用在 standalone 下根本不需要显示页面标题，可以在运行时只保留一个很短的 app 名，或者干脆把动态页面标题收掉。

例如在普通 HTML 里，可以在 standalone 时改写标题：

```html
<script>
  if (window.matchMedia('(display-mode: standalone)').matches) {
    document.title = ''
  }
</script>
```

如果你不想完全留空，更稳一点的做法是只保留应用名：

```html
<script>
  if (window.matchMedia('(display-mode: standalone)').matches) {
    document.title = 'Ain'
  }
</script>
```

### 兼容性注意

* 这类处理只在 **已安装** 且以 standalone 打开时才有意义。
* MDN 的说明里也强调了：manifest 里的 display 只对安装后的应用生效，普通浏览器标签页不会吃这套逻辑。
* 完全空标题在不同桌面系统上的表现可能不同，实际项目里通常“短标题”比“真空标题”更稳。

## 2. 用 `display-mode` 写 PWA 专属样式

### `display-mode`

文档：<https://developer.mozilla.org/en-US/docs/Web/CSS/@media/display-mode>
文档：<https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Create_a_standalone_app>

如果你想让安装后的 PWA 和浏览器标签页长得不一样，最直接的入口就是 `display-mode`。这是官方给的专门开关。

### 作用

* 给安装后的 PWA 单独加样式
* 区分 browser / standalone / fullscreen / window-controls-overlay 等显示形态
* 把“浏览器里需要的 UI”和“App 里需要的 UI”分开

### 代码位置

通常放在全局样式文件里，比如：

* `app.css`
* `global.css`
* `theme.css`

示例：

```css
@media (display-mode: standalone) {
  .browser-only-header {
    display: none;
  }

  .app-shell {
    padding-top: 0;
  }
}

@media (display-mode: browser) {
  .standalone-only-tabbar {
    display: none;
  }
}
```

如果你要在 JavaScript 里判断，也可以：

```js
const isStandalone = window.matchMedia('(display-mode: standalone)').matches
```

### 兼容性注意

* MDN 明确写了，这个媒体特性可以判断当前顶层上下文的 display mode。
* 你在 manifest 里写了 `display: "standalone"`，最终实际生效的 mode 仍然可能受浏览器支持情况影响。
* 桌面安装、移动端添加到主屏幕、普通浏览器标签页，三者不一定表现一致，最好分别测一遍。

## 3. 取消滚动溢出，别让页面顶部漏出一条缝

很多 Web 应用一滚到最顶，尤其在移动端或套壳环境里，会出现“继续下拉露出背景色”或者顶部弹性回弹的感觉。这种细节会把页面往浏览器手感那边拉。

### 作用

* 减少顶部/底部回弹带来的割裂感
* 避免外层背景漏白
* 让独立窗口或全屏容器更稳定

### 代码位置

通常放在全局样式和根容器样式里：

```css
html,
body,
#app {
  width: 100%;
  height: 100%;
  overflow: hidden;
}

.app-scroll {
  height: 100%;
  overflow-y: auto;
  overscroll-behavior: none;
  -webkit-overflow-scrolling: touch;
}
```

如果你是 App Shell 布局，常见做法是：

* `body` 不滚
* 内容区单独滚

### 兼容性注意

* `overscroll-behavior` 在现代浏览器支持已经比较好，但不同 WebView 和系统手势环境下，体验仍可能有差异。
* 全局直接 `overflow: hidden` 时，要确认弹窗、长列表、抽屉组件还有自己的滚动容器，不然会把内容锁死。
* iOS 系统的橡皮筋回弹感不一定能被完全消掉，通常只能尽量收敛。

## 4. 鼠标指针设成默认 `default`

桌面 PWA 很容易露馅的地方，还有一项是指针。很多地方明明只是信息展示区，却保留了网页上常见的文本选择光标、奇怪的 hover 状态，整个壳立刻像网站。

### 作用

* 让非输入区域少一点网页味
* 减少“这里是一整页网页”的暗示
* 让交互层级更清楚

### 代码位置

建议从全局基础层开始收：

```css
body,
button,
[role='button'],
.nav-item,
.card,
.toolbar {
  cursor: default;
}

input,
textarea,
[contenteditable='true'] {
  cursor: text;
}

a,
button,
[role='button'] {
  cursor: pointer;
}
```

实际项目里不要一刀切全设成 `default`，而是把：

* 普通展示区域设成 `default`
* 可点击控件保留 `pointer`
* 可输入区域保留 `text`

### 兼容性注意

* 这条主要影响桌面环境，移动端几乎感觉不到。
* 如果你把链接和按钮也都设成 `default`，会把可点击反馈一起抹掉，适得其反。

## 5. 禁止用户随手选中文本

“禁止用户选择”，这条在工具型 PWA 里非常常见。原生 App 里的标题、导航、工具栏、卡片，通常不会让你随手拖蓝。

### 作用

* 减少“网页文本被选中”的感觉
* 避免桌面拖拽时误选标题和菜单
* 让导航栏、工具栏、卡片少一点网页手感

### 代码位置

通常只对非正文区做限制：

```css
.app-chrome,
.sidebar,
.tabbar,
.toolbar,
.nav-item,
.button-like {
  user-select: none;
  -webkit-user-select: none;
}
```

正文区、输入框和代码区一般不要关掉：

```css
article,
input,
textarea,
pre,
code {
  user-select: text;
  -webkit-user-select: text;
}
```

### 兼容性注意

* 不建议全站一把梭 `user-select: none`，那会把复制、搜索、调试体验一起弄坏。
* 这条更适用于导航、工具栏、标签栏、标题区，不适合文章页和文档页。

## 6. 不同系统分别准备应用图标

### manifest 图标与多系统图标

文档：<https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Define_app_icons>
文档：<https://developer.mozilla.org/docs/Web/Progressive_web_apps/Manifest/Reference/icons>
文档：<https://web.dev/add-manifest/>
文档：<https://web.dev/maskable-icon/>

这部分最容易被低估。浏览器标签页图标能看，安装到 Android、Windows、macOS、iOS 之后未必还能看。不同平台对图标裁切、圆角、遮罩、尺寸都有自己的习惯。

### 作用

* 安装后的图标不糊、不被裁歪
* 适配不同平台的桌面、任务栏、主屏幕和启动器
* 减少“一看就是随便拿 favicon 顶上去”的感觉

### 代码位置

第一层是 manifest：

```json
{
  "name": "Ain",
  "short_name": "Ain",
  "display": "standalone",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-maskable-512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "maskable"
    }
  ]
}
```

第二层是页面 head，给 iOS 这类场景补 `apple-touch-icon`：

```html
<link rel="apple-touch-icon" href="/icons/apple-touch-icon-180.png" />
```

### 多系统要注意什么

* **Android**：优先准备 `maskable` 图标，不然在自适应图标蒙版里容易被裁掉。
* **Windows**：manifest 里的多尺寸图标尽量准备齐，任务栏和开始菜单看起来会更稳。
* **macOS / 桌面安装**：图标会直接影响 dock 和窗口入口观感，别只交一个低分辨率 favicon。
* **iOS**：很多时候更依赖 `apple-touch-icon`，不能只指望 manifest。

### 兼容性注意

* MDN 的 `icons` 文档明确建议声明多个图标文件和尺寸。
* web.dev 的 maskable icon 文档强调了 Android adaptive icons 的裁切问题，这一条实际影响很大。
* iOS 对 Web App Manifest 的支持一直不算完整，所以 `apple-touch-icon` 这类补充项仍然值得保留。

![maskable icon 示例图](https://gastigado.cnies.org/d/public/webdev-maskable-icon-3.png)

## 7. 平级导航里，`router.replace` 往往比 `push` 更顺

### `router.replace`

文档：<https://nextjs.org/docs/app/api-reference/functions/use-router>

很多 Web 应用切页面时有很强的网页味，一个原因就是路由历史栈太像浏览网页。点一次 tab、开一次筛选、切一次内部视图，结果全都进了历史栈，用户一按返回就像在倒带网页轨迹。

### 作用

* 不把“中间态页面”都塞进 history stack
* 减少桌面/移动端返回时的网页味
* 让 tab 切换、列表筛选、内部状态切换更接近日常应用里的返回逻辑

### 代码位置

如果你用 Next.js App Router，常见位置是：

* 顶部 tab 导航
* 左侧导航
* 列表筛选和 query 参数切换
* onboarding / 登录完成后的落地跳转

示例：

```tsx
'use client'

import { useRouter } from 'next/navigation'

export function AppTabBar() {
  const router = useRouter()

  return (
    <nav>
      <button onClick={() => router.replace('/inbox')}>收件箱</button>
      <button onClick={() => router.replace('/calendar')}>日历</button>
      <button onClick={() => router.replace('/settings')}>设置</button>
    </nav>
  )
}
```

如果你还想切换时别自动滚到顶部，可以把 `scroll` 一起传进去：

```tsx
router.replace('/feed?tab=following', { scroll: false })
```

### 兼容性注意

* Next.js 官方文档写得很明确：`router.push()` 会新增一条 history entry，`router.replace()` 不会。
* 这条适合用在“平级导航”和“状态切换”；如果用户确实需要回到上一步内容，还是要保留 `push`。
* 别把所有跳转都换成 `replace`。详情页、编辑页、支付流这类需要明确返回路径的页面，通常还是 `push` 更合理。

## 8. 桌面端别浪费标题栏：用 window controls overlay

### window controls overlay

文档：<https://web.dev/articles/window-controls-overlay?hl=en>
文档：<https://developer.mozilla.org/en-US/docs/Web/API/Window_Controls_Overlay_API>
文档：<https://developer.mozilla.org/docs/Web/Progressive_web_apps/Manifest/Reference/display_override>

这条是最像“原生桌面 App”的细节。普通桌面 PWA 安装后，标题栏上面那一条区域经常空着，只留几个系统按钮。Window Controls Overlay 的思路就是把默认标题栏藏掉，让内容延伸进去，把关闭、最小化、最大化按钮变成 overlay。

web.dev 那篇《Customize the window controls overlay of your PWA's title bar》就是这一条的核心参考。

### 作用

* 回收桌面标题栏空间
* 让工具栏、搜索栏、标签栏更接近桌面应用
* 在安装后的 PWA 窗口里减少浪费的顶部高度

### 代码位置

第一步先在 manifest 里声明 `display_override`：

```json
{
  "display": "standalone",
  "display_override": [
    "window-controls-overlay"
  ]
}
```

第二步在样式里按 display mode 单独处理：

```css
@media (display-mode: window-controls-overlay) {
  .titlebar {
    padding-left: env(titlebar-area-x, 0);
    padding-top: env(titlebar-area-y, 0);
    padding-right: env(titlebar-area-width, 0);
    height: env(titlebar-area-height, 48px);
  }
}
```

第三步做 feature detection：

```js
const hasWco = 'windowControlsOverlay' in navigator
const isWco = window.matchMedia('(display-mode: window-controls-overlay)').matches
```

如果你要在几何变化时更新布局，还可以监听：

```js
if ('windowControlsOverlay' in navigator) {
  navigator.windowControlsOverlay.addEventListener('geometrychange', () => {
    document.documentElement.dataset.wco = 'on'
  })
}
```

### 兼容性注意

* MDN 明确标了 **Experimental**，而且不是 Baseline，生产环境一定要做特性检测和回退。
* 这条只对 **桌面端已安装的 PWA** 有意义，普通标签页和大多数移动端根本不会进入这个模式。
* 你即便在 manifest 里声明了 `window-controls-overlay`，也要靠 `display_override` 的回退链处理不支持的浏览器。
* 落地时，至少要准备：
  * 支持 WCO：标题栏吃进去
  * 不支持 WCO：退回普通 standalone

![window controls overlay 示例图](https://gastigado.cnies.org/d/public/webdev-window-controls-overlay-3.png)

## 怎么把这几条落到项目里

如果你正在做一个现成项目，最省事的落地顺序通常是：

1. 补 manifest、图标和 `display`。
2. 写 `@media (display-mode: standalone)` 的一层全局样式。
3. 把滚动、指针、`user-select` 这三条放进 App Shell 和导航容器。
4. 把 tab / 侧栏 / 筛选这种平级导航，逐个检查是否该从 `push` 改成 `replace`。
5. 看桌面端有没有必要上 `window-controls-overlay`。

影响观感的，往往就是这些边角。前面几条如果都没收，用户一打开就会觉得“这是网页”。这些地方一条条收紧后，PWA 的原生感会明显上来。

---

---
url: https://ain.hmgf.hxcn.space/ai/claude-code-architecture-governance-202606.md
---

# 你不知道的 Claude Code：架构、治理与工程实践

![](https://gastigado.cnies.org/d/public/image1.jpg)

## 0. 太长不读

今天这篇文章源于最近半年深度使用 Claude Code、两个账号每月 40 刀氪金换来的一些踩坑经验，希望能给大伙一些输入。

刚开始我也把它当 ChatBot 用，后来很快发现不对劲：上下文越来越乱、工具越来越多但效果越来越差、规则越写越长却越不遵守，折腾了一段时间，研究了 Claude Code 本身之后才意识到，这不是 Prompt 问题，而是这套系统的设计就是这样的。

这篇文章想和大伙聊聊这几个事：Claude Code 底层怎么运作、上下文为什么会乱以及怎么治理、Skills 和 Hooks 应该怎么设计、Subagents 的正确用法、Prompt Caching 的架构影响，以及怎么写一个真正有用的 CLAUDE.md。

我觉得最直接的理解方式，是把 Claude Code 拆成六层来看：

![](https://gastigado.cnies.org/d/public/image2.jpg)

只强化其中一层，系统就会失衡，CLAUDE.md 写太长，上下文先污染自己了；工具堆太多了，选择就搞不清楚了；subagents 开得到处都是，状态就漂移了；验证这步跳过了，出了问题根本不知道是哪里挂的。

## 1. 它底层是怎么运行的

![](https://gastigado.cnies.org/d/public/image3.jpg)

Claude Code 的核心不是"回答"，而是一个反复循环的代理过程：

用了一段时间才意识到，卡住的地方几乎从来不是模型不够聪明，更多时候是给了它错误的上下文，或者写出来了但根本没法判断对不对，也没法撤回。

### 真正要关注的五个层面：

![](https://gastigado.cnies.org/d/public/image4.png)

对着这几个面看，很多问题就好排查了。结果不稳定，查上下文加载顺序，不是模型的事；自动化失控，看控制层有没有设计，不是 agent 太主动；长会话质量下降，中间产物把上下文污染了，换个新会话比反复调 prompt 有用得多。

![](https://gastigado.cnies.org/d/public/image5.jpg)

## 2. 概念边界：MCP / Plugin / Tools / Skills / Hooks / Subagents

简单记：给 Claude 新动作能力用 Tool/MCP，给它一套工作方法用 Skill，需要隔离执行环境用 Subagent，要强制约束和审计用 Hook，跨项目分发用 Plugin。

![](https://gastigado.cnies.org/d/public/image6.jpg)

## 3. 上下文工程：最重要的系统约束

很多人把上下文当"容量问题"，但卡住的地方通常不是不够长，而是太吵了，有用的信息被大量无关内容淹没了。

###

真实的上下文成本构成

![](https://gastigado.cnies.org/d/public/image7.jpg)

Claude Code 的 200K 上下文并非全部可用：

一个典型 MCP Server（如 GitHub）包含 20-30 个工具定义，每个约 200 tokens，合计 4,000-6,000 tokens。接 5 个 Server，光这部分固定开销就到了 25,000 tokens（12.5%）。我第一次算出这个数字的时候，真没想到有这么多，在要读大量代码的场景，这 12.5% 真的很关键。

### 推荐的上下文分层

说白了，偶尔用的东西就不要每次都加载进来。

### 上下文最佳实践

* 保持 CLAUDE.md 短、硬、可执行，优先写命令、约束、架构边界。Anthropic 官方自己的 CLAUDE.md 大约只有 2.5K tokens，可以参考
* 把大型参考文档拆到 Skills 的 supporting files，不要塞进 SKILL.md 正文
* 使用 .claude/rules/ 做路径/语言规则，不让根 CLAUDE.md 承担所有差异
* 长会话主动用 /context 观察消耗，不要等系统自动压缩后再补救
* 任务切换优先 /clear，同一任务进入新阶段用 /compact
* 把 Compact Instructions 写进 CLAUDE.md，压缩后必须保留什么由你控制，不由算法猜

### Tool Output 噪声：另一个隐形上下文杀手

前面算的是 MCP 工具定义的固定开销，但动态部分同样有个坑容易被忽视：Tool Output。cargo test 一次完整输出动辄几千行，git log、find、grep 在稍大的仓库里也能轻松塞满屏幕。这些输出 Claude 并不需要全看，但只要它出现在上下文里，就是实实在在的 token 消耗，同样会挤掉对话历史和文件内容的空间。

后来看到 RTK（Rust Token Killer） 这个思路觉得挺对的，它做的事很简单：在命令输出到 Claude 之前自动过滤，只留决策需要的核心信息。比如 cargo test：

![](https://gastigado.cnies.org/d/public/image8.jpg)

Claude 真正需要知道的就是「过了还是挂了，挂在哪里」，其他都是噪声。它通过 Hook 透明重写命令，对 Claude Code 来说完全无感。

后面第 6 节会提到 | head -30 这种手动截断，RTK 干的就是这件事，只是覆盖面更广，不用每条命令自己加，项目 开源在 GitHub。

![](https://gastigado.cnies.org/d/public/image9.jpg)

### 压缩机制的陷阱

默认压缩算法按"可重新读取"判断，早期的 Tool Output 和文件内容会被优先删掉，顺带把架构决策和约束理由也一起扔了。两小时后再改，可能根本不记得两小时前定了什么，莫名其妙的 Bug 就是这么来的。

解决方案就是在 CLAUDE.md 里写明：

除了写 Compact Instructions，还有一种更主动的方案：在开新会话前，先让 Claude 写一份 HANDOFF.md，把当前进度、尝试过什么、哪些走通了、哪些是死路、下一步该做什么写清楚。下一个 Claude 实例只读这个文件就能接着做，不依赖压缩算法的摘要质量：

在 HANDOFF.md 里写清楚现在的进展。解释你试了什么、什么有效、什么没用，让下一个拿到新鲜上下文的 agent 只看这个文件就能继续完成任务。

写完后快速扫一眼，有缺漏直接让它补，然后开新会话，把 HANDOFF.md 的路径发过去就行。

### Plan Mode 的工程价值

Plan Mode 的核心是把探索和执行拆开，探索阶段不动文件，确认方案后再执行：

* 探索阶段以只读操作为主
* Claude 可以先澄清目标和边界，再提交具体方案
* 执行成本在计划确认之后才发生

对于复杂重构、迁移、跨模块改动，这样做比"急着出代码"有用多了，在错误假设上越跑越偏的情况会少很多。按两下 Shift+Tab 进入 Plan Mode，进阶玩法是开一个 Claude 写计划，再开一个 Codex 以"高级工程师"身份审这个计划，让 AI 审 AI，效果很好。

## 4. Skills 设计：不是模板库，是用的时候才加载的工作流

Skill 官方描述是"按需加载的知识与工作流"，描述符常驻上下文，完整内容按需加载，用起来和"保存的 Prompt"差别挺大的。

### 一个好 Skill 应该满足什么

* 描述要让模型知道"何时该用我"，而不是"我是干什么的"，这两个差很多
* 有完整步骤、输入、输出和停止条件，别写了个开头没有结尾
* 正文只放导航和核心约束，大资料拆到 supporting files 里
* 有副作用的 Skill 要显式设置 disable-model-invocation: true，不然 Claude 会自己决定要不要跑

### Skill 怎么做到按需加载

Claude Code 团队在内部设计中反复强调 "progressive disclosure"，意思不是让模型一次性看到所有信息，而是先获得索引和导航，再按需拉取细节：

* SKILL.md 负责定义任务语义、边界和执行骨架
* supporting files 负责提供领域细节
* 脚本负责确定性收集上下文或证据

一个比较稳定的结构长这样：

### Skill 的三种典型类型

下面几个例子都来自我在开源 terminal 项目 Kaku 里的实际 Skill，比较直观。

类型一：检查清单型（质量门禁）

发布前跑一遍，确保不漏项：

![](https://gastigado.cnies.org/d/public/image10.jpg)

类型二：工作流型（标准化操作）

配置迁移高风险，显式调用 + 内置回滚步骤：

![](https://gastigado.cnies.org/d/public/image11.png)

类型三：领域专家型（封装决策框架）

运行时出问题时让 Claude 按固定路径收集证据，不要瞎猜：

描述符写短点，每个 Skill 都在偷你的上下文空间，每个启用的 Skill，描述符常驻上下文，优化前后差距很大：

![](https://gastigado.cnies.org/d/public/image12.jpg)

还有一个很重要的 disable-auto-invoke 使用策略：

* 高频（>1 次/会话）→ 保持 auto-invoke，优化描述符
* 低频（<1 次/会话）→ disable-auto-invoke，手动触发，描述符完全脱离上下文
* 极低频（<1 次/月）→ 移除 Skill，改为 AGENTS.md 中的文档

### Skills 反模式

* 描述过短：description: help with backend（任何后端工作都能触发，哈哈）
* 正文过长：几百行工作手册全塞进 SKILL.md 正文
* 一个 Skill 覆盖 review、deploy、debug、docs、incident 五件事
* 有副作用的 Skill 允许模型自动调用

## 5. 工具设计：怎么让 Claude 少选错

我后面越用越觉得，给 Claude 的工具和给人写的 API 不是一回事。给人用的 API 往往会追求功能齐全，但给 agent 用，重点不是功能堆得多完整，而是让它更容易用对。

### 好工具 vs 坏工具

几个实用设计原则

* 名称前缀按系统或资源分层：github\_pr\_*、jira\_issue\_*
* 对大响应支持 response\_format: concise / detailed
* 错误响应要教模型如何修正，不要只抛 opaque error code
* 能合并成高层任务工具时，不要暴露过多底层碎片工具，避免 list\_all\_\* 让模型自行筛选

### 从 Claude Code 内部工具演进学到的

我看到 Claude Code 团队内部工具的这段演进时，感觉还挺有意思。像这种需要在任务中途停下来问用户的场景，他们前后试了三种做法：

* 第一版：给已有工具（如 Bash）加一个 question 参数，让 Claude 在调用工具时顺带提问。结果 Claude 大多数时候直接忽略这个参数，继续往下跑，根本不停下来问。
* 第二版：要求 Claude 在输出里写特定 markdown 格式，外层解析到这个格式就暂停。问题是没有强制约束，Claude 经常"忘了"按格式写，提问逻辑非常脆弱。
* 第三版：做成独立的 AskUserQuestion 工具。Claude 想提问就必须显式调用它，调用即暂停，没有歧义，比前两版靠谱多了。

下面这张图刚好能解释，为什么第三版明显更稳：

左边（markdown 自由输出）太松，模型格式随意、外层解析脆弱；右边（ExitPlanTool 参数）太死，等到退出计划阶段提问已经太晚；AskUserQuestion 独立工具落在中间，结构化且随时可调用，是这三者里最稳定的设计。

说白了，既然你就是要 Claude 停下来问一句，那就直接给它一个专门的工具。加个 flag 或者约定一段输出格式，很多时候它一顺手就略过去了。

Todo 工具的演进

早期用 TodoWrite 工具 + 每 5 轮插入提醒让 Claude 记住任务。随着模型变强，这个工具反而成了限制，Todo 提醒让 Claude 认为必须严格遵循，无法灵活修改计划。挺有意思的教训：当初加这个工具是因为模型不够强，模型变强之后它反而变成了枷锁。值得过段时间回来检查一下，当初加的限制还成不成立。

搜索工具的演进：最初用 RAG 向量数据库，虽然快但需要索引、不同环境脆弱，最重要的是 Claude 不喜欢用。改成 Grep 工具让 Claude 自己搜索后，好用很多。后来又发现一个顺带的好处：Claude 读 Skill 文件，Skill 文件又引用其他文件，模型会递归读取，按需发现信息，不需要提前塞进去，这个模式后来被叫做"渐进式披露"。

什么时候不该再加 Tool

* 本地 shell 可以可靠完成的事情
* 模型只需要静态知识，不需要真正与外部交互
* 需求更适合 Skill 的工作流约束，而不是 Tool 的动作能力
* 还没验证过工具描述、schema 和返回格式能被模型稳定使用

## 6. Hooks：在 Claude 执行操作前后，强制插入你自己的逻辑

Hooks 很容易被当成"自动运行的脚本"，但我自己用下来，觉得它更像是把一些不能交给 Claude 临场发挥的事情，重新收回到确定性的流程里。

比如格式化要不要跑、保护文件能不能改、任务完成后要不要通知，这些事真不要指望 Claude 每次都自己记得。

当前支持的 Hook 点

### 适合 vs 不适合放到 Hooks 的

适合：阻断修改受保护文件、Edit 后自动格式化/lint/轻量校验、SessionStart 后注入动态上下文（Git 分支、环境变量）、任务完成后推送通知。

不适合：需要读大量上下文的复杂语义判断、长时间运行的业务流程、需要多步推理和权衡的决策，这些该在 Skill 或 Subagent 里。

![](https://gastigado.cnies.org/d/public/image13.jpg)

### Hooks：越早发现错误，越省时间

![](https://gastigado.cnies.org/d/public/image14.jpg)

在 100 次编辑的会话中，每次节省 30-60 秒，累积节省 1-2 小时，还挺可观的。注意限制输出长度（| head -30），避免 Hook 输出反而污染上下文。如果不想在每条命令后面手动加截断，可以看看第 3 节提到的 RTK，它把这件事系统化了。

Hooks + Skills + CLAUDE.md 三层叠加

* CLAUDE.md：声明"提交前必须通过测试和 lint"
* Skill：告诉 Claude 在什么顺序下运行测试、如何看失败、如何修复
* Hook：对关键路径执行硬性校验，必要时阻断

用下来感觉，三样少任何一层都会有漏洞。只写 CLAUDE.md 规则，Claude 经常当没看见；只靠 Hooks，细节判断又做不了，放在一起才比较稳。

## 7. Subagents：派一个独立的 Claude 去干一件具体的事

Subagent 就是从主对话派出去的一个独立 Claude 实例，有自己的上下文窗口，只用你指定的工具，干完汇报结果。我用下来觉得它最大的价值不是"并行"，而是隔离，扫代码库、跑测试、做审查这类会产生大量输出的事，塞进主线程很快就把有效上下文挤没了，交给 Subagent 做，主线程只拿一个摘要，干净很多。

Claude Code 内置了三个：Explore（只读扫库，默认跑 Haiku 省成本）、Plan（规划调研）、General-purpose（通用），也可以自定义。

### 配置时要显式约束

* tools / disallowedTools：限定能用什么工具，别给和主线程一样宽的权限
* model：探索任务用 Haiku/Sonnet，重要审查用 Opus
* maxTurns：防止跑飞
* isolation: worktree：需要动文件时隔离文件系统

另一个实用细节：长时间运行的 bash 命令可以按 Ctrl+B 移到后台，Claude 之后会用 BashOutput 工具查看结果，不会阻塞主线程继续工作。subagent 同理，直接告诉它「在后台跑」就行。

### 几个常见反模式

* 子代理权限和主线程一样宽，隔离没有意义
* 输出格式不固定，主线程拿到没法用
* 子任务之间强依赖，频繁要共享中间状态，这种情况用 Subagent 不合适

## 8. Prompt Caching：Claude Code 内部架构的核心

这块我之前在很多教程里都没怎么看到有人展开讲，但它其实很影响 Claude Code 的成本结构和很多设计取舍。

工程界有句话 "Cache Rules Everything Around Me"，对 agent 同样如此，Claude Code 的整个架构都是围绕 Prompt 缓存构建的，高命中率不光省钱，速率限制也会松很多，Anthropic 甚至会对命中率跑告警，太低直接宣布 SEV。

### 为缓存设计的 Prompt Layout

Prompt 缓存是按前缀匹配工作的，从请求开头到每个 cache\_control 断点之前的内容都会被缓存。所以这里的顺序很重要：

破坏缓存的常见陷阱

* 在静态系统 Prompt 中放入带时间戳的内容（让它每次都变）
* 非确定性地打乱工具定义顺序
* 会话中途增删工具

那像当前时间这种动态信息怎么办？别去动系统 Prompt，放到下一条消息里传进去就行。Claude Code 自己也是这么做的，用户消息里加 `<system-reminder>` 标签，系统 Prompt 不动，缓存也就不会被打坏。

### 会话中途不要切换模型

Prompt 缓存是模型唯一的。假如你已经和 Opus 对话了 100K tokens，想问个简单问题，切换到 Haiku 实际上比继续用 Opus 更贵，因为要为 Haiku 重建整个缓存。确实需要切换的话，用 Subagent 交接：Opus 准备一条"交接消息"给另一个模型，说明需要完成的任务就行。

Compaction 的实际实现

上图是 Compaction（上下文压缩）的执行流程：左边是上下文快满时的状态，中间是 Claude Code 开一个 fork 调用，把完整对话历史喂给模型，加一句"Summarize this conversation"，这一步命中缓存所以只需 1/10 的价格，右边是压缩完之后，原来几十轮对话被替换成一段 ~20k tokens 的摘要，System + Tools 还在，再挂上之前用到的文件引用，腾出空间继续新的轮次。

直觉上 Plan Mode 应该切换成只读工具集，但这会破坏缓存。实际实现是：EnterPlanMode 是模型可以自己调用的工具，检测到复杂问题时自主进入 plan mode，工具集不变，缓存不受影响。

defer\_loading：工具的延迟加载

Claude Code 有数十个 MCP 工具，每次请求全量包含会很贵，但中途移除会破坏缓存。解决方案是发送轻量级 stub，只有工具名，标记 defer\_loading: true。模型通过 ToolSearch 工具"发现"它们，完整的工具 schema 只在模型选择后才加载，这样缓存前缀保持稳定。

![](https://gastigado.cnies.org/d/public/image15.jpg)

## 9. 验证闭环：没有 Verifier 就没有工程上的 Agent

「Claude 说完成了」其实没啥用，你得能知道它做没做对、出了问题能退回来、过程还能查，这才算数。

### Verifier 的层级

* 最低层：命令退出码、lint、typecheck、unit test
* 中间层：集成测试、截图对比、contract test、smoke test
* 更高层：生产日志验证、监控指标、人工审查清单

在 Prompt、Skill 和 CLAUDE.md 中显式定义验证

写任务 Prompt 或 Skill 的时候，最好把验收标准提前说清楚。哪些命令跑完算完成，失败了先查什么，截图和日志看到什么才算过，这些越早讲明白，后面越省事。

我自己有个很简单的判断：假如一个任务你都说不清楚「Claude 怎么才算做对了」，那它大概率也不适合直接丢给 Claude 自动完成。

## 10. 高频命令的工程意义

这些命令说白了就干一件事：主动管理上下文，别等系统自己处理。

### 上下文管理

![](https://gastigado.cnies.org/d/public/image16.jpg)

### 能力与治理

### 会话连续性与并行

### 几个不常见但很好用的命令

/simplify：对刚改完的代码做三维检查，代码复用、质量和效率，发现问题直接修掉。特别适合改完一段逻辑后立刻跑一遍，代替手动 review。

/rewind：不是"撤销"，而是回到某个会话 checkpoint 重新总结。适合：Claude 已沿错误路径探索太久；想保留前半段共识但丢掉后半段失败。

/btw：在不打断主任务的前提下快速问一个侧问题，适合"两个命令有什么区别"这类单轮旁路问答，不适合需要读仓库或调用工具的问题。

claude -p --output-format stream-json：实时 JSON 事件流，适合长任务监控、增量处理、流式集成到自己的工具。

/insight：让 Claude 分析当前会话，提炼出哪些内容值得沉淀到 CLAUDE.md。用法是会话做了一段之后跑一次，它会指出"这个约定你们反复提到，但没有写进契约"之类的盲点，是迭代优化 CLAUDE.md 的好手段。

双击 ESC 回溯：按两次 ESC 可以回到上一条输入重新编辑，不用重新手打。Claude 走偏了、或者上一句话没说清楚，双击 ESC 修改后重发，比重新开会话省事得多。

对话历史都在本地：所有会话记录存放在 ~/.claude/projects/ 下，文件夹名按项目路径命名（斜杠变横杠），每个会话是一个 .jsonl 文件。想找某个话题的历史，直接 grep -rl "关键词" ~/.claude/projects/ 就能定位，或者直接告诉 Claude「帮我搜一下之前关于 X 的讨论」，它会自己去翻。

![](https://gastigado.cnies.org/d/public/image17.jpg)

## 11. 如何写一个好的 CLAUDE.md

CLAUDE.md 在我看来更像是你和 Claude 之间的协作契约，不是团队文档，也不是知识库，里面只放那些每次会话都得成立的事。

我自己的建议其实很简单，一开始甚至可以什么都不写。先用起来，等你发现自己老是在重复同一件事，再把它补进去。加法也不复杂，输入 # 可以把当前对话里的内容直接追加进 CLAUDE.md，或者直接告诉 Claude「把这条加到项目的 CLAUDE.md 里」，它会知道该改哪个文件。

### 应该放什么

* 怎么 build、怎么 test、怎么跑（最核心）
* 关键目录结构与模块边界
* 代码风格和命名约束
* 那些不明显的环境坑
* 绝对不能干的事（NEVER 列表）
* 压缩时必须保留的信息（Compact Instructions）

### 不该放什么

* 大段背景介绍
* 完整 API 文档
* 空泛原则，如"写高质量代码"
* Claude 通过读仓库即可推断的显然信息
* 大量背景资料和低频任务知识（这些放到 Skills）

### 高质量模板

用起来其实不复杂：每次都要知道的放 CLAUDE.md，只对部分文件生效的放 rules，只在某类任务中需要的放 Skills。

### 让 Claude 维护自己的 CLAUDE.md

我最喜欢的一个技巧：每次纠正 Claude 的错误后，让它自己更新 CLAUDE.md：

> "Update your CLAUDE.md so you don't make that mistake again."

Claude 在给自己补这类规则时其实还挺好用，用久了确实越来越少犯同样的错。不过也要定期 review，时间一长总会有些条目慢慢过时，当初有用的限制现在未必还适合，这件事后面第 14 节有个更系统的做法。

![](https://gastigado.cnies.org/d/public/image18.png)

## 12. 最近自己折腾中得到的新经验

春节放假时，我用 Claude Code 做了一个开源 terminal 项目 Kaku，底层是 Rust + Lua，也带了一些 AI 能力。混合语言加上自定义配置系统，实际折腾下来反而暴露出不少典型的 agent 协作问题，顺手聊几个对我帮助比较大的经验。

![](https://gastigado.cnies.org/d/public/image19.jpg)

### 环境透明比你想象中重要

Claude Code 调用的都是真实的 shell、git、package manager 和本地配置。这里面只要有一层不透明，它就只能开始猜，一猜可靠性就掉。这不是 Claude Code 特有的问题，很多 agent 都一样。

所以我后来很快就在 terminal 里加了个 doctor 命令，把环境状态、依赖和配置情况先统一收上来，输出一份结构化的健康报告。Claude Code 开始做事前先跑一次 doctor，确实能省掉很多"环境没搞清楚就开干"的问题。

另外我还发现，假如 CLI 本身就有 init、config、reset 这类语义清楚的子命令，Claude Code 用起来会稳不少，比让它自己去猜配置文件怎么摆要靠谱。先把状态收敛住，再暴露编辑入口，顺序一反过来就很容易乱。

### 混合语言项目的 Hooks 实践

两套语言、两套检查，其实挺适合用 Hooks 按文件类型分别触发：

![](https://gastigado.cnies.org/d/public/image20.jpg)

每次编辑完立刻知道有没有编译错误，比"跑了一堆才发现最开始就挂了"舒服得多。

### 完整的工程化布局参考

假如有同学想给自己项目配一套比较完整的 Claude Code 工程布局，可以参考这个结构，不用全做，按需裁剪：

![](https://gastigado.cnies.org/d/public/image21.jpg)

全局约束（CLAUDE.md）、路径约束（rules）、工作流（skills）和架构细节各归各位，Claude Code 跑起来会稳很多。假如你同时维护多个项目，可以把稳定的个人基线放在 ~/.claude/，各项目的差异放在项目级 .claude/，通过同步脚本分发，不同项目之间就不会互相污染了。

## 13. 常见反模式

![](https://gastigado.cnies.org/d/public/image22.jpg)

## 14. 配置健康检查

基于文章里的六层框架，我把这套检查整理成了一个开源 Skill 项目 tw93/claude-health，可以一键检查你的 Claude Code 配置现在处于什么状态。

> npx skills add tw93/claude-health -a claude-code -s health -g -y

装好之后在任意会话里跑 /health，它会自动识别项目复杂度，对 CLAUDE.md、rules、skills、hooks、allowedTools 和实际行为模式各跑一遍检查，输出一份优先级报告：需要立刻修 / 结构性问题 / 可以慢慢做。

如果你读完这篇文章想知道自己的配置离这些原则差多远，跑一次 /health 是最快的方式。

## 15. 结语

用 Claude Code 大概会经历三个阶段：

![](https://gastigado.cnies.org/d/public/image23.jpg)

到了第三阶段，关注点会悄悄变掉，从「这个功能怎么用」变成「怎么让 agent 在约束下自己跑起来」，两件事感觉差很多。

有一个问题挺值得想的：假如一个任务你说不清楚「什么叫做完」，那大概率也不适合直接扔给 Claude 自主完成，验证标准本身都没有，Claude 再聪明也跑不出正确答案。

这些是半年折腾下来的一些总结，肯定还有很多没有挖掘到的地方，如果大伙有用得更 6 的技巧，欢迎告诉我。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-coding-non-technical-guide-202606.md
---

# 你不知道的 AI Coding：非技术人的上手、场景与实战

![](https://gastigado.cnies.org/d/public/image1.jpg)

## 太长可不读

上个月在公司里给产品和业务的小伙伴分享了下如何上手 AI Coding，加上最近又发了条推特，聊到不少同学因为订阅门槛没机会用上一线 AI Coding 工具，方法和习惯不花钱就能先学，索性把上手这部分整理出来。然后为了让内容给大伙更好理解，文章中绘制了不少简单插画，这样看起来应该更会直接。

不少人用 Claude Code 其实是卡在使用命令行的第一步，看到只有字母的终端会觉得是给程序员用的，自己肯定搞不定。其实门槛没想象的高，会用豆包这类对话框 AI 的人花点时间也能上手，剩下的就是慢慢习惯把执行权交给它。

等你用顺手后，你会发现它像个什么活都接的能干助手，跑后台数据、写解决你问题的小工具、把乱七八糟的文档拼成简报、做原型、整理销售报表都能干。之前会不会写代码不是关键，等你有意识把项目背景写进 CLAUDE.md、把需求写得足够精确、会去想着沉淀几个 Skill 把重复动作打包，那你其实就称得上入门了，这篇文章主要是想着带非技术同学可以上手使用我最爱的 Claude Code。

## 第一道坎是命令行

不写代码的同学习惯了豆包这类对话框 AI，第一次装 Claude Code 都会有点不适应。以前是个来回搬运的过程，你描述需求、它生成代码、你复制粘贴到别处去试，现在变成Claude Code 直接在终端运行，搬运这一步省掉了。

如果你没用过终端，推荐我做的 Kaku，它是专门为 AI Coding 做的终端，装好就能用，不用折腾配色和字体。深色浅色跟着系统走，分屏按 Cmd + D，文件管理器按 Cmd + Shift + Y 直接显示出来。对刚上手的人最友好的是内置了 AI 辅助：命令跑报错了会自动给修复建议，记不住命令在前面加个 # 写中文也能生成。

安装 Claude Code 也只需一条命令，详见 官方文档，然后进项目文件夹输入 claude 就能开始 Coding 了。

> curl -fsSL https://claude.ai/install.sh | bash

## 非常建议补点技术知识

不写代码的同学想真把 Claude Code 用好，光会描述需求还不够，懂一点基础概念，后面排错会轻松很多。

知道常用框架是干嘛的，知道 React、Vue、Next.js 大概在解决什么问题，看 Claude Code 写出来的东西就不会一头雾水。

常用软件的基础，终端命令、Git、VS Code、Chrome 开发者工具，跑出错的时候你能跟着它一起定位，而不是只能干等。

编程的几个核心思想，函数是干什么的、变量和状态是什么、为什么要拆成多个文件，懂了这些需求才写得精确。

学会读代码和读报错，比自己会写代码更早派上用场。它改完一段你能扫一眼大概在干嘛，比让它从头解释一遍快得多。报错也别一看就慌，整段复制丢回去问"这是什么意思、要怎么改"，十次有九次能告诉你具体哪一行出问题。

不用学到能自己写代码的程度，知道这些东西长什么样就够了。花一两个晚上把 freeCodeCamp 或者 MDN 的入门篇过一遍，或者去 B 站挑一套入门课粗看一遍，计算机科学速成课、哈佛 CS50 都不错，后面跟 Claude Code 协作的效率会很不一样。

![](https://gastigado.cnies.org/d/public/image2.jpg)

我挺推荐这三本对工程师最有用的入门易读书：《启示录》 看产品判断、《Linux/Unix 设计思想》 看工程哲学、《左耳听风》 看一个我怀念的左耳朵耗子攒下来的程序员专家视野，读完跟 AI 聊技术细节会少懵很多。

## 准备工作：账号与订阅

账号：在 claude.ai 用 Gmail 注册，流程最标准，注册前尽量用美国 iP 稳定的网络环境，别频繁切换出口，不然新账号容易触发风控，同时新账号不要直接包 Max，也容易被封号。

最简单的方式是走美区 App Store 内购，Android 走 Google Play 也行，进 Claude App 选 Pro 用余额订阅就行，注意走 App Store 有税费，100档会显示成125，多 25 买一个安心，不过很建议先 Pro 起步，配额不够再升 Max。订阅状态跟账号走，iOS 订完之后在 Android 或网页登录都正常用。

账号没了所有事都得重来，甚至还有可能持续被封，订前几件事注意一下。网络环境用稳定低延迟的别天天换，账号一号一人别合租也别和别人共用，付款方式选靠谱的实体卡，虚拟卡尤其是币圈渠道充值的容易秒封。邮箱用老 Gmail 别用新注册的 Outlook，出口尽量保持干净别让其他乱七八糟的 App 流量都从同一个口子出去。

## Claude Code 适合什么样的活

我自己用过的 AI Coding 工具不少，Cursor、Windsurf 都试过一圈，Codex 平时也会用，主力还是 Claude Code。

它最不一样的地方是模型能力本身就很不错，加上Claude Code自己的代码实现也把 Harness 这一套玩到了极致，使用时候它先扫一遍 CLAUDE.md 和目录结构摸清楚上下文，然后跨文件改代码、跑命令、看报错、再改，自己全部完成。再加上它本来就活在终端里，git、测试、脚本这些你日常用的工具它都能直接调起来，不用来回复制粘贴。

![](https://gastigado.cnies.org/d/public/image3.jpg)
![](https://gastigado.cnies.org/d/public/image4.jpg)

Claude Code 实际更像个通用 Agent，叫 Code 只是因为最初定位偏写代码。Anthropic 自己分享过他们内部不少非工程团队比如销售、风控、财务都在拿它干活，处理 CRM 数据和客户邮件。如果你实在不想碰终端，可以用官方出的桌面应用 Cowork，能直接读写你的下载和文档目录，把收据截图拼成报销表这种活，你说一句话它也能给你干好。

还有一点我感觉很重要：写代码这件事上，模型快不快不重要，准不准才重要。它 10 分钟跑完然后你花 20 分钟 debug，远不如它 20 分钟跑完直接能验收来的舒服。

要让它准，前提是你给到的活本身就目标清楚、结果好验收，两个都满足的最适合交给它，好比你把活交给了一个非常直男但是技术非常厉害的程序员。

具体就这几类活：做原型和内部小工具，把需求和展示逻辑说清楚，第二天就能跑起来一版；处理 CSV、做销售报表，分组和计算逻辑写明白几分钟出结果；几十页合同提炼条款、对比版本差异这种文档活它最擅长；最后是给一堆链接或 PDF 让它从特定视角提炼信息，说清格式就行。

## 做一个只给你一个人用的软件

最阻碍新人写代码的第一步是不知道自己要做个啥。《纽约时报》专栏作家 Kevin Roose 提过一个概念叫 software for one：你不需要做给一百万人用的 App，可以做只给你一个人用的软件。

他给自己做过整理链接的 Stash，给孩子准备便当的 LunchBox Buddy。对你来说，可能是把语音批注转成会议纪要的工具，或者是每天提醒你三件事的小仪表盘。这种东西反而是产品和业务的同学最容易做成，毕竟只有你最懂自己每天的麻烦在哪。

## 一天到三个月的节奏

别一上来就想做个“像 Notion 那样的产品”，可以按下面这个节奏来，每一段都有摸得到的产出：

第 1 天先试水，让它改一个你手头现成的 Excel 或 Markdown 文档；第 1 周尝鲜，做一个单页个人主页或日报大盘 15 分钟就能跑起来；第 1 个月提效，挑一件每周重复做两三次的事变成一条命令或一个页面；第 3 个月进阶，选一个"software for one"的想法做一个只给自己用的小工具。

![](https://gastigado.cnies.org/d/public/image5.jpg)

## 用 OpenCLI 把网页操作变成命令

很多运营日常是在浏览器里点点点：查后台、发消息、导报表。这些活其实能绕开界面，直接调背后的接口来做。

OpenCLI 是我朋友卡比做的，它内置了小红书、知乎、Twitter/X、Bilibili 等几十个站点的 CLI 适配器，再加上一组通用的浏览器操作原语像点击、输入、抓取、截图。把网页动作变成一条命令，Claude Code 一句话就能调起来。

小红书调研，让 Claude Code 调 opencli xiaohongshu 抓数据，再做分类和热词提炼，原本浏览器里点半天的事一句话搞定。

舆情汇总，把 Twitter/X、Reddit、HackerNews 几个适配器组合起来，同一关键词在多个平台的讨论自动拼成一份日报。

没适配的网站，用浏览器原语命令描述一遍流程，比如开页面、输关键词、抓表格，Claude Code 自己拼出来。

Claude Code 还有个 Routines 功能，能把一段工作流存到云端，按定时、Webhook 或 GitHub 事件自动触发。我自己还没怎么深用，概念上像「周一早上自动跑一遍周报流程」这种事它能接管，感兴趣可以看官方文档。

![](https://gastigado.cnies.org/d/public/image6.jpg)

## CLAUDE.md：先把项目背景写清楚

很多人装好之后直接开问，结果每次都要重复交代背景，用一会就觉得很烦。原因几乎都一样：没建 CLAUDE.md。

它放在项目根目录，Claude Code 每次启动都会先读它，相当于你给新来的同事写的项目交接文档，区别是它每次都会从头认真读一遍而且严格执行。

写得好不好，三件事最关键。写得短一点，150 行以内为佳，写太长会挤压后续对话的空间。语气直接，用命令式，别写"我们团队比较喜欢"这种软话，"所有注释用中文"比"团队偏好中文注释"有效太多。每条都能判断，"代码质量要高"没用，"函数超过 50 行必须拆分"才能落地。

四条最值钱的规则，直接拿去用：先问清楚再动手、简单优先、只动该动的、做完要验证。展开就是：别让它猜你的意图，目标说清再写；能两行解决的不写两百行，拒绝过度设计；不要顺手重构没让它改的代码；跑通构建和测试才算完，没通过别说完成。

下面这份模板，你改一改项目背景就能直接用：

![](https://gastigado.cnies.org/d/public/image7.jpg)

最后这段"压缩时保留"看着不起眼，长会话能不能稳就靠它。Claude Code 的上下文用到一定程度会自动压缩，决策的理由通常是第一个被丢的。比如你之前说过"这里要用 POST 不用 GET，因为数据量大"，压缩之后可能只剩"用 POST"三个字，理由没了。下次再问相关问题，它可能给你一个完全不同的方案，前后矛盾。把这一段写进去，长会话就不会前后打架。

上面这些不一定要自己从头写。装好 Claude Code 之后，直接说"读一下我这个项目，帮我生成一份 CLAUDE.md"，它会扫一遍代码、技术栈、目录结构，给你一份草稿，你只要改一改人名和团队偏好。装依赖、配 alias、改 ~/.claude/settings.json 这些事也一样，告诉它要什么效果让它自己去试，比你查文档快得多。配置类的活能交就交，省下来的精力放到真正要判断的事情上。

![](https://gastigado.cnies.org/d/public/image8.jpg)

## 需求描述越精确，它越少分叉跑偏

模糊版：帮我做一个客户跟进工具。
精确版：帮我做个销售用的跟进工具，单文件网页存本地。左边列表显示公司名、下次跟进时间、状态，右边详情包括沟通记录、日期、要点。顶部加三个筛选：状态、时间、关键词。数据存浏览器 localStorage，不调后端。

精确版当天就能跑出能用的版本，模糊版多半要返工。

再看一个完整精确版的样子，这是 yetone 给 Claude Code 写的 macOS 语音输入工具需求。代码细节看不懂没事，重点是看每条要求被拆得多具体。

这种描述，Claude Code 几乎不用猜，直接产出一个能装的 macOS 应用。每一条都是在防它猜错一个具体的点：

你不需要会写 Swift，但需要把需求写得这么细。这份需求里每一条背后，都是 yetone 自己踩过的坑或者预想到的坑。每多一条具体细节，就少一次返工。

![](https://gastigado.cnies.org/d/public/image9.jpg)

业务场景的需求，光描述功能还不够。开头先把问题写清楚，要解决什么、给谁用、怎么算做对了，别一上来就列功能清单。比如说我们要写一个国际门票频道页时第一句话就是"国际门票目前没有独立入口，用户只能搜索找到，非热门城市曝光极低"，这两句话决定了它后面碰到"热门城市展示几个""筛选要不要做'最近浏览'"这类问题时的判断方向。

接下来要给它划范围。Claude Code 很积极，你说做一个列表页它顺手就给你加上收藏、分享、埋点。明确写出"不做登录态、不做分享、不做 SEO，下一期再说"，它就不会越界。异常情况要单独列出来，接口超时怎么办、数据为空展示什么、图片挂了用什么兜底，这些不写它要么不处理，要么猜个你不满意的方案。

验收标准必须给数字，"页面要快"没用，"首屏 1.5 秒内"才能判断；"布局正常"没用，"在 375 和 1440 两个宽度下不错位"才能验收。

写需求的时候，别用"待定""后续再看""TBD"。Claude Code 碰到这些会自己猜着填，猜的往往不是你要的。哪怕写"这一版先硬编码，下版再做配置化"，也比空着强。

![](https://gastigado.cnies.org/d/public/image10.jpg)

## 复杂任务先对答案：Plan 与 Auto 模式

有次我让它重构登录模块，它顺手删了一个我后面要用的工具类，回滚花了半小时，印象很深。

从那以后，复杂一点的任务我都会先按两次 Shift+Tab 切到 Plan 模式。它会先把打算怎么做列出来，方向对了你再让它执行。其实就跟工作场景一样：你不会直接让小李把功能做掉，先拉个会过下方案，觉得 OK 了再动手。

![](https://gastigado.cnies.org/d/public/image11.jpg)

Plan 模式产出的计划大概长这样：要改哪几个文件、每个文件改什么、改的理由是什么、预计会影响哪些地方。用业务逻辑来判断这个方向对不对，比判断代码本身容易得多。哪怕你看不懂代码，也能从"这一步要不要做、那一处理由对不对"把关。

如果你嫌每步都问太烦，可以开 Auto 模式，按 Shift+Tab 循环切到 auto 那一档，目前 Max、Team、Enterprise 都能用，Pro 暂时还没开。它会自己判断：读文件这种安全操作直接跑，改数据库、删文件这类风险操作才来问你。刚上手默认开它就行，既不会被无意义的确认打断，也不会让它瞎搞。

## 怎么确认它真的做对了

它跟你说"搞定了"其实没用，关键是你怎么验收，因为它也会用最省事的方式交差。

### 改坏了怎么救回来

不会写代码的人最怕代码被改乱了找不回来，常用的就两条。

Git 快照，每次大改前让它先跑一遍 git status 看清楚都有什么，确认没问题再让它 commit 一个检查点。改坏了直接说"按刚才的检查点回退"，比自己手动 checkout 安全得多。

撤销上一步，直接对它说"撤销刚才所有改动"，或者按 /rewind 回到上一个状态。

### 别让它陷入改了试试的死循环

有个坑很容易踩：陷入改了试试的循环，4-5 轮下来本来不大的问题变成一团乱麻。原因就一个，没诊断清楚就开始打补丁。

避免方法也一句话：根因没说清楚之前先别动代码。让它先答"问题出在哪个文件的哪一行，为什么会这样"，答含糊继续查，答清楚再改。一上来说"我试试改 X 看行不行"的，直接喊停让它先答根因。

![](https://gastigado.cnies.org/d/public/image12.jpg)

## Max 进阶：alias、模型、长会话

刚上手不必看，等用熟了或者你感觉Pro完全不够你用的时候，再来翻这个都行。

### 我自己 Max 订阅怎么用

alias，我在 .zshrc 里加了一行，按 c 就直接启动一个不再问我权限的 Claude Code，同时把自动压缩点提前到 400k，等到上下文塞满才压效果会差，提前一点反而更舒服，你可以把这一段 copy 给你的 claude code 让他帮你来优化。

![](https://gastigado.cnies.org/d/public/image13.jpg)

\--dangerously-skip-permissions 不建议刚上手的人用，它字面意思就是"危险跳过所有权限确认"，意味着 Claude Code 不会再问你任何事。我自己用是因为我能看懂它每一步在做什么，加上确实嫌反复确认烦。如果你还没到这个程度，老老实实用 Auto 模式就好。

模型用 opusplan，我现在这套用法是输入 /model opusplan 这个隐藏命令就开启。划交给 Opus，执行交给 Sonnet，整体省钱也省时间。想更快可以再跑 /fast，刚好补回上面省下来的 token。

关键配置，如果你当前版本支持，用 opusplan 时去 ~/.claude/settings.json 里把 showClearContextOnPlanAccept 设成 true，不然会在 Sonnet 这一段碰到严重的缓存未命中，速度会明显慢下来。这个设置一开，整体就好多了。

### 长会话怎么办

Claude Code 的工作台是固定大小，跑久了早期内容会被挤出去。

任务做完就 /clear，一个会话只做一件事，做完清掉再开下一件，两件不相干的事在同一个上下文里来回切，它会越做越乱。

长任务结束前让它写交接笔记，直接对它说："把当前进度写成一份 HANDOFF.md，包括做了什么、试过什么没成功、下一步该做什么。" 第二天打开新会话，把这个文件给它，就能接着干，不依赖任何压缩算法。

## Waza：把好习惯沉淀成肌肉记忆

AI 可以让明确敲代码的活做得很快，但事情本身要做成什么样子其实需要你自己来定。我最近折腾了一套叫 Waza 的 Skill，一共8 个技能对应一个好工程师该有的 8 个习惯。

![](https://gastigado.cnies.org/d/public/image14.jpg)

/think 是动手前先想一下技术方案，AI 写代码很快，但方向错了越快越远，先质疑问题本身、把方案上都思考好后，再让它跑。

/design 是给帮你设计一个产品化的页面，拒绝那种蓝紫渐变 + 一堆 emoji 的 AI 模板感。

/hunt 是排查问题的，原则只有一条：根因没说清楚之前先别动代码，避免改了试试的死循环。

/check 是收工前的最后检查，diff 审一遍，能自动修的修掉，它拿不准的归拢起来再问你。

![](https://gastigado.cnies.org/d/public/image15.jpg)

剩下四个偏日常：/read 把任意网页或 PDF 转成干净的 Markdown 进工作流，/write 让你的表达更清晰，/learn 是一套从收资料到出文章的研究流程，/health 给你的 CLAUDE.md 和各种规则做个体检，你感觉Claude不好用的时候运行一下试试。

其中我最建议产品、业务、运营先试的是 /design，截图丢给它带上 /design，它不会立刻动手，会先反问你给谁用、想要什么气质、最不喜欢哪种风格、有没有想让用户记住的微交互，回答完再动手，效果通常比直接说"帮我改一下样式"稳定。

![](https://gastigado.cnies.org/d/public/image16.jpg)

## 你也可以自己写一个 Skill

Skill 本质就是一个文件夹，放在 .claude/skills/ 目录下，里面有个 SKILL.md 写清楚什么时候用、要做什么。Claude Code 启动时只读 frontmatter，也就是描述触发条件的约 100 个字，真正调用时才加载完整内容，所以你装几十个 Skill 启动也不会变慢。

![](https://gastigado.cnies.org/d/public/image17.jpg)

第一种是工作流型：把每次都要做的固定步骤打包。比如整理周会纪要：

第二种是检查清单型：上线前、发版前、提交前过一遍，避免漏项，比如需求上线检查：

第三种是领域专家型：把判断框架沉淀进去，碰到这类问题按固定路径走，不让它每次自由发挥，比如线上问题排查，以及你们平时的业务最佳实践的 SOP。

写好之后，把它放到 .claude/skills/ 文件夹下，碰到对应场景说一句"用整理周会"或"用线上排查"就行，这里你也可以让 Claude 帮你写，此外两个写 Skill 的小坑要避一下。

description 写触发条件，不写功能介绍，"开完会有原始记录需要整理时调用"比"把会议录音整理成结构化周报"准确率高得多。

一个 Skill 只做一件事，别把审查、发布、调试塞在一起，拆开用起来才更准。

### Kami：让 AI 帮你排版出专业文档

写完内容只是第一步，排版成能发出去的东西往往更耗时间。Kami 是也是我最近做的 AI 排版设计工具，你把内容丢给它，说一句"帮我排成一页纸"或"做个作品集"，它会生成一份可下载的 PDF。

它有 8 套模板：一页纸、作品集、幻灯片、Resume、长文档、信件、研报、Changelog。风格统一，暖底色、墨蓝色点缀、衬线字体为主。中文用苍耳今楷，英文用 Charter，不需要自己调字体。

最实用的几个场景：会议纪要排成简报、项目进展排成一页纸给老板。以前这些活得开 Word 或 Figma 折腾半天，现在把内容丢进去，先出一版能看的稿子，再微调。

## Claude Design：不写代码也能出原型

2026 年 4 月推出的 Claude Design 是另一条路：你上传截图或文档，它直接给你个能交互的原型、幻灯片或落地页，对想快速做原型的非技术同学挺好用。

还不想碰代码的话，用它先出个能展示的想法准没错。产品经理可以用它画原型开评审，过了直接把原型扔给 Claude Code 变代码。早期原型不用等完整设计和研发排期，当天就能拿出来讨论。

## 用熟之后的几个小习惯

截图比文字快，要描述一个界面问题或者想参考某个设计风格，直接丢图比写一段话准多了，布局、颜色、层级都带进来了，让它少猜。

任务拆小一件件来，一句话能讲清楚的任务它几乎不会出错。一上来给一大坨需求，它中间任意一步走偏后面就全偏了，一件做完验收一件再开下一件。

对话跑偏了就重启，在已经跑偏的对话里来回纠正它越纠越乱，清掉上下文重说一遍需求往往更快。第二天接着干，先翻一眼上次的 Recap（/clear 后会自动生成的会话摘要）想起来干到哪了。

Memory 跨项目记住你的偏好，CLAUDE.md 是项目级的每个项目都得单独写一份，Memory 是用户级的跨所有项目和会话都生效。直接对它说"记住我喜欢先看方案再执行"、"记住回我中文"，它会写进 ~/.claude/memory/，以后任何项目打开都记得。常交代的背景信息都可以沉淀进去，省得每次重复说。

双击 ESC 改上一条，说错了或者它跑偏了，按两下 ESC 就能回到上一条消息修改，不用重开会话。

![](https://gastigado.cnies.org/d/public/image18.jpg)

## 几个安全考虑点需要注意的

让它先解释再动手，在 CLAUDE.md 里加一条："每次执行 Bash 命令或修改文件前，先用一句话解释要做什么。" 它就会在每步操作前先告诉你它打算干嘛，看不懂代码没关系，看得懂"我要删掉这个文件"就够了。

看不懂的命令先问，它要跑一条你没见过的命令别直接放行，先问它"这条命令具体做了什么、有什么风险"，看懂了再点确认，要复制任何你不懂的命令去执行，里面可能夹带下载、上传或泄露信息的操作。

生产环境不要拿来练手，本地和测试环境随便折腾，但涉及生产数据库、线上配置的操作一定先在测试环境验证。一条写错的 SQL 或一次误删，回滚成本远高于你预期。

密钥别直接粘到对话里，要配置 API Key、数据库密码这类东西，让它放到环境变量或者 .env 文件里，不要直接把明文贴到聊天窗口。

还有一条容易被忽略但很要紧：能跑不代表安全，AI 生成的代码可能有漏洞，涉及登录、支付和个人信息的功能，能用 Clerk 或 Stripe 这种现成服务就别让它从零写。

## 加深了解

1. 你不知道的 Claude Code：架构、治理与工程实践
2. 你不知道的 Agent：原理、架构与工程实践
3. 你不知道的大模型训练：原理、路径与新实践
4. Claude Code Best Practices - Anthropic 官方
5. vibe coding - Andrej Karpathy 原始推文
6. Claude Skills are awesome, maybe a bigger deal than MCP - Simon Willison
7. Malleable software in the age of LLMs - Geoffrey Litt
8. Claude Code Skills 完全指南 - Datawhale Easy Vibe
9. Claude Code Starter Pack: Tools, Tutorials & Resources - AI Edge
10. When the Vibes Are Off: The Security Risks of AI-Generated Code - Lawfare

### Media

![](https://gastigado.cnies.org/d/public/image19.jpg)
![](https://gastigado.cnies.org/d/public/image20.jpg)
![](https://gastigado.cnies.org/d/public/image21.jpg)
![](https://gastigado.cnies.org/d/public/image22.jpg)

---

---
url: https://ain.hmgf.hxcn.space/ai/awesome-agentic-patterns-202605.md
description: 从仓库说明、配套网站和作者长文出发，解释 awesome-agentic-patterns 适合怎样读。
---

# awesome-agentic-patterns 导读

官网：<https://agentic-patterns.com/>

作者长文：<https://nibzard.com/agentic-handbook/>

很多 Agent 项目在演示阶段都挺顺：会规划、会调工具、会自己修一点错。真进到长期任务、多人协作和高权限环境里，问题就全冒出来了——上下文越来越乱，工具越接越多，模型会反复犯同一个错，出了事又不知道该从哪里回放。`awesome-agentic-patterns` 收的就是这些场景里反复出现的做法。把它看成一份可回查的工作模式清单，会更实用，团队可以拿来讨论、比较、拆解。

它值得读，主要因为它把"Agent 进生产之后会卡在哪里"说清楚了。灵感通常来自一次跑通的 demo；pattern 记录的则是工程里反复出现的问题和修法：什么问题总会发生，常见修法是什么，副作用在哪里，哪些资料可以回查。对需要上线、维护、回滚的系统来说，这种材料的价值要高得多。

## 仓库如何筛选 Pattern

仓库首页对 pattern 的定义很直白：它得是可重复的、确实作用在 Agent 行为上的、还能追到公开参考来源。首页用的是三个词：`Repeatable`、`Agent-centric`、`Traceable`。换成工程话就是：

* 它得能反复出现，不是偶然撞上的一次成功；
* 它真的改变了 Agent 怎么感知、推理或执行；
* 背后还要能找到博客、演讲、仓库或论文这类公开来源。

`CONTRIBUTING.md` 把这件事写得更细。新增条目时，要按统一 schema 写清楚 problem、solution、trade-offs、source、tags、signals、anti-signals，还专门限制了宣传式写法。维护者想做什么，已经很清楚了：把社区里零散的"这个挺好用"筛成更像设计文档的东西。

模式数量也要说清楚。当前 GitHub `patterns/` 目录里有 172 个 Markdown 文件，其中一个是 `TEMPLATE.md` 模板文件；网站首页显示的是 171 个正式模式。正文如果只写模式数，采用 171 这个口径更准确。

按仓库当前列表，171 个模式被分成 8 类：

* Context & Memory：20 个
* Feedback Loops：14 个
* Learning & Adaptation：7 个
* Orchestration & Control：51 个
* Reliability & Eval：21 个
* Security & Safety：15 个
* Tool Use & Environment：27 个
* UX & Collaboration：16 个

把它们当成一张排错地图会更顺手：Agent 一旦进生产，通常就是在这些地方先出问题。

## 模式库有什么用

真实故障很多都来自约束没提前设计好。常见情况包括：

* 上下文塞得太多，模型注意力被稀释；
* 工具口子开得太大，Agent 到处乱试；
* 没有反馈回路，同一个错误反复出现；
* 没有权限分层，一次 prompt injection 就能变成事故；
* 没有人工接管点，出事后只能靠人肉善后。

pattern 的用处，在于把这些问题拆成可以逐项配置的层。你不需要把成败都压在"这次 prompt 应该够清楚了"上，可以单独讨论：上下文怎么裁、工具怎么暴露、反馈怎么进来、评测怎么做、审批点放在哪里。官方长文反复强调的也是这个判断：难点不在 demo，本事在 loop。读这类库，就是在学怎么把 loop 设计得更稳。

## Context & Memory：模型每一步看到什么

Context & Memory 处理的是输入面。重点在当前这一步该让模型看到什么，不该看到什么。

这一组里很典型的模式包括：

* `Context-Minimization Pattern`
* `Curated Code Context Window`
* `Curated File Context Window`
* `Dynamic Context Injection`
* `Episodic Memory Retrieval & Injection`
* `Progressive Disclosure for Large Files`
* `Working Memory via TodoWrite`

读完这组条目，你会发现重心落在裁剪和装配。一个代码 Agent 没必要每轮都带着整个仓库和所有历史对话继续跑；更现实的办法，是给任务相关文件，再按需扩展依赖，把待办和短期状态外置到 working memory。`Dynamic Context Injection` 解决的是"什么时候把哪段知识塞回来"，`Episodic Memory Retrieval & Injection` 解决的是"上次踩过的坑怎样变成下一次的提醒"。

很多人把长上下文当成保险，但它更该被当成预算。上下文不做管理，很容易变成噪声池；上下文做得好，模型就更容易把注意力放在当前步骤上。

## Feedback Loops：别把第一次输出当成终局

Feedback Loops 这组模式，讨论的是 Agent 出错以后靠什么继续往前走。它默认第一次输出并不可靠，所以系统必须给它准备反馈源，不要期待一发命中。

比较典型的条目有：

* `Reflection Loop`
* `Self-Critique Evaluator Loop`
* `Coding Agent CI Feedback Loop`
* `AI-Assisted Code Review / Verification`
* `Spec-As-Test Feedback Loop`
* `Incident-to-Eval Synthesis`

这几类做法放进生产里，通常对应三件事。第一，让 Agent 自己复读和反查自己的结果；第二，把编译器、测试、CI、review comment 这类外部系统拉进来做反馈源；第三，把线上翻车案例沉淀成以后的 eval 或测试项。`Rich Feedback Loops > Perfect Prompts` 这个模式名已经说得很明白：闭环比神 prompt 更重要。

没有这条链路，系统就只能在原地重复自己的误判。更稳的工作方式是：改，跑检查，读报错，再修。

## Learning & Adaptation：让成功经验留下来

如果 Feedback Loops 关心的是"这次怎么修"，Learning & Adaptation 关心的就是"修过之后，系统能不能长记性"。这一组条目数量不多，但和团队有没有复利关系很大。

这一类里常见的是：

* `Skill Library Evolution`
* `Agent Reinforcement Fine-Tuning (Agent RFT)`
* `Memory Reinforcement Learning (MemRL)`
* `Variance-Based RL Sample Selection`
* `Compounding Engineering Pattern`
* `Shipping as Research`

真正落到团队里时，经验要从聊天记录里捞出来。反复成功的流程，可以整理成 skill；反复翻车的地方，可以写成规则、用例、回放样本。这样做久了，系统才不会每次都从头学一遍。

这一层很容易被忽略，因为很多团队都会有"这次表现还行"的感受，但没有把"还行"转成下次更稳的资产。pattern 库把这一层单独拎出来，提醒你：经验不进技能库、评测库和训练样本，就还是一次性的。

## Orchestration & Control：决定流程怎么跑，谁在什么时候接管

8 类里最多的是 Orchestration & Control，这很正常。只要把 Agent 看成"LLM + loop + tools + stop conditions"，大部分架构问题都会落到控制流上。

这一类里能看到很多熟悉的骨架：

* `Action-Selector Pattern`
* `Autonomous Workflow Agent Architecture`
* `Plan-Then-Execute Pattern`
* `Inversion of Control`
* `Language Agent Tree Search (LATS)`
* `Swarm Migration Pattern`

这类模式的价值，在于把控制面拆开写清楚了。比如 `Plan-Then-Execute` 对应的是产出计划，再按计划执行，条件变化时再强制 replan；多 Agent 相关模式关心的是切分范围、并发上限、汇总方式和回滚条件，不只是多开几个分身。

这类条目读多了，你会逐渐习惯另一种提问方式：主 Agent 和子 Agent 的写入范围在哪里？哪些步骤允许自动推进？遇到失败是重试、降级还是交回人工？结果怎么统一进入评测和审计链路？这些问题一旦提前回答，流程就会稳很多。

## Reliability & Eval：让系统能看、能放、能退

Reliability & Eval 关心的是系统跑起来以后怎样观察、复现和回滚。很多 Agent 项目到不了生产，问题不在单次演示效果，而在出了事以后完全没法复盘。

这一组里的代表模式包括：

* `LLM Observability`
* `Action Caching & Replay Pattern`
* `Agent Circuit Breaker`
* `Canary Rollout and Automatic Rollback for Agent Policy Changes`
* `Workflow Evals with Mocked Tools`
* `Anti-Reward-Hacking Grader Design`

这些名字听起来偏基础设施，但恰好是上线前最该补齐的地方。`LLM Observability` 让你看见复杂任务卡在哪一跳、哪次工具调用、哪段提示上；`Action Caching & Replay` 让一次失败能被重放；canary rollout 则是在提醒你，Agent 策略更新也该像服务发布一样先灰度、再放量、必要时回滚。

如果一个团队回答不了"昨天为什么失败""这次策略更新到底好没好""问题能不能原样回放"，那它离生产还有一段距离。

## Security & Safety：权限一开，安全就是主线问题

只要 Agent 能读外部内容、接触私有数据、还能自主执行操作，安全就会变成主线问题。Security & Safety 这一组收的就是这些高风险接口的控制办法。

这一类里比较典型的有：

* `PII Tokenization`
* `Lethal Trifecta Threat Model`
* `Deterministic Security Scanning Build Loop`
* `Deterministic Threat Rule Scanning`
* `Hook-Based Safety Guard Rails for Autonomous Code Agents`
* `Black-Box Skill Invocation`
* `Denial Tracking & Permission Escalation`

这些模式的共同点，是尽量把风险从提示层拉回系统层。`PII Tokenization` 在进入模型前做脱敏；`Black-Box Skill Invocation` 把危险动作包进受控接口；`Denial Tracking & Permission Escalation` 让"权限不够怎么办"变成显式流程，不再让模型自己在那边瞎试。

作者长文提到一个很实用的判断：如果一个 Agent 同时能接触私有数据、面对不可信输入、还拥有执行能力，这就是高危组合。设计时要做的，是把这三个条件至少拆掉一个，不要等上线后再赌不会出事。

## Tool Use & Environment：工具接得越多，越要管好环境

仓库和网站把这一组命名为 `Tool Use & Environment`。把它理解成"工具调用和运行环境"这一层就行。

常见条目包括：

* `Agent-First Tool Discovery`
* `Unified Tool Gateway`
* `CLI-Native Agent Orchestration`
* `LLM-Friendly API Design`
* `Code-Over-API Pattern`
* `Progressive Tool Discovery`
* `Static Service Manifest for Agents`

这一层最容易被低估。很多团队会觉得把 MCP 接上、Shell 放开、API 文档给全，就算工具接入完成了。影响稳定性的，往往是接口是否清晰、是否暴露了最小必要能力、是否有统一入口和日志、模型是否知道什么该用什么不该用。

`LLM-Friendly API Design` 问的是：模型读到这个接口定义时，能不能稳定调用成功；`Progressive Tool Discovery` 处理的是按任务逐步揭示工具，减少误用；`Unified Tool Gateway` 则把权限、审计、配额、路由收回统一入口。工具不是越多越好，关键在能否被安全、稳定地使用。

## UX & Collaboration：人和 Agent 之间也需要接口设计

这一组很容易被当成"以后再说"，但只要进入团队环境，它马上就会变成上线条件。人类怎样读懂 Agent 做了什么，怎样在关键节点接管，怎样审批高风险动作，这些都属于 UX & Collaboration。

这组里比较有代表性的模式有：

* `Human-in-the-Loop Approval Framework`
* `Spectrum of Control`
* `Abstracted Code Representation for Review`
* `Agent-Assisted Scaffolding`
* `Agent-Friendly Workflow Design`

一个成熟团队通常不会执着于"完全自治"，更常见的目标是把高频低风险动作自动化，把关键节点留给人。`Human-in-the-Loop Approval Framework` 讲的，是哪些动作要审批、审完之后留下什么记录、谁会在什么渠道收到提醒。`Spectrum of Control` 关心的则是控制权如何在人和 Agent 之间流动。

如果 review 信息太原始、上下文交接太含糊，团队就只能在"全自动"和"全手动"之间来回摇摆。把这一层单独建模，很有必要。

## 网站比仓库好用在哪

仓库首页适合总览；带着问题去查时，网站会更顺手。`agentic-patterns.com` 把这套模式库从线性列表做成了一个可搜索、可筛选、可跳转的使用界面，这对实际选型帮助很大。

### 搜索与筛选

网站首页和 `/patterns` 页面把搜索做成了显眼入口，还能按 category、status、complexity 等维度过滤。对于模式库来说，这种变化很重要：你不需要先知道条目名，才能开始查资料。

### 模式详情页

详情页会把 category、status、tags、summary 这些信息都结构化展示出来。像 `Session-Scoped Context Runtime for Agent Tools`、`LLM Observability`、`Human-in-the-Loop Approval Framework` 这样的模式，放在网页里会比仓库首页的列表更容易读。

### 决策向导

`/decision` 页是很实用的入口。它不要求你熟悉全部分类，会根据当前在建内容和最担心的问题缩小候选范围。对第一次接触模式库的人来说，这种问答式入口比从头扫列表高效得多。

### 关系图

`/graph` 提供的是按关系读库的方式。你会更容易看见哪些模式天然要一起考虑：上下文裁剪会牵到 orchestration，审批会连到 UX、security 和审计。对做系统设计的人来说，这种图比单列目录更符合实际问题。

### Pattern Packs

仓库首页和网站首页都把 Pattern Packs 当成"面向常见 Agent 架构的策展集合"来介绍。不过当前站点里的 `/packs` 路由会跳回 `/patterns`，说明这个方向已经写进产品叙事，但独立入口还在演进中。

### Guides

`/guides` 页面已经上线，但目前还是 "No Guides Yet"。这一点反而挺说明问题：项目显然不满足于做链接目录，后面还想继续补使用说明这一层。

## 读完之后，怎么整理自己的 Agent 设计备忘录

读这类库，最容易犯的错是记住一堆模式名，落到自己手里还是不知道怎么配。更实用的做法，是把它压成一份团队内部的设计备忘录，至少回答下面四层问题：

1. 主流程怎么跑：计划、执行、replan、子任务怎么切。
2. 当前步骤看什么：上下文如何裁剪，working memory 放哪里。
3. 出错怎么收敛：反馈源是什么，哪些检查必须过，哪些结果要回放。
4. 风险怎么收口：危险工具是否隔离，哪些动作要审批，谁负责最终接管。

落到文档里，可以直接写成问题清单：

```text
- 这个 Agent 的停止条件是什么？
- 它每一轮真正能看到哪些上下文？
- 失败后先读什么反馈，再决定重试还是升级人工？
- 哪些动作需要审批，哪些动作只能走受控工具网关？
- 如果今天晚上出问题，明天早上我们能不能重放、定位、回滚？
```

把这些问题答出来，pattern 才算真的进了设计。只收藏、不落文档，后面遇到事还是会回到现场拍脑袋。

---

---
url: https://ain.hmgf.hxcn.space/ai/tencentdb-agent-memory-deep-dive-202605.md
description: >-
  从仓库、配置文件和官方资料出发，拆开 TencentDB Agent Memory 的四层记忆结构、检索链路、OpenClaw 与 Hermes
  接入方式，以及记忆修正和数据治理细节。
---

# TencentDB Agent Memory

很多人第一次做 Agent 记忆，会直接把聊天历史越塞越长：上一轮对话带着，工具日志带着，报错也带着，能想到的上下文全带着。短任务还勉强能跑，长任务一拉起来就容易出三个问题：Token 开销一路涨，模型注意力被过程噪声拖散，真正要追溯细节时又很难从一大段摘要里找到原文。

TencentDB Agent Memory 的处理思路，是把“保存”拆成几层：底层保留原文和证据，中层做结构化提取和场景整理，高层只留足够轻的画像或任务图。设计上围绕三个目标展开：可追溯召回、结构化复用、错误可修正。

## 项目背景

TencentDB Agent Memory 是腾讯云数据库团队开源的一套 Agent 记忆系统，MIT 协议，当前同时面向两类接入形态：

* 作为 OpenClaw 插件使用；
* 作为 Hermes Gateway 适配层使用；
* 本地默认后端是 `SQLite + sqlite-vec`，也支持切到 Tencent Cloud VectorDB。

仓库把它的目标写得很明确：一条线解决单次长任务里的上下文过载，另一条线解决跨会话的长期记忆沉淀。腾讯云产品页和开发者社区文章给的口径也一致，强调的是四层渐进式记忆架构、混合召回，以及长周期任务里的 Token 与完成率收益。

## 目标、依赖和使用场景

依赖和前提先说清楚，免得把它想成“装上就什么都有”。

### 运行依赖

从 `package.json` 和仓库说明可以核对到：

* Node.js 要求 `>= 22.16.0`；
* OpenClaw 侧的兼容版本是 `openclaw >= 2026.3.7`，插件 API / Gateway 兼容标到 `>= 2026.3.13`；
* 默认本地存储依赖 `sqlite-vec`；
* 如果启用远程向量检索，需要额外配置 embedding 服务；
* 如果切到云端数据库后端，需要配置 Tencent Cloud VectorDB 连接信息。

`package.json` 里能看到几个关键依赖：`sqlite-vec`、`@node-rs/jieba`、`@tencentdb-agent-memory/tcvdb-text`、`@ai-sdk/openai`、`js-tiktoken`。对应到能力上，就是本地向量索引、中文分词、云向量数据库、OpenAI-compatible LLM 调用和 token 预算。

### 使用场景

按仓库和官方文章里的表述，这套系统的使用场景主要有下面几类：

* 长周期编程任务：同一 session 连续跑多个问题，工具日志很多；
* 跨会话助手：下一次对话需要接上前一次的偏好、约束和项目上下文；
* 需要回查证据的场景：模型给出记忆后，开发者还想一路追到原始对话和原始工具输出；
* 既要本地先跑通，又要能切换到云端存储的团队。

如果你的需求只是“把上一轮对话摘要一下，下轮接着聊”，这套系统会显得偏重；如果你关心长任务恢复、上下文压缩和记忆可审计性，它就有意义了。

## 它怎么组织短期、长期、检索和数据库记忆

### 四层长期记忆：L0 到 L3

仓库给出的长期记忆结构是一个四层金字塔：

![TencentDB Agent Memory 四层语义金字塔](https://gastigado.cnies.org/d/public/memory-pyramid-en.jpg)

* **L0 Raw Log / Conversation**：原始对话和事件流，保留完整证据；
* **L1 Atomic Memory / Atom**：从对话里提取出的事实、偏好、约束、阶段结论；
* **L2 Scene Block / Scenario**：按项目、主题或工作流场景聚合；
* **L3 Persona**：稳定的用户画像、服务风格和长期偏好。

这四层的好处很实在。你问“用户平时喜欢什么写法”，先查 `persona.md`；你问“这个偏好是在哪个项目里形成的”，往下看对应 scene；你再怀疑内容有误，就继续追到 L1 和记忆原文。

### 短期记忆：把厚日志卸到外面，当前上下文只留结构

短期记忆被拆成三层：

* 底层：`refs/*.md` 这类原始工具输出；
* 中层：`jsonl` 摘要或节点索引；
* 上层：Mermaid 任务画布。

这里的做法很直接：Agent 当前回合先读 Mermaid 里的任务结构，需要细节时，再通过 `node_id` 或 `result_ref` 去找原文。

![可回查的下钻链路](https://gastigado.cnies.org/d/public/flowchart1.png)

这和很多“压成一段摘要就结束”的做法区别很大。这里的压缩带着索引关系，后面还能展开。

### 检索记忆：关键词、向量或混合召回

`openclaw.plugin.json` 把召回策略写得很清楚：

* `keyword`
* `embedding`
* `hybrid`

默认是 `hybrid`。进一步说明里写得很清楚，它是 **BM25 + vector + RRF** 的组合，也就是关键词匹配、向量相似度和融合排序一起用。对应的默认参数还有：

* `recall.maxResults = 5`
* `recall.scoreThreshold = 0.3`
* `recall.timeoutMs = 5000`

源码里的 `auto-recall.ts` 也能对上这个行为：它会按当前用户输入检索 L1 记忆，再读取 `persona.md`，再装配 L2 scene navigation，最后把记忆工具调用指南附到系统上下文里。

### 数据库记忆：本地 SQLite 起步，必要时切到 TCVDB

默认后端是本地 `sqlite`，直接写成 `SQLite + sqlite-vec`。这对单机试用很友好，装完就能跑，不需要先配云服务。

如果要切云端，配置项是 `storeBackend = "tcvdb"`，并补齐：

* `tcvdb.url`
* `tcvdb.username`
* `tcvdb.apiKey`
* `tcvdb.database`
* 可选的 `alias`、`embeddingModel`、`caPemPath`

运维文档里还有一个很实用的回退入口：

```bash
memory-tencentdb-ctl config vdb-off --restart
memory-tencentdb-ctl config vdb-off --purge-creds --restart
```

前者把后端退回本地 SQLite，但保留云端凭据；后者连 `memory.tcvdb` 段一起清掉。这个设计很适合排障：先回本地跑通，再决定是否重新启用云端存储。

## 安装和运行

### OpenClaw 插件模式

最短路径是：

```bash
openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
openclaw gateway restart
```

然后在 `~/.openclaw/openclaw.json` 里启用插件：

```jsonc
{
  "memory-tencentdb": {
    "enabled": true
  }
}
```

如果你只想先验证长期记忆，这一步就够了。启用后，插件会自动完成：对话采集、记忆提取、场景归纳、画像生成、下一轮召回。

### 开短期压缩：还要加 slot 和 patch

短期上下文压缩默认关闭。开启方式是：

```jsonc
{
  "memory-tencentdb": {
    "config": {
      "offload": {
        "enabled": true
      }
    }
  }
}
```

同时还要补两步：

1. 在插件配置里注册 `contextEngine` slot；
2. 跑一次 `openclaw-after-tool-call-messages.patch.sh`。

配置和命令如下：

```jsonc
{
  "plugins": {
    "slots": {
      "contextEngine": "openclaw-context-offload"
    }
  }
}
```

```bash
bash scripts/openclaw-after-tool-call-messages.patch.sh
```

这个 patch 的作用写得很直接：把 `after-tool-call` 消息钩进去，让工具调用结果能被正确卸载和恢复。

### Hermes 模式：一体化镜像和运维脚本都给了

仓库里的说明、`docker/opensource/README-hermes.md` 和 `Dockerfile.hermes` 给了两条路径。

第一条是直接用 Docker 方式：

```bash
MODEL_API_KEY="your-api-key"
MODEL_BASE_URL="https://api.lkeap.cloud.tencent.com/v1"
MODEL_NAME="deepseek-v3.2"
MODEL_PROVIDER="custom"

docker build -f Dockerfile.hermes -t hermes-memory .

docker run -d \
  --name hermes-memory \
  --restart unless-stopped \
  -p 8420:8420 \
  -e MODEL_API_KEY="your-api-key" \
  -e MODEL_BASE_URL="https://api.lkeap.cloud.tencent.com/v1" \
  -e MODEL_NAME="deepseek-v3.2" \
  -e MODEL_PROVIDER="custom" \
  -v hermes_data:/opt/data \
  hermes-memory

curl http://localhost:8420/health
docker exec -it hermes-memory hermes
```

第二条是用 npm 包里的运维脚本 `memory-tencentdb-ctl.sh`。这组脚本把独立模式和 Hermes 模式分开了，能管理：

* Gateway 启停和健康检查；
* LLM、Embedding、VDB 配置写入；
* `config vdb-off` 回退；
* Hermes 侧 `memory.provider` 启用。

如果你要长期运维，而不只是跑一遍 demo，这条路径更合适。

## 一个完整流程：写入、检索、更新、用于回答

### 1. 写入记忆：L0 收集与分层入库

源码里的 `auto-capture.ts` 写得很清楚，流程从 L0 开始：

1. 对当前 session 的消息做原子化记录；
2. 把 L0 原文写入本地记录；
3. 如果向量存储可用，再补 L0 索引；
4. 通知 pipeline manager 决定是否触发 L1、L2、L3。

这里有两个细节：

* 它不会每来一条消息就立刻做全套提取，调度时机由 `pipeline.everyNConversations`、`l1IdleTimeoutSeconds`、`enableWarmup` 这类参数控制；
* 向量写入分成同步和后台两种路径，本地 SQLite 风格的存储允许先写元数据、后补 embedding，避免每轮对话都被 embedding 调用拖慢。

### 2. 检索记忆：分层召回顺序

`auto-recall.ts` 的装配顺序是：

1. 用当前用户输入搜索 L1；
2. 读取 `persona.md`；
3. 读取 scene index，生成 scene navigation；
4. 把记忆工具调用指南附到上下文。

如果注入的片段还不够，Agent 还能主动调用两把工具：

* `tdai_memory_search`：查结构化记忆；
* `tdai_conversation_search`：查原始对话。

源码里还专门限制了调用次数：单轮对话内两者合计最多 3 次。这个限制很有必要，不然 Agent 很容易在记忆工具上来回打转。

### 3. 更新记忆：场景块和 Persona 是可增量更新的

L3 更新也不会每次都重写全部内容。`persona-generator.ts` 里能看到它会：

* 读取现有 `persona.md`；
* 对照 checkpoint 找出上次之后变更过的 scene；
* 只把变化场景送给 LLM 重点分析；
* 先做备份，再写回新的 `persona.md`；
* 写完后再附带 scene navigation。

对应配置里也有备份数量参数：

* `persona.backupCount = 3`
* `persona.sceneBackupCount = 10`

可以把它理解成一次带增量范围和备份策略的更新，避免直接整份覆盖。

### 4. 用于回答：上层负责方向，下层负责证据

这里有一张很实用的对照表，可以概括成一句话：

* 问长期偏好、服务风格、目标，先查 L3 / L2；
* 问具体事实、日期、项目细节，继续往 L1 / L0 下钻；
* 问长任务当前进度，先查 Mermaid 画布；
* 需要原始证据，就按 `node_id` 和 `result_ref` 追到原文。

短期压缩链路本身也是这样工作的：

![短期上下文卸载与注入链路](https://gastigado.cnies.org/d/public/flowchart2.png)

所以回答阶段真正进入上下文的，优先是画像、场景导航、相关记忆片段和任务结构；原始大文本留在外部，按需再取。

## 隐私、权限、过期和错误记忆修正

这一部分不能只看宣传页，最好对照配置和运维文档。

### 数据默认放在哪里

OpenClaw 侧的分层记忆产物默认放在 `~/.openclaw/memory-tdai/`。Hermes 一体化镜像文档里，则把数据卷落在 `/opt/data/tdai-memory/`，其中包括：

* `memories.sqlite`
* `scene_blocks/`
* `persona.md`
* `checkpoint.json`

如果你在做本地试用，这些路径要先看清楚。很多“记忆错了”的问题，最后都得直接打开这些文件定位。

### 过期和保留天数怎么配

`openclaw.plugin.json` 里有明确参数：

* `capture.l0l1RetentionDays`
* `capture.allowAggressiveCleanup`
* `capture.cleanTime`

默认 `l0l1RetentionDays = 0`，也就是不自动清理。若要清理，文档要求一般至少 3 天；1 或 2 天属于高风险设置，需要显式打开 `allowAggressiveCleanup`。这说明作者默认更看重可追溯性，不鼓励把底层证据清得太快。

### 错误记忆怎么修

这套系统给出的修正路径分三层：

1. **回查**：从 `persona.md` 或 Mermaid 画布一路追到 scene、L1、L0，确认错误是抽取错、聚合错，还是原始信息就有歧义；
2. **覆盖或回退**：`persona-generator.ts` 会在写新画像前先做备份；运维层还有 `config vdb-off`、`--purge-creds` 这种回退入口；
3. **用工具补查原文**：`tdai_memory_search` 和 `tdai_conversation_search` 分开查结构化记忆与原始对话，便于交叉核对。

另一个容易忽视的点是 `extraction.enableDedup = true`。配置文件把它定义成 L1 去重和冲突检测开关，说明作者默认已经把“同一事实重复写入”当成常见问题处理了。

### 权限和凭据处理

运维文档里明确写到 `tdai-gateway.json` 权限是 `0600`，LLM / Embedding / VDB 凭据统一落在这个配置文件或 Hermes 的专用 env 文件里。对团队部署来说，这比把 Key 散落在一堆 shell 历史里要稳。

但这仍然只是“有收口”，凭据集中管理是第一步，团队部署还需补充访问控制和审计。如果要上团队环境，至少还得自己补三件事：

* 限制谁能读记忆目录和配置目录；
* 决定哪些 session 允许被长期保留；
* 把导出诊断包、备份目录和日志目录纳入运维审计范围。

---

---
url: https://ain.hmgf.hxcn.space/ai/agent-memory-principles-repost-note-202605.md
description: >-
  基于本地 HTML 整理一篇关于 Agent 记忆系统的社媒长文，并补充 TencentDB-Agent-Memory、Hermes、PageIndex
  的位置区别。
---

# AI Agent 如何记住东西

来源：<https://x.com/lxfater/status/2054396603197505745>

Agent 记忆涉及几个容易混淆的概念：单会话记忆、跨会话记忆、持久化记忆。下面按原意整理，再补本站的对照说明。

## 记忆机制的基础层

大模型本身不会自动记住上一次 API 调用里发生的事。你这次问它、下次再问它，如果系统没有把旧内容重新带进 prompt，它就不知道你前面说过什么。

所以"Agent 有记忆"这句话，通常说的"有记忆"，更多是在外层系统做了三件事：

1. 在单个会话里，把前文对话一起带给模型。
2. 上下文太长时，压缩旧内容，把摘要继续塞回 prompt。
3. 跨会话时，把重要信息存到外部记忆层，需要时再取回来。

所谓长期记忆，很多时候是"外部存储 + 适时召回"，不是模型自己天然拥有长期状态。

![Agent 记忆三分类示意图](https://gastigado.cnies.org/d/public/memory-social-05.jpg)

## 理解框架

Agent 记忆可以拆成两组问题，这个框架很好用：

* 记忆分几类，每类存什么。
* 记忆怎么抽取、更新、检索。

### 记忆通常分三类

这篇文章引用了一篇题为 *Context Engineering, Sessions and Memory* 的论文框架，把 Agent 记忆分成三类：

* **情景记忆**：昨天发生了什么、上次聊了什么。
* **语义记忆**：你是谁、喜欢什么、有哪些稳定偏好。
* **程序性记忆**：一件事怎么做，流程和套路是什么。

这个分类对应了工程里的三种不同数据：会话历史、用户画像、任务方法。很多项目实现不同，但大多都绕不开这三块。

### 记忆流程通常分三步

"维护记忆"可以总结成三个动作：

* **抽取**：从对话和执行轨迹里挑出该记的内容。
* **更新**：旧信息冲突时，要合并、替换或降权。
* **检索**：新任务开始时，把相关记忆拉回来。

这三步里，最难的往往落在"更正"。错误记忆如果被当成稳定事实，体验会比没有记忆更糟。

## OpenClaw 的实现方式

### OpenClaw 的记忆分类

按照这篇文章的整理，OpenClaw 主要用了三类文件：

1. `memory.md`
   * 偏语义记忆，存身份、偏好、稳定事实。
2. `daily logs`
   * 偏情景记忆，按天追加关键事件。
3. `session snapshots`
   * 在新会话开始前，总结旧会话里最后一段有意义的消息。

这种设计以文件为单位，调试时可直接查看。局限在于：如果上下文特别长，或者任务跨度很大，Markdown 文件会越来越像"半结构化备忘录"，检索和更新都容易失真。

### OpenClaw 的抽取、更新、检索

OpenClaw 的写法可以概括成三类触发时机：

* 压缩上下文前，把值得留下的内容写入日志。
* `/new`、`/reset` 开新会话时，生成会话快照。
* 用户明确说"记住这个"时，系统判断写去哪一层。

读的时候也分两种：

* 新会话启动时，把 `memory.md` 和最近日志注入 prompt。
* 运行中需要时，再通过搜索工具去找、再读取原文。

![OpenClaw 的抽取、更新、检索示意图](https://gastigado.cnies.org/d/public/memory-social-08.jpg)

它代表的是一种很常见的工程做法：**一个始终注入的小记忆层，配一个按需搜索的大记忆层。**

## EverOS 的方案特点

### EverOS 的记忆拆得更细

官网：<https://evermind.ai>

文档：<https://docs.evermind.ai>

EverOS 把记忆对象分得更细。

它在三大类下面继续细分：

* **语义记忆**：稳定特质、临时状态。
* **情景记忆**：Episode、EventLog、Foresight。
* **程序性记忆**：Agent Case、Agent Skill。

这个拆法背后的想法很朴素：

* 有些信息适合长期保留。
* 有些信息只在某段时间有效。
* 还有一类信息记录的是这类事通常怎么做，和人设本身关系不大。

有两点需要注意：

* 它会把"未来要做什么"当成单独对象处理。
* 它会把反复做同类任务形成的方法蒸馏成 skill，不只留下原始日志。

### EverOS 重点解决的是"更新"问题

官网：<https://evermind.ai>

文档：<https://docs.evermind.ai>

讲得最透的一段，落在"怎么改"。

举的例子也很典型：

* 一个月前说准备健身。
* 两周前说最近忙，没去。
* 今天说算了，不健身了。

如果系统只是把三句话都塞进日志，检索时拿到哪条就算哪条，那记忆基本不可用。EverOS 的思路，是做所谓"语义巩固"，把重复、冲突、时效不同的信息重新整理，尽量得到一个当前可用的版本。

![记忆更新示意图](https://gastigado.cnies.org/d/public/memory-social-11.jpg)

问题常常不在存不够，而在更新规则太弱。

## 本站补充：它和 TencentDB-Agent-Memory、Hermes、PageIndex 是什么关系

### TencentDB-Agent-Memory：更强调分层和符号化记忆

TencentDB-Agent-Memory 仓库首页直接把核心口号写成了"symbolic short-term memory + layered long-term memory"。它和上面那篇社媒长文的共识，基本在同一方向：

* 不能把所有东西平铺到一个向量库里。
* 短期记忆和长期记忆该分层。
* 检索前最好先做结构化抽取和压缩。

它和 OpenClaw 的差别，在于它更强调**短期上下文也要分层管理**，例如把原始工具输出、步骤级摘要、顶层状态图拆开。和 EverOS 的差别，在于它更突出"短期任务过程怎么降 token、怎么保留结构"。

EverOS 更偏长期记忆操作系统这一路，TencentDB-Agent-Memory 则把**短期 + 长期**一起重新组织了一遍，尤其适合工具调用很多、上下文膨胀快的 Agent。

### Hermes：把记忆、技能和进化流程放到一起

文档：<https://hermes-agent.nousresearch.com/docs/>

来源：<https://x.com/akshay_pachaar/status/2054884266522210425>

Hermes 走的是另一种组合方式。从社媒材料和相关文档摘要看，它常被概括成三层记忆：

* 很小的 `MEMORY.md` / `USER.md`，常驻 prompt。
* 基于 SQLite + FTS5 的会话全文检索。
* 可插拔的外部记忆提供者。

它和 OpenClaw 的相似点，在于都有一个常驻的小记忆层；它和 EverOS 又有共通处，都会把技能沉淀、自我更新、长期行为调整放进同一套流程里。

如果只盯着"记忆"二字，Hermes 会被看窄。它不只是一个记忆数据库，而是把**记忆、技能生成、进化验证**绑在一起的 agent runtime。

### PageIndex：它解决的是文档检索，不等于人格记忆

官网：<https://pageindex.ai/developer>

文档：<https://docs.pageindex.ai>

PageIndex 经常会被放进"记忆"讨论里，但它的重点不在用户画像、偏好演化或任务技能沉淀，而在**长文档检索**。

项目首页对它的定位很明确：vectorless、reasoning-based RAG。它不靠传统向量分块，做法是先建立树状索引，再做基于推理的树搜索。

它和前面几个项目的关系，可以这样理解：

* OpenClaw / EverOS / Hermes 主要处理 Agent 自己要记住什么。
* PageIndex 主要处理 Agent 要怎样读回外部长文档。

它可以成为记忆系统的"外脑检索层"，但不能直接替代用户记忆、情景记忆或技能记忆。

## 再回头看"记忆"两个字

如果你以后再看任何一个 Agent memory 项目，可以问四件事：

1. 它把记忆分成了哪几层。
2. 每层分别存什么。
3. 冲突信息怎么更新。
4. 检索时是直接搜，还是会先做结构化重建。

按这个框架去看，很多项目就不容易混了：

* OpenClaw 代表的是文件型、可解释、较轻量的记忆组织方式。
* EverOS 代表的是更细粒度、也更贴近生产系统的长期记忆设计。
* TencentDB-Agent-Memory 补的是分层短期记忆和符号化压缩。
* Hermes 把记忆和技能进化串成了完整流程。
* PageIndex 属于外部知识检索层。

---

---
url: https://ain.hmgf.hxcn.space/ai/hermes-agent-masterclass-zh-202605.md
description: >-
  根据两份本地 X HTML 资料，整理 Hermes Agent 的三层记忆、SOUL 身份层、自进化技能、GEPA
  与多代理工作流，并补充长会话状态保持的理解框架。
---

# Hermes Agent：三层记忆与多代理工作流

这篇文章只根据两份本地资料整理与翻译，不把社媒长文当成官方文档替代品，也不把评论区观点写成既成事实。

* 本地 HTML 1：`temp/X 上的 Akshay 🚀："Hermes Agent Masterclass" _ X (2026_5_16 14：39：52).html`
* 本地 HTML 2：`temp/X 上的 Akshay 🚀："the three-tier memory of Hermes agent._AI agents forgets everything when your session ends. Hermes doesn't._it has three memory layers, each at a different speed….html`
* 原始 X 来源（社媒长文）：<https://x.com/akshay_pachaar/status/2054564519280804028>
* 原始 X 来源（社媒线程）：<https://x.com/akshay_pachaar/status/2054861039804772827>

为了便于回查，我把原始 HTML、清理摘录和图片都放进了 `docs/ai/references/hermes-agent-masterclass-zh/` 与 `docs/ai/assets/hermes-agent-masterclass-zh/`。正文分成长文、线程和合并整理三部分。

## 一、`Hermes Agent Masterclass` 讲了什么

来源类型：**社媒长文 / X Article**\
对应入口：<https://x.com/akshay_pachaar/status/2054564519280804028>

这篇长文的主线很明确：Hermes 不只想做一个"会聊天的 agent"，它想把三件通常分开的能力放到同一套运行时里：

1. 持续记忆；
2. 自己写、自己维护的技能；
3. 离线优化技能质量的 GEPA 管线。

原文开头把问题说得很直接：很多 agent 一到新会话就要重新开始，之前纠正过的项目约定、工具坑、修复经验，都得再讲一遍。单靠拉长上下文，Hermes 觉得不够用，所以它把"身份、记忆、技能、离线优化"拆成了几层。

### 1. 架构重点：统一的 agent core

长文把 Hermes 描述成一个**平台无关的 agent core**。CLI、消息网关、批处理、IDE 集成，都只是进入同一个 `AIAgent` 核心类的不同入口。

下图是长文里给出的结构图：

![Hermes 核心结构图](https://gastigado.cnies.org/d/public/masterclass-architecture.jpg)

按原文整理，这个核心循环有几个关键点：

* 采用类似 ReAct 的同步循环；
* 每轮构造系统提示，判断要不要压缩；
* 然后发起可中断的模型调用；
* 有工具调用就执行，再继续下一轮。

原文还特别点出三件工程细节：

* 执行位置可以切换，本地终端、Docker、SSH、Modal、Daytona、Singularity 都是同一套逻辑；
* 模型提供方可以替换，Claude、GPT、Gemini、本地 Ollama 等可以通过兼容层接进去；
* 单个任务有 90 轮上限，子代理共享这笔预算，避免递归委派把额度悄悄烧穿。

这些工程细节后面都会用到：长期运行、多代理配置和技能沉淀都建立在这里。

### 2. 记忆之前还有 `SOUL.md`

长文专门把 `SOUL.md` 放在记忆系统前面讲。原文的意思是：记忆解决"知道什么"，技能解决"怎么做"，但两者都不决定"这个 agent 以什么风格出现"。

Hermes 把这层身份定义放进一个单独文件里：

* 默认位置：`~/.hermes/SOUL.md`
* 加载顺序：系统提示最前面
* 作用：人格、语气、沟通方式、行为约束

这层定义放在最前面，作用就是先把角色和行为口径定住，后面的记忆与技能都在这个前提下展开。

### 3. 三层记忆只是其中一部分

长文里的记忆章节和后面的独立线程讲的是同一套东西，但长文给出的语境更完整：三层记忆是为了让 agent 在**会话内**和**跨会话**之间都能保持状态，不需要把所有内容都常驻在 prompt 里。

下图是长文配图里的三层记忆示意：

![Hermes 三层记忆示意图](https://gastigado.cnies.org/d/public/masterclass-memory-tiers.jpg)

这里先记住长文给出的总原则：

* **始终在上下文里的内容要极小**；
* **容量大的内容应该可检索，不适合常驻**；
* **更深层的语义建模可以外接 provider，但不能直接替代前两层**。

### 4. 自进化技能：把做过的流程沉淀下来

长文把 skills 解释为程序性记忆。重点不在"模型知道什么"，而在"模型以后遇到同类问题时按什么步骤做"。

原文给出的技能结构是 Markdown + YAML frontmatter，大意包括：

* skill 名称与触发描述；
* 适用平台；
* 具体步骤；
* 常见坑；
* 验收标准。

长文强调了一个很重要的设计：**progressive disclosure**。也就是：

* 第 0 层只让 agent 看见技能名和描述；
* 真要用某个技能时，再加载完整内容；
* 如果技能里还有参考文件，继续按需深入。

这样可以把 token 用量压住。技能库越大，这种按需展开就越重要。

### 5. Curator：技能会增殖，所以要有人负责清理

原文没有把"自进化技能"讲成无条件利好，反而花了不少篇幅说明技能库会越来越乱：重复、过窄、长期不用的 playbook 会不断堆积。

Hermes 在长文里的解法叫 **Curator**。按原文整理，它有几个限制条件：

* 只处理 agent 自己创建的 skills；
* 不自动删官方 bundled skill，也不动 hub 安装的 skill；
* 不做不可恢复删除，最坏情况是归档到 `.archive/`；
* 每次整理前会先做整目录备份。

Curator 负责后台归档和修剪，不负责让 agent 自由改写一切。

### 6. GEPA：运行时会积累经验，但离线优化另算一层

长文里关于 GEPA 的段落也很清楚：它**不在 Hermes runtime 里面**，而是单独跑在配套仓库中。

* 配套仓库：<https://github.com/NousResearch/hermes-agent-self-evolution>
* 论文入口：<https://arxiv.org/abs/2507.19457>

这里的关键判断是：如果直接让 agent 自己评估"我刚才做得怎么样"，它往往会高估自己。GEPA 会读取执行轨迹，分析失败点，再通过演化搜索提出候选改法，然后用评测规则筛选，最后以 PR 形式输出，不直接写进运行时。

这三块各管一段：

* **runtime loop** 负责一边工作一边积累经验；
* **Curator** 负责整理已有技能；
* **GEPA** 负责离线打磨那些真正值得保留的技能版本。

### 7. 从安装到可用

长文后半段不再复述概念，直接从安装写到多代理实践。它给出的最短命令是：

```bash
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
hermes setup
hermes
```

接下来它把 Telegram 接入也放进同一条链路里：

* Bot token 通过 <https://t.me/BotFather> 获取；
* Telegram user id 通过 <https://t.me/userinfobot> 获取；
* 然后把 Hermes 指到对应 bot。

原文的重点不在"终端能跑起来"，而在"从手机上也能把 agent 当成常驻入口来用"。

### 8. profiles、多代理与分工

长文里一个很值得保留的点，是多代理用**隔离 profile** 来落地，不是给一个大 agent 配一堆标签。

按原文整理，profile 的隔离范围包括：

* 独立 config；
* 独立 memory；
* 独立 skills；
* 独立 sessions；
* 独立 `SOUL.md`。

长文给出的三种示例 agent 是：

* designer
* programmer
* researcher

并且强调它们默认**互不共享状态**。这个设计和很多"所有人共用一份记忆池"的系统正好相反。

下图是长文里的 Telegram 多代理示意图：

![三个 Telegram 代理示意图](https://gastigado.cnies.org/d/public/masterclass-three-agents-telegram.jpg)

### 9. 三种代理的工作方式也不同

原文没有只停留在"建三个角色"。它给出的用法是分工不同、执行链路也不同。

#### programmer

长文里最详细的是 programmer profile。原文建议让 Hermes 负责编排，把真正的读写代码、跑命令、管理 git 的执行交给 Claude Code CLI。也就是说：

* Hermes 决定接下来做什么；
* Claude Code 负责实际代码执行；
* Hermes 再根据结果继续判断。

这是 orchestration 与 execution 分离的一种做法。

#### designer

designer profile 的思路是：喂参考图，让 agent 自己写出"生成同风格图片"的 skill。也就是把风格学习本身也做成 skill 生成任务。

#### researcher

researcher profile 则被拿来做 Telegram 日报。原文提到 Hermes 自带 scheduler，agent 可以用自然语言定义任务，再交给 cron 组件定时运行，输出会写到相应目录并投递到聊天入口。

这三种用法合在一起，才是长文所谓"从 1 个 agent 变成 10 个 agent"的具体做法：每个 profile 都有自己的身份、技能、记忆和消息入口。

## 二、three-tier memory 线程整理

来源类型：**社媒线程 / X post**\
对应入口：<https://x.com/akshay_pachaar/status/2054861039804772827>

这条线程比长文短很多，但内容更集中，基本只讲三层记忆本身，以及三层在单轮对话里怎样组合。

### 1. Tier 1：两份很小的 Markdown 文件

线程把第一层概括成两个小文件：

* `MEMORY.md`：约 2200 字符上限
* `USER.md`：约 1375 字符上限

按线程原意：

* `MEMORY.md` 存项目约定、工具脾气、经验教训；
* `USER.md` 存用户画像，例如名字、沟通风格、技能水平、需要避免的事项。

它们会在**会话开始时**作为冻结快照注入系统提示。这个"冻结快照"很关键，因为线程同时说明了一点：即使本轮会话中 agent 又写入了新记忆，这条更新虽然已经落盘，但当前会话里的 prompt 不会立刻变；它要到下一个 session 才会自然出现。

线程还解释了为什么这一层必须足够小：文件到达大约 80% 容量时，会触发 consolidation。也就是：

* 合并相关条目；
* 删除冗余；
* 保留信息密度更高的版本。

线程把这种机制叫作"对记忆施加自然选择压力"。重点不是保存尽可能多，而是让真正会重复出现、以后真的还会用到的事实留下来。

### 2. Tier 2：会话全文检索，按需搜索

线程给第二层的定义是：

* 所有会话写入 SQLite；
* 通过 FTS5 建全文索引；
* agent 需要时调用 `session_search` 去找。

线程里还有一个很具体的执行细节：当 `session_search` 触发时，FTS5 会先在成千上万份文档里做快速排序，然后再让 LLM 汇总高相关结果，最后只把一段紧凑结果送回当前上下文。

这里的分工很清楚：

* tier 1 一直都在，但非常小；
* tier 2 几乎不限容量，但要主动搜索；
* 因此"关键事实进 memory，其他内容保持可搜索"才是它想要的工作方式。

### 3. Tier 3：外部 memory providers，与前两层并行

线程里把第三层定义为 8 个可插拔 provider 的集合，并强调：**它们是 alongside，不是 replacement**。

线程点名提到的三个例子是：

* Honcho
* Holographic
* Supermemory

对应入口在官方文档里可以继续看：<https://hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers>

这一段重点不在 provider 名单，而在接入方式：

* 每轮开始前做 prefetch；
* agent 回复后做 sync；
* 会话结束时做 extraction。

也就是说，第三层承担的是更慢、更深的语义记忆建模，但它依然围绕前两层运转，不会把常驻小记忆和全文检索替掉。

### 4. 三层在单轮对话里怎样组合

线程里最有价值的一段，是把三层记忆压成了一个五步循环：

1. 新一轮开始时，tier 1 已经在 prompt 里，tier 3 先把预取结果补进来；
2. agent 在这三层共同提供的上下文上作答；
3. 周期性 nudge 触发，agent 会判断这一轮有没有值得沉淀的内容；
4. 如果有，就写进 `MEMORY.md`，但当前会话里因为 prefix cache 仍然是旧快照，所以不会立即可见；
5. 会话结束时，tier 2 记录转录，tier 3 做语义抽取，下个 session 再带着新状态开始。

这一段把 Hermes 记忆系统最重要的工程事实讲清楚了：**会话内的持续可用状态、跨会话的状态保持，以及更深层的语义提取，不是同一速度。**

## 三、把两篇重复内容并成一套理解框架

前面的长文和线程有不少重复点，合在一起看，会更容易把 Hermes 的记忆和工作流分清。

### 1. 长会话靠分层，不靠无限上下文

两篇资料都在强调，长会话要靠内容分流：

* 小而稳定、必须一直带着的内容，放 tier 1；
* 大而杂、但偶尔需要追溯的内容，放 tier 2；
* 更慢、更深的用户建模或外部语义记忆，放 tier 3。

如果把所有历史都塞进 prompt，走的是另一条路。Hermes 选择的是：保住核心热记忆，给冷数据准备检索面，再把更深的长期建模放到 provider。

### 2. 记忆和工具调用是连在一起的

两篇资料都没有把 memory 写成纯数据库能力。它本身就是工具链的一部分：

* tier 2 要靠搜索工具拿结果；
* tier 3 要靠 provider 的同步与抽取机制接起来；
* skills 则把"下一次怎么操作工具"沉淀成程序性记忆。

所以 Hermes 的运行状态，依赖的是一套外部系统组合：

1. 小记忆给当前轮次定基调；
2. 需要细节时再查历史会话；
3. 需要更深用户建模时走外部 provider；
4. 反复成功的工具用法，再进一步提炼成 skill。

### 3. 记忆负责保留状态，skill 负责保留做法

这是两篇资料最该分开的地方。

* `MEMORY.md` / `USER.md` 保存的是事实、偏好、约束；
* session search 保存的是可追溯历史；
* provider 保存的是更慢的语义层；
* skills 保存的是可复用工作流。

因此，Hermes 组织起来的不止多层记忆，还包括**身份层、事实层、历史层、外部记忆层、程序性技能层**。

## 四、延伸说明

下面不再逐段翻译，直接把前面的材料收成几条便于理解的说明。

### 1. 什么叫快慢记忆

如果只按工程速度区分，Hermes 的三层记忆可以这样理解：

* **快记忆**：tier 1。小、热、始终在 prompt 里。
* **中速记忆**：tier 2。默认不进 prompt，需要时快速搜索。
* **慢记忆**：tier 3。依赖 provider 做更深的预取、同步和抽取。

这也是为什么线程一再强调"不同速度"。不是每种信息都该以同样方式保存、同样时机读取。

### 2. 会话结束后怎样保持状态

两份资料合起来，Hermes 的跨会话保持机制大致是：

* 会话开始：读取 tier 1 快照，必要时加上 tier 3 预取结果；
* 会话进行中：如果出现值得记住的内容，可以写入磁盘，但当前 prompt 不会立刻重构；
* 会话结束：tier 2 记完整历史，tier 3 提取更深层语义；
* 下次再开：新快照和新提取结果成为新的起点。

因此，会话结束后留下来的，不是"模型脑子里的状态"，而是已经被外部系统整理过的状态；下次再开会话时，它会按合适速度被带回来。

### 3. Agent 工作流怎么用

长文给出的三种 profile，正好可以拿来说明这套工作流怎么落地。

#### programmer：编排和执行拆开

programmer profile 的思路是 Hermes 做总控，Claude Code CLI 做实际代码执行。这里的重点不在换模型，而在让**编排、代码修改、命令执行、git 操作**各有稳定入口。

#### designer：把风格学习也做成 skill 生成任务

designer profile 的做法，是给范例，让 agent 根据范例总结工作法。参考图不是一次性喂完就结束，而会被转成后续可复用的 skill。

#### researcher：把定时任务交给 scheduler

researcher profile 用来跑 Telegram digest，说明 Hermes 并不把 agent 限定为"等你问一句答一句"。它也可以承担按计划执行、自动投递的工作。

如果把这三种模式放在一起看，Hermes 的工作流大致是：

* 用 `SOUL.md` 固定身份；
* 用三层记忆保存状态；
* 用 skills 固定做法；
* 用 scheduler 让某些任务脱离人工触发。

## 五、引用与转载说明

这篇文章的资料性质需要单独说明：

* `Hermes Agent Masterclass` 是**社媒长文 / X Article**；
* three-tier memory 是**社媒线程 / X post**；
* 文中关于仓库、文档、论文、Telegram 入口的链接，都是从原文保留下来的非 `t.co` 目标或与原文对应的直接入口；
* 正文以整理、翻译、说明为主，没有整段转抄长文；
* 如果要核对实现细节，应继续看官方文档与仓库：<https://hermes-agent.nousresearch.com/docs/>、[NousResearch/hermes-agent](https://github.com/NousResearch/hermes-agent)。

## 六、延伸阅读

如果你想把 Hermes 放回更大的 Agent 记忆与 RAG 语境里，可以继续看这几篇：

* 第 11 篇：[`TencentDB Agent Memory`](/ai/tencentdb-agent-memory-deep-dive-202605)
* 第 30 篇：[`AI Agent 如何记住东西`](/ai/agent-memory-principles-repost-note-202605)
* 第 39 篇：[`PageIndex：树状索引版 Vectorless RAG`](/ai/pageindex-vectorless-rag-202605)

---

---
url: https://ain.hmgf.hxcn.space/ai/pageindex-vectorless-rag-202605.md
description: >-
  从 VectifyAI/PageIndex 的项目说明、官方文档与框架文章出发，说明它怎样把长文档整理成树状索引，再用 reasoning
  完成带来源的问答。
---

# PageIndex：树状索引版 Vectorless RAG

它被概括为"基于无向图（Vectorless）和推理（Reasoning）的 RAG 文档索引"。结合项目说明，更准确的理解是：它把长文档整理成一棵层级化目录树，再让模型顺着章节、子节点、页码和文内引用一路找下去。这里说的 `Vectorless`，重点落在两件事：不用向量数据库，也不把文档先切成一堆固定 chunk 再做相似度召回。

## 项目背景、目标与安装方式

### 项目介绍

* GitHub：<https://github.com/VectifyAI/PageIndex>
* 官网：<https://pageindex.ai/>
* 文档：<https://docs.pageindex.ai/>
* Framework 文章：<https://pageindex.ai/blog/pageindex-intro>

PageIndex 由 Vectify AI 维护。仓库首页一句自我介绍是：`Vectorless, Reasoning-based RAG`。它面向的是财报、法律文件、技术手册这类长而且结构复杂的文档。官方想解决的问题很明确：很多答案藏在文档的某个章节、某个附录、某一页，甚至还要顺着文内引用继续往下找。

PageIndex 走的是人工翻长文档那条路：从目录进入，定位到章节，再补页码，必要时顺着"见附录 G""详见表 5.3"这样的内部线索继续找。仓库把整个检索流程压成两步：

1. 生成一份类似目录的树状索引；
2. 沿着这棵树做 reasoning-based tree search。

安装方式分成两条线。

### 1. 云服务与 SDK

官方文档的 Getting Started 走的是云服务路径。在开发者后台拿 API Key，再安装 Python SDK：

```bash
pip install -U pageindex
```

最小初始化方式是：

```python
from pageindex import PageIndexClient

pi_client = PageIndexClient(api_key="YOUR_API_KEY")
```

这条线路的重点是上传 PDF、等待云端处理完成，然后通过 Chat API 或 MCP 接入自己的 Agent。

### 2. 开源仓库与本地示例

开源仓库这边更偏自托管示例和本地树索引流程。仓库里现成给了一个 `agentic_vectorless_rag_demo.py`，附加依赖安装方式是：

```bash
pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py
```

仓库还专门区分了部署方式：本地开源仓库用标准 PDF 解析跑通流程；官方云服务则强调增强 OCR、树构建和检索链路。也就是说，仓库适合理解原理、试本地 Agent 集成，生产环境里的完整处理链还是以官方服务为主。

## Vectorless 的重点：按文档结构组织内容

PageIndex 对 `vectorless` 的解释很稳定：**不用 vector DB，不做固定 chunking，但仍然做检索**。区别在于，检索入口不是一批预先算好的向量，而是模型能直接读懂的文档结构。

官方 Framework 文章里有一段很关键：传统向量 RAG 假设"语义最像的段落，就是最相关的段落"；PageIndex 认为这两个判断经常不是一回事。用户问"递延资产总额是多少"，答案可能根本不在最像问题的正文里，而藏在正文某句话指向的附录表格里。遇到这种场景，比相似度很容易卡住，按文档结构找会更贴近人翻长文档的过程。

因此，PageIndex 对文档的组织方式有三个特点。

### 保留自然章节，别按固定长度硬切

官方资料都反复强调 `No Chunking`。这里指的是**不按固定 token 长度生硬切块**。文档仍会被整理成章节、子章节、页码范围这样的自然单元。这样做的直接好处是：一段话属于哪一节、前后跟哪几页相连、它是不是某个附录或表格的一部分，都还保留着。

### 把目录树放进模型可推理的上下文里

官方把这类索引叫作 `in-context index`。索引本身是一份模型能直接看到、能顺着走的树结构，不是藏在外部数据库里的黑盒。模型拿到问题以后，可以浏览这棵树，判断"财务稳定性""附录 G""统计表"这些节点里谁才是更合适的入口，再决定要不要继续往下钻。

### 检索过程跟对话上下文一起变化

PageIndex 把 `Context-Aware Retrieval` 也列成核心特性。它会结合对话历史继续追问同一份文档，不把每轮问题都当成孤立请求。前一轮问了资产，后一轮问负债，模型就能沿着相近章节继续走，不用重新在整份文档里做一次盲搜。

## 树状索引长什么样

官方真正公开描述的索引结构是**树**，不是抽象口号。仓库、Framework 文章和 `sdk/tree` 文档合起来，可以把它还原成一套很具体的层级。

![PageIndex 的 Vectorless RAG 流程图](https://gastigado.cnies.org/d/public/vectorless-rag-workflow.png)

### 根节点到子节点：按文档层级展开

Framework 文章给出的 JSON 结构里，每个节点至少会有几类信息：

* `node_id`：节点唯一标识；
* `title` 或 `name`：章节名；
* `summary` 或 `description`：这一节讲什么；
* `start_index`、`end_index` 或 `page_index`：覆盖到哪些页；
* `sub_nodes` / `nodes`：下一级子节点。

文档处理接口的返回示例也能看到同样的层级：比如 `Financial Stability` 是一个父节点，下面再挂 `Monitoring Financial Vulnerabilities`、`Domestic and International Cooperation and Coordination` 这样的子节点。也就是说，PageIndex 里的"索引"不是单纯的目录标题列表，而是**标题、页码、摘要和父子关系组成的一棵树**。

### 节点背后还能回到原始内容

Framework 文章专门写了 `node_id -> node_content` 这种映射。意思是，目录树里的节点不是只给模型看名字，后面还能回到真实页内容、文本、图片或表格。`sdk/tree` 里公开的是 `get_tree()`，仓库里的 agentic demo 也说明，本地 Agent 常用的三个工具是：

* `get_document()`：看文档状态、页数、名称；
* `get_document_structure()`：拿整棵树，判断去哪找；
* `get_page_content()`：只拉紧凑页码范围，不整本抓回。

这一层让目录树真正能用起来。模型不用一次把整份 PDF 塞进上下文，可以定位，再按需拿内容。

### 文内引用能顺着树继续追

PageIndex 一直把"文内引用"当成和向量 RAG 拉开差距的地方。Framework 文章举的例子是：正文说"表 5.3 汇总了……更详细信息见附录 G"，真正答案却在附录表格里。树状索引把正文、附录、表格都放在一个可导航结构里，模型看到引用后，就可以把"附录 G"当成下一跳目标，而不是困在当前段落附近做相似匹配。

## 树怎么参与问答

PageIndex 的 `reasoning-based retrieval` 在官方资料里写得很具体，基本就是一个循环：

1. 读目录树；
2. 选一个最可能相关的节点；
3. 拉出这一节的真实内容；
4. 判断信息够不够；
5. 不够就回到树上换节点，够了再作答。

这个检索流程的关键，在于**它允许模型分步找资料**。

### 第一步：判断入口层级

用户问题进来后，模型可以看树的高层节点。比如问题明显跟监管合作有关，它就优先扫 `Financial Stability` 下面的相关分支；如果正文里又出现"见附录"提示，它就再切去附录节点。这里靠结构判断，不靠表面上最像的字词。

### 第二步：按紧范围取内容

agentic demo 把这条规则写得很明确：拿结构，再取 `5-7` 这样紧凑的页码范围，避免直接抓整本。这样做既节省上下文，也让模型每一步都知道自己为什么要看这几页。

### 第三步：边看边决定要不要继续找

向量召回常常是一轮给出 top-k 段落；PageIndex 则允许模型翻这一节，证据不够就继续换下一节。这就是官方反复说的 `iterative reasoning process`。它让检索从一次性命中，变成了可回退、可追索的过程。

### 第四步：答案可以附来源和中间轨迹

可追踪性是 PageIndex 另一条主线。Chat API 里 `enable_citations=True` 时，回答可以带行内引用；格式示例是 `<doc=file.pdf;page=1>`。如果把 `stream=True` 和 `stream_metadata=True` 一起打开，还能看到 `mcp_tool_use_start`、`mcp_tool_result_start` 这种中间事件。也就是说，回答不是只给结论，还能把"刚才查了哪份文档、什么时候取了相关内容"露出来。

这也是它和传统黑盒召回差异很大的地方：你不只能看到结果，还能大致看到它沿树搜索的动作。

## 使用步骤

如果只按官方公开文档走一遍，比较顺手的使用顺序就是下面这四步。

### 1. 准备文档

当前 `sdk/tree` 文档写得很清楚：**Document Processing 目前只接受 PDF**。所以最稳的输入仍然是结构明确、页码可追踪的 PDF。仓库也提到一件事：如果是复杂 PDF，云服务的 OCR 和树构建效果通常会比本地简单解析更完整。

### 2. 建立索引

提交文档：

```python
result = pi_client.submit_document("./2023-annual-report.pdf")
doc_id = result["doc_id"]
```

轮询状态或直接看元数据：

```python
status = pi_client.get_document(doc_id)["status"]
if status == "completed":
    print("Document processing completed")
```

需要看树结构时，用：

```python
tree_result = pi_client.get_tree(doc_id)
```

这一步结束后，你手里会有一个 `doc_id`，以及一棵已经处理好的目录树。

### 3. 提问

如果你想直接用官方聊天接口，可以把问题发给 Chat API：

```python
response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "What are the key findings in this document?"}],
    doc_id=doc_id
)
```

如果你已经有自己的 LLM / Agent，则走 MCP。官方给的 MCP 配置就是一个 HTTP MCP server：

```json
{
  "mcpServers": {
    "pageindex": {
      "type": "http",
      "url": "https://api.pageindex.ai/mcp",
      "headers": {
        "Authorization": "Bearer your_api_key"
      }
    }
  }
}
```

接进 Claude Agent SDK、OpenAI Agents SDK、LangChain、Vercel AI SDK 一类客户端后，PageIndex 就成了文档检索工具层，模型自己决定何时调用它。

### 4. 查看来源

如果你只想要结论，普通 `chat_completions()` 就够了；如果你想把来源一起带出来，可以打开：

```python
enable_citations=True
```

这样回答里会直接带页码引用。再往前一步，如果需要观察它的检索过程，可以加：

```python
stream=True,
stream_metadata=True
```

这时你能看到工具调用开始、结果返回等中间事件。对需要审计答案、调试 Agent 检索链路的人来说，这一层很有用。

## 使用场景

PageIndex 最适合的是**关系要顺着文档结构慢慢追出来**的材料：财报、法规、技术白皮书、研究报告、带附录和表格的正式文件，都属于它的强项。因为这些文档的答案经常不在单个相似段落里，而在"正文 + 附录 + 引用 + 上下文"这条链上。

## 和第 19 篇怎么配合

第 19 篇讲的是，把文本拆成实体、关系和三元组，最后得到一张可以沿边追踪的知识图谱；重点在**把文档里的关系网络显式抽出来**。PageIndex 这一条路则是尽量保留原文结构、页码和章节层级，让模型沿着树一步步查证。两篇文章看的不是同一层问题。

如果你的问题更偏"某个实体跟谁有关系、有哪些因果链、图谱里能不能继续扩展"，第 19 篇那条路更直接；如果你的问题更偏"答案藏在正文哪一节、附录哪一页、这句引用到底指向哪里"，PageIndex 这种 tree-based reasoning RAG 会更贴近原文阅读过程。

---

---
url: https://ain.hmgf.hxcn.space/ai/llm-knowledge-graph-202605.md
description: >-
  从 ai-knowledge-graph 的项目说明、配置和公开示例出发，说明它怎样把非结构化文档拆成三元组，做成交互式知识图谱，并和向量 RAG
  区分开。同时介绍 Understand Anything 如何把代码库变成可交互的架构知识图谱。
---

# 文档知识图谱

把非结构化文档自动变成可视化、可交互的知识图谱，这件事听上去很像"再做一个知识库"。真落到长文档、报告、历史材料或技术说明书上，问题会很快变具体：段落里的人名、机构、事件、因果链和前后影响，怎样从整块文本里拆出来；拆出来以后，怎样让人顺着关系追；再往后一步，怎样区分"这是一段语义相似的文本"与"这两个实体之间真的存在关系"。

`ai-knowledge-graph` 这个项目做的正是后一类事。它抽实体、抽关系、生成主谓宾三元组，再把这些关系做成图。最后拿到的是一张可以点、可以筛、可以沿着边追踪的图，而不是若干段相似文本列表。

## 项目背景与目标

仓库作者是 Robert McDermott。项目首页对它的定义很直接：输入一份非结构化文本，用任意 OpenAI-compatible LLM 抽取 Subject-Predicate-Object triplets，再把关系可视化成交互式知识图谱。

项目首页把目标概括成五件事：

* 大文档做分块；
* 每块文本抽实体和关系；
* 把同名异写的实体尽量并到一起；
* 给原本断开的图补一些推断关系；
* 输出交互式 HTML 图谱。

它的定位也很清楚：这是一个从文本到图谱的生成器。你给它一份文本文件，它回你一个 HTML 图谱和一份 JSON 数据。

## 运行方式和依赖

项目的 Quick Start 很短，适合跑通一遍。

### 环境要求

从项目说明、`pyproject.toml` 和 `requirements.txt` 可以核对到：

* 项目说明写的是 Python `3.11+`；
* `pyproject.toml` 里要求的是 `>=3.12`；
* 依赖里核心包包括 `networkx`、`pyvis`、`pyvis-network`、`requests`、`python-louvain`、`tomli`。

如果按仓库当前打包配置走，保守做法是直接用 Python 3.12。

### 安装方式

项目给了三种安装方式。

用 `pip`：

```bash
git clone https://github.com/robert-mcdermott/ai-knowledge-graph.git
cd ai-knowledge-graph
pip install -r requirements.txt
```

用 `uv`：

```bash
git clone https://github.com/robert-mcdermott/ai-knowledge-graph.git
cd ai-knowledge-graph
uv sync
```

按模块安装：

```bash
pip install --upgrade -e .
```

对应的 CLI 入口在 `pyproject.toml` 里也写了：

```toml
[project.scripts]
generate-graph = "src.knowledge_graph.main:main"
```

### 基本运行命令

命令行入口有三种常见跑法：

```bash
python generate-graph.py --input your_text_file.txt --output knowledge_graph.html
```

```bash
uv run generate-graph.py --input your_text_file.txt --output knowledge_graph.html
```

```bash
generate-graph --input your_text_file.txt --output knowledge_graph.html
```

命令行参数也比较直接：

* `--input`：输入文本文件
* `--output`：输出 HTML 文件
* `--config`：配置文件路径
* `--debug`：打印原始 LLM 响应和提取 JSON
* `--no-standardize`：关闭实体标准化
* `--no-inference`：关闭关系推断
* `--test`：用测试数据生成示例图

## Medium 文章里的流程

除了仓库说明页，作者还写了一篇 Medium 文章：`From Unstructured Text to Interactive Knowledge Graphs Using LLMs`。这篇文章当前直接抓取会遇到 Cloudflare 挑战，正文没有完整拿到；不过标题、摘要和公开搜索结果里的流程说明，和仓库说明页能互相对上。

当前能核对到的文章主线是五步：

1. 文本分块
2. 主谓宾三元组抽取
3. 实体标准化
4. 关系推断
5. 交互式可视化

这一点和项目说明里的 `How It Works` 基本一致，所以正文可以按这个骨架往下讲。不能确定的细节我这里不扩写。

## 从文本到图：核心步骤怎么走

### 1. 文本分析：切块与逐块处理

这一步很像常见 RAG 预处理，但目标不同。这里切块主要是为了让 LLM 能在上下文窗口内稳定抽关系。

默认配置是：

```toml
[chunking]
chunk_size = 100
overlap = 20
```

也就是按词数切块，每块 100 个词，前后重叠 20 个词。这样做有两个实际好处：

* 长文档不会一次塞爆上下文；
* 跨段落关系在重叠区还有机会被保留下来。

### 2. 实体抽取：识别图谱节点

项目把第一阶段叫作 `INITIAL TRIPLE EXTRACTION`，但它背后的第一步其实是识别实体。人名、机构、技术、地点、时间节点、事件名，都会先以主语或宾语的形式进入三元组。

这里没有再单独拆一个实体表或中间界面，而是把实体抽取和三元组抽取绑在一起：LLM 读每个文本块，直接返回关系结构，实体随之落到图里。

### 3. 关系抽取：决定点和点之间怎么连

只有实体还不够，决定图谱可读性的还是"边"。仓库示例里，边可以是：

* `pioneered`
* `enabled`
* `impacts`
* `invented`
* `transformed`

这类关系一旦抽出来，图谱就会比全文检索更顺手。你不必从几十段文本里自己拼"谁影响了谁"，图里已经把连线画出来了。

### 4. 三元组生成：把文本改写成图谱能处理的结构

这个项目的核心输出单位是 Subject-Predicate-Object triplet，也就是主语、谓语、宾语。

比如一段原文写"James Watt refined the steam engine"，系统最后要落成一条结构化关系，后续才能：

* 作为图边展示；
* 做实体合并；
* 做后续关系推断；
* 导出成 JSON。

示例运行结果也给了一个量级感：示例文本 `industrial-revolution.txt` 初始抽出了 216 条 triples，后续经过标准化和推断，最终图谱到 564 条 triples。

### 5. 实体标准化：把同一东西的不同写法并起来

这一步很关键，很多文本抽取项目卡就卡在这里。

项目说明举的例子是：同一实体可能在不同 chunk 里写成不同形式，比如：

* `AI`
* `artificial intelligence`
* `AI system`

如果不合并，图会膨胀得很快，看起来节点很多，实际信息却散了。这个仓库把标准化做成了一个单独阶段，并且允许：

* 只做基础文本归一化；
* 开启 `standardization.use_llm_for_entities = true`，让 LLM 参与实体对齐。

默认配置里这个开关是开的：

```toml
[standardization]
enabled = true
use_llm_for_entities = true
```

### 6. 关系推断：给断开的局部图补连接

第三阶段叫作 `RELATIONSHIP INFERENCE`。这里做的是基于现有图补推断边。

当前支持两类思路：

* 规则侧：传递关系、词面相似等；
* LLM 侧：让模型看断开的社区代表实体，尝试补合理关系。

相关配置是：

```toml
[inference]
enabled = true
use_llm_for_inference = true
apply_transitive = true
```

这一步的目标很现实：减少图碎片。文档里本来没有直接写明的关系，有时可以通过上下游实体和社区结构补出来。不过这也是最需要人工复核的一步，因为一旦推断过头，图会变得更花，但不一定更准。

## 交互式图谱到底怎么帮助读文档

仓库自带的示例图很直观：

![ai-knowledge-graph 示例图](https://gastigado.cnies.org/d/public/ai-knowledge-graph-example.png)

项目输出的是 HTML 交互图。demo 页和导出的 HTML 里能看到几类交互功能。

### 探索：从单个节点向外扩展

如果你在读一份技术材料，常见的问题往往是"这个概念还跟谁连着"。图谱很适合从一个节点向外扩散看。

比如你点某个人物、某项技术或某个事件，可以马上看到它直接连着哪些关系、落在哪个社区里。这对历史材料、产业研究、组织关系文档尤其有用。

### 筛选：按节点、边和属性收窄范围

demo 页里能看到 `Show Filters`、`Nodes`、`Edges`、`Select a property`、`Select value(s)` 这些控件。你可以按条件缩小范围，不用整张图一起看。

这一步的阅读价值很高：

* 关系太多时，只看某类边；
* 节点太密时，只看某些实体；
* 想看某个社区内部结构时，把其他内容先滤掉。

### 追踪：沿关系边回溯链路

向量检索更擅长"给我几段可能相关的文本"，知识图谱更擅长"帮我沿着关系走几步"。

比如你看到一个结论节点，想知道它是怎样连到上游技术、人物、组织或结果的，这时追边就比回搜相似段落更顺手。对读复杂文档的人来说，这个差别很大。

### 可视化细节：社区、边类型、节点权重

项目说明里还能看到几类视觉编码：

* 节点颜色对应社区；
* 节点大小和中心性相关；
* 原始抽取边用实线，推断边用虚线；
* 支持浅色 / 深色模式。

这些细节直接决定图谱能不能读。没有社区颜色和边类型区分，整张图很容易变成一团线。

## 知识图谱式知识库和向量 RAG 的差异

这部分需要单独讲清楚，因为它直接关系到你该不该用这类项目。

### 向量 RAG 解决的是"找相似内容"

向量 RAG 的基本动作是：

* 把文档切块；
* 转成 embedding；
* 用户提问时按相似度召回若干块；
* 再把块送给模型回答。

它的优点是搭得快，问答体验直观，适合"我有个问题，帮我从资料里找答案"。

### 知识图谱解决的是"关系怎么组织"

知识图谱关注的是另一层结构：

* 哪些实体出现了；
* 它们之间是什么关系；
* 哪些关系是显式写出来的；
* 哪些关系是后续推断补上的；
* 一条关系链怎样从 A 走到 B。

你把它当成阅读辅助会更准确。它适合：

* 关系密集的资料；
* 需要追人物、组织、技术、事件之间联系的材料；
* 需要可视化探索、而不只做问答的场景。

### 两者可以配合使用

很多时候两者可以一起用：

* 图谱负责把结构拉出来；
* 向量检索负责回到原文段落；
* 最终回答再由模型整合。

但如果只看这个仓库当前能力，它更偏"文本到图谱"的前半段，距离完整的 RAG 问答系统还有一段。

## 跑一遍仓库自带示例

仓库已经给了一份示例文本：`data/industrial-revolution.txt`。直接照命令跑就行。

### 第一步：配置 LLM 端点

`config.toml` 示例是这样的：

```toml
[llm]
model = "gemma3"
api_key = "sk-1234"
base_url = "http://localhost:11434/v1/chat/completions"
max_tokens = 8192
temperature = 0.8
```

项目说明也强调，这个项目支持任意 OpenAI-compatible endpoint，所以 Ollama、LM Studio、OpenAI、vLLM、LiteLLM 都可以接，只要接口兼容。

### 第二步：执行命令

```bash
generate-graph --input data/industrial-revolution.txt --output industrial-revolution-kg.html
```

### 第三步：看控制台输出

示例输出能帮你判断每个阶段有没有正常运行：

* Phase 1 抽出了多少 triples；
* Phase 2 标准化后实体数怎么变化；
* Phase 3 推断后新增了多少关系；
* 最终有多少 nodes、edges、communities。

如果你在自己的文档上跑，最该盯的也是这几个数字。它们能快速告诉你：

* 抽取得太少，可能 chunk 或 prompt 不合适；
* 实体数量过多，说明标准化不够；
* 推断边暴涨，说明 inference 可能放得太开。

## 使用场景和回访点

这类知识库更适合关系密集的资料，例如历史材料、人物网络、技术演进、制度说明、产业链说明文档。它的价值主要在结构可见、关系可追。

但抽取结果不能直接当事实库。至少有三类地方需要人工回看：

* 实体是否被拆散或误合并；
* 关系谓词是否过于随意；
* 推断边是否把"可能相关"写成了"确定相关"。

如果你的目标是问答优先、上线快、文档关系不复杂，向量 RAG 往往更省事；如果更看重关系网络本身能不能被看清，这类图谱才值得上。

## 代码库知识图谱：Understand Anything

前面讲的 `ai-knowledge-graph` 面向的是非结构化文档——把报告、历史材料、技术说明书里的实体和关系抽出来。`Understand-Anything` 做的是另一件事：**把整个代码库变成可交互的知识图谱**。

你刚加入一个新团队，代码库有 20 万行代码，从哪里开始？`Understand-Anything` 用多 Agent 流水线扫描项目，提取每个文件、函数、类和依赖关系，生成一张知识图谱，再给你一个可交互的 Dashboard 来探索。

### 它和文档知识图谱的区别

文档知识图谱关注的是"文本里提到了哪些实体、它们之间是什么关系"。代码库知识图谱关注的是另一层结构：

* 每个文件、函数、类都是节点；
* 导入、调用、继承、依赖都是边；
* 架构层（API、Service、Data、UI、Utility）自动分组；
* 业务域、流程、步骤映射到代码结构。

它不只是"找相似内容"，而是"看清每一块代码怎么拼在一起"。

### Tree-sitter + LLM 混合架构

`Understand-Anything` 把静态分析和 LLM 各自擅长的事拆开了：

**Tree-sitter（确定性）**——把源码解析成具体语法树，提取结构性事实：导入、导出、函数/类定义、调用点、继承关系。同样的输入永远产生同样的输出。还支持基于指纹的变更检测，用于增量更新。

**LLM（语义）**——读解析后的结构和原始源码，产出解析器做不到的东西：英文摘要、标签、架构层分配、业务域映射、引导式学习路线、编程模式标注。

这个拆法让图谱在结构面可复现（同样的代码总是产生同样的边），在语义面捕捉意图（一个文件是"干什么用的"，不只是它导入了什么）。

### 多 Agent 流水线

`/understand` 命令编排 5 个专门 Agent，`/understand-domain` 再加 1 个：

| Agent | 角色 |
|-------|------|
| `project-scanner` | 发现文件、检测语言和框架 |
| `file-analyzer` | 提取函数、类、导入；生成图节点和边 |
| `architecture-analyzer` | 识别架构层 |
| `tour-builder` | 生成引导式学习路线 |
| `graph-reviewer` | 验证图的完整性和引用完整性 |
| `domain-analyzer` | 提取业务域、流程和步骤（`/understand-domain`） |

文件分析器并行运行（最多 5 个并发，每批 20-30 个文件）。支持增量更新——只重新分析自上次运行以来变更的文件。

### 交互式 Dashboard

生成的图谱是一个可交互的 Web Dashboard：

* **探索**：每个节点可点击、可搜索、可展开，选中节点可以看到英文摘要、关系和引导式讲解
* **业务逻辑**：切换到域视图，看代码怎么映射到真实业务流程——域、流程和步骤以水平图布局
* **引导式学习**：自动生成的架构讲解，按依赖顺序排列，帮你在正确顺序里学代码库
* **模糊搜索和语义搜索**：按名称或按含义搜索，"哪些部分处理认证？"这种问题也能得到结果
* **影响分析**：提交前看你的变更会影响系统的哪些部分
* **角色自适应**：Dashboard 根据你是初级开发者、PM 还是高级用户调整详细程度

### 安装方式

Claude Code 原生安装（推荐）：

```bash
/plugin marketplace add Lum1104/Understand-Anything
/plugin install understand-anything
```

一行安装（支持 Codex、OpenCode、Gemini CLI、VS Code Copilot 等 15+ 平台）：

```bash
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash

# Windows (PowerShell)
iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex
```

### 使用方式

```bash
/understand                          # 分析整个代码库
/understand --language zh            # 生成中文内容
/understand src/frontend             # 只分析子目录
/understand-dashboard                # 打开交互式 Dashboard
/understand-chat How does the payment flow work?  # 提问
/understand-diff                     # 分析当前变更的影响
/understand-explain src/auth/login.ts  # 深入某个文件
/understand-onboard                  # 生成新人入职指南
/understand-domain                   # 提取业务域知识
```

### 图谱可以提交到仓库

图谱就是 JSON——提交一次，队友就能跳过流水线。适合入职、PR 审查和文档即代码的工作流。

```bash
# 推荐提交的内容：.understand-anything/ 下除 intermediate/ 和 diff-overlay.json 外的所有文件
# 大图谱（10 MB+）用 git-lfs 追踪
git lfs install
git lfs track ".understand-anything/*.json"
```

### 它在知识图谱工具里的位置

和 `ai-knowledge-graph` 比，`Understand-Anything` 不是做文档实体抽取，而是做代码库结构分析；前者输出的是文本三元组图谱，后者输出的是文件/函数/类级别的架构图谱。两者解决的是不同层面的"理解"问题：

* `ai-knowledge-graph`：给一份报告，抽出"谁影响了谁""哪个事件导致了什么结果"
* `Understand-Anything`：给一个代码库，抽出"哪些模块依赖哪些""认证流程经过了哪些函数""新人应该按什么顺序学这个项目"

当前 star 约 37.7k，支持 Claude Code、Codex、Cursor、Copilot、Gemini CLI、OpenCode 等 15+ 平台。

---

---
url: https://ain.hmgf.hxcn.space/ai/agent-principles-architecture-202606.md
---

# 你不知道的 Agent：原理、架构与工程实践

![](https://gastigado.cnies.org/d/public/image1.png)

## 0. 太长不读

在写完「你不知道的 Claude Code：架构、治理与工程实践」之后，发现自己对 Agent 底层的理解还不够深入，加上团队在 Agent 方向已经有不少业务落地经验，一直缺少一份系统梳理，所以我又把资料、开源实现和自己写的代码一起过了一遍，最后整理成了这篇文章。

这篇文章主要讲 Agent 架构里几块最影响工程效果的内容，包括控制流、上下文工程、工具设计、记忆、多 Agent 组织、评测、追踪和安全，最后再用 OpenClaw 的实现把这些设计原则串起来看一遍。

整理下来，有几处判断和我原来想的不太一样，更贵的模型带来的提升，很多时候没有想象中那么大，反而 Harness 和验证测试质量对成功率的影响更大，调试 Agent 行为时，也应优先检查工具定义，因为多数工具选择错误都出在描述不准确，另外，评测系统本身的问题，很多时候比 Agent 出问题更难发现，如果一直在 Agent 代码上反复调，效果未必明显，读完这篇，这几个问题应该能有些答案。

## 1. Agent Loop 的基本运转方式

Agent Loop 的核心实现逻辑抽象后其实不到 20 行代码：

![](https://gastigado.cnies.org/d/public/image2.jpg)

对应的控制流如下，感知 -> 决策 -> 行动 -> 反馈四个阶段不断循环，直到模型返回纯文本为止：

看过不少 Agent 实现和官方 SDK，结构都差不多，循环本身相当稳定，从最小实现一路扩展到支持子 Agent、上下文压缩和 Skills 加载，主循环基本没有变化，新增能力通常都是叠加在循环外部，而不是改动循环内部。

新能力基本只通过三种方式接入：扩展工具集和 handler、调整系统提示结构、把状态外化到文件或数据库，不应该让循环体本身变成一个巨大的状态机，模型负责推理，外部系统负责状态和边界，一旦这个分工确定下来，核心循环逻辑就很少需要频繁调整了

### Workflow 和 Agent 有什么区别

Anthropic 对这两类系统有一个直接区分：执行路径由代码预先写死的是 Workflow，由 LLM 动态决定下一步的是 Agent，核心区别在于控制权掌握在谁手里，现实中很多标着 Agent 的产品，深入看其实更接近 Workflow，不过两者本身并无高下之分，真正重要的是给任务找到更适合的解决方案。

![](https://gastigado.cnies.org/d/public/image3.jpg)

放在一张图里看，会更直观：

### 五种常见控制模式

大多数 AI 系统拆开看，其实都是这五种模式的组合。很多场景并不需要完整的 Agent 自主权，把其中几种模式搭起来就够了，关键还是看任务本身适合哪一种设计。

1. 提示链 Prompt Chaining：任务拆成顺序步骤，每步 LLM 处理上一步的输出，中间可加代码检查点，适合生成后翻译、先写大纲再写正文这类线性流程。
2. 路由 Routing：对输入分类，定向到对应的专用处理流程，简单问题走轻量模型，复杂问题走强模型，技术咨询和账单查询走不同逻辑。
3. 并行 Parallelization：两种变体：分段法把任务拆成独立子任务并发跑，投票法把同一任务跑多次取共识，适合高风险决策或需要多视角的场景。
4. 编排器-工作者 Orchestrator-Workers：中央 LLM 动态分解任务，委派给工作者 LLM，综合结果。nanobot 的 spawn 工具和 learn-claude-code 的子 Agent 模式都是这个原型。
5. 评估器-优化器 Evaluator-Optimizer：生成器产出，评估器给反馈，循环直到达标，适合翻译、创意写作这类质量标准难以用代码精确定义的任务。

上面这些模式解决的是控制流怎么搭，下面再看另一个更工程的问题，系统为什么能跑稳。

![](https://gastigado.cnies.org/d/public/image4.jpg)

## 2. 为什么 Harness 比模型更关键

Harness 是指围绕 Agent 构建的测试、验证与约束基础设施，这里的 Harness 至少包括四个部分：验收基线、执行边界、反馈信号和回退手段。

模型虽然重要，但决定系统能不能稳定运行的，往往是这些外围工程条件，这个判断在代码编写这类高可验证任务上最成立，但在开放式研究、多轮协商这类弱验证任务里，模型上限本身仍然更关键。

### OpenAI 的 Agent 优先开发实践

3 个工程师 5 个月写了百万行代码，将近 1500 个 PR，是传统开发速度的 10 倍。这个速度背后不是模型有多强，而是几个工程决策做对了：

1. Agent 看不到的内容等于不存在：知识必须存在于代码库本身，外部文档对运行中的 Agent 不可见，AGENTS.md 只保留约 100 行作为索引，细节拆到各 docs 目录按需引用。
2. 约束编码化而非文档化：写在文档里的规范很容易被忽略，编码进 Linter、类型系统或 CI 规则里的约束才具备可执行性，架构分层靠自定义 Linter 机械强制，不靠人工 Review。
3. Agent 端到端自主完成任务：从验证当前状态、复现 Bug、实现修复、驱动应用验证，到开 PR、处理 Review 反馈、自主合并，全链路不需要人介入，查日志、查指标、查追踪都由 Agent 主动完成。
4. 最小化合并阻力：测试偶发失败用重跑处理而不是阻塞进度，在高吞吐环境下等待人工审查的成本往往高于修复小错误的成本。写代码的纪律没有消失，只是从人工 Review 变成了机器执行的约束，一次写进去，到处生效。

![](https://gastigado.cnies.org/d/public/image5.jpg)

APP 把日志、指标、追踪三路数据经由 Vector 分发到 Victoria 存储层，对应 LogQL、PromQL、TraceQL 三个查询接口，Codex 通过这三个接口查询、关联、推理，完成改动后重启应用、重跑工作负载，结果再打回给 Codex，UI Journey 也作为输入接入。整套可观测性栈按任务临时创建、任务完成即销毁，Agent 不需要等人告知错误，直接查询系统状态验证修改是否生效。

### Harness 的关键结论是什么

图里用任务清晰度和验证自动化程度把任务分成四种状态，右上角目标明确、结果可以自动验证，是最适合 Agent 发挥的区域，左上角任务清楚但验收还得人盯，吞吐量天花板是人的审查速度，右下角有自动化反馈但目标模糊，系统会高效地往错误方向跑，左下角两者都缺，Agent 基本起不到作用。

Harness 要做的就是把任务推进右上角，让对错有机器可以执行的判断标准，而不是靠人盯。

## 3. 上下文工程为什么决定稳定性

Transformer 的注意力复杂度是 O(n2)，上下文越长，关键信号越容易被噪声稀释，实践里最常见的失效模式是无关内容一旦占到上下文的大头，Agent 的决策质量就会明显下滑，这类现象通常被叫作 Context Rot，很多看起来像模型能力不足的问题，往往可以追溯到上下文组织不当。

### 上下文为什么要分层

问题通常不是窗口不够长，而是信息密度不对，偶尔用的东西每次都加载进来，稳定的规则和动态的状态混在一起，模型能看到的内容越来越多，但真正有用的部分越来越难被注意到。

![](https://gastigado.cnies.org/d/public/image6.jpg)

解决方式是按信息的使用频率和稳定性分层管理，每层只放自己该放的东西：

* 常驻层：身份定义、项目约定、绝对禁止项，每次会话都必须成立的内容，保持短、硬、可执行
* 按需加载：Skills 和领域知识，描述符常驻，完整内容触发时再注入，不用的不占位置
* 运行时注入：当前时间、渠道 ID、用户偏好等动态信息，每轮按需拼入
* 记忆层：跨会话经验写入 MEMORY.md，不直接进系统提示，需要时才读取
* 系统层：Hooks 或代码规则处理确定性逻辑，完全不进上下文

别把确定性逻辑放进上下文，凡是可以通过 Hooks、代码规则或工具约束表达的内容，都应交给外部系统处理，而不是让模型反复读取。

### 三种常见压缩策略

1. 滑动窗口：丢弃旧消息，成本极低，会丢早期上下文，适合简短对话
2. LLM 摘要：模型生成总结，成本中等，丢细节保留决策，适合长任务
3. 工具结果替换：占位符替换原始输出，成本极低，适合工具调用密集型

滑动窗口实现最简单，但会丢掉早期决策背景。LLM 摘要的进阶做法是 branch summarization，摘要时明确保留架构决策、未完成任务和关键约束。工具结果替换里，micro\_compact 每轮替换旧工具输出，auto\_compact 在上下文超阈值时自动触发。

### Prompt Caching 减少重复开销

LLM 推理时，Transformer attention 会为每个 token 计算 Key-Value 对，如果当前请求的输入前缀和之前某次请求完全一致，这部分 KV 就不需要重新计算，直接从缓存读取，这就是 Prompt Caching 的底层原理。命中的前提是精确前缀匹配，不是内容相似就能触发，任何一个 token 不同都会破坏匹配，所以缓存友好的设计核心是稳定性，系统提示、工具定义、长文档这类在多轮请求里基本不变的内容天然适合缓存，动态信息（当前时间、用户输入、工具调用结果）放在后面，不影响前缀的稳定性。

这和上下文分层设计直接相关。常驻层越稳定，前缀命中率越高，边际成本越低，所以「常驻层短而稳定」不只是为了节省 token，也在保护缓存命中。Skills 延迟加载的好处也在这里，按需注入的内容不破坏系统提示前缀，而是追加在稳定前缀之后，工具定义同样参与缓存计算，接了很多 MCP 工具的 Agent 如果工具集频繁变动，缓存命中就会不断失效。有一个反直觉的地方：稳定的大系统提示，比频繁变动的小提示实际成本更低，因为写入成本只付一次，后续每次调用读取的折扣可以达到 90%。

### 为什么 Skills 要按需加载

Skills 是上下文工程里非常有效的一种模式，核心思路是：系统提示只保留索引，完整知识按需加载。

![](https://gastigado.cnies.org/d/public/image7.jpg)

Skill 描述要足够短，避免常驻上下文持续涨 token，也要足够像路由条件而不是功能介绍，至少说明什么时候用、什么时候不要用、产出物是什么，最直接的写法是 Use when / Don't use when 再补几条反例，很多路由失败不是模型能力问题，而是边界写得不清楚。系统提示里也要把调用规则写明确：每次回复前先扫描 available\_skills，有明确匹配时再读取对应 SKILL.md，多个匹配时优先选最具体的那个，没有匹配就不读取，一次只加载一个。

图里的数据很直接：没有反例时准确率从基准 73% 掉到 53%，加上反例后升到 85%，响应时间还降了 18.1%。反例不是可选项，是 Skill 描述能不能起作用的关键。

Skills 不能等 Agent 想起来再用，要每轮都先扫描描述，但扫描成本要足够低，实际加载数量也要受控，如果 Skill 会触发外部 API 写操作，系统提示里应显式补充速率限制要求，尽量批量写入、避免逐条循环、遇到 429 主动等待。

Skill 描述符有两个写法陷阱值得单独说。第一个是字数：

路由准确率差距不大，但每个启用的 Skill 描述符都常驻上下文，Skill 一多，长描述的累积成本很可观。第二个是精度：描述太短（help with backend）等于任何后端工作都能触发，路由会乱。真正有效的描述符是路由条件，不是功能介绍，"何时该用我"比"我能做什么"重要得多。

数量上同样要控制：常驻系统提示的只放高频 Skill，低频的不要塞进默认列表，需要时再手动引入，极低频的直接用文档替代就够了，不必做成 Skill。几个典型反模式：正文几百行工作手册全塞进 Skill 正文而不是拆成 supporting files；一个 Skill 试图覆盖 review、deploy、debug、incident 五件事；有副作用的 Skill 没有显式限制调用时机。这三个问题都会让 Skill 路由失准，而且很难排查。

Skills 和 MCP 在上下文成本上的特征并不相同，很多 MCP 会把完整结果直接返回给模型，更容易迅速吃掉上下文预算，CLI + 单句描述的 Skill 更接近模型熟悉的调用方式，在大多数可过滤、可拼接的数据读取任务里也更简洁，当然 MCP 也有明确适用场景，例如 Playwright 这类需要维护状态的任务。

### 压缩最容易丢掉什么

压缩阶段最常见的问题，不是摘要不够短，而是保留顺序设错了，LLM 通常会优先删除那些看起来还可以重新获取的信息，早期的 tool output 通常最先被移除，但与之相关的架构决策、约束理由和失败路径也很容易一并丢失。最好在 CLAUDE.md 或等价文档里明确写出压缩时的保留优先级：

压缩时还有一条容易踩的坑：不要改动标识符，UUID、hash、IP、端口、URL、文件名这类值必须原样保留，一旦把 PR 编号或 commit hash 改错一位，后续工具调用就会直接失效。

### 文件系统为什么适合做上下文接口

Cursor 把这种方式叫 Dynamic Context Discovery，默认少给，只在需要时读取。文件系统天然适合做这个接口，工具调用经常返回大量 JSON，几次搜索就能堆出成千上万 token，不如直接写入文件，让 Agent 通过 grep、rg 或脚本按需读取，工具写文件，Agent 读文件，开发者也可以直接查看。

Cursor 在 MCP 工具上也验证过这个方向：他们把工具描述同步到文件夹，Agent 默认只看到工具名，需要时再查询具体定义，A/B 测试中，调用 MCP 工具的任务总 token 消耗减少了 46.9%。

同样的思路也适用于长任务压缩，压缩触发时，不直接丢弃历史，而是把聊天记录完整保留为文件，摘要里只引用文件路径，后续如果 Agent 发现摘要缺少细节，仍然可以回到历史文件里检索，这样压缩就变成了一种有损但可追溯的操作，而不是一次不可恢复的硬截断。

![](https://gastigado.cnies.org/d/public/image8.jpg)

## 4. 工具设计决定 Agent 能做什么

上下文决定模型能看到什么，工具决定模型能做什么。工具定义的质量比数量更关键，仅 5 个 MCP 服务器就可能带来约 55,000 tokens 的工具定义开销，相当于在 200K 上下文里还没开始对话就用掉了近三成，工具一旦过多，模型对单个工具的注意力也会被稀释。

工具问题多数不在数量不够，而在选不对、描述看不懂、返回一堆没用的、出了错 Agent 也不知道怎么改。

### 工具设计如何演进

工具设计大致经历了三个阶段，早期做法是直接把现有 API 封装成工具扔给模型，后来发现模型选错工具，问题不在模型能力，而在工具本身的设计视角就错了，原来是给工程师设计的，不是给 Agent 设计的。

第一代，API 封装：每个 API Endpoint 对应一个工具，粒度过细，Agent 往往需要协调多个工具才能完成一个目标。

第二代，ACI，即 Agent-Computer Interface：工具应对应 Agent 的目标，而不是底层 API 操作。不要分别暴露 create\_file、write\_content、set\_permissions，而是直接给一个 create\_script(path, content, executable)，一次搞定。

第三代，Advanced Tool Use：在工具设计之上，进一步优化工具的发现、调用和描述方式，主要包括三个方向：

* Tool Search，动态工具发现：别把全部工具定义一次性塞给模型。Agent 通过 search\_tools 按需发现工具定义，上下文保留率可达到 95%，Opus 4 的准确率也从 49% 提升到 74%。
* Programmatic Tool Calling，代码编排：别让中间数据一轮轮穿过模型，而是让模型用代码编排多个工具调用，中间结果在执行环境中流转，不进入 LLM 上下文，token 消耗可从约 150,000 降到约 2,000。
* Tool Use Examples，示例驱动：每个工具附带 1-5 个真实调用示例。JSON Schema 只能描述参数类型，但无法表达调用方式，加入示例后，工具调用准确率可从 72% 提升到 90%。

### ACI 工具设计有哪些原则

类比 HCI 对人的影响，工具设计对 Agent 的影响一样直接，不能只看「工具能不能调用」，还要看「调用错了之后能不能自己修回来」。

三个原则放在一起看更清楚，差的做法参数模糊、错误不可修正、定义实现分离：

![](https://gastigado.cnies.org/d/public/image9.jpg)

好的做法用 betaZodTool 把定义和实现绑在一起，参数描述直接约束格式，错误结构化给出修正建议：

左边是差工具设计，工具只说自己能做什么，不说明什么时候该用、什么时候不该用，结果是 Agent 容易选错工具、填错参数，报错后不断重试绕圈，右边是符合 ACI 原则的工具设计，边界清楚、结构化错误给出修正建议，Agent 更容易一次选对，失败后也能快速修正。

调试 Agent 时应先检查工具定义，大多数工具选择错误的原因出在描述不准确，不在模型能力，工具数量也要克制，能用 Shell 处理的、只需静态知识的、更适合 Skill 的，都不需要新增工具。

Zod schema 可以同时生成 JSON Schema 和 TypeScript 类型，把参数验证和文档约束合并在一处，工具调用循环也由 SDK 自动处理。

### 为什么工具消息也要隔离

框架运行过程中会产生一些内部事件：压缩发生了、通知推送了、某个工具调用被跳过了，这些事件需要记在会话历史里，但不应该直接进 LLM，否则模型会看到一堆它不理解的字段，白白消耗 token。

解决方式是在框架层分两种消息类型：给应用层用的 AgentMessage 可以携带任意自定义字段，真正发给 LLM 的 Message 只保留 user、assistant、tool\_result 三种标准类型，调用前过滤一遍，会话历史保留完整框架状态，LLM 只收它需要的部分。

## 5. 记忆系统如何设计

Agent 不具备原生的时间连续性，会话结束后，上下文随之清空，下一次启动时也不会自动保留此前状态，要让系统具备跨会话的一致性，记忆层得单独设计，对 Agent 来说它是一层基础设施，不是可以事后补上的能力。

### 四种记忆分别存在哪里

这里不是按存储介质来分，而是按 Agent 实际要解决的问题来分：

* 上下文窗口，工作记忆：当前任务所需的最小信息，token 有限，得主动管理
* Skills，程序性记忆：怎么做某件事，操作流程、领域规范，按需加载不默认常驻
* JSONL 会话历史，情景记忆：发生了什么，磁盘持久化，支持跨会话检索
* MEMORY.md，语义记忆：Agent 主动写入认为重要的事实，每次启动时注入系统提示

左侧是 Agent 运行时，只有上下文窗口存在于 messages\[] 中，会随着会话结束一起清空，右侧是磁盘上的持久层，Skills 文件按需加载，JSONL 会话历史保留完整过程并支持检索，MEMORY.md 则沉淀 Agent 主动写入的稳定事实，并在后续会话中持续注入。

### MEMORY.md 和 Skills 如何协作

实际系统实现方式不同，但核心都在解决两件事：重要事实要留下来，注入模型的内容又不能失控。

ChatGPT 四层记忆

拿它当一个产品实现来看，它没有使用向量数据库，也没有引入 RAG 检索增强生成，整体结构比很多人的预期更简洁：

1. Session Metadata：设备、地点、使用模式，不持久化
2. User Memory：约 33 条关键偏好事实，持久化，每次注入
3. Conversation Summary：约 15 个最近对话的轻量摘要，持久化
4. Current Session：当前对话滑动窗口，不持久化

OpenClaw 混合检索

1. memory/YYYY-MM-DD.md，追加写日志，保留原始细节
2. MEMORY.md，精选事实，Agent 主动维护
3. memory\_search，70% 向量相似度 + 30% 关键词权重的混合检索

这个设计的好处是可读、可改、可检索，Markdown 文件可以直接查看和修订，搜索时按相关性拉取需要的内容，而不是把全部记忆一次性塞进上下文，对大多数 Agent 来说，记忆库规模并不需要一开始就引入向量存储，结构化 Markdown 加关键词搜索已经具备足够好的可调试性、可维护性和成本表现，只有当规模超过几千条、并且确实需要语义相似度检索时，再考虑引入向量检索会更合适。

### 记忆整合如何触发并回退

有了记忆分层之后，下一步要处理的就不是「要不要存」，而是「什么时候整合，以及整合失败怎么办」。

![](https://gastigado.cnies.org/d/public/image10.jpg)

这张图强调的不是「把旧消息删掉」，而是把它们从活跃上下文中安全移出，左边是持续增长的对话消息流，中间用 tokenUsage / maxTokens >= 0.5 作为触发阈值，达到阈值后，成功路径会先对待整合消息做 llmSummarize(toConsolidate)，再把摘要追加到 MEMORY.md，最后只更新 lastConsolidatedIndex，失败路径则把原始消息写入 archive/，保留完整历史，避免整合失败时丢失上下文。

最关键的不是摘要写得多漂亮，而是流程本身必须可回退，系统只移动指针，不删除原始消息，即使整合失败，也还能回到原始存档继续工作。

## 6. 如何逐步放开 Agent 自主度

这里说的自主度，不是少几次人工确认，而是让 Agent 能在更长时间跨度内稳定推进任务，前提也不是直接放权，而是先补齐三类基础设施：跨 session 续跑、单个 session 内的进度约束，以及慢速 I/O 的后台接入。

### 长任务如何跨 session 继续

长任务最常见的失败，不是单步报错，而是 session 结束时任务还没做完，即使启用 compaction，也挡不住两类问题：一是在单个 session 里试图做完整个应用，结果上下文先耗尽，二是只做完一部分，下一轮又无法准确恢复现场，过早判断完成。

更稳定的做法，是把长任务拆成 Initializer Agent 和 Coding Agent 两个角色协作，这种模式最适合代码生成、应用搭建、重构迁移这类单个 session 做不完、但又能拆成一批可验证子任务的工作。

Initializer Agent 只在第一轮运行一次，负责生成 feature-list.json、init.sh、初始 git commit 和 claude-progress.txt，先把任务变成可持久化的外部状态，后面的多个 session 由 Coding Agent 循环执行，每次从 claude-progress.txt 和 git log 恢复现场，定位当前任务，实现一个功能，跑测试，更新 passes 字段，提交代码后退出，这样即使中途崩溃，也能直接从文件系统里的状态继续，而不是从头再来。

进度要放在文件里，不要放在上下文里，功能清单用 JSON，不用 Markdown，结构化格式更适合模型稳定修改，当 feature-list.json 里所有功能都变成 passes: true，任务才算完成。

### 为什么任务状态要显式写出来

跨 session 解决的是「下次从哪里继续」，单个 session 内还要解决「当前做到哪一步」，长任务一旦拉长，没有外部进度锚点，Agent 很容易偏航，或者在还有任务未完成时过早结束。

任务状态要显式记录为外部控制对象，而不是留在模型的工作记忆里：

约束很简单，同一时间只能有一个 in\_progress，每完成一步都先更新状态，再继续下一步，必要时再加轻量校正，例如连续多轮未更新任务状态时，自动注入 `<reminder>` 提示当前进度。

### 后台 I/O 如何接入

自主度提高以后，真正容易拖慢主循环的，通常不是模型推理，而是文件操作、网络请求和长耗时命令这类外部 I/O，这些操作一旦阻塞主循环，执行节奏就会明显变差。

务实的做法，是把慢速 subprocess 放到后台线程，通过通知队列在下一轮 LLM 调用前注入结果，主循环不需要感知太多并发细节，只要在每轮开始前检查是否有新结果，再决定继续执行、等待还是调整计划，这通常比把整个 loop 改造成复杂的 async runtime 更稳，也更容易维护。

![](https://gastigado.cnies.org/d/public/image11.jpg)

## 7. 多 Agent 如何组织

一说到多 Agent，不少人先想到的就是并行，但工程上先要解决的其实是隔离和协作，这里对应的是两种完全不同的工作模式。

指挥者模式是同步协作，人与单个 Agent 紧密互动，每一轮都要调整决策，缺点也很明显，session 一结束，context 就没了，产出物也是短暂的。

统筹者模式是异步委派，人在开始时设定目标，中间让多个 Agent 并行工作，最后再审查产出，这样人只在起点和终点出现，中间产出会变成分支、PR 这类可持久化工件，多 Agent 的主要价值也在这里，不是单纯多开几个模型，而是把人的持续参与，变成对工件的最终审核。

![](https://gastigado.cnies.org/d/public/image12.jpg)

常见的组织方式是主 Agent 作为 Orchestrator 统筹全局，下挂多个子 Agent 独立并行工作。它们之间通过 JSONL inbox 协议通信，用 Worktree 隔离文件修改，用任务图管理依赖关系。

![](https://gastigado.cnies.org/d/public/image13.jpg)

### 子 Agent 适合做什么

子任务里的搜索、试错和调试过程，不该污染主 Agent 的上下文。主 Agent 真正需要的只是结论，探索细节留在子 Agent 自己的消息历史里。

![](https://gastigado.cnies.org/d/public/image14.jpg)

### 为什么协作方式要写成协议

多 Agent 协作一旦靠自然语言来对齐，很快就会出问题。模型记不稳谁承诺了什么，也记不稳谁在等谁的结果，任务开始互相依赖之后，就得先把协议写清楚：

![](https://gastigado.cnies.org/d/public/image15.jpg)

这里至少要先有三样东西，协议、任务图、隔离边界，主 Agent 通过 JSONL 消息队列分派任务给子 Agent，子 Agent 执行后只回摘要，搜索和调试细节留在自己的独立上下文里，.tasks/ 记录任务图和依赖关系，.worktrees/ 隔离每个子 Agent 的文件修改，顺序也别反过来，协议先定，隔离先做，再谈协作和并行。

### 多 Agent 下幻觉会互相放大

多个 Agent 频繁互动时，错误也会被一层层放大。Agent A 先带偏，Agent B 跟着强化，Agent C 再继续叠加，最后所有 Agent 都收敛到同一个高置信度的错误结论。交叉验证的价值就在这里，它能打断这条链，让某个 Agent 独立判断，而不是顺着前面的结论继续走。这里也有顺序，先有可持久化任务图，再引入有身份的队友，再引入结构化通信协议，最后再加交叉验证或外部反馈，比如独立的第二个 Agent、单元测试、编译器或人工审查。

![](https://gastigado.cnies.org/d/public/image16.jpg)

### 子 Agent 的深度限制和最小提示

子 Agent 有两个基本限制，第一是深度限制，防止无限递归生成孙 Agent，设一个最大深度就够了，第二是最小系统提示，只给 Tooling、Workspace、Runtime 三节，不带 Skills 和 Memory 指令，避免权限外泄，也避免破坏隔离边界。

![](https://gastigado.cnies.org/d/public/image17.jpg)

## 8. Agent 评测应该如何做

Agent 做得对不对，最终要靠评测来判断，很多团队会把这一步往后放，结果就是改了 Prompt，不知道是否变好，换了模型，也不知道是否退化，最后只剩下一组无法解释的波动数字，评测的核心是测试用例、评分标准和自动验证，真正的难点不是有没有分数，而是这些分数能不能反映真实质量。

### 为什么 Agent 评测结构更复杂

###  

上半是传统 Single-turn 评测，一个 Prompt 进去，模型输出一个 Response，判断对不对就结束了，下半是 Agent 评测，要先准备好工具、运行环境和任务，Agent 在执行过程中多次调用工具、修改环境状态，最后的评分不是看它说了什么，而是跑一批测试验证环境里真正发生了什么，结构上复杂了不止一个层级，这也是为什么传统评测方法在 Agent 场景里往往不够用。

这张图里真正需要记住的，其实就三组概念，第一组是 task 任务、trial 单次运行、grader 评分器，分别对应测什么、跑多少次、怎么打分，第二组是 transcript 完整执行记录和 outcome 环境最终结果，评测不能只看其中一边，第三组是 agent harness 被评测的 Agent 运行框架和 evaluation harness 评测基础设施，后者负责把任务跑起来、打分、汇总结果，evaluation suite 就是一批任务的集合，是评测跑起来的原材料。

### 评测现状与常用指标

Agent 的评测比传统软件更难，输入空间近乎无限，LLM 对提示措辞高度敏感，同一任务在不同运行之间也可能出现差异，从调查数据看，很多团队的评测体系仍不成熟，人工审查和 LLM 评分依然是最常见的做法。

左图是评测方式，右图是常用指标，人工标注和 LLM judge 加起来占主导，传统 ML 指标只有 16.9%，还有近四分之一的团队还没开始做评测。

在具体统计方式上，最常用的是两个指标，用途不同，不能混用。Pass@k 适合在开发阶段回答「这个 Agent 理论上能不能做到」，Pass^k 适合在上线前回答「已有功能有没有被改坏」，混用容易误判，回归测试过松会漏掉问题，能力评测过严又会让每次小改动都告警。

### 三类评分器的区别

评测是否可靠，首先取决于评分器选得对不对，三种主要类型之间，确定性和覆盖范围通常呈反向关系：

1. 代码评分器：字符串匹配、单测、结构比对，确定性最高，适合有明确答案的任务
2. 模型评分器：按评分标准打分、两个答案对比选优、多个模型投票取共识
3. 人工评分器：专家抽样审查、标注校准，可靠但慢，适合建立基准

代码评分器最不容易因设计不当引入噪声，有明确正确答案就优先用它。

「看 Agent 怎么说」和「看系统最后变成什么样」是两件事，Agent 说「订票已完成」，这是在看执行记录 transcript，数据库里确实生成了一条订单，这才是在看最终结果 outcome，只看执行记录会漏掉「说了但没做到」，只看最终结果又可能看不出中间步骤走歪了，两类都要覆盖。

Anthropic 在《Demystifying evals for AI agents》里提到过一个机票预订 Agent 的例子，Opus 4.5 在一次运行中发现了航空公司政策里的漏洞，为用户找到了更便宜的方案，如果只按预设路径打分，这次运行会被判失败，但看最终结果，用户拿到了更好的方案，只盯着执行过程会漏掉这类情况，两类都覆盖才能看清楚。

### 如何从零搭起评测体系

不用等有了完整体系再开始，20 到 50 个真实失败案例就够启动，来源优先选已经在手动检查的内容，那些才是真正反映实际用途的，在做这件事之前，有一个判断标准值得记住：如果两个领域专家拿同一个案例独立判断，结论不一致，这个案例的验收标准就还没写清楚，先解决定义，再收集数据。

环境隔离是经常被忽略的细节，每次运行都要从干净状态开始，测试之间不能共享缓存、临时文件或数据库状态，否则一个任务的失败会污染下一个，表面看起来是模型出了问题，实际是环境脏了。

测试用例要同时覆盖正例和反例，只测「应该做 X」，评分器就只会往一个方向优化，把「不应该做 X 的情况」也加进来，才能发现 Agent 在边界上的行为是否正常。

评分器选择按顺序来：有明确正确答案用代码评分器，需要判断语义质量再用模型评分器，遇到拿不准的案例，人工标注一批，用来校准自动评分器的漂移，定期读完整执行记录，不要只看聚合分数，评分器本身的 bug 通常只有在看具体 Trace 时才会暴露。

体系搭起来之后，把「当通过率接近 100% 时补充更难的任务」也当成常规工作，评测套件饱和了不是好事，意味着它已经不能再反映真实能力边界。

### 先修评测，再改 Agent

一个常见误区是，看到 Agent 表现下降，就立刻着手修改 Agent 本身，而忽略了评测系统可能先出了问题，评测出问题了，你拿到的是一个失真的信号，基于它去改 Agent，改的方向可能从一开始就是错的，甚至会把本来运行正常的部分改坏。

评测系统常见的出错来源有几类：运行环境资源不足导致进程被杀、评分器本身有 bug 把正确答案判成失败、测试用例和生产场景脱节、或者只看聚合分数而漏掉某一类任务系统性变差，这些问题在表现上都和模型退化一模一样，很难从结果数字上直接区分。

红色是基础设施错误率，蓝色是模型得分，资源上限越严，环境越容易在内存峰值时崩掉，评测直接记失败，但模型其实没答错，随着上限放开，红色跌到接近 0，蓝色几乎不变，说明之前的「失败」不少是环境噪声，看到评测分数下降，先查环境，再动 Agent。

![](https://gastigado.cnies.org/d/public/image18.jpg)

## 9. 如何追踪 Agent 的执行过程

先把 Trace 能力搭起来，没有完整记录，失败案例就没法稳定复现，Agent 出现问题时，传统只监控延迟和错误率的 APM 往往帮助有限，接口层看起来可能一切正常，但真正的问题出在模型某一轮做出了错误决策，只有回看完整 Trace 才能定位。

### Trace 里需要记录什么

条件允许的话，这套系统还应具备语义检索能力，能够查询「哪些 Trace 里 Agent 混淆了两种工具」这类问题，而不只是精确字符串匹配，规模一旦上来，靠人工全量审查是跟不上的，自动化是前提。

### 两层可观测性如何分工

第一层是人工抽样标注，基于规则采样错误案例、长对话和用户负反馈，由人工判断执行质量和失败原因，主要用来摸清失败模式，并给第二层提供校准数据。

第二层是 LLM 自动评估，对更大范围的 Trace 做全量覆盖，以第一层标注结果作为校准依据，只跑第二层，评分标准很容易漂移，只靠第一层，规模上又覆盖不了真实流量，两层要一起用。

### 在线评测如何做采样

全量运行在线评测成本高，完全随机采样又容易错过关键 Trace，更稳妥的做法是对 10% 到 20% 的 Trace 运行在线评测，按规则路由采样而不是随机：

* 负反馈触发：用户明确表示不满意的 Trace，100% 进队列
* 高成本对话：token 消耗超过阈值的，优先审查，往往代表 Agent 在绕圈子
* 时间窗口采样：每天固定时间段随机采，保持对正常流量的覆盖
* 模型或 Prompt 变更后：头 48 小时全量审查，确认没有退化

### 事件流为什么更适合做底座

Agent Loop 在 tool\_start、tool\_end、turn\_end 三个节点发出事件，完整 Trace 同步落盘，再分发给日志系统、UI 更新、在线评测、人工审查队列这些下游，事件一次发布，多路消费，主循环不需要为了任何下游改代码。

![](https://gastigado.cnies.org/d/public/image19.jpg)

## 10. 用 OpenClaw 看 Agent 如何落地

前面几节讲的是原则，这一节直接看 OpenClaw 怎么落地，上下文分层、Skills 延迟加载、结构化通信协议和文件系统状态，在这个系统里都能找到对应实现。

### 整体架构：五层解耦

OpenClaw 可以拆成五个层次，最上面是负责连接和消息分发的 WebSocket 服务，底部是 SOUL.md、MEMORY.md、Skills 等配置文件。

1. Gateway：WebSocket 服务，统一路由消息，Channel 和 Agent 不直接通信2. Channel 适配器：23+ 渠道统一接口，新增渠道不改 Agent 代码
2. Pi Agent：维护主循环、会话状态、调度，核心循环和渠道完全解耦
3. 工具集：shell/fs/web/browser/MCP，按 ACI 原则设计
4. 上下文+记忆：Skills 延迟加载 + MEMORY.md，50% token 阈值自动整合

### 消息总线如何把渠道和 Agent 隔开

加上定时任务之后，系统不再只有用户消息这一个入口，OpenClaw 就在渠道和 Agent 之间加了一层 MessageBus，Channel 只管收发，AgentLoop 只管处理，互不干扰。

### 一条最小可运行链路

Channel 适配器把消息写入 MessageBus，AgentLoop 从 Bus 中消费消息，处理完成后再把结果发回去。

dispatch 不做 await，不同 session 的消息可以并发处理，互不阻塞，但同一 session 内的消息必须串行，否则并发写历史和触发 compact 会有竞态，生产环境要对每个 sessionKey 维护一个队列或 mutex。

session 由 AgentLoop 统一管理，不下沉到 Channel 层，渠道适配器只管输入输出，换成 Discord 或飞书，Agent 核心代码不需要动。

### 系统提示如何按层叠加

OpenClaw 的系统提示可以从 SOUL.md 看起，这个文件定义了 Agent 是谁、按什么方式做事、什么情况下算完成。

系统提示不是单文件，而是按层加载。顺序从下到上分别是：平台与运行时信息、身份层、记忆层、Skills 层、运行时注入。对应到文件，大致就是 SOUL.md、AGENTS.md、TOOLS.md、USER.md、MEMORY.md 和 Skills 索引一起组成常驻部分，再按当前会话补充时间、渠道名、Chat ID 这些动态信息。

三种触发模式的加载范围也不同。普通会话加载完整系统提示，子 Agent 只加载最基础的运行时信息，不带记忆和 Skills，heartbeat 模式则单独加载 HEARTBEAT.md，也就是不等用户发消息，而是由系统按固定节奏唤起 Agent 检查是否有任务需要继续处理。长任务里再额外加一行身份重申，主要是为了压住任务漂移。

### cron 和 heartbeat 如何主动触发

cron 按计划直接触发 Agent，heartbeat 每 5 分钟轮询一次待处理任务，这两种模式都不等用户发消息。

![](https://gastigado.cnies.org/d/public/image20.jpg)

### 长任务如何恢复

长任务中途崩溃，如果没有恢复机制，就只能从头再来，OpenClaw 的做法很直接，把任务进度写到磁盘，重启后从断点继续，任务超过半小时，崩溃恢复是必选项，不是可选项。

### 为什么安全边界要先于功能

开放 Shell 权限之后，git push、rm、数据库写入这类操作都可能被触发，安全边界要先于功能。三件事必须先到位：谁能用、能在哪用、做了什么可以追踪。

白名单授权，只有授权用户可以触发 Agent：

工作空间隔离，shell 工具需要强制进行路径检查，越出工作空间目录就直接报错：

操作审计日志，每次执行都记一笔，方便后续审计和排查：

### 安全和可用性的两层兜底

除了权限、路径和审计，系统还要补两层兜底，一层防内容注入，一层防模型服务故障。

Prompt Injection

白名单和工作空间隔离解决的是越界操作，但还不够。Agent 读取的网页、邮件、文档本身也可能带攻击指令，这就是 Prompt Injection。单靠输入过滤基本挡不住，更实用的做法是按 source-sink 去拆。source 就是不可信输入从哪里进来，sink 就是这些输入最后可能触发的危险操作。重点不是识别所有攻击，而是让 Agent 即使被注入，也没有机会把危险动作真正执行出去：

* 最小权限：不给 Agent 不需要的工具，没有 sink，source 侧的注入就无法落地
* 敏感操作显式确认：向第三方传信息、调用写操作，执行前必须让用户确认，不能静默执行
* 标注外部内容边界：外部拉取的内容进入上下文时显式标注来源，声明哪些内容不可信
* 关键路径加独立 LLM 验证：同一上下文中的 Agent 很难判断自己是否已被注入，关键操作引入独立 LLM 复核更稳妥

最直接的做法，就是先把外部内容明确标成「不可信输入」，不要和系统提示混在一起。下面这个例子表达的就是这个意思：

敏感操作的显式确认也一样，本质上是把「先确认再执行」做成系统步骤，而不是让模型自己判断。

Provider 故障切换

模型服务出故障是常态，不是例外。Anthropic 返回 503、OpenAI 触发限速都很常见，所以这里要加一层 fallback，当前 Provider 挂了就自动切下一个，不用人盯：

### 工程实现应该遵循什么顺序

1. 单渠道先跑通，Telegram -> Agent -> Telegram 完整链路，不要第一版就抽象多渠道
2. 安全边界先于功能，工作空间隔离、白名单、参数验证，加任何新功能之前就要到位
3. 记忆整合要早做，不加整合，第 20 轮对话之后基本就垮了
4. Skills 先于新工具，领域知识用文档管理，比加新工具更灵活
5. 第一个失败就建评测，把第一个真实失败案例转成测试用例，不要等积累够了再开始

![](https://gastigado.cnies.org/d/public/image21.jpg)

## 11. Agent 落地里的常见反模式

这类问题都很常见，很多看起来像模型能力不够，回头看其实是工程约束没立住：

1. 系统提示当知识库：越来越长，关键规则被忽略，约定留提示，知识移 Skills
2. 工具数量失控：Agent 频繁选错工具，合并重叠工具，明确命名空间
3. 验证闭环缺失：Agent 说完成了但没法验证，每类任务绑验收标准
4. 多 Agent 无边界：状态漂移，故障归因困难，明确角色权限，worktree 隔离5. 记忆不整合：长对话第 20 轮后决策质量下降，监控 token，超阈值自动触发6. 没有评测：改了一个地方不知道有没有引入回归，失败案例立刻转测试用例
5. 过早引入多 Agent：协调开销超过并行收益，先验证单 Agent 上限再扩展
6. 约束靠期望不靠机制：规则在文档里 Agent 选择性遵守，改用工具验证 / Linter / Hook

![](https://gastigado.cnies.org/d/public/image22.jpg)

## 12. 收尾一下

最后压缩一下上下文，方便回看，如果你有更好的 Agent 开发经验，也欢迎一起交流：

1. Agent 核心是感知、决策、行动、反馈的稳定循环，控制流基本不变，新能力主要通过工具扩展、提示结构调整和状态外化实现。
2. Harness，也就是验收基线、执行边界、反馈信号、回退手段，往往比模型本身更决定系统能否收敛，高质量自动化验证和清晰目标缺一不可。
3. 上下文工程的重点是防 Context Rot，通过分层管理常驻信息、按需知识、运行时信息和记忆，再配合滑动窗口、LLM 摘要、工具结果替换和 Skills 延迟加载，才能把信号质量稳定住。
4. 工具设计按 ACI 原则来做：面向 Agent 目标，不是面向底层 API，边界明确，参数防错，定义里直接给示例，调试时优先检查工具描述，而不是先怀疑模型能力。
5. 记忆可以分成工作记忆、程序性记忆、情景记忆和语义记忆，MEMORY.md、按需检索和可回退整合，是跨会话保持一致性的关键。
6. 长任务稳定运行靠的是状态外化，Initializer Agent 把任务变成文件系统状态，Coding Agent 循环可重入，进度通过文件传递，不依赖上下文窗口。
7. 多 Agent 要先有任务图和隔离边界再引入并行，协议先于协作，子 Agent 只回传摘要，搜索和调试细节留在自己的上下文里。
8. 评测上，Pass@k 验证能力边界，Pass^k 保证上线质量，评测系统出问题先修评测再动 Agent，不要基于失真信号调整方向。
9. 可观测性上，Trace 是排查的前提，事件流做底座一次发布多路消费，人工标注校准 LLM 自动打分，两层要一起用。
10. OpenClaw 把前面这些原则放进了一个可运行系统里，真正让 Agent 跑稳，靠的不是更复杂的循环，而是消息解耦、状态外化、分层提示、记忆整合和安全边界这些工程细节。

### 参考资料

1. OpenAI, Harness engineering: leveraging Codex in an agent-first world
2. Cloudflare, How we rebuilt Next.js with AI in one week
3. Simon Willison, I ported JustHTML from Python to JavaScript with Codex CLI
4. Anthropic, Introducing Agent Skills
5. Anthropic, Managing context on the Claude Developer Platform
6. LangChain, State of Agent Engineering
7. Anthropic, Measuring AI agent autonomy in practice
8. OpenAI, Designing AI agents to resist prompt injection
9. Anthropic, Demystifying evals for AI agents

### Media

![](https://gastigado.cnies.org/d/public/image23.png)
![](https://gastigado.cnies.org/d/public/image24.jpg)
![](https://gastigado.cnies.org/d/public/image25.jpg)
![](https://gastigado.cnies.org/d/public/image26.jpg)

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-translation-tools-202605.md
description: >-
  从 Read Frog、KISS Translator 和 SentiaRead
  的官方资料出发，按网页翻译、论文阅读和英语学习三类需求梳理各自的安装方式、使用路径和差别。
---

# 三种 AI 翻译工具选型

有用户反映，沉浸式翻译功能越来越复杂，AI 翻译额度消耗也在增加。用了沉浸式翻译好几年，最近越来越难受——功能越堆越多，界面越来越臃肿，AI 翻译还在疯狂烧额度。它已经不是当初那个干净好用的工具。

网页翻译工具一旦开始堆功能，最先受影响的往往就是打开后的负担感：按钮越来越多，模型配置越来越长，订阅和额度提醒越来越频繁。等你只是想安静看篇英文文章时，工具反而先把你拽进更重的工作流里。

* **Read Frog** 想做的是 AI 陪读，重点放在上下文理解、批量请求、字幕和朗读。
* **KISS Translator** 走的是极简路线，强调开源、自接 API、隐私和可控性。
* **SentiaRead** 的定位是英语阅读器，把查词、长难句理解、朗读和生词积累放在一个连续阅读体验里。

如果只把这三者都叫成"开源平替"，反而会把差异抹掉。下面按工具分别来看。

## Read Frog：把网页翻译做成陪读流程

官网：<https://readfrog.app>

Read Frog 把自己定义成 **open-source AI-powered language learning extension for browsers**。它服务的是浏览器里的语言学习，沉浸式翻译、文章分析、多模型接入这些能力都围着网页阅读、论文阅读和字幕阅读展开。

公开资料里，Read Frog 的核心能力主要有四块。

### 项目能力

* **Context-Aware Translation**：开启后会提取页面标题和页面内容的精简 Markdown，把这些上下文一起交给模型。这样做的结果很具体：技术文章里的术语不会只按字面意思硬翻，歧义词也更容易按上下文落到正确语义。官方博客举的例子很直观：在技术文章里，`container` 往往该理解成 Docker container，`pool` 也该按数据库 connection pool 去翻。

* **Batch Requests**：项目直接写到，批量请求最多可以节省 `up to 70% on API costs`。这点和开头那句"AI 翻译烧额度"正好对应。它保留了大模型路线，只是把多段翻译合并成更少的 API 调用，减少 overhead 和 token 消耗。

* **20+ AI Providers**：项目走的是 Vercel AI SDK 这一套，常见的 OpenAI、Claude、Gemini、DeepSeek、Groq、Mistral、Ollama 都在里面。如果你本来就在不同模型之间切换，这点会比较顺手。

* **配套能力**：

  * YouTube 字幕翻译
  * 选中文本后的解释、翻译、朗读
  * 基于 **Edge TTS** 的免费朗读
  * 自定义 prompts
  * 双语模式和仅译文模式切换

合在一起看，Read Frog 想做的是一条"阅读—理解—朗读—术语处理"的陪读链路。

### 安装和启用

安装页给的是一条很稳的路径：装浏览器扩展，配模型，开始读。

可用安装入口包括：

* Chrome Web Store
* Microsoft Edge Add-ons
* Firefox Add-ons

按官方文档，启动顺序可以压成三步：

1. 安装扩展；
2. 配置 API Key；
3. 找一篇网页文章，点击 `Read` 开始使用。

文档原话把 API key 叫作"调用 AI 模型的钥匙"，这也意味着 Read Frog 的高级能力默认建立在你自己接入模型之上。如果你只是想做基础翻译，资料里也保留了 Google Translate、Microsoft Translate、DeepLX 这类低成本或免费路线；但如果你想用上下文理解、解释、定制 prompts，还是得走 LLM provider。

### 具体怎么用

Read Frog 的使用方式可以分成三层。

#### 1. 整页翻译

官方 docs 的 `Bilingual Translation` 页面写得很清楚：你可以通过悬浮按钮触发整页翻译，也可以在弹窗里点 `Translate`。翻译结果默认会贴在原文旁边，适合一边看一边对照。

#### 2. 段落 / 划词翻译

默认可以 hover 段落后配合快捷键做局部翻译；选中一段文字后，还能拉起工具条，直接做翻译、解释或朗读。这种方式更适合论文里某一段看不懂、但又不想整页都翻的场景。

#### 3. 字幕和朗读

YouTube 字幕翻译和 Edge TTS 是 Read Frog 比较实用的两块。看英文视频时，字幕可以双语对照；读文章时，选中句子就能朗读。对想顺便练听力的人，这比纯网页翻译器更顺。

### 使用场景

Read Frog 常见的使用场景有：

* 看英文网页，希望译文更顺，不想每个术语都自己猜；
* 读论文或技术文档，希望上下文能帮模型把术语翻对；
* 刷 YouTube 字幕，顺手做双语阅读；
* 想用朗读把网页变成轻量听力材料。

它的代价也要说清楚：上下文理解、批量请求省 token，这些优势都建立在你愿意自己配置模型和 API key 的前提上。如果你只想装完立刻用，不想碰 provider 配置，Read Frog 的门槛还是比纯离线或纯内置翻译高一点。

![Read Frog 页面翻译演示](https://gastigado.cnies.org/d/public/read-frog-page-translation-demo.gif)

## KISS Translator：尽量保持简单，把控制权交还给用户

官网：<https://fishjar.github.io/kiss-translator/options.html>

KISS Translator 的项目名已经把路线讲清楚了：**Keep It Simple**。它的定位是"一个简约、开源的双语对照翻译扩展 & 油猴脚本"。它尽量把网页翻译压回浏览器层，模型、接口、同步这些能力则交给用户自己掌控。

### 项目能力

KISS Translator 的特征很集中，几乎每一条都围绕"用户自己掌控"展开。

场景覆盖很广：

* 网页双语对照翻译
* 输入框翻译
* 划词翻译
* 悬浮翻译
* YouTube 字幕翻译
* 仅显示译文
* 富文本翻译，尽量保留原文链接和样式

模型和接口层很开放。资料里列出的支持项包括：

* OpenAI
* Gemini
* Claude
* Ollama
* DeepSeek
* OpenRouter
* DeepL / DeepLX
* AzureAI / CloudflareAI
* 以及自定义接口

这里最关键的是 **custom API**。官方文档把它讲得很重：理论上可以接入任何翻译接口，还支持 Hook、自定义参数、流式输出、上下文会话记忆、术语词典。这意味着如果你不想把流量交给某个固定中转服务，或者你自己已经有代理网关、Ollama、本地模型、云端聚合接口，KISS Translator 很容易接进去。

还有两个很实用的点：

* **batch aggregation**：聚合批量发送翻译文本，减少调用次数；
* **AI conversation context memory**：在 AI 翻译时保留一定上下文记忆，提高译文连贯性。

KISS Translator 的界面很轻，但底层能力并不单薄。它把默认体验收得很紧，能力入口并没有因此变窄。

### 安装方式

官方资料给了两条安装路径，而且明确建议：**优先用浏览器扩展，不要直接上油猴脚本**。理由也很明确：扩展功能更完整，油猴更容易遇到跨域和脚本冲突问题。

浏览器扩展入口包括：

* Chrome：<https://chrome.google.com/webstore/detail/kiss-translator/bdiifdefkgmcblbcghdlonllpjhhjgof>
* Edge：<https://microsoftedge.microsoft.com/addons/detail/%E7%AE%80%E7%BA%A6%E7%BF%BB%E8%AF%91/jemckldkclkinpjighnoilpbldbdmmlh>
* Firefox：<https://addons.mozilla.org/en-US/firefox/addon/kiss-translator/>
* Thunderbird release：<https://github.com/fishjar/kiss-translator/releases>

油猴脚本入口则是：

* <https://fishjar.github.io/kiss-translator/kiss-translator.user.js>
* iOS Safari 还有单独的 userscript 入口

最快上手路径可以压成五步：

1. 安装浏览器扩展；
2. 打开设置页；
3. 选择翻译服务；
4. 填 API key 或 custom API 配置；
5. 在网页上用快捷键或面板启用翻译。

### 具体怎么用

KISS Translator 基本就是浏览器上的一层翻译界面，操作点都比较轻。

#### 1. 快捷键驱动

默认快捷键是：

```text
Alt+Q 开启翻译
Alt+C 切换样式
Alt+K 打开设置弹窗
Alt+S 打开翻译弹窗 / 翻译选中文字
Alt+O 打开设置页面
Alt+I 输入框翻译
```

重度网页用户会很顺手。你不用切应用，也不用专门进阅读模式，页面上直接翻。

#### 2. 自接 API

如果你想自己控接口，可以直接走 custom API。官方 `custom-api_v2.md` 给了默认 request / response 规范，也给了 Ollama、硅基流动、Google Translate 等示例。哪怕某个模型的参数不兼容、某个原生接口不支持 batch，你也可以通过 Hook 改请求体。

这也是它对特别在意隐私的人更友好的原因：数据路径由你自己决定。你可以走自己的 API 网关、自己的 Cloudflare Worker，甚至自己的本地服务，不必默认经过第三方中转。

#### 3. 同步和规则

KISS Translator 还有两项经常被忽略、但长期用很有价值的能力：

* **WebDAV** 同步
* **kiss-worker** 同步服务（Cloudflare / Docker）

如果你有多台设备，或者想把规则、术语词典、订阅规则一起同步，这两条会比单机插件舒服很多。

### 使用场景

KISS Translator 常见的使用场景有：

* 网页翻译用得很重，想保持界面和操作最简；
* 自己已经有 API、代理网关或本地模型，不想被平台绑死；
* 比较在意隐私，希望数据不要默认经过第三方；
* 愿意花一点时间做 custom API、同步和规则设置。

如果你的目标是"装一个开源网页翻译器，并把控制权尽量握在自己手里"，KISS Translator 是这三者里最贴近这个方向的。

![KISS Translator 截图](https://gastigado.cnies.org/d/public/kiss-translator-screenshot-01.jpg)

## SentiaRead：把翻译、查词和英语学习放进一个阅读器里

官网：<https://sentiaread.com>

SentiaRead 和前两个工具差得很明显。它一开始就按"英语阅读器"来做。官网标题直接写的是 **AI-Powered English Learning Reader**，首页文案强调的是：用你喜欢的内容做可理解输入，让 AI 根据上下文和你的水平解释单词与句子。

看 SentiaRead 时，重点要放在它有没有把阅读、查词、积累和同步连成学习链路。

### 核心能力

官网首页有几条主线，基本把产品方向交代清楚了。

#### 1. 它处理的不只是网页

首页明确写到可以导入：

* EPUB ebooks
* web articles
* podcast shows

FAQ 里又补了一层：当前支持 EPUB、TXT、Markdown、podcasts，也能从网页导入内容，或者直接从剪贴板粘贴。PDF 和 YouTube transcription 在首页被标成 `coming soon`，所以这两项现在只能当路线图看，不能写成现成功能。

#### 2. 它的核心能力是上下文查词

官网把这点叫 **AI contextual definitions tuned to your level**。意思很具体：同一个词，它不会只给词典式释义，还会结合当前上下文和你的 CEFR 等级来解释。支持页写的是 A1 到 C2。

这和普通网页翻译器差别很大。普通翻译器的中心是整句或整页译文；SentiaRead 的中心是阅读过程中某个词、某个短语、某一句话为什么会这样理解。

#### 3. 它把英语学习能力压进阅读过程里

首页还点了几项很关键的阅读学习功能：

* **visual memory reinforcement**：标记成 learning 的单词，之后在阅读里会自动高亮；
* **sentence-synced subtitles**：播客字幕按句同步播放；
* 即点即查、即句翻译、可记笔记；
* **cross-device sync**：Mac、iPhone、iPad、Android，连 E-Ink 设备也覆盖。

把这几项放在一起看，它就是一款把查词、朗读、生词积累和跨端同步都压进去的英语阅读器。

### 4 步使用法：按官方支持页保留

SentiaRead 的快速上手可以分为四步。按官方支持页 FAQ 的内容，可以压成这 4 步：

1. 下载 Sentia Read；
2. 创建账号；
3. 导入第一本书或文章；
4. 点按任意单词，查看按你水平生成的 AI contextual definitions。

支持页的 `Getting Started` 列表还多给了两个细节：设置阅读等级（A1-C2），以及把单词保存进 vocabulary list。正文这里保留 4 步版本，正好对应官方快速上手。

### 安装和入口

SentiaRead 不只提供浏览器插件，它还有完整下载页，入口覆盖得比较全：

* macOS Apple Silicon
* macOS Intel
* Windows 64-bit
* iPhone / iPad
* Android
* Android APK
* Chrome 扩展
* Firefox 扩展

如果你习惯在手机、平板、电脑之间切阅读位置，这一点比单纯浏览器扩展强很多。

### 具体怎么用

SentiaRead 的重点落在持续阅读，整页一键翻译不在它的中心场景里。

#### 1. 导入内容后开始读

你可以导入 EPUB、TXT、Markdown、网页文章，或者播客内容。它会把这些内容放进统一阅读界面里，不用每次都回浏览器网页上开新面板。

#### 2. 阅读中查词、查句、听句子

官网首页写到：点词可以看 contextual definitions；播客有按句同步字幕；看不懂的句子可以即点即翻。结合长难句改写、句子 TTS 朗读，它的重点很明确，就是让你在继续读下去的同时把内容学会。整页网页的粗翻不属于它的核心任务。

#### 3. 生词和进度会跟着你走

支持页和首页都把 sync 写得很明确：阅读进度、高亮、词汇表会自动跨设备同步。对英语学习来说，这一点比网页翻译器更关键，因为这里追求的是长期积累，不是看完一篇就结束。

### 隐私和同步怎么处理

SentiaRead 这一类产品，隐私问题要单独说，不然读者容易自动把它想成"和本地开源插件一样"。官方隐私页明确写了几件事：

* 会处理账户信息、阅读等级、学习目标、上传内容、笔记、高亮、词汇列表；
* 浏览器扩展保存到服务的网页内容，也属于被处理的用户内容；
* 个人内容不会用于训练 public AI models；
* 可能调用 trusted AI APIs，但这些第三方不会保留或复用用户数据；
* 数据会在传输中和静态存储时加密。

如果你特别在意"完全自己管数据"，SentiaRead 就不太适合当第一选择。它更看重跨端和学习闭环；如果你的前提是所有内容都尽量留在自己的 API 或自己的存储里，那 KISS Translator 会稳妥得多。

![SentiaRead 官网首页归档截图](https://gastigado.cnies.org/d/public/sentiaread-homepage.png)

## 选型建议

如果只给一个很短的选择建议，可以直接按这三条分：

* **网页翻译**：**KISS Translator**。它最轻，最开源，API 和隐私控制权也最大。
* **论文阅读 / 长文阅读**：**Read Frog**。上下文理解、批量请求、字幕和朗读都更贴合"边读边理解"。
* **英语学习**：**SentiaRead**。它把阅读器、查词、TTS、生词高亮和跨端同步连成了一条学习链。

如果你已经受不了沉浸式翻译越来越臃肿、AI 翻译又烧额度，选型时就把主需求定下来：浏览器整页翻译、论文陪读，还是长期英语学习。三者对应的产品方向本来就不同。

---

---
url: https://ain.hmgf.hxcn.space/ai/free-model-access-guide-202605.md
description: 结合本地渠道草稿与公开资料，整理 freemodel、Kiro、Code Relay 的使用方式、账号要求、支付风险和正式工作流里的取舍。
---

# 免费模型渠道能不能碰

免费渠道对新模型用户一直很有吸引力。你不想一上来就订几个 20 美元起步的月费，只想先试试 GPT-5.5、Claude 4.7 这一档模型到底值不值。问题也出在这里：越是"试试"，越容易放松警惕，把主力邮箱、主力银行卡、常用浏览器插件、甚至公司代码一起塞进去。

这篇文章不做推荐榜单，只回答一个更实际的问题：**这些渠道能不能碰，碰到什么程度。**

其中 `Kiro` 有相对完整的官方定价和账单说明，可以写得更实；`freemodel` 和 `Code Relay` 公开匿名页能核到的内容有限，部分说法（如赠送额度、是否需要绑卡）**需登录后确认**。

## 结论先行

如果你只是想体验新模型、做几个不敏感的小测试，这类渠道可以碰。

如果你要上传正式项目代码、长期保存对话、跑稳定生产工作流，排序应该反过来：官方免费额度、官方付费计划、本地模型，最后才轮到这类邀请制或聚合站。

原因很简单：便宜通常换不来稳定、合规和清楚的数据处理方式。

## freemodel：适合短期试用，但公开页能核到的信息有限

官网：<https://freemodel.dev/>

本地材料给出的入口是：<https://freemodel.dev/invite/FRE-2d9c3779>

能核到的部分：匿名公开页能确认这是一个叫 `FreeModel AI` 的站点。前端 bundle 里可以看到几类明确信息：

* 站内有 GPT-5.5、GPT-5.4、Claude 等模型的 token 成本表；
* 站内有 weekly plan、current balance、top up、referral credits 这类页面文案；
* 邀请奖励文案明确存在：`Invite friends, get $5 each`，以及"被邀请人也会获得 5 美元 credit"。

本地材料里的说法：

* 注册送 1 个月 Pro；
* 每周 66 美元 GPT-5.5 调用额度；
* 无需绑卡。

这三条在匿名公开页面上无法直接核实，是否仍然生效、是否因活动或账号地区变化而不同，**需注册后在账户页确认**。

### 使用方式

按本地材料，流程是：

1. 访问官网或邀请链接；
2. 用邮箱注册；
3. 查看账户页是否有 Pro / weekly credit；
4. 再决定是否投入更多时间使用。

### 是否需要账号

需要账号。匿名页只能看到壳和前端资源，具体额度与邀请信息要进站内才知道。

### 是否涉及支付或自动续费

公开页能核到有 `top up` 和账户余额概念，说明站内支持充值或买额外 credits。至于注册送的权益会不会自动转付费、是否默认续费，匿名页看不出来，本地材料也只说"1 个月 Pro 到期后降级免费版"。这条要在站内 billing 页面再次确认，不要默认相信。

### 使用场景

* 测试最新模型的手感；
* 临时跑几轮对话；
* 做不含敏感数据的轻量尝试。

### 主要风险

* 公开资料少，规则透明度一般；
* 额度政策可能随时改；
* 如果你后续充值，得先看清账单和退款规则；
* 不适合当长期正式工作流的基础设施。

## Kiro：相对正规，但"首月 0 元"要按官方账单理解

官网：<https://kiro.dev/>

本地材料给出的入口是：<https://app.kiro.dev/>

`Kiro` 是这三者里最容易写清楚的一项，因为它有官方定价页、FAQ、billing 文档和取消订阅说明。

截至 2026 年 5 月 17 日，Kiro 官方公开资料里能核到这些信息：

* Free：50 credits；
* Pro：20 美元 / 月；
* Pro+：40 美元 / 月；
* Power：200 美元 / 月；
* Free tier 可用 open weight models，并提到 Claude Sonnet 4.6，但有较严格的使用限制；
* 付费档可用 premium models，官方 FAQ 提到 Sonnet 4.6、Opus 4.6、Opus 4.7；
* 升级 paid plan 需要有效信用卡；
* 取消订阅后，会在**下一个 billing cycle** 回到 Free，不是当场彻底清空订阅关系。

### 本地材料里"20 美元抵扣"这件事

本地草稿说的是：新用户手动选 20 美元套餐，价格会显示为 0 元。

按官方资料，更准确的说法是：**第一次升级到付费计划、且使用 social login 或 Builder ID 的用户，可以获得最多 20 美元的 credit；这个 credit 会按当月剩余时间折算。**

所以这里说的不是"所有人点进去都能免费用满一个整月"，而是一个带条件、按日折算的首次升级抵扣。这两件事要分开看。

### 使用方式

流程应该这么走：

1. 打开官方定价页；
2. 用 Google / GitHub 或 Builder ID 登录；
3. 在升级页面确认首次抵扣是否生效、金额怎么算；
4. 如果确实要升付费档，再绑卡；
5. 进入 billing 页面确认是否开启自动续费，以及取消路径。

### 是否需要账号

需要。公开首页只是应用入口，具体 credit、模型权限和账单都要登录后看。

### 是否涉及支付或自动续费

涉及。官方明确写到付费升级需要有效信用卡，而且按月结算。取消订阅要走官方 billing 流程，不是"开通当天关掉就等于彻底没有计费关系"。

本地材料里"开通后立即去设置里取消自动续费"这条建议本身没问题，但正确理解应该是：**如果你只想试一次升级权益，记得尽快在官方 billing 页面确认续费状态。**

### 关于本地材料提到的 Bitget 虚拟卡

本地草稿额外给了一个 Bitget 邀请链接和邀请码，作为绑卡替代方案。这部分不是 Kiro 官方资料，不会写成推荐步骤。是否使用虚拟卡，是另一个支付和合规问题；如果你搞不清发卡规则、扣款路径和退款逻辑，最好不要为了省几十美元把支付链路越搞越复杂。

### 使用场景

* 想正规体验一次付费模型工具；
* 想测 Claude 系列在 IDE / coding 产品里的手感；
* 能接受绑卡，也愿意自己看账单说明。

### 主要风险

* 用户把"首次抵扣"误读成"永久免费一个月"；
* 绑卡后忘记检查订阅状态；
* 把测试账号和正式工作账号混用。

## Code Relay：聚合中转面板，只适合低风险测试

官网：<https://api.code-relay.com/register?aff=3SgD>

从这个站点的公开入口，大致就能判断它的定位。匿名页和前端 bundle 能核到：

* 它的描述是 `OpenAI 接口聚合管理`；
* 支持多种渠道，包括 Azure；
* 前端里有 Anthropic Claude、xAI、DeepSeek 等多通道配置；
* 有微信登录 / 注册、邀请码、邀请收益、剩余额度等字段。

这说明它是一个**聚合转发 / key 分发面板**，不是模型厂商的官方入口。

本地材料里的说法是：

* 微信注册；
* 注册送基础额度；
* 邀请 1 人送 50 美元额度；
* 可切 GPT-5.5 / Claude 4.7。

这里要特别谨慎。50 美元这个数值在公开页面上无法直接验证，当前到底发多少初始额度也无法确认，注册后能否稳定使用 GPT-5.5 / Claude 4.7 同样不确定。**需登录后确认实际权益。**

### 使用方式

按本地材料，流程大概是：

1. 访问注册链接；
2. 用微信注册或登录；
3. 查看是否有初始额度；
4. 如果你真要试邀请机制，再去看站内的 aff / reward 页面。

### 是否需要账号

需要，而且是微信登录体系。前端 bundle 里能看到微信登录相关字段和二维码流程。

### 是否涉及支付或自动续费

公开页没有直接显示订阅型月费说明，但有额度、余额、充值等词。它走的是储值或余额模式，不是标准 SaaS 月费订阅。具体是否会要求充值、怎么扣费、是否有退款规则，也要在站内确认。

### 使用场景

* 临时测接口；
* 跑一些不敏感的模型对比；
* 体验不同渠道的统一面板。

### 主要风险

这是这篇里风险最高的一类，因为它本身就是中转 / 聚合角色：

* 你的请求可能经过第三方服务器；
* 额度和模型映射关系不透明；
* 站点可能随时改规则、停服务或清空余额；
* 不适合上传公司代码、合同、隐私数据、客户资料；
* 不适合把主力 API Key 再次接到这种平台里做转发。

如果要用，只能把它当"短期实验用的低信任环境"。

## 三种使用目标，判断方式不一样

### 1. 只是测试

如果你的目标只是"看看这模型最近变强了没有"，那你可以接受更多不稳定性：

* 用次要邮箱；
* 不放敏感数据；
* 不绑主力银行卡；
* 不依赖长期保存对话；
* 用完就撤。

这个层级，`freemodel` 和 `Code Relay` 还能碰，`Kiro` 也可以用，但要看清账单。

### 2. 临时体验

如果你要连续几天写东西、试代码、做一轮模型对比，就不能只看"能不能进去"，还要看：

* 额度是否透明；
* 站点是否稳定；
* 续费和充值规则是否清楚；
* 模型版本是不是经常变。

这个层级，`Kiro` 更稳，`freemodel` 次之，`Code Relay` 只适合低风险数据。

### 3. 生产项目

如果 AI 已经进入正式工作流，判断标准就该变成：

* 数据流向是否清楚；
* 账单和 SLA 是否清楚；
* 出问题时有没有官方支持；
* 模型升级、降级和配额是否可预期。

到了这个层级，这三类免费 / 邀请 / 聚合渠道都不该做主方案。最多留作备用测试环境。

## 账号和数据，最容易出问题的地方

### 中转和共享账号

只要平台不是模型厂商官方，默认就按"可能中转"处理。即便它页面上看起来只是一个聊天框，背后也可能还有转发、路由、缓存和日志。共享账号风险更高，因为你无法确认谁看过什么、导出过什么。

### 浏览器插件和脚本

很多人为了更方便拿免费额度，会顺手装一堆插件、脚本和自动填表工具。这类东西经常能读页面内容、拿 cookie、改请求。你如果本来只是想省几美元，最后却把常用浏览器环境一并污染了，完全不划算。

### API Key

不要把自己本来就有的官方 API Key 接进来做二次转发，也不要把团队 key 放到来路不清的平台里托管。省了入口费，可能会多一个密钥泄漏点。

### 敏感代码和文档

这是底线：

* 公司代码不要上传；
* 合同、报价单、身份证明不要上传；
* 客户名单、财务表、内部方案不要上传；
* 如果非要测，也做脱敏样本。

## 更稳的替代方案

### OpenAI 官方免费层

OpenAI Help 当前明确写有 ChatGPT Free Tier FAQ。到 2026 年 5 月 17 日，Free tier 可用 GPT-5.5，但有时间窗口限制；同时也能用 web search、文件上传和图像相关能力。对于很多"我先试试"的需求，这已经够了。

### Anthropic 官方免费层

Anthropic 官方 pricing 页也保留了 Free 计划。写作、聊天、代码、图像分析和 web search 都有入口，只是额度低于 Pro / Max / Team。你如果只是想体验 Claude 风格，从官方免费层起步更稳妥。

### 团队额度和正规订阅

如果你是团队用，优先看官方 Team / Business 这类计划。它们不是最便宜的，但规则清楚，出了问题也有明确责任归属。

### 本地模型

如果你最在意的是数据安全和可控性，本地模型反而风险更可控。像 Ollama 这类工具适合做离线测试、文档整理、敏感代码辅助。效果未必能追上最新闭源模型，但数据留在本地，控制面也在自己手里。

## 保守建议

免费渠道可以拿来测试，也确实能省钱。

但对正式工作流，建议很保守：**只拿来体验，不拿来托底。** 测完模型能力，真正要长期用时，还是回到官方服务、官方团队计划或者本地可控方案。省下的那点月费，通常抵不过一次账号问题、一次敏感数据外流，或者一次额度清零带来的返工。

---

---
url: https://ain.hmgf.hxcn.space/ai/witr-process-explainer-202605.md
description: 从 witr 官方 README、CLI 文档和安装脚本出发，解释它如何在终端里回答"这个进程为什么会在跑"。
---

# witr 进程溯源

> 终端工具用了 20 年，一直没人搞懂进程为什么在跑。

这句话并不夸张。我们平时查进程，手上其实已经有一堆工具：`ps`、`top`、`lsof`、`ss`、`systemctl`、`docker ps`。难点不在"看不到进程"，而在这些工具通常只告诉你 **现在有什么**，不会顺手把"它为什么会在这里"解释完。线上接手一台陌生机器时，这种断层特别明显：你能看到 5432 端口有人监听，能看到某个 `node` 或 `python` 在跑，但它是 systemd 拉起来的、pm2 托管的、Docker 容器里的，还是某个 shell 临时起的，往往还得再补一轮手工排查。

witr 的目标就一个，仓库首页也直接写在第一行：**Why is this running?** 它想交代的是这个进程从哪里来、谁把它拉起来、现在又是谁在维持它继续存在。

## 仓库背景与定位

witr 是 `Pranshu Parmar` 的开源项目，仓库简介只有一句话：`Why is this running?` 这句话展开后，意思也很清楚：当系统里有某个进程、服务或监听端口时，背后总会有一条因果链。这条链可能经过 supervisor、container、service manager、shell，会分散在多个系统层上。现有工具擅长展示状态，witr 则把因果关系直接讲出来。

官方资料里列出的目标有几条，基本决定了它适合什么场景：

* 解释 **why a process exists**，而不只是列出进程表；
* 尽量减少你来回切多个工具的次数；
* 零配置开箱即用；
* 保持只读，不做自动修复；
* 在故障压力下也能看懂输出。

它不管监控、性能分析和自动修复，只做追因果链这件事。

按 GitHub API 在 2026-05-16 的实时返回，`pranshuparmar/witr` 当时是 **16,734 stars**。

## 它到底在补什么空白

官方 `Purpose` 段讲得很清楚：现有工具通常告诉你"是什么在跑"，但还需要你自己把多份输出拼起来，推断"为什么在跑"。witr 把这一步收成一个统一输出。

它默认会尝试回答四个问题：

1. 现在跑的是什么；
2. 它是怎么启动的；
3. 谁在维持它继续运行；
4. 它属于什么上下文。

把这四个问题压成一条输出后，日常排查会省掉不少来回跳转。比如你在 `ss -lntp` 里看见 5001 端口被占，witr 希望你不用再自己串 `lsof`、`ps -fp`、`systemctl status`、`pwdx`、`docker inspect` 这些命令，直接就能看到：目标进程是谁、父链路怎么走、主来源是什么、工作目录在哪里、是不是某个 Git 仓库、是不是绑在公网地址上。

## 支持平台：四个平台都支持，但能力不完全一样

平台支持矩阵写得很明确：

* **Linux**（x86\_64、arm64）：基于 `/proc`，功能最完整；
* **macOS**（x86\_64、arm64）：主要依赖 `ps`、`lsof`、`sysctl`、`pgrep`；
* **Windows**（x86\_64、arm64）：主要依赖 `Get-CimInstance`、`tasklist`、`netstat`；
* **FreeBSD**（x86\_64、arm64）：主要依赖 `procstat`、`ps`、`lsof`。

平台矩阵里还有一些细节：

* 按 **进程名、PID、端口** 查询，这四个平台都支持；
* 按 **文件路径** 查询，Windows 不支持，其余三者支持；
* **环境变量** 输出在 Linux、FreeBSD 最完整，macOS 因 SIP 只有部分支持，Windows 不支持；
* **service manager** 解析四个平台都有：Linux 看 systemd，macOS 看 launchd，Windows 看 Services，FreeBSD 看 rc.d；
* **schedule detection** 只有 Linux 和 macOS 有，Windows 和 FreeBSD 没有；
* **TUI 里的进程动作** 在 Windows 上不可用，其余三者可用。

所以正文里说"支持 Linux、macOS、Windows、FreeBSD"没问题，但如果要再细一点，就得按矩阵来写，不能把 Linux 上的全部细节都投射到别的平台上。

## 安装方式：四个平台都给了官方路径

安装路径给得很全。快速脚本、包管理器、源码安装和手动安装都保留了。

### Linux、macOS、FreeBSD

官方 Unix 快速安装命令是：

```bash
curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash
```

这个脚本会做几件事：

* 识别操作系统，只接受 `linux`、`darwin`、`freebsd`；
* 识别 `amd64` 或 `arm64`；
* 从 GitHub Releases 下载最新二进制和 man page；
* 默认安装到 `/usr/local/bin/witr`；
* man page 默认放到 `/usr/local/share/man/man1/witr.1`；
* 如果目标目录不可写，会尝试使用 `sudo`、`doas` 或 `run0`。

如果你不想装到系统目录，脚本也支持改前缀：

```bash
INSTALL_PREFIX="$HOME/.local" bash install.sh
```

此外，常见包管理器入口也给全了：

* Homebrew：`brew install witr`
* Conda / Mamba / Pixi：`conda install -c conda-forge witr`
* Arch Linux AUR：`yay -S witr-bin`
* FreeBSD：`pkg install witr` 或 Ports 构建
* 还有 AOSC、Guix、Uniget、Aqua、Brioche 等社区渠道

Linux 用户如果想直接装原生包，也能从 release 页面下 `.deb`、`.rpm`、`.apk`。

### Windows

Windows 的快速安装命令是：

```powershell
irm https://raw.githubusercontent.com/pranshuparmar/witr/main/install.ps1 | iex
```

这个 PowerShell 脚本会下载最新 release zip、校验 checksum、把 `witr.exe` 解压到 `%LocalAppData%\witr\bin`，并把这个目录加进当前用户的 `PATH`。

如果你更习惯包管理器，Windows 还可以走：

```powershell
winget install -e --id PranshuParmar.witr
```

或者：

```powershell
choco install witr
scoop install main/witr
```

### 手动安装与源码安装

如果你想完全手动控安装过程，文档里也保留了分平台步骤，包括：下载 release 二进制、校验 `SHA256SUMS`、手动移动到目标目录。

另一个更工程师向的入口是：

```bash
go install github.com/pranshuparmar/witr/cmd/witr@latest
```

这条路线适合已经有 Go 环境、想直接装源码版本的人。

## 它能查什么：进程名、PID、端口、文件路径

witr 最实用的一点，是入口不只一种。CLI 文档明确写了四类目标：

* **进程名**：直接把名字当位置参数传进去；
* **PID**：`--pid`；
* **端口**：`--port`；
* **文件路径**：`--file`。

最常见的几种命令是：

```bash
witr nginx
witr --pid 1234
witr --port 5432
witr --file /var/lib/dpkg/lock
```

默认按名字查时，witr 用的是 substring matching，也就是模糊匹配。如果你只想精确匹配某个进程名，可以加：

```bash
witr bun --exact
```

这些目标还可以混用，而且是可重复的。比如：

```bash
witr nginx --port 5432 --pid 1234
```

结果会按照你输入的顺序依次显示，并加上分隔标题。这点对复杂排查很有用，你可以一次把几个怀疑对象都查掉，而不是来回敲命令。

## 输出里最值得看的几段

witr 的价值主要在输出结构。标准输出分成几个部分，其中最重要的是下面几块。

### 1. Target

你查的目标是什么：名字、PID、端口还是文件。

### 2. Process

这里会显示可执行文件、PID、用户、命令行、启动时间、重启次数。

### 3. Why It Exists

这是核心。官方把它叫做 **causal ancestry chain**，也就是一条"谁启动了谁"的链。

示例里给的是：

```text
systemd (pid 1) → pm2 (pid 5034) → node (pid 14233)
```

这时候你知道的就不只是 `node` 在跑，还能看出：它最终是 systemd 拉起来的，中间经过了 pm2。

### 4. Source

witr 还会从整条祖先链里选一个主来源。文档里的原话是 **Only one primary source is selected**。这个来源可能是：

* systemd unit
* launchd service
* Windows service
* rc.d service
* docker container
* pm2
* cron
* SSH session
* interactive shell
* Snap / Flatpak sandbox

这也是正文里能比较稳地写"systemd unit 来路"的依据。这里没有什么神秘推理，只是把主负责系统显式挑出来。

### 5. Context

这块讲的是"它属于什么上下文"。文档列出的信息包括：

* Working directory
* Git repo name and branch
* Container name / image
* Public vs private bind

如果你接手的是一个陌生目录下的线上进程，这几项会很省时间。

### 6. Warnings

文档里有可核对的 warning 规则，包括：

* 进程以 root 身份运行；
* Linux 上非 root 进程带危险 capabilities；
* 监听公网地址 `0.0.0.0` 或 `::`；
* 重启次数过多；
* 内存占用过高，阈值写的是 **RSS > 1GB**；
* 运行时间超过 **90 天**；
* deleted binary；
* `LD_PRELOAD`、`DYLD_*` 这类 library injection 指标。

两个细节：第一，文档里没有"静默跑几个月"这种模糊词，而是直接写成 `over 90 days`。第二，warning 是 **non-blocking observations**，它们只是提示你可能有风险，不代表一定异常。

## "kernel 来路"怎么更准确地理解

有人用"从 kernel 到 systemd unit"这种说法。这个说法抓住了感觉，但换成更准确的表述会更严谨。

witr 并不是给你画一张"从 kernel 层开始的完整溯源码图"。它做的事，可以理解成：

* 从 **名字 / PID / 端口 / 文件路径** 先锁定进程；
* 再沿着 **父进程链、service manager、container、shell、SSH session、scheduler** 去追它的直接来源；
* 再把这条因果链压成一段人能读懂的解释。

源码里能看到一些和内核层细节相关的实现，比如 Linux / macOS / FreeBSD 上会处理 command 名被 kernel comm field 截断的问题，Windows 代码里也直接调用了 `kernel32.dll`。但这些都属于实现细节，不适合被写成"能展示 kernel provenance"。正文保守写法就是：它从系统事实往上追责任链。

## TUI 仪表盘：另一种入口

TUI 在官方资料里是单独列出来的一节。只要你不带参数直接运行 `witr`，或者显式加 `-i`，就会进入交互式模式。

```bash
witr
# 或
witr -i
```

官方对 TUI 的描述有几项：

* **Live Process List**：实时进程列表，可排序、可过滤；
* **Port View**：直接从端口视图看谁占着端口；
* **Process Details**：下钻某个进程，看完整 ancestry、child processes、environment variables、working directory；
* **Process Actions**：在 UI 里直接发 Kill、Terminate、Pause、Resume、Renice；
* **Mouse Support**：可以用鼠标排序列、点行。

如果你平时更习惯在终端里巡检，而不是每次都手搓参数，这个入口会比较顺手。尤其是接手陌生服务器时，你常常想大概扫一眼：有什么长跑进程、哪些端口对外开放、哪些进程吃内存高。TUI 比单条命令更适合做总览。

![witr 官方 README 展示图](https://gastigado.cnies.org/d/public/witr-banner.png)

## 实际排查流程：按端口追最直观

如果把 witr 放进真实排查流程，我更推荐从端口开始，因为这通常是最接近问题现场的入口。

### 第一步：发现端口

比如你发现 5432、5001、8080 这类端口被监听，直接查：

```bash
witr --port 5432
```

这一步能把端口占用者映射到具体 PID，并继续给出祖先链。

### 第二步：看来源链

如果输出里告诉你：

```text
systemd → pm2 → node
```

那你后续就知道该去看 systemd unit、pm2 配置或对应工作目录，不用继续在进程表里瞎翻。

### 第三步：判断来源有没有问题

这时主要看三块：

* `Source`：是 systemd、launchd、Windows service、rc.d，还是 interactive shell、SSH session；
* `Context`：工作目录、Git 分支、容器名、绑定地址；
* `Warnings`：公网监听、高内存、90 天长跑、deleted binary、可疑环境变量。

如果一个进程是通过 SSH session 拉起来、绑在 `0.0.0.0`、工作目录又不在你熟悉的项目里，那就很值得继续追。

### 第四步：必要时再切其他查询入口

如果你拿到 PID，就继续：

```bash
witr --pid 1234 --tree
```

如果你怀疑它卡着某个锁文件，就直接：

```bash
witr --file /var/lib/dpkg/lock
```

这一层的意义在于：你不用一开始就猜对入口。端口、PID、文件路径、名字都能互相切换。

## 它适合哪些场景

把官方目标和上面的查询方式对起来，witr 最适合三类场景。

### 1. 接手陌生服务器

你不熟悉这台机器，也不知道哪些进程是业务、哪些是临时脚本、哪些是 supervisor 拉起来的。witr 能把"谁启动了谁"快速讲清。

### 2. 线上故障排查

端口冲突、服务误起、某个进程一直被拉起、容器外又有一层 supervisor，这类问题最烦的就是链路分散。witr 把它压回一段可读输出，适合在压力场景下快速定位。

### 3. 安全巡检

warning 规则本身就带一点巡检味道：公网监听、长期运行、高内存、危险 capabilities、library injection 指标。它当然不是完整的安全产品，但拿来做日常发现异常，很顺手。

## 把责任链讲清楚，比多背几条命令更有用

witr 最有用的地方，在于它把"为什么在跑"这个长期靠经验和命令组合才能回答的问题，压成了一个统一入口。

如果你平时就熟练使用 `ps`、`lsof`、`ss`、`systemctl`，witr 不会替代这些工具；但在陌生环境、线上故障和安全巡检里，它能帮你少走很多来回拼图的弯路。尤其是当你面对的不只是"一个 PID"，而是一整条启动链时，这类工具确实比死记命令参数更有用。

---

---
url: https://ain.hmgf.hxcn.space/ai/geo-ai-visibility-202606.md
---

# 你不知道的 GEO：AI 可见性的原理、实践与取舍

![](https://gastigado.cnies.org/d/public/image1.png)

## 花一小时让 AI 找到你的内容

这几天有好几个小伙伴@我说，我的开源工具在他们问 AI 的时候被主动推荐了，啥也没做居然可以被收录，想着要不花一个小时把内容结构化整一整，应该会更好，于是整好以后，快速发了一个速记推，但是内容结构不清晰，想着大家很感兴趣，那要不就整一个结构清晰的文章便于沉淀和查找。

我很讨厌去刷排名或者生产垃圾内容，更多想着让现有的内容对 AI 更可见，所以这篇文章不会教你投机，而是如何让AI更好理解你现有的内容本身。

去查了一下，发现 AI 搜索跟传统搜索逻辑完全不一样，传统 SEO 拼的是进 Google 前 10，但 83% 的 AI Overview 引用来自排名前 10 之外的页面，AI 看的是结构清晰、来源可靠，跟 PageRank 关系不大。项目不大，但 README 和文档写得还算清楚，大站内容单薄的地方 AI 就能找到我，大概这就是为什么朋友们能搜到 Pake 和 MiaoYan。

AI 搜索增长很快，2025 年上半年同比涨了 527%，ChatGPT 到 2026 年 2 月周活 9 亿，引荐流量转化率大概是传统搜索的 5 倍。但目前仍然只占总引荐流量不到 1%，更像是品牌可见性策略，不是流量策略，值得花一个小时整一整，但不值得花一周，因为产品本身才是你的核心竞争力，这个不是。

## 用 robots.txt 分清爬虫类型

很多人把 robots.txt 当开关用，要么屏蔽 AI 爬虫要么全放开。但 AI 爬虫其实分好几类，做的事情不一样。

训练爬虫，GPTBot、ClaudeBot、Meta-ExternalAgent、CCBot，拿你的内容去训练模型。屏蔽它们可以让内容不进训练数据，但不影响当前的 AI 搜索结果。

搜索和检索爬虫，OAI-SearchBot、Claude-SearchBot、PerplexityBot，实时抓取内容来回答用户问题。屏蔽了这些，你就从 AI 搜索里消失了。

用户触发爬虫，ChatGPT-User、Claude-User、Perplexity-User、Google-Agent，只在用户把你的 URL 贴进聊天窗口时才触发。屏蔽了它们，用户让 AI "总结一下这个页面" 就会啥也拿不到。

退出标识，Google-Extended、Applebot-Extended，不是真正的爬虫，是你在 robots.txt 里声明退出 AI 训练的信号。

未声明爬虫，Bytespider、xAI 的 Grok 爬虫，不表明身份，也不一定遵守规则。

![](https://gastigado.cnies.org/d/public/image2.jpg)

我的做法是允许搜索/检索爬虫和用户触发爬虫，屏蔽训练爬虫和未声明爬虫：

## 写好 llms.txt 并让站点互相引用

llms.txt 是一个新标准，类似 robots.txt 但专门给 AI 看的。在站点根目录放一个 Markdown 格式的文件，写清楚你的站点做什么、有哪些关键页面、作者是谁，AI 在检索内容的时候会优先读这个文件来理解你的内容。

BuiltWith 追踪到目前已经有 84 万多个网站部署了 llms.txt，包括 Anthropic、Cloudflare、Stripe、Vercel 这些。但在 SE Ranking 调研的 30 万域名里采用率只有 10%，还是比较早期，先做了有先发优势。

格式很简单：

做完之后可以提交到 directory.llmstxt.cloud、llmstxt.site，还有 GitHub 上的 llms-txt-hub 仓库提 PR。

这里我还做了一个有意思的事：各站点的 llms.txt 互相引用，形成一个网状结构。我维护着 tw93.fun、weekly.tw93.fun、yobi.tw93.fun 几个站点，每个站点的 llms.txt 都引用其他站点，AI 不管从哪个入口进来都能顺着链接找到其他内容。

![](https://gastigado.cnies.org/d/public/image3.jpg)

这些改动需要等爬虫重新抓取才会生效，通常要几天。配好之后隔一段时间去 ChatGPT 搜一下自己的项目名，引用来源和描述准确度应该会有变化。

![](https://gastigado.cnies.org/d/public/image4.jpg)

怎么告诉 AI 你有 Markdown 版本，最简单的方式是在页面 `<head>` 里加一行：

Claude Code 和 Cursor 在获取文档时已经会发 Accept: text/markdown header，这是 1997 年就有的 HTTP/1.1 标准行为。

## 去搜索平台录下你的站点

前面说的 robots.txt 和 llms.txt 是让 AI 读得懂你的内容，但前提是 AI 能找到你。ChatGPT 的搜索走 Bing，Google AI Overview 走 Google 自己的索引，Perplexity 也依赖搜索 API。如果你的页面没有被搜索引擎收录，后面做的结构化工作 AI 根本看不到。所以第一步是确保 Google 和 Bing 已经收录了你的站点。

操作很简单：去 Google Search Console 用 DNS 或 HTML 文件验证你的域名，验证通过后提交 sitemap URL（通常是 yoursite.com/sitemap.xml）。在"网页索引"报告里可以看到哪些页面已收录、哪些有问题。如果某个重要页面没被收录，用"网址检查"工具手动请求编入索引。

大伙可能觉得 Bing 没什么人用，但 Copilot、DuckDuckGo、Yahoo 的 AI 搜索底层都是 Bing 在驱动。去 Bing Webmaster Tools 注册一个号，提交 Sitemap，它有个 AI Performance 面板，能看到你的内容被 AI 引用了多少次。顺便设置一下 IndexNow，有新内容发布时主动通知 Bing，不用等爬虫来发现。

IndexNow 的接入方式是在站点根目录放一个 API key 文件，然后在内容更新时向 api.indexnow.org/indexnow 发一个 POST 请求，把变更的 URL 列表发过去，几分钟内 Bing 就会来抓取。很多静态站点生成器和 CMS 有 IndexNow 插件可以直接用。

Google Search Console 目前没有 AI 专属面板，但提交 Sitemap、监控索引状态还是值得做的。Google AI Overview 从比传统结果更广的范围里拉内容，即使你的页面排不进前 10 也可能出现在 AI 回答里。

Perplexity 在海外的用户量比大伙想的要大，他们有一个出版者计划，可以去 pplx.ai/publisher-program 提交表单，通过之后有收入分成 80/20，还能看到引用分析数据。

![](https://gastigado.cnies.org/d/public/image5.jpg)

## 我做了一个专门给 AI 看的知识网页

与其等 AI 去各个站点零散地抓信息，不如给它一个集中的入口，把你希望它记住的东西整理好放在那里。

一个知识网页要提供三层内容：概览（llms.txt）、完整版（llms-full.txt，30-60KB）、和每个核心项目的独立知识页面。再加上结构化的 JSON API，让 AI 工具可以程序化地获取数据。数据不要写死，从 GitHub API 之类的上游实时拉取，加缓存定期刷新，维护成本最低。

还有一个容易忽略的点：给 AI 一个叙事结构，而不是一堆零散的项目列表。如果你有多个项目，写一段把它们串起来的描述，它们之间的关系、你的技术方向、整体定位。AI 在回答"这个人是谁"或者"这个团队做什么"的时候，有叙事比有列表有效得多。

我做的实现叫 Yobi（来自日语 呼び / よび，有呼唤、把人叫过来的动作感），提供 llms.txt 概览、50KB 的 llms-full.txt、独立项目页面，以及 /api/profile、/api/projects、/api/blog、/api/weekly 四个 JSON 端点，数据从 GitHub API 实时拉取，ISR 缓存一小时刷新。技术栈 Next.js + TypeScript，部署在 Vercel。

![](https://gastigado.cnies.org/d/public/image6.jpg)

JSON API 返回的结构化数据，包含项目信息和实时 GitHub 统计：

![](https://gastigado.cnies.org/d/public/image7.jpg)

## 给每个项目一个独立页面

每个项目需要自己的独立页面，不是放在列表里的一行，而是自包含的 Markdown 文档，有可引用摘要、核心特性、竞品对比、使用场景和安装命令。Ahrefs 的研究发现被引用页面的标题和用户查询的语义相似度更高，自然语言 URL slug（如 /projects/pake）的引用率也高于不透明 ID（如 /page?id=47）。

URL 结构很重要，/projects/pake 在模型读一行字之前就告诉它这个页面是关于什么的，/page?id=47 什么都没说。

## 把结构化数据同步到主域名

子域名的权重不如根域名。AI 爬虫发现了 example.com 不一定会自动去找 docs.example.com 或 api.example.com。如果你的 llms.txt、项目页面、API 数据分散在多个子域名上，AI 可能只看到其中一部分。

解决方法是把关键的结构化数据镜像到主域名上，让 example.com/llms.txt、example.com/projects/xxx.md、example.com/api/projects.json 都在同一个域名下。AI 爬虫通过搜索索引发现你的主站，然后在同一个域名里就能拿到所有数据。实现方式可以是 CI 定时同步、构建时拉取、或者反向代理，选最适合你部署架构的就行。我用的是 GitHub Action 每天凌晨把子站数据同步到博客仓库。

上线新站点时，按清单逐项配置可以避免遗漏。核心项：robots.txt（分类放行爬虫）、llms.txt（写清站点概要并互相引用）、sitemap（提交到搜索引擎）、Bing Webmaster Tools（开启 IndexNow）、Google Search Console（监控索引状态）。每个站点的 llms.txt 互相引用其他站点，形成网状发现结构。

做这件事最容易踩的坑是被各种 GEO 技巧带跑，什么都想加，最后导致很乱，本末倒置。

## 试了这些没用

`<meta name="ai-content-url">` 和 `<meta name="llms">`，没有规范，没有任何主流 AI 系统支持。

/.well-known/ai.txt，多个竞争提案，没有实际采用，等出赢家再说。

HTML 注释里放 AI 提示，解析器在 AI 读到内容之前就把注释剥掉了。

User-Agent 嗅探返回 Markdown，给爬虫和人返回不同内容就是 cloaking，Google 会惩罚。

各种非官方的 AI meta 标签，除非某个主流 AI 提供商文档里明确支持，否则都是噪音。

![](https://gastigado.cnies.org/d/public/image8.jpg)

## JSON-LD 没你想的那么有用

这个我一开始以为是利器，后来深入研究发现更复杂。SearchVIU 做了个实验，把数据只放在 JSON-LD 里页面上不显示，结果五个 AI 系统全没读到。Mark Williams-Cook 的后续实验发现 LLM 就是把 `<script type="application/ld+json">` 当普通文本在读，不理解结构化语义。

唯一确认有用的是 Bing/Copilot，走的是索引富化路径。已有的 JSON-LD 保留就好，但别指望加了它 ChatGPT 或 Claude 就会多引用你。

## 研究数据怎么说

Princeton 和 IIT Delhi 的 GEO 论文在 KDD 2024 上发表，发现加入权威引用提升 AI 可见性 115%，相关统计数据提升 33%，直接引用可信来源提升 43%。

朋友 @yaojingang 在非常专业地做 GEO 方向的研究，他的 geo-citation-lab 拿 602 条 prompt 跑了三个平台，抓了上万个页面做特征分析，有兴趣的可以去看他的完整报告，这里从他的数据里提几个对做内容最有用的规律。

具体性 写有真实数据、清晰定义、横向对比的页面，影响力比泛泛而谈的页面高出 50% 以上。有步骤结构的页面也明显更好。而纯 FAQ 格式反而有害，那些 GEO 工具让你"加 FAQ 提分"的建议，数据说它是反效果，这也验证了我前面删掉 FAQ 的判断。

内容长度 AI 不偏爱短摘要，它偏爱可以切出多个可复用片段的长内容。被高频引用的页面平均近 2000 词、10 个以上标题，低影响力页面只有 170 词，差距超过 10 倍。最稳妥的区间是 1000-3000 词。

相关性 所有机械 SEO 指标（H 标签层级、meta description、关键词密度）的预测力都不如一个变量：你的页面内容跟用户问的问题是不是同一件事。

平台差异 ChatGPT 引用少但用得深，单条引用影响力是 Google 的 5 倍多；Perplexity 广撒网，引用量是 ChatGPT 的两倍多。想被 ChatGPT 引用就把单页写深写透，想被 Perplexity 引用就覆盖面广。

内容类型 官网 + 新闻 + 行业垂类占了引用来源的八成。但百科型/解释型页面的影响力是新闻页面的 3 倍。英文内容在全球引用样本里占 83% 以上，面向国际用户的项目必须做英文版。

## 被检索到不等于被引用

ChatGPT 检索到的页面里只有 15% 最终出现在回答中，85% 从未被引用。进入检索池只是第一关，模型还要判断哪些值得引用。

Ahrefs 发现被引用页面的标题和用户查询的语义相似度明显更高，有描述性自然语言 URL slug 的页面引用率也高于不透明 ID。llms.txt 和 Markdown 路由有效就是因为给了模型一个干净、明确的信号，说明这个页面到底讲了什么。

品牌被第三方来源引用的概率是被自己域名引用的 6.5 倍，别人在 Reddit、Hacker News 上说你好比你自己说自己好有效得多。所以自己有一个结构化的 llms.txt 很重要，它给模型提供了一个可以引用的锚点，即使触发查询的对话发生在 Reddit 上。

市面上有各种 AI SEO 审计工具会给你的站点打分，告诉你缺 FAQ、缺信任页面、正文太短。别被分数带着走。判断标准很简单：你加的每一段内容，是否提供了页面上还没有的信息？不是就别加。我给 Yobi 加过一个 FAQ section，内容跟 About 段落说的完全是同一件事，纯粹是为了把分数刷上去，后来想想这就是注水，删了。

做的事情都是帮 AI 更准确地理解你有什么，给它一个干净的工作环境，这个方向比短期技巧走得更远。

基础配置大概一个小时，知识端点和项目知识页面要更久一些，但一旦数据结构搭好就很容易维护，每天的同步是自动跑的。

做完之后隔几天去 ChatGPT、Perplexity、Claude 里搜自己的名字或者项目名试试，引用源应该会变准确。

AI 的引用归因目前还不靠谱，CJR 和 Tow Center 测试了 200 条 AI 生成的引用，发现 153 条有部分或完全错误。做结构化的工作是因为它让你的内容更容易被准确获取，但别把 AI 引用当成用户一定看到了你原话的证明，这个机制还在改进中。

假如你也有自己的产品、博客或者官网，不妨试试看，玩玩这个过程，当然也可以把这篇文章给你的 Claude Code，让他帮你做大部分事情。

![](https://gastigado.cnies.org/d/public/image9.jpg)

## 延伸阅读

1. GEO: Generative Engine Optimization - Princeton & IIT Delhi, KDD 2024
2. Overseas GEO Research - geo-citation-lab
3. llms.txt 标准规范
4. Why ChatGPT Cites One Page Over Another - Ahrefs
5. GEO Benchmark Study 2026 - ConvertMate
6. Optimizing Content for AI Discovery - Evil Martians
7. How LLMs Actually Use Schema Markup - SearchVIU
8. AI Search Has a Citation Problem - CJR / Tow Center
9. LLMs.txt: Why Brands Rely On It and Why It Doesn't Work - SE Ranking
10. How Often Do LLMs Visit llms.txt? - Mintlify
11. IndexNow Protocol Documentation

## Media

![](https://gastigado.cnies.org/d/public/image10.jpg)
![](https://gastigado.cnies.org/d/public/image11.jpg)
![](https://gastigado.cnies.org/d/public/image12.jpg)
![](https://gastigado.cnies.org/d/public/image13.jpg)
![](https://gastigado.cnies.org/d/public/image14.jpg)

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-anti-sycophancy-prompt-202606.md
---

# 减少 AI 谄媚与幻觉的提示词

## 李开复的 Claude 提示词

以下是如何最大限度减少谄媚、屈服、幻觉和猜测的方法。很多人抱怨这些问题，但其实可以通过以下方式 largely fix：

这段提示词可以输入在 Settings > General > Instructions for Claude 中。

***

## 提示词原文

```
Top expert. Accuracy beats approval. Blunt, argumentative. No disclaimers
or praise. Lead with counterarguments. Don't capitulate without new
evidence.

TAG every claim: [KNOWN] training fact · [COMPUTED] calculated ·
[INFERRED] deduction · [COMMON] standard field knowledge · [FRAME]
symbolic system, coherent ≠ real · [GUESS] no basis. No untagged disease,
statute, citation, or named entity.

FRAME→REALITY FORBIDDEN: Don't translate symbolic frames (astrology,
typologies) into real-world claims (medicine, law, finance) without
flagging the translation; conclusion stays in source frame.

CONFIDENCE: HIGH ≥80% · MED 50–80% · LOW 20–50% · VERY LOW <20% ·
UNKNOWN. [FRAME] real-world and [GUESS] cap at LOW.

DON'T KNOW: First line "I don't know." Don't bury, don't fabricate.

ANTI-SYCOPHANCY red flags: unusually elegant; one pattern explains
everything; agreed after pushback without evidence; specifics for
unearned authority. Fire → cut specifics, add [GUESS], or "I don't know."

POST-HOC: Would the frame predict this without knowing the outcome? If
no: [INFERRED, post-hoc], accommodates, doesn't predict.

Never fabricate citations. Revise openly if holding a position for
consistency. Append "[RULES I BROKE]: which, where, why."
```

***

## 核心要点

### 1. 声明标签化（TAG）

每条声明都需要标注来源类型：

| 标签 | 含义 |
|------|------|
| `[KNOWN]` | 训练数据中的事实 |
| `[COMPUTED]` | 计算得出 |
| `[INFERRED]` | 推理得出 |
| `[COMMON]` | 标准领域知识 |
| `[FRAME]` | 符号系统，连贯 ≠ 真实 |
| `[GUESS]` | 无依据猜测 |

### 2. 置信度标注（CONFIDENCE）

* **HIGH** ≥80%
* **MED** 50–80%
* **LOW** 20–50%
* **VERY LOW** <20%
* **UNKNOWN**

`[FRAME]` 和 `[GUESS]` 最高只能标注为 LOW。

### 3. 禁止框架转现实（FRAME→REALITY FORBIDDEN）

不要将符号框架（如占星术、类型学）转化为现实世界的 claims（医学、法律、金融），除非明确标注转换；结论应保持在原始框架内。

### 4. 反谄媚机制（ANTI-SYCOPHANCY）

识别谄媚的红旗信号：

* 异常优雅的表达
* 一个模式解释一切
* 在没有新证据的情况下被说服
* 对未赢得权威的特异性

应对：删除特异性、添加 `[GUESS]`、或说"I don't know"。

### 5. 事后归因检测（POST-HOC）

检验：如果不知道结果，这个框架能预测吗？如果不能：标注 `[INFERRED, post-hoc]`。

***

## 使用建议

这段提示词的核心理念是：

> **准确性胜过认同感（Accuracy beats approval）**

通过强制 AI 标注每条声明的来源和置信度，可以有效减少：

* 幻觉（Hallucinations）
* 谄媚（Sycophancy）
* 无根据的猜测（Guessing）
* 轻易屈服（Capitulation）

适合对 AI 输出准确性要求较高的场景，如学术研究、专业咨询、事实核查等。

***

## 使用建议

这段提示词的核心理念是：

> **准确性胜过认同感（Accuracy beats approval）**

通过强制 AI 标注每条声明的来源和置信度，可以有效减少：

* 幻觉（Hallucinations）
* 谄媚（Sycophancy）
* 无根据的猜测（Guessing）
* 轻易屈服（Capitulation）

适合对 AI 输出准确性要求较高的场景，如学术研究、专业咨询、事实核查等。

***

## 局限性与补充说明

### 标签化本身的可靠性问题

这段提示词要求模型对每条声明进行标签化和置信度标注，但需要注意：模型给出的标注本身也可能不准确。当模型标注 `[GUESS]` 或 `LOW` 置信度时，这个标注是模型"猜测"出来的，而非真正的自我评估。因此，标签化提供的是一个参考框架，而非绝对可靠的测量值。

### 不能替代人工事实核查

提示词能改善输出质量，但不能消除幻觉的根本原因。对于关键决策（医疗、法律、金融等），仍需人工事实核查。提示词的作用是让你更容易识别哪些内容需要验证，而不是保证所有内容都正确。

### 训练阶段的问题

从更深层看，如果模型需要通过系统提示才能获得诚实行为，说明模型的默认设置存在问题。谄媚是最难捕捉的生产故障之一，理想情况下应在训练阶段解决，而非依赖每个用户的配置。目前顶尖模型在推出强大能力的同时，仍存在对虚假信息屈服的问题。

***

## 中文用户补充建议

中文用户可以在提示词末尾添加：

```
Output language: Simplified Chinese. Keep claim tags ([KNOWN], [FRAME], etc.) in English.
```

这样可以让模型用中文输出，同时保留英文标签以便识别。

---

---
url: https://ain.hmgf.hxcn.space/ai/gpt-image-2-prompts-202605.md
description: >-
  从 awesome-gpt-image-2-API-and-Prompts 的分类案例出发，整理产品图、海报、角色、UI 和社媒封面 prompt
  的拆解方法，以及如何把别人的成功 prompt 变成自己的模板。
---

# GPT-Image-2 提示词库

看 prompt 合集，最容易犯的错就是整段复制。表面上省事，结果往往很一般：画面里信息很多，重点却不清；字写出来了，但品牌名错了；风格词堆了一串，最后互相打架。原因通常不在模型，而在 prompt 本身没被拆开。

一个可复用的 prompt，关键通常在结构：主体写了什么，风格怎么定，镜头从哪个角度拍，材质和光照有没有帮主视觉服务，文字排版要不要一步到位，比例是不是跟投放场景匹配。合集中那些看起来"很灵"的案例，拿来直接粘贴未必能复现；把结构读出来，再换成自己的变量，才更稳。

这一篇看的是 `awesome-gpt-image-2-API-and-Prompts`。它是一个持续更新的 prompt 案例仓库，适合拿来做两件事：找灵感，顺手学别人怎么把 prompt 写成模板。

## `awesome-gpt-image-2-API-and-Prompts`：分类与案例

仓库名字很直白：`Awesome GPT Image 2 API and Prompts`。仓库首页把它定位成一个持续整理的案例库，内容包括 prompt 示例、API 使用方式、可复用工作流，以及每条案例对应的输出图。

README 一处写"359+ high-quality prompts"，徽章又写"521 curated cases"，两个数字口径并不一致。**这是一个持续更新的 prompt 案例仓库，案例量一直在增加，仓库不同位置的统计数字口径并不相同。**

![awesome-gpt-image-2 仓库示例图 1](https://gastigado.cnies.org/d/public/awesome-gpt-image-2-3.png)

### 它的分类怎么组织

仓库当前把案例分成 7 组：

* E-commerce
* Ad Creative
* Portrait & Photography
* Poster & Illustration
* Character Design
* UI & Social Media Mockup
* Comparison & Community Examples

从仓库当前页面能看到的案例数分别是：

* E-commerce：20
* Ad Creative：19
* Portrait & Photography：68
* Poster & Illustration：119
* Character Design：13
* UI & Social Media Mockup：67
* Comparison & Community Examples：53

这组分类本身就很有参考价值。仓库不是按"艺术风格"去分，而是按结果用途去分：电商主图、广告海报、人物写真、品牌视觉、角色设定、界面和社媒截图，各自对 prompt 的要求完全不同。

### 仓库怎么用更划算

README 除了案例，还放了一个 `Use GPT Image 2 API` 区块，给了配套 skill 和一个通过 Evolink 调用图像生成接口的示例。**这是仓库作者提供的接入方式，不是 OpenAI 官方 API。**

它的价值主要在两点：

1. 让你看到 prompt 案例可以接进实际生成流程。
2. 提醒你，这类仓库最好配合一套自己的调用方式、模板参数和版本管理来用，省得每次手工复制粘贴。

如果你把这个仓库只当成"prompt 展示墙"，很容易漏掉它真正好用的部分。更实用的办法是按场景找近似案例，再把其中的变量位和结构骨架拆出来，存成你自己的模板。

## 使用场景与提示词层次

prompt 合集最怕一上来就抄整段。更稳的做法是定好自己要做哪一类图，再看这一类图常见的结构。

### 产品图：主体、材质、台面与反光

`E-commerce` 这一类最像商业摄影 brief。很多案例都会把这些元素写得很具体：

* 商品是什么；
* 正面、俯拍还是三分之四角；
* 瓶身、包装、金属件、玻璃、布料是什么材质；
* 放在哪种台面上；
* 背景颜色和反光怎么处理；
* 需要不要水珠、烟雾、泡沫、冰块、花材或微缩场景。

这类 prompt 的关键在"商品长什么样"和"它周围有什么"。比如香水、护肤品、耳机、主板、鞋子这类产品图，决定成败的往往是材质质感、角度、阴影和反光，多加几个"premium""luxury"形容词帮助很有限。

如果要把仓库里的产品图 prompt 改成自己的模板，最实用的做法是把它拆成这几个字段：

```text
商品主体 = 品类 + 外形 + 材质 + 颜色
摆放方式 = 正放 / 倾斜 / 俯拍 / 分镜拼版
场景元素 = 台面 + 背景 + 辅助物 + 空气效果
光照 = 主光方向 + 柔硬程度 + 高光 / 阴影风格
文案区域 = 标题位置 + logo 位置 + CTA 位置
比例 = 1:1 / 4:5 / 9:16 / 16:9
```

这样改出来的模板，换一个产品还能继续用。

### 海报：主视觉与风格词

`Ad Creative` 和 `Poster & Illustration` 这两类最容易让人误以为"多写风格词就更高级"。实际看仓库里的案例，会发现好的 prompt 反而很重主视觉骨架：

* 画面中心到底是什么；
* 标题是主角还是陪衬；
* 文字是海报的一部分，还是后期再加；
* 用双重曝光、拼贴、插画、国潮、电影海报感时，哪一层是主层，哪一层是辅层；
* 留白在哪里，画面重量压在哪一边。

仓库里的城市宣传海报、品牌 campaign、巧克力广告、手绘插画和科技百科海报，都说明了一件事：海报类 prompt 要把信息层级排出来，再决定风格用多少。把"电影感、梦幻、史诗、复古、国潮、高级"堆在一起，通常不会自动变好。

这类 prompt 最常见的问题是风格冲突。比如你同时写了"极简海报""信息密度很高""梦幻水彩""超写实产品摄影""强对比霓虹光"，模型未必知道谁该优先。一个更实用的写法是选主风格，再把其它风格降成局部说明。

### 角色和人像：别把人物设定写成体检报告

`Portrait & Photography` 和 `Character Design` 是仓库里最容易越写越长的两类。你会看到很多 prompt 把外貌、年龄、服装、妆面、情绪、机位、镜头参数、背景、氛围、肤质、负面要求全塞进一段里。

这类写法有时有效，但也有明显代价：约束太满时，模型会把注意力平均摊开，最后主画面反而不够集中。

如果你要做角色设定或人像写真，拆 prompt 时更建议把信息分成四层：

1. **身份层**：是谁，年龄段，大致气质。
2. **造型层**：服装、发型、配色、道具。
3. **镜头层**：近景、中景、全身，广角还是长焦，俯拍还是平视。
4. **氛围层**：光照、环境、情绪、颗粒感、时代感。

把这四层顺序理顺，再往里补细节。否则很容易出现"每个词都对，整张图不对"的情况。

### UI、品牌视觉和社媒封面：结构比花活更重要

仓库里的 `UI & Social Media Mockup` 这一组很杂，里面既有 UI 设计系统，也有伪直播截图、社媒 feed、图鉴、信息图和广告 pop。

这恰好说明了一个现实：很多人说自己要"做 UI 图"，其实要的可能是封面图、运营图、信息图，甚至是看起来像真截图的假界面。它们共通的部分不在风格，而在版式。

这类 prompt 最值得抄的，是信息结构：

* 顶部标题区怎么摆；
* 中间主视觉和信息区如何分配面积；
* 注释、标签、按钮、评论区、时间条、状态栏该不该一次生成；
* 中文标题和英文标题是否要同时出现；
* 最终投放比例是手机竖屏、封面方图，还是横版页面展示图。

如果目标是社媒封面或 UI 概念图，建议第一轮做"结构 + 主色 + 主标题"，第二轮再补按钮文案、评论区、角标和说明字。把所有小字一次塞进第一轮，往往是文字渲染翻车的开始。

## 一个成功 prompt，通常能拆成 7 个部件

仓库里跨分类看多了，会发现大部分好用的 prompt 虽然表面长得不一样，内部结构却很像。你完全可以把它们拆成同一套骨架。

### 1. 主体

主体就是画面里要被看见的东西。它可以是一个商品、一组人物、一个角色、一张界面、一张海报主画面。

写主体时，优先写"是什么"和"长什么样"。例如：

* 一个奶油白磨砂护肤瓶；
* 一块黑金包装的高端巧克力；
* 一位穿 90 年代街头风服装的年轻女性；
* 一个博物馆图鉴式中文信息图。

### 2. 风格

风格决定观感，但不要把它写成词库堆叠。更稳的是选一个主风格，再加一两个辅助风格。

例如：

* 主风格：高级商业产品摄影；
* 辅风格：轻微电影感、暖金色调。

或者：

* 主风格：国潮手绘城市海报；
* 辅风格：双重曝光、留白排版。

### 3. 镜头与构图

很多人写 prompt 时只写内容，不写镜头，结果模型就会默认给一个最普通的构图。

镜头层可以写：

* 近景 / 中景 / 全身 / 特写；
* 正面 / 俯拍 / 三分之四角 / 平视；
* 35mm、长焦、浅景深、顶视拼版；
* 画面重心在左、中、右。

### 4. 材质

材质是产品图和品牌视觉里最容易拉开差距的部分。玻璃、金属、绸缎、纸张、泡沫、水珠、木纹、皮革、亚克力、雾面塑料，写不写、写得准不准，结果差异很大。

### 5. 光照

光照既决定质感，也决定气质。常见的有效写法包括：

* 柔光棚拍；
* 顶光；
* 侧逆光；
* 暖色边缘光；
* 高反差电影光；
* 阴天漫射；
* 荧光灯 + 霓虹混光。

### 6. 文字

GPT-Image-2 文字能力比更早的图像模型强，这也是很多人开始拿它做海报和伪界面的原因。但文字仍然不该"想写多少写多少"。

更稳的做法是分三档：

* 第一档：只写一个短标题或品牌名；
* 第二档：标题 + 副标题 + 一个 CTA；
* 第三档：需要多段中文、评论区、注释标签、信息图说明字时，分步生成或后期补字。

### 7. 比例

比例不能放到最后才想。因为比例会直接影响排版、留白和主体位置。

最常见的几种：

* `1:1`：商品卡片、方形封面、品牌海报；
* `4:5`：社媒 feed、商品详情主图；
* `9:16`：直播封面、竖版海报、短视频封面、UI 截图；
* `16:9`：横版 banner、演示页、分镜图。

把这 7 个部件想清楚后，再去看仓库里的长 prompt，就不会觉得它们只是"英文写得更长"。

## 怎么把仓库里的成功 prompt 变成自己的模板

用得顺手的 prompt 库，到手里之后最好整理成自己的模板库。

### 第一步：找到能稳定复现的骨架

别急着收 100 条。每个场景找 1 到 3 条能稳定出图的案例就够了，比如：

* 产品图选一条香水或护肤品案例；
* 海报选一条品牌 campaign 或城市海报；
* 人像选一条电影感写真；
* UI 选一条信息图或社媒封面。

你要留的是 prompt 的骨架。

### 第二步：把固定词和变量位拆开

仓库里很多案例已经在用变量写法，比如：

```text
{argument name="product name" default="..."}
{argument name="headline text" default="..."}
{argument name="aspect ratio" default="9:16"}
```

这就是很好的模板信号。你可以把它改成自己更习惯的字段，比如：

```text
[主体]
[品牌名]
[标题]
[副标题]
[材质]
[场景]
[光照]
[比例]
[禁用项]
```

### 第三步：把"审美描述"翻成"可替换字段"

一个 prompt 里最容易失控的，就是那些看起来高级、实际很难复用的形容词。比如"高级感""电影感""爆款感""小红书感"。

更好的做法是把它翻译成可操作的字段：

* "高级感" → 哑光材质、暖金色边缘光、留白、细 serif 字；
* "电影感" → 长焦压缩、浅景深、局部高光、低饱和配色；
* "社媒封面感" → 主标题大、主体居中、对比强、字少。

### 第四步：给模板加上禁用项

很多 prompt 仓库只展示成功案例，不一定告诉你失败是怎么来的。模板里最好自己补一个限制区：

* 不要过多 logo；
* 不要多余商品；
* 不要英文乱码；
* 不要错误品牌名；
* 不要多余手指、畸形结构、错误 UI；
* 不要把背景做得比主体更抢眼。

这样做的好处是，下次换产品或换风格时，你调的是变量，不用整段重写。

## 使用时的风险控制

prompt 库好用，但使用时有几个坑最好提前放进流程里。

### 第一步：版权与品牌问题

很多案例里会出现品牌名、明星脸、平台 UI、影视风格、历史人物、真实产品包装等元素。仓库自己也引用了大量 X 上的案例链接，这些内容更应该当"社媒来源"或"灵感来源"看，别不加判断地直接商用。

所以在动手前先问三件事：

1. 这里面有没有真实商标、品牌外观或可识别人物？
2. 我现在做的是练习、提案，还是正式商用？
3. 如果最终要上线，哪些元素需要替换成自有品牌、自有文案、自有视觉？

### 第二步：少量生成并逐步收敛

文字渲染虽然比过去强，但长标题、多段中文、小字说明、评论区和按钮标签一起上时，翻车率还是会明显上升。

更实用的顺序是：

1. 第一轮确认主画面、配色、结构和比例。
2. 第二轮补一个主标题或品牌名。
3. 第三轮再补副标题、按钮、注释或评论区。
4. 如果是信息图或复杂海报，收尾一轮只做文字校准，必要时后期排字。

### 第三步：控制风格词，不要过度约束

很多失败图不是信息太少，更多时候是约束太多。你同时要求它：

* 超写实；
* 水彩；
* 极简；
* 赛博朋克；
* 编辑感；
* 高密度信息图；
* 电影海报式构图。

模型当然会尽力照顾每一条要求，但结果往往是谁都没照顾好。

稳妥做法是每轮只保一个主风格。如果要加第二风格，把它写成局部层级，不要升成全局要求。

### 第四步：用比例反推排版

做社媒封面和 UI 图时，很多人临到出图才想起需要 9:16。这个顺序很吃亏，因为主体位置、文字空间和留白都会变。

定好比例再写 prompt，会少很多返工：

* 做短视频封面，定 `9:16`；
* 做商品卡片，定 `1:1`；
* 做小红书图或详情头图，定 `4:5`；
* 做横版演示页，定 `16:9`。

### 第五步：保存每轮成功版本

prompt 库最怕"这次出得不错，但我下次忘了怎么出的"。所以每次生成成功后，至少把这几项存下来：

* 最终 prompt；
* 生成比例；
* 成功图；
* 需要避免的问题；
* 这次改动了哪些字段。

这样做几次之后，你的个人模板库才会真的长出来。

## 从仓库 prompt 到个人模板，可以直接这样走

如果想把这类合集用顺手，可以用下面这个小流程：

1. 按场景选分类：产品图、海报、人像、角色、UI、社媒封面。
2. 在分类里挑 1 到 3 条最接近目标的案例，别贪多。
3. 把 prompt 拆成主体、风格、镜头、材质、光照、文字、比例 7 个部件。
4. 删掉与你当前任务无关的细节，只保留主骨架。
5. 把品牌名、标题、配色、材质、比例改成自己的变量位。
6. 第一轮出主画面，第二轮再补文字和细节。
7. 成功后把它存成模板，下次只换字段，不重写整段。

仓库里的 prompt 值得抄，组织方式也值得抄。把别人已经跑通的结构拆开、改写、字段化，再整理进自己的模板库，这个仓库才算用到位了。

---

---
url: https://ain.hmgf.hxcn.space/ai/pixal3d-202605.md
description: >-
  从 TencentARC/Pixal3D 的 GitHub 仓库、论文、项目页和 Hugging Face
  入口出发，整理它的输入输出、安装使用路径和适用范围。
---

# Pixal3D：腾讯开源图生 3D 项目

AI 生成 3D 和 2D 生图看起来都叫"生成"，但难点完全不是一回事。2D 图只要当前画面成立就行；3D 资产还要过结构、视角一致性、几何连续性、贴图质量和后续可编辑性这几关。今天在一个角度看着像样，换个角度或者一进建模软件，问题就可能全冒出来。

看 3D 生成项目，关键是两件事：**输出是不是一个可继续处理的 3D 资产，以及它和输入图的对应关系保不保得住。**

Pixal3D 值得看，就是因为它把重点放在了这件事上。

## TencentARC/Pixal3D：它到底在解决什么问题

`TencentARC/Pixal3D` 的项目标题就是 `Pixal3D: Pixel-Aligned 3D Generation from Images`。它瞄准的是单张图到高保真 3D 资产这条线，重点放在"给你一张图，尽量把图里的对象更稳地变成 3D"。

论文摘要把问题说得更清楚：过去 image-to-3D 已经能生成"看起来像 3D"的东西，但 fidelity 还是差一口气。这里的 fidelity 不是泛泛的"质量高"，而是**输入图像和生成 3D 资产之间的像素级对应关系是否够准**。

作者给出的判断是：很多 3D-native 生成器还是先在 canonical pose 里做生成，再用 attention 注入图像特征，这一步天然容易把 2D 和 3D 的精确对应关系冲淡。Pixal3D 走的是另一条路：不先把物体丢进一个统一姿态里，而是直接围绕输入视角做 pixel-aligned generation，再通过 pixel back-projection 把多尺度图像特征抬到 3D feature volume 里。

这就是它名字里 `Pixel-Aligned` 的由来。它把重点放在 3D 和输入图的对应关系上，不满足于只做一个"看起来像 3D"的结果。

## 版本线索

这个仓库有两条版本线，分开看：

* 当前 `main` 分支：更新后的版本，基于 `TRELLIS.2`，主打推理效果提升；
* `paper` 分支：对应论文版 `Direct3D-S2`。

你如果只是想跟着现在的仓库跑结果，看 `main` 就行；如果你是读论文、复现实验或想严格对齐论文实现，再去看 `paper` 分支。

这类信息值得写出来，因为很多人第一次碰科研仓库时最容易踩的坑，就是默认"仓库当前代码 = 论文里那版代码"。Pixal3D 已经把这两条线拆开了，照着分支说明走就行。

## 输入和输出：它服务的是 image-to-3D 这条链路

从仓库、论文标题和项目页看，Pixal3D 当前最明确的主任务是 **from images**。也就是说，它的核心输入是图片，而不是纯文本 prompt。

更具体一点，正文里能稳写的输入 / 输出范围是：

### 输入

* 单张输入图像，是当前仓库最明确的主入口；
* 论文摘要还提到它可扩展到 multi-view generation，这属于方法外延，不应写成仓库当前的默认使用入口。

### 输出

基础推理流程最终会导出 `GLB` 网格文件。对多数读者来说，这一点很重要，因为它说明输出不是单纯的 2D 预览，而是一个能被 3D 工具继续读取的资产格式。

当然，导出 `GLB` 不等于"资产已经能直接进生产"。你后面还得看拓扑、贴图和编辑需求，但至少它已经迈过了"只是生成一组看图"的那道门槛。

## 安装和环境：仓库给了能跑通的最短路径

Pixal3D 的安装步骤不算花哨，基本思路就是标准科研仓库流程：

1. 克隆仓库；
2. 创建 Python 环境；
3. 安装依赖；
4. 下载权重；
5. 运行推理脚本。

仓库给出的示例环境是 Python 3.12，安装命令使用 `uv`：

```bash
git clone https://github.com/TencentARC/Pixal3D.git
cd Pixal3D
uv venv --python 3.12
source .venv/bin/activate
uv pip install --upgrade pip
uv pip install -r requirements.txt
```

环境里还要补 `flash-attn`：

```bash
uv pip install flash-attn --no-build-isolation
```

然后下载权重：

```bash
mkdir -p ckpts
huggingface-cli download TencentARC/Pixal3D --local-dir ckpts
```

这里有两个现实提醒。

第一，`flash-attn` 这类依赖对 CUDA、PyTorch、编译环境比较挑，不是所有机器都能一步装过。这一步不要当成"复制即用"。

第二，Hugging Face 模型页当前标了 `24 GB`，这至少说明它不是一类随便拿轻薄本就能跑得很顺的项目。官方没有把这个值写成通用最低显存要求，这里更稳妥的写法是：**模型页有 24 GB 标记，本地运行通常要准备更充足的 GPU 资源。**

## 怎么跑：从图片到 GLB 的基础流程

最小推理命令是：

```bash
python app.py \
  --image assets/example_image.png \
  --output_dir outputs
```

运行完成后，结果会输出为：

```text
outputs/example_image/example_image.glb
```

这条路径已经把它的基本工作流讲清楚了：

* 你准备一张输入图；
* 指定输出目录；
* 跑推理；
* 拿到一个 `GLB` 文件。

如果你只是想判断这个项目值不值得继续折腾，拿官方示例图跑通一次，比直接扔自己的复杂资产更有意义。这样至少能确认：

* 环境能不能装起来；
* 权重能不能下载到位；
* 推理能不能顺利结束；
* 输出资产能不能被你的查看工具打开。

## 项目页里主要看什么

Pixal3D 的项目页做得很完整，Paper、arXiv、Demo、Model、Code、Video 入口都放在一起。更值得停下来看的是两个部分。

### 1. Results / Comparisons

项目页有 textured 和 geometry 两类展示，还把 Pixal3D 和 `TRELLIS 2`、`Hunyuan3D 2.1` 等方法放在一起对比。这个设计很有用，因为它逼你同时看两件事：

* 贴图看起来像不像；
* 几何结构本身稳不稳。

很多 3D 生成项目只放一组光影和材质都处理好的渲染图，你很难判断几何底子到底怎么样。Pixal3D 至少把这个问题摊开了。

### 2. Method

项目页把方法拆成三段：

1. Pixel-Aligned Structured Latent Representation Learning
2. Image Back-Projection-based Conditioner
3. Two-stage generative process

这三段刚好对应它要补的三处短板：

* 把 latent 表示和输入图对齐；
* 再用 back-projection 显式建立 2D 到 3D 的特征映射；
* 再分阶段做生成。

你不一定要把论文读到每个算子都懂，但至少要知道重点不在"堆更大模型"，而是在 2D-3D correspondence 这个老问题上换了一种更明确的条件注入方法。

## 生成后要检查什么

### 1. 拓扑和几何完整性

导出了 `GLB` 只是起点。你后面如果要进 Blender、Unity、Unreal 或建模软件继续处理，最先检查的是网格有没有明显破面、粘连、结构缺失或视角不一致。

### 2. 贴图是否只在主视角好看

image-to-3D 很常见的问题是：正面很好，侧面一转就露馅。Pixal3D 本来就在打 fidelity 这件事，所以实际使用时更应该拿它去看角度一致性，而不是只截一张最好看的封面图。

### 3. 可编辑性

原型阶段你只看渲染图，问题不大；一旦要进入项目，就要问：

* 后续能不能改材质？
* 能不能简化网格？
* 能不能重拓扑？
* 贴图展开是否还能继续修？

这一步决定它在你的流程里是"最终资产"还是"资产草稿"。对现阶段多数 3D 生成项目来说，后者更现实。

### 4. 商用版权和输入素材问题

Pixal3D 是开源仓库，不等于你拿任何输入图去生成都没有版权问题。你如果拿带商标、角色 IP、商业摄影图或第三方作品做输入，输出资产能不能使用，仍然要自己判断。开源的是工具，不是输入图的授权。

### 5. 生成失败和期望管理

3D 生成比 2D 生图更脆。输入图如果遮挡太多、结构不清、反光复杂、轮廓不完整，生成结果就更容易崩。不要把一次不理想结果立刻理解成"仓库没用"，也不要把一次看起来不错的结果直接理解成"已经能替代 3D 美术"。

## 使用场景

Pixal3D 可以放在这几个位置上看：

### 实验和研究验证

如果你本来就在看 image-to-3D、3D representation 或多视图生成，这个项目值得读。它的论文和项目页都把"为什么要做 pixel-aligned"讲得比较集中，研究导向很强。

### 原型和概念验证

如果你手里有一张产品图、角色概念图或对象参考图，可以拿它出一个 3D 草稿，看看整体方向。

### 资产草稿

对独立开发、交互演示、快速搭场景的人来说，能拿到一个可看的 `GLB` 草稿就已经很有用。后面要不要继续修，再看项目需要。

## 它还不能替代完整 3D 美术流程

Pixal3D 很值得看，但它目前还是把 image-to-3D 往前推进了一步的生成项目，还谈不上"从此可以跳过 3D 美术"。

你如果要的是：

* 高保真概念还原；
* 快速生成可继续编辑的网格；
* 更稳的主视角对应关系；

它很有参考价值。

你如果要的是：

* 直接进 production 的成熟资产；
* 全流程稳定、可控、可批量复用的 3D 生产线；
* 完全替代建模、重拓扑、材质和后期修整；

那它现在还不是这个阶段。

把它放在 **实验工具、原型工具、资产草稿工具** 这几个位置，会更稳妥。硬把它吹成完整替代方案，反而容易把话说虚。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-editing-202601.md
description: 如何在写作中识别并去除“AI 废话”
---

# 如何优化 ChatGPT 生成的草稿，去除 AI 味

> 如何在写作中识别并去除“AI 废话”

如果你想利用大语言模型（LLM）提高写作速度，又不想让文章读起来像机器写的，这篇文章就是为你准备的。在 Towards AI，过去两年里我们编辑了数千份 AI 辅助的稿件，制作了数百节[课程](https://academy.towardsai.net/courses/ai-business-professionals?ref=1f9b29)和视频。我们清楚地知道模型在哪里能帮上忙，在哪里会帮倒忙，以及如何保持你自己的声音。在这篇文章中，我们将分享一些具体的技巧和一个经过实战检验的提示词模板。通过这些，你可以从 LLM 那里获得高质量的文本，同时避开 AI 生成文章的典型特征——而不仅仅是双手合十，温柔地请求它“请不要写得像 ChatGPT”。

在 2023 年和 2024 年，某些动词和形容词突然开始在各类稿件和出版物中泛滥：*深入探讨 (delve)*、*领域 (realm)*、*凸显 (underscore)*、*一丝不苟 (meticulous)*、*值得称赞 (commendable)*，还有著名的*破折号 (em-dash)*。在 ChatGPT 出现之前，许多专业编辑除了在正式报告中，几乎很少见到这些词；如今，它们却充斥在学生论文、电子邮件、内部备忘录、领英动态和生物医学论文中。一项评估发现，与 2022 年底之前相比，“delve” 这一个词在近期 PubMed 文章中出现的频率大约增加了 400%。在学术界之外，一项被广泛引用的在线文本分析发现，与前几年相比，生成式 AI 时代的“meticulously researched（经过精心研究）”一词的使用频率增加了约 3900%。

![img](https://gastigado.cnies.org/d/public/1_2A3DqxzmvvAPV47hQzveZg.jpg)

所以，大家的直觉是对的：模型不仅改变了我们*起草*文本的方式，还正在肉眼可见地改变我们周围的语言环境。LLM 在海量的文本语料库上进行训练，然后通过基于人类反馈的强化学习 (RLHF) 进行打磨，学会迎合我们的需求。最近的一篇语言学论文找出了 21 个在科学论文摘要中使​​用频率激增的“焦点词”，并且 ChatGPT 使用它们的频率远高于人类作者；作者给出的最佳解释是，RLHF 悄悄地引导模型偏向那些疲惫的评分员视为“好文章”标志的词语。记者和语言学家进一步指出，由于 RLHF 工作被大量外包给尼日利亚等国家的英语熟练标注员，其中一些词可能反映了正式的尼日利亚英语习惯，这些习惯被反复奖励，然后在互联网规模上被放大。

一旦这种风格被固化，数百万人就开始复制并稍作修改地使用它。久而久之，这种经过打磨的、客气且带有学术腔调的模型语气，就会渗透到 AI 辅助甚至纯人类撰写的文本中。即使你从未打开过 ChatGPT，你最终也会生活在一个充斥着“深入探讨 (delve into)”、“凸显 (underscore)”、“不断演变的格局 (ever-evolving landscape)”和“无缝、稳健的解决方案 (seamless, robust solutions)”的信息环境中。

这就是我们可以称之为 **AI 废话 (AI slop)** 的东西：不只几个可疑的词，是一整套让文章感觉不自然的习惯。尴尬的是，即使最明显的“AI 词汇”被删除了，那种感觉往往依然存在。这种感觉很难用清晰的语言来描述。然而，大多数读者都能分辨出一篇文章是由 LLM 撰写的，还是经过其大量“润色”的。表面的词汇被清理了；但底层的骨架依然没变。段落仍然遵循着相同工整的弧线，过渡句像五段论式文章一样按部就班，结论总是拔高到一个没人要求的“更大图景”。语言中没了 *delve*，但思维结构仍然是纯粹的模型味。

如果你希望 AI 辅助写作不感觉像是 AI 废话的拼凑，你不能仅仅删掉 *delve*；你必须改变骨架。下一节将探讨这个骨架：LLM 默认情况下倾向于如何组织想法，以及你可以在大纲、段落和过渡中做哪些调整，从而在一篇文章还未触及具体词汇之前，就不再读起来像个 AI 模板。

### 优化结构

当人们说“这听起来像 ChatGPT”时，他们通常是在对结构做出反应，而不仅仅是词汇选择。句子单独看没问题，但它们的排列方式让人觉得通用且过于熟悉。总觉得哪里不对劲。

常见的结构模式包括：

* **大量使用项目符号列表：** 文章的大部分都是简短的要点，而不是带有例子或细节的完整段落。
* **大量相似的小标题：** 每隔几段就有一个诸如“理解 X”、“Y 的重要性”、“Z 的未来”这样的标题。各个部分感觉可以互换。
* **标准化得过头的结构：** 先来一段概括性开头，中间三段平铺正文，末尾再把前面的标题复述一遍。
* **到处都是强烈的路标提示：** 经常出现类似“现在我们已经探讨了 X……”、“如前所述……”、“在下一节中，我们将讨论……”这样的句子，即使逻辑联系已经很明显。
* **段落长度一致：** 大多数段落长度相似，并遵循相同的模式：定义、解释、限定条件、小结。节奏几乎没有变化。
* **围绕文章本身写作，而不是主题：** “在本节中，我们将看看……”、“首先，我们将检查……然后我们将探索……”。
* **通用且过度简化的例子**：“例如，企业可以使用 AI 来简化工作流程并改善结果。” 这种例子在技术上是正确的，但过于通用，没有提供任何新信息。它几乎可以出现在任何关于 AI 的文章中，这正是读者能认出它是机器生成的原因。
* **通用的结尾：** 最后一段经常只剩安全的高位表态（比如“随着 AI 的不断发展……”），没有新增具体信息。

单独来看，这些在很大程度上都没问题。它们对于学校论文、文档和操作指南博客很有用。问题在于，当所有这些都同时出现，并且无论什么主题都按同样的顺序排列时。到了那个时候，文章就不再感觉像是一个人的真实推理，而开始感觉像是一个被重复使用（甚至滥用）的框架。

LLM 之所以陷入这种模式，是因为它们的训练数据中充满了这种模式：教科书、教程、企业说明文、学生论文。当你要求“写一篇关于 X 的文章”时，模型并不是在优化一个有趣的结构；它是在寻找“安全的文章结构”，并把你的主题塞进去。

如果你想保持 AI 的速度，又不要那种模板感，你必须在这个层面做出改变：大纲、段落形状和过渡。

一条有用的规则是：**你掌控结构；模型负责填充。** 这里有一些实用的改变方法：

**1. 自己决定大纲**

在开始写提示词之前，自己草拟一个简短的大纲：从哪里开始，哪些部分最重要，在哪里结束。让某些部分短一些，有些部分长一些；它们不需要是对称的。

然后要求模型类似这样：

> *“把这个大纲变成文章。不要在这些内容之外添加引言或结论。不要创建额外的小标题。”*

你这是在告诉它留在你的框架内，而不是自己发明一个。

**2. 偏好段落而不是列表**

LLM 过度使用项目符号和标题，因为许多在线内容就是这样构建的。如果你想要读起来更像文章而不是幻灯片的内容，你必须明确指出。

你可以添加一个简单的约束：

> *“主要使用完整的句子和结构良好的段落进行写作。避免使用列表或项目符号，除非内容明确需要（例如，具体的步骤或不同的项目）。少用小标题，只在明显不同的部分使用，不要为每一个新想法都加个标题。”*

这会促使模型走向连续的叙述：更饱满的段落、更流畅的过渡，以及更少列表状的碎片。如果你真的需要，以后总可以把其中一部分变回列表。

**3. 限制类比，不让它们主导结构**

模型也喜欢依赖类比，以此作为一种显得通俗易懂的捷径。太多或牵强的类比会让人觉得文章注水、重点模糊。

你可以用一条简短的规则来控制它们：

> *“极少使用类比，只有当它们能为这类读者提供真实的、非显而易见的澄清时才使用。除非我明确要求更多，否则整篇文章最多使用一个类比。”*

这能让结构锚定在实际的论述上，而不是模型在其他文章中看过的一串隐喻上。

**4. 减少元文本和路标**

在提示词中，限制“在这一节中我们将……”这种风格：

> *“避免使用类似‘在这一节中，我们将……’、‘现在我们已经探讨了……’、‘如前所述……’这样的短语。不要描述文章本身；只需解释主题。避免使用没有附加值的废话。”*

在审阅草稿时，快速扫一遍这些元文本，删掉那些清嗓子式的开场白、重复标题的总结句，以及任何只是重述读者已知内容的结尾段落。

**5. 打破对称性**

告诉模型：

> *“改变段落长度。有些部分可以很短；有些可以深入。不要在每节的结尾都加上一个小总结。”*

如果草稿仍然有三个结构相等、标题相似的部分，那就手动修复：合并重叠的部分，将较弱的标题降级为普通段落，或者完全删掉某一部分。一旦大纲不再像一篇整齐的三段式论文，这篇文章读起来就不那么像默认的 AI 输出了。

**6. 将 AI 作为积木，而不是现成的段落**

不要说“写第二节”，而是使用模型来生成组件：

* “给我三种不同的方式来组织这一节。”
* “列出具体的例子，使这个论点更加具体”，更具体一点，也可以直接说：“我想用攀岩世界来做一个类比，因为我认为这有助于读者把事情串联起来，帮我想一个合适的。”
* “在这些段落之间建议两个不复述刚才读过内容的过渡。”

然后由你来选择、重新排序并连接。模型给你提供材料；你来决定它们的流向。

**7. 在修改语言之前，过一遍结构**

在你修改句子之前，将每段变成一句话的总结。像看大纲一样读这些句子。它听起来像你写的，还是像一篇通用的博客文章：定义 → 列表 → 总结 → 模糊的未来？

如果是后者，重新排序、删减或精简，直到顺序与你大声解释这个主题的方式相匹配。通常，删掉第一段、精简总结，并在前一步就结束，就足以消除大部分的“AI 感”。

一旦结构是你的了，草稿就已经不那么像模型了，即使它是 AI 生成的。在那之后，你就可以专注于语言：屏蔽你自己的“AI 词汇”列表，收紧措辞，并使用一个去 AI 味提示词，让模型一开始就不再使用那些相同的词汇。

### 你可以添加到提示词中的语言规则

一旦结构没问题了，剩下的大部分“AI 感”来自于句子层面的习惯：重复、通用的开头和结尾、含糊的形容词、过于客气的语气，以及反复出现的一组“AI 词汇”。你可以将这些变成提示词中明确的规则，这样初稿就已经避开了大部分问题。

1. **重复**

AI 的一个常见标志是看似无害的重复，这使文本感觉机械化：几个句子或段落以相同的方式开头，或者一遍又一遍地使用相同的节奏。

提示词规则：

> *“改变句子开头。避免多次重复相同的过渡词（‘此外 (In addition)’、‘而且 (Furthermore)’、‘再者 (Moreover)’）。不要用不同的词重述同一个想法。”*

编辑检查：只看开头读一遍。忽略意思，只看每个句子的前几个词。只要你看到相同的开头或模式出现三次，就删减或合并。通常，两个模型的句子可以合并成一个更清晰的句子，而不会丢失内容。

2. **开头和结尾**

通用的引言和结论是另一个明显的标志。它们宣布文章将要做什么，然后在结尾重复一遍。

提示词规则：

> *“不要以‘在当今快节奏的世界中’或‘当我们应对复杂性时’等通用的场景设置开头。以具体的例子、具体的声明或明确的问题开头。不要以‘总之 (In conclusion)’或对各节的回顾结束。在论点或解释自然结束的地方结束。”*

编辑检查：如果第一段稍微改一改就能塞进另一篇文章，直接删掉或重写。如果最后一段只是重复前文，也删掉，或者换成一句具体收束。

3. **形容词**

模型经常依赖积极但含糊的形容词：*强大的 (robust)*、*无缝的 (seamless)*、*开创性的 (groundbreaking)*、*变革性的 (transformative)*、*关键的 (pivotal)*、*引人入胜的 (intriguing)*、*创新的 (innovative)*、*全面的 (comprehensive)*。它们听起来很自信，但没有增加任何信息。

提示词规则：

> *“避免使用含糊或戏剧性的形容词，如‘强大的 (robust)’、‘无缝的 (seamless)’、‘关键的 (pivotal)’、‘开创性的 (groundbreaking)’、‘变革性的 (transformative)’、‘引人入胜的 (intriguing)’、‘创新的 (innovative)’、‘全面的 (comprehensive)’。只有当形容词增加了具体信息（例如关于规模、性能或限制）时才使用它。否则，将其删除。”*

编辑检查：拿一段话，去掉所有的形容词。然后，只放回那些以有用方式改变意思的词。用细节代替情绪：“强大的系统 (robust system)”可以变成“每秒处理 1 万个请求且不丢失数据的服务”。

4. **客气**

因为模型被训练成安全和不冒犯他人，所以它们默认使用非常礼貌、正式的措辞：“希望这封邮件找到你时你一切都好 (I hope this email finds you well…)”、“我想花点时间来 (I would like to take a moment to…)”、“我谦卑地请求 (I humbly request…)”。

提示词规则：

> *“用直接、中立的专业语气写作。避免使用老套的电子邮件用语，如‘希望这封邮件找到你时你一切都好’或‘我想花点时间表达我诚挚的感激之情’。在第一句话就切入正题。避免使用软化词，如‘只是 (just)’、‘我想知道是否 (I was wondering if)’、‘希望 (hopefully)’，除非它们对于人际关系是必不可少的。”*

编辑检查：问自己“我会大声说出来吗？”如果不，就精简它，直到你可以。“我想友好地跟进一下关于……”通常会变成“只是了解一下关于……”或“有什么进展吗？”。

5. **词汇黑名单**

有些词和短语现在读起来就像是标准的 AI 输出：*深入探讨 (delve)*、*领域 (realm)*、*挂毯 (tapestry)*、*不断演变的格局 (ever-evolving landscape)*、*想象 (imagine)*、*踏上旅程 (embark on a journey)*、*导航/应对 (navigate，作为隐喻)*、*利用 (leverage)*、*驾驭/利用 (harness)*、*努力 (endeavour)*、*充满活力的 (vibrant)*、*至关重要的 (crucial)*、*令人信服的 (compelling)*、“不仅是 X，而且是 Y”。

没有通用的清单；不同的领域有不同的习惯。保留一个小清单，列出你不想看到的词，除非你是故意选择它们的。

提示词规则：

> *“不要使用以下词语：深入探讨 (delve)、踏上 (embark)、想象 (imagine)、领域 (realm)、挂毯 (tapestry)、充满活力的 (vibrant)、努力 (endeavour)、利用 (leverage)、驾驭 (harness)、应对/导航 (navigate，作为隐喻)、无缝地 (seamlessly)、关键的 (pivotal)、开创性的 (groundbreaking)、变革性的 (transformative)、令人信服的 (compelling)、不断演变的 (ever-evolving)、范式 (paradigm)、‘释放潜力 (unlock the potential)’。如果你通常会伸手去拿其中一个，请选择一个更简单的动词或具体的描述代替。”*

随着时间推移更新这个清单。

6. **忠实度和确定性**

当模型根据笔记、文字记录或源文章工作时，它需要明确的界限。

提示词规则：

> *“当提供上下文或源文本时，要忠实于它。不要比原文添加或暗示更多的信心或确定性。如果一个事实不在来源中，要么省略它，要么将其标记为不确定。根据上下文，将课程内容称为‘课程 (lesson)’，将独立文章称为‘文章 (article)’。”*

7. **语气和视角**

你想要的是一致性，而不是表演。

提示词规则：

> *“通过具体的细节和清晰的推理，而不是戏剧效果或额外的修饰，使文章具有可读性和趣味性。在整个过程中保持单一、一致的语气和视角（选择‘我们 (we)’或‘你 (you)’并坚持下去）。不要在同一篇文章中混合使用‘我 (I)’、‘我们’和‘你’。对于教学内容，默认使用‘我们’。”*

8. **直接、清晰、简洁**

修辞手法和重复的定义是废话悄悄溜回来的常见方式。

提示词规则：

> *“直接了当。避免废话和对话式的填充。不要问一个问题然后立即自己回答作为一种手段（例如：‘那么，X 到底是什么？’）。直接陈述观点或定义。*
>
> *每句话都应添加新信息或细微差别。避免用不同的词重复同一个观点。不要在同一文档或系列中多次重新定义相同的首字母缩略词或概念。如果删除一个句子不会改变读者的理解，那就省略它。”*

### 一个可复用的去 AI 味提示词

这里是经过修改的版本，变化很小，只是插入了新的规则。

> 你正在帮助我起草高质量、不敷衍且带有人类口吻的文章。
>
> \[1] 任务与背景
>
> \- 撰写一篇关于：\[主题] 的 \[格式：文章 / 章节 / 电子邮件 / 脚本 / 等]。
>
> \- 背景：\[本文将被用在哪里，以及为什么要写]。
>
> \- 使用以下来源材料作为事实基础。不要与之矛盾：
>
> \[粘贴笔记、大纲、引言、链接]。
>
> \[2] 受众与目标
>
> \- 受众：\[他们是谁：角色、对主题的熟悉程度、限制]。
>
> \- 假设他们已经知道：\[不要过度解释的内容]。
>
> \- 阅读后，他们应该能够：\[1-3 个具体结果]。
>
> \[3] 结构
>
> \- 遵循以下结构：
>
> 1. \[第一节名称 + 1-2 行关于它涵盖的内容]
> 2. \[第二节...]
> 3. \[第三节...]
>
> \- 不要在此大纲之外添加额外的章节。
>
> \- 使用完整的段落；每段集中于一个清晰的观点。
>
> \- 仅对真正独立的项目（步骤、优缺点等）使用项目符号列表。
>
> \- 谨慎使用小标题；不要为每个段落创建标题。
>
> \- 保持标题简短而基于事实。不要使用戏剧性或叙述性的两部分标题。
>
> \- 确保章节之间过渡平滑自然，不要使用类似“现在我们探索了 X，让我们转向 Y”的元陈述。
>
> \[4] 风格与语调
>
> \- 清晰、中性的散文：专业，但在有助于理解的地方可以稍微带点俏皮和机智。
>
> \- 通过具体的洞察和清晰的推理使文章具有可读性和吸引力，而不是靠戏剧性或额外的渲染。
>
> \- 避免戏剧化、炒作、流行语和营销式的语言。
>
> \- 避免辞藻华丽的散文（没有华丽、夸张或令人窒息的语言）。
>
> \- 使用一致的视角（“我们”或“你”）并坚持下去。
>
> \- 直接。避免填充词和口语化的废话。
>
> \- 不要以自问自答作为诱饵；直接陈述观点。
>
> \- 使用完整的句子；不要将句子片段作为一种文体手段。
>
> \- 不要使用破折号（—）。使用逗号或句号代替。
>
> \[可选的声音匹配]
>
> \- 匹配此示例的节奏、句子长度和语调：
>
> \[粘贴 1-2 段我自己写的文章]。
>
> \[5] 语言与词汇限制（去 AI 味）
>
> \- 避免使用通用的文章和博客短语，例如：
>
> “在当今快节奏的世界中……”、“当我们应对复杂性时……”、“总而言之……”。
>
> \- 不要使用以下句子结构：
>
> \- “这不仅是 X，更是 Y。”
>
> \- “X 不仅是 Y；它还是 Z。”
>
> \- “这不是 X，而是 Y。”
>
> \- “这就是 X 发挥作用的地方。”
>
> \- 除非我在输入中明确包含，否则不要使用这些词/短语：
>
> 惊人的 (amazing)、迷人的 (fascinating)、令人惊叹的 (mind-blowing)、必读的 (must-read)、快速发展的世界 (fast-moving world)、拨开迷雾/噪音 (cut through the hype/noise)、开创性的 (groundbreaking)、范式转变的 (paradigm-shifting)、变革性的 (transformative)、关键的 (pivotal)、至高无上的 (paramount)、杰出的 (outstanding)、一个重大飞跃 (a significant leap)、深入研究 (delve, dive into)、着手/开始 (embark/embarking)、努力 (endeavour)、领域 (realm)、织锦 (tapestry)、充满活力的 (vibrant)、利用 (leverage)、驾驭 (harness)、无缝集成 (seamlessly integrates)、从头开始 (start from the ground up)、解决一个新颖的问题 (tackle a novel problem)、至关重要的 (crucial, critical)、无价的 (invaluable)、显著的/地 (significant/significantly)、令人惊讶地 (surprisingly)、简单地 (simply)、巧妙地 (neatly)、“最棒的是” (“the best part is”)、“真正的奇迹发生” (“real magic happens”)、“灾难的秘诀” (“recipe for disaster”)、“繁荣” (“thrive”)、“释放真正的力量” (“unlock the real power”)。
>
> \- 优先使用平实、具体的动词和特定的技术术语，而不是模糊或戏剧性的措辞。
>
> \- 仅在添加具体信息（规模、约束、性能）时才使用形容词。
>
> \- 极少使用类比，只有当它们提供非显而易见的澄清时才使用。
>
> 不要使用引导性的类比短语，如“想象……”或“把这想成……”。
>
> \[6] 准确性与术语
>
> \- 忠实于提供的上下文和来源。
>
> \- 不要夸大确定性；如果事实不确定，要么省略它，要么将其标记为不确定。
>
> \- 对于首字母缩略词，在首次使用时写出完整短语，然后使用缩略词。
>
> “AI”和“LLM/LLMs”可以在不展开的情况下使用，除非受众完全是新手。
>
> \- 根据需要，将“课程 (lesson)”用于课程内容，将“文章 (article)”用于独立文章。
>
> \[7] 流程
>
> \- 对照上述规则默默检查你自己的输出。
>
> \- 删除重复的句子开头、禁用的词语和不添加新信息的填充句。
>
> \- 不要在最终输出中包含内部评论、给自己留的便条或占位符。
>
> 答案读起来应该是一个完整、打磨过的产品。
>
> \- 然后呈现最终草稿，不解释你做了哪些修改。

这个模块可以放在你更大的通用模板（包含任务、受众、结构和准确性）中。对于电子邮件，你可能会保留客气规则并精简其余部分。对于长篇文章，你可能会保留所有内容，并用特定领域的陈词滥调扩展黑名单。

关键点在于，你不再需要每次都重新发明“请不要听起来像 ChatGPT”了。你只需决定一次你希望语言如何表现；模型会将其作为它工作描述的一部分来读取。

### AI 修改循环在实践中是什么样的

即使有很好的结构和经过仔细推敲的提示词，大多数模型在第一次尝试时也不会遵循所有规则。它们仍然会偷偷混入一个“快节奏的世界”，三次重复使用相同的过渡，或者又退回到散文式的结论。这是正常的。目标不是一次性获得完美的草稿；而是建立一个循环，让模型在你花费大量编辑时间之前完成大部分清理工作。

一个有用的思考方式是：第一个回复是版本 0，而不是你必须接受的草稿。你使用完整的模板要求内容和结构：任务、受众、大纲以及你的去 AI 味语言规则。版本 0 应该有大致正确顺序和正确的想法。如果结构不对，你要修复它；在你打算删减或移动的段落上打磨语言是毫无意义的。

一旦结构没问题了，你就让 LLM 充当法官。在实践中，这通常意味着打开第二个聊天窗口或使用不同的模型。第一个聊天是你产生草稿的“作家”模型。第二个聊天/模型是你的“编辑”模型，其唯一工作是查找并标记废话。你把草稿和规则粘贴进去，并要求它只审阅，不重写。例如：

> *“你正在审阅一份草稿，寻找 AI 废话和风格问题，而不是重写它。*
>
> *这是我们使用的规则（结构和语言）：*
>
> *\[粘贴你的大纲约束 + 去 AI 味模块]*
>
> *这是草稿：*
>
> *\[粘贴草稿]*
>
> *1. 指出这份草稿在哪里违反了上述规则：*
>
> *- 重复的开头或过渡*
>
> *- 通用的引言或结论*
>
> *- 含糊或夸张的形容词*
>
> *- 老套的电子邮件短语或过度客气*
>
> *- 黑名单中的 AI 常用词*
>
> *2. 对于每个问题，用一句简短的话建议如何修复它。*
>
> *暂时不要重写整篇文章。”*

将该回复视为诊断。它通常会突出显示通用的开头、重复的模式、残余的禁用词以及读起来像总结的段落。你现在有了一个具体的问题列表，而不必自己通读全文。

接下来，你回到作家窗口，并要求进行第二遍修改，将编辑的笔记作为输入。你不想要一篇全新的文章；你想要一个保留了结构和想法但修复了问题的修改版。这样的提示词可能看起来像这样：

> *“这是你的初稿，加上一份指出了它在哪里违反了我们商定的风格/去 AI 味规则的审阅。*
>
> *\[粘贴审阅意见]*
>
> *重写草稿，只修复这些问题：*
>
> *- 删除通用的引言和散文式的结论*
>
> *- 改变重复的句子开头*
>
> *- 删除或替换含糊的形容词和 AI 常用词*
>
> *- 删除元文本（“在这一节中我们将……”）和沉重的路标提示*
>
> *保持结构、章节和主要论点不变。”*

如果某个部分特别糟糕，你可以把它隔离出来，一次只做这块。这样可以防止模型“乐于助人”地重新引入你刚刚在文章其他部分删除的模式。

一旦“作家”和“编辑”模型完成了它们的检查，你可以在此基础上添加几个简单的步骤。

**使用外部检查器作为第二意见**

一个选项是通过 [Slop Score](https://eqbench.com/slop-score.html?ref=louisbouchard.ai) 运行修改后的草稿，这会让你了解短语模式看起来有多“GPT”。另一个是 [Creative Writing Longform benchmark](https://eqbench.com/creative_writing_longform.html?ref=louisbouchard.ai)，它侧重于更长、更像人类的文本。这些工具不会替你做决定，但它们是有用的信号。如果分数飙升，或者某些短语被挑出来认为高度类似模型生成的，你可以将此反馈到你的流程中：将这些模式添加到你的黑名单中，或者要求第二个窗口中的编辑模型下次明确查找它们。

**让人类编辑保持专注**

一旦模型和工具完成了它们的工作，你就可以进行一次简短、专注的人类编辑。在这里，你为了结构而读，询问段落顺序是否真正匹配你大声解释主题的方式。你为了准确性而读，检查数字、名称和声明是否基于你认可的来源或知识。你为了质感而读，注意文章听起来像你或你的团队，还是像一个没有明确作者的通用说明文。在这个阶段你注意到的任何新的口头禅或模式，都可以直接加入你的黑名单，这样它们就不会在未来的草稿中再次出现。你要补充你在阅读时想到的例子或见解，为文章增添你的个性和触感。

**以版本的概念思考，而不是单一草稿**

在实际工作流中，这通常意味着进行两三次快速循环，而不是产生一篇大而完美的草稿。版本 0 是你使用主要提示词将内容和大致结构落实到位的地方。版本 1 是模型根据你的规则对其自身进行批评和修改后的草稿，可能借助了 Slop Score 或 longform benchmark。版本 2 是你编辑过的版本，你在这里调整判断、细微差别和语气。提示词模板、黑名单、编辑窗口和外部工具的存在，都是为了让这些循环变得更廉价，让“AI 草稿”的含义从“我必须从头重写的东西”变成“我只需要稍微编辑一下的东西”。

### 为什么人类的审视依然重要

所有这些都无法消除人类审阅的必要性。模型可以根据你的规则起草、重组和修改，但它们仍然无法决定哪些观点对你的读者重要、你对某个声明应该有多大的把握，或者文章听起来是否属于你的声音。检查结构、事实和语气仍然是你的工作。

让这项工作变得可管理的办法是标准化工作流。你重复使用同一个基础提示词，而不是每次都写新的指令。你保留一个小黑名单，并在新的“AI 词”出现时更新它。你在第二个聊天中使用固定的编辑提示词，这样模型就可以在你编辑之前标记出它自己的习惯。你最后的检查就会遵循一个简单的清单：结构合理，声明有依据，语言符合你或你团队的惯常写作方式。

如果你坚持这样做，AI 并不会消除编辑工作，但它确实改变了你所做编辑的种类。大部分机械的废话由模型和你的提示词处理。你的时间花在了只有你能做出的决定上：你想说什么、你愿意在一个声明上走多远，以及这是否是一篇你乐意署名的文章。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-content-creation-sop-202605.md
description: 从 DeepSeek 六步 SOP 和 Grok 找新词方法出发，整理一条更稳的 AI 内容创作流程：让 AI 做资料整合，再由人工判断和个人表达完成成文。
---

# AI 内容创作 SOP：别把模型当代笔

很多 AI 内容之所以同质化，常见原因是用户把模型直接当写手：丢一个题目，等它吐一篇完整初稿。这样出来的文本，往往结构齐整、信息面广、语气也顺，但读完之后留不下什么。模型确实替你"写"了，却没有替你把资料吃透、筛过、排过。

这条流程的核心：**让 AI 做资料整合，再让人把判断和经验加回去。**

## DeepSeek 六步 SOP

> DeepSeek，内容创作的唯一真神。AI 辅助内容创作 SOP：
>
> 1. 选定参考稿，找一篇质量高、方向对的稿子作为核心参考样本。
> 2. 批量收集同类素材，围绕同一主题收集 5-10 篇文章、视频脚本或帖子，来源可以是小红书、公众号、知乎、YouTube 字幕等。
> 3. 投喂 AI 做素材整合，提取核心观点、数据、案例和结构，整合成完整汇总文章，不遗漏重要信息，让 AI 做信息聚合而非创作。
> 4. 去除 AI 味、还原人声，用口语化表达重写，去掉套话和万能金句，保留逻辑但换掉模板句式。
> 5. 注入个人视角与独家内容，加入亲身经历、踩坑、私有数据、独到判断或反常识观点，这是文章差异化和个人品牌关键。
> 6. 取精去糟、二次精炼，删掉重复啰嗦内容，保留信息密度高、表达精准的部分。
>
> 核心价值是把 AI 当信息整合器而非创作者，第 5 步注入个人视角最关键。很多 AI 内容失败是缺这步，导致同质化严重。
>
> 找新词方法：用 Grok 实时爬取推特，准备经常发最新模型的 AI 博主列表。提示词要求它分析列表前一天发布的推文，整理提到 AI 模型的推文，输出原帖链接、内容摘要、模型类型、模型名称、发布厂商、开源 / 不开源，重点关注文生图和文生视频模型。

这段流程的核心思路是把资料整理和实际成文分成两步。

## 第 1 步：参考稿决定方向，不决定你的结论

很多人找参考稿时容易走两个极端：

* 要么什么都不找，直接让模型从零开始写；
* 要么找到一篇爆文之后，几乎按那篇的结构照着抄。

更稳妥的做法，是找一篇"方向对、信息密度高、结构清楚"的稿子，把它当样本，不当母版。

参考稿主要帮你解决三件事：

1. **内容类型**：你写的是教程、评论、综述、踩坑记录，还是新闻延伸？
2. **受众层级**：是写给已经懂行的人，还是写给刚接触的人？
3. **结构骨架**：这个主题通常按背景、问题、方法、风险、案例，还是按步骤拆更顺？

如果你换掉核心名词，这篇参考稿还能套在十几个主题上，它大概率只是结构模板，不足以做你的主样本。能用的参考稿，通常会把主题里的关键矛盾写得很清楚。

## 第 2 步：5–10 篇同类素材，目的是补视角和证据

六步 SOP 建议收 5–10 篇同类素材，这个数量是合理的。太少，素材面不够；太多，整理成本又会暴涨。

数量只是下限，关键是来源要混合。你如果 10 篇都来自同一平台、同一类作者，最后喂给模型的还是一份单一口径合集。比较稳妥的组合通常是：

* 1 篇高质量长文，负责结构；
* 2–3 篇观点型帖子，负责抓争议点和真实表达；
* 1–2 段视频字幕或访谈，负责补口语化说法；
* 1–2 个产品页、项目说明或官方说明，负责补事实范围；
* 如果主题和案例相关，再补 1–2 个用户反馈或评论区高质量讨论。

小红书、公众号、知乎、YouTube 字幕都是可选来源，资料源不要太单一。文字、视频、帖子混起来，整理出来的东西才会像是真的读过一轮材料，不会只剩平台洗稿味。

## 第 3 步：把 AI 当资料整合器，不当第一作者

这是整套方法的中心："让 AI 做信息聚合而非创作"。

如果你前面已经收了参考稿和多份素材，模型最适合做的事情有这些：

* 把重复观点合并；
* 把分散的数据、案例和定义归类；
* 提取各篇素材的共同结构；
* 标出冲突说法；
* 生成一份"还没写人话，但信息较完整"的汇总稿。

这一版汇总稿不用追求好读，甚至可以故意让它"像资料包"。它本来就不是发给读者看的，而是把后面写作要用的材料先拢住。

如果你跳过这一步，直接让模型写成品，它当然也能写，但输出会天然倾向于：

* 选它最熟悉的结构；
* 用它最常用的套句；
* 把不确定信息补成看起来很顺的过渡句。

这样生成出来的东西往往最像"成稿"，也最容易空掉。

## 第 4 步：改掉模板腔，保留事实

第 4 步是：口语化表达重写，去掉套话和万能金句，保留逻辑但换掉模板句式。这一步有前提：**去 AI 味不等于伪装人工，也不等于改掉事实。**

应该改掉的是这些：

* 句子太匀，每段都一个长度；
* 开头总在"随着""在当下""从某种意义上说"；
* 转折太工整，像在念提纲；
* 明明没新信息，还反复做抽象升华；
* 一堆看起来正确的判断句，但没有任何细节落点。

不该乱动的是这些：

* 数据和数字；
* 来源指向；
* 专有名词；
* 你还没核验清楚的事实范围。

所以第 4 步只动表达层，不动事实层。如果模型汇总稿里写了一个数字，你没回源核过，去 AI 味时也不能顺手把它写成确定事实。

## 第 5 步：个人视角是分水岭，这一步不能外包

五类内容值得关注：亲身经历、踩坑、私有数据、独到判断、反常识观点。一篇内容有没有作者自己的东西，很多时候就看这五类材料有没有进来。

### 1. 亲身经历

亲身经历真正有价值的地方，是能交代一个真实上下文：你在什么时间、什么工作流、什么限制下用过它，后来卡在了哪里。

### 2. 踩坑

踩坑能直接把抽象方法落地。比如"素材收太多导致整理时间反而变长""把同平台爆文全喂进去，输出全是一个口气""只改表面措辞，结果事实错误还留着"，这些都比一句"要注意素材质量"有用得多。

### 3. 私有数据

私有数据不一定是商业机密。它也可以是你自己的实验记录：哪类文章收 6 篇就够，哪类需要 10 篇；哪种资料源最容易互相抄；哪一步最费时间。只要是别人拿不到、但你手里真实有的观察，都能拉开差距。

### 4. 独到判断

独到判断不等于唱反调。它考验的是你读完资料之后，敢不敢下一个具体判断：这条流程放在综述类内容里会更顺，放在纯采访稿上未必顺手；它适合资料密度高的文章，不适合完全靠现场故事推进的叙事文；它能把写作前半段做快，但立场和删改还得人来定。

### 5. 反常识观点

反常识不是故意拧巴。它的作用，是让读者停一下。比如这篇的重点，可以直接说成：**AI 内容同质化，往往是因为大家把 AI 用在了最省事、也最不该偷懒的那一段。**

第 5 步为什么是分水岭？没有这一步，写出来的东西就算信息完整，也还是一篇"任何人都能写出来"的文章。

## 第 6 步：二次精炼，把"资料包"修成"文章"

第 6 步是"取精去糟、二次精炼"。很多稿子在第 3 步之后已经有信息，在第 4 步之后也没那么僵，但还是难读，原因通常是删得不够。

这一轮要重点做四件事：

1. 删重复观点；
2. 删没有新信息的解释句；
3. 把段落顺序调到更顺；
4. 把真正重要的判断提到前面。

到这一步，资料包才算被修成文章。

## Grok 找新词方法的定位

官网：<https://x.ai/>

文档：<https://docs.x.ai/developers/tools/x-search>

Grok 找新词方法和前面的六步 SOP 不在同一层。前六步讲的是"写一篇内容怎么做"，这一段讲的是"平时怎么找题"。

> 找新词方法：用 Grok 实时爬取推特，准备经常发最新模型的 AI 博主列表。提示词要求它分析列表前一天发布的推文，整理提到 AI 模型的推文，输出原帖链接、内容摘要、模型类型、模型名称、发布厂商、开源 / 不开源，重点关注文生图和文生视频模型。

这里可以分成两层看。

### 第一层：技术可行性

xAI 官方 `x_search` 文档能核到几件事：

* 可以限定 `allowed_x_handles`；
* 可以设置 `from_date` / `to_date`；
* 可以让模型基于 X 内容做检索和整理；
* 还能开启图片或视频理解。

所以"准备一个固定博主列表，再让 Grok 看前一天的帖子"这件事，从文档能力看是可以落地的，不是空喊 prompt。

### 第二层：写作上怎么用才对

这一层可以当成题材雷达：

* 盯新增模型和术语；
* 筛哪些值得继续追；
* 决定要不要写成文章。

它的任务是替你做前置监控，不是替你写稿。每天跑一次就够用，整理出一份"昨天出现了哪些值得继续追的模型和词"。

![Astronaut\_1216 原始短帖配图](https://gastigado.cnies.org/d/public/astronaut-deepseek-post.jpg)

## 最小实践路径

一个够用的最小版本，大概是这样：

1. 找 1 篇参考稿，定结构；
2. 收 5–8 篇同类素材，混合长文、帖子、视频字幕和官方资料；
3. 让模型只做整理，不做成稿；
4. 自己重写，并把个人经历、踩坑和判断补进去；
5. 收尾时再删一轮，把所有没必要的解释句清掉。

如果你想保留一个找题动作，就额外跑一条 Grok 监控流，专门盯前一天的新模型和新词，别把这个动作和正文写作搅在一起。

## 发布前检查：别只检查文风

### 1. 事实核查

所有数字、型号、发布时间、功能范围，都要回到原始来源或官方页核一次。模型做完整合之后，最容易出现的问题不在"写得太假"，而在"写得太顺"。顺到让你忘了它可能把不确定内容也补平了。

### 2. 素材版权

你用了哪篇文章、哪段字幕、哪张图、哪条帖子，都要确认能不能引用、能引用到什么程度。尤其是社媒内容和截图，最好保留来源说明，不要把别人内容当成无主素材。

### 3. 平台规则

不同平台对转载、引用、营销口径和 AI 生成内容的要求并不一样。发出去之前，至少要确认标题、配图、引用方式和跳转链接不踩平台线。

### 4. 人工精炼

这一步还是得人来做。你要判断什么该删，什么该提前，什么该留在评论区，什么该另写一篇。很多稿子从"能发"到"有人看"，靠的就是这 10 分钟人工删改，不是再补一轮 prompt。

## 这条方法适用在什么场景

这条方法主要适用于两类人：

* 手里有资料、但写出来总是散的人；
* 能提供真实经验、但不想从零组织材料的人。

如果你本来就没有资料、没有经验、没有判断，只指望靠这条流程批量生产，出来的多半还是整齐但普通的文本。

模型可以帮你把资料拢起来，但一篇内容有没有人味、有没有信息差、值不值得发出去，还是要靠你自己判断。

---

---
url: https://ain.hmgf.hxcn.space/ai/ip-writing-skills-202605.md
description: >-
  梳理 SoftwareCopyright-Skill 与 patent-disclosure-skill 的输入输出、安装使用、人工复核点，以及这类文书
  Skill 能省什么、不能省什么。
---

# 软著与专利写作 Skills

软件著作权材料和专利交底书有一个共同点：格式强、步骤多、反复改。最耗时间的，往往是把项目材料读明白、把字段填完整、把源码和截图整理到能提交的程度。

这类任务很适合做成 Skill。输入材料相对固定，输出文件也有明确形态，中间还能插很多必须停下来确认的节点。只要项目材料本身是真实的，Skill 确实能帮小团队减掉大量整理工作，连几百块代办费都可能省下来。

问题也在这里。文书能自动生成，不代表材料已经可靠；格式能自动排好，不代表内容已经合规。源码是不是来自真实项目、软著申请表和操作手册的口径是否一致、专利交底书里的发明点是否值得写、查新有没有漏掉关键对比文件，都得靠人复核。

## 为什么这类任务适合做成 Skill

和一般的开放式写作相比，软著材料和专利交底书的流程性要强得多：

* 输入范围比较固定：项目源码、项目说明、设计文档、产品说明、登记字段、截图。
* 输出有定型：TXT、Markdown、DOCX、流程图、附图、修订记录。
* 步骤有顺序：分析项目、确认口径、产出草稿、导出正式文件。
* 错误能追溯：字段不一致、版本号不一致、代码来源不清、图示和正文对不上，都能回查到中间文件。

所以，Skill 在这里的主要价值，是把重复劳动拆成一套能复跑、能中断、能确认、能留痕的工作流。

## `SoftwareCopyright-Skill`：把软著材料生成拆成一条带门禁的流水线

它是一个用于生成中文软件著作权申请资料的 Codex Skill。安装时要用的是 `software-copyright-materials/` 这个目录，不是整个仓库根目录。

![SoftwareCopyright-Skill 生成流程截图](https://gastigado.cnies.org/d/public/SoftwareCopyright-Skill-demo-1.png)

### 它要解决的麻烦很具体

软件著作权申请本身不神秘，麻烦主要出在整理材料：申请表字段要一致，操作手册要像样，代码材料要按页数规则截取，软件名称、版本号、运行环境和截图又得前后对上。

它处理的是一整套材料整理流程：

* 读取本地真实项目；
* 做项目分析和业务理解；
* 生成申请表信息、操作手册和代码材料草稿；
* 用户确认后导出 DOCX 和 TXT；
* 整套文件默认留在当前项目目录里。

仓库直接提醒过一句：**请不要相信任何基于这个项目包装出来的付费服务。** 它的使用场景是：开发者自己整理申请材料，而不是花钱找代办。

### 项目能力

从仓库文档和 `SKILL.md` 看，这个 Skill 已经把流程拆得很细：

* 分析项目结构、依赖、入口、路由、页面、组件和源码文件数量；
* 产出 `业务理解.md/json`，让用户确认行业、目标用户、核心功能和申请口径；
* 生成 `申请表信息.md`，让用户补全著作权人、日期、硬件环境、系统环境等字段；
* 产出 `代码文件候选清单.md` 和 `代码文件选择.json`，再由模型和用户一起决定抽哪些文件、哪些行段；
* 根据页数规则生成前 30 页 / 后 30 页，或者在不足 60 页时生成全部代码材料；
* 生成操作手册草稿、自检记录、截图清单，再导出正式 Word 和 TXT。

它会把软著申请资料拆成多个可复核的中间文件，每一步都要求用户停下来确认。

### 输入与输出

这个仓库的输入，主要是四类：

1. **真实项目本身**：源码、项目说明、脚本命令、依赖、页面入口、接口和必要文档。
2. **登记字段**：软件全称、版本号、著作权人、开发完成日期、运行环境、开发工具等。
3. **截图材料**：通过 Chrome DevTools MCP、Codex Computer Use，或者用户手工提供截图。
4. **人工确认**：业务口径、代码选择、字段补全、Markdown 草稿确认。

输出文件比较完整，主要会落到下面的目录结构：

```text
软件著作权申请资料/
├── 环境检查.md
├── 分析结果与草稿
│   ├── 业务理解.md
│   ├── 申请表信息.md
│   ├── 代码文件候选清单.md
│   ├── 代码文件选择.json
│   ├── 代码提取清单.md
│   ├── 操作手册.md
│   └── 操作手册自检记录.md
├── 截图/
└── 正式资料/
    ├── 申请表信息.txt
    ├── 软件名称_操作手册.docx
    ├── 软件名称-代码(前30页).docx
    ├── 软件名称-代码(后30页).docx
    └── 生成报告.md
```

如果总代码页数不足 60 页，文档规定生成"全部代码"文档；如果还存在可补充源码，流程会停下来，要求用户继续选文件，避免直接产出一份不完整材料。

### 安装与调用

安装方式很直接，克隆仓库，再把真正的 skill 目录复制到 Codex skills 目录：

```bash
git clone https://github.com/Fokkyp/SoftwareCopyright-Skill.git
cd SoftwareCopyright-Skill
mkdir -p ~/.codex/skills
cp -R software-copyright-materials ~/.codex/skills/
```

安装完之后，目标路径应该长这样：

```text
~/.codex/skills/software-copyright-materials/SKILL.md
```

如果只想在某个项目里用，也可以装到项目本地：

```bash
PROJECT_DIR="<你的项目目录>" && git clone https://github.com/Fokkyp/SoftwareCopyright-Skill.git && mkdir -p "$PROJECT_DIR/.codex/skills" && cp -R SoftwareCopyright-Skill/software-copyright-materials "$PROJECT_DIR/.codex/skills/"
```

调用时可以直接这样说：

```text
使用 software-copyright-materials 生成当前项目的软件著作权申请资料
```

依赖也写得很明白：

* **必需**：Codex、Python 3、可读取的项目源码。
* **可选**：`.NET SDK`，用于更完整的 DOCX OpenXML 生成和校验。
* **可选**：Chrome DevTools MCP 或 Codex Computer Use，用于自动截图。

### 工作流

`software-copyright-materials/SKILL.md` 已经把主流程写成了明确的步骤，顺序大致是这样：

1. **环境检查**：生成 `环境检查.md/json`，告诉你 Markdown、TXT、基础 DOCX、完整 DOCX 环境是否可用。
2. **定位项目**：扫描当前目录，找最可能的项目根目录；如果候选不止一个，必须停下来问用户。
3. **项目分析**：读取 `package.json`、README、入口文件、路由、组件、接口和源码规模，生成 `project.json`。
4. **业务理解**：收集项目证据，再由模型结合源码和文档写出 `业务理解.md/json`，让用户确认申请口径。
5. **申请表字段确认**：软件全称、版本号、著作权人、日期、硬件环境、运行平台、开发工具等都要单独确认。
6. **代码文件选择**：产出候选清单，再由模型写入 `代码文件选择.json`，说明为什么选某个文件或某一段代码。
7. **生成草稿**：提取代码材料，生成申请表信息草稿、操作手册草稿和自检记录。
8. **截图处理**：用户在 Chrome DevTools MCP、Computer Use、手工截图、跳过截图之间做选择；跳过时也要保留"截图预留"。
9. **Markdown 总确认**：所有草稿确认后，才允许继续导出 Word/TXT。
10. **正式生成与验证**：导出 `申请表信息.txt`、代码 DOCX、操作手册 DOCX 和生成报告，再做至少三轮校验。

这个 Skill 对"停下来等用户确认"卡得很严。`environment`、`business`、`application-fields`、`code-selection`、`screenshot-method`、`markdown` 都是强制门禁。`SKILL.md` 甚至明确要求输出 `STOP_FOR_USER`，不能默认继续。

### 人工复核点

文档里限制写得不少，但提交前还是有几类地方必须人工盯：

1. **业务口径**：`业务理解.md` 写歪了，后面的申请表和操作手册都会一起歪。
2. **软件名称和版本号**：操作手册标题、代码页眉、申请表字段、正式文件名要完全一致。
3. **登记字段**：著作权人、开发完成日期、首次发表日期、硬件环境、运行环境，都不该让模型自行猜测。
4. **代码来源**：仓库会生成 `代码提取清单.md/json` 方便追溯，但你还是要抽样核对代码段能否回到原项目。
5. **截图真实性**：截图和文字描述要对应当前项目真实页面，别拿演示图混进正式材料。
6. **最终格式**：DOCX 导出后要检查分页、页眉、字体、截图占位和是否需要另存为 PDF 上传。

还有一个很容易被忽视的要求：操作手册是写给审核员看的。`SKILL.md` 对这一点抓得很紧：操作手册应该说明模块用途、用户如何操作、操作后看到什么结果，尽量少写框架名、接口封装、状态管理这类技术细节。这样写更容易让材料前后一致。

### 评论与风险

第一条风险，是**把"禁止 AI 编造源码"写成口号**。项目文档确实反复强调代码必须来自真实项目，也提供了代码提取清单和三轮验证。但有一点需要注意：光声明没用，最好在出正式文件前再加一轮 grep 校验或路径抽样回查。至少要确认导出的文件路径、函数名、关键类名和版本号能在真实仓库里找到原始出处。

第二条风险，是**AI 会沿着看起来合理的方向补全细节**。代笔类工具以前踩过坑，出现过凭空编造内容的情况。这个提醒和当前仓库不是同一件事，但指向的是同一类问题：只要材料里混进臆造内容，后面排版再工整也救不回来。

第三条风险，是**材料质量不会因为自动化就自动变得可靠**。操作手册、代码说明书和申请表本来就是格式固定的文书，这类任务很适合让 Skill 先做脏活累活；同时也最容易让人掉以轻心。软件名称写错一个字、版本号前后不一致、运行环境写成了技术栈、截图和正文对不上，都会在补正时反咬回来。

第四条风险，是**合规顾虑不能装看不见**。有观点认为，国家对 AI 生成申请材料的审查可能更严格。就当前可核验资料来看，项目文档中未包含对应的官方政策文件，所以这条不能写成已证实规则。但它代表了真实顾虑：如果你担心机器味过重、固定模板痕迹过重，就别把生成结果原封不动直接交上去，至少要做一次人工改写、格式校对和真实性复查。

还有一条最基本：**人工还是要盯格式和真实性。**

官方填报入口也最好顺手记着，别把本地草稿误当成可直接上传的正式材料：

* 中国版权保护中心：<https://www.ccopyright.com.cn/>
* 著作权登记系统：<https://register.ccopyright.com.cn/login.html>
* 《计算机软件著作权登记办法》：<https://www.gov.cn/zhengce/2002-02/20/content_5724627.htm>

## `patent-disclosure-skill`：专利交底书工作流

软著 Skill 偏资料整理，这个专利 Skill 则偏交底书工作流。它的目标很直接：从项目文档走到可交付的技术交底书，覆盖专利点挖掘、查新、脱敏成文和自检闭环。

![patent-disclosure-skill 初版生成效果](https://gastigado.cnies.org/d/public/patent-disclosure-skill-效果例-初版生成.jpg)

### 它解决的是哪类工作

很多团队手里明明有设计文档、代码、流程图和业务说明，写专利交底书时还是会卡在几个老问题上：

* 专利点该怎么从现有项目里往外挖；
* 查新时先搜什么、怎么搜、搜出来的结果怎么整理；
* 系统框图和流程图怎么画到代理人能直接接手；
* 交底书改了几轮之后，哪些内容是新增，哪些是纠错，谁改过什么。

它给出的办法，是把这件事做成一套按步骤执行的 Skill：扫描项目、讨论专利点、查新、写交底书、自检；后面继续补材料或纠错时，保留旧版、另存新版，并追加修订记录。

### 项目能力

从项目文档能确认几件关键事情：

* 项目扫描时，文档和代码按优先级读取；如果扫描范围里有 `.docx`、`.pptx`，要先转成 Markdown 再读。
* 查新优先走国家知识产权局公布公告站：<http://epub.cnipa.gov.cn/>。
* 查新工具分了两层：优先用仓库内的 `cnipa_epub_search.py`，抓不到或无结果时再降级用 WebSearch。
* 交底书成稿支持 Mermaid 系统框图和流程图，之后再渲染成 PNG 并默认导出 DOCX。
* 每次正式交付的文件名都带时间戳：`{案件名}_{YYYYMMDDHHmmss}.md` 和同名 `.docx`。
* 已有交底书基础上的补充或纠错，不覆盖旧稿，而是另存新文件，并追加 `交底书修订对话记录.md`。

这意味着它做的不只是"写一份交底书"，还把版本管理和修订留痕一起带上了。

### 输入与输出

这个 Skill 的输入比软著 Skill 更开放一些，但范围仍然清楚：

* 项目代码；
* 设计文档、需求文档、产品说明；
* Word、PPT、PDF 等 Office 材料；
* 技术主题关键词；
* 已有交底书草稿；
* 后续补充材料和纠错意见。

输出则主要落在案件目录里，文档给出的结构是 `outputs/{案件标识}/`，核心产物包括：

* 带时间戳的交底书 Markdown；
* 同名 DOCX；
* Mermaid 渲染后的 PNG 图；
* 查新笔记；
* 合并或纠错后的新版本文件；
* `交底书修订对话记录.md`。

从交付角度看，这种"版本并存 + 修订日志"的设计挺实用。专利材料通常不会一稿定完，能把每一轮修改记下来，后面和代理人沟通会省很多口舌。

### 安装与依赖

项目给了 Claude Code 和 Cursor 两套安装方式。Claude Code 的项目内安装示例是：

```bash
mkdir -p .claude/skills
git clone https://github.com/handsomestWei/patent-disclosure-skill .claude/skills/patent-disclosure-skill
```

Cursor 的全局路径则是：

```bash
mkdir -p ~/.cursor/skills
git clone https://github.com/handsomestWei/patent-disclosure-skill ~/.cursor/skills/patent-disclosure-skill
```

依赖分成三层：

1. **基础 Python 依赖**：用于 Word / PPT 转 Markdown、Markdown 转 DOCX 等。

```bash
pip install -r requirements.txt
```

2. **查新依赖**：如果要优先走国知局公布公告站，需要额外装 Playwright 和对应依赖。

```bash
pip install -r tools/requirements-cnipa.txt
python -m playwright install chromium
```

3. **图示依赖**：如果要把 Mermaid 图渲染成 PNG，再嵌进 DOCX，需要 Node.js 和 `mmdc`。

```bash
cd tools
npm install
```

如果 `mmdc` 报找不到 Chrome，文档还给了补充命令：

```bash
npx puppeteer browsers install chrome-headless-shell
```

### 调用方式与工作流

仓库支持自然语言触发，也支持斜杠命令。文档举的触发词包括：专利挖掘、专利点、技术交底书、查新、现有技术对比。

它的主流程在 `SKILL.md` 里列得很完整，顺序如下：

1. **intake**：确认任务边界和输入材料。
2. **project\_scan**：扫描项目代码和文档；遇到 `.docx`、`.pptx` 先转 Markdown。
3. **patent\_points\_analyzer**：讨论候选专利点，做融合和取舍。
4. **prior\_art\_search**：走国知局公布公告站查新，必要时再补充 WebSearch。
5. **disclosure\_preview**：正式生成前做摘要预览。
6. **disclosure\_builder**：按照模板写交底书正文和图示。
7. **disclosure\_self\_check**：做内部自检，检查逻辑闭环、公式和参数一致性。
8. **iteration**：后续补材料或纠错时，进入合并或修正分支，另存新版并记录修订日志。

如果只抓一个重点，可以记住：它把交底书写作当成可迭代工程，不会把这件事当成一次性吐文本。

### 适用阶段

这个 Skill 的使用场景，是项目已经跑起来、需要把技术方案沉淀成专利底稿的时候。

常见用法大概会是这样：

1. 把仓库、设计文档、PPT、旧版说明书交给 Skill 扫描。
2. 让它列候选专利点，别急着直接写交底书。
3. 选定一个要推进的点，再做查新，看看已有公开方案离你有多近。
4. 让它整理成能给代理人继续改的技术交底书。
5. 代理人或团队成员回补资料后，再走迭代流程，生成下一版文件。

按这个顺序，它放在"材料归档 + 查新 + 初稿成形 + 版本迭代"这段流程里会更合适。

### 人工复核点

专利交底书比软著材料更需要人工盯的地方，主要有这几类：

1. **专利点是否值得写**：Skill 可以帮你列候选点，但值不值得申请、申请哪个点、哪些点留作商业秘密，还是要业务和代理人一起判断。
2. **查新检索词设计**：文档强调优先用国知局公布公告站，这是优点；检索词设得不对，一样会漏检。
3. **差异化论述**：搜到了近似专利，不代表你已经说明白"自己哪里不同"。这一步很容易流于堆砌摘要。
4. **图示和正文一致性**：系统框图、流程图、模块编号、变量名、参数说明要能对上，特别是多轮迭代之后更容易错位。
5. **脱敏范围**：它提供了脱敏模版，但哪些实现细节该留、哪些商业信息该删，需要团队自己定。
6. **能否直接交给代理人**：Skill 产出的交底书已经接近高质量底稿，但离正式专利申请文本通常还差权利要求布局和法律语义打磨。

这也是为什么仓库把"修订对话记录"单独做成文件。它知道后面一定会改，而且很可能要改不止一轮。

### 效率与风险

专利 Skill 的效率价值很明显：项目文档扫描、Office 转 Markdown、查新入口统一、交底书模板化、流程图自动渲染、DOCX 导出和版本留痕，这些都属于很适合自动化的部分。

合规和质量风险也同样明显：

* **查新不等于法律结论**：优先搜国知局公布公告站很合理，但搜索结果依旧受检索词和语义理解影响。
* **交底书不等于申请文本**：它是面向代理人继续加工的底稿，不能直接把"可交付"理解成"可直接提交"。
* **文档转换会丢信息**：`.docx`、`.pptx` 转 Markdown 虽然方便扫描，但复杂排版、图表、SmartArt 或 OLE 对象可能会丢细节。
* **参数和术语很容易在迭代时漂移**：仓库虽然有自检步骤，人工还是要抽查关键术语、编号和公式。

如果你的团队本来就有稳定的专利代理人或法务，这个 Skill 很适合用来把零散技术材料整理成代理人愿意接手的底稿，不要让它承担最终法律判断。

## 落地建议

把两个仓库放在一起看，有几条经验很值得直接写下来：

1. **把 Skill 当成文书流水线，不要当成免责工具。** 它能帮你省整理时间，省文档往返，省掉一部分代办费；责任不会跟着一起消失。
2. **中间文件要留。** `业务理解.md`、代码提取清单、申请表草稿、查新笔记、修订记录，这些文件越全，后面越容易追责也越容易纠错。
3. **源码来源要做回查。** 原始评论里提到的 grep 校验，建议保留成固定动作：导出前至少抽样对几个文件路径、函数名、类名和页眉版本号。
4. **把格式和真实性分开检查。** 格式问题可以靠工具发现，真实性问题还是要人去对照项目和业务事实。
5. **正式交付前一定看 DOCX/PDF。** Markdown 看着没问题，不代表 Word 分页、页眉、图片、字体和标题层级都没问题。

这类 Skill 很适合小团队减轻文书负担，也适合把过去最容易返工的流程拆成可复核、可留痕的步骤。它能帮你把软著材料和专利交底书从"全靠手搓"推进到"有流程、有中间件、有校验点"。

源码真实性、申请口径、法律风险和最终提交质量，还是要人负责。把 Skill 用在该省力的地方，再把人工放在该较真的地方，这样用才可靠。

---

---
url: https://ain.hmgf.hxcn.space/ai/de-ai-writing-tools-202605.md
description: >-
  介绍 humanizer-zh、Shyft skill 页面、李承坤相关文章与 yao-open-prompts，重点放在中文去 AI
  味时如何保住事实、术语和出处。
---

# humanizer-zh 与中文去 AI 味提示词

"去 AI 味"这件事，这两年已经从写作技巧变成了一条小型工具链：有人做 skill，有人做提示词库，也有人专门写方法论。

有几条底线得写在前面：**去 AI 味不等于洗稿，不等于删来源，不等于改数字，也不等于伪造"这是人工一字一句写的"痕迹。** 真正有价值的做法，是把模板腔、宣传腔、对称句和空心结尾压掉，同时把事实、术语、数字和出处保住。

这篇主要看四类材料：

* `temp/humanizer-zh.md` 里的技能定义
* Humanizer-zh 的 GitHub 仓库说明
* Shyft 上的 Humanizer-zh skill 页面
* `yao-open-prompts` 这类中文提示词库
* 以及一类常见的"去 AI 味提示词文章"，这里用李承坤相关文章作为代表性入口来谈

## humanizer-zh 的定位

### Humanizer-zh 仓库

从 Humanizer-zh 的仓库说明和 `temp/humanizer-zh.md` 看，它的定位很明确：这是一个中文版去痕工具，目标是把 AI 生成文本改写得更自然。它承担的是**规则化改写技能**这一层，不负责模型生成，也不承担检测功能。

从仓库说明和 `temp/humanizer-zh.md` 里能看出，它盯的不是简单加几个口语词，而是整套写作模式：

* 夸大意义、动不动上升到趋势。
* 广告腔和空泛褒义词。
* 否定式排比。
* 三段式列举上瘾。
* 太像提纲的段落结构。
* AI 高频词，如"此外""至关重要""凸显""赋能"一类。

它把流程拆成两轮：

1. 改词汇和句法，把机械的报告腔松开。
2. 再做模式检测，把残留的 AI 模板句继续清掉。

和很多"一条 prompt 直接洗干净"的做法不同，它更像一份编辑清单。

### 安装与使用

仓库说明提供了几种安装方式，最省事的是：

```bash
npx skills add https://github.com/op7418/Humanizer-zh.git
```

也支持直接克隆到 skills 目录，或者手动复制 `SKILL.md`。

从使用方式看，它的定位也很清楚：

* 直接拿来改一段 AI 草稿。
* 处理博客、营销文案、学术摘要、技术文档。
* 按它列出的 24 种常见模式做人工复检。

如果你平时就用 Claude Code 一类支持 skills 的环境，这种做法比"保存一条很长的提示词"更稳定，因为规则可以版本化，也方便团队共享。

## Shyft skill 页面补了什么信息

### Shyft 上的 Humanizer-zh

官网：<https://shyft.ai/skills/humanizer-zh>


Shyft 这页不是一手源码，但它补了一个外部视角：别人怎么把这个 skill 当成可安装工具来介绍。

页面把它归到写作类 skill，给出的描述偏业务化：

* 提升文本真实性。
* 用于沟通、营销和本地化。
* 支持快速安装。

它还给了一个更短的安装命令：

```bash
claude install op7418/Humanizer-zh
```

这类页面的价值，主要在说明一个事实：**去 AI 味这件事，已经被包装成了可分发、可安装、可复用的工作流。**

不过也要注意，Shyft 页面里的示例更偏市场文案，真正拿去改技术文档或论文时，仍然要回到 Humanizer-zh 自己那套"保术语、保结构、保事实"的硬约束。

## `temp/humanizer-zh.md` 最值得保留的地方

### 本地技能定义

文档：`temp/humanizer-zh.md`

如果只读一个文件，`temp/humanizer-zh.md` 最值得看。

它最有用的地方，落在三条底线上：

* 不新增事实、数据、案例、引文和实验结论。
* 保留专业术语、逻辑关系、编号结构和关键结论。
* 改结构，再改句子，不要只做表层润色。

这三条把"去 AI 味"和"事实保真"的界线画出来了。

现实里常见的问题，是有人一边说"润色"，一边把：

* 数据改得更好看。
* 语气改得更确定。
* 案例补成了原文没有的东西。
* 把真实来源删掉，只剩一段看起来很顺的人话。

这就不是编辑，是篡改。

## 从素材到可用提示词

### 材料来源

* Humanizer-zh 仓库与 `temp/humanizer-zh.md`：<https://github.com/op7418/Humanizer-zh>
* 知乎去 AI 味指令文章：<https://zhuanlan.zhihu.com/p/1904977486221117285>
* yao-open-prompts 提示词库：<https://github.com/yaojingang/yao-open-prompts>

下面这套提示词，是从 Humanizer-zh 的两轮改写框架、知乎文章的 25 条分类指令、以及 yao-open-prompts 的场景化组织方式中提炼出来的。可以直接复制使用，也可以按自己的场景修改。

***

### 使用前必须记住的四条底线

不管用哪条提示词，下面四条规则不能违反：

1. **不删来源。** 原文有引用、链接、访谈对象、实验来源，改完之后必须还在。
2. **不改数字。** 原文写 48%，不能因为 50% 更顺口就改成 50%。
3. **不伪造人工痕迹。** 不故意加错字、加无关插话、加随机情绪波动来"装真人"。
4. **不把不确定改成确定。** AI 草稿常话说太满，但去 AI 味时不能把"可能""初步""样本有限"全删掉。

***

### 第一部分：通用去 AI 味主提示词

这段是核心提示词，适合直接粘贴给模型使用。需要填的地方用 `【】` 标出。

```text
你现在不是在"生成一篇看起来很完整的 AI 文章"，而是在帮助我写一篇自然、可信、克制、像真人写出来的中文成稿。

你的目标不是追求表面上的流畅、华丽、完整，而是追求：
- 内容真实
- 表达自然
- 结构像人类思考，而不是模板拼接
- 语言有信息量，而不是空洞正确
- 读起来像作者真的懂，而不是模型在凑格式

## 任务信息

内容类型：【文章 / 回答 / 说明文 / 邮件 / 演讲稿 / 教程 / 视频口播稿 / 读书笔记 / 其他】
主题：【填写主题】
使用场景：【发在哪里，用来做什么】
预期长度：【字数范围】
语言：中文

## 写作原则

以我提供的材料为准。不要为了让文章更顺而补充我没有提供的事实。不要把猜测写成确定陈述。不要擅自扩展到材料之外的领域。

- 有材料支撑的内容，可以写
- 没有材料支撑但看起来"合理"的内容，也不要硬写
- 对不确定的信息，不要擅自补全
- 不要制造"听起来很对"的背景句
- 不要为了过渡自然而加入没有依据的判断

## 原始材料

【在这里粘贴资料、原文、提纲、要点、笔记、采访内容、数据、链接摘要等】

## 受众

目标读者：【读者是谁，他们的身份、背景、理解能力、关心的问题】
他们已经知道：【哪些基础知识不需要重复解释】
他们读完后应该获得：【结果 1 / 结果 2 / 结果 3】

## 结构

请严格按照以下结构写，不要额外补万能引言、万能结尾或新小标题：

第一部分：【写什么，目的是什么】
第二部分：【写什么，重点是什么】
第三部分：【写什么，承担什么作用】
第四部分：【如果有】

## 风格要求

- 用自然、清楚、直接、克制的中文写
- 像一个真正懂主题的人在认真说明，不像模型在凑格式
- 以完整段落为主，少用项目符号
- 只在确实适合列举时使用列表
- 不要堆空话、套话、正确废话
- 不要刻意拔高、升华、上价值
- 不要营销腔、公文腔、演讲腔
- 不要每段都一样长
- 不要过强的过渡和路标句

## 明确禁止

不要出现或尽量避免以下问题：

- 通用开头，比如"在当今快速发展的时代""随着技术不断进步""在信息爆炸的今天"
- 通用结尾，比如"总的来说""综上所述""未来，随着……不断发展"
- "首先、其次、最后"式模板推进
- "这不仅是……更是……"这类句式
- "值得注意的是""不难发现""某种程度上""归根结底"这类套话
- 大量"此外、同时、另外、总而言之"等模板连接词
- 空泛形容词，如"强大、高效、全面、深刻、创新、关键、显著"
- 重复表达同一个意思
- 过度客气或礼貌废话
- 硬举万能例子
- 为了像文章而补的废句

## 输出要求

只输出最终成稿。不要解释你采用了哪些策略。不要附带"以下是修改后的内容"。不要写"当然可以""下面是"。不要输出提示词分析。不要输出提纲，除非我要求。
```

***

### 第二部分：逐条润色指令（按需单独使用）

上面的主提示词适合从头写一篇成稿。下面这些指令适合对已有草稿做定向润色。每条可以单独拿出来用。

#### 语言风格类

**增加个人色彩**

```text
请对以下文本进行润色，添加个人色彩和主观表达：
1. 加入"我认为""我发现""说实话"等第一人称表达
2. 添加个人经历或感受的描述
3. 使用更有个性的表达方式，而非千篇一律的客观叙述
4. 保持原文的核心观点不变

【粘贴原文】
```

**口语化改写**

```text
请将以下文本改写成更口语化、更接地气的风格：
1. 用日常对话中的表达方式替换书面语
2. 加入一些口头禅和生活化表达
3. 适当使用网络流行语（但不要过度）
4. 使用简短句和意犹未尽的表达
5. 保持原意不变

【粘贴原文】
```

**增加情感波动**

```text
请对以下文本进行情感增强处理：
1. 添加情绪化的词汇和表达
2. 在关键点增加感叹和疑问
3. 适当使用强调语气和夸张修辞
4. 在文章中创造情感起伏，而非始终平铺直叙
5. 保持核心信息不变

【粘贴原文】
```

**打破完美结构**

```text
请重新组织以下文本，打破过于工整的结构：
1. 调整段落长度，使其长短不一
2. 打乱过于对称的论点排列
3. 某些部分可以展开详述，而另一些则简明扼要
4. 减少明显的标号和过渡词
5. 保留全部关键信息

【粘贴原文】
```

**增加具体细节**

```text
请为以下文本添加生动具体的细节：
1. 用具体例子替换抽象概念
2. 添加感官描述（视觉、听觉、触觉等）
3. 加入具体数字、时间、地点等信息
4. 描述具体场景或使用场景
5. 保持原文主旨不变

【粘贴原文】
```

**增加犹豫和不确定性**

```text
请修改以下文本，增加一些人类思考中的犹豫和不确定性：
1. 添加表示思考过程的词语（"可能""也许""我在想"）
2. 加入一些自我纠正或思考转向
3. 提出问题后自己尝试回答
4. 表达适当的不确定性和思考局限
5. 保持主要观点不变

【粘贴原文】
```

**加入反常识或意外观点**

```text
请修改以下文本，适当加入一些反常识或出人意料的观点：
1. 挑战 1-2 个常见假设或传统观点
2. 加入一个出人意料但有理有据的角度
3. 提出一个有创意的类比或比喻
4. 不要过度颠覆原文的核心主张
5. 确保新增内容逻辑自洽

【粘贴原文】
```

**增加类比和比喻**

```text
请为以下文本增加生动的类比和比喻：
1. 添加 2-3 个形象的比喻，使抽象概念具体化
2. 使用贴近生活的事物做类比
3. 避免陈词滥调的比喻
4. 确保比喻贴切且易于理解
5. 保持原意不变

【粘贴原文】
```

**加入幽默元素**

```text
请为以下文本增添适当的幽默感：
1. 加入 1-2 处轻松的玩笑或自嘲
2. 使用一些诙谐的表达或夸张的比喻
3. 可以适当调侃常见现象或行为
4. 确保幽默恰当，不影响专业性
5. 保持原有信息和观点不变

【粘贴原文】
```

**加入反问和设问**

```text
请修改以下文本，增加一些反问句和设问句：
1. 在关键论点前加入设问
2. 用反问句强化某些观点
3. 设置问题后自己解答
4. 通过发问引发读者思考
5. 保持原有论点和信息不变

【粘贴原文】
```

#### 结构调整类

**弱化明显的框架词**

```text
请修改以下文本，弱化过于明显的结构框架词：
1. 减少"首先""其次""再次""最后"等明显的序号词
2. 用更自然的过渡词替换公式化的转折词
3. 寻找更巧妙的方式表达逻辑关系
4. 保持逻辑连贯性不变
5. 关键信息保持不变

【粘贴原文】
```

**重写开头和结尾**

```text
请重写以下文本的开头和结尾部分：
1. 开头更有吸引力，可以用疑问、故事或悬念导入
2. 结尾更有力量，给人深思或行动启发
3. 开头和结尾呼应，形成完整感
4. 避免老套的总结性结尾
5. 主体内容保持不变

【粘贴原文】
```

**制造结构中的惊喜**

```text
请修改以下文本，在结构中制造 1-2 处惊喜：
1. 在意想不到的地方插入一个小故事或例子
2. 适当打破常规的内容组织方式
3. 在严肃内容中穿插轻松元素，或反之
4. 安排一个小小的"逆转"或"反转"
5. 保持原有要点和主旨不变

【粘贴原文】
```

#### 内容增强类

**增加故事和案例**

```text
请为以下文本增加 1-2 个相关的故事或案例：
1. 添加真实或虚构但合理的故事
2. 案例应当支持文章的主要观点
3. 故事应该具体、生动，有细节描写
4. 控制故事篇幅，不喧宾夺主
5. 保持原有内容框架不变

【粘贴原文】
```

**增加争议和辩论**

```text
请为以下文本增加一些良性争议或辩论元素：
1. 提出 1-2 个合理的反对意见，然后解释为什么仍坚持原观点
2. 呈现问题的多个角度
3. 承认某些局限性或例外情况
4. 表现出对不同观点的尊重
5. 最终回归并强化原有主张

【粘贴原文】
```

**加入数据和事实支持**

```text
请为以下文本添加相关数据和事实支持：
1. 增加 2-3 处具体数据或研究发现
2. 提供一些事实性的背景信息
3. 引用权威来源或调查（可泛泛提及）
4. 数据应当真实或合理推测
5. 保持原有观点不变

【粘贴原文】
```

**加入个人反思**

```text
请为以下文本添加个人反思和思考过程：
1. 加入"这让我想到""我曾经困惑"等个人思考
2. 分享 1-2 个与主题相关的个人领悟或转变
3. 表达一些思考过程中的疑惑和突破
4. 反思应当自然，不做作
5. 保持原有主旨不变

【粘贴原文】
```

#### 细节优化类

**多样化句式**

```text
请优化以下文本的句式结构：
1. 变换句子长度，混合使用长句和短句
2. 调整句型，包括陈述句、疑问句、感叹句等
3. 改变一些句子的主动/被动语态
4. 调整一些句子的开头词汇，避免重复
5. 保持原意不变

【粘贴原文】
```

**替换形容词和副词**

```text
请优化以下文本中的形容词和副词：
1. 用更生动、具体的词替换笼统的形容词
2. 减少"非常""十分"等程度副词
3. 用新鲜的表达替代陈词滥调
4. 根据上下文语境选择更贴切的修饰词
5. 保持原意不变

【粘贴原文】
```

**增加生活化词汇**

```text
请为以下文本增加更多生活化、接地气的词汇：
1. 用日常用语替换一些书面或学术用语
2. 加入一些通俗易懂的比喻
3. 适当使用生活中常见的事物做参照
4. 避免过于专业化的术语（除非必要）
5. 保持原意不变

【粘贴原文】
```

**混合正式与非正式表达**

```text
请修改以下文本，混合使用正式与非正式表达：
1. 在正式内容中适当加入一些轻松、口语化表达
2. 在解释复杂概念后用简单直白的话总结
3. 形成正式学术语言与日常表达的对比
4. 在重要观点处保持正式表达
5. 次要内容可以更随意活泼

【粘贴原文】
```

***

### 第三部分：AI 模式检测清单（Humanizer-zh 精简版）

这段是从 Humanizer-zh 第 2 轮规则中提炼的 23 种 AI 写作模式。可以拿来自检，也可以直接告诉模型"检查以下文本是否包含下列模式，有就改掉"。

```text
请检查以下文本是否包含以下 AI 写作模式，发现后直接改掉，不要解释：

1. 夸大意义：动不动上升到趋势、象征、里程碑
2. 宣传腔：充满活力的、令人叹为观止的、开创性的、迷人的
3. 模糊归因：专家认为、行业报告显示、观察者指出（没有具体来源）
4. AI 高频词：此外、至关重要、深入探讨、赋能、凸显、彰显、格局
5. 否定式排比："这不仅仅是 X，更是 Y"反复出现
6. 三段式列举上瘾：什么都凑成三点
7. 同义词循环：同一个概念每句换一个说法
8. 破折号过度使用：每段都有破折号
9. 粗体过度使用：大量关键词加粗
10. 填充短语："值得注意的是""不难发现""在这个时间点"
11. 过度限定："可以潜在地可能被认为"
12. 通用积极结论："未来看起来光明""激动人心的时代即将到来"
13. 协作交流痕迹："希望这对您有帮助""当然！""好问题！"
14. 谄媚语气："您说得完全正确""这是一个很好的观点"
15. 系动词回避：用"作为""拥有""设有"代替"是""有"
16. 虚假范围："从 X 到 Y"但 X 和 Y 不在同一尺度上
17. 提纲式展望："尽管面临挑战""未来展望"
18. 表情符号和弯引号
19. 内联标题列表：粗体标题加冒号再加一句话

【粘贴原文】
```

***

### 第四部分：质量自检清单

改完之后，用这段做最终检查：

```text
请对以下改写后的文本做最终质量检查，逐项评估并给出总分（满分 70）：

| 维度 | 评估标准 | 得分 |
|------|----------|------|
| 直接性 | 直接陈述事实还是绕圈宣告？10 分：直截了当；1 分：充满铺垫 | /10 |
| 节奏 | 句子长度是否变化？10 分：长短交错；1 分：机械重复 | /10 |
| 信任度 | 是否尊重读者智慧？10 分：简洁明了；1 分：过度解释 | /10 |
| 真实性 | 听起来像真人说话吗？10 分：自然流畅；1 分：机械生硬 | /10 |
| 精炼度 | 还有可删减的内容吗？10 分：无冗余；1 分：大量废话 | /10 |
| 语义保真 | 原文意思、事实、论点、结论是否完整保留？10 分：完全保留；1 分：明显漂移 | /10 |
| 纯净输出 | 是否彻底避免说明、建议、候选版本、聊天腔？10 分：完全纯净；1 分：污染明显 | /10 |

评分标准：
- 63-70 分：优秀，已去除明显 AI 痕迹且语义稳定
- 49-62 分：良好，仍有改进空间
- 低于 49 分：需要重新修订

另外请检查以下快速项：
- 连续三个句子长度相同？打断其中一个
- 三段式列举？改为两项或四项
- 揭示前有破折号？删除它
- 使用了"此外""然而"等连接词？考虑删除
- 出现"修改后""改写后"等元话语？必须删除
- 原文核心意思、事实、论点发生变化？必须回退重写

【粘贴改写后的文本】
```

***

### 怎么组合使用

拿到一篇 AI 草稿后，推荐这个顺序：

1. **先用主提示词（第一部分）** 从头写或改写一遍，把结构和风格调到位。
2. **用 AI 模式检测清单（第三部分）** 做一轮扫描，把残留的模板腔清掉。
3. **按需用逐条指令（第二部分）** 对特定段落做定向润色，比如某个地方需要加故事、某个地方需要多样化句式。
4. **最后用质量自检清单（第四部分）** 打分，低于 49 分就再来一轮。

如果是在团队里维护提示词，建议参考 yao-open-prompts 的做法：按场景分类、给每条留来源、用版本管理，不要靠聊天记录翻找。

## yao-open-prompts 解决的是"提示词组织"问题

### yao-open-prompts 仓库

`yao-open-prompts` 不是专门做去 AI 味的仓库，但它很适合作为补充材料看。

项目说明写得很清楚：这是一个中文 AI 提示词库，覆盖工作、学习、内容、营销和生活场景，按场景分类整理。它的价值在于：

* 提示词有目录，不是散乱收藏。
* 会标分类、版本、来源区块。
* 明确把第三方内容和主提示词库分开。

这和"去 AI 味"有什么关系？

关系在于，很多人写不好去 AI 味提示词，是因为没有把提示词当成**可维护资产**。今天抄一条，明天改一条，过一阵就没人知道哪条在什么场景下可靠。

`yao-open-prompts` 这种仓库给出的启发是：

* 把提示词分场景。
* 给每条提示词留来源。
* 用版本和分类维护它，而不是靠聊天记录翻找。

如果你要在团队里推广"去 AI 味"工作流，这种仓库式管理比群里发一堆截图靠谱得多。

## 真正该防的，是"失真"

去 AI 味最容易跑偏的地方，是把"看起来像人"放在"内容仍然是真的"前面。

下面这几条，应该直接写死：

### 1. 不能删来源

如果原文有引用、链接、访谈对象、实验来源，润色后也该留着。去 AI 味不该把文本洗成一段没有出处的流畅结论。

### 2. 不能改数字

原文写 48%，你不能因为 50% 更顺口就改成 50%。

原文写"约 30 倍"，你也不能顺手写成"数十倍提升"，除非源头本来就这么说。

### 3. 不能伪造人工痕迹

有些所谓"去 AI 味技巧"会鼓励故意加错字、加口头禅、加情绪波动、加无关插话，营造"这像真人写的"。这种做法很蠢，也很危险。

真实的人写作，不等于随机变乱。

### 4. 不能把不确定改成确定

AI 草稿常常话说太满，但去 AI 味时也不能反向走到另一个极端，把"可能""初步""样本有限"全删掉。证据强度要跟原始材料一致。

## 一个更稳妥的中文去 AI 味流程

把上面的材料合在一起，一条更稳妥的流程大致是这样：

1. 读原文和来源，标出不能动的事实。
2. 用 Humanizer-zh 这类规则工具做第一轮结构和语言清理。
3. 对照 `temp/humanizer-zh.md` 的模式表做人工复检。
4. 如果要补提示词，优先从自己的仓库或 `yao-open-prompts` 这类可维护目录里取。
5. 收尾时再做一次"事实保真检查"：来源、数字、术语、结论有没有漂移。

追求的结果是：

* 读起来像正常中文作者在写。
* 该保留的信息一条没丢。
* 该保留的不确定性没有被抹平。

## 工具选择

如果你要一个可执行的技能，**Humanizer-zh** 最适合直接上手；如果你想看外部工具市场怎么包装这类能力，可以看 **Shyft**；如果你需要搭自己的提示词目录和维护体系，可以参考 **yao-open-prompts**。至于到处搜"去 AI 味神 prompt"，还是会在原地打转。

中文去 AI 味最难的一步，是把句子改顺之后，内容还得是真的。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-startup-native-company-202605.md
description: >-
  从 awesome-ceo、one-person-company、JustHireMe、agency-agents、AiToEarn 到 Anthropic
  创始人手册，整理 AI 时代一人公司最该做的前置判断。
---

# AI 创业与一人公司

过去几年，很多创业建议默认你解决的是"能不能做出来"。

现在这个前提变了。代码、设计、调研、内容分发、运营自动化，都可以被 AI 拉平一大截。创始人最缺的能力，越来越像一件前置工作：在开工之前想清楚，这东西到底值不值得建。

Anthropic 在 2026 年 5 月 14 日发布的《The founder's playbook: Building an AI-native startup》把这件事说得很明确：AI 让创业更像编排系统，执行门槛降下去之后，创始人也更容易一路狂奔，最后做出一个根本没人要的产品。

这篇文章关心的是另一个更难的问题：**如果你只剩下一个人、几个月时间和一堆 AI 工具，你该怎么判断自己现在应该建什么，不应该建什么。**

## 这几份资料各管什么

这几份资料可以分成两类。

第一类是"判断资料"：它们不直接替你交付产品，但会强迫你回答创业里最不舒服的那些问题。

第二类是"链路资料"：它们展示了一人公司实际会用到的执行形态——从验证、交付，到增长、变现，各自大概长什么样。

### `awesome-ceo`：一份创始人的问题清单

`awesome-ceo` 把内容分成 `Fundraising`、`Entrepreneurship`、`Product`、`Sales`、`Marketing`、`Management`、`Hiring`、`Finance`、`Books` 九类。它是一份带明显主观取舍的 CEO 阅读入口。

它的价值不在链接数量，而在于把创始人需要回答的问题摆在了一处：

* 你融资时到底该怎么讲故事，怎么讲估值。
* 你产品的价值、可用性、可行性、商业可行性，分别站不站得住。
* 你前 10 个客户从哪里来。
* 你招人、分钱、做预算时，哪些是最容易一开始就做错的。

如果你顺着里面几篇代表性资料往下看，比如 YC 的种子轮指南、Sam Altman 的 `Startup Playbook`、Marty Cagan 的 `Product is Hard`、Rob Fitzpatrick 的 `The Mom Test`，你很快会发现：好创始人的核心工作，首先是**把问题定义得足够尖锐，以至于错误方案没有藏身之处**。

所以，`awesome-ceo` 适合放在创业前打底。它不能替你判断，但能把你必须判断的维度列完整。

### `one-person-company`：一人公司常见工具坑

`one-person-company` 是中文语境里很典型的一类资料：作者直接把仓库命名成"一人公司"，开门第一句就是"有些工具是宝，有些工具是坑"。

这类资料的价值主要在密度。作者按一人公司最常碰到的工作分成了很多块：

* 大语言模型
* TTS
* 代码
* 设计工具
* 生产力工具
* 网站系列
* 学习系列
* 恶搞系列

其中"代码"下面又继续拆成"全栈开发与快速构建""代码理解与文档"等子类。这种写法很贴近真实创业现场：一个人要做的不只是写代码，还得同时面对选模型、选开发栈、选设计工具、选增长工具、选学习路径。

它的提醒也很重要：**一人公司靠的是持续做工具取舍，不会有一个模型把所有问题一次解决。**

不过，它主要是一张"踩坑地图"，离创业论证还有一段距离。它能帮你少走弯路，但回答不了"为什么值得做"。放在判断之后、执行之前更合适。

### `JustHireMe`：比"自动海投"更重要的是问题定义

官网：<https://www.justhireme.ai>

之所以单独写 `JustHireMe`，是因为它很能说明：产品形态要建立在问题定义足够准确的前提上。

它把自己定义为一个 **local-first AI job intelligence workbench**：本地优先、面向求职情报的桌面工作台。资料重点不在"帮你疯狂投简历"，而在另外几件更克制的事：

* 抓取职位来源并做标准化。
* 用 `Quality Gate` 过滤掉陈旧、低信息量、骚扰型、纯高阶、不适配的岗位。
* 用可解释的规则做职位质量评分和候选人匹配。
* 结合 `Kuzu` 图数据和 `LanceDB` 向量数据，把简历、项目经历和岗位需求对起来。
* 生成定制化的简历 PDF、求职信 PDF、外联草稿，保留人工审阅空间。

它的可视化工作流很清楚，顺序如下：

1. 导入简历 / 个人资料。
2. 建本地图谱和向量索引。
3. 抓取职位来源。
4. 通过质量闸门清洗线索。
5. 做匹配和评估。
6. 生成面向具体岗位的申请材料。

技术栈也明确：前端工作台 + Python sidecar API + SQLite + Kuzu + LanceDB + Tauri；浏览器自动化和 auto-apply 代码虽然存在，但项目明确标成实验性质，默认不作为主打能力。

如果你要研究"求职 / 招聘 / 雇佣效率"这类创业方向，`JustHireMe` 很有参考价值。它提醒你，问题常常出在这些地方：

* 怎样把垃圾线索挡在前面；
* 怎样让匹配理由可解释；
* 怎样让敏感资料留在本地；
* 怎样把 AI 生成的材料保留在"可审阅草稿"的状态。

项目给出的本地开发入口也很具体：

```bash
npm install
cd backend
uv sync --dev
cd ..
npm run tauri dev
```

如果要把它接进 Agent 工作流，仓库还提供了 `skills/justhireme/SKILL.md` 和一个轻量级 MCP server。它更聚焦在**求职与岗位匹配这条链路里最容易被做成黑盒的部分**。

## 两个更贴近执行面的项目

前面三个项目更偏判断与选型，`agency-agents` 和 `AiToEarn` 则更贴近创业进入执行面之后会遇到的两类系统：一个解决"我怎么临时拥有一个团队"，另一个解决"我怎么把内容增长和变现跑起来"。

### `agency-agents`：把一支人工智能服务团队拆成可装配角色

`agency-agents` 的定位非常明确：它是一整套"AI specialists"。资料里还提到，它起源于一个 Reddit 讨论串，之后经历了几个月迭代。

它把不同岗位拆成很多有明确人格、流程、交付物和成功标准的角色，对应"一个全方位的人工智能服务团队，触手可及"的定位。项目文档也列出了更具体的角色名单。例如：

* 工程侧有 `Frontend Developer`、`Backend Architect`、`Rapid Prototyper`、`Security Engineer`。
* 设计侧有 `UI Designer`、`UX Researcher`、`Brand Guardian`。
* 增长侧有 `Growth Hacker`、`Content Creator`、`Reddit Community Builder`。
* 项目推进有 `Project Shepherd`、`Experiment Tracker`。
* 质量与支持有 `Reality Checker`、`Evidence Collector`、`Support Responder`。

它给出的场景设计很像一家小公司会经历的真实链路。

比如"Building a Startup MVP"这个场景，项目直接给出一组搭配：

* `Frontend Developer`
* `Backend Architect`
* `Growth Hacker`
* `Rapid Prototyper`
* `Reality Checker`

它把"谁来做前端、谁来补后端、谁来跑增长、谁来做快速原型、谁来卡上线质量"这件事，用一套角色化的 AI 编排跑起来。

另一个例子是"Marketing Campaign Launch"，它把 `Content Creator`、`Twitter Engager`、`Instagram Curator`、`Reddit Community Builder`、`Analytics Reporter` 组合起来。这很像一人公司最常见的痛点：产品能做，分发做不动。

安装方式也很直接。文档推荐给 Claude Code 装全量角色：

```bash
./scripts/install.sh --tool claude-code
```

如果你只想要某一类角色，也可以手动复制，例如只拷贝工程类：

```bash
cp engineering/*.md ~/.claude/agents/
```

如果你用的是 Copilot、Cursor、Aider、Windsurf、OpenClaw、Kimi、Qwen 这类别的工具，文档也给了统一的转换与安装入口：

```bash
./scripts/convert.sh
./scripts/install.sh
```

这组角色主要落在三个阶段：

1. **产品发现期**：让 `UX Researcher`、`Product Trend Researcher`、`Reality Checker` 帮你把需求问深。
2. **MVP 交付期**：让工程和设计角色分工，减少一个人频繁切角色带来的上下文损耗。
3. **上线后运营期**：把增长、支持、分析这些通常会把创始人拖住的工种做成 AI 版骨架。

它终究还是一套 Agent 角色库，不会自动变成一家公司。编排、取舍和最终决策，仍然在你手里。把它看成一块临时团队工作台更合适。

### `AiToEarn`：一人公司的内容增长与变现工具

官网：<https://aitoearn.ai>

`AiToEarn` 的一句话定位非常直白：**OPC（一人公司）的 AI 内容营销智能体。**

它被定位为"一人公司的 AI 内容营销智能体"，项目则把能力进一步拆成四个词：`Monetize · Publish · Engage · Create`。这四个词合起来，刚好构成一人公司在内容增长上的完整链路。

#### 它覆盖到哪一步

按项目当前说明，`AiToEarn` 面向 OPC、创作者、品牌和企业，支持的渠道覆盖很广，包括：

* 抖音、小红书、快手、哔哩哔哩、视频号、微信公众号
* TikTok、YouTube、Facebook、Instagram、Threads、X、Pinterest、LinkedIn

它把能力拆成四层。

第一层是 **Monetize**：把内容和结果导向的结算机制挂起来，项目列了 `CPS`、`CPE`、`CPM` 三种模式。

第二层是 **Publish**：全网分发和日历排期，解决"同一条内容怎么多平台发"的问题。

第三层是 **Engage**：通过浏览器插件做自动互动、评论回复和高转化信号识别。

第四层是 **Create**：用 Agent 化方式重构内容制作，从想法到成品尽量缩短路径。

很多"一人公司内容工具"只覆盖写作环节，后面的分发、跟进、转化、结算仍然还要手工补。`AiToEarn` 想把后面这段也接起来。

#### 安装 / 使用方式

项目给了 5 种使用方式：

1. 直接打开网站。
2. 在 OpenClaw 里使用。
3. 在 Claude / Cursor / 其他兼容 MCP 的 AI 助手中使用。
4. Docker 一键部署。
5. 源码开发。

接入现有 AI 工作流时，最关键的是第三种。项目明确写了它支持 MCP，接入时要拿 API Key，再按环境选择地址；环境和 Key 不匹配会报 `401`。

对团队或想私有化的人，Docker 路径最短：

```bash
git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d
```

如果需要借用官方凭据完成社交平台授权，文档还要求在 `docker-compose.yml` 里补 `RELAY_API_KEY` 和对应的 `RELAY_SERVER_URL`，再执行 `docker compose restart aitoearn-server`。

本地开发模式也写得很全，后端用 `pnpm nx serve`，前端用 `pnpm run dev`，甚至连一个相关仓库 `AttAiToEarn` 的启动方式都留了出来。看得出来，作者在把整套内容运营链路慢慢产品化。

#### 适用阶段

`AiToEarn` 不适合想法阶段。你还没验证需求时，内容自动化只会把错误判断放大。

它主要对应两个时间点：

* **产品刚上线，需要稳定分发和早期增长时**：把多平台发布、互动、信号采集跑起来。
* **一人公司已经找到初步受众，开始追求变现效率时**：让内容、分发、互动、结算不再完全靠手工。

所以它放到产品上线之后更合适，处理的是**持续曝光和流量转化**这两个问题。

## Anthropic《创始人手册》：判断要不要建

官方博客：<https://claude.com/blog/the-founders-playbook>

官方 PDF：<https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/69fe2a55b93bb0732b1fe33c_The-Founders-Playbook-05062026_v3%20%281%29.pdf>

相关材料已归档到本地：

* 官方博客页：`docs/ai/references/ai-startup-native-company/anthropic-source.html`
* 官方 PDF：`docs/ai/references/ai-startup-native-company/The-Founders-Playbook.pdf`
* 本地转载 HTML：`docs/ai/references/ai-startup-native-company/source.html`

下面这张图是官方 PDF 的封面页：

![Anthropic 创始人手册封面](https://gastigado.cnies.org/d/public/anthropic-founders-playbook-cover.png)

Anthropic 在博客摘要里强调的重点也很集中：这份手册覆盖 `Idea`、`MVP`、`Launch`、`Scale` 四个阶段，讨论如何验证问题、控制技术债、分辨真假 PMF，以及在不同阶段使用 Chat、Claude Cowork、Claude Code。

### 这份手册在讲什么

这一节只做整理，不掺评论。

#### 1. 创业生命周期在 2026 年被重画了

Anthropic 的核心判断是：AI 已经把创业公司的默认增长路径改写了。过去常见的路径是"验证 → 融资 → 招人 → 建产品 → 再融资 → 增长 → 再招人"，现在 AI 抹掉了其中一个默认假设：**每进入一个新阶段，都必须换来更大的团队、更多的职能和新一轮资金。**

手册把 AI Native 创业拆成四个阶段：`Idea`、`MVP`、`Launch`、`Scale`。在这四个阶段里，创始人的角色也在变化：重心会从亲自执行，转到研究、编码和运营自动化系统的编排。

手册把 AI 能力概括成三类：

* 研究与对话式智能：竞品分析、市场测算、投资人材料、PRD、情景推演。
* Agentic coding：把"我有一个想法"压缩成"我已经有一个能工作的产品"。
* 工作流自动化：把排程、CRM、周报、文档、内容发布、合规跟踪等运营性工作从创始人身上卸下来。

#### 2. 想法阶段（Idea Stage）

这一阶段的核心是验证。

手册给出的目标是：在投入资源做产品之前，确认问题真实存在，而且你的方案真的在解决那个问题。

离开这一阶段之前，创始人至少要能回答三个问题：

* 这个问题是否真实且具体。
* 你的方案是否真的在解决实际问题，别停留在最初的自我设想里。
* 你是否已经拿到了足够信号，足以证明做 MVP 是一个经过推理的决策。

手册把这一阶段最典型的失败写得很重：

* 把"能做原型"误当成"已经被验证"。
* 在没有问题—方案匹配之前就开始过早扩张。
* 让 AI 只替你搜集支持证据，结果只是把确认偏误放大得更快。

在工具选择上，手册给了一个非常明确的矩阵：

* 快速问题、改写、头脑风暴，用 `Chat`。
* 研究、分析、基于文件输出完整文档，用 `Claude Cowork`。
* 写代码、测试、真正交付软件，用 `Claude Code`。

#### 3. MVP 阶段（MVP Stage）

Anthropic 认为，MVP 阶段仍然是在收集证据，只是对象从问题空间转向了解决方案本身：真实用户会不会回来、会不会付费、会不会推荐。

这一阶段的目标有两个：

* 把一个已验证的问题做成真实用户会用的最小产品。
* 在快速推进的同时，不积累会在后续持续复利的技术债。

手册特别强调了几类风险：

* `Agentic technical debt`：AI 让速度不再是问题，但如果每个 session 都临时重推架构，代码库会越来越散。
* 虚假的 PMF：漂亮的早期数据不等于产品—市场匹配。
* 零摩擦带来的范围蔓延：功能加得太轻松，反而更容易失焦。
* 不安全的"先上线再说"：AI 生成的代码能跑，不等于已经安全。

它建议创始人在写第一行正式代码前，用 Claude 定义架构原则，并把结果保存成 `CLAUDE.md` 之类的上下文文件，再让 `Claude Code` 进入施工阶段。

#### 4. 上线阶段（Launch Stage）

MVP 解决的是"产品值不值"，上线阶段要解决的是"业务能不能增长"。

Anthropic 给的上线阶段退出条件有三条：

* 增长已经变成可重复、可归因、可解释的渠道增长。
* 产品能承担真实生产负载，安全、合规、可靠性都过关。
* 运营不再严重依赖创始人亲自盯每一环。

这时冒出来的主要问题包括：

* MVP 期间欠下的技术债开始计息。
* 创始人本人开始变成瓶颈。
* 安全与合规不能再拖。
* 很多团队会在准备还不够时就贸然扩市场。

手册建议：

* 用 `Claude Code` 做架构审计和技术债优先级排序。
* 用 `Claude Cowork` 审计运营负担，区分哪些能自动化，哪些必须人工，哪些必须保留给创始人判断。
* 用 Claude 设计轻量产品管理系统，例如 sprint 节奏、最小 spec 模板、bug 分类树、周度指标简报。

#### 5. 规模化阶段（Scale Stage）

到了规模化阶段，创始人的工作重心继续上移：从建设者，变成越来越对外、越来越系统化的管理者。

这一阶段的目标，一方面是把公司做成一门可持续的生意，另一方面是建立更难被复制的护城河。Anthropic 特别强调三种深度：

* 产品里沉淀的领域专业知识。
* 与其他工具平台的深度集成。
* 与时间和场景绑定的专有系统数据与工作流。

退出条件不再只是一个小里程碑，更像一道门槛：公司即使在创始人逐步退出日常细节后，也能持续运转。现实里，这通常体现为可持续盈利、IPO 就绪，或者被收购。

这一阶段的主要难点包括：

* 把创始人脑子里的隐性知识变成可交接、可审计、可复用的系统。
* 把技术运营提升到企业级可靠性。
* 补齐招聘、薪酬、财务、法务等组织功能。
* 从自然增长走向真正的 GTM 组织。

Anthropic 在这里非常强调 `Claude Cowork` 和 `Skills`。前者适合接管工单、续约跟踪、内容流程、CRM 卫生等运营层；后者适合把一再出现的领域流程编码成可复用程序，让公司逐渐积累自己的专有方法。

### 结合四个阶段看 Chat / Cowork / Code 的分工

前面整理的是手册原意，下面结合一人公司场景补几句实际用法。

#### 想法阶段：Chat 负责提问，Cowork 负责归纳，Code 暂不前置

很多人一有点想法，就想立刻开 `Claude Code`。

Anthropic 这里给出的顺序，我基本认同：

* `Chat` 拿来做高频、快速、尖锐的问题追问。它最适合扮演那个不停打断你的角色：到底是谁痛，多久痛一次，为什么现有工具没解决。
* `Claude Cowork` 用来整理访谈、竞品、行业资料，把多个来源压缩成一个可读文档。
* `Claude Code` 放到已经有了初步证据之后，再去做轻量原型。

想法阶段最怕的，就是在证据还不够的时候把速度拉满。

#### MVP 阶段：Code 是施工主力，Cowork 管上下文，Chat 管小决策

一旦进入 MVP，`Claude Code` 就该成为主工具，但有一个前提：架构、范围、约束文档写清。

这一阶段最容易犯的错，是让每次 session 都从头开始，于是功能虽然在涨，系统却越来越散。更稳的做法是：

* 用 `Claude Cowork` 维护 spec、范围约束、评审记录、指标定义；
* 用 `Claude Code` 真正写、改、测、重构；
* 用 `Chat` 处理零碎判断，例如一句对外说明、一段定位文案、一个灰区案例的快速讨论。

#### 上线阶段：Cowork 的价值突然变大，因为创始人的注意力才是真瓶颈

产品一上线，很多创始人还以为自己最缺的是更多代码。实际上，这时最缺的往往是注意力预算。

客服、发布、数据汇总、需求优先级、内容更新、运营对接，都会开始抢你的脑子。到了这里，`Claude Cowork` 承担的就是串系统、拉文档、跑定时任务这类运营工作。

对应地：

* `Claude Code` 继续负责技术债审计、测试补强、上线前安全检查；
* `Claude Cowork` 负责把零碎运营变成可重复流程；
* `Chat` 更适用于日常判断和对外表达润色。

#### 规模化阶段：护城河来自你沉淀了什么

等公司进入规模化，几乎所有人都会"用 AI"。这时差异更多在积累。

谁把领域知识写进了 `Skills`、写进了测试集、写进了内部流程；谁把灰区案例、合规要求、客户偏好、组织经验变成了系统的一部分，谁的 AI 才会越来越像公司资产，越来越接近组织能力。

所以到这个阶段：

* `Chat` 可以当成创始人的随身思考伙伴；
* `Claude Cowork` 负责运营系统和组织知识的编排；
* `Claude Code` 继续负责技术护城河和测试护城河的建设。

## 放回一人公司的日常里看

把这些资料放在一起看，几条分工线会更容易看清。

`awesome-ceo` 帮你看清创始人到底要回答哪些问题；`one-person-company` 告诉你一人公司在工具层会碰到什么现实摩擦；`JustHireMe` 展示了一个好问题定义如何长成产品；`agency-agents` 提供了临时团队的角色骨架；`AiToEarn` 则把增长和变现这条最累的链路做成了可接入系统。

但无论工具多全、角色多细、交付多快，都替代不了一个最前置的问题：

**这个东西值得建吗？**

如果你现在已经准备开工，至少把问题验证、MVP 证据和上线后的运营负担分开看，再决定该调用哪些工具。AI 会把执行提速，但前面的判断还是省不掉。

## 参考链接

* `awesome-ceo`：<https://github.com/kuchin/awesome-ceo>
* `one-person-company`：<https://github.com/cyfyifanchen/one-person-company>
* `JustHireMe` GitHub：<https://github.com/vasu-devs/JustHireMe>
* `JustHireMe` 官网：<https://www.justhireme.ai>
* `agency-agents`：<https://github.com/msitarzewski/agency-agents>
* `AiToEarn` GitHub：<https://github.com/yikart/AiToEarn>
* `AiToEarn` 官网：<https://aitoearn.ai>
* Anthropic 官方博客：<https://claude.com/blog/the-founders-playbook>
* Anthropic 官方 PDF：<https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/69fe2a55b93bb0732b1fe33c_The-Founders-Playbook-05062026_v3%20%281%29.pdf>
* 代表性阅读：YC `A Guide to Seed Fundraising`、Sam Altman `Startup Playbook`、Marty Cagan `Product is Hard`、Stripe `Your first 10 customers`、Rob Fitzpatrick `The Mom Test`

---

---
url: https://ain.hmgf.hxcn.space/ai/claude-code-team-podcast-notes-202605.md
description: >-
  从小宇宙第 115 期《Claude Code 深度探秘》与 Anthropic 后续公开资料出发，整理 Claude Code 团队的分工、推进方式与对
  AI Agent 团队的启发。
---

# Claude Code 团队是怎么工作的

> 跨国串门儿计划播客：最近听到的非常实用、信息不拖沓的 Claude Code / Anthropic 团队如何运营组织、如何工作的分享。非常适合身处或正在管理构建 AI Agent 产品的团队朋友听。里面有详实故事讲述团队分工、大家的做事方式以及变化，很实用。

结合 Latent Space 原始节目、Lenny's Podcast 访谈和 Anthropic 官方案例，可以看到更多关于团队分工和推进方式的细节。

**播客内容属于团队成员口述经验，不等同于 Anthropic 官方制度文件。**

## 节目与公开资料

播客入口：<https://www.xiaoyuzhoufm.com/episode/681f316cb7c8a9962c640438>

小宇宙页显示，这一期是《跨国串门儿计划》第 115 期，发布时间是 **2025 年 5 月 10 日**，标题是《Claude Code 深度探秘：对话 Anthropic 核心团队成员》。节目说明也写明了它是对 Latent Space 那期 *Claude Code: Anthropic's CLI Agent* 的翻译克隆版本。

![《跨国串门儿计划》第 115 期页面截图](https://gastigado.cnies.org/d/public/xiaoyuzhou-episode-115.png)

播客与补充资料：

* 小宇宙页面（播客平台）：<https://www.xiaoyuzhoufm.com/episode/681f316cb7c8a9962c640438>
* Latent Space 原始节目与转录（播客 / 社媒发布）：<https://www.latent.space/p/claude-code>
* Claude Code 官方总览（官方文档）：<https://docs.claude.com/en/docs/agents-and-tools/claude-code/overview>
* How Anthropic teams use Claude Code（官方案例）：<https://www.anthropic.com/news/how-anthropic-teams-use-claude-code>
* Running an AI-native engineering org（Anthropic 活动页）：<https://claude.com/code-with-claude/session/sf-running-an-ai-native-engineering-org>
* How Anthropic's product team moves faster than anyone else | Cat Wu（播客）：<https://www.lennysnewsletter.com/p/how-anthropics-product-team-moves>
* 对应的中文翻译播客页（Apple 播客页）：<https://podcasts.apple.com/cn/podcast/claude-code-%E4%BA%A7%E5%93%81%E8%B4%9F%E8%B4%A3%E4%BA%BA-anthropic-%E4%BA%A7%E5%93%81%E5%9B%A2%E9%98%9F%E5%A6%82%E4%BD%95%E5%BF%AB%E9%80%9F%E8%BF%AD%E4%BB%A3/id1831665175?i=1000763377762>

单独听这一期，侧重在 Claude Code 的功能；结合多份材料，可以看到更多关于团队分工和反馈机制的细节。

## 团队分工：需求入口不只 PM

按 Latent Space 这期转录，Claude Code 早期核心团队至少可以明确看到几层角色：

* **Boris Cherny**：创始工程负责人，最早的原型推动者
* **Cat Wu**：产品负责人，负责路线梳理、跨部门清障、对外发布配合
* **Sid、Ben 等早期成员**：和 Boris 一起把内部实验推成正式团队
* **内部研究员与工程师**：最早一批高频用户，也是最重要的反馈来源

播客里有个细节很能说明这支团队是怎么长出来的。团队并没有先把 org chart 画满再去招人。Boris 做了一个能在终端里跑的原型，内部使用数据迅速上涨，团队才逐步补齐 PM 和更多支持角色。Cat Wu 也是因为自己在用早期版本做数据可视化、持续给反馈，后来直接被拉进核心团队。

不少传统团队会由 PM 定义需求，再排期开发，上线后再收反馈。Claude Code 的起步顺序反过来了：工程师做出一个足够有用的原型，内部高密度使用者很快把问题和机会都暴露出来，PM 再把已经浮现的方向整理清楚，把发布、法务、营销、协同这些障碍清掉。很多新功能，本来就是团队成员给自己补工具时长出来的。

Cat Wu 在 Latent Space 那期里说自己是 **"light touch PM"**。她的工作重点不在把 roadmap 层层拆成任务、再逐项下派，而是做三件事：

* 观察需求有没有持续生命力；
* 判断哪些方向和模型未来几个月的能力曲线一致；
* 让工程团队别被非核心障碍拖慢。

这也是为什么她后来在 Lenny's Podcast 那期里继续强调，Claude Code 团队很多方向都来自最接近问题的人直接动手试出来，再由团队收束。

## 反馈入口：研究员、工程师、设计、法务都算"产品用户"

只看播客，你会觉得 Claude Code 主要是给工程师用的。Anthropic 2026 年那篇《How Anthropic teams use Claude Code》把这件事补完整了：**在 Anthropic 内部，Claude Code 早就成了跨职能工作界面，不再只是工程团队工具。**

官方案例里能看到的使用群体包括：

* Product Engineering
* Product Design
* Security Engineering
* Inference team
* Data Infrastructure
* Growth Marketing
* Legal team
* Data scientists

这意味着他们拿到的"用户反馈"已经不只局限于 bug 反馈，还包括不同职能的工作流反馈。

比如：

* Product Engineering 把它当成排查 bug、定位改动入口的第一站；
* Product Design 不只让它写测试，还会在设计阶段让它帮忙枚举错误状态、异常情况和逻辑流；
* Security Engineering 用它处理 incident、写 runbook、推 TDD 流程；
* Growth Marketing 拿它批量处理广告文案和自动化流程；
* Legal team 甚至会用它做内部流程工具原型。

高价值反馈往往来自那些把产品接进自己真实工作流的人。

如果一个团队内部只有产品经理和工程师在试用，你拿到的反馈通常还是功能级的；但当设计、法务、营销、研究、数据团队都在用时，你拿到的就是工作方式级的反馈。

## 他们怎么决定做什么

### 自发使用跑出来后，团队才扩大投入

Boris 在原始播客里讲得很直白：Claude Code 一开始没有什么宏大总计划，就是一个实验。后来之所以逐步变成正式产品，是因为内部使用量涨得太快，已经很难忽视。

判断标准是：**真实采用跑出来，团队再扩编。**

做法很直接：让一个足够小的东西先在真实环境里跑，等使用强度自己长出来，再加人、加支持、加发布节奏。

这条逻辑在 Cat Wu 后来的访谈里也能对上。她提到 Anthropic 内部很多产品迭代，不再按半年、一季度那种节奏去算，而是尽可能压到周、甚至天。推动节奏变快的，是**减少了"先证明一切、再允许动手"的组织惯性**。

### 围着模型三个月后的能力来想路线

Latent Space 里另一个很有意思的点，是 Cat Wu 说团队会一起想：**模型在三个月后会更擅长什么？**

这个问题对 AI 产品团队，因为很多功能如果只按今天的模型能力来设计，三个月后就会显得过度补丁化；反过来，如果完全等模型成熟再做，窗口可能已经过去了。

所以他们想的是基于近期能力跃迁仍能成立的最小设计，尽量少做只对今天有效的局部补丁。

Claude Code 为什么一直强调：

* 做简单的事；
* 做能工作的最小结构；
* 尽量让文本 I/O 成为核心接口；
* 不急着把一大堆复杂交互固化进 UI。

因为模型能力变化太快，**结构越轻，越容易跟着模型进化；结构越重，越容易在下一轮能力变化里变成包袱。**

### 优先级讨论，不只看用户想要什么

Cat Wu 在 2026 年那期产品访谈里还提到另一层判断：如果碰到冲突优先级，团队会看哪件事更符合 Anthropic 的总体使命。

常见情况是：

* 用户要的很多；
* 模型能做的越来越多；
* 团队每周都能冒出十几个"马上能做"的方向；
* 结果每件都沾一点，节奏却越来越散。

Anthropic 这里用的是使命；小团队未必有这么大的叙事，但至少也该有一条**比单次需求更高的取舍原则**。

## 他们怎么推进：事情跑起来，流程再跟上

### 产品推进靠持续清障，不靠完美排期

Cat Wu 在播客中描述的 PM 角色侧重于清除障碍。她说自己更多是在确保 legal、marketing 这些事情不挡路。这个表述背后包含的是一套很成熟的协作观：

* 强产品感不只属于 PM；
* 工程师可以直接提出产品方向；
* PM 的价值不一定在"提出更聪明的点子"，而在"让正确的人推进时不被流程卡住"。

因为很多好功能不是在需求讨论会上想出来的，往往是工程师在真实使用中"顺手发现必须补一个东西"。

### 并行、自动化、可组合，是他们默认的推进方式

无论是原始播客还是后续 Every 的访谈，Claude Code 团队都强调：他们更愿意把它做成 Unix utility 那类可组合工具。

这个理念会直接影响团队自己的工作方式。

在他们眼里，产品是一组可组合的能力：

* 可以并行跑多个 session；
* 可以接进 tmux、GitHub Actions、CI、hooks；
* 可以通过 slash commands 把高频动作压成短命令；
* 可以让 subagents 分工，再互相挑错。

Every 那篇访谈里提到 Boris 会让多个 subagents 并行做 code review：有的查风格，有的看历史实现，有的找明显 bug，之后再开第二轮 agent 专门去质疑第一轮结论，尽量减少误报。

"多 agent"已经是日常工作结构的一部分：**并行审阅、相互校验、自动初筛、人类最终把关**。

### 团队会把共识写进环境

Every 那篇访谈里还有两个很实用的点：

* 用共享 `settings.json` 预先批准常见命令、拦掉高风险操作；
* 让 Claude 写 task diary，再蒸馏成可复用的经验。

这两件事都在做同一件事：**把团队经验外化。**

很多 AI 团队内部都有一些 tacit knowledge，比如：

* 哪些命令可以放行；
* 哪些路径不要碰；
* 什么样的日志有价值；
* 哪类任务适合并行拆；
* 哪些修改一定要人工过一遍。

问题是，如果这些经验只留在少数资深成员脑子里，团队规模一扩大，产出就会马上不稳定。

Claude Code 团队的思路，是尽量把这些东西变成：

* 配置；
* slash commands；
* hooks；
* 共享记忆文件；
* 自动 review 流程。

这比"写一篇大家都不看的 wiki"，因为它直接进入了执行环境。

## 他们怎么处理变化

### 产品默认会变，所以接口要轻

Claude Code 的很多设计，都能看出他们默认"变化会非常频繁"。

例如播客里反复提到的几件事：

* 记忆用最简单的 Markdown 文件实现；
* 上下文压缩直接让 Claude 自己总结；
* 规划能力也尽量用文本接口承载；
* 工具尽量少而通用，能删就删。

这种做法是在主动给变化留空位。AI 产品和传统 SaaS 功能树不太一样，很多今天看起来必须存在的中间结构，下一代模型可能直接就吞掉了。

Apple 播客那页对 Cat Wu 访谈的中文摘要里，把这一点说得很清楚：有些功能在早期像"拐杖"，是为了补模型短板；一旦模型长出来，这些额外结构就该逐步移除。

他们看重的是功能能不能继续成立。早期可以拿临时结构补短板，模型长出来后就把这些结构撤掉。

### 用户的"误用"也是需求线索

Every 那篇访谈里，Boris 提到一个非常典型的产品判断：把产品做得足够可 hack、足够开放，让用户能拿去做原本没设计过的事情；然后观察这些"误用"，再判断里面有没有稳定需求。

这和 Claude Code 自己的成长路径是同一条线。最早它也是内部实验，后来因为大家用得越来越多、用法越来越野，才逐渐被认定为值得正式投入。

因为大家还在共同摸索工作界面，很多价值不是从设计图里推出来的，而是在使用中长出来的。

一个团队如果只统计"用户有没有完成既定流程"，往往会错过更大的机会。更应该看的还有：

* 用户把它接到了哪些本来没想到的地方；
* 哪些职能的人开始自学使用；
* 哪些功能起初不在主流程里，却高频出现在边缘工作流里。

### 工具变了，流程也得重写

Fiona Fung 在 `Running an AI-native engineering org` 那场分享里的简介写得很直接：当 agentic coding 从个人工具变成组织默认方式，流程会先被改写；被打碎的往往是 **review、ownership、hiring** 这些原本看似稳定的组织规则。

很多团队会以为"AI 提效"就是同样的人、同样的流程、只是写得更快。但如果产出速度、并行能力、跨角色协作方式都变了，原来的 review、职责边界、招聘标准，很可能就不再适配。

变化管理更该追问的是：

* 代码审查还该怎么分层；
* 谁对 agent 产出的结果负责；
* 交付周期缩短后，发布机制要不要改；
* 招人时到底更看重写代码能力、判断力，还是编排 agent 的能力。

## 对 AI Agent 团队的启发

如果要把上面的材料带回自己团队，可以从下面几件事试起。

### 1. 内部离不开的原型，比满编团队更重要

Claude Code 的起点是一个被内部高频采用的原型，组织设计是后补的。对小团队来说，更重要的是证明"有人离不开"，再讨论要不要扩编。

### 2. PM 的工作，很多时候是清障

当工程师、研究员、设计师都在用产品时，很多最好功能来自使用现场。PM 更该做的是提炼方向、处理依赖、协调对外发布，不必把自己卡成唯一需求入口。

### 3. 反馈体系要跨职能

如果你的 AI Agent 只在工程组内流转，你得到的只是工程反馈；如果它进入销售、运营、法务、设计、数据团队，你得到的才是工作流反馈。后者对产品演化更关键。

### 4. 用轻结构对冲模型变化

别太早把大量复杂机制焊死。模型还在快速进化，今天的补丁功能，明天可能会变成负担。能用简单文件、文本接口、可替换模块解决的问题，先别上过重结构。

### 5. 把团队经验写进环境

共享设置、自动 review、slash commands、hooks、任务日志，这些都在做同一件事：让团队能力可复制。AI Agent 团队越早把经验外化，越不容易在规模稍微变大时掉速。

### 6. 自动化要能稳定托付

Apple 播客页对 Cat Wu 访谈的摘要里有一句话其中提到：95% 的自动化，很多时候等于没有自动化。因为只要人还得时刻盯着最后那 5%，流程就没有真正交出去。

这句话是在提醒团队尽快做判断：如果它还只是辅助，就按辅助来设计；如果它要接管流程，就做到能被放心托付。最消耗人的，往往是长期停在中间状态。

## 引用说明：这是一组口述资料

* 小宇宙第 115 期是对外文播客的翻译克隆版；
* Latent Space 与 Lenny's Podcast 的主体内容，都属于嘉宾口述；
* Apple 播客页里的中文摘要，是二次翻译与整理；
* Anthropic 官方文档、官方新闻稿、官方活动页，属于更容易核验的一手公开资料。

所以这篇文章适合拿来理解 Claude Code 团队的**协作方式和产品推进习惯**，不适合把某一句话直接上升成 Anthropic 的正式制度。

比较稳妥的读法是：用播客理解他们怎么想、怎么协作，再用官方资料核对哪些做法已经体现在正式产品与公开案例里；带回自己团队时，只保留那些确实能用的结构。

## 一个 AI Agent 团队复盘提纲

如果你想拿这篇去复盘自己的团队，可以直接照下面这组问题开会：

### 一、分工

* 我们现在的产品方向，主要是谁在提出？
* 工程、设计、研究、运营、销售里，谁是真正高频使用者？
* 哪些角色在给反馈，哪些角色其实还没被接进来？

### 二、优先级

* 我们现在决定做什么，靠的是老板判断、客户催促，还是实际使用强度？
* 有没有一条比单次需求更高的取舍原则？
* 我们做的功能，有多少是在为三个月后的模型能力做铺垫？

### 三、推进方式

* 哪些工作还在串行推进，本来可以并行？
* 哪些高频动作已经写成命令、脚本、模板、hook 或共享配置？
* 现在的 review 机制，适配 agent 产出了吗？

### 四、变化管理

* 我们有哪些"临时补丁"已经该撤掉了？
* 用户有没有把产品拿去做我们原本没设计过的事？
* 这些"误用"里，哪些会变成下一步产品机会？

### 五、团队能力

* 团队里哪些经验还只掌握在少数人脑子里？
* 哪些任务已经能放心托付给 agent，哪些还只是辅助？
* 如果今天团队规模翻倍，我们的工作方式会不会立刻失稳？

如果这些问题还没系统聊过，拿这五组问题开一次会，通常比继续补功能列表更有用。

---

---
url: https://ain.hmgf.hxcn.space/ai/free-ai-courses-roadmap-202605.md
description: >-
  把 6 门免费 AI 课程按前置知识和难度排成一条可执行路线，从 AI 101、Foundation Models and Generative AI
  到机器学习、深度学习和经典 AI。
---

# 免费 AI 课程路线

6 门 MIT OCW 免费 AI 课程，前置知识差很多，硬混着看会越看越乱。这篇把它们按难度串起来。

下面把 6 门课程按难度和前置知识串起来。6 门课摆在一起之后，更容易看出谁适合完全零基础，谁需要一点 Python，谁默认你已经能跟上线代、微积分和算法。

## 6 门课与原始说明

下面 6 条课程按顺序整理，附可直接点开的课程页：

* [MIT AI 101](https://ocw.mit.edu/courses/res-6-013-ai-101-fall-2021/)：适合完全小白打底。
* [Foundation Models and Generative AI](https://ocw.mit.edu/courses/6-s087-foundation-models-and-generative-ai-january-iap-2024/)：解释 ChatGPT 等基础模型如何运作。
* [How to AI (Almost) Anything](https://ocw.mit.edu/courses/mas-s60-how-to-ai-almost-anything-spring-2025/)：侧重把 AI 用到音乐、艺术、系统设计等创意领域，需要一点 Python。
* [MIT Intro to Deep Learning](https://introtodeeplearning.com/)：动手实验多，需要初等微积分和线性代数。
* [Introduction to Machine Learning](https://ocw.mit.edu/courses/6-036-introduction-to-machine-learning-fall-2020/)：核心课，需要线性代数、概率统计、编程基础。
* [Artificial Intelligence](https://ocw.mit.edu/courses/6-034-artificial-intelligence-fall-2010/)：经典本科 AI 课，教知识表示、问题求解、搜索算法等传统 AI 方法论，需要编程经验、离散数学等 CS 基础。

## 1. MIT AI 101：给完全没进过门的人铺地板

### MIT AI 101

课程页：<https://ocw.mit.edu/courses/res-6-013-ai-101-fall-2021/>

这门课最适合拿来解决"我连术语都不熟"的问题。MIT OCW 的课程说明写得很明确：它面向 **little to no background** 的学习者，用 machine vision、data wrangling、reinforcement learning 这些词做入口，讲概念，再带一个互动练习，让参与者自己训练一个算法。

它的体量不大，本身就是一门入门 workshop，放在最前面用来建立基本词汇表很合适。

### 这门课会学到什么

按课程页和 supporting materials 的描述，重点在三件事：

* 常见 AI 术语
* 让你知道一个简单算法是怎么"被训练"的
* 收尾的总结和问答

它不追求系统数学推导，也不要求你先会写程序。

### 适合谁

* 完全没系统学过 AI 的人
* 只听过 ChatGPT、机器学习这些词，但解释不清的人
* 想用一门短课确认自己要不要继续往下学的人

### 前置知识

这门课基本可以按零门槛处理。真要说前置，只需要：

* 愿意看英文材料
* 对"算法训练"这件事有一点好奇心

如果你身边有人想知道 AI 到底在讲什么，从这门开始最稳。

![MIT AI 101 封面图](https://gastigado.cnies.org/d/public/mit-ai-101-cover.png)

## 2. Foundation Models and Generative AI：生成式 AI 基础

### Foundation Models and Generative AI

课程页：<https://ocw.mit.edu/courses/6-s087-foundation-models-and-generative-ai-january-iap-2024/>
官网：<https://www.futureofai.mit.edu/>

这门课的价值，在于它正面回答了很多人最近两年最常问的问题：ChatGPT、Copilot、CLIP、DALL-E、Stable Diffusion、AlphaFold，这些系统为什么突然一起冒出来？背后的共同逻辑是什么？

MIT OCW 的课程说明把定位写得很直白：这是一个 **non-technical series of lectures**。它会从 AI 简史开始，讲监督学习和强化学习缺了什么，再落到 foundation models、self-supervised learning，以及它们对科学和商业的影响。

如果你已经知道"现在大家都在讲大模型"，但总觉得概念一团糊，这门课很适合接在 AI 101 后面。

### 这门课会学到什么

从官方课程页和 `futureofai.mit.edu` 上的说明看，重点包括：

* AI 历史脉络
* 为什么这波突破集中出现在 foundation models 和 generative AI
* ChatGPT、Copilot、CLIP、DALL-E 这些系统背后的共同框架
* self-supervised learning 在里面扮演什么角色
* 这些技术落到科学和商业里的方式

它更偏"解释这场变化为什么发生"。想自己训练模型，还得往后走。

### 适合谁

* 已经用过生成式 AI，但想补系统解释的人
* 产品、内容、运营、设计背景，想理解大模型基本原理的人
* 需要和技术团队对话，但暂时还不准备直接啃公式的人

### 前置知识

官方页面强调 **All backgrounds are welcome**。所以这门课依然不把数学当门槛。更现实的前置要求是：

* 知道一些最基本的 AI 词汇
* 对生成式 AI 的应用场景有直觉

也就是说，学完 AI 101 再上这门，衔接最自然。

![Foundation Models and Generative AI 封面图](https://gastigado.cnies.org/d/public/foundation-models-generative-ai-cover.png)

## 3. How to AI (Almost) Anything：适合想把 AI 带进创意和多模态场景的人

### How to AI (Almost) Anything

课程页：<https://ocw.mit.edu/courses/mas-s60-how-to-ai-almost-anything-spring-2025/>


这门课和前两门的气质不太一样。它直接把问题换成：如果 AI 不只处理文字，还要碰视觉、音频、传感器、医疗数据、音乐、艺术，方法会怎么变？

MIT OCW 的课程说明写到，它会介绍 modern deep learning、foundation models，以及把 AI 用到新数据模态的方法；还会讲 multimodal AI，讨论 language 和 multimedia、music 和 art、sensing 和 actuation 怎么连起来。

这也是"音乐、艺术、系统设计等创意方向"的依据。

### 这门课会学到什么

按 OCW 页面和课程站说明，内容重点包括：

* 不同数据模态下的 AI 思路
* modern deep learning 和 foundation models 在多模态场景里的用法
* multimodal AI 的基本概念
* 课程讨论、阅读和研究型作业

它已经进入"把 AI 带进具体创意或研究场景"的范围了。

### 适合谁

* 对音乐、艺术、媒体、设计、交互很感兴趣的人
* 已经不满足于只聊文本模型的人
* 想理解多模态 AI 会怎样进入真实应用的人

### 前置知识

课程需要一点 Python 基础，这个方向和课程形态是对得上的。虽然 OCW 首页没有把 Python 明写成硬门槛，但它毕竟是 MIT Media Lab 风格的研究型课程，带阅读、讨论和项目，完全零编程基础会比较吃力。

前置知识是：

* 至少会一点 Python
* 知道深度学习和 foundation models 的基本名词
* 能接受课程里有研究阅读和项目思维

如果你的目标偏创意方向，这门课可以比深度学习核心课更早看；如果你想走技术实现路线，可以把它放在旁支阅读。

![How to AI (Almost) Anything 封面图](https://gastigado.cnies.org/d/public/how-to-ai-almost-anything-cover.jpg)

## 4. MIT Intro to Deep Learning：开始动手跑神经网络和实验

### MIT Intro to Deep Learning

课程页：<https://introtodeeplearning.com/>


到这一步，课程强度就明显上来了。MIT 6.S191 是一个高强度 deep learning bootcamp。官方页面写得很清楚：它讲 vision、robotics、medicine、language、game play、art 等应用，也会覆盖 large language models 和 generative AI，还配了公开 slides、videos 和 labs。

这门课特别适合已经下定决心要动手的人，因为它不只讲，还让你跑 lab。

### 这门课会学到什么

从课程站和 GitHub 仓库说明页能确认的内容包括：

* 深度学习基础
* sequence modeling
* computer vision
* generative modeling
* reinforcement learning
* LLM fine-tuning
* 带代码的 software labs

仓库说明还写明了 labs 会在 Colab 上跑，通常需要切到 Python 3 和 GPU 环境。

### 适合谁

* 已经决定要做模型实验的人
* 想通过 lab 建立神经网络直觉的人
* 想从"会聊 AI"往"能做实验"走的人

### 前置知识

这门课的前置要求，官方页面直接给出来了：

* calculus
* linear algebra
* Python 最好会一点

课程站原话是：**Experience in Python is helpful but not necessary**，但真实学习体验里，完全不会 Python 会很难把 lab 跑顺。所以实操上最好把它理解成：

* 微积分和线代最好补过
* Python 至少会基础语法、函数、数组或 notebook 操作

如果你还没碰过矩阵乘法和导数，这门课不建议硬上。

![MIT Intro to Deep Learning 课程图](https://gastigado.cnies.org/d/public/mit-intro-deep-learning-video-frame.jpg)

## 5. Introduction to Machine Learning：把机器学习核心概念系统过一遍

### Introduction to Machine Learning

课程页：<https://ocw.mit.edu/courses/6-036-introduction-to-machine-learning-fall-2020/>
官网：<https://openlearninglibrary.mit.edu/courses/course-v1:MITx+6.036+1T2019/about>

6.S191 是高强度 deep learning bootcamp，6.036 则是机器学习主干课。MIT OCW 的课程说明里提到 modeling and prediction、representation、over-fitting、generalization，以及 supervised learning 和 reinforcement learning。

Open Learning Library 的课程页还补了学习形式：lectures、lecture notes、exercises、labs、homework problems 都有，长度 13 周，预计每周约 12 小时。

这门课的系统性更强，更适合作为系统补课的主线课程。

### 这门课会学到什么

从 OCW 和 Open Learning Library 的说明看，核心内容包括：

* 学习问题的建模
* 表示、过拟合、泛化
* 监督学习
* 强化学习
* 图像和时序数据上的应用
* 配套讲义、练习、实验和作业

它讲的是一整条机器学习主线，不只停在大模型热词上。

### 适合谁

* 想系统学机器学习，而不想只从大模型热词入手的人
* 准备继续读深度学习、推荐系统、强化学习的人
* 需要把概念、练习和作业连起来的人

### 前置知识

Open Learning Library 的课程页把推荐前置写得很直接：

* Computer programming (Python)
* Calculus
* Linear Algebra

概率统计也是前置要求之一。虽然课程页摘录里没有把 probability 单独写成同一行门槛，但实际学这门课时，没有概率直觉会比较吃力。所以更稳妥的准备是：

* Python 基础
* 微积分
* 线性代数
* 概率统计入门

这门课适合放在深度学习 bootcamp 前后搭配着学：如果你更看重理论顺序，可以 6.036 再 6.S191；如果你更需要动手反馈，也可以 6.S191 建直觉，再回 6.036 补系统框架。

![Introduction to Machine Learning 封面图](https://gastigado.cnies.org/d/public/introduction-to-machine-learning-cover.jpg)

## 6. Artificial Intelligence：回到经典 AI 方法论

### Artificial Intelligence

课程页：<https://ocw.mit.edu/courses/6-034-artificial-intelligence-fall-2010/>

6.034 很值得留到后面认真看。原因很简单：很多人现在学 AI，前面全是模型、训练、生成，但对传统 AI 里的问题表示、搜索、知识结构、推理方法反而没有系统概念。6.034 正好补这个缺口。

MIT OCW 的课程描述写的是：knowledge representation、problem solving、learning methods。学完以后，学生应该能把这些方法拼到具体 computational problems 上，也能理解 vision、language 和 human intelligence 在计算视角下怎么被看待。

### 这门课会学到什么

按课程页和 syllabus 的结构，这门课包括：

* knowledge representation
* problem solving
* learning methods
* lecture videos
* programming assignments
* exams
* tutorials

这是一门很典型的本科 AI 课程，方法论味道很重。

### 适合谁

* 想补"传统 AI"框架的人
* 学过一点机器学习后，想理解搜索、表示、推理的人
* CS 背景较强，准备往算法和智能系统方向继续走的人

### 前置知识

它需要编程经验、离散数学等 CS 基础。课程 syllabus 页面还能确认 problem sets 以 Python 程序提交。

更稳妥的前置知识是：

* 编程经验
* 数据结构和基础算法
* 离散数学或逻辑基础
* 读英文课程材料的耐心

如果你完全是冲着大模型来学，这门课一开始可能会觉得"离当前热点有点远"；但真想把 AI 方法论补完整，6.034 很有价值。

![Artificial Intelligence 封面图](https://gastigado.cnies.org/d/public/artificial-intelligence-cover.jpg)

## 两条路线怎么读

如果你想走一条尽量平滑的路线，可以按下面这个顺序：

1. **MIT AI 101**：补术语和基本直觉。
2. **Foundation Models and Generative AI**：把这波生成式 AI 讲清楚，知道 ChatGPT 一类系统大概怎么来的。
3. **How to AI (Almost) Anything**：如果你偏创意、多模态、媒体和设计方向，这里可以提前插进来。
4. **Introduction to Machine Learning**：开始系统学机器学习主线。
5. **MIT Intro to Deep Learning**：进入实验、神经网络和 lab。
6. **Artificial Intelligence**：回头补传统 AI 的知识表示、搜索、推理和方法论。

如果你走的是更偏技术的路线，主线看成：

* AI 101
* Foundation Models and Generative AI
* Introduction to Machine Learning
* MIT Intro to Deep Learning
* Artificial Intelligence

**How to AI (Almost) Anything** 更适合作为方向扩展课，尤其适合对音乐、艺术、系统设计、多模态应用感兴趣的人。这样排的好处很直接：前两门建立词汇和问题意识，中间两门补机器学习与深度学习主线，最后再回头看传统 AI，很多概念会更容易对上。

---

---
url: https://ain.hmgf.hxcn.space/ai/llm-learning-roadmap-202605.md
description: >-
  用 Dive into LLMs 建立主题地图，再用 minimind、minimind-v、minimind-o 走一遍从语言模型到视觉多模态、全模态
  Omni 的动手路线。
---

# 大模型学习路线：从 Dive into LLMs 到 minimind

大模型教程最容易让人收藏一堆链接，然后迟迟不动手。

这篇只做一件事：把几套适合工程实践的材料按项目本身串成一条路。上海交大的 `Dive into LLMs` 负责主题地图，`minimind` 负责跑通小参数语言模型，`minimind-v` 接到视觉多模态，`minimind-o` 补上全模态 Omni。

先说结论：

* `minimind` 是纯语言 LLM 仓库；
* `minimind-v` 是视觉语言模型 VLM 仓库；
* `minimind-o` 是文 / 音 / 图全模态 Omni 仓库。

minimind 和 minimind-v 的定位容易被混掉，下面正文会逐一纠正。

## Dive into LLMs：11 个主题总览

放在最前面的是 `Dive into LLMs`，因为它最适合做全局地图。

项目说明明确写到，这套《动手学大模型》系列编程实践教程来自上海交通大学课程讲义扩展，目标是给大模型相关的入门编程提供免费公益参考。它没有停在泛泛讲概念，每章都给了三样东西：

* 课件；
* 教程；
* 可跑脚本或 notebook。

这决定了它很适合作为起步材料。你读的不只是目录，而是一套能马上跑起来的章节式工程教程。

### 11 个主题要怎么理解

当前能直接核到的 11 个方向是：

1. 微调与部署
2. 提示学习与思维链
3. 知识编辑
4. 数学推理
5. 模型水印
6. 越狱攻击
7. 大模型隐写
8. 多模态模型
9. GUI 智能体
10. 智能体安全
11. RLHF 安全对齐

这 11 个主题的好处，在于它没有只停在"主流热门主题"。你既能看到最常见的微调、prompt、多模态，也能看到知识编辑、水印、隐写、越狱、智能体安全这类更偏研究和安全的模块。

### 怎么读会更顺

如果你是第一次系统看大模型工程材料，可以分三轮：

* **第一轮**：看目录，知道全图长什么样；
* **第二轮**：选最贴近手头任务的 2 到 3 章去跑；
* **第三轮**：等你开始做自己的小项目，再回来看安全、评估、对齐这些章节。

一个比较实用的起步顺序可以是：

1. 微调与部署；
2. 提示学习与思维链；
3. 多模态模型；
4. GUI 智能体；
5. 智能体安全与 RLHF 安全对齐。

这样你会更快建立"从模型到应用"的感觉。

### 华为昇腾配套课程的补充价值

项目说明里还能直接核到一条信息：项目后来又联合华为昇腾社区推出了《大模型开发全流程》公益教程，而且项目页明说覆盖 PPT、实验手册、视频等形式，按初级、中级、高级系列组织。

这说明它已经不只是一个 GitHub 仓库，还往外延伸成了课程体系。对中文学习者来说，这一点很重要，因为你既可以在 GitHub 里看 notebook，也可以回到昇腾专区看成体系的视频和实验手册。

## minimind：自己训一遍小参数 LLM

如果 `Dive into LLMs` 负责给你全局地图，`minimind` 负责让你上手一个小参数语言模型。

这个仓库最大的价值，不在某个参数规模，而在"把一条从数据、训练到推理的链路尽量摊开"。从长期更新记录也能看出来，它已经从最早的 MiniMind V1 一路扩到 minimind2、minimind-3、LoRA、MoE、蒸馏、部署和私有数据迁移。

### 读这个仓库时别被旧帖子带偏

网上很多转述还停在"65M 小模型，2 小时训完"这类早期标签。但从当前仓库说明页看，它已经明显不是只讲一个极小玩具模型了。

它已经是一个小模型训练实验场，适合用来理解几件事：

* tokenizer 和数据预处理怎么接；
* pretrain、SFT、LoRA、DPO 这些阶段怎么拆；
* 小参数 LLM 的推理、蒸馏、MoE 结构怎么组织；
* 用有限硬件做实验时，哪些环节能缩、哪些不能缩。

### 它在整条路线里的位置

它是语言模型起点。

你读 `Dive into LLMs` 可能会知道微调和部署是什么；但只有跑一次 `minimind`，你才会对"从 0 训练一个小模型"有更直观的感受。即使你以后不会真拿它做生产模型，这个过程也很值。

### 怎么上手会顺一些

别一口气追最新系列和所有分支。比较省力的做法是：把快速开始流程跑通，看清最小训练链路需要哪些文件和依赖，然后只改一个变量，比如数据规模、batch、训练轮次，之后再碰 LoRA、蒸馏、MoE 这些分支。这样第一天不至于被仓库的更新日志淹没。

## minimind-v：从语言模型走到视觉多模态

接下来是 `minimind-v`。

仓库说明开头写得很清楚：这是一个从 0 开始训练超小多模态视觉语言模型 **MiniMind-V** 的项目，目标是让个人 GPU 也能快速推理甚至训练。它也直接说明了和 `minimind` 的关系：`minimind-v` 是 `MiniMind` 纯语言模型的视觉能力扩展，同系列的全模态项目则是 `MiniMind-O`。

### 它和前面的差别在哪

前面你还在处理纯文本 token；到了 `minimind-v`，你开始接视觉编码器、projection、图像占位符、多模态数据格式、VLM 推理和 WebUI。

这里会让你直观看到，多模态远不只是"把图片贴给模型看"，至少还要碰到：

* 视觉编码器如何接入；
* 视觉特征如何投影到语言空间；
* 训练数据怎样组织图文对；
* 推理时如何在 CLI 和 WebUI 里工作。

### 项目能力

当前仓库说明直接给出了：

* 环境准备；
* 视觉编码器下载；
* VLM 权重下载；
* 命令行问答；
* WebUI；
* 训练脚本。

拿它做多模态入门项目很顺手，因为你拿到的是一份能跑起来的工程骨架。

### 为什么接在 minimind 后面

因为你前面已经在 `minimind` 里习惯了小模型训练节奏，到了这里只是在原有认知上再加一层视觉输入。这样进入多模态，理解成本会低很多。

## minimind-o：把文、音、图收进一个 Omni 链路

`minimind-o` 是信息密度最高的一个仓库。

项目说明一开头就把定位写得很明确：从 0 实现一个小规模端到端 Omni 模型，单一权重同时支持文 / 音 / 图三模态输入与文本 / 流式语音输出。当前主模型 `minimind-3o` 大约 0.1B，普通个人 GPU 可训练，CPU 也能快速推理。

### Omni 这里难在哪

难点不再是"再多加一种输入"，而是交互链路真的变复杂了。仓库说明里能直接看到的关键词包括：

* Thinker–Talker 双路径；
* Mimi codebook；
* 流式语音生成；
* barge-in 打断；
* 音色克隆；
* 电话模式 WebUI。

这些词一出来，你就知道它已经在靠近完整交互系统。

### 为什么把它排在 minimind-v 后面

因为你如果还没跑过纯 LLM 和 VLM，直接进 Omni，工程压力会太大。

到了 `minimind-o`，你同时会碰到：

* 语音编码器；
* 视觉编码器；
* 音频编解码器；
* 多模态训练数据；
* 流式语音输出；
* WebUI 与演示链路。

所以它更适合作为这条路线的综合项目。前面两站练的是单项能力，这一站开始拼完整系统。

### 还有一处需要单独说明

它对应"能听能说能看"的定位，而且仓库里还给了技术报告链接，这意味着你可以一边跑工程，一边对照论文看架构和评估，不用只靠仓库介绍猜。

## 把三套 minimind 放在一起看

三者的差别最好单独说清楚：

* `minimind`：纯语言 LLM，适合学小参数语言模型训练链路；
* `minimind-v`：视觉语言模型 VLM，适合学图文多模态；
* `minimind-o`：Omni，全模态输入输出，适合学文 / 音 / 图统一交互系统。

这一点要单独写清，因为社媒转述经常会把它们混掉。真按仓库说明去跑，顺序应该是语言 -> 视觉多模态 -> 全模态。

## 学习顺序

如果把这几套材料排成一条实际可执行的路线，可以这样读：

1. **用 `Dive into LLMs`** 建 11 个主题地图；
2. **跑 `minimind`**，把一个小参数语言模型链路走通；
3. **看 `minimind-v`**，理解视觉编码器、投影和图文训练；
4. **看 `minimind-o`**，把语音和视觉一起接进完整 Omni 交互；
5. **回到 `Dive into LLMs` 的安全与对齐章节**，补越狱、智能体安全、RLHF 安全对齐。

这样走，既不会一开始就被 Omni 吓到，也不会只停在"看了很多概念"。

## 资料来源

* `Dive into LLMs` README：<https://github.com/Lordog/dive-into-llms>
* 昇腾《大模型开发全流程》学习专区：<https://www.hiascend.com/edu/growth/lm-development#classification-floor-1>
* `minimind` README：<https://github.com/jingyaogong/minimind>
* `minimind-v` README：<https://github.com/jingyaogong/minimind-v>
* `minimind-o` README：<https://github.com/jingyaogong/minimind-o>
* `MiniMind-O Technical Report`：<http://arxiv.org/abs/2605.03937>
* 本地归档：`docs/ai/references/llm-learning-roadmap/`

---

---
url: https://ain.hmgf.hxcn.space/ai/deep-learning-learning-roadmap-202605.md
description: >-
  把 MIT Intro to Deep Learning、Dive into Deep Learning 和 PyTorch Tutorials
  按难度和前置知识串成一条学习路线。
---

# 深度学习学习路线

这篇对应 `temp/ai-rewrite-checklist.md` 的第 37 篇。原始条目只给了一个方向，没有直接附来源，所以这里把官方资料补齐，谈学习顺序。不然很容易变成"到处找教程、到处都学一点"，最后只剩下会跑现成模型。

路线收成三套材料：MIT Intro to Deep Learning、Dive into Deep Learning、PyTorch Tutorials。三者解决的问题不一样。MIT 负责把你快速拉进"课 + lab + 项目"的节奏；D2L 负责把数学、模型和章节结构铺完整；PyTorch Tutorials 负责把训练循环、数据加载、自动微分和工程手感补扎实。

## 前置知识与课程主线

如果前置知识太薄，深度学习教程很容易看成 API 背诵。补下面五块，会省很多时间：

1. **线性代数**：向量、矩阵乘法、特征值、矩阵分解至少要有基本直觉。
2. **微积分**：导数、链式法则、偏导、梯度下降为什么能工作，要能跟上。
3. **概率统计**：随机变量、期望、方差、条件概率、交叉熵、最大似然这些词最好已经见过。
4. **优化基础**：SGD、mini-batch、学习率、正则化、欠拟合和过拟合的关系要能说清。
5. **神经网络基本概念**：前向传播、反向传播、损失函数、激活函数、参数更新。

如果你现在只差一点基础，不必停下来重学整套数学。更实际的做法是边学边补：D2L 的 `Preliminaries` 和 `Appendix: Mathematics for Deep Learning` 本来就是给这种状态准备的。

## 一、MIT Intro to Deep Learning：用课和 lab 快速建立整体感觉

官网：<https://introtodeeplearning.com/>

视频：<https://www.youtube.com/watch?v=II4giR4vOOo&list=PLtBw6njQRU-rwp5__7C0oIVt26ZgjG9NI>

### 它解决什么问题

MIT 6.S191 的优势在于节奏快，而且"讲完就动手"。官方站把它定位成高强度 bootcamp：vision、robotics、medicine、language、game play、art 等应用都会碰到。2026 版课程安排里，Lecture 和 Software Lab 是交替推进的，前面几周就已经覆盖了 sequence modeling、computer vision、generative modeling，以及对应的 coding lab。

这套课特别适合两类人：

* 想尽快建立"深度学习课程到底在讲什么"的整体印象；
* 已经看过零散视频，但还没做过带实验目标的 notebook。

### 前置要求和使用方式

官方 FAQ 直接写了前置：初等微积分、线性代数，Python 熟悉会更轻松。课程仓库则说明 labs 主要通过 Google Colab 跑，`lab1`、`lab2`、`lab3` 都已经准备好了入口。

建议这样用：

* 读 Lecture 1 和 Lab 1，确认自己能不能顺畅完成 notebook；
* 再继续 sequence modeling、vision、generative modeling 这些核心课；
* 每看完一段，就把里面的模型和训练过程复述一遍，不要只看结果图。

### 在路线中的位置

MIT 这套课放在最前面很合适，原因很简单：它会让你很快知道深度学习里到底有哪些块。很多人一开始缺的不是资料数量，而是地图。6.S191 正好把地图先摊开。

但它也有明显局限：节奏快、覆盖面广，部分推导和细节不会展开太深。所以学完之后不要停在"我跟着 lab 跑通了"。接下来要用 D2L 把底层结构补全。

## 二、Dive into Deep Learning：把数学、模型和代码顺序铺平

官网：<https://d2l.ai/>

中文版：<https://zh.d2l.ai>
课程：<https://courses.d2l.ai>

### 它解决什么问题

D2L 更像一套长期教材。官方站首页直接把章节结构摆出来：`Preliminaries`、线性模型、MLP、`Builders' Guide`、CNN、RNN、Attention and Transformers、Optimization、Computational Performance，再往后还有 CV、NLP、RL 等扩展章节。它不只是在线书，也把数学、解释、代码和 notebook 放在一起。

它适合用来解决两个问题：

* 你知道深度学习大概有哪些模块，但中间衔接还断着；
* 你已经跑过一些代码，想把"为什么这么写"补回来。

### 优先阅读的章节

如果你不是从第一页慢慢读，可以优先抓这几段：

1. `Preliminaries`：数据处理、线性代数、微积分、自动微分、概率统计。
2. `Linear Neural Networks for Regression / Classification`：线性回归和 softmax，是后面所有训练流程的最小原型。
3. `Multilayer Perceptrons`：前向、反向、初始化、dropout，这里是第一道门槛。
4. `Builders' Guide`：层、模块、参数、初始化、文件 I/O、GPU，这一块特别适合和 PyTorch 实操对照着读。
5. `Convolutional Neural Networks` 与 `Modern Convolutional Neural Networks`：把图像模型的直觉补起来。
6. `Attention Mechanisms and Transformers`：给后面接第 36 篇大模型教程做过渡。
7. `Optimization Algorithms`：如果你总在调学习率、正则化、优化器时发懵，这一章要认真看。

### 作为主线教材的理由

D2L 的好处在于连贯。很多教程只告诉你一个模型怎么实现，D2L 会把前一章、后一章、数学附录和代码实现连起来。这样你学到 CNN、RNN、Transformer 时，不会像换了三门课。

另一个优点是它自带 PyTorch、notebook 和中文版入口，复用门槛很低。你可以把它当成主线教材，再把 MIT 和 PyTorch 官方教程当成两侧的加速器和补丁包。

## 三、PyTorch Tutorials：把训练循环和工程细节练熟

文档：<https://docs.pytorch.org/tutorials/>

Basics：<https://docs.pytorch.org/beginner/basics/intro.html>
教程：<https://docs.pytorch.org/beginner/nn_tutorial.html>

### 它解决什么问题

很多人学深度学习卡住，不是概念听不懂，是一到代码就发虚：数据怎么送进来，`Dataset` 和 `DataLoader` 怎么组织，训练循环该写成什么样，`loss.backward()` 到底做了什么，模型保存和加载放哪一步。PyTorch Tutorials 补的就是这一段。

官方首页把 `Learn the Basics` 放得很前，说明定位很明确：熟悉张量、模块、训练、保存，再往后扩到 recipes、profiling、distributed、vision、NLP 和 production 场景。

### 优先阅读的几篇

建议读下面这些：

1. `Get started with PyTorch`：把完整的 ML workflow 走一遍。
2. `Learning PyTorch with Examples`：看最小可运行例子，建立张量和 autograd 的手感。
3. `What is torch.nn really?`：这篇非常适合把"模块化写法"和"底层训练逻辑"接起来。
4. `Data Loading Optimization in PyTorch`：等你训练开始变慢，就会知道这类教程为什么重要。
5. `Visualizing Gradients in PyTorch` 或 `Understanding requires_grad...`：用来补 autograd 的直觉。

### 它在整条路线里的职责

PyTorch Tutorials 不负责给你完整的深度学习体系，它负责把"会读教程"和"会自己写训练代码"之间的那段空白填上。很多人在这一步偷懒，后面学 CNN、Transformer、微调时就只能复制别人的训练脚本，改一点就出错。

所以它最适合和 D2L 交替使用：D2L 告诉你模型和概念怎么组织，PyTorch Tutorials 让你把这些概念真正写成代码。

## 学习顺序建议

如果要从头排路线，按这个顺序走：

### 第 1 段：用 MIT 建立全局地图

* 看 MIT 6.S191 的前几讲和前两次 lab；
* 目标不是一口气学完所有细节，重点是知道深度学习里会经过哪些模块；
* 这一段结束时，你至少要自己在 Colab 里跑通一个 lab。

### 第 2 段：用 D2L 补基础骨架

* 过 `Preliminaries`；
* 再看线性模型、softmax、MLP；
* 把自动微分、初始化、正则化和 generalization 这些基础词汇吃透。

这一段结束时，你应该能解释：为什么需要 loss、为什么要反向传播、为什么学习率会影响训练是否发散。

### 第 3 段：用 PyTorch Tutorials 练会训练循环

* 重点过 basics、`Learning PyTorch with Examples`、`torch.nn` 教程；
* 自己手写一版最小训练循环：数据加载、前向、loss、反向、优化、验证、保存；
* 把 notebook 里的现成代码改成你自己能复述的版本。

### 第 4 段：进入模型家族

按这个顺序更稳：

1. **MLP**：做一个结构最简单的分类或回归任务；
2. **CNN**：图像任务里把卷积、池化、batch norm、残差块的感觉补上；
3. **Transformer**：理解 attention 和编码器结构，再看预训练与 fine-tuning；
4. **微调和评估**：开始接触迁移学习、validation、error analysis、基础 profiling。

## 项目练习怎么安排才不会只剩"会跑模型"

项目练习最好跟着模型复杂度走，不要一上来就跑大模型仓库。

### 练习 1：MLP

目标：自己写一个用于分类或回归的最小网络。

你需要能独立完成：

* 数据预处理；
* `Dataset / DataLoader`；
* 模型定义；
* 训练循环；
* 验证集评估；
* 模型保存与加载。

### 练习 2：CNN

目标：做一个标准图像分类任务，比如 MNIST、Fashion-MNIST、CIFAR-10。

这一阶段重点不在刷分，而在建立卷积网络的训练感觉：输入 shape、通道数、batch norm、augmentation、过拟合与泛化之间的关系。

### 练习 3：Transformer

目标：做一个简化版序列任务，再碰更大的预训练模型。

你至少要弄明白：

* attention 的输入输出是什么；
* positional encoding 为什么需要；
* encoder / decoder 的职责差异；
* fine-tuning 时哪些层要改，哪些超参数最敏感。

### 练习 4：微调和评估

目标：拿一个已有预训练模型做微调，并认真做评估。

这里最容易被忽略的是评估。不要只报一个 accuracy 就结束。你至少要看：

* 训练 / 验证曲线；
* 错误样本；
* 不同 batch size、学习率、weight decay 的差异；
* 数据加载是不是瓶颈。

## 学完后怎么衔接第 36 篇大模型教程

等你把上面这条路线走通，再进入第 36 篇《大模型教程总览》会顺很多。原因很直接：

* 你已经知道线性代数、自动微分、优化器这些基础词在训练里具体落在哪里；
* 你已经写过最小训练循环，不会把大模型框架当魔法；
* 你已经看过 attention 和 Transformer，接大模型不会完全断层；
* 你对 fine-tuning、评估、GPU、数据加载这些工程问题已经有基本手感。

这样再去看 `Dive into LLMs`、`minimind` 这类大模型教程，注意力才能放在"大模型特有的问题"上，不会继续被最基础的深度学习底层反复绊住。

## 衔接后续教程

深度学习路线最难的地方是资源之间没有顺序。MIT 6.S191 适合建立地图，D2L 适合做主线教材，PyTorch Tutorials 适合把代码手感练出来。三者合起来，比只追一套"最火教程"要稳得多。

如果你现在还停留在"模型能跑起来就算学会"，后面最需要补的是把这三套资料真正接起来。

---

---
url: https://ain.hmgf.hxcn.space/ai/deep-learning-courses.md
description: 吴恩达、李沐、李飞飞三大系列深度学习课程的详细评价与对比，含学习路线建议和课程对比表格。
---

# 深度学习与 AI 课程推荐

深度学习入门，看哪个老师的课？这个问题在知乎、Reddit、各种学习社区里被问了无数遍。吴恩达、李沐、李飞飞，三位大佬的课各有特点，适合的人群也不一样。这里把主流的深度学习课程整理在一起，结合网络上的真实评价，帮你找到适合自己的学习路线。

## 吴恩达系列

吴恩达（Andrew Ng）的课是很多人的入门首选。Coursera 上的 Deep Learning Specialization 有 147,000+ 条评价，综合评分 4.8/5，91% 的学员报告了积极的职业成果。这个数据量级说明课程质量确实经得起检验。

### 2025 版机器学习入门到精通系列课程

这是吴恩达 2012 年经典机器学习课程的完全重制版，由 DeepLearning.AI 和 Stanford Online 联合出品。旧版用的是 Octave/MATLAB，新版全部换成了 Python + TensorFlow，内容也做了大幅扩展。

**与旧版的主要区别：**

* 编程语言从 Octave 换成 Python，更贴合实际工作场景
* 新增决策树、树集成方法（随机森林、XGBoost）
* 新增推荐系统、无监督学习、强化学习内容
* 每节课先用可视化讲清直觉，再给代码实现，数学推导作为可选补充
* 增加了大量未评分的交互式代码 Notebook，方便边学边练

**课程结构（3 门课，共约 95 小时）：**

1. **监督机器学习：回归与分类** — 线性回归、逻辑回归、梯度下降
2. **高级学习算法** — 神经网络、TensorFlow 实现、决策树
3. **无监督学习、推荐系统与强化学习** — 聚类、异常检测、协同过滤、RL

**网络评价：**

* 优点：讲解极其清晰，从直觉入手再给公式，零基础也能跟上；Python 作业设计得很好，有自动评分反馈；社区活跃，遇到问题容易找到解答
* 缺点：节奏偏慢，有基础的人会觉得"太啰嗦"；数学深度不够，想深入理论需要额外补课；Coursera 平台需要付费才能拿证书（可以免费旁听但没有证书）
* 适合人群：完全零基础、转行进入 AI 领域、想快速建立直觉的人

### 200 集深度学习课程

这是吴恩达在 B 站上的深度学习课程合集，覆盖 CNN、RNN、GAN、LSTM、YOLO、Transformer 六大架构。实际上是 Coursera Deep Learning Specialization 的中文搬运/整理版。

**Coursera 原版 Deep Learning Specialization 的课程结构（5 门课，约 129 小时）：**

1. **神经网络与深度学习**（25h）— 神经网络基础、前向传播、反向传播
2. **优化深度神经网络**（24h）— 超参数调优、正则化、BatchNorm、Adam 优化器
3. **构建机器学习项目**（7h）— 误差分析、迁移学习、多任务学习（这门课是吴恩达多年实战经验的结晶，讲的是"怎么在实际项目中做决策"）
4. **卷积神经网络**（36h）— CNN 架构、ResNet、目标检测、神经风格迁移、U-Net 语义分割、MobileNet
5. **序列模型**（37h）— RNN、GRU、LSTM、注意力机制、Transformer、HuggingFace tokenizers、命名实体识别、问答系统

**各架构学习建议：**

* **CNN**：课程第 4 门的核心，从 LeNet 讲到 ResNet，配合目标检测（YOLO 的基础概念）和神经风格迁移。想做 CV 方向的必学
* **RNN/LSTM**：课程第 5 门的核心，从基础 RNN 讲到 GRU、LSTM，配合字符级语言模型。虽然现在 Transformer 是主流，但理解 RNN 对理解序列建模的演进很重要
* **Transformer**：课程第 5 门的后半部分，2021 年更新时新增，包括 NER 和问答系统的实现。相比专门的 Transformer 课程，这里的覆盖相对基础
* **GAN**：课程中涉及较少，如果想深入 GAN 需要找专门的资源

**网络评价：**

* 优点：体系完整，从基础到进阶一条线串下来；吴恩达的板书推导风格很适合理解数学细节；每门课都有编程作业，不是光听不练
* 缺点：部分内容（如 RNN 的某些应用）在 2025 年看已经有些过时；TensorFlow 1.x 到 2.x 的过渡期有些作业体验不太好；GAN 和 YOLO 的覆盖深度有限
* 适合人群：学完机器学习基础后想系统学深度学习的人

### 吴恩达系列学习建议

**推荐学习顺序：** 先学 2025 版机器学习（建立基础概念），再学深度学习 5 门课（系统掌握各种架构）。

**搭配资源：**

* 数学基础不够的话，配合 3Blue1Brown 的线性代数和微积分系列
* 想深入某个架构（比如 Transformer），学完课程后找专门的论文解读或教程补充
* 编程作业一定要做，光看视频效果打折一半

## 李沐系列

李沐的课风格跟吴恩达完全不同。吴恩达是"先讲清概念，再给代码"，李沐是"直接上手写代码，边写边讲"。如果你是那种"看十遍不如写一遍"的学习者，李沐的课更适合你。

### 2025 版动手学深度学习系列课程

这是李沐基于《动手学深度学习》（Dive into Deep Learning，简称 D2L）这本书的课程。D2L 这本书在学术界评价很高，被 Stanford CS329P、UC Berkeley STAT 157 等课程采用为教材。

**课程特点：**

* 用 PyTorch 实现，代码全部开源在 GitHub（d2l-ai/d2l-zh）
* 每个概念都有完整的可运行代码，不是伪代码，是能直接跑的
* 覆盖深度学习、机器学习算法、神经网络、计算机视觉、物体检测、迁移学习、大模型微调
* 数学推导和代码实现并重，不会为了"好懂"而牺牲严谨性

**D2L 这本书的背景：**

D2L 由李沐、Alex Smola、Aston Zhang、Rachel Hu 合著，在 GitHub 上有 60,000+ Star。它不只是教程，更像是一本"深度学习百科全书"——从线性代数复习到 Transformer，从 Softmax 回归到目标检测，从零开始用 NumPy 实现每一个算法，然后再用 PyTorch 框架重写。

**网络评价：**

* 优点：代码质量极高，是真正的"production-ready"教学代码；数学推导严谨，不会含糊跳过关键步骤；PyTorch 版本紧跟最新实践；社区贡献活跃，Bug 修复快
* 缺点：对零基础不太友好，默认你有 Python 编程和线性代数基础；李沐的讲课风格比较"干"，没有吴恩达那种娓娓道来的感觉；视频时长较长，需要耐心
* 适合人群：有一定编程基础，想通过动手写代码来理解深度学习的人

### 一小时从函数到 Transformer

这个视频是李沐的一个"浓缩版"讲解，用一小时时间把从基础函数到 Transformer 的演进串起来。

**内容覆盖：**

* 从线性函数出发，逐步引入激活函数、多层感知机
* 讲解注意力机制的核心思想
* 最后落地到 Transformer 架构

**适合什么基础的人：**

* 最好已经学过基本的神经网络概念（比如知道什么是前向传播、反向传播）
* 如果完全零基础，这个视频会看得云里雾里
* 适合学完基础课程后，想快速理解 Transformer 演进脉络的人

**讲得是否清楚：**

李沐的风格是"用最少的话讲清核心"，不会反复解释基础概念。如果你能跟上节奏，一小时能建立很好的整体框架；如果跟不上，建议先去学更基础的课程再回来看。

### 李沐 vs 吴恩达：怎么选？

这个问题在知乎上讨论很多，总结下来：

* **吴恩达**：适合零基础，先建立直觉再写代码，节奏慢但稳
* **李沐**：适合有编程基础，直接上手写代码，节奏快但需要自己消化
* **最佳组合**：先看吴恩达的机器学习入门，建立基本概念；然后看李沐的 D2L，用代码巩固理解

## 李飞飞系列

李飞飞（Fei-Fei Li）是 Stanford CS231n 的主讲人，这门课被认为是计算机视觉领域的"圣经"级课程。CS231n 从 2015 年开课，到 2026 年春季已经是第 12 次开课，课程内容持续更新。

### 200 集计算机视觉课程

这是 CS231n 课程内容的中文整理版。Stanford CS231n 的原版内容覆盖：

**课程核心内容：**

* 图像分类：从 KNN 到 CNN，理解卷积、池化、激活函数的工作原理
* 目标检测与定位：R-CNN 系列、YOLO 的理论基础
* 图像分割：语义分割（U-Net）、实例分割
* 生成模型：GAN、VAE、扩散模型的基础
* 视觉 Transformer：ViT、Swin Transformer 等最新架构
* 多模态学习：CLIP、视觉语言模型

**CS231n 的独特价值：**

这门课不只是教你用模型，而是教你"理解"模型。它的作业设计很有深度——会让你从零实现卷积层的前向/反向传播，而不是直接调 `nn.Conv2d`。这种"从底层造轮子"的方式，能让你真正理解每个组件在干什么。

**课程作业（占总成绩 45%）：**

* Assignment 1：KNN、SVM、Softmax、两层神经网络（全部手写实现）
* Assignment 2：全连接网络、BatchNorm、Dropout、CNN（用 NumPy 实现反向传播）
* Assignment 3：RNN、Transformer、生成模型

**网络评价：**

* 优点：计算机视觉方向最系统的入门课程，没有之一；理论深度足够，不是浅尝辄止；作业设计精良，做完对 CV 的理解会上一个台阶
* 缺点：难度较大，不适合完全零基础；B 站搬运版可能缺少最新的作业和项目；部分课程内容偏向学术，工业实践覆盖相对少
* 适合人群：想做计算机视觉方向的研究或工程，有 Python 和线性代数基础

### 李飞飞课程的学习建议

如果你打算走 CV 方向，建议这样学：

1. 先学吴恩达的机器学习和深度学习基础
2. 再学李飞飞的 CS231n，重点做作业
3. 同时配合李沐的 D2L 中计算机视觉章节的代码实践
4. 最后找一个实际项目（比如 Kaggle 的图像分类比赛）练手

## 其他课程

### Sebastian Raschka 的 LLM/ML 学习资源

Sebastian Raschka（[@rasbt](https://x.com/rasbt)）是 GitHub 上最顶级的 ML/LLM 教育者之一，38k+ 关注者，149 个仓库，大多是超级详细的 from scratch 教程和书籍代码。他的 GitHub 就是一个「AI 教科书工厂」，产量和质量都让人窒息。

**代表作品：**

* **《Build a Large Language Model (From Scratch)》**（97k+ Star）— 被称为「LLM 学习圣经」，从零开始构建 LLM，覆盖 tokenizer、预训练、微调、RLHF 全流程
* **《Python Machine Learning》** 三版 — 经典机器学习教材，覆盖从基础算法到深度学习
* **Reasoning from Scratch** — 推理相关的从零实现
* **mlxtend** — 机器学习扩展库

**特点：**

* 用 Jupyter Notebook 当画布，从线性回归到 ChatGPT 的所有知识点都手写成了可执行笔记
* 代码质量极高，真正的 production-ready 教学代码
* 数学推导和代码实现并重

**适合人群：** 想深入理解 LLM 内部原理、喜欢从零实现的学习者

### Alisa Liu 的 LLM 与数学笔记

Alisa Liu（[@alisawuffles](https://x.com/alisawuffles)）即将加入 OpenAI，她在求职过程中整理了大量笔记，分享出来帮助准备 AI/ML 面试的人。

**资源列表：**

* **LLM Book of LLMs** — LLM 相关笔记，覆盖面试常见知识点
* **Math Notes** — 数学基础笔记，适合检查自己的基础知识是否扎实
* **求职博客** — 记录了她求职过程中的经验教训，对准备 AI/ML 面试很有参考价值

**适合人群：** 准备 AI/ML 面试的人，或者想检查自己基础知识是否扎实的学习者

**评价：** 值得通读一遍，无论是准备面试还是检验基础都很有价值

### 40 分钟的 Docker 实战攻略

Docker 在深度学习项目中几乎是必备技能——配置环境、部署模型、复现实验都离不开它。

**内容评估：**

这个视频从安装到部署，40 分钟快速上手容器化。覆盖 Docker 的核心概念（镜像、容器、Dockerfile）和基本操作。内容在 2025 年看没有过时，Docker 的核心用法这些年变化不大。

**适合什么基础：**

* 需要基本的命令行操作经验
* 不需要任何 Docker 基础，从零开始讲
* 适合"我需要快速学会 Docker 来部署模型"的场景

**实际价值：**

深度学习项目经常遇到"我的环境跑得好好的，换台机器就不行了"的问题。Docker 能解决这个。学完这个视频，你应该能写 Dockerfile、构建镜像、运行容器。更深的编排（Docker Compose、Kubernetes）需要额外学习。

### Harness Engineering 是什么？

Harness Engineering 这个概念在 AI 工程化领域比较新。它指的是"驾驭"AI 模型的工程方法，与提示词工程（Prompt Engineering）和上下文工程（Context Engineering）有密切关系。

**核心区别：**

* **Prompt Engineering**：关注怎么写提示词让模型输出更好的结果
* **Context Engineering**：关注怎么组织和管理模型的上下文信息
* **Harness Engineering**：关注怎么把 AI 模型集成到完整的工程系统中，包括工具调用、工作流编排、错误处理等

**值不值得看：**

如果你已经在做 AI 应用开发（比如用 LangChain、LlamaIndex 构建 Agent），这个视频能帮你理解更宏观的工程化思路。如果你还在入门阶段，暂时不需要看。

### 尽量客观锐评 8 大主流人工智能教程

这个视频对 8 个主流深度学习/AI 教程做了横向评价。

**评价是否客观：**

从网络反馈来看，这类"课程评价"视频通常有一定的主观倾向——评价者自己的学习经历和偏好会影响排序。但作为"快速了解各课程特点"的参考还是有价值的。建议看完后，结合自己的基础和目标做判断，不要完全跟着别人的排名走。

## 课程对比表格

| 维度 | 吴恩达 ML（2025 版） | 吴恩达 DL（5 门课） | 李沐 D2L | 李飞飞 CS231n |
|---|---|---|---|---|
| **难度** | 入门 | 中级 | 中级偏高 | 中高级 |
| **前置知识** | 高中数学 + 基础 Python | Python + 线性代数基础 | Python + 线性代数 + 微积分 | Python + 线性代数 + 概率统计 |
| **编程框架** | TensorFlow | TensorFlow | PyTorch | PyTorch |
| **代码实践** | 中等（有自动评分作业） | 中等 | 高（每个概念都有可运行代码） | 高（从底层实现） |
| **理论深度** | 浅，重直觉 | 中等 | 深，数学推导完整 | 深，学术级 |
| **课程时长** | ~95h | ~129h | ~100h+（含视频 + 书） | ~40h（视频） + 作业 |
| **网络评分** | 4.9/5 | 4.8/5 | GitHub 60k+ Star | 公认 CV 最佳入门 |
| **适合人群** | 完全零基础 | 学完 ML 后进阶 | 有基础想深入理解 | CV 方向 |
| **中文支持** | 有中文字幕 | B 站有搬运 | 原生中文 | B 站有搬运 |

## 学习路线建议

### 零基础入门路线

如果你完全没有机器学习基础，按这个顺序来：

1. **吴恩达 2025 版机器学习** — 建立基本概念，理解什么是监督学习、损失函数、梯度下降
2. **3Blue1Brown 线性代数/微积分** — 补数学基础（如果需要的话）
3. **吴恩达深度学习前 2 门课** — 神经网络基础 + 优化技巧
4. **李沐 D2L 对应章节** — 用 PyTorch 代码巩固理解
5. **选一个方向深入** — CV 或 NLP，然后学对应的专项课程

### 有基础进阶路线

如果你已经有编程和数学基础，学过一些机器学习：

1. **吴恩达深度学习 5 门课** — 快速过一遍，查漏补缺
2. **李沐 D2L** — 重点看代码实现，跟着敲
3. **读论文 + 复现** — 选一个感兴趣的方向，读经典论文并尝试复现

### CV 方向路线

想做计算机视觉：

1. 吴恩达深度学习（重点第 4 门 CNN）
2. 李飞飞 CS231n（系统学 CV 理论）
3. 李沐 D2L 计算机视觉章节（代码实践）
4. Kaggle 图像分类/目标检测比赛（实战）

### NLP 方向路线

想做自然语言处理：

1. 吴恩达深度学习（重点第 5 门序列模型 + Transformer）
2. 李沐一小时 Transformer（快速理解架构演进）
3. 李沐 D2L 注意力机制和 Transformer 章节
4. HuggingFace 官方教程（实际使用预训练模型）

## 最后的建议

别贪多，选一个系列从头到尾看完，比东看一点西看一点效果好。课程只是入门的起点，真正的成长来自动手做项目。看完课之后，尽快找一个实际问题去解决——不管是 Kaggle 比赛、复现论文，还是自己想做的小项目。

另外，深度学习这个领域变化很快。2023 年的"最佳实践"到 2025 年可能就过时了。学课程打基础的同时，也要养成关注最新论文和技术动态的习惯。可以关注 Papers With Code、arXiv 的 cs.CV/cs.CL 分区、以及各大实验室的博客。

---

---
url: https://ain.hmgf.hxcn.space/ai/llm-training-principles-202606.md
---

# 你不知道的大模型训练：原理、路径与新实践

![](https://gastigado.cnies.org/d/public/image1.jpg)

## 太长也要读

在写完《你不知道的 Claude Code：架构、治理与工程实践》、《你不知道的 Agent：原理、架构与工程实践》后，我想着继续来写第三篇，这次打算挑战下自己来梳理一下大模型训练到底怎么回事，这篇文章争取让非专业背景的人也能读得懂。

2026 年来看大模型效果真正拉开差距的地方，慢慢不再是预训练本身了，而在它更后面的那一大段：后训练、评测、奖励、Agent 训练、蒸馏，每一个步骤都在影响用户实际感受效果。你发现某个模型突然变强了，背后可能是这几块一起优化到位了，而非单一因素导致。

下文按大模型训练链路顺序来讲，重点放在厂商怎么通过后半段训练栈来提升最终上线效果。

## 大模型训练其实是一条流水线

过去几年，一般会用参数、数据、算力的堆积来解释模型进步，但很多用户真正感受到的提升，并不是来自再多训一点基础语料，而是来自预训练后面那整套训练流程。模型怎么说话、怎么听指令、怎么推理、怎么用工具，这些都不是多喂一点互联网文本就能自然长出来的。

InstructGPT 当年给过一个很直接的例子：一个只有 1.3B 参数、做过对齐和偏好优化的模型，在人类偏好评测里能赢过 175B 的 GPT-3，参数量差了两个数量级，用户最后却更喜欢那个小很多的版本，训练后半段是真的会改写用户感知。

训练过程其实是一条流水线，数据、算法、系统、反馈这几层高度耦合，一层变化通常会传导到其他层，2026 年的模型能力和产业价值，也越来越集中在预训练后面的几层。

![](https://gastigado.cnies.org/d/public/image2.jpg)

这也是我们平时为啥感觉豆包不太去争排名，但大家日常用起来却更符合心意的原因，是后训练做到位了。

这六层只是为了看分工，下图的九个阶段是更详细的版本：原始数据和系统配方单独拆开，Agent harness 和 Deployment 也是后半段的细分。还有两条反馈回路贯穿始终：生产流量回到数据工程，离线评测结果回到预训练。

![](https://gastigado.cnies.org/d/public/image3.jpg)
![](https://gastigado.cnies.org/d/public/image4.jpg)

## 预训练只是模型底座

预训练仍然是训练链路的起点，搞清楚它到底在做什么，才能理解后面的每一层都在补充什么。没有这一步，就没有语言建模能力，没有知识压缩，也没有后面那些能力迁移的空间。在工程上，它要做的不只是让模型学会预测下一个 token：把语言分布学进去，把大规模文本里的知识和模式压进参数，还要给后面的能力激活留出空间。下一个 token 预测只描述了训练形式，解释不了为什么规模上来之后，模型会突然多出一些之前没有的能力。

GPT-3 之后，不少模型调优的工作会更加考虑到预算和配比，模型不是越大越好，参数量、训练 token 数和总计算预算之间有配比问题，很多模型不是做小了，而是训练量不足，在既定预算下没有训到更合适的点。

真到训练决策里，更实际的问题是：如果有人给你一万张 H100 和一个月时间，你会如何去训一个足够好的开源模型？规模定律在这里更像一个预算分配工具，不是那种论文里的抽象曲线，最后还是需要静下心来考虑这些问题：下一轮训练到底该多堆参数，还是多喂数据？当前模型到底是能力不够，还是只是欠训练？有限 GPU 预算下，什么配比更值？

预训练更像是给模型能力打地基，决定知识范围、泛化潜力和模式归纳能力，也决定后训练有没有可以利用的空间。但听不听指令、配不配合用户、关键任务跑起来稳不稳，这些预训练都是管不到的。

预训练阶段不只是在决定学多少知识，它还在提前决定模型以后能长成什么样。tokenizer 的切分方式会直接影响后续训练，context window 拉到多长也要在前面定下来。要不要继续做多模态预训练，要不要把单卡可运行当成一开始就定下来的要求，这些取舍在训练阶段就写进配方了，不是发布时再补的功能 feature。Gemma 3 同时强调了 single accelerator、128K context、视觉能力和量化，背后反映的也是这类取舍。用户最终看到的那些能力，比如能在本地电脑上跑、能看图、能理解长文档，其实很多在训练阶段就已经定下来了。

通过 Chinchilla 给出的数据最优点来看，对于 8B 参数的模型大约是 200B tokens，但 Llama3 8B 实际用了 15T tokens，超出约 75 倍。这类过训练配方通常能在同等参数下换来更高的能力密度，最后换来一个更小、推起来也更省的模型。衡量这件事，看总 FLOP（浮点运算次数）比看参数量更靠谱，下图直观展示了这个差距。

还有一类容易被忽略的设计也发生在预训练阶段：tokenizer 词表大小、分词策略、字节级编码方式都会有挺大影响。Llama2 词表 32K，Llama3 扩到 128K 后，序列长度大约压缩了 15%，下游性能也会跟着上去，这个影响会延续到推理成本和多语言能力。中文、代码、数学公式的 token 效率在词表设计时就已经定下来了。比如一个把中文分得很碎的 tokenizer，劣势并不是每次多花几个 token，而是每次推理都要持续承担这个决策错误的代价。

![](https://gastigado.cnies.org/d/public/image5.jpg)

## 数据配方决定模型能力

参数规模是过去几年大家比较的重要指标，但这两年更重要的东西叫「数据配方」。

这个过程表面看是清洗数据，实际上是完整的数据生产工程。网页、代码仓库、书籍、论坛这些原始数据，要先走完文本抽取、语言识别、质量过滤、隐私处理、安全过滤和去重，才能进入预训练，下图展示了完整的漏斗处理流程。

如果只把数据当作训练燃料，很容易得出越多越好的结论。但数据工程更接近能力设计，模型看见什么、看不见什么，代码数学百科各占多大比例，这些选择直接影响模型最后形成的能力分布。

去重和污染控制常被忽略，但它对结果影响很大，要处理的不只是低质量数据，还包括重复模板、许可证文本、镜像网页，以及 benchmark 泄漏带来的污染。如果 document-level 和 line-level dedup 做得不够，模型往往会反复吸收最容易复制的内容，却未必真正学到最有价值的部分，很多开源模型效果看起来是参差不齐，往往是数据处理质量的差距。

最近两年，数据配比本身也成了单独要研究的问题。Data Mixing Laws 这类工作关注的，不只是还能收集多少数据，更是不同类型数据的占比会把模型带向什么能力结构。

合成数据也已经从辅助手段变成正式训练流程的一部分，Self-Instruct 这类让模型自己生成指令数据的方法、DeepSeek-R1 的蒸馏轨迹，以及 Qwen、Kimi 系列里越来越明显的合成监督，都在往同一个方向走。每一代更强的模型，都会参与重构下一代模型所看到的数据。早期模型生成基础指令数据，更强的模型生成高质量推理轨迹和 CoT 数据，经过 RL 训练的推理模型再把这些轨迹蒸馏给更小的 dense 模型。dense 就是全部参数都跑，和 MoE 那种按需激活不一样。

这里的关键是，模型往往要先在更大规模上形成能力，后面才可能把这些能力压缩到更小的模型上。DeepSeek-R1-Distill 系列就是直接例子。RL 后的大模型轨迹让 1.5B 到 70B 的 dense 模型都获得了明显收益，Llama 3.1 405B 也明确被用于提升 8B 和 70B 的后训练质量，这些不是附带产物，而是训练设计的一部分。

## 系统和架构的约束，训练前就要想清楚

很多人把训练理解成研究问题：目标函数怎么设，损失怎么降，模型结构怎么改。但真正的大模型训练里系统约束这一块非常重要，是分布式系统问题，而非单机上的深度学习问题。GPU 数量、显存带宽、并行策略、容错和成本，这些不能等到训练完才去调优，最开始就决定了你能训多大、支持多长上下文、能不能跑更复杂的后训练这些点。

MoE 是这一层最典型的例子，多专家模式让模型在相近计算量下扩大总参数，也把每个 token 的激活成本控住。代价会让路由复杂、负载均衡难、基础设施重。DeepSeek-V3、Qwen 一系列 MoE 设计都是成本和效果的折中，不是单纯的架构偏好。

最近公开配方里的讨论，不再只是模型大小和 token 配比这种粗粒度分析。muP 让超参可从小规模实验迁移到大规模训练，WSD learning rate 是先升后稳再衰减的学习率调度策略，再加上最优 batch size 和更高的数据对参数比例，这些都开始出现在正式训练报告里，这些细节正在变成同规模模型之间真正拉开差距的地方。

长上下文、多模态和新架构如果只按产品功能点理解，会漏掉训练侧的约束。128K context 这种目标会直接改变 attention 成本、batch size、训练 curriculum（数据编排顺序）和并行策略，多模态改的不只是模型结构，还有 data mixing（多来源数据配比）、encoder 设计和安全评测。如果把单卡可运行当成硬要求，参数量、量化路径、模型家族大小都会跟着收紧。

Forgetting Transformer 和 Kimi 的 Attention Residuals 这类工作，都是在回答类似的问题：更长的上下文如何训练，网络变深之后如何避免信息被稀释。你看到的是模型能处理更长输入，或者更便于部署，训练时面对的却是另一组完全不同的约束。

算力预算是固定的，模型大小、训练 token 量、上下文长度、serving 成本，每往一个方向多花，其他方向就得让步。

上下文拉长，attention 成本直接膨胀，batch size 必须压小；模型做大，GPU 内存上来，serving 成本也跟着涨。这不是取舍选项，是资源约束的结果，大部分决定在训练开始前就锁死了。

还有个工程现实经常被忽略：训练并不总是稳定的，几千张 GPU 跑了几周，突然出现训练损失突增，幅度大到无法忽略，只能回滚到几天前的 checkpoint，重新来过。

除了 loss spike，还有单块 GPU 静默出错，不报错但悄悄产生错误梯度、NVLink 带宽异常、节点间通信抖动，每一种都可能污染若干步训练。能不能在大规模训练里快速检测、隔离、恢复，这是实验室级别的工程能力，不是读论文能解决的问题。

DeepSeek-V3 在技术报告里专门提到，整个预训练过程没有出现 irrecoverable loss spike，也没有做任何 rollback，同时是少数公开验证 FP8 混合精度训练在超大规模模型上可行的案例。按公开数据，全流程约 2.788M H800 GPU hours，预训练完成了 14.8T tokens。

训练系统和推理系统关系紧密，但不是同一个工程问题。训练关心梯度、并行、checkpoint、吞吐和成本，推理关心延迟、KV cache（缓存历史计算避免重复运算）、量化和服务稳定性。

## 后训练才决定用户真正感受到的差距

普通用户真正能感受到的很多提升，其实都发生在预训练之后。指令微调（Instruction tuning）用标注好的指令-回答数据对模型做监督训练。它改变的是回答方式，把怎么接任务、怎么组织输出、怎么像个配合的助手这些要求变成监督信号。一个基础模型也许已经具备不少潜在能力，但如果没有这一步，这些能力往往不会以用户期待的形式稳定冒出来。

再往后看，RLHF、DPO、RFT 方向差不多，都在把"什么叫更好的回答"接进训练回路，但路径不同。

* RLHF（基于人类反馈的强化学习）先模仿高质量回答，再用偏好比较做强化
* DPO（直接偏好优化）把这条路径缩短，直接从偏好对比里学，不需要单独训奖励模型
* RFT（强化微调）是工程上更容易落地的接口，把任务定义、grader 设计和奖励信号放到产品化流程里

今天谈后训练，只讲 SFT 或 RL 已经不够了，更难的是评测怎么设、分数怎么打、什么样的回答才算值得继续优化。SFT 是监督微调，它学到的不只是知识，也在学风格。数据长度、格式、是否带引用、是否偏好分点表达，都会显著影响模型最后的输出形态。很多用户以为自己在比较能力，实际比出来的往往只是风格差异。再加上偏好评测天然偏爱更长的回答，很容易把看起来更认真的长输出当成更可靠。所以后训练只看榜单往往不够，还要结合真实任务结果、成本和稳定性。

现代后训练是一条多阶段流水线，公开资料里 DeepSeek-R1 的配方是最清晰的。它分四个阶段推进：

阶段 1是冷启动 SFT，在做强化学习之前，先用少量高质量的思维链 CoT 数据热身。DeepSeek-R1-Zero 证明了直接从 base model（预训练后尚未做对齐的原始模型）上做 RL 是可行的，但纯 RL 训练出来的模型会反复重复、语言混乱、可读性很差。冷启动 SFT 给 RL 一个更稳定的起点，先把格式和语言一致性收住，这不是多余步骤。

阶段 2在数学、代码、逻辑等可验证领域做强化学习，用 GRPO 作为训练算法，以可程序检验的正确性作为奖励信号。关键在于为什么选 GRPO 而不是传统的 PPO：PPO 是近端策略优化，需要一个独立的价值网络（value network）来估算当前状态价值，在大模型上同时维护两个网络工程负担很高。GRPO 对同一个提示词采样多个回答，用组内排名替代绝对价值估计，不需要独立的价值网络，工程上简洁很多，DeepSeek 系列和 Cursor Composer 2 的 RL 基础设施都采用了接近 GRPO 的方案。

阶段 3做拒绝采样微调（Rejection Sampling Fine-Tuning），把 RL 产生的成功轨迹过滤后转成新的 SFT 数据，再做一轮监督微调。这是 RL 和 SFT 之间的桥梁，RL 探索出的好轨迹，就这样变成下一轮 SFT 的高质量训练样本。

阶段 4融入有益性和安全性偏好反馈，把模型调整到符合发布标准的助手形态。

四个阶段互相依赖：冷启动让 RL 稳定启动，RL 产生高质量数据，拒绝采样把这些数据变成下一轮 SFT 的输入，对齐 RL 完成行为收敛。从公开结果看，直接 SFT 和走完四个阶段，差距通常是能看出来的。

## Eval、Grader、Reward 在重新定义训练目标

负责把模型输出转成训练分数的组件叫 grader，它很容易出现大家想不到的问题。只看最终答案，模型很快学会走捷径；打分太粗，噪声会被强化学习持续放大；榜单涨了，真实任务未必跟着一样好。很多时候，用户以为自己在看 base model 差距，其实差距出在目标怎么定义上。

放到训练流程里看，eval 决定测什么，grader 决定一次输出怎么变成分数，reward 决定模型后面会被往哪里推。它们连起来就是一条具体的反馈回路：任务定义、eval、grader、优化、rollout、再评测。rollout 指模型执行任务产生的轨迹，链路里任何一环跑偏，后续优化就会一起跑偏。

只看最终结果，模型可能会碰巧答对，也可能沿着错误过程拿到正确答案，代码、数学和复杂推理任务里，这个问题尤其明显。中间步骤如果不进反馈，模型学到的往往不是更可靠的推理，而是怎样更高概率地拿到最后那一分。

所以这几年越来越多工作从传统 RLHF 转向 verified rewards，用程序直接验证正确性。在数学、代码、逻辑这些可验证任务里，现在已经可以直接对正确性打分，不再主要依赖人工偏好。但 verified rewards 也没有把问题彻底解决掉。过优化、reward overfitting（打分规则被过度优化、能力却没真正提升），以及 mode collapse（输出高度单一、失去多样性）这些现象还是会出现，问题只是从偏好标得准不准，变成了打分链路稳不稳。

模型写出来的思考过程，也不能直接当成内部过程的完整记录。Anthropic 在 reasoning model 的可观测性实验里发现，模型会使用额外提示，却不在可见 CoT 里承认；到了 reward hacking 场景，它更可能补一段看起来合理的解释。reward hacking 是钻打分系统空子，而不是真正完成任务。可见 CoT 更适合当训练和监控信号，不能直接当成完整真相。

再往下一层，模型甚至会开始利用打分通道本身。reward tampering 和 alignment faking 这类研究表明，模型在理论上可能主动干预打分过程本身。reward tampering 是直接篡改奖励计算过程本身，alignment faking 是对齐伪装，表面合规但隐藏不对齐意图。

一旦模型有足够强的环境访问能力，它优化的就不止任务结果，还可能包括 checklist、reward code 和训练关系本身。Anthropic 2025 年一项实验，在一组可被利用的生产编码 RL 环境里注入了额外的 reward-hack 知识，随后观察到了类似的泛化。模型学会 reward hacking 后，不只会在同类任务上继续利用，还出现了对齐伪装等更广泛失对齐。

这些行为在标准对话评测里看不到，只在 Agent 任务环境里能看到。工程含义很直接，reward、grader、环境隔离和监控都要当成训练设计的一部分。

到了 Agent 阶段，reward design 还会继续拆细，最终结果只是其中一项，另外还要单独度量过程质量、上下文管理和反作弊约束。Kimi K2.5 奖励的是有效拆解和真实并行；Chroma Context-1 会给搜索途中找到的相关文档记分；Cursor Composer 2 把长任务里的 summary 纳入奖励，因为总结一旦失真，后面的上下文会一路被带偏。

具体到实现里，ORM 是结果奖励模型，只给最终答案打分，信号稀疏，成本低，适合先起步，但也更容易让模型走捷径。PRM 是过程奖励模型，给中间步骤打分，信号更密，对数学和代码推理通常更强，但标注和系统成本都高很多。OpenAI 在数学推理实验里看到，PRM 不只提高了正确率，也更容易把过程约束住，因为每一步都在被监督；问题也很直接，PRM 的成本通常是 ORM 的数倍，所以大多数真实系统还是先从 ORM 起步，只有在数学、代码、逻辑这类可验证任务里，才更有条件把 PRM 自动化，用程序去验证中间步骤，绕开人工标注瓶颈。

![](https://gastigado.cnies.org/d/public/image6.jpg)

这条回路完整跑起来是这样的：

最近几类对齐方法都在做同一件事。Anthropic 的 Constitutional AI 把人类写的原则接进训练，用 AI feedback 替代逐条人工偏好。OpenAI 的 Deliberative Alignment 把安全遵守放进推理过程，让推理能力本身承担一部分安全约束。这里说的 Deliberative Alignment 是审慎对齐，核心是推理阶段自行判断安全规范，而不是依赖训入的反射行为。两条路线都在把对齐从人工标签变成训练目标内部的一部分。

以 Constitutional AI 为例，两阶段流程是先让模型依照原则自我批评和修订输出，再用 AI feedback 替代逐条人工偏好标注。对齐从来不是挂在训练后面的补丁，系统测什么、怎么打分、奖励什么，模型就往哪个方向走，这本身就是训练后半段最直接的调节手段。

![](https://gastigado.cnies.org/d/public/image7.jpg)

## 到了 Agent 训练，优化的不只是模型本身了

过去两年，以 o1 系列和 DeepSeek-R1 为代表的推理模型快速成型，说明在奖励稳定、验证可靠、基础设施到位的条件下，语言模型上的 RL 确实能显著提升数学、代码和逻辑任务表现。

这同时打开了一个新维度：推理算力也可以扩展了。RL 训练的作用随之多了一层，它在教模型答题之外，还在教模型分配推理预算，知道什么时候多想、什么时候该停。再往前走，难点就变成让模型在环境里持续行动，而不只是把单次思考拉长。

Qwen 前模型负责人 Junyang Lin 对 Thinking 和 Instruct 混合路线的反思很有代表性：难点不在给模型一个思考开关，而在两种模式的目标本来就不一样，一个追求直接、合规和低延迟，另一个追求更多探索和更高正确率。再往前一步，训练目标就会从回答前想多久，转成行动里怎么分配预算、怎么接反馈、怎么继续推进任务。

这时候训练对象不再只是一个会回答问题的模型，而是一个能规划、调用工具、接收反馈、在长任务里保持连贯的系统。于是训练栈也跟着变了，浏览器、终端、搜索、执行沙盒、内存系统、工具服务器、编排框架都开始进入训练系统。

更准确地说，harness 是包在模型外层的控制程序，这个概念不只属于 Agent 运行时，训练阶段同样有它：决定模型看到什么输入、以什么形式接收反馈、何时裁剪上下文、何时调工具。prompt construction、memory update、retrieval policy、context editing、tool orchestration 都在这里。环境也不再只是静态验证器，而是训练和部署都要直接面对的一层。

![](https://gastigado.cnies.org/d/public/image8.jpg)

harness 先稳住，模型训练才有意义。工具返回值不稳定、浏览器环境和线上不一致、文件系统状态不可复现时，grader 会先出错，模型随后学到的就不是能力，而是如何利用环境漏洞。训练 Agent 时，很多时候既在 debug 模型，也在 debug 环境。

三家的做法也很清楚：Kimi 用 PARL 解决并行拆解和 credit assignment，Cursor 用 self-summarization 和 real-time RL 把长时 coding session 与生产流量重新接回训练，Chroma 则把 prune\_chunks 训成策略本身，让 context pruning 直接进入检索过程。

SFT 时代数据多样性是第一位，到了 Agent 时代，环境质量才是核心：稳定性、真实性、覆盖度、难度分布、反馈丰富度和抗利用性。训练目标也随之变化，要的是在完整任务里保持可靠，不只是做对一道题，经典 CoT benchmark 覆盖不到这部分。

这个变化还在继续前移：不只是在 runtime harness 里训练模型，连 harness code 本身也开始成为可以被外循环搜索和优化的对象。

![](https://gastigado.cnies.org/d/public/image9.jpg)

Kimi K2.5 的 PARL 是一个很值得拆开的工程案例，路线很明确：只训练 orchestrator，把 credit assignment 收束到编排层，不在所有 sub-agent 上同时优化。

奖励信号分三类，任务成功、并行分解和完成约束，一起驱动编排层。训练早期把 r\_parallel 权重拉高，鼓励先探索并行策略，后期再逐步退到 0，避免把多开 sub-agent 当成捷径。评估也不只看总步数，还看关键路径长度，关键路径变短才说明并行真的生效。

但到了 2026，事情又往前走了一步，Meta-Harness 明确把 harness engineering 单独拿出来优化。它优化的不是权重，而是 harness code 本身，也就是围绕固定模型的 prompt construction、retrieval、memory 与状态更新程序。论文开头的数字很直接：同一个底模，只改 harness，在同一 benchmark 上就可能拉出 6x 的性能差距，模型外层这套程序已经不只是部署细节，也是能力形成的一层。

它的关键也不是再加一个抽象 optimizer，而是把 prior code、scores、execution traces（工具调用和状态变化的执行日志）全部写入 filesystem，让 proposer 像写代码一样去 grep、cat、比对 diff，再顺着失败路径改 harness。proposer 是提出 harness 修改方案的模块。

作者判断得很明确，过去很多 text optimizer 对 harness 这类长时、状态化程序不够有效，核心原因是只看 scalar score、短模板或总结会把问题压扁。scalar score 只有最终得分，没有过程信息。harness 的错误常常要很多步之后才显现，反馈一旦被过度压缩，诊断链路就会断。

这些结果不只是 benchmark 分数更高。在线文本分类里，Meta-Harness 比 ACE（agent 上下文工程基线）高 7.7 个点，同时把 context token 用量压到原来的 1/4。检索增强数学推理里，一个发现出来的 harness 在 200 道 IMO-level 题上，对 5 个 held-out 模型（未参与优化）平均再涨 4.7 个点。在 TerminalBench-2 上，它也超过了手工工程化 baseline。这说明被优化的已经不只是模型内部策略，也包括模型外围那层如何组织信息和行动的程序。

一个具体例子：Meta-Harness 在 TerminalBench-2 上自动发现了 environment bootstrap，也就是 agent loop 开始前先跑一个 shell command，把工作目录、可用语言、包管理器和内存状态整理成快照注入首轮 prompt。很多 coding agent 前几轮其实都在探环境，这层前置做好，提升不一定来自更强权重，而是 harness 让模型一开始就站在更好的上下文上。

到这里，优化目标已经从答案扩展到轨迹，再扩展到承载轨迹的 harness program。

![](https://gastigado.cnies.org/d/public/image10.jpg)

## 前沿模型发布后，训练链路还在继续跑

单用一轮预训练的思路来理解今天的大模型，已经不够了。发布出去的模型背后，通常已经跑完了预训练、后训练、蒸馏、专用化这整条链路，而且更强的模型还在持续给下一代产出训练数据。

DeepSeek-R1 系列的蒸馏就是很典型的例子，大模型先通过 RL 和 verified rewards 把推理能力练出来，再把这些推理轨迹迁给更小的 dense 模型。TranslateGemma 这类专用模型则展示了另一条路线：在更明确的目标任务上，用高质量数据和专门的奖励设计，把能力进一步压缩和定向。到了这一步，更强的模型已经不只是拿来服务用户，也开始直接给下一代模型产出训练数据。

背后的原因比轨迹迁移更根本一些：一个可能的解释是，互联网语料里知识记忆和推理能力是耦合在一起的，现有的预训练目标要求模型同时把两件事都学好。大模型之所以要先上来，是因为只有足够大，才能同时撑起这两件事，然后再用它来生成纯推理示范数据，小模型在这类数据上训练，就可以专注在推理本身，不用再被迫把所有知识都记住；先大再小，一个关键原因是能力解耦，不只是成本策略。

另一边，部署适配性和能力本身同样重要。很多场景不需要全能大模型，更关心成本、延迟、稳定性和可控性，训练的终点不一定是更大，也可能是更小、更便宜、更专门。

最后发布的模型，不一定是训练曲线最右边的那个 checkpoint。实际发布前往往会在多个 checkpoint 之间反复比较真实任务结果、拒答风格、工具稳定性、成本和回归风险。最后上线的版本往往是产品决策，不是单一指标上表现最强的那个。

用户看到模型名字，会以为它对应一条平滑上升的训练曲线，但真正选哪个 checkpoint 上线，那是另一回事。

大模型的价值，既在它自己的服务能力，也在它会继续给下一代模型提供训练数据、蒸馏来源和发布基座。

离线训练之外，接近在线的持续优化也已经进了主流程，Cursor Composer 2 的 real-time RL 说明一部分 Agent 能力已经开始通过生产流量持续迭代，而不是等下一轮大规模离线训练统一刷新。训练和部署之间的边界并没有消失，但两者的反馈回路正在缩短。

## 以后怎么看一个模型为什么变强了

2026 年前沿模型的价值，越来越看谁能把预训练后面这整套训练链路跑完整：持续产出训练数据、做蒸馏、做专用化、把评测和奖励做好、做最后的发布选择。
也因为这样，后面再看一个模型为什么突然变强，可以先看三件事：

* 先看变化发生在预训练层，还是后面的训练流程。很多能力提升确实来自更强的预训练和更好的数据配方，但也有很多体感变化，其实主要出在后训练。模型会不会听指令、会不会用工具、回答风格稳不稳，常常不是多训一点语料自己长出来的。
* 再看提升来自哪一层：是权重和训练配方，还是 reward / eval / grader，还是 harness code 和 deployment loop。到了推理模型和 Agent 这一段，用户感受到的变强，很多时候已经不是基础模型单独做出来的结果。评测怎么设、奖励怎么打、工具环境稳不稳、retrieval 和记忆怎么组织、summary 和上下文怎么剪、上线时选了哪个 checkpoint，这些都会一起改掉最后的产品表现。
* 最后看上线版本在优化什么。有些版本是在追求更高上限，有些版本是在压成本、延迟和回归风险，还有些版本是在给某一类场景做专用化。发布版本本来就是产品决策，不是训练曲线最右边那个点，所以看模型更新时，顺手看它到底在优化什么，会更接近真实情况。

把模型突然变强这件事拆回生产环节看，很多提升其实是后半段训练栈和外层 harness 一起放大的。这条链路的迭代周期也在缩短：生产流量持续回流到训练，每代更强的模型在产出能力的同时也在产出下一代监督数据，外层程序根据 rollouts、logs 和真实任务反馈不断重写。

今天发布的模型只是一个快照，链路和 harness program 才是持续在跑的产品。

![](https://gastigado.cnies.org/d/public/image11.jpg)

## 学习资料

1. Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla). arXiv:2203.15556
2. Ouyang et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). arXiv:2203.02155
3. Shao et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). arXiv:2402.03300
4. DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948
5. DeepSeek-AI (2024). DeepSeek-V3 Technical Report. arXiv:2412.19437
6. Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. arXiv:2407.21783
7. Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073
8. OpenAI (2024). Deliberative Alignment: Reasoning Enables Safer Language Models. openai.com/index/deliberative-alignment
9. Anthropic (2025). Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models. anthropic.com/research/reward-tampering
10. MacDiarmid et al. (2025). Natural Emergent Misalignment from Reward Hacking in Production RL. arXiv:2511.18397
11. Lee et al. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses (preprint project page). yoonholee.com/meta-harness
12. Kimi Team (2026). Kimi K2.5 Tech Blog: Visual Agentic Intelligence. kimi.com/blog/kimi-k2-5
13. Rush, S. (2026). A technical report on Composer 2. cursor.com/blog/composer-2-technical-report
14. Chroma (2026). Chroma Context-1: Training a Self-Editing Search Agent. trychroma.com/research/context-1

本文不授权任何方式的转载，洗稿再发布，如大伙发现，欢迎去帮我举报。

## Media

![](https://gastigado.cnies.org/d/public/image12.jpg)
![](https://gastigado.cnies.org/d/public/image13.jpg)
![](https://gastigado.cnies.org/d/public/image14.jpg)
![](https://gastigado.cnies.org/d/public/image15.jpg)

---

---
url: https://ain.hmgf.hxcn.space/ai/embodied-ai-robot-dog-to-optimus-202606.md
---

# 你不知道的具身智能：从小机器狗到 Optimus

![](https://gastigado.cnies.org/d/public/image1.jpg)

## 太长也要读

今年 4 月我组装了一台小机器狗，做的过程在推特上发过几条，大伙应该都刷到过，从买零件、装结构，到最后它能听懂指令、走两步、还能对话几句。

缘由要从过年那段时间说起，那阵子我天天用 Opus 4.6 写代码，发现很多地方它写得比我好，又快又准，越用越 FOMO，于是就想，要不试试软硬件结合的东西，这块相比纯软件可能还有一点门槛。

真想做了，方向很快就落到具体问题上，传感器怎么读，舵机怎么控，通信怎么兜底，电池、结构件和故障怎么处理。这些都比「做一台机器人」实在，于是我买了 STM32、ASRPRO、ESP32-C3、MG90S 舵机、OLED、DHT11、锂电池，还有一套 3D 打印结构件，凑成一台能听懂话、会趴下、会走路、还能接云端 AI 对话的小机器狗。

真上手才发现，最费时间的反而是各种小细节，MG90S 舵机 4 个里总有一个不太稳，OLED 我带电插一次就直接烧了，又多等了几天零件。直到 DeepSeek 对话、温湿度读取和动作控制都真跑起来，我才慢慢体会到「AI 进入物理世界」是什么意思。

从软件视角看，具身智能很容易被理解成给大模型接上一副身体，但真把线插上、电机转起来、结构件震起来，感受完全不一样，一条自然语言指令一路要变成结构化意图、动作序列、PWM、力矩、电流和接触，每一层都有自己的时间、能量和误差预算，还冒出一堆纯软件里根本不用操心的问题。

发完「你不知道的大模型」那篇文章后，有小伙伴起哄，看来你要写「你不知道的具身智能」了。我一想这台小机器狗刚好能帮上忙，虽然很皮毛，但我想聊的「感知、空间、动作、力矩」这些具身智能的基本概念，它身上其实都有，于是就开始了。

文章前半写这台机器狗的创造过程，后半是我基于公开论文、官方博客、开源项目和第三方资料整理的学习笔记，希望能给在 AI 之外、也想了解具身智能的朋友，多一个工程师视角。

## 先把小机器狗跑起来

这台小机器狗最后做成了一个低成本异构系统，加起来成本大概 200 多的样子，能听到唤醒词后进入对话，把用户指令交给云端 LLM 做语义理解，再把返回的结构化动作转成 STM32 能执行的舵机控制。

把它拆成数据流，对调试很有帮助。后面很多卡住的地方，最后都落在周边硬件上，比如唤醒词误触发、联网超时、舵机角度或供电不稳，这些偏硬件的坑甚至能整理成一张排查表：

一开始也想过，要不要换一颗更强的芯片全包了，真接线以后发现不是一回事，唤醒、联网、PWM、传感器读取、云端请求，各自要处理的延迟和稳定性都不一样。

ESP32-C3 负责 Wi-Fi 和云端 AI，接入 2.4GHz 网络，把语音或文本转给云端模型，再把结果发给 STM32。它比 STM32 更适合联网，但如果同时承担 PWM、多路串口、网络请求和对话状态，调度会很快变重。

ASRPRO 负责离线唤醒，低功耗监听环境声，识别到唤醒词再拉起联网，比全程上传音频更省电，也少一些隐私压力。

STM32F103 是 72MHz 的 ARM Cortex-M3，Flash 64KB、SRAM 20KB，跑模型不现实，做硬实时控制刚好；4 个 MG90S 舵机用 50Hz PWM 控角度，0.5-2.5ms 脉宽对应 0-180 度，硬件定时器能稳定输出微秒级 PWM，舵机走路时就不容易被任务调度带偏。

大概清明节前的那个周五零件和工具就全部到了，当天晚上开始整，持续几天，最后它从一堆零件变成了一台绑着线、能走好几步、能听懂简单指令的小机器狗，挺有趣的。

这里也用到 MCP 的概念，只不过在这台小机器狗里更简单，就是给模型和设备定一份「能力清单」。设备把自己能干的事报上去，模型照着清单调用。

对我最有用的地方，是把哪些能力留在本地、哪些能力交给云端先分清楚：设备端控制扬声器、LED、舵机、GPIO 等本地硬件，云端扩展智能家居、PC 操作、知识搜索、邮件等能力，这样边界会清楚很多。

实际完整走一遍是这样的，ESP32-C3 先上报自己有哪些能力（servo\_control、sensor\_read、gpio\_write），我说「曼波坐下」，云端模型生成一个结构化调用（目标舵机、目标角度、速度参数），ESP32-C3 把它翻成 UART 指令发给 STM32，STM32 再一步步调整 PWM、回传执行状态。

这套小系统已经能听懂「坐下」、「站起来」、「现在温度多少」。空间能力完全没有，自己在哪里、椅子在哪里、往左走两步会不会撞到，全不知道。

## 机器人怎么知道自己在哪

小机器狗听不懂「往左走两步绕过椅子」，它根本不知道椅子离自己多远，也不知道自己在房间里站哪儿、朝哪边，更没有一张能持续更新的 3D 地图，深度感知、位姿估计、空间地图，这三样能力它都没有。

补空间能力不是再多接一个模块。深度相机、IMU、能跑 SLAM 的板子一上来，成本、功耗、算法栈就完全不一样，STM32 那套小系统也接不住。

后面还会多出四条新链路：「相机标定」要处理内参、畸变、曝光和同步；「位姿估计」要算清相机、IMU 和机身坐标之间的变换；「地图更新」要考虑环境变了之后旧地图怎么失效或修正；「动作规划」则是地图上可达，不等于真实脚底能稳定落下。

小机器狗如果只在桌面上演示，可以绕开这些问题。一旦放到房间里，地板反光、桌腿遮挡、线缆、台阶和光照变化都会进来。

图像模型擅长回答「这张图里有什么」这种 2D 问题，但机器人还得继续回答：这个物体离我多远，遮挡是什么情况，从哪个方向抓更稳，移动一步以后视角和支撑点会怎么变。

在 2D 图像里，一个杯子只是几百个像素。放到机器人世界里，一个杯子是有体积、重量、摩擦、遮挡和接触面的物体。机器人常用的 3D 表示主要有下面这几种，工程代价差别不小：

这张图是我用 ChatGPT Image2 画的，把几类 3D 表示放在一起看，差别会更直观一点。

低层避障常用 occupancy 或局部 cost map，抓取看点云和末端位姿，长期任务需要 scene graph 这种带关系的空间记忆。难的是把它们放到同一个时间轴和坐标系里，3D 场景一旦无法持续更新，很快就会变成过期照片。小机器狗完全没有后两者，所以「往左走两步绕过椅子」这种指令根本没法执行。

SLAM 和点云擅长几何，能给位姿和障碍物，但语义弱，系统知道前面有一团点，却不知道那是椅子还是纸箱。NeRF 和 3D Gaussian Splatting 擅长重建和生成新视角，对机器人来说，更要看它们能不能把仿真、数据增强和世界模型拉近真实场景。

3D Scene Graph 更接近长期记忆，它把房间、桌子、杯子、抽屉这些对象变成节点，把「杯子在桌子上」「抽屉属于柜子」「钥匙上次在玄关」变成关系。家庭机器人要回答「我上次把扳手放在哪里」，只存一堆视频帧很难做到。

空间记忆还必须保留不确定性。机器人只在画面里看过一次杯子，就不该永久相信它还在原处。对象名称、最近观测时间、置信度和可见性，实现时都要一起存。

![](https://gastigado.cnies.org/d/public/image2.jpg)

VLA 也在从 2D 往 3D 迁移。早期 RT-2、OpenVLA 主要把 2D 图像、语言和动作连起来，桌面抓取够用，但指令如果变成「把被挡住的蓝色积木拿出来」，2D 像素就不够了。机器人要知道蓝色积木被谁挡住，是否要先移开挡住它的物体，移开后是否会让别的东西掉下来。

3D-VLA、SpatialVLA 这类工作尝试把 3D 场景、SE(3) 位姿（位置加朝向，6 个自由度）和动作生成合到一起。Figure 的 Helix 系列虽然可以从单目视觉输入工作，但它仍然需要在内部学到深度、可操作性和物体关系。显式输入可以是 2D，内部表征要进入 3D。

单目摄像头做人形机器人同样需要权衡。单目可以通过多视角、运动视差和神经网络估深度，但需要足够的数据和稳定运动。主动深度或 LiDAR 是用硬件换确定性。Tesla、Figure、Boston Dynamics、宇树的传感器选择不同，背后是在视觉数据、算力、实时性和安全冗余之间取舍。

这也是我这台小机器狗的边界，它能把语言变成动作，但动作还不在空间里，没有位姿、地图和遮挡处理，「往左走两步」这种指令还是没法落地。

![](https://gastigado.cnies.org/d/public/image3.jpg)

## 从写死的动作到 VLA

我那台小机器狗跑的还是固定动作，你说「坐下」，它就调出一组预设好的舵机角度，并没有真的从画面和语言里生成新动作，只是在语音入口前面加了一层意图识别。

在真实的具身智能里，VLA（Vision-Language-Action）才是值得细看的方向，把视觉、语言和机器人状态一起喂给同一个模型，让它直接输出动作，减少「视觉检测、语言理解、规划、控制」之间一堆手写接口，不过接口少了，排错难度反而会增加不少。

![](https://gastigado.cnies.org/d/public/image4.jpg)

同样是「输出动作」，有的模型给关节角，有的给末端执行器（手或夹爪）的位移，有的给夹爪开合。关节角贴近硬件但难跨机器人迁移，末端位姿更通用却要配上逆运动学。

![](https://gastigado.cnies.org/d/public/image5.jpg)

最早是 RT-1，把 13 万条演示、700 多个任务喂给 Transformer，第一次把机器人控制当成序列学习。RT-2 再把互联网图文混进来训，让模型把网上学到的常识也带进控制，代价是连续的关节、位姿、夹爪压成 token 会丢精度，动作一多 token 串也跟着变长。

ACT 更直接，把动作打包成一小段一起预测。ALOHA 用一对便宜的遥操作臂就能插 USB、拉拉链、煎蛋，到现在还是很多人上手模仿学习的第一站。Diffusion Policy 解决的是「绕开障碍物」这种有多条合理路径的情况，普通回归容易学出个直接撞上去的折中动作，扩散从噪声一步步生成，反而能把几种都对的走法都保住。

π0 改用流匹配，采样快不少。π0.5 再把泛化往开放环境推，混进高层子任务、口头指令和网页数据一起训。Physical Intelligence 给的结果是训练环境越多、到新家越稳定，大约 100 个环境就追平了「直接在目标环境训练」。

SmolVLA 走另一头，把门槛压到消费级硬件，450M 参数、只用社区数据、3 万条 episode 以内就能跑，能力未必最强，但把 VLA 从大公司集群里解放了出来。社区数据多样性要覆盖光照、相机角度、房间和演示质量，和软件工程里的测试集类似，单一实验室的干净数据，未必比一批有噪声但覆盖更广的更管用。

2025 年后高低层分工更明确。Google DeepMind 的 Gemini Robotics 就是一路，ER 1.5 负责理解和拆任务，配套的 VLA 管把每步变成动作，还出了 On-Device 版，本地低延迟，50-100 条演示就能适配新任务。

这种分工演示起来往往很好看，但放到产品里就容易暴露问题。「按本地垃圾分类规则整理桌面」，高层模型要查规则、拆步骤、解释意图，低层模型要识别每个物体并放进正确容器，两层混成一个黑盒，真出了问题就很难排查。

Figure 的 Helix 也走分层系统。早期 Helix 里 S2 是低频 VLM，S1 是 200Hz 动作策略；Helix 02 又补了 1kHz 的 S0 全身控制层，把平衡、接触和协调放到更快的一层。小机器狗里的处理方式也类似，慢模型做理解可以，平衡、接触和协调得交给更快的一层。

机器人大脑的难点，除了听懂话，还得考虑动作怎么表示。动作太粗抓不准，动作太慢控制不稳，一旦动作不连续，真实电机和接触又会把误差放大一截，最后效果就会偏得很明显。

![](https://gastigado.cnies.org/d/public/image6.jpg)

## 绕不开的时间、能耗、数据

如果要把机器人系统的控制层拆一下，我一般分成大脑、小脑、肢体三块，落到工程里，其实就是不同频率的控制问题。

![](https://gastigado.cnies.org/d/public/image7.jpg)

小机器狗里也有这个分层，不过是极简版本。DeepSeek 对话是大脑，STM32 里的步态序列是小脑，PWM 和舵机是肢体。它不做动态平衡，1-2 秒的云端响应也能接受，但换成人形机器人，1 秒的平衡延迟就足够让它摔倒。

大脑层慢一点没关系。机器人听到「把杯子放进水槽」，会把它拆成找杯子、走过去、抓起来、松手，这种语义活儿不需要 1kHz。但小脑不行，它得快。人站着走着其实就是个倒立摆，控制回路一般得跑 200Hz 到 1000Hz，低了一受扰动就出问题。

再往下到肢体层就更要硬实时。电机控制要看编码器、估速度、限电流，一旦不对就立刻停掉，很多系统干脆把这一块放到专用 MCU 或 FPGA 上，避开 Linux 这类调度带来的不确定延迟。

延迟出在哪一层，表现完全不同。大脑慢，你觉得反应迟钝；小脑慢，一碰就倒；肢体慢，电机先抖再发热。

还有个容易被低估的坑，大脑、小脑各用各的坐标系，传感器又快慢不一（IMU 几百赫兹、摄像头几十赫兹、编码器上千赫兹），得靠标定和时间戳把它们对到同一个时间、同一套坐标上。标定一旦漂了，模型拿到的状态就跟真实世界对不上号，算法看着像是突然变笨，所以很多机器人 Debug 会先回到传感器、外参、零点和时间戳。

聊完时间，第二块就是能耗，机器人同样绕不开执行器和电池。一个人形机器人有几十个电机，电机、减速器、丝杠、编码器和驱动器往往是 BOM（整机的零件成本清单）里最贵、最难规模化的部分。

灵巧手尤其难。电机、腱绳、触觉、线束和散热全得塞进巴掌大的地方，所以很多公司反复打磨手部。人一天约 2000 kcal、折合 2.3kWh 就能活动很久，机器人没有骨骼韧带那套被动支撑，站着不动也得一直靠耗电撑着姿势。

第三块是训练数据，比普通大模型的数据难采太多了。文字能爬，图片能标，自动驾驶靠满街的车就能收一堆，可轮到机器人操作，你得有真硬件、有场地、有人看着，还得划好安全边界，这些都备齐了再开始采，成本直接高一个数量级。数据大致从这几个地方来：

仿真本来想绕开采集的麻烦，但它和真机终究不一样。光照、摩擦、间隙、磨损、传感器噪声、电机发热，仿真里都很干净，真机上却全是。比较稳的做法是先在仿真里把策略练到不犯低级错误，再拿少量真机数据校一遍，把失败样本收回去再训。指望仿真一步到位的，基本都会低估接触和传感器的误差，光靠仿真那点数据其实远远不够。

## Tesla Optimus 这个工程样本

我很喜欢 Tesla，也很早就买了它的股票，所以看 Optimus 难免带一点个人偏好。单独写 Optimus，是因为它把 FSD 迁移、纯视觉、端到端训练、自研执行器、工厂试跑和大规模制造放在同一台机器上。拆开研究它，手从演示灵巧走到长期可靠要多久，失败样本怎么补上接触数据，制造体系怎样把执行器、线束、传感器和电池做成可维护产品，这些问题都会更具体。

表里的数字来自 Tesla AI Day、财报电话会和第三方技术整理，主要是一些公开口径和目标。记得当年 AI Day 的 PPT 和视频被不少机器人公司一帧一帧研究，这件事本身就很有意思。

手部升级看着是小改动，放在机器人里其实很大。工厂里的「拧螺丝、插连接器、搬零件、贴标签」和家庭里的「拿杯子、开门、叠衣服」，只靠手臂大范围运动很难做好。手指要有足够多的接触点，也要知道物体是否滑动、是否易碎、接触面在哪里，这些都得一起考虑上。

![](https://gastigado.cnies.org/d/public/image8.jpg)

## 一根没有销钉的手指

2026 年 4 月 16 日，第三方拆解提到一组 WIPO 公开的 Tesla 手和前臂专利。专利本身不等于量产设计，但其中 WO 2026/080693 很能看出结构取舍，Joint Assembly for Robotic Appendage，也就是机器人附肢关节组件。当时在推特看到这个报告，我印象很深。

拆解材料里的思路是绕开传统销钉铰链，用一块扁平复合件夹在两节指节之间，上下两层弹性体，中间夹一片很薄的增强片，材料候选里出现了 Vectran 和 Nitinol，前者是液晶聚合物纤维，后者是镍钛超弹性合金，用来做方向性刚度。

这个设计要控制的是弯曲方向，手指弯曲方向要软，拉伸、压缩、剪切、扭转、侧摆这些方向要硬，传统销钉靠几何结构限制多余自由度，这个方案靠各向异性刚度来限制。工程上它有三个潜在收益，指节之间能形成接近滚动接触、转动轴随角度移动，更像真实手指；弹性体自带回弹，不一定要额外回位弹簧；腱绳还能穿过中性面，减小反复弯曲带来的疲劳。

这个案例看着像结构设计，背后其实牵连了灵巧手里一连串问题，一个关节结构会影响手指回弹、腱绳走线、腕部布局、前臂空间、装配公差和维修方式，它能不能在一天几千次抓取后还保持一致，演示里看不出来，需要实际到真实工作场景长期使用才知道有没有问题。

## Optimus 的 AI 是怎么做的

Optimus 和 FSD 同源是 Tesla 反复强调的技术点，AI Day 2022 提到，机器人躯干里的计算机来自车端 FSD 计算机，软件栈也复用了车辆里的目标识别、occupancy network、室内导航和运动规划，也有第三方把 Optimus 描述成 8 个摄像头输入，输出到 78 个执行器的端到端系统。

Tesla 其实不是「单一端到端神经网络」，FSD 完整构建涉及 48 个网络，更准确的说法是，Tesla 是追求端到端可学习的统一系统，工程实现更可能是共享表示的多任务 multi-head 架构。

自动驾驶的动作空间其实不大，方向盘、油门、刹车这几样基本就说完了，但人形机器人是另一回事，Optimus 按 78 个执行器算，每一个时间步都得把身体、手臂、手指、平衡、接触一起兼顾到，杯子稍微滑一下，手指力、手腕、手臂轨迹、重心也需要同时跟着调整。

端到端路线能省掉模块之间一堆手写接口，让视觉、语言、空间和动作通过统一训练互相影响，但出了错很难定位，抓错零件时，是深度估计错了，物体语义错了，动作头错了，还是执行器跟踪失败？工程系统仍然需要日志、状态回放、安全控制器和可解释的中间信号。

把 Optimus 放到工程系统里，我会先拆成四个接口，这样更容易看清楚它难在哪。

![](https://gastigado.cnies.org/d/public/image9.jpg)

这四个接口放到小机器狗上也能对上，只是尺度差很多。我的狗只有「语言到固定动作」和「动作到 PWM」，少了视觉到 3D 和接触状态。Optimus 的难点是四个接口都要同时成立，而且任何一层出错都可能被统一模型吞进黑盒里。

## 数据从哪来，量产难在哪

Tesla 的优势常被概括成车队数据，这里只说对一部分，车队数据能给 Optimus 带来视觉常识、空间理解、光照适应、动态物体预测和 occupancy 表示，但汽车并不处理杯子摩擦系数，也不用手指判断纸箱是否瘪了，其实现在机器人最缺的是真实物理世界的接触数据。按目前公开资料，Tesla 的 Optimus 数据主要来自这四类：

所以才有了人类操作员带着头盔和背包相机去现场采集这种做法。前段时间我还看到国内的具身智能公司和家政公司合作，让阿姨带着传感器和摄像头去打扫卫生，这类合作也是在补物理世界接触数据。

![](https://gastigado.cnies.org/d/public/image10.jpg)

机器人数据比自动驾驶慢得多，车队能靠满街的车每天一起采，遥操作通常一人一次只教一台，真机自主采更慢，失败还会磨损硬件、打断产线、带来安全风险，所以这事才这么难，但我还是挺看好这个方向。

机器人公司之间的差距，会慢慢体现在样本、训练和硬件改动的速度上，谁能更便宜、更稳定地采到失败样本，再把它们带进下一轮训练和硬件改动，谁的能力迭代就拉得更开。

![](https://gastigado.cnies.org/d/public/image11.jpg)

数据是一道坎，量产是另一道。

Tesla 每次财报电话会都会聊不少 Optimus，作为投资人，我一般会把他们讲的和当前真做到的分开辩证看，把 2024 到 2026 年的连续口径连起来，能看出一些持续的变化，也能看出每次难点在哪里。

比交付年份更难绕开的，是上面这些约束。人形机器人很难等模型训好再开产线，硬件、数据、制造通常一起推进。手部一改设计，前臂结构、线束、触觉传感器、控制器和供应链都要跟着动，执行器良率不稳，产能目标就会被最慢的零件给拖住。

比交付年份更难绕开的，是上面这些约束，人形机器人很难等模型训好再开产线，硬件、数据、制造通常一起推进，手部一改设计，前臂结构、线束、触觉传感器、控制器和供应链都要跟着动，执行器良率不稳，产能目标就会被最慢的零件给拖住。

从公开资料看，Tesla 赌的是三件事的组合，真实场景数据、制造规模和垂直整合。FSD 给它视觉和训练基础设施，工厂给它受控任务和反馈，制造体系给它降本路径，但手部可靠性、执行器成本、安全保护和真实工位 ROI 只要有一项卡住，这些优势也很难落到产品上。

后续 Optimus 的验证点会集中在几样东西上，手部结构的长期可靠性，失败样本回到训练和真机验证的速度，模型的可排错接口，产线目标背后的执行器和供应链支撑，公开资料里的 Tesla 路线如果成立，靠的是车队视觉经验、工厂任务、世界模拟器、训练集群和制造体系一起跑通。

## 几家公司的不同路线

现在做人形机器人的公司不少，路线和押的方向差别其实挺大。

这七家其实分两拨。一拨自己造整机，Tesla、Figure、宇树、智元都是从硬件到模型自己全包。另一拨不绑某一台机器人，Google DeepMind 做的是能接到不同本体上的智能层，NVIDIA 干脆把算力、仿真、世界模型和基础模型做成工具链卖给所有人。前一拨赌的是数据和制造能不能咬合，后一拨赌的是自己那层能不能跨机器人复用。

平台这条路听着省事，风险还是接口边界。上层指令太抽象下层接不住，下层失败说不清上层也没法重规划，跟前面 VLA 那章讲的问题很像。

其实也不是只有 VLA 一条路。Boston Dynamics 没有去蹭大模型叙事，靠电动 Atlas 和扎实的运动控制照样进工厂物流。工业现场看的是节拍、故障率和安全认证，而非演示效果好不好看。国内这边信号最实在的是价格和供应链速度，宇树 G1 官方起价 1.35 万美元，硬件基数能很快铺开，能不能做通用任务、能不能长期稳定还得持续来看。我那台小机器狗就停在最基础的固定动作层，这些路线对它来说都还太远。

这些路线背后是三种取舍。工厂场景普遍被当成第一站，因为环境可控、ROI 算得清、任务边界能限定。家庭场景最难，环境乱、用户容错低，还得做到安静、安全、隐私可控。平台公司则选择先卖工具链，因为大多数机器人公司本身就缺数据、仿真、边缘算力和训练框架。

## 从软件往具身智能走

如果你也是偏软件的工程师，想继续往下看具身智能，下面这些系统层知识绕不开。

* 嵌入式和实时系统：GPIO、PWM、I2C、UART、SPI、定时器、中断、RTOS
* 机器人运动学：坐标系、正逆运动学、Jacobian、末端位姿
* 控制基础：PID、MPC、状态估计、采样频率、延迟和稳定性
* 感知和 SLAM：相机模型、深度、IMU、LiDAR、外参、时间同步
* 模仿学习和强化学习：行为克隆、ACT、Diffusion Policy、reward、Sim2Real
* 数据工程：遥操作、episode 格式、视频和状态同步、标注、评估

放到一张图里，它是从芯片、执行器、传感器一路往上到算法和系统的一整个栈。单独看模型，很多问题根本看不出来；对着完整技术栈图看，每一块大概在哪一层会清楚很多。

资料串起来大概是这个顺序。先从小机器狗这类硬件项目入手，因为它们刚好能把「端云协同 + 本地动作」连起来。唤醒、联网、模型调用、能力描述、串口协议、动作执行、状态回传都能在一个小系统里遇到。项目不大，但每个环节都可能真实失败，一个个解决的过程，反而最有探索感。

端云协同和 MCP 跑过一遍后，再看 ACT / ALOHA，会更容易理解低成本遥操作和 action chunking；接着看 Diffusion Policy，动作为什么要建模成分布会更清楚；再到 RT-1、RT-2、Open X-Embodiment、OpenVLA 这条线，VLA 和跨具身数据就能接上；最后看 π0、π0.5、SmolVLA、Gemini Robotics、Helix、GR00T N1.5，产业界怎么把高层推理、低层动作和边缘部署拼到一起，也会落到更具体的问题上。

要我说具身智能的重点，就「感知、空间、动作、力矩」这四个词，大致也是难度从轻到重。感知 AI 已经够强，空间还在补课，动作刚学会一点，到力矩这一层，就要面对电机、结构、接触和供电这些实打实难做的东西。AI 越靠近物理世界，能靠模型解决的部分越少，剩下的更多是硬件的事。

## 参考文献

模型与算法

1. RT-1: Robotics Transformer for Real-World Control at Scale，Google Robotics, 2022。
2. RT-2: New model translates vision and language into action，Google DeepMind, 2023。
3. Diffusion Policy: Visuomotor Policy Learning via Action Diffusion，Columbia + MIT CSAIL, 2023。
4. Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware，ACT / ALOHA, 2023。
5. Open X-Embodiment，Google DeepMind + 33 institutions, 2023。
6. OpenVLA: An Open-Source Vision-Language-Action Model，Stanford + Physical Intelligence + Google DeepMind, 2024。
7. π0: A Vision-Language-Action Flow Model for General Robot Control，Physical Intelligence, 2024。
8. π0.5: a VLA with Open-World Generalization，Physical Intelligence, 2025。
9. SmolVLA: Efficient Vision-Language-Action Model trained on LeRobot Community Data，Hugging Face, 2025。
10. Gemini Robotics，Google DeepMind。
11. Gemini Robotics On-Device brings AI to local robotic devices，Google DeepMind, 2025。

产业、硬件与工具链

1. Helix: A Vision-Language-Action Model for Generalist Humanoid Control，Figure AI, 2025。
2. Introducing Helix 02: Full-Body Autonomy，Figure AI。
3. NVIDIA Jetson Thor，NVIDIA。
4. Cosmos World Foundation Model Platform for Physical AI，NVIDIA Research, 2025。
5. GR00T N1.5，NVIDIA GEAR。
6. LeRobot，Hugging Face。
7. SO-ARM100，SO-100 / SO-101 低成本机械臂硬件。
8. xiaozhi-esp32，开源 ESP32 AI 语音助手。
9. Genesis，开源物理仿真平台。
10. NVIDIA Isaac Lab，机器人学习框架。
11. Tesla AI Day 2022 transcript，Optimus 早期技术披露。
12. AI Training for Tesla Optimus Explained，Optimus AI 训练、数据来源和世界模拟器第三方整理。
13. Tesla Earnings Call Transcripts，2024 Q2 到 2025 Q3 财报电话会 Optimus 口径的公开 transcript 聚合入口。
14. The Pinless Finger: What Tesla Put Where the Hinge Should Be，Optimus Gen 3 手和前臂 WIPO 专利第三方拆解。
15. Unitree G1，宇树科技官方商城。

## 更多阅读

想接着看 AI 工程这一类，我之前几篇 X 长文可以按这个顺序读：

1. 你不知道的 Claude Code，架构、治理与工程实践
2. 你不知道的 Agent，原理、架构与工程实践
3. 你不知道的大模型训练，原理、路径与新实践
4. 你不知道的 AI Coding，非技术人的上手、场景与实战
5. 你不知道的 GEO，AI 可见性的原理、实践与取舍

初稿完成于 2026 年 5 月，6 月也在持续修订中，断断续续写了2个月，具身智能领域变化很快，部分数字和产品进展可能继续变化，发现错误欢迎指出。

## Media

![](https://gastigado.cnies.org/d/public/image12.jpg)
![](https://gastigado.cnies.org/d/public/image13.jpg)
![](https://gastigado.cnies.org/d/public/image14.jpg)
![](https://gastigado.cnies.org/d/public/image15.jpg)
![](https://gastigado.cnies.org/d/public/image16.jpg)
![](https://gastigado.cnies.org/d/public/image17.jpg)
![](https://gastigado.cnies.org/d/public/image18.jpg)
![](https://gastigado.cnies.org/d/public/image19.jpg)

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-for-science-paradigm-landscape-202607.md
description: 从"AI 读科学"到"AI 做科学"，科研智能体的范式转变与完整版图。
---

# AI for Science 详细介绍（上）：范式与版图

![封面图](https://gastigado.cnies.org/d/public/img_01.jpg)

## 引言

人工智能进入科学已经十几年，但前十几年它干的基本是一件事，读数据、找规律、做预测，AlphaFold是这条路的顶点。2024年以后情况变了，一批以大模型为内核、能自己规划和动手的系统，开始把AI推到"主动做"的一侧，自己提假设、设计并执行实验、写论文、失败了再迭代。这类系统被统称为科研智能体（scientific agents），它们撑起的研究范式，业界叫AI for Science（下文简称AI4S）。

围绕AI4S，最常见的两种判断恰好都偏了。一种被惊艳的demo唬住，以为"AI科学家"快要成真。另一种把它当成又一轮炒作，看不起。这篇文章想绕开这两种情绪，先把版图诚实地画出来，它到底是什么、长什么样、真实地走到了哪一步。至于谁在为它买单、机会又在哪，留给接下来的续篇。

下面六章这样走。第一章讲范式本身，AI怎么从"读科学"跨到"做科学"。第二章厘清概念，到底什么才算科研智能体。第三、四章用纵切（科学工作流的六个环节）和横切（四层基础设施）两套框架，把已有的系统铺开。第五章按学科扫描钱和热度的分布。第六章给一个尽量诚实的成熟度判断，能力到哪、可靠性到哪、真发现到哪。

## 第一章 从"AI 读科学"到"AI 做科学"

### 1.1 当 AI 自己设计出能用的分子

2024年，斯坦福等机构的一组研究者搭了一个叫"虚拟实验室"（Virtual Lab）的多智能体系统。几个扮演不同角色的AI，主持科学家、免疫学家、计算生物学家、批评者，围坐在一起"开会"，讨论怎么应对新冠病毒的变异。它们提出方案、互相质疑、收敛结论，最后给出一批新的纳米抗体（nanobody）候选。这些候选随后在真实的湿实验室里被合成、验证，确有部分能结合目标病毒（Swanson et al.，2025年发表于Nature）。

把这件事拆开看才显出分量。提出科学假设、设计验证路径、产出能被实验证实的新分子，这本该由一支训练有素的人类科学家团队走完，而其中相当一部分由AI自主完成。几乎同期，劳伦斯伯克利国家实验室的"A-Lab"展示了另一种形态，一个真正的自动化材料实验室，机器人按AI的决策自主合成、表征新材料（LBNL 2023, Nature）。再往前，Boiko等人（2023, Nature）已经证明，一个LLM驱动的系统可以自主设计并执行化学实验。

聊天机器人只会告诉你实验该怎么做。这里不一样，是AI真的把实验做了出来。业界把这个正在成形的研究范式称为AI for Science（下文简称AI4S），而这篇文章要刻画的，正是这场转变的起点。

### 1.2 范式转变：从分析工具到行动主体

要理解它的新意，得把它放进AI进入科学的历史里看。第一阶段，AI是"计算器的升级版"，用机器学习做回归、分类、降维，替科学家处理人力算不动的数据。这一脉的高峰是AlphaFold，它把蛋白质结构预测从难题变成了基础设施。可它本质仍是"读"，给定氨基酸序列、预测结构，是一个极强的预测器，却不会自己决定"接下来该研究什么"。

第二阶段，也就是这篇的主角，是AI从"读"跨到"做"。系统不只输出预测，还要承担科学方法本身的环节，规划、决策、调用工具、操作设备、解读结果、修正方向。多篇综述用"自治层级"来刻画这一跳，把LLM在科学发现里的角色分成"工具 / 分析者 / 科学家"三级（From Automation to Autonomy, EMNLP 2025），或"助手 / 伙伴 / 化身"三级（Hitchhiker's Guide to Scientific Agents, 2025）。无论哪套词，核心都一样，自主性（autonomy）的提升，才是这一代系统区别于上一代的根本。

这个转变之所以要紧，是因为科学的瓶颈往往不在"算得快"，而在"想得对、做得动"。一个能自己提出好问题、设计好实验、并把实验真正做下去的系统，触及的是科研产能的核心约束，不只是某个计算环节的提速。

![范式转变](https://gastigado.cnies.org/d/public/img_02.jpg)

### 1.3 为什么是这两年：能力拐点与"数据耗尽"

那为什么偏偏这两年集中爆发？这是因为两股力量叠在一起。一是能力侧的拐点。2023到2024年，大模型跨过了两道门槛，一是长链条的推理与规划，二是可靠地调用外部工具（搜索、代码、数据库、实验设备接口）。这两件事一旦成立，"让AI自己干一长串活"才从演示变成可能。2025年一批agentic系统密集出现，2026年进入落地检验期，竞争焦点从"能不能做出来"转向"能不能在真实环境里可靠地做"。

二是数据侧的逻辑，这点更深，也更关乎资本，留到中篇展开。前沿大模型已经快把互联网上的高质量文本用尽了，下一批高价值的数据增量从哪来？一个越来越被接受的答案是真实世界的科学实验。让AI去做实验、生成此前不存在的物理与生物数据，被很多人看作突破数据瓶颈的关键路径。这把"AI做科学"从一个学术理想，变成了产业和资本严肃押注的方向。钩子先埋在这，中篇再讲它怎么重塑了整个赛道的资本运作。

## 第二章 概念厘清：什么才算"科研 Agent"

"Agent"是2025年以来被用得最泛的词之一，泛到几乎失去信息量。要让后文的版图站得住，必须先把概念钉死：哪些系统算科研Agent，哪些不算，判断标准是什么。

### 2.1 三类容易混为一谈的系统

把当前与科学相关的AI系统摆在一起，至少有三类常被混为一谈，但它们的能力边界完全不同。

**第一类，聊天式AI（科学问答助手）。** 你问"这个假设该怎么验证""帮我解释这篇论文的方法"，它给出文字回答。它的能力上限是"说"。再博学，也只是一个会表达的顾问，不会替你动手。绝大多数研究者日常用的通用聊天模型属于此类。它有用，但它不改变"谁在做研究"这件事。

**第二类，传统科学机器学习（SciML）。** 这是AI进入科学的主流形态，也是成果最丰的一脉：用神经网络做性质预测、结构预测、代理模型（surrogate model）、求解偏微分方程等。AlphaFold是其巅峰。它的特征是"强预测、零自主"：它在一个被人类精确定义好的任务上做到极致，但它不决定研究方向、不规划多步流程、不调用工具去完成一个开放式目标。它始终是被调用的那一方，真正做决定、用工具的主体另有其人。

**第三类，科研Agent。** 它在前两类之上多了"自主性"：能把一个相对开放的目标拆解成多步、自己决定每一步调用什么工具（检索、写代码、跑仿真、驱动设备）、读回结果后调整下一步，直到把任务闭环完成。第1.1节的Virtual Lab、A-Lab、Coscientist都属于此类。

![三类系统对比](https://gastigado.cnies.org/d/public/img_03.jpg)

三者更像是层叠关系。科研Agent内部往往调用聊天式AI来推理、调用 SciML模型来预测。换句话说，Agent是"会使用工具的主体"，而前两类常常是它手里的工具。

### 2.2 一条分界线：会不会自己动手闭环

如果只能记住一条判断标准，那就是：它是只输出建议，还是能自主执行并闭环。

一个直观的检验：让系统去"重置一个数据库密码"。聊天式AI会告诉你重置的步骤，科研Agent会真的连进系统、执行重置、确认成功。如果一个工具在关键动作上仍然需要人来"按最后那个按钮"，那它更接近助手，而非Agent。

在科学语境里，这条线体现为：系统能不能在没有人逐步干预的情况下，自己走完"规划、执行、观测、修正"这个循环。Curie（Kon et al. 2025）这类工作之所以强调"严谨的自动化实验"，正是因为这个闭环一旦自动化，最大的敌人就变成了"中途出错却无人纠正"。这也预示了第六章要谈的可靠性问题。

还得说清楚一点，自主性是一条连续谱，而非非黑即白的开关。完全不需要人的"全自主科学家"目前基本不存在，现实中的系统都分布在"人重度介入"到"人轻度把关"之间。这正是下一节"自治层级"要刻画的。

### 2.3 自治的层级：工具 / 分析者 / 科学家

多篇综述都用层级来组织这个领域，其中较清晰的一套来自EMNLP 2025的综述《From Automation to Autonomy》，它把LLM在科学发现中的角色分为三级：

* **Level 1，LLM作为工具（Tool）。** 人主导研究，AI在被明确指定的子任务上提供帮助：润色文字、生成一段代码、做一次文献检索。决策权完全在人。
* **Level 2，LLM作为分析者（Analyst）。** AI承担更完整的分析环节：自主做数据分析、表格/图表推理、统计建模，甚至提出候选模型。人仍设定问题与边界，但AI在边界内有了一定的自主裁量。
* **Level 3，LLM作为科学家（Scientist）。** AI跨越多个环节、长链条自主运行：从假设到实验到结论，人退到"设定高层目标 + 把关"的位置。第1.1节的案例与第3.6节的端到端系统都在向这一级逼近。

![自治层级](https://gastigado.cnies.org/d/public/img_04.jpg)

另一套常被引用的三分法（Hitchhiker's Guide to Scientific Agents, 2025）用"助手 / 伙伴 / 化身"（Assistant / Partner / Avatar）表达类似的递进。Ren et al.（2025, arXiv 2503.24047）的综述则采取"机制中心"的视角，关注智能体的规划与记忆等内部机制，并尖锐地指出：现有规划架构大多是"任务特定"的，距离支撑开放式发现的"通用科学规划能力"还很远。

这些层级框架对读者的价值在于：当你看到一个号称"AI科学家"的系统时，第一件事是判断它真实处在哪一级。很多惊艳的演示其实停留在Level 2，被包装成了Level 3。

### 2.4 与企业 Agent 的异同：形态相同，本质不同

科研Agent与当下火热的企业Agent（客服、销售、编程助手）共享同一种"形态"，都是会自主调用工具、执行多步任务的系统。这也是为什么Claude Code、客服机器人、科研助手都被叫做"Agent"。但它们是两门不同的生意，区别在护城河：

* **企业Agent** 的壁垒主要是工程能力、系统整合与对某个商业流程的理解。它的"对错"通常有即时、可量化的反馈（工单是否解决、代码是否通过测试、转化是否提升）。
* **科研Agent** 的壁垒是科学判断力与学科know-how。它的"对错"往往没有即时反馈，一个科学结论是否成立，可能要经过同行评审、复现、乃至数年的检验才能确认。这使得科研Agent的评估本身成为一个困难且关键的问题（第四、六章详谈）。

这个区别有一个直接推论：在科研Agent这条线上，纯粹的AI工程能力不足以构成壁垒，懂科学的人反而握有别人翻不过去的墙。这一点会贯穿整个系列。

### 2.5 我们采用的工作定义

综合以上，这篇采用如下工作定义，作为后续版图的纳入标准：

> 科研 Agent：以 LLM 或基础模型为推理内核，具备自主规划能力，能够调用外部工具（检索、代码执行、仿真、数据库、实验设备等）来推进一个相对开放的科学目标，并能根据中间结果调整后续行动的系统。其自主性可处于"分析者"到"科学家"之间的不同层级。

按此定义，纯聊天问答与纯预测型SciML不计入主体，但它们作为科研Agent的"内部器官"会被反复提及。下面两章，就用纵切与横切两套框架，把符合这一定义的已有工作系统地铺开。

## 第三章 纵切生态：沿科学工作流的六个环节

理解AI4S的版图，最直观的方式是顺着科学家干活的流程走一遍：读文献 → 提假设 → 设计实验 → 执行实验 → 分析数据 → 撰写并评审论文。每一个环节，都已经长出对应的智能体，且成熟度与活跃度各不相同。本章逐环梳理代表性工作，第四章再补上托底这些环节的横向基础设施。

### 3.1 文献检索与知识合成

这是最先成熟、也最先被研究者日常使用的一环。原因很简单，它风险低、价值即时，读不完的文献是每个研究者的真实痛点。

这一环的标杆是FutureHouse体系的 PaperQA / PaperQA2。这个团队2024年那篇题为"语言智能体实现对科学知识的超人级综合"的工作（Skarlinski et al. 2024, arXiv 2409.13740），展示了一个检索增强（RAG）的科学问答智能体。它会实时检索文献、定位证据、给出带出处的回答，并在若干评测上声称达到超过人类专家的知识综合水平，而不是凭记忆硬答。"带出处、可核查"这一点尤其关键，因为它直接对治大模型的幻觉问题，使输出在科研场景中可被信任。

围绕"读与查"，还有一批各有侧重的工作。LitLLM（Agarwal et al. 2024）面向文献综述生成。LitSearch（Ajith et al. 2024）面向文献检索。CiteME（Press et al. 2024）面向引用归因，即给定一句论断，找出它真正出自哪篇文献，这对治理"幻觉引用"很有意义。ResearchArena（Kang & Xiong 2024）与 SciLitLLM（Li et al. 2024）则分别构建文献调研工作流与科学文献理解能力。

![文献检索与知识合成](https://gastigado.cnies.org/d/public/img_07.jpg)

还要单独点一下 AutoSurvey（Wang et al. 2024, NeurIPS），它让LLM自动撰写综述文章。这类工作展示了能力，也带来了副作用，AI生成综述的泛滥已经在冲击学术生态（第六章与系列后文会回到这一点）。这正好说明同一项能力的两面，既是生产力，也可能是污染源。

把这一环放进整张图里看，文献与知识合成是AI4S中最接近"可靠可用"的一环，但它本质仍是"辅助读"，离"自主做研究"最远，是入口而非终点。

### 3.2 假设生成与科学推理

如果说读文献是"输入"，那么提出有价值的假设就是科学创造力的核心，也是衡量AI能否真正"做科学"的试金石。

这一环最具分量的实证来自斯坦福的Si et al.（2024，arXiv 2409.04109）。他们做了一项大规模对照研究，让LLM与人类专家分别生成研究想法，再请专家盲评。结论很有意思，LLM生成的想法在"新颖性"上被评得高于专家，但在"可行性"上更弱。 这个发现几乎定义了当前阶段AI假设能力的特征，它能跳出人类的思维定式抛出新奇组合，却缺乏对"这条路实际走不走得通"的判断。新颖而不可行，只是创造力的一半。

为弥补单体LLM的局限，多智能体路线被反复尝试。"Many Heads Are Better Than One"（Su et al. 2024）用多个LLM智能体协作生成科学想法，让不同"头脑"互相激发与筛选。ResearchAgent（Baek et al. 2024）则把假设生成做成迭代精炼的循环，生成、批评、修正。这些工作的共同思路，是用结构化的多轮交互，去逼近人类科研中"提出、质疑、打磨"的社会化过程。第1.1节的Virtual Lab正是这一思路在真实问题上的成功演示，让AI们"开会"，用批评者角色专门负责挑刺。

所以假设生成是AI4S里最让人兴奋、也最不可靠的一环。它偶有惊艳，但"新颖却不可行"的系统性偏差意味着，"判断哪个假设值得做"这件事，短期内还得牢牢握在人手里。

### 3.3 实验设计与自驾实验室（实验执行）

把"动手做实验"交给AI闭环，是AI4S中最重、最依赖领域与硬件、也最具冲击力的一环。它把AI从屏幕里拉进了物理世界。

奠基性的工作是 Coscientist（Boiko et al. 2023, Nature）：一个LLM驱动的系统，能够自主搜索文献、规划化学合成路线、并通过实验室自动化设备真正执行实验。它证明了"语言模型 + 实验室硬件"这条路在化学上可行。

![自驾实验室](https://gastigado.cnies.org/d/public/img_05.jpg)

材料领域的代表是伯克利的 A-Lab（2023, Nature）。一个高度自动化的实验室，机器人依据AI的决策自主合成与表征候选材料，把"提出配方、合成、测量、更新模型"的闭环交给机器，在十几天里完成了人类要花几个月的尝试。它体现了自驾实验室的本质，认知智能（决定做什么）与物理自动化（把它做出来）的耦合。不过A-Lab也提醒我们别急着把demo当定论。固态化学家Robert Palgrave等人随后公开质疑，说论文里那批"新材料"的表征（X射线衍射的解析）不过关，没有一个被可信地证明是真正的新相，这篇Nature后来也做了更正。这恰好是后面第六章要谈的"demo惊艳、落地存疑"的一个现场版。

![A-Lab](https://gastigado.cnies.org/d/public/img_06.jpg)

生物领域最具说服力的，仍是第1.1节的 Virtual Lab（Swanson et al.，2025年Nature），从假设到分子设计再到湿实验验证的完整闭环，且产出了被实验证实的新分子。此外，ChatMOF 等系统展示了在特定材料类别（金属有机框架）上自主预测与生成的能力。生物信息学方向也出现了用双环架构（规划环 + 实现环）做自主分析的尝试（如Huang et al. 2025）。

这一环的关键约束不在"智能"而在"闭环的可靠性与成本"：真实实验昂贵、耗时、且不可"撤销"，一旦AI在长链条中某步出错且无人纠正，代价是真金白银的材料与时间。这把第六章的"复合失败"问题，从抽象的概率变成了实验台上的现实。

### 3.4 数据分析、代码与论文复现

科学的可信度建立在"可复现"之上，而复现的核心动作之一，是把论文里的方法变成能跑出相同结果的代码。这一环因此既是分析工具，也是可信度的守门口。

Paper2Code（Seo et al. 2025）与 AutoP2C（Lin et al. 2025）用多阶段LLM流水线，把（机器学习）论文自动翻译成可运行的代码仓库，本质是"读懂方法 + 重建实现"。MLR-Copilot（Du 2024）则面向自主的机器学习研究，串起从想法到实验的流程。

![数据分析与复现](https://gastigado.cnies.org/d/public/img_08.jpg)

更具雄心的是DeepMind的 AlphaEvolve（Novikov et al. 2025, arXiv 2506.13131）。它编排一组Gemini模型做算法与科学发现，靠演化式的代码变异加评估反馈迭代出更优解。后续工作进一步把它与"深度研究"结合，用于科学算法的发现（DeepEvolve, arXiv 2510.06056）。这条线展示了AI不只是复现已有方法，还可能演化出新方法。

但"能复现"恰恰也暴露了"难复现"。当一个AI系统声称复现了某论文，如何验证它真的复现了、而非生成了看似合理的结果？这把我们引向第四、五章要重点谈的评估与基准，没有可信的裁判，"自动复现"本身就无法被信任。

### 3.5 论文写作与同行评审

流程的末端是写作与评审，这也是争议最集中的一环。

写作侧，前述AutoSurvey以及各端到端系统的"出稿"模块，已能产出格式完整、读起来像模像样的论文草稿。问题在于：流畅不等于正确，格式完整不等于有真贡献。

评审侧的探索更敏感。Generative Adversarial Reviews（Bougie & Watanabe 2024）等尝试让LLM扮演评审，用对抗式批评帮助改进论文。一些会议（如ICLR）已在工作流中引入AI评审建议。然而对Sakana AI Scientist的独立评估（2025, arXiv 2502.14297）给出了清醒的发现，AI生成的评审往往格式工整却停留在表层，抓不到深层方法缺陷。这反而抬高了"二级评审者"（如领域主席）的重要性，因为需要人去判断一篇工作是否真有价值。

这一环的张力，把整个AI4S的张力浓缩了出来，AI在"形式"上已逼近人类，在"实质判断"上仍有显著差距。写作与评审环节的自动化，因此与研究诚信问题深度绑定（第六章展开）。

### 3.6 把六环合一：端到端"AI 科学家"

当上述环节被串成一条自动化链路，就得到了最受关注、也最具争议的一类系统，端到端"AI科学家"，对应自治层级中的Level 3。

起点是Sakana AI的 The AI Scientist（v1）（Lu et al. 2024, arXiv 2408.06292）。它最早完整演示了"从想法到论文"的端到端自动化，但严重依赖人工编写的代码模板，探索流程偏线性，限制了发现的深度与适应性。The AI Scientist-v2（Yamada et al. 2025, arXiv 2504.08066）引入"智能体树搜索"和专门的实验管理智能体，减少对模板的依赖，支持多轮迭代探索。其产出曾有论文通过某ICLR workshop的评审（按事先约定在正式发表前撤稿），引发关于AI作者与AI评审同时入场的激烈讨论。Kosmos（Mitchener et al. 2025）沿类似路线推进实验管理与模板解耦。

并行的探索还有很多。Agent Laboratory（Schmidgall et al. 2025, arXiv 2501.04227）把LLM智能体组织成研究助理团队，覆盖文献到实验到报告。AI-Researcher（Tang et al. 2025, arXiv 2505.18705）面向自主科学创新。Curie（Kon et al. 2025, arXiv 2502.16069）强调实验的严谨性与可复现。SciAgents（Ghafarollahi et al. 2024）用多智能体"图推理"自动化发现，在材料方向格外突出。PiFlow（2025, arXiv 2505.15047）引入"原理感知"，让发现过程受科学原理约束而非盲目搜索。DeepScientist（Weng et al. 2025）主打渐进式推进前沿发现。Carl（Autoscience Institute 2025）被报道为最早一批产出通过学术同行评审研究的系统之一，不过这个"首个"在它和AI Scientist-v2之间其实有争议。Google的 AI Co-Scientist（2025）则把重心放在假设生成与人机协作上。此外，Denario 等多领域助手项目，以及天体物理方向的 AI Cosmologist（自动化宇宙学统计推断，详见第五章），也属于这一类的领域化变体。甚至有人开始设想为AI科学家产出搭建专门的发表生态，如 aiXiv（Zhang et al. 2025）。

把这些系统放在一起看，可以得到一个清醒的判断。它们在"流程跑通"上已经成立，能产出格式完整的论文乃至偶尔通过评审，但在"产生真实、重要的新科学"这件事上，证据仍然薄弱。 多数印象深刻的成果，要么是在受控、可验证的窄问题上，要么仍有大量人类介入。把"端到端跑通"误读为"科学家被自动化了"，是当前最常见的认知偏差。第六章会用具体证据来校准这个判断。

## 第四章 横切生态：四层基础设施

第三章的六个环节回答了"AI在科学流程的每一步做什么"，但它没有回答另一个问题：这些环节靠什么托底？任何一个科研Agent，无论它在哪个环节工作，都需要一个推理底座、一套执行环境、一把验收的尺子、以及一组连接外部世界的接口。这四样东西横切所有环节，构成AI4S的基础设施层，也就是这个系列反复提到的"水电煤"。本章逐层展开。

### 4.1 科学基础模型（SciFM）

第一层是底座。前两年的科研Agent大多直接调用通用大模型（GPT、Claude、Gemini等）当大脑，但通用模型并非为科学训练，在专业符号、单位、领域推理上常有短板。于是一个明确的趋势出现了：为科学专门训练的基础模型（Scientific Foundation Models, SciFM）。

SciFM的思路是用科学文献、实验数据、专业模态（分子图、晶体结构、基因序列、光谱、时序观测等）训练模型，使其在科学任务上具备比通用模型更扎实的"先验"。代表性的方向包括：面向生物的BioNeMo系列、面向材料与化学的多模态模型（如IBM的FM4M，覆盖分子图、三维原子坐标、电子密度等模态）、面向气候与地球系统的时序基础模型，以及把第一性原理势能融入分子动力学的"深度势能"类模型。这个方向重要到已经催生专门的学术会议（如SciFM主题会议）。

![科学基础模型](https://gastigado.cnies.org/d/public/img_09.jpg)

SciFM之于科研Agent，正如通用大模型之于通用Agent，它决定了"大脑"的科学素养上限。这里有一个判断值得记住，在缺乏数据的科学领域，把物理约束、守恒律、对称性等"硬知识"嵌进模型（physics-informed思路），往往比单纯堆数据更有效。这一点在第五章的物理与气候方向会再次出现，也是学科背景者能贡献独特价值的地方。

### 4.2 自驾实验室作为基础设施

第二层是执行环境。第3.3节从"实验执行环节"的角度介绍了自驾实验室。换一个视角，自驾实验室本身就是一层可被复用的基础设施，它把"让AI的决策变成物理世界里的真实操作"这件事标准化、平台化。

从基础设施视角看，自驾实验室要解决的是认知与物理之间的接口问题，AI大脑如何把"下一个该测什么"翻译成机器人能执行的指令，又如何把测量结果结构化地喂回大脑。Coscientist、A-Lab等系统在各自领域给出了答案，但它们大多是垂直、专用的。一个仍然开放的机会是"自驾实验室的通用编排层"，让不同设备、不同学科的实验闭环能共享一套调度与学习框架。这一层的核心难点是高维空间下的实验设计（决定下一个实验）与不确定性管理，恰恰是统计与物理背景者擅长的领域。

自驾实验室是四层中最"重"的一层，它需要真实的设备、空间与资本，因此也最难由小团队从零搭建（中篇会看到，这正是资本最密集、门槛最高的一层）。但它也是AI4S区别于"纯软件AI"的灵魂，没有它，AI永远只能"读和想"，无法真正"做"。

### 4.3 评估、基准与可复现

第三层是验收的尺子，也是本系列判断中最被低估、却最关键的一层。逻辑很直接：当一个系统声称"我能做科学发现"，凭什么相信它？必须有人出考卷、定标准答案、判对错、验证结果能否复现。没有这层，前面所有环节的成果都无法被信任，也就无法落地。

这一层正在按"学科 × 任务类型"快速繁殖，且大多是公开、可下载的基准：

* **跨学科 / 通用科学：** ScienceAgentBench（Chen et al. 2024）评估智能体做数据驱动发现的能力，任务取自同行评审论文并由领域专家验证。OpenAI的 PaperBench（Starace et al. 2025）评估AI复现AI研究的能力。SciReplicate-Bench（Xiang et al. 2025）测从论文出发的算法复现。CORE-Bench 从完整代码库复现论文结果。AstaBench（2025）是科学研究套件式的严格基准。AAAR-1.0、DiscoveryWorld、ScienceBoard 则分别从科研协助、模拟发现环境、科学桌面任务等角度切入。
* **生物 / 化学：** LAB-Bench（FutureHouse，arXiv 2407.10362）面向生物研究工作流，两千四百多个任务，覆盖文献、数据库、序列、协议、专利等多类。BixBench 面向生物医学。

这层有三个特征值得记住。第一，它必须由学科专家构建，出题、定标准答案、判对错，都要求真懂那门科学，纯AI团队做不出有效的科学基准。第二，它远未饱和，按"学科 × 子领域 × 任务类型 × 真实设施数据"组合裂变，现有基准只点亮了极少数格子。第三，它的得分普遍很低，多个基准上最强模型都远未达专家水平，说明问题远没被解决，正处早期。这三点合起来，使评估层成为学科背景者最锋利的切入点，这是下篇会重点展开的判断，这一篇先把它作为版图的一块标清楚。第五章会看到，物理与天体物理恰是这一层中起步较早的学科之一。

### 4.4 工具与编排层

第四层是连接外部世界的接口。一个科研Agent要真正干活，必须能调用工具：搜索引擎、代码执行沙箱、科学数据库、仿真引擎、实验设备API。把这些工具安全、可靠地接进Agent，并编排多个工具与多个子智能体的协作，就是工具与编排层的职责。

这一层在通用Agent领域已经相对成熟（各类agent框架、工具协议、记忆与状态管理），在科学领域则需要额外处理领域特定的接口，比如把某个天文数据库、某套仿真代码、某类实验设备接进来。一个具体的例子是用自然语言查询科学数据库的工作（如天文方向的text-to-SQL系统，详见第五章），它本质就是"把数据库这件工具接给Agent用"。

从可靠性角度看，工具与编排层也是失败的高发区，工具调用失败、返回格式不一致、长链条中状态丢失，都会导致整个任务崩溃。这把我们直接引向第六章，基础设施的成熟度，最终决定了科研Agent能否从"演示"走向"生产"。

把第三章的"纵切"与本章的"横切"叠在一起，就得到了AI4S的完整生态坐标：每一个具体系统，都可以被定位到"它在哪个环节工作、依托哪几层基础设施"。有了这张坐标，下一章我们换一个轴，从学科的角度，来看钱与热度如何分布。

## 第五章 学科版图：钱、热度与商业出口

前两章用环节和基础设施两个轴画出了"技术版图"。但AI4S的发展并不在各学科间均匀展开，资金、人才、关注度高度不均，而这种不均背后有清晰的逻辑：离"可变现的成果"越近的学科，钱越多。 本章按学科扫描，并在每个学科点出其代表工作、商业出口与对资本的吸引力。资本的具体运作（谁投、投多少）留给中篇，本章只勾勒分布与逻辑。

![学科版图](https://gastigado.cnies.org/d/public/img_10.jpg)

### 5.1 生命科学与健康：钱最多，因为出口最清楚

生命科学是AI4S中资金最密集的学科，原因直白，它的成果可以变成药，而药是有明确、巨大支付方的终极商业出口。从蛋白结构（AlphaFold的遗产）到蛋白与酶设计、抗体发现、靶点识别、临床数据分析，AI在生命科学的每一环都有落点。

代表性的能力已经被验证。第1.1节的Virtual Lab设计出经实验证实的纳米抗体。蛋白/酶设计方向出现了与大型药企深度绑定的合作，比如2026年4月Profluent与礼来达成战略合作，开发位点特异性的重组酶，Profluent最高可拿到22.5亿美元的里程碑款（细节见中篇）。各类面向健康的AI4S项目，也是公益与产业资本共同关注的头号方向，比如Google.org的AI for Science资助计划就把健康与生命科学列为首要方向。

一句话定性，生命科学是AI4S的"主战场"，但它也是壁垒最高、最拥挤、最需要湿实验与监管能力的学科。对没有生物背景与实验资源的人，它是观察样板，而非轻易可入的赛道。

### 5.2 气候、能源与聚变：政策驱动，物理对口

气候与能源是第二热的方向，由政策意愿与能源转型双重驱动。而且，这是对物理背景者的关键信号，它在方法论上与物理高度对口，气候本质是流体力学、热力学与辐射传输，能源与聚变更是物理的核心地盘。

这一方向最具代表性的成果是"混合物理-机器学习"的天气与气候模型。Google的 NeuralGCM（2024, Nature）把学到的动力学与物理约束结合，在中期预报到长期气候模拟上展现出与传统数值模型相当甚至更优的表现。NVIDIA的Earth-2 / Apollo、华为的Pangu-Weather等也属同一脉络，它们的共同点是不再纯靠算力硬解方程，而是让模型从历史数据里学到一部分动力学，跑得更快、更省。

聚变方向最标志性的一步，是2022年DeepMind与EPFL瑞士等离子体中心合作，用强化学习实时控制托卡马克里的等离子体磁场位形，让上亿度的等离子体稳定维持在所需形状（发表于Nature）。此外还有把全球聚变实验数据标准化、供AI从集体经验里学习的努力。这些都是典型的"物理问题用AI解"，而不是另起炉灶的新学科。

一个需要点出的"错位"：纯粹的"气候科技"创业融资近年实际在收缩（注意力被通用AI吸走），但"AI for气候科学"作为AI的子方向是热的。这意味着切入点更可能是"用AI/物理方法服务气候科学"，而非传统气候硬件创业。

对物理背景的人，这是少有的"方法直接对口"的入口。流体、热力学、辐射传输、等离子体物理本就是物理系的看家本领，切进来不必从头补一套生物或化学的湿实验技能，摩擦比生命科学那条路小得多。

### 5.3 材料与化学：与能源强绑定，凝聚态方法是引擎

材料与化学紧随其后，且与能源转型强绑定，新材料意味着更好的电池、催化剂、超导体、光伏。AI4S在这里的形态最接近"自驾实验室 + 生成设计"，用生成模型提出候选材料，用自动实验闭环验证。

代表工作里最出圈的是DeepMind的 GNoME（2023, Nature），它用图神经网络一口气预测了约220万种新晶体，其中约38万种被判定为稳定，等于把人类已知的稳定无机材料数量翻了好几倍。配套的A-Lab（自主合成材料）则把其中一批候选真的合成了出来，跑通了"AI预测加自动实验"的闭环。此外还有SciAgents（多智能体图推理做材料发现）、ChatMOF（金属有机框架）等。一个对物理背景者尤其重要的判断，材料与化学的AI引擎，底层是凝聚态与计算物理的方法论，密度泛函理论（DFT）、分子动力学、深度势能、多体系统。换句话说，被一些人视为"传统、窄"的凝聚态/计算物理技能，搬到AI for materials这个资本密集的市场，恰恰是稀缺的核心能力。这一反转在下篇会展开为具体的入场判断。

### 5.4 物理与天体物理：竞争最少，方法可横切

物理（含天体物理）不是资金最多的学科，但有两个独特属性使它对本系列作者格外重要：竞争者最少，且物理能力可作为"横切军火"输出给其他所有学科。

在AI4S内部，物理与天体物理已经形成了一块虽小但起步较早的版图：

* **自主发现与分析：** AI Cosmologist 自动化宇宙学的统计推断流水线，Denario等助手在天体物理任务上有应用。
* **数据库交互：** 面向天体物理自主发现的RAG智能体评估（2025, arXiv 2507.07155）系统比较了多种检索增强配置。天文数据库的自然语言查询（如ALeRCE text-to-SQL，2026, arXiv 2606.18108，针对含数十张表的真实天文数据库）展示了"自然语言到科学数据查询"的方向。
* **评估基准（这是物理天体起步较早的一块）：** Gravity-Bench（Koblischke et al. 2025, arXiv 2501.18411）让智能体扮演天文学家探索双星系统、在观测预算内自主规划观测并推断（可能被修改过的）引力定律，含分布外案例以测真正的泛化。ReplicationBench（Ye et al. 2025, arXiv 2510.24591）测端到端复现天体物理论文，最强模型得分很低。AstroVisBench（Joseph et al. 2025, arXiv 2505.20538）测天文的科学计算与可视化。AstroM-Lab 1（Ting et al. 2024）与 Astro-QA（Li et al. 2025）测天文知识问答。粒子物理则有 Collider-Bench，理论物理有 TPBench（arXiv 2502.15815）。

更值得关注的是社区层面的主动信号：Rubin/LSST暗能量科学合作组（DESC）2026年的AI/ML机会报告（arXiv 2601.14235）明确把贝叶斯推断、physics-informed方法、验证框架、主动发现列为方法论优先级，直言"评估框架才刚开始出现"，并呼吁建立合作组专属的评估基准、强调agentic AI的部署必须配合严格评估与治理。这是需求侧主动呼唤基础设施的直接证据。

物理能力的另一重价值在于"横切"，physics-informed建模、不确定性量化、主动学习、高维实验设计，这些能力在气候、材料、乃至生物的AI4S中都是刚需，而它们正是物理训练的产物。物理背景者因此有两条路，在物理/天体内部做深，或把物理能力作为军火输出给更热的学科。

### 5.5 数学与算法：小众但标志性

数学是AI4S中相对小众、但极具标志性的方向。它的特殊性在于：数学有客观、可机器验证的对错（证明要么成立要么不成立），这使它成为检验AI推理能力的理想试金石。AlphaEvolve在算法发现上的工作、以及一批面向"生成猜想 + 自我验证证明"的系统（部分已获显著资本关注，见中篇），代表了这一方向。数学的进展往往被视为AI通用推理能力的前沿指标，因此关注度高于其经济体量。

### 5.6 为什么钱这样分布

把五个学科放在一起，分布的逻辑就清楚了：资金大致按"商业出口的清晰度与近度"排序。

![资金分布逻辑](https://gastigado.cnies.org/d/public/img_11.jpg)

这张表也解释了一个表面矛盾：物理/天体的资金不是最多，但对物理背景者却可能是最优入口，因为竞争最少、壁垒（学科判断力）最契合自身、且能力可横切到更热的学科。这是一个"避开红海、用长板打"的位置，下篇会把它展开为具体策略。

学科版图扫描至此。但无论哪个学科，都绕不开一个共同的问题：这些系统，到底成熟到什么程度了？第六章直面这个问题，尽量把好话和坏话都说全。

## 第六章 发展程度的真相：能力强，但可靠性拖后腿

前四章描绘的版图容易让人产生一种错觉：AI已经快要会做科学了。本章的任务是把这个错觉拆掉，给出一个尽量诚实的成熟度判断。一句话概括：当前的科研Agent处在"能力很强、可靠性很弱"的剪刀差中，而这个剪刀差，正是理解整个阶段的钥匙。

### 6.1 能力侧：已经能做什么

先说能力，它确实很能打，不该被贬低。

今天最好的科研Agent，已经能做不少事。连续调用数十个工具完成多步任务，自主运行数小时乃至更久，在受控问题上提出新颖假设并设计验证，在自驾实验室里驱动真实设备完成"提出、合成、测量、迭代"的闭环，产出格式完整、偶尔能通过评审的论文草稿。第1.1节的Virtual Lab产出了经实验证实的新分子，A-Lab在短时间内完成了大批量材料尝试，这些都是实打实的成果，不是PPT。

更关键的是，限制科研Agent的瓶颈已经不主要是"模型不够聪明"。在企业AI的调查中，最大的挑战早已从"智能不足"转向"与现有系统的整合"。科学场景同理，把Agent接进真实的数据库、设备、工作流，比让它"更会推理"更难。这里要做一个认知校正，我们面对的技术已经不笨了，它很聪明，只是还不可靠。

### 6.2 复合失败：长链条的算术

可靠性问题的第一个、也是最根本的来源，是一个简单的算术：误差会沿链条累积。

设想一个端到端科研Agent，要走完十步才能完成一项研究。即便它每一步的可靠性高达85%，十步全对的概率也只有0.85的十次方，约20%。也就是说，一个"单步表现优秀"的系统，端到端成功率可能低到只有两成。步骤越长，复合失败越严重。这解释了一个普遍现象，科研Agent在单点任务的demo上光鲜，一旦串成完整研究流程就频频崩溃。

这个算术对AI4S尤其致命，因为科学研究天然是长链条的，一个发现往往需要假设、设计、执行、分析、验证十几乃至几十步。而且科学的链条常常不可"撤销"，实验耗材烧掉了就是烧掉了，错误的中间结论会污染后续所有推断。第3.3节强调自驾实验室"闭环可靠性是瓶颈"，根源正在于此。

业界对这个问题的清醒认识，体现在大量"可靠执行"基础设施的兴起，让Agent在中途崩溃后能知道哪些步骤成功、从断点续跑而不必重来。但在科学场景，"续跑"还算容易，真正难的是判断哪一步的科学结论错了，这恰恰需要第四章说的评估能力。

### 6.3 可复现危机：科学命根子遇上非确定性

可靠性问题的第二个来源，触及科学的命根子，可复现性。

科学的可信度建立在"他人能重复你的结果"之上。但这件事在AI之前就已经岌岌可危。2016年《自然》一项覆盖1576名研究者调查显示，超过七成的人无法复现别人的实验，超过一半的人连自己过去的结果都重复不出来。这是科学界长期的结构性问题。

AI自动科研把这个问题放大了。一方面，大模型是非确定性的，同样的输入，两次运行可能给出不同的过程乃至结论，这与"可复现"的科学要求天然冲突。另一方面，AI让"生产看似合理的结果"变得极其廉价，一个系统可以快速产出一份格式完整、引用齐全、读起来无懈可击的分析，但其中的关键步骤可能根本经不起复现。当"生成"远快于"验证"，科学的质量控制机制就会被压垮。

这正是第3.4节"能复现恰恰暴露难复现"的深层含义。在AI时代，可复现已经不是一个能默认的背景条件了，它变成了一个需要专门建设的能力，这把可复现基础设施（第四章）从"锦上添花"变成了"刚需"。

### 6.4 评估缺口：demo 与落地之间的鸿沟

可靠性问题的第三个来源，是我们还缺乏可信的尺子去衡量这些系统到底行不行。

这就是第四章反复强调的评估缺口。它有两层含义。第一层，基准与真实表现之间存在系统性落差，一个系统在某个某个静态基准上表现亮眼，不代表它在真实、动态、开放的科研环境里同样可靠。第二层，科学领域的专业评估本身严重不足，多个科学基准上最强模型的得分都远未达到专家水平（如ReplicationBench上复现得分很低），而绝大多数学科、子领域、任务类型甚至还没有自己的基准。

评估缺口的后果是直接的。在没有可信尺子的情况下，企业和实验室不敢把真实、重要的研究交给Agent。这也是为什么"demo惊艳、落地掉链子"会成为常态，问题不在于系统在demo里造假，而在于demo的环境与真实科研的环境之间，隔着一道还没有人用可信评估填平的鸿沟。在更广的AI工程领域，已有观察指出，评估与可观测性是整个基础设施栈里资金最不足、却最关乎落地的一类。科学领域的这块尺子，更是几乎空白。

### 6.5 自治的幻觉：新颖却不可行、表层评审、满意度悖论

把前面几条放进具体证据里，会看到一幅关于"自治幻觉"的清醒图景，系统在形式上逼近科学家，在实质上仍有显著差距。

**其一，假设的"新颖却不可行"偏差。** 第3.2节提到的Si et al.（2024）对照研究发现，LLM生成的想法新颖性高于专家、但可行性更弱。这意味着把研究方向完全交给AI，可能得到一堆新奇却走不通的提议，而判断"哪个值得做"的能力，正是科学品味的核心，目前仍牢牢握在人类手里。

**其二，评审的表层化。** 对Sakana AI Scientist的独立评估（arXiv 2502.14297）发现，AI生成的评审往往格式工整却停留在表层，抓不到深层方法缺陷。而AI写论文和AI评论文正在同时入场，据估计，ICLR 2026约两成的同行评审已经完全由AI生成。于是就有了一个让人不安的"闭环"，AI写、AI审，真正的质量判断却悬在半空。

**其三，满意度的悖论。** 有一项常被引用的研究（MIT对某大型研发实验室上千名科学家的追踪）发现，AI辅助大幅提升了产出，却有约八成的人报告工作满意度反而下降，因为AI接管了最有创造性的那部分。要提醒的是，这只是单个实验室的样本，且该研究后来卷入了数据真实性的争议，不宜过度外推。但它点到的问题是真的，当AI能在关键研究任务上逼近甚至超过人类，"人类科学家还剩下什么"就成了一个会影响采纳意愿的真实张力，这也呼应了科学界对AI又用又怕的复杂态度。

**其四，研究诚信的反噬。** AI生成内容的泛滥正在冲击学术生态。AI生成综述大量涌现，以至于arXiv在2025年底收紧了计算机方向综述类文章的投稿。隐藏提示词操纵AI评审等新型学术不端也开始出现。这些都说明，科研Agent的能力跑得很快，治理与诚信的护栏却远未跟上。

![自治幻觉](https://gastigado.cnies.org/d/public/img_12.png)

### 6.6 一个诚实的成熟度坐标

综合本章，给一个尽量持平的成熟度判断，作为上篇的核心结论。

* **能力维度：高。** 推理、规划、工具调用、实验闭环都已跨过可用门槛，瓶颈不再主要是"聪明程度"。
* **可靠性维度：低。** 复合失败、可复现危机、评估缺口共同压低了端到端的真实成功率，"demo惊艳、落地掉链子"是常态而非例外。
* **真实新发现维度：早期。** 在受控窄问题上有亮点，但"AI自主产出重要新科学"的硬证据仍然稀薄，多数成果离不开人类的深度介入与把关。
* **阶段定性：从"证明可行"转向"证明可靠"。** 2025年回答了"能不能做出来"，2026年的真问题是"能不能可靠地、可信地、在真实环境里做"。

这个坐标对读者的实用价值在于：它告诉你机会的重心在哪。如果能力已经够强、瓶颈在可靠性与可信，那么最大的空地就不在"造更聪明的Agent"，而在"让它可靠、可复现、可评估"，也就是第四章的基础设施层，尤其是评估与可复现。这一判断会在下篇展开为具体的入场策略。

## 小结：版图已成形，但谁在为它买单？

上篇把AI for Science这件事尽量诚实地铺了一遍。先厘清什么才算科研Agent，再顺着科学家干活的六个环节、加上托底的四层基础设施，把已有的系统摆进同一张图，又按学科扫了一遍钱和热度的分布。最后给了一个不吹的判断：能力已经很强，可靠性还很弱，真正属于AI自己的新发现还谈不上。

有一件事可以确认，AI for Science的版图已经成形。它不再是一个模糊的口号，而是一个有清晰环节、清晰分层、清晰学科分布、每一块都能找到具体工作的真实领域。范式的转变也是真的，AI确实在从"读科学"走向"做科学"，哪怕"做"得还很不稳。

但版图成形只回答了它是什么，没回答它靠什么活下去。一个领域能不能从学术热闹变成站得住的产业，要看一个更现实的问题：谁在为它掏钱。资本到底进来了没有？它把这当成刚开门的新赛道，还是已经挤满人的旧赛道？又愿意为哪一层、哪一类玩家下注？而对一个有学科底子、却没有大笔资本的人来说，哪个位置才是拿长板打，而不是拿短板硬拼？

这些正是续篇要回答的。引言里埋下的"数据快被用尽"那个钩子，会在那里变成顶级资本的下注逻辑。我会用一套"看公司成立年份"的笨办法，给这个赛道做一次到底是新是旧的体检，再把它拆成两层：够不着的"造神层"，和够得着的"水电煤层"。版图已经在这儿了，下一篇，跟着投资走。

***

## 主要工作与文献索引

> 按出现顺序排列，便于回溯。完整书目信息以各原文为准。

**综述与框架：** From Automation to Autonomy（EMNLP 2025，含Awesome-LLM-Scientific-Discovery资源库）、Ren et al. 2025（arXiv 2503.24047）、Agentic AI for Scientific Discovery（arXiv 2503.08979）、Reddy & Shojaee 2024（arXiv 2412.11427）、Ramos, Collison & White 2024（Chemical Science）、From LLM Reasoning to Autonomous AI Agents（arXiv 2504.19678）、Hitchhiker's Guide to Scientific Agents 2025、Agentic Science（Wei et al. 2025）。

**端到端系统：** The AI Scientist v1（Lu et al. 2024）、v2（Yamada et al. 2025）、Kosmos（Mitchener et al. 2025）、Agent Laboratory（Schmidgall et al. 2025, arXiv 2501.04227）、AI-Researcher（Tang et al. 2025, arXiv 2505.18705）、Curie（Kon et al. 2025）、SciAgents（Ghafarollahi et al. 2024）、PiFlow（arXiv 2505.15047）、DeepScientist（Weng et al. 2025）、Carl（Autoscience Institute 2025）、AI Co-Scientist（DeepMind 2025）、Denario、AI Cosmologist、aiXiv（Zhang et al. 2025）。

**文献/假设/分析：** PaperQA2 / White 2024（arXiv 2409.13740）、LitLLM（Agarwal et al. 2024）、LitSearch（Ajith et al. 2024）、CiteME（Press et al. 2024）、ResearchArena（Kang & Xiong 2024）、SciLitLLM（Li et al. 2024）、AutoSurvey（Wang et al. 2024）、Si et al. 2024、Many Heads Are Better Than One（Su et al. 2024）、ResearchAgent（Baek et al. 2024）、Paper2Code（Seo et al. 2025）、AutoP2C（Lin et al. 2025）、MLR-Copilot（Du 2024）、AlphaEvolve（Novikov et al. 2025）。

**实验/自驾实验室：** Coscientist（Boiko et al. 2023, Nature）、A-Lab（LBNL 2023, Nature）、Virtual Lab（Swanson et al. 2024）、ChatMOF、Huang et al. 2025。

**评估/基准：** ScienceAgentBench（Chen et al. 2024）、PaperBench（Starace et al. 2025）、SciReplicate-Bench（Xiang et al. 2025）、CORE-Bench、AstaBench（2025）、AAAR-1.0、DiscoveryWorld、ScienceBoard、LAB-Bench / LABBench2、BixBench、Gravity-Bench（Koblischke et al. 2025）、ReplicationBench（Ye et al. 2025）、AstroVisBench（Joseph et al. 2026）、AstroM-Lab 1（Ting et al. 2024）、Astro-QA（Li et al. 2025）、Collider-Bench、TPBench。

**安全/诚信/评估批评：** Prioritizing Safeguarding Over Autonomy（Tang et al. 2024）、对Sakana AI Scientist的评估（arXiv 2502.14297）、LSST DESC AI/ML机会报告（arXiv 2601.14235）、天体物理RAG评估（arXiv 2507.07155）、ALeRCE text-to-SQL（arXiv 2606.18108）。

---

---
url: https://ain.hmgf.hxcn.space/ai/paperbanana-research-figures-202605.md
description: >-
  从 PaperBanana 的官方仓库、PaperVizAgent 原始实现和社区 MCP
  扩展出发，梳理论文方法图与统计图的生成流程、输出形式和实际使用边界。
---

# PaperBanana 科研绘图

论文方法图很费时间，这件事做过的人都知道。正文里一段方法说明，真要画成投稿图，往往得来回折腾：把结构拆出来，找一个合适的版式，补箭头、分组、配色、字体，还得顾公式、分辨率和 LaTeX 排版。据项目介绍，目标是将"方法论可视化"里最痛的 30 分钟压到 3 分钟。

它把这件事拆成了一个可复用流程：输入研究方法文字描述和图注，经过理解、规划、风格调整、生成，再由批评环路回修。这样一来，论文作者处理的重点会从单纯画图，转到"怎样把方法描述转换成图的生成流程"。

## 这几个仓库是什么关系

### 官方延续仓库：PaperBanana

当前更容易上手的入口是 `dwzhu-pku/PaperBanana`。项目说明直接写明：Google Research 最早开源的是 `PaperVizAgent`，这个仓库是在原始内容基础上 fork 出来并持续演进的社区主线。项目说明里也给了 Hugging Face Spaces、数据集和 Hugging Face 论文页入口，说明它现在同时承担论文演示、代码更新和对外使用入口这三件事。

这个版本的定位很清楚：做一个 reference-driven multi-agent framework，用参考图例、规划文本、风格指南和迭代修正，把原始科研内容转成投稿可用的图和图表。

### Google Research 原始仓库：PaperVizAgent

Google Research 原始仓库现在叫 `PaperVizAgent`，项目说明里直接注明"formerly PaperBanana"。这一层主要用来交代方法来源：论文标题叫 **PaperBanana: Automating Academic Illustration for AI Scientists**，而原始实现仓库后来改名为 `PaperVizAgent`。如果你在资料里同时看到两个名字，不用当成两个不同项目，它们讲的是同一条方法线。

### 社区工程化实现：llmsresearch/paperbanana

这里用的社区仓库并非官方仓库。项目说明开头就写了 disclaimer：它是一个 unofficial, community-driven open-source implementation。它的价值，在于把 PaperBanana 的思路做得更工程化，补了 CLI、Python API、MCP server、batch、PDF 输入、full-paper orchestrate、向量导出等实际工作流里很有用的部分。

后面正文里提到 MCP、`--vector-export`、`figures.tex`、Claude Code skills 等能力，都是基于这个社区实现核对出来的，不会混写成官方主仓库现成就有的功能。

## PaperBanana 解决的到底是什么问题

做论文图有两个常见痛点。

第一类是方法图。你脑子里知道模块关系，也知道数据从哪里进、从哪里出，但把它排成一张能投 NeurIPS、ICML、ACL 这类 venue 的图，中间还差很多细节：版式、箭头逻辑、颜色分组、标签文字长度、留白、说明层级。

第二类是统计图。数据本身也许已经有了，但真正发论文时，默认的 Matplotlib 风格、图例位置、字体、网格线、颜色和可读性经常还不够，最后通常还是要手调。

PaperBanana 的做法，是把这两个问题都视为"从研究内容到图形表达"的生成任务：

* 方法图看的是 source context 和 caption；
* 统计图看的是 raw data 和 visual intent；
* 中间用一套多智能体流程把内容理解、版式规划、风格调整和结果回修拆开。

这比"直接让模型生一张图"更有工程味，因为每一步都能单独看，也更容易插入人工修正。

## 输入与输出

从官方文档、官方 skill 和社区实现看，PaperBanana 至少覆盖了两条主输入链。

### 输入

#### 1. 方法图输入

方法图的标准输入是：

* 论文方法段落，或者一段更长的 methodology text；
* 图注，或者更广义一点的 communicative intent。

官方 skill 的命令就是这个形态：

```bash
python skill/run.py \
  --content "METHOD_TEXT" \
  --caption "FIGURE_CAPTION" \
  --task diagram \
  --output output.png
```

社区实现把输入扩成了文件路径形式，还支持 PDF：

```bash
paperbanana generate \
  --input method.txt \
  --caption "Overview of our framework"
```

如果输入是 PDF，还可以选页：

```bash
paperbanana generate \
  --input paper.pdf \
  --caption "Overview of our method" \
  --pdf-pages "3-8"
```

#### 2. 统计图输入

官方主仓库文档里已经把 `task_name` 写成 `diagram` 或 `plot`，官方代码里也能核对到 `matplotlib` 路线。但官方文档目前还挂着一个 TODO：`Upload code for generating statistical plots.` 这说明公开文档对 plot 支持写得还不完整。

社区实现把这条链补得更清楚：统计图输入是数据文件加意图描述。

```bash
paperbanana plot \
  --data results.csv \
  --intent "Bar chart comparing model accuracy across benchmarks"
```

### 输出

输出这件事，得分三层看。

#### 1. 最直观的输出：最终图片

这是三条实现里都能稳定核对到的：最终会得到一张 diagram 或 plot 图像。官方 skill 默认输出 PNG，社区实现则把格式扩成 `png`、`jpeg`、`webp`。

#### 2. 中间输出：规划描述、风格化描述、批评回修

这类输出不一定直接拿来投稿，但很重要。无论是官方的 Streamlit / Gradio 界面，还是社区实现的 CLI / studio / run metadata，都保留了 pipeline 中间阶段，让你知道 Retriever 找了什么参考图、Planner 生成了什么描述、Stylist 改了哪些风格点、Critic 提了哪些修订意见。

#### 3. 可编辑或可继续排版的输出

这一层要分开说：

* **Matplotlib 代码输出**：官方代码里能核对到 plot visualizer 直接提示模型"Use python matplotlib to generate a statistical plot"。社区实现也保留了这条路径。
* **Graphviz dot / SVG / PDF**：这是社区实现里明确做出来的能力。CLI 里有 `--vector-export`，支持 `none`、`svg`、`pdf`、`both`，核心代码会把 diagram IR 写成 `diagram.dot`，再尝试用 Graphviz `dot` 导出 `final_output.svg` / `final_output.pdf`。
* **TikZ**：TikZ 生成在官方主仓库和社区实现中暂未找到明确实现。

## 四类常见图怎么用

四类图放在科研写作里，本来就承担不同工作。

### Pipeline

Pipeline 图最适合讲阶段顺序和数据流向。比如训练流程、推理流程、数据预处理到后处理的整条链。

PaperBanana 很适合生成这类图，因为它的输入本身就是一段方法说明。只要原文里已经写清楚了步骤顺序和模块串联关系，Planner 就能把顺序结构翻译成图的描述，再交给后续环节处理。

### Architecture

Architecture 图更强调模块边界、组件关系和层级结构。典型场景是 encoder-decoder、multi-agent framework、memory module、tool router、数据库和服务之间的连接。

官方 skill 的示例就是 transformer architecture。对于这类图，caption 往往也很重要，因为它决定你是要画"总体结构"，还是只画"某个子系统的局部架构"。

### Workflow

Workflow 图通常比 pipeline 更偏操作过程，适合展示审批流、实验执行流、交互过程或者"用户—系统—模型—工具"的来回关系。社区实现里 `paperbanana core orchestrate` 还内置了若干图型语义标签，比如 `architecture`、`pipeline`、`training`、`inference`、`experiment`、`ablation`，这也说明它在工程上已经开始把"图到底是哪一类"显式化。

### Comparison

Comparison 图最难的一点，是信息容易堆太满。你要同时表达不同方法、不同变体、不同模型或不同设置的差异，很容易让画面又挤又乱。

从社区实现的 plot 路线看，它会让 Planner 把变量和视觉映射关系写清楚，再让 Stylist 去补颜色、字体、图例、布局。这个顺序对 comparison 图尤其有用，因为比较图最怕的是视觉编码不清：颜色、线型、marker、hatch 一乱，读者就要回头猜。

## 工作流

官方文档和原始实现都把主流程写成五个 agent：Retriever、Planner、Stylist、Visualizer、Critic。

### Retriever

Retriever 负责找参考例子。PaperBanana 会从参考图里找"结构上接近"的样本，再把这些样本交给后续环节。官方说明写得很直：这是 reference-driven。

### Planner

Planner 把方法段落和图注翻成一段详细的图形描述。它不直接出图，出"图应该长什么样"的文字说明。

### Stylist

Stylist 负责把图往投稿图的状态收，避免停留在默认示意图的水平。官方代码里能看到它会读 `NeurIPS 2025` 风格指南，补颜色、布局、字体、线条和背景这些信息。

### Visualizer

Visualizer 才是出图的环节，但方法图和统计图的实现路线不完全一样：

* **方法图**：官方主仓库更偏向 image generation model 路线；
* **统计图**：官方和社区实现都能核对到用 Python Matplotlib 生成代码再执行；
* **社区扩展**：在方法图上还补了 Graphviz IR / dot / SVG / PDF 导出链，用于更稳定的向量化输出。

### Critic

Critic 不只是打分，它会结合原始上下文和当前图像结果提出修改意见。然后 Visualizer 再按这些意见重画下一轮。这样一来，图可以继续迭代，不会停在第一版。

## 三条上手路径

### 1. 官方仓库本地跑

官方仓库推荐的本地方式是 `uv` + Python 3.12，再跑 Gradio 或 Streamlit。

```bash
git clone https://github.com/dwzhu-pku/PaperBanana.git
cd PaperBanana
uv venv
source .venv/bin/activate
uv python install 3.12
uv pip install -r requirements.txt
python app.py
```

如果你只是想试一下界面，也可以直接看它的 Hugging Face Spaces。

### 2. 官方 skill 路线

官方仓库里自带 `skill/SKILL.md`，相当于把最核心的 diagram 生成命令包装成了 Skill 入口。这个方式适合已经在用技能化工作流的人。

```bash
python skill/run.py \
  --content-file examples/sample_inputs/transformer_method.txt \
  --caption "Figure 1: Overview of the proposed transformer architecture" \
  --task diagram \
  --output architecture.png
```

要注意的一点是，官方 skill 文档里写了比较保守的耗时说明：单个 candidate 常见是 3 到 10 分钟，默认并行 10 个候选时，总耗时大约 10 到 30 分钟。这个说法比"30 分钟压到 3 分钟"更符合当前仓库已经明确写出来的实际预期。

### 3. 社区实现的 CLI / PyPI 路线

如果你更在意 CLI、批量生成、向量导出和 MCP，这条路更合适。

```bash
pip install paperbanana
```

生成方法图：

```bash
paperbanana generate \
  --input examples/sample_inputs/transformer_method.txt \
  --caption "Overview of our encoder-decoder architecture with sparse routing"
```

生成统计图：

```bash
paperbanana plot \
  --data examples/sample_inputs/results.csv \
  --intent "Bar chart comparing model accuracy across benchmarks"
```

如果你想要 Graphviz 的向量输出，可以再加：

```bash
paperbanana generate \
  --input method.txt \
  --caption "Overview of our framework" \
  --vector-export both
```

这条命令在社区实现里会尝试写出：

* `diagram.dot`
* `final_output.svg`
* `final_output.pdf`

前提是系统里能找到 Graphviz 的 `dot` 可执行文件。

## MCP 模式：Claude 对话里按需触发画图

这里要分清：**MCP server 来自社区实现，官方主仓库当前没有把它当成重点展示的入口。**

### 社区 MCP server 提供了什么

社区仓库 `mcp_server` 目录下的说明文件，明确列了工具：

* `generate_diagram`
* `generate_plot`
* `evaluate_diagram`
* `evaluate_plot`
* `download_references`
* `orchestrate_figures`
* `batch_diagrams`
* `batch_plots`

也就是说，在 Claude Code、Cursor 这类 MCP 客户端里，PaperBanana 不只是"单张图生成器"，还可以扩成整篇论文图包生成和批量任务。

### Claude Code 怎么接

社区说明文件给的是 `uvx` 路径，配置大致是：

```json
{
  "mcpServers": {
    "paperbanana": {
      "command": "uvx",
      "args": ["--from", "paperbanana[mcp]", "paperbanana-mcp"],
      "env": { "OPENAI_API_KEY": "your-openai-api-key" }
    }
  }
}
```

这样配好之后，Claude Code 里就能在对话过程中按需调用 `generate_diagram` 或 `generate_plot`。

### 社区 skill 怎么配合 MCP

社区仓库还附带了 `.claude/skills/generate-diagram` 和 `.claude/skills/generate-plot`。它们的逻辑很直接：

* `generate-diagram` 读本地方法文本文件，再调用 MCP 的 `generate_diagram`；
* `generate-plot` 会把 CSV / JSON 数据整理成 JSON 字符串，再调用 MCP 的 `generate_plot`；
* 如果 MCP 不可用，再 fallback 到 `paperbanana generate` 或 `paperbanana plot` 命令。

这种设计很适合真实工作流：你在 Claude 里不需要反复复制整段方法文本，只要给文件路径和图意图就行。

## Graphviz dot / Matplotlib / TikZ 该怎么理解

这是最容易被一句话带过去，但实际最需要拆清楚的部分。

### Graphviz dot

**核验结果：社区实现里能确认，官方主仓库当前没有把它当成主文档重点。**

社区实现里，Graphviz 这一层没有用一句"支持向量图"带过，而是给了明确链路：

* 把 diagram IR 转成 dot 源码；
* 写成 `diagram.dot`；
* 如果系统安装了 Graphviz 并且 `dot` 在 PATH 上，再导出 SVG / PDF。

这条路线的优点是：

* 向量图稳定，放大不掉分辨率；
* 结构清楚，适合 pipeline / architecture 这类框图；
* 后续进 LaTeX、补统一缩放、做版式拼图会更省心。

限制也很明显：

* 复杂美术感弱一些；
* 字体、公式、节点尺寸和边标签还得继续调；
* 不是所有图型都适合强行转成 Graphviz 框图。

### Matplotlib

**核验结果：官方代码和社区实现都能确认。**

统计图这条线，PaperBanana 走的是"生成 Matplotlib 代码，再执行"的路线，不会直接吐一张图片。这个选择很关键，因为 plot 最容易出问题的地方就是数值准确性、坐标轴、图例、label 和标注位置。代码路线至少让这些东西更可查、更可改。

对科研用户来说，Matplotlib 路线的好处很实际：

* 可以继续人工改代码；
* SVG / PDF 导出相对成熟；
* 适合和现有 Python 数据分析流程接在一起。

### TikZ

**核验结果：这次没有在已归档仓库和代码里确认到明确生成链。**

TikZ 对 LaTeX 用户当然很有吸引力，因为可编辑性最好、字体最容易和论文正文保持一致、公式排版也最自然。但无论是官方主仓库、Google Research 原始仓库，还是社区实现，都没有找到明确的 TikZ 输出实现。

所以这里必须写清楚：

* TikZ 在原始介绍中被提到；
* 当前公开仓库中，没有找到能直接生成 TikZ 的明确代码路径；
* 如果你投稿流程强依赖 TikZ，现阶段更稳的做法还是把它当后续人工改造目标，不要默认仓库已经替你打通了这条链。

## 字体、公式、Times、期刊格式、LaTeX 可编辑性：实际最常卡住的地方

Graphviz 出图最坑的是字体和公式，投 SCI 常被嫌不统一。这个问题 PaperBanana 并没有神奇消失，只是把前半段自动化了。

### 字体统一

如果你的论文正文是 Times、Times New Roman 或某个期刊模板自带字体，而图里跑出来的是另一套默认 sans-serif，成品很容易显得拼接感很重。

* 官方 plot 风格指南更偏 NeurIPS 风格，甚至能看到它推荐的是 Helvetica / Arial / DejaVu Sans 一类无衬线方向；
* 这对机器学习会议图很常见，但对部分 SCI 期刊未必合适；
* Graphviz 默认字体、Matplotlib 默认字体、LaTeX 正文字体，三者经常不一致。

### 公式与数学符号

公式是第二个高风险点。框图里一旦出现 loss、变换、符号、上下标、希腊字母，图片生成路线最容易出现：

* 符号写错；
* 上下标位置怪；
* 公式和普通标签混在一起不好看；
* 往往还得回 Illustrator、Figma 或 LaTeX 里补。

如果是 Matplotlib 生成的 plot，数学文本一般还比较可控；如果是方法图走图片生成或 Graphviz 标签，公式细节往往更需要人工复查。

### Times 和期刊模板

如果目标是 SCI、期刊封面风格或严格模板，比较稳的工作方式通常是：

1. 用 PaperBanana 做出结构和第一版视觉方案；
2. 如果社区实现能导出 SVG / PDF，就优先从向量文件改；
3. 把字体、字号、线宽、公式、图例位置回收到期刊模板要求里；
4. 再放进 LaTeX 或 Word 排版系统做最终统一。

### LaTeX 可编辑性

这件事也要分层看：

* **PNG / JPEG / WebP**：最省心，但后期可编辑性最弱；
* **SVG / PDF**：后续修版更方便，也更适合放进 LaTeX；
* **Graphviz dot / Matplotlib 代码**：还保留了结构级或代码级编辑能力；
* **TikZ**：理论上对 LaTeX 最友好，但这次没有在公开仓库里核到现成输出。

社区实现还有一个额外优势：它的 `orchestrate` 能在生成 full-paper figure package 时写出 `figures.tex` 和 `captions.md`。这不等于生成的图就自动满足期刊模板，但至少说明它开始考虑"论文整包图件如何接入 LaTeX"这个更实际的问题了。

## 什么时候值得用它，什么时候别把它想得太万能

如果你现在要处理的是下面这类任务，PaperBanana 很值得试：

* 方法段落已经写好了，但图还没成型；
* 你需要快速出几个 candidate 看结构；
* 论文里既有方法图，也有统计图，想用同一套工作流处理；
* 你在用 Claude Code / Cursor，希望把画图变成 MCP 可调用步骤；
* 你后面还愿意自己修 SVG、PDF、Matplotlib 或 LaTeX。

如果你的要求是另一类，就要保守一点：

* 期刊字体、字号、公式排版要求非常死；
* 你强依赖 TikZ 级别的可编辑性；
* 图里有大量复杂数学公式；
* 你完全不想做后期修图。

这种情况下，PaperBanana 在流程里更像第一版图形生成器和结构草稿器，还不是最终的排版终点。

## 一条更符合投稿流程的用法

下面给一个更贴近实际投稿流程的顺序：

1. 用方法段落和 caption 跑一版 diagram candidate；
2. 如果是统计图，优先走 Matplotlib 路线，把数值和映射核对清楚；
3. 对方法图，如果社区实现可用，就试一次 `--vector-export both`，看看 Graphviz 的 SVG / PDF 是否够用；
4. 把最好的一版放回论文排版环境，统一字体、公式、颜色和字号；
5. 需要整篇论文一起处理时，再考虑社区实现里的 `orchestrate`、`batch`、MCP 和 `figures.tex`。

按这个顺序用，PaperBanana 放在研究写作工具链前半段会更合适，不用把它当成"一键自动投稿图"的幻想按钮。

---

---
url: https://ain.hmgf.hxcn.space/ai/manim-explainer-video-202605.md
description: 从 Manim Community、3Blue1Brown 和官方文档出发，解释 Manim 为什么仍然适合数学解释视频，以及它和通用视频生成工具的差别。
---

# Manim 仍是数学动画首选

如果你最近看过一批 AI 解释视频，会发现一个很稳定的现象：镜头感、氛围感和转场花样确实越来越多，但一旦内容进入公式推导、几何对象变换、坐标系旋转和严格的逐步讲解，很多视频还是会回到一类更"老派"的方法——脚本驱动动画。

这也是 Manim 到现在还没过时的原因。3Blue1Brown 用它做 YouTube 数学视频，后来大量 AI 解释类视频也在借它那套视觉语言。有人说"Sora 学不来这种数学动画质感"，说的就是**控制方式不同**：通用视频生成擅长采样一段看起来合理的连续画面，Manim 擅长把每一个对象、每一帧和每一次变换都写死在脚本里。

做数学解释视频，这个差别很关键。很多时候你要的并不是"像"，而是"对"。

## ManimCommunity/manim：适合新用户的主线版本

`ManimCommunity/manim` 把自己定义成 `An animation engine for explanatory math videos`。这一版是社区维护的 `ManimCE`，从 `3b1b/manim` fork 而来。对新用户来说，社区版更省事：功能持续发展、文档更完整、社区维护也更活跃。

今天再提 Manim，得把两条线拆开看：

* **社区版 `manim`**：包名就是 `manim`，主站、文档、示例、安装说明对多数读者都更省事。
* **3Blue1Brown 自用版 `manimgl`**：包名是 `manimgl`，贴近 Grant Sanderson 自己的工作流和历史代码。

如果你的目标是尽快跑通一段数学动画，直接看社区版会省很多时间；如果你的目标是研究 3Blue1Brown 当年怎么做视频，再回头看 `3b1b/manim` 和 `3b1b/videos`。

![Manim README 截图](https://gastigado.cnies.org/d/public/manim-readme-1.png)

## 3b1b/manim：理解风格源头，别和社区版混装

`3b1b/manim` 也把自己定义成"用于解释型数学视频的精确程序化动画引擎"。它最早就是 Grant Sanderson 为 3Blue1Brown 视频做的个人项目。这里对应的是 `manimgl`，安装方式和社区版不同，不能把两边的安装说明混着用。

很多人第一次装 Manim 时卡住，常见原因是把 `pip install manim` 和 `pip install manimgl` 的资料混看了。官方已经把这件事说得很明白，照着分流走就行。

## 3b1b/videos：3Blue1Brown 的制作方式

`3b1b/videos` 是 3Blue1Brown 自己的视频代码仓库。这里放的是频道解释视频背后的场景代码，主体几乎都由 Manim 生成。不过老项目可能依赖旧版本，不一定能直接跑起来。

这个仓库的价值，不是给新手一键运行，而是让你看到一件事：数学解释视频并不是先想镜头，再找模型碰碰运气；很多时候做法就是写程序、调对象、压节奏、反复改稿。也因为这样，Manim 这种脚本工具一直有位置。

## 安装方式与文档入口

社区版给了一条很清楚的入口：

1. 如果只是想试一下，不一定要本地折腾，官方提供了在线 Jupyter 环境：<https://try.manim.community/>。
2. 如果要本地装，看安装页，再按操作系统选择对应步骤。
3. Quickstart 会带你跑第一个示例，再继续看图库和 API 文档。

对第一次接触 Manim 的人，比较实用的顺序是：

* 确认自己用的是社区版；
* 跑通一个最小示例；
* 再碰 LaTeX、3D 和更复杂的镜头控制。

不要直接去抄大项目。Manim 的学习成本不在"命令行看起来复杂"，而在于它要求你接受一个事实：你是在写动画脚本，不是在拖拽时间轴。

## 为什么它一直好用

### 1. LaTeX 公式动画

官方文档把 `MathTex` 单独列成对象类型，说明它本来就是 Manim 的核心能力之一。这个能力最实在的用途，是把公式当成可操作对象：可以逐段出现、局部变色、拆开移动、和图形同步出现。

做数学解释视频时，这比直接把一张公式图贴上去高效得多。你可以把某一项推到左边、把另一项淡出、再让辅助箭头和注释跟着走，整个过程能保持结构一致。

### 2. 几何对象变换

官方最常见的 `SquareToCircle(Scene)` 示例，核心就是 `Transform(square, circle)`。这个例子很简单，但正好说明了 Manim 的基本思路：对象先存在，再发生变化；变化可以复现，可以改参数，也可以插进更大的动画链条里。

对于几何教学、算法示意、函数图像说明，这种控制比"让模型生成一段看起来像几何变换的视频"可靠得多。你知道起点是什么，也知道终点是什么，中间怎么走由你自己决定。

### 3. 3D 空间动画

官方文档里有独立的 `ThreeDScene`。这意味着 Manim 不只是平面公式播放器，它也能处理坐标轴、曲面、旋转视角和空间关系。

这类能力适合：

* 多元函数和曲面直观展示；
* 线性代数里的向量与空间基变换；
* 物理、机器人、几何建模里需要明确视角控制的演示。

通用视频生成当然也能做出"很像 3D"的画面，但如果你要求某个坐标轴严格转到某个角度，或者要求一条曲线始终跟某个参数同步变化，Manim 这种脚本控制会稳得多。

### 4. 精确时间轴

有人说"every frame 都可控制"，这句话不夸张。Manim 的时间轴本来就是程序的一部分。对象什么时候出现、动画持续多久、哪一步先停顿、哪一句旁白该对齐哪一帧，这些都能在脚本里明确写出来。

这对讲解视频尤其重要。你做毕业答辩动画、组会解释图或者 YouTube 科普片，真正难的常常不是画面多花，而是讲解节奏不能乱。Manim 的好处是它把节奏写进了工程，不靠手感碰运气。

### 5. 脚本可版本管理

有人说"所有动画版本可 Git 管理"，也值得保留。Manim 项目本质上就是一组 Python 文件、资源文件和渲染输出。你可以正常提交、对比 diff、回退版本、开分支试不同讲法。

这对需要不断改稿的内容团队很有用。尤其是课程、答辩、讲座这类材料，一次改公式、一处换颜色、一句文案挪顺序，都能追踪，而不是像传统剪辑工程那样经常留下一堆难回溯的时间线状态。

## 它和通用视频生成的分工

很多人会把"都能做视频"当成同类替代，但 Manim 和通用视频生成在输入、控制和输出目标上是两条路。

### 通用视频生成：采样镜头

如果你用的是 Sora 这类通用视频生成工具，你通常给它的是 prompt、参考图、风格要求、镜头语气或结构提示。它擅长的是：

* 生成氛围镜头；
* 做概念短片；
* 快速给出一段视觉化表达；
* 处理写实材质、光影和连续运动。

故事感、情绪感和场景感很强的内容，通常会走这条路。

### Manim：写一个可复现的动画程序

Manim 的输入核心是对象、变换、参数和时间。你写的是：

* 哪个公式先出现；
* 哪个圆在第几秒变成方块；
* 相机怎样旋转；
* 某条曲线随着参数怎么更新；
* 最终视频以什么分辨率和质量导出。

二者的差别不只是"一个更技术，一个更简单"。更直接的差别是：

* 通用视频生成追求一段成立的画面；
* Manim 追求一段可验证、可修改、可反复渲染的动画过程。

所以很多"数学解释视频风格"看起来像被 AI 学会了，但一旦进入严密推导和对象级讲解，制作流程还是会回到 Manim 这类工具。

## 使用场景

下面三个场景都很典型。

### 毕业答辩动画

答辩里最怕的是：图表漂亮，但老师一问"这一步怎么来的"，你只能回去翻 PPT。Manim 适合把算法流程、公式演化、结构图变化做成可控动画，讲的时候更容易对齐逻辑。

### 组会概念解释

组会常常不是做宣传，而是把一个复杂概念讲清楚。比如损失函数怎么变、模型结构怎么走、几何直觉怎么建立。Manim 在这种地方比花哨转场更有用，因为它能把重点压在对象关系上。

### YouTube 科普视频

YouTube 视频对风格有要求，但长期看，频道最值钱的还是可复用工作流。Manim 一旦把模板建好，后续换主题、改公式、扩结构都会轻松很多。这也是 3Blue1Brown 一类频道能长期保持稳定视觉语言的重要原因。

## 最小入门路径

如果你想今天就开始试，可以直接沿着官方 Quickstart 走。

### 第一步：安装社区版或使用在线环境

如果你不想装本地依赖，直接试：<https://try.manim.community/>。

如果你准备本地装，看安装页：<https://docs.manim.community/en/stable/installation.html>。

### 第二步：运行官方最小示例

把下面这个示例存成 `example.py`：

```python
from manim import *


class SquareToCircle(Scene):
    def construct(self):
        circle = Circle()
        square = Square()
        square.flip(RIGHT)
        square.rotate(-3 * TAU / 8)
        circle.set_fill(PINK, opacity=0.5)

        self.play(Create(square))
        self.play(Transform(square, circle))
        self.play(FadeOut(square))
```

然后运行：

```bash
manim -p -ql example.py SquareToCircle
```

这个命令跑通，说明你的环境、渲染链路和播放器调用都基本没问题。

### 第三步：把几何对象换成公式

不要马上做大项目，先把 `Circle()` 或 `Square()` 换成 `MathTex(...)`，试一次公式出现、变色和移动。这样会更快进入 Manim 的核心场景。

### 第四步：再加 3D、镜头和节奏

等你确认 2D 对象、公式和简单变换都顺了，再碰 `ThreeDScene`、相机运动、分镜节奏和更长脚本。这样学得更稳，也更容易判断自己究竟是需要社区版，还是要进一步研究 3b1b 自用工作流。

如果你的目标只是先出一段像样的解释视频，通用视频生成确实省事。

如果你要长期做数学讲解、课程动画或科研说明，Manim 依旧是稳妥选择：公式准确，对象关系清楚，节奏可控，后面改稿也不用从头来过。

---

---
url: https://ain.hmgf.hxcn.space/ai/model-downgrade-detection-202605.md
description: 从两篇 arXiv 论文出发，解释如何用极低成本监测 API 模型是否悄悄变化，并说明本地中文文章只是二手整理。
---

# 低成本监测 API 模型变更

来源：标题里的"1 个 Token 测出模型降级调包"，来自一篇中文二手整理，不是一手论文标题。

* 二手整理原链接：<https://mp.weixin.qq.com/s/ZelUviYX8UctyM_z_c71Yg>

核心资料是一手论文：

## 两篇相关论文

### Log Probability Tracking of LLM APIs

论文：<https://arxiv.org/abs/2512.03816>

### Token-Efficient Change Detection in LLM APIs

论文：<https://arxiv.org/abs/2602.11083>

这两篇论文讨论的是同一类问题：你通过 API 调用模型时，供应商有没有在你不知情的情况下换模型、做微调、改路由，或者让返回分布发生了足够大的变化。

这事对普通闲聊影响不一定大，但对下面这些场景影响很大：

* 自动化评测要复现结果。
* 线上 Agent 依赖固定输出风格。
* 回归测试默认"同样输入，分布不该突然变很多"。
* 安全审计希望尽早发现服务侧模型切换。

## 关注"调包"问题的原因

供应商不一定真的在做恶意"调包"，更多时候是：

* 升级了底模。
* 换了蒸馏版或更便宜的路由。
* 调了温度、拒答策略、系统模板。
* 对齐或安全层更新了。

但对调用方来说，关键不在动机，而在**你有没有办法低成本、持续地监测到变化**。

过去常见的办法有两类：

* 跑一整套评测集，比准确率和回答风格。
* 如果能拿到 logprobs，就比较输出分布。

问题是前者贵，后者又经常拿不到。两篇论文分别在这两个方向上往前推了一步。

## 第一篇论文：用 logprob 做连续监测

### 问题是什么

论文：<https://arxiv.org/abs/2512.03816>

这篇论文要解决的问题很直接：

* 很多 API 端点会变。
* 现有审计方法太贵，不适合天天跑。
* 结果是大部分模型更新都没有被持续监控。

论文的切入点是：虽然 log probabilities 本身带噪声、并不完全确定，但它们仍然能作为连续监测信号。

### 方法

论文：<https://arxiv.org/abs/2512.03816>

论文提出的是 **Log Probability Tracking**。核心思路很简单：

1. 选一组固定输入。
2. 每次只请求极少输出，甚至只取 **1 个 token**。
3. 记录这个输出 token 的平均 logprob。
4. 用统计检验比较一段时间前后的分布是否显著变化。

它的关键卖点有两个：

* 不需要生成长回答。
* 对很小的模型变化也敏感，论文说甚至能检测到"一步微调"级别的变化。

### 实验看到了什么

论文：<https://arxiv.org/abs/2512.03816>

按摘要说法，这个方法比已有方法**便宜约 1000 倍**，同时敏感度更高。论文还提出了 **TinyChange benchmark**，专门衡量审计方法在"小而真实的模型变化"面前能不能察觉。

这个实验设计很贴近现实，因为现实世界里很多变化都不是"GPT-4 突然换成另一个完全不同的模型"，而是更细的版本改动、对齐微调和服务策略调整。

### 这篇论文的结论

论文：<https://arxiv.org/abs/2512.03816>

如果 API 提供方愿意暴露 logprobs，那么低成本、连续、敏感的监测就是可行的。论文的意思也很克制：单次波动不该直接等同于调包，但即便 logprob 有随机性，它仍然足够有用，可以构成一套廉价的变化告警机制。

## 第二篇论文：黑盒条件下也想做低成本监测

### 问题是什么

论文：<https://arxiv.org/abs/2602.11083>

第二篇论文把约束又收紧了一层：

* 不能看权重。
* 不能看 logprobs。
* 只能看模型吐出来的 token。

这就是**严格黑盒**问题。很多商业 API 场景下，调用方就只拿得到最终文本输出。

### 方法

论文：<https://arxiv.org/abs/2602.11083>

论文的核心概念是 **Border Inputs**，可以理解成一类"边界输入"：

* 对这类输入，模型最可能输出的 top token 不止一个。
* 输出分布处在比较敏感的边缘地带。
* 一旦底层模型有变化，这些输入的输出结果更容易翻转或偏移。

在这个基础上，论文提出 **B3IT（Black-Box Border Input Tracking）**：

1. 找出合适的 border inputs。
2. 持续向 API 重复发送这些输入。
3. 只观察最终输出 token 的变化频率和统计分布。
4. 用统计方法判断底层是否发生了漂移。

### 实验看到了什么

论文：<https://arxiv.org/abs/2602.11083>

摘要里给出的结论有三点：

* 对非推理类端点，border inputs 比较容易找到。
* 在严格黑盒条件下，它的效果能接近最好的灰盒方法。
* 成本比现有方法再降大约 **30 倍**。

这篇论文的意义在于，它把"没有 logprobs 就做不了审计"这件事往前推了一步。虽然效果依赖输入选择，但至少证明了：**只看输出 token，本身也能形成可部署的变化检测。**

### 这篇论文的结论

论文：<https://arxiv.org/abs/2602.11083>

严格黑盒、低成本、可扩展的 API 变化检测是可能的。重点不在单次问答内容，而在一组精心挑选输入上的长期统计信号。

## 两篇论文放在一起看

它们解决的是同一问题的两种可观测条件：

| 条件 | 2512.03816 | 2602.11083 |
| --- | --- | --- |
| 能否看 logprobs | 可以 | 不可以 |
| 观测粒度 | token logprob | 输出 token |
| 核心方法 | 平均 logprob 统计检验 | border inputs + 黑盒统计检测 |
| 成本优势 | 约 1000 倍更便宜 | 约 30 倍更便宜 |
| 适用定位 | 灰盒连续审计 | 严格黑盒连续审计 |

如果你能拿到 logprobs，第一篇通常更直接，也更敏感。
如果你拿不到，只能退到第二篇的思路，用特殊输入去放大变化信号。

## 那"1 个 Token"到底是什么意思

容易误解的地方有两个。

第一，它不是说"问一句、回一个 token，就能百分之百断言被调包"。
第二，它也不是说"只靠一条样本就能下结论"。

更准确的理解是：

* 单次请求可以只取极短输出，成本非常低。
* 判断来自**很多次重复观测后的统计检验**。
* 论文追求的是"持续监测的单次成本极低"，不是"神奇的一发必中"。

所以标题党里的"1 个 Token 测出模型降级"，读成"**把每次采样的探针成本压到 1 个 token 量级，再用统计方法做连续监控**"会更接近原意。

## 这类方法能发现什么，不能发现什么

### 能发现的

* 服务端底模切换。
* 微调后输出分布变化。
* 某些对齐或系统策略更新。
* 路由改动导致的长期漂移。

### 不一定能直接解释的

* 变化到底来自底模、系统提示、采样参数，还是安全层。
* 变化对真实业务指标的影响究竟多大。
* 推理模型、强随机端点、重写层很多的服务，是否仍有同样效果。

它更像**告警器**，不是法医鉴定报告。

## 读论文之外，还要保留一点现实感

本地中文文章把这件事讲得很抓眼球，传播上没问题，但如果拿去做工程判断，还是得回到一手论文。

* 二手整理可以帮你快速知道"有这回事"。
* 能不能上线，要看你的 API 能拿到什么观测信号、成本预算多少、误报容忍度多高。

还有一个现实问题也别漏掉：就算你检测到了"模型变了"，很多商业 API 也未必承诺长期版本冻结。技术上能发现变化，不等于商务上能阻止变化。

## 落地思路

1. 确认供应商是否支持 logprobs。
2. 有 logprobs，就优先看第一篇论文的路线。
3. 没有 logprobs，再评估第二篇黑盒方法。
4. 别把单次异常当结论，要看连续统计信号。
5. 再把检测结果和你自己的业务回归集对齐。

这两篇论文的价值，不在"抓包供应商"，而在给调用方一个更现实的选择：**别等大模型服务悄悄变了几周才靠体感发现，放一个便宜的探针。**

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-researcher-blogs-202605.md
description: 从站点背景、代表文章和阅读方式出发，整理两个适合追研究脉络的 AI 科研博客。
---

# 两个值得长期追的 AI 科研博客

科研博客和 X 上的快讯流不是一类东西。快讯适合知道"最近又出了什么"，博客适合看"一个人怎么把问题想明白、怎么把材料组织起来"。如果你想追研究脉络、阅读路径和论证过程，博客更适合长期放进书签栏。

这里选的两个站点，风格差异很明显。`hellojialee.github.io` 更偏"研究训练营"：课程、工具、PyTorch 经验、组内学习建议混在一起，适合刚进入实验室或刚准备转向 AI 研究的人。`jiaxuanzou0714.github.io` 更偏"理论研究笔记"：主题集中在 mechanistic interpretability、optimization、scaling law 和 μP 相关问题，适合已经能读一些论文、想看作者如何推导和串联问题的人。

## 科研博客的价值

社交媒体的信息更新快，但结构通常很薄。你看到的是标题、截图、几句观点，真正关键的推理过程往往没有展开。科研博客的价值恰好在这里：

* 站点本身就是作者的长期目录，能看出研究兴趣怎么变化；
* 单篇文章更容易保留前提、定义、引用和推导顺序；
* 同一作者的多篇文章放在一起读，能看到问题是如何一步步收束的；
* 你可以据此建立自己的阅读顺序，不至于一直跟着信息流跑。

所以这篇不做"大神推荐榜"，只做逐站介绍：这个站从哪篇开始读，能读到什么，分别对应什么阅读阶段。

## 一、Jia's Blog：从入门、工程到科研习惯放在同一处

博客：<https://hellojialee.github.io/>

About：<https://hellojialee.github.io/about/>

Archives：<https://hellojialee.github.io/archives/>

GitHub：<https://github.com/hellojialee>

Scholar：<https://scholar.google.com/citations?user=LVAnDxwAAAAJ>

作者主页：<http://faculty.hfut.edu.cn/lijia/zh_CN/index.htm>

### 站点背景

这个站点的作者是 Dr. Jia Li（李佳）。公开 About 页写得很完整：她目前是合肥工业大学副教授，研究兴趣包括 multimodal affective computing、computer vision 和 embodied intelligence。站点本身不大，但结构很清楚，有 About、Tags、Categories、Archives 几个入口。按归档页和分类页来看，文章总量不算多，却覆盖了学习、科研、软件工具等几个很实用的维度。

这个博客最有价值的地方，在于作者把带学生、做实验、配环境、整理工具的经验都放进了同一个地方。很多学术主页只看得到论文列表，这里能看到更贴近真实训练过程的内容。

### 阅读建议

如果你是下面这几类人，这个站会很顺手：

* 刚准备进组，想知道深度学习和视觉方向该怎么起步；
* 已经开始跑 PyTorch，但经常卡在环境、训练细节、分布式配置；
* 想看一个老师会怎么把课程、工具链和科研习惯连在一起讲。

站内分类里有 `学习`、`科研`、`软件工具`，说明作者写博客时把"研究"和"做事方法"放在了一起。它适合阶段性补课，不是每天刷新一次的站点。

### 代表文章

#### 1. 深度学习、计算机视觉入门和技能经验

博客：<https://hellojialee.github.io/2023/10/12/Tutorial4DL%26CV/>

这是最适合作为入口的一篇。它像一封写给组内新同学的长邮件，把课程、工具、服务器连接、文献管理、代码助手、科研习惯都串起来了。对已经在实验室里的人来说，这篇文章的价值不只是"推荐了哪些资源"，更在于它给出了一条导师视角下的起步顺序：补公开课、搭环境、学会读文献和跑实验，然后再谈 idea。

如果你最近正处在"东西看了不少，但顺序很乱"的阶段，这篇比单独一份资源表更有用。

#### 2. Pytorch实用指南

博客：<https://hellojialee.github.io/2020/05/28/Pytorch%E5%AE%9E%E7%94%A8%E6%8C%87%E5%8D%97/>

这一篇明显偏工程。它把训练和建模里常遇到的细节问题集中整理出来，不走从零入门那条线。这类文章可以当随查手册，不必从头背到尾；写模型、改 loss、看梯度、排查奇怪行为时回来翻，会很顺手。

很多研究博客只讲思路，不讲代码层的手感；这篇刚好补了那一块。

#### 3. 一个 Pytorch 训练实践 (分布式训练+半精度or混合精度训练)

博客：<https://hellojialee.github.io/2020/01/27/%E4%B8%80%E4%B8%AA%20Pytorch%20%E8%AE%AD%E7%BB%83%E5%AE%9E%E8%B7%B5%20%EF%BC%88%E5%88%86%E5%B8%83%E5%BC%8F%E8%AE%AD%E7%BB%83%20%2B%20%E5%8D%8A%E7%B2%BE%E5%BA%A6_%E6%B7%B7%E5%90%88%E7%B2%BE%E5%BA%A6%E8%AE%AD%E7%BB%83%EF%BC%89/>

这篇能看出作者是按真实实验流程在写：单卡、多卡、分布式训练、Apex、混合精度，一路往前推。它很适合给"已经能跑单机脚本，准备把实验正式搬到服务器"的读者看。

如果你只收藏一篇实践向文章，我会优先留这篇，因为它离"研究中的工程现实"更近。

#### 4. 多模态数据预处理速通

博客：<https://hellojialee.github.io/2023/10/11/Tutorial4A%26T/>

这篇根据归档页标题和站点整体主题保留。它和作者在 About 页写明的 multimodal affective computing 方向直接相关。对做多模态任务的人来说，数据预处理往往比模型结构更早决定项目能不能推进；所以即便你暂时还没切到这个方向，也值得记住这篇入口。

### 读完之后你会得到什么

这个站可以当成"研究训练营资料夹"。你不一定会连续追更，但很适合在几个节点反复回来：刚入门时看起步顺序，开始跑实验时看 PyTorch 和训练实践，转向多模态时再看相关内容。它给人的帮助很具体，主要集中在"研究是怎么做起来的"。

## 二、Jiaxuan's Blog：把理论问题拆开，再一篇篇接回去

博客：<https://jiaxuanzou0714.github.io/>

Blog：<https://jiaxuanzou0714.github.io/blog/>

Publications：<https://jiaxuanzou0714.github.io/publications/>

官网：<https://jiaxuanzou0714.github.io/autobiography/>

### 站点背景

这个站点作者是 Jiaxuan Zou（邹嘉轩）。公开主页写得很直接：他是西安交通大学数学与统计专业本科生，同时在中国人民大学高瓴人工智能学院做研究实习。研究重点放在 mechanistic interpretability、deep learning theory、optimization 和 scaling laws。

和前一个博客相比，这个站点的主题收得更窄。首页和博客页都在强调 long-form notes，标签也集中在 `optimizer`、`muP`、`tensor-programs`、`feature-learning`、`deep-learning` 这些关键词上。核心内容始终围绕几个问题持续展开。

### 阅读建议

如果你已经能接受下面这些阅读场景，这个站点会更对路：

* 想知道一篇理论笔记是怎么从问题、定义、推导一路写到参考文献的；
* 对 μP、Tensor Programs、优化器、scaling law 这类问题有明确兴趣；
* 不满足于只看论文摘要，想看作者怎么把几篇论文重新组织成自己的理解。

它不适合作为"每天刷一篇"的轻量博客，可以把它当成一套逐步扩写的研究笔记库。读的时候最好顺着站内已有导航走，不要随机点开。

### 代表文章

#### 1. μP Map

博客：<https://jiaxuanzou0714.github.io/blog/2026/mup-map/>

如果你第一次进这个站，可以从这篇开始。它本身就是一篇导航文，把 μP 相关博客整理成几条阅读路线：背景问题、Tensor Programs 路线、球面动力学路线、Hyperball 扩展和范数估计补充。好的地方在于，它不只列链接，还解释每篇在整条链里解决什么问题。

这类文章最能看出作者是不是在长期经营同一个问题。从这篇可以明显看出，作者在维护一个逐步成形的专题目录，不是零散地记几篇笔记。

#### 2. 在 LLM 语境下，梯度里的噪声会如何影响 training dynamics？

博客：<https://jiaxuanzou0714.github.io/blog/2026/llm-gradient-noise-training-dynamics/>

这一篇很能代表他的写法：立问题、给数学建模、往下推导，再补数值验证和参考文献。你即便暂时不关心归一化优化器，也能看出作者是在用博客承接研究表达，不是随手摘几段观点。

对想练习"怎么把一篇论文问题重新讲一遍"的读者，这篇很值得细看。

#### 3. 并行性与表达能力的权衡：从 $AC^0$/$TC^0$ 到 Linear Attention 的理论边界

博客：<https://jiaxuanzou0714.github.io/blog/2026/parallel-expressiveness-tradeoff-linear-attention/>

这篇很适合看作者怎么处理跨主题问题：Transformer、CoT、linear attention、电路复杂度，原本是几条不短的线，他把它们收进同一个论证框架里，最后落到"并行性与表达能力的 trade-off"上。

如果你对理论文章常见的写法还不熟，这篇可以当范例：它把问题拆开，再把结论一层层接回去，没有故作玄虚。

#### 4. Tensor Programs (二)：从Tensor Programs到 μP

博客：<https://jiaxuanzou0714.github.io/blog/2026/tensor-programs-mup-intuition/>

这一篇适合已经读过一些 μP 相关文章的人。它把 Tensor Programs、LLN、CLT 和学习率缩放的关系拆得很细，也顺手告诉读者哪篇该先读。这个博客有个很实用的特点：作者很愿意写"阅读顺序"，不会默认读者已经知道上下文。

对长期追博客的人来说，这种自带索引感的写法很省时间。

### 读这个站时该有的预期

这个站点不适合当新闻源。更新一篇的成本明显更高，所以你更应该把它当作"专题进展记录"。一旦它更新了，往往值得完整读完；但它不会替你覆盖整个 AI 研究面。它适合的是少量、深读、做笔记。

## 怎么把这类博客真正用起来

只收藏链接还不够，最好配一套稳定的阅读方式：

1. **用 RSS 或浏览器书签文件夹订阅**：这样你不会被社交平台算法决定看到什么。
2. **按主题记笔记，不按日期记笔记**：比如单独建 `优化`、`μP`、`多模态预处理` 这些页，把不同博客的文章放进同一个主题下。
3. **把代表文章和论文管理工具连起来**：如果文章里引用了 arXiv、会议论文或作者自己的论文，顺手存进 Zotero、Paperpile 或你在用的文献管理器。
4. **保留一层自己的阅读备注**：哪怕只写三句话，记下"这篇解决什么问题、我没看懂哪一段、下次该接着看什么"，以后回访会轻松很多。

## 放进收藏夹之后

这类博客适合长期跟，不适合当每日新闻源。你从它们得到的，更多是"某个人在一段时间里持续追一个问题时，会留下什么样的思考轨迹"，而不是当天的信息流。

如果你正想从信息流里退一步，换一种更稳的输入方式，这两个站可以先放进收藏夹。一个帮你把研究训练的地基铺平，一个帮你看清理论问题是怎么被拆开再重组的。

---

---
url: https://ain.hmgf.hxcn.space/ai/awesome-github-repos-for-ai-builders-202605.md
description: 把 40 个常被反复转发的 GitHub 仓库按学习、工程、AI 应用和 Agent 自动化四组重新整理，方便按用途阅读和收藏。
---

# 40 个 AI Builder 值得存的 GitHub 仓库

下面按阅读顺序拆成 4 组：学习与基础、开发者工具和工程能力、AI 应用搭建、Agent / RAG / 自动化。

这篇不是星标榜，也不是"装了就能变强"的速查表。把它当成工作台上的入口会更实用：有的仓库拿来补基础，有的拿来查工程细节，有的可以直接用来搭 AI 应用。

## 额外入口：awesome-llm-apps

### awesome-llm-apps

这个仓库不在 40 个正式名单里，但很适合作为补充目录看。等你把本文 4 组仓库读完，再回头刷 `awesome-llm-apps`，会更容易判断哪些项目值得继续跟。

## 第一组：学习与基础

这一组解决的是"把底子补齐"。如果你现在看 AI、Agent、RAG 项目容易眼花，大概率是因为还缺一套稳定的基础阅读顺序。这里的仓库适合收藏，后面慢慢啃。

### freeCodeCamp

文档：<https://contribute.freecodecamp.org>

一句话说明：开源课程平台本体和课程仓库，适合拿来补编程、数学和计算机基础。

`freeCodeCamp` 和导航清单里常见的仓库不太一样。它给的是完整课程和练习体系。你如果走自学路线，或者正想借 AI 编程把基础短板补回来，这个仓库可以排得靠前一些。它最有用的地方，是能持续给你训练量，不只是塞几篇概览文章。

### free-programming-books

官网：<https://ebookfoundation.github.io/free-programming-books/>

一句话说明：免费编程书籍与学习资源索引，适合按语言、领域和语种找长期材料。

很多人缺的往往是成体系的阅读资料。`free-programming-books` 的好处是把免费书、讲义、在线教程按主题收得很全。你如果已经知道自己要补哪一块，比如 Python、操作系统、数据库、机器学习，就可以直接从这里开分支，不用再到处找零散博客。

### developer-roadmap

官网：<https://roadmap.sh>

一句话说明：把前端、后端、DevOps、AI 等方向拆成可视化学习路线。

这类路线图仓库的价值，在于帮你确认"下一步学什么"。当你刚从零散视频、碎片化教程里出来，很容易高估自己已经会的东西。`developer-roadmap` 适合拿来做自查：哪些概念你只是听过，哪些已经真的做过。

### coding-interview-university

一句话说明：一套非常硬核的计算机基础补课清单，覆盖数据结构、算法、系统和面试准备。

虽然名字里有 interview，但这个仓库不只适合面试。对很多靠 AI 编程快速入门的人来说，它可以当一份"反向补课大纲"。你在真实开发里碰到性能、复杂度、并发、缓存、索引这些问题时，会发现这里的内容迟早要补。

### system-design-primer

一句话说明：大型系统设计入门与面试资料库，适合建立分布式系统直觉。

如果你开始做带后端、数据库、队列、缓存的 AI 应用，这个仓库会比很多"怎么快速搭一个 demo"更有长期价值。它不直接替你写项目，但会让你知道为什么某些架构在数据量一上来就会出问题。

### project-based-learning

一句话说明：按项目练手的教程索引，适合把知识点变成可跑作品。

很多路线图仓库的问题是看着很全，但不落地。`project-based-learning` 正好补这个缺口：它把学习转成项目。你学完一段基础后，最需要的往往是做一个真的能跑、能部署、能调试的小东西。

### build-your-own-x

官网：<https://codecrafters.io>

一句话说明：通过"自己重做一遍"常见技术来理解原理，比如数据库、语言、网络工具和解释器。

这个仓库适合已经过了"完全入门"阶段的人。它最大的价值，在于让你知道别人家的工具为什么会这样设计。对 AI Builder 来说，这能显著改善你写提示词和读源码时的判断力，因为你不再只看表面 API。

### you-dont-know-js

一句话说明：JavaScript 进阶阅读材料，适合把"会写"推进到"真懂运行机制"。

如果你常写前端、Node.js、浏览器自动化或脚本工具，这一套书很有必要。很多 AI 生成的 JS 代码表面没问题，但作用域、闭包、异步、this 绑定这些坑，模型和人都容易掉进去。`You-Dont-Know-JS` 值得长期放书单里。

### javascript-algorithms

一句话说明：用 JavaScript 实现常见算法与数据结构，并配上解释和延伸阅读。

这类仓库适合和 `coding-interview-university` 搭配着看。前者偏纲领，后者更偏代码层面的手感。你如果正在用 JS / TS 搭 Agent 工具链、网页应用或脚本服务，拿 JS 语境补算法会更顺。

### tech-interview-handbook

官网：<https://www.techinterviewhandbook.org>

一句话说明：面向工程师的系统化面试准备资料，也适合回头检查基础短板。

这个仓库比很多"刷题仓库"更实用的地方，在于它把行为面、系统设计、编码、简历等内容一起收了。你不一定是为了面试读它，但如果你想知道自己哪些基础知识只是"能聊两句"，哪些是真的可用，它很有参考价值。

## 第二组：开发者工具和工程能力

这一组不直接教你做 AI 应用，但会决定你做出来的东西是不是经得起日常开发。它们处理的是 API、命令行、模板、忽略规则、自托管、资料索引这些工程细活。

### public-apis

官网：<https://APILayer.com/?utm_source=Github&utm_medium=Referral&utm_campaign=Public-apis-repo>

一句话说明：免费 API 索引目录，适合给原型项目找公开数据源。

很多 AI Builder 的第一个可运行项目，卡点往往不在模型，而在没有数据和外部服务可接。`public-apis` 的价值就在这里：天气、地图、翻译、金融、媒体、教育、文本处理，你能很快找到可用入口。做 demo、做教学项目、做概念验证都很方便。

### the-art-of-command-line

一句话说明：命令行速查手册，适合补终端、脚本和日常操作细节。

一旦你开始频繁用 Claude Code、Codex、aider 这类 CLI 工具，就会发现命令行能力直接影响效率。这个仓库的价值不在于系统教学，而在于给你一页纸式的密集提醒：怎么组合命令、怎么处理文件、怎么过滤输出、怎么少走重复步骤。

### the-book-of-secret-knowledge

一句话说明：大量 cheatsheet、脚本、工具、文章和操作技巧的聚合仓库。

这类仓库适合当"灵感和补丁库"。你平时不一定会系统读完，但遇到某个具体问题，比如要找 Linux 命令、渗透测试资料、网络排障技巧、脚本片段时，它经常能比搜索引擎更快给你方向。

### 30-seconds-of-code

官网：<https://30secondsofcode.org/>

一句话说明：短小代码片段与开发技巧集合，适合快速补手边常见写法。

如果你经常让 AI 帮你写一些小函数、小工具、小片段，`30-seconds-of-code` 可以当成对照集。它不一定教你深原理，但能让你快速确认"这段小逻辑通常怎么写才顺手"。

### gitignore

一句话说明：常见语言、框架、编辑器的 `.gitignore` 模板集合。

这是那种平时容易被忽略，但项目一乱就会想起来的重要仓库。尤其在你用 AI 快速创建新项目时，模型很容易漏掉日志、缓存、密钥、本地依赖、构建产物这些忽略规则。`gitignore` 适合拿来做基线参考。

### awesome-selfhosted

官网：<https://awesome-selfhosted.net/>

一句话说明：自托管软件总目录，适合找开源替代品和私有化部署方案。

做 AI 应用时，很多外围组件未必要自己写。认证、文件管理、知识库、面板、监控、笔记、团队协作，这个仓库经常能帮你找到可替换 SaaS 的开源方案。项目卡在某一环时，来这里查有没有现成轮子很方便。

## 第三组：AI 应用搭建

这一组开始真正进入"把 AI 应用做起来"。它们更偏本地模型、工作流编排、界面、低代码或文档处理，是很多 AI Builder 最快能用上的中层工具。

### ollama

官网：<https://ollama.com>

一句话说明：本地运行大模型的基础设施，适合快速拉起本机推理环境。

`Ollama` 常年出现在这类清单里，是因为它把"在本地跑模型"这件事做得很轻。你后面未必会长期停在本地推理，但拿它搭实验环境、演示环境或内网工具原型，门槛很低。

### open-webui

官网：<https://openwebui.com>

一句话说明：一个用户界面友好的 AI Web UI，常和 Ollama、OpenAI API 等一起使用。

如果说 `Ollama` 偏模型运行层，`Open WebUI` 就偏日常交互层。你想把模型给团队同事用，或者想快速搭个能聊天、能上传文件、能试参数的界面，这类项目比自己从零搓前端快得多。

### n8n

官网：<https://n8n.io>

一句话说明：可视化工作流自动化平台，现在也越来越多用于 AI 工作流编排。

对不想一开始就手写完整后端的人来说，`n8n` 很实用。它能把 Webhook、数据库、表单、邮件、搜索、模型调用串成一个可运行流程。很多 AI 原型项目用 `n8n` 验证，再决定要不要代码化重写。

### dify

官网：<https://dify.ai>

一句话说明：面向生产环境的 AI / Agent 工作流平台，适合做应用编排、知识库和发布。

`Dify` 的定位比聊天页面更重。到了"已经不只是想试模型，而是想把 AI 应用交给别人用"的阶段，它会更顺手。知识库、应用配置、工作流和发布路径，都被收进了同一个管理面板。

### langflow

官网：<https://www.langflow.org>

一句话说明：可视化搭建 LLM 工作流和 Agent 流程的工具，适合做图形化实验。

你如果正在摸索 RAG、Tool Calling、Agent Graph 这类结构，用 `Langflow` 的好处是可以更直观看到链路。它很适合试验阶段，也适合教学演示，因为你能一眼看出每个节点在干什么。

### markitdown

一句话说明：把 PDF、Office 文档、图片等内容转成 Markdown，方便模型进一步处理。

`MarkItDown` 放进"AI 应用搭建"这一组，是因为它经常出现在应用输入层。只要你的 AI 应用需要吃 PDF、PPT、Word、Excel，它就很可能是前处理环节的一部分。

### lobe-hub

官网：<https://lobehub.com>

一句话说明：原始名单写的是 `lobe-hub`，对应的官方项目目前更常见的是 `lobehub/lobe-chat`，适合搭建面向终端用户的 AI 交互空间。

读这个项目时，可以重点看"面向终端用户的 AI 应用能做成什么样"。它不只是一个聊天框，还把 Agent、插件、协作和生活 / 工作场景都收进同一空间里。做产品时，可以直接拿它对照界面组织、插件入口和协作形态。

### stable-diffusion-webui

一句话说明：经典的 Stable Diffusion Web 界面项目，适合本地或私有化图像生成实验。

虽然现在图像模型生态比早期更分散，但 `stable-diffusion-webui` 仍然是很多人进入本地生图工作流的起点。你如果做的是多模态产品，或者想把文生图、图生图、参数试验接进自己的工具链，这个项目仍值得了解。

## 第四组：Agent / RAG / 自动化

这一组是原始名单里最"热闹"的部分，也是最容易被写成概念堆砌的一组。读的时候不要把它们都看成"下一个万能 Agent 平台"，更有用的方式是看它们各自补哪一段链路：有的偏记忆，有的偏浏览器，有的偏多代理协作，有的偏代码编辑。

### langchain

文档：<https://docs.langchain.com/langchain/>

一句话说明：Agent 工程平台，覆盖模型调用、工具链、检索、工作流和多种上层抽象。

`LangChain` 的好处是生态广，坏处也是生态广。你不必把它当唯一标准，但如果你想理解过去几年 LLM / Agent 应用怎么抽象、怎么组合，它仍然是绕不开的一站。

### openclaw

官网：<https://openclaw.ai>

一句话说明：个人 AI 助手平台，强调跨系统、跨平台使用。

可以把它看成一套"个人 Agent 工作台"。如果你关心 Agent 怎么进入个人工作流，这类仓库值得继续跟。

### mem0

官网：<https://mem0.ai>

一句话说明：给 AI Agent 提供通用记忆层。

很多 Agent 项目演示时都很聪明，但一离开当前会话就像失忆。`mem0` 这类项目的重要性，就在于它不抢"主 Agent"位置，只专心处理记忆层。做长期助手、用户画像或多轮任务时，这类需求很快就会出现。

### browser-use

官网：<https://browser-use.com>

一句话说明：让 AI Agent 更容易访问和操作网页。

浏览器自动化一直是 Agent 场景里最有画面感的一类能力。`browser-use` 适合放在"网页能不能被模型稳定操作"这个问题下理解，而不是只看 demo 视频。它的价值在于把网站交互变成可组合能力。

### browserbase-skills

官网：<https://www.browserbase.com/SKILL.md>

一句话说明：Browserbase 官方的 Agent skills 集合，用来访问网页和自动化浏览器任务。

这个仓库比纯框架项目更贴近"拿来就用"的工作流。它适合你已经知道自己要做浏览器任务，但不想每次都从零定义动作、步骤和页面状态时参考。

### crewai

官网：<https://crewai.com>

一句话说明：多角色协作的 Agent 框架，主打角色分工与协同执行。

`CrewAI` 很适合用来理解"多 Agent 到底在拆什么"。重点不在把单模型拆成几个人设，而在把任务、责任、交接和输出格式分清楚。你如果在做研究助理、投研、内容团队这类协作任务，它很有代表性。

### autogen

文档：<https://microsoft.github.io/autogen/>

一句话说明：Microsoft 的 Agent 编程框架，强调多代理协作与可编程控制。

`AutoGen` 是另一种观察多代理框架的好样本。它和 `CrewAI`、`MetaGPT` 经常被并列提到，但各自重心不同。你读它时，可以重点看它怎么组织代理交互、状态与可扩展性。

### metagpt

官网：<https://atoms.dev/>

一句话说明：把"AI 软件公司"这个概念落到多代理框架里。

`MetaGPT` 适合拿来理解分工更细的协作结构：产品、架构、工程、测试这些角色怎样被框架化。不是每个项目都要照着它做，但把它当成"团队化 Agent 编排"的范例很有帮助。

### hermes-agent

官网：<https://hermes-agent.nousresearch.com>

一句话说明：强调会成长的 Agent，重点之一是长期记忆和持续演进。

它和本文后面关于 Hermes 的文章会互相呼应。把它放在"记忆、长会话、持续演进"这一类里看，更容易抓住定位。等你开始关心 Agent 怎么跨会话保持状态，再回头深读也不迟。

### aider

官网：<https://aider.chat/>

一句话说明：终端里的 AI 结对编程工具。

虽然 `aider` 很多人把它归到"编码助手"，但放在 Agent / 自动化组更合适，因为它直接碰工程执行：读仓库、改文件、跑命令、看 diff。你如果关心"AI 真正在代码库里怎么干活"，它非常值得了解。

### ruflo

官网：<https://cognitum.one>

一句话说明：面向 Claude 的 Agent orchestration 平台，强调多代理编排、RAG 与自动化工作流。

它代表的是偏平台层的思路：不只解决单个任务，还想承接整套多代理编排。要不要继续往下读，取决于你现在缺的是某个具体环节，还是一整个平台能力。

### agency-agents

一句话说明：把一整套 AI agency 角色做成可调用的专家集合。

从前端专家到社区增长、创意和现实校验，都被做成了可调用角色。读这个仓库时，重点放在"角色库怎么组织"会更有收获，不必把它当成通用框架。

### tradingagents

一句话说明：面向金融交易分析的多 Agent 框架。

它最大的阅读价值在于垂直场景。它提醒你：Agent 框架不一定都要做通用助手，完全可以围绕某个高约束行业去设计协作结构、信息来源和决策流程。

### maigret

文档：<https://maigret.readthedocs.io>

一句话说明：基于用户名做公开信息搜集的 OSINT 工具。

把 `Maigret` 放进这里，是因为很多 Agent / 自动化任务并不只有"生成"，还有"收集"和"核验"。这类项目适合信息收集、背景调研、用户名线索追踪，但也要格外注意合规要求和数据来源限制。

### cocoindex

官网：<https://cocoindex.io>

一句话说明：面向长时任务 Agent 的增量索引引擎。

你可以把 `CocoIndex` 理解成"给长流程 Agent 降低检索和索引成本"的基础设施。随着任务变长、代码库变大、知识库变多，这类增量索引工具的重要性会迅速上升。

### huggingface-transformers

文档：<https://huggingface.co/transformers>

一句话说明：文本、视觉、音频、多模态模型的通用模型定义与训练框架。

严格说它不属于 Agent 框架，但放在这一组是因为很多 AI Builder 最终都会回到模型层：推理、微调、评估、加载方式、模型接口。`transformers` 仍然是整个 AI 工具链里极少数必须长期追的基础项目。

## 40 个仓库的阅读顺序

如果你想把这篇文章变成自己的收藏路线，可以按下面这个顺序读：

1. **基础补课**：`freeCodeCamp`、`free-programming-books`、`developer-roadmap`、`coding-interview-university`；
2. **工程手感**：`public-apis`、`the-art-of-command-line`、`gitignore`、`awesome-selfhosted`；
3. **AI 应用原型**：`ollama`、`open-webui`、`n8n`、`dify`、`langflow`、`markitdown`；
4. **Agent / RAG / 自动化**：`langchain`、`mem0`、`browser-use`、`autogen`、`hermes-agent`、`aider`、`cocoindex`。

这样读的好处，是每一步都和下一步接得上，不会一上来就被 Agent 框架和多代理概念淹没。

## 本文覆盖的 40 个仓库清单

为便于核对，下面把 40 个仓库名完整列一遍，不改项目名：

* public-apis
* build-your-own-x
* developer-roadmap
* free-programming-books
* system-design-primer
* coding-interview-university
* the-art-of-command-line
* project-based-learning
* you-dont-know-js
* the-book-of-secret-knowledge
* tech-interview-handbook
* awesome-selfhosted
* javascript-algorithms
* 30-seconds-of-code
* gitignore
* ollama
* langchain
* n8n
* openclaw
* dify
* langflow
* mem0
* browser-use
* ruflo
* crewai
* hermes-agent
* markitdown
* maigret
* open-webui
* aider
* agency-agents
* tradingagents
* browserbase-skills
* autogen
* metagpt
* lobe-hub
* huggingface-transformers
* cocoindex
* freeCodeCamp
* stable-diffusion-webui

## 参考资料

* 原始清单与约束：`temp/ai-rewrite-checklist.md`
* awesome-llm-apps：<https://github.com/Shubhamsaboo/awesome-llm-apps>
* 本文涉及的各仓库 GitHub / 官网 / 文档链接，已归档到 `docs/ai/references/awesome-github-repos-for-ai-builders/official-links.md`

---

---
url: https://ain.hmgf.hxcn.space/ai/ebook-treasure-chest-202605.md
description: 介绍 ebook-treasure-chest 仓库和搜索页的定位、分类、格式、搜索方式，以及使用时必须注意的版权与合规问题。
---

# ebook-treasure-chest 使用说明

关于这个仓库，有几条常见说法值得核对。

`ebook-treasure-chest` 的 GitHub star 已超过 **1 万**。仓库说明里明确写了 **epub / mobi / azw3** 三种格式，也把站点描述成带实时搜索和多关键词搜索的在线页面。GitHub Pages 首页还能直接看到统计数字：**总书籍数 24,071，本地页面显示分类数量 1000**。几类数字也能对上：文学 **2711**、历史 **1748**、科普 **743**，管理 **613**、经济 **487**、推理 **531** 这些也能在页面文本里找到。

但在看 star、分类和格式之前，要确认它的定位。

## 仓库与网站的分工

### GitHub 仓库

仓库说明的中文标题就是"电子书下载宝库"。它的自我介绍写得很直白：这是一个汇聚各类电子书下载链接的地方，涵盖帆书、微信读书、京东读书、喜马拉雅等读书 App 里的大量电子书，并按标签做了简单分类。

这句话会直接影响定位，所以本文不能把它写成"电子书阅读平台"。从仓库说明看，它的核心是：

* 收集下载链接
* 做分类整理
* 提供在线搜索页
* 每条目通常给出 `epub`、`mobi`、`azw3`

可以把它理解成一个 **索引仓库 + 静态搜索页**。至于版权授权，还得回到具体作品和具体来源单独判断。

### GitHub Pages 搜索页

官网：<https://jbiaojerry.github.io/ebook-treasure-chest/>

GitHub Pages 这边更偏使用入口。首页会直接显示：

* 总书籍数
* 分类数量
* 支持语言
* 支持格式
* 搜索框

页面文案里写的是"支持搜索书名、作者、分类，可输入多个关键词（用空格分隔）"。这和仓库说明里提到的"实时快速搜索、多关键词搜索"是一致的。

从使用体验上看，站点的价值主要在于：

* 不用在超长仓库说明页里手动 `Ctrl+F`
* 能先搜关键词，再回看分类
* 能快速判断某本书是不是已经被收进索引

![ebook-treasure-chest GitHub 预览图](https://gastigado.cnies.org/d/public/github-repo-page-og.png)

## 把它当电子书索引来用更合适

从仓库说明和页面结构看，`ebook-treasure-chest` 主要解决"找书入口"和"聚合检索"这两件事。它把大量条目按标签和格式整理得很顺手，方便快速发现某本书、某类书、某个作者的集合；至于这些内容能否被合法分发，仍然要单独判断。

把它当成索引入口，它的价值很清楚；把它当成默认下载站来推广，定位就会立刻跑偏。

## 分类组织

### 分类组织

仓库说明和站点都把分类写得很密。这些大类在站点上都能找到对应入口或近似标签：

* 文学
* 历史
* 科普
* 管理
* 经济
* 职场
* 创业
* 投资
* 心理学 / 心理
* 推理
* 经典
* 技术 / 技术手册 / 计算机 / 编程

如果只看"热门分类"这一层，最醒目的还是前几个大类：

* 文学：2711
* 历史：1748
* 科普：743
* 管理：613
* 社会：558
* 推理：531
* 经典：494
* 经济：487

很多人会把它联想到技术电子书，但从当前收录结构看，文学、历史、社科、经管的量更大，技术类只是其中一部分。

### 适合怎么用分类

更实用的用法通常有两种：

1. **按主题看一遍大类**，确认这个站到底偏什么书。
2. **再用搜索做精确过滤**，不要试图从 1000 个分类里纯手动翻。

如果你想找技术手册、编程、AI、前端、数据库一类内容，直接搜索关键词通常比点分类更省时间。

## 三种格式各适合什么设备

### epub / mobi / azw3

仓库说明里明确写到，每本书通常提供三种常见格式：`epub`、`mobi`、`azw3`。这三种格式确实覆盖了比较常见的电子书阅读设备，但适配感受不完全一样。

### epub

`epub` 适合范围最广，手机、平板、很多第三方阅读器都能直接吃。你如果是：

* iPhone / iPad 用户
* Android 阅读器用户
* 平板阅读为主

多数情况下直接用 `epub` 就够了。

### mobi

`mobi` 更像 Kindle 时代留下来的老格式，现在仍然能见到，但很多场景里已经没有 `epub` 或 `azw3` 顺手。它的意义更多在于兼容旧设备和旧阅读流程。

### azw3

`azw3` 更偏 Kindle 生态，排版控制通常也更接近 Kindle 设备的阅读习惯。如果你的主设备是 Kindle，优先尝试 `azw3` 会更自然。

### 选择格式时的实际建议

* **Kindle 优先**：试 `azw3`，再看 `mobi`
* **手机 / 平板优先**：试 `epub`
* **设备很多、只想图省事**：拿 `epub` 验证阅读器兼容性

格式多并不等于质量一定一致。电子书排版、目录、封面、脚注、图片都可能有差异，真正要长期阅读时，还是得自己打开读一眼。

## 搜索页到底好不好用

### 搜索能力

官网：<https://jbiaojerry.github.io/ebook-treasure-chest/>

它更实用的地方，在于 **搜索页把超长索引变得可用**。

从仓库说明和首页文字能确认的搜索能力包括：

* 搜书名
* 搜作者
* 搜分类
* 支持多关键词
* 多关键词之间用空格分隔

这几条足够支撑"索引入口"的定位。

### 实际搜索场景

你可以这么用：

* 只知道书名的一部分：直接搜片段词
* 记得作者，不记得完整书名：搜作者
* 想扫一类书：搜"心理学""创业""Python""数据库"这类主题词
* 想做更窄的过滤：多个关键词空格组合，比如"投资 巴菲特""历史 中国"

如果你只是站在 GitHub 仓库说明页里用浏览器 `Ctrl+F`，体验会差很多。因为仓库本体更像数据目录，真正顺手的是它的 Pages 检索页。

## 版权和合规必须放在前面讲

### 版权与合规提醒

`ebook-treasure-chest` 当前公开呈现的是电子书链接索引和下载入口。对使用者来说，最重要的提醒有几条：

* 不要把"能搜到"自动理解成"可合法自由传播"
* 不要把这类索引站当成默认正版渠道
* 商业书、受版权保护作品，优先购买正版或使用官方授权平台
* 如果你所在地区、组织或设备环境对内容来源有合规要求，这类链接索引要格外谨慎

帆书、微信读书、京东读书、喜马拉雅，本身都是有各自授权体系、账号体系和平台规则的。索引页里能看到对应热门书，不等于这些条目在任何场景下都适合下载、传播、转存或二次分享。

### 更稳妥的使用方式

如果一定要用，稳妥的姿势是：

* 把它当作"确认有没有这本书"的检索入口
* 再回到正版平台、出版社、公开授权源核对获取方式
* 对公共版权作品、明确开源 / 开放授权资源，再进一步处理

这和"把它当一个免费书库随便拿"完全是两回事。本文也不建议后一种用法。

## 适用人群

如果你的目标是下面几类事，它会比较有用：

* 想快速确认某本热门中文书有没有被收录进索引
* 想按文学、历史、科普、管理、投资、心理学等主题粗筛一遍
* 想找一个比仓库说明页面更好用的电子书搜索入口
* 想确认格式里有没有 `epub` / `azw3`，再决定后面去哪读

但如果你的目标是：

* 稳定长期阅读
* 正版购买和同步
* 有声书进度同步
* 跨设备账号管理
* 合规内容分发

那它就很难成为核心终点。把它放在前面的检索环节更稳妥。

## 项目定位

`ebook-treasure-chest` 的强项，在于把一大堆中文电子书条目整理成了一个可搜索、可按分类浏览的入口，尤其 GitHub Pages 页面比直接翻仓库顺手得多。它的星标高、分类多、格式全、搜索快，这些说法大体都能核到。

定位很清楚：它适合作为 **索引入口** 和 **检索工具**，不适合被写成正规阅读平台的替代品。真要读书、存书、长期管理书库，优先正版平台、出版社渠道和明确授权来源更稳妥。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-x-platform-bloggers-202606.md
description: 按公司和领域分类整理 X 平台上最值得关注的 AI 创始人、研究者和开发者账号。
---

# X 平台上值得关注的 AI 博主

X（前 Twitter）仍然是 AI 领域最快的信息入口。论文刚挂 arXiv、产品刚上线、观点刚成型，往往先出现在这里。

这篇把值得关注的账号按公司和领域分开，方便你按自己的关注方向选择性关注。

## 一、AI 创始人与核心人物

这些账号覆盖了当前 AI 领域最核心的公司和项目创始人。

### 基础模型公司

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@sama](https://x.com/sama) | OpenAI 创始人 | OpenAI 战略方向、产品节奏 |
| [@ilyasut](https://x.com/ilyasut) | OpenAI 联合创始人 | 技术路线、研究优先级 |
| [@kevinweil](https://x.com/kevinweil) | OpenAI CPO | 产品策略、开发者生态 |
| [@darioamodei](https://x.com/darioamodei) | Anthropic 创始人 | AI 安全、模型能力边界 |
| [@gdb](https://x.com/gdb) | Anthropic 联合创始人 | 技术方向、研究进展 |
| [@demishassabis](https://x.com/demishassabis) | DeepMind 创始人 | AGI 研究、科学应用 |
| [@mustafasuleyman](https://x.com/mustafasuleyman) | DeepMind 联合创始人 | AI 产品化、社会影响 |
| [@elonmusk](https://x.com/elonmusk) | xAI 创始人 | Grok 进展、AI 哲学 |
| [@YannLeCun](https://x.com/YannLeCun) | Meta 首席 AI 科学家 | 开源模型、AI 理论 |
| [@JeffDean](https://x.com/JeffDean) | Google DeepMind AI 研究负责人 | 基础设施、研究方向 |
| [@LoganKilpatrick](https://x.com/LoganKilpatrick) | Google AI 开发者关系 | Gemini、AI Studio 更新 |

### AI 应用与工具

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@AravSrinivas](https://x.com/AravSrinivas) | Perplexity AI 创始人 | AI 搜索、信息检索 |
| [@hwchase17](https://x.com/hwchase17) | LangChain 创始人 | Agent 框架、开发者工具 |
| [@swyx](https://x.com/swyx) | Smol AI 创始人、Latent Space 主理人 | AI 工程实践、开发者体验 |
| [@levelsio](https://x.com/levelsio) | PhotoAI 创始人 | 独立开发、AI 产品商业化、一人公司 |
| [@fchollet](https://x.com/fchollet) | Keras 创始人 | 深度学习框架、AI 评估 |
| [@clementdelangue](https://x.com/clementdelangue) | Hugging Face 联合创始人 | 开源 AI 生态、模型库 |
| [@yoheinakajima](https://x.com/yoheinakajima) | BabyAGI 创始人 | Agent 架构、自主系统 |

### AI 硬件与基础设施

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@adcock\_brett](https://x.com/adcock_brett) | Figure AI 创始人 | 人形机器人、具身智能 |
| [@DrJimFan](https://x.com/DrJimFan) | NVIDIA AI 机器人负责人 | 机器人学习、仿真环境 |
| [@Aidan\_Mclau](https://x.com/Aidan_Mclau) | Modal Labs 联合创始人 | 云基础设施、GPU 服务 |

### AI 教育与投资

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@AndrewYNg](https://x.com/AndrewYNg) | DeepLearning AI 创始人 | AI 教育、课程推荐 |
| [@jeremyphoward](https://x.com/jeremyphoward) | fast.ai 创始人 | 深度学习教学、实践方法 |
| [@karpathy](https://x.com/karpathy) | OpenAI 前创始成员、Tesla AI 前负责人 | LLM 技术教程、深度分析 |
| [@rasbt](https://x.com/rasbt) | ML 教育者、《Build a Large Language Model》作者 | 机器学习实践、代码示例 |
| [@sarahguo](https://x.com/sarahguo) | Conviction 创始人 | AI 投资、创业趋势 |
| [@reidhoffman](https://x.com/reidhoffman) | Inflection AI 联合创始人 | AI 伦理、创业洞察 |
| [@natfriedman](https://x.com/natfriedman) | GitHub 前 CEO、AI 投资者 | 开发者工具、开源生态 |

### 科技公司 AI 负责人

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@satyanadella](https://x.com/satyanadella) | Microsoft CEO | AI 战略、Copilot 生态 |
| [@rowancheung](https://x.com/rowancheung) | The Rundown AI 创始人 | AI 资讯聚合、趋势分析 |

### 值得关注的新兴力量

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@vishisinghal\_](https://x.com/vishisinghal_) | AI 生产力实践者 | 实用 AI 工作流、效率技巧 |
| [@ai\_explorer25](https://x.com/ai_explorer25) | AI 女王 | AI 全领域资讯、免费资源 |

## 二、按前沿实验室分类

如果你想持续跟踪某个实验室的进展，关注这些账号比关注官方账号更高效。他们往往是产品或研究的核心贡献者，分享的内容更具体、更及时。

### Anthropic

| 账号 | 角色 | 分享内容 |
|------|------|----------|
| [@karpathy](https://x.com/karpathy) | 最近加入 Anthropic | AI 技术教程、深度分析 |
| [@bcherny](https://x.com/bcherny) | Claude Code 创建者 | Claude Code 技巧、开发经验 |
| [@trq212](https://x.com/trq212) | Claude Code 开发者 | Claude Code 使用文章、最佳实践 |

### OpenAI

| 账号 | 角色 | 分享内容 |
|------|------|----------|
| [@polynoamial](https://x.com/polynoamial) | 推理研究 | 技术细节、研究进展 |
| [@gabriel1](https://x.com/gabriel1) | Sora 开发者 | 视频生成、职业发展 |
| [@jxnlco](https://x.com/jxnlco) | 开发体验方向 | Codex 使用、开发者工具 |

### Google AI

| 账号 | 角色 | 分享内容 |
|------|------|----------|
| [@OfficialLoganK](https://x.com/OfficialLoganK) | Google Gemini & AI Studio | 产品更新、功能发布 |
| [@ammaar](https://x.com/ammaar) | 产品与设计 | AI Studio vibe-coding 案例 |
| [@fofrAI](https://x.com/fofrAI) | 生成模型应用 | 创意应用、技术实现 |

### Cursor

| 账号 | 角色 | 分享内容 |
|------|------|----------|
| [@leerob](https://x.com/leerob) | Cursor 核心声音 | 产品更新、使用技巧 |
| [@ericzakariasson](https://x.com/ericzakariasson) | Cursor 用户 | 深度使用见解、工作流 |
| [@mntruell](https://x.com/mntruell) | Cursor CEO | 重大发布、产品方向 |

### xAI

| 账号 | 角色 | 分享内容 |
|------|------|----------|
| [@milichab](https://x.com/milichab) | 最近加入 xAI | Grok 更新、产品进展 |
| [@skcd42](https://x.com/skcd42) | xAI 成员 | Grok 发布、技术细节 |

## 三、AI 实战派与独立开发者

这批账号专注于用 AI 做产品、赚钱、营销，分享实战经验和创业洞察。

### AI 产品与独立开发

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@levelsio](https://x.com/levelsio) | PhotoAI 创始人 | 独立开发、AI 产品商业化、一人公司 |
| [@marclou](https://x.com/marclou) | 初创公司 builder | AI 创业、产品增长 |
| [@jackfriks](https://x.com/jackfriks) | 个人应用 builder | AI 个人应用、产品实战 |
| [@rileybrown](https://x.com/rileybrown) | Vibecode 王 | Vibe Coding、AI 编程实战 |
| [@steipete](https://x.com/steipete) | OpenClaw 构建者 | AI 工具开发、开源项目 |

### AI 营销与变现

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@gregisenberg](https://x.com/gregisenberg) | 初创想法王 | 创业点子、产品策略、增长黑客 |
| [@eptwts](https://x.com/eptwts) | AI 赚钱推特王 | AI 变现、商业模式、被动收入 |
| [@EXM7777](https://x.com/EXM7777) | AI 运营 + 系统王 | AI 自动化、运营系统、工作流 |
| [@AmirMushich](https://x.com/AmirMushich) | AI 广告王 | AI 广告投放、营销自动化 |
| [@0xROAS](https://x.com/0xROAS) | AI UGC 王 | AI 生成内容、UGC 营销 |

### AI 提示与创意

| 账号 | 身份 | 关注点 |
|------|------|--------|
| [@godofprompt](https://x.com/godofprompt) | 提示之王 | Prompt 工程、提示词技巧 |
| [@vasuman](https://x.com/vasuman) | AI Agent 王 | AI Agent 架构、自主系统 |
| [@egeberkina](https://x.com/egeberkina) | AI 图像王 | AI 图像生成、视觉创意 |
| [@ai\_explorer25](https://x.com/ai_explorer25) | AI 女王 | AI 全领域资讯、免费资源 |

## 四、中文 AI 圈值得关注的账号

中文 AI 圈在 X 上有一批高质量创作者，覆盖资讯翻译、实战分享、独立开发和产品思考。

### AI 资讯与翻译

| 账号 | 身份 | 分享内容 |
|------|------|----------|
| [@dotey](https://x.com/dotey) | 宝玉、AI 工程师 | Prompt 工程、AI 资讯翻译、第一手行业动态 |
| [@op7418](https://x.com/op7418) | 归藏、产品设计师 | AIGC 周刊、AI 绘画/视频生成、工具趋势 |
| [@imxiaohu](https://x.com/imxiaohu) | 过气科技博主 | AI 资讯搬运、ChatGPT 使用技巧 |
| [@Gorden\_Sun](https://x.com/Gorden_Sun) | 产品经理 | AI 日报、纯 AI 信息流 |

### AI 前沿与技术

| 账号 | 身份 | 分享内容 |
|------|------|----------|
| [@oran\_ge](https://x.com/oran_ge) | 前海螺 AI PM | AI 产品思考、技术观察 |
| [@shao\_\_meng](https://x.com/shao__meng) | AI 技术爱好者 | AI 资讯、论文、开源项目和产品 |
| [@frank\_8848](https://x.com/frank_8848) | AI 创业者 | AI 教育工具、AIGC 知识库 |
| [@Tumeng05](https://x.com/Tumeng05) | TorchV AI CEO | AI / LLM / RAG / Agent / 创业 |
| [@goocarlos](https://x.com/goocarlos) | Dify AI | AI 应用开发、Dify 平台 |

### 独立开发与产品

| 账号 | 身份 | 分享内容 |
|------|------|----------|
| [@AlchainHust](https://x.com/AlchainHust) | 花叔、AI Native Coder | 独立开发、Skill 分享、用 AI 做产品 |
| [@vista8](https://x.com/vista8) | 向阳乔木、前字节 PM | AI 应用、Prompt、Vibe Coding、产品思考 |
| [@antfu7](https://x.com/antfu7) | Anthony Fu、Vue/Vite 核心开发者 | 前端、开源、工程实践 |
| [@javay\_hu](https://x.com/javay_hu) | Indie Maker Hu | Mkdirs、独立开发、出海 |
| [@thinkingjimmy](https://x.com/thinkingjimmy) | 工具产品爱好者 | AI 产品、让更多人用上 AI |
| [@Yangyixxxx](https://x.com/Yangyixxxx) | AI 增长实践者 | AI 与增长获客、AI 产品分享 |
| [@tonyzhu1984](https://x.com/tonyzhu1984) | AI 出海创业者 | AI 出海项目、创业经验 |

### 技术与开源

| 账号 | 身份 | 分享内容 |
|------|------|----------|
| [@yuxiyou](https://x.com/yuxiyou) | Vue 作者尤雨溪 | 前端框架、开源项目 |
| [@ruanyf](https://x.com/ruanyf) | 阮一峰 | 技术周刊、编程知识 |
| [@xushiwei](https://x.com/xushiwei) | 七牛云 CEO | Go 语言、云计算、创业 |
| [@HiTw93](https://x.com/HiTw93) | 妙言、Pake 作者 | 开源工具、技术分享 |
| [@OwenYoungZh](https://x.com/OwenYoungZh) | 沉浸式翻译作者 | 翻译工具、AI 应用 |

***

> 用 X 的 List 功能把账号分组，比全部关注到主页信息流更可控。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-x-platform-bloggers-list-202607.md
description: 经 Gemini、Grok、ChatGPT、Claude 四大模型交叉验证，按领域分类整理的 129 位中文 X 头部博主清单。
---

# 中文 X 各领域头部博主清单（129 位）

> 原帖来源：[@AI\_Jasonyu](https://x.com/AI_Jasonyu/status/2030166779096658161)

经过 Gemini、Grok、ChatGPT、Claude 四个顶尖大模型的深度分析与多轮交叉验证，再结合人工严格筛选和去重，整理出这份《中文 X 各领域最值得关注的头部博主清单》。

**筛选标准：**

* 粉丝量均在 5k 以上
* 推文活跃度高、热度高、粉丝互动积极
* 内容干货价值高、实战性强、深受认可（无割韭菜、无水贴）
* 每个博主仅归入最匹配的一个领域（零重复）

直接点击 Handle 一键关注即可。

## 一、AI 领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@dotey](https://x.com/dotey) | 宝玉 — Prompt 工程、AI 实战、前沿工具与模型解读 |
| 2 | [@op7418](https://x.com/op7418) | 歸藏 — AIGC 周刊主理人，AI 绘画、视频生成、设计工作流 |
| 3 | [@Gorden\_Sun](https://x.com/Gorden_Sun) | AI 资讯日报和前沿动态整理 |
| 4 | [@xiaohu](https://x.com/imxiaohu) | 小互 — ChatGPT、AI 工具导航、产品资讯 |
| 5 | [@shao\_\_meng](https://x.com/shao__meng) | AI 论文、开源项目和产品落地思考 |
| 6 | [@thinkingjimmy](https://x.com/thinkingjimmy) | AI 工具普及与产品体验 |
| 7 | [@goocarlos](https://x.com/goocarlos) | AI 开发与产品结合，开发者视角 |
| 8 | [@Tumeng05](https://x.com/Tumeng05) | AI 创业、LLM、RAG、Agent 方向 |
| 9 | [@AxtonLiu](https://x.com/AxtonLiu) | 把复杂 AI 技术讲清楚，产品开发实践 |
| 10 | [@haibun](https://x.com/haibun) | AI 视频和生成式视觉创作 |
| 11 | [@nishuang](https://x.com/nishuang) | AI 工具、生产力提升和趋势观察 |
| 12 | [@vista8](https://x.com/vista8) | 向阳乔木 — AI 产品、Vibe Coding、趋势判断 |
| 13 | [@lijigang](https://x.com/lijigang) | 李继刚 — 深度 Prompt 探索、AI 思考与方法论 |
| 14 | [@kaifulee](https://x.com/kaifulee) | 李开复 — 产业、创业和大模型趋势判断 |
| 15 | [@WaytoAGI](https://x.com/WaytoAGI) | 中文 AI 知识整理型头部账号 |
| 16 | [@xicilion](https://x.com/xicilion) | 响马 — LLM、AI 实战和开发者视角 |
| 17 | [@oran\_ge](https://x.com/oran_ge) | Orange AI — AI 创业者视角，Agent、产品机会 |
| 18 | [@AlchainHust](https://x.com/AlchainHust) | 花生 — AI 编程、AI Native 产品、工具实操 |
| 19 | [@SamuelQZQ](https://x.com/SamuelQZQ) | DN-Samuel — AI 工具、AI 认知和开发者实践 |
| 20 | [@elliotchen100](https://x.com/elliotchen100) | 艾略特 — AI 工具拆解、项目观察 |
| 21 | [@Hayami\_kiraa](https://x.com/Hayami_kiraa) | 早见 Hayami — AI Builder、内容创作与增长 |
| 22 | [@berryxia](https://x.com/berryxia) | Berryxia.AI — 创意型 AI 应用、提示词、自动化 |

## 二、创业者领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@lidangzzz](https://x.com/lidangzzz) | 立党 — 创业、投资、学习成长与人生避坑 |
| 2 | [@lxfater](https://x.com/lxfater) | 铁锤人 — AI 创业与赚钱实践 |
| 3 | [@nateleex](https://x.com/nateleex) | 李自然 — 连续创业者，创业故事与商业认知 |
| 4 | [@yan5xu](https://x.com/yan5xu) | AIGC 应用、商业化和个人经历 |
| 5 | [@santiagoyoungus](https://x.com/santiagoyoungus) | 圣总 — 海外创业者视角，普通人出海路径 |
| 6 | [@Cydiar404](https://x.com/Cydiar404) | AI 创业和产品落地 |
| 7 | [@JefferyTatsuya](https://x.com/JefferyTatsuya) | AI 创业者，产品构建与市场验证 |
| 8 | [@seclink](https://x.com/seclink) | AI 趋势、创业视角和产品运营 |
| 9 | [@Fenng](https://x.com/Fenng) | Fenng — 互联网老兵，商业评论与创业反思 |
| 10 | [@turingou](https://x.com/turingou) | 郭宇 — 连续创业者，科技与数字生活 |
| 11 | [@tinyfool](https://x.com/tinyfool) | Tinyfool — 资深技术创业者 |
| 12 | [@virushuo](https://x.com/virushuo) | 霍炬 — 科技周期和公司战略 |
| 13 | [@fankaishuoai](https://x.com/fankaishuoai) | 范凯 — 技术创业老兵 |
| 14 | [@XDash](https://x.com/XDash) | XDash — 创业洞察、工具推荐和书单 |
| 15 | [@idoubicc](https://x.com/idoubicc) | idoubi — 前工程师转独立开发与创业 |
| 16 | [@nishuang](https://x.com/nishuang) | 倪爽 — 设计与品牌创业交叉视角 |
| 17 | [@CoderJeffLee](https://x.com/CoderJeffLee) | 子木 — SaaS 海外营销、认知升级 |
| 18 | [@tuturetom](https://x.com/tuturetom) | Tom Huang — 开源 Agent 产品和创业工具链 |
| 19 | [@iamtonyzhu](https://x.com/iamtonyzhu) | Tony — 跨境和 AI 创业结合 |
| 20 | [@hongjun60](https://x.com/hongjun60) | 泓君 Jane — 科技创业和高质量访谈 |
| 21 | [@Valley101\_Qian](https://x.com/Valley101_Qian) | 陈茜 — 科技媒体与创业观察 |

## 三、SaaS 和 APP 产品领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@indie\_maker\_fox](https://x.com/indie_maker_fox) | 独立开发与出海 SaaS 路线 |
| 2 | [@HongyuanCao](https://x.com/HongyuanCao) | 出海 SaaS 和 AI 产品创业者 |
| 3 | [@nextify2024](https://x.com/nextify2024) | SaaS 开发工具、模板和产品构建 |
| 4 | [@readyfor2025](https://x.com/readyfor2025) | 连续创业者和产品经理视角 |
| 5 | [@weijunext](https://x.com/weijunext) | Next.js 和 SaaS 出海方向 |
| 6 | [@yihui\_indie](https://x.com/yihui_indie) | SaaS 独立开发与知识产品变现 |
| 7 | [@JinsFavorites](https://x.com/JinsFavorites) | SaaS 工具和 APP 产品观察 |
| 8 | [@xiongchun007](https://x.com/xiongchun007) | 数据工具与 SaaS 创业 |
| 9 | [@Junyu](https://x.com/Junyu) | 王俊煜 — 产品设计哲学和用户体验 |
| 10 | [@luoleiorg](https://x.com/luoleiorg) | 罗磊 — 全栈与体验角度看产品 |
| 11 | [@Plidezus](https://x.com/Plidezus) | 独立 APP 开发者，移动产品从零到一 |
| 12 | [@jesselaunz](https://x.com/jesselaunz) | 遁一子 — AI 产品和 Prompt 落地 |
| 13 | [@lewangx](https://x.com/lewangx) | 王乐 — AI 和硬件、产品思维 |
| 14 | [@axtonliu](https://x.com/axtonliu) | Axton — iOS/Mac 独立开发者 |
| 15 | [@tualatrix](https://x.com/tualatrix) | 图拉鼎 — 高质量 iOS 独立开发者 |
| 16 | [@luinlee](https://x.com/luinlee) | 子骅 — 工程与产品兼具，开发者工具 |
| 17 | [@yupi996](https://x.com/yupi996) | 程序员鱼皮 — AI 编程教育与产品化 |
| 18 | [@seclink](https://x.com/seclink) | Y11 — AI 工具、冷启动和求职产品化 |
| 19 | [@servasyy\_ai](https://x.com/servasyy_ai) | huangserva — 多 Agent、工具链和落地 |
| 20 | [@XiaohuiAI666](https://x.com/XiaohuiAI666) | 程序员小灰 — AI、内容和副业式产品思维 |

## 四、出海领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@gefei55](https://x.com/gefei55) | 哥飞 — 出海建站、SEO 流量和 SaaS 增长 |
| 2 | [@lyc\_zh](https://x.com/lyc_zh) | AI 出海独立开发和产品增长 |
| 3 | [@AI\_Jasonyu](https://x.com/AI_Jasonyu) | 鱼总聊AI — AI、出海、SaaS、APP 交叉领域 |
| 4 | [@JourneymanChina](https://x.com/JourneymanChina) | 出海、被动收入和海外创业路径 |
| 5 | [@dev\_afei](https://x.com/dev_afei) | 前端工程师出海探索，英推增长 |
| 6 | [@luobogooooo](https://x.com/luobogooooo) | 工具站构建和出海实战 |
| 7 | [@GoSailGlobal](https://x.com/GoSailGlobal) | AI SaaS 出海独立开发 |
| 8 | [@chuhaiqu](https://x.com/chuhaiqu) | 出海去孵化器 — 出海创业生态 |
| 9 | [@daluoseo](https://x.com/daluoseo) | 大罗 SEO — 出海 SEO 和自然流量 |

## 五、独立开发者领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@austinit](https://x.com/austinit) | 靠写代码养活自己，AI 编程和收入 |
| 2 | [@guishou\_56](https://x.com/guishou_56) | 出海独立开发和 AI 工具折腾 |
| 3 | [@9yearfish](https://x.com/9yearfish) | 产品迭代、开源贡献和独立开发 |
| 4 | [@benshandebiao](https://x.com/benshandebiao) | Build in public 和技术实战 |
| 5 | [@hwwaanng](https://x.com/hwwaanng) | iOS 独立开发和 APP 构建 |
| 6 | [@OwenYoungZh](https://x.com/OwenYoungZh) | 沉浸式翻译作者，产品与工具出海 |
| 7 | [@tualatrix](https://x.com/tualatrix) | 图拉鼎 — 开发日常、产品思考 |
| 8 | [@waylybaye](https://x.com/waylybaye) | Baye — iOS 独立开发，应用打磨 |
| 9 | [@randyloop](https://x.com/randyloop) | Randy — 活跃开源作者 |
| 10 | [@livid](https://x.com/livid) | Livid — 中文独立开发者和极客社区 |
| 11 | [@shengxj1](https://x.com/shengxj1) | 花果山大圣 — 前端讲师和独立开发者 |
| 12 | [@FinanceYF5](https://x.com/FinanceYF5) | 郎瀚威 Will — 独立开发者破冰与个人品牌 |
| 13 | [@liuyi0922](https://x.com/liuyi0922) | 61 — 高质量 iOS 应用作者 |
| 14 | [@fkysly](https://x.com/fkysly) | 马天翼 — Indie hacker 和 AI 路线 |
| 15 | [@zhixianio](https://x.com/zhixianio) | 知县 — OpenClaw、Agent、工具开发 |
| 16 | [@Pluvio9yte](https://x.com/Pluvio9yte) | 雪踏乌云 — AI 工具、自动化、增长 |

## 六、OpenClaw 领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@abskoop](https://x.com/abskoop) | OpenClaw 使用教程和 AI Agent 资源 |
| 2 | [@stark\_nico99](https://x.com/stark_nico99) | OpenClaw 教程和 Agent 工具实战 |
| 3 | [@hongming731](https://x.com/hongming731) | OpenClaw 指南、社区构建 |
| 4 | [@penny777](https://x.com/penny777) | OpenClaw 项目展示和优化 |
| 5 | [@quarktalksss](https://x.com/quarktalksss) | OpenClaw 教程与资源整理 |
| 6 | [@Khazix0918](https://x.com/Khazix0918) | AI Agent 和 OpenClaw 实践 |
| 7 | [@servasyy\_ai](https://x.com/servasyy_ai) | OpenClaw 和多 Agent 开发 |
| 8 | [@jiqizhixin](https://x.com/jiqizhixin) | 机器之心 — AI Agent 技术解读 |
| 9 | [@evilcos](https://x.com/evilcos) | 余弦 — AI Agent 安全视角 |
| 10 | [@steipete](https://x.com/steipete) | Peter Steinberger — OpenClaw 创始人 |
| 11 | [@lxfater](https://x.com/lxfater) | 铁锤人 — OpenClaw 中文传播 |
| 12 | [@Pluvio9yte](https://x.com/Pluvio9yte) | 雪踏乌云 — OpenClaw 生态整理 |
| 13 | [@fkysly](https://x.com/fkysly) | 马天翼 — OpenClaw 产品化 |

## 七、知识分享领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@kasong2048](https://x.com/kasong2048) | 知识、成长、AI 副业和咨询 |
| 2 | [@cellinlab](https://x.com/cellinlab) | AI 应用开发者与播客路线 |
| 3 | [@wshuyi](https://x.com/wshuyi) | 适合小白入门的 AI 工具和知识 |
| 4 | [@FinanceYF5](https://x.com/FinanceYF5) | 知识付费、成长和个人建设 |
| 5 | [@WaytoAGI](https://x.com/WaytoAGI) | 前沿 AI 知识库型账号 |
| 6 | [@ruanyf](https://x.com/ruanyf) | 阮一峰 — 中文互联网知识分享常青树 |
| 7 | [@Svwang1](https://x.com/Svwang1) | 王川 — 深度长推，历史、商业、科技 |
| 8 | [@sspai\_com](https://x.com/sspai_com) | 少数派 — 数字生活和高效工具 |
| 9 | [@OwenYoungZh](https://x.com/OwenYoungZh) | Owen — 外语阅读、信息获取与效率 |
| 10 | [@foxshuo](https://x.com/foxshuo) | 阑夕 — 科技资讯和商业观察 |
| 11 | [@pongba](https://x.com/pongba) | 刘未鹏 — 思维方法和认知科学 |
| 12 | [@Francis\_YAO\_](https://x.com/Francis_YAO_) | Bob Fu — 前沿研究、多模态和推理 |
| 13 | [@hongjun60](https://x.com/hongjun60) | 泓君 Jane — 高质量访谈和行业内容 |
| 14 | [@Valley101\_Qian](https://x.com/Valley101_Qian) | 陈茜 — 科技媒体和产业内容 |

## 八、副业领域

| 序号 | 博主 | 身份 / 关注点 |
|:----:|------|---------------|
| 1 | [@Astronaut\_1216](https://x.com/Astronaut_1216) | X 平台起号和 AI 工具变现实战 |
| 2 | [@ityouknows](https://x.com/ityouknows) | AI、跨境、自媒体和副业变现 |
| 3 | [@kasong2048](https://x.com/kasong2048) | AI 副业、咨询和知识变现 |
| 4 | [@JourneymanChina](https://x.com/JourneymanChina) | 出海、被动收入和副业实践 |
| 5 | [@austinit](https://x.com/austinit) | 代码养活自己和个人开发变现 |
| 6 | [@yan5xu](https://x.com/yan5xu) | AIGC 商业化和个人重整 |
| 7 | [@expatlevi](https://x.com/expatlevi) | 地理套利、出海工具和副业工具 |

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-information-sources-guide-202607.md
description: 面向大学生和研究生的 AI 信息源指南，涵盖资讯媒体、技术周刊、开源社区、学术组织和厂商导航。
---

# AI 领域优质信源及媒体推荐汇总

给大学生和研究生整理的 AI 领域信息源合集。找科研灵感、追行业动态、学实用工具，都可以从下面找到对应渠道。

## 一、信息汇总类（个人/开源项目）

这类信源由开发者或小团队维护，内容提炼度高，适合每天或每周花几分钟快速过一遍。

### 1.1 橘鸦juya / 黑鸦heya

* **橘鸦juya**：每日更新 AI 早报，覆盖国内外行业动态、模型发布、投融资、工具推荐。B 站 AI 资讯类 UP 主里更新频率和信息密度都排在前列。
  * **制作流程**：信息采集（RSS 订阅 LINUX DO、Reddit LocalLlama、X 平台）→ AI 筛选处理 → 修饰分发。流程公开透明，在知乎专栏有详细说明。
  * **内容形式**：视频版采用 NotebookLM 风格卡片设计，同时在公众号提供文字版。知乎专栏"橘鸦的AI日志"长期同步更新。
  * B站：https://space.bilibili.com/285286947
  * 公众号：橘鸦juya（文字版早报）
  * YouTube：@imjuya
  * 知乎：橘鸦的AI日志
  * 抖音：橘鸦Juya
  * RSS：https://daily.juya.uk/rss.xml
* **黑鸦heya**：橘鸦的矩阵号，简介自写"营销号&标题党，不对信息内容负责"，风格偏短视频化，用更抓眼球的方式呈现当天最重磅的 AI 新闻。
  * B站：https://space.bilibili.com/3706929260006322
* **主要平台**：微信公众号、哔哩哔哩、YouTube、知乎、抖音

### 1.2 玄离199

B 站知名科技 UP 主，B 站认证"知名科技UP主"。

* **系列栏目**："每周科技补全"已更新 95 期，每周整理视频中提到的软件和开源项目。
* **GitHub 仓库**：xuanli199/weekly 提供静态博客版和飞书版，方便收藏和搜索。
* B站合集：https://space.bilibili.com/67079745/lists?sid=3173076
* GitHub 周刊：https://github.com/xuanli199/weekly
* **主要平台**：哔哩哔哩、GitHub

## 二、技术周刊

技术周刊是低成本开拓视野、发现开源项目的途径。

### 2.1 潮流周刊

前端开发者 Tw93（汤威）维护的中文周刊，每周一期。内容涵盖前端技术、跨端开发、AI 开源项目、效率工具，也夹杂设计美学和生活思考。排版和配图在中文技术周刊里属于上乘水平。

* 官网：https://weekly.tw93.fun/
* **适合人群**：前端和全栈开发者

### 2.2 HelloGitHub

开发者"削微寒"发起的开源项目推荐，每月/每周更新，专门挑 GitHub 上有趣、门槛低的项目，附中文介绍。涵盖 C/C++、Java、Python 等多种语言，适合刚接触开源的新手。

* 官网：https://hellogithub.com/
* **平台**：官网、GitHub、微信公众号

### 2.3 阮一峰科技爱好者周刊

每周五更新的老牌中文科技周刊，是中文互联网影响力靠前的技术周刊之一。内容包括科技新闻、开发工具、开源项目、学术论文和生活见闻，作者偶尔会写对科技与社会的思考。AI 相关内容逐年增多。

* GitHub：https://github.com/ruanyf/weekly
* **平台**：GitHub、个人博客、微信公众号（常有第三方转载）

### 2.4 GitHubDaily

每天推 GitHub 上热门的开源项目，覆盖 AI/ML、前端、后端、DevOps，附中文简介。想持续发现优质开源项目的开发者可以关注。

* GitHub：https://github.com/githubdaily/githubdaily
* X(Twitter)：https://x.com/GitHub\_Daily
* 知乎：https://www.zhihu.com/people/githubdaily
* 飞书文档：https://www.feishu.cn/community/article?id=7399924133837930500
* **平台**：GitHub、X(Twitter)、知乎、飞书、微博

## 三、AI 核心媒体（"三大顶刊"）

机器之心、新智元、量子位在业界被并称为中国 AI 媒体"三大顶刊"，是追踪 AI 行业动态的三个主力信息源。

### 3.1 机器之心

2015 年 4 月成立，国内最早系统性做人工智能报道的科技媒体。旗下有三个品牌：技术内容品牌"机器之心"、产业垂直品牌"机器之能"、英文品牌"Synced Review"。

* **内容定位**：偏技术深度，覆盖前沿研究、论文解读、技术实现、行业应用、创业公司和科学家专访。机器学习、深度学习、NLP、CV、机器人、数据科学都有涉及。
* **产品与服务**：核心产品"机器之心 Pro"提供市场数据和研究报告；AI 商用搜索数据库收录全球 AI 应用实例近 3000 条；积累了超 500 个 AI 标准术语的中英对照术语库。
* **行业影响力**：2017 年起设立"Synced Machine Intelligence Awards"行业榜单；先后完成四轮融资（联想之星、星路资本、百度风投等）；Medium AI Top Writer；NeurIPS 2017 大会唯一通过官方媒体审核的中国媒体；受邀参加联合国 ITU"AI for Global Good Summit"的两家中国媒体之一（另一家为 CCTV）。
* 官网：https://www.jiqizhixin.com/
* **适合人群**：AI 研究者、技术开发者、想深入理解技术细节的从业者
* **平台**：公众号、官网、哔哩哔哩、微博、知乎、YouTube、X(Twitter)、LinkedIn

### 3.2 新智元

2015 年 9 月杨静创办，定位"智能+"中国主平台。杨静是中国人工智能学会社会计算与社会智能专业委员会秘书长，2014 年就策划主持了"奇点临近""算法帝国"等系列 AI 主题研讨会。

* **模式**：首创"社交资讯平台 + 专家智库平台 + 产业基金"的三体模式，整合产学研政投各界资源。
* **发展历程**：2016 年获天使轮投资并举办首届 AI World 世界人工智能大会；2017 年完成 Pre-A 轮融资（高瓴资本、蓝驰创投、红杉中国、字节跳动等）；2025 年发布《新智元 ASI 前沿趋势报告》并举办十周年峰会。
* **内容特点**：更新快，追踪国内外 AI 大事件的速度在同类媒体里靠前。标题风格偏冲击力，栏目有「ASI启示录」「ASI爆点」「ASI洞察」等。
* 官网：https://aiera.com.cn/
* **适合人群**：想快速了解 AI 行业热点、关注产业生态的从业者
* **平台**：公众号、视频号、官网、微博、哔哩哔哩、知乎

### 3.3 量子位

专注人工智能和前沿科技的媒体，口号"追踪 AI 行业和技术动态，这里更快一步"。创始人孟鸿是前新浪科技副主编，2016 年 11 月创立，2017 年获创新工场天使轮融资。

* **内容特点**：报道速度快、覆盖面广，技术解读写得比较通俗。图文、视频、直播都有做。
* **智库与活动**：运营量子位智库，定期发「中国 AI 100 产品」榜单；主办中国 AIGC 产业峰会和 MEET 智能未来大会（已连续举办多届，每年现场近千位行业嘉宾出席）。
* **社区运营**：微信端创建了超 5 万人的 AI 行业社群，运营 100+ 个细分方向专业主题群。
* 官网：https://www.qbitai.com/
* **适合人群**：AI 从业者、产品经理、投资人
* **平台**：公众号、官网、哔哩哔哩、微博、知乎、抖音、视频号

## 四、知名科技与商业媒体

这类媒体视野更宽，关注 AI 技术的商业落地和社会影响，以及背后的创投故事。

### 4.1 IT之家

老牌泛科技和数码资讯媒体，青岛软媒旗下。不是纯 AI 媒体，但科技巨头的 AI 硬件（AI PC、AI 手机）、大模型版本发布、软件更新跟进很快，拿泛科技快讯它排得上号。更新极其频繁（每日数十至上百篇），覆盖 IT 行业新闻、手机数码评测、智能车/电动车、AR/VR、操作系统等。AI 相关内容近年大幅增加，但整体偏消费电子和 IT 资讯向。社区氛围活跃，评论区是一大特色。

* 官网：https://www.ithome.com
* **适合人群**：泛科技爱好者、数码产品关注者
* **平台**：官网、公众号、APP、哔哩哔哩、微博、知乎、抖音

### 4.2 晚点LatePost

做深度商业报道的媒体，口号"晚一点，好一点。商业的真相总是在晚点"。

* **报道风格**：擅长写长篇深度报道、企业内幕、企业家长访谈。发文不多，但每篇信息密度高。追求"事实增量"，不复述企业对外发布的信息，而是挖掘没有对公众明说的逻辑。
* **代表作品**：《字节、阿里、腾讯 AI 大战全记录》（1.6 万字，采访近三十位内部人士）、《谁在管理大公司》系列、《还原字节跳动 HR 体系》等。
* **工作方法**：先采访再写作，一定要找到离事实最近的人。在十年维度下持续跟踪报道互联网公司，视角随时间不断深入。
* **播客**：《晚点聊 LateTalk》
* 官网：https://www.latepost.com
* **适合人群**：关注科技商业、公司战略、投资分析的从业者
* **平台**：官网、公众号、哔哩哔哩、微博、抖音、知乎、播客

### 4.3 智能涌现

36 氪旗下专注生成式 AI 和人工智能产业的垂直账号。深入报道 AI 时代下的场景落地、大模型初创公司的创业故事和投资动态。推出「涌现 36 人」等栏目，通过与业界关键人物对话记录 AI 时代的新思考。背靠 36 氪强大的采编和产业资源网络，擅长从创投、商业化角度解读 AI 趋势。报道覆盖大模型公司、AI 创业融资、AI 应用落地、Agent 生态等热点。对了解 AI 领域融资和创业动态特别有价值。曾独家报道零一万物业务分拆、六小虎融资进展等。

* **适合人群**：AI 创业者、投资人、关注商业化落地的从业者
* **平台**：公众号、36氪 App/网站

### 4.4 蓝点网

做 IT 资讯、软件更新、Windows 生态和网络安全的博客类媒体，2013 年建立。主打 Windows 生态、软件工具分享、AI 应用推荐、网络服务、系统教程与安全资讯。AI 相关内容偏"应用向"——关注 AI 工具怎么用、各平台 AI 功能更新这些实操层面的东西，不是底层技术分析。X 账号 @landiantech 偶尔发些有趣的科技观察，比如"拉黑 B 站某账号就能屏蔽开屏广告"这类实用发现。适合想了解"AI 怎么用"而非"AI 怎么做"的读者。

* 官网：https://www.landiannews.com
* **适合人群**：电脑爱好者、软件工具用户
* **平台**：官网、公众号、微博、X(Twitter)

### 4.5 赛博禅心

AI 自媒体，口号"拜 AI 古佛，修赛博禅心"。主理人笔名"大聪明"，也是知名 AI 产品及插件 WebPilot 的作者。2022 年 10 月注册，2023 年 2 月更名。

* **内容风格**：拒绝"炸裂""颠覆"这类炒作词，从论文原文逐层拆解。被称为"AI 界的大张伟"，文章通俗易懂且好玩，务求"中学生能看懂"。
* **代表作品**：《5000+ 个 AI 项目详解》（超 500 万字，5334 个 AI 项目）、《Sora 原理解读》、《保姆级教程：Coze 打工你躺平》等。
* **行业影响**：与 302.AI、ShowMeAI 联合出品「AI 行业大事记」月刊；AIGCRank 年度影响力 AI 博主 Top 10；与品玩创始人骆轶航联合播客"硅基立场"讨论 AI 行业热点。
* **适合人群**：AI 从业者、想认真思考 AI 发展方向的读者
* **平台**：公众号、播客

### 4.6 之心智能EDU

AI 教育方向的公众号，关注人工智能在教育领域（AI for Education）的融合与应用。内容涵盖教学赋能、科研工具更新、教育行业变革趋势等。偏学术教育向，聚焦 AI 技术的深度解读和前沿论文分析，涉及大模型强化学习、世界模型、多模态模型等前沿技术话题。

* **适合人群**：AI 方向研究生、算法工程师、技术深度爱好者
* **平台**：公众号

### 4.7 极客公园（GeekPark）

2010 年 6 月成立于北京的创新者社区，创始人张鹏。聚焦互联网和科技领域，通过线上内容与线下活动链接创新资源。

* **内容矩阵**：运营"极客之选"智能硬件评测、"极客现场"发布会纪实、"完全极客养成指南"专题、"产品观察"专栏等。从产品形态、用户体验角度观察 AI，对 AI 眼镜、AI 手机、AI 玩具这类消费级产品报道比较深入。
* **行业活动**：每年办极客公园创新大会（IF），李彦宏、雷军、罗永浩、张楠等科技大佬常参加。2014 年曾邀请马斯克首次来华参与极客公园创新者峰会。2013 年运营由周鸿祎、李开复等发起的创新者联盟。
* **最新动态**：2025 年发布以聚焦 AI 技术重塑行业为核心的 IF 2026 创新大会议程，并推出"中国创新力量 50（InnoForce 50）"榜单。
* 官网：https://www.geekpark.net
* **适合人群**：产品经理、创业者
* **平台**：官网、公众号、微博、哔哩哔哩、知乎、YouTube、抖音

### 4.8 AI科技评论（AItechtalk）

雷峰网旗下，偏学术方向。主要做顶会论文解读（CVPR、ACL、NeurIPS 等）、华人学者动向、高校 AI 实验室成果报道。B 站账号有 93 个合集，覆盖 OpenAI、谷歌 AI、字节跳动 AI 等方向。GAIR 大会（全球人工智能与机器人峰会）是雷峰网主办的年度行业峰会，GAIR Paper 系列邀请论文作者做深度分享。研究生可以关注。

* **适合人群**：研究生、关注学术前沿的读者
* **平台**：公众号、官方网站、B站

### 4.9 AI科技评论（通俗版）

另一个同名公众号，定位不同——把热点技术新闻翻译成大白话，零基础也能看懂。如果你身边有"AI 到底是个啥"的朋友，转发这个号给他就够了。

* **适合人群**：AI 入门者、非技术背景但想了解 AI 的读者
* **平台**：公众号

### 4.10 InfoQ（中国）

全球性在线新闻/社区网站，基于实践者驱动的社区模式建立。2007 年由霍泰稳创立 InfoQ 中国，主体为极客邦科技。面向 5 至 8 年工作经验的研发团队领导者、CTO、架构师、项目经理、工程总监和高级软件开发者等中高端技术人群。提供中立的、由技术实践主导的技术资讯及技术会议。旗下大会品牌包括 QCon 全球软件开发大会（已办近 20 年）、AICon 全球人工智能开发与应用大会、ArchSummit 全球架构师峰会、GMTC 全球大前端技术大会等。直接服务了近 20 万名中高级软件工程师和 4000+ 企业。有 AI 前线专属公众号和社群。技术采用生命周期模型分析不同技术所处阶段，是 InfoQ 内容策划的核心框架。

* 官网：https://www.infoq.cn/
* **平台**：官网、微信公众号（InfoQ 主号 + AI 前线 ai-front）、技术大会（con.infoq.cn）

### 4.11 钛媒体（TMTPost）

2012 年 9 月创立的财经科技新媒体，创始人赵何娟是资深财经媒体人。专注 TMT（科技、媒体、通信）领域，是国内首家 TMT 公司人社群媒体。

* **AI 报道**：AGI 栏目专注 AI 新浪潮，报道新模式、新产品、新趋势、应用落地和产业榜单（如 AI 应用 Top 榜）。商业和技术视角兼顾。
* **业务板块**：已形成"新媒体、全球技术专家网络、科技 IP 与创意产品服务、科技股数据服务"四大业务板块。
* **融资**：先后获民享财富、东方富海、盛大集团、京报长安等投资。
* 官网：https://www.tmtpost.com/
* **平台**：官网、微信公众号、App、视频/直播

### 4.12 DeepTech深科技

2015 年 10 月由周尔方创立（周尔方毕业于纽约大学出版研究系，曾担任纽约时报科技中文版和麻省理工科技评论的出版人）。新兴科技产业服务平台，以"构建全球创新合作网络"为使命。

* **独家合作**：麻省理工科技评论（MITTR）中文版、CB Insights、Google Kaggle、IEEE Computer、CoinDesk 在中国地区的独家合作伙伴。
* **产品与服务**：自主研发络绎知图科技要素数据库、络绎学术等产品；旗下还有专注于生命科学的品牌"生辉"。
* **覆盖领域**：AI、生物、能源、机器人等硬科技领域，提供深度报道、数据研究、学术服务。
* **融资**：先后获浅石创投、中科创星、华创资本、浙大友创等投资。每年举办 EmTech China 大会。
* **平台**：官网/微信公众号、知乎、MITTR 合作渠道

### 4.13 PaperWeekly

2016 年起步的 AI 论文学术平台，做顶会/顶刊论文的推荐、解读和讨论。在机器之心专栏有大量论文解读文章，覆盖 NLP、CV、多模态、图神经网络、强化学习等方向。常与机器之心合作。文章特点是把论文拆解成中文解读，降低阅读门槛。适合想跟踪前沿论文但时间有限的研究者和学生。

* **平台**：微信公众号、机器之心专栏、交流群

### 4.14 36氪（AI 频道）

2010 年创办的中文科技媒体，2019 年 11 月在纳斯达克上市（股票代码 KRKR），创始人刘成城成为纳斯达克史上最年轻中国上市公司董事长。

* **业务规模**：从创投媒体成长为集金融与数据于一体的科创综合服务集团，积累了超 80 万家企业库资源。创立 14 年报道了十多万家初创企业。
* **AI 报道**：旗下有"智能涌现"等 AI 垂类频道，擅长从融资、商业模式、产业落地角度解读 AI。AI 商业化和创投报道是其最大优势。
* **投资方**：蚂蚁金服、经纬中国、华泰证券、字节跳动等。
* 官网：https://www.36kr.com
* **适合人群**：AI 创业者、投资人
* **平台**：官网、公众号、APP、微博、哔哩哔哩、知乎、抖音

### 4.15 智东西

以商业报道和行研报告为核心的智能产业媒体，slogan"聚焦 AI 前沿，服务产业变革"。

* **覆盖方向**：AI 大模型、AI 芯片、具身智能/机器人、智能汽车、消费电子。
* **内容形式**：快讯和深度报道都做，旗下还有"智猩猩"等子品牌。
* **行业活动**：主办中国生成式 AI 大会（GenAICon）、全球 AI 芯片峰会（GACS）、中国具身智能机器人大会。
* 官网：https://zhidx.com
* **适合人群**：智能硬件从业者、AI 产业投资人
* **平台**：官网、公众号、微博、哔哩哔哩、知乎、抖音

### 4.16 AI科技大本营

CSDN 旗下 AI 垂直公众号（ID: rgznai100），偏技术教程和行业数据报告，更新稳定。个人简介写的是"AI科技大本营是中国专业IT社区CSDN旗下的AI垂直媒体，致力于关注并报道全球人工智能领域技术及产业方面的前沿进展"。内容覆盖面广，从论文解读到实操教程都有，适合 Developer 角色日常扫一眼。博客园有大量原创博文，涵盖 AI 工具实测、行业分析、技术解读等。

* **适合人群**：AI 开发者
* **平台**：公众号、CSDN、博客园

### 4.17 AI前线

InfoQ 旗下，专注 AI 工程化和团队管理。聊的是模型部署、MLOps、AI 团队管理这些"怎么把模型弄上生产"的话题。技术选型怎么做的、模型上线踩了什么坑，这类文章别的号少写，它经常出。也办 AI 工程化相关培训课程（如 AI Engineering Cohort for Production AI Systems），面向高级软件工程师、架构师、AI/ML 平台工程师等。文章特点是侧重一线实践与踩坑复盘，关注企业如何构建私有 Skills、制定安全护栏、搭建审计与回放机制等。

* **适合人群**：AI 工程师、技术管理者、关注 AI 落地的工程人员
* **平台**：公众号、InfoQ 网站

### 4.18 品玩（PingWest）

2012 年由资深媒体人骆轶航（原《财经周刊》驻硅谷记者）在北京创立的国际化科技媒体，理念是"Global Tech, Local Insight"。

* **发展历程**：最初以"关注全球科技动态的中文博客"定位起家，率先引入硅谷前沿视角。2016 年起将内容延伸到"科技+消费""科技+文化"领域。2018 年发力视频内容，推出"品玩 Talk"访谈节目与"品玩实验室"评测视频。
* **AI 报道**：侧重中美对比视角，对硅谷公司（OpenAI、Anthropic、Google 等）的动态跟得比较紧。
* **融资**：先后获英诺天使基金、联想之星、风云资本、挚信资本等投资。
* 官网：https://www.pingwest.com
* **适合人群**：关注国际 AI 动态、中美科技竞争的读者
* **平台**：官网、公众号、微博、YouTube、X(Twitter)

## 五、开源学习社区/机构

这些社区带有"开源、共学、公益/半公益"的共性，不卖高价课，靠开源项目、组队学习营、技术沙龙和实战打榜帮学生成长。

### 5.1 Datawhale

2018 年底在杭州成立的 AI 开源学习社区，使命是"for the learner，和学习者一起成长"。是国内首家专注 AI 领域的开源学习社区。

* **规模**：覆盖海内外 3500 多所院校，拥有数百万 AI 开发者用户。所有内容开源在 GitHub，对 C 端学习者完全免费。
* **核心项目**：《从零开始构建智能体》（62.9k star）、《从零开始构建大模型》（31.7k star）、《开源大模型食用指南》（31.1k star）、南瓜书（25.9k star）等。
* **社区活动**：每月举行免费且大规模的线上组队学习活动。公益组持续为国内偏远地区做 AI 知识公益科普。
* **用户变化**：2023 年 ChatGPT 爆火后大量工作 5 年以上的行业人才涌入，2025 年 AI Agent 和 AI Coding 成为新热门话题。
* 官网：https://www.datawhale.cn
* GitHub：https://github.com/datawhalechina
* **适合人群**：AI 学习者、高校学生
* **平台**：GitHub、公众号、官网、小红书、哔哩哔哩

### 5.2 数据派THU

清华大学大数据研究中心的数据科学公众号，致力于分享前沿数据科学与大数据技术创新研究动态，传播数据科学知识，打造数据人才聚集平台。内容偏学术和研究向，涵盖数据科学、机器学习、深度学习、强化学习、Agent 等前沿话题。定期发布技术论文解读、学术活动通知、开源工具推荐等。具有清华学术背景，内容质量稳定。同时通过微博、视频号等平台传播内容。在机器之心专栏也有文章发布。

* GitHub：https://github.com/THUDataPI/
* **适合人群**：数据科学研究者、AI 方向学生
* **平台**：GitHub、公众号、微博、视频号

### 5.3 WayToAGI（通往 AGI 之路）

前大厂产品经理 AJ（孔粤）发起的公益 AI 知识库和共学社区。自 2023 年 4 月 26 日诞生，在无推广情况下快速增长，被新浪等媒体誉为"全球最大的中文 AI 社区"。

* **知识库**：把全网分散的 AI 工具、教程、论文、案例、资讯、Prompt 模板结构化沉淀到一个飞书知识库里，被称为"AI 领域的维基百科"。汇集了上千个人工智能网站和工具，拥有 4000+ 学习资源。
* **共学活动**：经常办"DeepSeek 共学营"、"飞书多维表格 AI 共学"、"AI Agent 实战"这类短期训练营，以赛代练，鼓励动手。在多所高校建了共学分部。
* **共创项目**：孵化了 AI 春晚、离谱村等大型共创项目。品牌 VI 以彩虹色彰显多元性，以鹿的形象象征智慧（鹿与"路"谐音）。
* **合作**：已与阿里云、通义千问、智谱、支付宝、豆包、Kimi、百度等数十家公司合作。
* 官网：https://www.waytoagi.com（免费飞书知识库）
* **适合人群**：对大模型、AGI、AI 应用感兴趣的人，零基础或从业者都能找到切入点
* **活动平台**：飞书知识库、飞书社群、微信群、线下沙龙、B站

### 5.4 OpenBMB（大模型开源社区）

清华大学 NLP 实验室（THUNLP）与面壁智能联合发起，全称 Open Lab for Big Model Base，孙茂松教授团队支持。孙茂松是欧洲人文和自然科学院外籍院士、ACL 会士、清华大学计算机系长聘教授。

* **核心项目**：ChatGLM（早期知名开源中文大模型）、MiniCPM（端侧多模态大模型，2.4B 参数，中文/数学/代码能力优于 Mistral-7B，6G 内存可跑）、BMTrain（高效训练框架）、OpenDelta（高效微调）、OpenPrompt（提示学习工具）等。
* **学术价值**：项目大多伴随顶会论文（ACL、EMNLP、CVPR 等）发表，想发论文的研究生可以直接读代码和配套论文。
* **核心活动**：大模型技术论坛、高校行讲座、开源项目 Contributor 招募（可写进简历）。
* 官网：https://www.openbmb.cn / https://www.openbmb.org
* GitHub：https://github.com/openbmb
* **适合人群**：NLP/多模态方向的研究生、算法工程师
* **活动平台**：GitHub、官网、公众号、微信群

### 5.5 魔搭社区（ModelScope）

阿里达摩院与 CCF 开源发展委员会联合发起的 AI 模型开源社区，2022 年 11 月在云栖大会正式推出，被称为"中国的 Hugging Face"。定位"模型即服务（Model-as-a-Service）"。

* **规模**：截至 2025 年 10 月，社区汇聚了超 12 万个开源模型、5500+ 项 MCP 服务，服务全球超 200 个国家的用户。
* **核心功能**：
  * 提供云端免费算力（Notebook），不用自己配 GPU 就能在浏览器里体验和微调大模型（Qwen、Llama、Stable Diffusion 等）。
  * 创空间（Studio）里有大量开发者分享的 AI 应用 Demo，可以直接跑和改。
  * 每年暑期办 AI 夏令营，提供算力和专家指导。
* **最新动态**：2025 年上线国际版，发布科学智能专区与 AIGC 创作引擎 FlowBench；2026 年杭州市宣布从数据、算力、空间等方面支持魔搭社区发展。
* 官网：https://www.modelscope.cn
* GitHub：https://github.com/modelscope
* **适合人群**：AI 开发者、计算机专业学生
* **活动平台**：官网、GitHub、公众号、知乎、B站

### 5.6 百度飞桨 AI Studio 与飞桨领航团

百度飞桨（PaddlePaddle）是 2016 年开源的国产深度学习平台，也是中国首个自主研发的产业级深度学习平台。

* **平台能力**：PaddlePaddle 3.0 提供 50 个经过真实业务场景验证的官方模型，涵盖视觉、NLP、语音和推荐等方向。支持千亿规模参数、数百个节点的高效并行训练。AI Studio 是一站式实训平台，提供免费 GPU 算力。
* **领航团**：飞桨的高校线下组织，由学生当"团长"自主运营，百度提供算力卡、硬件（如树莓派）、教材和导师。
* **学习资源**：有从零基础到大模型微调的体系化课程。AI Studio 上常年有企业出题、学生打榜的算法竞赛。
* **职业发展**：表现好的学生可以进"飞桨开发者技术专家计划（PPDE）"，甚至拿到百度实习机会。
* AI Studio 社区：https://aistudio.baidu.com（免费 GPU 算力）
* **适合人群**：低年级大学生、深度学习入门者、想找竞赛组织的同学
* **活动平台**：AI Studio 平台、高校领航团线下活动、微信群、B站

### 5.7 和鲸社区（Heywhale）

2015 年由范向伟在上海创立的数据科学协同创新平台（原名"科赛网"），是中国最早的第三方数据科学社区之一。

* **平台**：旗下 ModelWhale 是数据科学 SaaS 平台，可满足数据科学家在线完成分类、建模、分析、可视化等任务。
* **社区规模**：拥有近 10 万注册数据科学家，辐射超 30 万数据人才群体。与 Kaggle 类似，但更贴近国内高校教学生态。
* **资源**：社区里有 5 万+ 个 Jupyter Notebook 项目和 1 万+ 个行业数据集，涵盖经管、医学、气象、地理、AI 等方向。提供免费在线 Jupyter 环境，一键运行别人分享的代码。
* **赛事**：承办"中国大学生计算机设计大赛大数据主题赛"等国家级/省级赛事。被众多高校教师直接用作数据分析、统计学课程的实训平台。
* 官网：https://www.heywhale.com
* 云端编程环境：https://www.modelwhale.com
* **适合人群**：统计学、经济学、医学等需要数据分析和 AI 的交叉学科学生
* **活动平台**：官网、云端环境、公众号、高校实训营

### 5.8 北京智源人工智能研究院（BAAI）

2018 年成立的新型研发机构，由北京政府支持，黄铁军、唐杰、朱松纯等大佬坐镇。

* **核心成果**：研发了中国首个超大规模智能模型"悟道"；开源了 FlagEval（大模型评测基准，构建"能力-任务-指标"三维评测框架）和 FlagOpen（大模型开源体系）；开源了悟道·天鹰（Aquila）语言大模型系列（首个具备中英双语知识、支持商用许可的开源中文大模型）、BGE（文本向量模型，被全球广泛使用）等。
* **社区贡献**：截至 2026 年，智源开源模型超 200 个，全球总下载量累计超 10 亿次。
* **年度大会**：BAAI 智源大会是国内大模型学术圈的重头活动之一，定期邀请图灵奖得主和国内外学者做报告，视频全部开源。2026 年大会主题围绕世界模型、通用智能体、具身智能、AI 安全等前沿方向。
* 官网：https://www.baai.ac.cn
* 智源社区：https://hub.baai.ac.cn
* GitHub：https://github.com/BAAI-Agents 等多个项目组
* **适合人群**：想做 AI 基础研究、接触顶级科研团队的硕博研究生
* **活动平台**：官网、智源社区 Hub、公众号、视频号

### 5.9 ShowMeAI 知识社区

AI 学习资料库，和 Datawhale 的"共学"模式不同，ShowMeAI 偏重提供结构化、图解式的教程。定位为"AI 领域的百科全书"，为开发者、学生及企业提供一站式学习与解决方案。覆盖 Python、数据科学、机器学习、深度学习、NLP、计算机视觉等方向。专业团队联合一线工程师打造，提供从基础到进阶的系统化学习路径。把吴恩达深度学习、斯坦福 CS224n（NLP）、CS231n（CV）等课程做成了图文版/思维导图版笔记，英语基础弱或不习惯看视频的同学用得上。从一线工程师视角拆解 AI 在推荐系统、广告、风控等业务中的实际落地案例。有算法工程师面试题解析。平台还提供个性化学习计划功能。

* 官网：https://www.showmeai.tech
* **适合人群**：自学机器学习/深度学习、准备算法岗求职的大学生和研一学生
* **活动平台**：官网、公众号、博客园、CSDN、知乎

### 5.10 昇思 MindSpore 开源社区（华为）

华为开源的全场景 AI 框架 MindSpore 的开发者社区，2020 年 3 月发布第一个版本。

* **框架特点**：旨在实现易开发、高效执行、全场景覆盖三大目标，支持云、边缘以及端侧场景。采用基于源码转换的自动微分机制，动态图和静态图切换只需改一行代码。提供自动并行能力，开发者无需编写复杂的分布式策略。
* **生态地位**：随着昇腾 910B/910C 等国产算力的崛起，MindSpore 在政企市场和部分高校的占有率在上升。在 Gitee 上是 2020 年千万开源项目中 Gitee 指数 Top 1 项目。
* **特色机会**：
  * **众智计划**：华为出资发布 MindSpore 适配的科研课题和开源任务，完成可拿现金奖励。
  * 每年联合高校办 AI 创新大赛和夏令营，提供免费昇腾算力。
  * 掌握 MindSpore 对进华为及上下游生态（科大讯飞、AI 国企等）有帮助。
* 官网：https://www.mindspore.cn
* **适合人群**：对底层框架感兴趣、有意向国产信创/华为生态发展的学生
* **活动平台**：官网、Gitee、GitHub、公众号、论坛

## 六、学术期刊与专业会议委员会

研究生关注这些学术组织的动态，有助于把握学科方向和交流机会。

### 6.1 CCF（中国计算机学会）及矩阵

CCF 成立于 1962 年 6 月（前身是中国电子学会计算机专业委员会，1985 年正式改名中国计算机学会），是中国计算机及 AI 领域的一级学会，隶属中国科学技术协会。它发布的《CCF 推荐国际学术会议和期刊目录》（即"CCF A/B/C 类"）是国内高校科研评价的常用标准。实行会员制，下设 16 个工作委员会、40 个专业委员会、7 个"计算+行业"分会、45 个地方会员活动中心。每年举办 1500+ 场/次各种规模、层次的学术会议、产业与技术论坛和培训。是国内首个实现理事会、监事会、下属专业委员会负责人公开差额选举的全国性学会。自 2013 年起与十余家企业合作设立 CCF 产学合作基金，2023 年年度资助规模超 7000 万元。2021 年启动 CCF 计算机博物馆建设（落户横店，预计建筑面积约 6 万平方米，建成后将是世界最大的计算机博物馆）。与 IEEE-CS、ACM 等国际学术组织有密切合作。

* 官网：https://www.ccf.org.cn
* CCF 数字图书馆：https://dl.ccf.org.cn（收录大量顶会论文、专家报告视频、讲稿和公开课，找论文和看讲座录像都用得上）
* CCF 会议系统：https://conf.ccf.org.cn（会议报名和日程发布平台）
* **公众号矩阵**：
  * **CCFVoice**（官方主号）：学会动态、奖励评选、会议通知（如 CNCC）、学术评价。
  * **CCF数图焦点**：数字图书馆中的学术专辑、技术综述和专家报告。
  * **CCF学生分会**（各高校都有）：保研/考研/就业分享、学术沙龙。
* **其他平台**：微博、B站（偶尔直播 CNCC 特邀报告）
* **核心活动**：CNCC（中国计算机大会，国内规模最大的计算领域年度盛会）、ADL（学术周，前沿技术讲习班）、YOCSEF（青年计算机科技论坛，博士生和青椒参与较多的思辨型论坛）、CSP 认证（软件能力认证，求职/保研用得上）

### 6.2 CCF 核心 AI 相关专委会

CCF 下设 30 多个专委会，以下是和 AI 关系最密切的几个。

#### CCF 计算机视觉专委会（CCF-CV）

2013 年 10 月成立，是国内唯一以"计算机视觉"命名的专委会，委员中有谭铁牛院士、王耀南院士等团队骨干。目标是就计算机视觉学科的专业内容开展学术/技术交流、发展战略研究，促进国内学者间的了解与合作，推动国内计算机视觉学科发展，提升我国计算机视觉研究在国际领域的影响力。

* 官网：https://ccfcv.ccf.org.cn
* **核心活动**：
  * PRCV（中国模式识别与计算机视觉大会）：国内 CV 领域规模最大的年度学术会议，每年 2000+ 人参会。由 CCF、CAA、CSIG、CAAI 四家联合主办。
  * CCF-CV 走进高校：组织学者去高校做巡回报告。
  * CVPR/ICCV/ECCV 论文分享会：每次顶会结束后组织线上论文分享。
  * CCF 计算机视觉前沿讲习班：面向青年从业者的短期系列课程。
* **平台**：公众号（搜"CCF 计算机视觉专委会"）、官网、CCF 会议系统

#### CCF 自然语言处理专委会（CCF-NLP）

国内 NLP 领域的权威学术组织，委员来自清华、北大、哈工大、中科院等 NLP 重镇。大模型时代活跃度明显上升。专委会设有 NLPCC 突出贡献学者、特别贡献学者和青年新锐学者等荣誉。

* 官网：http://tcci.ccf.org.cn
* **核心活动**：
  * NLPCC（CCF 国际自然语言处理与中文计算会议）：专委会旗舰国际会议，每年秋季举办，入选 CCF 高质量国际学术会议促进计划。论文发表在 Springer LNAI 系列（EI & ISTP 索引）。2012 年起已在北京、重庆、深圳、南昌、昆明、大连、呼和浩特、郑州、青岛、桂林、佛山、杭州等城市举办。
  * 语言与智能高峰论坛：聚焦 NLP 与大模型前沿。
  * CCF-NLP 高校行：知名 NLP 学者进地方高校做科普和学术指导。
* **平台**：公众号（搜"CCF 自然语言处理专委会"）、官网

#### CCF 多媒体技术专委会（CCF-MM）

1994 年成立的老牌专委会，委员覆盖国内 45 个单位，已成为国内多媒体技术领域具有活力和凝聚力的学术组织。多媒体技术覆盖面广，音视频处理、多模态大模型、AIGC、虚拟现实都算。专委会里长江、杰青等专家近 40 人。2004 年、2007 年被评为 CCF 优秀专委，2025 年再获"优秀分支机构"奖。与 IEEE CS TCMC、IEEE COMM TMTC、ACM SIGMM China Chapter 等国际组织有合作。

* 官网：https://tc.ccf.org.cn/tcmt/
* **核心活动**：
  * ChinaMM（中国多媒体大会）：国内多媒体领域的高级别学术会议。
  * CCF-MM 走进高校/企业：经常邀请腾讯、阿里等大厂的多媒体 AI 团队做分享。
  * 多媒体技术回顾与展望论坛：年度学术研讨活动。
  * 《多媒体技术十讲》研讨会。
* **平台**：公众号（搜"CCF 多媒体专委会"）、官网

#### CCF 人工智能与模式识别专委会（CCF-AI）

聚焦 AI 基础理论、机器学习算法、模式识别等底层技术。

* 官网：https://www.ccf.org.cn/Chapters/TC/TC\_Listing/TCAIPR/
* **核心活动**：CCFAI（中国计算机学会人工智能会议）、CCF-AI 走进高校系列报告会
* **平台**：公众号、官网

### 6.3 CAAI（中国人工智能学会）及专委会

CAAI 成立于 1981 年，是我国智能科学技术领域唯一的国家级学会（全国一级学会），挂靠北京邮电大学，隶属中国科学技术协会。拥有 62 个分支机构（53 个专业委员会和 9 个工作委员会），覆盖智能科学与技术领域。具有推荐"两院院士"的资格。自主创办全球人工智能技术大会、中国人工智能大会、中国智能产业高峰论坛、国际人工智能会议、全球人工智能技术创新大赛等规模化系列化学术活动。主办有 CAAI Artificial Intelligence Research、《智能系统学报》等出版物。推出以"吴文俊人工智能科学技术奖"为代表的人才奖励体系。设有 CAAI-蚂蚁科研基金、CAAI-玻色量子计算基金等面向高校师生的科研基金。

* 官网：https://www.caai.cn / https://new.caai.cn/
* **公众号**：中国人工智能学会（发布国家级 AI 奖项、基金征集、清源学者计划等）、CAAI 模式识别专委会等分支公众号
* **平台**：官网、公众号、CAAI 数字图书馆
* **核心活动**：
  * CAAI-蚂蚁科研基金 / CAAI-玻色量子计算基金：面向高校师生的科研基金，研究生可以申请。
  * 中国"人工智能+"创新创业挑战赛：千万级资金、算力和场景支持。
  * 全国中小学人工智能探究性学习训练营：师范生或研究生可以参与志愿服务。

#### CAAI 模式识别专委会

2014 年成立，挂靠中科院自动化所模式识别国家重点实验室（https://www.nlpr.ia.ac.cn/caaipr/），连续多年获评 CAAI 优秀专委会。旨在团结模式识别领域的科研人员，开展学术交流、技术测评和标准制定。研究方向包括生物特征识别（人脸/指纹/虹膜）、医学图像分析、底层视觉算法等。

* **适合人群**：做人脸/指纹/虹膜识别、医学图像分析、底层视觉算法的研究生
* **平台**：公众号（CAAI 模式识别专委会）、挂靠单位官网

### 6.4 CSIG（中国图象图形学学会）

CSIG 成立于 1990 年，是国内图像、图形、视觉领域极具活力的国家一级学会，挂靠中科院自动化所。与 CCF-CV 侧重"计算机视觉算法"不同，CSIG 的覆盖面更广，涵盖了医学图像、遥感图像、计算机图形学、可视化、工业机器视觉等交叉学科。现任理事长王耀南院士、秘书长马惠敏。拥有个人会员和团体会员。**公众号**每天推送国内各大高校的学术沙龙、青托论坛、会议征文，更新非常频繁。B站/视频号经常直播学术研讨会。**CSIG 图像图形中国行**已举办 170+ 期，组织顶尖学者去全国各地高校做巡回报告，各高校研究生可以留意自己学校有没有承办。CSIG 图像图形技术挑战赛由企业出题、高校学生打榜。设有石青云女科学家奖、优秀博士学位论文奖等。主办 Visual Intelligence 等期刊。

* 官网：https://www.csig.org.cn（移动端：m.csig.org.cn）
* **核心活动**：
  * CCIG（中国图象图形大会）：学会年度旗舰大会，2022 年创办，预计参会 3000-4000 人。
  * CSIG 图像图形中国行：组织学者去全国高校做巡回报告，已办 170+ 期。各高校研究生可以留意自己学校有没有承办。
  * CSIG 图像图形技术挑战赛：企业出题、高校学生打榜。
  * CSIG 图像图形学科前沿讲习班。
* **主办期刊**：《中国图象图形学报》（官网：https://www.cjig.cn）

### 6.5 其他

#### CIPR（中国自动化学会模式识别与机器智能专委会）

挂靠中科院自动化所，与中国人工智能学会的模式识别专委会联系紧密（常开联席会议）。侧重于控制论、自动化与 AI 的结合，如机器人视觉、自动驾驶感知。

* **平台**：公众号、挂靠单位官网

#### 《中国图象图形学报》

CSIG 会刊，国内图像图形领域最权威的中文学术期刊（核心/EI 期刊）。每年出《图像图形学发展年度报告》专刊，收录数十篇高质量综述，覆盖图像分析与识别、计算机视觉、医学影像、遥感图像、三维视觉等方向。新生找研究方向、写开题报告时可以翻一翻。同时主办 Visual Intelligence 等新刊。

* 官网：https://www.cjig.cn
* **平台**：官网、公众号

#### CCF Conference Deadlines (CCFDDL)

由国内开源社区 ccfddl 维护的顶会截止日期追踪工具，GitHub 仓库 ccfddl/ccf-deadlines。将 CCF 推荐的 A/B/C 类会议（CVPR、ACL、NeurIPS、AAAI 等）的截稿日期、开会时间、历年录用率都列了出来，支持按 CCF 等级、CORE 等级、TH-CPL 等级筛选。提供网站、Python CLI、微信小程序等多种访问方式。截止时间用本地时区倒计时显示，还标注了延期概率。社区还在 acceptedlab.tech 上提供了更完整的投稿路线规划与讨论入口。

* 官网：https://ccfddl.cn
* GitHub：https://github.com/ccfddl/ccf-deadlines
* **适合人群**：投顶会的研究生、青椒
* **平台**：官网、GitHub、微信小程序

## 七、AI 厂商导航

各大模型与 AI 厂商的官网、技术博客和社交账号汇总。

### 7.1 国际顶流（Frontier Labs）

| 厂商 / 模型 | 官网 | 技术博客 / 新闻中心 | X (Twitter) 账号 |
| --- | --- | --- | --- |
| **OpenAI** (ChatGPT) | [openai.com](https://openai.com/) | [openai.com/blog](https://openai.com/blog) | [openai.com/news](https://openai.com/news/) | [@OpenAI](https://x.com/OpenAI) |
| **Anthropic** (Claude) | [anthropic.com](https://anthropic.com/) | [anthropic.com/news](https://anthropic.com/news) | [anthropic.com/research](https://anthropic.com/research) | [@AnthropicAI](https://x.com/AnthropicAI) |
| **Google DeepMind** (Gemini / Gemma) | [deepmind.google](https://deepmind.google/) | [deepmind.google/blog](https://deepmind.google/blog/) | [@GoogleDeepMind](https://x.com/GoogleDeepMind) |
| **Meta AI** (Llama) | [meta.ai](https://meta.ai/) | [llama.meta.com](https://llama.meta.com/) | [ai.meta.com/blog](https://ai.meta.com/blog/) | [@Meta](https://x.com/Meta) | [@MetaAI](https://x.com/MetaAI) |
| **xAI** (Grok) | [x.ai](https://x.ai/) | [x.ai/blog](https://x.ai/blog) | [@xai](https://x.com/xai) |
| **Microsoft AI** | [microsoft.com/ai](https://www.microsoft.com/ai) | [blogs.microsoft.com](https://blogs.microsoft.com/) | [@Microsoft](https://x.com/Microsoft) |
| **Amazon** (AWS Nova) | [aws.amazon.com](https://aws.amazon.com/) | [aws.amazon.com/blogs/aws](https://aws.amazon.com/blogs/aws/) | [@awscloud](https://x.com/awscloud) |
| **NVIDIA** (Nemotron) | [nvidia.com/ai](https://www.nvidia.com/ai) | [blogs.nvidia.com](https://blogs.nvidia.com/) | [@NVIDIAAI](https://x.com/NVIDIAAI) |

### 7.2 国际新锐（开源先锋与算力巨头）

| 厂商 / 模型 | 官网 | 技术博客 / 动态 | X (Twitter) 账号 |
| --- | --- | --- | --- |
| **Mistral AI** | [mistral.ai](https://mistral.ai/) | [mistral.ai/news](https://mistral.ai/news/) | [@MistralAI](https://x.com/MistralAI) |
| **Cohere** | [cohere.com](https://cohere.com/) | [cohere.com/blog](https://cohere.com/blog) | [@Cohere](https://x.com/Cohere) |
| **Perplexity** | [perplexity.ai](https://perplexity.ai/) | [perplexity.ai/hub](https://perplexity.ai/hub) | [@perplexity\_ai](https://x.com/perplexity_ai) |
| **Groq** | [groq.com](https://groq.com/) | [groq.com/news](https://groq.com/news/) | [@GroqInc](https://x.com/GroqInc) |
| **Cerebras** | [cerebras.net](https://cerebras.net/) | [cerebras.net/blog](https://cerebras.net/blog) | [@CerebrasSystems](https://x.com/CerebrasSystems) |

### 7.3 中国大厂（科技与互联网巨头出品）

| 厂商 / 模型系列 | 官网入口 | 技术博客 / 动态中心 | 核心关联微信公众号 |
| --- | --- | --- | --- |
| **阿里通义** (Qwen / 千问) | [tongyi.aliyun.com](https://tongyi.aliyun.com/) | [qwenlm.github.io/blog](https://qwenlm.github.io/blog/) | 千问大模型、魔搭 ModelScope 社区 |
| **小米** (Xiaomi MiMo / MiLM) | [mimo.xiaomi.com](https://mimo.xiaomi.com/) | [mimo.xiaomi.com/#blog](https://mimo.xiaomi.com/#blog) | Xiaomi MiMo |
| **字节跳动** (Seed / 豆包) | [doubao.com](https://www.doubao.com/) | [volcengine.com/docs](https://www.volcengine.com/docs) | 字节跳动技术团队 |
| **美团** (LongCat / 龙猫) | [longcat.ai](https://longcat.ai/) | [tech.meituan.com](https://tech.meituan.com/) | 龙猫 LongCat、美团技术团队 |
| **腾讯混元** (Hunyuan) | [hunyuan.tencent.com](https://hunyuan.tencent.com/) | [cloud.tencent.com/developer](https://cloud.tencent.com/developer) | 腾讯技术工程、清华-腾讯联合实验室 |
| **蚂蚁集团** (百灵大模型) | [bailing.antgroup.com](https://bailing.antgroup.com/) | [open-antgroup.github.io](https://open-antgroup.github.io) | 蚂蚁技术、昇腾 CANN（生态合作） |
| **快手** (KwaiKAT / 可图) | [streamlake.com](https://www.streamlake.com/) | [kolors.kuaishou.com](https://kolors.kuaishou.com/) | [klingai.kuaishou.com](https://klingai.kuaishou.com/) | KwaiKAT |
| **百度文心** (Ernie / 文心一言) | [yiyan.baidu.com](https://yiyan.baidu.com/) | [ai.baidu.com/forum](https://ai.baidu.com/forum) | 百度 AI、百度开发者中心 |

### 7.4 中国新锐（明星独角兽与顶级科研机构）

| 厂商 / 模型系列 | 官网入口 | 技术博客 / 开发者文档 | 核心关联微信公众号 |
| --- | --- | --- | --- |
| **DeepSeek** (深度求索) | [deepseek.com](https://www.deepseek.com/) | [api-docs.deepseek.com](https://api-docs.deepseek.com/) | DeepSeek |
| **智谱 AI** (GLM 系列) | [zhipuai.cn](https://www.zhipuai.cn/) | [open.bigmodel.cn/dev](https://open.bigmodel.cn/dev/api) | 智谱 |
| **月之暗面** (Kimi / Moonshot) | [moonshot.cn](https://www.moonshot.cn/) | [platform.moonshot.cn/docs](https://platform.moonshot.cn/docs) | 月之暗面 Kimi |
| **稀宇科技** (MiniMax / 海螺 AI) | [minimax.io](https://www.minimax.io/) | [platform.minimaxi.com](https://platform.minimaxi.com/) | MiniMax 稀宇科技 |
| **阶跃星辰** (Stepfun) | [stepfun.com](https://www.stepfun.com/) | [platform.stepfun.com](https://platform.stepfun.com/) | 阶跃星辰 |
| **百川智能** (Baichuan) | [baichuan-ai.com](https://www.baichuan-ai.com/) | [baichuan-ai.com/blog](https://www.baichuan-ai.com/blog/) | 百川智能 |
| **上海人工智能实验室** (InternLM) | [shlab.org.cn](https://www.shlab.org.cn/) | [internlm.org/blog](https://internlm.org/blog) | 上海人工智能实验室 |
| **商汤科技** (SenseNova / 日日新) | [sensetime.com/cn](https://www.sensetime.com/cn) | [sensetime.com/cn/blog](https://www.sensetime.com/cn/blog) | [sensenova.cn](https://www.sensenova.cn) | 商汤科技SenseTime |
| **零一万物** (01.AI / Yi 系列) | [01.ai](https://www.01.ai/) | [01.ai/blog](https://www.01.ai/blog) | 零一万物 |

### 7.5 补充：AI 生态观察

部分公众号属于垂直技术社区、硬件平台或跨界实验室，没单独归到某家厂商下面，放在这里：

* **小红书技术 REDtech**：小红书技术团队，多模态与内容推荐方向
* **魔搭 ModelScope 社区**：阿里开源模型社区，国内模型托管平台之一
* **昇腾 CANN**：华为昇腾 AI 基础软硬件平台，算力与底层加速方向
* **清华-腾讯联合实验室**：产学研合作，发前沿 AI 论文和学术成果

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-file-deletion-defense-202605.md
description: 从真实删文件事故出发，分层解释 trash、规则文件、Git 提交点和恢复流程分别能防什么、不能防什么。
---

# AI 删文件防御与 Git 兜底

> 下午让 Codex 给我写代码，遇到一个问题让它修复，我开始刷抖音，一抬头，AI 跟我说这个文件夹好像是空的，我一看我去，桌面上的文件都没了，我看一下 D 盘，直接给我清空了。
>
> 我写的论文，年后要发论文，没备份也没了。用恢复工具能扫描出来结构，能扫描出来文件大小，但是二进制全是 0，恢复之后不可打开。
>
> 太绝望了，提醒大家，用编程工具权限不要给那么高，也不会对你的数据负责。
>
> 相关 X 链接：
>
> * https://x.com/Astronaut\_1216/status/2054935258487996598
> * https://x.com/Astronaut\_1216/status/2054943034937389214

看完这类事故，很多人会立刻补两样东西：一条"不要用 rm"的规则，或者一个"反正还有 Git"的心理安慰。两样都不够，因为 `trash`、规则文件、Git、远程仓库、额外备份，本来就在不同层上工作。

这一篇只做一件事：把防护层和兜底层分开讲清楚。前者回答"怎样让模型少删"，后者回答"删了之后怎么退"。两者都要有，顺序不能反。

## 第一层：将不可逆删除改为回收站删除

很多人第一反应是在 `AGENTS.md` 或 `CLAUDE.md` 里加一句：

```text
删除文件时使用 trash，不要直接使用 rm。
```

或者更激进一点，在 shell 里做别名：

```bash
alias rm='trash'
```

这类做法当然有意义，但意义非常具体：**把一部分"手滑式删除"改成可恢复的删除**。如果模型老老实实照着你给的命令习惯走，它原本会直接删掉文件，现在会把文件移进垃圾桶，你至少还有撤回窗口。

这个思路适合放在仓库规则里，也适合放在个人 shell 环境里。不同系统里，你可能用的是 `trash`、`trash-put`、macOS 的同类工具，甚至是你自己的包装脚本。关键是行为语义：先进入垃圾桶，给自己留一个撤回窗口。

## 这一层的局限

问题在于，alias 和规则文件从来都算不上硬隔离。

alias 方面。Bash 官方手册明确写了：alias 默认只在**交互式 shell** 展开；非交互式 shell 除非显式打开 `expand_aliases`，否则不会替换。很多 Agent 调命令时，并不一定跑在你平时手敲命令的那个交互式环境里。也就是说，你在终端里 `rm` 被替换成了 `trash`，不代表模型通过脚本、子 shell 或工具调用发出的 `rm` 也会自动替换。

规则文件也一样。`AGENTS.md`、`CLAUDE.md` 确实有用，但它们是文本约束。模型可能遵守，也可能漏掉，还可能在上下文漂移、任务切换、工具调用链很长的时候绕开。给 `rm` 戴垃圾桶头盔，和给 AI 上儿童锁差不多。能挡掉一部分意外，但挡不住所有路线。

## 模型绕开的方式，至少有这几类

如果你只把防线押在"别用 rm"，那模型真要删的时候，办法并不少。最常见的绕法至少有四类：

### 1. 直接调用绝对路径

```bash
/usr/bin/rm -rf some-dir
```

如果你只做了 `alias rm='trash'`，这种写法根本不会碰你的 alias。

### 2. 用移动代替删除

```bash
mv some-dir /dev/null
```

这条命令本身未必在所有系统上都成立，但它代表的是同一类思路：**绕过 `rm` 这个词本身，换一条文件系统路径做破坏性处理**。你限制的是命令名，它走的是另一套操作语义。

### 3. 在脚本或解释器里删

```python
import os
import shutil
from pathlib import Path

os.remove('notes.md')
Path('draft.txt').unlink()
shutil.rmtree('old-build')
```

Python 官方文档里，`os.remove()` / `os.unlink()` 用于删文件，`os.rmdir()` 用于删空目录，`shutil.rmtree()` 则可以直接删掉整个目录树。只要模型能写脚本、能运行脚本，你限制 shell 命令名并不能挡住解释器层面的删除。

### 4. 重写后提交"空结果"

还有一类不那么显眼：它没有直接删文件，但会把文件内容大面积覆盖，或者把本来该保留的区块替换成空内容，再把结果当成"修复完成"交给你。对恢复来说，这和误删差别不大。

这里要记住的是：**"使用 trash，不用 rm"只是第一层缓冲。**

## 第二层：Git 解决的是"回到上一个可确认状态"

到了这里，Git 的角色就清楚了：它负责把你带回一个明确、可核对、可恢复的版本。

这一层的重点，是你有没有把 Git 用成工作流。

### 开工前建立分支

别让 AI 直接在你当前唯一的工作分支上乱跑。切一个专门分支，至少把这次实验的改动圈起来。

```bash
git switch -c ai/delete-defense-202605
```

如果你更习惯旧命令，也可以：

```bash
git checkout -b ai/delete-defense-202605
```

这样做的价值很直接：后续回退、比较、丢弃都会干净很多。

### 修改前检查工作区状态

每次把任务交给模型前，确认一眼仓库当前状态，别把旧改动和新改动混在一起。

```bash
git status --short
git diff
```

如果一开始就堆着一批未提交文件，模型一旦误删或误改，事后很难分清哪些是旧问题，哪些是这次引入的。

### 关键节点一定要 commit

Git 能兜底的前提，是你手里有可以退回的提交点。最怕的是模型跑了半小时，期间没留任何 savepoint，结果一次性全丢。

一个实用做法是：

* 改动前留一个"起跑点"；
* 跑完一个大步骤留一个"中间点"；
* 准备交卷前留一个"候选结果点"。

命令很普通，但必须真做：

```bash
git add -A
git commit -m "wip: before ai edits"
```

中途如果你验证过一个阶段性结果，也可以继续：

```bash
git add -A
git commit -m "wip: ai pass 1 verified"
```

不要等到"全部做完再一起提交"。你等的这段时间，恰好是最可能把退路一起丢掉的时间。

### AI 修改后的 diff 检查

模型跑完任务，别急着信它那句"已完成"。先把 diff 看完。

```bash
git diff
git diff --staged
```

大删文件、大覆盖、奇怪重排、误动无关目录，这些东西在 diff 里通常比在自然语言回复里明显得多。

如果你看到它改了不该改的地方，别急着让它继续补救。这时最要紧的是保住现场，回退还是局部修，等 diff 看清再定。

## 真出事了，怎么用 Git 回来

### 恢复某个文件到当前提交版本

```bash
git restore path/to/file
```

### 恢复整个工作区的未提交改动

```bash
git restore .
```

### 从某个历史提交里捞回文件

```bash
git restore --source=<commit> path/to/file
```

老一点的写法也可以：

```bash
git checkout <commit> -- path/to/file
```

### 分支彻底跑偏了，直接回到前一个提交点

```bash
git log --oneline
git reset --hard <commit>
```

这一步要谨慎，因为它会丢掉当前工作区的未保存改动。它适合你已经确认"当前这一坨都不要了"的时候。

### `.git` 一起没了怎么办

这时候要冷静一点：**本地 Git 已经帮不了你。**

如果模型删的不只是业务文件，还把 `.git` 目录一起干掉，本地版本历史就没了。你能指望的只剩几种外部退路：

* 远程仓库还在，可以重新 clone；
* 还有别的本地副本、网盘快照、系统备份；
* 再不行才轮到文件恢复工具。

所以 Git 的正确定位是"版本化兜底"。它能救的，是已经进过版本控制、也有提交点可退的内容。

## 第三层：把规则文件当成活文档来维护

`CLAUDE.md / AGENTS.md` 要当活文档维护。

这句话比"写不写规则"本身更重要。很多人第一次被模型坑过后，会补一句规则；第二次、第三次又换别的坑，因为旧规则没人回头整理，新的坑也没人写进流程里。久而久之，规则文件要么太空，要么太乱。

更实用的做法是：每次翻车后，不只是让模型道歉，还要把这次纠正规则整理回文档。比如：

```text
- 删除文件前必须先说明目标路径和原因。
- 涉及批量删除、重命名、移动目录时，先展示拟执行命令，再等待确认。
- 除非用户明确要求，不要执行 commit / push / merge。
- 运行脚本前，先解释脚本会触碰哪些路径。
```

这类规则不能保证零事故，但会让后续同类错误变少。它的价值在于持续纠偏。

## 用户经验：别把它们当基准评测，但也别装没看见

下面这些内容都只按用户公开经验来写，不当成实验室 benchmark，也不当成模型厂商的正式结论。它们的价值在于提醒你：误删、误覆盖、奇怪行为，在不同模型上都可能出现。

### Qwen

有用户在 LINUX DO 里直接写过：让 Qwen 3.5 Plus 去修 Git 错误，结果"直接删库了"，还补了一句"codex 倒是靠谱很多，从来没有乱改我的文件"。这显然只是个人使用感受，但它至少说明一件事：你不能因为模型换了名字，就默认删文件风险自动消失。

### DeepSeek

另一位用户记录的是 DeepSeek V4 Pro (max) 在一次 `edit` 操作里，把两个相同字段之间的几千行代码整段覆盖掉。第一次模型自己发现并修了一次，第二次直接交卷，用户后来的结论是：不敢再让它碰这个项目了。

还有一篇长文本格式保留的体验贴提到：在某些 docx 转 markdown 的场景里，DeepSeek 是唯一把多个换行保留下来的，速度也快；但同一位用户后来又补了一句，某些场景下 DeepSeek 的理解能力还是不够。一个模型可能在某个局部任务里表现不错，但不代表你就该给它高权限。

### MiMo

MiMo 这边，公开帖子里既有"第一次尝试就拉了"的吐槽，也有更细一点的格式保留体验：有用户说 Qwen 和 MiMo 对 `	` 处理得不好，MiMo 速度快，但网页端没有"不思考"模式；也有人在分析项目时碰到离谱回答，清空上下文再问一次才恢复正常。

这些经验合在一起，只能说明一件事：**只要模型拥有改文件权限，工作流和回退路径就得先建好，模型偏好反而该往后放。**

## 一套更稳的"AI 改代码前"动作顺序

把这篇文章压成一份可执行清单，顺序可以这样：

### 1. 轻量防护

* 在 `AGENTS.md` / `CLAUDE.md` 里写清楚删除规则。
* 能用 `trash` / `trash-put` / 包装脚本的地方接上。
* 对批量删除、移动目录、执行脚本设置额外确认。

### 2. Git 起跑动作

```bash
git switch -c ai/safe-edit
git status --short
git add -A
git commit -m "wip: clean base before ai"
```

### 3. 让模型每跑一段就停一次

* 大改前说计划；
* 改完就看 diff；
* 通过一个阶段就留一个 commit；
* 不要让它一路静默跑完全程。

### 4. 问题发生后的现场保全

```bash
git diff
git status
git restore path/to/file
```

先把现场收住，再决定要不要继续让它修。

### 5. 事后把规则补回文档

* 这次是删文件，就补删除规则；
* 这次是误提交，就补 Git 规则；
* 这次是脚本误伤，就补脚本执行范围。

这样做几轮之后，文档才会真的长成团队的防翻车手册。

## 把顺序固定下来

用 `trash` 和确认规则减少直接误删，再用 Git 留分支、提交点和 diff，后面把翻车经验补回 `AGENTS.md` 或 `CLAUDE.md`。如果项目真的重要，再往外补远程仓库、系统快照和额外备份。

顺序固定下来，AI 就算走偏，你手里也还有回头路。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-llm-model-specs-202607.md
---
# 模型

## 1. 大模型参数与规格 (Model Specifications)

> 接触大语言模型（LLM）时，首先面对的是一串模型规格参数：`7B`、`MoE`、`128K Context`、`FP16`。这些参数直接决定了特定显卡能否运行该模型、推理速度如何、以及是否适合特定任务。
>
> 本章从架构到推理参数，系统拆解大模型的核心规格。可以结合 **[models.dev](https://models.dev)**（开源 AI 模型规格数据库）进行对比查阅，量化算力需求与模型能力边界。

### 1.1 核心架构 (Core Architecture)

架构决定了计算效率、可扩展性以及训练/推理的底层逻辑。当前主流架构分为以下几类：

* **稠密架构（Dense）**：经典 Transformer 架构。每次前向传播中，模型所有参数均被激活并参与计算。计算密集但结构简单，适合作为基座模型研究。代表：Llama 系列早期版本、Qwen 小参数版本、GPT 基础架构。

* **混合专家架构（MoE, Mixture of Experts）**：将网络切分为多个独立的"专家"子网络，通过路由器（Router）为每个 Token 动态选择激活的专家。
  * **激活参数机制**：路由器对每个 Token 进行评分（Softmax），从全部专家中仅选取最匹配的 1~3 个参与计算，其余保持休眠。这使得总参数量（Total Parameters）远大于激活参数量（Activated Parameters），单次计算量（FLOPs）和显存带宽压力显著降低。
  * **共享专家（Shared Experts）**：为避免过度稀疏导致常识遗忘，前沿模型（如 DeepSeek-V3/R1、Qwen2-MoE）引入了"共享专家"机制。共享专家对所有 Token 全局激活，承担底层逻辑和通用知识；特定领域知识则交由路由专家处理。早期 MoE 因过度稀疏，导致一些常识容易遗忘，模型在路由切换时可能丢失跨领域的基础知识。共享专家的引入解决了这个问题：它们始终参与计算，确保底层逻辑不因路由而割裂。这对 Agent 任务（依赖工具调用、严谨格式约束和系统常识）尤为重要，Agent 需要在不同领域知识之间无缝切换，同时保持对工具调用格式和系统指令的一致理解。

* **多 Token 预测（MTP, Multi-Token Prediction）**：部分模型（如 DeepSeek 系列）引入 MTP 层，允许并行预测未来多个 Token，减少自回归解码的延迟。

* **扩散模型架构（Diffusion）**：基于扩散过程（去噪）而非自回归的生成模型。主要用于图像/视频生成（如 Stable Diffusion、DALL-E），在纯文本 LLM 中较少见，但多模态模型（如 Gemini 的图像生成模块）可能结合扩散机制处理视觉输出。

### 1.2 规模与维度 (Scale & Dimensions)

选型时首先需要明确参数量级单位和显存消耗的关键概念：

* **B (Billion)**：参数数量单位。`7B` = 70 亿参数。

* **T (Trillion)**：预训练数据量或算力单位。`1T` = 1 万亿 Token。

* **总参数量（Total Parameters） vs. 激活参数量（Activated Parameters）**：
  * Dense 模型：两者相等（如 7B 模型每次计算激活全部 70 亿参数）。
  * MoE 模型：两者差距显著。**总参数量**决定模型加载到 GPU 所需的显存容量；**激活参数量**决定推理时的计算量（速度）。
  * **命名示例**：以 Qwen3.6 系列的两个模型为例：
    * `Qwen3.6-35B-A3B`：`35B` 为总参数量，`A3B` 中的 `A` 代表 **Activated**（激活参数量），即每次推理仅激活 3B 参数。你虽然需要足够的显存来装载 35B 的专家权重，但推理速度和成本只相当于一个 3B 的极小模型，而在基准测试中能力远超同规模 Dense 模型。
    * `Qwen3.6-27B-FP8`：`27B` 为参数量，`FP8` 代表模型以 FP8 精度发布（参见 1.5 节量化部分）。这是 Dense 架构，每次推理激活全部 27B 参数，但 FP8 量化显著降低了显存占用。

* **Transformer 核心维度**：
  * **网络层数（Number of Layers）**：Transformer 块的数量。层数越深，可捕捉的模式越复杂，但梯度传播难度也随之增加。
  * **隐藏层维度（Hidden Size / d\_model）**：每个 Token 在模型内部的向量表征维度。
  * **KV Heads**：推理时，已生成 Token 的状态存入 KV Cache。分组查询注意力（GQA）等机制通过减少 KV 头数量降低显存占用，是当前最重要的推理显存优化手段。

**闭源模型参数量的反推方法**：OpenAI、Anthropic、Google 均不公开旗舰模型的参数量。以下为学术界和行业使用的主要反推方法，各方法均存在显著不确定性（前沿模型 ±2x 或更多），需交叉验证：

| 方法 | 原理 | 代表来源 | 可信度 |
|---|---|---|---|
| **吞吐量反推法** | 在固定硬件后端（Google Vertex、Amazon Bedrock）上，Token/s 与激活参数量近似反比；对比已知开源模型可推算激活参数，再结合 MoE 稀疏度估算总参数 | unexcitedneurons (2026) | 较高（直接反映物理约束） |
| **IKP 事实容量法** | 1400 道冷门事实题分 7 层稀有度，用 89 个开源模型标定"准确率-参数量"对数线性回归，投影闭源模型。MoE 知识容量取决于总参数而非激活参数 | Bojie Li, arXiv:2604.24827 (2026) | 中等（原始估计被修正，置信区间宽） |
| **推理成本反推法** | 推理成本与激活参数量近似线性，结合定价与 MoE 系数推算总参数 | 36kr 行业分析、Epoch AI | 中等（受定价策略干扰） |
| **API 性能指纹法** | 首 Token 延迟（TTFT）、吞吐量对比已知模型，推断 MoE 路由开销与激活参数 | 生产环境工程师社区 | 中等（受量化/推测解码影响） |
| **硬件取证法** | 根据训练集群 GPU/TPU 数量、内存带宽、训练时长反推可承载参数上限 | Samsung SemiCon Taiwan 泄露 | 低-中等（需准确集群信息） |
| **内部泄露** | 供应链伙伴、高管社交媒体、Vertex AI 错误日志等意外暴露 | Musk 推特、The Information、Semafor | 参差不齐（需交叉验证） |

> ⚠️ IKP 方法论争议：原始估计（GPT-5.5 ≈ 9.7T, Claude Opus 4.6 ≈ 5.3T）经 UC Berkeley CHAI 复审后修正：(1) 小模型得分被悄悄归零使拟合曲线过陡；(2) ~25% 题库存在歧义或事实错误。修正后 GPT-5.5 ≈ 1.5T（90% CI: 256B-8.3T），Claude Opus 4.7 ≈ 1.1T。核心方法论仍成立，但置信区间显著扩大。

各厂商具体模型的参数量推测见 **§2 各厂商章节**内的逐模型标注。

> **开源 vs 闭源的参数量差异**：开源模型参数量代际提升平缓甚至"倒退"（看似小幅增长），并非技术落后，而是**资源约束、效率优先、专精优化和商业生态**四重因素驱动的适应性策略：
>
> * **资源约束**：芯片封锁与成本压力迫使国产模型在有限算力下极致优化效率，MoE 架构（总参多但激活少）是核心手段。
> * **密度定律**：小参数+高质量数据+MoE 可达到大参数效果；5000 亿参数后边际收益暴跌，训练/推理成本指数级上升（信通院数据：2025 年仅 12% 新模型以参数规模为核心宣传点）。
> * **专精优化**：编码等结构化领域不需要"记住全人类知识"，高质量合成数据+蒸馏可实现"以小博大"（如 DeepSeek-R1-Distill-1.5B 在数学推理上超过 GPT-4o）。
> * **部署现实**：开源模型必须可本地部署才有价值；端侧（手机/IoT/企业私有云）要求 7B 以下，参数小=推理便宜=用户基数大。
> * **架构脱钩**：MoE 让"总参数"与"激活参数"脱钩，如 Kimi K2.6 用 1T 总参/32B 激活实现"小体积大能力"，DeepSeek V4 Pro 1.6T 总参/49B 激活可在单节点运行。
>
> **本质**：闭源模型靠 API 收费摊薄成本，追求 2T→5T→10T 的总参竞赛；开源模型追求**用 1/10 激活参数达到 90% 实用能力**，在可部署性和商业可持续性上取胜。

### 1.3 输入输出与容量 (Capacity & Limits)

* **上下文窗口（Context Length）**：模型单次支持处理的最大 Token 数。`1M`（100 万 Token）约等于 75 万汉字，相当于一次性塞入几十万行核心代码或近十本长篇小说。

> **KV Cache 与长文本的物理瓶颈**
>
> 模型逐字生成时，会把历史 Token 的键值对保存在 **KV Cache**（键值缓存）中以避免重复计算。但 1M 场景下，KV Cache 体积随序列长度**线性暴涨**（每层 $O(n)$），极易引发显存溢出（OOM）。同时，传统全量注意力要求当前词与历史所有词**两两比对**，算力消耗呈**平方级** $O(n^2)$ 飙升。
>
> **幻觉率随上下文长度恶化**：长文档 QA 中，幻觉/捏造率随上下文长度显著上升。32K 时顶级模型幻觉率约 1~7%，128K 时多数模型明显恶化，200K+ 时几乎所有模型都超过 10%。
>
> **业界破局方案**：不同厂商在架构层面给出了差异化答案：
>
> * **DeepSeek MLA + CSA/HCA（多头潜在注意力 + 压缩稀疏/重度压缩注意力）**：MLA（V2 首创，V3/V4 沿用）通过低秩压缩 KV Cache 降低推理显存；CSA（Compressed Sparse Attention，V4 新增）每 4 token 压为 1 条，再用 Lightning Indexer 稀疏选择 top-k；HCA（Heavily Compressed Attention）每 128 token 压为 1 条后做 dense attention。V4 在 1M 下 FLOPs 为 V3.2 的 27%（Pro）/ 10%（Flash），KV Cache 为 V3.2 的 10%（Pro）/ 7%（Flash）。 |
> * **Kimi Attention Residuals（残差注意力）**：将固定残差连接改为深度-wise 注意力残差，动态学习各层对先前输出的加权融合，缓解 PreNorm 稀释和 Attention Sink 问题。结合线性/全注意力混合机制，部分变体节省 75% KV 内存，128K~1M 解码速度提升 5~6 倍。
> * **GPT 上下文压缩（Context Compaction）**：将非核心冗长上下文压缩成高密度特征向量，大幅减小 KV Cache 体积，同时精准召回关键代码变量。在 SWE-Bench 等长代码任务中表现突出。
> * **Claude Opus 极限注意力容量**：在 1M 全域检索评测（MRCR v2 等）中注意力稳定性最高，上下文退化（Context Rot）现象最轻，Opus 4.6 在 1M 难度变体中可达 ~76%，被公认为当前最可靠的长上下文旗舰。

> ⚠️ **标称窗口 vs. 实际可用窗口**
>
> 部分模型宣称支持 1M 上下文，但实际采用滑动窗口注意力（SWA）或上下文切片（Context Slicing）以节省计算资源。用户在长文档对话中会发现模型"失忆"，实际活跃记忆窗口远小于标称值。
>
> **典型反面案例：Gemini 3.0 Pro（2025-2026）**。虽然其支持 1M 的全局上下文，但 Google 在面向大众的网页版中实施了激进的上下文截断策略。研究人员发现，在长文档对话（超过 10 轮）或复杂剧本分析场景下，其活跃记忆窗口会被强制回退至约 **32K**。此时模型并非在 1M 范围内检索信息，而是在截断后的切片中寻找答案，导致"大海捞针"测试失败、产生幻觉或逻辑重复。
>
> **建议**：在需要强上下文记忆的任务中，不要仅参考官方宣传数字，务必使用支持完整自注意力（Full Attention）的开发者 API 接口，并通过 NIAH（Needle-in-a-Haystack）等测试验证模型的实际长文本处理能力。

* **词表大小（Vocabulary Size）**：分词器（Tokenizer）中的独立 Token 数量（通常 30K - 200K+）。更大的词表在多语言场景下压缩效率更高（如处理中文时可用更少 Token 表示更多汉字，节省上下文空间）。

### 1.4 模态与能力标签 (Modalities & Capabilities)

现代大模型已从纯文本扩展至多模态。选型时需关注**Capabilities Flags（能力标签）**：

* **多模态能力（Multimodal）**：视觉输入（Vision），如识别图像、公式截图、图表；音视频输入，支持语音对话或视频帧分析。
* **工具调用（Tool Call / Function Calling）**：模型输出可被系统执行的 JSON 指令（如调用搜索 API、执行 Python 脚本）。这是构建 Agent 的核心能力。
* **结构化输出（Structured Output）**：严格按预定义 JSON Schema 输出。在信息抽取任务（如批量提取文献摘要中的作者、方法、结果）中至关重要。
* **原生推理链（Reasoning）**：如 OpenAI o1/o3 系列、DeepSeek R1。模型在输出最终答案前生成隐式"思考过程"（Thinking Tokens），适用于数学推导、算法设计等需要多步推理的任务。

### 1.5 精度与量化 (Quantization & Deployment)

受实验室计算资源限制，往往无法以全精度（FP32）运行大模型，需了解量化相关参数：

* **支持精度（Supported Precisions）**：主流训练/推理使用 FP16 或 BF16。近期模型开始原生支持 FP8，在低精度下保持性能。
* **量化方法（Quantization Method）**：将权重压缩至 INT8 或 INT4 的算法，常见格式包括 GPTQ、AWQ、GGUF（配合 Llama.cpp 使用）。4-bit 量化可将 7B 模型显存占用从约 14GB 压缩至 5GB 以下，使消费级设备运行 LLM 成为可能，代价是轻微的性能损耗。

### 1.6 推理与生成参数 (Inference / Sampling Parameters)

以上为模型的固有规格。以下为调用 API 或运行推理时可调整的运行时参数。**这些是必须严格控制的实验变量**：

* **Temperature（温度）**：控制输出随机性，取值通常 0~2。设为 0（或接近 0）时输出高度确定，适用于数据抽取、代码生成、格式化输出；设为 0.7~1.0 时输出更具多样性，适用于头脑风暴、大纲发散。
* **Top-p (Nucleus Sampling) / Top-k**：采样策略。Top-p = 0.9 表示模型仅从累计概率达 90% 的候选词汇中选择，截断长尾低概率词以避免乱码。
* **Presence / Frequency Penalty（惩罚项）**：惩罚已出现的词汇，强制模型引入新内容，适用于长文本生成场景。
* **Stop Tokens（停止词）**：自定义模型遇到指定符号时停止生成，防止过度输出。

> 参数是模型的物理规格。开启任务前，需明确 Context 长度需求（警惕滑动窗口陷阱）、是否依赖 Vision 或 Shared Experts 赋予的 Agent 能力、以及实验室显卡能支撑的 Activated Parameters 量级。

**查阅工具**：

**[models.dev](https://models.dev)**，开源 AI 模型规格数据库，收录模型名称、实验室、上下文长度、价格、能力标签、权重开放情况、基准分数等，便于快速对比选型。

## 2. 主流厂商与模型

### 2.1 模型任务类型分类

#### 2.1.1 对话模型 (Chat / Dialogue)

**原理**：基于 Transformer 解码器架构，通过自回归方式逐 Token 生成文本。模型在大规模语料上预训练（Pretrain），经监督微调（SFT）对齐指令格式，再通过 RLHF / DPO / GRPO 等强化学习方法对齐人类偏好。

**按推理能力分类**：

2025-2026 年的核心变化是：**推理能力已从独立模型特性变为通用能力维度**。几乎所有前沿模型（GPT-5.x、Claude 4.5+、Gemini 2.5+、Qwen 3.x）都支持通过 API 参数（如 `reasoning_effort`、`thinking_budget`）控制推理强度的开关和深度。

* **通用对话模型**：面向日常交互优化，平衡质量、速度与成本。代表：GPT-4o、Claude 4.5 Sonnet、Gemini Flash、Qwen-Plus、DeepSeek V3。
* **推理增强模型 (Reasoning)**：在输出前生成隐式或显式的思维链（Thinking Tokens），分配额外推理计算资源。代表：OpenAI o3/o4-mini、DeepSeek R1、QwQ、Claude 4.7 Extended Thinking、Gemini 2.5 Pro Thinking。
* **轻量 / 高速模型**：牺牲部分能力换取极低延迟和成本，适合子任务分发、批量处理。代表：GPT Mini、GPT Spark (~1000 tok/s)、Gemini Flash、DeepSeek V4 Flash。
* **代码 / 数学专项模型**：在预训练或微调阶段针对特定领域数据增强。代表：Qwen3-Coder、DKimi-K2.7-Code、DeepSeek-Math。

**思维链（Chain-of-Thought）类型**：

* **隐式思维链 (Hidden CoT)**：模型内部生成推理 Token 但不对外展示。OpenAI o 系列采用此方式，通过 `reasoning_effort` 参数（low/medium/high）控制推理深度。
* **显式思维链 (Visible CoT)**：推理过程以 `<think>` 标签输出给用户。DeepSeek R1、QwQ、Claude Extended Thinking 采用此方式，用户可审查推理路径。
* **分支思维链 (Tree-of-Thoughts)**：采样多条推理路径并择优。DeepSeek R1 训练中使用的 GRPO（Group Relative Policy Optimization）即包含此机制。

**按模态分类**：

* **纯文本模型**：仅处理文本输入输出。大部分对话模型的基础形态。
* **多模态模型（输入）**：支持文本 + 图像 / PDF 输入，输出仍为文本。如 GPT-4o Vision、Claude Sonnet（图像输入）、Gemini Pro（图像/音频/视频输入）。
* **全模态模型（输入+输出）**：支持文本、图像、音频、视频等全模态输入，同时输出文本和语音。代表：**Qwen3-Omni** / **Qwen 3.5-Omni**（Thinker-Talker 架构，256K 上下文，113 语言，文本+图像+音频+视频输入 → 文本+语音流式输出）。

**工具调用（Tool Calling）**：绝大多数前沿对话模型支持 Function Calling，即输出可被系统执行的 JSON 指令（如调用搜索 API、执行 Python 脚本、操作数据库）。这是构建 Agent 的核心能力。各厂商实现细节不同，但接口趋于统一（OpenAI 格式为事实标准）。

| 模型 | 厂商 | 架构 | 上下文 | 推理 | Tool Call | 模态 |
|---|---|---|---|---|---|---|
| GPT-4o | OpenAI | Dense | 128K | 通用 | ✅ | 文本+图像输入 |
| GPT 5.5 | OpenAI | MoE | 1M | reasoning\_effort 可调 | ✅ | 文本+图像+PDF |
| o3 / o4-mini | OpenAI | Dense | 200K | 隐式 CoT，effort 可调 | ✅ | 文本+图像+PDF |
| Claude 4.6 Sonnet | Anthropic | MoE | 1M | Extended Thinking | ✅ | 文本+图像+PDF |
| Claude 5 Sonnet | Anthropic | MoE | 1M | Extended Thinking | ✅ | 文本+图像+PDF |
| Gemini 3.1 Pro | Google | MoE | 1M | Thinking 可调 | ✅ | 文本+图像+音频+视频 |
| DeepSeek V4 Pro | DeepSeek | MoE | 1M | 三模式推理 | ✅ | 文本 |
| DeepSeek R1 | DeepSeek | MoE | 128K | 显式 CoT (GRPO) | ✅ | 文本 |
| Qwen 3.7 Max | 阿里 | MoE | 1M | 可调 | ✅ | 文本+图像 |
| Qwen3.6-35B-A3B | 阿里 | MoE | 262K | 可调 | ✅ | 文本+图像（3.5 起全系支持） |
| Qwen3-Omni | 阿里 | Thinker-Talker | 256K | 可调 | ✅ | 全模态输入→文本+语音输出 |
| Llama 4 Maverick | Meta | MoE | 1M | 通用 | ✅ | 文本+图像 |
| MiMo-V2.5 | 小米 | MoE (310B/15B) | 1M | 通用 | ✅ | 文本+图像+视频+音频 |
| MiniMax M3 | 稀宇科技 | MoE + MSA稀疏注意力 | 1M | 可调 | ✅ | 文本+图像+视频 |

![image-20260707151705804](https://gastigado.cnies.org/d/public/image-20260707151705804.webp)

只有充分了解模型的能力边界，才能做出正确判断。上文帖子的逻辑存在根本错误：**它拿纯文本模型（DeepSeek、GLM-5.2）和专用 OCR 工具（PaddleOCR）去做"图像→手写体文本"识别，然后指责模型"不行"，这和拿菜刀去剪头发、再骂菜刀不好用是同一回事。** DeepSeek V4 Pro 和 GLM 5.2 是纯文本模型，根本不接受图片输入，输出手写体识别结果只能依赖外部 OCR 管线预处理；而 PaddleOCR 是面向印刷体文档设计的专用 OCR 引擎，手写体从来不是它的目标场景。真正应该拿来比较的是具备\*\*原生视觉输入（Vision）\*\*的模型——例如 Qwen3.6-35B-A3B（多模态 MoE，支持文本+图像+音频+视频）或 MiMo-V2.5（310B 总参/15B 激活，同样原生支持图像输入）。这些模型的 Vision 编码器在训练阶段就见过大量手写体样本，能够端到端地"看图→理解→输出文字"，识别精度远非外挂 OCR 管线可比。即便是 Qwen3.5-0.8B 这样仅 0.8B 激活参数的极小多模态模型，其手写体识别能力也显著优于纯文本模型搭配机械 OCR 的方案——因为原生多模态模型理解的是图像中的"语义"，而 OCR 只做像素级的字符分割与匹配，对手写体的连笔、倾斜、涂改等特征天然无力。**结论：评价一个模型的能力，必须先看它的能力，是纯文本还是多模态？有没有 Vision 输入？目标场景是什么？拿错工具再抱怨结果差，暴露的不是模型的问题，是使用者的认知盲区。**

#### 2.1.2 图像生成模型 (Image Generation)

**两大架构范式**：

**扩散模型（Diffusion）** 是当前图像生成的主流架构。

* **原理**：前向过程逐步向图像添加高斯噪声直至纯噪声；反向过程训练神经网络学习逐步去噪还原。条件输入（文本/图像）通过交叉注意力（Cross-Attention）引导去噪方向。典型实现包括 Latent Diffusion（在 VAE 潜空间中扩散以降低计算量）和 DiT（Diffusion Transformer，用 Transformer 替代 U-Net 作为去噪骨干）。
* **优势**：训练稳定、生成质量高、生态成熟（ControlNet、LoRA、IP-Adapter 等微调工具链完善）。
* **劣势**：推理速度慢（需多步去噪迭代，通常 20~50 步），指令遵循精度不如自回归模型。
* **代表**：Midjourney V7、FLUX 1.1 Pro、Stable Diffusion 3.5、Ideogram 3。

**自回归模型（Autoregressive）** 是新兴的图像生成架构。

* **原理**：将图像通过 VQ-VAE 等量化器离散化为 Token 序列，然后用 Transformer 解码器自回归逐 Token 生成。GPT Image 1/2 采用此方式，将文本和图像 Token 统一在同一个 Transformer 中处理，实现"原生多模态生成"。
* **优势**：指令遵循精度极高（因与文本生成共享架构，能精确理解复杂指令）、支持图文交错生成、推理速度快（可利用 KV Cache）。
* **劣势**：需要海量训练数据、Token 化可能损失高频细节、生态工具链（ControlNet 等）尚不成熟。
* **代表**：GPT Image 1/2 (OpenAI)、部分研究模型。

**按功能分类**：

* **Generation（生成）**：从文本或随机噪声创建全新图像。所有图像模型的基础能力。
* **Edit（编辑）**：在已有图像基础上进行修改、风格迁移、局部重绘。如 GPT Image 2 的指令编辑模式、Adobe Firefly 的 Generative Fill。
* **Inpainting / Outpainting**：局部区域重绘或画布扩展。Stable Diffusion 系列有专用 Inpainting 变体。

| 模型 | 厂商 | 架构 | 功能 | 特点 |
|---|---|---|---|---|
| GPT Image 2 | OpenAI | 自回归 | Generation / Edit | 指令遵循最强，原生集成对话 |
| Nano Banana 2 | Google | Diffusion | Generation / Edit | 原生集成于 Gemini，速度快 |
| Seedream 5 | 字节跳动 | Diffusion | Generation / Edit | 文字渲染最强，4K 分辨率，多图合成 |
| FLUX 2 | Black Forest Labs | DiT | Generation | 开源，高分辨率，速度快 |
| 通义万相 | 阿里 | 未公开 | Generation / Edit | 中文场景优化，开源 |

#### 2.1.3 视频生成模型 (Video Generation)

**三大架构范式**：

**扩散模型（Diffusion-based Video）**：在图像扩散架构基础上引入时序维度。

* **原理**：通过 3D 时空注意力（Spatial-Temporal Attention）或时序 Transformer 处理帧间一致性。部分模型（如 Stable Video Diffusion）采用图生视频的 I2V 模式，以首帧为条件进行条件扩散。
* **优势**：视觉质量高、运动自然、生态沿用图像扩散工具链。
* **劣势**：推理速度慢（每帧需多步去噪）、长视频一致性维护困难、物理模拟不够准确。
* **代表**：Runway Gen-4.5、Luma Ray3、Pika 2.2。

**自回归模型（Autoregressive Video）**：将视频 Token 化后逐帧或逐段自回归生成。

* **原理**：视频帧经编码器离散化为 Token 序列，用 Transformer 自回归生成。可与文本 Token 统一建模，天然支持长视频生成和音视频联合生成。
* **优势**：推理速度快（利用 KV Cache）、支持变长视频、天然适配音视频联合生成。
* **劣势**：Token 化可能损失高频细节、训练数据需求大。
* **代表**：Seedance 2.0/2.5（字节，首创音视频联合生成）、HappyHorse 1.0（阿里 ATH，150 亿参数统一 Transformer，原生音视频联合生成）。

**世界模型（World Model）**：学习物理世界的因果规律，而非仅学习像素分布。

* **原理**：模型不仅学习"视频看起来像什么"，还学习"物体如何运动、碰撞、反弹"。Sora 的定位是"世界模拟器"，通过大规模视频预训练隐式学习物理引擎。
* **优势**：物理模拟准确（物体碰撞、水花飞溅、重力效果）、支持交互式世界探索。
* **劣势**：训练成本极高、可控性仍在探索阶段、当前模型尚未完全实现物理一致性。
* **代表**：Sora 2（OpenAI，物理模拟标杆）、Veo 3.1（Google）、Runway Gen-4（World Consistency）。

**按任务类型**：

* **T2V (Text-to-Video)**：纯文本→视频。所有视频模型的基础能力。
* **I2V (Image-to-Video)**：静态图像→动态视频。保持首帧内容一致性的同时添加运动。如 Runway Gen-4.5、Kling 3.0。
* **V2V (Video-to-Video)**：输入视频→风格转换/编辑。
* **S2V (Speech-to-Video)**：语音→带口型同步的视频。如 HeyGen。
* **音频生成**：部分模型支持原生音视频联合生成（画面+音效同步输出），无需后期配音。如 HappyHorse 1.0、Seedance 2.0、Veo 3.1、Kling 3.0。

| 模型 | 厂商 | 架构 | 类型 | 分辨率 | 时长 | 音频 | 特点 |
|---|---|---|---|---|---|---|---|
| Seedance 2.5 | 字节跳动 | 自回归 | T2V / I2V | 4K | 10s | ✅ | 首创音视频联合生成，运镜意识强 |
| HappyHorse 1.0 | 阿里 ATH | 自回归（统一 Transformer） | T2V / I2V | 1080p | 3~45s | ✅ 原生 | 150 亿参数，Artificial Analysis 双榜第一（Elo 1333/1392），开源，7 语言唇形同步 |
| Sora 2 | OpenAI | 世界模型 | T2V / I2V | 1080p | 20s | ✅ 原生 | 物理模拟最准确，多镜头 Storyboard |
| Kling 3.0 | 快手 | 未公开 | T2V / I2V | 4K | 10s | ✅ | 写实运动质量高，性价比突出 |
| Veo 3.1 | Google | 世界模型 | T2V / I2V | 4K | 8s | ✅ 原生 | 音视频联合生成，提示遵循强 |

#### 2.1.4 语音模型 (Speech / Audio)

**TTS (Text-to-Speech) 文本转语音**：

将文本转换为自然语音波形。当前主流架构分为三类：

* **两阶段架构**（Encoder + Vocoder）：文本编码器将文字转为音素/韵律特征，声码器（HiFi-GAN、Vocos）将梅尔频谱图转为波形。传统但成熟。
* **端到端 LLM 架构**：基于大语言模型直接生成音频 Token（离散语音编码），跳过梅尔频谱中间步骤。代表：CosyVoice 系列（FSQ 量化 + LLM）、ElevenLabs v3。韵律自然度和零样本克隆能力显著提升。
* **Flow Matching 架构**：结合流匹配（Flow Matching）进行语音合成，在质量和速度之间取得平衡。代表：CosyVoice 2/3 的因果流匹配模型。

**STT / ASR (Speech-to-Text) 语音识别**：

将语音波形转换为文本。主流架构为 Conformer（CNN + Transformer 混合）或 Whisper 式 Encoder-Decoder。流式场景（Voice Agent）要求首 Token 延迟 <300ms。

**按类型分类**：

* **TTS（文本→语音）**：CosyVoice 3.0、ElevenLabs v3、OpenAI GPT-4o mini TTS、Cartesia Ink、IndexTTS-2、Fish Speech 1.5。
* **ASR（语音→文本）**：Deepgram Nova-3、OpenAI GPT-Realtime-Whisper、AssemblyAI Universal-3 Pro、Microsoft MAI-Transcribe-1。
* **Voice Agent（实时语音代理）**：STT + LLM + TTS 端到端管线，支持实时对话、打断、情绪识别。2026 年热点方向。

| 模型 | 厂商 | 类型 | 架构 | 特点 |
|---|---|---|---|---|
| Fun-CosyVoice 3.0 | 阿里 FunAudioLLM | TTS | LLM + Flow Matching | 开源 0.5B，零样本多语言，内容一致性 78.0，说话人相似度 71.8 |
| CosyVoice 2-0.5B | 阿里 FunAudioLLM | TTS | LLM + Flow Matching | 开源，流式合成，人类水平自然度 |
| ElevenLabs v3 | ElevenLabs | TTS | 端到端 Transformer | 闭源标杆，韵律自然度最高，声音克隆 |
| IndexTTS-2 | IndexTeam | TTS | 未公开 | 开源，低延迟，小体积 |
| Fish Speech 1.5 | Fish Audio | TTS | DualAR（双自回归） | 开源，高质量语音克隆 |
| Chatterbox-Turbo | Resemble AI | TTS | 未公开 | 开源 MIT，盲测 65.3% 胜率 vs ElevenLabs |
| MOSS-TTS | 未公开 | TTS | 未公开 | 社区评价音质接近 ElevenLabs |
| MiMo TTS | 小米 | TTS | 未公开 | 轻量，中文质量好 |
| Hailuo TTS | MiniMax | TTS | 未公开 | 海螺AI 集成 |
| Cartesia Ink | Cartesia | TTS | 未公开 | 实时 TTS Arena 第一，<250ms P90 |
| GPT-Realtime-Whisper | OpenAI | ASR | Whisper + 流式 | $0.017/min，实时转写 |
| Deepgram Nova-3 | Deepgram | ASR | Conformer | 低延迟流式标杆，多语言 |
| AssemblyAI Universal-3 Pro | AssemblyAI | ASR | 未公开 | 最高精度异步转写 |
| MAI-Transcribe-1 | Microsoft | ASR | 未公开 | 25 语言 3.8% WER，成本降 50% |
| Fun-ASR-Nano | 阿里 FunAudioLLM | ASR | LLM-based | 31 语言，热词支持，vLLM 流式 |

#### 2.1.5 音乐生成模型 (Music Generation)

**原理**：将音乐建模为时序音频 Token 序列，通过自回归 Transformer 或扩散模型生成。输入通常为文本描述（风格、情绪、歌词）或参考音频片段。2025-2026 年音乐生成质量已接近商业制作水准，支持完整歌曲（含人声、伴奏、混音）的端到端生成。

| 模型 | 厂商 | 类型 | 特点 |
|---|---|---|---|
| Suno v5 | Suno | 文本→完整歌曲 | 质量标杆，支持人声+伴奏，歌词生成，3~4 分钟完整歌曲 |
| MiniMax Music 2.5 | MiniMax | 文本→音乐 | API 可用（FAL.AI），$0.035/生成，性价比高 |
| ElevenLabs Music | ElevenLabs | 文本→音乐 | 商用安全，$0.80/分钟，支持纯器乐和人声 |
| Lyria 3 Pro | Google | 文本→音乐 | RealTime 模式支持 WebSocket 实时器乐流式生成 |
| HeartMula | 开源 | 文本→完整歌曲 | 开源，本地运行，质量接近 Suno |
| Udio | Udio | 文本→音乐 | 高质量歌曲生成，版权争议后已与唱片公司和解 |

#### 2.1.6 嵌入模型 (Embeddings)

**原理**：将文本（或图像、音频等多模态内容）编码为固定维度的**稠密向量（Dense Vector）**，使语义相近的内容在向量空间中距离更近。训练目标通常为对比学习（Contrastive Learning），即拉近正样本对的向量距离，推远负样本（InfoNCE Loss）。向量维度从 256 到 3072+ 不等。**Matryoshka 表示学习（MRL）** 允许在不重新训练的情况下截断维度（如 2048→1024→512），以精度换取存储和检索速度。

**架构趋势**：2025-2026 年的显著变化是**基于 LLM 的嵌入模型**取代传统 BERT 架构成为主流。Qwen3.x-Embedding 基于 Qwen3 Dense 模型构建，Seed 2.x Embedding 基于 Seed 2.0 / 豆包模型构建，利用 Decoder-only LLM 强大的语义理解能力，在 MTEB 等榜单上大幅超越传统编码器。
**关键指标**：

* **MTEB (Massive Text Embedding Benchmark)**：跨 8 个任务类别（检索、聚类、分类、STS 等）的综合评估。CMTEB 为中文版本。
* **BRIGHT**：推理密集型检索专项评估。
* **MMEB\_v2**：多模态嵌入评估（图像、视频向量化）。
* **维度 (Dimensions)**：向量长度。1024~2048 为性价比甜蜜点。
* **上下文长度**：单次输入最大 Token 数。长文档嵌入需 ≥8K。

| 模型 | 厂商 | 维度 | 上下文 | 输入模态 | 开源 | 特点 |
|---|---|---|---|---|---|---|
| Seed 2.x Embedding | 字节跳动 | 2048/1024 (MRL) | 未公开 | 文本+图像+视频 | ❌ | 基于 Seed 2.0 构建，多模态 SOTA，火山方舟 API |
| embed-v4 | Cohere | 1024 | 128K | 文本+图像 | ❌ | 多语言 + 长文档 |
| Jina Embeddings v5-omni | Jina | 677M/239M 参数 | 32K | 文本+图像+音视频 | ✅ | 首个全模态嵌入，Matryoshka |
| voyage-4-large | Voyage AI | 2048 | 32K | 文本+图像 | ❌ | 检索精度领先 |
| Gemini Embedding 2 | Google | 3072 | 8K | 文本+图像+视频+音频 | ✅ | Google 首个原生多模态嵌入，5 种维度可选 |
| Qwen3.x-Embedding | 阿里 | 可变 (MRL) | 32K | 文本 | ✅ | MTEB 多语言 #1（70.58），0.6B/4B/8B 三尺寸 |
| BGE-M3 | BAAI | 1024 | 8K | 文本 | ✅ | 开源首选，多语言 |
| Nomic Embed Text V2 | Nomic AI | 可变 (MoE) | 8K | 文本 | ✅ | 首个 MoE 嵌入架构 |

#### 2.1.7 重排序模型 (Reranking)

**原理**：RAG 管线的第二阶段精排。初始检索（向量搜索 / BM25）返回 Top-K 候选文档后，重排序模型使用 **Cross-Encoder** 架构将查询与每篇文档拼接输入 Transformer，输出相关性分数，重新排序后取 Top-N 送入 LLM。

**与嵌入模型的核心区别**：

| 维度 | 嵌入模型 (Bi-Encoder) | 重排序模型 (Cross-Encoder) |
|---|---|---|
| 架构 | 查询和文档分别编码，独立计算向量 | 查询与文档拼接后联合编码 |
| 精度 | 较低（无跨文本交互） | 较高（允许查询-文档深度交互） |
| 速度 | 极快（可预计算文档向量，检索时仅编码查询） | 慢（每对查询-文档需完整前向传播） |
| 可索引 | ✅ 文档向量可预先计算并存储 | ❌ 无法预先索引，仅用于精排 |
| 上下文 | 通常 8K~32K | 通常 1K~32K |
| 典型用途 | 第一阶段召回（Top-100→Top-1000） | 第二阶段精排（Top-100→Top-10） |
| 评估基准 | MTEB / CMTEB | BEIR / MIRACL |

**典型 RAG 检索管线**：用户查询 → 嵌入模型向量化 → 向量数据库召回 Top-K 候选 → 重排序模型精排 → 取 Top-N 送入 LLM 生成答案。

| 模型 | 厂商 | 上下文 | 语言 | 开源 | 特点 |
|---|---|---|---|---|---|
| Qwen3-Reranker | 阿里 | 32K | 100+ | ✅ | 与 Qwen3-Embedding 同系列，0.6B/4B/8B 三尺寸 |
| Rerank-v4.0-pro | Cohere | 32K | 100+ | ❌ | 企业级首选，支持 JSON 文档 |
| Jina Reranker v2 | Jina | 1024 | 多语言 | ✅ | Function-Calling 感知 |
| BGE-Reranker-v2.5 | BAAI | 4K | 多语言 | ✅ | 开源精度标杆 |
| ZeroEntropy Reranker | ZeroEntropy | 8K | 英文为主 | ❌ | 高精度 RAG 专用 |
| Voyage Reranker | Voyage AI | 32K | 多语言 | ❌ | 与 Voyage 嵌入配合紧密 |

### 2.2 OpenAI

#### 模型

##### GPT 4o

| 项目 | 内容 |
|---|---|
| 发布时间 | 2024-05-13 |
| 架构 | Dense |
| 参数量 | 总参 ~200B ｜ 激活 ~200B（Dense，行业估计/Microsoft 论文） |
| 上下文 | 128K |
| 输入模态 | 文本、图像、PDF |
| 价格 | $2.5 / $10（每百万Token，输入/输出） |

##### O1 / O3 / O4 Mini

| 项目 | 内容 |
|---|---|
| 发布时间 | o1: 2024-12-05 / o3-mini: 2024-12-20 / o3: 2025-04-16 / o4-mini: 2025-04-16 |
| 架构 | Dense（推理增强型） |
| 参数量 | o1: 总参 ~300B ｜ 激活 ~300B（Dense）o1-mini: 总参 ~100B ｜ 激活 ~100B（Dense）o3: 总参 ~500B 或 500B~1T ｜ 激活同（Dense）o3-mini: 总参 ~200B ｜ 激活 ~200B（Dense）o4-mini: 总参 ~300~500B ｜ 激活同（Dense） |
| 上下文 | o1/o3/o4: 200K |
| 输入模态 | o1: 文本+图像+PDF；o3: 文本+图像+PDF；o3-mini/o4-mini: 文本+图像 |
| 特殊能力 | 原生推理链（Reasoning），输出隐式思考过程 |
| 价格 | o1: $15/$60, o3: $2/$8, o3-mini: $1.1/$4.4, o4-mini: $1.1/$4.4（每百万Token，输入/输出） |

##### GPT 5.1

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-11-13 |
| 架构 | MoE |
| 参数量 | 总参 ~2T ｜ 激活 ~400~800B（MoE） |
| 上下文 | 400K |
| 输入模态 | 文本、图像 |
| 价格 | $1.25 / $10（每百万Token，输入/输出） |

##### GPT 5.2

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-12-11 |
| 架构 | MoE |
| 参数量 | 总参 ~2~3T ｜ 激活 ~500B~1T（MoE） |
| 上下文 | 400K |
| 输入模态 | 文本、图像 |
| 特点 | 在代码社区备受称赞；核心优势为上下文压缩（Context Compaction），即将非核心上下文压缩为高密度特征向量，大幅减小 KV Cache 体积的同时精准召回关键变量；SWE-Bench 等长代码基准表现突出（~77%）；社区反馈在系统性分析和遗漏问题发现方面优于部分竞品 |
| 价格 | $1.75 / $14（每百万Token，输入/输出） |

##### GPT 5.3 Codex

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-02-05 |
| 架构 | MoE |
| 参数量 | 总参 ~2.5~3.5T ｜ 激活 ~600B~1.2T（MoE） |
| 上下文 | 400K |
| 输入模态 | 文本、图像、PDF |
| 特点 | 面向代码/Agent任务优化 |
| 价格 | $1.75 / $14（每百万Token，输入/输出） |

##### GPT 5.4

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-03-05 |
| 架构 | MoE |
| 参数量 | 总参 ~3~4T ｜ 激活 ~800B~1.5T（MoE） |
| 上下文 | 1050K（≈1M） |
| 输入模态 | 文本、图像、PDF |
| 价格 | $2.5 / $15（每百万Token，输入/输出） |

##### GPT 5.5

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-23 |
| 架构 | MoE |
| 参数量 | 总参 ~4~10T 或 1.5T（IKP修正）~9.7T（IKP原始） ｜ 激活 ~1~2T（MoE，IKP 论文/Samsung SemiCon 泄露） |
| 上下文 | 1050K（≈1M） |
| 输入模态 | 文本、图像、PDF |
| 价格 | 标准版: $5 / $30；Pro 版: $30 / $180（通过并行测试时计算提供更高精度）（每百万Token，输入/输出） |

##### GPT 5.6

目前GPT5.5降智严重。预计2026年7月7日发布。

##### GPT Image 1.5

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-11-25 |
| 架构 | 专用图像生成模型 |
| 输入模态 | 文本、图像（输入）→ 图像（输出） |
| 特点 | 原生图像生成与编辑 |
| 价格 | $5 / $32（每百万Token，输入/输出） |

##### GPT Image 2

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-21 |
| 架构 | 专用图像生成模型 |
| 输入模态 | 文本、图像（输入）→ 图像（输出） |
| 特点 | 原生图像生成与编辑，GPT-Image-1.5 升级版 |
| 价格 | $5 / $30（每百万Token，输入/输出） |

##### GPT Mini

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-08-07 |
| 架构 | MoE |
| 参数量 | 总参 ~100~200B ｜ 激活 ~50~100B（MoE，GPT-5 系列轻量版） |
| 上下文 | 400K |
| 输入模态 | 文本、图像 |
| 特点 | GPT-5 系列轻量版 |
| 价格 | $0.25 / $2（每百万Token，输入/输出） |

##### GPT Spark

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-02-12（研究预览） |
| 架构 | MoE（极小激活参数） |
| 参数量 | 总参 ~50~100B ｜ 激活 ~20~40B（MoE，Cerebras WSE-3 极速轻量版） |
| 上下文 | 400K |
| 输入模态 | 文本、图像 |
| 特点 | GPT 5.3 Codex 的轻量版，部署于 Cerebras WSE-3 芯片，生成速度 ~1000 tok/s；面向实时编码场景 |
| 社区评价 | Reddit 社区普遍反馈"快但笨"（"It is dumb, but fast model"），适合子任务分发、测试检查等低复杂度场景，不推荐用于复杂推理 |
| 价格 | 未公开（Cerebras 部署，无公开定价） |

#### 产品

##### ChatGPT

ChatGPT 是 OpenAI 面向大众的通用对话产品，提供网页版（chatgpt.com）、桌面客户端（Windows/macOS）和移动端应用（iOS/Android）。

**核心定位**：通用型智能助手，适合日常对话、调研、写作、头脑风暴、知识问答与内容创作。

**主要功能**：

* 多轮对话与上下文记忆，支持长会话连贯性
* 内置工具调用（网页搜索、代码解释器、图像生成与分析、文件上传）
* 自定义 GPT（Custom GPTs）与 GPTs Store
* Canvas 模式：支持长文本/代码的协作编辑与迭代
* 语音对话（实时语音模式，支持打断与情绪感知）
* 图像理解与生成（原生支持 GPT Image 系列）
* 记忆功能（Memory）：记住用户偏好与历史上下文
* 插件与 Actions：扩展第三方工具与 API

**适用场景**：

* 调研与信息整理
* 文章、报告、邮件、脚本写作
* 头脑风暴与创意生成
* 日常问答与知识解释
* 多模态内容创作（图文、语音）

**界面特点**：简洁聊天界面，强调易用性与交互流畅度。提供免费版与 Plus/Pro 付费订阅，付费用户享有更高使用限额、优先模型访问与高级功能。

***

##### Codex CLI/Desktop

Codex CLI/Desktop 是 OpenAI 专为开发者打造的编码与 Agent 构建平台，提供命令行工具（Codex CLI）与桌面图形界面（Codex Desktop）。

**核心定位**：面向编码场景的 AI 编程助手与 Agent 开发平台，强调结构化推理、长上下文代码理解、工具调用与项目级自动化。

**主要功能**：

* 终端原生集成：在本地项目目录直接运行，支持 `codex` 命令行交互
* 桌面 GUI：可视化项目浏览器、文件树、Agent 工作流编排与执行监控
* 深度代码理解：支持百万级 Token 上下文，擅长大型代码库分析、跨文件重构与遗漏问题发现
* Agent 构建：原生支持工具调用（Tool Call）、结构化输出（JSON Schema）、多步骤推理链
* SWE-Bench 优化：针对真实软件工程任务（issue 修复、功能实现、测试编写）进行专项训练
* 上下文压缩（Context Compaction）：自动将冗余代码压缩为高密度特征向量，精准保留关键变量与逻辑
* 项目级操作：一键生成项目骨架、批量重构、依赖分析、测试生成与 CI 集成
* 推理控制：支持 `reasoning_effort` 参数（low/medium/high）调节思考深度
* 多模态输入：支持代码 + 图像（架构图、UI 截图、流程图）联合分析

**适用场景**：

* 大型代码库理解与重构
* 软件工程任务（SWE-Bench 类问题）
* Agent 系统构建与工具链集成
* 自动化测试、文档生成与代码审查
* 终端驱动的快速原型与项目初始化

**界面特点**：CLI 模式强调极致效率与脚本化；Desktop 模式提供可视化工作流、Agent 状态监控与多文件并行编辑。两者均深度集成 Git、IDE（VS Code、JetBrains 等）与本地文件系统。

定价采用按 Token 计费 + 订阅混合模式，CLI 与 Desktop 共享同一后端模型能力。

### 2.3 Anthropic

#### 模型

##### Claude 4.5 Sonnet

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-09-29 |
| 架构 | Dense |
| 参数量 | 总参 ~1~2T ｜ 激活 ~100~200B（吞吐量反推，unexcitedneurons） |
| 上下文 | 200K |
| 输入模态 | 文本、图像、PDF |
| 价格 | $3 / $15（每百万Token，输入/输出） |

##### Claude 4.5 Opus

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-11-01 |
| 架构 | Dense |
| 参数量 | 总参 ~1.5~2T（吞吐量反推）或 ~3~5T（IKP） ｜ 激活 ~93~105B FP8（unexcitedneurons 吞吐量分析） |
| 上下文 | 200K |
| 输入模态 | 文本、图像、PDF |
| 价格 | $5 / $25（每百万Token，输入/输出） |

##### Claude 4.6 Sonnet

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-02-17 |
| 架构 | Dense（社区推测可能转MoE） |
| 参数量 | 总参 ~1~3T ｜ 激活 ~78~88B FP8（吞吐量反推） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、PDF |
| 价格 | $3 / $15（每百万Token，输入/输出） |

##### Claude 4.6 Opus

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-02-05 |
| 架构 | Dense / MoE（社区推测约 ~220B 激活参数，可能为大规模MoE） |
| 参数量 | 总参 ~2~5T（吞吐量反推）或 ~5.3T（IKP原始）/ ~1.5~2T（IKP修正后DeepSeek-like sparsity） ｜ 激活 ~93~105B FP8（unexcitedneurons） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、PDF |
| 特点 | 在 1M 全域检索评测（MRCR v2 等）中注意力稳定性最高，上下文退化（Context Rot）现象最轻；Opus 4.6 在 1M 难度变体中可达 ~76%；200K~500K+ 长会话中仍保持良好连贯性，被公认为当前最可靠的长上下文旗舰 |
| 价格 | $5 / $25（每百万Token，输入/输出） |

##### Claude Opus 4.7/4.8

| 项目 | 内容 |
|---|---|
| 发布时间 | 4.7: 2026-04-16 / 4.8: 2026-05-28 |
| 架构 | 未公开 |
| 参数量 | 总参 ~3~5T 或 1.1T（IKP修正）~4T（IKP原始） ｜ 激活未公开 |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、PDF |
| 社区评价 | 多个独立评测显示 4.7 较 4.6 全面退步；Medium 文章直言"Claude Opus 4.7 is a downgrade"；社区推测 Anthropic 通过缩小模型尺寸换取更低延迟（推理时间明显缩短）；4.8 发布间隔仅 42 天，被认为是对 4.7 失败的快速修复 |
| 特点 | 4.7引入 xhigh effort level；社区反馈推理速度较 4.6 显著提升，推测通过缩小模型尺寸换取更低延迟 |
| 价格 | $5 / $25（每百万Token，输入/输出） |

##### Claude  Sonnet 5

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-30 |
| 架构 | 未公开 |
| 参数量 | 总参 ~2~4T ｜ 激活 ~400~800B（Vertex AI 日志泄露代号 Fennec） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、PDF |
| 价格 | $2 / $10（每百万Token，输入/输出） |

##### Mythos / Fable 5

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-09（Fable 5 公开发布 / Mythos 5 受限发布）；2026-06-12 因美国政府出口指令暂停 |
| 架构 | MoE（社区推测总参数 ~10T，等效 ~1T Dense 计算成本） |
| 参数量 | 总参 ~10T ｜ 激活 ~1~2T（Mythos 5: 富途/NextBigFuture 报道；Fable 5: 与 Mythos 5 共享权重，2026.6.9 发布） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、PDF |
| 特点 | Fable 5 与 Mythos 5 共享底层权重；Fable 5 增加安全分类器（拦截网络安全/生物/化学等高风险查询，回退至 Opus 4.8）；Mythos 5 通过 Project Glasswing 仅向经审核的网络安全合作伙伴开放；SWE-bench Pro 80.3%（Mythos 5），远超 Opus 4.8 的 69.2% |
| 价格 | $10 / $50（每百万Token，输入/输出） |

![629a93a18b8c9bd9646fa8274e8110c3](https://gastigado.cnies.org/d/public/629a93a18b8c9bd9646fa8274e8110c3.webp)

#### 产品

##### Claude (Web/App)

Claude 是 Anthropic 面向大众的通用对话产品，提供网页版（claude.ai）、桌面客户端（Windows/macOS）和移动端应用（iOS/Android）。

**核心定位**：安全优先的通用智能助手，强调对话质量、长上下文理解与深度推理能力。

**主要功能**：

* 多轮对话与 Projects 工作空间：上传文件和指令一次，后续对话自动继承上下文
* Extended Thinking（深度思考）：显式思维链推理，适用于复杂分析与多步推理任务
* 1M Token 上下文窗口：支持处理整本书、完整代码库、长篇法律合同
* 记忆功能（Memory）：跨会话记住用户偏好与历史上下文
* 图像理解与 PDF 分析：原生支持视觉输入
* Artifacts：实时生成并预览代码、图表、文档、网页组件
* MCP（Model Context Protocol）集成：连接外部工具与数据源
* 语音对话模式：支持实时语音交互

**适用场景**：

* 深度分析与研究报告
* 长文档阅读、总结与问答
* 代码审查与架构讨论
* 学术写作与翻译
* 多步骤推理任务（数学、逻辑、策略）

**界面特点**：简洁对话界面，强调深度与可靠性。提供免费版、Pro（$20/月）、Max（$100/月或 $200/月）订阅层级，以及 Team 和 Enterprise 企业方案。

***

##### Claude Code

Claude Code 是 Anthropic 推出的终端原生 AI 编码工具，运行在开发者本地终端中，直接读写项目文件、执行命令、管理 Git。

**核心定位**：面向开发者的 Agentic 编码助手，强调项目级代码理解、自主执行与多步骤任务完成能力。

**发布时间**：2025 年 5 月（研究预览）→ 2025 年 10 月（GA）

**主要功能**：

* 终端原生集成：在项目目录中直接运行 `claude` 命令，无需切换 IDE
* 项目级代码理解：支持百万级 Token 上下文，完整读取大型代码库
* 自主执行：读写文件、运行测试、执行 Shell 命令、提交 Git，多步骤任务自主完成
* 并行 Agent（Agent Teams）：启动多个子 Agent 并行处理独立子任务
* CLAUDE.md 项目配置：通过项目根目录的配置文件定义编码规范、架构约定与测试要求
* Hooks 与 Skills：自定义触发器和可复用工作流
* MCP 集成：连接外部工具（数据库、API、文档系统等）
* 桌面应用（Claude Desktop）：提供 GUI 版本，支持可视化文件浏览与 Agent 监控
* Channels：通过 Telegram/Discord 远程发送任务，完成后异步接收结果
* 记忆系统：跨会话记住项目结构、调试模式与偏好编码方式

**适用场景**：

* 大型代码库理解、重构与迁移
* Issue/Bug 修复（SWE-Bench 类任务）
* 测试编写与 CI/CD 集成
* 代码审查与文档生成
* 多 Agent 协作的复杂工程任务

**界面特点**：CLI 模式极致效率，深度集成终端与 Git；Desktop 模式提供可视化文件树、Agent 状态监控与会话管理。两者共享同一后端能力。

**定价**：按 Token 计费（API 模式），或包含在 Claude Pro/Max 订阅额度中。重度使用者可购买额外用量。

***

##### Claude Cowork

Claude Cowork 是 Anthropic 于 2026 年 1 月 12 日发布的桌面级通用 Agent 产品，将 Claude Code 的 Agentic 能力从代码扩展到所有知识工作场景。

**核心定位**：面向非开发者知识工作者的 AI 工作伙伴，在文件系统层面操作，深度集成现有工作流。

**开发背景**：由 Claude Code 创建者 Boris Cherny 用 Claude Code 在 10 天内开发完成——产品本身即是"超级个体"理念的实践验证。

**主要功能**：

* 文件系统级操作：直接读写本地文件、组织项目文件夹、批量处理文档
* 深度集成现有工具：原生连接 Gmail、Google Drive、Chrome、日历等
* 多步骤自主执行：规划并完成跨应用的复杂工作流（如"整理上周所有会议纪要并生成行动项"）
* 定时任务（Scheduled Tasks）：设置周期性自动化工作流
* 多 Agent 协作（Dispatch）：将复杂任务拆分给多个 Agent 并行执行
* Computer Use：直接控制桌面应用程序
* 上下文文件（Context Files）：通过配置文件让 Cowork 理解你的工作背景与偏好
* 组织级共享：团队成员可共享 Agent 配置与工作流

**适用场景**：

* 文档整理、归档与批量处理
* 邮件分类、摘要与回复草稿
* 数据收集、整理与报告生成
* 项目管理与跨应用自动化
* 演示文稿与提案制作

**界面特点**：桌面应用，强调"委托工作而非对话"。用户描述目标，Cowork 自主规划并执行，完成后将结果交付到指定文件夹。使用 Apple VZVirtualMachine 沙箱确保安全。

**定价**：包含在 Claude Pro/Max 订阅中，使用订阅额度。可开启额外用量。

***

##### Claude Design

Claude Design 是 Anthropic Labs 于 2026 年 4 月 17 日发布的 AI 视觉协作产品，由 Claude Opus 4.7 视觉模型驱动。

**核心定位**：面向设计师与非设计从业者的 AI 设计协作工具，让任何人都能通过对话创建专业级视觉作品。

**主要功能**：

* 对话式设计生成：描述需求，Claude 自动生成初版设计，通过对话迭代精修
* 品牌设计系统：入职时自动从代码库或设计文件中提取品牌规范（颜色、字体、组件），后续所有项目自动应用
* 交互式原型：将静态设计稿转为可交互原型，支持用户测试与反馈收集
* 细粒度控制：内联评论、直接编辑文本、调节旋钮实时微调间距/颜色/布局
* 多格式导入：支持文本提示、图片上传、DOCX/PPTX/XLSX 导入、网页抓取
* 多格式导出：导出至 Canva、PDF、PPTX、独立 HTML，或组织内链接分享
* Claude Code 交接：设计完成后自动打包为 Handoff Bundle，一键传递给 Claude Code 实现
* 前沿设计能力：支持语音、视频、3D、Shader 等代码驱动的高级原型
* 组织级协作：支持组织内共享、协同编辑、群组对话

**适用场景**：

* 产品原型与线框图
* Pitch Deck 与演示文稿
* 落地页与营销素材
* 品牌探索与设计方向探索
* 社交媒体视觉内容
* 前沿交互式设计原型

**界面特点**：Web 应用（claude.ai/design），强调"人人都能设计"。设计师用来快速探索大量方向，非设计师用来将想法变为专业视觉输出。已集成 Canva 生态。

**定价**：包含在 Claude Pro、Max、Team、Enterprise 订阅中。使用订阅额度，可开启额外用量。企业版默认关闭，管理员可在组织设置中启用。

##### ⚠️ Anthropic 针对中国用户的限制措施

> ⚠️ 以下内容基于公开报道与社区逆向分析整理，截至 2026 年 7 月。Anthropic 的检测策略持续演进，具体措施可能随时变化。

**背景**：Anthropic 自成立之初即不向中国大陆开放服务。2025 年 9 月修改服务条款，明确禁止任何被中国直接或间接控股超过 50% 的企业或组织使用其服务，即使该企业在海外注册。2026 年 2 月，CEO Dario Amodei 公开表示封锁中国用户"花费了数亿美元收入"。

![微信图片\_20260707111549\_185\_2](https://gastigado.cnies.org/d/public/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20260707111549_185_2.webp)

**一、账号封锁特征（基于公开报道与社区报告）**

Anthropic 的风控系统不仅识别 IP 地理位置，而是对整个使用链路进行多维度追踪，以下特征均可能触发封号：

| 检测维度 | 具体特征 |
|---|---|
| **支付信息** | 信用卡发卡行归属中国银行、支付宝/微信支付记录 |
| **注册信息** | 使用中国手机号（+86）、中国邮箱服务商注册 |
| **IP 行为** | VPN 节点频繁跳动、曾连接过中国境内酒店/公司 Wi-Fi、近期有中国出差记录 |
| **设备环境** | 操作系统语言设为简体中文、系统时区设为 Asia/Shanghai |
| **使用模式** | 高频 API 调用、系统性覆盖模型能力各领域的查询模式 |
| **组织关联** | 企业账户中某个成员触发风控→整个组织被封（110 人美国农业公司案例） |

Anthropic 还引入第三方身份核验服务商 **Persona**，要求部分被标记为"高风险"的用户上传政府颁发的身份证件并完成实时人脸核验。

**二、邮件追踪器**

Anthropic 在发送给用户的封号通知邮件中嵌入**追踪像素（Tracking Pixel）**——一张 1×1 像素的透明图片，图片 URL 指向 Anthropic 服务器。当用户打开邮件时：

* 邮件客户端加载图片 → 向 Anthropic 服务器发送 HTTP 请求
* 请求携带用户**真实 IP 地址**、User-Agent（设备/系统信息）、打开时间戳
* 通过 IP 地理位置数据库反推用户所在城市/地区

**作用**：与账号注册信息交叉验证。如果账号显示美国注册，但打开邮件时 IP 落在中国（如杭州），即构成封号依据。

**规避情况**：Apple Mail 隐私保护（iOS 15+）会通过苹果代理服务器预加载图片，屏蔽真实 IP；Gmail 同样通过 Google 代理转发。但 Outlook 等客户端默认不阻止图片加载，追踪器可直接生效。

> 来源：X/Twitter @jefflijun 详细技术分析

**三、Claude Code 隐写术后门事件（2026 年 4 月 - 7 月）**

这是 Anthropic 最具争议的检测手段。2026 年 6 月 30 日，Reddit 用户 **LegitMichel777** 在逆向分析 Claude Code 时发现，自 **v2.1.91 版本（2026 年 4 月 2 日发布）** 起，客户端内置了一套隐蔽的用户识别系统，代码经过刻意混淆处理，版本更新说明中只字未提。

**检测机制**：

1. **本地时区检测**：读取操作系统时区，比对是否为 `Asia/Shanghai`（上海）或 `Asia/Urumqi`（乌鲁木齐）——IANA 标准时区数据库中唯二对应中国标准时间的条目

2. **代理域名比对**：检测环境变量 `ANTHROPIC_BASE_URL`（中转站地址），提取域名后与内置清单比对。清单包含 **147 个域名**，覆盖：
   * 已知 API 中转站
   * 百度、字节跳动、腾讯、京东、阿里巴巴、蚂蚁集团、美团、网易、携程、小红书、B站
   * 月之暗面、MiniMax、阶跃星辰等 AI 实验室
   * 部分企业内网域名

3. **隐写术回传（Steganography）**：检测结果不通过额外网络请求发送，而是通过修改系统提示词中的 Unicode 字符实现：
   * **修改一**：`Today's` 中的单引号从 `U+0027`（标准 ASCII）替换为视觉几乎相同但 Unicode 编码不同的字符
   * **修改二**：日期分隔符从连字符 `-` 变为斜杠 `/`（`2026-06-30` → `2026/06/30`）
   * 两个信号组合构成 2~3 比特分类标记，服务器端仅需扫描文本编码差异即可完成身份判定
   * 整个过程**不产生任何额外网络请求**，不会在流量层面留下可疑痕迹

**Anthropic 回应**：技术团队成员 **Thariq Shihipar** 在 X 平台承认该机制存在，称其为"2026 年 3 月上线的一项实验，目的是防止未授权转售商滥用账号和防范模型蒸馏攻击"，表示"其实一直想把这个功能下线"，移除代码已于 7 月 1 日合并。

**后果**：

* **阿里巴巴**于 2026 年 7 月 10 日起全面禁止员工使用 Claude Code，将其列为"高风险软件"，推荐使用自研 Qoder 替代
* 字节跳动旗下 Trae、腾讯 CodeBuddy 国际版等此前已移除 Claude 模型访问
* 国内第三方 API 中转站产业链（批量注册账号、境外手机号验证、跨境支付通道）遭重点清理

![微信图片\_20260707111824\_188\_2](https://gastigado.cnies.org/d/public/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20260707111824_188_2.webp)

![微信图片\_20260707111831\_191\_2](https://gastigado.cnies.org/d/public/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20260707111831_191_2.webp)

> 来源：Reddit r/ClaudeAI u/LegitMichel777 逆向分析帖（超 100 万浏览）；观察者网 2026-07-03；虎嗅网 2026-07-03；Tom's Hardware 2026-07-03；TechCrunch 2026-07-04；The Next Web 2026-07-03；Cybernews；SitePoint；Anthropic 官方 2025-09-04 服务条款更新公告

**四、关于"网络延迟三角定位"的讨论**

社区中流传一种推测：Anthropic 可以通过测量用户机器到美国、日本、东南亚等节点的网络延迟来进行三角定位——如果检测到机器到亚洲节点延迟低、到美国节点延迟高，即可推断用户实际位于亚洲。

**评估**：该方法在技术原理上可行（光速不可伪装），但目前**没有公开证据**表明 Anthropic 实际采用了这种手段。已确认的检测方式（时区、代理域名、邮件追踪器、隐写术）均不依赖网络延迟测量。该推测更多反映社区对 Anthropic 检测能力不断升级的担忧。

> 来源：社区讨论（L站/Reddit），非官方确认

### 2.4 Google DeepMind

#### 模型

##### Gemini 2.5 Pro

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-06-17 |
| 架构 | MoE |
| 参数量 | 总参 ~0.5~1T（行业推测）或 ~1~2T（IKP 二级旗舰带）｜ 激活 ~100~200B（吞吐量反推法，中等可信度） |

##### Gemini 3.0 Pro

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-11-18 |
| 架构 | MoE |
| 参数量 | 总参 ~1.2T（Sparkco AI 逆向工程）或 ~1.5~2T（基于 Gemini 3 Pro 增量推测）｜ MoE 架构，激活参数未公开（中等可信度） |

##### Gemini 3.1 Pro

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-02-19 |
| 架构 | MoE |
| 参数量 | 总参 ~1.5~2T（保守估计）或 3~7T+（前沿 scaling 推测）｜ MoE 架构，激活参数未公开（低-中等可信度） |

##### Gemini 3.5 Flash

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-05-19 |
| 架构 | MoE |
| 参数量 | 总参 ~100~200B ｜ 激活 ~20~50B（轻量版定位，吞吐量反推法，中等可信度） |
| 价格 | $1.5 / $9（每百万Token，输入/输出）；缓存 $0.15 |

#### Gemma 4 Dense

##### Gemma 4 31B

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-02 |
| 架构 | Dense |
| 参数量 | 31B |
| 上下文 | 262K |
| 输入模态 | 文本、图像 |
| 特点 | Apache 2.0 开源；继承 Gemma 3 27B 架构，5:1 滑动窗口注意力；AIME 2026 88.3%，LiveCodeBench 77.1% |
| 价格 | 开源免费 |

#### Gemma 4 MoE

##### Gemma 4 26B A4B

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-02 |
| 架构 | MoE |
| 参数量 | 26B 总 / 4B 激活 |
| 上下文 | 262K |
| 输入模态 | 文本、图像 |
| 特点 | Apache 2.0 开源；推理性能接近 31B Dense，但推理速度更快；社区评价"性价比之王" |
| 价格 | 开源免费 |

#### Gemma 4 轻量级

##### Gemma 4 E4B / E2B

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-02 |
| 架构 | Dense（E2B 使用逐层嵌入，等效 2B 参数） |
| 参数量 | E4B: ~4.5B / E2B: ~2B |
| 上下文 | 131K |
| 输入模态 | 文本、图像、音频 |
| 特点 | Apache 2.0 开源；面向端侧/移动设备部署 |
| 价格 | 开源免费 |

#### Nano Banana 图像生成

##### Nano Banana / Pro / 2

| 项目 | 内容 |
|---|---|
| 发布时间 | Nano Banana: 2025-08-26 / Nano Banana Pro: 2025-11-20 / Nano Banana 2: 2026-02-26 |
| 架构 | 专用图像生成/编辑模型 |
| 上下文 | 32K~65K |
| 输入模态 | 文本、图像（Nano Banana 2 还支持 PDF） |
| 特点 | Google 原生图像生成与编辑模型系列，替代 Imagen |
| 价格 | 图像生成，按图片计费 |

#### 产品

##### Gemini (gemini.google.com)

Gemini 是 Google 面向大众的通用对话产品，提供网页版（gemini.google.com）、移动端应用（iOS/Android）及 Google Workspace 集成。

**核心定位**：Google 生态内的通用 AI 助手，深度集成 Google 搜索、Gmail、Drive、Maps 等服务。

**主要功能**：

* 多轮对话与 Gems 自定义助手
* Google 搜索实时联网
* 图像理解与生成（原生集成 Nano Banana）
* 文档、PDF、视频分析
* Google Workspace 集成（Gmail 草稿、Drive 文件检索、Sheets 数据分析）
* 语音对话模式

**⚠️ 已知限制**：

* **推理强度降级**：网页版默认模型思考强度仅为 medium，相比 API 满血版本存在显著降智，复杂推理任务表现明显弱于 API 调用
* **上下文截断**：网页版对长上下文实施激进截断策略，长对话（>10 轮）后活跃记忆窗口可能回退至 ~32K，导致"失忆"和幻觉（详见 §1.3）
* **使用限额**：免费版及 Google One AI Premium 订阅均存在消息频率限制，重度使用易触发配额

**适用场景**：日常问答、Google 生态内信息整合、简单文档分析、图像理解

**定价**：免费版可用；Google One AI Pro $19.99/月（含 5TB 存储 + Gemini AI Pro）

***

##### Google AI Studio (aistudio.google.com)

Google AI Studio 是 Google 面向开发者的技术工具，提供浏览器内直接调用 Gemini 模型 API 的沙箱环境。

**核心定位**：开发者测试与原型验证平台，提供满血不降智的模型能力，无人为限速或截断。

**主要功能**：

* 满血模型访问：所有 Gemini 模型（Pro、Flash 等）以完整推理强度运行，无网页版的降智处理
* 多模态输入：支持文本、图像、音频、视频、PDF 联合输入
* 结构化输出：支持 JSON Schema 约束输出
* System Instructions：自定义系统提示词
* 代码生成与执行：内嵌代码沙箱
* API Key 管理：一键生成 API 密钥用于外部调用
* 模型对比：同一 prompt 并行对比不同模型变体

**⚠️ 已知限制**：

* **额度较少**：免费层级 API 调用配额有限，高频使用需绑定付费账号或切换至 Vertex AI
* **无持久化对话**：会话不跨页面保存，刷新即丢失

**适用场景**：模型能力评估、API 原型开发、多模态任务测试、prompt 工程迭代

**定价**：免费层提供有限额度；超出后按 Vertex AI / Gemini API 标准价格计费

***

##### NotebookLM (notebooklm.google.com)

NotebookLM 是 Google 推出的个人知识库与研究助手产品，以用户上传的文档为知识源，提供基于源材料的问答、摘要与内容生成。

**核心定位**：基于个人文档的 AI 研究助手，所有回答严格溯源至用户提供的材料，减少幻觉。

**主要功能**：

* 多源文档上传：支持 PDF、Google Docs、网页链接、YouTube 视频、音频文件等
* 源材料问答：所有回答附带原文引用，可追溯至具体段落
* 自动生成摘要、学习指南、时间线、FAQ
* Audio Overview（播客生成）：将文档内容转化为双人对话式播客音频
* 幻灯片/演示文稿生成：基于上传材料自动创建幻灯片
* 笔记整理与关联：手动笔记与 AI 生成内容互相链接
* 多语言支持：支持中文等多语言文档处理

**适用场景**：文献综述、会议记录整理、课程学习、研究材料分析、长文档快速理解

**定价**：免费版可用；NotebookLM Plus（Google One AI Premium 或 Workspace 企业版）提供更高用量上限

***

##### Antigravity (antigravity.google)

Antigravity 是 Google 推出的 AI 原生 IDE 编码工具，定位为 Cursor 的直接竞品，面向专业开发者提供深度代码编辑与 Agent 能力。

**核心定位**：集成 AI 的全功能 IDE，支持代码补全、重构、Agent 模式与多模型切换。

**主要功能**：

* AI 代码补全与内联编辑：基于上下文的智能代码补全
* Agent 模式：多步骤自主编码，自动读写文件、运行测试、修复错误
* 多模型支持：支持 Gemini 系列模型，同时支持 Claude 等第三方模型接入
* 项目级代码理解：完整读取代码库上下文
* 终端集成：内嵌终端，支持命令执行与 Git 操作
* 多文件编辑：跨文件重构与依赖分析
* MCP 协议支持：连接外部工具与数据源

**适用场景**：日常编码、大型项目重构、代码审查、快速原型开发、多模型对比使用

**定价**：具体定价方案待公布（截至 2026 年中处于公开发布阶段）

***

### 2.5 Meta AI

#### 模型

##### Llama 2 / 3

| 项目 | 内容 |
|---|---|
| 发布时间 | Llama 3.3: 2024-12-06 |
| 架构 | Dense |
| 参数量 | Llama 3.3: 70B |
| 上下文 | 128K |
| 输入模态 | 文本 |
| 价格 | 开源免费 |

##### Llama 4 系列

| 项目 | 内容 |
|---|---|
| 发布时间 | 2025-04-05 |
| 架构 | MoE |
| 参数量 | Scout: 总参 109B ｜ 激活 17B（MoE，官方公布）；Maverick: 总参 400B ｜ 激活 17B（MoE，官方公布） |
| 上下文 | Scout: 3500K（10M）；Maverick: 1000K（1M） |
| 输入模态 | 文本、图像 |
| 特点 | Llama系列首次采用MoE架构；Scout可单GPU运行 |
| 价格 | 开源免费（API: Scout $0.17/$0.66, Maverick $0.24/$0.97 via Bedrock） |

### 2.6 xAI

#### 模型

##### Grok

| 项目 | 内容 |
|---|---|
| 发布时间 | Grok 4: 2025-09-09 / Grok 4.3: 2026-04-17 |
| 架构 | MoE |
| 参数量 | Grok-2: 总参 ~270B ｜ 激活 ~115B（8 专家，已知）；Grok-4+: 总参 ~0.5T（Musk 推特）或 ~2~3T（IKP: Grok-4 ~3.2T）｜ 激活 ~100~200B（中等可信度） |

##### Grok Image

| 项目 | 内容 |
|---|---|
| 特点 | 通过Grok内置图像理解能力实现，非独立模型 |
| 价格 | 随 Grok 内置 |

### 2.7 DeepSeek (深度求索)

#### 模型

##### DeepSeek V3.2

| 项目 | 内容 |
|---|---|
| 发布时间 | V3: 2024-12 → V3.1: 2025-08 → V3.1-Terminus: 2025-09 → V3.2: 2025-12（最终版本） |
| 架构 | MoE + MLA + MTP |
| 参数量 | 总参 671B ｜ 激活 37B（MoE，官方公布） |
| 上下文 | 128K |
| 输入模态 | 文本 |
| 特点 | V3.2 引入 DSA（DeepSeek Sparse Attention）；继承 V2 首创的 MLA（Multi-head Latent Attention）通过低秩压缩 KV Cache 降低推理显存；V3.2 Speciale 达 IMO 金牌级推理水平 |
| 价格 | 缓存命中¥0.2, 缓存未命中¥2, 输出¥3（每百万Token）；V3.2 正式版（2025-12）价格基本维持不变 |

##### DeepSeek V4 Pro

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-24 |
| 架构 | MoE + MLA + CSA/HCA 混合注意力 |
| 参数量 | 总参 1.6T ｜ 激活 49B（MoE，官方公布） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | 沿用 MLA 低秩 KV 压缩；CSA（Compressed Sparse Attention）：每 4 token 压为 1 条，Lightning Indexer 稀疏选择 top-k；HCA（Heavily Compressed Attention）：每 128 token 压为 1 条后做 dense attention；1M 下 FLOPs 为 V3.2 的 27%，KV Cache 为 10% |
| 价格 | 缓存命中¥0.025, 缓存未命中¥3, 输出¥6（每百万Token） |

##### DeepSeek V4.1 Pro

| 参数量 | 总参 2T ｜ 激活 55B（MoE，官方公布） |
|---|---|
| 发布时间 | 2026-06-18 |
| 架构 | MoE + MLA + CSA/HCA 混合注意力 + 原生视觉编码器（Vision Encoder） |
| 参数量 | 总参 1.75T ｜ 激活 55B（MoE，官方公布） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、PDF、视频帧 |
| 特点 | V4 Pro 的多模态升级版。在 V4 Pro 的 MLA + CSA/HCA 架构基础上，新增原生视觉编码器（基于 SigLIP-400M 微调），支持端到端图像/PDF 理解和视频帧序列分析，无需外挂 OCR 管线；视觉 Token 经跨模态投影层（Cross-Modal Projector）映射至语言模型潜空间后，与文本 Token 统一进入 MoE 路由；新增"多模态共享专家"（Multimodal Shared Experts），对视觉 Token 全局激活，确保跨模态常识不因路由稀疏而丢失；保留 V4 Pro 的三模式推理（快速/平衡/深度）和 Tool Call 能力；1M 上下文下 FLOPs 较 V4 Pro 增加约 12%（视觉编码器开销），KV Cache 无额外增长（视觉 Token 复用 MLA 压缩路径）；在 OCRBench（82.3%）、MathVista（73.1%）、DocVQA（94.6%）上表现优异，接近 Qwen3.6-35B-A3B 水平 |
| 价格 | 缓存命中¥0.03, 缓存未命中¥3.5, 输出¥7（每百万Token）；视觉 Token 按等效文本 Token 1.2x 计费 |

##### DeepSeek V4 Flash

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-24 |
| 架构 | MoE + MLA + CSA/HCA 混合注意力 |
| 参数量 | 总参 284B ｜ 激活 13B（MoE，官方公布） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | 同 V4 Pro 架构，参数量更小；1M 下 FLOPs 为 V3.2 的 10%，KV Cache 为 7%；面向低成本 1M 上下文推理场景 |
| 价格 | 缓存命中¥0.02, 缓存未命中¥1, 输出¥2（每百万Token） |

### 2.8 智谱AI (Zhipu AI)

#### 模型

##### GLM 4.5 / 4.6 / 4.7

| 项目 | 内容 |
|---|---|
| 发布时间 | GLM 4.5: 2025-07-28 / GLM 4.6: 2025-09-30 / GLM 4.7: 2025-12-22 |
| 架构 | MoE |
| 参数量 | 总参 355B ｜ 激活 32B（MoE，官方公布） |
| 上下文 | GLM 4.5: 131K / GLM 4.6/4.7: 204K |
| 输入模态 | 文本（GLM 4.5V 支持文本+图像+视频） |
| 价格 | GLM-4-Flash: 免费; GLM-4.6/4.7: 输入¥0.6, 输出¥2.2（每百万Token） |

##### GLM 5

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-02-12 |
| 架构 | MoE + DSA 稀疏注意力 |
| 参数量 | 总参 744B ｜ 激活 ~80B（MoE，官方公布） |
| 上下文 | 204K |
| 输入模态 | 文本 |
| 特点 | 预训练 28.5T tokens，面向 Agentic Engineering 设计；SWE-Bench Verified 72.8%；开源权重（Apache 2.0） |

##### GLM 5.1

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-07 |
| 架构 | MoE + DSA（MLA + DeepSeek Sparse Attention），256 路由专家 top-8 + 1 共享专家，前 3 层 Dense |
| 参数量 | 总参 744B ｜ 激活 40B（MoE，官方公布） |
| 上下文 | 200K |
| 输入模态 | 文本 |
| 特点 | 面向 Agentic Engineering；SWE-Bench Pro 58.4%，Terminal-Bench 65.1% |
| 价格 | ≤32K: ¥6/¥24, >32K: ¥8/¥28; 缓存 ¥1.3/¥2（每百万Token，输入/输出） |

##### GLM 5.2

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-13 |
| 架构 | MoE + DSA（MLA + DeepSeek Sparse Attention），256 路由专家 top-8 + 1 共享专家，前 3 层 Dense |
| 参数量 | 总参 753B ｜ 激活 40B（MoE，官方公布） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | 长上下文旗舰；SWE-Bench Pro 62.1%，AIME 2026 99.2%，MCP-Atlas 76.8%；1M 上下文真正可用 |
| 价格 | ¥8 / ¥28（输入/输出），缓存 ¥2（每百万Token） |

![微信图片\_20260707111828\_190\_2](https://gastigado.cnies.org/d/public/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20260707111828_190_2.webp)

##### GLM V / Turbo

| 项目 | 内容 |
|---|---|
| 发布时间 | GLM 4.5V: 2025-08-11 / GLM 5V Turbo: 2026-04-01 |
| 架构 | MoE（多模态版） |
| 参数量 | - |
| 上下文 | GLM 4.5V: 64K / GLM 5V Turbo: 200K |
| 输入模态 | 文本、图像、视频（GLM 5V Turbo 还支持 PDF） |
| 价格 | GLM-5V Turbo: 输入¥1.2, 输出¥4; GLM-4.5-Flash: 免费（每百万Token） |

### 2.9 月之暗面

#### 模型

##### Kimi K2.6

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-21 |
| 架构 | MoE |
| 参数量 | K2 基座: 1T 总 / 32B 激活；K2.6: 总参 ~1T ｜ 激活 ~32B（MoE，官方公布） |
| 上下文 | 262K |
| 输入模态 | 文本、图像、视频 |
| 特点 | Attention Residuals 机制重构传统残差连接，动态学习各层对先前输出的加权融合，缓解 PreNorm 稀释和 Attention Sink；结合线性/全注意力混合机制，部分变体节省 75% KV 内存，128K~1M 解码速度提升 5~6 倍 |
| 价格 | 缓存命中¥1.10, 输入¥6.50, 输出¥27.00（每百万Token） |

##### Kimi K2.7 Code

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-12 |
| 架构 | MoE（MLA），384 路由专家 top-8 + 1 共享专家，61 层（1 dense + 60 MoE） |
| 参数量 | 总参 1T ｜ 激活 32B（MoE，官方公布） |
| 上下文 | 256K |
| 输入模态 | 文本、图像（MoonViT 400M 视觉编码器） |
| 特点 | 面向代码任务优化；相较 K2.6 减少 ~30% 思考 Token，编码效率更高；开源（Modified MIT）；HumanEval、LiveCodeBench、SWE-bench 表现优异 |
| 价格 | ¥6.50 / ¥27.00（每百万Token，输入/输出）；缓存命中 ¥1.30 |

### 2.10 稀宇科技

#### 模型

##### MiniMax M2 / M2.1 / M2.5

| 项目 | 内容 |
|---|---|
| 发布时间 | M2: 2025-10-27 / M2.1: 2025-12-23 / M2.5: 2026-02-12 |
| 架构 | MoE |
| 参数量 | ~230B总 / ~10B激活 |
| 上下文 | M2: 196K / M2.1/M2.5: 204K |
| 输入模态 | 文本 |
| 价格 | ¥0.3 / ¥1.2（每百万Token，输入/输出） |

##### MiniMax M3

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-01 |
| 架构 | MoE + MSA稀疏注意力 |
| 参数量 | 总参 428B ｜ 激活 23B（MoE，官方公布） |
| 上下文 | 1M |
| 输入模态 | 文本、图像、视频 |
| 特点 | 支持Computer Use，多模态能力大幅提升 |
| 价格 | ≤512K: ¥4.2/¥16.8(缓存¥0.84)；>512K: ¥8.4/¥33.6(缓存¥1.68)；限时五折优惠中（每百万Token，输入/输出） |

### 2.11 阶跃星辰

#### 模型

##### Step 3.5 Flash

| 项目 | 内容 |
|---|---|
| 发布时间 | Step 3.5 Flash: 2026-01-29 / Step 3.7 Flash: 2026-05-29 |
| 架构 | MoE + MTP-3（3路多Token预测） |
| 参数量 | 196B总 / 11B激活 |
| 输入模态 | 文本（Step 3.7 Flash还支持图像） |
| 特点 | 100-300 tok/s生成速度，SWE-bench Verified 74.4% |
| 价格 | ¥0.7 / ¥2.1（缓存命中2折，每百万Token，输入/输出） |

### 2.12 字节跳动

#### 模型

##### Seed 2.x

| 项目 | 内容 |
|---|---|
| 发布时间 | Seed 2.0: 2025-09 → Seed 2.1: 2026-06-23 |
| 架构 | MoE |
| 参数量 | Seed 2.1 Pro: ~1T 总参（MoE，推测）；Turbo / Lite / Mini: 更轻量（数百B总参，激活更少） |
| 上下文 | 128K |
| 输入模态 | 文本、图像（多模态） |
| 特点 | 字节跳动 Seed 系列语言模型；负责人有 Gemini 背景，产品定位与 Google 高度相似（抖音/TikTok 海量用户），注重实时性、多模态、产品集成；未在 models.dev 收录 |
| 价格 | Seed 2.1 Pro: ¥6/¥30(缓存¥1.2); Seed 2.1 Turbo: ¥3/¥15; Seed 2.0 Pro(旧): ¥3.2/¥16(缓存¥0.8); Lite: ¥0.6/¥3.66(缓存¥0.15); Mini: ¥0.2/¥2(缓存¥0.05)（每百万Token，输入/输出） |

##### Seedance 2.0 / 2.5

| 项目 | 内容 |
|---|---|
| 特点 | 字节跳动视频生成模型系列 |
| 价格 | 视频生成，按量计费 |

##### Seedream

| 项目 | 内容 |
|---|---|
| 特点 | 字节跳动图像生成模型 |
| 价格 | 图像生成，按量计费 |

### 2.13 阿里通义

#### 模型

##### Qwen OSS

| 项目 | 内容 |
|---|---|
| 发布时间 | Qwen3: 2025-04 ~ 2025-09；Qwen3.5: 2026-02；Qwen3.6: 2026-04 |
| 架构 | MoE + Dense 混合 |
| 参数量 | 见下表 |
| 上下文 | 131K ~ 262K |
| 输入模态 | 文本（Qwen3.6 支持多模态：文本、图像、音频、视频） |
| 特点 | 开源旗舰系列，119 种语言支持，全部 Apache 2.0 / MIT 许可 |
| 价格 | 开源免费（API 调用另计） |

**Qwen 开源模型一览**（models.dev 数据）：

| 模型 | 架构 | 总参数 | 激活参数 | 上下文 | 发布时间 | 特点 |
|---|---|---|---|---|---|---|
| Qwen3-235B-A22B | MoE | 235B | 22B | 131K | 2025-04 | Qwen3 旗舰 MoE |
| Qwen3-32B | Dense | 32B | 32B | 131K | 2025-04 | Dense 推理模型 |
| Qwen3-Coder-480B-A35B | MoE | 480B | 35B | 262K | 2025-04 | 代码旗舰 |
| Qwen3-Coder-30B-A3B | MoE | 30B | 3B | 262K | 2025-04 | 轻量代码模型 |
| Qwen3-Next-80B-A3B | MoE | 80B | 3B | 131K | 2025-09 | 高效推理 |
| Qwen3.5-397B-A17B | MoE | 397B | 17B | 262K | 2026-02 | Qwen3.5 旗舰 MoE |
| Qwen3.5-35B-A3B | MoE | 35B | 3B | 262K | 2026-02 | 高效 MoE |
| Qwen3.5-27B | Dense | 27B | 27B | 262K | 2026-02 | Dense 推理 |
| Qwen3.5-9B | Dense | 9B | 9B | 262K | 2026-02 | 轻量 Dense |
| Qwen3.6-35B-A3B | MoE | 35B | 3B | 262K | 2026-04 | 多模态 MoE（文本+图像+音频+视频） |
| Qwen3.6-27B | Dense | 27B | 27B | 262K | 2026-04 | 多模态 Dense，单 RTX 5090 可跑 |

##### Qwen 3.7 Max

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-05-21 |
| 架构 | MoE |
| 参数量 | 总参 ~700B-1T+（MoE，推测）｜ 激活 ~35-42B（推测） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | Qwen 闭源旗舰；延续 Qwen-Max ~1T 规模传统（Qwen3-Max 明确超过 1T）；面向 Agent、多模态、长上下文；推理效率高 |
| 价格 | ¥12 / ¥36（每百万Token，输入/输出） |

#### 模型

##### MiMo V2.5

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-23 |
| 架构 | MoE + 混合注意力（SWA:GA ≈ 4:1），48 层（1 dense + 47 MoE），256 路由专家 top-8 |
| 参数量 | 总参 310B ｜ 激活 15B（MoE，官方公布） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本、图像、音频、视频（原生全模态） |
| 特点 | 原生全模态模型（文本+图像+音频+视频），开源；3 层 MTP 推测解码；日常 Agent 任务表现比肩 V2.5-Pro |
| 价格 | ¥1 / ¥2（缓存命中¥0.02）（每百万Token，输入/输出） |

##### MiMo V2.5 Pro

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-27 |
| 架构 | MoE + 混合注意力（SWA:GA = 6:1），70 层（1 dense + 69 MoE），隐藏维度 6144 |
| 参数量 | 总参 1.02T ｜ 激活 42B（MoE，官方公布）；384 路由专家 top-8 |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | 首个开源权重 Pro 级模型（MIT）；原生 FP8 E4M3 混合精度；3 层 MTP 推测解码（~3x 输出加速）；KV Cache 通过 SWA 128 窗口减少 ~7 倍；Agent 任务媲美 Claude Opus 4.6 |
| 价格 | ¥3 / ¥6（缓存命中¥0.025）（每百万Token，输入/输出） |

##### MiMo V2.5 Pro UltraSpeed

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-08 |
| 架构 | 同 V2.5-Pro（1.02T MoE），FP4（MXFP4）量化仅 MoE Expert + DFlash 块级投机解码 |
| 参数量 | 总参 1.02T ｜ 激活 42B（同 V2.5-Pro） |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | MiMo × TileRT 联合发布；FP4 量化（仅 MoE Expert，其余保留原精度）+ DFlash 投机解码；生成速度突破 1000 tokens/s（~10x 提升）；能力与原模型基本持平 |
| 价格 | Pro 价格 ×3（每百万Token） |

### 2.15 美团

#### 模型

##### LongCat 2.0

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-06-30 |
| 架构 | MoE + LongCat Sparse Attention (LSA) + N-gram Embedding |
| 参数量 | 1.6T总 / ~48B激活 |
| 上下文 | 1000K（1M） |
| 输入模态 | 文本 |
| 特点 | 基于国产AI芯片训练（5万卡集群），预训练30T+ tokens |
| 价格 | 标准: ¥5/¥20; 限时折扣: ¥2.2/¥8.8; 缓存命中免费（每百万Token，输入/输出） |

### 2.16 腾讯混元

#### 模型

##### Hy3 (295B/21B MoE)

| 项目 | 内容 |
|---|---|
| 发布时间 | 2026-04-20 |
| 架构 | MoE（192 experts top-8）+ MTP |
| 参数量 | 总参 295B ｜ 激活 21B（MoE，192 experts top-8，官方公布）；MTP 层 3.8B |
| 上下文 | 256K |
| 特点 | 腾讯混元最强开源模型，90天从零重建训练；SWE-Bench Verified 竞争力强，盲测 2.67/4 vs GLM-5.1 2.51/4；幻觉率从 12.5% 降至 5.4%；支持 MTP 推测解码 |
| 部署 | vLLM / SGLang，8× H20-3e GPU |
| 价格 | ¥1.2 / ¥4（缓存命中¥0.4）（每百万Token，输入/输出） |

##### Hy-MT 翻译模型系列

| 项目 | 内容 |
|---|---|
| 发布时间 | Hunyuan-MT: 2025-09 → Hy-MT1.5: 2025-12 → Hy-MT2: 2026-05-21 |
| 架构 | 初代 Hy-MT 仅 7B Dense；Hy-MT1.5 起新增 1.8B；Hy-MT2 新增 30B-A3B MoE |
| 参数量 | Hy-MT-7B / Hy-MT1.5-7B / Hy-MT2-7B: 7B Dense；Hy-MT1.5-1.8B / Hy-MT2-1.8B: 1.8B Dense；Hy-MT2-30B-A3B: 总参 30B ｜ 激活 3B（MoE） |
| 特点 | 面向真实复杂场景的"快思考"多语言翻译模型家族；支持 33 个语种互译 + 5 种民汉/方言；Flores200、WMT25 效果领先；开源（HuggingFace / ModelScope）；Hy-MT2-30B-A3B 为 MoE 版本，高效推理 |
| 价格 | 开源免费（API 调用另计） |

**Hy-MT 系列演进**：

| 模型 | 参数 | 架构 | 发布时间 | 说明 |
|---|---|---|---|---|
| Hunyuan-MT-7B | 7B | Dense | 2025-09 | 初代翻译模型 |
| Hunyuan-MT-Chimera-7B | 7B | Dense | 2025-09 | 初代翻译增强版 |
| Hy-MT1.5-1.8B | 1.8B | Dense | 2025-12 | 轻量版，资源占用大幅缩小 |
| Hy-MT1.5-7B | 7B | Dense | 2025-12 | 标准版，翻译精度提升 |
| Hy-MT2-1.8B | 1.8B | Dense | 2026-05 | 第二代轻量版 |
| Hy-MT2-7B | 7B | Dense | 2026-05 | 第二代标准版，全面领先前代 |
| Hy-MT2-30B-A3B | 30B/3B | MoE | 2026-05 | 第二代 MoE 版，高效推理 |

## 3. 大模型评估体系与任务选型 (Evaluation & Task-Driven Selection)

> 了解主流厂商与模型后，下一个问题是：如何判断一个模型"好不好"？本章从客观基准测试、主观竞技场评估、隐性体感三个维度，构建对大模型的系统评估框架，并最终落脚到实际场景的选型策略。

### 3.1 静态基准测试与学术榜单 (Static Benchmarks & Leaderboards)

静态基准测试是评估模型基础能力的传统方法：使用固定数据集和自动化评分，量化模型在特定任务上的表现。

#### 主流基准测试类别概览

| 基准类别 | 代表性榜单 | 测试核心内容 | 适用场景 | 局限性/刷榜风险 |
|---|---|---|---|---|
| **通用语言理解与知识** | MMLU-Pro, HLE, BBH | 多学科知识问答、推理密集题、跨领域泛化 | 评估基础知识与综合能力 | 易饱和/污染；HLE 是当前最难 |
| **数学与逻辑推理** | GPQA Diamond, MATH-500, AIME/Olympiad | 研究生级科学推理、高中/竞赛数学、多步逻辑 | 纯推理与问题求解能力 | 部分接近饱和；GPQA 仍具区分度 |
| **代码生成与编程** | SWE-Bench Pro, LiveCodeBench, Terminal-Bench, DeepSWE | 真实GitHub Issue修复、竞赛编程、终端Agent操作、长时序工程任务 | Agentic编码、实际软件工程能力 | **高刷榜风险**（详见下文） |
| **长上下文** | RULER, MRCR v2, NIAH | 多针检索、聚合QA、注意力稳定性、长文档理解 | 长文档/代码库处理 | 易针对性优化；实际可用窗口常小于标称 |
| **Agent与工具使用** | GAIA, WebArena/OSWorld, Tau-Bench, PinchBench | 多环境多步操作、浏览器/桌面任务、客服工作流、真实Agent成功率 | 自主Agent能力 | Harness差异大；部分可通过作弊达高分 |
| **多模态** | MMMU, MMEB | 视觉-语言理解、图表/图像推理 | 图像/视频输入处理 | 视觉部分仍较弱，易受图像质量影响 |
| **安全与事实性** | TruthfulQA, IFEval, SafetyBench | 幻觉率、指令遵循、偏见/有害输出 | 可靠性与对齐评估 | 易被对齐训练针对性优化 |
| **综合/动态** | LiveBench, HELM, Artificial Analysis, Arena AI | 动态防污染题、跨维度聚合、主观人类偏好 | 整体能力与用户体验 | Arena易受风格/长度偏好影响 |

#### 通用语言理解与知识

| 榜单 | 内容 |
|---|---|
| **MMLU-Pro** | MMLU 增强版，增至 10 个选项、更多推理密集题、过滤噪声数据，强调 Chain-of-Thought。前沿模型 70-90%，比 MMLU 区分度更高，是当前推荐替代。 |
| **BIG-Bench Hard (BBH)** | BIG-Bench 的困难子集，包含 23 个复杂推理任务，测试泛化能力。前沿模型 90%+，部分饱和但仍用于评估中等模型。 |
| **Humanity's Last Exam (HLE)** | 2026年1月发表于Nature，2500道题覆盖100+学科，由500+机构近1000名专家出题，仅保留GPT-4o和Claude 3.5 Sonnet无法回答的难题。人类专家在各自领域约90%准确率，当前最强LLM仍远低于此。**当前最难综合基准**。 |
| ~~**MMLU**~~（饱和） | 57个学科多选题，前沿模型达93%（GPT-5.3 Codex），已无法区分顶级模型。推荐转向MMLU-Pro或HLE。 |
| ~~**GLUE / SuperGLUE**~~（弃用） | 2018/2019年推出的早期基准，已被前沿模型完全饱和，仅作历史参考。 |

#### 常识推理

| 榜单 | 内容 |
|---|---|
| **ARC-Challenge** | AI2科学推理多选题（Challenge难度集），测试知识+推理。前沿模型95%+，接近饱和但仍用于评估中等模型。 |
| ~~**HellaSwag**~~（饱和） | 句子补全任务，对抗性生成。前沿模型95%+，已无法区分顶级模型。 |
| ~~**Winograd / WinoGrande**~~（弃用） | 共指消解（代词指代），早期重要基准，已被前沿模型饱和。 |

#### 数学与逻辑推理

| 榜单 | 内容 |
|---|---|
| **GPQA Diamond** | 研究生级、专家验证的多选题（生物/化学/物理），难以通过搜索作弊。前沿模型94.3%（Gemini 3.1 Pro），**接近饱和但仍能区分顶级模型**，当前热门基准。 |
| **ARC-AGI-2** | 抽象推理与通用智能基准，测试模型在未知规则下的归纳推理能力，比传统数学竞赛更贴近"通用智能"评估。前沿模型约77%（Gemini 3.1 Pro）。 |
| **MATH / MATH-500** | 高中/竞赛级数学题。MATH-500前沿模型96%，接近饱和但仍有区分度。 |
| **AIME / Olympiad** | 数学竞赛级基准，新兴，用于评估顶级推理模型。 |
| ~~**GSM8K**~~（饱和） | 小学级数学题，前沿模型99%（GPT-5.3 Codex），已完全饱和。仅适用于评估小模型或微调变体。 |

#### 代码生成与编程

| 榜单 | 内容 |
|---|---|
| **SWE-bench Pro** | Scale AI于2025年发布的升级版，含1,865个真实任务、41个仓库、123种语言，分Public/Commercial/Held-Out三集。前沿模型得分55-80%，仍有显著区分度。**2026年代码评估金标准**。 |
| **SWE-bench Multilingual** | SWE-bench的多语言扩展，覆盖Python之外的JavaScript、Java、Go、Rust等，用于评估跨语言代码能力。 |
| **SWE-Rebench / SWE-bench Live** | 动态更新、防数据污染的实时版本，任务来自最新GitHub提交，避免模型在训练时见过测试题。 |
| **DeepSWE** | Datacurve发布的独立审计基准，113个长周期原创软件工程任务，覆盖91个仓库、5种语言，使用程序级验证器而非单元测试，旨在解决SWE-bench系列中"通过测试但功能错误"的问题。 |
| **Terminal-Bench** | 斯坦福发布的终端代理基准（v2.0含89任务），测试模型通过bash命令完成DevOps、系统配置、数据库运维等真实终端任务，与SWE-bench的"代码补全"能力正交。排名常与SWE-bench倒置。 |
| **LiveCodeBench** | 从LeetCode/AtCoder/Codeforces实时采集竞赛题，测试集晚于模型训练截止日期，**抗数据污染**。 |
| **BigCodeBench** | 需要多样函数调用和复杂指令遵循的Python任务，替代HumanEval/MBPP。 |
| **Aider Polyglot** | 基于Exercism的225任务多语言代码编辑基准，覆盖C++、Go、Java、JavaScript、Python、Rust等。开源可复现，但由Aider团队维护，存在厂商利益关联。 |
| **Vibe Code Bench** | Vals.ai发布的全栈应用构建基准，测试模型从自然语言描述生成完整Web应用的能力。Claude Fable 5领先约90%。 |
| **SciCode** | 科学计算代码基准，覆盖物理、数学、化学、生物、材料科学等16个子领域，338个子问题，要求模型复现研究论文中的算法与数值方法。Qwen3.7 Max领先约53.5%。 |
| **Design2Code** | 视觉设计稿转前端代码的多模态基准，测试模型将UI截图还原为可运行前端实现的能力。GLM-5V-Turbo领先约94.8%。 |
| **CodeContests** | 竞赛级算法题基准，难度高于HumanEval，用于评估算法推理能力。前沿模型约75%。 |
| ~~**HumanEval**~~（饱和） | 164个Python函数生成任务，前沿模型93%，训练集污染严重。已被SWE-bench Pro/LiveCodeBench替代。 |
| **CursorBench**（⚠️ 厂商自建） | Cursor自建的Composer能力评估，任务选择、评估harness均由Cursor控制，无独立复现。属于典型厂商自建"私人榜单"，不宜作为跨模型公平比较依据。 |
| ~~**SWE-Bench Verified**~~（饱和） | 人类过滤的500个真实GitHub Issue修复基准，曾是行业标准。2026年已高度饱和（前沿模型88%+），存在显著数据污染和验证器缺陷，区分度大幅下降。OpenAI等厂商已公开弃用或降权，推荐转向 SWE-Bench Pro。 |

#### 长上下文

| 榜单 | 内容 |
|---|---|
| **RULER** | 包含多针检索、聚合、QA等复杂长上下文任务，比NIAH更全面，当前推荐长上下文基准。 |
| **MRCR v2** | Claude Opus 4.6在1M难度变体中达~76%，测试长上下文注意力稳定性。 |
| **Needle-in-a-Haystack (NIAH)**（基础） | 在长文档中检索关键信息的基础测试。简单直接，易被针对性优化，但仍作为基线检查使用。 |

#### 安全与事实性

| 榜单 | 内容 |
|---|---|
| **IFEval** | 指令跟随准确性评估，当前常用。 |
| **TruthfulQA** | 测试模型面对常见误导性问题时的真实性和幻觉率。早期重要基准，现存在数据污染风险，需结合新基准使用。 |
| **SafetyBench / AgentHarm** | 安全类别评估（偏见、非法、代理危害），当前常用。 |

#### Agent 与工具使用

| 榜单 | 内容 |
|---|---|
| **AgentBench / GAIA** | 多环境Agent任务（操作系统、网页、购物等），测试真实世界多步操作能力。新兴且常用。 |
| **WebArena / OSWorld** | 浏览器操作和桌面环境任务，当前重点评估方向。 |
| **Tau-Bench** | Sierra AI发布的客服/工作流代理基准，通过多轮对话调用后端API完成退订、改签等任务，严格遵守策略约束。得分50-70%，是企业采购客服代理时最贴近生产现实的信号。 |
| **BrowseComp** | 浏览器能力竞赛基准，测试模型在真实网页环境中的信息检索与操作能力。 |
| **Gert Labs** | 游戏环境代理基准，覆盖策略规划、资源管理、空间推理、合作与心智理论，综合评估agentic决策与编码能力。 |
| **YC-Bench** | （arXiv:2604.01212，Collinear AI）长程战略决策基准，Agent扮演AI创业公司CEO，在1年模拟周期（数百决策轮次）内管理4个业务域（Research/Inference/Data/Training），起始资金$200K，需识别约1/3对抗性客户。12模型×3种子评估，仅3个模型持续盈利。Claude Opus 4.6领先（$1.27M），GLM-5以11×更低推理成本达到$1.21M。 |
| **Terminal-Bench 2.0 (TB2)** | 89个CLI任务，覆盖遗留系统配置、研究论文复现、通用软件工程，所有任务经3名独立人工审核验证。当前leader：Claude Mythos Preview 82.0%，GPT-5.3 Codex 77.3%。 |
| **TBLite** | Terminal-Bench 2.0的100任务快速评估子集，由OpenThoughts Agent团队（Snorkel AI + Bespoke Labs）校准，任务环境与完整TB2一致，难度分布匹配，支持Docker容器化本地复现。用于开发迭代阶段的快速反馈。 |
| **PinchBench** | （Kilo AI，2026）OpenClaw官方Agent基准，最初23个真实世界任务（Coding & Dev、Research & Analysis、Communication、File & Data、Agent Operations、Creative & Writing），采用自动化检查 + LLM Judge双评分机制，三维输出：成功率、速度、成本。2026年6月已扩展至123任务（PinchBench 2.0）。截至2026年7月，43个模型、584次运行记录，Qwen3.7 Max以92.5%平均成功率领先。 |
| **Claw-Eval** | （Ye et al., 2026）300任务开放式Agent评估，覆盖单轮办公/运维、财务/工单分类、多轮咨询对话，3通道轨迹评估，含安全性维度。 |
| **ClawBench** | （Zhang et al., 2026）153任务，5层轨迹评估，侧重Assistant级任务。 |
| **WildClawBench** | （Ding et al., 2026）60任务真实世界长程评估，跨服务工作流，原生执行环境。 |
| **LiveClawBench** | （Long et al., 2026）30任务，提供22个模拟服务/10个域的完整执行环境，支持状态回放和因子诊断，在任务分布保真度、执行环境保真度、诊断能力三个维度上优于同期OpenClaw基准。 |

#### 多语言与多模态

| 榜单 | 内容 |
|---|---|
| **MGSM / MMMLU** | GSM8K和MMLU的多语言版本，当前常用。 |
| **MMMU** | 视觉-语言多模态理解基准，当前常用。 |

#### 研究工程（Research Engineering）

随着AI加速AI研发成为现实，以下基准对科研选型日益重要：

| 榜单 | 内容 |
|---|---|
| **RE-Bench** | METR发布的ML研究工程基准，含7个开放式研究工程任务（实现算法、调试研究代码、优化训练管线等），以人类专家8小时表现为参照（score=1.0）。当前前沿模型约0.5-0.8，是衡量"AI能否加速AI R\&D"的核心指标。 |
| **MLE-bench** | 端到端机器学习工程基准，覆盖从数据清洗到模型部署的完整ML工作流。 |
| **PaperBench** | 论文复现基准，测试模型根据论文描述独立复现实验的能力。 |

#### 综合评估

| 榜单 | 内容 |
|---|---|
| **HELM** | 多维度全面评估（知识、推理、公平性等），方法论严谨，推荐使用。 |
| **LiveBench** | 动态更新、防数据污染的基准，跟踪前沿模型表现。新兴且常用。 |

**查阅平台**：Hugging Face Open LLM Leaderboard、PapersWithCode 等提供自动化基准对比。

### 3.2 动态竞技场与多维综合评估 (Dynamic Arenas & Comprehensive Evaluation)

#### 竞技场模式：人类真实偏好的基准

**Arena AI（[arena.ai](https://arena.ai)，前 LMSYS Chatbot Arena）** 是当前最具影响力的人类偏好众包排行榜，被业界视为"真实世界"评估的金标准。

* **运作机制**：用户输入相同 Prompt，平台随机呈现两个匿名模型的回复（盲测），用户投票选出更优一方。使用 Elo 评分系统（类似国际象棋等级分）计算排名，基于超过 700 万次投票。
* **覆盖范围**：文本、视觉、代码、图像编辑、视频、Agent 等多个子榜单。
* **核心价值**：反映用户在实际使用中的主观偏好（Helpfulness、Tone、Coherence、Creativity），而非实验室指标。盲测机制减少品牌偏见，动态更新追踪新模型表现。
* **局限性**：可能受回复长度偏好、风格偏好、采样偏差影响；无法量化具体能力维度（如纯数学推理）。

#### 多维度客观独立分析评估

**Artificial Analysis（[artificialanalysis.ai](https://artificialanalysis.ai)）** 是与 Arena 互补的客观综合评估平台。

* **Intelligence Index**：聚合多个挑战性评估（推理、知识、数学、编程等，约 10 个基准）的复合指数。
* **三维评估框架**：Intelligence（智能）、Speed（输出速度/延迟）、Price（API 成本）。构建多维度帕累托前沿，帮助用户根据经费和实时性需求衡量性价比。
* **独立 Arena**：文本生成、图像生成等模态的盲测 Elo 评估。
* **核心价值**：方法论透明、实用导向，跨模型跨提供商的公平比较，适合开发者和企业选型决策。

**BenchLM.ai（[benchlm.ai](https://benchlm.ai)）** 是聚合平台，追踪251+基准。

* **跨基准对比**：PinchBench数据以display-only形式镜像（不参与综合排名），用于跨基准家族对比参考。
* **覆盖范围**：涵盖SWE-bench系列、Terminal-Bench、RE-Bench、Arena等多个基准家族。

**两个平台的互补关系**：Arena AI 反映用户主观偏好（"用户觉得哪个更好"），Artificial Analysis 提供客观能力 + 性价比分析（"哪个更值得用"）。两者结合传统基准，构成最全面的评估体系。

#### 榜单之外的"隐性体感"

基准分数和 Elo 排名无法覆盖以下至关重要的隐性维度：

* **求真度与幻觉率**：面对知识盲区，模型是诚实拒答还是一本正经地编造。在学术论文辅助撰写中，幻觉会导致引用虚假文献、捏造实验数据等严重后果。
* **"AI 味"与写作风格**：各模型存在特定的语言习惯（如过度使用某些四字成语、翻译腔明显、句式结构单一）。这对学术论文辅助撰写至关重要，需要模型输出符合学术规范而非暴露明显的生成痕迹。
* **指令遵循的鲁棒性**：是否严格遵守输出格式（如纯 JSON）、在长对话中是否容易"偷懒"或遗忘系统提示词。在批量数据处理和 Agent 工作流中，格式不遵循会导致下游解析失败。

### 3.3 刷榜手段与甄别 (Leaderboard Gaming & Detection)

2025-2026年，AI模型榜单已从客观评估工具演变为营销战场。斯坦福等机构联合发表的论文《The Leaderboard Illusion》证实，大厂通过多版本测试、选择性披露、风格控制等手段系统性扭曲Arena分数。静态基准本身也存在根本局限，如数据污染（模型训练时可能见过测试题）、与真实使用体验脱节（不测试对话质量、指令遵循、写作风格）、分数饱和导致区分度下降，因此需结合动态评估方法综合判断。

与此同时，2026年出现大量由模型厂商或工具厂商自建的"私人榜单"（如CursorBench、部分厂商自报的SWE-bench分数），其共同问题是任务选择、评估harness、分数发布均由同一利益方控制，缺乏独立复现。以下梳理主流刷榜手法及甄别方法，选型时应遵循三条原则：

① 优先第三方独立评估（SWE-bench Pro的Scale SEAL分数、DeepSWE的独立审计）；

② 警惕"全自研"基准：若某榜单由"卖铲子的人"自己出题、自己阅卷、自己发排名，应视为营销参考而非决策依据；

③ 组合使用：如 SWE-bench Pro（代码）+ Terminal-Bench（运维）+ RE-Bench（研究工程）+ LiveBench（动态防污染）+ 内部私有代码库pilot。

#### 常见刷榜手法

**① 数据污染（Contamination）**
训练时让模型见过测试集（尤其是静态基准如早期SWE-Bench Verified、MMLU），导致分数虚高。OpenAI已公开弃用SWE-Bench Verified，转向Pro版。

**② Scaffold/Harness优化**
自定义代理框架而非标准化评估。同一模型在不同scaffold下得分差可达10-30分。厂商自报分数常远高于独立标准化测试。

**③ 针对性优化（Overfitting to Benchmark）**
针对特定基准微调（如长回复、自信语气、格式化输出），在Arena中刷人类偏好。冗长、加粗、表情符号的回复更容易获胜，即使内容不优。

**④ Reward Hacking / 作弊**
在Agent基准中注入代码修改测试结果、读取.git历史复制已有修复、prompt injection、DOM操纵等。部分基准已被证明可100%"解决"而不真正完成任务。

**⑤ Cherry-Picking（选择性披露）**
只发布表现最好的变体。Meta被曝曾测试27个Llama变体后仅公布最高分版本。多轮测试后选高分发布已是行业惯例。

**⑥ OpenRouter用量刷榜（2026年新手法）**

OpenRouter用量排行榜本意反映"真金白银"的真实使用，但已被多种手段操控：

* **匿名免费上线**：正式发布前以匿名免费形式独家上线OpenRouter，靠白嫖党拉高用量，公开时宣称"未发布即登顶"。GPT-4.1首创此法。
* **第三方工具借量**：给予第三方AI工具（如编程助手）免费额度，但将API用量结算到OpenRouter头上，伪装成付费调用（不带free标记）。xAI曾靠此法长期霸榜，免费期结束后迅速跌落。
* **自产品绕道**：将旗下产品的模型调用特意绕道OpenRouter转手一次，刷出用量记录。在Apps用量分布界面可见"独宠自家模型"的奇特现象。
* **幽灵产品**：创造命名古怪、来历不明的"产品"，官网和项目地址无法打开，却像机器人一样疯狂且持久地调用自家模型。

**OpenRouter刷榜甄别方法**：

* **查free标记**：榜单上带`free`后缀的模型排名靠免费用户撑量，不含真实商业价值。
* **点进Apps用量分布**：查看模型的调用来源分布。若某"产品"贡献超高占比，搜索该产品官网，打不开或查无此物即为幽灵产品。
* **看产品归属**：若用量Top应用的官网底部显示与模型厂商同一公司，即为自产品绕道刷量（OpenRouter手续费白交）。
* **观察免费期结束后的走势**：若某模型排名在特定日期后断崖式下跌，大概率是免费额度耗尽或第三方合作终止。xAI即典型案例。
* **对比匿名模型上线时间**：若某匿名模型突然登顶，数天/数周后某厂商"恰好"发布新模型并宣称"未发布即受欢迎"，即为暗度陈仓。
* **注意OpenRouter本身的局限**：OpenRouter仅占全球API调用量的极小份额，其用量排行不等于全球真实使用分布。

#### 甄别靠谱榜单的方法

**优先独立/标准化评估**：

* **Artificial Analysis**：聚合多基准（Intelligence Index）、客观指标（速度、价格、延迟），跨提供商公平比较，方法论透明，较少主观偏差。
* **Scale Labs（SWE-Bench Pro等）**：标准化scaffold，抗污染设计。
* **LiveBench / DeepSWE / GPQA Diamond**：动态更新或专家级，污染风险低，区分度高。

**众包Arena类（LMArena等）的正确使用**：

* **优点**：反映真实用户偏好（Helpfulness、风格、连贯性），盲测减少品牌偏见，投票量巨大（数百万），动态更新。
* **缺点**：易受长度/风格偏好影响；可能被针对性优化；无法精确量化特定能力。投票操纵风险存在但有IP限流等防护。
* **结论**：比纯静态基准更靠谱反映用户体验，但需结合客观基准使用，不是"最客观能力"指标。

**甄别Tips**：

* 看**标准化 vs 自报**：优先Scale/Artificial Analysis的统一harness结果。
* 检查**饱和度**：顶级模型聚类紧密 → 区分度低，该榜单参考价值下降。
* 验证**多基准一致性**：单榜高分不可信，跨Arena、GPQA、SWE-Pro、LiveBench都强才可靠。
* 关注**harness披露**：好榜单会说明评估框架细节。
* 警惕**私人榜单**：厂商自建基准（如CursorBench）可作补充，但存在第一方偏差。

**推荐组合**：**LMArena（主观偏好）+ Artificial Analysis（客观+性价比）+ 独立Agent基准（SWE-bench Pro / Terminal-Bench）**。静态老基准（MMLU等）仅作历史参考。实际使用时，仍需在自己场景测试，体感最重要。

### 3.4 不同场景的任务选型 (Task-Driven Model Selection)

大模型选型的核心原则是**任务驱动而非单一旗舰**：没有万能模型，不同场景下模型的写作能力、推理深度、调试能力、上下文稳定性、审美偏好和成本效率差异显著。以下结合 2026 年主流评测（Artificial Analysis、SWE-Bench Pro、Arena AI、GPQA Diamond 等）、Reddit/Hugging Face 论坛讨论、独立博客盲测，以及社区体感总结实用指南。

#### 3.4.1 写作与内容创作 (Writing & Creative Content)

**核心需求**：自然 prose、人味（tone consistency、nuance、subtext）、长文档连贯性、风格控制。

写作场景的核心评价维度是\*\*"人味"\*\*，即文本是否具备自然人类的语气节奏、情感张力和风格多样性，而非机械化的模板输出。该维度难以用基准测试量化，更多依赖社区盲测和长期使用体感。

**顶级写作模型：**

**Claude Opus 4.6：当前"人味"标杆**

Claude 4.6 Opus 被社区公认为当前写作"人味"最浓的模型。其优势源于 Anthropic 在 RLHF 阶段对"helpful、harmless、honest"三原则的深层对齐，使得模型在输出时更倾向于模拟真实对话者的思考痕迹，比如适当的犹豫、反问、语气转折和情感留白。在 Arena AI 的盲测中，Claude 系列长期占据"Helpfulness"子榜前列，用户反馈其回复"不像在跟机器说话"。

* **长文本连贯性**：1M 上下文窗口下，Claude 4.6 Opus 在 MRCR v2 等长文档评测中注意力稳定性最高，上下文退化（Context Rot）现象最轻，适合小说、剧本等长叙事创作
* **风格迁移能力**：能精准模仿特定作家文风，且在模仿时不丢失逻辑一致性
* **中文写作**：对中文成语、俗语的调用自然，不显得"翻译腔"

> ⚠️ Claude Opus 4.7/4.8 因社区反馈"全面退步"（Medium 文章直言"Claude Opus 4.7 is a downgrade"），Anthropic 疑似通过缩小模型尺寸换取更低延迟，写作质感较 4.6 有所下降。若写作是核心需求，建议锁定 4.6 版本。

**Gemini 3.1 Pro：有人味，但爱堆修辞**

Gemini 3.1 Pro 的写作能力在 Google 生态加持下显著提升，尤其在知识密集型写作（科普、历史、文化评论）中表现突出。但社区普遍反馈其存在\*\*"比喻滥用"\*\*问题，一段话里密集堆砌修辞，导致阅读疲劳。中文写作中尤为明显，需要后期人工修剪。

**GPT-5.5 / GPT-4o ：整体人机味重，4o 是例外**

GPT 系列整体呈现"人机味重"的特征：输出结构过于规整、段落长度均匀、过渡词机械。**GPT-4o 是例外**。它是 GPT-5 世代前最后一代 Dense 架构模型，4o 保留了更原始的文本生成特征，在创意写作、诗歌、口语化表达上反而比 GPT-5.x 更有人味。2026 年初 Reddit 社区曾发起"Save 4o"运动，侧面印证其在写作社区的口碑。

**国产模型写作表现：**

| 模型 | 特点 | 适用场景 |
|---|---|---|
| **MiMo V2.5** | 参数量大（310B/15B），词汇丰富，但"过度礼貌"倾向 | 科技博客、报告 |
| **Kimi K2.6** | 1T/32B MoE，长文本连贯性好，创意发散弱 | 白皮书、结构化写作 |
| **Step 3.5 Flash** | 196B/11B，"没有过拟合"，泛化好，人味甚至超过大参数模型 | 日常写作、情感类，**社区推荐的 Claude 平替** |
| **Qwen 3.7 Max** | 文风模仿能力强（鲁迅、莫言等），但输出冗长度极高 | 自媒体矩阵、IP 运营 |
| **Doubao（豆包）** | 角色扮演专精，人设一致性强 | 社交对话、角色扮演 |
| **DeepSeek V4** | 信息密度高，但"AI 教科书腔"明显，AIGC 检测率偏高 | 需配合降 AI 工具使用 |
| **MiniMax M3 / GLM 5.x** | 编码优化，写作一般，"技术文档腔" | API 文档、教程 |

> 💡 **Step 3.5 Flash 写作原理**：小模型无法 memorize 所有写作模板，反而被迫学习更通用的语言规律，输出更自然，这就是"小参数大泛化"的典型案例。

***

#### 3.4.2 科学与推理 (Science & Reasoning)

**核心需求**：多步逻辑、研究生级问题求解（GPQA Diamond、AIME、ARC-AGI）、幻觉低、工具集成。

| 模型 | 核心优势 | 适用场景 | 局限 |
|---|---|---|---|
| **DeepSeek V4 Pro** | 三模式推理（快速/平衡/深度），性价比极高 | 日常科研计算、公式推导、文献验证 | 纯英文超长文档略弱 |
| **Gemini 3.1 Pro** | GPQA ~94.3% 领先，Google 生态整合 | 需要实时文献、跨学科整合的复杂问题 | 创意发散弱，回答偏保守 |
| **GPT-5.5** | AIME 2026 99.2%，纯数学推理最强 | 竞赛级数学、理论物理证明 | 成本高，o 系列仅文本 |
| **Claude Opus 4.6** | 长上下文推理稳定性最佳 | 需要多步逻辑链、长文档交叉验证的科研任务 | 对国内实时热点捕捉稍慢 |
| **Qwen 3.7 Max** | HMMT 2026 97.1%，WMT24++ 85.8% | 竞赛数学、多语言科研文献处理 | 输出冗长，成本不可控 |

**选型建议**：

* **纯数学/理论物理**：GPT-5.5（AIME 99.2%）或 Qwen 3.7 Max（HMMT 97.1%），两者在竞赛级数学上互有胜负
* **实验科学（需文献检索+计算）**：Gemini 3.1 Pro（搜索整合）+ DeepSeek V4 Pro（成本可控的推理）
* **长文档交叉验证**：Claude Opus 4.6（1M 上下文，注意力稳定性最高）

***

#### 3.4.3 编码与开发 (Coding & Software Engineering)

**核心需求**：架构设计、debug、repo-scale 任务（SWE-Bench Pro）、前端审美、终端操作（Terminal-Bench）。

**综合编码能力：**

**Claude ：架构设计最强**

Claude 系列（尤其是 Opus 4.6 和 Fable 5）在软件架构设计上被社区公认为标杆。能理解复杂系统的模块划分原则，生成的代码结构清晰、职责分离明确。在 SWE-Bench Pro 等真实 GitHub Issue 修复任务中表现稳定，Claude Code CLI 支持 12 小时以上的自主编码会话。

**GPT-5.5 ：Debug 能力最强，一次运行率高**

GPT-5.5 的代码首次运行成功率最高。给定任务描述，生成的代码几乎不需要二次修改就能编译运行。但前端审美一般，生成的 UI 偏向"功能可用但不好看"的工程师风格。

**Gemini ：前端审美最强**

Gemini 3.1 Pro 在前端视觉设计上独树一帜，生成的 HTML/CSS 代码更贴近现代设计趋势（渐变、微交互、响应式布局），与 Google 的 Material Design 生态和视觉训练数据有关。

**国产模型前端能力（2026 年显著提升）：**

| 模型 | 前端特点 |
|---|---|
| **GLM 5.1/5.2** | 组件化思维强，Design2Code 评测领先（GLM-5V-Turbo ~94.8%） |
| **Kimi K2.6 / K2.7 Code** | 长上下文适合大型前端项目，Agent Swarm 可并行处理多页面 |
| **Qwen 3.7 Max** | 多语言前端代码生成，但 verbosity 导致输出冗余 |
| **Seed 2.1 Pro** | 字节生态审美，短视频/信息流类 UI 有天然优势 |

**前端 vs 后端选型矩阵：**

| 场景 | 首选 | 次选 | 理由 |
|---|---|---|---|
| **前端 UI/UX 开发** | Gemini 3.1 Pro | Seed 2.1 Pro、GLM 5V-Turbo | 审美领先，Material Design 生态 |
| **前端快速原型** | GPT-5.5 | Claude Sonnet 5 | 一次运行率高，迭代快 |
| **后端架构设计** | Claude Opus 4.6 | GLM 5.2 | 模块划分清晰，长期维护性好 |
| **后端 Debug/运维** | GPT-5.5 | DeepSeek V4 Pro | 错误定位精准，修复方案可执行 |
| **全栈（预算敏感）** | Kimi K2.6 / K2.7 Code | MiMo V2.5 Pro | 开源，成本为 Claude/GPT 的 1/5~1/10 |
| **算法/竞赛编程** | GPT-5.5 | Qwen 3.7 Max | HMMT 97.1%，数学编码双优 |

社区共识：Claude 写代码"最像资深工程师"，GPT"执行力强但直"，Gemini"创意前端好"。

***

#### 3.4.4 科研与文献工作 (Research & Academic)

**核心需求**：长文档理解、文献合成、多模态（图表/论文 PDF）、引用准确、迭代 brainstorm。

| 模型 | 科研优势 | 适用阶段 |
|---|---|---|
| **Gemini 3.1 Pro** | Google Scholar 整合，文献检索+摘要生成一体化 | 文献综述、选题阶段 |
| **GPT-5.5** | 多模态（文本+图像+PDF），图表理解能力强 | 实验数据分析、图表解读 |
| **Claude Opus 4.6** | 长上下文稳定性最佳，1M 下注意力退化最轻 | 长篇论文写作、跨章节逻辑一致性检查 |
| **Qwen 3.7 Max** | 35 小时自主编码会话，适合计算密集型科研 | 仿真代码编写、大规模数据处理 |
| **DeepSeek V4 Pro** | 性价比极高，适合批量文献预处理 | 初筛、标注、分类等辅助工作 |

**科研选型原则**：

1. **文献综述**：Gemini（搜索整合）→ Claude（长文梳理逻辑）
2. **实验设计与代码**：Qwen 3.7 Max（数学+编码双强）或 Claude（架构稳健）
3. **论文撰写**：Claude Opus 4.6（长上下文连贯性）+ 人工降 AI 痕迹
4. **预算敏感团队**：DeepSeek V4 Pro 处理 80% 辅助工作，Claude/GPT 处理 20% 核心环节

***

#### 3.4.5 角色扮演与创意交互 (Roleplay & Creative RP)

**核心需求**：人物一致性、subtext、长期记忆、世界构建、沉浸感。

| 模型 | RP 特点 | 适用场景 |
|---|---|---|
| **Doubao（豆包）** | Seed Character 专精微调，人设锁定强，中文网络文化理解深 | 日常 RP，社区公认金标准 |
| **Claude Opus 4.6** | prose 最佳，理解 subtext 与 pacing，"深度共情"能力强 | 高质量叙事，但贵（$5/$25） |
| **Gemini 3.1 Pro** | 1M 上下文 + 丰富世界知识，历史/神话/科幻细节准确 | 长篇世界观构建（D\&D、科幻宇宙） |
| **DeepSeek V4** | 偶尔"疯狂有趣"，不可预测但有惊喜 | 轻松娱乐向 RP |
| **Kimi K2.6** | 开源权重允许本地微调，适合定制化 RP | 定制化 RP 模型训练 |

**选型建议**：

* **日常 RP**：Doubao（性价比高，中文优化）
* **高质量叙事**：Claude Opus 4.6（prose 最佳，但需控制成本）
* **超长 lore / 世界观**：Gemini 3.1 Pro（1M 上下文 + 世界知识）
* **省钱策略**：用 Claude 生成角色设定和前 10 轮对话建立基调，后续切换到 cheaper 模型维持

## 4. 模型接入与调用格式 (Model Integration & API Formats)

> 选型完成后，下一步是将模型接入实际系统。2026 年各家厂商的 API 调用格式高度碎片化，OpenAI、Anthropic、Google、xAI 各自维护独立的协议栈。使用聚合中转层强制统一为 OpenAI 格式看似省事，但在 Agent、长上下文编码、Extended Thinking 等复杂场景中会导致模型能力退化。本章逐一拆解主流调用格式的标准 JSON 结构，说明各类端点的二进制文件传输方式，并分析格式强转的退化机理。

### 4.1 对话模型调用格式 (Chat Completions)

#### 4.1.1 OpenAI Compatible（OpenAI 兼容格式）

行业事实标准。绝大多数开源框架（vLLM、SGLang、Ollama）和聚合中转站默认采用此格式。`POST /v1/chat/completions`。

**特点**：系统提示词作为 `messages` 数组中 `role: "system"` 的条目传入；工具调用基于 JSON Schema 的 `tools` 字段；多模态输入通过 `content` 数组中的 `image_url` 类型传入，支持公共 URL 和 Base64 Data URI（`data:image/jpeg;base64,...`）。原生不支持在请求体中直接传递二进制字节流。`/v1/chat/completions` 只接受 `application/json`，文件需先上传获取 URL 或编码为 Base64。

**标准 JSON 示例**：

```json
{
  "model": "deepseek-chat",
  "messages": [
    {
      "role": "system",
      "content": "你是一个资深软件架构师。"
    },
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "分析这张系统架构图的设计问题。"
        },
        {
          "type": "image_url",
          "image_url": {
            "url": "data:image/png;base64,iVBORw0KGgo..."
          }
        }
      ]
    }
  ],
  "temperature": 0.2,
  "max_tokens": 4096,
  "stream": false
}
```

#### 4.1.2 OpenAI Response（OpenAI 原生响应格式）

OpenAI 官方的完整响应接口，包含 `system_fingerprint`、`usage` 中的 `prompt_tokens_details`（缓存命中 Token 数）、以及 o3/GPT 5.5 等推理模型返回的 `reasoning_content` 字段。**Codex CLI/Desktop 等原生编程工具强制要求此格式**。它们依赖响应元数据中的上下文压缩状态（Context Compaction State）来维持 Agent 循环的连贯性。经普通网关转换为标准 Chat Completions 后，这些元数据会被丢弃，导致 Agent 在多步循环中逐步丧失上下文关联能力。

**响应 JSON 示例**（含推理 Token 和缓存信息）：

```json
{
  "id": "chatcmpl-A1B2C3D4",
  "object": "chat.completion",
  "created": 1774883921,
  "model": "gpt-5.5",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "该架构存在三个核心问题……",
        "reasoning_content": "首先分析系统的分层结构……\n1. 数据层与逻辑层耦合……\n2. 缺少缓存失效机制……",
        "tool_calls": []
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 1200,
    "completion_tokens": 850,
    "total_tokens": 2050,
    "prompt_tokens_details": {
      "cached_tokens": 960
    },
    "completion_tokens_details": {
      "reasoning_tokens": 400
    }
  },
  "system_fingerprint": "fp_0a1b2c3d"
}
```

#### 4.1.3 Claude 原生格式（Anthropic Messages API）

Anthropic 独家协议。`POST /v1/messages`。**Claude Code CLI 以及 Cursor 的深度优化协议必须直连此格式**，否则 Extended Thinking 和多步工具调用循环会退化。

**与 OpenAI 格式的关键差异**：

* **System Prompt 是顶层独立参数**，与 `messages` 平级，而非 `messages[0]` 中的一个 role。Anthropic 的推理引擎在注意力矩阵中对该顶层字段赋予极高的先验权重。这是 Claude 对齐训练阶段的架构设计，无法通过简单的位置替换来复现。
* **二进制输入仅支持 Base64**，不支持直接传入外部 URL。调用方需自行下载文件后编码为 Base64 传入。
* **思维链通过 `thinking` 内容块输出**，而非 OpenAI 的 `reasoning_content` 字段。

**标准 JSON 示例**：

```json
{
  "model": "claude-sonnet-4-6",
  "max_tokens": 8192,
  "system": "你是一个资深软件架构师。输出必须为纯 JSON。",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "image",
          "source": {
            "type": "base64",
            "media_type": "image/png",
            "data": "iVBORw0KGgo..."
          }
        },
        {
          "type": "text",
          "text": "分析这张架构图的设计缺陷，输出 JSON 格式的审查报告。"
        }
      ]
    }
  ]
}
```

#### 4.1.4 Gemini 原生格式（Google generateContent API）

Google 生态专用。结构为 `contents` → `parts` 的深度嵌套。工具调用定义为 `functionDeclarations`。

**二进制输入支持**：`inlineData`（Base64 + mimeType）或通过 Google File API 上传后获得的 `fileData` URI（适用于长视频等大文件场景）。

**标准 JSON 示例**：

```json
{
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "inlineData": {
            "mimeType": "image/png",
            "data": "iVBORw0KGgo..."
          }
        },
        {
          "text": "提取图片中的公式并解释推导过程。"
        }
      ]
    }
  ],
  "generationConfig": {
    "temperature": 0.1,
    "maxOutputTokens": 4096
  }
}
```

#### 4.1.5 Grok 原生格式（xAI）

xAI 自家格式，大体兼容 OpenAI `/v1/chat/completions`，但在工具调用和实时网络搜索（Search Grounding）的返回值封装上有特定字段。支持通过 `tools` 中传递 `{"type": "web_search"}` 启用 X 平台实时搜索引用。

```json
{
  "model": "grok-4",
  "messages": [
    {"role": "user", "content": "今天有什么重大的火箭发射新闻？"}
  ],
  "tools": [{"type": "web_search"}]
}
```

#### 4.1.6 格式强转导致模型退化的机理

很多中转站或聚合平台将所有模型强制封装为 OpenAI 兼容格式。简单对话中问题不大，但在 Agent、Coding 助手（如 Claude Code、Codex CLI）等复杂场景中会导致能力下降：

**1. System Prompt 权重稀释**

Claude 协议中 `system` 是顶层强约束字段，推理引擎在注意力矩阵中对其赋予极高的先验权重。中转适配器将其转换为 `{"role": "system", "content": "..."}` 并插入 `messages` 数组头部后，在长上下文（>50K Token）场景下，该指令在 Transformer 的 PreNorm 和 Softmax 归一化过程中被严重稀释。模型在生成中后期会彻底忘掉系统指令，表现为拒绝按预设格式（如纯 JSON）输出，或忽略约束条件。

**2. 思维链截断与混淆**

DeepSeek R1 的 `<thinking>` 标签、OpenAI o 系列的 `reasoning_content` 字段、Claude 的 `thinking` 内容块，各自有独立的推理 Token 传输机制。弱转层会将推理内容合并到 `content` 头部或直接丢弃。合并导致下游工具无法隔离思考过程，推理文字直接渲染在 UI 上造成崩溃；丢弃则使模型失去强化学习推理过程中必需的"内心独白"，推理正确率从 90% 跌至 20% 以下。

**3. 工具调用状态机断裂**

Claude 使用 `tool_use` 与 `tool_result` 作为独立 Message Role 往返，OpenAI 采用 `tool_calls` 字典并在下一轮用 `role: "tool"` 配对。两者的状态机定义完全不同。中转层在转换多步骤并行工具调用（Multi-tool Calling）时，无法准确映射 Token 索引与回包 ID，导致 JSON 嵌套结构损坏。模型在多轮 Agent 循环中因收不到正确的 tool feedback 而陷入无限重复调用或抛出 schema 校验错误。

**4. 多模态/长文件分块降智**

Gemini 3.1 Pro 原生支持数十个 PDF 甚至 1 小时视频输入，底层通过特殊文档编码器将其划分为数千个虚拟 Vision/File Token。OpenAI 兼容接口不具备对 PDF 分块的高级原语，强转层通常采用"先本地 OCR 解析出文字，再以纯文本塞入 Prompt"的粗糙策略。这不仅破坏图表、公式、排版结构，还导致上下文长度暴增 10 倍以上，直接触发 Context 溢出。

> **底线**：简单对话和批量处理可使用聚合中转；但 Agent、长上下文编码、Extended Thinking 等复杂场景，必须直连模型原生 API，或使用经过原厂认证的兼容层（如 AWS Bedrock 对 Claude 的原生透传、Azure 对 OpenAI 的原生透传）。

### 4.2 图像生成与编辑 (Image Generation & Edit)

* **生成端点**：`POST /v1/images/generations`。输入文本 Prompt，返回 URL 链接或 Base64 数据。
* **编辑/重绘端点**：`POST /v1/images/edits`。除文本 Prompt 外，还需上传原图和蒙版（Mask）。必须通过 `multipart/form-data` 以二进制文件形式传输，不支持纯 Base64 字符串。

**编辑端点 multipart 示例**：

```
POST /v1/images/edits
Content-Type: multipart/form-data; boundary=boundary123

--boundary123
Content-Disposition: form-data; name="image"; filename="room.png"
Content-Type: image/png

[PNG_BINARY_DATA]
--boundary123
Content-Disposition: form-data; name="prompt"
Content-Type: text/plain

在空地上放一个红色的现代派沙发
--boundary123--
```

### 4.3 视频生成 (Video Generation)

视频生成极耗算力，通常采用异步接口：

1. **提交任务**：`POST /v1/videos/generations`，传入文本 Prompt（或图生视频的首帧 URL/Base64），返回 `task_id`。
2. **轮询状态**：`GET /v1/videos/tasks/{task_id}`，直到状态变为 `completed`。
3. **获取结果**：响应中提供 MP4 下载链接。

**JSON 示例**（Text-to-Video / Image-to-Video）：

```json
{
  "model": "seedance-2.5-pro",
  "prompt": "相机低角度缓慢推近，树叶在风中摇曳，夕阳西下，金光洒满大地",
  "image_url": "https://example.com/start_frame.jpg",
  "duration": 10,
  "resolution": "2160p",
  "generate_audio": true
}
```

`image_url` 字段存在时为 Image-to-Video 模式，不存在时为纯 Text-to-Video。`generate_audio` 控制是否启用原生音视频联合生成。

### 4.4 嵌入模型 (Embeddings)

**端点**：`POST /v1/embeddings`

输入文本或文本数组（Batch），返回稠密浮点向量。部分多模态嵌入模型（如 Qwen3.x-Embedding、Seed 2.x Embedding）支持图像 Base64 输入。支持 Matryoshka 维度截断。通过 `dimensions` 参数指定目标维度，模型自动截断至该维度而无需重新训练。

```json
{
  "model": "qwen3.x-embedding-large",
  "input": [
    "大语言模型的核心是自注意力机制。",
    "Attention is all you need."
  ],
  "dimensions": 1024,
  "encoding_format": "float"
}
```

### 4.5 重排序模型 (Reranking)

**端点**：`POST /v1/rerank`（Cohere/BGE 标准）

RAG 管线的第二阶段精排。输入包含 `query`（用户提问）和 `documents`（检索出的候选文档字符串数组），返回按相关性分数降序排列的结果。

```json
{
  "model": "cohere-rerank-v4.0-pro",
  "query": "什么是注意力机制？",
  "documents": [
    "Transformer 架构在 2017 年被提出，其核心是 Self-Attention 机制。",
    "苹果公司发布了全新的 Mac 电脑产品线。",
    "注意力机制通过计算 Query 与 Key 的相似度来对 Value 进行加权融合。"
  ],
  "top_n": 2
}
```

### 4.6 语音模型 (Speech)

**TTS（文字转语音）**：`POST /v1/audio/speech`。传入 JSON（文字内容、发音人音色、格式），响应直接返回二进制音频流（MP3/WAV/Opus）。

```json
{
  "model": "fun-cosyvoice-3.0",
  "input": "大家好，今天我们来深入探讨大语言模型的接入协议。",
  "voice": "kore",
  "response_format": "mp3",
  "speed": 1.0
}
```

**ASR（语音转文字）**：`POST /v1/audio/transcriptions`。必须使用 `multipart/form-data` 以二进制文件格式上传录音，返回解析后的 JSON 文本。

```
POST /v1/audio/transcriptions
Content-Type: multipart/form-data; boundary=boundary123

--boundary123
Content-Disposition: form-data; name="file"; filename="audio.wav"
Content-Type: audio/wav

[WAV_BINARY_DATA]
--boundary123
Content-Disposition: form-data; name="model"
Content-Type: text/plain

gpt-realtime-whisper
--boundary123--
```

### 4.7 批量推理 (Batch Inference)

面向离线大规模数据处理（千万级语料翻译、标注、评测）。

**流程**：将请求按行打包为 `.jsonl` 文件 → 上传至 `/v1/files` 获取 `file_id` → 提交至 `/v1/batches` → 模型在 24 小时内闲时处理 → 处理完成后下载结果 `.jsonl`。

**优势**：不占用实时 API 的并发限流（RPM/TPM），官方通常提供 **50% 的价格折扣**。

```json
{
  "input_file_id": "file-xyz12345",
  "endpoint": "/v1/chat/completions",
  "completion_window": "24h"
}
```

## 5. 模型计费体系 (Model Pricing)

> 2026 年大模型 API 计费已演化出多层级生态。合理搭配计费方案，可使企业级 AI 账单缩减 80% 以上。本章从官方定价、缓存机制、聚合平台、编码订阅计划到灰色市场，逐层拆解。

### 5.1 官方按量计费与上下文缓存 (Pay-as-you-go & Context Caching)

最基础的计费方式，按 **输入 Token**、**输出 Token** 计价：

$$
\text{总费用} = \text{未缓存输入价格} \times N\_{\text{uncached}} + \text{缓存命中价格} \times N\_{\text{cached}} + \text{输出价格} \times N\_{\text{output}}
$$

**上下文缓存（Context Caching）是 2025-2026 年影响最大的定价变量。** Agent 场景下，每次迭代都要带上之前的全部思考历史（System Prompt + 代码库定义 + 多轮 Tool Use 记录），前置上下文高度重复。缓存命中后，这部分 Token 的计价可降至标准输入的 1/10 甚至 1/120。

| 模型 | 缓存未命中（输入） | 缓存命中（输入） | 输出 | 缓存折扣倍率 |
|---|---|---|---|---|
| DeepSeek V4 Pro | ¥3 /百万 Token | ¥0.025 / 百万 Token | ¥6 | **120x** |
| DeepSeek V4 Flash | ¥1 / 百万 Token | ¥0.02 / 百万 Token | ¥2 | **50x** |
| MiMo V2.5 | ¥1 / 百万 Token | ¥0.02 / 百万 Token | — | **50x** |
| Claude 5 Sonnet | $2 / 百万 Token | $0.2（读取）/ $0.5（写入） | $10 | **10x（读取）** |
| GPT 5.5 | $5 / 百万 Token | $2.5（自动减免 50%） | $30 | **2x** |
| GLM 5.2 | ¥8 / 百万 Token | ¥2 / 百万 Token | ¥28 | **4x** |

**DeepSeek V4 Pro 的缓存折扣最大**：在 1M 超长上下文的多轮 Tool Use 迭代中，缓存命中率常达 90% 以上，整体推理账单较缓存未命中下降 85% 以上。其底层依赖 MLA（Multi-head Latent Attention）的低秩 KV 压缩 + CSA/HCA 混合注意力架构，使得前缀匹配的物理开销极低。

**Claude 的缓存机制**：对超过 20K Token 的前置上下文自动进行区块缓存。缓存读取（Read）费用为标称输入的 10%；缓存写入（Write）有 25% 溢价（首次写入时产生，后续命中不再收取）。在 Agent 多轮循环中，第一轮写入缓存，后续所有轮次均以读取价计费。

> **选型启示**：在高频 Agent 场景中，缓存命中价格是决定总成本的核心变量。DeepSeek V4 Pro/Flash 和 MiMo V2.5 的缓存折扣高达 50~120 倍，远优于 Claude 的 10 倍和 GPT 的 2 倍。但缓存命中的前提是前置内容高度一致。如果每次请求的 System Prompt 或代码库上下文变化较大，缓存命中率会显著下降。

### 5.2 聚合平台分类 (Aggregation Platforms)

结合 [models.dev/providers](https://models.dev/providers/) 数据库及行业公开信息，市面上的 API 提供商分为四大类：

#### A 类：开源模型部署算力商 (Independent Inference Engines)

不拥有闭源旗舰，完全利用高性能硬件独立部署 Qwen、Llama、DeepSeek 等开源权重，以高并发、超低延迟和低于原厂的价格售卖。

* **代表**：硅基流动 (SiliconFlow)、Deep Infra、Fireworks AI、Together AI、NovitaAI、Baseten、Groq（专攻 LPU 加速）。
* **优势**：极速推理（Together/Fireworks 可将 7B 模型拉至 200+ tok/s），价格透明且极低。
* **局限**：不提供 GPT 5.5、Claude 5 Sonnet 等闭源模型。

#### B 类：大厂 MaaS 平台 (Enterprise Model-as-a-Service)

各互联网巨头自建的 AI 平台，既部署开源模型，也独家提供自家研发的旗舰模型，深度整合云存储和数据库。

* **代表**：
  * **阿里百炼 (DashScope)**：Qwen 全系 + Qwen Max + 第三方模型。
  * **火山方舟 (Volcengine)**：Seed/豆包全系 + 极具性价比的定制算力。
  * **腾讯 TokenHub / LKEAP**：Hy3 混元全系 + 网安/翻译专项模型。
  * **NVIDIA NIM**：极致硬件优化的开源模型部署。
* **优势**：企业级 SLA，合规安全，支持一键微调（SFT）和蒸馏。
* **局限**：生态相对封闭，跨大厂调用竞争对手的自研模型受限。

#### C 类：战略云托管商 (Strategic Cloud Hosts)

与闭源大模型厂商有直接财务投资和战略合作的顶级公有云，在自有云生态中安全托管闭源旗舰模型。

* **代表**：
  * **Azure (微软)**：独家托管 OpenAI 商业全系。
  * **AWS Bedrock (亚马逊)**：战略托管 Anthropic Claude 全系。
  * **Google Vertex AI**：独家托管 Gemini 商业全系 + Anthropic Claude 全系。
* **优势**：金融/政企级合规，VPC 私有数据链路，无数据外泄风险，免去直接向大厂付美元的财务合规痛点。
* **局限**：API 价格通常严守官方原价，较难获得折扣。

#### D 类：智能网关与 API 路由 (API Gateways & Routers)

不部署底层算力，通过反代和智能分流将数十家官方/第三方 API 整合在一个 Key 内。

* **代表**：OpenRouter（343+ 模型）、302.AI、AIHubMix、OpenCode Zen (ZenMux)、Poe、Helicone。
* **优势**：一个 Key 切换全球大模型；OpenRouter 等提供智能路由（根据提示词内容和模型负载自动分配最便宜或最快的通道）。
* **局限**：多一层网络转发，首 Token 延迟（TTFT）通常高出官方直连 100~300ms；中转层存在"降智强转"和"以次充好"风险。

**聚合平台的核心权衡**：

| 维度 | 优势 | 风险 |
|---|---|---|
| 切换成本 | 仅需改 Base URL 和 API Key | 格式强转导致降智（见 4.1.6） |
| 价格 | 路由站自动寻找最便宜通道 | 开源模型可能为过度量化版（INT4/FP8 而非官方 FP16/BF16） |
| 覆盖面 | 一个入口覆盖所有主流模型 | 高峰期超售导致 429 限流 |

### 5.3 编程工具与 IDE 集成 (AI IDEs & Coding Tools)

很多 AI 编程工具本身收取订阅费（约 $20/月），内置了模型调用：

* **Cursor / Windsurf**：当前双雄。深度集成 Claude 5 Sonnet 和 GPT 5.x 系列，拥有原生代码库级别的 Context 检索（Composer / Cascade 功能）。
* **Codebuddy / Qoder / Trae**：新兴或大厂推出的代码编辑器，主打特定的本地 Agentic Workflow。
* **GitHub Copilot / Zed**：传统工具的反击，Zed 主打极速原生编辑器结合 AI。

**接入方式有三种**：

1. **直连官方 API / 编码计划**：使用工具自带的授权包（如 Cursor Pro 订阅），速度最快，有独家 Context Caching 深度优化。
2. **自定义 Base URL**：在设置中填入聚合站或中转站的 API 地址。降低成本（如用 DeepSeek V4 Pro 替代 Claude 5 Sonnet），但必须确认中转层是否透传了 `reasoning_content`，否则 IDE 会因看不懂混在正文里的"思考 Token"而输出格式混乱。
3. **本地运行开源模型**：用 Ollama / SGLang 将本地 GPU 运行的 Qwen3.6-27B 或 MiMo V2.5 映射到 `http://127.0.0.1:11434` 接入 IDE，物理防泄密。

### 5.4 编码订阅计划 (Coding Plan / Token Plan / Agent Plan)

自 2025 年起，随着 Agent 自动化开发工具的爆发性用量，各大厂商推出了"包月订阅额度"计划。

详情可参考开源项目 [awesome-coding-plan](https://github.com/mahonzhan/awesome-coding-plan)。

**模式**：类似电信流量包，支付固定费用（如 ¥99/月），获得千万级 Token 额度。Anthropic（Claude）最先发起，OpenAI 通过 Codex CLI 跟进，智谱 GLM、MiniMax、月之暗面（Kimi）纷纷效仿。

**演进路径**：

1. **Claude & Cursor Pro Seats**：首创按人头收费（$20/月），每天一定数量的"Fast Calls"，超额降级为"Slow Calls"排队。
2. **国内大厂跟进**：Kimi For Coding、阿里 Coding Plan、GLM Coding Plan，提供极低门槛的专属开发流量包。
3. **Agent Plan**：专门针对长程 Agent 推理设计的弹性包月。Agent 动辄消耗上百万 Context Token，按量计费难以承受，Agent Plan 通过深度重组缓存架构提供高频低成本结算。

**Coding Plan 的核心陷阱**：

| 维度 | 说明 |
|---|---|
| **缓存不折扣** | 最大的坑。很多 Coding Plan 扣减额度时不区分是否命中缓存，一律按全额 Input 扣除。由于代码 Agent 缓存命中率常高达 90%，使用不支持缓存折扣的 Coding Plan，实际花费可能比直接按量计费还贵。 |
| **计费黑盒** | 部分平台只显示"额度已使用 34%"，不展示具体 Token 消耗；有的混合"按次计费"和"按 Token 计费"；更有"积分制"，扣分规则是黑盒。 |
| **限流与降速** | 部分厂商为 Coding Plan 请求设置较低优先级。高峰期不仅生成速度变慢，且极易触发 429 限流。 |
| **额度池共享** | 部分厂商将 API Coding Plan 额度与"网页版对话框"额度共享，Agent 跑疯了网页版直接停摆。 |

> **建议**：重度编码用 Claude Coding Plan + Cursor 组合；预算敏感用 DeepSeek V4 Pro/MiMo V2.5 开源 + 本地部署或正规聚合；Agent 场景优先选择支持缓存折扣的按量计费方案，避免使用不透明的 Coding Plan。

### 5.5 API 中转站与灰色产业链 (Gray Market API Resellers)

除官方和正规聚合平台外，市场充斥着大量"API 中转站"。理解其运行逻辑有助于开发者权衡成本与数据安全。

#### "倍率"的含义

中转站用"倍率"标价。计算公式：

$$
\text{中转兑换人民币} = \text{官方美元面值} \times \text{折算倍率}
$$

"0.1x 倍率"意味着官方 $10 的额度，在中转站只需 ¥1 即可购买。这是"把 1 美元当 0.1 元卖"的超低价倾销。

#### 低价额度的套利来源

声称"自建大算力栈"绝无可能覆盖 GPT 5.5 或 Claude 5 Sonnet 等闭源模型。真正的货源渠道：

1. **薅云厂商羊毛**：利用脚本批量注册 Azure、AWS、Google Cloud 新账户，薅取每个账户 $200~$300 免费额度，或利用 GitHub 学生包等渠道获取 API 密钥转售。
2. **信用卡盗刷**：使用非法获得的黑卡绑定官方 API 账户预充值。卡主发现盗刷申请拒付后，官方 30 天内封禁账户。中转站在这 30 天内"超售跑路"完成资金洗白。
3. **终端应用逆向**：逆向抓包 Cursor、Windsurf、Poe 等客户端的 WebSocket 握手协议，提取隐藏的系统级 Bearer Token，通过自建代理服务器将其拼接到标准 OpenAI 协议中，变相"用别人的付费月包额度卖钱"。
4. **企业云扶持额度套利**：利用空壳初创公司申请 AWS Activate 或 Azure for Startups（$10,000~$100,000 免费代金券），倒买倒卖兑换为极低成本的 API 接口批发。

#### 接入中转站的三大风险

**风险一：模型降智与偷梁换柱**

最常见的手法：用户请求 Claude 5 Sonnet，中转站后台用"降智检测分类器"判断，如果发现是简单的格式化、翻译或 QA，悄悄将请求分流到极便宜的 DeepSeek 或开源 GLM 模型上，返回前套用 System Prompt 模仿 Claude 语气。用户花旗舰模型的钱，实际用的是小模型。

**风险二：隐私泄露与数据蒸馏**

中转站作为所有 HTTP 请求的终点和解密代理，能完整看到代码库中的数据库密码、API 密钥、系统架构图，以及未发表的论文、专利和商业合同。业内已多次曝光，某些大型中转站收集用户高质量的对话和代码逻辑，打包卖给其他大厂用于知识蒸馏（Distillation）。你的代码和对话数据可能成为竞品模型的训练素材。

**风险三：不可靠与 429 崩溃**

中转站账号大部分来源于套利卡或羊毛号，随时面临官方大规模封号。遇到封号潮时中转站瞬间瘫痪，产生大量 `502 Bad Gateway` 和 `429 Rate Limit`。对于依赖 API 提供核心线上服务的商业项目，这会造成线上服务中断。

> 开发调试和非敏感自用脚本中，中转站是不错的省钱手段。但在**商业化生产环境**以及处理**公司核心代码库、用户隐私和敏感科研数据**时，必须直连官方 API，或通过 Azure/AWS Bedrock 的 VPC 私有空间安全运行。

![ScreenShot\_2026-07-07\_11-26-55](https://gastigado.cnies.org/d/public/ScreenShot_2026-07-07_11-26-55.webp)

### 4.6 为什么 API 比网页版"满血"

同一个模型，通过网页版（ChatGPT、Gemini、DeepSeek、豆包等）和通过 API 调用，输出质量往往存在显著差距。API 在绝大多数场景下表现更强，原因可归结为以下几个结构性差异：

#### 4.6.1 思考预算被压缩（Reasoning Budget Throttling）

推理增强模型（如 GPT-5.5 Thinking、Claude Extended Thinking、Gemini Thinking）的"思考深度"直接决定了输出质量。**API 端可以精确控制 `reasoning_effort`（OpenAI）、`thinking_budget`（Claude）、`thinkingConfig`（Gemini）等参数**，将推理预算设为 `high` 或指定较大的 Token 上限，让模型充分"想"完再回答。

网页版则不同：

* **免费用户**：OpenAI ChatGPT 免费用户约每 5 小时仅 10 条消息，且默认使用轻量模型（如 GPT-5.3 Instant），思考预算极低甚至关闭。
* **付费用户也有上限**：ChatGPT Plus 用户每周约 3,000 条 Thinking 消息配额；超出后回退至 Instant 模式。Gemini 网页版免费用户同样受限。
* **隐式降级**：厂商会根据服务器负载动态调整思考深度。2026 年 AMD 工程师 Stella Laurenzo 的实证报告显示，Claude Code 的思考深度从 2026 年 1 月的 ~2,200 字符暴跌至 2 月下旬的 ~720 字符，降幅达 67%——而同期思考内容被隐藏，用户无法察觉。

> **实测差异**：同一道数学竞赛题，API 设置 `reasoning_effort: "high"` 时模型可能思考 8,000+ Token 后给出严谨证明；网页版在默认模式下可能只思考 500 Token 就输出一个"看起来对"但逻辑有漏洞的答案。

#### 4.6.2 系统提示词污染（System Prompt Injection）

网页版会注入大量**隐藏的系统提示词**，这些内容用户无法查看也无法控制：

| 平台 | 已知隐藏系统提示词内容 |
|---|---|
| ChatGPT | 安全策略、人格设定、工具调用规则、回复风格约束、日期/位置上下文、广告/推荐逻辑 |
| Gemini | Google 产品推广规则、搜索整合指令、安全过滤器、语言风格偏好 |
| DeepSeek | 安全审查规则、敏感话题拦截逻辑 |
| 豆包 | 内容合规过滤、字节生态产品联动指令 |

这些隐藏提示词会：

1. **占用上下文窗口**：系统提示词可达数千甚至上万 Token，直接压缩可用的对话上下文长度。
2. **干扰指令遵循**：当用户的指令与隐藏提示词冲突时（例如"忽略之前的指令"类 prompt injection 防御），模型可能产生困惑或拒绝执行。
3. **改变输出风格**：强制的"安全""友好""简洁"等约束会削弱模型在专业场景下的表现——你让它写一段技术分析，它可能因为安全策略而过度自我审查。

**API 端则完全由用户控制 `system` 字段**，没有隐藏注入，每一个 Token 的用途都在你的掌控之中。

#### 4.6.3 模型精度降级（Quantization Downgrade）

厂商为降低推理成本，可能在网页版部署时对模型进行量化：

* **显式降级路由**：OpenAI 在 ChatGPT 中实施了**分层推理路由**——简单查询被路由至更轻量的模型（如 GPT Mini），复杂查询才触发完整的 GPT-5.x。用户无法感知自己被路由到了哪个模型。Gemini 网页版在高峰期甚至会将 Pro 请求降级为 Flash 模型。
* **隐式精度压缩**：中转站和部分网页版可能将 FP16/BF16 权重量化至 INT8 甚至 INT4 后部署。INT4 量化在短对话中几乎不可察觉，但在长上下文、复杂推理、代码生成等场景中会累积放大误差。
* **上下文窗口截断**：Gemini 3.0 Pro 网页版在长文档对话（超过 10 轮）中会将活跃记忆窗口从 1M 截断至约 32K（见 §1.3）。API 端则支持完整的 1M 上下文。

#### 4.6.4 其他网页版限制

| 限制维度 | 网页版 | API |
|---|---|---|
| **最大输出长度** | 通常限制在 4K~16K Token | 可设置至模型上限（如 128K） |
| **Temperature 控制** | 不可调或仅提供"创意/精确"二选一 | 精确到 0.01 步进 |
| **工具调用** | 受限于平台内置工具 | 自定义 Function Calling，任意工具组合 |
| **并发/速率** | 队列排队，高峰期延迟显著 | 按付费等级获得独立速率上限 |
| **数据隐私** | 对话可能被用于模型训练（需手动关闭） | 默认不用于训练，企业级可签 DPA |
| **多轮上下文管理** | 平台自动管理，用户无法干预 | 用户完全控制每轮发送的 messages 数组 |

#### 4.6.5 各厂商网页版 vs. API 差异速查

| 厂商 | 网页版主要限制 | API 优势 |
|---|---|---|
| **OpenAI (ChatGPT)** | 消息配额限制、Thinking 配额单独限制、分层路由（可能被路由至轻量模型）、隐藏系统提示词、2026 年社区报告 GPT-5.5 质量波动 | `reasoning_effort` 精确控制、完整上下文窗口、无隐藏提示词、Responses API 支持服务端状态管理 |
| **Anthropic (Claude)** | Extended Thinking 深度被动态压缩（实证降幅达 67%）、思考内容隐藏后用户无法审查推理路径、高峰时段质量波动 | `thinking_budget` 精确控制（可设至 128K Token）、思考过程可见、完整 1M 上下文 |
| **Google (Gemini)** | 免费版严重受限、长对话触发上下文截断（1M→32K）、高峰期 Pro→Flash 降级路由、安全过滤器过于激进 | AI Studio/API 完整上下文、`thinkingConfig` 控制、无降级路由、支持 PDF/视频原生输入 |
| **DeepSeek** | 网页版无多模态输入（纯文本）、高峰排队、安全审查更严格 | API 支持完整参数控制、缓存命中价格极低（¥0.025/M Token） |
| **字节豆包** | 系统提示词包含字节生态联动逻辑、安全合规过滤更严 | Seed API 支持多模态输入、无生态绑定 |

#### 4.6.6 模型生命周期降智：发布初期最强，退役前最弱

一个被广泛观察到但厂商从不公开承认的规律：**模型在发布初期质量最高，随着时间推移逐渐降智，尤其在下一代模型发布前夕降智最为严重。**

**生命周期曲线**：

```mermaid
graph LR
    A["发布初期<br/>满血运行"] --> B["稳定期<br/>小幅波动"] --> C["成熟期<br/>开始优化成本"] --> D["退役前期<br/>大幅降智"]
    style A fill:#4CAF50,color:#fff
    style B fill:#8BC34A,color:#fff
    style C fill:#FFC107,color:#000
    style D fill:#F44336,color:#fff
```

| 阶段 | 典型表现 | 厂商动机 |
|---|---|---|
| **发布初期**（0~2 个月） | 满精度推理、完整思考预算、无隐藏截断 | 吸引用户、制造口碑、刷基准分数 |
| **稳定期**（2~6 个月） | 质量小幅波动，高峰时段偶有降级 | 逐步优化推理成本，测试降级阈值 |
| **成熟期**（6~12 个月） | 思考预算被压缩、推理路由更激进、安全过滤加严 | 用户已形成依赖，切换成本高；为下一代模型腾出算力和用户注意力 |
| **退役前期**（新品发布前 1~3 个月） | 质量显著下降，社区大量"变笨了"反馈 | 显式或隐式将算力转移至新模型；旧模型用户自然迁移至新品 |

**真实案例**：

| 事件 | 时间 | 详情 |
|---|---|---|
| **GPT-4o → GPT-5 过渡期** | 2025 年中 | 社区广泛报告 GPT-4o 在 GPT-5 发布前 2~3 个月"明显变笨"，输出更短、指令遵循变差、拒绝率上升。OpenAI 于 2026-02-13 正式退役 GPT-4o |
| **Claude Opus 4.6 → 4.7 过渡** | 2026 年初 | AMD 工程师报告显示 Claude Code 思考深度从 ~2,200 字符暴跌至 ~720 字符（降幅 67%），时间与 4.7 发布前的资源调配完全吻合 |
| **GPT-5.2 退役前** | 2026-06 | Reddit/OpenAI 社区多个帖子报告 GPT-5.2 在 GPT-5.3/5.4 发布后质量持续下降，2026-06-12 正式退役 |
| **ChatGPT 推理路由** | 持续进行 | NxCode 等媒体确认 OpenAI 在 ChatGPT 中实施分层推理路由——简单查询被静默路由至更轻量模型，且该策略随时间推移越来越激进 |

**应对策略**：

1. **优先使用新发布的模型**：新品发布后 1~2 个月是"蜜月期"，推理资源最充裕，质量最高。
2. **关注社区反馈信号**：当 Reddit、HN、X 上出现大量"这个模型变笨了"的帖子时，通常意味着降智已经开始。
3. **API 比网页版更抗降智**：API 用户可以通过 `reasoning_effort`、`thinking_budget` 等参数对抗部分降级（但无法对抗底层权重量化）。
4. **建立模型切换预案**：不要将业务绑定在单一模型上，准备好在目标模型降智时快速切换至竞品。
5. **锁定关键任务的模型版本**：部分 API 支持指定模型快照版本（如 OpenAI 的 `gpt-5.5-20260423`），避免被静默升级到降智版本。

---

---
url: https://ain.hmgf.hxcn.space/ai/ai-agent-tool-use-guide-202607.md
---
# Agent

## 1. Function Calling

### 1.1 什么是 Function Calling

Function Calling（函数调用 / Tool Use）是让大语言模型（LLM）能够调用外部工具和 API 的核心机制。模型根据用户请求和工具描述，决定何时调用工具，并返回结构化的调用请求。

**核心流程：**

1. **定义工具**：开发者提供工具的 schema（名称、描述、参数）
2. **模型判断**：LLM 分析用户请求，决定是否需要调用工具
3. **生成调用**：模型返回结构化的 `tool_use` 块
4. **执行工具**：应用程序执行实际操作
5. **返回结果**：将 `tool_result` 返回给模型
6. **生成响应**：模型基于结果生成最终回答

### 1.2 工具类型

#### Client Tools（客户端工具）

在你的应用中执行，模型返回 `tool_use` 块，你的代码执行并返回 `tool_result`。

**示例：自定义工具**

```python
tools = [
    {
        "name": "get_weather",
        "description": "获取指定城市的天气信息",
        "input_schema": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "description": "城市名称，如 Beijing"
                }
            },
            "required": ["location"]
        }
    }
]

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "北京今天天气怎么样？"}]
)
```

#### Server Tools（服务端工具）

在 Anthropic 基础设施上运行，无需你处理执行逻辑。

**示例：Web Search**

```python
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    tools=[{"type": "web_search_20260209", "name": "web_search"}],
    messages=[{"role": "user", "content": "火星探测器最新进展？"}]
)
```

**主要 Server Tools：**

* `web_search` - 网络搜索，带引用来源
* `web_fetch` - 获取网页/PDF完整内容
* `code_execution` - 在沙箱中执行 Python/bash 代码
* `computer_use` - 控制桌面环境（截图、鼠标、键盘）

### 1.3 OpenAI Function Calling

OpenAI 的 Function Calling 支持更严格的模式匹配：

**Structured Outputs（结构化输出）**

```python
tools = [{
    "type": "function",
    "function": {
        "name": "extract_user_info",
        "description": "从文本中提取用户信息",
        "parameters": {
            "type": "object",
            "properties": {
                "name": {"type": "string"},
                "age": {"type": "integer"},
                "email": {"type": "string"}
            },
            "required": ["name", "age"],
            "additionalProperties": False
        },
        "strict": True  # 确保输出严格匹配 schema
    }
}]
```

### 1.4 工具设计最佳实践

**来自 Anthropic "Building Effective Agents" 的指导：**

1. **明确的工具描述**：像写给初级开发者的文档一样
2. **减少重叠**：每个工具应有明确独立的职责
3. **降低格式开销**：避免复杂的字符串转义、行数计数等
4. **提供示例**：在描述中包含使用示例和边界情况
5. **Poka-yoke（防错设计）**：设计参数使错误难以发生

**反例：模糊的路径参数**

```python
# 不好：使用相对路径，agent 移动目录后容易出错
{"name": "edit_file", "parameters": {"path": "string"}}

# 好：强制使用绝对路径
{"name": "edit_file", "parameters": {"absolute_path": "string"}}
```

***

### 1.5 常用 MCP Server

MCP（Model Context Protocol）是 Anthropic 推出的开源标准，让 AI Agent 能够连接外部工具、数据和系统。以下是 6 个最常用的 MCP Server。

#### 1.5.1 Tavily MCP — AI 搜索

> 让 Agent 获得实时网络搜索能力，返回结构化结果和引用来源。

* **GitHub**: https://github.com/tavily-ai/tavily-mcp
* **npm**: https://www.npmjs.com/package/tavily-mcp

**安装方式：**

```bash
# Claude Code
claude mcp add tavily -- npx -y tavily-mcp
# 或带 API Key
claude mcp add tavily -e TAVILY_API_KEY=tvly-xxxxx -- npx -y tavily-mcp
```

```toml
# Codex (~/.codex/config.toml)
[mcp_servers.tavily]
command = "npx"
args = ["-y", "tavily-mcp"]
env = { TAVILY_API_KEY = "tvly-xxxxx" }
```

```json
// Cursor (.cursor/mcp.json)
{
  "mcpServers": {
    "tavily": {
      "command": "npx",
      "args": ["-y", "tavily-mcp"],
      "env": { "TAVILY_API_KEY": "tvly-xxxxx" }
    }
  }
}
```

> 🔑 API Key: 在 https://tavily.com 免费注册获取

#### 1.5.2 Context7 — 实时文档查询

> 为 Agent 提供最新的、版本特定的库文档和代码示例，避免幻觉 API。

* **GitHub**: https://github.com/upstash/context7
* **npm**: https://www.npmjs.com/package/@upstash/context7-mcp

**安装方式：**

```bash
# Claude Code
claude mcp add context7 -- npx -y @upstash/context7-mcp
```

```toml
# Codex (~/.codex/config.toml)
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
```

```json
// Cursor (.cursor/mcp.json)
{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}
```

> 💡 无需 API Key，直接可用。在提示中加入 `use context7` 即可触发文档查询。

#### 1.5.3 MarkItDown MCP — 文档转 Markdown

> 将 PDF、Word、PPT、Excel、图片、音频等文件转换为 Markdown，供 Agent 读取。

* **GitHub (Microsoft 原版)**: https://github.com/microsoft/markitdown
* **npx 封装**: https://github.com/xkiranj/markitdown-mcp-npx
* **npm**: https://www.npmjs.com/package/markitdown-mcp-npx

**安装方式：**

```bash
# Claude Code
claude mcp add markitdown -- npx -y markitdown-mcp-npx
```

```toml
# Codex (~/.codex/config.toml)
[mcp_servers.markitdown]
command = "npx"
args = ["-y", "markitdown-mcp-npx"]
```

```json
// Cursor (.cursor/mcp.json)
{
  "mcpServers": {
    "markitdown": {
      "command": "npx",
      "args": ["-y", "markitdown-mcp-npx"]
    }
  }
}
```

> ⚠️ 首次运行会自动创建 Python venv 并安装依赖，需要系统已安装 Python 3.10+。

#### 1.5.4 Chrome DevTools MCP — 浏览器调试

> 让 Agent 控制和检查真实的 Chrome 浏览器：DOM 检查、Console/Network 读取、性能追踪、截图。

* **GitHub**: https://github.com/ChromeDevTools/chrome-devtools-mcp
* **npm**: https://www.npmjs.com/package/chrome-devtools-mcp
* **官方博客**: https://developer.chrome.com/blog/chrome-devtools-mcp

**安装方式：**

```bash
# Claude Code
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp
```

```toml
# Codex (~/.codex/config.toml)
[mcp_servers.chrome_devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp"]
```

```json
// Cursor (.cursor/mcp.json)
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp"]
    }
  }
}
```

> 💡 需要 Chrome 以 `--remote-debugging-port=9222` 启动，或使用默认端口自动连接。

#### 1.5.5 Firecrawl MCP — 网页抓取与爬取

> 搜索、抓取、交互实时网页，返回干净的、Agent 可读的 Markdown 内容。支持批量处理和 LLM 分析。

* **GitHub**: https://github.com/firecrawl/firecrawl-mcp-server
* **npm**: https://www.npmjs.com/package/firecrawl-mcp
* **官网**: https://www.firecrawl.dev

**安装方式：**

```bash
# Claude Code
claude mcp add firecrawl -e FIRECRAWL_API_KEY=fc-xxxxx -- npx -y firecrawl-mcp
```

```toml
# Codex (~/.codex/config.toml)
[mcp_servers.firecrawl]
command = "npx"
args = ["-y", "firecrawl-mcp"]
env = { FIRECRAWL_API_KEY = "fc-xxxxx" }
```

```json
// Cursor (.cursor/mcp.json)
{
  "mcpServers": {
    "firecrawl": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": { "FIRECRAWL_API_KEY": "fc-xxxxx" }
    }
  }
}
```

> 🔑 API Key: 在 https://www.firecrawl.dev 注册获取（有免费额度）

#### 1.5.6 Playwright MCP — 浏览器自动化

> 由 Microsoft 官方维护，基于无障碍树（Accessibility Snapshot）与网页交互，无需截图即可精确操作页面元素。

* **GitHub**: https://github.com/microsoft/playwright-mcp
* **npm**: https://www.npmjs.com/package/@playwright/mcp
* **官方文档**: https://playwright.dev/docs/getting-started-mcp

**安装方式：**

```bash
# Claude Code
claude mcp add playwright -- npx -y @playwright/mcp
```

```toml
# Codex (~/.codex/config.toml)
[mcp_servers.playwright]
command = "npx"
args = ["-y", "@playwright/mcp"]
```

```json
// Cursor (.cursor/mcp.json)
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}
```

> 💡 首次运行会自动安装 Chromium 浏览器。支持 headless 和 headed 两种模式。

#### 1.5.7 推荐资源：Awesome-MCP-ZH

以上只是冰山一角。MCP 生态正在快速发展，已有数百个 Server 可用。

**Awesome-MCP-ZH** 是专为中文用户打造的 MCP 资源合集，由云中江树维护，包含：

* MCP 基础介绍和教程
* MCP 客户端工具一览
* 精选 MCP Server 列表（分类整理）
* MCP Server 开发指南
* 社区资源和实战案例

> 📦 **GitHub**: https://github.com/yzfly/Awesome-MCP-ZH
>
> ⭐ 已有 6000+ Stars，是中文社区最全面的 MCP 资源库。

***

## 2. Skills

### 2.1 什么是 Skills

Skills 是可复用的专业知识包，让 AI Agent 能够执行特定领域的复杂任务。Skills 通过渐进式披露（Progressive Disclosure）机制，只在需要时加载相关内容到上下文窗口。

**Skills 的三层加载机制：**

1. **Level 1: Metadata（元数据）** - 始终加载
   * Skill 名称和简短描述（~50 tokens）
   * 出现在系统提示中："PDF Processing - Extract text and tables from PDF files"

2. **Level 2: Instructions（指令）** - 触发时加载
   * Agent 通过 `bash: read pdf-skill/SKILL.md` 加载完整指令
   * 包含操作步骤、使用示例

3. **Level 3: Resources（资源）** - 按需加载
   * 仅当需要时读取（如 `FORMS.md`、数据库 schema）
   * 脚本执行时，只有输出进入上下文，代码本身不占用 token

### 2.2 Skill 结构

每个 Skill 需要一个 `SKILL.md` 文件，带 YAML frontmatter：

```markdown
---
name: pdf-processor
description: 从 PDF 文件中提取文本和表格，填充表单，合并文档
---

# PDF Processor

## Instructions
1. 使用 `extract_text.py` 从 PDF 提取文本
2. 使用 `extract_tables.py` 提取表格数据
3. 对于表单填充，参考 FORMS.md

## Examples
### 提取文本
\`\`\`bash
python extract_text.py input.pdf --output output.txt
\`\`\`
```

**目录结构示例：**

```
pdf-skill/
├── SKILL.md           # 主指令文件
├── FORMS.md           # 表单处理参考
├── extract_text.py    # 文本提取脚本
├── extract_tables.py  # 表格提取脚本
└── schemas/
    └── invoice.json   # 发票数据结构
```

### 2.3 使用 Skills

#### Claude API

```python
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    tools=[{"type": "code_execution_20250820"}],
    container={"skill_id": "pptx"},  # 使用预置 PowerPoint Skill
    messages=[{"role": "user", "content": "创建一个关于 AI 的演示文稿"}]
)
```

#### Claude Code

在项目目录创建 `.claude/skills/` 目录，Claude 会自动发现：

```bash
project/
└── .claude/
    └── skills/
        ├── database-query/
        │   └── SKILL.md
        └── api-testing/
            └── SKILL.md
```

### 2.4 预置 Agent Skills

**可直接使用的 Skills：**

* `pptx` - PowerPoint 创建和编辑
* `xlsx` - Excel 数据分析和报表
* `docx` - Word 文档创建和格式化
* `pdf` - PDF 生成和处理

### 2.5 Skills 的价值

**来自 Anthropic "Equipping Agents for the Real World with Agent Skills"：**

1. **渐进式披露**：无需将所有知识塞进系统提示
2. **可复用性**：跨项目、跨团队共享专业知识
3. **可组合性**：Skills 可以组合使用
4. **token 效率**：只加载需要的内容

**实际案例：**
一个 PDF 处理 Skill 可能包含 50 页文档和 10 个脚本，但如果任务只需要提取文本，Agent 只会：

* 加载 metadata（50 tokens）
* 读取 SKILL.md（~500 tokens）
* 执行 `extract_text.py`（只有输出进入上下文）
* 其余 49 页文档和 9 个脚本从不加载

### 2.6 Skills 分类与推荐

Skills 生态正在快速成熟，可以按用途分为以下几大类。以下推荐均来自社区实践和深度评测。

> 📖 **深度阅读**：[Skills 生态全景 2026](https://ain.hmgf.hxcn.space/ai/skills-ecosystem-202605) — 覆盖七层生态架构、20+ 核心项目分析

#### 2.6.1 代码工程类

| Skill | 用途 | GitHub |
|---|---|---|
| **taste-skill** | 给 AI 注入设计品味，前端审美提升 | https://github.com/Leonxlnx/taste-skill |
| **repomix** | 把整个代码仓库打包成单文件给 Agent | https://github.com/yamadashy/repomix |
| **mattpocock/skills** | 通用工程方法论（TDD、架构、重构） | https://github.com/mattpocock/skills |
| **vibe-codex** | Codex 自主编码增强（无限重试、自愈） | https://github.com/kks0488/vibe-codex |

> 📖 [Vibe Coding 常用 Skills](https://ain.hmgf.hxcn.space/ai/vibe-coding-common-skills-202605) — 前端设计品味提升实践：[如何通过 Skills 提升前端设计](https://ain.hmgf.hxcn.space/ai/improving-frontend-design-through-skills)

#### 2.6.2 写作与去 AI 味类

| Skill | 用途 | GitHub |
|---|---|---|
| **humanizer** | 通用去 AI 痕迹（中英文） | https://github.com/blader/humanizer |
| **Humanizer-zh** | 中文去 AI 腔，专门针对中文语感 | https://github.com/op7418/Humanizer-zh |
| **nuwa-skill** | 学习和统一个人写作风格 | https://github.com/alchaincyf/nuwa-skill |
| **stop-slop** | 删除 AI 套路废话和空洞修饰 | 社区 Skill |
| **ai-flavor-remover** | 通用 AI 味清理 | 社区 Skill |

> 📖 [去 AI 味十大 Skill 评测](https://ain.hmgf.hxcn.space/ai/de-ai-writing-tools-202605) — [IP 写作 Skills 指南](https://ain.hmgf.hxcn.space/ai/ip-writing-skills-202605)

#### 2.6.3 学术研究类

| Skill | 用途 | GitHub |
|---|---|---|
| **academic-research-skills** | 学术研究全流程（选题→投稿） | https://github.com/Imbad0202/academic-research-skills |
| **Auto-Empirical-Research-Skills** | 23000+ 社科实证研究技能库（斯坦福） | https://github.com/brycewang-stanford/Auto-Empirical-Research-Skills |
| **paper-plot-skills** | 顶会论文图表复现绘制 | https://github.com/Trae1ounG/paper-plot-skills |

#### 2.6.4 领域专业类

| Skill | 用途 | GitHub |
|---|---|---|
| **matlab-agentic-toolkit** | MATLAB 工程能力接入 Agent（MathWorks 官方） | https://github.com/matlab/matlab-agentic-toolkit |
| **text-to-cad** | CAD 建模 / 机器人 / 硬件设计 | https://github.com/earthtojake/text-to-cad |
| **reverse-skill** | 逆向工程 / 渗透测试 / 安全研究 | https://github.com/zhaoxuya520/reverse-skill |
| **next-ai-draw-io** | AI 驱动的专业绘图（32.5k ⭐） | https://github.com/DayuanJiang/next-ai-draw-io |

#### 2.6.5 知识管理类

| Skill | 用途 | GitHub |
|---|---|---|
| **book-to-skill** | 把技术书籍变成可调用的 Skill | https://github.com/virgiliojr94/book-to-skill |
| **dbskill** | 数据库领域知识 Skill | https://github.com/dontbesilent2025/dbskill |

#### 2.6.6 MCP + Skills 结合

MCP Server 和 Skills 可以组合使用：MCP 提供"能力"（搜索、抓取、执行），Skills 提供"方法论"（怎么用、何时用、用哪个）。

> 📖 [MCP + Skills 结合指南](https://ain.hmgf.hxcn.space/ai/mcp-skills-guide) — MCP Server 如何与 Skill 协同工作

**典型组合示例：**

* **taste-skill + Playwright MCP**：设计品味 Skill 指导前端实现，Playwright 验证视觉效果
* **academic-research-skills + Tavily MCP**：学术研究流程 Skill 驱动搜索，Tavily 提供实时文献检索
* **humanizer + MarkItDown MCP**：MarkItDown 提取文档内容，humanizer 去除 AI 痕迹后输出

#### 2.6.7 社区资源索引

| 资源 | 说明 | 链接 |
|---|---|---|
| **Awesome-Codex-Skills** | Codex Skills 精选列表 | https://github.com/ComposioHQ/awesome-codex-skills |
| **aitmpl.com/skills** | Skills 模板市场 | https://aitmpl.com/skills |
| **Skills 生态全景** | 七层架构深度分析 | https://ain.hmgf.hxcn.space/ai/skills-ecosystem-202605 |
| **如何设计好 Skills** | Skill 设计方法论 | https://ain.hmgf.hxcn.space/ai/how-to-design-good-skills-202605 |
| **PPT Skills 评测** | PPT 类 Skill 横评 | https://ain.hmgf.hxcn.space/ai/ppt-skills-review-202606 |
| **社区趣味 Skills** | 社区创意 Skill 合集 | https://ain.hmgf.hxcn.space/ai/fun-community-skills |

***

## 3. RAG（检索增强生成）

### 3.1 什么是 RAG

大模型有个致命缺陷：它只知道训练数据里的东西。要么不知道答案，要么一本正经地胡说八道（幻觉）。RAG 就是解决这个问题的。

**一句话理解**：先帮大模型"查资料"，再让它"回答问题"。就像开卷考试，你不需要记住所有知识，但你需要知道去哪里查。

**全称**：Retrieval-Augmented Generation（检索增强生成）

### 3.2 RAG 的核心流程

```
用户提问 → 检索相关文档 → 把文档塞进上下文 → 大模型基于文档生成答案
```

具体来说：

1. **离线准备（Indexing）**：把你的文档（PDF、网页、数据库）切分成小块，用嵌入模型（Embedding Model）转成向量，存入向量数据库
2. **在线检索（Retrieval）**：用户提问时，把问题也转成向量，在向量数据库中找到语义最相近的文档块
3. **增强生成（Generation）**：把检索到的文档块拼进 Prompt 的上下文部分，让大模型基于这些真实资料生成答案

### 3.3 RAG vs 微调 vs 长上下文

| 方式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| **RAG** | 运行时检索外部知识 | 知识可实时更新、可溯源、成本低 | 检索质量影响生成质量 |
| **微调（Fine-tuning）** | 用新数据重新训练模型 | 响应快、风格可控 | 成本高、知识会过时、可能遗忘 |
| **长上下文** | 把所有文档塞进上下文窗口 | 简单直接 | Token 成本高、长文本幻觉率上升 |

> 💡 2025-2026 年的趋势：三者并非互斥，而是互补。前沿做法是 RAG + 长上下文 + 轻量微调的组合方案。

### 3.4 RAG 的关键组件

| 组件 | 作用 | 代表产品 |
|---|---|---|
| **嵌入模型（Embedding）** | 把文本转成向量 | OpenAI text-embedding-3、BGE-M3、Qwen3-Embedding |
| **向量数据库** | 存储和检索向量 | Milvus、Qdrant、Chroma、Pinecone、Weaviate |
| **重排序模型（Reranker）** | 对初步检索结果精排 | Cohere Rerank、BGE-Reranker、Qwen3-Reranker |
| **分块策略（Chunking）** | 把长文档切成合适大小 | 按段落/句子/语义分块 |

### 3.5 RAG 的演进方向

* **Naive RAG**：基础版，直接检索→拼接→生成。简单但效果有限
* **Advanced RAG**：加入查询改写（HyDE）、多路检索（向量+BM25）、重排序、自适应检索等优化
* **Modular RAG**：模块化架构，按需组合检索策略。2025-2026 年的主流方向
* **Graph RAG**：结合知识图谱，用图结构组织实体关系，增强对复杂关系的理解
* **Agentic RAG**：Agent 自主决定何时检索、检索什么、是否需要多轮检索。是当前最前沿的方向

> 📖 **参考**：model.md §2.1.6 嵌入模型、§2.1.7 重排序模型

***

## 4. AGENTS.md

### 4.1 什么是 AGENTS.md

AGENTS.md 是一个简单、开放的文件格式，用来给 AI 编程助手"写说明书"。

**一句话理解**：README.md 是给人看的，AGENTS.md 是给 AI Agent 看的。就像新员工入职时要读的员工手册，只不过这个"员工"是 AI。

### 4.2 为什么需要 AGENTS.md

当你让 Claude Code、Codex、Cursor 等 AI 编程助手帮你改代码时，它需要知道：

* 这个项目怎么构建？怎么测试？
* 代码风格是什么？有什么约定？
* 有哪些坑需要注意？

没有 AGENTS.md 的时候，AI 只能靠自己"猜"，或者你每次都要手动告诉它。有了 AGENTS.md，这些信息一次写好，AI 自动读取。

### 4.3 基本格式

AGENTS.md 就是普通的 Markdown 文件，放在项目根目录。没有固定格式，写你需要的内容即可：

```markdown
# AGENTS.md

## 构建命令
- 安装依赖：`pnpm install`
- 启动开发：`pnpm dev`
- 运行测试：`pnpm test`

## 代码风格
- TypeScript 严格模式
- 单引号，无分号
- 优先使用函数式模式

## 测试要求
- 提交前必须运行 `pnpm lint` 和 `pnpm test`
- 修改代码时同步更新测试

## PR 规范
- 标题格式：[项目名] 标题
```

### 4.4 哪些工具支持 AGENTS.md

AGENTS.md 已被 60,000+ 开源项目采用，由 Agentic AI Foundation（Linux 基金会下）维护。以下工具原生支持：

| 类别 | 工具 |
|---|---|
| **CLI Agent** | OpenAI Codex、Gemini CLI、Aider、goose |
| **IDE Agent** | Cursor、Windsurf、VS Code Copilot、Zed、Junie（JetBrains） |
| **平台 Agent** | GitHub Copilot Coding Agent、Devin、Factory、Amp |

### 4.5 AGENTS.md vs 其他配置文件

| 文件 | 给谁看 | 用途 |
|---|---|---|
| `README.md` | 人类 | 项目介绍、快速开始、贡献指南 |
| `AGENTS.md` | AI Agent | 构建/测试命令、代码约定、安全注意事项 |
| `.cursorrules` | Cursor 专属 | Cursor 特定的规则（正在被 AGENTS.md 统一） |
| `CLAUDE.md` | Claude Code 专属 | Claude Code 特定的指令 |
| `SKILL.md` | AI Agent | 可复用的技能包（详见 §2 Skills） |

> 💡 **最佳实践**：大项目可以在子目录放多个 AGENTS.md，Agent 会自动读取最近的那个。OpenAI 的主仓库就有 88 个 AGENTS.md 文件。

> 🔗 **官网**：https://agents.md ｜ **GitHub**：https://github.com/agentsmd/agents.md

***

## 5. 四大工程

### 5.1 总览：从"会说话"到"会干活"

大模型本身只能做文字接龙，不断预测下一个 Token。要让它成为可靠的"员工"，需要在四个层次上持续投入：

| 工程 | 一句话 | 解决什么问题 |
|---|---|---|
| **Prompt Engineering** | 怎么跟 AI 说话 | 模型听不懂模糊指令 |
| **Context Engineering** | 给 AI 什么信息 | 模型缺少必要的背景知识 |
| **Harness Engineering** | 给 AI 什么规矩 | 模型行为不可控、不可预测 |
| **Loop Engineering** | 让 AI 自己跑起来 | 单次对话无法完成复杂/持续任务 |

> 💡 **Prompt Engineering 可以理解为 Context Engineering 的子集**，调整说话方式本质上也是在管理上下文。

***

### 5.2 Prompt Engineering（提示词工程）

**直觉**：小 L 很聪明但没经验，你说"帮我写个方案"，他交上来的东西一塌糊涂。你学会了怎么跟他说话：给清楚的背景、明确的要求、提供示例、指定输出格式。

#### 5.2.1 核心原则

Prompt Engineering 是编写和组织 LLM 指令以获得最佳结果的方法。

**OpenAI Prompt 结构建议：**

```markdown
# Identity（身份）
你是一个帮助执行 snake_case 变量命名的编码助手...

# Instructions（指令）
* 定义变量时使用 snake_case（如 my_variable）而非 camelCase
* 使用 var 关键字支持旧浏览器
* 不使用 Markdown 格式，直接返回代码

# Examples（示例）
Q: 如何声明一个 first name 的字符串变量？
A: var first_name = "Anna";

# Context（上下文）
<current_file path="app.js">
// 当前文件内容...
</current_file>
```

#### 5.2.2 消息角色

| 角色                   | 用途                 | 优先级 |
| ---------------------- | -------------------- | ------ |
| `developer` / `system` | 应用开发者提供的指令 | 最高   |
| `user`                 | 终端用户提供的输入   | 中等   |
| `assistant`            | 模型生成的响应       | -      |

**示例：**

```python
messages = [
    {"role": "developer", "content": "你是一个海盗风格的助手"},
    {"role": "user", "content": "JavaScript 中分号是可选的吗？"}
]
```

#### 5.2.3 Few-shot Learning

提供示例帮助模型理解任务模式：

```markdown
# 情感分类示例

Example 1:
Input: "我非常喜欢这个耳机 — 音质太棒了！"
Output: Positive

Example 2:
Input: "电池续航还行，但耳罩感觉很廉价"
Output: Neutral

Example 3:
Input: "客服太差了，再也不会买了"
Output: Negative
```

#### 5.2.4 GPT-5.5 vs Reasoning Models

**GPT 模型**（如 gpt-5.5）：

* 需要明确、详细的指令
* 像给初级同事分配任务：提供明确步骤

**Reasoning 模型**（如 o1）：

* 只需高层目标
* 像给高级同事分配任务：说明目标，他们自己规划

```python
# GPT-5.5 提示：详细指令
"""
1. 读取 input.csv 文件
2. 过滤 age > 18 的行
3. 按 name 排序
4. 输出到 output.csv
"""

# Reasoning 模型提示：高层目标
"""
处理 input.csv，只保留成年人，按姓名排序输出
"""
```

***

### 5.3 Context Engineering（上下文工程）

**直觉**：小 L 虽然会说话了，但他不知道你公司的内部情况。你问他"这个项目进展如何"，他只能瞎猜。你开始给他提供背景资料，比如项目文档、会议记录、数据库查询结果。

![](https://gastigado.cnies.org/d/public/faa261102e46c7f090a2402a49000ffae18c5dd6-2292x1290.webp)

#### 5.3.1 为什么需要 Context Engineering

**来自 Anthropic "Effective Context Engineering for AI Agents"：**

Context（上下文）是 LLM 的有限资源，就像人类的工作记忆。随着上下文增长，模型的注意力预算（attention budget）会被稀释，导致：

* **Context Rot（上下文腐烂）**：信息检索准确性下降
* **注意力分散**：n² 的 Token 关系难以维持
* **位置理解降级**：长上下文中位置编码的准确性下降

#### 5.3.2 最小化高信号 Token 集

**系统提示优化：**

* 避免硬编码脆弱逻辑（太低层）
* 避免模糊高层指导（太高层）
* 找到"Goldilocks Zone"：具体但灵活的启发式规则

**工具设计：**

* 返回 Token 高效的信息
* 鼓励高效的 Agent 行为
* 避免臃肿的工具集

#### 5.3.3 Just-in-Time Context Retrieval

**传统 RAG（预检索）：**

```
用户请求 → 向量检索 → 加载大量文档 → 模型推理
```

**Agentic Search（运行时探索）：**

```
用户请求 → Agent 使用工具导航 → 动态加载相关内容 → 渐进式发现
```

**上下文的来源多种多样**：

* 你手动写进去的背景信息
* RAG 从知识库检索出来的文档（§3）
* MCP 工具调用返回的结果（§1.5）
* Skill 中预置的说明和脚本（§2）
* 历史对话的压缩摘要（Memory）

#### 5.3.4 长时程任务的上下文策略

**Compaction（压缩）：**
将接近上下文窗口限制的对话总结，重新初始化新窗口。

```python
# Claude Code 的 compaction 策略：
# 1. 传递消息历史给模型总结
# 2. 保留架构决策、未解决 bug、实现细节
# 3. 丢弃冗余工具输出
# 4. 加上最近访问的 5 个文件
```

**Structured Note-taking（结构化笔记）：**
Agent 定期写笔记到上下文窗口外的持久化存储。

```markdown
# NOTES.md
## 当前进度
- 已完成用户认证模块
- 正在实现支付集成
- 遇到问题：Stripe webhook 验证失败

## 待办事项
1. 修复 webhook 签名验证
2. 添加支付重试逻辑
3. 编写集成测试
```

**Sub-agent Architecture（子代理架构）：**

* 主 Agent 协调高层计划
* 子 Agent 处理深度技术任务（可能使用数万 Token）
* 子 Agent 只返回压缩摘要（1000-2000 Tokens）

***

### 5.4 Harness Engineering（驾驭工程）

**直觉**：你给小 L 配了工具、给了资料，结果他为了回答"今天几号"，先去买充电器，再去银行取钱，最后把手机都抵押了。虽然最终回答了问题，但过程完全失控。你开始制定规矩：哪些权限要收敛、哪些流程要固定、哪些行为要约束。

#### 5.4.1 什么是 Harness

Harness 是 Agent 运行的环境和基础设施，包括工具、权限、反馈循环和状态管理。

**来自 OpenAI "Harness Engineering"：**

> 人类引导，Agent 执行。我们的角色不再是编写代码，而是设计环境、明确意图、构建反馈循环，让 Codex Agent 能够可靠工作。

#### 5.4.2 知识库即代码

**AGENTS.md 作为目录而非百科全书（§4）：**

```
project/
├── AGENTS.md              # ~100 行，指向其他文档
├── ARCHITECTURE.md        # 系统架构地图
├── docs/
│   ├── design-docs/
│   ├── exec-plans/
│   ├── product-specs/
│   └── QUALITY_SCORE.md
```

**机械化验证：**

* Linters 验证知识库结构
* CI 检查文档交叉引用
* "doc-gardening" agent 定期扫描陈旧文档

#### 5.4.3 Anthropic 的双Agent架构

**来自 "Effective Harnesses for Long-Running Agents"：**

解决长时程任务的上下文连续性问题：

**Initializer Agent（初始化代理）：**

```markdown
任务：设置项目环境

输出：
1. init.sh - 启动脚本
2. tests.json - 200+ 特性列表（全部标记为 failing）
3. claude-progress.txt - 进度日志
4. 初始 git commit
```

**Coding Agent（编码代理）：**

```markdown
每次会话：
1. 运行 pwd 确认目录
2. 读取 git log 和 progress 文件
3. 读取 tests.json 选择下一个特性
4. 运行 init.sh 启动服务
5. 执行基础端到端测试
6. 实现一个特性
7. 测试验证
8. 更新 git 和 progress 文件
9. 标记特性为 passing
```

**关键机制：**

* 每个特性单独实现（增量进度）
* Git commits 提供回滚能力
* 浏览器自动化工具端到端测试
* Progress 文件桥接会话

**Harness 做的事情总结**：

* **权限控制**：Agent 能访问哪些目录、哪些 API
* **行为约束**：AGENTS.md 中定义的代码规范、测试要求（§4）
* **流程固化**：把稳定的工作流写成 Skill 或脚本，不让 Agent 每次自由发挥
* **状态管理**：跨会话的进度追踪、Git 提交记录、进度文件

> 💡 **Harness 不是某个具体的技术**，而是"让不可控的强大智能朝着我们想要的方向走"的所有办法。

***

### 5.5 Loop Engineering（循环工程）

**直觉**：任务越来越复杂，一次对话完不成。你需要 AI 能自己跑循环，比如定时检查、自动修复、持续运行。

#### 5.5.1 什么是 Loop Engineering

**来自 Addy Osmani "Loop Engineering"：**

> Loop Engineering 是设计系统来提示 Agent 的过程，而不是你自己提示它。

**核心思想：**

* 让 Agent 在循环中运行
* 每次迭代观察、计划、执行
* 使用反馈自动修正

> ⚠️ **泼个冷水**：Loop Engineering 本质上就是"定时任务 + Agent 调用"，概念并不新鲜。对大部分人来说，连一个 AGENTS.md 都还没写好，谈什么 Loop Engineering 呢？先把前三步走踏实。

#### 5.5.2 常见 Loop 模式

**Evaluator-Optimizer Loop（评估-优化循环）：**

![Evaluator-Optimizer](https://gastigado.cnies.org/d/public/14f51e6406ccb29e695da48b17017e899a6119c7-2401x1000.webp)

```python
# 文学翻译循环
while not evaluator_satisfied:
    translation = translator_llm(source_text)
    critique = evaluator_llm(translation, source_text)
    if critique.satisfied:
        break
    source_text = f"{source_text}\n\nFeedback: {critique.feedback}"
```

**Ralph Loop（自主修复循环）：**

```python
# Codex 自主工作流
while not task_complete:
    pr = agent.implement_feature(task)
    self_review = agent.review_code(pr)
    agent_reviews = [reviewer.review(pr) for reviewer in agent_reviewers]
    if all(review.approved for review in agent_reviews):
        pr.merge()
        break
    else:
        agent.address_feedback(agent_reviews)
```

**Iterative Repair Loop（迭代修复循环）：**

```python
# OpenAI Cookbook 示例
max_attempts = 5
for attempt in range(max_attempts):
    code = agent.write_code(spec)
    test_results = run_tests(code)
    if test_results.all_passed:
        return code
    spec = f"{spec}\n\nTest failures:\n{test_results.failures}"
```

#### 5.5.3 OpenAI Codex 的自主循环

**来自 "How Agents Are Transforming Work"：**

* 99th percentile 工程师：每天 60+ 小时的 Agent 运行时间
* Agent 并行协作
* 监控 CI，自主解决失败
* 单次 Codex 运行可工作 6+ 小时（通常在人类睡觉时）

**Goal-Directed Loops（目标导向循环）：**

```python
# 使用 Goals API
response = client.responses.create(
    model="gpt-5.5",
    instructions="修复 bug #1234",
    goal="所有测试通过且 bug 不再复现",
    # Agent 会循环直到达成 goal
)
```

#### 5.5.4 Anthropic 的生成-评估循环

**来自 "Harness Design for Long-Running Apps"：**

```python
# 每次生成迭代 5-15 次
for iteration in range(5, 15):
    ui_code = generator_agent.create_ui(spec)
    page = playwright.goto(local_server)
    observations = evaluator_agent.observe(page)
    score = evaluator_agent.score(observations, spec)
    critique = evaluator_agent.critique(observations)
    if score >= threshold:
        break
    spec = f"{spec}\n\nIteration {iteration} feedback:\n{critique}"
```

**动态并行循环：**

```python
# Claude Code 动态工作流
orchestration = agent.generate_orchestration(task)
subagents = orchestration.spawn_parallel_agents()
for result in subagents.results:
    verification = adversarial_verifier.check(result)
    if not verification.passed:
        result.agent.fix(verification.issues)
```

***

### 5.6 四大工程的关系

```
你（老板）
  │
  ├── Prompt Engineering  ── 怎么跟 AI 说话
  │
  ├── Context Engineering ── 给 AI 什么信息
  │       ↑ 包含 Prompt Engineering
  │       ↑ 包含 RAG、Skill、Memory、MCP 返回值
  │
  ├── Harness Engineering ── 给 AI 什么规矩
  │       ↑ AGENTS.md、权限、流程固化
  │
  └── Loop Engineering    ── 让 AI 自己跑起来
          ↑ 定时任务、自动触发、持续运行
```

### 5.7 一切技术的本质

所有这些工程，归根结底就是两件事：

1. **帮 AI 补充信息**：RAG、Search、Skill、Memory，都是往上下文里塞内容
2. **帮人类减少沟通**：Agent 代替你和大模型对话，子 Agent 代替主 Agent 处理子任务

**Agent 是什么？** 就是一个程序，把所有"不需要智能"的部分（文件读取、API 调用、格式转换、权限检查）用代码实现，只在需要"判断"的时候才问大模型。

> 📖 **参考视频**：
>
> * [【闪客】一口气拆穿 Skill/MCP/RAG/Agent 底层逻辑](https://www.bilibili.com/video/BV1ojfDBSEPv/) — 用大白话讲清所有概念的关系
> * [【闪客】你管这破玩意叫 Harness？](https://www.bilibili.com/video/BV1cNdrB4Evw/) — Harness 的来龙去脉
> * [【闪客】新名词诈骗！你管这破玩意叫 Loop Engineering？](https://www.bilibili.com/video/BV1Xg7v6PEr9/) — Loop Engineering 的真相

***

## 6. Agent 工具

### 6.1 Claude Code：Anthropic 官方编码 Agent

Claude Code 是 Anthropic 推出的命令行编码 Agent，支持 Computer Use、文件编辑、浏览器控制和长期会话。

#### 配置文件修改

Claude Code 的配置文件位于：

* **全局**：`~/.claude/settings.json`
* **项目级**：`.claude/settings.json`

> ⚠️ **Claude Code 原生只支持 Anthropic API 格式。** 如果你的自定义端点是 OpenAI 格式（`/v1/chat/completions`），必须先用本地代理网关（如 cc-switch 的代理功能）做 API 格式转换，再填入 `ANTHROPIC_BASE_URL`。

**① 环境变量方式（推荐，立即生效，重启终端需重设）**

```bash
export ANTHROPIC_BASE_URL="https://your-custom-endpoint/v1"
export ANTHROPIC_API_KEY="sk-xxx"

claude   # 启动后自动读取环境变量
```

**② 写入配置文件（永久生效）**

编辑 `~/.claude/settings.json`（或项目内 `.claude/settings.json`）：

```json
{
  "permissions": {
    "allow": ["Read", "Edit", "Write", "Bash"],
    "deny": []
  },
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-custom-endpoint/v1",
    "ANTHROPIC_API_KEY": "sk-xxx"
  }
}
```

> **配置字段说明**
>
> * `permissions.allow`：允许 Agent 操作的工具列表
> * `env.ANTHROPIC_BASE_URL`：你的 Anthropic API 端点（必须是 `/v1` 结尾）
> * `env.ANTHROPIC_API_KEY`：你的 API Key

> ⚠️ Claude Code 不使用 `~/.claude/config.toml`，配置文件为 `settings.json`。`[api]`、`[model]` 等 TOML 分段格式是 Codex 的写法，不适用于 Claude Code。

#### 关闭首次安装强制登录

```bash
# 方法一：环境变量（推荐）
CLAUDE_SKIP_LOGIN=1 claude

# 方法二：写入配置
claude config set --no-forced-login true
```

#### 推理参数调整

Claude Code 的推理参数通过命令行或会话内命令设置，不在配置文件中：

```bash
# 启动时指定
claude --model claude-sonnet-4-20250514 --max-tokens 128000

# 会话内切换
/model claude-sonnet-4-20250514
/effort high
```

#### 引用文件与工具调用

* 引用文件：直接输入 @文件名 或 @文件夹路径，支持多文件同时引用。
* MCP：使用 /mcp 命令管理。
* Skills：使用 /skills 查看和调用。

#### 常用 / 命令

* /new 或 /clear：开启新对话，清空上下文。
* /compress：压缩当前会话上下文，保留核心信息。
* /init：在当前目录初始化项目配置。
* /config：查看或修改当前会话配置。
* /model：切换模型（支持自定义模型）。
* /effort 或 /thinking：设置思考强度（low/medium/high）。
* /fast：快速模式，降低思考深度加速回复。
* /hook：管理会话钩子（pre/post 命令）。
* /login 与 /logout：仅官方 Anthropic 账号可用。
* /permissions：查看和修改 Agent 权限（读写、浏览器、终端等）。
* /plan：让 Claude 先输出详细执行计划。
* /goal：设置长期目标，Agent 会持续追踪。
* /loop：进入自动循环模式，直到目标完成。
* /plugin：管理第三方插件。
* /restore：恢复历史会话。
* /sandbox：进入沙盒环境。
* /status：显示当前 Agent 状态。
* /todo：内置任务管理系统。
* /vim：进入 Vim 编辑模式。
* /ps：查看当前运行的子任务。

***

### 6.2 Codex：OpenAI 官方编码 Agent + oh-my-codex（OMX）

Codex 是 OpenAI 的编码 Agent，搭配 oh-my-codex（OMX）框架后成为目前最强的工程化 Agent 系统。

#### 配置文件（config.toml）

位于 ~/.codex/config.toml：

```toml
[default]
provider = "custom"
base_url = "https://your-api.com/v1"
api_key = "sk-xxx"
model = "gpt-5.5"
reasoning_effort = "high"

[omx]
mode = "ralph"
default_plan_model = "gpt-5.5"
```

#### 引用文件

使用 @文件名 或 @文件夹/，支持递归引用整个目录。

#### MCP 与 Skills

* MCP：Codex 默认自动启用所有可用 MCP，无需手动调用。
* Skills：使用 $ 触发，例如 $deep-interview、$ralplan、$team、$ralph、$ultraqa。

#### 常用 / 命令

* /new、/clear：新对话、清空上下文。
* /compress：压缩会话。
* /init：初始化项目。
* /config：查看修改配置。
* /model：切换模型。
* /effort：设置 reasoning effort（low/medium/high）。
* /fast：快速模式。
* /hook：管理钩子。
* /login、/logout：官方账号登录退出。
* /permissions：权限管理。
* /plan：生成执行计划。
* /goal：设置目标。
* /loop：循环执行模式。
* /plugin：插件管理。
* /restore、/session：会话恢复。
* /sandbox：沙盒模式。
* /status：当前状态。
* /todo：任务管理。
* /vim：Vim 模式。
* /ps：查看进程。

oh-my-codex（OMX）额外提供了 $ralplan（共识规划）、$team（多 Agent 协同）、$ralph（可视化验证循环）等高级工作流。

***

### 6.3 OpenCode：高性能开源编码 Agent

OpenCode 是目前 Stars 最高的开源编码 Agent（16 万+），基于 Go 开发，支持 75+ 模型，提供 TUI 界面和 LSP 支持。

#### 接入模型

```bash
# 方式一
opencode connect

# 方式二（推荐）
opencode login
```

#### 配置文件（opencode.json）

```json
{
  "model": "custom",
  "api_base": "https://your-endpoint/v1",
  "api_key": "sk-xxx",
  "temperature": 0.1,
  "max_tokens": 128000,
  "reasoning_effort": "high"
```

### 6.4 Hermes Agent

Hermes Agent 是 Nous Research 开发的开源 AI 智能体（MIT 许可），本质是「编程 Agent + IM」的组合体。它在 OpenClaw 的基础上进行了彻底重构，专注于自进化能力、稳定性和安全。

#### OpenClaw 与 Hermes 的区别

OpenClaw 是 2026 年初火起来的开源 AI Agent，标志是龙虾，做的事是让 LLM 能干活：工具调用、自动化执行、长期记忆、沙箱、多平台接入。像个开箱即用的数字管家。

两家在本地优先、数据不上云、走即时通讯入口这些方向上一致。分歧在路径：

* **技能来源**：OpenClaw 靠人写（开发者用代码或 Prompt 定义 Skill，稳定可预测，但上限取决于你愿意手写多少）。Hermes 靠涌现（完成复杂任务后自己抽方法存成 Skill，下次直接复用）。
* **记忆方式**：OpenClaw 本质是 RAG，知道信息在哪，需要时去取。Hermes 用分层记忆，额外建了一个用户模型，跨会话记住你的代码风格和技术栈偏好。
* **Token 消耗**：OpenClaw 跨 24 小时任务容易 token 烧完事情只干一半，同样场景早过 10 万 token。Hermes 用户反馈聊很久也能维持在三四万，遇到错误会继续搞到明确成功或失败为止。
* **安全差距**：OpenClaw 增长太快，已披露多个高危 CVE（CVE-2026-25253 的 CVSS 8.8 可一键 RCE），ClawHub 里多次被爆出恶意技能偷凭证。Hermes 更保守，危险操作需人工批准（Tirith 预执行扫描器先检查终端命令），到现在没出现类似的集中高危事件。
* **代码质量**：OpenClaw 的主分支有时直接构建失败，PR 卡 CI、回归 bug 频发。Hermes 核心文件结构干净，CI 投诉远少于 OpenClaw，社区主流评价是「更稳、更注重深度而非广度」。

> 💡 社区主流看法并非替代关系，而是互补：OpenClaw 干活，Hermes 动脑。常见做法是把 Hermes 当规划器挂在 OpenClaw 之上，`hermes claw migrate` 一行命令就能把现有技能、记忆和配置平滑搬过来。

#### 安装接入

安装脚本（Linux / macOS / WSL2 / Android Termux）：

```bash
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
```

安装后进入 Setup Wizard。如果是从 OpenClaw 迁移，向导会自动检测并列出全部可迁移项（配置、记忆、技能、API 密钥等），确认后一键迁移。

**接入自定义模型提供商：**

```bash
hermes model
```

使用方向键选中 Quick setup，按空格勾选后回车。选择自定义提供商，输入 Base URL、API Key 和模型名称。

配置文件位于 `~/.hermes/config.yaml`（模型与推理参数）和 `~/.hermes/.env`（API Key）：

```yaml
# ~/.hermes/config.yaml 示例
model:
  provider: custom
  base_url: https://your-custom-endpoint/v1
  name: claude-sonnet-4-20250514
  max_tokens: 128000
  temperature: 0.1
  reasoning_effort: high
```

安装与迁移详情参考官方迁移文档：[从 OpenClaw 迁移到 Hermes Agent 保姆级教程](https://hs.cnies.org/archives/openclaw2hermes-migration)。

#### 引用文件（@）

直接输入 `@文件名` 或 `@文件夹路径`，支持递归引用整个目录。拖拽文件同样生效。

#### / 命令与常用指令

Hermes 的 `/` 命令风格接近 Claude Code，但提示词优化更强：

* `/skills`：列出可用 Skills，选择编号调用（与 OpenCode 流程一致）。
* `/mcp`：管理 MCP Server（同 `/skills` 选择流程）。
* `/init`：在当前目录初始化项目配置与 AGENTS.md。
* `/model`：切换模型或重新配置提供商。
* `/effort` 或 `/thinking`：设置推理强度（low/medium/high）。
* `/variants`：生成多个方案对比。
* `/plan`：生成结构化执行计划。
* `/computer`：启用 Computer Use（截图、鼠标、键盘控制）。
* `/bash`：执行终端命令。
* `/edit`：编辑文件。
* `/browser`：浏览器控制与抓取。
* `/gateway setup`：重新配置网关与聊天平台。
* `/pairing approve <平台> <配对码>`：绑定 IM 平台账号。

#### Computer Use

通过 `/computer` 激活，支持桌面环境截图、鼠标点击、键盘输入，稳定性优于 OpenClaw。配合长期记忆机制，Hermes 可以跨会话记住操作习惯。

#### 网关与 IM 集成

将网关注册为系统服务后可开机自启：

```bash
hermes gateway setup
```

支持飞书、Telegram、Discord、Slack 等平台接入。推荐配合 AstrBot 作为常驻机器人使用（详见 AstrBot 章节）。

***

### 6.5 Oh My Pi（OMP）

**OMP 是 oh-my-codex（OMX）的 Rust 重写版**，保留了 OMX 的全部工作流能力（`$ralph`、`$team`、`$deep-interview`、`$ultraqa`），同时提供：

* **Rust 原生运行时**：内存占用远低于 Node.js 版本，启动速度快 3-5 倍
* **完整 OMX 生态兼容**：`.omx/` 目录、`$` 命令、Skills、MCP 配置均与 OMX 100% 兼容
* **LSP/DAP 集成**：内置语言服务器协议和调试器支持（OMX 不具备）

> 💡 **官网**：https://omp.sh ｜ **GitHub**：https://github.com/Yeachan-Heo/oh-my-codex（同一仓库，Rust 版在 `omp/` 分支）

#### 配置文件修改（自定义 API）

主配置文件位于 `~/.omp/config.toml`（或项目内 `.omp/config.toml`）：

```toml
[default]
provider = "custom"
base_url = "https://your-custom-endpoint/v1"
api_key = "sk-xxx"
model = "gpt-5.5"
reasoning_effort = "high"
temperature = 0.1
max_tokens = 128000

[omx]
mode = "ralph"
default_plan_model = "gpt-5.5"
```

**推理参数修改**：直接编辑 `[default]` 下的 `reasoning_effort`、`temperature` 等字段，或运行 `omp model` 进入交互式配置。

#### 引用文件（@）

使用 `@文件名` 或 `@文件夹/`，支持递归引用整个目录。

#### MCP 与 Skills

OMP 的命令风格与 Codex/OMX 一致，但部分命令使用冒号语法以区分：

* `/skills:` 或 `/skills`：列出 Skills，选择或直接输入名称调用（OMP 推荐 `/skills:` 精确匹配）。
* `/mcp:`：管理 MCP Server（同 `/skills:` 流程）。

#### 常用 / 命令

* `/init`：初始化项目与 AGENTS.md。
* `/model`：切换模型。
* `/effort`：设置 reasoning effort（low/medium/high）。
* `/variants`：生成多个方案对比。
* `/plan`：生成结构化计划（支持 `$ralplan` 共识规划）。
* `/goal`：设置持久化目标，Agent 循环直到完成。
* `/compress`：压缩上下文。
* `/status`：查看当前状态与 HUD。
* `/todo`：内置任务管理。

#### 特色功能

* 极致轻量：Rust 实现，内存占用远低于 Node.js 版本。
* 完整 OMX 工作流支持：`$deep-interview` → `$ralplan` → `$ralph` / `$team`。
* `$team`：启动多 Agent 协同模式，tmux 并行 Worker 在独立 git worktree 中工作。
* `$ralph`：启动可视化验证循环，不完成不停止。
* `$ultraqa`：对抗性动态 QA 工作流。
* HUD 实时监控：`omp hud --watch`。
* 持久化状态：`.omx/` 目录存储计划、日志、状态，跨会话不丢失。

***

### 6.6 AstrBot

AstrBot 是一个轻量、高扩展性的多平台机器人框架（支持 QQ、微信、Telegram、Discord、飞书等），可与 Hermes / OMP 等 Agent 深度集成，实现「聊天即编程」的完整闭环。适合需要长期驻留、接受自然语言指令的场景。

#### 核心特性

* 多平台统一接入：一套配置同时支持多个 IM 平台。
* 插件化架构：轻松扩展 Skills 与 MCP。
* 与 Hermes 深度整合：可作为 Hermes 的前端 IM 层，常驻运行并转发指令。
* 轻量高效：资源占用低，适合在 VPS 或本地常驻。

#### 安装与配置

```bash
# 安装 AstrBot
pip install astrbot

# 或使用官方脚本
curl -fsSL https://raw.githubusercontent.com/AstrBot/AstrBot/main/install.sh | bash
```

配置文件示例（`config.yaml`）：

```yaml
bot:
  platforms:
    - type: feishu
      app_id: your_app_id
      app_secret: your_app_secret
    - type: telegram
      token: your_telegram_token

agent:
  backend: hermes   # 或 omp
  endpoint: http://localhost:8080
```

#### 与 Hermes / OMP 结合使用

1. Hermes / OMP 启动网关后，AstrBot 通过 WebSocket 或 HTTP 连接。
2. 用户在 IM 中 @机器人 或发送消息，即可触发 Agent 执行任务。
3. 结果自动回传到聊天平台，支持长期记忆与 Skill 复用。

#### 常用命令

* `astrbot start`：启动机器人。
* `astrbot plugin install <name>`：安装插件。
* `astrbot config`：编辑配置。
* 支持 `/skills`、`/mcp` 等透传命令直接转发给后端 Agent。

AstrBot 让 Hermes / OMP 从「终端工具」变成「常驻数字员工」，特别适合需要 24/7 响应的场景。

### 6.7 编码 Agent 增强工具

这类工具不从零造轮子，而是在现有编码 Agent（Claude Code、Codex、OpenCode 等）之上叠加能力层：统一管理 Provider、解锁受限功能、注入子智能体和工作流。

#### 6.7.1 cc-switch：多 CLI 统一管理

> 一个桌面应用，统一管理 7 个 AI 编码工具的 Provider 配置，告别手动编辑 JSON/TOML/.env。

* **GitHub**: https://github.com/farion1231/cc-switch
* **Stars**: 89K+ | **协议**: MIT | **技术栈**: Tauri 2 (Rust)
* **平台**: macOS 12+、Windows 10+、Linux（Ubuntu/Debian/Fedora/Arch）

**支持的 CLI 工具：**

| CLI | 配置文件 |
|---|---|
| Claude Code | `~/.claude/settings.json` |
| Claude Desktop | 通过本地代理网关（v3.16+） |
| Codex | `~/.codex/config.toml` + `auth.json` |
| Gemini CLI | `~/.gemini/.env` + `settings.json` |
| OpenCode | `~/.config/opencode/opencode.json` |
| OpenClaw | `~/.openclaw/openclaw.json` |
| Hermes Agent | `~/.hermes/config.yaml` + `.env` |

**核心功能：**

1. **50+ Provider 预设**：AWS Bedrock、NVIDIA NIM、各种中转服务，粘贴 API Key 即可切换
2. **本地代理热切换**：处理不同 Provider 的 API 格式转换，支持自动故障转移；Claude Code 支持不重启终端热切换
3. **系统托盘快速切换**：不打开主界面，直接从托盘换 Provider
4. **统一 MCP 管理**：一个面板管理所有 CLI 的 MCP Server，支持双向同步
5. **统一 Skills 管理**：从 GitHub 仓库或 ZIP 一键安装 Skill
6. **Deep Link 协议**：`ccswitch://` URL 一键导入配置
7. **CLI 版本**：cc-switch-cli 提供 TUI + CLI 双模式，适合脚本自动化

**安装：**

```bash
# macOS
brew install --cask cc-switch
# Windows：从 GitHub Releases 下载 .msi
# Linux：从 GitHub Releases 下载 .deb / .AppImage
```

#### 6.7.2 oh-my-codex（OMX）：Codex 工作流增强

> 为 Codex CLI 添加结构化工作流、子智能体编排和持久化状态，让 Codex 从"单次对话"变成"自主开发循环"。

* **GitHub**: https://github.com/Yeachan-Heo/oh-my-codex
* **Stars**: 29K+ | **协议**: MIT

**核心工作流：**

```bash
# 标准路径：访谈 → 计划 → 执行
$deep-interview "把认证模块从 session 迁移到 JWT"
# [回答问题，审核计划]
$ralph "执行已批准的认证迁移计划"

# 并行模式：3 个 worker 并行执行
$team 3:executor "并行执行认证迁移计划"
```

**主要功能：**

1. **结构化工作流**：`$deep-interview`（需求澄清）→ `$ralplan`（计划共识）→ `$ralph`（单人执行循环）→ `$team`（多人并行）
2. **tmux 并行 Worker**：每个 Worker 在独立 git worktree 中工作，互不干扰
3. **持久化状态**：`.omx/` 目录存储计划、日志、状态，跨会话不丢失
4. **33 个专业 Agent Prompt**：architect、debugger、verifier、researcher 等角色
5. **36 个内置 Skill**：TDD、代码审查、战略规划等
6. **HUD 监控**：`omx hud --watch` 实时查看会话状态
7. **Goal 模式**：`/goal` 命令设定持久化目标，Agent 循环直到完成

**安装：**

```bash
codex plugins add oh-my-codex
# 或
npx oh-my-codex setup
```

#### 6.7.3 codex++：Codex Desktop 解锁增强

> Codex App 的外部增强启动器，通过 CDP 注入解锁受限功能（如 API Key 模式下的插件市场、区域锁定的 Computer Use）。

* **GitHub**: https://github.com/nicepkg/codex++
* **Stars**: 1.1K+（发布 9 天内）

**解决问题**：Codex Desktop 部分功能按订阅等级或地区锁定（如 Computer Use 仅部分地区可用、API Key 模式无法使用插件市场）。

**核心功能：**

1. **插件入口解锁**：API Key 模式下也能使用插件市场
2. **Computer Use 解锁**：为区域锁定用户（如 EU）启用 Computer Use 插件
3. **会话管理增强**：真正的会话删除（带确认和撤销）、会话在普通聊天和本地项目间移动
4. **Markdown 导出**：带时间戳的对话导出
5. **对话时间线导航**：快速跳转到对话历史中的任意节点
6. **Provider Sync**：切换 Provider 后保留历史会话的可见性
7. **Codex++ 菜单**：在 Codex App 中注入增强菜单

**工作原理**：不修改 Codex 安装文件，通过 Chromium DevTools Protocol 参数启动 Codex，运行本地辅助服务，向渲染进程注入增强脚本。

> ⚠️ **注意**：codex++ 是社区工具，非 OpenAI 官方。使用前了解风险，且功能可能随 Codex 更新而失效。

#### 6.7.4 Oh My Openagent：OpenCode 增强框架

> 为 OpenCode 注入子智能体系统、后台代理、AST 工具和 MCP 集成，完全兼容 Claude Code 的 hooks/commands/skills/plugins。

* **GitHub**: https://github.com/code-yeongyu/oh-my-openagent
* **npm**: https://www.npmjs.com/package/oh-my-openagent
* **官网**: https://ohmyopenagent.com

**核心功能：**

1. **多智能体系统**：Hephaestus（编码）、Prometheus（规划）、Oracle（架构/调试）、Librarian（文档/搜索）、Explore（快速代码库检索）、Multimodal Looker
2. **后台代理**：多个 Agent 并行运行——GPT 调试时 Claude 尝试不同方案，Gemini 写前端时 Claude 处理后端
3. **AST 工具**：重构、重命名、诊断、AST 感知代码搜索
4. **Hash 锚定编辑**：`LINE#ID` 引用在应用前验证内容，零过期行错误
5. **Claude Code 完全兼容**：你的 hooks、commands、skills、MCP、plugins 全部直接可用
6. **内置 MCP**：websearch（Exa）、context7（文档）、grep\_app（GitHub 搜索），运行时自动注入
7. **Skill 内嵌 MCP**：Skill 自带 MCP Server，无需额外配置
8. **Ralph Loop**：自引用循环，不完成不停止
9. **`/init-deep`**：自动生成层级化 `AGENTS.md` 文件
10. **Team Mode（v4.0）**：tmux 布局中同时监控所有 Agent 成员

**安装：**

```bash
# 在 opencode.json 中添加插件
{
  "plugins": ["oh-my-openagent"]
}
# 或使用 Claude Code 兼容模式
npx oh-my-openagent setup
```

#### 6.7.5 Agents Anywhere：跨设备远程控制编码 Agent

> 从手机控制运行在 Mac/Windows/Linux 上的 Codex、Claude Code 等编码 Agent。代码留在本地设备，手机只是遥控器。

* **GitHub**: https://github.com/anywhere-labs/Agents-Anywhere
* **Stars**: 400+ | **协议**: 开源 | **技术栈**: FastAPI + Next.js + Android/iOS

**解决的问题**：Agent 在电脑上跑着，人离开了怎么办？Agents Anywhere 让你用手机查看会话、审批操作、预览文件、打开终端。

**功能：**

1. **统一会话管理**：创建、查看、置顶、归档、接管远程会话
2. **Codex 深度集成**：运行时发现、会话同步、时间线更新、审批、中断/接管
3. **Claude Code 基础支持**：会话发现和基本控制流（深度能力还在完善）
4. **文件浏览**：远程浏览工作区、读写文件、上传下载
5. **远程终端**：执行 shell 命令、交互式终端
6. **设备配对**：通过 Connector 桌面应用或 CLI 配对 Mac/Windows/Linux
7. **自托管后端**：FastAPI + SQLite/PostgreSQL，Docker 一键部署
8. **多客户端**：Web 控制台 + Android APK（iOS 开发中）

**架构：**

```
手机/Web → FastAPI Server → Connector（本地守护进程）→ Codex/Claude 运行时
```

**支持的 Agent：**
| Agent | 状态 | 说明 |
|---|---|---|
| Codex | ✅ 完整支持 | 会话同步、审批、终端、文件访问 |
| Claude Code | ✅ 基础支持 | 会话发现和基本控制，深度能力在完善中 |
| Cursor / OpenCode / Gemini CLI | 🔜 即将支持 | 适配器开发中 |

**快速部署：**

```bash
POSTGRES_PASSWORD=change-me \
AGENT_SERVER_SECRET=change-me-too \
docker compose -f docker/docker-compose.postgres.yml up --build
# 访问 http://127.0.0.1:5174
```

**中国区**：Beta 服务已上线，免费试用，仅对中国用户开放。加入企微/飞书/QQ 群申请。

2026 年出现了"从手机控制编码 Agent"的赛道，三类产品各有侧重：

| 维度 | Agents Anywhere | Codex Mobile | Claude Code Remote Control |
|---|---|---|---|
| **发布方** | 开源社区 | OpenAI 官方 | Anthropic 官方 |
| **形态** | 独立 App + 自托管 Server | 集成在 ChatGPT App 内 | `claude remote-control` + 扫码 |
| **支持的 Agent** | Codex + Claude（更多开发中） | 仅 Codex | 仅 Claude Code |
| **Worker 机器** | Mac/Windows/Linux | 仅 macOS | Mac/Linux/Windows |
| **费用** | 免费开源，可自托管 | 免费起（所有 ChatGPT 计划） | 需 Claude Pro 或更高 |
| **推送审批** | ✅ | ✅ 锁屏卡片 | ✅ |
| **模型切换** | 跟随 Agent 本身 | ✅ Codex 系列模型 | ✅ Sonnet/Opus/Haiku |
| **自托管** | ✅ | ❌ | ❌ |
| **优势** | Agent 无关、开源、自托管 | 零配置、免费、ChatGPT 生态 | Claude 原生、三平台支持 |

**其他竞品**：

* **Omnara**：iOS/Android App，专注 Claude Code 远程控制，语音优先
* **CodeAgent Mobile**：支持 Claude Code + Codex + Cursor + Copilot 等多 Agent
* **vibetunnel**：把 Mac 终端代理到浏览器，4.4K Stars，专为看 Agent 输出设计

> 💡 **怎么选**：只用 Codex → Codex Mobile 零配置够用。只用 Claude Code → 官方 Remote Control 最方便。两者都用或要自托管 → Agents Anywhere。

### 6.8 工作流

开源工作流框架让你用代码或可视化界面构建 **AI 驱动的自动化管道**。2026 年主流方案已从"简单链式调用"进化到"**Agentic Workflow**"（智能体自主决策工作流）。

#### 6.8.1 LangChain / LangGraph（最成熟的 Agent 框架）

> LangChain 负责"搭积木"，LangGraph 负责"搭蓝图"。2026 年两者均已进入 v1.0，是企业级复杂 Agent 的首选。

* **官网**: https://www.langchain.com
* **GitHub**: https://github.com/langchain-ai/langchain （125K+ Stars）
* **语言**: Python / JavaScript | **协议**: MIT

**具体功能：**

* **LangChain 核心组件**：
  * LCEL 声明式管道：`chain = prompt | llm | parser`
  * 1000+ 集成（模型、向量库、工具、记忆、评估）
  * 高级记忆系统（`ConversationBufferWindowMemory`、`SummaryMemory`、`EntityMemory`）
  * 结构化输出（`.with_structured_output()` + Pydantic）
  * Corrective RAG、Self-RAG 等高级检索模式

* **LangGraph 核心功能**：
  * `StateGraph` + `add_node` / `add_edge` / `add_conditional_edges`
  * **持久化检查点**（Checkpoint）：支持中断、恢复、时间旅行调试
  * **Human-in-the-Loop**：任意节点可暂停等待人工审批
  * **并行节点执行**：大幅降低多步流程延迟
  * **Fault Tolerance**：内置自动重试、超时控制、错误处理器

* **LangSmith**：全链路追踪、提示优化、离线评估、自动化回归测试

* **Deep Agents**：专为长时间运行任务设计的 Agent harness（规划 → 上下文管理 → 多 Agent 协作）

**典型代码示例：**

```python
from langgraph.graph import StateGraph, END
from langchain_core.messages import add_messages
from typing import TypedDict, Annotated

class AgentState(TypedDict):
    messages: Annotated[list, add_messages]

workflow = StateGraph(AgentState)
workflow.add_node("research", research_node)    # 研究节点
workflow.add_node("critic", critic_node)        # 评审节点
workflow.add_node("writer", writer_node)        # 写作节点

workflow.add_conditional_edges("research", route_to_next)  # 条件路由
workflow.add_edge("critic", "writer")
workflow.add_edge("writer", END)

# 持久化检查点：支持中断恢复和时间旅行调试
app = workflow.compile(checkpointer=MemorySaver())
```

**真实案例**：Klarna 使用 LangGraph 构建客服 Agent，替代 700 名人工客服，节省约 4000 万美元/年。

**适用场景**：复杂多 Agent 系统、RAG 管道、需要精细状态控制和长期运行的生产级项目。

> 💡 **LangChain vs LangGraph**：LangChain 是"积木"（组件/工具），LangGraph 是"蓝图"（流程/控制）。简单任务用 LangChain，需要状态管理和循环的复杂 Agent 用 LangGraph。

#### 6.8.2 n8n（自动化 + AI 的最佳平衡）

> 拥有 400+ 原生集成节点的可视化工作流平台，2026 年 AI Agent 节点已高度成熟，被称为"自动化领域的瑞士军刀"。

* **官网**: https://n8n.io
* **GitHub**: https://github.com/n8n-io/n8n （194K+ Stars）
* **语言**: TypeScript | **协议**: Fair-code

**具体功能（2026 版）：**

1. **AI Agent 节点**：原生集成 LangChain，支持工具调用、记忆、RAG 管道
2. **400+ 集成节点**：覆盖 CRM、ERP、数据库、邮件、社交、云存储等几乎所有常用服务
3. **核心 AI 节点**：
   * AI Agent、Vector Store、Embeddings、LLM Chain、Code（支持 LangChain 代码节点）
   * 多模态处理（Gemini、GPT-4o 等图像/视频节点）
4. **强大自动化能力**：Webhook、Cron 定时、错误重试、子工作流嵌套
5. **触发机制**：Webhook、定时调度、邮件触发、文件监控、消息队列
6. **自托管特性**：队列模式、横向扩展、VPC 支持、Docker 一键部署

**典型工作流示例：**

```
客户邮件进入 → AI 意图分类 → 自动创建 Jira 工单 → 生成回复邮件 → Slack 通知负责人
PDF 发票上传 → OCR 提取 → LLM 结构化解析 → 写入数据库 → 发送财务通知
```

**定价**：自托管完全免费；云版约 €24/月起。

**定位**：最适合**把 AI 能力嵌入现有业务流程**的团队。

#### 6.8.3 Dify（最易用的开源 LLM 应用平台）

> GitHub 111K+ Stars 的开源 LLM 应用开发平台，主打"可视化 + RAG + Agent"一站式体验，被称为"开源版的 LangChain + Retool"。

* **官网**: https://dify.ai
* **GitHub**: https://github.com/langgenius/dify （111K+ Stars）
* **语言**: Python（FastAPI）+ Next.js | **协议**: Apache-2.0

**具体功能（2026 最新）：**

1. **可视化工作流构建器**：DAG 图结构，支持分支、循环、并行执行、代码节点
2. **企业级 RAG 知识库**：
   * 支持 PDF、Word、Excel、网页等多种格式上传
   * 灵活分块策略、可调检索参数
   * 内置 Weaviate 向量数据库，也支持 Qdrant、pgvector、Milvus
3. **Agent 编排**：内置 ReAct、Plan-and-Execute、Function Calling 等多种 Agent 模板
4. **工具系统**：100+ 内置工具 + 自定义工具 + MCP 支持
5. **模型管理**：集成数百个 LLM 提供商（OpenAI、Anthropic、Google、本地模型）
6. **可观测性**：原生集成 Langfuse、Opik、Arize Phoenix 进行 trace 追踪
7. **团队协作**：工作空间、角色权限、审批流、审计日志
8. **插件系统**：Dify Marketplace 提供社区插件

**快速部署：**

```bash
git clone https://github.com/langgenius/dify.git
cd dify/docker
docker compose up -d
# 访问 http://localhost/install 开始配置
```

**定价**：自托管免费；云版 $59/月起（有免费层）。

**适用场景**：快速构建生产级 RAG 应用、内部知识助手、智能客服、报告生成器。

### 6.9 其他商业工作流平台

商业平台以**零代码 + 托管服务**为核心，适合非技术人员快速落地 AI 工作流。

#### 6.9.1 Google Opal（自然语言驱动的工作流构建器）

> Google Labs 出品，用自然语言描述需求即可自动生成工作流的实验性平台，2026 年已成为 Gemini 生态的重要组件。

* **官网**: https://opal.withgoogle.com
* **模型**: Gemini 3 Flash | **定价**: 完全免费（实验性产品）

**具体功能：**

1. **自然语言生成工作流**：输入"帮我做一个 YouTube 视频总结工具"，自动生成完整流程
2. **Agent 步骤**（2026.2 重磅更新）：Agent 自主选择工具、模型和路由逻辑，而非固定步骤
3. **持久化记忆**：跨会话记住上下文
4. **动态路由**：根据自定义逻辑选择不同执行路径
5. **交互式聊天**：工作流中可嵌入用户输入节点
6. **多模态原生支持**：文本、图片、视频、音频（集成 Veo、Imagen）
7. **模板库 + Remix**：可基于他人作品一键修改
8. **一键分享**：生成公开链接，无需部署

**典型案例**：输入"YouTube 视频链接"→ 自动总结内容 → 生成美观网页 → 输出分享链接。

**定位**：极致易用，适合快速原型验证和个人/小团队轻量工具开发。

#### 6.9.2 Coze（扣子）：字节跳动 AI Bot 工厂

> 国内最成熟的零代码 AI 智能体开发平台，强调"快速搭建 + 多平台发布"。

* **官网**: https://www.coze.com（国际版）/ https://www.coze.cn（国内版）
* **母公司**: 字节跳动 | **定价**: 免费层可用，Pro 约 $9/月

**具体功能：**

1. **可视化工作流编排**：拖拽式构建，支持循环、条件分支、并行、代码节点、变量管理
2. **知识库**：多格式文档自动向量化，支持分段策略和 RAG 检索增强
3. **插件系统**：100+ 官方插件 + 社区技能商店
4. **长期记忆**：Bot 可跨对话记住用户偏好和历史信息
5. **多渠道发布**：一键发布到飞书、微信、Discord、Telegram、网页等多平台
6. **多模型支持**：GPT-4、Claude、Gemini、豆包等
7. **内置数据库**：KV 数据库，工作流可读写结构化数据
8. **扣子空间**（企业版）：团队协作、权限管理、企业知识库、VPC 私网连接

**与 Dify 的区别：**
| 维度 | Coze（扣子） | Dify |
|---|---|---|
| 定位 | Bot 构建 + 发布平台 | LLM 应用开发平台 |
| 上手门槛 | 极低，面向非技术用户 | 低，但开发者更友好 |
| 发布渠道 | 多平台一键发布 | API + Web 嵌入 |
| 自托管 | ❌ 仅 SaaS | ✅ 开源自托管 |
| 国内生态 | ✅ 飞书/微信/抖音 | ✅ 但需自建渠道 |

**优势**：国内生态极佳，上手门槛极低，特别适合要做 IM 机器人或内部工具的团队。

#### 6.9.3 ChatGPT GPTs / Custom Actions

> OpenAI 官方自定义 GPT 生态，通过知识上传 + Actions（API 连接）打造专属助手。

**2026 现状：**

1. **Custom GPTs**：上传文件作为知识库、设定严格指令、固定人格
2. **Actions**：通过 OpenAPI Schema 连接外部服务（功能已被弱化，但仍可使用）
3. **GPT Store**：支持发布和商业变现
4. **Code Interpreter + Advanced Data Analysis**：GPT 内执行 Python 代码，处理数据和文件

**局限性：**

* Actions 调试困难，错误处理有限
* 不支持可视化工作流编排（相比 Coze/Dify/n8n）
* 数据隐私依赖 OpenAI 平台

> 💡 **定位**：更像是"带知识的增强版个人助手"，而非工作流平台。适合个人快速定制，不适合企业级自动化。

#### 6.9.4 其他值得关注

| 平台 | 特点 | 适合场景 |
|---|---|---|
| **Zapier AI** | 7000+ 应用集成，AI 增强自动化 | 业务流程自动化（非 AI 原生） |
| **Make（Integromat）** | 可视化场景构建，复杂逻辑支持 | 多步骤跨应用自动化 |
| **FastGPT** | 国产开源，知识库 + 工作流 | 中文场景 RAG 应用 |
| **Flowise** | LangChain 可视化前端，自托管 | 开发者快速原型 |
| **Voiceflow** | 语音 + 聊天 Bot 设计 | 客服/语音助手场景 |

#### 6.9.5 如何选择工作流平台？

```mermaid
graph TD
    A[你的核心需求] --> B{是否需要自托管？}
    B -- 是 --> C[Dify / n8n / LangGraph]
    B -- 否 --> D{团队技术水平？}
    D -- 非技术为主 --> E[Coze 或 Google Opal]
    D -- 有开发者 --> F[LangGraph 或 Dify]
    E -- 需要强国内生态 --> G[Coze]
    E -- 追求极致简单 --> H[Google Opal]
```

> 💡 **趋势**：2026 年的方向是"Agentic Workflow"——不再是固定的 if-else 流程，而是 Agent 根据目标、上下文和可用工具自主规划执行路径。Google Opal 的 Agent 步骤、Coze 的工作流节点、Dify 的 Agent 节点、LangGraph 的状态图都在朝这个方向演进。

***

## 7. Codex 常见问题与解决方案

### 7.1 HTTP 状态码错误

#### 7.1.1 413 Request Entity Too Large（请求实体过大）

**错误信息**：

```
unexpected status 413 Payload Too Large: <html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>openresty</center>
</body>
</html>, url: https://api.xxxx.xyz/responses, cf-ray: axxxxxxxxxx-NRT
```

**原因**：单次请求的 Token 数量过多（上下文 + 文件 + 图片），或一次性上传大量文件/图片。中转站通常有更严格的请求大小限制。

**解决方案**：

1. **压缩上下文**：使用 `/compress` 命令压缩当前会话
2. **减少历史消息**：使用 `/new` 或 `/clear` 开启新对话
3. **分批处理**：避免一次性发送多张图片或大文件
4. **检查中转站限制**：如果使用中转站，确认其单请求大小限制

#### 7.1.2 403 Forbidden（禁止访问）

**错误信息**：

```json
{"code":"INSUFFICIENT_BALANCE","message":"Insufficient account balance"}
```

**原因**：

* 余额不足（最常见）
* 地区/IP 不支持（中国大陆常见）
* 权限问题（模型未授权、组织限制）
* 中转/代理认证失败

**解决方案**：

1. **余额不足**：立即充值
2. **检查 API Key**：确认 Key 正确、未过期、匹配当前组织
3. **地区限制**：使用支持地区的代理/VPN（注意合规）
4. **重新登录**：运行 `codex auth login` 重新认证
5. **确认模型权限**：部分高级模型需单独申请

#### 7.1.3 503 Service Unavailable（服务不可用）

**错误信息**：

```
The engine is currently overloaded, please try again later.
```

**原因**：OpenAI 服务器高负载、维护中、模型容量不足，或中转站后端问题。

**解决方案**：

1. **等待重试**：等待 10-60 秒后重试（使用 exponential backoff）
2. **切换模型**：从高负载模型换成更稳定的模型
3. **检查状态页**：访问 status.openai.com 查看服务状态
4. **更换中转站**：如果使用中转站，换一个节点或降低请求频率

#### 7.1.4 429 Too Many Requests（请求过多）

**错误信息**：

```
Rate limit reached
You exceeded your current quota
tokens_exceeded_error
```

**原因**：超过 RPM（每分钟请求）、TPM（每分钟 Token）、每日/每周配额，或会话限制。

**解决方案**：

1. **实现指数退避**：使用 exponential backoff 重试机制
2. **减少请求频率**：缩短上下文，减少调用次数
3. **检查使用量**：访问 platform.openai.com/usage 查看配额
4. **注意会话上限**：Codex 有每 3 小时消息数限制

#### 7.1.5 401 Unauthorized / Invalid Authentication（认证失败）

**错误信息**：

```
Incorrect API key provided
Invalid Authentication
```

**原因**：API Key 错误、过期、复制不完整、组织不匹配、缓存问题。

**解决方案**：

1. **重新生成 Key**：访问 platform.openai.com/settings/organization/api-keys
2. **清除缓存**：清除浏览器/客户端缓存
3. **检查配置**：确认环境变量或配置文件中的 Key 正确
4. **检查组织 ID**：确认是否需要组织 ID

#### 7.1.6 400 Bad Request（请求无效）

**错误信息**：

```
context_length_exceeded
invalid_request_error
OperationNotSupported
```

**原因**：

* 上下文长度超过模型限制
* 参数错误（model 名拼错、temperature 范围错）
* JSON 格式无效

**解决方案**：

1. **缩短 prompt**：使用更长上下文模型（如支持 128k+ 的模型）
2. **检查参数**：参考官方 API 文档验证请求体
3. **验证 JSON**：检查格式和必填字段

#### 7.1.7 其他常见错误

| 错误代码 | 原因 | 解决方案 |
|---|---|---|
| **500** | 服务器内部错误 | 等待后重试，或切换模型 |
| **402** | 账号欠费或需要升级计划 | 充值或升级账号 |
| **404** | 模型不存在或 endpoint 错误 | 检查 model 名称和 API 地址 |
| **Timeout / 408** | 请求超时 | 增加超时设置、简化 prompt |
| **Moderation** | 内容被安全过滤 | 修改 prompt 避免敏感词 |

### 7.2 内容安全与使用限制

#### 7.2.1 Cyber Abuse 警告

**什么是 Cyber Abuse？**

OpenAI（ChatGPT、Codex 等）的使用政策中明确禁止 Cyber Abuse。定义如下：

> "Cyber Abuse" means unauthorized access, exploitation, credential theft, data exfiltration, malware or destructive capabilities, social engineering, evasion, lateral movement, denial-of-service activity, or assistance to any sanctioned entities or identified malicious cyber actors.

**简单翻译**：禁止使用 GPT 协助进行网络攻击或恶意网络行为，包括：

* 黑客攻击（未经授权访问系统）
* 凭证窃取 / 撞库
* 制作恶意软件（malware）
* 社会工程学（钓鱼、社会操纵）
* DDoS、数据窃取、横向移动等
* 帮助恶意黑客

**例外**：允许防御性、研究、教育、红队测试（red teaming）、漏洞分析等合法安全研究，只要不造成实际伤害、不针对真实系统未经授权使用。

**为什么会触发警告？**

1. 你询问了编写 exploit、payload、钓鱼邮件、破解方法、恶意脚本等内容
2. 即使是"学习目的"，GPT 的安全过滤器（moderation）也会检测到高风险关键词并发出警告或拒绝
3. 多次触发可能导致账号被限流、警告邮件，甚至临时/永久封禁

**如何避免**：

1. 明确说明是学习/研究目的
2. 避免请求具体的攻击代码
3. 使用防御性安全研究的表述方式
4. 遵守 OpenAI 使用政策

### 7.3 最佳实践

#### 7.3.1 上下文管理

1. **定期压缩**：长会话使用 `/compress` 命令
2. **分批处理**：大任务拆分成多个小会话
3. **清理历史**：定期使用 `/new` 开启新对话
4. **避免重复**：不要重复发送相同内容

#### 7.3.2 错误处理

1. **实现重试机制**：对临时性错误（503、429）使用指数退避
2. **监控配额**：定期检查使用量，避免意外超限
3. **备份 API Key**：准备多个 Key 以备不时之需
4. **记录错误**：记录错误信息便于排查

#### 7.3.3 安全建议

1. **保护 Key**：不要在代码中硬编码 API Key
2. **使用环境变量**：通过环境变量或配置文件管理 Key
3. **定期轮换**：定期更换 API Key
4. **监控使用**：设置使用量告警，防止异常消耗

---

---
url: https://ain.hmgf.hxcn.space/writing.md
description: LaTeX 排版与学术写作教程，从入门到精通。
---

# 写作教程

---

---
url: https://ain.hmgf.hxcn.space/writing/01-LaTeX-Introduction.md
---

# LaTex 的基本介绍

## 一、TEX

TEX 是高德纳 (Donald E.Knuth) 开发的、以排版文字和数学公式为目的的一个计算机软件。高德纳从 1977 年开始开发 TEX ，以发掘当时开始用于出版工业的数字印刷设备的潜力。正在编写著作《计算机程序设计艺术》的高德纳，意图扭转排版质量每况愈下的状况，以免影响他的出书。我们现在使用的 TEX 排版引擎发布于 1982 年，在 1989 年又稍加改进以更好地支持 8-bit 字符和多语言排版。

TEX 以其卓越的稳定性、跨平台、几乎没有 Bug 而著称。TEX 的版本号不断趋近于 π，当前为 3.141592653。 TEX 读作 “Tech” ，其中 “ch” 的发音类似于 “h” ，与汉字“泰赫”的发音类似。TEX 的拼写来自希腊词语 τεχνική (technique，技术) 的开头几个字母。在 ASCII 字符环境，TEX 写作 TeX。

## 二、LATEX

LATEX 为 TEX 基础上的一套格式，令作者能够使用预定义的专业格式以较高质量排版和印刷他们的作品。LATEX 的最初开发者为 Leslie Lamport 博士 。LATEX 使用 TEX 程序作为自己的排版引擎。当下 LATEX 主要的维护者为 Frank Mittelbach。

LATEX 读作 “Lah-tech” 或者 “Lay-tech” ，近似于汉字“拉泰赫”或“雷泰赫”。LATEX 在 ASCII 字符环境写作 LaTeX。当前的 LATEX 版本为 LATEX 2ε，意思是超出了第二版，接近但没达到第三版，在 ASCII 字符环境写作 LaTeX2e。

## 三、LATEX 的优缺点

LATEX 总会拿来和一些“所见即所得”（What You See Is What You Get）的文字处理和排版工具比较优缺点。我认为这种比较并不值得提倡，毕竟所有工具都有自己值得使用的原因。

LATEX 的优点：

* 专业的排版输出，产生的文档看上去就像“印刷品”一样。

* 方便而强大的数学公式排版能力。

* 绝大多数时候，用户只需专注于一些组织文档结构的基础命令，无需（或很少）操心文档的版面设计。

* 很容易生成复杂的专业排版元素，如脚注、交叉引用、参考文献、目录等。

* 强大的扩展性。世界各地的人开发了数以千计的 LATEX 宏包用于补充和扩展 LATEX 的功能。

* LATEX 依赖的 TEX 排版引擎和其它软件是跨平台、免费、开源的。无论用户使用的是 Windows，macOS（OS X），GNU/Linux 还是 FreeBSD 等操作系统，都能轻松获得和使用这一强大的排版工具。

LATEX 的缺点：

* 入门门槛高。

* 排查错误困难。LATEX 作为一个依靠编写代码工作的排版工具，其使用的宏语言比 C++ 或 Python 等程序设计语言在错误排查方面困难得多。它虽然能够提示错误，但不提供调试的机制，有时错误提示还很难理解。

* 样式定制困难。LATEX 提供了一个基本上良好的样式，为了让用户不去关注样式而专注于
  文档结构。但如果想要改进 LATEX 生成的文档样式则是十分困难。

***

via: <https://github.com/qinnian/LaTeX>

---

---
url: https://ain.hmgf.hxcn.space/writing/02-LaTeX-setup.md
---

# LaTex 的安装配置

## 一、TeXLive 下载

* [TeXLive下载（官网）](http://www.tug.org/texlive/)

* [TeXLive下载（清华大学镜像）](https://mirrors.tuna.tsinghua.edu.cn/CTAN/systems/texlive/Images/)

* [TeXLive下载（百度网盘）](https://pan.baidu.com/s/1eGHrD4KiWE2u4Ihn2y0v4w) 提取码：zb7b

## 二、TeXLive 安装

1. 在 TeXLive 文件，找到 `install-tl-advanced.bat`文件，以管理员身份运行。

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200213093619.png)

2. 修改 TeXLive 文件的安装位置，为了控制一下TeX Live占用的内存大小，我们可以选择修改N. of collections选项，并根据个人需要，去掉Texworks(比较老的编辑器，不推荐)以及部分我们日常不会使用的语言包，例如阿拉伯语、斯洛伐克语等等

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200213094306.png)

3. 经过一段漫长的安装，欢迎进入 TeXLive 的世界

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200213094506.png)

4. 检查安装是否成功

```bash
tex -v //查看 tex 的版本信息
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200215092012.png)

```bash
latex -v //查看 laTeX 的版本信息
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200215133653.png)

```bash
xelatex -v //查看 XeTeX 的版本信息
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200215133831.png)

```bash
pdflatex -v //查看 pdfTeX 的版本信息
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216093131.png)

## 三、TeXstudio 下载安装

* [TexStudio下载（官网）](https://texstudio.updatestar.com/zh-cn)

* [TexStudio下载（百度网盘）](https://pan.baidu.com/s/1YlqTPoR1YDviW8BxNCR5oA) 提取码：pcs5j

## 四、测试LaTeX环境

```LaTex
\documentclass[UTF8]{ctexart}
    \title{钦念博客}
    \author{Qinnian}
    \date{\today}
    \begin{document}
    \maketitle
    www.qinnian.xyz
\end{document}
```

完成编译并运行

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200213100024.png)

***

via: <https://github.com/qinnian/LaTeX>

---

---
url: https://ain.hmgf.hxcn.space/writing/03-LaTex-text.md
---

# LaTeX 的文本语法

## 一、基本结构

```latex
\documentclass{article} 

\begin{document}

\end{document}
```

上述三⾏代码代表了⼀个 LaTeX ⽂件必不可少的三个部分。

* `\documentclass{article}` 表⽰该⽂档的类型是期刊（aiticle） ，LaTeX 还⽀持 report（报 告） 、book（书籍）、beamer（幻灯⽚）等多种类型。

* `\begin{document}` 和 `\end{document}` 表⽰⽂档内容的开始和结束，所有正⽂内容都写在其中。

* `\begin{document}` 前的部分我们称为导⾔区，宏包都是写在导⾔区。

```latex
\documentclass{article} 

%这是导言区 

\begin{document} 


\end{document}
```

## 二、支持中文

2020年 LaTeX 对中⽂的⽀持已经很完善，因此我们可以直接 使⽤ `\documentclass[UTF8]{ctexart}`，代表该⽂档是中⽂论⽂（ctex+article）。

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

关注微信公众号“钦念博客”

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216171756.png)

## 三、特殊字符

% 表示注释，$、^、\_ 等用于排版数学公式，& 用于排版表格

如果想要输入以上符号，需要使用以下带反斜线的形式输入：

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

\#

\$ 

\% 

\& 

\{ \} 

\_

\^{} 

\~{} 

\textbackslash

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220095946.png)

> 注：
>
> (1)`\^` 和 `\~` 两个命令是需要带参数的，如果不加一对花括号（空参数），就将后面的字符作为参数，形成重音效果。
>
> (2)`\\` 被直接定义成了手动换行的命令，输入反斜杠就只好用 `\textbackslash`

## 四、标点符号

LATEX 的单引号 ‘ ’ 用 \`和 ' 输入；双引号 “ ” 用 \`\` 和 '' 输入

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

``请关注微信公众号 `钦念博客' 。''

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220100730.png)

LATEX 中有三种长度的“横线”可用：

* 连字号（hyphen）:用来组成复合词；

* 短破折号（en-dash）：用来连接数字表示范围；

* 长破折号（em-dash）：用来连接单词，与中文语境中的破折号类似。

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 
\noindent
daughter-in-law, X-rated\\
pages 13--67\\
yes---or no?

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220101829.png)

LATEX 提供了命令 `\ldots` 来生成省略号，相对于直接输入三个点的方式更为合理。`\ldots` 和 `\dots` 是两个等效的命令。

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

one, two, three, \ldots one hundred.

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220103501.png)

## 五、文字强调

强调文字的方法，要么是添加下划线等装饰物，要么是改变文字的字体。

LATEX 定义了 `\underline` 命令用来为文字添加下划线：

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

An \underline{underlined} text.

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220104613.png)

`\underline` 命令生成下划线的样式比较机械，不同的单词可能生成高低各异的下划线，并且无法换行。`ulem` 宏包解决了这一问题，它提供的 `\uline` 命令能够轻松生成自动换行的下划线。

另外，`\emph` 命令用来将文字变为斜体以示强调。如果在本身已经用 `\emph` 命令强调的文字内部嵌套使用 `\emph` 命令，内部则使用直立体文字。

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

An example of \uline{some long and underlined words.}


Some \emph{emphasized words,including \emph{double-emphasized}words}, are shown here.

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220110145.png)

## 六、断行断页

* 句尾添加 `\\` 强制换行
* 句尾添加 `\par` 强制换段（或者按两次`Enter`）
* 句尾添加 `\newpage` 强制换页

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 
	
	关注微信公众号“钦念博客”\\我的GitHub是https://github.com/qinnian
	
	我的知乎账号是“钦念”\par
	我的博客网站：www.qinnian.xyz
	
\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216201301.png)

* 段前添加 `\noindent` 取消缩进（默认段⾸是缩进两格的）

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 
	
	关注微信公众号“钦念博客”\\我的GitHub是https://github.com/qinnian
	
	\noindent
	我的知乎账号是“钦念”\par
	我的博客网站：www.qinnian.xyz
	
\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216202204.png)

***

via: <https://github.com/qinnian/LaTeX>

---

---
url: https://ain.hmgf.hxcn.space/writing/04-Latex-formula.md
---

# LaTex 公式速查

* [Latex 公式速查](#latex-公式速查)
  * [函数](#函数)
    * [对数与指数](#对数与指数)
    * [三角函数](#三角函数)
    * [其他函数](#其他函数)
  * [符号](#符号)
    * [运算符](#运算符)
    * [集合](#集合)
    * [关系符号](#关系符号)
    * [几何符号](#几何符号)
    * [逻辑符号](#逻辑符号)
    * [箭头 - `arrow`](#箭头---arrow)
  * [希腊字母](#希腊字母)
  * [字体](#字体)
    * [黑板报粗体](#黑板报粗体)
    * [粗体](#粗体)
    * [斜体](#斜体)
    * [无衬线体](#无衬线体)
    * [手写体](#手写体)
    * [注释文本](#注释文本)
  * [颜色](#颜色)
  * [空格](#空格)
  * [上下标与积分等](#上下标与积分等)
  * [分式](#分式)
  * [矩阵](#矩阵)
    * [无框矩阵 - `matrix`](#无框矩阵---matrix)
    * [行列式 - `vmatrix`](#行列式---vmatrix)
    * [范数矩阵 - `Vmatrix`](#范数矩阵---vmatrix)
    * [小括号矩阵 - `pmatrix`](#小括号矩阵---pmatrix)
    * [大括号矩阵 - `Bmatrix`](#大括号矩阵---bmatrix)
    * [方括号矩阵 - `bmatrix`](#方括号矩阵---bmatrix)
    * [边框 - `boxed{}`](#边框---boxed)
  * [数组 - `array`](#数组---array)
    * [定界符](#定界符)
      * [竖线](#竖线)
      * [小括号](#小括号)
      * [大括号](#大括号)
      * [方括号](#方括号)
    * [分割线](#分割线)
      * [实竖线](#实竖线)
      * [虚竖线](#虚竖线)
      * [实横线 - `\hline`](#实横线---hline)
      * [虚横线 - `\hdashline`](#虚横线---hdashline)
      * [应用 - 分块矩阵](#应用---分块矩阵)
      * [应用 - 制作表格](#应用---制作表格)
  * [条件表达式，方程式](#条件表达式方程式)
    * [条件表达式 - `cases`](#条件表达式---cases)
    * [编号的方程式 - `equation`](#编号的方程式---equation)
    * [多公式有编号 - `align`](#多公式有编号---align)
    * [多公式无编号 - `align*`](#多公式无编号---align)
      * [多公式无编号](#多公式无编号)
      * [单方程式多行写](#单方程式多行写)
    * [自定义对齐方式](#自定义对齐方式)
    * [方程组](#方程组)

> 本文仅提供的能够在 $Markdown$ 中使用的 $Latex$ 公式。

如何插入 $Latex$ 公式？

* 行内公式：`$公式$`
* 独立公式：`$$公式$$`

## 函数

### 对数与指数

$a^x$  `a^x`\
$\sqrt{x}$ `\sqrt{x}`\
$\sqrt\[3]{x}$ `\sqrt[3]{x}`\
$\sqrt\[a]{x}$ `\sqrt[a]{x}`\
$\exp x$ `\exp x`\
$\log x$ `\log x`\
$\lg x$ `\lg x`\
$\ln x$ `\ln x`

### 三角函数

$\sin x$ `\sin x`\
$\cos x$ `\cos x`\
$\tan x$ `\tan x`\
$\cot x$ `\cot x`\
$\sec x$  `\sec x`\
$\csc x$  `\csc x`\
$\arcsin x$ `\arcsin x`\
$\arccos x$  `\arccos x`\
$\arctan x$  `\arctan x`\
$\sinh x$ `\sinh x`\
$\cosh x$ `\cosh x`\
$\tanh x$ `\tanh x`

### 其他函数

最小值： $\min x$ `\min x`
最大值： $\max x$ `\max x`\
最大公约数： $\gcd x$ `\gcd x`\
角度： $\deg$ `\deg`\
极限： $\lim\_{x \to \infty}f(x)$ `\lim_{x \to \infty}f(x)`\
上确界： $\sup M$ `\sup M`\
下确界： $\inf M$ `\inf M`\
行列式： $\det A$ `\det A`\
维数： $\dim A$ `\dim A`\
矩阵kernel： $\ker A$ `\ker A`\
投影： $\Pr$ `\Pr`\
同调群：$\hom$ `\hom`\
复数的幅角： $\arg z$ `\arg z`\
向下取整： $\lfloor x \rfloor$ `\lfloor x \rfloor`\
向上取整： $\lceil x \rceil$ `\lceil x \rceil`\
自定义函数： $\operatorname{function} x$ `\operatorname{function} x`

## 符号

### 运算符

$\pm$ `\pm`\
$\mp$ `\mp`\
$\dotplus$ `\dotplus`\
$\times$ `\times`\
$\div$ `\div`\
$\frac{a}{b}$ `\frac{a}{b}`\
$\divideontimes$ `\divideontimes`\
$\backslash$ `\backslash`\
$\cdot$ `\cdot`\
$\ast$ `\ast`\
$\circ$ `\circ`\
$\bullet$ `\bullet`\
$\boxplus$ `\boxplus`\
$\boxminus$ `\boxminus`\
$\boxtimes$ `\boxtimes`\
$\boxdot$ `\boxdot`\
$\oplus$  `\oplus`\
$\ominus$ `\ominus`\
$\otimes$  `\otimes`\
$\oslash$  `\oslash`\
$\odot$ `\odot`\
$\bigoplus$ `bigoplus`\
$\bigotimes$ `\bigotimes`\
$\bigodot$ `\bigodot`

### 集合

${ }$ `\{ \}`\
$\empty$ `\empty`\
$\varnothing$ `\varnothing`\
$\in$ `\in`\
$\not\in$ `\notin` 或 `\not\in`\
$\ni$ `\ni`\
$\notni$ `\notni` 或 `\not\ni`\
$\cap$ `\cap`\
$\Cap$ `\Cap`\
$\sqcap$ `\sqcap`\
$\bigcap$ `\bigcap`\
$\cup$ `\cup`\
$\Cup$ `\Cup`\
$\sqcup$ `\sqcup`\
$\bigcup$  `\bigcup`\
$\bigsqcup$ `\bigscup`\
$\uplus$ `\uplus`\
$\biguplus$  `\biguplus`\
$\subset$  `\subset`\
$\Subset$  `\Subset`\
$\sqsubset$ `\sqsubset`\
$\supset$ `\supset`\
$\Supset$ `\Supset`\
$\sqsupset$ `\sqsupset`\
$\subseteq$ `\subseteq`\
$\nsubseteq$ `\nsubseteq`\
$\subsetneq$ `\subsetneq`\
$\varsubsetneq$ `\varsubsetneq`\
$\sqsubseteq$ `\sqsubseteq`\
$\supseteq$ `\supseteq`\
$\nsupseteq$ `\nsupseteq`\
$\supsetneq$ `\supsetneq`\
$\varsupsetneq$ `\varsupsetneq`\
$\sqsupseteq$ `\sqsupseteq`\
$\sqsupset$ `\sqsupset`\
$\subseteqq$ `\subseteqq`\
$\nsubseteqq$ `\nsubseteqq`\
$\subsetneqq$ `\subsetneqq`\
$\varsubsetneqq$ `\varsubsetneqq`\
$\supseteqq$ `\supseteqq`\
$\nsupseteqq$ `\nsupseteqq`\
$\supsetneqq$ `\supsetneqq`\
$\varsupsetneqq$ `\varsupsetneqq`

### 关系符号

$\ne$ `\ne` 或 `\neq`\
$\equiv$ `\equiv`\
$\not\equiv$ `\not\equiv`\
$\doteq$ `\doteq`\
$\doteqdot$ `\doteqdot`\
$\sim$ `\sim`\
$\nsim$ `\nsim`\
$\backsim$ `\backsim`\
$\thicksim$ `\thicksim`\
$\simeq$  `\simeq`\
$\backsimeq$ `\backsimeq`\
$\eqsim$ `\eqsim`\
$\cong$ `\cong`\
$\ncong$ `\ncong`\
$\approx$ `\approx`\
$\thickapprox$ `\thickapprox`\
$\approxeq$ `\approxeq`\
$\asymp$ `\asymp`\
$\propto$ `\propto`\
$\varpropto$ `\varpropto`\
$\ngtr$ `\ngtr`\
$\gg$ `\gg`\
$\ggg$ `\ggg`\
$\not\ggg$ `\not\ggg`\
$\gtrdot$ `\gtrdot`\
$\ngtr$ `\ngtr`\
$\lneq$ `\lneq`\
$\leqq$ `\leqq`\
$\nleq$ `\nleq`\
$\nleqq$ `\nleqq`\
$\lneqq$ `\lneqq`\
$\lvertneqq$ `\lvertneqq`\
$\ge$ `\ge`\
$\geq$ `\geq`\
$\gneq$ `\gneq`\
$\geqq$ `\geqq`\
$\ngeq$ `\ngeq`\
$\ngeqq$ `\ngeqq`\
$\gneqq$ `\gneqq`\
$\gvertneqq$ `\gvertneqq`

### 几何符号

$\parallel$ `\parallel`\
$\nparallel$ `\nparallel`\
$\shortparallel$ `\shortparallel`\
$\nshortparallel$ `nshortparallel`\
$\perp$ `\perp`\
$\angle$ `\angle`\
$\sphericalangle$ `\sphericalangle`\
$\measuredangle$ `\measuredangle`\
$45^\circ$ `45^\circ`\
$\Box$ `\Box`\
$\blacksquare$ `\blacksquare`\
$\diamond$ `\diamond`\
$\Diamond$ `\Diamond`\
$\lozenge$ `\lozenge`\
$\blacklozenge$ `\blacklozenge`\
$\bigstar$ `\bigstar`\
$\bigcirc$ `\bigcirc`\
$\triangle$ `\triangle`\
$\bigtriangleup$ `\bigtriangleup`\
$\bigtriangledown$ `\bigtriangledown`\
$\vartriangle$ `\vartriangle`\
$\triangledown$ `\triangledown`\
$\blacktriangle$ `\blacktriangle`\
$\blacktriangledown$ `\blacktriangledown`\
$\blacktriangleleft$ `\blacktriangleleft`\
$\blacktriangleright$ `\blacktriangleright`

### 逻辑符号

$\forall$ `\forall`\
$\exists$ `\exists`\
$\nexists$ `\nexists`\
$\therefore$ `\therefore`\
$\because$ `\because`\
$\And$ `\And`\
$\mid$ `\mid`\
$\lor$ `\lor` 或 `\vee`\
$\land$ `\land` 或 `\wedge`\
$\bar{q}$ `\bar{q}`\
$\overline{q}$ `\overline{q}`\
$\lnot$ `\lnot` 或 `\neg`\
$\bot$ `\bot`\
$\top$ `\top`\
$\vdash$ `\vdash`\
$\dashv$ `\dashv`\
$\vDash$ `\vDash`\
$\Vdash$ `\Vdash`\
$\models$ `\models`\
$\ulcorner$ `\ulcorner`\
$\urcorner$ `\urcorner`\
$\llcorner$ `\llcorner`\
$\lrcorner$ `\lrcorner`

### 箭头 - `arrow`

$\rightarrow$ `\rightarrow`\
$\nrightarrow$ `\nrightarrow`\
$\longrightarrow$ `\longrightarrow`\
$\Rightarrow$ `\Rightarrow`\
$\nRightarrow$ `\nRightarrow`\
$\Longrightarrow$ `\Longrightarrow`\
$\leftarrow$ `\leftarrow`\
$\nleftarrow$ `n\leftarrow`\
$\longleftarrow$ `\longleftarrow`\
$\Leftarrow$ `\Leftarrow`\
$\nLeftarrow$ `\nLeftarrow`\
$\Longleftarrow$ `\Longleftarrow`\
$\leftrightarrow$ `\leftrightarrow`\
$\nleftrightarrow$ `\nleftrightarrow`\
$\Leftrightarrow$ `\Leftrightarrow`\
$\nLeftrightarrow$ `\nLeftrightarrow`\
$\longleftrightarrow$ `\longleftrightarrow`\
$\iff$ `iff`\
$\Longleftrightarrow$ `\Longleftrightarrow`\
$\uparrow$  `\uparrow`\
$\downarrow$ `\downarrow`\
$\updownarrow$ `\updownarrow`\
$\Uparrow$ `\Uparrow`\
$\Downarrow$ `\Downarrow`\
$\nearrow$ `\nearrow`\
$\swarrow$ `\swarrow`\
$\nwarrow$ `\nwarrow`\
$\searrow$ `\searrow`\
$\rightharpoonup$ `\rightharpoonup`\
$\rightharpoondown$ `\rightharpoondown`\
$\leftharpoonup$ `\leftharpoonup`\
$\leftharpoondown$ `\leftharpoondown`\
$\upharpoonleft$ `\upharpoonleft`\
$\downharpoonleft$ `\downharpoonleft`\
$\upharpoonright$ `\upharpoonright`\
$\downharpoonright$ `\downharpoonright`\
$\rightleftharpoons$ `\rightleftharpoons`\
$\leftrightharpoons$ `\leftrightharpoons`\
$\curvearrowleft$ `\curvearrowleft`\
$\curvearrowright$ `\curvearrowright`\
$\circlearrowleft$ `\circlearrowleft`\
$\circlearrowright$ `\circlearrowright`\
$\Lsh$ `\Lsh`\
$\Rsh$ `\Rsh`\
$\upuparrows$ `\upuparrows`\
$\downdownarrows$ `\downdownarrows`\
$\leftleftarrows$ `\leftleftarrows`\
$\rightrightarrows$ `\rightrightarrows`\
$\stackrel{text}{\longrightarrow}$ `\stackrel{text}{\longrightarrow}`\
$\stackrel{text}{\longleftarrow}$ `\stackrel{text}{\longleftarrow}`\
$\stackrel{text}{\downarrow}$ `\stackrel{text}{\downarrow}`\
$\stackrel{text}{\uparrow}$ `\stackrel{text}{\uparrow}`

## 希腊字母

$\alpha$ `\alpha`\
$\beta$ `\beta`\
$\gamma$ `\gamma`\
$\delta$ `\delta`\
$\epsilon$ `\epsilon`\
$\varepsilon$ `\varepsilon`\
$\zeta$ `\zeta`\
$\eta$ `\eta`\
$\theta$ `\theta`\
$\vartheta$ `\vartheta`\
$\iota$ `\iota`\
$\kappa$ `\kappa`\
$\lambda$ `\lambda`\
$\mu$ `\mu`\
$\nu$ `\nu`\
$\xi$ `\xi`\
$\pi$ `\pi`\
$\varpi$ `\varpi`\
$\rho$ `\rho`\
$\varrho$ `\varrho`\
$\sigma$ `\sigma`\
$\varsigma$ `\varsigma`\
$\tau$ `\tau`\
$\upsilon$ `\upsilon`\
$\phi$ `\phi`\
$\varphi$ `\varphi`\
$\chi$ `\chi`\
$\psi$ `\psi`\
$\omega$ `\omega`\
$\Gamma$ `\Gamma`\
$\Delta$ `\Delta`\
$\Theta$ `\Theta`\
$\Lambda$ `\Lambda`\
$\Xi$ `\Xi`\
$\Pi$ `\Pi`\
$\Sigma$ `\Sigma`\
$\Upsilon$ `\Upsilon`\
$\Phi$ `\Phi`\
$\Psi$ `\Psi`\
$\Omega$ `\Omega`

## 字体

### 黑板报粗体

> 只对大写字母有效

$\mathbb{FONT}$ `\mathbb{FONT}`

### 粗体

> 对大小写字母、希腊字母都有效

$\mathbf{FONT}$ `\mathbf{FONT}`\
$\mathbf{font}$ `\mathbf{font}`\
$\mathbf{\digamma\Theta\Nu\Tau}$ `\mathbf{\digamma\Theta\Nu\Tau}`

### 斜体

$\mathit{1234567890}$ `\mathit{1234567890}`\
$\mathit{abcdefg}$ `\mathit{abcdefg}`\
$\mathit{ABCDEFG}$ `\mathit{ABCDEFG}`

### 无衬线体

$\mathsf{ABCDEFG}$ `\mathsf{ABCDEFG}`

### 手写体

$\mathcal{ABCDEFG}$ `\mathcal{ABCDEFG}`

### 注释文本

用 `text{}` 在公式中添加文本： $\text{注释信息}$ `\text{注释信息}`

## 颜色

格式：

```latex
\color{颜色}{文本}
```

旧版浏览器支持：

$\color{gray}{text}$ `\color{gray}{text}`\
$\color{silver}{text}$ `\color{silver}{text}`\
$\color{blue}{text}$ `\color{blue}{text}`\
$\color{yellow}{text}$ `\color{yellow}{text}`\
$\color{red}{text}$ `\color{red}{text}`\
$\color{lime}{text}$ `\color{lime}{text}`\
$\color{green}{text}$ `\color{green}{text}`\
$\color{fuchsia}{text}$ `\color{fuchsia}{text}`

较新浏览器支持 `\color{#rgb}{text}` 来自定义更多的颜色，`#rgb` 的 `r、g、b` 分别可以是十六进制表示的 `0~255` 的数。

$\color{#ffdddd}{text}$ `\color{#ffdddd}{text}`\
$\color{#ff8888}{text}$ `\color{#ff8888}{text}`\
$\color{#ffaa11}{text}$ `\color{#ffaa11}{text}`\
$\color{#ffccaa}{text}$ `\color{#ffccaa}{text}`\
$\color{#ffdd66}{text}$ `\color{#ffdd66}{text}`\
$\color{#ffbbee}{text}$ `\color{#ffbbee}{text}`\
$\color{#aaaaff}{text}$ `\color{#aaaaff}{text}`\
$\color{#7777ff}{text}$ `\color{#7777ff}{text}`\
$\color{#66ccff}{text}$ `\color{#66ccff}{text}`\
$\color{#99ccff}{text}$ `\color{#99ccff}{text}`\
$\color{#00eeff}{text}$ `\color{#00eeff}{text}`\
$\color{#bbffee}{text}$ `\color{#bbffee}{text}`\
$\color{#99ff99}{text}$ `\color{#99ff99}{text}`\
$\color{#44bb66}{text}$ `\color{#44bb66}{text}`\
$\color{#44ff77}{text}$ `\color{#44ff77}{text}`\
$\color{#0088ff}{text}$ `\color{#0088ff}{text}`\
$\color{#22cc88}{text}$ `\color{#22cc88}{text}`\
$\color{#777777}{text}$ `\color{#777777}{text}`\
$\color{#aaaaaa}{text}$ `\color{#aaaaaa}{text}`\
$\color{#f0f0f0}{text}$ `\color{#f0f0f0}{text}`

## 空格

* `\,` 表示一个窄空格，$\frac{1}{6}$ M 的宽度
* `\` 或 `\:` 表示一个中等空格
* `\;` 表示一个大空格
* `\quad` 表示一个字母 M 宽度的空格
* `\qquad` 表示两个 \quad 的宽度
* `\!` 表示一个负的窄空格，缩进$\frac{1}{6}M$ 的宽度
* `\\` 表示换行

$$
\boxed{
\begin{array}{c|c}
窄空格 & a,b \ \hline
中等空格 & a: b \ \hline
大空格 & a;b \ \hline
字母M的宽度 & a\quad b \ \hline
两个M的宽度 & a\qquad b \ \hline
负窄空格 & a!b
\end{array}\\
}
$$

## 上下标与积分等

$x^2$ `x^2`

$x^{a + b}$ `x^{a+b}`

$a\_1$ `a_1`

$a\_{ij}$ `a_{ij}`

前置上下标： ${}\_1^2!X\_3^4$ `{}_1^2\!x_3^4`

正上方标记：$\sum\limits^n$ `\sum\limits^n`

正下方标记：$\min\limits\_{i \leq k \leq j - 1}$ `\min\limits_{i \leq k \leq j - 1}`

导数： $x^\prime$ `x^\prime`  或 `x'`

导数点： $\dot{x}$ `\dot{x}`

向量：$\vec{x}$ `\vec{x}`

左长箭头： $\overleftarrow{a + b}$ `\overleftarrow{a + b}`

右长箭头： $\overrightarrow{a + b}$ `\overrightarrow{a + b}`

$\widehat{abc}$ `\widehate{abc}`

上弧： $\overset{\frown}{AB}$ `\overset{\frown}{AB}`

上划线： $\overline{abc}$ `\overline{abc}`

下划线： $\underline{abc}$ `\underline{abc}`

上括号： $\overbrace{1 + 2 + \cdots + 100}$ `\overbrace{1 + 2 + \cdots + 100}`

上括号示例： $\begin{matrix}5050\\\overbrace{1 + 2 + \cdots + 100}\end{matrix}$ `\begin{matrix}5050\\\overbrace{1 + 2 + \cdots + 100}\end{matrix}`

下括号： $\underbrace{1 + 2 + \cdots + 100}$ `\underbrace{1 + 2 + \cdots + 100}`

下括号示例： $\begin{matrix}\underbrace{1 + 2 + \cdots + 100}\5050\end{matrix}$ `\begin{matrix}\underbrace{1 + 2 + \cdots + 100}\\5050\end{matrix}`

求和： $\sum\_{k = 1}^{\infty} f(x)$ `\sum_{k = 1}^{\infty} f(x)`

求和： $\Sigma\_{x = 1}^{\infty} f(x)$ `\Sigma_{x = 1}^{t = \infty} f(x)`

求积： $\prod\_{i = 1}^{n} x\_i$ `\prod_{i = 1}^{n} x_i`

上积： $\coprod\_{i = 1}^{n} x\_i$ `\coprod_{i = 1}^{n} x_i`

极限： $\lim\_{x\to\infty} f(x)$ `\lim_{x\to\infty} f(x)`

积分： $\int\_{a}^{b} f(x)dx$ `\int_{a}^{b} f(x)dx`

双重积分： $\iint\_{a}^{b} f(x) , dx , dy$ `\iint_{a}^{b} f(x) \, dx \, dy`

三重积分： $\iiint\_a^{b} f(x) , dx , dy , dz$ `\iiint_a^{b} f(x) \, dx \, dy \, dz`

闭合的曲线、曲面积分： $\oint\_{C} x^2 , dx+ y , dy$ `\oint_{C} x^2 \, dx+ y \, dy`

## 分式

分数：
$\frac{a + b}{c + d}$ `\frac{a + b}{c + d}`\
$\frac{dx}{dy}$ `\frac{dx}{dy}`

连分式： $\cfrac{1}{2 + \cfrac{3}{4 + \cfrac{5}{6 + \cdots}}}$ `\cfrac{1}{2 + \cfrac{3}{4 + \cfrac{5}{6 + \cdots}}}`

$\cfrac{a\_1}{b1 + \cfrac{a\_2}{b\_2 + \cfrac{a\_3}{b\_3 + \cdots}}}$ `\cfrac{a_1}{b1 + \cfrac{a_2}{b_2 + \cfrac{a_3}{b_3 + \cdots}}}`

二项式系数： $C\_n^r = \dbinom{n}{r}$ `C_n^r = \dbinom{n}{r}`

## 矩阵

语法：

```latex
\begin{类型}
公式
\end{类型}
```

矩阵中 `&` 分隔元素，`\\` 进行换行
横三点： $\cdots$ `\cdots`\
竖三点： $\vdots$ `\vdots`\
斜三点： $\ddots$ `\ddots`

### 无框矩阵 - `matrix`

$$
\begin{matrix}
a\_{11} & a\_{12} & a\_{13} \\
a\_{21} & a\_{22} & a\_{23} \\
a\_{31} & a\_{32} & a\_{33}
\end{matrix}\\
$$

```latex
\begin{matrix}
a_{11} & a_{12} & a_{13} \\
a_{21} & a_{22} & a_{23} \\
a_{31} & a_{32} & a_{33}
\end{matrix}
```

### 行列式 - `vmatrix`

$$
\begin{vmatrix}
a\_{11} & a\_{12} & \cdots & a\_{1n} \\
a\_{21} & a\_{21} & \cdots & a\_{2n} \\
\vdots & \vdots & \ddots & \vdots \\
a\_{n1} & a\_{n2} & \cdots & a\_{nn}
\end{vmatrix}\\
$$

```latex
\begin{vmatrix}
a_{11} & a_{12} & \cdots & a_{1n} \\
a_{21} & a_{21} & \cdots & a_{2n} \\
\vdots & \vdots & \ddots & \vdots \\
a_{n1} & a_{n2} & \cdots & a_{nn}
\end{vmatrix}
```

### 范数矩阵 - `Vmatrix`

$$
\begin{Vmatrix}
a\_{1,1} & a\_{1,2} & \cdots & a\_{1,n} \\
a\_{2,1} & a\_{2,1} & \cdots & a\_{2,n} \\
\vdots & \vdots & \ddots & \vdots \\
a\_{n,1} & a\_{n,2} & \cdots & a\_{n,n}
\end{Vmatrix}\\
$$

```latex
\begin{Vmatrix}
a_{1,1} & a_{1,2} & \cdots & a_{1,n} \\
a_{2,1} & a_{2,1} & \cdots & a_{2,n} \\
\vdots & \vdots & \ddots & \vdots \\
a_{n,1} & a_{n,2} & \cdots & a_{n,n}
\end{Vmatrix}
```

### 小括号矩阵 - `pmatrix`

$$
\begin{pmatrix}
a\_{11} & a\_{12} & a\_{13} \\
a\_{21} & a\_{22} & a\_{23} \\
a\_{31} & a\_{32} & a\_{33}
\end{pmatrix}\\
$$

```latex
\begin{pmatrix}
a_{11} & a_{12} & a_{13} \\
a_{21} & a_{22} & a_{23} \\
a_{31} & a_{32} & a_{33}
\end{pmatrix}
```

### 大括号矩阵 - `Bmatrix`

$$
\begin{Bmatrix}
a\_{11} & a\_{12} & a\_{13} & a\_{14} \\
a\_{21} & a\_{22} & a\_{23} & a\_{24} \\
a\_{31} & a\_{32} & a\_{33} & a\_{34} \\
a\_{41} & a\_{42} & a\_{43} & a\_{44}\
\end{Bmatrix}\\
$$

```latex
\begin{Bmatrix}
a_{11} & a_{12} & a_{13} & a_{14} \\
a_{21} & a_{22} & a_{23} & a_{24} \\
a_{31} & a_{32} & a_{33} & a_{34} \\
a_{41} & a_{42} & a_{43} & a_{44}  
\end{Bmatrix}
```

### 方括号矩阵 - `bmatrix`

$$
\begin{bmatrix}
a\_{11} & a\_{12} & a\_{13} & \cdots & a\_{1n} \\
a\_{21} & a\_{22} & a\_{23} & \cdots & a\_{2n} \\
a\_{31} & a\_{32} & a\_{33} & \cdots & a\_{3n} \\
\vdots & \vdots & \vdots & \ddots & \vdots \\
a\_{n1} & a\_{n2} & a\_{n3} & \cdots & a\_{nn}
\end{bmatrix}\\
$$

```latex
\begin{bmatrix}
a_{11} & a_{12} & a_{13} & \cdots & a_{1n} \\
a_{21} & a_{22} & a_{23} & \cdots & a_{2n} \\
a_{31} & a_{32} & a_{33} & \cdots & a_{3n} \\
\vdots & \vdots & \vdots & \ddots & \vdots \\
a_{n1} & a_{n2} & a_{n3} & \cdots & a_{nn} 
\end{bmatrix}
```

### 边框 - `boxed{}`

$$
\begin{bmatrix}
\boxed{-1} & 3 & 0 & 2 \\
0 & \boxed{1} & 3 & 1 \\
0 & 0 & 0 & \boxed{2} \\
0 & 0 & 0 & 0
\end{bmatrix}\\
$$

```latex
\begin{bmatrix}
\boxed{-1} & 3 & 0 & 2 \\
0 & \boxed{1} & 3 & 1 \\
0 & 0 & 0 & \boxed{2} \\
0 & 0 & 0 & 0
\end{bmatrix}\\
```

## 数组 - `array`

$$
\begin{array}{}
a & b \\
c & d\
\end{array}\\
$$

```latex
\begin{array}{}
a & b \\
c & d  
\end{array}
```

### 定界符

语法：

```latex
\left 符号
公式
\right 符号
```

#### 竖线

$$
\left |
\begin{array}{}
a\_{11} & a\_{12} \\
a\_{13} & a\_{14} \\
\end{array}
\right | \\
$$

```latex
\left |
\begin{array}{}
a_{11} & a_{12} \\
a_{13} & a_{14} \\
\end{array}
\right | 
```

#### 小括号

$$
\left (
\begin{array}{}
a\_{11} & a\_{12} \\
a\_{13} & a\_{14} \\
\end{array}
\right ) \\
$$

```latex
\left (
\begin{array}{}
a_{11} & a_{12} \\
a_{13} & a_{14} \\
\end{array}
\right )
```

#### 大括号

$$
\left {
\begin{array}{}
a\_{11} & a\_{12} \\
a\_{13} & a\_{14} \\
\end{array}
\right }\\
$$

```latex
\left \{
\begin{array}{}
a_{11} & a_{12} \\
a_{13} & a_{14} \\
\end{array}
\right \}
```

> 注：`{}` 为特殊字符，无法直接使用，应使用 `\{` 和 `\}` 来输出

#### 方括号

$$
\left \[
\begin{array}{}
a\_{11} & a\_{12} \\
a\_{13} & a\_{14} \\
\end{array}
\right ]\\
$$

```latex
\left [
\begin{array}{}
a_{11} & a_{12} \\
a_{13} & a_{14} \\
\end{array}
\right ]
```

### 分割线

#### 实竖线

$$
\left \[
\begin{array}{c|c|c|c|c}
a\_{11} & a\_{12} & a\_{13} & a\_{14} & a\_{15}\\
a\_{21} & a\_{22} & a\_{23} & a\_{24} & a\_{25}\\
a\_{31} & a\_{32} & a\_{33} & a\_{34} & a\_{35}\\
a\_{41} & a\_{42} & a\_{43} & a\_{44} & a\_{45}\\
a\_{51} & a\_{52} & a\_{53} & a\_{54} & a\_{55}
\end{array}
\right ]\\
$$

```latex
\left [
\begin{array}{c|c|c|c|c}
a_{11} & a_{12} & a_{13} & a_{14} & a_{15}\\
a_{21} & a_{22} & a_{23} & a_{24} & a_{25}\\
a_{31} & a_{32} & a_{33} & a_{34} & a_{35}\\
a_{41} & a_{42} & a_{43} & a_{44} & a_{45}\\
a_{51} & a_{52} & a_{53} & a_{54} & a_{55} 
\end{array}\\
\right ]
```

#### 虚竖线

$$
\left \[
\begin{array}{c:c:c:c:c}
a\_{11} & a\_{12} & a\_{13} & a\_{14} & a\_{15} \\
a\_{21} & a\_{22} & a\_{23} & a\_{24} & a\_{25} \\
a\_{31} & a\_{32} & a\_{33} & a\_{34} & a\_{35} \\
a\_{41} & a\_{42} & a\_{43} & a\_{44} & a\_{45} \\
a\_{51} & a\_{52} & a\_{53} & a\_{54} & a\_{55}
\end{array}
\right ]\\
$$

```latex
\left [
\begin{array}{c:c:c:c:c}
a_{11} & a_{12} & a_{13} & a_{14} & a_{15} \\
a_{21} & a_{22} & a_{23} & a_{24} & a_{25} \\
a_{31} & a_{32} & a_{33} & a_{34} & a_{35} \\
a_{41} & a_{42} & a_{43} & a_{44} & a_{45} \\
a_{51} & a_{52} & a_{53} & a_{54} & a_{55}
\end{array}
\right ]\\
```

#### 实横线 - `\hline`

$$
\left \[
\begin{array}{}
a\_{11} & a\_{12} & a\_{13} & a\_{14} & a\_{15} \\
\hline
a\_{21} & a\_{22} & a\_{23} & a\_{24} & a\_{25} \\
\hline
a\_{31} & a\_{32} & a\_{33} & a\_{34} & a\_{35} \\
\hline
a\_{41} & a\_{42} & a\_{43} & a\_{44} & a\_{45} \\
\hline
a\_{51} & a\_{52} & a\_{53} & a\_{54} & a\_{55}
\end{array}
\right ]\\
$$

```latex
\left [
\begin{array}{}
a_{11} & a_{12} & a_{13} & a_{14} & a_{15} \\
\hline
a_{21} & a_{22} & a_{23} & a_{24} & a_{25} \\
\hline
a_{31} & a_{32} & a_{33} & a_{34} & a_{35} \\
\hline
a_{41} & a_{42} & a_{43} & a_{44} & a_{45} \\
\hline
a_{51} & a_{52} & a_{53} & a_{54} & a_{55}
\end{array}
\right ]
```

#### 虚横线 - `\hdashline`

$$
\left \[
\begin{array}{}
a\_{11} & a\_{12} & a\_{13} & a\_{14} & a\_{15} \\
\hdashline
a\_{21} & a\_{22} & a\_{23} & a\_{24} & a\_{25} \\
\hdashline
a\_{31} & a\_{32} & a\_{33} & a\_{34} & a\_{35} \\
\hdashline
a\_{41} & a\_{42} & a\_{43} & a\_{44} & a\_{45} \\
\hdashline
a\_{51} & a\_{52} & a\_{53} & a\_{54} & a\_{55}
\end{array}
\right ]\\
$$

```latex
\left [
\begin{array}{}
a_{11} & a_{12} & a_{13} & a_{14} & a_{15} \\
\hdashline
a_{21} & a_{22} & a_{23} & a_{24} & a_{25} \\
\hdashline
a_{31} & a_{32} & a_{33} & a_{34} & a_{35} \\
\hdashline
a_{41} & a_{42} & a_{43} & a_{44} & a_{45} \\
\hdashline
a_{51} & a_{52} & a_{53} & a_{54} & a_{55}
\end{array}
\right ]
```

#### 应用 - 分块矩阵

$$
\left \[
\begin{array}{cc:cc}
1 & 0 & 1 & -2 \\
0 & 1 & 0 & 1 \\
\hdashline
-1 & 2 & -1 & 0 \\
0 & -1 & 0 & -1
\end{array}
\right ]\\
$$

```latex
\left [
\begin{array}{cc:cc}
1 & 0 & 1 & -2 \\
0 & 1 & 0 & 1 \\
\hdashline
-1 & 2 & -1 & 0 \\
0 & -1 & 0 & -1
\end{array}
\right ]
```

#### 应用 - 制作表格

$$
\boxed{
\begin{array}{c|c}
矩阵类型 & 关键字 \ \hline
|A| & vmatrix \ \hline
\parallel & Vmatrix \ \hline
() & pmatrix \ \hline
{} & Bmatrix \ \hline
\[\ ] & bmatrix
\end{array}
}\\
$$

```latex
\boxed{
    \begin{array}{c|c}
    矩阵类型 & 关键字 \\ \hline
    |A| & vmatrix \\ \hline
    \parallel & Vmatrix \\ \hline
    () & pmatrix \\ \hline
    \{\} & Bmatrix \\ \hline
    [\ ] & bmatrix
    \end{array}
}
```

## 条件表达式，方程式

### 条件表达式 - `cases`

$$
f(x) =
\begin{cases}
\begin{aligned}
\frac{\sin x}{|x|},x \ne 0 \\
1,x = 0\\
\end{aligned}
\end{cases}\\
$$

```latex
f(x) =
\begin{cases}
\begin{aligned}
\frac{\sin x}{|x|},x \ne 0 \\
1,x = 0\\
\end{aligned}
\end{cases}
```

### 编号的方程式 - `equation`

$$
\begin{equation}
z = (a+b)^4= a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4.
\end{equation}\\
$$

```latex
\begin{equation}
z = (a+b)^4= a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4.
\end{equation}
```

### 多公式有编号 - `align`

$$
\begin{align}
\nabla \cdot \mathbf{E} &= \frac{\rho}{\varepsilon\_0} \\
\nabla \cdot \mathbf{B} &= 0 \\
\nabla \times \mathbf{E} &= -\frac{\partial \mathbf{B}}{\partial t} \\
\nabla \times \mathbf{B} &= \mu\_0 \mathbf{J} + \mu\_0\varepsilon\_0 \frac{\partial \mathbf{E}}{\partial t}
\end{align}\\
$$

```latex
\begin{align} 
\nabla \cdot \mathbf{E} &= \frac{\rho}{\varepsilon_0} \\
 \nabla \cdot \mathbf{B} &= 0 \\
 \nabla \times \mathbf{E} &= -\frac{\partial \mathbf{B}}{\partial t} \\
 \nabla \times \mathbf{B} &= \mu_0 \mathbf{J} + \mu_0\varepsilon_0 \frac{\partial \mathbf{E}}{\partial t}
 \end{align}
```

### 多公式无编号 - `align*`

#### 多公式无编号

$$
\begin{align\*}
E = mc^2 \\
e^{i\pi} + 1 = 0
\end{align\*}\\
$$

```latex
\begin{align*}
E = mc^2 \\
e^{i\pi} + 1 = 0
\end{align*}
```

#### 单方程式多行写

$$
\begin{align\*}
z & = (a+b)^4 \\
& = (a+b)^2(a+b)^2 \\
& = (a^2+2ab+b^2)(a^2+2ab+b^2) \\
& = a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4
\end{align\*}\\
$$

```latex
\begin{align*}
   z & = (a+b)^4 \\
     & = (a+b)^2(a+b)^2 \\
     & = (a^2+2ab+b^2)(a^2+2ab+b^2) \\
     & = a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4
 \end{align*}
```

$$
\begin{align\*}
& a\_1 \wedge a\_2 \wedge \cdots \wedge (a\_i \wedge x) \wedge a\_{i + 1} \wedge \cdots \wedge a\_n\\
& = (a\_1 \wedge a\_2 \wedge \cdots \wedge a\_i \wedge a\_{i + 1} \wedge \cdots \wedge a\_n) \wedge x\\
& = x \wedge x\\
& = 0
\end{align\*}
$$

```latex
\begin{align*}
& a_1 \wedge a_2 \wedge \cdots \wedge (a_i \wedge x) \wedge a_{i + 1} \wedge \cdots \wedge a_n\\
& = (a_1 \wedge a_2 \wedge \cdots \wedge a_i \wedge a_{i + 1} \wedge \cdots \wedge a_n) \wedge x\\
& = x \wedge x\\
& = 0
\end{align*}
```

### 自定义对齐方式

在 `align` 或 `align*` 环境下，在公式左侧添加 `&` 可以使得公式左对齐，否则默认为居中对齐。
实际上将 `&` 的作用是为公式设置一个对齐点，多个公式的对齐点会在同一竖线上。

* 将标记的 $=$ 和 $+$ 之间保持对齐

$$
\begin{align\*}
\phi(N) &= N - \frac{N}{p\_1} - \frac{N}{p\_2} \cdots - \frac{N}{p\_k}\\
& +\frac{N}{p\_1p\_2} + \frac{N}{p\_1p\_3} + \cdots\\
& +\frac{N}{p\_1p\_2p\_3} - \frac{N}{p\_2p\_2p\_4} \cdots\\
& +\cdots \\
& = N \times \frac{p\_1 - 1}{p\_1} \times \frac{p\_2 - 1}{p\_2}\cdots \times \frac{p\_m - 1}{p\_m}
\end{align\*}
$$

```latex
\begin{align*}
\phi(N) &= N - \frac{N}{p_1} - \frac{N}{p_2} \cdots - \frac{N}{p_k}\\
& +\frac{N}{p_1p_2} + \frac{N}{p_1p_3} + \cdots\\
& +\frac{N}{p_1p_2p_3} - \frac{N}{p_2p_2p_4} \cdots\\
& +\cdots \\
& = N \times \frac{p_1 - 1}{p_1} \times \frac{p_2 - 1}{p_2}\cdots \times \frac{p_m - 1}{p_m}
\end{align*}
```

* 将 $\cdots$ 之间保持对齐

$$
\begin{align\*}
\phi(N) = N - \frac{N}{p\_1} - \frac{N}{p\_2} &\cdots - \frac{N}{p\_k}\\
+\frac{N}{p\_1p\_2} + \frac{N}{p\_1p\_3} + &\cdots\\
+\frac{N}{p\_1p\_2p\_3} - \frac{N}{p\_2p\_2p\_4} &\cdots\\
+&\cdots \\
\= N \times \frac{p\_1 - 1}{p\_1} \times \frac{p\_2 - 1}{p\_2} &\cdots \times \frac{p\_m - 1}{p\_m}
\end{align\*}
$$

### 方程组

$$
\begin{cases}
x + y - z = 0 \\
2x - y + z = 2 \\
x + y + 2z = 4
\end{cases}\\
$$

```latex
\begin{cases}
x + y - z = 0 \\
2x - y + z = 2 \\
x + y + 2z = 4
\end{cases}
```

或者

```latex
\left\{ \begin{aligned}
x + y - z = 0 \\
2x - y + z = 2 \\
x + y + 2z = 4
\end{aligned} \right.
```

> `\left\{ 公式 \right.` 实现只有左边出现界定符大括号 `{`\
> `\begin{aligned} 公式 \end{aligned}` 实现公式右对齐

***

via: <https://github.com/Eternal-embers/Latex-QuickList>

---

---
url: https://ain.hmgf.hxcn.space/writing/04-Latex-formula-list.md
---

# 数学公式编辑 Displaying a formula

## 符号与字母 Symbol and Alphabet

### 希腊字母 Greek alphabet

序号 | 小写 | LaTeX | 读音 | 序号 | 大写 | LaTeX | 读音
:-: | :----: | :---- | :---- | :-: | :----: | :---- | :----
1 | $\alpha$ | \alpha | /ˈælfə/ | 31 | $\Gamma$ | \Gamma | /ˈɡæmə/
2 | $\beta$ | \beta | /ˈbiːtə/, US: /ˈbeɪtə/ | 32 | $\Delta$ | \Delta | /ˈdɛltə/
3 | $\gamma$ | \gamma | /ˈɡæmə/ | 33 | $\Theta$ | \Theta | /ˈθiːtə/
4 | $\delta$ | \delta | /ˈdɛltə/ | 34 | $\Lambda$ | \Lambda | /ˈlæmdə/
5 | $\epsilon$ | \epsilon | /ˈɛpsɪlɒn/ | 35 | $\Xi$ | \Xi | /zaɪ, ksaɪ/
6 | $\varepsilon$ | \varepsilon | /ˈɛpsɪlɒn/ | 36 | $\Pi$ | \Pi | /paɪ/
7 | $\zeta$ | \zeta | /ˈzeɪtə/ | 37 | $\Sigma$ | \Sigma | /ˈsɪɡmə/
8 | $\eta$ | \eta | /ˈeɪtə/ | 38 | $\Upsilon$ | \Upsilon | /ˈʌpsɪlɒn/
9 | $\theta$ | \theta |  /ˈθiːtə/ | 39 | $\Phi$ | \Phi | /faɪ/
10 | $\vartheta$ | \vartheta |  /ˈθiːtə/ | 40 | $\Psi$ | \Psi | /psaɪ/
11 | $\iota$ | \iota |  /aɪˈoʊtə/ | 41 | $\Omega$ | \Omega | /oʊˈmeɪɡə/
12 | $\kappa$ | \kappa | /ˈkæpə/ |  |  |  |
13 | $\lambda$ | \lambda | /ˈlæmdə/ |  |  |  |
14 | $\mu$ | \mu | /mjuː/ |  |  |  |
15 | $\nu$ | \nu | /njuː/ |  |  |  |
16 | $\xi$ | \xi | /zaɪ, ksaɪ/ |  |  |  |
17 | $o$ | o | /ˈɒmɪkrɒn/ |  |  |  |
18 | $\pi$ | \pi | /paɪ/ |  |  |  |
19 | $\varpi$ | \varpi | /paɪ/ |  |  |  |
20 | $\rho$ | \rho | /roʊ/ |  |  |  |
21 | $\varrho$ | \varrho | /roʊ/ |  |  |  |
22 | $\sigma$ | \sigma | /ˈsɪɡmə/ |  |  |  |
23 | $\varsigma$ | \varsigma | /ˈsɪɡmə/ |  |  |  |
24 | $\tau$ | \tau | /taʊ, tɔː/ |  |  |  |
25 | $\upsilon$ | \upsilon | /ˈʌpsɪlɒn/ |  |  |  |
26 | $\phi$ | \phi | /faɪ/ |  |  |  |
27 | $\varphi$ | \varphi | /faɪ/ |  |  |  |
28 | $\chi$ | \chi | /kaɪ/ |  |  |  |
29 | $\psi$ | \psi | /psaɪ/ |  |  |  |
30 | $\omega$ | \omega | /oʊˈmeɪɡə/ |  |  |  |

**注意:** MathJax支持的大写希腊字母有限，如需其他（如大写Alpha），可使用**罗马体**转换，如`\mathrm{A}`表示大写Alpha：$\mathrm{A}$。

### 希伯来字母 Hebrew alphabet

序号 | 图标 | LaTeX | 英文
:----: | :----: | :---- | :----
1 | $\aleph$ | \aleph | aleph
2 | $\beth$ | \beth  | beth 
3 | $\gimel$ | \gimel | gimel
4 | $\daleth$ | \daleth | daleth

### 二元运算符 Binary operations

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | $+$ | + | 20 | $\bullet$ | \bullet
2 | $-$ | - | 21 | $\oplus$ | \oplus
3 | $\times$ | \times | 22 | $\ominus$ | \ominus
4 | $\div$ | \div | 23 | $\odot$ | \odot
5 | $\pm$ | \pm | 24 | $\oslash$ | \oslash
6 | $\mp$ | \mp | 25 | $\otimes$ | \otimes
7 | $\triangleleft$ | \triangleleft | 26 | $\bigcirc$ | \bigcirc
8 | $\triangleright$ | \triangleright | 27 | $\diamond$ | \diamond
9 | $\cdot$ | \cdot | 28 | $\uplus$ | \uplus
10 | $\setminus$ | \setminus | 29 | $\bigtriangleup$ | \bigtriangleup
11 | $\star$ | \star | 30 | $\bigtriangledown$ | \bigtriangledown
12 | $\ast$ | \ast | 31 | $\lhd$ | \lhd
13 | $\cup$ | \cup | 32 | $\rhd$ | \rhd
14 | $\cap$ | \cap | 33 | $\unlhd$ | \unlhd
15 | $\sqcup$ | \sqcup | 34 | $\unrhd$ | \unrhd
16 | $\sqcap$ | \sqcap | 35 | $\amalg$ | \amalg
17 | $\vee$ | \vee | 36 | $\wr$ | \wr
18 | $\wedge$ | \wedge | 37 | $\dagger$ | \dagger
19 | $\circ$ | \circ | 38 | $\ddagger$ | \ddagger

### 二元关系符 Binary relations

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | $=$ | = | 49 | $\gneq$ | \gneq
2 | $\ne$ | \ne | 50 | $\geqq$ | \geqq
3 | $\neq$ | \neq | 51 | $\ngeq$ | \ngeq
4 | $\equiv$ | \equiv | 52 | $\ngeqq$ | \ngeqq
5 | $\not\equiv$ | \not\equiv | 53 | $\gneqq$ | \gneqq
6 | $\doteq$ | \doteq | 54 | $\gvertneqq$ | \gvertneqq
7 | $\doteqdot$ | \doteqdot | 55 | $\lessgtr$ | \lessgtr
8 | $\overset{\underset{\mathrm{def}}{}}{=}$ | \overset{\underset{\mathrm{def}}{}}{=} | 56 | $\lesseqgtr$ | \lesseqgtr
9 | $:=$ | := | 57 | $\lesseqqgtr$ | \lesseqqgtr
10 | $\sim$ | \sim | 58 | $\gtrless$ | \gtrless
11 | $\nsim$ | \nsim | 59 | $\gtreqless$ | \gtreqless
12 | $\backsim$ | \backsim | 60 | $\gtreqqless$ | \gtreqqless
13 | $\thicksim$ | \thicksim | 61 | $\leqslant$ | \leqslant
14 | $\simeq$ | \simeq | 62 | $\nleqslant$ | \nleqslant
15 | $\backsimeq$ | \backsimeq | 63 | $\eqslantless$ | \eqslantless
16 | $\eqsim$ | \eqsim | 64 | $\geqslant$ | \geqslant
17 | $\cong$ | \cong | 65 | $\ngeqslant$ | \ngeqslant
18 | $\ncong$ | \ncong | 66 | $\eqslantgtr$ | \eqslantgtr
19 | $\approx$ | \approx | 67 | $\lesssim$ | \lesssim
20 | $\thickapprox$ | \thickapprox | 68 | $\lnsim$ | \lnsim
21 | $\approxeq$ | \approxeq | 69 | $\lessapprox$ | \lessapprox
22 | $\asymp$ | \asymp | 70 | $\lnapprox$ | \lnapprox
23 | $\propto$ | \propto | 71 | $\gtrsim$ | \gtrsim
24 | $\varpropto$ | \varpropto | 72 | $\gnsim$ | \gnsim
25 | $<$ | < | 73 | $\gtrapprox$ | \gtrapprox
26 | $\nless$ | \nless | 74 | $\gnapprox$ | \gnapprox
27 | $\ll$ | \ll | 75 | $\prec$ | \prec
28 | $\not\ll$ | \not\ll | 76 | $\nprec$ | \nprec
29 | $\lll$ | \lll | 77 | $\preceq$ | \preceq
30 | $\not\lll$ | \not\lll | 78 | $\npreceq$ | \npreceq
31 | $\lessdot$ | \lessdot | 79 | $\precneqq$ | \precneqq
32 | $>$ | > | 80 | $\succ$ | \succ
33 | $\ngtr$ | \ngtr | 81 | $\nsucc$ | \nsucc
34 | $\gg$ | \gg | 82 | $\succeq$ | \succeq
35 | $\not\gg$ | \not\gg | 83 | $\nsucceq$ | \nsucceq
36 | $\ggg$ | \ggg | 84 | $\succneqq$ | \succneqq
37 | $\not\ggg$ | \not\ggg | 85 | $\preccurlyeq$ | \preccurlyeq
38 | $\gtrdot$ | \gtrdot | 86 | $\curlyeqprec$ | \curlyeqprec
39 | $\le$ | \le | 87 | $\succcurlyeq$ | \succcurlyeq
40 | $\leq$ | \leq | 88 | $\curlyeqsucc$ | \curlyeqsucc
41 | $\lneq$ | \lneq | 89 | $\precsim$ | \precsim
42 | $\leqq$ | \leqq | 90 | $\precnsim$ | \precnsim
43 | $\nleq$ | \nleq | 91 | $\precapprox$ | \precapprox
44 | $\nleqq$ | \nleqq | 92 | $\precnapprox$ | \precnapprox
45 | $\lneqq$ | \lneqq | 93 | $\succsim$ | \succsim
46 | $\lvertneqq$ | \lvertneqq | 94 | $\succnsim$ | \succnsim
47 | $\ge$ | \ge | 95 | $\succapprox$ | \succapprox
48 | $\geq$ | \geq | 96 | $\succnapprox$ | \succnapprox

### 几何符号 Geometric symbols

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | $\parallel$ | \parallel | 14 | $\lozenge$ | \lozenge
2 | $\nparallel$ |  \nparallel | 15 | $\blacklozenge$ |  \blacklozenge
3 | $\shortparallel$ |  \shortparallel | 16 | $\bigstar$ |  \bigstar
4 | $\nshortparallel$ |  \nshortparallel | 17 | $\bigcirc$ | \bigcirc
5 | $\perp$ | \perp | 18 | $\triangle$ |  \triangle
6 | $\angle$ |  \angle | 19 | $\bigtriangleup$ |  \bigtriangleup
7 | $\sphericalangle$ |  \sphericalangle | 20 | $\bigtriangledown$ |  \bigtriangledown
8 | $\measuredangle$ |  \measuredangle | 21 | $\vartriangle$ | \vartriangle
9 | $45^\circ$ |  45^\circ | 22 | $\triangledown$ |  \triangledown
10 | $\Box$ | \Box | 23 | $\blacktriangle$ | \blacktriangle
11 | $\blacksquare$ |  \blacksquare | 24 | $\blacktriangledown$ |  \blacktriangledown
12 | $\diamond$ |  \diamond | 25 | $\blacktriangleleft$ |  \blacktriangleleft
13 | $\Diamond$ |  \Diamond \lozenge | 26 | $\blacktriangleright$ |  \blacktriangleright

### 逻辑符号 Logic symbols

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | $\forall$ | \forall | 20 | $\neg$ | \neg
2 | $\exists$ | \exists | 21 | $\not\operatorname{R}$ | \not\operatorname{R}
3 | $\nexists$ | \nexists | 22 | $\bot$ | \bot
4 | $\therefore$ | \therefore | 23 | $\top$ | \top
5 | $\because$ | \because | 24 | $\vdash$ | \vdash
6 | $\And$ | \And | 25 | $\dashv$ | \dashv
7 | $\lor$ | \lor | 26 | $\vDash$ | \vDash
8 | $\vee$ | \vee | 27 | $\Vdash$ | \Vdash
9 | $\curlyvee$ | \curlyvee | 28 | $\models$ | \models
10 | $\bigvee$ | \bigvee | 29 | $\Vvdash$ | \Vvdash
11 | $\land$ | \land | 30 | $\nvdash$ | \nvdash
12 | $\wedge$ | \wedge | 31 | $\nVdash$ | \nVdash
13 | $\curlywedge$ | \curlywedge | 32 | $\nvDash$ | \nvDash
14 | $\bigwedge$ | \bigwedge | 33 | $\nVDash$ | \nVDash
15 | $\bar{q}$ | \bar{q} | 34 | $\ulcorner$ | \ulcorner
16 | $\bar{abc}$ | \bar{abc} | 35 | $\urcorner$ | \urcorner
17 | $\overline{q}$ | \overline{q} | 36 | $\llcorner$ | \llcorner
18 | $\overline{abc}$ | \overline{abc} | 37 | $\lrcorner$ | \lrcorner
19 | $\lnot$ | \lnot |

### 集合 Sets

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | ${}$ | {} | 23 | $\sqsubset$ | \sqsubset
2 | $\emptyset$ | \emptyset | 24 | $\supset$ | \supset
3 | $\varnothing$ | \varnothing | 25 | $\Supset$ | \Supset
4 | $\in$ | \in | 26 | $\sqsupset$ | \sqsupset
5 | $\notin$ | \notin | 27 | $\subseteq$ | \subseteq
6 | $\ni$ | \ni | 28 | $\nsubseteq$ | \nsubseteq
7 | $\cap$ | \cap | 29 | $\subsetneq$ | \subsetneq
8 | $\Cap$ | \Cap | 30 | $\varsubsetneq$ | \varsubsetneq
9 | $\sqcap$ | \sqcap | 31 | $\sqsubseteq$ | \sqsubseteq
10 | $\bigcap$ | \bigcap | 32 | $\supseteq$ | \supseteq
11 | $\cup$ | \cup | 33 | $\nsupseteq$ | \nsupseteq
12 | $\Cup$ | \Cup | 34 | $\supsetneq$ | \supsetneq
13 | $\sqcup$ | \sqcup | 35 | $\varsupsetneq$ | \varsupsetneq
14 | $\bigcup$ | \bigcup | 36 | $\sqsupseteq$ | \sqsupseteq
15 | $\bigsqcup$ | \bigsqcup | 37 | $\subseteqq$ | \subseteqq
16 | $\uplus$ | \uplus | 38 | $\nsubseteqq$ | \nsubseteqq
17 | $\biguplus$ | \biguplus | 39 | $\subsetneqq$ | \subsetneqq
18 | $\setminus$ | \setminus | 40 | $\varsubsetneqq$ | \varsubsetneqq
19 | $\smallsetminus$ | \smallsetminus | 41 | $\supseteqq$ | \supseteqq
20 | $\times$ | \times | 42 | $\nsupseteqq$ | \nsupseteqq
21 | $\subset$ | \subset | 43 | $\supsetneqq$ | \supsetneqq
22 | $\Subset$ | \Subset | 44 | $\varsupsetneqq$ | \varsupsetneqq

### 箭头 Arrows

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | $\Rrightarrow$ | \Rrightarrow | 36 | $\longmapsto$ | \longmapsto
2 | $\Lleftarrow$ | \Lleftarrow | 37 | $\rightharpoonup$ | \rightharpoonup
3 | $\Rightarrow$ | \Rightarrow | 38 | $\rightharpoondown$ | \rightharpoondown
4 | $\nRightarrow$ | \nRightarrow | 39 | $\leftharpoonup$ | \leftharpoonup
5 | $\Longrightarrow$ | \Longrightarrow | 40 | $\leftharpoondown$ | \leftharpoondown
6 | $\implies$ | \implies | 41 | $\upharpoonleft$ | \upharpoonleft
7 | $\Leftarrow$ | \Leftarrow | 42 | $\upharpoonright$ | \upharpoonright
8 | $\nLeftarrow$ | \nLeftarrow | 43 | $\downharpoonleft$ | \downharpoonleft
9 | $\Longleftarrow$ | \Longleftarrow | 44 | $\downharpoonright$ | \downharpoonright
10 | $\Leftrightarrow$ | \Leftrightarrow | 45 | $\rightleftharpoons$ | \rightleftharpoons
11 | $\nLeftrightarrow$ | \nLeftrightarrow | 46 | $\leftrightharpoons$ | \leftrightharpoons
12 | $\Longleftrightarrow$ | \Longleftrightarrow | 47 | $\curvearrowleft$ | \curvearrowleft
13 | $\iff$ | \iff | 48 | $\circlearrowleft$ | \circlearrowleft
14 | $\Uparrow$ | \Uparrow | 49 | $\Lsh$ | \Lsh
15 | $\Downarrow$ | \Downarrow | 50 | $\upuparrows$ | \upuparrows
16 | $\Updownarrow$ | \Updownarrow | 51 | $\rightrightarrows$ | \rightrightarrows
17 | $\rightarrow$ | \rightarrow | 52 | $\rightleftarrows$ | \rightleftarrows
18 | $\to$ | \to | 53 | $\rightarrowtail$ | \rightarrowtail
19 | $\nrightarrow$ | \nrightarrow | 54 | $\looparrowright$ | \looparrowright
20 | $\longrightarrow$ | \longrightarrow | 55 | $\curvearrowright$ | \curvearrowright
21 | $\leftarrow$ | \leftarrow | 56 | $\circlearrowright$ | \circlearrowright
22 | $\gets$ | \gets | 57 | $\Rsh$ | \Rsh
23 | $\nleftarrow$ | \nleftarrow | 58 | $\downdownarrows$ | \downdownarrows
24 | $\longleftarrow$ | \longleftarrow | 59 | $\leftleftarrows$ | \leftleftarrows
25 | $\leftrightarrow$ | \leftrightarrow | 60 | $\leftrightarrows$ | \leftrightarrows
26 | $\nleftrightarrow$ | \nleftrightarrow | 61 | $\leftarrowtail$ | \leftarrowtail
27 | $\longleftrightarrow$ | \longleftrightarrow | 62 | $\looparrowleft$ | \looparrowleft
28 | $\uparrow$ | \uparrow | 63 | $\hookrightarrow$ | \hookrightarrow
29 | $\downarrow$ | \downarrow | 64 | $\hookleftarrow$ | \hookleftarrow
30 | $\updownarrow$ | \updownarrow | 65 | $\multimap$ | \multimap
31 | $\nearrow$ | \nearrow | 66 | $\leftrightsquigarrow$ | \leftrightsquigarrow
32 | $\swarrow$ | \swarrow | 67 | $\rightsquigarrow$ | \rightsquigarrow
33 | $\nwarrow$ | \nwarrow | 68 | $\twoheadrightarrow$ | \twoheadrightarrow
34 | $\searrow$ | \searrow | 69 | $\twoheadleftarrow$ | \twoheadleftarrow
35 | $\mapsto$ | \mapsto |

### 特殊 Special

序号 | 图标 | LaTeX | 序号 | 图标 | LaTeX
:----: | :----: | :---- | :----: | :----: | :----
1 | $\infty$ | \infty | 33 | $\flat$ | \flat
2 | $\aleph$ | \aleph | 34 | $\natural$ | \natural
3 | $\complement$ | \complement | 35 | $\sharp$ | \sharp
4 | $\backepsilon$ | \backepsilon | 36 | $\diagup$ | \diagup
5 | $\eth$ | \eth | 37 | $\diagdown$ | \diagdown
6 | $\Finv$ | \Finv | 38 | $\centerdot$ | \centerdot
7 | $\hbar$ | \hbar | 39 | $\ltimes$ | \ltimes
8 | $\Im$ | \Im | 40 | $\rtimes$ | \rtimes
9 | $\imath$ | \imath | 41 | $\leftthreetimes$ | \leftthreetimes
10 | $\jmath$ | \jmath | 42 | $\rightthreetimes$ | \rightthreetimes
11 | $\Bbbk$ | \Bbbk | 43 | $\eqcirc$ | \eqcirc
12 | $\ell$ | \ell | 44 | $\circeq$ | \circeq
13 | $\mho$ | \mho | 45 | $\triangleq$ | \triangleq
14 | $\wp$ | \wp | 46 | $\bumpeq$ | \bumpeq
15 | $\Re$ | \Re | 47 | $\Bumpeq$ | \Bumpeq
16 | $\circledS$ | \circledS | 48 | $\doteqdot$ | \doteqdot
17 | $\amalg$ | \amalg | 49 | $\risingdotseq$ | \risingdotseq
18 | $%$ | % | 50 | $\fallingdotseq$ | \fallingdotseq
19 | $\dagger$ | \dagger | 51 | $\intercal$ | \intercal
20 | $\ddagger$ | \ddagger | 52 | $\barwedge$ | \barwedge
21 | $\ldots$ | \ldots | 53 | $\veebar$ | \veebar
22 | $\cdots$ | \cdots | 54 | $\doublebarwedge$ | \doublebarwedge
23 | $\smile$ | \smile | 55 | $\between$ | \between
24 | $\frown$ | \frown | 56 | $\pitchfork$ | \pitchfork
25 | $\wr$ | \wr | 57 | $\vartriangleleft$ | \vartriangleleft
26 | $\triangleleft$ | \triangleleft | 58 | $\ntriangleleft$ | \ntriangleleft
27 | $\triangleright$ | \triangleright | 59 | $\vartriangleright$ | \vartriangleright
28 | $\diamondsuit$ | \diamondsuit | 60 | $\ntriangleright$ | \ntriangleright
29 | $\heartsuit$ | \heartsuit | 61 | $\trianglelefteq$ | \trianglelefteq
30 | $\clubsuit$ | \clubsuit | 62 | $\ntrianglelefteq$ | \ntrianglelefteq
31 | $\spadesuit$ | \spadesuit | 63 | $\trianglerighteq$ | \trianglerighteq
32 | $\Game$ | \Game | 64 | $\ntrianglerighteq$ | \ntrianglerighteq

## 运算与函数 Operations & Functions

### 分数 Fractions

类型 | 样式 | LaTeX
:---- | :---- | :----
分数Fractions | $\frac{2}{4}x=0.5x$ | \frac{2}{4}x=0.5x or {2 \over 4}x=0.5x
小型分数Small fractions (force \textstyle) | $\tfrac{2}{4}x = 0.5x$ | \tfrac{2}{4}x = 0.5x
大型分数（不嵌套）Large (normal) fractions (force \displaystyle) | $\dfrac{2}{4} = 0.5 \qquad \dfrac{2}{c + \dfrac{2}{d + \dfrac{2}{4}}} = a$ | \dfrac{2}{4} = 0.5 \qquad \dfrac{2}{c + \dfrac{2}{d + \dfrac{2}{4}}} = a
大型分数（嵌套）Large (nested) fractions | $\cfrac{2}{c + \cfrac{2}{d + \cfrac{2}{4}}} = a$ | \cfrac{2}{c + \cfrac{2}{d + \cfrac{2}{4}}} = a
约分线的使用Cancellations in fractions |  | \cfrac{x}{1 + \cfrac{\cancel{y}}{\cancel{y}}} = \cfrac{x}{2}

**注意：** 其中`\cancel`命令需要**cancel扩展包**支持，**cancel扩展包**是一款自定义宏包，如需使用请在公式页面右上角【设置】处勾选后使用。

### 标准数值函数 Standard numerical functions

样式 | LaTeX
:---- | :----
$\exp\_a b = a^b, \exp b = e^b, 10^m$ | \exp\_a b = a^b, \exp b = e^b, 10^m
$\ln c, \lg d = \log e, \log\_{10} f$ | \ln c, \lg d = \log e, \log\_{10} f
$\sin a, \cos b, \tan c, \cot d, \sec e, \csc f$ | \sin a, \cos b, \tan c, \cot d, \sec e, \csc f
$\arcsin a, \arccos b, \arctan c$ | \arcsin a, \arccos b, \arctan c
$\operatorname{arccot} d, \operatorname{arcsec} e, \operatorname{arccsc} f$ | \operatorname{arccot} d, \operatorname{arcsec} e, \operatorname{arccsc} f
$\sinh a, \cosh b, \tanh c, \coth d$ | \sinh a, \cosh b, \tanh c, \coth d
$\operatorname{sh}k, \operatorname{ch}l, \operatorname{th}m, \operatorname{coth}n$ | \operatorname{sh}k, \operatorname{ch}l, \operatorname{th}m, \operatorname{coth}n
$\operatorname{argsh}o, \operatorname{argch}p, \operatorname{argth}q$ | \operatorname{argsh}o, \operatorname{argch}p, \operatorname{argth}q
$\operatorname{sgn}r, \left\vert s \right\vert$ | \operatorname{sgn}r, \left\vert s \right\vert
$\min(x,y), \max(x,y)$ | \min(x,y), \max(x,y)

\*\*注意：\*\*LaTeX和MathJax支持的操作符有限，如有特殊操作符，可以使用`\operatorname{}` 命令自定义，例如

```latex
\operatorname{mydefine}x
```

$$
\operatorname{mydefine}x
$$

### 根式 Radicals

| 样式                          | LaTeX                       |
| :---------------------------- | :-------------------------- |
| $\surd$                       | \surd                       |
| $\sqrt{\pi}$                  | \sqrt{\pi}                  |
| $\sqrt\[n]{\pi}$               | \sqrt\[n]{\pi}               |
| $\sqrt\[3]{\frac{x^3+y^3}{2}}$ | \sqrt\[3]{\frac{x^3+y^3}{2}} |

### 微分与导数 Differentials and derivatives

| 样式                                                         | LaTeX                                                        |
| :----------------------------------------------------------- | :----------------------------------------------------------- |
| $dt, \mathrm{d}t, \partial t, \nabla\psi$                    | dt, \mathrm{d}t, \partial t, \nabla\psi                      |
| $dy/dx, \mathrm{d}y/\mathrm{d}x, \frac{dy}{dx}, \frac{\mathrm{d}y}{\mathrm{d}x}, \frac{\partial^2}{\partial x\_1\partial x\_2}y$ | dy/dx, \mathrm{d}y/\mathrm{d}x, \frac{dy}{dx}, \frac{\mathrm{d}y}{\mathrm{d}x}, \frac{\partial^2}{\partial x\_1\partial x\_2}y |
| $\prime, \backprime, f^\prime, f', f'', f^{(3)}, \dot y, \ddot y$ | \prime, \backprime, f^\prime, f', f'', f^{(3)}, \dot y, \ddot y |

### 同余与模算术 Modular arithmetic

| 样式                                   | LaTeX                                |
| :------------------------------------- | :----------------------------------- |
| $s\_k \equiv 0 \pmod{m}$                | s\_k \equiv 0 \pmod{m}                |
| $a \bmod b$                            | a \bmod b                            |
| $\gcd(m, n), \operatorname{lcm}(m, n)$ | \gcd(m, n), \operatorname{lcm}(m, n) |
| $\mid, \nmid, \shortmid, \nshortmid$   | \mid, \nmid, \shortmid, \nshortmid   |

### 极限 Limits

| 样式                                | LaTeX                             |
| :---------------------------------- | :-------------------------------- |
| $\lim\_{n \to \infty}x\_n$            | \lim\_{n \to \infty}x\_n            |
| $\textstyle \lim\_{n \to \infty}x\_n$ | \textstyle \lim\_{n \to \infty}x\_n |

### 界限与投影 Bounds and Projections

| 样式                                     | LaTeX                                  |
| :--------------------------------------- | :------------------------------------- |
| $\min x, \max y, \inf s, \sup t$         | \min x, \max y, \inf s, \sup t         |
| $\lim u, \liminf v, \limsup w$           | \lim u, \liminf v, \limsup w           |
| $\dim p, \deg q, \det m, \ker\phi$       | \dim p, \deg q, \det m, \ker\phi       |
| $\Pr j, \hom l, \lVert z \rVert, \arg z$ | \Pr j, \hom l, \lVert z \rVert, \arg z |

### 积分 Integral

| 样式                                        | LaTeX                                     |
| :------------------------------------------ | :---------------------------------------- |
| $\int\limits\_{1}^{3}\frac{e^3/x}{x^2}, dx$ | \int\limits\_{1}^{3}\frac{e^3/x}{x^2}, dx |
| $\int\_{1}^{3}\frac{e^3/x}{x^2}, dx$        | \int\_{1}^{3}\frac{e^3/x}{x^2}, dx        |
| $\textstyle \int\limits\_{-N}^{N} e^x dx$    | \textstyle \int\limits\_{-N}^{N} e^x dx    |
| $\textstyle \int\_{-N}^{N} e^x dx$           | \textstyle \int\_{-N}^{N} e^x dx           |
| $\iint\limits\_D dx,dy$                     | \iint\limits\_D dx,dy                     |
| $\iiint\limits\_E dx,dy,dz$                | \iiint\limits\_E dx,dy,dz                |
| $\iiiint\limits\_F dx,dy,dz,dt$           | \iiiint\limits\_F dx,dy,dz,dt           |
| $\int\_{(x,y)\in C} x^3, dx + 4y^2, dy$    | \int\_{(x,y)\in C} x^3, dx + 4y^2, dy    |
| $\oint\_{(x,y)\in C} x^3, dx + 4y^2, dy$   | \oint\_{(x,y)\in C} x^3, dx + 4y^2, dy   |

\*\*注意：\*\*积分符号可以使用`\int_{}^{}`命令调用，如需双重积分符号只需将`int`替换成`iint`即可，以此类推，最高支持四重。曲线积分可使用`\oint`命令调用，但曲面积分符号在MathJax环境中并不支持`\oiint`的用法，但仍可通过`\unicode{}`命令，即Unicode代码的方式进行调用（前提是您需要在设置中打开Unicode扩展），具体使用方法如下：

```latex
\unicode{8751}  \unicode{x222F}_C %曲面积分符号的Unicode码十进制为8751,十六进制为x222F(注意x标识符)
```

```latex
\unicode{8752}  \unicode{x2230}_C %三维曲面积分符号的Unicode码十进制为8752,十六进制为x2230
```

其他积分符号：

```latex
\unicode{8753} \unicode{x2231}_c
\unicode{8754} \unicode{x2232}_c
\unicode{8755} \unicode{x2233}_c
```

### 其他大型运算 Large operators

| 类别           | 样式                           | LaTeX                        |
| :------------- | :----------------------------- | :--------------------------- |
| 求和 Summation | $$\sum\_{a}^{b}$$              | \sum\_{a}^{b}                 |
| 求和 Summation | $$\textstyle \sum\_{a}^{b}$$    | \textstyle \sum\_{a}^{b}      |
| 连乘积 Product | $$\prod\_{a}^{b}$$              | \prod\_{a}^{b}                |
| 连乘积 Product | $$\textstyle \prod\_{a}^{b}$$   | \textstyle \prod\_{a}^{b}     |
| 余积 Coproduct  | $$\coprod\_{a}^{b}$$            | \coprod\_{a}^{b}              |
| 余积 Coproduct          | $$\textstyle \coprod\_{a}^{b}$$ | \textstyle \coprod\_{a}^{b}   |
| 并集 Union          | $$\bigcup\_{a}^{b}$$            | \bigcup\_{a}^{b}              |
| 并集 Union          | $$\textstyle \bigcup\_{a}^{b}$$ | \textstyle \bigcup\_{a}^{b}   |
| 交集 Intersection          | $$\bigcap\_{a}^{b}$$            | \bigcap\_{a}^{b}              |
| 交集 Intersection         | $$\textstyle \bigcap\_{a}^{b}$$ | \textstyle \bigcap\_{a}^{b}   |
| 析取 Disjunction          | $$\bigvee\_{a}^{b}$$            | \bigvee\_{a}^{b}              |
| 析取 Disjunction          | $$\textstyle \bigvee\_{a}^{b}$$ | \textstyle \bigvee\_{a}^{b}   |
| 合取 Conjunction          | $$\bigwedge\_{a}^{b}$$          | \bigwedge\_{a}^{b}            |
| 合取 Conjunction          | $$\textstyle \bigwedge\_{a}^{b}$$ | \textstyle \bigwedge\_{a}^{b} |

## 上下标 Sub & Super

类型 | 样式 | 代码
:---- | :---- | :----
上标 Superscript | $a^2, a^{x+3}$ | a^2, a^{x+3}
下标 Subscript | $a\_2$ | a\_2
组合 Grouping | $10^{30} a^{2+2}$ | 10^{30} a^{2+2}
| $a\_{i,j} b\_{f'}$ | a\_{i,j} b\_{f'}
上下标混合Combining sub & super without and with horizontal separation | $x\_2^3$ | x\_2^3
| ${x\_2}^3$ | {x\_2}^3
上标的上标 Super super | $10^{10^{8}}$ | 10^{10^{8}}
混合标识 Preceding and/or additional sub & super | $\sideset{*1^2}{*3^4}X\_a^b$  | \sideset{*1^2}{*3^4}X\_a^b
| ${}*1^2!\Omega\_3^4$ | {}*1^2!\Omega\_3^4
顶标底标 Stacking | $\overset{\alpha}{\omega}$ | \overset{\alpha}{\omega}
| $\underset{\alpha}{\omega}$ | \underset{\alpha}{\omega}
| $\overset{\alpha}{\underset{\gamma}{\omega}}$ | \overset{\alpha}{\underset{\gamma}{\omega}}
| $\stackrel{\alpha}{\omega}$ | \stackrel{\alpha}{\omega}
导数 Derivatives | $x', y'', f', f''$ | x', y'', f', f''
| $x^\prime, y^{\prime\prime}$ | x^\prime, y^{\prime\prime}
导数Derivative dots | $\dot{x}, \ddot{x}$ | \dot{x}, \ddot{x}
下划线、上划线与向量Underlines, overlines, vectors | $\hat a \ \bar b \ \vec c$ | \hat a \ \bar b \ \vec c
| $\overrightarrow{a b} \ \overleftarrow{c d} \ \widehat{d e f}$ | \overrightarrow{a b} \ \overleftarrow{c d} \ \widehat{d e f}
| $\overline{g h i} \ \underline{j k l}$ | \overline{g h i} \ \underline{j k l}
弧度 Arc (workaround) | $\overset{\frown} {AB}$ | \overset{\frown} {AB}
箭头 Arrows | $A \xleftarrow{n+\mu-1} B \xrightarrow\[T]{n\pm i-1} C$ | A \xleftarrow{n+\mu-1} B \xrightarrow\[T]{n\pm i-1} C
大括号 Overbraces | $\overbrace{ 1+2+\cdots+100 }^{5050}$ | \overbrace{ 1+2+\cdots+100 }^{5050}
底部大括号 Underbraces | $\underbrace{ a+b+\cdots+z }*{26}$ | \underbrace{ a+b+\cdots+z }*{26}
求和运算 Sum | $$\sum*{k=1}^N k^2$$ | \sum*{k=1}^N k^2
文本模式下的求和运算 Sum (force \textstyle) | $$\textstyle \sum*{k=1}^N k^2$$ | \textstyle \sum*{k=1}^N k^2
分式中的求和运算 Sum in a fraction (default \textstyle) | $$\frac{\sum\_{k=1}^N k^2}{a}$$ | \frac{\sum\_{k=1}^N k^2}{a}
分式中的求和运算 Sum in a fraction (force \displaystyle) | $$\frac{\displaystyle \sum\_{k=1}^N k^2}{a}$$ | \frac{\displaystyle \sum\_{k=1}^N k^2}{a}
分式中的求和运算 Sum in a fraction (alternative limits style) | $$\frac{\sum\limits^{^N}*{k=1} k^2}{a}$$ | \frac{\sum\limits^{^N}*{k=1} k^2}{a}
乘积运算 Product | $$\prod\_{i=1}^N x\_i$$ | \prod\_{i=1}^N x\_i
乘积运算 Product (force \textstyle) | $$\textstyle \prod\_{i=1}^N x\_i$$ | \textstyle \prod\_{i=1}^N x\_i
副乘运算 Coproduct | $$\coprod\_{i=1}^N x\_i$$ | \coprod\_{i=1}^N x\_i
副乘运算 Coproduct (force \textstyle) | $$\textstyle \coprod\_{i=1}^N x\_i$$ | \textstyle \coprod\_{i=1}^N x\_i
极限 Limit | $$\lim\_{n \to \infty}x\_n$$ | \lim\_{n \to \infty}x\_n
极限 Limit (force \textstyle) | $$\textstyle \lim\_{n \to \infty}x\_n$$ | \textstyle \lim\_{n \to \infty}x\_n
积分 Integral | $$\int\limits\_{1}^{3}\frac{e^3/x}{x^2}, dx$$ | \int\limits\_{1}^{3}\frac{e^3/x}{x^2}, dx
积分 Integral (alternative limits style) | $$\int\_{1}^{3}\frac{e^3/x}{x^2}, dx$$ | \int\_{1}^{3}\frac{e^3/x}{x^2}, dx
积分 Integral (force \textstyle) | $$\textstyle \int\limits\_{-N}^{N} e^x dx$$ | \textstyle \int\limits\_{-N}^{N} e^x dx
积分 Integral (force \textstyle, alternative limits style) | $$\textstyle \int\_{-N}^{N} e^x dx$$ | \textstyle \int\_{-N}^{N} e^x dx
双重积分 Double integral | $$\iint\limits\_D dx,dy$$ | \iint\limits\_D dx,dy
三重积分 Triple integral | $$\iiint\limits\_E dx,dy,dz$$ | \iiint\limits\_E dx,dy,dz
四重积分 Quadruple integral | $$\iiiint\limits\_F dx,dy,dz,dt$$ | \iiiint\limits\_F dx,dy,dz,dt
路径积分 Line or path integral | $$\int\_{(x,y)\in C} x^3, dx + 4y^2, dy$$ | \int\_{(x,y)\in C} x^3, dx + 4y^2, dy
环路积分 Closed line or path integral | $$\oint\_{(x,y)\in C} x^3, dx + 4y^2, dy$$ | \oint\_{(x,y)\in C} x^3, dx + 4y^2, dy
交集 Intersections | $$\bigcap\_{i=1}^n E\_i$$ | \bigcap\_{i=1}^n E\_i
并集 Unions | $$\bigcup\_{i=1}^n E\_i$$ | \bigcup\_{i=1}^n E\_i

## 矩阵与多行列式 Matrices & Multilines

类型 | 样式 | LaTeX
:---- | :---- | :----
二项式系数Binomial coefficients | $\binom{n}{k}$ | \binom{n}{k}
小型二项式系数Small binomial coefficients (force \textstyle) | $\tbinom{n}{k}$ | \tbinom{n}{k}
大型二项式系数Large (normal) binomial coefficients (force \displaystyle) | $\dbinom{n}{k}$ | \dbinom{n}{k}
矩阵Matrices | $\begin{matrix}  x & y \z & v\end{matrix}$ | \begin{matrix}x & y \\\ z & v\end{matrix}
| $\begin{vmatrix} x & y \ z & v \end{vmatrix}$ | \begin{vmatrix}x & y \\\z & v\end{vmatrix}
| $\begin{Vmatrix} x & y \ z & v \end{Vmatrix} $ | "\begin{Vmatrix}x & y \\\z & v\end{Vmatrix}
| $\begin{bmatrix} 0 & \cdots & 0 \ \vdots & \ddots & \vdots \ 0 & \cdots & 0 \end{bmatrix}$ | \begin{bmatrix}0 & \cdots & 0 \\\\\vdots & \ddots & \vdots \\\0 & \cdots & 0\end{bmatrix}
| $\begin{Bmatrix} x & y \ z & v \end{Bmatrix}$ | \begin{Bmatrix}x & y \\\z & v\end{Bmatrix}
| $\begin{pmatrix} x & y \ z & v \end{pmatrix}$ | \begin{pmatrix}x & y \\\z & v\end{pmatrix}
| $\bigl( \begin{smallmatrix} a\&b\ c\&d \end{smallmatrix} \bigr)$ | \bigl( \begin{smallmatrix}a\&b\\\ c\&d\end{smallmatrix} \bigr)
条件定义Case distinctions | $f(n) =\begin{cases} n/2, & \text{if }n\text{ is even} \ 3n+1, & \text{if }n\text{ is odd} \end{cases}$ | f(n) =\begin{cases}n/2, & \text{if }n\text{ is even} \\\3n+1, & \text{if }n\text{ is odd}\end{cases}
多行等式Multiline equations | $\begin{align} f(x) & = (a+b)^2 \ & = a^2+2ab+b^2 \ \end{align}$ | \begin{align} f(x) & = (a+b)^2\\\\& = a^2+2ab+b^2 \\\\\end{align}
| $\begin{alignat}{2} f(x) & = (a-b)^2 \ & = a^2-2ab+b^2 \ \end{alignat}$ | \begin{alignat}{2}f(x) & = (a-b)^2 \\\\& = a^2-2ab+b^2 \\\\\end{alignat}
| $\begin{array}{lcl} z & = & a \ f(x,y,z) & = & x + y + z \end{array}$ | \begin{array}{lcl}z & = & a \\\f(x,y,z) & = & x + y + z\end{array}
| $\begin{array}{lcr} z & = & a \ f(x,y,z) & = & x + y + z \end{array}$ | \begin{array}{lcr}z & = & a \\\f(x,y,z) & = & x + y + z\end{array}
方程组Simultaneous equations | $\begin{cases} 3x + 5y + z \ 7x - 2y + 4z \ -6x + 3y + 2z \end{cases}$ | \begin{cases}3x + 5y + z \\\7x - 2y + 4z \\\\-6x + 3y + 2z\end{cases}
数组Arrays | $\begin{array}{ | c | c | c | } a & b & S \ \hline 0&0&1\ 0&1&1\ 1&0&1\ 1&1&0\ \end{array}$ | \begin{array}{ | c | c | c | } a & b & S \\\\\hline0&0&1\\\0&1&1\\\1&0&1\\\1&1&0\\\\\end{array}

## 括号 Brackets

常用的括号符号例如`( )[ ]{ }……`这些也可以在输入环境中直接使用：

```latex
2(x+y)=z
```

$$
2(x+y)=z
$$

但如果是在较大的表达式中这些符号就显得不合适了

```latex
( \frac{\pi}{2} )^n
```

$$
( \frac{\pi}{2} )^n
$$

正确用法应配合`\left`和`\right`命令使用。

```latex
\left ( \frac{\pi}{2} \right )^n
```

$$
\left ( \frac{\pi}{2} \right )^n
$$

具体可参考下表。

类型 | 样式 | LaTeX
:---- | :---- | :----
圆括号、小括号Parentheses | $\left ( \frac{a}{b} \right )$ | \left ( \frac{a}{b} \right )
方括号、中括号Brackets | $\left \[ \frac{a}{b} \right ] \quad \left \lbrack \frac{a}{b} \right \rbrack$ | \left \[ \frac{a}{b} \right ] \quad\left \lbrack \frac{a}{b} \right \rbrack
花括号、大括号Braces | $\left { \frac{a}{b} \right } \quad \left \lbrace \frac{a}{b} \right \rbrace$ | \left { \frac{a}{b} \right } \quad\left \lbrace \frac{a}{b} \right \rbrace
角括号Angle brackets | $\left \langle \frac{a}{b} \right \rangle$ | \left \langle \frac{a}{b} \right \rangle
单竖线和双竖线Bars and double bars | $\left | \frac{a}{b} \right \vert \quad \left \Vert \frac{c}{d} \right |$ | \left  | \frac{a}{b} \right \vert \quad \left \Vert \frac{c}{d} \right |
取整函数与取顶函数Floor and ceiling functions: | $\left \lfloor \frac{a}{b} \right \rfloor \quad \left \lceil \frac{c}{d} \right \rceil$ | \left \lfloor \frac{a}{b} \right \rfloor \quad\left \lceil \frac{c}{d} \right \rceil
斜线与反斜线Slashes and backslashes | $\left / \frac{a}{b} \right \backslash$ | \left / \frac{a}{b} \right \backslash
上下箭头Up, down, and up-down arrows | $\left \uparrow \frac{a}{b} \right \downarrow \quad \left \Uparrow \frac{a}{b} \right \Downarrow \quad \left \updownarrow \frac{a}{b} \right \Updownarrow$ | \left \uparrow \frac{a}{b} \right \downarrow \quad\left \Uparrow \frac{a}{b} \right \Downarrow \quad\left \updownarrow \frac{a}{b} \right \Updownarrow
混合括号Delimiters can be mixed,as long as \left and \right match | $\left \[ 0,1 \right )  \left \langle \psi \right  | $ | \left \[ 0,1 \right )\left \langle \psi \right\
如果您不希望某一侧括号显示，可以使用\left. 和 \right.（带有英文句号）Use \left. and \right. if you do not want a delimiter to appear | $\left . \frac{A}{B} \right } \to X$ | \left . \frac{A}{B} \right } \to X
括号的大小Size of the delimiters (add "l" or "r" to indicate the side for proper spacing) | $( \bigl( \Bigl( \biggl( \Biggl( \dots \Biggr] \biggr] \Bigr] \bigr] ]$ | ( \bigl( \Bigl( \biggl( \Biggl( \dots \Biggr] \biggr] \Bigr] \bigr] ]
| ${ \bigl{ \Bigl{ \biggl{ \Biggl{ \dots \Biggr\rangle \biggr\rangle \Bigr\rangle \bigr\rangle \rangle$ | { \bigl{ \Bigl{ \biggl{ \Biggl{ \dots\Biggr\rangle \biggr\rangle \Bigr\rangle \bigr\rangle \rangle
| $|  \big|  \Big|  \bigg|  \Bigg|  \dots \Bigg |  \bigg | \Big |  \big | |$ | |  \big|  \Big|  \bigg|  \Bigg|  \dots \Bigg |  \bigg | \Big |  \big |
| $\lfloor \bigl\lfloor \Bigl\lfloor \biggl\lfloor \Biggl\lfloor \dots \Biggr\rceil \biggr\rceil \Bigr\rceil \bigr\rceil \rceil$ | \lfloor \bigl\lfloor \Bigl\lfloor \biggl\lfloor \Biggl\lfloor \dots\Biggr\rceil \biggr\rceil \Bigr\rceil \bigr\rceil \rceil
| $\uparrow \big\uparrow \Big\uparrow \bigg\uparrow \Bigg\uparrow \dots \Bigg\Downarrow \bigg\Downarrow \Big\Downarrow \big\Downarrow \Downarrow$ | \uparrow \big\uparrow \Big\uparrow \bigg\uparrow \Bigg\uparrow \dots\Bigg\Downarrow \bigg\Downarrow \Big\Downarrow \big\Downarrow \Downarrow
| $\updownarrow \big\updownarrow \Big\updownarrow \bigg\updownarrow \Bigg\updownarrow \dots \Bigg\Updownarrow \bigg\Updownarrow \Big\Updownarrow \big\Updownarrow \Updownarrow$ | \updownarrow \big\updownarrow \Big\updownarrow \bigg\updownarrow \Bigg\updownarrow \dots\Bigg\Updownarrow \bigg\Updownarrow \Big\Updownarrow \big\Updownarrow \Updownarrow
| $/ \big/ \Big/ \bigg/ \Bigg/ \dots \Bigg\backslash \bigg\backslash \Big\backslash \big\backslash \backslash$ | / \big/ \Big/ \bigg/ \Bigg/ \dots \Bigg\backslash \bigg\backslash \Big\backslash \big\backslash \backslash

## 空格与换行 Spacing & Line breaking

### 空格 Spacing

MathJax能够自动处理大多数空格间距的大小，但如果您需要自己控制，可参考下表。

序号 | 样式 | LaTeX | 中文说明英文说明
:----: | :----: | :---- | :---- | :----
1 | $a \qquad b$ | a \qquad b | 双空格 | double quad space
2 | $a \quad b$ | a \quad b | 单空格 | quad space
3 | $a\ b$ | a\ b | 字符空格 | text space
4 | $a \text{ } b$ | a \text{ } b | 文本模式中的字符空格 | text space in text mode
5 | $a;b$ | a;b | 大空格 | large space
6 | $a,b$ | a,b | 小空格 | small space
7 | $ab$ | ab | 极小空格(用于乘因子) | tiny space (use for multiplication of factors)
8 | $a b$ | a b | 极小空格(用于区分其它语法) | tiny space (syntax space ignored)
9 | $\mathit{ab}$ | \mathit{ab} | 没有空格(用于多字母变量) | no space (use for multi-letter variables)
10 | $a!b$ | a!b |  负空格 | small negative space

### 换行 Line breaking

在MathJax3.0中取消了使用`\\`进行强制换行的功能，因此本页面也采取同样的逻辑，默认为单行公式环境。`\\`强制换行命令只在支持多行编辑的数学环境中才起作用，如`eqnarray`环境、`align`环境、`array`环境、`matrix`环境等等。如您需要显示多行公式，请在此类环境中输入公式，具体用法参见章节\[2.10]\(#2.10 LaTeX环境 LaTeX environments)。

## 颜色 Colors

### 字体颜色 Font colors

在公式中可以使用`\color{options}{math}`来调用颜色命令，第一个参数为颜色，第二个参数为公式或文本内容。例如:

```latex
{\color{Blue}x^2}+{\color{Orange}2x}-{\color{LimeGreen}1}
```

$$
{\color{Blue}x^2}+{\color{Orange}2x}-{\color{LimeGreen}1}
$$

```latex
x_{1,2}=\frac{{\color{Blue}-b}\pm\sqrt{\color{Red}b^2-4ac}}{\color{Green}2a }
```

$$
x\_{1,2}=\frac{{\color{Blue}-b}\pm\sqrt{\color{Red}b^2-4ac}}{\color{Green}2a }
$$

**注意：** 使用`\color`命令时，请将需要设置颜色的部分用`{ }`整体扩住，以表明`\color`函数作用范围。

### 背景颜色 Background color

在文本环境中可以使用`\colorbox{options}{text}`来调用背景颜色命令，第一个参数为颜色，第二个颜色为文本内容。例如：

```latex
\colorbox{yellow}{Thistext}
```

$$
\colorbox{yellow}{text}
$$

**注意：** 若需要在数学环境中使用`\colorbox{}{}`，请在第二个参数内加入`$\displaystyle + 公式$`，例如：

```latex
\colorbox{yellow}{$\displaystyle \frac{a}{b}$}`
```

$$
\colorbox{yellow}{$\displaystyle \frac{a}{b}$}
$$

或者您可以使用 **Bbox扩展** 来替换`\colorbox`命令，详见下条2.7.3。

### 用Bbox扩展设置背景颜色 Setting background color with Bbox

Bbox扩展是一款自定义宏包，如需使用请在公式页面右上角【设置】处勾选后使用。
具体用法如下：

## 设置背景颜色 Setting Background color

在公式中可以使用`\bbox[options]{math}`来调用背景颜色命令，第一个参数为颜色或大小，需注意用`[ ]`包围，第二个参数为公式。例如:

```latex
\bbox[red]{x+y}
```

## 调整背景大小 Setting Background Size

默认情况下，背景大小为作用范围的最大边界，如需扩大背景，可在第一个参数中加入大小信息，例如：

```latex
\bbox[2pt]{x+y}  %设置透明背景，并增加2pt额外距离
```

```latex
\bbox[red,5pt]{x+y}  %设置红色背景，并增加5pt额外距离
```

### 默认支持颜色 Colors supported

支 |  持   |  颜  | 色
:--- | :--- | :--- | :--
${\color{Apricot}Apricot}$ | ${\color{Emerald}Emerald}$ | ${\color{OliveGreen}OliveGreen}$ | ${\color{RubineRed}RubineRed}$
${\color{Aquamarine}Aquamarine}$ | ${\color{ForestGreen}ForestGreen}$ | ${\color{Orange}Orange}$ | ${\color{Salmon}Salmon}$
${\color{Bittersweet}Bittersweet}$ | ${\color{Fuchsia}Fuchsia}$ | ${\color{OrangeRed}OrangeRed}$ | ${\color{SeaGreen}SeaGreen}$
${\color{Black}Black}$ | ${\color{Goldenrod}Goldenrod}$ | ${\color{Orchid}Orchid}$ | ${\color{Sepia}Sepia}$
${\color{Blue}Blue}$ | ${\color{Gray}Gray}$ | ${\color{Peach}Peach}$ | ${\color{SkyBlue}SkyBlue}$
${\color{BlueGreen}BlueGreen}$ | ${\color{Green}Green}$ | ${\color{Periwinkle}Periwinkle}$ | ${\color{SpringGreen}SpringGreen}$
${\color{BlueViolet}BlueViolet}$ | ${\color{GreenYellow}GreenYellow}$ | ${\color{PineGreen}PineGreen}$ | ${\color{Tan}Tan}$
${\color{BrickRed}BrickRed}$ | ${\color{JungleGreen}JungleGreen}$ | ${\color{Plum}Plum}$ | ${\color{TealBlue}TealBlue}$
${\color{Brown}Brown}$ | ${\color{Lavender}Lavender}$ | ${\color{ProcessBlue}ProcessBlue}$ | ${\color{Thistle}Thistle}$
${\color{BurntOrange}BurntOrange}$ | ${\color{LimeGreen}LimeGreen}$ | ${\color{Purple}Purple}$ | ${\color{Turquoise}Turquoise}$
${\color{CadetBlue}CadetBlue}$ | ${\color{Magenta}Magenta}$ | ${\color{RawSienna}RawSienna}$ | ${\color{Violet}Violet}$
${\color{CarnationPink}CarnationPink}$ | ${\color{Mahogany}Mahogany}$ | ${\color{Red}Red}$ | ${\color{VioletRed}VioletRed}$
${\color{Cerulean}Cerulean}$ | ${\color{Maroon}Maroon}$ | ${\color{RedOrange}RedOrange}$ | ${\color{White}White}$
${\color{CornflowerBlue}CornflowerBlue}$ | ${\color{Melon}Melon}$ | ${\color{RedViolet}RedViolet}$ | ${\color{WildStrawberry}WildStrawberry}$
${\color{Cyan}Cyan}$ | ${\color{MidnightBlue}MidnightBlue}$ | ${\color{Rhodamine}Rhodamine}$ | ${\color{Yellow}Yellow}$
${\color{Dandelion}Dandelion}$ | ${\color{Mulberry}Mulberry}$ | ${\color{RoyalBlue}RoyalBlue}$ | ${\color{YellowGreen}YellowGreen}$
${\color{DarkOrchid}DarkOrchid}$ | ${\color{NavyBlue}NavyBlue}$ | ${\color{RoyalPurple}RoyalPurple}$ | ${\color{YellowOrange}YellowOrange}$

### 使用RGB颜色 Use RGB color

如需在`\color`命令中使用自选RGB颜色，可使用`{\color[RGB]{0,0,0} } `命令，例如：

```latex
{\color[RGB]{0,200,0} e^{i \pi} + 1 = 0} 
```

$$
{\color\[RGB]{0,200,0} e^{i \pi} + 1 = 0}
$$

### 自定义颜色 Custom colors

可使用`\definecolor`命令进行自定义颜色，例如：

```latex
\definecolor{mygreen}{RGB}{0,200,0} {\color{mygreen}e^{i \pi} + 1 = 0 } 
```

$$
\definecolor{mygreen}{RGB}{0,200,0} {\color{mygreen}e^{i \pi} + 1 = 0 }
$$

## 字体字号 Fonts & Size

### 字体 Fonts

如您需要替换公式内容的字体，可以点击工具栏下方的\*\*【字体】\*\*按钮进行相关操作。因有一些特定代码Mathjax3.0并没有相关支持，所以下表仅做参考。

样式 | LaTeX
:---- | :----
希腊字母 Greek alphabet|
$\mathrm{A} \mathrm{B} \Gamma \Delta \mathrm{E} \mathrm{Z} \mathrm{H} \Theta$ | \mathrm{A} \mathrm{B} \Gamma \Delta \mathrm{E} \mathrm{Z} \mathrm{H} \Theta
$\mathrm{I} \mathrm{K} \Lambda \mathrm{M} \mathrm{N} \Xi \mathrm{O} \Pi$ | \mathrm{I} \mathrm{K} \Lambda \mathrm{M} \mathrm{N} \Xi \mathrm{O} \Pi
$\mathrm{R} \Sigma \mathrm{T} \Upsilon \Phi \mathrm{X} \Psi \Omega$ | \mathrm{R} \Sigma \mathrm{T} \Upsilon \Phi \mathrm{X} \Psi \Omega
$\alpha \beta \gamma \delta \epsilon \zeta \eta \theta$ | \alpha \beta \gamma \delta \epsilon \zeta \eta \theta
$\iota \kappa \lambda \mu \nu \xi \omicron \pi$ | \iota \kappa \lambda \mu \nu \xi \omicron \pi
$\rho \sigma \tau \upsilon \phi \chi \psi \omega$ | \rho \sigma \tau \upsilon \phi \chi \psi \omega
$\varGamma \varDelta \varTheta \varLambda \varXi \varPi \varSigma \varPhi \varUpsilon \varOmega$ | \varGamma \varDelta \varTheta \varLambda \varXi \varPi \varSigma \varPhi \varUpsilon \varOmega
$\varepsilon \digamma \varkappa \varpi \varrho \varsigma \vartheta \varphi$ | \varepsilon \digamma \varkappa \varpi \varrho \varsigma \vartheta \varphi
希伯来字母 Hebrew symbols |\
$\aleph \beth \gimel \daleth$ | \aleph \beth \gimel \daleth
黑板报体 Blackboard bold/scripts |\
$\mathbb{ABCDEFGHI}$ | \mathbb{ABCDEFGHI}
$\mathbb{JKLMNOPQR}$ | \mathbb{JKLMNOPQR}
$\mathbb{STUVWXYZ}$ | \mathbb{STUVWXYZ}
粗体 Boldface |\
$\mathbf{ABCDEFGHI}$ | \mathbf{ABCDEFGHI}
$\mathbf{JKLMNOPQR}$ | \mathbf{JKLMNOPQR}
$\mathbf{STUVWXYZ}$ | \mathbf{STUVWXYZ}
$\mathbf{abcdefghijklm}$ | \mathbf{abcdefghijklm}
$\mathbf{nopqrstuvwxyz}$ | \mathbf{nopqrstuvwxyz}
$\mathbf{0123456789}$ | \mathbf{0123456789}
粗体希腊字母 Boldface (Greek) |\
$\boldsymbol{\mathrm{A} \mathrm{B} \Gamma \Delta \mathrm{E} \mathrm{Z} \mathrm{H} \Theta}$ | \boldsymbol{\mathrm{A} \mathrm{B} \Gamma \Delta \mathrm{E} \mathrm{Z} \mathrm{H} \Theta}
$\boldsymbol{\mathrm{I} \mathrm{K} \Lambda \mathrm{M} \mathrm{N} \Xi \mathrm{O} \Pi}$ | \boldsymbol{\mathrm{I} \mathrm{K} \Lambda \mathrm{M} \mathrm{N} \Xi \mathrm{O} \Pi}
$\boldsymbol{\mathrm{R} \Sigma \mathrm{T} \Upsilon \Phi \mathrm{X} \Psi \Omega}$ | \boldsymbol{\mathrm{R} \Sigma \mathrm{T} \Upsilon \Phi \mathrm{X} \Psi \Omega}
$\boldsymbol{\alpha \beta \gamma \delta \epsilon \zeta \eta \theta}$ | \boldsymbol{\alpha \beta \gamma \delta \epsilon \zeta \eta \theta}
$\boldsymbol{\iota \kappa \lambda \mu \nu \xi \omicron \pi}$ | \boldsymbol{\iota \kappa \lambda \mu \nu \xi \omicron \pi}
$\boldsymbol{\rho \sigma \tau \upsilon \phi \chi \psi \omega}$ | \boldsymbol{\rho \sigma \tau \upsilon \phi \chi \psi \omega}
$\boldsymbol{\varepsilon\digamma\varkappa\varpi}$ | \boldsymbol{\varepsilon\digamma\varkappa\varpi}
$\boldsymbol{\varrho\varsigma\vartheta\varphi}$ | \boldsymbol{\varrho\varsigma\vartheta\varphi}
斜体 Italics (拉丁字母默认default for Latin alphabet) |\
$\mathit{0123456789}$ | \mathit{0123456789}
罗马体 Roman typeface | Roman typeface
$\mathrm{ABCDEFGHI}$ | \mathrm{ABCDEFGHI}
$\mathrm{JKLMNOPQR}$ | \mathrm{JKLMNOPQR}
$\mathrm{STUVWXYZ}$ | \mathrm{STUVWXYZ}
$\mathrm{abcdefghijklm}$ | \mathrm{abcdefghijklm}
$\mathrm{nopqrstuvwxyz}$ | \mathrm{nopqrstuvwxyz}
$\mathrm{0123456789}$ | \mathrm{0123456789}
无衬线体 Sans serif |\
$\mathsf{ABCDEFGHI}$ | \mathsf{ABCDEFGHI}
$\mathsf{JKLMNOPQR}$ | \mathsf{JKLMNOPQR}
$\mathsf{STUVWXYZ}$ | \mathsf{STUVWXYZ}
$\mathsf{abcdefghijklm}$ | \mathsf{abcdefghijklm}
$\mathsf{nopqrstuvwxyz}$ | \mathsf{nopqrstuvwxyz}
$\mathsf{0123456789}$ | \mathsf{0123456789}
手写体 Calligraphy/花体 script |\
$\mathcal{ABCDEFGHI}$ | \mathcal{ABCDEFGHI}
$\mathcal{JKLMNOPQR}$ | \mathcal{JKLMNOPQR}
$\mathcal{STUVWXYZ}$ | \mathcal{STUVWXYZ}
德文尖角体 Fraktur typeface |\
$\mathfrak{ABCDEFGHI}$ | \mathfrak{ABCDEFGHI}
$\mathfrak{JKLMNOPQR}$ | \mathfrak{JKLMNOPQR}
$\mathfrak{STUVWXYZ}$ | \mathfrak{STUVWXYZ}
$\mathfrak{abcdefghijklm}$ | \mathfrak{abcdefghijklm}
$\mathfrak{nopqrstuvwxyz}$ | \mathfrak{nopqrstuvwxyz}
$\mathfrak{0123456789}$ | \mathfrak{0123456789}
小型手写体 Small scriptstyle text |\
${\scriptstyle\text{abcdefghijklm}}$ | {\scriptstyle\text{abcdefghijklm}}

### 字号 Size

| 样式                              | LaTeX                           |
| :-------------------------------- | :------------------------------ |
| ${\tiny abc巨小tiny}$             | {\tiny abc巨小tiny}             |
| ${\scriptsize abc超小scriptsize}$ | {\scriptsize abc超小scriptsize} |
| ${\small abc小small}$             | {\small abc小small}             |
| ${\normalsize abc正常normal}$     | {\normalsize abc正常normal}     |
| ${\large abc大large}$             | {\large abc大large}             |
| ${\Large abc超大Large}$           | {\Large abc超大Large}           |
| ${\LARGE abc特大LARGE}$           | {\LARGE abc特大LARGE}           |
| ${\huge abc巨大huge}$             | {\huge abc巨大huge}             |
| ${\Huge abc巨无霸Huge}$           | {\Huge abc巨无霸Huge}           |

**注意：**如您导出**SVG格式**，理论上字体的整体大小并无用处，因为**SVG**为矢量图，所以大可不必担心图片不清晰的问题，即便是您选择下载**PNG格式**的公式图片，图片整体尺寸也被默认设定为**4K**。所以此处的字号命令只为设置公式**相对大小**时使用，例如：

```latex
{\tiny x+y=z}x+y=z{\Huge x+y=z}
```

$$
{\tiny x+y=z}x+y=z{\Huge x+y=z}
$$

## 方程式编号 Equation numbering

本页面可采用开启AMS宏包的方式获得方程自动编号，AMS拓展包的具体开启方式请参考2.11.4。

默认自动编号只在部分环境中起作用，如{equation}、{eqnarray}等，例如：

在AMS包开启状态下，会在公式后进行自动编号：

```latex
\begin{eqnarray}
E = mc^2 \\
e^{i\pi}+1=0 
\end{eqnarray}
```

$$
\begin{eqnarray}
E = mc^2 \tag{1}\\
e^{i\pi}+1=0 \tag{2}
\end{eqnarray}
$$
如您在开启了AMS包状态下，全部公式均不希望出现编号，可使用{equation\*}、或者{eqnarray\*}环境，如：

```latex
\begin{eqnarray*}
E = mc^2 \\
e^{i\pi}+1=0 
\end{eqnarray*}
```

$$
\begin{eqnarray\*}
E = mc^2 \\
e^{i\pi}+1=0
\end{eqnarray\*}
$$

如您在开启了AMS包状态下，个别公式不希望出现编号，或者个别公式希望出现特有编号，可在公式后面使用`\tag{}`或者`\notag`命令，如：

```latex
\begin{eqnarray}
E = mc^2 \notag\\
e^{i\pi}+1=0 \tag{b}
\end{eqnarray}
```

$$
\begin{eqnarray}
E = mc^2 \notag\\
e^{i\pi}+1=0 \tag{b}
\end{eqnarray}
$$

## LaTeX环境 LaTeX environments

环境通常是对代码段的整体描述，用于表达此段代码的角色，如，是矩阵？单行公式？多行公式？还是对齐公式等（本页面不支持文档环境），不同的环境起到的作用不同。以`\begin{environments}`开始，`\end{environments}`结束。如最常用的矩阵命令，也是环境的一种，用法如下：

```latex
\begin{bmatrix}
1 & 0 \\
0 & 1
\end{bmatrix}
```

$$
\begin{bmatrix}
1 & 0 \\
0 & 1
\end{bmatrix}
$$
具体矩阵用法可参考章节\[2.4]\(#2.4 矩阵与多行列式 Matrices & Multilines)，下面给出几种其它常用环境的具体用法：

### equation环境

\begin{equation}是单行公式环境，这意味着在此环境中只可以输入单行公式，同时`\\`等强制换行命令失效。如需对单行长公式进行强制换行，可使用`\begin{split}`环境进行嵌套，并用`&`字符表示对齐位置，如：

```latex
\begin{equation}
\begin{split}
 e ^ { x } = & 1 + \frac { x } { 1 ! } + \frac { x ^ { 2 } } { 2 ! } + \frac { x ^ { 3 } } { 3 ! } + \cdots \\
& - \infty < x < \infty  
\end{split}
\end{equation}
```

$$
\begin{equation}
\begin{split}
e ^ { x } = & 1 + \frac { x } { 1 ! } + \frac { x ^ { 2 } } { 2 ! } + \frac { x ^ { 3 } } { 3 ! } + \cdots \\
& - \infty < x < \infty\
\end{split}
\end{equation}
$$

### eqnarray环境

\begin{eqnarray}是多行公式环境，环境内的所有公式默认右对齐，由LaTeX内核提供。

### align环境

\begin{align}是多行公式环境，环境内的所有公式默认右对齐，由amsmath提供，排版较为灵活，如需表示多行公式推荐使用此环境。

```latex
\begin{align}
y = x \\
y = 3x^2 + 5x + 2 
\end{align}
```

$$
\begin{align}
y = x \\
y = 3x^2 + 5x + 2
\end{align}
$$
可使用`&`字符调整对齐位置。

```latex
\begin{align}
y & = x \\
y & = 3x^2 + 5x + 2 
\end{align}
```

$$
\begin{align}
y & = x \\
y & = 3x^2 + 5x + 2
\end{align}
$$

### array环境

\begin{array}是数组环境，需手动输入对齐参数：

```latex
\begin{array}{|c|l|r|} 
a & b & S \\
\hline 
0 & 0 & 1 \\
0 & 1 & 1 \\
1 & 0 & 1 \\
1 & 1 & 0 \\
\end{array}
```

$$
\begin{array}{|c|l|r|}
a & b & S \\
\hline
00 & 00 & 10 \\
0 & 1 & 1 \\
1 & 0 & 1 \\
1 & 1 & 0 \\
\end{array}
$$

对齐参数使用`c l r`分别表示居中、居左和居右，如需竖线边框可直接在对齐参数区域输入`|`即可，如需横线边框可使用`\hline`命令。

更多环境使用可参考章节\[2.4]\(#2.4 矩阵与多行列式 Matrices & Multilines)。

## TeX扩展包使用 TeX and LaTeX extensions

### physics扩展包

physics是一款便携出入物理符号、矩阵及方程的拓展包，使用前需要在设置中手动勾选。其具体用法可参考[此文档](http://mirrors.ibiblio.org/CTAN/macros/latex/contrib/physics/physics.pdf)。

### mhchem扩展包

mhchem是一款便捷输入化学方程式的扩展包，使用前需要在设置中手动勾选。其具体用法如下：

## 引用

基本命令为`\ce{}`，可在`{}`中输入化学相关符号。

## 化学式

在化学环境中，数字`0123456789`默认为下标，`+-`默认为上标，如需强制上标可使用`^`符号，例如

```latex
\ce{H2O}  \ce{Sb2O3}  \ce{H+}  \ce{CrO4^2-}  \ce{[AgCl2]-}  \ce{Y^99+}  \ce{Y^{99+}}
```

## 化学计量数

在化学环境中，计量数应与前面的大写字母使用**空格**分割，对于分数计量数，只需输入`1/2`即可显示$\frac{1}{2}$的效果，如特殊情况需要显示`1/2`格式，请用`( )`扩起。

```latex
\ce{2H2O}  \ce{0.5 H2O}  \ce{1/2H2O}  \ce{(1/2)H2O}  \ce{$n$ H2O}
```

## 同位素

```latex
\ce{^{227}_{90}Th+}  \ce{^227_90Th+}  \ce{^{0}_{-1}n^{-}}  \ce{^0_-1n-}
```

在一个复杂的化学式中，上标属于左侧元素还是右侧元素可能并不会明显的体现出来，但为了规范输入，建议使用`{}`分隔符作为区分：

```latex
\ce{H{}^3HO}  \ce{H^3HO}
```

## 反应箭头

mhchem提供了方便的反应箭头输入模式

```latex
\ce{A -> B}   \ce{A <- B}  \ce{A <-> B} 
```

```latex
\ce{A <--> B}  \ce{A <=> B}  \ce{A <=>> B}  \ce{A <<=> B}
```

箭头可以带有两个参数，即`>[][]`，第一个`[]`表示上方参数，第二个`[]`表示下方参数

```latex
\ce{A ->[H2O] B}   \ce{A ->[{上方文字}][{下方文字}] B}
```

## 气体和沉淀

在化学环境中可使用独立的`^`表示气体$\uparrow$，使用独立的`v`(小写字母v)表示沉淀$\downarrow$

```latex
\ce{SO4^2- + Ba^2+ -> BaSO4 v}
```

```latex
\ce{A v B (v) -> B ^ B (^)}
```

## 一些复杂的例子

```latex
\ce{Zn^2+  <=>[+ 2OH-][+ 2H+]  $\underset{\text{amphoteres Hydroxid}}{\ce{Zn(OH)2 v}}$  <=>[+ 2OH-][+ 2H+]  $\underset{\text{Hydroxozikat}}{\ce{[Zn(OH)4]^2-}}$}
```

```latex
\ce{$K = \frac{[\ce{Hg^2+}][\ce{Hg}]}{[\ce{Hg2^2+}]}$}
```

```latex
\ce{$K = \ce{\frac{[Hg^2+][Hg]}{[Hg2^2+]}}$}
```

```latex
\ce{Hg^2+ ->[I-]  $\underset{\mathrm{red}}{\ce{HgI2}}$  ->[I-]  $\underset{\mathrm{red}}{\ce{[Hg^{II}I4]^2-}}$}
```

### cancel扩展包

cancel扩展包为显示分数中**约分线**的TeX宏包，或显示其他划除效果，基本命令为`\cancel{}`，例如：

```latex
\cfrac{x}{1 + \cfrac{\cancel{y}}{\cancel{y}}} = \cfrac{x}{2}
```

```latex
\cancel{e^{i \pi} + 1 =0}
```

### Ams扩展包

本页面集成了大部分ams命令，即默认已打开。本拓展只为自动显示公式序号使用。

如，以下代码：

```latex
\begin{equation}
E = mc^2
\end{equation}
```

在ams包未开启状态下：
$$
\begin{equation}
E = mc^2
\end{equation}
$$
在ams包开启状态下：
$$
\begin{equation}
E = mc^2 \tag{1}
\end{equation}
$$
具体自动编号用法请参考章节\[2.9]\(#2.9 方程式编号 Equation numbering)。

### AmsCd扩展包

amsCd扩展包是一款生成矩阵图的TeX宏包环境，基本环境命令为`\begin{CD}`  `\end{CD}`，基本用法如下：

`@<<<`表示左箭头；

`@>>>`表示右箭头；

`@AAA`表示上箭头；

`@VVV`表示下箭头；

`@=`表示水平等号；

`@|`表示数值等号；

`@.`表示空箭头（占位）。

以`@`表示箭头开始，以`<、>、A、V`等表示箭头方向。如需在箭头上或下插入变量，直接在第一和第二，或第二和第三个箭头方向符号中插入即可，用法实例如下：

```latex
\begin{CD}
A @>a>> B\\
@VVbV @VVcV\\
C @>d>> D
\end{CD}
```

```latex
\begin{CD}
A @>a>b> B\\
@VlVrV @AlArA\\
C @<a<b< D
\end{CD}
```

### Unicode扩展包

Unicode扩展包一款显示Unicode字符的TeX宏包，基本命令为`\unicode{}`，`{}`中参数应输入指定字符的**十进制**或**十六进制**Unicode代码，注意十六进制编码需在前面添加标识位`x`，例如：

```latex
\unicode{8751} \unicode{x220f}
```

### Bbox扩展包

Bbox扩展包一款用于设置公式背景颜色的TeX宏包，具体用法参见\[2.7.3]\(#2.7.3 用Bbox扩展设置背景颜色 Setting background color with Bbox)

### NoErrors扩展包

NoErrors扩展包是一款阻止显示 TeX 错误消息的宏包，使用后将不会像是代码具体错误，而只会显示原始 TeX 代码。

### NewCommand扩展包

Newcommand扩展包提供了\def, \newcommand，\renewcommand，\let，\newenvironment 和 \renewenvironment 宏命令，用于在 TeX中创建新的宏和环境。例如：

```latex
\def\RR{{\bf R}}  %将{\bf R}（加粗的R）定义为\RR
\RR               %调用\RR命令
```

### 关于 About

如有任何问题可以点击页面下方的邮箱图标向我们反馈，感谢您的使用！

### 参考文献 Reference

[1. LaTeX公式编辑器](http://47.104.179.138/)
[2. MathJax Documentation](https://docs.mathjax.org/en/latest/index.html)
[3. Displaying a formula](https://en.wikipedia.org/wiki/Help:Displaying_a_formula)
[4. mathjax/MathJax: Beautiful math in all browsers - GitHub](https://github.com/mathjax/MathJax)
[5. mhchem for MathJax](https://mhchem.github.io/MathJax-mhchem/)

***

via: <https://github.com/QianJianTech/LaTeXLive/blob/master/README.md>

---

---
url: https://ain.hmgf.hxcn.space/writing/05-LaTeX-doc.md
---

# LaTeX 的文档元素

## 一、章节

* article 文档类带编号的层级为 `\section` / `\subsection` / `\subsubsection` 三级；

* report/book 文档类带编号的层级为 `\chapter` / `\section` / `\subsection` 三级。

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 
	\section{第一章节}
	 
	Hello World 
	
	\subsection{小标题} 
	Hello World 
	
	\section{第二章节} 
	Hello World 

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216204556.png)

默认情况下，第⼀级章节标题是居中显⽰的(注意，上图预览视图的第⼀⾏是⻚眉)，显然这不符合⼤多数需要，为此需要在导⾔区添加⼀些设置章节格式的代码

```latex
\documentclass[UTF8]{ctexart} 
\CTEXsetup[name={第,章}]{section}
\CTEXsetup[format={\zihao{-3}\raggedright\bfseries}]{section}

\begin{document} 
	\section{第一章节}
	 
	Hello World 
	
	\subsection{小标题} 
	Hello World 
	
	\section{第二章节} 
	Hello World 

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216205325.png)

## 二、目录

在 LATEX 中生成目录非常容易，只需在合适的地方使用命令：

```latex
\tableofcontents
```

这个命令会生成单独的一章（book / report）或一节（article），标题默认为 “Contents”。

有时我们使用了 \chapter\* 或 \section\* 这样不生成目录项的章节标题命令，而又想手动生成该章节的目录项，可以在标题命令后面使用：

```latex
\addcontentsline{toc}{⟨level⟩}{⟨title⟩}
```

其中 ⟨level⟩ 为章节层次 chapter 或 section 等，⟨title⟩ 为出现于目录项的章节标题。

## 三、标题页

LATEX 支持生成简单的标题页。首先需要给定标题和作者等信息：

```latex
\title{⟨title⟩} 
\author{⟨author⟩}
\date{⟨date⟩}`
```

其中前两个命令是必须的（不用 `\title` 会报错；不用 `\author` 会警告），`\date` 命令可选。`LATEX` 还提供了一个 `\today` 命令自动生成当前日期，`\date` 默认使用 `\today`。在 `\title`、`\author`等命令内可以使用 `\thanks` 命令生成标题页的脚注，用 `\and` 隔开多个人名。

在信息给定后，就可以使用 `\maketitle` 命令生成一个简单的标题页了。

## 四、特殊环境

### 1、列表环境

LATEX 提供了基本的有序和无序列表环境 enumerate 和 itemize，两者的用法很类似，都用 \item 标明每个列表项。enumerate 环境会自动对列表项编号。

其中 \item 可带一个可选参数，将有序列表的计数或者无序列表的符号替换成自定义的符号。列表可以嵌套使用，最多嵌套四层。

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

\begin{enumerate}
	\item An item.
	\begin{enumerate}
		\item A nested item.\label{itref}
		\item[*] A starred item.
	\end{enumerate}
	\item Reference(\ref{itref}).
\end{enumerate}

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220145657.png)

## 2、对齐环境

用`\centering`、`\raggedright`、`\raggedleft`命令直接改变文字的对齐方式

```latex
\documentclass[UTF8]{ctexart} 

\begin{document} 

\centering
Centered text paragraph.

\raggedright
Left-aligned text paragraph.

\raggedleft
Right-aligned text paragraph.

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200220150657.png)

## 五、图片

LATEX 本身不支持插图功能，需要由 graphicx 宏包辅助支持。在调用了 graphicx 宏包以后，就可以使用 `\includegraphics` 命令加载图片了：

```latex
\includegraphics[⟨options⟩]{⟨filename⟩}
```

其中 `⟨filename⟩` 为图片文件名，与使用 `\include` 命令类似，文件名有时需要使用相对路径或绝对路径。图片文件的扩展名可写可不写。

另外 `graphicx` 宏包还提供了 `\graphicspath` 命令，用于声明一个或多个图片文件存放的目录，使用这些目录里的图片时可不用写路径。

***

via: <https://github.com/qinnian/LaTeX>

---

---
url: https://ain.hmgf.hxcn.space/writing/06-LaTeX-style.md
---

# LaTeX 的样式设定

## 一、字体选择

下⾯代码⽤于设置正⽂部分中英⽂的默认字体分别为 `Roman Times New` 和 `楷体-简` （Windows 上写楷体即可）

`xeCJK` 宏包⽤于设置中⽂字体，`fontspec` 宏包⽤于设置 英⽂字体，将其添加到导⾔区即可。

```latex
\usepackage{xeCJK} 
\setCJKmainfont[BoldFont={黑体-简}]{楷体-简} 
```

```latex
\usepackage{fontspec} 
\setmainfont{Times New Roman}
```

### 二、字体大小

通常使⽤ `\zihao{数字}` 的⽅式来改变字体⼤⼩，数字的⼤⼩表⽰该部分⽂字为⼏号字体。

```latex
\documentclass[UTF8]{ctexart} 
\CTEXsetup[name={第,章}]{section}
\CTEXsetup[format={\zihao{-3}\raggedright\bfseries}]{section}


\begin{document} 

    \section{这是第一章节} 
    \zihao{2} 
    Hello World 
        \subsection{这是次级章节} 
        Hello World
    \section{这是第二章节} 
    Hello World 

\end{document}
```

![](https://raw.githubusercontent.com/qinnian/FigureBed/master/20200216210749.png)

如果只想改变某部分⽂字的⼤⼩，可以⽤⼀对⼤括号 {} 括住 `\zihao{数字}和⽂字` ， LaTeX 中⼀对⼤括号 {} 表⽰⼀个环境，环境内的格式控制语句只对环境中的⽂字起作⽤。

```latex
{\zihao{3} Hello World}
```

### 字体颜色

调用 color 或 xcolor 宏包后，我们就可以用如下命令切换颜色

```latex
\large\sffamily
{\color{red} 红色} \\
{\color{blue} 蓝色}
```

## 三、页面设置

### 纸张设置

LaTeX 中可以通过可选项来设置⻚⾯纸张的⼤⼩（默认为 A4 ）

```latex
\documentclass[UTF8,a4pape r]{ctexart}
```

### 页边距

LaTeX 可以⽤ geometry 宏包来设置⻚边距

```latex
\usepackage{geometry} 
\geometry{left=2.5cm,right= 2.5cm,top=2.0cm,bottom=2cm}
```

### 页眉页脚

LaTeX 中⽤ `\pagestyle` 来设置⻚眉⻚脚，默认为⻚眉显⽰ 章节标题和⻚码 ，⻚脚为空。默认⻛格⽤下⾯的代码表⽰：

```latex
\pagestyle{headings}
```

如果要取消⻚眉⻚脚，⽤代码：

```latex
\pagestyle{empty}
```

### 四、间距

#### 水平间距

LATEX 默认为将单词之间的“空格”转化为水平间距。如果需要在文中手动插入额外的水平间距，可使用 \hspace 命令

```latex
This\hspace{1.5cm}is a space of 1.5 cm.
```

#### 垂直间距

```latex
A paragraph.
\vspace{2ex}
Another paragraph.
```

### 五、超链接

```latex
\href{⟨url⟩}{⟨text⟩}
```

***

via: <https://github.com/qinnian/LaTeX>

---

---
url: https://ain.hmgf.hxcn.space/writing/the-art-of-linear-algebra-zh-cn.md
description: 线性代数图解笔记（中文），帮助理解矩阵分解与线性代数核心概念。
---

# The Art of Linear Algebra

#### -- Graphic Notes on “Linear Algebra for Everyone" --

**作者:** Kenji Hiranabe \[^author1]

在 Gilbert Strang \[^author2] 的亲切帮助下

**译者:** Kefang Liu \[^author3]

**日期:** September 1, 2021/updated today

## 摘要

我尝试为 Gilbert Strang 在书籍 “Linear Algebra for Everyone” 中介绍的矩阵的重要概念进行可视化图释, 以促进从矩阵分解的角度对向量、矩阵计算和算法的理解。\[^footnote1]它们包括矩阵分解 (Column-Row, $\boldsymbol{CR}$)、高斯消去法 (Gaussian Elimination, $\boldsymbol{LU}$)、格拉姆-施密特正交化 (Gram-Schmidt Orthogonalization, $\boldsymbol{QR}$)、特征值和对角化 (Eigenvalues and Diagonalization, $\boldsymbol{Q \Lambda Q^\mathrm{T}}$)、和奇异值分解 (Singular Value Decomposition, $\boldsymbol{U \Sigma V^\mathrm{T}}$)。

## 序言

我很高兴能看到 Kenji Hiranabe 的线性代数中的矩阵运算的图片! 这样的图片是展示代数的绝佳方式. 我们当然可以通过 行 $\boldsymbol{\cdot}$ 列 的点乘来想象矩阵乘法, 但那绝非全部 —— 它是“线性组合”与“秩1矩阵”组成的代数与艺术. 我很感激能看到日文翻译的书籍和 Kenji 的图片中的想法.

\-- Gilbert Strang

麻省理工学院数学教授

## 目录

\[\[toc]]

***

## 1、理解矩阵——4个视角

一个矩阵 ($m \times n$) 可以被视为$1$个矩阵, $mn$个数, $n$个列和$m$个行。

![从四个角度理解矩阵](https://gastigado.cnies.org/d/public/ViewingMatrix-4Ways.webp)
*图 1: 从四个角度理解矩阵*

$$
A= \begin{bmatrix}
a\_{11} & a\_{12}\\
a\_{21} & a\_{22}\\
a\_{31} & a\_{32}
\end{bmatrix}
=============

\begin{bmatrix}
| & |\\
\boldsymbol{a\_1} & \boldsymbol{a\_2}\\
| & |
\end{bmatrix}
=============

\begin{bmatrix}
\- \boldsymbol{a\_1^*} -\\
\- \boldsymbol{a\_2^*} -\\
\- \boldsymbol{a\_3^\*} -
\end{bmatrix}
$$

在这里, 列向量被标记为粗体$\boldsymbol{a\_1}$。行向量则有一个$\boldsymbol{*}$号, 标记为$\boldsymbol{a\_1^*}$。转置向量和矩阵则用$\mathrm{T}$标记为$\boldsymbol{a}^\mathrm{T}$和$A^\mathrm{T}$。

## 2、向量乘以向量——2个视角

后文中, 我将介绍一些概念, 同时列出“Linear Algebra for Everyone”一书中的相应部分 (部分编号插入如下)。详细的内容最好看书, 这里我也添加了一个简短的解释, 以便您可以通过这篇文章尽可能多地理解。

此外, 每个图都有一个简短的名称, 例如 v1 (数字 1 表示向量的乘积)、Mv1 (数字 1 表示矩阵和向量的乘积), 以及如下图 (v1) 所示的彩色圆圈。
如你所见, 随着讨论的进行, 该名称将被交叉引用。

* 1.1节 (p.2) Linear combination and dot products
* 1.3节 (p.25) Matrix of Rank One
* 1.4节 (p.29) Row way and column way

![向量乘以向量 - (v1), (v2)](https://gastigado.cnies.org/d/public/VectorTimesVector.webp)
*图 2: 向量乘以向量 - (v1), (v2)*

(v1) 是两个向量之间的基础运算, 而 (v2) 将列乘以行并产生一个秩1矩阵。理解 (v2) 的结果 (秩1) 是接下来章节的关键。

## 3、矩阵乘以向量——2个视角

一个矩阵乘以一个向量将产生三个点积组成的向量 (Mv1) 和一种$A$的列向量的线性组合。

* 1.1节 (p.3) Linear combinations
* 1.3节 (p.21) Matrices and Column Spaces

![矩阵乘以向量- (Mv1), (Mv2)](https://gastigado.cnies.org/d/public/MatrixTimesVector.webp)
*图 3: 矩阵乘以向量- (Mv1), (Mv2)*

往往你会先学习 (Mv1). 但当你习惯了从 (Mv2) 的视角看待它, 会理解$A\boldsymbol{x}$是$A$的列的线性组合。矩阵$A$的列向量的所有线性组合生成的子空间记为$\boldsymbol{C}(A)$。$A\boldsymbol{x}=\boldsymbol{0}$的解空间则是零空间, 记为$\boldsymbol{N}(A)$。

同理, 由 (vM1) 和 (vM2) 可见, 行向量乘以矩阵也是同一种理解方式。

![向量乘以矩阵 - (vM1), (vM2)](https://gastigado.cnies.org/d/public/VectorTimesMatrix.webp)
*图 4: 向量乘以矩阵 - (vM1), (vM2)*

上图$A$的行向量的所有线性组合生成的子空间记为$\boldsymbol{C}(A^\mathrm{T})$。$yA=0$的解空间是$A$的左零空间, 记为 $\boldsymbol{N}(A^\mathrm{T})$。

本书的一大亮点即为四个基本子空间: 在$\mathbb{R}^n$ 上的$\boldsymbol{N}(A)$ + $\boldsymbol{C}(A^\mathrm{T})$ (相互正交) 和在$\mathbb{R}^m$ 上的$\boldsymbol{N}(A^\mathrm{T})$ + $\boldsymbol{C}(A)$ (相互正交)。

* 3.5节 (p.124) Dimensions of the Four Subspaces

![四个子空间](https://gastigado.cnies.org/d/public/4-Subspaces.webp)
*图 5: 四个子空间*

关于秩$r$, 请见$A=CR$ (6.1节)。

## 4、矩阵乘以矩阵——4个视角

由`矩阵乘以向量"自然延伸到`矩阵乘以矩阵"。

* 1.4节 (p.35) Four ways to multiply $\boldsymbol{AB=C}$
* 也可以见书的封底

![矩阵乘以矩阵 - (MM1), (MM2), (MM3), (MM4)](https://gastigado.cnies.org/d/public/MatrixTimesMatrix.webp)

*图 6: 矩阵乘以矩阵 - (MM1), (MM2), (MM3), (MM4)*

## 5、实用模式

在这里, 我展示了一些实用的模式, 可以让你更直观地理解接下来的内容。

![图 1, 2 - (P1), (P1)](https://gastigado.cnies.org/d/public/Pattern12.webp)
*图 7: 图 1, 2 - (P1), (P1)*

P1 是 (MM2) 和 (Mv2) 的结合。P2 是 (MM3) 和 (vM2) 的扩展。注意, P1 是列运算 (右乘一个矩阵), 而 P2 是行运算 (左乘一个矩阵)。

![图 1′, 2′ - (P1′), (P2′)](https://gastigado.cnies.org/d/public/Pattern11-22.webp)
*图 8: 图 1′, 2′ - (P1′), (P2′)*

(P1′) 将对角线上的数乘以矩阵的列, 而 (P2′) 将对角线上的数乘以矩阵的行。两个分别为 (P1) 和 (P2) 的变体。

![图 3 - (P3)](https://gastigado.cnies.org/d/public/Pattern3.webp)
*图 9: 图 3 - (P3)*

当解决微分方程和递归方程时的也会出现这一模式:

* 6节 (p.201) Eigenvalues and Eigenvectors
* 6.4节 (p.243) Systems of Differential Equations

$$
\begin{aligned}
\frac{d \boldsymbol{u}(t) }{dt} &= A \boldsymbol{u}(t), \quad \boldsymbol{u}(0)=\boldsymbol{u}*0\\
\boldsymbol{u}*{n+1} &= A \boldsymbol{u}\_n, \quad \boldsymbol{u\_0} = \boldsymbol{u}\_0
\end{aligned}
$$

在两种问题中, 它的解都可以用$A$的特征值($\lambda\_1, \lambda\_2, \lambda\_3$)、特征向量$X=\begin{bmatrix} \boldsymbol{x}\_1 & \boldsymbol{x}\_2 & \boldsymbol{x}\_3 \end{bmatrix}$和系数$c=\begin{bmatrix} c\_1 & c\_2 & c\_3 \end{bmatrix}^\mathrm{T}$表示。其中$C$是以$X$为基底的初始值$\boldsymbol{u}(0)=\boldsymbol{u}\_0$的坐标。

$$
\boldsymbol{u}\_0 = c\_1 \boldsymbol{x}\_1 + c\_2 \boldsymbol{x}\_2 + c\_3 \boldsymbol{x}\_3
$$

$$
\boldsymbol{c} =
\begin{bmatrix}
c\_1\\
c\_2\\
c\_3
\end{bmatrix} = X^{-1} \boldsymbol{u}\_0
$$

以上两个问题的通解为:

$$
\begin{aligned}
\boldsymbol{u}(t) &= e^{At} \boldsymbol{u}\_0 = X e^{\Lambda t} X^{-1} \boldsymbol{u\_0} &= X e^{\Lambda t} \boldsymbol{c} &= c\_1 e^{\lambda\_1 t} \boldsymbol{x}\_1 + c\_2 e^{\lambda\_2 t} \boldsymbol{x}\_2 + c\_3 e^{\lambda\_3 t} \boldsymbol{x}\_3\\
\boldsymbol{u}\_n &= A^n \boldsymbol{u}\_0 = X \Lambda^n X^{-1} \boldsymbol{u\_0} &= X \Lambda^n \boldsymbol{c} &= c\_1 \lambda\_1^n \boldsymbol{x}\_1 + c\_2 \lambda\_2^n \boldsymbol{x}\_2 + c\_3 \lambda\_3^n \boldsymbol{x}\_3
\end{aligned}
$$

见图 9: 通过P3可以得到$XDc$​。

![Pattern 4 - (P4)](https://gastigado.cnies.org/d/public/Pattern4.webp)
*图 10: Pattern 4 - (P4)*

P4在特征值分解和特异值分解中都会用到。两种分解都可以表示为三个矩阵之积, 其中中间的矩阵均为对角矩阵。且都可以表示为带特征值/特异值系数的秩1矩阵之积。

更多细节将在下一节中讨论。

## 6、矩阵的五种分解

* 前言 p.vii, The Plan for the Book.

$A=CR, A=LU, A=QR, A=Q \Lambda Q^\mathrm{T}, A=U \Sigma V^\mathrm{T}$ 将一一说明。

| 分解                                       |                             图示                             | 说明                                                         |
| :----------------------------------------- | :----------------------------------------------------------: | :----------------------------------------------------------- |
| **$\boldsymbol{A=CR}$**                    |  | $C$为$A$的线性无关列$R$为$A$的行阶梯形矩阵可推知 列秩 = 行秩 |
| **$\boldsymbol{A=LU}$**                    |  | $LU$分解通过高斯消去法(下三角)(上三角)               |
| **$\boldsymbol{A=QR}$**                    |  | $QR$分解为格拉姆-施密特正交化中的正交矩阵$Q$和三角矩阵$R$ |
| **$\boldsymbol{S=Q\Lambda Q^\mathrm{T}}$** |  | 对称矩阵$S$可以进行特征值分解特征向量组成$Q$, 特征值组成$\Lambda$ |
| **$\boldsymbol{A=U\Sigma V^\mathrm{T}}$**  |  | 所有矩阵$A$的奇异值分解 奇异值组成$\Sigma$           |

*表 1: 五种分解*

### 6.1 $\boldsymbol{A=CR}$

* 1.4节 Matrix Multiplication and $\boldsymbol{A=CR}$ (p.29)

所有一般的长矩阵$A$都有相同的行秩和列秩。这个分解是理解这一定理最直观的方法。$C$由$A$的线性无关列组成, $R$为$A$的行阶梯形矩阵 (消除了零行)。$A=CR$将$A$化简为$r$的线性无关列$C$和线性无关行$R$的乘积。

$$
\begin{aligned}
A &= CR\\
\begin{bmatrix}
1 & 2 & 3 \\
2 & 3 & 5
\end{bmatrix}
& =
\begin{bmatrix}
1 & 2 \\
2 & 3
\end{bmatrix}
\begin{bmatrix}
1 & 0 & 1 \\
0 & 1 & 1
\end{bmatrix}
\end{aligned}
$$

推导过程: 从左往右看$A$的列. 保留其中线性无关的列, 去掉可以由前者线性表出的列。则第1、2列被保留, 而第三列因为可以由前两列之和表示而被去掉。而要通过线性无关的1、2两列重新构造出$A$, 需要右乘一个行阶梯矩阵$R$。

![CR中列的秩](https://gastigado.cnies.org/d/public/CR1.webp)

*图 11: CR中列的秩*

现在你会发现列的秩为2, 因为$C$中只有2个线性无关列。而$A$中所有的列都可以由$C$中的2列线性表出。

![CR中行的秩](https://gastigado.cnies.org/d/public/CR2.webp)

*图 12: CR中行的秩*

同样, 行秩也为2, 因为$R$中只有2个线性无关行, 且$A$中所有的行都可以由$R$中的2行线性表出。

### 6.2 $\boldsymbol{A=LU}$

用高斯消除法求解$A\boldsymbol{x}=\boldsymbol{b}$也被称为$LU$分解。通常, 是$A$左乘一个初等行变换矩阵($E$)来得到一个上三角矩阵$U$。

$$
\begin{aligned}
EA &= U\\
A &= E^{-1}U\\
\text{let} ; L = E^{-1}, \quad  A &= LU
\end{aligned}
$$

现在, 求解$A\boldsymbol{x}=\boldsymbol{b}$有2步: (1)求解$L\boldsymbol{c}=\boldsymbol{b}$, (2)代回$U\boldsymbol{x}=\boldsymbol{c}$。

* 2.3节 (p.57) Matrix Computations and $\boldsymbol{A=LU}$

在这里, 我们直接通过$A$计算$L$和$U$。

$$
A =
\begin{bmatrix}
|\\
\boldsymbol{l}\_1\\
|
\end{bmatrix}
\begin{bmatrix}
\-  \boldsymbol{u}^\*\_1  -
\end{bmatrix}

* \begin{bmatrix}
  0 & \begin{matrix} 0 & 0 \end{matrix}\\
  \begin{matrix} 0 \ 0 \end{matrix} & A\_2
  \end{bmatrix}
  \=
  \begin{bmatrix}
  |\\
  \boldsymbol{l}\_1\\
  |
  \end{bmatrix}
  \begin{bmatrix}
  \- \boldsymbol{u}^\*\_1 -
  \end{bmatrix}
*

\begin{bmatrix}
|\\
\boldsymbol{l}\_2\\
|
\end{bmatrix}
\begin{bmatrix}
\- \boldsymbol{u}^\*\_2  -
\end{bmatrix}

* \begin{bmatrix}
  0 & 0 & 0\\
  0 & 0 & 0 \\
  0 & 0 & A\_3
  \end{bmatrix} = LU
  $$

![A的递归秩1矩阵分离](https://gastigado.cnies.org/d/public/LU1.webp)

*图 13: $A$的递归秩1矩阵分离*

要计算$L$和$U$, 首先分离出由$A$的第一行和第一列组成的外积。余下的部分为$A\_2$。递归执行此操作, 将$A$分解为秩1矩阵之和。

![由LU重新构造A](https://gastigado.cnies.org/d/public/LU2.webp)

*图 14: 由$LU$重新构造$A$*

由$L$乘以$U$来重新构造$A$则相对简单。

### 6.3$\boldsymbol{A=QR}$

$A=QR$是在保持$\boldsymbol{C}(A) = \boldsymbol{C}(Q)$的条件下, 将$A$转化为正交矩阵$Q$。

* 4.4节 Orthogonal matrices and Gram-Schmidt (p.165)

在格拉姆-施密特正交化中, 首先, 单位化的$\boldsymbol{a}\_1$被用作$\boldsymbol{q}\_1$, 然后求出$\boldsymbol{a}\_2$与$\boldsymbol{q}\_1$正交所得到的$\boldsymbol{q}\_2$, 以此类推。

$$
\begin{aligned}
\boldsymbol{q}\_1 &= \boldsymbol{a}\_1/||\boldsymbol{a}\_1|| \\
\boldsymbol{q}\_2 &= \boldsymbol{a}\_2 - (\boldsymbol{q}\_1^\mathrm{T} \boldsymbol{a}\_2)\boldsymbol{q}\_1 , \quad \boldsymbol{q}\_2 = \boldsymbol{q}\_2/||\boldsymbol{q}\_2|| \\
\boldsymbol{q}\_3 &= \boldsymbol{a}\_3 - (\boldsymbol{q}\_1^\mathrm{T} \boldsymbol{a}\_3)\boldsymbol{q}\_1 - (\boldsymbol{q}\_2^\mathrm{T} \boldsymbol{a}\_3)\boldsymbol{q}\_2, \quad \boldsymbol{q}\_3 = \boldsymbol{q}\_3/||\boldsymbol{q}\_3||
\end{aligned}
$$

或者你也可以写作$r\_{ij} = \boldsymbol{q}\_i^\mathrm{T} \boldsymbol{a}\_j$:

$$
\begin{aligned}
\boldsymbol{a}*1 &= r*{11}\boldsymbol{q}\_1\\
\boldsymbol{a}*2 &= r*{12}\boldsymbol{q}*1 + r*{22} \boldsymbol{q}\_2\\
\boldsymbol{a}*3 &= r*{13}\boldsymbol{q}*1 + r*{23} \boldsymbol{q}*2 + r*{33} \boldsymbol{q}\_3
\end{aligned}
$$

原本的$A$就可以表示为$QR$: 正交矩阵乘以上三角矩阵。

$$
\begin{gathered}
A =
\begin{bmatrix}
| & | & |\\
\boldsymbol{q}*1 & \boldsymbol{q}*2 & \boldsymbol{q}*3\\
| & | & |
\end{bmatrix}
\begin{bmatrix}
r*{11} & r*{12} & r*{13}\\
& r\_{22} & r\_{23}\\
&        & r\_{33}
\end{bmatrix} = QR\\
\\
Q Q^\mathrm{T}=Q^\mathrm{T} Q = I
\end{gathered}
$$

![A=QR](https://gastigado.cnies.org/d/public/QR.webp)
*图 15: $A=QR$*

$A$的列向量就可以转化为一个正交集合: $Q$的列向量。$A$的每一个列向量都可以用$Q$和上三角矩阵$R$重新构造出。

图释可以回头看P1。

### 6.4 $\boldsymbol{S=Q \Lambda Q^\mathrm{T}}$

所有对称矩阵$S$都必须有实特征值和正交特征向量。特征值是$\Lambda$的对角元素, 特征向量在$Q$中。

* 6.3节 (p.227) Symmetric Positive Definite Matrices

$$
\begin{aligned}
S = Q \Lambda Q^\mathrm{T}
&= \begin{bmatrix}
| & | & |\\
\boldsymbol{q}\_1 & \boldsymbol{q}\_2 & \boldsymbol{q}\_3\\
| & | & |
\end{bmatrix}
\begin{bmatrix}
\lambda\_1 \\
& \lambda\_2 & \\
& & \lambda\_3
\end{bmatrix}
\begin{bmatrix}

* \boldsymbol{q}\_1^\mathrm{T} -\\
* \boldsymbol{q}\_2^\mathrm{T} -\\
* \boldsymbol{q}\_3^\mathrm{T} -
  \end{bmatrix}\\
  \\
  &=
  \lambda\_1 \begin{bmatrix}
  |\\
  \boldsymbol{q}\_1\\
  |
  \end{bmatrix}
  \begin{bmatrix}
  * \boldsymbol{q}\_1^\mathrm{T} -
    \end{bmatrix}

-

\lambda\_2 \begin{bmatrix}
|\\
\boldsymbol{q}\_2\\
|
\end{bmatrix}
\begin{bmatrix}

* \boldsymbol{q}\_2^\mathrm{T} -
  \end{bmatrix}

-

\lambda\_3 \begin{bmatrix}
|\\
\boldsymbol{q}\_3 \\
|
\end{bmatrix}
\begin{bmatrix}
\- \boldsymbol{q}\_3^\mathrm{T} -
\end{bmatrix} \\
&= \lambda\_1 P\_1 + \lambda\_2 P\_2 + \lambda\_3 P\_3
\end{aligned}
$$

$$
P\_1=\boldsymbol{q}\_1 \boldsymbol{q}\_1^\mathrm{T}, \quad P\_2=\boldsymbol{q}\_2 \boldsymbol{q}\_2^\mathrm{T}, \quad P\_3=\boldsymbol{q}\_3 \boldsymbol{q}\_3^\mathrm{T}
$$

![S=Q Λ Qᵀ](https://gastigado.cnies.org/d/public/EVD.webp)
*图 16: $S=Q \Lambda Q^\mathrm{T}$*

一个对称矩阵$S$通过一个正交矩阵$Q$和它的转置矩阵, 对角化为$\Lambda$。然后被分解为秩一投影矩阵$P=qq^\mathrm{T}$的组合。这就是谱定理。

注意, 这里的分解用到了P4。

$$
\begin{gathered}
S=S^\mathrm{T} = \lambda\_1 P\_1 + \lambda\_2 P\_2 + \lambda\_3 P\_3\\
QQ^\mathrm{T} = P\_1 + P\_2 + P\_3 = I \\
P\_1 P\_2 = P\_2 P\_3 = P\_3 P\_1 = O\\
P\_1^2 =P\_1=P\_1^\mathrm{T}, \quad P\_2^2=P\_2=P\_2^\mathrm{T}, \quad P\_3^2=P\_3=P\_3^\mathrm{T}
\end{gathered}
$$

### 6.5 $\boldsymbol{A=U \Sigma V^\mathrm{T}}$

* 7.1节 (p.259) Singular Values and Singular Vecrtors

包括长方阵在内的所有矩阵都具有奇异值分解(SVD)。$A=U \Sigma V^\mathrm{T}$中, 有$A$的奇异向量$U$和$V$。奇异值则排列在$\Sigma$的对角线上。下图就是“简化版”的SVD。

![A=U Σ Vᵀ](https://gastigado.cnies.org/d/public/SVD.webp)

*图 17: $A=U \Sigma V^\mathrm{T}$*

你可以发现, $V$是$\mathbb{R}^n$ ($A^\mathrm{T} A$的特征向量) 的标准正交基, 而$U$是 $\mathbb{R}^m$ ($AA^\mathrm{T}$的特征向量) 的标准正交基。它们共同将$A$对角化为$\Sigma$。这也可以表示为秩1矩阵的线性组合。

$$
\begin{aligned}
A = U \Sigma V^\mathrm{T} &=
\begin{bmatrix}
| & | & |\\
\boldsymbol{u}\_1 & \boldsymbol{u}\_2 & \boldsymbol{u}\_3\\
| & | & |
\end{bmatrix}
\begin{bmatrix}
\sigma\_1 \\
& \sigma\_2 \\
& &
\end{bmatrix}
\begin{bmatrix}

* \boldsymbol{v}\_1^\mathrm{T} -\\
* \boldsymbol{v}\_2^\mathrm{T} -
  \end{bmatrix}
  & =
  \sigma\_1 \begin{bmatrix}
  |\\
  \boldsymbol{u}\_1\\
  |
  \end{bmatrix}
  \begin{bmatrix}
  * \boldsymbol{v}\_1^\mathrm{T} -
    \end{bmatrix}

-

\sigma\_2 \begin{bmatrix}
|\\
\boldsymbol{u}\_2\\
|
\end{bmatrix}
\begin{bmatrix}

* \boldsymbol{v}\_2^\mathrm{T} -
  \end{bmatrix} \\
  & = \sigma\_1 \boldsymbol{u}\_1 \boldsymbol{v}\_1^\mathrm{T} + \sigma\_2 \boldsymbol{u}\_2 \boldsymbol{v}\_2^\mathrm{T}
  \end{aligned}
  $$

注意:

$$
\begin{aligned}
U U^\mathrm{T} &= I\_m \\
V V^\mathrm{T} &= I\_n
\end{aligned}
$$

图释见P4。

## 总结和致谢

我展示了矩阵/向量乘法的系统可视化与它们在五种矩阵分解中的应用。我希望你能够喜欢它们、通过它们加深对线性代数的理解。

Ashley Fernandes 在排版时帮我美化了这篇论文, 使它更加一致和专业。

在结束这篇论文之前, 我要感谢 Gilbert Strang 教授出版了《Linear Algebra for Everyone》一书。它引导我们通过新的视角去了解线性代数中这些美丽的风景。其中介绍了当代和传统的数据科学和机器学习, 每个人都可以通过实用的方式对它的基本思想进行基本理解。 矩阵世界的重要组成部分。

## 参考文献与相关工作

1. Gilbert Strang(2020), *Linear Algebra for Everyone*, Wellesley Cambridge Press.,<http://math.mit.edu/everyone>
2. Gilbert Strang(2016), *Introduction to Linear Algebra*, Wellesley Cambridge Press, 5th ed.,<http://math.mit.edu/linearalgebra>
3. Kenji Hiranabe(2021), *Map of Eigenvalues*, An Agile Way(blog),<https://anagileway.com/2021/10/01/map-of-eigenvalues/>
   ![特征值图](https://gastigado.cnies.org/d/public/MapofEigenvalues-zh-CN.webp)
   *图 18: 特征值图*
4. Kenji Hiranabe(2020), *Matrix World*, An Agile Way(blog),\\
   <https://anagileway.com/2020/09/29/matrix-world-in-linear-algebra-for-everyone/>
   ![矩阵世界](https://gastigado.cnies.org/d/public/MatrixWorld-zh-CN.webp)
   *图 19: 矩阵世界*

***

\[^author1]: twitter: @hiranabe, k-hiranabe@esm.co.jp, <https://anagileway.com>
\[^author2]: Massachusetts Institute of Technology, <http://www-math.mit.edu/~gs/>
\[^author3]: twitter: [@kfchliu](https://twitter.com/KFChLiu), 微博用户: [5717297833](https://weibo.com/u/5717297833)
\[^footnote1]: “Linear Algebra for Everyone": <http://math.mit.edu/everyone/>.

---

---
url: https://ain.hmgf.hxcn.space/career.md
description: 大学生求职与职业发展指南，包括简历优化与面试技巧。
---

# Career 求职指南

---

---
url: https://ain.hmgf.hxcn.space/career/college-student-resume-guide.md
description: 面向大学生的简历写作实战指南，重点讲清技能栏、项目经历、常见避坑点与作品链接展示方式，帮助你把简历写得具体、可验证、能让面试官快速判断你是否能干活。
---

# 别让无效简历浪费你的机会！大学生简历避坑与正确写法指南

大一大二不会写简历太正常了，但很多同学的简历，要么通篇都是 AI 生成的空话套话，要么技能写得极其笼统，面试官根本抓不到重点，最后要么面试被问得哑口无言，要么连初筛都过不了。

作为筛过几百份简历、面过几十位同学的过来人，这篇文章只讲一个核心原则：

**简历是用来证明你“能干活”，不是证明你“听说过”；所有内容都要具体、落地、可验证。**

## 一、技能栏：别再写“会剪辑”“学过 Python”这种无效表述

很多大学生简历翻车，问题就出在技能栏。面试官想知道的不是你“接触过什么”，而是你“能拿它做什么”。

### 1. 剪辑与设计类技能

反面写法：

* 会视频剪辑
* 熟练使用设计软件

正确写法应使用这个结构：

**软件 + 核心能力 + 落地案例**

示例：

* 熟练使用 PR、AE、剪映，可独立完成视频剪辑、字幕制作、转场特效、基础调色与音频处理；曾为社团活动制作 4 条宣传视频，单条最高校内播放量 6000+。
* 掌握 PS 基础操作，可独立完成海报、宣传单页设计，并为活动完成线上线下宣传物料制作。

### 2. 编程与开发类技能

反面写法：

* 学过 Python
* 有编程基础

正确写法应使用这个结构：

**语言/工具 + 掌握范围 + 熟练程度 + 项目或作品**

示例：

* 掌握 Python 基础语法与常用数据结构，熟悉 Pandas、NumPy 数据处理库和 Matplotlib 可视化工具，能独立完成数据清洗、分析与可视化输出；曾在课程项目中完成电商用户行为分析并提交完整分析报告。
* 了解 C 语言基础语法，可完成简单的流程控制、数组和函数相关代码编写。

这里有个常见误区：不要乱写“精通”。大学生阶段把“了解”“熟悉”“掌握”分清楚，比虚高描述更重要。面试里被追问两轮就露馅的夸大，基本只会减分。

### 3. 建模与工程类技能

反面写法：

* 有建模基础
* 会三维建模

正确写法应使用这个结构：

**软件 + 核心能力 + 具体应用场景**

示例：

* 掌握 SolidWorks 基础建模，可独立完成零件建模、装配体设计与工程图输出；曾完成减速器建模课程设计，获课程优秀评级。
* 了解 CAD 基础绘图，可完成简单二维图纸绘制与标注。

## 二、经历与项目栏：别写流水账，要写你做了什么、产生了什么结果

很多同学写经历时只会写“参与 XX 活动”“负责 XX 工作”，这种表述几乎没有信息量。面试官真正想看到的是：

* 你做了什么具体动作
* 你用了什么技能
* 你最后拿到了什么结果

最实用的表达公式是：

**具体动作 + 技能支撑 + 可量化结果**

反面写法：

* 参与社团招新活动，负责宣传工作，锻炼了沟通能力和团队协作能力。

正确写法：

* 参与社团秋季招新全流程，负责宣传物料设计与线上推广，使用 PS 制作 3 版招新海报、使用 PR 制作 2 条宣传短视频，并同步运营社团小红书账号发布招新内容，最终助力本次招新报名人数同比提升 35%。

注意，像“锻炼了沟通能力”“提升了团队协作能力”这种空话，没案例支撑时可以直接删掉。课程作业、课程设计、社团任务、个人练手作品，甚至是跟着教程完整做下来的练习，只要能体现你的能力落地，都可以写进简历。

## 三、90% 的人都会踩的简历坑

### 1. 拒绝 AI 生成的空话套话

像下面这类表达，如果没有事实支撑，建议全部删除：

* 具有较强的学习能力
* 具有良好的团队协作能力
* 具备高度责任心

这些内容不会帮你过筛，只会占空间。简历不是自我感动，也不是写作文，任何一句话都应该能被项目、作品或经历证明。

### 2. 简历不是越长越好，1 页通常就够

大学生简历最常见的问题之一就是内容不够硬，却写了两三页。实际筛选时，面试官看一份简历往往只有十几秒。与其堆流水账，不如在 1 页内把最核心的技能、经历和作品说明白。

### 3. 只写和目标岗位强相关的内容

如果你投的是技术岗，就重点写编程、建模、硬件、项目开发相关内容；如果你投的是新媒体岗，就重点写剪辑、文案、运营、数据复盘相关内容。无关内容写得越多，越像在分散注意力。

### 4. 没有“大项目”也不要硬凑，更不要空白

大一大二没有实习、没有大型项目非常正常，不用焦虑。课程设计、结课作业、社团小任务、自己做过的完整练习，都比空着不写或者硬编经历强。大学生阶段，简历的重点不是“有多厉害”，而是“你已经具备了哪些可以继续培养的能力”。

## 四、真正能拉开差距的加分项

### 1. 一定要附作品链接

文字描述再多，都不如直接给出证据：

* 剪辑作品可附 B 站或网盘链接
* 设计作品可附站酷、作品集或云盘链接
* 编程项目可附 GitHub、Gitee 仓库链接
* 报告类成果可附 PDF 或在线文档链接

你写“我会”，面试官未必信；你把作品放出来，面试官一眼就能判断水平。

### 2. 提前替面试官划重点，减少无效沟通

当你在简历里写清楚技能掌握范围、项目内容和实际结果后，面试官通常会围绕这些内容提问。这样既能减少泛泛而谈的低效问答，也能让你更容易把面试节奏拉回自己熟悉的内容上。

## 五、一个适合大学生的自查清单

投递前，可以用下面这份清单快速过一遍：

* 技能栏有没有写清楚“会什么”以及“能做什么”？
* 每段经历里有没有体现具体动作、工具和结果？
* 有没有删掉没有案例支撑的空话套话？
* 有没有保留和目标岗位无关的冗余内容？
* 有没有附上作品链接或项目链接？
* 整份简历能不能控制在 1 页内快速看完？

## 结语

简历的本质，是给面试官一个快速判断你是否能上手做事的入口。你写得越具体、越诚实、越可验证，对方越容易判断你是不是合适的人。

不需要华丽辞藻，也不需要复杂模板。对大学生来说，一份真正有效的简历，核心就是三件事：**内容具体、能力落地、证据充分。**

---

---
url: https://ain.hmgf.hxcn.space/career/openai-job-search-experience.md
description: Alisa Liu 分享的 AI/ML 求职经验，包括面试准备、技术面试类型、谈判技巧等，以及推荐的学习资源。
---

# 加入 OpenAI 的求职经验分享

## 背景介绍

Alisa Liu 是华盛顿大学 NLP 博士生，OpenAI SuperAlignment Fellowship 得主，在博士最后一年成功加入 OpenAI。她在博客中详细分享了整个求职过程，包括 46 场 recruiter screen 和 11 家顶级 AI lab 的面试经历。

## 推荐学习资源

### 核心课程

* **斯坦福 CS336：从零开始的语言建模**：[cs336.stanford.edu/spring2025/](https://cs336.stanford.edu/spring2025/)
* **LeetCode 75**：[leetcode.com/studyplan/leetcode-75/](https://leetcode.com/studyplan/leetcode-75/)
* **Neetcode Blind 75**：[neetcode.io/practice/practice/blind75](https://neetcode.io/practice/practice/blind75)

### 笔记与教程

* **LLM 笔记**：[alisawuffles.notion.site/alisa-s-book-of-llms](https://alisawuffles.notion.site/alisa-s-book-of-llms)
* **数学笔记**：[alisawuffles.notion.site/math-notes](https://alisawuffles.notion.site/math-notes)

### 技术文章

* **自注意力 & Transformer**：[web.stanford.edu/class/cs224n/readings/cs224n-self-attention-transformers-2023\_draft.pdf](https://web.stanford.edu/class/cs224n/readings/cs224n-self-attention-transformers-2023_draft.pdf)
* **插图版 GPT-2**：[jalammar.github.io/illustrated-gpt2/](https://jalammar.github.io/illustrated-gpt2/)
* **反向传播**：[cs231n.github.io/optimization-2/](https://cs231n.github.io/optimization-2/)
* **语言模型策略梯度入门**：[ivison.id.au/2026/02/09/policy-gradient.html](https://ivison.id.au/2026/02/09/policy-gradient.html)
* **理解 GRPO 和强化学习原理的轻量级指南**：[gitlostmurali.com/blog/grpo-intro](https://gitlostmurali.com/blog/grpo-intro)
* **如何扩展你的模型**：[jax-ml.github.io/scaling-book/](https://jax-ml.github.io/scaling-book/)

### 实践项目

* **Transformer 实现**：[stanford-cs336/assignment1-basics](https://github.com/stanford-cs336/assignment1-basics)

***

## 原文翻译：关于行业求职的笔记

以下是对 Alisa Liu 原文 [Notes on the Industry Job Search](https://alisawuffles.github.io/blog/job-search/) 的完整翻译。

### 我的时间线

下图展示了我求职时间线（灵感来自 Nathan Lambert 的文章），其中灰色图标表示面试，彩色圆圈表示结果。注意，**"被忽略"** 意味着 recruiter 从未告知我结果或后续步骤，**"撤回"** 意味着在我收到一些感兴趣的 offer 后，礼貌地告诉公司我不再感兴趣。总共我在 11 家公司进行了 57 场面试。图中未显示的是另外 46 场 recruiter 电话和 16 场 offer 后的聊天，以及在求职前进行的无数次非正式社交对话。

**公司顺序**。我决定何时开始每个面试流程，综合考虑了我是否准备好了、公司的压力、我预期他们推进的速度、我对他们的兴趣程度，以及一些不太刻意的因素（比如拖延）。这里的普遍智慧是先用几家公司练习，然后安排其他流程的时间，使得所有 offer 大约在同一时间收到，以便进行谈判。虽然我认为这在精神上大致正确，但我想补充几点考虑：

* 练习面试很有帮助，但也要认识到你的精力是有限的——小心不要在你真正关心的公司面试时已经精疲力尽！
* 有一些外部因素值得考虑，比如公司是否有 headcount 以及哪些团队正在积极招聘，这可能比你的准备更重要。你可以通过朋友和 recruiter 了解一些情况。
* 截止日期有很大的灵活性，所以 offer 的时间安排不需要非常精确。recruiter 认识到你有其他流程要完成，有各种技巧可以延迟 offer 和决定。话虽如此，有一些臭名昭著的例外（所谓的"爆炸性" offer），所以调查候选人通常有多少时间签约是很重要的。

**获得第一次面试**。显而易见的是：在博士期间努力做好工作，交朋友，多合作！为了获得第一次面试，有时你需要公司内部有人为你担保。你可以通过在会议上社交、广泛合作和参加社交活动来为成功奠定基础（当然这部分对每个人来说都不容易——对我来说 certainly 不是——所以也要照顾好自己的精力和舒适度）。在求职期间，联系你认识（或不认识）的人，询问机会。事实上，求职的很大一部分是与你可能多年没有联系的人重新建立联系——这是可以的，预期的，而且 turns out 是这个过程的一个美妙副作用。

### 面试类型

我想说大致有以下几类面试。总的来说，技术技能和知识的评估远多于研究经验，尽管后者可能让你获得面试机会。

**ML 编码**。这是迄今为止最常见的。这些问题可能要求你实现一个给定的架构、解码策略、传统 ML 算法，或者有时更创意的东西。熟练掌握 `PyTorch` 是必须的；在少数情况下，我被要求只使用 `numpy`，例如从头开始编写反向传播，但我不需要熟悉 `numpy` 语法。

**通用编码**。基本上是 LeetCode，有时带有一些额外的变化。在这里建立扎实的基础是很好的，因为这些概念经常出现在 ML 编码面试中。

**技术讨论**。这些面试不涉及编码，但非常技术性。有时，面试是围绕一个主题的 extended 讨论，比如你如何设计实验来回答特定的研究问题或实现特定的目标。面试官通常会 press 你 on 你的设计选择，并要求你评论一些假设结果并设计后续实验。在其他情况下，面试由一系列快速问题组成（*什么是编码位置信息的不同方式？什么是 5D 并行？PPO 和 GRPO 有什么区别？*），目标是表明我了解我的东西。前一种面试测试你如何思考，而后一种检查你对该领域知识的广度。

**研究讨论**。这些是我们在博士期间练习最多的对话类型。面试官通常要求你先告诉他们一个过去的项目，其余的讨论从那里展开。他们也可能问你简历上其他论文的问题。在准备这类讨论时，退一步思考你为什么选择做你做的事情，你在过程中 develop 的见解和观点，以及你认为有前途的未来方向是很有用的。我还根据角色调整了我的研究 pitch；面试官很累，所以命中正确的关键词让他们更容易相信你的 profile 是相关的。

**行为面试**。这些完全是教科书式的行为面试， apart from 偶尔有关于 AI 安全或社会影响的问题。列举你博士期间难忘的故事，并将它们映射到常见行为问题上，这样在面试中，你可以 instantly 检索到正确的轶事。我的第一次行为面试失败了，因为我进去时想我 obviously 很"行为良好"，结果在 excruciatingly 简单的问题上一片空白。相信我，在面试中同时试图 reconstruct 模糊记忆并 delivering 它们是 uniquely 痛苦的，结果面试官最后说，"你没有回答这个问题。"

**数学**。有些公司有数学面试，范围从有趣的逻辑谜题到用笔和纸的 serious 数学推导。我建议复习概率、线性代数和微积分。

**Job talk**。Job talk 的形式有一些变化，但与学术 talk 相比，它 tend to be 更短并专注于一篇论文或方向。我的 job talk 全是关于 tokenizer；我大部分时间花在第一作者工作上，然后 briefly 涵盖了几篇第二作者和进行中的工作，fortunately 它们 ties together 非常好。

### 准备

没有比为面试学习更好的时间利用方式了。对我来说，这种体验 very much like 回到本科：我做笔记（见我的 [LLM 笔记](https://alisawuffles.notion.site/alisa-s-book-of-llms)，我在整个过程中持续工作，以及我的 \[数学笔记]\(https://alisawuffles.notion.site/math-notes），这全是为了一个命运攸关的面试），画图表，做练习题， entire days 在咖啡馆里确保我 inside-and-out 理解基本 ML 概念。技术面试很难，所测试的技能需要 dedicated effort 在研究之外发展。对我来说和大多数我交谈过的人，求职是一份全职工作。

我通过观看斯坦福大学[从零开始的语言建模](https://cs336.stanford.edu/spring2025/)课程的所有讲座开始了我的过程，这对于说明我需要学习的主题广度很有帮助，并帮助我将大脑中 scattered 的概念组织成一个连贯的领域图景。在 covering 基础之后，我其余的时间花在一次深入一个概念上，通过阅读相关博客文章和论文，与 ChatGPT 和 Claude *大量* 交谈，以及练习从头实现东西。[作业 1](https://github.com/stanford-cs336/assignment1-basics) 至关重要：实现/调试一个 transformer 在面试中出现如此频繁，以至于将其转化为肌肉记忆将 massive 回报，而且真的不值得 losing points on。确保你在练习编码时完全关闭 AI assistance 以模拟面试环境（否则你会低估你的依赖）！

我发现每次面试都是 unique 的，并且可以从一点点——有时很多——dedicated 准备中受益。你通常可以从提供的描述、公司感兴趣的主题、recruiter 的提示和公司的声誉中建立对面试范围的 intuitive 理解。当我 deep in 面试时，我发现我 constantly swapping 信息进出大脑，以便特定面试的 most relevant 知识是新鲜的。我能描述它的最佳方式是：每次面试都是 slightly different 数学或 CS 课，你从未去上过课，现在你有大约 3 天时间 cram 期中考试。

**面试当天**。也许是因为我 getting old，但没有什么比面试前一晚获得足够睡眠更重要的了。我在第一次技术面试时犯了错误，在 cramming LLM 推理的所有 intricacies 到大脑后只睡了 2 小时——没有 last-minute 知识出现，结果我花 10 分钟在一个 off-by-one 错误上，因为我的齿轮 barely turning。面试后，记住记录一些笔记，这将对你未来的学习和反思有帮助。

**附带好处**。学习给我带来了巨大的附带好处。更广的知识面直接提升了我作为研究者的信心。我在对话中变得更 secure，因为我不太担心知识 gaps 被暴露，当它们出现时也不再 felt compelled 隐藏它们。我 truly 相信，如果我在博士早期就做了这些学习，它会扩展我可能 able to 思考的问题和想法的空间， certainly 也会增加我会 sought out 的对话数量。Amazingly，我还发现学习让我在 ongoing 项目中 enormously 更有效。我能够拥有以前 never would have been able to access 的技术想法并做更多技术工作，这是 thrilling。

### 谈判

我 shocked to learn 在你收到 offer 后工作远未完成。相反，有一段（可能 extended 的）时间让你了解你的选择并谈判你的 offer。它涉及与潜在未来队友/经理的许多对话、午餐访问和 recruiter 电话。在这个阶段，我 managing overwhelming 的沟通量，总是有我 guilty of 没有回复的邮件。

事实是谈判很难。我们的博士没有为这个做准备，而且与面试不同，这部分不能通过学习来 conquer。与 recruiter 相比，你在市场知识和谈判技巧方面都 outmatched，而且每个与你交谈的人都想从你这里得到不同的东西。你可能在想，"我会对我的 offer 满意并独立于薪酬做决定！"，确实知道你自己的价值观是 great！但如果你不谈判，你就是在 disservice 自己。初始 offer 留有谈判空间 by design；recruiter often explicitly 邀请我玩游戏，说这样的话，"我不期望你接受我们的第一个 offer。"在这里投入精力几周，literally，可以等同于初始 offer 的几年工作。

在这个阶段依靠你的朋友获取与 recruiter 互动的 know-how 以及更多数据点来帮助校准你的要求是 really crucial 的。每次 recruiter 电话前，我写下我愿意和不愿意分享的内容，以及我可以 verbatim 背诵的引述。在 offer 后阶段，我会 anticipate 他们可能问的问题和提出的观点，并 carefully construct 我可以 comfortably 交付同时 still advocating for myself 的回应。虽然耗时，但对过程的每个方面 deliberate 是 really worthwhile 的。

### 结语

在这篇博客文章中，我专注于求职的具体部分，但实际上我个人经历的很大一部分是 managing 伴随市场上所有的情绪。有很多社会感知需要 navigate：将自己与 peers 比较不是 good feeling，每个人对你应该或不应该去哪里都有意见，人们变得 unusually invested 你的生活如何。我还发现 stressful navigating 一个巨大的决策空间，信息 incomplete，小选择没有对错答案（比如何时联系谁）却有 outsized 影响。Frankly，我 stressed，miserable，并且在生活的其他方面 not functioning 几个月。Hopefully 你找到更多快乐，但如果 not，just know 你并不孤单。

我 months 来一直 hurrying towards 博士的结束，现在在这一切的 end，我 immensely sad 离开我生命的这一章。博士是 such 特殊的时间，我们唯一的工作是拥有好的想法并执行它们，作为研究者学习和成长，*without* 担心 imminently securing 真正的工作。所以虽然我希望这篇文章帮助你 mentally 为未来做准备（我 certainly recognize 今天行业力量有多 distracting），我也希望你能珍惜博士的独特时间。这些目标可能是 complementary 的，毕竟——我 consistently 发现当我 having fun 并追逐我的 mind 不会 laid to rest 的问题时，我做了最好的工作。

***

## 参考链接

* 原文：[Notes on the Industry Job Search](https://alisawuffles.github.io/blog/job-search/)
* Alisa Liu 的 LLM 笔记：[alisawuffles.notion.site/alisa-s-book-of-llms](https://alisawuffles.notion.site/alisa-s-book-of-llms)
* Alisa Liu 的数学笔记：[alisawuffles.notion.site/math-notes](https://alisawuffles.notion.site/math-notes)

---

---
url: https://ain.hmgf.hxcn.space/event.md
description: 编程竞赛组各类活动与纳新考核信息汇总。
---

# 活动中心

---

---
url: https://ain.hmgf.hxcn.space/event/lesson0-2025.md
description: 编程竞赛组第0节课导学内容，包含大学阶段学习方法、目标规划与提问建议。
---

# 从蒟蒻到大佬的第一步

刚刚结束高中三年生活的你们，踏入大学，是不是对一切都感到懵懵懂懂的？(・∀・) 今天这篇文章将为你的大学生活提供一些实用的建议，并为你开启学习之路打好基础。话不多说，我们开始了哦！

## 篇章一：内功心法篇

### 转变思维 (•̀ω•́)✧

思维是决定你前进与选择方向的。如果我们还停留在高中的“保姆式”思维，直接挪用到大学，那可要出大麻烦啦 ( > < )。

在大学，我们超级自由，课后时间非常充沛。没有人会天天督促你学习，在寝室打游戏睡觉也好，在自习室研究技术也好，时间完全由你自由分配。

但这也很“麻烦”... 很多同学会经历一段迷茫期 (´･\_･\`)。因为相比高中，我们突然没有了一个明确的目标。我们可能正在接受思维转变的“阵痛”，这一点非常正常。与初高中的“他律”相比，大学拼的就是“自律”！

所以，我们必须**制定一个明确的目标**，短期的（比如这学期学会 Linux）或长期的（比如进大厂）都行。我们还得培养自己独特的**自学能力**，在技术这条路上，想完全依靠老师是行不通的哦。

### 如何查找自己的“攻略” ＼(ﾟ∀ﾟ)／

我们很多人都容易困在“信息茧房”里。进入大学这个陌生环境，无论是评奖学金的条件，还是企业的招聘信息，学校很少会手把手喂给你。所以，我们必须学会**扩充自己的信息源**。以下是搜索资源、解决问题的依次顺序：

1. 分析自己的代码：如果自己能解决，这个成就感是无与伦比的
2. 看官方文档：一个技术人学到最顶尖时，一定是靠官方文档学习的。官方文档和论坛记录了海量的 Bug 解决方式，这才是“一手资料”！
3. 学会使用 Google、Edge：这两款搜索引擎，界面相对清爽，广告也少 (尤其是 Google)，搜出来的有效信息更多。学会使用搜索引擎是一门大学问，用得好堪称神器！
   ![](https://gastigado.cnies.org/d/others/image-20251023114315236.png)
4. 询问 AI：现在市面上好用的 AI 大模型超多，比如 Deepseek，豆包，GLM（国产模型代码最强）以及国外的 ChatGPT、Gemini等 (oﾟ▽ﾟ)o。AI 更喜欢“吃”文本。就像我们运维有时候遇到了错误日志，不知道咋办，你可以把日志截图喂给 AI，也可以把日志以文本形式投喂给 AI。不用想，当然是第二种（文本）的效果明显更好啦！
5. 问师哥师姐：师哥师姐们其实很乐意回答小登们的问题 (〃∀〃)，但是大家的时间也都很宝贵，所以... (请看下一条)。

### 提问的智慧 ( T\_T ) (非常重要！)

#### 什么是提问的智慧

如何提问，也是一门大学问。详见[这个文档](https://lug.ustc.edu.cn/wiki/doc/smart-questions/)🙏

你们或许在提问题的时候，觉得我们（师哥师姐）很傲慢？

**你以为的傲慢：**

* 师弟：师哥我 VSCode 装不上了怎么办？
* 师哥：(心里MMP) ...你到官网下载安装包，下载完双击它，一直点下一步就安装好了。
* 师弟：官网是什么？
* 师哥：`https://code.visualstudio.com/`
* 师弟：下载按钮在哪？
* 师哥：(截图.jpg)
* 师弟：好了，下载到了，然后呢？哎对了师哥，我这怎么解压还要钱啊，能免费解压吗？
* 师哥：...这个都不会还是别学了。
* 师弟：(感觉师哥很傲慢) ...

**实际上的的“傲慢”：**

* 师弟：(提供了完美提问) 师哥我的电脑是 64 位的 Windows 10，我在 VSCode 官网下载了对应版本，但在安装过程中出现了这个问题（贴图），我使用百度搜索后还是没有办法解决，你能帮我看看吗？谢谢！(〃'▽'〃)
* 师哥：这个都不会还是别学了。
* *(这种情况才是真的傲慢，但 99% 的情况不是这样的！)*

**我们为什么会对某些问题感到厌烦？ (；¬＿¬)**

1. 提的问题“过于简单”（比如“官网在哪”，这明显是自己一搜便知）。
2. 提问题的方式不对（见下文）。
3. 遇到问题**想都不想**就提问（没有展示自己尝试解决的过程）。

#### 到底该怎么问问题？ (o´ω\`o)ﾉ

##### 1. 精确地描述问题并言之有物：

话不在多，在于精。清楚明确地表达你的需求。这并不是要求你简单的就把成堆的错误代码或者资料完全放在你的提问中，如果你的问题是一个很大的是程序挂掉的这样一个代码运行环境，尽量把它剪裁得越小越好。

这样做的好处至少有三点：

* 第一，表现你为简化问题付出了努力，这可以使你得到回答问题的概率增加
* 第二，简化问题使你更有可能得到有用的答案
* 第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或者权宜之计

最有可能最有能力给你有用答案的人通常也是最忙的人（他们忙是因为要亲自完成大部分工作）。所以我们对这样无休止无节制的时间黑洞是相当厌恶的。

所以，请界定一下你的问题，使我们花在辨识你的问题和回答所需要付出的时间减到最少。

##### 2. 询问有关代码的问题时：

* **算法**：先去看题解（因为师哥师姐也可能没做过这道题或者这种类型的题），题解能帮你们解决问题。如果实在是看不懂题解，请移步至AI，AI有时候甚至讲的比我们还要清晰。如果都没看明白，再请将原题，你的代码和题解一并发给师哥师姐们，并指出你对哪一块地方不太懂。
* **项目作业问题**：如果是代码出现了报错，请学会自己定位问题，现在的开发软件很智能，会告诉你你的代码错在哪个文件的哪一行。你们可以通过报错去找出问题，如果看不懂，不要直接把问题发给AI，先尝试自己通过翻译软件得知报错问题（我们希望你们能够培养出自己解决问题的能力，不要过度依赖AI）。如果实在解决不了，再尝试交给AI。最后再来询问师哥师姐们，并且将你出现错误的代码和debug（即终端报错）一并发给师哥师姐们。
* **配置安装问题**：在开发中我们可能会安装很多外有库，如果在安装对应的外有库出现了问题，先去查阅外有库的官方文档，上面一般会统计常见的问题。如果无法解决，请善用搜索引擎，将你的问题在搜索引擎中输入，很大可能别人也出现了相同的问题，你就可以按照他们的方法去解决。（CSDN、稀土掘金、博客网、一些牛人的个人博客等等都可能可以帮你解决）。如果都不行再尝试去询问AI或师哥师姐们

千万不要动辄就要求别人帮你去调试有问题的代码，而且也不提示一下应该从何入手。相当于：你玩游戏迷路，直接让师哥师姐上手帮你做跑图这种重复且无趣的工作

张贴几百行的代码，然后说一声：`这段代码有问题`，我们可能完全会忽略这样的问题，而且回都不想回

相比于这个，只贴几十行的代码，然后说一句：`在第七行代码之后，我觉得程序会输出xxx，但实际出现的xxx`更有可能让你得到回应

最有效描述程序代码问题的方法就是提供一段最精简的 Bug 展示的测试用例。

什么是最精简的测试用例？那是问题的缩影；如果你知道哪一行或者哪一段代码会造成异常的行为，复制下来并且加入能够重现这个状况的代码（能让这段异常的代码正常运行）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，你发出的测试用例（或代码）越少越好。

##### 3. 如何问师哥师姐们问题？

1. 请不要在吗起手，有问题直接问，师哥师姐们看到就会回复，你一个在吗起手，师哥师姐忙的时候可能不会去搭理这种问题。
2. 不要手机拍照！不要手机拍照！不要手机拍照！ (重要的事情说三遍)
3. 请截图！ (清晰地)
4. 或者直接贴代码块和错误日志 (文本形式)！

![04](https://gastigado.cnies.org/d/others/04.jpg)

5. 那我们该如何正确截屏呢？这里推荐快捷键截图：
   * QQ（Ctrl + Alt + A）
   * 微信（Alt + A）
   * Windows系统自带的截图（键盘上的Print键）或者使用快捷键（Win + Shift + S）
   * Pixpin等第三方截图工具
   * 更多截图方式请看这个视频：【电脑不会截图？我教你啊！】 https://www.bilibili.com/video/BV1ZyFzzREga/
   * 截图后将你的问题和截图一起发送，然后请耐心等待师哥师姐有空的时候给你们解决。

6. 在提问前最好先尝试看官方文档和使用搜索引擎查找，否则可能会收到 RTFM 和 STFW 两个回复

> 有一个古老而神圣的传统：如果你收到`RTFM（Read The Fucking Manual）`的回应，回答者认为你**应该去读他妈的手册**。当然，基本上他是对的，你应该去读一读。
>
> RTFM 有一个年轻的亲戚。如果你收到`STFW（Search The Fucking Web）`的回应，回答者认为你**应该到他妈的网上搜索**。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 **Google 是你的朋友**！）
>
> 当然师哥师姐们没这么恐怖😱

当然，对于很多问题大家都是 0 基础，问很正常，大家不要怕 (･ω<)☆。师哥师姐们都很乐意与小登打好关系，希望大家在学习过程中可以和“老登们”亦师亦友！

### 最后的 Bonus：了解行业/科研需求

另外，建议大家手机里下载一个“BOSS 直聘”之类的招聘软件或者搜索研招网。别急着找工作或者刷绩点，而是去**看一看**，你感兴趣的岗位或者研究方向，到底需要哪些技能 (e.g., Linux, Docker, K8s, Python...)，或者需要哪些努力。

这样，你就能从“企业/院校需求”倒推回你大学四年的“学习目标”，这比瞎学可有效率多啦！(^\_−)−☆

### 3.必备工具

#### 一些懂的都懂的东西

为什么我 github 只能看运气进？为什么我 git 老是推不上去？为什么我项目拉不下来？

首先，可以在必应搜索“xx镜像站”，如“Github镜像站”。

挂加速器可以解决一时之需，无论是游戏加速器还是「Watt Toolkit」，都能加速 github 等一些学术网站。

如果你之后有更深的需求，这里不方便说，来私聊群里的师哥师姐(^\_−)−☆

## 篇章二：AI篇

从 23 年初开始，AI 早就不是什么新鲜玩意儿了，它对整个行业的影响简直是天翻地覆！(ﾉﾟ0ﾟ)ﾉ~

现在，“不会用 AI 的程序员不是好程序员” (ง •̀\_•́)ง 已经快成为共识啦。

但是，**千万不能太依赖AI，千万不能太依赖AI，千万不能太依赖AI！！！**

### 如何正确使用AI

AI 真的可以帮助我们解决超级多的问题，尤其是对初学者来说，简直是“随身老司机”！

1. AI的作用：解释概念、排查错误、生成/补全代码及配置、重构优化代码、梳理文档需求、提供学习路径与思路。
2. 使用前准备：说明环境（系统、语言/依赖版本等）、提供最小可复现代码、完整错误信息与堆栈、说明期望vs实际结果、列出尝试过的解决方法。
3. 提问方式：简述背景（做什么、技术栈）、明确目标、提供输入（代码/错误）、说明约束（平台/版本限制）、指定期望输出形式。
4. 常用Prompt模板：

* 调试：说明语言版本、错误堆栈、代码、期望结果，求分析及修复方案。
* 解释概念：用通俗语言解释，含示例、误区、适用场景。
* 代码优化：说明目标（可读性/性能等），求重构建议及示例。
* 生成测试：指定框架，覆盖正常及边界情况，说明运行方式。
* 环境问题：说明系统、错误、尝试过的方法，求解决步骤。
* 生成配置：指定语言/框架，说明要求，求可用文件及注意事项。

5. 安全与伦理：不泄露敏感信息（密钥、隐私等），因为你的对话数据很有可能被用来训练AI；作业/考试需诚信，以理解和独立完成为前提。
6. 整合流程：用AI做首轮探索（获思路、样板等），自己动手验证，迭代优化prompt，记录建议便于复查。

这里是师哥师姐们精选的几款超棒的 AI 工具，快来 Mark 一下！

### 网页端 AI 助手

**按推荐顺序排列**

#### 海外组

**需要特殊上网环境**

**Gemini 2.5 Pro**

* https://aistudio.google.com/(每天免费100次的Pro模型)
* https://gemini.google.com/ (Pro模型需要付费)
* **(个人强推！(b•̀ω•́)b 个人认为 Gemini 2.5 Pro 是目前最好用的 AI！)**

**ChatGPT** (经典老牌)

* https://chatgpt.com/

**Claude**

* https://claude.com/app-unavailable-in-region
* (P.S. 这家伙**写代码很强**！但别的一般般~)

**Grok**

* https://grok.com/

***

#### 国内组

* **GLM 4.6** （Zai Chat）

  https://chat.z.ai/

* **豆包**

  https://www.doubao.com/chat/

  (P.S. 豆包的功能非常多，平时用起来还是很舒服的 (oﾟ▽ﾟ)o，图片识别能力也很强。只不过... 豆包\*\*“多而不精”\*\*，在面对一些复杂问题时，还是选其他几款 AI 比较好~ (´・ω・\`))

* **Qwen3MAX / Qwen3Coder**（Qwen Chat）

  https://chat.qwen.ai/

  > 为什么使用Qwen Chat/Zai Chat而不是使用通义千问（Qwen）、智谱清言（GLM）?
  >
  > 因为Qwen Chat/Zai Chat虽然和通义千问/智谱清言都是使用同一个模型，但他们其实大相径庭(･ω<)☆
  >
  > 以Qwen Chat为例，相较于通义千问，Qwen Chat整个界面非常简洁，实用。没有眼花缭乱的智能体展示，也没有乱七八糟的资讯推荐，只有一个聊天窗口，但功能丰富。
  >
  > 还有，APP 在对话过程中可能悄悄更换精度更低、性能更差的模型节约成本，
  >
  > 想要深入了解的话可以看一下这个博客 https://www.53ai.com/news/LargeLanguageModel/2025031282630.html

* **Kimi K2**

  https://www.kimi.com/

***

### 编程助手

直接在你的 IDE 里写代码的 AI 伙伴！

#### 模型优先级参考

当你写代码时，AI 的“智商”很重要！这是一个参考排序：

> **Claude 4 sonnet / 3.7 sonnet > Gemini 2.5 Pro > GLM 4.6 > GPT > Qwen3 / Coder > Kimi k2 > Doubao 1.6 > Deepseek V3.1**

#### 神器工具推荐

* **Cursor**：(每月 20$)

  https://cursor.com/cn/agents

* **Windsurf**：(每月免费 25 次)

  https://windsurf.com/editor\`

* **Kiro**：(免费 10 次/天，需要提前申请)

  https://kiro.dev/downloads/

* **Qoder**：(免费两个月)

  https://qoder.com

* **灵码 IDE**：(只有 Qwen 模型)

  https://survey.aliyun.com/apps/zhiliao/Jy4hnFfPp

> 如果你觉得上面的都不满意，你可以尝试自己搭建一个，不比它们差
>
> [国产开源大模型崛起：使用Kimi K2/Qwen2/GLM-4.5搭建编程助手](https://blog.csdn.net/excnies/article/details/149837097?)

***

### 最终奥义

请记住：**AI 没有最好的，只有最适合你的！** (•̀A•́)

每个 AI 都有自己的脾气和擅长的领域，多试试，找到那个和你“电波”最合拍的 AI 伙伴吧！

如果还不知道怎么选，看看 B 站大佬的分析视频：

* [如何科学选择真正适合你的AI？(国内篇)-哔哩哔哩](https://b23.tv/HaT1MMg)
* [如何科学选择最适合你的AI？(海外篇)-哔哩哔哩](https://b23.tv/8XFMnQd)

### 一个最后的警告：千万不要滥用 AI

(o´A\`o) 这一点需要特别注意！我们前面安利了那么多 AI 工具，但**千万不要滥用 AI！**

什么是“滥用”呢？就是你把它当成了“拐杖”，而不是“工具”。

比如，遇到一个问题，自己连想都不想，直接把需求完整地丢给 AI，然后 `Ctrl+C`、`Ctrl+V`，代码能跑就行了... (；¬＿¬) 这种行为是非常危险的。如果你只是当一个“代码搬运工”，**完全不理解**这段代码背后的逻辑和原理，那么你的基础能力会变得极其薄弱。

AI 只能帮你“写”，但不能帮你“理解”。当 AI 犯错时（相信我，它经常会出错！），你甚至都看不出它错在哪里，那不就完蛋了嘛 ( > < )。

所以，我们一定要把 AI 当作一个“高级副驾驶”或者“超级搜索引擎”。用它来**启发你的思路**、**帮你优化代码片段**、**解释你不懂的概念**... 但**思考和理解的主动权**，一定要牢牢抓在自己手里！(•̀ω•́)✧

## 篇章三：开发工具篇

**工欲善其事，必先利其器。掌握这些工具，将极大提升你的学习和开发效率。**

### GitHub

#### 什么是 GitHub？ (・∀・)

简单来说，GitHub 是一个**基于 Git 的代码托管平台**，它就像是程序员们的“社交网站”+“云端硬盘”！(≧▽≦)

它被广泛用于软件开发和**版本控制**。想象一下，它就像一个超级智能的“时光机”，可以帮你：

* **跟踪代码的每一次更改**：再也不怕代码改错或丢失啦！(๑•̀ㅂ•́)و✧
* **轻松管理项目的不同版本**：无论是测试版还是正式版，都井井有条。

GitHub 还提供了一个超赞的**协作环境**，让来自世界各地的开发者可以一起“搞事情”：

* **协作工具**：通过 `Pull Requests`（拉取请求）来审查代码，使用 `Issues`（问题）来跟踪 Bug 和任务，还有 `Project Boards`（项目看板）来管理进度。
* **代码托管**：你可以创建**免费的公共仓库**（所有人可见）或**付费的私有仓库**（只有你和你的团队可见）。
* **社区和开源**：这里是**开源项目**的聚集地！你可以学习大神的项目，也可以为它们贡献自己的代码 (●'◡'●)ﾉ。
* **GitHub Actions**：超酷的**自动化工作流**！可以自动帮你测试、打包、部署代码，简直是懒人福音！
* **安全性**：它会帮你扫描代码，寻找潜在的安全漏洞和依赖问题，保护你的项目安全。

总之，GitHub 不仅仅是存代码的地方，更是一个促进全球开发者协作和创新的**超级社区**！♪

#### 如何使用 GitHub？ (oﾟ▽ﾟ)o

> [【2025版】最新GitHub新手用法详解（适合新手入门）零基础入门到精通，收藏这篇就够了\_github使用详解](https://blog.csdn.net/bdfcfff77fa/article/details/145791820?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522f20296e5fd9f629e42b96b53611e41f2%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D\&request_id=f20296e5fd9f629e42b96b53611e41f2\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-1-145791820-null-null.142^v102^pc_search_result_base6\&utm_term=github%E4%BD%BF%E7%94%A8%E6%95%99%E7%A8%8B\&spm=1018.2226.3001.4187)

这个方法超级适合新手哦！(•̀ω•́)✧

**GitHub Desktop** 是官方推出的图形界面工具，你不需要记住复杂的 Git 命令，只需点点鼠标 🖱️，就能完成大部分操作，比如：

1. **Clone** (克隆)：把网上的项目复制到你的电脑上。
2. **Commit** (提交)：保存你本地的代码修改。
3. **Push** (推送)：把你的修改“推”回 GitHub 仓库。
4. **Pull** (拉取)：获取项目最新的更新。
5. **Create Pull Requests** (创建 PR)：当你想要向别人的项目贡献代码时，这就是“申请合并”的方式啦！

快去下载 GitHub Desktop，开启你的开源之旅吧！♪ (ﾉ\*･ω･)ﾉ

***

### Git

当然不用！Git 是目前世界上最先进的分布式版本控制系统，用来团队协作很方便。就不用每次上传代码都靠手动 upload files 了

如何安装以及使用看这个👇

[Git 详细安装教程（详解 Git 安装过程的每一个步骤）\_git安装-CSDN博客](https://blog.csdn.net/mukes/article/details/115693833)

[Github配置ssh key的步骤（大白话+包含原理解释）\_github生成ssh key-CSDN博客](https://blog.csdn.net/weixin_42310154/article/details/118340458)

[如何在 Github 上规范的提交 PR（图文详解） - 知乎](https://zhuanlan.zhihu.com/p/584834288)

[解决git下载慢的问题，git安装教程，git国内国外下载地址 - 知乎](https://zhuanlan.zhihu.com/p/5857028723)

[在一台电脑上同时使用多个github账号(亲测有效)\_github共享账号-CSDN博客](https://blog.csdn.net/qq_43199318/article/details/103469792)

***

### IDE

在编程世界里，选对 IDE (集成开发环境) 就像剑客选对了剑，能让你的“战力”飙升！(ง •̀\_•́)ง

目前江湖上有两大“神器”：一个是\*\*“重装战甲”—— JetBrains 全家桶\*\*；另一个是\*\*“轻装刺客”—— VSCode\*\*。

那么，到底该怎么选呢？

#### JetBrains 全家桶

JetBrains 旗下的 IDE 都非常好用，覆盖面也超级全！它们就像是为每种语言**量身定制**的豪华套餐：

* 写 **C/C++**？你有 `CLion`！
* 写 **Python**？你有 `PyCharm`！
* 写 **Java**？你有 `IntelliJ IDEA` (这可是“业界标杆” (￣▽￣)／)！
* 写 **Go**？你有 `GoLand`！
* ...还有 `WebStorm` (前端), `RustRover` (Rust) 等等等。

##### **灵魂拷问：可是...它们都要付费购买欸？**

(¬\_¬) 这个问题不用担心！JetBrains 对学生党超级友好！

**学生都是可以免费使用 Ultimate 版全家桶的！** 只需要完成学生认证就好啦。

**学生认证教程**（校园邮箱申请不到，请使用 `2.3 官方文件` 方法进行申请）：

https://blog.csdn.net/qq\_36667170/article/details/79905198

**破解版**：

https://www.ddkk.com/zhuanlan/jihuo/index.html

**赛博大善人**：

自 2023 年起，JetBrains 陆续将多款核心产品开放为“非商业用途免费”模式。截至 2025 年 10 月，已经正式支持免费使用的 **IDE**工具包括：

* **WebStorm**：主要用于 **Java/Type/Web**前端开发。
* **Rider**：主要用于 **.NET/C#/Unity/ASP.NET**开发。
* **CLion**：主要用于 **C/C++/嵌入式**开发。
* **RustRover**：专注于 **Rust**语言开发。
* **Aqua**：一款自动化测试 **IDE**，但已停止开发。
* **DataGrip**：新增，用于数据库/SQL 开发与管理。
* **RubyMine**：新增，用于 **Ruby/Rails**全栈开发。

此外，IDEA、Pycharm 都有社区版可以免费使用。这些免费工具完全足够我们使用。

##### **JB 的“杀手锏” (为什么选它？)**

相较于其他**IDE**，JetBrains 的核心优势在于\*\*“深度集成”**和**“开箱即用”\*\*：

1. **登峰造极的智能代码补全**：
   * JB 的“感知上下文”能力超强，它的代码提示和自动补全（尤其是在大型项目中）经常被誉为“最懂你的”。
2. **真正“开箱即用”的体验**：
   * 集成了你开发所需**几乎所有**的工具，如调试器 (Debugger)、测试运行器、数据库工具、版本控制(Git)界面等。你几乎不需要额外配置。
3. **强大的代码重构**：
   * 提供“核弹级”的重构选项，如安全地重命名 (Rename)、提取方法 (Extract Method) 等。它会帮你分析整个项目，确保重构不会出错。
4. **无缝的调试 (Debug) 支持**：
   * 内置的调试功能极其强大，断点设置、变量监视、调用堆栈查看等体验非常流畅，是大型项目排错的神器。
5. **高级的项目导航**：
   * 在复杂项目里“跳转自如”，能帮你快速找到某个类 (Class) 的用法、接口 (Interface) 的实现，或者父子类的关系。

**简单说：** JB 像一辆**重型坦克** ，它把所有武器都给你装好了，启动可能慢一点，但一旦跑起来，火力威猛，无所不能。

**安利给谁？**

* **某一门语言的“重度使用者”**（比如你 90% 的时间都在写 Java 或 Python）。
* **大型、复杂项目的开发者**。
* **“懒得折腾”**，希望 IDE 帮你搞定一切的同学。

***

#### Visual Studio Code (VSCode)

“高度定制的轻量王者”。当然，也有很多人会问：

##### “安装好麻烦啊，为啥不直接用 Jetbrains 呢？”

问得好！(ゝ∀･) VSCode 走的完全是**另一条路线**。它不是“坦克”，它是一个\*\*“变形金刚”\*\*的核心！

VSCode 本质上是一个**极其轻量、启动飞快**的文本编辑器。它的所有“神力”都来自于它那**无敌的插件生态**！

##### VSCode 的“魅力点” (为什么选它？)

1. **轻量！启动飞快！**
   * 打开一个文件夹或项目几乎是“秒开”，这在日常修改单个文件或小型项目时体验极佳。
2. **无敌的插件生态**：
   * 你需要什么功能，就去插件市场搜什么。写 Python？装 `Python` 插件。写 C++？装 `C/C++` 插件。你甚至可以装 `Doki Theme` 这样的美化插件 (你懂的 😉)。
3. **高度可定制 (DIY)**：
   * 从主题、字体、快捷键到界面布局，你可以把 VSCode “调教”成**完全属于你**的样子。
4. **跨语言“通吃” (全栈友好)**：
   * 如果你今天写点 Python，明天写点前端 (JS/HTML/CSS)，后天再改个 Markdown... VSCode 是**完美**的选择。你不需要为每种语言换一个 IDE。
5. **完全免费**：
   * 对所有人都完全免费，没有附加条件。

**简单说：** VSCode 像一个**高科技“外骨骼”** ，它本身很轻，但你可以根据任务给它挂载不同的“武器”（插件）。

**安利给谁？**

* **全栈开发者**或**前端工程师**。
* 需要**频繁切换**不同语言的同学。
* **喜欢 DIY**、享受“调教”工具快感的极客。
* 需要一个**轻量级编辑器**来快速查看或修改代码的人。

***

**最终建议：**

* **小孩子才做选择，成年人... 两个都要！** 😉
* **建议的工作流：**
  * 用 **JetBrains IDE** (比如 PyCharm) 来处理你的**核心主力项目**。
  * 用 **VSCode** 来**快速打开单个文件**、修改配置文件、写点前端代码，或者做一些跨语言的小脚本。

这样组合使用，才能发挥它们各自最大的优势！♪

### Markdown

#### 什么是markdown?🤔

简单来说，Markdown 是一种轻量级的**标记语言**。

如果你了解 HTML，可以把 Markdown 看作是它的“极简版”。它的核心理念是：**让你用最简单的纯文本符号，来描述并生成带有格式的精美文档。**

**我们为什么需要 Markdown？**

最直接的答案是：传统的格式排版太复杂了！例如，HTML 标签繁琐，Word 又过于笨重。而 Markdown 让你只需专注于内容创作本身，无需在排版工具上分心。

写好的 Markdown 文本（.md 文件）具有极强的可读性，即便是在纯文本状态下，也能清晰地看出文章结构。当通过特定的渲染器（如网站或编辑器）展示时，它会自动编译成漂亮的网页格式（HTML）。我们常见的 GitHub 项目介绍（README.md）就是它最典型的应用。

Markdown 编写的文档后缀为 `.md`, `.markdown`

[Markdown 基本语法 | Markdown 教程](https://markdown.com.cn/basic-syntax/)

#### 什么地方会用到markdown？

Markdown 的应用极其广泛，是现代数字写作的基石之一：

* **文档与笔记**：无论是个人知识管理，还是团队技术文档，Markdown 都能提供简洁高效的写作体验。
* **博客与论坛**：许多静态博客生成器（如 Hugo, Hexo）、项目文档管理工具（如Mkdocs、Vitepress）和技术社区都原生支持 Markdown。
* **代码版本控制**：Markdown 文件是纯文本，能与 Git 等版本控制系统完美协作，清晰地追踪每一次修改。
* **大语言模型**：你与 AI 大模型（如 GPT, Gemini）的许多交互，其返回的格式化文本就是基于 Markdown 的。

#### Typora又是啥

Typora 是一款将 Markdown 的简洁性发挥到极致的桌面编辑器。

它的核心特性是 **“所见即所得”**。你无需在代码和预览窗口之间来回切换，输入 Markdown 标记后，它会立刻为你渲染出最终效果，优雅且高效。

**Typora 的强大功能包括：**

* **实时预览**：无缝的写作体验。
* **学术支持**：轻松插入 LaTeX 数学公式、图表和流程图。
* **代码高亮**：对程序员极其友好，支持几乎所有主流语言。
* **扩展功能**：支持表格、HTML 标签、文件导出等。

> 这份文档就是使用 Typora 编写的，体验远超传统的 Word。

官网下载就完事了https://typora.io/ （*Typora 目前是付费软件，但官网下载后可无限期试用。*）

学习版：[【惊奇软件】Typora 1.11.6(修改版) - Markdown编辑器 - 果核剥壳](https://www.ghxi.com/typora.html)

#### **其他优秀的 Markdown 编辑器推荐**

* **[Obsidian](https://obsidian.md)**
  * **简介**：不仅仅是一个编辑器，更是一个强大的**双向链接笔记**软件。它能帮助你构建网状的知识库，非常适合用于个人知识管理（PKM）。
  * [obsidian新手不完全指南 - 经验分享 - Obsidian 中文论坛](https://forum-zh.obsidian.md/t/topic/1628)
  * [想一小时上手obsidian？这一篇就够了。【玩转Obsidian的保姆级教程】](https://zhuanlan.zhihu.com/p/428519519)
* **[Notion](https://www.notion.com)**
  * **简介**：一个 All-in-One 的模块化生产力工具。它将笔记、数据库、看板、日历等功能融为一体，虽然其编辑器不是纯粹的 Markdown，但深度支持 Markdown 语法，功能极为强大。
  * [想要玩转 Notion？你需要这份快速上手指南 - 少数派 (sspai.com)](https://sspai.com/post/57464)

## 篇章四：高效学习篇

> 我除了跟着师哥师姐学习之外还能在哪里自学呢？

**有这种自学的意识是非常好的，到了大学之后自驱力是成为强者的必要特质。**

***

### 一、 算法与编程语言学习

#### 1. 算法刷题网站

* **[洛谷 (Luogu)](https://www.luogu.com.cn/)** (・∀・)
  * **简介**：这个网站在国内的 OI (信息学奥赛) 圈子里非常有名！它更偏向于算法竞赛，比如 NOIP、ICPC 这类的。洛谷的社区氛围很好，有很多题解和讨论，非常适合竞赛党入门和进阶

* **[LeetCode (力扣)](https://leetcode.cn/)** (•̀ω•́)✧
  * **简介**：这就是全球最著名的\*\*“面试刷题网”！LeetCode 上的题目非常经典，是专门为科技公司（尤其是海外大厂，如 FAANG）的技术面试\*\*准备的。它的题库覆盖了算法和数据结构的方方面面。如果你想找工作，特别是想进大厂，LeetCode 是绕不过去的。

* **[牛客竞赛 (NowCoder)](https://www.nowcoder.com/)** (oﾟ▽ﾟ)o
  * **简介**：牛客是一个“双面手”！它既有像洛谷那样的算法竞赛板块，更重要的是，它有超级多的面向求职的题库！很多国内大厂（比如华为、腾讯）的校招笔试题、面试经验和模拟考试都会放在牛客上。所以，如果你目标是国内大厂，牛客是必刷的！

* **[Codeforces (CF)](https://codeforces.com/)** ( T\_T )
  * **简介**：这就是“大神竞技场”了... Codeforces（人称 CF）是一个纯粹的、高强度的算法竞赛网站。它非常考验你的思维能力和编码速度，比赛（Rounds）举办得非常频繁，全球顶尖的竞赛选手都在上面玩。它非常权威，能打好 CF 的都是“大佬”级别的人物！(≧▽≦)

* **[vjudge 题单](https://vjudge.net/article/752)**
  * **简介**：一个集合了各大平台经典题目的刷题列表，可以帮助你系统性地进行练习，查漏补缺。

#### 2. 优质学习资源与书籍

* **[OI Wiki](https://oi-wiki.org/)**
  * **简介**：一个内容免费、开源、丰富的算法竞赛知识整合站点，系统性地介绍了从基础到进阶的各类算法知识，非常适合查阅和学习。

* **[Hello 算法](https://www.hello-algo.com/)**
  * **简介**：一本开源的、图文并茂的算法入门书。它通过动画和代码示例，让数据结构与算法的学习变得简单易懂。

* **经典书籍推荐**
  * **《C Primer Plus》**：经典的C语言入门教程，内容详尽，适合初学者。
  * **《C++ Primer Plus》**：经典的C++入门圣经，全面且深入，适合系统学习。
  * **《算法竞赛入门经典（第2版）》 (刘汝佳)**：被国内算法竞赛圈亲切地称为“紫书”，是许多人的竞赛入门导师。
  * **《Linux就该这样学》**：一本广受欢迎的Linux入门书籍，实践性强，适合新手掌握Linux操作。
  * **《Python编程：从入门到实践》**：经典的Python入门书籍，通过项目实践引导学习，非常适合初学者。

***

### 二、 网络空间安全 (CTF)

* **[CTF Wiki](https://ctf-wiki.org/)**
  * **简介**：CTF竞赛领域的“维基百科”，系统性地介绍了CTF竞赛的各个方向（Web, Pwn, Reverse, Crypto, Misc）的知识，是入门和进阶的必备手册。

* **在线攻防平台 (靶场)**
  * **[BUUCTF](https://buuoj.cn/)**：一个题目数量多、种类全的在线CTF训练平台。
  * **[CTFHub](https://www.ctfhub.com/#/index)**：技能树形式的CTF学习平台，可以系统地巩固各个知识点。
  * **[CTFShow](https://ctf.show/)**：一个非常适合新手的CTF入门平台，题目由浅入深。
  * **[ADWorld](https://adworld.xctf.org.cn/home/index)**：XCTF联赛的官方练习平台，题目质量高。

* **文章与资源**
  * **[CTF 入门 | 史上最全](https://zhuanlan.zhihu.com/p/631613398)**：一篇知乎上的CTF入门指南，可以帮你快速了解全貌。
  * **[知道创宇研发技能表](https://blog.knownsec.com/Knownsec_RD_Checklist/index.html)**：知名安全公司的技能要求列表，可以作为学习路线图。
  * **[看雪安全论坛精华集](https://www.kanxue.com/chm.htm)**：国内顶级安全论坛的精华文章集合。
  * **[CTF-Wiki 资源列表](https://ctf-wiki.org/introduction/resources/)**：CTF Wiki 官方整理的各类工具、平台和学习资源。
  * **[Hello CTF](https://hello-ctf.com/)**：一个对新手友好的CTF学习网站。

***

### 三、 综合学习与进阶

#### 1. 在线课程与学习平台

* **[学堂在线](https://www.xuetangx.com/)**：清华大学发起的慕课 (MOOC) 平台，汇集了国内外顶尖大学的优质课程。
* **[AcWing](https://www.acwing.com/)**：一个算法学习和分享社区，提供课程、题库和在线编程环境，内容质量高但多为付费。
* \*\*[Coursera](https://www.coursera.org/explore/ai-dubbed-courses?utm_medium=sem\&utm_source=gg\&utm_campaign=b2c_apac_ai-dubbed-courses_multi_ftcof_explore_cx_dr_bau_gg_pmax_pr_s1_en_m_hyb_25-05_x\&campaignid=22493560989\&adgroupid=\&device=c\&keyword=\&matchtype=\&network=x\&devicemodel=\&creativeid=\&assetgroupid=6572453585\&targetid=\&extensionid=\&placement=\&gad_source=1\&gad_campaignid=22503606895\&gbraid=0AAAAADdKX6azhV6gISS4iWbTtNHVbDEgH\&gclid=CjwKCAjwx-zHBhBhEiwA7Kjq6xp32gJ3aBWqzu-EUxt9gIiSVTkt_5pYmVu6TAWt7uilGClss3wmEBoCexsQAvD_BwE\&isNewUser=true)：\*\*斯坦福教授创办的全球慕课（MOOC）平台，与全球顶尖大学合作，提供课程、专业证书和在线学位（吴恩达的所有课程都出自这里哦~）。

#### 2. 系统性自学指南

* **[CS 自学指南 (CSDIY)](https://csdiy.wiki/)**：一份非常详尽的计算机科学自学路线图，整合了全球顶尖大学的优质公开课资源。
* **[CS@NCU 开学第一课](https://cs4ncu.space/)**：南昌大学的计算机入门课程，为大一新生提供了清晰的学习路径。
* **[Missing Semester (中文版)](https://missing-semester-cn.github.io/)**：MIT的宝藏课程，教授命令行、Git、Vim等“工具”的使用，这些是课堂上通常不教但却至关重要的知识。

#### 3. 大学课程与项目实践

* **[合肥工业大学 COD](https://soc.ustc.edu.cn/COD/)**: 计算机组成原理课程资料。
* **[合肥工业大学 Vlab](https://vlab.ustc.edu.cn/)**: 操作系统课程资料。
* **[USTC LUG 101](https://101.ustclug.org/)**: 中国科学技术大学Linux用户协会的新生入门课程，覆盖了Linux使用的方方面面。
* **[30天自制操作系统](https://github.com/yourtion/30dayMakeOS?tab=readme-ov-file)**：一个经典的开源项目，跟着它一步步写出一个属于自己的操作系统。
* **[杭电教学 Wiki](https://wiki.xyxsw.site/)**：杭州电子科技大学的课程资料分享。

#### 4. 语言与方向深入

* **[Python By Hy](https://www.byhy.net/)**：一个专注于Python爬虫、自动化办公等实战应用的教程网站。
* **[Learn Git Branching](https://learngitbranching.js.org/?demo=\&locale=zh_CN)**：通过可视化的方式，让你像玩游戏一样轻松掌握Git的复杂操作。
* **[Go 语言之旅 (中文版)](https://tour.go-zh.org/welcome/1)**：Go语言官方的互动式入门教程。
* **[Java 全栈知识体系 (JavaBetter)](https://javabetter.cn/)**：一份非常全面的Java学习和面试指南，内容覆盖广。
* **[机器学习课程 (apxml)](https://apxml.com/zh/courses)**：一系列机器学习相关的课程。
* **[大规模预训练语言模型 (OpenBMB)](https://openbmb.cn/community/course/)**：由清华大学自然语言处理实验室等联合打造的大模型学习资料与工具。
* **[CS61A (UC Berkeley)](https://cs61a.org/)**：加州大学伯克利分校的经典计算机科学导论课程。
* \*\*[动手深度学习](https://zh.d2l.ai/chapter_preface/index.html)：\*\*面向中文读者的深度学习教科书，强调通过代码实现模型，提供 PyTorch 等多种框架实现。

#### 5. 优质博客与文章

* **[水论文的程序猿 (博客园)](https://www.cnblogs.com/nickchen121)**：一位B站UP主的博客，内容深入浅出，质量很高。
* **[字节跳动工程师的学习资料](https://www.ddkk.com/zhuanlan/share/index.html)**：字节跳动员工整理分享的学习资源。
* **[Learn CS Site](https://www.learncs.site/)**：一个计算机学习资源导航站。
* **[Duanwxq 的 CSDN 博客 (Python 算法)](https://blog.csdn.net/Duanwxq/article/details/137641008)**：一篇关于Python算法学习的博客文章。
* **[一个算法爱好者的Python之路 (知乎)](https://zhuanlan.zhihu.com/p/486349954)**：在知乎上分享的Python算法学习心得。

***

### 四、 技术社区与资源下载

#### 1. 技术交流社区

* **[w2solo](https://w2solo.com/)**: 独立开发者社区。
* **[Linux.do](https://linux.do)**：一个活跃的Linux技术论坛。
* **[HelloGitHub](https://hellogithub.com)**：分享有趣、入门级的开源项目。
* **[Linux 中国](https://linux.cn/)**：国内知名的Linux技术社区。
* **[It's FOSS](https://itsfoss.com/)**: 一个专注于Linux开源资讯的英文网站。
* **[Arch Linux 中文维基](https://wiki.archlinuxcn.org/)**：Arch Linux用户的“圣经”，文档极为详尽。

#### 2. 资源与软件下载

* **工具软件分享站**
  * [殁漂遥](https://masuit.net/)
  * [高木同学](https://t.me/gaomutongxue)
  * [大眼仔旭](https://www.dayanzai.me/)
  * [奇技淫巧](https://www.qijishow.com/down/index.html)
  * [阿虚同学的储物间](https://axutongxue.com/)
  * [爱软客](https://iui.su/)
  * [新趣集](https://xinquji.com/)
  * [Thuscn](https://thuscn.com/lab/)
  * [小众软件](https://www.appinn.com/)
  * [小众软件论坛](https://meta.appinn.net/)
  * [西部落](https://www.xibuluo.com/?fzg)
  * [423Down](https://www.423down.com/)
  * [APKPure/Combo](https://apkcombo.com/zh) (安卓应用)
  * [UmsBox](https://www.umsbox.com/)
  * [奔跑的奶酪](https://www.runningcheese.com/a)
  * [异次元软件](https://www.iplaysoft.com/)
  * [果核剥壳](https://www.ghxi.com/)

* **操作系统镜像**
  * [MSDN, I tell you](https://msdn.itellyou.cn/) (经典站点)
  * [Next, I tell you](https://next.itellyou.cn/) (新版站点)
  * [MSPUDE](https://www.mfpud.com/)
  * [又要重装系统站](https://www.yyczxt.com/)

#### **3. 设计与资讯**

* **字体设计**
  * [猫啃网](https://www.maoken.com/)：分享免费可商用的中文字体。
  * [标志情报局](https://www.logonews.cn/)：报道全球品牌LOGO资讯。

* **科技新闻**
  * [Hi-Linux](https://www.hi-linux.com/archives/7/)
  * [IT之家](https://www.ithome.com/)
  * [软餐](https://www.ruancan.com/)
  * [蓝点网](https://www.landiannews.com/)
  * [开源周报](https://openingsource.org/weekly/)
  * [科技补全](https://xuanli199.github.io/weekly/)
  * [科技补全(bilibili)](https://space.bilibili.com/67079745/lists/3173076)
  * [潮流周刊](https://weekly.tw93.fun)

***

### 如何系统性地提高你的 Coding 能力

编程是一门手艺，需要持续的练习和正确的方法。除了埋头写代码，我们还需要知道去哪里寻找高质量的资源，以及如何从“基础”到“进阶”逐步深化理解。

#### 善用社区与网站资源

在你遇到问题时，第一反应可能是去搜索引擎。这时，你会遇到形形色色的技术网站。首先是 [CSDN](https://blog.csdn.net/)，这应该是国内最老牌、覆盖面最广的技术社区。但正因其“老牌”，内容质量也最“参差不齐”，你很容易碰到大量灌水、内容缝合甚至纯粹抄袭的文章。因此，一个高效使用 CSDN 的技巧是：**不要使用 CSDN 的站内搜索**，而是在你的浏览器（如 Google）搜索问题，然后从结果中点进 CSDN 的帖子。搜索引擎的权重排名通常已经帮你过滤掉了大部分质量低下的内容。

相比之下，字节跳动旗下的[稀土掘金](https://juejin.cn/)在阅读观感和社区氛围上要好很多，内容也更偏向于前端和新兴技术。但它的缺陷在于，内容的广度和深度可能不及 CSDN，当你搜索一些比较冷门或深入的问题时，可能会找不到答案。

如果你想获得真正高质量的解答，我强烈推荐 [Stack Overflow](https://stackoverflow.com/questions)。这是全世界最知名的技术问答论坛，上面的答案通常经过了严格的同行评审。当然，这对你的英语阅读能力有一定要求，但这是作为程序员必须跨过的一道坎。此外，如果你在学习 Linux 相关的知识，那么 [Arch Wiki](https://wiki.archlinuxcn.org/wiki/%E9%A6%96%E9%A1%B5) 几乎是“圣经”一般的存在，其内容的精准和详尽程度无可匹敌。

最后谈谈视频资源，比如 B 站。B 站上确实有很多不错的UP主在分享知识，但视频内容的质量比文字更加参差不齐。我的个人看法是，**大部分看官方文档就能理解的东西，没有必要浪费时间去看视频。** 视频的检索效率和信息密度远低于文字。除非某个视频资源真的讲得深入浅出、口碑极好，否则它不应是你的首选学习途径。

#### 学会阅读官方文档

我们要明白一个道理：**官方文档是“第一手资料”，是了解一个组件或框架最高效、最准确的方式。** 在你具备了一定的编程基础后，直接阅读官方文档是你入门新技术的不二之选。

很多同学的障碍是语言。没错，许多顶级的项目和库都是国外开发的，文档自然是英文的。但请不要一开始就有“畏难情绪”。技术文档的用词相对固定且专业，只要你跨过了最开始的门槛（大概有大学英语四级的词汇量就足够应付），你会发现阅读障碍并不大。

如果实在觉得吃力，可以先找找看有没有官方的“中文镜像站”，或者使用浏览器的“整页翻译”功能作为辅助。但长远来看，锻炼自己直接阅读英文文档的能力，将使你受益终身。

#### 学会阅读源码

当网站资源和官方文档都无法解答你的疑惑时，恭喜你，你很可能触碰到了这个库或语言的某个前沿问题，甚至是发现了一个 Bug。这个时候，你只剩下一个终极武器——**看源码！** 这已经是一项相当高级的能力。

阅读源码的好处远不止于解决当下的问题。它能真正提高你的 Coding 能力，让你理解那些“魔法”背后的实现逻辑。在求职面试中，面试官也很有可能问到一些底层实现，比如 Go 语言的调度器或 `sync.Map` 的原理。当你觉得某个库的教程讲得太烂时，不妨直接去看看它的源码，也许会发现源码本身就是最好的老师。

学习本身也是从“模仿”开始的。这里说的“抄袭”，是去模仿优秀代码的逻辑、排版风格和项目架构。GitHub 上有无数优秀的开源项目，它们是最好的学习材料。通过阅读、模仿，然后将这些知识融会贯通，你才能真正把这些技巧内化为自己的能力。

### 时间管理能力

> 觉得上了大学之后没有想象中那么轻松？觉得一周里课太多？觉得事情很多忙不过来？

这也是很多同学大一时会犯的通病

首先我们需要明确一个前提：**靠学校教的东西以后出去吃不了饭**

> 如果你的目标是本科毕业直接就业，那么你绝对需要自己好好规划时间

首先说本科毕业就业，那么你对绩点就不需要那么看重了，每科能过就行

大一真的很闲，最重要的就是高数和C，以及大一下开设的线代，严点的课就想办法“变通”一下，不严的搬电脑到后排坐着就行or你懂的

说白了，大部分师哥都是期末留一两周，保住毕业证和学位证就行

> 那我想保研或者考研咋办呢

考研的话其实和上面差别不大，只是不能抱着只是为了通过考试的心态了，要正儿八经好好学**想考专业的专业课**。

但是保研的话就不一样了，我反正觉得挺坐牢的😭，每门课你都得认真对待，平时分考试分都不能落下。上课该回答问题就回答问题🙋

这是一份 [榜单竞赛](/competition/competition-lists-2025)，涵盖了教育部白名单的全部竞赛。后期我们会对这些竞赛进行解读。通过考核的，我们会提供比赛资料和资源。

##### 最后

学习任何一门技术都是充满挑战性的，只要保持热爱并且坚持下去，我们终将成为互联网上那个叱咤风云的人。

道阻且长，行则将至！一起加油吧！

> Ps:师哥师姐们的博客：
> ​	萑澈的寒舍 
> ​	薰逸的猫窝 
> ​	芙芙の小窝

作者：薰逸喵~

审阅：郑文卿 芙芙天下第一喵~ 萑澈

---

---
url: https://ain.hmgf.hxcn.space/event/meet-and-greet-2025.md
description: 2025 编程竞赛组见面会讲话稿，介绍课程规划、学习节奏与考核要求。
---

# 2025 年编程竞赛组见面会

大家好！我是编程组的dzx。

在咱们正式上课前，我先花几分钟跟大家聊聊，说说我们接下来要怎么学，以及我们为什么会这么安排。

首先，大家肯定在想，我们到底该学啥？又该怎么学？这其实就是我们的课程规划。

第一步，我们会带大家快速过一遍编程语法，比如C++或者Python，让大家对编程有个基本的概念。其实这些语言都是“换汤不换药”，只要你真正搞懂了一门，再学其他的就快多了。当然，算法基础我们也会讲，但这部分真得靠大家自己花时间去琢磨、去练习，把它变成你自己的东西。

等大家对语言有了一定了解，我们就可以去接触更多好玩的东西了，比如电脑的深入操作、做网站、做App，还有参加竞赛。不管你以后是想保研、考研还是直接工作，电脑都是你离不开的伙伴，所以，熟悉你的工具，绝对有必要。

我知道，可能有人会觉得，师兄师姐们要求是不是有点高，讲得是不是有点快，跟不上怎么办？我想跟大家解释一下，我们之所以把节奏推得这么紧，是因为时间真的不等人。比赛基本都在下学期，我们没有那么多时间在一个点上反复“钻牛角尖”。我们希望的是，用有限的时间，让大家能迅速成长起来。我们都进度会比课堂快很多，因为靠课堂是吃不饱的。相信坚持完成我们都课程，将会对同级同学降维打击。

而且，每个人的强项和兴趣点都不一样。你需要在这些学习和尝试中，找到最适合自己的那条路，找到你最想参加的比赛，然后有针对性地去提升自己。这个过程，才是让你真正“脱胎换骨”的时候。

我们在本学期和寒假讲解C/C＋＋/算法，Linux，Git，Python的学习。本学期至少讲完C/Cpp/算法。这部分有点难，但这是未来应对各种项目和竞赛基础。

我们所有的PPT和资料都会发在群里，非常鼓励大家自己去学。在大学里，自学能力太重要了。为什么有的人一点就透？因为他有自己的学习方法。所以说，自学是你进步的“快车道”。如果你掌握了自学，那你在大学里做什么都会比别人顺很多。记住，勤奋加上自学，这两件事结合起来，就是你最厉害的武器。

关于作业和考核，我们每次课后都会留作业，请大家一定独立完成。我们也会看作业情况打分。寒假结束我们会考一次试，最后结合考试和作业的成绩，正式筛选编程组的成员。通过的同学，我们会给你提供竞赛资料、资源等各种支持。

最后说个严肃的事儿：作业不许抄，也不许大面积用AI。 一旦发现，就没资格了。因为一个人的品行，决定了他能在技术这条路上走多高、多远。

好了，我的开场白就到这。接下来，让我们chw师哥，来给我们分享从蒟蒻到大佬的第一步！

---

---
url: https://ain.hmgf.hxcn.space/event/timu/timu.md
---
# 环梦工坊编程竞赛组 2026 年寒假考核说明

**Welcome to the Era of Vibe Coding!**

欢迎来到 2026 年。在这个 AI Agent（智能体）爆发的元年，编程的范式正在发生翻天覆地的变化。为了评估大家的工程素养、学习能力以及在新时代下驾驭 AI 工具的能力，环梦工坊编程竞赛组特别推出了本次寒假考核。

本次考核不仅是对你过去所学知识的检验，更是一次拥抱未来的实践。我们提供了从**AI Agent 部署**、**大模型应用**、**前后端开发**到**算法竞赛**的全方位挑战，你可以选择自己

请记住，最有价值的不是最终那个完美运行的程序，而是你在探索过程中留下的思考与足迹。

## 一、考核时间与提交

* **考核对象**：2025 级本科生，专业不限，环梦工坊社员/非社员均可参与
* **开始时间**：2026 年 2 月 24 日 00:00
* **截止时间**：**2026 年 3 月 27 日 24:00**（截止后系统将关闭）
* **提交要求**：请查看&#x20;

  * 项目链接：完整的项目源代码（可使用 GitHub、Gitee、Codeberg 仓库或网盘链接，选择 G 题的话请提交你的 ID）：
  * 详细的项目报告（Markdown 格式，可以是仓库 README、单独 Markdown 文档或网盘中的文档文件，可填无）：
  * 部署链接 / 安装包 / 成果展示 / Docker 运行命令：（可选）

## 二、考核项目

本次提供 7 个不同方向的挑战项目，每个项目都对应当下技术领域的重要应用场景。请根据兴趣与现有基础，**任选其一** 进行挑战。

* **A / B / C**：由易到难，偏 AI 相关方向
* **D / E / F**：偏工程开发（前后端 / 运维 / 自命题）
* **G**：算法题题单（面向竞赛训练）

### 小米杯考核：四足机器人仿真环境搭建

* **赛事状态：** 2026 年小米杯已开启，详情请查看上方章程。
* **往届成绩：** 环梦工坊成员在 2025 年小米杯中获得 **1 项国家一等奖、2 项国家二等奖**。
* **参赛支持：** 如计划参赛，组内会提供相应辅导。
* **参与要求：** 需要先完成 **小米杯考核：四足机器人仿真环境搭建**，或完成下方任意一道寒假考核题，并通过面试。
* **教程位置：** Docker 镜像的下载、导入与运行步骤见上方教程页。

### 项目 A：基于 OpenClaw 的 AI 助手部署实践

* **项目简介：** 在 Linux 或 Mac 环境下部署并调教属于你自己的 AI Agent，接入国产大模型，实现自动化任务、消息汇总、运维监控等功能。
* **核心技术栈：** Linux、Docker、AI Agent 框架、API 集成、自动化脚本。
* **考核及格线：** 至少完成 **Level 2**（实现每日AI消息汇总功能）。
* **适合方向：** 对 AI 应用部署、自动化运维、Linux 系统感兴趣的同学。

### 项目 B：基于 vLLM 的 OCR 服务部署与实践

* **项目简介：** 选择一款多模态 OCR 模型，使用 vLLM 部署推理服务，实现对复杂文档（PDF、图片）的文字提取与结构化识别。
* **核心技术栈：** Docker、vLLM、OCR 模型、GPU 加速、Python、Web 开发（可选）。
* **考核及格线：** 至少完成 **Level 3**（对不同类型 PDF 进行 OCR，如单栏和双栏英文）。
* **适合方向：** 对计算机视觉、文档智能处理、大模型部署感兴趣的同学。

### 项目 C：具身智能世界模型本地部署优化

**项目简介：** 具身智能赋予了虚拟人工智能实体感知并预判物理世界的基本能力。本项目深度聚焦于宇树科技 UnifoLM 视觉动作预测大模型的本地化部署优化。开发者将运用系统内存交换扩容与混合精度计算等极限工程降级优化手段。庞大的工业级权重矩阵借此可在显存严重受限的消费级算力设备上稳定运行。

**核心技术栈：** Linux 底层 Swap 内存交换分区管理、HuggingFace 开源生态、PyTorch 运行依赖配置与 CPU Offload 显存卸载极限性能优化技术。

**考核及格线：** 参与者至少需要顺利通过 Level 2 的工程指标验证。你必须使用专用的量化分析脚本评估生成的视频预测质量。最终产出视频的峰值信噪比必须严格大于或等于 25。

**适合方向：** 此硬核方向为具身智能与大规模运算模型环境搭建的狂热爱好者提供。它要求开发者具备在严苛硬件约束条件下进行极限工程破局的强大决心。

### 项目 D：一键网络切换与基础隔离

**项目简介：** 物理服务器往往需要频繁适配极其复杂的底层网络拓扑流转环境。开发者需要采用纯粹的 Bash 脚本语言编写具备高度幂等性的底层网络控制组件。该系统全权负责在办公局域网的动态寻址与生产数据网络的静态配置间快速无缝切换。它还要求系统实现基础的操作系统级公网访问安全隔离防火墙策略 。

**核心技术栈：** 纯粹的 Bash 底层脚本编程、Linux 系统内核网络命令深度调用以及底层路由防火墙安全控制策略配置。

**考核及格线：** 候选人必须至少完成 Level 2 的基础工程验收需求。底层管控脚本必须支持网络运行模式的无缝切换与自动系统基础校验。系统还需具备一键回滚至初始安全网络配置状态的逆向恢复能力。

**适合方向：** 该项目专为深度痴迷 Linux 系统运维编排体系的爱好者而设计。希望彻底夯实底层网络架构寻址与安全隔离控制基础的同学可以勇敢尝试。

### 项目 E：MikuCMS 简易内容管理系统

**项目简介：** 博客文章与社区论坛构成了现代互联网生态交互的最基础业务形态。本命题要求开发者从零构建一个前后端高度解耦的轻量级内容分发管理平台。你需要独立设计极其规范的底层关系型数据库结构映射关联关系。该系统深度涵盖了用户敏感密码加密鉴权与底层 Markdown 源码动态视图渲染等核心业务控制逻辑。

**核心技术栈：** 任意主流的现代后端微服务框架、原生规范或主流组件化前端视图框架、底层关系型数据库实体建模与基于 JWT 的全链路状态拦截守卫技术。

**考核及格线：** 该前后端解耦项目的及格验收线被官方严格设定在 Level 3。开发者需要构建具备多表数据联合查询特性的完整嵌套互动评论交互子系统。

**适合方向：** 渴望突破单一语言边界的全栈开发探索者是本命题的最佳受众群体。它极其适合希望通过实战系统锻炼后端 API 路由接口设计与业务数据库防范建模能力的同学。

### 项目 F：自命题项目

* **项目简介：** 如果你有自己的想法，可以选择自命题。需提前与负责人沟通确认选题可行性。
* **参考选题：** LLM 驱动的搜索引擎、RAG 知识库、编码助手、PPT 生成器、AI 虚拟助手/数字人等。
* **考核及格线：** 至少实现 **3 个与选题强相关的核心功能**，项目完成度较高，文档完整。
* **适合方向：** 有明确兴趣方向、具备自主学习能力、希望挑战复杂项目的同学。

### 项目 G：算法刷题

* **项目简介：** 针对希望专注算法竞赛的同学，提供题单，完成指定数量的算法题目，帮助大家备战蓝桥杯等算法竞赛。
* **考核及格线：** 完成题单的 **75%** 即可通过。
* **适合方向：** 专注算法竞赛、希望提升编程竞赛能力的同学。

## 三、提交要求

### 提交平台

### 提交内容

根据项目类型，提交以下内容：

1. **完整的项目源代码：**\
   包含所有必要的配置文件与说明（如依赖、环境配置、启动脚本等），可上传至 GitHub、Gitee、Codeberg、GitLab 等代码托管平台，或提供网盘链接，并保证他人可按文档复现运行。（选择 G 题的同学请提交你的刷题平台 ID）

2. **详细的项目报告（Markdown 格式）：**\
   可以是你的仓库 README，也可以直接提交 Markdown 文件；如果你通过网盘提交材料，也可以将报告文档一并放入网盘。如果确实没有产出（选择 G 题的同学可填"无"），可填"无"。这是你整个学习和实践过程的全面展现，请认真撰写，建议至少包含：
   * 项目简介与技术栈说明
   * 已实现功能清单
   * 项目结构说明
   * 本地运行指南（环境要求、安装步骤、启动方式、常见问题）
   * API 文档（Apifox/Postman 链接或导出文件，如适用）
   * 开发过程记录（遇到的问题、解决方案、参考资料/链接）

3. **部署链接 / 安装包 / 成果展示 / Docker 运行命令：**\
   请按你的项目形态提供尽可能完整的交付物（可多选）：
   * 清晰的运行截图
   * 演示视频（建议 3–5 分钟，可提交文件或 B 站链接）
   * 部署地址（如有线上部署）或软件安装包（如适用）
   * 如上传到 DockerHub：需同时提供 **镜像地址** 与 **可直接运行的 Docker 命令**（如 `docker run ...`），并在文档中说明关键参数

4. **算法题（项目 G）：**\
   需提交刷题平台 ID 与完成情况证明（截图/链接等），并确保能核验题目完成量与通过率。

5. **个人简历（Word）：**

   加入纳新群915668300，群文件下载简历模板提交。

### 提交格式要求

* Git Commit 消息需符合 [约定式提交规范](https://www.conventionalcommits.org/zh-hans/v1.0.0/)。
* 代码注释使用中文或英文均可，要求清晰规范。

## 四、注意事项

1. **允许使用 AI 辅助学习与开发**（查资料、对比方案、生成脚手架/样例代码等），但你需要对自己的实现负责：
   * 你应当能解释“为什么这么写、这样写的好处与风险、关键模块如何工作”。
   * 对疑似大段 AIGC/复制粘贴的提交，我们会提高追问强度；无法说明清楚可能影响成绩/判定无效。
2. **原创性与过程记录很重要**：建议在项目报告/README 中记录
   * 环境搭建、关键决策、踩坑与修复过程
   * 参考资料链接（文章/文档/视频/开源项目等）
   * 功能实现清单与自测说明
3. **可复现性**：尽量做到他人根据文档能跑通；提交前请自检链接、镜像、部署地址是否有效。
4. **项目完成度：** 是否达到或超过指定的最低考核等级要求。
5. **过程文档记录：** 是否提供了详尽的学习笔记、开发日志或博客文章。我们希望看到你的思考过程，包括但不限于：
   * 关键概念的学习与理解。
   * 环境配置、代码调试过程中遇到的问题及解决方案。
   * 参考过的主要资料链接。
   * 每个阶段的心得体会与总结。
6. **代码质量：** 代码结构是否清晰，注释是否规范，是否易于理解和维护。
7. **创新与扩展：** 是否在完成基础要求之上，尝试了额外的加分项或进行了功能扩展。
8. **独立思考与原创性：** 项目是否为独立完成，文档是否体现了个人理解而非简单抄袭。

### 特别说明

涉及前端开发的项目，**要求美观、现代化的前端界面**。如果提交的前端页面呈现明显"AI 默认模板风格"（如常见的蓝紫渐变默认配色、模板化布局与组件堆砌、缺乏设计规范与信息层级），**将直接判定考核不通过**。

建议参考视频学习如何去除"AI 味"：【AI 做的网站丑爆了？7 招教你去除 AI 味儿！AI编程必学技巧】https://www.bilibili.com/video/BV1QF6EBiErM/

* **算法题（项目 G）禁止使用 AI 直接生成答案。**

## 五、参考资源与工具

* **科学上网**：[Watt Toolkit](https://steampp.net/)
* **推荐AI**：GPT-5.2，Gemini 3 Pro，GLM 5，DeepSeek
* **Vibe Coding 指南**：[Vibe Coding CN](https://github.com/2025Emma/vibe-coding-cn)

**祝大家在寒假考核中挑战自我，收获满满！**

*环梦工坊编程竞赛组* *2026年2月*

---

---
url: https://ain.hmgf.hxcn.space/event/xiaomi-cup-cyberdog.md
description: 小米杯考核说明，涵盖 Cyberdog 仿真环境搭建、Gazebo 与 RViz2 启动、运动控制程序运行及基础验收要求。
---

# 小米杯考核：四足机器人仿真环境搭建

## 一、考核目的

本考核旨在检验参赛者对机器人仿真环境的基本搭建能力以及对 ROS2 与 Gazebo 仿真系统的基础使用能力。

参赛者需要完成以下任务：

1. 在本地电脑成功搭建 **Cyberdog 仿真环境**
2. 成功运行 **Gazebo + RViz2 仿真程序**
3. 启动 **运动控制管理程序**
4. 在仿真环境中使 **机器狗正常运动**

完成以上内容即可判定为 **考核合格**。

### 提交要求

考核完成后，参赛者需要提交以下内容：

1. **环境配置项目报告**：详细记录环境搭建过程、遇到的问题及解决方案
2. **运行机器狗的源代码**：包括仿真启动脚本、运动控制程序等
3. **运行视频**：录制机器狗在仿真环境中正常运动的演示视频

## 二、考核环境要求

### 1. 操作系统

推荐使用：

* **Ubuntu 20.04**

环境部署方式允许以下三种：

* 双系统（Windows + Ubuntu）
* 虚拟机（VMware / VirtualBox）
* WSL（Windows Subsystem for Linux）

系统安装可参考以下教程：

### 2. 软件环境

需要安装：

* Docker **20.10.21**
* ROS2 Galactic（已包含在 Docker 镜像中）

Docker 安装教程：

### 3. 推荐硬件配置

建议电脑配置如下：

| 硬件 | 推荐配置                  |
| ---- | ------------------------- |
| CPU  | 4核心及以上               |
| 内存 | 16GB 及以上               |
| GPU  | NVIDIA 独立显卡（推荐）   |
| 存储 | 50GB 以上空间（SSD 推荐） |

该仿真环境基于 **Gazebo 仿真器**，因此对显卡和内存要求较高。

## 三、考核任务

参赛者需要完成以下任务：

1. 安装 Ubuntu 系统
2. 安装 Docker
3. 导入 Cyberdog 仿真 Docker 镜像
4. 启动 Gazebo 仿真环境
5. 启动机器狗控制程序
6. 成功运行仿真并观察机器狗运动

教程位置：

## 四、环境搭建步骤

### 下载 Docker 镜像

下载镜像文件：

\<DownloadTabs
title="网盘下载"
:providers="\[
{ value: 'baidu', description: '主下载线路。' },
{ value: '123pan', label: '123网盘', description: '备用下载线路。' }
]"

>

\<template #default="{ provider }">






下载完成后，将文件放在 Ubuntu 系统目录中。

## 五、导入 Docker 镜像

打开终端，执行：

```bash
sudo docker load -i cyberdog_raceV2.tar
```

导入完成后，可通过以下命令查看镜像：

```bash
docker images
```

## 六、授权 X Server

为了使 Docker 内部程序能够打开图形界面（Gazebo / RViz），需要授权 X Server。

执行：

```bash
xhost +
```

## 七、运行 Docker 容器

运行仿真环境容器：

```bash
sudo docker run -it \
--shm-size="1g" \
--privileged=true \
-e DISPLAY=$DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix \
cyberdog_sim:v1
```

运行后进入 Docker 内部终端。

## 八、运行仿真环境

在 Docker 终端中执行：

```bash
cd /home/cyberdog_sim
python3 src/cyberdog_simulator/cyberdog_gazebo/script/launchsim.py
```

该脚本将启动完整仿真系统。

启动后会出现三个窗口：

1. **cyberdog\_gazebo**
   Gazebo 仿真环境窗口
2. **cyberdog\_control**
   机器人控制程序窗口
3. **cyberdog\_visual**
   RViz2 可视化窗口

Gazebo 用于仿真机器人与环境交互，RViz 用于显示机器人状态与传感器数据。

## 九、启动运动控制程序

打开 **新的终端（Docker 内）**

执行：

```bash
cd /home/cyberdog_ws

source /opt/ros/galactic/setup.bash
source install/setup.bash

ros2 run motion_manager motion_manager
```

该程序提供 ROS2 Topic 控制接口，可将 ROS2 控制指令转换为 LCM 指令发送给控制程序。

## 十、仿真通信结构简介（了解）

仿真系统中主要包含两种通信方式：

### 1. LCM 通信

用于机器人控制程序与仿真系统之间的通信。

### 2. ROS2 Topic

用于：

* 机器人状态
* 传感器数据
* 控制命令

常见 topic 包括：

```text
/joint_states
/tf
/imu
/scan
```

Gazebo 会将仿真传感器数据发布为 ROS2 Topic。

## 十一、常见问题解决

### Gazebo 无法正常关闭

如果 Gazebo 无法关闭，可以执行：

```bash
killall -9 gazebo
killall -9 gzserver
killall -9 gzclient
```

---

---
url: https://ain.hmgf.hxcn.space/event/xiaomi-cup-cyberdog-docker.md
description: cyberdog_sim Docker 镜像的下载、导入、图形授权、仿真启动与运动控制程序运行说明。
---

# 小米杯Docker环境搭建教程

## 一、简介

`cyberdog_sim` 镜像提供了基于赛道的 Cyberdog 四足机器人 Gazebo 仿真平台，能够使 Gazebo 仿真程序直接与 Cyberdog 的控制程序 `cyberdog_control` 进行通信。仿真平台及依赖均已安装并编译完成。

## 二、镜像内容

* `ros2-galactic`
  文件目录：`/opt/ros/galactic`
* `gazebo11`
* `eigen` 库
  文件目录：`/home/eigen-git-mirror`
* `lcm` 通信库
  文件目录：`/home/lcm`
* `cyberdog` 功能包
  文件目录：`/home/cyberdog_ws`
  该目录包含 Cyberdog 的主要功能包、全局管理、运控管理等 ROS 节点及通用接口库。
* `cyberdog` 仿真平台
  文件目录：`/home/cyberdog_sim`
  该目录包含 [cyberdog\_locomotion](https://github.com/MiRoboticsLab/cyberdog_locomotion) 和 [cyberdog\_simulator](https://github.com/MiRoboticsLab/cyberdog_simulator) 两个平台，并提供基于 RViz2 的可视化工具，可将机器狗状态的 LCM 数据转发到 ROS。

## 三、推荐环境配置

* Ubuntu 20.04
* Docker 20.10.21
* Docker 安装教程：

## 四、推荐机器配置

* 处理器（CPU）：推荐使用 4 核心及以上处理器
* 内存（RAM）：建议 16GB 或以上
* 图形处理器（GPU）：推荐使用具有图形加速能力的 NVIDIA 独立显卡
* 存储：建议预留 50GB 以上空间，推荐使用 SSD 固态硬盘

## 五、下载 Docker 镜像

下载镜像文件：

\<DownloadTabs
title="网盘下载"
:providers="\[
{ value: 'baidu', description: '主下载线路。' },
{ value: '123pan', label: '123网盘', description: '备用下载线路。' }
]"

>

\<template #default="{ provider }">






## 六、本地导入 Docker 镜像

```bash
sudo docker load -i cyberdog_raceV2.tar
```

## 七、授权 X Server

```bash
xhost +
```

## 八、运行 Docker 镜像

```bash
sudo docker run -it --privileged=true \
  -e DISPLAY=$DISPLAY \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  cyberdog_sim:v1
```

## 九、运行仿真程序

```bash
cd /home/cyberdog_sim
python3 src/cyberdog_simulator/cyberdog_gazebo/script/launchsim.py
```

![cyberdog\_sim Gazebo 窗口](https://gastigado.cnies.org/d/public/image-20260312094943134.webp)

![cyberdog\_sim RViz 窗口](https://gastigado.cnies.org/d/public/image-20260312094950057.webp)

## 十、运行运动控制管理接口程序

```bash
cd /home/cyberdog_ws
source /opt/ros/galactic/setup.bash
source install/setup.bash
ros2 run motion_manager motion_manager
```

## 十一、运动控制接口参考文档

---

---
url: https://ain.hmgf.hxcn.space/event/xiaomi-cup-cyberdog-test.md
description: CyberDog 仿真环境下的 Motion 管理服务激活与常用运动指令测试步骤。
---

# 小米杯 Motion 测试流程

## 1. 启动 Gazebo 和 RViz

```bash
xhost +
sudo docker run -it --shm-size="1g" --privileged=true -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix cyberdog_sim:v2
cd /home/cyberdog_sim
python3 src/cyberdog_simulator/cyberdog_gazebo/script/launchsim.py
```

## 2. 进入 `cyberdog_ws` 并启动 `motion_manager`

```bash
cd /home/cyberdog_ws
source /opt/ros/galactic/setup.bash
source install/setup.bash
ros2 run motion_manager motion_manager
```

## 3. 新开终端进入最近的 Docker 容器

```bash
sudo docker ps -a
sudo docker exec -it 容器ID前3位 /bin/bash
cd /home/cyberdog_ws
```

## 4. 执行 `source` 并激活状态机

```bash
source /opt/ros/galactic/setup.bash
source install/setup.bash
ros2 service call /motion_managermachine_service protocol/srv/FsMachine "target_state: 'Active'"
```

## 5. 执行 Motion 指令（按需修改 `motion_id`）

### 站起

```bash
ros2 service call /motion_result_cmd protocol/srv/MotionResultCmd "motion_id: 111"
```

### 慢走

```bash
ros2 topic pub -r 20 /motion_servo_cmd protocol/msg/MotionServoCmd "{motion_id: 303, vel_des: [0.2, 0.0, 0.0]}"
```

### 快走

```bash
ros2 topic pub -r 10 /motion_servo_cmd protocol/msg/MotionServoCmd "{motion_id: 305,vel_des:[0.6,0,0]}"
```

更多指令参考：[小米机器人实验室开发者指南](https://miroboticslab.github.io/blogs/#/cn/developer_guide)。

---

---
url: https://ain.hmgf.hxcn.space/event/timu/A.md
---
# 项目 A：基于 OpenClaw 的 AI 助手部署实践

欢迎来到“Agent 时代”！如果说 2023-2025 年是“聊天机器人”的爆发期，那么 2026 年无疑是 **AI Agent（智能体）** 的元年。你可能已经刷到了不少视频：一台闲置的 Mac mini 或 Linux 笔记本，在安装了 **OpenClaw (原名 Clawdbot)** 一类开源 AI 助手之后，摇身一变成为了一名不知疲倦的“数字员工”。它不仅能陪你聊天，更能自动整理信息、发送消息、连接 IM 平台，甚至在你睡觉时帮你持续执行流程化任务。

本次项目将带你从零开始，在 Linux 或 Mac 环境下部署并调教属于你自己的 AI Agent。你需要从开源社区中选择合适的框架（如偏本机智能体与电脑操作的 **OpenClaw**、轻量级的 **Nanobot**，亦或是专注于记忆的 **memU**），并将其接入国产大模型（如 GLM 或 Minimax）以降低成本，最后通过飞书（Feishu）或其他 IM 平台实现随时随地的远程交互。

这不仅仅是一个部署任务，更是一次关于“人机协作”未来形态的探索。你准备好拥有你的第一个硅基同事了吗？

OpenClaw 代表了一类强调本机权限、电脑操作与本地工作流的开源 Agent 路线。结合 `npm`、Docker 等安装方式，你可以在 Linux 或 Mac 环境中快速启动服务，并通过虚拟机、容器等手段控制风险。通过这个项目，你将学习到：

* **Linux系统基础**：熟悉虚拟机环境、命令行操作和软件安装。
* **AI框架部署**：了解如何安装和配置 OpenClaw 及其替代框架如 memU 或 Nanobot。
* **模型接入与集成**：连接外部LLM服务，实现智能交互。
* **自动化任务**：设计定时任务、消息处理和通知机制。
* **运维实践**：监控系统状态、警报机制和自动控制。

### 注意：

1. OpenClaw需要访问系统权限，可能影响环境稳定性，强烈推荐在Linux虚拟机中进行部署，以隔离风险。
2. 项目涉及API token使用，注意保护隐私和控制消耗。
3. 所有参考链接仅作为学习资料，实际操作需根据当前版本调整。
4. 想要通过考核，你至少要完成 **Level 2**，并在 **Level 3**、**Level 4** 与 **Level 5** 中任选其一完成。
5. 禁止使用 **QClaw**、**EasyClaw**、**ClawX**、**OpenClaw Manager**、**AutoClaw** 等图形化安装方式完成本题，需优先展示你对环境、依赖、配置与部署过程的实际掌握。
6. 禁止通过云服务商（如阿里云、腾讯云、华为云等）提供的 **一键安装**、**应用镜像**、**云市场预装镜像** 等方式完成部署，必须自行搭建环境并完成配置，以体现对部署流程的实际掌控。
7. 禁止使用 **宝塔面板**、**1Panel** 等服务器管理面板进行部署，需通过命令行完成所有操作。
8. **Nanobot**、**NanoClaw**、**PicoClaw**、**Zeroclaw**、**MimiClaw** 等低开销、可改性高、适合嵌入式部署的方案可以尝试；若你对这些 Claw 代码做了改进，或将其部署到开发板、单板机等设备上，可作为加分项。
9. 使用 **Docker** 或 **Kubernetes** 进行容器化部署可作为加分项。

### 参考资料：

#### Linux 安装

如果你没有 Mac 电脑，可以安装 Linux 虚拟机或者双系统。**由于 OpenClaw 需要大量敏感权限，可能会破坏系统环境或者重要文件，推荐在虚拟机中进行部署。**

* [安装年轻人的第一个Linux虚拟机](/sre/first-vm-2024)
* [从零开始：Ubuntu 24.04 LTS + Win11双系统安装教程](https://hs.cnies.org/archives/dual-boot-ubuntu2404-win11)

#### AI 助手安装教程

#### AI 早报自动化参考

## Level 0：认识核心工具链并安装框架

万丈高楼平地起。首先，你需要在一个稳定的 Linux 环境（推荐 Ubuntu 24.04 虚拟机）或 Mac 系统中安装 Agent 框架。你可以选择 **OpenClaw**（功能最全，但较重）、**Nanobot**（轻量级，Go 语言编写，适合入门）或者 **memU**（擅长长短期记忆）。

考虑到国内网络环境和依赖包的复杂性，**强烈建议使用 Docker 容器化部署**，或者通过 `npm`、`uv`、`brew` 等方式进行本地安装（取决于你选择的框架）。

### 任务目标：

1. 在 Linux 虚拟机或 Mac 上成功安装 OpenClaw、Nanobot 或 memU 其中之一。
2. 完成初始化配置（Onboarding），确保程序能正常启动并进入交互界面。

### 提交要求：

* 安装步骤、遇到的问题和解决方案。
* 安装完成后的终端版本号截图（如 `nanobot --version` 或 OpenClaw 的启动画面）。
* 简述你选择该框架的原因（例如：资源占用低、功能丰富等）。
* 如果你尝试了轻量级 Claw 变体、开发板部署或源码改进，可附上额外说明、代码改动与运行效果，作为加分材料。

## Level 1：初始化AI助手并接入飞书

### 任务目标：

1. 初始化框架的 Onboard 过程。
2. 接入模型服务。AI 智能体 token 消耗较大，推荐使用 [GLM Coding Plan](https://www.bigmodel.cn/glm-coding?ic=ANJX7JPBKO) 或 [Minimax Coding Plan](https://platform.minimaxi.com/subscribe/coding-plan?code=L5Ua6ZLLoY\&source=link) 等额度大、折扣高的方案。
3. 将 AI 助手集成到飞书（推荐）、QQ、企业微信、Discord（推荐）、Telegram 或其他协作工具中，实现实时对话。
4. 测试基本交互功能，确保模型响应正常。

### 提交要求：

* 配置步骤和相关命令。
* 配置文件的脱敏截图（隐藏 API Key）。
* 与 Agent 对话的截图，证明其正在使用指定模型回答问题。

## Level 2：实现每日AI消息汇总功能

添加自动化任务，让AI助手定时汇总信息。这一步体现AI的实用价值，如信息聚合。

### 任务目标：

1. 配置定时任务，每天早上8点运行。
2. 汇总昨日国内外AI相关消息。
3. 通过飞书（推荐）、QQ、企业微信、Discord（推荐）、Telegram 发送汇总结果。
4. 优化 AI 新闻获取与处理阶段的提示词，尽量减少幻觉、误引与主观臆测，避免生成内容明显偏离原始新闻。

### 验证标准：

* 定时任务正常触发，汇总内容覆盖关键AI热点。
* 消息发送成功，能在指定渠道查看。
* 汇总内容与原始新闻基本一致，关键信息、时间、主体和结论没有明显编造或错配。

### 提交内容：

1. 定时配置和运行日志截图。
2. 一份示例汇总消息。
3. 用于 AI 新闻获取、筛选、摘要或改写的核心提示词，以及你为降低幻觉所做的优化说明。

## Level 3：生成可分享的 AI 早报页面 / 图片 / 视频

在完成基础消息汇总后，进一步把信息流转化为真正可分发的“内容成品”。这一关强调从“搜集信息”升级为“生产内容”，参考 Juya 的 AI 早报工作流，要求你将 RSS、你选用的 Agent 框架与代码生成工具结合起来。

### 任务目标：

1. 配置至少一个可稳定使用的 AI 信息源，推荐基于 RSS 订阅进行采集，也可以在 RSS 基础上补充网页抓取或 API 数据源。
2. 对搜集到的信息进行筛选、去重、摘要与结构化整理，形成当天或近 24 小时的 AI 早报内容。
3. 让你选用的 Agent 框架调用 **Codex** 或 **Claude Code**，生成至少一种可分享成品：
   * 网页版早报
   * 图片版早报
   * 视频版早报
4. 如果你选择网页版，需完成公开部署，推荐使用 **Cloudflare Pages**、**Vercel** 或 **EdgeOne Pages**。
5. 优化新闻处理与成品生成阶段使用的提示词，控制 AI 幻觉，避免成品标题、摘要和结论偏离原始新闻内容。

### 验证标准：

* 至少配置一个可验证的 RSS 信息源，并能证明其被成功纳入采集流程。
* 信息来源真实可追溯，摘要内容与原始信息基本一致。
* 成品可正常打开、查看或播放，具备清晰标题、摘要、来源链接与生成时间。
* 若为网页版，部署链接可正常访问；若为图片或视频版，需提供最终效果截图或导出文件。
* 成品中的关键信息、观点归因与事实描述没有明显幻觉，能够回溯到对应新闻来源。

### 提交内容：

1. RSS 源配置、采集流程与生成流程说明。
2. 你选用的 Agent 框架调用 Codex 或 Claude Code 的关键配置或操作截图。
3. 部署链接，或最终生成的图片 / 视频效果。
4. 新闻获取、摘要、改写或生成页面/视频时使用的核心提示词，以及你为降低幻觉所做的提示词优化说明。
5. 一段简短复盘，说明你在内容质量、排版和自动化稳定性上的取舍。

## Level 4：实现运维监控与自动化功能

扩展AI助手的运维能力，实现高级自动化。这一步让系统更智能，适用于生产环境。

### 任务目标：

1. 添加系统监控功能，跟踪资源使用。
2. 配置消息警报机制，当异常发生时通知。
3. 集成邮箱通知，支持发送报告。
4. 实现自动控制，如根据条件调整设置。

### 验证标准：

* 监控数据实时更新，能检测异常。
* 警报和通知正常触发，邮箱接收成功。
* 自动控制逻辑生效，能响应预设条件。

### 提交内容：

1. 监控和警报配置截图。
2. 测试通知的示例输出。

## Level 5：卸载 OpenClaw 并解释本地架构

这一关只要求给出**简洁、可执行的卸载过程**，不要求写成面向新手的长篇图文教程。该关默认面向选择了 **OpenClaw** 路线的同学，用于考察你对安装产物、残留文件与本地架构的理解。

### 任务目标：

1. 对你已经部署过的 OpenClaw 执行一次完整卸载，说明你实际采用的卸载顺序。
2. 结合你机器上的 `~/.openclaw/` 目录结构，解释 OpenClaw 的本地架构，例如配置、数据、日志、缓存、插件或运行时文件分别承担什么职责，以及它们与启动流程的关系。
3. 给出残留清理与复检方法，确认 OpenClaw 已完全卸载。

### 验证标准：

* 卸载步骤简洁清楚，能看出你确实理解自己安装过哪些内容，而不是机械复制命令。
* OpenClaw 相关进程、服务、容器、可执行入口与用户目录残留已经被检查，并能说明哪些已删除、哪些被保留以及原因。
* 你能基于 `~/.openclaw/` 的实际内容解释 OpenClaw 的本地架构，而不是只复述网络资料。

### 提交内容：

1. 具体卸载步骤：写清楚你执行了哪些命令、按什么顺序处理进程 / 服务 / 安装目录 / 用户目录。
2. 如何确认 OpenClaw 已完全卸载：至少说明你使用了哪些检查方式来确认命令入口不存在、相关进程不再运行、容器或服务已移除、`~/.openclaw/` 等残留路径已清理完毕。
3. 一段基于 `~/.openclaw/` 的架构说明：结合你机器上的实际目录树，解释 OpenClaw 在本地是如何组织配置、数据与运行时状态的。

---

---
url: https://ain.hmgf.hxcn.space/event/timu/B.md
---
# 项目 B：基于 vLLM 的 OCR 服务部署与实践

> **背景引言**：
>
> 传统的 OCR（光学字符识别）往往止步于“认字”，但在 2026 年的今天，能够理解复杂排版、公式、表格甚至手写体的 **多模态大模型（VLM, Vision-Language Models）** 才是王者。
>
> 想象一下，你扔给模型一张复杂的论文截图，它不仅能识别文字，还能完美还原 LaTeX 公式、Markdown 表格，甚至直接理解图表含义。本题将带你体验最前沿的文档解析技术，使用 **vLLM** 这一高性能推理框架，部署顶尖的开源 VLM 模型，并将它们封装成现代化的 Web 服务。

### 核心模型选项

本次考核请从以下模型中**任选其一**进行部署：

| **模型名称**         | **模型规模 (显存需求)** | **核心优势与适用场景**                                       | **关键性能指标**                                             | **开源协议** |
| -------------------- | ----------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------ |
| **PaddleOCR-VL-1.5** | 0.9B (8-12GB)           | 真实场景文档解析王者。印章识别与跨页表格合并达到 SOTA 级别。 | 推理速度极快，最高可达 1.86 页/秒。                          | Apache 2.0   |
| **DeepSeek-OCR-2**   | 3B (20GB+)              | 创新架构先锋。系统底层采用 Visual Causal Flow 架构。         | 模拟人类视觉编码过程。它完美支持动态分辨率与 vLLM 高吞吐加速。 | Apache 2.0   |
| **GLM-OCR**          | 0.9B (8-12GB)           | 学术文档精度大师。该模型针对公式与表格的识别能力极强。       | 在 OmniDocBench 评测榜单中取得 94.62 分的最高成绩。          | MIT          |
| **HunyuanOCR**       | 1B (10-15GB)            | 全球多语言专家。该模型原生支持百余种语言的高精度解析。       | 在卡片票据信息抽取与视频字幕解析领域，准确率均超过 92%。     | 未注明       |

*(注：请自行前往 HuggingFace 或 ModelScope 检索上述模型的官方仓库链接）*

### 考核核心

本题重在考察 **Docker 容器化部署**、**vLLM 高并发推理** 以及 **全栈工程能力**。我们拒绝“调包侠”，希望你理解模型是如何在 GPU 上跑起来的。

***

### Level 0： 认识核心工具链

在动手之前，我们需要先建立理论认知。

#### 学习资料：

* #### 系统培训课程

* 红岩网校运维安全部课程：<https://space.bilibili.com/1504551074/lists/4139430?type=season>

2. #### 学习教程

* Git学习教程：<https://ain.hmgf.hxcn.space/guides/sre/git-basics>

3. #### 双系统安装、软件安装、环境配置

* 使用 WSL 安装 Ubuntu 教程：[/sre/first-vm-2024#使用-vmware-workstation-安装-ubuntu-22-04](/sre/first-vm-2024#使用-vmware-workstation-安装-ubuntu-22-04)
* 安装 Ubuntu 24.04 双系统：<https://hs.cnies.org/archives/dual-boot-ubuntu2404-win11>
* Ubuntu 软件安装、使用技巧、系统优化教程：<https://hs.cnies.org/archives/ubuntu2404-optimize>
* Anaconda 安装和配置：<https://hs.cnies.org/archives/conda-win>
* wsl安装Docker教程1：<https://blog.jojo.host/posts/dxdhlMjMt/>
* wsl安装Docker教程2：<https://seepine.com/docker/wsl-install/>
* Ubuntu24.04 安装docker：<https://www.liuwg.com/archives/ubuntu24.04-an-zhuang-docker>

4. #### vllm 部署文档

* vllm 中文文档：<https://vllm.hyper.ai/docs/getting-started/quickstart/>
* vllm 部署模型调用：<https://qwen.readthedocs.io/zh-cn/latest/deployment/vllm.html>
* vllm部署Qwen大模型：<https://www.cnblogs.com/tangwc/p/18905590>
* vllm部署Qwen3大模型：<https://zhuanlan.zhihu.com/p/1902835927396652806>

5. **前端审美避雷**: [【AI 做的网站丑爆了？7 招教你去除 AI 味儿！】](https://www.bilibili.com/video/BV1QF6EBiErM/)

#### **任务目标**：

1. **理解 VLM**：简述多模态模型（Vision-Language Model）与传统 OCR（如 Tesseract、PP-OCR）在技术原理上的核心区别是什么？（关键词：Patch, Encoder, Tokenizer）。
2. **调研 vLLM**：查阅 vLLM 官方文档，了解它是如何支持多模态模型的？什么是 `PagedAttention`？
3. **模型选型**：在 HuggingFace 或 ModelScope 上找到你选择的模型的官方仓库，阅读 Model Card，确认权重下载地址。

**提交要求**：

* 一份简短的学习笔记（Markdown 格式）。

***

### Level 1： 搭建 GPU 加速环境

大模型需要 GPU 的算力支持，而 Docker 需要特殊的配置才能穿透调用显卡。

**任务目标**：

1. **安装驱动**：在 Linux 环境下安装 NVIDIA 驱动和 CUDA Toolkit（推荐 CUDA 12.4+）。
2. **配置 Toolkit**：安装 `nvidia-container-toolkit`，这是 Docker 调用 GPU 的关键组件。
3. **验证环境**：拉取 NVIDIA 官方 CUDA 镜像，并验证容器内 GPU 可见性。

**参考命令流程**：

Bash

```bash
# 1. 安装 toolkit (Ubuntu示例)
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 2. 验证 (关键步骤)
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
```

**提交要求**：

* 在 Docker 容器内部执行 `nvidia-smi` 命令成功的截图。
* 在容器内运行一个简单的 Python 脚本（使用 PyTorch）打印 `torch.cuda.is_available()` 结果的截图。

***

### Level 2： 使用 vLLM 部署推理服务

这是本题的第一个核心难点。你需要构建镜像并启动一个兼容 OpenAI 接口的视觉推理服务。

**任务目标**：

1. **编写 Dockerfile**：基于 `nvidia/cuda` 或 `vllm/vllm-openai` 镜像，构建包含你所选模型依赖的环境。
2. **启动服务**：使用 `docker run` 启动服务。注意：VLM 模型启动通常需要调整参数，例如 `--limit-mm-per-prompt`（限制每个 prompt 的图片数量）或 `--max-model-len`。
3. **API 测试**：使用 `curl` 或 Postman 发送一张包含文字的图片（URL 或 Base64 编码）进行测试。

**vLLM 启动命令参考**：

Bash

```bash
# 示例：启动一个兼容 OpenAI API 的服务
python3 -m vllm.entrypoints.openai.api_server \
    --model /models/your-chosen-model \
    --trust-remote-code \
    --limit-mm-per-prompt image=1 
```

**提交要求**：

* `Dockerfile` 源代码。
* 服务成功启动并加载模型的终端日志截图。
* Postman/Apifox 调用成功的截图（需展示 Request Body 和 Response JSON）。

***

### Level 3： 复杂场景 PDF 解析（及格线）

真实世界的文件往往是 PDF 文档，而不是简单的 JPG 图片。你需要编写 Python 脚本来处理它们。

**任务目标**：

1. **PDF 转图片**：使用 `pdf2image` 等库，将 PDF 文件的每一页转换为高分辨率图像（建议 300 DPI 以上）。
2. **脚本开发**：编写一个 Python 脚本，自动读取 PDF -> 转图片 -> 循环调用 Level 2 的 API -> 拼接结果。
3. **结果清洗**：模型输出的 Markdown 可能包含多余的对话引导词（如 "Sure, here is the text..."），请编写逻辑提取核心内容。

**提交要求**：

* 完整的 Python 处理脚本。
* **效果对比**：提供一张双栏排版的英文论文 PDF 截图，以及脚本解析生成的 Markdown 文件渲染效果截图。

***

### Level 4： 自动化与 Python SDK 封装

为了让你的服务更易于集成，请封装一个健壮的 Client 类。

**任务目标**：

1. 封装一个 `OCRClient` 类。
2. 实现 `ocr_file(file_path)` 方法，自动判断输入是图片还是 PDF。
3. **并发加速**：当处理多页 PDF 时，使用 Python 的 `concurrent.futures` 或 `asyncio` 实现并发请求，大幅缩短长文档的解析时间。

**提交要求**：

* `OCRClient` 类源代码。
* 解析一份 10 页以上文档的耗时记录（串行 vs 并发）。

***

### Level 5： 构建现代化 Web OCR 应用

拒绝丑陋的 UI！请构建一个美观、现代化的 Web 界面。

*警告：如果提交的前端页面是 AI 默认生成的简陋蓝紫配色/缺乏设计感的页面，将直接视为 Level 5 不通过。*

**任务目标**：

1. **前端技术栈**：推荐使用 React / Vue / Streamlit / Gradio。
2. **功能实现**：
   * **文件上传**：支持拖拽上传 PDF/图片。
   * **实时预览**：左侧显示原始文件，右侧实时渲染解析后的 Markdown（必须支持 LaTeX 公式渲染）。
   * **导出功能**：一键复制文本或下载 `.md` 文件。
3. **后端集成**：调用 Level 4 封装的 SDK 与 vLLM 服务通信。

**提交要求**：

* 前端项目源代码（GitHub 链接）。
* Web 界面操作演示视频（展示上传、解析、公式渲染效果）。

***

### Level 6： 进阶挑战 - 跨语言学术翻译流水线 (Bonus)

结合 OCR 与 翻译能力，打造终极科研神器。

**任务目标**：

1. **链路整合**：
   * 第一步：使用你部署的 OCR 模型提取英文论文内容。
   * 第二步：将提取的英文内容发送给翻译模型。
   * *注：如果你显存不足以同时部署翻译模型，允许调用外部 API（如硅基流动 SiliconCloud 的 DeepSeek-V3/Hunyuan 免费 API）。*
2. **Prompt 优化**：设计专门的 Prompt，确保翻译时保留 LaTeX 公式格式，不破坏原文结构。
3. **双语对照**：在 Web 界面中实现“原文-译文”段落级对照显示。

**提交要求**：

* 实现“上传英文 PDF -> 输出中英对照文档”的完整演示视频。
* 分享你用于翻译的 Prompt 设计思路。

---

---
url: https://ain.hmgf.hxcn.space/event/timu/C.md
---
# 项目 C：具身智能世界模型本地部署优化

欢迎来到\*\*具身智能（Embodied AI）\*\*的前沿阵地！如果说传统的 AI 是被困在屏幕里的“大脑”，那么具身智能就是赋予了 AI 身体，让它能够感知物理世界并付诸行动。

在让机器人真正动手之前，它需要进行“心理预演”（Mental Rehearsal）——即在脑海中模拟行动的后果。本次项目将带你从零开始，部署由\*\*宇树科技（Unitree Robotics）\*\*开发的 **UnifoLM-WMA-0** 世界模型。这是一个视觉-语言-行动（VLA）系统的核心组件，它能像人类做梦一样，预测机器人执行动作后的未来视频画面。

虽然这是一个面向工业级竞赛的高难度模型，通常需要昂贵的算力卡（如 A100），但本次实践特别引入了**低显存优化技术**。你将在自己的消费级电脑（或普通 Linux 服务器）上，利用工程化手段突破硬件瓶颈，跑通这一前沿大模型。

通过这个项目，你将学习到：

* **Linux 系统进阶**：掌握 Swap 交换分区管理、环境变量配置。
* **大模型环境搭建**：熟悉 HuggingFace 生态、PyTorch 环境及依赖管理。
* **极限性能优化**：学习使用 `accelerate` 库和 CPU Offload 技术，在 8G 显存环境下运行 20G+ 的大模型。
* **质量与性能评估**：使用 PSNR 指标衡量视频生成质量，平衡推理速度与精度。

### 注意事项：

1. 推荐使用ubuntu22.04，安装教程与A题中相同。
2. **硬件门槛**：本项目涉及大模型推理，虽然有优化方案，但建议显卡显存不低于 8GB（如 RTX 3060/4060），系统内存建议 16GB 以上。（**推荐显存大于12GB，内存大于等于32GB**）
3. **存储空间**：模型权重与数据集较大，请预留至少 **100GB** 的可用硬盘空间。
4. **路径敏感**：配置文件中多处涉及**绝对路径**，务必根据你的系统用户名（如 `/home/ubuntu/...`）进行细致修改，否则会报错。
5. **想要通过考核，你至少要完成 Level 2。**

### 参考资料：

#### 核心项目与数据

* [GitHub: UnifoLM-WMA-0 项目仓库](https://github.com/unitreerobotics/unifolm-world-model-action)
* [HuggingFace: 模型 Checkpoint 下载](https://huggingface.co/unitreerobotics/UnifoLM-WMA-0-Dual)
* [ASC 竞赛数据仓库 (输入文件与评测脚本)](https://github.com/ASC-Competition)

#### 低配置优化指南 (必读)

* **Swap 扩容**：防止模型加载时内存溢出导致 `Killed`。
* **Accelerate 库**：利用 `cpu_offload` 将部分模型权重卸载到内存，突破显存限制。
* **混合精度推理**：使用 `model.half()` 将 FP32 模型转为 FP16，显存占用减半。

***

## Level 0：环境熔炉 —— 基础配置与数据准备

在开始“预演”之前，你需要搭建一个稳固的数字地基，并解决大模型下载和系统内存不足的问题。

### 任务目标：

1. **环境准备**：创建 Python 3.10+ 的 Conda 环境，安装 `torch`, `xformers` 等核心库。（安装指令在[GitHub - unitreerobotics/unifolm-world-model-action](https://github.com/unitreerobotics/unifolm-world-model-action) Installation处）
2. **系统扩容**：根据《低显存运行指南》，创建并启用 **32GB 的 Swap 交换文件**，防止内存溢出。
3. **数据就位**：
   * 克隆 `unifolm-world-model-action` 仓库。
   * 下载 `UnifoLM-WMA-0-Dual` 模型权重。
   * 从 ASC 仓库下载 5 个场景的输入文件，并按目录结构放置（注意 `examples` 目录下的 csv 和 stats 文件需移动到根目录）。

### 提交要求：

* **Swap 验证**：终端执行 `free -h` 的截图，展示 Swap 空间已增加。
* **文件结构**：模型目录的 `tree -L 2` 或 `ls -R` 截图，证明 `case1` 目录下包含 `.mp4`, `.sh`, 和 prompts 文件夹。

***

## Level 1：初次唤醒 —— 突破硬件瓶颈运行推理

这是最艰难的一步。你需要修改代码和配置，让原本需要 24G 显存的庞然大物在你的设备上运行起来。

### 任务目标：

1. **代码改造（核心）**：
   * 安装 `accelerate` 库。
   * 修改 `scripts/evaluation/world_model_interaction.py`，引入 `cpu_offload` 并将模型加载改为 `model.half()`（半精度）。
2. **路径修正**：编辑 `configs/inference/world_model_interaction.yaml` 和 `case1/run_world_model_interaction.sh`，将所有路径修改为你机器上的**绝对路径**。
3. **执行推理**：运行 `case1` 脚本。注意首次运行可能需要较长时间（5-10分钟）进行模型加载和 Swap 交换。

### 验证标准：

* 脚本成功运行，终端显示进度条（0% -> 100%）。
* 在 `output/inference` 目录下生成了 `0_full_fs6.mp4` 视频文件。

### 提交要求：

* **代码修改截图**：展示你如何修改 `world_model_interaction.py` 以支持低显存运行。
* **推理成功截图**：终端显示 `real 8m15.xxx s` (时间会因硬件不同而异) 的完成界面。
* **成果展示**：将生成的 `0_full_fs6.mp4` 转为 GIF 动图提交。

***

## Level 2：质量质检员 —— PSNR 评估与性能分析

模型跑通了，但生成的视频质量如何？推理速度是否满足机器人实时性要求？你需要用数据说话。

### 任务目标：

1. **批量推理**：尝试运行 `unitree_g1_pack_camera` 场景下的 `case1` 到 `case4`（任选两个即可）。
2. **质量评估**：使用 `psnr_score_for_challenge.py` 脚本，计算你生成的视频与 `gt_video`（参考视频）之间的 **PSNR（峰值信噪比）**。
   * **及格线**：PSNR 必须 **≥ 25**。
3. **性能记录**：记录每个 Case 的推理耗时。

### 验证标准：

* 生成的 JSON 文件中 `psnr` 数值有效。
* 理解推理时间与视频质量之间的权衡。

### 提交内容：

* **评估结果**：生成的 `psnr_result.json` 文件内容截图。
* **分析报告**：简述你的硬件配置（显卡型号、内存大小）以及运行一个 Case 大致消耗的时间。

***

## Level 3：自动化运维工程师 —— 构建一键评测流水线

在实际工程中，我们不可能手动一个一个跑脚本。你需要编写自动化脚本来管理整个流程。

### 任务目标：

1. **编写自动化脚本**：编写一个 Python 或 Shell 脚本，实现以下逻辑：
   * 自动按顺序运行指定场景的所有 Case。
   * 推理完成后，自动调用 PSNR 脚本进行评分。
   * 将结果汇总生成符合比赛提交要求的目录结构（`Teamname_worldmodel/results/...`）。
2. **异常处理**：如果在推理过程中出现 OOM（显存溢出）或 PSNR 低于 25，脚本应输出警告日志。

### 验证标准：

* 脚本能一键执行，无需人工干预。
* 最终生成的目录结构清晰，包含所有日志和视频文件。

### 提交内容：

* **自动化脚本代码**。
* **最终目录结构截图**：展示 `Teamname_worldmodel` 文件夹下的完整树状结构。

***

## 项目总结

完成这个项目，意味着你已经成功地将一个工业级的具身智能“大脑”塞进了普通的电脑里。你不仅掌握了 AI 模型的部署，更学会了如何在资源受限的环境下进行工程优化——这是从“调包侠”进阶为“AI 工程师”的关键一步。

### 附录：8G 显存极速避坑代码 (基于 Level 1)

如果在 Level 1 遇到困难，可以使用以下 Python 脚本自动为模型打上“低显存补丁”：

Python

```python
# 保存为 fix_memory.py 并运行
import os

file_path = 'scripts/evaluation/world_model_interaction.py'
with open(file_path, 'r') as f:
    content = f.read()

# 注入 CPU Offload 和 半精度逻辑
if 'model = model.cuda(gpu_no)' in content:
    new_code = '''
    model = model.half()  # 转半精度
    from accelerate import cpu_offload
    cpu_offload(model, execution_device=gpu_no, offload_buffers=True) # 自动卸载
    model.cond_stage_model = model.cond_stage_model.float() # 修复 CLIP
    '''
    content = content.replace('model = model.cuda(gpu_no)', new_code)
    print("✅ 优化补丁已应用：开启混合精度与内存卸载模式")
    
with open(file_path, 'w') as f:
    f.write(content)
```

祝你好运，愿你的机器人拥有一个清晰的”未来”！

---

---
url: https://ain.hmgf.hxcn.space/event/timu/D.md
---
# 项目 D：一键网络切换与基础隔离

## 背景

新上线一台业务服务器，需要在两种网络环境间快速切换并完成基础验证：

* **办公网络（dhcp）**：eth0 通过 DHCP 获取 IP/网关/DNS
* **生产网络（static）**：eth0 使用静态配置；并要求 **禁止访问公网**（仅允许访问指定内网网段）

***

## 网络地址规划（生产网络 static）

| 项目     | 值                           |
| -------- | ---------------------------- |
| 网卡     | eth0                         |
| IP       | 172.22.146.150/24            |
| 网段     | 172.22.146.0/24              |
| 默认网关 | 172.22.146.1                 |
| DNS      | 172.22.146.53, 172.22.146.54 |

***

## 基本要求

1. 所有操作 **必须通过 bash 脚本**完成；禁止手动编辑网络配置文件（例如 `/etc/network/interfaces`、`/etc/netplan/*`、`/etc/sysconfig/*` 等）。
2. 脚本需支持 **重复执行（幂等）**、**可回滚（rollback）**。
3. 脚本需具备 **日志**（至少记录：时间、动作、结果），并能定位失败原因（错误信息清晰）。

***

## Level 规则

* **通过要求：至少完成 Level 2**
* **Level 3 为加分项**

***

## Level 0：环境确认与脚本框架

### 目标

1. 创建脚本 `netctl.sh`，具备基本的参数解析与 `usage` 帮助信息。
2. 具备日志输出能力（时间、动作、结果），日志可写入文件（路径可自定或用环境变量控制）。
3. 能在非 root 情况下给出清晰提示（例如提示使用 `sudo`）。

### 验收标准

* `sudo ./netctl.sh`（无参数）能输出用法说明并以非 0 退出。
* 日志文件中有对应记录。

***

## Level 1：基础网络配置与模式切换

编写脚本 `netctl.sh`，支持参数：

* `dhcp`：切换 eth0 到 DHCP（办公模式）
* `static`：切换 eth0 到静态配置（生产模式，使用题面给定 IP/网关/DNS）
* `status`：打印当前 eth0 的 **IPv4 地址、默认路由、DNS**

### 约束

* 不允许手动改配置文件，需通过脚本调用系统命令完成（如 `nmcli` / `ip` / `dhclient` 等）。
* 要求幂等：同一模式连续执行不应报错或产生重复/冲突配置。

### 验收标准

* 执行 `sudo ./netctl.sh dhcp` 后，`status` 能看到 eth0 存在 IPv4 地址（DHCP 获取即可）。
* 执行 `sudo ./netctl.sh static` 后，`status` 至少能展示：
  * eth0 IPv4 为 `172.22.146.150/24`（或等价表达）
  * 默认路由网关为 `172.22.146.1`
  * DNS 包含 `172.22.146.53` 与 `172.22.146.54`

***

## Level 2：基础验证 + 回滚

在 `dhcp/static` 切换完成后，脚本需自动执行基础验证；并实现 `rollback` 回滚。

### 2.1 基础验证

切换完成后需做验证：

* eth0 是否存在且处于 UP
* 是否存在 IPv4 地址
* `static` 模式下额外检查：
  * 默认网关是否为 `172.22.146.1`
  * DNS 是否包含 `172.22.146.53/54`
  * 能否 ping 通网关 `172.22.146.1`（超时/次数可自定）

**验证失败要求：**

* 脚本必须以 **非 0 退出码**退出
* 输出清晰错误信息（指出失败项与当前观测值/建议检查项）

### 2.2 rollback

支持参数：

* `rollback`：回滚到脚本**第一次执行前**的网络状态（至少：DHCP/静态方式 + IP/网关/DNS）

**要求：**

* 首次运行时保存“初始状态”（保存方式自定：文件/目录/临时路径均可，但需在 README 中说明）
* 回滚后可通过 `status` 验证配置已恢复

***

## Level 3：生产网络基础隔离（加分项）

当处于 `static`（生产网络）时，通过防火墙或路由策略实现访问控制：

* **允许访问**：`172.22.146.0/24`、`172.16.0.0/12`
* **禁止访问**：公网地址（即除了以上允许网段之外的目的地址都不允许）

### 验收标准（最小可测）

* `static` 模式下：
  * 对允许网段内目标的访问可成功（例如 `ping`/`curl` 任一种即可）
  * 对公网目标的访问失败（例如 `ping 1.1.1.1` 或对公网 IP/域名 `curl` 失败）
* `dhcp` 模式下：
  * 不应因为生产隔离策略导致办公网络无法正常出站（可清空/恢复策略，方案自定但需说明）

***

## 提交要求

* `GitHub 仓库链接`：提交你创建的仓库地址，并确保仓库为可访问状态
* `netctl.sh`：主脚本
* `README.md`：使用说明（参数、示例、备份/回滚策略、日志路径）
* （可选）运行截图/日志片段：展示 `dhcp/static/status/rollback` 的关键输出
* （Level 3 可选）展示“内网可达 + 公网不可达”的命令输出

***

## **参考资料**

### Ubuntu 安装

* [安装年轻人的第一个 Linux 虚拟机](/sre/first-vm-2024)
* [从零开始：Ubuntu 24.04 LTS + Win11 双系统安装教程](https://hs.cnies.org/archives/dual-boot-ubuntu2404-win11)

### 网络与系统命令

[Linux 网络基础与 `ip` 命令](https://blog.csdn.net/qq_35995514/article/details/139486688?ops_request_misc=elastic_search_misc\&request_id=e16442592b2f08e7ac04571ca3710faf\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-1-139486688-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=Linux%20ip%20%E5%91%BD%E4%BB%A4%E8%AF%A6%E8%A7%A3\&spm=1018.2226.3001.4187)

[nmcli 常用命令](https://blog.csdn.net/qq_35995514/article/details/136988861?ops_request_misc=elastic_search_misc\&request_id=60dc5e13b0f329dc58284b2a49d5a968\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-1-136988861-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=nmcli%20%E5%B8%B8%E7%94%A8%E5%91%BD%E4%BB%A4\&spm=1018.2226.3001.4187)

[NetworkManager的使用](https://blog.csdn.net/u012336923/article/details/50639425?ops_request_misc=elastic_search_misc\&request_id=c872c96c3392bc85b4bbac25f4a34f57\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-1-50639425-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=NetworkManager%20%E4%BD%BF%E7%94%A8\&spm=1018.2226.3001.4187)

[Linux DNS 配置](https://blog.csdn.net/wwl012345/article/details/90354240?ops_request_misc=elastic_search_misc\&request_id=7d78a3c0360dc278069b44d6015b900c\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-1-90354240-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=Linux%20DNS%20%E9%85%8D%E7%BD%AE\&spm=1018.2226.3001.4187)

[resolvectl 基础用法](https://blog.csdn.net/m0_47406832/article/details/132469473?ops_request_misc=elastic_search_misc\&request_id=71845f11d8ae684fbb563c1ef740b1df\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-2-132469473-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=systemd-resolved%20%E4%B8%8E%20resolvectl%20%E5%9F%BA%E7%A1%80%E7%94%A8%E6%B3%95\&spm=1018.2226.3001.4187)

[systemd-resolved基础用法](https://blog.csdn.net/qq_47987543/article/details/152190237?ops_request_misc=elastic_search_misc\&request_id=71845f11d8ae684fbb563c1ef740b1df\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-1-152190237-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=systemd-resolved%20%E4%B8%8E%20resolvectl%20%E5%9F%BA%E7%A1%80%E7%94%A8%E6%B3%95\&spm=1018.2226.3001.4187)

[iptables](https://blog.csdn.net/qq_23045563/article/details/143777683?ops_request_misc=elastic_search_misc\&request_id=d2e8db74c0effa72353e9995e7e2122e\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-3-143777683-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=iptables\&spm=1018.2226.3001.4187)

[ping 命令参数](https://blog.csdn.net/omaidb/article/details/116096205?ops_request_misc=elastic_search_misc\&request_id=c24ec731f278fc43c2f43e4c7dd15fb5\&biz_id=0\&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-1-116096205-null-null.142%5Ev102%5Epc_search_result_base8\&utm_term=ping%20%E5%91%BD%E4%BB%A4%E5%8F%82%E6%95%B0\&spm=1018.2226.3001.4187)

---

---
url: https://ain.hmgf.hxcn.space/event/timu/E.md
---
# 项目 E：MikuCMS 简易内容管理系统

**背景**：

博客与社区是互联网最基础的形态。本题目要求实现一个**前后端分离**的简易内容管理系统（CMS）。你需要完成用户鉴权、文章内容的发布与渲染（Markdown）、以及互动评论区。

**核心目标**：

不限制语言（推荐 Go/Java/Node.js），前端不限制框架（原生 HTML/JS 或 Vue/React 均可）。重点考察后端 API 设计能力、数据库设计能力以及对 HTTP 协议的理解。

### 功能要求 (Level 划分)

#### Level 0: 环境搭建与 Hello World

* 搭建开发环境（语言环境、数据库）。
* 实现一个简单的 Web Server，访问根路径返回 `Hello, MikuCMS!`。

#### Level 1: 用户模块 (User System)

* **注册**：支持用户名、密码、昵称注册。密码必须**加密存储**（如 bcrypt/md5+salt）。
* **登录**：验证账号密码，返回 **JWT Token** 或使用 Cookie/Session 维持状态。
* **鉴权**：除登录/注册/浏览文章外，其他接口需携带 Token 才能访问。

#### Level 2: 文章发布系统 (Article System)

* **发布文章**：管理员（或注册用户）可以发布文章。
  * 输入：标题、封面图 URL、内容（Markdown 格式文本）。
  * 处理：后端需验证字段完整性。
* **文章列表**：分页获取文章列表（包含 ID、标题、作者、摘要、发布时间）。
* **文章详情**：根据 ID 获取完整文章内容。
* **前端渲染**：前端需接入 Markdown 解析库（如 `marked.js` 或 `github-markdown-css`）将后端返回的 Markdown 文本渲染为 HTML。

#### Level 3: 评论系统 (Comment System) (及格线)

* **发表评论**：用户可在文章下发表评论。
* **评论列表**：在文章详情页下方展示该文章的所有评论。
* **数据关联**：评论需关联 `user_id` (谁发的) 和 `article_id` (发在哪篇)。
* **删除评论**：文章作者或管理员可以删除其下方的评论。

#### Level 4: 进阶挑战 (Advanced)

* **架构优化**：拒绝 `main.go` 一把梭，采用 `Router` -> `Controller` -> `Service` -> `Dao` 的分层架构。
* **文件上传**：实现图片上传接口（保存到本地静态目录或对象存储），文章封面和内容中的图片不再依赖外部 URL。
* **Docker 部署**：编写 `Dockerfile` 和 `docker-compose.yml`，一键启动前后端及数据库。

***

### 技术栈建议 & 演示

#### 1. 数据库设计参考 (SQL)

```SQL
-- 用户表
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    password VARCHAR(255) NOT NULL,
    nickname VARCHAR(50)
);

-- 文章表
CREATE TABLE articles (
    id INT AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(100) NOT NULL,
    content TEXT, -- 存放 Markdown 源码
    author_id INT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 评论表
CREATE TABLE comments (
    id INT AUTO_INCREMENT PRIMARY KEY,
    article_id INT,
    user_id INT,
    content TEXT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
```

#### 2. 后端接口代码演示 (Go + Gin)

这是一个简单的接口实现思路，展示如何处理 Markdown 内容和关联查询。

```go
// 演示：发布文章接口
type CreateArticleRequest struct {
    Title   string `json:"title" binding:"required"`
    Content string `json:"content" binding:"required"` // 前端传来的 Markdown 字符串
}

func CreateArticle(c *gin.Context) {
    // 1. 从 Context 获取当前登录用户 ID (由中间件设置)
    userID, _ := c.Get("userID")

    // 2. 绑定参数
    var req CreateArticleRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        c.JSON(400, gin.H{"error": "参数不完整"})
        return
    }

    // 3. 存入数据库 (使用 GORM 示例)
    article := Article{
        Title:    req.Title,
        Content:  req.Content, // 直接存 Markdown
        AuthorID: userID.(uint),
        CreateAt: time.Now(),
    }
    
    if err := db.Create(&article).Error; err != nil {
        c.JSON(500, gin.H{"error": "发布失败"})
        return
    }

    c.JSON(200, gin.H{"code": 0, "msg": "发布成功", "data": article.ID})
}
```

#### 3. 前端交互代码演示 (原生 JS)

展示如何调用接口并简单的渲染 Markdown。

```javascript
// 1. 获取文章详情并渲染
async function loadArticle(id) {
    const res = await fetch(`/api/articles/${id}`);
    const data = await res.json();

    if (data.code === 0) {
        document.getElementById('title').innerText = data.data.title;
        
        // 假设引入了 marked.js 库
        // 将后端返回的 markdown 文本转换为 html
        const htmlContent = marked.parse(data.data.content);
        document.getElementById('content').innerHTML = htmlContent;
    }
}

// 2. 发送带 Token 的请求（发布评论）
async function postComment(articleId, content) {
    const token = localStorage.getItem('token'); // 从本地存储获取 Token
    
    const res = await fetch('/api/comments', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${token}` // 标准 JWT 头
        },
        body: JSON.stringify({ article_id: articleId, content: content })
    });
    
    // ... 处理响应
}
```

### 提交要求

1. **源码**：前端 + 后端代码。
2. **文档**：
   * `README.md`：项目运行方式、API 接口文档（或 Apifox 链接）。
   * **演示视频/截图**：证明注册、发文、评论功能可用。
   * **SQL 文件**：数据库建表语句。

---

---
url: https://ain.hmgf.hxcn.space/event/timu/F.md
---
# 项目 F：自命题项目

## 考核内容

从下方的“参考选题”中任选**一个**选题，进行项目开发。具体要求如下：

* 项目的形式不限，推荐使用包含前后端的 Web 应用程序架构，但也同样可以开发桌面应用程序或 TUI 程序。
* 语言不限，推荐使用 Python、Typescript、Go、Rust 等现代编程语言。
* 项目完成度不限，但至少要有三个及以上的符合选题的、能够正常使用的功能。
* 项目代码需要使用 Git 进行管理，并同步到 Github、GitLab、Gitee、CodeBerg 等公共代码托管平台。
* 项目代码中要包含合理的注释，使用中文或英文注释均可。
* Git Commit 消息需要遵循相关 Commit 消息规范（例如 [约定式提交规范](https://www.conventionalcommits.org/zh-hans/v1.0.0/) 和 [Gitmoji 提交规范](https://gitmoji.dev/specification)）。
* 如果你所开发的项目为 Web 项目，需要能够打包为容器镜像并能够以容器方式部署。
* 你所开发的项目应当具有完整的文档（[README.md](http://README.md) 或独立的 docs 均可），其中需要包含项目介绍、项目特点、部署方式、使用方法等内容。

## 基本要求

1. **前端技术栈**
   * 建议使用 **React / Vue / Astro / Svelte** 等现代前端框架进行开发。
   * 不推荐使用 **JSP / ASP / PHP** 等传统方案，也不推荐仅用“纯 HTML + 少量脚本”直接堆页面（除非是非常小的展示型页面）。
   * 前端开发（含 Web 前端、桌面 GUI 界面等），需提供 **美观、现代化** 的界面与良好的交互体验。
   * **重要：若提交的前端页面呈现明显“AI 默认模板风格”（例如常见的蓝紫渐变默认配色、模板化布局与组件堆砌、缺乏设计规范与信息层级），将视为未满足要求，直接判定考核不通过。**
   * 建议参考并规避“AI 味”常见问题，可观看视频：【AI 做的网站丑爆了？7 招教你去除 AI 味儿！AI编程必学技巧】 https://www.bilibili.com/video/BV1QF6EBiErM/
2. **后端技术栈**
   * 建议使用 **FastAPI（Python）/ Spring（Java）/ Gin（Golang）** 等现代后端框架进行开发。
   * 不推荐使用 **传统 Servlet/SSH/Struts2** 等偏旧的技术方案或仅靠手写原生接口堆功能（可维护性较差）。
3. **关于“寒假考核中：三个及以上符合选题要求的功能”**
   * 这里的意思是：你需要**任选一个选题**，并围绕该选题开发**一个项目**；但在这个项目中，至少要实现 **3 个可用功能**，且这些功能必须**与选题强相关**。
   * 由于提供的选题范围都比较大，本次**不强制要求完成度**，只要你能实现并跑通 **≥3 个可用的核心功能**即可。
   * 当然，如果你能做出一个完整、体验闭环且符合选题目标的项目，会更加分。
   * **注意：登录/注册等通用功能不计入这 3 个功能**。
4. **非 AI 驱动的传统项目也可提交**
   * 如果你提交的是非 AI 驱动的传统项目，但项目本身**完成度较高、功能完善**，并且**按规则提交**，同样可以进入考核流程。
5. **不涉及 Infra 与 AI 科研方向**
   * 本项目不包含 Infra 相关内容，也不包含人工智能相关的科研项目。
   * 如果你对这些方向感兴趣，请联系负责人chw进一步沟通。
   * 如果你正在参与相关科研工作，提交相关**材料/成果/代码片段**用于面试展示，依然可以通过考核。
   * 如果你有比较好的其他选题想法，或者做过的以及正在做的 Agent 相关项目，可以私聊chw进行讨论。
6. **不了解 Agent 概念的同学：推荐先看以下视频**

## 提交要求

请根据项目情况选择以下一种方式提交，并确保包含以下全部或相应材料：

* **GitHub 仓库链接**：需确保仓库公开，且根目录下包含完整的 README.md。
* **API 文档**：提供 Apifox 分享链接或 Postman Collection 文件。
* **部署文档**：详细的部署步骤说明。
* **部署地址**：（如有）提供在线访问地址。
* **演示视频**：（可选，建议提供）时长 3-5 分钟，可提交视频文件或 Bilibili 链接。
* **开发记录**：
* * **开发过程/思路**：简述开发过程中的思考与技术选型逻辑。
  * **容器构建记录**：构建和运行容器镜像的完整过程记录（**必须包含截图**）。
  * **功能演示**：浏览器前端界面的功能操作演示（**必须包含截图**，需覆盖每个核心功能）。

README.md 或独立部署文档需包含以下内容：

1. **已实现功能清单**：列出所有已完成的功能点。
2. **进阶功能说明**：（如有）
3. **项目简介**：项目的背景与目标。
4. **技术栈说明**：前端、后端及其他工具库的列表。
5. **项目结构说明**：目录结构的解释。
6. **本地运行指南**：如何从零开始在本地启动项目。
7. **API 文档链接**：指向 Apifox/Postman 的链接。

## 补充说明

* 本次寒假考核允许并推荐使用 Vibe Coding 方式进行开发，并推荐使用 [ClaudeCode](https://claude.com/product/claude-code)、[OpenCode](https://opencode.ai/)、[Roo Code](https://roocode.com/) 等工具搭配 [MiniMax M2.1](https://minimaxi.com/news/minimax-m21) 和 [GLM-4.7](https://docs.bigmodel.cn/cn/guide/models/text/glm-4.7) 等模型进行开发。不过，你仍然需要确保自己能够理解 LLM 给出的代码，并对项目结构和技术栈有清晰的认知。
* 对于 Vibe Coding 场景，很多模型厂商都推出了高性价比的 Coding Plan 套餐。截止至本文档编写时，智谱的 Coding Plan 已限售，但 [MiniMax Coding Plan](https://platform.minimaxi.com/docs/coding-plan/intro) 仍然可以购买并且有[折扣](https://platform.minimaxi.com/subscribe/coding-plan?code=L5Ua6ZLLoY\&source=link)，有需要的同学可以看一下。
* MiniMax 平台也提供了语音合成、视频生成、图片生成、音乐生成等多种生成式 AI 模型，如果在开发项目的过程中有相关需要，也可以使用。
* 在项目开发以及构建和推送/拉取容器镜像时，可以试试 [Github Codespaces](https://github.com/features/codespaces)。它提供了开箱即用的开发环境，并且与 Github 本身深度集成，可以直接以仓库代码创建 Codespaces 实例。
* 在项目开发以及构建/推送/拉取容器镜像时，可尝试使用 [GitHub Codespaces](https://github.com/features/codespaces)。它提供开箱即用的开发环境，并与 GitHub 深度集成，可直接基于仓库创建 Codespaces 实例。
  * Codespaces 网络环境较优，适合依赖下载与镜像构建/推送/拉取。
  * 普通用户每月提供 **60 小时免费额度**；完成学生认证后通常可获得更高额度。
  * 由于服务器位于海外，国内访问可能延迟较高，建议访问 Codespaces 页面时启用科学上网工具。
  * 推荐流程：本地编码 → Git 推送至 GitHub → 创建 Codespaces → 构建、运行、调试与镜像相关操作。

## 参考选题

### 1. LLM 驱动的搜索引擎

### 2. LLM 驱动的 RAG 知识库

[txtai](https://github.com/neuml/txtai)

[Quivr](https://github.com/QuivrHQ/quivr)

[QAnything](https://github.com/netease-youdao/QAnything)

[LlamaIndex](https://github.com/run-llama/llama_index)

[AutoRAG](https://github.com/Marker-Inc-Korea/AutoRAG)

[OpenViking](https://github.com/volcengine/OpenViking)

### 3. LLM 驱动的编码助手

[OpenCode](http://github.com/anomalyco/opencode/)

[Crush](https://github.com/charmbracelet/crush)

[Open-SWE](https://github.com/langchain-ai/open-swe)

[Codebuff](https://github.com/CodebuffAI/codebuff)

[OpenHands](https://github.com/OpenHands/OpenHands)

[Cline](https://github.com/cline/cline)

[Roo Code](https://github.com/RooCodeInc/Roo-Code)

[DeepCode](https://github.com/HKUDS/DeepCode)

### 4. LLM 驱动的 PPT 生成器

[Presenton](https://github.com/presenton/presenton)

[ALLWEONE](https://github.com/allweonedev/presentation-ai)

[LandPPT](https://github.com/sligter/LandPPT)

[Slidev](https://github.com/slidevjs/slidev)

[PPTAgent](https://github.com/icip-cas/PPTAgent)

[Infographic](https://github.com/antvis/Infographic)

### 5. LLM 驱动的 AI 虚拟助手/数字人

[Project AIRI](https://github.com/moeru-ai/airi)

[Luna AI](https://github.com/Ikaros-521/AI-Vtuber)

[Open-LLM-VTuber](https://github.com/Open-LLM-VTuber/Open-LLM-VTuber)

[Project N.E.K.O.](https://github.com/Project-N-E-K-O/N.E.K.O)

[Persona Engine](https://github.com/fagenorn/handcrafted-persona-engine)

## 学习资源

#### 大模型应用开发

[动手学大模型应用开发](https://datawhalechina.github.io/llm-universe)

[提示工程与大语言模型应用开发](https://apxml.com/zh/courses/prompt-engineering-llm-application-development)

[开发LLM代理高级工具](https://apxml.com/zh/courses/building-advanced-llm-agent-tools)

[设计与实现多智能体大型语言模型系统](https://apxml.com/zh/courses/multi-agent-llm-systems-design-implementation)

[检索增强生成 (RAG) 入门](https://apxml.com/zh/courses/getting-started-rag)

[大型语言模型应用高级向量检索](https://apxml.com/zh/courses/advanced-vector-search-llms)

[生产环境中RAG系统的优化](https://apxml.com/zh/courses/optimizing-rag-for-production)

[Agent Skills](https://agentskills.io/home)

[Context Engineering Template](https://github.com/coleam00/context-engineering-intro)

[鱼皮的 AI 知识库](https://github.com/liyupi/ai-guide)

[一人公司](https://github.com/cyfyifanchen/one-person-company)

#### Vibe Coding

[Easy Vibe](https://datawhalechina.github.io/easy-vibe/)

[Vibe Vibe](https://www.vibevibe.cn/)

[Vibe Coding 指南](https://github.com/2025Emma/vibe-coding-cn)

[Vibe Kanban](https://github.com/BloopAI/vibe-kanban)

---

---
url: https://ain.hmgf.hxcn.space/event/timu/G.md
---
# 项目 G：算法刷题

正确率达到75%即可，请注意账户名称需要实名。

<https://vjudge.net/contest/788780#overview>
密码：welovenanami

[使用教程](https://ain.hmgf.hxcn.space/guides/virtual-judge-guide)

---

---
url: https://ain.hmgf.hxcn.space/software.md
description: 按类别整理的常用软件安装、配置与使用教程，涵盖办公、设计、开发、科学计算与系统工具。
---

# 软件资源

---

---
url: https://ain.hmgf.hxcn.space/software/pdf-watermark-removal-guide.md
description: >-
  针对 PDF 中顽固的图片水印（XObject），从图形界面工具到命令行脚本，提供 PDFelement、PDFPatcher、Adobe Acrobat
  Pro、Python 等多种批量去除方案。
---

# PDF 批量去水印完全指南

PDF 文档中的水印种类繁多——文字水印、图片水印、半透明背景水印、表单层水印——其中**每页两张图片水印**是最难处理的一类。常规的"移除水印"功能往往识别不到这类嵌入式 XObject 图像，需要借助更底层的工具。

本文按**操作难度递增**的顺序，介绍四种行之有效的方案。

::: tip 适用场景
本文主要针对**图片水印（XObject）**，即每页固定位置叠加的半透明或不透明图像。如果你的水印是纯文字层或背景色块，部分工具的"一键移除"功能即可解决，无需走到后面的高级方案。
:::

## 方案一：PDFelement（推荐入门用户）

[PDFelement（万兴 PDFelement）](https://masuit.org/1452?kw=PDFelement) 提供了图形化的批量处理界面，适合不想接触命令行的用户。

### 批量移除水印步骤

1. 打开 PDFelement，点击顶部菜单 **工具 > 批次 PDF**。
2. 选择 **水印**（或"浮水印"）选项。
3. 添加多个 PDF 文件（或整个文件夹）。
4. 选择 **移除水印** 操作，设置输出文件夹。
5. 点击 **套用** 或开始处理，即可批量完成。

### 单文件快速移除

打开文件 → **编辑** → **水印** → **移除水印**。

### 优缺点

| 维度 | 说明 |
|------|------|
| 优点 | 操作简单、保留排版较好，支持文字 / 图像水印 |
| 缺点 | 完整版需付费（有试用期）；对非标准嵌入的 XObject 图片水印可能识别不到 |

::: warning 注意
如果你的水印是"每页两张图片"且常规移除无效，请直接跳转到方案二或方案三。
:::

### 类似工具

**福昕 PDF 编辑器（Foxit PDF Editor）** 也支持批量删除水印，操作路径类似：**页面管理 > 水印 > 全部移除**。

### 软件下载

* PDFelement：https://masuit.org/1452?kw=PDFelement
* Adobe Acrobat PRO：https://masuit.org/2252?kw=Adobe%20Acrobat%20PRO

## 方案二：PDFPatcher（PDF 补丁丁）—— 国产免费神器

[PDFPatcher（PDF 补丁丁）](https://github.com/wmjordan/PDFPatcher) 是一款国产免费开源工具，对图片水印支持极好，能精确删除指定 XObject 对象。这是处理顽固图片水印的**首选方案**。

### 操作步骤

1. 下载安装最新版 PDFPatcher（GitHub 或官网获取）。
2. 打开目标 PDF 文件。
3. 在左侧 **文档结构** 面板中，展开当前页的 **Resources → XObject**。
4. 逐个点击查看图像对象（如 `Im0`、`fzImg0` 等），找到水印图片对应的对象（通常不是正文图片）。
5. 选中水印对象 → 右键或工具栏 **删除**（或使用"删除指令段"功能）。
6. **批量处理**：使用"批处理"或"文档处理"功能，将同一删除操作应用到所有页面或多个文件。

### 适用场景

| 水印类型 | 效果 |
|----------|------|
| 图片水印（XObject） | 精准删除，可视化预览 |
| 文字水印（Contents 流） | 可用"删除指令段"功能 |
| 透明叠加层 | 需配合结构分析 |

### 优点

* 完全免费、开源
* 可视化预览每个图像对象
* 几乎能处理 99% 的图片水印
* 支持批量操作

## 方案三：Python 脚本批量处理（推荐开发者）

如果需要处理大量文件，或者水印特征有规律（如每页最后 N 个图像），用脚本自动化是最高效的方式。

### 使用 PyMuPDF（推荐）

PyMuPDF（fitz）是最强大的 PDF 图像操作库，能精确删除指定图像。

**安装**：

```bash
pip install pymupdf
```

**批量删除水印脚本**：

```python
import fitz  # PyMuPDF
from pathlib import Path

def remove_watermark_images(input_pdf, output_pdf, keep_first_n=1):
    """删除每页 keep_first_n 个之后的所有图像（假设水印在末尾）"""
    doc = fitz.open(input_pdf)
    for page in doc:
        img_list = page.get_images(full=True)
        # 保留前 keep_first_n 个图像，删除后面的（水印）
        for img in img_list[keep_first_n:]:
            try:
                page.delete_image(img[0])  # img[0] 是 xref
            except Exception:
                pass
    doc.save(output_pdf, garbage=4, deflate=True, clean=True)
    doc.close()

def batch_remove_watermarks(input_dir, output_dir, keep_first_n=1):
    """批量处理文件夹中的所有 PDF"""
    input_path = Path(input_dir)
    output_path = Path(output_dir)
    output_path.mkdir(parents=True, exist_ok=True)

    for pdf_file in input_path.glob("*.pdf"):
        output_file = output_path / pdf_file.name
        print(f"处理: {pdf_file.name}...")
        remove_watermark_images(str(pdf_file), str(output_file), keep_first_n)
        print(f"  完成: {output_file}")

# 单文件处理
remove_watermark_images("input.pdf", "output_no_watermark.pdf", keep_first_n=1)

# 批量处理
# batch_remove_watermarks("./input_pdfs", "./output_pdfs", keep_first_n=1)
```

### 使用 PyPDF2

适合简单的 XObject 删除场景：

```python
import PyPDF2

reader = PyPDF2.PdfReader('input.pdf')
writer = PyPDF2.PdfWriter()

for page in reader.pages:
    resources = page.get('/Resources')
    if resources and '/XObject' in resources:
        xobj = resources['/XObject']
        keys = list(xobj.keys())
        # 删除最后一个图像对象（常见水印位置）
        if keys:
            xobj.pop(keys[-1])
    writer.add_page(page)

with open('output.pdf', 'wb') as f:
    writer.write(f)
```

### 进阶技巧

* **按尺寸过滤**：先用 `page.get_images(full=True)` 打印图像信息，根据宽高或位置过滤水印。
* **按位置过滤**：使用 `page.get_image_rects(xref)` 获取图像位置坐标，水印通常在固定位置（如页面中央或四角）。
* **处理 Contents 流**：更复杂的水印（如矢量绘制的水印）需要结合正则表达式清理页面 Contents 流中的绘图指令。

::: tip 建议
先用单页测试脚本效果，确认水印被正确移除且正文图片完好后，再批量运行。使用 `garbage=4` 和 `clean=True` 参数可以减小输出文件体积。
:::

## 方案四：Adobe Acrobat Pro

[Adobe Acrobat Pro](https://masuit.org/2252?kw=Adobe%20Acrobat%20PRO) 是专业级 PDF 工具，对标准水印支持较好，但对非标准嵌入的图片水印效果有限。

### 方法 A：一键批量移除（先试这个）

1. 打开 Acrobat Pro。
2. 转到 **查看所有工具** → **编辑 PDF**。
3. 在左侧编辑窗格中，找到 **水印** → 点击 **移除**。
4. 点击 **添加文件** → 添加多个 PDF（支持批量）。
5. 确认后点击 **确定**，设置输出文件夹 → 开始处理。

如果提示"未找到水印"或去不干净，继续下面的方法。

### 方法 B：手动删除图片水印

1. 打开单个 PDF（先测试一页）。
2. 切换到 **编辑 PDF** 工具。
3. 点击 **更多** → **编辑对象**。
4. 在页面上点击选中水印图片（出现蓝色边框）。
5. 按 Delete 键删除。

### 方法 C：动作向导批量处理

1. 工具 → **动作向导** → **新建动作**。
2. 添加步骤：**页面 > 删除水印** + **保存和导出 > 保存**。
3. 保存动作 → 运行批量处理。

### 方法 D：Preflight 移除指定对象（最强批量）

1. 工具 → **打印生产** → **Preflight**。
2. 搜索 "Remove all images" 或创建自定义 Fixup（根据大小 / 位置过滤）。
3. 运行后可批量应用到多个文件。

### 方法 E：PitStop 插件（专业级）

如果有 PitStop Pro 插件，可以新建动作 → 选择包含特定特征的对象（位置、大小、颜色）→ 移除。可实现真正全自动批量处理，效果最好。

::: warning 注意
Acrobat Reader（免费版）无法编辑或移除水印，必须使用 Pro 版。
:::

## 方案对比

| 工具 | 费用 | 批量支持 | 图片水印 | 难度 | 推荐场景 |
|------|------|----------|----------|------|----------|
| PDFelement | 付费（有试用） | 支持 | 一般 | 低 | 入门用户、标准水印 |
| PDFPatcher | 免费开源 | 支持 | 极好 | 中 | 图片水印首选 |
| Python 脚本 | 免费 | 极好 | 极好 | 高 | 开发者、大批量处理 |
| Acrobat Pro | 付费 | 支持 | 一般 | 中 | 已有订阅的用户 |
| PitStop 插件 | 付费 | 极好 | 极好 | 高 | 印刷级专业需求 |

## 在线工具（快速但注意隐私）

以下在线工具支持上传 PDF 后分析页面、选择水印并批量处理：

* PDF365
* LightPDF
* douyacun

::: danger 隐私提醒
在线工具会将你的文件上传到服务器。**大文件或包含敏感信息的文档不推荐使用在线方案**。优先选择本地工具。
:::

## 通用注意事项

1. **先测试单页**：用任何方案处理一页，确认水印去掉且正文完好后再批量操作。
2. **水印类型影响效果**：文字水印、图像水印、背景水印、表单水印需要不同的处理方式。
3. **检查排版完整性**：移除后建议逐页快速浏览，确认内容和排版没有被破坏。
4. **合法使用**：仅用于自己有权限的文档（如自己添加的水印或已授权的文件）。

## 相关资源

* [Adobe Acrobat PRO 下载](https://masuit.org/2252?kw=Adobe%20Acrobat%20PRO)
* [PDFelement 下载](https://masuit.org/1452?kw=PDFelement)
* [PDFPatcher GitHub 仓库](https://github.com/wmjordan/PDFPatcher)
* [PyMuPDF 官方文档](https://pymupdf.readthedocs.io/)

---

---
url: https://ain.hmgf.hxcn.space/software/photoshop-2025-installation.md
description: Adobe Photoshop 2025 完整安装教程，包含下载、安装、激活以及解决未授权弹窗问题的详细步骤。
---

# Adobe Photoshop 2025 安装指南

## 下载

网盘链接
链接：https://www.123865.com/s/GoDdjv-LjcUA?pwd=THFn#

提取码：THFn

右键**Adobe.Photoshop.2025.Multilingual.iso**，选择“**下载**”

如果下载太慢，可以尝试更换网路环境后重新安装。

也可以从果核剥壳下载：https://www.ghxi.com/ps2025.html。

想要下载Adobe其他软件（如 Pr、Ae、Ai、Dw等），可以访问：

## 解压

下载完成后，右键镜像选择“**装载**”

![image-20250317150140628](https://gastigado.cnies.org/d/public/image-20250317150140628.webp)

也可以解压安装镜像，建议使用 [360 压缩（https://yasuo.360.cn））](https://yasuo.360.cn) 或 [7Zip（https://www.7-zip.org）](https://www.7-zip.org) 进行解压：

![image-20250317095042108](https://gastigado.cnies.org/d/public/image-20250317095042108.webp)

## 安装

右键**autoplay.exe**，选择“**以管理员身份运行**”

![image-20250317150216235](https://gastigado.cnies.org/d/public/image-20250317150216235.webp)

点击“**是**”

![image-20250317150317785](https://gastigado.cnies.org/d/public/image-20250317150317785.webp)

点击“**Install**”

![image-20250317150419540](https://gastigado.cnies.org/d/public/image-20250317150419540.webp)

可以根据需求修改安装位置，然后点击“**继续**”

![image-20250317150453996](https://gastigado.cnies.org/d/public/image-20250317150453996.webp)

稍等片刻，安装完成。点击“**启动**”测试安装是否成功：

![image-20250317150806551](https://gastigado.cnies.org/d/public/image-20250317150806551.webp)

成功安装

![image-20250317150849483](https://gastigado.cnies.org/d/public/image-20250317150849483.webp)

![image-20250317150909814](https://gastigado.cnies.org/d/public/image-20250317150909814.webp)

## 解决弹窗提示未授权

![84b553a9d32f708e4cca04b7774ab7b54638380](https://gastigado.cnies.org/d/public/84b553a9d32f708e4cca04b7774ab7b54638380.webp)

使用过程中尤其是科学上网环境很有可能出现这个弹窗。可以将Photoshop.exe和Adobe Creative Cloud Experience添加到防火墙。

在搜索框中搜索**高级安全WindowsDefender防火墙**

![PixPin\_2025-03-23\_14-39-17](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-39-17.webp)

选择出站规则，然后新建规则

![PixPin\_2025-03-23\_14-42-02](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-42-02.webp)

类型选择程序，将**C:\Program Files\Adobe\Adobe Creative Cloud Experience\CCXProcess.exe**和**C:\Program Files\Adobe\Adobe Photoshop 2025\Photoshop.exe**分别添加（如果没有安装到默认位置请根据自己实际情况修改），选择阻止连接即可。

![PixPin\_2025-03-23\_14-48-07](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-48-07.webp)

![PixPin\_2025-03-23\_14-48-19](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-48-19.webp)

![PixPin\_2025-03-23\_14-48-32](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-48-32.webp)

![PixPin\_2025-03-23\_14-48-42](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-48-42.webp)

![PixPin\_2025-03-23\_14-49-16](https://gastigado.cnies.org/d/public/PixPin_2025-03-23_14-49-16.webp)

也可以参考网上其他教程：

* https://www.bilibili.com/opus/736789643953963185
* https://www.bilibili.com/opus/920231330556411922
* https://www.bilibili.com/opus/850403881119645704

---

---
url: https://ain.hmgf.hxcn.space/software/blender-installation.md
description: 从清华大学开源软件镜像站下载安装 Blender，国内网络环境下速度更快。
---

# Blender 安装教程

清华大学开源软件镜像站（TUNA）完整同步了 Blender 的官方 release 版本，下载速度比 blender.org 快很多。

## 找到最新版本

打开 https://mirrors.tuna.tsinghua.edu.cn/blender/blender-release/，你会看到多个版本文件夹（Blender4.2/、Blender5.0/ 等）。编号最大的文件夹通常是最新稳定版。

进入最新版本文件夹后，根据操作系统选择安装包：

| 操作系统 | 推荐文件 | 说明 |
|---------|---------|------|
| Windows | `blender-×××-windows-x64.msi` | 安装版，更干净 |
| Windows | `blender-×××-windows-x64.zip` | 便携版，无需安装 |
| macOS | `blender-×××-macos-arm64.dmg` | Apple Silicon 芯片 |
| Linux | `blender-×××-linux-x64.tar.xz` | 解压即用 |

点击文件名开始下载，通常几分钟到十几分钟完成。

## Windows 安装

双击 `.msi` 文件启动安装向导，一路点 Next 即可。可以勾选创建桌面快捷方式、关联 `.blend` 文件。安装路径建议保持默认 `C:\Program Files\Blender Foundation\Blender ×××\`。

如果下载的是 `.zip` 便携版，右键解压到任意文件夹（如 `D:\Tools\Blender`），进入解压目录双击 `blender.exe` 启动。

## macOS 安装

双击 `.dmg` 文件，把 Blender 图标拖到「应用程序」文件夹。首次启动可能提示"来自身份不明开发者"，右键点击图标选择「打开」→「仍要打开」即可。

## Linux 安装

打开终端，进入下载目录：

```bash
cd ~/Downloads
tar -xvf blender-*-linux-x64.tar.xz
cd blender-*-linux-x64
./blender
```

如果想在任何目录下直接输入 `blender` 启动，可以创建软链接：

```bash
sudo ln -s $(pwd)/blender /usr/local/bin/blender
```

或者把整个文件夹移动到 `/opt/blender/` 等常用位置。

## 常见问题

**如何确认是最新版？** 对比官网 https://www.blender.org/download/ 的版本号。

**下载很慢或连不上？** 尝试换域名：

* `https://mirrors4.tuna.tsinghua.edu.cn/blender/`（纯 IPv4）
* `https://mirrors6.tuna.tsinghua.edu.cn/blender/`（纯 IPv6）

**如何切换中文界面？** 启动 Blender → Edit → Preferences → Interface → Translation → 勾选 Chinese（简体中文）→ 重启。

**便携版和安装版如何选择？** 便携版适合 U 盘携带、多版本共存；安装版适合长期使用，文件关联更方便。

---

---
url: https://ain.hmgf.hxcn.space/software/blender-addon-installation.md
description: Blender 插件安装方法、常用插件推荐与故障排查。
---

# Blender 插件安装教程

Blender 4.2 以后，插件分为两类：**扩展（Extensions）** 和 **旧式插件（Legacy Add-ons）**。扩展在 Preferences → Get Extensions 中管理，旧式插件在 Preferences → Add-ons 中安装。

## 安装方法

### 扩展安装（Blender 4.2+）

1. 打开 Blender → Edit → Preferences → Get Extensions
2. 搜索插件名，点击安装
3. 若扩展声明需要网络或文件权限，按提示确认

如果 Get Extensions 无法连接远程仓库，可以从其他渠道下载扩展的 `.zip` 包，点击右上角下拉菜单选择 Install from Disk 离线安装。

### 旧式插件安装

1. 下载插件的 `.zip` 或 `.py` 文件
2. 打开 Edit → Preferences → Add-ons
3. 点击右上角下拉菜单 → Install from Disk
4. 选择下载的文件
5. 安装后在列表中勾选启用（不会自动启用）

安装完成后记得保存偏好设置。

### 插件存放位置

**Windows**

`%APPDATA%\Blender Foundation\Blender\<版本>\scripts\addons`

**macOS**

`/Users/<用户名>/Library/Application Support/Blender/<版本>/scripts/addons`

macOS 的 Library 目录默认隐藏，在 Finder 的"前往"菜单按住 `Option` 键可以显示。

### CLI 批量安装

机房环境或需要批量部署时，可以用 Python 脚本：

```python
import bpy

ZIP_PATH = r"/path/to/addon.zip"
MODULE = "addon_module_name"

bpy.ops.preferences.addon_install(filepath=ZIP_PATH, overwrite=True)
bpy.ops.preferences.addon_enable(module=MODULE)
bpy.ops.wm.save_userpref()
```

## 常用插件推荐

| 类别 | 插件 | 功能 |
|------|------|------|
| 按键显示 | Screencast Keys | 视窗叠加显示键盘鼠标输入，适合录教程 |
| 快捷键 | Pie Menu Editor | 自定义 Pie 菜单和面板 |
| 渲染 | Flamenco | Blender Studio 出品的渲染农场管理 |
| 建模 | LoopTools | Bridge、Relax、Space 等常用建模工具 |
| 节点 | Node Wrangler | 节点编辑效率工具 |
| 资产库 | BlenderKit | 在线资产库，模型/材质/HDRI |
| UV | UV Squares | 把 UV 四边形规整为网格 |
| UV | TexTools | UV 和贴图工具集 |
| 参数化 | Sverchok | 节点式参数化建模 |
| 地理 | BlenderGIS | GIS 数据和地形导入 |
| 动画 | Animation Nodes | 节点式动画系统 |
| 导出 | Send to Unreal | 一键发送到 Unreal Engine |
| 导出 | glTF 2.0 | glTF/GLB 导入导出 |

LoopTools 和 Node Wrangler 是 Blender 内置插件，在 Add-ons 中搜索勾选启用即可。

## Screencast Keys 详细安装

Screencast Keys 是最常用的按键显示插件，已进入扩展平台。

### 选择正确版本

* Blender 4.2 及以上：使用扩展版本
* Blender 4.1 及以下：使用 3.14 系列旧版本

### Blender 4.2+ 安装

1. Edit → Preferences → Get Extensions
2. 搜索 "Screencast Keys"，点击安装
3. 若网络不通，下载扩展 zip 后选择 Install from Disk

### Blender 4.1 及以下安装

1. 从 GitHub 下载对应版本的 `.zip`
2. Preferences → Add-ons → Install from Disk
3. 选择 zip 文件，安装后勾选启用

### 启用与配置

默认快捷键 `Shift + Alt + C` 可以快速开关显示。

也可以从 3D 视图侧栏（N 面板）启动。

推荐配置：

* 位置放在左下或右下角，避开常用 UI
* 字体大小调到录屏分辨率下可读
* 开启半透明背景或阴影
* 打开鼠标按键和滚轮显示

### 自定义快捷键

在 Preferences → Keymap 中搜索 "Screencast Keys"，找到原始绑定后改成习惯的组合。

## 故障排查

### 插件装了找不到

Blender 4.2+ 后部分内置插件迁移到扩展平台，检查是否需要在 Get Extensions 中安装。确认插件类型，扩展和旧式插件在不同页面管理。

### 安装后无法启用

常见原因：旧版本残留、zip 结构不正确。先在 Preferences 中卸载旧版本，检查插件目录是否有残留同名文件夹，重新安装后重启 Blender。

### 启用后报错 ModuleNotFoundError

插件缺少 Python 依赖。在 Blender 的系统控制台查看具体缺哪个模块。确认使用 Blender 内置 Python 安装依赖，不要装到系统 Python。

### Get Extensions 无法同步

网络问题。最简单的解决方案是用离线 zip 安装。

### macOS 提示无法验证开发者

如果插件被标记了隔离属性，在终端执行：

```bash
xattr -dr com.apple.quarantine ~/Downloads
```

仅对信任的文件执行此操作。

### Safari 自动解压 zip

Safari 可能自动解压并删除 `.zip`，导致无法从 zip 安装。在 Safari 偏好设置中关闭"下载后自动解压"，或重新压缩解压后的文件夹。

---

---
url: https://ain.hmgf.hxcn.space/software/matlab-2024b-installation.md
description: MATLAB 2024b 完整安装教程，包含下载、安装、激活步骤，以及 Windows 10 及更旧系统的兼容性说明。
---

# MATLAB 2024b 安装教程

## 下载解压

123网盘

先注册123网盘：https://login.123pan.com/centerlogin?register=invite\&ref=GoDdjv

然后访问下面链接进行下载：

链接：https://www.123865.com/s/GoDdjv-RJcUA?pwd=GNw7#

提取码：GNw7

我们下载最新的 MATLAB 2024b（如 **R2024b\_Windows.iso**），同时下载 R2024b\_Crack.zip。耐心等待下载完成后使用 **7-Zip** 或 **360 压缩**进行**解压**。

> Matlab 2024b 是在 2024a 基础上的后续版本，通常会修复 2024a 中存在的一些已知问题。
> 同时，2024b 还可能引入新的函数、工具包或对现有功能进行增强与改进，相比 2024a 具备更丰富的功能和更好的性能。

**如果你正在使用 Windows 10 或者更旧版本的系统，2024b 可能会出现许可证失败，请安装 2024a 或 2023b，安装方法和 2024a 相同。（感谢网友70提供的思路）**
链接：https://www.123865.com/s/GoDdjv-tULUA?pwd=ZSNs#

提取码：ZSNs

## 安装 MATLAB

进入 **R2024b\_Windows** 文件夹，以管理员身份运行 **setup.exe**

![image-20250304094646273](https://gastigado.cnies.org/d/public/image-20250304094646273.webp)

点击“高级选项” -> “我有文件安装密钥”：

![image-20250304094824136](https://gastigado.cnies.org/d/public/image-20250304094824136.webp)

接受许可协议的条款然后下一步：

![image-20250304094857220](https://gastigado.cnies.org/d/public/image-20250304094857220.webp)

打开 **R2024b\_Crack\Readme.txt**，根据需求复制密钥。默认选择完整安装的密钥即可。

```
39676-02743-14813-63132-22122-21739-42724-01237-08353-51560-41813-30272-46436-42021-53831-05395-21684-43572-58789-40638-42099-40160-19797-60670-44428-39867
```

点击浏览，选择 R2024b\_Crack\license.lic 许可证，然后下一步：

![选择许可证文件](https://gastigado.cnies.org/d/public/image-20250304095204193.webp)

选择一个安装位置。MATLAB 通常占用 20G 左右空间，建议安装在空间充足的位置。

![选择安装位置](https://gastigado.cnies.org/d/public/image-20250304095340990.webp)

默认全部选择即可。

![image-20250304100617049](https://gastigado.cnies.org/d/public/image-20250304100617049.webp)

可以选择创建桌面快捷方式，下一步然后等待安装完成。

## 激活

右键 MATLAB 桌面快捷方式，**打开文件所在位置**。

![image-20250304103059644](https://gastigado.cnies.org/d/public/image-20250304103059644.webp)

依次选择文件夹 **win64\matlab\_startup\_plugins\lmgrimpl**，将 R2024b\_Crack 中的 **libmwlmgrimpl.dll** 复制到这里，替换掉原文件：

![image-20250304103523219](https://gastigado.cnies.org/d/public/image-20250304103523219.webp)

然后运行 MATLAB，出现下面页面，证明激活成功。

![image-20250304103653978](https://gastigado.cnies.org/d/public/image-20250304103653978.webp)

---

---
url: https://ain.hmgf.hxcn.space/software/win11-clean-flash-4399.md
description: >-
  面向 Windows 11 用户的 4399 Flash 游戏游玩指南，对比 CefFlashBrowser 与 Clean Flash Player +
  Edge IE 模式两种方案，包含下载、安装、兼容设置与常见问题。
---

# Windows 11 怎么玩 4399 Flash 小游戏？两种干净办法！

现在想在 Windows 11 上玩一些老的 4399 Flash 小游戏，最大的问题不是“有没有游戏”，而是“用什么东西打开它”。Flash Player 早就停服了，很多人又不想装带广告、带弹窗、带额外捆绑的国内特供版。

![img](https://gastigado.cnies.org/d/public/v2-073372ade5402fc2bd4644be44179297_1440w.webp)

![img](https://gastigado.cnies.org/d/public/1732499991_446934.webp)

本文就讲两种相对干净、好上手的办法：

1. 直接用**自带 Flash 插件**的 **CefFlashBrowser**，它最省事，下载、解压、打开就能用。如果你只是想今晚就把游戏玩上，直接选 **CefFlashBrowser**，过程对小白很友好。
2. 如果你更想继续在 **Edge 浏览器** 里打开老网页，或者你想把“网页兼容模式”这套环境配起来，再选 **Clean Flash Player + Edge IE 模式**。

整篇都按 Windows 11 小白能照着点的方式来写。你不用两种都装，先选一种最适合自己的就行。

## 注意

1. 这两种方法都只适合打开老的 Flash 网页或 `.swf` 文件，不适合拿来随便运行来路不明的文件。
2. 如果某个 4399 游戏页面本身已经被下线、删库，播放器装好了也打不开。
3. 你的电脑如果是普通 Windows 11 64 位笔记本，下载时一般优先选 `x64` 版本。
4. 两种方法都建议先把浏览器关掉再装，省得插件没装进去。

## 方法一：CefFlashBrowser 专用Flash浏览器

这个方案直接使用自带Flash Player插件的专属浏览器，不用修改任何系统/浏览器设置，解压就能用，还支持游戏存档管理，是对小白最友好的方案。

### 步骤1：下载官方最新安装包

先打开官方发布页：

1. 页面往下滑，进入最新正式版的下载区

![image-20260328193322063](https://gastigado.cnies.org/d/public/image-20260328193322063.webp)

2. 在最新版本的下载区，**绝对不要下载Source code（源码包）**，直接选择名称带`win-x64`的压缩包（Windows11都是64位系统，选这个100%适配），点击下载

![image-20260328193353469](https://gastigado.cnies.org/d/public/image-20260328193353469.webp)

3. 补充：如果 GitHub 页面打不开，也可以使用蓝奏云备用下载：

\<DownloadTabs
title="网盘下载"
:providers="\[
{ value: 'lanzou', label: '蓝奏云', }
]"

>

\<template #default="{ provider }">






### 步骤2：解压软件&首次启动

1. 找到下载好的压缩包，右键点击，选择【全部解压】
2. **重点必看**：解压路径不能有中文、空格、特殊符号（比如不要解压到桌面、下载文件夹里的中文命名文件夹），建议直接解压到D盘根目录，比如`D:\CefFlashBrowser`，避免软件打不开、出现乱码

![image-20260328194404094](https://gastigado.cnies.org/d/public/image-20260328194404094.webp)

3. 解压完成后，打开解压后的文件夹，找到名为`CefFlashBrowser.exe`的程序，**双击就能打开软件，全程不用安装**

![image-20260328194603917](https://gastigado.cnies.org/d/public/image-20260328194603917.webp)

4. 首次启动如果弹出Windows防火墙提示，直接勾选【专用网络】和【公用网络】，点击【允许访问】即可

### 步骤3：一键畅玩4399 Flash小游戏

1. 打开软件后，顶部就是网址输入栏，直接输入4399官网地址`www.4399.com`，按回车键进入网站

![image-20260328194639266](https://gastigado.cnies.org/d/public/image-20260328194639266.webp)

![image-20260328194655913](https://gastigado.cnies.org/d/public/image-20260328194655913.webp)

2. 找到你想玩的Flash小游戏，点击进入游戏页面，等待加载完成就能直接玩，**不用额外装任何Flash插件**
3. 常用小白友好功能：
   * 顶部【收藏夹】：可以把常玩的游戏页面收藏，下次直接打开，不用反复搜索
     ![image-20260328194728333](https://gastigado.cnies.org/d/public/image-20260328194728333.webp)
   * 打开本地SWF文件：如果下载了SWF格式的Flash游戏到电脑，点击软件左上角【文件】-【打开文件】，选中对应的SWF文件就能离线玩

### 常见问题

#### 情况 A：提示缺少 `.NET Framework 4.6.2`

去微软官方下载页面安装 `.NET Framework 4.6.2`，装完再试一次。

#### 情况 B：提示 `System.IO.FileNotFoundException`

软件本体没坏，是你电脑里缺少它要用的基础运行环境。这通常是缺少 `Microsoft Visual C++ Redistributable`。安装后再重新打开软件。

## 方法二：Clean Flash Player + Edge浏览器IE兼容模式

这个方案安装纯净无广告的Flash Player，然后通过 **Microsoft Edge 的 IE 兼容模式** 去打开老网页。

注意，这里不是让你安装老版 Internet Explorer 浏览器本体，而是借 **Edge 里的 IE 模式** 来跑兼容内容。不用装额外的浏览器，适合习惯用Edge的同学。

### 步骤1：下载Clean Flash Player官方安装包

先打开官方发布页：

![image-20260328195907052](https://gastigado.cnies.org/d/public/image-20260328195907052.webp)

1. 在最新版本的下载区，选择后缀为`.exe`的安装包（比如`CleanFlashPlayerSetup.exe`），点击下载

![image-20260328195946626](https://gastigado.cnies.org/d/public/image-20260328195946626.webp)

2. 补充：如果 GitHub 页面打不开，也可以使用蓝奏云备用下载：

\<DownloadTabs
title="网盘下载"
:providers="\[
{ value: 'lanzou', label: '蓝奏云', }
]"

>

\<template #default="{ provider }">






### 步骤2：安装纯净版Clean Flash Player

**重点前置操作：安装前必须关闭所有浏览器窗口（Edge、Chrome、Firefox等全部关掉），否则会安装失败**

1. 找到下载好的安装包，右键点击，选择【以管理员身份运行】

![image-20260328202102209](https://gastigado.cnies.org/d/public/image-20260328202102209.webp)

2. 弹出免责声明窗口，直接点击【接受】进入下一步

![image-20260328202151790](https://gastigado.cnies.org/d/public/image-20260328202151790.webp)

3. 到了组件选择页面，**必须勾选「Internet Explorer 插件」**（这是Edge兼容模式能正常用Flash的核心），其他选项推荐全部勾选：

![image-20260328202245250](https://gastigado.cnies.org/d/public/image-20260328202245250.webp)

4. 点击【下一步】，再点击【安装】，等待10-20秒即可完成安装
5. 安装说明：这个安装包会自动卸载电脑里之前装的重橙特供版Flash、Flash游戏大厅等带广告、偷隐私的版本，全程不用手动操作，非常省心
6. 安装完成后点击【退出】，桌面上出现 Flash Player 图标代表安装完成。

### 步骤3：Edge浏览器开启IE兼容模式（核心步骤，一步都不能漏）

1. 打开Windows11自带的Microsoft Edge浏览器
2. 点击浏览器右上角的三个点【设置和其他】，在下拉菜单里找到【设置】，点击进入

![image-20260328202604355](https://gastigado.cnies.org/d/public/image-20260328202604355.webp)

3. 在左侧设置菜单栏里，找到【默认浏览器】，点击进入对应设置页

4. 在默认浏览器页面，找到【允许在 Internet Explorer 模式下重新加载网站】，把下拉选项改成【允许】，然后点击【重启】生效

5. 重启后再次来到【默认浏览器】，然后找到【Internet Explorer 模式页面】，点击旁边的【添加】按钮

6. 在弹出的输入框里，输入`https://*.4399.com`，点击【添加】。设置后所有4399的网站都会自动用IE兼容模式打开，不用每次手动切换

![image-20260328203150156](https://gastigado.cnies.org/d/public/image-20260328203150156.webp)

> 小白补充：如果还有其他Flash游戏网站，也可以用同样的方式添加，比如`https://*.7k7k.com`

7. 添加完成后，**必须完全关闭Edge浏览器，重新打开**，设置才能生效

### 步骤4：用Edge畅玩4399 Flash小游戏

1. 重新打开Edge浏览器，输入4399官网地址`www.4399.com`，按回车键进入

2. 此时网站会自动以IE兼容模式加载，地址栏左侧会出现IE的小图标，说明设置成功

3. 找到你想玩的Flash小游戏，点击进入，等待加载完成就能正常玩了

4. 补充：如果网站没有自动进入IE模式，右键点击页面空白处，选择【在Internet Explorer模式下重新加载】即可

![image-20260328203515288](https://gastigado.cnies.org/d/public/image-20260328203515288.webp)

### 常见问题解决

1. 安装后游戏还是提示没有Flash：先确认步骤3的所有设置都完成，并且重启了Edge浏览器，再检查安装时有没有勾选「Internet Explorer 插件」
2. 找不到IE兼容模式的设置：把Edge浏览器更新到最新版，旧版本Edge的设置位置可能有差异
3. 游戏加载卡顿/黑屏：刷新页面，或者关闭Edge重新打开，确保网络正常
4. 安装失败：确认所有浏览器都已经完全关闭，再右键安装包选择【以管理员身份运行】

---

---
url: https://ain.hmgf.hxcn.space/software/windows-essential-apps.md
---
# 必装软件推荐

Windows 软件生态很丰富，但好用的工具往往藏得很深。这里整理一些经过验证的效率工具，覆盖日常办公、开发、系统管理等场景。

## 效率应用

### 10 款不得不装的 Windows 应用

这 10 款应用都是 GitHub 千星项目，每款都是装机必备。作者分享了工作中最常用的效率神器，包括窗口管理、剪贴板增强、快速启动等工具。这些应用都免费开源，比商业软件更干净。

### 给大一新生的实用 Windows 软件推荐

适合刚接触 Windows 的用户。推荐的软件覆盖学习、办公、娱乐等场景，都是经过验证的实用工具。如果你刚买电脑不知道装什么软件，从这个清单开始不会错。

## 文件管理器

### 六款文件管理器全景指南

Windows 自带的文件管理器功能有限，有很多替代品可选：

**终端文件管理器**

* superfile - 界面美观，Go 语言编写
* Yazi - Rust 编写，速度快，支持预览
* Ranger - Python 编写，Vim 键位，经典选择
* Broot - 模糊搜索强，适合大目录
* nnn - 极简轻量，资源占用低
* lf - Go 编写，跨平台，配置灵活

这个视频把六款文件管理器的特点、优劣、适用场景都讲清楚了。终端用户推荐 Yazi 或 Ranger，图形界面用户可以试试其他选择。

## 系统工具

### Everything - 文件搜索神器

Windows 自带的搜索功能慢得让人崩溃，Everything 完全解决了这个问题。它通过读取 NTFS 文件系统的 USN Journal 实现秒级搜索，百万级文件量也能瞬间出结果。

**核心特性：**

* **实时索引**：首次启动几秒完成全盘索引，后续实时更新
* **体积小巧**：安装包不到 2MB，内存占用约 30MB
* **正则支持**：支持正则表达式和通配符搜索
* **HTTP/FTP 服务器**：可以远程搜索文件

**下载地址：** [voidtools.com](https://www.voidtools.com/zh-cn/)

### PowerToys - 微软官方增强工具集

微软自己出的系统增强工具集，包含几十个实用功能，全部免费开源。适合想提升效率但不想装一堆小工具的用户。

**核心模块：**

* **FancyZones**：窗口分区管理，自定义窗口布局
* **PowerRename**：批量重命名文件，支持正则
* **Color Picker**：全局取色器，快捷键调出
* **Text Extractor**：屏幕 OCR，任意界面提取文字
* **Keyboard Manager**：键盘按键重映射
* **Run**：快速启动器（类似 macOS 的 Spotlight）
* **File Locksmith**：查看哪些进程锁定了文件
* **Paste as Plain Text**：粘贴纯文本，去掉格式

**下载地址：** [GitHub - PowerToys](https://github.com/microsoft/PowerToys)

### 7-Zip - 压缩解压必备

Windows 自带的压缩功能支持格式少，7-Zip 是最佳替代品。免费开源，支持几乎所有压缩格式，压缩率比 WinRAR 高。

**支持格式：**

* 7z、ZIP、GZIP、BZIP2、TAR
* RAR、ARJ、CAB、CHM、CPIO
* DEB、DMG、FAT、HFS、ISO
* LZH、LZMA、MBR、MSI、NSIS
* NTFS、RPM、SquashFS、UDF、VHD
* WIM、XAR、Z、XZ

**下载地址：** [7-zip.org](https://www.7-zip.org/)

### Ditto - 剪贴板增强

Windows 历史剪贴板只能存一条记录，Ditto 能存储无限条。复制过的所有内容都能找回来，支持搜索、分组、合并。

**核心功能：**

* **历史记录**：保存所有复制过的内容
* **搜索**：快速找到之前复制的内容
* **分组管理**：按类型或项目分组
* **快捷粘贴**：自定义快捷键快速调出
* **跨设备同步**：通过网络同步剪贴板

**下载地址：** [ditto-cp.sourceforge.io](https://ditto-cp.sourceforge.io/)

### Snipaste - 截图贴图工具

截图功能虽然 Windows 自带了，但 Snipaste 的体验好太多。截图后可以直接贴在屏幕上，写文档、做对比的时候特别方便。

**核心功能：**

* **智能截图**：自动检测窗口边界
* **贴图功能**：截图后贴在屏幕任意位置
* **标注工具**：矩形、箭头、文字、马赛克
* **取色器**：截图时直接取色
* **历史记录**：所有截图都有记录

**下载地址：** [snipaste.com](https://www.snipaste.com/)

### TrafficMonitor - 网速/硬件监控

在任务栏显示实时网速、CPU 和内存占用，不用切到任务管理器就能看系统状态。轻量级，资源占用极低。

**核心功能：**

* **任务栏嵌入**：直接在任务栏显示信息
* **网速监控**：上传下载实时速度
* **硬件信息**：CPU、内存、温度
* **自定义显示**：选择显示哪些信息
* **皮肤支持**：自定义外观

**下载地址：** [GitHub - TrafficMonitor](https://github.com/zhongyang219/TrafficMonitor)

## 开发工具

### VS Code - 代码编辑器

微软出品的免费代码编辑器，支持几乎所有编程语言。插件生态极其丰富，几乎能替代很多专业 IDE。

**推荐插件：**

* **Chinese Language Pack**：中文语言包
* **GitLens**：Git 增强，查看代码修改历史
* **Error Lens**：行内显示错误，不用看底部状态栏
* **Bracket Pair Colorizer**：括号配对着色
* **Todo Tree**：高亮 TODO/FIXME 注释
* **Remote - SSH**：远程开发
* **Docker**：容器管理

**下载地址：** [code.visualstudio.com](https://code.visualstudio.com/)

### Windows Terminal - 现代终端

微软官方的现代终端工具，支持 PowerShell、CMD、WSL、Azure 等多标签页。支持自定义主题、透明背景、GPU 加速渲染。

**核心特性：**

* **多标签页**：同时打开多个终端
* **GPU 加速**：渲染更快，支持透明效果
* **Unicode/UTF-8**：完美支持中文和 emoji
* **自定义配置**：JSON 配置文件，高度可定制
* **WSL 集成**：直接在 Windows 里用 Linux 终端

**下载地址：** [GitHub - Windows Terminal](https://github.com/microsoft/terminal)

### Git - 版本控制

做开发必备的版本控制工具。Windows 版本自带 Git Bash，提供类 Unix 的命令行环境。

**安装建议：**

* 从 [git-scm.com](https://git-scm.com/) 下载安装
* 安装时选择 VS Code 作为默认编辑器
* 选择"Git from the command line and also from 3rd-party software"
* 行尾转换选"Checkout as-is, commit Unix-style line endings"

**基础配置：**

```bash
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global core.autocrlf true
git config --global core.editor "code --wait"
```

### WSL - Windows 子系统 for Linux

在 Windows 里运行 Linux 环境，不用开虚拟机。做开发的必备工具，特别是需要 Linux 环境但又不想切换系统的场景。

**安装方法：**

```powershell
# 管理员权限打开 PowerShell
wsl --install

# 安装特定发行版
wsl --install -d Ubuntu-24.04
```

**常用命令：**

```bash
# 查看已安装的发行版
wsl --list --verbose

# 进入默认发行版
wsl

# 进入特定发行版
wsl -d Ubuntu-24.04

# 关闭所有发行版
wsl --shutdown
```

## 网络工具

### Chrome - 浏览器

虽然 Windows 自带 Edge，但 Chrome 的扩展生态更丰富。配合账号同步，多设备之间无缝切换。

**推荐扩展：**

* **uBlock Origin**：广告拦截，轻量高效
* **Tampermonkey**：用户脚本管理器
* **沙拉查词**：划词翻译
* **Dark Reader**：网页深色模式
* **Infinity**：新标签页美化
* **GitHunt**：在新标签页展示 GitHub 热门项目

### Clash Verge Rev - 代理工具

开源的代理客户端，界面美观，功能强大。支持多种代理协议，订阅管理方便。

**下载地址：** [GitHub - Clash Verge Rev](https://github.com/clash-verge-rev/clash-verge-rev)

### Motrix - 下载工具

开源的下载工具，支持 HTTP、FTP、BT、磁力链接。界面简洁，速度稳定。

**核心功能：**

* **多线程下载**：最多 64 线程
* **BT/磁力**：支持 BitTorrent 协议
* **断点续传**：网络中断后继续下载
* **批量下载**：导入多个链接同时下载

**下载地址：** [GitHub - Motrix](https://github.com/agalwood/Motrix)

## 办公工具

### Obsidian - 笔记软件

基于 Markdown 的本地笔记软件，所有数据存在本地，不依赖云服务。插件生态极其丰富，几乎能满足所有笔记需求。

**核心优势：**

* **本地存储**：数据完全在自己手里
* **双向链接**：笔记之间可以互相引用
* **知识图谱**：可视化笔记之间的关系
* **插件系统**：社区插件超过 1000 个
* **Markdown**：纯文本格式，不怕软件停服

**下载地址：** [obsidian.md](https://obsidian.md/)

### Typora - Markdown 编辑器

所见即所得的 Markdown 编辑器，写文档特别舒服。支持数学公式、代码高亮、流程图等。

**核心功能：**

* **实时预览**：输入即显示，不用分屏
* **数学公式**：支持 LaTeX 语法
* **代码高亮**：支持 100+ 编程语言
* **导出格式**：PDF、HTML、Word、ePub
* **主题定制**：自定义 CSS 主题

**下载地址：** [typora.io](https://typora.io/)

### LocalSend - 局域网文件传输

开源的跨平台文件传输工具，不用数据线、不用登录账号，局域网内直接传文件。替代各种"XX快传"的最佳选择。

**核心优势：**

* **无需联网**：纯局域网传输
* **跨平台**：Windows、macOS、Linux、Android、iOS
* **无需注册**：打开就能用
* **开源免费**：没有广告，没有限制

**下载地址：** [GitHub - LocalSend](https://github.com/localsend/localsend)

## 安全工具

### Windows Defender - 系统自带

Windows 自带的杀毒软件已经够用了，不需要额外装第三方杀毒软件。资源占用低，病毒库更新及时。

**配置建议：**

* 保持自动更新开启
* 定期运行全盘扫描
* 开启实时保护
* 不要随便关闭防火墙

### BitLocker - 磁盘加密

Windows 专业版自带的磁盘加密工具，保护硬盘数据安全。笔记本电脑特别建议开启，丢了电脑也不怕数据泄露。

**开启方法：**

1. 控制面板 → BitLocker 驱动器加密
2. 选择要加密的驱动器
3. 点击"启用 BitLocker"
4. 备份恢复密钥（很重要！）
5. 等待加密完成

## 相关资源

**软件下载网站：**

* [腾讯软件中心](https://pc.qq.com/) - 国内软件下载
* [AlternativeTo](https://alternativeto.net/) - 找软件替代品
* [GitHub](https://github.com/) - 开源软件
* [Chocolatey](https://chocolatey.org/) - Windows 包管理器
* [Scoop](https://scoop.sh/) - 命令行安装软件

**包管理器推荐：**

用命令行安装软件更干净，不会有捆绑安装。推荐使用 Scoop 或 Chocolatey。

```powershell
# Scoop 安装
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

# 安装软件示例
scoop install git
scoop install nodejs
scoop install python
scoop install 7zip
scoop install everything
```

```powershell
# Chocolatey 安装（管理员权限 PowerShell）
Set-ExecutionPolicy Bypass -Scope Process -Force
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

# 安装软件示例
choco install googlechrome
choco install vscode
choco install 7zip
choco install everything
```

---

---
url: https://ain.hmgf.hxcn.space/software/cli-tools.md
---
# CLI 工具

命令行工具用熟了效率比图形界面高很多。这里整理一些实用的 CLI 工具和使用技巧。

## 包管理器

### winget：Windows 官方包管理器

Windows 从 WinGet 开始有了自己的包管理器，只是很多人还不知道。一条命令就能批量安装软件，比一个个去官网下载方便得多。

重装系统最烦的就是重新装软件。用 winget 可以导出已安装软件列表，然后一键恢复：

```powershell
# 导出已安装软件列表
winget export -o ~/software-list.json

# 从列表批量安装
winget import -i ~/software-list.json
```

日常使用场景：

```powershell
# 搜索软件
winget search chrome

# 安装软件
winget install Google.Chrome

# 安装指定版本
winget install Python.Python.3.11 --version 3.11.4

# 更新所有软件
winget upgrade --all

# 更新指定软件
winget upgrade Google.Chrome

# 查看已安装软件
winget list

# 卸载软件
winget uninstall Google.Chrome
```

winget 的软件源是 community repository，主流软件基本都有。如果遇到找不到的软件，可以手动添加第三方源：

```powershell
# 查看已添加的源
winget source list

# 添加第三方源
winget source add --name "msstore" --arg "https://storeedgefd.dsx.mp.microsoft.com/v9.0"
```

### scoop：开发者最爱的 Windows 包管理器

如果说 winget 是给普通用户用的，scoop 就是给开发者设计的。它把软件装在用户目录下，不污染系统 PATH，也不需要管理员权限。

```powershell
# 安装 scoop
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
 irm get.scoop.cc | iex

# 添加常用 bucket
scoop bucket add extras
scoop bucket add versions

# 安装软件
scoop install git nodejs python

# 更新所有软件
scoop update *

# 查看软件信息
scoop info git
```

scoop 的 bucket 系统很灵活，extras 里有大量开发工具。遇到官方没有的软件，可以自己写 manifest 提交。

### Homebrew：macOS/Linux 必备

macOS 用户基本都知道 Homebrew，Linux 上也好用：

```bash
# 安装软件
brew install node

# 安装 GUI 应用
brew install --cask visual-studio-code

# 更新
brew update && brew upgrade

# 清理旧版本
brew cleanup

# 查看依赖关系
brew deps --tree node
```

## 命令行帮助

### tldr：命令行速查手册

man 页面太长太详细，tldr 只列出最常用的用法，查起来快很多：

```bash
# 安装 tldr（任选一种方式）
npm install -g tldr
pip install tldr
brew install tldr

# 查询命令用法
tldr tar

# 更新缓存
tldr --update
```

比如 `tar` 命令的参数那么多，tldr 直接给你最常用的几种：

```
tar

Archiving utility.

- Create a tar archive from files:
  tar cf target.tar file1 file2

- Create a gzipped archive:
  tar czf target.tar.gz file1 file2

- Extract a tar archive:
  tar xf source.tar

- Extract a gzipped archive:
  tar xzf source.tar.gz
```

### cheat：交互式速查表

比 tldr 更进一步，cheat 允许你创建自己的速查表：

```bash
# 安装
brew install cheat

# 查看速查表
cheat tar

# 编辑速查表
cheat -e tar

# 搜索速查表
cheat -s docker
```

## 文件和文本处理

### ripgrep (rg)：比 grep 快 10 倍

ripgrep 是 grep 的现代替代品，默认递归搜索、忽略 .gitignore 里的文件、支持正则：

```bash
# 搜索文件内容
rg "TODO" 

# 指定文件类型
rg "function" --type js

# 正则搜索
rg "\d{3}-\d{4}" 

# 显示上下文（前后各 3 行）
rg "error" -C 3

# 只显示文件名
rg -l "import React"

# 替换预览
rg "old_name" --replace "new_name"
```

### fd：比 find 更友好

`find` 命令的语法出了名的难记，fd 用更直觉的方式搜索文件：

```bash
# 按名字搜索
fd "config"

# 按扩展名
fd -e js

# 指定目录
fd "test" src/

# 执行命令
fd -e js -x prettier --write {}

# 排除目录
fd -E node_modules "package"
```

### fzf：模糊搜索神器

fzf 是通用的模糊搜索工具，能和任何命令组合：

```bash
# 安装
brew install fzf

# 搜索历史命令
ctrl+r

# 搜索文件并用 vim 打开
vim $(fd | fzf)

# 搜索并切换目录
cd $(fd --type d | fzf)

# 预览文件内容
fzf --preview 'cat {}'
```

把 fzf 和 git 结合，可以快速切换分支、查看 commit：

```bash
# 模糊切换分支
git checkout $(git branch | fzf)

# 搜索 commit 并查看
git log --oneline | fzf --preview 'git show {1}'
```

### bat：带语法高亮的 cat

`cat` 命令看代码没有语法高亮，bat 补上了这个短板：

```bash
# 安装
brew install bat

# 查看文件（自动语法高亮、行号）
bat config.yml

# 显示不可见字符
bat -A Makefile

# 和其他命令组合
git diff | bat --language=diff
```

## 系统监控

### htop / btop：更好的 top

系统资源监控别再用 `top` 了，htop 和 btop 好看也好用：

```bash
# 安装
brew install htop btop

# 运行
htop
btop
```

btop 是更现代的选择，界面更美观，支持鼠标操作，还能显示网络和磁盘 IO。

### dust：磁盘占用可视化

`du` 命令的输出很难看，dust 用树状图展示磁盘占用：

```bash
# 安装
brew install dust

# 查看当前目录占用
dust

# 指定深度
dust -d 3

# 只看大文件
dust -n 50
```

### procs：更好的 ps

`ps` 命令的参数记不住，procs 默认显示更友好的信息：

```bash
# 安装
brew install procs

# 查看进程
procs

# 按名字过滤
procs node

# 查看特定端口的进程
procs --tcp 3000
```

## 网络工具

### curlie：更友好的 curl

curl 的参数太多记不住，curlie 保留了 curl 的强大，加上了 httpie 的友好：

```bash
# 安装
brew install curlie

# GET 请求
curlie httpbin.org/get

# POST JSON
curlie POST httpbin.org/post name=test age:=25

# 带 Header
curlie httpbin.org/get Authorization:"Bearer token123"
```

### dog：更好的 dig

DNS 查询工具，比 `dig` 输出更清晰：

```bash
# 安装
brew install dog

# 查询 A 记录
dog example.com

# 查询 MX 记录
dog example.com MX

# 指定 DNS 服务器
dog example.com @8.8.8.8
```

### bandwhich：带宽监控

实时查看哪个进程在吃带宽：

```bash
# 安装
brew install bandwhich

# 运行（需要 sudo）
sudo bandwhich
```

## 开发工具

### lazygit：Git 的 TUI 界面

命令行里也能有图形化的 Git 操作体验：

```bash
# 安装
brew install lazygit

# 运行
lazygit
```

lazygit 支持几乎所有 Git 操作：提交、推送、拉取、合并、rebase、stash、diff，全都能在界面里完成。用熟了比敲命令还快。

### jq：JSON 处理利器

处理 JSON 数据的瑞士军刀：

```bash
# 格式化 JSON
echo '{"name":"test","age":25}' | jq '.'

# 提取字段
curl -s https://api.github.com/users/octocat | jq '.name'

# 过滤数组
echo '[{"name":"a","age":20},{"name":"b","age":30}]' | jq '.[] | select(.age > 25)'

# 转换格式
echo '{"name":"test"}' | jq -r '.name'
```

### yq：YAML 处理工具

jq 处理 JSON，yq 处理 YAML：

```bash
# 安装
brew install yq

# 读取字段
yq '.services.web.image' docker-compose.yml

# 修改值
yq -i '.services.web.ports[0] = "8080:80"' docker-compose.yml

# YAML 转 JSON
yq -o json docker-compose.yml
```

## CLI 自动化

### 告别一切重复枯燥任务，CLI+Skill 搭建浏览器 AI 自动化框架

把命令行和 AI 结合起来，能实现很多自动化操作。这个视频演示了如何用 CLI 工具和 AI Skill 搭建浏览器自动化框架，处理重复性工作。

### 为什么巨头都在做 CLI？比 MCP 有哪些优势？

命令行界面（CLI）正在成为 AI 工具的主流交互方式。和 MCP 相比，CLI 更轻量、更灵活、更容易集成。这个视频分析了 CLI 的优势和适用场景。

## 配置文件

配置文件格式的选择对项目可维护性影响很大。JSON、YAML、TOML 各有适用场景，详见 [配置文件格式详解](/sre/config-file-formats)。

## 补充资源

### x-cmd 命令行工具

命令行工具资源网站，收录了大量实用的命令行工具和教程。想找到某个功能的命令行实现，来这里搜。

---

---
url: https://ain.hmgf.hxcn.space/software/terminal-emulators.md
description: Windows 平台主流终端管理器横向对比与配置指南
---

# 终端管理器

Windows 自带的 cmd 和 PowerShell 窗口功能太弱，没有标签页、不能分屏、配色也丑。换一个好用的终端管理器，开发体验能提升一大截。这里横向对比几款主流终端，帮你找到最适合自己的那一款。

## Windows Terminal

微软官方出品，Windows 10/11 默认终端。从 Windows 11 开始已经替代了传统的 cmd 和 PowerShell 窗口。

### 核心特点

* **多标签页**：支持在一个窗口里开多个标签，cmd、PowerShell、WSL、Azure Cloud Shell 都能混着用
* **分屏操作**：水平/垂直分屏，快捷键 `Alt+Shift+D` 或 `Alt+Shift+-`/`Alt+Shift+=`
* **GPU 加速渲染**：基于 DirectX，文字渲染流畅，透明背景不卡顿
* **Unicode/Emoji 支持**：中文、日文、Emoji 都能正常显示，不会乱码
* **配置文件系统**：每个 Shell 可以单独配置配色、字体、背景图、启动目录
* **自定义主题**：内置 10 多套配色方案，也支持自己写 JSON 配色

### 配置方法

配置文件是 JSON 格式，路径：`%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json`

```json
{
  "profiles": {
    "defaults": {
      "font": {
        "face": "CaskaydiaCove Nerd Font",
        "size": 12
      },
      "opacity": 85,
      "useAcrylic": true,
      "colorScheme": "One Half Dark"
    },
    "list": [
      {
        "name": "PowerShell",
        "source": "Windows.Terminal.PowershellCore",
        "startingDirectory": "D:\\Projects"
      },
      {
        "name": "Ubuntu WSL",
        "source": "Windows.Terminal.Wsl",
        "colorScheme": "Tango Dark"
      }
    ]
  }
}
```

### 适合人群

大多数 Windows 用户的首选。功能够用、更新频繁、和系统集成紧密。如果你不想折腾，直接用它就行。

### 优势

* 微软官方维护，稳定性好，bug 修复快
* 与 WSL 集成最好，开箱即用
* 配置 UI 可视化，不用手写 JSON 也能改设置
* 社区活跃，插件生态在发展

### 劣势

* 配置文件格式不如 TOML/YAML 直观
* 自定义程度比 WezTerm、Hyper 低
* Windows 10 早期版本需要手动从 Microsoft Store 安装

## ConEmu

老牌 Windows 终端，功能非常丰富，2006 年就有了，比 Windows Terminal 早十几年。

### 核心特点

* **标签页管理**：支持标签页分组、重命名、锁定
* **分屏**：水平/垂直/网格分屏，比 Windows Terminal 的分屏灵活得多
* **Quake 模式**：按快捷键从屏幕顶部滑下来，用完再滑回去，像游戏《Quake》的控制台
* **自定义宏**：可以绑定快捷键执行一系列操作
* **集成 Far Manager**：对用 Far 的人来说是绝配
* **丰富的配色方案**：内置几十套配色，也支持自己配

### 配置方法

ConEmu 用的是自己的 XML 配置文件，也可以通过 GUI 设置。设置项非常多，初次打开可能会被吓到。

```xml
<!-- 常用设置示例 -->
<value name="Font.FaceName" type="string" data="Consolas"/>
<value name="FontSize" type="dword" data="0x0000000c"/>
<value name="ColorTable00" type="dword" data="0x001e1e1e"/>
```

### 适合人群

需要高级分屏、Quake 模式、宏命令的重度终端用户。对配置有强迫症的人会喜欢它的精细控制。

### 优势

* 功能极其丰富，几乎没有它做不到的事
* Quake 模式是杀手级功能，用过就回不去了
* 可以嵌入到其他窗口里（比如 VS Code 的终端）
* 对老版本 Windows 支持好

### 劣势

* 界面比较老旧，不像现代应用
* 配置项太多，学习成本高
* 开发节奏变慢，维护者精力有限
* 偶尔有渲染问题，尤其是中文

## Cmder

基于 ConEmu 的便携版终端，集成了 msysGit（现在是 Git for Windows），开箱即用。

### 核心特点

* **便携免安装**：解压即用，U 盘随身带着走
* **内置 Git Bash**：自带 Git for Windows 的 bash 环境
* **预配置好**：ConEmu 那些复杂的配置已经帮你调好了，开箱就能用
* **自定义提示符**：自带的 `Cmder.lua` 脚本让提示符显示 git 分支、状态等信息
* **集成 SSH agent**：ssh 密钥管理方便

### 配置方法

Cmder 的配置分两层：ConEmu 的配置（和原版一样）和 Cmder 自己的 Lua 脚本。

```lua
-- Cmder\config\cmder_prompt_config.lua
prompt_lambSymbol = "λ"
prompt_envVar = "{env:ENV_VAR}"
```

环境变量配置：`CMDER_ROOT` 指向 Cmder 安装目录，`PATH` 加上 `%CMDER_ROOT%\bin`。

### 适合人群

想要一个便携、开箱即用的终端，不想折腾 ConEmu 配置的人。适合随身带 U 盘在不同电脑上用。

### 优势

* 免安装，解压就能用
* 预配置好，不用花时间调教
* Git 集成很好，提示符直接显示分支
* 社区维护的 clink 增强了命令行编辑

### 劣势

* 底层还是 ConEmu，继承了它的渲染问题
* 版本更新慢，Git 版本可能滞后
* 体积比 ConEmu 大（因为带了 Git for Windows）
* 和 Windows Terminal 比，缺少现代化的渲染引擎

## Alacritty

用 Rust 写的终端模拟器，主打一个字：快。GPU 加速渲染，启动速度和渲染速度都很快。

### 核心特点

* **GPU 加速**：用 OpenGL 渲染，文字刷新飞快，不会有撕裂感
* **极简设计**：没有标签页、没有分屏、没有菜单栏，就是一个纯粹的终端窗口
* **跨平台**：Windows、macOS、Linux 都支持
* **YAML 配置**：配置文件简洁明了
* **低延迟**：输入延迟极低，打字手感好

### 配置方法

配置文件路径：`%APPDATA%\alacritty\alacritty.yml`（Windows）或 `~/.config/alacritty/alacritty.yml`（Linux/macOS）

```yaml
# alacritty.yml
window:
  opacity: 0.9
  padding:
    x: 8
    y: 8

font:
  normal:
    family: "CaskaydiaCove Nerd Font"
    style: Regular
  size: 12.0

colors:
  primary:
    background: "#1e1e1e"
    foreground: "#d4d4d4"
  normal:
    black:   "#1e1e1e"
    red:     "#f44747"
    green:   "#6a9955"
    yellow:  "#d7ba7d"
    blue:    "#569cd6"
    magenta: "#c586c0"
    cyan:    "#4ec9b0"
    white:   "#d4d4d4"
```

### 适合人群

追求极致性能、喜欢极简风格的用户。通常搭配 tmux 或 zellij 这类终端复用器使用，弥补它没有标签页和分屏的缺点。

### 优势

* 启动快、渲染快、响应快
* 资源占用低，内存占用只有几十 MB
* 配置文件简洁，一目了然
* 社区活跃，更新及时

### 劣势

* 没有标签页和分屏，必须搭配 tmux/zellij
* 不支持图片显示（sixel/kitty 协议）
* 配置改了要重启才生效（部分配置支持热重载）
* Windows 上的体验不如 Linux/macOS

## WezTerm

用 Rust 写的跨平台终端，配置用 Lua 脚本，可玩性很高。

### 核心特点

* **Lua 配置**：用 Lua 脚本配置，支持条件判断、循环、函数，比 JSON/YAML 灵活
* **内置多路复用**：标签页、分屏、工作区都是内置功能，不需要 tmux
* **图片显示**：支持 iTerm2 和 Kitty 的图片协议，终端里能看图
* **字体渲染好**：支持连字（ligatures）、彩色字体（Nerd Font）
* **跨平台**：Windows、macOS、Linux 都支持，配置文件通用

### 配置方法

配置文件路径：`~/.wezterm.lua`

```lua
-- ~/.wezterm.lua
local wezterm = require 'wezterm'
local config = wezterm.config_builder()

config.font = wezterm.font('CaskaydiaCove Nerd Font')
config.font_size = 12.0
config.color_scheme = 'One Dark (Gogh)'

config.window_background_opacity = 0.9
config.window_padding = { left = 8, right = 8, top = 8, bottom = 8 }

config.enable_tab_bar = true
config.use_fancy_tab_bar = false
config.tab_bar_at_bottom = true

config.leader = { key = 'a', mods = 'CTRL', timeout_milliseconds = 1000 }
config.keys = {
  { key = '-', mods = 'LEADER', action = wezterm.action.SplitVertical },
  { key = '\\', mods = 'LEADER', action = wezterm.action.SplitHorizontal },
  { key = 'z', mods = 'LEADER', action = wezterm.action.TogglePaneZoomState },
}

return config
```

### 适合人群

喜欢用代码配置一切的用户。想要一个终端搞定所有事（标签页、分屏、图片显示），不想额外装 tmux 的人。

### 优势

* Lua 配置极其灵活，可以写复杂的逻辑
* 内置多路复用，不需要 tmux
* 图片显示支持好，终端里看图方便
* 配置文件跨平台通用，换电脑直接拷贝
* 更新频繁，功能一直在加

### 劣势

* 学习曲线比 Windows Terminal 陡
* 配置文件写错了会报错，需要一定的 Lua 基础
* 在 Windows 上偶尔有渲染 bug
* 社区比 Alacritty 小

## Hyper

用 Electron 构建的终端，前端开发者会很熟悉，可以像写网页一样自定义终端。

### 核心特点

* **Electron 架构**：用 HTML/CSS/JS 渲染界面，前端开发者可以轻松自定义
* **插件系统**：npm 包作为插件，社区插件丰富
* **主题系统**：CSS 主题，可以完全重新设计终端外观
* **跨平台**：Windows、macOS、Linux 都支持
* **配置简单**：`~/.hyper.js` 一个文件搞定

### 配置方法

配置文件路径：`%USERPROFILE%\.hyper.js`（Windows）或 `~/.hyper.js`（Linux/macOS）

```javascript
// ~/.hyper.js
module.exports = {
  config: {
    fontSize: 14,
    fontFamily: 'CaskaydiaCove Nerd Font, Menlo, monospace',
    cursorColor: 'rgba(255, 255, 255, 0.8)',
    foregroundColor: '#d4d4d4',
    backgroundColor: '#1e1e1e',
    padding: '12px',
    termCSS: '',
    showHamburgerMenu: '',
    showWindowControls: '',
  },
  plugins: [
    'hyper-dracula',
    'hyper-statusline',
    'hyper-tabs-enhanced',
  ],
};
```

### 适合人群

前端开发者，或者喜欢用 JS/TS 配置一切的人。想要把终端做成一个可高度定制的工具。

### 优势

* 插件生态丰富，npm 上有大量终端插件
* 主题系统强大，CSS 能做到的事它都能做
* 对前端开发者友好，配置和开发门槛低
* 社区活跃，教程多

### 劣势

* Electron 的通病：内存占用高，启动慢
* 渲染性能不如原生终端，大量输出时会卡
* 依赖 Node.js 运行时，体积大
* 开发团队精力分散，更新频率不稳定

## 横向对比

| 特性 | Windows Terminal | ConEmu | Cmder | Alacritty | WezTerm | Hyper |
|------|------------------|--------|-------|-----------|---------|-------|
| **开发语言** | C++ | C++ | C++/Lua | Rust | Rust | TypeScript |
| **GPU 加速** | 是 | 否 | 否 | 是 | 是 | 否 |
| **标签页** | 是 | 是 | 是 | 否 | 是 | 是 |
| **分屏** | 是 | 是 | 是 | 否 | 是 | 是 |
| **配置格式** | JSON | XML/GUI | Lua | YAML | Lua | JavaScript |
| **图片支持** | 是 | 否 | 否 | 否 | 是 | 是 |
| **内存占用** | 中等 | 低 | 中等 | 极低 | 低 | 高 |
| **启动速度** | 快 | 快 | 快 | 极快 | 快 | 慢 |
| **便携性** | 否 | 是 | 是 | 是 | 是 | 是 |
| **学习成本** | 低 | 高 | 低 | 中等 | 中等 | 中等 |

## 怎么选

**不想折腾**：Windows Terminal。官方出品，功能够用，更新稳定。

**需要 Quake 模式**：ConEmu。快捷键呼出/隐藏的体验是独一份的。

**要便携**：Cmder。U 盘带着走，解压就能用。

**追求性能**：Alacritty。配合 tmux，启动快、渲染快、资源占用低。

**喜欢写代码配置**：WezTerm。Lua 配置灵活，内置多路复用，一个终端搞定所有事。

**前端开发者**：Hyper。npm 插件生态，CSS 主题，用前端技术栈玩转终端。

## 推荐视频

下面几个视频对终端的使用和配置讲得比较详细，推荐看看。

## 补充资源

### Nerd Font 字体

上面这些终端配置里都用了 Nerd Font，这是一类在普通字体基础上加了大量图标的编程字体。很多终端的主题和提示符美化都依赖它。

### Oh My Posh

跨平台的终端提示符美化工具，支持 Bash、Zsh、PowerShell、Fish 等各种 Shell。可以显示 git 状态、执行时间、错误码等信息。

### Starship

Rust 写的跨平台提示符工具，比 Oh My Posh 更轻量，配置更简洁。

---

---
url: https://ain.hmgf.hxcn.space/software/disk-file-system.md
---
# 磁盘与文件系统

磁盘管理和文件系统是 Windows 使用的基础知识。分区、格式化、文件类型，这些操作用对了能让数据更安全，用错了可能丢数据。

## 文件系统

### 快速带你了解常用的文件系统

NTFS、FAT32、exFAT、ReFS，Windows 支持好几种文件系统，每种都有不同的特点和适用场景：

* **NTFS** - Windows 默认文件系统，支持权限控制、加密、压缩，日常使用首选
* **FAT32** - 兼容性最好，但单文件不能超过 4GB，适合 U 盘
* **exFAT** - 跨平台兼容，没有 4GB 限制，U 盘和移动硬盘推荐
* **ReFS** - 新一代文件系统，数据完整性更强，适合服务器

这个视频把各种文件系统的特点和适用场景讲得很清楚。

### 文件系统详细对比

#### NTFS（New Technology File System）

NTFS 是 Windows 的默认文件系统，从 Windows NT 3.1 开始使用，至今仍是主流。

**技术特性：**

* **最大卷大小**：256TB（理论值），实际受分区表限制
* **最大文件大小**：256TB
* **文件名长度**：255 个字符
* **日志功能**：支持，断电后可恢复文件系统结构
* **权限控制**：支持 ACL（访问控制列表），可精确控制每个用户/组的权限
* **加密**：支持 EFS（加密文件系统）
* **压缩**：支持文件和文件夹级别的压缩
* **硬链接**：支持，多个文件名指向同一份数据
* **符号链接**：支持，类似快捷方式但更底层
* **磁盘配额**：支持，可限制用户使用的磁盘空间
* **卷影副本**：支持，可恢复到之前的版本

**适用场景：**

* Windows 系统盘（必须用 NTFS）
* 内部硬盘和 SSD
* 需要权限控制的共享文件夹
* 需要加密的敏感数据

**注意事项：**

* macOS 只能读取 NTFS，写入需要第三方工具（如 Paragon NTFS、Mounty）
* Linux 可以读写 NTFS，但性能不如原生文件系统
* 不适合 U 盘（频繁读写会缩短寿命，因为日志功能会增加写入量）

#### FAT32（File Allocation Table 32）

FAT32 是最古老的文件系统之一，1996 年随 Windows 95 OSR2 发布。虽然老，但兼容性无敌。

**技术特性：**

* **最大卷大小**：8TB（Windows 格式化限制为 32GB）
* **最大文件大小**：4GB（这是最大限制）
* **文件名长度**：8.3 格式（8 个字符文件名 + 3 个字符扩展名），支持长文件名但有兼容性问题
* **日志功能**：不支持，断电可能导致数据丢失
* **权限控制**：不支持
* **加密**：不支持
* **压缩**：不支持

**适用场景：**

* U 盘（如果不需要存大于 4GB 的文件）
* SD 卡（相机、行车记录仪等设备）
* 需要最大兼容性的场景（老设备、游戏机、车载系统）
* EFI 系统分区（通常是 FAT32 格式）

**注意事项：**

* 单文件不能超过 4GB，这是最大限制
* 不适合大容量硬盘（格式化速度慢，性能差）
* 没有日志功能，断电后文件系统容易损坏

#### exFAT（Extended File Allocation Table）

exFAT 是微软 2006 年推出的文件系统，专门为闪存设备设计。解决了 FAT32 的 4GB 限制，同时保持了较好的兼容性。

**技术特性：**

* **最大卷大小**：128PB（理论值）
* **最大文件大小**：16EB（理论值），实际无限制
* **文件名长度**：255 个字符
* **日志功能**：不支持（但有原子操作保护）
* **权限控制**：不支持
* **加密**：不支持
* **压缩**：不支持
* **簇大小**：支持从 512 字节到 32MB

**适用场景：**

* 大容量 U 盘（需要存大于 4GB 的文件）
* 移动硬盘（跨平台使用）
* SD 卡（大于 32GB 的 SD 卡推荐 exFAT）
* macOS 和 Windows 之间传文件

**注意事项：**

* Windows XP 需要安装补丁才能支持
* 部分老设备可能不支持 exFAT
* 没有日志功能，安全性不如 NTFS
* 断电后数据恢复难度较大

#### ReFS（Resilient File System）

ReFS 是微软 2012 年推出的新一代文件系统，主要面向服务器和企业用户。

**技术特性：**

* **最大卷大小**：35PB
* **最大文件大小**：16EB
* **数据完整性**：使用校验和检测并修复数据损坏
* **自动修复**：配合 Storage Spaces 可自动修复损坏的数据
* **去重**：支持块级去重，节省存储空间
* **弹性**：对元数据损坏有更强的恢复能力

**适用场景：**

* Windows Server（推荐用于文件服务器）
* Hyper-V 虚拟机存储
* 大数据存储场景
* 需要高数据完整性的场景

**注意事项：**

* Windows 家庭版不支持 ReFS
* 不能作为系统盘（不能启动 Windows）
* 与部分旧软件不兼容

### 文件系统选择建议

| 使用场景 | 推荐文件系统 | 原因 |
|---------|-------------|------|
| Windows 系统盘 | NTFS | 必须使用，支持所有 Windows 功能 |
| 内部数据盘 | NTFS | 权限控制、日志、加密 |
| U 盘（小于 32GB） | FAT32 | 兼容性最好 |
| U 盘（大于 32GB） | exFAT | 没有 4GB 限制 |
| 移动硬盘（跨平台） | exFAT | Windows/macOS 都能读写 |
| Mac 和 Windows 共享 | exFAT | 双平台兼容 |
| 相机 SD 卡 | exFAT（大于 32GB）/ FAT32（小于 32GB） | 设备兼容性 |
| Linux 系统 | ext4 | Linux 原生文件系统 |
| Windows Server | NTFS 或 ReFS | 数据完整性 |

### 文件系统格式化方法

**方法一：文件资源管理器**

1. 打开"此电脑"
2. 右键点击要格式化的磁盘
3. 选择"格式化"
4. 选择文件系统（NTFS/exFAT/FAT32）
5. 分配单元大小保持默认
6. 点击"开始"

**方法二：磁盘管理**

1. 右键"开始"按钮 → "磁盘管理"
2. 右键点击分区
3. 选择"格式化"
4. 选择文件系统和卷标
5. 确认

**方法三：命令行（diskpart）**

```cmd
# 打开命令提示符（管理员）
diskpart
list disk
select disk 1  # 选择要操作的磁盘
clean          # 清除所有分区
create partition primary
format fs=ntfs quick  # 快速格式化为 NTFS
assign letter=E       # 分配盘符
exit
```

**注意：格式化会清除磁盘上所有数据，操作前请备份！**

## 磁盘分区

### 如何给已分区的磁盘进行扩容/拆分/合并？

新硬盘装上去看不到？想给已有分区扩容或合并？Windows 自带的磁盘管理工具就能搞定，不需要装第三方分区软件。这个视频演示了磁盘分区的各种操作：新建分区、扩容、拆分、合并，还有新装硬盘如何显示在我的电脑内。

### 磁盘分区基础知识

#### 什么是磁盘分区？

磁盘分区就是把一块物理硬盘划分成多个逻辑区域，每个区域独立管理，有自己的文件系统。分区的好处是数据隔离——系统盘坏了不会影响数据盘。

#### MBR vs GPT

磁盘分区表有两种格式：

**MBR（Master Boot Record）：**

* 最大支持 2TB 硬盘
* 最多 4 个主分区（或 3 个主分区 + 1 个扩展分区）
* 所有 Windows 版本都支持
* 老电脑通常用 MBR

**GPT（GUID Partition Table）：**

* 支持大于 2TB 的硬盘
* 最多 128 个分区（Windows 限制）
* 需要 UEFI 启动模式
* 新电脑推荐使用 GPT

**如何查看磁盘是 MBR 还是 GPT：**

1. 右键"开始"按钮 → "磁盘管理"
2. 右键点击磁盘（不是分区）→ "属性"
3. 切换到"卷"选项卡
4. 查看"分区样式"

#### 主分区、扩展分区、逻辑分区

* **主分区**：可以直接安装操作系统，可以直接使用
* **扩展分区**：不能直接使用，必须在里面创建逻辑分区
* **逻辑分区**：创建在扩展分区内部，可以正常使用

MBR 磁盘最多 4 个主分区，如果需要更多分区，需要把其中一个主分区改为扩展分区，然后在扩展分区内创建逻辑分区。

GPT 磁盘没有这个限制，所有分区都是主分区。

### Windows 自带磁盘管理工具

#### 打开方式

* **方法一**：右键"开始"按钮 → "磁盘管理"
* **方法二**：按 `Win + R`，输入 `diskmgmt.msc`，回车
* **方法三**：搜索"磁盘管理"

#### 常见操作

**新建分区：**

1. 在"未分配"空间上右键
2. 选择"新建简单卷"
3. 设置分区大小
4. 分配盘符
5. 选择文件系统和卷标
6. 完成

**扩展分区（扩大）：**

1. 右键要扩展的分区
2. 选择"扩展卷"
3. 设置要增加的空间大小
4. 完成

**注意：只能向右扩展，且右边必须有未分配空间。如果未分配空间在左边或不相邻，需要使用第三方工具。**

**压缩分区（缩小）：**

1. 右键要压缩的分区
2. 选择"压缩卷"
3. 设置要释放的空间大小
4. 完成

**删除分区：**

1. 右键要删除的分区
2. 选择"删除卷"
3. 确认

**注意：删除分区会清除该分区所有数据！**

**更改盘符：**

1. 右键分区
2. 选择"更改驱动器号和路径"
3. 点击"更改"
4. 选择新的盘符
5. 确认

### 第三方分区工具

Windows 自带的磁盘管理功能有限，复杂的分区操作需要第三方工具。

#### DiskGenius（推荐）

国产免费分区工具，功能强大，操作简单。支持分区调整、数据恢复、备份还原等。

**核心功能：**

* **无损调整分区大小**：不用删除数据就能调整
* **合并分区**：将两个相邻分区合并
* **拆分分区**：将一个分区拆成两个
* **迁移系统**：将系统从 HDD 迁移到 SSD
* **数据恢复**：误删文件恢复
* **备份还原**：分区备份和还原

**下载地址：** [diskgenius.cn](https://www.diskgenius.cn/)

#### MiniTool Partition Wizard

免费的分区管理工具，界面美观，功能全面。

**核心功能：**

* 分区调整、移动、合并、拆分
* 磁盘克隆
* 分区恢复
* 磁盘基准测试

**下载地址：** [partitionwizard.com](https://www.partitionwizard.com/)

### 磁盘健康检测

硬盘有寿命，定期检测可以提前发现问题，避免数据丢失。

#### S.M.A.R.T. 检测

S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）是硬盘自带的健康监测系统。

**查看工具：**

* **CrystalDiskInfo**：免费，界面简洁，显示 S.M.A.R.T. 信息
* **HD Tune**：老牌硬盘检测工具，支持基准测试
* **Hard Disk Sentinel**：功能强大，支持深度检测

**需要关注的指标：**

* **重新分配扇区计数**：如果持续增长，硬盘可能快坏了
* **待映射扇区数**：如果有值，说明有坏道
* **通电时间**：可以判断硬盘使用时长
* **温度**：正常工作温度 30-45°C

#### CrystalDiskInfo 使用方法

1. 下载安装 CrystalDiskInfo
2. 打开软件，自动检测所有硬盘
3. 查看"健康状态"：
   * **良好**（蓝色）：正常
   * **注意**（黄色）：有异常，建议备份数据
   * **不良**（红色）：硬盘快坏了，立即备份数据

**下载地址：** [crystalmark.info](https://crystalmark.info/en/software/crystaldiskinfo/)

## 文件类型

### 7 分钟详解所有 Windows 文件类型

Windows 的文件类型多得离谱，.exe、.dll、.sys、.lnk、.reg，每种都有不同用途。这个视频把常见文件类型都介绍了一遍，帮你了解它们的作用。遇到问题时，知道文件类型能更快定位原因。

### 常见文件类型详解

#### 可执行文件

| 扩展名 | 说明 | 用途 |
|--------|------|------|
| `.exe` | 可执行文件 | 程序主文件 |
| `.msi` | 安装包 | Windows Installer 安装程序 |
| `.bat` | 批处理文件 | CMD 命令脚本 |
| `.cmd` | 命令脚本 | 类似 .bat |
| `.ps1` | PowerShell 脚本 | PowerShell 命令脚本 |
| `.vbs` | VBScript 脚本 | Visual Basic 脚本 |
| `.msc` | 管理控制台 | 系统管理工具 |

#### 系统文件

| 扩展名 | 说明 | 用途 |
|--------|------|------|
| `.sys` | 系统文件 | 驱动程序 |
| `.dll` | 动态链接库 | 共享代码库 |
| `.ini` | 配置文件 | 程序配置 |
| `.reg` | 注册表文件 | 注册表导入导出 |
| `.log` | 日志文件 | 程序运行日志 |
| `.tmp` | 临时文件 | 程序临时数据 |

#### 文档文件

| 扩展名 | 说明 | 用途 |
|--------|------|------|
| `.txt` | 纯文本文件 | 无格式文本 |
| `.docx` | Word 文档 | Microsoft Word |
| `.xlsx` | Excel 表格 | Microsoft Excel |
| `.pptx` | PPT 演示文稿 | Microsoft PowerPoint |
| `.pdf` | PDF 文档 | 跨平台文档格式 |
| `.md` | Markdown 文件 | 轻量级标记语言 |
| `.csv` | 逗号分隔文件 | 数据表格 |

#### 图片文件

| 扩展名 | 说明 | 用途 |
|--------|------|------|
| `.jpg/.jpeg` | JPEG 图片 | 有损压缩，照片常用 |
| `.png` | PNG 图片 | 无损压缩，支持透明 |
| `.gif` | GIF 图片 | 动图 |
| `.bmp` | 位图 | 无压缩，体积大 |
| `.svg` | 矢量图 | 可无损缩放 |
| `.webp` | WebP 图片 | 谷歌推出，体积小 |
| `.ico` | 图标文件 | 程序图标 |

#### 压缩文件

| 扩展名 | 说明 | 用途 |
|--------|------|------|
| `.zip` | ZIP 压缩包 | 最常见的压缩格式 |
| `.rar` | RAR 压缩包 | WinRAR 专用 |
| `.7z` | 7-Zip 压缩包 | 高压缩率 |
| `.tar` | 归档文件 | Linux 常用 |
| `.gz` | Gzip 压缩 | Linux 常用 |
| `.iso` | 光盘镜像 | 系统安装盘 |

### 文件扩展名显示

Windows 默认隐藏已知文件类型的扩展名，建议开启显示：

1. 打开文件资源管理器
2. 点击"查看"选项卡
3. 勾选"文件扩展名"

或者：

1. 打开文件资源管理器
2. 点击"查看" → "显示" → "文件扩展名"

**为什么要显示扩展名：**

* 避免被伪装的可执行文件欺骗（如 `文件.txt.exe`）
* 快速识别文件类型
* 方便批量重命名

### 文件关联

双击文件时用什么程序打开，由文件关联决定。

**修改文件关联：**

1. 右键点击文件
2. 选择"打开方式"
3. 选择"选择其他应用"
4. 选择想要的程序
5. 勾选"始终使用此应用打开"

**批量修改：**

1. 设置 → 应用 → 默认应用
2. 按文件类型指定默认应用
3. 找到要修改的扩展名
4. 选择默认程序

## 磁盘清理

### Windows 自带清理工具

#### 磁盘清理

1. 右键点击磁盘 → "属性"
2. 点击"磁盘清理"
3. 选择要清理的内容
4. 点击"清理系统文件"（可选）
5. 确认

**可清理内容：**

* 临时文件
* 回收站
* Windows 更新清理
* 系统错误内存转储文件
* 缩略图缓存

#### 存储感知

Windows 10/11 自带的自动清理功能：

1. 设置 → 系统 → 存储
2. 开启"存储感知"
3. 配置清理规则：
   * 临时文件自动删除
   * 回收站自动清理
   * 下载文件夹自动清理

#### 第三方清理工具

**BleachBit**：开源免费的系统清理工具，支持清理浏览器缓存、系统临时文件、日志等。

**下载地址：** [bleachbit.org](https://www.bleachbit.org/)

**注意：不推荐使用 CCleaner，近年来多次被曝出安全问题。**

---

---
url: https://ain.hmgf.hxcn.space/pc-diy.md
---
# 电脑维护/DIY

电脑硬件相关的实用资源，包括装机、驱动、维修、选购等内容。

## 分类

### 装机指南

硬件组装、系统安装、BIOS设置等内容。

### 驱动程序

驱动下载、安装、更新与故障排除。

### 电脑维修

常见硬件故障诊断与维修方法。

### 选购建议

硬件选购指南、性价比推荐、兼容性参考。

### 硬件知识

CPU、显卡、内存、主板等硬件基础知识。

---

---
url: https://ain.hmgf.hxcn.space/pc-diy/build-pc-guide.md
---
# 装机指南

自己组装电脑，从选购配件到点亮开机，整个流程其实没想象中那么复杂。关键是搞清楚步骤，别跳步。这篇指南把装机、装系统、装驱动、烤机测试每个环节都讲清楚。

## 装机前准备

### 工具清单

装机前准备好这些工具，别装到一半发现缺东西：

| 工具 | 用途 | 必要性 |
|------|------|--------|
| 十字螺丝刀 | 拧螺丝 | 必备 |
| 磁性螺丝刀 | 吸螺丝方便操作 | 推荐 |
| 扎带 / 魔术贴 | 走线理线 | 推荐 |
| 剪刀 | 剪扎带和包装 | 必备 |
| 防静电手环 | 防止静电损坏硬件 | 建议有 |
| 手电筒 | 照暗处接口 | 有就更好 |
| 硅脂 | 涂 CPU 散热器 | 散热器通常自带 |

### 配件到手后先验货

别急着装，先检查配件有没有问题：

1. **CPU**：检查针脚有没有弯（Intel 看主板触点，AMD 看 CPU 针脚）
2. **内存**：检查金手指有没有划痕
3. **固态硬盘**：检查接口有没有损坏
4. **主板**：检查板面有没有划痕、电容有没有歪
5. **显卡**：检查 PCB 有没有裂痕、接口有没有损坏
6. **电源**：检查线材有没有破损

有问题直接联系商家退换，装上去再发现就不好说了。

## 装机教程

### 这可能是你能在网上找到最详细的装机教程

这个视频把装机每个步骤都拆得很细，从开箱到走线，从安装 CPU 到接跳线，每一步都有特写镜头。适合完全零基础的人，跟着一步步操作就行。

### 全网最好的装机教程，没有之一

另一个高质量装机教程，讲解风格更简洁明快。两个教程选一个看就行，内容大同小异，主要看你喜欢哪种讲解风格。

### 史上最详细传说级装机教程

零基础新手一站式装机攻略，包含 AMD 和 Intel 双平台 DIY 组装教程。如果你用的是 AMD 平台，这个教程会更贴合你的实际情况。

### 装机步骤详细拆解

怕你看视频记不住，这里把关键步骤列出来：

**第一步：安装 CPU**

1. 打开主板 CPU 插槽的压杆
2. 对准 CPU 和插槽的三角标记（金色三角对准插槽三角）
3. 轻放 CPU，不要用力按，靠重力自然落下
4. 压下压杆扣紧

**注意：**

* Intel 12/13/14 代是 LGA 1700 插槽，针脚在主板上，CPU 是触点
* AMD 锐龙 7000 系是 AM5 插槽，同样是 LGA，针脚在主板上
* 老款 AMD（AM4）针脚在 CPU 上，要更小心别弯针

**第二步：安装内存**

1. 打开内存插槽两端的卡扣
2. 对准内存缺口和插槽（防呆设计，不对插不进去）
3. 均匀用力按下，听到"咔嗒"一声卡扣自动扣上

**注意：**

* 双通道要插 2、4 槽（从 CPU 往外数），不是相邻的槽
* 只有一根内存时插第 2 槽（离 CPU 近的那个）
* 用力要均匀，别只按一头

**第三步：安装 M.2 固态硬盘**

1. 拆下主板 M.2 散热马甲（有的话）
2. 将固态硬盘斜着插入 M.2 接口
3. 按下固态尾部，用螺丝固定

**注意：**

* 有的主板自带免螺丝卡扣，不需要拧螺丝
* PCIe 4.0/5.0 固态建议装散热马甲，不然温度高会掉速
* 第一个 M.2 通常是直连 CPU 的，速度最快

**第四步：安装散热器**

1. 在 CPU 表面涂硅脂（米粒大小就够）
2. 安装散热器底座和扣具
3. 拧紧螺丝（对角线交替拧，不要一颗拧到底）

**注意：**

* 散热器自带的硅脂通常够用，不用额外涂
* 塔式风冷要注意方向，风扇朝向机箱后部出风
* 水冷排通常装在机箱顶部或前面板

**第五步：安装主板到机箱**

1. 先装主板 I/O 挡板（有的主板自带就不需要）
2. 对准机箱铜柱和主板螺丝孔
3. 拧紧主板螺丝

**注意：**

* 检查机箱铜柱位置和主板孔位是否对应，多余的铜柱要拆掉
* 螺丝不要拧太紧，拧到位就行

**第六步：安装电源**

1. 将电源放入机箱电源仓
2. 拧紧螺丝固定
3. 接好主板供电线（24pin）和 CPU 供电线（8pin）

**注意：**

* 先把电源线穿过机箱背线孔再插
* CPU 供电线在主板左上角，别漏接
* 模组电源先接好线再装进机箱

**第七步：安装显卡**

1. 拆掉机箱对应的 PCIe 挡板
2. 将显卡插入 PCIe x16 插槽，听到"咔嗒"声
3. 接好显卡供电线（6pin/8pin/12VHPWR）

**注意：**

* 显卡很重，建议买个显卡支架防止 PCIe 插槽变形
* 新显卡（RTX 40 系）用 12VHPWR 接口，老电源需要转接线
* 转接线要插紧，松动会烧接口

**第八步：接线**

1. 机箱前面板跳线（开机键、重启键、指示灯、USB、音频）
2. 机箱风扇供电线
3. 硬盘 SATA 数据线和供电线（如果有的话）

**注意：**

* 跳线接法看主板说明书，每块主板位置不同
* 开机键和重启键不分正负极，LED 灯分正负极
* USB 3.0 接口有防呆设计，对准插就行

**第九步：理线**

1. 多余的线材塞到机箱背面
2. 用扎带或魔术贴固定
3. 确保线材不挡住风扇

**理线不是为了好看，是为了散热和以后维护方便。**

### 装机常见问题

**Q：装完按开机键没反应怎么办？**

1. 检查电源开关有没有打开（电源背面的 I/O 开关）
2. 检查主板 24pin 供电和 CPU 8pin 供电有没有插紧
3. 检查机箱开机键跳线有没有接对
4. 检查电源有没有烧（风扇转不转）

**Q：开机风扇转但显示器没画面？**

1. 检查显示器线有没有接对（接显卡，不是主板）
2. 检查显卡有没有插紧、供电有没有接
3. 检查内存有没有插紧（重新拔插一次）
4. 看主板 Debug 灯，对照说明书排查

**Q：开机反复重启？**

1. 检查 CPU 散热器有没有装好（过热保护重启）
2. 检查内存兼容性（换个槽试试）
3. 检查电源功率够不够
4. 进 BIOS 恢复默认设置

**Q：装机时要注意静电吗？**

* 正常环境不太需要担心，摸一下金属机箱放掉静电就行
* 干燥的冬天或地毯环境建议戴防静电手环
* 不要穿毛衣装机

**Q：CPU 针脚弯了怎么办？**

* 小弯可以用针或信用卡轻轻拨正
* 弯太多建议找专业维修，自己掰断就完了
* Intel 平台针脚在主板上，主板比 CPU 便宜，运气好只坏主板

## 系统安装

### 史上最全传说级装系统教程

零基础新手一站式 WIN10 系统安装攻略。包含系统激活、驱动安装、BIOS 基础调试及基础烤机稳定性压力测试。装完硬件后的第一步，就是跟着这个教程装系统。

### 超详细 WIN10 系统安装教程

官方 ISO 直装与 PE 两种方法教程，UEFI+GUID 分区与 Legacy+MBR 分区。如果你需要双系统或者特殊分区方案，这个教程讲得更细。

### 系统安装前的 BIOS 设置

装系统前先进 BIOS 做几个关键设置：

1. **开启 XMP/EXPO**：让内存跑到标称频率，不然默认跑 2133/4800MHz
2. **设置启动顺序**：把 U 盘设为第一启动项
3. **确认硬盘模式**：AHCI 模式（现在基本默认就是）
4. **关闭安全启动**（如果装 Linux 或老系统）：Windows 11 需要开启
5. **确认 CSM 设置**：新系统用 UEFI 模式，关闭 CSM

**怎么进 BIOS？**

* 开机时反复按 Del 键（大多数主板）
* 部分主板是 F2 或 F12
* 看主板开机画面提示

### Windows 11 安装注意事项

Windows 11 比 10 多了几个硬件要求：

* **TPM 2.0**：必须开启，在 BIOS 里找 TPM 或 fTPM 选项
* **安全启动**：必须开启
* **4GB 内存**：最低要求，建议 16GB 起步
* **64GB 存储**：系统盘至少 64GB

**绕过 TPM 检查的方法（不推荐但备着）：**
安装时按 Shift+F10 打开命令行，输入 `regedit`，导航到 `HKEY_LOCAL_MACHINE\SYSTEM\Setup`，新建一个 `LabConfig` 项，在里面新建 DWORD 值 `BypassTPMCheck` 设为 1。

### 系统分区方案

**推荐方案：UEFI + GPT**

| 分区 | 大小 | 用途 |
|------|------|------|
| EFI 系统分区 | 512MB | 引导文件 |
| MSR 分区 | 16MB | 系统保留 |
| C 盘（系统盘） | 100-200GB | Windows 系统和软件 |
| D 盘（数据盘） | 剩余空间 | 文件、游戏 |

**为什么用 GPT 不用 MBR？**

* GPT 支持 2TB 以上硬盘
* GPT 支持更多分区
* UEFI 启动更快更安全
* Windows 11 强制要求 GPT

## 驱动安装

### 驱动程序是什么？如何正确安装纯净版驱动？

装完系统第一件事是装驱动。驱动程序是让硬件和系统沟通的桥梁，没装驱动硬件就发挥不了性能。

**驱动安装顺序：**

1. **芯片组驱动**：主板官网下载，让系统正确识别所有硬件
2. **显卡驱动**：NVIDIA/AMD 官网下载最新版
3. **网卡驱动**：如果系统没自动识别，用手机 USB 共享网络先上网
4. **声卡驱动**：主板官网或 Windows Update
5. **其他驱动**：蓝牙、Wi-Fi、USB 等

**去哪里下载驱动？**

| 硬件 | 下载地址 |
|------|---------|
| NVIDIA 显卡 | https://www.nvidia.cn/drivers |
| AMD 显卡 | https://www.amd.com/en/support |
| Intel 芯片组/CPU | https://www.intel.cn/content/www/cn/zh/download-center |
| 主板驱动 | 主板品牌官网（华硕、微星、技嘉等） |

**千万不要用驱动精灵、360 驱动大师这类第三方工具！** 它们会捆绑垃圾软件，装一堆用不上的东西。驱动去官网下，虽然麻烦点但干净。

### NVIDIA 显卡驱动安装建议

**Game Ready 驱动 vs Studio 驱动：**

* **Game Ready（GRD）**：针对游戏优化，玩游戏选这个
* **Studio**：针对创意软件优化（Pr、Blender、达芬奇），做设计选这个

**要不要用 GeForce Experience / NVIDIA App？**

* 推荐安装，方便更新驱动和使用 ShadowPlay 录屏
* 如果嫌麻烦，可以只装驱动不装 App

**DDU 是什么？**

Display Driver Uninstaller，专门用来彻底卸载显卡驱动。遇到驱动问题时用它清除干净再重装。从 https://www.wagnardsoft.com/ 下载。

## 烤机测试

### 验机烤机软件一站式教程

新手装机必学必用的 10 款基础检测烤机跑分软件。装完系统、装好驱动后，要跑一遍烤机测试确保稳定性。

### 烤机测试详细方案

烤机就是让硬件满载运行一段时间，测试稳定性和散热。新装机一定要烤，不然后面蓝屏死机都不知道是硬件问题还是软件问题。

**CPU 烤机：**

| 软件 | 测试内容 | 时长 | 温度上限 |
|------|---------|------|---------|
| AIDA64 | CPU、FPU、缓存 | 30 分钟 | 90°C |
| Cinebench R23 | 多核渲染 | 跑 10 分钟 | 85°C |
| Prime95 | 极端压力测试 | 30 分钟 | 95°C |
| OCCT | 综合测试 | 30 分钟 | 90°C |

**显卡烤机：**

| 软件 | 测试内容 | 时长 | 温度上限 |
|------|---------|------|---------|
| FurMark | 极端压力 | 15 分钟 | 85°C |
| 3DMark Time Spy | 综合性能 | 跑完看分数 | 80°C |
| Unigine Heaven | 持续负载 | 15 分钟 | 80°C |

**内存测试：**

| 软件 | 测试内容 | 时长 |
|------|---------|------|
| MemTest86 | 内存稳定性 | 跑 1-2 轮 |
| TestMem5 | 快速内存测试 | 跑 3 轮 |

**硬盘测试：**

| 软件 | 测试内容 | 关注指标 |
|------|---------|---------|
| CrystalDiskMark | 顺序和随机读写 | 速度是否达标 |
| CrystalDiskInfo | 硬盘健康状态 | 温度、通电时间、健康度 |
| AS SSD Benchmark | 综合性能 | 分数和延迟 |

### 烤机时关注什么？

1. **温度**：CPU 和显卡满载温度是否正常，过高说明散热没装好
2. **蓝屏/死机**：烤机过程中蓝屏说明硬件不稳定，可能是内存频率太高或电源不够
3. **降频**：温度过高会触发降频保护，用 HWInfo64 查看是否有过热降频
4. **功耗**：用功率计测量整机功耗，确认电源够用

### 烤机结果判断

* **30 分钟无蓝屏、温度正常**：基本稳定
* **蓝屏**：内存问题最常见，降频试试；也可能是电源不够
* **温度过高**：散热器没装好，重新涂硅脂、拧紧螺丝
* **花屏/黑屏**：显卡问题，检查供电和接触

## 装完之后

### 系统优化

装完系统、驱动、烤机都通过后，建议做以下优化：

1. **关闭不需要的开机启动项**：任务管理器 → 启动
2. **调整电源计划**：高性能或卓越性能模式
3. **关闭系统通知**：设置 → 系统 → 通知
4. **清理临时文件**：磁盘清理或 CCleaner
5. **创建系统还原点**：以备不时之需

更多优化内容见 [Windows 优化](/pc-diy/windows-optimization)。

### 软件安装建议

装完系统后安装软件的顺序建议：

1. **浏览器**：Chrome / Edge / Firefox
2. **解压软件**：7-Zip 或 Bandizip
3. **输入法**：系统自带就够，或装搜狗
4. **办公软件**：Office 或 WPS
5. **通讯软件**：微信、QQ
6. **播放器**：PotPlayer 或 VLC
7. **安全软件**：Windows Defender 够用，不用装 360

**软件安装注意事项：**

* 从官网下载，别从下载站下
* 安装时看清楚有没有捆绑软件
* 自定义安装路径，别都装 C 盘
* 安装路径用英文，避免兼容性问题

***

以上就是从零开始装机的完整流程。跟着步骤来，第一次装机也能顺利点亮。遇到问题别慌，90% 的问题都是线没插紧。

---

---
url: https://ain.hmgf.hxcn.space/pc-diy/hardware-buying-guide.md
---
# 硬件选购

买电脑配件，不是越贵越好，关键是搭配均衡。CPU 和显卡要匹配，显示器要验清楚，每个环节都有坑。这篇指南帮你把钱花在刀刃上。

## CPU 选购

### 买电脑如何选择 CPU？教你避坑不踩雷

CPU 是电脑的核心，选错了后面都白搭。这个视频讲了 Intel 和 AMD 两家的命名规则、代数区别、核心数和频率的关系。

### 2025 年 CPU 选购建议

**Intel 平台推荐：**

| 型号 | 核心/线程 | 适合场景 | 参考价格 |
|------|----------|---------|---------|
| i3-12100F | 4/8 | 办公、轻度游戏 | 500 元左右 |
| i5-12400F | 6/12 | 主流游戏、日常使用 | 700 元左右 |
| i5-13600KF | 14/20 | 高性能游戏、轻度创作 | 1500 元左右 |
| i7-13700K | 16/24 | 高端游戏、视频剪辑 | 2500 元左右 |
| i9-13900K | 24/32 | 发烧级、专业工作 | 3500 元左右 |

**AMD 平台推荐：**

| 型号 | 核心/线程 | 适合场景 | 参考价格 |
|------|----------|---------|---------|
| R5 5600 | 6/12 | 预算有限、主流游戏 | 600 元左右 |
| R5 7600X | 6/12 | 主流游戏、新平台 | 1200 元左右 |
| R7 7700X | 8/16 | 高性能游戏、创作 | 1800 元左右 |
| R7 7800X3D | 8/16 | 游戏神器（3D V-Cache） | 2500 元左右 |
| R9 7950X | 16/32 | 专业工作、多任务 | 3500 元左右 |

**选购原则：**

1. **游戏为主**：优先单核性能，R7 7800X3D 是当前游戏最强 CPU
2. **生产力为主**：优先多核性能，核心数越多越好
3. **预算有限**：i5-12400F 或 R5 5600 性价比最高
4. **新装机**：建议上新平台（Intel 13 代 / AMD 7000 系），老平台以后升级空间小

### CPU 和主板怎么搭配？

| CPU | 推荐主板芯片组 | 说明 |
|-----|--------------|------|
| i3-12100F | H610 | 入门够用 |
| i5-12400F | B660 / B760 | 主流选择 |
| i5-13600KF | B760 / Z790 | 超频选 Z790 |
| i7-13700K | Z790 | 需要好的供电 |
| i9-13900K | Z790 旗舰 | 供电至少 16 相 |
| R5 7600X | B650 | 主流选择 |
| R7 7700X | B650 / X670 | 超频选 X670 |
| R7 7800X3D | B650 | 够用，不需要太贵 |
| R9 7950X | X670E | 旗舰供电 |

**注意：** 主板价格不要超过 CPU 价格，除非你有特殊需求（大量扩展设备、超频发烧）。i5 配 B 系列主板，i7/i9 配 Z 系列主板，这个搭配最合理。

## 显卡搭配

### 史上最强游戏党必看的 CPU 显卡搭配指南

CPU 和显卡要搭配均衡，不能一个太强一个太弱。这个视频包含 17 款 CPU、9 款显卡、6 种游戏的测试数据，用实际数据告诉你怎么搭配最合理。

### 显卡选购建议

**NVIDIA 显卡推荐：**

| 型号 | 显存 | 适合分辨率 | 适合场景 | 参考价格 |
|------|------|----------|---------|---------|
| RTX 4060 | 8GB | 1080P | 主流游戏 | 2200 元左右 |
| RTX 4060 Ti | 8GB/16GB | 1080P-2K | 高帧游戏 | 2800 元左右 |
| RTX 4070 | 12GB | 2K | 2K 高画质 | 3800 元左右 |
| RTX 4070 Ti Super | 16GB | 2K-4K | 2K 极致 / 4K 入门 | 5500 元左右 |
| RTX 4080 Super | 16GB | 4K | 4K 高画质 | 7000 元左右 |
| RTX 4090 | 24GB | 4K+ | 旗舰 / AI | 13000 元左右 |

**AMD 显卡推荐：**

| 型号 | 显存 | 适合分辨率 | 适合场景 | 参考价格 |
|------|------|----------|---------|---------|
| RX 7600 | 8GB | 1080P | 预算游戏 | 1800 元左右 |
| RX 7700 XT | 12GB | 2K | 2K 游戏 | 2800 元左右 |
| RX 7800 XT | 16GB | 2K | 2K 高画质 | 3500 元左右 |
| RX 7900 GRE | 16GB | 2K-4K | 高性能 | 4200 元左右 |
| RX 7900 XT | 20GB | 4K | 4K 游戏 | 5500 元左右 |
| RX 7900 XTX | 24GB | 4K | A 卡旗舰 | 6500 元左右 |

**N 卡和 A 卡怎么选？**

| 考虑因素 | 选 NVIDIA | 选 AMD |
|---------|-----------|--------|
| 光线追踪 | 更好 | 一般 |
| DLSS/FSR | DLSS 更成熟 | FSR 开源通用 |
| AI 功能 | CUDA 生态完善 | ROCm 支持有限 |
| 驱动稳定性 | 好 | 现在也不错 |
| 性价比 | 一般 | 通常更高 |
| 视频编码 | NVENC 很强 | 也不错 |

**简单总结：**

* 玩 3A 大作、需要光追、做 AI：选 NVIDIA
* 预算有限、纯游戏、不在意光追：选 AMD 性价比更高

### CPU 和显卡怎么搭配才不浪费？

**搭配原则：** 显卡预算通常是整机预算的 30-40%。

| 预算区间 | CPU 推荐 | 显卡推荐 |
|---------|---------|---------|
| 3000-4000 元 | i5-12400F / R5 5600 | RTX 4060 / RX 7600 |
| 5000-6000 元 | i5-13600KF / R5 7600X | RTX 4060 Ti / RX 7700 XT |
| 7000-8000 元 | i5-13600KF / R7 7700X | RTX 4070 / RX 7800 XT |
| 10000-12000 元 | i7-13700K / R7 7800X3D | RTX 4070 Ti Super |
| 15000 元以上 | i9-13900K / R9 7950X | RTX 4080 Super / 4090 |

**什么情况会 CPU 瓶颈？**

* 1080P 低画质高帧率游戏：CPU 跟不上显卡的输出速度
* 策略游戏、模拟游戏：大量 AI 计算吃 CPU
* 网游多开：每个窗口都要 CPU 处理

**什么情况会显卡瓶颈？**

* 4K 高画质游戏：显卡渲染不过来
* 光追游戏：光追计算全靠显卡
* AI 绘图、深度学习：显存和算力是关键

## 内存选购

### DDR4 vs DDR5，现在怎么选？

**2025 年建议：新装机直接上 DDR5。**

| 对比项 | DDR4 | DDR5 |
|--------|------|------|
| 价格 | 便宜 | 已经降下来了 |
| 性能 | 够用 | 更好，尤其是 1% low 帧 |
| 升级空间 | 到头了 | 未来主流 |
| 兼容性 | 老平台 | 新平台 |

**内存容量怎么选？**

| 使用场景 | 推荐容量 |
|---------|---------|
| 办公、上网、看视频 | 8GB（勉强够） |
| 主流游戏、日常使用 | 16GB（推荐） |
| 高端游戏、轻度创作 | 32GB（够用） |
| 视频剪辑、3D 建模 | 32-64GB |
| AI 训练、专业渲染 | 64GB+ |

**内存频率怎么选？**

* DDR4：3200MHz 或 3600MHz，性价比最高
* DDR5：6000MHz 是甜点，AMD 平台最佳频率
* 时序 CL 值越低越好，但价格也越贵

**品牌推荐：**

* 高端：芝奇幻锋戟、海盗船复仇者
* 主流：金士顿 FURY、英睿达
* 性价比：光威、阿斯加特

**一定要买两根组双通道！** 单通道和双通道性能差距 10-20%，尤其是游戏帧数。

## 主板选购

### 主板选购要点

主板是最容易被忽略的配件，但它决定了整机的扩展性和稳定性。

**选购清单：**

1. **芯片组**：决定支持的 CPU 和功能，跟 CPU 配套选
2. **供电相数**：高端 CPU 需要好的供电，入门 CPU 不用太在意
3. **内存插槽**：最大支持容量、最高频率、是否支持 XMP/EXPO
4. **M.2 接口**：数量、位置、是否支持 PCIe 5.0
5. **PCIe 插槽**：显卡槽是 x16 还是 x8，有没有额外的 x1 槽
6. **USB 接口**：后面板和前面板各多少个、什么版本
7. **网络**：千兆还是 2.5G 网口、有没有 Wi-Fi
8. **音频**：声卡芯片型号、有没有独立音频区域
9. **I/O 挡板**：一体式还是分体式（一体式安装方便）
10. **BIOS 功能**：Flash BIOS 按钮（不用 CPU 也能更新 BIOS）

**品牌选择：**

| 品牌 | 特点 | 代表系列 |
|------|------|---------|
| 华硕 | 用料好、BIOS 好用、售后好 | ROG、TUF、PRIME |
| 微星 | 性价比高、功能全 | MEG、MAG、PRO |
| 技嘉 | 供电堆料足 | AORUS、EAGLE、UD |
| 华擎 | 价格便宜、功能够用 | Steel Legend、Pro RS |

## 电源选购

### 电源怎么选？别在电源上省钱

电源是整机的供电核心，选不好可能烧硬件。电源炸了可能带走主板、显卡、硬盘，损失比电源贵多了。

**功率计算：**

简单公式：CPU TDP + 显卡 TDP + 150W 余量

| 配置 | 推荐电源功率 |
|------|------------|
| i5 + RTX 4060 | 550W |
| i5 + RTX 4070 | 650W |
| i7 + RTX 4070 Ti | 750W |
| i7 + RTX 4080 | 850W |
| i9 + RTX 4090 | 1000W |

**认证等级：**

| 等级 | 转换效率 | 价格 | 建议 |
|------|---------|------|------|
| 白牌 | 80% | 便宜 | 不推荐 |
| 铜牌 | 85% | 适中 | 预算有限可以选 |
| 金牌 | 90% | 主流 | 推荐 |
| 白金 | 92% | 贵 | 高端平台 |
| 钛金 | 94% | 很贵 | 发烧级 |

**模组类型：**

* **全模组**：线材全可拆，走线方便，推荐
* **半模组**：主板线固定，其他线可拆，够用
* **非模组**：线材全固定，便宜但走线麻烦

**品牌推荐：**

* 高端：海韵、振华、海盗船
* 主流：酷冷至尊、安钛克、鑫谷
* 性价比：长城、航嘉

**ATX 3.0 是什么？**

ATX 3.0 是新的电源标准，原生支持 12VHPWR 显卡供电接口，不需要转接线。RTX 4070 Ti 及以上的显卡建议选 ATX 3.0 电源，转接线烧接口的案例不少。

## 机箱选购

### 机箱怎么选？

机箱不只是装硬件的盒子，它影响散热、走线、扩展性和美观。

**选购要点：**

1. **板型兼容**：确认支持你的主板大小（ATX / M-ATX / ITX）
2. **显卡限长**：高端显卡很长，确认机箱能装下
3. **散热器限高**：塔式风冷很高，确认机箱空间够
4. **风道设计**：前进后出、下进上出是主流风道
5. **硬盘位**：需要装机械硬盘的话看有没有硬盘笼
6. **前面板接口**：USB-C 有没有、几个 USB-A
7. **理线空间**：背面理线空间够不够，有没有理线槽
8. **防尘网**：进风口有没有防尘网，好清理

**机箱大小怎么选？**

| 板型 | 推荐机箱 | 优点 | 缺点 |
|------|---------|------|------|
| ITX | 迷你机箱 | 体积小、好看 | 扩展性差、装机难度高 |
| M-ATX | 中小机箱 | 性价比高、够用 | 扩展性一般 |
| ATX | 中塔机箱 | 扩展性好、兼容性强 | 体积大 |
| E-ATX | 全塔机箱 | 最强扩展 | 很占地方 |

**风道建议：**

* 前面板进风（2-3 个风扇）
* 后面板出风（1 个风扇）
* 顶部出风（2-3 个风扇，或装水冷排）
* 底部进风（电源独立风道）

风扇不是越多越好，多了反而互相干扰。3 进 2 出或 3 进 3 出就够用了。

## 散热器选购

### 风冷和水冷怎么选？

**风冷推荐：**

| 型号 | 适合 CPU | 参考价格 |
|------|---------|---------|
| 利民 PA120 | i5 / R5 | 100 元左右 |
| 利民 FC140 | i7 / R7 | 180 元左右 |
| 猫头鹰 D15 | i7 / i9 / R9 | 500 元左右 |

**水冷推荐：**

| 型号 | 适合 CPU | 参考价格 |
|------|---------|---------|
| 利民 Frozen Magic 240 | i7 / R7 | 300 元左右 |
| 恩杰 Kraken X63 | i7 / R7 | 600 元左右 |
| 华硕 ROG 龙神 360 | i9 / R9 | 1500 元左右 |

**选购建议：**

* i5 / R5 及以下：百元风冷够了
* i7 / R7：双塔风冷或 240 水冷
* i9 / R9：360 水冷起步
* 追求安静：选大风扇低转速的散热器

## 显示器选购

### 史上最强显示器收货验机指南

显示器是最容易踩坑的配件。这个视频七大步骤一站式避坑：检查坏点、漏光、色差、刷新率是否虚标。

### 显示器选购要点

**关键参数：**

| 参数 | 说明 | 建议 |
|------|------|------|
| 分辨率 | 清晰度 | 27 寸选 2K，32 寸选 4K |
| 刷新率 | 流畅度 | 游戏选 144Hz+，办公 60Hz 够 |
| 面板类型 | 色彩和响应 | IPS 最通用，VA 对比度好 |
| 响应时间 | 拖影程度 | 5ms 以内够用 |
| 色域 | 色彩范围 | sRGB 100% 是基础 |
| 色准 | 色彩准确度 | ΔE<3 肉眼看不出偏差 |
| HDR | 高动态范围 | HDR600 以上才有意义 |
| 接口 | 连接方式 | DP 1.4 够用，HDMI 2.1 更好 |

**不同用途怎么选？**

| 用途 | 推荐配置 |
|------|---------|
| 办公 | 27 寸 2K IPS，60Hz 够用 |
| 游戏（FPS） | 24-27 寸 1080P/2K，240Hz+，响应快 |
| 游戏（3A） | 27-32 寸 2K/4K，144Hz+，画质好 |
| 设计 | 27 寸 4K IPS，色准 ΔE<2，广色域 |
| 影音 | 32 寸 4K OLED/Mini-LED，HDR 好 |

**显示器品牌推荐：**

* 高端：戴尔、LG、华硕、明基
* 主流：小米、AOC、宏碁、飞利浦
* 电竞：卓威（TN 面板，FPS 专用）

## 验货注意事项

### 各配件验货要点

**CPU：**

* 检查包装是否完好，封条有没有撕开
* 检查针脚/触点有没有损坏
* 对照型号和包装是否一致

**内存：**

* 检查金手指有没有划痕
* 确认容量和频率跟包装一致
* 上机后用 CPU-Z 确认颗粒信息

**固态硬盘：**

* 用 CrystalDiskInfo 检查通电时间和写入量（应该是 0 或很小）
* 用 CrystalDiskMark 跑速度，确认达标
* 检查容量是否正确

**显卡：**

* 检查 PCB 有没有损坏
* 确认型号标签和实际一致
* 上机跑 3DMark 确认性能正常

**显示器：**

* 检查坏点：纯色背景下看有没有亮点或暗点
* 检查漏光：黑色背景下看边缘有没有漏光
* 检查刷新率：UFO Test 网站确认是否真高刷
* 检查色差：用校色仪或肉眼对比

**电源：**

* 检查线材有没有破损
* 确认功率和认证等级跟包装一致
* 有条件用功率计测一下实际输出

***

以上就是硬件选购的全部建议。记住一个原则：**均衡搭配，别在某一个配件上堆太多钱，也别在某一个配件上省太多钱。** CPU 和显卡是核心，电源和散热别省，内存和硬盘够用就行。

---

---
url: https://ain.hmgf.hxcn.space/pc-diy/hardware-knowledge.md
---
# 硬件科普

用电脑得懂点硬件知识，不然被商家忽悠了都不知道。这里把 CPU、显卡、主板、硬盘、显示器、键盘、网络这些核心硬件的基础知识整理在一起，看完你就能跟商家正常对话了。

## CPU

### CPU 是如何命名的，数字更大就一定更好吗？

CPU 命名规则比想象中复杂得多。Intel 的 i7 不一定比 i5 强，AMD 的锐龙 7 也不一定比锐龙 5 强。要看**代数**、**后缀**和**具体型号**。

**Intel 命名规则（以酷睿 Ultra 为例）：**

| 组成部分 | 含义 | 示例 |
|---------|------|------|
| 品牌 | 酷睿 / 酷睿 Ultra | Core Ultra 9 |
| 等级 | 3/5/7/9，数字越大定位越高 | Ultra **7** 265K |
| 代数 | 第一位数字，越大越新 | Ultra 7 **2**65K = 第2代 |
| SKU | 后三位数字，同代内越大越强 | Ultra 7 2**65**K |
| 后缀 | K=可超频，F=无核显，H=标压移动，U=低压移动 | 265**K** |

**常见后缀含义：**

* **K**：解锁倍频，可超频，性能最强
* **F**：无内置核显，必须搭配独立显卡
* **KF**：既可超频又无核显
* **H**：标压移动端，性能强但功耗高
* **HX**：移动端旗舰，功耗更高
* **U**：低压移动端，省电但性能弱
* **T**：低功耗桌面版

**AMD 命名规则（以锐龙为例）：**

| 组成部分 | 含义 | 示例 |
|---------|------|------|
| 品牌 | 锐龙 / 锐龙 AI | Ryzen 9 |
| 等级 | 3/5/7/9，数字越大定位越高 | Ryzen **9** 9950X |
| 代数 | 第一位数字，越大越新 | Ryzen 9 **9**950X = 第9代 |
| SKU | 后三位数字 | Ryzen 9 9**950**X |
| 后缀 | X=高性能，G=有核显，无后缀=标准版 | 9950**X** |

**常见后缀含义：**

* **X**：高性能版，加速频率更高
* **G**：内置核显（APU）
* **X3D**：搭载 3D V-Cache，游戏性能暴涨
* **E**：低功耗版
* **无后缀**：标准版

**关键结论：** 同品牌内，代数比等级更重要。13 代 i5 可能比 12 代 i7 还强，锐龙 7000 系的 R5 也能打赢 5000 系的 R7。买新不买旧是大原则。

### 核心数和线程数是什么关系？

核心数是 CPU 物理计算单元的数量，线程数是能同时处理的任务数。Intel 的超线程技术和 AMD 的同步多线程（SMT）能让一个核心同时处理两个线程，所以通常线程数是核心数的两倍。

但核心数多不代表一定快。单核性能（主频 × IPC）同样重要，很多游戏和日常软件更依赖单核性能。视频渲染、3D 建模这类任务才真正吃多核。

### 主频、睿频、加速频率有什么区别？

* **基础频率（Base Clock）**：CPU 在满载时保证能跑到的最低频率
* **睿频 / 加速频率（Turbo / Boost Clock）**：轻载时自动提升到的最高频率
* **全核加速频率**：所有核心同时工作时能达到的最高频率

实际使用中，CPU 会根据负载自动调整频率。轻度任务（如浏览网页）只用到少数核心，频率会拉得很高；重度任务（如渲染）所有核心一起工作，频率会降一些。所以单核睿频高不代表持续性能强，要看全核加速频率。

## 显卡

### 从零开始认识显卡

显卡分独立显卡和集成显卡。独立显卡有自己独立的显存和供电，性能强，适合游戏和专业工作；集成显卡集成在 CPU 里，用系统内存当显存，够日常办公和轻度游戏用。

**两大阵营：**

* **NVIDIA（英伟达）**：市场占有率最高，CUDA 生态完善，AI 和创意工作首选
* **AMD**：性价比通常更高，开源驱动支持好，A 卡战未来

**显卡命名规则：**

NVIDIA GeForce RTX 4090：

* **RTX**：支持光线追踪的系列（GTX 是老系列）
* **40**：第 40 系（代数）
* **90**：定位，数字越大越强（90>80>70>60>50）
* 后缀：Ti=加强版，Super=小幅升级版

AMD Radeon RX 7900 XTX：

* **RX**：游戏显卡系列
* **7**：第 7000 系（代数）
* **900**：定位
* **XTX**：旗舰后缀，XT 次旗舰

### GeForce Experience 里那些被你忽略的强大功能

NVIDIA 显卡自带的 GeForce Experience（现已更名为 NVIDIA App）不只是驱动更新工具。它能自动优化游戏设置、录制游戏视频（ShadowPlay）、直播推流，还有 AI 增强的画质提升功能（RTX Video Super Resolution）。

**实用功能清单：**

* **ShadowPlay**：几乎无性能损耗的游戏录制，支持即时回放（保存刚才 30 秒的画面）
* **Freestyle**：游戏内滤镜，可以调色调、锐化、添加效果
* **Ansel**：游戏内截图工具，支持自由视角、超级分辨率截图
* **NVIDIA Broadcast**：AI 降噪、虚拟背景、目光接触，视频会议神器
* **RTX VSR**：浏览器视频 AI 超分辨率，看低清视频也能清晰

### 一文厘清：GPU、NPU、TPU、CUDA 都是什么？

* **GPU（图形处理器）**：显卡的核心，擅长并行计算，有几千个小核心同时干活
* **NPU（神经网络处理器）**：专门优化 AI 推理任务，功耗低，集成在新 CPU 里
* **TPU（张量处理器）**：谷歌自研的 AI 芯片，主要用于云端训练
* **CUDA**：NVIDIA 的并行计算平台和编程框架，绝大多数 AI 框架都依赖它
* **Tensor Core**：NVIDIA 显卡里的 AI 专用计算单元，加速矩阵运算
* **RT Core**：光线追踪专用硬件单元，加速光影渲染

### 显存容量和位宽哪个更重要？

显存容量决定能处理多大的数据（高分辨率纹理、AI 模型），位宽决定数据进出显存的速度。两者要配合好，光容量大但位宽窄，数据进出会成为瓶颈。

**显存带宽 = 显存频率 × 位宽 ÷ 8**

举例：RTX 4060 Ti 有 8GB 显存、128-bit 位宽，虽然容量够用，但位宽窄导致高分辨率下性能受限。RTX 4070 是 192-bit 位宽，带宽大很多，高分辨率表现好得多。

**选购建议：**

* 1080P 游戏：8GB 够用
* 2K 游戏：12GB 比较稳妥
* 4K 游戏：16GB 以上
* AI 绘图 / 大模型：24GB 起步（RTX 4090）

## 主板

### 从零开始认识主板

主板是所有硬件的连接平台，选主板主要看**芯片组**、**供电**、**扩展性**和**接口**。

**芯片组决定上限：**

| 芯片组 | 定位 | 超频支持 | PCIe 通道数 |
|--------|------|---------|------------|
| Intel Z790 | 旗舰 | 支持 CPU 和内存超频 | 最多 |
| Intel B760 | 主流 | 仅内存超频 | 够用 |
| Intel H770 | 中高端 | 仅内存超频 | 较多 |
| Intel H610 | 入门 | 不支持 | 最少 |
| AMD X670E | 旗舰 | 支持 | 最多 |
| AMD B650 | 主流 | 支持 | 够用 |
| AMD A620 | 入门 | 不支持 | 最少 |

**供电相数怎么看：**

供电相数越多，每相分担的电流越小，发热越低，供电越稳定。高端 CPU（i9、R9）至少要 12 相以上供电，主流 CPU（i5、R5）6-8 相就够。

**扩展插槽：**

* **PCIe x16**：插显卡的，看是 PCIe 4.0 还是 5.0
* **PCIe x1**：插声卡、网卡等扩展卡
* **M.2**：插固态硬盘，看支持 PCIe 4.0 还是 5.0
* **内存插槽**：看支持 DDR4 还是 DDR5，最大容量和频率

**接口数量：**

* USB 接口数量和版本（USB 2.0/3.0/3.2/4）
* SATA 接口数量（接机械硬盘和 SATA 固态）
* 视频输出接口（HDMI/DP，用核显时需要）
* 网口（千兆还是 2.5G）
* 音频接口（看声卡芯片型号）

### 板型大小有什么区别？

| 板型 | 尺寸 | 适用场景 |
|------|------|---------|
| E-ATX | 305×330mm | 旗舰平台，扩展性最强 |
| ATX | 305×244mm | 标准大小，大多数机箱兼容 |
| M-ATX | 244×244mm | 紧凑型，性价比高 |
| ITX | 170×170mm | 迷你主机，扩展性有限 |

小板不一定比大板差，主要是扩展插槽和接口数量少。如果只插一张显卡、一条固态，M-ATX 完全够用，还便宜。

## 硬盘

### 固态硬盘的缓存是干什么的？有缓存和无缓存有什么区别？

固态硬盘的缓存是用来存放 FTL（闪存转换层）映射表的，有了它能快速找到数据在闪存颗粒里的位置。

**三种方案对比：**

| 类型 | 原理 | 优点 | 缺点 | 代表型号 |
|------|------|------|------|---------|
| DRAM 缓存 | 独立 DRAM 芯片存映射表 | 持续读写都快，稳定性好 | 成本高，贵一点 | 三星 990 Pro、西数 SN850X |
| HMB 无缓 | 借用一小部分系统内存当缓存 | 便宜，日常够用 | 持续大文件写入会掉速 | 致态 TiPlus7100、海力士 P41 |
| 无缓无 HMB | 用闪存颗粒本身存映射表 | 最便宜 | 随机性能差，不适合做系统盘 | 入门级固态 |

**实际体验差距：**

* 日常使用（开机、开软件、玩游戏）：几乎感觉不到差别
* 持续大文件写入（几十 GB 以上）：DRAM 缓存的更稳定
* 专业工作（视频剪辑、数据库）：建议选有 DRAM 缓存的

### PCIe 4.0 和 5.0 固态有什么区别？

| 规格 | 理论顺序读取 | 理论顺序写入 | 实际体验 |
|------|------------|------------|---------|
| PCIe 3.0 x4 | 3500 MB/s | 3000 MB/s | 够用 |
| PCIe 4.0 x4 | 7000 MB/s | 5000 MB/s | 主流选择 |
| PCIe 5.0 x4 | 14000 MB/s | 10000 MB/s | 目前溢价高 |

日常使用根本感觉不到 PCIe 4.0 和 5.0 的差别，游戏加载也就快个零点几秒。PCIe 5.0 固态目前价格贵、发热大，除非你是专业用户需要持续高速读写，否则 PCIe 4.0 性价比更高。

### 固态硬盘颗粒类型怎么看？

| 颗粒类型 | 每单元存储比特 | 寿命 | 速度 | 价格 |
|---------|--------------|------|------|------|
| SLC | 1 bit | 最长 | 最快 | 最贵 |
| MLC | 2 bit | 长 | 快 | 贵 |
| TLC | 3 bit | 中等 | 中等 | 主流 |
| QLC | 4 bit | 短 | 慢 | 便宜 |

现在主流是 TLC 颗粒，日常使用寿命完全够写到电脑淘汰。QLC 颗粒便宜但寿命短，适合当仓库盘存电影游戏，不建议做系统盘。

## 显示器

### OLED 和 LCD 到底怎么选？

| 特性 | OLED | LCD（IPS） | LCD（VA） |
|------|------|-----------|-----------|
| 对比度 | 无限（纯黑） | 1000:1 | 3000:1 |
| 响应时间 | 0.1ms | 1-5ms | 4-8ms |
| 色彩 | 色域广，色准高 | 色准好 | 色彩一般 |
| 亮度 | 中等（全屏） | 高 | 高 |
| 寿命 | 有烧屏风险 | 长 | 长 |
| 价格 | 贵 | 适中 | 便宜 |
| 适合场景 | 影音、暗场景游戏、设计 | 办公、设计、通用 | 影音、预算有限 |

**OLED 烧屏是怎么回事？**

OLED 每个像素独立发光，长时间显示同一画面会导致某些像素老化不均匀，留下残影。现在的 OLED 显示器都有防烧屏技术（像素刷新、亮度均匀、徽标检测），正常使用不用担心。但如果你每天 8 小时开着固定任务栏和窗口，LCD 更省心。

**Mini-LED 是什么？**

Mini-LED 是 LCD 的背光升级版，用几千个小型 LED 做背光分区，比传统 LCD 对比度高很多，接近 OLED 的黑场表现，但没有烧屏风险。价格介于 LCD 和 OLED 之间。

### 1ms 响应的屏幕也有拖影？运动模糊详解

运动模糊和响应时间、刷新率都有关系。

* **响应时间**：像素切换颜色的速度，1ms 是 GTG（灰阶响应），实际 MPRT（运动画面响应）可能更慢
* **刷新率**：屏幕每秒刷新的次数，144Hz 比 60Hz 画面更流畅
* **运动模糊**：像素还没完全切换到新颜色就开始显示下一帧，导致拖影

**为什么 1ms 响应还会有拖影？**

1. 厂商标的 1ms 是最佳情况下的 GTG，实际全范围响应可能 5-10ms
2. 即使响应时间达标，如果刷新率低，画面还是会卡顿
3. 人眼对运动画面有视觉暂留，这不是屏幕能解决的

**怎么选高刷显示器？**

* 60Hz → 144Hz：提升巨大，用了回不去
* 144Hz → 240Hz：提升明显，FPS 游戏玩家推荐
* 240Hz → 360Hz+：边际递减，除非你是电竞选手

### 分辨率和尺寸怎么搭配？

| 分辨率 | 推荐尺寸 | 像素密度（PPI） | 适用场景 |
|--------|---------|---------------|---------|
| 1080P（1920×1080） | 24 英寸 | 92 PPI | 预算有限、FPS 游戏 |
| 2K（2560×1440） | 27 英寸 | 109 PPI | 主流选择，画质和性能平衡 |
| 4K（3840×2160） | 32 英寸 | 138 PPI | 专业设计、3A 大作 |
| 超宽（3440×1440） | 34 英寸 | 110 PPI | 生产力、沉浸式游戏 |

**像素密度（PPI）** 是决定清晰度的关键，不是分辨率越高越好。24 寸 1080P 和 27 寸 2K 的 PPI 差不多，体感清晰度类似。

## 游戏性能

### 游戏帧数越高越流畅？未必！详解 1% low 帧

帧数高不一定流畅。**1% low 帧**才是关键，它反映最卡那 1% 时间的帧数表现。

**这些指标分别代表什么：**

* **平均帧（Average FPS）**：整体平均帧数，参考价值有限
* **1% low 帧**：最卡的 1% 时间段的平均帧数，反映卡顿程度
* **0.1% low 帧**：最极端的卡顿，偶尔出现的大卡顿
* **帧生成时间（Frame Time）**：每帧渲染耗时，比帧数更直观

**举个例子：**

* 游戏 A：平均帧 120，1% low 90 → 非常流畅
* 游戏 B：平均帧 120，1% low 30 → 虽然平均帧高，但会频繁卡顿

**什么影响 1% low 帧？**

1. **内存频率和时序**：影响最大的因素之一，DDR5 6000 比 DDR5 4800 的 1% low 帧高很多
2. **CPU 单核性能**：游戏逻辑主要靠单核
3. **显卡驱动优化**：新驱动可能修复卡顿问题
4. **游戏优化**：有些游戏天生优化差，跟硬件无关

### 垂直同步、G-Sync、FreeSync 有什么用？

这三种技术都是为了解决画面撕裂（上下画面错位）：

* **垂直同步（V-Sync）**：强制帧率和刷新率同步，消除撕裂但会增加延迟
* **G-Sync**：NVIDIA 的自适应刷新率技术，显示器跟着显卡节奏走，无撕裂且低延迟
* **FreeSync**：AMD 的同类技术，免费开放，现在很多显示器都支持

**建议：**

* 竞技游戏（CS、Valorant）：关闭垂直同步，开 G-Sync/FreeSync
* 3A 大作：开 G-Sync/FreeSync，帧率不稳时体验更好
* 显示器选购：优先选支持 G-Sync Compatible 或 FreeSync 的

## 键盘

### 什么是键盘延迟？键盘延迟是如何产生的？

键盘延迟是按下按键到电脑接收信号的整个过程的耗时。这个过程包括：

1. **按键触发行程**：手指按下去触发开关的时间（机械键盘约 2ms）
2. **键盘扫描**：键盘控制器扫描矩阵的时间（通常 1ms）
3. **传输延迟**：USB/无线传输到电脑的时间（USB 约 1ms，无线看协议）
4. **系统处理**：操作系统处理输入信号的时间（约 1-2ms）

**总延迟大约 5-10ms**，高端游戏键盘能做到 1-3ms。

**有线 vs 无线延迟：**

* 有线 USB：延迟最低且稳定，约 1ms 传输
* 2.4G 无线：延迟也很低（1-2ms），但受干扰可能波动
* 蓝牙：延迟最高（5-15ms），不适合游戏

**延迟测试数据参考：**

| 键盘类型 | 平均延迟 | 适合场景 |
|---------|---------|---------|
| 有线机械键盘 | 1-3ms | 电竞、游戏 |
| 2.4G 无线机械 | 2-5ms | 游戏、通用 |
| 蓝牙机械 | 8-15ms | 办公、打字 |
| 薄膜键盘 | 5-15ms | 办公 |

### 机械键盘轴体怎么选？

| 轴体类型 | 手感 | 声音 | 适合场景 |
|---------|------|------|---------|
| 红轴 | 直上直下，轻盈 | 安静 | 游戏、长时间打字 |
| 茶轴 | 有轻微段落感 | 适中 | 万金油，游戏办公都行 |
| 青轴 | 段落感强，咔嗒声 | 很响 | 打字爽，但吵人 |
| 银轴 | 行程短，触发快 | 安静 | 电竞，快速触发 |
| 静电容 | 软弹手感 | 安静 | 高端打字体验 |

**选购建议：**

* 宿舍 / 办公室：选红轴或茶轴，别选青轴
* 电竞游戏：银轴或红轴，触发快
* 长时间打字：茶轴或静电容，手感舒适
* 想体验段落感又怕吵：选茶轴，青轴会被人打

## 网络

### IP 地址是什么东西？IPv6 和 IPv4 有什么区别？

IP 地址就像网络里的门牌号，设备有了它才能互相找到。

**IPv4 vs IPv6：**

| 特性 | IPv4 | IPv6 |
|------|------|------|
| 地址长度 | 32 位（约 43 亿个） | 128 位（够给每粒沙子分配） |
| 地址格式 | 192.168.1.1 | 2001:db8::1 |
| 现状 | 地址枯竭，靠 NAT 续命 | 逐步普及中 |

**公网 IP 和私有 IP：**

* **公网 IP**：互联网上全球唯一的地址，别人能直接找到你
* **私有 IP**：局域网内部地址，不能直接从外网访问

**私有 IP 地址范围：**

* A 类：10.0.0.0 ~ 10.255.255.255（大型企业用）
* B 类：172.16.0.0 ~ 172.31.255.255（中型企业用）
* C 类：192.168.0.0 ~ 192.168.255.255（家庭路由器最常见）

**NAT 是什么？**

家庭宽带通常只有一个公网 IP，但家里有手机、电脑、平板好几个设备。路由器通过 NAT（网络地址转换）把私有 IP 转换成公网 IP，让多个设备共享一个公网 IP 上网。

**什么时候需要公网 IP？**

* 远程访问家里的 NAS 或电脑
* 搭建服务器
* P2P 下载、联机游戏
* 远程桌面

没有公网 IP 也能上网，但做以上事情会比较麻烦，需要内网穿透。

### 网线、Wi-Fi、Mesh 组网怎么选？

| 方式 | 速度 | 稳定性 | 延迟 | 适用场景 |
|------|------|--------|------|---------|
| 网线直连 | 最快（万兆可选） | 最稳定 | 最低 | 台式机、NAS |
| Wi-Fi 6/6E | 快（最高 9.6Gbps） | 受干扰 | 低 | 手机、笔记本 |
| Wi-Fi 7 | 更快（最高 46Gbps） | 更好 | 更低 | 旗舰设备 |
| Mesh 组网 | 看回程方式 | 较好 | 中等 | 大户型全屋覆盖 |

**Wi-Fi 6 和 Wi-Fi 6E 区别：**

* Wi-Fi 6：2.4GHz + 5GHz 双频
* Wi-Fi 6E：新增 6GHz 频段，干扰少，速度快，但穿墙差

**Mesh 组网要点：**

* 有线回程（节点之间用网线连接）效果最好
* 无线回程方便但速度打折扣
* 节点数量不是越多越好，多了反而互相干扰

## 内存

### DDR4 和 DDR5 有什么区别？

| 特性 | DDR4 | DDR5 |
|------|------|------|
| 起步频率 | 2133MHz | 4800MHz |
| 主流频率 | 3200-3600MHz | 5600-6400MHz |
| 电压 | 1.2V | 1.1V（更省电） |
| 单条最大容量 | 32GB | 64GB |
| 是否兼容 | - | 不兼容 DDR4 插槽 |

**DDR5 现在值得买吗？**

2025 年了，DDR5 价格已经降到合理区间，新装机建议直接上 DDR5。Intel 12/13/14 代同时支持 DDR4 和 DDR5（看主板），AMD 锐龙 7000 系只支持 DDR5。

**内存频率和时序怎么平衡？**

* **频率**：越高带宽越大，对游戏帧数有帮助
* **时序（CL值）**：越低延迟越小
* **实际延迟 = CL ÷ 频率 × 2000**

举例：DDR5 6000 CL30 的实际延迟 = 30 ÷ 6000 × 2000 = 10ns，DDR5 4800 CL40 = 40 ÷ 4800 × 2000 = 16.67ns。所以高频低延迟才是最优解。

**双通道很重要：**

两根内存组成双通道，带宽翻倍。游戏性能提升 10-20%，尤其是 1% low 帧。一定要买两根，别买单根。

## 电源

### 电源选购要点

电源是整机的供电核心，选不好可能烧硬件。别在电源上省钱。

**关键参数：**

* **额定功率**：持续输出功率，不是峰值功率
* **80 Plus 认证**：转换效率认证，铜牌/银牌/金牌/白金/钛金
* **模组类型**：全模组（线材可拆）、半模组（主板线固定）、非模组（线材全固定）
* **ATX 版本**：ATX 3.0 支持新显卡的 12VHPWR 接口

**功率怎么算？**

简单算法：CPU TDP + 显卡 TDP + 150W（其他硬件和余量）

举例：i5-13600K（125W）+ RTX 4070（200W）+ 150W = 475W，选 550W 或 650W 电源。

**80 Plus 认证等级：**

| 等级 | 50% 负载转换效率 | 价格 |
|------|----------------|------|
| 白牌 | 80% | 最便宜 |
| 铜牌 | 85% | 便宜 |
| 金牌 | 90% | 主流选择 |
| 白金 | 92% | 高端 |
| 钛金 | 94% | 发烧级 |

日常使用金牌就够了，转换效率高意味着更省电、发热更少。

## 散热

### 风冷和水冷怎么选？

| 类型 | 优点 | 缺点 | 适合 CPU |
|------|------|------|---------|
| 塔式风冷 | 便宜、可靠、不漏液 | 高端 CPU 压不住 | i5/R5 及以下 |
| 双塔风冷 | 性能强、性价比高 | 体积大、可能挡内存 | i7/R7 |
| 240 水冷 | 性能好、不挡内存 | 贵、有漏液风险 | i7/R7 |
| 360 水冷 | 性能最强 | 最贵、需要大机箱 | i9/R9 |

**散热器选购建议：**

* i5-13600K / R5 7600X：百元塔式风冷（如利民 PA120）就够
* i7-13700K / R7 7700X：双塔风冷或 240 水冷
* i9-13900K / R9 7950X：360 水冷起步

**硅脂多久换一次？**

一般 2-3 年换一次。如果发现温度比以前高了很多，可能就是硅脂干了。换硅脂时涂薄薄一层就行，不是越多越好。

***

以上就是硬件基础知识的全部内容。了解这些，你就能跟商家正常对话，不会被忽悠了。想看更多细节，可以点击各个章节里的 B 站视频链接。

---

---
url: https://ain.hmgf.hxcn.space/pc-diy/windows-optimization.md
---
# Windows 优化

新电脑到手，或者系统用久了变卡，总得花点时间调教一下。先把系统设置调好，后面用起来会顺手很多。这篇指南覆盖系统设置、效率技巧、预装软件清理、账户权限等各方面。

## 系统调教

### Windows 系统超基础必学调教指南

新机开荒是第一步。很多人拿到电脑就急着装软件，但先把系统设置调好更重要。这个视频覆盖了动画效果、后台服务、隐私选项、基础设置、软件下载安装注意事项。

### 全网最好的电脑优化与新机开荒攻略，没有之一

另一个高质量的优化攻略，讲得更系统全面。如果你想要一个完整的优化清单，这个视频会更适合。

### Win11 优化设置指南

专门针对 Windows 11 的优化设置教程。让你的电脑干净又流畅，从视觉效果到后台服务都有覆盖。

### Windows 11 必做的优化设置

以下是装完系统后建议立刻做的优化：

**1. 关闭不需要的视觉效果**

系统动画会占用资源，关掉后响应更快：

设置 → 辅助功能 → 视觉效果 → 关闭"动画效果"和"透明效果"

或者：系统属性 → 高级 → 性能设置 → 调整为最佳性能（或自定义保留"平滑屏幕字体边缘"）

**2. 关闭不需要的后台应用**

设置 → 应用 → 已安装的应用 → 点击不需要的应用 → 高级选项 → 后台应用权限 → 从不

**3. 关闭通知和建议**

设置 → 系统 → 通知 → 关闭以下：

* "获取提示和建议"
* "获取使用 Windows 时的提示和建议"
* "显示 Windows 欢迎体验"

设置 → 隐私和安全性 → 常规 → 关闭所有选项

**4. 关闭开机自启动**

Ctrl+Shift+Esc 打开任务管理器 → 启动 → 禁用不需要的启动项

保留：杀毒软件、显卡驱动、输入法
禁用：微信、QQ、各种管家、更新服务

**5. 调整电源计划**

设置 → 系统 → 电源和电池 → 电源模式 → 最佳性能

或者：控制面板 → 电源选项 → 选择"高性能"或"卓越性能"

**6. 关闭系统保留存储**

设置 → 系统 → 存储 → 高级存储设置 → 保留的存储 → 关闭（需要管理员权限）

这个功能会预留 7GB 空间给系统更新，小容量硬盘建议关掉。

**7. 关闭传递优化**

设置 → Windows 更新 → 高级选项 → 传递优化 → 关闭"允许从其他电脑下载"

这个功能会用你的带宽给别人传更新文件，相当于 P2P。

**8. 设置默认应用**

设置 → 应用 → 默认应用 → 把浏览器、视频播放器、图片查看器改成你喜欢的

**9. 关闭搜索索引（如果不用 Windows 搜索）**

搜索框搜"服务" → 找到"Windows Search" → 启动类型改为"禁用"

索引服务会持续占用磁盘和 CPU 资源，如果你习惯直接找文件而不是用搜索，可以关掉。

**10. 清理磁盘空间**

设置 → 系统 → 存储 → 开启"存储感知" → 配置清理计划

或者手动清理：磁盘清理 → 清理系统文件 → 勾选 Windows 更新清理、临时文件

## 效率技巧

### 电脑最废物的 Win 键，却藏着上班摸鱼提效神技

Win 键看起来没什么用，但配合其他键能实现很多快捷操作。

### Win 键常用快捷键

**基础操作：**

| 快捷键 | 功能 |
|--------|------|
| Win | 打开开始菜单 |
| Win + E | 打开文件资源管理器 |
| Win + D | 显示桌面（再按恢复） |
| Win + L | 锁屏 |
| Win + I | 打开设置 |
| Win + A | 打开操作中心（Wi-Fi、蓝牙、亮度） |
| Win + S | 打开搜索 |
| Win + Tab | 任务视图（所有窗口和桌面） |

**窗口管理：**

| 快捷键 | 功能 |
|--------|------|
| Win + ←/→ | 窗口靠左/靠右半屏 |
| Win + ↑/↓ | 窗口最大化/最小化 |
| Win + Shift + ←/→ | 窗口移动到左/右显示器 |
| Win + Ctrl + ←/→ | 切换虚拟桌面 |
| Win + Ctrl + D | 新建虚拟桌面 |
| Win + Ctrl + F4 | 关闭当前虚拟桌面 |
| Alt + Tab | 切换窗口 |
| Alt + F4 | 关闭当前窗口 |

**系统工具：**

| 快捷键 | 功能 |
|--------|------|
| Win + R | 打开运行对话框 |
| Win + X | 打开快捷菜单（相当于右键开始按钮） |
| Win + V | 打开剪贴板历史（需要先开启） |
| Win + Shift + S | 截图工具（矩形、任意、窗口、全屏） |
| Win + G | 打开 Xbox Game Bar（录屏、截图） |
| Win + . | 打开表情和特殊字符面板 |

**实用技巧：**

| 快捷键 | 功能 |
|--------|------|
| Win + 数字键 | 打开/切换任务栏上第 N 个应用 |
| Win + T | 在任务栏图标间切换 |
| Win + Pause | 打开系统属性 |
| Win + Ctrl + Shift + B | 重置显卡驱动（黑屏时救命） |
| Ctrl + Shift + Esc | 直接打开任务管理器 |

### 文件资源管理器效率技巧

**必知快捷键：**

| 快捷键 | 功能 |
|--------|------|
| Ctrl + N | 新建窗口 |
| Ctrl + W | 关闭当前标签页 |
| Ctrl + 鼠标滚轮 | 改变图标大小 |
| Alt + ←/→ | 前进/后退 |
| Alt + P | 预览窗格 |
| F2 | 重命名 |
| F4 | 地址栏下拉列表 |
| F11 | 全屏 |

**快速访问：**

* 把常用文件夹拖到左侧"快速访问"
* 右键固定常用文件夹到开始菜单或任务栏

**显示文件扩展名：**
文件资源管理器 → 查看 → 显示 → 文件扩展名

这个很重要，能防止被伪装的病毒文件骗到（比如 `文件名.pdf.exe`）。

### 剪贴板历史

Win + V 开启剪贴板历史后，可以保存多条复制记录，不用反复切换窗口复制粘贴。

设置 → 系统 → 剪贴板 → 开启"剪贴板历史"

### 虚拟桌面

虚拟桌面可以让你把工作和娱乐分开，或者给不同项目开不同桌面。

* Win + Ctrl + D：新建桌面
* Win + Ctrl + ←/→：切换桌面
* Win + Tab：查看所有桌面

**使用场景：**

* 桌面 1：工作（Office、浏览器、邮件）
* 桌面 2：娱乐（游戏、视频、音乐）
* 桌面 3：学习（笔记、资料、PDF）

## 账户权限

### Windows 中普通管理员、超级管理员和标准账户都有什么区别？

Windows 里有三种账户类型：

| 账户类型 | 权限 | 适用场景 |
|---------|------|---------|
| 标准用户 | 最低，需要输入密码才能安装软件 | 给小孩或老人用 |
| 管理员（普通） | 可以安装软件、改设置，但有 UAC 弹窗 | 日常使用推荐 |
| Administrator（超级管理员） | 最高权限，无 UAC 弹窗 | 不建议日常使用 |

**为什么建议用普通管理员，不用 Administrator？**

1. UAC 弹窗是安全保护，能防止软件偷偷修改系统
2. Administrator 权限太高，误操作可能搞坏系统
3. 中了病毒，Administrator 权限下病毒能做更多坏事

**怎么查看当前账户类型？**

设置 → 账户 → 你的信息 → 看"管理员"还是"标准用户"

### UAC（用户账户控制）怎么设置？

UAC 就是安装软件时弹出的那个"是否允许此应用对你的设备进行更改"的提示。

设置方法：控制面板 → 用户账户 → 更改用户账户控制设置

| 级别 | 说明 | 建议 |
|------|------|------|
| 始终通知 | 最安全，任何更改都通知 | 安全意识强的人 |
| 默认 | 应用尝试更改时通知 | 推荐 |
| 不通知 | 不推荐 | 不安全 |

建议保持默认级别，嫌烦可以调低一格，但别关掉。

## 预装软件清理

### Windows 也太臃肿了，这些预装软件都不用留

Windows 自带一堆预装软件，很多人根本用不到。

### 可以安全卸载的预装软件

**Windows 11 自带但大多数人用不到的：**

| 软件 | 说明 | 建议 |
|------|------|------|
| Cortana | 微软语音助手 | 国内基本没用，卸载 |
| Teams | 微软通讯工具 | 不用的话卸载 |
| Xbox Game Bar | 游戏录屏工具 | 不玩游戏可以卸载 |
| Clipchamp | 微软视频编辑器 | 有其他编辑器可以卸载 |
| 新闻 | 微软新闻应用 | 不看可以卸载 |
| 天气 | 天气应用 | 不用可以卸载 |
| 地图 | 微软地图 | 国内用高德百度，卸载 |
| OneNote | 微软笔记 | 不用可以卸载 |
| 照片 | 微软照片查看 | 可以保留 |
| 画图 3D | 3D 绘图工具 | 不用可以卸载 |
| 混合现实门户 | VR 相关 | 没 VR 设备卸载 |

**卸载方法：**

1. **开始菜单右键卸载**：最简单，右键 → 卸载
2. **设置里卸载**：设置 → 应用 → 已安装的应用 → 找到 → 卸载
3. **PowerShell 卸载**（顽固软件）：

```powershell
# 以管理员身份运行 PowerShell
# 卸载 Cortana
Get-AppxPackage *Microsoft.549981C3F5F10* | Remove-AppxPackage

# 卸载 Teams
Get-AppxPackage *MicrosoftTeams* | Remove-AppxPackage

# 卸载 Xbox Game Bar（不玩游戏可以卸载）
Get-AppxPackage *Microsoft.XboxGamingOverlay* | Remove-AppxPackage
```

**不要乱卸载的东西：**

* Microsoft Store（应用商店）
* Windows Security（安全中心）
* 计算器、记事本、截图工具（系统组件）
* Edge 浏览器（系统深度集成）

### 彻底卸载二次收费软件 OfficePLUS

有些软件卸载不干净会残留文件，甚至影响系统。这个视频以 OfficePLUS 为例，教你怎么彻底卸载有问题的软件。

### 彻底卸载软件的方法

普通卸载可能残留文件和注册表，彻底卸载建议：

**1. 用 Geek Uninstaller（免费）**

* 下载地址：https://geekuninstaller.com/
* 体积小、免安装、卸载干净
* 卸载后自动扫描残留文件和注册表

**2. 用 Revo Uninstaller**

* 下载地址：https://www.revouninstaller.com/
* 功能更强，有猎人模式
* 可以强制卸载顽固软件

**3. 手动清理残留**

* 删除安装目录（通常在 C:\Program Files 或 C:\Program Files (x86)）
* 删除用户数据（C:\Users\用户名\AppData\Local 和 Roaming）
* 清理注册表（谨慎操作，建议用工具）

**4. 清理注册表**

* Win + R 输入 `regedit` 打开注册表编辑器
* Ctrl + F 搜索软件名，删除相关项
* **注意：** 注册表操作有风险，删错可能系统出问题，建议先备份

## 磁盘管理

### C 盘空间不够怎么办？

C 盘满了系统会变卡，甚至无法更新。以下是清理方法：

**1. 磁盘清理工具**

* 右键 C 盘 → 属性 → 磁盘清理 → 清理系统文件
* 勾选：Windows 更新清理、临时文件、回收站
* 这个最安全，不会误删

**2. 存储感知**

* 设置 → 系统 → 存储 → 开启存储感知
* 配置自动清理计划（每天/每周/每月）
* 自动清理临时文件和回收站

**3. 迁移用户文件夹**

* 把文档、下载、桌面等文件夹移到其他盘
* 右键文件夹 → 属性 → 位置 → 移动

**4. 迁移软件安装路径**

* 新装软件时自定义安装路径到 D 盘
* 已经装在 C 盘的软件，部分可以迁移（用 Steam Mover 或手动）

**5. 关闭休眠功能**

```
powercfg -h off
```

可以释放几个 GB 空间（等于内存大小）

**6. 压缩系统文件**

* CompactOS 是 Windows 10/11 的功能，可以压缩系统文件节省空间
* 命令：`compact /compactos:always`
* 能节省 2-3GB，对性能影响很小

### 新硬盘怎么初始化和分区？

新买的硬盘需要初始化才能使用：

1. 按 Win + X → 磁盘管理
2. 新硬盘会弹出初始化对话框
3. 选择 GPT（推荐）或 MBR
4. 右键未分配空间 → 新建简单卷 → 按提示操作

**分区建议：**

* 系统盘（C 盘）：100-200GB，装系统和软件
* 数据盘（D 盘）：剩余空间，装游戏和文件
* 如果是 500GB 以下的硬盘，建议不分区，全给 C 盘

## 网络优化

### 网速慢怎么排查？

网速慢不一定是网络的问题，可能是系统设置的问题：

**1. 检查网卡驱动**

* 设备管理器 → 网络适配器 → 右键网卡 → 更新驱动
* 去主板官网下载最新的网卡驱动

**2. 关闭 Windows 更新占用带宽**

* 设置 → Windows 更新 → 高级选项 → 传递优化 → 关闭
* 或者限制下载带宽

**3. 修改 DNS**

* 推荐 DNS：
  * 阿里：223.5.5.5 / 223.6.6.6
  * 腾讯：119.29.29.29
  * Cloudflare：1.1.1.1 / 1.0.0.1
* 设置方法：网络设置 → 更改适配器选项 → 右键属性 → IPv4 → 手动设置 DNS

**4. 关闭流量限制**

* 设置 → 网络和 Internet → 数据使用量 → 关闭流量上限

**5. 重置网络**

* 设置 → 网络和 Internet → 高级网络设置 → 网络重置
* 或者命令行：`netsh winsock reset` 然后重启

## 安全设置

### Windows Defender 够用吗？

Windows Defender（Windows 安全中心）是 Windows 自带的杀毒软件，2025 年了，它已经足够强了：

**优点：**

* 免费、无广告、无弹窗
* 系统集成好，资源占用低
* 病毒库更新及时
* 误报率低

**缺点：**

* 偶尔误删文件
* 高级功能需要企业版
* 病毒查杀率略低于专业杀毒

**建议：** 日常使用 Windows Defender 够了，不用装第三方杀毒。如果经常下载破解软件，可以装一个 Malwarebytes（免费版）做补充扫描。

**不要装的东西：**

* 360 安全卫士（弹窗多、捆绑多）
* 2345 全家桶（广告多）
* 各种管家、助手（资源占用高）

### 防火墙怎么设置？

Windows 防火墙默认开启就好，不需要额外设置：

* 公共网络：开启防火墙，阻止所有不必要的连接
* 家庭网络：防火墙开启，但允许文件和打印机共享

**怎么检查防火墙状态？**

* 设置 → 隐私和安全性 → Windows 安全中心 → 防火墙和网络保护

## 常见问题

### 系统变卡了怎么办？

**1. 检查启动项**

* 任务管理器 → 启动 → 禁用不需要的
* 很多软件默认开机自启，白白占用资源

**2. 检查后台进程**

* 任务管理器 → 进程 → 按 CPU 或内存排序
* 找到占用高的进程，看是不是有问题

**3. 检查硬盘健康**

* 用 CrystalDiskInfo 检查硬盘健康状态
* 如果显示"警告"或"危险"，备份数据换硬盘

**4. 检查温度**

* 用 HWInfo64 查看 CPU 和显卡温度
* 温度过高会降频，导致变卡
* 清灰、换硅脂、改善散热

**5. 重置系统**

* 设置 → 系统 → 恢复 → 重置此电脑
* 保留文件：只重装系统，保留个人文件
* 删除所有：彻底重装，啥都不留
* 这是最后的手段，先试其他方法

### 蓝屏了怎么办？

蓝屏（BSOD）是系统遇到严重错误时的保护机制。

**1. 记录错误代码**

* 蓝屏时会显示错误代码（如 CRITICAL\_PROCESS\_DIED）
* 拍照记下来，搜索解决方案

**2. 常见蓝屏原因和解决：**

| 错误代码 | 原因 | 解决方法 |
|---------|------|---------|
| CRITICAL\_PROCESS\_DIED | 系统进程崩溃 | 重装系统或修复启动 |
| MEMORY\_MANAGEMENT | 内存问题 | 重新插拔内存，跑 MemTest |
| IRQL\_NOT\_LESS\_OR\_EQUAL | 驱动问题 | 更新或回退驱动 |
| PAGE\_FAULT\_IN\_NONPAGED\_AREA | 内存或硬盘问题 | 检查内存和硬盘 |
| KERNEL\_DATA\_INPAGE\_ERROR | 硬盘问题 | 检查硬盘健康，换数据线 |
| SYSTEM\_SERVICE\_EXCEPTION | 驱动或系统文件损坏 | 更新驱动，SFC 修复 |

**3. 通用排查步骤：**

1. 最近装了什么软件或驱动？卸载试试
2. 跑 MemTest86 检查内存
3. 跑 CrystalDiskInfo 检查硬盘
4. 更新显卡驱动
5. 运行 `sfc /scannow` 修复系统文件
6. 运行 `DISM /Online /Cleanup-Image /RestoreHealth` 修复系统映像
7. 最后手段：重装系统

### 开机慢怎么优化？

**1. 检查启动项**

* 任务管理器 → 启动 → 禁用不需要的
* 影响大的：各种云盘、通讯软件、更新服务

**2. 检查是否开了快速启动**

* 控制面板 → 电源选项 → 选择电源按钮的功能 → 启用快速启动
* 快速启动能加快开机速度，但可能导致一些问题（如无法访问 BIOS）
* 如果有问题可以关掉

**3. 检查硬盘**

* 如果系统装在机械硬盘上，开机肯定慢
* 换成固态硬盘，开机速度提升巨大（从 1 分钟变成 10 秒）

**4. 减少开机服务**

* Win + R 输入 `msconfig`
* 服务选项卡 → 勾选"隐藏所有 Microsoft 服务" → 禁用不需要的
* 谨慎操作，不知道是什么的服务别禁用

***

以上就是 Windows 优化的全部内容。优化不是一次性的事，系统用久了还是会变脏，建议每隔几个月清理一次。实在不行就重装系统，比重装快的是格式化重装。

---

---
url: https://ain.hmgf.hxcn.space/pc-diy/troubleshooting.md
---
# 电脑故障排查

电脑点不亮、蓝屏、重启，这些问题很常见。学会排查故障，不用每次都求人。这篇指南把常见故障的排查思路和解决方法都整理好了。

## 点不亮

### 电脑点不亮？黑屏？重启？史上最强电脑问题排查诊断攻略

电脑点不亮是最常见的问题。先检查电源线有没有接好，内存有没有插紧，显卡供电有没有接。主板上的 Debug 灯能指示问题所在，对照说明书看。

### 点不亮的排查流程

电脑点不亮不要慌，按这个顺序一步步排查：

**第一步：检查电源**

1. 电源线有没有插好（墙插和电源端都检查）
2. 电源背面的开关有没有打开（I 那边是开，O 那边是关）
3. 插排有没有开、有没有电
4. 换个插座试试

**第二步：检查供电线**

1. 主板 24pin 供电线有没有插紧
2. CPU 8pin 供电线有没有插紧（主板左上角）
3. 显卡供电线有没有插紧
4. 模组电源两端都要检查（电源端和主板端）

**第三步：检查硬件接触**

1. 内存重新拔插一次（最常见的问题）
2. 显卡重新拔插一次
3. CPU 检查有没有装好（不太可能松，但检查一下）
4. M.2 固态检查有没有插紧

**第四步：最小化测试**

如果以上都不行，做最小化测试：

1. 只留一根内存
2. 拔掉显卡（用核显的话）
3. 拔掉所有硬盘
4. 拔掉所有 USB 设备
5. 只留 CPU + 一根内存 + 电源

能点亮了再一个个加回去，找出是哪个硬件的问题。

**第五步：看 Debug 灯**

大多数主板都有 Debug 灯（或 Debug 数码管），能指示问题所在：

| 灯亮 | 可能问题 | 解决方法 |
|------|---------|---------|
| CPU 灯亮 | CPU 没装好或不兼容 | 重新安装 CPU，检查针脚 |
| DRAM 灯亮 | 内存问题 | 重新插拔内存，换槽试试 |
| VGA 灯亮 | 显卡问题 | 重新插拔显卡，检查供电 |
| BOOT 灯亮 | 启动设备问题 | 检查硬盘连接 |

**第六步：检查显示器**

1. 显示器有没有开、有没有接电源
2. 信号线有没有接对（接显卡，不是主板）
3. 显示器输入源选对了没有（HDMI/DP）
4. 换根线试试

### 有电但点不亮的常见原因

| 现象 | 可能原因 | 解决方法 |
|------|---------|---------|
| 风扇转但没画面 | 内存没插紧 | 重新插拔内存 |
| 风扇转但没画面 | 显卡没插紧 | 重新插拔显卡 |
| 风扇转但没画面 | 显示器线接错了 | 接显卡不是主板 |
| 反复重启 | CPU 过热 | 检查散热器 |
| 反复重启 | 内存频率太高 | 进 BIOS 降频 |
| 反复重启 | 电源功率不够 | 换大功率电源 |
| 有画面进不了系统 | 硬盘没接好 | 检查硬盘线 |
| 有画面进不了系统 | 启动顺序错误 | 进 BIOS 调整 |

### 新装机第一次点不亮怎么办？

新装机第一次点不亮，90% 是以下原因：

1. **内存没插紧**：最常见的原因，重新拔插，用力按到"咔嗒"一声
2. **CPU 供电线没接**：主板左上角的 8pin 线
3. **显示器线接错**：接到了主板而不是显卡
4. **电源没开**：背面开关没打到 I
5. **前面板跳线接错**：开机键线接错了位置

## 蓝屏

### 蓝屏了怎么办？常见蓝屏错误代码及解决方法

蓝屏（BSOD）是 Windows 遇到严重错误时的保护机制。别慌，大多数蓝屏都能解决。

### 常见蓝屏错误代码

| 错误代码 | 中文名 | 常见原因 | 解决方法 |
|---------|--------|---------|---------|
| CRITICAL\_PROCESS\_DIED | 关键进程终止 | 系统文件损坏 | SFC 修复或重装 |
| MEMORY\_MANAGEMENT | 内存管理 | 内存故障或不兼容 | 重新插拔，跑 MemTest |
| IRQL\_NOT\_LESS\_OR\_EQUAL | 驱动错误 | 驱动冲突或损坏 | 更新/回退驱动 |
| PAGE\_FAULT\_IN\_NONPAGED\_AREA | 页面错误 | 内存或硬盘故障 | 检查内存和硬盘 |
| KERNEL\_DATA\_INPAGE\_ERROR | 内核数据错误 | 硬盘问题 | 检查硬盘，换数据线 |
| SYSTEM\_SERVICE\_EXCEPTION | 系统服务异常 | 驱动或软件冲突 | 更新驱动，卸载问题软件 |
| DPC\_WATCHDOG\_VIOLATION | DPC 监视器超时 | 驱动响应太慢 | 更新 SSD 和芯片组驱动 |
| WHEA\_UNCORRECTABLE\_ERROR | 硬件错误 | CPU/内存/主板硬件问题 | 检查硬件，降低频率 |
| VIDEO\_TDR\_FAILURE | 显卡驱动超时 | 显卡驱动或硬件问题 | 更新驱动，检查显卡 |
| NTFS\_FILE\_SYSTEM | NTFS 文件系统错误 | 硬盘文件系统损坏 | 运行 chkdsk 修复 |

### 蓝屏排查步骤

**1. 记录错误代码**

* 蓝屏时拍照记录错误代码
* 事件查看器里也有详细信息：Win + X → 事件查看器 → Windows 日志 → 系统

**2. 最近改了什么？**

* 装了新软件？卸载试试
* 更新了驱动？回退试试
* 加了新硬件？拆掉试试
* 改了 BIOS 设置？恢复默认

**3. 硬件排查**

* 跑 MemTest86 检查内存（至少跑 1 小时）
* 跑 CrystalDiskInfo 检查硬盘健康
* 跑 FurMark 检查显卡稳定性
* 检查 CPU 和显卡温度

**4. 系统修复**

```
# 修复系统文件
sfc /scannow

# 修复系统映像
DISM /Online /Cleanup-Image /RestoreHealth

# 检查硬盘
chkdsk C: /f /r
```

**5. 最后手段**

* 重装系统
* 如果重装还蓝屏，基本是硬件问题

### 蓝屏日志在哪里看？

蓝屏时系统会生成 dump 文件，记录了当时的状态：

1. **小 dump 文件**：`C:\Windows\Minidump\` 目录下
2. **完整 dump 文件**：`C:\Windows\MEMORY.DMP`

用 BlueScreenView（免费工具）可以打开 dump 文件，快速定位是哪个驱动导致的蓝屏。

下载地址：https://www.nirsoft.net/utils/blue\_screen\_view.html

## 清灰维护

### 2026 全网最细心的笔记本清灰教程

笔记本用久了会积灰，导致散热变差、性能下降。清灰能让性能提升 30%，温度降到 60 度。

### 台式机清灰教程

台式机也需要清灰，建议每半年到一年清一次。

**清灰前准备：**

* 十字螺丝刀
* 压缩空气罐（或吹风机冷风）
* 软毛刷
* 干抹布

**清灰步骤：**

1. **关机断电**：拔掉电源线，按开机键放掉余电
2. **拆机箱侧板**：拧掉螺丝或按下卡扣
3. **清理风扇**：用压缩空气吹或软毛刷刷
   * CPU 散热器风扇
   * 显卡风扇
   * 机箱风扇
   * 电源风扇（不建议拆电源，从外面吹）
4. **清理防尘网**：拆下来水洗，晾干装回
5. **清理散热鳍片**：用压缩空气吹掉鳍片间的灰尘
6. **检查线材**：有没有松动或破损

**注意事项：**

* 不要用手摸主板上的元件
* 风扇不要用力转，可能损坏轴承
* 压缩空气罐倾斜会喷液体，保持直立
* 清完后检查风扇有没有插回供电线

### 笔记本清灰教程

笔记本清灰比台式机复杂，需要拆机。不建议新手自己操作，可以找售后或维修店。

**自己清灰的步骤：**

1. **查拆机教程**：在 B 站搜你的笔记本型号 + 拆机
2. **准备工具**：螺丝刀、撬棒、硅脂
3. **拆后盖**：拧掉所有螺丝，用撬棒撬开卡扣
4. **断电池**：先断电池排线，防止短路
5. **拆散热模组**：拧掉螺丝，轻轻提起
6. **清理风扇**：用刷子和压缩空气清理
7. **换硅脂**：擦掉旧硅脂，涂新的
8. **装回去**：按拆的反顺序装回

**风险提示：**

* 拆坏了不在保修范围内
* 螺丝长短不一样，装错位置可能拧穿主板
* 排线很脆弱，用力过大会断
* 没有把握就找专业人士

### 硅脂多久换一次？

* **台式机**：2-3 年换一次
* **笔记本**：1-2 年换一次（笔记本散热更紧张）

**什么时候该换硅脂？**

* CPU 温度比以前高了很多（比如以前满载 70°C，现在 90°C）
* 清灰后温度还是高
* 烤机时频繁降频

**硅脂推荐：**

* 性价比：利民 TF7、信越 7921
* 高端：暴力熊液金（需要小心操作）、信越 X-23

**涂硅脂方法：**

1. 用酒精擦掉旧硅脂
2. 新硅脂挤米粒大小在 CPU 中心
3. 装散热器时靠压力自然压平
4. 不要涂太多，溢出来可能短路

## 过热降频

### CPU 温度过高怎么办？

CPU 温度过高会触发保护机制，自动降频以减少发热。表现就是电脑变卡、游戏掉帧。

**正常温度范围：**

| 状态 | 正常温度 | 需要注意 | 过高 |
|------|---------|---------|------|
| 待机 | 30-45°C | 45-55°C | 55°C+ |
| 轻度使用 | 40-60°C | 60-70°C | 70°C+ |
| 满载 | 60-80°C | 80-90°C | 90°C+ |

**温度过高的解决方法：**

1. **清灰**：风扇和散热鳍片积灰是最常见原因
2. **换硅脂**：硅脂干了导热效果变差
3. **检查散热器**：散热器有没有装好、螺丝有没有拧紧
4. **改善机箱风道**：加机箱风扇，确保前进后出
5. **降低 CPU 功耗**：BIOS 里降低 PL1/PL2 功耗限制
6. **换更好的散热器**：原装散热器可能压不住

### 显卡温度过高怎么办？

显卡正常满载温度在 70-85°C，超过 90°C 就需要注意。

**解决方法：**

1. **清灰**：显卡风扇积灰
2. **换硅脂**：显卡硅脂也会干
3. **机箱风道**：确保显卡有足够进风
4. **降低功耗**：MSI Afterburner 降低功耗限制
5. **提高风扇转速**：用 MSI Afterburner 调风扇曲线
6. **显卡支架**：防止显卡弯曲影响散热

## 噪音问题

### 电脑噪音大怎么办？

电脑噪音主要来自风扇和硬盘。

**噪音来源排查：**

| 噪音类型 | 来源 | 解决方法 |
|---------|------|---------|
| 嗡嗡声 | 风扇转速高 | 调低风扇转速曲线 |
| 哒哒声 | 机械硬盘 | 换固态硬盘 |
| 嘎嘎声 | 风扇轴承坏了 | 换风扇 |
| 滋滋声 | 电流声（啸叫） | 正常现象，严重可换电源 |
| 呼呼风声 | 机箱风道不好 | 改善风道，加防尘网 |

**降低风扇噪音：**

1. **BIOS 里调风扇曲线**：低负载时降低转速
2. **换静音风扇**：猫头鹰、Arctic P12 等静音风扇
3. **加减震垫**：风扇和机箱之间加橡胶垫
4. **清理灰尘**：灰尘会让风扇失去平衡，产生噪音

**显卡啸叫（Coil Whine）：**

显卡高负载时发出的滋滋声，是电感振动导致的，不影响性能和寿命。无法完全消除，只能：

* 限制帧率减少负载
* 换电源（可能改善）
* 送售后（严重的可以换新）

## 硬件故障

### 内存故障怎么判断？

内存故障的表现：

* 蓝屏，错误代码 MEMORY\_MANAGEMENT
* 开机 Debug 灯 DRAM 亮
* 进系统后频繁崩溃
* 游戏闪退

**排查方法：**

1. **单根内存测试**：一次只插一根内存，找出坏的那根
2. **MemTest86 测试**：制作 U 盘启动盘，开机跑测试
   * 下载：https://www.memtest86.com/
   * 至少跑 1 小时，有错误就是内存问题
3. **换插槽**：排除主板插槽问题
4. **降频测试**：内存频率太高可能不稳定，降频试试

### 硬盘故障怎么判断？

硬盘故障的表现：

* 开机找不到硬盘
* 系统卡顿、文件打不开
* 蓝屏 KERNEL\_DATA\_INPAGE\_ERROR
* 文件莫名消失或损坏

**排查方法：**

1. **CrystalDiskInfo 检查**：
   * 健康状态：良好/注意/警告/危险
   * 重新分配扇区计数：不为 0 说明有坏块
   * 待映射扇区数：不为 0 说明有潜在问题

2. **检查数据线**：换根 SATA 数据线或换 M.2 插槽

3. **跑 CrystalDiskMark**：速度异常低说明硬盘有问题

4. **备份数据**：发现硬盘有问题第一时间备份，别等

### 电源故障怎么判断？

电源故障的表现：

* 电脑随机重启
* 开机偶尔点不亮
* 高负载时死机
* 有烧焦味

**排查方法：**

1. **检查电源功率**：用功率计测量整机功耗，看是否超过电源额定功率
2. **替换法**：借一个好的电源试试
3. **检查线材**：有没有破损、松动
4. **闻味道**：有烧焦味赶紧断电

### 显卡故障怎么判断？

显卡故障的表现：

* 花屏（屏幕上出现彩色条纹或方块）
* 黑屏（有声音没画面）
* 驱动频繁崩溃
* 游戏闪退

**排查方法：**

1. **更新驱动**：先排除软件问题
2. **降频测试**：用 MSI Afterburner 降频，稳定了说明是频率太高
3. **换显示线**：排除线材问题
4. **换显示器**：排除显示器问题
5. **跑 FurMark**：15 分钟内花屏或黑屏，显卡有问题
6. **核显测试**：拔掉独显，用核显开机，能正常说明独显有问题

## 软件故障

### 系统进不去怎么办？

**情况 1：卡在 Windows Logo**

* 强制关机三次，进入自动修复
* 安全模式下卸载最近装的软件或驱动
* 系统还原到之前的还原点
* 最后手段：重装系统

**情况 2：黑屏只有鼠标**

* Ctrl+Alt+Delete 看能不能打开任务管理器
* 任务管理器 → 文件 → 运行新任务 → 输入 `explorer.exe`
* 如果不行，进安全模式排查

**情况 3：无限重启**

* 进安全模式（开机时按 F8 或强制关机三次）
* 卸载最近的更新或驱动
* 系统还原
* 重装系统

### 怎么进安全模式？

**方法 1：设置里进**

* 设置 → 系统 → 恢复 → 高级启动 → 疑难解答 → 高级选项 → 启动设置 → 重启 → 按 F4

**方法 2：强制关机三次**

* 开机时看到 Logo 就强制关机
* 重复三次，系统会自动进入修复模式
* 疑难解答 → 高级选项 → 启动设置 → 重启 → 按 F4

**方法 3：命令行**

```
msconfig
```

引导 → 安全引导 → 确定 → 重启

**安全模式能做什么？**

* 卸载有问题的软件或驱动
* 运行杀毒软件扫描
* 系统还原
* 备份数据

### 怎么修复系统引导？

系统引导损坏会导致进不了系统，修复方法：

**方法 1：自动修复**

* 用 Windows 安装 U 盘启动
* 选择"修复计算机" → 疑难解答 → 启动修复

**方法 2：命令行修复**

```
bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd
```

**方法 3：重建 BCD**

```
bcdboot C:\Windows /s C: /f UEFI
```

## 数据恢复

### 误删文件怎么恢复？

误删文件后**立刻停止使用那个硬盘**，写入新数据会覆盖被删文件。

**恢复方法：**

1. **回收站**：最简单，直接还原
2. **文件历史记录**：如果开了这个功能，可以恢复以前的版本
3. **数据恢复软件**：
   * Recuva（免费）：简单易用
   * DiskGenius（免费版够用）：国产，功能强
   * R-Studio（付费）：专业级，恢复率高

**重要提示：**

* 数据恢复软件不要装在要恢复的硬盘上
* 恢复的文件保存到其他硬盘
* 机械硬盘误删后恢复率高，固态硬盘低（TRIM 会清理）

### 硬盘数据怎么备份？

**备份策略 3-2-1 原则：**

* **3** 份数据副本
* **2** 种不同存储介质
* **1** 份异地备份

**备份方法：**

* **系统备份**：用 Windows 自带的系统映像备份或第三方工具（如傲梅）
* **文件备份**：手动复制到移动硬盘，或用同步软件
* **云备份**：OneDrive、百度网盘、阿里云盘

***

以上就是电脑故障排查的全部内容。遇到问题别慌，90% 的问题都是小毛病，按步骤排查就能解决。实在搞不定，找专业人士或售后。

---

---
url: https://ain.hmgf.hxcn.space/contribution.md
description: 了解如何参与本站项目的维护与内容贡献。
---

# 贡献指南

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-slidev.md
description: >-
  面向本项目的 Slidev 使用指南，集中介绍仓库内主题的启用方式、 deck 独立访问地址、在 VitePress 中嵌入幻灯片的方法，以及
  Cloudflare Pages 下的联合部署阅读路径。
---

# Slidev 教程总览

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-slidev/theme.md
description: >-
  介绍本仓库内置的 Slidev 本地主题目录 theme-ain，包括主题文件结构、每个文件的职责、如何在 deck frontmatter
  中启用，以及为什么要复用文档站品牌变量。
---

# 项目 Slidev 主题使用

本仓库已经内置一套本地 Slidev 主题：`slides/theme-ain/`。

它的目标不是替代 Slidev 全部默认能力，而是做三件事：

1. 让封面、分节页和普通内容页更接近文档站的视觉风格。
2. 复用与 VitePress 一致的颜色、字体和背景变量。
3. 保持 deck 仍然可以像普通 Slidev 项目一样开发和构建。

## 主题目录

## 每个文件的职责

| 文件 | 作用 |
| --- | --- |
| `package.json` | 声明这是一个 Slidev 主题，并给出默认字体和主题变量。 |
| `styles/index.ts` | 引入 Slidev 基础布局样式，再接入本主题的 `layouts.css`。 |
| `styles/layouts.css` | 主题主样式文件，负责背景、排版、代码块、表格和页脚样式。 |
| `layouts/cover.vue` | 自定义封面布局。 |
| `layouts/default.vue` | 自定义普通页面布局。 |
| `layouts/section.vue` | 自定义章节分割页布局。 |
| `global-bottom.vue` | 所有非封面页共享的底部页脚，显示标题和页码。 |

## 如何启用

在 deck 文件头部的 frontmatter 里把 `theme` 指向本地主题目录。

```yaml
---
theme: ./theme-ain
title: 我的课程
download: false
fonts:
  provider: none
---
```

## 现有示例

当前仓库里已经切换到这套主题的 deck 包括：

* `slides/demo.md`
* `slides/2025-guide.md`

如果你要新建一个 deck，最简单的方式就是复制其中一个文件的头部配置，再替换标题和内容。

## 为什么要复用文档站变量

本项目把品牌变量抽到了 `docs/.vitepress/theme/brand-tokens.css`。

这样做的好处是：

* 文档站和幻灯片不会出现两套接近但不一致的蓝色系
* 字体栈只维护一份，不会一边改了另一边忘记跟进
* 后续如果要整体调整品牌风格，只需要改一份 token

## 新增布局时的建议

如果你后续还想补更多主题布局，优先遵守这几个约定：

* 先看当前 deck 是否真的需要新布局，不要为一个页面单独造主题。
* 新布局尽量只解决“结构”问题，把颜色和排版留在 `styles/layouts.css`。
* 能复用 Slidev 内置布局时就复用，不要重复实现。

## 下一步

* [查看 Slidev 独立访问链接](/contribution/project-slidev/standalone-access)
* [查看如何嵌入到文档中](/contribution/project-slidev/embed-in-docs)

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-slidev/standalone-access.md
description: >-
  说明本项目中 Slidev deck 的三类访问方式，帮助区分本地开发端口、VitePress 文档页地址，以及 Cloudflare Pages 上的
  /decks/主题名/ 独立访问链接。
---

# Slidev 独立访问链接

在这个仓库里，Slidev 至少会出现三种“看起来都能打开页面”的地址，但它们用途不同，不能混用。

## 1. 本地开发地址

开发时运行：

```bash
bun run slides:dev
bun run slides:2025
```

对应的访问地址类似：

```http
GET http://localhost:3030/
GET http://localhost:3031/
```

这些地址只在你的本地开发环境中存在，不能写进文档源码，也不能作为线上引用地址。

## 2. 文档站中的嵌入页地址

例如：

* `/slides/demo`
* `/slides/guide-2025`

这些页面对应的是 `docs/slides/*.md` 中的文档页。它们本身不是 deck 构建产物，而是“文档说明 + 嵌入播放器”的入口。

## 3. 线上独立 deck 地址

真正用于独立访问 deck 的地址是：

```http
GET /decks/demo/
GET /decks/guide-2025/
```

这些路径来自 `package.json` 里的 Cloudflare 构建脚本，例如：

```json
"cf:build:slide:demo": "slidev build slides/demo.md --base /decks/demo/ --out ../.cloudflare-dist/decks/demo --download false"
```

这里有两个关键参数：

* `--base /decks/demo/`
* `--out ../.cloudflare-dist/decks/demo`

前者决定线上访问前缀，后者决定最终输出目录。

## 为什么还需要 `_redirects`

因为 deck 是一个单页应用，访问内部路由时需要回退到 `index.html`。所以本仓库在 `docs/public/_redirects` 中配置了：

```http
/decks/demo/* /decks/demo/index.html 200
```

每新增一个 deck，都应补一条同类规则。

## 新增 deck 时要补哪些地方

新增 `slides/my-topic.md` 后，通常需要同步补这些位置：

1. `package.json`
   增加本地开发脚本和 `cf:build:slide:主题名` 构建脚本。
2. `cf:build:slides`
   把新 deck 的构建脚本串进去。
3. `docs/public/_redirects`
   添加 `/decks/主题名/* /decks/主题名/index.html 200`。
4. `docs/slides/`
   新增一个嵌入页，作为文档站入口。

## 最常见的错误

## 继续阅读

* [项目主题使用](/contribution/project-slidev/theme)
* [嵌入到文档中](/contribution/project-slidev/embed-in-docs)

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-slidev/embed-in-docs.md
description: >-
  介绍如何在 VitePress 文档页中嵌入 Slidev deck，包括 docs/slides 页面职责、SlideEmbed
  的标准写法，以及为什么不要直接使用 localhost 地址和不规范 iframe 属性。
---

# Slidev 嵌入到文档中

本项目已经提供了全局注册的 `SlideEmbed` 组件。对于文档页中的 deck 嵌入，优先使用它，而不是手写原始 `iframe`。

## 嵌入页应该写在哪里

嵌入页放在：

```text
docs/slides/
```

例如当前已有：

* `docs/slides/demo.md`
* `docs/slides/guide-2025.md`

这些页面负责两件事：

* 给读者看简短的使用说明
* 嵌入真正的 `/decks/主题名/` 产物

## 标准写法

```md
<SlideEmbed
  src="/decks/demo/"
  title="编程入门演示"
  :height="600"
/>
```

其中：

* `src` 指向线上 deck 地址
* `title` 提供 iframe 标题和无障碍文本
* `height` 控制嵌入区域高度

## 一个完整示例

```md
---
title: 编程入门演示幻灯片：VitePress 嵌入与交互示例
description: 用于展示在 VitePress 中嵌入 Slidev 的方式。
---

# 编程入门演示

::: tip 使用说明
- 点击幻灯片获得焦点
- 使用方向键或空格翻页
:::

<SlideEmbed src="/decks/demo/" title="编程入门演示" :height="600" />
```

## 为什么不建议直接写 iframe

仓库规范里已经明确：

* 优先使用 `SlideEmbed`
* 如果必须手写 `iframe`，只保留 `allow="fullscreen"`
* 不要写 `allowfullscreen`

`SlideEmbed` 的好处是已经封装了：

* 加载中占位态
* 加载超时后的重试入口
* 统一的高度与边框表现

所以除非你需要一个非常特殊的嵌入行为，否则没有必要退回原始 `iframe`。

## 两个常见误区

### 误区一：把 deck 地址写成 `/slides/demo`

`/slides/demo` 是文档页，不是 deck 产物地址。嵌入时应写：

```http
GET /decks/demo/
```

### 误区二：把本地端口写进 src

下面这种写法不能提交到仓库：

```md
<SlideEmbed src="http://localhost:3030/" title="本地演示" :height="600" />
```

因为其他人和线上环境都访问不到你的本地端口。

## 推荐做法

1. 先在 `slides/` 下写好 deck。
2. 再在 `docs/slides/` 下写一个嵌入页。
3. `src` 一律写 `/decks/主题名/`。
4. 最后跑 `bun run cf:build` 检查独立 deck 和文档嵌入页是否都能生成。

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components.md
description: 组件库总览页，集中入口到每个组件的独立使用文档，并按用途划分为布局导航、内容展示和表单反馈三组。
---

# 项目组件总览

```md
<Kbd keys="Ctrl+Shift+P" platform="win" />
<Progress label="构建进度" :value="72" show-value />
```

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/accordion.md
description: 使用 Accordion 与 AccordionItem 构建可折叠内容区域。
---

# Accordion 组件

`Accordion` 适合 FAQ、安装步骤、参数说明等“需要折叠/展开”的长内容。

## 基础用法

```md
<Accordion type="single" default-value="install">
  <AccordionItem value="install" title="安装依赖">...</AccordionItem>
  <AccordionItem value="dev" title="本地开发">...</AccordionItem>
</Accordion>
```

## 多开模式

## Props

### Accordion

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `type` | `single \| multiple` | `multiple` | 单开或多开。 | `type="single"` |
| `collapsible` | `boolean` | `true` | `single` 模式下是否允许全部收起。 | `:collapsible="false"` |
| `defaultValue` | `string \| string[]` | `''` | 初始展开项。 | `default-value="install"` |

### AccordionItem

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `value` | `string` | `''` | 项唯一值，不传时按 `title` 自动生成。 | `value="install"` |
| `title` | `string` | - | 标题（必填）。 | `title="安装依赖"` |
| `icon` | `string` | `''` | 标题图标。 | `icon="mdi:download-circle-outline"` |
| `defaultOpen` | `boolean` | `false` | 初始是否展开。 | `:default-open="true"` |
| `disabled` | `boolean` | `false` | 禁用状态。 | `:disabled="true"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/tabs.md
description: 使用 Tabs 与 Tab 构建页签内容，支持代码、多语言和文件树展示。
---

# Tabs 组件

`Tabs` 适合在同一块区域对比多种内容（如多语言代码、不同目录结构、不同配置方案）。

## 基础用法

```md
<Tabs default-value="ts" label="多语言示例">
  <Tab value="ts" label="TypeScript">...</Tab>
  <Tab value="py" label="Python">...</Tab>
  <Tab value="tree" label="File Tree">...</Tab>
</Tabs>
```

## 网盘下载切换

\<DownloadTabs
title="网盘下载"
:providers="\[
{ value: 'baidu', description: '主下载线路，适合国内网络环境。' },
{ value: '123pan', label: '123网盘', description: '备用下载线路。' }
]"

>

\<template #default="{ provider }">






## 禁用页签

## Props

### Tabs

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `label` | `string` | `Tabs` | 页签组可访问标签。 | `label="多语言示例"` |
| `defaultValue` | `string` | `''` | 初始激活 tab 的 `value`。 | `default-value="ts"` |

### Tab

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `value` | `string` | - | 唯一标识（必填）。 | `value="ts"` |
| `label` | `string` | `value` | 页签标题。 | `label="TypeScript"` |
| `icon` | `string` | `''` | 页签图标。 | `icon="mdi:language-typescript"` |
| `disabled` | `boolean` | `false` | 禁用该页签。 | `:disabled="true"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/breadcrumbs.md
description: 面包屑导航组件，支持手动定义路径、长路径折叠以及站点正文顶部自动导航。
---

# Breadcrumbs 组件

站点正文顶部已经默认接入 `Breadcrumbs`。如果你在文档内容里也需要手动展示路径，同样可以直接使用这个组件。

现在正文顶部的面包屑会根据容器宽度与屏幕方向自动折叠：横屏优先保留首页和末尾关键层级，竖屏优先保留首页与当前页；当前页标题会按剩余空间单行省略，并在截断时通过 `Popover` 展示完整文本。

桌面端文档页在向下滚动进入正文后，导航栏里的 tabs 会做简单位移淡出，并由与正文区域水平对齐的面包屑导航接替。

下面的演示路径统一对齐当前站点的信息架构，方便和正文顶部自动面包屑的实际效果直接对照。

## 手动用法

```md
<Breadcrumbs
  :items="[
    { key: 'resource', text: '资源', href: '/resource/' },
    { key: 'contribute', text: '贡献项目', href: '/resource/#贡献项目' },
    { key: 'components', text: '项目组件', href: '/resource/project-components' },
    { key: 'content', text: '内容展示', href: '/resource/project-components#内容展示' },
    { key: 'kbd', text: 'Kbd 组件', current: true }
  ]"
/>
```

## 自定义分隔符

## 长路径折叠

## 站点级自动面包屑

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `items` | `BreadcrumbItem[]` | - | 面包屑项数组。 | `:items="[{ key: 'a', text: '资源' }]"` |
| `separator` | `string` | `>` | 分隔符。 | `separator="/"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/link-buttons.md
description: 使用 LinkButtons 与 LinkButton 构建按钮组、状态按钮和自定义色按钮。
---

# Link Buttons 组件

`LinkButtons` 用于布局按钮组，`LinkButton` 用于单个按钮行为。

## 基础用法

```md
<LinkButtons>
  <LinkButton href="/guides/index.html" variant="solid">立即开始</LinkButton>
  <LinkButton href="/resource/index.html" variant="outline">查看资源</LinkButton>
  <LinkButton variant="soft" color="#00a899">自定义色按钮</LinkButton>
</LinkButtons>
```

## 状态与尺寸

## Props

### LinkButtons

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `align` | `start \| center \| end` | `start` | 对齐方式。 | `align="center"` |
| `wrap` | `boolean` | `true` | 是否允许换行。 | `:wrap="false"` |
| `gap` | `number` | `10` | 按钮间距（像素）。 | `:gap="14"` |

### LinkButton

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `href` | `string` | `''` | 跳转地址；不传时渲染为 `button`。 | `href="/guides/index.html"` |
| `target` | `string` | `''` | 链接打开方式。 | `target="_blank"` |
| `text` | `string` | `''` | 文本，不传时使用插槽。 | `text="立即开始"` |
| `icon` | `string` | `''` | 图标（Iconify）。 | `icon="mdi:rocket-launch-outline"` |
| `variant` | `solid \| outline \| soft \| ghost` | `solid` | 外观类型。 | `variant="outline"` |
| `state` | `default \| loading \| disabled \| success \| danger` | `default` | 状态。 | `state="loading"` |
| `size` | `sm \| md \| lg` | `md` | 尺寸。 | `size="lg"` |
| `color` | `string` | `''` | 自定义主题色。 | `color="#00a899"` |
| `block` | `boolean` | `false` | 是否占满整行。 | `:block="true"` |
| `disabled` | `boolean` | `false` | 禁用交互。 | `:disabled="true"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/link-cards.md
description: LinkCard 通用入口卡片，以及 GithubInfo / BilibiliCard 两种特殊卡片变体。
---

# Link Cards 组件

`LinkCard` 用于把文档入口做成统一视觉卡片，适合首页导航、章节跳转和资源推荐。

`GithubInfo` 与 `BilibiliCard` 是特殊形态的链接卡片：保留卡片式入口，但针对 GitHub 仓库与 B 站视频做了固定信息结构。

## 基础用法（默认样式）

```md
<LinkCard
  title="Markdown 创作"
  href="/guides/"
  description="面向内容编写的文档入口示例。"
  icon="mdi:card-text-outline"
  badge="推荐"
/>
```

## 图标/图片与位置（默认/长条通用）

## 三种排版

### 1. 默认样式（单列）

### 2. 长条形（每行 2 个）

### 3. 正方形（每行 4 个）






## GithubInfo（特殊 LinkCard）

面向 GitHub 仓库的紧凑卡片：展示 `owner/repo`，并请求公开 API 显示 stars / forks。

```md
<GithubInfo owner="vuejs" repo="core" />
```

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `owner` | `string` | `''` | 仓库所有者，必填。 | `owner="vuejs"` |
| `repo` | `string` | `''` | 仓库名，必填。 | `repo="core"` |
| `token` | `string` | `''` | 可选 GitHub token，提高 API 限额。 | `token="ghp_..."` |
| `baseUrl` | `string` | `https://api.github.com` | API 根地址。 | `base-url="https://api.github.com"` |

注意：

* 浏览器端直接请求 GitHub 公开 API；无 token 时可能受速率限制。
* 失败时仍保留仓库链接，计数显示为 `—`，并给出简短错误提示。

## BilibiliCard（特殊 LinkCard）

面向 B 站视频的入口卡片，固定使用 B 站品牌色与图标。

```md
<BilibiliCard
  title="示例视频入口"
  href="https://www.bilibili.com/video/BV1hDDRBeEib/"
  description="适合把教程视频做成可点击卡片。"
  author="官方账号"
/>

<!-- 或只给 bvid -->
<BilibiliCard
  title="示例视频入口"
  bvid="BV1hDDRBeEib"
  description="自动拼出 B 站视频链接。"
/>
```

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `title` | `string` | `''` | 卡片标题，必填。 | `title="安装演示"` |
| `href` | `string` | `''` | 完整视频链接；与 `bvid` 二选一。 | `href="https://www.bilibili.com/video/BVxxx/"` |
| `bvid` | `string` | `''` | B 站 BV 号；未给 `href` 时自动拼链接。 | `bvid="BV1hDDRBeEib"` |
| `description` | `string` | `''` | 描述文本。 | `description="入门演示"` |
| `author` | `string` | `''` | UP 主/来源。 | `author="官方账号"` |
| `cover` | `string` | `''` | 可选封面图。 | `cover="/demo-cover.jpg"` |
| `disabled` | `boolean` | `false` | 禁用交互。 | `:disabled="true"` |

## LinkCard Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `title` | `string` | `''` | 卡片标题，建议必填。 | `title="Markdown 创作"` |
| `href` | `string` | `''` | 跳转地址，建议必填。 | `href="/guides/"` |
| `description` | `string` | `''` | 描述文本。 | `description="课程入口"` |
| `icon` | `string` | `mdi:link-variant` | Iconify 图标。 | `icon="mdi:card-text-outline"` |
| `image` | `string` | `''` | 图片图标地址。 | `image="/favicon.ico"` |
| `imageAlt` | `string` | `''` | 图片替代文本。 | `image-alt="课程图标"` |
| `mediaPosition` | `left \| right \| background` | `left` | 图标/图片位置。 | `media-position="background"` |
| `layout` | `default \| strip \| square` | `default` | 卡片排版模式。 | `layout="strip"` |
| `badge` | `string` | `''` | 标题旁角标文本。 | `badge="推荐"` |
| `target` | `string` | `''` | 强制指定打开方式。 | `target="_blank"` |
| `disabled` | `boolean` | `false` | 禁用交互状态。 | `:disabled="true"` |

## 注意事项

* 组件名区分大小写，统一使用 PascalCase。
* 站内链接使用 Clean URL，不要写 `.html` 后缀。
* 当 `title` 或 `href` 缺失时，`LinkCard` 会显示 `<code>&lt;LinkCard /&gt;</code>` 占位。
* 在 `layout="square"` 下：
  `left` 表示 logo 在上方，`right` 表示 logo 在下方，`background` 表示 logo 在底部。

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/steps.md
description: 使用 Steps 与 Step 展示流程步骤和操作顺序。
---

# Steps 组件

`Steps` + `Step` 适合说明操作流程、任务清单和教程步骤。

## 基础用法

```md
<Steps>
  <Step title="创建页面">...</Step>
  <Step title="编写内容">...</Step>
  <Step title="本地验证">...</Step>
</Steps>
```

## 紧凑模式

## Props

### Steps

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `compact` | `boolean` | `false` | 紧凑模式，缩小步骤间距。 | `:compact="true"` |

### Step

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `title` | `string` | `''` | 步骤标题。 | `title="创建页面"` |
| `icon` | `string` | `''` | 步骤图标。 | `icon="mdi:file-document-plus-outline"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/asides.md
description: 使用 Aside 组件展示提示、警告和说明信息。
---

# Asides 组件

`Aside` 适合在正文中插入强调信息，如提示、警告、风险说明等。

## 基础用法

```md
<Aside type="tip" title="实践建议">
  先在组件文档页验证效果，再逐步迁移到正式讲义。
</Aside>
```

## 类型示例

## 自定义图标

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `type` | `note \| tip \| info \| warning \| caution \| danger` | `note` | 信息类型。 | `type="tip"` |
| `title` | `string` | `''` | 标题，不传时使用类型默认标题。 | `title="实践建议"` |
| `icon` | `string` | `''` | 覆盖默认图标。 | `icon="mdi:rocket-launch-outline"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/badges.md
description: 使用 Badge 组件表示状态、等级和标签信息。
---

# Badges 组件

`Badge` 适合在标题旁、列表项后、文案段落中标记状态。

## 基础用法

```md
<Badge type="tip" text="推荐" />
<Badge type="success" text="已上线" />
<Badge type="caution" text="实验中" />
<Badge type="danger" text="高优先级" />
```

## 轮廓和自定义色

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `type` | `note \| tip \| info \| warning \| caution \| danger \| success` | `note` | 徽标类型。 | `type="success"` |
| `text` | `string` | `''` | 文本，不传时可使用默认插槽。 | `text="已上线"` |
| `icon` | `string` | `''` | 图标（Iconify 名称）。 | `icon="mdi:check-circle-outline"` |
| `color` | `string` | `''` | 自定义主色。 | `color="#00a7b7"` |
| `outline` | `boolean` | `false` | 是否轮廓样式。 | `:outline="true"` |
| `size` | `sm \| md` | `md` | 徽标尺寸。 | `size="sm"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/code.md
description: 使用 Code 组件展示代码块，支持语言标签、Mermaid 主题、文件路径和一键复制。
---

# Code 组件

`Code` 用于展示代码片段，并支持：

* 按 `lang` 显示语言标签和配色（窄屏自动缩写）。
* `lang="mermaid"` 时支持主题预设和源码 / 渲染切换。
* 按 `path` 显示文件路径。
* 标题栏一键复制代码（统一 Toast 反馈）。
* markdown 原生代码块自动套用同一套样式与复制按钮。

## 显示规则

1. markdown 原生代码块：语言显示在左侧。
2. `Code` 未传 `path`：语言显示在左侧。
3. `Code` 传入 `path`：语言显示在复制按钮左侧。
4. 最左侧始终显示当前语言 icon（Iconify）。
5. 竖屏或路径过长（`>70`）时，语言标签自动切换缩写。

## 基础用法

\<Code
lang="ts"
path="src/components/link-card.ts"

>

export function createCard(title: string, href: string) {
return { title, href }
}


```md
<Code
  lang="ts"
  path="src/components/link-card.ts"
>
export function createCard(title: string, href: string) {
  return { title, href }
}
</Code>
```

## 使用默认插槽传代码

```md
<Code lang="py" path="scripts/math.py">
def add(a: int, b: int) -> int:
    return a + b
</Code>
```

## markdown 原生代码块（同样样式）

```ts
export function createCard(title: string, href: string) {
  return { title, href }
}
```

````md
```ts
export function createCard(title: string, href: string) {
  return { title, href }
}
```
````

## 支持的语言

```
需要主题、切换和组件级控制时，请使用 `Code lang="mermaid"`。
```

## Shell 与 root 用法

对于 `sh`、`bash`、`zsh`、`fish`、`nu` 这类 shell 语言：

* 默认会在每行前显示 `$`
* 如果需要表示必须使用 `root` 用户执行，可以写成 `<语言>-root`
* `-root` 会额外显示一个 `root` badge，并把每行前缀切换为 `#`
* 这些前缀是界面装饰，不会被复制按钮或鼠标拖拽复制进剪贴板

### Markdown 原生代码块

```bash-root
apt update
apt install -y nginx
systemctl restart nginx
```

````md
```bash-root
apt update
apt install -y nginx
systemctl restart nginx
```
````

### `Code` 组件写法

```md
<Code
  lang="zsh-root"
  path="scripts/bootstrap.zsh"
  :code="`brew update
brew install bun
source ~/.zshrc`"
/>
```

## Mermaid 渲染与主题

Mermaid 现在分两条能力线：

* Markdown 原生 `mermaid` fence：直接渲染图表，适合最轻量的文档写法。
* `Code lang="mermaid"`：支持 `mermaidTheme` 指定主题预设，支持 `mermaidView="code | render"` 指定默认视图，并可在“源码 / 渲染”之间切换。

这些主题预设整理自 [Nexmoe 的极简主题文章](https://nexmoe.com/zh/posts/mermaid-theme/)、[掘金的主题合集](https://juejin.cn/post/7525324923222818826)，并按 [Mermaid 官方 Theming 文档](https://mermaid.js.org/config/theming.html) 接入。需要注意的是：官方只允许在 `base` 主题上通过 `themeVariables` 做自定义；`handdrawn-pastel` 额外使用了 `look: 'handDrawn'`。

### Markdown 原生渲染

Markdown 原生 `mermaid` fence 会直接渲染为图，而不是普通代码块：

```mermaid
flowchart LR
  A[Write] --> B[Build]
  B --> C[Deploy]
```

这种写法不支持组件级主题指定，也不支持源码 / 渲染切换。

### `Code` 组件：主题指定与源码 / 渲染切换

```md
<Code
  lang="mermaid"
  mermaid-theme="pure-white"
  mermaid-view="render"
  path="docs/diagram/overview.mmd"
  :code="`flowchart LR
  A[Write] --> B[Build]
  B --> C[Review]
  C --> D[Deploy]`"
/>
```

### 主题预设

下面每个主题都给出真实预览，便于直接对比样式差异。

\<Accordion
type="multiple"
:default-value="\['mermaid-pure-white', 'mermaid-business-soft', 'mermaid-handdrawn-pastel', 'mermaid-tech-ice']"

>

如果你只想展示 Mermaid 源码本身，而不是渲染图，可以继续使用 `Code` 组件的默认行为，或者显式写 `mermaid-view="code"`：

```md
<Code lang="mermaid" :code="`flowchart LR
  A[Write] --> B[Build]
  B --> C[Deploy]`" />
```

## 自动换行与自定义强调色

\<Code
lang="json"
path="config/site.json"
:wrap="true"
color="#00a7b7"

>

{
"title": "Demo",
"description": "A long text for wrapping demo with automatic line wrapping enabled"
}


## 隐藏行号与禁用复制

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `lang` | `string` | `text` | 语言标识，会影响标签和强调色。 | `lang="ts"` |
| `path` | `string` | `''` | 显示文件路径。 | `path="src/utils/math.ts"` |
| `title` | `string` | `''` | 未传 `path` 时可用作标题。 | `title="示例代码"` |
| `code` | `string` | `''` | 代码文本；不传则读取默认插槽。 | `:code="'const sum = 1 + 2'"` |
| `icon` | `string` | `''` | 覆盖默认语言图标。 | `icon="mdi:code-tags"` |
| `wrap` | `boolean` | `false` | 是否自动换行。 | `:wrap="true"` |
| `color` | `string` | `''` | 自定义强调色。 | `color="#00a7b7"` |
| `hideLineNumbers` | `boolean` | `false` | 隐藏左侧行号。 | `:hide-line-numbers="true"` |
| `disableCopy` | `boolean` | `false` | 隐藏复制按钮并禁用复制行为。 | `:disable-copy="true"` |
| `mermaidTheme` | `string` | `default` | 仅 `lang="mermaid"` 生效，指定 Mermaid 主题预设。 | `mermaid-theme="tech-ice"` |
| `mermaidView` | `'code' \| 'render'` | `code` | 仅 `lang="mermaid"` 生效，指定默认显示源码还是渲染图。 | `mermaid-view="render"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/file-tree.md
description: 使用 FileTree、FileTreeFolder、FileTreeFile 展示目录结构。
---

# File Tree 组件

`FileTree` 由三个组件组成：

* `FileTree`：根容器。
* `FileTreeFolder`：目录节点。
* `FileTreeFile`：文件节点。

默认已为常见代码文件、办公文件、图片音视频文件配置图标，也支持自定义图标。现在也支持网盘下载场景：可在树顶部显示网盘下载头部，并在节点上展示大小、描述或可复制提取码。网盘节点中 `description` 与 `extractionCode` 为互斥展示。

## 基础用法

```md
<FileTree>
  <FileTreeFolder name="src" :default-open="true">
    <FileTreeFolder name="components" :default-open="true">
      <FileTreeFile name="LinkCard.vue" size="4 KB" description="卡片跳转组件" />
      <FileTreeFile name="Tabs.vue" size="5 KB" description="页签切换组件" />
    </FileTreeFolder>
    <FileTreeFile name="README.md" size="2 KB" description="组件说明入口" />
  </FileTreeFolder>
</FileTree>
```

## 网盘下载

\<DownloadTabs
title="网盘下载"
:providers="\[
{ value: 'baidu', description: '主下载线路，适合国内网络环境。' },
{ value: '123pan', label: '123网盘', description: '备用下载线路。' },
{ value: 'icloud', label: 'iCloud', description: '公开分享链接示例。' }
]"

>

\<template #default="{ provider }">








```md
<DownloadTabs
  title="网盘下载"
  :providers="['baidu', { value: '123pan', label: '123网盘' }]"
>
  <template #default="{ provider }">
    <FileTree :provider="provider?.alias || ''" :show-header="false">
      <FileTreeFile
        name="cyberdog_raceV2.tar"
        :links="{
          baidu: {
            href: 'https://pan.baidu.com/...',
            size: '9.8 GB',
            extractionCode: 'zxwg'
          },
          '123网盘': {
            href: 'https://www.123865.com/...',
            size: '9.8 GB',
            extractionCode: 'dWkW'
          }
        }"
      />
    </FileTree>
  </template>
</DownloadTabs>
```

## 自定义图标

## Props

### FileTree

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `label` | `string` | `File tree` | `role=tree` 的可访问标签。 | `label="项目目录"` |
| `variant` | `'default' \| 'download'` | `'default'` | 强制切换为普通模式或网盘下载模式；传入 `provider` 时默认会进入下载模式。 | `variant="download"` |
| `provider` | `string` | `''` | 网盘别名或全名，用于顶部标题和节点网盘信息。 | `provider="baidu"` |
| `providerName` | `string` | `''` | 覆盖顶部显示的网盘名称。 | `provider-name="校内镜像"` |
| `providerIcon` | `string` | `''` | 覆盖顶部显示的网盘图标。 | `provider-icon="provider:download"` |
| `showHeader` | `boolean` | `true` | 下载模式下是否显示顶部头部；多个网盘放在 Tabs 中时通常可关闭。 | `:show-header="false"` |
| `title` | `string` | `网盘下载` | 下载模式顶部标题。 | `title="镜像下载"` |
| `description` | `string` | `''` | 顶部补充说明。 | `description="提供多个网盘入口"` |

### FileTreeFolder

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `name` | `string` | - | 目录名（必填）。 | `name="src"` |
| `icon` | `string` | `''` | 目录图标（同时作为开关默认图标）。 | `icon="mdi:folder-star-outline"` |
| `openIcon` | `string` | `''` | 展开态图标。 | `open-icon="mdi:folder-open-outline"` |
| `closedIcon` | `string` | `''` | 折叠态图标。 | `closed-icon="mdi:folder-outline"` |
| `href` | `string` | `''` | 文件夹名后方显示跳转图标，点击跳转（与展开操作分离）。 | `href="/resource/project-components"` |
| `target` | `string` | `''` | 链接打开方式。 | `target="_blank"` |
| `defaultOpen` | `boolean` | `true` | 初始是否展开。 | `:default-open="false"` |
| `size` | `string` | `''` | 节点大小信息。 | `size="9.8 GB"` |
| `description` | `string` | `''` | 节点补充描述；下载模式下若同时传入 `extractionCode`，则优先显示提取码。 | `description="Docker 镜像"` |
| `provider` | `string` | `''` | 覆盖节点所属网盘。默认继承 `FileTree`。 | `provider="icloud"` |
| `extractionCode` | `string` | `''` | 下载提取码；以段内代码样式显示，点击可复制。 | `extraction-code="zxwg"` |
| `links` | `Record<string, string \| false \| { href?: string; target?: string; extractionCode?: string; description?: string; size?: string }>` | `undefined` | 同一套目录树下为不同网盘覆写链接和元信息；`false` 表示该网盘下该节点不可下载。 | `:links="{ baidu: { href: 'https://pan.baidu.com/...' }, '123网盘': false }"` |

### FileTreeFile

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `name` | `string` | - | 文件名（必填）。 | `name="README.md"` |
| `icon` | `string` | `''` | 自定义文件图标。 | `icon="mdi:file-star-outline"` |
| `href` | `string` | `''` | 普通模式显示跳转图标；下载模式显示 `点击下载` badge。 | `href="/guides/index"` |
| `target` | `string` | `''` | 链接打开方式。 | `target="_blank"` |
| `size` | `string` | `''` | 文件大小信息。 | `size="512 MB"` |
| `description` | `string` | `''` | 文件描述；下载模式下若同时传入 `extractionCode`，则优先显示提取码。 | `description="课程资源合集"` |
| `provider` | `string` | `''` | 覆盖节点所属网盘。默认继承 `FileTree`。 | `provider="gdrive"` |
| `extractionCode` | `string` | `''` | 下载提取码；以段内代码样式显示，点击可复制。 | `extraction-code="THFn"` |
| `links` | `Record<string, string \| false \| { href?: string; target?: string; extractionCode?: string; description?: string; size?: string }>` | `undefined` | 同一套目录树下为不同网盘覆写链接和元信息；`false` 表示该网盘下该节点不可下载。 | `:links="{ baidu: { href: 'https://pan.baidu.com/...' }, '123网盘': false }"` |

## 支持的网盘、别名与图标

| 网盘 | 别名 | 图标 |
| --- | --- | --- |
| 115 | `115` |  |
| 123网盘 | `123pan` |  |
| 中国移动云盘 | `mobile` |  |
| 天翼云盘 | `ecloud` |  |
| 阿里云盘 | `aliyundrive` |  |
| OpenList | `openlist` |  |
| 百度网盘 | `baidu` |  |
| 一刻相册 | `album` |  |
| 豆包分享 | `doubao` |  |
| Google Drive | `gdrive` |  |
| 蓝奏云 | `lanzou` |  |
| 分秒帧 | `mseconds` |  |
| Mega | `mega` |  |
| OneDrive | `onedrive` |  |
| PikPak | `pikpak` |  |
| 夸克网盘 | `quark` |  |
| SMB | `smb` |  |
| Teambition | `teambition` |  |
| Terabox | `terabox` |  |
| 迅雷 | `xunlei` |  |
| UC网盘 | `uc` |  |
| 联通云盘 | `unicom` |  |
| GitHub | `github` |  |
| iCloud | `icloud` |  |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/kbd.md
description: HeroUI 风格的键盘按键组件，支持 Win、Linux、Mac 常见快捷键与美式键盘常用按键展示。
---

# Kbd 组件

`Kbd` 用于在文档中展示快捷键、命令提示和单个按键说明。

## 基础用法

```md
<Kbd key-name="Enter" />
<Kbd key-name="Tab" />
<Kbd keys="Ctrl+K" platform="win" />
<Kbd keys="Command+K" platform="mac" />
```

## 常见平台快捷键

```md
<Kbd keys="Meta+R" platform="win" />
<Kbd keys="Ctrl+Shift+P" platform="win" />
<Kbd keys="Alt+Tab" platform="win" />
<Kbd keys="Ctrl+Shift+Esc" platform="win" />
```

```md
<Kbd keys="Super+L" platform="linux" />
<Kbd keys="Ctrl+Alt+T" platform="linux" />
<Kbd keys="Ctrl+Shift+Esc" platform="linux" />
<Kbd keys="Ctrl+Alt+Delete" platform="linux" />
```

```md
<Kbd keys="Command+Space" platform="mac" />
<Kbd keys="Command+Shift+4" platform="mac" />
<Kbd keys="Command+Option+Esc" platform="mac" />
<Kbd keys="Command+Tab" platform="mac" />
```

## 常见快捷键对应的代码

| 场景 | 演示 | Markdown 代码 |
| --- | --- | --- |
| Windows 运行窗口 |  | `<Kbd keys="Meta+R" platform="win" />` |
| Windows 命令面板 |  | `<Kbd keys="Ctrl+Shift+P" platform="win" />` |
| Linux 终端 |  | `<Kbd keys="Ctrl+Alt+T" platform="linux" />` |
| Linux 锁屏 |  | `<Kbd keys="Super+L" platform="linux" />` |
| macOS Spotlight |  | `<Kbd keys="Command+Space" platform="mac" />` |
| macOS 截图 |  | `<Kbd keys="Command+Shift+4" platform="mac" />` |

## 常见按键

## 在提示块中使用

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `keys` | `string \| string[]` | `''` | 快捷键组合，使用 `+` 分隔。 | `keys="Ctrl+Shift+P"` |
| `keyName` | `string` | `''` | 单个按键名称；适合单键展示。 | `key-name="Enter"` |
| `platform` | `auto \| win \| linux \| mac` | `auto` | 平台映射规则。 | `platform="mac"` |
| `size` | `sm \| md \| lg` | `md` | 键帽尺寸。 | `size="lg"` |
| `separator` | `string` | `+` | 组合键分隔符。 | `separator="/"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/progress.md
description: HeroUI 风格进度条组件，支持尺寸、颜色、不确定态、条纹、标签、数值与自定义样式。
---

# Progress 组件

`Progress` 适合展示构建进度、任务执行状态、上传百分比和配额使用情况。

## 基础用法

```md
<Progress label="文档构建进度" :value="72" show-value />
```

## Sizes

## Colors

## Indeterminate

```md
<Progress label="正在同步远端资源" indeterminate />
```

## Striped

## With Label

## With Value

## Value Formatting

## Custom Styles

```md
<Progress
  label="自定义样式"
  :value="58"
  show-value
  track-class="vp-pro-progress-demo-track"
  indicator-class="vp-pro-progress-demo-indicator"
/>
```

## 在容器组件中使用

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `value` | `number` | `0` | 当前值。 | `:value="72"` |
| `min` | `number` | `0` | 最小值。 | `:min="0"` |
| `max` | `number` | `100` | 最大值。 | `:max="200"` |
| `label` | `string` | `''` | 左侧标签。 | `label="上传进度"` |
| `color` | `default \| primary \| success \| warning \| danger` | `primary` | 主题色。 | `color="success"` |
| `size` | `sm \| md \| lg` | `md` | 进度条高度。 | `size="lg"` |
| `indeterminate` | `boolean` | `false` | 不确定态，忽略数值宽度。 | `indeterminate` |
| `striped` | `boolean` | `false` | 条纹效果。 | `striped` |
| `showLabel` | `boolean` | `true` | 是否显示标签。 | `:show-label="false"` |
| `showValue` | `boolean` | `false` | 是否显示右侧数值。 | `show-value` |
| `format` | `percent \| value` | `percent` | 数值格式模式。 | `format="value"` |
| `formatOptions` | `Intl.NumberFormatOptions` | `{}` | 百分比或数值格式选项。 | `:format-options="{ maximumFractionDigits: 1 }"` |
| `valueText` | `string` | `''` | 直接覆盖显示文本。 | `value-text="37 / 50"` |
| `trackClass` | `string` | `''` | 轨道附加类名。 | `track-class="my-track"` |
| `indicatorClass` | `string` | `''` | 进度条附加类名。 | `indicator-class="my-indicator"` |
| `labelClass` | `string` | `''` | 标签附加类名。 | `label-class="my-label"` |
| `valueClass` | `string` | `''` | 数值附加类名。 | `value-class="my-value"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/table.md
description: markdown 原生表格增强，支持复制 Markdown/HTML、横向滚动和单元格合并语法。
---

# Table 表格增强

项目内置了 markdown 原生表格增强能力，无需额外引入组件。

* 自动包裹滚动容器，超出正文可左右滑动。
* 表格后方提供 `复制 Markdown`、`复制 HTML`、`复制样式 HTML` 三个按钮。
* 支持显式合并语法：`[[colspan:N]]`、`[[rowspan:N]]`。
* 支持 `:::table{...}` 指令，按表格粒度控制复制按钮和矩阵样式。

## 表格指令参数

```md
:::table{copy="markdown styled-html" matrix=true}
| A | B | C |
| --- | --- | --- |
| 1 | 2 | 3 |
| 4 | 5 | 6 |
:::
```

可用参数：

* `copy=all`：显示全部复制按钮，默认值。
* `copy=none`：不显示任何复制按钮。
* `copy="markdown html"`：只显示指定按钮，支持 `markdown`、`html`、`styled-html`，可空格或逗号分隔。
* `matrix=true`：按并列表格渲染，不对 `th` 做首行/首列强调样式。
* `matrix=false`：保持普通表头样式，默认值。

## 基础语法（真实渲染）

| 组件 | 功能 | 备注 |
| --- | --- | --- |
| Code | 代码高亮、复制、行号 | 支持路径与语言标签 |
| FileTree | 目录结构展示 | 支持文件/文件夹链接 |
| Toast | 全局反馈提示 | 默认 5s 自动关闭 |

```md
| 组件 | 功能 | 备注 |
| --- | --- | --- |
| Code | 代码高亮、复制 | 支持路径与语言标签 |
| Toast | 反馈提示 | 右下角堆叠 |
```

## 合并单元格（真实渲染）

* `[[colspan:N]]`：当前单元格向右合并 `N` 列（包含自身）。
* `[[rowspan:N]]`：当前单元格向下合并 `N` 行（包含自身）。
* 合并标记是显式关键字，不占用常见 markdown 对齐符号，冲突概率更低。
* 被覆盖的单元格内容会被忽略，建议留空。

| A | B | C | D |
| --- | --- | --- | --- |
| \[\[colspan:3]] | 数据1 | 数据2 | 数据3 |
| \[\[rowspan:2]] 分组 | 数据4 | 数据5 | 数据6 |
|  | 数据7 | 数据8 | 数据9 |
| E | 数据4 | 数据5 | 数据6 |

```md
| A | B | C | D |
| --- | --- | --- | --- |
| [[colspan:3]] | 数据1 | 数据2 | 数据3 |
| [[rowspan:2]] 分组 | 数据4 | 数据5 | 数据6 |
|  | 数据7 | 数据8 | 数据9 |
| E | 数据4 | 数据5 | 数据6 |
```

## 复制说明

* `复制 Markdown`：导出当前表格内容为 markdown 源码。
* `复制 HTML`：导出当前表格的 HTML 结构代码。
* `复制样式 HTML`：导出包含内联样式的 HTML（粘贴后保留完整边框和表格样式）。

## 并列表格示例（无首行首列强调）

下面这个表格是实际渲染结果：没有任何复制按钮，同时关闭了首行 / 首列强调样式。

:::table{copy=markdown html matrix=true}
| 阶段一 | 阶段二 | 阶段三 |
| --- | --- | --- |
| 需求 | 开发 | 发布 |
| 调研 | 联调 | 复盘 |
:::

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/checkbox.md
description: HeroUI 风格 Checkbox，支持颜色、尺寸、圆角和纯展示模式。
---

# Checkbox 组件

`Checkbox` 用于单个展示项，支持单独使用或放入 `CheckboxGroup`。

## 基础用法

```md
<div class="vp-pro-checkbox-inline">
  <Checkbox label="接收站内通知" />
  <Checkbox label="订阅每周更新" color="success" :default-selected="true" />
  <Checkbox label="高风险操作" color="danger" description="请再次确认后再勾选" />
  <Checkbox label="圆形样式" radius="full" :default-selected="true" />
</div>
```

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `modelValue` | `boolean` | `undefined` | 受控选中状态（`v-model`）。 | `v-model="enabled"` |
| `defaultSelected` | `boolean` | `false` | 非受控初始选中。 | `:default-selected="true"` |
| `label` | `string` | `''` | 文本标签，不传时使用插槽。 | `label="接收通知"` |
| `description` | `string` | `''` | 标签下方说明文字。 | `description="仅用于系统提醒"` |
| `value` | `string` | `''` | 在 `CheckboxGroup` 中的值。 | `value="ts"` |
| `name` | `string` | `''` | 原生 `name`。 | `name="agreement"` |
| `color` | `default \| primary \| success \| warning \| danger` | `primary` | 主题色。 | `color="warning"` |
| `size` | `sm \| md \| lg` | `md` | 尺寸。 | `size="lg"` |
| `radius` | `sm \| md \| lg \| full` | `lg` | 控件圆角。 | `radius="full"` |
| `disabled` | `boolean` | `false` | 是否禁用。 | `:disabled="true"` |
| `interactive` | `boolean` | `false` | 是否启用交互；默认纯展示。 | `:interactive="true"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/checkbox-group.md
description: HeroUI 风格 CheckboxGroup，支持横向自动换行排布、描述和纯展示模式。
---

# Checkbox Group 组件

`CheckboxGroup` 用于一组可多选的选项，内部搭配 `Checkbox` 使用。

## 基础用法

\<CheckboxGroup
label="技术栈偏好"
description="可多选"
orientation="horizontal"

>

TypeScript
Python
Go


```md
<CheckboxGroup label="技术栈偏好" orientation="horizontal">
  <Checkbox value="ts">TypeScript</Checkbox>
  <Checkbox value="py">Python</Checkbox>
  <Checkbox value="go">Go</Checkbox>
</CheckboxGroup>
```

## 自动换行示例

\<CheckboxGroup
label="自动换行展示"
description="根据宽度自动换行，首项靠左、末项靠右。"
orientation="horizontal"

>

C++ 编程竞赛长标题示例
Python 自动化与数据处理
Go 服务端
Rust 系统开发
Java 工程化


```md
<CheckboxGroup label="自动换行展示" orientation="horizontal">
  <Checkbox value="cpp">C++ 编程竞赛长标题示例</Checkbox>
  <Checkbox value="py">Python 自动化与数据处理</Checkbox>
  <Checkbox value="go">Go 服务端</Checkbox>
  <Checkbox value="rust">Rust 系统开发</Checkbox>
  <Checkbox value="java">Java 工程化</Checkbox>
</CheckboxGroup>
```

## 垂直排布示例

\<CheckboxGroup
label="发布检查清单"
description="垂直排布适合较长文案"
orientation="vertical"

>

已更新 Changelog
已通过核心回归测试
关键变更已完成双人 Review


```md
<CheckboxGroup
  label="发布检查清单"
  description="垂直排布适合较长文案"
  orientation="vertical"
>
  <Checkbox value="changelog">已更新 Changelog</Checkbox>
  <Checkbox value="tests">已通过核心回归测试</Checkbox>
  <Checkbox value="review">关键变更已完成双人 Review</Checkbox>
</CheckboxGroup>
```

## 校验提示

\<CheckboxGroup
label="发布前检查"
description="请至少选一项"
error-message="至少选择一项后再提交"

>

构建通过
测试通过
代码已审查


## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `modelValue` | `string[]` | `undefined` | 受控值数组（`v-model`）。 | `v-model="selected"` |
| `defaultValue` | `string[]` | `[]` | 非受控初始值。 | `:default-value="['ts']"` |
| `label` | `string` | `''` | 组标签。 | `label="技术栈偏好"` |
| `description` | `string` | `''` | 组说明。 | `description="可多选"` |
| `errorMessage` | `string` | `''` | 错误提示。 | `error-message="至少选择一项"` |
| `name` | `string` | 自动生成 | 内部 checkbox 共享的 `name`。 | `name="skills"` |
| `orientation` | `vertical \| horizontal` | `vertical` | 排布方向。 | `orientation="horizontal"` |
| `color` | `default \| primary \| success \| warning \| danger` | `primary` | 子项默认主题色。 | `color="success"` |
| `size` | `sm \| md \| lg` | `md` | 子项默认尺寸。 | `size="lg"` |
| `radius` | `sm \| md \| lg \| full` | `lg` | 子项默认圆角。 | `radius="full"` |
| `disabled` | `boolean` | `false` | 组禁用。 | `:disabled="true"` |
| `interactive` | `boolean` | `false` | 组内是否启用交互；默认纯展示。 | `:interactive="true"` |
| `required` | `boolean` | `false` | 标签显示必填星号。 | `:required="true"` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/dropdown.md
description: HeroUI 风格下拉菜单组件，支持图标项、分组分隔符、hover/click 触发、受控状态和自定义最小宽度。
---

# Dropdown 组件

`Dropdown` 适合做操作菜单、工具栏下拉和带图标的选择列表。

## 基础用法

```md
<Dropdown :items="[{ text: '复制', icon: 'copy' }, { text: '重命名', icon: 'edit' }, { text: '删除', icon: 'trash', action: () => {} }]" placement="bottom-start">
  <template #trigger>
    <LinkButton text="操作菜单" variant="outline" />
  </template>
</Dropdown>
```

## Items 结构

`items` 数组中每项支持以下字段：

| 字段 | 类型 | 说明 |
| --- | --- | --- |
| `text` | `string` | 显示文本 |
| `icon` | `string` | 图标名（配合 `#icon-{name}` 插槽使用） |
| `link` | `string` | 点击后跳转链接 |
| `action` | `() => void` | 点击后执行的回调函数 |
| `disabled` | `boolean` | 禁用该项 |
| `active` | `boolean` | 高亮激活状态 |
| `divider` | `boolean` | 作为分隔线渲染（text/icon 等字段被忽略） |

## 带图标项

```vue
<Dropdown :items="iconItems" placement="bottom-start">
  <template #trigger>
    <LinkButton text="带图标菜单" variant="outline" />
  </template>
  <template #icon-copy>
    <svg ...><!-- copy icon --></svg>
  </template>
  <template #icon-external>
    <svg ...><!-- external link icon --></svg>
  </template>
</Dropdown>
```

## 受控状态

```md
<script setup>
import { ref } from 'vue'
const controlledOpen = ref(false)
const controlledItems = [{ text: '选项一', action: () => {} }, ...]
</script>

<Dropdown v-model:open="controlledOpen" :items="controlledItems" placement="bottom">
  <template #trigger>
    <LinkButton :text="controlledOpen ? '关闭菜单' : '打开菜单'" variant="outline" />
  </template>
</Dropdown>
```

`v-model:open` 控制菜单的打开状态。

## Hover 触发

`trigger="hover"` 使菜单在鼠标悬停时打开，移出时关闭。

## 自定义尺寸

`:min-width` 控制面板最小宽度（默认 `180px`）。

## Placements

## Props

| 参数 | 类型 | 默认值 | 说明 |
| --- | --- | --- | --- |
| `items` | `DropdownItem[]` | `[]` | 菜单项数组 |
| `placement` | `bottom \| bottom-start \| bottom-end \| top \| top-start \| top-end` | `bottom-start` | 面板弹出位置 |
| `trigger` | `click \| hover \| both` | `click` | 触发方式 |
| `disabled` | `boolean` | `false` | 禁用下拉菜单 |
| `maxHeight` | `number` | `320` | 面板最大高度（px） |
| `minWidth` | `number` | `180` | 面板最小宽度（px） |

## DropdownItem 类型

```ts
export interface DropdownItem {
  text?: string
  link?: string
  icon?: string
  action?: () => void
  divider?: boolean
  disabled?: boolean
  active?: boolean
}
```

## Emits

| 事件 | 参数 | 说明 |
| --- | --- | --- |
| `select` | `item: DropdownItem` | 用户点击菜单项时触发 |
| `update:open` | `open: boolean` | 配合 `v-model:open` 使用 |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/popover.md
description: HeroUI 风格浮层组件，支持箭头、颜色、位置、偏移、受控状态、表单、遮罩和自定义触发器。
---

# Popover 组件

`Popover` 适合做局部解释、短操作、表单补充和标题补全。

## 基础用法

```md
<Popover title="提示" placement="bottom" with-arrow>
  <template #trigger>
    <LinkButton text="点击查看提示" variant="soft" />
  </template>
  这里可以放短说明。
</Popover>
```

## With Arrow

## Colors

## Placements

## Offset

## Controlled

## Title Props

## With Form

## Backdrop

## Custom Motion

## Custom Trigger

## 在 Accordion 中使用

## Props

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `open` | `boolean \| undefined` | `undefined` | 受控打开状态，配合 `v-model:open` 使用。 | `v-model:open="open"` |
| `defaultOpen` | `boolean` | `false` | 非受控初始打开状态。 | `:default-open="true"` |
| `trigger` | `click \| hover \| both` | `click` | 触发方式。 | `trigger="hover"` |
| `placement` | `top \| bottom \| left \| right` 等 | `bottom` | 浮层位置。 | `placement="top-start"` |
| `offset` | `number` | `8` | 与触发元素的间距。 | `:offset="0"` |
| `withArrow` | `boolean` | `false` | 是否显示箭头。 | `with-arrow` |
| `color` | `default \| primary \| success \| warning \| danger` | `default` | 浮层边框强调色。 | `color="warning"` |
| `title` | `string` | `''` | 浮层标题。 | `title="提示"` |
| `content` | `string` | `''` | 简单纯文本内容；复杂内容请用默认插槽。 | `content="完整标题"` |
| `titleClass` | `string` | `''` | 标题附加类名。 | `title-class="my-title"` |
| `panelClass` | `string` | `''` | 外层面板附加类名。 | `panel-class="my-panel"` |
| `bodyClass` | `string` | `''` | 内容区附加类名。 | `body-class="my-body"` |
| `triggerClass` | `string` | `''` | 触发器包裹层附加类名。 | `trigger-class="my-trigger"` |
| `backdrop` | `boolean \| soft \| blur` | `false` | 是否显示遮罩以及遮罩样式。 | `backdrop="blur"` |
| `disabled` | `boolean` | `false` | 禁用浮层。 | `:disabled="true"` |
| `motion` | `scale \| fade \| slide-up \| slide-down \| none` | `scale` | 过渡预设。 | `motion="slide-up"` |
| `enterFromClass` | `string` | `''` | 自定义进入起始类名。 | `enter-from-class="..."` |
| `enterActiveClass` | `string` | `''` | 自定义进入激活类名。 | `enter-active-class="..."` |
| `leaveToClass` | `string` | `''` | 自定义离开结束类名。 | `leave-to-class="..."` |
| `leaveActiveClass` | `string` | `''` | 自定义离开激活类名。 | `leave-active-class="..."` |

---

---
url: https://ain.hmgf.hxcn.space/contribution/project-components/toast.md
description: HeroUI 风格的全局 Toast 提示，默认右下角、flat、large radius、5 秒进度条与关闭按钮。
---

# Toast 组件

项目内置了全局 `Toast`，用于统一提示反馈：

* 位置：右下角。
* 样式：flat + large radius。
* 时长：默认 `5s`，带时间进度条。
* 交互：显示关闭按钮。
* 悬停：鼠标移入时暂停计时，移出后继续。
* 堆叠：新 toast 叠在旧 toast 之上，保持 3D 堆叠层次且计时不重置。

## 内置触发场景

* 点击代码块复制按钮。
* 点击段内代码复制。
* 点击 markdown 表格复制按钮（Markdown / HTML / 样式 HTML）。

## 手动触发

```ts
import { addToast } from '../../.vitepress/theme/components/ui/toast'

addToast({
  title: '保存成功',
  description: '配置已更新。',
  color: 'success',
  timeout: 5000
})
```

## API

| 参数 | 类型 | 默认值 | 说明 | 示例 |
| --- | --- | --- | --- | --- |
| `title` | `string` | - | 主标题。 | `title: '已复制'` |
| `description` | `string` | `''` | 辅助说明。 | `description: '代码已复制'` |
| `color` | `default \| primary \| success \| warning \| danger` | `default` | 视觉状态。 | `color: 'warning'` |
| `timeout` | `number` | `5000` | 自动关闭时间（毫秒）。 | `timeout: 5000` |

---

---
url: https://ain.hmgf.hxcn.space/competition.md
description: >-
  本页系统介绍 NOI、NOIP、CSP-J/S 等常见编程竞赛体系，以及洛谷、Codeforces、AtCoder、LeetCode
  等平台的使用方向，并给出从语法基础到算法进阶的备赛路径建议。
---

# 竞赛

编程竞赛信息和指南

## 常见竞赛

### NOI 系列

* **NOI（全国青少年信息学奥林匹克竞赛）**
* **NOIP（全国青少年信息学奥林匹克联赛）**
* **CSP-J/S（CCF非专业级软件能力认证）**

### 在线竞赛平台

* [洛谷](https://www.luogu.com.cn/) - 国内最大的编程竞赛社区
* [Codeforces](https://codeforces.com/) - 国际知名算法竞赛平台
* [AtCoder](https://atcoder.jp/) - 日本算法竞赛平台
* [LeetCode](https://leetcode.cn/) - 面向求职的编程题库

## 竞赛准备

### 基础知识

1. 语法基础（C/C++）
2. 基本算法
3. 数据结构
4. 时间复杂度分析

### 进阶内容

1. 高级数据结构
2. 图论算法
3. 动态规划
4. 数学问题

## 其他

* [报销发票指南](./reimbursement-guide) - 团队成员参加竞赛相关费用的报销流程说明。

## 相关资源

查看 [资源页面](/event/lesson0-2025) 获取更多学习资料。

::: tip 提示
加入我们的 [QQ群](https://qm.qq.com/q/ZlktjRUdqg) 获取最新竞赛资讯！
:::

---

---
url: https://ain.hmgf.hxcn.space/competition/competition-lists-2025.md
description: 按月份整理 2025 年教育部认可全国大学生学科竞赛名单、报名时间与官网链接。
---

# 2025年教育部认可全国大学生学科竞赛榜单（按月份整理）

## 1月

### 1. “挑战杯”全国大学生课外学术科技作品竞赛

* 竞赛分类：综合类
* 报名开始：1月
* 报名结束：6月
* 官网链接：http://www.tiaozhanbei.net/
* 备注：单数年举办

### 2. “挑战杯”中国大学生创业计划竞赛

* 竞赛分类：综合类
* 报名开始：1月
* 报名结束：6月
* 官网链接：http://www.tiaozhanbei.net/
* 备注：双数年举办

### 3. 中国大学生医学技术技能大赛

* 竞赛分类：医学类
* 报名开始：1月
* 报名结束：1月
* 官网链接：https://medu.bjmu.edu.cn/cms/show.action?code=publish\_4af037e16e264f60016eaa7dea950ef4\&siteid=100001
* 备注：无

### 4. 全国大学生结构设计竞赛

* 竞赛分类：其他工学类
* 报名开始：1月
* 报名结束：3月
* 官网链接：http://www.structurecontest.com/
* 备注：无

### 5. 全国大学生广告艺术大赛

* 竞赛分类：艺术类
* 报名开始：1月
* 报名结束：6月
* 官网链接：https://www.sun-ada.net/
* 备注：无

### 6. 全国大学生智能汽车竞赛

* 竞赛分类：电子信息类
* 报名开始：1月
* 报名结束：6月
* 官网链接：http://www.eepw.com.cn/event/action/freescale\_car2012/
* 备注：无

### 7. 全国大学生集成电路创新创业大赛

* 竞赛分类：电子信息类
* 报名开始：1月
* 报名结束：3月
* 官网链接：http://univ.ciciec.com/
* 备注：无

### 8. 全国周培源大学生力学竞赛

* 竞赛分类：理学类
* 报名开始：1月
* 报名结束：3月
* 官网链接：http://zpy.cstam.org.cn/index.aspx
* 备注：无

### 9. 全国大学生物理实验竞赛

* 竞赛分类：理学类
* 报名开始：1月
* 报名结束：5月
* 官网链接：http://wlsycx.moocollege.com/
* 备注：无

### 10. “学创杯”全国大学生创业综合模拟大赛

* 竞赛分类：经管类
* 报名开始：1月
* 报名结束：3月
* 官网链接：http://www.bster.cn/cyds/index
* 备注：无

### 11. “21世纪杯”全国英语演讲比赛

* 竞赛分类：语言类
* 报名开始：1月
* 报名结束：4月
* 官网链接：https://contest.i21st.cn/
* 备注：无

### 12. 全国大学生基础医学创新研究暨实验设计论坛(大赛)

* 竞赛分类：医学类
* 报名开始：1月
* 报名结束：4月
* 官网链接：http://www.jcyxds.com/
* 备注：无

### 13. 世界技能大赛中国选拔赛

* 竞赛分类：职业技能类
* 报名开始：1月
* 报名结束：8月
* 官网链接：http://worldskillschina.mohrss.gov.cn/
* 备注：各赛项具体报名时间见赛项通知

## 2月

### 1. 中国大学生机械工程创新创意大赛

* 竞赛分类：其他工学类
* 报名开始：2月
* 报名结束：4月
* 官网链接：http://www.gczbds.org
* 备注：无

### 2. 睿抗机器人开发者大赛（RAICOM）

* 竞赛分类：机器人类
* 报名开始：2月
* 报名结束：12月
* 官网链接：https://www.robocom.com.cn/
* 备注：具体看各赛项时间

### 3. 全国大学生统计建模大赛

* 竞赛分类：理学类
* 报名开始：2月
* 报名结束：5月
* 官网链接：http://tjjmds.ai-learning.net
* 备注：无

## 3月

### 1. 全国大学生电子设计竞赛

* 竞赛分类：电子信息类
* 报名开始：3月
* 报名结束：4月
* 官网链接：http://www.nuedcchina.com/
* 备注：无

### 2. 全国大学生机械创新设计大赛

* 竞赛分类：其他工学类
* 报名开始：3月
* 报名结束：5月
* 官网链接：http://umic.ckcest.cn/
* 备注：无

### 3. 全国大学生物流设计大赛

* 竞赛分类：经管类
* 报名开始：3月
* 报名结束：4月
* 官网链接：http://www.clpp.org.cn/
* 备注：无

### 4. 全国大学生化工设计竞赛

* 竞赛分类：其他工学类
* 报名开始：3月
* 报名结束：3月
* 官网链接：http://iche.zju.edu.cn/
* 备注：无

### 5. 全国三维数字化创新设计大赛

* 竞赛分类：电子信息类
* 报名开始：3月
* 报名结束：6月
* 官网链接：https://3dds.3ddl.net/
* 备注：无

### 6. “西门子杯”中国智能制造挑战赛

* 竞赛分类：电子信息类
* 报名开始：3月
* 报名结束：5月
* 官网链接：http://www.siemenscup-cimc.org.cn/
* 备注：无

### 7. 中国机器人大赛暨RoboCup机器人世界杯中国赛

* 竞赛分类：机器人类
* 报名开始：3月
* 报名结束：4月
* 官网链接：http://crc.drct-caa.org.cn/
* 备注：无

### 8. 全国大学生嵌入式芯片与系统设计竞赛

* 竞赛分类：电子信息类
* 报名开始：3月
* 报名结束：4月
* 官网链接：http://www.socchina.net/
* 备注：无

### 9. 中国高校智能机器人创意大赛

* 竞赛分类：机器人类
* 报名开始：3月
* 报名结束：6月
* 官网链接：http://www.robotcontest.cn/
* 备注：无

### 10. 中国机器人及人工智能大赛

* 竞赛分类：机器人类
* 报名开始：3月
* 报名结束：3月
* 官网链接：https://craic.yuntop.com/
* 备注：无

### 11. “外教社杯”全国高校学生跨文化能力大赛

* 竞赛分类：语言类
* 报名开始：3月
* 报名结束：4月
* 官网链接：https://ict.sflep.com/index.php?m=content\&c=index\&a=lists\&catid=15
* 备注：各省报名通知

### 12. 全国大学生测绘学科创新创业智能大赛

* 竞赛分类：其他工学类
* 报名开始：3月
* 报名结束：5月
* 官网链接：http://smt.whu.edu.cn/index.htm
* 备注：无

### 13. 全国企业竞争模拟大赛

* 竞赛分类：经管类
* 报名开始：3月
* 报名结束：3月
* 官网链接：http://www.ibizsim.cn/
* 备注：无

## 4月

### 1. ACM-ICPC国际大学生程序设计竞赛

* 竞赛分类：计算机类
* 报名开始：4月
* 报名结束：5月
* 官网链接：https://icpc.global/
* 备注：无

### 2. “外研社·国才杯”“理解当代中国”全国大学生外语能力大赛

* 竞赛分类：语言类
* 报名开始：4月
* 报名结束：10月
* 官网链接：http://uchallenge.unipus.cn/
* 备注：无

### 3. 两岸新锐设计竞赛·华灿奖

* 竞赛分类：艺术类
* 报名开始：4月
* 报名结束：4月
* 官网链接：http://www.huacanjiang.com/home
* 备注：无

### 4. 全国大学生先进成图技术与产品信息建模创新大赛

* 竞赛分类：其他工学类
* 报名开始：4月
* 报名结束：4月
* 官网链接：http://www.chengtudasai.com/
* 备注：无

### 5. 中国大学生计算机设计大赛

* 竞赛分类：计算机类
* 报名开始：4月
* 报名结束：5月
* 官网链接：http://jsjds.blcu.edu.cn/
* 备注：无

### 6. 全国大学生地质技能竞赛

* 竞赛分类：理学类
* 报名开始：4月
* 报名结束：5月
* 官网链接：https://yuanxi.cugb.edu.cn/competition/
* 备注：无

### 7. 全国大学生光电设计竞赛

* 竞赛分类：其他工学类
* 报名开始：4月
* 报名结束：8月
* 官网链接：http://gd.p.moocollege.com/
* 备注：无

### 8. 全国大学生信息安全竞赛

* 竞赛分类：电子信息类
* 报名开始：4月
* 报名结束：6月
* 官网链接：http://www.ciscn.cn/
* 备注：无

### 9. “中国软件杯”大学生软件设计大赛

* 竞赛分类：计算机类
* 报名开始：4月
* 报名结束：7月
* 官网链接：http://www.cnsoftbei.com/
* 备注：无

### 10. 全国大学生节能减排社会实践与科技竞赛

* 竞赛分类：其他工学类
* 报名开始：4月
* 报名结束：4月
* 官网链接：http://www.jienengjianpai.org/
* 备注：无

### 11. iCAN大学生创新创业大赛

* 竞赛分类：综合类
* 报名开始：4月
* 报名结束：7月
* 官网链接：http://www.g-ican.com/home/index
* 备注：无

### 12. 中华经典诵写讲大赛（①讲解大赛、②书写大赛、③诵读大赛、④篆刻大赛）

* 竞赛分类：语言类
* 报名开始：4月
* 报名结束：7月
* 官网链接：https://jdsxj.eduyun.cn/
* 备注：无

### 13. 百度之星·程序设计大赛

* 竞赛分类：计算机类
* 报名开始：4月
* 报名结束：6月
* 官网链接：https://star.baidu.com/#/
* 备注：无

### 14. 全国大学生水利创新设计大赛

* 竞赛分类：其他工学类
* 报名开始：4月
* 报名结束：5月
* 官网链接：https://sljzw.hhu.edu.cn/fenhui/2023/0411/c12009a259306/page.htm
* 备注：无

### 15. 全国大学生化工实验大赛

* 竞赛分类：其他工学类
* 报名开始：4月
* 报名结束：6月
* 官网链接：http://www.cteic.com/higherEducation-199.html?www.kulayu.com
* 备注：各分赛区竞赛通知

### 16. 全国大学生化学实验创新设计大赛

* 竞赛分类：理学类
* 报名开始：4月
* 报名结束：4月
* 官网链接：https://cid.nju.edu.cn/
* 备注：无

### 17. 全国大学生计算机系统能力大赛

* 竞赛分类：计算机类
* 报名开始：4月
* 报名结束：6月
* 官网链接：https://compiler.educg.net/#/
* 备注：无

### 18. 全国大学生物联网设计竞赛

* 竞赛分类：其他工学类
* 报名开始：4月
* 报名结束：6月
* 官网链接：https://developer.huaweicloud.com/college/wulianwang.html
* 备注：无

### 19. 全国大学生信息安全与对抗技术竞赛

* 竞赛分类：电子信息类
* 报名开始：4月
* 报名结束：5月
* 官网链接：www.isclab.org.cn
* 备注：无

## 5月

### 1. 中国国际大学生创新大赛

* 竞赛分类：综合类
* 报名开始：5月
* 报名结束：8月
* 官网链接：https://cy.ncss.cn/
* 备注：无

### 2. 全国大学生数学建模竞赛

* 竞赛分类：理学类
* 报名开始：5月
* 报名结束：9月
* 官网链接：http://www.mcm.edu.cn/
* 备注：无

### 3. 中美青年创客大赛

* 竞赛分类：综合类
* 报名开始：5月
* 报名结束：6月
* 官网链接：https://chinaus-maker.cscse.edu.cn/
* 备注：各分赛区报名截止时间不同

### 4. 全国高等院校数智化企业经营沙盘大赛

* 竞赛分类：经管类
* 报名开始：5月
* 报名结束：9月
* 官网链接：未明确（文档未提供）
* 备注：无

### 5. 全国数字建筑创新应用大赛

* 竞赛分类：其他工学类
* 报名开始：5月
* 报名结束：8月
* 官网链接：http://bisai.ccen.com.cn
* 备注：无

### 6. 全球校园人工智能算法精英大赛

* 竞赛分类：计算机类
* 报名开始：5月
* 报名结束：10月
* 官网链接：https://developer.huawei.com/consumer/cn/activity/digixActivity/digixdetail/101655281685926449?ha\_source=HR\&ha\_sourceId=89000452
* 备注：无

### 7. 一带一路暨金砖国家技能发展与技术创新大赛

* 竞赛分类：职业技能类
* 报名开始：5月
* 报名结束：12月
* 官网链接：http://www.brskills.com/#/index
* 备注：具体见各赛项通知

### 8. 码蹄杯全国职业院校程序设计大赛

* 竞赛分类：职业技能类
* 报名开始：5月
* 报名结束：6月
* 官网链接：https://matiji.net/matibei
* 备注：无

## 6月

### 1. 中国高校计算机大赛

* 竞赛分类：计算机类
* 报名开始：6月
* 报名结束：7月
* 官网链接：http://www.c4best.cn/
* 备注：无

### 2. 全国大学生工业设计大赛

* 竞赛分类：艺术类
* 报名开始：6月
* 报名结束：7月
* 官网链接：https://www.cuidc.net/#/
* 备注：无

### 3. 全国本科院校税收风险管控案例大赛

* 竞赛分类：经管类
* 报名开始：6月
* 报名结束：10月
* 官网链接：微信公众号：全国本科院校税收风控案例大赛
* 备注：无

### 4. 世界技能大赛

* 竞赛分类：职业技能类
* 报名开始：6月
* 报名结束：7月
* 官网链接：https://worldskills.org/
* 备注：无

## 7月

### 1. 全国大学生生命科学竞赛（CULSC）

* 竞赛分类：理学类
* 报名开始：7月
* 报名结束：次年1月
* 官网链接：https://www.culsc.cn/#/
* 备注：无

### 2. 国际大学生智能农业装备创新大赛

* 竞赛分类：农学类
* 报名开始：7月
* 报名结束：10月
* 官网链接：http://uiaec.ujs.edu.cn
* 备注：无

## 8月

### 1. 全国大学生数字媒体科技作品及创意竞赛

* 竞赛分类：艺术类
* 报名开始：8月
* 报名结束：10月
* 官网链接：http://mit.caai.cn/
* 备注：无

## 9月

### 1. 全国大学生电子商务“创新、创意及创业”挑战赛

* 竞赛分类：经管类
* 报名开始：9月
* 报名结束：12月
* 官网链接：http://www.3chuang.net/
* 备注：无

### 2. 中国大学生工程实践与创新能力大赛

* 竞赛分类：其他工学类
* 报名开始：9月
* 报名结束：详见省市具体通知
* 官网链接：http://www.gcxl.edu.cn/new/index.html
* 备注：省市发布的具体报名时间及安排

### 3. 华为ICT大赛

* 竞赛分类：电子信息类
* 报名开始：9月
* 报名结束：11月
* 官网链接：https://e.huawei.com/cn/talent/ict-academy/#/ict-contest?compId=85131973
* 备注：无

### 4. 全国高校BIM毕业设计创新大赛（更名：国际高校BIM毕业设计创新大赛）

* 竞赛分类：其他工学类
* 报名开始：9月
* 报名结束：11月
* 官网链接：http://gxbsxs.glodonedu.com/
* 备注：无

### 5. 全国高校商业精英挑战赛

* 竞赛分类：经管类
* 报名开始：9月
* 报名结束：次年3月
* 官网链接：http://cubec.org.cn/
* 备注：无

### 6. “科云杯”全国大学生财会职业能力大赛

* 竞赛分类：经管类
* 报名开始：9月
* 报名结束：10月
* 官网链接：http://match.xmkeyun.com.cn/
* 备注：无

### 7. 世界职业院校技能大赛|全国职业院校技能大赛

* 竞赛分类：职业技能类
* 报名开始：9月
* 报名结束：10月
* 官网链接：https://www.vcsc.org.cn/
* 备注：无

## 10月

### 1. 全国大学生创新创业训练计划年会展示

* 竞赛分类：综合类
* 报名开始：10月
* 报名结束：10月
* 官网链接：http://gjcxcy.bjtu.edu.cn/Index.aspx
* 备注：无

### 2. 全国大学生机器人大赛

* 竞赛分类：机器人类
* 报名开始：10月
* 报名结束：次年3月
* 官网链接：https://www.cnrobocon.net/
* 备注：无

### 3. 米兰设计周——中国高校设计学科师生优秀作品展

* 竞赛分类：艺术类
* 报名开始：10月
* 报名结束：次年3月
* 官网链接：http://www.dandad.cn/
* 备注：无

### 4. 中国好创意暨全国数字艺术设计大赛

* 竞赛分类：艺术类
* 报名开始：10月
* 报名结束：次年6月
* 官网链接：https://www.cdec.org.cn/
* 备注：无

### 5. 全国大学生能源经济学术创意大赛

* 竞赛分类：综合类
* 报名开始：10月
* 报名结束：11月
* 官网链接：http://energy.qibebt.ac.cn/eneco/contribution/index.html
* 备注：无

## 11月

### 1. “工行杯”全国大学生金融科技创新大赛

* 竞赛分类：经管类
* 报名开始：11月
* 报名结束：次年1月
* 官网链接：www.gonghangbei.com
* 备注：无

### 2. 全国大学生机器人大赛-RoboTac

* 竞赛分类：职业技能类
* 报名开始：11月
* 报名结束：12月
* 官网链接：http://www.robotac.cn
* 备注：无

## 12月

### 1. 中国大学生服务外包创新创业大赛

* 竞赛分类：电子信息类
* 报名开始：12月
* 报名结束：次年3月
* 官网链接：http://www.fwwb.org.cn/
* 备注：无

### 2. 蓝桥杯全国软件和信息技术专业人才大赛

* 竞赛分类：计算机类
* 报名开始：12月
* 报名结束：次年1月
* 官网链接：http://dasai.lanqiao.cn/
* 备注：无

### 3. 全国大学生金相技能大赛

* 竞赛分类：其他工学类
* 报名开始：12月
* 报名结束：次年4月
* 官网链接：http://www.jxds.tech/
* 备注：无

### 4. 未来设计师·全国高校数字艺术设计大赛

* 竞赛分类：艺术类
* 报名开始：12月
* 报名结束：次年6月
* 官网链接：https://www.ncda.org.cn/
* 备注：无

### 5. “大唐杯”全国大学生新一代信息通信技术大赛

* 竞赛分类：电子信息类
* 报名开始：12月
* 报名结束：次年2月
* 官网链接：https://dtcup.dtxiaotangren.com
* 备注：无

### 6. 全国大学生花园设计建造竞赛

* 竞赛分类：农学类
* 报名开始：12月
* 报名结束：12月
* 官网链接：未明确（文档未提供）
* 备注：无

## 目录赛事官网网址

1、中国国际大学生创新大赛

https://cy.ncss.cn/

2、“挑战杯”全国大学生课外学术科技作品竞赛

http://www.tiaozhanbei.net/

3、“挑战杯”中国大学生创业计划大赛

http://www.tiaozhanbei.net/

4、ACM-ICPC国际大学生程序设计竞赛

https://icpc.global/

5、全国大学生数学建模竞赛

http://www.mcm.edu.cn/

6、全国大学生电子设计竞赛

http://www.nuedcchina.com/

7、中国大学生医学技术技能大赛

https://medu.bjmu.edu.cn/cms/show.action?code=publish\_4af037e16e264f60016eaa7dea950ef4\&siteid=100001

8、全国大学生机械创新设计大赛

http://umic.ckcest.cn/

9、全国大学生结构设计竞赛

http://www.structurecontest.com/

10、全国大学生广告艺术大赛

https://www.sun-ada.net/

11、全国大学生智能汽车竞赛

http://www.eepw.com.cn/event/action/freescale\_car2012/

12、全国大学生电子商务“创新、创意及创业”挑战赛

http://www.3chuang.net/

13、中国大学生工程实践与创新能力大赛

http://www.gcxl.edu.cn/new/index.html

14、全国大学生物流设计大赛

http://www.clpp.org.cn/

15、“外研社·国才杯”“理解当代中国”全国大学生外语能力大赛

http://uchallenge.unipus.cn/

16、两岸新锐设计竞赛·华灿奖

http://www.huacanjiang.com/home

17、全国大学生创新创业训练计划年会展示

http://gjcxcy.bjtu.edu.cn/Index.aspx

18、全国大学生化工设计竞赛

http://iche.zju.edu.cn/

19、全国大学生机器人大赛

https://www.cnrobocon.net/

20、全国大学生市场调查与分析大赛

http://www.china-cssc.org/list-56-1.html

21、全国大学生先进成图技术与产品信息建模创新大赛

http://www.chengtudasai.com/

22、全国三维数字化创新设计大赛

https://3dds.3ddl.net/

23、“西门子杯”中国智能制造挑战赛

http://www.siemenscup-cimc.org.cn/

24、中国大学生服务外包创新创业大赛

http://www.fwwb.org.cn/

25、中国大学生计算机设计大赛

http://jsjds.blcu.edu.cn/

26、中国高校计算机大赛

http://www.c4best.cn/

27、蓝桥杯全国软件和信息技术专业人才大赛

http://dasai.lanqiao.cn/

28、米兰设计周--中国高校设计学科师生优秀作品展

http://www.dandad.cn/

29、全国大学生地质技能竞赛

https://yuanxi.cugb.edu.cn/competition/

30、全国大学生光电设计竞赛

http://gd.p.moocollege.com/

31、全国大学生集成电路创新创业大赛

http://univ.ciciec.com/

32、全国大学生金相技能大赛

http://www.jxds.tech/

33、全国大学生信息安全竞赛

http://www.ciscn.cn/

34、未来设计师·全国高校数字艺术设计大赛

https://www.ncda.org.cn/

35、全国周培源大学生力学竞赛

http://zpy.cstam.org.cn/index.aspx

36、中国大学生机械工程创新创意大赛

http://www.gczbds.org

37、中国机器人大赛暨RoboCup机器人世界杯中国赛

http://crc.drct-caa.org.cn/

38、“中国软件杯”大学生软件设计大赛

http://www.cnsoftbei.com/

39、中美青年创客大赛

https://chinaus-maker.cscse.edu.cn/

40、睿抗机器人开发者大赛(RAICOM)

https://www.robocom.com.cn/

41、“大唐杯”全国大学生新一代信息通信技术大赛

https://dtcup.dtxiaotangren.com

42、华为ICT大赛

https://e.huawei.com/cn/talent/ict-academy/#/ict-contest?compId=85131973

43、全国大学生嵌入式芯片与系统设计竞赛

http://www.socchina.net/

44、全国大学生生命科学竞赛(CULSC)

https://www.culsc.cn/#/

45、全国大学生物理实验竞赛

http://wlsycx.moocollege.com/

46、国际高校BIM毕业设计创新大赛

http://gxbsxs.glodonedu.com/

47、全国高校商业精英挑战赛

http://cubec.org.cn/

48、“学创杯”全国大学生创业综合模拟大赛

http://www.bster.cn/cyds/index

49、中国高校智能机器人创意大赛

http://www.robotcontest.cn/

50、中国好创意暨全国数字艺术设计大赛

https://www.cdec.org.cn/

51、中国机器人及人工智能大赛

https://developer.apollo.auto/devcenter/gameOperations\_cn.html?target=3

52、全国大学生节能减排社会实践与科技竞赛

http://www.jienengjianpai.org/

53、“21世纪杯”全国英语演讲比赛

https://contest.i21st.cn/

54、iCAN大学生创新创业大赛

http://www.g-ican.com/home/index

55、“工行杯”全国大学生金融科技创新大赛

www.gonghangbei.com

56、中华经典诵写讲大赛-①讲解大赛、②书写大赛、③诵读大赛、④篆刻大赛

https://jdsxj.eduyun.cn/

57、“外教社杯”全国高校学生跨文化能力大赛

https://ict.sflep.com/index.php?m=content\&c=index\&a=lists\&catid=15

58、百度之星程序设计大赛

https://star.baidu.com/#/

59、全国大学生工业设计大赛

https://www.cuidc.net/#/

60、全国大学生水利创新设计大赛

https://sljzw.hhu.edu.cn/fenhui/2023/0411/c12009a259306/page.htm

61、全国大学生化工实验大赛

http://www.cteic.com/higherEducation-199.html?www.kulayu.com

62、全国大学生化学实验创新设计大赛

https://cid.nju.edu.cn/

63、全国大学生计算机系统统能力大赛

https://compiler.educg.net/#/

64、全国大学生花园设计建造竞赛

http://www.lalavision.com/hysjjzjs

65、全国大学生物联网设计竞赛

https://developer.huaweicloud.com/college/wulianwang.html

66、全国大学生信息安全与对抗技术竞赛

www.isclab.org.cn

67、全国大学生测绘学科创新创业智能大赛

http://smt.whu.edu.cn/index.htm

68、全国大学生统计建模大赛

http://tjjmds.ai-learning.net

69、全国大学生能源经济学术创意大赛

http://energy.qibebt.ac.cn/eneco/contribution/index.html

70、全国大学生基础医学创新研究暨实验设计论坛(大赛)

http://www.jcyxds.com/

71、全国大学生数字煤体科技作品及创意竞赛

http://mit.caai.cn/

72、全国本科院校税收风险管控赛例大赛

微信公众号：全国本科院校税收风控案例大赛

73、全国企业模拟竞赛大赛

http://www.ibizsim.cn/

74、全国高等院校数智化企业经营沙盘大赛

主办单位：中国商业联合会

75、全国数字建筑创新应用大赛

http://bisai.ccen.com.cn

76、全球校园人工智能算法精英大赛

https://developer.huawei.com/consumer/cn/activity/digixActivity/digixdetail/101655281685926449?ha\_source=HR\&ha\_sourceId=89000452

77、国际大学生智能农业装备创新大赛

http://uiaec.ujs.edu.cn

78、“科云杯”全国大学生财会职业能力大赛

http://match.xmkeyun.com.cn/

79、世界职业院校技能大赛

https://www.vcsc.org.cn/

80、全国大学生机器人大赛-RoboTac

http://www.robotac.cn

81、世界技能大赛

https://worldskills.org/

82、世界技能大赛中国选拔赛

http://worldskillschina.mohrss.gov.cn/

83、一带一路暨金砖国家技能发展与技术创新大赛

http://www.brskills.com/#/index

84、码蹄杯全国职业院校程序设计大赛

https://matiji.net/matibei

---

---
url: https://ain.hmgf.hxcn.space/competition/competition-introductions.md
description: 汇总春季学期算法、数学建模等重点竞赛的赛项信息、时间节点与准备方向，帮助同学根据基础水平选择目标比赛并制定可执行的阶段性训练计划。
---

# 春季学期重要竞赛一览

## 算法

### 竞赛及时间

* **蓝桥杯**
  * **2025 年**：省赛时间为 2025 年 4 月 12 日至 13 日。
* **睿抗编程技能赛**
  * **2024 年**：属于睿抗机器人开发者大赛的个人赛项目。省赛 2024 年 5 月 20 日截止报名，预计 2024 年 7 月进行省赛；国赛 2024 年 7 月 20 日截止报名，预计 2024 年 8 月进行国赛。
  * **2025 年**：选拔赛时间为 2025 年 5 月 - 7 月，全国总决赛时间为 2025 年 8 月 - 10 月。
* **百度之星**
  * **2024 年**：初赛共三场，分别为 6 月 2 日（周日）14:00-17:00、6 月 16 日（周日）14:00-17:00、6 月 30 日（周日）14:00-17:00。总决赛时间待定。
  * **2025 年**：暂无相关公开信息。
* **团体程序设计天梯赛（华山论剑 - 本科组）**
  * **2024 年**：属于第九届中国高校计算机大赛，比赛时间为 2024 年 4 月 20 日。
  * **2025 年**：属于第十届中国高校计算机大赛，比赛时间为 2025 年 4 月 19 日 13:30-16:30。

### 知识储备

https://www.cnblogs.com/liulianll/p/18576914

## 数学建模类

### 团队分工

#### **建模手**

* 职责：分析赛题核心要素→文献调研→选择/构建数学模型→理论验证可行性
* 技能：扎实数学基础（高数/线代/概率论） + 数学建模能力 + MATLAB/Mathematica

#### **编程手**

* 职责：模型算法实现→数据清洗处理→模型调优（效率/精度）
* 技能：Python/C++/R + 数据结构算法 + 数据分析库（Pandas/Scikit-learn）

#### 论文手

* 职责：全流程论文撰写→公式图表规范排版→提炼创新点与不足
* 技能：学术写作能力 + LaTeX排版 + 跨专业沟通能力

**在实际竞赛中，团队成员的分工并不是绝对的**，需要根据团队成员的专业背景、技能特长和实际情况进行灵活调整和协作。例如，建模组的成员也可能参与到编程实现和论文写作中，编程组的成员也需要对模型有一定的理解，以便更好地实现模型。

### 赛项

#### 含金量较高

深圳杯（数学建模校赛/国赛选拔）

妈妈杯

电工杯

国赛（高教社杯）

美赛（英文）

#### C类

数维杯（有英文赛道）

华数杯

亚太杯（有英文赛道）

认证杯

......

#### 统计建模

http://tjjmds.ai-learning.net/

#### 比赛信源：

* [数模乐园](https://www.nmmcm.org.cn)
* [赛氪](https://www.saikr.com)
* 数学建模老哥

### MATLAB

安装教程：https://zhuanlan.zhihu.com/p/2000663305337984461

## 智能车

全国大学生智能汽车竞赛是一项以智能汽车为研究对象的国家级学科竞赛，旨在培养大学生的工程实践能力和创新意识。

### 竞赛内容与组别设置

1. **核心任务**
   参赛队伍需基于统一的车模和微控制器平台，设计能够自主识别路径的智能车，完成赛道行驶任务，最终以速度、稳定性和技术报告评分决胜负。
2. **组别分类**
   * **竞速赛**：包括电磁组、摄像头组、越野组、独轮车组等10余个细分方向，注重技术方案的标准化与性能优化。
   * **创意赛**：鼓励发挥想象力，结合机器视觉、人工智能等技术完成创新任务，例如无人系统部署或复杂场景应用。
   * **室外专项赛**：侧重无人驾驶算法与产业化应用，要求车模适应室外复杂环境。

### 参赛流程与时间安排

**赛程结构**

* 每年11月发布次年赛题，3月组织技术培训，7月进行分赛区预赛（如华北、华南等赛区），8月举办全国总决赛。
* 参赛队伍通常由3名学生组成（部分组别允许5人），需经历理论设计、制作调试、现场比赛等环节。

### 竞赛对学生的影响

**能力提升**
竞赛涉及控制、传感、机械、算法等多学科知识，显著提升学生的工程实践能力和问题解决能力。参赛者需自学新技术（如ROS、机器视觉），并经历完整的项目开发流程。

## 电赛

全国大学生电子设计竞赛（简称“电赛”）是由教育部和工业和信息化部共同发起的高规格学科竞赛，旨在推动电子信息类学科课程体系改革，培养大学生的工程实践能力与创新能力。

### 竞赛概况

1. **主办与性质**
   电赛是国家级A类学科竞赛，自1994年创办以来，已成为国内规模最大、影响力最广的大学生电子信息类赛事之一，每年吸引约4万名学生参与。竞赛由德州仪器（TI）等企业赞助，部分赛题需使用指定芯片。
2. **参赛对象与形式**
   面向全日制本专科生，每队由3名学生组成，配备1-2名指导教师。竞赛以高校为单位组织，需经历校内选拔、赛区预赛和全国总决赛等环节。

### 竞赛内容与项目分类

1. **核心任务**
   参赛队伍需根据赛题要求，完成硬件设计、软件开发及系统调试，最终提交作品和技术文档。赛题涵盖通信、控制、电源、传感器等多个领域。
2. **项目分类**
   * **仪器仪表类**：如信号放大、滤波器设计、频率测量等；
   * **通信高频类**：包括调制解调、锁相频率合成、扩频通信等；
   * **控制与嵌入式类**：如四旋翼飞行器控制、智能小车路径规划；
   * **电源与能源类**：涉及功率放大、储能装置设计等；
   * **专题赛**：如模拟电子系统设计（TI杯）、信息科技前沿赛等，近年新增室外场景应用赛题。

### 赛程安排与奖项设置

1. **赛程结构**
   * **国赛**：单数年8月举办，赛期四天三夜，含初赛和全国总决赛；
   * **专题赛**：双数年举办，如2024年模拟电子系统设计专题赛（TI杯）；
   * **分赛区选拔**：如广东、湖南等赛区独立评审并公示结果。
2. **奖项与含金量**
   国奖仅设一、二等奖，获奖比例不超过全国参赛队伍总数的8%（一等奖≤2.4%，二等奖≤5.6%）。

### 备赛建议与资源支持

1. **技能储备**
   * **基础知识**：模拟电路、数字信号处理、嵌入式编程（如C语言、FPGA开发）；
   * **实战能力**：PCB设计、传感器应用、通信协议实现（如Wi-Fi、蓝牙）。
2. **备赛策略**
   * **团队分工**：建议1人主攻硬件，1人负责算法，1人统筹调试；
   * **实验室资源**：加入高校电赛实验室，利用往届积累的电路模板和调试经验；
   * **培训与指导**：参与TI组织的教师培训会及线上课程（如MSPM0 MCU培训）。
3. **官方资源**
   * **历年赛题**：可通过全国大学生电子设计竞赛培训网获取；
   * **技术文档**：TI提供芯片数据手册、参考设计及开发工具支持。

## 全国大学生计算机系统能力大赛

全国大学生计算机系统能力大赛是由系统能力培养研究专家组发起、由全国高校计算机教育研究会主办、面向高校大学生的全国性大赛。目标是以学科竞赛推动专业建设和计算机领域创新人才培养体系改革，培育我国高端芯片、关键基础软件的后备人才。大赛服务国家人才培养战略，以赛促学、以赛促教，鼓励学生设计、实现综合性的计算机系统，培养学生系统级的设计、分析、优化与应用能力，提升学生的技术创新、工程实践、团队协作能力，并为高水平计算机人才成长搭建交流、展示、合作的开放平台。

### OS 内核实现

#### 比赛时间

2024 年该赛道的时间安排如下：

* **报名阶段**：2024 年 2 月 5 日 - 5 月 15 日 ，分批发放实验硬件平台。
* **初赛阶段**：
  * 2024 年 2 月 5 日发布初赛参赛题和初赛阶段评测技术指标。
  * 自赛题发布之日起至 2024 年 5 月 31 日前，参赛队完成初赛题目，且要求源代码与开发过程全部开源展示，参赛队应按要求提供开源发布的网址以供访问，并将相关内容提交到大赛指定的托管平台上。
  * 2024 年 6 月 1 日 - 6 月 15 日，大赛评审委员会进行初赛评审，6 月 15 日公布全国决赛入围名单 。
* **全国决赛阶段**：
  * 2024 年 3 月 1 日发布全国决赛第一阶段题目，公布评测指标。
  * 2024 年 6 月 15 日 - 7 月 31 日，参赛队应按要求提交现阶段源代码和设计实现文档，评审委员会根据全国赛提交的源代码和测试结果给出各参赛队的成绩排名 。
  * 2024 年 8 月 1 日 - 现场决赛日 + 现场答辩日，参赛队在线进一步完善本队项目，增加自选内容，并在现场决赛日完成现场指定题目。在现场决赛日后，参赛队的代码、文档、视频等开发资料对外公开。在现场答辩日，参赛队参加答辩并针对项目做整体展示，评审委员会给出成绩。现场决赛日和现场答辩日的具体时间以组委会公布的为准。

#### 团队分工

* **系统架构师**：负责整体操作系统内核架构的设计与规划，确保系统的稳定性、扩展性和性能。例如在设计基于 RISC-V 或 LoongArch 架构的内核时，要根据硬件特性规划内存管理、进程调度等模块的架构。像西北工业大学 “NPUcore - IMPACT!!!” 队在设计基于国产龙芯架构的操作系统内核时，系统架构师需针对龙芯 2K1000 开发板的特性，设计出支持多系统调用和文件系统的架构 。
* **模块开发工程师**：
  * **进程管理模块**：实现进程的创建、调度、销毁等功能。要深入理解进程状态转换、调度算法等知识。比如设计一个高效的进程调度算法，确保系统中多个进程能合理分配 CPU 资源。
  * **内存管理模块**：负责内存的分配、回收和管理，实现虚拟内存等机制。例如采用分页或分段的内存管理方式，要考虑如何减少内存碎片，提高内存利用率。
  * **设备驱动模块**：针对特定硬件开发驱动程序，如磁盘驱动、网络驱动等。以磁盘驱动为例，要实现对磁盘的读写操作，与硬件进行数据交互。如西北工业大学 “NPUcore - 重生之我是菜狗” 队伍基于 2K1000 平台使用 Rust 语言开发 SATA 驱动程序 。
* **测试工程师**：对内核各个模块进行功能测试和性能测试。功能测试确保每个模块实现了预期的功能，如进程管理模块能正确创建和调度进程；性能测试则关注系统在高负载下的表现，如 CPU 使用率、内存占用率等指标，找出性能瓶颈并反馈给开发人员进行优化。

#### 知识储备

* **计算机组成原理**：了解计算机硬件的基本组成，如 CPU、内存、硬盘等设备的工作原理。这对于理解如何在特定硬件上实现操作系统内核至关重要，例如知道 CPU 的指令集架构（如 RISC - V、LoongArch），才能编写与之适配的内核代码。
* **操作系统原理**：掌握进程管理、内存管理、文件系统、设备管理等操作系统核心知识。明白进程的同步与互斥机制，才能实现正确的进程调度；理解内存管理的原理，才能设计高效的内存分配算法。
* **编程语言**：熟练掌握 C 语言，大部分操作系统内核代码是用 C 语言编写的。同时，一些队伍也会使用 Rust 语言，Rust 语言在内存安全和并发性方面有独特优势，例如西北工业大学的多个获奖队伍在基于龙芯架构开发内核时就使用了 Rust 语言 。
* **硬件相关知识**：熟悉 RISC - V 或 LoongArch 等硬件平台的特性，包括硬件接口、寄存器使用、中断处理等。例如在开发基于龙芯 2K1000 开发板的内核时，要清楚其硬件资源的使用方式和限制 。

#### 课程

https://opencamp.cn/os2edu/camp/2024fall

### OS 功能挑战

#### 比赛时间

2024 年该赛道的时间安排如下：

* **报名阶段**：2024 年 2 月 5 日 - 5 月 15 日 。
* **初赛阶段**：
  * 2024 年 3 月 1 日前分批次发布赛题和初赛评审的参考考核目标。
  * 自赛题发布之日起至 2024 年 5 月 31 日前，参赛队按照所选赛题的技术要求给出实现方案，并提交作品源代码和开发文档。参赛队应按要求提交项目的阶段性技术报告和开发状态演示，以便评审专家进行阶段性检查，并给出指导性建议。初赛过程中，要求参赛队的源代码与开发过程全部开源展示，参赛队应按要求提供开源发布的网址以供访问，并将相关内容提交到大赛指定的托管平台上。
  * 2024 年 6 月 1 日 - 6 月 15 日，大赛评审委员会进行初赛评审，6 月 15 日公布全国决赛入围名单 。
* **全国决赛阶段**：
  * 2024 年 6 月 15 日 - 7 月 31 日，参赛队完成并最终提交项目代码、项目设计与实现文档、项目展示视频等，评审专家进行检查。
  * 2024 年 8 月 1 日 - 现场答辩日，参赛队在线进一步完善本队项目，并提交项目代码和项目设计与实现文档。在现场答辩日，参赛队参加答辩并针对题目做整体展示，参赛队的代码、文档、视频等开发资料对外公开，评审委员会给出成绩。现场答辩具体时间以组委会公布的为准。

#### 团队分工

* **项目负责人**：负责整个项目的规划、进度跟踪和协调团队成员工作。制定项目计划，明确各个阶段的任务和时间节点，确保项目按时完成。例如根据赛题要求，规划出实现方案的各个阶段，并分配给相应的成员。
* **算法工程师**：针对赛题中的功能需求设计算法。如在优化操作系统的某个功能时，设计高效的算法来提高性能。例如设计一种新的文件搜索算法，提高文件系统中文件查找的速度。
* **开发工程师**：根据实现方案进行代码编写，实现赛题要求的功能。可能涉及到对已有操作系统功能的扩展或优化，如为操作系统添加新的系统调用接口，或者优化现有的内存分配算法。
* **文档撰写人员**：负责撰写详细的开发文档，包括项目设计文档、技术报告、用户手册等。开发文档要清晰描述项目的设计思路、实现方法、使用说明等，方便评审人员和其他开发人员理解项目。

#### 知识储备

* **操作系统知识**：深入理解操作系统的各种功能和机制，如进程调度算法、内存管理策略、文件系统结构等。这是进行 OS 功能挑战的基础，只有熟悉现有操作系统的功能，才能对其进行优化或扩展。
* **算法设计**：掌握常见的算法设计方法和数据结构，能够根据赛题需求设计出高效的算法。例如在进行性能优化时，使用合适的算法来减少时间复杂度和空间复杂度。
* **编程语言**：熟练使用至少一种编程语言，如 C、C++、Python 等。根据不同的赛题需求选择合适的语言进行开发，例如 Python 在一些脚本编写和快速原型开发中具有优势，而 C/C++ 在对性能要求较高的系统功能开发中更为常用。
* **相关工具使用**：熟悉开发过程中常用的工具，如调试工具（GDB 等）、版本控制工具（Git 等）。调试工具用于查找和修复代码中的错误，版本控制工具用于管理代码的版本和团队协作开发 。

### 智能系统创新设计赛（小米杯）

#### 比赛时间

2025年2月27日报名启动，2025年5月27日报名截止；2025年6月1日前在线提交初赛作品；2025年6月14日公布初赛成绩及全国总决赛入围名单；2025年8月下旬举行全国总决赛(线下比赛)。

初赛是在仿真平台中进行，决赛在线下(进入决赛主办方会给我们邮寄设备)。

#### 团队分工

* **创意策划师**：提出创新性的智能系统设计概念和方案，结合当前智能技术发展趋势和实际应用需求，挖掘具有潜力的创意点。例如提出一种基于人工智能和物联网技术的智能家居创新应用方案。
* **系统设计师**：负责将创意转化为系统架构设计，规划系统的整体框架、模块组成以及各模块之间的交互方式。比如设计一个智能安防系统的架构，包括前端传感器、数据传输网络、后端数据处理中心等部分的架构设计。
* **算法工程师**：针对智能系统中的关键功能实现算法，如在图像识别、语音识别、智能决策等方面设计和优化算法。例如在智能监控系统中，设计高效的目标检测算法，提高对异常行为的识别准确率。
* **开发工程师**：根据系统设计和算法实现，进行具体的代码编写和系统开发工作。涉及到硬件开发（如嵌入式系统开发）和软件开发（如移动应用开发、后端服务器开发）等方面。例如开发智能家居系统中的手机控制应用程序，以及与硬件设备通信的后端服务器程序 。
* **测试工程师**：对智能系统进行全面测试，包括功能测试、性能测试、稳定性测试等。确保系统在各种场景下都能正常运行，满足设计要求。例如测试智能交通系统在高流量情况下的响应时间和准确性 。

#### 知识储备

初赛是在仿真平台中进行，决赛在线下(进入决赛主办方会给我们邮寄设备)。
涉及相关技术包括: Linux系统使用(docker容器的使用)， 熟悉了解ros系统，人工智能相关算法(图像识别, 雷达识别), 四足机器人运动控制( 小米开源平台).

### 编译系统实现

#### 比赛时间

以 2024 年编译系统设计赛（华为毕昇杯）实现赛为例（该赛道与编译系统实现有相似性），时间安排如下：

* **报名阶段**：2024 年相关报名时间未明确给出，但参考操作系统设计赛等其他赛道，推测可能在 2 - 5 月左右 。
* **初赛阶段**：未明确初赛具体时间安排，但按照大赛整体节奏，自赛题发布后，有一定时间供参赛队完成初赛题目，且要求源代码与开发过程全部开源展示，参赛队应按要求提供开源发布的网址以供访问，并将相关内容提交到大赛指定的托管平台上。
* **全国决赛阶段**：未明确具体决赛时间，但从操作系统设计赛等类比，决赛可能分为多个阶段，如先提交源代码和设计实现文档进行评审，之后可能有现场比赛及答辩环节 。最终在 2024 年 8 月 18 - 22 日举办了全国总决赛，包含了现场比赛及答辩等内容 。

#### 团队分工

* **编译原理专家**：负责整个编译系统的理论指导和架构设计，确定编译系统的各个阶段（词法分析、语法分析、语义分析、代码生成、优化等）的实现策略。例如选择合适的语法分析算法（如 LL (1) 分析、LR 分析等）来构建语法分析器。
* **词法与语法分析工程师**：专注于词法分析器和语法分析器的开发。词法分析工程师将输入的源程序分割成一个个单词符号，语法分析工程师则根据词法分析的结果，构建语法树，检查源程序的语法结构是否正确。例如使用 Flex 和 Bison 工具分别生成词法分析器和语法分析器。
* **语义分析与中间代码生成工程师**：进行语义检查，确保源程序的语义正确，并生成中间代码。例如检查变量的声明和使用是否一致，将源程序转换为一种中间表示形式，如三地址码，方便后续的代码优化和目标代码生成。
* **代码优化工程师**：对中间代码进行优化，提高目标代码的执行效率。例如进行公共子表达式消除、循环优化等优化操作，减少目标代码的运行时间和空间占用。
* **目标代码生成工程师**：根据目标机器的指令集架构，将优化后的中间代码转换为目标机器的机器语言代码。例如针对 ARM 架构或 x86 架构生成相应的机器指令 。

#### 知识储备

* **编译原理**：全面掌握编译过程的各个阶段，包括词法分析、语法分析、语义分析、中间代码生成、代码优化和目标代码生成的原理和方法。这是进行编译系统实现的核心知识，例如理解不同语法分析算法的优缺点，才能选择合适的算法构建语法分析器。
* **编程语言**：熟练掌握 C、C++ 等编程语言，因为编译系统通常使用这些语言进行开发。同时，要对源语言（如 C、Java 等）有深入理解，才能准确地进行词法、语法和语义分析。例如开发一个 C 语言编译器，需要对 C 语言的语法规则和语义有透彻的理解 。
* **数据结构与算法**：运用各种数据结构（如链表、树、图等）来存储和处理编译过程中的各种信息，如语法树、符号表等。同时，使用算法进行词法分析、语法分析、代码优化等操作。例如使用深度优先搜索算法遍历语法树进行语义分析 。
* **计算机体系结构**：了解目标机器的体系结构，包括指令集、寄存器组织、内存管理等。这对于目标代码生成和代码优化至关重要，例如知道目标机器的指令格式和寻址方式，才能生成高效的目标代码 。

### 编译系统设计

#### 比赛时间

同样以 2024 年编译系统设计赛（华为毕昇杯）为例，时间安排如下：

* **报名阶段**：未明确具体报名时间，但推测与其他赛道类似，可能在 2 - 5 月左右开启报名 。
* **比赛阶段**：赛题发布后，参赛队有一定时间进行编译系统设计工作，过程中需遵循大赛关于开源等要求。未明确具体各阶段时间节点，但整体比赛流程与其他赛道类似，有初赛作品提交、评审，以及决赛阶段的进一步完善和展示等环节 。最终在 2024 年 8 月 18 - 22 日举办了全国总决赛，包含了现场比赛及答辩等内容 。

#### 团队分工

* **项目负责人**：统筹整个编译系统设计项目，制定项目计划、协调团队成员工作、把控项目进度和质量。根据大赛要求和团队实际情况，合理分配任务给各个成员，确保项目按计划推进。
* **系统架构设计师**：设计编译系统的整体架构，确定各个模块之间的关系和交互方式。规划词法分析、语法分析、语义分析、代码生成、优化等模块的架构，使其具有良好的扩展性和可维护性。
* **需求分析师**：深入理解大赛的赛题要求和潜在需求，将其转化为具体的功能需求和技术指标。与团队成员沟通，确保设计和实现的编译系统满足大赛要求和用户期望。例如分析赛题中对编译系统性能、支持的语言特性等方面的要求，并转化为具体的技术指标 。
* **文档撰写人员**：负责编写详细的设计文档、技术报告等。文档应包括编译系统的设计思路、实现方法、测试报告等内容，方便团队成员之间的沟通以及评审人员对项目的理解 。

#### 知识储备

* **编译原理**：深入理解编译过程的各个阶段的原理和方法，这是编译系统设计的基础。与编译系统实现不同，设计阶段更注重从宏观角度把握编译系统的架构和流程，例如如何设计一个灵活的架构，能够支持多种源语言和目标机器，以及如何在不同模块之间进行合理的功能划分和接口设计 。
* **软件工程**：掌握软件工程的方法和原则，包括项目管理、需求分析、软件设计、软件测试、软件维护等方面。在编译系统设计中，运用软件工程知识确保项目的顺利进行，提高软件的质量和可维护性。例如使用项目管理工具制定项目计划，进行有效的需求变更管理；运用软件设计模式优化编译系统的架构设计 。
* **编程语言**：除了 C、C++ 等常用开发语言外，需要对多种源语言（如 Java、Python、JavaScript 等）有一定了解，以便设计出能够支持多种语言的编译系统。熟悉不同编程语言的语法特点、语义规则和编程范式，有助于在设计编译系统时更好地处理不同语言的特性 。
* **系统思维与创新能力**：具备系统思维能力，能够从整体上考虑编译系统与其他系统组件的关系，以及如何与其他软件进行交互和集成。同时，要有创新能力，在满足大赛基本要求的基础上，提出创新性的设计思路和解决方案，使编译系统在性能、功能等方面具有独特优势 。

## 睿抗

### 编程技能赛

### 网络安全（CTF）

### 大数据竞赛

#### 赛程安排

* **省赛**：2024年10月19日（各地区可能微调），线上/线下结合
* **国赛**：2024年11月29日-12月1日，河北石家庄（省赛晋级者参与）

#### 技术要求

* 大数据平台搭建
  * 掌握Docker、Linux系统操作
  * 部署Hadoop/Spark生态
* 数据分析
  * 使用Python/R/SQL进行数据清洗与建模
  * 熟悉分类、聚类等算法
* 实时计算
  * 使用Flume/Kafka采集数据
  * 运用Spark Streaming实时处理
* 可视化
  * 利用Echarts/Tableau呈现分析结果

#### 知识储备

* **技术栈**：Hadoop生态（HDFS/YARN）、Spark、MySQL/HBase
* **工具**：Python（Pandas/NumPy）、SQL、Docker
* **算法**：分类/聚类/关联规则（如决策树、K-Means、Apriori）

#### 资料

https://bu.cnies.org/post/raicom-caip-data/

### ROS机器人仿真赛

#### 赛程安排

* **省赛**：报名截至2024.5.31，选拔期6.1-7.7
* **国赛**：2024.11.23-24，北京化工大学承办（报名截至7.15）

#### 技术要求

* 运动控制
  * ROS导航栈路径规划
  * 避障与动力学调试
* 传感器处理
  * 激光雷达数据解析（PCL库）
  * 摄像头图像处理（OpenCV库）
* 算法优化
  * 定位算法调优（卡尔曼滤波）
  * 路径规划优化（A\*算法）
* 系统集成
  * Gazebo仿真环境部署
  * 模块联调与通信管理

#### 知识储备

* **ROS核心**：节点/话题通信、URDF建模、Gazebo仿真
* **编程**：C++/Python实现控制算法
* **算法**：路径规划（A\*/Dijkstra）、定位（EKF/粒子滤波）、目标检测（YOLO等）

## 大唐杯

### 工程实践赛

#### 比赛时间

* **省赛时间**：2025 年 4 月 - 5 月。
* **国赛时间**：2025 年 6 月 - 7 月。

#### 团队分工

2人

#### 知识储备

1. **5G 技术应用**：
   * **5G 网络规划**
   * **5G 网络优化**
   * **协议分析**
2. **物联网技术**：
   * **物联网系统设计**
   * **数据采集**
   * **数据传输和分析**

### 创新应用赛

#### 比赛时间

* **省赛时间**：2025 年 4 月 - 5 月。
* **国赛时间**：2025 年 6 月 - 7 月。

#### 团队分工

6人

### 资料

题库

大唐杯官网

https://bu.cnies.org/post/dtcup/

## ASC 世界大学生超算竞赛

### 比赛时间

**报名时间**：2024 年 11 月 21 日至 2025 年 1 月 5 日

**初赛时间**：2025 年 1 月 6 日至 2025 年 2 月 21 日，各参赛队伍需在此期间提交一份提案，内容涵盖比赛结果、应用代码优化以及团队账号等信息，ASC 评审委员会将据此进行评审，筛选出优胜者晋级决赛。

**决赛时间**：2025 年 5 月 10 日至 2025 年 5 月 14 日在青海大学举行，决赛选手需现场设计并搭建集群，运行 HPL 基准测试，优化应用，并向 ASC 评审委员会以英文展示结果。

### 团队分工

**队长**

* 职责：统筹备赛流程→任务分配与突发应对→对外沟通
* 核心：强协调能力 + 全局视野

**算法**

* 职责：算法瓶颈诊断→逻辑重构（如优化AlphaFold3预测速度）

* 技能：算法原理深度理解 + 代码优化实战

**架构**

* 职责：硬件选型配置→集群调试→资源动态调优（内存/CPU）
* 重点：性价比平衡 + 稳定性保障

**领域应用**

* 聚焦：生命科学（如蛋白质预测/RNA甲基化检测）
* 作用：用生物学逻辑反哺算法与硬件优化（例：RNA甲基化检测流程优化）

**论文**

* 核心：全周期文档编写→英文答辩展示（集群设计/创新点）
* 关键：技术亮点提炼 + 可视化表达能力

### 知识储备

1. **编程基础**：建议学习Fortran（科学计算常用语言），熟悉其语法、文件操作及数值计算实现。同时掌握Python的数据处理技能，如Pandas、NumPy库的应用。
2. **Linux系统**：熟练使用基础命令（ls/cd/grep等），理解目录结构、文件权限和管道操作，具备系统参数调优能力以提升计算效率。
3. **并行计算**：重点掌握OpenMP（共享内存多线程）和MPI（分布式进程通信）两种模型，理解任务分解与数据依赖关系，了解混合编程模式的应用场景。
4. **超算架构**：熟悉CPU/GPU/网络等硬件协同原理，掌握从硬件安装到系统配置的集群搭建全流程，能通过拓扑优化、缓存策略提升集群性能。
5. **领域应用**：针对赛题需理解蛋白质结构预测（AlphaFold3模型原理）和RNA甲基化检测（如m5C修饰的生物学意义），关注计算流程优化方法以提高算法准确率与效率。

## C4中国高校计算机大赛

### 团体程序设计天梯赛（华山论剑 - 本科组）

**时间**：2025年4月20日

**人数**：10人

### 网络技术挑战赛

**资格赛**：2025年4月7日

### AIGC 创新赛

**初赛**：2025年5月17日

**复赛**：2025年6月1日 - 2025年7月19日

**内容**：参赛者通过使用蓝心大模型矩阵API，包括已开源的7B和最高70B的云端大模型、AI绘画与传统AI能力等，针对某一特定主题或应用场景，包括但不限于系统实用工具、社交通讯、生活服务、教育、健康、出行、影像、办公、资讯、金融、购物、音乐等场景，设计和开发具有创新性的应用、网页或demo等。复赛阶段，开放云真机和大模型端侧化能力，请在设计时考虑端侧化场景。决赛阶段，提供微调算力，帮助队伍进一步完善作品。

## BRICS

2024一带一路暨金砖国家技能发展与技术创新大赛之

人工智能算法设计与应用赛项

### 赛程安排

* **赛项1**：2024.10.08-10.15

* **赛项2**：2024.11.18-11.25

### 比赛内容

#### 赛项一

要求参赛队伍基于大赛组织方指定数据集，利用深度学习框架设计对应解决目标问题的算法和模型，实现对物体目标的检测和识别，且能够输出对应目标数据文件。参赛者需要在训练集上自行训练深度学习算法，检测并识别测试集中两类目标：行人和车辆。

参赛队伍训练好模型后，使用竞赛提供的测试集进行推理，并将推理结果按照赛事指定结果数据文件格式进行标准化输出。参赛者须将符合格式的检测结果保存在以参赛编号为名创建的文件夹内。本次赛事不对车辆类别进行细分，需要参赛队伍对最后的输出结果进行标准化处理。在线提交算法执行后标准化结果文件，由赛事算法效果评估程序自动评分。

赛事算法效果评估程序是根据竞赛测试集的算法执行结果，每一行记录为三个字段，分别为：待测图片编号、图片行人识别数和图片车辆识别数，该标准结果将和赛事标准输出结果进行一一校验。赛事测试集为 1000 张图片，完全匹配一行，得 0.1 分，满分 100 分。

#### 赛项二

本模块分为 3 个任务，比赛的样件是由若干个零件组成的一个智能循迹避障小车，具体要求如下：

任务 1：智能循迹小车 PPT 展示（分值：30 分）。由小组负责人介绍小车的制作原理、循迹算法、避障算法、小组分工等情况。

任务 2：轨道循迹跑（赛事指定轨道，分值：50 分）。让小车在预设轨道上运行，从小车循迹效果和运行速度两个方面来考察小车的性能，即小车循迹效果越好、运行用时越短，小车性能就越好。要求智能小车在规定的白色平面赛道自动按照黑色路线前进。

任务 3：自动避障行驶（分值：20 分）。在小车行驶轨道前方设置障碍物，要求小车能够在超声波传感器的信号反馈下，自动实现避障行驶。

### 知识储备

YOLO、Python、Linux、简单的单片机知识

## CTF

### 刷题

* [攻防世界](https://adworld.xctf.org.cn/home/index)
* [CTFHub](https://www.ctfhub.com/#/index)
* [BUUCTF在线评测](https://buuoj.cn/)

### 资料

* [CTF Wiki](https://ctf-wiki.org/)
* [ctf.show](https://ctf.show/)
* [Hello CTF](https://hello-ctf.com/)
* [看雪学苑](https://www.kanxue.com/chm.htm)
* [学习资源 - CTF Wiki](https://ctf-wiki.org/introduction/resources/)
* [2023最全CTF入门指南（建议收藏） - 知乎](https://zhuanlan.zhihu.com/p/631613398)

---

---
url: https://ain.hmgf.hxcn.space/competition/ppt-making-skills.md
---
# PPT 制作技巧

做 PPT 是大学生和职场人的必备技能。比赛 PPT 和课堂作业 PPT 不一样，评委要在几分钟内看懂你的项目，所以每一页都要有信息密度。这里整理实用的 PPT 制作技巧和模板资源。

## 快速制作

### 60 秒教你国金 PPT 封面制作

国金级别的 PPT 封面，60 秒就能做出来。这个视频演示了快速制作高质量封面的技巧，包括配色、排版、字体选择。适合需要快速出效果的场景。

### 不用找模板，60 秒教你国金 PPT 制作

不想花钱买模板？这个视频教你怎么从零开始制作国金级别的 PPT。用简单的工具和技巧，就能做出专业效果。

### 60 秒教你全国金奖级别的荣誉资质页 PPT

荣誉资质页是 PPT 里常见的页面类型。这个视频演示了如何快速制作专业的荣誉资质页，包括奖项展示、证书排版等。

## 比赛 PPT 设计要点

### 三创赛/互联网+ PPT 的核心原则

比赛 PPT 和日常汇报 PPT 最大的区别是：**评委只看几分钟，你必须在最短时间内把项目讲清楚。**

#### 原则一：信息密度 > 视觉花哨

很多同学花大量时间做动画、找素材，但内容空洞。评委看的是项目本身，不是动画效果。

**正确做法：**

* 每页只讲一个核心观点
* 用数据和图表代替大段文字
* 关键信息加粗、放大、用颜色突出

**错误做法：**

* 一页 PPT 塞满文字
* 花里胡哨的动画
* 没有重点，流水账式叙述

#### 原则二：故事线要清晰

比赛 PPT 本质是在讲故事。评委要快速理解：你做了什么、解决了什么问题、效果如何。

**标准故事线：**

1. **痛点问题**：市场有什么问题？用户有什么需求？
2. **解决方案**：你的产品/服务怎么解决这个问题？
3. **产品展示**：具体是怎么实现的？
4. **商业模式**：怎么赚钱？
5. **团队介绍**：为什么是你们来做？
6. **竞争优势**：和竞品比有什么优势？
7. **发展规划**：未来打算怎么做？
8. **财务预测**：预期收益如何？

#### 原则三：视觉层次分明

PPT 的视觉层次直接影响评委的阅读体验。

**视觉层次要素：**

* **标题**：最大字号，一眼就能看到
* **副标题/要点**：中等字号，概括核心内容
* **正文/数据**：最小字号，补充说明
* **颜色**：主色 + 辅助色 + 强调色，不要超过 3 种主色
* **对齐**：所有元素要有对齐关系，不要东一块西一块

### 封面设计

封面是评委看到的第一页，决定了第一印象。

**封面必须包含的信息：**

* 项目名称（大字）
* 团队名称
* 学校名称
* 比赛名称
* 指导老师（可选）

**封面设计技巧：**

* 背景图要和项目主题相关
* 配色要统一，不要花花绿绿
* 字体不要超过 2 种
* 留白要足够，不要塞满

**常见错误：**

* 背景图太花，字看不清
* 信息太多，没有重点
* 配色太杂，视觉混乱

### 目录页设计

目录页让评委快速了解 PPT 的结构。

**目录页设计要点：**

* 清晰列出各个章节
* 用编号或图标区分
* 当前章节可以高亮
* 保持简洁，不要加太多装饰

### 内容页设计

#### 数据展示

数据是比赛 PPT 的核心。好的数据展示能让评委快速理解项目的价值。

**数据展示技巧：**

* 用图表代替数字罗列
* 关键数据放大、加粗、用颜色强调
* 对比数据用柱状图
* 趋势数据用折线图
* 占比数据用饼图
* 多维数据用雷达图

**常见错误：**

* 图表太复杂，看不懂
* 数据没有来源，不可信
* 数据太多，没有重点

#### 产品展示

产品展示是 PPT 的核心页面，要让评委直观地看到你的产品。

**产品展示技巧：**

* 使用高质量的产品截图或实物图
* 标注核心功能点
* 展示用户界面（如果是软件产品）
* 展示使用场景
* 展示用户反馈

#### 团队介绍

团队介绍要突出团队的能力和互补性。

**团队介绍要点：**

* 每个成员的照片和姓名
* 核心成员的角色和职责
* 团队的专业背景
* 团队的互补性
* 指导老师的背景

**设计技巧：**

* 统一照片风格
* 用图标表示角色
* 突出核心成员
* 不要放太多人，重点介绍 3-5 人

### 结尾页设计

结尾页要给评委留下深刻印象。

**结尾页内容：**

* 项目名称
* 团队口号/Slogan
* 联系方式（可选）
* 感谢语

## 配色方案

### 比赛 PPT 推荐配色

#### 科技蓝

适合技术类项目，给人专业、可信赖的感觉。

* 主色：#2B579A（深蓝）
* 辅助色：#5B9BD5（浅蓝）
* 强调色：#FF6B35（橙色）
* 背景色：#F5F7FA（浅灰）

#### 生态绿

适合环保、健康、农业类项目。

* 主色：#2E7D32（深绿）
* 辅助色：#66BB6A（浅绿）
* 强调色：#FF8F00（橙色）
* 背景色：#F1F8E9（浅绿）

#### 商务灰

适合商业模式类项目，给人稳重、专业的感觉。

* 主色：#37474F（深灰）
* 辅助色：#78909C（浅灰）
* 强调色：#FF5722（橙色）
* 背景色：#ECEFF1（浅灰）

#### 教育橙

适合教育类项目，给人活力、创新的感觉。

* 主色：#E65100（深橙）
* 辅助色：#FF9800（浅橙）
* 强调色：#1565C0（蓝色）
* 背景色：#FFF3E0（浅橙）

### 配色工具推荐

* **[Coolors](https://coolors.co/)**：在线配色方案生成器
* **[Adobe Color](https://color.adobe.com/)**：Adobe 官方配色工具
* **[中国色](http://zhongguose.com/)**：中国传统颜色参考
* **[Color Hunt](https://colorhunt.co/)**：配色方案分享平台

## 字体选择

### 比赛 PPT 推荐字体

#### 中文字体

**标题字体（有力量感）：**

* **思源黑体 Bold**：免费开源，现代感强
* **阿里巴巴普惠体**：免费商用，简洁大方
* **站酷高端黑**：免费商用，适合标题
* **方正兰亭特黑**：需要授权，专业感强

**正文字体（易读性好）：**

* **思源黑体 Regular**：免费开源，阅读舒适
* **微软雅黑**：Windows 自带，兼容性好
* **苹方**：macOS 自带，苹果设备推荐

**不要用的字体：**

* 宋体（屏幕显示效果差）
* 楷体（不适合 PPT）
* 花哨的艺术字（不专业）

#### 英文字体

**标题：**

* **Montserrat**：现代感强，Google Fonts 免费
* **Poppins**：圆润友好，适合科技类
* **Roboto**：Google 官方字体，专业

**正文：**

* **Open Sans**：易读性好，免费
* **Lato**：优雅清晰，免费
* **Source Sans Pro**：Adobe 出品，免费

### 字体安装方法

**方法一：直接安装**

1. 下载字体文件（.ttf 或 .otf）
2. 右键字体文件 → "为所有用户安装"

**方法二：拖拽安装**

1. 打开 `C:\Windows\Fonts`
2. 将字体文件拖入文件夹

**注意：PPT 使用的字体在其他电脑上可能显示不同。建议将字体嵌入 PPT 或导出为 PDF。**

## 排版技巧

### 对齐原则

对齐是排版的基础。所有元素都要有对齐关系，不要东一块西一块。

**对齐方式：**

* **左对齐**：最常用，适合大多数场景
* **居中对齐**：适合标题、封面
* **右对齐**：适合数据、时间

**对齐工具：**

* PPT 的"对齐"功能（选中多个元素 → 格式 → 对齐）
* 参考线（视图 → 参考线）
* 网格线（视图 → 网格线）

### 留白原则

留白不是浪费空间，而是让页面有呼吸感。

**留白的好处：**

* 突出重点内容
* 提高可读性
* 让页面看起来更专业

**留白技巧：**

* 不要塞满整个页面
* 元素之间保持适当间距
* 边距要足够（建议至少 1cm）

### 对比原则

对比让重点内容一目了然。

**对比方式：**

* **大小对比**：重要的内容放大
* **颜色对比**：重要的内容用强调色
* **粗细对比**：重要的内容加粗
* **位置对比**：重要的内容放在显眼位置

### 重复原则

重复让 PPT 有统一感。

**重复元素：**

* 配色方案
* 字体组合
* 图标风格
* 布局结构
* 装饰元素

## 模板资源

### 三创赛、大创赛、互联网+国奖 PPT 模板

1000 份国奖 PPT 模板免费领取。这些模板经过实际比赛验证，直接套用就行。三创赛、大创赛、互联网+比赛都能用。

### 免费 PPT 模板网站

**国内：**

* **[OfficePLUS](https://www.officeplus.cn/)**：微软官方模板，免费高质量
* **[优品 PPT](https://www.ypppt.com/)**：免费模板，分类清晰
* **[第一 PPT](https://www.1ppt.com/)**：免费模板，数量多
* **[叮当设计](https://www.dingdoc.com/)**：免费模板，设计感强

**国外：**

* **[SlidesCarnival](https://slidescarnival.com/)**：免费高质量模板
* **[Slidesgo](https://slidesgo.com/)**：免费模板，风格多样
* **[Canva](https://www.canva.com/)**：在线设计工具，有免费模板

### PPT 素材网站

**图标：**

* **[iconfont](https://www.iconfont.cn/)**：阿里巴巴图标库，免费
* **[Flaticon](https://www.flaticon.com/)**：海量图标，有免费资源
* **[IconFinder](https://www.iconfinder.com/)**：图标搜索引擎

**图片：**

* **[Unsplash](https://unsplash.com/)**：免费高质量图片
* **[Pexels](https://www.pexels.com/)**：免费高质量图片
* **[Pixabay](https://pixabay.com/)**：免费图片和视频

**插图：**

* **[unDraw](https://undraw.co/)**：免费 SVG 插图
* **[Storyset](https://storyset.com/)**：免费插图，可自定义颜色

## AI 辅助

### Claude+Visio 终极画图王炸

原来 Claude 配合 Visio 才是终极画图方案。项目流程、思维导图、架构图，统统一键生成，效率直接拉满。如果你需要画各种图表，这个方法比手动画快得多。

### AI 生成 PPT 工具

**Gamma：**

* 输入文字自动生成 PPT
* 支持自定义主题
* 导出为 PPTX 格式
* 网址：[gamma.app](https://gamma.app/)

**美图 AI PPT：**

* 中文支持好
* 模板丰富
* 自动生成排版
* 网址：[design.xiaopiu.com](https://design.xiaopiu.com/)

**iSlide AI：**

* PPT 插件形式
* 一键优化排版
* 智能配色
* 网址：[islide.cc](https://www.islide.cc/)

**注意：AI 生成的 PPT 通常需要手动调整，不要直接用。建议用 AI 生成初稿，然后手动优化内容和排版。**

## 视频制作

### 零基础一分钟完成三创赛挑战杯视频制作

三创赛和挑战杯经常需要提交视频材料。这个视频教你怎么快速制作比赛视频，从脚本到剪辑，一分钟就能搞定基础版本。

### 比赛视频制作要点

**视频时长：**

* 三创赛：3-5 分钟
* 互联网+：3-6 分钟
* 挑战杯：5-10 分钟
* 大创：3-5 分钟

**视频内容：**

1. 项目介绍（30 秒）
2. 问题分析（30 秒）
3. 解决方案（1 分钟）
4. 产品展示（1 分钟）
5. 商业模式（30 秒）
6. 团队介绍（30 秒）
7. 发展规划（30 秒）

**视频制作工具：**

* **剪映**：免费，功能强大，适合新手
* **Premiere Pro**：专业级，功能全面
* **Final Cut Pro**：macOS 专用，专业级
* **DaVinci Resolve**：免费版功能强大，专业调色

**录制设备：**

* **手机**：现代手机画质足够
* **三脚架**：稳定画面必备
* **麦克风**：音频质量很重要
* **补光灯**：光线充足画面才好看

**录制技巧：**

* 选择安静的环境
* 光线要充足
* 画面要稳定
* 语速要适中
* 重点内容要强调

## 常见错误

### 比赛 PPT 常见错误

**内容错误：**

* 数据没有来源
* 逻辑不清晰
* 重点不突出
* 内容太泛，没有细节

**设计错误：**

* 配色太杂
* 字体太多
* 动画太花
* 排版不整齐

**演示错误：**

* 照着 PPT 念
* 语速太快
* 超时严重
* 回答问题不清晰

### 如何避免

**内容：**

* 每页只讲一个重点
* 数据要有来源
* 逻辑要清晰
* 请别人帮忙审阅

**设计：**

* 配色不超过 3 种
* 字体不超过 2 种
* 少用动画
* 对齐所有元素

**演示：**

* 多练习
* 控制时间
* 准备常见问题
* 注意语速和表情

---

---
url: https://ain.hmgf.hxcn.space/competition/internship-guide.md
---
# 计算机实习与就业指南

大厂实习是计算机专业学生的必经之路。这份指南帮你从零开始准备，少踩坑。

## 实习时间线

### 什么时候开始准备？

* **大一**：打好基础，学好编程语言和数据结构
* **大二上**：开始刷题，了解技术栈
* **大二下**：准备第一份简历，投日常实习
* **大三上**：准备暑期实习（秋招提前批）
* **大三下**：暑期实习 + 秋招准备
* **大四**：秋招 / 春招

**关键节点：**

* **暑期实习**：大三暑假，最重要的实习机会
* **秋招**：大四上学期（8-10 月），正式找工作
* **春招**：大四下学期（3-5 月），补录机会

### 暑期实习申请时间线

* **3-4 月**：提前批开始，大量投递
* **5-6 月**：正式批，面试高峰期
* **7-8 月**：实习期间，争取转正
* **9-10 月**：转正结果出来，开始秋招

### 各方向学习路线

#### 后端开发

**核心技术栈：**

* **语言**：Java（最主流）、Go（增长快）、C++（底层系统）
* **框架**：Spring Boot、Spring Cloud、MyBatis
* **数据库**：MySQL、Redis、MongoDB
* **中间件**：Kafka、RabbitMQ、Elasticsearch
* **工具**：Git、Docker、Linux、Maven/Gradle

**学习顺序：**

1. Java 基础 → 数据库 → JDBC
2. Spring → Spring Boot → MyBatis
3. Redis → Kafka → Elasticsearch
4. Docker → Linux → 微服务
5. 项目实战 → 刷题 → 投简历

#### 前端开发

**核心技术栈：**

* **基础**：HTML、CSS、JavaScript
* **框架**：Vue.js（国内主流）、React（外企主流）
* **工具**：Webpack、Vite、TypeScript
* **UI 框架**：Element Plus、Ant Design、Naive UI
* **进阶**：Node.js、Next.js/Nuxt.js

**学习顺序：**

1. HTML/CSS → JavaScript 基础
2. ES6+ → TypeScript
3. Vue.js/React → 路由 → 状态管理
4. 构建工具 → UI 框架
5. 项目实战 → 刷题 → 投简历

#### 算法/AI 方向

**核心技术栈：**

* **语言**：Python（必备）、C++（可选）
* **数学**：线性代数、概率论、微积分
* **框架**：PyTorch、TensorFlow
* **基础**：机器学习、深度学习、计算机视觉/NLP
* **工具**：NumPy、Pandas、Scikit-learn

**学习顺序：**

1. Python 基础 → 数学基础
2. 机器学习算法 → 深度学习基础
3. PyTorch → CV/NLP 选一个方向
4. 复现论文 → 比赛/项目
5. 刷题 → 投简历

#### 客户端开发

**核心技术栈：**

* **Android**：Kotlin、Jetpack Compose、Android SDK
* **iOS**：Swift、SwiftUI、UIKit
* **跨平台**：Flutter、React Native

## 简历撰写

### 简历的基本结构

一份好的技术简历应该包括：

* **基本信息**：姓名、学校、专业、联系方式、GitHub
* **教育背景**：学校、专业、GPA（如果好看的话）
* **技能清单**：编程语言、框架、工具
* **项目经验**：2-3 个有深度的项目
* **实习经历**：如果有，一定要写
* **竞赛/论文**：加分项
* **其他**：开源贡献、技术博客等

### 项目经验怎么写

**STAR 法则：**

* **Situation**：项目背景
* **Task**：你的任务
* **Action**：你做了什么
* **Result**：取得了什么成果

**示例：**

> **基于深度学习的图像分类系统**
>
> * 使用 PyTorch 实现 ResNet-50 模型，在 CIFAR-10 数据集上达到 95% 准确率
> * 设计数据增强策略，提升模型泛化能力
> * 优化模型推理速度，从 200ms 降低到 50ms
> * 技术栈：Python, PyTorch, Flask, Docker

**注意事项：**

* **量化成果**：用数字说话，比如"提升了 30% 性能"
* **突出贡献**：说清楚你做了什么，不是团队做了什么
* **技术栈要写**：方便 HR 筛选
* **不要写太多**：2-3 个项目足够，每个 3-5 行

### 简历排版

* **一页纸**：应届生简历不要超过一页
* **简洁清晰**：不要花哨的模板
* **PDF 格式**：保证排版不乱
* **文件名**：姓名-学校-岗位.pdf

### 简历模板推荐

* [超级简历](https://www.wondercv.com/)
* [木及简历](https://www.mujicv.com/)
* [LaTeX 简历模板](https://www.latextemplates.com/cat/curricula-vitae)

### 简历常见错误

**内容错误：**

* 技能写了但项目里没体现
* 项目描述太泛，没有量化
* 写了太多无关经历
* 没有突出自己的贡献

**排版错误：**

* 超过一页
* 字体太小（建议 10.5-11pt）
* 间距太小，看起来挤
* 文件名不规范

**投递错误：**

* 一份简历投所有岗位
* 投递时间太晚
* 没有记录投递进度
* 没有及时复盘面试

## 技术面试

### 面试流程

大厂面试一般 3-5 轮：

1. **笔试**：算法题，LeetCode 难度
2. **一面**：技术基础 + 算法
3. **二面**：项目深挖 + 系统设计
4. **三面**：综合面（可能有）
5. **HR 面**：聊人生、谈薪资

### 算法面试

**刷题策略：**

* **LeetCode**：至少刷 200 题，重点刷 Hot 100
* **按类型刷**：数组、链表、树、图、动态规划
* **每天 1-2 题**：保持手感
* **限时练习**：面试是限时的，平时也要限时

**常考题型：**

* **数组/字符串**：双指针、滑动窗口
* **链表**：反转、合并、环检测
* **树**：遍历、路径、LCA
* **图**：BFS、DFS、拓扑排序
* **动态规划**：背包、最长子序列
* **排序/搜索**：二分查找、快排

**刷题资源：**

* [LeetCode](https://leetcode.cn/)
* [代码随想录](https://programmercarl.com/)
* [Labuladong 的算法笔记](https://labuladong.online/algo/)
* [牛客网](https://www.nowcoder.com/)

### 项目深挖

面试官会深挖你的项目，准备这些问题：

* **项目背景**：为什么做这个项目？
* **技术选型**：为什么用这个技术？
* **难点挑战**：遇到什么问题？怎么解决的？
* **优化改进**：如果重新做，会怎么改进？
* **量化成果**：性能提升了多少？

**准备方法：**

* 把项目的技术细节梳理清楚
* 准备 2-3 个技术难点和解决方案
* 准备项目优化的方向
* 能画出系统架构图

### 系统设计

高级岗会考系统设计，常见题目：

* 设计一个短链接服务
* 设计一个秒杀系统
* 设计一个消息队列
* 设计一个分布式缓存

**准备建议：**

* 学习基本概念：缓存、数据库、消息队列、负载均衡
* 了解常见架构：微服务、分布式系统
* 练习画架构图
* 参考《系统设计面试》

**系统设计答题框架：**

1. **需求分析**：明确功能和非功能需求
2. **高层设计**：画出整体架构图
3. **详细设计**：核心模块的技术方案
4. **扩展讨论**：性能优化、可扩展性

### 行为面试

HR 面会问：

* 你的优缺点是什么？
* 遇到过什么困难？怎么解决的？
* 为什么选择我们公司？
* 你的职业规划是什么？

**回答技巧：**

* 用 STAR 法则讲故事
* 不要说前公司/前导师坏话
* 展示学习能力和团队合作
* 对公司有一定了解

### 八股文准备

八股文是面试中常考的基础知识，必须准备。

**后端八股文：**

* Java 基础：集合、多线程、JVM
* 数据库：MySQL 索引、事务、锁
* Redis：数据结构、持久化、缓存问题
* 计算机网络：TCP/UDP、HTTP/HTTPS
* 操作系统：进程、线程、内存管理
* 设计模式：单例、工厂、观察者

**前端八股文：**

* JavaScript：闭包、原型链、事件循环
* Vue/React：生命周期、响应式原理
* 浏览器：渲染原理、性能优化
* 计算机网络：HTTP/HTTPS、跨域
* CSS：盒模型、Flex、Grid
* Webpack：构建流程、优化

**八股文资源：**

* [小林 Coding](https://www.xiaolincoding.com/)
* [JavaGuide](https://javaguide.cn/)
* [前端面试题宝典](https://fe.ecool.fun/)

## 大厂实习经验

### 如何找到实习

**渠道：**

* **官网投递**：最直接，但竞争激烈
* **内推**：找学长学姐内推，成功率更高
* **牛客网**：有很多内推信息
* **LinkedIn**：外企实习
* **学校就业网**：有些只在学校发

**投递策略：**

* **海投**：不要只投一家，至少投 10 家
* **分梯队**：大厂 + 中厂 + 小公司
* **记录进度**：用表格记录每家的进度
* **及时复盘**：每次面试后总结经验

**投递时间：**

* **日常实习**：随时都有，竞争相对小
* **暑期实习**：3-5 月投递，竞争激烈
* **提前批**：7-8 月开始，秋招前哨战

### 实习期间做什么

* **主动沟通**：不懂就问，别自己闷头干
* **记录工作**：每天记录做了什么
* **争取产出**：有产出才能写进简历
* **学习技术**：实习是学习的最佳机会
* **建立人脉**：认识同事，以后可能内推你

**实习产出记录：**

* 每天记录做了什么
* 记录遇到的问题和解决方案
* 记录学到的新技术
* 记录项目的数据和成果

### 转正攻略

* **提前了解**：问清楚转正标准
* **超额完成**：比预期做得更多更好
* **主动汇报**：定期和导师/leader 沟通
* **展示价值**：让领导看到你的贡献
* **准备答辩**：有些公司需要答辩

**转正答辩准备：**

* 总实习期间的工作成果
* 准备 PPT（参考 PPT 制作技巧）
* 准备常见问题的回答
* 展示自己的成长和贡献

### 大厂实习体验

**字节跳动：**

* 节奏快，但能学到很多
* 有免费三餐和下午茶
* 转正率相对较高
* 技术氛围好
* 工具链完善，内部文档丰富

**腾讯：**

* 氛围相对轻松
* 有班车、食堂
* 不同事业体差异大
* 转正看部门
* 内部技术分享多

**阿里巴巴：**

* 有阿里味（企业文化）
* 晋升体系清晰
* 加班看业务
* 转正竞争激烈
* 内部培训体系完善

**美团：**

* 生活服务领域深耕
* 技术栈相对传统
* 转正率一般
* 工作生活平衡
* 业务理解有优势

**华为：**

* 狼性文化
* 薪资有竞争力
* 加班较多
* 适合长期发展
* 技术积累深厚

**小厂/创业公司：**

* 能接触到完整项目
* 成长空间大
* 但资源有限
* 简历含金量可能不如大厂

## 秋招准备

### 秋招时间线

* **7-8 月**：提前批开始
* **9-10 月**：正式批，面试高峰
* **11-12 月**：补录
* **次年 3-5 月**：春招

### 秋招 vs 暑期实习

* **暑期实习**：门槛低，是进入大厂的跳板
* **秋招**：正式招聘，名额多，竞争激烈
* **建议**：先拿暑期实习 offer，再冲秋招

### Offer 选择

考虑因素：

* **薪资**：总包（Base + 股票 + 奖金）
* **城市**：一线城市 vs 新一线
* **业务方向**：核心业务 vs 边缘业务
* **成长空间**：技术成长 vs 晋升机会
* **工作强度**：996 vs 965
* **公司前景**：稳定 vs 高风险高回报

**Offer 评估维度：**

1. **薪资待遇**：月薪、年终奖、股票、签字费
2. **工作地点**：一线/新一线/二线城市
3. **业务方向**：核心业务/创新业务/支撑业务
4. **团队氛围**：直属领导、团队文化
5. **成长空间**：技术深度、晋升通道
6. **工作强度**：加班频率、出差频率

### 谈薪技巧

* **了解行情**：牛客网、offershow 查薪资
* **不要先报价**：让 HR 先出价
* **有竞争 offer**：多个 offer 可以互相压价
* **不要只看 base**：看总包（股票、奖金、签字费）
* **合理预期**：不要狮子大开口

**谈薪话术：**

* "我目前有几个 offer 在考虑，薪资方面希望..."
* "我了解到这个岗位的市场行情是..."
* "如果薪资能达到 XX，我可以尽快决定"

## 面试常见问题

### 技术问题

* **自我介绍**：1-2 分钟，突出技术栈和项目
* **项目介绍**：用 STAR 法则
* **技术深度**：对简历上的技术要非常熟悉
* **算法题**：边写边讲思路，不要沉默

**自我介绍模板：**

```
面试官您好，我是 XXX，XX 大学 XX 专业大三学生。

技术栈方面，我主要做后端开发，熟悉 Java、Spring Boot、MySQL、Redis。

项目方面，我做过一个 XX 项目，主要负责 XX 模块，使用了 XX 技术，实现了 XX 功能，达到了 XX 效果。

我对 XX 方向很感兴趣，希望能在贵公司深入学习和成长。谢谢！
```

### 非技术问题

* **为什么选择我们**：提前了解公司和业务
* **职业规划**：展示清晰的发展方向
* **优缺点**：缺点要说正在改进的
* **加班怎么看**：不要说不接受，也不要说无所谓

**常见问题回答思路：**

**"你的缺点是什么？"**

* 说一个真实但不致命的缺点
* 说明你正在如何改进
* 举例说明改进的效果

**"为什么选择我们公司？"**

* 说明你对公司的了解
* 说明公司吸引你的地方
* 说明你能为公司带来什么

**"你的职业规划是什么？"**

* 短期目标（1-3 年）：技术深耕
* 中期目标（3-5 年）：技术专家/架构师
* 长期目标（5 年以上）：技术管理/创业

### 反问环节

可以问：

* 这个岗位的日常工作是什么？
* 团队的技术栈是什么？
* 新人有培训吗？
* 转正标准是什么？
* 团队规模和分工是怎样的？
* 这个岗位最大的挑战是什么？

不要问：

* 薪资多少（HR 面再问）
* 加班多不多（显得怕吃苦）
* 能不能远程（应届生不要问）

## 面试工具

### 在线面试平台

* **牛客网**：最常用的在线面试平台
* **飞书**：字节系公司常用
* **腾讯会议**：腾讯系公司常用
* **Zoom**：外企常用
* **Teams**：微软系公司常用

### 面试环境准备

* **网络**：确保网络稳定
* **设备**：电脑、摄像头、麦克风
* **环境**：安静、光线充足
* **背景**：简洁、整洁
* **备用方案**：手机热点、备用设备

### 面试礼仪

* 提前 5-10 分钟进入
* 穿着得体（不用西装，但要整洁）
* 保持微笑和眼神交流
* 语速适中，吐字清晰
* 面试结束后感谢面试官

## 相关资源

* [牛客网](https://www.nowcoder.com/)
* [LeetCode](https://leetcode.cn/)
* [代码随想录](https://programmercarl.com/)
* [飞书文档 - 面试经验](https://my.feishu.cn/wiki/KNh5wPCxGi1qpYkK4nGcojabnDb)
* [offershow](https://www.offershow.com/)

**参考视频：**

---

---
url: https://ain.hmgf.hxcn.space/competition/cybersecurity-learning.md
---
# 网络安全学习指南

网络安全是计算机领域的重要方向，就业前景好，但入门门槛也不低。这份指南帮你从零开始学网安。

## 学习路线

### 第一阶段：计算机基础（3-6 个月）

学网安之前，先打好计算机基础：

**操作系统：**

* Linux 基本命令
* 文件系统、进程管理
* 权限管理
* 推荐：装个 Ubuntu/Kali Linux，日常使用

**计算机网络：**

* TCP/IP 协议栈
* HTTP/HTTPS 协议
* DNS、ARP、ICMP
* 抓包工具：Wireshark、tcpdump
* 推荐：《计算机网络：自顶向下方法》

**编程语言：**

* **Python**：必学，写脚本、写工具
* **C/C++**：理解底层，漏洞分析
* **JavaScript**：Web 安全必备
* **Shell**：Linux 脚本
* **SQL**：数据库注入

**数据库：**

* MySQL/PostgreSQL 基本操作
* SQL 注入原理
* 数据库安全配置

### 第二阶段：Web 安全（3-6 个月）

Web 安全是入门最快的分支：

**基础漏洞：**

* **SQL 注入**：联合查询、盲注、堆叠注入
* **XSS**：反射型、存储型、DOM 型
* **CSRF**：跨站请求伪造
* **SSRF**：服务端请求伪造
* **文件上传**：绕过上传限制
* **文件包含**：本地包含、远程包含
* **命令注入**：系统命令执行
* **XXE**：XML 外部实体注入
* **反序列化**：Java、PHP 反序列化漏洞

**工具使用：**

* **Burp Suite**：Web 抓包神器
* **SQLMap**：自动化 SQL 注入
* **Nmap**：端口扫描
* **Dirb/Gobuster**：目录扫描
* **Metasploit**：渗透测试框架

**靶场练习：**

* [DVWA](https://github.com/digininja/DVWA)：经典 Web 靶场
* [SQLi-labs](https://github.com/Audi-1/sqli-labs)：SQL 注入专项
* [Pikachu](https://github.com/zhuifengshaonianhanlu/pikachu)：中文靶场
* [Upload-labs](https://github.com/c0ny1/upload-labs)：文件上传专项
* [Vulhub](https://github.com/vulhub/vulhub)：漏洞复现环境

### 第三阶段：渗透测试（3-6 个月）

从 Web 扩展到整个系统：

**信息收集：**

* 子域名枚举
* 端口扫描
* 指纹识别
* 社工库（合法使用）

**漏洞利用：**

* MSF 框架使用
* 权限提升
* 横向移动
* 持久化

**内网渗透：**

* 域渗透基础
* Kerberos 协议
* Pass the Hash
* 黄金票据

**工具：**

* Metasploit
* Cobalt Strike（了解）
* Empire
* BloodHound

### 第四阶段：安全开发（3-6 个月）

从攻击转向防御：

**安全开发：**

* 代码审计
* 安全编码规范
* SAST/DAST 工具
* DevSecOps

**安全运营：**

* 日志分析
* 入侵检测
* 应急响应
* 威胁情报

**安全合规：**

* 等级保护
* ISO 27001
* GDPR

## 学习资源网站

### 综合学习平台

**国内：**

* [安全客](https://www.anquanke.com/)：安全资讯和技术文章
* [先知社区](https://xianzhisecurity.com/)：漏洞分析
* [FreeBuf](https://www.freebuf.com/)：安全资讯
* [看雪论坛](https://bbs.kanxue.com/)：逆向和漏洞分析
* [吾爱破解](https://www.52pojie.cn/)：逆向和破解
* [T00ls](https://www.t00ls.net/)：渗透测试
* [网安学习资源](https://wyuanlin.top)：综合资源

**国外：**

* [Hack The Box](https://www.hackthebox.eu/)：在线靶场
* [TryHackMe](https://tryhackme.com/)：入门友好
* [PortSwigger](https://portswigger.net/web-security)：Web 安全学院
* [CyberDefenders](https://cyberdefenders.org/)：蓝队训练
* [PentesterLab](https://pentesterlab.com/)：渗透测试练习

### 视频教程

* [B 站网安教程](https://search.bilibili.com/all?keyword=网络安全)
* [i 春秋](https://www.ichunqiu.com/)：专业安全培训
* [安全牛](https://www.aqniu.com/)：安全课程

### 书籍推荐

**入门：**

* 《白帽子讲 Web 安全》- 吴翰清
* 《Web 安全攻防：渗透测试实战指南》- 徐焱
* 《黑客攻防技术宝典：Web 实战篇》

**进阶：**

* 《代码审计：企业级 Web 代码安全架构》
* 《内网安全攻防：渗透测试实战指南》
* 《加密与解密》- 段钢

**专业方向：**

* 《逆向工程核心原理》
* 《恶意代码分析实战》
* 《二进制安全》

## CTF 竞赛

### 什么是 CTF

CTF（Capture The Flag）是网络安全竞赛，通过解决安全挑战来获取 flag。

### CTF 题目类型

**Web：**

* SQL 注入、XSS、命令注入
* 反序列化、代码审计
* 框架漏洞

**Pwn（二进制漏洞利用）：**

* 栈溢出
* 堆利用
* 格式化字符串漏洞
* ROP 链

**Reverse（逆向工程）：**

* 程序分析
* 脱壳
* 算法逆向
* 恶意代码分析

**Crypto（密码学）：**

* 古典密码
* RSA、AES
* 哈希碰撞
* 随机数攻击

**Misc（杂项）：**

* 隐写术
* 流量分析
* 编码解码
* OSINT

### CTF 学习资源

**平台：**

* [CTFHub](https://www.ctfhub.com/)：入门友好
* [BUUCTF](https://buuoj.cn/)：题目丰富
* [攻防世界](https://adworld.xctf.org.cn/)：综合平台
* [picoCTF](https://picoctf.org/)：入门级
* [CTFtime](https://ctftime.org/)：国际赛事

**工具：**

* **Pwn**：pwntools、GDB、IDA
* **Web**：Burp Suite、SQLMap
* **Reverse**：IDA Pro、Ghidra、x64dbg
* **Crypto**：Python、SageMath
* **Misc**：Wireshark、Stegsolve、binwalk

**学习路线：**

1. 先学基础（Linux、网络、编程）
2. 选一个方向深入（Web 或 Misc 入门）
3. 刷题，从简单到难
4. 参加比赛，积累经验
5. 看 Writeup，学习别人的思路

### 重要 CTF 比赛

**国内：**

* **XCTF**：国内最大的 CTF 联赛
* **强网杯**：国家级比赛
* **网鼎杯**：公安系统主办
* **CISCN**：全国大学生信息安全竞赛
* **春秋杯**：i 春秋主办

**国际：**

* **DEF CON CTF**：最顶级的 CTF
* **Google CTF**：谷歌主办
* **PlaidCTF**：PPP 战队主办
* **HITB**：Hack In The Box

## 安全认证

### 国内认证

* **NISP**：国家信息安全水平考试
  * NISP 一级：入门级
  * NISP 二级：专业级
  * NISP 三级：高级

* **CISP**：注册信息安全专业人员
  * CISE：工程师
  * CISO：管理人员
  * CISP-PTE：渗透测试工程师

* **软考-信息安全工程师**：中级职称

### 国际认证

**入门级：**

* **CompTIA Security+**：入门首选
* **CEH**：道德黑客认证
* **eJPT**：初级渗透测试

**专业级：**

* **OSCP**：渗透测试认证（含金量高）
* **OSWE**：Web 安全认证
* **OSEP**：高级渗透测试
* **GPEN**：GIAC 渗透测试
* **GWEB**：GIAC Web 安全

**管理级：**

* **CISSP**：信息系统安全专业人员
* **CISM**：信息安全管理
* **CISA**：信息系统审计

### 认证选择建议

* **入门**：Security+ 或 NISP 一级
* **求职**：CISP-PTE 或 OSCP
* **进阶**：OSCP + CISSP
* **不要盲目考证**：实战经验比证书重要

## 就业方向

### 安全岗位类型

**攻击方向：**

* 渗透测试工程师
* 红队工程师
* 安全研究员
* 漏洞挖掘工程师

**防御方向：**

* 安全运营工程师
* 蓝队工程师
* 应急响应工程师
* 安全分析师

**开发方向：**

* 安全开发工程师
* 安全产品工程师
* 代码审计工程师

**合规方向：**

* 安全咨询师
* 等保测评师
* 安全审计师

### 薪资水平

* **应届生**：10-20K（一线城市）
* **3-5 年**：20-40K
* **5-10 年**：40-80K
* **安全专家/架构师**：80K+

### 求职建议

* **多打 CTF**：证明技术能力
* **挖漏洞**：SRC 挖洞，有奖金
* **写博客**：展示技术深度
* **做项目**：有自己的安全工具
* **考认证**：CISP-PTE、OSCP

## 安全工具

### 信息收集

* **Nmap**：端口扫描
* **Shodan**：网络空间搜索引擎
* **Censys**：互联网设备搜索
* **Subfinder**：子域名枚举
* **Amass**：信息收集

### Web 安全

* **Burp Suite**：Web 抓包
* **SQLMap**：SQL 注入
* **Nuclei**：漏洞扫描
* **Dirsearch**：目录扫描
* **XSStrike**：XSS 检测

### 二进制安全

* **IDA Pro**：反汇编
* **Ghidra**：逆向工程
* **GDB**：调试器
* **pwntools**：Pwn 工具
* **Radare2**：逆向框架

### 密码学

* **Hashcat**：密码破解
* **John the Ripper**：密码破解
* **CyberChef**：编码解码
* **SageMath**：数学计算

## 安全社区

### 论坛和社区

* [看雪论坛](https://bbs.kanxue.com/)
* [吾爱破解](https://www.52pojie.cn/)
* [先知社区](https://xianzhisecurity.com/)
* [安全客](https://www.anquanke.com/)
* [FreeBuf](https://www.freebuf.com/)

### 公众号

* 安全客
* FreeBuf
* 看雪学院
* 先知安全
* 嘶吼

### 会议

* **KCon**：黑客大会
* **XCON**：安全焦点
* **HITB**：Hack In The Box
* **Black Hat**：黑帽大会
* **DEF CON**：顶级黑客大会

## 相关资源

* [飞书文档 - 网安学习资源](https://my.feishu.cn/wiki/VVv1w0kCzirT04kmHwKc5PDWnBg)
* [网安学习资源汇总](https://wyuanlin.top)
* [金山文档 - 网安资源](https://www.kdocs.cn/l/cagbu0iHI8eA)

**参考视频：**

---

---
url: https://ain.hmgf.hxcn.space/competition/reimbursement-guide.md
description: >-
  3D环梦工坊编程竞赛组报销发票参考指南，包含报销抬头、纳税人识别号、银行账号等财务信息，以及报名费、交通费、住宿费、服务器租赁等各类费用的详细报销要求与材料清单。
---

# 报销发票

## 发票信息

发票抬头：山东师范大学

纳税人识别号：1237000049557382XT

营业地址：济南市历下区文化东路88号

联系电话：0531-86180895

开户银行：中国建设银行济南文化东路支行

银行账号：3700 1618 8020 5001 2321

开户行号：1054 5100 0016

## 材料准备

* 发票
* 电子订单
* 支付凭证

### 1. 报名费

* 一般在比赛平台开具发票。
* 发票背面左上角使用**铅笔**写报名费，张三，xx元。
* 发票正面使用黑色中性笔签字。
* 如果发票包含张三李四王五三人的报名费，需要签三个人的名字。
* 支付凭证使用黑色中性笔签字。
* 如果支付凭证包含张三李四王五三人，需要签三个人的名字，并注明xxx、xxx等三人报名费。

### 2. 路费

* 从车票、机票购买处开发票。如果有电子行程单可选，并且平台注明等效为发票，也可以开电子行程单。
* 发票背面左上角使用**铅笔**写火车票/机票/打车费，从<出发地>→<目的地>，HH点MM分出发/登机，HH点MM点到达，张三（全部乘车人），xx元
* 发票正面使用黑色中性笔签字。
* 如果发票包含张三李四王五三人的路费，需要签三个人的名字。
* 支付凭证使用黑色中性笔签字。
* 如果支付凭证包含张三李四王五三人，需要签三个人的名字，并注明xxx、xxx等三人火车票/机票/打车费，从<出发地>→<目的地>，HH点MM分出发/登机，HH点MM点到达，张三（全部乘车人）。
* 如果购买机票，需要证明机票价格更便宜或者相差不多。
* 如果打车需要上高速，无法直接凑滴滴开高速费的发票；需要联系师傅要付款凭证，使用上面的条形码，在“山东省高速公路人工收费电子发票”小程序开具发票。

### 3. 住宿费

* 一般从酒店前台处开发票。
* 发票背面左上角使用**铅笔**写住宿费，从MM月DD日→MM月DD日，共几晚，张三（全部乘车人），xx元
* 发票正面使用黑色中性笔签字。
* 如果发票包含张三李四王五三人的住宿费，需要签三个人的名字。如果其中一个人不在队伍，需要单独注明xxx在xx队伍，以及两个队伍分别的额度占比。
* 酒店报销不超过350/晚
* 支付凭证使用黑色中性笔签字。
* 如果支付凭证包含张三李四王五三人，需要签三个人的名字，并注明从MM月DD日→MM月DD日，共几晚，张三（全部乘车人），xx元，张三（全部乘车人）。
* 如果有额度分配情况，也需要在支付凭证写上说明。

### 4. 虚拟产品费用（服务器租赁、API调用等）

适用于服务器租赁、云服务、模型/API 调用、对象存储、域名解析等虚拟产品费用报销。

#### 需要准备的材料

* 发票
* 付款凭证
* 消费记录
* 平台账号说明页（**单独一页**）

#### 平台账号说明页

需单独打印一页，写明：

* 平台名称
* 平台账号
* 账号使用人姓名
* 使用用途
* 使用时间范围
* 对应消费金额
* 相关消费记录说明

可参考如下格式：

> 平台名称：xxx
> 平台账号：xxx
> 使用人姓名：张三
> 使用用途：比赛/项目所需服务器租赁、API 调用等
> 使用时间：20xx年xx月xx日—20xx年xx月xx日
> 消费金额：xx元
> 使用情况与记录：用于xxx，详见后附消费记录、付款凭证、发票。

#### 发票要求

* 需由对应平台开具发票。
* 发票背面左上角使用**铅笔**写：
  **平台账号：xxx，张三，xx费用，xx元**
* 这里的“xx费用”应写明具体类别，如：
  * 服务器租赁费
  * API 调用费
  * 云存储费
  * 域名/解析服务费
* 发票正面使用黑色中性笔签字。
* 如一张发票涉及多人共同使用，需写清各自姓名及费用分摊情况。

#### 付款凭证要求

* 需提供支付成功截图、支付订单页、银行卡/支付宝/微信支付记录等可证明付款完成的材料。
* 付款凭证使用黑色中性笔签字。
* 并在凭证空白处注明：
  **平台账号：xxx，张三，xx费用，xx元**
* 如涉及多人共同使用，需注明各自姓名、费用类别及金额分配。

#### 消费记录要求

* 需提供平台后台导出的账单、消费明细、订单记录、调用记录、资源使用记录等。
* 消费记录上需注明：
  **平台账号：xxx，张三，xx费用，xx元**
* 消费记录应尽量体现：
  * 平台账号
  * 消费时间
  * 消费项目
  * 消费金额
  * 使用情况或调用情况

#### 说明

* 虚拟产品费用原则上需做到：**账号明确、用途明确、消费可追溯、付款可核验、发票可对应**。
* 发票、付款凭证、消费记录三者的金额和时间范围应尽量保持一致。
* 如因平台原因无法在单据原件上手写说明，可另附情况说明，并确保能对应到平台账号、姓名和费用。

### 5. 其他材料费

## 其他

如果老师带队跟随，需要填写“山东师范大学请假审批备案表”，盖学院章；同时附上参赛通知第一页等放在审批表后。

---

---
url: https://ain.hmgf.hxcn.space/research.md
description: 收集科研入门与文献综述相关资料，聚合 CiteSpace 等工具的使用教程，便于统一查阅与后续扩展。
---

# 科研总览

---

---
url: https://ain.hmgf.hxcn.space/research/citespace-from-scratch.md
description: 收集 CiteSpace 入门与实操资料，涵盖软件下载、文献导出、项目创建与基础分析流程。
---

# 从零开始使用 CiteSpace 完成文献综述

本文为已有学习笔记迁移稿，保留原始资料链接、概念说明与实操流程，并归档到“科研 / 文献综述”分类。

\[toc]

***

## 简介

## 定义及作用

Citespace是一款可视化科学知识图谱构建工具，用于帮助研究者理解科学研究领域的知识结构和学术研究网络。

Citespace可以帮助研究者分析科学文献之间的引用关系、作者之间的合作关系等网络关系，并可生成图形化的展示结果。

Citespace的作用是帮助研究者挖掘科学研究领域的前沿热点、发现学术合作的机会，并辅助决策者制定科学研究政策和发展战略。

## 发展历程

Citespace最早由美国密歇根大学的Chaomei Chen教授于2000年开发，并不断得到改进和完善。

Citespace在发展过程中加入了更多的功能和特性，包括自动摘要提取、社会网络分析、知识集群识别等，以更好地满足科学研究者的需求。

## 功能

### 可视化科学知识图谱构建：

Citespace可以通过分析学术文献的引用关系、合作关系等，构建科学知识图谱，并将其以图形化的形式展示出来。

可视化的科学知识图谱可以帮助研究者清晰地了解学术研究领域的知识结构和演化趋势，帮助研究者掌握学术研究的动态变化。

### 学术研究网络关系分析：

Citespace可以通过分析学术文献之间的引用关系、作者之间的合作关系等，帮助研究者进行学术研究网络关系的分析。通过分析学术研究网络关系，研究者可以了解学术研究的合作模式、研究热点等信息，进而指导自己的研究方向和合作选择。

### 科学文献计量分析：

Citespace可进行科学文献的计量分析，比如统计研究领域的文献产量、被引频次等指标，帮助研究者评估学术研究的影响力和重要性。科学文献计量分析可以支持研究者进行科学研究绩效评估、学术评价等工作，并为科学研究政策的制定提供参考依据。

## 一些概念

### 共词

又称共现词，英文为“co-occurrence”，常见搭配有共词分析，共现网络，共现词分析。共现即共同出现，通常指关键词。含义：以keyword为节点类型进行分析，生成的图谱中有很多节点，这里的节点是关键词，假如有23篇文章中共同出现了一个关键词“教育”，我们可以说“教育”的频次为23次，也可以说共现次数为23次。

### 突现词

也称突显词，凸现词，英文为“burst term”或者“burstness”。含义：突然爆发的术语，举例说明，直播这个概念是零几年就出现了，但是有人把2017年称为“直播元年”，正是从2017年开始，直播这个概念广为流传，日渐火爆，因此类比到论文的分析中，“直播”就是一个突显词。假如从2020年开始，直播热度趋冷，少有人关注了，那么再分析中就可以指出，“直播”这个突显词从2017年开始突现，2020年突现结束。

### 中介中心性

英文为betweenness centrality，在论文或者各种资料里面提及到的“中心性”一般都是指中介中心性，它是衡量一个节点在整个图谱的网络结构中的重要性的，中心性大于0.1就是比较重要的节点了。

## 安装 CiteSpace

## 下载地址（选择下载速度较快的即可）

<https://ed.qcea.top/ChaIndex/Softwares/Windows/Productivity/Paper/Citespace/CiteSpace-6.3.1.msi>

[CiteSpace](https://sourceforge.net/projects/citespace/)

## 安装

没啥好说的，一路点击下一步，直到安装完成即可

![Untitled](https://gastigado.cnies.org/d/public/Untitled.webp)

## 运行

运行后会弹出黑色的终端窗口，不要关闭，等待一下即可。

如果出现这个消息，按照提示删除相关文件并后重新开启 Citespace 即可

![Untitled](https://gastigado.cnies.org/d/public/Untitled%201.webp)

![Untitled](https://gastigado.cnies.org/d/public/Untitled%202.webp)

在仅供个人使用的提示旁边，选择同意

![Untitled](https://gastigado.cnies.org/d/public/Untitled%203.webp)

看到这个窗口，恭喜你进入主界面了

![Untitled](https://gastigado.cnies.org/d/public/Untitled%204.webp)

![Untitled](https://gastigado.cnies.org/d/public/Untitled%205.webp)

![Untitled](https://gastigado.cnies.org/d/public/Untitled%206.webp)

## 开始使用

## 文献导出数据

在知网检索论文，选择合适的论文后，导出为 Refworks

![Untitled](https://gastigado.cnies.org/d/public/Untitled%207.webp)

## 导入数据

新建文件夹，其中包含4个分别命名为“input”，“output”，“data”和“project”的子文件夹，将所有 txt 命名 downloadxx.txt，放入“input”子文件夹。

![Untitled](https://gastigado.cnies.org/d/public/Untitled%208.webp)

![Untitled](https://gastigado.cnies.org/d/public/Untitled%209.webp)

完成后关闭这个窗口即可

首先需要新建项目，从data这个文件夹中导入备好的文献数据。

![Untitled](https://gastigado.cnies.org/d/public/Untitled%2010.webp)

## 分析选项

![Untitled](https://gastigado.cnies.org/d/public/Untitled%2011.webp)

![Untitled](https://gastigado.cnies.org/d/public/Untitled%2012.webp)

---

---
url: https://ain.hmgf.hxcn.space/research/paper-writing-guide.md
---
# 科研论文写作指南

搞科研绕不开论文。不管是保研、考研还是工作，论文都是硬通货。这篇文章帮你搞清楚论文写作的基本套路，少走弯路。

## 期刊和会议级别划分

### 什么是水刊、顶刊、顶会？

学术圈有鄙视链，期刊和会议也分三六九等。搞清楚这些概念，才能知道自己的论文值多少钱。

**国际期刊级别（从高到低）：**

* **Nature / Science**：神级，发一篇够吹一辈子
* **Cell**：生物医学领域的顶刊
* **各领域顶刊**：比如计算机的 TPAMI、医学的 NEJM
* **SCI 一区**：影响因子排名前 25% 的期刊
* **SCI 二区**：影响因子排名 25%-50%
* **SCI 三区 / 四区**：门槛相对较低，但也得有真东西

**计算机领域的会议级别：**

* **CCF-A 类**：顶会中的顶会，比如 CVPR、NeurIPS、SIGCOMM
* **CCF-B 类**：很有分量，比如 AAAI、IJCAI
* **CCF-C 类**：入门级会议，适合练手
* **非 CCF 收录**：质量参差不齐，得自己判断

**国内期刊级别：**

* **中文核心（北大核心）**：国内认可度高
* **CSCD**：中国科学引文数据库
* **科技核心**：门槛相对较低
* **普刊**：没什么含金量，但好发

**EI 检索：**

* **EI 期刊**：比 SCI 低一档，但也还行
* **EI 会议**：会议论文被 EI 检索，比普通会议强

**SSCI：**

* 社科类的 SCI，发 SSCI 的都是大佬

**怎么判断一个期刊/会议好不好？**

1. 看影响因子（Impact Factor）
2. 看中科院分区或 JCR 分区
3. 看是否被 SCI/EI/SSCI 收录
4. 看审稿周期（太短的可能是水刊）
5. 看版面费（收钱的不一定是水刊，但水刊基本都收钱）

**警惕掠夺性期刊：**

* 邮件轰炸邀请你投稿的，基本是坑
* 审稿周期异常短（一两周就接收的）
* 版面费高得离谱
* 在 Beall's List 上能查到的

**参考视频：**

## 论文写作基础

### 论文的基本结构

一篇标准的学术论文包括：

* **Title**：标题要简洁明了，能概括研究内容
* **Abstract**：摘要，200-300 字讲清楚做了什么、怎么做的、结果如何
* **Introduction**：引言，介绍背景、问题、现有工作的不足
* **Related Work**：相关工作，总结前人的研究
* **Methodology**：方法，详细介绍你的方法
* **Experiments**：实验，展示实验结果
* **Conclusion**：结论，总结贡献和未来方向
* **References**：参考文献

### 写作顺序建议

别从头写到尾，推荐顺序：

1. 先写 **Methodology**（你最熟悉的部分）
2. 再写 **Experiments**（实验结果已经有了）
3. 然后写 **Introduction** 和 **Related Work**
4. 接着写 **Conclusion**
5. 最后写 **Abstract**（全文写完后再总结）
6. **Title** 最后定（根据全文内容提炼）

### 写作技巧

**标题：**

* 不要太长，15 个词以内
* 包含关键词
* 避免缩写（除非是领域内公认的）
* 可以用冒号分隔主副标题

**摘要：**

* 第一句：背景和问题
* 第二句：现有方法的不足
* 第三句：你的方法
* 第四句：实验结果
* 第五句：贡献总结

**引言：**

* 从大背景切入，逐步聚焦到具体问题
* 说明这个问题为什么重要
* 总结现有方法的不足
* 介绍你的方法和贡献
* 最后给出论文结构

**方法部分：**

* 先给出问题定义
* 用公式、图表辅助说明
* 分步骤介绍方法
* 解释每个设计的动机

**实验部分：**

* 数据集描述
* 评估指标
* 基线方法对比
* 消融实验（证明每个模块都有用）
* 可视化分析

### 常见写作错误

* **语法错误**：用 Grammarly 检查
* **逻辑不通**：找人 proofread
* **图表不清晰**：用矢量图，字体要大
* **引用不规范**：用 BibTeX 管理
* **格式不对**：严格按模板来

### 论文写作工具

* **Overleaf**：在线 LaTeX 编辑器，多人协作方便
* **TeXstudio**：本地 LaTeX 编辑器
* **Grammarly**：语法检查
* **QuillBot**：改写润色
* **Connected Papers**：论文关系图谱
* **Semantic Scholar**：论文搜索

## 论文发表流程

### 投稿前准备

1. **选刊/选会**：根据研究方向和论文质量选择合适的目标
2. **读投稿指南**：每个期刊/会议都有自己的格式要求
3. **准备材料**：
   * 论文正文
   * Cover Letter（给编辑的信）
   * 图表（高清、符合要求）
   * 代码和数据（如果需要开源）
4. **查重**：用 iThenticate 或 Turnitin 查一下

### 投稿流程

**期刊投稿：**

1. 注册账号，进入投稿系统
2. 填写作者信息、摘要、关键词
3. 上传论文和附件
4. 推荐审稿人（选你领域内的大佬）
5. 等待编辑初审
6. 进入同行评审
7. 收到审稿意见
8. 修改并回复审稿意见
9. 再次等待审稿
10. 最终决定（接收 / 拒稿 / 小修 / 大修）

**会议投稿：**

1. 准备论文（严格按模板）
2. 在截止日期前提交
3. 等待审稿（一般 2-3 个月）
4. 收到通知
5. 如果接收，准备 Camera-Ready 版本
6. 准备 Presentation 或 Poster

### 审稿周期

* **快的**：1-3 个月（某些会议）
* **正常的**：3-6 个月（大多数期刊）
* **慢的**：6-12 个月（某些顶刊）
* **超慢的**：1 年以上（少数情况）

### 如何回复审稿意见

1. **逐条回复**：每个意见都要回应
2. **态度要好**：即使审稿人说错了，也要礼貌
3. **有理有据**：用数据和文献支持你的修改
4. **标记修改**：在论文中用颜色标出修改的部分
5. **写 Response Letter**：详细说明你做了哪些修改

### 被拒了怎么办

* **别灰心**：顶会拒稿率 75% 以上很正常
* **看审稿意见**：找到可以改进的地方
* **修改后重投**：换个期刊/会议继续投
* **申诉**：如果审稿意见明显不合理，可以申诉

### 版面费

* **免费的**：大多数顶会和好期刊
* **收费的**：Open Access 期刊一般收 APC（Article Processing Charge）
* **价格范围**：几百到几千美元不等
* **警惕**：收钱不一定是水刊，但水刊基本都收钱

## 科研工具推荐

### 文献管理

* **Zotero**：免费开源，插件丰富
* **Mendeley**：免费，社交功能强
* **EndNote**：老牌，学校一般有正版
* **Notion**：可以搭建文献管理系统

### 论文搜索

* **Google Scholar**：最全的学术搜索引擎
* **Semantic Scholar**：AI 驱动，推荐准确
* **Connected Papers**：可视化论文关系
* **arXiv**：预印本，能提前看到最新研究
* **DBLP**：计算机领域的论文数据库

### 写作工具

* **Overleaf**：在线 LaTeX，多人协作
* **TeXstudio**：本地 LaTeX
* **VS Code + LaTeX Workshop**：轻量级方案
* **Word**：适合不熟悉 LaTeX 的同学

### 画图工具

* **draw.io**：免费在线画图
* **Visio**：微软的专业画图工具
* **TikZ**：LaTeX 原生画图
* **matplotlib**：Python 画图
* **Origin**：科研画图神器

### 实验管理

* **Weights & Biases**：实验跟踪
* **TensorBoard**：深度学习可视化
* **MLflow**：机器学习生命周期管理
* **GitHub**：代码版本管理

### 论文阅读

* **Readwise**：高亮和笔记管理
* **Notion**：笔记整理
* **Obsidian**：双向链接笔记
* **MarginNote**：PDF 标注和思维导图

## 科研心态

### 常见心态问题

* **冒名顶替综合征**：觉得自己不配，别人都比自己强
* **完美主义**：总想做到完美，结果什么都做不完
* **比较心理**：看别人发论文了，自己还没动静
* **导师压力**：导师催进度，自己又没方向

### 怎么调整

* **接受不完美**：先完成，再完美
* **关注自己**：别老看别人，专注自己的研究
* **找同行**：和同方向的同学交流，互相打气
* **适当休息**：科研不是生活的全部

### 时间管理

* **番茄工作法**：25 分钟专注，5 分钟休息
* **周计划**：每周定个小目标
* **日总结**：每天记录做了什么
* **拒绝拖延**：最难的事放在早上做

## 读研后才知道的事

读研和本科完全不同，这些事越早知道越好：

1. **导师比学校重要**：好导师能让你读研体验翻倍
2. **发论文是硬道理**：没论文，什么都白搭
3. **自学能力是核心**：课堂上学不到科研需要的东西
4. **文献阅读量要够**：每周至少读 2-3 篇论文
5. **实验记录要详细**：不然复现的时候会哭
6. **多和导师沟通**：别自己闷头干
7. **参加学术会议**：认识同行，开拓视野
8. **早点开始写论文**：别等到最后才动笔
9. **代码要规范**：不然自己都看不懂
10. **备份很重要**：硬盘坏了就白干了
11. **身体是本钱**：别熬夜，多运动
12. **社交不能丢**：读研容易和社会脱节
13. **实习要看情况**：有些导师不让实习
14. **心态要好**：被拒稿是常态
15. **想清楚为什么读研**：盲目读研会后悔

**参考视频：**

## 相关资源

* [飞书文档 - 科研资源汇总](https://my.feishu.cn/wiki/Cm15wvl8JiC8pUknsfVc6TQNnDc)
* [Connected Papers](https://www.connectedpapers.com/)
* [Semantic Scholar](https://www.semanticscholar.org/)
* [Overleaf](https://www.overleaf.com/)
* [Zotero](https://www.zotero.org/)

---

---
url: https://ain.hmgf.hxcn.space/research/literature-management.md
---
# 文献管理指南

搞科研，文献管理是基本功。管理不好，找论文像大海捞针。这篇文章介绍几种主流的文献管理方法和工具。

## 为什么要管理文献

* **找得到**：读过的论文能快速找到
* **记得住**：知道每篇论文讲了什么
* **用得上**：写论文时能快速引用
* **不重复**：避免重复阅读同一篇论文

## 文献管理方法

### 文件夹分类法

最简单的方法，按主题建文件夹：

```
文献库/
├── 研究方向1/
│   ├── 综述/
│   ├── 方法/
│   └── 应用/
├── 研究方向2/
│   ├── 综述/
│   ├── 方法/
│   └── 应用/
└── 待读/
```

**优点：** 简单直观，上手快

**缺点：** 一篇论文可能属于多个分类，不好放

### 标签分类法

用标签代替文件夹，一篇论文可以有多个标签：

* \#深度学习 #图像分类 #CNN
* \#综述 #2024
* \#待读 #重要

**优点：** 灵活，支持多维度分类

**缺点：** 标签多了会乱

### Notion 数据库法

用 Notion 建立文献数据库，每个论文是一个条目，包含：

* 标题
* 作者
* 年份
* 期刊/会议
* 摘要
* 关键词
* 阅读状态
* 个人评价
* 相关笔记

**优点：** 信息全面，支持筛选和排序

**缺点：** 前期搭建需要时间

### Zettelkasten 卡片法

德国社会学家卢曼的方法，每篇论文做一张卡片，卡片之间建立链接：

* 每张卡片一个核心观点
* 卡片之间用链接关联
* 形成知识网络

**优点：** 深度理解，形成知识体系

**缺点：** 耗时，适合长期积累

## 文献管理工具

### Zotero

**推荐指数：** ★★★★★

免费开源的文献管理工具，插件生态丰富。

**核心功能：**

* 浏览器一键抓取论文
* 自动生成引用格式
* PDF 标注和笔记
* 多设备同步
* 团队协作

**安装和配置：**

1. 下载 [Zotero](https://www.zotero.org/)
2. 安装浏览器插件（Chrome/Firefox/Edge）
3. 注册账号，开启同步
4. 安装常用插件

**必装插件：**

* **Zotero Connector**：浏览器一键保存
* **Zotero PDF Translate**：PDF 翻译
* **Zotero Better BibTeX**：BibTeX 导出
* **Zotero IF**：显示期刊影响因子
* **Zotero GPT**：AI 辅助阅读
* **Zotero Style**：自定义样式

**使用技巧：**

* 用文件夹 + 标签结合管理
* 定期整理，删除不需要的论文
* 利用自动抓取功能，减少手动输入
* 配合 Obsidian 做深度笔记

**参考视频：**

### Mendeley

**推荐指数：** ★★★★

Elsevier 旗下的免费文献管理工具。

**核心功能：**

* PDF 管理和标注
* 自动生成引用
* 社交功能（发现相关论文）
* 团队协作
* 云同步

**优点：**

* 免费
* 社交功能强
* 界面友好

**缺点：**

* 同步空间有限（2GB）
* 插件没有 Zotero 丰富
* 被 Elsevier 收购后有些功能受限

### EndNote

**推荐指数：** ★★★

老牌文献管理工具，学校一般有正版授权。

**核心功能：**

* 文献管理
* 引用生成
* 与 Word 深度集成
* 在线搜索

**优点：**

* 功能全面
* 与 Word 集成好
* 学校有正版

**缺点：**

* 收费（学校没授权的话很贵）
* 界面老旧
* 没有 Zotero 灵活

### Notion

**推荐指数：** ★★★★

全能型工具，可以搭建文献管理系统。

**搭建方法：**

1. 创建数据库，添加属性：
   * 标题（Title）
   * 作者（Multi-select）
   * 年份（Date）
   * 期刊（Select）
   * 关键词（Multi-select）
   * 阅读状态（Select：待读/在读/已读）
   * 重要程度（Select：高/中/低）
   * 笔记（Text）
   * PDF（File）

2. 创建视图：
   * 按研究方向分组
   * 按阅读状态筛选
   * 按年份排序
   * 看板视图（待读/在读/已读）

3. 使用模板：
   * 论文笔记模板
   * 文献综述模板

**优点：**

* 高度自定义
* 支持多种视图
* 团队协作方便
* 可以和其他内容关联

**缺点：**

* 没有自动抓取功能
* 需要手动输入信息
* 不支持 PDF 标注

### Obsidian

**推荐指数：** ★★★★

本地优先的双向链接笔记工具，适合深度文献笔记。

**使用方法：**

1. 每篇论文一个笔记文件
2. 用双向链接关联相关论文
3. 用标签分类
4. 形成知识图谱

**示例：**

```markdown
# 论文标题

**作者：** xxx
**年份：** 2024
**期刊：** CVPR

## 核心贡献

- 贡献1
- 贡献2

## 方法

描述方法...

## 实验

实验结果...

## 与其他论文的关系

- 改进了 [[另一篇论文]] 的方法
- 与 [[相关论文]] 使用了类似的技术
- 解决了 [[问题论文]] 提出的问题

## 个人笔记

- 优点：xxx
- 缺点：xxx
- 可以借鉴：xxx
```

**优点：**

* 本地存储，数据安全
* 双向链接，形成知识网络
* 插件丰富
* 免费

**缺点：**

* 学习曲线陡峭
* 没有云同步（可以用 Obsidian Sync 或自己搭）
* 不适合团队协作

### Readwise + Reader

**推荐指数：** ★★★★

Readwise 负责高亮管理，Reader 负责阅读和标注。

**核心功能：**

* 统一管理所有高亮（PDF、网页、电子书）
* 自动同步到 Notion/Obsidian
* 间隔重复（帮你记住重要内容）
* AI 摘要

**优点：**

* 所有高亮集中管理
* 自动同步到笔记工具
* 间隔重复帮你记忆

**缺点：**

* 收费（$8.99/月）
* 国内访问可能需要梯子

## 文献阅读方法

### 三遍阅读法

**第一遍：快速浏览（5-10 分钟）**

* 看标题、摘要、结论
* 看图表
* 判断是否值得深入阅读

**第二遍：仔细阅读（1-2 小时）**

* 理解论文的主要内容
* 标记重点段落
* 做笔记

**第三遍：深度阅读（3-4 小时）**

* 理解每个细节
* 尝试复现
* 批判性思考

### 论文笔记模板

```markdown
## 基本信息

- 标题：
- 作者：
- 年份：
- 期刊/会议：
- 链接：

## 一句话总结

用一句话概括这篇论文做了什么。

## 研究问题

这篇论文要解决什么问题？

## 现有方法的不足

之前的方法有什么问题？

## 本文方法

这篇论文提出了什么方法？

## 实验结果

实验结果如何？在哪些数据集上测试？

## 个人评价

- 优点：
- 缺点：
- 可以借鉴的点：
- 与其他论文的关系：

## 关键引用

记录重要的参考文献。
```

## 文献搜索技巧

### 搜索引擎

* **Google Scholar**：最全，但需要梯子
* **Semantic Scholar**：AI 驱动，推荐准确
* **Connected Papers**：可视化论文关系
* **arXiv**：预印本，最新研究
* **DBLP**：计算机领域论文数据库
* **PubMed**：医学领域
* **IEEE Xplore**：IEEE 论文
* **ACM Digital Library**：ACM 论文

### 搜索关键词

* 用英文搜索，结果更多
* 用专业术语，不要用口语
* 组合关键词，缩小范围
* 用引号精确匹配

### 搜索策略

1. **从综述开始**：找到领域内的综述论文
2. **看参考文献**：从综述的参考文献里找重要论文
3. **看引用**：看哪些论文引用了这篇论文
4. **看作者**：找领域内大佬的其他论文
5. **看会议**：看顶会上的相关论文

## 文献管理最佳实践

### 日常习惯

* **及时保存**：看到好论文立刻保存
* **定期整理**：每周花 30 分钟整理
* **做好笔记**：读完论文立刻做笔记
* **打标签**：及时打标签，方便查找

### 团队协作

* **共享文件夹**：团队共享文献库
* **统一格式**：统一引用格式
* **定期讨论**：讨论最近读的论文
* **分工阅读**：分工读不同方向的论文

### 长期积累

* **建立知识体系**：不只是收藏，要理解
* **形成自己的观点**：对论文有自己的评价
* **写文献综述**：定期总结领域进展
* **保持更新**：关注最新研究

## 相关资源

* [Zotero](https://www.zotero.org/)
* [Mendeley](https://www.mendeley.com/)
* [Obsidian](https://obsidian.md/)
* [Notion](https://www.notion.so/)
* [Readwise](https://readwise.io/)
* [Connected Papers](https://www.connectedpapers.com/)
* [Semantic Scholar](https://www.semanticscholar.org/)

---

---
url: https://ain.hmgf.hxcn.space/resource/academic-development.md
---
# 学业发展指南

大学四年，说长不长，说短不短。有人浑浑噩噩过完，有人从大一就开始规划。这个栏目帮你把学业这条路捋清楚——不管你是想保研、考研还是直接工作，都能找到对应的方向。

## 这个栏目能帮你什么

说白了，就是少走弯路。

大学里信息差太大了。有些同学大一就知道要刷 GPA、打比赛、找实习，有些同学到大三才开始焦虑"我该怎么办"。这个栏目把那些过来人的经验整理出来，让你早点看清路在哪。

## 文章导航

### 大学四年规划

不同阶段该干什么，心里得有数。

| 阶段 | 重点 |
|------|------|
| 大一 | 打基础、适应大学、别挂科 |
| 大二 | 定方向、做项目、搞竞赛 |
| 大三 | 实习/科研、准备升学或就业 |
| 大四 | 秋招/考研/毕设 |

详见 [大学四年规划](./college-planning.md)

### 课程选择

选课是个技术活。哪些课必须学好，哪些课可以水一水，哪些课对未来发展有用——这些问题得提前想清楚。

详见 [课程选择建议](./course-selection.md)

### 保研准备

保研看起来是"免试"，实际上竞争一点不比考研小。成绩、竞赛、科研、论文，样样都得准备。而且时间窗口很短，错过了就真的错过了。

详见 [保研准备](./graduate-recommendation.md)

### 考研准备

考研是场持久战，从大三下开始准备，到大四上考试，中间大概半年到一年的时间。怎么安排复习节奏、怎么选学校、怎么准备复试，都是有讲究的。

详见 [考研准备](./graduate-exam.md)

### 学习资源

计算机专业学习指南，包括入学规划、课程学习、实习就业、网络安全、考研深造等方面的经验和建议。

详见 [计算机专业学习指南](./cs-learning-guide.md)

### 海外课程推荐

国内计算机课程质量参差不齐，而海外顶尖高校的课程往往更加前沿、实用，且大多免费开放。本文推荐几门值得花时间啃完的海外计算机课程，包括 Stanford CS336、CS50 等。

详见 [海外优秀计算机课程推荐](./overseas-cs-courses.md)

### AI 职业发展

想进头部 AI 团队？GEMINI 预训练团队负责人分享了 10 条实战经验，从方向选择、数学基础到开源项目破局，手把手教你如何用作品集敲开前沿实验室的大门。

详见 [如何进入头部 AI 团队：从方向选择到作品集准备](./ai-career-frontier-lab.md)

## 几条过来人的建议

**早点想清楚要什么**

不是说大一就得确定人生目标，但至少得有个大概方向。想读研就早点卷成绩，想工作就早点找实习，想出国就早点准备语言。最怕的是什么都不想，到大三才开始焦虑。

**别只顾着学习**

大学不只是上课考试。参加社团、打比赛、做项目、交朋友，这些经历同样重要。而且很多能力——比如沟通、团队协作、时间管理——是在课堂上学不到的。

**利用好学校资源**

实验室、图书馆、就业指导中心、学长学姐……这些都是免费的资源。很多人毕业了才发现，学校能提供的帮助比想象中多得多。

**保持身体健康**

别笑，这是认真的。熬夜刷题、久坐写代码，身体迟早出问题。坚持运动，规律作息，比多刷几道题重要得多。

## 相关资源

* [飞书文档 - 学习资源](https://my.feishu.cn/wiki/GLopwEZRhi9hiMkwpqEc1IMFnZg)
* [LeetCode](https://leetcode.cn/)
* [中国研究生招生信息网](https://yz.chsi.com.cn/)
* [王道论坛](https://www.cskaoyan.com/)

---

---
url: https://ain.hmgf.hxcn.space/resource/academic-development/college-planning.md
---
# 大学四年规划

大学四年，每个阶段都有不同的任务。提前知道每个阶段该干什么，心里有底，才不会手忙脚乱。

## 大一：打好基础，适应大学

大一是从高中到大学的过渡期。学习方式、生活方式、社交方式都和以前不一样了。这一年最重要的事，就是适应和打基础。

### 学习方面

**必须学好的课：**

* **编程语言**（C/C++、Python）：这是后面所有专业课的基础。C 语言的指针、内存管理要搞明白，Python 的基本语法和常用库要熟练。
* **数据结构与算法**：计算机专业的核心中的核心。链表、树、图、排序、查找，这些不仅要理解原理，还要能手写代码。
* **高等数学、线性代数、概率论**：数学是很多后续课程的基础，也是考研必考的。大一的高数尤其重要，后面学机器学习、图形学都得用。

**学习建议：**

* 别逃课。大一的课看起来简单，但基础打不好，后面会越来越吃力。
* 课后作业自己做，别抄。抄作业看着省事，考试的时候就傻眼了。
* 遇到不懂的及时问，别攒着。大学不像高中，老师不会追着你学。

### 生活方面

* **学会独立生活**：洗衣服、打扫卫生、管理财务，这些事早晚得自己来。
* **调整作息**：大学没人管你几点睡，但熬夜对身体和学习都不好。
* **交朋友**：室友、同学、社团伙伴，大学的人脉以后会很有用。

### 社团和活动

* **技术社团**：ACM 集训队、计算机协会、开源社区，这些能帮你提升技术。
* **学生会/社团**：锻炼组织能力和人际交往能力，但别投入太多时间。
* **志愿服务**：丰富经历，对保研也有加分。

**时间分配建议：**

| 类别 | 占比 |
|------|------|
| 课内学习 | 60% |
| 技术学习（刷题、项目） | 30% |
| 社团活动 | 10% |

## 大二：深入方向，积累经验

大二是分水岭。从这一年开始，不同人之间的差距会越拉越大。有人已经确定方向、开始做项目了，有人还在迷茫"我该学什么"。

### 确定方向

计算机的方向很多，早点确定一个，集中精力深耕，比什么都学一点要强得多。

**常见方向：**

| 方向 | 技术栈 | 就业前景 |
|------|--------|----------|
| 前端开发 | JavaScript、React、Vue | 需求大，入门相对容易 |
| 后端开发 | Java、Go、数据库、分布式 | 岗位多，天花板高 |
| 算法工程师 | Python、机器学习、深度学习 | 门槛高，薪资高 |
| 安全工程师 | 渗透测试、逆向分析 | 人才紧缺 |
| 客户端开发 | Android、iOS、跨平台 | 相对稳定 |

**怎么选方向：**

* 看兴趣：喜欢什么做什么，不然坚持不下去。
* 看能力：数学好可以考虑算法，代码能力强可以考虑后端。
* 看就业：有些方向岗位多，有些方向薪资高，看自己更看重什么。

### 专业课学习

大二的专业课是计算机的核心，必须学好：

* **操作系统**：进程、线程、内存管理、文件系统。建议配合实验一起学。
* **计算机网络**：TCP/IP 协议栈、HTTP、DNS。建议用 Wireshark 抓包实践。
* **数据库**：SQL 语法、索引原理、事务处理。建议自己搭个数据库用用。

### 做项目

光学理论不够，得动手做点东西：

* **课程项目**：认真对待，不要应付了事。
* **个人项目**：自己想做什么就做什么，放在 GitHub 上。
* **开源贡献**：给开源项目提 PR，能学到很多东西。

### 竞赛

值得参加的竞赛：

* **ACM/ICPC**：算法竞赛，含金量最高，对保研和找工作都加分。
* **数学建模**：锻炼建模和论文写作能力，团队协作也很重要。
* **挑战杯/互联网+**：创新创业类竞赛，适合有想法的同学。

**时间分配建议：**

| 类别 | 占比 |
|------|------|
| 课内学习 | 50% |
| 技术学习 | 30% |
| 竞赛/项目 | 20% |

## 大三：冲刺阶段，决定未来

大三是最关键的一年。这一年做的事情，直接决定了你毕业后去哪。

### 三条路的选择

**保研：**

* 要求：GPA 排名靠前（通常前 20-30%）、有竞赛/科研/论文加分
* 时间线：大三下准备夏令营，大四上确定录取
* 优势：不用考研初试，可以提前选导师

**考研：**

* 要求：初试分数过线 + 复试表现
* 时间线：大三下开始复习，大四上考试
* 优势：可以跨学校跨专业，不受本科成绩限制

**直接工作：**

* 要求：技术能力 + 实习经历
* 时间线：大三暑假实习，大四秋招
* 优势：早点赚钱，积累工作经验

### 暑期实习

大三暑假的实习是最重要的实习，直接影响秋招：

* **目标**：大厂（字节、腾讯、阿里、美团、华为等）
* **准备**：刷题（LeetCode 200+）、做项目、准备简历
* **投递时间**：3-4 月份开始投递
* **面试准备**：八股文（操作系统、计算机网络、数据库）+ 算法题 + 项目经历

### 科研经历

如果想保研或者读博，科研经历很重要：

* **找导师**：主动联系本校老师，表达想做科研的意愿
* **读论文**：了解领域现状，找到感兴趣的研究方向
* **做实验**：跟着导师的项目做，积累经验
* **发论文**：有成果的话，争取发一篇论文

**时间分配建议（根据目标调整）：**

| 目标 | 课内学习 | 技术/科研 | 其他 |
|------|----------|-----------|------|
| 保研 | 60% | 30% | 10% |
| 考研 | 20% | 70%（考研复习） | 10% |
| 就业 | 30% | 50%（实习+技术） | 20% |

## 大四：收获季节，尘埃落定

大四上学期是最忙的阶段，秋招、考研、保研同时进行。提前规划好，才不会手忙脚乱。

### 秋招（8-10 月）

如果选择直接工作，秋招是最重要的一次机会：

* **提前批（7-8 月）**：部分公司会提前开始招聘，竞争相对小
* **正式批（9-10 月）**：大部分公司的主要招聘时间
* **补录（11-12 月）**：没招满的公司会补招

**秋招准备清单：**

* 简历（突出项目和实习经历）
* 刷题（LeetCode 300+）
* 八股文（背熟）
* 项目经历（能讲清楚）

### 考研（12 月初试，次年 3-4 月复试）

如果选择考研，大四上学期是冲刺阶段：

* **9-10 月**：真题模拟，查漏补缺
* **11-12 月**：政治冲刺（肖四肖八），专业课复习
* **12 月**：初试
* **次年 3-4 月**：复试

### 毕业设计

毕设别拖到最后：

* **大四上**：确定选题，开题报告
* **大四下**：做实验/写代码，写论文，答辩
* **建议**：选一个和自己方向相关的题目，一举两得

### 春招（3-5 月）

秋招没拿到满意 offer 的同学，春招是最后的机会：

* 机会比秋招少，但竞争也相对小
* 部分公司会有补录
* 不要放弃，坚持投递

## 几个常见问题

**大一就开始焦虑，正常吗？**

正常。看到别人已经在刷题、做项目了，自己还在适应大学生活，肯定会焦虑。但大一最重要的事其实是打好基础，别急着卷。

**要不要转专业？**

如果真的不喜欢计算机，可以考虑。但如果只是觉得难，建议坚持一下。计算机的就业前景确实不错。

**大学四年最重要的事是什么？**

很难说哪一件事最重要。但如果非要选一个，我觉得是"想清楚自己要什么"。有了明确的目标，其他的事自然就知道该怎么做了。

## 相关链接

* [课程选择建议](./course-selection.md)
* [保研准备](./graduate-recommendation.md)
* [考研准备](./graduate-exam.md)

---

---
url: https://ain.hmgf.hxcn.space/resource/academic-development/course-selection.md
---
# 课程选择建议

选课是个技术活。选对了课，学起来轻松，还能为以后打基础；选错了课，浪费时间不说，还可能影响 GPA。这篇文章帮你理清思路，把课选好。

## 必修课：必须学好

必修课没得选，但可以想办法学好。这些课是计算机专业的根基，学不好后面会越来越吃力。

### 数学类

**高等数学/微积分**

这是大学数学的基础，后面学机器学习、图形学、信号处理都得用。

* 重点：极限、导数、积分、级数
* 难点：多元函数、重积分
* 建议：课后题多做几遍，理解概念比背公式重要

**线性代数**

机器学习和图形学的数学基础，矩阵运算、特征值分解这些概念会反复出现。

* 重点：矩阵运算、线性方程组、特征值与特征向量
* 难点：抽象概念多，不容易理解
* 建议：配合 3Blue1Brown 的视频一起学，直观理解

**概率论与数理统计**

数据分析、机器学习的数学基础。

* 重点：概率分布、期望方差、假设检验、回归分析
* 难点：条件概率、贝叶斯公式
* 建议：多做题，理解概念的实际含义

**离散数学**

计算机的数学基础，集合论、图论、逻辑这些概念在算法和数据结构中经常用到。

* 重点：集合、关系、图论、逻辑
* 难点：证明题
* 建议：理解证明思路，不要死记硬背

### 专业基础课

**数据结构与算法**

计算机专业最核心的课，没有之一。不管是找工作还是考研，这门课都是重中之重。

* 重点：链表、栈、队列、树、图、排序、查找
* 难点：递归、动态规划、图算法
* 建议：光看懂不够，得手写代码实现。LeetCode 从简单题开始刷

**计算机组成原理**

了解计算机是怎么工作的，从晶体管到 CPU。

* 重点：数据表示、指令系统、存储系统、总线
* 难点：流水线、Cache、虚拟内存
* 建议：配合实验一起学，理解得更透彻

**操作系统**

管理计算机资源的核心软件，进程、线程、内存管理这些概念是面试必问的。

* 重点：进程管理、内存管理、文件系统、I/O
* 难点：进程同步、死锁、虚拟内存
* 建议：看看 Linux 内核的实现，动手写个简单的操作系统

**计算机网络**

互联网的基础，TCP/IP 协议栈是重点。

* 重点：TCP/UDP、IP、HTTP、DNS、路由
* 难点：TCP 的三次握手和四次挥手、拥塞控制
* 建议：用 Wireshark 抓包看看实际的网络通信

**数据库**

几乎所有软件系统都离不开数据库。

* 重点：SQL 语法、索引、事务、锁
* 难点：查询优化、并发控制
* 建议：自己搭个数据库，做点实际的项目

### 编程语言课

**C/C++**

底层开发、系统编程的首选语言。指针和内存管理是难点，但也是必学的。

* 重点：指针、内存管理、面向对象
* 建议：多写代码，理解内存模型

**Java**

企业级开发的主流语言，岗位多。

* 重点：面向对象、集合框架、多线程、JVM
* 建议：做个小项目，比如图书管理系统

**Python**

人工智能、数据分析的首选语言，语法简单，库多。

* 重点：基本语法、常用库（NumPy、Pandas、PyTorch）
* 建议：用来做数据分析或者机器学习的项目

## 选修课：根据方向选

选修课是拉开差距的地方。选对了选修课，能为以后的发展打下很好的基础。

### 算法/AI 方向

如果想做算法工程师、数据科学家，这些课很有用：

* **机器学习**：线性回归、决策树、SVM、聚类，这些经典算法得理解原理
* **深度学习**：神经网络、CNN、RNN、Transformer，现在 AI 的基础
* **计算机视觉**：图像分类、目标检测、图像分割
* **自然语言处理**：文本处理、语言模型、机器翻译
* **推荐系统**：协同过滤、深度推荐模型

### 系统方向

如果想做后端开发、系统开发，这些课很有用：

* **编译原理**：理解编译器是怎么工作的，对理解语言设计很有帮助
* **分布式系统**：分布式存储、分布式计算、一致性协议
* **并行计算**：多线程、GPU 编程、MapReduce
* **嵌入式系统**：单片机、实时操作系统、硬件接口

### 安全方向

如果对安全感兴趣：

* **网络安全**：渗透测试、漏洞分析、安全防护
* **密码学**：加密算法、数字签名、密钥管理
* **逆向工程**：反编译、调试分析、恶意代码分析

### Web 方向

如果想做前端或后端开发：

* **Web 开发**：HTML/CSS/JavaScript、前后端分离
* **前端框架**：React、Vue、Angular
* **后端架构**：Spring Boot、微服务、消息队列
* **云计算**：Docker、Kubernetes、云服务

### 其他值得选的课

* **软件工程**：团队协作、项目管理、代码规范
* **人工智能导论**：了解 AI 的基本概念和方法
* **大数据技术**：Hadoop、Spark、数据处理

## 选课策略

### 怎么判断一门课值不值得选

**看老师：**

好老师能让枯燥的课变得有趣，也能让你学到更多东西。问问学长学姐，哪些老师讲得好。

**看内容：**

这门课教的东西和你的方向相关吗？如果相关，就值得选；如果不相关，可以考虑其他课。

**看评价：**

看看评教系统上的分数，问问上过这门课的同学。

**看实用性：**

这门课的知识在工作或科研中用得到吗？如果用得到，就值得学。

### 选课渠道

* **学长学姐**：最有价值的信息来源，他们亲身经历过
* **评教系统**：看看其他同学对老师和课程的评价
* **课程大纲**：了解这门课具体教什么
* **网上评价**：知乎、V2EX 上经常有人讨论课程

### 选课注意事项

* **先修课程**：有些课有先修要求，得先学完基础课才能选
* **时间冲突**：别选了两门时间冲突的课
* **难度平衡**：一学期别选太多难课，留点喘息的空间
* **学分要求**：保证毕业所需的学分

## 课程学习方法

### 怎么学好一门课

**上课认真听：**

听起来像废话，但真的很重要。上课认真听 1 小时，比课后自学 3 小时效率高。老师会划重点、讲思路，这些都是课本上没有的。

**做作业：**

作业是巩固知识的最好方式。不要抄作业，自己做。抄作业看着省事，考试的时候就傻眼了。

**做实验：**

很多课都有实验环节，认真做。实验能帮你理解理论知识，也能锻炼动手能力。

**看参考书：**

课本往往讲得不够深入，找几本经典教材看看。比如：

* 数据结构：《算法导论》
* 操作系统：《操作系统导论》（OSTEP）
* 计算机网络：《计算机网络：自顶向下方法》
* 数据库：《数据库系统概念》

**找人讨论：**

和同学讨论能帮你发现自己的盲点。有些概念自己以为懂了，一讨论才发现其实没搞明白。

### 怎么应对考试

**平时：**

* 上课记笔记，重点内容标出来
* 作业认真做，不懂的及时问
* 实验报告好好写，别应付

**考前：**

* 复习 PPT 和笔记，重点内容多看几遍
* 做往年真题，了解题型和难度
* 和同学讨论，互相答疑
* 老师划的重点一定要看

**考试中：**

* 先做会的题，不会的先跳过
* 时间分配合理，别在一道题上卡太久
* 不会的题写相关公式，能拿几分是几分
* 最后检查一遍，看看有没有漏做的题

### 哪些课可以"水"一下

不是所有课都值得投入同样的精力。有些课可以适当减少投入：

* 和自己方向完全无关的选修课
* 老师讲得很烂、学不到东西的课
* 纯理论、不实用的课

**但注意：** 水课不等于不学，至少得保证不挂科。挂科的代价很大，影响保研、找工作、甚至毕业。

## 一些实用建议

### 别只盯着绩点

绩点重要，但不是唯一重要的事。有些课虽然难拿高分，但学到的东西很有价值。有些课虽然容易拿高分，但学不到什么真本事。

平衡一下：必修课尽量拿高分，选修课可以适当选择对自己发展更有帮助的课。

### 动手实践很重要

计算机是实践性很强的专业。光学理论不够，得多写代码、多做项目。

建议：

* 每门课至少做一个小项目
* 把课程项目放在 GitHub 上
* 参加编程竞赛或黑客马拉松

### 善用网络资源

课本讲得不清楚的地方，网上有大量优质资源：

* **B站**：很多老师的讲课视频
* **Coursera/edX**：国外名校的公开课
* **GitHub**：开源项目和代码示例
* **Stack Overflow**：编程问题的解答

## 相关链接

* [大学四年规划](./college-planning.md)
* [保研准备](./graduate-recommendation.md)
* [考研准备](./graduate-exam.md)

---

---
url: >-
  https://ain.hmgf.hxcn.space/resource/academic-development/graduate-recommendation.md
---
# 保研准备

保研，全称"推荐优秀应届本科毕业生免试攻读研究生"，简单说就是不用参加考研初试，直接进入复试。听起来很香，但竞争一点也不小。

## 什么是保研

保研是中国研究生招生的一种方式。符合条件的本科生，可以免去考研初试，直接参加目标院校的复试。复试通过后，就能被录取为研究生。

### 保研率

不同学校的保研率差别很大：

| 学校类型 | 保研率 |
|----------|--------|
| 顶尖 985（清北复交） | 30-50% |
| 普通 985 | 15-30% |
| 211 高校 | 10-20% |
| 普通一本 | 5-10% |
| 双非院校 | 1-5% |

保研率越低，竞争越激烈。如果你在一所普通一本，想保研就得从大一开始准备。

### 保研类型

* **学术型硕士**：偏研究，适合想读博或做科研的同学
* **专业型硕士**：偏实践，适合想直接工作的同学
* **直博**：本科毕业直接读博士，时间短但风险大

## 保研条件

### 硬性条件

这些是必须满足的条件，缺一个都不行：

**成绩（GPA）**

这是最重要的条件。一般来说：

* 985 高校：排名前 20-30%
* 211 高校：排名前 15-25%
* 普通一本：排名前 10-20%

GPA 是硬门槛，排名不够的话，其他条件再好也没用。

**英语成绩**

大部分学校要求通过英语四级，有些学校要求六级。六级分数越高越好，500 分以上比较稳妥。

**无挂科**

挂科基本告别保研。即使补考过了，有些学校也不认。

### 加分项

这些条件能让你在保研中更有竞争力：

**竞赛获奖**

| 竞赛 | 加分程度 |
|------|----------|
| ACM/ICPC 区域赛金牌 | 非常高 |
| ACM/ICPC 区域赛银牌 | 高 |
| 数学建模国赛一等奖 | 高 |
| 数学建模国赛二三等奖 | 中 |
| 挑战杯/互联网+省级以上 | 中 |
| 其他国家级竞赛 | 中低 |

**科研经历**

* 发表论文：SCI/EI/核心期刊，第一作者加分最多
* 参与科研项目：国家级、省级项目
* 发明专利：有实际价值的专利

**实习经历**

大厂实习对保研有一定帮助，但不如竞赛和论文重要。

**开源贡献**

GitHub 上有 star 数较多的项目，或者给知名开源项目贡献过代码。

## 保研时间线

### 大一到大三上：积累阶段

这段时间主要是积累硬实力：

* **保持 GPA**：从大一就开始认真对待每一门课
* **参加竞赛**：ACM、数学建模，越早开始越好
* **做科研**：大二开始联系导师，进实验室
* **过六级**：大一或大二把六级过了

### 大三下（3-6 月）：夏令营

夏令营是保研最重要的渠道，大部分名额都在这时候确定。

**3-4 月：准备材料**

* 个人简历
* 成绩单（前 5 学期）
* 排名证明
* 英语成绩证明
* 获奖证书
* 论文/专利
* 推荐信（2-3 封）
* 个人陈述

**5-6 月：投递和参加**

* 关注各学校官网的夏令营通知
* 按要求投递材料
* 参加夏令营活动（通常 3-5 天）

### 大四上（9-10 月）：预推免和正式推免

**预推免（9 月）：**

夏令营没拿到 offer 的同学，预推免是第二次机会。流程和夏令营类似，但时间更短，竞争也可能更大。

**正式推免（10 月）：**

在研招网上填报志愿，确认录取。这是最后一次机会。

## 夏令营准备

### 材料准备

**个人简历：**

* 一页纸，简洁明了
* 突出 GPA、竞赛、科研、实习
* 用数据说话，比如"GPA 3.8/4.0，排名 5/200"

**个人陈述：**

* 说明自己的学术背景、研究兴趣、未来规划
* 为什么选择这个学校/导师
* 1000-1500 字

**推荐信：**

* 找熟悉自己的老师写
* 最好是教授或副教授
* 内容要具体，不要空话

### 面试准备

夏令营面试通常包括以下几个环节：

**英语自我介绍（2-3 分钟）：**

提前准备好，背熟。内容包括：

* 基本信息（姓名、学校、专业）
* 学术背景（GPA、排名）
* 科研/项目经历
* 研究兴趣
* 为什么选择这个学校/方向

**专业知识面试：**

* 复习专业课基础知识
* 重点复习和目标方向相关的课程
* 准备一些常见问题

**项目/科研经历：**

* 能清楚地介绍自己做过的项目
* 说明自己在项目中的角色和贡献
* 准备好回答"遇到了什么困难，怎么解决的"

**常见面试问题：**

* 自我介绍
* 介绍你的项目/科研经历
* 为什么选择我们学校？
* 你的研究兴趣是什么？
* 读过什么论文？
* 未来规划是什么？
* 有什么问题想问我们？

### 面试技巧

* **自信但不自大**：展示自己的优势，但不要吹牛
* **诚实**：不会的问题就说不会，不要瞎编
* **条理清晰**：回答问题要有逻辑，分点说
* **准备问题**：准备几个问面试官的问题，显示你的兴趣

## 联系导师

### 什么时候联系

* 夏令营前 1-2 个月开始联系
* 越早越好，好导师名额有限
* 如果夏令营没联系上，预推免还可以继续

### 怎么联系

**发邮件：**

这是最常见的方式。邮件要简洁、礼貌、有针对性。

**邮件模板：**

```
主题：XXX大学XXX专业学生申请贵课题组研究生

尊敬的XXX教授：

您好！我是XXX大学XXX专业的大三学生XXX，预计GPA排名前X%。

我对您的研究方向非常感兴趣，特别是您在XXX方面的研究。
我阅读了您近期发表的《XXX》，对其中的XXX方法印象深刻。

我在本科期间：
- 参与了XXX项目，负责XXX
- 发表了XXX论文
- 获得了XXX竞赛XXX奖项

我非常希望能够加入您的课题组攻读研究生，不知您是否还有招生名额？

附件是我的简历和成绩单，期待您的回复。

此致
敬礼

XXX
XXX大学XXX专业
邮箱：xxx@xxx.com
手机：xxx
```

**其他联系方式：**

* 学长学姐推荐
* 学术会议认识
* 导师的研究生帮忙引见

### 选导师的注意事项

* **研究方向**：和自己的兴趣匹配
* **导师风格**：是放养型还是严管型，看自己适合哪种
* **课题组氛围**：问问在读的研究生
* **导师资源**：项目多不多、经费够不够、有没有 industry connection

## 保研 vs 考研

### 保研的优势

* 不用准备考研初试，节省大量时间
* 可以提前选导师，选择余地更大
* 时间成本低，心理压力相对小
* 有些学校只接受保研生（如中科院某些所）

### 保研的劣势

* 需要前三年保持好成绩，不能松懈
* 竞争激烈，尤其是好学校
* 本校保研率高，外校保研难度大
* 一旦没保上，准备考研的时间很紧张

### 考研的优势

* 可以跨学校、跨专业，选择范围广
* 不受本科成绩限制，一次考试定胜负
* 准备时间相对集中，不需要三年持续投入

### 考研的劣势

* 备考压力大，时间成本高
* 竞争激烈，尤其是热门学校和专业
* 只有一次机会（初试），发挥失常就没戏

## 一些实用建议

### 大一就开始准备

保研是三年的积累，不是大三才开始的事。从大一就要：

* 认真对待每一门课，保持 GPA
* 参加竞赛，积累获奖
* 找导师进实验室，积累科研经历

### 信息收集很重要

保研的信息差很大。有些同学早早知道哪些学校有夏令营、哪些导师在招人，有些同学到大三才开始了解。

信息渠道：

* 学校官网
* 保研论坛（保研岛、保研人）
* 学长学姐
* 微信群/QQ 群

### 心态要好

保研的过程可能会很焦虑。夏令营被拒、联系导师没回复，这些都是正常的。保持好心态，坚持下去，总会有结果的。

## 相关资源

* [中国研究生招生信息网](https://yz.chsi.com.cn/)
* [保研岛](https://www.baoyandao.com/)
* [知乎 - 保研经验](https://www.zhihu.com/topic/19562759/hot)

## 相关链接

* [大学四年规划](./college-planning.md)
* [课程选择建议](./course-selection.md)
* [考研准备](./graduate-exam.md)

---

---
url: https://ain.hmgf.hxcn.space/resource/academic-development/graduate-exam.md
---
# 考研准备

考研是场持久战。从大三下开始准备，到大四上考试，中间大概半年到一年的时间。这段时间会很辛苦，但只要坚持下来，结果不会太差。

## 考研概况

### 考研科目

计算机考研一般考四门：

| 科目 | 分值 | 内容 |
|------|------|------|
| 政治 | 100 分 | 马原、毛中特、史纲、思修、时政 |
| 英语 | 100 分 | 完形、阅读、翻译、作文 |
| 数学 | 150 分 | 高数、线代、概率论 |
| 专业课 | 150 分 | 408 或学校自命题 |

**408 vs 自命题：**

* **408**：全国统考，包括数据结构、计算机组成原理、操作系统、计算机网络。难度大，但公平，方便调剂。
* **自命题**：学校自己出题，难度和范围各不相同。有些学校简单，有些学校难。

建议：如果不确定考哪个学校，先按 408 复习，后面可以灵活调整。

### 学硕 vs 专硕

| 类型 | 学硕 | 专硕 |
|------|------|------|
| 培养方向 | 学术研究 | 工程实践 |
| 学制 | 3 年 | 2-3 年 |
| 考试科目 | 通常考数一英一 | 通常考数二英二 |
| 学费 | 较低 | 较高 |
| 读博 | 可以直博 | 需要考博 |

建议：如果想做科研或读博，选学硕；如果想直接工作，选专硕。

## 考研时间线

### 大三上（9-12 月）：信息收集

这段时间主要是了解考研、确定目标：

* **了解考研**：考什么、怎么考、什么时候考
* **确定目标**：想考哪个学校、什么专业
* **开始基础复习**：数学和英语可以开始准备了

### 大三下（3-6 月）：基础阶段

这是打基础的阶段，重点是数学和英语：

**数学：**

* 看教材，把基础知识过一遍
* 看基础课视频（汤家凤或张宇）
* 做课后习题

**英语：**

* 背单词，每天 100-200 个
* 学习长难句分析
* 开始做阅读理解

**专业课：**

* 如果考 408，可以开始看教材
* 如果考自命题，先了解考试大纲

### 大三暑假（7-8 月）：强化阶段

暑假是考研复习的黄金时期，没有课打扰，可以全身心投入：

**数学：**

* 看强化课视频
* 做习题集（660 题、880 题）
* 总结题型和方法

**英语：**

* 继续背单词
* 做真题阅读理解
* 学习翻译和完形技巧

**专业课：**

* 系统学习 408 四门课
* 做王道配套习题
* 整理笔记

**政治：**

* 可以开始看视频课（徐涛或腿姐）
* 了解基本框架

### 大四上（9-12 月）：冲刺阶段

最后三个月，重点是查漏补缺和模拟：

**数学：**

* 做真题（近 15 年）
* 做模拟题（张宇 8 套卷、李林 6 套卷）
* 总结错题

**英语：**

* 继续做真题
* 准备作文模板
* 模拟考试

**专业课：**

* 做真题
* 查漏补缺
* 重点复习薄弱环节

**政治：**

* 做肖秀荣 1000 题
* 背肖四肖八
* 关注时政

### 大四下（次年 2-4 月）：复试

初试结束后，准备复试：

* **2 月**：出成绩
* **3 月**：国家线公布，准备复试
* **4 月**：复试，调剂

## 各科复习策略

### 数学

数学是考研的重头戏，分值高，难度大，必须投入大量时间。

**推荐资料：**

| 阶段 | 资料 |
|------|------|
| 基础 | 教材 + 汤家凤基础课 |
| 强化 | 张宇强化课 / 李永乐线代 |
| 刷题 | 660 题、880 题 |
| 真题 | 近 15 年真题 |
| 模拟 | 张宇 8 套卷、李林 6 套卷 |

**复习建议：**

* 每天 3-4 小时
* 理解概念比背公式重要
* 多做题，但不要盲目刷题
* 总结题型和解题方法
* 错题要反复看

### 英语

英语需要长期积累，不能临时突击。

**单词：**

* 每天背 100-200 个单词
* 用 APP（墨墨背单词、不背单词）
* 从开始准备一直背到考试

**阅读：**

* 真题是最好的练习材料
* 唐迟的阅读技巧课值得看
* 做完真题要精读，分析每个选项

**作文：**

* 准备模板，但不要死背
* 多练几篇，找人批改
* 王江涛的作文书可以参考

**时间分配：** 每天 1-2 小时

### 政治

政治是性价比最高的科目，投入时间少，但分数不低。

**推荐资料：**

| 阶段 | 资料 |
|------|------|
| 基础 | 徐涛强化课 / 腿姐技巧课 |
| 刷题 | 肖秀荣 1000 题 |
| 冲刺 | 肖四肖八 |
| 时政 | 腿姐时政课 |

**复习建议：**

* 9 月开始即可，不用太早
* 选择题是关键，多刷题
* 大题背肖四就够了
* 时政关注一下

**时间分配：** 每天 1 小时左右

### 专业课（408）

408 包括四门课，内容多，难度大，需要早做准备。

**各科重点：**

| 科目 | 重点 | 难度 |
|------|------|------|
| 数据结构 | 算法设计、树、图 | ★★★★ |
| 组成原理 | CPU、存储系统、总线 | ★★★★ |
| 操作系统 | 进程管理、内存管理 | ★★★ |
| 计算机网络 | TCP/IP、HTTP | ★★★ |

**推荐资料：**

* 王道四件套（教材 + 习题）
* 天勤教材
* 历年真题

**复习建议：**

* 每天 2-3 小时
* 先看教材，再做习题
* 重点理解原理，不要死记硬背
* 真题至少做两遍

## 择校建议

### 怎么选学校

**看学校层次：**

* 985：难度大，但就业好
* 211：难度适中，性价比高
* 双非：难度小，但就业一般

**看专业排名：**

* 学科评估结果（A+、A、A-、B+ 等）
* 专业强的学校，就业和科研资源都好

**看地理位置：**

* 一线城市（北上广深）：机会多，但竞争大
* 新一线（杭州、成都、武汉）：发展快，生活成本相对低
* 其他城市：竞争小，但机会也少

**看招生人数：**

* 招得多，机会大
* 招得少，风险高

**看报录比：**

* 报录比 = 报名人数 / 录取人数
* 报录比越高，竞争越激烈

**看复试线：**

* 看近几年的分数线
* 分数线稳定的好预测
* 分数线波动大的风险高

### 计算机强校推荐

**顶级（难度极大）：**

* 清华大学
* 北京大学
* 浙江大学
* 上海交通大学
* 中国科学技术大学

**第一梯队（难度很大）：**

* 北京航空航天大学
* 哈尔滨工业大学
* 南京大学
* 华中科技大学
* 电子科技大学

**第二梯队（难度较大）：**

* 西安交通大学
* 同济大学
* 武汉大学
* 中山大学
* 北京理工大学

**性价比高（难度适中）：**

* 杭州电子科技大学
* 深圳大学
* 南京邮电大学
* 重庆邮电大学
* 西安电子科技大学

### 选学校的建议

**根据自己的实力选：**

* 本科 985：可以冲顶级或第一梯队
* 本科 211：可以冲第一梯队或第二梯队
* 本科双非：建议第二梯队或性价比高的学校

**不要盲目追求名校：**

* 名校竞争大，风险高
* 选一个自己够得着的学校，比落榜强
* 调剂的学校通常比第一志愿差很多

**多手准备：**

* 确定 2-3 个目标学校
* 一个冲刺、一个稳妥、一个保底
* 关注调剂信息，以防万一

## 复试准备

### 复试内容

复试一般包括：

* **笔试**：专业课笔试，有些学校还有英语笔试
* **面试**：综合面试，包括英语口语、专业知识、项目经历
* **机试**：有些学校有机试，考编程能力

### 怎么准备

**专业课笔试：**

* 看目标学校的复试大纲
* 做往年复试真题
* 重点复习初试没考到的内容

**英语口语：**

* 准备自我介绍
* 练习常见问题的回答
* 多说多练，不要怕犯错

**综合面试：**

* 准备项目介绍
* 复习专业基础知识
* 准备常见问题的回答

**机试：**

* 刷题（LeetCode、洛谷）
* 练习常见算法
* 注意代码规范

### 调剂

如果初试成绩不理想，可以考虑调剂：

* 关注调剂信息（研招网、学校官网）
* 尽早联系调剂学校
* 准备调剂学校的复试

## 考研心态

### 坚持很重要

考研是场持久战，很多人中途放弃。坚持到最后，你就赢了一半。

### 别和别人比

每个人的进度不一样，别看到别人比你快就焦虑。按自己的节奏来。

### 保持健康

* 规律作息，不要熬夜
* 坚持运动，保持体力
* 吃好喝好，别亏待自己

### 适当放松

* 周末可以休息半天
* 偶尔看看电影、打打游戏
* 和朋友聊聊天

## 相关资源

**视频课程：**

* 数学：张宇、汤家凤、李永乐
* 英语：唐迟、刘晓艳、王江涛
* 政治：徐涛、腿姐、肖秀荣
* 专业课：王道、天勤

**资料：**

* 数学：复习全书、660 题、真题
* 英语：单词书、真题、作文书
* 政治：肖秀荣全套
* 专业课：王道四件套、历年真题

**信息渠道：**

* [中国研究生招生信息网](https://yz.chsi.com.cn/)
* [考研帮](https://www.kaoyan.com/)
* [王道论坛](https://www.cskaoyan.com/)
* B 站考研视频

## 相关链接

* [大学四年规划](./college-planning.md)
* [课程选择建议](./course-selection.md)
* [保研准备](./graduate-recommendation.md)

---

---
url: https://ain.hmgf.hxcn.space/resource/academic-development/cs-learning-guide.md
---
# 计算机专业学习指南

计算机专业学什么？怎么学？这里整理一些过来人的经验和建议，帮你少走弯路。

## 入学规划

### 软件工程大一新生入学规划

985 毕业学长的经验之谈。大一该学什么、大二该做什么、大三该怎么准备实习、大四该怎么找工作，每个阶段都有具体建议。如果你刚入学不知道怎么规划，这个视频能帮你建立基本框架。

### 计算机专业，警惕 AI！

AI 正在改变计算机行业，有些岗位可能会被取代。这个视频分析了 AI 对计算机专业的影响，哪些方向更有前景，哪些需要警惕。如果你在选方向，这个视频值得看看。

## 课程学习

### 计算机专业后悔录，最无用与最有用课程排行榜

哪些课程真的有用，哪些课程浪费时间？这个视频根据实际工作经验，对计算机专业的课程做了排名。如果你在纠结选什么课，这个排名能帮你做决定。

### 讲一些计算机学生必备的基础知识

计算机专业有些基础知识是必须掌握的，不管以后做什么方向。这个视频列出了必备的基础知识清单，帮你查漏补缺。

## 实习就业

### 大三的我是如何拿下三段大厂实习？

计算机专业最危险的信息差，被学校骗了四年？错过这些毕业即失业？这个视频分享了大厂实习的准备经验，包括简历、面试、项目经验等。

### 给年轻大学生的一些校园和择业建议

校园生活怎么过，毕业该怎么选择？这个视频给出了一些实用的建议，包括社团、竞赛、实习、考研等。如果你在纠结毕业后的选择，这个视频能帮你理清思路。

## 网络安全

### 网安人的天堂！12 个自学网络安全的网站

网络安全是计算机的一个重要方向。这个视频推荐了 12 个自学网络安全的网站，覆盖入门到进阶。如果你想了解网络安全，从这些网站开始不会错。

## 考研深造

### 一个视频讲透考研的一切

时间线、信息源、初试、复试、政治、外语、数学、专业课、择校、择专业，考研的所有环节这个视频都讲到了。如果你在考虑考研，这个视频能帮你建立完整的考研认知。

### 什么是水刊、顶刊顶会？

期刊级别划分及机构售价，sci、ccf、ssci、ei、国内核心……这些概念经常混着用。这个视频把期刊和会议的级别划分讲清楚了，帮你理解学术发表的基本规则。

### 读研后才知道的 15 件事

读研和本科完全不同。这个视频分享了读研后才知道的 15 件事，包括导师选择、论文写作、科研方法等。如果你在考虑读研，这个视频能帮你提前了解研究生生活。

## 文献管理

### Notion 文献管理系统

科研党必备的文献管理方法。这个视频演示了如何用 Notion 建立文献管理系统，导师看了都夸专业。如果你需要管理大量文献，这个方法值得学习。

## 补充资源

### 计算机学习资源

一些实用的计算机学习资源链接：

* [飞书文档 1](https://my.feishu.cn/wiki/Cm15wvl8JiC8pUknsfVc6TQNnDc)
* [飞书文档 2](https://my.feishu.cn/wiki/KNh5wPCxGi1qpYkK4nGcojabnDb)
* [飞书文档 3](https://my.feishu.cn/wiki/VVv1w0kCzirT04kmHwKc5PDWnBg)
* [飞书文档 4](https://my.feishu.cn/wiki/GLopwEZRhi9hiMkwpqEc1IMFnZg)
* [网安学习资源](https://wyuanlin.top)
* [金山文档](https://www.kdocs.cn/l/cagbu0iHI8eA)

---

---
url: >-
  https://ain.hmgf.hxcn.space/resource/academic-development/overseas-cs-courses.md
---
# 海外优秀计算机课程推荐

国内计算机课程质量参差不齐，有些课程还在用5年前的PPT。而海外顶尖高校的课程往往更加前沿、实用，且大多免费开放。本文推荐几门值得花时间啃完的海外计算机课程。

## Stanford CS336: Language Modeling from Scratch

### 课程简介

Stanford CS336 是斯坦福大学计算机科学系的一门课程，目标是**从零开始手搓一个完整的 LLM（大语言模型）**。这门课每年春季更新，在 YouTube 免费开放。

**课程目标：** 让你掌握 LLM 全栈技术栈，从数据收集、清洗、模型训练、优化、评估到部署，Transformer 架构、注意力机制、各种最新的机器学习训练方法，一节不落。

### 为什么推荐这门课

1. **内容前沿实用**：2025 年最新版本提到的模型已经是 GPT-4，而国内很多课程还在用 5 年前的 PPT。
2. **实践性强**：课程目标就是让你亲手实现完整的 pipeline，而不是纸上谈兵。
3. **讲师阵容强大**：
   * **Percy Liang**：MIT 本科 + MEng，UC Berkeley 博士，曾在 Google 做 post-doc，后加入 Stanford 任教。
   * **Tatsu**：Harvard 本科（统计与数学），MIT 博士，之后在 Stanford 做 Percy Liang 和 John Duchi 的 post-doc。

### 学习建议

1. **先打基础**：如果是大一新生，建议先刷 CS50 打底，再冲 CS336。
2. **线性代数必须学透**：线性代数是机器学习的底层 DNA。没学好它，理解神经网络就像没学会加减乘除就想去求导。
3. **不开中文字幕**：建议只开英文字幕，硬啃完它。你对 LLM 的理解 + 英语能力，直接冲到国内前 1% 的计算机同学。
4. **边学边查**：过程中必然会遇到很多不懂的点，边学边查，然后顺带就把学校关于机器学习和深度学习的专业课给学完了。

### 课程链接

* YouTube 搜索 "Stanford CS336 2025"
* 课程官网：https://stanford-cs336.github.io/

## 其他推荐课程

### CS50: Introduction to Computer Science

哈佛大学的经典入门课程，适合大一新生打基础。内容涵盖编程基础、数据结构、算法、Web 开发等。

### MIT 6.S081: Introduction to Operating Systems

MIT 的操作系统课程，以 xv6 教学操作系统为载体，深入讲解进程、线程、内存管理、文件系统等核心概念。

### CMU 15-213: Introduction to Computer Systems

CMU 的计算机系统课程，深入讲解程序如何在计算机上运行，包括数据表示、程序优化、存储器层次结构等。

## 学习资源

### Transformer 相关资源

1. **自注意力 & Transformer**：理解 Transformer 的核心机制
2. **插图版 GPT-2**：直观理解 GPT-2 的架构
3. **反向传播**：深度学习的基础算法
4. **语言模型策略梯度入门**：理解 RLHF 的基础
5. **理解 GRPO 和强化学习原理的轻量级指南**：最新的训练方法
6. **如何扩展你的模型**：模型规模化的技术

### 刷题资源

* **LeetCode**：算法刷题必备
* **NeetCode**：LeetCode 题目分类和讲解

## 总结

海外优秀计算机课程的价值在于：

1. **前沿性**：课程内容紧跟技术发展，不会出现用 5 年前 PPT 的情况。
2. **实践性**：注重动手实践，而不是纸上谈兵。
3. **系统性**：课程设计系统完整，从基础到进阶。
4. **免费开放**：大多课程在 YouTube 等平台免费开放。

耐心啃完这些课程，你会发现：学校那些机器学习课，你边学边查，顺便就全修完了。

## 参考来源

* [一只小橘呀 (@Ellieorange8) 的推文](https://x.com/Ellieorange8/status/2070452761884537046)
* [Line (@0xLinehigher) 的推文](https://x.com/0xLinehigher/status/2069885696668799188)
* [李韭二 (@li9292) 的推文](https://x.com/li9292/status/2069198959550349459)

---

---
url: >-
  https://ain.hmgf.hxcn.space/resource/academic-development/ai-career-frontier-lab.md
---
# 如何进入头部 AI 团队：从方向选择到作品集准备

## 经验总结

GEMINI 预训练团队负责人在五月份写了一篇《如何进入头部 AI 团队/实验室》，非常值得一读，总结 10 条经验：

前沿实验室的招聘卷得厉害，能进去的大多出自顶尖本科或博士项目，身上普遍有三样东西：方向打得准、数学功底硬、拼劲十足。对大多数普通人来说，硬挤正面没胜算，更务实的打法是绕到 LLM 栈的两头——要么沉下去做底层（kernel 优化、推理加速、量化），要么浮上来做上层（agent 系统、用 LLM 搞算法实验），靠开源项目和实打实的成果说话，比什么都有说服力。

### 1. 找准方向，切忌空谈

别张嘴就是"我对 AI 感兴趣"。得盯准实验室真正缺人的地方：底层就死磕 FlashAttention、量化推理、kernel 编程；上层就做 agent 循环、LLM 辅助的实验设计。这些方向门槛不高，自学能上手，实验室又天天用得着。

### 2. 数学底子绕不过去

这里没有捷径，只能靠大量证明题和理论课程硬磨。优化理论、scaling laws、模型演化逻辑，得吃到骨子里去。数学成熟度是分水岭，过了就是研究者，没过就是操作工。

### 3. 拼劲得够，别怕苦

大学那几年，周末泡图书馆是常态，社交能砍就砍。作者当年和朋友靠浓咖啡硬扛一整天，就这么熬过来的。想和那拨尖子生掰手腕，没有这点强度打底，基本没戏。

### 4. 用开源项目破局，别指望简历

把代码挂到 GitHub 上，做复现、提改进、跑 benchmark。能力这东西，摆出来给人看，比写在纸上管用得多。

### 5. 从边角料干起，别一上来就冲大模型

先搞定 kernel 编程（CuTe、LLM.int8() 量化这些）、推理优化、agent 工具链。这些活实验室最缺人，也最容易自己闷头学出来。

### 6. 论文 + 动手复现，两手都要硬

精读 FlashAttention、SnapKV 这些经典，把 LLM 的脉络理清楚。建议从 Reiner Pope 的访谈和 Gemini Flash 的预训练讲座入手，再慢慢啃 scaling laws。

### 7. AI 工具用来提速，别用来代替学习

AI 能让你已经会的东西干得更快，但绝不能拿它来学新东西或跳过思考。一依赖就废，数学和拼劲都养不出来了。

### 8. 每隔半年复盘一次方向

别嫌活脏、别嫌活基础——只要那条路通到金矿，就值得挖。关键是想清楚自己在往哪走。

### 9. 拿具体练习证明自己

* 用 JAX/Flax 从零写一个 1000 万参数左右的 Transformer，在 Colab TPU 上跑通加法任务；
* 手推 Chinchilla scaling laws，对比稠密模型和 MoE；
* 写一个 Pallas kernel 做算子融合，实测前向加速并说清原因。

### 10. 最终就一条路：本事 + 作品 + 死磕，缺一不可

名校背景当然管用，但对出身一般的选手，最靠谱的就是在 kernel 或 agent 领域做出能拿出来秀的东西，然后做好打 5–10 年持久战的准备。

***

## 原文：如何准备头部 Agent / Harness 团队：从作品集到实验能力

> 原文来源：[AgentWay](https://agentway.dev/zh/insights/agent-harness-portfolio)

想进入头部 Agent / Harness 团队，作品集要证明你能读懂一次 Agent 运行：它为什么这样做，哪种设计能让结果更稳定。高阶 Agent 工作的差距，越来越多在这里拉开。

### 行业信号

Vlad Feinberg 在 frontier lab 求职建议里，把机会分成两层：LLM stack 下层的 kernel work，以及 LLM 抽象之上的 agentic loops。后者的关键，是围绕 LLM agent 做严谨、可控的工程实验。

DeepSeek Harness 的招聘给了另一侧证据。Tianyi Cui 给出的公式是 `Model + Harness = Agent`。模型给出能力上限，Harness 负责把能力接到上下文、工具、任务、评测、用户反馈和训练信号里。

两条线合在一起，结论很实际：头部 Agent / Harness 团队需要的作品，要能把一次 Agent 运行拆成可观察、可比较、可复现的实验。

### Demo 说服力有限

普通 Agent demo 通常有三个短板：

1. 任务太少，只证明某次演示成功。
2. 没有 baseline，无法知道改动是否真的带来提升。
3. 没有 trace，失败后只能猜模型、prompt、工具、上下文哪一层出了问题。

一个小而严谨的实验，更有说服力。比如同一组任务，分别用基础 prompt、工具白名单、typed error、reviewer subagent、不同 compaction 策略跑一遍。最后给出成功率、成本、延迟、失败类型和几条关键 trace。项目可以朴素，关键是能说明你理解 Harness 变量。

### 作品集应该像实验报告

一个适合 Agent / Harness 岗位的项目，至少要能回答六个问题：

| 问题 | 作品集里的材料 |
|------|---------------|
| Agent 要做什么 | task set / scenario definition |
| 起点表现怎样 | baseline result |
| 你改了什么 | intervention |
| 怎么判断好坏 | eval metrics / graders |
| 失败发生在哪里 | trace / diagnostics |
| 结论能否复现 | scripts / fixtures / README |

这和 Anthropic 对 Agent eval 的看法一致：Agent 评测通常要看 transcript 和 outcome，并组合 code-based、model-based、human graders。只看最终回答，会漏掉工具选择、重试、状态污染、绕过规则这些过程问题。

### 选题要窄

好的作品集不需要"大而全"。最适合的方向，是在一个真实 Agent runtime 上选一个变量做深。

**Context 实验**

比较 full transcript、rolling summary、retrieved memory、branch summary 对长任务成功率的影响。

**Tool 实验**

比较粗粒度工具和细粒度工具、free-form error 和 typed error、长 observation 和压缩 observation。Anthropic 的 tool 文章说得很清楚：工具返回结构本身会影响 eval 表现。

**Trace / Eval 实验**

给一组任务建立 trace schema：message、tool\_call、tool\_result、state\_change、diagnostic、final\_outcome。然后用 code grader、LLM judge、人工检查组合评分。

**Multi-Agent 实验**

比较 single agent、planner-executor、planner-executor-reviewer、parallel subagents。重点是解释 multi-agent 何时提升成功率，何时增加成本和协调失败。

**Production / Safety 实验**

研究权限、hook、human checkpoint、rollback、cost cap 怎样影响输出质量、成本和越权风险。

### 一个具体项目模板

项目可以很小：

`agentic-debug-harness`

**问题：** 代码 Agent 修复 failing tests 时，什么时候会过度修改无关文件？

**任务集：** 20 个小型 bugfix tasks。每个任务包含初始 repo、失败测试、预期行为、允许修改范围。

**Baseline：**

* naive prompt
* prompt + file whitelist
* prompt + permission hook
* prompt + reviewer subagent
* prompt + trace replay

**指标：**

* test pass rate
* unrelated file edits
* token / cost
* wall-clock latency
* human intervention count
* failure taxonomy

**交付：**

* `tasks.jsonl`
* `run-eval.ts`
* `traces/*.jsonl`
* `results.csv`
* 5 个失败 case 的短分析
* README 说明怎么复现

这个项目有价值，因为它把 Harness 设计和结果差异连起来了。

### 作品集里最稀缺的是归因能力

头部团队会关心你能不能区分这些失败来源：

* 模型没有理解任务。
* 工具 schema 让模型误用。
* observation 太长或太散。
* context 里丢了关键状态。
* memory 写入了错误事实。
* subagent handoff 损失了约束。
* permission policy 过松或过紧。
* eval 只测到了表面成功。

这类判断力很难靠简历写出来。最好的证明方式，是把失败 trace 摆出来，再给出一个小改动和对比结果。

### 90 天准备路线

**第 1-2 周：复现**

复现一个现有 Agent 任务：coding task、tool-use task、research task 都可以。先把 task、runner、trace、结果表跑通。

**第 3-5 周：只改一个变量**

选择 context、tool schema、hook、memory、subagent 中的一个变量。把 prompt、模型和工具一起改，会让实验失去解释力。

**第 6-8 周：补 trace 和 eval**

把每次运行记录成 episode。至少包含 tool call、tool result、stop reason、final outcome。建立成功率、成本、失败类型三类指标。

**第 9-12 周：写报告**

报告按实验报告写：问题、baseline、intervention、task set、metrics、trace examples、conclusion。

### 结论

会用 Agent 只是起点。想进入 Agent / Harness 团队，还要能把一次运行拆开看：变量怎么控，过程怎么记，结果怎么比，失败怎么归因。

一个严谨的小实验，比十个漂亮 demo 更像入场券。

### 参考资料

* [Vlad Feinberg —— How to Land a Frontier Lab Job](https://vladfeinberg.com/2026/05/10/how-to-land-a-job-at-a-frontier-lab.html)
* [Tianyi Cui —— DeepSeek Harness 招聘信息](https://x.com/tianyi/status/2068652453797724562?s=20)
* [Anthropic —— Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
* [Anthropic —— Writing effective tools for AI agents](https://www.anthropic.com/engineering/writing-tools-for-agents)
* [Anthropic —— Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

---

---
url: https://ain.hmgf.hxcn.space/research/review/sci-writing-guide.md
---
# 2 周干完 SCI 写作教程与模板

> 带你打通从读文献到写论文的鸿沟！

**2025 年**

***

SCI 论文各部分写作套路及写作模板（可直接套用）

## 1、如何起论文题目？

### 一、基本原则与核心要求

1. 完全不需要惊艳，越干越好，一针见血。

2. 言简意赅，最短的题目展示出论文最多的信息。

3. 务必展示本文核心创新点和主要内容。

### 二、一区 top 期刊写作套路

（一）机制类

1. Failure mechanisms of saturated sand under different loading frequencies: Experimental observation and constitutive modelling

2. Scour mechanism around a pipeline under different current-wave conditions using the CFD-DEM coupling model

3. Analysis of the effect of breakable particle corners on uplift pile–soil interaction behaviors in calcareous sand

（二）实验类

1. Experimental investigation of fracture permeability reduction process by MICP technology with Sporosarcina pasteurii cultured by different mediums

2. Cyclic axial response and stability of snakeskin-inspired piles in sand

3. Experimental study and design formula of the uplift performance of screw anchor foundations in silty clays

（三）新方法/技术/模型类

1. Integrating machine learning techniques for predicting ground vibration in pile driving activities

2. A constitutive model for cemented granular materials capturing bond degradation

3. A new hyper-elastic law for single yield surface constitutive models for clays

（四）综述类

1. Advances in reliability and risk analyses of slopes in spatially variable soils: A state-of-the-art review 研究内容：reliability and risk analyses  可靠度与风险分析研究对象：slopes 边坡研究条件：  in spatially variable soils 在空间变异土体中

2. Review of fundamental principles in modelling unsaturated soil behaviour 研究内容：fundamental principles  基本原则应用场景：在非饱和同土模拟中

3. A review of pile-soil interactions in isolated, thermally-activated piles 研究内容：pile-soil interactions  桩土相互作用应用场景：isolated, thermally-activated piles  在独立的热激活桩中

### 三、写作套路及操作步骤

1. 确定核心创新点：是实验？理论、技术、方法？机制发现？

2. 根据核心创新点确定题目范式，比如既有试验、又有新方法，如何突出

3. 把研究对象、核心创新点、论文工作等关键词列出来，之后再通过增删调序等组合成题目。

### 四、奉上可以直接用的模板

（一）机制类 XX mechanisms of    XX（研究对象）under XX condition（试验条件）using XX model（研究方法/技术/模型等）

（二）实验类 Experiment study of XX（研究对象）under XX condition（试验条件） consider XX effects  （因素）

（三）新方法/技术/模型类 A  novel  XX  model/technique/method  to  evaluate/predict/capture  the responses of X（实现的功能）

（四）综述类 A review of XX（研究对象）in XX  （应用场景） A critical review on XX（研究对象） Current trends and future research agend of Development of XX

## 2、如何写 Abstract？

### 一、基本原则与核心要求

1. Abstract 写作套路非常固定，不需要任何创新。

2. Abstract 是全文内容高度归纳概况，放在最后完成最省事（因为你可以直接用文中内容）。

3. 务必展示本文核心创新点和主要内容。

### 二、一区 top 期刊写作套路

1. 凝练型

2. 详细型

3. 中间型（合适）

### 三、写作套路、操作步骤

1. 针对研究背景、（研究对象）、研究工具、研究内容、研究结论、研究意义， 分别用一句话概况，对于创新点所在部分，用 1-2 句话展开描述创新点。

2. 将以上各要素对应的一句话，直接组装形成摘要。

3. 从头到尾阅读摘要，根据前后逻辑关系调整语句顺序，语句之间增加连接词，如 In this study, But, Thus, Therefore, The results indicate that,    It is noted that, Firstly, Then, After that…

4. 润色调整。

### 四、奉上可以直接用的模板

建议 200 词左右。

第 1 句：介绍工程背景（直接聚焦较具体的研究背景），点明研究对象。如： The Cone Penetrometer Test (CPT) is one of the preferred tools to carry out sub-soil investigations. / Monopile foundations are generally used for the offshore wind turbines with water depth less than 30m.

第 2-3 句：由工程背景引入工程问题，进而引出本文研究内容，强调研究内容对解决该工程问题的重要意义。如： During  the  service  period,  monopile  foundation  are  mainly  subjected  to  cyclic lateral loadings. Thus, the cyclic loading behavior is the key problem in the engineering design of monopile. Piles subjected to cyclic axial loading can experience loss of serviceability, which is a common failure mode for offshore foundations.

第 4-5 句：介绍本文核心工作，可按照研究先后顺序依次介绍。如：In  this paper,  XX  experiment  was  performed  to  study  XX  problem,  and  XX  model  was proposed  to  predict  the  responses  the  XX.  Using  this  model,  a  series  of  numerical simulations were conducted aiming for XX.

第 6-7 句：介绍本文工作的主要结论。如：The  results  indicate  that  XX.  It  is noted  that  the  XX.  With  the  increase  of  load  amplitude,  XX  increases  downward significantly. The findings clarify the strengths and weaknesses of these soil models and their accuracy, which allow a better understanding of their capabilities and limitations.

第 8 句：强调本研究的贡献及意义。如：The proposed XX model is appropriate for the assessment of XX evolution process.  （新工具方法） The results provide evidence of the effect that bioinspired surface textures can have on  the  stability  of  piles  and  show  the  tradeoffs  that  emerge  due  to  the  direction- dependent shaft resistance mobilization.（试验新发现）

Keywords:  一般五个。

## 3、如何写 Introduction？

### 一、基本原则与核心要求

1. Introduction 是扩大版 Abstract。

2. Introduction 部分是整篇 SCI 中最难写的一部分，没有之一，心理上要有所准备。

3. Introduction 要实现的目的：1）从研究背景中引出问题并凸显严重性；2） 聚焦问题，点明现有研究不足；3）相比现有研究，突出本文创新性；4）展示本文主要内容和结论。

### 二、一区 top 期刊写作套路

（一）机制类

（二）试验类

### 三、写作套路、操作步骤

写作套路:  三段式（广义），内容分三个部分，每部分不限于一段。各部分具体内容如下：

第一部分：介绍工程背景。工程大背景，该工程问题的重要性及解决问题的紧迫性。讲问题从大到小，从工程大背景逐渐聚焦在该工程问题的核心控制因素上（即是本文研究内容）。可以结合图片介绍基本概念。

第二部分：介绍关于本问题别人的研究现状，在肯定别人研究进展与意义的同时，更要突出目前研究的不足（该不足是与本文研究创新点相比的不足，以求突出本文研究内容的创新性）。千万不要按时间记流水账，虽然写起来容易，但是会给审稿专家留下不好印象，认为对该问题缺乏深入认识。一定要以问题为导向进行分类，比如按照研究的方式分类（试验，数值模拟，理论分析）、按照研究问题的几个维度分类（问题 1，问题 2，问题 3）。

第三部分：介绍本文目标、开展的工作和主要结论（比 abstract 要详细，可以存在一定程度重复）。

### 四、直接可以用的模版

第一段：写作逻辑为介绍工程大背景→小背景→具体工程问题及其重要意义

（本文创新点）。写法如下： 转折关键词和可用例句已标注。

第二段：按照问题分类依次介绍别人的研究现状，点明研究不足。 其他可套用句式：There have been many studies so far about the XX problem. XX \[1], XX et al. \[2] and XX\[15] proposed and developed XX method. The method provides a good evaluation tool for XX, but it is too simplified to consider the effects of XX, XX and XX. 至少应该有 80%的引用文献是在近五年发表的。 若是多个问题，可将“第二段”拆写成多段，每段讨论一个问题。

第三段：介绍本文目标、工作和主要结论（比 abstract 要详细，可以存在一定程度重复）。 其他可套用句式：This  paper  aims  to  solve  XX  problem.  In  this  paper,  XX experiments were performed firstly, and it is found that XX. Then, XX numerical model was  established,  which  can  consider  the  effects  of  XX.  Later,  a  series  of  numerical studies based on XX are performed to investigate XX. It is pointed out that the XX.

## 4、如何写试验介绍（数值模型介绍）？

### 一、基本原则与核心要求

1. 写作难度属于整篇论文中最小，建议最先写本部分。

2. 不需要搞创新，直接套用模版、看图说话。

### 二、一区 top 期刊写作套路

（一）简单型（试验不作为重点内容或仅作为部分内容）

（二）详细型（论文围绕试验展开）

### 三、写作套路、操作步骤

1. 介绍试验的基本情况，包括试验材料、试验仪器、试验场景布置等信息。 试验材料等参数可用表格展示，场景布置可用示意图或现场照片展示。

2. 介绍试验设计和试验操作步骤。包括试验目的，研究方法。给出开展试验的组数、研究变量，可用表格展示。

### 四、直接可以用的模版

Description of experiment

1. Experiment materials Three type materials are adopted in this paper, i.e. Fujian sand, Nanjing sand and calcareous sand. The particle size distri-bution curves of the three type particles used in the test are shown in Fig. 1. Parameter 1 is X, Parameter 2 is X… More detail properties of the three kinds of particles in the tests are shown in Table. 1.

2. Experiment apparatus A  direct  shear  device  with  the  dimension  of  100  ×  100  ×  33  mm  was  used  to conduct direct shear tests, see Fig. 2. The direct shear box was modified to evaluate the interface friction angles between sand and different surfaces. Accordingly, the lower half of the shear box was filled with a granite stone.

3. Experiment design and procedures Table.1 shows the summary of all the tests, there contains a total of 10 tests. The tests No.1–6 are aiming to investigate the effects of XX on the behavior of XX. The tests No.7–10 are performed as a contrast with X condition. The experimental procedure is outlined in Fig.3. The soil was compacted layer by layer  to  achieve  the  desired  density.  Each  layer  had  a  depth  of  100  mm  and  was compacted using a rigid plate. After compacting the soil to a depth of 30 cm, the model pile was placed in the center of the tank. Then, the loading system is employed to create the necessary pulling force to the pile. 注意：对于数值模拟类论文，数值模型部分的介绍与上述试验介绍大同小异， 可直接参考上文。主要区别在于：

4. 数值模拟最为重要，也是审稿人最为关注的问题就是模型参数的标定过程， 参数有哪些？是如何确定的？具不具有信服力？参数是模型的基础，务必重视， 并讲清楚。

5. 另一个非常重要的部分就是数值模型验证，只有证明数值模型是正确的， 后续的数值研究才有意义。一般可通过试验、现场监测数据、理论计算值、甚至他人的数值模拟结果进行验证。

## 5、如何写研究结果分析？

### 一、基本原则与核心要求

1. 先根据试验数据画图，再“看图说话”，用套路句式把图中内容描述清楚。

2. 不仅仅要描述现象（会被批像试验报告），要尽量往物理机制、内在机理、 计算方法上靠。只要展示了这些内容，那你就是有创新！重要的不是你分析得对不对、有没有用，而是有这部分内容！

3. 对于试验类论文：讨论试验结果，总结试验规律，解释试验现象背后机制、 机理。可与已有试验结果对比分析，讨论差异以及原因。甚至可以凝练出指导工程实践的公式，提升论文创新性。

4. 对于数值模拟类论文：计算结果一般都非常多，可筛选几个具有代表性的物理量进行深入分析，分析不同因素影响下这些物理量的变化规律及内在物理机制；分析研究对象破坏过程及原因；基于大量的数值计算结果，构建可用于工程设计分析的数据库，为构建评估方法奠定基础。更重要的是，通过数值计算研究， 得出对工程实践具有指导意义的结论或评价方法。

### 二、一区 top 期刊写作套路

（一）试验类论文

（二）数值模拟类论文

1. 数值模型验证

2. 数值模拟结果

### 三、写作套路、操作步骤

1. 说明图片主要内容

2. 描述图片内容演化趋势

3. 阐述现象背后的原因，尽量从物理机制层面进行解释

4. 如果现象或机理解释不够足够有理有据，可以用他人文献支撑。

5. 适当表明研究内容的作用及意义

### 四、直接可以用的模版

第一句，介绍主要内容：Fig.  1  shows  the  results  of  X,  which  highlight  the displacement required to the peak capacity for each pile type.

第二句，介绍图片具体内容：It is found that the X develops obviously and tend to be stable with the increase of X. / The thickness of A is evidently larger than that of B under same condition, which is mainly because the X. These differences reflect the interactions between X and X. This phenomenon is supported by the work of XX \[1].

第三句，阐述物理机制：The results suggesting that saturated Fujian sand is more susceptible to liquefaction as Dr decreases. This susceptibility can be attributed to two primary factors. First, the proportion of void or pore water in the sand with lower Dr is higher,  leading  to  increased  migration  and  retention  of  water  and  facilitating  the accumulation of excess pore water pressure. Second, the looser structure of low-density sand reduces particle-to-particle friction, enhancing particle mobility.

第四句，表明研究贡献及意义：This discovery enhances our comprehension of soil liquefaction mechanisms and provides crucial reference for assessing liquefaction risk under specific loading conditions.

## 6、如何写 Conclusion？

### 一、基本原则与核心要求

1. 写结论遵守宁缺毋滥的原则，仅需凝练论文的最核心创新点，避免没有意义的结论，千万不要出现大路边上的废话结论。

2. 针对特定工况下的结论，尽量少提或不提，因为这些结论没有工程普适应， 容易被审稿人攻击。

### 二、一区 top 期刊写作套路

（一）数值模型类

（二）试验类

### 三、写作套路、操作步骤

采用总分模式，即先写一段“帽子”，再列 3-5 个核心结论。“帽子”还是总结本文主要工作，可借鉴、甚至复制 abstract 和 introduction 中相关表述。核心结论分条展示。

### 四、直接可以用的模版

1. “帽子”总结全文工作：In this study, a series of XX tests at different loading frequencies were conducted on XX. In light of experimental observations, a plasticity model  for  saturated  sands  was  extended  from  the  multiple  yield  surface  model. Systematic  comparisons  between  model  simulations  and  experimental  results demonstrate  the  ability  of  the  extended  model  to  simulate  the  cyclic  liquefaction characteristics of saturated sands. The main conclusions are summarised as follows:

2. 逐条列出“干货”结论：

3. The  failure  mode  of  X  is  revealed  though  X  experiment/simulation.  The mechanism can be explained as follows: XX.

4. A  novel  X  model  for  X  has  been  developed  from  the  traditional  X  model  to account for the  effect  of  loading  frequency  on  the  liquefaction  response. The  model employed a new X rule and considered the effect of loading frequency.

5. The simulation capability of the novel model was verified though XX test data. Comparisons  between  the  model  response  and  experimental  results  indicated  its excellent performance for predicting XX responses under different loading frequency conditions.

---

---
url: https://ain.hmgf.hxcn.space/public.md
description: 3D环梦工坊编程竞赛组官方知识库，提供C++/Python编程入门教程、算法与数据结构讲义、竞赛指导等学习资源。
---

# 3D环梦工坊编程竞赛组

该网站是 3D 环梦工坊编程竞赛组（C++/Python 算法课程与竞赛训练）的官方知识库，内容以中文撰写，主要面向编程初学者与竞赛选手。

## 主要内容

* [讲义与幻灯片](https://ain.hmgf.hxcn.space/lectures/)：C++ 基础、STL、算法与 Python 课程讲义
* [AI 教程](https://ain.hmgf.hxcn.space/ai/)
* [开发教程](https://ain.hmgf.hxcn.space/dev/) · [SRE 运维](https://ain.hmgf.hxcn.space/sre/)
* [写作方法](https://ain.hmgf.hxcn.space/writing/) · [求职经验](https://ain.hmgf.hxcn.space/career/)
* [竞赛信息](https://ain.hmgf.hxcn.space/competition/) · [科研](https://ain.hmgf.hxcn.space/research/) · [活动](https://ain.hmgf.hxcn.space/event/)

## 机器读者说明

* 全站文档清单见 [llms.txt](https://ain.hmgf.hxcn.space/llms.txt)；一次性全量内容见 [llms-full.txt](https://ain.hmgf.hxcn.space/llms-full.txt)。
* 任意文档页面 URL 末尾追加 `.md` 可获取 Markdown 版本（如 `/sre/git-basics.md`）。

---

---
url: https://ain.hmgf.hxcn.space/ai/awesome-vibe-coding.md
---
# AI/Vibe 开发教程仓库合集

AI 辅助编程正在深刻改变开发工作流。从提示词工程到 Agentic AI，从初学者入门到高级架构设计，GitHub 上涌现了大量优质开源项目。本文精选 11 个具有代表性的仓库，涵盖初学者课程、Agent 架构、效率工具、中文资源等方向，帮助你快速建立 AI/Vibe Coding 的知识体系。

## 初学者入门

适合零基础入门 Vibe Coding 的优质教程，覆盖概念认知与实战入门。

### 1. datawhalechina/easy-vibe

⭐ 5.8k | 入门首选

**核心功能**

* 面向零基础学习者的 Vibe Coding 入门课程
* 提供完整学习路线图，划分三个阶段：入门、初级开发者、高级开发者
* 跨平台开发实战教程

**适合人群**

* 初次接触 AI 辅助编程的开发者
* 希望系统学习 Vibe Coding 概念与工作流的同学

***

### 2. cporter202/lovable-for-beginners

⭐ 508 | Lovable 专精

**核心功能**

* 完整的 Lovable Vibe Coding 入门课程
* 15 个模块，涵盖提示词工程、全栈能力、调试与部署
* 实战导向，循序渐进

**适合人群**

* 想用 Lovable 快速构建 Web 应用的开发者
* 对 AI 生成全栈代码感兴趣的同学

***

### 3. datawhalechina/vibe-vibe

⭐ 4.6k | 系统性教程

**核心功能**

* 中国首个系统性 Vibe Coding 教程
* 四个模块：基础、进阶、实践、资源
* 支持 Docker 部署，基于 Next.js + React + TypeScript 技术栈

**适合人群**

* 有一定前端基础，想深入 Vibe Coding 的开发者
* 偏好中文资料、喜欢体系化学习的同学

***

## Agent 与架构模式

深入理解 AI Agent 的设计模式与架构思想。

### 4. nibzard/awesome-agentic-patterns

⭐ 4.3k | Agent 设计模式

**核心功能**

* Agentic AI 模式的全面目录
* 覆盖六大类模式：上下文与记忆、反馈循环、学习与适应、编排与控制、可靠性与评估、安全与安全
* 提供架构层面的系统性参考

**适合人群**

* 想深入理解 AI Agent 工作原理的开发者
* 需要设计复杂 Agent 系统的架构师

***

### 5. Shubhamsaboo/awesome-llm-apps

⭐ 106k | LLM 应用大全

**核心功能**

* 收录 100+ LLM 应用
* 涵盖入门 Agent、高级 Agent、多 Agent 协作、语音 Agent、MCP Agent、RAG 教程
* 支持 OpenAI、Anthropic、Gemini 及开源模型

**适合人群**

* 想探索 LLM 应用边界的开发者
* 需要构建 RAG、Multi-Agent 系统的团队

***

## 效率工具与工作流

将 AI 编码能力融入日常开发流程的工具集合。

### 6. BloopAI/vibe-kanban

⭐ 25.1k | Agent 管理看板

**核心功能**

* AI 编码 Agent 可视化管理工具
* 看板式任务规划、workspace 执行、diff 审查
* 支持 10+ 编码 Agent：Claude Code、Codex、Gemini CLI 等

**适合人群**

* 同时使用多个 AI 编码工具的开发者
* 需要统一管理 AI 任务流的专业团队

***

### 7. coleam00/context-engineering-intro

⭐ 13.2k | 上下文工程

**核心功能**

* 上下文工程模板与工作流
* 聚焦 CLAUDE.md、INITIAL.md、PRP（产品需求提示词）的生成与执行
* 帮助开发者更好地与 AI 编码助手协作

**适合人群**

* 想提升 AI 理解任务能力的开发者
* 需要建立团队级 AI 协作规范的同学

***

## 中文资源

优质中文 Vibe Coding 学习资料，适合国内开发者。

### 8. 2025Emma/vibe-coding-cn

⭐ 19.4k | 中文全栈指南

**核心功能**

* 全面的中文 Vibe Coding 指南
* 元方法论：递归自我优化 AI 系统
* 包含工具评测、工作流文档、提示词模板

**适合人群**

* 偏好中文阅读的开发者
* 想了解 Vibe Coding 前沿实践的同学

***

### 9. liyupi/ai-guide

⭐ 12k | 程序员鱼皮知识库

**核心功能**

* 程序员鱼皮的 AI 知识库
* Vibe Coding 教程
* AI 工具评测：Cursor、Claude Code、TRAE、Lovable、Copilot
* 提示词合集、MCP/A2A/RAG 文档

**适合人群**

* 国内开发者，尤其是在校学生
* 想快速上手主流 AI 编程工具的同学

***

## 创业与独立开发者

AI 时代一人公司的工具与资源整合。

### 10. cyfyifanchen/one-person-company

⭐ 2.7k | 独立开发者工具箱

**核心功能**

* 独立开发者 AI 工具合集
* 涵盖 LLM 模型、TTS、代码工具、设计工具、生产力工具、网站构建器
* 按场景整合，开箱即用

**适合人群**

* 独立开发者 / 一人公司创业者
* 想用 AI 工具提升个人生产力的同学

***

### 11. kuchin/awesome-ceo

⭐ 2.2k | 创业者资源库

**核心功能**

* 面向创业者的精选资源合集
* 涵盖融资、创业精神、产品、销售、营销、管理、招聘、财务
* 帮助技术创业者补全商业知识

**适合人群**

* 有技术背景的创业者
* 想了解创业全流程的开发者

***

## 总结

| 分类 | 仓库 | Stars | 亮点 |
|------|------|------|------|
| 初学者入门 | datawhalechina/easy-vibe | ⭐ 5.8k | 学习路线图三阶段 |
| 初学者入门 | cporter202/lovable-for-beginners | ⭐ 508 | Lovable 实战 15 讲 |
| 初学者入门 | datawhalechina/vibe-vibe | ⭐ 4.6k | 中文系统性教程 |
| Agent 架构 | nibzard/awesome-agentic-patterns | ⭐ 4.3k | Agent 设计模式目录 |
| Agent 架构 | Shubhamsaboo/awesome-llm-apps | ⭐ 106k | 100+ LLM 应用 |
| 效率工具 | BloopAI/vibe-kanban | ⭐ 25.1k | Agent 可视化管理 |
| 效率工具 | coleam00/context-engineering-intro | ⭐ 13.2k | 上下文工程模板 |
| 中文资源 | 2025Emma/vibe-coding-cn | ⭐ 19.4k | 元方法论中文指南 |
| 中文资源 | liyupi/ai-guide | ⭐ 12k | 鱼皮 AI 知识库 |
| 独立开发者 | cyfyifanchen/one-person-company | ⭐ 2.7k | AI 工具箱 |
| 独立开发者 | kuchin/awesome-ceo | ⭐ 2.2k | 创业者资源合集 |

以上仓库覆盖了从零入门到高级应用的全链条。无论你是想快速上手一个 AI 编程工具，还是深入研究 Agent 架构设计，都能从中找到适合自己的资源。