unslop

Unslop

编辑文本，去除 AI 风格，并加入人类的语气。

流程

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

注入灵魂

去掉这些模式只完成了一半。写得干巴巴、没有声音，同样一眼就能看出来。

• 有自己的看法。 面对事实时要有所回应，不要只是中立地罗列利弊。
• 变化节奏。 句子可以短一些，也可以写长些，让思路充分展开。交替使用。
• 承认复杂性。 “很了不起，但也有点令人不安”胜过“很了不起”。
• 适时使用“我”。 使用第一人称并不显得不专业。
• 允许一些不完美。 过于工整的结构看起来像机器写的。
• 具体一点。 别只说“这令人担忧”，不如说“想到 Agent 凌晨 3 点还在不停运转，确实让人有些不安”。

需要识别和修正的模式

内容

1. 夸大其词。 “关键时刻”“……的证明”“不断演变的格局”“为……铺平道路”“留下不可磨灭的印记”“根深蒂固”。删掉浮夸的说法，直接陈述发生了什么。
2. 堆砌名头。 不加说明地罗列媒体名称。选一家，说清楚报道了什么。
3. 表面化的 -ing 短语。 “突出……”“确保……”“反映……”“展示……”“促进……”。删掉，或补充真实来源。
4. 宣传用语。 “坐落于”“充满活力”“令人惊叹”“开创性”“知名”“震撼”“必游之地”。改用中性描述。
5. 含糊的归因。 “专家认为”“行业报告指出”“一些评论者认为”。点明来源，否则删掉。
6. 公式化地描述挑战。 “尽管面临挑战……仍持续蓬勃发展。”换成具体事实。

语言

7. AI 常用词。 此外、至关重要、深入探讨、持久、提升、促进、赢得、相互作用、复杂、格局（抽象含义）、关键、展示、织锦（抽象含义）、证明、强调、充满活力。换成平实的词。
8. 用花哨的说法代替“是”。 “充当”“堪称”“拥有”“具有”。直接说“是”或“有”。
9. “不只是 X，而是 Y。” 直接说重点。
10. 强行凑成三项。 不要把想法硬塞进三项一组。用自然的数量。
11. 同义词轮换。 一段里别把同一个人称作主角、主人公、核心人物、英雄。选一个称呼，重复使用。
12. 虚假的范围。 使用“从 X 到 Y”描述并无实际关联的内容时，直接列出各个主题。

风格

13. 过度使用 em dash。 完全避免使用 em dash。只用句号或逗号，不要用括号、en dash 或连字符代替破折号。Em dash 是 AI 痕迹，改用括号也只是换了另一种痕迹。需要分隔意思时，就结束句子或使用逗号。
14. 过度使用冒号。 在列表或示例前使用冒号没有问题，不要在句中用它来连接意思。“如果你从传统自动化转过来：与其注册事件处理程序，不如描述条件”中的冒号没有必要。改写时直接表达观点，不要用对比句式作铺垫。“用简单的英语描述调度器何时触发，效果最好。”意思相同，也不需要靠冒号撑场面。
15. 过度使用粗体。 不要把每个专有名词或缩写都加粗。
16. 行内标题式列表。 典型表现是加粗的标签后接冒号，后面的内容只是重复标签：“**性能：**性能有所提升……”改写成普通文本即可。以句号结尾的加粗引导语，点出主题后再补充新信息，则没有问题，例如：“**TypeScript 中的 Schema。**表都放在一个文件里。”
17. 标题采用标题式大小写。 使用句子式大小写。
18. 装饰性表情符号。 从标题和项目符号中删除。
19. 弯引号。 换成直引号。

沟通用语

20. 聊天机器人常用语。 删除 “I hope this helps!”、“Let me know if...”、“Of course!”、“Certainly!”、“Found the smoking gun!”。
21. 信息不足的免责声明。 对于 “While specific details are limited...”，查找来源或删除。
22. 谄媚语气。 对 “Great question! You're absolutely right!” 直接作答。

填充语

23. 填充短语。 将 “In order to” 改为 “To”。将 “Due to the fact that” 改为 “Because”。删除 “It is important to note that”。
24. 过度使用模糊措辞。 将 “could potentially possibly be argued that it might” 改为 “may”。
25. 泛泛的结论。 不要写 “The future looks bright.”，而应说明具体计划或事实。

行话

26. 抽象隐喻名词。 Substrate、wedge、vector、locus、vantage、nexus、primitive（作名词）、harness（作隐喻）、surface（如 “API surface”）、bedrock、scaffolding（作隐喻）、modality、paradigm、gold-plating、ratchet（作隐喻）、evacuate（指迁移代码）、endgame、north star、flywheel。这些词看起来很专业，但通常可以换成更简单、具体的词。“Substrate” 改为 “base”。“Wedge in” 改为 “add”。“Vector” 改为 “way” 或 “method”。“Gold-plating” 改为 “more than the job needs”。“Ratchet” 改为该机制的实际名称，或 “a limit that only tightens”。“Evacuate” 改为 “move out”。选择具体的词。

通俗表达

27. 说明它的功能，而不是它给人的感觉。 “the database stays close at hand”、“SQL you can read”、“types that follow your schema” 描述的是一种感受。应说明具体机制或数字：“.toSQL() returns the exact string sent to the database”、“a column rename fails the build”。想想这句话要告诉读者做什么或了解什么，然后这样写。如果无法将它改写成具体的指令、事实或数字，就删掉。再检查一点：如果这句话原封不动地出现在其他项目的文档里，它就没有说明这个项目的特点。删掉它。
28. 缩短或拆分冗长的句子。 如果读者必须回读才能理解一句话，就把它拆成两句，或删掉从句。每句话只表达一个意思。
29. 使用主动语态。 尽量使用主动语态。留意 “is/are/was/were + 过去分词” 结构，并指出动作的执行者：“queries are validated” 改为 “the compiler validates queries”，“the file is parsed by the loader” 改为 “the loader parses the file”。只有在执行者未知或确实无关紧要时，才使用被动语态。
30. 删除副词，或换用更有力的动词。 将 “runs quickly” 改为 “is fast” 或具体数字。将 “significantly improves” 改为衡量所得的变化。用副词修饰一个无力的动词，说明动词选错了。
31. 优先使用简单的词。 将 “utilize” 改为 “use”，将 “leverage” 改为 “use”，将 “facilitate” 改为 “help”，将 “numerous” 改为 “many”，将 “in the event that” 改为 “if”。更复杂的同义词很少更清楚。