ISO 8373-2021工业机器人术语落地：接口、验收与术语库

简介：ISO 8373-2021《机器人 词汇》第三版官方英文标准全文，面向工业机器人与服务机器人领域的研发工程师、系统集成商、标准与测试人员，以及需要规范术语表达的高校师生。文件为国际标准化组织2021年11月发布的正式版本，统一了机械结构、几何与运动学、编程与控制、性能、传感与导航、模块与模块化等章节的核心定义，可用于解决跨团队沟通中术语混用、指标范围不一致的问题。资源包共1个PDF文件，约2.25MB，为可直接检索的原文文档，正文含前言、引言、范围、规范性引用文件及第1至第9章术语条目，并附资料性附录。查阅时可沿目录快速定位“关节”“末端执行器”“基座”“控制器”“传感器”“自主性”“人机协作”“安全停止功能”等条目，也便于校准产品手册与技术方案中的用词。目前已有1043人学习下载，适合作为机器人项目立项、文档编写与标准对照的常用参考。

1. 机器人词汇不是背单词：ISO 8373-2021 先把“工业机器人”边界钉死

产线评审会上，机械、电气、算法三方对“工业机器人”各说各话，合同里写的是“机器人系统”，验收表却按“机器人本体”测，最后返工。机器人词汇 ISO 8373-2021 这份资源的价值就在这里：它把工业机器人、机器人系统、末端执行器、机械接口这些词的定义和边界写成可引用的条款，而不是靠经验猜。第三版 2021-11 发布，覆盖通用、机械结构、几何运动学、编程控制、性能、传感导航、模块化七组术语，适合做集成、选型、需求评审和验收的人当术语基线。它不是操作手册，不能直接告诉你加减速怎么调，但能让你在写 SOW、接口表和验收大纲时少留歧义。下面按“术语地图、工程约束、抽取脚本、避坑、术语服务”五段拆。

2. 第三版术语地图：七组词条怎么映射到选型与接口表

2.1 先看目录结构：七组术语对应七类工程问题

拿到这份标准正文，别从第 3 章第一条开始背。先看目录：第 3 章是通用术语，第 4 章机械结构，第 5 章几何与运动学，第 6 章编程与控制，第 7 章性能，第 8 章传感与导航，第 9 章模块与模块化。这个分组不是学术分类，它和工程文档的章节天然对齐。通用术语决定“这东西算不算机器人”，机械结构决定选型和接口，几何运动学决定坐标系和关节描述，编程控制决定任务程序和操作员角色，性能决定验收指标，传感导航决定移动能力，模块化决定扩展和维修边界。

我一般会先把七组术语做成一张“问题—条款—产物”表，再让不同角色认领。机械工程师认领第 4 章，电气和控制工程师认领第 3.4、3.11、3.12、第 6 章，测试工程师认领第 3.16、3.17 和第 7 章，做移动底盘的认领第 8 章，做可重构设备的认领第 4.6 和第 9 章。这样术语表不是词典，而是评审分工表。

第三版前言明确提到，这一版修订了定义，新增了 medical robot、wearable robot 以及模块化相关词条，并和现有标准做了协调。对做集成的人来说，最直接的变化是“医疗机器人”不再被硬塞进工业机器人或服务机器人里，3.8 明确它不被视为工业机器人或服务机器人。这个边界在项目立项时非常有用：如果产品注册路径走医疗电气设备，术语表里就不该出现“工业机器人集成商”这种模糊写法。

可执行步骤我通常按四步走。第一步，把目录页和第 3 到第 9 章标题抄进一个表格，不要抄定义。第二步，给每个条款号补一列“我们项目里谁用”。第三步，把项目现有文档里的词往里填，填不进去的词单独放“待确认”。第四步，对“待确认”词做一次评审，能映射到标准条款的就映射，映射不上的说明是项目自定义词，必须在文档里加定义。这个动作看起来笨，但比后面因为“机器人系统”和“机器人本体”混用而返工便宜得多。

2.2 机械结构词条：从 actuator 到 manipulator 的选型映射

