1. 为什么提示词值得当成一门手艺来练我接触AI提示词这件事最早是从帮朋友写产品文案开始的。那时候我以为提示词就是“把话说清楚”结果第一次让模型写一段电商详情页它给我返回了一篇四平八稳、毫无购买欲的说明文。后来我花了大概三个月时间反复拆解自己写过的每一条提示词对比输出质量的差异才慢慢摸到一点门道提示词不是“提问”而是“设计任务”。你给模型的不是一句话而是一份隐形的需求文档。这个认知转变非常关键。很多人觉得提示词就是“你问它答”跟搜索引擎差不多。但实际用下来你会发现搜索引擎给你的是链接列表而大语言模型给你的是“它理解之后重新组织的内容”。这意味着你输入的每一个词、每一个标点、每一处语序都会影响它理解的方向。提示词写得好模型就像一个经验丰富的执行者写得含糊它就像一个刚入职、不敢多问的新人只能靠猜。这篇文章想解决的问题很具体怎么从“随便问问”进化到“稳定产出可用结果”。我会把提示词拆成三个层面来讲——框架、模板、实战。框架解决的是“怎么想”的问题模板解决的是“怎么写”的问题实战解决的是“怎么调”的问题。适合谁看如果你已经用过一段时间AI工具但输出质量时好时坏或者你刚开始接触提示词想少走弯路那这篇内容应该能帮到你。我自己的经验是提示词能力提升最快的阶段不是看了多少教程而是开始用固定框架去约束自己的表达。下面我从整体设计思路开始拆。2. 提示词的整体设计思路与框架选型2.1 提示词的本质把模糊需求翻译成可执行指令很多人写提示词失败根本原因不在“词”上而在“需求本身就没想清楚”。你让模型“写一篇好文章”它不知道“好”的标准是什么你让模型“优化这段代码”它不知道优化目标是性能、可读性还是兼容性。提示词的第一道工序其实是自我追问我到底要什么我习惯把提示词设计分成三层目标层、约束层、格式层。目标层回答“做什么”约束层回答“不做什么、优先做什么”格式层回答“以什么形式交付”。这三层缺一层输出就容易跑偏。比如“写一封辞职信”是目标层“语气温和但坚定不抱怨公司”是约束层“300字以内分三段”是格式层。三层齐全模型才有明确的执行边界。这个思路和软件工程里的“需求规格说明书”很像。你不会跟开发说“做个好用的App”你会说“做一个面向老年人的天气App首页只显示温度和降水概率字体不小于18px”。提示词也是一样颗粒度越细返工越少。2.2 三大经典框架的适用场景与取舍逻辑市面上流传的提示词框架很多我实际用下来真正高频使用的就三个CRISPE、CO-STAR、思维链。它们不是互斥的而是针对不同任务类型的“工具箱”。CRISPE适合需要模型扮演特定角色、并且对背景信息依赖较强的任务。它的结构是Capacity角色、Request请求、Insight背景洞察、Statement具体指令、Personality风格、Experiment多版本尝试。我一般用CRISPE来写需要“专业口吻”的内容比如行业分析、技术方案、法律文书草稿。它的优势是角色和背景分离得很清楚模型不容易把“你是谁”和“你要做什么”搞混。CO-STAR更适合内容创作类任务尤其是需要控制语气和受众的场景。它的结构是Context上下文、Objective目标、Style风格、Tone语气、Audience受众、Response响应格式。我写社交媒体文案、产品介绍、邮件模板时用得最多。CO-STAR的好处是它强迫你思考“谁在看”这一点在内容创作里经常被忽略。思维链严格来说不算一个完整框架而是一种推理策略。它的核心是让模型“先想再答”通过显式要求模型展示推理步骤来提升复杂任务的准确率。我一般在数学计算、逻辑推理、多条件决策这类任务里用它。比如让模型做预算分配、排期规划、方案对比加上“请逐步分析”之后输出质量会有明显提升。这三个框架的关系可以这样理解CRISPE和CO-STAR是“任务描述框架”思维链是“推理增强策略”。你可以用CO-STAR写一个任务描述然后在具体指令里加入思维链要求。我自己的常用组合是CO-STAR搭骨架思维链补逻辑。2.3 框架不是越多越好什么时候该放弃框架这里要泼一盆冷水。框架是给复杂任务用的不是所有提示词都需要套框架。我见过有人连“今天天气怎么样”都要写一段CO-STAR这就属于过度设计。判断标准很简单如果任务本身没有歧义、不需要特定风格、不涉及多步推理直接问就行。我自己的经验法则是任务涉及三个以上约束条件或者输出需要直接用于正式场景才值得上框架。日常查资料、简单改写、快速翻译用自然语言直接说反而效率更高。框架的价值在于“防遗漏”而不是“显专业”。还有一个容易被忽略的点框架用久了会形成思维惯性。我有一段时间所有提示词都套CO-STAR结果写出来的东西越来越模板化缺乏灵活性。后来我刻意练习“无框架写作”强迫自己用最朴素的语言把需求说清楚反而发现了很多框架覆盖不到的细节。框架是拐杖最终目标是能扔掉拐杖走路。3. 七类通用模板的拆解与实操要点3.1 角色扮演类模板让模型“入戏”的正确姿势角色扮演是提示词里最常用的技巧但很多人用错了方向。常见的错误写法是“你是一个资深程序员帮我写代码。”这句话的问题在于“资深程序员”这个角色太宽泛模型不知道你是要写算法、写接口还是写脚本。我常用的角色扮演模板结构是这样的你是一位在[具体领域]有[具体年限]经验的[具体职位]你的日常工作包括[具体任务1]、[具体任务2]。你擅长用[具体方法/工具]解决[具体问题]。现在你需要帮我完成[具体任务]要求是[具体要求]。举个例子同样是写代码我会这样写你是一位在电商行业有5年经验的后端工程师日常负责订单系统和支付网关的维护。你擅长用Python和PostgreSQL处理高并发场景下的数据一致性问题。现在你需要帮我写一个订单超时自动取消的定时任务要求考虑分布式锁、幂等性和失败重试。这样写的好处是模型不仅知道“你是谁”还知道“你平时怎么干活”输出的内容会更贴近真实工作场景。我实测下来加了具体工作背景之后代码的工程化程度明显提升不再是教科书式的示例代码。还有一个细节角色扮演类提示词里不要给模型戴高帽。比如“你是世界顶级专家”“你是最厉害的设计师”这种描述对输出质量几乎没有帮助反而可能让模型过度自信忽略细节。具体的工作经验比空洞的头衔有用得多。3.2 结构化输出类模板让结果直接可用结构化输出是我用得最多的一类模板因为它的回报最直接模型返回的内容可以直接粘贴到表格、文档、代码里不需要二次整理。这类模板的核心是明确指定输出格式包括字段名、字段顺序、分隔符、空值处理方式。我常用的结构化输出模板长这样请按照以下格式输出不要添加任何额外说明字段1[内容] 字段2[内容] 字段3[内容]如果某个字段无法确定填写“待确认”不要留空。如果是表格类输出我会更具体请以Markdown表格形式输出表头为| 方案名称 | 核心思路 | 适用场景 | 实施难度 | 预期效果 | 共输出3个方案按实施难度从低到高排列。这里有个坑要注意模型对“不要添加额外说明”的执行并不总是严格。它有时候会在表格前后加一句“以下是我为您整理的方案”。如果你需要纯数据可以在提示词末尾加一句“只输出表格不要有任何前后缀文字。”我试过多次加上这句话之后纯净度会高很多。另外结构化输出模板特别适合批量任务。比如你有一批用户评论需要分类可以写一个固定模板然后把评论逐条填入。这样每次输出的格式完全一致后续用脚本处理也很方便。3.3 分步推理类模板复杂问题的拆解利器分步推理类模板的核心是“把大问题拆成小问题”让模型一步一步来。这类模板特别适合方案对比、决策分析、故障排查这类需要逻辑链条的任务。我常用的分步推理模板结构是请按以下步骤分析这个问题 第一步列出所有已知条件和约束。 第二步分析每个条件对结果的影响。 第三步提出至少3个可行方案。 第四步对比每个方案的优缺点。 第五步给出推荐方案及理由。这个模板的关键在于步骤之间要有逻辑递进不能是简单的罗列。第一步的输出应该是第二步的输入第二步的输出应该是第三步的输入。如果步骤之间没有依赖关系模型很容易在每个步骤里重复同样的内容。我踩过的一个坑是步骤太多。有一次我写了八步结果模型在第五步就开始敷衍后面的步骤明显质量下降。后来我控制在五步以内每个步骤的要求写具体输出质量就稳定了。如果任务确实复杂我会拆成两轮对话第一轮做前几步第二轮基于第一轮的结果继续。3.4 风格控制类模板让输出“像那么回事”风格控制类模板解决的是“内容对但味道不对”的问题。比如你让模型写一篇科技评论内容没问题但读起来像说明书你让模型写一段品牌文案信息都全但语气像公告。这时候就需要风格控制模板。我常用的风格控制模板会从三个维度描述风格语感、节奏、用词。请用以下风格写作 语感轻松但不随意像朋友之间聊专业话题。 节奏短句为主每段不超过4行段落之间用过渡句衔接。 用词避免“赋能”“抓手”“闭环”等套话多用具体动词和名词。如果是模仿特定风格我会提供一段参考文本请参考以下文本的风格写一段关于[主题]的内容。注意模仿其句式结构、用词习惯和段落节奏但不要照抄内容。[参考文本]这里要注意风格模仿的参考文本不宜过长200到300字就够了。太长了模型会倾向于复制原文而不是学习风格。另外如果参考文本本身质量不高模型也会学偏。我一般会选自己写的、风格稳定的段落作为参考。3.5 迭代优化类模板把“改稿”变成可复用的流程迭代优化类模板是我最近半年用得越来越多的类型。它的思路是不指望一次输出就完美而是设计一个“生成-反馈-修改”的循环。这类模板特别适合写作、设计、方案策划这类需要反复打磨的任务。我常用的迭代优化模板分两轮第一轮请根据以下要求生成[内容类型] [具体要求] 生成后请自行评估三个维度信息完整性、逻辑连贯性、语言流畅度。对每个维度打分1-10分并指出最需要改进的一个点。第二轮根据你上一轮的自我评估请针对最需要改进的点进行修改输出修改后的版本。修改时保持其他部分不变只调整你指出的问题。这个方法的妙处在于它让模型自己发现问题而不是等我指出问题。我实测下来经过一轮自我评估和修改输出质量平均能提升20%到30%。而且这个过程可以重复多轮直到满意为止。不过要注意不要让模型无限迭代。一般两到三轮就够了再多的话模型可能会为了“改而改”把原本正确的内容改错。我一般会在第三轮之后人工介入判断是否继续。3.6 约束排除类模板用“不要什么”来定义“要什么”约束排除类模板的思路是当正面描述很难说清楚时用反面描述来缩小范围。这在创意类任务里特别有用因为“好创意”很难定义但“烂大街的创意”很容易识别。我常用的约束排除模板请为[主题]生成5个创意方案。要求不要使用“科技感”“未来感”“沉浸式”这类已经被用烂的概念。不要出现“赋能”“颠覆”“革命性”等词汇。不要采用“问题-解决方案”的经典叙事结构。每个方案用一句话概括不超过30字。这种“负面清单”式的约束往往比正面要求更能激发模型的多样性。我试过让模型写产品slogan正面要求写“简洁有力”输出都很平庸换成“不要用形容词不要用感叹号不要超过8个字”出来的东西反而更有意思。约束排除类模板还有一个变体优先级排序。当多个约束条件冲突时明确告诉模型哪个优先。比如“如果简洁性和完整性冲突优先保证简洁性。”这样模型在取舍时就有依据不会左右摇摆。3.7 多轮对话类模板把一次问答变成一次协作多轮对话类模板适合那些“一次说不清”的任务。它的核心是设计一个对话流程每一轮解决一个子问题逐步逼近最终目标。这类模板在复杂咨询、方案设计、学习辅导场景里特别有用。我常用的多轮对话模板会预设对话路线我们将分三轮对话来完成[任务]。 第一轮请你先了解背景我会提供[背景信息]你只需要复述你理解的关键点不要给出建议。 第二轮基于你理解的背景提出3个初步方向每个方向用两句话说明。 第三轮我会选择一个方向你针对这个方向给出详细方案。这个模板的关键是每一轮的任务要单一。如果一轮里让模型既理解背景又提方案它很容易顾此失彼。分开之后每一轮的质量都会更高。我自己的使用心得是多轮对话模板特别适合“我自己也没想清楚”的情况。通过让模型先复述、再发散、再聚焦我往往能在对话过程中理清自己的思路。有时候模型第二轮提出的方向会触发我想到更好的方向这是单轮问答很难实现的。4. 六个实战案例的完整拆解4.1 案例一用CO-STAR写一篇产品发布文案这个案例来自我帮一个朋友的新产品写发布文案。产品是一款面向自由职业者的时间管理工具核心卖点是“自动识别任务优先级”。我一开始直接写“帮我写一篇产品发布文案”输出很平淡像新闻稿。后来改用CO-STAR框架Context一款面向自由职业者的时间管理工具核心功能是自动识别任务优先级目标用户是同时接多个项目的设计师、开发者、写作者。 Objective写一篇发布文案让读者产生“这个工具能解决我时间混乱的问题”的认知。 Style第一人称像产品创作者在分享自己的痛点。 Tone真诚、不夸张承认工具不是万能的。 Audience25到35岁的自由职业者有3年以上独立工作经验。 Response800字左右分四段痛点场景、现有方案的不足、这个工具的做法、适合谁用。输出质量比第一版好很多尤其是“承认工具不是万能的”这个语气设定让文案读起来不像广告。我后来只改了两个地方把“自动识别”改成了“帮你判断”把“提升效率”改成了“少做无用功”。这两个改动让文案更口语化更贴近目标用户的表达习惯。这个案例给我的启发是CO-STAR里最容易被忽略的是Tone和Audience。很多人只写Context和Objective结果输出要么太正式要么太随意。把语气和受众写清楚模型才知道“对谁说话、用什么姿态说话”。4.2 案例二用CRISPE生成一份技术方案对比这个案例是我自己工作中遇到的需要对比三种数据库方案用于一个中等规模的SaaS产品。我用CRISPE框架写提示词Capacity你是一位有8年经验的后端架构师经历过从单体到微服务的迁移熟悉PostgreSQL、MongoDB和TiDB的优缺点。 Request对比这三种数据库方案用于一个日活5万、数据量500GB的SaaS产品。 Insight团队只有3个后端运维能力有限希望尽量减少运维复杂度。预算中等可以接受云托管方案。 Statement从数据模型、查询性能、扩展性、运维成本、团队学习成本五个维度对比给出推荐方案。 Personality务实、不堆术语每个结论都要有依据。 Experiment先给一个简版对比表再展开详细分析。输出结果很扎实尤其是“团队只有3个后端”这个约束让模型在推荐时明显偏向运维简单的方案。最后推荐的是云托管PostgreSQL理由写得很清楚团队熟悉、运维托管、扩展性够用。这个结论和我自己的判断一致但模型补充了一些我没想到的细节比如“TiDB的分布式事务在中小规模下收益不明显反而增加调试成本”。这个案例的关键在于Insight部分要写真实约束。如果你写“预算充足、团队技术强”模型就会推荐更复杂但更“先进”的方案。约束写得越真实推荐越接地气。4.3 案例三用思维链做一次预算分配这个案例是我帮一个社群做年度预算分配。总预算12万需要分配到内容创作、活动运营、工具采购、储备金四个方向。我用了思维链提示词请按以下步骤帮我分配预算 第一步列出每个方向的必要支出项。 第二步估算每个支出项的最低成本和理想成本。 第三步根据“保证核心产出、控制固定成本、留有余量”的原则给出分配比例。 第四步检查分配后每个方向是否满足最低成本如果不满足调整比例。 第五步输出最终分配表和一句话说明。模型在第三步给出的比例是内容40%、活动30%、工具20%、储备10%。第四步检查时发现工具的最低成本需要2.8万而20%只有2.4万于是自动调整到内容38%、活动28%、工具23%、储备11%。这个自我检查的步骤是我特意加的效果很好避免了“分完才发现不够”的问题。这个案例让我意识到思维链的价值不在于“让模型想”而在于“让模型按你指定的方式想”。如果你不指定步骤模型也会推理但推理路径不可控。指定步骤之后推理过程变得可预期、可检查。4.4 案例四用结构化模板批量处理用户反馈这个案例是我帮一个做独立产品的朋友处理用户反馈。他收集了200多条用户留言需要分类整理。我设计了一个结构化模板请对以下用户反馈进行分类按以下格式输出反馈原文[原文] 分类[功能建议/体验问题/内容需求/其他] 紧急程度[高/中/低] 关键词[不超过3个] 建议处理方式[一句话]只输出结果不要任何额外说明。然后我把200条反馈分成10批每批20条逐批处理。输出结果直接粘贴到表格里半小时就完成了原本需要一整天的工作。分类准确率我抽查了30条只有2条需要手动调整准确率超过90%。这里有个细节分类标准要提前定义清楚。我在模板里没有详细解释“功能建议”和“内容需求”的区别导致有几条反馈被分错了。后来我加了一句“功能建议指对产品功能的增加或修改内容需求指对产品内提供的信息或素材的需求。”加上之后分类准确率明显提升。4.5 案例五用风格控制模板改写一段技术文档这个案例是我把自己写的一段技术文档改写成面向非技术读者的版本。原文是系统采用事件驱动架构通过消息队列实现服务间异步通信确保高并发场景下的最终一致性。我用的风格控制模板请将以下技术描述改写为面向非技术读者的版本 语感像在给朋友解释不用比喻直接说人话。 节奏一句话说清楚一件事不超过25个字。 用词避免“架构”“异步”“一致性”等术语用日常词汇替代。原文[技术描述]输出是系统里各个部分不直接互相等待而是通过一个“中转站”传递消息。这样即使同时有很多人使用系统也不会卡住数据最终会保持一致。这个改写我直接用了因为目标读者是产品经理和运营他们不需要知道“事件驱动”和“消息队列”只需要知道“系统不会卡、数据不会乱”。这个案例让我体会到风格控制的核心是“换位思考”你得先想清楚读者是谁、他们关心什么然后用他们的语言写出来。4.6 案例六用多轮对话模板做一次方案策划这个案例是我帮一个线下活动做策划。活动主题是“城市漫步”目标人群是25到35岁的上班族。我用了三轮对话第一轮我提供了背景活动目的、目标人群、预算范围、场地限制。要求模型只复述关键点不提建议。模型复述得很准确还主动问了一个我没提到的问题“活动是周末还是工作日晚上”这个问题提醒了我后来我把时间定在周六下午。第二轮我让模型基于背景提出3个方向。模型给了“主题路线型”“任务挑战型”“社交匹配型”三个方向。我选了“任务挑战型”因为目标人群是上班族他们更需要“有目标感的放松”而不是“随便走走”。第三轮我让模型针对“任务挑战型”给出详细方案包括路线设计、任务设置、时间安排、物料清单。输出很完整我基本直接用了只调整了任务难度把“寻找指定店铺”改成了“拍摄指定颜色的门”降低了执行门槛。这个案例的关键在于第一轮的“只复述不建议”。如果第一轮就让模型提建议它会在背景理解不充分的情况下给出泛泛的方案。先复述、再发散、再聚焦每一步的质量都更高。5. 常见问题与排查技巧实录5.1 输出太泛怎么让模型“说具体”这是最常见的问题。你问“怎么写好提示词”模型给你一堆“要清晰、要具体、要有结构”的正确废话。排查思路是检查你的提示词里有没有“可验证的具体要求”。“要具体”本身不具体。你得告诉模型“具体到什么程度”。比如不要写“给出建议”写“给出3条建议每条不超过20字必须包含一个动词”。不要写“分析优缺点”写“列出2个优点和2个缺点每个用一句话说明必须引用具体数据或案例”。不要写“写一段介绍”写“写一段100到150字的介绍第一句是结论后面三句是支撑理由”。我自己的经验是凡是能用数字约束的都用数字约束。字数、条数、比例、时间范围这些数字会逼着模型给出更具体的内容。5.2 输出太长怎么控制篇幅模型默认倾向于“多写”因为训练数据里长文本居多。控制篇幅的方法有三个层次第一层在提示词里明确字数范围。比如“300到400字”而不是“简短一点”。模型对具体数字的遵守程度远高于模糊描述。第二层指定结构。比如“分三段每段不超过5行”。结构约束比字数约束更有效因为模型会优先满足结构要求。第三层如果还是太长在末尾加一句“如果超出字数优先删除例子和重复说明保留核心结论。”这句话给了模型一个“删减优先级”它知道该砍哪里。我实测下来三层叠加之后篇幅控制成功率在90%以上。剩下10%的情况我会直接说“压缩到一半只保留核心信息”模型一般都能做到。5.3 输出不稳定同样的提示词为什么结果不一样这个问题困扰过我很长时间。同样的提示词早上跑和下午跑结果质量不一样。后来我总结出三个主要原因原因一上下文污染。如果是在同一个对话窗口里连续提问前面的对话内容会影响后面的输出。解决方法很简单重要任务开新对话。原因二提示词里有歧义词。比如“优化一下”可以指性能优化、可读性优化、成本优化。模型每次选的方向可能不同。解决方法把“优化”替换成具体目标比如“减少50%的运行时间”。原因三温度参数。大多数对话产品不暴露温度参数但模型本身有随机性。解决方法在提示词里加一句“请给出你最确定的一个答案不要提供多个版本”。这句话会降低输出的随机性。5.4 模型“不听话”明明说了不要还是出现这是提示词里最让人头疼的问题。你写了“不要用专业术语”输出里还是有“赋能”“闭环”。排查下来通常是因为否定指令的优先级低于肯定指令。模型会优先满足“写一段产品介绍”然后才考虑“不要用术语”。解决方法有两个方法一把否定指令改成肯定指令。不要写“不要用术语”写“用日常词汇比如‘帮忙’而不是‘赋能’‘做完’而不是‘闭环’”。给出替代方案模型更容易执行。方法二把否定指令放在最后并且加粗强调。比如“再次强调不要出现‘赋能’‘抓手’‘闭环’这三个词。”位置和强调都会提升指令的优先级。5.5 常见问题速查表问题现象可能原因排查动作解决技巧输出太泛缺少具体约束检查是否有数字、条数、字数要求用数字替代形容词输出太长未指定篇幅检查是否有字数范围加“分三段每段不超过5行”输出不稳定上下文污染或歧义词开新对话检查歧义词替换歧义词为具体目标模型不听话否定指令优先级低检查否定指令位置改否定为肯定或末尾强调格式不对格式描述不具体检查是否指定了字段和分隔符给出完整格式示例内容重复步骤之间无递进检查分步推理的逻辑链确保每步输出是下一步输入5.6 我踩过的三个坑坑一提示词写得太长。我曾经写过一段800字的提示词结果模型只关注了最后几句前面的背景全忽略了。后来我控制在300字以内把最重要的约束放在开头和结尾中间放背景信息。这样模型的注意力分配更合理。坑二一次让模型做太多事。比如“写一篇文案同时翻译成英文再生成三个标题”。模型会把精力分散每件事都做得一般。后来我拆成三轮每轮只做一件事质量明显提升。坑三忽略模型的“自我评估”能力。我以前都是自己检查输出后来发现让模型自己评估更高效。加一句“请检查你的输出是否满足以下要求如果不满足请修改后重新输出”模型的自检能力比我想象的强。6. 提示词能力的长期修炼路径提示词这件事入门容易精通难。我自己的修炼路径大概分三个阶段第一阶段是“抄模板”把别人的好提示词拿来改改用第二阶段是“拆框架”理解每个框架为什么这样设计第三阶段是“忘框架”根据任务本身设计提示词不再依赖固定结构。如果你现在处于第一阶段我的建议是先固定用CO-STAR写两周。所有需要模型输出的任务都套这个框架。两周之后你会对“上下文、目标、风格、语气、受众、格式”这六个要素形成肌肉记忆。然后再尝试CRISPE和思维链对比不同框架的输出差异。如果你已经过了第一阶段我建议你开始建立自己的提示词库。按任务类型分类写作类、分析类、代码类、创意类。每类下面存3到5个经过验证的模板。每次用的时候先选模板再根据具体任务微调。这样既保证质量稳定又不会太耗时。还有一个习惯我坚持了很久每次输出不满意时不要直接改提示词先问自己“我到底哪里没说清楚”。大多数时候问题不在模型而在我的需求描述本身就有模糊地带。把这个问题想清楚提示词自然就改好了。最后分享一个我最近在用的技巧让模型帮你写提示词。当你不知道该怎么描述一个任务时直接问模型“我想让AI帮我完成[任务]请帮我写一段提示词要求包含角色、背景、具体指令和输出格式。”模型给出的提示词往往结构完整你只需要微调具体内容。这个方法特别适合新手相当于让模型教你跟模型沟通。提示词能力不是孤立的它和你的表达能力、逻辑能力、领域知识都相关。你对自己要做的事理解得越深提示词就写得越好。反过来写提示词的过程也在逼你把事情想清楚。这大概是我做这件事最大的收获。