KuoHuBlog
怎么举一个优秀的例子？
不少的网页都有表单，表单是要给用户填的，既然要给用户填，就绕不开一个经典的道理：“用户永远会以你想象不到的方式使用你的产品。” 意思也就是说 永远不要相信用户的输入 。
教用户怎么正确输入，也是一个技术。很多人包括很多开发者会觉得，我第一次做设计，我甚至都不是干设计的，我怎么知道我写的提示好不好？是的，我也没做过设计。但就像以前网络上很流行的一句 “你是第一次当父母，但你不是第一次当孩子” 一样；包括遇上难用的软件，用户也会反问开发者： “你们自己用过自己的产品吗？” 也许你是第一次做设计，但肯定不是第一次做用户。
本文在此提出以下判断例子好坏的 4 个标准，和优化设计的 2 个技巧：
| 类型 | 名称 | 大意 |
|---|---|---|
| 标准 | 语法正确 | 最低要求，避免表意不明、不合逻辑等高中就教过的常见语法错误 |
| 标准 | 覆盖广泛 | 覆盖尽可能多的例子，至少举出最常见的例子而不是特例 |
| 标准 | 优先举例 | 优先给出示例而不是模板，模板容易带有一些不容易发现的歧义 |
| 标准 | 简短准确 | 不要照抄校验规则，也不要太长，适时使用表格等表达形式 |
| 技巧 | 描述后果 | 如果要让用户不要做什么，就应该告知做了后果是什么 |
| 技巧 | 优先选择 | 如果能让用户选择，尽量避免让用户填空 |
接下来会详细描述这些标准、技巧及适用范围。
标准 1：语法正确
语法正确不论放在什么地方都是非常重要的，在谈论怎么判断语法正确之前，不妨先复习一下高中知识，有哪些常见的语法错误呢？
| 大类 | 大意 | 小类 | 要点 |
|---|---|---|---|
| 语序不当 | 顺序反了 | 多重定语 | 领属的-指示代词-数量-动词-形容词-名词 |
| 多重状语 | 目的/原因/条件-时间地点-范围-情态/程度 | ||
| 定状错位 | - | ||
| 关联词位置 | 分句同主语，关联词靠后； 分句换主语，关联词靠前。 | ||
| 并列词位置 | 并列词语的轻重、先后、大小 | ||
| 主客位置 | 主客颠倒，谁对谁怎样 | ||
| 搭配不当 | 搭配错了 | 主谓搭配不当 | - |
| 动宾搭配不当 | - | ||
| 主宾搭配不当 | - | ||
| 修饰中心不当 | - | ||
| 结构混乱 | 结构乱了 | - | 多种句式结构混乱 |
| 表意不明 | 意思糊了 | 歧义 | - |
| 指代不明 | - | ||
| 不合逻辑 | 逻辑混了 | 不符合事实 | - |
| 自相矛盾 | - | ||
| 概念并列不当 | 概念交叉、概念种属、概念混搭 | ||
| 一面对两面 | |||
| 成分缺余 | 成分歪了 | 缺主语 | 慎用介词：使、让、对…… |
| 缺谓语 | - | ||
| 缺宾语 | - | ||
| 成分赘余 | 主语赘余、谓语赘余、宾语赘余、表意赘余 |
其中我加粗的几个是在各种引导提示中最常见的语法错误，接下来会一一说明。剩下的可能更多在质量比较低的机翻文档中见到，不过那属于怎么把话说顺，不在这篇文章的讨论范围内，不过如果是中文母语者的话，我觉得应该也不会那么容易犯语序不当这种错误。
1.1.1 歧义
歧义是一个非常常见的问题。举一个有歧义的例子：
请上传你的简历和作品集或推荐信
请上传你的简历，并上传作品集或者推荐信
在错误示例中，就会呈现两种理解：
- （简历）和（作品集或推荐信）——作品集和推荐信二选一
- （简历和作品集）或（推荐信）——简历和作品集是捆绑的，或者单独给推荐信
这种由滥用连词和缺少标点导致的断句歧义是最常见的。当然还有很多类型的歧义暂时没有提到，因为在写提示语时，多数歧义并不是单纯的歧义，而是往往伴随着指代不明、滥用特例等其他问题。
接下来会对这些尚未提到的情况做更详细的解释。
1.1.2 指代不明
You are unlikely to be verified until you have completed your GitHub user profile with your full name exactly as it appears in your academic affiliation document. Please do not use a variation of your name or a nickname. Once you have updated your profile information log out and log back into GitHub before re-applying.
除非您已在 GitHub 用户资料中填入与学术隶属文件完全一致的全名，否则您不太可能通过验证。请勿使用名字变体或昵称。更新个人资料信息后，请登出 GitHub 并重新登录，然后再次申请。
这是我在第一次申请 GitHub Student Developer Pack 的时候被打回的消息，里面提及的一个原因。这里的 GitHub user profile 和 full name 就是指代不明的典型，到底是我 Public Profile 里的 Name 还是 Billing information 里的 First name 和 Last name 呢？或者也许是我的 username ？
那肯定有人会说这不是给你标了个链接吗？这个问题问得很好，我会在 1.2.1 自相矛盾的部分说明为什么这仍然是一个坏提示。
1.2.1 自相矛盾
紧接着上一章节 1.1.2 指代不明的例子，为什么这个提示仍然是个坏提示呢？点开这个链接，翻到 Changing your profile name，注意到这段赫然写着
Your GitHub profile name does not need to correlate with your real-world identity.
你的 GitHub 个人资料名称无需与现实身份对应。
所以这个提示就是既指代不明又自相矛盾的。
如果你仍然不甘心，去他们的常见问题里翻了翻，看见了这个：
Ensure your billing information and identification on your academic evidence are accurate. Do you use a variation of your name or a nickname? It’s these small but important points to consider when applying that can make a much smoother process.
确保您的 账单信息 及 学术证明文件 上的身份信息准确无误。您是否使用过姓名变体或昵称？申请时考虑这些细微但重要的细节，将使整个流程更为顺畅。
用户看到这个 FAQ 可能感觉稳了，就是去改 billing information 上的姓名。但真的是吗？因为后续多次我提交被拒，去发了工单，问了这个姓名的问题
Q: Regarding GitHub Education’s suggestion to update my “full name” to my real name: Which specific “full name” field does this refer to?
Q：关于 GitHub Education 建议我将”全名”更新为真实姓名：具体指哪个姓名字段？
A: This is referring to the Name field in your GitHub public profile settings.
A：指的是您 GitHub Public Profile 设置中的 Name 字段。
你能在文档、社区、支持找到三种答案，这就是 自相矛盾 。
1.2.2 概念并列不当
概念并列不当分为 概念交叉 、 概念种属 和 概念混搭 ，接下来会一一解释。
1.2.2.1 概念交叉
有趣的是，GitHub 这个例子不仅“自相矛盾”，还同时犯了 概念并列不当 的毛病——Public Profile Name、Billing Name、Username 被混为一谈，塞进了同一个 full name 里。用户在不同文档里看到同一个词，但被指去改不同的地方，这就是 概念交叉 。
如果难以理解，还有一个更加经典的 概念交叉 的例子：
请选择你的学历：
- 博士
- 硕士
- 本科
- 大专
- 学生
请选择你的最高学历：
- 博士
- 硕士
- 本科
- 大专
- 高中及以下
问题在于：“学生” 是身份，不是学历层级。“大专” 和 “本科” 是学历层级，“学生”和它们是 概念交叉 ——学生可以是大专生、本科生、硕士生、博士生。把 “学生” 和 “大专/本科” 并列，相当于说 “请选择水果：苹果、香蕉、食物”。
1.2.2.2 概念种属
请选择你最常使用的社交媒体：
- 微信
- 微博
- 抖音
- 即时通讯工具
- 短视频平台
全部用具体产品：
- 微信
- 微博
- 抖音
- 快手
- 其他
微信是具体App，即时通讯工具是品类；抖音是具体App，短视频平台是品类。把具体产品（种）和品类（属）并列，就是 概念种属 。
- 即时通讯工具（如微信、QQ）
- 社交媒体（如微博、小红书）
- 短视频平台（如抖音、快手）
品类之间不能有交叉（如“社交媒体”和“短视频平台”就有重叠，抖音既是短视频也是社交媒体），这样又属于上一节的 概念交叉 了
1.2.2.3 概念混搭
你的工作状态是？
- 全职
- 兼职
- 自由职业
- 学生
- 暂时不工作
- 寻找工作
拆成两个独立问题：
- 你的主要身份是？→ 学生 / 在职 / 自由职业 / 其他
- 你的工作时长是？（如在职/自由职业选填）→ 全职 / 兼职
全职/兼职是按 工作时长 分类，自由职业是按 雇佣关系 分类，学生是按 身份 分类，暂时不工作和寻找工作是按 就业意愿/状态 分类。这几个维度完全不是一个坐标系里的东西。
一个自由职业者可能做全职的自由职业（每天8小时），那他该选“全职”还是“自由职业”？一个学生如果也在兼职，该选“学生”还是“兼职”？
这就是 概念混搭 。
再举一个现实的例子：
简单来说， 词元是AI大模型处理信息的最小单元 ，兼具可计量、可定价、可交易三大特征。它不仅是智能时代的价值锚点，更是连接技术供给与商业需求的“结算单位”。词元应用场景远超AI领域，与日常生活紧密相关。
——身份凭证类，相当于数字世界的“临时身份证”，用于便捷登录各类平台、完成转账授权等，如微信登录第三方小程序、手机银行动态口令等，有明确有效期，兼顾便捷性与安全性。
这也是概念混搭，词元和凭证在计算机领域都由 Token 一词翻译而来，但中文语境下这两个词并没什么关系。
1.3.1.1 表意赘余
表意赘余，就是说了等于没说，或者一句话里同一个意思翻来覆去地讲。一般会在一些质量较差的机翻里面看到。能举的例子有很多：
请填写你的用户名，用户名是你在平台上的唯一标识，请确保你的用户名是唯一的。
请填写你的用户名（唯一，不可重复）
“用户名是你在平台上的唯一标识” 和 “请确保你的用户名是唯一的” 本质上是同一句话翻来覆去说，第二句是多余的。
请进行点击“提交”按钮以完成执行此次操作。
请点击“提交”按钮以执行此操作。
“进行点击” 就是 “点击”，“完成执行” 就是 “执行” 或 “完成”。
为了能够成功上传文件，请确保你已经预先选择了正确的文件格式。
请确保选择的文件格式正确，以便成功上传。
“为了能够”就是“为了”，“预先选择”就是“选择”（选择本身就在动作发生之前）。
总而言之，作为提示语，应当尽量精简，至于原因会在标准 4 的章节中讲到。
标准 2：覆盖广泛
覆盖广泛要求你举的例子应当具有广泛性，而不是特例。比如有些机构可能在北京海淀，在他们官网上让你填地址的时候就会拿 北京市海淀区 作为例子，但这显然没有考虑到北京市作为直辖市的特殊性。比如现在有一个输入框，标签叫 地址，给的示例就是 北京市海淀区，你是一名江苏南京江宁人，那你觉得填以下哪个最有可能呢？
- 南京市江宁区
- 江苏省南京市
- 江苏省南京市江宁区
所以这个例子显然不好。应该选择一个广泛的例子作为示例。但有一个例外：身份证。对于身份证这种有刚性结构的字段，则不需要 “泛”，因为它本身就是铁板一块。
所谓覆盖广泛，其实重点不在泛，而是 广 。我的意思是，如果一个特例本身能包含更多的信息，那么不妨就用特例。比如某学校给学生注册了一个网课平台，告诉学生账号是类似这么个格式：esqz6 + 身份证后 8 位。举例：esqz60617261X，这个例子就比举 esqz606201038 要好。因为能够携带更多的信息：后者你不知道 X 是大写还是小写，前者能直接看出 X 要大写。而身份证不带 X 的学生本来也不用在意最后一位是什么，这个 X 对他们也没有干扰。
标准 3：优先举例
需要注意的是，这里强调 优先 而不是 举例 。
模板会在不经意间引入很多 歧义 ，比如上一节提到的 esqz6 + 身份证后 8 位，这个后 8 位含不含 X 呢？如果给出的是 esqz60617261X 这种例子，我就知道，哦，是含 X 的，而且 X 要大写。
这是举例更优于模板的地方。
还有一个例子是，请填写你的班级。拿我的初中举例，你大概会看到以下这么几种写法：
九（1）班初三（1）班91班91初三一初三（1）九（1）所以模板其实有很大的问题，也是自然语言最愚蠢的地方，很多时候你靠光一个抽象的词是说不明白的。这也是为什么需要举例。
当然，既然叫 优先，也就意味着存在例外。比如还是身份证，有个空，就是让你填身份证，没有别的要求，那么就无需再使用举例，只需要提供一个模板，更准确说，一句话，身份证，X 大写，就可以了。
换言之，如果一个数据本身就有刚性的结构，没什么歧义，也不需要有什么变化，那么此时更建议使用模板，因为更简单直接。
标准 4：简短准确
尽管上面要求你要覆盖广泛，但也要简短准确，因为最终是要给用户看的。
密码长度不得少于8位，且必须包含至少一个大写字母、至少一个小写字母、至少一个数字、至少一个特殊字符（如 !@#$%^&* 等），且不得包含连续重复的字符，不得与用户名相同，不得为常见的弱密码……
密码需 8-20 位，含大小写字母、数字和特殊字符
这是把后端的正则校验规则直接复制粘贴给用户看。准确吗？非常准确，每个条件都列全了。简短吗？完全不。
密码：123456
密码：8-20 位，含字母和数字
简短吗？短得不得了。准确吗？如果你是想引导用户设置一个强密码，那这个例子完全是灾难。而且对于这种开放性填空，也更应该考虑模板而不是举例。
密码 8-16 位，必须包含大小写字母、数字、特殊符号
密码 8-16 位，含大小写字母、数字和符号（仅限 ! $ ）
看着好像挺全的，但 “特殊符号” 是哪些？用户输入 # 报错，输入 @ 也报错，最后发现只允许 ! 和 $。这是把校验规则抄了一半，还没抄全。
技巧 5：描述后果
总而言之，如果想让用户不要做某件事，不要只说 “不要做”，而要告诉用户 “做了会导致什么后果”。
人类对 “禁令” 天然有逆反心理，但对 “损失” 会主动规避。以下给出三个例子，都比较好理解：
请上传 JPG 或 PNG 格式的图片
仅支持 JPG/PNG，其他格式将无法显示
手机号为必填项
手机号用于接收订单通知，不填将无法跟进订单状态
密码不能过于简单
密码过于简单容易被盗号，建议包含字母、数字和特殊符号
技巧 6：优先选择
这个技巧几乎可以运用在上面所有的标准里，用选择代替填空总是更好的。就像一般会让你选择 男/女/其他/不显示，而不会让你填空 性别。在许多地方都能用来消歧义——比如 北京市海淀区 这个例子，只要加几个下拉单选框，就没有举例的问题了。班级 这个例子也同理。
如果实在不知道怎么简短准确，也可以试试用选择代替描述。也就是不描述规则本身，而是利用表格，对相应情况进行列举，读表格比读文字来的快，这样用户就可以更简单地锁定有用信息，降低认知负荷。比如注册后初始化，要你填一个 workspace name：
请输入工作区名称
用户看到这个框会愣住——什么叫工作区名称？填我的名字？公司名？项目名？还是随便起个酷的名字？
即便你加一句提示：
请填写工作区名称，用于标识你的团队
用户还是很懵：标识团队？那我填“技术部”还是“xxx科技有限公司”还是“前端小分队”？
一个好得多的做法是 加一个辅助表格，让用户对号入座——虽然仍然是填空，但用户看到表格就知道 “我属于哪一类、该填什么方向” 了：
| 你的场景 | 建议格式 | 示例 |
|---|---|---|
| 个人使用 | 名字 + “的工作区” | 张三的工作区 |
| 小团队（<10人） | 团队名或项目名 | 前端组 / 博客项目 |
| 企业/组织 | 公司全称或缩写 | 云创科技 / YC-Tech |
| 临时/测试 | 随意 | test-123456 |
用户扫一眼表格，三秒钟就能锁定自己属于哪一行，然后照着示例填。这就把 “开放性问题” 变成了 “半开放选择题”——你不需要替用户决定填什么，但你帮他框定了 “可以填什么方向”，大幅降低认知负荷。
就像你写试卷时肯定感觉选择比填空好写，填空比简答好写，简答比作文好写。
适用范围
我自己编的这套框架适用于大多数 格式半开放、用户需要参考才能理解 的场景（如地址、密码、用户名、班级、工作区名称、报错等）。
但有两个场景不适用：
- 格式全国统一且人人熟知（如身份证号）——不需要示例，只需要字段名 + 特例说明（如 X 大写）。
- 系统具备实时强校验能力（如校验位算法、实时查重）——用户不需要提前学，填错系统当场告诉他。
在这两种场景下，“不写示例” 反而是最友好的设计。
最后
不论如何设计 UI 和提示，都请牢记底线：前后端都要做校验。用户总是会以你想象不到的方式输入数据，前端校验帮用户及时修正，后端校验才是最终防线。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！