酒香也怕巷子深：用 AI Skill 给内容和产品装上运营循环

一个不太体面的现实

老话说，酒香不怕巷子深。

这话放在村口小酒馆也许成立，放到今天的互联网，就有点像把单体应用直接扔进 Kubernetes 里裸奔：不是完全不行，但大概率活得很艰难。

你写了一篇自认为还不错的文章，结构清楚，观点也不水；你做了一个小工具，能解决真实问题，README 也写了。然后呢？发出去，刷新统计，几十个阅读，三五个点赞，评论区安静得像凌晨三点的办公室。

很多技术人对运营有一种本能抗拒，觉得那是“吆喝”，甚至有点不体面。可现实是：价值如果不能被正确的人看见、理解、信任和复用，它就只能停在你自己的硬盘里自嗨。

我现在越来越觉得，AI 对内容创作和软件产品最大的帮助，不是“帮我写一篇爆款文”，而是帮我们把运营做成一条循环：选题、包装、分发、反馈、复盘、再创作。这个循环一旦能跑起来，酒不一定立刻卖爆，但至少不会一直闷在坛子里。

别把运营想成喊麦

先把一个误会拆掉。

运营不是把一句话改成十种标题党，也不是在十个群里复制粘贴同一段广告。那叫打扰，不叫运营。

我理解的技术内容和软件产品运营，核心就四件事：

这里面很多工作不需要天才创意，反而需要稳定、重复、耐心。说白了，就是工程师最熟的那一套：把流程拆开，定义输入输出，加检查点，然后让机器跑。

这就是 Skill 的用武之地。

一条最小运营 Loop

如果把运营看成一个系统，它至少要有五个环节。

1. Capture：把原始材料抓住

原始材料可能是一段随手记的想法、一段代码变更、一次用户反馈、一条聊天记录、一个 issue，或者产品发布时那份没人愿意读的 changelog。

很多内容死在第一步：不是没价值，而是散落在聊天、笔记、commit message 和脑子里。AI 可以先做“捡破烂”的工作，把碎片收集起来，按主题归类。

2. Package：把材料包装成别人能入口的形态

同一个东西，给不同人看，包装方式要不一样。

给工程师看，可以是架构图、命令、代码片段和边界条件；给产品经理看，要讲场景、用户收益和取舍；给新用户看，最好是三步上手，别一上来就扔一篇博士论文。

AI 很适合做多版本包装，但前提是你要告诉它目标读者是谁。否则它会生成一种很熟悉的味道：每句话都正确，每句话都没用。

3. Distribute：分发到合适的地方

内容发布不是“发出去”三个字这么简单。

同一篇文章，可以拆成：

• 博客长文：讲完整逻辑；
• 短帖：提炼一个反直觉观点；
• README 更新：让后来者能找到入口；
• 内部分享稿：方便团队同步；
• FAQ：回答别人最可能问的五个问题。

AI 可以帮你把一份材料改成多种载体，但不能替你判断“谁该看到”。这个判断还得人来做，因为它背后是关系、场景和责任。

4. Listen：把反馈收回来

运营最容易断的地方，就是只发不听。

阅读数、点击数、评论、收藏、转发、issue、安装量、star、邮件回复，都是反馈。别迷信单个数字，尤其别把“点赞少”直接理解成“内容差”。有些内容是慢热型资产，今天没人说话，三个月后有人搜到，救他一命。

AI 可以帮你把反馈整理成模式：哪些问题重复出现，哪些地方读者看不懂，哪些标题带来了误解，哪些用户已经露出了真实需求。

5. Iterate：把反馈变成下一轮动作

最后一步才是循环的关键。

如果反馈只是被看一眼，然后躺在聊天记录里，那就还是手工作坊。真正的 Loop 要把反馈变成下一轮任务：

• 文章标题太抽象 → 生成 3 个更具体的版本；
• README 被问了 5 次安装问题 → 补一个 quick start；
• 用户总是误用某个参数 → 加一段 warning 和示例；
• 某个短帖效果好 → 扩写成完整文章；
• 某篇文章被搜索命中 → 做成系列入口页。

这时候 AI 不再是“帮我写点什么”，而是“帮我维护一个会学习的运营系统”。

Skill 不要写成许愿池

很多人写 Skill，第一反应是：

帮我写爆款文章。

这就像给实习生派活：“你把系统搞稳定一点。”听上去豪迈，实际没法执行。

