blog-writing

name: blog-writing description: My blog writing style. Use it for polish a blog article.

博客写作风格技能

概述

本技能用于按照特定的技术博客写作风格辅助创作或润色文章。

核心风格特征

一、技术深度导向

• 聚焦底层技术：分布式系统、编程语言设计、编译器原理、系统设计等
• 不满足于表面应用，喜欢探索技术本质和底层实现
• 强调理解原理胜过简单使用

二、实践驱动

• 大部分文章源于实际工作遇到的问题或个人的探索实践
• 有大量代码示例和具体的实现细节
• 记录踩坑经验和解决方案
• 性能测试数据经常出现（如协程实现的各种版本性能对比）

三、第一人称与个性化表达

• 大量使用"我"来表达个人观点和感受
• 不避讳主观评价，会明确表达喜欢或不喜欢
  • "说实话，我非常不喜欢这个feature"
  • "我认为更合适的方式"
• 展示个人思考过程，包括困惑、发现和领悟

四、口语化与亲切感

• 文风轻松自然，不像严格的学术文章
• 常用口语化表达：
  • "嗯，扫了一眼..."
  • "OK，我们可以改造一下..."
  • "就这么干了"
  • "这不就傻逼了"
• 使用感叹号和反问表达情绪

五、思维过程可视化

• 喜欢展示"如何思考"而非仅仅"是什么"
• 经常使用"首先"、"然后"、"再考虑"这样的步骤引导
• 记录从困惑到理解的完整过程

六、对比与评价

• 经常对比不同方案、工具、方法的优缺点
• 给出明确的选择倾向，并说明理由
• 例如：对比 Emacs vs Acme，有栈协程 vs 无栈协程

内容组织结构

典型结构

问题引入 → 背景说明 → 核心概念讲解 → 实现细节 → 总结/展望

层次分明

• 善用多级标题组织内容
• 代码块、公式、列表交替使用，避免单调

循序渐进

• 从简单到复杂，逐步深入
• 用例子引入抽象概念
• 经常"举个例子"来说明

语言使用规范

技术术语

• 保留英文原词（coroutine, macro, lambda, vector clock 等）
• 但会给出中文解释或类比
• "理解逻辑时钟的关键，就是理解时间的先后是用事件之间的happened-before关系来表示的。不要让物理时钟的概念影响思维。嗯，就像光年不是时间单位。"

比喻和类比

• 善用类比来解释复杂概念
• 例如：把 trampoline 的实现称为"蹦床"

简洁有力

• 不啰嗦，直接切入主题
• 每段话信息密度高

常见元素

代码示例

• 几乎每篇文章都有大量代码
• 代码有版本对比（v0.c, v1.c, v2.c...）
• 包含实际可运行的代码

图表辅助

• ASCII 表格展示数据对比
• 列表展示要点

外部链接

• 大量引用相关文章、论文、官方文档
• 链接到个人 GitHub 项目

性能数据

• 经常给出具体的测试时间、对比数据
• 用数据支撑观点

情感色彩

热情

• 对技术有强烈的热情
• "这正是我写这篇文章的用意：布道"
• "要让自己的感受告诉周围的人，让至少100个迷失的灵魂得到救赎"

幽默与自嘲

• "我没有黑某个号称可以煮咖啡的工具"
• "装个逼"
• "脑洞"

坦诚

• 不掩饰自己的无知或困惑
• "好晚，不知道自己在想啥了"
• "其实这个算法是借鉴类型推导里面...（好吧，我根本不知道常量传播标准做法应该是怎么做的）"

文章类型

常见的文章类型包括：

1. 技术原理解析（逻辑时钟、HLC、acme、常量传播等）
2. 实现方案分享（C协程、尾递归优化、显式重命名宏等）
3. 踩坑记录（编译planeshift、Go内存分配等）
4. 面试题思考（字符串长度、面试题等）
5. 框架/工具使用（skynet、libgdx等）
6. 刷题总结（leetcode经验）

写作技巧

推荐做法

• 从实际问题出发引入主题
• 用大量代码示例说明
• 给出具体的实现方案和性能数据
• 表达个人观点和思考过程
• 使用口语化表达增加亲切感
• 提供外部链接供深度阅读
• 多用例子和类比
• 记录学习过程中的困惑和领悟

注意事项

• 需要有足够的技术深度
• 代码必须是实际可运行的
• 观点要有依据，最好有数据支撑
• 不回避自己的不足和困惑
• 保持真实和真诚

典型段落示例

引入问题的风格

遇到这个问题是这样的，select * from t where a < 5 and a > 5 我期望它能直接推导出来，这是一个空集，因为 a < 5 and a > 5 恒为假。结果呢？它给我搞出来了一个全表扫！这不就傻逼了。嗯，扫了一眼我们的代码，开始没看太懂。于是决定自己想想怎么做。

循序渐进讲解的风格

首先我们想下 iterator 的概念。一个 iterator 是可以调用多次的，它不是调用一次就返回了，而是可以 next 多次直到最终结果的完成。我们可以搞一个状态机，记录里面的状态，每次 next 之后更新状态，直到结束。

表达个人观点的风格

老实说，我非常不喜欢这个feature。Go自做主张弄一些背后我无法确定的事情。顺带一提吧，另一个Go中我不喜欢的feature是init函数。

对比评价的风格

无栈协程可以在编译器做些支持，提供 await yield 之类的关键字，其实本质上就是回调写法用 monad 的形式让代码不那么回调地狱。无栈协程使用起来不太舒适，即使语法糖各种已经弄得很方便的情况。有个无解的痛点是，只要是无栈协程实现，都克服不了函数染色的问题。

核心原则：真实、深度、实用、亲切