第 4 章是这份资源里最容易被低估的部分。很多人以为机械结构术语只是画图用的，实际上它直接决定采购规格书和接口表怎么写。4.1 的 actuator 是“把电能、液压、气动或其他能量转换为机器人运动的动力机构”，注意它不等于“电机”，也不等于“驱动器”。写规格书时如果把 actuator 写成 motor，供应商回过来的参数可能是电机转矩，而不是关节输出端的运动能力，后面做负载校验就会翻车。4.2 的 arm 是基座到腕之间的连杆和动力关节集合，4.3 的 wrist 是腕到末端执行器之间的部分，这两个词不能拿来指整机。4.14 的 manipulator 是“由相对铰接或滑动的段组成的机构”，注释明确说不包括末端执行器。也就是说，机械接口 4.11 是 manipulator 和 end-effector 的分界点。

这张表怎么用？拿一份现有采购规格书，把“本体”“手臂”“腕部”“夹具”“法兰”这些词逐个替换成标准术语。替换不了的地方，就是接口定义缺失的地方。比如很多规格书只写“末端法兰”，不写机械接口的定位方式和螺纹规格，到了现场装夹爪才发现厚度干涉。4.11 的注释指向 ISO 9409-1 和 ISO 9409-2，这说明机械接口不是随便画个法兰，它有配套的接口标准。你不需要在这份词汇标准里找尺寸，但必须知道“机械接口”是一个独立术语，不能和“末端执行器”揉在一起。

选型理由也在这里：4.14.1 到 4.14.3 把矩形、圆柱、极坐标机器人按关节类型和坐标系分类。这个分类不是让你背，而是让你在方案评审时能说清楚“为什么选三滑动关节的笛卡尔构型，而不是两旋转一滑动的极坐标构型”。三滑动关节的构型在笛卡尔坐标系里描述简单，直线运动解耦好，但占地和刚性设计是另一回事；圆柱和极坐标构型用旋转关节换工作空间，标定和奇异点处理更麻烦。标准只给定义，不给优劣，但定义统一之后，优劣讨论才不会跑偏。

2.3 几何、运动学与编程控制：configuration 和 joint 怎么写进接口表

4.5 的 configuration 在运动学语境下是“完全决定机器人形状的所有关节值的集合”，4.6 的 configuration 在模块化语境下是“为实现机器人所需功能而进行的模块布置”。同一个词两个义项，这是术语落地时最容易埋雷的地方。接口表里如果只写“configuration”，读的人可能以为是关节角，也可能是模块组合。我的做法是加命名空间：kinematic_configuration和modular_configuration，并在字段说明里引用 4.5 和 4.6。这样既不改变标准定义，又避免工程文档歧义。

joint 4.8 的注释说关节可以是主动/动力或被動/无动力，4.8.1 和 4.8.2 又分了滑动和旋转。写接口表时，关节不能只写“J1、J2、J3”，还要写类型、主动/被动、运动方向。对于移动机器人，4.4 的 leg 是“通过往复运动与行驶表面间歇接触来支撑和推进移动机器人的连杆与关节机构”，这个定义把 leg 和轮式移动平台区分开了。做底盘选型时，如果项目里写“leg”但实际是轮组，术语就对不上，验收时也没法按 leg 的往复运动特征去测。

编程与控制部分，3.4 的 control system 包括硬件和软件，实现逻辑与功率控制，并允许监控机器人行为以及与环境中的其他对象和人交互。3.11 的 operator 是“被指定启动、监控和停止预期操作的人”，3.12 的 task programmer 是“被指定准备任务程序的人”。这两个角色在很多小项目里由同一个人兼，但文档里最好分开写，因为安全职责和编程职责不是一回事。3.9 的 industrial robot system 包含工业机器人、末端执行器、末端执行器传感器和设备，以及任务程序。注意它把任务程序也算进系统，这意味着验收“机器人系统”时不能只测本体，还要测任务程序和相关外围设备。

可执行步骤：先建一张“构型与角色清单”，字段包括configuration_id、configuration_type（kinematic/modular）、joint_count、joint_type_list、operator_role、task_programmer_role、task_program_id。然后拿这张清单去对现有接口表，缺字段的补，定义冲突的标红。最后把 3.4、3.11、3.12、3.9 的条款号写进字段说明，评审时直接引用。这个动作不需要写代码，但需要有人对字段负责，否则表格建完也没人维护。