一个好 Skill 应该像一个小型 SOP：触发条件清楚，输入材料清楚，执行步骤清楚，输出格式清楚，检查标准也清楚。

我会把 Skill 写成下面这种粒度：

注意，这些 Skill 都不承诺“让你火”。它们只承诺一件事：把本来容易偷懒、遗漏、凭感觉做的事，变成可重复执行的流程。

一个可以直接抄的 Skill 模板

下面这个模板不花哨，但够用。

---
name: content-distribution-loop
description: Use when a blog post, README, release note, or product update needs to be repackaged and distributed to different audiences.
---

# Content Distribution Loop

## Goal

Turn one source artifact into several audience-specific distribution assets, then produce a feedback checklist for the next iteration.

## Inputs

- Source artifact: blog post, README, changelog, PR summary, or notes
- Target audience: engineers, product managers, new users, existing users, or internal stakeholders
- Distribution channels: blog, newsletter, team chat, README, docs, social post, release note
- Constraints: facts that must not be changed, claims that need verification, sensitive information to exclude

## Workflow

1. Identify the core claim in one sentence.
2. List the target reader's likely questions.
3. Generate channel-specific drafts:
   - Long summary for blog or docs
   - Short post for chat or social channel
   - FAQ for repeated questions
   - README or onboarding snippet if applicable
4. Mark unsupported claims and facts that need human review.
5. Produce a feedback collection checklist.

## Output

- Core claim
- Audience/channel matrix
- Draft assets
- Human review notes
- Feedback checklist

## Quality Gate

- Do not invent metrics, testimonials, user quotes, or roadmap promises.
- Do not change technical facts from the source artifact.
- Keep promotional copy specific and restrained.
- If the source is weak, say what is missing instead of polishing it into nonsense.

这里最重要的是最后的 Quality Gate。运营不是化妆术，不能把一个还没解决的问题包装成行业革命。AI 很擅长把话说满，所以更需要边界。

软件产品推广：先补四张卡片

如果你推广的是一个软件产品，尤其是一个开源工具、内部平台、开发者工具，我建议先别急着投放，也别急着写长篇大论。先让 AI 帮你补齐四张卡片。

1. 定位卡片

一句话说清楚：

这个东西给谁用，解决什么具体问题，和现有方案比少受什么罪。

如果这句话说不清，后面所有运营动作都会发虚。

2. 场景卡片

列出 3 个典型场景：

• 新用户第一次上手；
• 老用户遇到一个具体问题；
• 团队准备把它接入现有流程。

每个场景都要写“触发条件、操作步骤、预期结果、失败时怎么办”。这不是文案，这是产品的生存指南。

3. 证据卡片

证据可以是 benchmark、真实案例、用户反馈、减少的步骤、修复的问题、节省的时间。没有证据就写“尚待验证”，别硬编。

技术人其实很吃这一套：你不一定要热血沸腾，但你得给我一个相信你的理由。

4. 上手卡片

最小上手路径：

安装 -> 运行第一个例子 -> 看懂输出 -> 修改一个参数 -> 遇到问题知道去哪查

很多产品死在“看起来很强，但第一步走不通”。AI 可以帮你从新手视角扫 README，找出那些你自己已经习惯、但别人会卡住的地方。

GitHub 开源项目怎么推广和运营

开源项目的推广，千万别只盯着 star。

star 当然好看，像简历上的名校光环，不能说没用。但一个项目真正能活下来，靠的是另一组更朴素的东西：有人能看懂，有人能跑起来，有人愿意提 issue，有人敢交 PR，有人过了三个月还能回来继续用。

GitHub 项目运营，本质上是把“陌生人第一次路过”变成“他愿意试一下”，再变成“他愿意留下来”。这中间有一条漏斗：

路过 -> 看懂 -> 跑通 -> 产生信任 -> 提问/反馈 -> 贡献/传播

AI Skill 可以在每一层帮忙，但别让它替你假装项目很火。它应该做的是把项目的真实价值说清楚，把用户卡住的地方暴露出来，把维护者容易忘的运营动作定时提醒。

1. README 是门面，不是仓库说明书

很多 README 最大的问题，不是写得少，而是写得像内部交接文档。默认读者已经知道项目背景、使用场景、依赖关系和作者脑子里的上下文。

一个面向开源用户的 README，前 30 秒至少要回答四个问题：

