---
title: "Claude 好提示词 vs 坏提示词：20 组实战对比案例"
description: "把「写清楚」拆成六个可检查的维度，用周报、SQL 排错、活动通知三组改写示范，说明好提示词到底多了什么。"
updated: 2026-11-13
canonical: https://docai.cc/learn/good-vs-bad-prompts/
markdown_mirror: https://docai.cc/learn/good-vs-bad-prompts.md
---
## 坏提示词多半缺三样

缺对象：不知道写给谁看，模型只能取平均口味，写出来的东西谁都能用，也就谁都不适用。

缺标准：没说什么算完成，长度、结构、语气全靠猜。它交一篇一千字的文章，你无法说它错，只能说不是你要的。

缺禁区：没说什么不能做，模型就会自由补全，包括编造数据、替你表态、加一堆套话。

把提示词当成一份任务说明，而不是一个搜索词，问题就暴露了。

## 六个维度的一张检查表

| 维度 | 常见写法 | 要补的内容 |
| --- | --- | --- |
| 读者与用途 | 帮我写个通知 | 谁看、看完要做什么 |
| 背景 | 直接抛任务 | 已知条件、限制、前因后果 |
| 结构 | 随便写 | 分几块、每块放什么 |
| 长度 | 不设限 | 字数或条目数 |
| 语气 | 正式一点 | 可参照的对象、要避免的腔调 |
| 禁区 | 不提 | 不许编数字、不许贬低竞品等 |

不是每一项都必须填，但空白越多，模型的自由发挥空间越大。提示词的基本构成，可以再看[什么是提示词](/concepts/prompt/)。

## 三组改写示范

### 示范一：周报

坏写法只有四个字：帮我写周报。

好写法：

```
写一份本周周报，读者是部门负责人。
背景：登录改版已上线；支付对账延期，原因是第三方接口变更。
结构：已完成 / 进行中 / 风险与需要支持。
限制：每部分不超过 5 条；风险要写影响范围和希望谁做决定。
语气：陈述事实，不用「赋能」「闭环」这类词。
不要补写我没有提供的进展。
```

差别不在字数，而在可检验：读完能判断这份周报是否合格。

### 示范二：SQL 排错

「帮我优化这条 SQL」几乎必然得到泛泛而谈。换成带上下文的问法：

```
这条查询在订单表 800 万行时耗时 6 秒，目标 1 秒内。
表结构：orders(id, user_id, status, created_at)，status 上有索引。
执行计划：全表扫描。
约束：不能改表结构，不能动已有索引。
请先指出最可能的瓶颈，再给两种改写方案并比较代价。
```

数据量、现状、目标、限制四项一摆，回答才会落到具体位置，而不是复述索引常识。

### 示范三：活动通知

坏：写个活动通知。

好：写给园区里的入驻企业，通知周五下午的消防演练；必须包含时间、集合点、预计时长、需要携带的物品；三百字以内；语气是行政通知，准确优先；不要写「隆重举行」这类套话。

同一件事，坏提示词给你一篇模板，好提示词给你一篇能直接发的东西。要模仿某种固定文体时，附两三条样例比堆形容词更有效，做法见[什么是少样本提示](/concepts/few-shot/)。

## 另外十七组一句话对照

标题里的 20 组，前面三组展开讲透，其余压成一句话，方便按场景查找。左边是常见的随手写法，右边补上对象、条件或可验收的标准。

| 场景 | 坏提示词 | 好提示词 |
| --- | --- | --- |
| 产品介绍 | 写个产品介绍 | 给采购经理写 120 字产品介绍：突出三年保修与上门安装，不写「行业领先」这类空话，结尾留联系方式 |
| 文字润色 | 润色一下 | 把这段文字改得更克制：删掉重复的形容词，保留全部数字和原意，长度不超过原文 |
| 道歉邮件 | 写封道歉信 | 给延迟收货的客户写道歉邮件：说明原因、给出新到货时间、提供两个补偿选项，150 字内，不推卸责任 |
| 起标题 | 起个标题 | 给这篇文章起 10 个标题：面向刚接触 AI 的职场人，不用夸张词，每个不超过 20 字 |
| 报错排查 | 报错了怎么办 | 贴出完整报错、相关代码和运行环境；先判断原因，再给最小修改，不要重写整个文件 |
| 写爬虫 | 写个爬虫 | 用 Python 抓取一个公开列表页：遵守 robots.txt，每秒最多一次请求，结果存 CSV，先给可运行的骨架 |
| 代码优化 | 优化这段代码 | 说明慢在哪里、目标耗时、不能改的接口；先判断瓶颈，再给两种改法和各自的代价 |
| 补测试 | 写点测试 | 为这个函数补单元测试：覆盖正常输入、边界值和异常输入，用 pytest，断言写清楚预期行为 |
| 问卷分析 | 分析下问卷 | 这份问卷 500 份，我要判断新功能能否上线；按年龄段交叉统计满意度，标出样本量不足的分组 |
| 竞品分析 | 做个竞品分析 | 对比 A、B 两家在定价、功能覆盖、目标客户上的差异，用表格呈现，数据注明来源与日期 |
| 找数据异常 | 看看这数据 | 按周汇总这份销售表，找出环比波动超过 20% 的品类，列出对应订单号供我抽查 |
| 解释概念 | 解释一下 Docker | 我是后端新手，用「打包行李」类比解释镜像和容器，说明两者区别，再给三条最常用命令 |
| 学习计划 | 给个学习计划 | 我每天能学 40 分钟，目标三个月内独立做一个静态网站；按周拆分，每周一个可验收的小作品 |
| 论文总结 | 总结这篇论文 | 用「问题—方法—实验—局限」四段总结，术语第一次出现时给中文解释，最后列出三条可复现的步骤 |
| 回复消息 | 帮我回这条消息 | 对方在催进度，我要如实说明延期两天并给出补救方案；语气礼貌、不卑不亢，80 字内 |
| 会议纪要 | 总结下会议 | 按「结论 / 待办（负责人与截止日）/ 未决问题」三块整理，只写记录里出现的信息，没定的事标「待定」 |
| 需求评审 | 看看这个需求 | 从开发角度评审这份需求：指出缺失的验收标准、可能的边界情况，以及需要产品确认的三个问题 |

这十七组的共同点只有一个：把「好一点」「专业一点」这类无法验收的词，换成对象、范围或可检查的结果。

## 要求越多越好吗

不是。堆到互相冲突，模型只能取舍。同时要「简短」和「覆盖所有细节」，结果通常两边都不讨好。

一次只解决一个任务；把长期稳定的偏好放进[系统提示词](/learn/write-a-system-prompt/)或自定义指令，不要每次重复；临时条件写进当前这条消息。

还有一个简单判据：把提示词发给一个不了解背景的同事，如果他需要追问才能动手，模型多半也需要。先补背景，再加要求。

如果一条提示词反复改仍不满意，先检查任务本身是否过大。拆成两步，往往比继续加形容词有效。

写完对照一遍：哪条要求是模型无法验证的？删掉它，结果往往更稳。

## 自测

1. 你最近的提示词里，读者和用途写清楚了吗？
2. 有没有一条要求模型根本无从判断是否做到？
3. 去掉哪条要求，结果反而会更好？

好提示词不是更长的提示词，而是把「完成」定义得更清楚。下一节换一类材料：[把文件交给 Claude 之前要知道的事](/learn/claude-file-upload-guide/)。