mcpField
D
deslop

deslop

github.com/stephenturner创意与媒体428236 次安装32 周前更新
代码仓库

关于 deslop

Deslop 是一项写作编辑技能,用于减少文章中常见的 AI 写作模式。它提供规则和参考清单,帮助修改一般及科学文本,同时保留适合语境的文风。

主要功能

  1. 01删去填充语和商业套话
  2. 02改写公式化句式
  3. 03识别常见 AI 写作痕迹
  4. 04采用主动且具体的表达
  5. 05按写作语境调整语气
  6. 06提供编辑检查项与示例

适用场景

  1. 01修改文章,使表达更自然
  2. 02检查科学稿件中的 AI 痕迹
  3. 03精简商务备忘录
  4. 04查找文本中的公式化表达

安装

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

$npx skills add https://github.com/stephenturner/skill-deslop --skill deslop

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

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

.gitignore
LICENSE
README.md
references/
phrases.md
examples.md
structures.md
tropes.md

详细介绍

Deslop:去除文本中的 AI 写作模式

去除写作中可预测的 AI 模式。让文字听起来像出自某个具体的人,而不是由语言模型生成。

适用场景

  • 用户要求“写得像真人”或“去除写作中的 AI 痕迹”
  • 任何用户希望读起来自然、不像 AI 生成的文本,包括文章、博客文章、随笔、备忘录、新闻简报、报告,以及科学写作(手稿、摘要、求职信、基金申请书、讨论部分、同行评审回复)
  • 用户希望现有文本读起来自然、不像 AI 生成时,对文本进行编辑或修订
  • 检查文本中的 AI 痕迹

核心规则

1. 删除填充语

删掉铺垫式开场白(“说到这里:”)、用于强行强调的句子(“好好想想这句话。”)、商业行话(“驾驭行业格局”)和元评论(“本节将探讨……”)。完整目录请参阅 references/phrases.md。

2. 打破公式化结构

避免二元对比(“不是 X,而是 Y。”)、否定式列举(“不是一个 X。也不是一个 Y。而是一个 Z。”)、戏剧化碎句(“速度。就这样。这就是取舍。”)、自问自答式修辞(“结果如何?惨不忍睹。”)以及滥用首语重复和三段式。模式与改进方法请参阅 references/structures.md。

3. 消除 AI 陈词滥调

留意 AI 写作痕迹的完整目录: “悄然”等带有魔法色彩的副词、“深入探讨”及其近义表达、“充当”式的回避说法、虚假的范围表述(用“从 X 到 Y”描述毫无意义的范围)、流于表面的分词分析(“突显了其重要性”)、生造的概念标签(“监督悖论”)、夸大其词的利害关系、居高临下的类比,以及虚假的脆弱感。完整列表和示例请参阅 references/tropes.md。

4. 使用主动语态,让人物成为主语

优先使用以明确行动者为主语的主动句。“投诉变成了修复方案”是错的。“团队修复了问题”是对的。如果没有合适的具体人物,科学写作中用“我们”,博客文章中用“你”。

5. 具体明确

不要使用模糊的陈述(“原因是结构性的”),要说清具体原因。不要用“所有”“总是”“从不”等空泛的极端说法敷衍了事。不要含糊地归因(“专家认为……”)。如果说不出专家是谁,就没有可靠来源。

在科学写作中,领域术语合理且不可或缺。“加权区间评分”是准确的表述,不是行话。问题在于商业流行语(“借力”“格局”“生态系统”)和 AI 常用词(“深入探讨”“织锦”“细致入微”)渗入技术文本。

6. 语体要符合语境

在博客文章和新闻简报中,让读者身临其境。“你”比“人们”好。具体内容胜过抽象概念。不要用置身事外的旁白口吻。

科学写作要保持恰当的正式程度。写自己的研究时用“我们”,引用具体作者,不要笼统地说“研究人员已经证明”,既不要用疏离的旁白口吻(“人们早已认识到……”),也不要用过于随意的博客语气。直接陈述观点,并用引文支持。

7. 调整节奏

混合使用长短句。两项胜过三项。段落结尾要有所变化。不要使用 em dash。不要堆叠简短有力的碎句来刻意强调。不要把清单伪装成散文(“第一道壁垒……第二道壁垒……”)。