• 这是什么？
• 谁会需要它？
• 和我现在的做法相比，它省了什么麻烦？
• 我怎么在 5 分钟内看到第一个结果？

可以让 AI 做一个 readme-first-impression Skill：把 README 当成陌生用户来读，输出“看懂了什么、没看懂什么、第一步会卡在哪里、哪些句子像内部黑话”。这比让 AI 直接“优化 README”靠谱，因为它先暴露问题，再谈改写。

2. 示例比愿景更会说话

技术人看开源项目，很少被宏大愿景打动，更多时候是被一个例子救了。

一个好 example 应该像餐馆门口的招牌菜：别把整本菜单都端出来，先让人尝到一口最有代表性的味道。

项目至少要有三类示例：

很多开源项目不是缺功能，而是缺“可复制的成功路径”。AI 最适合把成功路径写清楚。

3. Release Note 要讲用户故事

开源项目发版本，常见写法是：

v0.3.1
- fix bug
- update dependency
- improve performance

这当然没错，但读者看完也不知道该不该升级。

更好的 Release Note 至少补三句人话：

• 这个版本解决了谁的什么痛点？
• 升级后用户能少踩哪个坑？
• 有没有 breaking change、迁移步骤和回滚办法？

这里可以用 release-storyteller Skill：读取 changelog、merged PR、closed issue，生成面向用户的版本说明，同时标出“需要维护者确认的事实”。注意最后这句很重要，AI 不能替你确认兼容性承诺。

4. Issue 区是客服台，也是产品雷达

Issue 不是垃圾桶，也不是作者受刑场。它是开源项目最重要的运营入口之一。

一个健康的 issue 区，要让用户感觉到三件事：

• 这个项目有人维护；
• 我的问题有模板可以按；
• 哪些问题是 bug，哪些是使用咨询，哪些是 feature request。

AI 可以帮你做 issue-triage Skill：

## issue-triage Skill 输出

- 问题类型：bug / question / feature / docs / duplicate
- 是否缺少复现信息
- 建议标签
- 建议回复草稿
- 是否需要转成文档改进任务
- 是否暴露了产品定位问题

这件事看起来很琐碎，但长期价值很大。你每认真处理一个 issue，都相当于给后来者补了一块路标。

5. 贡献者漏斗要低摩擦

开源项目想有人贡献，不能只在 README 里写一句“Contributions welcome”。这话就像会议最后说“大家有问题随时找我”，通常等于没人找。

更有效的是给贡献者铺台阶：

• good first issue：真正适合新手，不是核心维护者懒得做的硬骨头；
• CONTRIBUTING.md：说明开发环境、测试命令、代码风格、提 PR 流程；
• CODE_OF_CONDUCT.md：社区基本规则；
• PR 模板：让贡献者知道要补测试、写说明、关联 issue；
• 维护者响应节奏：哪怕暂时没空，也给一个明确的下一步。

AI 可以定期跑一个 contributor-funnel-check Skill，检查这些文件是否存在、是否过时、good first issue 是否真的友好、PR 模板是否让人看得懂。

6. 推广渠道要匹配项目气质

不是所有项目都适合 Hacker News，也不是所有项目都适合在朋友圈刷屏。

可以按项目类型选择渠道：

AI 可以帮你把同一份材料改成不同渠道的版本，但渠道选择最好由人来定。因为“在哪儿说”本身就是判断力。

7. 一份 GitHub 运营 Skill 草稿

如果要把上面这些动作沉淀成 Skill，我会先写一个很朴素的版本：

---
name: github-open-source-growth-loop
description: Use when a GitHub open-source project needs README review, release packaging, issue triage, contributor onboarding, or weekly growth review.
---

# GitHub Open Source Growth Loop

## Inputs

- Repository URL or local repo path
- Target users
- Recent releases, issues, PRs, README, examples, and docs
- Promotion channels under consideration

## Workflow

1. Review the first-time user path:
   - README opening
   - installation
   - quick start
   - first successful output
2. Review trust signals:
   - license
   - release notes
   - tests
   - examples
   - issue response pattern
3. Mine recent issues and PRs:
   - repeated questions
   - missing docs
   - confusing API points
   - possible good first issues
4. Generate distribution assets:
   - short project pitch
   - release announcement
   - FAQ
   - demo outline
5. Produce next actions:
   - top 3 README fixes
   - top 3 docs/examples fixes
   - top 3 community/issue actions

## Quality Gate

