企业官网建设流程全解析

很多人用大语言模型，觉得它“时灵时不灵”，同一个问题换个说法结果就天差地别。这背后的差别，往往不是模型本身的问题，而是提示词写得好不好。提示词工程（Prompt Engineering）说白了，就是一套跟大模型高效沟通的方法论。它不是玄学，也不是靠运气，而是有明确套路、可拆解、可复现的技术活。这篇文章我就围绕“提示词工程怎么写才有效”这件事，把背后最核心的 5 大要素逐个拆开揉碎，再配上可以直接拿去用的实战代码示例，帮你把提示词这件事彻底整明白。

1. 内容整体设计与思路拆解

先聊一个很多人没想透的问题：提示词到底在“工程化”什么？

我见过不少开发者，写提示词跟发朋友圈一样，想到哪儿写到哪儿。比如“帮我写个方案”“给我一段营销文案”，然后抱怨模型输出太水。这不是模型不行，而是信息输入太少了。大模型的本质是一个概率模型，你给它的信息越多、越精准，它生成的输出就越贴近你的预期。提示词工程的核心，就是设计一套“信息投喂”策略，让模型在有限的上下文里，尽可能理解你到底想要什么。

我梳理了一下，一套有效的提示词，几乎总是包含这 5 大核心要素：

1. 角色设定：告诉模型“你是谁”。
2. 任务指令：告诉模型“你要干什么”。
3. 上下文信息：告诉模型“你还需要知道什么背景”。
4. 输出约束：告诉模型“你该以什么形式回答”。
5. 示例引导：告诉模型“你参考我的标准来”。

这五个要素放在一起，就像你给一位新来的同事交代工作。你光说“把这份数据整理一下”，他大概率不知道你要的是表格、PPT还是分析报告，也不知道你的数据处在什么业务背景下。但你如果告诉他“你是数据分析师，请把这份季度销售数据整理成一张按月汇总的表格，毛利和净利单独列一列，风格参照我上个月那份报表”——他立刻就知道该怎么做了。

这套逻辑本身并不依赖某一家模型厂商，也不依赖具体代码框架。它可以应用在纯文本对话里，也可以应用在调用 API 的工程代码中。这也是为什么说提示词工程是一种“通用能力”：掌握了它，你换哪个模型都能快速上手。

在写这篇文章之前，我其实做过一次小范围的对比测试。同样一个任务，分别用“一句话指令”和“五要素完整指令”去调用同一个模型，输出质量的差距可以说判若云泥。后面我会把完整的测试对比过程、代码都放出来，你可以自己跑一遍感受下。

2. 核心要素逐项拆解：这 5 个维度到底怎么玩

2.1 角色设定：给模型一个“人设锚点”

角色设定是提示词里最容易被忽略，但效果立竿见影的一个要素。你让模型“写一段关于咖啡的介绍”，和你说“你是资深咖啡师，正在为一本美食杂志写一篇面向咖啡爱好者的深度介绍”，产出的内容专业度和风格都会完全不同。

为什么一个简单的人设变化会带来这么大差别？原因在于，大模型在生成文本时，会依赖于它在训练阶段学到的“语境相关性”。当你设定了角色，模型就会倾向于从这个角色的知识分布里抽取内容。这个机制有点像“表演”：你给演员一个角色，他自然会进入状态，调动的表情、语气、词汇都会往那个方向靠。

实操的时候，角色设定不能太宽泛。比如“你是专家”这种设定就太虚了，模型不知道自己是什么领域的专家。正确的写法是带上具体领域、具体身份、甚至具体立场：

• 弱：你是畅销书作家。
• 强：你是一位擅长写非虚构类作品、尤其擅长把复杂技术概念讲给普通读者听的科普作家。

角色设定还可以配合“任务场景”一起使用。比如让模型扮演“恶意用户”来测试你自己写的提示词，检验提示词的鲁棒性，这就是一种很经典的对抗性用法。我在做自动化内容审核系统的时候，经常让模型同时扮演“审核员”和“违规发布者”两个角色，互相博弈来找提示词的漏洞，效果非常好。

2.2 任务指令：把需求说清楚是基本素养

任务指令是整个提示词的主干，它直接告诉模型要做什么。很多人的问题是：任务描述得太模糊，或者一次塞了太多任务。

先说模糊的问题。“分析这段数据”就是一个典型的模糊指令。数据是什么格式？从哪些维度分析？有没有重点指标？输出形式是什么？这些没讲清楚，模型就只能靠猜。而猜的结果，就是输出内容五花八门，每次都不稳定。

