你不是不会用 AI,你只是没把话说清楚

最近听到不少吐槽，说 AI 越用越气。

让 AI 写个方案，AI 端上来一盘“正确的废话”；让 AI 总结一篇文章，它总结得像领导发言；让 AI 写代码，AI 一脸自信地编了个不存在的库。最后得出结论：AI 也就那样。

后来看了一眼提示词，沉默了。

写的是：

帮我写一下这个。

好家伙。

这就像你走进一家饭店，跟厨师说“给我做个吃的”，然后嫌人家没做出你梦里的那碗牛肉面。AI 确实很强，但它还没强到能从你四个字里读出你的人生经历、业务背景、老板偏好和交付格式。

很多人以为自己在使用 AI，其实是在考验 AI 算命。

这就是提示词工程（prompt engineering）真正要解决的问题。大白话就是：你怎么把任务交代清楚，让模型少猜一点，多做一点。

OpenAI 官方前几天也分享了一套很实用的方法。看完之后你会发现，所谓高手提示词，很多时候没有什么神秘咒语，就是几个朴素到不能再朴素的常识。

只不过，大多数人平时懒得做。

OpenAI 文档开头就提到：因为模型的训练方式不同，有些提示词格式确实更容易让模型产出有用结果。这句话翻译成人话就是，AI 对“表达方式”很敏感。

同样是让它总结文章，你把指令和原文混在一起，它可能会读懵；你先说任务，再用清楚的边界把原文框起来，它就更容易知道哪部分是命令，哪部分是材料。

效果差一点的写法是：

请把下面这段文字总结成要点列表，只保留最重要的信息。{在这里放入文本}

更稳的写法是：

请把下面这段文字总结成要点列表，只保留最重要的信息。 Text: """{在这里放入文本}"""

这里的 “”” 作用就是划边界。

它在告诉模型，前面是你要做的事，后面才是你要处理的材料。就像你给同事发需求，最好别把需求、聊天记录、老板原话、参考链接全糊成一坨。人看了都头大，AI 也不例外。

我一直觉得，提示词写不好的人，往往不是不会用 AI，而是没有养成“交代任务”的习惯。在公司里，这种人也很常见。他让设计师“高级一点”，让运营“有网感一点”，让程序员“简单改一下”，让 AI“优化一下”。听起来都很轻松，落到执行层，个个都是天坑。

尽量使用最新、能力最强的模型。原因也不复杂。新模型通常更强，也更容易被提示词调动起来。你给它一个清楚的任务，它更可能理解你的意图，而不是在旁边疯狂脑补。

这就像你找人干活。一个经验丰富的人，你说半句他能接住；一个刚入行的人，你把流程写成 SOP，他也可能漏掉两步。模型也是这样，能力越强，提示词工程的性价比越高。

当然，文档也提醒了一个细节：给推理模型（reasoning model）写提示词，和给 GPT 模型写提示词，会有一些差别。（推理模型可以简单理解为更擅长多步思考、数学推理、复杂决策的模型。它处理任务时更像是在“想一想再答”，而普通 GPT 模型更偏向快速生成自然语言内容。）

这事儿不用神化。你只要记住一个原则：模型越强，越值得你把任务说清楚。别拿最新模型当许愿池，往里面扔一句“帮我搞定”，然后坐等奇迹发生。AI 再聪明，也不该替你承担表达混乱的成本。

OpenAI 的第三条建议，我觉得是最值钱的一条：对你想要的上下文、结果、长度、格式、风格，说得越具体越好。很多人的提示词都死在“差不多”三个字上。

“写短一点。”“写得专业一点。”“别太啰嗦。”“风格活泼一点。”

这些话对人类同事都不算清楚，对 AI 更是大型猜谜现场。短一点是 100 字还是 800 字？专业一点是行业报告，还是少说废话？活泼一点是轻松口语，还是互联网黑话乱飞？

文档里给了一个例子。效果较差：

写一首关于 OpenAI 的诗。

更好：

写一首简短、鼓舞人心的诗，主题是 OpenAI，重点放在最近发布的 DALL-E 产品上。DALL-E 是一种文本生成图像的机器学习模型，请模仿 {某位著名诗人} 的风格。

差别就是：后者给了主题、情绪、长度倾向、产品背景、风格参照。模型不用在一片雾里自由发挥，产出自然更接近你想要的东西。

