mcpField
R
readability-check

readability-check

github.com/jdevalk营销与增长109123 次安装19 周前更新
代码仓库

关于 readability-check

用于审查博客草稿及其他多段文本可读性的技能。它从结构、句子清晰度等十个方面进行检查,并将短元数据和 SEO 排名问题指向其他技能。

主要功能

  1. 01十类可读性审查
  2. 02结构与段落检查
  3. 03句长和被动语态检查
  4. 04填充词、衔接与重复检查
  5. 05Flesch 易读性评分
  6. 06区分元数据与 SEO 审查场景

适用场景

  1. 01审查完成的博客草稿
  2. 02查找长篇文本中的难读段落
  3. 03检查引言和结论
  4. 04判断何时使用元数据或 SEO 审查

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/jdevalk/skills --skill readability-check

安装后在 Claude Code 中输入/readability-check确认已加载。

附带文件README.md

详细介绍

可读性检查

对博客文章草稿或其他多段文字进行可读性审核。用户要求检查可读性(“检查可读性”“做一遍可读性检查”“这篇内容容易读吗”)时使用,或在完成大量草稿后主动使用——作为博客撰写技能中批判性审读之后的第二轮检查,而不是在写作过程中使用。

对于短文本——页面标题、元描述、架构 description 字段、常见问题解答、个人简介、仓库标语——请使用 metadata-check 技能。Flesch 评分和下方的十项分类评估标准不适用于 5–30 个词的文本,还会造成误导。

若要判断文章是否具备排名竞争力——搜索意图匹配度、关键词短语布局、E-E-A-T、内部链接——请在本次审核后衔接使用 content-seo 技能。可读性是获得排名的前提,而非替代品。

受众校准

始终假设读者的英语是第二语言。这是默认情况,不是备用假设。

在技术文章中,技术部分可以使用受众预期会接触到的领域术语——但任何非技术段落(引言、背景、结论、过渡、示例、类比)都必须让非技术背景的英语二语读者读得懂。背景介绍和阐明写作动机的段落能帮助尚不了解相关领域的读者读懂文章;也最容易让他们失去兴趣。

对话式表达胜过正式文风。直接称呼读者(“你”“你的”)、偶尔向读者提问的文章,更能留住英语二语读者。请标出非技术部分中大段疏离、采用第三人称的行文。

读者实际如何阅读

读者会先浏览,再决定是否细读。他们会查看标题、第一段和每段的首句,仅凭这些内容决定是否继续阅读。搜索引擎和 AI 系统也会侧重这些元素来判断文本主题。因此,本次审核会重点关注这三处:标题和首句能呈现论点的文章,既方便浏览,也适合通读,还便于机器理解。

检查内容

通读全文,然后按以下每项标准分别反馈。对于每个问题,请引用具体文本,注明所在位置(章节标题或“引言”/“结论”),说明问题所在,并提出明确的修改建议。

1. 整体结构与主题顺序

文章的组织应当体现出写作前的规划——主题分组合理,顺序清晰,各部分逐一讲完。

  • 文章应遵循一种清晰的组织原则:主题式(逐项讨论各个方面)、时间顺序式(由旧到新)、教学式(由易到难——最适合讲解复杂主题)、问题—解决方案式(先提出问题,再介绍选项),或倒金字塔式(先讲最重要的内容,再补充细节和背景——最适合新闻和公告)。
  • 相关主题必须放在一起。请标出主题跳转:讨论某个主题后搁置,隔两节又重新提起。
  • 浏览测试:只看标题和每段首句,也应能了解文章的完整论点。如果浏览者会漏掉要点,说明该要点埋在段落中间——应将其前置。
  • 结论应重申核心信息,并使用总结性提示词(所以、总之、核心结论是)。如果引言以故事、问题或统计数据开篇,结论应回扣这一内容——这样能首尾呼应,让文章更完整。
2. 段落结构

