大语言模型：下一代 DSL 编写者

以下正文同步自 InfoQ 中国，版权归原站所有，已转换为易读排版。

向前沿大语言模型索要 Python 代码，你就会得到 Python 代码。向它索要团队自定义的标记语言，你得到的只会是“貌似”标记的东西：凭空发明的关键字、猜出来的参数名以及规范中从未出现过的语法结构——而模型输出这些内容时还一副笃定无误的样子。人们下意识的补救办法是使用更多的提示词、更长的上下文和更好的检索手段。真正的治本之策是在大模型接触到你的语言之前就敲定设计方案：从一开始就不要使用外部语法。这个方案有个名字：类型化领域锚定（Typed Domain Grounding，TDG）。它可以用你现有的类型系统马上落地实现。

大模型能熟练编写 Kotlin、TypeScript、Python 和 SQL 代码，最主要的原因是：这些语言在训练数据中出现了数百万次。粗略来看，语法能力本质上是训练数据出现频次的函数——代码大模型基准测试直接记录了这种关系：按频率和流行度对语言分类，结果显示低资源语言对应的模型表现性能会随之下降[8]。语料密集之处，生成结果更为可靠；语料稀疏之处，生成结果会退化为东拼西凑的模仿，但输出语气不变，看起来依旧信心十足。正因为没有明显的失败信号，这种失败才如此容易被忽略。

从大模型的视角来看，每一门全新设计的外部领域特定语言，其精确语法在训练语料中的出现频次都等于零。尽管如此，大模型通常仍能从它见过的、语法相近的文法、API 和标记符号中继承可迁移的先验知识。但这种迁移并不能解决问题；恰恰相反，它正是下文所说的插值失效背后的根源。

当模型遇到陌生的标记语法时，并不会直接抛出明显的错误，而是会做插值推断。它会悄悄挪用 Mermaid 或 PlantUML 里的箭头语法；调用你的 API “理应存在”但实际并不存在的 addRelation 或 withLabel；或是给只接受两个入参的结构传入三个参数——只因为某个语法相近的同类语法是三参数的。每一处错误都是大模型基于语料算出的最高概率补全，但被用在了语料库里从未出现过的语言上。输出的文本行文流畅、缩进工整，但却是错的。

传统领域特定语言的一个优点反而让这个问题变得更糟：宽松容错。绘图工具与配置解析器在设计上本就具备容错性——遇到无法识别的代码行就直接跳过，按最优猜测进行渲染，对拼写错误不会抛出报错。对人类使用者而言，这是友好的特性；但对于 AI 来说，这就是一个陷阱门。

大模型生成了一张包含十个类的图，其中有一个凭空发明的关系关键字。解析器跳过了那一行。最终进入设计文档的是一张看起来专业、实则缺少一条关联关系的图。

人类如果输入错误，会察觉到问题，因为人类本意就是要建立这个关联关系。但大模型不存在任何意图；下游工程师被九个正确的类和整洁的排版所麻痹，根本不会怀疑这张图是不完整的。

在日常的大模型工程中，“锚定”几乎已经成了 RAG 的同义词。检索相关文档，放入上下文，大模型的输出就能锚定在真实来源上。这是数据空间层面的锚定，用来约束模型对客观世界的描述。但这对我们的问题毫无帮助：即便大模型上下文中的事实完美无误，它仍然可能生成语法凭空捏造的 DSL 语句。

在没有检索的情况下被要求绘制支付系统图，大模型可能让支付服务直接写入账本，而实际上两者之间存在消息队列——语法无可挑剔，内容却是错的。检索可以修复这个问题。但当文档已经放进上下文后，大模型虽然能够正确描述队列这一组件，却会用一种一知半解的标记语法来表达。在这种情况下，内容是对的，标记语法却是错的。再多的检索也无济于事，因为问题根源在于模型对目标语言的掌握能力上，而不在于它的知识。

类型化领域锚定的是另一个维度。它不是把答案的内容锚定在检索到的数据中，而是把标记符号锚定在模型本就懂得如何生成的结构之中——也就是锚定能力空间。两者是正交的，可以很好地组合在一起：通过 RAG 检索事实，再通过类型化、编译器检查的 DSL 来表达它们。