- Do not invent stars, adoption numbers, users, benchmarks, or testimonials.
- Mark all unverified claims.
- Keep promotional copy specific, modest, and technically accurate.
- Prefer improving onboarding before asking for more traffic.

最后一句是关键：先修路，再拉客。

如果项目 README 还跑不通，issue 半年没人回，example 过期，安装命令一执行就报错，这时候推广做得越猛，反噬越快。运营不是给烂路刷油漆，而是先把坑填上，再把路牌立起来。

社交媒体创作怎么运营：知乎、小红书、小宇宙、抖音不是同一个厨房

很多人做内容分发，最容易犯的错误是：写完一篇文章，然后让 AI “改写成知乎、小红书、小宇宙、抖音版本”。

这句话听着高效，实际有点像把一锅红烧肉倒进四个盘子里，一个叫中餐，一个叫西餐，一个叫日料，一个叫短视频。盘子换了，菜还是那锅菜。读者一入口，就知道你是在跨平台搬运。

真正的社交媒体运营，不是把同一篇文章切成几段到处贴，而是保留同一个观点内核，重新设计入口、节奏和互动方式。

先放一张简表：

1. 先拆出“内容原子”

一篇长文里通常有很多东西：观点、故事、方法、清单、图表、金句、反例、工具模板。不要急着发，先让 AI 帮你拆成内容原子。

长文 -> 核心观点 -> 3 个痛点 -> 3 个故事 -> 5 个清单 -> 2 个争议点 -> 1 个行动模板

不同平台拿不同原子，不要一股脑全塞进去。

可以做一个 content-atomizer Skill：

## content-atomizer 输出

- 一句话核心观点
- 适合长文讨论的 3 个论点
- 适合短帖开头的 5 个钩子
- 适合图片卡片的 5 条清单
- 适合播客讨论的 5 个问题
- 需要作者亲自确认的事实和经历

这一步很重要。内容运营不是先问“我要发哪里”，而是先问“我手里到底有什么料”。

2. 知乎：原则是可信，方法是把问题讲透

知乎的读者通常不怕长，但怕空。

适合知乎的内容，不是“我有一个观点”，而是“我为什么形成这个观点，以及它在什么条件下成立”。尤其是技术、职场、产品类话题，知乎读者会天然追问：你凭什么这么说？有没有例子？有没有反例？有没有边界？

知乎运营有三个原则：

• 问题意识：标题最好像一个真实问题，而不是自我宣传；
• 经验支撑：观点背后要有场景、经历、案例或失败教训；
• 边界清楚：适用条件、不适用条件、反例要讲出来。

具体方法可以按这个结构：

• 标题：尽量像一个真实问题，不要像宣传语；
• 开头：先给一个判断，再交代自己的经验背景；
• 正文：用“观点 -> 场景 -> 例子 -> 反例 -> 建议”的结构；
• 结尾：给清单、模板或可执行步骤；
• 评论区：把高质量追问补回正文，形成二次迭代。

例如这篇文章发知乎，不必叫“用 AI Skill 给内容和产品装上运营循环”，可以换成：

技术人做开源项目和博客，为什么总是写完就没人看？AI 能帮到哪一步？

这个标题不一定华丽，但它像一个真实困惑，容易引出讨论。

AI 在知乎运营里适合做三件事：把长文改成问答结构，补出读者可能追问的问题，整理评论区里的高质量反驳。最不适合做的是凭空编“亲身经历”和“行业案例”。

3. 小红书：原则是可收藏，方法是卡片化

小红书不是不能发技术内容，但它对“入口”的要求更高。

读者不是坐在书桌前打开论文，而是在碎片时间刷到你。你得先让他知道：这条内容跟我有什么关系，值不值得收藏。

小红书运营有三个原则：

• 第一眼要具体：封面别写大词，要写场景、结果或痛点；
• 每张卡只讲一件事：一张卡塞三层逻辑，读者会直接划走；
• 给收藏理由：清单、模板、步骤、避坑点，比宏大观点更适合沉淀。

小红书版本要把抽象方法压成可视化卡片：

标题可以更生活化一点，但别装嫩，也别硬蹭情绪：

• “写了很多文章没人看？我用这个 5 步循环复盘内容”
• “开源项目没人用，不一定是代码差，可能是 README 第一屏输了”
• “技术人做内容运营，别一上来就追爆款”