段落是主题单元,而非视觉单元。若只是为了排版美观而添加空白,主题却没有变化,就会打乱读者对文本的理解。

  • 每个段落都必须以最重要的句子——核心句——开头。首句单独来看也应通顺:浏览内容的读者会读它,AI 系统也会从中提取答案。
  • 段落其余部分围绕核心句展开:用支持性句子进行解释、举证或补充细节,也可以用总结句或过渡句收尾。较长的段落最好以总结句作结。
  • 每个段落只表达一个观点。一个段落做两件事时,就应拆分。
  • 每个段落都应完整:在同一处讲清主题的所有内容。要指出与乒乓式结构相反的情况——段落分开后,下一段却只是接着讲同一个观点(这种分段只是为了美观,并非结构需要)。
  • 视觉密度比严格的句子数量更重要,但超过约 8 句或 120 词的段落应标出。过长的段落几乎总是藏着两个主题,应按主题拆分,而非在任意位置截开。
  • 段落长度长短搭配是好事:一连串长度相同的段落会显得单调。不要仅因短小有力的段落夹在较长段落之间就标出它。
3. 开篇段落

第一段的分量远超其他段落——AI 系统会引用它,读者也会据此决定是否继续阅读。它没有空间像印刷文章那样先铺垫,再逐步切入主题;网页读者只会给你几秒钟。好的引言要做到三点:传达主旨、吸引读者、设定预期。请重点检查:

  • 第一句是否直接点明文章主旨,而不只是交代背景?
  • 第一段能否单独作为摘要?
  • 是否有吸引读者继续阅读的亮点——例如一个问题、令人意外的事实、一项统计数据或一则简短轶事?开篇即便正确但平淡,也会像含糊不清的开篇一样让读者失去兴趣。
  • 是否点出了读者带着什么问题而来?读者若能在开头几行认出自己的问题,就会继续寻找解决方案。
  • 是否设定了预期——读者能否看出读完后会学到什么或得到什么?
  • 文章的核心主题词是否自然地出现在第一段中?读者(或搜索引擎)不应需要猜测文章主题。
  • 是否有可以删掉的模棱两可表述(如“在这篇文章中,我会尝试……”)?
  • 长度:最多两个较短的段落(总计约 10–12 句)。过长的引言会延迟读者获得有用内容。

对引言采用全文最严格的易读性标准:句子短、使用主动语态、不用难词。它应是最容易阅读的部分,而非最难的部分。

4. 句子长度

采用分级标准:

  • 14–20 词:正常,无需处理。
  • 21–30 词:较长。如果一个段落中有多个这样的句子,就应标出。
  • 30 词以上:很长。每处都应标出,并建议拆分。

长句对 L2 读者尤其不友好,因为他们必须在工作记忆中保留更多语法信息。若长句无法避免(例如必要的列表),请确保它前后的句子都较短。

5. 被动语态

标出被动结构(如“X 由 Y 完成”“建议……”)。对每处被动结构:

  • 如果行为主体明确,且改为主动语态读起来很自然,就改写。
  • 如果行为主体确实未知、无关紧要,或句子的重点在于动作承受者,则保留被动语态。
  • 即使段落中的两个被动结构各自都有合理理由,也要标出这种被动结构叠加的情况。
6. 难词

不要依赖音节数——它会把常见词(如“information”)误判为难词,却把简单词(如“queue”)误判为容易的词。相反,如果一个词符合以下条件,就标记它:

  • 非技术领域的 L2 读者可能不会在对话中使用这个词,并且
  • 有更常见且适合该句子的同义词。

如果有更简单的替代词,以下词语可作为标记示例:utilize(use)、leverage(use)、facilitate(help)、commence(start)、subsequently(then)、ascertain(find out)、endeavor(try)。

例外:

  • 受众预期会遇到的领域术语(如“structured data”“hydration”“middleware”)——在技术章节中不要标记。
  • 在技术文章的非技术段落中,即使是轻微的行话,也要严格按照 L2 标准判断。

确实需要使用难词时,要确保周围的句子简短易懂,让读者有余力处理难词。

7. 填充词和模糊表达

