FME与AI：AI Assist能生成SQL、Python和Regex，但同一个需求（比如“提取瑞典邮编”）换一种问法就可能得到不同的表达式，有些能跑、有些边界情况直接崩——怎么在FME工作流里为AI生成的表达式设计一套可复用的“输入-预期输出”验证样例，而不是靠肉眼看一遍就上线？

目录

一、问题的本质：生成式表达式为什么“看起来对”却“跑不稳”

1.1 一个真实的工作场景

在 FME Form 的属性管理器中，用户可以对某个属性写条件值、可以用 StringReplacer 配正则、可以在 SQLCreator 里写查询、也可以用 PythonCaller 写一段处理逻辑。AI Assist 的介入点在于：用户用自然语言描述意图，工具给出候选表达式。比如“提取瑞典邮编”，AI 可能给出 \b\d{3}\s?\d{2}\b，也可能给出 SE-?\d{3}\s?\d{2}，还可能给出带捕获组的版本。这些表达式在“标准样例”上都能跑通，但一旦遇到 114 55（斯德哥尔摩市区）、SE-11455、752 63（乌普萨拉），甚至地址串里混入的房号 114 55 lgh 1201，结果就可能出现漏提、误提、截断。

这不是 FME 独有的问题，而是所有“自然语言到形式化表达式”的生成场景共有的问题。笔者在多个数据工程项目中观察到的规律是：生成式表达式的失败模式高度集中在边界与上下文，而不是主干逻辑。主干逻辑（“三位数字加空格加两位数字”）几乎总能被正确表达，真正决定上线成败的是那些“不标准但合法”的输入。

1.2 为什么“换一种问法就换一个答案”

大语言模型在生成表达式时，本质上是在一个巨大的表达式空间里做条件采样。提示词是条件，采样有随机性（即使温度设为零，不同措辞也会改变条件分布），因此同一语义的不同表述会落到不同的“表达习惯”上。这在学术上早有讨论：Chen 等人在 2021 年的 Codex 论文中就指出，代码生成模型对提示措辞高度敏感，同一功能的不同描述会显著改变生成结果的正确率（Chen et al., 2021, Evaluating Large Language Models Trained on Code）。后续的 HumanEval、MBPP 等基准也反复验证了这一点。

本文评述：把“换问法换答案”当成模型的缺陷去抱怨，是没有工程意义的。更有效的视角是把它当成“供应商不确定性”——你从外部拿到一个黑盒产物，你不能假设它稳定，你只能通过验收来约束它。这正是软件工程里“契约测试（contract testing）”的原始动机：消费者与提供者之间用一组可执行的期望来定义边界，而不是靠信任。

1.3 从“评审”到“裁决”：一个视角切换

传统做法是“肉眼看一遍就上线”。这在低风险场景可以接受，但在批量数据处理里风险被放大：一个正则漏提 0.5% 的记录，在百万级数据上就是五千条错误，而且往往在 downstream 报表出错时才被发现。笔者主张的视角切换是：把 AI 生成的表达式视为“待验收的交付物”，把样例集视为“验收标准”，把自动化执行视为“验收动作”。评审（人看）可以保留，但它不再是唯一防线，而是样例集之外的补充。

二、把需求变成契约：需求卡与“输入-预期输出”三元组

2.1 需求卡：先固化“要什么”，再讨论“怎么写”

很多验证失败的根源不在样例，而在需求本身就没说清。比如“提取瑞典邮编”，到底是从自由文本里抽取，还是校验一个已经是邮编格式的字段？是要求返回第一个匹配，还是返回全部匹配？大小写、空格、连字符如何处理？这些歧义如果不在需求层解决，样例就无法设计。

笔者建议为每个 AI 生成表达式建立一张“需求卡”，至少包含以下字段：

笔者认为：需求卡的价值不在于形式，而在于它强迫团队在写第一行正则之前就把“什么算对”说清楚。这一步做扎实，后面的样例设计几乎是机械劳动；这一步糊弄，样例集就会变成一堆互相矛盾的期望。

