企业官网建设流程全解析

不夸张地说，提示词工程现在已经是“会用大模型”和“用得好大模型”之间的分水岭。同一个模型，有人拿它聊聊天天写个段子，有人拿它产出整份可交付的方案、代码和数据分析报告，差别就在提示词上。

这篇文章我打算写得全但尽量不啰嗦，覆盖从“提示词到底是个什么东西”到“程序员怎么写结构化提示词”再到“温度参数、思维链、踩坑记录”这一整套内容。不管你是完全没接触过的小白，还是已经写过不少代码的程序员，都可以按自己的基础挑着看，也可以直接收藏，等遇到具体问题再回来翻。

1. 我见过最浪费大模型能力的三种问法

先来回想一个很常见的场景：你打开某个大模型产品，在对话框里输入“帮我写一份活动策划”，然后回车。结果是，它确实给你写了一篇活动策划，但内容四平八稳、千篇一律，放哪都能用，放哪都没用。

这不是模型不行，是提示词给的“信息量”太小了。我过去一年里帮不少朋友排查过“为什么AI写不出来想要的东西”，最后发现几乎都能归结到下面这三种问法上。

1.1 只给任务，不给上下文

“帮我写个周报”“帮我写一封英语邮件”“给我列一份读书计划”。

这种一句话任务，就好比你在公司走廊里拦住一个刚入职的实习生，说“帮我做个方案”，然后转身走了。他没背景、没目标、没受众、没边界，只能给你一个看起来正确但毫无针对性的东西。大模型也是一样的道理：你给多少信息，它就只能在这个信息范围内做推断，缺了的关键信息，它会拿最常见的通用模板来糊弄你。

我后来养成一个习惯：每次发提示词之前，先问自己一句，如果这句话交给一个能力很强但完全不了解我处境的同事，他能做出来吗？如果他自己都得先反问你三个问题，那这个提示词就还没写完。

1.2 目标大而空，没有边界

“如何提升写作能力”“怎么学好编程”“帮我分析一下当前的行业趋势”。这种问题太宽泛了。模型不知道你的写作水平、不知道你想提升哪类写作、不知道你是零基础还是想进阶，所以它只能给出非常普适的“多读多写多练”式建议。

如果你把问题压缩到一个可执行的范围，效果立刻不一样。比如不要问“怎么提升写作能力”，而是问“我每周需要写一篇行业观察文章，但每次开头都卡半小时，请给我三种不同风格的开头写法，并分别说明适合什么选题”。这样的提示词，模型能给出的建议会具体十倍。

我自己经常用一个小技巧：在提示词里写明“我现在遇到的具体障碍是什么”，而不是单纯说“帮我写”。一旦把“卡点”讲清楚，模型就不会漫天撒网。

1.3 不指定输出格式，拿到一堆“散装”内容

很多人是想到什么问什么，完全不提格式要求。结果模型给你一段一段的纯文本，没有标题、没有表格、没有序号，看起来就像一份演讲稿。你觉得不好用，但模型其实很无辜——你根本没说要什么格式。

这里要记住一点：大模型的输出格式，默认是“最顺滑的自然语言”，也就是大段文字。你想要表格、Markdown、带序号步骤、JSON结构、字数限制，全部要明确写出来。尤其你是程序员、需要把输出拿去二次处理的时候，格式要求往往比内容本身还重要。

我放一个最典型的对比：

• 低质量提示词：帮我写个校园市集的活动策划
• 高质量提示词：帮我写一份面向大学生的校园市集活动策划，预算5000元以内，时间是周六下午两点到六点。输出格式为800字左右的活动方案，必须包含以下五个部分：活动主题、摊位布置、互动环节、人员分工、风险预案。语气务实，不要用空泛的形容词。

看出差别了吗？高质量那句把背景、预算、时间、结构、语气全部框住了，模型没有自由发挥的空间，输出自然贴合你的需求。

2. 好提示词和差提示词的分水岭：底层框架

我常跟朋友说，与其把提示词工程当成一门玄学，不如把它理解为“给新同事写一份需求说明书”。你把需求写得越清楚，对方交付的质量就越高。一份合格的提示词，背后通常包含四个要素：角色、任务、上下文、约束。

