企业官网建设流程全解析

大模型能生成流畅的自然语言，也能完成不少语法层面的纠错任务，但回到“语法工程”这个领域，情况要复杂得多。语法工程不是让模型输出一段通顺的文本，而是要把一门语言的词类、语序、论元结构、形态变化和功能关系，写成一套可执行、可测试、可复用的形式规则。以粤语 ParGram 资源建设为例，最近的工作把问题推进得非常具体：LLM 到底能在语法工程里承担多少工作？生成出来的词条、句子和规则解释，能不能直接进资源库？

过去一年里，很多团队尝试用大模型自动构建语料、自动标注、自动生成规则，但真正产出可靠语法库的并不多。原因在于：语法工程对精确性的要求极高，而 LLM 的输出天然带有概率性，没法保证每次都在同一个逻辑体系内自洽。与其问“LLM 能不能做语法工程”，不如问“LLM 能在哪个环节、以什么方式、在什么样的评估标准下帮上忙”。粤语 ParGram 资源建设正好是一个不错的测试场，因为它语法现象丰富、数据资源稀缺，又有相对成熟的英语语法基线可以对照。

这篇文章想围绕“可控实验评估 + 英语基线”这条主线展开。我会先解释语法工程和 ParGram 的基础，再谈粤语语法资源建设的难点，然后分析 LLM 可以切入的环节，最后给出一个受控实验评估的完整思路，并配上可复用的代码示例。读完你会得到一个更实际的判断：LLM 不是语法工程师的替代品，但足够好的工作流，确实能把语法资源建设的门槛拉低一大截。

1. 为什么语法工程需要重新被审视

1.1 传统语法工程的现实痛点

传统语法工程指的并不是“写一些正则表达式去匹配句子”，而是构建能覆盖一门语言核心句法现象的形式化语法系统。以 LFG（词汇功能语法）为例，语法工程师要维护词汇条目、形态规则、短语结构规则和功能约束，最终让计算机能够解析一个句子，并输出其功能结构（f-structure）和构成结构（c-structure）。这套过程非常依赖语言学专家的判断，也需要大量的语料验证。

最大的痛点是成本。一个中型语法的词条量动辄上万，规则数量也可能达到几百条，每新增一种语言现象，就要修改规则、补测试用例、跑回归，再检查是否破坏了已有分析。这个过程既费时又容易出错，而且高度依赖个人经验。如果团队里没有资深计算语言学家，项目几乎寸步难行。

更麻烦的是，很多语言和方言并没有足够的电子词典、树库或平行语料。粤语就是一个典型例子。主流搜索引擎和预训练模型里包含的粤语文本远少于普通话和英语，传统机器学习方法需要的数据规模根本凑不齐，而人工从零构建语法资源又太慢。于是，大家自然会想到：能不能让 LLM 来补足一部分资源建设工作？

1.2 LLM 解决了一部分问题，但没有解决全部问题

LLM 对语法工程最有价值的，不是“生成一篇语法论文”，而是它在很多局部任务上表现得相当好。比如：给定一个粤语句子，它可以给出几种合法变体；给一个词条，它可以补充搭配和论元结构；给一段规则，它可以生成自然语言解释。这些能力在语法资源建设的初期非常有帮助，因为我们需要大量候选内容供专家筛选。

但问题也随之而来。LLM 的回答风格不稳定，同一个问题换一种问法就可能得到不同的结果。它还会一本正经地生成语法上根本不存在的表达，尤其对粤语这种书面资源较少、口语变化丰富的语言，幻觉问题会更明显。如果直接把模型输出写入语法库，很容易造成规则内部矛盾，后期排查成本反而更高。

所以，关键并不是“LLM 能不能生成语法资源”，而是“如何设计一套流程，让 LLM 的产出可控、可验证、可追溯”。这正是受控实验评估要解决的问题。我们先把 LLM 当作候选生成器，再用人工评价和英语基线对照来衡量其真实效果，最后决定哪些产出可以入库。

2. 从 ParGram 到粤语：形式语法资源的基本盘

2.1 ParGram 与 LFG 框架

ParGram（Parallel Grammar）是一个多语言语法开发项目，核心思路是在 LFG 框架下，用统一的语法描述体系来开发不同语言的语法资源。LFG 的全称是 Lexical Functional Grammar，它把句子的信息分成至少两个层次：构成结构表示短语结构的线性组织，功能结构表示主语、宾语、时态、格等语法功能。

