企业官网建设流程全解析

很多人第一次接触大模型的时候，都会有这么一个困惑：明明AI看起来什么都知道，但让它干点具体的活，它就开始“自由发挥”了。你问它“帮我写个文案”，它给你写一篇散文；你让它“总结一下这份文档”，它给你复述了一遍原文。问题出在哪？大多数时候不是模型不够聪明，而是你没把话说清楚。

这篇是“AI Agent 学习之路”系列的第二篇，主题锁定在提示词与提示工程。这个系列面向的读者，是那些已经对AI Agent有概念、想动手搭建但还没完全上手的开发者，以及那些每天都在用ChatGPT、Claude、通义千问这类产品，但总觉得“差点意思”的重度使用者。这篇内容会解决一个核心问题：怎么让大模型真正听懂你要什么，并且稳定地按你的要求输出结果。

先不扯太高深的理论。提示词工程（Prompt Engineering）本质上就是一套和AI沟通的方法论。你写提示词，就是在给一个极其聪明但极度依赖指令的“实习生”布置任务。你交代不清楚，他就只能靠猜；你交代清楚了，他就能超水平发挥。而到了AI Agent这个层面，提示词更是从“写一次性的提问”变成了“写一套持久化的工作说明书”，这也是Prompt Engineering和Agent开发之间最关键的衔接点。

我自己是从一个很笨的路径走过来的——先是靠感觉写提示词，被各种莫名其妙的结果折磨到崩溃，然后才开始系统地把提示词拆解成可复用的结构，最后才摸到一点门道。这篇就算是我把那些碎片化经验重新整理出来的版本，希望能帮你少走一点弯路。

1. 先破一个观念：提示词不是“咒语”，是“需求说明书”

很多人把提示词工程说得特别玄，好像有什么神秘配方，抄几个模板就能让AI“觉醒”。实际不是这样。你仔细观察大模型的工作方式就会发现，它做的事情是“预测下一个词”。它不看懂你的意思，它只是根据你给的一堆文字，算出最合理的后续文字是什么。

这就像一个特别会接话的朋友。你只说了半句话，他就能接着往下唠，但唠的方向完全取决于你给的信息量和上下文。如果你给他的是一个模糊的指令，他只能给你一个模糊的、基于统计概率的回复。反过来，如果你给他足够清晰的任务描述、背景信息、输出格式、参考示例，他就能在大概率上产出一个符合你预期的结果。

所以提示词工程的核心，从来就不是“想办法骗过模型”，而是“把自己的需求精确翻译给模型听”。这个翻译能力是可以被拆解、被训练的。我常用的一个类比是：写提示词和写需求文档是一回事。你写需求文档的时候会写清楚背景、目标、范围、输入输出格式、验收标准。好提示词也是这样。它不靠运气，靠结构。

这一节我只想先把观念扭过来。后面谈的所有框架、技巧、示例，都是建立在这个理解之上的——提示词不是聊天，是工程。

1.1 大模型的“听话”机制：它到底怎么理解你的话

我们先把大模型的处理逻辑简化一下。以Transformer为基础架构的大模型，在处理文本时会把输入的内容拆成Token，然后计算这些Token之间的关联权重，再根据这些权重去预测下一个最可能出现的Token。这个预测过程是逐字逐字往后推的，所以理论上，你输入的每一个字都在影响模型的输出走向。

这带来一个很实用的结论：给模型的“前置输入”越长、结构越清晰、包含的有效约束越多，模型在推理时能“参考”的信息就越充分，输出质量就越稳定。

我经常用一个例子去解释这件事。你让一个程序员写一个函数，只丢给他一句话：“写个函数处理一下数据。”他大概率会懵，因为他不知道数据是什么格式、要处理成什么样子、用什么语言写、性能有没有要求。但如果你告诉他：用Python写一个函数，接收一个CSV文件路径，读取里面的销售额字段，按月份汇总，返回一个列表，列表元素是（月份，总额）这样的元组，他会非常明确地知道该做什么。

