# 用 AI 整理产品术语表：让同一个词在不同页面保持清楚的含义

本文包含指向 SunAPI 的介绍性链接。下文的资料管理产品、术语与页面均为虚构，用来说明一种编辑辅助流程。文章不声称 SunAPI 自带术语库，也不把模型提出的解释当成产品官方定义。团队需要确认术语含义、适用范围和维护责任，再决定如何在公开内容中使用。

一个产品从几篇说明发展到几十页文档后，同一个概念可能出现多个名称。某页写资料夹，另一页写集合，第三页又使用内部开发代号。读者很难判断它们是同一功能还是不同功能。AI 可以帮助发现候选术语与相似表达，但若直接要求生成完整词典，模型也可能补入产品从未定义的概念。术语整理应从实际用法开始，让每条定义都有来源和确认状态。

本文采用虚构的共享资料应用。产品有用于组织条目的清单、用于给条目标记主题的标签，以及允许他人查看的公开页面。团队希望统一帮助文档，但不想把所有相近词都强行合并。流程的目标是识别含义差异、形成可审阅定义，并帮助编辑在后续写作中选择准确表达，而不是追求一张词条最多的表格。

# 先明确术语表服务谁

面向用户的术语表与内部开发词典不同。用户需要理解功能和操作，开发者可能需要对象名称和实现关系。若把二者混在一起，定义会变得难读，也可能暴露无关内部细节。首先决定本轮整理的读者、语言和内容范围，再选择来源。

虚构团队只处理新手帮助文档中的界面概念，不处理后台表名或代码变量。内部代号可以作为编辑参考，但不会自动成为公开词条。这个边界让模型知道哪些候选不应纳入。若将来需要开发词典，可以建立相关但独立的资料集，明确映射关系，而不是让一个词条同时承担所有读者的解释需求。

# 从实际页面提取候选词

选取已批准、与当前产品版本一致的页面，保存标题、正文片段和版本。AI 可以提出重复出现的名词、界面标签与可能同义表达。每个候选都应附上用例，方便编辑判断它是不是稳定概念，而不是某个句子里的普通用词。

不要让模型只根据产品简介扩展一整套常见功能词。其他资料产品可能有工作区或收藏夹，不代表当前产品也有。候选词的存在需要源内容支持。对于仅在旧文档出现的词，保留历史状态并检查是否已废弃。来源越清楚，团队越容易决定是统一名称、补充解释，还是修正一篇使用了错误概念的文章。

# 区分界面标签和概念名称

一个概念可能在界面中通过短标签呈现，而正文需要更完整的解释。界面按钮“共享”与概念“只读公开页面”不一定能互换。术语表应记录名称类型，让编辑知道何时必须保持标签原样，何时可以使用概念的完整名称。

若产品有多个界面语言，标签还需要对应具体版本。不能把模型自然翻译的词当成已经上线的正式名称。对于未确认映射，标记待核实。术语统一不是让所有地方机械使用同一个字符串，而是让表达与场景一致。界面提示、帮助步骤和概念介绍有不同功能，定义应帮助编辑选择，而不是消除必要的语言差异。

# 让每条定义回答具体问题

一条有用定义通常说明它是什么、用于什么，以及与最容易混淆的概念有什么区别。例如，标签用于给条目标记主题，清单用于组织一组条目。具体规则仍需来源支持，不能仅凭名称推断一个条目能有多少标签或是否允许跨清单移动。

AI 可以起草定义并列出依据不足的部分。编辑应允许定义暂时不完整，而不是要求每条都填入限制、示例和高级用途。若来源只说明基本功能，就先写基本含义，并提出需要负责人确认的问题。词条的价值来自准确和可用，不来自长度。一个简短但有明确范围的定义，比包含多种虚构行为的完整段落更适合维护。

# 对相近词保留差异证据

模型可能把集合、清单和资料夹判断为同义词，但需要检查实际上下文。它们可能指不同层级，或反映历史命名变化。要求输出共同点、差异片段与建议处理方式，让编辑决定合并、建立参照或保留独立词条。

合并会影响多个页面，不能只因字面相似就执行。若确认是同一概念，可以选择正式名称，记录旧名称与替换条件。若是不同概念，则明确区别和使用例子。不要让读者在术语统一之后反而失去原本能分辨的功能边界。相似表达的处理是产品知识判断，AI 提供线索与草稿，不拥有最后定义权。

# 建立词条状态与负责人

术语表可以包含候选、待确认、已批准、历史名称和不建议使用等状态。每个状态的含义要清楚，并与应用行为对应。候选词不应在写作工具中被显示为必须遵守的官方规则。历史名称可以帮助理解旧内容，但不一定适合新文章。

负责人应来自团队明确安排，不由模型根据出现频率或作者姓名猜测。定义更新需要记录原因、来源版本和适用日期。这样，后续编辑遇到疑问时有清楚的确认路径。没有维护责任的术语表很容易变成另一个过时文件。状态与负责人让整理成果进入实际工作，而不是在一次生成后被当成永远正确的词典。

