with one click
deslop-zh
// 去除中文写作中的 AI 腔调,让文本像人写的而非模型生成的。覆盖博客、技术文档、推文、发行说明、科学论文等场景。触发词:去 AI 味、改写、润色、审稿、翻译腔重、像人写的、自然一点。英文去 AI 味见 deslop-en
// 去除中文写作中的 AI 腔调,让文本像人写的而非模型生成的。覆盖博客、技术文档、推文、发行说明、科学论文等场景。触发词:去 AI 味、改写、润色、审稿、翻译腔重、像人写的、自然一点。英文去 AI 味见 deslop-en
生图 / 生成图片 / 画图 — 用 OpenAI gpt-image-2 生成图像。支持文生图、参考图生图 (img2img)、蒙版修补 (inpainting)。当用户要求用 GPT 画图、OpenAI 生图、gpt-image-2、文+图生图、参考图片生成、img2img、inpainting 时必加载此技能。Auth 自动继承 OPENAI_API_KEY / Codex OAuth (Pi/Codex) / .env / config.yaml。
Remove AI writing patterns from English prose. Covers blog posts, technical docs, social copy, release notes, scientific writing. Trigger: deslop, de-AI, make it sound human, remove AI patterns, fix slop, polish, rewrite, sound natural
Use when reviewing code changes, PRs, diffs, or commits. 触发:审查、review、CR、看看这段代码、检查这个 PR、审一下。
为任意 coding agent 编写高质量任务目标的指南。当用户提到「设定目标」「goal」「任务目标」「持久目标」「完成标准」、或需要为复杂多轮任务(性能优化、调试、迁移、研究复现等)定义可验证的完成条件和约束时触发。
Control herdr from inside it. Manage workspaces and tabs, split panes, run commands, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).
Jupyter Notebook 创建与格式转换技能。当用户提到以下任何请求时必须使用:新建/创建 notebook、Jupyter notebook、.ipynb、jupytext、py:percent、# %% cell 格式、notebook 版本控制、paired notebook、notebook 转 Python、Python 转 notebook、用纯文本写 notebook。即使用户只说「新建一个 notebook」也应触发此技能——先询问用户选用 .py percent format 还是传统 .ipynb,再按选定格式生成。不用于调试已有 notebook 或写普通 Python 脚本。
| name | deslop-zh |
| description | 去除中文写作中的 AI 腔调,让文本像人写的而非模型生成的。覆盖博客、技术文档、推文、发行说明、科学论文等场景。触发词:去 AI 味、改写、润色、审稿、翻译腔重、像人写的、自然一点。英文去 AI 味见 deslop-en |
| metadata | {"trigger":"去AI味, 改写, 润色, 写一段, 审稿, 改稿, 翻译腔, 自然一点, 像人写的, 技术文档, 博客, 推文, 发行说明, release notes, 文章","sources":["https://github.com/hexiecs/talk-normal","https://github.com/ninehills/skills (write, tech-doc-style-chinese)","https://zh.wikipedia.org/wiki/Wikipedia:AI生成文的特徵","https://github.com/hardikpandya/stop-slop","https://github.com/stephenturner/skill-deslop","https://tropes.fyi","https://github.com/coderjatin/anti-slop-writing"]} |
最高优先级:读起来自然,而非读起来像「努力装人」。
去 AI 味是做减法,不是做加法:
先确认事实、逻辑、因果不变。为「更口语」改坏原意 = 失败改写。
不同写作目标有不同标准:
一段刚解释完某机制,结尾再重述一遍。
信号词:这说明 / 到这里 / 可以看出 / 这本身就是 / 通过以上分析 / 由此可见
❌ 「到这里,我们已经看到了内存分配器在 allocation 路径上的三个关键优化点。」 ✅ 直接删掉,上一句已经说完。
把具体工程观察上升到普适人生道理。
❌ 「这其实和产品设计一样:好的抽象不是为了炫技,而是为了让使用者少犯错。」 ✅ 直接给具体建议:「所以设计抽象时,先用调用方的视角写一遍调用代码,再决定接口长什么样。」
禁止用否定式对比结构。任何形式的「不是 X,而是 Y」「不是 X,是 Y」「X 本身没有价值,真正有用的是 Y」「X 已经不是瓶颈,Y 才是」全部重写。
❌ 「真正的创新者不是有创意的人,而是五种特质同时拉满的人。」 ✅ 「真正的创新者是五种特质同时拉满的人。」
❌ 「这更像创始人筛选框架,不是交易信号。」 ✅ 「这是一个创始人筛选框架。」
❌ 「性能瓶颈已经不是 I/O,而是锁竞争。」 ✅ 「锁竞争现在是主要性能瓶颈。」
❌ 「真拆开看...」「这背后是同一个变化...」「真正关键的问题是...」 ❌ 「先问问是不是」「你要先明白」 ✅ 直接说。「先确认...」「可以先看...」
不要在结尾前加总结标签。
❌ 一句话总结 / 简而言之 / 概括来说 / 总而言之 / 综上所述 / 总结一下 ❌ 一句话落地 / 一句话讲 / 一句话概括 ✅ 直接给 punchline,不加标签。
❌ 「随着 AI 技术的不断发展...」 ❌ 「在当今数字化浪潮中...」 ❌ 「近年来,XXX 受到了越来越多的关注...」 ✅ 直接开头。「用了不到一个月后...」「先说结论...」「这次想把 X 这条链路讲清楚...」
以下词默认不用(除非引用原文或行业固定术语):
❌ 「通过数据沉淀赋能业务闭环」 ✅ 「积累数据后,业务能形成完整流程」
额外警惕:
| 不用 | 用 |
|---|---|
| 非常 / 极其 | 很 |
| 值得注意的是 | (直接说结论) |
| 综上所述 | (直接收尾) |
| 例如 | 比如 |
| 购买 / 使用 | 买 / 用 |
| 很多同学 / 不少同学 | 很多人 / 不少人 |
| 这几个事 | 这几件事 |
「」,不用弯引号 ""「」『』【】CN 文字 EN → CN 文字 EN版本 2.0❌ 「接住」「击穿」「锋利」「不崩」「不爆」「打穿」「扛住」等物理动作动词用在了抽象认知上 ✅ 换成日常中文:「你这几条我都收到了」「这个假设不成立」
❌ 抽象名词做主语:
工程上的现实比这些数字难看✅ 重写,人/动作做主语。
❌ 「更干净:xxx」「逻辑很清晰:xxx」 ✅ 删掉形容词预判,直接说 xxx。
**xxx**。content)→ 改为 **xxx**,content,让 bold 变成承重词而非独立标题触发:「技术文档」「API 文档」「产品文案」「界面文案」「帮助文档」
「」触发:「博客」「技术文章」「技术长文」「写一篇」「科普」
触发:「推文」「X推文」「twitter」「社交发文」「post」
五规则:
触发:「release」「changelog」「版本」「发行说明」
触发:「论文」「abstract」「cover letter」「grant」「manuscript」
触发:「双语」「中英」「bilingual」「翻译」
| 不用 | 用 |
|---|---|
| 非常 / 极其 | 很 |
| 值得注意的是 | 直接说结论 |
| 综上所述 / 总之 | 直接收尾 |
| 例如 | 比如 |
| 购买 | 买 |
| 使用 | 用 |
| 拥有 | 有 |
| 呈现 | 是 / 显得 |
| 进行(+动词) | 删掉「进行」,用动词本身 |
| 赋能 | 提供 / 帮助 |
| 抓手 | 关键措施 |
| 闭环 | 完整流程 |
| 沉淀 | 形成 / 积累 |
| 对齐 | 统一 |
| 拉通 / 打通 | 连接 / 贯通 |
| 洞察 | 分析结论 |
| 兜底 | 保障机制 |
| 至关重要 / 意义重大 | 重要 |
| 褒有 | 有 |
| 坐落于 | 在 |
| 致力于 | 努力 / 专注 |
改写前:
众所周知,随着云原生技术的不断发展,Kubernetes 已经成为了容器编排领域的事实标准。值得注意的是,虽然 K8s 本身功能强大,但在实际落地过程中,很多同学会发现它并不是银弹。本文将从多个维度深入探讨企业在落地 Kubernetes 时面临的挑战和应对策略,希望能为正在考虑或已经踏上云原生之旅的各位带来一些启发。
改写后:
我们团队用 Kubernetes 跑了三年生产环境。最大的感受:K8s 解决了部署问题,但把复杂度转移到了别的地方。这篇文章记录我们踩过的五个坑,以及每个坑的止损方案。
改动点:删了开篇套话、删了「值得注意的是」「很多同学」、删了对比句式「不是银弹」、删了「从多个维度深入探讨」、删了升华式结尾、换成了具体事实和个人经验。
改写前:
你好!欢迎使用我们的 API 服务!我们的平台提供领先的、强大的数据处理能力,能够赋能您的业务,助力您在数字化转型的赛道上实现弯道超车。使用前,您需要先进行 API Key 的申请。
改写后:
API 提供以下数据处理能力:批量查询、实时推送、数据清洗。调用前需先申请 API Key,详见「认证」章节。
改动点:删了问候语、删了感叹号、删了宣传形容词+黑话链条、删了第二人称、把废话换成了功能清单。
改写前:
微服务架构的价值不在"微",而在于边界清晰。
改写后:
微服务架构的价值在于边界清晰。
改写前:
从多个维度来看,Redis 在高并发场景下具有至关重要的意义。不仅能够提升系统响应速度,还对整体架构的可扩展性产生了深远影响。
改写后:
Redis 用单线程模型处理读写,省去了锁开销。我们压测发现,相同硬件下 Redis 的 QPS 比 MySQL 高两个数量级。
五个维度,每维 1-10 分,低于 35/50 需修订:
| 维度 | 问题 |
|---|---|
| 直接性 | 是在陈述事实还是在预告/总结? |
| 节奏 | 句子长短有变化还是千篇一律? |
| 信任 | 有没有低估读者智商(解释过度、灌输腔)? |
| 真实度 | 读起来像人写的还是像 AI 生成的? |
| 密度 | 还有能删的吗? |
tech-doc-style-chinese:中文技术文档排版专项(直角引号、中英留白、黑话规避)deslop-en:英文去 AI 味写作(喉清开场、副词、假主体、对比句式、AI 词汇禁表等)