简介：《AI提示词大全》基础版.pdf 是一份面向人工智能语言模型使用者的提示词参考资料，适合希望提升人机交互效率的入门与进阶读者。内容围绕提示词在实际任务中的构造与优化展开，涵盖写作助理、提示词修改器、提示词生成器、英语翻译或修改、论文式回答、语音输入优化等常见场景，并给出中英双语示例，便于对照理解不同表达对模型输出的影响。压缩包内共1个PDF文件，大小约1.36MB，结构紧凑，可直接查阅，已有1082人学习。读者可从中获得可复用的提示词模板、文本润色与长句拆分思路、面向GPT-4等模型的提示语重写方法，以及根据角色和任务生成专用提示词的实践参考；同时能理解提示词对模型行为和回答质量的影响，减少后续人工修正，提升写作辅助、翻译改进与结构化问答等工作的效率。
1. 拿到一份 PDF 提示词清单，先别急着复制粘贴
《AI提示词大全》基础版.pdf 摆到面前时，多数人的第一反应是把它当成一份无脑复制的模板清单：写作助理、提示词生成器、周报生成器、四重结构归纳，几十条摆在那里，粘上就用。真按这个方式用上一周，你会发现同一段提示词换个模型、换个场景，效果忽上忽下，很玄学。问题不在模板本身，而在于模板只给了成品，没告诉你它的骨架长什么样、哪个词是必改的变量、哪一句是给模型的硬约束。这份文档真正值钱的地方是四组场景分类——常用、发散思维、写作辅助、文章故事——以及每条提示词里已经写死的角色设定和输出边界。下面按我自己实际使用的顺序拆：先看骨架，再改槽位，然后让模型自己改提示词，最后是踩过的坑和怎么建库。
2. 提示词骨架拆解：从「写作助理」抽出五个必备字段
2.1 五个字段：角色、任务、约束、槽位、输出格式
把文档里几十条提示词横着摆一遍，会发现合格的条目基本都能拆成五个字段：角色（你是谁）、任务（做什么）、约束（不做什么）、槽位（哪部分要被替换）、输出格式（交付物长什么样）。缺字段的条目不是不能用，而是稳定性差——模型会自己补上它认为合理的那部分，补得对不对全看运气。
我一般按这个顺序检查一条陌生提示词：先找角色句，通常是「我希望你能充当…」或「你是一名…」；再找任务动词，是改写、生成、拆解还是评估；然后扫约束，重点看有没有「只输出…」「不要…」「避免…」这类否定句；接着把方括号里的占位符圈出来；最后确认输出格式是否可判定。这套检查做三五条就熟了，之后看到任何新模板都能在十几秒内判断出它靠不靠谱。
「写作助理」这一条是最典型的五字段齐全样本，也是整份文档里复用率最高的一条。原文大意是：作为中文写作改进助理，改进拼写、语法、清晰度、简洁性和整体可读性，拆分长句、减少重复、提供改进建议，只提供更正版本、避免解释，从编辑以下文本开始。五字段一一对应，没有缺项，但存在一处内部冲突，下一节展开。
2.2 用「写作助理」做一次字段标注
# 角色 你是一名中文写作改进助理。 # 任务 改进所提供文本的拼写、语法、清晰度、简洁度和整体可读性； 拆分长句；减少重复表达。 # 约束 只输出修改后的正文。 不输出解释、不输出修改前后对照、不加「修改后：」之类的前缀。 # 输入槽位 {{article}} # 输出格式 纯净的正文段落，保留原有分段结构。这段重排和原文最大的区别是把「提供改进建议」删掉了。原文任务段写着「并提供改进建议」，约束段又写着「只提供文本的更正版本，避免包括解释」——这两句是打架的。模型碰到互相矛盾的指令，表现就是时好时坏：有时给你一大段点评，有时只给改后文本，取决于它这一轮更看重哪一句。这不是模型不稳定，是提示词本身没收敛。
常见做法是二选一。你要的是「改完直接用」，就砍掉建议，只留更正版本；你要的是「知道为什么这么改」，就把约束改成「先输出三条最重要的改动理由，再输出修改后正文」，并且明确理由最多三条，防止模型写成长篇分析。两件事都要，就必须分两次调用，一次改、一次评，别塞进同一轮。
中英双版在这条上也有差异：英文版要求输出 "the corrected Chinese version of the text"，明确限定了输出语言是中文；中文版只写「只提供文本的更正版本」，没锁语言。你拿一段英文原文去跑中文版，模型有概率把英文也一起改了然后原样返回，这时候你会以为是模型不听话，其实是提示词漏了一个字段。
2.3 负向约束决定下限，输出格式决定可自动化
新手容易把注意力全放在「角色」上，觉得角色写得越花哨效果越好。实际经验恰恰相反：角色只影响语气和知识调用倾向，负向约束才决定输出能不能用。文档里那些效果稳定的条目，几乎都带一句「不要写解释」「直接输出结果，不需要额外的声明」「只给我提示」。
「主题解构」那条就是正面例子：中文版直接写「直接输出结果，不需要额外的声明」。少了这句，模型十有八九会在子主题列表前面加一句「好的，以下是针对…的拆解」，后面再加一句「希望对你有帮助」。你自己看无所谓，但要把它接进脚本、接进批处理流水线，这些客套话就是噪音，还得额外写正则去清。
输出格式要写成可判定的。什么叫可判定：能不能用一行代码判断输出合格。「概括为 100 个字」可判定，数一下就知道；「使其易于阅读」不可判定，只能靠人眼。「以 markdown 格式编写」可判定；「排版清晰」不可判定。「生成五个标题，不超过 20 个字」可判定；「标题要吸引人」不可判定。我改模板时会把所有形容词式的格式要求，逐个换成数字或者结构描述，改完通常能省掉一半的返工。
2.4 四条常用模板按骨架重排后的差异
拿文档里另外三条做对照，能看出骨架缺项会带来什么具体后果。
「内容总结」原文要求概括为 100 字、易于阅读和理解、避免复杂句子结构或技术术语。字段基本齐，但缺一个关键约束：允不允许保留原文专有名词。实际用下来，模型为了压到 100 字，经常把产品名、型号、接口名一并简化掉，摘要读起来通顺但没法用。补一句「专有名词、数字、单位原样保留」就解决了。
「周报生成器」要求以 markdown 编写、易于阅读、面向一般受众、重点提供对利益相关者和决策者有用的见解和分析。这条的问题是目标堆太多且都偏虚。模型面对「有用的见解」这种描述，最常见的应对是生成几句正确但没信息量的话。我的改法是把它变成结构约束：本周完成、进行中、风险与阻塞、需要决策的事项，四段固定，每段不超过三条，每条必须带具体对象或数字。
「论文式回答」要求写一篇高度详细的文章，含引言、主体、结论。这条骨架最干净，但少一个长度锚点。不加字数或段落数，模型可能给你 300 字也可能给你 3000 字。补一句「正文不少于五个段落，每段不超过 200 字」，输出就稳定了。
3. 把模板改成自己的：槽位替换、中英双版与参数化
3.1 槽位命名：从 [文章内容] 到 {{article}}
原文档用中文方括号做占位，比如 [文章内容]、[主题]、[问题]、[语音文字输入]、[工作内容]、[格言要求]、[小说类型]、[文章开头]。人眼看没问题，但一旦要批量替换就会翻车：待处理的正文里本身可能带 [1]、[注]、[图 3] 这类方括号，简单做字符串替换会把正文内容一起吃掉。
我一般把槽位统一改成双花括号加英文小写命名，比如 {{article}}、{{topic}}、{{question}}、{{transcript}}、{{worklog}}、{{genre}}、{{opening}}。双花括号在中文技术文本里出现概率极低，冲突面小；英文命名方便在脚本里做键值映射，不用维护一张中文到变量的对照表。改完之后，模板文件就变成纯静态文本加若干占位符，可以被任何语言加载。
命名还有个小习惯：槽位名要能自解释，别用 {{text1}}、{{text2}}。半个月后回头看 {{transcript}} 你立刻知道这是语音转写稿，需要先做口语词清理；看到 {{text2}} 只能重新读一遍模板。
3.2 中英双版不是翻译关系，用之前先对齐
文档里不少条目给了中英两版，很多人的默认假设是「英文版更精确，中文版是翻译」。实际拆下来会发现，两版经常不是一回事——有的英文版多了输出语言限定，有的中文版多了具体步骤，还有的干脆内容对不上。上面提过的「主题解构」就是一例：中文版说的是把主题拆成子主题，紧接着的英文段落写的却是「生成一串有洞察力的问题」，那是「提问助手」的内容。
这类错位在扫描件里很常见，成因多半是排版串行或者 OCR 识别时把相邻段落拼到了一起。处理办法很土但有效：拿中文版和英文版分别跑同一个输入，看输出结构是否一致。结构一致，说明只是措辞差异，挑约束更全的那版用；结构不一致，说明有一版是错的，以中文版为准，因为这份文档的主线是中文场景。
还有一类是刻意的差异，不是错误。「四重结构归纳」那条明确写了「本提示词中英文版本存在较大差异，若需使用英文版请切换语言」。这种就属于作者自己知道两版不同，但没在正文里说清差在哪。我的做法是只保留中文版，英文版另存成独立条目，各自维护，不做同步——强行对齐反而会把两边的特点都磨掉。
3.3 用脚本做批量槽位填充
模板改好槽位之后，填充就是几行代码的事。用 Python 的 string.Template 而不是 str.format，原因是提示词正文里经常出现花括号（比如要求模型输出 JSON），format 会直接抛 KeyError，而 Template 只认 $ 开头的占位符，正文里的花括号原样保留。
from string import Template from pathlib import Path import json # 模板文件里用 $article 作为槽位，与正文中的花括号互不干扰 tpl_text = Path("prompt_lib/normalized/writing_assistant.tpl").read_text(encoding="utf-8") TPL = Template(tpl_text) # 回归用例：id + 待处理文本，统一放在 json 里便于版本管理 cases = json.loads(Path("prompt_lib/regression/cases.json").read_text(encoding="utf-8")) for case in cases: article = case["text"].strip() if not article: continue # 空输入直接跳过，避免生成只有壳的提示词 prompt = TPL.substitute(article=article) out = Path(f"prompt_lib/normalized/{case['id']}.prompt.txt") out.write_text(prompt, encoding="utf-8") print(case["id"], len(prompt))逻辑说明：读取模板、读回归用例、逐条替换、落盘成可直接粘贴的提示词文件。几个参数点值得注意。read_text和write_text都显式指定encoding="utf-8"，在默认编码不是 UTF-8 的机器上不加这一句，中文会变成乱码或者直接抛 UnicodeDecodeError，这是血泪经验。substitute在缺变量时会抛 KeyError，属于「快速失败」，比safe_substitute静默留下 $article 更好排查——模板里少写一个槽位，你希望它当场报错，而不是让你粘贴出去之后才发现模型在对着 $article 发呆。
最后那行print(case["id"], len(prompt))不是调试残留。提示词长度是要盯的指标：同一条模板，输入文本从 200 字涨到 2000 字，提示词总长会跟着涨，超长之后模型对前半段（尤其是角色和约束）的遵循度会下降。打印长度等于给自己一个预警，超过阈值就该考虑把长文切段处理，而不是硬塞。
3.4 参数化：把数字从正文里提出来
文档里散着一堆硬编码的数字：「概括为 100 个字」「800 字左右」「不超过 20 个字」「不少于五个段落」「十大事实」「六个董事」。这些数字直接写在正文里，想换个量级就得改模板文本，改多了模板就花了。
我一般把它们提成变量：{{word_limit}}、{{title_limit}}、{{paragraph_min}}、{{fact_count}}、{{role_count}}。模板里写成「概括为 {{word_limit}} 个字」，用例文件里给不同场景配不同值——周报摘要用 150，新闻摘要用 80，同一套模板覆盖多个需求。这么改之后模板数量能砍掉一大半，维护成本跟着降。
提变量时有个细节：数字后面的量词要一起绑进变量说明里。「不超过 20 个字」里的「字」不能丢，否则填英文场景时模型会按英文单词数算，20 个单词和 20 个汉字的信息量差着好几倍。变量注释里写清楚单位，比在模板里留一句「注意单位」管用。
4. 让模型改提示词：修改器、生成器与三轮收敛
4.1 提示词修改器要先关掉「加戏」开关
文档里「提示词修改器」的原文很短：我在尝试从以下提示词中获得良好结果：「你的提示词」，你能否写出更优化、能产生更好结果的提示词。这条的思路是对的——人写的提示词语序和机器偏好不一致，重写一遍确实能提效果。但直接照抄会有个典型问题：模型倾向于把提示词扩写成一屏，加一堆你没要求的约束，比如「请确保内容准确无误、符合事实、不包含任何偏见」。这些话听着没错，实际会稀释真正的指令。
加固的办法是补两条约束：不新增原提示词没有的任务，只做结构重排和措辞精简；输出时先给一版精简版，再给一版带说明的版本。前者防止加戏，后者方便你判断它改了什么。
我正在尝试从下面这段提示词中获得稳定结果：「{{raw_prompt}}」 请你重写它，要求： 1. 只做结构重排和措辞精简，不新增原提示词未涉及的任务或约束； 2. 保留原有的输入槽位和输出格式要求； 3. 明确区分角色、任务、约束、输入、输出五部分； 4. 先输出重写后的提示词，再输出不超过三行的改动说明。 如果原提示词存在互相矛盾的指令，请在改动说明中指出，不要自行删改。第 4 条是关键。前面提过「写作助理」里任务和约束打架，让模型自己发现并指出来，比你自己逐条比对快得多。第 4 条的后半句「不要自行删改」也得加，否则模型会悄悄帮你选一个，你还以为提示词本来就长这样。
4.2 提示词生成器：样例给还是不给
文档里「提示词生成器」的原文明确写了「不要参照我给你的例子」，只给标题、让模型产出一条自解释的提示词。这个设计有它的道理：给了样例，模型的输出会高度贴近样例的结构，换场景时灵活性差。
但实际用下来，完全不给样例的代价是输出质量波动大。给一个标题「周报摘要」，模型可能生成角色、任务、格式俱全的完整提示词，也可能就给你一句「请帮我写周报」。折中做法是给样例但限定学习范围：只学格式骨架，不学内容和措辞，并且明确说明样例里的领域词汇不得出现在输出中。
另一处要注意的是「自解释」这个词。原文要求提示词自解释、与题目相适应，这个要求本身没错，但模型对「自解释」的理解经常是「把所有背景都写进去」，导致生成的提示词里出现「作为一个需要处理周报的职场人士」这种无信息量的铺垫。我一般把它替换成更硬的描述：生成的提示词必须能脱离上下文单独使用，不得出现「如上所述」「刚才提到的」这类指代。
4.3 三轮收敛：从能跑到能复用
单次生成的提示词，能跑通就不错了，离可复用还差两轮。我固定的流程是这样：
第一轮，用修改器或生成器拿到初版，直接拿两三个真实输入跑一遍，只看输出结构对不对，不管内容质量。这一轮主要筛掉完全跑偏的版本，比如该输出列表的输出了散文。
第二轮，把第一轮的输出贴回给模型，让它指出这份提示词里可能产生歧义的地方，每条歧义对应一个具体的输入例子。这一步很有用——模型对自己写的指令哪里松、哪里紧，判断往往比人准。它指出的歧义里，大概有一半是我自己没想到的。
第三轮，按歧义清单逐条收紧约束，再跑同一批输入，对比修改前后的输出差异。差异不明显就说明这条约束没必要，删掉，保持提示词短。提示词不是越长越好，每多一句约束，模型遵循其他约束的余量就少一分。
三轮下来，一条提示词大概能从「偶尔能用」变成「十次里八次能用」。剩下那两次不稳，通常是输入本身的问题，不是提示词的锅，别在这上面死磕。
4.4 什么时候不该用元提示词
元提示词（让模型写提示词）不是万能的，有几类场景用了反而添乱。任务本身极短的，比如「翻译成英文」「提取文中的所有日期」，这类需求一句话就说清了，交给模型重写，它要么原样返回，要么加一堆废话约束，纯属浪费一轮调用。
对格式要求极其严格的场景也不适合。比如要求输出固定字段的 JSON、要求按特定分隔符拼接，这类格式约束手写比让模型生成可靠得多，模型经常在生成的提示词里把字段名改个大小写，或者把必填项写成可选项。
还有一类是已经调好的成熟提示词。跑得稳就别动，模型版本更新时再拿出来做一次回归测试就行。我见过有人每隔几天就让模型重写一遍自己的提示词，改来改去反而把原来稳定的约束改没了，这是典型的过度优化。
5. 避坑与排查：五类翻车现场的处理顺序
5.1 现象：从 PDF 复制出来的提示词中英混排错位，粘进对话框就报错
现象很直观：复制一段提示词，中文句子中间突然插进半句英文，或者英文段落被截断成两行，开头的角色句跑到了结尾。粘进对话框后模型回复的内容驴唇不对马嘴，你还以为是提示词写错了。
原因是这份文档本身就是扫描或转换产物，正文里也明确提到过文字识别可能出现错字或漏识别，需要使用者自行修正。双栏排版、中英对照排版这两种情况最容易被识别成逐行交错，导致本该在下面的英文段落插进了中文中间。
解决办法是复制后先做一次结构检查：通读一遍，看角色句、任务句、约束句是否连贯；把混进来的英文段落单独剪切出去，判断它是同一提示词的英文版还是下一条提示词的内容。判断依据看开头——英文版通常以 "I want you to act as" 起头，和上面的中文条目主题一致；如果主题不一致，那就是串行了，把它归到下一条去。这一步花两分钟，能省掉后面半小时的困惑。
5.2 现象：模板照抄后模型开始长篇解释，输出没法直接用
现象是模型在改完文本之后，又附上一段「主要修改了以下几点」，甚至给你一个修改前后对照表，你想直接复制结果还得手动裁掉。
原因有两层。一层是提示词内部矛盾，任务段写了「提供改进建议」，约束段写了「避免包括解释」，模型两边都想满足，就折中给你一点解释。另一层是模型的默认行为倾向，大多数对话模型在没有强约束时会主动补充说明，这属于它的训练偏好，不是理解错了。
解决办法是二选一，别含糊。只要结果就在约束里写死「只输出修改后的正文，不输出任何解释、对照、前缀、后缀」，并把任务段里的「提供改进建议」删掉。要解释就把输出格式写死成两段，明确「修改后正文」和「改动理由（最多三条）」，用标题分隔。绝对不要出现「尽量」「适当」这类词，模型会把它们理解成「可以不做」。
5.3 现象：四重结构归纳十次只成一两次，输出结构每次都不一样
现象是这条提示词跑出来的结果极不稳定，有时候四部分齐全，有时候只给两部分，有时候模型自创一个第五部分。文档里作者自己也写了「很不稳定，十次里面只有一两次成功」，属于已知问题。
原因不在模型，在这条提示词本身太长且嵌套太深。它要求模型同时做四件事：提炼核心意义、围绕意义联想、标注信息来源、逐条验证准确性，而且第二部分还有「联想再联想」的多层展开。层级一多，模型很难在单次生成里全程保持结构，越往后越容易丢字段。
解决办法是把一条拆成四条，分次调用。第一次只做含义提炼，第二次只做联想扩展，第三次只标注来源（没有来源就明确输出「无」），第四次只做事实核查。每一条都短、都单一目标，稳定性立刻上来。代价是要多几轮调用，但对于需要结构化结果的场景，这个代价是值得的。那条拟人化版本（文档里标注成功率的那个）更是如此，它额外要求模型先随机生成几个角色形象、由你指定一个再扮演，这一步的随机性叠加在四重结构上，稳定才怪。要用就固定角色，别让它随机生成。
5.4 现象：多角色设定互相打架，输出变成几个人轮流说话
现象是智囊团类提示词跑出来，几个角色的观点高度雷同，或者干脆变成一段对话剧本，你要的决策建议淹没在角色扮演里。
原因有两个。一是提示词里给每个角色只有名字没有立场，模型对名字背后的观点倾向理解趋同，自然写出来就一样。二是原文里那版直接挂了几个现实中的公众人物当角色，这类设定涉及具体人物，落地时建议全部换成虚构角色，比如「成本控制型评审」「用户体验型评审」「合规风控型评审」，用立场差异代替身份差异。
解决办法是把角色设定从「是谁」改成「关心什么」。每个角色明确写一条核心关注点、一条反对倾向、一条评判标准，三个角色之间至少有一处直接冲突。冲突写进提示词，输出才会有分歧，否则模型倾向于让所有人达成共识，你就拿不到真正有价值的反对意见。
5.5 现象：输出格式漂移，第一次是列表第二次变表格
现象是同一段提示词连续跑五次，输出格式出现三种：纯文本段落、无序列表、markdown 表格。你要做后处理就得写三套解析逻辑。
原因是格式约束写得不够硬，或者被其他约束挤掉了。提示词越长，靠近末尾的约束权重越高，写在前面的格式要求容易被忽略。另外，如果输入内容本身带有表格或列表，模型会倾向于沿用输入的格式。
解决办法有两个方向。一是把格式约束挪到提示词最后一段，并且给出一个极短的样例结构，比如「输出格式：第一行 标题｜第二行 正文｜第三行 标签」，用结构描述代替「用 markdown 格式」这种模糊要求。二是在下游加一道校验，用脚本检查输出是否符合预期结构，不符合就重跑一次，别指望一次成功。校验脚本不用复杂，检查行数、检查是否包含指定分隔符、检查首行是否符合前缀约定，三条就够挡掉大部分漂移。
6. 建一个能复用的提示词库：版本号、回归集与灰度
单条提示词调好只是开始，真正省时间的是把它管起来。我自己的库结构是这样：raw放从文档里原样扒下来的条目，一个字不改，方便回溯；normalized放改过槽位和约束的可用版本；regression放测试输入和对应的期望特征；archive放被替换掉的旧版本，不删。目录用一条命令建好：
mkdir -p prompt_lib/{raw,normalized,regression,archive}分开存放的意义在于，出问题时你能快速判断是模板改坏了还是输入变了。archive千万别省，我吃过亏——某次改完一条提示词，效果明显变差，想回退却发现旧版被覆盖了，只能凭记忆重写，重写完还不如原来那版。
命名带版本号，格式用「场景_版本」，比如writing_assistant_v0.3.tpl。版本号规则简单点：改槽位或结构升次版本号，只调措辞升修订号。每条模板头部留三行注释，写清最近改动、改动原因、上一次通过率。
回归集是这套东西的核心。每条提示词配五到十条输入，覆盖短文本、长文本、含专有名词的文本、含表格的文本、空输入这几类边界。每次改完模板，全量跑一遍，记录哪些用例的输出结构变了。不用追求自动评分，人眼看结构对不对就够，重点是「每次都跑同一批」，这样前后才有可比性。
| 字段 | 示例 | 说明 |
|---|---|---|
| 编号 | WA-003 | 场景缩写加序号，便于引用 |
| 版本 | v0.3 | 结构与措辞变更分开计数 |
| 槽位 | article, word_limit | 列出全部变量名 |
| 回归用例 | 8 条 | 含 1 条空输入、2 条超长输入 |
| 最近通过 | 7/8 | 未通过的用例单独记原因 |
| 变更原因 | 删除「提供建议」消除指令冲突 | 一句话写清动机 |
灰度这一步很多人跳过，但很值。新版本先在小批输入上跑，跑通了再替换旧版。尤其是给团队共用的时候，一条提示词改动会影响所有人的输出，先灰度能避免大家一起返工。
还有个细节：模板文件里的槽位一旦确定就别随手改名。改名意味着所有调用方都要跟着改，漏一处就会在运行时报 KeyError，而报错的位置往往离真正的原因很远。
从那以后我每次动模板，哪怕只是改一个标点，都强制走一遍「改文件 → 跑回归集 → 记通过率 → 归档旧版」这四步，再没出现过改完不知道哪版好用的情况。希望帮到你。
本文还有配套的精品资源，点击获取
