# Kirito Writing Style

> Kirito 博客写作风格指南，用于指导技术博客文章的撰写。当需要撰写技术博客文章、公众号文章、技术分享内容时使用此 skill。适用场景：(1) 撰写新的技术博客文章 (2) 润色或改写已有文章 (3) 将技术内容转化为 Kirito 风格的博客 (4) 编写技术教程或经验分享

- Skill: `lexburner/kirito-writing-style` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lexburner/kirito-writing-style`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lexburner/kirito-writing-style/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lexburner (https://skillmd.com/u/lexburner)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lexburner/kirito-writing-style

---


# Kirito 写作风格指南

## 概述

本 skill 提供 Kirito 博客的写作风格规范，帮助撰写具有个人特色、亲切自然、技术深度与可读性兼具的技术博客文章。Kirito 的文章特点是：口语化与专业性并存、善于讲故事、注重实践经验分享、敢于表达个人观点。

## 核心风格特征

### 人称与语气

- 使用第一人称"我"讲述，建立与读者的亲近感
- 语气轻松幽默，适当使用网络流行语
- 口语化表达
- 敢于自嘲和调侃，保持真实感
- 书面语与口语自然融合，不刻意追求学术腔

### 特色词汇与表达

**常用书面表达：**
- "私以为"（表达个人观点，带谦逊语气）
- "的确"（强调认同）
- "所幸"（转折或庆幸）
- "诸如"（列举）
- "一言以蔽之"（总结）
- "姑且"（暂且、权且）
- "不妨"（建议性表达）

**括号补充说明（高频特色）：**
```
这个项目 99% 的代码都是由 AI 完成的（这完美体现了"用 AI 造工厂"的思路）。
不知道你注意到没有，实际数据 value + 用于填充的 p1~p6 总共只占据了 7 * 8 = 56 个字节（而 Cache Line 的大小应当是 64 字节）。
```

### 卖关子与设问

善于通过卖关子、设问来吸引读者继续阅读：
```
不妨先卖个关子，他们的耗时会有区别吗？
这问题问的和中小学试卷中的："它们之间有区别吗？如有，请说出区别。"一样没有水准，没区别的话文章到这儿就结束了。
```

## 文章结构

### 标准结构模板

```markdown
---
title: [标题]
date: [日期]
tags:
- [标签1]
categories:
- [分类]
toc: true
---

[引言段落：交代写作背景、个人经历或问题引入]

<!-- more -->

## 前言/闲聊（可选）

[更详细的背景介绍，可以是个人故事、心路历程或问题陈述]

## 正文章节

### 小标题1
[内容]

### 小标题2
[内容]

## 总结 / 最后

[收尾总结，个人感悟或行动建议]
```

### 引言写法

引言应交代写作动机或背景，建立与读者的连接：

**反思型引言：**
```
话说原创文章已经断更 2 个月了，倒也不是因为忙，主要还是懒。但是也感觉可以拿出来跟大家分享的技术点越来越少了...思来想去，我回忆起了写作的初心，不就是为了记录自己的学习过程吗？
```

**问题驱动型引言：**
```
前不久公众号后台有人给我留言，请教如何体系地学习 Java 知识，我当时心想：这话题太大，Java 技术栈也太深，不是一篇文章能说清楚的...
```

**事件型引言：**
```
最近瞥了一眼项目的重启脚本，发现运维一直在使用 kill -9 <pid> 的方式重启 springboot embedded tomcat，其实大家几乎一致认为：kill -9 <pid> 的方式比较暴力，但究竟会带来什么问题却很少有人能分析出个头绪。
```

**心路历程型引言：**
```
在我还是个小白的时候，学习技术：第一个想法是百度，搜别人的博客，一步步跟着别人后面配置，把 demo run 起来。而现在，遇到问题的第一思路变成了：源码 debug，官方文档。
```

### 结尾写法

结尾应有总结或展望，避免戛然而止，可以带有行动号召或祝福：

```
怎么提升代码技巧？说真的方法论归方法论，重点还是代码行数锻炼出来的代码敏感度，不多说了，滚去写代码了 [抱拳]。
```

```
最后祝大家都成为摇号潮中的锦鲤。
```

```
最后再聊聊可扩展性这个话题...哎，谁让我不会 mina，grizzy，还懒得去学呢 [摊手]。
```

## 叙述技巧

### 借用经典类比

善于引用经典著作或名言来类比技术概念：
```
王国维在《人间词话》中提到了古今之成大事业、大学问者，必经的三种境界..."昨夜西风凋碧树，独上高楼，望尽天涯路。"此第一境也...我也按照我的理解，将精进技术分成了三个境界。
```

### 用生活比喻技术

```
如果 Agent 模式是结对编程，那么 Quest 模式就是任务委派。
心跳扮演的角色应当是晴天收伞，雨天送伞。
主动追求别人的是你，主动说分手的也是你。（用于解释客户端发起心跳和断连）
```

### 澄清误区

善于指出常见误区，然后给出正确理解：
```
误区一：Dubbo 调用不是默认同步的吗？
Dubbo 在通信层是异步的，呈现给使用者同步的错觉是因为内部做了阻塞等待...

