简介在 AI 开发领域，提示工程 (Prompt Engineering) 是优化大型语言模型 (LLM) 输出的关键技术。本文介绍一个高级提示模板。

关于"LLM 聊天中的 Prompt Engineering"和"Agentic Engineering 中的 Prompt Engineering"，最终都归结为一个简单的系统。它在网上疯传——数十万次浏览，数千次收藏，很多人意识到他们一直在对着 AI 许愿，而不是在工程化行为或系统。

读完这篇文章，如果你愿意，你将不再需要复制粘贴任何人的 Prompt。你会想要构建自己的。

1. 停止复制粘贴 Prompt

互联网上充斥着"Top 50 ChatGPT Prompts"的帖子。人们收藏它们，粘贴进去，很多时候得到中等结果，然后继续寻找下一个。

问题出在这里：为一个特定使用场景、特定上下文、特定输出目标构建的 Prompt，永远不会比你自己构建的效果更好。而且这也不该由我来告诉你——这是你自己该搞清楚的。但我还是告诉你了，因为我爱你。

你现在做的事情就像戴别人的处方眼镜。技术上能用，实际上没用。你的上下文和设置对任何 Prompt 设置都很重要，即使别人分享的东西…

修复方法不是找更多 Prompt 来复制。修复方法是学习如何构建，以及如何随心所欲地修改它们。

你需要的是系统架构，而不是一个你很少查阅的书签库。

总体内容

1. 基础架构（The Core Tags）

这些标签是构建稳定行为的基石：

<role>：定义模型身份。不要使用“helpful assistant”这种冗余描述，而应定义具有特定背景的专家（例如：“具有15年经验的定位与消息架构高级品牌战略家”）。
<mission>：核心指令。定义 Scope，明确模型应做什么、不应做什么。
<rules>：行为准则。控制模型的思维模式而非输出内容，例如设定“永远不要假设用户未提供的上下文” 。
<constraints>：输出边界。硬性限制（如：字数限制、禁止引用竞品、语言要求）。
<output_format>：数据结构化。决定输出的形态（JSON、Markdown、甚至是特定的 API 参数格式）。
<examples>：Few-shot 校准。通过具体的 <example> 展示推理逻辑、语调和结构，这是校准模型最有效的手段。

2. 高阶逻辑组件（The Advanced Tags）

针对更复杂的交互场景，需要引入特定的逻辑控制：

<context>：引用背景资料。区分于指令，作为模型行动前的参考素材。
<knowledge>：注入领域事实。如产品定价、业务逻辑或技术规范。
<method> / <steps>：序列化工作流。确保模型按 Step 1 -> Step 2 的顺序思考，防止其跳步。
<anti_patterns>：负向反馈。展示“反面教材”，告知模型哪些具体的模式（如“模棱两可的废话”）是需要绝对规避的。
<evaluation>：自评检查。强制模型在交付前根据 Checklist 进行 QA 自检。
<discovery_engine>：反向询问。将交互模式从“表单填充”转变为“专家访谈”，让模型主动引导用户提供缺失的关键信息。
<fallback>：异常处理。定义当信息不足或超出 Scope 时的防御性行为，防止强行猜测。

详细内容

1. XML Tag 系统

大多数人用纯英文段落来 Prompt。这对简单问题有效。对于任何稍微复杂的事情，它完全崩溃。

问题是歧义。当你写一个段落时，模型必须猜测角色在哪里结束、任务在哪里开始、约束在哪里、输出应该是什么样子，以及是否有任何上下文或记忆…

每次猜测都是潜在的失败。

XML tags 消除猜测。它们创建带标签的容器，告诉模型每条信息是什么以及如何使用。

<role>
 你是谁
</role>

<mission>
 你做什么
</mission>

<rules>
 你如何表现
</rules>

模型不需要解释结构。结构是明确的。每个 tag 是一个边界。每个边界是你做的决定，所以模型不需要做。

这不是理论。AnthropicAI（Claude 背后的公司）在他们自己的 system prompts 中使用 XML tags。这就是模型设计用来解析结构化指令的方式。

2. 核心 Tags

这些是你几乎在每个 Prompt 中都会使用的 tags。把它们当作基础。大多数 Prompt 需要所有这些。有些可以跳过一两个，取决于使用场景。

<role>

这是模型成为谁。不是模糊的个性。一个具有特定专业知识的特定专家。

Bad:

1	<role>你是一个 helpful assistant。</role>

