企业官网建设流程全解析

简介：这是一份面向AI语言模型使用者的提示词基础参考资料，定位于AIGC场景下Prompt的设计与优化，适合需要系统提升AI交互质量的个人学习者与团队。内容以常用Prompt为主线，逐一说明写作助理、提示词修改器、提示词生成器、英语翻译或修改、论文式回答、语音输入优化等场景的目标与调用方式；写作助理突出拼写语法、清晰简洁与可读性改进，提示词修改器可重新撰写更适配GPT-4等模型的提示语，生成器则支持按指定标题构造自制Prompt，翻译模块强调用更高级、更优雅的英文替换简化表达。全文以单个PDF文件呈现，压缩包大小1.36MB，文件类型为PDF，便于下载后离线阅读或检索具体模板。截至目前已有1060人学习下载。通过学习，读者能直接获得可套用的中英文提示词模板及具体示例，并理解如何根据需求调整提示结构，从而强化模型输出质量、减少人工修正成本，整体提高人机协同效率。

1. 《AI提示词大全》基础版：它不是拿来背的，是拿来拆的

拿到一份《AI提示词大全》基础版 PDF，最常见的开局是翻完目录，看到“写邮件”“做表格”“写代码”“润色文案”各占几十条，存进收藏夹，然后就再也没打开。真照着抄的时候，输出总差一口气：标题不够抓人，代码跑不通，表格改了这处漏了那处。问题不在模板不够好，而在提示词本来就不是用来背的，是用来拆的——基础版每条模板背后都站着一套“角色设定 + 任务描述 + 输出约束”的结构，拆出这层骨架，你才能在任意模型和任意场景里自己拼提示词。这篇文章面向每天重度使用对话模型的从业者，目标很具体：把手头那本基础版 PDF 变成自己的模板库，文案、代码、数据处理三类高频场景直接复用，同时把最常见的翻车点提前踩一遍。

2. 提示词的三层骨架：角色、任务、输出约束怎么配比

任何一条能稳定产出的提示词，都能拆成三个部分：模型以什么身份说话、模型具体干什么、输出长成什么样。这三层缺一个，输出质量就会明显下滑。基础版 PDF 里的模板质量参差不齐，但凡是效果稳定的那几条，结构上都符合这个骨架。这一章把每层拆开讲清楚，后面所有场景模板都从这里推导。

2.1 角色设定：让模型进入正确的推理语境

先问一个问题：为什么“帮我写一个活动策划案”和“你是一名活动策划，帮我写一个活动策划案”，输出质量差别会那么大？不是玄学，是模型在训练阶段见过大量不同身份的语料，角色词会把接下来的生成路径拉向对应的语料分布。“活动策划”四个字激活的是方案类文本的语言习惯：分阶段、有预算、列玩法。没有角色词的时候，模型默认走的是“通用助手”的路径，什么场景都能答，但什么场景都不深入。

我在整理基础版 PDF 时发现，里面收录的角色设定五花八门，但真正有效的只占一小半。有效的那批有个共同点：角色不是孤立的，它后面一定跟着任务。完整的结构是这样：

你是一名【角色】，擅长【领域】。 现在请你完成下面的任务：【具体任务描述】。 要求：【输出约束】。

提示：角色设定只负责“模型以什么身份和语气说话”，它不负责告诉模型做什么。只写“你是一名资深文案”不接任务，输出会变成一段自我介绍的废话。

参数层面的建议是：角色越具体越好，但不要超过两层。“资深市场营销专家”比“营销专家”好，“有十年快消品行业经验的资深市场营销专家”反而开始拖累输出，因为模型要把多余的身份信息也考虑进去，生成速度变慢，还容易跑偏。我一般控制在“一个头衔 + 一个擅长领域”的结构，后面直接跟任务。另外，角色设定要放到会话开头或 system 位置，而不是埋在长文本中间。模型对提示词首部的注意力最强，角色词放在中间容易被后续内容稀释。

