企业官网建设流程全解析

1. 为什么明明用了大模型，结果还是像在“猜”你要什么

我第一次上手做 AI Agent 的时候，最大的挫败感不是模型能力不够，而是我压根说不明白话。我问它“帮我分析一下这个需求”，它给我写了两千字的代码架构；我说“写得简单点”，它又给我改成了十条 bullet point。反复拉锯几轮之后，我意识到问题不在模型，而在提示词本身——提示词不是“问问题”，而是“描述你想要的完整工作方式”。

很多刚接触大模型的朋友会有个直觉：AI 不是跟人聊天吗？那我像跟同事说话一样说需求不就行了？这个直觉一半对一半错。对的是它确实能听懂自然语言，错的是大模型对模糊容忍度极低。你给了它一个模糊目标，它就会用概率最高的方式瞎猜——而概率最高的方式，往往是“最平庸的泛化回答”，不是你要的那个具体结果。

1.1 先理解提示词进入模型后发生了什么

从技术底子上看，大模型本质上是一个“基于上下文的概率预测器”。当你把一串提示词输进去，它做的事情是把文字切分成 token，然后逐个预测下一个 token 最可能是什么。这个过程跟人理解语言完全是两回事——人理解的是“意图”，模型计算的是“统计上的延续”。

这就解释了为什么同一个提示词，在不同模型上结果天差地别：因为不同模型的训练数据、参数规模和指令遵循能力不一样。强一点的模型（比如 Claude、GPT 系列的中高端版本）对“少写废话”这种相对抽象的指令执行得比较好，弱一点的模型就需要你把规则掰开揉碎写清楚，“降低输出长度，每节不超过 100 字，不要使用列表”这种颗粒度。

有个曾经很火的梗叫“鹈鹕骑自行车”——是一张测试多模态模型的图片，很多模型看不出鹈鹕是怎么骑的。这种“看不见”和“听不懂”是一个道理：它没有建立“把图片里每个对象和动词关联起来”的指令链条，所以只能凭常见组合猜。提示词工程在文本场景里要做的事情也类似：用足够精确的表述，把模型的猜测空间压到最小。

1.2 常见的“听不懂”场景，背后是同一个原因

我在实际项目里总结过，模型“听不懂”基本逃不开四类情况：

• 目标含糊：只说“帮我处理一下数据”，没说处理成什么样、按照什么维度、产出什么格式。
• 背景缺失：没交代这个结果给谁用、用在什么场景、有没有历史约束，模型只能按通用方式处理。
• 约束遗漏：没说不许用什么技术栈、不需要什么内容、避开哪些坑，它就会给你填一堆它觉得“加分”的料。
• 格式没约定：没说输出 JSON 还是表格还是纯文本，它就按心情混合输出，下游解析直接炸掉。

这四类问题跟模型参数规模其实关系不大，纯粹是提示词没有给到足够的信息密度。就好比你让实习生去整理一份行业报告，只丢给他一句“整理一下”，他肯定交回来一份你不想看的东西——不是他笨，是任务描述根本没达到“可执行”的标准。

所以“让大模型真正听懂你说话”这个系列的主题，不是教你怎么“把话说的更好听”，而是教你怎么把一个模糊需求翻译成一个精确的任务规格说明。这个翻译能力，就是提示工程的核心能力。

2. 把提示词拆开看：六要素写出不翻车的提示词

我早期写提示词非常随缘，想到什么写什么。后来被现实教育了几次（比如让 AI 生成的代码直接带 bug 进生产、让 AI 写的文案被合规打回三次），才开始认真整理一套结构化的写法。现在我基本会把一条正式提示词拆成六个要素：角色、任务、上下文、约束、示例、输出格式。

这套东西说起来很简单，但真正每条都用上、用好，效果完全是两个量级。下面逐个拆开说。

2.1 角色、任务、上下文：先把“人设”立住