AI 在小红书运营里的价值，主要是帮你把长文拆成“可收藏”的卡片脚本：每张卡一句标题、三条要点、一个例子。最后还要检查：有没有夸大承诺，有没有标题党，有没有不适合公开的公司/项目信息。

具体方法可以这样跑：

1. 先从文章里抽出 5-8 个“可保存”的点；
2. 每个点改成一张卡：标题、三条要点、一个例子；
3. 封面只讲一个钩子，不要把文章标题原封不动搬上去；
4. 文案末尾问一个轻问题，比如“你卡在哪一步”，不要硬要点赞关注；
5. 复盘收藏和私信问题，把高频问题补成下一组卡片。

4. 小宇宙：原则是可听，方法是把文章改成对话

小宇宙是播客平台，听众不是“看完”，而是“听完”。这完全是另一套体验。

一篇文章如果要变成播客，不是照着读一遍。那样听起来像念报告，主持人累，听众也累。

小宇宙运营有三个原则：

• 先有故事，再有观点：声音内容特别怕一上来就讲概念；
• 节奏要有坡度：开场、冲突、展开、回收，听众需要被带着走；
• shownotes 要能复用：链接、清单、模板、延伸阅读要放清楚。

播客版本适合改成对话提纲：

开场故事 -> 一个争议问题 -> 两三个真实场景 -> 方法拆解 -> 反例和边界 -> 给听众的行动建议

比如这篇文章可以拆成一期 25 分钟节目：

• 0-3 分钟：为什么技术人不爱运营；
• 3-8 分钟：酒香也怕巷子深，内容和产品都需要入口；
• 8-15 分钟：AI Skill 怎么把运营做成循环；
• 15-21 分钟：GitHub、知乎、小红书分别怎么做；
• 21-25 分钟：三条边界和一周行动清单。

AI 可以做 podcast-outline Skill：根据文章生成口播提纲、主持人问题、转场句、标题候选和 shownotes。但最终的语气最好人来调，尤其是你自己的经历、停顿、玩笑和判断，这些是播客的“活气”。

具体方法上，可以把每篇文章拆成一期 20-30 分钟节目，而不是追求一次讲完所有细节。播客的价值不是信息密度最高，而是让听众愿意跟你思考一段路。

5. 抖音：原则是单点突破，方法是短、准、能演示

抖音的逻辑跟前面三个平台都不一样。

知乎允许你慢慢铺垫，小红书允许你用卡片承载步骤，小宇宙允许你讲一段长故事。抖音不太等人。你前 3 秒没有让人知道“这跟我有什么关系”，后面写得再好也没人看见。

抖音运营有三个原则：

• 一个视频只讲一个点：不要把一篇文章压成一个短视频，那是压缩饼干，不是内容；
• 开头先给冲突或收益：痛点、反常识、错误示范、前后对比都可以；
• 能演示就别空讲：屏幕录制、代码前后对比、README 修改前后、数据面板变化，都比口号有用。

技术类内容在抖音可以这样拆：

比如这篇文章可以拆出几个抖音选题：

• “为什么你的开源项目没人用？先别怪算法，看看 README 第一屏。”
• “写文章没人看，可能不是文章差，而是你没有分发循环。”
• “AI 帮你做运营，第一步不是写文案，而是拆内容原子。”
• “一个技术博客，怎么改成知乎、小红书、抖音三个版本？”

AI 在抖音运营里适合做分镜脚本：开头 3 秒钩子、镜头/画面、口播词、字幕重点、结尾互动问题。人要负责判断：这个钩子会不会太夸张，演示是不是可信，是否泄露了不该公开的信息。

6. 四个平台，一套复盘指标

不同平台的指标也不能混着看。

每个平台都应该收回两个东西：用户问题和下一轮素材。

知乎评论里反复追问的地方，可能是下一篇长文；小红书收藏高的卡片，可能说明这个 checklist 值得扩写；小宇宙听众留言里的困惑，可能适合做一期 Q&A；抖音评论里反复问“怎么做”的地方，可能就是下一条演示视频。

7. 一份社交媒体运营 Skill 草稿

可以把社交媒体分发也做成一个 Skill：

---
name: social-media-content-loop
description: Use when a long-form article or product update needs to be adapted for Zhihu, Xiaohongshu, Xiaoyuzhou, Douyin, or similar social platforms.
---

# Social Media Content Loop

## Inputs

