Claude 好提示词 vs 坏提示词：20 组实战对比案例

坏提示词多半缺三样

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

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

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

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

六个维度的一张检查表

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

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

三组改写示范

示范一：周报

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

好写法：

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

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

示范二：SQL 排错

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

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

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

示范三：活动通知

坏：写个活动通知。

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

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

另外十七组一句话对照

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

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

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

要求越多越好吗

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

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

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

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

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

自测

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

好提示词不是更长的提示词，而是把「完成」定义得更清楚。下一节换一类材料：把文件交给 Claude 之前要知道的事。