mcpField
P
proofreading

proofreading

github.com/seb1n文档处理232166 次安装11 周前更新
代码仓库

关于 proofreading

proofreading 是一项按多轮流程检查文本正确性、一致性、清晰度和语气的技能。它面向需要获得修订稿及逐项修改说明的作者,并可依据风格指南、受众和语言变体调整审校。

主要功能

  1. 01多轮语法与拼写检查
  2. 02标点及风格一致性检查
  3. 03可读性评分与语气分析
  4. 04附修改理由的校订结果
  5. 05适配风格指南与受众

适用场景

  1. 01按 APA 风格审校学术论文
  2. 02检查技术文档中的错误
  3. 03评估草稿的语气与可读性
  4. 04保留地区拼写和有意风格

安装

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

$npx skills add https://github.com/seb1n/awesome-ai-agent-skills --skill proofreading

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

详细介绍

校对

此技能可让 AI Agent 系统地校对文本,检查语法、拼写、标点、风格和一致性方面的错误。Agent 会采用结构化的多轮审阅流程,支持标准风格指南(AP、Chicago、APA 或自定义内部风格),并提供可读性评分和语气分析。输出包括修正后的文本,以及对每处改动的注释摘要。

工作流

  1. 语法检查 扫描文本中的语法错误,包括主谓一致、时态使用不当、悬垂修饰语、句子片段、连写句和从句位置不当。修正每处错误,并记录原表达和修正后的表达。特别留意包含多个从句、可能产生歧义的复杂句。

  2. 拼写和用词 找出拼写错误、容易混淆的同音词(例如,“affect”和“effect”,“their”和“there”)以及错误的词形。根据提供的上下文或术语表核实专有名词和领域术语。标记那些拼写正确但可能用错语境的词语。

  3. 标点和格式规范 检查逗号、分号、冒号、破折号、短破折号、连字符、引号和撇号的用法。遵循指定风格指南的规则,例如,Chicago 风格使用牛津逗号,而 AP 风格不使用。修正省略号、括号和方括号嵌套的误用。

  4. 风格和一致性 确保文档的格式一致:标题大小写(标题式大小写或句式大小写)、数字格式(使用数字或拼写数字)、缩写用法(首次出现时定义)以及列表标点。检查被动语态是否过度使用,并在主动表达能让含义更清晰时提出建议。确保术语使用一致——如果一处写“用户界面”,另一处写“UI”,则统一用法。

  5. 清晰度和可读性 评估句子长度、段落结构和整体可读性。标记超过 30 个单词、可能需要拆分的句子。找出可以在不损失准确性的前提下简化的术语或过于复杂的词汇。计算可读性评分(Flesch-Kincaid 或同类评分),并报告结果。提出结构调整建议,例如添加过渡句或拆分密集段落。

  6. 语气分析和最终审阅 评估整体语气(正式、会话式、学术、说服性),并确认其符合用户说明的意图。标记突兀的语气变化,例如在一份正式报告中出现随意的表达。最后通读一遍,确保所有修正衔接自然,且编辑过程中没有引入新错误。

用法

提供待校对的文本和任何相关背景。还可选择指定:

  • 风格指南 — AP、Chicago、APA、MLA 或自定义风格参考
  • 受众 — 学术、专业、普通公众、技术人员
  • 语气 — 正式、非正式、会话式、中性
  • 重点领域 — 仅语法、仅风格、全面校对
  • 输出格式 — 仅提供修正后的文本、提供带修订标记的修正文本,或提供带注释的改动列表

示例提示:“请按 APA 风格校对以下研究摘要。标记所有被动语态用法,并提供可读性评分。”

示例

示例 1:校对学术段落

输入:

研究参与者是从一批本科生中选出的,他们选修了一门入门心理学课程。数据是在 6 周内收集的,并采用混合方法进行分析。研究人员创立了,接受干预的参与者表现出显著改善,不过对照组的参与者没有。

修正后的输出:

研究参与者是从一批选修入门心理学课程的本科生中选出的。数据是在为期六周的时间内收集的,并采用混合方法进行分析。研究人员发现,接受干预的参与者表现出显著改善;不过,对照组的参与者没有。

