ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Claude2提示词工程实战:从高级Prompt到本地提示词库

Claude2提示词工程实战:从高级Prompt到本地提示词库 简介《50个Claude2提示词高级Prompts让工作逆天提效》是一份面向职场人士与团队管理者的实用提示词手册汇集五十个可直接调用的Claude2高级指令覆盖学习新技能、复杂项目拆解、会议主持、任务自动化、日常例程优化等多个高频工作场景。文件为单个docx文档共一个文件大小约十五KB轻量便携便于下载后随时查阅与复制调用。目前已有五百九十四人学习浏览。每个提示词均配有中英文对照和逐步操作指引例如“从零掌握新技能”“紧迫期限下准备交付物”“管理多个截止日期”“避免工作疲劳”等均提供了可落地的执行路径。读者只需将实际任务填入对应模板即可获得Claude2条理清晰的输出结果有效减少设计提示词和反复试错的时间让日常工作从琐碎无序变为标准化流程进而显著提升个人生产力与团队协作效率尤其适合需要同时推进多个项目、优化任务优先级的中高阶职场用户。1. 花一分钟想清楚Claude2提示词清单到底该怎么吃同样的Claude2有人拿它闲聊有人拿它当半个员工。差别往往不在模型而在你手上有没有一批打磨过的高级提示词——这正是“50个Claude2提示词高级Prompts让工作逆天提效”这类文档能传开的原因它把提效这件事从“靠灵感”变成了“靠清单”。不过我也见过太多人拿到手就复制粘贴结果该翻车还是翻车。下面不打算替你逐条复述文档而是按一线用法拆开提示词怎么组织、50个提示词怎么分桶、怎么建成本地提示词库、参数怎么配、坑在哪最后补一个让输出质量再升一档的自审技巧。适合正在用Claude2处理写作、编程、数据分析和复盘的人也适合想从“问一句答一句”升级到“一次把活干对”的人。2. 高级提示词的底层结构为什么你的Prompt总是不出活2.1 普通提示词为什么总在工作里翻车先看懂模型的“猜”与“编”先看一个典型工作提示词“请帮我把这段文字润色一下。”这种指令给到Claude2大概率得到一段“看起来更正式、实际上没变化”的文字。原因不是模型笨而是它根本不知道你要的“润色”是什么标准是压缩字数还是扩写是口语改书面还是保留个人风格要不要保留专业术语段与段之间要不要加小标题这些全是提示词工程里说的“未定义需求”。模型只能按照训练数据里的平均印象猜一个答案而平均答案在真实工作里恰恰是最不可用的。翻车还有一种常见情况是上下文污染。你让Claude2先翻译一段话再让它写一封邮件它会把翻译腔带进邮件。模型在同一个对话里会持续受前面内容影响这不是玄学而是自回归生成的基本性格相邻的token权重高前文把风格带偏了后文就会跟着歪。所以高级提示词的第一作用是每次用一条独立、完整、自洽的指令把需求界定清楚减少模型自己猜的部分。提示词工程这个词被讲得很玄落到日常里其实就是三件事把任务说清、把约束说清、把交付格式说清。能做到这三件事你的输入就已经超过了大多数“请帮我写一下”。普通提示词和高级提示词的差距也在这里普通提示词只有“任务”高级提示词有“任务约束格式示例”后者相当于把验收标准提前写进了指令里模型不再需要猜你的口味。2.2 提示词设计的三个固定组件角色、任务、约束第一个组件是角色设定。它不是让模型玩角色扮演而是给它一个“从哪个角度回答问题”的定位。比如“你是一个有十年经验的科技媒体编辑”这句话会显著影响用词和结构偏好。第二个组件是任务描述要具体到动作改写、提取、对比、生成、排查而不是含糊的“处理”。任务描述里最好带上输入材料的位置和长度比如“下面引号中是原始文案约200字”。第三个组件是输出约束包括格式、长度、语气、禁忌。这是最容易偷懒的一环也是决定输出能不能直接用的关键。三个组件之外我习惯再加一个可选组件参考示例。给一段“输入→输出”的对照比写十句抽象要求都管用。比如你想让模型按某种风格改写给它一段“原文→改后文”的示例格式问题瞬间解决。这一条在50个提示词里几乎通用后面每个模板我都在合适位置留了示例位。提示词设计到这里基本骨架就立住了。组件说起来不复杂但为什么很多人写提示词时总是漏因为脑子里默认“模型应该懂我”。从业久了你就会发现模型最不懂的就是“你脑子里的默认值”。把默认值逐条写出来提示词的质量立刻就稳了。我给自己定过一个习惯每条提示词写完先问三句——它知道输入是什么吗它知道输出长什么样吗它知道不能做什么吗三句都能答上这条提示词才算合格。2.3 最小可用的Claude2提示词模板从复制到能跑你是{角色}。请完成以下任务不要遗漏任何一条要求。 原始材料 {粘贴你的材料} 任务 1. {任务动作一} 2. {任务动作二} 输出要求 - 格式{标题/表格/段落} - 长度{字数范围} - 语气{正式/口语/中性} - 禁忌{不要出现的内容} 参考示例 输入{示例输入} 输出{示例输出} 请先输出你的理解再开始执行。这个模板的逻辑并不复杂角色设定限定视角任务动作限定步骤输出要求限定交付标准参考示例限定格式。最后一句“请先输出你的理解”是关键——它强迫模型把需求复述一遍等于让你在动手前有机会发现提示词里的两义性。如果你看到模型复述的理解和你的需求不一致直接改提示词不用浪费一整轮输出。这一段代码块里的占位符就是后面“50个提示词”全部模板的通用骨架。参数说明网页版Claude2没有开放temperature调节但API调用时有几个参数会直接影响这套模板的效果。temperature控制随机性0.2左右适合写代码和数据分析0.7左右适合文案改写top_p和temperature作用类似二选一调就行别同时猛拉。max_tokens决定了模型最多输出多少字如果你的任务本身要生成2500字默认的2048个token会直接把后半截截掉——这种截断问题在长文档场景里非常常见后面避坑章还会再说。2.4 temperature、top_p与max_tokens提示词参数取值表参数作用建议值注意事项temperature控制随机性越低越确定代码/数据分析 0.1-0.3文案 0.6-0.8太高容易胡编太低容易车轱辘话top_p控制候选词范围一般保持默认和temperature择一调节别同时乱拉max_tokens输出长度上限按目标字数再加30%余量截断时优先查这里system消息全局约束与单条提示词互补别把任务细节全塞给system参数是提示词的“后半场”。我会在每条提示词文件头加一行注释记下推荐参数例如“温度0.3max_tokens 3000”。这样从docx或Excel里抄出来用的时候不会因为环境不同而输出漂移。给一个更具体的做法把参数写进提示词文件的元信息区而不是混在指令正文里。原因是指令正文会被模型读到元信息只是你调用时的参考。再提醒一句这些参数在不同模型版本上的实际表现会有差异别把取值表当成真理。先用小样本跑三条把输出质量打过分了再批量使用。这也解释了为什么我总是建议“提示词和参数要配套记录”——提示词本身再漂亮参数不对输出照样漂。3. 50个提示词怎么分桶五个工作方向、每桶十个高频场景3.1 50个提示词的分桶逻辑五类方向、每桶十个高频场景整理这类提示词清单我的习惯不是一上来就写50条而是先分五个工作方向每个方向定十个场景再逐个填模板。这样做的好处是能对齐覆盖率你日常工作流里反复出现的动作才会被沉淀成提示词冷门的写十条也没用。参考分桶如下编号方向典型场景关键词A01-A10写作与改写新闻稿改写、邮件拟稿、长文提纲、标题生成、内容摘要、口语转书面、缩写、扩写、风格模仿、翻译定稿B01-B10编程与脚本代码解释、报错排查、SQL生成、正则编写、代码重构、测试用例、脚本生成、字段命名、代码评审、技术方案C01-C10数据分析数据口径核对、异动归因、指标梳理、报表解读、趋势分析、实验分析、用户分群、埋点核对、复盘数据、预测建模D01-D10复盘与汇报项目复盘、周报生成、会议纪要、目标拆解、OKR对齐、述职准备、风险清单、决策记录、日程梳理、经验沉淀E01-E10沟通与协调消息拟稿、需求澄清、邮件追问、会议邀请、冲突沟通、同步汇报、文档评论、面试问答、反馈给予、自我介绍注意这里的十个场景不是死的而是留白。你会发现真正到工作里用得上的是那些高频且规则清晰的动作。这也是提示词工程和普通收藏的区别收藏者囤的是数量使用者建的是索引。表里A01-A10这类编号对应到提示词库里就是检索用的主键——它让“50个”不是一个噱头而是一套可维护的清单结构。选场景还有一个标准这个任务是不是每次都要重讲一遍背景如果是就值得写成模板。比如每次写周报都要回忆格式、要列数据、要有下一步计划说明这个场景可以被固化。反之一年只做一次的“竞品调研报告”写模板的成本反而高于临时写提示词。把这三个标准记下来高频、规则清晰、重复性强。命中两条就可以进分桶。3.2 写作与改写方向三个能直接用的提示词模板第一个是风格化改写。这个模板在自媒体编辑和营销岗位里用得最多它解决的问题是“模型改完像没改”或者“模型自己加戏”。你是资深中文编辑擅长在不改变原意的前提下调整表达风格。 原始文案 {粘贴原文} 目标风格{犀利/温和/专业/口语} 改写要求 1. 保留原文所有事实信息 2. 删除空话和套话 3. 每段不超过3句话 4. 结尾给一句话钩子 输出格式改后文案并附上修改说明3-5个要点。这个模板的关键是“保留事实信息”和“删除空话”它帮模型区分了风格和内容的边界。如果你遇到过模型主动帮你加了原文没有的观点多半是没写“保留事实信息”这条。参数建议temperature取0.6因为这个任务需要在忠实和自然之间平衡太低会呆板太高会放飞。第二个是长文提纲生成。这个模板用于公众号长文、知乎回答甚至方案结构设计。核心是让模型只出骨架不出肉。你是内容策划请为一篇关于{主题}的深度文章生成提纲。 读者{目标读者} 目标字数{字数} 结构要求 1. 开头用具体场景引入不用背景介绍式开场 2. 中间分3-4个大节每节给出一个小标题 3. 每个小标题后写一句“本节要回答的问题” 4. 结尾落在行动建议上 输出格式使用Markdown有序列表不要输出正文。参数说明temperature设0.4左右提纲任务需要结构稳定随机性过强会出现各节比例失衡的问题。如果你发现模型总在给你写正文而不是提纲把“不要输出正文”改成“只输出标题与问题句禁止展开论述”约束会更硬。第三个是邮件拟稿模板我的日常使用率最高因为同一封工作邮件反复改语句是最大的浪费。你是职场沟通顾问。请根据以下要点起草一封邮件。 收件人{对象} 目的{表达感谢/催办/道歉/约时间} 关键信息{材料} 语气{客气但有边界} 输出要求 - 主题行不超过15个汉字 - 正文段落在6句以内 - 用项目符号列出需要对方确认的事项 - 不出现“冒昧打扰”“如您方便”等冗余客套语这个模板的结构亮点在最后一条把常见客套语直接列为禁忌。模型训练数据里充满这类客套你不禁止它就会用。这也是高级提示词区别于普通提示词的地方——它不只告诉模型要什么还告诉它别给什么。3.3 编程与脚本方向把Claude2当结对程序员来用这个方向对普通人和程序员都适用。程序员用它解释老代码非程序员用它生成小脚本。你没看错这就是ai编程提示词的正确打开方式先解释后生成再重构。你是资深Python工程师。请解释下面这段代码并输出改造建议。 代码 {粘贴代码} 解释要求 1. 先说这段代码在做什么一句话 2. 再逐块解释关键逻辑 3. 指出潜在问题边界情况、性能、可读性 4. 给出一个改进版本只改必要部分 输出格式先代码后解释不要倒过来。注意“只改必要部分”这句它用来防止模型把能跑的代码整体重写成它自己的风格。代码解释类任务的temperature建议0.1越确定越好。如果你准备把这段代码用于生产建议再加一句“改动需要保持对外接口不变”模型就会老老实实做局部优化。第二个是测试用例生成。很多工程师让模型写测试默认要求“帮我测一下”得到的结果往往泛泛而谈。数据驱动一点让它按输入类型生成用例。你是测试工程师。请为下面的函数设计测试用例。 函数代码 {粘贴代码} 要求 1. 覆盖正常输入、边界输入、异常输入三类 2. 每个用例注明输入、预期输出、测试目的 3. 直接用pytest写测试文件 4. 不修改被测函数参数建议temperature 0.1-0.2。测试用例需要可读性和确定性随机性越高用例的边界覆盖越不稳定。如果返回的测试文件直接能跑说明提示词写到位了。第三个是SQL生成。数据岗位的同学用这个模板的频率很高它最大的价值是让模型先讲口径再写SQL避免跑数时才发现统计口径不对。你是数据分析师熟悉{数据库类型}。请根据下面的业务需求写SQL查询。 业务需求{描述} 表结构{粘贴建表语句或字段说明} 要求 1. 先列出你对需求的理解再写SQL 2. 只查询必要的字段 3. 涉及日期字段时明确时间口径 4. 给出结果字段的口径说明 输出格式SQL代码块在前口径说明在后。这个模板解决的是模型乱写字段名的问题。把表结构直接贴进去模型就少很多猜“先列出理解”则让你在跑到数之前发现口径偏差。参数建议temperature 0.1SQL生成任务容错极低一次偏离就可能导致查询报错或统计口径错误。3.4 数据分析与复盘方向让模型先分事实再下结论数据分析类提示词最高频的用法是让Claude2先归纳再下结论而不是让它直接编结论。数据分析最忌讳模型输出“显著提升”“整体向好”这种无依据的判断。你是商业分析顾问。请根据下面的数据材料完成一份解读。 数据材料 {粘贴表格/指标数据} 业务背景{产品/项目背景} 分析步骤 1. 核对数据完整性指出缺失或异常指标 2. 找出三个关键变化并给出可能原因 3. 把变化与业务动作做关联 4. 给出下一步验证动作 输出格式 - 先用表格展示关键指标 - 结论部分不超过200字 - 不确定的判断标注“待验证”“标注‘待验证’”这句特别重要。它虽然不是硬校验但会给模型一个心理提示它不知道自己不知道的事。加了这句之后输出里的推测性语句比例会明显下降。如果你发现模型还是在编原因可以再补一句“若无数据支撑请直接说明缺少哪些数据”。复盘场景的模板也属于这一类。项目复盘写不好很大程度是事实和推测混在一起写。下面模板把这条边界强制画出来你是项目复盘主持人。请根据下面的事实材料产出一份复盘纪要。 事实材料{粘贴关键事件/时间线} 复盘要求 1. 区分“结果”与“归因”先列事实再列推测 2. 每个问题点给出一条可执行改进 3. 避免指责性表述 4. 输出三件做对的 三件可以改进的 下一步行动表 输出格式Markdown表格。这个模板的深层逻辑是模型擅长整理不擅长归因。你让它在“事实区”只列可验证的事件它就没有空间去编故事归因部分要求对应可执行改进既防止空话也让复盘能落地到行动。这是我个人觉得50个提示词里“深度学习”价值最高的一类。4. 把提示词文档落成本地提示词库从.docx到可检索的复用资产4.1 一份docx提示词文档的重新组织先拆表再建库拿到别人整理的提示词docx第一步不是读是拆结构。我一般会把它拆成一张表提示词ID、方向、使用场景、变量、提示词正文、预期输出、验证方式。拆完以后那些“一次性”的提示词会被你自然淘汰留下的才是真的能进工作流的。下面是建库时的字段建议字段说明示例ID唯一编号A01方向对应分桶写作与改写触发场景什么时候用改公众号标题变量需要替换的部分{原文},{字数}提示词正文完整模板文本见第2.3节模板预期输出判断成功标准3个备选标题验证方式怎么知道好不好人工过一遍语气与信息点这样一张表的价值在于检索等活来了你不用回忆自己囤过什么直接按触发场景过滤。这也是“50个”这个数字最有价值的地方——它不是一个数量指标而是“保证你的常用方向都有模板可用”的覆盖度设计。真正的提示词库不在docx里而在你拆出的表里。常见的错误是把docx当收藏夹整篇堆在一起要用时从头翻到尾。给自己立个规矩任何提示词入库前必须补全“触发场景”和“预期输出”两列。做不到这两点的提示词说明你自己都没想清楚它什么时候用得上。4.2 用Python批量校验提示词变量缺失与格式断裂一查便知提示词一旦多了人工检查很累容易漏。我自己写过一个检查脚本对每一行提示词做三件事查变量是否成对出现、查是否有输出要求、查是否包含角色设定。脚本不长但能省很多事import csv problems [] with open(prompts.csv, encodingutf-8) as f: for row in csv.DictReader(f): pid row[ID] text row[提示词正文] if not text.strip(): problems.append((pid, 空提示词)) if text.count({) ! text.count(}): problems.append((pid, 变量括号不配对)) if 输出 not in text and 格式 not in text: problems.append((pid, 缺少输出约束)) if not any(key in text for key in (你是, 请作为, 担任)): problems.append((pid, 缺少角色设定)) for pid, issue in problems: print(f{pid}: {issue})逻辑说明这段脚本用csv模块逐行读取提示词表把常见问题按规则筛出来。变量括号计数能防止你复制提示词时漏了一个花括号——这种错在模板里最隐蔽也最容易导致整段模板失效检查“输出/格式”关键词是在确认每条提示词都有交付标准而“你是/请作为/担任”对应三段式里的角色组件。参数说明如果你想控制检查严格度可以修改关键词列表。有的提示词本身就不需要角色设定把第三项检查删掉即可想更严格可以再加一条检查提示词正文里是否还有未替换的{花括号}防止把半成品模板放进生产环境。脚本输出是逐行打印问题数量多时可以加个计数器统计失败比例。提示词CSV文件建议用UTF-8带BOM编码保存否则Excel打开中文会乱码——这是我处理中文CSV时踩过的坑。4.3 从docx批量转成结构化CSV不再手动复制粘贴如果你的提示词清单还是docx别手动复制太慢。用python-docx可以按标题层级自动拆解把每个方向的每条提示词导成结构化数据from docx import Document import csv doc Document(Claude2提示词清单.docx) out [] current_section for para in doc.paragraphs: style para.style.name txt para.text.strip() if style.startswith(Heading 1): current_section txt continue if style.startswith(Heading 2) and txt: out.append({方向: current_section, 场景: txt, 内容: }) elif out: out[-1][内容] txt \n with open(prompts.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[方向, 场景, 内容]) writer.writeheader() writer.writerows(out)逻辑说明这个脚本用python-docx读取docx按Heading 1划分方向按Heading 2划分场景正文段落累积成提示词内容最后以utf-8-sig编码写出CSV保证Excel打开不乱码。注意先要安装依赖pip install python-docx。它读取的是Word内置样式不是眼睛看到的“加粗”。参数说明style.startswith(Heading 1)依赖Word内置样式名。中英文Word样式名有差异比如“标题 1”和“Heading 1”脚本里最好两个都判断。如果原文档所有标题都是手写加粗而不是用样式这个脚本读不到那就退一步按文本特征归类。如果这份docx是你自己整理的我建议直接另存为Markdown或纯文本再转少一层解析麻烦。这一步批量导出来的CSV再喂给4.2的校验脚本一条完整的建库流水线就通了。4.4 调用方式固定主干、替换变量、小步验证提示词库建好后调用方式建议遵循“固定主干、替换变量、小步验证”。意思是每条模板在正式使用前先跑一次样例根据输出微调措辞或参数再把“调好的一版”回写进表里。经过两三轮迭代你的提示词库才是真正属于你的而不是从docx里抄来的印刷品。还有一个容易被忽略的细节API调用里system提示词和单条提示词的配合。常见做法是把全局约束放进system比如“全程用中文回答输出使用Markdown不要编造数据”把每条具体任务放user。这样50个提示词可以共享同一套系统级规范换任务时只替换用户消息部分。网页版没有system入口但可以用“开场设定”消息达到类似效果——“以下是你需要始终遵守的全局要求……” 这个技巧能让50条提示词省掉大量重复的前缀。小步验证的具体操作是每次只改一个变量。有人习惯同时改温度和提示词翻车后不知道是哪一步造成的。正确顺序是先把提示词固定单独调参数参数定下来之后再改提示词里的任务描述。每次改动跑三条样例对比预期输出分数过了再入库。5. Claude2提示词实战避坑5条高频翻车记录与排查办法5.1 输出总被截断长文生成在结尾断掉现象让Claude2写2500字报告输出到一半戛然而止最后一句明显没写完。原因API调用时max_tokens设置不够网页版则有单次输出长度上限。模型不是不想写而是“稿纸”写到边界了。解决API调用把max_tokens提到估算字数对应长度一般按汉字字数×1.5再加余量。网页版把任务拆成“大纲→第一章→第二章”的分段生成策略。别指望一次吐完分段生成反而更稳每段结束时让模型自然停在段落边界。5.2 一本正经编数据模型给出了不存在的数字现象让模型做行业分析它给出了精确的“2025年市场规模2.7万亿”这类数字但来源不明核实后根本对不上。原因Claude2是生成模型不是数据库。你没给数据源它只能按训练时见过的分布补一个“看起来合理”的数字。这属于模型“黑匣子”里最难防的一部分。解决在提示词里明确写“只使用我给出的数据不要补充外部数据”如果必须引用市场数据要求它标注“此数字需要人工核实”。对事实类任务更稳的写法是先把信息来源文本粘贴进材料区再让模型基于材料作答。5.3 格式崩坏要表格却给散文现象提示词里写了“输出格式Markdown表格”模型返回的是带破折号的清单。原因模型对“表格”的理解跟你的展示格式之间有偏差通常是因为“预期格式”没有可视化——它不知道你要的表格长什么样。解决在提示词里直接附上期望的表格示例表头加一行数据格式就锁住了。这一条在提示词工程里叫“输出端示例”比任何文字描述都可靠。同理要JSON就贴一段JSON样例要标题就列举条数和风格。5.4 越聊越笨同一对话里改三轮越改越歪现象第一轮输出很好之后每轮“按上次风格再写”的内容越来越不齐整语气漂移。原因上下文污染。对话越长早期指令的影响被新内容稀释同时新写入的修正语句可能让模型过度解读。解决涉及多种任务时果断新开对话把“主提示词参考示例”一起粘进新会话。做对比实验时每条提示词用独立会话跑结果才有可比性。别指望一个对话里既写文案又调代码又做周报Claude2没有“跨任务记忆”只有“上下文噪声”。5.5 被安全拒答模型说“我不能帮你生成”现象明明只想让它整理工作要点模型却以安全为由拒绝。原因部分措辞触碰了模型内部的内容边界或者是任务范围写得过大被误判比如“对某件争议事件写一段评价”就容易被一把拦住。解决把任务从“评价”改成“基于以下合规材料归纳要点”把范围收窄让模型基于给定材料作答。这一条不是绕过限制而是让任务落在模型可以执行的事实整理范畴内。合规的改写和解释是正常使用方式按这个方向调整提示词即可。5.6 验证输出质量给每条提示词配验收评分在50个提示词库里每条提示词的“预期输出”字段要真写清楚比如“标题候选3条每条不超过20字覆盖犀利/温和/专业三种语气”。生成后按验收清单打分格式符合度、事实可靠性、可直接使用率每项1-5分。总得分偏低就回去改提示词而不是重跑一次碰运气。这套打分机制会把提示词迭代从“感觉不行”变成“数字不行”。我自己的习惯是分数低于12分满分15的提示词不进生产清单。分数差的提示词不是不能留而是需要回到第2章的骨架重新补组件——通常是漏了输出约束或参考示例补完之后再打分一般都能救回来。6. 反手一招让Claude2给输出做自我审校——输出级反馈回路看再多提示词模板不如掌握一个能持续提升质量的小技巧在每条提示词后面预留一轮“自审指令”。具体做法是首轮先用主模板生成紧接着扔给它一条审校指令让模型自己挑毛病、自己改。这招比反复重写提示词省事也比“再生成一次”的随机采样靠谱得多。请暂缓交付。先按以下检查清单审核你刚才的输出 1. 是否回答了所有任务点 2. 格式与要求是否一致 3. 是否存在未经验证的推断 4. 哪些地方可以更简洁 输出问题清单不超过5条然后给一份修订版。用法很简单配合第3章的分桶提示词默认都加第二轮审校。写作类让模型检查空话编程类让模型检查边界数据分析类让模型检查“推断是否有数据支撑”。我自己的习惯是审校指令固定放一个地方——提示词库表的“验证方式”字段里每次调用主模板后顺手追加。审校轮的温度可以比首轮低0.2因为它要的是收敛而不是发散。这套反馈回路跑顺之后你会发现很多“模型不行”的结论其实是冤枉了它多数时候是提示词没给它自检的机会。把它当作一个会改稿的同事而不是一台一次成型打印机效果立刻不一样。我做提示词工作这两年最大的教训就是——别急着怪模型先看看自己给没给它“返工权”。希望这个技巧也能帮到你的日常提效。本文还有配套的精品资源点击获取
返回列表