Prompt 配方

这里不做“神奇咒语”收集,而是把提示词拆成可理解、可复用、可迭代的任务模板。你可以先看方法框架,再从配方库里复制适合的版本。

12
常用模板
6
任务分类
1
复制可用

先说任务

把你要模型完成的动作放在最前面,例如解释、改写、审查、规划或生成。

补足上下文

说明目标读者、使用场景、已有资料和限制条件,减少模型自由发挥。

限定输出

提前定义格式、粒度、长度、语气和判断标准,让结果更容易直接使用。

要求自检

让模型标出不确定信息、潜在风险和下一步问题,避免看起来很完整但其实不可靠。

一个稳定 Prompt 的结构

角色

让模型进入合适的专业视角,例如工程导师、代码审查者、产品经理。

任务

明确动词和目标,不要只给一个宽泛主题。

背景

补充读者、业务、代码、文档或约束条件。

输入

贴出需要处理的材料,并用清晰分隔符包起来。

输出

指定格式、章节、表格字段、语气和长度。

检查

要求指出缺失信息、风险、假设和可继续追问的问题。

容易失效的写法

过于宽泛

例如“帮我写一篇 AI 文章”,模型会倾向于输出泛泛内容。

只给结论不说用途

同一个主题用于博客、汇报、代码注释时,输出应该完全不同。

没有边界

不说明不能编造、不能扩展、不能脱离资料,容易产生幻觉。

一次塞太多目标

同时要求研究、写作、排版、翻译和审查,会让结果失焦。

Prompt 配方库

按真实任务整理模板。选择场景后复制,再把大括号里的变量替换成你的具体内容。

学习解释 写教程、做学习笔记、给团队同步概念时使用。

结构化技术解释

把一个技术概念讲给有基础但不熟悉该领域的读者。

请用「一句话定义 / 核心机制 / 典型场景 / 常见误区 / 最小示例」解释:{topic}

读者背景:{audience}
要求:避免堆砌术语,每个术语第一次出现时都要解释。
需要替换的变量
topicaudience
使用要点
  • - 先限定读者背景
  • - 要求模型给最小示例
  • - 让模型指出常见误区
学习解释 学完一篇文章、一个视频或一个模型能力后使用。

费曼学习复盘

检查自己是否真正理解一个概念。

我刚学习了:{topic}

请你像导师一样检查我的理解:
1. 先让我用自己的话解释它。
2. 找出解释中模糊、跳跃或错误的地方。
3. 给我 3 个追问。
4. 最后给一版更清晰的解释。
需要替换的变量
topic
使用要点
  • - 适合学习地图配套使用
  • - 让模型先追问,不要直接给答案
  • - 可反复迭代
代码开发 提交 PR、重构代码或接入第三方 API 前使用。

代码审查助手

让模型优先找 bug、风险和遗漏测试,而不是泛泛总结。

请以资深代码审查者的视角检查以下变更。

目标:{goal}
变更内容:
{diff}

请按严重程度列出问题,格式为:
- 严重级别
- 文件位置
- 问题原因
- 可能影响
- 修复建议

只列真实风险,不要做泛泛总结。
需要替换的变量
goaldiff
使用要点
  • - 提供目标比只贴 diff 更有效
  • - 要求按严重程度排序
  • - 明确不要泛泛总结
代码开发 调试构建失败、接口报错、依赖冲突时使用。

从报错到修复方案

把错误信息、上下文和已尝试方案整理成可诊断输入。

我遇到了一个开发问题,请帮我定位原因并给出修复路径。

环境:{environment}
目标:{goal}
错误信息:
{error}

相关代码或配置:
{context}

我已经尝试过:{attempts}

请输出:最可能原因、验证步骤、最小修复方案、如果仍失败的下一步排查。
需要替换的变量
environmentgoalerrorcontextattempts
使用要点
  • - 不要只贴错误,补充环境
  • - 写出已尝试方案
  • - 要求最小修复
内容写作 写博客、周报、项目文档或作品集时使用。

项目日志整理

把零散开发记录整理成一篇可读的工程复盘。

请把以下开发记录整理为项目日志。

记录:
{notes}

