术语表设计的核心步骤是：先确定读者和收录范围，再定字段结构与唯一词条规则，然后明确“提出—评审—发布—变更”的责任人与状态，最后用真实文档试填并做一致性检查。最终产物是一张可维护的术语表和一份简短的维护流程说明。本文按这四步展开，并说明术语表在ONES文档与知识库中的承载和协作方式。
要点总览（TL;DR）
- 术语表设计从范围说明开始：明确读者对象、收录边界和不收录清单，首版控制在几十条以内，先跑通流程再扩展。
- 必填字段控制在六到七个：中文名、英文名、定义、同义词与禁用写法、责任人、状态；定义用陈述句说清本质属性，五十字以内，避免循环定义。
- 维护流程设草稿、评审中、已发布、变更中、已废弃五个状态，每个状态有责任人和进入下一状态的条件，评审周期建议控制在一周内。
- 承载位置按团队情况选择文档页面、知识库条目或表格；先用表格完成首版评审再迁入知识库长期维护，是多数团队可行的路径。
- 验收用七项检查：字段完整性、唯一性、冲突、一致性、责任人落实、更新机制、可检索性，每季度做一次全表复核。
术语表先定什么：范围、读者与词条边界
动手建表之前，先写一份范围说明。它决定后面收哪些词、字段设多少、谁来评审。范围没定清楚，术语表容易变成大而全的词典，维护成本高，写作者也不会主动查。
三项判断
第一，术语表服务谁。读者不同，收录重点不同：面向新人，收组织内部高频且容易误解的词；面向跨团队协作，收各团队叫法不一致的词；面向对外文档和翻译，收需要固定译法和写法的词。可以同时服务多类读者，但要排出优先级，避免字段为所有人设计而变得臃肿。
第二，收录范围怎么划。常见做法是两条线取交集：一是领域核心概念，二是实际出现过混淆或写错的词。只收易混淆词，表会轻但覆盖不全；只收核心概念，表会全但没人查。建议首版以“近三个月文档评审中被指出写法不一致的词”为起点，再补少量领域核心概念，控制在几十条以内，先跑通流程。
第三，词条边界怎么定。原则是一个概念一条词条。同一概念在不同场景有不同含义时，优先拆成两条并在定义中写明适用范围，例如“订单（交易场景）”和“订单（履约场景）”；如果只是同一含义的不同叫法，合并为一条，用同义词字段承接。判断标准是：两个词条能否互换使用而不改变句意，能互换就合并。
与需求文档、流程制度的分工
术语表只负责“词怎么说、指什么”，不承载业务规则和操作步骤。业务规则写在需求文档或制度里，术语表通过“相关词条”和“来源出处”指向它们。这样术语表保持稳定，规则变化时不必逐条改定义。范围说明中应附一份不收录清单，例如临时项目代号、仅在一个团队内部使用的缩写、随版本频繁变化的参数名，减少后续争议。
本节产出：一份范围说明，包含读者对象、收录边界、不收录清单和首版词条数量上限。
术语表字段怎么设：必填项与选填项
字段设计的目标是让每条词条能被独立理解、被检索到、被追责。必填项控制在六到七个，选填项按需增加。字段过多会拖慢填写，过少则无法判断词条是否有效。
| 字段名 | 是否必填 | 填写要求 | 示例 |
|---|---|---|---|
| 中文名 | 必填 | 团队统一使用的标准写法，唯一 | 工作项 |
| 英文名 | 必填 | 对外文档和界面使用的英文对应，无对应时填“无” | Work Item |
| 定义 | 必填 | 一句话说清“是什么”，不写用途宣传，不用被定义词解释自身 | 团队在项目中跟踪的一项具体任务、缺陷或需求，具有负责人和状态 |
| 同义词与禁用写法 | 必填 | 列出可接受的别名和明确不用的写法，禁用写法要写全常见错法 | 同义词：任务项；禁用：工单、事项 |
| 责任人 | 必填 | 负责该词条定义准确和变更响应的角色或姓名 | 产品文档负责人 |
| 状态 | 必填 | 草稿、评审中、已发布、已废弃之一 | 已发布 |
| 示例 | 选填 | 一句包含该词的实际用法，帮助理解边界 | “每个工作项在迭代结束时需更新状态。” |
| 来源出处 | 选填 | 定义依据的文档、标准或会议决议 | 《产品数据模型说明》第2节 |
| 相关词条 | 选填 | 易混词或上下位概念，写中文名 | 迭代、需求 |
| 适用范围 | 选填 | 限定该词条生效的产品线、团队或文档类型 | 全部对外文档 |
| 生效版本 | 选填 | 该定义开始生效的版本或日期 | v2.1，2025-03 |
定义写法要求
定义用陈述句说明概念的本质属性，控制在五十字以内。避免三类问题：循环定义，如“工作项就是工作项”；营销化表述，如“高效协同的核心载体”；把操作步骤写进定义。写完可以用一个检验：把定义代入一句实际文档，句意是否清楚。不清楚就补充区别性特征，例如与相邻概念的差异。
同义词与禁用写法的用法
同义词字段解决“同一个东西多种叫法”，禁用写法解决“明确不该出现的叫法”。两者配合使用：写作者检索任一叫法都能找到标准词条，评审时也有依据指出错误写法。禁用写法要覆盖实际出现过的错法，包括缩写、旧称和翻译变体。词条发布后，禁用写法可作为文档检查的对照项。
从提出到发布：术语表的维护流程与角色
术语表的价值在于持续维护。流程不必复杂，但每个状态要有责任人和进入下一状态的条件。建议设三个角色：提出人、评审人、词条责任人。小团队可由同一人兼任评审与责任，但要区分动作。
| 状态 | 动作 | 责任人 | 进入下一状态的条件 |
|---|---|---|---|
| 草稿 | 提出词条，填写必填字段 | 任何团队成员 | 必填字段齐全，附至少一个实际用例或出处 |
| 评审中 | 核对定义准确性、与现有词条是否冲突、禁用写法是否完整 | 评审人（领域专家加文档负责人） | 无重复词条，定义通过评审，争议已记录结论 |
| 已发布 | 更新术语表，通知相关写作者 | 词条责任人 | 通知发出，引用该词的文档列入待检查 |
| 变更中 | 修改定义或写法，记录变更原因 | 词条责任人 | 变更评审通过，旧写法移入禁用写法 |
| 已废弃 | 标记废弃，保留词条供检索 | 词条责任人 | 替代词条已发布，引用处完成替换 |
提出与评审
提出人提交时应说明三件事：这个词在哪里造成了歧义、建议的定义、已知的其他叫法。评审判断标准有两条：定义是否准确且可区分，是否与现有词条重复或冲突。出现争议时，由领域专家给出结论并记录理由，避免同一问题反复讨论。评审周期建议控制在一周内，超时默认退回补充信息。
发布、变更与废弃
发布不只是改状态，还要通知到实际写文档的人，并把使用该词的文档列入检查范围。变更时保留变更记录，旧写法移入禁用写法而不是直接删除，方便检索到历史文档。废弃词条保留在表中并标注替代词，引用处按清单逐个替换，替换完成后才关闭该词条。
示例：一条术语词条怎么写
下面是一条完整词条，可直接作为模板使用。
| 字段 | 内容 |
|---|---|
| 中文名 | 迭代 |
| 英文名 | Sprint |
| 定义 | 团队在固定周期内完成一组工作项的时间盒，有明确的起止日期和交付目标。 |
| 同义词与禁用写法 | 同义词：冲刺；禁用：周期、阶段、版本 |
| 责任人 | 研发文档负责人 |
| 状态 | 已发布 |
| 示例 | “本迭代计划完成十二个工作项。” |
| 来源出处 | 《研发协作规范》第3节 |
| 相关词条 | 工作项、版本 |
| 适用范围 | 研发类文档与对外说明 |
| 生效版本 | v1.0 |
对照说明与常见错误
这条词条中，定义说明了“时间盒”和“交付目标”两个区别性特征，能与“版本”区分开；同义词承接“冲刺”这一常见叫法；禁用写法列出“周期”“阶段”，因为这两个词在文档中常被用来指代其他概念。常见错误有三类：定义写成“迭代就是一次迭代周期”，属于循环定义，修正为说明时间盒和交付目标；禁用写法只写一个词，遗漏实际错法，修正为从评审记录中收集；把“版本”列为同义词，导致两个概念混用，修正为放入相关词条并各自定义。
术语表放在哪里、怎么被用起来
承载位置影响使用率。三种常见选择各有适用条件：文档页面适合词条少、读者固定的团队，更新快但检索弱；知识库条目适合词条多、需要分类和权限控制的组织，检索和引用方便；表格适合首版试运行和批量整理，协作编辑直观但版本留痕较弱。多数团队的做法是先用表格完成首版评审，再迁入知识库长期维护。
让写作者查得到、用得上
三个动作能明显提高使用率：在文档模板开头放术语表入口；评审清单中加入“关键术语与术语表一致”一项；新词条发布时在团队频道通知并附一句用法示例。写作者在写作时能一键检索到标准写法和禁用写法，术语表才真正参与文档生产，而不只是存档。
评审与版本留痕
词条的每次变更都应留下谁改、改了什么、为什么改的记录。评审意见与结论保存在词条附近，便于后续追溯。使用ONES时，可以把术语表作为知识库中的独立页面或条目维护，每个词条对应页面内的一节或一条记录；提出与评审通过文档评论和状态流转完成，变更历史由版本记录保留，写作者在文档中引用术语表页面即可跳转查阅。这样词条的定义、评审结论和版本变化在同一处可查，减少在聊天工具和表格之间来回核对。
完成检查：术语表可用的判断标准
术语表是否可用，用下面这份清单逐项核对。全部通过即可投入日常使用，未通过项按对应动作补齐。
- 字段完整性：抽查十条词条，六个必填字段是否齐全；定义是否都在五十字以内且无循环定义。
- 唯一性：同一概念是否只有一条词条；同义词是否只指向一个标准词；是否存在两个词条定义几乎相同的情况。
- 冲突检查：禁用写法是否与任何已发布词条的中文名重复；相关词条链接是否有效。
- 一致性：抽取三份近期文档，检查其中的关键术语写法是否与术语表一致，不一致处记录并修正。
- 责任人落实：每条词条是否都有责任人；责任人是否知道自己的词条清单。
- 更新机制：最近一次变更是否有记录；提出入口是否对全员可见；评审是否在一周内完成。
- 可检索性：用同义词和禁用写法搜索，能否找到对应标准词条。
建议每季度做一次全表复核，重点检查长期未更新但引用频繁的词条，以及新增文档中反复出现却未收录的词。复核结果作为下一轮收录和废弃的依据，让术语表随文档实践持续收敛。
常见问题
术语表首版应该收多少条词条？
建议首版控制在几十条以内，以“近三个月文档评审中被指出写法不一致的词”为起点，再补少量领域核心概念。首版的目标是跑通提出、评审、发布、变更的流程，让团队形成使用习惯，而不是一次收全。词条数量少，评审周期短，责任人也能逐条核对定义质量。等流程稳定后，再按季度复核逐步扩充。
同一个概念在不同团队叫法不一样，术语表怎么处理？
确定一个标准中文名，其余叫法放入同义词字段，明确不用的写法放入禁用写法。如果两个叫法指向同一含义，合并为一条词条；如果同一词在不同场景含义不同，拆成两条并在定义中写明适用范围。判断标准是：两个词条能否互换使用而不改变句意，能互换就合并。禁用写法要覆盖实际出现过的错法，包括缩写、旧称和翻译变体，这样评审时才有依据指出错误写法。
术语表由谁维护？小团队需要设几个角色？
建议设三个角色：提出人、评审人、词条责任人。提出人可以是任何团队成员；评审人由领域专家加文档负责人组成；词条责任人负责定义准确和变更响应。小团队可由同一人兼任评审与责任人，但要区分动作，避免自己提、自己评、自己发布而缺少核对。关键是每个状态都有明确的责任人和进入下一状态的条件，评审周期建议控制在一周内，超时默认退回补充信息。
术语表发布后，怎么让写作者真的去查、去用？
三个动作能明显提高使用率：在文档模板开头放术语表入口；在文档评审清单中加入“关键术语与术语表一致”一项；新词条发布时在团队频道通知并附一句用法示例。此外，用同义词和禁用写法都能检索到标准词条，写作者才愿意查。术语表参与文档生产流程，而不只是存档，使用率才会稳定下来。
旧词条废弃后，历史文档里的写法要全部改吗？
不必一次性全改。废弃词条保留在表中并标注替代词，旧写法移入禁用写法，方便检索到历史文档。引用处按清单逐个替换，优先处理对外文档和高频引用的文档，替换完成后才关闭该词条。历史归档文档可以保留原写法，但要在词条中记录废弃时间和替代关系，避免后续读者混淆。