3. 从术语到工程约束：需求、接口、验收三段落地法

3.1 需求阶段：用 robot、industrial robot、service robot 切产品类别

需求阶段最怕的是产品类别没切干净。3.1 的 robot 是“具有自主度、执行移动、操作或定位的程序化驱动机构”，注释说它包括控制系统，机械结构例子包括 manipulator、mobile platform 和 wearable robot。3.5 的 robotic device 是“用机器人技术开发，但不满足 robot 全部特征的机构”，例子包括遥操作远程 manipulator、触觉设备、末端执行器、无动力外骨骼。这两个定义放在一起看，边界就出来了：有没有自主度、是不是程序化驱动、能不能执行移动/操作/定位，三个条件缺一个就可能落到 robotic device。很多项目把“遥操作机械臂”写成 robot，到了功能安全评审时才发现它没有自主决策，按 robot 的自主性要求去写需求就写偏了。

3.6 的 industrial robot 有四个硬条件：自动控制、可重编程、多用途 manipulator、三个或以上轴可编程，并且固定安装或固定在移动平台上，用于工业环境的自动化应用。注释还说明它包括 manipulator、由机器人控制器控制的机器人 actuator、控制器、示教/编程手段和通信接口，也包括集成到运动学方案中的辅助轴。3.7 的 service robot 是个人或专业用途、为人或设备执行有用任务的 robot。3.8 的 medical robot 是用作医疗电气设备或医疗电气系统的 robot，并且明确不被视为 industrial robot 或 service robot。这个“不被视为”很关键，它让医疗机器人有了独立类别，不再被硬塞进工业或服务。

可执行步骤：第一步，把产品需求书里的“机器人”全部标出来。第二步，对每个“机器人”问上面五个问题，把答案写在旁边。第三步，答案落到 3.1、3.5、3.6、3.7、3.8 的条款号上。第四步，如果同一产品在不同章节被写成不同类别，拉一次跨部门评审。这里最常见的翻车是销售文档写“服务机器人”，技术文档写“工业机器人系统”，注册文档又写“医疗机器人”，三份文档各说各话。术语基线不解决技术问题，但能把这种低级冲突提前暴露。

3.2 接口阶段：mechanical interface、end-effector、gripper 的字段化

接口阶段的核心不是画图，是把 4.11、4.12、4.13 变成字段。4.11 的 mechanical interface 是 manipulator 末端用于安装末端执行器的安装面，注释指向 ISO 9409-1 和 ISO 9409-2。4.12 的 end-effector 是专门设计用于连接到机械接口、使机器人执行任务的装置，例子包括 gripper、焊枪、喷枪。4.13 的 gripper 是用于抓取和保持的末端执行器。这三个词是包含关系：mechanical interface 是安装面，end-effector 是装在它上面的装置，gripper 是 end-effector 的一种。接口表里如果把三者混成一列，采购和现场装配就会对不上。

我一般会用一个 YAML 术语卡把接口字段固定下来，字段名用英文，说明里带条款号。这样机械、电气、采购都能读同一份文件。

# 机械接口术语卡：字段名固定，说明引用 ISO 8373:2021 条款 mechanical_interface: clause: "4.11" description: "manipulator 末端用于安装 end-effector 的安装面" fields: - name: interface_standard type: string note: "如有配套接口标准，填标准号；没有则填 project-defined" - name: mounting_surface_size type: string note: "安装面尺寸，按项目图纸填写" - name: positioning_feature type: string note: "定位销、止口或其他定位方式" - name: thread_spec type: string note: "螺纹规格，不要只写 M 几" end_effector: clause: "4.12" description: "连接到 mechanical interface 上执行任务的装置" fields: - name: task_type type: enum values: [gripping, welding, spraying, other] - name: mass_kg type: number - name: interface_ref type: string note: "指回 mechanical_interface 的编号" gripper: clause: "4.13" description: "用于抓取和保持的 end-effector" fields: - name: grip_type type: enum values: [parallel, angular, vacuum, magnetic, other] - name: opening_mm type: number - name: holding_force_n type: number

