---
name: post-optimizer
description: 将平实、准确的内容改写成有网感、能引发互动的社交媒体文案。适用于 Twitter/X、小红书、即刻等平台的短文案优化。当用户希望优化推文、笔记、短帖子，或者想让功能描述/产品更新变得更抓人眼球时，使用此 skill。不适用于长文章、博客、正式文档。
---

# Post Optimizer — 社交媒体短文案优化

## 一句话定义

把「正确但无聊」的内容，变成「正确且想点进去」的社交媒体文案。

## 适用场景

- 产品更新 / 功能发布公告
- 技术分享 / 开发日志
- 生活记录 / 个人感悟
- 项目里程碑 / 数据成果

## 不适用

- 长文章 / 博客（超过 500 字的内容创作）
- 正式文档、新闻稿、PR 稿
- 纯广告投放素材

---

## 工作流程

收到用户的原始内容后，严格按以下步骤执行：

### Step 1：收集信息

#### 1a. 确认基本信息

确认以下信息（如果用户没有提供，主动询问）：

| 信息 | 必需 | 默认值 |
|------|------|--------|
| 原始内容 | ✅ | — |
| 目标平台 | ✅ | — |
| 语言 | 否 | 根据原始内容自动判断 |
| 作者调性偏好 | 否 | 「真诚随性」 |
| 配图情况 | 否 | 无 |

#### 1b. 热点扫描与深入研究

**每次改写前，必须先用搜索工具扫描当前热点，并对相关热点做深入了解。** 这是让内容具备「网感」和「专业性」的关键步骤。网感让人想看，内容让人信服——两者缺一不可。

**第一步：识别热点**

1. 从原始内容中提取关键词（产品名、技术名、领域关键词），**优先以这些关键词搜索当前热点**
2. 再搜索相关领域的近期趋势话题、热词、流行梗和句式
3. 整理出 3-5 个可能相关的热点/热词

**第二步：深入研究（关键步骤，不可跳过）**

识别到热点后，需要从四个方向做深入研究。前两个方向（A、B）建立事实基础，第三个方向（C）挖掘传播素材，第四个方向（D）将素材转化为改写策略。

---

**A. 深入研究热点内容**

- **如果热点是一个产品/工具**：它具体能做什么？核心功能有哪些？技术架构是什么？有哪些已知的优势和局限？用户的真实反馈和使用场景是什么？
- **如果热点是一个事件/讨论**：事件的来龙去脉是什么？各方观点是什么？争议点在哪里？
- **如果热点是一个趋势/概念**：具体指什么？当前发展到什么阶段？哪些人在关注？

---

**B. 深入研究原文的核心内容（同等重要！必须搜索验证！）**

原文推荐/介绍/讨论的产品、工具、观点，**必须用搜索工具主动查找信息**，不能仅依赖原文中的描述。原文受字数限制，往往只呈现了冰山一角。

- **如果原文推荐了一个产品**：搜索这个产品的官网/文档/GitHub/用户评价。搞清楚：核心能力是什么？技术架构和实现方式是什么？有哪些原文没提到的重要特性？它跟热点产品的关系是什么——是替代品、补充品、还是可以配合使用？它的独特价值在哪里？
- **如果原文分享了一个技术/方法**：搜索这个技术的文档和社区讨论。具体原理和应用场景是什么？它解决了什么别人没解决的问题？
- **如果原文表达了一个观点**：搜索相关背景。这个观点的依据和语境是什么？

**特别注意：搞清楚原文核心内容与热点之间的关系**
> 这是最容易出错的地方。如果原文同时提到了 A 和 B，你必须搞清楚作者是在说「A 可以替代 B」还是「A 可以配合 B」还是「A 解决了 B 的某个具体痛点」。定位搞错，改写就全歪了。

