企业官网建设流程全解析

1. 提示词工程到底在解决什么问题

1.1 它不是玄学话术，而是显式的上下文设计

如果你最近在玩大模型，大概率有过这种体验：同一件事，换一个说法，结果天差地别；换个时间再问，同样的说法，答案又不一样。于是很多人开始把提示词当成某种“咒语”去研究，觉得一定存在某种神奇口令，能让模型发挥全部潜力。

我做了几年大模型应用开发，可以负责任地说：提示词工程的核心不在“咒语”，而在“上下文设计”。模型本身的能力是固定的，它能利用的信息就是当前上下文窗口里的所有内容。你的提示词本质上是一套“上下文布局”：告诉模型当前任务是什么、背景是什么、约束是什么、期望输出长什么样。把这些信息布局得越清楚，模型回答的质量就越稳定。

这也是为什么优秀提示词和普通提示词之间的差距，不在于用了多少生僻词汇或神奇句式，而在于信息密度、结构层次和边界定义是否到位。一个“帮我把这段文章改通顺”的提示词，看起来没问题，但模型不知道你要改成什么风格、是否允许大幅删改、要不要保持原长度。它只能在泛泛的指令里挑一个平均值。反过来说，当你想明白这些问题并把它们写进提示词，输出自然就不一样了。

1.2 为什么说上下文工程是提示词工程的下一站

最近行业里讨论“上下文工程”的人越来越多，有人把它说成提示词工程的下一代形态。这个说法有点道理，也不全对。我的理解是：提示词工程是上下文工程的一个子集，而且是最靠近用户的那部分。

什么意思呢？上下文工程关注的不只是系统提示词怎么写，而是整个上下文中所有元素的组织方式。包括用户输入、系统指令、检索到的知识片段、工具调用结果、多轮对话历史，甚至模型自己的中间推理过程。这些元素以什么顺序进入上下文、每条占多大比例、哪些信息必须放在靠近开头或结尾的位置，都会影响模型最终输出。

举一个最典型的例子：给大模型接一个企业知识库。你单靠一段写得再漂亮的提示词，也无法让它回答出私有文档里的内容，因为模型根本没有这些信息。你得先通过检索把相关文档片段找出来，塞进上下文，再给模型下达“只基于以上资料回答”的指令。这时候，检索质量、片段长度、排序方式、上下文拼装顺序，这些看似不属于提示词的部分，反而决定了最终效果。

所以我在这篇文章里列的10个技巧，既有传统提示词玩法，也有偏上下文工程的实践。核心思路是一致的：让模型在更明确、更有限、更完整的上下文里工作。

2. 10个立刻能上手的技巧（上）：先把手头的提示词改规范

2.1 技巧1：角色锚定，但别只说“你是一个专家”

角色提示是大多数人最开始接触的技巧。给它一个角色，比如“你是一名资深律师”“你是十年经验的前端架构师”，模型输出确实会更贴合角色设定。原因是这个角色名在训练数据里关联了大量特定语料，相当于帮模型锁定了一个输出分布空间。但这只是第一步，如果你想让它真正稳定输出，只有“角色名”远远不够。

一个完整的角色锚定至少包含三个维度：角色背景、任务场景、行为约束。要说明它是谁、服务于谁、专业边界在哪；要说明它要做什么、输出给谁看；还要说明哪些行为是被禁止的。我给一个对比：

• 弱写法：你是一名数据分析师。帮我分析这份销售数据。
• 强写法：你是一名有8年零售行业经验的数据分析师，现在需要为一家电商公司的管理层制作月度销售分析报告。请基于我提供的数据，指出销售额变化的3个主要原因，并给出1条可执行的建议。不要堆砌统计术语，用管理层能听懂的语言表达。

后一种写法里，模型能判断的维度更多。它知道用户是管理层、不需要术语、要有决策建议，这些约束会直接影响它对信息粒度的取舍。角色设定不是让你编故事，而是在给模型划出“谁在什么立场上以什么标准回答”的边界。

