同一概念在界面各处使用同一措辞
别名: 交付内措辞一致 · same wording across surfaces · 跨屏同词
概念解释
一次交付里出现的多个屏幕，会把同一对象叫成不同的名字，而实现会把每个名字都做成真的。跨屏同词（surface-consistent wording）要求：在这一包要发出去的画面、标注和字符串表里，同一个概念只用同一个已选定的说法——导航上叫「工作区」，设置里就不要改口「项目」，空操作的按钮也不要再写成「新建空间」。它检验的是这一次发运材料有没有自相矛盾，不是去建立全产品词库、禁用词和迁移流程。
选哪个词可以在发运前改；发出去的材料里同时存在两个词，实现没有仲裁权，只会全做上。
机制
实现按屏幕抄字符串，不按概念去重。列表页写「归档」，详情页写「结束」，确认框写「关闭」，三个动词会变成三个函数名、三条帮助搜索词、三种用户心智。设计文件里这些差异常常来自不同帧的作者、不同时间的改稿，或某一帧为了塞进窄按钮而换了近义词。视觉走查很难抓住它：三帧分开看都通顺，矛盾只在把同一任务的入口句并排时才出现。
交付包是工程看见的唯一原文集合。包内不一致会以「都是设计说的」身份进入代码，事后再统一要改标识符、改翻译键、改已经学会旧叫法的用户。同词不是文风偏好，是让这一包里的概念在进入代码之前先收敛成一个表面形式。窄处塞不下时，该改布局或改短标签的批准形式，而不是偷偷换一个近义动词。
边界
同一概念在按钮上的短标签和在说明段落里的全称可以并存，前提是交付里写明二者指向同一概念、短标签是谁的缩略。引用用户自己起的名字、引用法律原文、引用第三方产品名，必须保持来源措辞，不能为了内部整齐而改写。向导里为了教学故意先用日常说法、再过渡到产品名，需要把过渡写进该流程的帧，避免其它入口提前使用教学用词。不同用户角色看到的是不同概念（管理员的「成员」与访客的「参与者」若权限模型本就不同）时，强行同词会抹掉区分——先确认是不是同一个概念，再谈同词。
怎么落地
- 发运前把本包全部可见字符串按概念归堆：同一对象、同一动作、同一状态各只留一个选定说法，把其它说法标成待改，而不是留给实现「都可以」。
- 窄按钮需要更短的字时，在交付里登记该短标签为这一概念的批准短式，并在所有同样窄的位置复用，禁止每一处各自缩写。
- 字符串表用同一键供应所有出现点；禁止为了某一帧的版面另开一个近义键。
- 抽一条主路径，把沿途所有对同一对象的叫法抄在一张表上。出现两个词，就改设计源和文案源直到只剩一个，再交给实现。不要在代码审查里才做同义词合并。