这份 YAML 不是标准原文，是把术语变成字段的工程模板。interface_standard字段的意义在于区分“有配套接口标准”和“项目自定义接口”，避免把自定义法兰说成标准接口。positioning_feature和thread_spec分开，是因为现场装配时定位和锁紧是两件事，混在一起写容易漏。end_effector.task_type用枚举，是为了让采购和工艺能按任务类型筛选，而不是在一堆自由文本里找“焊枪”。gripper单独列，是因为 gripper 是 end-effector 的子类，字段可以更具体，但不能反过来把焊枪也叫 gripper。

参数怎么改？如果项目里末端执行器是焊枪，task_type选 welding，gripper段可以删掉，但end_effector的mass_kg和interface_ref必须保留。如果项目里是快换装置，mechanical_interface要加quick_change_ref字段，但不要改 4.11 的定义。字段可以扩展，术语定义不能改。这个原则在接口评审时很重要：允许项目加字段，不允许项目重新定义标准词。

3.3 验收阶段：validation 与 verification 别混成一张表

3.16 的 validation 是“通过检查和提供客观证据，确认特定预期用途的特定要求已得到满足”，3.17 的 verification 是“通过检查和提供客观证据，确认要求已得到满足”。两句话很像，差别在“特定预期用途”。verification 回答“我有没有按规格做对”，validation 回答“我做的这个东西在预期用途下有没有用对”。工业机器人系统验收时，verification 可以测重复定位精度、负载、节拍；validation 要放到实际工艺场景里，看抓取、焊接、搬运的任务要求是否满足。很多项目把调试记录当 validation 证据，这就是典型的混淆。

可执行步骤：第一步，验收大纲分两列，左列 verification，右列 validation。第二步，每条验收项标注条款号，能引 3.17 的放左列，能引 3.16 的放右列。第三步，检查右列有没有“特定预期用途”的描述，没有就补场景。第四步，把 3.9 的 industrial robot system 范围写进验收边界，明确末端执行器、传感器、任务程序是否在范围内。这样验收表不会变成一张大杂烩。

3.4 术语基线表：字段设计与版本管理

术语基线表不是把标准全文抄一遍，而是只收项目用到的词。字段我一般设七个：term_id、preferred_term、clause、definition_short、project_usage、forbidden_variants、owner。definition_short用自己的话转述，不复制标准原文；project_usage写这个词在本项目里指什么；forbidden_variants写禁止使用的旧词，比如把“机器人系统”写成“机器人本体”；owner写维护人。版本管理用语义化版本，术语新增走 minor，定义变更走 major，拼写修正走 patch。每次评审前导出一次快照，和需求文档、接口表一起归档。

提示：术语基线表只收项目实际用到的词，不要一开始就全量导入。全量导入的后果是没人维护，三个月后表里全是过期定义。

4. 把 PDF 拆成术语库：抽取脚本、字段规范与一致性检查

4.1 资源预处理：页眉页脚、分栏和条款号断行

标准正文是 PDF，直接复制粘贴会带页眉、页脚、版权行和分栏断行。条款号经常单独一行，术语名在下一行，定义再下一行。预处理的目标不是把 PDF 转成完美文本，而是把“条款号 + 术语 + 定义”抽出来，人工再校一遍。我一般先做三件事：去掉重复页眉页脚，按块而不是按行读取，保留条款号所在的块。分栏问题用块坐标排序解决，不能只用extract_text()的阅读顺序，否则左右栏会串。

可执行步骤：第一步，把 PDF 放到data/raw/，不要改原文件。第二步，用脚本输出data/interim/blocks.jsonl，每行一个文本块，带页码和坐标。第三步，人工抽 3 页看块顺序对不对，尤其看第 3 章和第 4 章的分栏。第四步，确认页眉页脚模式，写进清洗规则。这个步骤听起来琐碎，但跳过它，后面抽出来的术语会缺定义或者条款号错位。

4.2 抽取“条款号 + 术语 + 定义”三元组

下面这段 Python 用 PyMuPDF 按块读取，按页码和纵坐标排序，再用正则抓条款号开头的块。它不追求一次抽全，目标是把候选三元组落到 JSONL，方便人工复核。