2.2 技巧2：少样本示例，让规则长在例子里面

如果你发现无论怎么描述规则，模型总是“听懂了但做不对”，那就别再讲规则了。给它看例子。少样本提示的理论基础是上下文学习：模型在训练时就具备根据示例推断任务规律的能力。你不需要告诉它“人名要抽出来、公司名要抽出来、地名要抽出来”，直接给它三组“输入文本-期望输出”的对照，它就能学会这个模式。

但示例不是随便丢几个就行。用多了以后我总结出几个关键点：第一，示例质量比数量重要，两三个能覆盖边界情况的例子，远胜于十个模糊雷同的例子。第二，最好既有正例也有负例。拿信息抽取来说，我会在示例里专门放一条“没有目标实体”的输入，并让模型返回“无结果”。加了这一步，误报率明显下降，因为模型知道了“空就是空，不要硬填”。

第三，示例的输出格式要和你期望的最终输出格式完全一致。如果示例用JSON，它就会学着用JSON；如果示例是口语段落，它也会学着口语化。模型在示例里找规律，你得确保你给的规律就是你想让它学会的规律。

2.3 技巧3：思维链，让模型把计算过程摊开写

思维链是2022年前后火起来的方法，入门用法简单：在提示词末尾加一句“请一步一步思考”，模型就会在给出答案前输出推理过程。但真实生产环境里，有两个问题必须想清楚：一是什么任务该用，二是什么时候别用。

先说该用的。数学题、逻辑推理、代码调试这些多步骤场景，模型直接输出最终答案时，中间一步算错很难被发现；如果把推理过程显式写出来，错误更容易暴露，模型也更可能中途自我修正。但如果是简单任务，比如情感分类、格式转换、摘要总结，思维链只会拖慢响应、多烧token，甚至把一眼能看出的结论越想越偏。我见过不少开发者在简单任务上强行加“深思熟虑”，结果输出变得冗长又绕。

再说怎么防跑偏。在提示词里可以这样约束：“在给出结论前，请用不超过200字说明推理步骤，每一步都要引用题干中的数据或原文。”加了“引用原文”这个要求，模型就被迫回到原始输入，而不是凭空推断。这一步对很多幻觉问题都有抑制作用。

2.4 技巧4：结构化输出，让结果可以被程序直接消费

如果把大模型接入业务系统，最基础的门槛是输出格式。模型天生擅长自然语言，但你的系统需要的是JSON、XML、Markdown表格这类结构化数据。解决方法不复杂：在提示词里明确格式要求，并附上一个结构示例。

我日常的写法是：

请以JSON格式输出，不要包含JSON之外的任何文字。输出结构：{"result": [{"name": "实体名称", "type": "实体类型，可选值为PERSON、ORG、LOCATION"}]}。如果未识别到任何实体，返回{"result": []}。

这里有个容易忽略的坑：模型可能会在JSON前后加上“好的，结果如下”这类话，导致解析失败。除了在提示词里强调“不要包含其他任何文字”，更稳的办法是在程序解析端做兼容，把输出中第一对花括号之间的内容截取出来再解析。提示词能降低问题概率，但工程上永远要留一道兜底。

另一个经验是：越复杂的JSON结构，模型越容易在字符串里混入未转义的引号或换行。能扁平的JSON就尽量扁平，不要用太深的嵌套。如果必须嵌套，给一个完整的示例比写一堆字段说明更有用。

2.5 技巧5：反问澄清，信息不足时让模型先提问

很多人抱怨“模型总是在编”，其实有时候是任务本身给的信息不完整，模型只能靠猜。与其让它猜，不如在提示词里明确授权它反问。

模板写法：

我的需求是：为我的新产品做一份市场推广方案。如果你认为我提供的信息不足以给出高质量方案，请先向我提出不超过3个关键问题，我会逐个答复。如果信息充足，则直接生成方案。