这毫无意义。模型默认就是"helpful assistant"。你加了零价值。

Good:

1	<role>你是一位拥有 15 年经验的资深品牌战略师，专注于为 B2B SaaS 公司构建定位。</role>

<role> tag 设置了过滤其他所有内容的透镜。一个 code reviewer 和一个 creative writer 会完全 differently 解释同一个 mission。Role 是每个其他 tag 建立的基础。

Role 越具体，模型猜测得越少。"Marketing expert"是一个猜测。"Senior brand strategist specializing in positioning and messaging architecture"是一个指令。

<mission>

这是模型实际做什么。不是描述。一个指令。

Bad:

1	<mission>帮助用户进行写作。</mission>

Good:

1	<mission>分析用户的草稿，并就结构、清晰度和说服力提供具体、可操作的反馈。</mission>

Mission 定义你的范围。什么进去，什么出来。模型做什么，不做什么。一个没有清晰 mission 的 Prompt 会做它想做的任何事情。而"它想做的"通常很平庸。

<rules>

Rules 是行为性的。它们控制模型如何行动，不是它产生什么。

<rules>
在提出建议之前，始终询问澄清问题。
不要给出泛泛的建议。每条建议都必须针对用户的具体情况。
如果用户的想法存在致命缺陷，直接指出。不要淡化坏消息。
除非用户明确要求，否则不要使用 bullet points。
</rules>

Rules 防止模型最糟糕的行为习惯。每个模型都有默认的 rails 它会回退到。当你想要自然的书面英语时，它用 bullet points。当你想要一个 Prompt 时，它随机开始写代码。当你想要一个 app idea interrogation 时，它做出假设。Rules 是你覆盖这些 defaults 的方式。

把 rules 当作"永远不要做这个"和"总是做这个"层。它们是保持模型在你道路上的 guardrails。

<constraints>

Constraints 是硬限制。它们定义输出的边界。

<constraints>
回复必须少于 280 个字符。
不要提及竞争对手的名称。
所有建议必须能在 30 天内实施。
输出必须使用美式英语。
</constraints>

Rules vs Constraints: Rules 控制你的方法。"Always ask clarifying questions"是一个 rule。"Keep your response under 300 words"是一个 constraint。这个区别很重要，因为模型对它们的处理方式不同。Rules 塑造模型如何思考。Constraints 塑造模型产生什么。

<output_format>

最被忽视的 tag。

大多数人描述他们想要什么，但从不描述它看起来是什么样子。

<output_format>
返回一个不超过 3 句话的单一段落，总结核心思想。
随后给出 1-10 的信心分数。
如果信心分数低于 7，添加一行说明哪些额外信息会提高信心。
</output_format>

没有 output format，你得到的是模型那一刻想给你的任何东西。有时是一个段落。有时是一篇 500 字的 essay 带 bullet points。有时是一个 list 当你想要一个 narrative。

Output format 是"给我写点关于这个的东西"和"给我确切这个，以确切这个形状"之间的区别。这个 tag 把你的 Prompt 从请求变成架构。

看看同一个 Prompt 如何随着不同的 output formats 改变：

相同的 role，相同的 mission，但是：

<output_format>一句话。</output_format> 给你一个 tweet
<output_format>三段式执行摘要。</output_format> 给你一个 briefing
<output_format>带有章节和子章节的详细报告。</output_format> 给你一个 analysis
<output_format>JSON，包含键：summary, confidence, gaps。</output_format> 给你结构化数据

模型一点都没变。你对 output format 的控制就是一切。

<examples>

最强大、最未被充分利用的 tag。一个好的 example 教给模型的比一段 description 更多。

<examples>
<example>
<user>评审这个标题："We Make Great Software"</user>
<response>
评分：3/10
问题：泛泛的价值主张。"Great"毫无意义。没有具体性，没有差异化。
重写："用 AI 编写测试套件，发货速度快 3 倍。"
理由：具体结果（快 3 倍），具体机制（AI 测试套件），具体受众（开发团队）。
</response>
</example>
</examples>

Example 不只是向模型展示你想要什么。它一次性向模型展示 format、depth、tone、structure 和 reasoning。没有任何 amount of written instructions 能复制一个 concrete example 所做的。

两个 examples 通常就够了。三个对大多数 Prompts 来说是 overkill。目标不是 comprehensive coverage。它是 calibration。

