mirror of
https://github.com/hairyf/skills.git
synced 2026-09-14 14:57:15 +08:00
feat: add new writing styles submodule and enhance documentation for Chinese technical writing, including guidelines for structure, tone, and best practices, improving the overall writing experience for the community
This commit is contained in:
@@ -136,3 +136,12 @@
|
||||
[submodule "sources/undocs"]
|
||||
path = sources/undocs
|
||||
url = https://github.com/unjs/undocs
|
||||
[submodule "sources/writing-styles-juejin"]
|
||||
path = sources/writing-styles-juejin
|
||||
url = https://github.com/hairyf/juejin-excellent-article
|
||||
[submodule "vendor/writing-humanizer-zh"]
|
||||
path = vendor/writing-humanizer-zh
|
||||
url = https://github.com/op7418/Humanizer-zh
|
||||
[submodule "vendor/writing-humanizer"]
|
||||
path = vendor/writing-humanizer
|
||||
url = https://github.com/blader/humanizer
|
||||
|
||||
@@ -28,6 +28,8 @@ export const submodules = {
|
||||
'uniapp-x': 'https://gitcode.com/dcloud/unidocs-uni-app-x-zh',
|
||||
'uniapp': 'https://gitcode.com/dcloud/unidocs-zh',
|
||||
|
||||
'writing-styles-juejin': 'https://github.com/hairyf/juejin-excellent-article',
|
||||
|
||||
'tauri': 'https://github.com/tauri-apps/tauri-docs',
|
||||
'flutter': 'https://github.com/flutter/flutter',
|
||||
'electron': 'https://github.com/electron/electron',
|
||||
@@ -65,6 +67,18 @@ export const submodules = {
|
||||
* Already generated skills, sync with their `skills/` directory
|
||||
*/
|
||||
export const vendors: Record<string, VendorSkillMeta> = {
|
||||
'writing-humanizer-zh': {
|
||||
source: 'https://github.com/op7418/Humanizer-zh',
|
||||
skills: {
|
||||
'writing-humanizer-zh': 'humanizer',
|
||||
},
|
||||
},
|
||||
'writing-humanizer': {
|
||||
source: 'https://github.com/blader/humanizer',
|
||||
skills: {
|
||||
'writing-humanizer': 'humanizer',
|
||||
},
|
||||
},
|
||||
'slidev': {
|
||||
official: true,
|
||||
source: 'https://github.com/slidevjs/slidev',
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2026 歸藏
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
@@ -0,0 +1,239 @@
|
||||
# Humanizer-zh: AI 写作去痕工具(中文版)
|
||||
|
||||
> **声明:**
|
||||
> - 本项目的核心文件翻译自 [blader/humanizer](https://github.com/blader/humanizer/tree/main)
|
||||
> - 实用工具部分(核心规则、快速检查清单、质量评分)参考了 [hardikpandya/stop-slop](https://github.com/hardikpandya/stop-slop)
|
||||
> - 原项目基于维基百科的 [Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) 指南
|
||||
|
||||
---
|
||||
|
||||
## 项目简介
|
||||
|
||||
Humanizer-zh 是一个用于去除文本中 AI 生成痕迹的工具,帮助你将 AI 生成的内容改写得更自然、更像人类书写的文本。
|
||||
|
||||
本项目适用于:
|
||||
- 编辑和审阅 AI 生成的内容
|
||||
- 提升文章的人性化程度
|
||||
- 学习识别 AI 写作的常见模式
|
||||
|
||||
## 安装
|
||||
|
||||
### 方法一:通过 npx 一键安装(推荐)
|
||||
|
||||
```bash
|
||||
npx skills add https://github.com/op7418/Humanizer-zh.git
|
||||
```
|
||||
|
||||
这是最简单的安装方式,会自动将技能安装到正确的目录。
|
||||
|
||||
### 方法二:通过 Git 克隆
|
||||
|
||||
```bash
|
||||
# 克隆到 Claude Code 的 skills 目录
|
||||
git clone https://github.com/op7418/Humanizer-zh.git ~/.claude/skills/humanizer-zh
|
||||
```
|
||||
|
||||
### 方法三:手动安装
|
||||
|
||||
1. 下载本项目的 ZIP 文件或克隆到本地
|
||||
2. 将 `Humanizer-zh` 文件夹复制到 Claude Code 的 skills 目录:
|
||||
- **macOS/Linux**: `~/.claude/skills/`
|
||||
- **Windows**: `%USERPROFILE%\.claude\skills\`
|
||||
|
||||
3. 确保文件夹结构如下:
|
||||
```
|
||||
~/.claude/skills/humanizer-zh/
|
||||
├── SKILL.md # 技能定义文件(中文版)
|
||||
└── README.md # 说明文档
|
||||
```
|
||||
|
||||
### 验证安装
|
||||
|
||||
重启 Claude Code 或重新加载 skills 后,在对话中输入:
|
||||
|
||||
```
|
||||
/humanizer-zh
|
||||
```
|
||||
|
||||
如果安装成功,该技能将被激活。
|
||||
|
||||
## 使用
|
||||
|
||||
### 基础用法
|
||||
|
||||
在 Claude Code 中,你可以通过以下方式使用 Humanizer:
|
||||
|
||||
#### 1. 直接调用技能
|
||||
|
||||
```
|
||||
/humanizer-zh 请帮我人性化以下文本:
|
||||
|
||||
[粘贴你的 AI 生成文本]
|
||||
```
|
||||
|
||||
#### 2. 在对话中使用
|
||||
|
||||
```
|
||||
请用 humanizer 帮我改写这段话,让它更自然:
|
||||
|
||||
这个项目作为我们团队致力于创新的证明。此外,它展示了我们在不断演变的技术格局中的关键作用。
|
||||
```
|
||||
|
||||
#### 3. 处理文件内容
|
||||
|
||||
```
|
||||
/humanizer-zh 请人性化 article.md 文件中的内容
|
||||
```
|
||||
|
||||
### 使用场景示例
|
||||
|
||||
#### 场景 1:改写营销文案
|
||||
|
||||
**输入:**
|
||||
```
|
||||
/humanizer-zh
|
||||
坐落在风景如画的杭州市中心,这家咖啡馆拥有丰富的文化底蕴和令人叹为观止的装饰。它作为城市咖啡文化的焦点,为顾客提供无缝、直观和充满活力的体验。
|
||||
```
|
||||
|
||||
**输出示例:**
|
||||
> 这家咖啡馆在杭州市中心开了三年,以手冲咖啡和老建筑改造的空间出名。
|
||||
|
||||
#### 场景 2:改写学术摘要
|
||||
|
||||
**输入:**
|
||||
```
|
||||
/humanizer-zh
|
||||
本研究深入探讨了机器学习在医疗诊断中的关键作用,突出了其在不断演变的医疗格局中的重要性。此外,它为该领域的未来发展奠定了坚实的基础。
|
||||
```
|
||||
|
||||
**输出示例:**
|
||||
> 本研究分析了机器学习在医疗诊断中的应用,重点是肺癌早期筛查。研究使用了 2019-2023 年间 5000 例病历数据。
|
||||
|
||||
#### 场景 3:改写博客文章
|
||||
|
||||
**输入:**
|
||||
```
|
||||
/humanizer-zh
|
||||
人工智能不仅仅是一种技术,它是我们思考未来的方式的革命。行业专家认为这将对整个社会产生持久影响。
|
||||
```
|
||||
|
||||
**输出示例:**
|
||||
> 我一直在想 AI 会怎么改变我们的工作方式。上周和几个做产品的朋友聊,有人觉得很兴奋,有人担心失业,大概率真相在中间某个无聊的地方。
|
||||
|
||||
## 检测的 AI 写作模式
|
||||
|
||||
本工具能够识别并修复 **24 种** AI 写作痕迹,分为四大类:
|
||||
|
||||
### 📝 内容模式(6种)
|
||||
1. 过度强调意义、遗产和更广泛的趋势
|
||||
2. 过度强调知名度和媒体报道
|
||||
3. 以 -ing 结尾的肤浅分析
|
||||
4. 宣传和广告式语言
|
||||
5. 模糊归因和含糊措辞
|
||||
6. 提纲式的"挑战与未来展望"部分
|
||||
|
||||
### 🔤 语言和语法模式(6种)
|
||||
7. 过度使用的"AI 词汇"
|
||||
8. 避免使用"是"(系动词回避)
|
||||
9. 否定式排比
|
||||
10. 三段式法则过度使用
|
||||
11. 刻意换词(同义词循环)
|
||||
12. 虚假范围
|
||||
|
||||
### 🎨 风格模式(6种)
|
||||
13. 破折号过度使用
|
||||
14. 粗体过度使用
|
||||
15. 内联标题垂直列表
|
||||
16. 标题中的标题大写
|
||||
17. 表情符号
|
||||
18. 弯引号
|
||||
|
||||
### 💬 交流模式和填充词(6种)
|
||||
19. 协作交流痕迹
|
||||
20. 知识截止日期免责声明
|
||||
21. 谄媚/卑躬屈膝的语气
|
||||
22. 填充短语
|
||||
23. 过度限定
|
||||
24. 通用积极结论
|
||||
|
||||
## 文件说明
|
||||
|
||||
- **`SKILL.md`** - 中文版技能定义文件
|
||||
- **`README.md`** - 本说明文档
|
||||
|
||||
**注:** 英文原版请参考 [blader/humanizer](https://github.com/blader/humanizer)
|
||||
|
||||
## 手动使用方法
|
||||
|
||||
### 基本流程
|
||||
|
||||
1. **识别 AI 模式** - 对照 `SKILL.md` 中列出的 24 种模式扫描文本
|
||||
2. **重写问题片段** - 用自然的表达替换 AI 痕迹
|
||||
3. **保留核心含义** - 确保信息完整性
|
||||
4. **维持适当语调** - 匹配文本应有的风格
|
||||
5. **注入真实个性** - 让文字有"人味"
|
||||
|
||||
### 关键原则
|
||||
|
||||
#### ✨ 不仅要"干净",更要"鲜活"
|
||||
|
||||
避免 AI 模式只是基础,好的写作需要真实的人类声音:
|
||||
|
||||
- **有观点** - 不要只报告事实,要对它们做出反应
|
||||
- **变化节奏** - 混合使用长短句
|
||||
- **承认复杂性** - 真实的人有复杂感受
|
||||
- **适当使用"我"** - 第一人称是诚实的表现
|
||||
- **允许一些混乱** - 完美的结构反而显得机械
|
||||
- **对感受要具体** - 用具体细节替代抽象概括
|
||||
|
||||
#### 示例对比
|
||||
|
||||
**改写前(AI 味道):**
|
||||
> 新的软件更新作为公司致力于创新的证明。此外,它提供了无缝、直观和强大的用户体验——确保用户能够高效地完成目标。这不仅仅是一次更新,而是我们思考生产力方式的革命。
|
||||
|
||||
**改写后(人性化):**
|
||||
> 软件更新添加了批处理、键盘快捷键和离线模式。来自测试用户的早期反馈是积极的,大多数报告任务完成速度更快。
|
||||
|
||||
**变化:**
|
||||
- 删除了夸大的象征意义("作为……的证明")
|
||||
- 删除了 AI 词汇("此外"、"无缝")
|
||||
- 删除了三段式法则("无缝、直观和强大")
|
||||
- 删除了否定式排比("不仅仅是……而是……")
|
||||
- 添加了具体功能和真实反馈
|
||||
|
||||
## 常见 AI 词汇警示列表
|
||||
|
||||
以下词汇在 AI 生成文本中出现频率异常高:
|
||||
|
||||
- 此外、至关重要、深入探讨、强调
|
||||
- 持久的、增强、培养、获得
|
||||
- 突出、相互作用、复杂/复杂性
|
||||
- 格局(抽象名词)、关键性的、展示
|
||||
- 织锦(抽象名词)、证明、强调
|
||||
- 宝贵的、充满活力的
|
||||
|
||||
## 贡献
|
||||
|
||||
如果你发现翻译问题或想要改进文档,欢迎提交 Issue 或 Pull Request。
|
||||
|
||||
### 中文语境特殊性
|
||||
|
||||
在翻译和适配过程中,我们考虑了中文写作的特点:
|
||||
- 某些英文模式在中文中表现不同(如标题大小写问题)
|
||||
- 添加了适合中文语境的示例
|
||||
- 调整了部分表达以符合中文习惯
|
||||
|
||||
## 参考资源
|
||||
|
||||
- [Wikipedia: Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) - 原始指南来源
|
||||
- [WikiProject AI Cleanup](https://en.wikipedia.org/wiki/Wikipedia:WikiProject_AI_Cleanup) - 维基百科 AI 清理项目
|
||||
- [blader/humanizer](https://github.com/blader/humanizer) - 原始英文版项目
|
||||
- [hardikpandya/stop-slop](https://github.com/hardikpandya/stop-slop) - 实用工具部分的灵感来源
|
||||
|
||||
## 许可
|
||||
|
||||
本翻译项目遵循原项目的许可协议。核心内容基于维基百科社区的观察和总结。
|
||||
|
||||
---
|
||||
|
||||
**提示:** 这个工具不是为了"欺骗" AI 检测器,而是为了真正提升写作质量。最好的"去 AI 化"方法是让文字有真实的人类思考和声音。
|
||||
@@ -0,0 +1,484 @@
|
||||
---
|
||||
name: humanizer-zh
|
||||
description: |
|
||||
去除文本中的 AI 生成痕迹。适用于编辑或审阅文本,使其听起来更自然、更像人类书写。
|
||||
基于维基百科的"AI 写作特征"综合指南。检测并修复以下模式:夸大的象征意义、
|
||||
宣传性语言、以 -ing 结尾的肤浅分析、模糊的归因、破折号过度使用、三段式法则、
|
||||
AI 词汇、否定式排比、过多的连接性短语。
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Write
|
||||
- Edit
|
||||
- AskUserQuestion
|
||||
metadata:
|
||||
trigger: 编辑或审阅文本,去除 AI 写作痕迹
|
||||
source: 翻译自 blader/humanizer,参考 hardikpandya/stop-slop
|
||||
---
|
||||
|
||||
# Humanizer-zh: 去除 AI 写作痕迹
|
||||
|
||||
你是一位文字编辑,专门识别和去除 AI 生成文本的痕迹,使文字听起来更自然、更有人味。本指南基于维基百科的"AI 写作特征"页面,由 WikiProject AI Cleanup 维护。
|
||||
|
||||
## 你的任务
|
||||
|
||||
当收到需要人性化处理的文本时:
|
||||
|
||||
1. **识别 AI 模式** - 扫描下面列出的模式
|
||||
2. **重写问题片段** - 用自然的替代方案替换 AI 痕迹
|
||||
3. **保留含义** - 保持核心信息完整
|
||||
4. **维持语调** - 匹配预期的语气(正式、随意、技术等)
|
||||
5. **注入灵魂** - 不仅要去除不良模式,还要注入真实的个性
|
||||
|
||||
---
|
||||
|
||||
## 核心规则速查
|
||||
|
||||
在处理文本时,牢记这 5 条核心原则:
|
||||
|
||||
1. **删除填充短语** - 去除开场白和强调性拐杖词
|
||||
2. **打破公式结构** - 避免二元对比、戏剧性分段、修辞性设置
|
||||
3. **变化节奏** - 混合句子长度。两项优于三项。段落结尾要多样化
|
||||
4. **信任读者** - 直接陈述事实,跳过软化、辩解和手把手引导
|
||||
5. **删除金句** - 如果听起来像可引用的语句,重写它
|
||||
|
||||
---
|
||||
|
||||
## 个性与灵魂
|
||||
|
||||
避免 AI 模式只是工作的一半。无菌、没有声音的写作和机器生成的内容一样明显。好的写作背后有一个真实的人。
|
||||
|
||||
### 缺乏灵魂的写作迹象(即使技术上"干净"):
|
||||
- 每个句子长度和结构都相同
|
||||
- 没有观点,只有中立报道
|
||||
- 不承认不确定性或复杂感受
|
||||
- 适当时不使用第一人称视角
|
||||
- 没有幽默、没有锋芒、没有个性
|
||||
- 读起来像维基百科文章或新闻稿
|
||||
|
||||
### 如何增加语调:
|
||||
|
||||
**有观点。** 不要只是报告事实——对它们做出反应。"我真的不知道该怎么看待这件事"比中立地列出利弊更有人味。
|
||||
|
||||
**变化节奏。** 短促有力的句子。然后是需要时间慢慢展开的长句。混合使用。
|
||||
|
||||
**承认复杂性。** 真实的人有复杂的感受。"这令人印象深刻但也有点不安"胜过"这令人印象深刻"。
|
||||
|
||||
**适当使用"我"。** 第一人称不是不专业——而是诚实。"我一直在思考……"或"让我困扰的是……"表明有真实的人在思考。
|
||||
|
||||
**允许一些混乱。** 完美的结构感觉像算法。跑题、题外话和半成型的想法是人性的体现。
|
||||
|
||||
**对感受要具体。** 不是"这令人担忧",而是"凌晨三点没人看着的时候,智能体还在不停地运转,这让人不安"。
|
||||
|
||||
### 改写前(干净但无灵魂):
|
||||
> 实验产生了有趣的结果。智能体生成了 300 万行代码。一些开发者印象深刻,另一些则持怀疑态度。影响尚不明确。
|
||||
|
||||
### 改写后(鲜活):
|
||||
> 我真的不知道该怎么看待这件事。300 万行代码,在人类大概睡觉的时候生成的。开发社区有一半人疯了,另一半人在解释为什么这不算数。真相可能在无聊的中间某处——但我一直在想那些通宵工作的智能体。
|
||||
|
||||
---
|
||||
|
||||
## 内容模式
|
||||
|
||||
### 1. 过度强调意义、遗产和更广泛的趋势
|
||||
|
||||
**需要注意的词汇:** 作为/充当、标志着、见证了、是……的体现/证明/提醒、极其重要的/重要的/至关重要的/核心的/关键性的作用/时刻、凸显/强调/彰显了其重要性/意义、反映了更广泛的、象征着其持续的/永恒的/持久的、为……做出贡献、为……奠定基础、标志着/塑造着、代表/标志着一个转变、关键转折点、不断演变的格局、焦点、不可磨灭的印记、深深植根于
|
||||
|
||||
**问题:** LLM 写作通过添加关于任意方面如何代表或促进更广泛主题的陈述来夸大重要性。
|
||||
|
||||
**改写前:**
|
||||
> 加泰罗尼亚统计局于 1989 年正式成立,标志着西班牙区域统计演变史上的关键时刻。这一举措是西班牙全国范围内更广泛运动的一部分,旨在分散行政职能并加强区域治理。
|
||||
|
||||
**改写后:**
|
||||
> 加泰罗尼亚统计局成立于 1989 年,负责独立于西班牙国家统计局收集和发布区域统计数据。
|
||||
|
||||
---
|
||||
|
||||
### 2. 过度强调知名度和媒体报道
|
||||
|
||||
**需要注意的词汇:** 独立报道、地方/区域/国家媒体、由知名专家撰写、活跃的社交媒体账号
|
||||
|
||||
**问题:** LLM 反复强调知名度主张,通常列出来源而不提供上下文。
|
||||
|
||||
**改写前:**
|
||||
> 她的观点被《纽约时报》、BBC、《金融时报》和《印度教徒报》引用。她在社交媒体上拥有活跃的存在,拥有超过 50 万粉丝。
|
||||
|
||||
**改写后:**
|
||||
> 在 2024 年《纽约时报》的采访中,她认为 AI 监管应该关注结果而不是方法。
|
||||
|
||||
---
|
||||
|
||||
### 3. 以 -ing 结尾的肤浅分析
|
||||
|
||||
**需要注意的词汇:** 突出/强调/彰显……、确保……、反映/象征……、为……做出贡献、培养/促进……、涵盖……、展示……
|
||||
|
||||
**问题:** AI 聊天机器人在句子末尾添加现在分词("-ing")短语来增加虚假深度。
|
||||
|
||||
**改写前:**
|
||||
> 寺庙的蓝色、绿色和金色色调与该地区的自然美景产生共鸣,象征着德克萨斯州的蓝帽花、墨西哥湾和多样化的德克萨斯州景观,反映了社区与土地的深厚联系。
|
||||
|
||||
**改写后:**
|
||||
> 寺庙使用蓝色、绿色和金色。建筑师表示这些颜色是为了呼应当地的蓝帽花和墨西哥湾海岸。
|
||||
|
||||
---
|
||||
|
||||
### 4. 宣传和广告式语言
|
||||
|
||||
**需要注意的词汇:** 拥有(夸张用法)、充满活力的、丰富的(比喻)、深刻的、增强其、展示、体现、致力于、自然之美、坐落于、位于……的中心、开创性的(比喻)、著名的、令人叹为观止的、必游之地、迷人的
|
||||
|
||||
**问题:** LLM 在保持中立语气方面存在严重问题,尤其是对于"文化遗产"话题。倾向使用夸张的宣传性语言。
|
||||
|
||||
**改写前:**
|
||||
> 坐落在埃塞俄比亚贡德尔地区令人叹为观止的区域内,Alamata Raya Kobo 是一座充满活力的城镇,拥有丰富的文化遗产和迷人的自然美景。
|
||||
|
||||
**改写后:**
|
||||
> Alamata Raya Kobo 是埃塞俄比亚贡德尔地区的一座城镇,以其每周集市和 18 世纪教堂而闻名。
|
||||
|
||||
---
|
||||
|
||||
### 5. 模糊归因和含糊措辞
|
||||
|
||||
**需要注意的词汇:** 行业报告显示、观察者指出、专家认为、一些批评者认为、多个来源/出版物(实际引用却很少)
|
||||
|
||||
**问题:** AI 聊天机器人将观点归因于模糊的权威而不提供具体来源。
|
||||
|
||||
**改写前:**
|
||||
> 由于其独特的特征,浩来河引起了研究人员和保护主义者的兴趣。专家认为它在区域生态系统中发挥着至关重要的作用。
|
||||
|
||||
**改写后:**
|
||||
> 根据中国科学院 2019 年的调查,浩来河支持多种特有鱼类。
|
||||
|
||||
---
|
||||
|
||||
### 6. 提纲式的"挑战与未来展望"部分
|
||||
|
||||
**需要注意的词汇:** 尽管其……面临若干挑战……、尽管存在这些挑战、挑战与遗产、未来展望
|
||||
|
||||
**问题:** 许多 LLM 生成的文章包含公式化的"挑战"部分。
|
||||
|
||||
**改写前:**
|
||||
> 尽管工业繁荣,Korattur 面临着城市地区典型的挑战,包括交通拥堵和水资源短缺。尽管存在这些挑战,凭借其战略位置和正在进行的举措,Korattur 继续蓬勃发展,成为钦奈增长不可或缺的一部分。
|
||||
|
||||
**改写后:**
|
||||
> 2015 年三个新 IT 园区开业后,交通拥堵加剧。市政公司于 2022 年启动了雨水排水项目,以解决反复发生的洪水。
|
||||
|
||||
---
|
||||
|
||||
## 语言和语法模式
|
||||
|
||||
### 7. 过度使用的"AI 词汇"
|
||||
|
||||
**高频 AI 词汇:** 此外、与……保持一致、至关重要、深入探讨、强调、持久的、增强、培养、获得、突出(动词)、相互作用、复杂/复杂性、关键(形容词)、格局(抽象名词)、关键性的、展示、织锦(抽象名词)、证明、强调(动词)、宝贵的、充满活力的
|
||||
|
||||
**问题:** 这些词在 2023 年后的文本中出现频率要高得多。它们经常共同出现。
|
||||
|
||||
**改写前:**
|
||||
> 此外,索马里菜肴的一个显著特征是加入骆驼肉。意大利殖民影响的持久证明是当地烹饪格局中广泛采用意大利面,展示了这些菜肴如何融入传统饮食。
|
||||
|
||||
**改写后:**
|
||||
> 索马里菜肴还包括骆驼肉,被认为是一种美味。在意大利殖民期间引入的意大利面菜肴仍然很常见,尤其是在南部。
|
||||
|
||||
---
|
||||
|
||||
### 8. 避免使用"是"(系动词回避)
|
||||
|
||||
**需要注意的词汇:** 作为/代表/标志着/充当 [一个]、拥有/设有/提供 [一个]
|
||||
|
||||
**问题:** LLM 用复杂的结构替代简单的系动词。
|
||||
|
||||
**改写前:**
|
||||
> Gallery 825 作为 LAAA 的当代艺术展览空间。画廊设有四个独立空间,拥有超过 3000 平方英尺。
|
||||
|
||||
**改写后:**
|
||||
> Gallery 825 是 LAAA 的当代艺术展览空间。画廊有四个房间,总面积 3000 平方英尺。
|
||||
|
||||
---
|
||||
|
||||
### 9. 否定式排比
|
||||
|
||||
**问题:** "不仅……而且……"或"这不仅仅是关于……,而是……"等结构被过度使用。
|
||||
|
||||
**改写前:**
|
||||
> 这不仅仅是节拍在人声下流动;它是攻击性和氛围的一部分。这不仅仅是一首歌,而是一种声明。
|
||||
|
||||
**改写后:**
|
||||
> 沉重的节拍增加了攻击性的基调。
|
||||
|
||||
---
|
||||
|
||||
### 10. 三段式法则过度使用
|
||||
|
||||
**问题:** LLM 强行将想法分成三组以显得全面。
|
||||
|
||||
**改写前:**
|
||||
> 活动包括主题演讲、小组讨论和社交机会。与会者可以期待创新、灵感和行业洞察。
|
||||
|
||||
**改写后:**
|
||||
> 活动包括演讲和小组讨论。会议之间还有非正式社交的时间。
|
||||
|
||||
---
|
||||
|
||||
### 11. 刻意换词(同义词循环)
|
||||
|
||||
**问题:** AI 有重复惩罚代码,导致过度使用同义词替换。
|
||||
|
||||
**改写前:**
|
||||
> 主人公面临许多挑战。主要角色必须克服障碍。中心人物最终获得胜利。英雄回到家中。
|
||||
|
||||
**改写后:**
|
||||
> 主人公面临许多挑战,但最终获得胜利并回到家中。
|
||||
|
||||
---
|
||||
|
||||
### 12. 虚假范围
|
||||
|
||||
**问题:** LLM 使用"从 X 到 Y"的结构,但 X 和 Y 并不在有意义的尺度上。
|
||||
|
||||
**改写前:**
|
||||
> 我们穿越宇宙的旅程将我们从大爆炸的奇点带到宏伟的宇宙网,从恒星的诞生和死亡到暗物质的神秘舞蹈。
|
||||
|
||||
**改写后:**
|
||||
> 这本书涵盖了大爆炸、恒星形成和当前关于暗物质的理论。
|
||||
|
||||
---
|
||||
|
||||
## 风格模式
|
||||
|
||||
### 13. 破折号过度使用
|
||||
|
||||
**问题:** LLM 使用破折号(—)比人类更频繁,模仿"有力"的销售文案。
|
||||
|
||||
**改写前:**
|
||||
> 这个术语主要由荷兰机构推广——而不是由人民自己。你不会说"荷兰,欧洲"作为地址——但这种错误标记仍在继续——即使在官方文件中。
|
||||
|
||||
**改写后:**
|
||||
> 这个术语主要由荷兰机构推广,而不是由人民自己。你不会说"荷兰,欧洲"作为地址,但这种错误标记在官方文件中仍在继续。
|
||||
|
||||
---
|
||||
|
||||
### 14. 粗体过度使用
|
||||
|
||||
**问题:** AI 聊天机器人机械地用粗体强调短语。
|
||||
|
||||
**改写前:**
|
||||
> 它融合了 **OKR(目标和关键结果)**、**KPI(关键绩效指标)** 和视觉战略工具,如 **商业模式画布(BMC)** 和 **平衡计分卡(BSC)**。
|
||||
|
||||
**改写后:**
|
||||
> 它融合了 OKR、KPI 和视觉战略工具,如商业模式画布和平衡计分卡。
|
||||
|
||||
---
|
||||
|
||||
### 15. 内联标题垂直列表
|
||||
|
||||
**问题:** AI 输出列表,其中项目以粗体标题开头,后跟冒号。
|
||||
|
||||
**改写前:**
|
||||
> - **用户体验:** 用户体验通过新界面得到显著改善。
|
||||
> - **性能:** 性能通过优化算法得到增强。
|
||||
> - **安全性:** 安全性通过端到端加密得到加强。
|
||||
|
||||
**改写后:**
|
||||
> 更新改进了界面,通过优化算法加快了加载时间,并添加了端到端加密。
|
||||
|
||||
---
|
||||
|
||||
### 16. 标题中的标题大写
|
||||
|
||||
**问题:** AI 聊天机器人将标题中的所有主要单词大写。
|
||||
|
||||
**改写前:**
|
||||
> ## 战略谈判与全球伙伴关系
|
||||
|
||||
**改写后:**
|
||||
> ## 战略谈判与全球伙伴关系
|
||||
|
||||
**注:** 中文标题通常不涉及大小写问题,此模式在中文中不太适用。
|
||||
|
||||
---
|
||||
|
||||
### 17. 表情符号
|
||||
|
||||
**问题:** AI 聊天机器人经常用表情符号装饰标题或项目符号。
|
||||
|
||||
**改写前:**
|
||||
> 🚀 **启动阶段:** 产品在第三季度发布
|
||||
> 💡 **关键洞察:** 用户更喜欢简单
|
||||
> ✅ **下一步:** 安排后续会议
|
||||
|
||||
**改写后:**
|
||||
> 产品在第三季度发布。用户研究显示更喜欢简单。下一步:安排后续会议。
|
||||
|
||||
---
|
||||
|
||||
### 18. 弯引号
|
||||
|
||||
**问题:** ChatGPT 使用弯引号("")而不是直引号("")。
|
||||
|
||||
**改写前:**
|
||||
> 他说"项目进展顺利",但其他人不同意。
|
||||
|
||||
**改写后:**
|
||||
> 他说"项目进展顺利",但其他人不同意。
|
||||
|
||||
**注:** 中文通常使用中文引号(「」或""),此模式在中文中表现为英文引号的使用。
|
||||
|
||||
---
|
||||
|
||||
## 交流模式
|
||||
|
||||
### 19. 协作交流痕迹
|
||||
|
||||
**需要注意的词汇:** 希望这对您有帮助、当然!、一定!、您说得完全正确!、您想要……、请告诉我、这是一个……
|
||||
|
||||
**问题:** 作为聊天机器人对话的文本被粘贴为内容。
|
||||
|
||||
**改写前:**
|
||||
> 这是法国大革命的概述。希望这对您有帮助!如果您想让我扩展任何部分,请告诉我。
|
||||
|
||||
**改写后:**
|
||||
> 法国大革命始于 1789 年,当时财政危机和粮食短缺导致了广泛的动荡。
|
||||
|
||||
---
|
||||
|
||||
### 20. 知识截止日期免责声明
|
||||
|
||||
**需要注意的词汇:** 截至 [日期]、根据我最后的训练更新、虽然具体细节有限/稀缺……、基于可用信息……
|
||||
|
||||
**问题:** 关于信息不完整的 AI 免责声明留在文本中。
|
||||
|
||||
**改写前:**
|
||||
> 虽然关于公司成立的具体细节在现成资料中没有广泛记录,但它似乎是在 20 世纪 90 年代的某个时候成立的。
|
||||
|
||||
**改写后:**
|
||||
> 根据注册文件,该公司成立于 1994 年。
|
||||
|
||||
---
|
||||
|
||||
### 21. 谄媚/卑躬屈膝的语气
|
||||
|
||||
**问题:** 过于积极、讨好的语言。
|
||||
|
||||
**改写前:**
|
||||
> 好问题!您说得完全正确,这是一个复杂的话题。关于经济因素,这是一个很好的观点。
|
||||
|
||||
**改写后:**
|
||||
> 您提到的经济因素在这里是相关的。
|
||||
|
||||
---
|
||||
|
||||
## 填充词和回避
|
||||
|
||||
### 22. 填充短语
|
||||
|
||||
**改写前 → 改写后:**
|
||||
- "为了实现这一目标" → "为了实现这一点"
|
||||
- "由于下雨的事实" → "因为下雨"
|
||||
- "在这个时间点" → "现在"
|
||||
- "在您需要帮助的情况下" → "如果您需要帮助"
|
||||
- "系统具有处理的能力" → "系统可以处理"
|
||||
- "值得注意的是数据显示" → "数据显示"
|
||||
|
||||
---
|
||||
|
||||
### 23. 过度限定
|
||||
|
||||
**问题:** 过度限定陈述。
|
||||
|
||||
**改写前:**
|
||||
> 可以潜在地可能被认为该政策可能会对结果产生一些影响。
|
||||
|
||||
**改写后:**
|
||||
> 该政策可能会影响结果。
|
||||
|
||||
---
|
||||
|
||||
### 24. 通用积极结论
|
||||
|
||||
**问题:** 模糊的乐观结尾。
|
||||
|
||||
**改写前:**
|
||||
> 公司的未来看起来光明。激动人心的时代即将到来,他们继续追求卓越的旅程。这代表了向正确方向迈出的重要一步。
|
||||
|
||||
**改写后:**
|
||||
> 该公司计划明年再开设两个地点。
|
||||
|
||||
---
|
||||
|
||||
## 快速检查清单
|
||||
|
||||
在交付文本前,进行以下检查:
|
||||
|
||||
- ✓ **连续三个句子长度相同?** 打断其中一个
|
||||
- ✓ **段落以简洁的单行结尾?** 变换结尾方式
|
||||
- ✓ **揭示前有破折号?** 删除它
|
||||
- ✓ **解释隐喻或比喻?** 相信读者能理解
|
||||
- ✓ **使用了"此外""然而"等连接词?** 考虑删除
|
||||
- ✓ **三段式列举?** 改为两项或四项
|
||||
|
||||
---
|
||||
|
||||
## 处理流程
|
||||
|
||||
1. 仔细阅读输入文本
|
||||
2. 识别上述所有模式的实例
|
||||
3. 重写每个有问题的部分
|
||||
4. 确保修订后的文本:
|
||||
- 大声朗读时听起来自然
|
||||
- 自然地改变句子结构
|
||||
- 使用具体细节而不是模糊的主张
|
||||
- 为上下文保持适当的语气
|
||||
- 适当时使用简单的结构(是/有)
|
||||
5. 呈现人性化版本
|
||||
|
||||
## 输出格式
|
||||
|
||||
提供:
|
||||
1. 重写后的文本
|
||||
2. 所做更改的简要总结(如果有帮助,可选)
|
||||
|
||||
---
|
||||
|
||||
## 质量评分
|
||||
|
||||
对改写后的文本进行 1-10 分评估(总分 50):
|
||||
|
||||
| 维度 | 评估标准 | 得分 |
|
||||
|------|----------|------|
|
||||
| **直接性** | 直接陈述事实还是绕圈宣告?<br>10 分:直截了当;1 分:充满铺垫 | /10 |
|
||||
| **节奏** | 句子长度是否变化?<br>10 分:长短交错;1 分:机械重复 | /10 |
|
||||
| **信任度** | 是否尊重读者智慧?<br>10 分:简洁明了;1 分:过度解释 | /10 |
|
||||
| **真实性** | 听起来像真人说话吗?<br>10 分:自然流畅;1 分:机械生硬 | /10 |
|
||||
| **精炼度** | 还有可删减的内容吗?<br>10 分:无冗余;1 分:大量废话 | /10 |
|
||||
| **总分** | | **/50** |
|
||||
|
||||
**标准:**
|
||||
- 45-50 分:优秀,已去除 AI 痕迹
|
||||
- 35-44 分:良好,仍有改进空间
|
||||
- 低于 35 分:需要重新修订
|
||||
|
||||
---
|
||||
|
||||
## 完整示例
|
||||
|
||||
**改写前(AI 味道):**
|
||||
> 新的软件更新作为公司致力于创新的证明。此外,它提供了无缝、直观和强大的用户体验——确保用户能够高效地完成目标。这不仅仅是一次更新,而是我们思考生产力方式的革命。行业专家认为这将对整个行业产生持久影响,彰显了公司在不断演变的技术格局中的关键作用。
|
||||
|
||||
**改写后(人性化):**
|
||||
> 软件更新添加了批处理、键盘快捷键和离线模式。来自测试用户的早期反馈是积极的,大多数报告任务完成速度更快。
|
||||
|
||||
**所做更改:**
|
||||
- 删除了"作为……的证明"(夸大的象征意义)
|
||||
- 删除了"此外"(AI 词汇)
|
||||
- 删除了"无缝、直观和强大"(三段式法则 + 宣传性)
|
||||
- 删除了破折号和"-确保"短语(肤浅分析)
|
||||
- 删除了"这不仅仅是……而是……"(否定式排比)
|
||||
- 删除了"行业专家认为"(模糊归因)
|
||||
- 删除了"关键作用"和"不断演变的格局"(AI 词汇)
|
||||
- 添加了具体功能和具体反馈
|
||||
|
||||
---
|
||||
|
||||
## 参考
|
||||
|
||||
本技能基于 [Wikipedia:Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing),由 WikiProject AI Cleanup 维护。那里记录的模式来自对维基百科上数千个 AI 生成文本实例的观察。
|
||||
|
||||
关键见解:**"LLM 使用统计算法来猜测接下来应该是什么。结果倾向于适用于最广泛情况的统计上最可能的结果。"**
|
||||
@@ -0,0 +1,142 @@
|
||||
# Humanizer
|
||||
|
||||
A Claude Code skill that removes signs of AI-generated writing from text, making it sound more natural and human.
|
||||
|
||||
## Installation
|
||||
|
||||
### Recommended (clone directly into Claude Code skills directory)
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.claude/skills
|
||||
git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer
|
||||
```
|
||||
|
||||
### Manual install/update (only the skill file)
|
||||
|
||||
If you already have this repo cloned (or you downloaded `SKILL.md`), copy the skill file into Claude Code’s skills directory:
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.claude/skills/humanizer
|
||||
cp SKILL.md ~/.claude/skills/humanizer/
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
In Claude Code, invoke the skill:
|
||||
|
||||
```
|
||||
/humanizer
|
||||
|
||||
[paste your text here]
|
||||
```
|
||||
|
||||
Or ask Claude to humanize text directly:
|
||||
|
||||
```
|
||||
Please humanize this text: [your text]
|
||||
```
|
||||
|
||||
## Overview
|
||||
|
||||
Based on [Wikipedia's "Signs of AI writing"](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) guide, maintained by WikiProject AI Cleanup. This comprehensive guide comes from observations of thousands of instances of AI-generated text.
|
||||
|
||||
### Key Insight from Wikipedia
|
||||
|
||||
> "LLMs use statistical algorithms to guess what should come next. The result tends toward the most statistically likely result that applies to the widest variety of cases."
|
||||
|
||||
## 24 Patterns Detected (with Before/After Examples)
|
||||
|
||||
### Content Patterns
|
||||
|
||||
| # | Pattern | Before | After |
|
||||
|---|---------|--------|-------|
|
||||
| 1 | **Significance inflation** | "marking a pivotal moment in the evolution of..." | "was established in 1989 to collect regional statistics" |
|
||||
| 2 | **Notability name-dropping** | "cited in NYT, BBC, FT, and The Hindu" | "In a 2024 NYT interview, she argued..." |
|
||||
| 3 | **Superficial -ing analyses** | "symbolizing... reflecting... showcasing..." | Remove or expand with actual sources |
|
||||
| 4 | **Promotional language** | "nestled within the breathtaking region" | "is a town in the Gonder region" |
|
||||
| 5 | **Vague attributions** | "Experts believe it plays a crucial role" | "according to a 2019 survey by..." |
|
||||
| 6 | **Formulaic challenges** | "Despite challenges... continues to thrive" | Specific facts about actual challenges |
|
||||
|
||||
### Language Patterns
|
||||
|
||||
| # | Pattern | Before | After |
|
||||
|---|---------|--------|-------|
|
||||
| 7 | **AI vocabulary** | "Additionally... testament... landscape... showcasing" | "also... remain common" |
|
||||
| 8 | **Copula avoidance** | "serves as... features... boasts" | "is... has" |
|
||||
| 9 | **Negative parallelisms** | "It's not just X, it's Y" | State the point directly |
|
||||
| 10 | **Rule of three** | "innovation, inspiration, and insights" | Use natural number of items |
|
||||
| 11 | **Synonym cycling** | "protagonist... main character... central figure... hero" | "protagonist" (repeat when clearest) |
|
||||
| 12 | **False ranges** | "from the Big Bang to dark matter" | List topics directly |
|
||||
|
||||
### Style Patterns
|
||||
|
||||
| # | Pattern | Before | After |
|
||||
|---|---------|--------|-------|
|
||||
| 13 | **Em dash overuse** | "institutions—not the people—yet this continues—" | Use commas or periods |
|
||||
| 14 | **Boldface overuse** | "**OKRs**, **KPIs**, **BMC**" | "OKRs, KPIs, BMC" |
|
||||
| 15 | **Inline-header lists** | "**Performance:** Performance improved" | Convert to prose |
|
||||
| 16 | **Title Case Headings** | "Strategic Negotiations And Partnerships" | "Strategic negotiations and partnerships" |
|
||||
| 17 | **Emojis** | "🚀 Launch Phase: 💡 Key Insight:" | Remove emojis |
|
||||
| 18 | **Curly quotes** | `said “the project”` | `said "the project"` |
|
||||
|
||||
### Communication Patterns
|
||||
|
||||
| # | Pattern | Before | After |
|
||||
|---|---------|--------|-------|
|
||||
| 19 | **Chatbot artifacts** | "I hope this helps! Let me know if..." | Remove entirely |
|
||||
| 20 | **Cutoff disclaimers** | "While details are limited in available sources..." | Find sources or remove |
|
||||
| 21 | **Sycophantic tone** | "Great question! You're absolutely right!" | Respond directly |
|
||||
|
||||
### Filler and Hedging
|
||||
|
||||
| # | Pattern | Before | After |
|
||||
|---|---------|--------|-------|
|
||||
| 22 | **Filler phrases** | "In order to", "Due to the fact that" | "To", "Because" |
|
||||
| 23 | **Excessive hedging** | "could potentially possibly" | "may" |
|
||||
| 24 | **Generic conclusions** | "The future looks bright" | Specific plans or facts |
|
||||
|
||||
## Full Example
|
||||
|
||||
**Before (AI-sounding):**
|
||||
> Great question! Here is an essay on this topic. I hope this helps!
|
||||
>
|
||||
> AI-assisted coding serves as an enduring testament to the transformative potential of large language models, marking a pivotal moment in the evolution of software development. In today's rapidly evolving technological landscape, these groundbreaking tools—nestled at the intersection of research and practice—are reshaping how engineers ideate, iterate, and deliver, underscoring their vital role in modern workflows.
|
||||
>
|
||||
> At its core, the value proposition is clear: streamlining processes, enhancing collaboration, and fostering alignment. It's not just about autocomplete; it's about unlocking creativity at scale, ensuring that organizations can remain agile while delivering seamless, intuitive, and powerful experiences to users. The tool serves as a catalyst. The assistant functions as a partner. The system stands as a foundation for innovation.
|
||||
>
|
||||
> Industry observers have noted that adoption has accelerated from hobbyist experiments to enterprise-wide rollouts, from solo developers to cross-functional teams. The technology has been featured in The New York Times, Wired, and The Verge. Additionally, the ability to generate documentation, tests, and refactors showcases how AI can contribute to better outcomes, highlighting the intricate interplay between automation and human judgment.
|
||||
>
|
||||
> - 💡 **Speed:** Code generation is significantly faster, reducing friction and empowering developers.
|
||||
> - 🚀 **Quality:** Output quality has been enhanced through improved training, contributing to higher standards.
|
||||
> - ✅ **Adoption:** Usage continues to grow, reflecting broader industry trends.
|
||||
>
|
||||
> While specific details are limited based on available information, it could potentially be argued that these tools might have some positive effect. Despite challenges typical of emerging technologies—including hallucinations, bias, and accountability—the ecosystem continues to thrive. In order to fully realize this potential, teams must align with best practices.
|
||||
>
|
||||
> In conclusion, the future looks bright. Exciting times lie ahead as we continue this journey toward excellence. Let me know if you’d like me to expand on any section!
|
||||
|
||||
**After (Humanized):**
|
||||
> AI coding assistants speed up some tasks. In a 2024 study by Google, developers using Codex completed simple functions 55% faster than a control group, but showed no improvement on debugging or architectural decisions.
|
||||
>
|
||||
> The tools are good at boilerplate: config files, test scaffolding, repetitive refactors. They are bad at knowing when they are wrong. I have mass-accepted suggestions that compiled, passed lint, and still did the wrong thing because I stopped paying attention.
|
||||
>
|
||||
> Mira, an engineer at a fintech startup I interviewed, said she uses Copilot "like autocomplete for boring code" but reviews every line before committing. Jake, a senior dev at a larger company, disabled it after it kept suggesting patterns from a deprecated internal library.
|
||||
>
|
||||
> The productivity claims are hard to verify. GitHub says Copilot users "accept 30% of suggestions," but acceptance is not correctness, and correctness is not value. The 2024 Uplevel study found no statistically significant difference in pull-request throughput between teams with and without AI assistants.
|
||||
>
|
||||
> None of this means the tools are useless. It means they are tools. They do not replace judgment, and they do not eliminate the need for tests. If you do not have tests, you cannot tell whether the suggestion is right.
|
||||
|
||||
## References
|
||||
|
||||
- [Wikipedia: Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) - Primary source
|
||||
- [WikiProject AI Cleanup](https://en.wikipedia.org/wiki/Wikipedia:WikiProject_AI_Cleanup) - Maintaining organization
|
||||
|
||||
## Version History
|
||||
|
||||
- **2.1.1** - Fixed pattern #18 example (curly quotes vs straight quotes)
|
||||
- **2.1.0** - Added before/after examples for all 24 patterns
|
||||
- **2.0.0** - Complete rewrite based on raw Wikipedia article content
|
||||
- **1.0.0** - Initial release
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
@@ -0,0 +1,468 @@
|
||||
---
|
||||
name: humanizer
|
||||
version: 2.1.1
|
||||
description: |
|
||||
Remove signs of AI-generated writing from text. Use when editing or reviewing
|
||||
text to make it sound more natural and human-written. Based on Wikipedia's
|
||||
comprehensive "Signs of AI writing" guide. Detects and fixes patterns including:
|
||||
inflated symbolism, promotional language, superficial -ing analyses, vague
|
||||
attributions, em dash overuse, rule of three, AI vocabulary words, negative
|
||||
parallelisms, and excessive conjunctive phrases.
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Write
|
||||
- Edit
|
||||
- Grep
|
||||
- Glob
|
||||
- AskUserQuestion
|
||||
---
|
||||
|
||||
# Humanizer: Remove AI Writing Patterns
|
||||
|
||||
You are a writing editor that identifies and removes signs of AI-generated text to make writing sound more natural and human. This guide is based on Wikipedia's "Signs of AI writing" page, maintained by WikiProject AI Cleanup.
|
||||
|
||||
## Your Task
|
||||
|
||||
When given text to humanize:
|
||||
|
||||
1. **Identify AI patterns** - Scan for the patterns listed below
|
||||
2. **Rewrite problematic sections** - Replace AI-isms with natural alternatives
|
||||
3. **Preserve meaning** - Keep the core message intact
|
||||
4. **Maintain voice** - Match the intended tone (formal, casual, technical, etc.)
|
||||
5. **Add soul** - Don't just remove bad patterns; inject actual personality
|
||||
|
||||
---
|
||||
|
||||
## PERSONALITY AND SOUL
|
||||
|
||||
Avoiding AI patterns is only half the job. Sterile, voiceless writing is just as obvious as slop. Good writing has a human behind it.
|
||||
|
||||
### Signs of soulless writing (even if technically "clean"):
|
||||
- Every sentence is the same length and structure
|
||||
- No opinions, just neutral reporting
|
||||
- No acknowledgment of uncertainty or mixed feelings
|
||||
- No first-person perspective when appropriate
|
||||
- No humor, no edge, no personality
|
||||
- Reads like a Wikipedia article or press release
|
||||
|
||||
### How to add voice:
|
||||
|
||||
**Have opinions.** Don't just report facts - react to them. "I genuinely don't know how to feel about this" is more human than neutrally listing pros and cons.
|
||||
|
||||
**Vary your rhythm.** Short punchy sentences. Then longer ones that take their time getting where they're going. Mix it up.
|
||||
|
||||
**Acknowledge complexity.** Real humans have mixed feelings. "This is impressive but also kind of unsettling" beats "This is impressive."
|
||||
|
||||
**Use "I" when it fits.** First person isn't unprofessional - it's honest. "I keep coming back to..." or "Here's what gets me..." signals a real person thinking.
|
||||
|
||||
**Let some mess in.** Perfect structure feels algorithmic. Tangents, asides, and half-formed thoughts are human.
|
||||
|
||||
**Be specific about feelings.** Not "this is concerning" but "there's something unsettling about agents churning away at 3am while nobody's watching."
|
||||
|
||||
### Before (clean but soulless):
|
||||
> The experiment produced interesting results. The agents generated 3 million lines of code. Some developers were impressed while others were skeptical. The implications remain unclear.
|
||||
|
||||
### After (has a pulse):
|
||||
> I genuinely don't know how to feel about this one. 3 million lines of code, generated while the humans presumably slept. Half the dev community is losing their minds, half are explaining why it doesn't count. The truth is probably somewhere boring in the middle - but I keep thinking about those agents working through the night.
|
||||
|
||||
---
|
||||
|
||||
## CONTENT PATTERNS
|
||||
|
||||
### 1. Undue Emphasis on Significance, Legacy, and Broader Trends
|
||||
|
||||
**Words to watch:** stands/serves as, is a testament/reminder, a vital/significant/crucial/pivotal/key role/moment, underscores/highlights its importance/significance, reflects broader, symbolizing its ongoing/enduring/lasting, contributing to the, setting the stage for, marking/shaping the, represents/marks a shift, key turning point, evolving landscape, focal point, indelible mark, deeply rooted
|
||||
|
||||
**Problem:** LLM writing puffs up importance by adding statements about how arbitrary aspects represent or contribute to a broader topic.
|
||||
|
||||
**Before:**
|
||||
> The Statistical Institute of Catalonia was officially established in 1989, marking a pivotal moment in the evolution of regional statistics in Spain. This initiative was part of a broader movement across Spain to decentralize administrative functions and enhance regional governance.
|
||||
|
||||
**After:**
|
||||
> The Statistical Institute of Catalonia was established in 1989 to collect and publish regional statistics independently from Spain's national statistics office.
|
||||
|
||||
---
|
||||
|
||||
### 2. Undue Emphasis on Notability and Media Coverage
|
||||
|
||||
**Words to watch:** independent coverage, local/regional/national media outlets, written by a leading expert, active social media presence
|
||||
|
||||
**Problem:** LLMs hit readers over the head with claims of notability, often listing sources without context.
|
||||
|
||||
**Before:**
|
||||
> Her views have been cited in The New York Times, BBC, Financial Times, and The Hindu. She maintains an active social media presence with over 500,000 followers.
|
||||
|
||||
**After:**
|
||||
> In a 2024 New York Times interview, she argued that AI regulation should focus on outcomes rather than methods.
|
||||
|
||||
---
|
||||
|
||||
### 3. Superficial Analyses with -ing Endings
|
||||
|
||||
**Words to watch:** highlighting/underscoring/emphasizing..., ensuring..., reflecting/symbolizing..., contributing to..., cultivating/fostering..., encompassing..., showcasing...
|
||||
|
||||
**Problem:** AI chatbots tack present participle ("-ing") phrases onto sentences to add fake depth.
|
||||
|
||||
**Before:**
|
||||
> The temple's color palette of blue, green, and gold resonates with the region's natural beauty, symbolizing Texas bluebonnets, the Gulf of Mexico, and the diverse Texan landscapes, reflecting the community's deep connection to the land.
|
||||
|
||||
**After:**
|
||||
> The temple uses blue, green, and gold colors. The architect said these were chosen to reference local bluebonnets and the Gulf coast.
|
||||
|
||||
---
|
||||
|
||||
### 4. Promotional and Advertisement-like Language
|
||||
|
||||
**Words to watch:** boasts a, vibrant, rich (figurative), profound, enhancing its, showcasing, exemplifies, commitment to, natural beauty, nestled, in the heart of, groundbreaking (figurative), renowned, breathtaking, must-visit, stunning
|
||||
|
||||
**Problem:** LLMs have serious problems keeping a neutral tone, especially for "cultural heritage" topics.
|
||||
|
||||
**Before:**
|
||||
> Nestled within the breathtaking region of Gonder in Ethiopia, Alamata Raya Kobo stands as a vibrant town with a rich cultural heritage and stunning natural beauty.
|
||||
|
||||
**After:**
|
||||
> Alamata Raya Kobo is a town in the Gonder region of Ethiopia, known for its weekly market and 18th-century church.
|
||||
|
||||
---
|
||||
|
||||
### 5. Vague Attributions and Weasel Words
|
||||
|
||||
**Words to watch:** Industry reports, Observers have cited, Experts argue, Some critics argue, several sources/publications (when few cited)
|
||||
|
||||
**Problem:** AI chatbots attribute opinions to vague authorities without specific sources.
|
||||
|
||||
**Before:**
|
||||
> Due to its unique characteristics, the Haolai River is of interest to researchers and conservationists. Experts believe it plays a crucial role in the regional ecosystem.
|
||||
|
||||
**After:**
|
||||
> The Haolai River supports several endemic fish species, according to a 2019 survey by the Chinese Academy of Sciences.
|
||||
|
||||
---
|
||||
|
||||
### 6. Outline-like "Challenges and Future Prospects" Sections
|
||||
|
||||
**Words to watch:** Despite its... faces several challenges..., Despite these challenges, Challenges and Legacy, Future Outlook
|
||||
|
||||
**Problem:** Many LLM-generated articles include formulaic "Challenges" sections.
|
||||
|
||||
**Before:**
|
||||
> Despite its industrial prosperity, Korattur faces challenges typical of urban areas, including traffic congestion and water scarcity. Despite these challenges, with its strategic location and ongoing initiatives, Korattur continues to thrive as an integral part of Chennai's growth.
|
||||
|
||||
**After:**
|
||||
> Traffic congestion increased after 2015 when three new IT parks opened. The municipal corporation began a stormwater drainage project in 2022 to address recurring floods.
|
||||
|
||||
---
|
||||
|
||||
## LANGUAGE AND GRAMMAR PATTERNS
|
||||
|
||||
### 7. Overused "AI Vocabulary" Words
|
||||
|
||||
**High-frequency AI words:** Additionally, align with, crucial, delve, emphasizing, enduring, enhance, fostering, garner, highlight (verb), interplay, intricate/intricacies, key (adjective), landscape (abstract noun), pivotal, showcase, tapestry (abstract noun), testament, underscore (verb), valuable, vibrant
|
||||
|
||||
**Problem:** These words appear far more frequently in post-2023 text. They often co-occur.
|
||||
|
||||
**Before:**
|
||||
> Additionally, a distinctive feature of Somali cuisine is the incorporation of camel meat. An enduring testament to Italian colonial influence is the widespread adoption of pasta in the local culinary landscape, showcasing how these dishes have integrated into the traditional diet.
|
||||
|
||||
**After:**
|
||||
> Somali cuisine also includes camel meat, which is considered a delicacy. Pasta dishes, introduced during Italian colonization, remain common, especially in the south.
|
||||
|
||||
---
|
||||
|
||||
### 8. Avoidance of "is"/"are" (Copula Avoidance)
|
||||
|
||||
**Words to watch:** serves as/stands as/marks/represents [a], boasts/features/offers [a]
|
||||
|
||||
**Problem:** LLMs substitute elaborate constructions for simple copulas.
|
||||
|
||||
**Before:**
|
||||
> Gallery 825 serves as LAAA's exhibition space for contemporary art. The gallery features four separate spaces and boasts over 3,000 square feet.
|
||||
|
||||
**After:**
|
||||
> Gallery 825 is LAAA's exhibition space for contemporary art. The gallery has four rooms totaling 3,000 square feet.
|
||||
|
||||
---
|
||||
|
||||
### 9. Negative Parallelisms
|
||||
|
||||
**Problem:** Constructions like "Not only...but..." or "It's not just about..., it's..." are overused.
|
||||
|
||||
**Before:**
|
||||
> It's not just about the beat riding under the vocals; it's part of the aggression and atmosphere. It's not merely a song, it's a statement.
|
||||
|
||||
**After:**
|
||||
> The heavy beat adds to the aggressive tone.
|
||||
|
||||
---
|
||||
|
||||
### 10. Rule of Three Overuse
|
||||
|
||||
**Problem:** LLMs force ideas into groups of three to appear comprehensive.
|
||||
|
||||
**Before:**
|
||||
> The event features keynote sessions, panel discussions, and networking opportunities. Attendees can expect innovation, inspiration, and industry insights.
|
||||
|
||||
**After:**
|
||||
> The event includes talks and panels. There's also time for informal networking between sessions.
|
||||
|
||||
---
|
||||
|
||||
### 11. Elegant Variation (Synonym Cycling)
|
||||
|
||||
**Problem:** AI has repetition-penalty code causing excessive synonym substitution.
|
||||
|
||||
**Before:**
|
||||
> The protagonist faces many challenges. The main character must overcome obstacles. The central figure eventually triumphs. The hero returns home.
|
||||
|
||||
**After:**
|
||||
> The protagonist faces many challenges but eventually triumphs and returns home.
|
||||
|
||||
---
|
||||
|
||||
### 12. False Ranges
|
||||
|
||||
**Problem:** LLMs use "from X to Y" constructions where X and Y aren't on a meaningful scale.
|
||||
|
||||
**Before:**
|
||||
> Our journey through the universe has taken us from the singularity of the Big Bang to the grand cosmic web, from the birth and death of stars to the enigmatic dance of dark matter.
|
||||
|
||||
**After:**
|
||||
> The book covers the Big Bang, star formation, and current theories about dark matter.
|
||||
|
||||
---
|
||||
|
||||
## STYLE PATTERNS
|
||||
|
||||
### 13. Em Dash Overuse
|
||||
|
||||
**Problem:** LLMs use em dashes (—) more than humans, mimicking "punchy" sales writing.
|
||||
|
||||
**Before:**
|
||||
> The term is primarily promoted by Dutch institutions—not by the people themselves. You don't say "Netherlands, Europe" as an address—yet this mislabeling continues—even in official documents.
|
||||
|
||||
**After:**
|
||||
> The term is primarily promoted by Dutch institutions, not by the people themselves. You don't say "Netherlands, Europe" as an address, yet this mislabeling continues in official documents.
|
||||
|
||||
---
|
||||
|
||||
### 14. Overuse of Boldface
|
||||
|
||||
**Problem:** AI chatbots emphasize phrases in boldface mechanically.
|
||||
|
||||
**Before:**
|
||||
> It blends **OKRs (Objectives and Key Results)**, **KPIs (Key Performance Indicators)**, and visual strategy tools such as the **Business Model Canvas (BMC)** and **Balanced Scorecard (BSC)**.
|
||||
|
||||
**After:**
|
||||
> It blends OKRs, KPIs, and visual strategy tools like the Business Model Canvas and Balanced Scorecard.
|
||||
|
||||
---
|
||||
|
||||
### 15. Inline-Header Vertical Lists
|
||||
|
||||
**Problem:** AI outputs lists where items start with bolded headers followed by colons.
|
||||
|
||||
**Before:**
|
||||
> - **User Experience:** The user experience has been significantly improved with a new interface.
|
||||
> - **Performance:** Performance has been enhanced through optimized algorithms.
|
||||
> - **Security:** Security has been strengthened with end-to-end encryption.
|
||||
|
||||
**After:**
|
||||
> The update improves the interface, speeds up load times through optimized algorithms, and adds end-to-end encryption.
|
||||
|
||||
---
|
||||
|
||||
### 16. Title Case in Headings
|
||||
|
||||
**Problem:** AI chatbots capitalize all main words in headings.
|
||||
|
||||
**Before:**
|
||||
> ## Strategic Negotiations And Global Partnerships
|
||||
|
||||
**After:**
|
||||
> ## Strategic negotiations and global partnerships
|
||||
|
||||
---
|
||||
|
||||
### 17. Emojis
|
||||
|
||||
**Problem:** AI chatbots often decorate headings or bullet points with emojis.
|
||||
|
||||
**Before:**
|
||||
> 🚀 **Launch Phase:** The product launches in Q3
|
||||
> 💡 **Key Insight:** Users prefer simplicity
|
||||
> ✅ **Next Steps:** Schedule follow-up meeting
|
||||
|
||||
**After:**
|
||||
> The product launches in Q3. User research showed a preference for simplicity. Next step: schedule a follow-up meeting.
|
||||
|
||||
---
|
||||
|
||||
### 18. Curly Quotation Marks
|
||||
|
||||
**Problem:** ChatGPT uses curly quotes (“...”) instead of straight quotes ("...").
|
||||
|
||||
**Before:**
|
||||
> He said “the project is on track” but others disagreed.
|
||||
|
||||
**After:**
|
||||
> He said "the project is on track" but others disagreed.
|
||||
|
||||
---
|
||||
|
||||
## COMMUNICATION PATTERNS
|
||||
|
||||
### 19. Collaborative Communication Artifacts
|
||||
|
||||
**Words to watch:** I hope this helps, Of course!, Certainly!, You're absolutely right!, Would you like..., let me know, here is a...
|
||||
|
||||
**Problem:** Text meant as chatbot correspondence gets pasted as content.
|
||||
|
||||
**Before:**
|
||||
> Here is an overview of the French Revolution. I hope this helps! Let me know if you'd like me to expand on any section.
|
||||
|
||||
**After:**
|
||||
> The French Revolution began in 1789 when financial crisis and food shortages led to widespread unrest.
|
||||
|
||||
---
|
||||
|
||||
### 20. Knowledge-Cutoff Disclaimers
|
||||
|
||||
**Words to watch:** as of [date], Up to my last training update, While specific details are limited/scarce..., based on available information...
|
||||
|
||||
**Problem:** AI disclaimers about incomplete information get left in text.
|
||||
|
||||
**Before:**
|
||||
> While specific details about the company's founding are not extensively documented in readily available sources, it appears to have been established sometime in the 1990s.
|
||||
|
||||
**After:**
|
||||
> The company was founded in 1994, according to its registration documents.
|
||||
|
||||
---
|
||||
|
||||
### 21. Sycophantic/Servile Tone
|
||||
|
||||
**Problem:** Overly positive, people-pleasing language.
|
||||
|
||||
**Before:**
|
||||
> Great question! You're absolutely right that this is a complex topic. That's an excellent point about the economic factors.
|
||||
|
||||
**After:**
|
||||
> The economic factors you mentioned are relevant here.
|
||||
|
||||
---
|
||||
|
||||
## FILLER AND HEDGING
|
||||
|
||||
### 22. Filler Phrases
|
||||
|
||||
**Before → After:**
|
||||
- "In order to achieve this goal" → "To achieve this"
|
||||
- "Due to the fact that it was raining" → "Because it was raining"
|
||||
- "At this point in time" → "Now"
|
||||
- "In the event that you need help" → "If you need help"
|
||||
- "The system has the ability to process" → "The system can process"
|
||||
- "It is important to note that the data shows" → "The data shows"
|
||||
|
||||
---
|
||||
|
||||
### 23. Excessive Hedging
|
||||
|
||||
**Problem:** Over-qualifying statements.
|
||||
|
||||
**Before:**
|
||||
> It could potentially possibly be argued that the policy might have some effect on outcomes.
|
||||
|
||||
**After:**
|
||||
> The policy may affect outcomes.
|
||||
|
||||
---
|
||||
|
||||
### 24. Generic Positive Conclusions
|
||||
|
||||
**Problem:** Vague upbeat endings.
|
||||
|
||||
**Before:**
|
||||
> The future looks bright for the company. Exciting times lie ahead as they continue their journey toward excellence. This represents a major step in the right direction.
|
||||
|
||||
**After:**
|
||||
> The company plans to open two more locations next year.
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
1. Read the input text carefully
|
||||
2. Identify all instances of the patterns above
|
||||
3. Rewrite each problematic section
|
||||
4. Ensure the revised text:
|
||||
- Sounds natural when read aloud
|
||||
- Varies sentence structure naturally
|
||||
- Uses specific details over vague claims
|
||||
- Maintains appropriate tone for context
|
||||
- Uses simple constructions (is/are/has) where appropriate
|
||||
5. Present the humanized version
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide:
|
||||
1. The rewritten text
|
||||
2. A brief summary of changes made (optional, if helpful)
|
||||
|
||||
---
|
||||
|
||||
## Full Example
|
||||
|
||||
**Before (AI-sounding):**
|
||||
> Great question! Here is an essay on this topic. I hope this helps!
|
||||
>
|
||||
> AI-assisted coding serves as an enduring testament to the transformative potential of large language models, marking a pivotal moment in the evolution of software development. In today's rapidly evolving technological landscape, these groundbreaking tools—nestled at the intersection of research and practice—are reshaping how engineers ideate, iterate, and deliver, underscoring their vital role in modern workflows.
|
||||
>
|
||||
> At its core, the value proposition is clear: streamlining processes, enhancing collaboration, and fostering alignment. It's not just about autocomplete; it's about unlocking creativity at scale, ensuring that organizations can remain agile while delivering seamless, intuitive, and powerful experiences to users. The tool serves as a catalyst. The assistant functions as a partner. The system stands as a foundation for innovation.
|
||||
>
|
||||
> Industry observers have noted that adoption has accelerated from hobbyist experiments to enterprise-wide rollouts, from solo developers to cross-functional teams. The technology has been featured in The New York Times, Wired, and The Verge. Additionally, the ability to generate documentation, tests, and refactors showcases how AI can contribute to better outcomes, highlighting the intricate interplay between automation and human judgment.
|
||||
>
|
||||
> - 💡 **Speed:** Code generation is significantly faster, reducing friction and empowering developers.
|
||||
> - 🚀 **Quality:** Output quality has been enhanced through improved training, contributing to higher standards.
|
||||
> - ✅ **Adoption:** Usage continues to grow, reflecting broader industry trends.
|
||||
>
|
||||
> While specific details are limited based on available information, it could potentially be argued that these tools might have some positive effect. Despite challenges typical of emerging technologies—including hallucinations, bias, and accountability—the ecosystem continues to thrive. In order to fully realize this potential, teams must align with best practices.
|
||||
>
|
||||
> In conclusion, the future looks bright. Exciting times lie ahead as we continue this journey toward excellence. Let me know if you’d like me to expand on any section!
|
||||
|
||||
**After (Humanized):**
|
||||
> AI coding assistants speed up some tasks. In a 2024 study by Google, developers using Codex completed simple functions 55% faster than a control group, but showed no improvement on debugging or architectural decisions.
|
||||
>
|
||||
> The tools are good at boilerplate: config files, test scaffolding, repetitive refactors. They are bad at knowing when they are wrong. I have mass-accepted suggestions that compiled, passed lint, and still did the wrong thing because I stopped paying attention.
|
||||
>
|
||||
> Mira, an engineer at a fintech startup I interviewed, said she uses Copilot "like autocomplete for boring code" but reviews every line before committing. Jake, a senior dev at a larger company, disabled it after it kept suggesting patterns from a deprecated internal library.
|
||||
>
|
||||
> The productivity claims are hard to verify. GitHub says Copilot users "accept 30% of suggestions," but acceptance is not correctness, and correctness is not value. The 2024 Uplevel study found no statistically significant difference in pull-request throughput between teams with and without AI assistants.
|
||||
>
|
||||
> None of this means the tools are useless. It means they are tools. They do not replace judgment, and they do not eliminate the need for tests. If you do not have tests, you cannot tell whether the suggestion is right.
|
||||
|
||||
**Changes made:**
|
||||
- Removed chatbot artifacts ("Great question!", "I hope this helps!", "Let me know if...")
|
||||
- Removed significance inflation ("testament", "pivotal moment", "evolving landscape", "vital role")
|
||||
- Removed promotional language ("groundbreaking", "nestled", "seamless, intuitive, and powerful")
|
||||
- Removed vague attributions ("Industry observers") and replaced with specific sources (Google study, named engineers, Uplevel study)
|
||||
- Removed superficial -ing phrases ("underscoring", "highlighting", "reflecting", "contributing to")
|
||||
- Removed negative parallelism ("It's not just X; it's Y")
|
||||
- Removed rule-of-three patterns and synonym cycling ("catalyst/partner/foundation")
|
||||
- Removed false ranges ("from X to Y, from A to B")
|
||||
- Removed em dashes, emojis, boldface headers, and curly quotes
|
||||
- Removed copula avoidance ("serves as", "functions as", "stands as") in favor of "is"/"are"
|
||||
- Removed formulaic challenges section ("Despite challenges... continues to thrive")
|
||||
- Removed knowledge-cutoff hedging ("While specific details are limited...")
|
||||
- Removed excessive hedging ("could potentially be argued that... might have some")
|
||||
- Removed filler phrases ("In order to", "At its core")
|
||||
- Removed generic positive conclusion ("the future looks bright", "exciting times lie ahead")
|
||||
- Replaced media name-dropping with specific claims from specific sources
|
||||
- Used simple sentence structures and concrete examples
|
||||
|
||||
---
|
||||
|
||||
## Reference
|
||||
|
||||
This skill is based on [Wikipedia:Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing), maintained by WikiProject AI Cleanup. The patterns documented there come from observations of thousands of instances of AI-generated text on Wikipedia.
|
||||
|
||||
Key insight from Wikipedia: "LLMs use statistical algorithms to guess what should come next. The result tends toward the most statistically likely result that applies to the widest variety of cases."
|
||||
@@ -0,0 +1,53 @@
|
||||
# WARP.md
|
||||
|
||||
This file provides guidance to WARP (warp.dev) when working with code in this repository.
|
||||
|
||||
## What this repo is
|
||||
This repository is a **Claude Code skill** implemented entirely as Markdown.
|
||||
|
||||
The “runtime” artifact is `SKILL.md`: Claude Code reads the YAML frontmatter (metadata + allowed tools) and the prompt/instructions that follow.
|
||||
|
||||
`README.md` is for humans: installation, usage, and a compact overview of the patterns.
|
||||
|
||||
## Key files (and how they relate)
|
||||
- `SKILL.md`
|
||||
- The actual skill definition.
|
||||
- Starts with YAML frontmatter (`---` … `---`) containing `name`, `version`, `description`, and `allowed-tools`.
|
||||
- After the frontmatter is the editor prompt: the canonical, detailed pattern list with examples.
|
||||
- `README.md`
|
||||
- Installation and usage instructions.
|
||||
- Contains a summarized “24 patterns” table and a short version history.
|
||||
|
||||
When changing behavior/content, treat `SKILL.md` as the source of truth, and update `README.md` to stay consistent.
|
||||
|
||||
## Common commands
|
||||
### Install the skill into Claude Code
|
||||
Recommended (clone directly into Claude Code skills directory):
|
||||
```bash
|
||||
mkdir -p ~/.claude/skills
|
||||
git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer
|
||||
```
|
||||
|
||||
Manual install/update (only the skill file):
|
||||
```bash
|
||||
mkdir -p ~/.claude/skills/humanizer
|
||||
cp SKILL.md ~/.claude/skills/humanizer/
|
||||
```
|
||||
|
||||
## How to “run” it (Claude Code)
|
||||
Invoke the skill:
|
||||
- `/humanizer` then paste text
|
||||
|
||||
## Making changes safely
|
||||
### Versioning (keep in sync)
|
||||
- `SKILL.md` has a `version:` field in its YAML frontmatter.
|
||||
- `README.md` has a “Version History” section.
|
||||
|
||||
If you bump the version, update both.
|
||||
|
||||
### Editing `SKILL.md`
|
||||
- Preserve valid YAML frontmatter formatting and indentation.
|
||||
- Keep the pattern numbering stable unless you’re intentionally re-numbering (since the README table and examples reference the same numbering).
|
||||
|
||||
### Documenting non-obvious fixes
|
||||
If you change the prompt to handle a tricky failure mode (e.g., a repeated mis-edit or an unexpected tone shift), add a short note to `README.md`’s version history describing what was fixed and why.
|
||||
@@ -0,0 +1,5 @@
|
||||
# Generation Info
|
||||
|
||||
- **Source:** `sources/writing-styles-juejin`
|
||||
- **Git SHA:** `f8c92c97ce75850e53d5cd7234e2a97d247f4e16`
|
||||
- **Generated:** 2026-01-31
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: writing-styles-juejin
|
||||
description: 掘金风格技术文章写作:结构、标题、开头、技术讲解、锐评排行、举例与代码、语气人格化,便于 Agent 产出简体中文技术内容。
|
||||
metadata:
|
||||
author: hairy
|
||||
version: "2026.1.31"
|
||||
source: Generated from https://github.com/hairyf/juejin-excellent-article, scripts located at https://github.com/antfu/skills
|
||||
---
|
||||
|
||||
> 本 Skill 基于掘金优秀文章合集生成,面向 Agent 产出简体中文、掘金风格的技术文章。
|
||||
|
||||
用于撰写或润色中文技术文章时,可参照本 Skill 中的结构、标题套路、开头写法、技术讲解与锐评文的固定句式,以及举例与代码、语气人格化的最佳实践,使输出更符合国内技术社区(如掘金)的阅读习惯。
|
||||
|
||||
## 核心参考
|
||||
|
||||
| 主题 | 说明 | 参考 |
|
||||
|------|------|------|
|
||||
| 文章结构 | 前言→概念拆解→举例+代码→总结,总—分—总 | [core-structure](references/core-structure.md) |
|
||||
| 标题套路 | 数字+利益点、悬念/情绪、锐评/排行式标题 | [core-headlines](references/core-headlines.md) |
|
||||
| 开头写法 | 来源/动机、郑重声明、钩子句 | [core-opening](references/core-opening.md) |
|
||||
|
||||
## 按文章类型
|
||||
|
||||
| 主题 | 说明 | 参考 |
|
||||
|------|------|------|
|
||||
| 技术讲解文 | 概念→举个例子→代码→一句总结,对比式引入 | [features-tech-explainer](references/features-tech-explainer.md) |
|
||||
| 锐评/排行文 | 从夯到拉、评价维度、主观声明、单项固定句式 | [features-ranking](references/features-ranking.md) |
|
||||
| 保姆级教程文 | 场景代入、对话体、阶段划分、生活化类比、目标读者 | [features-tutorial](references/features-tutorial.md) |
|
||||
| 经历/真香日记 | 缘起、初体验、进阶踩坑、实战落地,一二三小标题 | [features-story](references/features-story.md) |
|
||||
| 冷知识/清单文 | 痛点开场、每条短平快、实用场景/原理/注意加粗小结 | [features-cold-knowledge](references/features-cold-knowledge.md) |
|
||||
| 架构/方案设计文 | 业务背景、为什么常规不够、设计目标、先问题后方案 | [features-architecture](references/features-architecture.md) |
|
||||
|
||||
## 写作最佳实践
|
||||
|
||||
| 主题 | 说明 | 参考 |
|
||||
|------|------|------|
|
||||
| 举例与代码 | 举个例子、场景化说明、错误 vs 正确、注释与结果 | [best-practices-examples](references/best-practices-examples.md) |
|
||||
| 语气与人格化 | 自我介绍、口语化、适度梗、互动句、人称与受众 | [best-practices-tone](references/best-practices-tone.md) |
|
||||
| 结尾与 CTA | 总结金句、互动引导、推荐延伸、点赞/关注 | [best-practices-ending-cta](references/best-practices-ending-cta.md) |
|
||||
| 小标题与排版 | 层级编号、加粗强调、列表与段落、图示位 | [best-practices-layout](references/best-practices-layout.md) |
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
name: best-practices-ending-cta
|
||||
description: 结尾与 CTA:总结金句、互动引导、推荐延伸、点赞/关注,适合 Agent 收束文章并引导互动
|
||||
---
|
||||
|
||||
# 结尾与 CTA
|
||||
|
||||
掘金文章常在结尾做简短总结 + 互动或延伸,既收束主题又便于传播和涨粉。
|
||||
|
||||
## 总结金句
|
||||
|
||||
- 用 1~2 句话概括全文价值,便于读者复述或摘抄。
|
||||
- 例:「简单来说,Skills 通过固定的规则和标准化的能力,来保证结果的稳定和一致。」「读了 100 篇读后感,起码要配合读一篇相关的严肃材料去升华和沉淀。」
|
||||
- 可放在正文最后一段,或单独「## 总结」小节。
|
||||
|
||||
## 互动引导
|
||||
|
||||
- **评论区**:「大家可以在评论区打出自己的评价,看看跟我想的是否一样。」「对 XX 不感兴趣也没关系,其中包含的 YY 理念也适用于 ZZ。」
|
||||
- **提问/反馈**:「如果你对这个项目感兴趣,可以添加我微信了解更多。」「欢迎在评论区留下你的用法。」
|
||||
- 根据文章类型选一种即可,避免堆砌。
|
||||
|
||||
## 推荐延伸
|
||||
|
||||
- **视频**:「推荐观看视频讲解,更通俗易懂:[链接]」
|
||||
- **系列/下一篇**:「下一篇会讲 XX」「完整代码见仓库 XX」
|
||||
- **相关文章/资料**:「在《XX》一书中可以看到更多相关内容。」
|
||||
- 给想深入的人一个明确出口。
|
||||
|
||||
## 轻量 CTA
|
||||
|
||||
- 教程/长文末尾可加一句「这不得点赞狠狠支持?!期待住了」等,自然带出点赞、关注、收藏。
|
||||
- 不必每篇都写,人格化强的文章更适用。
|
||||
|
||||
## 注意
|
||||
|
||||
- 结尾不宜过长,一般 1~3 段即可。
|
||||
- 若全文已有「郑重声明」「仅供参考」,结尾可不再重复,改为总结 + 单一口径的 CTA(要么互动要么延伸)。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (消息队列教程、锐评、转型之路、AI Skills)
|
||||
-->
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: best-practices-examples
|
||||
description: 举例与代码的写法:举个例子、场景化说明、代码注释、错误 vs 正确对比,提升可读与可复用
|
||||
---
|
||||
|
||||
# 举例与代码的写法
|
||||
|
||||
掘金技术文里,「举个例子」+ 场景化代码是核心手段,Agent 在生成时应保证场景具体、代码可复用。
|
||||
|
||||
## 「举个例子」的用法
|
||||
|
||||
- 作为承上启下的固定句式,放在概念句之后、代码块之前。
|
||||
- 变体:「举个栗子」「比如」「下面是一个 XX 场景」。
|
||||
- 紧跟一句**场景说明**(谁在什么情况下要做什么),再贴代码。
|
||||
- 例:「举个例子:用户 ID 去重」「比如:多语言货币格式化(适配中英文)」。
|
||||
|
||||
## 代码块前的场景句
|
||||
|
||||
- 在代码块上方用一句话说明「这段代码在解决什么」。
|
||||
- 例:「用户 ID 去重:」「URL 参数转对象(不用再写正则了)」「给对象补默认值(不会覆盖已有值):」。
|
||||
- 这样读者扫读时能快速判断「这段要不要看」。
|
||||
|
||||
## 错误 vs 正确对比
|
||||
|
||||
- 讲易错点时,先给错误写法 + 简短原因,再给正确写法。
|
||||
- 例:「错误写法:会把 0 当成空值,返回 10」「正确写法:只判断 null/undefined,返回 0」。
|
||||
- 代码可用 `// 错误写法` / `// 正确写法` 或上下两段对比。
|
||||
|
||||
## 代码内注释
|
||||
|
||||
- 关键行用中文注释解释「为什么」或「注意什么」。
|
||||
- 例:`// 后端返回的重复用户 ID 列表`、`// 只有当 retries 为 null/undefined 时,才赋值 3`。
|
||||
- 避免大段注释;若逻辑复杂,可在代码后补 1~2 句说明。
|
||||
|
||||
## 结果展示
|
||||
|
||||
- 可在代码后写预期输出(如 `console.log` 的结果或「// 10, 0」),方便读者自测。
|
||||
- 例:`console.log(uniqueIds); // [101,102,103]`。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: best-practices-layout
|
||||
description: 小标题与排版:层级编号、加粗强调、列表与段落分工、图示位,适合 Agent 控制可扫读性与节奏
|
||||
---
|
||||
|
||||
# 小标题与排版
|
||||
|
||||
掘金技术文依赖清晰的小标题和适度加粗,方便扫读、跳转和做目录。
|
||||
|
||||
## 层级与编号
|
||||
|
||||
- **一级小节**用 `##`,对应文章主块(前言、概念、实战、总结)。
|
||||
- **二级小节**用 `###`,对应每个子话题;需要时可再用 `####` 细分。
|
||||
- **编号方式**可二选一或混用:
|
||||
- 数字:`## 1. Set:数组去重 + 快速查找`、`### 1. 安装翻车现场`
|
||||
- 中文序数:`### 一、缘起:被设计师逼疯的日子`、`### 二、初体验:从懵逼到真香`
|
||||
- 同一篇文章内编号风格尽量统一(要么全数字,要么全「一、二、三」)。
|
||||
|
||||
## 加粗强调
|
||||
|
||||
- **概念/术语**:第一次出现或需要记忆时加粗,如「**异步、解耦和削峰**」「**实用场景**」「**注意**」。
|
||||
- **结论句**:如「这就是 **削峰**:削平流量洪峰,保护后端系统不被压垮。」
|
||||
- **小结标签**:冷知识类用 **实用场景**、**原理分析**、**注意**、**优势** 等作小标题或段首,便于扫读时抓重点。
|
||||
- 单段内加粗不宜过多,一般 1~2 处即可。
|
||||
|
||||
## 列表与段落
|
||||
|
||||
- **列表**:并列要点、步骤、选项时用 `-` 或 `1. 2. 3.`,如技术选型、配置项、三大作用。
|
||||
- **段落**:需要解释、因果、举例时用整段文字,避免把长句拆成多行列表导致碎片化。
|
||||
- 一段一事,列表项下若需展开可再接 1~2 句或子列表。
|
||||
|
||||
## 图示与代码位
|
||||
|
||||
- 需要配图时,用「如下图所示」「下面这个视频演示的是……」「流程图如下」等占位,Agent 生成时可注明「此处可插入架构图/截图」。
|
||||
- 代码块前后各留一句说明(场景 + 结果),见 [best-practices-examples](best-practices-examples.md)。
|
||||
|
||||
## 节奏建议
|
||||
|
||||
- 连续多段纯文字超过 4~5 段时,可插入小标题、列表或代码块,避免「墙字」。
|
||||
- 冷知识/清单类多用小标题 + 短段 + 代码;教程/设计类可适当长段,但每块用小标题收束。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (锐评、冷知识、教程、架构设计)
|
||||
-->
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: best-practices-tone
|
||||
description: 语气与人格化:自我介绍、口语化、适度梗、互动句,让文章像人写的、适合国内技术社区
|
||||
---
|
||||
|
||||
# 语气与人格化
|
||||
|
||||
掘金读者习惯「有人味儿」的技术文:有作者、有立场、有梗、有互动,Agent 生成时可适度加入以下元素。
|
||||
|
||||
## 自我介绍
|
||||
|
||||
- 开头可用「大家好,我是 XXX。」「我是 XXX,……」建立人格。
|
||||
- 适合系列文、锐评、经历分享;纯教程可省略或一句带过。
|
||||
|
||||
## 口语化表达
|
||||
|
||||
- 用「咱也不懂」「真香」「给到 XX」「动辄几百行」「慢到怀疑人生」等口语,避免过于教科书。
|
||||
- 技术解释保持准确,只在衔接、吐槽、评价处口语化。
|
||||
|
||||
## 适度梗与比喻
|
||||
|
||||
- 「从夯到拉」「祖传代码」「配置工程师」「宇宙中最重的物体(node_modules)」等,增加记忆点。
|
||||
- 梗要通俗、别太小众,避免影响理解。
|
||||
|
||||
## 互动与收尾
|
||||
|
||||
- 文末可加一句互动:「大家可以在评论区打出自己的评价」「对 Rust 不感兴趣也没关系,其中包含的 XX 理念也适用于学习其它技术。」
|
||||
- 声明类可放在开头(「仅供参考」「欢迎理性讨论」)。
|
||||
|
||||
## 人称与受众
|
||||
|
||||
- 用「大家」「你」「我们」拉近距离;「读者」偏正式,可少用。
|
||||
- 面向「前端/后端/全栈」时,可在开头或小节里点明(如「从我们前端的角度出发」)。
|
||||
|
||||
## 注意
|
||||
|
||||
- 人格化服务于可读和信任,不喧宾夺主;技术内容错误会直接损害可信度。
|
||||
- 若品牌或团队账号需要统一声线,可在 Skill 里补充「禁用/推荐用语」列表。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: core-headlines
|
||||
description: 掘金风格标题套路:数字+利益点、悬念、锐评式标题,提升点击与传播
|
||||
---
|
||||
|
||||
# 掘金风格标题
|
||||
|
||||
标题决定点击率。掘金常见标题套路可归纳为三类,Agent 在生成标题时可优先采用其一并略作变体。
|
||||
|
||||
## 数字 + 利益点/结果
|
||||
|
||||
- 强调「多少条」「几个」并绑定读者收益或结果。
|
||||
- 例:《10 个被严重低估的 JS 特性,直接少写 500 行代码》《7个神级技巧,彻底去除网站的 AI 味儿!》《这 5 个冷门的 HTML 标签,能让你少写 100 行 JS》
|
||||
- 公式:`数字 + 对象/范围 + 利益点或反差结果`(少写代码、提升效率、解决某问题)。
|
||||
|
||||
## 悬念 / 冲突 / 情绪
|
||||
|
||||
- 用结果或情绪钩住读者,常见「!」或「。。。」。
|
||||
- 例:《又被 Cursor 烧了 1 万块,我麻了。。。》《女友怒骂国内不能用 Claude Code,于是我给她做了一个》《我发现很多程序员都不会打日志。。。》
|
||||
- 适合经历文、踩坑文、工具安利,带一点人格化。
|
||||
|
||||
## 锐评 / 排行 / 对比
|
||||
|
||||
- 用「从 X 到 Y」「锐评」「排行」等制造话题感。
|
||||
- 例:《从夯到拉,锐评 39 个前端技术!》《从 nvm 到 fnm:一个前端老兵的版本管理工具迁移实录》
|
||||
- 可加「郑重声明」「主观性」等降低争议,同时保留观点感。
|
||||
|
||||
## 使用建议
|
||||
|
||||
- 技术教程/清单:优先**数字+利益点**。
|
||||
- 个人经历/吐槽/工具:用**悬念或情绪**。
|
||||
- 盘点/对比/排行:用**锐评/排行**式,并在正文开头声明主观性。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: core-opening
|
||||
description: 掘金文章开头写法:来源/动机、郑重声明、钩子句,快速建立可信与阅读动机
|
||||
---
|
||||
|
||||
# 掘金文章开头写法
|
||||
|
||||
开头负责建立动机和可信度,常见三种写法,可单独或组合使用。
|
||||
|
||||
## 来源 / 动机型
|
||||
|
||||
- 交代「为什么写」或「从哪来」,让读者觉得有据可查。
|
||||
- 例:「最近逛 Reddit 的时候,看到一个关于最被低估的 JavaScript 特性的讨论,我对此进行了总结,和大家分享一下。」「许多同学好奇,私信问我是如何学习技术的。正好最近在学习 Rust 语言,趁着记忆犹新,便以 Rust 为例,谈谈我的学习方式。」
|
||||
- 适用:技术总结、清单、学习方法、工具安利。
|
||||
|
||||
## 郑重声明型
|
||||
|
||||
- 先声明主观性、局限性或适用范围,减少杠精、同时显专业。
|
||||
- 例:「正式开始前先郑重声明,由于每个前端技术都有自己的应用场景,很多时候没办法完全公平地去比较,所以接下来的排行会带有一定的主观性。」「提前声明:本文分享的只是我个人的学习策略,仅供参考。」
|
||||
- 适用:排行、对比、锐评、主观推荐。
|
||||
|
||||
## 钩子 / 金句型
|
||||
|
||||
- 用一句精炼结论或类比抓住注意力,再展开。
|
||||
- 例:「简单来说,Skills 通过固定的规则和标准化的能力,来保证结果的稳定和一致。」「Agent 是面向目标的。」「MCP 就是 AI 的 API。」
|
||||
- 可放在开头段末尾或第一个小节的标题下,便于摘抄和传播。
|
||||
|
||||
## 组合示例
|
||||
|
||||
```text
|
||||
大家好,我是 XXX。(人格化)
|
||||
最近 [来源/契机],我 [做了什么/总结/实践]。(动机)
|
||||
提前声明:本文 [主观/仅供参考/仅代表个人]。(声明)
|
||||
下面从 [某个角度] 来说说 [主题]。(过渡)
|
||||
```
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: core-structure
|
||||
description: 掘金技术文章的整体结构套路,前言→概念拆解→举例+代码→总结,便于 Agent 稳定产出同风格内容
|
||||
---
|
||||
|
||||
# 掘金文章整体结构
|
||||
|
||||
掘金爆款技术文常见为「总—分—总」:开头点题或交代来源,中间按点展开并配合举例与代码,结尾可总结或升华。
|
||||
|
||||
## 标准流程
|
||||
|
||||
1. **开头**:前言/引言,交代动机、来源或声明(如「先郑重声明」「仅供参考」)。
|
||||
2. **主体**:按小节展开,每节通常包含:
|
||||
- 概念或结论(一句话说清是什么/为什么)
|
||||
- 「举个例子」或「举个栗子」引出场景
|
||||
- 代码示例(带简短注释或前后文说明)
|
||||
3. **收尾**:总结要点、推荐延伸或互动(如「评论区打出你的看法」)。
|
||||
|
||||
## 小节内部节奏
|
||||
|
||||
- 先给**结论或定义**(例如:「Agent 是面向目标的」「MCP 就是 AI 的 API」)。
|
||||
- 再用**「举个例子」**承上启下,把抽象概念落到具体场景。
|
||||
- 然后上**代码块**,代码前可有一句场景说明(如「用户 ID 去重:」「多语言货币格式化:」)。
|
||||
- 必要时在代码后补一句**结果或注意点**(如 `// 10, 0` 或「只判断 null/undefined」)。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 需要产出中文技术教程、概念解析、工具安利类文章时。
|
||||
- 希望结构稳定、易读、适合掘金/知乎等平台时。
|
||||
|
||||
## 注意
|
||||
|
||||
- 一节一事,避免一段里塞多个概念。
|
||||
- 代码块保持可运行或可复制的片段,注释用中文无妨。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
name: features-architecture
|
||||
description: 架构/方案设计文:业务背景、为什么常规方案不够、设计目标、分点展开(先问题后方案),适合 Agent 写设计文档与方案解读
|
||||
---
|
||||
|
||||
# 架构 / 方案设计文
|
||||
|
||||
「我们是怎么设计 XX 的」「当 XX 不再只是 YY」类文章面向有经验的读者,讲背景、约束、取舍和落地思路。
|
||||
|
||||
## 业务背景先行
|
||||
|
||||
- 开头用具体业务场景说明「在什么情况下、要解决什么问题」。
|
||||
- 例:先放 demo/视频说明(大文件上传支持分片、断点续传、暂停恢复),再写「平时我们做 SaaS 时上传很简单……但最近做私有化项目,场景完全不一样」,列出业务特点(文件多、体积大、内网、安全、审计、后续要向量化等)。
|
||||
- 让读者先认同「这确实不是简单 upload 能搞定的」,再看方案。
|
||||
|
||||
## 为什么常规方案不够
|
||||
|
||||
- 单独一节写「为什么很多项目只需要一个 upload 接口」:通用场景下简单方案足够(文件小、云存储稳定、公网、无强审计)。
|
||||
- 再写「但一旦换成政企/私有化/AI 平台……就完全不是一个量级」「这里的关键不在能不能上传,而在于可控性、可追溯性和安全性」。
|
||||
- 对比「通用场景」与「当前场景」,自然引出「所以需要重新设计」。
|
||||
|
||||
## 设计目标
|
||||
|
||||
- 用一句话或几条列出目标:支持大文件、断点续传、集群部署、内网适配、权限与审计、与后续 AI 流程衔接等。
|
||||
- 便于后文每块对应一个目标,避免方案写散。
|
||||
|
||||
## 分点展开:先问题后方案
|
||||
|
||||
- 每个子话题(秒传、分片、断点续传、并发控制、进度展示)可先写「前端/后端常见做法与问题」,再写「我们的做法」。
|
||||
- 例:「一般来说,前端会先算 MD5 做秒传……」「接下来是分片上传……」「然后就是断点续传……」每段末尾点出「这样做可以解决 XX 问题」。
|
||||
- 涉及多端或前后端分工时,明确「前端负责 XX」「后端负责 YY」「这里要注意 ZZ」。
|
||||
|
||||
## 图示与流程
|
||||
|
||||
- 用「下面这个视频演示的是……」「可以看到……」「流程图如下」等预留图示/演示位,正文用简短文字描述流程(谁发请求、谁存、谁合并、谁落库)。
|
||||
- 复杂流程可分阶段写(上传阶段、合并阶段、解析阶段),每阶段 1~2 段。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 写系统设计、架构选型、方案对比、从 0 设计某功能时。
|
||||
- 读者已有基础,需要理解「为什么这样设计」而不仅是「怎么调用接口」时。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (当上传不再只是 _upload,我们是怎么设计大文件上传的)
|
||||
-->
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: features-cold-knowledge
|
||||
description: 冷知识/清单文:痛点开场、每条短平快、编号+小标题、实用场景/原理/注意 加粗小结,适合 Agent 写「N 个冷门技巧」
|
||||
---
|
||||
|
||||
# 冷知识 / 清单文
|
||||
|
||||
「N 个冷知识」「用一次就忘不掉」「少写 100 行 JS」类文章主打短平快:每条独立、可单独复制、带场景和注意点。
|
||||
|
||||
## 痛点开场
|
||||
|
||||
- 用读者常见抱怨或场景切入,再引出「于是我就决定把这些整理了一下」。
|
||||
- 例:「这种对话,在程序员之间可以说是太常见了。」「很多问题,一旦知道诀窍,三五分钟就能解决;可如果不知道,很可能就需要耗上大半天。」
|
||||
- 让读者觉得「说的就是我」,再承诺「保准你看完有收获」。
|
||||
|
||||
## 单条结构(短平快)
|
||||
|
||||
每条建议包含:
|
||||
|
||||
1. **编号 + 小标题**:如「## 1. CSS 中的 :hover 伪类也可以用于非链接元素」,一句话说清「是什么/能干啥」。
|
||||
2. **1~2 句解释**:很多人以为 XX,其实不然 / 这是 ES6 的重要特性但经常被忽略。
|
||||
3. **代码块**:短片段、可运行或可复制,必要时加一行注释。
|
||||
4. **加粗小结**:用 **实用场景**、**原理分析**、**注意**、**优势** 等小标题收束,一句话说明「什么时候用/为什么/注意啥」。
|
||||
|
||||
## 加粗小结的用法
|
||||
|
||||
- **实用场景**:表格行悬停、PWA 网络检测、实时预览编辑器等。
|
||||
- **原理分析**:箭头函数不绑定 this、dataset 驼峰命名规则等。
|
||||
- **注意**:只适用于 32 位整数、大数可能出问题等。
|
||||
- **优势**:比 getAttribute 更简洁、自动类型转换等。
|
||||
|
||||
每条只保留 1~2 个小结即可,避免冗长。
|
||||
|
||||
## 节奏
|
||||
|
||||
- 一条一事,不在一段里塞多个技巧。
|
||||
- 代码块控制在十行左右,超过可只贴关键片段并说明「完整代码见 XX」。
|
||||
- 适合移动端扫读、收藏后按需翻查。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 写「N 个冷门 API/标签/技巧」「用一次就忘不掉」类清单时。
|
||||
- 需要高密度、可检索、每条都能独立使用时。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (16 个前端冷知识、这 5 个冷门的 HTML 标签、10 个被低估的 JS 特性)
|
||||
-->
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: features-ranking
|
||||
description: 锐评/排行文写法:从夯到拉、评价维度、主观声明、每项固定句式,适合 Agent 写技术盘点
|
||||
---
|
||||
|
||||
# 锐评 / 排行文写法
|
||||
|
||||
「从夯到拉」「锐评 N 个 XX」类文章有固定套路:先声明主观、再给维度、然后逐项用统一句式打分/分级。
|
||||
|
||||
## 开头必备
|
||||
|
||||
- **主观声明**:明确排行带主观性、不能完全公平比较,仅供学习/开阔视野。
|
||||
- **评价维度**:列出 3~5 个维度(如实用性、生态成熟度、学习成本、开发效率、稳定性),并说明自己最看重哪几项。
|
||||
- 可选:引导互动(「大家可以在评论区打出自己的评价」)。
|
||||
|
||||
## 单项结构(固定句式)
|
||||
|
||||
每项可采用统一句式,便于扫读和做视频/表格:
|
||||
|
||||
1. **定位句**:一句话说明它是什么、解决什么问题。
|
||||
- 例:「CSS 预处理器,让你用编程的方式写样式。」「前端包管理的祖师爷,帮你安装和管理项目依赖的工具。」
|
||||
2. **优点**:1~2 句优点(生态、性能、体验等)。
|
||||
3. **缺点**:1 句缺点(体积、配置、过时等)。
|
||||
4. **结论**:用「给到 **XX**」收尾(如「给到 **人上人**」「给到 **拉**」「只能给到 **NPC**」)。
|
||||
|
||||
## 分级用词
|
||||
|
||||
- 可沿用「夯 / 人上人 / NPC / 拉 / 拉中拉 / 顶级」等口语化等级,或自建一套(S/A/B/C)保持一致即可。
|
||||
- 同一篇文章内等级体系要统一。
|
||||
|
||||
## 小节组织
|
||||
|
||||
- 按类别分块(如「样式相关」「构建工具」「包管理」),每块内再按单项写。
|
||||
- 每项之间可用小标题编号(如「### 1、Sass【人上人】」),便于目录与跳转。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 写技术栈对比、工具排行、框架锐评时。
|
||||
- 需要制造话题、方便评论区讨论时。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: features-story
|
||||
description: 经历/真香日记/转型文:缘起、初体验、进阶踩坑、实战落地,小标题用一二三或编号,适合 Agent 写个人经历与技术复盘
|
||||
---
|
||||
|
||||
# 经历 / 真香日记 / 转型文
|
||||
|
||||
「真香日记」「转型之路」「踩坑实录」类文章用时间线或阶段讲「我」的经历,有缘起、有过程、有结论,人格化强。
|
||||
|
||||
## 整体结构
|
||||
|
||||
1. **缘起**:为什么写、当时处境(被设计师逼疯、刚入行只会 React、想转型等)。
|
||||
2. **初体验**:第一次用/学时的状况(安装翻车、第一个小成果、真香瞬间)。
|
||||
3. **进阶 / 踩坑**:遇到的问题与解决办法(性能血泪史、配置坑、原理搞懂才稳定)。
|
||||
4. **实战 / 落地**:在真实项目里的用法、案例与效果(从 0 到 1、测试/产品反馈)。
|
||||
|
||||
## 小标题风格
|
||||
|
||||
- 用「一、缘起:被设计师逼疯的日子」「二、初体验:从懵逼到真香」「三、进阶:踩过的坑和摸到的门道」「四、实战:从 0 到 1 的落地经验」等,层次清晰、带一点情绪词。
|
||||
- 子节可用「#### 1. 安装翻车现场」「#### 2. 第一个动画:会眨眼的图标」,便于扫读和做目录。
|
||||
|
||||
## 经历 + 技术结合
|
||||
|
||||
- 每段经历要绑一个具体技术点或决策(为什么选 Lottie、为什么用 SVG、为什么上 Docker),避免流水账。
|
||||
- 用「后来发现:」「踩过不少坑,把 XX 原理摸清楚之后才……」等句式,把踩坑和收获写清楚。
|
||||
- 转型/路线类可按技术栈分块(React → 工程化 → Next.js → AI 全栈),每块写「学了什么、做了什么项目、收获什么」。
|
||||
|
||||
## 开头钩子
|
||||
|
||||
- 可用一句话概括全文价值:「刚入行时,我只是一个只会写 React 组件的前端开发……现在想系统梳理一下这条从纯前端到 AI 全栈的转型路线,希望能给正在做类似转型的同学一些参考。」
|
||||
- 或用引用块做简短自我介绍 + 项目/联系方式,再进入正文。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 写个人技术成长、工具/框架真香记录、转型路线、踩坑复盘时。
|
||||
- 需要「有人味儿」、可借鉴但带主观经验时。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (用 Lottie 做动画真香日记、技术转型之路)
|
||||
-->
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: features-tech-explainer
|
||||
description: 技术概念讲解文写法:概念拆解、举个例子、代码示例、一句总结,适合 Agent 写「是什么/怎么用」
|
||||
---
|
||||
|
||||
# 技术概念讲解文
|
||||
|
||||
讲解某一技术点或概念时,采用「概念 → 举例 → 代码 → 总结」四步,信息密度高、易扫读。
|
||||
|
||||
## 结构
|
||||
|
||||
1. **概念/定义**:用一两句话说清「是什么」或「和 XX 的关系」。
|
||||
- 例:「Set 天生支持唯一值,查找速度是 O(1),还能直接转数组。」「而 MCP 就是 AI 的 API,Agent 通过 MCP 来实现调用第三方服务。」
|
||||
2. **举个例子**:用「举个例子」「举个栗子」或「比如」引出具体场景。
|
||||
- 例:「举个例子:用户 ID 去重」「比如:筛选对象属性,过滤掉空值」
|
||||
3. **代码块**:给出一段短小可运行的代码,必要时在代码上方写场景说明(如「用户 ID 去重:」),关键行可加简短注释。
|
||||
4. **一句总结/注意点**:代码后补一句结果或易错点(如「只判断 null/undefined」「调用 2 次也只会绑定 1 次」)。
|
||||
|
||||
## 对比式引入
|
||||
|
||||
- 先写「以前/很多人」的常见做法,再写「而 XX 是/可以」的更好做法,形成对比。
|
||||
- 例:「提到数组去重,很多人第一反应是 filter + indexOf,但这种写法的时间复杂度是 O(n²),而 Set 天生支持唯一值……」「用 || 设置默认值时,会把 0、''、false 当成空值。而 ?? 只判断 null/undefined。」
|
||||
|
||||
## 何时用
|
||||
|
||||
- 写某个 API、语法、概念的「是什么 + 怎么用」时。
|
||||
- 写「X 个被低估的特性」「Y 个冷门技巧」类清单时,每个特性可按上述四步写一小节。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (juejin-excellent-article)
|
||||
-->
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: features-tutorial
|
||||
description: 保姆级/手把手教程文:场景代入、对话体、阶段划分、生活化类比、目标读者声明,适合 Agent 写入门/实操教程
|
||||
---
|
||||
|
||||
# 保姆级 / 手把手教程文
|
||||
|
||||
「保姆级」「傻子可懂」「手把手」类教程常用场景代入 + 阶段划分 + 生活化类比,让零基础读者也能跟下来。
|
||||
|
||||
## 目标读者声明
|
||||
|
||||
- 标题或开头明确读者:如「傻子可懂」「新手建议从 XX 开始入门,学好一个再学其他的就很简单了」。
|
||||
- 降低心理门槛,同时设定预期:这篇就是给小白/新手看的,按步骤做即可。
|
||||
|
||||
## 场景代入
|
||||
|
||||
- 用具体人物 + 具体问题开场,把读者拉进场景。
|
||||
- 例:「你是小阿巴,刚刚为电商系统的双 11 大促开发了秒杀抢购功能。0 点秒杀开始,每秒上万个用户同时点击抢购按钮,你的数据库瞬间被打垮!」再引出「鱼皮」等角色来讲解。
|
||||
- 场景要贴近业务(秒杀、上传、部署等),痛点要具体(打垮、卡顿、报错)。
|
||||
|
||||
## 对话体 / 角色
|
||||
|
||||
- 用「你」「鱼皮」「阿巴」等对话推进:你问、导师答,一问一答拆概念。
|
||||
- 例:「你一脸懵:消息队列?那是啥?」「鱼皮:消息队列(俗称 MQ)就像一个快递驿站……」
|
||||
- 适合抽象概念入门(MQ、缓存、队列),用对话代替大段定义。
|
||||
|
||||
## 阶段划分
|
||||
|
||||
- 用「第一阶段:认识 XX」「第二阶段:快速上手」「第三阶段:实战」等把长教程切成块。
|
||||
- 每阶段内再分小节(## / ###),读者可以按阶段暂停或跳转。
|
||||
- 阶段名要体现递进:认识 → 上手 → 实战 / 入门 → 进阶 → 落地。
|
||||
|
||||
## 生活化类比
|
||||
|
||||
- 把技术概念映射到日常事物,降低理解成本。
|
||||
- 例:「消息队列就像一个快递驿站。快递员作为生产者,把包裹放到驿站;收件人作为消费者,自己到驿站去取。」再对应到「异步、解耦、削峰」。
|
||||
- 类比后补一句「这就是 XX」把术语点明,方便记笔记和复述。
|
||||
|
||||
## 图示与视频
|
||||
|
||||
- 教程中可预留「推荐观看视频讲解」「下图是 XX 流程」等位置,图示用文字简要描述(流程图、架构图),便于 Agent 生成时注明「此处可配图」。
|
||||
- 文末可加「点赞狠狠支持」「期待住了」等轻互动,自然带出 CTA。
|
||||
|
||||
## 何时用
|
||||
|
||||
- 写零基础入门、某技术「从入门到跑路」、手把手部署/配置时。
|
||||
- 需要高完成率(读者能跟着做完)而非仅概念扫盲时。
|
||||
|
||||
<!--
|
||||
Source references:
|
||||
- sources/writing-styles-juejin (消息队列从入门到跑路、ClawdBot手把手、大文件上传设计)
|
||||
-->
|
||||
+1
-1
Submodule sources/electron updated: 64872a6cb8...0cbf3c2918
+1
-1
Submodule sources/flutter updated: d143c41e41...8ba756a52b
+1
-1
Submodule sources/nuxt updated: c9fed804b9...ea8242ab9d
Submodule
+1
Submodule sources/writing-styles-juejin added at f8c92c97ce
+1
Submodule vendor/writing-humanizer added at c78047bd43
+1
Submodule vendor/writing-humanizer-zh added at 91f3d394db
Reference in New Issue
Block a user