在图 1 中，RAG 在数据空间对回答的内容进行锚定。TDG 则在能力空间对语言进行锚定——两者是正交、可组合的流水线，而非竞争者。

这条原则可以浓缩为一句话：“永远不要发明大模型从未见过的语法：将领域逻辑嵌入它已经熟悉的语言，让编译器充当判定权威。”

将领域逻辑实现为主流宿主语言中的内部 DSL，不需要新语法，也不需要定制的解析器。那些读起来像是专用语言的代码，本质上就是普通的宿主语言代码，因此现有的工具链（高亮、补全、跳转到定义、安全重命名、调试器，以及评审者熟悉的 diff）都是开箱即用——如果从零自研这些能力，每一项都可能是耗时数年的工程。

经典的嵌入式 DSL 相关文献（如 Paul Hudak 和 Martin Fowler 的著作）会权衡表达能力、类型系统强度和工具生态。TDG 增加了一个在 LLM 出现之前不可能存在的评判标准：语料覆盖度。Kotlin、TypeScript 或 Python 自带充足的先验生成能力，无需额外投入。前沿实验室不会公开精确的训练数据配比，但这套论证只需关注差距本身即可。任何主流语言在公开代码中的样本量都远高于一门全新 DSL 所能达到的水平。一门优雅但小众的语言则几乎没有这类优势。这些评判标准通常方向一致，但当它们产生分歧时，语料覆盖度就拥有一票话语权。

设计 API 时，要让领域错误表现为类型错误：优先使用命名参数而非位置参数，用枚举替代魔法字符串，构造器作用域只暴露当前上下文内合法的构造。密封类型层次结构可以让 API 限定关系端点只能是四类中的一种，模型若幻觉出第五种变体，就不存在对应的类型。接收者类型可以控制代码块内可见的函数集合。在类体外部写 attribute(...) 会直接触发名称解析失败。非法嵌套直接变成这门语言无法表达的语句。这里的严格性是实现手段，而非吹毛求疵。

大模型生成，编译器检查，诊断信息回流形成修复提示词。编译器反馈修复循环在自调试相关文献中已有充分论述 [1]——GCR 本身并不是 TDG 的创新点。TDG 创新的地方在于让这个熟悉的循环同时提供了两个用途：一是作为修复通道，用于修复损坏的输出；而是作为测量工具，统计某条 DSL 需要修复的频次，并定位其根本原因。修复提示词携带出错的代码片段、完整的诊断信息和源代码位置，使得有针对性的编辑成为可能，而不是盲目重新生成——后者只是从产生错误的那个分布里重新采样。这个循环是有边界的，在 kUML 的设置中最多尝试三次。如果能够成功修复，往往前几次就解决。一个在三次反馈后仍然失败，说明它缺失相关业务概念，而不是仅仅丢了一个逗号。

嵌入式 DSL 解决了语法问题，但还有词汇层面的问题：存在哪些构造项、它们叫什么名字？如果把完整的 API 文档塞进每一个提示词里，会把五个相关构造项淹没在九十五条无关内容中。TDG 的解决方案是：让模型在生成过程中可以查询可调用的工具——例如可以实现为 MCP 服务器——它返回少量经过筛选、验证可用、能够直接编译的示例，且恰好匹配模型当下所需的构造项，而非一股脑返回海量无关文档。效果提升十分显著：在 kUML 的实验中，kuml.examples工具将 SysML v2 图的一次编译通过率从 25% 提升至 87.5%。

构建块 1–3 构成 TDG 方案的核心定义，而构建块 4–5 则是让 TDG 落地实例在实际场景中拥有良好表现的配套能力。它们是互补的，而非 TDG 的必要定义项。对比其他技术思路，TDG 不是检索增强生成（见上文）——它锚定的是语言，而不是事实。此外，TDG 也不像某些面向 LLM 的语法提案那样设计新语法。相反，它选择一种现有的且训练数据充足的语法，让该语言的编译器来做检查。下面的两个示例展示了这种方法在实践中的样子，图后会展开和相关研究工作的完整对比。

kUML 是一种嵌入 Kotlin 的建模语言，可用于绘制 UML、SysML v2 和 C4 图表。它是迄今为止指标度量最完备的 TDG 实现。