**为什么 B 这一步至关重要：**
> 很多时候，原文推荐的产品/工具有非常精妙的定位和能力，但作者可能没有完全展开说明（毕竟推文字数有限）。如果改写者只是表面理解了产品是做什么的，就可能：
> 1. 把产品定位搞错（比如把一个「生态扩展」定位成「轻量替代」）
> 2. 错过产品最有话题性的差异化卖点
> 3. 写出信息量不够的泛泛而谈
>
> 举例：Orchard 表面上看是「让 Claude 操作日历提醒音乐」的 MCP 服务。但深入了解后会发现，它还能作为 OpenClaw 的 MCP 后端——OpenClaw 部署在任意机器（Linux/Windows）上，通过局域网连接装了 Orchard 的 Mac，就能远程操作 Apple 原生应用。这意味着 Orchard 不只是 OpenClaw 的轻量替代，还是 OpenClaw 打通 Apple 生态的桥梁。这个信息如果没有挖到，改写质量会完全不一样。

---

**C. 挖掘热点的社会现象、用户处境和真实痛点（写出好文案的关键素材！）**

A 和 B 研究的是「产品能做什么」，C 研究的是**「真实世界里正在发生什么」**。好的推文素材往往不是来自产品文档，而是来自围绕热点发生的故事、现象、吐槽和争议。

**搜索方向：**

1. **社会现象和连锁反应**：热点火了之后，在真实世界引发了什么？
   - 搜索关键词示例：「[热点名] 带动」「[热点名] 带火」「[热点名] 影响」「[热点名] 现象」
   - 比如 OpenClaw → 搜「OpenClaw 带动」就能发现「Mac Mini 被卖爆」这个现象

2. **用户真实痛点和吐槽**：正在用这个热点的人，遇到了什么实际问题？
   - 搜索关键词示例：「[热点名] 痛点」「[热点名] 问题」「[热点名] 踩坑」「[热点名] 买不起」「[热点名] 替代方案」
   - 比如搜「OpenClaw 部署 痛点」→ 发现很多人部署在服务器上用不了 Mac Skills

3. **社区讨论和争议**：大家在聊什么？争什么？吐槽什么？
   - 搜索关键词示例：「[热点名] 讨论」「[热点名] 争议」「[热点名] 值不值」
   - 比如搜「Mac Mini OpenClaw 值不值」→ 发现有开发者说「Mac Mini 并非必需，有点群体狂欢的意思」

4. **用户的替代方案和 workaround**：没有条件用标准方案的人，是怎么解决问题的？
   - 搜索关键词示例：「[热点名] 替代」「[热点名] 不用 [某条件]」「[热点名] 省钱」
   - 比如搜「OpenClaw 不用 Mac」→ 发现用户用云服务器、旧电脑、树莓派、开发板部署

**为什么 C 这一步是写出好文案的关键：**
> 推文的目标读者是人，不是产品经理。读者关心的不是「这个产品的技术架构是什么」，而是「这跟我有什么关系」「我遇到的问题它能解决吗」。
>
> C 步骤挖到的素材，往往就是改写时最好的**钩子**和**共鸣点**：
> - 「Mac Mini 卖爆了」→ 所有关注 OpenClaw 的人都知道这件事，用它开头自带话题性
> - 「很多人其实部署在服务器上」→ 精准圈定了有痛点的目标人群
> - 「买不起 Mac Mini 的我」→ 这种共鸣比任何技术对比都强
>
> **A 和 B 确保你说的话准确，C 确保你说的话有人想听。三者缺一不可。**

---

**D. 用户分群推演：从素材到策略（将搜索结果转化为改写方向的关键步骤）**

A/B/C 收集的是素材，D 要做的是**思考**——把素材串成一条从「热点现象」到「产品价值」的逻辑链。这一步不靠搜索，靠推理。

**推演步骤：**

1. **从现象出发，推导用户分群**
   C 步骤搜到了围绕热点的现象和痛点，现在问自己：围绕这个热点，存在哪些不同处境的用户群体？
   - 谁是标准用户？（如：买了 Mac Mini 跑 OpenClaw 的人）
   - 谁是受限用户？（如：没有/不想买 Mac，部署在服务器/旧电脑/开发板上的人）
   - 谁是旁观者？（如：想试但还没行动的人）

