同一个模型，有人用它省下两小时，有人觉得它一无是处。差别大多不在模型，在提示词。
这一课讲写提示词的基本功：一条提示词该包含什么、什么时候给示例、角色设定到底有没有用、怎么用结构和格式限制输出。
一、提示词是给模型的一份简报
模型像一个能力很强、但对你一无所知的智者。
它读过大半个互联网，会写代码、会分析，可它不知道你的项目、你心里的「好」是什么样。
你只说一句「帮我写点东西」，它只能给出最安全、最平均的答案。
你把读者是谁、要包含什么、要避开什么、过去满意的样子交代清楚，质量马上不一样。
使用模型的那一刻，提示词是你唯一能调的东西。你改不了它的权重，也没法临时重新训练它。
所以写提示词不是找「魔法咒语」，而是两件很普通的事：
- 说清楚：把你要什么、给谁看、做到什么程度算完成，用模型好理解的方式写出来
- 反复改：把提示词当草稿，跑真实输入，看哪里错，改掉再跑
模型越来越聪明，也没让这门手艺过时。把需求写清楚，永远都很重要。
二、好的提示词的五个要素
不是每条提示词都需要五样全有。问个简单事实，一句话就够。但任务稍微复杂，按这五项过一遍，能挡掉大部分问题。
| 要素 | 要回答的问题 | 写法示例 |
|---|---|---|
| 任务 | 要它做什么 | 用明确动词：修复、总结、分类、提取、改写 |
| 上下文 | 给谁、在什么背景下 | 「这是给后端新人看的」「项目用的是 Spring Boot 3」 |
| 格式 | 输出长什么样 | 「只返回修改后的函数」「三条要点，每条一句」 |
| 示例 | 好结果长什么样 | 贴一段你满意的代码风格或回复 |
| 约束 | 边界在哪 | 「不要改其他文件」「不新增依赖」 |
拿写代码的场景举个例子。
改之前：
修一下这段代码。改之后：
这个 TypeScript 函数应该返回数组的中位数，但传入空数组时会抛出
TypeError。只修这个 bug，不要重构其他逻辑。空数组时返回 null。
只返回修改后的函数，不需要解释。后一条每个字都在消除歧义：哪里坏了、改到什么程度、边界情况怎么处理、输出要什么。
三、角色提示：有用，但别指望它变聪明
「你是一名资深后端工程师」这类开头，几乎人人都写过。它到底有没有用？
答案是：对风格有用，对准确性帮助不大，有时还有害。