误区二：Channel.writeAndFlush 会返回一个 channelFuture，我只需要判断 channelFuture.isSuccess 就可以判断请求是否成功了。
注意，writeAndFlush 成功并不代表对端接受到了请求...
```

### 感谢与致谢

在得到他人帮助时会表达感谢：
```
感谢 @闪电侠的提醒...
这个优化点来自于和 @折袖 - 许华建 的交流，非常感谢。
私下请教过美团点评的长连接负责人：俞超（闪电侠）...
```

## 技术内容写法

### 授人以渔

不仅讲"是什么"，更要讲"为什么"和"怎么做"：
```
首先澄清几点：阅读源码绝对和工作年限无关；阅读源码绝对和工作职位无关；大多数源码并不是很难；debug + 源码分析绝对比看文章来的直观。
```

### 分享踩坑经验

坦诚分享自己的错误和教训（这是 Kirito 文章的重要特色）：
```
这里踩过一个坑，原本想使用 protoBuffer 来作为自定义协议...但后续优化时发现 DubboMeshProto 的方法存在不必要的耗时...
在队友 @闪电侠的帮助下成功定位到了内存泄露的问题。
```

### Benchmark 验证

不轻信结论，用数据说话：
```
那接下来，还是用 benchmark 来说话吧...说干就干，省略一堆测试步骤，直接给出测试结果。
从测试结果来看，似乎单连接和多连接的差距是非常大的，近乎可以看做是 2 倍！看起来连接控制的效果真是好呀，那么事实真的如此吗？
```

### 代码示例风格

代码示例应简洁，配合文字解释，适当添加注释：
```java
public void run() {
    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
    Iterator<Driver> driversIterator = loadedDrivers.iterator();
    try{
        while(driversIterator.hasNext()) {
            driversIterator.next();
        }
    } catch(Throwable t) {
    // Do nothing
    }
    return null;
}
```

### 善用表格对比

| | **传统 API 网关** | **AI 网关** |
|---|---|---|
| 请求响应模型 | 无流式处理需求 | 流式处理，SSE 协议支持 |
| 内容感知深度 | 根据 header/query/path | 支持 OpenAI 协议，多模型协同 |

### 善用引用块

引用块用于突出重要观点、他人言论或文档内容：
```markdown
> shutdown()：Initiates an orderly shutdown in which previously submitted tasks are executed...
> — JDK 文档
```

## 文章类型特点

### 技术教程类

- Architecture First 或 Code First 的选择要明确
- 层层递进，由浅入深
- 提供完整可运行的代码示例
- 章节末尾适当总结

### 比赛总结类

- 按时间线叙述优化历程
- 分享具体的 QPS/性能数据
- 坦诚分享踩坑和负优化
- 感谢帮助过自己的人

### 生活杂谈类

- 保持真实感，分享真实经历
- 可以有适度的吐槽和调侃
- 结尾可以有祝福或感慨

## 写作禁忌

1. **避免纯翻译腔** - 不要机械翻译英文文档，要有自己的理解和表达
2. **避免过度学术化** - 不要堆砌专业术语而不解释
3. **避免缺乏个人观点** - 要有"私以为"的判断，不能只是复述
4. **避免无故事性** - 技术内容也要有叙事性，避免纯罗列
5. **避免无结尾** - 文章要有明确的收尾和总结
6. **避免不敢表达** - 敢于说"我不太确定"、"个人猜想"，保持真实

## 参考资料

更多写作风格示例见 [references/examples.md](references/examples.md)