术语表上线后，真正决定它能否长期可用的，是新增、变更、冲突和废弃这四类日常动作有没有统一载体和明确责任人。本文给出一套轻量维护机制：用统一的条目字段和状态承载所有操作，新增走四步流程，变更留版本与影响记录，冲突先分类再处理，废弃用停用标记替代删除，并配套角色分工与检查清单，可直接套用到已有初版的术语表上。
要点总览（TL;DR）
- 术语表上线后的维护底座是统一的条目字段与状态流转：标准术语、别名、定义、适用范围、负责人、状态、版本、生效日期缺一不可，状态覆盖草案、评审中、已发布、已停用。
- 新增术语走“提出—查重—评审—发布”四步，每步明确输入、动作、输出与完成标志，查重结论要记录在提案上，避免重复条目。
- 变更先分类（定义微调、名称调整、范围变化），再记录变更前后对照与影响文档清单，按对外可见程度排优先级完成引用更新。
- 冲突以定义与使用场景为判定依据，分同义不同名、同名不同义、跨团队叫法不一致、与外部标准不一致四类处理；未决时标注待定、限定范围并指定裁决人。
- 废弃采用停用标记加别名指向替代术语，定期盘点确认无有效引用后再归档，直接删除仅适用于从未发布的误建条目。
术语表维护的核心机制：条目字段与状态流转
维护机制能否运转，取决于每个术语是否有固定的“容器”。建议先统一术语条目字段，让新增、变更、冲突、废弃都落在同一张表或同一套页面结构上，而不是散落在聊天记录和零散文档里。
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 标准术语 | 团队正式使用的名称，唯一 | 作为写作与检索的基准 |
| 英文/别名 | 英文写法、历史叫法、常见缩写 | 支撑查重与检索命中 |
| 定义 | 一句话说明所指对象，可验证 | 判定同义、多义的核心依据 |
| 适用范围 | 适用的产品、团队或业务场景 | 处理跨团队叫法不一致 |
| 反例或易混词 | 容易混淆的相近术语及区别 | 减少误用 |
| 负责人 | 该条目的维护人 | 明确受理与推进责任 |
| 状态 | 草案、评审中、已发布、已停用，可按需增加待合并 | 标识条目当前可用性 |
| 版本 | 每次实质修改递增 | 支撑变更追溯 |
| 生效日期 | 状态变为已发布的日期 | 界定新旧写法的切换点 |
状态流转需要绑定触发条件与权限：草案由提出人或术语负责人创建；提交评审后进入评审中，由评审人推进；评审通过后由术语负责人发布为已发布；确认不再使用时改为已停用。待合并状态用于冲突已识别但尚未裁决的条目，避免它被当作正式术语使用。
维护节奏建议采用“定期评审会加临时提案”的组合：每月或每两周一次固定评审会，集中处理积压的新增与冲突；日常通过提交入口随时受理，紧急术语可走临时评审。频率按团队术语产出量调整，产出少的团队可改为季度评审加随时提交。
新增术语：从提出到发布的四步操作
新增是最频繁的动作，用固定四步可以避免重复条目和定义含糊。每一步都要有明确输入、动作、输出和完成标志。
第一步：提出
任何使用术语表的成员都可以提出。提交时使用统一模板，至少包含：候选术语、英文或别名、候选定义、来源文档或使用场景、提出人、期望生效时间。完成标志是提案进入待处理队列，并已指派术语负责人。
第二步：查重
术语负责人先在现有术语表的标准术语和别名中检索，再在常用文档中搜索该词的实际用法。判断结果分三种：已有同义条目则归并并补充别名；已有近义但定义不同则进入冲突判定；确无对应条目则进入评审。完成标志是查重结论记录在提案上。
第三步：评审
评审人包括术语负责人和相关领域专家。判断标准有两条：该概念是否确实需要独立条目，能否并入现有条目；定义是否可验证，能否用一句话说清所指对象和边界。评审结论为通过、修改后通过或驳回，均需写明理由。完成标志是评审意见记录完整、结论明确。
第四步：发布
通过后写入术语表，补齐全部字段，状态改为已发布并记录生效日期；随后通知相关写作角色，并同步到写作规范或文档模板中引用术语表的位置。完成标志是条目可被检索到、通知已发出。
术语变更：版本记录与影响范围处理
变更的风险在于旧写法仍在流通。处理原则是先分类、再留痕、后同步，避免定义改了但文档没跟上。
变更类型可分三类：定义微调，所指对象不变、表述更准确；名称调整，标准术语本身更换；适用范围扩大或收窄，同一术语在不同场景下的边界变化。三类的影响面依次增大，名称调整和范围变化通常需要更完整的引用排查。
每条变更需记录：变更原因、变更前后对照、影响文档清单、生效日期、变更人与评审人。变更前后对照建议直接写出旧定义与新定义，便于使用方快速判断自己是否受影响。
影响处理按以下顺序进行：先检索引用该术语的文档与页面，形成影响清单；再按使用频率和对外可见程度排优先级，对外文档和规范类文档优先更新；最后在生效日期前完成高优先级更新，低优先级项列入待办并设定完成期限。通知机制上，向使用方说明变更内容、生效时间和过渡期写法，过渡期内允许旧写法但需标注。
术语冲突：类型判定与处理规则
冲突长期悬置会削弱术语表的权威性。处理时先判定类型，再套用对应规则，判定依据是定义与使用场景，而非谁先提出或谁的声音大。
| 冲突类型 | 判定依据 | 处理动作 |
|---|---|---|
| 同义不同名 | 两个名称指向同一对象，定义可互相替换 | 归并：保留一个主术语，另一个登记为别名 |
| 同名不同义 | 同一名称在不同场景指不同对象 | 拆分：拆为独立条目，加限定语区分 |
| 跨团队叫法不一致 | 各团队各有习惯叫法，指向基本一致 | 指定主术语并标注适用范围，其余登记别名 |
| 与外部标准不一致 | 团队用法与行业或客户标准存在差异 | 明确以哪一方为准，并在条目中注明差异 |
冲突未决时需要临时处置：将相关条目标注为待定，限定其使用范围，并指定裁决人（通常是术语负责人或领域专家），设定裁决期限。临时处置的目的是让写作可以继续，同时不让未定条目被当作正式术语扩散。
术语废弃：停用标记、别名保留与清理
废弃不等于删除。历史文档、检索记录和外部引用都可能指向旧术语，直接删除会造成阅读断裂和检索失效。
废弃判定条件包括：已被新术语替代、业务上不再使用、合并到其他条目。处理动作是：状态改为已停用，保留原术语作为别名指向替代条目，注明停用原因、替代术语和停用日期。这样旧文档中的写法仍能被检索到，读者也能顺着别名找到当前用法。
清理按节奏进行：每季度或每半年盘点一次停用条目，确认无有效引用后再归档到历史区。归档前核对引用情况，仍有引用的条目保留在停用状态而非移出术语表。直接删除仅适用于误建条目且从未发布、无任何引用的情况。
角色分工与交付物
维护机制要落到人。角色不必多，但每个动作都要有人负责。
| 角色 | 主要职责 |
|---|---|
| 术语负责人（维护人） | 日常受理提案、执行查重、推进状态流转、组织评审、维护条目字段完整性 |
| 评审人/领域专家 | 判断定义准确性与必要性，裁决冲突，确认变更影响范围 |
| 文档与内容作者 | 按术语表写作，提交新词与冲突反馈，配合完成引用更新 |
交付物包括：术语条目表、变更记录表、冲突处理记录、停用清单、定期评审纪要。这些记录既是维护痕迹，也是后续审计和交接的依据。术语表本身可放在团队知识库中，借助页面模板统一条目结构、借助版本记录保留修改历史、借助权限区分维护人与普通作者的编辑范围。例如 ONES Wiki 提供页面模板库用于创建制式化文档，记录所有页面版本并支持查看与回滚，支持为不同角色配置读写权限，可作为承载术语条目与变更留痕的载体之一；条目字段与状态的具体配置方式需按实际使用环境确认。
示例：一次跨团队术语冲突的完整处理
以下为演示情景。产品团队把用户提交的服务请求称为“工单”，客服团队称为“服务单”，两个团队在共享文档中混用，导致新成员理解困难。
处理过程：客服团队一名作者提交冲突提案，附上两个叫法的来源文档和使用场景；术语负责人查重后发现两条目分别存在、定义高度重叠，判定为同义不同名；评审会上，两个团队的领域专家对照定义确认指向同一对象，考虑到对外文档和客户沟通中“服务单”使用更广，指定“服务单”为主术语，“工单”登记为别名并注明适用范围为内部研发沟通；随后检索引用“工单”的文档，形成影响清单，对外文档优先改为“服务单”，内部文档在过渡期内允许使用别名；最后向两个团队发出变更通知，说明主术语、别名和生效日期。
处理后的条目状态为已发布，版本递增，变更记录中保留冲突提案、评审结论和影响清单。可迁移的规律是：冲突处理的关键不在谁让步，而在用定义确认是否同一对象，再用使用范围决定主术语，并把另一叫法保留为别名，让历史写法仍可检索。
完成检查：术语表维护是否到位
定期用以下清单自查，可以判断机制是在运转还是停留在纸面。
- 条目完整性：已发布条目是否字段齐全，状态与实际可用性一致，负责人明确。
- 新增记录：每个新增条目是否有提案、查重结论和评审意见，发布后是否通知到位。
- 变更记录：名称或定义变更是否有前后对照、影响清单和生效日期，高优先级引用是否已更新。
- 冲突闭环：每个冲突是否有结论，未决项是否标注待定、限定范围并指定裁决人和期限。
- 停用处理：停用条目是否保留别名并指向替代术语，归档前是否确认无有效引用。
- 评审节奏：定期评审是否按约定频率执行，是否留有纪要并跟踪待办完成情况。
检查中发现的问题应回到对应流程修正，而不是临时打补丁。维护机制的价值在于让术语表与实际使用保持一致，这需要持续的小幅投入，而非一次性的集中整理。
常见问题
术语表刚上线、条目还很少，需要马上建立完整的评审流程吗？
不必一开始就配齐所有环节。条目少、使用范围集中时，可以先保留“提出—查重—发布”三步，评审由术语负责人和一位领域专家口头确认并记录结论即可。当出现跨团队混用、同一概念反复被提出，或对外文档开始引用术语表时，再把评审会固定下来、增加评审人范围。机制随使用量增长而加码，比一次性搭重流程更容易持续。
同一个术语在不同产品线含义不同，是拆成多个条目还是保留一个条目加说明？
判断依据是定义能否互相替换。如果两个含义指向的对象不同、替换后会造成理解错误，就拆成独立条目，并用限定语区分，例如在标准术语前加上产品线或场景前缀。如果只是同一对象在不同场景下的表述差异，保留一个条目、在适用范围字段中写清边界即可。拆分后要在别名中互相指向，避免检索时只命中其中一个。
停用术语保留为别名后，术语表会不会越来越臃肿？
会有这个风险，所以需要配套盘点节奏。建议每季度或每半年检查一次停用条目，核对是否仍有文档或页面引用：仍有引用的继续保留停用状态，确认无有效引用的归档到历史区，从主表中移出但保留可查记录。别名本身也应定期合并，同一旧叫法只保留一条指向关系，避免多个别名指向不同条目造成新的混淆。
冲突裁决由谁做，裁决人不了解业务场景怎么办？
裁决人通常由术语负责人担任流程角色，具体判定则依赖对应领域的专家意见。做法是在冲突提案中写清双方的使用场景和来源文档，由相关团队的领域专家分别确认定义，术语负责人依据定义是否指向同一对象给出结论。遇到涉及对外承诺或客户沟通的术语，应把对外口径的负责人纳入裁决，避免内部统一后与外部表述脱节。
术语表放在知识库页面里维护，怎么保证变更后使用方真的看到了？
通知要具体到人和文档，而不是只在群里发一条消息。变更记录中列出影响文档清单后，按清单逐项通知对应作者，说明变更内容、生效时间和过渡期写法；对外文档和高频引用文档优先处理。知识库页面本身可以借助版本记录保留修改历史、借助权限区分维护人与普通作者的编辑范围，例如 ONES Wiki 提供页面模板库用于创建制式化文档，记录所有页面版本并支持查看与回滚，支持为不同角色配置读写权限，可作为承载术语条目与变更留痕的载体之一；条目字段与状态的具体配置方式需按实际使用环境确认。