这种两层表示对跨语言语法对比非常友好。英语、汉语、粤语的语序差异很大，但在功能结构层面，很多句法关系可以统一建模。比如英语的 “I ate rice” 和粤语的 “我食咗饭”，构成结构很不一样，但在功能结构上都有主语和宾语。

工程实践上，ParGram 依赖一些成熟的工具链，比如用 Lexc 编写词法、用 XFST 做形态分析、用 XLE 解析句子并生成功能结构。这些工具的特点是对输入格式要求严格，一个小错误就可能导致整个语法无法加载。这也是 LLM 难以直接生成“可运行语法”的原因之一：它不理解编译器的内部约束，也不容易生成满足工具严格格式的完整代码。

2.2 粤语作为语法工程对象，难在哪里

粤语是汉语族中非常重要的一支，但它不是标准书面普通话。它有自己的口语表达体系，很多句子结构在普通话里不成立，或者语序不同。比如完成体标记“咗”放在动词后；双宾结构里常把“直接宾语”放在前面，说“畀本书我”，而不说“给我一本书”；还有极其丰富的句末语气词，用来表达疑问、确认、感叹、不满等语气功能。

这些现象给语法工程带来了具体困难。第一，粤语没有绝对统一的书写标准，同一个词可能写成不同汉字，给词条合并带来干扰。第二，口语色彩强，很多表达高度依赖语境，脱离语料就很难判断一个句子是否合法。第三，句末语气词数量多、组合方式复杂，需要专门的规则和特征体系来处理，不是简单加几个词条就能覆盖。

从资源建设的角度看，粤语 ParGram 还处于早期阶段。已有的英文语法资源比较成熟，但粤语语法资源往往需要从零搭建，光是把基础词类和常见句型撑起来，就需要大量人工投入。正因如此，像“LLM 对语法工程有多大用”这类问题在粤语场景下尤其值得研究，因为一旦实验设计不严谨，很容易把“LLM 能力不足”和“粤语资源稀缺”混为一谈。

2.3 为什么英语基线能帮上忙

英语在 ParGram 项目中已经有多年的积累，语法类型、测试语料、评测指标相对完整。用英语做基线，意义在于提供一个“参考刻度”。如果 LLM 在英语场景下生成的词条和规则建议也是七零八落，说明问题大概率出在方法本身；如果 LLM 在英语场景表现不错、在粤语场景却下滑明显，那就可以把问题归因到语种资源覆盖度、提示词设计或粤语特有的语法复杂度上。

所以，一个严谨的实验至少要包含两个对照组：一组用粤语提示，一组用英语提示，两者采用完全相同的任务模板和评估流程。通过横向比较，我们才有底气说“LLM 在这个环节是否真的有用”。

3. LLM 在语法工程中可以承担什么角色

3.1 从“生成一句话”到“生成可审校的候选”

如果只是让 LLM 写几个粤语例句，它通常能完成，但这对语法工程价值不大。语法工程需要的是“覆盖某个语法现象的例句、带注释的语义结构、符合词条格式的词典记录”，这些是更结构化的产出。

我建议把 LLM 的任务拆成下面几类：

这种拆分很重要。不是所有任务都适合用 LLM，比如“格式转换”用确定性脚本更可靠，“歧义句发现”则一定要专家参与。LLM 的定位是扩大候选池，而不是代替语法工程师。

3.2 LLM 的短板不能靠“换模型”解决

很多团队尝试换更大的模型来提高语法工程效果，但实际瓶颈往往不在模型参数量，而在任务设计。如果提示词里没有给出明确的输出格式和评价标准，模型就会自由发挥，生成大量不一致的内容。就算换成更强的模型，也只能改善语言质量，不能解决格式混乱和术语漂移。

语法工程需要的是内部一致的形式系统。比如一个词在词典里标注为动词，那它出现在规则里就必须遵守动词的约束；如果 LLM 在不同轮次里把同一个词标成不同词类，就会直接污染资源库。因此，工程上必须把 LLM 的每次输出固定成 JSON 或 XML 这样的结构化数据，并且配上版本号，方便审计和回滚。

3.3 我建议采用的工作模式

最稳妥的工作流是：人写种子种子词条和规则 → LLM 生成候选扩展 → 专家批量审核 → 通过测试用例后合并入库。每一步之间的接口固定下来，LLM 只负责“生成”，不负责“决定”。这套模式不会让语法工程一夜之间全自动，但能把专家的精力从“翻词典写词条”转移到“审查关键语法判断”，这才是 LLM 真正提升效率的地方。

4. 从零搭建一个粤语语法 mini 资源

4.1 先建立一个可验证的语法骨架

