提示词工程快速入门
理论说够了，这一篇直接动手，从零写出一个可以稳定使用的提示词。
1. 准备工作
任何能调用大模型的工具都行：
- Web 端：Claude.ai、ChatGPT、Gemini
- API：Anthropic、OpenAI、Google
- CLI 工具：Claude Code、Cursor
本篇用 Claude.ai 演示，所有提示词在 GPT、Gemini 上同样适用。
2. 第一个提示词：写商品描述
需求：给一款蓝牙耳机写电商详情页的卖点描述。
第一版：朴素写法
输出（节选）：
这款蓝牙耳机音质卓越，佩戴舒适，续航持久，是您理想的选择……
问题明显：空话连篇、没有信息量、放在任何耳机上都成立。
3. 加上具体信息
输出已经具体多了：
- 比 1 元硬币还轻：单耳 4.2g，戴久不累
- 地铁里的安静岛：-45dB 主动降噪，盖住 90% 通勤噪音
- ……
把"参数"翻译成"用户感知"是这一步的关键。
4. 加约束控制风格
输出还是有点像"模板"。继续加约束：
帮我写一个蓝牙耳机的卖点。
产品参数：
- 蓝牙 5.4
- 单耳重 4.2g
- 主动降噪 -45dB
- 续航 8h，盒充 32h
- IPX5 防水
- 价格 ¥299
目标用户：通勤白领
要求：
- 共 5 条卖点
- 每条 30 字以内
- 用动词开头，避免形容词堆砌
- 避免"卓越"、"极致"、"震撼"这类空词
- 每条要把"参数"换算成"用户能感知的体验"
输出：
- 戴 4.2g 的耳机通勤，几乎感觉不到它的存在
- 开降噪关上地铁噪音，专注听播客或开会
- 一次充电管 8 小时，加充电盒能撑一周
- 下雨跑步、出汗运动都不怕
- 蓝牙 5.4 抗干扰，通勤地铁不卡顿
这就接近能直接上线的文案了。
5. 加示例进一步定调
如果想要某种特定的语气，给一个例子比解释五百字还有效：
模型会模仿"参数堆叠 + 短句"的风格输出。
6. 把这次经验沉淀成模板
每次写产品文案都重复以上过程很累。把它做成模板：
你是电商文案专家。
按以下规则写产品卖点：
- 卖点共 {{N}} 条
- 每条不超过 {{length}} 字
- 用动词开头，避免空形容词
- 每条要把参数翻译成用户体验
产品参数：
{{params}}
目标用户：
{{audience}}
参考语气（可选）：
{{style_example}}
下次只要填空，输出质量就稳定。
7. 第二个提示词：代码审查
换个场景：让 Claude 审查一段代码。
朴素写法
帮我看下这段代码有什么问题：
def login(user, pwd):
sql = f"SELECT * FROM users WHERE name='{user}' AND pwd='{pwd}'"
return db.query(sql)
模型可能输出一段长篇大论，包括代码不规范、命名问题、可读性等。信号太多，重点反而被淹没。
改进版
你是一名资深安全工程师，请审查下面这段代码。
只关注：
- SQL 注入
- 密码存储
- 时序攻击
不要讨论：
- 命名风格
- 代码格式
- 一般性可读性
代码：
def login(user, pwd):
sql = f"SELECT * FROM users WHERE name='{user}' AND pwd='{pwd}'"
return db.query(sql)
输出格式（markdown 表格）：
| 严重程度 | 问题 | 修复建议 |
输出会聚焦在三类风险，按表格清晰列出，可以直接转给开发同事。
8. 第三个提示词：信息提取
让模型从非结构化文本里提取结构化数据。
从下面文本中提取信息，按 JSON 输出。
字段定义：
- name: 公司名称（字符串）
- founded: 成立年份（整数）
- ceo: CEO 姓名（字符串，无则 null）
- hq: 总部所在城市（字符串）
- products: 主要产品列表（字符串数组）
要求：
- 仅输出 JSON，不要任何额外说明
- 字段缺失用 null，不要省略
- products 至少 3 个，不足时基于公开信息补充常见的
文本：
"""
Anthropic 是一家成立于 2021 年的 AI 安全公司，
总部位于旧金山。其代表产品包括 Claude 系列大模型。
"""
输出：
{
"name": "Anthropic",
"founded": 2021,
"ceo": null,
"hq": "San Francisco",
"products": ["Claude", "Claude API", "Claude Code"]
}
这种"输入文本 → 输出 JSON"的模式，是把 LLM 接入业务系统的核心模式之一。
9. 第四个提示词：开放问答
不是所有任务都有"标准答案"，比如咨询、写作、头脑风暴。
我在做一个本地咖啡店的副业项目，预算 30 万，
位置选在写字楼一楼。
请帮我列出 3 个最容易翻车的环节，并给出风险描述和应对建议。
要求：
- 按"环节 → 风险 → 建议"三段式输出
- 每个环节用粗体标题
- 建议要可执行，不要空话（如"做好选址"算空话）
模型会给出有结构、有可执行性的建议，而不是泛泛而谈。
10. 调试一个不好的提示词
假设你写了：
输出大概率是百科式的、空洞的、3000 字的注水文。怎么改？
Step 1：明确受众
Step 2：明确目标
Step 3：明确格式
Step 4：定下调性
Step 5：给参考
每一步加上去，输出质量都会显著提升。
11. 一个常被忽略的技巧：让模型先确认
模型在不确定时容易硬答。让它先反问，能避免大量返工：
模型会回答：
- 这个产品的核心目标用户是谁？
- 你期望解决的核心问题是什么？
- 是否有时间或预算约束？
回答完，再让它写文档，质量直接两级跳。
12. 一个真实案例的迭代过程
需求：根据一段会议录音整理纪要。
v1（10 分输出 4 分）：
v2（10 分输出 6 分）：
v3（10 分输出 8 分）：
你是一名专业会议助理。
将下面会议录音整理成纪要，要求：
1. **参会人**：列出所有发言过的人（按发言顺序）
2. **议题**：每个议题一段，包含：
- 议题名（粗体）
- 主要观点（每位发言人的核心立场，1-2 句）
- 结论
3. **待办**：表格形式
| 任务 | 负责人 | 截止时间 |
要求：
- 不要逐字记录，要凝练
- 不要丢失反对意见
- 看不出来的待办时间填"未明确"
录音：
{{录音文本}}
v4（10 分输出 9 分）：
加上一个范例 + 让模型先确认听不清的部分：
迭代到 v4，已经可以直接发给团队。整个过程才 10 分钟。
13. 常见问题
Q：提示词写到多长合适？ A：能短就短。关键是信息密度而不是长度。300 字胜过 3000 字水文。
Q：英文提示词比中文好用吗？ A：早期模型确实英文效果更好。Claude/GPT-4 之后差距很小，用你最熟悉的语言写得更细才重要。
Q：每次都要写很长很烦怎么办？ A：建提示词模板库，重复任务用 Cursor / Custom GPTs / Claude Projects 等保存复用。
Q：模型经常不按格式输出怎么办？ A：1）用 JSON 强约束；2）给一个完整示例；3）在提示词最后再强调一次"只输出 JSON，不要任何前后文字"。
14. 检查清单
写完提示词后，对着这 8 条过一遍：
- 角色 / 任务 / 上下文 / 约束 / 格式 / 示例 是否齐全？
- 有没有模糊词（"差不多"、"尽量"、"最好"）？
- 有没有具体的数值约束（字数、条数、长度）？
- 否定指令是否能改成肯定指令？
- 输出格式是否明确（JSON / Markdown / 表格）？
- 复杂任务是否拆成了多步？
- 是否给了至少 1 个示例（可选但推荐）？
- 关键约束有没有在末尾再强调一次？
总结
- 写提示词 = 把模糊的需求翻译成模型能稳定执行的指令
- 五个改进步骤：加具体信息 → 加约束 → 加示例 → 沉淀模板 → 让模型先反问
- 调试不好的提示词：明确受众、目标、格式、调性、参考
- 复杂任务用迭代法（v1 → v2 → v3），每次只改一个维度
- 用检查清单（8 条）兜底，确保关键要素不遗漏
- 沉淀自己的模板库，是工程化使用 LLM 的第一步