这四点不需要每次都写全，但你需要知道它们各自解决什么问题。

2.1 角色设定：不是嘴上说“你是专家”就够了

让模型扮演角色是提升输出质量最直接的手段。但你写的角色越具体，效果越好。比如“你是一名营销专家”这种设定，有帮助，但有限。你换成“你是一名有8年快消品行业经验的品牌经理，擅长市场定位和用户洞察，尤其熟悉校园人群的消费心理”，模型的输出风格会立刻变得不一样。

原因是模型在响应角色时，会倾向于调用与该角色相关的知识分布和语言风格。角色设定得越细致，它“进入状态”越深。不过也要注意一个度：角色不要堆砌太多。我见过有人写“你是资深产品经理、技术专家、心理学大师、写作高手”，这种角色多了，模型反而不知道以谁为主，输出会很拧巴。

一般建议：一个主角色加一两个关键属性就够用了。

2.2 任务指令：动词开头，目标唯一

“列出”“评估”“改写”“总结”“翻译”，这些动词是任务的核心。一个提示词最好只包含一个主任务，如果你有好几个子任务，不要堆在一起，而是拆成步骤让模型依次完成。

比如你想让模型帮你写一篇公众号推文，就不要只写“帮我写一篇推文”，而是写“请先列出这篇文章的大纲，再根据大纲逐段展开，控制在1200字左右”。这样模型有了明确的执行路径，不会一下子把大纲和正文混在一起，输出节奏也会好很多。

我自己的经验是，当任务描述出现“以及”“然后”“顺便”这类词的时候，就要警惕了。提示词里任务过多，模型会顾此失彼，最后每个任务都完成得很敷衍。

2.3 上下文：给模型一段“工作记忆”

上下文是提示词里最容易被忽略的一项。模型本身没有关于你的记忆，你给它多少背景，它就基于多少背景去思考。你要写商业计划书，就要告诉它你的行业、目标客户、市场情况、预算约束、竞争对手。你要写论文大纲，就要告诉它你的研究方向、主要素材、学校要求、目录结构。

这些信息能让模型的输出从“泛泛而谈”变成“为你量身定制”。我在一次实测里写过两份内容差不多的提示词，一份带了详细的行业背景和客户人群描述，另一份没带，前者的输出可落地程度明显高于后者。

但也提醒一下，上下文不是越多越好。如果你塞进去的都是一些无关紧要的信息，模型反而会被带偏。给信息的原则是“直接跟当前任务相关”。

2.4 约束与交付要求：把边界画清楚

约束条件，说直白点就是画“允许与不允许”。你希望输出多少字、希望它用书面语还是口语、希望它不要使用某些词、希望它以什么结构结束，这些都可以明明白白写在提示词里。

比如写商业文案时，你可以加一句“不要使用‘赋能’‘闭环’‘抓手’这类黑话，多用大白话”。写技术文档时，你可以加一句“不要输出多余解释，只输出可执行代码”。这些约束会直接影响模型的语言习惯，让它别按自己最习惯的套路出牌。

到这里你可能会发现，所谓提示词工程，并不是什么高深的魔法，本质上就是一句话：把你的需求说清楚。角色、任务、上下文、约束，这四样东西就是“需求说明书”的固定栏目，写多了自然顺手。

3. 小白先抄作业：拿来即用的三套提示词模板

如果你刚接触提示词工程，让你一上来就自己写框架确实有点难。我的建议是，先抄别人验证过的模板，把占位符换成自己的内容。用不了几次，你就能理解这些模板为什么要这样搭。

下面三个模板是我平时使用频率最高的，覆盖了大多数人日常的80%需求场景。

3.1 万能写作模板：适合周报、总结、方案、文案

这个模板的核心思路是：先把素材给够，再让模型帮你组织语言。很多人写不好提示词，是因为让模型去编造素材，而不是让它去整理素材。