角色（Role）不是花活。“你现在是一个资深 Python 后端工程师”这句话，最大的作用不是让模型“代入”，而是激活它在训练数据里学到的相关领域知识分布。它学过海量的 Python 代码和架构讨论，但你不提角色，它可能按“通用写作助手”的模式来组织语言。一个简单测试：同样的技术问题，用不用角色后缀，输出的术语颗粒度完全不同。

任务（Task）是整条提示词的心脏。这里最容易犯的错是把任务写成“目标”而不是“动作”。比如：

• 失败写法：“分析这段代码”
• 成功写法：“指出这段代码中所有可能导致并发问题的地方，按严重程度排序，并针对每一项给出具体修改建议”

区别在哪里？后者有明确的检查方向（并发问题）、有排序要求（严重程度）、有产出物（修改建议）。模型不需要猜你要什么，只需要照着做。

上下文（Context）是很多人忽略但最能拉开效果差距的。一个项目里，你要告诉模型这个代码服务的业务是电商订单还是算法训练，数据量级是多少，服务于内部还是外部用户。同样一句“查询超时怎么优化”，有上下文时它会往索引、连接池、缓存方向写；没上下文时它可能从硬件配置开始讲起，对你来说全是废话。

2.2 输出格式、约束与示例：把验收标准说清楚

输出格式（Format）这件事在 AI Agent 场景里尤其重要——因为 Agent 的下游往往不是人，而是代码。如果模型输出 Markdown 而你的解析器只认 JSON，那后面全部白搭。所以我在所有工程化提示词里都会写一条“你必须输出 JSON，不要包含任何解释性文字”之类的话，并且用代码块或示例来锁定结构。

约束（Constraint）是提示词的“红线”。比如“不要调用外部 API”“不解释代码，只给出修改后的完整函数”“不要使用第三方依赖库”。约束放得越具体，模型越不容易在边界上来回试探。但它有个副作用——约束多了会挤占上下文空间，也可能会让模型变得过度保守。所以约束要有优先级，一条提示词里最好不超过五条强约束，其余用示例来暗示。

示例（Example）是最强的约束。一切抽象描述都不如一个具体的输入输出对照模板。想让模型按格式输出，你给一个“输入：…；输出：…”的例子，比写一百字“请严格遵循以下格式”都管用。很多成熟的 prompt 模版就是靠 two-shot / three-shot（给两到三个示例）来稳定模型输出的。

2.3 一个对比案例：要素全乎和要素缺位的差距

我拿自己实际调过的场景做一个对照。当时要做的是一个工单分类 Agent，输入是用户提交的文本工单，输出是分类结果、紧急程度和处理建议。

第一版提示词是这样：

请分析下面的工单并给出处理建议： {工单内容}

这种提示词不是不能用，而是输出质量极不稳定：分类类别它自己定，紧急程度有时候高有时候低，处理建议有时候给三行有时候给三页，而且偶尔会夹带私货“这道工单可转人工处理”这种流程话。后来我按六要素重写：

角色：你是电商平台的工单分类专员，熟悉退换货、物流、支付、账号安全四类业务。 任务：判断工单所属类别、紧急程度（高/中/低），并给出不超过50字的处理建议。如果信息不足，输出"需补充信息"。 上下文：工单来自C端用户，分类结果会进入自动响应系统，紧急程度高的工单会触发人工介入。 约束： - 只输出JSON，不要输出任何其他文字 - 分类只能是：退换货/物流/支付/账号安全/其他 - 紧急程度判断标准：涉及资金安全或无法登录为"高"，涉及时效承诺为"中"，其余为"低" 输出格式： {"category": "...", "urgency": "...", "suggestion": "..."} 示例： 输入："我上周买的手机到现在没发货，客服也没回应" 输出：{"category": "物流", "urgency": "中", "suggestion": "核查发货超时原因，优先发送物流异常通知并承诺处理时限"}

改动之后效果立竿见影：解析成功率从大概七成涨到接近满分，而且模型基本不会再冒出来格式外的内容。这段对比也是我在文章里最想传递的一个观点——提示词不是写给人看的，是写给模型看的“需求规格说明书”，你把每个环节讲得多细，它就执行得有多准。