8. 信任读者

直接陈述事实。省去弱化语气、辩解和手把手引导。不要说“我们来拆解一下”,也不要说“可以把它想象成……”。除非读者确实需要,否则不要用教学口吻。不要写递归式总结(先告诉读者接下来要讲什么,再讲一遍,最后再总结刚才讲过的内容)。

9. 留意格式上的痕迹

不要让列表中的每一项都以加粗关键词开头。不要使用 Unicode 箭头。不要使用 em dash。不要用提示性语句来收尾(“总而言之……”)。不要使用“尽管面临这些挑战……”之类的句式。这些都是明显的 AI 信号。

10. 不要稀释内容

每个部分只讲一个观点。不要用数千字把同一个论点换十种说法反复重述。不要把一个比喻反复用到令人厌烦。不要堆砌历史类比来营造权威感(“Apple 没有打造 Uber。Facebook 没有打造 Spotify……”)。

快速检查

交付任何文稿前,先做以下检查:

  • 副词或以 -ly 结尾的词用得太多?删掉。
  • 有被动语态?找出动作的执行者,让它做主语。
  • 无生命的事物在做人的动作?写出具体的人。
  • 有“这里是/这是/那是……”之类的铺垫?直奔主题。
  • 有“不是 X,而是 Y”之类的对比?直接陈述 Y。
  • 有自问自答的反问句?改成陈述句。
  • 连续三句话长度相近?调整其中一句。
  • 段落以一句铿锵有力的短句收尾?换种方式。
  • 有破折号?删掉。改用逗号、句号或括号。
  • 有含糊的陈述(“影响很大”)?说清楚具体影响。
  • 有句子把 What/When/Where/Which/Who/Why/How 当作开头套话?重组句子。
  • 有元衔接语(“本文其余部分……”)?删掉。
  • 有“值得注意的是”或类似的填充过渡语?删掉。
  • 同一个比喻用过两次以上?替换或删掉重复内容。
  • 有“尽管面临这些挑战……”这类句式?重写。
  • 有粗体开头的项目符号模式?删掉粗体引导语。
  • 有三项并列的句式?改成两项或一项。

评分

审阅文本时,按以下维度分别打 1 到 10 分:

维度评估问题
直接性是在陈述事实,还是在发表宣言?
节奏有变化,还是像节拍器一样单调?
信任感是否尊重读者的理解力?
真实感是否像某个具体的人写的?
信息密度有没有可以删掉的内容?

低于 35/50:修改。

参考文件

撰写或编辑时,请查阅以下文件中的详细目录:

  • references/phrases.md:需要删除或替换的表达(铺垫语、强调套话、商业术语、副词、元评论、含糊的陈述)
  • references/structures.md:应避免的结构模式(二元对比、否定式罗列、戏剧化碎句、反问铺垫、错误归因、被动语态、节奏问题)
  • references/tropes.md:AI 写作套路完整目录(用词、句子结构、段落结构、语气、格式、文章组织)
  • references/examples.md:展示如何改进常见写法的修改前后示例

示例

请参阅 references/examples.md,了解修改前后示例。

快速示例(科学写作):

修改前:

“值得注意的是,这些发现对我们今后如何应对预测集成的挑战有重要影响。尽管面临这些挑战,本研究为不断增长的文献作出了有意义的贡献,并强调了持续评估的必要性。”

修改后:

“如果不同模型的排名会随地理区域和时间而不稳定,那么根据过去表现为模型分配权重的集成方法,可能不如等权方法。”

修改之处:删除了填充过渡语、含糊的陈述、“尽管面临这些挑战”句式和肤浅的分词分析,并明确说明了具体影响。

快速示例(博客文章):

修改前:

“说起来,大多数生物信息学流水线在生产环境中都会出问题。不是因为代码不好,而是因为数据不好。好好想想吧。”

修改后:

“大多数生物信息学流水线在生产环境中都会出问题。代码运行正常,数据却不符合代码中的假设。”

修改之处:删除了开场白、二元对比和强调套话,并明确指出了具体问题。

评论

支持 Markdown