classDiagram(name = "Order") { val customer = classOf(name = "Customer") { attribute(name = "customerId", type = "String") } val order = classOf(name = "Order") { attribute(name = "date", type = "LocalDate") operation(name = "cancel") { returns(typeName = "Boolean") } } association(source = customer, target = order) { source { multiplicity(spec = "1") } target { multiplicity(spec = "0..*") } }}

复制代码

对大语言模型而言，这就是普通的 Kotlin 代码：接收者 lambda、命名参数、普通变量引用，这些构造都是大模型从训练数据里海量公开 Kotlin 代码库中学到的。建模领域能力建立在模型本就掌握的语法之上。

即便模型仍然产生幻觉——例如它虚构了一个聚合关系（如 source = customer、target = order），在顶层作用域（关联代码块之外）调用该语句时，Kotlin 编译器会返回带精确位置的报错信息。如果用 PlantUML 或 Mermaid 写出同样的幻觉内容，宽松的渲染器大概率依旧会生成一张图，只是悄悄丢失部分元素。

这个虚构的 aggregation(...) 调用会直接在 IntelliJ IDEA 编辑器中被标记出来，实时预览面板会即时提示“无法解析引用 ‘aggregation’”——用户还在输入的过程中，编译器就已经变成了判定预言机。

幻影引用也会以同样方式被拦截。假设大模型写出关联语句（例如 association(source = order, target = invoice)），但始终没有声明 invoice 这个分类器。在 kUML 中，图元就是普通的 Kotlin 变量。因此“存在哪些模型元素”就是变量解析问题。编译器会在精确的行列位置抛出错误：Unresolved reference (invoice)，并自动生成修复提示词。如果把同样的幻影引用放到宽松的基于命名的标记语法中，后果比静默失败更糟：不少绘图工具会在连线引用某个节点时自动帮你创建这个节点。被幻觉出来的 invoice 不会被丢弃，反而升格成一个真实的空类，而它根本不存在于任何需求规范中，看起来却和其他合法元素一样合法。一个工具链把幻影引用转化为带位置的报错；另一个工具则把幻影变成了图里的摆设元素。

为了表明 TDG 是一个原则而不是 kUML 的特性，需要在领域之外检验该模式是否可推广——这就需要基础设施定义场景作为例子。本小节是一个思想实验，并不是第二个实测结果。目标是论证架构层面的可泛化性，而不是额外的实证证据。Terraform 的 HCL 是一个外部 DSL，只不过它的训练语料相对充足。模型很少会写错它自身的块语法，问题出在下一层：属性名称与各类资源类型的结构属于提供者 schema，而不是语言本身的语法。

模型在编写aws_s3_bucket代码块时只能凭记忆猜测那些印象模糊、随版本发生变更的属性。不过 Terraform 好在可以在本地捕获这类问题。terraform validate 命令与 Terraform 语言服务器（terraform-ls）会根据从已安装插件拉取的提供者 schema 校验属性名、类型和引用，无需调用云 API。这项校验本身就很能说明问题：为外部 DSL 实现这套能力需要一整套复杂的机制，包含 schema 分发、独立校验阶段和语言服务器，而嵌入式 DSL 因为宿主语言编译器从一开始就有了同等能力。Terraform 云开发工具包（CDK for Terraform）已经可以为五种语言生成带类型约束的提供者绑定[2]，这正是将 TDG “选用宿主语言”思路应用到基础设施领域的案例。但无论是 HCL 还是带类型的 DSL，本地校验都无法触及 schema 之下的那一层问题：比如 AMI 镜像是否真实存在、你是否拥有对应权限、配额是否充足。这类信息只有在程序和真实云 API 交互时才能获取。

现在设想用同样的基础设施作为一个类型化的 Kotlin DSL。这是一个思想实验，不是一个已经存在的库——思路与 Pulumi、AWS CDK 和 CDK for Terraform 在其他语言中提供类型绑定的做法一脉相承[2]，只不过这些工具目前都没有发布官方 Kotlin SDK。

