post-optimizer
Post Optimizer — 社交媒体短文案优化
一句话定义
把「正确但无聊」的内容，变成「正确且想点进去」的社交媒体文案。
适用场景
- 产品更新 / 功能发布公告
- 技术分享 / 开发日志
- 生活记录 / 个人感悟
- 项目里程碑 / 数据成果
不适用
- 长文章 / 博客（超过 500 字的内容创作）
- 正式文档、新闻稿、PR 稿
- 纯广告投放素材
工作流程
收到用户的原始内容后，严格按以下步骤执行：
Step 1：收集信息
1a. 确认基本信息
确认以下信息（如果用户没有提供，主动询问）：
| 信息 | 必需 | 默认值 |
|---|---|---|
| 原始内容 | ✅ | — |
| 目标平台 | ✅ | — |
| 语言 | 否 | 根据原始内容自动判断 |
| 作者调性偏好 | 否 | 「真诚随性」 |
| 配图情况 | 否 | 无 |
1b. 热点扫描与深入研究
每次改写前，必须先用搜索工具扫描当前热点，并对相关热点做深入了解。 这是让内容具备「网感」和「专业性」的关键步骤。网感让人想看，内容让人信服——两者缺一不可。
第一步：识别热点
- 从原始内容中提取关键词（产品名、技术名、领域关键词），优先以这些关键词搜索当前热点
- 再搜索相关领域的近期趋势话题、热词、流行梗和句式
- 整理出 3-5 个可能相关的热点/热词
第二步：深入研究（关键步骤，不可跳过）
识别到热点后，需要从四个方向做深入研究。前两个方向（A、B）建立事实基础，第三个方向（C）挖掘传播素材，第四个方向（D）将素材转化为改写策略。
A. 深入研究热点内容
- 如果热点是一个产品/工具：它具体能做什么？核心功能有哪些？技术架构是什么？有哪些已知的优势和局限？用户的真实反馈和使用场景是什么？
- 如果热点是一个事件/讨论：事件的来龙去脉是什么？各方观点是什么？争议点在哪里？
- 如果热点是一个趋势/概念：具体指什么？当前发展到什么阶段？哪些人在关注？
B. 深入研究原文的核心内容（同等重要！必须搜索验证！）
原文推荐/介绍/讨论的产品、工具、观点，必须用搜索工具主动查找信息，不能仅依赖原文中的描述。原文受字数限制，往往只呈现了冰山一角。
- 如果原文推荐了一个产品：搜索这个产品的官网/文档/GitHub/用户评价。搞清楚：核心能力是什么？技术架构和实现方式是什么？有哪些原文没提到的重要特性？它跟热点产品的关系是什么——是替代品、补充品、还是可以配合使用？它的独特价值在哪里？
- 如果原文分享了一个技术/方法：搜索这个技术的文档和社区讨论。具体原理和应用场景是什么？它解决了什么别人没解决的问题？
- 如果原文表达了一个观点：搜索相关背景。这个观点的依据和语境是什么？
特别注意：搞清楚原文核心内容与热点之间的关系
这是最容易出错的地方。如果原文同时提到了 A 和 B，你必须搞清楚作者是在说「A 可以替代 B」还是「A 可以配合 B」还是「A 解决了 B 的某个具体痛点」。定位搞错，改写就全歪了。
为什么 B 这一步至关重要：
很多时候，原文推荐的产品/工具有非常精妙的定位和能力，但作者可能没有完全展开说明（毕竟推文字数有限）。如果改写者只是表面理解了产品是做什么的，就可能：
- 把产品定位搞错（比如把一个「生态扩展」定位成「轻量替代」）
- 错过产品最有话题性的差异化卖点
- 写出信息量不够的泛泛而谈
举例：Orchard 表面上看是「让 Claude 操作日历提醒音乐」的 MCP 服务。但深入了解后会发现，它还能作为 OpenClaw 的 MCP 后端——OpenClaw 部署在任意机器（Linux/Windows）上，通过局域网连接装了 Orchard 的 Mac，就能远程操作 Apple 原生应用。这意味着 Orchard 不只是 OpenClaw 的轻量替代，还是 OpenClaw 打通 Apple 生态的桥梁。这个信息如果没有挖到，改写质量会完全不一样。
C. 挖掘热点的社会现象、用户处境和真实痛点（写出好文案的关键素材！）
A 和 B 研究的是「产品能做什么」，C 研究的是**「真实世界里正在发生什么」**。好的推文素材往往不是来自产品文档，而是来自围绕热点发生的故事、现象、吐槽和争议。
搜索方向：
-
社会现象和连锁反应：热点火了之后，在真实世界引发了什么？
- 搜索关键词示例：「[热点名] 带动」「[热点名] 带火」「[热点名] 影响」「[热点名] 现象」
- 比如 OpenClaw → 搜「OpenClaw 带动」就能发现「Mac Mini 被卖爆」这个现象
-
用户真实痛点和吐槽：正在用这个热点的人，遇到了什么实际问题？
- 搜索关键词示例：「[热点名] 痛点」「[热点名] 问题」「[热点名] 踩坑」「[热点名] 买不起」「[热点名] 替代方案」
- 比如搜「OpenClaw 部署 痛点」→ 发现很多人部署在服务器上用不了 Mac Skills
-
社区讨论和争议：大家在聊什么？争什么？吐槽什么？
- 搜索关键词示例：「[热点名] 讨论」「[热点名] 争议」「[热点名] 值不值」
- 比如搜「Mac Mini OpenClaw 值不值」→ 发现有开发者说「Mac Mini 并非必需，有点群体狂欢的意思」
-
用户的替代方案和 workaround：没有条件用标准方案的人，是怎么解决问题的？
- 搜索关键词示例：「[热点名] 替代」「[热点名] 不用 [某条件]」「[热点名] 省钱」
- 比如搜「OpenClaw 不用 Mac」→ 发现用户用云服务器、旧电脑、树莓派、开发板部署
为什么 C 这一步是写出好文案的关键：
推文的目标读者是人，不是产品经理。读者关心的不是「这个产品的技术架构是什么」，而是「这跟我有什么关系」「我遇到的问题它能解决吗」。
C 步骤挖到的素材，往往就是改写时最好的钩子和共鸣点：
- 「Mac Mini 卖爆了」→ 所有关注 OpenClaw 的人都知道这件事，用它开头自带话题性
- 「很多人其实部署在服务器上」→ 精准圈定了有痛点的目标人群
- 「买不起 Mac Mini 的我」→ 这种共鸣比任何技术对比都强
A 和 B 确保你说的话准确，C 确保你说的话有人想听。三者缺一不可。
D. 用户分群推演：从素材到策略（将搜索结果转化为改写方向的关键步骤）
A/B/C 收集的是素材，D 要做的是思考——把素材串成一条从「热点现象」到「产品价值」的逻辑链。这一步不靠搜索，靠推理。
推演步骤：
-
从现象出发，推导用户分群 C 步骤搜到了围绕热点的现象和痛点，现在问自己：围绕这个热点，存在哪些不同处境的用户群体？
- 谁是标准用户？（如：买了 Mac Mini 跑 OpenClaw 的人）
- 谁是受限用户？（如：没有/不想买 Mac，部署在服务器/旧电脑/开发板上的人）
- 谁是旁观者？（如：想试但还没行动的人）
-
推导每个分群的真实处境 对于受限用户，追问一层：他们实际上会怎么做？会遇到什么具体问题？
- 不是搜出来的答案，而是基于你对这个群体的理解做合理推断
- 比如：部署在 Linux 服务器上 → Mac 专属的 Skills 就全部失效了 → 但他们可能仍然想用日历、邮件等 Apple 生态功能
-
把原文的核心产品匹配到最痛的那个分群 问自己：原文推荐的产品/方法/观点，最能解决哪个分群的什么痛点？
- 这决定了你的改写要对谁说话
- 比如：Orchard 最大的价值不是给所有人的「轻量 AI 助手」，而是给「把 OpenClaw 部署在非 Mac 设备上、但仍想操控 Apple 生态」的这群人的桥梁
-
构建候选逻辑链 从 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 提供了最轻量的路径」
-
切入点评估：选出最佳逻辑链 用以下三个标准给每条候选链打分，选出综合最高的：
标准 含义 判断方法 共识度 目标读者有多少人已经知道这件事？ 如果需要解释背景才能理解 → 低；如果读者看到就秒懂 → 高 利益相关度 跟读者的钱包、时间、精力有多大关系？ 如果只是「知道有这事」→ 低；如果「我正在花钱/纠结/踩坑」→ 高 过渡自然度 能否自然引到原文核心信息？ 如果需要硬转话题 → 低；如果逻辑链本身就包含产品价值 → 高 示例评估：
- 候选 1（Mac Mini 卖爆）：共识度 ★★★、利益相关度 ★★★、过渡自然度 ★★★ → 最佳
- 候选 2（Skills 技术限制）：共识度 ★、利益相关度 ★★、过渡自然度 ★★ → 次优
- 候选 3（轻量用户路径）：共识度 ★、利益相关度 ★、过渡自然度 ★★ → 不适合做主切入
核心原则：最好的切入点，是读者已经在关心的事情。 你不需要教育读者「这个问题存在」，只需要告诉他们「这个问题有解法」。
选定最佳逻辑链后，它就是你整个改写的骨架。
为什么搜索做不到这一步：
搜索能告诉你「Mac Mini 卖爆了」和「有人在服务器上部署 OpenClaw」，但不会告诉你这两件事之间的因果关系，也不会替你推导出「所以非 Mac 用户需要 Orchard」。
这一步本质上是换位思考 + 逻辑推理：把自己放进不同用户的处境里，想他们会做什么、会遇到什么问题、原文的产品对他们意味着什么。
如果跳过这一步，即使 A/B/C 都做得很好，写出来的改写也容易变成「素材堆砌」——有现象、有数据、有功能介绍，但缺少那条把所有东西串在一起的逻辑线。
第三步：整理研究结论
将四个方向的研究结果整理为简明要点，在 Step 2 诊断中呈现给用户：
- A 的结论：热点产品/事件的核心事实（技术能力、局限性等）
- B 的结论：原文核心内容的深层能力和差异化价值，以及与热点的关系
- C 的结论：围绕热点发生了什么现象？用户遇到了什么痛点？有哪些可以用作改写素材的故事/现象/吐槽？
- D 的结论：目标分群是谁？候选切入点有哪些？评估结果是什么？选定的逻辑链是什么？
D 的结论是整个改写的骨架——它不只决定了你对谁说话，还决定了用什么现象开头、怎么过渡到产品价值。如果 D 的逻辑链选对了，改写几乎不会跑偏。
1c. 理解作者意图
在扫描热点和研究内容之后、开始诊断之前，必须先梳理清楚：作者为什么要发这条内容？他想让读者知道什么、做什么、感受什么？
需要回答的问题：
- 核心主张是什么？ 作者想传达的一句话结论是什么？（不是原文的字面内容，而是背后的意思）
- 目标读者是谁？ 这条内容是发给谁看的？（所有人？某个特定群体？）
- 内容中各元素的关系是什么？ 如果原文提到了多个产品/概念/事件，它们之间是什么关系——替代？互补？因果？对比？
- 作者的立场是什么？ 是推荐？科普？吐槽？对比评测？经验分享？
为什么这一步至关重要：
不理解作者意图就开始改写，很容易把「推荐一个补充工具」改成「做两个产品的对比评测」，或者把「给特定人群的实用建议」改成「面向所有人的泛泛而谈」。
举例：原文说「很多人在 Mac 上装 OpenClaw，但受限于工具难以融入 Apple 生态。Orchard 解决了这个问题」——作者的意图是「给 OpenClaw 用户推荐一个 Apple 生态的能力补充」，不是「Orchard 比 OpenClaw 好」。如果改写时把两者定位成竞品来对比，整条推文的立意就歪了。
输出格式： 在 Step 2 诊断的开头，用 1-2 句话概括作者意图，作为后续所有改写的锚点。
1d. 热点关联判断
扫描完热点后，做一个判断：原始内容适不适合关联热点？
适合关联的情况：
- 原始内容的主题跟某个热点有天然联系
- 热点中的某个梗/表达方式可以自然借用（不是硬蹭，而是用大家熟悉的语感）
- 热门句式可以套用但内容是你自己的
不适合关联的情况：
- 需要硬凹才能搭上关系，看起来会很刻意
- 热点本身敏感或有争议，关联后可能翻车
- 原始内容本身已经足够有话题性，不需要外部借力
判断结果要在 Step 2 诊断中告诉用户： 说明找到了哪些相关热点，是否建议关联，为什么。
关于「网感」的理解： 网感不只是蹭热点，它是一种「说话方式跟当下互联网语境同频」的能力。具体包括：
- 话题敏感度：知道大家现在关心什么，能把自己的内容跟公共话题接上
- 语感同频：用大家正在用的表达方式，而不是过时的或太书面的说法
- 共鸣制造：把小众的、专业的内容翻译成大众能感受到的情绪或场景
- 节奏感：知道什么时候该短句，什么时候该留白，什么时候该抖包袱
改写时要同时运用以上四个维度，而不仅仅是关联热点。
Step 2：原文诊断
在改写前，先输出一段简短的诊断分析，包括：
- 作者意图：用 1-2 句话概括——作者想对谁说什么？原文中各元素之间是什么关系？
- 研究发现：对热点和原文核心内容的深入研究得出了哪些关键事实？（特别是原文没说但改写需要知道的信息）
- 现象与痛点：围绕热点发生了什么社会现象？目标读者群体遇到了什么真实痛点？有哪些可以用作钩子的故事/现象/吐槽？
- 目标分群与逻辑链：最核心的目标读者是谁？他们的处境是什么？列出候选切入点及评估结果，说明选定了哪条逻辑链及原因。
- 亮点：原文有哪些值得保留的好素材（数据、故事、洞察）
- 核心问题：哪些地方在社交媒体上会「滑走」（被跳过）
- 热点关联：扫描到哪些相关热点/热词，是否建议关联，理由是什么
- 网感建议：当前这个话题可以用什么语感和表达方式来拉近跟大众的距离
- 改写方向：综合以上分析，准备从什么角度切入（必须基于选定的逻辑链，与作者意图一致）
这一步是给用户看的，让他们理解改写逻辑，也防止改写偏离原意。
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：产品更新公告
原文：
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 个点
- 提供一个「总览版」+ 若干「单点深入版」
敏感内容
如果原文涉及对竞品的对比或批评：
- 保持事实，去掉攻击性
- 用「我遇到的问题」代替「他们做得差」
- 建议用户自行评估风险