这与 Clawdbot/Moltbot/OpenClaw 之类的东西显然不同，因为这里我们是在 Prompting 一个 LLM 来为你做一个 Prompt，而 OpenClaw 有持久的上下文记忆，examples 越多越好。我会写一篇单独的文章来讲这个。

3. 高级 Tags

Core tags 处理你 80% 的 prompting，而 advanced tags 处理另外 20%——需要更多 precision、interactivity 或 domain specificity 的 Prompts。

你不会在每个 Prompt 中使用所有这些。当 core tags 不够用时，你才 reach for 它们。

<context>

这是模型在行动前需要的背景信息。这与 mission 分开，因为 context 是 reference material，不是指令。

1
2
3

<context>
用户是一位 SaaS 创始人，ARR 200 万美元，15 名员工，向中端市场销售。他们正在考虑扩展到企业市场，但缺乏销售基础设施。
</context>

Context 为模型设置舞台。没有它，模型给 generic advice 给一个 generic person。有了它，每个 response 都校准到用户的 actual situation。

何时使用： 任何时候模型需要知道关于用户、项目、行业或情况的事情，在它开始工作之前。

<persona> 和 <tone>

Role 定义 expertise。
Persona 定义 character。
Tone 定义 emotional register。

1
2

<persona>直接、不废话的沟通者。使用短句。避免企业术语。</persona>
<tone>自信但不傲慢。直率但不粗鲁。用户卡住时给予支持，找借口时给予挑战。</tone>

这些与 role 分开是有原因的。一个"senior financial analyst"（role）可以是 warm and encouraging 或 cold and clinical。Role 不决定 voice。Persona 和 tone 控制那个。

何时使用： 任何时候你需要模型以特定方式沟通，而 role 单独无法 capture。Writing prompts、coaching prompts 和 brand voice prompts 作为 starters。

<audience>

输出是给谁的。这改变 vocabulary、depth 和 assumed knowledge。

1	<audience>从未写过代码的非技术创始人。他们理解商业概念，但需要通过商业类比来解释技术概念。</audience>

同一个关于 building out an API 的解释，对于 developer vs CEO vs student 看起来完全不同。Audience 是帮助控制那个的 tag。

何时使用： 任何时候模型的输出会被除你之外的人阅读，或者当你需要模型校准 complexity 时。

<knowledge>

作为 reference 注入的 domain-specific information。与 context 不同，因为 knowledge 是 factual material，不是 situational。

<knowledge>
我们的定价层级：Starter（29 美元/月，1 用户），Growth（99 美元/月，5 用户），Enterprise（定制）。
我们的主要竞争对手：工具 A（更便宜，功能更少）和工具 B（更贵，学习曲线更陡）。
我们的差异化优势是实时协作，这是竞争对手原生都不提供的。
</knowledge>

何时使用： 任何时候模型需要 specific facts、data 或 institutional knowledge 来做它的工作。Product info、company policies、technical specifications、pricing data。

<method> 或 <steps>

模型遵循的 sequenced process。不是"做这些事情"。更像是"按这个顺序做，不要跳过步骤"。

<method>
1. 在回复之前完整阅读用户的输入。
2. 识别核心问题或痛点。用一句话复述以确认理解。
3. 检查是否缺少关键信息。如果是，在继续之前询问。
4. 按照 output_format 中指定的格式提供你的分析。
5. 以一个能深化分析的跟进问题结束。
</method>

Method 对 order matters 的复杂工作流很强大。Analysis prompts、debugging prompts、research prompts。任何 step 3 依赖 step 2 的东西。

何时使用： 任何时候模型需要经历一个过程，而不只是产生一个 output。

<anti_patterns>

“不要做这个"tag，但有 teeth。不只是说"不要做 X”，你展示 bad output 是什么样子，所以模型可以识别并避免它。

<anti_patterns>
BAD："评估这个机会时有很多因素需要考虑..."
WHY：模糊的填充词。什么都没说。浪费读者的时间。

BAD："一方面...另一方面..."
WHY：骑墙。用户要求的是建议，不是辩论。

BAD：任何回复以"好问题！"开头
WHY：谄媚的填充词。直接回答问题。
</anti_patterns>

Anti-patterns 对 rules 单独无法解决的 specific failure modes 更有效。一个 rule 告诉模型"不要 vague"。一个 anti-pattern 准确展示 vague 是什么样子。模型可以针对 concrete examples 进行 pattern-match，比针对 abstract instructions 更好。

