ClawHub

human-tech-blog

Other

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

Install

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

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