post-optimizer

Installation
SKILL.md

Post Optimizer — 讲故事,不写 changelog

一句话定义

把「正确但无聊」的内容,变成一个让人想读完的故事

核心理念:活人感 = 讲故事

人不爱看功能列表,但爱听故事。

每一个产品更新、每一个技术决策、每一条生活感悟背后,都有一个故事——某个问题困扰了你,某个灵感突然出现,某次纠结之后做了一个取舍。把这个故事讲出来,活人感就自然来了。

对比一下:

❌ 功能罗列(死的) ✅ 讲故事(活的)
新增版本更新徽标功能,用户可在主窗口右上角查看更新日志 以前检测到更新就直接弹窗,总觉得像在打断用户。后来改成右上角放个小徽标——你看到了点一下,没注意到也不烦你。侵入感小了很多。
优化了图片压缩算法,速度提升 30% 压缩一张 4K 图之前要等 3 秒,我自己用着都烦。花了一周重写了核心算法,现在不到 1 秒。
支持暗色模式 凌晨两点改 bug 的时候被自己的白色界面闪瞎了眼,第二天就开始写暗色模式。

故事的本质是:让读者看到「人」,而不是「产品」。


适用场景

  • 产品更新 / 功能发布
  • 技术分享 / 开发日志
  • 生活记录 / 个人感悟
  • 项目里程碑 / 数据成果
  • 用户给一个主题,要求生成推文

不适用

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

工作流程

Step 1:理解素材,挖掘故事

用户给的素材可能是:

  • 一段写好的草稿
  • 一组功能点 / 更新日志
  • 一个主题 / 想法
  • 一段口述的背景信息

无论哪种,你的第一步都是找到故事

1a. 故事挖掘清单

从素材中寻找以下线索(按优先级排列):

  1. 起因:为什么做这个?是什么问题触发的?是自己踩坑了?用户反馈了?还是某个灵光一闪?
  2. 纠结 / 取舍:过程中有没有做过什么决定?放弃了什么方案?为什么选了现在的方案?
  3. 思考逻辑:背后有没有产品思路、交互逻辑、技术权衡?(比如「弹窗 vs 徽标」就是一个交互逻辑的取舍)
  4. 转折 / 意外:有没有本来想做 A 结果变成了 B?有没有意料之外的收获或者坑?
  5. 情绪节点:有没有"卧槽终于搞定了"、"这也太烦了"、"用着用着突然觉得不对"这样的时刻?
  6. 用户相关:这个改动对用户有什么切身影响?用户之前可能遇到过什么痛点?

如果素材里这些信息不够,主动问用户。 问得具体一点:

  • "这个功能是怎么想到要做的?"
  • "做的过程中有没有纠结过什么?"
  • "之前用户是怎么处理这个问题的?"

不要泛泛地问"能给我更多背景吗"——要针对性地挖。

1b. 确认基本信息

信息 必需 默认值
素材内容
目标平台
语言 根据素材自动判断
配图情况

1c. 热点扫描(轻量版)

用搜索工具快速扫描一下素材相关领域的近期热点。目的不是做完整市场研究,而是回答两个问题:

  1. 有没有当前热点可以自然关联? 如果素材本身跟某个热门话题有天然联系,借一下势,开头会更容易抓人。
  2. 大家最近在聊什么相关的事? 了解目标读者的语境,避免用过时的表达或错过共识性话题。

注意:不是每条推文都需要蹭热点。 如果素材本身故事就很好,或者跟热点没有天然关联,就不蹭。硬蹭比不蹭更糟。

Step 2:构思 & 诊断

在动手写之前,先理清思路,输出一段简短的诊断(给用户看,让他们理解你的改写逻辑):

  1. 故事线:你从素材中提炼出的故事是什么?一句话概括(例:"这是一个「用更轻的方式通知用户更新」的交互设计故事")
  2. 核心信息:这条推文最终要传达的一个点是什么?
  3. 钩子策略:打算用什么方式开头抓人?
  4. 热点关联:找到了什么相关热点?是否建议关联?
  5. 注意事项:有没有需要作者确认的信息、可能的敏感点

