metadata-check

元数据检查

审查简短且高价值的字符串，每个字符都至关重要——标题、元描述、架构描述、常见问题解答、标语、简介和社交卡片文案。Flesch 评分和十类可读性标准不适用于 5–30 个单词的字符串；此技能会检查适用的项目。

对任何符合元数据字符串形式的内容使用此技能。对于多段文字（博客文章、README、CONTRIBUTING 文件），请改用 readability-check。

检查内容

逐条检查以下各项。每项的结果为 ✓（通过）、⚠（需要改进）或 ✗（有问题）。

• 把最能体现差异的词放在前面。 最具体、便于搜索的词应靠近开头。“Astro SEO：权威指南”胜过“关于 Astro SEO 的权威指南”——读者的目光会先落在主题上。
• 具体胜于抽象。 使用名称、数字和具体说法。“将 LCP 降低 40%”胜过“显著提升性能。”
• 坚决删掉填充词和模糊措辞。 每个词都占用宝贵空间。删掉真的、只是、非常、实际上、基本上、简单地、有点、算是、我认为。在元数据中，这些不是文风问题，而是在 SERP 字符数中白白占位。
• 除非宾语是主语，否则使用主动语态。 “审核你的 GitHub 个人资料”胜过“你的 GitHub 个人资料可以接受审核。”
• 标题和描述不要重复。 重述标题的元描述会白白浪费约 60 个字符（总共 200 个字符）。描述应说明页面包含什么，而不是再次宣布页面是什么。
• 避免生僻词。 优先选择常见的同义词，除非用户搜索的就是领域术语。在 utilize 和 use 之间，选 use。目标受众熟悉的领域术语可以保留（hydration、middleware、structured data）。
• 考虑 SERP 和平台截断。 了解各平台的限制：
  • Google SERP：标题约在 55–65 个字符处截断，描述约在 155–160 个字符处截断。
  • GitHub 仓库描述：约 350 个字符，但搜索结果和个人资料卡片只显示开头约 100 个字符。
  • Twitter/X 简介：160 个字符。
  • Open Graph 描述：通常显示约 200 个字符。 超出截断位置的内容应可有可无，而不是关键承诺。
• 每个字段只表达一个想法。 试图承诺两件事的标题和描述会显得含糊。选最有力的一项。

跳过内容

不要对以下内容运行此技能：

• URL、架构 @id 值、文件名、枚举值或任何技术标识符。
• 多段文字——请改用 readability-check。
• 用户未编写且无法更改的字符串（导入内容、上游默认值）。

输出格式

对每个字符串，返回：

### [Field name] — [length] chars

> [The string itself]

- Front-loading: [✓/⚠/✗] [one-line reason if not ✓]
- Concreteness: [✓/⚠/✗] [reason]
- Filler: [✓/⚠/✗] [reason]
- Active voice: [✓/⚠/✗] [reason]
- Duplication: [✓/⚠/✗] [reason]
- Word choice: [✓/⚠/✗] [reason]
- Truncation fit: [✓/⚠/✗] [reason] — platform: [SERP/GitHub/Twitter/OG]
- One idea: [✓/⚠/✗] [reason]

**Rewrite:** [only if any check failed — a concrete replacement string, not a suggestion]

审核意见要简明可行——元数据反馈应能在几秒内付诸行动，而且通常会一次审核一批字符串。如果某个字符串已经没有问题，就不要凑字数；只需标记全部 ✓ 并继续。