再说任务太多的问题。有人喜欢一口气让模型“先总结文章，再提取关键词，再翻译成英文，再写一段推荐语”，看起来很高效，但模型在一段提示词里同时处理多个任务时，注意力和输出质量都会被稀释，最后往往两头不讨好。更稳妥的方案是拆分成多个步骤、多次调用，每次只让模型做一件事。

在写任务指令时，我总结了一个“三句话公式”：

• 第一句话：动作词 + 核心对象（比如“提取这份文件的要点”）。
• 第二句话：限定条件（比如“只提取与成本相关的信息，不要其他内容”）。
• 第三句话：输出要求（比如“用列表形式，每条不超过50字”）。

这套公式看着简单，但你实际去用的时候会发现，它几乎能应对90%以上的基础任务。它的本质是通过“减法”削减模型的自由发挥空间，让输出更可控。

2.3 上下文信息：少让模型当“盲人摸象”

上下文信息是决定提示词质量的“天花板”。模型本身不具备读取你脑子的能力，它只知道你给它看了什么。你给的背景信息越充分，它的输出就越贴合实际情况。

我举个真实的例子。之前我帮一个做电商的朋友优化商品文案生成流程，他最初的提示词是“帮我把这个商品写一个吸引人的标题”。输入的商品信息只有名称和一个价格数字。产出的标题基本是通用模板，什么“超高性价比”“不容错过”，完全没有商品的核心卖点。

后面我帮他把提示词改成带上完整的“商品信息卡片”：材质、工艺、使用场景、目标人群、差异化优势、历史竞品分析。结果生成的标题和文案质量直接上了一个台阶。差别在哪里？就在于模型拿到了一张“信息全景图”，它知道自己在什么样的前提下写文案。

上下文信息需要注意一个度的问题。信息太少模型会泛泛而谈，信息太多又会冲淡主线任务。我的经验是：所有上下文信息都要和最终任务直接相关，和任务无关的细节果断删掉。比如你要模型做多轮对话，那对话历史就是上下文的关键；你要模型做知识库问答，那检索到的相关文档片段就是上下文的核心。不分青红皂白把一堆资料丢给模型，不仅浪费 token，还可能干扰它的判断。

2.4 输出约束：给模型的回答装上“骨架”

输出约束的作用，是把模型的输出框在既定的边界里。用术语说，就是让生成结果具备“高可解析性”和“高可控性”。

最常用的输出约束包括几种：格式约束（比如用 JSON、Markdown、表格）、长度约束（比如限制在 X 字以内）、结构约束（比如“分三段输出，每段一个小标题”）、以及内容约束（比如“不要包含价格信息”“不要用评价性语言”）。

在实际项目里，格式约束的价值会被放大。因为当你用代码调用大模型时，往往还要做后续的程序处理。如果模型返回的是一段自由文本，你去解析它的成本会很高。但如果你在提示词里要求它“严格按 JSON 格式输出，包含 name、price、reason 三个字段”，那后续的数据处理就顺畅多了。

举一个典型例子：

请分析下面这段用户评论的情感倾向，输出 JSON 格式，包含 sentiment 字段（取值为 positive/negative/neutral）和 confidence 字段（取值为 0 到 1 之间的小数）。

像这样明确的约束，即便模型有时理解力有限，也会因为格式骨架的存在而“收敛”得很规矩。有些模型甚至能稳定输出你要求的字段，只是偶尔会有字段缺失或类型错误，这时候你可以在代码里加一个 JSON 解析的容错机制兜底。

长度约束是另一个容易翻车的地方。很多人说“一句话总结”，结果模型输出了一大段。因为“一句话”在模型的理解里很模糊。更精确的写法是“用一段话总结，字数不超过 30 个字”。注意，“不超过30个字”和“最多30字”其实也有细微差别，但总体上，数字化的约束永远比形容词靠谱。

2.5 示例引导：一句话胜过千言万语

如果说前面四个要素都是“说教”，那示例引导就是“示范”。你给模型一个输入和输出的对应示例，它就能从示例里反推你的偏好和标准。

示例引导在业界有个更专业的名字叫 Few-shot Learning（少样本学习），核心原理是让模型通过类比来完成任务。它尤其适用于那些不太好用规则描述的任务，比如风格转换、语气模仿、内容改写等。

举个例子。你想让模型把产品文案从“正式商务风”改成“活泼口语风”，光说“改写一下”是不够的。但你给它一个对照示例：

输入原文：本公司致力于为用户提供一站式数字化转型解决方案。 输出示例：我们是干什么的？帮你搞定数字化转型，一站式那种！