// 思想实验 —— 并非现有库，用于在建模之外的领域演示 TDG 原理val assets = s3Bucket(name = "assets") { versioning = Versioning.ENABLED encryption = ServerSideEncryption.AES256}lambdaFunction(name = "thumbnailer") { runtime = Runtime.JAVA_21 memoryMb = 512 trigger = s3Trigger(bucket = assets, event = S3Event.OBJECT_CREATED)}针对该设计的四类经典幻觉：- 编造属性（例如使用 encryptionMode，而非合法属性 encryption）→ 触发编译错误，列出真实可用的属性名。- 值类型错误（例如写成 memoryMb = "512MB"）→ 在任何工具执行前就触发类型错误。- 引用从未声明的存储桶 → 判定为未定义变量，并精确定位出错代码行。- 使用 S3 不存在的触发器事件 → 由 S3Event 枚举校验而不会当作普通字符串直接放行。

复制代码

图 3 展示了同样的四类幻觉。Terraform 可在本地通过 terraform validate /terraform-ls 以及文中所述的提供程序 schema 机制捕获这类问题。类型化的 Kotlin DSL 则可通过原生编译器就能以相同方式捕获它们。

在原生 Terraform 中，这四类问题同样可以在本地被拦截，依靠的还是这套 schema 机制。而在类型化版本里，它们会作为普通编译错误直接报错：不需要协议、无需单独的校验阶段，也不用构建和维护语言服务器。还有一个问题仍然存在：哪一种校验机制能够跟得上真实运行的 API（保持同步更新）？

在这一点上，两种方法是对称的，没有哪个是赢家：terraform validate 根据锁文件中固定的提供程序版本执行校验，类型化 DSL 则根据构建文件中固定的 SDK 版本执行校验——任何一个固定版本都有可能悄悄落后于实时的 API。在这两者之下还有一层：云端实时状态（例如资源是否存在、权限、配额），它们对 HCL 和 Kotlin 同样不可见，直到调用了 API。嵌入式 DSL 的优势并不比 Terraform 的校验机制做更多检查；它是以近乎零增量成本实现同等校验，并且输出的形式（编译器诊断信息）最适合修复迭代流程。该模式可以推广到任意具备以下条件的领域：拥有类型化内部 DSL、支持快速批处理的编译器以及训练数据充足的宿主语言。Gradle 的 Kotlin DSL、compose 风格的 UI 构建器以及替代无 schema YAML 的类型化配置 DSL 都属于这类场景。

TypeScript 类型作为响应 schema，编译器诊断信息则作为修复提示词。TDG 用于校验数据结构（即响应 schema）。TDG 内置完整的领域语言，支持语义定义和工件生成。

把目标 DSL 的 BNF 语法输入上下文。TDG 的区别在于：它缓解外来语法问题的方式是建设性地消解它，无需额外学习外部语法。

类型化 DSL 作为语义解析的目标语言。TDG 的区别在于：它是一个外部 DSL，有自己的语法——而这恰恰是 TDG 所要规避的设计。

为大模型设计一种全新、token 占用更少的语法（例如衍生自 Python 的 SimPy，并非同名仿真库）。TDG 的区别在于：它不设计新语法，而是选择一种现有的、训练数据充足的语法。

把事实锚定在响应中（数据空间）。TDG 的区别在于：它在语言空间中完成锚定（正交且可组合）。

带有编译器反馈的修复循环（即自调试、自修复）。TDG 的区别在于：它把修复循环视为支撑性的构建块和测量工具，而不是自身的核心创新点。

与 TDG 最相近的是 TypeChat[3]。两者都使用主流类型系统进行合法性校验，并把诊断信息反馈给大模型，但 TypeChat 验证的是答案是否符合接口规范：情感分析结果是正面、负面还是中性，提取的对象是否有正确的字段。TDG 则把领域变成一个带有语义和下游工件生成的语言，检查的是响应 schema 永远看不到的东西：一个关联关系是否连接了真实存在的分类器，一个转换是否位于状态机内部。TypeChat 解决的是“这个答案的结构是否正确”，而 TDG 解决的是“这是否是领域内合法的语句？”——后者是更丰富的校验问题，并且由同一套编译器机制完成校验。

语法提示[4]和面向 AI 的语法方案[6]都接受了 TDG 并不认同的前提：必须存在一种新语法。一个在运行时将文法送入模型上下文，一个设计了一种更具 token 效率的语法，但语料频率仍为零，因此能力短板依旧存在，必须通过额外教导模型来弥补。TDG 解决的是“如何教会模型一套外部语法”之前的问题：为什么非得要有外部语法？ThingTalk[5] 就是一个值得警惕的例子——它有完善的类型系统，却仍然是外部 DSL，依旧存在训练数据不足的问题。