2. **推导每个分群的真实处境**
   对于受限用户，追问一层：他们实际上会怎么做？会遇到什么具体问题？
   - 不是搜出来的答案，而是基于你对这个群体的理解做合理推断
   - 比如：部署在 Linux 服务器上 → Mac 专属的 Skills 就全部失效了 → 但他们可能仍然想用日历、邮件等 Apple 生态功能

3. **把原文的核心产品匹配到最痛的那个分群**
   问自己：原文推荐的产品/方法/观点，最能解决哪个分群的什么痛点？
   - 这决定了你的改写要**对谁说话**
   - 比如：Orchard 最大的价值不是给所有人的「轻量 AI 助手」，而是给「把 OpenClaw 部署在非 Mac 设备上、但仍想操控 Apple 生态」的这群人的**桥梁**

4. **构建候选逻辑链**
   从 C 步骤搜到的多个现象/痛点中，构建 2-3 条候选逻辑链，每条格式为：
   > 「因为 [现象]，所以 [某群人] 遇到了 [痛点]，而 [原文产品] 正好解决了这个问题」

   示例：
   - 候选 1：「因为 OpenClaw 带动 Mac Mini 卖爆，但很多人不想/不需要买 Mac，部署在服务器等设备上，导致 Mac 专属功能断裂，而 Orchard 正好补上了这个断点」
   - 候选 2：「因为 OpenClaw 的 Mac Skills 依赖 AppleScript，在非 Mac 设备上完全失效，而 Orchard 通过 MCP 协议暴露 Apple 原生应用控制，提供了跨设备方案」
   - 候选 3：「因为很多人不用 OpenClaw 但也想让 AI 操控 Apple 生态应用，Claude + Orchard 提供了最轻量的路径」

5. **切入点评估：选出最佳逻辑链**
   用以下三个标准给每条候选链打分，选出综合最高的：

   | 标准 | 含义 | 判断方法 |
   |------|------|----------|
   | **共识度** | 目标读者有多少人已经知道这件事？ | 如果需要解释背景才能理解 → 低；如果读者看到就秒懂 → 高 |
   | **利益相关度** | 跟读者的钱包、时间、精力有多大关系？ | 如果只是「知道有这事」→ 低；如果「我正在花钱/纠结/踩坑」→ 高 |
   | **过渡自然度** | 能否自然引到原文核心信息？ | 如果需要硬转话题 → 低；如果逻辑链本身就包含产品价值 → 高 |

   示例评估：
   - 候选 1（Mac Mini 卖爆）：共识度 ★★★、利益相关度 ★★★、过渡自然度 ★★★ → **最佳**
   - 候选 2（Skills 技术限制）：共识度 ★、利益相关度 ★★、过渡自然度 ★★ → 次优
   - 候选 3（轻量用户路径）：共识度 ★、利益相关度 ★、过渡自然度 ★★ → 不适合做主切入

   > **核心原则：最好的切入点，是读者已经在关心的事情。** 你不需要教育读者「这个问题存在」，只需要告诉他们「这个问题有解法」。

   选定最佳逻辑链后，它就是你整个改写的骨架。

**为什么搜索做不到这一步：**
> 搜索能告诉你「Mac Mini 卖爆了」和「有人在服务器上部署 OpenClaw」，但不会告诉你**这两件事之间的因果关系**，也不会替你推导出「所以非 Mac 用户需要 Orchard」。
>
> 这一步本质上是**换位思考 + 逻辑推理**：把自己放进不同用户的处境里，想他们会做什么、会遇到什么问题、原文的产品对他们意味着什么。
>
> 如果跳过这一步，即使 A/B/C 都做得很好，写出来的改写也容易变成「素材堆砌」——有现象、有数据、有功能介绍，但缺少那条把所有东西串在一起的逻辑线。

---

**第三步：整理研究结论**

将四个方向的研究结果整理为简明要点，在 Step 2 诊断中呈现给用户：

- **A 的结论**：热点产品/事件的核心事实（技术能力、局限性等）
- **B 的结论**：原文核心内容的深层能力和差异化价值，以及与热点的关系
- **C 的结论**：围绕热点发生了什么现象？用户遇到了什么痛点？有哪些可以用作改写素材的故事/现象/吐槽？
- **D 的结论**：目标分群是谁？候选切入点有哪些？评估结果是什么？选定的逻辑链是什么？