不管是不是用 LLM，第一步都应该是建立一个最小的语法骨架。这个骨架包含三类内容：词库、规则、测试集。先不用追求覆盖面，只保证结构清晰、能被程序解析，后面的资源和规则才能稳定扩展。

下面是一个简单的粤语语法资源骨架，用 JSON 表示：

{ "grammar_name": "CantoneseMini", "language": "yue", "lexicon": [ {"word": "我", "cat": "N", "gloss": "I/me", "features": {"pers": 1, "num": "sg"}}, {"word": "你", "cat": "N", "gloss": "you", "features": {"pers": 2, "num": "sg"}}, {"word": "食", "cat": "V", "gloss": "eat", "subcat": ["SUBJ", "OBJ"]}, {"word": "睇", "cat": "V", "gloss": "watch/read", "subcat": ["SUBJ", "OBJ"]}, {"word": "咗", "cat": "Asp", "gloss": "PERF", "features": {"aspect": "perfective"}} ], "phrase_structure_rules": [ {"name": "S -> NP VP", "annotations": "SUBJ=NP; VP=S"}, {"name": "VP -> V NP", "annotations": "OBJ=NP"}, {"name": "VP -> V Asp NP", "annotations": "OBJ=NP"} ], "test_sentences": [ "我食咗饭。", "你睇咗书。" ] }

这个 JSON 文件本身不是一个完整的 XLE 语法，但它定义了一个可读、可校验的语法骨架。后续无论是让 LLM 扩展词条，还是让评估脚本统计覆盖率，都可以从这份结构开始。这里的重点是：所有资源都必须是结构化、可解析的数据，而不是散落在一段段自然语言里的解释。

4.2 使用 LLM 扩展词条候选

有了骨架，我们可以用 LLM 来扩展词条。下面的 JSON 是一个提示模板的示例，你可以在本地模型服务或商用模型 API 中调用，但不要直接把输出入库，只作为候选：

{ "purpose": "expand_cantonese_lexicon", "system_prompt": "你是计算语言学助手，熟悉粤语语法。你只输出 JSON，不要输出额外解释。", "user_prompt": "根据以下粤语词汇列表，为每个词补充词类、英文释义、常用论元结构。只输出合法 JSON 数组。\n词汇：食、睇、畀、行、讲、知、想、要" }

为了让输出格式稳定，最好在提示词里写明“只输出 JSON 数组”和字段定义。模型返回后，先用 JSON parser 解析，无法解析的记录直接丢弃或重新生成。这段处理逻辑是语法工程里最容易忽略的环节，因为很多失败不是模型不聪明，而是输出格式不可控。

4.3 把候选转成 LFG 规则

LLM 生成的词条不是最终资源，还需要映射到 LFG 规则中。比如“畀”这个动词涉及双宾语结构，语法上需要两个宾语功能，不能简单塞进动词条目。一个概念性的 LFG 规则可以写成这样：

% 注意：这是示意写法，不是可直接运行的 XLE 代码 VP -> V NP NP { ^ = !; (^ OBJ) = !; (^ OBJ2) = !; }.

这段代码用 LFG 的注释方式，说明双宾动词“畀”“送”等会把两个 NP 分别映射为 OBJ 和 OBJ2。真正使用时，还需要在 XLE 里处理语序、格标记、可选项等细节，但思路是清楚的：LLM 负责生成候选词汇，规则形态由人工工程师把关。这样既能利用 LLM 的词汇知识，又能保证最终语法资源的一致性。

4.4 用 Python 校验 JSON 资源

资源文件会越来越大，第一步要做的是格式校验。下面这段 Python 脚本可以检查词典里的词条是否重复、词类是否有定义、规则名是否唯一：

import json import sys def validate_grammar(path): with open(path, 'r', encoding='utf-8') as f: g = json.load(f) errors = [] pos_set = {"N", "V", "Asp", "P", "Adv", "Conj", "Part"} for item in g.get("lexicon", []): if "word" not in item or "cat" not in item: errors.append(f"词条缺少 word 或 cat: {item}") elif item["cat"] not in pos_set: errors.append(f"未定义的词类 {item['cat']}: {item['word']}") names = [r["name"] for r in g.get("phrase_structure_rules", [])] if len(names) != len(set(names)): errors.append("规则名存在重复") if errors: print("校验失败:") for e in errors: print(" -", e) sys.exit(1) print("校验通过") if __name__ == "__main__": validate_grammar("canto-grammar-mini.json")

