当计算语言学家需要用形式语法构建一个粤语语法库时最常见的卡点其实不是“不懂粤语”也不是“不会写规则”而是“规则怎么写都覆盖不全”。一个语法规则可能要拆成几十种句法环境每种环境还要考虑助词、话题化、零代词等粤语特有现象。过去这类工作基本靠语言学家手工编写规则、手工整理例句、手工标记特征成本高、周期长而且很难在不同工程人员之间保持一致。所以项目标题里那个问题非常直接How Useful are LLMs for Grammar Engineering?如果 LLM 能在语法工程的某些环节帮上忙哪怕只是把例句分类、特征标注、初始规则生成这些重复劳动自动化一部分对粤语这类资源稀缺语言来说都是巨大的效率提升。但问题在于“有用”这个词不能凭感觉判断必须通过受控实验、基线对比和指标测量才算数。这篇文章会围绕这个研究问题展开聊清楚语法工程为什么需要 LLMCantonese ParGram Resources 这类资源卡在哪里以及“with English Baselines”这种实验设计到底在解决什么问题。我会把论文标题拆成三层形式语法工程的背景、LLM 如何进入这个流程、以及受控实验怎么评估“有用性”。最后给出一套可以在自己项目里复用的判断方法和排查思路。1. 语法工程不是写正则是在写“语言理论”1.1 一张语法规则背后是一整套理论选择很多人第一次接触 ParGram 时容易产生一个错觉形式语法规则跟正则表达式差不多本质上都是“匹配某种字符串模式”。但 ParGram 这类项目完全不是这个思路。在 ParGram 框架里语法规则基于词汇功能语法LFG等约束性语法理论每条规则不仅要说明“这个词可以出现在哪里”还要解释“这个词在句子里承担什么语法功能”“它和句子的其他部分有怎样的约束关系”。比如粤语里很常见的“我食咗饭”如果要形式化描述不只是要匹配“主语谓词体标记宾语”还要表达“食”要求一个施事主语和一个受事宾语“咗”是一个完成体标记它附着在动词后面并且和整个事件的时间结构相关。这些信息一旦进入规则库就不是简单的字符串匹配而是一组结构约束、功能标注和补足语要求。写规则的人必须同时做两件事理解语言学理论又理解形式化框架的工程约束。这比日常敲代码复杂得多因为每一条规则背后都有一整套语言分析决策。1.2 粤语资源的稀缺让语法工程更难大多数语法工程项目会优先选择资源丰富的语言作为研究平台原因非常实际有大规模树库、有成熟的词汇资源、有大量可用语料、有一批熟悉该语言的标注者。英语就是典型的“容易开始”的语言。一个英语语法库即使中间有坑也至少能找到公开测试集和大量语料来验证。但粤语的情况完全不同。粤语虽然是全球使用人口很多的汉语族语言但在计算语言学资源建设上仍然属于相对稀缺的目标语言。它缺少大规模一致标注的语料库缺少与 LFG 或 ParGram 体系直接对齐的既有语法资源而且粤语自身的语言现象又很独特丰富的句末助词、话题化结构、动词体貌标记、省略与零代词、语序和普通话不完全一致等。这些现象单独拿出来都够写一篇论文合在一起建一个完整语法库传统手工作业的时间成本和知识成本会非常高。所以这里出现了一个天然的动机如果 LLM 能够在这种资源稀缺、需要快速构建初始规则和测试语料的场景里发挥作用哪怕只是辅助生成候选规则或候选测试句都可能让粤语语法工程的启动速度明显加快。这也是项目标题把“Cantonese ParGram Resources”和“LLM”放在一起的原因。2. LLM 进入语法工程能做什么不能做什么2.1 LLM 可以做但需要验证的几类任务从工程实践看LLM 在语法工程里最有潜力的环节并不是“直接生成完整语法库”而是那些“需要语言直觉但不需要完全精确”的中间任务。结合 ParGram 这类框架常见候选任务有下面四类。第一类是候选测试句生成。语法工程需要大量最小对测试句来验证规则比如“我食饭”“我食咗饭”“我唔食饭”“我饭食咗”能不能被语法接受、结构有什么不同。传统做法是语言学家手工构造时间消耗非常大。LLM 可以基于少量示例生成数量更多的候选句再由人工筛选。这个任务门槛不高但非常有用因为测试句覆盖度直接决定语法库回归测试的质量。第二类是词条特征预测。ParGram 语法库中每个词都有词类、次范畴化框架、句法功能特征。LLM 可以根据词条和上下文预测这些特征减少人工翻阅词典或语料库的时间。例如给定“畀”这个词LLM 可以根据句子示例猜测它可能带双宾语或补足语结构并给出若干种可能的特征组合。第三类是句法结构的候选标注。给定一个粤语例句LLM 可以输出候选的短语结构或依存关系。虽然不能直接作为最终结果但可以作为初始候选交给语法工程师在编辑器里调整。这样比从零开始画树或写 c-structure 轻松不少。第四类是规则片段的初始生成。有了明确的框架约定和少量示例LLM 可以尝试生成某一类语法规则的雏形。比如实现粤语“动词体标记”规则的初始模板再由人工修改。这里风险比较高因为规则里的功能名称、约束条件、宏定义都必须符合项目约定LLM 很可能生成“看起来像规则但实际结构不对”的内容。这四类任务有一个共同特点产出物都需要人工审核但审核成本远低于从零构建。这正是 LLM 在语法工程里真正的定位不是替代语言学家而是把大量“需要语言直觉的重复工作”压成“生成校验”的受控流程。2.2 为什么不能直接让 LLM 生成一套完整语法有人可能会想既然 LLM 能写 Python 代码为什么不直接让它输出一套完整的 ParGram 语法库这里必须说明边界。形式语法库不是一份散文文本而是一个可运行的、与解析器配套的约束系统。它有一套极其具体的工程约定规则里使用的特征名、值的层级、模板和宏定义、禁止的写法、与外部词汇库的衔接方式。不同语法项目之间的这些约定差异很大。LLM 即使学过很多语言学数据也未必知道你这个项目里“asp”是“aspect”还是“assertive particle”更不知道你希望在哪种结构里复用某个宏。更关键的是语法库的正确性很难靠“读一遍”判断。一条规则有没有歧义、会不会过度生成、是否会阻断其他规则必须在完整语法库上解析大量测试句才能发现。LLM 产生规则时看到的上下文通常只有一小段提示它没有能力在局部推理里评估全局规则之间的交互。因此如果让 LLM 一次性生成完整语法库几乎必然会出现大量局部合理、全局不可用的问题。所以更稳妥的路线是把语法库拆成若干可独立生成、可独立验证的片段让 LLM 在“有框架约定 有少量示例 有明确任务边界”的情况下完成片段然后通过解析器或测试集做自动验证。这也是为什么论文要用“受控实验”来做评估的原因——如果不控制任务边界LLM 的能力和短板会被混在一起得到的数据很难指导实际使用。3. 受控实验设计怎么衡量“有没有用”3.1 英语基线同一个流程换一种语言如果只是让 LLM 生成几条例句然后说“看起来可以”这在研究层面没有任何说服力。因为语法工程里的很多困难并不来自语言本身而来自框架复杂度。为了把“LLM 在语法工程中的作用”从“LLM 总体上很强”这个模糊判断里分离出来最直接的方法就是设置基线。项目标题里的“English Baselines”就是这条逻辑同一个实验流程用英语语法库跑一遍再用粤语语法库跑一遍然后把结果放到一起对比。如果 LLM 在英语任务上表现很好但在粤语任务上明显下降差异大概率来自语言资源稀缺程度、粤语特有句法结构、或框架规则适配度。如果 LLM 在两个语言上表现接近说明它具备一定的跨语言语法工程能力至少不是“只会英语”。但要注意英语基线并不是“用英语测试 LLM 能力”这么简单。在实际研究里还需要考虑基线数据是否同规模英语和粤语的训练语料、词典条目、测试句数目是否保持一致。基线任务是否同难度英语语法库可能已经打磨了多年粤语语法库可能是全新构建二者直接比较需要排除“成熟度差异”。基线评测维度是否相同如果英语用解析成功率和 F1粤语也应该用同样指标而不是换成人工主观评分。从工程经验看英语基线更像是一把尺子。尺子统一了才能衡量“粤语 LLM”这个组合的真实增量是多少。没有基线的实验只能说明“LLM 做了某些事”不能说明“这些事比传统方法好多少”。3.2 实验切片规则生成、句子分类、错误修复与特征赋值衡量“LLM 对语法工程是否有用”不能只问一个笼统的问题。因为语法工程是一条流水线不同环节对 LLM 的要求完全不同。受控实验通常会切成几个典型任务每个任务独立计算效果然后汇总判断。从常见实验设计来看至少会覆盖下面几个切片词条特征预测给 LLM 一个词和若干上下文让它输出词类、次范畴化框架、体标记属性等。评测方式是预测特征和人工标注特征的匹配度。候选规则生成给 LLM 一个框架片段和几条示例让它补全/生成一条语法规则。评测方式不是看文本相似度而是看规则能否通过框架编译以及能否解析预期句子。测试句分类给 LLM 一个句子集合让它判断这些句子在给定语法库下是否应该被分析成功。这相当于辅助构造回归测试集。评测方式是分类准确率。错误修复给 LLM 一条失败的分析日志和对应规则片段让它提出修改建议。评测方式是建议是否指向真实问题、修改后能否让解析通过。每个切片对应一种“效用”。预测词条特征解决的是“初始资源构建慢”的问题候选规则生成解决的是“规则初始模板难写”的问题测试句分类解决的是“回归测试覆盖不足”的问题错误修复解决的是“维护期排错费人力”的问题。这四个切片的价值并不相同。从实践看测试句生成和词条特征预测最容易见效因为这两个任务对全局规则一致性要求低LLM 只需要局部语言直觉。候选规则生成和错误修复则更难因为它们要求 LLM 理解当前语法库的工程结构和规则交互局部输出很容易踩坑。3.3 指标与对照组不只是“看起来行不行”受控实验还需要定义清楚指标。语法工程不是聊天机器人评测不能只靠“人工打分是否流畅”。常见的量化方式包括规则编译通过率生成的规则能否被 LFG 工具链接受。解析成功/失败准确率在测试集上LLM 辅助后的语法库是否比基线语法库解析出更多正确结构。人工修正率自动化生成的结果有多少需要人工修改以及修改幅度多大。耗时对比同一批任务传统手工作业需要多少时间使用 LLM 辅助后需要多少时间。最后一项尤其重要。语法工程团队最终关心的不是“LLM 生成了什么”而是“整个流程能不能更快、更稳”。如果 LLM 生成了 60% 的候选规则但剩下 40% 需要人工大量修改总耗时反而可能超过完全手工。因此受控实验必须把“人工介入成本”也纳入评估不只是看“生成质量”。还有一点容易被忽略对照组。不能只用“有 LLM 辅助”和“完全手工”对比最好再设置一个“有 LLM 但没有框架规范提示”的对照组用来区分 LLM 的能力是来自语言知识本身还是来自用户把任务拆得足够清晰。这个对照可以避免高估“提示工程”的作用。4. 从研究到落地语法工程中的人机协作流程4.1 推荐的最小流程先让 LLM 做“语料预处理”如果是在自己的语法工程项目里尝试这套方法我不建议一上来就让 LLM 写规则。更稳妥的做法是先从语料预处理切入把这个环节跑通再逐步往上走。一个可复用的最小流程是准备一组粤语例句数量不用太多30 到 50 句即可。把这些句子按任务拆成两类一类是要测试语法覆盖范围的句子一类是要用于词条信息补充的句子。给 LLM 一段非常明确的提示说明目标语言、ParGram 框架、输出格式和当前项目的特征系统。注意这里的说明不是一句“你是语言学专家”就够而是要把项目里实际使用的特征名、宏名、词类列表丢进去。让 LLM 为每个句子输出候选的结构分析或词条特征然后让懂语法工程的同事在编辑器里快速确认或修正。为什么先做语料预处理因为这一步的产物即使不完美也不会破坏现有语法库。候选句子选错了删掉重来词条特征猜错了手动改一下。它和“运行中的语法规则”之间隔着安全的距离风险最低但能让团队快速建立对 LLM 输出风格的体感。这个流程的目的不是一步到位而是找到一个稳定的协作模式LLM 负责生成“量大、不完整但方向正确的候选”人类负责“判断、修正、确定”。一旦这个模式被团队认可再扩展到候选规则生成和错误修复。4.2 人工校验的关键节点引入 LLM 之后人工校验不是变少了而是变得更重要了。关键校验节点至少有三个。第一个节点是生成前的任务定义校验。在让 LLM 开始干活之前人必须确认任务边界是否足够窄。比如“请生成粤语体助词的测试句”就比“请增强粤语语法库”有效得多。任务定义不清晰后续所有输出都会偏离。第二个节点是生成后的规则语义校验。LLM 生成的规则可能在形式上完全符合框架语法但在语言学分析上是错的。比如它可能给某个动词添加了错误的次范畴化框架或者把句末助词误标成语气词。这一步需要语言学家或资深语法工程师介入不能只靠编译通过就放行。第三个节点是集成后的回归测试校验。新规则加入完整语法库后可能会影响已有句子的解析路径。此时必须跑一个覆盖已有测试句的回归套件确认没有引入新的过度生成或分析冲突。只要这一环节暴露问题之前的候选生成和修复建议就可能要回滚。这三个节点实际上回答了“LLM 有用吗”的另一个方面有用不等于可以无人值守。真正稳定的语法工程流程是把 LLM 放在一个由人工把关的管道里而不是把它放在最终决策点。4.3 长期维护规则库、测试套件与回归语法工程不是一次性建设而是长期维护。粤语语法库一旦进入使用阶段就要面对新词、新句式、跨方言差异、解析器升级等问题。这时候LLM 的价值会从“初始生成”转移到“维护支持”。一个常见场景是新来了一批语料需要补充词条和测试句。传统做法是人工扫描语料找出不在词库中的词然后逐个补充。有了 LLM可以先自动抽取候选词条再生成包含该词条的测试句人工确认后加入回归套件。这个流程可以每天处理一批而不是隔几个月集中做一次。另一个场景是规则回归。某个语法改动导致解析失败数量增加排查时通常要逐条看失败日志。LLM 如果能在失败日志里定位出“疑似同一类规则冲突”就能减少大量人工筛选时间。但要注意这种定位只是线索最终修改仍需要人来决定。长期维护考验的不是单次生成质量而是过程的可追溯性。每条候选规则、每个测试句、每次修改建议都应该记录来源和状态。这个环节建议使用版本管理而不是直接在编辑器里手工改否则后续很难知道哪些内容是 LLM 生成的哪些是人工调整过的。5. 实际使用经验与避坑清单5.1 让 LLM 先理解框架约定再谈规则很多人把 LLM 当成“懂语言学”的了于是直接说“帮我写一条 LFG 规则”结果得到的规则要么用了错误的功能名要么缺少约束条件要么和项目里的宏定义对不上。问题不在 LLM 的语言学水平而在你提供的上下文不够。在生成规则之前我建议在提示里放三样东西项目已有的规则片段至少 3 到 5 条不同类型的规则。当前特征系统表包括特征名、允许值、层级关系。对应的测试例句和预期分析结果。这三样东西等于给 LLM 搭了一个脚手架。有了脚手架它生成的内容才能大概率落在项目的框架约定内。如果直接用一个空白的对话让它“写语法规则”得到的结果基本只能当参考不能用。另外输出格式要明确。比如可以要求“只输出 LFG 规则不要解释”“用feature: value的格式列出特征”。这样后续可以写脚本做格式校验减少手工整理成本。5.2 小样本评测永远优先于全量生成一个很常见的错误是第一次试完觉得“效果还不错”于是直接把整个语法库的剩余部分都交给 LLM 批量生成。这种做法风险极大。语法工程和普通内容生成不一样一条规则出错会影响一大批句子。而且一旦批量生成错误模式很可能是有规律的——同一类错误分布在多个词条里回头看时已经很难逐一清理。正确做法是每次只取一个小样本比如 10 个词条或 20 个测试句分别人工评估以下维度格式是否符合框架约定。语义是否正确。是否能直接编译通过。是否在完整语法库上解析出预期的句子。人工修正时间是否在可接受范围内。如果这五个维度在小样本上稳定通过再扩大规模。扩大时也要分批进行每批之间跑一次回归测试。先跑通再优化最后再谈规模化。这一步不是保守而是语法工程本身的试错成本太高。5.3 排查链路生成的规则为什么不可用当 LLM 生成的规则不可用时不要急着调整提示词或换模型。先按这个顺序排查。先看任务定义。提示里是否说清楚了目标语言、框架、特征系统和输入输出格式如果任务本身太宽泛后续所有问题都不奇怪。再看示例质量。示例规则和示例句子是否和当前任务同类型如果让 LLM 生成粤语体助词的规则却只给了英语话题化规则做示例它输出的内容大概率会偏离。接着看框架术语。生成的规则是否使用了当前项目不存在的特征名或宏名这种情况常见于 LLM 从通用知识中“泛化”出了错误术语。解决办法是在提示里明确列出允许使用的特征名和宏名。然后看规则集成位置。一条规则在单个文件里看起来没问题放进完整语法库后可能和其他规则冲突。排查时要在完整语法库上跑几条相关测试句看失败日志是否指向约束冲突或循环规则。最后看语言分析本身。前面的步骤都没问题规则还是不适用就要回到语言学判断这个句法现象的分析是否和当前语法理论一致LLM 的候选规则可能基于一种你并不打算采用的分析框架这时只能在人工层修改或放弃。这个排查链路不复杂但它能避免一个很常见的误区把“规则不可用”直接归结为“LLM 不行”。很多时候不是 LLM 不行而是任务定义、上下文质量、规则集成和语言学分析中某一步出了问题。6. 语法工程之后LLM 不是魔法而是一台加速器6.1 对 ParGram 这类长期项目的意义ParGram 这类项目有一个特点它们不是写一个小脚本跑完就结束而是持续多年、跨语言、跨团队维护的语法资源集合。在这样的项目里任何能降低“入门门槛”和“重复劳动成本”的工具都有长期价值。LLM 的意义不在于让新手一夜之间成为语法工程师而在于让有经验的人能把更多精力放在真正困难的问题上。比如一个资深语法工程师过去每天花费两三小时整理词条和测试句现在可以把这段时间压缩到几十分钟然后把省下来的时间用于设计更复杂的规则、分析跨语言差异或优化解析性能。从研究角度看LLM 辅助构建的粤语资源也比“手工从零写”更有机会被快速验证。语法资源的价值最终要看它能不能被其他研究者使用、被解析器正确加载、被后续项目扩展。LLM 如果能在初始版本生成和测试集建设上提供助力就可能让资源建设从“五年后见成果”缩短到“先出一个可用的 v0.1 版本”。6.2 对普通开发者意味着什么可能你并不做粤语语法也不研究 LFG但这个问题完全可以迁移到另一个场景当你想用 LLM 辅助构建“复杂且有严格规范的系统”时什么该放手什么该严格校验。任何工程领域都一样LLM 擅长的是把“语言直觉和知识”变成候选方案。但一旦这个候选方案要进入生产系统就必须经过格式校验、集成测试、回归测试和人工审查。语法工程只是把这条规则放到最极端的位置因为产出物不是草稿文本而是可运行的约束系统。这也解释了为什么“LLM 对语法工程有多有用”这个问题不能用“能生成语法规则”来回答。真正的答案是它在这个领域里是一个加速器能够降低启动成本和维护成本但它的可靠性、一致性、工程化边界仍然需要人类用体系化的实验来界定。对普通开发者来说这个结论同样适用LLM 生成的代码、配置文件、测试用例都应该以“候选人”而不是“最终答案”的身份进入工作流。6.3 一个判断框架什么时候该用 LLM 做语法工程如果你也在考虑把 LLM 引入自己的语法工程或类似工程流程可以用这个四步判断框架任务是否边界清晰如果任务能拆成“输入一句话输出一个特征集”这样的单元适合 LLM如果任务要求“理解整个语法库的全局约束”需要谨慎。错误成本是否可控如果 LLM 的结果需要人工花一分钟确认可以批量使用如果一条错误会污染数据库且难以回滚就不能直接全自动。是否能自动验证生成结果后是否有解析器、编译器和测试集可以快速判断正确性。没有自动验证只靠人工判断最好不要大规模使用。是否保留了人工决策点流程里是否每隔几步就有人工审查和版本回滚机制。如果没有建议先补上再引入 LLM。这个框架同样适用于其他领域。核心思想很简单LLM 的真正价值不是替你做决定而是把“从无到有”变成“从候选到确认”。它把耗时的生成过程压缩了但把更多的责任放在了“确认”这一环上。所以回到最初的问题LLM 对语法工程到底有多有用从研究设计看它有用但需要受控评估从工程实践看它有用但必须放在有人工把关的流程里从长期建设看它有用因为它让粤语这类资源稀缺语言的语法资源建设有了更快启动的可能。但这种“有用”从来不是免费的代价是你需要重新设计整个协作流程把大任务拆成小任务把全量信任改成局部验证把人放在最终决策的位置上。这个代价才是决定 LLM 能否真正改变语法工程的关键。