2.2 任务动词：生成、改写、总结、分类用的是不同的处理逻辑

提示词里最容易被忽略的部件是动词。同样是给一篇三千字的行业报告，你说“总结一下”和“帮我提炼出三个核心结论，每个结论配一条数据支撑”，模型执行的是两套完全不同的信息处理。前者默认输出一段概括，后者会被迫做筛选、归纳、对应。基础版 PDF 里不少模板效果差，问题就出在动词太抽象——“分析一下”“看一下”“处理一下”这类模糊动词，等于把任务定义权交还给了模型，它只好按最中庸的理解来答。

我习惯用一个对照思路来检查动词：这句话拿到现实里，你会安排给谁干？不同动词对应的处理逻辑差别很大：

一个提示词里最好只有一个主动词，辅助动作放到“要求”里。最常见的错误是把多个动词串在一起：“总结一下这份报告，然后找出问题，再给出建议。”模型会在三个任务之间平均分配上下文，每个任务都浅尝辄止。拆成三句、分三轮问，效果反而稳定。这个经验几乎适用所有对话模型，和模型本身的聪明程度关系不大。

2.3 输出约束：把格式、长度、风格写进提示词，不要憋在脑子里

输出约束是基础版 PDF 里最“卖货”的部分，也是用户最容易跳过的一部分。很多人觉得“模型应该知道我要什么格式”，但实际上模型的默认输出格式是 Markdown 加解释文字，它不会默认给你 JSON，也不会默认只给三句话。凡是输出格式能预定的任务，都应该把约束写到提示词里。

举个例子，我要让模型输出一个结构化的任务清单：

你是一名数据分析助理。 请把下面的会议记录整理成任务清单。 要求： 1. 每条任务以 "- [ ] " 开头，后面接任务描述。 2. 如果记录里有负责人姓名，在任务描述末尾用括号标注。 3. 不要输出任何解释文字，只输出清单本身。 4. 如果记录里没有任务内容，只输出一行：暂无任务。 会议记录： 【粘贴你的会议记录】

这个提示词的几个要点：第一条约束锁定了列表格式，第三条防止模型画蛇添足加“好的，我来整理一下”，第四条处理了边界输入。“如果……只输出……”这类的条件约束对模型特别有效，比“请务必注意”管用得多。原因是它给了模型一个明确的兜底路径，模型不需要自己猜。

常见的反面写法是“请输出一个格式良好的清单”。什么叫格式良好？模型觉得有解释、有编号、还有空行就是格式良好。约束条件的本质是降低模型的决策空间：你替它把选择都做了，它自然没有机会跑偏。长度和风格约束同理——“不超过150字”比“简短一点”有效，“口语化”比“活泼一点”有效。形容词是给人类看的，数字和具体格式才是给模型看的。

3. 三个高频场景的提示词写法：文案、代码、数据处理

骨架拆完了，这一章落到具体场景。基础版 PDF 里收录最多的是文案类模板，其次是编程和数据处理。这三个场景对应三种完全不同的约束重点：文案要管住风格和结构，代码要管住正确性和可运行性，数据处理要管住格式和幻觉。每个场景给一套可复用的提示词写法。

3.1 文案场景：从标题到正文的递进式提示词

文案是提示词使用最密集的场景。基础版 PDF 里文案模板数量最多，但最常见的问题是“一条提示词想干完所有事”——又要起标题，又要写正文，又要给三个版本，还要带情绪词。结果模型输出一条四不像。

我的做法是拆成两轮。第一轮定方向，第二轮出成品。给模型的信息越多，每一条具体约束留下的空间就越小，输出越可控。

第一轮：

你是一名小红书种草文案作者，擅长数码产品方向。 产品信息：某品牌的头戴式降噪耳机，主打通勤场景，卖点是降噪深度和佩戴舒适度。 请先不要写正文，只做两件事： 1. 列出这个产品在"地铁通勤"场景下的3个用户痛点。 2. 针对每个痛点写一个吸引人的标题，要求字数不超过18个字，口语化。

