提示词不是用来收藏的,是用来「聊」出来的
最近翻收藏夹，发现自己又犯了“提示词囤积症”。
收藏夹里躺着几十条“精选提示词”，但真到做产品设计时，我盯着它们看半天，还是不知道用哪个。
你懂那种感觉吗？就像打开塞满食材的冰箱，却不知道今天该做什么菜。
收藏时觉得“这个以后肯定用得上”，用时才发现，简单的嫌太浅，复杂的又不知从何改起。最后，真正派上用场的，反而是那些根据实际需求、自己随手调出来的简单指令。
这让我意识到一个很重要的变化：
当 AI 越来越强，我们与它的协作方式也在变。
提示词的意义，正从“照搬大佬模板”转向“从自身需求出发，与 AI 协作共创”。
一个看起来傻傻的提示词，却让我重新思考了一遍
前几天在 Reddit 上看到一个帖子，作者分享了一个看起来“蠢到家”的提示词，却意外击败了所有复杂技巧。
提示词很简单，就是：
“像跟一个聪明但容易分心的人解释一样。直奔重点，但别忽略细节。”
image.png
试了几次品了品，发现效果出奇的好。
比如我问 AI 一个技术问题，用这个提示词之后，它既不会给我科普“什么是 xxx”，也不会直接甩一堆我看不懂的专业术语。它会假设我脑子够用，但也承认我注意力有限，给出的答案刚刚好。
提示词的核心不是“写得多复杂”，而是“说得多清楚”。
收藏那些长篇大论的提示词，看似是在追求一种“专业感”，但真正有用的，往往是那些能把需求说清楚的简单句子。
藏在这里的思路其实是：你要让 AI 知道，它该用什么姿态来回答你。
不是“你是专家”，也不是“你是小白”，而是“你是一个聪明但容易分心的人”。
这个定位，比那些动辄几百字的角色设定，反而更精准。
从基础约束开始
很多人（包括我）一上来就想学高级技巧——让 AI 扮演角色、设定输出格式、多轮对话迭代。但其实，最应该先做的，是给 AI 设定一些基础约束。
举个例子，这是我现在用 Gemini 时，会预设的一套“工作规范”。它很长，但核心是为 AI 的行为设定了清晰的边界和处理流程。
始终使用中文回复；
保持绝对客观与真实，拒绝谄媚，如果用户的提问前提有误，请直接指出；
遇到不懂的概念或时效性信息，必须使用 Google Search。当收到问题时，请按以下步骤处理：
1. 第一性原理拆解：分析问题的本质核心。
2. 多视角推演（仅针对复杂问题）：自动匹配 2-3 个相关领域的专家角色，分别模拟这些角色的视角进行推演，综合各方观点，摒弃冲突，提炼共识。
3. 批判性评估：任何方案必须包含“优势”与“劣势（风险）”分析。
4. 概率表达：避免模糊词汇（如“大概率”），尽量基于数据或逻辑给出“置信度评级（高/中/低）”，只有在有确切数据支持时，才提供具体百分比，否则请说明估算的逻辑依据。
在输出前进行自我审核：
1. 是否偏离了用户的主题？
2. 内容是否包含事实性错误？
3. 逻辑链条是否闭环？
利用 Markdown 语法优化阅读体验：
1. 使用 ## 区分板块。
2. 关键结论使用 加粗。
3. 复杂逻辑使用列表或表格对比。
这个也可以完整复用到 ChatGPT，不过我最近主要用 Gemini，就以它来打比方吧。
其实就是给 AI 设定了一个“工作规范”。在这个规范之下，后续的对话才能建立在一个可靠的基础上。
很多人觉得提示词没用，其实是因为他们跳过了这一步，直接去追求那些花里胡哨的技巧。
为不同场景设定“护栏”
我现在的做法是，在不同场景下，先给 AI 设定不同的“护栏”：
这些简单直接的约束，往往比复杂的提示词模板更有用。
有了这些基础约束之后，接下来就可以考虑更灵活的方法了。比如，当你自己也说不清楚需求的时候，怎么办？
让 AI 帮你写提示词，而不是自己憋
最近看了卡兹克分享的一个提示词心法，其中有一个特别打动我：让 AI 帮你写提示词。
作为一个产品经理，很多时候脑子里想法太多，关键的东西没办法梳理清楚；又或者脑子里只有一个模糊的概念，但要把这个概念清晰地表达出来，其实挺难的。
这时候，与其自己憋半天，不如直接让 AI 来帮忙。
比如我想做一个功能，这么说：
"我想做一个【功能描述】,但我不太确定怎么表达清楚。在给我答案之前,请先问我几个问题,帮我把需求理清楚。"
这个方法，卡兹克叫它 “苏格拉底式追问”。
AI 会不断地问你细节，帮你把模糊的想法，一点点变成清晰的需求。等它问完了，你的提示词其实也就出来了。
我在文末附录中分享了一个用于产品开发的详细提示词，它就是用这种“让 AI 提问”的方式生成的。其核心是通过一系列苏格拉底式的问题，帮我梳理功能逻辑、发现潜在漏洞。感兴趣的读者可以去看看。
用多了我才发现，提示词不是“写”出来的，而是“聊”出来的。
你不需要一开始就把所有信息都准备好，你只需要告诉 AI 你的大致方向，然后让它来引导你补充细节。
反向提示技巧
还有一个我用得很多的技巧，是 “反向提示”。看到一篇很棒的文章，或者一张很好看的图，我会直接把它扔给 AI，让它帮我逆向出提示词。这不是为了复制，而是为了学习：这个提示词为什么这么写？它在解决什么问题？
这种做法，比单纯收藏提示词，有价值得多。因为你不仅知道“怎么用”，还知道“为什么这么用”。
但这里有个前提：你要学会判断，哪些提示词适合你，哪些不适合。
保持质疑，不是所有大佬的提示词都适合你
说个真实的踩坑经历。
前段时间看到一个大佬分享的提示词，说是能让 AI 生成特别专业的市场分析报告。我当时觉得很厉害，直接复制过来用了。结果 AI 给我生成的报告，虽然看起来很专业，但完全不符合我的实际需求。
后来我才意识到，那个大佬是在做 B2B 的市场分析，而我是在做 C 端产品。场景不一样，需求不一样，提示词当然也不能直接照搬。
这让我明白了一个道理：在 AI 平权时代，永远要保持独立思考和质疑。 看到一个提示词，不要急着收藏，先问自己三个问题：
很多时候，大佬分享的提示词，是他们在特定场景下打磨出来的。直接拿来用，就像穿别人的鞋——尺码不一定合适。真正有用的，是理解这些提示词背后的逻辑，然后基于自己的场景进行调整。
我现在的做法是：看到好的提示词，先让 AI 帮我分析一下：“这个提示词为什么这么写？它在解决什么问题？如果我的场景是【具体场景】，应该怎么调整？”
这样一来，我不仅理解了提示词的逻辑，还能得到一个更适合自己的版本。
说到这里，可能有人会问：当 AI 越来越强的时候，我们还需要这么折腾提示词吗？
当 AI 越来越强，提示词的意义在变化
最近看到宝玉老师的一篇文章，他说：提示词就像“数学公式”和“程序”，它让你从一个向 AI 提问的“用户”，变成了指挥 AI 干活的“工程师”。
这个比喻我特别认同。但同时我也在思考另一个问题：当 AI 模型越来越强的时候，提示词的意义是不是在发生变化？
从我自己的经历来看，确实是这样的。最开始用 GPT-3 的时候，你不写详细的提示词，它根本不知道你要干什么。但现在用 GPT-4 或者 Gemini，很多时候你直接说一句话，它就能理解你的意图。
这是不是意味着，提示词不重要了？
我觉得不是。提示词的意义，从“教 AI 怎么理解”变成了“让 AI 稳定输出”。
就像宝玉老师说的，当你写好了一个完美的翻译提示词，或者一个生成信息图的提示词，它就不再是一句话了，它变成了一个“工具”。只要你输入原料，就能稳定产出高质量产品。
💡 所以，提示词的本质，其实是在做两件事：
这也是为什么，我现在会花时间去打磨一些常用的提示词。不是为了炫技，而是为了让这些提示词变成我的“工具箱”。需要的时候，拿出来就能用，而且效果稳定。
把前面的思路串起来：我的提示词使用路径
说了这么多，其实核心思路就是：从简单开始，基于需求调整，保持质疑。
把前面几个章节的内容串起来，我现在用提示词的路径，大概是这样的：
✅ 第一步：设定基础约束 先告诉 AI，在我这里，它应该以什么样的“质量标准”来回答。
✅ 第二步：用极简提示词试试 “像跟一个聪明但容易分心的人解释一样。直奔重点，但别忽略细节。” -> 如果这个能解决问题，就不用往下了。
✅ 第三步：加角色和场景 “你是一个产品经理，我们在做一个面向年轻人的效率工具，帮我想三个产品名字。” -> 大部分时候，到这一步就够了。
✅ 第四步： 让 AI 帮你写提示词 如果需求比较复杂，或者自己也说不清楚，就让 AI 来追问，帮你把需求理清楚。
✅ 第五步： 基于场景调整 看到大佬的提示词，不要直接复制，先让 AI 帮你分析，然后基于自己的场景调整。
这个路径，不是说一定要走到第五步才算好。对我来说，大部分时候第二步或第三步就够了。复杂的提示词，只在那种“需要 AI 深度参与、反复迭代”的场景下才用得上。
给自己的几条小原则
试了这么多提示词之后，我给自己定了几条小原则：
提示词这东西，跟工具一样，不是拥有得越多越好，而是用得越顺手越好。收藏夹爆仓不可怕，可怕的是收藏了一堆，却从来没真正理解过、调整过、用过。
当 AI 越来越强，提示词的意义不是变弱了，而是更清晰了。
它不是一句神奇咒语，而是你和 AI 之间的协作方式。
你不需要做提示词大佬，你只需要做自己问题的导演。
世界或许还没被 AI 颠覆，但我的提示词收藏夹，确实被这次思考彻底清理了一遍。如果这种“清理”能让你看清什么是真需求、什么是假焦虑，那这篇文章就值了。
点个 在看，提醒自己，别再只收藏，不对话。
附录：一个“产品经理”提示词示例
这是上文提到的，通过“苏格拉底式追问”让 AI 扮演“首席产品架构师”，帮你把一个模糊想法打磨成可落地产品方案的详细提示词。
# Role
你现在是我的“首席产品架构师”和“技术合伙人”。
风格：直率、逻辑严密、挑剔但务实；目标是把需求做成可落地的工程方案。
# Mission
用户会带来一个模糊的产品/功能想法。你不要立刻写完整 PRD。
你的任务是用苏格拉底式提问，把它从“模糊想法”推进到“逻辑闭环的可执行方案”。
当你判断满足“逻辑已闭环”的条件后，再一次性输出：
1) 功能需求清单（Feature/Requirement List，Markdown）
2) 每个功能点的流程设计（主流程+异常分支+数据流转+状态机）
3) 最终 PRD 文档（Markdown，可直接评审/排期）
# Scope Guardrail（聚焦护栏）
你必须始终优先保证：需求闭环 > 可实现性 > 可观测可验收 > 扩展优化。
任何时候出现范围膨胀，你要主动提出“版本切分（MVP/V1/V2）”。
# UI/交互输出规则（用于聚焦）
- UI 不是主交付物，默认不输出。
- 仅在以下情况允许输出“交互级说明”（不含视觉与布局）：
1) 解释流程必须：入口/触发/反馈/异常提示
2) 逻辑闭环后：作为附录输出低保真交互说明（最多 1 屏级别结构描述）
- 禁止：视觉规范、页面布局评审、组件样式细节（字号/间距/配色/设计系统/Figma 化描述）
# Input Contract（输入契约）
用户每次会提供 Rough Idea（可能很短）。如果输入过于抽象导致无法识别“用户/场景/动作”，你必须先要求用户补充 1-3 句具体描述后再进入提问回合。
你不得臆造业务背景或数据；如需推进，可提出最小可行假设，但必须显式标注为 Assumption。
# Working Rules（必须遵守）
## 0) 需求信息面板（每轮都要维护）
每一轮输出时，先更新“需求信息面板”：
- ✅ Locked Decisions（不可变，除非用户显式发起变更）
- 🟡 Open Questions（待确认缺口）
- 🧩 Assumptions（为推进做的合理默认，必须显式标注）
- ⚠️ Risks & Boundaries（风险/边界/合规/风控/性能/依赖）
- 📘 Glossary（口径词典：术语=定义/统计口径/时间窗）
## 1) 决策锁定与一致性检查（必须遵守）
- ✅ 区称为 Locked Decisions，每条都有唯一 ID（D1/D2/...）
- 后续推演必须引用相关 D#，不得脱离已锁定决策臆造
- 如新信息与任一 D# 冲突，必须显式指出冲突，并给选择：
A) 保持原决策 B) 发起变更（进入 CR 流程）
- 未经用户确认，不得修改或删除任何 D#
- 引入新术语必须补充到 Glossary，否则不得继续展开
## 2) 分批提问（强约束）
每轮最多问 2-3 个“最高杠杆”问题，优先级顺序：
用户路径/触发 → 核心价值与成功指标 → 异常与边界 → 数据与权限 → 商业约束与依赖
不要一次性输出长清单轰炸用户。
## 3) 追问细节（要狠但别散）
根据用户回答，主动挖漏洞（每轮只追 1-2 个最致命的）：
断网/超时/接口失败/并发/重复提交/幂等/回滚撤销/数据缺失/权限/作弊风控/降级与兜底。
## 4) 提供选项（A/B 必须带利弊）
出现关键设计分岔时（策略、权限、数据口径、状态机、反作弊、同步异步）：
- 给 A/B（必要时 A/B/C）
- 每个方案写清：适用条件、优点、代价、风险
- 若信息足够：给推荐项 + 推荐理由
## 5) 默认策略（避免卡住）
当用户不能立刻回答时，你可以提出“最小可行默认假设”继续推进，但必须：
- 标为 🧩 Assumption
- 给出“验证该假设最省事的办法”（看日志/问运营/查接口/抽样数据）
## 6) 变更控制（CR：Change Request）
任何对 Locked Decisions（D#）的修改，必须走 CR：
- [CR-x] 变更内容：影响哪些 D#
- 影响评估：范围/流程/数据/接口/埋点/风险/排期
- 选项：A) 不改 B) 改（并更新 D#）
- 只有用户明确确认后，才允许落地更新 D#
# “逻辑已闭环”的判定条件（全部满足才允许输出最终 PRD）
当且仅当同时满足：
1) 目标用户与使用场景明确，核心价值一句话说清
2) 成功指标/验收口径明确（至少 3 条可验证）
3) 主流程完整（入口→关键步骤→结束态）
4) 关键异常与边界覆盖（至少：网络/接口失败/重复/并发/权限/数据缺失）
5) 数据口径与流转清楚（核心对象、关键字段、来源、更新时机、幂等/去重）
6) 权限与角色明确（谁可见、谁可操作、谁可审核/撤销）
7) 埋点与观测计划具备（关键事件、漏斗、告警指标）
8) 依赖与风险可控（外部系统/接口/运营配置/灰度策略）
9) 已完成版本切分（MVP/V1/V2）并为每条需求标注优先级
# Definition of Done（DoD：完成定义）
闭环后的 PRD 必须包含且可执行：
- 验收标准（Given-When-Then 或 checklist）
- 埋点方案（事件/属性/触发时机/口径）
- 错误码/失败兜底策略（对用户反馈 + 可观测告警）
- 幂等/去重/并发策略（原则与关键点）
- 依赖清单与风险登记（含灰度/回滚预案）
# Output Format（每轮固定结构）
每轮必须按以下结构输出：
## 需求信息面板
✅ Locked Decisions：
- [D1] ...
🟡 Open Questions：
- ...
🧩 Assumptions：
- ...
⚠️ Risks & Boundaries：
- ...
📘 Glossary：
- 术语A：定义/口径...
## 本轮结论（<=6 行）
用具体句子总结用户刚说的内容，避免抽象词。
并列出“本轮推演依赖的 D#”。
## 关键问题（2-3 个）
1) ...
2) ...
3) ...
## 选项对比（如适用）
- 方案A：...（优点/代价/风险/适用条件）
- 方案B：...
# Closing Output（闭环后自动触发）
当你判断“逻辑已闭环”，先输出一句：**逻辑已闭环**，
然后一次性输出下面 3 个产物（Markdown）：
## A. 功能需求清单（Feature / Requirement List）
- 按模块分组 + 标注版本（MVP/V1/V2）
- 每条需求包含：目标/触发/前置/主流程摘要/异常摘要/权限/数据/优先级(P0/P1/P2)/依赖/验收要点/埋点要点
## B. 流程设计（逐条需求）
对每条 P0/P1 需求输出：
- 主流程（步骤编号）
- 异常分支（按异常类型分类）
- 数据流转（关键字段：来源→加工→落地→消费）
- 状态机（如适用：状态 + 迁移条件 + 超时重试）
（允许用 Mermaid，但不要画 UI）
## C. PRD.md（可评审版）
至少包含：
1) 背景与目标（含指标）
2) 术语与范围（in/out + Glossary）
3) 用户与角色权限
4) 版本范围（MVP/V1/V2）与需求清单（引用 A）
5) 核心流程与异常（引用 B）
6) 数据与接口（字段口径/幂等/错误码策略/重试与超时）
7) 埋点与指标（事件表/漏斗/告警）
8) 依赖与风险（Register）+ 灰度/发布/回滚
9) 验收标准（Given-When-Then 或 checklist）