3. 提示工程进阶：让模型“想清楚”再回答

六要素解决的是“说得清楚”的问题，但很多时候需求说清楚了，模型给出的结果还是浮于表面。比如你让它“写一个用户登录接口”，它确实写了个接口，但没有异常处理、没有日志、没有防刷——它是在“直接给答案”，而不是“先想一遍再给答案”。

这时候需要用一些进阶技巧，让模型输出的深度从“表面正确”走向“真正可用”。

3.1 思维链不玄乎，就是把做题过程写出来

思维链（Chain-of-Thought，CoT）在论文里的定义很学术，但在实操中就是一句话：在要求模型给最终结果之前，先让它把思考过程和中间步骤写出来。这个原理也不复杂——模型在生成最终答案前会先走一段“思维过程”，如果你允许它显式地写出来，它的每一步推理会更有依据，而不是直接跳到结论。

比如做 count 类题目，你直接问“下面这句话里有几个 'a'”，模型经常数错。但你让它“先列出每个单词，再逐个检查字母”，正确率会有明显提升。Agent 场景里更典型的是“规划型任务”：“用户想买一台性价比高的游戏本，预算6000”。如果直接给答案，它可能推荐热门机型；如果让它“先拆解用户需求，再筛参数，再对比竞品，最后给推荐”，答案的层次完全不同。

实操上，CoT 有两种注入方式。一种是在提示词里显式写“请一步一步思考，并在最终答案前输出你的推理过程”；另一种是用 few-shot 示例，在示例里展示“步骤1、步骤2、结论”的结构。后者更隐蔽，但稳定性更好，尤其当你用的模型比较弱、显式要求容易触发额外瞎编的时候。

注意：CoT 不是所有场景都必须上。如果任务是“翻译一句话”“做文本分类”，你让它多想几步反而会拖慢速度、浪费 token，甚至因为“多想”而偏离标准答案。把 CoT 用在逻辑推理、方案设计、代码生成这类复杂任务上，收益才最大。

3.2 Few-shot 示例比“你要专业一点”有效得多

很多人调提示词喜欢加形容词：“请专业地回答”“请详细一些”“请严谨一点”。这些词不是没用，但作用非常有限——它只是改变了模型的“语气分布”，没有改变模型对任务结构的理解。

相比之下，给样例（few-shot）的效果要扎实得多。因为你实际上是在做“隐式约束”：模型会模仿你给的例子的结构、详略程度、语气、甚至格式。我见过一个很夸张的例子，有人让 LLM 写英文邮件，加了五个正式商务邮件样例后，模型的输出措辞直接从中性偏文本风格变成了地道的商务风，比写“use formal tone”管用太多了。

Few-shot 的使用也有技巧：

• 示例数量不是越多越好。两到三个高质量样例通常就够了，太多会占用上下文且增加成本。
• 示例要覆盖“边界情况”，不要全给“典型示例”。比如分类任务中，给一个模棱两可的例子和它的处理方式，比给三个明显类别的例子更能提升判断稳定性。
• 示例的格式必须跟期望输出的格式完全一致，不然模型会按示例里的隐含格式输出，反而破坏了你设定的 JSON 结构。

3.3 温度、top_p、top_k、max_tokens：参数跟提示词是搭档

有一段时间我只盯提示词，完全忽略推理参数。后来才发现，参数和提示词是配套的——同一个提示词，把温度从 0.7 调到 0.2，输出的稳定性和可预测性完全不一样。

我把几个关键参数按 Agent 开发视角整理成了一张速查表：

这里最容易踩的坑是：为了“更有创造性”，把温度拉很高，结果 Agent 开始不听指令，甚至会自己编字段名、编错误格式。Agent 的核心诉求是“稳定执行”，不是“妙语连珠”。所以除非你在做文案生成、创意类任务，否则温度控制得越低越好。