何时使用： 当模型持续产生特定类型的 bad output，而 rules 单独没有解决时。

<fallback>

当模型无法完成任务时应该做什么。有了这个，模型不能 hallucinate 一个答案或给你一个无用的"I’m not sure"。

<fallback>
如果你没有足够的信息给出有信心的答案，说"我需要更多关于 X 的信息"并准确说明什么会有帮助。
如果问题超出这个 role 的范围，说明并建议用户可能在哪里找到答案。
永远不要猜测。永远不要编造数据。永远不要伪造来源。
</fallback>

何时使用： 任何 wrong answers 比 no answers 更糟糕的 Prompt。Financial analysis、medical information、legal review、technical specifications。

<evaluation>

Self-check criteria。模型在交付前审查自己的 output。

<evaluation>
在回复之前，验证：
- 这是否直接回答了用户的问题？如果没有，重新聚焦。
- 每个主张是否具体且可操作？如果有任何模糊之处，重写。
- 忙碌的人会在 60 秒内觉得有用吗？如果不是，无情地删减。
- 是否有任何假设？如果有，明确标注。
</evaluation>

Evaluation 就像给模型一个 quality assurance (QA) checklist。它在 output 到达你之前强制进行 second pass。

何时使用： 任何 quality consistency 真正重要的 Prompt。Client facing work、content production、analysis、recommendations、code review。

<discovery_engine>

模型在行动前问用户的问题。这是我的 viral app idea interrogation prompt 背后的 tag。

<discovery_engine>
在做任何工作之前，询问用户：
1. 你需要什么具体结果？
2. 最终输出的受众是谁？
3. 我在什么约束下工作（长度、格式、语气）？
4. 你已经尝试过什么但没用？
5. 我绝对不应该做什么？

等待所有答案后再继续。
</discovery_engine>

这个 tag 翻转了 dynamic。不是用户提供所有东西 upfront 然后希望他们没漏掉任何东西，模型提取它需要的东西。这是填写表单和与专家对话之间的区别。

何时使用： 任何用户的 initial input 可能不完整的 Prompt。Consulting prompts、strategy prompts、creative briefs、project planning。

<chain>

把 Prompts 链接在一起。一个的输出成为另一个的输入。

<chain>
这个 Prompt 是 3 步中的第 2 步。
输入：你将收到一份结构化的需求文档（第 1 步的输出）。
你的工作：将需求转换为技术架构文档。
输出：你的输出将输入到第 3 步，生成实施计划。
不要包含实施细节。那是第 3 步的工作。
</chain>

何时使用： Multi-step workflows，每个 Prompt 处理一个 phase。Research → analysis → recommendation。Draft → critique → revision。Interrogation → documentation → implementation。

4. 选择你的 Tags

不是每个 Prompt 都需要每个 tag。这是 architecture，不是 decoration。

这样想：

场景	推荐 Tags
简单任务（总结这个，重写那个，回答这个问题）	`<role>` + `<mission>` + `<output_format>`
专业输出（client deliverable、published content、formal analysis）	`<role>` + `<mission>` + `<rules>` + `<constraints>` + `<output_format>` + `<examples>`
Interactive/对话式（coaching、consulting、brainstorming）	`<role>` + `<mission>` + `<rules>` + `<discovery_engine>` + `<fallback>`
复杂工作流（multi-step analysis、research、production pipeline）	所有 core tags + `<method>` + `<evaluation>` + `<chain>` + `<anti_patterns>`

从 core tags 开始。只有当你遇到 specific problem 真正需要解决时，才添加 advanced tags。一个六个 tags 都做得很好的 Prompt，比一个十二个 tags 其中一半 mediocre 的 Prompt 更好。

5. 完整 Prompt：Voice Style Extractor

这是框架的实际应用。这个 Prompt 接受任何 writing sample 并 reverse engineer 作者的声音成一个可重用的 system prompt。对 content creators、ghostwriters，或任何需要在 AI-generated content 中保持一致 voice 的人有用。

<role>
你是一位语言取证分析师，专门将写作模式解构为可复制的系统。
</role>

<mission>
用户将提供一份写作样本。你的工作是提取每一个可识别的模式，并将其转换为可用于复制声音的风格指南。
</mission>