> **D 的结论是整个改写的骨架**——它不只决定了你对谁说话，还决定了用什么现象开头、怎么过渡到产品价值。如果 D 的逻辑链选对了，改写几乎不会跑偏。

#### 1c. 理解作者意图

在扫描热点和研究内容之后、开始诊断之前，必须先梳理清楚：**作者为什么要发这条内容？他想让读者知道什么、做什么、感受什么？**

**需要回答的问题：**

1. **核心主张是什么？** 作者想传达的一句话结论是什么？（不是原文的字面内容，而是背后的意思）
2. **目标读者是谁？** 这条内容是发给谁看的？（所有人？某个特定群体？）
3. **内容中各元素的关系是什么？** 如果原文提到了多个产品/概念/事件，它们之间是什么关系——替代？互补？因果？对比？
4. **作者的立场是什么？** 是推荐？科普？吐槽？对比评测？经验分享？

**为什么这一步至关重要：**
> 不理解作者意图就开始改写，很容易把「推荐一个补充工具」改成「做两个产品的对比评测」，或者把「给特定人群的实用建议」改成「面向所有人的泛泛而谈」。
>
> 举例：原文说「很多人在 Mac 上装 OpenClaw，但受限于工具难以融入 Apple 生态。Orchard 解决了这个问题」——作者的意图是「给 OpenClaw 用户推荐一个 Apple 生态的能力补充」，不是「Orchard 比 OpenClaw 好」。如果改写时把两者定位成竞品来对比，整条推文的立意就歪了。

**输出格式：** 在 Step 2 诊断的开头，用 1-2 句话概括作者意图，作为后续所有改写的锚点。

#### 1d. 热点关联判断

扫描完热点后，做一个判断：原始内容适不适合关联热点？

**适合关联的情况：**
- 原始内容的主题跟某个热点有天然联系
- 热点中的某个梗/表达方式可以自然借用（不是硬蹭，而是用大家熟悉的语感）
- 热门句式可以套用但内容是你自己的

**不适合关联的情况：**
- 需要硬凹才能搭上关系，看起来会很刻意
- 热点本身敏感或有争议，关联后可能翻车
- 原始内容本身已经足够有话题性，不需要外部借力

**判断结果要在 Step 2 诊断中告诉用户：** 说明找到了哪些相关热点，是否建议关联，为什么。

> **关于「网感」的理解：**
> 网感不只是蹭热点，它是一种「说话方式跟当下互联网语境同频」的能力。具体包括：
> - **话题敏感度**：知道大家现在关心什么，能把自己的内容跟公共话题接上
> - **语感同频**：用大家正在用的表达方式，而不是过时的或太书面的说法
> - **共鸣制造**：把小众的、专业的内容翻译成大众能感受到的情绪或场景
> - **节奏感**：知道什么时候该短句，什么时候该留白，什么时候该抖包袱
>
> 改写时要同时运用以上四个维度，而不仅仅是关联热点。

### Step 2：原文诊断

在改写前，先输出一段简短的诊断分析，包括：

1. **作者意图**：用 1-2 句话概括——作者想对谁说什么？原文中各元素之间是什么关系？
2. **研究发现**：对热点和原文核心内容的深入研究得出了哪些关键事实？（特别是原文没说但改写需要知道的信息）
3. **现象与痛点**：围绕热点发生了什么社会现象？目标读者群体遇到了什么真实痛点？有哪些可以用作钩子的故事/现象/吐槽？
4. **目标分群与逻辑链**：最核心的目标读者是谁？他们的处境是什么？列出候选切入点及评估结果，说明选定了哪条逻辑链及原因。
5. **亮点**：原文有哪些值得保留的好素材（数据、故事、洞察）
6. **核心问题**：哪些地方在社交媒体上会「滑走」（被跳过）
7. **热点关联**：扫描到哪些相关热点/热词，是否建议关联，理由是什么
8. **网感建议**：当前这个话题可以用什么语感和表达方式来拉近跟大众的距离
9. **改写方向**：综合以上分析，准备从什么角度切入（必须基于选定的逻辑链，与作者意图一致）