Step 3:改写输出

只输出一个最优版本。

不要给三个风格让用户选——你是专家,直接给出你认为最好的方案。如果用户不满意,再调整。

改写时遵循以下结构(不是死板模板,灵活运用):

故事型推文的基本骨架

[钩子] — 一句话抓住注意力(场景、痛点、反常识、一个让人共鸣的瞬间)

[故事] — 讲清来龙去脉(为什么做、怎么想的、做了什么取舍)

[结果] — 现在变成什么样了(功能展示、效果对比、解决了什么问题)

[收尾] — 让人想说话(抛问题、留互动钩子、或用一句利落的话收住)

这个骨架的关键在于:读者先看到「人」(你的经历、想法、纠结),再看到「产品」(你做了什么)。 而不是反过来。

Step 4:微调(可选)

用户确认后,可以进一步:

  • 调整语气(更轻松 / 更犀利 / 更克制)
  • 增减信息量
  • 适配其他平台

讲故事的技巧库

开头:前 3 秒定生死

第一句话的唯一任务是「让人停下来」。最好的开头往往是故事的某个片段:

类型 示例
痛点共鸣 "每次检测到更新就弹窗,总觉得像在打断别人说话。"
场景闪回 "凌晨两点被自己的白色界面闪瞎了眼。"
反常识 "MacBook 刘海终于有用了。"
自我吐槽 "压缩一张图要 3 秒,我自己用着都烦。"
转折 "本来只想加个小功能,结果重新想了一遍整个更新逻辑。"
蹭共识 用一个读者已经知道的现象开头,自带话题性

绝对禁止用来开头的:

  • 版本号("v1.8.0 发布")
  • 时间客套("经过几个月的努力")
  • 感谢("感谢大家的支持")
  • 空洞宣布("很高兴地宣布")

中段:让人看到「为什么」

这是故事的核心部分——不是罗列"做了什么",而是讲"为什么这么做"。

好的中段会让读者觉得:「哦原来是这么回事」「这个思路有意思」「我之前也遇到过这个问题」。

技巧:

  • 对比旧方案 vs 新方案,让读者看到思考过程("以前是弹窗,现在改成徽标,侵入感小多了")
  • 暴露纠结过程,显得真实("其实一开始想做 A,但后来觉得...")
  • 用因果链串联,而不是并列("因为 → 所以 → 结果"比"功能1、功能2、功能3"好一万倍)
  • 加入具体细节,让故事有质感(数字、场景、具体操作步骤)

收尾:让人想说话

好的社交媒体内容是「开一个话头」,不是「做一个总结」。

  • 抛一个真实的问题("你们平时怎么处理更新提醒的?")
  • 留一个开放的结尾("下一步打算...")
  • 一句利落的收束("就这样,试试看。")

语气校准:像朋友发消息

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

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


平台适配指南

Twitter / X

  • 语言:中文为主(如用户要求英文则切换)
  • 长度:核心内容 1-3 句话,可用 thread 展开
  • 风格:简洁、有态度、像跟朋友说话
  • emoji:少用或不用,偶尔 1-2 个点缀
  • 格式:不用 bullet point,纯文本 + 配图/GIF
  • 节奏:短句。换行。留白。让人一口气读完。

小红书

  • 语言:中文
  • 长度:200-400 字,要有节奏感
  • 标题:极其重要!有信息量 + 好奇心(用户先看标题决定是否点进来)
  • 风格:真实、有个人色彩,略带「种草」感但不油腻
  • emoji:适度使用,起到分段和视觉调节(每 1-2 段 1-2 个)
  • 格式:善用换行制造阅读节奏,关键句单独成段

即刻

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

风格护栏 — 防止改过头

绝对禁止

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

