产品团队的 ChatGPT Prompt 工作流

很多团队把 Prompt 当“灵感放大器”，上来就问模型“帮我写一版完整方案”，结果拿到的内容看起来很全，实际没人敢直接用。根因通常不是模型不行，而是你没有先定义交付件。你到底要的是 PRD 的某个章节、发布公告、销售话术，还是客服 FAQ？这四种东西的结构、口径和审核人完全不同，混在一个请求里，必然得到“什么都沾一点，什么都不够用”的回答。

建议先写三行定义：给谁看、要解决什么问题、什么算完成。比如“面向渠道销售，目标是解释新套餐价值，完成标准是包含 3 个场景、2 个异议处理、1 个行动建议”。只要这三行没写出来，你后面再怎么调提示词，都是在模糊目标上做微调。

还有一个特别实用的小动作：在开工前先列“不能出现什么”。例如不能写未确认价格、不能承诺上线时间、不能使用绝对化措辞。很多翻车并不是“少写了”，而是“写了不该写的”。把禁区先写清楚，比后面救火轻松得多。

第一阶段只做探索，不追求文案好看。让模型先把目标、约束、已知事实、未知项列出来，尤其要逼它说“还缺什么信息”。你会发现很多本来以为明确的需求，其实关键字段都没给。这个阶段的价值是补齐输入，不是生成终稿。

第二阶段专注结构化草案。先确定目录和段落职责，再写具体句子。比如第一段交代背景，第二段给方案，第三段写风险和边界，第四段给行动建议。你先把骨架搭对，后面润色才不会在错误方向上越写越远。

第三阶段才是语言打磨：术语统一、语气一致、长度控制、删掉空话。这里有个常见误区是第一版就要求“像最终稿一样可发布”，结果一旦事实口径变了，前面所有精修都白费。把润色放到最后，不是偷懒，是减少返工。

很多团队流程卡在“快发了才拉人审”。产品说目标不对，法务说风险太高，运营说语气不匹配，最后所有意见同时砸回来。正确做法是把审核权责拆开：产品 owner 负责目标一致性，业务专家负责事实准确性，发布 owner 负责可上线性。每个人只对自己那一层拍板，效率会高很多。

审核反馈建议统一成三段式：问题是什么、影响是什么、建议怎么改。拒绝“感觉不太好”“读起来不顺”这类抽象评价。没有结构化反馈，作者只能猜，猜一次错一次，团队沟通成本会越来越高。

如果你们团队人多，建议每周做一次“被打回原因”归类。比如高频是口径不一致、数据来源不明、措辞过度承诺。把这些高频错误直接写进 Prompt 模板，下一轮自然会少掉大量无效往返。

发布前至少过三道闸：事实可溯源、承诺可兑现、表述符合合规边界。只要其中一道有疑点，就回到对应阶段重做，不要在终稿上“补丁式修词”。补丁能遮住表面问题，但遮不住逻辑漏洞。

我建议加一个特别有效的动作：反向提问。让模型自己指出“这份内容最可能错的三处”。这个动作看似简单，但对发现盲区很有用，尤其在数字、政策、流程类文本里，经常能提前暴露风险点。

质量闸门不等于流程臃肿。你只需要把最容易造成线上事故的 5-8 个检查项固定下来，谁负责、怎么判定、失败后回到哪一步，写成标准动作。只要这条链路固定，质量会比“靠经验把关”稳定得多。

最终交付不要只发正文。至少要附三样：前提假设、未决风险、Prompt 版本号。下一位同学接手时，第一眼就能知道这份内容在什么边界内成立，哪里可以复用，哪里必须重审。

建议按场景维护模板库，比如需求澄清、发布文案、销售答疑、客服回复。每类保留“高通过率首稿模板 + 复核清单 + 反例库”。首稿模板解决速度，复核清单守住底线，反例库防止重复踩坑，这三件套缺一不可。

再往前走一步，可以建立判例库：记录场景、最终采用版本、被否决原因和适用边界。团队新人遇到类似任务时，先查判例再起草，产出质量会明显更稳。真正成熟的 Prompt 工作流，不是某个人写得好，而是团队能持续复现好结果。