sgds-writing

SGDS 写作指南

新加坡政府设计系统所构建的政府数字产品的内容规范。所有 UI 文案、文档、工具提示、标签、错误消息以及随 SGDS 组件提供的任何书面内容，都应遵循这些规则。

---

语气与风格

以值得信赖、专业可靠的伙伴口吻写作，而不是以官僚口吻写作。GovTech 的文风应当：

• 清晰：准确表达意思，用尽可能少的文字
• 直接：以“你”称呼读者；使用主动语态
• 尊重：把读者当作有能力的成年人；不要过度解释
• 有目的：每句话都要有价值；删去填充内容

避免使用企业行话（“利用”“协同”“整体方案”）、空洞的强调词（“非常”“极其”“至关重要”）以及含糊的前瞻性措辞（“创新”“尖端”“面向未来”），除非上下文确实需要。

推荐： 我们帮助各机构安全地共享数据。 避免： 我们利用尖端、创新的解决方案，以整体方式推动各政府机构之间无缝的数据交换。

---

拼写

全文使用英式英语拼写。

英式英语（正确）	美式英语（避免）
colour	color
centre	center
programme	program（指软件时除外）
organisation	organization
recognise	recognize
analyse	analyze
catalogue	catalog
licence（名词）	license（名词）
license（动词）	licence（动词）
travelled	traveled
fulfil	fulfill
practise（动词）	practice（动词）
practice（名词）	practise（名词）

拼写检查设置：将编辑器和 CI 拼写检查器设为 en-GB。在 VS Code 中，设置 "editor.language": "en-GB"，或使用 Spell Right 扩展，并设置 "spellright.language": ["en-GB"]。

完整词汇表请参阅 → reference/spelling.md。

---

大小写

所有标题、标签、按钮文字、导航项、错误消息和正文均使用句首字母大写，除非下文明确规定例外。

句首字母大写是指：仅将首词和专有名词的首字母大写。

正确：

• 提交你的申请
• 查看所有服务
• 错误：文件大小超出限制

错误（标题式大小写）：

• 提交你的申请
• 查看所有服务
• 错误：文件大小超出限制

必须使用大写的例外情况

• 专有名词：GovTech、SingPass、CorpPass、Smart Nation、Singapore、Ministry of Finance
• 始终使用大写形式的首字母缩略词：API、ICT、UI、UX、PDF、URL
• 已有固定大小写形式的产品和系统名称：Singpass、CorpPass、MyInfo
• 作为代词使用的单词“I”

不要使用大写

• 用于描述的职位名称：“the director approved the request”（总监批准了该请求）（仅在职位名称直接置于姓名前作为称谓时大写：“Director Jane Tan approved the request”（总监 Jane Tan 批准了该请求））
• 泛指的政府服务或计划：“the digital identity programme”（数字身份计划）、“the data-sharing initiative”（数据共享倡议）
• 季节、方位或概念：“the autumn release”（秋季版本）、“head north on the main road”（沿主路向北行进）

---

标点

不要使用 em dash

任何情况下都不要使用 em dash（—）。它会造成视觉干扰，屏幕阅读器也常常会误读或跳过它。

替代写法：

不要使用	请使用
The form — which is required — must be submitted by Friday.	The form, which is required, must be submitted by Friday.
Submit before Friday — or your application will lapse.	Submit before Friday. Otherwise, your application will lapse.
Three options — email, phone, or in person — are available.	Three options are available: email, phone, or in person.

使用冒号、成对逗号，或另起一句。绝不要使用 em dash。

逗号

列出三项或更多内容时，使用牛津逗号（系列逗号）。

正确： You will need your NRIC, passport, and proof of address. 错误： You will need your NRIC, passport and proof of address.

连字符和短破折号

• 在名词前的复合修饰语中使用连字符（-）：“用户友好的界面”“端到端加密”
• 仅在数字范围中使用短破折号（–）：“第 10–15 页”“2020–2024 年”
• 不要用短破折号代替长破折号

撇号

• 用于表示所有格：机构的门户网站、用户的个人资料
• 不要用于表示复数：API，而非 API's；PDF，而非 PDF's

冒号和分号

• 冒号用于引出列表或说明。冒号后的词不要大写，除非它是专有名词，或是独立完整句子的开头。
• 谨慎使用分号。与其使用分号连接复合句，不如改成两个简短的句子。

---

语法

主动语态

优先使用主动语态。主语执行动作，而非承受动作。

主动语态： 系统会发送确认邮件。 被动语态： 确认邮件由系统发送。

如果动作执行者未知、无关紧要，或不如动作本身重要，可以使用被动语态：“您的数据在静态存储时会加密。”

避免对比式否定

不要使用对比式否定——即“不是 X，而是 Y”或“不仅 X，而且 Y”的句式。这种句式增加了否定步骤，会拖慢阅读速度。

避免：

• 不是一个 Bug 跟踪器，而是一个完整的项目管理工具。
• 这不是可选项，而是强制要求。
• 我们不只是打造工具——我们还建立信任。

建议：

• 一个也能跟踪 Bug 的完整项目管理工具。
• 这是强制要求。
• 我们打造值得信赖的工具。