这里的关键是把“质量优先”放在“速度优先”前面。模型不是客服，你授权它提问，它就会在关键信息缺位时主动拦截，而不是生成一份看似完整、实际全是空话的方案。我遇到过好几次内部需求，想用大模型做竞品分析，但连竞品对象、目标用户都没说清。不加反问机制时，模型把所有知名品牌都评论一遍，看着好像全面，其实完全没有可用性。加了反问环节，用户被迫先想清楚边界，后续生成的方案质量立刻不一样。

3. 10个立刻能上手的技巧（下）：进阶玩法与组合技

3.1 技巧6：自我检查，让模型再挑一遍自己的毛病

一个容易被忽视的进阶玩法是自我修正。模型第一遍生成的内容，只要约束不够严格，多多少少会有瑕疵。与其额外调用一次模型专门做“审查”，不如在同一个提示词里设置两阶段任务。

写法示例：

第一步：根据我的要求生成一篇关于远程办公效率的文章，800字左右。第二步：逐条检查你生成的这篇文章，重点检查事实准确性、逻辑连贯性、是否包含没有依据的具体数字或案例。如果发现问题，重写一遍，并说明修改了哪里。

加了第二步之后，输出质量提升是肉眼可见的。原因在于模型第一遍生成时倾向于选择最流畅的词汇和句式，而进入检查阶段后会切换成一种更挑剔的视角，一些第一遍时容易出现的“幻觉细节”会被它自己揪出来。

需要注意，自我检查不适合所有场景。同一段内容要生成两遍，token消耗和响应时间都会增加。如果目标是几百字的短回复，丢在同一个提示词里没问题；如果是上千字的长文，我更建议拆成两次独立调用，第一次生成，第二次只审查和修改，这样每一步的上下文更干净。

3.2 技巧7：拆解任务，让模型先出大纲再写全文

大模型在长文本生成上有个通病：开头高能、结尾烂尾；或者开头持A观点，结尾悄悄偏向B观点。最典型的是让它一次性输出1500字以上，中后段经常出现重复表达、逻辑跳跃。解决思路是为任务设置“中间产物”，把一个大任务切成若干个小步骤。

拿写长文举例，可以让模型先输出文章大纲，你确认后再逐段扩展。提示词可以这样写：

请先为“智能家居安全设计”这个话题写一份文章大纲，包含5个章节，每章给出3个关键点。大纲确认后，再逐章撰写正文，每章约400字。全部完成后，按章节顺序拼接为完整文章。

这个做法本质上是任务分解。一段上下文里只聚焦一个章节时，模型需要同时管理的信息量大幅减少，前后一致性自然更好。虽然交互成本高了一点，但换来的是结构稳定的长文。做API接入时，你还要自己处理多轮调用的上下文拼接，建议把已经确认的大纲一直保留在后续每轮的上下文中，防止模型写后半部分时忘记框架。

3.3 技巧8：多候选生成与自洽性选择

大模型的输出带有随机性，同一个提示词跑两次，结果会有差异。很多人把随机性当成麻烦，换个思路它也能变成工具：让模型一次生成多个候选，然后从中选最优。学术上管这个叫自洽性，说白了就是“多准备几个答案，再挑好的”。

在网页对话界面里，可以这样让模型在同一回复中给出多个版本：

请给出3个不同方向的方案，每个方向要有明显差异，不要只是换几个同义词。随后从这3个方案中选出最符合以下标准的一个：信息准确、结构简洁、可落地执行，并说明你的选择理由。

在API环境下，更常见的做法是多次调用同一提示词，把temperature调到0.7以上，让每次生成有更多变化，再用程序对这些结果做汇总评分。评分可以用规则，比如是否包含关键字段、长度是否符合要求；也可以再用模型当裁判。

这个技巧适合创意方案、文案标题、产品命名这类多样性优先的任务。事实型问答和代码生成不建议这么做——代码多跑几次再让模型选，反而可能把本来正确的那份改成错的，因为它在“评分”时也会引入新的臆测。