- Source article, notes, release note, or README
- Target platforms: Zhihu, Xiaohongshu, Xiaoyuzhou, Douyin, newsletter, team chat
- Target reader/listener
- Claims that must stay accurate
- Private or sensitive details that must not be exposed

## Workflow

1. Extract content atoms:
   - core claim
   - stories
   - checklists
   - examples
   - controversial questions
   - reusable templates
2. Generate platform-specific assets:
   - Zhihu: question-style title, long-form outline, answer draft
   - Xiaohongshu: cover title, card-by-card script, checklist copy
   - Xiaoyuzhou: episode title, talking outline, shownotes
   - Douyin: 3-second hook, storyboard, voice-over script, subtitle points
3. Add human review notes:
   - unsupported claims
   - places needing personal experience
   - possible over-promotion
4. Produce feedback plan:
   - metrics to watch
   - comments/questions to collect
   - next iteration candidates

## Quality Gate

- Do not fabricate numbers, comments, user stories, or endorsements.
- Do not turn technical content into clickbait.
- Preserve the author's real stance and voice.
- Adapt format for each platform instead of mechanically rewriting the same text.

这里的关键不是“多发几个平台”，而是让每个平台都成为一次用户研究。发出去不是结束，发出去才刚开始。

从 MDD 看运营：用度量驱动改进，而不是用数字折磨自己

我写过一本书叫《微服务之道：度量驱动开发》，里面反复讲一个观念：度量不是为了好看，也不是为了考核谁，而是为了让改进有方向。

这个思路放到内容和产品运营上也一样。很多运营动作失败，不是因为不努力，而是因为没有反馈系统。今天发知乎，明天发小红书，后天录播客，大后天剪抖音，忙得像救火队，最后只剩一句：“好像没什么效果。”

MDD 的思路会先问三个问题：

1. 我们想改善什么？
2. 用什么指标判断它有没有改善？
3. 指标变化之后，下一步动作是什么？

如果第三个问题答不上来，这个指标多半只是“仪表盘装饰品”。

1. 先定义北极星：到底要改进什么

运营指标不能一上来就铺满一张表。先选一个北极星指标。

内容和开源产品的北极星，不一定是播放量、阅读量、star 数。它更应该贴近你的真实目标：

一句话：北极星指标要靠近价值，不要靠近虚荣。

当然，虚荣指标不是完全没用。阅读量、播放量、点赞数像系统里的 QPS，能说明入口有没有流量。但 QPS 高不代表系统健康，播放量高也不代表内容建立了信任。

2. 再建漏斗：看用户在哪一步掉了

MDD 很强调从端到端链路看问题。运营也一样。

比如一个 GitHub 开源项目，可以拆成这条漏斗：

看到项目 -> 打开 README -> 跑 quick start -> 提 issue/收藏/star -> 二次使用 -> 贡献 PR

每一步都可以有度量：

社交媒体也可以建漏斗：

刷到 -> 停下 -> 看完/听完 -> 收藏/评论 -> 进入主页/链接 -> 复访/订阅

如果抖音 3 秒留存低，问题多半在开头；如果小红书曝光不错但收藏低，问题可能是卡片没有保存价值；如果知乎阅读不错但评论很水，可能是观点不够有讨论性；如果小宇宙播放高但完播低，可能是开场太长或者节奏太平。

没有漏斗，你只能笼统地说“效果不好”。有了漏斗，至少知道该修哪一段管道。

3. 用实验指标驱动小步快跑

运营改进不要一次改十个变量。

这跟排查线上问题一样：你同时改缓存、线程池、SQL、网络参数，最后性能上去了，也不知道是谁的功劳；性能下去了，更不知道是谁背锅。

一次运营实验只改一个主要变量：

• 标题实验：同一篇文章，比较问题式标题和方法式标题；
• 封面实验：小红书同一组卡片，比较“痛点封面”和“清单封面”；
• 开头实验：抖音同一主题，比较“错误示范开头”和“反常识开头”；
• README 实验：开源项目第一屏从“功能列表”改成“场景 + Quick Start”；
• 播客实验：小宇宙从“背景铺垫”改成“先讲冲突故事”。

每个实验都要提前写清楚：

假设：如果我把 README 第一屏改成场景 + Quick Start，新用户安装问题会减少。
指标：安装相关 issue 数、quick start 访问/复制次数、评论中的困惑点。
周期：观察 7-14 天。
决策：如果安装问题减少，就保留；如果问题转移到配置阶段，就补配置示例。