import json import re from pathlib import Path import fitz # PyMuPDF PDF_PATH = Path("data/raw/iso8373.pdf") OUT_PATH = Path("data/interim/terms_raw.jsonl") # 条款号：3.1、3.16、4.8.1、4.14.3 这类层级编号 CLAUSE_RE = re.compile(r"^(\d+(?:\.\d+){1,3})\s*$") # 术语行：条款号后一行，通常是英文术语，允许连字符和空格 TERM_RE = re.compile(r"^[A-Za-z][A-Za-z0-9\-\s/]{1,80}$") def iter_blocks(page): """按纵坐标、横坐标排序，缓解双栏串行。""" blocks = page.get_text("blocks") blocks.sort(key=lambda b: (round(b[1], 1), round(b[0], 1))) for block in blocks: text = block[4].strip() if text: yield text def main(): doc = fitz.open(PDF_PATH) records = [] for page_no, page in enumerate(doc, start=1): lines = [] for block in iter_blocks(page): lines.extend([ln.strip() for ln in block.splitlines() if ln.strip()]) i = 0 while i < len(lines): m = CLAUSE_RE.match(lines[i]) if not m: i += 1 continue clause = m.group(1) term = "" definition_lines = [] j = i + 1 if j < len(lines) and TERM_RE.match(lines[j]): term = lines[j] j += 1 while j < len(lines) and not CLAUSE_RE.match(lines[j]): # 遇到下一个条款号前，都视为定义候选 definition_lines.append(lines[j]) j += 1 if term: records.append({ "clause": clause, "term": term, "definition": " ".join(definition_lines), "page": page_no, }) i = j OUT_PATH.parent.mkdir(parents=True, exist_ok=True) with OUT_PATH.open("w", encoding="utf-8") as f: for rec in records: f.write(json.dumps(rec, ensure_ascii=False) + "\n") print(f"written {len(records)} records to {OUT_PATH}") if __name__ == "__main__": main()

逻辑说明：iter_blocks先按纵坐标再按横坐标排序，是为了让同一页的左右栏尽量按从上到下、从左到右的顺序进入列表。CLAUSE_RE只匹配单独成行的条款号，避免把正文里的“3.1”误抓。TERM_RE限制术语行以字母开头，减少把定义首行当术语。定义收集到下一个条款号为止，所以定义里如果出现条款号引用（比如“见 3.2”），可能被截断，这正是需要人工复核的地方。

参数说明：PDF_PATH换成实际文件路径；OUT_PATH是候选输出；CLAUSE_RE的层级上限是 3 级，覆盖 4.8.1 这类编号，如果标准里有更深的编号要改。page.get_text("blocks")的块坐标单位是 PDF 点，排序用round(..., 1)是为了减少浮点误差导致的抖动。抽出来的definition不保证完整，下一步要人工抽查 20 条，重点看跨页定义和带注释的条目。

运行后看什么？先看总数，再看第 3 章前 10 条能不能对上 3.1 到 3.10。如果条款号有但术语为空，说明术语行不符合TERM_RE，可能是术语里带数字或特殊符号，放宽正则但别放宽到匹配定义句。如果定义明显串到下一栏，回到块排序，检查是否同一纵坐标的左右栏顺序反了。这个脚本不处理表格和注释，注释里的 Note 1 to entry 会混进定义，人工复核时要把 Note 段拆出去。

4.3 一致性检查：缩写冲突、同义词和跨文档引用

抽完候选词，下一步不是马上入库，而是做一致性检查。三个检查最有用：同一术语的大小写变体、缩写是否冲突、同一缩写有没有多个全称。3.15 明确提醒，描述用户界面时不要用 HRI 表示 human–robot interface，因为容易和 human–robot interaction 混淆。这种提醒就是一致性检查的规则来源。下面这段脚本读 JSONL，输出可疑项。