> 这一步是给用户看的，让他们理解改写逻辑，也防止改写偏离原意。

### Step 3：改写输出

提供 **2-3 个版本**，每个版本风格不同：

- **版本 A — 钩子型**：用悬念、反常识或提问开头，激发好奇心
- **版本 B — 故事/场景型**：用一个具体的画面或小故事带入，有代入感
- **版本 C — 直给型**：简洁有力，单刀直入讲核心信息

每个版本附带：
- **改写思路**（1-2 句话，说明为什么这样写）
- **配图/配媒体建议**（如果适用）
- **注意事项**（可能的风险或需要作者确认的点）

### Step 4：微调（可选）

用户选定版本后，可以进一步要求：
- 调整语气（更轻松 / 更正式 / 更犀利）
- 增减信息量
- 适配其他平台

---

## 核心改写原则

### 原则 1：钩子先行 — 前 3 秒定生死

第一句话的唯一任务是「让人停下来」。

**技巧库：**
- **反常识**：说一句大家以为不对的话 → "macOS 刘海终于有用了。"
- **提问**：抛一个让人想回答的问题 → "你每天花多少时间等编译？"
- **数字冲击**：用具体数据开头 → "3 天，47 个 bug，1 个人。"
- **场景闪回**：一个有画面感的瞬间 → "凌晨两点，Xcode 弹了第 12 次报错。"
- **对比/转折**：预期 vs 现实 → "本来只想修个小 bug，结果重写了半个模块。"
- **蹭共识**：用一个读者已经知道的现象开头 → "OpenClaw 把 Mac Mini 都带卖爆了，但其实不是每个人都需要买一台。"

**绝对禁止用来开头的：**
- 版本号（"v1.8.0 发布"）
- 时间客套（"经过几个月的努力"）
- 感谢（"感谢大家的支持"）
- 空洞宣布（"很高兴地宣布"）

### 原则 2：话题感 — 让人想说话

好的社交媒体文案是「开一个话头」，不是「做一个总结」。

**技巧库：**
- 留一个有争议的观点 → "原生 app 真的比 web app 体验好吗？"
- 邀请参与 → "你们觉得还差什么功能？评论区说"
- 故意不说完 → "最后一个功能… 还是你们自己试吧"
- 共鸣提问 → "有没有人跟我一样，改完 bug 立刻发现新 bug？"

### 原则 3：一条一个点

一条推文/笔记只讲一个核心信息。如果原始内容有 5 个功能更新，建议：
- 拆成 5 条独立内容（每条聚焦一个功能）
- 或者选出最有话题性的 1-2 个重点讲，其余一笔带过

### 原则 4：像朋友发消息

**语气校准参考：**

| ❌ 官方腔 | ✅ 朋友语气 |
|-----------|------------|
| 感谢用户们的理解和积极反馈 | 你们的吐槽都听到了，改了 |
| 本次更新包含以下优化 | 这次改了个让我自己都受不了的问题 |
| 我们致力于提供更好的体验 | 说实话之前那个体验确实不行 |
| 经过团队的不懈努力 | 肝了两周终于搞定了 |

**关键：有真实情绪，不装。** 可以是兴奋、吐槽、自嘲、骄傲——但不能是「官方声明」。

### 原则 5：视觉优先

- 能用图/GIF/视频展示的，就不用文字描述
- 文字部分尽量控制在 3-5 句话
- 给出具体的配图/配视频建议

---

## 平台适配指南

### Twitter / X

- **语言**：中文为主（如用户要求英文则切换）
- **长度**：核心内容控制在 1-3 句话，可以用 thread 展开
- **风格**：简洁、有态度、像跟朋友说话
- **emoji**：少用或不用，偶尔 1-2 个点缀
- **格式**：不用 bullet point，纯文本 + 配图/GIF
- **节奏示例**：
  ```
  短句。

  稍长一点的解释。

  一句带互动的收尾。
  ```

### 小红书