你是一名[岗位]的[角色定位描述]。 接下来我要写一份[文档类型]，背景如下： [一句话说明这次写作的用途和目标读者] 我目前掌握的素材是： [分条列出你的关键信息、数据、已完成的工作] 请帮我把素材整理成一份[文档类型]，要求： 1. 结构上分为[第一部分]、[第二部分]、[第三部分] 2. 语气[正式/口语/简洁] 3. 字数控制在[数字]以内 4. 不要添加素材中没有的事实

比如写周报，就可以这样填：

你是一名市场部的运营专员，熟悉用户增长和活动执行。 接下来我要写一份本周工作周报，目标读者是我的直属负责人。 我掌握的素材是： ① 完成了线上拉新活动的页面搭建，活动上线3天新增注册用户1200人 ② 输出了下月内容日历初稿，覆盖公众号、小红书两个渠道共8篇 ③ 排查了上周投放转化率下降的问题，初步定位为落地页加载超时 请帮我把这些素材整理成周报，结构包括：本周完成、数据小结、遇到的问题、下周计划，语气简洁，总字数控制在400字以内，不要添加素材中没有的内容。

这个模板的关键在于它把“素材”和“组织”分开了。模型做它最擅长的事——重新组织语言，而不会替你去编造事实。

3.2 信息整理模板：适合会议纪要、文章摘要、内容归类

大模型处理长文本的能力很强，但它需要你明确告诉它“整理成什么样”以及“哪些信息最重要”。信息整理模板的核心思路是：给原始素材，定义输出结构。

以下是[一份会议记录/一篇文章/一段访谈]的原始内容： 【粘贴原始内容】 请帮我整理成一份[结构类型]，要求： 1. 包含[主题]、[关键结论]、[待办事项]三个部分 2. 每条结论用一句不超过20字的话概括 3. 待办事项需标出负责人和时间点 4. 如果有信息缺失则注明“原文未提及”，不要自行补充

比如开完会你有一大段语音转文字：

以下是本次项目讨论会的语音转写内容： 【粘贴转写文字】 请整理成会议纪要，包含：会议主题、主要讨论点、最终结论、待办事项（负责人+截止时间），输出用Markdown格式，关键结论每条不超过一行。

这个模板价值在于“不要自行补充”这一句。它防止了模型在整理时顺手编造细节，这是信息整理场景最容易踩的坑。

3.3 学习辅导模板：适合解释概念、拆解问题、做知识梳理

遇到陌生概念，直接问大模型“什么是XX”，得到的答案往往是大而全的定义，看完似懂非懂。但如果你要求模型用类比来解释，效果会完全不一样。

你是一名[教学角色]。 我正在学习[主题]，完全没有相关基础。 请用生活化的方式解释[概念]： 1. 先给出一个生活化的类比，让我建立直觉 2. 再补充一个简单的例子，展示这个概念实际怎么用 3. 最后用一句话总结这个概念的本质 4. 过程中避免使用专业术语，如果必须使用请先解释

举个例子，如果你问“数据库索引是什么”，标准答案可能是一堆B+树、查询优化之类的名词。但用上面的模板，模型会给你解释成类似图书馆索引卡片一样的东西，让一个零基础的人也能迅速建立直觉。这个模板非常适合所有自学场景。

这三个模板你直接用即可，先跑通几次，再回来看第二部分的原理，会发现原来模板的每一句话都对应着“角色/任务/上下文/约束”里的某个要素。

4. 程序员进阶：用工程化思维写提示词

如果是程序员，前面的基础可能已经不够了。实际开发中你要处理的是不可控的输入、需要自动化的输出，还要考虑提示词的复用、测试和维护。这一部分我把自己在项目里用到的工程化方法分享出来。

4.1 用分隔符把“指令”和“数据”隔离

当你让模型处理一段外部输入时（比如一段用户评论、一段日志、一段文档），指令和数据混在一起会让模型分不清“让它做什么”和“给它什么”。解决办法是用一个明确的标记把输入数据包起来。

请你判断以下用户反馈的情感倾向（positive/negative/neutral）。 反馈内容在####和####之间： #### 快递晚了两天还没到，客服也联系不上，体验很差。 #### 请直接输出情感分类结果。

