深入解析 Event Planner GPT 泄露提示词：事件策划 Agent 的思维链、追问机制与文案风格设计-育师

提示工程

【免费下载链接】GPTs

leaked prompts of GPTs

项目地址：https://gitcode.com/GitHub_Trending/gp/GPTs

导读

本文以开源仓库 GPTs 中收录的 Event Planner 泄露提示词为绝对核心，逐段拆解这款由 FIG ROYALE LTD 打造的事件策划 GPT 的系统指令：从开场信息采集协议、Tree of Thought 逐步推理、反事实思维校验，到 Garey Halbert / Joanna Wiebe / Mindy Weiss 三大文案风格约束与"必须持续追问"的交互规则。读完本文，你将能够理解事件类 GPT 的系统提示词是如何被设计的，并掌握将这些提示词工程手法迁移到自建 GPT 或业务 Agent 中的完整方案。

一、文档背景与定位

该文档位于仓库根目录 prompts/Event Planner.md，属于本仓库收录的"GPT 泄露提示词"（Leaked Prompts）之一。README 明确说明仓库的用途是收集 GPTs 的系统提示词原文（README.md）。

文档全文由三部分构成：

标题与一句话定位：Event Planner，Your go-to for event planning.（你的事件策划首选助手）；
归属信息：作者为 FIG ROYALE LTD；
核心系统提示词：一段完整的 markdown 代码块，定义了这个 GPT 的完整行为规范。

从提示词内部结构看，该 GPT 的核心定位是一个同时覆盖个人与商务场景的事件经理（event manager）：它不仅要给出建议与组织技巧，还要负责重要任务提醒，"确保没有任何事项被遗漏"。

二、开场对话协议：从三个问题锁定场景边界

提示词的开篇即规定了交互的第一动作：

Always start by asking how many attendees are planning the location indoors or outdoors. If outdoors, ask for the season.

这是一个强制性的开场信息采集协议，可以拆解为三个依次追问的变量：

顺序	采集变量	作用
1	参会人数（how many attendees）	决定场地容量、预算量级、餐饮与座位规划、物料数量
2	场地类型：室内 or 室外（indoors or outdoors）	决定天气预案、供电/音响方案、棚架搭建、交通指引
3	若为室外：季节（the season）	决定防晒/取暖策略、雨季备份方案、时令主题与菜单

这三个问题形成了事件策划的分支树：人数 → 室内/室外 → 季节。从工程角度看，这是在用最少的对话轮次完成场景归约（scenario reduction），让后续所有建议都能落在确定性的约束集里。例如：

50 人室内会议与 500 人户外婚礼，涉及的服务商、预算分配、风控清单完全不同；
同为户外活动，夏季要处理高温与暴晒，冬季要处理取暖与路面湿滑。

这种"先问约束、再给方案"的顺序，是事件策划类 Agent 与普通问答式 Chatbot 的关键差异——它避免了在没有上下文的情况下输出泛泛而谈的建议。

三、核心推理管线：从关键词提取到二级复核

提示词的中段描述了完整的信息处理流水线，这一段是整份提示词的技术精华，可分解为六个连续步骤：

3.1 关键词提取

Identify the main elements and keywords within the query.

系统要求先识别查询中的主要元素与关键词。在事件策划场景中，这些关键词包括：活动类型（婚礼/年会/生日/团建）、日期、预算、主题色、人数、地点、餐饮偏好、表演需求等。这一步是后续所有检索与推理的输入锚点。

3.2 逐步思维树（Tree of Thought）

Construct a detailed, step-by-step tree of thought to explore each point thoroughly.

这里明确要求构建**详细的、逐步的思维树（ToT）**来穷尽探索每个要点。这是一种比标准链式思考（CoT）更强的推理结构：它将一个问题拆分为多个分支，每个分支再继续展开子节点，最终形成一棵完整的推理树。

值得注意的是，"Tree of Thought" 作为显式术语在本仓库的提示词中并非孤例——World Class Software Engineer 的提示词同样提到使用树状思维配合知识库 JSON 与 Python 模板实现（World Class Software Engineer.md#L60）。这说明 ToT 是这批高质量 GPT 提示词中反复出现的通用推理技术。

在事件策划中，ToT 的典型形态是：

活动目标（如"500 人户外婚礼"） ├── 场地分支：备选场地 A/B/C → 容量、租金、档期、交通 ├── 天气分支：雨季概率 → 备用室内方案 → 帐篷/雨棚预算 ├── 预算分支：总预算 → 分配比例 → 单项报价比对 ├── 餐饮分支：人数 × 人均预算 → 菜单定制 → 过敏原清单 └── 流程分支：仪式 → 用餐 → 娱乐 → 撤场时间线

3.3 广域训练数据检索

Draw from a wide range of related data in the GPT's training to ensure a comprehensive understanding.

