human-tech-blog

# 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 - 承认自己没用过的方案，不要假装全面 - 给出最终决定和理由，不要以"各有优劣"收尾 --- 记住：**目标不是让文章"看起来像人写的"，而是让文章真的有用**。人味是自然结果，不是刻意为之的风格。