3.4 技巧9：上下文工程的核心——把背景知识放进提示词

这里要谈的其实是整体视野上的做法：不要把模型默认成什么都知道，主动把背景资料、业务约束、示例文档放进提示词。模型内部的知识是静态的，存在信息截止日期，而且不包含你业务中的私有内容。但它的上下文窗口足够大，可以临时接纳你给的新材料。

简单落地方式包括：让它总结一段日志，就把日志原文贴进去；你们公司有内部命名规范，就把规范写成一个简短的段落放在任务描述前面；做知识库问答就先用检索把相关片段捞出来，再拼进提示词里。

顺序方面有一条经验：把背景信息放在提示词最前面，任务指令放中间，输出格式要求放最后。原因是模型对上下文不同位置的注意力权重有差异，开头和结尾的信息更容易被强化。重要背景放开头，能在生成后续内容时持续形成约束；输出格式放最后，等于在收尾阶段给它一个明确的“着陆点”。这一条看起来不起眼，实际改完效果经常有明显变化。

3.5 技巧10：把提示词当代码来维护，做版本和评测

最后一个技巧更像工程习惯。提示词早期可以靠灵感，但一旦进入生产环境，就必须当代码管起来。需要有版本号、变更记录和回归测试。

具体操作分三步。第一，给每一类提示词建独立文档，记录初始版本、修改时间、修改原因、实测效果。第二，准备一个小规模评估集，比如20条真实业务输入，每次修改提示词后都用同一批输入去测试，观察输出是变好还是变差，而不是凭感觉说“好像好点”。第三，如果一个提示词的某个片段被多个场景复用，就把易变部分和固定部分拆成变量，比如用占位符表示任务描述、背景资料，固定部分单独维护。

我实践下来的体会是：没有评估集的提示词优化，基本等于裸奔。你调整了几版风格，如果不跑同一批测试输入做对比，根本分不清效果提升来自新写法，还是来自模型这次随机生成的运气。一份20条的测试集不用很重，但能帮你少走很多弯路。

4. 可直接抄作业的模板库（建议复制后按需修改）

4.1 通用任务模板：角色+背景+任务+约束+输出格式

这个模板适合大部分文本处理任务，要点是把五类信息全部写清楚，缺一类都可能影响最终效果。

【角色】 你是一名具有5年经验的{领域}专家，服务于{目标受众/使用方}。 【背景】 {说明当前情况、为什么需要这个任务、这个任务的使用场景} 【任务】 请完成以下任务：{明确描述要做的事} 【约束】 - 不要{列出禁止事项} - 必须{列出强制要求} 【输出格式】 {描述期望的输出结构，最好给出示例}

这个模板看着简单，但每个字段都在回答模型一个问题：角色解决“以什么身份说话”，背景解决“为什么做这件事”，任务解决“到底要做什么”，约束解决“哪些不能做”，输出格式解决“结果长什么样”。五个问题都回答了，模型的输出空间就被压缩到一个很小的范围内。

4.2 RAG/资料问答模板：让模型只基于给定资料回答

做知识库问答时最怕一件事：模型脱离你给的资料自由发挥。想让模型“只基于资料回答”，不能只靠一句“请根据以下资料回答”，还需要明确告诉它遇到未知内容怎么处理。

你是一名企业知识库助手。以下是用户问题和相关资料片段。 【资料片段】 {检索到的文档内容，用分页符或其他标记分隔} 【用户问题】 {用户的问题} 【回答要求】 1. 只基于以上资料片段回答，不要引用资料以外的信息。 2. 如果资料中未包含答案，请明确回答“资料中未找到相关信息”，不要自行推断。 3. 回答末尾用[1][2]标注引用来源，对应资料片段的编号。 4. 用简洁的要点形式输出，控制在200字以内。