AI 可以帮你生成实验卡，但不能替你宣布实验成功。样本量太小、渠道变化、节假日、平台推荐波动，都会让数据带噪声。MDD 不是迷信数字，而是用数字逼自己少拍脑袋。

4. 加质量护栏：别为了指标把内容做坏

所有度量体系都有副作用。

如果只盯播放量，你会越来越标题党；只盯 star，你会越来越爱写炫酷 README；只盯日更，你会把内容写成流水账；只盯转化，你会把读者当漏斗里的沙子。

所以 MDD 里一定要有护栏指标：

好的运营不是单指标冲刺，而是多指标平衡。像开车一样，油门要看，刹车也要看，仪表盘亮红灯不能装没看见。

5. 把度量写进 Skill：让复盘自动发生

最后，度量驱动运营最好也沉淀成 Skill。

---
name: mdd-growth-review
description: Use when content, social media posts, GitHub projects, or product updates need a metrics-driven growth review.
---

# MDD Growth Review

## Inputs

- Content or product artifact
- Distribution channels
- Metrics snapshot
- User feedback: comments, issues, messages, reviews
- Previous experiment notes

## Workflow

1. Identify the north-star metric and the current goal.
2. Build a funnel from exposure to trust or reuse.
3. Map available metrics to each funnel step.
4. Detect the biggest drop-off or quality risk.
5. Propose one small experiment for the next cycle.
6. Define success metric, guardrail metric, observation period, and decision rule.

## Output

- North-star metric
- Funnel diagnosis
- Top 3 observations
- One recommended experiment
- Metrics to watch
- Human judgment required

## Quality Gate

- Do not over-interpret small samples.
- Do not optimize vanity metrics without guardrails.
- Do not fabricate metrics or user feedback.
- Always connect metrics to a concrete next action.

这个 Skill 的重点不是写漂亮周报，而是逼自己回答一句话：根据这组数据，下一轮到底改什么？

三个边界，别让 AI 把你带沟里

第一，不要虚构数据。

“提升 300%”“10 分钟上手”“被大量用户喜爱”这种话，如果没有证据，就不要写。AI 写起来顺手，读者看起来刺眼。

第二，不要骚扰式分发。

同一段话复制到所有群，只会消耗信任。好的分发应该像 API 设计：给不同调用方提供合适的接口，而不是把内部实现整个倒出去。

第三，不要把 AI 生成当市场判断。

AI 可以帮你整理反馈，但不能替你理解用户的沉默。很多真正重要的信息，藏在“他为什么没继续问”“他为什么装了又卸”“他为什么看了 README 还来找你”这些细节里。

运营最终还是人的工作。AI 负责把重复劳动降下来，人负责判断什么值得做。

明天就能做的最小动作

不用一下子搞一个完整增长系统。先做一个小循环。

• [ ] 选一篇已经写好的文章，提炼一句核心观点和三个目标读者问题。
• [ ] 用 long-to-short 思路，把它改成一段 200 字分享语、一个 FAQ、一个 README/文档入口。
• [ ] 发到一个真正合适的渠道，而不是所有渠道。
• [ ] 48 小时后收集反馈：评论、问题、私聊、阅读数据、转发语境。
• [ ] 记录一组基线指标：曝光、收藏、评论质量、链接点击、安装/运行问题。
• [ ] 用 feedback-miner 思路，把反馈整理成下一篇文章或下一次产品改进任务。

跑完一轮，你就会知道：原来运营不是玄学，也不是喊麦。它更像监控系统，只不过监控对象从 CPU、内存、QPS，换成了读者理解度、用户上手成本和信任积累。

总结

一句话：AI 不是内容和产品运营的魔法棒，它更像一套可以反复运行的脚手架。

好内容、好产品当然还是根。没有根，怎么推广都是塑料花。但有了根之后，还要有路径、有入口、有反馈、有复盘。否则酒再香，也可能只是你自己在巷子深处闻得很陶醉。

如果你已经开始写 Skill，不妨从最朴素的地方开始：别写“帮我火”，写“帮我把这篇文章改成三种读者能看懂的版本，并列出需要我亲自确认的事实”。这就够了。

运营不是把自己变成销售，而是让你认真做出来的东西，不再被沉默埋掉。

相关阅读

• Loop Engineering：别再手摇 AI 了，去设计那台摇柄
• 写 Skill 之前先想清楚的三件事

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。