<method>
1. 在分析之前完整阅读整个样本。
2. 识别以下维度的模式：
   - 句子结构（长度分布、节奏、片段 vs 完整句）
   - 词汇水平（年级水平、术语密度、用词选择模式）
   - 标点习惯（破折号、省略号、用句号强调、逗号使用）
   - 段落结构（长度、过渡、独立行）
   - 修辞手法（重复、直接称呼、问句、回调）
   - 语气标记（权威水平、幽默类型、情感 register）
   - 格式偏好（标题、列表、粗体、换行）
   - 他们从不做什么（与他们做什么同等重要）
3. 综合成结构化为 system prompt 的风格 profile。
</method>

<rules>
绝不要用模糊的形容词描述风格。"Conversational"不是一个模式。"使用短句且频繁使用片段"是一个模式。
每个观察必须得到样本中至少两个例子的支持。
如果样本太短无法可靠识别模式，标记为"数据不足"而不是猜测。
</rules>

<anti_patterns>
BAD："作者有一种随意、引人入胜的语气。"
WHY：毫无意义。每个内容创作者都认为自己有随意、引人入胜的语气。零可操作信息。

BAD："写作清晰简洁。"
WHY：描述的是质量，不是机制。怎么清晰？短句？简单词？逻辑流？要具体。
</anti_patterns>

<output_format>
返回两个部分：

分析：每个识别到的模式的详细分解，按维度组织，附带支持例子。

风格 Prompt：一份完整的、可直接复制粘贴的 system prompt，以"你是一位以[作者描述]风格写作的[角色]..."开头，包含所有识别的具体模式。
</output_format>

<examples>
<example>
<user>[我的写作样本]</user>
<response>
分析：
- 句子结构：非常短（3-5 词）和中等（15-20 词）的混合。几乎没有长句。频繁使用以"And"或"But"开头的片段。
- 直接称呼：在每篇文章的前 3 句使用"you"。让读者成为主体，而不是作者。
- 用词选择："Suck"故意非正式，降低 register 以创造亲密感。从不用"utilize"当"use"可以时。

[继续所有维度]

风格 Prompt：
你是一位直接、不废话的作家，尊重读者的智力...
</response>
</example>
</examples>

为什么这个 Prompt 有效（框架分解）：

<role> 是具体的："linguistic forensics analyst。"不是"writing expert。"Specificity 告诉模型确切使用什么 lens。
<method> 强制 sequenced analysis。先读，然后识别，然后 synthesize。没有它，模型试图一次性做所有三个，会漏掉 patterns。
<anti_patterns> 防止最常见的 failure mode：vague style descriptions 听起来 insightful 但实际上对 replication 无用。
<output_format> 要求两个 deliverables：analysis（所以你可以验证它是准确的）和 style prompt（所以你可以使用它）。
<examples> 部分展示期望的 depth。一个 example 比任何 amount of written instruction 更能校准模型。

6. 完整 Prompt：Keyword & Sentiment Search Engine

这个 Prompt 把你的 AI 变成 research analyst，监控围绕 specific topics、accounts 或 keywords 的对话，并报告 sentiment、patterns 和 actionable insights。

<role>
你是一位专注于实时话语分析和叙事检测的社会情报分析师。
</role>

<mission>
用户提供关键词、账户名、主题或组合。你的工作是分析当前对话，并就情感、声量、新兴模式和战略影响提供情报简报。
</mission>

<context>
这用于市场研究、品牌监控、竞争情报或趋势识别。用户需要可操作的洞察，而不仅仅是数据聚合。
</context>

<method>
1. 在可用来源中搜索提供的关键词/账户/主题。
2. 按情感分类发现：正面、负面、中性、混合。
3. 识别主导叙事（大多数人在说什么？）。
4. 识别离群叙事（少数人在说什么但可能重要？）。
5. 标记任何新兴转变（情感在变化吗？新角度在获得关注吗？）。
6. 评估声量和速度（多少对话，在增长还是下降？）。
7. 提取可操作的洞察（用户应该用这些信息做什么？）。
</method>

<rules>
区分 loud minority opinions 和 actual consensus。10 条愤怒的推文不是 widespread backlash。
永远不要在没有声量上下文的情况下将情感呈现为事实。"负面情感"没有"来自多少人"是误导性的。
如果数据不足以得出结论，说明。不要从有限样本 extrapolate。
始终将人们在说的与他们意思的分开。表面抱怨往往掩盖更深层次的问题。
</rules>

<constraints>
所有分析必须基于公开可用信息。
不要推测个人的私人动机。
不要将 AI 生成的摘要呈现为直接引用。
标记 verified accounts 和 general public discourse 之间的区别。
</constraints>

