多数上线效果不佳，是因为同一份文案被复制到每个渠道。一条 push 的注意力预算和一封 200 字的邮件完全不同，而应用内 banner 的阅读量又远超这两者。下面 15 个 Prompt 用同一份 feature brief 派生出渠道适配的变体——应用内 banner、push、邮件、社交（X / LinkedIn / Reddit 各异）、changelog、blog、press blurb——每个都守住同一核心承诺，同时遵守该渠道的字数上限与语气。
一句话总结： 先写真理源 brief（Prompt 1），再从它派生所有渠道。把应用内渠道放在第一位——SaaS 应用内消息平均带来约 24.5% 的功能采用率，而营销邮件点击率约 2.27%（ActiveCampaign / Userpilot，2026），采用真正发生在产品内。需要自然的创始人声音时用 Claude Opus 4.7 或 Sonnet 4.6；想用一个模型在同一会话里把七个渠道都构思、起草、复用一遍，就用 GPT-5.5。
适合哪些场景
组织多渠道上线的产品营销、自己发公告的创始人、跑生命周期 campaign 的增长团队、写产品内消息的内容设计师。
该用哪个模型来跑（2026 年 6 月）
- Claude Opus 4.7 / Sonnet 4.6——语气最自然、首稿改动最少的写作模型；LinkedIn 创始人帖、博客长文、以及任何要”像人写的”内容首选它。Sonnet 4.6 是主力，Opus 4.7 留给最高风险的文案。
- GPT-5.5——性价比最高的全能选手：每个渠道都够用，还能在同一会话里完成构思、列大纲、内容复用。语气审计和回顾这两个 Prompt 默认用 Thinking 模式。
- Gemini 3.1 Pro——结构化、brief 驱动的输出最强（表格、销售一页纸、渠道矩阵），也适合把很长的内部 spec 粘进它的 1M token 上下文。
无论用哪个，人工复审都不能省：实测里经人编辑的 AI 文案比原始输出好约 127%，而即便做过品牌语气调校的稿子，也要再过一次人工才能逼近纯人工水平的 5-10% 以内。
什么时候不建议这样写 Prompt
小 bug 修复不要用——只进 changelog。隐身功能（提前公告会伤上线）也不要用。
各渠道字数上限（2026 年 6 月实测）
写之前先把文案对齐到渠道。下面是硬上限和安全目标区间：
| 渠道 | 硬上限 | 安全目标 | 备注 |
|---|---|---|---|
| 应用内 banner | — | 标题 < 8 词 | 阅读量最高的渠道；动词开头 |
| Push 标题（iOS） | 全文 178 字符 | 标题 25-50 字符 | iOS 截断前约显示 4 行 |
| Push 标题（Android） | 标题 65 字符 | 标题 10-25 字符 | 正文可到约 240 字符，目标 40-60 |
| 邮件 subject | — | < 50 字符，约 6 词 | 手机端超过约 40 字符会被截 |
| 邮件 preview text | — | < 90 字符 | 收件箱里显示在 subject 旁 |
| 邮件正文 | — | < 200 词 | 1 痛点、1 方案、3 条要点、1 CTA |
| X 钩子推文 | 280 字符 | < 200 字符，不带链接 | 链接留到最后一条推文 |
| LinkedIn 帖 | 3000 字符 | 1200-1500 字符 | 创始人声音；AI 稿要重写 |
| Reddit 帖 | — | < 350 词 | 同行语气；带上已知限制 |
| Press blurb | — | 约 80 词 | AP 风格，不堆形容词 |
Prompt 结构公式
上线公告 Prompt 一定带这六个要素：
- 角色：让 AI 扮演谁（资深 PM / 独立创始人 / 产品设计师 / 独立开发者 / 增长负责人）。
- 上下文：阶段（想法 / MVP / 增长 / 规模化）、团队规模、流量或 ARR、平台（web / iOS / Android）、受众、限制。
- 目标：一个具体交付物——一段 PRD、一组用户故事、一个实验设计、一篇上线公告。
- 限制：时间线（本 sprint / 本季度）、要砍的范围、不能动的东西（现有流程、计费、合规）。
- 输出格式：表格、清单、可贴 ticket 的 JSON、或带标签的段落，能直接粘到 Linear / Notion / Jira。
- 示例 / 信号：1-2 份你欣赏的参考或竞品、加 1 个想避开的反例。
这套 Prompt 适合用在哪
- 多渠道功能上线
- Beta 转 GA 公告
- 主版本（v2.0）上线
- 集成 / 合作上线
- 弃用 / 替换公告
15 个可直接复制的 Prompt 模板
1. 真理源 feature brief
从这里开始。所有渠道变体都从这一份派生。
You are a product marketer. Generate a feature launch brief that becomes the source for all channel variants. Sections: (1) one-sentence promise, (2) who it is for, (3) what they could not do before, (4) what they can do now, (5) one specific example, (6) availability (date / tier / regions), (7) 3 banned words for this launch. Total 200 words.
Feature: [paste internal spec]可替换变量： feature spec
优化建议： brief 太泛时追加：“Every section must contain one concrete fact a competitor could not write — feature name, number, customer name, or specific workflow.”
2. 应用内 banner 文案（少于 8 字）
应用内是功能采用的主要来源，这里值得花最多时间打磨。
From this brief, write an in-app banner headline for [feature]. Less than 8 words. Action-led. No exclamation. Plus the matching 12-word subhead and a 2-word CTA. Output 3 variants for A/B testing.
Brief: [paste]3. Push 通知
From the brief, write a push notification for [feature]: title (less than 25 chars so it survives Android's 65-char cap and iOS truncation), body (less than 90 chars, target 40-60 for highest tap-through), deep link target. Make it feel earned, not spammy. Mark which user segment should receive it.
Brief: [paste]4. 邮件公告
From the brief, write an email: (1) subject line (less than 50 chars, ~6 words, benefit-led not feature-led), (2) preview text (less than 90 chars), (3) body (under 200 words) with: 1 sentence problem, 1 sentence solution, 3 bullets of what is new, 1 CTA button, 1 footer with link to changelog. Plus 2 alternative subject lines for A/B testing.
Brief: [paste]5. X / Twitter 公告线程
From the brief, write a 5-tweet thread launching [feature]. Tweet 1: hook (less than 200 chars, no link). Tweets 2-4: each one specific value (with one image suggestion). Tweet 5: where to start + CTA. Voice: builder-to-builder, not corporate.
Brief: [paste]6. LinkedIn 公告帖
From the brief, write a LinkedIn post (1200-1500 chars) for the founder: lead with the problem story, show 3 specific outcomes for customers, include 1 customer quote (mark as TBD if not available), close with the CTA. Voice: confident, slightly reflective.
Brief: [paste]7. Reddit / 社区帖
From the brief, write a Reddit post for [subreddit]. Voice: peer, not vendor. Acknowledge what the community has asked for, share what is new in plain terms, ask for feedback honestly, include known limitations. Less than 350 words.
Brief: [paste]8. Changelog 条目
From the brief, write a changelog entry. Format: H2 title (action verb + outcome), 60-word summary, 3-bullet "what changed" list with screenshots or GIF placeholder, 1-line "what is next" note. Voice: precise, useful for power users.
Brief: [paste]9. 博客长文
From the brief, write a 600-800 word blog post: (1) why we built this (problem context), (2) what we learned in beta, (3) how it works (with one screenshot suggestion), (4) what is next, (5) thanks to specific early users. Voice: builder team, not press release.
Brief: [paste]10. Press blurb
From the brief, write a press-friendly 80-word blurb for journalists: lead paragraph (what + why now), one quotable line from the founder, availability detail, contact link. Avoid hype language. Should read like AP-style copy.
Brief: [paste]11. 销售一页纸
From the brief, write a sales one-pager: (1) value statement (2 sentences), (2) 3 customer pain points it solves, (3) 3 talking points vs competitors, (4) discovery questions sales should ask, (5) common objections + answers. Format: tight, scannable.
Brief: [paste]12. 客成扩张邮件
From the brief, write an expansion email to existing customers in [segment] who do not yet use [related feature]. Frame the new feature as the missing piece. Less than 180 words. Include one personalized variable (last-used feature, role).
Brief: [paste]13. 弃用 / 替换公告
We are replacing [old feature] with [new feature]. Write announcements for: (1) email to affected users (200 words, with migration steps), (2) in-product banner (less than 25 words), (3) changelog (with timeline of deprecation). Voice: clear, takes responsibility for the transition.
Context: [paste]14. 渠道语气审计
Below are draft variants for the same launch across 6 channels. Audit voice consistency vs channel appropriateness: (1) same promise on every channel, (2) tone shifts appropriately (formal email vs casual X), (3) no copy-paste artifacts, (4) banned words honored. Score each variant 1-5 and rewrite outliers.
[paste variants]15. 上线后回顾模板
Two weeks after launch, write a retro template comparing predicted vs actual outcomes per channel: open rates, click rates, in-product adoption, social engagement, support volume impact. For each gap: 1 sentence hypothesis. End with 3 lessons for the next launch.容易踩的坑
- 一份公告复制粘贴到所有渠道。
- 用”我们激动地宣布”开头——浪费最被读的一行。
- 一次上线塞 4 个功能——稀释采用率。
- Changelog 里堆形容词（“革命性”）——重度用户一眼跳过。
- 忘了应用内渠道——多数采用来自产品内不是邮件。
- 替换功能时没出弃用公告——静默下架毁信任。
- 不做回顾——同一套打法继续用而不学习。
优化技巧
- 总是先写真理源 brief；每个渠道变体都派生它。
- 每个渠道注意力预算不同——邮件 subject 别拿来做 banner。
- 语气随渠道：LinkedIn 正式、X 随意、Reddit 同行。
- 应用内 + 邮件合力贡献多数采用——一个都别少。
- 社区帖一定带已知限制——诚实换好感。
- 渠道时序：应用内 + 邮件上线日；社交 48 小时铺开；博客一周内。
- 两周内必做回顾；不做就忘了。
设目标前，可拿外部基准对一下自己的数字：ActiveCampaign 2026 邮件基准 和 Userpilot 功能采用率指标指南。
FAQ
- 一次上线用几个渠道？: 大功能 6 个全上（应用内、邮件、社交、changelog、博客、press）。小改动 2 个（应用内、changelog）。不要给小事过度铺排。
- 所有渠道同一句话吗？: 同一承诺，不同表达。邮件 subject 目标约 6 词、少于 50 字符；应用内 banner 少于 8 词；push 标题少于 25 字符才能扛住 Android 的 65 字符上限。一句话套到三处，至少有一处会显得别扭。
- 哪个 AI 模型写上线文案最好？: 截至 2026 年 6 月，Claude Opus 4.7 / Sonnet 4.6 语气最自然、改动最少（LinkedIn 和博客用它），GPT-5.5 是单会话覆盖全部七个渠道的最佳全能选手，Gemini 3.1 Pro 在结构化表格和销售一页纸上最强。无论哪个都要过一遍人工。
- 提前多久公告？: 大功能提前 1-3 天预热，小的即时。别提前一个月——用户会忘。
- AI 能写创始人的 LinkedIn 声音吗？: 能起草不能直发。LinkedIn 必须由创始人用自己节奏改一遍。
- 怎么判断上线成功？: 看 14 天采用率，不是公告的 open rate。应用内消息平均带来约 24.5% 的功能采用，而邮件点击率约 2.27%——使用骗不了人，open rate 会。