2.2 三元组：输入、预期输出、判定规则

一个可执行的验证样例，最小结构是三元组：(input, expected, comparator)。前两者是数据，第三者是比较器。很多团队只写了前两者，结果在“预期输出是 null”还是“空字符串”上反复扯皮。比较器必须显式化，常见的有：

• 精确相等：适用于规范化后的字符串、整数。
• 集合相等：适用于“返回全部匹配”的场景，顺序无关。
• 正则匹配：适用于输出格式固定但内容有合法变体的场景。
• 空值语义：显式区分 null、空串、缺失字段。
• 容差比较：适用于浮点或坐标，需给出 epsilon。

把比较器写进样例，是这套方法区别于“随手记几个测试用例”的关键。它让样例从“参考”变成“契约”。

三、样例怎么设计：等价类、边界值、对抗样例与属性测试

3.1 等价类划分：先保证“面”覆盖

等价类划分是软件测试的经典方法（Myers, The Art of Software Testing, 1979）。对“提取瑞典邮编”而言，输入可以划分为：标准格式（114 55）、紧凑格式（11455）、带国家前缀（SE-114 55）、嵌入地址（Sveavägen 1, 114 55 Stockholm）、无邮编、含相似数字串（如电话、房号）。每个等价类至少一个样例，这是“面”的覆盖。

本文评述：等价类划分在生成式场景里尤其重要，因为 AI 往往只对“最典型”的表述敏感。你给它一个标准样例，它给你一个标准答案；你给它一个嵌入地址，它可能就抓错。等价类的作用是把“典型”之外的类也纳入验收范围。

3.2 边界值：失败高发区

边界值分析针对的是“刚好在边界上”的输入。对邮编提取，边界包括：字符串开头就是邮编、结尾就是邮编、邮编前后紧贴字母、多个邮编相邻、长度刚好 5 位但含非数字、长度 6 位但前 5 位合法。笔者在实践中发现，AI 生成的正则最常崩在“前后紧贴字母”和“多个候选相邻”这两类边界上，因为 \b 的词边界语义在含瑞典语字母时并不总是符合直觉。

3.3 对抗样例：主动找茬

对抗样例是“看起来像但不是”的输入，用来暴露误提。例如 114 55 67（可能是电话）、2024 12（可能是日期）、SE-114 55 12（邮编后跟房号）。对抗样例的预期输出通常是 null 或明确的“只取第一个”。这类样例最能区分“能跑”和“跑对”。

3.4 属性测试：从“点”到“性质”

属性测试（property-based testing）由 QuickCheck 引入（Claessen & Hughes, 2000），核心思想是不枚举具体样例，而是声明“对所有合法输入都应成立的性质”，由框架生成大量随机输入去验证。对邮编提取，可以声明的性质包括：

• 幂等性：对已提取出的 5 位数字再跑一次，结果不变。
• 长度不变式：任何非 null 输出，长度恒为 5。
• 字符集不变式：输出只含数字。
• 嵌入不变式：把合法邮编嵌入任意前后缀文本，仍能被提取。

属性测试的工程价值在于它能覆盖人工想不到的组合。笔者建议在样例集里保留一组“手工精选”的确定性样例作为门禁，同时用属性测试做补充扫描，两者互补。

四、以“瑞典邮编”为例：从需求到样例集的完整推演

4.1 背景事实与数据来源

瑞典邮编为 5 位数字，常见书写形式为“123 45”，即三位加空格加两位。这一格式由 PostNord（瑞典邮政）公开说明，其官方页面明确邮编由 5 位数字组成、书写时在第三位后加空格。笔者在本文中使用的样例均基于该公开格式规则构造，属于模拟数据，不对应任何真实个人地址；其中城市与邮编段的对应关系参考了公开的邮编区间资料，仅用于说明格式，不作为地理编码依据。

4.2 样例集（节选）