标记那些增加篇幅却没有实际意义的词语:really、just、very、actually、basically、simply、in order to(→ to)、at this point in time(→ now)、due to the fact that(→ because)。也要标记那些无故弱化论断的模糊表达:I think、sort of、kind of、it could be argued that。

8. 过渡词

过渡词是连接句子和段落的粘合剂——它们会在读者阅读前提示句子之间的关系。要根据关系选用恰当的连接词:

  • 列举:first、also、in addition、another、finally
  • 因果:because、so、since、therefore
  • 比较或对比:however、rather、yet、while、on the other hand
  • 总结:as a result、hence、in short、the takeaway is
  • 强调:especially、most of all、above all
  • 举例说明:for example、in other words、that said

检查事项:

  • 标记连续 3 段或更多段落都没有过渡词的情况。
  • 列表、步骤序列和结论最需要过渡词——没有提示的列举会迫使读者自行推断结构,而没有总结词的结论读起来也不像结论。
  • 不要矫枉过正:自然流畅也很重要。不是每个段落都需要明确的连接词。
9. 变化
  • 标记在约 200 词内重复 3 次或更多次的词语或短语(冠词、介词和领域术语除外)。
  • 标记连续 3 段或更多段落都以相同的句式开头的情况(例如都以“You can...”开头)。
  • 建议使用同义词或调整句式。
10. 小标题与标题层级

作者几乎总是小标题用得太少,而不是太多。如果拿不准,通常应该添加小标题。

  • 对于超过 1000 词的文章,任何正文部分都不应在没有小标题的情况下连续超过约 300 词。长段落或主题相近的段落组前都应添加标题。
  • 每个标题都必须准确概括其下方的内容——只求吸引眼球、却未能说明章节内容的标题会误导读者和机器。
  • 小标题应有足够的信息量,即使单独阅读也能理解——浏览目录的读者应该能把握文章的结构。
  • 检查标题层级是否正确嵌套(不要从 h2 跳到 h4)。
  • 同级标题在语法形式上应保持一致(全用名词短语、疑问句或祈使句——每个章节选定一种并保持一致)。
  • 对于超过约 1500 词的文章,建议添加目录。面对没有导航的长篇文字,读者容易望而却步;目录能让读者更有掌控感,也方便他们跳转到所需内容。

评分

报告两项内容。

Flesch 阅读易读性(计算方式:206.835 − 1.015 × (words/sentences) − 84.6 × (syllables/words))。目标区间:

  • 70+ — 通俗易懂的英语,适合英语非母语读者。非技术类文章,以及技术类文章中的非技术段落,都应以此为目标。
  • 60–70 — 标准水平。对于技术类文章整体而言可以接受,但非技术部分的得分应更高。
  • 50–60 — 较难阅读。请标出问题,并建议具体的删减内容。
  • 低于 50 — 难以阅读。需要重写。

Flesch 指数是机械计算的,无法发现段落层面的问题,但可以作为客观参考。如果可以,请另外报告引言和结论的得分——它们应处于目标区间的上限。

各类别状态——为上述 10 项检查分别指定以下状态之一:

  • ✓ 通过 — 没有明显问题。
  • ⚠ 需要改进 — 有少量可修正的问题;请在下方列出。
  • ✗ 存在问题 — 文章中存在系统性问题。

输出格式

## Readability audit: [post title]

### Score
- Flesch Reading Ease: [n] ([band])
- Intro: [n] · Conclusion: [n]
- Per-category: 1. ✓  2. ⚠  3. ✓  4. ✗  5. ⚠  6. ✓  7. ✓  8. ⚠  9. ✓  10. ✓

### Summary
[One paragraph: overall readability, the one or two biggest issues, and which audience the post currently serves vs. which it should serve.]

### Issues found
[Grouped by category. For each: location, quoted text, why it's a problem, concrete fix.]

### What's working
[Specific sentences, paragraphs, or transitions that read well — quote them. Vague praise ("the intro is fine") doesn't help the writer calibrate; specific praise ("the analogy in the 'Setup' section lands because it bridges to a non-technical reader") does.]

评论

支持 Markdown