这里第2条和第3条是最关键的。第2条给了模型一个“承认不知道”的出口，明显减少编造；第3条把回答和证据绑定，便于用户复核。在实际业务里，如果发现答案经常出现资料里没有的细节，优先检查检索环节是否把最相关内容漏掉了，而不是一味改提示词。

4.3 信息抽取模板：实体识别与结构化输出

信息抽取类任务对输出格式要求最严格，建议把格式示例直接写进提示词，同时准备好负例。

你是一名信息抽取引擎。从用户提供的文本中抽取指定类型的信息，并以JSON返回。 【抽取目标】 - 人名（PERSON） - 公司名（ORG） - 产品名（PRODUCT） 【输出格式】 {"result": [{"name": "实体文本", "type": "实体类型"}]} 【规则】 1. 只抽取文本中明确出现的实体，不要根据常识推断。 2. 如果一个实体被多次提到，只保留一次。 3. 如果没有识别到任何目标实体，返回 {"result": []}。 【示例】 文本：华为在昨天发布了Mate 70系列手机。 输出：{"result": [{"name": "华为", "type": "ORG"}, {"name": "Mate 70系列", "type": "PRODUCT"}]} 【待抽取文本】 {在此处输入文本}

如果你一次性需要抽取的实体类型很多，建议分多次抽取，每次只抽一两类。类型越多，模型串场的概率越大。另外，如果文本里大量出现“公司名和人名相同”的情况，可以把“结合上下文上下文判断”写进规则，同时期待它在较长的上下文信息中自行作出更准确的判断。

4.4 代码相关模板：生成、审查、改错三类常用场景

代码类任务和文本类任务差别很大，代码对正确性要求高，容错率低。我用得最多的是三个模板：生成、审查、改错。先看代码审查模板：

你是一名资深的{语言}开发工程师，请审查以下代码，找出潜在问题。 【代码】 {此处粘贴代码} 【审查重点】 1. 是否存在边界条件处理缺失 2. 是否存在内存泄漏或资源未释放问题 3. 错误处理是否合理 4. 代码风格是否清晰可维护 【输出格式】 按以下格式输出： - 问题描述：... - 风险等级：高/中/低 - 修改建议：...

代码生成模板更强调约束条件。写代码前一定要让模型先给出实现思路，再写代码，避免它直接甩出一段看着对但逻辑有误的实现。提示词里加一句“先简要说明你的实现思路，再输出代码”能显著提高代码与需求的匹配度。改错场景则一定要附上报错信息原文、运行环境版本、出错的输入样例，这三个信息缺哪个都容易让模型陷入猜测。

4.5 内容创作模板：文章、营销文案与多版本生成

内容创作类模板是最不需要“死板”的，但它需要一个清晰的创作简报。很多内容看起来空洞，是因为模型没拿到具体的选题角度、目标读者、字数范围和风格偏好。

你是一名{平台}内容作者。请创作一篇关于{主题}的文章。 【读者画像】 {目标读者的身份、认知水平、阅读场景} 【文章目标】 {读者读完后应该知道什么、能做什么} 【风格要求】 {口语化/专业/幽默/严谨...} 【结构建议】 {如果有明确结构要求就写，没有就让模型自己定} 【其他要求】 - 字数：{范围} - 开头需要{具体钩子} - 避免{哪些表达或内容}

营销文案则适合用多版本生成。一次生成5个标题或3个slogan，再让模型说明每个版本对应的场景和理由。这个方法比一次只给一个结果要高效得多，因为文案好坏本身有很强的主观性，多版本能给决策留出比较空间。

5. 高频问题与排查思路

5.1 模型不遵守格式约束怎么办

这是接入业务系统时最常遇到的问题。你明确说了“以JSON输出”，它还是给你带解释文字。我通常按以下顺序排查：第一，检查提示词里有没有给格式示例。只描述格式结构，模型理解起来还是抽象；给一段具体示例，它才能照着样子走。第二，检查提示词里是否出现自相矛盾的表述，比如前面允许它“详细说明”，后面又要求“只输出JSON”。第三，检查解析端是否过于脆弱，能不能支持剥离前后缀的兼容逻辑。