再给它另一个产品的原文，让它照着示例的风格去写，效果就会好很多。它会自动学习示例里那种短句、设问、口语化的表达特征，而不是用一堆“亲和”“高效”之类的空词来搪塞你。

示例也不是越多越好。一般情况下，两三个高质量示例就足够，太多了反而会让模型“学偏”。另外，示例要尽量贴近你的真实任务场景，领域差异过大的示例会起反效果。比如你让它模仿某短视频平台的文案风格，示例就一定要选该平台上的真实爆款文案，而不是拿微博评论来凑数。

3. 实战代码示例：一套可复用的提示词封装方案

理论说完，直接上代码。我这里提供一个基于 Python 的提示词封装示例，它把前面讲的 5 大要素做成了可配置的结构，方便你在真实项目里直接使用。

3.1 先看一个效果对比：一句话指令 vs 五要素指令

我觉得这个对比特别有冲击力，先展示给你看。

我用同一个模型，分别给两种提示词，任务都是“写一个咖啡品牌的新品推广语”。

第一组提示词：

帮我写一个咖啡品牌的新品推广语。

模型输出：

这款咖啡口感醇厚，香气扑鼻，是您日常生活中不可错过的选择。限时优惠，快来抢购！

第二组提示词（完整五要素）：

角色：你是资深品牌营销专家，擅长捕捉年轻消费者的心理。 任务：为一款主打"冷萃冻干"的精品黑咖啡写一句推广语，突出便捷和口感。 背景信息：目标人群是 25-35 岁的一线城市上班族，工作忙但追求品质，经常早上来不及去咖啡店。 输出约束：字数控制在 20 字以内，语气要有活力，不能出现"醇厚""精选"等烂大街的词，不用感叹号，只输出推广语本身，不要解释。 示例： 传统写法：精选优质咖啡豆，醇厚口感无可挑剔。 优秀写法：冷水一冲，3秒解锁咖啡馆级黑咖。

模型输出：

不用出门，冷水即溶，你的随行咖啡馆。

看到差距了吗？第一个结果更像“通用广告词生成器”的产物，第二个则是完全贴合产品卖点、人群场景和品牌调性的定制文案。这种输出质量的差距，就是提示词工程的价值所在。

3.2 结构化提示词封装类

实际写代码的时候，不要每次手动拼字符串，而是用一个可配置的结构来管理提示词。我习惯这样写：

# prompt_engine.py import json from typing import Optional, List, Dict class PromptTemplate: def __init__(self, role: str = "", task: str = "", context: str = "", constraints: Optional[List[str]] = None, examples: Optional[List[Dict[str, str]]] = None): self.role = role self.task = task self.context = context self.constraints = constraints or [] self.examples = examples or [] def build(self) -> str: parts = [] if self.role: parts.append(f"角色：{self.role}") if self.context: parts.append(f"背景信息：{self.context}") parts.append(f"任务：{self.task}") if self.constraints: parts.append("输出约束：") for c in self.constraints: parts.append(f"- {c}") if self.examples: parts.append("示例：") for e in self.examples: parts.append(f"输入：{e['input']}") parts.append(f"输出：{e['output']}") return "\n".join(parts) def call_model(prompt: str, model: str = "your_model_name", temperature: float = 0.5, max_tokens: int = 500) -> str: # 这里替换成你实际使用的大模型 API 调用 # 我用的是一个兼容的接口，你换成自己的即可 import openai client = openai.OpenAI(base_url="your_api_endpoint", api_key="your_api_key") resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=temperature, max_tokens=max_tokens ) return resp.choices[0].message.content if __name__ == "__main__": tpl = PromptTemplate( role="资深品牌营销专家，擅长捕捉年轻消费者的心理", task="为一款主打冷萃冻干的精品黑咖啡写一句推广语，突出便捷和口感", context="目标人群是25-35岁一线城市上班族，工作忙但追求品质", constraints=[ "字数控制在20字以内", "语气要有活力", "不能出现『醇厚』『精选』等烂大街的词", "不用感叹号", "只输出推广语本身，不要解释" ], examples=[ {"input": "传统写法", "output": "精选优质咖啡豆，醇厚口感无可挑剔。"}, {"input": "优秀写法", "output": "不用出门，冷水即溶，你的随行咖啡馆。"} ] ) prompt = tpl.build() print("生成的提示词：\n", prompt) result = call_model(prompt) print("\n模型输出：\n", result)

这段代码你把 API 地址和密钥换成自己的就能跑。数据流非常清晰：先组装提示词，再调模型，最后拿到输出。

