ChatGPT提示词模板工程化：输出契约、参数化改造与失效排查

简介：这份《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_factory=list) # 输出约束，逐条拆开，不要揉成一段 protocol: str = "" # 交互协议 + 启动信号 slots: dict = field(default_factory=dict) # 占位符默认值 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( tid="linux-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 一张选型表：约束强度决定复用频次

这张表的用法很简单：约束越强的模板越适合无脑复用，因为它的输出格式稳定，你不需要每轮检查；约束越弱的模板越需要你在提问前想清楚要什么，否则就是在跟模型聊天。很多人抱怨提示词模板没用，本质是拿弱约束模板去干强约束模板的活。

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_last=6): """保留最近若干轮 + 首轮 + 锚点，控制上下文长度，防止指令被稀释""" if not history: return [{"role": "system", "content": anchor}] head, tail = history[:1], history[-keep_last:] return [{"role": "system", "content": anchor}] + head + tail

keep_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用来抓「一次性生成」，面试官那类模板超过八行基本就是跑偏。这套规则写死在代码里，比每次凭肉眼判断稳定得多。

最后给一个我的习惯：每条改过的模板我都会存两个版本，一个原始版、一个加了锚点的加固版，跑对比时用同一批输入各跑一遍，谁的失败项少用谁。有段时间我图省事，改完模板直接上线，结果在正式场景里被格式漂移卡了两天，从那以后我每次动模板都强制走一遍回归脚本，哪怕只改了一个标点。希望帮到你。

本文还有配套的精品资源，点击获取