import json import re from collections import defaultdict from pathlib import Path IN_PATH = Path("data/interim/terms_raw.jsonl") REPORT_PATH = Path("data/reports/term_consistency.txt") # 抓定义里的缩写，形如 HRI、ISO、IEC ABBR_RE = re.compile(r"\b[A-Z]{2,6}\b") def load_records(): records = [] with IN_PATH.open(encoding="utf-8") as f: for line in f: if line.strip(): records.append(json.loads(line)) return records def main(): records = load_records() term_variants = defaultdict(set) abbr_to_terms = defaultdict(set) for rec in records: term = rec["term"].strip() # 大小写归一，找同一术语的不同写法 term_variants[term.lower()].add(term) for abbr in ABBR_RE.findall(rec.get("definition", "")): abbr_to_terms[abbr].add(term) lines = [] for key, variants in sorted(term_variants.items()): if len(variants) > 1: lines.append(f"大小写变体: {sorted(variants)}") for abbr, terms in sorted(abbr_to_terms.items()): if len(terms) > 1: lines.append(f"缩写 {abbr} 出现在多个术语定义中: {sorted(terms)}") REPORT_PATH.parent.mkdir(parents=True, exist_ok=True) REPORT_PATH.write_text("\n".join(lines) or "no obvious conflict", encoding="utf-8") print(f"report written: {REPORT_PATH}, items={len(lines)}") if __name__ == "__main__": main()

逻辑说明：term_variants用lower()做键，收集同一词的不同大小写写法，比如Robot和robot。abbr_to_terms收集每个缩写出现在哪些术语的定义里，如果一个缩写出现在多个术语定义中，就提示人工确认是不是同一概念。这个检查不判断对错，只把可疑项捞出来。参数说明：ABBR_RE只抓 2 到 6 个大写字母，避免把普通单词抓进来；如果项目里有带数字的缩写，要改正则。REPORT_PATH输出纯文本，方便贴进评审记录。

这个脚本的边界很明显：它抓不到同义词，比如“末端执行器”和“工具”都指 end-effector，但文本上不相似。同义词检查要靠术语基线表的forbidden_variants字段，不能靠正则。跨文档引用检查也要人工做，比如需求文档引用了 3.9，接口表却只引 3.6，这种引用不一致脚本看不出来。

4.4 输出 CSV/JSON 并接入评审清单

抽完、查完，最后落到两个文件：terms.csv给评审看，terms.json给工具用。CSV 字段包括clause、term、definition_short、project_usage、owner、status。JSON 保留完整定义和页码，方便回溯。评审清单只放status为pending和conflict的条目，不要把全部条目倒给评审，否则没人看。

接入评审清单的步骤：第一步，把status=pending的条目按 owner 分组。第二步，每条待确认术语写一句“项目里怎么用”。第三步，评审会上只做三件事：确认定义、确认禁用变体、确认 owner。第四步，评审后把status改成approved或rejected，并记录日期。这个流程不复杂，但需要一个人盯版本，否则术语表会变成一次性文档。

5. 避坑与排查：术语标准落地最常见的五类翻车

5.1 把 robotic device 当 robot 报合规

现象：项目里有一台遥操作远程 manipulator，需求文档写“机器人”，验收按 robot 的自主性去测，结果发现没有自主决策，测试项无法闭环。原因：3.1 的 robot 要求有自主度，能基于当前状态和感知执行移动、操作或定位；3.5 的 robotic device 是用机器人技术开发但不满足 robot 全部特征的机构，例子明确包括遥操作远程 manipulator、触觉设备、末端执行器、无动力外骨骼。把“有机械结构、能动”当成 robot，是典型的定义偷懒。解决：在项目立项表里加一列“产品类别判定”，按 3.1、3.2、3.5 逐条打勾，不满足 robot 全部条件的写 robotic device，再决定适用哪套安全和验收要求。如果项目坚持叫“机器人”，至少在术语基线表里注明“项目自定义用法”，不要把它当成标准里的 robot。

5.2 industrial robot 与 industrial robot system 混用

现象：合同写“工业机器人交付”，验收时供应商只交本体和控制器，项目方认为末端执行器、视觉和任务程序也该在范围内，双方扯皮。原因：3.6 的 industrial robot 包括 manipulator、机器人控制器、示教/编程手段和通信接口，也包括集成到运动学方案的辅助轴；3.9 的 industrial robot system 是包含工业机器人、末端执行器、末端执行器传感器和设备、任务程序的机器。两个词的范围不同，合同不写清楚就会翻车。解决：在合同和验收大纲里分两层写，第一层写 industrial robot 范围，第二层写 industrial robot system 范围，末端执行器和任务程序放在第二层。验收表按两层拆，别把系统级测试压到本体供应商头上。

