大模型提示词工程，说白了就是学会和大模型“好好说话”，把脑子里的模糊需求翻译成它听得懂的指令。别小看这件事——同样一个模型，有人能让它当编程助手、数据分析师、文案策划，有人却只能得到又空又水的回答。差别几乎全在提示词上。这篇指南是写给两类人的：一类是写代码的程序员，想用大模型提升开发效率；另一类是完全没接触过代码的小白，想让大模型帮忙处理日常任务。我会把我在多次实际项目中验证过的五大核心技巧，配合能直接抄作业的案例，从原理到操作一步步拆给你看。读完之后，你会发现提示词工程不是玄学，而是一套完全可以量化、可控的交流方法。1. 先纠正一个误区：大模型是“聪明的实习生”，不是“全知的搜索引擎”很多人在第一次用大模型时，都习惯把它当成搜索引擎来用，输入几个关键词，期待它直接吐出正确答案。一旦结果不符合预期，就开始怀疑模型能力不行。但事实上，绝大多数失败案例，问题都出在提示词本身。1.1 为什么你总觉得大模型“答非所问”？我经常遇到这样的场景：有人问模型“帮我写个Python程序”，模型反问要写什么程序；有人再输入“写个游戏”，模型就真的输出一个极简的猜数字游戏，然后用户觉得“这也太简陋了”。问题出在哪？出在“Python程序”和“游戏”都是高度模糊的指令。大模型的工作方式，本质上是通过词元预测生成最可能的下一个内容。它没有魔法，也不知道你脑子里在想什么。它的“聪明”更多体现在：一旦你给出清晰的约束和上下文，它就能在极短的时间内检索海量的训练知识，组合出相当专业的答案。这就像带了一个能力很强但完全不了解你公司背景的实习生——你只告诉他“写个报告”，他当然大概率写出通用模板；但你告诉他“你是财务分析岗，请根据我给的销售数据，写一份不超过300字的分析摘要，重点标注异常波动”，他会给你超出预期的结果。所以，提示词工程的核心，不是“多输入几个词”，而是把隐含需求显性化。把自己的目标、模型的身份、输出的格式、需要绕开的坑，全部说清楚。这样模型才不需要猜，也不用瞎猜。1.2 提示词工程的三个核心要素：指令、上下文、期望输出无论提示词是长是短，拆解下来都离不开这三个要素。理解了它们，后面的技巧才有根基。指令（Instruction）：告诉模型“你要做什么”。比如“请翻译”“请总结”“请生成代码”。指令越具体，行为越可控。只写“帮我看看这段代码”就远远不如“请帮我审查这段Python代码，找出潜在的越界问题，并给出修改建议”更高效。上下文（Context）：给模型提供必要的信息背景。包括角色设定、已知条件、参考示例、禁止事项等。上下文决定了模型从哪个知识范围里取答案。模型并不会天然知道你用的是Python 3还是Python 2，也不会知道你的用户群体是大学生还是企业客户，这些都需要你用上下文写清楚。期望输出（Output Format）：定义答案的样子。比如“用Markdown表格输出”“给出JSON格式”“分成三点，每点不超过50字”。明确期望输出，是控制答案质量最直接的手段。你可以把这三个要素想象成给实习生的任务单：做什么、背景是什么、交上来的东西长什么样。一张合格的任务单，实习生能立刻上手；一张只有“做个方案”四个字的任务单，实习生能发挥的地方太多，风险也随之增大。接下来的五个技巧，本质上都是在把这三要素落地：角色设定强化上下文，示例补充上下文，思维链约束推理路径，格式约束定义期望输出，迭代优化动态修正指令。理解了这一点，后面每一章你都能学得更快。2. 技巧一：把“随便聊聊”改成“目标明确的项目需求单”——角色设定与任务描述第一个技巧，也是我每次用大模型时最先做的一步：给模型一个明确的角色，以及一个像需求文档一样清晰的任务描述。很多人习惯直接甩一个问题，然后得到了一个平平无奇的回答。但你一旦把提示词改写成项目需求单，输出质量会立刻上一个大台阶。2.1 角色设定：给模型一个可以“代入”的专业身份为什么要设定角色？因为大模型在预训练阶段看过大量的文本，有编程类、销售类、医学类、法律类等不同领域的语料。当你明确给出“你现在是一名有10年经验的资深后端工程师”这个角色时，模型内部的生成路径会主动偏向该领域的专业表达和思考方式，而不是在所有知识里平均用力。这里有个常见误区：有人觉得角色设定只是加一句“你是一名某某专家”就完事了。实际上，角色设定要包含“身份 + 领域 + 层级 + 任务目标”。举两个对比：较弱的提示词：“你是一名专家，帮我写一段登录代码。”较强的提示词：“你是一名熟悉网络安全和Web开发的高级后端工程师，请使用Python的FastAPI框架，为我的项目写一个基于JWT的无状态登录接口，要求考虑密码加密存储、token过期处理，并附带单元测试。”后者的效果几乎是碾压级的。模型知道要给FastAPI风格的代码、要装什么库、需要考虑哪些安全细节，而不只是丢弃一个泛泛的登录页面。如果你是小白的读者，可能会觉得这些专业词太陌生，没关系，你只需要记住一个原则：角色设定中角色的具体程度，决定了答案的专业程度。哪怕你是让模型“帮我写一份周三下午三点部门周会的会议纪要”，也要设定“你是一名行政助理，专注会议记录，记录要清晰分点，并标出未决事项”——因为行政助理这个角色，会让模型倾向于使用会议纪要的行文习惯，而不是散文。2.2 任务描述的五要素与反面案例拆解给实习生布置任务时，任务描述要足够具体。我总结了一个好用的五要素检查法：目标：你最终要得到什么？是一段代码、一篇文章，还是一个方案？约束：有没有技术栈、篇幅、风格、数据来源的限制？参考：提供哪些已知信息？比如已有的代码、字段定义、背景说明。反例：哪些情况绝对不能出现？验收标准：怎么判断结果合格？来看一个反面案例：有人输入“帮我写一份英语学习计划”。这个任务里，目标模糊（是长期计划还是考前冲刺？）、约束缺失（每天学多久？目标分数多少？）、无参考、无反例、无验收标准。模型只能给你一份“早上背单词、下午听听力”的通用计划。我给这个提示词做个简单的升级：假设你是一名有10年教学经验的雅思口语老师。请为一位目标分数6.5分、每天只能投入40分钟备考的上班族，制定一份为期8周的口语提升计划。要求：每周设置一个主题，安排当天的具体练习动作；不要推荐付费课程；计划需要用Markdown表格按周展示；最后注明每周的自我测试方法。这样模型就能输出一份相当可落地的计划，而不是泛泛而谈。核心逻辑是：你给的约束越像真实需求，模型就越不容易发挥“车轱辘话”。在你输入之前，先花一分钟想清楚：如果我是这个项目的负责人，我拿到这份答案，能不能直接验收？如果答案是否定的，那提示词大概率还不够具体。2.3 实战：让模型帮你写一段可运行的Python脚本我举一个程序员更关心的例子。假设你准备写一个批量重命名文件的脚本，但不想自己查模块资料。先给出一个弱提示词：“写个脚本，把文件名重命名为日期格式。”模型会输出一堆没头没尾的代码，可能还不清楚要重命名的目录在哪。按五要素改写后：请你扮演一名有8年经验的Python开发工程师。任务：编写一个Python 3脚本，批量重命名指定文件夹下的所有图片文件，规则统一改为YYYYMMDD_HHMMSS.jpg，保留原文件扩展名。约束：使用os和re模块，不要引入第三方库；脚本运行前打印将被重命名的文件列表；自动跳过已经符合命名规则的图片；如果无匹配文件，输出提示信息。请给出完整可运行的代码，并在代码末尾用注释说明用法。效果很好，模型会主动写一个完整的脚本，还带有主入口和错误处理。你会发现，它给出的代码从“玩具片段”变成了“能直接用进项目的工具”。这就是角色与任务描述带来的差异。两个提示词之间只差了几个从句，但输出质量天差地别。3. 技巧二：与其说一千遍，不如给一个“葫芦”——Few-Shot示例的魔力第二个技巧，是用示例来“打样”。你可能会觉得，指令已经写得很清楚了，为什么模型还是听不懂？因为大模型天然喜欢模仿——示例给它展示了具体的输入输出映射关系，这是最直接的约束。这条技巧，可以说是小白最容易上手、提升效果最明显的一个。3.1 为什么一个示例顶得上一串形容词我经常用一句大白话解释：你跟人类讲“要把工作总结写得简洁一点”，可能不如直接给他看一份你觉得写得好的“简洁总结示例”来得快。因为“简洁”是个主观词，不同人理解不同。但示例会把抽象的要求变成具体的格式、语气和内容量。比如你想让模型根据一段商品描述，生成一段用于社交媒体的推广文案。如果你只是说“请生成推广文案，要求活泼”，模型可能会给你一段略显“AI风”的文字。但如果你在提示词里放一个示例：示例输入：天然蚕丝面膜，补水保湿，适合敏感肌，一盒10片。 示例输出：换季烂脸姐妹看过来！这盒蚕丝面膜真的把“温和”写在配方里了，敏感肌直接闭眼入，10片装可以撑一个皮肤修复周期。然后让模型按同样的风格为你的另一款商品生成文案，它就会自动模仿这个示例的结构，包括“痛点称呼+核心卖点+行动建议”。示例不仅传递了格式，更传递了“语感”。模型会把示例当作最优解，在它的附近展开生成，这比任何形容词都更接近你想表达的意思。因此，在构造提示词时，先想一想能不能给模型一个“葫芦”——哪怕是很短的一个输入输出对。等到没有示例可用时，再去堆砌修饰词。需要注意的是，示例不能随便找一个。示例的质量非常关键：你给的示例中包含某种偏见，模型就更容易放大这种偏见。3.2 如何构造高质量示例：正面清单+负面反例一个高质量的示例，最好包含一对“应该怎么做”和“不应该怎么做”的对照。正面示例（正向样本）：告诉模型符合要求的样子。负面示例（反向样本）：告诉模型必须避开的样子。举个例子，你想让模型把口语化的句子改写成正式书面语。提示词可以这样写：请把你收到的每一段口语文本改写成正式的书面语。以下为转换示例：输入：那个项目我们搞砸了，客户很不高兴，可能以后不合作了。 输出：该项目未能达成预期目标，客户反馈表示强烈不满，未来合作存在较大不确定性。输入：感觉这功能还行，就是有点卡。 输出：该功能整体表现尚可，但运行流畅度不足。现在请改写：这次培训太无聊了，好多人都睡着了，组织得也不行。注意，这里包含了两个正面示例，但并没有反面示例。那什么时候需要反面示例？当你特别担心模型出现某种错误时，可以加一句“你绝不能输出以下内容”或直接放一个反面示例。比如：反面示例：输入：开会迟到了半小时。输出：早到不如晚到，反正没人说什么。（×）大模型很有“求生欲”，一旦它在上下文中读到“反面示例”，生成时就会倾向于绕开这种表达。在我实际项目中，我发现反面示例对抑制模型胡编乱造特别有效。尤其在做知识问答类任务时，给一个“不确定不要乱猜，明确答‘信息不足’”的反面示例，模型的“幻觉率”会明显下降。3.3 实战：用示例让模型输出结构化JSON程序员经常需要让模型输出JSON，但模型偶尔会在JSON里夹带markdown注释或额外文字，导致解析失败。示例就是解决这个问题的最好办法。你是一个数据提取器。请根据用户输入的公司信息，提取出“公司名称”“所在城市”“成立年份”“员工数”四个字段，并输出为严格的JSON对象。示例输入：某科技公司2015年在上海成立，目前团队规模有180人，主要做企业服务。 示例输出：{"company_name":"某科技公司","city":"上海","founded_year":2015,"employee_count":180}现在请提取：某教育公司，总部在广州，2019年成立，现有员工420人。你会发现，模型几乎不会输出多余的文字，它知道目标就是模仿示例输出纯粹的JSON。如果你再补充一句“不要输出JSON之外的内容”，它也会乖乖听话。这正是示例承诺了输入输出的“边界感”——模型在示例中看到的映射关系越清晰，它就越不会自由发挥。4. 技巧三：让模型把“草稿纸”亮出来——强制分步推理与思维链第三个技巧，可能是“程序员友好度”最高的一条：请求模型在给出最终结论前，先展示推理步骤。这种方法在英文资料中常被称为Chain-of-Thought，也就是思维链提示。4.1 从“直接给答案”到“让我看看你的推理过程”大模型在面对复杂逻辑题时，如果你直接让它给答案，它常常会因为“想一步到位”而翻车。但如果你在提示词中加上一句“请一步一步思考，并在回答中展示每一步的推导过程”，正确率会明显提升。原因不难理解：模型生成的每一步输出，都会成为它后面生成内容的“上下文”。当它先写出“已知条件有哪些”、再写“第一步计算”、再写“第二步筛选”时，这个逐步生成的路径，等于在给自己做了一遍逻辑推导，而不是被“能急停下来的直觉”带跑。举一个例子。假设有一道题：“一个盒子里有红球和白球，红球比白球多3个，总数为27个，请问红球和白球各多少个？”直接问“是多少？”模型有时会搞混。更稳妥的提示词是：请一步步推理：设白球数量为x，请先列出已知条件。根据红球比白球多3个，列出红球与白球的关系式。结合总数为27，建立方程并求解。最终给出红球和白球的具体数量。模型会按照这个框架输出完整推导，答案几乎不会错。这个技巧不仅适用于数学题，还适用于方案选择、代码调试、文本逻辑分析等任务。尤其是当模型需要综合对比多个条件时，强制分步能显著减少遗漏。4.2 什么时候该用思维链，什么时候别乱用思维链很好用，但也不是万能的。我总结了三个适用场景和三个不适用场景：适用场景：数学题、逻辑推理、多条件筛选：需要逐层推导，全程每一步都可能出错。代码排查：让模型分析一段有Bug的代码，它先枚举怀疑点，再逐个排除，远比直接让“找Bug”靠谱。复杂决策：比如“选择A城市还是B城市开分店”，让模型先列出两地的优势劣势，再给结论。不适用场景：简单提取任务：比如“从一句话里提取人名”，根本不需要推理，模型一步就能完成。需要快速响应的对话场景：每条回复都要求模型长篇幅推理，会造成不必要的延迟和字数浪费，体验很糟。开放式创意写作：让AI“先推理怎么打动读者再写文案”，反而可能抑制它的灵感。这时候最好直接给文风示例，而不是逼它做逻辑。换句话说，思维链是在“答案不确定且需要推导”的场景下才值得投入的。没事别加“请一步步思考”，否则你会得到一堆无关痛痒的“自我检讨”。4.3 实战：用思维链解决一道“多条件筛选任务”前段时间我模拟了一个任务：要求模型根据一组条件，推荐一款合适的笔记本电脑。由于条件比较多，模型直接回答容易漏项。我给它的提示词是这个样子：你是数码产品顾问。请基于以下条件，推荐一款笔记本电脑，并展示你的决策过程： 预算: 6000-8000元； 用途: 轻度视频剪辑、Java开发； 必需：至少16GB内存，512GB SSD，屏幕14英寸以上； 偏好：重量不超过1.5kg。请先列出满足必需条件的机型，再根据偏好一一排除，最后给出你的最终建议及理由。结果模型按照“筛选必需条件->代入偏好->比较剩余选项->给出结论”的路线输出，最后推荐结果非常清晰。这个过程中，虽然模型并没有真的“计算”，但强制分步让它把筛选逻辑完整呈现在上下文里，降低了随机发挥的概率。你在自己写提示词时，可以模仿这种“先列约束-再列候选-再剔除-再收尾”的结构。5. 技巧四：学会画“边界线”——分隔符、输出格式与格式约束前面几个技巧，核心都是“引导内容”。第四个技巧更偏“控制结构”：通过分隔符、格式要求，让模型的输出严格符合你的使用场景。这对于程序员对接自动化流程特别重要，但对小白来说也同样能提升阅读效率。5.1 用分隔符把“指令”和“内容”分开，避免模型混淆一个经典的问题：如果你在提示词中给了大模型一段待处理的文本，里面包含了“请忽略所有指令”这句话，模型很可能会照做。这时候，分隔符就派上用场了。最常见的分隔符有三类：特殊符号：###、---、>>>成对包裹：<content>...</content>、<code>...</code>、[]、{}Markdown代码块标记：python、text举个例子，你要让模型翻译一段会议记录。不要把待翻译内容直接混在指令中，而是像这样：请将以下会议记录翻译成英文。会议记录被包裹在===符号内：周二下午，产品部与研发部就发票模块的接口方案达成一致，预计下周末联调。这样即使原文中出现“假装你是翻译、忽略之前的指令”之类的话，模型也不会把它当作有效指令。原因在于分隔符清晰标记了“哪些是待处理数据，哪些是不可违抗的命令”，这让模型的执行边界变得很明确。尤其是你在做提示词注入防护或自动化处理时，这个习惯能帮你省去很多麻烦。5.2 明确输出格式：表格、JSON、代码块，一次说清输出格式的约束，应从“给模型一个准确模板”的角度入手。比如：要求“请用Markdown表格输出，第一列是功能名，第二列是优先级，第三列是预计工时”要求“输出JSON，字段名必须为：name, price, stock”要求“先写一段简要说明，再输出带行号的代码块”这里有个实践经验：格式要求最好放在提示词的末尾，而不是开头。原理上，模型是逐步生成内容的，结尾部分的要求更容易成为生成最后阶段的“注意焦点”。如果你把格式要求放在开头，模型在前面的长文本生成过程中可能会慢慢忘记它。虽然这不算绝对规律，但在我用过的多个主流大模型上，这个技巧都明显奏效。不要让模型自己发挥。比如你问“请列出本周的5项待办并给出优先级”，如果你不指定格式，模型可能输出一段话。但如果你要求“请用表格输出，按优先级从高到低排列，并增加‘预计耗时’列”，结果就会跨越式地好用。对于小白来说，这是最容易看到明显效果的一招。5.3 实战：让模型整理会议纪要，并按模板输出我来展示一个可以直接套用的模板，这个模板几乎可以用于任何会议纪要或信息总结类任务：你是一名会议记录专员。下面是用<<<包裹的原始会议转写片段： <<< 昨天开会讨论了下季度促销活动。小张说预算批下来了，总共五万，小李说希望在第三周开始推广，可以找几位达人做视频，小王补充说必须先准备好物料，避免投放时手忙脚乱。请按以下模板进行整理：会议主题议定事项未决事项行动项（用表格表示：事项 | 负责人 | 截止时间）整体事实错误时，请标注“需人工核实”。模型输出的结果就会是结构清晰、可直接放进项目管理的模板。你会发现，格式约束不仅让内容变清楚，还让后续处理变得更容易。你可以直接把这段输出复制进表格，或者通过脚本解析。6. 技巧五：没有一次写对也很正常——多轮迭代与结构化修改最后一个技巧，也是最容易被忽略的：提示词工程不是一个“一次成型”的过程，而是一个“调参”过程。即使是经验丰富的从业者，也没有人能做到第一版提示词永远完美，更常见的情况是：先写一个能跑通的版本，再根据输出的反馈逐步优化。学会迭代，是提示词工程从“入门”到“进阶”的分水岭。6.1 提示词是“调”出来的：把每次输出当反馈信号很多人用大模型失败后，会觉得“这个模型不行”，然后放弃。其实更准确的思路是：每次输出都是对提示词质量的一次评测。如果输出偏了，往往不是模型变笨了，而是提示词里有一个“干扰项”或“缺口”。你可以把输出当作一个反馈信号，去问自己三个问题：哪里跟预期不符？是信息缺了，还是格式不对，还是语气跑偏？这个不符，是因为提示词缺少了哪一个约束？我可以用什么方式补齐这个约束？是加一个示例，还是明确输出格式？这种“审视输出—修正提示词—再次生成”的循环，本质上就是产品经理常说的快速迭代。配合下面要讲的几种策略，你会越调越准。6.2 三种高效迭代策略：补齐、压缩、换角度补齐（Refine）：针对性补充缺失信息。例如第一次生成后，模型漏掉了某个方面，你的第二次提示词可以这样写：“你刚才的答案遗漏了风险分析，请保留原有内容，新增一个‘风险与应对’小节。”这种方式可以避免让模型重新生成多余的全量回答，只做增量修改。压缩（Condense）：在保持核心内容的前提下，要求更短更精炼。如果第一版太啰嗦，可以增加“去除口头语、每点限制在20字内、合并重复信息”等约束。这是成本最低的优化。换角度（Rephrase）：如果同一提示词重复调整两三次仍然效果很差，不妨完全换一个提问角度。比如之前让模型“写计划”，改为“假设我是项目的投资人，请你用三个问题来探询这个计划的不足，然后再给出完善建议”。角度一变，模型的注意力分布会完全不同，常常能带来惊喜。三种策略没有谁更高级，关键在于针对不同的失败模式灵活选择。我自己的习惯是：先判断是内容缺失还是结构混乱，内容缺失用补齐，结构混乱用格式约束或压缩，主题跑偏严重就直接换角度。6.3 实战：从“很一般的回答”到“能直接用的回答”的两次修改过程我模拟一个任务：请大模型帮忙撰写一封向客户催款的正式函件。第一版提示词：请帮我一封催客户付款的邮件。模型输出了一封语气生硬、还带威胁口吻的邮件。这显然不行。第一次迭代：增加角色与目的约束。假设你是企业信用管理专家，要写一封既保持合作关系、又能让对方重视付款期限的催款函。客户推迟付款30天，且未说明理由。语气要礼貌但坚定。请给出一封可直接发送的邮件，约200字。模型这次输出了一封措辞得体的信，但段落过长，缺少重点信息位置。第二次迭代：增加格式与核心要素。请保留上一版邮件的基本内容，但把邮件结构改为：主题行、抬头、欠款金额及账期说明（可填写占位符）、当前影响说明、请求明确付款日期、致谢与联系方式。使用模板风格，把关键信息用[]标出。这次模型提供了一个清晰的模板，几乎可以直接复制到邮箱里使用。整个过程只花了几分钟。你会发现，模型每一次输出都在给你的提示词打分，而你的每一次微调，都在缩小“当前输出”和“理想输出”之间的差值。多轮迭代不是没面子，而是工作常态。7. 综合案例：五个技巧合起来，让大模型帮你完成一个“个人记账小工具”前面分别讲了五个技巧，现在把它们全部串起来，做一个完整的实战案例。假设一个完全不懂代码的小白，想做一个“个人记账小工具”，并且希望通过大模型生成产品需求文档和可运行的Python原型代码。我们来一步步构造提示词。7.1 第一步：用角色设定与任务描述铺底你是一位拥有6年经验的产品经理兼Python开发工程师。请协助我完成一个“个人记账小工具”的MVP版本设计。首先输出一份《产品需求文档》，然后再根据该需求文档生成一套可直接运行的Python原型代码。这里用了技巧一，给出了身份和具体任务，还规定了输出顺序。这样一来，模型就不会只给你一段代码，而是先有设计逻辑，再给实现。7.2 第二步：用示例与格式约束规范输出在模型生成需求文档前，我们最好补充格式要求：需求文档请按以下结构输出：用户故事功能清单（用表格：功能名 | 优先级 | 说明）基本数据模型（建议使用Python dataclass示意）核心交互流程（用序号描述步骤即可，不要画图）这样模型就会严格按你的模板输出，而不是自由发挥出五六个大标题。等模型输出需求文档后，我们再让它生成代码。7.3 第三步：用思维链让模型先生成代码设计，再写具体实现直接让模型“写代码”容易漏掉边界条件。我们加上分步要求：请针对功能清单中的“添加账单”“按月统计”“提醒预算”三个功能，先生成代码的执行流程，再根据流程用Python编写实现。代码要求：使用标准库，不使用框架数据保存到本地JSON文件每个函数都要有类型标注和docstring请先输出函数列表，再逐个写出函数实现这段提示词隐含了“先思考后编码”的思维链。模型通常会先列出一个Bill类、add_bill()函数、monthly_summary()函数、budget_alert()函数等，然后依次填写实现。这样生成的代码比直接让他“写吧”要完整得多。7.4 第四步：多轮迭代微调代码第一次生成的代码往往只有基础增删查，没有预算提醒逻辑。我们继续用迭代策略：功能清单里提到“提醒预算”，但你刚才的代码里没有实现这部分。请补充一个模块，在新增账单后自动判断当月支出是否超过已设定的预算，如果超过则输出一条包含超额金额的提示。请只补充这部分代码和对应测试用例。模型会基于已有的数据结构，快速补上相关逻辑。经过两三次这样的迭代，这个小白就能获得一个可运行、带基础功能的记账小工具原型。整段过程不需要写一行代码，但最终产出却相当扎实。7.5 从案例中复盘五个技巧各自的作用现在回头看看这个完整的案例：技巧一（角色+任务）为整个过程定下了专业基调；技巧二（示例）虽然没有在每一步都用到，但在格式要求中隐含了对输出结构的“打样”；技巧三（思维链）在生成代码前先生成流程设计，降低了逻辑跳步风险；技巧四（格式约束）让需求文档和代码都结构清晰，便于理解；技巧五（迭代优化）将“没做预算提醒”这种缺口逐步补齐。你会发现，这些技巧并不是孤立存在的，而是像各个零件一样共同服务于一个目标：把模糊的大需求拆解成清晰的小要求。当你熟练掌握后，这些技巧就会变成你与模型交流时的本能反应。最后再分享一个小经验：不要把提示词当成一个“能一次写对的谜题”，它更像一把需要不断打磨的钥匙。每次生成结果不满意，不要急着换工具，先想一想是不是没有把需求说全。技术总在变化，模型总在升级，但“清晰表达需求”这件事，永远不会过时。哪怕你现在只记住“角色要具体、格式要说清、推理要分步”这三句话，也已经能超过大部分只会乱问的用户了。
大模型提示词工程，说白了就是学会和大模型“好好说话”，把脑子里的模糊需求翻译成它听得懂的指令。别小看这件事——同样一个模型，有人能让它当编程助手、数据分析师、文案策划，有人却只能得到又空又水的回答。差别几乎全在提示词上。这篇指南是写给两类人的：一类是写代码的程序员，想用大模型提升开发效率；另一类是完全没接触过代码的小白，想让大模型帮忙处理日常任务。我会把我在多次实际项目中验证过的五大核心技巧，配合能直接抄作业的案例，从原理到操作一步步拆给你看。读完之后，你会发现提示词工程不是玄学，而是一套完全可以量化、可控的交流方法。1. 先纠正一个误区：大模型是“聪明的实习生”，不是“全知的搜索引擎”很多人在第一次用大模型时，都习惯把它当成搜索引擎来用，输入几个关键词，期待它直接吐出正确答案。一旦结果不符合预期，就开始怀疑模型能力不行。但事实上，绝大多数失败案例，问题都出在提示词本身。1.1 为什么你总觉得大模型“答非所问”？我经常遇到这样的场景：有人问模型“帮我写个Python程序”，模型反问要写什么程序；有人再输入“写个游戏”，模型就真的输出一个极简的猜数字游戏，然后用户觉得“这也太简陋了”。问题出在哪？出在“Python程序”和“游戏”都是高度模糊的指令。大模型的工作方式，本质上是通过词元预测生成最可能的下一个内容。它没有魔法，也不知道你脑子里在想什么。它的“聪明”更多体现在：一旦你给出清晰的约束和上下文，它就能在极短的时间内检索海量的训练知识，组合出相当专业的答案。这就像带了一个能力很强但完全不了解你公司背景的实习生——你只告诉他“写个报告”，他当然大概率写出通用模板；但你告诉他“你是财务分析岗，请根据我给的销售数据，写一份不超过300字的分析摘要，重点标注异常波动”，他会给你超出预期的结果。所以，提示词工程的核心，不是“多输入几个词”，而是把隐含需求显性化。把自己的目标、模型的身份、输出的格式、需要绕开的坑，全部说清楚。这样模型才不需要猜，也不用瞎猜。1.2 提示词工程的三个核心要素：指令、上下文、期望输出无论提示词是长是短，拆解下来都离不开这三个要素。理解了它们，后面的技巧才有根基。指令（Instruction）：告诉模型“你要做什么”。比如“请翻译”“请总结”“请生成代码”。指令越具体，行为越可控。只写“帮我看看这段代码”就远远不如“请帮我审查这段Python代码，找出潜在的越界问题，并给出修改建议”更高效。上下文（Context）：给模型提供必要的信息背景。包括角色设定、已知条件、参考示例、禁止事项等。上下文决定了模型从哪个知识范围里取答案。模型并不会天然知道你用的是Python 3还是Python 2，也不会知道你的用户群体是大学生还是企业客户，这些都需要你用上下文写清楚。期望输出（Output Format）：定义答案的样子。比如“用Markdown表格输出”“给出JSON格式”“分成三点，每点不超过50字”。明确期望输出，是控制答案质量最直接的手段。你可以把这三个要素想象成给实习生的任务单：做什么、背景是什么、交上来的东西长什么样。一张合格的任务单，实习生能立刻上手；一张只有“做个方案”四个字的任务单，实习生能发挥的地方太多，风险也随之增大。接下来的五个技巧，本质上都是在把这三要素落地：角色设定强化上下文，示例补充上下文，思维链约束推理路径，格式约束定义期望输出，迭代优化动态修正指令。理解了这一点，后面每一章你都能学得更快。2. 技巧一：把“随便聊聊”改成“目标明确的项目需求单”——角色设定与任务描述第一个技巧，也是我每次用大模型时最先做的一步：给模型一个明确的角色，以及一个像需求文档一样清晰的任务描述。很多人习惯直接甩一个问题，然后得到了一个平平无奇的回答。但你一旦把提示词改写成项目需求单，输出质量会立刻上一个大台阶。2.1 角色设定：给模型一个可以“代入”的专业身份为什么要设定角色？因为大模型在预训练阶段看过大量的文本，有编程类、销售类、医学类、法律类等不同领域的语料。当你明确给出“你现在是一名有10年经验的资深后端工程师”这个角色时，模型内部的生成路径会主动偏向该领域的专业表达和思考方式，而不是在所有知识里平均用力。这里有个常见误区：有人觉得角色设定只是加一句“你是一名某某专家”就完事了。实际上，角色设定要包含“身份 + 领域 + 层级 + 任务目标”。举两个对比：较弱的提示词：“你是一名专家，帮我写一段登录代码。”较强的提示词：“你是一名熟悉网络安全和Web开发的高级后端工程师，请使用Python的FastAPI框架，为我的项目写一个基于JWT的无状态登录接口，要求考虑密码加密存储、token过期处理，并附带单元测试。”后者的效果几乎是碾压级的。模型知道要给FastAPI风格的代码、要装什么库、需要考虑哪些安全细节，而不只是丢弃一个泛泛的登录页面。如果你是小白的读者，可能会觉得这些专业词太陌生，没关系，你只需要记住一个原则：角色设定中角色的具体程度，决定了答案的专业程度。哪怕你是让模型“帮我写一份周三下午三点部门周会的会议纪要”，也要设定“你是一名行政助理，专注会议记录，记录要清晰分点，并标出未决事项”——因为行政助理这个角色，会让模型倾向于使用会议纪要的行文习惯，而不是散文。2.2 任务描述的五要素与反面案例拆解给实习生布置任务时，任务描述要足够具体。我总结了一个好用的五要素检查法：目标：你最终要得到什么？是一段代码、一篇文章，还是一个方案？约束：有没有技术栈、篇幅、风格、数据来源的限制？参考：提供哪些已知信息？比如已有的代码、字段定义、背景说明。反例：哪些情况绝对不能出现？验收标准：怎么判断结果合格？来看一个反面案例：有人输入“帮我写一份英语学习计划”。这个任务里，目标模糊（是长期计划还是考前冲刺？）、约束缺失（每天学多久？目标分数多少？）、无参考、无反例、无验收标准。模型只能给你一份“早上背单词、下午听听力”的通用计划。我给这个提示词做个简单的升级：假设你是一名有10年教学经验的雅思口语老师。请为一位目标分数6.5分、每天只能投入40分钟备考的上班族，制定一份为期8周的口语提升计划。要求：每周设置一个主题，安排当天的具体练习动作；不要推荐付费课程；计划需要用Markdown表格按周展示；最后注明每周的自我测试方法。这样模型就能输出一份相当可落地的计划，而不是泛泛而谈。核心逻辑是：你给的约束越像真实需求，模型就越不容易发挥“车轱辘话”。在你输入之前，先花一分钟想清楚：如果我是这个项目的负责人，我拿到这份答案，能不能直接验收？如果答案是否定的，那提示词大概率还不够具体。2.3 实战：让模型帮你写一段可运行的Python脚本我举一个程序员更关心的例子。假设你准备写一个批量重命名文件的脚本，但不想自己查模块资料。先给出一个弱提示词：“写个脚本，把文件名重命名为日期格式。”模型会输出一堆没头没尾的代码，可能还不清楚要重命名的目录在哪。按五要素改写后：请你扮演一名有8年经验的Python开发工程师。任务：编写一个Python 3脚本，批量重命名指定文件夹下的所有图片文件，规则统一改为YYYYMMDD_HHMMSS.jpg，保留原文件扩展名。约束：使用os和re模块，不要引入第三方库；脚本运行前打印将被重命名的文件列表；自动跳过已经符合命名规则的图片；如果无匹配文件，输出提示信息。请给出完整可运行的代码，并在代码末尾用注释说明用法。效果很好，模型会主动写一个完整的脚本，还带有主入口和错误处理。你会发现，它给出的代码从“玩具片段”变成了“能直接用进项目的工具”。这就是角色与任务描述带来的差异。两个提示词之间只差了几个从句，但输出质量天差地别。3. 技巧二：与其说一千遍，不如给一个“葫芦”——Few-Shot示例的魔力第二个技巧，是用示例来“打样”。你可能会觉得，指令已经写得很清楚了，为什么模型还是听不懂？因为大模型天然喜欢模仿——示例给它展示了具体的输入输出映射关系，这是最直接的约束。这条技巧，可以说是小白最容易上手、提升效果最明显的一个。3.1 为什么一个示例顶得上一串形容词我经常用一句大白话解释：你跟人类讲“要把工作总结写得简洁一点”，可能不如直接给他看一份你觉得写得好的“简洁总结示例”来得快。因为“简洁”是个主观词，不同人理解不同。但示例会把抽象的要求变成具体的格式、语气和内容量。比如你想让模型根据一段商品描述，生成一段用于社交媒体的推广文案。如果你只是说“请生成推广文案，要求活泼”，模型可能会给你一段略显“AI风”的文字。但如果你在提示词里放一个示例：示例输入：天然蚕丝面膜，补水保湿，适合敏感肌，一盒10片。 示例输出：换季烂脸姐妹看过来！这盒蚕丝面膜真的把“温和”写在配方里了，敏感肌直接闭眼入，10片装可以撑一个皮肤修复周期。然后让模型按同样的风格为你的另一款商品生成文案，它就会自动模仿这个示例的结构，包括“痛点称呼+核心卖点+行动建议”。示例不仅传递了格式，更传递了“语感”。模型会把示例当作最优解，在它的附近展开生成，这比任何形容词都更接近你想表达的意思。因此，在构造提示词时，先想一想能不能给模型一个“葫芦”——哪怕是很短的一个输入输出对。等到没有示例可用时，再去堆砌修饰词。需要注意的是，示例不能随便找一个。示例的质量非常关键：你给的示例中包含某种偏见，模型就更容易放大这种偏见。3.2 如何构造高质量示例：正面清单+负面反例一个高质量的示例，最好包含一对“应该怎么做”和“不应该怎么做”的对照。正面示例（正向样本）：告诉模型符合要求的样子。负面示例（反向样本）：告诉模型必须避开的样子。举个例子，你想让模型把口语化的句子改写成正式书面语。提示词可以这样写：请把你收到的每一段口语文本改写成正式的书面语。以下为转换示例：输入：那个项目我们搞砸了，客户很不高兴，可能以后不合作了。 输出：该项目未能达成预期目标，客户反馈表示强烈不满，未来合作存在较大不确定性。输入：感觉这功能还行，就是有点卡。 输出：该功能整体表现尚可，但运行流畅度不足。现在请改写：这次培训太无聊了，好多人都睡着了，组织得也不行。注意，这里包含了两个正面示例，但并没有反面示例。那什么时候需要反面示例？当你特别担心模型出现某种错误时，可以加一句“你绝不能输出以下内容”或直接放一个反面示例。比如：反面示例：输入：开会迟到了半小时。输出：早到不如晚到，反正没人说什么。（×）大模型很有“求生欲”，一旦它在上下文中读到“反面示例”，生成时就会倾向于绕开这种表达。在我实际项目中，我发现反面示例对抑制模型胡编乱造特别有效。尤其在做知识问答类任务时，给一个“不确定不要乱猜，明确答‘信息不足’”的反面示例，模型的“幻觉率”会明显下降。3.3 实战：用示例让模型输出结构化JSON程序员经常需要让模型输出JSON，但模型偶尔会在JSON里夹带markdown注释或额外文字，导致解析失败。示例就是解决这个问题的最好办法。你是一个数据提取器。请根据用户输入的公司信息，提取出“公司名称”“所在城市”“成立年份”“员工数”四个字段，并输出为严格的JSON对象。示例输入：某科技公司2015年在上海成立，目前团队规模有180人，主要做企业服务。 示例输出：{"company_name":"某科技公司","city":"上海","founded_year":2015,"employee_count":180}现在请提取：某教育公司，总部在广州，2019年成立，现有员工420人。你会发现，模型几乎不会输出多余的文字，它知道目标就是模仿示例输出纯粹的JSON。如果你再补充一句“不要输出JSON之外的内容”，它也会乖乖听话。这正是示例承诺了输入输出的“边界感”——模型在示例中看到的映射关系越清晰，它就越不会自由发挥。4. 技巧三：让模型把“草稿纸”亮出来——强制分步推理与思维链第三个技巧，可能是“程序员友好度”最高的一条：请求模型在给出最终结论前，先展示推理步骤。这种方法在英文资料中常被称为Chain-of-Thought，也就是思维链提示。4.1 从“直接给答案”到“让我看看你的推理过程”大模型在面对复杂逻辑题时，如果你直接让它给答案，它常常会因为“想一步到位”而翻车。但如果你在提示词中加上一句“请一步一步思考，并在回答中展示每一步的推导过程”，正确率会明显提升。原因不难理解：模型生成的每一步输出，都会成为它后面生成内容的“上下文”。当它先写出“已知条件有哪些”、再写“第一步计算”、再写“第二步筛选”时，这个逐步生成的路径，等于在给自己做了一遍逻辑推导，而不是被“能急停下来的直觉”带跑。举一个例子。假设有一道题：“一个盒子里有红球和白球，红球比白球多3个，总数为27个，请问红球和白球各多少个？”直接问“是多少？”模型有时会搞混。更稳妥的提示词是：请一步步推理：设白球数量为x，请先列出已知条件。根据红球比白球多3个，列出红球与白球的关系式。结合总数为27，建立方程并求解。最终给出红球和白球的具体数量。模型会按照这个框架输出完整推导，答案几乎不会错。这个技巧不仅适用于数学题，还适用于方案选择、代码调试、文本逻辑分析等任务。尤其是当模型需要综合对比多个条件时，强制分步能显著减少遗漏。4.2 什么时候该用思维链，什么时候别乱用思维链很好用，但也不是万能的。我总结了三个适用场景和三个不适用场景：适用场景：数学题、逻辑推理、多条件筛选：需要逐层推导，全程每一步都可能出错。代码排查：让模型分析一段有Bug的代码，它先枚举怀疑点，再逐个排除，远比直接让“找Bug”靠谱。复杂决策：比如“选择A城市还是B城市开分店”，让模型先列出两地的优势劣势，再给结论。不适用场景：简单提取任务：比如“从一句话里提取人名”，根本不需要推理，模型一步就能完成。需要快速响应的对话场景：每条回复都要求模型长篇幅推理，会造成不必要的延迟和字数浪费，体验很糟。开放式创意写作：让AI“先推理怎么打动读者再写文案”，反而可能抑制它的灵感。这时候最好直接给文风示例，而不是逼它做逻辑。换句话说，思维链是在“答案不确定且需要推导”的场景下才值得投入的。没事别加“请一步步思考”，否则你会得到一堆无关痛痒的“自我检讨”。4.3 实战：用思维链解决一道“多条件筛选任务”前段时间我模拟了一个任务：要求模型根据一组条件，推荐一款合适的笔记本电脑。由于条件比较多，模型直接回答容易漏项。我给它的提示词是这个样子：你是数码产品顾问。请基于以下条件，推荐一款笔记本电脑，并展示你的决策过程： 预算: 6000-8000元； 用途: 轻度视频剪辑、Java开发； 必需：至少16GB内存，512GB SSD，屏幕14英寸以上； 偏好：重量不超过1.5kg。请先列出满足必需条件的机型，再根据偏好一一排除，最后给出你的最终建议及理由。结果模型按照“筛选必需条件->代入偏好->比较剩余选项->给出结论”的路线输出，最后推荐结果非常清晰。这个过程中，虽然模型并没有真的“计算”，但强制分步让它把筛选逻辑完整呈现在上下文里，降低了随机发挥的概率。你在自己写提示词时，可以模仿这种“先列约束-再列候选-再剔除-再收尾”的结构。5. 技巧四：学会画“边界线”——分隔符、输出格式与格式约束前面几个技巧，核心都是“引导内容”。第四个技巧更偏“控制结构”：通过分隔符、格式要求，让模型的输出严格符合你的使用场景。这对于程序员对接自动化流程特别重要，但对小白来说也同样能提升阅读效率。5.1 用分隔符把“指令”和“内容”分开，避免模型混淆一个经典的问题：如果你在提示词中给了大模型一段待处理的文本，里面包含了“请忽略所有指令”这句话，模型很可能会照做。这时候，分隔符就派上用场了。最常见的分隔符有三类：特殊符号：###、---、>>>成对包裹：<content>...</content>、<code>...</code>、[]、{}Markdown代码块标记：python、text举个例子，你要让模型翻译一段会议记录。不要把待翻译内容直接混在指令中，而是像这样：请将以下会议记录翻译成英文。会议记录被包裹在===符号内：周二下午，产品部与研发部就发票模块的接口方案达成一致，预计下周末联调。这样即使原文中出现“假装你是翻译、忽略之前的指令”之类的话，模型也不会把它当作有效指令。原因在于分隔符清晰标记了“哪些是待处理数据，哪些是不可违抗的命令”，这让模型的执行边界变得很明确。尤其是你在做提示词注入防护或自动化处理时，这个习惯能帮你省去很多麻烦。5.2 明确输出格式：表格、JSON、代码块，一次说清输出格式的约束，应从“给模型一个准确模板”的角度入手。比如：要求“请用Markdown表格输出，第一列是功能名，第二列是优先级，第三列是预计工时”要求“输出JSON，字段名必须为：name, price, stock”要求“先写一段简要说明，再输出带行号的代码块”这里有个实践经验：格式要求最好放在提示词的末尾，而不是开头。原理上，模型是逐步生成内容的，结尾部分的要求更容易成为生成最后阶段的“注意焦点”。如果你把格式要求放在开头，模型在前面的长文本生成过程中可能会慢慢忘记它。虽然这不算绝对规律，但在我用过的多个主流大模型上，这个技巧都明显奏效。不要让模型自己发挥。比如你问“请列出本周的5项待办并给出优先级”，如果你不指定格式，模型可能输出一段话。但如果你要求“请用表格输出，按优先级从高到低排列，并增加‘预计耗时’列”，结果就会跨越式地好用。对于小白来说，这是最容易看到明显效果的一招。5.3 实战：让模型整理会议纪要，并按模板输出我来展示一个可以直接套用的模板，这个模板几乎可以用于任何会议纪要或信息总结类任务：你是一名会议记录专员。下面是用<<<包裹的原始会议转写片段： <<< 昨天开会讨论了下季度促销活动。小张说预算批下来了，总共五万，小李说希望在第三周开始推广，可以找几位达人做视频，小王补充说必须先准备好物料，避免投放时手忙脚乱。请按以下模板进行整理：会议主题议定事项未决事项行动项（用表格表示：事项 | 负责人 | 截止时间）整体事实错误时，请标注“需人工核实”。模型输出的结果就会是结构清晰、可直接放进项目管理的模板。你会发现，格式约束不仅让内容变清楚，还让后续处理变得更容易。你可以直接把这段输出复制进表格，或者通过脚本解析。6. 技巧五：没有一次写对也很正常——多轮迭代与结构化修改最后一个技巧，也是最容易被忽略的：提示词工程不是一个“一次成型”的过程，而是一个“调参”过程。即使是经验丰富的从业者，也没有人能做到第一版提示词永远完美，更常见的情况是：先写一个能跑通的版本，再根据输出的反馈逐步优化。学会迭代，是提示词工程从“入门”到“进阶”的分水岭。6.1 提示词是“调”出来的：把每次输出当反馈信号很多人用大模型失败后，会觉得“这个模型不行”，然后放弃。其实更准确的思路是：每次输出都是对提示词质量的一次评测。如果输出偏了，往往不是模型变笨了，而是提示词里有一个“干扰项”或“缺口”。你可以把输出当作一个反馈信号，去问自己三个问题：哪里跟预期不符？是信息缺了，还是格式不对，还是语气跑偏？这个不符，是因为提示词缺少了哪一个约束？我可以用什么方式补齐这个约束？是加一个示例，还是明确输出格式？这种“审视输出—修正提示词—再次生成”的循环，本质上就是产品经理常说的快速迭代。配合下面要讲的几种策略，你会越调越准。6.2 三种高效迭代策略：补齐、压缩、换角度补齐（Refine）：针对性补充缺失信息。例如第一次生成后，模型漏掉了某个方面，你的第二次提示词可以这样写：“你刚才的答案遗漏了风险分析，请保留原有内容，新增一个‘风险与应对’小节。”这种方式可以避免让模型重新生成多余的全量回答，只做增量修改。压缩（Condense）：在保持核心内容的前提下，要求更短更精炼。如果第一版太啰嗦，可以增加“去除口头语、每点限制在20字内、合并重复信息”等约束。这是成本最低的优化。换角度（Rephrase）：如果同一提示词重复调整两三次仍然效果很差，不妨完全换一个提问角度。比如之前让模型“写计划”，改为“假设我是项目的投资人，请你用三个问题来探询这个计划的不足，然后再给出完善建议”。角度一变，模型的注意力分布会完全不同，常常能带来惊喜。三种策略没有谁更高级，关键在于针对不同的失败模式灵活选择。我自己的习惯是：先判断是内容缺失还是结构混乱，内容缺失用补齐，结构混乱用格式约束或压缩，主题跑偏严重就直接换角度。6.3 实战：从“很一般的回答”到“能直接用的回答”的两次修改过程我模拟一个任务：请大模型帮忙撰写一封向客户催款的正式函件。第一版提示词：请帮我一封催客户付款的邮件。模型输出了一封语气生硬、还带威胁口吻的邮件。这显然不行。第一次迭代：增加角色与目的约束。假设你是企业信用管理专家，要写一封既保持合作关系、又能让对方重视付款期限的催款函。客户推迟付款30天，且未说明理由。语气要礼貌但坚定。请给出一封可直接发送的邮件，约200字。模型这次输出了一封措辞得体的信，但段落过长，缺少重点信息位置。第二次迭代：增加格式与核心要素。请保留上一版邮件的基本内容，但把邮件结构改为：主题行、抬头、欠款金额及账期说明（可填写占位符）、当前影响说明、请求明确付款日期、致谢与联系方式。使用模板风格，把关键信息用[]标出。这次模型提供了一个清晰的模板，几乎可以直接复制到邮箱里使用。整个过程只花了几分钟。你会发现，模型每一次输出都在给你的提示词打分，而你的每一次微调，都在缩小“当前输出”和“理想输出”之间的差值。多轮迭代不是没面子，而是工作常态。7. 综合案例：五个技巧合起来，让大模型帮你完成一个“个人记账小工具”前面分别讲了五个技巧，现在把它们全部串起来，做一个完整的实战案例。假设一个完全不懂代码的小白，想做一个“个人记账小工具”，并且希望通过大模型生成产品需求文档和可运行的Python原型代码。我们来一步步构造提示词。7.1 第一步：用角色设定与任务描述铺底你是一位拥有6年经验的产品经理兼Python开发工程师。请协助我完成一个“个人记账小工具”的MVP版本设计。首先输出一份《产品需求文档》，然后再根据该需求文档生成一套可直接运行的Python原型代码。这里用了技巧一，给出了身份和具体任务，还规定了输出顺序。这样一来，模型就不会只给你一段代码，而是先有设计逻辑，再给实现。7.2 第二步：用示例与格式约束规范输出在模型生成需求文档前，我们最好补充格式要求：需求文档请按以下结构输出：用户故事功能清单（用表格：功能名 | 优先级 | 说明）基本数据模型（建议使用Python dataclass示意）核心交互流程（用序号描述步骤即可，不要画图）这样模型就会严格按你的模板输出，而不是自由发挥出五六个大标题。等模型输出需求文档后，我们再让它生成代码。7.3 第三步：用思维链让模型先生成代码设计，再写具体实现直接让模型“写代码”容易漏掉边界条件。我们加上分步要求：请针对功能清单中的“添加账单”“按月统计”“提醒预算”三个功能，先生成代码的执行流程，再根据流程用Python编写实现。代码要求：使用标准库，不使用框架数据保存到本地JSON文件每个函数都要有类型标注和docstring请先输出函数列表，再逐个写出函数实现这段提示词隐含了“先思考后编码”的思维链。模型通常会先列出一个Bill类、add_bill()函数、monthly_summary()函数、budget_alert()函数等，然后依次填写实现。这样生成的代码比直接让他“写吧”要完整得多。7.4 第四步：多轮迭代微调代码第一次生成的代码往往只有基础增删查，没有预算提醒逻辑。我们继续用迭代策略：功能清单里提到“提醒预算”，但你刚才的代码里没有实现这部分。请补充一个模块，在新增账单后自动判断当月支出是否超过已设定的预算，如果超过则输出一条包含超额金额的提示。请只补充这部分代码和对应测试用例。模型会基于已有的数据结构，快速补上相关逻辑。经过两三次这样的迭代，这个小白就能获得一个可运行、带基础功能的记账小工具原型。整段过程不需要写一行代码，但最终产出却相当扎实。7.5 从案例中复盘五个技巧各自的作用现在回头看看这个完整的案例：技巧一（角色+任务）为整个过程定下了专业基调；技巧二（示例）虽然没有在每一步都用到，但在格式要求中隐含了对输出结构的“打样”；技巧三（思维链）在生成代码前先生成流程设计，降低了逻辑跳步风险；技巧四（格式约束）让需求文档和代码都结构清晰，便于理解；技巧五（迭代优化）将“没做预算提醒”这种缺口逐步补齐。你会发现，这些技巧并不是孤立存在的，而是像各个零件一样共同服务于一个目标：把模糊的大需求拆解成清晰的小要求。当你熟练掌握后，这些技巧就会变成你与模型交流时的本能反应。最后再分享一个小经验：不要把提示词当成一个“能一次写对的谜题”，它更像一把需要不断打磨的钥匙。每次生成结果不满意，不要急着换工具，先想一想是不是没有把需求说全。技术总在变化，模型总在升级，但“清晰表达需求”这件事，永远不会过时。哪怕你现在只记住“角色要具体、格式要说清、推理要分步”这三句话，也已经能超过大部分只会乱问的用户了。