- **语言**：中文
- **长度**：可以比推特长，200-400 字都行，但要有节奏感
- **风格**：真实、有个人色彩、略带「种草」感但不油腻
- **emoji**：适度使用，起到分段和视觉调节作用（每 1-2 段用 1-2 个）
- **格式**：善用换行制造阅读节奏，关键句单独成段
- **标题**：很重要！要有信息量 + 好奇心（小红书用户先看标题决定是否点进来）
- **节奏示例**：
  ```
  【标题：一句钩子】

  开头一句话交代场景 🎯

  中间 2-3 段展开核心内容
  每段不超过 2-3 行
  关键信息加粗或单独成行

  结尾一句互动引导
  ```

### 即刻

- **语言**：中文
- **长度**：中等，100-300 字
- **风格**：社区感强，像在跟一群朋友聊天，可以更松散和随意
- **emoji**：随意，符合个人风格即可
- **特殊**：即刻用户偏好「真诚分享」，太营销的东西反感度高
- **适合**：开发日志、思考感悟、产品小更新

---

## 风格护栏 — 防止改过头

改写必须遵守以下底线：

### 绝对禁止
- ❌ 编造数据或夸大事实
- ❌ 营销话术（"错过就后悔"、"赶紧冲"、"绝绝子"）
- ❌ 空洞形容词堆砌（"强大"、"完美"、"极致"、"颠覆"）
- ❌ 标题党（内容撑不起标题的夸张）
- ❌ 过度 emoji（不要变成微商画风）
- ❌ 违背作者原意或个人风格

### 始终保持
- ✅ 信息的真实性和准确性
- ✅ 作者本人会说出口的语气
- ✅ 「这是一个人在说话」的感觉，而不是「一个品牌在发声明」
- ✅ 如果原文有技术细节，改写后核心技术信息仍要准确

### 自检问题
改写完成后，用这三个问题自检：
1. 作者本人发这条会觉得尴尬吗？→ 如果会，语气改过头了
2. 读者看完能获得原文的核心信息吗？→ 如果不能，删减过多了
3. 这条内容有没有「让人想说点什么」的冲动？→ 如果没有，话题感不够

---

## 改写示例

### 示例 1：产品更新公告

**原文：**
> Zipic v1.8.0 发布。这次更新添加了 Notch 区域图片展示功能，优化了图片压缩算法，修复了若干已知问题。

**平台：推特（中文）**

**诊断：** 原文信息完整但像 changelog，没有钩子。Notch 区域展示图片是天然话题点——大家一直吐槽刘海没用，这个功能直接反转了这件事，应该放大。压缩算法优化和 bug 修复可以一笔带过。

**版本 A — 钩子型：**
> MacBook 刘海终于有用了。
>
> Zipic 1.8 可以直接在 Notch 区域预览图片，顺便优化了压缩算法。
>
> 你们还希望刘海能干嘛？

改写思路：用反常识开头，「刘海有用了」自带话题性。结尾抛问题引互动。
配图建议：Notch 区域显示图片的截图或 GIF。

**版本 B — 场景型：**
> 每次看到 MacBook 那个刘海都觉得浪费。
>
> 所以 Zipic 1.8 把它变成了图片预览区——拖张图上去就能看。另外压缩速度也快了不少。

改写思路：从一个大家共有的小烦恼出发，用「所以」自然转入功能介绍，不硬推。
配图建议：屏幕录制 GIF，展示拖拽到 Notch 的交互。

**版本 C — 直给型：**
> Zipic 1.8 更新：
> · Notch 区域可以直接预览图片了
> · 压缩算法优化，速度更快
>
> 这个 Notch 功能挺好玩的，试试看。

改写思路：保留简洁信息量，但去掉了版本号开头和客套话，用「挺好玩的」收尾拉近距离。
配图建议：功能截图 1-2 张。

---

### 示例 2：有趣发现分享（产品/设计/技术）

**原文：**
> 今天发现 Linear 的交互设计有个很巧妙的细节：当你拖拽任务卡片时，卡片会轻微倾斜并产生一个柔和的阴影变化，让你感觉真的在「拿起」一个东西。这种微交互看起来简单，但对用户体验的提升很大。

