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
• 承认自己没用过的方案，不要假装全面
• 给出最终决定和理由，不要以"各有优劣"收尾

---

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