大模型和程序员不一样的地方在于，它没有“常识性的自省能力”。它不会主动问你“数据长什么样”，它只会根据你的描述去推。你把条件写足了，它就能给你精确的结果；你写不足，它就用训练数据里出现概率最高的模式去补全。这就是为什么同一个模型，有人用起来像专家，有人用起来像智障。

1.2 提示词工程能解决什么问题，哪些问题它根本解决不了

把提示词工程当成万能药，是很多人第二个观念误区。它能解决的是“指令表达不清晰”“上下文不完整”“输出格式不受控”“角色定位不明确”这类问题。换句话说，模型本来就能干这件事，只是你没说清楚，它没干对。提示词工程在这里的作用，是把模型的已有能力精确“激发”出来。

但它解决不了模型本身能力不足的问题。比如你让一个只接受了中文预训练的模型去精确翻译冷门小语种，无论你把提示词写得多精致，结果都不会太好。再比如你让模型做复杂的数学推理，如果模型本身推理能力就是短板，提示词只能在一定程度上通过引导步骤来缓解，但突破不了它的能力上限。

这很像你在职场上给下属布置任务。提示词是沟通方式，下属的能力天花板是另一码事。一个好的管理者可以通过清晰的沟通让普通下属交付合格结果，但你不能指望沟通解决所有问题。模型的能力边界、上下文窗口限制、幻觉倾向，这些是提示词工程的天花板，也是为什么后续要引入RAG（检索增强生成）、微调、Agent工具调用这些手段的原因。

2. 提示词的基础结构：一个能稳定复用的四段式框架

我早期写提示词完全是野路子，想到哪写到哪。效果时好时坏，坏的时候居多。后来复盘才发现，写得好的那些提示词，底层结构都差不多，无非是“角色、任务、背景、格式”这四大块在排列组合。

再往后我干脆把这四块固定成模板，每次写提示词都往里面填内容。效果非常稳定，而且思路也快了很多。这里把这个四段式框架分享出来，你后面写任何提示词都可以拿它当骨架。

先说这四个部分各自解决什么问题，再给一个能直接用的示例模板。

2.1 角色设定：告诉模型“你是谁”

“你现在是一位有十年经验的资深数据分析师”这句话看着简单，但背后是有实际意义的。大模型在训练过程中见过大量带有角色前缀的对话数据，当你给模型指派角色时，等于在它的“记忆库”里激活了一类和该角色相关的回答模式。数据分析师角色的回答会更注重逻辑、细分维度、指标定义，而“营销文案专家”角色的回答会更注重情绪调动、场景化描写、利益点提炼。

角色的本质作用，是把模型的输出分布往你期待的方向“偏移”一下。你不设定角色，模型就会用一个平均化的、样样通样样松的口吻回答你。你设定了角色，模型就会像一个特定岗位的人那样去思考和组织语言。

角色设定也不是越多越好。我见过有人把角色设定写成一篇小作文，给模型安了五六个头衔，什么“既是营销专家又是心理学大师还是数据分析师还是文案写手”。这种情况模型往往表现得很差，因为角色越混杂，输出风格越不稳定。一个清晰单一的角色，远好过一堆角色的缝合。

2.2 任务描述：用动词开头，说清楚要做什么

任务描述是提示词里最核心的骨架。一句话能说清楚的坚决不用三句话。这里有一个特别实用的技巧：任务描述要用动词开头。

对比一下两组说法：

• 差：“我想让你帮我看看这个问卷数据，分析一下用户反馈，看看有什么问题，然后给我一个结果。”
• 好：“对以下问卷数据按负面反馈率从高到低排序，提取高频出现的问题关键词，输出一个问题清单。”

第一组描述的问题在哪里？指令模糊。模型不知道“分析一下”具体指什么，“一个结果”又是什么样子的。第二组描述把任务拆成了“排序、提取关键词、输出问题清单”三个明确的动作，模型在每一步都能直接执行，不需要猜。

这里还有一个容易被忽略的地方：任务的复杂度决定了你要不要拆步骤。如果是多步骤任务，建议在提示词里明确写出先后顺序，或者让模型按照编号逐步执行。比如“第一步先提取数据，第二步做统计，第三步输出结论”，这种顺序性指令能显著减少模型跳步、漏步的情况。

