005、Prompt Engineering基础如何写出高质量的提示词从一次惨痛的API调用说起凌晨两点我盯着终端里那行“400 Bad Request”发呆。客户那边催着要一个基于GPT-4的代码审查工具我写了整整三天的prompt结果模型输出了一堆“根据您的要求我将对代码进行审查”这种废话。更离谱的是有一次它直接开始写诗说我的代码“像春天的柳絮一样飘忽不定”。那一刻我意识到不是模型不行是我根本不会跟它说话。后来我花了两个月把OpenAI的文档翻了个底朝天又拆解了十几个生产级prompt案例才慢慢摸到门道。今天这篇笔记就当是给当年那个凌晨两点的自己写的一封回信。别把大模型当搜索引擎很多人第一次写prompt习惯性用搜索引擎的思维“帮我写一个Python爬虫。” 结果模型给你一个通用模板里面全是your_url_here这种占位符。你气得想骂街但问题出在你自己身上——你给的信息量连一个刚入职的实习生都带不动。搜索引擎是信息检索大模型是信息生成。两者的本质区别在于搜索引擎需要你提供关键词大模型需要你提供上下文、约束和示例。我踩过最深的坑是让模型“分析这段代码的性能问题”。它给我列了十条建议从“使用更快的算法”到“考虑并行计算”每条都对每条都没用。后来我改成这样你是一个有10年经验的C性能优化专家。下面这段代码运行在ARM Cortex-M4上主频168MHzRAM只有64KB。请分析性能瓶颈并给出具体的优化方案要求1不能增加内存占用 2保持代码可读性 3给出修改前后的性能对比估算。结果模型给出的建议直接能用甚至指出了我没想到的指令预取问题。核心心法给模型一个身份、一个场景、一组硬约束。别让它猜你要什么你连它要猜你这件事都不该让它知道。结构化prompt的三种武器武器一角色锚定“你是一个资深嵌入式工程师”和“你是一个刚毕业的嵌入式工程师”同一个问题输出质量天差地别。这不是玄学是模型在训练数据中学到的——不同身份对应不同的语言风格、知识深度和决策逻辑。我习惯在prompt开头用三句话锚定角色你是谁专业背景、经验年限你在做什么具体任务你的输出格式是什么代码、文档、表格、JSON比如你是一个在半导体行业工作12年的芯片验证工程师正在用SystemVerilog写一个AXI4总线协议的验证环境。请帮我生成一个基于UVM的testbench框架输出格式为完整的.sv文件包含必要的注释和TODO标记。武器二示例驱动这是最容易被忽视但效果最显著的方法。模型对“抽象描述”的理解能力远不如对“具体例子”的模仿能力。别这样写请用简洁的语言描述这个函数的功能。这样写请用以下格式描述函数功能 示例 函数void delay_us(uint32_t us) 描述实现微秒级软件延时通过循环计数方式占用CPU适用于短时间等待场景。 现在请描述这个函数 函数int calculate_crc32(uint8_t *data, uint32_t len) 描述模型看到示例后输出的格式、语气、详细程度都会自动对齐。这比你在prompt里写一百遍“要简洁”都管用。武器三思维链引导遇到复杂推理任务直接问“这个算法的复杂度是多少”模型可能直接给出错误答案。但如果你让它“先分析算法步骤再计算每步的时间复杂度最后给出总复杂度”准确率能提升30%以上。这不是我编的是Google那篇《Chain-of-Thought Prompting》论文里的结论。我实际测试下来在嵌入式代码优化这类需要多步推理的任务上效果更明显。一个我常用的模板请按以下步骤分析 1. 先列出该算法的核心操作 2. 分析每步操作的时间复杂度 3. 考虑最坏情况和平均情况 4. 给出最终结论并说明优化空间那些让我翻车的细节温度参数不是摆设很多人调prompt只改文本不改API参数。temperature0.7的模型和temperature0.1的模型输出风格完全不同。写代码、做数学推理我固定用0.1-0.2写文案、做创意生成才敢开到0.7以上。有一次我忘了改参数让模型“生成一个I2C驱动”结果它给我加了三个炫酷的注释表情符号还自作主张改了我的寄存器地址。从那以后我写prompt都会在末尾加一句“temperature0.1确保输出确定性。”负面提示词比正面提示词更管用“不要输出无关内容”这句话模型经常听不懂。但如果你说“只输出代码不要任何解释”它大概率会乖乖照做。我总结了一个负面提示词清单不要使用“根据您的要求”这类开场白不要添加注释说明代码用途不要输出markdown格式除非明确要求不要修改函数签名把这些写进prompt能省掉你80%的后处理时间。长度控制要具体“简短回答”这种模糊描述模型的理解和你完全不一样。你说简短它给你三行你说非常简短它给你一行你说“一句话”它可能给你一个从句套从句的长难句。正确的做法是给具体约束请用不超过50个字描述这个函数的功能。 请输出不超过10行的代码片段。 请用3个要点总结每个要点不超过15个字。一个完整的实战案例这是我给一个智能家居项目写的prompt用来生成MQTT通信协议文档你是一个有8年经验的物联网嵌入式工程师熟悉MQTT v3.1.1协议和ESP32平台。 任务为智能灯控系统设计MQTT主题结构和消息格式。 约束 1. 主题层级不超过3级 2. 消息体使用JSON格式字段名使用驼峰命名 3. 包含设备发现、状态上报、命令下发三个场景 4. 每个场景给出一个完整的消息示例 输出格式 - 主题结构用树形图表示用缩进模拟层级 - 消息格式用JSON示例 - 最后用表格总结所有主题和对应的消息类型 负面约束 - 不要解释MQTT协议基础 - 不要添加“这是一个设计”之类的废话 - 不要使用markdown代码块外的额外说明 请开始。这个prompt跑出来的结果我直接拿去给团队评审只改了两个字段名就定稿了。我的调试方法论写prompt和写代码一样需要迭代调试。我一般走这个流程写第一版把需求、约束、示例都写进去尽量详细跑一次看输出是否符合预期重点关注格式和内容找偏差模型在哪些地方理解错了是信息不足还是约束模糊改prompt针对偏差修改每次只改一个变量重复2-4直到输出稳定符合预期我见过最离谱的同事一个prompt改了30多版就为了调一个输出格式。后来发现是少了一个换行符。所以prompt里的空格、换行、标点符号都和代码一样敏感。最后说点实在的别迷信那些“万能prompt模板”。每个任务、每个模型、每个场景都需要微调。GPT-4和Claude-3对同一个prompt的反应可能完全不同更别说那些开源模型了。我的建议是先花一周时间用同一个任务反复测试不同写法的prompt记录下哪些写法有效、哪些无效。这个过程会让你对prompt engineering的理解超过90%的教程读者。另外别把prompt engineering当成魔法。它本质上是一种沟通技巧——你和一个知识渊博但有点固执的专家沟通需要学会用他能理解的方式表达你的需求。最后留一个思考题如果你要让模型帮你写一个FreeRTOS的任务调度器你会怎么写prompt试试看你会发现自己的prompt水平已经和一周前不一样了。