术语规范的核心是一张可填写的术语表：每条术语写清标准名、禁用或慎用写法、定义、适用范围、正反示例和负责人。本文给出一个虚构团队知识库场景下的术语表填写示例，逐项解释每个字段为什么这样写，再提炼可迁移到其他术语的填写规律，并说明示例的适用边界。
要点总览（TL;DR）
- 术语规范的核心是一张可填写的术语表，每条至少写清标准名、禁用或慎用写法、定义、适用范围、正反示例和负责人。
- 示例给出五条虚构术语条目，覆盖工作项、需求、缺陷、迭代和验收标准，并保留“评审中”状态演示术语需要持续维护。
- 字段填写有依据：禁用写法来自文档盘点，定义写到能判断对象归属，适用范围限定到具体文档类型，正反示例使用可直接出现的真实句式。
- 迁移到自团队时，先按歧义程度和使用频率筛选十到二十条候选术语，再按统一模板填写，并处理术语之间的引用与冲突。
- 示例为虚构情景，行业强监管术语、法律定义需专业人员确认；术语表规模扩大后需要按模块拆分并指定分领域负责人。
示例目标：这份术语表要解决什么问题
先设定一个虚构情景：某产品团队维护一个内部知识库，成员来自产品、研发、测试和运营，日常在需求文档、接口说明、测试用例和对外文案中反复使用同一批业务词。团队发现，同一个概念在不同文档里有三四种叫法，检索时经常找不到；有些词在不同模块里指的不是同一件事，读者需要靠上下文猜测；新成员入职后要花时间辨认哪些写法是团队认可的。这个情景用于演示填写方式，不代表任何真实团队。
术语规范要解决的具体问题可以归为三类。第一类是同一概念多种叫法，例如“用户”与“客户”、“账号”与“账户”混用，导致检索和引用失效。第二类是同一词指不同对象，例如“订单”在交易模块指待支付单据，在履约模块指已确认的发货任务，读者无法判断当前语境。第三类是新人理解成本，缺少统一定义时，新人只能从零散文档中拼凑含义，容易形成错误理解。
据此设定示例的验收标准：读者看完本文后，能照着样例为自团队的术语填出一张表，每条术语至少包含标准名、禁用写法、定义、适用范围和示例五项，并能判断哪些术语值得优先纳入。这个标准也是后文评价示例是否够用的依据。
完整示例：一份术语表填写样例
下表是一份已填写的术语表样例，团队名称、术语条目和示例句子均为虚构，用于演示字段如何落地。条目之间保持定义口径一致：凡涉及“工作项”的术语，都指向同一层含义，避免互相矛盾。
| 标准术语 | 英文或缩写 | 禁用/慎用写法 | 定义 | 适用范围 | 正例 | 反例 | 负责人 | 状态 |
|---|---|---|---|---|---|---|---|---|
| 工作项 | Work Item | 慎用：任务、事项、条目 | 团队在项目中跟踪的一项可分配、可流转状态的工作单元，包含需求、缺陷、任务等类型 | 项目协作与研发管理相关文档 | “该工作项已从进行中流转到待验证。” | “这个任务已经做完了。”（在需要区分类型时使用“任务”会造成歧义） | 知识库管理员 | 已发布 |
| 需求 | Requirement | 禁用：诉求、需要点 | 描述用户或业务需要被满足的内容，是工作项的一种类型，需经过评审后进入开发 | 产品规划与需求管理文档 | “需求评审通过后，拆分为若干开发工作项。” | “客户提了个诉求，先记下来。”（正式文档中应写“需求”） | 产品负责人 | 已发布 |
| 缺陷 | Defect | 慎用：Bug、问题单 | 产品行为与预期不一致的可复现问题，是工作项的一种类型，需记录复现步骤与影响范围 | 测试与质量相关文档 | “该缺陷已复现，影响范围为登录模块。” | “有个 Bug 回头再看。”（正式记录应写“缺陷”并附复现信息） | 测试负责人 | 已发布 |
| 迭代 | Iteration | 慎用：周期、Sprint | 团队按固定时间盒推进工作项交付的一个计划单元，有明确的起止日期与目标 | 研发计划与进度同步文档 | “本迭代目标包含三个需求与五个缺陷修复。” | “这个周期先把活干完。”（正式计划中应写“迭代”并注明起止） | 项目负责人 | 评审中 |
| 验收标准 | Acceptance Criteria | 禁用：验收条件、通过标准 | 判断一个工作项是否完成的可核验条件，逐条描述预期结果 | 需求与测试文档 | “验收标准：登录失败三次后锁定账号十分钟。” | “差不多能用就算通过。”（缺少可核验条件） | 产品负责人 | 已发布 |
这张表刻意保留了“评审中”状态，用来演示术语并非一次定稿。表格之外，团队通常还需要一句总则，例如“本表未收录的词，按现有文档中最常见的写法使用，并在下次评审时补充”，避免读者遇到空白时无从判断。
逐项解释：每个字段为什么这样填
标准术语与禁用写法的对应关系，来自对现有文档的实际盘点，而非凭感觉指定。做法是把近几个月的文档、工单和聊天记录中出现的同义写法列出来，按出现频率和歧义程度排序，把最容易造成误解的写法列为禁用，把仅在口语中可接受、正式文档应避免的写法列为慎用。示例中“任务”被列为慎用而非禁用，是因为它在“工作项类型”语境下仍有明确含义，全面禁用反而增加表达负担。
定义的颗粒度以“读者能据此判断一个对象是否属于该术语”为准，通常一到两句话，写清本质属性、所属类别和关键约束。示例中“缺陷”的定义包含“可复现”“与预期不一致”“工作项的一种类型”三个要素，读者遇到一个具体问题时能据此判断该不该记为缺陷。要避免循环定义，例如“需求就是用户提出的需求”，这类写法没有增加任何信息，应改为描述对象来源、用途和流转条件。
适用范围用来限定术语在哪些文档或业务环节生效。示例中“迭代”限定在研发计划与进度同步文档，是因为运营侧另有“活动周期”的说法，若不限定，两个场景会互相污染。适用范围写得越具体，跨场景误用越少；范围过宽等于没有限定。
正反示例应使用真实句式，而不是抽象说明。“该工作项已从进行中流转到待验证”是一句可以直接出现在文档里的句子，读者能对照自己的写法判断对错；写成“正确使用工作项一词”则无法指导实际写作。反例要指出问题所在，例如缺少复现信息、在需要区分类型时使用了笼统说法，让读者知道错在哪里而不只是知道错了。
负责人和状态字段解决的是维护责任问题。负责人是这条术语的最终解释人，遇到争议时由其裁定；状态用“评审中”“已发布”“待修订”等简单取值，让读者知道当前条目是否可以直接引用。没有负责人和状态的术语表，容易在几个月后变成无人维护的过期清单。
可迁移规律：换一批术语怎么照样填
换一批术语时，第一步是收集候选而不是直接开写。可以从三个来源收集：高频出现的业务名词、已经产生过歧义的词、新人反复询问的词。收集后按“歧义程度×使用频率”排序，优先处理既高频又容易混淆的术语，低频且含义稳定的词可以暂缓。一次纳入十到二十条，比一次铺开上百条更容易评审和落地。
第二步是按统一模板填写。每条术语固定回答五个问题：标准写法是什么、哪些写法应避免、它指什么、在哪些场景生效、正确和错误的句子各是什么。可以把模板写成可复制的结构：
- 标准术语：
- 英文或缩写：
- 禁用/慎用写法：
- 定义（一句话说清本质属性与类别）：
- 适用范围（文档类型或业务环节）：
- 正例（可直接使用的句子）：
- 反例（指出具体问题）：
- 负责人与状态：
第三步是处理术语之间的引用与冲突。当一条术语的定义依赖另一条术语时，直接引用标准名，例如“需求是工作项的一种类型”，而不是重复解释“工作项”的含义，避免两处定义随时间漂移。当两条术语出现含义重叠时，先判断是否真的指同一对象：确实同义则合并为一条，把另一写法列入禁用；指向不同对象则分别保留，并在适用范围中写清区分条件。
第四步是建立轻量评审与更新机制。新术语先以“评审中”状态提交，由相关模块负责人确认定义和示例后改为“已发布”；已有术语在业务含义变化时改为“待修订”，修订完成再发布。评审不必复杂，一次短会或文档评论即可完成，关键是留下谁在何时确认过的记录。术语表承载在知识库文档中时，可以借助文档模板统一格式、借助版本记录追溯每次修改。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，并记录页面版本、支持查看与回滚，适合把术语表作为一份持续维护的文档来管理；具体模板配置以实际产品界面为准。
适用边界：示例不能直接照搬的地方
本文的术语条目、团队名称和示例句子均为虚构，用于演示填写方式，不代表任何真实团队的做法，也没有经过实测验证效果。读者可以参考字段结构和填写思路，但具体术语的标准名、禁用写法和定义，必须根据自团队的文档现状重新确定。
本文范围限于知识表达层面的术语规范，需求文档模板的具体内容、研发流程制度的设计与标准化不在讨论范围内。术语表能统一叫法，不能替代流程设计；把术语规范当成流程文档使用，会超出它的作用范围。
行业强监管领域的术语、法律定义和合同用语，需要由法务或合规专业人员确认后再纳入术语表。这类术语的细微差别可能带来实际责任，示例中的填写方法只能作为组织信息的框架，不能作为含义判断的依据。
当术语表规模扩大到数十条以上时，维护成本会明显上升：跨模块的引用关系变复杂，评审排期变长，过期条目难以及时发现。此时需要考虑按模块拆分术语表、指定分领域负责人，并定期清理长期未更新的条目。示例展示的是小规模起步阶段的写法，规模变大后的组织方式需要另行设计。
常见问题
术语表刚起步，应该先收录哪些术语？
优先收录两类：一是高频出现且已经产生过歧义的词，二是新人反复询问的词。判断时可以把近几个月的文档、工单和聊天记录中出现的同义写法列出来，按出现频率和歧义程度排序。一次纳入十到二十条，比一次铺开上百条更容易评审和落地；低频且含义稳定的词可以暂缓，等术语表运转起来后再补充。
同一个词在不同模块含义不同，应该合并成一条还是分开写？
先判断是否真的指同一对象。确实同义则合并为一条，把另一种写法列入禁用或慎用；指向不同对象则分别保留，并在各自的适用范围中写清区分条件。例如“订单”在交易模块指待支付单据，在履约模块指已确认的发货任务，这种情况适合分开写，并在定义中说明所在业务环节，避免读者靠上下文猜测。
术语表放在知识库里，怎么保证大家用的是最新版本？
可以从三件事入手：给每条术语设置负责人和状态，让读者知道当前条目是否可以直接引用；新术语先以“评审中”提交，确认后再改为“已发布”；业务含义变化时改为“待修订”，修订完成再发布。术语表承载在知识库文档中时，可以借助文档模板统一格式、借助版本记录追溯修改。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，并记录页面版本、支持查看与回滚，适合把术语表作为一份持续维护的文档来管理；具体模板配置以实际产品界面为准。
行业里有法定含义的术语，能直接按示例的方法写吗？
不建议直接照搬。法律定义、合同用语和强监管领域的术语，细微差别可能带来实际责任，需要由法务或合规专业人员确认后再纳入术语表。示例中的字段结构可以作为组织信息的框架，帮助把标准名、定义、适用范围和示例放在一起，但含义判断应以专业确认结果为准。
术语表条目变多以后，维护不动了怎么办？
规模扩大到数十条以上时，跨模块的引用关系会变复杂，评审排期变长，过期条目也难以及时发现。可以考虑按模块拆分术语表，为每个模块指定负责人，并定期清理长期未更新的条目。评审机制保持轻量即可，一次短会或文档评论就能完成确认，关键是留下谁在何时确认过的记录。