5.3 HRI 缩写指代不清

现象：需求文档写“HRI 界面响应时间小于 200 ms”，开发理解为 human–robot interaction 的整体交互，测试理解为用户界面刷新，最后测的不是一个东西。原因：3.15 的 HRI 是 human–robot interaction，指人和机器人之间通过用户界面进行的信息和动作交换，注释明确提醒不要用 HRI 表示 human–robot interface。缩写冲突在跨团队文档里非常常见。解决：术语基线表里把 HRI 固定为 human–robot interaction，用户界面写全称 user interface，需要缩写就另起一个不冲突的写法。所有需求条目里的 HRI 都要能展开成全称，展不开的就删掉重写。

5.4 configuration 多义项混用

现象：接口表里写“configuration 由供应商定义”，机械团队以为是模块布置，算法团队以为是关节角集合，联调时发现双方说的不是一回事。原因：4.5 的 configuration 在运动学语境下是所有关节值的集合，4.6 的 configuration 在模块化语境下是模块布置。同一个词两个义项，标准用尖括号标了语境，工程文档却经常省略。解决：字段名加命名空间，kinematic_configuration和modular_configuration分开；文档里第一次出现时写全称加条款号；评审时专门问一句“你说的是 4.5 还是 4.6”。这个坑不大，但很耗时间，血泪经验是越早拆开越好。

5.5 validation 和 verification 互换

现象：验收报告里写“已完成 validation”，附的是重复定位精度测试记录。客户问“预期用途验证在哪”，答不上来。原因：3.16 的 validation 强调特定预期用途的要求已满足，3.17 的 verification 强调要求已满足。重复定位精度是 verification，不是 validation。解决：验收大纲分两列，左列 verification 放规格符合性测试，右列 validation 放场景任务验证；每条证据标注条款号；评审时检查右列有没有“特定预期用途”的描述。如果项目只有 verification 没有 validation，就在验收范围里明确写“不含 validation”，不要用错词掩盖缺失。

6. 进阶用法：把 ISO 8373-2021 做成团队可检索的术语服务

6.1 术语服务的输入输出

术语表停在 CSV 阶段，用起来还是靠人翻。再往前走一步，把术语基线做成一个小服务：输入是 YAML 术语卡，输出是 JSON Schema、检索索引和 MR 检查规则。JSON Schema 给接口表校验用，检索索引给文档站用，MR 检查规则给代码评审用。下面这张表是我常用的最小输入输出。

6.2 一个最小 CI 检查

最小检查不用上复杂工具，一段 bash 加 grep 就能拦住大部分低级错误。把禁用变体写进forbidden.txt，在 MR 里跑一遍，命中就失败。

#!/usr/bin/env bash set -euo pipefail # forbidden.txt 每行一个禁用变体，例如：机器人本体、HRI 界面 FORBIDDEN_FILE="terms/forbidden.txt" TARGET_DIR="${1:-docs}" if [[ ! -f "$FORBIDDEN_FILE" ]]; then echo "missing $FORBIDDEN_FILE" exit 1 fi status=0 while IFS= read -r word; do [[ -z "$word" ]] && continue if grep -RIn --exclude-dir=.git -- "$word" "$TARGET_DIR"; then echo "forbidden term found: $word" status=1 fi done < "$FORBIDDEN_FILE" exit "$status"

这段脚本的用法是./term-check.sh docs，检查docs目录下有没有禁用变体。FORBIDDEN_FILE里的词要来自术语基线表的forbidden_variants字段，不要手写一堆没评审过的词。grep -RIn会打印文件名和行号，方便直接跳转。它不检查同义词，也不检查条款引用，那些要靠 JSON Schema 和人工评审。参数TARGET_DIR可以换成specs或contracts，按项目文档目录调整。

从那以后我每次把术语表接进项目，都强制走一遍“抽候选、人工复核、禁用变体进 CI”这三步，哪怕项目只有三个人。术语标准不是拿来背的，是拿来在评审会上拍桌子的依据。希望帮到你。

本文还有配套的精品资源，点击获取