这件事放到公众号写作里也一样。你不能只说“帮我写篇 AI 文章”。你得说读者是谁，是普通用户还是开发者；文章多长，是 800 字短评还是 3000 字深度文；语气是什么，是冷静科普还是犀利评论；要不要保留 Markdown 格式；术语要不要解释。你交代得越完整，AI 越不像废话机器。反过来，你越懒，AI 越像实习生第一次写周报。

还有一个很多人忽略的点：想要固定格式，就把格式展示出来。OpenAI 官方也说了，模型在看到具体格式要求时，通常表现更好。这种方法叫“展示并说明”。别只告诉它“提取实体”，你可以直接给它一个输出模板。

比如效果较差的写法：

从下面的文本中提取提到的实体。请提取以下 4 类实体：公司名称、人名、具体话题和主题。 Text: {text}

更好的写法是：

从下面的文本中提取重要实体。请先提取所有公司名称，再提取所有人名，然后提取与内容相关的具体话题，最后提取更宏观的主题。 Desired format:Company names: <用逗号分隔的公司名称列表>People names: -||-Specific topics: -||-General themes: -||-Text: {text}

这一步特别适合那些要接程序处理的场景。比如你要批量从用户反馈里提取问题类型，或者从新闻里抽取公司、人名、主题。输出格式越稳定，后面程序越好解析。你要是只说“整理一下”，模型今天给你表格，明天给你 bullet list，后天给你一段散文。

程序员看了血压直接拉满。

我之前见过一个团队，用 AI 做客服工单分类，最开始提示词写得很潇洒：“请判断用户问题属于哪一类。”结果模型输出一会儿是“退款问题”，一会儿是“用户想退款”，一会儿是“该问题和售后相关”。人能看懂，机器不好接。

后来他们把格式卡死：

Category: Reason: <一句话说明>

世界清净了。AI 能不能稳定朝着一个方向走，关键是你有没有给它设置轨道。

我们在测试模型的时候，一个很常见的顺序是：先试零样本（zero-shot），再试少样本（few-shot），都不行，再考虑微调（fine-tune）。

（零样本就是不给示例，直接让模型完成任务。少样本就是给模型几个输入和输出样例，让它照着模式继续做。微调则是用一批训练数据进一步训练模型，让它更适合某类特定任务。）

很多人一遇到效果不好，第一反应就是：是不是要微调？先别上来就开大。微调当然有价值，但它成本更高，维护也更麻烦。很多普通任务，提示词写清楚一点，给几个示例，效果就已经够用了。

零样本的写法可以很简单：

从下面的文本中提取关键词。 Text: {text} Keywords:

如果效果不稳定，就给几个样例：

文本 1：Stripe 提供了一组 API，网页开发者可以用它们把支付处理功能集成到自己的网站和移动应用中。关键词 1：Stripe、支付处理、API、网页开发者、网站、移动应用##文本 2：OpenAI 训练了先进的语言模型，它们非常擅长理解和生成文本。我们的 API 提供了访问这些模型的能力，可用于解决几乎所有涉及语言处理的任务。关键词 2：OpenAI、语言模型、文本处理、API##文本 3：{文本}关键词 3：

这就像带新人。你只说“照公司风格写”，新人满脸茫然；你拿出两篇合格样稿，说“就按这个结构和颗粒度来”，对方马上知道边界在哪里。AI 也吃这一套。

所以，别一开始就幻想训练一个专属模型。很多时候，你缺的不是微调，缺的是几个好例子。

OpenAI 文档里专门提到，要减少 “fluffy and imprecise descriptions”。就是少写那些听起来像说了很多、其实没有给出明确标准的话。

提示词里最常见的 fluffy 句子，大概长这样：

这个产品描述应该相当简短，只要几句话，不要写太多。

看起来没毛病，其实全是毛病。相当简短是多短？几句话是几句？不要太多是不要超过多少？更好的写法是：

用一段 3 到 5 句话的文字来描述这个产品。

一下子清楚了。这就是提示词里的硬尺子。你给 AI 一个可执行标准，它就能围着标准干活。你给它一团感觉，它只能凭感觉编程，最后产物也很“凭感觉”。

写提示词时，能用数字就用数字，能给范围就给范围，能给格式就给格式。不要说“简洁”，说“控制在 150 字以内”；不要说“详细”，说“分 5 个要点，每个要点 2 句话”；不要说“像公众号”，说“用面向普通读者的公众号风格，开头用一个具体场景切入，每 3 到 5 段设置一个小标题，避免学术论文腔”。

这不是啰嗦。这是把模糊需求翻译成可执行任务。

