简介这份资源是面向AI提示词工程师、内容创作者与对话产品开发者的实战指令合集围绕ChatGPT等大模型的内容生成能力整理出175种可直接套用的训练指令模板帮助使用者解决提示词设计零散、输出质量不稳定、场景覆盖不全等问题。包内为1个PDF文档压缩包约540KB以结构化条目形式呈现便于按需检索与复制修改。内容覆盖人工风格互联网文章写作、随机写书、人工风格改写、软文与帖子生成、民间传说文案、书籍与文章摘要、市场调研、短视频脚本、抖音文案、电商产品描述、Midjourney提示词、小说大纲、关键字与代码生成、引流脚本、励志文、黑化ChatGPT及角色扮演等方向并涉及perplexity与burstiness等改写概念。已有896人学习下载适合希望系统掌握提示词设计、提升AI内容产出效率与多样性的读者参考。1. 175种CHATGPT训练指令模板一份PDF背后提示工程师真正该抄的是什么很多人拿到「175种CHATGPT训练指令模板」这类PDF第一反应是收藏第二反应是复制粘贴第三反应是发现效果不稳定最后丢进硬盘吃灰。问题不在模板本身而在于把提示词当成了咒语而不是当成一套可调参的工程接口。这份PDF的价值不是175条现成句子而是它隐含了一套「角色—任务—约束—输出格式」的结构化写法。提示工程师Prompt Engineer真正要做的是把这些模板拆成可复用的参数再按自己的业务场景重新组装。这篇笔记面向三类人刚接触AI对话、想系统掌握prompt写法的开发者手里有一堆模板但不知道怎么落地的产品经理以及想把提示词工程接入自动化流程的工程师。接下来我会按「模板怎么读—指令怎么改—参数怎么调—坑在哪」的顺序把这份PDF里的东西拆成能直接抄作业的步骤。2. 拆解175种指令模板从角色设定到输出约束的四层结构2.1 为什么大多数模板直接复制会翻车拿到一份175种的指令模板合集最常见的用法是找到一条看起来像自己需求的整段复制进对话框。结果往往是这样第一次回答还行第二次换个问法就崩了或者输出格式每次都不一样根本没法做后续解析。血泪经验是模板不是拿来用的是拿来拆的。拆之前先理解一件事ChatGPT这类对话模型的输出本质是对输入token序列的概率续写。你给的指令越模糊模型自由发挥的空间越大输出就越不可控。175种模板之所以有效是因为它们在无意中做了同一件事——压缩模型的输出空间。压缩的方式有四种限定角色、限定任务、限定约束、限定格式。这四层结构才是模板真正的骨架。我一般拿到一条陌生模板先做一件事把它按这四层拆开标出哪些词在限定角色哪些在限定任务哪些在限定输出。拆完你会发现175种模板里真正独特的结构不超过20种剩下的都是同一结构换场景词。这意味着你不需要背175条只需要掌握20种结构再根据业务替换变量。2.2 四层结构拆解角色、任务、约束、格式先看一条典型的模板长什么样。假设PDF里有一条「让AI扮演资深产品经理写需求文档」的指令拆开大概是这个结构[角色] 你是一位有10年经验的B端产品经理擅长写PRD。 [任务] 请根据以下用户反馈写一份需求文档。 [约束] 不要编造未提及的功能优先级按用户提及频率排序每条需求必须附验收标准。 [格式] 用Markdown表格输出列为需求编号、需求描述、优先级、验收标准。 [输入] {{用户反馈内容}}这五段里角色和任务决定模型调用哪部分知识约束决定模型不能做什么格式决定输出能不能被程序消费。很多人只写了角色和任务结果就是输出忽长忽短、格式随机根本没法接入下游流程。拆解时有个技巧把「约束」和「格式」单独拎出来因为它们才是可复用的部分。角色和任务随业务变但约束和格式往往可以跨场景复用。比如「不要编造未提及的信息」这条约束几乎适用于所有需要事实准确性的场景「用Markdown表格输出」这条格式适用于所有需要结构化数据的场景。2.3 用Python批量拆解模板并提取变量175条模板靠手拆太慢我一般写个脚本先做粗分类。思路很简单把PDF转成文本后按空行或编号切分然后对每条模板做关键词匹配判断它属于哪种结构类型。import re # 假设已经把PDF文本提取成字符串 templates_text # 每条模板之间用 --- 分隔 templates templates_text.split(---) # 定义四层结构的关键词特征 role_keywords [你是一位, 你是一名, 扮演, 作为, 你的角色] task_keywords [请, 帮我, 生成, 写一份, 分析, 总结] constraint_keywords [不要, 必须, 禁止, 只能, 不得, 确保] format_keywords [格式, 表格, JSON, Markdown, 列表, 输出为] def classify(template): result {role: False, task: False, constraint: False, format: False} for kw in role_keywords: if kw in template: result[role] True break for kw in task_keywords: if kw in template: result[task] True break for kw in constraint_keywords: if kw in template: result[constraint] True break for kw in format_keywords: if kw in template: result[format] True break return result # 统计每条模板覆盖了几层 stats {4层: 0, 3层: 0, 2层: 0, 1层: 0} for t in templates: c classify(t) n sum(c.values()) if n 4: stats[4层] 1 elif n 3: stats[3层] 1 elif n 2: stats[2层] 1 else: stats[1层] 1 print(stats)这段脚本的逻辑是用关键词匹配快速判断每条模板覆盖了四层结构中的哪几层。参数方面role_keywords这类列表需要根据你手上PDF的实际用词调整比如有些模板用「假设你是」而不是「你是一位」。跑完之后你会得到一张分布图通常4层齐全的模板不到三成大部分是2到3层。那些缺格式或缺约束的模板就是你需要重点补全的对象。提示关键词匹配只是粗筛不要指望它100%准确。它的价值在于帮你快速定位哪些模板结构完整、哪些需要补而不是替代人工判断。3. 把模板改造成可复用指令变量替换与参数化写法3.1 从固定模板到参数化指令的改造步骤拆完结构之后下一步是把固定模板改造成参数化指令。所谓参数化就是把模板里写死的场景词抽成变量用占位符代替。这样一条模板就能覆盖多个场景而不是一条只干一件事。改造步骤分四步。第一步找出模板里所有跟具体业务绑定的词比如「B端产品经理」「用户反馈」「需求文档」这些就是变量。第二步给每个变量起一个语义清晰的名字比如{{role}}、{{input_type}}、{{output_type}}。第三步把变量抽出来写成带占位符的模板。第四步为每个变量定义取值范围和默认值避免调用时漏填。以刚才那条产品经理模板为例改造后是这样[角色] 你是一位有{{experience_years}}年经验的{{domain}}产品经理擅长写{{doc_type}}。 [任务] 请根据以下{{input_type}}写一份{{doc_type}}。 [约束] 不要编造未提及的功能优先级按{{sort_rule}}排序每条需求必须附验收标准。 [格式] 用{{output_format}}输出列为{{columns}}。 [输入] {{input_content}}改造完之后这条模板可以覆盖「B端/C端」「需求文档/竞品分析/用户画像」等多个组合。参数说明上experience_years建议给默认值「10」domain给「B端」output_format给「Markdown表格」。这样即使调用方漏填也有兜底。3.2 用Jinja2管理指令模板与变量注入手工替换占位符容易出错尤其是模板多了之后。我一般用Jinja2来做模板渲染因为它支持条件判断和循环能处理更复杂的指令逻辑。from jinja2 import Template prompt_template Template( [角色] 你是一位有{{ experience_years }}年经验的{{ domain }}产品经理擅长写{{ doc_type }}。 [任务] 请根据以下{{ input_type }}写一份{{ doc_type }}。 [约束] - 不要编造未提及的功能 - 优先级按{{ sort_rule }}排序 {% if require_acceptance %} - 每条需求必须附验收标准 {% endif %} [格式] 用{{ output_format }}输出列为{{ columns | join(、) }}。 [输入] {{ input_content }} ) # 渲染 result prompt_template.render( experience_years10, domainB端, doc_type需求文档, input_type用户反馈, sort_rule用户提及频率, require_acceptanceTrue, output_formatMarkdown表格, columns[需求编号, 需求描述, 优先级, 验收标准], input_content用户反馈希望增加批量导出功能…… ) print(result)这段代码的关键在于{% if require_acceptance %}这个条件块它让同一条模板可以根据场景决定是否启用某条约束。参数方面columns用列表传入渲染时用join拼成字符串input_content建议做长度截断避免超过模型上下文窗口。Jinja2的好处是模板和代码分离产品经理改模板不用动Python代码工程师改逻辑不用动模板。3.3 指令版本管理与A/B测试的最小实践模板改多了之后最大的问题是「改完不如改前」。我踩过的坑是凭感觉调了一版上线后发现效果变差但已经忘了上一版长什么样。后来我养成了一个习惯每条指令模板都带版本号改动必须记录。最小实践是这样在模板文件头部加一行注释记录版本、日期、改动点。然后用一个简单的JSON文件管理版本映射。{ prd_writer: { current: v3, versions: { v1: {file: prd_writer_v1.j2, date: 2024-01-10, note: 初版}, v2: {file: prd_writer_v2.j2, date: 2024-01-15, note: 增加验收标准约束}, v3: {file: prd_writer_v3.j2, date: 2024-01-20, note: 调整优先级排序规则} } } }A/B测试的做法是同一批输入分别用两个版本渲染把输出并排对比。对比维度建议固定三个格式合规率、事实准确率、人工可用率。格式合规率看输出能不能被程序解析事实准确率看有没有编造人工可用率看人愿不愿意直接用。三个维度都达标才切换current版本。注意不要同时改多个变量。一次只改一个参数否则出了问题根本不知道是哪个改动导致的。这是玄学调参和工程调参的分界线。4. 提示工程师的调参手册温度、token与上下文窗口4.1 温度与top_p什么场景该调、调到多少提示词写得好参数没配对效果照样翻车。最常见的两个参数是temperature和top_p。temperature控制输出的随机性值越高越随机值越低越确定。top_p控制候选词的累积概率阈值值越低候选越少输出越保守。我一般按场景给默认值。需要事实准确、格式稳定的场景比如写需求文档、提取结构化数据temperature给0到0.3top_p给0.1到0.5。需要创意发散的场景比如写文案、头脑风暴temperature给0.7到1.0top_p给0.8到1.0。需要平衡的场景比如总结、改写temperature给0.3到0.7top_p给0.5到0.9。有个容易忽略的点temperature和top_p不建议同时调高。两个都高输出会飘得没法用。我一般固定一个调另一个优先调temperature因为它更直观。4.2 token预算与上下文窗口的分配策略prompt token是另一个高频踩坑点。很多人写指令时恨不得把所有背景都塞进去结果要么超了上下文窗口要么把关键指令挤到后面模型注意力被稀释。我的分配策略是指令部分控制在总预算的20%以内输入数据占50%留30%给输出。如果输入数据太长先做摘要或分段不要硬塞。上下文窗口方面不同模型不一样但通用原则是关键指令放开头和结尾中间放数据。因为模型对开头和结尾的注意力更强中间容易「遗忘」。def build_prompt(instruction, data, max_tokens4096): # 粗略估算1个中文字符约等于1.5个token instruction_tokens len(instruction) * 1.5 data_tokens len(data) * 1.5 reserved_for_output max_tokens * 0.3 if instruction_tokens data_tokens reserved_for_output max_tokens: # 数据太长先截断或摘要 available max_tokens - instruction_tokens - reserved_for_output data data[:int(available / 1.5)] return f{instruction}\n\n[输入数据]\n{data}这段代码的逻辑是先估算指令和数据的token量如果超预算就截断数据。参数max_tokens根据你用的模型填reserved_for_output建议不低于30%。注意这只是粗估实际token数用对应模型的tokenizer算更准。4.3 用系统指令与用户指令分层控制输出很多模型支持系统指令system prompt和用户指令user prompt分层。系统指令用来定角色和全局约束用户指令用来传具体任务和数据。分层的好处是系统指令可以复用不用每次重复写。system_prompt 你是一位资深产品经理擅长写需求文档。 约束 1. 不要编造未提及的功能 2. 每条需求必须附验收标准 3. 输出用Markdown表格列为需求编号、需求描述、优先级、验收标准 user_prompt 请根据以下用户反馈写需求文档 用户反馈希望增加批量导出功能导出格式支持Excel和CSV……这样分层的写法系统指令一次写好后续所有需求文档任务都能复用。参数方面系统指令建议控制在200字以内太长会占用上下文预算。用户指令里只放变化的部分不要重复系统指令里已有的约束。5. 避坑与排查提示词工程里最容易翻车的5个地方5.1 输出格式随机变化程序无法解析现象同一套指令第一次输出Markdown表格第二次输出纯文本列表第三次夹了一堆解释性文字。原因格式约束写得太模糊比如只写了「用表格输出」没指定表格类型和列名。解决格式约束必须具体到列名、分隔符、是否允许额外文字。我一般会加一句「只输出表格不要任何解释性文字」并在代码侧做格式校验不合格就重试。5.2 模型编造未提及的信息现象输入里没提的功能模型自己加上了还写得有模有样。原因约束里没写「不要编造」或者写了但位置太靠前被后续内容稀释。解决把「不要编造未提及的信息」这条约束放在指令末尾并在输入数据前后各加一次。另外temperature调到0.3以下能明显降低编造概率。5.3 指令太长导致关键约束被忽略现象指令写了500字模型只执行了前100字的要求后面的约束像没看见。原因上下文窗口内模型对中间部分的注意力最弱。解决把关键约束放开头和结尾中间放数据。如果指令确实长拆成系统指令和用户指令两层系统指令只放最核心的3条约束。5.4 变量替换后语义漂移现象模板里写的是「B端产品经理」变量替换成「C端」后输出风格没变还是B端那套。原因变量只替换了词但模型对「C端」的理解没被激活。解决在变量旁边加一句解释比如{{domain}}产品经理{{domain}}的特点是……或者给变量加取值范围枚举让模型知道可选值有哪些。5.5 多轮对话中指令被历史稀释现象第一轮效果很好聊到第五轮模型开始跑偏忘了最初的约束。原因多轮对话里历史消息会占用上下文早期指令被挤到后面。解决每轮对话都重新注入核心约束或者用系统指令固定约束。如果对话很长定期做一次「指令重述」把核心约束再发一遍。6. 进阶技巧把175种模板变成你自己的指令库6.1 建立指令库的目录结构与命名规范175种模板拆完之后如果不做整理很快又会变成一堆散落的文本。我的做法是建一个指令库按「场景/任务」两级目录组织每个指令一个文件文件名带版本号。prompt_library/ ├── writing/ │ ├── prd_writer_v3.j2 │ ├── user_story_v2.j2 │ └── release_note_v1.j2 ├── analysis/ │ ├── feedback_summary_v2.j2 │ └── competitor_analysis_v1.j2 └── extraction/ ├── entity_extract_v3.j2 └── table_parse_v2.j2命名规范建议用「任务名_版本号.j2」任务名用小写加下划线。每个文件头部写清楚适用场景、输入变量、输出格式、已知限制。这样别人拿到你的指令库不用问你也知道怎么用。6.2 用评测集验证指令效果指令改完到底有没有变好不能靠感觉。我一般会建一个小评测集20到50条输入覆盖典型场景和边界情况。每次改指令跑一遍评测集对比三个指标格式合规率、事实准确率、人工可用率。指标计算方式合格线格式合规率能被程序解析的输出数 / 总输出数≥95%事实准确率无编造信息的输出数 / 总输出数≥90%人工可用率人工评估可直接使用的输出数 / 总输出数≥80%评测集不用大但要有代表性。我一般会放三类样本典型输入、边界输入比如空输入、超长输入、对抗输入比如故意误导的输入。跑完评测集如果三个指标都达标才切换版本。6.3 从模板到工作流把指令接入自动化流程指令库建好之后下一步是接入自动化流程。最常见的做法是用API调用把指令渲染和模型调用串起来。import openai from jinja2 import Template def run_prompt(template_path, variables, modelgpt-4, temperature0.3): with open(template_path, r, encodingutf-8) as f: template Template(f.read()) prompt template.render(**variables) response openai.ChatCompletion.create( modelmodel, messages[ {role: system, content: 你是一位资深产品经理。}, {role: user, content: prompt} ], temperaturetemperature, max_tokens2000 ) return response.choices[0].message.content这段代码把模板渲染和API调用串在一起参数temperature默认0.3适合需要稳定输出的场景。max_tokens根据输出长度需求调整建议留20%余量。接入自动化流程后指令库就不再是静态文档而是可调用的服务。我自己的习惯是每接手一个新场景先翻指令库看有没有能复用的没有就新建一条拆成四层结构跑评测集达标后入库。这样积累下来175种模板最终会变成你自己的几十条高复用指令而不是175条躺在硬盘里的文本。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向AI提示词工程师、内容创作者与对话产品开发者的实战指令合集围绕ChatGPT等大模型的内容生成能力整理出175种可直接套用的训练指令模板帮助使用者解决提示词设计零散、输出质量不稳定、场景覆盖不全等问题。包内为1个PDF文档压缩包约540KB以结构化条目形式呈现便于按需检索与复制修改。内容覆盖人工风格互联网文章写作、随机写书、人工风格改写、软文与帖子生成、民间传说文案、书籍与文章摘要、市场调研、短视频脚本、抖音文案、电商产品描述、Midjourney提示词、小说大纲、关键字与代码生成、引流脚本、励志文、黑化ChatGPT及角色扮演等方向并涉及perplexity与burstiness等改写概念。已有896人学习下载适合希望系统掌握提示词设计、提升AI内容产出效率与多样性的读者参考。1. 175种CHATGPT训练指令模板一份PDF背后提示工程师真正该抄的是什么很多人拿到「175种CHATGPT训练指令模板」这类PDF第一反应是收藏第二反应是复制粘贴第三反应是发现效果不稳定最后丢进硬盘吃灰。问题不在模板本身而在于把提示词当成了咒语而不是当成一套可调参的工程接口。这份PDF的价值不是175条现成句子而是它隐含了一套「角色—任务—约束—输出格式」的结构化写法。提示工程师Prompt Engineer真正要做的是把这些模板拆成可复用的参数再按自己的业务场景重新组装。这篇笔记面向三类人刚接触AI对话、想系统掌握prompt写法的开发者手里有一堆模板但不知道怎么落地的产品经理以及想把提示词工程接入自动化流程的工程师。接下来我会按「模板怎么读—指令怎么改—参数怎么调—坑在哪」的顺序把这份PDF里的东西拆成能直接抄作业的步骤。2. 拆解175种指令模板从角色设定到输出约束的四层结构2.1 为什么大多数模板直接复制会翻车拿到一份175种的指令模板合集最常见的用法是找到一条看起来像自己需求的整段复制进对话框。结果往往是这样第一次回答还行第二次换个问法就崩了或者输出格式每次都不一样根本没法做后续解析。血泪经验是模板不是拿来用的是拿来拆的。拆之前先理解一件事ChatGPT这类对话模型的输出本质是对输入token序列的概率续写。你给的指令越模糊模型自由发挥的空间越大输出就越不可控。175种模板之所以有效是因为它们在无意中做了同一件事——压缩模型的输出空间。压缩的方式有四种限定角色、限定任务、限定约束、限定格式。这四层结构才是模板真正的骨架。我一般拿到一条陌生模板先做一件事把它按这四层拆开标出哪些词在限定角色哪些在限定任务哪些在限定输出。拆完你会发现175种模板里真正独特的结构不超过20种剩下的都是同一结构换场景词。这意味着你不需要背175条只需要掌握20种结构再根据业务替换变量。2.2 四层结构拆解角色、任务、约束、格式先看一条典型的模板长什么样。假设PDF里有一条「让AI扮演资深产品经理写需求文档」的指令拆开大概是这个结构[角色] 你是一位有10年经验的B端产品经理擅长写PRD。 [任务] 请根据以下用户反馈写一份需求文档。 [约束] 不要编造未提及的功能优先级按用户提及频率排序每条需求必须附验收标准。 [格式] 用Markdown表格输出列为需求编号、需求描述、优先级、验收标准。 [输入] {{用户反馈内容}}这五段里角色和任务决定模型调用哪部分知识约束决定模型不能做什么格式决定输出能不能被程序消费。很多人只写了角色和任务结果就是输出忽长忽短、格式随机根本没法接入下游流程。拆解时有个技巧把「约束」和「格式」单独拎出来因为它们才是可复用的部分。角色和任务随业务变但约束和格式往往可以跨场景复用。比如「不要编造未提及的信息」这条约束几乎适用于所有需要事实准确性的场景「用Markdown表格输出」这条格式适用于所有需要结构化数据的场景。2.3 用Python批量拆解模板并提取变量175条模板靠手拆太慢我一般写个脚本先做粗分类。思路很简单把PDF转成文本后按空行或编号切分然后对每条模板做关键词匹配判断它属于哪种结构类型。import re # 假设已经把PDF文本提取成字符串 templates_text # 每条模板之间用 --- 分隔 templates templates_text.split(---) # 定义四层结构的关键词特征 role_keywords [你是一位, 你是一名, 扮演, 作为, 你的角色] task_keywords [请, 帮我, 生成, 写一份, 分析, 总结] constraint_keywords [不要, 必须, 禁止, 只能, 不得, 确保] format_keywords [格式, 表格, JSON, Markdown, 列表, 输出为] def classify(template): result {role: False, task: False, constraint: False, format: False} for kw in role_keywords: if kw in template: result[role] True break for kw in task_keywords: if kw in template: result[task] True break for kw in constraint_keywords: if kw in template: result[constraint] True break for kw in format_keywords: if kw in template: result[format] True break return result # 统计每条模板覆盖了几层 stats {4层: 0, 3层: 0, 2层: 0, 1层: 0} for t in templates: c classify(t) n sum(c.values()) if n 4: stats[4层] 1 elif n 3: stats[3层] 1 elif n 2: stats[2层] 1 else: stats[1层] 1 print(stats)这段脚本的逻辑是用关键词匹配快速判断每条模板覆盖了四层结构中的哪几层。参数方面role_keywords这类列表需要根据你手上PDF的实际用词调整比如有些模板用「假设你是」而不是「你是一位」。跑完之后你会得到一张分布图通常4层齐全的模板不到三成大部分是2到3层。那些缺格式或缺约束的模板就是你需要重点补全的对象。提示关键词匹配只是粗筛不要指望它100%准确。它的价值在于帮你快速定位哪些模板结构完整、哪些需要补而不是替代人工判断。3. 把模板改造成可复用指令变量替换与参数化写法3.1 从固定模板到参数化指令的改造步骤拆完结构之后下一步是把固定模板改造成参数化指令。所谓参数化就是把模板里写死的场景词抽成变量用占位符代替。这样一条模板就能覆盖多个场景而不是一条只干一件事。改造步骤分四步。第一步找出模板里所有跟具体业务绑定的词比如「B端产品经理」「用户反馈」「需求文档」这些就是变量。第二步给每个变量起一个语义清晰的名字比如{{role}}、{{input_type}}、{{output_type}}。第三步把变量抽出来写成带占位符的模板。第四步为每个变量定义取值范围和默认值避免调用时漏填。以刚才那条产品经理模板为例改造后是这样[角色] 你是一位有{{experience_years}}年经验的{{domain}}产品经理擅长写{{doc_type}}。 [任务] 请根据以下{{input_type}}写一份{{doc_type}}。 [约束] 不要编造未提及的功能优先级按{{sort_rule}}排序每条需求必须附验收标准。 [格式] 用{{output_format}}输出列为{{columns}}。 [输入] {{input_content}}改造完之后这条模板可以覆盖「B端/C端」「需求文档/竞品分析/用户画像」等多个组合。参数说明上experience_years建议给默认值「10」domain给「B端」output_format给「Markdown表格」。这样即使调用方漏填也有兜底。3.2 用Jinja2管理指令模板与变量注入手工替换占位符容易出错尤其是模板多了之后。我一般用Jinja2来做模板渲染因为它支持条件判断和循环能处理更复杂的指令逻辑。from jinja2 import Template prompt_template Template( [角色] 你是一位有{{ experience_years }}年经验的{{ domain }}产品经理擅长写{{ doc_type }}。 [任务] 请根据以下{{ input_type }}写一份{{ doc_type }}。 [约束] - 不要编造未提及的功能 - 优先级按{{ sort_rule }}排序 {% if require_acceptance %} - 每条需求必须附验收标准 {% endif %} [格式] 用{{ output_format }}输出列为{{ columns | join(、) }}。 [输入] {{ input_content }} ) # 渲染 result prompt_template.render( experience_years10, domainB端, doc_type需求文档, input_type用户反馈, sort_rule用户提及频率, require_acceptanceTrue, output_formatMarkdown表格, columns[需求编号, 需求描述, 优先级, 验收标准], input_content用户反馈希望增加批量导出功能…… ) print(result)这段代码的关键在于{% if require_acceptance %}这个条件块它让同一条模板可以根据场景决定是否启用某条约束。参数方面columns用列表传入渲染时用join拼成字符串input_content建议做长度截断避免超过模型上下文窗口。Jinja2的好处是模板和代码分离产品经理改模板不用动Python代码工程师改逻辑不用动模板。3.3 指令版本管理与A/B测试的最小实践模板改多了之后最大的问题是「改完不如改前」。我踩过的坑是凭感觉调了一版上线后发现效果变差但已经忘了上一版长什么样。后来我养成了一个习惯每条指令模板都带版本号改动必须记录。最小实践是这样在模板文件头部加一行注释记录版本、日期、改动点。然后用一个简单的JSON文件管理版本映射。{ prd_writer: { current: v3, versions: { v1: {file: prd_writer_v1.j2, date: 2024-01-10, note: 初版}, v2: {file: prd_writer_v2.j2, date: 2024-01-15, note: 增加验收标准约束}, v3: {file: prd_writer_v3.j2, date: 2024-01-20, note: 调整优先级排序规则} } } }A/B测试的做法是同一批输入分别用两个版本渲染把输出并排对比。对比维度建议固定三个格式合规率、事实准确率、人工可用率。格式合规率看输出能不能被程序解析事实准确率看有没有编造人工可用率看人愿不愿意直接用。三个维度都达标才切换current版本。注意不要同时改多个变量。一次只改一个参数否则出了问题根本不知道是哪个改动导致的。这是玄学调参和工程调参的分界线。4. 提示工程师的调参手册温度、token与上下文窗口4.1 温度与top_p什么场景该调、调到多少提示词写得好参数没配对效果照样翻车。最常见的两个参数是temperature和top_p。temperature控制输出的随机性值越高越随机值越低越确定。top_p控制候选词的累积概率阈值值越低候选越少输出越保守。我一般按场景给默认值。需要事实准确、格式稳定的场景比如写需求文档、提取结构化数据temperature给0到0.3top_p给0.1到0.5。需要创意发散的场景比如写文案、头脑风暴temperature给0.7到1.0top_p给0.8到1.0。需要平衡的场景比如总结、改写temperature给0.3到0.7top_p给0.5到0.9。有个容易忽略的点temperature和top_p不建议同时调高。两个都高输出会飘得没法用。我一般固定一个调另一个优先调temperature因为它更直观。4.2 token预算与上下文窗口的分配策略prompt token是另一个高频踩坑点。很多人写指令时恨不得把所有背景都塞进去结果要么超了上下文窗口要么把关键指令挤到后面模型注意力被稀释。我的分配策略是指令部分控制在总预算的20%以内输入数据占50%留30%给输出。如果输入数据太长先做摘要或分段不要硬塞。上下文窗口方面不同模型不一样但通用原则是关键指令放开头和结尾中间放数据。因为模型对开头和结尾的注意力更强中间容易「遗忘」。def build_prompt(instruction, data, max_tokens4096): # 粗略估算1个中文字符约等于1.5个token instruction_tokens len(instruction) * 1.5 data_tokens len(data) * 1.5 reserved_for_output max_tokens * 0.3 if instruction_tokens data_tokens reserved_for_output max_tokens: # 数据太长先截断或摘要 available max_tokens - instruction_tokens - reserved_for_output data data[:int(available / 1.5)] return f{instruction}\n\n[输入数据]\n{data}这段代码的逻辑是先估算指令和数据的token量如果超预算就截断数据。参数max_tokens根据你用的模型填reserved_for_output建议不低于30%。注意这只是粗估实际token数用对应模型的tokenizer算更准。4.3 用系统指令与用户指令分层控制输出很多模型支持系统指令system prompt和用户指令user prompt分层。系统指令用来定角色和全局约束用户指令用来传具体任务和数据。分层的好处是系统指令可以复用不用每次重复写。system_prompt 你是一位资深产品经理擅长写需求文档。 约束 1. 不要编造未提及的功能 2. 每条需求必须附验收标准 3. 输出用Markdown表格列为需求编号、需求描述、优先级、验收标准 user_prompt 请根据以下用户反馈写需求文档 用户反馈希望增加批量导出功能导出格式支持Excel和CSV……这样分层的写法系统指令一次写好后续所有需求文档任务都能复用。参数方面系统指令建议控制在200字以内太长会占用上下文预算。用户指令里只放变化的部分不要重复系统指令里已有的约束。5. 避坑与排查提示词工程里最容易翻车的5个地方5.1 输出格式随机变化程序无法解析现象同一套指令第一次输出Markdown表格第二次输出纯文本列表第三次夹了一堆解释性文字。原因格式约束写得太模糊比如只写了「用表格输出」没指定表格类型和列名。解决格式约束必须具体到列名、分隔符、是否允许额外文字。我一般会加一句「只输出表格不要任何解释性文字」并在代码侧做格式校验不合格就重试。5.2 模型编造未提及的信息现象输入里没提的功能模型自己加上了还写得有模有样。原因约束里没写「不要编造」或者写了但位置太靠前被后续内容稀释。解决把「不要编造未提及的信息」这条约束放在指令末尾并在输入数据前后各加一次。另外temperature调到0.3以下能明显降低编造概率。5.3 指令太长导致关键约束被忽略现象指令写了500字模型只执行了前100字的要求后面的约束像没看见。原因上下文窗口内模型对中间部分的注意力最弱。解决把关键约束放开头和结尾中间放数据。如果指令确实长拆成系统指令和用户指令两层系统指令只放最核心的3条约束。5.4 变量替换后语义漂移现象模板里写的是「B端产品经理」变量替换成「C端」后输出风格没变还是B端那套。原因变量只替换了词但模型对「C端」的理解没被激活。解决在变量旁边加一句解释比如{{domain}}产品经理{{domain}}的特点是……或者给变量加取值范围枚举让模型知道可选值有哪些。5.5 多轮对话中指令被历史稀释现象第一轮效果很好聊到第五轮模型开始跑偏忘了最初的约束。原因多轮对话里历史消息会占用上下文早期指令被挤到后面。解决每轮对话都重新注入核心约束或者用系统指令固定约束。如果对话很长定期做一次「指令重述」把核心约束再发一遍。6. 进阶技巧把175种模板变成你自己的指令库6.1 建立指令库的目录结构与命名规范175种模板拆完之后如果不做整理很快又会变成一堆散落的文本。我的做法是建一个指令库按「场景/任务」两级目录组织每个指令一个文件文件名带版本号。prompt_library/ ├── writing/ │ ├── prd_writer_v3.j2 │ ├── user_story_v2.j2 │ └── release_note_v1.j2 ├── analysis/ │ ├── feedback_summary_v2.j2 │ └── competitor_analysis_v1.j2 └── extraction/ ├── entity_extract_v3.j2 └── table_parse_v2.j2命名规范建议用「任务名_版本号.j2」任务名用小写加下划线。每个文件头部写清楚适用场景、输入变量、输出格式、已知限制。这样别人拿到你的指令库不用问你也知道怎么用。6.2 用评测集验证指令效果指令改完到底有没有变好不能靠感觉。我一般会建一个小评测集20到50条输入覆盖典型场景和边界情况。每次改指令跑一遍评测集对比三个指标格式合规率、事实准确率、人工可用率。指标计算方式合格线格式合规率能被程序解析的输出数 / 总输出数≥95%事实准确率无编造信息的输出数 / 总输出数≥90%人工可用率人工评估可直接使用的输出数 / 总输出数≥80%评测集不用大但要有代表性。我一般会放三类样本典型输入、边界输入比如空输入、超长输入、对抗输入比如故意误导的输入。跑完评测集如果三个指标都达标才切换版本。6.3 从模板到工作流把指令接入自动化流程指令库建好之后下一步是接入自动化流程。最常见的做法是用API调用把指令渲染和模型调用串起来。import openai from jinja2 import Template def run_prompt(template_path, variables, modelgpt-4, temperature0.3): with open(template_path, r, encodingutf-8) as f: template Template(f.read()) prompt template.render(**variables) response openai.ChatCompletion.create( modelmodel, messages[ {role: system, content: 你是一位资深产品经理。}, {role: user, content: prompt} ], temperaturetemperature, max_tokens2000 ) return response.choices[0].message.content这段代码把模板渲染和API调用串在一起参数temperature默认0.3适合需要稳定输出的场景。max_tokens根据输出长度需求调整建议留20%余量。接入自动化流程后指令库就不再是静态文档而是可调用的服务。我自己的习惯是每接手一个新场景先翻指令库看有没有能复用的没有就新建一条拆成四层结构跑评测集达标后入库。这样积累下来175种模板最终会变成你自己的几十条高复用指令而不是175条躺在硬盘里的文本。希望帮到你。本文还有配套的精品资源点击获取
