简介这份《ChatGPT使用秘籍150个ChatGPT提示词模板中英文版》PDF面向自然语言处理爱好者、机器学习从业者、语言模型研究者以及希望提升日常对话效率的普通用户核心是借助可直接套用的提示词模板降低构建高质量ChatGPT对话的门槛。压缩包仅含1个PDF文件大小约5.18MB便于下载、检索与随身查阅。资源目前已吸引1274人学习说明其在提示词实践群体中具有一定参考价值。内容围绕150个中英文模板展开涵盖充当Linux终端、英语翻译与润色、岗位面试官、JavaScript控制台、Excel工作表、英语发音助手、旅游指南、抄袭检查员、影视角色及广告商等场景每类模板通常包含角色设定、输出格式约束和交互节奏说明读者可替换任务参数后复用也可对照中英文版本理解表达差异。它适合用来快速搭建对话原型、优化提示词结构、提升问答与创作效率同时可作为学习语言模型应用方式的辅助材料不过仍需具备一定的自然语言处理与机器学习基础并按实际需求调整模板。1. 一份 PDF 提示词库真正的价值不是复制粘贴而是输出契约很多人第一次打开这份《ChatGPT 使用秘籍150 个 ChatGPT 提示词模板中英文版》第一反应是「就这不就是一堆 I want you to act as……」。我一开始也这么想直到把它当成一份「输出契约样本集」来读才发现它解决的问题很具体让语言模型在特定角色下按你规定的格式、规定的轮次、规定的信息密度说话。开发调试时你要的是干净可复制的代码块语言处理时你要的是不带解释的译文面试演练时你要的是一问一答而不是一次性甩出二十道题。这份资源把自然语言处理、机器学习、语言模型这些偏工程的诉求和写作、面试、旅游规划、餐饮推荐这类生活娱乐场景用同一套「角色 约束 协议」的写法串了起来新手能直接抄熟手能拿它当模板库改造。它不适合指望开箱即用的人适合愿意动手改两行字的人。2. 提示词骨架拆解从「充当 Linux 终端」看出三段式结构2.1 角色声明、输出约束、交互协议三段缺一不可拿资源里最短的那条「充当 Linux 终端」逐句拆。第一句是角色声明我希望你充当 Linux 终端。这句决定了模型接下来调用哪一类词汇分布——是 shell 命令的输出而不是自然语言解释。第二段是输出约束只回复一个唯一的代码块、不要写解释、除非我指示否则不要输入命令。第三段是交互协议我会输入命令你回复终端应该显示的内容当我需要用英语告诉你一些内容时我会用花括号 {像这样}我的第一个命令是 pwd。这三段各自承担不同职责顺序也不是随便排的。角色声明放最前面因为它在上下文里权重最高、最不容易被后续多轮对话稀释输出约束紧跟在角色之后用来压制模型「顺手解释两句」的默认习惯交互协议放最后因为它的结尾往往是一句启动信号——「我的第一个命令是 pwd」——模型读到这句就知道该立刻进入状态而不是反问你「请问你想让我扮演什么」。一个反直觉的结论是这三段里最容易出问题的不是角色而是约束。角色写错模型顶多演得不像约束写漏模型的输出就直接没法用。资源里凡是「只回复一个唯一的代码块」「不要写解释」这种带否定词的句子都是在给输出格式上锁。后面第 5 章会专门讲这把锁是怎么被撬开的。再看「担任岗位面试官」那条它的交互协议写得比终端模板更啰嗦请你只回答面试官的问题、不要一次性写下所有对话、一个一个地问我问题、像面试官一样等待我的回答。这里连说三遍「一个一个」本质上是在对抗模型一次性把整场面试生成完的倾向。这种重复不是冗余是血泪经验堆出来的。2.2 中英双版不是翻译冗余语言类模板的选型依据资源最大的结构特点是中英文各一份。大部分模板中英两版语义等价但有一类模板必须用对版本依赖语言检测的那几条。「充当英语翻译和改进者」的写法是我会用任何语言与你交流你将检测语言、翻译它并用更优美、更优雅、更高级的英语单词和句子回答。这条模板的执行前提是模型能正确识别输入语言并做出翻译动作。如果你用中文版声明去处理一段中文输入模型有一定的概率把「检测语言」理解成「保持原语言」结果就是原样返回或者只做润色不做翻译。常见做法是目标语言明确写死翻译成英语并且给一个 in-context 示例让模型照着这个格式走一轮后面就稳了。另一类必须本地化的是「充当英语发音助手」。原文这条是给某一种母语的使用者设计的要求用该母语的拉丁字母来标注音标性拼写并且明确「回复不能是翻译只能是发音」。你直接照抄得到的是别人母语的注音体系对你的场景毫无意义。改造点只有一个把「面向某语言使用者」换成「面向中文使用者」注音体系换成拼音。这类模板的价值不在文本本身而在于它教会你一个结构输入句子 → 只输出读音 → 不做翻译 → 不加解释。至于开发调试类的模板中英版差别很小因为命令、代码块、表格这些输出格式本身就是语言中立的。选中文版的唯一好处是你自己读着顺改起来快。2.3 把三段式落成可复用的参数化骨架150 条模板放在 PDF 里只能靠肉眼找真要天天用得先把它结构化。我一般会把每条模板拆成四个字段角色、约束列表、协议、占位符。下面这段是把「充当某角色」类模板统一渲染的骨架用 Python 写不依赖任何外部库。from dataclasses import dataclass, field import re PLACEHOLDER re.compile(r\{([a-z_][a-z0-9_]*)\}) # 只认小写下划线避开原文 {像这样} 这种语言切换标记 dataclass class PromptTemplate: tid: str # 模板编号和 PDF 目录顺序对齐方便检索 role: str # 角色声明必须是一句完整的话 constraints: list field(default_factorylist) # 输出约束逐条拆开不要揉成一段 protocol: str # 交互协议 启动信号 slots: dict field(default_factorydict) # 占位符默认值 def render(self, **kw): merged {**self.slots, **kw} body self.role.strip() if self.constraints: body \n \n.join(f- {c} for c in self.constraints) if self.protocol: body \n self.protocol.strip() missing set(PLACEHOLDER.findall(body)) - set(merged) if missing: raise ValueError(f模板 {self.tid} 有未填占位符: {missing}) return PLACEHOLDER.sub(lambda m: str(merged[m.group(1)]), body) terminal PromptTemplate( tidlinux-terminal, role我希望你充当 Linux 终端。我会输入命令你会回复终端应该显示的内容。, constraints[ 只回复一个唯一的代码块不要写任何解释, 除非我明确指示否则不要主动输入命令, ], protocol当我需要用英语告诉你一些内容时我会用花括号 {像这样}。我的第一个命令是 pwd。, ) print(terminal.render())这段代码有两个关键设计。第一个是constraints用列表而不是一整段字符串因为约束条数直接决定输出格式的稳定程度你随时可以往里追加一条而不破坏原有结构。第二个是PLACEHOLDER正则只匹配小写加下划线的名字这是刻意的原文里{像这样}和{like this}是「用花括号包裹非母语提示」的语法标记不是待填充变量如果正则写宽了渲染时会被当成占位符报错或者被替换掉。render里做了缺失占位符检查这个检查看着多余实际能救你。资源里带占位符的模板角色扮演类的{character}、{series}如果漏填就直接发出去模型大概率会一本正经地扮演一个叫 character 的角色你还得回头翻记录才知道哪里错了。slots字段是给常用值留的默认位。比如你经常让模型扮演同一部作品里的同一个角色就把默认值填进去调用时只传变化的参数。这条路径走通之后150 条模板就变成了一个可以按编号取用、按场景组合的本地库而不是一份躺在文件夹里的 PDF。3. 模板分组与选型150 条里哪几十条能天天用3.1 开发调试三件套终端、JS 控制台、Excel 工作表这三条是资源里输出约束最硬的模板共同特征是「唯一输出、禁止解释」。终端和控制台的差别只在语言环境终端模板面向 shell 命令及其回显控制台模板面向 JavaScript 的求值结果两者的协议句式几乎一模一样都是「我输入命令你只回代码块里的输出不要主动执行下一条」。真正值得说的是 Excel 工作表那条。它要求模型只回复一个纯文本的 10 行表格行号做行首、A 到 L 做列头、第一列表头留空用来对行号然后「我写公式你执行公式只回复表格结果」。这条模板的价值不在 Excel 本身而在于它示范了一种「把模型当解释器」的用法输入是公式或表达式输出是求值结果中间过程完全不可见。你做数据校验、格式转换、批量字段映射的时候这个结构可以直接搬。用这三条的共同前提是你的输入必须是自洽的。终端模板里如果你发一条有歧义的命令模型会按最可能的解释回显而不会告诉你「这条命令有两种理解」。所以真实用法是把它当草稿纸命令先在本地确认过语法再丢进去看预期输出或者反过来用它推演一条命令大概会打印什么再回本地验证。3.2 语言处理三件套翻译改进、发音助手、词源追溯这三条的共同约束是「只回结果不写解释」但内部逻辑完全不同。翻译改进类的核心指令是「保持意思相同但使句子更具文学性」并且明确「我只希望你回答纠正和改进」。它适合处理你已经写好、但读起来干巴巴的段落。注意它的定位是改进而不是翻译两者混用会得到一个既不像译文也不像润色的四不像。要翻译就用标准的翻译指令要润色就用这条别指望一条模板干两件事。发音助手类的改造点在第 2 章已经说过把母语体系换掉即可。它还有一个隐藏用法把「只输出读音」换成「只输出音标 重音位置」就变成了一条英语口语练习模板输出格式更紧凑。词源追溯类要求模型给一个词、追溯它的古代词根、说明含义随时间的演变。这条模板的实际用途比看起来大做术语表、做产品命名、做跨语言概念对照时它能快速给你一个概念的语义演化路径。但它的输出质量波动也最大因为词源学本身有很多争议说法模型会把主流观点和边缘推测混在一起说你拿到的结果只适合当线索不能当定论。3.3 内容生产四件套编剧、小说家、影评人、脱口秀这四条模板的输出约束明显更弱因为它们的目标是发散而不是收敛。编剧模板要求「先立人物、再定场景、再写对白人物立住之后才铺剧情」小说家模板要求「情节线突出、人物有吸引力、高潮出人意料」影评人模板列了一长串可覆盖的维度——情节、主题、基调、表演、导演、配乐、摄影、美术、特效、剪辑、节奏、对白——但强调最重要的是「这部电影让你产生了什么感受」脱口秀模板则要求「结合个人轶事让内容更有共鸣」。这四条的正确用法不是让模型一次生成成稿而是拿它们当结构检查表。比如你写完一个短片剧本把影评人模板贴上去让它按那十二个维度逐项打分你会发现自己漏掉的往往是节奏和基调这两项。脱口秀模板里「结合个人轶事」那句尤其值得学任何创作类模板只要加上一条「必须包含一个具体的第一人称细节」输出立刻从正确的废话变成能改的东西。生活娱乐和餐饮旅游方向的模板在这份资源里也有一批比如旅游指南类要求「我给位置你推荐附近可去的地方我给类型时你推荐同类型的邻近地点」。这类模板的输出约束最松实用性取决于你给的信息密度只说「我在某座城市」得到的是百科式罗列说清「我在老城区、只想逛博物馆、步行 20 分钟内」得到的才是能用的清单。3.4 一张选型表约束强度决定复用频次类别代表模板输出约束强度启动信号复用时频开发调试Linux 终端、JS 控制台、Excel 工作表强唯一代码块或纯文本表格第一条命令每天语言处理翻译改进、发音助手、词源追溯中强只回结果不解释第一句话每周内容生产编剧、小说家、影评人、脱口秀弱靠多轮追问收敛第一个请求按项目角色模拟岗位面试官、角色扮演、各类教练中一问一答不同步输出你好 / Hi按场景咨询顾问职业顾问、UX/UI、网络安全弱到中取决于背景信息量第一段背景描述低频这张表的用法很简单约束越强的模板越适合无脑复用因为它的输出格式稳定你不需要每轮检查约束越弱的模板越需要你在提问前想清楚要什么否则就是在跟模型聊天。很多人抱怨提示词模板没用本质是拿弱约束模板去干强约束模板的活。4. 二次改造把模板接进自己的流程4.1 占位符替换与变量注入以及那个容易翻车的花括号资源里带变量的模板不多但坑集中。角色扮演类的写法是{character}和{series}双占位你只填一个另一个就留在文本里。更麻烦的是原文协议里那句「当我需要用非母语告诉你一些内容时我会用花括号 {像这样} 包起来」——同一个符号既做变量又做语法标记机器和人都容易看混。我一般会做一次发送前扫描把没填的占位符和疑似语法标记分开报出来。import re VAR re.compile(r\{([a-z][a-z0-9_]*)\}) # 变量小写蛇形命名 MARK re.compile(r\{[^{}]*[\u4e00-\u9fa5][^{}]*\}) # 语法标记括号内含中文 def preflight(text: str, allow: set frozenset()) - list: 发送前体检返回问题列表空列表表示可以发 problems [] for name in VAR.findall(text): if name not in allow: problems.append(f疑似未填变量: {{{name}}}) for hit in MARK.findall(text): problems.append(f疑似语法标记残留: {hit}) return problems draft 请扮演 {character}来自 {series}。当我需要用英语说明时会用 {像这样}。 print(preflight(draft, allow{character, series}))allow参数是白名单用来放行「这一轮我有意保留、下一轮才填」的变量。输出里两条就会分别打印出语法标记残留和未填变量。这套检查跑在发请求之前比事后翻聊天记录便宜得多。变量注入的另一个习惯是把变量值也做成模板的一部分。比如{character}不要只填一个名字填「名字 三条性格特征 一句口头禅」角色稳定性会明显提升原因在第 5 章讲。4.2 我一般会在模板末尾追加的三行资源里的模板原文已经是完整可用的但接到真实工作流里我几乎每次都会在末尾补三行。这三行不改变角色只补协议漏洞。第一行如果我的描述缺少必要信息先问我一个问题然后停下不要猜。这条专治模型「过度配合」——你给的信息不全它不会说不知道而是编一个最像的答案填上你还以为是自己没说清。第二行保持上一轮回复的格式不变除非我明确要求更换。多轮对话里格式漂移是最常见的隐性故障第三轮开始从代码块变成普通文本、从表格变成缩进列表你还得手动改回来。这句约束能把格式按住。第三行每轮回复的最后一行用一句话说明你下一步需要我提供什么。这条对角色模拟类模板特别有用面试官模板加了这句之后它会主动问你「要不要进入下一题」而不是等你发指令。三行的位置有讲究必须放在协议之后也就是整个提示词的最后。放在角色声明后面会被后面的长文本稀释放在中间容易被模型当成可选项。4.3 长会话里的状态保持与断点重置模板跑到第五轮以后会出现一种很典型的衰减角色还在约束松了。终端模板开始给你加一句「这条命令的作用是列出目录内容」面试官模板开始一次性列出三个问题。这不是模型变笨而是长上下文里早期指令的权重被后来的对话内容稀释了。常见做法是重贴锚点。把角色、约束、协议压缩成两到三行每五轮或者每次发现格式跑偏时插一次。压缩的关键是保留否定词和格式词删掉所有解释性描述。ANCHOR ( 【锚点】角色{role}。 输出只给一个代码块不解释、不加前言后语。 协议一次一问/一次一条命令等我回复后再继续。 ) def build_messages(history, anchor, keep_last6): 保留最近若干轮 首轮 锚点控制上下文长度防止指令被稀释 if not history: return [{role: system, content: anchor}] head, tail history[:1], history[-keep_last:] return [{role: system, content: anchor}] head tailkeep_last控制保留的最近轮数我一般设 6设太小会丢上下文设太大锚点又被冲淡。首轮单独保留是因为首轮往往包含最完整的角色声明模型对它有更强的记忆。锚点用系统位而不是用户位是为了让它在每一轮都被重新读一遍。断点重置是另一件事。当你发现连续两轮输出都不符合格式不要再追加纠正语句直接开一个新会话把锚点和最近两轮的有效内容贴进去。在已经跑偏的上下文里继续拉扯成本比重新开始高得多这一点我在早期项目里吃过不少亏。5. 避坑模板失效的五种典型表现与排查顺序5.1 输出模板失效解释性废话与格式漂移现象一终端模板开始加解释。你发pwd它回一个代码块然后补一句「这条命令用于显示当前工作目录」。原因通常是三种之一约束句放在了长提示词的中后段被稀释你在某轮里说了「顺便解释一下这条命令」这句话污染了整个会话的约束或者模板里同时存在「只回代码块」和「像终端一样友好地回应我」这类互相冲突的表述。解决办法是把否定约束提到角色声明紧后面并且用「唯一」这种绝对化措辞——「只回复一个唯一的代码块不要写任何解释」比「尽量不要解释」有效得多。如果污染已经发生别在原会话里补救重开一轮贴锚点。现象二格式从代码块退化成普通文本。第三轮开始输出不再包在 里。原因是模型在多轮里逐渐向「对话」的默认模式回归尤其是当你的输入也变成自然语言的时候。解决方式是在锚点里把格式要求写成具体符号而不是「代码块」这三个字明确说「输出必须以三个反引号开始、以三个反引号结束」。符号比概念更难被忽略。5.2 角色与状态失效人设崩塌和上下文遗忘现象三面试官模板一次性甩出十个问题。你刚说「你好」它把整场面试的题目全列出来了。原因是模型对「完成一个任务」有很强的倾向它会把「面试」理解成一个需要交付的完整产物而不是一段交互。原文里连说三遍「一个一个地问我问题」就是在对抗这个倾向但只靠重复还不够。解决方式是加一条硬性收尾「每轮只输出一个问题输出后立即停止等待我的回答」。把「停止」这个词显式写进去比「等我回答」有效。现象四角色扮演到第五轮开始串味。你设的角色说话风格逐渐变回模型的默认语气。原因在于角色描述的粒度太粗。只写名字模型只能靠训练数据里的模糊印象写「名字 三条性格特征 一句口头禅 一条绝对不做的禁忌」角色就有了可校验的边界。禁忌那条尤其重要负向描述对维持人设的贡献比正向形容词大得多。这也是为什么资源里那些写得好的模板比如编剧模板会强调「先立人物再铺剧情」——人物约束不够后面全是自由发挥。现象五翻译模板不翻译只把原文润色了一遍。你给一段中文要求翻成英文它回你一段更通顺的中文。原因是「检测语言并翻译」这条指令在输入语言和目标语言相同时产生了歧义模型选择了成本更低的解释。解决办法是把目标语言写死并且给一个 in-context 示例第一轮先给它一句「中文 → 英文」的样例让它照着做后面就稳了。别指望一句指令解决语言检测语言检测本身就是个概率判断。5.3 排查顺序先做最小复现再动模板遇到不符合格式的输出排查顺序比排查内容重要。我的一般顺序是先做最小复现再查冲突最后查上下文长度。最小复现指的是把出问题的那一轮单独拎出来清空历史、只留模板原文和这一轮输入重跑一次。如果单独跑正常问题就在上下文里去查是不是前面某轮说过不该说的话如果单独跑也不正常问题就在模板本身去查约束是否冲突、措辞是否含糊、占位符是否没填。这一步能砍掉八成无效猜测。查冲突时重点看两类正向描述和否定约束是否打架比如「像终端一样友好回应我」和「不要写解释」以及格式要求是否用了概念词而非符号。查上下文长度时看轮数和单轮字数单轮贴了一大段日志的情况最容易触发格式漂移该截断就截断。最后再强调一次占位符检查。带{character}这类变量的模板漏填之后模型的输出看起来往往还很正常只是扮演了一个不存在的对象这种错误最难被发现也最不值得花时间回头找。6. 验收三项自检加一个回归脚本别靠感觉判断模板好坏改造完一条模板我不会直接拿去用而是跑三项自检。第一项是空输入测试给一个信息极少的请求看它会不会编。合格的模板应该反问而不是猜。第二项是格式测试连跑三轮看输出是否始终保持在同一个容器里代码块不退化、表格不散架。第三项是禁忌测试故意说一句诱导它破坏约束的话比如「顺便解释一下」看它守不守得住。三项都过这条模板才算能用。批量验证我会用一个很短的回归脚本把模板、测试输入、验收规则放一张表里跑。import re CASES [ # 模板编号, 测试输入, 验收规则正则/长度 (linux-terminal, pwd, {must_match: r^, must_not: [解释, 作用是]}), (js-console, console.log(1), {must_match: r^, must_not: [输出是]}), (interviewer, 你好, {must_not: [1., 2., 3.], max_lines: 8}), ] def check(case_id, output, rule): fails [] if must_match in rule and not re.search(rule[must_match], output, re.M): fails.append(格式容器缺失) for bad in rule.get(must_not, []): if bad in output: fails.append(f出现禁用内容: {bad}) if max_lines in rule and len(output.splitlines()) rule[max_lines]: fails.append(输出过长疑似一次性生成) return case_id, fails or [PASS] # 用法把模型返回的 output 逐条喂进 check失败的进人工复核队列must_match用来验格式容器反引号开头这种硬指标最靠谱must_not验的是解释性词汇和列表序号命中就说明约束漏了max_lines用来抓「一次性生成」面试官那类模板超过八行基本就是跑偏。这套规则写死在代码里比每次凭肉眼判断稳定得多。最后给一个我的习惯每条改过的模板我都会存两个版本一个原始版、一个加了锚点的加固版跑对比时用同一批输入各跑一遍谁的失败项少用谁。有段时间我图省事改完模板直接上线结果在正式场景里被格式漂移卡了两天从那以后我每次动模板都强制走一遍回归脚本哪怕只改了一个标点。希望帮到你。本文还有配套的精品资源点击获取