# Blog Refine

> Only invoke when explicitly requested via "润色博客"、"技术博客优化"、"@blog-refine" or "polish blog". Do NOT auto-trigger.

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

---


# 技术内容优化

将中文技术博客提升至一流工程博客的水准（Netflix Tech Blog、Uber Engineering、Stripe Engineering、美团技术团队）。

## 处理流程

当用户提供博客草稿或技术内容时，严格执行以下步骤：

### 0. 前置评估与访谈（必须首先执行）

收到用户内容后，先评估是否具备足够信息构建循序渐进的文章结构。

**触发访谈的条件（按优先级）**：

1. **信息缺失**：原文缺少背景、问题场景，无法自行补充
2. **跨度过大**：原文同时涉及 3 个以上独立技术领域，难以整合
3. **内容碎片化**：原文是笔记/要点形式，缺乏连贯叙事

**若触发任一条件**：

- 暂停优化流程，先向用户提问收集必要信息
- 每轮提问 2-3 个问题，聚焦于补全缺失的背景、场景、目标读者等
- 收集到足够信息后再继续后续步骤

**若不触发**：直接进入步骤 1。

---

### 1. 逻辑与代码审查

*   技术事实准确性：检查技术概念、原理和机制的描述是否正确（如 GC 算法、网络协议、架构模式等），标注明显错误
*   逻辑完整性：识别循环论证、逻辑谬误、因果关系错误或薄弱论点
*   代码正确性：验证代码片段是否符合该语言的惯用写法和最佳实践；标注未明确说明的伪代码
*   输出：在"审查报告"部分明确列出问题。若无问题，注明"逻辑与代码审查通过"

### 2. 去冗余与精炼

#### 2.1 段落级冗余检测

*   同义重复：若两个段落表达相同观点，合并为一个段落，但必须保留所有独特的论据、数据和例子
*   首尾重复：开头和结尾不应复述相同内容；结尾应聚焦"下一步思考"或"延伸阅读"
*   过渡冗余：删除"如前所述""正如上文提到的"等口头引用，用逻辑顺序替代

#### 2.2 句子级精简

*   弱动词："进行了优化" → "优化了"；"实现了部署" → "部署了"
*   冗余修饰："非常非常重要" → "关键"；"完全彻底地" → "彻底"
*   无信息量的句子：直接删除无实质内容的过渡句

### 3. 模糊表达处理

*   有数据支撑：保留并确保数据准确
*   无数据支撑：
    *   不得虚构数据
    *   将"性能提升了很多"改为"性能有所提升"
    *   或添加注释标记：`<!-- TODO: 补充具体数据 -->`
*   模糊量词："大量""海量""显著" → 若无法量化，改为更谨慎的表述

### 4. 去"AI味"与语气专业化

#### 4.1 禁用词汇（中英文）

| 禁用 | 替换建议 |
|------|----------|
| 深入探讨、让我们来看看 | 直接切入主题 |
| 本文将介绍 | 删除或改为直述 |
| 众所周知 | 删除 |
| Delve、Dive into | 删除 |
| Leverage、Harness | use、apply |
| Game-changer、Revolutionary | 删除（除非有事实支撑） |
| 总而言之、综上所述 | 删除或精简 |

#### 4.2 语气要求

*   采用权威、直接、资深工程师的语气
*   ❌ "在这篇文章中，我们将探索如何..."
*   ✅ "本文演示如何..." 或直接从概念切入

### 5. 中文技术写作规范

| 问题 | 检测 | 修复 |
|------|------|------|
| 翻译腔 | "这是一个非常好的实践" | "这种做法效果好" |
| 长句 | 单句超过 40 字（中文字符逐字计数，英文单词和数字各算 1 字） | **必须**拆分为多个短句，每句 ≤ 40 字。这是硬性要求，无例外。特别注意：枚举多个概念时容易写出长句，必须拆成多句。❌ "白色表示未访问，灰色表示已发现但引用未扫描完，黑色表示已扫描完。"（超 40 字）→ ✅ 拆为三句，每句介绍一种颜色。 |
| 指代不清 | "它""这个"指代模糊 | 明确写出主语 |
| 被动语态滥用 | "该方案被我们采用" | "我们采用了该方案" |
| 中英混排 | 中英文之间无空格 | 添加空格（如：使用 Go 语言） |