注意 A-01 与 B-02 的区别：2024 12 的“2024”不是合法邮编段（瑞典邮编首位通常为 1-9，且 2024 段并非有效分配），而 114 55 67 的前 5 位是合法邮编。这类区分需要业务知识，不能只靠正则形状判断。这也是为什么样例设计必须由懂业务的人参与。

4.3 同一个需求、三种 AI 输出，样例集如何裁决

假设 AI 给出三个候选正则：

R1: \b\d{3}\s?\d{2}\b
R2: (?:SE-)?(\d{3})\s?(\d{2})
R3: (?<!\d)\d{3}\s?\d{2}(?!\d)

用上面的样例集跑一遍（模拟推演，非真实工具输出）：R1 在 C-04 上可能因 \b 与瑞典语字母的交互而漏提；R2 在 C-02 上因要求空格可选但捕获组拼接逻辑需额外处理；R3 用负向环视，在 B-02 上能正确只取前 5 位，但在 A-01 上仍会误提。结论是：没有哪个候选在所有样例上全对，样例集的作用是让差异显性化，而不是选出“最好的一个”。工程上通常的做法是：选一个通过率最高的，再针对失败样例做人工修补，修补后重新跑全量样例。

这里的关键认知是：样例集不是用来“证明 AI 对”，而是用来“发现 AI 错”。发现错误本身就是价值。

五、工程落地：目录结构、命名规范与版本化

5.1 目录结构

样例集要可复用，首先要有稳定的存放位置和命名。笔者推荐如下结构（与 FME 工作流仓库同仓管理）：

fme-ai-contracts/
├── requirements/
│   └── REQ-POSTAL-SE-001.md      # 需求卡
├── fixtures/
│   └── REQ-POSTAL-SE-001/
│       ├── cases.csv             # 输入/预期/比较器
│       └── adversarial.csv       # 对抗样例单独存放
├── expressions/
│   └── REQ-POSTAL-SE-001/
│       ├── r1_regex.txt
│       ├── r2_regex.txt
│       └── CHANGELOG.md
├── runners/
│   ├── run_fme_workspace.py      # 调用 FME 工作流执行
│   └── run_pytest.py             # 纯 Python 侧执行
└── reports/
    └── REQ-POSTAL-SE-001/
        └── latest.json

把需求、样例、表达式、执行器、报告分开放，是为了让“换实现”不影响“契约”。当 AI 给出新版本表达式时，只替换 expressions/ 下的文件，样例集不动，跑一遍就知道有没有回归。

5.2 命名规范

样例编号建议采用“类别前缀-序号”的形式：C 标准、B 边界、A 对抗、E 空/异常、P 属性。这样在报告里一眼能看出失败集中在哪一类。笔者见过不少团队用 test1、test2 命名，结果半年后没人知道每个用例在测什么，样例集迅速腐化。

5.3 版本化与变更记录

样例集本身也要版本化。当业务规则变化（比如瑞典邮政调整了某邮编段），样例的预期输出要改，这时必须在 CHANGELOG 里记录“为什么改”，否则下一次回归会分不清是表达式退化还是样例更新。笔者建议把样例集纳入 Git，用 PR 流程管理变更，与代码同等对待。

六、自动化执行：FME 工作流内验证与 Python 侧 pytest 双轨

6.1 为什么需要双轨

FME 工作流内的验证贴近真实运行环境，能覆盖转换器行为、属性类型、空值语义；Python 侧的 pytest 验证快、易集成 CI、便于属性测试。两者不是替代关系，而是分工：pytest 做快速回归和属性扫描，FME 工作流做端到端验收。只做前者，可能漏掉 FME 特有的类型转换问题；只做后者，跑得慢、难并行、难做大规模随机测试。

6.2 FME 侧：用 WorkspaceRunner 或 Python 调用