这一轮的价值在于：让模型先暴露它的理解，你再决定哪些方向是对的。模型列出的痛点如果和你预期不符，你现在改还来得及；如果直接生成正文，跑偏以后要花更多轮次纠正。

第二轮把选定的标题和痛点回填：

基于上面的3个痛点，请写一篇种草笔记正文。 要求： 1. 正文不超过150字，用短句，避免书面语。 2. 自然融入通勤场景的细节，比如地铁报站声、办公室午休。 3. 不出现"神器""绝绝子"这类夸张词。 4. 最后一行加一个引导评论的提问。

这里有一个容易被忽略的点：第二轮提示词里带上第一轮模型的输出，而不是只写“按上面的内容写”。模型上下文窗口里保有第一轮的对话历史，你可以直接说“按你刚才列出的第2个痛点来写”，但如果换了会话窗口，就必须把痛点原文复制进提示词。基础版 PDF 的用法里最坑的一点就是它会教你把模板套进新会话，却不提醒你把上下文也带过去。

3.2 编程场景：让模型输出可直接运行的代码

写代码的场景，提示词的核心诉求从“生成内容”变成了“约束正确性”。模型写代码最大的问题是：它默认生成的是“看起来对的代码”，而不是“能跑的代码”——变量名对不上、依赖没写全、边界条件缺失，都是模型的高频失误。基础版里编程类模板通常会教你在提示词里写“请用Python实现”，但这远远不够。

我常用的做法是把验收条件写进提示词：