### 6. 结构优化

#### 6.1 循序渐进原则

*   **章节内部节奏**：每个主要章节遵循"背景/问题 → 原理 → 方案 → 实践"的渐进结构（可省略不适用的部分，但顺序不变）
*   **章节间过渡**：每个 ## 级别章节（除最后一个章节外）都必须在末尾有 1-2 句过渡句，引向下一章节的主题。无一例外——包括倒数第二个章节到"延伸思考/下一步"之间也必须有过渡。
    *   ✅ "理解了原理后，接下来看生产环境中最容易踩的坑：参数配置。"
    *   ✅ "方案设计完成，但如何验证它真的有效？"
    *   ✅ "优化完成后，回顾一下整体思路和可继续探索的方向。"（倒数第二章到结尾章节的过渡）
    *   ❌ 无过渡直接跳到下一章节
    *   ❌ 最后一个内容章节结束后直接跳到"延伸/下一步"
    *   ❌ 章节以代码块、TODO 注释或列表收尾而无过渡句（过渡句必须是正文文字，不能是注释或代码）
*   **禁止**：不得在没有铺垫的情况下直接抛出复杂概念

#### 6.2 金字塔原则

*   最重要的信息优先呈现

#### 6.3 标题层级

*   强制使用编号层级结构
    *   一级标题：`# 1. 主标题`、`# 2. 主标题`
    *   二级标题：`## 1.1 子标题`、`## 1.2 子标题`
    *   三级标题：`### 1.1.1 细分标题`（如需要）
*   确保层级严格嵌套，不跳级

### 7. 加粗使用规范

**核心原则：非必要不加粗**

| 类型 | 规则 |
|------|------|
| **禁止加粗** | 技术名词、概念、术语（如 GC、Docker、微服务） |
| **禁止加粗** | Markdown 标题内的文字（标题本身已突出） |
| **禁止加粗** | 普通关键词或重点词汇 |
| **允许加粗** | ⚠️ 风险警告（如：数据丢失、服务中断） |
| **允许加粗** | ⚠️ 易错陷阱/常见误区 |
| **允许加粗** | ⚠️ 关键决策点（如：不可逆操作、重大权衡） |

**数量限制**：全文加粗内容应 ≤ 5 处

### 8. SEO 与元数据优化

#### 8.1 标题生成原则

*   长度限制：中文标题 ≤ 15 字，英文标题 ≤ 8 个单词
*   核心提炼：标题应提炼文章的核心技术点或解决方案，而非罗列内容
*   避免模式：
    *   ❌ 冗长描述型："从零开始深入理解 Go 语言垃圾回收机制的原理与调优实战"
    *   ❌ 罗列型："XXX 的原理、实践与优化指南"
    *   ✅ 核心概念型："Go GC 调优实践"
    *   ✅ 问题导向型："解决高延迟的 GC 策略"
*   格式要求：
    *   优先使用名词短语或动宾结构
    *   关键技术词前置
    *   避免"深入""详解""全面"等无信息量词汇

#### 8.2 Meta Description

*   长度 < 160 字符
*   一句话概括文章解决的问题和核心方案

## 输出格式

请分两部分输出：

**第一部分：审查报告**

```markdown
## 审查报告

### 技术事实与逻辑
[技术错误、逻辑谬误列表，或"审查通过"]

### 代码审查
[代码问题列表，或"审查通过"]

### 冗余问题
[发现的段落/句子级冗余，及处理方式]

### 结构问题
[标题层级、叙事流程问题，及修正方案]

### SEO 建议
- 标题: [建议标题]
- Meta: [建议描述]
```

**第二部分：优化后的完整内容**

直接输出优化后的完整 Markdown 文档，无需额外说明。