在一个包含 50 项任务的基准测试中，将 kUML 与 PlantUML、Mermaid 进行对比。这套带编译器校验的嵌入式语言搭配 GCR 循环，在使用 Claude Sonnet 5 时取得了最高的结构保真度（45.3%，对比 PlantUML 的 37.9% 与 Mermaid 的 37.4%）以及最低的幻觉率（15.4%，对比 PlantUML 的 16.5% 与 Mermaid 的 21.9%）。测试任务涵盖 UML、SysML v2 和 C4 图表类型，每一项都锚定到一个源规范。根据结构保真度（即与该规范的节点集和边集相似度，不做更深层次的语义检查）和幻觉率来评分。模型会生成大量规范文档中并未要求的内容。这两项指标需要联合起来看。一个工具工具可以通过输出所有看似合理的内容来伪造较高的保真度，而幻觉率指标恰好可以识别这类手段。

公开示例库目前包含在同一套 GCR 测试框架下完成的九组模型运行结果。整体表现相比摘要里给出的单一指标更依赖模型本身。使用 Claude Sonnet 5 和 GPT-4o 实现了全面优势：结构保真度更高、幻觉率更低，但该优势并不能在所有模型上普遍成立。Gemini 2.5 Flash、Gemini 2.5 Pro 在 Mermaid 或 PlantUML 结构保真度指标上表现领先；Qwen3-Coder:30B 也呈现出同样的趋势。Grok 4 为 kUML 给出的结构保真度是所有测试里最低的（36.8%，对比 34.6% 与 36.4%），同时幻觉率却是最高的（28.1%，对比 22.4% 与 23.0%）。

这些效应是真实的，并在多个模型系列上可复现，在本文深入讨论的两个模型上效果最为突出，但并非所有被测模型都能呈现该特性。本文摘要指标的适用范围客观来讲仅限于 Claude Sonnet 5。整个评分过程完全采用算法自动计算，而非依靠大模型或人工评审。表格中每一项结果都对应单次生成任务，最多允许三轮 GCR 修复尝试，并非多次采样后的平均值。单次运行结果无法给出方差估计，因此上面的差值仅为方向性证据；当指标差距较大且在多个模型系列上趋势一致时证据力度最强。全部九组实验的分模型详细结果可在公开基准测试示例库查看（例如 kuml.dev/benchmark-gallery）。

该基准测试并未显示 Claude Sonnet 5 在首轮生成时拥有更高的编译通过率。与之相反，kUML 的首轮编译成功率实际上低于宽松型工具的首次尝试成功率。这种不对称性正是关键所在：严格的预言机前期会拦截更多错误，并且该行为与后续更高的结构保真度、更低的幻觉率存在相关性。这种相关性可以直接在基准实验中得到验证，但并不能证明是“拦截——修复”机制本身造成了指标差距（也有可能是三种标记语法之间存在其他差异）。这是最简洁合理的解读，并非独立的因果验证实验。示例引导机制进一步放大了该效果：在提供 kuml.examples 的前提下，仅使用 Claude Sonnet 5、每组单次运行，SysML v2 在修复循环后的编译通过率从 25% 提升至 87.5%，也就是 8 项任务中从 2 项编译成功提升到 7 项。这是编译层面的结果，不等于保真度结果。完整的详细数据可查阅公开的方法说明页面。

直白说明这一局限：TDG 解决的是语法层面的缺陷，而非模型理解能力的不足。模型完全可以生成能够顺利编译但实质内容错误的模型。在同一基准测试中，有一个模型在 C4 架构图任务上的语义理解始终很肤浅，即便编译器没有检出任何问题。所有构造都符合语法规范，但架构本身却很单薄。这套预言机只检查形式合法性，不评判内容优劣。TDG 是把优质模型变成可靠的产出者，而不是把能力薄弱的模型变成优秀的架构师。

首先考虑外部语法问题——不是因为嵌入式 DSL 总是更优，而是因为这个问题值得给出明确回答，不能习惯性直接跳过：为什么不采用 Kotlin/TypeScript/Python 的构建器 API？

在选择宿主语言时，将训练数据亲和性与类型系统能力、生态成熟度放在同等地位，作为选型标准。

