Community写作与编辑github.com

jakubkrehel/better-writing

专注于改进项目中的产品文案。

better-writing 是什么?

这个技能致力于提升项目中的产品文案质量,强调清晰、简洁和一致性。它提供了一套全面的写作指南,涵盖从语气、术语一致性、错误信息到空状态提示等各个方面。该技能支持在任何开发平台或 AI 代理工具(如 Claude Code、Cursor)的 Markdown 文件中使用,通过其详细的 SKILL.md 文档提供即时的最佳实践参考。它的核心价值在于帮助开发者编写更易读、更友好、更本地化友好的用户界面文案,从而改善用户体验并减少因文案不当引起的混乱。技能文档以结构化的方式列出了原则,并提供了大量正反示例,使开发者能够快速应用这些规则。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jakubkrehel/skills/tree/main/skills/better-writing

Installed? Explore more 写作与编辑 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

界面文案撰写

清晰简洁胜于巧妙;前后一致胜于变化多端。最好的错误消息是重新设计交互,让错误无法发生。

文案的渲染方式(通过 text-transform 进行的大小写、截断、智能标点符号)属于 better-typography。错误标记和声明(aria-invalid、实时区域)属于 better-accessibility。为翻译字符串预留的空间属于 better-layout。

了解现有声音

在撰写或审阅之前,先阅读附近的文案。注意产品的术语、其本地化约定以及任何语气或内容风格指南。

刻意追求的品牌声音并非缺陷。仅当偏离平实语言会导致不一致、歧义、翻译风险或与情境不符的语气时,才提出异议。

一种声音,灵活的语气

产品拥有一种声音,现有的文案确立了它。局部编辑不能凭空创造一种新声音。保持术语一致:如果菜单中是“归档”,那么提示框中就不应该是“移至存储”。语气随情境灵活调整:

情境语气
成功、新手引导、空状态温暖,可以轻松
常规操作、设置中性,极简
错误、破坏性确认冷静、平实、零俏皮
数据丢失、安全严肃、明确

直接称呼读者

在指导性文案中,请使用“你”,而不是“用户”。在错误提示中,“我们”会引入歧义并显得像是在推卸责任,因此应优先使用“无法加载内容”,而不是“我们正在加载内容时遇到问题”。已确立的第一人称声音可以在低风险的文案中保留,只要它仍然清晰可读。

谨慎使用所有格:“收藏”优于“你的收藏”。在整个流程中保持一致的视角。

用平实的词语替代巧妙的词语

选择那些疲倦的读者一眼就能看懂的词语,并删掉所有不起作用的词语。不要使用习语、口语或无法翻译的幽默。

跳过不必要的性别:“订阅者可以发布食谱”,而不是“每个订阅者都可以发布他或她的食谱”。匹配输入设备:触屏用“轻点”,使用指针用“单击”,两种方式都可能存在时用“选择”。

永远不要围绕变量将片段组装成句子(如 "You have " + n + " new messages"),因为不同语言的词序会变化。应使用带有适当复数形式的完整模板字符串。

动词优先的按钮

按钮标签应以命名操作的动词开头:“发送”、“保存草稿”、“删除项目”。永远不要用“好的!”、“走起!”或对重要操作使用简单的“是”和“否”。

确认按钮应重复操作的后果,这样用户无需阅读正文就能回答对话框的问题。“删除此项目?”应提供 删除项目 和 取消 选项。

一致的流程词汇

多步骤流程应自始至终使用统一词汇:“开始”进入,“继续”或“下一步”(选其一)前进,“完成”结束。交替使用同义词会让用户疑惑按钮是否具有不同功能。

链接描述其目标位置

链接文本必须在脱离上下文的状况下也有意义,因为屏幕阅读器用户通过页面上链接的列表进行导航。请写“阅读计费文档”。而“点击这里”既违反了这条规则,也违反了设备动词规则。

单独的“了解更多”会在同一页面上出现两个时失效。请为每个链接添加后缀:“了解导出的更多信息”。

统一的大小写策略

对每种元素类型选择首字母大写或句子大小写,然后将其应用于该类型的每个实例。句子大小写是更安全的默认选择。它更平静,没有需要记忆的逐词规则,并且本地化起来更干净。“保存更改”旁边出现“放弃更改”会显得很随意。

设置描述开启状态

为开关标注其开启时的作用。例如“发送已读回执”让用户可以推断出关闭状态;而负面描述(“不发送已读回执”)会使开关变成一个双重否定。

应直接链接到所引用的设置,而不是描述其路径:使用“通知设置”链接,而不是“前往 设置 > 通知 > 电子邮件”。

错误信息说明如何修复,并显示在出错位置旁边

错误是一条指令,它应该位于失败的输入字段旁边:

不好好
密码太短请选择至少包含 8 个字符的密码
名称无效名称中只能使用字母
哎呀!出了点问题。无法保存。请检查你的连接并重试。

无责备,无“哎呀”,无感叹号。以正面方式表述提示(“仅使用字母”,而不是“不要使用数字或符号”),并在用户犯错之前显示它们,而不是在犯错之后。当同一个错误反复触发时,应重新设计交互,而不是重新措辞。

空状态指向下一步

空状态应说明这是什么地方、如何填充它,并提供唯一的一个清晰下一步操作:

<!-- 不好:耸肩 -->
<p>无结果。</p>

<!-- 好:指导加下一步 -->
<p class="font-medium">还没有项目</p>
<p class="text-sm text-zinc-500">项目能将你的任务和文件整合在一起。</p>
<button class="mt-4">创建一个项目</button>

搜索或筛选器为空的状态应提及查询条件并提供退出方式:“未找到‘季度’的结果。清除筛选器”。切勿将永久性信息放在空状态中。一旦出现内容,它就会消失。

占位符是示例,不是标签

占位符应显示期望的格式:[email protected]、DD/MM/YYYY。它在输入时会消失,因此绝不能作为唯一的标签。每个字段都需要保留一个可见的标签。

报告

严重程度。 HIGH 表示误导用户或隐藏了从错误中恢复的方法。MEDIUM 表示破坏了语气、术语或大小写的一致性。LOW 表示孤立的措辞润色。

验证。 此处源代码就足够了。对照它调用的每个操作检查每个标签,对照每个错误消息中已说明的修复方法检查,并对照周围文案检查术语。无需进行浏览器检查。

格式。 将发现按它们违反的原则进行分组,按严重程度排序,每行一个根本原因,列出它出现的每个位置:

严重程度位置修改前修改后原因

位置 为 路径/到/文件:行号。原因 指明违反的原则和用户影响。

当有任何 HIGH 级别的发现时,以 阻止 结束;否则以 批准 结束,并将剩余问题留在报告中作为待办事项。切勿在未检查覆盖范围的情况下 批准。没有可报告的内容时,声明“无可操作的文案问题发现”并报告验证结果。

Individual skills in this repo

This repo contains 7 individual skills — each has its own dedicated page.

相关技能