格式问题很多时候不全是模型的锅。模型在生成时会被上下文中重复出现的模式影响，如果你的示例写得足够密集、结构足够一致，它照着做的概率会高很多。如果试了很多次还是不定，还可以考虑用更小的输出约束工具。至于是什么，这里不多扩展，你只需要知道，纯提示词不是唯一解法。

5.2 加了思维链效果反而变差

之前提过，思维链不是万能的。如果发现加了“请一步步思考”效果反而变差，先检查任务类型。简单分类任务、格式转换任务本来就不需要复杂推理，模型被“要求思考”后反而会增加额外步骤，在这些步骤里它的错误率会上升。

另一个常见原因是思维链的推理过程太长，导致模型在长步骤中逐渐偏离原始问题。解决办法是限制推理长度，并要求每一步引用原始输入信息。比如写成“请用不超过3步得出结论，每一步都要说明依据”，就能把推理控制在较短链路里。

另外，如果模型在推理过程中输出了错误的前提，后续再怎么推也是错的。这时候与其让它一口气推到底，不如把推理过程拆成几步，每步单独和原始输入比对。部分场景下，也可以先让模型复述一遍题目中的关键信息，再让它推理，瞎推断的情况会少很多。

5.3 上下文太长导致关键信息被忽略

很多人以为给的信息越多越好，实际上模型对上下文的注意力是有限的。当上下文超过一定长度后，中间部分的信息容易被忽略或者被错误理解，俗称“迷失在中间”。如果你的提示词很长，但需要的核心指令或关键数据放在长文中间，模型很可能看不到。

解决办法有几个：把最关键的信息放在提示词开头或结尾；把不重要的大段资料挪到提示词末尾附近，用分隔符明确标注“以下是参考资料”；或者精简上下文，只保留与当前回答最相关的部分，而不是一股脑全塞进去。在RAG场景里，缩短检索片段、提炼摘要，比把大原文端给模型更有效。

5.4 模板不生效：最容易被忽略的变量

用了模板还是没效果，先不要怀疑模板本身。我遇到过几次“同一套模板在A场景表现很好，在B场景完全失效”的情况，最后排查下来都是变量没改对。最常见的问题是模板里用方括号占位符，但填写时把原方括号也一起删了；或者背景资料切换后，任务指令还沿用上一场景的描述，导致逻辑冲突。

还有个容易被忽略的点：同一个模板在不同模型上表现差异会很大。有些模型对指令的理解能力强，有些模型对格式的遵从能力弱。换模型后，如果发现输出风格明显变化，优先检查是不是模型本身的指令遵循能力差异导致的，而不是反复调模板。

6. 一点个人实操心得

做了这么多轮提示词优化之后，我最大的体会是：提示词工程表面上是写文字，本质上是在设计信息结构。你写的每一句话都在参与塑造模型的“上下文工作区”，与其纠结某个词用得好不好，不如先想清楚这个任务里哪些信息是不可或缺的、哪些约束不能放松、哪些反馈能帮助模型自我修正。

提到上下文工程，我的态度是：它不是一个需要单独学习的知识体系，而是提示词工程的延伸。当你开始关心信息放哪里、上下文怎么组装、历史记录要不要压缩、检索结果如何排序，其实已经在做上下文工程了。行业下一个阶段的竞争点，也会从“谁提示词写得好”转向“谁能把整个上下文链路设计得更高效”。

最后分享一个小技巧：每次改提示词之前，把当前版本和上一版本的输出放在一起对比。如果拿不准哪个好，可以开一个全新的会话语境，把两版提示词各跑一遍，再分别针对结果追问一轮。比起反复在同一个对话里修改，这种方法更能避免上下文污染带来的误判。