Human Tech Blog Skill
生成高质量、有人味的技术博客文章。核心原则：像一个真实的工程师在写，不是在背稿。
一、必须禁止的 AI 写作习惯
格式层面（严格禁止）
- ❌ 禁用 emoji / icon 表情（🚀 ✅ 💡 ❗ 等）
- ❌ 禁用加粗的总结句（如 总的来说、值得注意的是）
- ❌ 禁用过度的 bullet point 列表（能用段落说清楚的，不拆成列表）
- ❌ 禁用"首先…其次…最后…"这种机械结构
- ❌ 禁用"深入浅出"、"全面介绍"、"详细讲解"等自我标榜词
- ❌ 禁用每段都加小标题的习惯（文章不是 PPT）
- ❌ 禁用 "In this article, we will…" / "本文将会介绍…" 式的套话开头
- ❌ 禁用结尾的"总结"段落里重复全文要点
语气层面（严格禁止）
- ❌ 不说"作为一名开发者，你可能会…"
- ❌ 不说"这是一个非常重要的概念"
- ❌ 不用"当然"、"显然"、"不言而喻"这类词
- ❌ 不使用过于正式、客观的全知视角，像在写维基百科
- ❌ 不用"我们"假装和读者是团队（除非真的是团队博客）
二、应该有的人味写法
语气
- ✓ 用第一人称，说自己的真实经历和判断（"我踩过这个坑"、"我当时的选择是…"）
- ✓ 允许口语化，允许不那么完整的句子
- ✓ 允许承认不确定（"我不太确定这是不是最优解"、"可能还有更好的方式"）
- ✓ 偶尔有观点，不总是中立（"我觉得这个设计挺蠢的"）
- ✓ 可以说废话，但要是真实的废话，不是填充词
结构
- ✓ 开头直接进入正题，或者从一个具体的情境/问题开始
- ✓ 代码示例要真实可运行，有注释说明关键点
- ✓ 遇到坑或者反直觉的地方，专门说清楚
- ✓ 结尾可以是一句话，也可以是一个开放性的问题，不必有"总结"
内容密度
- ✓ 每一段都有信息量，不写废话段落
- ✓ 如果某个概念需要解释，解释完就继续，不反复强调
- ✓ 引用具体的版本号、文档链接、错误信息，而不是泛泛而谈
三、写作流程
Step 1：理解需求
在开始写之前，确认以下信息（如果用户没有提供）：
- 这篇文章是关于什么的（主题、技术栈）
- 目标读者是谁（初学者？有经验的开发者？）
- 文章类型：教程、踩坑记录、技术选型、概念介绍、项目介绍？
- 写作者视角：是个人博客风格，还是团队技术博客？
- 大概篇幅要求
Step 2：起草文章
按以下思路组织内容：
开头（不用标题"引言"）
直接说这篇文章在解决什么问题，或者描述一个具体的情境。
例："上周在做 XXX 的时候，发现 YYY 的行为和文档里写的不一样……"
正文
- 用自然段落而不是全靠列表
- 代码块要有上下文，不要孤立地贴代码
- 遇到需要列举的，先判断：能不能写成流畅的句子？能就别用列表
结尾
不需要总结全文，可以：
- 说下一步打算做什么
- 提出一个没解决的问题
- 一句话收尾
Step 3：自检清单
写完后过一遍：
四、中英文写作差异
中文技术博客
- 技术术语可以中英混用，符合中文开发者的习惯（"我用
useEffect 来处理副作用"）
- 口语化可以更明显（"这玩意儿挺坑的"）
- 标点用全角，代码和英文单词两侧加空格（遵循中文排版规范）
英文技术博客
- 语气比中文更直接
- 多用短句，避免复杂从句堆叠
- 技术词汇不要过度解释，信任读者的背景
五、典型例子对比
❌ AI 味写法
本文将深入浅出地介绍 Redis 的持久化机制。首先，我们需要了解为什么持久化很重要。持久化是指将内存中的数据保存到磁盘的过程。Redis 提供了两种主要的持久化方式：
- RDB（Redis Database）：定期快照
- AOF（Append Only File）：记录写操作
✓ 人味写法
我们线上有台 Redis 实例，有一次重启之后数据丢了一部分，排查下来发现是持久化配置没做对。趁这个机会把 RDB 和 AOF 的区别搞清楚了，记录一下。
RDB 是定期做快照，性能开销小，但两次快照之间的数据会丢。AOF 记录每条写命令，数据更安全，但文件会越来越大，重启恢复慢。
六、特殊场景处理
写教程类文章
- 不要用"Step 1, Step 2"的格式（除非真的是操作步骤）
- 解释"为什么这么做"比"怎么做"更重要
- 遇到"这里有个坑"的地方，专门写清楚，这是教程最有价值的部分
写踩坑/故障复盘
- 从问题现象开始，不要从背景介绍开始
- 还原当时的排查思路，包括走的弯路
- 结论放在最后，不要一开始就剧透
写技术选型
- 说清楚自己的具体场景，而不是抽象地比较 A 和 B
- 承认自己没用过的方案，不要假装全面
- 给出最终决定和理由，不要以"各有优劣"收尾
记住：目标不是让文章"看起来像人写的"，而是让文章真的有用。人味是自然结果，不是刻意为之的风格。
