周五发布前，给支付团队建一份能直接执行的产品术语表

周五要发布余额提醒，界面写“充值”，帮助中心写“付款”，客服模板又写“购买额度”。用户需要猜测：这三处说的是同一个动作吗？先打开共享表格、测试环境和文档仓库，沿着一条支付路径建立术语表。第一版只处理本次发布会出现的词，让团队当天就能使用。

1. 沿着充值路径收集真实用词

从余额页进入充值页，完成一次测试支付，再查看到账提示和帮助文章。把按钮、字段、状态及错误提示中的关键名称逐项复制到表格，每项附上页面地址或文件路径。先收集十五到二十个词，保留冲突写法，不急着改名。

优先记录影响操作判断的词，例如“账户余额”“充值金额”“支付失败”。“立即”“轻松”这类表达可以留给文案规范处理。术语表首先要回答：这个词指什么，用户看到它应该理解什么。

2. 为每个概念建立一条记录

建立以下字段，并让每条记录只描述一个概念：

• 概念编号：使用稳定编号，例如 TERM-001，改名时保留。
• 首选名称与定义：团队统一使用的名称，以及它的具体含义。
• 替代写法与禁用写法：注明允许条件和停用原因。
• 适用范围与例句：标明界面、文档或接口中的用法。
• 负责人、状态与更新日期：说明由谁确认，是否可以正式使用。

如果“额度”同时指账户资金和请求次数上限，就拆成两条概念。把不同含义塞进同一行，后续搜索和翻译都会继续出错。

3. 用实际场景检验定义

先填写最容易混淆的一组词。“账户余额”可定义为“账户中可用于支付后续用量费用的金额”；“充值”是向账户增加资金的操作；“支付”是结算该笔订单的动作。这样，用户支付成功后，系统还可能处于等待余额更新的阶段。

请产品和开发各检查一个边界情况：赠送金额是否计入余额？支付成功是否意味着充值到账？答案如果不同，就先修正定义或拆分状态，再确定名称。不要用“余额就是可用余额”这样的循环解释填满表格。

4. 在真实句子里选定首选名称

将候选词放回按钮、提示和文章标题中朗读。“充值成功，账户余额已更新”能否准确描述系统行为？“购买额度”是否让用户误以为买到了固定请求次数？依据产品事实、已有用户习惯和句子可读性选词，并记录选择理由。

同时写清适用边界：中文界面可以统一显示“账户余额”，接口字段仍保留现有标识。字段名、日志值和历史订单状态需要单独评估，避免一次文字统一意外改变程序行为。

5. 为跨语言协作添加上下文

需要翻译时，为每种目标语言增加对应列，并附上页面位置、完整例句及长度限制。不要让译者只看到孤立的“额度”。同一个中文词在资金、速率限制和套餐权益里可能对应不同概念，应当回到概念编号分别处理。

如果团队已经用脚本调用模型整理候选词，可以考虑 RelayVano，按量调用并通过兼容 OpenAI 的 SDK 接入 https://api.relayvano.com。注册 RelayVano 后，可先拿一页不含敏感信息的文案试跑；让模型提出疑似冲突，由负责人确认并入表。

6. 按范围替换并检查命中结果

给本次涉及的记录标记“已批准”，再到界面资源、帮助文档和客服模板中搜索旧词。逐条查看上下文后替换：旧词可能属于另一个概念，也可能出现在用户引用或历史记录中。每完成一处，就在清单里记录修改位置。

对于明确禁用的写法，可以在持续集成中增加文本检查，并排除生成文件和历史归档。第一轮先输出提醒；确认误报范围后，再决定哪些命中需要阻止合并。

7. 用一次完整操作验收术语

回到测试环境，再走一遍充值、支付和到账流程。对照术语表检查按钮、通知、错误提示及帮助链接，确认同一概念使用相同名称，不同状态仍然有清楚区别。

最后指定一位维护人，并在变更模板里加入“新增或修改了哪些概念”。新词先提议、再确认、后发布；旧词保留停用记录。下次有人询问“这里该写余额还是额度”，团队就能直接找到定义、例句和决定依据。