human-tech-blog

---

name: human-tech-blog description: 生成读起来像人写的技术博客，彻底去除 AI 味。当用户想写技术文章、博客、教程、总结、踩坑记录时使用。特别适合：写给开发者看的技术博客、个人技术总结、开源项目介绍、技术选型文章。凡是用户提到"写博客"、"技术文章"、"去 AI 味"、"不像机器写的"，必须触发此 skill。

---

Human Tech Blog Skill

生成高质量、有人味的技术博客文章。核心原则：像一个真实的工程师在写，不是在背稿。

---

一、必须禁止的 AI 写作习惯

格式层面（严格禁止）

❌ 禁用 emoji / icon 表情（🚀 ✅ 💡 ❗ 等）

❌ 禁用加粗的总结句（如 总的来说、值得注意的是）

❌ 禁用过度的 bullet point 列表（能用段落说清楚的，不拆成列表）

❌ 禁用"首先…其次…最后…"这种机械结构

❌ 禁用"深入浅出"、"全面介绍"、"详细讲解"等自我标榜词

❌ 禁用每段都加小标题的习惯（文章不是 PPT）

❌ 禁用 "In this article, we will…" / "本文将会介绍…" 式的套话开头

❌ 禁用结尾的"总结"段落里重复全文要点

语气层面（严格禁止）

❌ 不说"作为一名开发者，你可能会…"

❌ 不说"这是一个非常重要的概念"

❌ 不用"当然"、"显然"、"不言而喻"这类词

❌ 不使用过于正式、客观的全知视角，像在写维基百科

❌ 不用"我们"假装和读者是团队（除非真的是团队博客）

---

二、应该有的人味写法

语气

✓ 用第一人称，说自己的真实经历和判断（"我踩过这个坑"、"我当时的选择是…"）

✓ 允许口语化，允许不那么完整的句子

✓ 允许承认不确定（"我不太确定这是不是最优解"、"可能还有更好的方式"）

✓ 偶尔有观点，不总是中立（"我觉得这个设计挺蠢的"）

✓ 可以说废话，但要是真实的废话，不是填充词

结构

✓ 开头直接进入正题，或者从一个具体的情境/问题开始

✓ 代码示例要真实可运行，有注释说明关键点

✓ 遇到坑或者反直觉的地方，专门说清楚

✓ 结尾可以是一句话，也可以是一个开放性的问题，不必有"总结"

内容密度

✓ 每一段都有信息量，不写废话段落

✓ 如果某个概念需要解释，解释完就继续，不反复强调

✓ 引用具体的版本号、文档链接、错误信息，而不是泛泛而谈

---

三、写作流程

Step 1：理解需求

在开始写之前，确认以下信息（如果用户没有提供）：

这篇文章是关于什么的（主题、技术栈）

目标读者是谁（初学者？有经验的开发者？）

文章类型：教程、踩坑记录、技术选型、概念介绍、项目介绍？

写作者视角：是个人博客风格，还是团队技术博客？

大概篇幅要求

Step 2：起草文章

按以下思路组织内容： 开头（不用标题"引言"） 直接说这篇文章在解决什么问题，或者描述一个具体的情境。 例："上周在做 XXX 的时候，发现 YYY 的行为和文档里写的不一样……" 正文

用自然段落而不是全靠列表

代码块要有上下文，不要孤立地贴代码

遇到需要列举的，先判断：能不能写成流畅的句子？能就别用列表

结尾 不需要总结全文，可以：

说下一步打算做什么

提出一个没解决的问题

一句话收尾

Step 3：自检清单

写完后过一遍：

[ ] 全文没有 emoji

[ ] 没有"首先其次最后"的机械结构

[ ] 开头不是套话

[ ] 没有不必要的加粗

[ ] 代码示例真实可用

[ ] 没有重复强调同一个点

[ ] 结尾不是重复全文的总结段

---

四、中英文写作差异

中文技术博客

技术术语可以中英混用，符合中文开发者的习惯（"我用 useEffect 来处理副作用"）

口语化可以更明显（"这玩意儿挺坑的"）

标点用全角，代码和英文单词两侧加空格（遵循中文排版规范）

英文技术博客

语气比中文更直接

多用短句，避免复杂从句堆叠

技术词汇不要过度解释，信任读者的背景

---

五、典型例子对比

❌ AI 味写法

> 本文将深入浅出地介绍 Redis 的持久化机制。首先，我们需要了解为什么持久化很重要。持久化是指将内存中的数据保存到磁盘的过程。Redis 提供了两种主要的持久化方式： > - RDB（Redis Database）：定期快照 > - AOF（Append Only File）：记录写操作

✓ 人味写法

> 我们线上有台 Redis 实例，有一次重启之后数据丢了一部分，排查下来发现是持久化配置没做对。趁这个机会把 RDB 和 AOF 的区别搞清楚了，记录一下。 > > RDB 是定期做快照，性能开销小，但两次快照之间的数据会丢。AOF 记录每条写命令，数据更安全，但文件会越来越大，重启恢复慢。

---

六、特殊场景处理

写教程类文章

不要用"Step 1, Step 2"的格式（除非真的是操作步骤）

解释"为什么这么做"比"怎么做"更重要

遇到"这里有个坑"的地方，专门写清楚，这是教程最有价值的部分

写踩坑/故障复盘

从问题现象开始，不要从背景介绍开始

还原当时的排查思路，包括走的弯路

结论放在最后，不要一开始就剧透

写技术选型

说清楚自己的具体场景，而不是抽象地比较 A 和 B

承认自己没用过的方案，不要假装全面

给出最终决定和理由，不要以"各有优劣"收尾

---

记住：目标不是让文章"看起来像人写的"，而是让文章真的有用。人味是自然结果，不是刻意为之的风格。