这个脚本不是什么复杂功能，但它能确保每一步都是可重复的。实际工程里，你可以在提交代码前把它放进 CI（持续集成）流程，一旦 LLM 生成的新词条导致格式错误，立刻会暴露出来。

5. 受控实验设计：为什么要用英语基线

5.1 避免“选几个漂亮例子”的陷阱

很多 LLM 演示喜欢展示几个成功案例，比如 LLM 生成了几个粤语句子，看起来不错。但语法工程不是“看个例”，而是要看覆盖率、准确率和错误模式。如果只挑成功案例，很容易高估 LLM 的作用。

受控实验的核心是：固定输入、固定提示、固定评估标准，然后比较不同条件下的表现差异。具体到粤语 ParGram 项目，至少应该比较四种条件：

这里的英语基线不是用来证明“英语比粤语简单”，而是作为一条校准线。如果 LLM 在粤语任务上的表现明显低于英语基线，说明需要进一步分析是提示词问题、训练数据覆盖问题，还是粤语本身的语法复杂度问题。

5.2 提示模板要尽量固定

受控实验里，提示模板必须对每个语种做同样处理，不能粤语用一套模板、英语用另一套模板。模板中的差异越小，结论越可信。比如都采用“为以下词汇列表补充词类、释义、论元结构”的格式，只是词汇列表不同。

同时，每个语种最好准备多组词汇和句子，避免只测少量样本造成偏差。通常的做法是划定一个“语言现象清单”，比如粤语里的完成体、双宾结构、句末语气词，英语里的时态、被动结构、宾语从句；再针对每个现象设计 10 到 30 条测试输入。这样实验既覆盖多个语法现象，又能对每个现象单独统计。

5.3 实验流程也可以完全自动化

LLM 调用、输出解析、格式校验、指标统计都可以写成脚本。这样整个实验能够复现：只要给定相同的输入和模型版本，任何人跑一遍都能得到相同的结果。这个“可复现性”对语法工程尤其重要，因为我们需要不断更新模型版本和提示词，没有自动化流程，根本没法比较新旧版本的效果。

5.4 英语基线并不是“越高越好”

需要提醒的是，英语基线高不一定代表实验成功。英语在大模型的训练语料里占比很高，模型对英语语法更熟悉，很容易生成“看起来专业”的内容，但这不代表它真的理解语法工程。所以，英语基线更重要的作用是暴露方法瓶颈：如果英语这么高资源的语种，LLM 产出的采纳率也只是一般，那就说明“用 LLM 直接生成语法资源”这个路径本身仍需谨慎。

6. 评估指标与验证脚本

6.1 选择什么指标

语法资源建设不是问答评测，不能只看“生成内容是否通顺”。我建议至少统计以下四个指标：

这四个指标能分别反映：LLM 的语言水平、资源可用性、修正成本、工程稳定性。只看其中某一个是片面的。比如 LLM 输出格式很好但内容全部不合格，那说明任务设计有问题；如果内容合格但格式一塌糊涂，说明提示模板解析策略需要优化。

6.2 写一个简单的评估脚本

下面的 Python 脚本可以处理包含专家标注的结果 CSV，计算可接受率和平均编辑次数。你需要先准备一个 CSV 文件，例如：

case_id,language,condition,accepted,edit_count yue_001,yue,llm,1,2 eng_001,eng,llm,1,0 yue_002,yue,llm,0,5 eng_002,eng,llm,1,1

然后是评估脚本：

import csv import sys from collections import defaultdict def load_results(path): rows = [] with open(path, newline='', encoding='utf-8') as f: reader = csv.DictReader(f) for row in reader: rows.append({ "language": row["language"], "condition": row["condition"], "accepted": row["accepted"].strip().lower() == "1", "edit_count": int(row["edit_count"]) }) return rows def summarize(rows): groups = defaultdict(lambda: {"accepted": 0, "total": 0, "edit_sum": 0}) for r in rows: g = groups[(r["language"], r["condition"])] g["total"] += 1 g["accepted"] += 1 if r["accepted"] else 0 g["edit_sum"] += r["edit_count"] for (lang, cond), g in sorted(groups.items()): print(f"{lang} | {cond}: acceptance={g['accepted'] / g['total']:.2%}, avg_edit={g['edit_sum'] / g['total']:.2f}") if __name__ == "__main__": path = sys.argv[1] if len(sys.argv) > 1 else "results.csv" summarize(load_results(path))

运行方式很简单：

python evaluate_results.py results.csv

预期输出大致是这样的格式，具体数值会因实验数据不同而变化：

eng | llm: acceptance=72.00%, avg_edit=1.40 yue | llm: acceptance=51.00%, avg_edit=3.10