还有一类提示词，看起来很用力，其实是在把 AI 往沟里带。比如你手里有一段产品介绍，想让 AI 改得更适合普通用户阅读。很多人会这么写：

请把下面这段产品介绍改得好一点。不要太长，不要太官方，不要用专业术语，不要像广告。 Text: {产品介绍}

这段提示词最大的问题，不是要求少，而是全在踩刹车。“不要太长”，到底多长算长？“不要太官方”，什么叫官方？“不要像广告”，那要像什么？AI 看到这一串否定句，只能在原地猜拳。

更好的写法，是直接告诉它该往哪儿走：

请把下面这段产品介绍改写给第一次了解这个产品的普通用户看。写法要求：1. 用 3 段完成，每段不超过 80 字。2. 第一段说清楚它解决什么问题。3. 第二段用一个生活场景解释它怎么用。4. 第三段说明它适合谁、不适合谁。5. 如果出现专业术语，第一次出现时用括号解释。Text: {产品介绍}

看出差别没有？前一个提示词只是在喊“别这样、别那样”。后一个提示词给了读者对象、段落数量、字数边界、内容顺序和术语处理方式。AI 不需要揣摩你的审美，只要照着路线走就行。

这条规则特别适合所有 AI 智能体（AI Agent）场景。不要只写一堆禁令，比如“不要编造”“不要泄露隐私”“不要回答超出范围的问题”。这些都要写，但不够。你还要给替代路径：遇到不知道的问题，就说无法确认，并建议查阅官方文档；遇到隐私信息，就提醒用户不要输入，并引导到安全流程；遇到越权请求，就拒绝，并提供合规范围内的帮助。

人不能只靠红灯开车，AI 也一样。你得告诉它绿灯在哪里。

OpenAI 文档最后还提到一个很有意思的小技巧：代码生成时，可以用“leading words”，也就是引导词，把模型推向你想要的模式。

比如你想让它写 Python 函数，效果较差的提示词是：

# 写一个简单的 Python 函数：# 1. 让我输入一个英里数# 2. 把英里转换成公里

更好的写法是在后面加一个：

import

这相当于把第一笔给它写出来。模型看到 import，更容易顺着 Python 代码的方式继续生成。同理，如果你希望它写 SQL，SELECT 往往是一个很好的开头。

这招非常像老编辑改稿。新人不知道怎么开头，你不用讲一堆大道理，直接给他写第一句，他就能顺着往下走。AI 有时候也是这样，给它一个模式，它就更容易进入状态。

文章最后，OpenAI 提到了几个常用参数。最常见的是 model 和 temperature。

model 很好理解，性能更高的模型通常更贵，也可能有更高延迟。你要在效果、成本和速度之间做选择。

temperature 是温度，控制模型输出“不那么可能出现的词元（token）”的频率。（token 可以粗略理解为模型处理文本时的基本单位，可能是一个词、一个字，也可能是词的一部分。）

温度越高，输出越随机，通常也更有创造性。可随机不等于真实。做数据提取、事实问答这类任务，temperature 设为 0 通常更稳。

还有 max_completion_tokens，它不是用来精确控制文章长度的，而是给生成设置一个硬性上限。模型可能在它觉得回答完成时停下，也可能在撞到这个上限时被截断。stop 是停止序列。模型一旦生成某些指定字符或词元，就会停止输出。

这些参数听起来技术味很重，普通用户不用一开始就全搞懂。记住一个大方向就行：写创意内容，可以适当提高温度；做事实任务，温度低一点；怕输出太长，用上限兜底；需要固定结束位置，就设置停止序列。

别把参数当玄学旋钮乱拧。很多输出不理想，问题不在参数，在提示词。

提示词工程这件事，越学到后面，越会发现它没那么神秘。把任务放开头，用清楚的符号隔开上下文，说清楚长度、格式、风格、读者和目标，能给示例就给示例，先试零样本，再试少样本，微调别急。

少说“差不多”，多给可执行标准。不要只写禁令，要告诉模型替代做法。写代码时，给它一个起手式。这些规则单独看都不高级，甚至有点朴素。可把它们放到一起，就会改变你和 AI 的关系。

以前你是在对 AI 许愿。现在你是在给 AI 派活。

这中间差的不是一句神奇咒语，而是一种工作习惯：把脑子里模糊的期待，翻译成别人能执行的指令。

说到底，AI 时代最先被淘汰的，可能不是不会写代码的人，也不是不会画图的人。是那些永远只会说“帮我优化一下”的人。

欢迎关注「OpenClaw 腾讯云社区」，期待你的「在看」哦～👇