所做的更改:

#原文修正原因
1“参与者是”“参与者们是”主谓一致
2“他们选修”“他们选修”同音词错误
3“一门入门”“一门入门”冠词搭配(元音音素)
4“数据是”“数据是”在学术写作中,“数据”是复数(APA)
5“6 周”“六周”10 以下的数字拼写出来;复合修饰语加连字符
6“分析”“分析”美式英语拼写(APA 默认)
7“混合方法”“混合方法”形容词形式不正确
8“创立了”“发现”动词形式错误
9“参与者”“参与者”指人时使用“谁”
10“接受”“接受”拼写错误
11“显著”“显著”拼写错误
12“改善,不过”“改善;不过,”连词副词前使用分号

可读性: Flesch-Kincaid 年级水平为 14.2(适合学术读者)。

示例 2:校对技术文档

输入:

配置

若要设置 SDK,首先使用 npm 安装依赖项。在终端中运行 npm install @acme/sdk。安装后,您需要调用 AcmeClient() 构造函数并传入您的 API 密钥来初始化客户端。确保 API 密钥得到安全存储,且未硬编码在源代码中,我们建议使用环境变量。

修正后的输出:

配置

若要设置 SDK,首先使用 npm 安装依赖项。在终端中运行 npm install @acme/sdk。安装后,您需要调用 AcmeClient() 构造函数并传入您的 API 密钥来初始化客户端。确保 API 密钥得到安全存储,且未硬编码在源代码中。我们建议使用环境变量。

所做的更改:

#原文修正原因
1“配置”“配置”标题中的拼写错误
2“设置”“设置”“设置”是动词短语;“setup”是名词或形容词
3“依赖项”“依赖项”拼写错误
4“安装后,您”“安装后,您”引导短语后缺少逗号
5“初始化”“初始化”为保持一致而采用美式英语拼写
6“调用 AcmeClient()”“调用 AcmeClient() 构造函数”缺少冠词
7“您的”“您的”同音词错误(“you're” = “you are”)
8“API 密钥”“API 密钥”首字母缩略词应大写
9“安全地”“安全地”拼写错误
10“源代码中,我们”“源代码中。我们”逗号拼接——用句号分隔独立分句
11“建议”“建议”拼写错误

最佳实践

  • 采用多轮检查。 不要试图在一次阅读中找出所有类型的错误。分别检查语法、拼写、标点和风格,才能获得更全面的结果。
  • 保留作者的语气。 修正错误,但不要改写成另一种风格。目标是润色,而不是替换作者的表达方式。
  • 展示修改内容。 务必提供带注释的修改清单,让作者可以审阅、了解修改原因,并逐项接受或拒绝。
  • 始终一致地遵循正确的风格指南。 AP 和 Chicago 对逗号、数字和大小写有不同规定。开始前先确认应遵循哪份指南。
  • 单独标明主观建议。 区分客观错误(拼写错误、语法错误)和主观建议(措辞选择、句子结构调整),方便作者确定处理优先级。
  • 考虑受众。 面向开发者的技术文档可以使用术语,而面向公众的博客文章则可能不适合使用这些术语。请据此调整简化建议。

特殊情况

  • 有意偏离风格规范: 创意写作、对话和营销文案可能会为了表达效果而有意违反语法规则。对于看似有意为之的句子片段或口语表达,在“纠正”前应先询问作者。
  • 混合语言: 文档中包含代码片段、外语短语或其他语言的品牌名称时,应将这些部分排除在拼写检查之外。
  • 英语地区变体: 区分美式英语、英式英语、澳大利亚英语及其他变体。“Colour” 在英式英语中并非拼写错误;“analyze” 在美式英语中也并非拼写错误。
  • 高度专业或领域特定的文本: 医学、法律和科学文本中包含的专业术语可能会触发误报。将被标记的术语与领域词汇表交叉核对后,再判定是否为错误。
  • 极短文本: 对于单句或标题,可读性评分可能没有意义。应着重关注正确性和清晰度。

评论

支持 Markdown