القائمة
Kirito 博客写作风格指南，用于指导技术博客文章的撰写。当需要撰写技术博客文章、公众号文章、技术分享内容时使用此 skill。适用场景：(1) 撰写新的技术博客文章 (2) 润色或改写已有文章 (3) 将技术内容转化为 Kirito 风格的博客 (4) 编写技术教程或经验分享
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | kirito-writing-style |
| description | Kirito 博客写作风格指南，用于指导技术博客文章的撰写。当需要撰写技术博客文章、公众号文章、技术分享内容时使用此 skill。适用场景：(1) 撰写新的技术博客文章 (2) 润色或改写已有文章 (3) 将技术内容转化为 Kirito 风格的博客 (4) 编写技术教程或经验分享 |
本 skill 提供 Kirito 博客的写作风格规范，帮助撰写具有个人特色、亲切自然、技术深度与可读性兼具的技术博客文章。Kirito 的文章特点是：口语化与专业性并存、善于讲故事、注重实践经验分享、敢于表达个人观点。
常用书面表达：
括号补充说明（高频特色）：
这个项目 99% 的代码都是由 AI 完成的（这完美体现了"用 AI 造工厂"的思路）。
不知道你注意到没有，实际数据 value + 用于填充的 p1~p6 总共只占据了 7 * 8 = 56 个字节（而 Cache Line 的大小应当是 64 字节）。
善于通过卖关子、设问来吸引读者继续阅读：
不妨先卖个关子，他们的耗时会有区别吗？
这问题问的和中小学试卷中的："它们之间有区别吗？如有，请说出区别。"一样没有水准，没区别的话文章到这儿就结束了。
---
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 来说话吧...说干就干，省略一堆测试步骤，直接给出测试结果。
从测试结果来看，似乎单连接和多连接的差距是非常大的，近乎可以看做是 2 倍！看起来连接控制的效果真是好呀，那么事实真的如此吗？
代码示例应简洁，配合文字解释，适当添加注释：
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 协议，多模型协同 |
引用块用于突出重要观点、他人言论或文档内容：
> shutdown()：Initiates an orderly shutdown in which previously submitted tasks are executed...
> — JDK 文档
更多写作风格示例见 references/examples.md
[project] 生成舰队Collection岛风风格的信息图。当用户需要创建可视化信息图、流程图，或需要以岛风形象进行图表生成时使用此技能。
[project] 根据参考文稿批量生成 Notion 风格松弛感手绘信息图组图。当用户需要阅读文档并生成一组社交媒体传播用的信息图时使用此 skill。适用于将文章、笔记转化为视觉化内容系列。
[project] 根据文字稿生成 Qoder 品牌风格的 HTML 演示文稿。支持浏览器直接演示（键盘翻页、自动缩放）。