你是一名Python后端工程师。 请实现一个函数：parse_access_log(log_path)，解析Nginx访问日志，统计每个IP的请求次数和总流量。 要求： 1. 只使用Python标准库，不要引入第三方依赖。 2. 函数签名、输入输出格式严格按题目定义。 3. 处理日志格式不匹配的行，跳过但不报错。 4. 输出的数据结构为字典，key是IP字符串，value是包含 count 和 bytes 两个字段的字典。 5. 不要解释实现思路，只输出代码，代码用 ```python 代码块包裹。

注意最后一条——很多人觉得让模型解释思路有助于理解，但在“需要直接落地的代码”场景里，解释生成的额外文本会干扰你复制粘贴，同时增加模型输出超长的概率。这一条约束在基础版 PDF 里很少被写全，因为模板作者假设你在使用时会删掉解释，但实际上大多数人不会删。

代码生成后的验证环节是另一个坑。我每次都会把模型生成的代码丢到一个临时目录里跑一遍最小用例，而不是直接贴进生产代码库。原因后面避坑章会展开：模型代码的翻车是概率性的，题越复杂越容易翻车，和模型档次无关。

3.3 数据处理场景：用提示词代替简单脚本

数据处理场景可能是提示词性价比最高的地方。很多临时性的数据操作——从一段乱糟糟的文本里提取结构化字段、把 Excel 导出的一列日期统一格式、把半结构化的聊天记录归类——写脚本要开环境、调依赖，而用提示词几分钟就完成。基础版 PDF 的数据类模板通常聚焦在“提取”和“转换”两种操作上。

一个实际的提取任务的提示词写法：

你是一名数据处理助理。 请从下面的原始文本中提取结构化的客户信息。 原始文本： 【粘贴原始文本】 要求： 1. 输出JSON数组，每个元素包含 name、phone、order_id、amount 四个字段。 2. 字段在原文中不存在的，置为 null，不要自行推断。 3. 如果原始文本包含多段类似记录，全部提取；不确定的记录不要输出。 4. 只输出JSON，不要加任何解释。

这里的第三条约束价值最高。“字段在原文中不存在的，置为 null，不要自行推断”直接堵住了模型最常见的幻觉来源；“不确定的记录不要输出”则防止模型把看起来像但实际不是的片段硬塞进结果。这两条是数据类提示词里最重要的防幻觉设计。

转换类任务的要点是给样例。你把“2019年3月5日”改成“2019-03-05”，给一对样例比描述十句规则都快。后面调优章会专门讲少样本示例，这里先记住一句话：数据类提示词里，一个真实样例的约束力大于任何形容词。

4. 提示词调优：温度值、少样本示例、迭代策略怎么定

模板写对了，输出质量的上限还要看几个外部参数和用法习惯。这一章讲三个最影响效果的维度：temperature 温度值、少样本示例、迭代策略。前两个是参数层面，第三个是使用习惯层面，三者叠加决定了同样一条提示词在不同人手里的差距。

4.1 温度值：稳定性与创造性的取舍

对话 API 里的 temperature 参数经常被忽略，但它是决定提示词效果的上限参数。温度值控制模型输出概率分布的随机程度：温度接近 0 时，模型每步都挑概率最高的词，输出稳定但机械；温度偏高时，模型会概率性地选择次优词，输出多样但容易跑偏。

下面是一个通过 API 调用模型的示意代码，用来演示温度参数的具体位置：

import requests, os # 示意代码：不同供应商的 API 结构基本类似 # 密钥从环境变量读取，不要硬编码在脚本里 api_key = os.getenv("LLM_API_KEY") endpoint = os.getenv("LLM_ENDPOINT") payload = { "model": "your-model-name", # 换成你实际可用的模型标识 "temperature": 0.2, # 0.2 用于稳定输出，如数据提取 "messages": [ {"role": "system", "content": "你是一名严格的数据提取助手，只输出JSON"}, {"role": "user", "content": "提取下面文本中的订单号和金额：【文本】"} ] } resp = requests.post(endpoint, headers={ "Authorization": f"Bearer {api_key}" }, json=payload) print(resp.json()["choices"][0]["message"]["content"])

提示：这段代码只是结构示意，具体字段名以你对接的供应商文档为准。关键要理解 temperature 这个参数的位置和取值逻辑，而不是照抄代码。

温度值的选取规则，我用一张表总结：

经验是：先按任务类型定温度，再调提示词。很多人顺序反了——提示词写得很好但温度偏高，输出依然飘，于是怀疑提示词有问题，其实改温度就能解决。

4.2 少样本示例：两个例子顶十句抽象描述

模型对规则的理解能力再强，也不如给它看两个具体的例子来得直接。少样本示例（few-shot）的基本套路是：任务描述 + 两个或三个输入输出对 + 新的输入。它的原理是让模型从例子中归纳出规律，而不是从抽象语言中猜测规则。

我在基础版 PDF 里看到过不少带示例的模板，但示例的质量普遍不高——示例和真实任务的形态差距太大，有的示例还是英文的，和中文任务混在一起，反而增加了模型的困惑。一个好的示例应该满足三个特征：

• 和真实输入同语言、同风格。
• 覆盖一个边界情况。例如“提取订单号”的示例里，放一个“订单号缺失”的对比例子，模型就能学会输出 null 而不是乱猜。
• 输出和输入的关系可以推断。不要让模型猜你为什么这么改。

一个实际的少样本提示词结构：

请将下面的日期统一转换为 YYYY-MM-DD 格式。 示例1： 输入：2023年8月15日 输出：2023-08-15 示例2： 输入：23年12月3号 输出：2023-12-03 示例3（边界情况）： 输入：日期未知 输出：null 现在转换： 输入：2019年3月5日 输出：

注意示例2的存在——它告诉模型“年”可以被简写，“号”要和“日”等价处理。这种覆盖过真实数据变化的示例，比在提示词里写“注意年份可能只有两位、日期可能用‘号’表示”管用得多。模型自己从例子里归纳的规则，比它照着你给的规则执行更不容易遗漏。

4.3 迭代策略：一次生成拉不齐，就分轮逼近

提示词不是一锤子买卖。对复杂任务，我的默认策略是三轮逼近：第一轮出结构、第二轮填内容、第三轮修表达。这和“一次生成完所有内容”的差别是根本性的，因为模型在长输出里保持一致性的能力是有限的，输出越长，中后段的逻辑越容易涣散。

拿写一份项目周报举例，三轮回合的拆法是：

第一轮：“你是一名项目经理。请列出本周周报的六个组成部分，每个部分用一句话说明该填什么内容。”——这一轮只产出骨架，不产出内容。

第二轮：“基于上面六部分，填入以下信息：【工作进展、遇到的问题】。每个部分控制在三句话以内。”——这一轮确保内容触达。

第三轮：“检查周报中是否有含糊表述，把‘基本上完成了’这类词改成具体描述。输出最终版本。”——这一轮是质量关。

每轮之间的对话历史是共享的，所以不需要把上一轮的输出复制进下一轮提示词。但如果中途新开了会话，就得把第一轮的骨架粘贴回来。这个细节我吃过亏：在某个模拟项目X里，我新开会话后只贴了原始数据就让它继续生成，结果模型按自己理解重建了一套结构，和第一轮完全对不上，整个周报前后矛盾，白白浪费一个小时。血泪经验总结成一条：轮次之间的上下文连续性，比提示词本身还要重要。

5. 提示词避坑指南：五个高频翻车现场与解决路径

这一章写基础版 PDF 使用中最常出现的五个坑，每一条都是“现象 → 原因 → 解决”的结构。前四条是模型行为层面的坑，第五条是模板使用习惯层面的坑。遇到过的人看完会心一笑，没遇到的建议直接存档。

5.1 幻觉数据：模型一本正经地编造结果

现象：在数据提取或事实问答类任务里，模型输出内容看着完全合理，字段齐全、数字精确，但原文里根本没有这些信息。比如要求提取合同金额，模型直接生成了一个金额数字，格式标准、位置合理，就是原文里不存在。

原因：模型生成长文本时注意力会衰减，当它“猜不出”答案时，会倾向于用概率最高的词补齐空缺，而不是承认缺失。这是模型架构决定的，不是提示词写错了。

解决：把“不确定就输出 null”写进提示词，同时要求模型从原文引用关键片段作为依据。做法是在提示词里加一条：“每个提取的字段必须附上原文片段，找不到原文片段的字段输出 null。”这样模型被迫进行核对动作，幻觉率会明显下降。如果任务允许，还可以让模型先输出“数据来源行号”，再做汇总，双重校验。

5.2 上下文超限：提示词越长，模型越懵

现象：把一份几百页的文档直接贴进提示词，或者把几十条要求堆叠在一起，模型开始丢三落四——前文提到的要求后面忘了，中间部分的内容被忽略。

原因：模型的有效上下文虽然看起来很大，但注意力不是平均分配的，长文本的中后段会被“稀释”。提示词堆得太满，等于让模型在噪音里找信号。

解决：拆分任务，一次只处理一段数据；把主要要求放在提示词头部和尾部——模型对开头和结尾的记忆通常强于中间。另外，长文档优先用“分段处理 + 汇总整合”的流程，不要指望一次全塞进去。我处理超过十页的资料时，会先让模型对每一段各产出一段摘要，再让模型基于这些摘要做全局分析，比一次性贴全文稳定得多。

5.3 格式漂移：要求输出 JSON 却混进解释文字

现象：提示词写了“只输出JSON”，模型还是先来一句“好的，以下是提取结果：……”，或者在JSON后面补一段说明。放进脚本里解析直接报错。

原因：模型训练数据里“先说明再输出”是常见模式，仅仅一条“只输出JSON”的约束不够强，它把说明性文字当成了正常行为的一部分。越是偏对话训练的模型，这个习惯越顽固。

解决：把约束变成双重表达：“只输出JSON，不要输出任何其他文字、不要解释、不要使用Markdown代码块。”同时把后续的解析逻辑设计得更宽容——解析时先截掉第一个“{”到最后一个“}”之间的内容，而不是直接加载整个输出：

import json # raw_text 是模型返回的内容 # 防御性解析：去掉模型可能附加的解释文字 start = raw_text.find("{") end = raw_text.rfind("}") if start != -1 and end != -1 and end > start: candidate = raw_text[start:end + 1] try: data = json.loads(candidate) except json.JSONDecodeError: print("解析失败，检查模型输出是否包含非法JSON") else: print("未找到JSON对象，检查提示词约束")

做一层防御，比赌模型每次都遵守格式可靠得多。这个习惯在批量任务里尤其重要，一次格式漂移会中断整条流水线。

5.4 约束打架：既要简短又要全面，模型两头不讨好

现象：提示词里同时出现“控制在50字以内”和“覆盖所有要点”两条互斥要求，模型的输出要么是压缩到只剩帽子的50字，要么是忽略了字数限制的长文。用户看到哪个都觉得不对。

原因：约束之间的优先级没有写明，模型无法判断哪条更重要，只能自己折中，而折中通常两边都不讨好。

解决：在提示词里显式指定优先级。例如“字数控制在50字以内是硬性要求，如果信息有冲突，只保留最重要的三条”。给模型一条决策路径，比让它自己权衡可靠得多。这个原理和 2.3 的条件约束一脉相承。凡是出现两个方向相反的要求，都先问自己：哪个是必须满足的？把它标成硬性要求。

5.5 模板僵化：换个场景，模板直接失效

现象：同一个模板，在 A 场景输出漂亮，换到 B 场景立刻水准大跌。很多人在这个时候骂模型，其实是模板的问题——模板里隐含的角色定位、示例风格、约束条件都是为 A 场景量身定做的。

原因：基础版 PDF 的模板高度特化。“为科技产品写种草文案”的模板拿到家居品类可能还行，拿到法律咨询场景就完全不对。模型发挥的是语料分布，模板一旦脱离了匹配的语料域，输出自然变形。

解决：改模板的时候先动角色词和示例，再动约束条件。把角色从“科技产品文案”改成“家居产品文案”，把示例换成家居品类的，保留结构不动。我习惯在模板里标注哪些部分随场景替换、哪些部分是骨架——这个标注习惯比模板本身更有价值。改完之后用一个小样本集做验证，至少跑三个不同输入再确认能用。

6. 把提示词沉淀成自己的资产：模板库、版本对照和验证习惯

基础版 PDF 是别人的资产，你从里面拆出来的骨架和改过的模板才是你自己的。最后一章讲怎么把手头的东西变成可持续复用的工具。我的做法是建立一个纯文本的模板库，每个模板一行元信息加一个正文，周期性地做版本对照。模板文件用统一格式记录：模板名称、适用场景、角色词、任务动词、输出约束、失败记录。其中失败记录是最关键的部分，因为它是模型真实行为的反馈，也是基础版 PDF 永远不会给你的信息。

版本对照具体怎么操作：每次改过的提示词，不覆盖原版，而是另存一个文件名带版本号的副本。我用日期加序号区分，比如prompt_copywriting_20250112_v3.txt。改了什么、为什么改，写在文件头部注释里。这条习惯让我的模板库在半年后还能追溯，不会出现“我记得这个模板改过但不知道改了什么”的情况。

验证习惯是模板投入复用前的最后一道关。我要求自己每个模板至少跑三个输入：一个正常输入、一个边界输入、一个异常输入。正常输入确认稳定产出，边界输入比如空文本、超长文本、格式错乱的文本，异常输入则是完全不该匹配的场景。三条都过了才放进常用模板目录；没过就补约束，继续验证。这个过程看起来麻烦，但比每次现写提示词快得多。翻车记录多了以后你会发现，一个模板花十分钟验证，能省下后面几十次的反复调试。

收尾说一个习惯：遇到任何输出异常，我现在的第一反应不是“换提示词”，而是“看上下文里有没有残留内容”。大量所谓的提示词失效，其实是历史对话里的旧输出污染了新一轮的判断。清空会话、把干净的输入跑一遍，往往问题就消失了。这个教训花了我不少时间才养成，希望帮到你。

本文还有配套的精品资源，点击获取