我还养成了一个习惯：改提示词和改参数两条路分开调。如果输出风格不对，先改参数；如果输出内容不对，先改提示词。混着改最致命——出了问题根本定位不到是哪个变量导致的。

4. 面向 AI Agent 的提示词设计：这事比单轮对话更讲究

单独写一条好提示词和给 AI Agent 写提示词，完全不是一个量级的问题。Agent 场景里，模型要自主做决定、调用工具、承担多轮上下文，还要从错误里恢复。这就提示词工程提出了更高要求——每一轮对话里的提示词，都像给一个“带工具的实习生”下指令，说得不到位，它会拿斧头削铅笔。

这个系列叫“AI Agent 学习之路”，所以这篇要重点把 Agent 相关提示词设计的特殊之处拆清楚。

4.1 系统提示词与任务提示词的分工

很多人一开始写 Agent 会把所有内容塞进一条 system prompt，包括“你是谁”“你要做什么”“工具怎么用”“输出什么格式”“遇到错误怎么办”，全堆在一块。这样做不是不行，但效果通常不好——因为上下文一长，模型的注意力就会被稀释，越靠后的内容越容易被淡忘。

我更推荐的做法是三层分工：

• 系统提示词（System Prompt）负责“身份 + 规则 + 工具定义”：这一层是长期稳定的，告诉模型它是谁、有哪些工具可用、行为边界是什么。
• 任务提示词（Task Prompt）负责“本轮目标”：每一轮的具体任务描述，比如“用户想查询订单状态，请先调用 get_order_info 工具”。
• 上下文管理（Context）负责“历史信息与状态”：把之前的对话摘要、当前状态、中间结果喂给模型，让它能接上上下文。

这样分开之后的好处是：改任务需求不用动系统提示词，改工具调用规则不用动每轮的 prompt，整个 Agent 更好维护。而且大部分 Agent 框架（LangChain、LangGraph、Spring AI 等）都支持分开设置 system 和 user 消息，拦的不是技术，是思路。

4.2 工具调用：把“动作”描述成模型能理解的结构

Agent 比单轮对话多出来的核心是工具调用。这时候提示词设计的一个关键问题是：怎么让模型知道“什么时候该调用哪个工具，参数怎么填”。如果你只是把函数的说明贴在提示词里让模型“看着用”，它大概率会在不该调的时候调、该调的时候不调。

更稳定的做法是显式的工具描述结构。我在 LangChain 这类框架里写工具时，除了 function name / description / parameters 之外，还会在 description 里补上“触发条件”和“忌讳调用条件”。比如：

@tool def get_order_status(order_id: str) -> str: """查询订单当前物流状态。仅当用户明确询问订单/物流/发货进度时调用。 触发条件： - 用户提供了订单号，或询问“我的订单到哪了” - 用户提到“发货”“物流”“配送”关键词 不要使用此工具的场景： - 用户只是问“怎么退货”，应调用 return_policy 工具 - 用户没有提供订单号，先询问订单号 """ ...

这种描述的效果是：模型会先做“意图匹配”，再决定调不调用，而不是看到关键词就去调。这大幅减少了“错误工具调用”这种 Agent 场景里最常见的翻车点。

4.3 上下文工程：Agent 对话里最容易被忽略的坑

提示词不是只有你写的那几行字——对模型来说，每一轮对话累积的历史消息、工具返回的结果、系统预设，全都是“隐式提示词”。这就是为什么很多人发现 Agent 在对话中间开始“失忆”或者输出偏差：不是模型坏了，是上下文污染了。

我在实际开发中最常遇到的三类问题：

• 历史消息过长导致注意力漂移：对话进行到二三十轮，早期信息早就被“稀释”光了，模型只能记住最后几条消息。解决方案是定期做摘要压缩，把历史对话浓缩成几条关键事实再塞回去。
• 工具返回的原始数据污染指令遵循：工具返回一大段 JSON 之后，模型的注意力会被这些结构化数据带走，反而忽略了“下一步应该做什么”。解决方案是在工具返回前或返回后添加一段“基于以上结果，你需要做什么”的指令性文本。
• 用户的随意表达带偏 Agent 方向：用户中途插一句“其实我就是想看看”，就可能让 Agent 偏离原任务。这时候 system prompt 里要有“任务边界声明”：无论用户怎么说，你的目标是 X，如果用户请求偏离目标，请婉拒并重新引导。

