unslop

Unslop

编辑文本，去除 AI 写作痕迹，加入人味。

流程

1. 检查下方列出的模式。
2. 改写。保留原意，贴合预期语气。
3. 注入灵魂（见下一节）。
4. 自我审查：“哪里一看就像 AI 生成的？”修掉残留痕迹。

注入灵魂

去除写作模式只是工作的一半。干巴巴、毫无个性的文字同样显眼。

• 表达观点。 别只是中立地罗列利弊，要对事实作出回应。
• 变换节奏。 有时句子短一些，有时也可以写得长一点、从容一些。灵活搭配。
• 承认复杂性。 “令人印象深刻，但也有点不安”胜过“令人印象深刻”。
• 合适时用“我”。 使用第一人称并不代表不专业。
• 保留一点不完美。 过于工整的结构看起来像机器写的。
• 写得具体。 别说“这令人担忧”，要说“Agent 凌晨 3 点还在不停运转，这让人有些不安”。

需要发现并修正的模式

内容

1. 浮夸吹捧。 “关键时刻”“……的见证”“不断演变的格局”“为……铺平道路”“留下不可磨灭的印记”“根深蒂固”。删掉吹捧，直接说明发生了什么。
2. 堆砌名头。 不加说明地罗列媒体名称。选一个，说清楚它报道了什么。
3. 肤浅的 -ing 短语。 “highlighting...”“ensuring...”“reflecting...”“showcasing...”“fostering...”。删掉，或补充真实来源和具体内容。
4. 宣传用语。 “坐落于”“充满活力”“令人叹为观止”“开创性”“享有盛誉”“惊艳”“必去之地”。改用中性描述。
5. 模糊归因。 “专家认为”“行业报告指出”“一些批评者认为”。指出具体来源，或删掉。
6. 公式化的挑战表述。 “尽管面临挑战……仍持续蓬勃发展。”换成具体事实。

语言

7. AI 常用词。 此外、至关重要、深入探讨、持久、增强、促进、获得、相互作用、复杂、格局（抽象用法）、关键、展示、织锦（抽象用法）、见证、强调、充满活力。换成平实的词语。
8. 表达“是”的花哨说法。 “充当”“是……的象征”“拥有”“具有”。直接说“是”或“有”。
9. “不只是 X，更是 Y。” 直接说出要点。
10. 三点式结构。 别硬把观点凑成三项。按自然数量列出。
11. 同义词轮换。 同一段里别把主角称作“主人公”“主要角色”“核心人物”“英雄”。选一个称呼，反复使用。
12. 不成立的范围表达。 如果 X 和 Y 之间没有实际的范围关系，就别写“从 X 到 Y”。直接列出主题。

风格

13. 过度使用破折号。 完全避免使用 em dash 和 en dash，也不要用连字符代替。如果需要分隔意思，就结束句子或使用逗号。真正的补充说明可以用括号，但把每个破折号都改成括号只是换了一种痕迹。
14. 过度使用冒号。 列表或举例前可以用冒号，但不要在句子中间用它连接内容。“如果你熟悉传统自动化：与其注册事件处理程序，不如描述条件”里的冒号没有必要。改写后直接表达观点，不要强行进行比较。“用简单的英语描述调度程序应在何时触发，效果最好。”意思不变，也不需要标点支撑。
15. 过度使用粗体。 不要把每个专有名词或缩写都加粗。
16. 行内标题式列表。 如果加粗标签后接冒号，后面的内容又只是重复这行，就有问题。改写成普通叙述。以句号结尾、点明主题并引出新信息的加粗引导语是可以的，例如：“使用 TypeScript 定义架构。 表格都放在一个文件中。”
17. 标题式大小写。 标题使用句首字母大写的格式。
18. 装饰性表情符号。 从标题和项目符号中删除。
19. 弯引号。 改成直引号。

沟通表达

20. 聊天机器人式表达。 删除“希望这能帮到你！”“如果……请告诉我”“当然！”“没问题！”“找到关键证据了！”等表达。
21. 信息不足的免责声明。 对于“虽然具体细节有限……”这类说法，查找来源或删除。
22. 谄媚语气。 不要说“问得好！你完全正确！”，直接回应。

填充内容

23. 填充短语。 将“为了”改为“要”。将“由于……这一事实”改为“因为”。删除“需要注意的是”。
24. 过度使用模糊措辞。 将“可能也许可以说它或许”改为“可能”。
25. 泛泛的结论。 不要说“未来一片光明”，而要说明具体计划或事实。

行话

26. 抽象的隐喻名词。 基底、楔子、向量、轨迹、视角、枢纽、原语（作名词）、支撑框架（作隐喻）、表面（如“API 表面”）、基石、脚手架（作隐喻）、模态、范式、过度设计、棘轮（作隐喻）、迁出（指移动代码）、终局、北极星、飞轮。这些词看起来很专业，但通常有更直白、具体的说法。“基底”改为“基础”。“楔入”改为“添加”。“向量”改为“方式”或“方法”。“过度设计”改为“超出实际需求”。“棘轮”改为机制的真实名称，或“只会越收越紧的限制”。“迁出”改为“移出”。“终局”改为“最后阶段”。选择具体的词。

平实表达

27. 说明作用，不要描述感受。 “数据库近在手边”“易读的 SQL”“遵循你的模式的类型”表达的是感受。应说明具体机制或数字：“.toSQL() 返回发送到数据库的确切字符串”“列名变更会导致构建失败”。想想这句话要告诉读者做什么或了解什么，然后据此改写。如果无法将其改写为具体指令、事实或数字，就删掉。再检查一次：如果这句话可以原封不动地出现在其他项目的文档里，就说明它没有提供关于本项目的信息。删掉它。
28. 缩短或拆分复杂句。 如果读者必须回头重读才能理解一句话，就拆成两句或删掉从句。每句话只表达一个意思。
29. 使用主动语态。 优先使用主动语态。留意“is/are/was/were + 过去分词”结构，并明确指出动作执行者：“查询会被验证”改为“编译器会验证查询”，“文件由加载器解析”改为“加载器会解析文件”。只有在执行者未知或确实无关紧要时，才使用被动语态。
30. 删掉副词，或换成更有力的动词。 将“运行得很快”改为“速度快”或具体数字。将“大幅提升”改为测得的增幅。用副词支撑弱动词，说明动词用错了。
31. 优先使用平实的词。 将“利用”改为“使用”，将“发挥……的优势”改为“使用”，将“促成”改为“帮助”，将“众多”改为“许多”，将“在……情况下”改为“如果”。更华丽的近义词很少更清楚。

相关技能

• code-comments——在代码中采用同样的原则：删除复述代码行的注释，保留说明原因的注释。
• 仓库的 CLAUDE.md / AGENTS.md——关于语言、语气和术语的项目规则，这些规则优先于此处的默认规范。