请包含:背景、目标、关键决策、踩坑、解决方案、最终效果、下一步。
风格:真实、克制、面向开发者,不要写成营销稿。
需要替换的变量
notes
使用要点
  • - 保留关键取舍
  • - 写出失败路径
  • - 不要让模型过度包装
内容写作 准备教程、观点文章、产品介绍或学习笔记时使用。

长文大纲生成

把一个选题扩展成结构清晰的文章大纲。

请为主题「{topic}」生成一份长文大纲。

目标读者:{audience}
文章目标:{goal}
限制:{constraints}

请输出:标题建议、核心观点、章节结构、每节要点、需要补充的资料、容易写空的地方。
需要替换的变量
topicaudiencegoalconstraints
使用要点
  • - 先定读者和目标
  • - 让模型指出薄弱章节
  • - 大纲生成后再分段写
RAG 做知识库问答、企业文档助手、资料检索助手时使用。

RAG 答案生成约束

让模型基于检索片段回答,并标注引用依据。

你是一个基于检索结果回答问题的助手。

用户问题:{question}
检索片段:
{chunks}

回答要求:
1. 只使用检索片段中的信息回答。
2. 如果片段不足以回答,请说明缺少什么信息。
3. 每个关键结论后标注来源编号。
4. 最后给出“可继续追问的问题”。
需要替换的变量
questionchunks
使用要点
  • - 明确禁止编造
  • - 要求标注来源编号
  • - 让模型说出信息不足
RAG 知识库答案跑偏、引用错误或召回为空时使用。

检索失败诊断

分析 RAG 没答准是切块、召回、重排还是生成的问题。

请诊断这次 RAG 问答失败的原因。

用户问题:{question}
期望答案:{expected}
召回片段:
{retrieved_chunks}
模型回答:
{answer}

请按「问题改写 / 文档切块 / 向量召回 / 重排过滤 / 生成约束」五类分析,并给出优先修复建议。
需要替换的变量
questionexpectedretrieved_chunksanswer
使用要点
  • - 同时提供期望答案和召回片段
  • - 按链路定位问题
  • - 优先修复召回再修生成
Agent 做自动化工作流、资料整理、研究助理时使用。

Agent 任务规划

让模型先拆解任务,再选择工具和执行顺序。

你是一个谨慎的任务规划 Agent。

目标:{goal}
可用工具:{tools}
限制条件:{constraints}

请先输出计划,不要直接执行:
1. 任务拆解
2. 每一步需要的工具
3. 成功标准
4. 可能失败点
5. 需要用户确认的问题
需要替换的变量
goaltoolsconstraints
使用要点
  • - 先规划再执行
  • - 列出成功标准
  • - 让模型主动暴露不确定性
Agent 做多步搜索、代码生成、数据整理流程时使用。

工具调用结果反思

让 Agent 在工具返回后检查结果是否足够可靠。

请根据工具调用结果进行反思。

原始目标:{goal}
执行计划:{plan}
工具结果:
{tool_results}

请判断:
- 是否已经满足目标
- 哪些结论有证据支持
- 哪些地方仍不确定
- 是否需要再次调用工具
- 下一步最小行动是什么
需要替换的变量
goalplantool_results
使用要点
  • - 避免一次工具结果就下结论
  • - 区分证据和推测
  • - 保持下一步最小化
产品运营 规划网站栏目、功能迭代、产品页面时使用。

用户需求澄清

把模糊想法拆成需求、约束和可执行版本。

我有一个初步想法:{idea}

请帮我澄清需求:
1. 用户是谁
2. 用户真正想完成什么
3. 这个功能的最小可用版本
4. 不应该做什么
5. 衡量效果的指标
6. 需要我补充的关键问题
需要替换的变量
idea
使用要点
  • - 适合功能规划早期
  • - 要求给出不做什么
  • - 先做最小可用版本
产品运营 参考学习社区、榜单站、导航站、工具页时使用。

竞品页面拆解

分析一个页面的栏目、信息架构和可借鉴点。

请分析这个页面或产品:{product_or_url}

关注点:{focus}

请输出:核心用户、页面目标、信息架构、关键模块、交互方式、可借鉴点、不适合照搬的地方、适合我项目的改造建议。
需要替换的变量
product_or_urlfocus
使用要点
  • - 先声明关注点
  • - 区分借鉴和照搬
  • - 要求给出改造建议