用分隔符的核心价值是降低歧义。模型在没有明确边界的情况下，很可能把你给的数据也当成指令的一部分来理解。边界越清晰，模型理解越准确。

4.2 结构化输出：让模型直接产出可编程的数据

程序员用大模型，最大的诉求往往是“输出可以直接被程序消费”。这时候，让模型输出JSON是一个非常实用的方案。但要让模型稳定地输出JSON，需要把字段定义清楚。

对以下用户评价进行多维度分析，并以JSON对象输出。 字段定义： - sentiment: 情感倾向，值为 positive/negative/neutral - keywords: 评论中提到的主要问题点，字符串数组 - summary: 一句话总结，不超过20字 评价内容： 商品质量还可以，但色差比较严重，包装也有破损。 输出要求：只输出JSON对象，不要输出任何解释，不要用Markdown代码块包裹。

这里关键点是最后那句“不要输出任何解释，不要用Markdown代码块包裹”。很多模型在默认情况下会好心地在JSON外面加一个```json代码块，虽然人眼看着舒服，程序解析起来却多了额外步骤。把这句话写进去后，输出基本就是干干净净的JSON。

4.3 少样本示例：给一个范例比给十条规则更有效

少样本提示词的核心思路是：在提示词里直接给出一两个输入输出示例，让模型照着模仿。很多时候，一个具体例子比一段抽象描述更能约束模型的输出风格。

请判断下面的客服工单应该分配给哪个部门。 可选部门：技术支持、售后服务、物流支持、账号安全 示例1： 工单：电脑频繁蓝屏，重启也没用。 结果：技术支持 示例2： 工单：银行卡被锁定了，收不到验证码。 结果：账号安全 现在请判断： 工单：订单显示已签收，但实际没有收到包裹。 结果：

少样本这种方式，本质上是在给模型建立“参考系”。它对输出格式、输出风格、判断标准的约束效果比写一大堆规则还要好。我在做自动分类任务时，优先使用少样本而不是写一堆if-else式的规则描述。

4.4 提示词的版本管理与回归测试

很多程序员把提示词当成一次性输入，用完关掉就没了。但在正式项目里，提示词和代码一样需要管理，它会随着测试迭代变化。

我的习惯是：把每个生产环境使用的提示词保存成独立文件，文件名带版本号，比如classify_prompt_v1.2.md。文件内容包括提示词全文、适用场景、示例输入输出、曾踩过的坑。每改动一版，就把旧版本留档。这样当模型服务升级或输出质量下降时，你能快速回滚到之前稳定的版本。

跟提示词配套的，还要有回归测试样例。我会维护一组固定的输入，每次修改提示词后都跑一遍，看输出是否符合预期。模型本身的更新可能导致输出变化，有了回归样例，你可以第一时间发现“是不是提示词不行了”。

5. 让模型“先想再做”：思维链与参数微调

进入这一部分，算是提示词工程的中高级操作了。很多人把提示词单纯理解为“把话说清楚”，这没错，但如果想把模型能力再往上压榨一层，你需要理解两个东西：思维链和生成参数。

5.1 思维链：让模型的输出有“推理过程”

大模型在回答复杂问题时，如果直接要求它给出结论，它很容易跳跃到常见的答案模式，省略中间推理过程。但如果你要求它先列推理步骤再给结论，正确率会有明显提升。

这就是“思维链提示词”的基本思想。通俗一点理解：它就像考试做数学题，只写答案的学生容易在中间步骤出错，要求写清过程的学生，反而会因为有步可依而少犯低级错误。

最简单的用法是在提示词里写明：

请按以下步骤回答： 1. 先拆解我在这个场景下面临的问题是什么 2. 列出可能的解决思路，并比较各自的优劣 3. 给出你的建议，并说明理由

实测下来，对于推荐类、规划类、分析类的问题，加了思维链之后输出质量几乎都会上一个台阶。一个细节是：近年不少模型本身已经在内部做了推理规划，对外表现为“默认就该更好”。但在指令明确、需要分步输出的应用场景里，显式写清步骤依然有效，一方面是为了让中间过程可见，另一方面也是用结构约束住模型，不让它跑题。

5.2 温度参数：稳定与发散之间的旋钮

如果说提示词是“告诉模型做什么”，那温度参数就是“告诉模型怎么选词”。简单理解，温度越高，模型每次输出越随机，越有“发散感”；温度越低，输出越保守，越稳定。

在代码生成、分类、信息提取这类场景中，你希望模型尽量稳定、别自由发挥，此时的温度应设置偏低，我常用的范围是0到0.3。在创意文案、头脑风暴、起标题这类场景中，适当的随机性反而能带来惊喜，温度可以调高到0.7到0.9。你可以根据自己的口味去调：

大部分产品界面的默认温度通常偏高，更偏发散，这也是为什么你在让模型写代码时，它却常常给你“加了点自己的理解”。遇到这种情况先检查一下温度配置。

5.3 上下文窗口与多轮对话的取舍

上下文窗口是模型单次能接收的信息总量。对话轮数越多，占用的上下文越多，早期信息会被逐渐挤出去。这时候模型会出现一个典型行为：你说的最新几句话它记得很清楚，但最开始给它的关键要求已经被慢慢遗忘了。

所以我的建议是：对于重要任务，不要用多轮对话慢慢挤牙膏，而是把完整需求一次性写清楚放在一轮里。如果任务特别复杂，拆成多个独立子任务分开对话，每个子任务都自己携带完整上下文，得到的结果往往比在多轮对话里来回修更好。

还有一个反直觉的经验：写代码任务里，与其反复在一个会话里从第一版改到第五版，不如在最后需要整合时新开一个会话，把前面积累的出问题和修问题记录整理成一个新的提示词，把“最终需求”一次性发给模型。此招面对长任务时非常省心。

6. 实测踩坑记录与提升稳定性的操作细节

说到底，提示词工程是一个需要反复实践的手艺。我把自己踩过的坑整理成了一张表，算是给前面所有内容的补充。

6.1 高频翻车场景与对策

这张表我曾经打印出来贴在显示器边上，每次遇到输出不对劲就对照看一眼，结果省下来很多无谓的折腾。

6.2 先调提示词，别急着换模型

遇到模型输出质量下降，不少人的第一反应是怀疑模型不行。但在大多数情况下，问题出在提示词本身。建议你先做一轮自查：背景信息给了多少？输出格式有没有明确？示例有没有给？温度设置是否合理？我自己实测，80%的“效果不好”都能通过调整提示词解决，换模型反而要付出迁移成本。

调提示词时记住一个原则：一次只改一个变量。比如第一次只加“受众背景”，第二次只加“示例输出”，这样你能清楚地知道哪一处改动带来了效果提升。全部混在一起改，遇到效果变好了，你反而不知道是哪个词生效的。

6.3 多轮对话的“错误污染”问题

多轮对话中，如果模型第一轮输出里已经出现了一个错误，你在后续轮次纠正它，模型有很大概率在后续输出里继续沿用前面错误的信息。这种“错误污染”在多轮对话中非常常见。

对策有两条。第一，当发现模型跑偏时，不要继续在同一个会话里纠正，直接新开一个会话，把完整需求重发一次。第二，如果你想保留前面的有效信息，可以在新会话里把之前有价值的输出复制给模型，同时明确告知“忽略之前对话中的错误，按当前要求重新生成”。

6.4 一个不会过时的底层能力

说了这么多方法和参数，最后讲点体会。提示词工程这个领域变化很快，今天很多人还在研究提示词模板，明天模型厂商就可能更新了更好的交互方式。但有一个底层能力不会变：把需求说清楚。无论是给人派活，还是给大模型写提示词，这个能力都是相通的。

如果你刚开始接触，我建议你把前面第三部分的模板先存下来，真实场景中用上三次。等你用完了，再回头读第二部分的框架，大概率会有“原来如此”的体会。我到现在还会定期翻看自己之前写过的提示词，有时候会发现当时写得很啰嗦，简洁后效果反而更好。

这就是提示词工程有意思的地方：它不是一条死记硬背的技术路线，而是一个不断把你脑子里的想法打磨得更清晰的过程。多写、多试、多复盘，效果自然会出来。