看到这种结果后，下一步不是马上下结论说“粤语比英语难”，而是排查三类原因：提示词是否对粤语足够友好、输出解析是否丢掉了某些正确内容、粤语测试集本身是否设定了过高的语言标准。

7. 常见问题与排查思路

实际运行这套流程时，你会遇到很多细节问题。下面几个是最常见的：

这些排查都不是一次性工作。语法工程本身是持续迭代的，LLM 候选质量也会随着模型更新而变化。每一次实验都应该记录模型版本、提示词模板、种子资源版本和评测结果，这样后续出现问题才能回溯。

8. 最佳实践与工程建议

8.1 把 LLM 当作“候选生成器”，而不是“权威判定器”

这句话值得反复强调。LLM 可以快速给出词条、例句和规则解释，但它没有能力保证一套语法系统内部的逻辑一致性。专业语法工程师的价值并不在“知道某个词是什么意思”，而在“知道这个词进入规则后，会不会影响其他词类的处理”。所以，资源入库前必须经过至少一位语法专家确认，尤其是涉及论元结构、语序限制、语义角色这些关键判断时，不能省这一步。

8.2 所有资源都要版本化

语法资源和普通代码没有区别，需要版本管理。每次 LLM 生成的候选、每次人工修改、每次实验评估，都应该有迹可循。文件名里可以加上日期和模型版本，例如canto_lexicon_2025_06_qwen.json，然后通过 Git 维护合并历史。这样即使某次生成内容质量很差，也能快速回滚。

8.3 警惕训练数据污染

很多粤语例句可能已经出现在 LLM 的训练数据里，所以它生成一个合法句子，不一定代表它理解了句法规则。实验设计时，最好准备一部分“不可能出现在公开语料中的新造词”或“人工构造的边际句”，比如把不常见名词放入典型句型，观察 LLM 是否能正确给出论元结构。如果模型在常见句上表现好、在构造句上大幅下降，说明它更多是在记忆而不是推理。这个结论对语法工程尤其重要。

8.4 注意内容安全与版权边界

语法资源建设通常会用到大量例句，LLM 生成例句时可能无意间生成含有冒犯性或隐私风险的句子。尤其是粤语是日常口语，更容易出现不礼貌表达。工程上要加一道“内容过滤”步骤，至少排除明显不文明词汇，并提醒标注人员不要将真实人名、地名写入测试语料。安全边界应该在实验设计阶段就确定，而不是等语料发布后再补救。

8.5 从最小可行语法开始，别想一步到位

一开始不要追求覆盖所有粤语语法现象。先选 3 到 5 个高频、规则清晰的现象，比如完成体“咗”、双宾结构、基本语序，搭建一个 mini 语法，跑通“LLM 生成 → 人工审核 → 入库 → 测试”的完整循环。之后再逐步扩展。这样做的最大好处是，每个环节的问题都能在小范围内暴露，不会等语法库膨胀到几万词条后才发现设计缺陷。

9. 接下来的方向

从项目标题里可以看到，研究者已经把“受控实验评估”和“英语基线”当作默认方法。这比单纯展示几个 LLM 生成的粤语例句要有说服力得多。顺着这个方向，下一步最值得做的是三件事。

第一，建立一个小而完整的粤语金标测试集。测试集应覆盖核心词类、高频句型、典型句末语气词，并且每条句子都要有专家标注的合法性判断和功能结构解释。这个测试集既是语法库的回归测试，也是以后评估 LLM 新版本的基准。

第二，把实验流程包装成半自动管线。从提示词模板、模型调用、输出解析、格式校验，到统计指标，全部用脚本串起来。人工只负责审校最终生成的内容。这样的管线一旦跑通，换一种语言、换一个语法框架，也能快速复用。

第三，针对 LLM 的高频幻觉模式做错误分类。不要只记录“这条错了”，而是记录“错在词类、错在语序、还是错在论元结构”。错误模式积累到一定量后，可以根据错误类型定制修正规则，甚至在提示词中主动加入反例来降低幻觉概率。

回到最初的问题：LLM 对语法工程到底有没有用？答案是肯定的，但它有用在一个很具体的位置——候选生成、文档解释、测试样例扩充。真正的语法决策、规则一致性和资源质量保证，仍然要落在有经验的语法工程师手里。如果你正要开展类似的小语种资源建设，与其焦虑模型能力够不够，不如先把实验评估框架搭好。一个能准确衡量“产出质量”的流程，远比单个惊艳的生成案例更能推动项目稳定前进。