这里还要提一个小细节：temperature参数。它是控制模型随机性的重要旋钮。你对输出要求稳定、格式严谨时，把 temperature 调低（0~0.3）；你需要模型发挥创意、生成多样化内容时，把 temperature 调高（0.7~1.0）。我在做结构化数据提取任务时，通常直接设成 0，让模型输出结果尽量收敛；做营销文案生成时，会调到 0.8 左右，避免每次结果都一模一样。

3.3 输出结果的结构化解析

如果你让模型输出 JSON，那就涉及解析问题。我习惯写一个容错解析函数，因为你直接json.loads很容易被模型的多余文本搞崩。

import json import re def parse_json_response(text: str) -> dict: # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 如果模型返回的内容里包含 JSON 代码块，先提取 code_block = re.search(r"```(?:json)?\s*(\{.*?\})\s*```", text, re.DOTALL) if code_block: try: return json.loads(code_block.group(1)) except json.JSONDecodeError: pass # 如果模型返回的是纯文本开头和结尾，尝试找到第一个 { 和最后一个 } start = text.find("{") end = text.rfind("}") if start != -1 and end != -1: try: return json.loads(text[start:end+1]) except json.JSONDecodeError: pass raise ValueError(f"无法解析模型输出为 JSON：{text}")

这套容错逻辑我一直在用，覆盖了绝大多数模型返回格式不稳定的情况。尤其在对接开源模型或者本地微调模型时，这类看似简单的兜底函数能帮你省下一大把调试时间。

4. 常见问题与排查技巧实录

提示词工程虽然讲究方法，但实战中永远会遇到新问题。这里整理几个我频繁踩过的坑，以及对应的排查思路。

4.1 模型不从你的“示例”里学习怎么办

这是初始化使用示例引导时最常见的问题。你给了模型一个很好的示例，但它输出的时候完全无视了，还是按自己的习惯来。这种情况很多时候不是示例没用，而是示例太少了，只给一个示例模型很难形成稳定的模式。

解决方案是我前面提过的：至少给出 2~3 个示例，并且示例之间要有明确的差异对比，比如一个“错误写法”加一个“正确写法”。模型会从这种对比里学到“边界在哪里”，比只给一个孤立的正面示例有效得多。也可以尝试在示例前后加上解释性文字，比如“注意，下面的示例中，优选用例的特点是……”。

4.2 输出结果总是“太啰嗦”或者“太简短”

这个问题的根源多数在约束不够量化。你让模型“简洁一点”，它不会知道什么叫简洁。把它改成“用 5 条列表输出，每条不超过 20 字”，它立刻就能执行到位。

同样地，有时候你希望答案足够详细，结果它三句话讲完了。你需要在提示词里加一条“请从背景、现状、问题、建议四个维度展开，每个维度不少于 100 字”。数字是模型最容易理解的约束方式，没有之一。

还有一个容易被忽略的原因：模型的max_tokens参数你可能设置得太小了。如果模型生成到一半被截断，那输出肯定看起来“不够长”。排查的时候先检查这个参数，再优化提示词。

4.3 角色设定有时候会“失效”

有些模型对角色设定的响应不明显，特别是在模型能力偏弱或者角色描述和任务脱节的时候。比如你设定“你是资深医生”，但让它去写相声段子，模型就很难把这两个信息自然融合。

解决方法是把角色设定和任务场景缝合在一起，而不是各说各话。比如“你是一位擅长把专业医学知识融入日常幽默段子的写手，请为一场医院开放日活动写 3 个 30 秒的暖场相声梗”。这样角色的“知识背景”和任务的“表达形式”就统一到一个语境里了。

如果模型还是不听，可以在角色定义后加一句“以上角色设定必须严格遵守”，或者把角色设定重复到任务描述里。这算是一种“笨办法”，但实测在某些场景下效果立竿见影。

4.4 上下文太长，模型“记不住前面说的话”

大模型有上下文窗口限制，超过窗口长度时，早期的内容会被截断或者被模型“忽略”。这在很多问答系统里特别常见：你把一大段知识库资料全塞进提示词，结果模型只重点看了后半段。

解决思路有三条：一是优先把与任务最相关的内容放在提示词的后半部分，因为有些模型对越靠后的内容关注度越好；二是做内容检索，不要全塞进去，只挑和问题匹配度最高的片段；三是把长文本做摘要压缩后再输入。我在做知识库问答系统的时候，通常会用向量检索把候选文档压缩到 5~10 个片段，再交给模型，效果远比全量塞入好得多。