# 使用 SunAPI 起草定义与比较说明

开发团队可以参考 SunAPI 文档，核对当前请求格式和响应处理。应用提供获准使用的页面片段、候选词与定义规则，让模型返回草稿和证据。产品事实确认、来源存储和批准流程由应用与团队管理，不会因接口生成文字自动完成。

密钥放在服务端，只提交任务所需资料。保存术语表版本、来源版本与提示规则，便于比较后续结果。验证时可以使用虚构概念，检查模型是否会增加数量限制、权限说明或未存在的功能。配置选择要依据实际表现和审阅要求，而不是宣称某种模型能自动建立完全准确的产品知识库。生成阶段的目标是让定义更容易核对。

# 把定义正文与内部讨论分开

公开定义应简明清楚，内部讨论可以保留来源差异、未解决问题和决策理由。两者在界面和导出时需要明确区分。否则，编辑可能把内部备注复制到文章，或者误把一段讨论建议当成已经批准的规则。

输出结构可以要求词条编号、推荐名称、定义、使用场景、来源与问题列表。普通代码检查编号和字段，但不能证明定义语义正确。若结构无效，应保留草稿状态并说明原因，不静默删除出错部分后显示完成。编辑需要知道哪些词条没有处理好，尤其当它们与大量页面关联时，遗漏可能影响后续统一工作。

# 用真实句子验证定义是否实用

定义写得好听，还需要能指导实际写作。选取几个来源句子，让编辑判断应该使用哪个词，以及替换后含义是否保持。若规则无法解决常见场景，可能需要补充使用条件，而不是继续润色定义。

例如，一句话正在描述按钮操作，应保留按钮标签；另一句话介绍只读功能，可以使用概念名称。模型可以提出替换候选，但编辑核对界面和语境。不要把术语一致性变成全站查找替换。某个词可能出现在引用、历史说明或不同概念中，机械替换会制造新错误。术语表应帮助理解每次使用，而不是让编辑放弃判断。

# 处理不同语言的对应关系

若团队维护多语言内容，可以为同一概念记录各语言已批准表达，但不要假设每个词都有一对一对应。某种语言可能需要短解释，某个界面仍保留原文标签。记录这些情况比强行填满对照列更可靠。

AI 可以提出翻译候选，不能将其自动升为正式用语。需要了解产品和相关语言的人审阅。不同语言的定义也要与同一概念版本关联，避免一个版本已更新权限条件，另一个仍保留旧规则。本文不评价特定语言的翻译质量；这里强调的是应用如何保存决定，让后续编辑知道哪些表达已经确认，哪些仍需要讨论。

# 更新术语时定位受影响页面

批准新名称后，应用可以查找相关用例，生成待审列表。每条展示原句、建议改法和上下文。不要直接覆盖所有命中，因为同一个词可能在不同位置承担不同作用。历史引用、界面截图说明和普通语言表达需要分别判断。

维护记录应注明哪些页面已经更新，哪些暂未处理，以及原因。术语表变化不等于所有公开内容已经同步。若某页仍使用旧名称，可以根据站点规则安排修改，而不是让系统把待处理状态隐藏起来。可追踪更新能减少下一轮重复检查，也避免不同编辑对当前进度作出相反理解。

# 识别来源冲突而不自行调和

若两篇现行说明对清单含义有不同描述，模型应引用冲突并提出具体问题。不要拼成一个兼容所有说法的新定义，那可能创造产品从未支持的行为。负责人需要确认哪一处应修正，或是否存在未被写清的条件差异。

有些冲突来自版本，有些来自作者用词不一致，还有些暴露产品规则本身尚未明确。分类有助于安排处理。术语整理工具应允许冲突未解决时暂停批准相关词条，而不是为了完成度强制选择一边。词典里出现待确认提示，通常比一个看起来权威却没有证据的定义更能保护编辑质量。

# 建立验证样例与反馈循环

验证集可包含同词不同义、不同词同概念、旧名称、界面标签和缺少定义来源的候选。提前写好预期，检查模型是否保留条件并承认未知。还要测试无效引用、处理中页面更新和重复合并建议，让应用状态可靠。

记录编辑修改原因，区分事实错误、范围过宽、表达不清和不必要合并。根据这些信息改进来源准备与输出规则。评价不只看提取多少词，而要看词条能否帮助编辑作出更准确选择。报告结果时说明文档范围，不把有限内部样例扩大成自动统一所有产品知识的保证。工具应降低维护成本，同时保留必要的专业判断。

一份有用术语表连接实际用法、已确认含义与持续维护。AI 可以加快候选提取、比较和定义起草，团队负责决定概念边界与正式表达。通过来源、状态和上下文检查，术语统一不再只是替换文字，而是让不同页面对同一个功能保持可理解的一致性。最终读者更容易知道自己看到的词指什么，编辑也更容易解释为什么在某个位置选择了这个名称。