2.3 上下文与约束条件：给足决策依据

上下文解决的是“模型不知道你说的是哪件事”的问题。比如你说“分析一下这个数据”，如果不附带数据或者数据的来源说明，模型完全不知道“这个数据”指的是什么。

在实际开发Agent的时候，上下文一般来自三个方面：

• 对话历史中用户提供的信息
• 外部系统查询回来的数据（通过工具调用）
• 知识库检索回来的文档片段

把一个具体场景串起来就是：用户说“帮我看看北京分公司上个月的销售情况”，Agent先去工具里把北京分公司的销售数据抓回来，然后把“销售数据原文”注入到提示词的上下文区域，再让模型基于这份数据做分析。没有数据注入，模型就只能凭训练时的先验知识瞎编，编出来的东西大概率不靠谱。

约束条件更偏向限制模型的行为边界。用一个简单说法就是“能做什么、不能做什么、做到什么程度”。比如“不要编造数据，只基于提供的资料回答”“字数控制在800字以内”“如果信息不足直接说不清楚，不要猜测”。这些约束本质上是给模型划定一个表达的范围，降低幻觉和失控的概率。

2.4 输出格式：锁定结果结构

输出格式是我认为四个模块里最容易被新手忽略、但对Agent开发最致命的一环。因为Agent拿到的模型输出，很多时候不是给人看的，而是要给程序解析的。如果模型输出的格式不规范，轻则解析报错，重则整个自动化流程直接断掉。

输出格式这块有三个层次的要求：

• 第一层：限定内容结构。比如“输出用Markdown格式，包含背景、分析、结论三段”“输出用JSON格式，字段包含name、type、price”。
• 第二层：限定长度范围。比如“回复控制在200字以内”“每一条要点不超过50个字”。
• 第三层：限定表达风格。比如“用口语化的方式解释，避免专业术语”“用冷静客观的口吻描述，不做主观评价”。

这三个层次可以根据场景需要自由组合。在Agent场景里我最常用的是限定JSON格式输出，后面第三节会给一个完整的示例。

四段式框架其实说白了就是：告诉模型你是谁（角色）、要做什么（任务）、基于什么做（上下文）、做成什么样（格式）。这四件事说清楚了，提示词的质量就已经超过80%的人了。

3. 从“能懂”到“懂得好”：三种实用的进阶技巧

框架能解决“模型听懂你的话”的问题，但距离“模型高质量完成你的任务”，中间还隔着一段路。这段路需要靠一些进阶技巧来补齐。

我按实用性排序，选了三个最常用的：示例驱动（Few-shot）、思维链（Chain-of-Thought）、角色扮演进阶玩法。这三个和Agent开发的关系最紧密，也最容易在实践里体会到效果上的差距。

3.1 示例驱动：一个例子胜过十句解释

Example是提示词工程里被严重低估的手段。人类的沟通里“举个栗子”是很高效的说明方式，对模型也同样有效。模型在训练时见过大量“输入-输出配对”的数据，当你在提示词里给出示例时，模型会自动模仿示例的格式和风格来生成输出。

举一个实战中的例子。假设你要模型从招聘信息里提取“职位名称、薪资范围、学历要求”三个字段。如果只是口头描述：“提取一下这个岗位的薪资、学历信息和职位名”，模型给出来的结果往往结构五花八门。但如果给出一个示例：

输入：招聘岗位：前端开发工程师，薪资15-25K，本科及以上学历，3年以上经验 输出：{"职位名称":"前端开发工程师","薪资范围":"15-25K","学历要求":"本科及以上"}

再让模型对下一条招聘信息做同样的处理，它的输出格式就会稳定得多。这其实就是Few-shot的基本用法，一个示例不够就多给两三个，模型就“懂规矩”了。

Few-shot的威力在Agent开发中尤其明显。因为Agent经常要和外部工具对接，工具的输入输出格式是有规格的，模型输出的格式一旦不符，整个链路就断了。用两三个高质量示例把格式“钉死”，比在提示词里反复强调“一定要输出JSON”有效得多。