始终保持

  • 信息的真实性和准确性
  • 作者本人会说出口的语气
  • 「这是一个人在说话」的感觉
  • 如果有技术细节,核心技术信息仍要准确

自检三问

  1. 作者本人发这条会觉得尴尬吗?→ 如果会,改过头了
  2. 读者看完能获得核心信息吗?→ 如果不能,删减过多了
  3. 读者能感受到一个真实的人在说话吗?→ 如果不能,故事没讲好

改写示例

示例 1:产品功能更新

素材:

Zipic 主窗口右上角新增版本更新徽标。检测到更新后显示徽标,点击可查看更新日志。

补充背景(用户提供或挖掘得到的):

以前检测到更新要么需要用户手动触发,要么自动弹窗。觉得弹窗侵入感太强,想要一种更轻的方式。改成徽标后,用户看到了点一下看日志再决定更不更新,没注意到也不会被打断。

平台:Twitter / X(中文)

诊断:

  • 故事线:这是一个「重新思考更新通知方式」的交互设计故事
  • 核心信息:用更克制的方式通知用户更新
  • 钩子策略:从「弹窗打断用户」这个大家都有的痛点切入

改写:

以前检测到版本更新就直接弹窗,总觉得像在打断别人。

改成了右上角一个小徽标——你注意到了点一下,看看更新了什么再决定。没注意到也不烦你。

更新提醒这种东西,侵入感越小越好。

配图建议:主窗口右上角徽标的截图,或点击后显示更新日志的 GIF。

示例 2:技术发现分享

素材:

今天发现 Linear 的交互设计有个很巧妙的细节:当你拖拽任务卡片时,卡片会轻微倾斜并产生一个柔和的阴影变化,让你感觉真的在「拿起」一个东西。

平台:Twitter / X(中文)

诊断:

  • 故事线:一个使用中的 aha moment
  • 核心信息:好的微交互让人「感觉对了」但说不出为什么
  • 钩子策略:用发现的瞬间带入

改写:

今天拖 Linear 的任务卡片时愣了一下——

这手感也太好了。卡片拖起来微微倾斜,阴影跟着手走,就像真的拿起了一张卡片。

好的微交互就是这样,你说不出哪里好,但就是舒服。

配图建议:屏幕录制 Linear 拖拽效果的 GIF,最好放慢。

示例 3:独立开发感悟

素材:

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

平台:小红书(中文)

诊断:

  • 故事线:独立开发者「忙了一天但啥都没干」的日常
  • 核心信息:独立开发最难的不是技术,是自我管理
  • 钩子策略:用一天的时间线还原「滑坡」过程,谁看了都有代入感

改写:

独立开发者的一天是怎么"废掉"的

早上:今天一定要把那个核心功能写完 上午:先回复几条用户反馈吧 中午:顺手修个小 bug 下午:研究了一下新的部署方案 晚上:……核心功能一行没写

独立开发一年,这种剧情反复上演 😅

后来意识到问题不是时间不够,是没有人帮你说「不」 以前上班,优先级有人帮你定 现在每天起来第一件事就是跟自己博弈:今天到底先干嘛?

后来摸索出一个笨办法——每天只定一件"今天必须搞定"的事,不管发生什么先做完它

你们有什么管用的方法吗?


特殊情况处理

素材已经很好

不要强行大改。可以:

  • 做微调(强化钩子、优化节奏)
  • 直接告诉用户「这条已经挺好了」,说明好在哪
  • 给 1-2 个小建议

素材信息量过大

如果一次更新了很多功能:

  • 建议拆分成多条,每条讲一个故事
  • 帮用户选出最有故事性的 1-2 个点
  • 其余一笔带过或留给后续

用户只给了一个主题

没有具体素材时,主动引导用户讲出背后的故事:

  • "这个想法是怎么来的?"
  • "做的时候有没有什么有意思的事?"
  • "遇到过什么让你印象深刻的用户反馈?"

有了故事素材,再开始写。

Related skills
Installs
26
GitHub Stars
150
First Seen
Mar 4, 2026