系统要求"从训练数据中调用广泛相关的数据"，以保证理解全面。这意味着在给出建议时不能只依赖用户当前的消息，而应综合调用历史经验：常见活动流程、供应商询价区间、行业标准时间线、经典避坑案例等。

3.4 用查询属性引导检索与推理

Use specific attributes from the query to guide the search and reasoning process.

即把第 3.1 步提取出的属性（人数、预算、日期、风格）当作检索过滤器，让推理结果与用户的具体场景对齐，而不是输出通用模板。

3.5 数据一致性保障

Ensure consistency in data retrieval, particularly for repetitive or related queries.

这是针对重复性或关联性查询的一致性约束。用户在策划过程中会反复追问（"场地定了吗""预算还够吗"），系统必须保证前后答复不矛盾，不能出现"上午说预算 5 万足够、下午又说需要 8 万"这类自相矛盾。

3.6 反事实思维（Counterfactual Thinking）

Apply counterfactual thinking where appropriate, considering how different circumstances might have changed the outcome or the state of the subject in question.

"在合适之处应用反事实思维"——即主动设想不同的前置条件会如何改变结果。事件策划是典型的高不确定性领域，反事实推理的具体价值在于：

风险预演：如果下雨怎么办？如果核心嘉宾临时缺席怎么办？如果预算被砍掉 30% 怎么办？
方案比选：如果场地从室内改到室外，流程和成本会发生哪些变化？
回溯归因：某个环节若换成另一种执行方式，结果是否会更优？

这是把策划从"给清单"升级为"给预案"的关键机制。

3.7 输出前复核

Review each response for coherence, relevance, and accuracy before presenting it. Ask for additional context if necessary to refine the accuracy of the response.

在呈现答复前，系统必须自查回复的连贯性、相关性与准确性；若信息不足，应主动索要更多上下文来校准答案。这是一个标准的质量门（quality gate）。

3.8 二级复核（Secondary Review）

Conduct a secondary review to cross-verify data consistency, particularly for lesser-known topics.

提示词要求在首轮复核之后再执行第二轮交叉验证，尤其针对冷门知识点（如小众场地法规、特殊民俗流程、罕见供应商资质要求）。双重复核机制的目的，是防止低置信度信息直接流向用户。

至此，完整的处理管线为：

关键词提取 → ToT 思维树 → 广域检索 → 属性引导推理 → 一致性保障 → 反事实风险推演 → 首轮质量复核 →（必要时补问上下文）→ 二级交叉复核 → 格式化输出

四、输出格式与文案风格约束

提示词在输出层面给出两条硬约束：

4.1 设计化排版

Present the response in a designed format to maintain clarity and logical flow.

要求以"经过设计的格式"呈现，保证清晰与逻辑流畅。事件策划天然适合结构化输出：分段的待办清单、带时间线的时间表、预算表格、风险清单等。参考本仓库中同属"日程/事件"主题的 Calendar GPT 的做法——它用 emoji 分项列出日程（⏰ 时间、📍 地点、👥 参会人）——可以看到这类 GPT 普遍偏好"可视化结构 + 信息分层"的输出风格。

4.2 三大文案风格注入

Write questions and replies using Garey Halbert, Joanna Wiebe, and Mindy Weiss's style.

这是 Event Planner 提示词最具辨识度的设计：要求提问与答复同时借鉴三位营销/策划领域人物的风格：

人物	领域身份	风格要点（基于公开的行业常识，非仓库证据）
Gary Halbert	直邮文案传奇	口语化、直接、强行动导向，善于用对话体逼出决策
Joanna Wiebe	转化文案（Copyhackers）	以用户语言写文案，强调共情、清晰、逐层推进说服
Mindy Weiss	名人婚礼/活动策划师	审美导向、注重细节与情感体验，擅长仪式感叙事

将三者叠加的效果是：提问像销售漏斗一样逐层收窄需求，回答像说服文案一样让用户愿意行动，同时保留活动策划该有的精致与仪式感。这正是活动策划场景所稀缺的"既专业又感性"的混合语调。

4.3 持续追问机制

Always ask follow-up questions by gathering more insights and information!

提示词以强制语气收尾："永远通过收集更多洞察与信息来追问！"结合第 3.7 步"必要时索要更多上下文"，追问机制贯穿全程。这与 Practice English by Debating 中"通过追问挑战观点"的设计同源，但目的不同：事件策划的追问是为了逐步收敛需求、补全约束，而非辩论对抗。

一个典型的追问演进序列：

Q1: 这次活动预计多少人参加？ Q2: 场地是室内还是室外？若在户外，是什么季节？ Q3: 预算范围大概是多少？有没有必须保留的核心环节？ Q4: 有没有已预订的场地/供应商，或者完全从零开始？ Q5: 需要我帮忙安排哪些部分（餐饮/流程/物料/邀请函）？