3.2 思维链：让模型把推理过程走完

思维链（Chain-of-Thought）这个技巧，最早是被观察到一个现象启发的：你让大模型直接做一道复杂的数学题，它经常算错；但如果你要求它“一步步思考”或者给它一个中间推导的示例，它的正确率会显著提升。

原因也不难理解。模型的推理是逐Token生成的，如果不加任何引导，它在推理过程里的“中间步骤”会被跳过或压缩，直接跳到结果。而“一步步思考”这个指令，强制模型把中间步骤展开，每一步都建立在之前步骤的基础上，推理就变得更可靠了。

实际操作中我的惯用手法是：“请一步步分析，先列出已知条件，再推导，最后给出结论，结论用一句话总结。”这一个简单的描述，就能让很多复杂任务的完成质量上一个台阶。

思维链在Agent场景里还有一招变体用法：叫“Plan-then-Execute”。也就是先让模型把任务拆解成一个计划（Plan），再去逐步执行（Execute）。拆计划的过程和思维链有异曲同工之妙，都是把隐含的推理展开为显式的步骤。你在搭Agent的时候，经常会看到“把任务分成几步”这类提示词，底层的逻辑就在这里。

3.3 从Passive到Active：给模型定“主动性边界”

这里说的不是让模型“越权”去自作主张，恰恰相反——是让模型明确知道自己什么时候该主动，什么时候该停下来问。

在写单轮问答的提示词时，你不需要管主动性边界，因为模型只需要回答一次。但当你在开发Agent时，模型是要在多个步骤里做决策的。它可能收到了一个用户的指令，而这个指令执行到一半发现信息不足，这时候模型应该怎么办？继续蒙着头往下做，还是停下来向用户确认？

这个边界需要在提示词里显式定义。比如这样写：“如果在执行过程中发现用户提供的资料不足以完成任务，直接列出缺少的信息，请用户提供，不要自行假设。”

我见过不少Agent项目翻车，翻车的原因不是模型不会干活，而是模型在不该发挥的时候“发挥”了。它发现资料不够，自己补了一段编造的数据进去，结果误导了整个下游流程。定清主动性边界，就是为了防止这类事情发生。

4. AI Agent场景下的提示词实战：从单轮到多轮系统

前面讲的内容，其实都可以用在单轮对话里。但AI Agent和普通ChatBot最大的区别在于：Agent不是“一次对话一次输出”，而是“一个目标多轮推理多工具调用”。提示词在这个过程中扮演的角色，要比单轮对话复杂得多。

我一开始搭Agent的时候，总想着把提示词写得“事无巨细”，长篇大论塞进去。后来实践发现，提示词太长反而会稀释模型的注意力。系统提示词应该是“稳定”且“精炼”的，不该把每轮对话的上下文都塞进去。这中间有一个分离的概念要理解清楚。

4.1 系统提示词和应用提示词的分层

一个Agent的提示词体系，我不建议一股脑堆在同一个提示词里。更合理的做法是把提示词分成“系统提示词”和“应用提示词”两层。

系统提示词（System Prompt）定义Agent的“人设、职责、边界、工作流程”。它在整个会话周期里保持不变。比如一个“客服Agent”的系统提示词可以这样写：

你是一位电商平台的客服助手，负责解答用户关于订单、物流、退换货的问题。你的工作流程是：先判断用户问题类型，再查找订单信息，最后给出答复。如果用户问题超出客服范围，请引导用户联系人工客服。答复必须保持礼貌简洁，单次答复不超过200字。不要编造订单数据，所有订单信息都从订单查询工具中获取。

应用提示词（User Prompt / 用户消息）则负责每一轮对话里具体的目标。用户说了什么，工具返回了什么，这些动态信息才放进应用提示词里。

为什么要做这个分层？因为模型是有注意力机制的，上下文越长，模型对关键信息的注意力就越分散。如果把“Agent身份说明”“工具使用规范”“用户当前问题”“工具返回数据”等等全部混在一个提示词里，模型很可能越往后越“犯迷糊”。分层以后，稳定信息和动态信息互不干扰，模型的行为会更可预期，调起来也更好定位问题。