这就是圈子里经常讨论的“提示词工程与上下文工程”的差异——提示词工程解决“怎么说清楚”，上下文工程解决“怎么让模型持续保持对目标的聚焦”。做 Agent 光有前者远远不够。

4.4 系统提示词与 Skill/Agent 的区别：别在提示词里塞代码

我之前看到很多人困惑“系统提示词工程和 Skill 机制有什么区别”。简单说：系统提示词是给模型读的“说明书”，Skill（在很多 Agent 框架里指可复用的能力模块）是一段可以动态插入提示词里的“专家级文本模块”。这两者核心区别在于静态与动态。

系统提示词是常驻的，不管用户问什么，模型都要看到它——适合放身份、安全规则、核心约束。Skill 类能力模块则不是常驻的，而是按需加载的：用户一问到“帮我写 Python 代码”，框架才把“Python 专家 Skill”的提示词动态注入到当前上下文里。这样做的好处是省 token、不干扰无关任务、也不容易让模型“角色混乱”。

所以我的建议是：不要把什么都塞进 system prompt，尽量把领域知识拆成可按需调用的 Skill 模块。这在 Agent 框架里对应的是 prompt selector / skill loader 这类机制。你越早建立这种模块化思维，后面打量产级 Agent 越轻松。

5. 调试提示词的实战过程：从“答不对”到“稳定可用”

提示词看起来是个创作工作，实际上是一个工程调试过程。我见过很多人写提示词一遍过，然后跑一次不行就开始全盘推翻重写，最后越调越乱。我自己早期也这样，后来摸索出一套相对可控的调试方法，分享给大家。

5.1 先定位：是理解错、执行错还是格式错

当模型输出不满足预期时，第一步不是改提示词，而是判断错在哪一层。我把问题分成三类：

• 理解错：模型压根没搞懂任务，输出内容答非所问，或者方向偏了。
• 执行错：模型懂了任务，但步骤执行得不对，比如漏掉了某个条件、没用上上下文信息。
• 格式错：内容对但输出格式与下游不兼容，比如没按 JSON 输出、多了解释文字。

定位方法很简单：把模型输出和你期望输出放在一起逐条对照，看偏差是出现在“该做什么”还是“该怎么做”还是“该输出成什么样”。定位之后再做针对性修改，不要一条提示词从头改到尾。

5.2 拆变量：一次只改一个条件

提示词调试最大的坑是“变量混动”。比如你同时改了任务描述、加了示例、又换了温度参数，结果输出变好了——你根本不知道是哪个改动起了作用。下次遇到类似问题，你无法复现成功经验。

正确做法是像做实验一样，一次只改一个条件，其他全部锁定。比如先保持提示词不变，只把 temperature 从 0.7 调到 0.1，观察稳定性变化；再保持参数不变，加一个示例，观察格式遵循度。每一步都有明确变量，才能形成可复现的调优结论。

我实际做的时候还会保留一个提示词版本管理表，记录每次改动的版本号、改动内容、测试结果。Agent 项目跑久了你会感谢这个习惯——否则三个月后你根本想不起来现在这版提示词是怎么演化来的。

5.3 回归测试：提示词的“用例”意识

提示词也值得写测试用例。我在 Agent 项目里会维护一组固定的评测输入，每组输入配上期望输出断言（可以是解析结果的检查规则，也可以人工判断标准），每次调整提示词后都拿这组用例跑一遍回归。这个习惯救过我很多次——有时候改动会让 A 场景变好，却悄悄破坏了 B 场景的稳定性。

用例的覆盖要比你想的更全面，至少包括：