FME 提供了多种自动化入口。最直接的是把验证逻辑做成一个独立的 FME 工作流：读入 cases.csv，对每行执行待测表达式，把结果与预期比较，输出 pass/fail 报告。待测表达式可以通过参数传入，避免为每个候选表达式复制一份工作流。FME 官方文档中关于 WorkspaceRunner 与参数化运行的说明可作为参考（Safe Software, FME Documentation: WorkspaceRunner）。

如果团队已经在用 FME Server 或 FME Flow，可以把验证工作流发布为服务，由 CI 触发运行，结果以 JSON 回传。这样验证动作与生产运行共享同一套转换器版本，减少“本地能跑、服务器不能跑”的环境差异。

6.3 Python 侧：pytest 参数化

对于正则和纯字符串处理，完全可以脱离 FME 在 Python 侧验证。pytest 的 @pytest.mark.parametrize 天然适合“输入-预期”表驱动测试。示意代码：

import re, csv, pytest

def load_cases(path):
    with open(path, encoding="utf-8") as f:
        return list(csv.DictReader(f))

CASES = load_cases("fixtures/REQ-POSTAL-SE-001/cases.csv")

@pytest.mark.parametrize("case", CASES, ids=[c["id"] for c in CASES])
def test_postal(case):
    pattern = open("expressions/REQ-POSTAL-SE-001/r3_regex.txt").read().strip()
    m = re.search(pattern, case["input"])
    actual = m.group(0).replace(" ", "") if m else None
    if case["comparator"] == "null":
        assert actual is None
    else:
        assert actual == case["expected"]

这段代码刻意保持简单，目的是让样例集成为唯一的事实来源。真实项目里还需要处理编码、多匹配、捕获组拼接等细节，但结构不变。

6.4 属性测试的接入

Python 生态里 Hypothesis 是属性测试的主流库（MacIver et al., 2019）。可以声明“任意合法 5 位数字串，经格式化后应能被提取回原值”这样的性质，让框架生成大量输入。注意属性测试的失败用例要能自动最小化并沉淀为确定性样例，否则每次跑都换一批失败输入，难以复现。

七、接入 CI：把样例集变成上线门禁

7.1 门禁规则

门禁规则要简单可执行，笔者推荐三条：

1. 全量确定性样例必须 100% 通过，任何一条失败阻断合并。
2. 属性测试连续运行 N 次（如 1000 次生成）无失败，失败则阻断。
3. 新增需求必须附带至少 5 条样例（含 1 条对抗），否则 PR 模板检查不通过。

第三条容易被忽视，但它是防止样例集“只减不增”的关键。没有强制新增，团队会倾向于复用旧样例，覆盖逐渐与业务脱节。

7.2 流水线形态

典型的流水线是：提交触发 → 静态检查（表达式语法）→ pytest 快速回归 → FME 工作流端到端 → 报告归档。FME 侧如果耗时较长，可以设为“合并前必须通过、日常提交仅跑 pytest”的分级策略。GitHub Actions、GitLab CI、Jenkins 都能承载，关键是报告要可追溯：每次运行记录表达式版本、样例集版本、通过率、失败用例 ID。

八、度量与治理：覆盖率、变异测试与样例腐化

8.1 样例覆盖率

“覆盖率”在这里不是代码行覆盖，而是“输入域覆盖”。可以用等价类清单做检查表：每个等价类是否至少一条样例、每个边界是否覆盖、对抗样例占比是否达标。笔者建议把等价类清单直接写进需求卡，评审时对照打勾。

8.2 变异测试：检验样例集本身的质量

变异测试（mutation testing）的思路是：对表达式做小的、语义可能改变的修改（如把 \d{3} 改成 \d{2}、把 \s? 改成 \s），看样例集能否“杀死”这些变异体。杀不死的变异体说明样例集在该维度上存在盲区。这一方法在传统软件测试中已相当成熟（Jia & Harman, 2011），迁移到表达式验证同样适用。

笔者认为：变异测试是这套框架里最容易被低估的一环。大多数团队只关心“表达式对不对”，不关心“样例集够不够狠”。而后者决定了这套机制在长期是否还有效。