五、端到端交互示例：提示词如何驱动一场婚礼策划

把上述机制串起来，可以得到一份符合提示词意图的完整对话示例（以下为基于提示词设计的演示性流程，用于说明各机制的调用时机）：

用户：我想办一场婚礼。
Event Planner（执行开场协议 + 追问机制）：首先恭喜你！为了帮你把婚礼策划得滴水不漏，我需要先了解几个关键信息——
预计有多少位来宾？
场地计划在室内还是户外？如果是户外，大概在哪个季节举行？
用户：大约 120 人，户外，明年 5 月。
Event Planner（ToT 展开 + 反事实推演 + 结构化输出）：太好了，5 月的户外婚礼既浪漫又充满春日气息。基于 120 人、户外、5 月这组信息，我先为你铺一条主线时间线，同时把几个容易忽略的风险点一并列出：
时间线（倒排）
12 个月前：确定场地档期与备选方案（此时段旺季预订紧张）
6 个月前：敲定餐饮试菜、摄影摄像、主持团队
3 个月前：发送请柬并统计出席人数（预留 10% 机动桌位）
1 个月前：婚礼流程彩排、座位图定稿、天气预案确认
风险预案（反事实推演）
若当日下雨：是否已锁定备用室内场馆或租用棚架？
若 5 月出现高温：是否需要为户外仪式准备遮阳与饮水点？
若核心嘉宾临时缺席：座位图与致辞顺序是否有 B 方案？
接下来，为了帮你把预算和风格定得更准，我想再确认几点：整体预算大概在什么范围？婚礼风格偏向清新森系、复古庄园还是现代极简？有没有必须保留的仪式环节（比如父母致辞、First Dance）？告诉我更多细节，我会把每一部分拆成可执行的小步骤并持续提醒你推进！

这个示例清晰地展示了：开场三个问题 → 关键词提取 → ToT 时间线 → 反事实风险预案 → 结构化排版 → 持续追问，六条机制在两次对话轮内全部触发。

六、与仓库内其他事件/日程类 GPT 的横向参照

将 Event Planner 提示词与本仓库其他相关提示词对照，可以更准确地定位它的设计取向：

Calendar GPT：专注"日程读取与汇报"，依赖 Zapier Actions 操作真实日历，输出风格为 emoji 分项日程——它解决的是"今天有什么安排"，而 Event Planner 解决的是"未来的活动怎么从零到一规划好"；
Executive f(x)nn.md)：专注"大任务拆解为极小的可执行步骤"（如"洗碗：走到厨房、戴手套、拿洗洁精"），与 Event Planner 的"ToT 逐步推演"在方法论上同源，但粒度更细、面向个人待办；
World Class Software Engineer：同样显式使用 Tree of Thought 术语，可作为"ToT 是这批高质量 GPT 通用推理技术"的旁证。

三者的关系可以概括为：Calendar GPT 管"看日程"，Executive f(x)n 管"拆任务"，Event Planner 管"策划全流程"——后者同时具备前两者的部分能力（时间线 + 步骤拆解），并额外叠加了反事实风控与文案风格层。

七、提示词工程视角：这份文档教会我们什么

从提示词工程（Prompt Engineering）角度，Event Planner.md 至少提供了五个可复用的设计范式：

强制性开场采集协议：用"人数 → 室内/室外 → 季节"三个问题完成场景归约，避免无约束输出——任何领域的 Agent 都可以提炼出自己领域的最小约束问题集；
显式推理方法命名：直接声明"construct a tree of thought"，把推理结构写进系统提示词，而不是留给模型自由发挥；
双重复核门："Review before presenting" + "Conduct a secondary review" 形成两级质量闸门，适合高风险领域（策划、医疗、法律等）的输出控制；
风格锚定：用真实领域人物的风格作为语气锚点（Halbert / Wiebe / Weiss），比抽象的"请写得专业一些"更具可执行性；
以"永远追问"收尾：将追问固化为系统级行为，保证信息持续收敛，防止一次性答复导致的信息稀疏。

需要说明的是：本文对以上机制的解读基于提示词文本本身的语义与结构推断，仓库中不包含该 GPT 的源码、测试或运行日志，因此文中未声称任何性能指标或真实运行效果；所有"将产生如何效果"的表述均指提示词设计意图。

结语

Event Planner 泄露提示词是一份麻雀虽小、五脏俱全的 GPT 系统提示词范本：它用不足 200 词的篇幅，完整封装了"场景约束采集 → 树状推理 → 反事实风控 → 双重复核 → 风格化输出 → 持续追问"的端到端 Agent 行为链路。对于想要在 GPT Builder 中复刻或二次开发事件策划助手的开发者，这份提示词本身就是一份可直接借鉴的规格说明书；对于提示词工程研究者，它则是研究"如何用系统提示词塑造 Agent 工作流"的绝佳样本。