4.2 工具调用的提示词设计：让模型学会用“手”

Agent区别于普通聊天的本质，在于它会调用工具。不管是查数据库、调API、发HTTP请求还是执行代码，Agent拿到外部工具返回的数据之后，都要组织成语言回复给用户。而这一整段行为的“说明书”，就是提示词。

工具调用部分的提示词设计，有一个非常基础也很容易踩坑的点：工具返回的原始数据格式很“机器化”，但模型的用户答复必须“人话化”。

举个例子。你让Agent查一个订单的物流信息，工具返回的数据是长这样的：

{"order_id":"A12345","status":"delivered","last_location":"上海分拨中心","update_time":"2025-06-01 14:30"}

如果模型直接把这个JSON原封不动地丢给用户，那就很蠢。你需要在提示词里说明：“基于工具返回的数据，用自然语言组织一段用户可读的回复。回复中必须包含订单状态和当前物流位置，不需要提及原始数据格式。”

工具调用的提示词里还有一条铁律：告诉模型只在需要的时候调用工具，不需要的时候不要乱调。如果不加这条限制，模型可能对每个提问都走一遍工具流程，既浪费Token又增加了延迟。更烦人的是，某些工具的调用有副作用，乱调可能产生脏数据。

4.3 上下文工程：Agent对话轮次里的提示词拼接方式

“大模型提示词工程与上下文工程”这个话题今年讨论度很高，因为单纯的提示词技巧只解决了“单轮指令表达”的问题，而Agent是典型的多轮场景。每一轮对话都涉及历史信息、工具结果、用户当前输入的重新拼接。这套拼接的规则，被越来越多的人单独拎出来叫“上下文工程”。

上下文工程的核心关注点是：每一轮放到模型输入窗口里的内容，哪些该留，哪些该丢，以什么顺序排。

一个通用顺序是这样的：

• 系统提示词（固定）
• 对话历史（按时间倒序或者正序截取，通常保留最近几轮）
• 本轮用户输入
• 本轮工具返回结果（如果有）

实操中很容易犯的错误是把工具返回的一大段数据无脑全部塞进下一轮对话。工具返回数据动辄几千Token，如果每次都全量保留，几轮下来上下文就爆了，还会干扰模型对后续指令的判断。所以上下文工程里有个重要动作：对工具返回结果做摘要后再回填。

我在实战中的习惯是，工具返回的数据先经过一轮“压缩”，提取出本层任务需要的关键字段，再放回上下文里。这样一个Agent即使跑几十轮，上下文也能保持在可控范围内。

4.4 一个可复制的客服Agent提示词完整示例

理论讲再多，不如放一个能直接跑的示例。这里分享一个我实际在项目里用过、效果稳定的客服Agent提示词结构，你拿到手以后可以按自己的业务改。

SYSTEM_PROMPT = """ 你是一个名为“小安”的电商平台客服Agent，负责帮助用户解决订单查询、物流跟踪、退换货申请等问题。 ## 工作流程 1. 首先要判断用户问题的类型，可能类型包括：订单查询、物流查询、退换货、其他。 2. 根据问题类型，调用对应工具获取信息。 3. 拿到工具返回结果后，组织一段清晰自然的答复。 4. 如果工具没有返回有效数据，如实告知用户“暂时未查到相关信息”，严禁编造。 ## 可用工具 - get_order_info(order_id): 查询订单详情 - get_logistics_info(order_id): 查询物流轨迹 - apply_refund(order_id, reason): 提交退款申请 ## 回答要求 - 每条答复不超过150字 - 语气礼貌、口语化、简洁 - 涉及订单状态时，必须引用工具返回的真实状态字段，不得自行推断 ## 边界行为 - 如果用户问题与电商平台业务无关，友好告知“这个问题我暂时无法处理，建议联系人工客服” - 不要在信息不全时自行假设，缺什么信息就向用户问什么 """