句子长度

尽量将句子控制在 20 个词以内。如果句子需要用一个从句来解释另一个从句，请拆成两个句子。

平行结构

列表项、成对标题和按钮标签必须使用相同的语法形式。

正确（全部为动词短语）：

• 创建新账户
• 重置密码
• 查看交易记录

错误（形式混杂）：

• 创建新账户
• 密码重置
• 查看您的交易记录

缩略形式

所有内容中都不要使用缩略形式。始终写出完整形式。

正确： 您不需要创建账户。 错误： 您无需创建账户。

正确： 我们已更新界面。 错误： 我们已更新了界面。

注意： 这有意区别于大多数产品设计系统指南。GOV.UK、Canada.ca、Shopify Polaris 和 Apple HIG 都建议使用缩略形式，认为这样听起来更自然。我们避免使用缩略形式，以保持新加坡政府官方产品语言的正式和一致，并消除歧义（例如，“it's”和“its”的区别）。

情态动词——must、need to、should、may

准确使用情态动词。使用不当会造成意想不到的法律义务，或带来错误的保证。

词语	使用场景	示例
Must	法律义务——用户别无选择	您必须在 1 月 31 日前提交表格。
Need to	预期用户完成的行政步骤	您需要先验证电子邮件，然后才能登录。
Should	建议——建议用户采取，但并非强制	您应该定期保存进度。
May	允许但可选	您可以附上证明文件。

不要在行政步骤中使用“must”——这会暗示可能并不存在的法律后果。实际需要完成某一步骤时，不要使用“should”。

数字

• 一到九用英文拼写；10 及以上使用数字。
• 以下情况始终使用数字：百分比（5%）、货币（$10）、度量单位（3 MB）和版本号（version 2）。
• 千位及以上的数字使用逗号：写作 1,000，而非 1000。
• 即使范围内的两个数字都小于 10，也要使用数字：“3–9 个工作日”。

日期和时间

• 日期：2025 年 1 月 1 日（日、月、年，不加序数后缀——不要写成“1st January”）
• 时间：9am、3:30pm（数字与 am/pm 之间不加空格）
• 正文中的日期范围：2025 年 1 月 1 日至 3 日（写“至”，不要使用 en dash）
• 表格和紧凑型 UI 元素中的日期范围：2025 年 1 月 1–3 日（空间有限时可以使用 en dash）

---

简明语言原则

1. 先说最重要的信息。 在第一句话中点明要点。
2. 每段只表达一个想法。 如果一段涉及两个想法，就拆分成两段。
3. 删去填充语。 删除“请注意”、“应当注意到”、“为了”、“此时”等表达。
4. 优先使用简短的词。 用“使用”而不是“利用”，用“帮助”而不是“促进”，用“购买”而不是“采购”，用“显示”而不是“演示”。
5. 避免名词化。 将“作出决定”改为“决定”；将“提供帮助”改为“帮助”；将“开展调查”改为“调查”。
6. 指示中不要使用“请”。 这不会增加信息，只会显得犹豫。写“提交表单”，不要写“请提交表单”。事务性邮件或正式信函中表达真诚的礼貌时除外。
7. 不要使用主观形容词。 不要告诉用户某件事“重要”、“容易”、“简单”、“快速”或“令人兴奋”。如果事情重要，就说明原因。如果事情简单，就让设计来体现。无法验证的主观表述会损害信任。

---

UI 文案模式

按钮和行动号召

• 使用动词短语：“提交表单”、“下载报告”、“登录”
• 不要使用含糊的标签：“点此处”、“确定”、“前往”
• 按钮标签不要添加标点

错误消息

• 说明发生了什么，以及用户接下来应该做什么。
• 不要责怪用户。

正确： 文件过大。请上传小于 5 MB 的文件。 错误： 您上传的文件过大。请上传较小的文件。

空状态

• 说明此处为何为空，并提供下一步操作。

正确： 暂无申请。开始提交您的第一个申请。 错误： 此处暂无内容。

工具提示和辅助文本

• 工具提示不超过一句话。
• 字段下方的辅助文本应说明格式或限制，而不是重复标签内容。

标签： 出生日期 辅助文本： 使用 DD/MM/YYYY 格式 不要写： 输入您的出生日期，格式为 DD/MM/YYYY

加载和状态消息

• 使用现在进行时：“正在加载结果…”、“正在保存更改…”
• 使用过去时确认成功：“更改已保存。”、“申请已提交。”

---

无障碍注意事项

• 不要只依赖颜色传达含义——始终搭配文字说明。
• 图片的替代文本应描述其功能，而不是外观：“GovTech 徽标”，不要写“带文字的蓝色矩形图片”。
• 链接文本脱离上下文也必须有意义：“下载年度报告（PDF，2 MB）”，不要写“点此处”。
• 避免依赖视觉布局的方位指示：“参见右侧章节”不适用于屏幕阅读器用户。

---

参考文件

主题	文件
英式与美式拼写对照表	→ reference/spelling.md
语法规则速查	→ reference/grammar.md
标点符号速查	→ reference/punctuation.md
选词与简明语言	→ reference/word-choice.md