在我们构建现代编译器和解析器的过程中，理解文法的结构始终是核心挑战之一。当我们深入探讨自顶向下的解析技术时，FIRST 和 FOLLOW 集合不仅是教科书上的概念，更是构建强大解析工具、甚至是在现代 AI 辅助编程环境中理解代码结构的基石。在这篇文章中，我们将以 2026 年的技术视角，重新审视这两个至关重要的集合，探讨它们如何指导解析器高效处理输入，以及它们在 AI 驱动的开发流程中的新角色。
为什么 FIRST 和 FOLLOW 至关重要？
让我们先回到基础。FIRST 和 FOLLOW 是两个至关重要的集合，它们能帮助我们在语法分析中更好地理解文法的结构。简单来说，它们解决的是“预测”的问题：当我们看到一个符号时，我们该选择哪条产生式规则来推导？这是构建 LL(1) 解析器 的前提，也是我们在 Cursor 或 Windsurf 等 AI IDE 中实现精准代码补全的核心逻辑。
如果不精确计算这些集合，我们的解析器就会在遇到分支时陷入犹豫，要么回溯导致性能指数级下降，要么直接崩溃。在 2026 年，随着代码库越来越庞大，任何解析阶段的性能瓶颈都会被无限放大。
FIRST 集：预测的开始
所谓 FIRST 集，是指当我们从一个非终结符出发推导字符串时，可能出现在该字符串最开头的所有终结符号。它告诉我们：当我们要展开某个非终结符时，首先遇到的“那个符号”可能是谁。
场景化解析：从 JSON 到 AI 上下文
在 2026 年的“氛围编程”范式中，我们不仅是在写代码，更是在与 AI 结对编程。当你输入一个函数调用的前缀时，IDE 之所以能精准预测你接下来可能输入的变量名或关键字，正是因为后台的解析器利用了类似 FIRST 集的逻辑来确定上下文。
让我们来看一个实际的例子。假设我们正在处理一个 JSON 解析器（这在现代云原生应用中非常常见），我们需要定义处理对象的文法。
示例：处理嵌套结构
考虑以下产生式规则：
// 产生式: Obj -> { PairList }
// PairList -> Pair , PairList | ε
为了计算 FIRST(Obj)，我们需要查看产生式 INLINECODEe4c33093。显然，字符串必须以 INLINECODE922994fe 开头。因此，{ 被加入 FIRST(Obj)。
但更复杂的情况出现在处理 PairList 时。
当 X 拥有多条产生式规则时：
> PairList → Pair , PairList
> PairList → ε
我们需要检查所有右侧可能：
- 第一条规则 INLINECODEa9ea78af 的首符号取决于 INLINECODE2c976470。假设 INLINECODE9317ae72 的第一个符号是 INLINECODEa9842f54（即键名），那么 INLINECODEf9d086c0 就属于 INLINECODE8d6d573b。
- 第二条规则 INLINECODEe81d9c9c 意味着 INLINECODE9582a955 可以为空。因此，ε 也要包含在
FIRST(PairList)中。
最终结果： FIRST(PairList) = { String, ε }。
生产级代码实现：处理复杂依赖
在我们的实际工程中，我们通常不会手动计算这些集合，而是编写算法来生成。但是，理解原理对于调试至关重要。让我们看一个基于 C++ 的更深入的 FIRST 集合计算器片段，这展示了我们如何处理“空串传播”的逻辑。
#include
#include
#include
#include
#include 代码解析与避坑指南：
在我们最近的一个编译器重构项目中，我们经常遇到的一个 Bug 是无限递归。注意上面的代码注释，如果文法存在左递归（如 A -> A α），这个简单的函数会栈溢出。在 2026 年的现代工具链中，我们倾向于在计算 FIRST 之前先使用 Agentic AI 辅助工具检测并消除左递归，这是安全左移的一部分。
FOLLOW 集：识别上下文的边界
FOLLOW 集则包含了在文法的任何推导过程中，可能紧跟在某个非终结符之后的所有终结符号。它帮助我们识别在语法结构中，什么符号可以紧跟在一个非终结符后面，这对于处理那些非终结符出现在规则末尾的情况尤为重要。
为什么 FOLLOW 是解析器的“安全网”？
想象一下，我们在调试一个复杂的 SQL 解析器。当解析器处理到一个 INLINECODE202aeb6b 语句的末尾时，它如何知道后面接的是 INLINECODE83a4a4c5 还是 GROUP BY？这就是 FOLLOW 集合在起作用。它定义了合法的“下一个符号”边界。如果输入流中的下一个符号不在 FOLLOW 集中，我们就知道源代码中存在语法错误。
计算 FOLLOW 集的实战策略
让我们深入探讨几个关键场景，这些都是我们在构建高性能解析器时必须处理的边界情况。
#### 1. 当 X 出现在非终结符之前时
如果 X 后面紧跟着一个非终结符（例如 B），那么 FIRST(B) 集合会被加入到 FOLLOW(X) 中。但是，这里有一个极易被忽视的细节：ε 的处理。
示例：
> S → A X B
> B → b | ε
假设我们需要计算 FOLLOW(X)。
- 首先，B 紧跟在 X 后面。我们将
FIRST(B)加进去。 - 因为 INLINECODE811c0628，所以 INLINECODE2a5c1fb8。
- 关键点： 我们不能直接把 ε 加到 FOLLOW(X) 中。ε 是“空”，不是一个实际输入符号。
- 如果 B 推导出 ε，那么 B 就消失了。此时，X 后面实际上跟的是 B 后面的东西（如果有），或者是 S 后面的东西（即
FOLLOW(S)）。
结论： INLINECODEe9c6d41c 包含 INLINECODEc1125b14。如果 INLINECODE67bdae4d 包含 ε，那么 INLINECODE17e6f14a 还要包含 FOLLOW(S)（即产生式左部 S 的 FOLLOW 集）。
#### 2. 边界情况与容灾：$ 符号的陷阱
在我们的生产环境中，最常见的错误源于忘记初始化起始符号的 FOLLOW 集。
规则： 如果 X 是文法的起始符号（例如 S），INLINECODE570e58d6 必须包含输入结束标记 INLINECODE7c578658。
如果我们在手写解析器时漏掉了这一点，解析器可能会在文件读取完毕后继续尝试读取内存中的垃圾数据，导致未定义行为或安全漏洞。在现代 DevSecOps 实践中，这类逻辑错误是静态分析工具的重点检测对象。
高级实现：传递闭包与迭代
与 FIRST 集不同，FOLLOW 集的计算通常需要迭代多次，直到集合不再变化（不动点）。让我们看一段更接近生产环境的 Rust 伪代码，展示了如何处理这种迭代依赖。
use std::collections::{HashMap, HashSet};
use std::vec::Vec;
#[derive(Debug, Clone)]
struct Production {
lhs: String, // 左部：非终结符
rhs: Vec, // 右部：符号串
}
fn compute_follow(productions: &Vec, start_symbol: &str) -> HashMap<String, HashSet> {
let mut follow_sets = HashMap::new();
// 1. 初始化：所有 FOLLOW 集为空，除了起始符号加入 $
follow_sets.insert(start_symbol.to_string(), HashSet::from(["$".to_string()]));
// 2. 迭代直到不再变化（不动点算法）
loop {
let mut updated = false;
for prod in productions {
let lhs = &prod.lhs;
// 获取产生式左部的 FOLLOW 集（克隆以避免借用检查器问题）
let lhs_follow = follow_sets.get(lhs).unwrap_or(&HashSet::new()).clone();
// 遍历产生式右部的每一个符号
for (i, symbol) in prod.rhs.iter().enumerate() {
// 如果 symbol 是非终结符（假设大写开头）
if symbol.chars().next().map(|c| c.is_uppercase()).unwrap_or(false) {
let current_follow = follow_sets.entry(symbol.clone()).or_insert_with(HashSet::new);
let old_size = current_follow.len();
// 获取当前符号之后的部分
let beta = &prod.rhs[i+1..];
if !beta.is_empty() {
// 情况 A -> alpha B beta
// 将 FIRST(beta) - {ε} 加入 FOLLOW(B)
// 这里我们需要一个辅助函数 compute_first_of_string(beta)
// 假设我们已经有了 FIRST 集合的映射: first_sets
let first_beta = compute_first_of_sequence(beta, &follow_sets); // 简化逻辑
for term in first_beta {
if term != "ε" {
current_follow.insert(term);
}
}
// 如果 FIRST(beta) 包含 ε，则将 FOLLOW(lhs) 也加入 FOLLOW(B)
if first_beta.contains("ε") {
for term in &lhs_follow {
current_follow.insert(term.clone());
}
}
} else {
// 情况 A -> alpha B (B 在末尾)
// 将 FOLLOW(lhs) 加入 FOLLOW(B)
for term in &lhs_follow {
current_follow.insert(term.clone());
}
}
if current_follow.len() > old_size {
updated = true;
}
}
}
}
if !updated {
break;
}
}
follow_sets
}
// 辅助：计算符号串的 FIRST（简化版）
fn compute_first_of_sequence(beta: &[String], follow_map: &HashMap<String, HashSet>) -> HashSet {
let mut result = HashSet::new();
// 实际逻辑：遍历 beta，累加 FIRST，直到遇到非 ε
// 这里仅作演示，实际依赖全局的 FIRST 集合而非 FOLLOW 集合
if beta.is_empty() {
result.insert("ε".to_string());
}
result
}
这段代码展示了现代系统级编程语言如何处理此类问题。注意我们使用了 HashSet 来保证 O(1) 的查找效率，这在处理包含数万条规则的庞大文法（如 TypeScript 或 C++ 的完整文法）时至关重要。
构建 LL(1) 解析表与冲突消解
FIRST 和 FOLLOW 集合的终极目标，是指导我们创建 LL(1) 解析表。这些表就像是地图，指引解析器根据下一个输入符号选择正确的产生式规则。
决策机制：M[A, a]
解析表 INLINECODEa49fceb1 的行是非终结符，列是终结符（或 $）。INLINECODE74700a98 填入的是什么规则？
- 基于 FIRST 集： 如果 INLINECODEc26f2656 属于 INLINECODEf16a4378，那么我们就填入对应的产生式
A -> α。 - 基于 FOLLOW 集： 如果 INLINECODE952add72 属于 INLINECODE6421d527（即 A 可以推导出空），并且 INLINECODE468ef4fd 属于 INLINECODEb1d8a3ae，那么我们填入产生式
A -> ε。
处理冲突：我们的实战经验
你可能会遇到这样的情况：在表 M[A, a] 中，既填入了规则 1，又想填入规则 2。这就是 FIRST/FOLLOW 冲突。这意味着文法不是 LL(1) 的。
解决方案：
在我们最近处理的一个 DSL（领域特定语言）项目中，我们遇到了严重的二义性问题。我们没有选择强行编写复杂的回溯解析器（性能太差），而是采用了以下策略：
- 文法变换： 利用 Agentic AI 分析冲突点，自动进行左因子提取。例如将 INLINECODE09971c97 重写为 INLINECODEfd21d253 和
A‘ -> β1 | β2。 - 信息层增强： 在某些无法通过文法解决的极端情况下（如 C++ 的类型声明与表达式），我们不再试图通过上下文无关文法来解决。现代编译器通常混合使用词法分析器和符号表信息来辅助决策（即“符号栅栏”技术），这其实是一种混合解析策略。
2026 视角：AI 辅助文法工程与多模态开发
随着我们步入 2026 年，编译器设计正在经历一场静默的革命。传统的“编写文法 -> 生成解析器”的流水线正在被 AI 辅助的闭环系统所取代。
Agentic AI 在文法优化中的角色
在我们的工具链中，AI Agent 不仅仅是一个聊天机器人。它拥有读取抽象语法树（AST）和 FIRST/FOLLOW 集合的能力。当我们定义一个新的语言特性时，Agent 会实时计算 FIRST 和 FOLLOW 集合，并检测潜在的“预测分析冲突”。
例如，如果 Agent 发现 INLINECODEf1fd7236 和 INLINECODE3e4faf0d 有交集，导致 Statement -> stmt1 | stmt2 无法通过 LL(1) 解析，它会主动建议重构方案，而不是让编译器在运行时崩溃。这种“安全左移”极大地提高了开发效率。
多模态开发与实时协作
在现代的云原生 IDE 中，文法设计是多模态的。我们可能在一个窗口修改 EBNF 文法，而在另一个窗口实时看到解析表的热力图变化。红色区域表示 FIRST/FOLLOW 冲突，绿色区域表示 LL(1) 安全区。这种可视化对于复杂的语言设计至关重要。
此外，边缘计算的兴起要求我们将编译器做得更轻量。通过精确计算 FIRST 和 FOLLOW，我们可以生成最小化的状态机，减少解析器的内存占用，这对于在浏览器端甚至微控制器上运行高级语言解析器是关键。
总结与展望
回顾这篇文章，我们从基础的 FIRST 和 FOLLOW 定义出发，深入探讨了它们在 2026 年技术栈中的实际应用。无论是为了在 Cursor 中编写更精准的 Prompt，还是为了构建高性能的服务端边缘编译器，理解这两个集合的原理都是不可逾越的步骤。
随着 AI 原生应用的兴起，虽然我们越来越多地依赖 LLM 来处理自然语言，但作为计算机科学最基础的“语言”——编程语言，其解析逻辑依然严密地建立在形式化文法之上。掌握 FIRST 和 FOLLOW，就是掌握了与计算机底层逻辑对话的钥匙。希望我们分享的这些代码片段和工程经验，能帮助你在实际开发中避开常见的陷阱，构建出更健壮的系统。
让我们保持这种对底层技术的敬畏与探索，继续在代码的世界中前行。