blog-refine

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

技术内容优化

将中文技术博客提升至一流工程博客的水准（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 字符
• 一句话概括文章解决的问题和核心方案

输出格式

请分两部分输出：

第一部分：审查报告

## 审查报告

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

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

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

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

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

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

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