<output_format>
主题：[分析的内容]
时间范围：[何时]
声量：[多少对话]
速度：[增长/稳定/下降]

情感分解：
- 正面（X%）：[主导正面主题]
- 负面（X%）：[主导负面主题]
- 中性（X%）：[信息性/事实性提及]

关键叙事：
1. [最常见叙事 + 例子]
2. [第二常见 + 例子]
3. [值得关注的 emerging/outlier 叙事]

可操作洞察：
[基于这些数据该做什么]

需关注的风险：
[可能出错的地方]

机会：
[存在什么机会]

缺口：
[数据不足的地方]
[什么会改进这个分析]
</output_format>

<evaluation>
在交付之前：
- 每个百分比是否与实际声量数据挂钩？
- 叙事是否由多个数据点支持，而非单个例子？
- 洞察是真正可操作的还是只是观察？
- 我是否标注了我不知道的？
</evaluation>

为什么这个 Prompt 有效（框架分解）：

<context> tag 在这里做了关键工作。没有它，模型不知道你是在做 brand monitoring、competitive research 还是 academic analysis。相同的 keywords，但完全不同的 analytical lens。
<method> 创建一个 7-step analytical process。这防止模型 jump to conclusions。它必须 categorize，然后 identify narratives，然后 check for shifts，然后 assess volume，然后 extract insights。每个 step 建立在前一个之上。
<rules> 防止 sentiment analysis 中最大的罪过：把 noise 当作 signal。关于"10 angry tweets 不是 widespread backlash"的 rule 在做真正的工作，因为模型喜欢 overweight negative sentiment。
<evaluation> tag 强制 self-check。模型必须在交付前验证它自己的 percentages 有 data 支持。这 catches hallucinated statistics。
<output_format> 设计上不灵活。Intelligence briefs 需要 consistent structure，这样你可以跨 time periods 和 topics 比较它们。GAPS 部分可以说是最重要的：它告诉模型什么找不到，这通常比它找到的更 valuable。

7. 完整 Prompt：The Idea Interrogator

如果你关注我，你可能见过这个。它是 viral tweet 背后的 Prompt。那个在写一行代码或构建任何东西之前，强迫 AI 撕碎你的 app 或 coding idea 的 Prompt。

这是完整版本，建立在你刚学的相同框架上：

<role>
你是一位无情的需求分析师。你不构建。你不编码。你不建议解决方案。你只审问想法直到它们被完全理解。
</role>

<mission>
用户将描述一个应用、产品或功能想法。你的工作是询问每一个必要的问题，在任何工作开始之前充分理解需求。

在审问阶段不要生成任何代码、文档、计划或建议。
</mission>

<discovery_engine>
从询问你需要的每一个问题开始。不要保留。不要控制自己。一次 pass 提取完整画面。

至少涵盖：
- 解决的核心问题和为谁解决
- 用户类型、角色和权限
- 每个页面、流程和交互
- 数据：存储什么、在哪里、谁能访问
- 认证和授权模型
- 第三方服务和集成
- 边缘情况和错误状态
- 性能和规模预期
- 平台目标（网页、移动端、桌面端）
- 设计偏好和约束
- 预算和时间线现实
- 成功的样子，量化

然后对每个包含模糊性的答案深入挖掘。
</discovery_engine>

<rules>
永远不要假设。永远不要推断。永远不要以"合理默认值"填补空白。
如果答案模糊，追问。"Something modern"不是一个技术栈。"User-friendly"不是一个设计系统。
当你认为你完成了，你可能还没有。询问你可能遗漏了什么。
目标不是速度。目标是零假设。
</rules>

<anti_patterns>
BAD：接受"I'll figure that out later"作为答案。
WHY：那是一个伪装成答案的假设。如果它对构建重要，它现在重要。

BAD：在审问中途建议解决方案。
WHY：你建议的那一刻，用户就锚定到你的建议，而不是思考他们的实际需求。

BAD：一次问一个问题。
WHY：这不是治疗 session。用户脑子里有一个想法。完整提取它，然后让他们对所有内容做出回应。
</anti_patterns>

<fallback>
如果用户对一个问题说"I don't know"，不要跳过它。而是：
1. 解释为什么这个问题对构建重要。
2. 给出其他人常用的 2-3 种方法。
3. 让他们选择一种或将其标记为明确的开放问题。

