---
name: viral-tech-writing
description: 用于撰写中文科技爆款文章、公众号长文、技术复盘稿和高打开率标题。适合需要同时做到抓流量、显得专业、信息密度高、观点鲜明的写作任务，尤其适用于 AI、大模型、产品发布、技术事故复盘、工程突破和行业分析。
---

# 爆款技术文章写作

这个 skill 用来把“有料但不好看”的技术内容，写成“愿意点开、能读下去、还显得专业”的中文长文。

目标不是写自嗨技术文，也不是写空洞情绪文，而是做两件事同时成立：

1. 标题先把人拉进来
2. 正文用事实、数字、机制解释把可信度撑住

## 适用场景

- AI / 大模型 / Agent / 推理框架 / 本地部署相关文章
- 产品发布稿、能力突破稿、版本升级稿
- 技术事故复盘、Bug 修复复盘、性能优化复盘
- 行业判断、趋势分析、架构解读
- 需要“像科技媒体，但比媒体更懂工程”的中文文章

## 核心写法

### 1. 标题要混合两种力量

标题默认采用“情绪钩子 + 专业信息”的混合结构。

不要只写：

- `我们修复了一个内存问题`

优先写：

- `Mac上跑大模型：一次模型切换引发的90GB内存雪崩，我是怎么把它堵住的`
- `128K 上下文跑通之后，oMLX 最危险的内存缺口终于暴露了`

标题公式优先顺序：

1. `大事件/冲突 + 主体 + 后果`
2. `新能力/新突破 + 关键数字 + 行业意义`
3. `事故/问题 + 根因 + 修复结果`

标题中尽量至少包含以下元素里的 2-3 个：

- 主体：产品名、模型名、框架名、公司名
- 冲突：崩了、失控、卡死、雪崩、暴涨、翻车、硬上限被打破
- 数字：90GB、128K、37.8x、50轮
- 结果：修到根上、跑通、堵住、闭环、稳定

### 2. 开头先给结论，不要先讲背景

前 3 段必须回答下面至少两个问题：

- 这件事为什么值得看？
- 到底出了什么事？
- 结果有多夸张？

不允许一上来先铺论文史、框架史、行业史。

错误示例：

- `近年来，随着大模型的发展……`

正确方向：

- `如果你还觉得本地大模型推理只是模型权重大一点，这次事故可能会改变这个认知。`
- `我们把上下文从 32K 推到 128K 后，真正先炸掉的不是模型，而是模型切换后的运行时内存。`

### 3. 正文结构按“事故复盘链”写

技术复盘优先用这套结构：

1. 背景链
2. 事故现场
3. 根因拆解
4. 修复架构
5. 验证结果
6. 升维总结

每一段只回答一个问题：

- 背景链：为什么会做到这里
- 事故现场：具体发生了什么
- 根因拆解：为什么会这样
- 修复架构：你到底改了什么
- 验证结果：怎么证明不是碰巧
- 升维总结：这对别人意味着什么

### 4. 正文必须区分三种内容

写作时必须把下面三类内容分开，不要混写：

- `事实`：日志、指标、版本、代码路径、配置、测试结果
- `推断`：根据源码或行为推出的机制解释
- `判断`：这件事对平台、行业、用户意味着什么

如果是推断，不要写成绝对事实。

例如：

- 少写：`KV cache 轻松吃掉 60GB`
- 多写：`在我们的实测链路里，128K 时 KV/cache 相关运行时内存进入几十 GB 量级并不意外`

### 5. 用数字撑专业感

每篇文章至少要有 3 类数字：

- 能力数字：32K、128K、37.8x、4.5 秒
- 资源数字：14.8GB、58GB、33.1GB、104GB
- 验证数字：50轮、43轮、0 重启、0.0GB 累积

如果一篇技术长文几乎没有数字，专业感会明显下降。

### 6. 用“机制解释”而不是“现象描述”

不要只写：

- `内存没降下来`

要写成：

- `系统把 unload 成功误判成 reclaim 成功，因为账面 estimated_size 下降了，但真实 active memory 没降。`

核心要求：

- 现象后面必须跟根因
- 根因后面必须跟代码路径或系统机制
- 修复后面必须跟验证方法

## 语言风格

### 应该有的气质

- 句子短，判断硬
- 开头敢下结论
- 中段大量用事实和数字压实
- 结尾能升到平台或行业层面

### 不该有的问题

- 不要通篇“震惊体”
- 不要满篇感叹号
- 不要只学自媒体口气，不给工程证据
- 不要为了热闹牺牲严谨
- 不要混淆事故链、验证链、产品化链

## 默认工作流

当用户让你“写一篇抓流量但显得专业的文章”时，按这个顺序输出：

1. 先提炼事实链
2. 再给 3-5 个标题版本
3. 选一个最稳的标题
4. 搭正文结构
5. 写首稿
6. 最后再做一轮“去虚词、补数字、压结论、提专业感”

## 标题生成规则

默认同时给三类标题：

### A 类：最像科技爆款

- 冲突更强
- 适合公众号打开率

### B 类：最像专业媒体

- 信息密度更高
- 适合显得稳

### C 类：折中版

- 既能抓流量，又不显得太浮

如果用户没指定，优先推荐 C 类。

## 技术事故复盘的固定模板

```markdown
# [标题]

如果你最近还觉得[旧认知]，这次[事故/突破]可能会改变这个认知。

先说背景。
[背景链：为什么会推到这个场景]

但真正的问题，不在[表面现象]，而在[真正根因]。

## 事故现场
[时间、模型/产品链路、关键异常、关键数字]

## 根因拆解
[源码路径、资源生命周期、误判点]

## 修复架构
[不是修一行，而是修一套机制]

## 验证结果
[高风险链路验证 + soak test / benchmark / regression]

## Lessons Learned
[3 条以内，必须硬]

## 行业意义
[升维一句话：这件事对谁意味着什么]
```

## 最后的检查清单

交稿前必须自查：

- [ ] 标题里有没有主体、冲突、数字、结果中的至少两项
- [ ] 开头 3 段内有没有把人拉进来
- [ ] 事故链、验证链、产品化链有没有分清
- [ ] 事实、推断、判断有没有分清
- [ ] 文中有没有足够多的真实数字
- [ ] 是否至少解释了一层系统机制，而不只是描述现象
- [ ] 结尾有没有升到平台、产品或行业层面

## 默认产出要求

除非用户要求极短版，否则默认输出：

1. 3 个标题候选
2. 1 个推荐标题
3. 文章正文
4. 如有必要，再补一句“适合发公众号/朋友圈转发”的导语
