P Prompt Hub

四种输入类型灵活组合

问题输入（回答问题）、任务输入（执行任务）、实体输入（操作对象）、补全输入（续写内容）。当自然语言指令难以表达时，用补全前缀引导模型。

明确约束：做什么 + 不做什么

指定输出长度、格式（表格/列表/段落）、风格。用 System Instruction 设定整体基调。

始终包含示例

没有示例的提示词效果通常较差。通过展示偏好可以改变模型行为（如偏好简洁回答）。但示例过多可能导致过拟合，需实验找到最佳数量。

格式一致性：确保 few-shot 示例的结构、XML 标签、空格、换行符完全一致。

不要假设模型知道

将所需指令和信息直接包含在提示词中。用 Text: 标签包裹参考资料，指令放在上下文之后。

三种分解策略

分解指令：每个提示词只含一个指令。链式提示：多步骤任务逐步串联。聚合响应：对数据不同部分并行操作后聚合。

关键参数

temperature（0=确定性，高=创意）、topK、topP、max_output_tokens、stop_sequences。

⚠️ Gemini 3.x 重要提示：强烈建议保持 temperature、top_p、top_k 为默认值。修改可能导致循环或性能下降。

三种迭代方法

换措辞：同义不同表达。切换类比任务：如把分类改为多选题格式。改变内容顺序：[examples][context][input] → [input][examples][context]。

八项核心原则

① 精准直接 ② 使用一致结构（XML/Markdown）③ 定义模糊参数 ④ 控制输出冗长度 ⑤ 多模态输入一致性 ⑥ 关键指令放最前面 ⑦ 长上下文先放所有上下文再放指令 ⑧ 锚定上下文用过渡短语

增强推理

Gemini 2.5/3 自动生成内部思考文本。重度推理任务可用 "Think very hard before answering" 提升性能。

Reasoning vs GPT 模型

Reasoning 模型：给高级指导即可（像资深同事，给目标信任细节）。GPT 模型：需精确指令（像初级同事，需明确步骤）。大模型更智能，小模型更快更便宜。

优先级链：developer > user > assistant

developer 消息优先级最高（函数定义），user 消息次之（函数参数），assistant 为模型输出。instructions 参数提供高级指令，优先级高于 input。

将 Prompt 存在应用代码中，不用可复用 prompt 对象

✅ Prompt 构建器放在靠近功能的小模块中 ✅ 用类型化参数处理动态值 ✅ 直接传给 API ✅ 更改前加测试用例 ✅ 用部署系统推出变更。OpenAI 正弃用 API 中的可复用 prompt 对象。

Developer 消息标准结构

推荐顺序：Identity（身份/风格/目标）→ Instructions（规则/约束）→ Examples（输入→输出示例）→ Context（专有数据，放末尾）。

重复内容放开头

将预期反复使用的内容放在 prompt 开头，且在 JSON 请求体最前面的 API 参数中传递，最大化缓存收益。

提供多样化的输入/输出示例

无需微调即可引导模型完成新任务。用 XML 标签包裹示例，包含 id 属性关联输入和输出。

提供专有数据，约束响应范围

查询向量数据库将返回文本包含在 prompt 中，或使用内置 file search tool。注意上下文窗口 token 限制。

固定模型快照 + 建立测试套件

将生产应用绑定特定模型版本（如 gpt-4.1-2025-04-14）确保一致性。构建评估套件监控 prompt 性能。

编码任务

明确角色和工作流指导，要求模型用单元测试验证补丁，包含工具使用示例，生成干净的语义化 Markdown。

前端工程

推荐技术栈：Tailwind CSS + shadcn/ui + Lucide 图标 + Motion 动画。用 rubric 自评迭代。

Agentic 任务三大实践

① 充分规划与持久性：分解子任务，每次工具调用后反思。② 透明前言：重要步骤前解释原因。③ 进度跟踪：用 TODO 列表或 rubric 强制结构化。

黄金法则：给最不了解任务的同事看

如果他们会困惑，Claude 也会困惑。用直接动作动词开头（Write/Analyze/Generate），跳过前言。想要"超出预期"的行为，必须显式请求。

解释"为什么"很重要

不仅说 NEVER use bullet points，而是说 I prefer responses in natural paragraph form because I find flowing prose easier to read and more conversational。Claude 能从解释中举一反三。

3-5 个示例，满足三特征

相关性：紧密镜像实际用例。多样性：覆盖边缘情况。结构化：用 <example> 标签包裹。从一个示例开始，仅在不足时增加。

用 XML 标签划定内容边界

使用一致、描述性的标签名。多层内容时嵌套标签（如 <documents> 内含 <document index="n">）。混合指令、上下文、示例和变量时尤其重要。

长文档放顶部，指令放底部

复杂多文档场景中，将查询放在末尾可提升响应质量高达 30%。让 Claude 先引用文档相关部分再执行任务。

说该做什么，而非不做什么

❌ Do not use markdown → ✅ Your response should be composed of smoothly flowing prose。用 XML 格式指示器。匹配提示词风格到期望输出。详细格式偏好用 XML 标签。

adaptive thinking + effort 调控

用 thinking: {type: "adaptive"} 配合 effort 参数控制思考深度。偏好通用指令（"think thoroughly"）而非手写分步计划。思考关闭时可用 <thinking> 和 <answer> 标签手动 CoT。

主动模式 vs 保守模式

主动行动：<default_to_action>By default, implement changes rather than only suggesting them</default_to_action>。保守行动：<do_not_act_before_instructions>Do not jump into implementation unless clearly instructed</do_not_act_before_instructions>。注意 Opus 4.5/4.6 对 system prompt 更敏感，降级 "CRITICAL: You MUST" 为 "Use this tool when"。

状态跟踪 + 多窗口工作流 + 安全平衡

聚焦增量进展。用 git 跟踪状态。跨多上下文窗口时：第一个窗口搭框架、写测试，后续迭代。对不可逆操作（删除文件、git push --force）必须先询问用户。

避免过度工程和硬编码

Opus 4.5/4.6 倾向过度工程。明确指示：Avoid over-engineering. Only make changes that are directly requested or clearly necessary. 避免聚焦通过测试而用变通方法。

允许说"我不知道" + 先调查再回答

If the data is insufficient to draw conclusions, say so rather than speculating. 对于代码库问题：Never speculate about code you have not opened. You MUST read the file before answering.