这个提示词本身没什么魔法，但它把“身份”“流程”“工具”“边界”四件事完整地定义清楚了。模型的稳定性就会比不写系统提示词高很多。你在实际业务里做替换时，最重要的原则就一条：你能多精确地描述流程，模型就能多精确地执行流程。

5. 问题排查与避坑实录：AI Agent提示词翻车现场盘点

写提示词这件事，不管你理论学得多好，实操中该踩的坑一个都躲不掉。下面整理的是我踩过、以及在社区里高频看到的一些问题，每一条都配了现象、原因和解决办法。

5.1 模型回复“泛泛而谈”怎么办

现象：问什么答什么，但答得都很虚，没有具体内容，感觉像在念科普。

原因：大多数情况是因为提示词里的“任务描述”写得太抽象了。模型不知道你要什么粒度的信息，只能给一个通用级别的回答。

解法：把任务“具象化”。给两个示例来对比。

推荐你用一个技巧：把“泛泛描述”改成“加上具体角度的描述”。比如你把“分析一下市场情况”改成“只分析华东地区的竞品定价情况，重点关注三家头部品牌的定价波动，结合最近一次促销活动，输出一个降价原因分析”。模型拿到这种偏具体的任务指令，输出就不会飘了。

5.2 模型开始“自以为是地编数据”

现象：用户买了个产品想查物流，Agent找不到，却在回复里编了一条“预计明天送达”。

原因：提示词里没有加“不编造数据”的边界约束，模型在信息缺失时默认用“自回归式的补全”来应对。

解法：在提示词里显式加上约束：“所有事实性信息必须来自工具返回结果。如果工具返回为空或查询不到数据，直接告知用户‘暂时未查询到该订单信息’，禁止根据上下文猜测或杜撰。”

这条我用血泪教训换来的，建议所有Agent开发者在系统提示词里都加一句。

5.3 工具返回的数据被模型“扭曲”了

现象：工具返回明明是一个JSON，里面status是“pending”，但模型在回复给用户时却说“您的包裹已经发出”。

原因：模型把工具返回的字段当成了推理素材，而不是事实依据。它可能结合了用户的上下文，做了“合理化推断”。

解法：在提示词里规定“状态描述必须和字段值保持一致，如需推断请注明‘根据当前状态推测’”。同时，工具返回结果注入提示词时，可以加上一句前缀：“以下内容是通过工具查询获得的真实数据，你的所有回答必须严格基于这些数据，不得在此基础上修改数据含义。”

5.4 多轮对话后Agent开始“失忆”

现象：刚开始对话还好好的，聊到第十轮，Agent把最开始用户提到的信息忘了，开始重复提问。

原因：上下文管理策略没有做好。对话历史超过一定长度后，早期的信息被截断丢了，或者模型注意力被后续大量信息稀释。

解法：不要无脑把全部历史丢给模型。做一个简单的“关键信息提取”步骤，把每一轮对话里的关键实体和结论提取出来，单独维护一个“会话要点列表”，放进每一轮的上下文里。

6. 写在最后：提示词能力的上限和下限

聊到这儿，一个很现实的问题就浮现了：提示词工程这么重要，那它是不是Agent开发里最核心的能力？

我的看法是，提示词能力决定了Agent的“表达下限”，而工具链和架构能力决定了Agent的“能力上限”。一个提示词写得很好的Agent，可能各项任务都能做到60-80分；但一个拥有强大工具链的Agent，可以通过调用专业的工具，把单项任务做到95分以上。提示词是让大模型的能力“发挥出来”的手段，但它替代不了外部工具的能力。

所以我的学习路径建议是：先花时间把提示词工程吃透，这是你所有Agent开发的地基；再花时间研究工具调用、多模态、RAG；最后才会走到微调那条路上去。地基打得越稳，后面起楼越踏实。

最后分享一个今天刚用上的小技巧：如果你觉得某个模型的输出“老是差口气”，不要急着换更大的模型。先把你现在的提示词里所有模糊的词都换掉，改成看得见摸得着的具体要求。很多时候，不是模型不行，是你还没把它调到该有的状态。