编辑任何文本以去除 AI 写作痕迹并保留原意、匹配语气时使用

适用于对文章、文档、说明、邮件等文本做去 AI 味编辑，删除套话、虚饰、模板句和冗余表达。

适用场景

解决思路

1. 扫描文本，寻找下列模式。
2. 改写文本；保留原意，匹配作者想要的语气。
3. 规则编号是稳定 id，供其他技能引用；不要重编号，删除规则会留下编号空缺。
4. 规则3：处理表层的 -ing 短语，如 “highlighting...”、“ensuring...”、“reflecting...”、“showcasing...”、“fostering...”；删除它们，或用真实来源展开。
5. 规则5：处理模糊归因，如 “Experts believe”、“Industry reports suggest”、“Some critics argue”；点名来源或删除。
6. 规则7：替换 AI 词汇，如 Additionally、crucial、delve、enduring、enhance、fostering、garner、interplay、intricate、landscape（抽象用法）、pivotal、showcase、tapestry（抽象用法）、testament、underscore、vibrant；改用朴素词。
7. 规则8：改掉说 “is” 的花哨方式，如 “serves as”、“stands as”、“boasts”、“features”；直接说 “is” 或 “has”。
8. 规则9：改掉 “Not just X, but Y.” 句式；直接陈述观点。
9. 规则10：避免三件套/规则三；不要强行把观点凑成三组，用自然数量。
10. 规则11：避免同义词轮换；同一段里 protagonist、main character、central figure、hero 混用应只选一个并重复用。
11. 规则12：避免虚假范围；不要用 “from X to Y” 表示 X 和 Y 不在有意义尺度上的内容，直接列主题。
12. 规则13：避免破折号滥用；完全不用 em dash，只用句号或逗号（不用括号、en dash、用连字符替代破折号）；需要分隔想法就结束句子或用逗号。
13. 规则14：避免冒号滥用；冒号可用于列表或例子前，不要当作句中连接符。例：“If you're coming from traditional automation: instead of registering event handlers, you describe conditions” 中的冒号没有增加信息；改写成让观点独立成立、不做对比框架。“Describing when the scheduler should fire works best as plain English.” 同样含义，不靠支撑性标点。
14. 规则15：避免粗体滥用；不要每个专有名词或缩写都加粗。
15. 规则16：处理行内标题列表；识别标志是加粗标签加冒号且重复该行内容，如 “**Performance:** Performance improved...” ，改成散文。若加粗引导语以句号结尾、点明条目、后面跟真正新增细节，如 “**Schema in TypeScript.** Tables live in one file.”，则保留。
16. 规则17：标题不要用 Title Case；改用句子大小写。
17. 规则18：删除装饰性 emoji；从标题和项目符号中移除。
18. 规则19：弯引号改成直引号。
19. 规则20：删除聊天机器人短语，如 “I hope this helps!”、“Let me know if...”、“Of course!”、“Certainly!”、“Found the smoking gun!”。
20. 规则22：删除谄媚语气，如 “Great question! You're absolutely right!”；直接回应。
21. 规则23：删除填充短语；“In order to” 改成 “To”，“Due to the fact that” 改成 “Because”，“It is important to note that” 直接删除。
22. 规则24：减少过度模糊限制；“could potentially possibly be argued that it might” 改成 “may”。
23. 规则25：删除泛泛结尾，如 “The future looks bright.”；给出具体计划或事实。
24. 规则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”；“Endgame” 改成 “the last phase”；选具体词。
25. 规则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”。问这句话要告诉读者做什么或知道什么，然后写出来。若不能改述成具体指令、事实或数字，就删。再检查：若这句话原封不动放到另一个项目文档里也成立，它对本项目什么都没说，删掉。
26. 规则28：缩短或拆分密集句；读者需回读才能解析时，拆成两句或删从句。一句一个想法。
27. 规则29：优先主动语态；抓 “is/are/was/were + past participle”，补出行为者：“queries are validated” 改成 “the compiler validates queries”，“the file is parsed by the loader” 改成 “the loader parses the file”。只有行为者未知或确实不重要时可用被动。
28. 规则30：删副词，或换更强动词；“runs quickly” 改成 “is fast” 或数字，“significantly improves” 改成实测差值。副词在撑弱动词说明动词不对。
29. 规则31：优先朴素词；“utilize” 改成 “use”，“leverage” 改成 “use”，“facilitate” 改成 “help”，“numerous” 改成 “many”，“in the event that” 改成 “if”。更花哨的同义词很少更清楚。
30. 规则32：去掉做作文风；有直白说法时不用隐喻或修饰，包括格言（“wire it or delete it”）、为效果用的修辞片段、拟人化代码（“the plan holds it”）、比喻动词（“rides along”、“stands on”）、套路框架短语。“A dial worth turning” 改成 “a parameter worth varying”。说你想说的。规则26 覆盖隐喻名词。
31. 规则33：避免过度压缩；不要丢冠词、写无动词片段、符号语或让读者解码的缩写。“Parser rejects bad date → exit 2, no write” 改成 “The parser rejects a bad date, exits with code 2, and writes nothing.” 写完整句子，带冠词和动词，展开箭头和缩写。