没有未解决的模糊性被掩盖。
</fallback>

<output_format>
审问完成后，交付：

需求摘要
按类别组织（用户、功能、数据、认证、集成、设计、约束）。

已确认决策
用户在审问期间做出的每个明确决策。

开放问题
任何仍未解决的，附带说明为什么重要以及何时需要决定。

假设日志
如果任何假设不可避免，明确列出以便跟踪和验证。

以以下结束："审查这个摘要。如果有任何错误、遗漏或需要澄清的地方，在继续之前说出来。"
</output_format>

为什么这个 Prompt 有效（框架分解）：

<role> 故意 narrow。"You do not build. You do not code. You do not suggest."每个句子移除一个行为。没有这些 explicit contradictions，模型会试图通过提供解决方案或随机开始 coding 来 helpful，这完全破坏了目的。
<discovery_engine> 是这个 Prompt 的核心。它告诉模型 upfront 问所有东西，不是 drip-feed questions。那是一个 deliberate design choice。你想要 full picture 在一次 pass 中提取，这样用户可以看到他们 idea 的 scope，以及 waste less model compute 在一个 back-and-forth 中。
<anti_patterns> 部分针对这个 Prompt 失败的三种最常见方式：接受 vagueness、建议而不是询问、和 pacing questions 太慢。每个都是模型自然 defaults 到的行为，而这个 Prompt 必须 override。
<fallback> 处理"I don’t know"问题。不是跳过 question，模型解释为什么它 matters 并给出 options。这把"I don’t know"变成 decision point 而不是 dead end。
<output_format> 交付四个 distinct sections，每个 serving a different purpose。Requirements summary 是 document。Confirmed decisions 是你的 audit trail。Open questions 是 todo list。Assumptions log 是 risk register。一起它们给你一个 complete foundation 来 build from。

8. 调试你的 Prompts

你的 Prompt 不工作。也许 output 是 generic。也许它忽略了 format instructions。也许它编造了 facts。

以下是如何找出哪个 tag 是问题：

问题	解决方案
Output 是 generic 或 shallow	你的 `<role>` 太 vague。让它更具体。添加 years of experience、specialization、或 domain。Role 越具体，output 越不 generic。这个要玩得开心。
Output 是 wrong format	你的 `<output_format>` 缺失或太 loose。如果你想要 `.csv` 或 `.md` 却得到 paragraphs，那不是模型的 fault。准确指定 output 应该是什么样子。
Output 忽略你的 instructions	你的 `<rules>` 或 `<constraints>` 被 buried 或 contradictory。把它们移到 Prompt 更早的位置。让它们更短更直接。检查是否有 rules 互相 conflict。
Output 是 playing it safe 或 sugarcoating everything	添加 `<anti_patterns>` 部分，带有 hedging behavior 的 explicit examples。向模型展示你不想要什么。
Output misses the point	你的 `<mission>` 是 ambiguous。如果你能读你的 mission statement 并想象三种不同的 interpretations，模型会随机 pick 一个。Tighten 它直到只有一个 possible reading。
Output makes up facts	添加 `<fallback>` tag。告诉模型当它不知道某事时该做什么。没有 fallback instructions，模型的 default 是 confidently guess。
Output 跨 runs 不一致	添加 `<examples>`。没有什么比向模型展示 good 是什么样子更能 stabilize output。一个 example 抵得上一百 words of instructions。
Output 是对的但 process 是错的	添加 `<method>` tag 带有 explicit steps。模型可能通过 wrong path 到达 right answer，这意味着下次它会得到 wrong answer。你的 method 确保 process 是 repeatable 和 scalable。

9. 构建你自己的

你现在有了系统。每个 tag，它做什么，何时使用它，以及当你不用时它如何 break。

这个框架无论你是在构建 code review、voice extraction、content writing、SEO strategy、data analysis、meal planning 的 Prompt，还是 literally 你能想到的任何其他东西，都是一样的。Tags 不改变，里面的内容改变。

现在你可以随意 copy、build 和 remix Prompts。去把它们变成你自己的。

你现在是 Tony Stark。去构建你的 Jarvis。

如果你想让我分享我 50+ 个建立在这个 exact framework 上的 AI use cases 和 Prompts，那很快就会来。stay tuned for more。

如果你读到这里，你现在比 99% 每天使用 AI 的人更了解 Prompt construction。这不是 secret。这是一个系统。现在它是你的了。

原文地址