unslop

去除 AI 腔

编辑文本，去掉 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. **同义词轮换。**同一段里不要混用 protagonist、main character、central figure、hero。选一个并保持一致。
12. **虚假的范围表达。**如果 X 和 Y 不在有意义的范围内，就不要写“from X to Y”。直接列出主题。

风格

13. **过度使用长破折号。**完全避免使用长破折号。只用句号或逗号，不要用括号、短破折号或连字符代替破折号。需要分隔想法时，另起一句或使用逗号。
14. **过度使用冒号。**列表或示例前可以用冒号，但不要在句中用冒号连接内容。“If you're coming from traditional automation: instead of registering event handlers, you describe conditions”中的冒号没有必要。改写句子，让观点脱离比较框架后也能成立。“用简单的英语描述调度器何时触发，效果最好。”意思相同，也不依赖标点技巧。
15. **过度使用粗体。**不要把每个专有名词或缩写都加粗。
16. **行内标题列表。**典型形式是加粗标签加冒号，重复说明本行内容：“Performance: Performance improved...”。把这类内容改成普通行文。以句号结尾、点明主题并引出真正新信息的加粗引导语可以保留，例如“**TypeScript 中的架构。**所有表格都放在一个文件中。”
17. **标题使用标题式大小写。**标题使用句式大小写。
18. **装饰性表情符号。**从标题和项目符号中删除。
19. **弯引号。**使用直引号。

沟通痕迹

20. 聊天机器人用语。“希望这能帮到你！”“如果……请告诉我”“当然！”“当然可以！”“找到关键线索了！”删除。
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、wedge in（加入）、vector（方式、方法）、locus、vantage、nexus、作为名词的 primitive、作为隐喻的 harness、API surface 中的 surface、bedrock、作为隐喻的 scaffolding、modality、paradigm、gold-plating（做超出工作所需的事）、作为隐喻的 ratchet（使用机制的真实名称，或“只会收紧的限制”）、evacuate（指移动代码时，改用 move out）、endgame（最后阶段）、north star、flywheel。这些词看似专业，但通常有更具体、直白的说法。请选用具体的词语。

直白表达

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”和“leverage”改为“use”，“facilitate”改为“help”，“numerous”改为“many”，“in the event that”改为“if”。更华丽的同义词很少能让表达更清楚。
32. **避免矫饰的文风。**有直白说法时，不要使用比喻或华丽表达：警句（“要么接入，要么删除”）、刻意追求效果的片段句、拟人化描述代码（“计划把它保留下来”）、比喻性动词（“随之而来”“立足于”）以及陈词滥调式的引入语。把“一个值得转动的旋钮”改为“一个值得调整的参数”。有话直说。比喻名词见规则 26。
33. **避免过度压缩。**不要省略冠词、使用无动词的片段句、符号化表达，或让读者必须解码而不是阅读的缩写。“Parser rejects bad date → exit 2, no write”改为“The parser rejects a bad date, exits with code 2, and writes nothing.”使用包含冠词和动词的完整句子，并将箭头和缩写写成文字。