有意识地设计编译器的严格性：使用具名参数、用枚举替代字符串、采用上下文作用域的构造器——每一个都决定着哪一类幻觉会被转为编译错误，哪些则无法被检测。

把诊断信息视为一个接口：精确的源代码位置、命名的期望值、可解析的输出——这些决定了修复循环收敛的速度。

构建教学通道：采用经过筛选、CI 校验、可直接调用的示例，其效果优于静态塞进提示词里的文档。

摒弃宽松校验模式。要认识到：静默“修复”格式错误的输入是预言机的一个漏洞，而不是一种友好特性，因此默认应当严格报错、明确失败。

内部 DSL 看起来像宿主语言。例如，classDiagram(name = "Order") { ... } 的可读性不如一种专门设计的紧凑符号——不过一旦图表被渲染，DSL 源码通常不再是主要阅读载体。

多年投入、已经可用的外部 DSL，不应当直接废弃。TDG 面向的是新领域语言或新模式，而不是本季度就要进行的迁移改造。

用户需要宿主工具链，并且（对人类而言）还需要具备阅读该语言的能力。对于已经在这套生态里工作的团队，该绑定不会带来额外开销；但对于从未接触过 Lambda 表达式的领域专家群体，这是一笔实实在在的入门成本。

作为回报，你得到了一个完整的编译器、IDE、重构工具链和幻觉判定预言机——这些你都不需要从零开始开发，并且未来大概率会使用这套系统的编写者本来就熟悉它们。对于越来越多的领域而言，这笔取舍的收益明显偏向 TDG，但它终究是一种权衡。

DSL 设计长期以来都在探讨一门语言可以多大程度贴合领域语义与人类阅读者。如今出现了第二个问题，它成为一个独立的设计维度，并非用来替代原有问题，也不代表在所有场景下二者地位均等：这种语言与未来最主要的编写者已有的能力有多贴近？它的工具链可以免费提供多少校验能力？如果 DSL 的主要编写者仍然是人类领域专家，那么传统的可读性问题依旧占据主导；倘若 DSL 越来越多地由大模型生成、读取，第二个问题的权重就会相应提升。同时认真考量这两点的设计者，最终构建出的语言能够让幻觉不再是输出结果里悄无声息的虚影，而是编辑器中的红色下划线。本文提出的方案无需等待未来的研究突破：宿主语言、编译器以及示例引导协议在当下均已可用。

X. Chen, M. Lin, N. Schärli, D. Zhou: "Teaching Large Language Models to Self-Debug." arXiv:2304.05128, 2023; and T. X. Olausson, J. P. Inala, C. Wang, J. Gao, A. Solar-Lezama: "Demystifying GPT Self-Repair for Code Generation." arXiv:2306.09896, 2023

Pulumi (pulumi.com), AWS CDK (aws.amazon.com/cdk), CDK for Terraform (developer.hashicorp.com/terraform/cdktf) infrastructure definition in general-purpose languages with typed provider SDKs. None currently ships an official Kotlin SDK; the Kotlin example in this article is a thought experiment, not an existing library.

Microsoft: TypeChat. GitHub repository, 2023. https://github.com/microsoft/TypeChat

B. Wang, Z. Wang, X. Wang, Y. Cao, R. A. Saurous, Y. Kim: "Grammar Prompting for Domain-Specific Language Generation with Large Language Models." NeurIPS 2023. arXiv:2305.19234

G. Campagna et al.: "Genie: A Generator of Natural Language Semantic Parsers for Virtual Assistant Commands." PLDI 2019 (ThingTalk as the typed target language; see also arXiv:2203.12751)

Z. Sun, X. Du, Z. Yang, L. Li, D. Lo: "AI Coders Are Among Us: Rethinking Programming Language Grammar Towards Efficient Code Generation." ISSTA 2024. arXiv:2404.16333

X. Ye, R. Sun, S. Ö. Arık, T. Pfister: "Effective Large Language Model Adaptation for Improved Grounding" (AGREE). Google Research, NAACL 2024. arXiv:2311.09533

F. Cassano et al.: "MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation." IEEE Transactions on Software Engineering, 2023. arXiv:2208.08227

查看英文原文：https://www.infoq.com/articles/next-dsl-author-language-model/

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。