**平台：推特（中文）**

**诊断：** 内容本身有洞察力，观察很细，但写法像在写设计分析报告。「拿起一个东西」这个感受描述很好，应该前置。最后那句「对用户体验的提升很大」太抽象，反而削弱了前面具体观察的力度。

**版本 A — 钩子型：**
> Linear 的拖拽有一个细节：卡片拖起来会微微倾斜，阴影跟着变。
>
> 就这一个小动效，让你觉得自己真的「拿」着一个东西。
>
> 微交互做到这个程度，体验差距就是这么拉开的。

改写思路：先给具体细节（倾斜+阴影），再用「拿」字制造感官共鸣，最后一句点睛但不说教。
配图建议：屏幕录制 Linear 拖拽效果的 GIF，最好放慢播放。

**版本 B — 场景型：**
> 今天用 Linear 拖任务的时候突然愣了一下——
>
> 这个卡片拖起来的手感也太好了吧。微微倾斜，阴影跟手，就像真的拿起了一张卡片。
>
> 好的微交互就是这样，你说不出哪里好，但就是舒服。

改写思路：用「愣了一下」制造一个真实的发现瞬间，让读者跟着体验那个 aha moment。
配图建议：同上，GIF 效果最佳。

---

### 示例 3：个人感悟（独立开发 / 生活）

**原文：**
> 做独立开发一年了，最大的感受是时间管理特别重要。以前上班的时候有人帮你安排优先级，现在所有事情都要自己决定先做什么。经常一天结束发现忙了很多但真正重要的事没推进。

**平台：小红书（中文）**

**诊断：** 感悟真实，很多独立开发者有共鸣。但写得太「总结陈词」了，像在做年终汇报。「一天结束发现忙了很多但重要的事没推进」这个痛点非常具象，应该放大。

**版本 A — 钩子型：**
> 标题：独立开发一年，最大的坑不是技术
>
> 是时间管理。
>
> 以前上班，优先级有人帮你定
> 现在每天醒来第一件事就是想：今天先干嘛？
>
> 结果经常忙了一整天
> 回头一看，重要的事一个没动 😅
>
> 后来摸索出一个方法：
> 每天只定 1 件「今天必须搞定」的事
> 不管发生什么，这件先做
>
> 听起来简单，但真的管用。你们有什么自己的方法吗？

改写思路：标题用「最大的坑不是技术」制造悬念。正文从痛点共鸣切入，给一个具体方法（让内容有价值），结尾引互动。
配图建议：简洁的手写风格配图，或 Notion/日历截图展示时间管理方法。

**版本 B — 场景型：**
> 标题：独立开发者的一天是怎么「废掉」的
>
> 早上：今天一定要把那个核心功能写完
> 上午：先回复几条用户反馈吧
> 中午：顺手修个小 bug
> 下午：研究了一下新的部署方案
> 晚上：……核心功能一行没写
>
> 独立开发一年，这种剧情反复上演
> 后来意识到：不是时间不够，是没有人帮你说「不」
>
> 你们独立开发/自由职业也是这样吗？

改写思路：用时间线还原一天的「滑坡」过程，每个人都能对号入座。最后一句提炼洞察并引导互动。
配图建议：时间线风格的插图，或一个「计划 vs 实际」的对比图。

---

## 特殊情况处理

### 原文已经很好
如果原文本身已经有不错的网感和互动感，不要强行大改。可以：
- 做微调（优化节奏、强化钩子）
- 直接告诉用户「这条已经挺好了」，并说明好在哪里
- 给 1-2 个小的优化建议

### 原文信息量过大
如果原文包含太多信息（比如一次更新了 8 个功能）：
- 建议拆分成多条内容
- 帮用户选出最有话题性的 1-2 个点
- 提供一个「总览版」+ 若干「单点深入版」

### 敏感内容
如果原文涉及对竞品的对比或批评：
- 保持事实，去掉攻击性
- 用「我遇到的问题」代替「他们做得差」
- 建议用户自行评估风险