unslop

Unslop

编辑文本，去除 AI 风格。

流程

1. 检查以下模式。
2. 重写。保留原意，符合预期语气。
3. 自查：“哪些地方一看就像 AI 生成的？”修正剩余问题。

需要检测和修正的模式

规则编号是固定 ID，供其他技能引用。删除规则后，编号会留空。

内容

3. 表面化的 -ing 短语。 “highlighting...”“ensuring...”“reflecting...”“showcasing...”“fostering...”。删除，或补充真实来源。
4. 含糊的归因。 “专家认为”“行业报告显示”“一些批评者认为”。注明来源，或删除。

语言

7. AI 常用词汇。 Additionally、crucial、delve、enduring、enhance、fostering、garner、interplay、intricate、landscape（抽象用法）、pivotal、showcase、tapestry（抽象用法）、testament、underscore、vibrant。换成朴素的词。
8. 用花哨说法代替“是”。 “serves as”“stands as”“boasts”“features”。直接说“是”或“有”。
9. “不只是 X，而是 Y。” 直接陈述观点。
10. 三项列举。 生硬地把观点凑成三项。按自然数量列举。
11. 同义词轮换。 在同一段里交替使用“主角”“主人公”“核心人物”“英雄”。选一个说法，重复使用。
12. 虚假的范围表达。 “从 X 到 Y”，但 X 和 Y 并不构成有意义的范围。直接列出主题。

风格

13. 过度使用 em dash。 完全避免使用 em dash。只用句号或逗号（不用括号、en dash 或连字符来代替破折号）。如需分隔意思，请结束句子或使用逗号。
14. 过度使用冒号。 列表或示例前可以用冒号，不要在句中用冒号连接内容。“如果你之前用的是传统自动化：你不需要注册事件处理器，而是描述条件”中的冒号没有作用。改写，让观点不依赖比较性的铺垫。“用自然语言描述调度器应在何时触发，效果最好。”意思相同，也不需要多余标点。
15. 过度使用粗体。 不要把每个专有名词或缩写都加粗。
16. 行内标题式列表。 典型写法是用粗体标签和冒号重复后面的内容：“性能： 性能提升了……”。改写成普通句子。以句号结尾的粗体引导语，点明主题后再提供新信息，例如“TypeScript 中的架构。 表格都放在一个文件中。”不属于这种问题。
17. 标题使用标题式大小写。 标题使用句子式大小写。
18. 装饰性表情符号。 从标题和项目符号中删除。
19. 弯引号。 换成直引号。

沟通用语

20. 聊天机器人套话。 删除“I hope this helps!”“Let me know if...”“Of course!”“Certainly!”“Found the smoking gun!”等表达。
21. 谄媚语气。 删除“好问题！你完全正确！”等表达，直接回答。

填充内容

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. 泛泛的结论。 “未来一片光明。”改为陈述具体计划或事实。

行话

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”改为“超出实际需要”。“Ratchet”改为这种机制的真实名称，或“只会不断收紧的限制”。“Evacuate”改为“move out”。“Endgame”改为“最后阶段”。选择具体的词。

平实表达

27. 说明它做什么，而不是它给人的感受。“数据库近在手边”“易读的 SQL”“与架构保持一致的类型”描述的是一种感受。改为说明机制或数字：“.toSQL() 返回发送到数据库的确切字符串”“重命名列会导致构建失败”。想想这句话告诉读者该做什么或该了解什么，然后据此写作。如果无法将它改写成具体指令、事实或数字，就删掉。再检查一次：如果这句话原封不动地出现在其他项目的文档中也成立，那它就没有说明这个项目的任何信息。删掉。
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”。更花哨的同义词很少更清楚。
32. **避免矫饰的表达。**有直白说法时，不要使用比喻或华丽辞藻：格言式表达（“wire it or delete it”）、为制造效果而使用的修辞性片段、拟人化的代码（“the plan holds it”）、比喻性动词（“rides along”“stands on”）、陈词滥调式的铺垫语。“A dial worth turning”改为“a parameter worth varying”。把意思说清楚。规则 26 讨论了比喻性名词。
33. **避免过度压缩。**省略冠词、无动词片段、符号表达，以及让读者费力解码而非阅读的缩写。“Parser rejects bad date → exit 2, no write”改为“The parser rejects a bad date, exits with code 2, and writes nothing.”写完整句子，保留冠词和动词，并将箭头和缩写展开写明。