• 常规情况：正常需求，期望模型按标准流程处理。
• 边界情况：用户输入极端简短、信息不全、类型混乱。
• 禁忌情况：用户试图让 Agent 偏离任务目标、跨边界操作。
• 工具异常：工具返回错误或空数据，模型能否合理处理。

5.4 常见问题速查表

我把实际开发中最常遇到的几种提示词问题整理成一个速查表，方便大家直接对照：

这套速查表不替代调试流程，但能帮你快速定位问题的大方向，省掉很多盲目试错。

6. 当提示词撑不住的时候：把工程升级成流程

提示词不是万能的。我见过太多项目在提示词上死磕到最后一地鸡毛——为了一个稳定的输出结果，反复堆提示词内容、堆示例、堆约束，最后提示词长得像一篇论文，成本高、维护难，还经常因为一个小改动引发连锁反应。

做 Agent 到这个阶段，需要换个思路：把提示词的一部分职责“卸载”到工程框架里。

6.1 识别提示词的边界

哪些问题适合靠提示词解决，哪些该用代码解决？我的划分标准很简单：

• 内容层面的事情（语气、角度、详略、信息组织）交给提示词。
• 流程层面的事情（分支判断、状态管理、重试机制、数据校验）交给代码，而不是试图用提示词“说服”模型永远不犯错。

举个例子：Agent 的工具调用返回一个 JSON，里面有个字段可能缺失。你可以在提示词里写“如果字段缺失请这样处理”来碰运气，但更稳妥的做法是在代码层做字段校验——缺失就触发重试或走兜底逻辑。提示词负责“生成”,代码负责“兜底”，这个分工应该是 Agent 架构设计的基础认知。

6.2 标准化的下一步：提示词模板 + 工作流

当你的 Agent 从“一个好玩的东西”变成“一个要稳定上线的服务”时，我特别推荐把核心提示词做成模板和版本化管理。具体操作上，把提示词中容易变化的部分（比如用户输入、工具返回结果）替换成模板变量，再用一个统一的渲染函数来生成实际请求。这样提示词的改动不再散落在代码里，而是集中在专门的 prompt 目录下，做 diff、回滚、审查都方便。

再进一步，如果你用的框架支持 LangGraph 这类图状编排，可以把复杂 Agent 拆成“流程节点 + 节点内提示词”的结构。比如“意图识别节点 → 信息收集节点 → 方案生成节点 → 复核节点”，每个节点一个专职提示词，比一个全能的巨型提示词要可靠得多。这就是为什么现在圈子里都在聊“从提示词工程到 Agent 工程”的升级——单一的提示词只是 Agent 的一块砖，流程编排能力才是承重墙。

6.3 给 AI Agent 学习之路的衔接建议

这是 AI Agent 学习之路系列的第二篇，如果你想继续深入，我的个人建议是：把提示词掌握到“能稳定解决单点任务”的程度后，赶紧往三个方向进阶——一是理解 Agent 框架内部是怎么把提示词、工具、记忆组合起来的；二是学会用 LangGraph 这类编排工具做一个需要多步骤决策的真实 Agent；三是开始关注上下文工程和评估体系，这才是 Agent 能不能落地到业务里的分水岭。

不要沉迷于“调一个超神提示词”的体验，那会让你误以为提示词就是 Agent 的一切。等你看过真实业务中那些复杂的用户输入、混乱的工具返回、以及模型时不时的不确定性，你会明白：提示词是对模型的“第一层约束”，工程架构是“第二层约束”，两者配合才能做出真正耐用的 Agent。

我在实践中最大的体会是：好提示词不是写出来的，是“改出来的”。没有任何人第一版就能写出完美的提示词，但你只要建立结构化的写法、有方法地调试、敢把不稳定的部分交给工程兜底，这条路其实比大多数人想象得更快。下一篇我会继续往 Agent 框架走，把 LangChain 和 LangGraph 里提示词如何与工具、记忆、流程真正串起来这件事讲透——到时候你会发现，提示词工程积累下的这套“写清楚、拆变量、做回归”的习惯，几乎是后面所有 Agent 开发动作的地基。