4.5 输出的 JSON 字段时有时无

这种情况非常折磨人。模型明明答应你输出 JSON，结果第二个字段它有时候给、有时候不给，还有的时候给你串成一个字符串。

排查的时候我会先做一件事：把temperature调到 0 再跑一遍。如果输出稳定了，就说明是随机性带来的字段缺失。如果还是不稳定，那大概率是提示词对字段的定义不够清楚，或者字段命名和模型的预训练知识冲突了。

一个更稳妥的做法，是在提示词里直接给一个“字段模板”：

请严格按以下 JSON 结构输出，不要额外加字段： {"公司名称": "", "成立年份": 0, "主营业务": ""}

这种“填空式”约束，比单纯说“输出 JSON 格式”要清晰得多，模型照着填就行，基本不会跑偏。

4.6 常见问题速查表

这张表是我自己日常排查问题时的首选清单。每次遇到提示词效果不达标，我都会先对照这张表按顺序检查，而不是凭感觉乱调。值得提醒的是，一次只改一个变量。很多人喜欢一次性把提示词改了七八处，然后发现效果变好了，却根本不知道是哪一步起的作用。提示词工程的本质是“实验科学”，保持变量可控才能持续积累经验。

5. 进阶玩法：从“写提示词”到“设计提示词系统”

一旦你熟练掌握了单个提示词的设计方法，就可以把它从“单次调用”升级到“系统化设计”。这里分享三个我正在用的进阶技巧。

5.1 链式提示词：把一个复杂任务拆成多步流水线

前面我提到不要在一个提示词里塞多个任务，更合理的做法是设计一条“提示词流水线”。以写一份行业分析报告为例：

• 第一步：让模型提取资料中的核心数据和观点。
• 第二步：让模型基于这些数据生成分析大纲。
• 第三步：让模型按大纲逐段撰写。
• 第四步：让模型做整篇校对和风格统一。

每一步都用独立的提示词模板，输入是上一步的输出。这样做的好处是每一步的目标都很聚焦，模型输出质量更可控，而且你可以在任意一步插入人工修改或审核。不要小看这个“插一脚”的能力，在真实业务流程里，让中间结果经过人审再进入下一步，往往能避免很多连锁错误。

5.2 思维链：引导模型先推理再回答

在处理逻辑推理、数学计算、条件判断类任务时，直接让模型给答案很容易出错。一个通用技巧是引导模型“先展示推理过程，再给出最终答案”。

请解决下面的问题，先写出你的推理步骤，然后给出最终答案。

严格来说，这个叫思维链提示（Chain-of-Thought）。它并不神秘，本质上就是强制模型把思路外显，从而减少盲猜的概率。我在处理一些需要多条件判断的文本分类任务时，经常用这个技巧，发现模型在小样本场景下的准确率提升很明显。

唯一的代价是输出变长了，token 消耗会稍微增加。但多数情况下，这个成本换来的是更高的结果置信度，是划算的。

5.3 自动评估：让模型自己评判自己的输出

质量评估是提示词工程里最容易被低估的一环。你怎么知道这次生成的提示词到底好不好？凭感觉不行，靠运气更不行。一个稳妥的做法是再写一个“评估提示词”，让模型对自己的输出按几个维度打分。

比如让模型生成营销文案后，再调用一次模型，提示词大致长这样：

你是一位严格的文案评审。以下是一条营销文案，请从吸引力、信息准确度、和用户痛点的契合度三个维度打分，每个维度满分10分，给出总分和修改建议。文案内容：{生成结果}

这样做还有一个额外的好处：模型给的修改建议，可以作为下一轮生成提示词的优化方向，形成“生成—评估—再生成”的闭环。我在做内容工厂项目时，就是靠这套自动评估机制来筛选候选文案的，效率比人工审核高出数倍。

写在最后的实操体会

我自己做提示词工程也踩了不少坑，从最初完全靠“多试几次碰运气”，到现在能结构清晰地把问题拆解成五个要素逐个调整，这个转变让我实实在在感受到了“工程化”的力量。每次被模型输出气到的时候，我都会提醒自己：不是模型糊涂，而是我的提示词没说到位。

如果你刚接触提示词工程，我的建议是别一上来就追求什么高级技巧，先老老实实把这 5 个核心要素用起来，在你最常用的场景里把每个要素都试着写一遍，再对照本文的排查表做优化。等你对这些基础操作形成了肌肉记忆，再去玩链式提示、思维链那些进阶玩法，一定要记着，最容易忽略的往往就是角色设定和输出约束这两条，但往往补上它们，效果就会立刻不一样。