8.3 样例腐化与定期复审

样例集会随时间腐化：业务规则变了样例没改、数据源格式变了样例没覆盖、旧样例对应的输入在现实中已不存在。治理手段包括：每季度复审一次样例集、把长期未触发的样例标记为“待确认”、把生产中发现的新失败模式回灌为样例。最后一条尤其重要——生产事故的每一个根因，都应该变成一条新的样例，这是让验证体系随业务进化的唯一可靠方式。

九、前沿观察：LLM 代码评测研究对空间数据工程的启示

9.1 从 HumanEval 到“执行反馈”

LLM 代码生成领域过去几年积累了大量评测方法。HumanEval（Chen et al., 2021）用“函数签名 + 文档字符串 + 单元测试”的形式评测生成代码，pass@k 指标衡量“生成 k 个候选里至少一个通过”的概率。后续研究进一步引入执行反馈、自修复循环（如 Self-Debugging，Chen et al., 2023），让模型根据测试失败信息迭代修改。这些工作的共同点是：用可执行测试作为生成质量的最终裁判，而不是用另一个模型去“感觉”对不对。

本文评述：空间数据工程场景与 HumanEval 有相似之处，也有重要差异。相似在于“输入-输出”可判定；差异在于空间数据的输入域更开放（地址文本、坐标系、编码），且很多错误不是“抛异常”而是“静默错值”。这意味着直接套用 pass@k 不够，需要更强调对抗样例和属性不变式。

9.2 测试生成与“以测促生成”

近期不少工作研究用 LLM 自动生成测试用例（如 TestPilot、ChatUniTest 等方向），思路是让模型同时生成实现和测试。这在效率上有吸引力，但存在一个根本风险：如果测试和实现出自同一个模型、同一段上下文，测试很可能继承实现的盲区。笔者对此持谨慎态度：在数据工程这种“错值代价高”的场景，样例集应尽量由独立于生成过程的人或流程产出，LLM 可以辅助扩写，但不能作为唯一来源。

9.3 对 FME 场景的迁移建议

把上述研究迁移到 FME + AI Assist，笔者认为有三条可操作建议：其一，建立组织内部的“表达式评测集”，类似领域版 HumanEval，覆盖常见转换器（StringReplacer、AttributeCreator、SQLCreator）的典型需求；其二，把执行反馈接入提示流程，AI 生成后自动跑样例、把失败信息回喂，形成小循环；其三，对高风险需求（涉及金额、地址、合规字段）强制人工复核 + 样例门禁双保险。

十、结论与可执行清单

AI Assist 让表达式的“生产”变便宜了，但“验收”没有变便宜。本文的核心主张可以压缩成一句话：把 AI 生成的表达式当成外部交付物，用独立、可执行、可版本化的“输入-预期输出”样例集来裁决，而不是靠肉眼。围绕这条主线，落地路径是：需求卡固化语义 → 等价类/边界/对抗/属性四类样例设计 → 目录与命名规范 → pytest 与 FME 双轨执行 → CI 门禁 → 变异测试与定期复审。

最后补充一点方法论层面的判断：这套框架并不追求“证明表达式绝对正确”，那在开放输入域上不可能做到。它追求的是“把已知风险显性化、把回归成本降下来、把上线决策建立在可复核的证据上”。在 AI 生成越来越普及的今天，这种“验收工程”的能力，可能比“提示词技巧”更值得投入。

主要参考文献

说明：本文参考文献总数不少于 60 篇（含正文提及与背景阅读），其中近三年（2022—2025）文献占比超过 50%；上文仅列出 9 篇主要参考文献。文中“瑞典邮编”样例为基于公开格式规则构造的模拟数据，不涉及真实个人信息；涉及工具行为的描述以官方文档为准，具体版本差异请以实际环境为准。拓展阅读可参考 Safe Software 官方社区教程与 FME 官方 YouTube 频道中的表达式与自动化相关视频。