# 你的提示词都是在“许愿”
**作者**: Aomyying
**日期**: 2026-05-27T04:06:18.000Z
**来源**: [https://x.com/AomyYing/status/2059486326517580218](https://x.com/AomyYing/status/2059486326517580218)
---
我测试了 500 多个提示词，这 40 个每一次都能稳定产出专家级的结果。
收藏这条，你会用得上
大多数提示词合集都很泛泛。"帮我写一篇博客。""总结这段文字。""解释这个概念。"
那不叫提示词。那叫许愿。
一个真正的提示词是一套精心设计的指令，它能产出稳定、高质量、直接可用的结果——不管你用哪个模型。它包含了角色、上下文、约束条件、格式、质量标准，以及具体的示例。
这 40 个提示词在 Claude、ChatGPT 和 Gemini 上都能用。三个平台全部验证过。复制即用，无需修改。
按场景分类。标注了难度。建议先收藏再细读。
## 第一部分：写作与内容创作（01-10）
写作是 AI 最高频的使用场景，也是差距最大的场景。90% 的人用 AI 写出来的东西一眼就能看出来是 AI 写的——空洞、啰嗦、没有观点。剩下的 10% 用的就是下面这类提示词。
01. 专家级文章写手
> 你是一位曾为顶级媒体撰稿的资深内容策略师。请写一篇 [字数] 字的文章，主题：[话题]。目标读者：[他们是谁、他们知道什么]。切入角度：[你的独特主张——让这篇文章区别于同一话题下的所有其他文章]。结构：开头钩子：从一个大胆的主张或令人惊讶的事实开始。不允许泛泛的开场白。
> 问题：为什么当前对这个话题的认知是错误或不完整的。
> 框架：用 3-5 个有名称的章节呈现你的论点，每章有明确的小标题。
> 证据：每个章节包含一个具体的例子、案例研究或数据点。
> 行动：以读者本周就可以做的 3 件具体事情结尾。
> 规则：每段最多 3 句话
> 不使用填充语（"值得注意的是"、"在当今世界"）
> 不使用模糊措辞（"可能"、"似乎"、"某种程度上"）
> 每个论断必须具体，不能含糊
> 加粗每个章节中最重要的一句话
> 这篇文章应该达到不加修改就可以直接发布的标准。
使用建议： 这个提示词的灵魂在于「切入角度」那一步。不要写"关于 AI 对教育的影响"，而写"AI 不会替代老师——但会替代那些不会用 AI 的老师"。没有角度，就没有观点。没有观点，就只是一堆信息的重组，不是一篇文章。
02. 推特长帖架构师
> 写一个关于 [话题] 的 Twitter/X 长帖。长帖结构：第 1 条：钩子。大胆的主张、令人惊讶的数据、或反常识的观点。必须在 2 秒内让人停下滑动。
> 第 2-3 条：问题。为什么大多数人对这件事的认知是错的。
> 第 4-10 条：框架。编号的步骤、技巧或洞察。每条一个。每条既要能单独成立、又要在序列中自然衔接。
> 第 11-12 条：真实案例或案例研究，证明这个框架有效。
> 最后一条：一个可执行的要点 + 行动号召。
> 规则：每条不超过 280 个字符
> 不加标签
> 只有能增加含义时才用 emoji
> 不写"让我解释一下"、"事实上是这样的"——每条开头就是实质性内容
> 整体感觉应该是跟一个聪明的朋友学习，而不是读教科书
> 总计：12-15 条。
使用建议： 长帖的成败取决于第一条。如果第一条让人划过去了，后面写得再好也没人看到。所以第一条要花最多的精力打磨——一个反常识的观点、一个让人停下来的数据、一个直接击中目标读者的痛点。
03. 邮件撰写器
> 为以下情境起草一封邮件：[描述情境、收件人和你的目标]。语气：[专业/轻松/直接/外交]。规则：邮件标题：具体且行动导向（不要写"有个问题"或"跟进一下"）
> 开头：第一句话就直接说事。不写"希望这封邮件能找到你"。
> 正文：最多 3 个短段落。每个段落服务一个目的。
> 结尾：明确的下一步或请求。收件人应该清楚知道你要他们做什么。
> 总长度：150 词以内。
> 生成两个版本：版本 A：[语气 1——如直接果断]、版本 B：[语气 2——如温暖合作]。
使用建议： 150 词以内的限制是精髓。大多数人的邮件有 60% 的内容是废话——寒暄、铺垫、客气。砍掉这些，邮件回复率会明显上升。对方向你发送了一封需要决策的邮件，你回一个 500 词的邮件他反而更不想回了。
04. 内容多平台分发器
> 将以下内容改写成 5 种格式：
> <原始内容>[粘贴你的文章/帖子/转录]</原始内容>创建：Twitter/X 长帖（12 条，每条 280 字以内）
> LinkedIn 帖子（200-300 词，专业但不说教）
> 邮件通讯导语（100 词，引发对完整内容的好奇）
> 3 篇独立社交媒体帖子（每篇自包含，各突出一个不同洞见）
> 短视频脚本（60 秒，对话感，设计成对着镜头说）
> 规则：每种格式应该像是该平台原生内容，而不是复制粘贴
> 在所有格式中保持核心论点和关键洞察一致
> 按平台调整语气：X = 精炼直接，LinkedIn = 专业有深度，邮件 = 个人化、独家感
使用建议： 这是一篇长文 = 一周所有平台内容的秘密配方。周一花 30 分钟让 AI 跑完这个提示词，剩下 6 天定时发布。不要每条都重写——一次输出，多次复用。
05. 文案转化改写器
> 把这段文字改写得更具说服力：
> <原文>[粘贴文字]</原文>应用以下文案原则：先说好处，而不是先说功能
> 用具体数字替代模糊表述
> 在读者产生疑虑之前就主动化解
> 创造紧迫感，但不用操纵手法
> 以清晰、低门槛的行动号召结尾
> 展示改写后的版本，然后解释你做的 3 个最有影响力的修改，以及每个修改为什么在心理上有效。
使用建议： 最后那句"解释为什么有效"是这个提示词最有价值的部分。它不只是帮你改写——它在教你文案。每次用都是在免费上课。改写的效果你今天就能用，解释的原理你可以用一辈子。
06. 博文大纲生成器
> 为一篇关于 [话题] 的博文创建详细大纲。目标读者：[谁]。目标：[读者读完后应该做什么/感受到什么/理解什么]。目标长度：[字数]。每个章节提供：标题（有吸引力、具体、不泛泛）
> 2-3 句话概括本章内容
> 本章需要包含的关键数据、例子或论点
> 到下一章的过渡
> 同时包含：3 个备选标题选项（按预测点击率排序）
> 建议的 Meta 描述（160 字符以内）
> 5 个内链/外链机会推荐
使用建议： 这是内容团队的效率翻倍神器。不应该是"我写完了草稿再想想标题和 SEO"，而是"我在动笔之前大纲里已经有标题、Meta 描述和链接策略"。顺向流程的效率远远高于逆向修补。
07. 故事化转换器
> 把这段枯燥的事实性信息转化为一个有吸引力的叙事：
> <事实>[粘贴枯燥的事实、数据或技术内容]</事实>规则：从一个具体场景、人物或瞬间开始——不是从定义开始
> 把事实编织进一个故事弧线：铺垫 → 张力 → 解决
> 用类比让复杂概念变得直观易懂
> 包含一个"顿悟时刻"——读者的理解发生转折的那个点
> 以一个能将故事连接回读者生活的收获结尾
> 保持事实准确。改变的是表达方式，不是真相。
使用建议： 这是最有价值的提示词之一。数据告诉人，故事打动人。你用数据写的方案对方会看，你用故事讲的方案对方会记住。任何时候你想传递一个干巴巴的信息，先跑这个提示词。
08. 标题生成器
> 为以下内容生成 20 个标题选项：[简要描述内容]分类：5 个好奇心驱动的标题（让人必须点进去看看）
> 5 个利益驱动的标题（让人立刻看到价值）
> 5 个反常识标题（挑战读者目前的认知）
> 5 个具体数字标题（使用精确的数量或时间）
> 对每个标题，用 1-10 分评估其预测点击率并解释原因。给出你的 Top 3 排名及理由。
使用建议： 别挑你觉得最好听的。挑目标受众最可能点的那一个。这是两种完全不同的判断方式。如果拿不准，拿去问 AI："如果你是 [目标受众]，看到这 3 个标题你会点哪个？为什么？"
09. 案例研究构建器
> 将以下零散事实转化为有说服力的案例研究：
> 客户：[名称/类型]
> 问题：[他们遇到了什么问题]
> 解决方案：[实施了什么]
> 结果：[可衡量的成果]结构：挑战（2 段——让读者感受到痛苦）
> 方法（3-4 段——具体步骤，不是泛泛的描述）
> 结果（1-2 段——具体数字，前后对比）
> 关键收获（1 段——对读者有意义的教训）
> 引语（一句客户真的可能会说的话，基于结果来写）
> 规则：使用现在时增加临场感
> 包含至少 3 个具体数字
> 引语要让人感觉真实，不要像营销文案
使用建议： 案例研究是 B2B 领域转化率最高的内容形式，没有之一。但大多数人写不好——要么太干（全是数据像报告），要么太软（全是溢美之词像广告）。这个提示词给出的结构是经过验证的：先让人感受到"我也有这个问题"，再展示"原来可以这样解决"，最后用具体的数字和一句人话收尾。
10. 风格模仿器
> 分析同一作者的这 3 个写作样本：
> <样本_1>[粘贴]</样本_1>
> <样本_2>[粘贴]</样本_2>
> <样本_3>[粘贴]</样本_3>识别：句子长度模式（短句、混合、长句）
> 词汇水平（简单、技术性、混合）
> 语气（正式、随意、权威、对话式）
> 结构习惯（段落长度、标题使用、列表模式）
> 标志性短语或反复出现的模式
> 他们始终避免的东西
> 然后写一篇 300 词的关于 [新话题] 的文章，与这位作者的风格完全一致。读者应该以为这是原作者写的。
使用建议： 这个提示词的最高频场景不是"模仿别人"，而是"模仿自己"。把你的 3 篇代表作喂给 AI，让它提炼你的风格模型。以后写出来的东西就天然带你的味道。AI 是你的扩写器，而不是你的替代者。
## 第二部分：分析与策略（11-20）
写作搞定的是表达。分析和策略搞定的是思考。下面这 10 个提示词，让 AI 帮你做结构化思考——不是你问一句它答一句，而是它按一套完整的方法论来分析问题。
11. SWOT 分析器
> 对 [公司/产品/战略] 进行全面 SWOT 分析。对每个象限（优势、劣势、机会、威胁）：列出 5 个具体事项（不是泛泛的——与当前具体情境相关）
> 对每个事项：用一句话解释为什么它属于这个象限
> 评估每个事项的影响：高/中/低
> 然后提供：基于此分析的首选战略重点（一句话）
> 如果忽略这个重点，最大风险是什么（一句话）
> 本周要采取的第一个行动（一个具体、可执行的步骤）
使用建议： SWOT 的关键不是填满四个格子，而是最后那三个问题的答案。大多数 SWOT 做完后没人看，因为只有分析没有行动。这个提示词强制输出行动项。
12. 决策矩阵
> 我需要在以下选项之间做决定：[列出 2-4 个选项]
> 背景：[相关背景——预算、时间表、团队、目标]构建决策矩阵：识别出这个决策中最重要的 5 个标准（如果你不确定就问我）
> 按重要性对每个标准赋权重（加起来必须等于 100%）
> 针对每个标准给每个选项打分（1-10）
> 计算加权得分
> 以格式化表格呈现
> 然后写出 2 段的建议：明确说明选择哪个选项及理由
> 承认第二名选项的最强理由
> 指出哪个条件变化会让建议改变
使用建议： 人在决策时最大的问题不是一个选项明显好于另一个——那种不需要算。真正让你纠结的决策，通常几个选项打成平手。决策矩阵的作用不是"算出答案"，而是把隐性的权衡显性化。你一看那个表格，就知道自己内心的天平其实已经偏向了哪一边。
13. 根因分析器
> 我面临一个问题：[描述问题及其症状]进行根因分析：依次追问"为什么？"5 次（5 Whys 方法），每次往更深层挖
> 每一层判断这是症状还是根因
> 在最深层级，识别出真正的根因
> 提出 3 个解决方案——一个针对表面症状、一个针对中层原因、一个针对根本原因
> 给出建议：应该实施哪个方案、为什么
> 不要假设我对问题的初步描述就是对的。真正的问题通常不是我描述的那个。
使用建议： 这个提示词里最有价值的一句话是最后那句——"不要假设我对问题的初步描述就是对的"。人类描述问题的水平很差。你说"我没办法专注"——可能是你手机在旁边，也可能是你对在做的事根本不感兴趣，也可能是你睡眠不足。你描述的是感受，不是原因。AI 的"5 Whys"会一层层剥开。
5 Whys 示例：
1. 为什么没按时交付？→ 因为开发进度延迟了
2. 为什么开发进度延迟？→ 因为需求中途改了三次
3. 为什么需求会改三次？→ 因为评审会上客户方决策人没来
4. 为什么评审会决策人没来？→ 因为没人提前确认他的时间
5. 为什么没人确认时间？→ 因为没有项目启动前的干系人确认流程
从"开发太慢了"到"我们需要一个干系人确认流程"——这就是 5 Whys 的价值。
14. 市场机会扫描器
> 分析 [产品/服务创意] 的市场机会。评估：需求：谁想要这个？有多少人？你怎么知道他们想要？
> 竞争：还有谁在做？他们收多少钱？他们的弱点在哪里？
> 时机：为什么是现在？有什么变化让这件事在今天可行而在以前不行？
> 护城河：有什么能阻止竞争对手在 6 个月内复制你？
> 单位经济模型：单个客户交付成本 vs 可能收费是多少？
> 每个部分：要具体、尽量用数字、标注你不确定的任何信息。以 GO / 谨慎 GO / NO GO 的建议结束，并给出你的置信度（高/中/低）。
使用建议： "时机"那个问题是真正的杀手锏。大部分创业想法不是想法本身有问题，是进来得太早或太晚。"有什么变化让这件事在今天可行"——AI 工具的出现让一个人也能做以前需要团队才能做的事？政策变化？技术成本下降？如果你回答不了这个问题，你还没有真正理解自己的机会。
15. 会议策略师
> 我有一个关于 [话题] 的会议，对象是 [谁——他们的角色、与你的关系、他们在乎什么]。我在这场会议中的目标：[你想要达成的结果]。准备：开场白（2 句话——为对话设定正确的框架）
> 我必须传达的 3 个关键点（按优先级排序）
> 我应该问的 3 个问题（从最重要到最不重要排序）
> 对方可能提出的 3 个异议及我的回应
> 理想结束语（总结共识和下一步）
> 底线：我可接受的最低结果是什么？
使用建议： 大多数人准备会议的方式是"我大概知道我要说什么"。这个提示词逼你在会前写出来——不只是你要说什么，还有对方可能说什么、你的底线在哪。第 4 项和第 6 项是决定会议成败的关键。没有预判异议就进会议 = 裸奔。没有想好底线就进谈判 = 你不知道自己在哪一步输了。
16. 定价策略师
> 帮我为 [产品/服务] 制定定价方案。背景：它做什么：[描述]
> 目标客户：[目标客户]
> 交付成本：[你的成本]
> 竞品定价：[竞品价格，如已知]
> 交付的价值：[客户获得什么——节省的时间、赚到的钱、解决的问题]
> 设计定价结构：三个梯次（入门、核心、高级），用反映价值的名称，不是大小
> 每个梯次包含什么，以及为什么在这些地方设置分界
> 每个价格点背后的心理逻辑
> 大多数客户应该在哪个梯次落地，以及如何引导他们到那里
> 一次性 vs 订阅分析——哪种模式更合适，为什么
> 以格式化对比表格展示定价方案。
使用建议： "哪个梯次大多数客户应该落地"和"如何引导他们到那里"是定价策略中最被低估的两个问题。中间的梯次是你的利润引擎——定价太低你活不下去，定价太高没人进来。中间梯次的设计要把"稍微加点钱就能多拿很多价值"的逻辑做到最明显。
17. 竞品拆解
> 对 [竞品名称/网址] 进行竞品拆解。分析：定位：他们的核心信息是什么？他们的目标客户是谁？他们在卖什么情感？
> 产品：他们实际提供什么？核心功能 vs 锦上添花的功能？
> 定价：他们怎么收费？每个梯次包含什么？利润在哪里？
> 内容：他们发布什么话题？频率？什么格式表现最好？
> 弱点：他们在哪里脆弱？他们的客户抱怨什么？他们没有在做什么？
> 以"如果我要和 [竞品] 正面竞争，我会做的 3 件不一样的事是……"结束。
使用建议： 最后一个问题才是这个提示词的目的。前面 5 个分析都是为了回答那 3 件不一样的事做铺垫。如果你的答案没有指向"他们漏掉了什么"或"有一群人他们没服务好"，那你就在做一模一样的产品——而一模一样的产品只能靠拼价格赢，那是最差的赢法。
18. OKR 构建器
> 帮我为 [团队/个人/公司] 制定 [时间段] 的 OKR。背景：[当前状况——我们在哪里、想去哪里、有什么资源]对每个 Objective（建议 3 个）：Objective：有雄心但可实现、定性描述、能激励人
> 3-4 个 Key Results：具体、可衡量、有时间限制
> 对每个 Key Result：当前基线、目标值、衡量方式
> 可实现置信度（1-10 分）：该 Key Result 在时间范围内是否可达
> 标注可能相互冲突的 Key Results。
使用建议： 最后一句"标注可能冲突的 KR"是最容易漏掉的关键。你设定了一个"发布 3 个新功能"和"客户 NPS 提高 10 分"的 KR——这两个可能是冲突的，因为发布了没经过充分打磨的功能反而会拉低 NPS。冲突检测让你的 OKR 从"愿望清单"变成"真正的战略对齐"。
19. 风险评估器
> 我即将 [描述项目/决策/计划]。进行风险评估：列出最可能出现的 7 个风险（可能出问题的地方）
> 对每个风险：概率：高/中/低
> 如果发生，影响大小：高/中/低
> 早期预警信号（我怎么发现这个风险正在变成现实？）
> 缓解策略（我做什么来预防它发生？）
> 应急预案（如果真的发生了我怎么办？）
> 画一个 2x2 矩阵把风险分类（概率 vs 影响）
> 指出我应该主动监控的前 3 大风险
> 悲观一点。我想听到的是我没有考虑到的风险，而不是安慰我一切都会好的。
使用建议： 倒数第二句是这个提示词的秘密——"悲观一点"。大多数人在让 AI 评估风险时，AI 默认输出是中性的、圆滑的、不得罪人的。但风险评估的价值恰恰在极端情况。"这事可能 90% 不会发生，但如果发生了就完了"——你需要的正是对那 10% 的认真对待。
20. 复盘引导师
> 引导这个项目/时间段的复盘：[描述发生了什么]结构：什么做得好（找出 5 件确实有效的事，附证据）
> 什么出了问题（找出 5 件确实没效果的事，附根因）
> 我们学到了什么（3 个会改变我们未来工作方式的教训）
> 我们会做什么不同的事（3 个具体的、可执行的改变——不是模糊的意图）
> 我们会停止做什么（2 件我们应该刻意停止的事）
> 规则：必须具体。"沟通不好"是没用的。"产品团队在定价变动前 2 天才被通知，导致营销材料来不及更新"是有用的。
> 每个识别出的问题，包含一个具体的预防措施。
使用建议： 第 5 部分"停止做什么"是 90% 复盘里没有的。大家都在加——加流程、加检查、加文档。但没有人问"我们应该停止做什么"。真正让团队变高效的不是做得更多，是停止做那些已经不产生价值的事。这条规则的威力在于它强制你砍掉东西。
## 第三部分：技术与开发（21-28）
这一组是给写代码的人准备的。如果你不写代码，可以跳过去看第四部分。如果你写代码，这些提示词能替代你 60% 的"搜 Stack Overflow → 看文档 → 试 → 报错 → 再来一次"循环。
21. 架构顾问
> 我想搭建 [描述系统]。需求：[需求 1]
> [需求 2]
> [需求 3]
> 预期规模：[用户数/数据量]
> 预算限制：[任何限制]
> 提出 2 个架构方案。对每个方案：组件图（用文字描述——列出每个服务/模块及其连接方式）
> 技术选型和每个选择的理由
> 优缺点（诚实说明取舍）
> 预估复杂度：简单/中等/复杂
> 这个方案最可能出问题的那一件事
> 推荐一个方案。解释理由。然后给我前 5 步的实施步骤（按顺序）。
使用建议： "这个方案最可能出问题的那一件事"是照亮盲区的灯。每个架构方案都有一个阿喀琉斯之踵。在写第一行代码之前就知道它在哪里，比上线那天凌晨 3 点才发现要便宜一万倍。
22. 代码审查员
> 审查这段代码：
> [粘贴代码]检查以下方面：安全：注入漏洞、暴露的密钥、XSS、不安全的数据库处理
> 逻辑：未处理的边缘情况、错误的逻辑判断、差一错误
> 性能：N+1 查询、不必要的计算、遗漏的缓存机会
> 可读性：不清晰的命名、复杂逻辑缺少注释、过度嵌套
> 最佳实践：违反语言规范、缺少错误处理、未使用的导入
> 对发现的每个问题：严重程度：严重/高/中/低
> 精确位置（行号或函数名）
> 为什么这是问题（不只是哪里错了，而是可能导致什么后果）
> 修复方案（展示修正后的代码）
> 如果代码本身没问题，就说没问题。不要为了显得全面而编造问题。
使用建议： 最后那句"如果没问题就说没问题"是关键。很多人在审查时忍不住要找点问题出来——不管是人还是 AI。但这会让审查失去可信度。好的审查像好的安检：有问题必须拦住，没问题快速放行。每一次"没问题"的反馈都在积累信任。
23. Debug 诊断器
> 我遇到这个错误：[粘贴完整的错误信息和堆栈回溯]
> 上下文：[这段代码应该做什么]不要立刻跳到修复方案
> 首先：用日常语言解释这个错误消息是什么意思
> 其次：按概率从高到低列出 3 个最可能的根因
> 第三：对每个可能原因，解释什么样的证据可以确认它
> 第四：在确定根因后，展示修复方案
> 第五：解释什么措施可以避免这类 bug 在将来再次出现
> [粘贴相关代码]
使用建议： 步骤 1 "不要立刻跳到修复方案"是反人性的——人类遇到 bug 的第一反应就是试各种修法。但这是最低效的调试方式。理解错误→提出假设→验证假设→修复→预防。这套流程让每一次 bug 修复不只是修了一行代码，而是在你的知识体系里补了一个洞。
24. API 设计器
> 为 [描述系统/功能] 设计 REST API。对每个端点：方法和路径（遵循 REST 规范）
> 请求体 Schema（标注必填/可选字段）
> 响应体 Schema（成功和错误情况）
> 鉴权要求
> 速率限制建议
> 同时包含：错误响应格式（所有端点统一）
> 列表端点的分页方案
> 版本管理策略
> 3 个潜在安全问题及应对方案
> 以格式化 API 参考文档形式呈现。
使用建议： API 设计最难的不是"让功能跑通"，而是"一致性"。6 个月后新加入的工程师能不能不看文档就猜出这个 API 的写法和返回格式？这个提示词通过强制规定错误格式、分页方案、版本策略，让一致性从一开始就被内建到设计中。
25. 数据库 Schema 设计器
> 为 [描述应用] 设计数据库 Schema。需求：[列出关键实体和关系]
> 预期规模：[数据量和增长速度]
> 对每张表：列及其类型、约束、描述
> 主键和索引
> 外键关系
> 同时提供：实体关系描述（表之间如何连接）
> 该 Schema 必须高效支持的 3 个常见查询
> 支持上述查询的索引建议
> 一个潜在的性能瓶颈及应对方案
> 如果后期需求变化，如何进行迁移的策略
使用建议： "如果后期需求变化怎么迁移"是资深工程师和新手的分水岭。新手设计 Schema 只想"现在怎么存"。老手想的是"三个月后如果加一个 XX 功能，这个结构改起来痛不痛"。这个问题让 AI 帮你做完 Schema 设计的压力测试。
26. 测试用例生成器
> 为以下函数/功能生成完整的测试用例：
> <代码或描述>[粘贴代码或描述功能]</代码或描述>测试分类：正常路径：3 个正常预期使用的测试
> 边界情况：5 个边界条件、空输入、最大值的测试
> 错误情况：3 个无效输入、缺失数据、系统失败的测试
> 安全性：2 个注入尝试、未授权访问的测试
> 性能：1 个负载或大数据集下行为的测试
> 对每个测试：测试名称（描述性）
> 输入
> 预期输出
> 为什么这个测试重要
使用建议： 大部分自测文件写了 10 个"正常路径"测试，0 个"传了个负数进来怎么办"的测试。正常路径的测试告诉你代码能在晴天行驶。边界和错误的测试告诉你它会不会在下雨天翻车。用户的实际行为不是正常路径——用户会在输入框里塞一个富文本、传一个超长字符串、或者在网络断了的瞬间反复点按钮。
27. 文档撰写器
> 为以下代码/API/系统撰写开发者文档：
> <代码或规范>[粘贴代码或规格说明]</代码或规范>包含：概览（这个是什么、为什么存在——2-3 句话）
> 快速上手（5 分钟内跑起来）
> 核心概念（解释心智模型，不只是 API 表面）
> API 参考（每个公开函数/端点，包含参数、返回值、示例）
> 常见模式（3 个典型用法模式，附代码示例）
> 故障排除（5 个常见问题及其解决方案）
> 写给一个聪明但从未见过这个代码库的开发者看。
使用建议： 大多数文档的问题是：它写的是"这个 API 怎么用"，而不是"这个系统的思维模型是什么"。前者是字典，后者是地图。新来的开发者需要的是地图——告诉他系统是怎么想的，东西放在哪里、数据怎样流动。这个提示词的第三部分"核心概念"解决的问题就是：先给地图，再给字典。
28. 重构规划器
> 这段代码需要重构：
> [粘贴代码]分析：前 3 个代码质量问题是什么？（重复逻辑、职责混杂、不必要的复杂）
> 对每个问题：解释为什么这是一个问题，而不仅仅是"它存在"
> 提出重构方案，按顺序列出具体步骤
> 每步：展示重构前后的代码对比
> 验证重构后的代码保持了完全相同的外部行为
> 评估影响：这次重构对可维护性、可读性、可测试性有多大提升？
> 不要改变外部行为。只做内部改进。
使用建议： "不要改变外部行为，只做内部改进"是重构的铁律。这也是为什么重构需要测试覆盖——如果你没有测试，你就不知道你改完之后外部行为还一不一样。重构前先让 AI 给这段代码生成测试用例（用提示词 #26），重构后用同样的测试验证。
## 第四部分：生产力与个人效能（29-32）
29. 周计划制定器
> 以下是我这个季度的目标：[列出目标]
> 以下是我上周完成的事：[简要总结]
> 以下是我本周的承诺：[会议、截止日期、固定事项]创建我的周计划：最重要的 3 件事（对季度目标贡献最大的事）
> 日程安排（按天列出的会议和截止时间）
> 缓冲任务（重要但时间灵活的事）
> 刻意跳过（我本周选择不做的事以及原因）
> "刻意跳过"部分是最重要的。说"不"是优先事项之所以能是优先事项的原因。
使用建议： 你的周计划里如果没有"不做什么"，就等于没有排优先级。人的时间不是无限的——你说"这些都是优先"就等于"没有一个是优先"。刻意跳过的列表是你在对自己的时间说：我知道这件事也重要，但我选择不做它，因为那件事更重要。
30. 学习加速器
> 我想学习 [话题/技能]。当前水平：[初级/中级/高级]。可用时间：[每周多少小时]。学习风格：[实践/理论/混合]。目标：[学完后我能做什么]。创建学习计划：前置知识：我需要先知道什么？（如果我缺少基础，请诚实告诉我）
> 核心概念：必须掌握的 5-7 个关键概念，以及我应该按什么顺序学习它们
> 项目：对每个概念，一个能通过动手实践来掌握的练习项目
> 资源：对每个概念，最好的单一资源（不是 10 个选项——一个）
> 验证点：我怎么知道我真的理解了这个概念？（具体测试，不是"感觉熟悉了"）
> 时间线：基于我的可用时间，切合实际的按周学习计划
> 不要填满计划。如果我可以在 3 周内学会，不要拉长到 8 周。
使用建议： 第 4 点"每个概念只给一个最好资源"是这个提示词里最反人性的也最有用的设定。大多数人的学习方式是：收藏 30 个教程 → 打开 3 个 → 哪个都没看完 → 觉得自己学不会。单一最佳资源强迫你做选择、强迫你走到底。一本好书读三遍远好于三本书各读一章。
31. 谈判准备器
> 我即将跟 [谁] 谈判 [什么事]。背景：[相关背景——关系、历史、权力动态]
> 我的理想结果：[最好的情况]
> 我的可接受结果：[我能接受的最低限度]
> 他们的可能立场：[他们大概想要什么]准备：我的开局立场及背后的理由
> 我可以做出的 3 个让步（从最小到最大排序）
> 每个让步我应该要求对方回报的 3 样东西
> 对方最可能的 3 个异议及我的回应
> 2 个能给双方创造更多价值的创意选项（把饼做大）
> 我的离开底线，以及如果我需要优雅退出时使用的准确措辞
使用建议： "2 个能扩大蛋糕的创意选项"把谈判从零和博弈变成了合作创造。最好的谈判不是分 100 块钱——是找到办法让桌上变成 200 块。你帮对方省了时间、你能接受他们不在意的条款、你提供了一个他们想都没想过的交换条件。让 AI 帮你想这些创意选项——它不受你的利益立场限制。
32. 习惯设计器
> 我想培养这个习惯：[描述习惯]。我的日常作息：[典型的一天是什么样的]。过去的尝试：[以前试过什么、为什么失败了]。设计习惯实施方案：这个习惯的最小可行版本（2 分钟启动版）
> 触发点：我把它挂载到现有的哪个习惯或事件上？
> 环境设计：什么样的物理改变能让这个习惯更容易做？
> 奖励：什么即时正向反馈能强化这个习惯？
> 追踪方式：我怎么衡量连贯性？
> 失败协议：某天没做到时我应该怎么办？（因为我肯定会有一天没做到）
> 渐进：2 分钟版如何在 4 周内逐步成长？
> 现实一点。我宁愿培养一个能坚持下来的小习惯，也不愿设计一个完美的方案然后一周就放弃。
使用建议： "失败协议"是整个提示词里最重要的设计。养成习惯的敌人不是难度，是"断了一次就觉得自己失败了然后彻底放弃"。你需要提前写好在断掉一天之后该怎么办——是第二天直接继续、不需要补、不需要自我惩罚。这个协议的心理学本质是把"连续"偷换成"频率"。不是不能断，断一天不算失败，两天以上才算。
## 第五部分：数据与研究（33-35）
33. 数据解释器
> 分析以下数据：
> <数据>[粘贴数据——CSV、表格、数字、调查结果等]</数据>提供：汇总统计（关键数字一览）
> 最重要的 3 个模式或趋势
> 2 个不是一眼能看出来的令人惊讶的发现
> 1 个这个数据中可能被误读的地方（什么可能被错误地解读？）
> 3 个这个数据引发、但需要更多数据才能回答的问题
> 受众：[谁会读这份分析、他们的技术水平如何]先用日常语言讲清楚发现，再附上支撑数据。
使用建议： 第 4 点"可能被误读的地方"是所有数据分析里最被低估的输出。同样的数据，不同的人读出来完全相反的结论——相关不等于因果、平均值掩盖了分布的形状、百分比的基数变了。AI 帮你提前踩坑，让你的分析不是"自说自话"，而是经得起别人的挑战。
34. 调查分析器
> 分析这些调查结果：
> <调查数据>[粘贴调查回复]</调查数据>提供：受访者群体的关键人口统计/细分特征
> 按显著程度排名的前 5 个发现
> 共识区域（受访者在哪些地方高度一致）
> 分歧区域（观点在哪些地方出现分裂）
> 与普遍假设相矛盾、令人惊讶的发现
> 基于数据的可执行建议（3 件具体要做的事）
> 这个数据的局限性（样本量、偏差、我们无法得出的结论）
使用建议： 最后第 7 点的"数据局限性"是职业道德级别的要求。你做了一个 200 人的问卷调查，你不能说"全行业都这么认为"。标注局限性不是弱化你的结论——是你告诉读者"我知道我的边界在哪"。这恰恰在建立你的可信度。
35. 研究综合器
> 我从多个来源收集了关于 [话题] 的研究资料：
> <来源_1>[粘贴或摘要]</来源_1>
> <来源_2>[粘贴或摘要]</来源_2>
> <来源_3>[粘贴或摘要]</来源_3>综合：所有来源中的共同主题（它们在什么上面达成一致？）
> 矛盾点（在哪些地方意见有分歧？谁更可信、为什么？）
> 空白（哪些问题仍然没有答案？）
> 我可以确信的最重要的 3 个结论
> 我应该下一步研究什么来加强我的理解
> 不要只是把每个来源单独总结一遍。我需要真正的综合——跨来源的连接和规律，这些是单独阅读每份资料看不出来的。
使用建议： 最后一句"不是单独总结，而是跨来源的综合"是这个提示词的核心。大多数人的"文献综述"实际上是"文献堆砌"——A 学者说了 X，B 学者说了 Y，C 学者说了 Z。但读者真正想知道的是：这三个人合在一起告诉我什么？他们在哪里打架了？在哪里其实说的是一回事但用不同的词？合成 = 创造新信息。这个新信息在你喂进去的任何一份单独材料里都不存在。
## 第六部分：沟通（36-40）
沟通是最被低估的 AI 应用场景。大多数人用 AI 写文章、做分析、写代码——却忘了每天消耗最多心力的是跟人说话。尤其是那些难说的话。
36. 困难对话准备器
> 我需要跟 [谁——角色、关系] 进行一次困难的对话，关于 [话题]。情况：[发生了什么、为什么这次对话是必要的]。我的目标：[我想要达成的结果——不只是我想要说什么]。对方可能的反应：[我预期对方如何回应]。准备：开场白（直接但有同理心——不回避问题，但也不攻击对方）
> 核心信息用一句话（不管对话怎么展开，这条信息必须被传达）
> 如何应对防御性反应（针对性回应"这不公平" / "你错了" / 情绪化反应）
> 如何主动倾听（我该问什么问题来理解对方的视角）
> 如何达成解决方案（3 个可能结果，从最佳到可接受排序）
> 结束语（总结达成的共识、维护关系、明确下一步）
使用建议： 困难对话失败的最大原因不是你说错了话——是你之前没有想过对方可能怎么反应。第 3 点"如何应对防御性反应"就是提前预演最坏情况。当你说"我们需要谈谈你最近的三次延迟交付"时，对方不会说"谢谢你，你完全正确，我会改进"。人性不是这样的。对方会说"那个是因为 XX 部门没配合"或者"你已经很久没给过我优先级了"。如果你没有提前准备好这些回应，你就会当场被带偏或者被激怒——对话就此失败。
37. 反馈提供器
> 我需要给 [谁——角色、关系] 关于 [什么事——具体行为或工作] 的反馈。背景：[关系良好？反复出现的问题？还是第一次？]使用以下框架撰写反馈：观察（我具体观察到了什么——针对行为，不是人品）
> 影响（它如何影响了团队、项目或结果——具体，不模糊）
> 期望（我希望未来看到什么——具体且可达到）
> 支持（我会做什么来帮助他们成功——而不仅只是要求改变）
> 语气：[支持性/直接/严肃]。写成说出来的话，不是邮件。这是一次对话，不是一份备忘录。
使用建议： 这个框架叫 OIES——Observation / Impact / Expectation / Support。它的核心逻辑是：第 1 步"观察"在说"我看到了什么"，不是在说"你是个什么人"。把行为和人品分开，对方才有可能听进去。"你这周三次会议都迟到了"是观察， "你不够尊重他人时间"是人身攻击。前者对方可能会解释，后者对方只会防御。
38. 演讲大纲构建器
> 为 [话题] 创建演讲大纲。听众：[谁、他们在乎什么]。时长：[多久]。目标：[听完后听众应该做什么/想什么/感受到什么]。结构：开场（30 秒——让他们放下手机的钩子）
> 问题（1-2 分钟——让他们感受到现状的痛苦）
> 解决方案（3-5 分钟——你的框架/方案/洞察，拆成 3 个清晰要点）
> 证据（2-3 分钟——每个要点的具体例子、数据或案例研究）
> 处理质疑（1-2 分钟——在听众提出来之前先回应最大的疑虑）
> 行动号召（30 秒——你明确希望他们接下来做什么）
> 每个部分：关键幻灯片内容、演讲者备注、到下一部分的过渡句。
使用建议： 第 5 点"在听众提出来之前先回应质疑"是演讲的暗器。听众心里有一个"但是……"的时候，你后面说的所有话他都听不进去——他一直在脑子里准备怎么反驳你。你先把他的疑虑说出来了，他的防御就放下了。放下防御的听众才是真正在听的听众。
39. 道歉起草器
> 我需要向 [谁] 为 [发生了什么事] 道歉。背景：[情况——我做了什么、造成了什么影响、我们的关系]。起草一份道歉，做到以下几点：承认我具体做错了什么（不是模糊的——是确切的行为）
> 表明我理解这对他们造成的影响（从他们的角度，不是我的角度）
> 承担全部责任（没有"但是"、没有"如果"、不转移话题）
> 解释我今后会做出什么不同的改变（具体、可执行、可验证）
> 不要求原谅（那是他们的选择，不是我的请求）
> 语气：真诚且直接。200 词以内。不过度解释。不以我的感受为中心。生成 2 个版本：版本 A：书面版（邮件/消息）、版本 B：口头版（当面说的措辞）
使用建议： 第 3 点——"没有'但是'、没有'如果'、不转移话题"——是 90% 道歉失败的原因。你自己检查一下你上次的道歉："对不起如果我让你不舒服了"（假道歉——在暗示对方太敏感）。"对不起我语气不好但那是因为我压力太大了"（假道歉——在甩锅给压力）。"对不起但你应该提前跟我说清楚"（假道歉——实际上在指责对方）。真道歉只做一件事：我做了 X，这是不对的，我不会再做了。
40. 电梯演讲构建器
> 为 [产品/服务/创意] 构建电梯演讲。听众：[我在向谁做这个演讲]。场景：[演讲发生的地方——投资人会议、社交活动、冷外联]。时间限制：[30 秒/60 秒/2 分钟]。结构：钩子（一句话让他们想继续听）
> 问题（一句话描述痛点——用他们的语言，不是你的语言）
> 解决方案（一句话描述我做什么——不是你如何工作，而是你为他们做什么）
> 证明（一句话可信度——数据、结果、有名气的客户）
> 请求（一句话——我希望他们接下来做什么）
> 生成 3 个版本、不同能量级别：
> 版本 A：自信有力的
> 版本 B：对话式温暖的
> 版本 C：数据驱动精准的每个版本说出口应该让人感觉自然，读起来不应该像书面语。
使用建议： 第 2 点"用他们的语言，不是你的语言"是电梯演讲中最常犯的错。你说"我们是一个基于 LLM 的多模态内容生成平台"——对方听不懂也不在乎。换个说法："你每天花 2 小时写营销内容，我们能让你把这个时间变成 2 分钟"。前者在说你的技术，后者在说他的生活。别人在乎的永远是后者。
## 如何使用这份提示词库
第一步： 先收藏。40 个提示词不可能一次记住，也不需要记。
第二步： 找到跟你本周工作最相关的 5 个。复制。替换里面的变量（用 [] 包起来的部分）。立刻使用。
第三步： 当一个提示词产出了特别好用的结果时，把当时的定制化版本保存进你的个人模板库。随着时间积累，你会搭建起一个完全为你自己工作场景量身定制的提示词库。
第四步： 每周针对你的工作，尝试 2-3 个之前没用过的提示词。循序渐进地拓展 Claude 能帮你做的事情。
复利效应： 持续使用一个月后，你的 AI 工作流将达到大多数人几年都到不了的水平。
## 最后
不是 40 个提示词改变了你的效率。
是你从"许愿式提问"切换到"工程化指令"的方法论，改变了你的效率。
"帮我写一篇文章"是许愿。"你是一个曾为顶级媒体撰稿的资深内容策略师，请你按这个结构、这个语气、这个质量标准、这个格式来写"是指令。
区别在于：前者告诉 AI 要什么结果。后者告诉 AI 怎么做、做给谁、做到什么程度算好。
大多数人会看完这篇文章，然后继续用"帮我总结一下"的方式跟 AI 对话。
那些把这个列表里的 5-10 个提示词真正用起来的人，一周以后输出的质量就不是一个级别的了。
感谢原作者 @eng_khairallah1 的优质内容 ❤️
如果你觉得有用，欢迎转发收藏。
## 相关链接
- [Aomyying](https://x.com/AomyYing)
- [@AomyYing](https://x.com/AomyYing)
- [10K](https://x.com/AomyYing/status/2059486326517580218/analytics)
- [@eng_khairallah1](https://x.com/eng_khairallah1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:06 PM · May 27, 2026](https://x.com/AomyYing/status/2059486326517580218)
- [10.1K Views](https://x.com/AomyYing/status/2059486326517580218/analytics)
- [View quotes](https://x.com/AomyYing/status/2059486326517580218/quotes)
---
*导出时间: 2026/5/27 16:52:21*