企业官网建设流程全解析

我正式研究提示词工程，是从一次发布翻车开始的。那时候我让 AI 帮忙起草一份给客户的软件更新说明，结果它洋洋洒洒写了一千多字，翻来覆去全是"全新升级、体验优化、功能增强"这类放之四海皆准的废话。那一刻我意识到，问题不在模型，而在我的提问方式。后来我花了很长时间把各种公开方法和自己踩坑总结的技巧整理成一套打法，也就是这篇文章要分享的 10 个提示词工程技巧。每个技巧都配了可以直接抄的写法和模板，文章末尾还有一个分类模板库，适合所有正在跟提示词打交道、想把 AI 输出质量稳定拉高的朋友。

1. 先别急着写提示词：三个影响效果的关键误区

技巧之所以能起作用，前提是你没踩进最常见的三个坑。我见过太多人拿着同样的问题去问模型，效果差得离谱，最后全甩锅给"模型不行"。其实拉开差距的往往不是工具，而是提问前的基本功。

1.1 误区一：把提示词当搜索框，问完就走

很多人习惯把大模型当搜索引擎用，上来就是"帮我写个方案""帮我总结一下报告"，然后期待输出的内容能直接用。搜索引擎没给够关键词也能给个大致结果，因为它是靠关键词匹配去捞现成页面；但大模型不一样，它做的是概率预测——根据你的输入去推断你心里最想要的那个答案。输入里信息越少，它能依赖的就只剩训练数据里的常规套路，于是它只能给你一个"任何场景都能套、任何场景都不精准"的平均答案。

这就像你请一位外包设计师做海报，需求只给一句话"帮我设计个海报"，他真没法知道你要的是电商大促风还是极简性冷淡风，最后只能交个通用模板应付。问题不在设计师，在需求文档太薄。提示词工程的第一步，就是把自己从"搜一下"的心态切到"写需求文档"的心态：你想让模型做什么、为谁做、做到什么程度，先想清楚再敲回车。

1.2 误区二：指令太空，模型只能靠猜

"写得专业一点""语言生动一些""做个好看的排版"，这类话都属于无信息量指令。什么叫专业？什么叫生动？模型其实没有你的判断标准。它可以往学术论文方向写，也可以往商务报告方向写，两个方向都算"专业"，但显然不是你脑子里那个版本。

要让模型不再靠猜，你得把模糊形容词翻译成可衡量的标准：篇幅多少字、目标读者是谁、什么语气、分几个模块、需要包含哪些信息点、必须避免什么。举个例子，你让 AI"改一下这句话让它更专业"，远不如给它这样的指令："把下面这段产品说明改写为给企业采购人员看的版本，保留核心参数，删掉夸张形容词，语气克制中性，输出 3 个版本，每个不超过 120 字。"后者的输出基本可以直接用，前者往往是在碰运气。

1.3 误区三：一次成型心态，缺少迭代意识

第三个坑是心态问题。很多人默认提示词和数学公式一样，写完必须一步到位。一旦输出不理想，就得出"这 AI 不行"的结论。但实际上，提示词更像代码——写完第一版能一次通过的概率很低，大部分时候需要反复调试：改措辞、补例子、加约束、换拆解思路，才逐渐逼近理想输出。

我习惯用一个类比：写提示词就像给同事布置任务。你说了一遍对方理解偏了，正常的做法是再解释清楚一点，而不是甩下一句"你能力不行"就走人。模型也是一样，第一次没做对，就换一种方式重新表达。把"一次成型"的执念换成"快速试错、逐步收敛"的思路，后面那些技巧才能派上用场。

2. 技巧 1-3：定角色、抠动词、把信息前置

前三招属于提示词的地基，决定了模型以什么身份、执行什么动作、基于什么信息开始思考。地基打正了，后面的进阶技巧才有意义。

2.1 技巧 1：角色锚定

给模型预设角色，本质上是在"修剪"它的输出空间。大模型的训练数据覆盖了百科、小说、新闻、代码、客服记录等无数语域，你不给它角色设定，它输出的是所有语域的平均值——哪个领域都沾一点，哪个领域都不够地道。但一旦你告诉它"你是一名有 8 年前端开发经验的工程师"，它就会自动偏向技术语域，输出里会多一些工程化的思考方式和行业黑话。

角色设定有一个关键细节：不能只说"你是专家"，越具体越好。同样是产品经理，写"你是一名负责中小商户收银软件的产品经理"比"你是一名产品经理"要强得多，因为前者会在输出时主动代入"商户的真实使用场景"和"产品迭代的表达习惯"。

看个对比就明白了。基础版提示词是"请帮我写一个版本发布说明"，模型给你的大概率是功能罗列，毫无重点。改进版是"你是一名有多年经验、负责维护一款面向中小商户收银软件的产品经理，现在要为即将发布的 v3.2 版本撰写一份给终端商户的更新说明。"后者的输出会自动带出商户关心的点，比如操作界面变化、对日常收银的影响、是否需要重新配置，而不是一堆空泛的功能名词。

模板骨架我放在这里，你可以直接套：

你是一名[角色]，拥有[具体经历/专长]。现在请你[任务]，服务于[受众]，最终输出用于[用途]。

每个方括号都逼着你补全信息，写完整理完，提示词的质量已经超过一半的人了。

2.2 技巧 2：动词驱动的任务指令

模型对精确的动作动词更敏感。"总结、改写、翻译、对比、分类、排序、解释、举例"这些词，比"处理一下""写一写""弄一下"明确得多。同一个任务，动词选得不对，输出结构会完全跑偏。比如"解释一下什么是微服务"和"给微服务举个生活中的例子"，前者要求逻辑说理，后者要求具象映射，模型会给出完全不同的两类答案。

这里有一份我常用的动词速查表，写提示词时对着挑一个主动词就够了：

一个提示词里建议只保留一个主任务动词。如果你想让它做多步操作，不要用"然后"一笔带过，而是用编号明示步骤："1. 先用 50 字总结原文；2. 再列出三个可能的风险；3. 最后给出应对建议。"明确的主动词加上编号步骤，模型就跟接到了带排期的任务单一样，很少会漏环节。

2.3 技巧 3：信息前置

提示词的排版顺序，直接影响模型对信息的权重分配。从注意力机制的特性来看，出现在前文的内容会在后续生成中占据更高的语义权重。也就是说，重要的背景、约束和上下文，应当尽量往前放，不要藏在长提示词的最后。

一个我反复验证过的高效结构是四段式：

[背景信息]：产品是收银软件，目标用户是中小商户，本次更新新增库存预警功能。 [约束条件]：全文不超过 300 字，不使用技术术语，语气口语化。 [任务指令]：撰写一份面向商户的版本更新说明。 [输出格式]：分三段：本次更新内容、操作变化提醒、常见问题。

模型的注意力从一开始就被锁定在"给中小商户写口语化说明"这个语境里，后面的输出自然不容易跑偏。我看到很多人习惯把任务写在最前面、背景信息反手丢在最后面，这种写法不是不行，只是模型的注意力已经被前几个字带偏了，后面的背景信息很难再拉回正确的语义场。实测下来，信息块前置的提示词，返工率能少一半。

3. 技巧 4-6：示例、思维链、任务拆解，把输出质量再拉高一档

如果你已经能把指令说清楚了，接下来要解决的是"听懂归听懂，输出不够好"的问题。这个时候需要上场的是少样本示例、思维链和任务拆解。

3.1 技巧 4：少样本示例（Few-shot）

有时候光用形容词描述你要的风格，说破嘴皮子也不如直接给模型看一个标准答案。少样本提示就是在提示词里塞入少量输入-输出示例，让模型照着示例的格式和调性来生成。示例的价值不只是示范结构，更在于传达那些"只可意会不可言传"的标准——比如句子的颗粒度、转折词的用法、口气是克制还是热情。

举个例子。你可以在提示词里先放一个参考：

「v2.8 更新说明： 本次更新主要解决两个问题：一是修复了导出报表时偶发卡死的问题；二是新增了按日筛选报表的功能。使用上有一点变化——报表默认改为最近 30 天数据，如需查询更早数据，请在筛选器中自行选择。」

请模仿这段的风格，为 v3.2 撰写更新说明。

模型看过这个参考之后，会本能地模仿"先总说目的、再分点说明、每一条都点出对用户的影响"这个套路。比你在后面加十句"写得具体一点"都管用。

这里有个进阶技巧：如果能给一正一反两个示例，效果会更好。先给出你想要的写法，再补充一句"不要写成这种风格：『本次版本华丽升级，为您带来前所未有的流畅体验』"，正反面对齐之后，模型的收敛速度会明显加快，基本两轮以内就能稳定在你想要的风格上。

3.2 技巧 5：思维链（Chain-of-Thought）

当你问模型一个需要推理的问题，直接要答案往往容易出错。原因很简单：模型在跳步，它省略了中间的推理过程，直接从问题跳到结论，中间一旦有一步"想当然"，结论就不可靠了。思维链提示的做法是要求模型先展示推理过程，再给出最终结论。

实操写法就是在提示词末尾加一句：

请一步一步思考，先列出你的推理过程，再给出最终结论。

我举个例子。如果我问"这次功能更新会不会引发商户咨询量上升"，模型可能直接答"会有一定影响"这种不痛不痒的话。但如果要求它先列举"更新了哪些功能 → 哪些功能改变了商户的既有操作习惯 → 习惯改变最容易引发什么疑问"，再综合判断，它给出的回答会细致得多，甚至能预判出"库存预警阈值设置"这种具体咨询点。

不过思维链也不是每次都要用。我的原则是看任务难度：简单改写、格式转换这类任务不需要思维链，加上去反而拖沓；涉及逻辑推理、多因素权衡、长文本规划的任务，才值得启用。

3.3 技巧 6：分步拆解（Task Decomposition）

一个提示词里塞太多要求，模型就容易顾此失彼，写完开头的两个要求，把后面的要求忘个干净。与其让它一口气完成一个巨型任务，不如把它拆解成几个可控的步骤。

拆解有两种实现方式：

一种是在同一条提示词里用编号定义步骤。比如"1. 先列出这篇文章的大纲；2. 根据大纲写一个 300 字摘要；3. 最后给出 5 个备选标题。"这种方式适合步骤不多、顺序明确的场景，模型会按编号逐步执行，结构感很强。

另一种是把任务拆成多条独立的提示词，每条完成一个子任务。比如写一篇深度调研报告，可以先让模型生成大纲，你审完大纲再让它逐节展开，最后单独让它做整体润色。这种多轮方式的优势是每个关键节点都有人工检查，单步输出质量更可控，代价是流程变长、往返变多。

我的建议是：能拆成编号步骤的任务，优先用一条提示词搞定；需要在关键节点人工把关的重度任务，再走多轮拆解的路线。真实工作里两者经常混着用，同一个项目里大概率两个都出现过。

4. 技巧 7-8：管得住格式、划得出边界，结果才能直接用

前六个技巧解决的是"内容对不对、好不好"的问题，接下来的两个技巧解决的是"输出能不能直接用"的问题。说实话，后者在工作中往往更关键。

4.1 技巧 7：结构化输出

当模型输出要进入后续流程——导入表格、程序解析、作为素材入库——你就必须对输出格式做硬性约束。常见的约束形式包括 Markdown 表格、JSON、CSV、带编号的层级标题等。

举个例子，我想让模型把产品需求转成结构化字段，可以直接这么写：

请把下面的产品需求转换为 JSON 格式，字段包括：feature_name、target_user、problem、solution、priority。 只输出 JSON 对象，不要加任何其他文字。

模型返回的结果大概是：

{ "feature_name": "库存预警", "target_user": "商户店长", "problem": "库存不足时无法提前补货，导致缺货", "solution": "当库存低于阈值时在首页推送预警，并给出建议补货量", "priority": "高" }

这类提示词在自动化工作流里几乎是必需品。有一点需要特别提醒：不同模型的输出稳定性有差异，如果这个 JSON 要直接交给程序解析，一定要在末尾加上"只输出 JSON 对象，不要加解释文字"，否则模型经常会在 JSON 前后补一句"以下是转换结果"，导致解析报错。这是我在自动化脚本里踩过好几次的坑。

4.2 技巧 8：负面约束与边界划定

很多人写提示词只写"要什么"，不写"不要什么"。但实际上，给模型划定边界、明确排除项，能有效防止它跑偏。模型在生成时看到"不要做 X"的指令，至少会降低 X 的出现概率，所以正确用法是正面要求和负面约束组合出击。

负面约束必须具体，抽象词没有用。你说"不要啰嗦"，模型不知道你眼里的啰嗦是什么样。你应该说"不要重复前面已经提到的功能点，条数控制在 5 条以内"。你说"不要用营销话术"，不如说"不要出现'一键直达、极致体验、超值钜惠'这类词"。

我特别推荐一个通用约束，几乎在所有总结类任务里都能生效：

如果原文中没有提到的信息，请明确说"文档中未提及"，不要自行补充。

这一句话就能大幅减少模型在总结时编造细节的冲动。对内容安全要求高的场景，我会再加一行"只基于给定资料回答，不引用外部知识"，边界立刻清晰很多。

5. 技巧 9-10：像工程一样迭代提示词，而不是靠感觉

前面八个技巧针对的是单次提示词的编写，最后这两个技巧则关乎长期能力——怎样把一次的成功经验沉淀为可以反复调用的资产。

5.1 技巧 9：单变量迭代

大多数人调整提示词的方式是"凭感觉重写"，输出不理想就整段换掉。这样做最大的问题在于，你永远不知道到底是哪个改动起了作用。今天加了角色设定、换了动词、又补了一个示例，输出确实变好了，但你无法判断是角色起作用，还是示例的功劳。

我建议用做实验的思路来写提示词：一次只改一个变量。给提示词做版本管理，v1 是什么样、v2 改了什么、对应输出发生了什么变化，全部记录下来。时间长了，你会积累出一张宝贵的对照表：

这样做虽然比"整段重写"稍微慢一点，但每一步都在积累可复用的判断力。调过几十次之后，你会形成一种直觉：看到输出哪里不对，就知道该去动提示词的哪个位置——改上下文还是换示例，而不是盲人摸象。

5.2 技巧 10：把成功案例沉淀成模板库

跑通一个提示词之后，别让它躺在聊天记录里吃灰。把里面的具体信息抽象成占位符，它就能变成一个跨场景复用的模板。比如"你是一名专门负责维护中小商户收银软件的产品经理"可以抽象成"你是一名[岗位]，专门负责[业务描述]"，下次换一个行业、换一个任务，照样能套进去。

我自己的提示词管理文档长这样：每个模板包含场景说明、模板正文、适用模型、注意事项四个字段。场景说明让我在需要时能快速检索到正确的模板，适用模型提醒我同一个模板在不同模型上的表现差异，注意事项则记录那些踩过的坑，比如"这个模板需要配合思维链使用，否则结论太跳"。

模板化带来一个隐形收益：提示词工程的经验可以跨任务复制。你为一个场景辛苦调试出来的结构，往往只需要替换几个变量，就能服务另一个完全不同的场景。积累模板库的速度越快，你在新任务上的起点就越高，这是我从开始做提示词管理以后体感最强的一点。

6. 模板库：拿来就能改的 10 组提示词模板

最后把我常用的模板整理出来，按场景分好类。使用方式很简单：复制模板，替换方括号里的变量，根据实际需求微调。模板不可能覆盖所有场景，但作为起点，它们能帮你省掉大量的试错时间。

6.1 文案创作类

产品发布说明模板：

你是一名[岗位]从业者，负责[产品名]的对外沟通。请为[本次版本号]撰写一份给[目标受众]的更新说明。 要求：先说本次更新的核心目的，再分点列出用户能感知的变化，最后给出操作注意事项。 全文[字数]字以内，不使用[禁用词]，语气[语气描述]。

公众号推文开头模板：

请为以下主题撰写一个公众号推文开头，要求前两句话抓住读者注意力，第三句话自然引出文章主题。主题是[主题]，目标读者是[人群]，文章后续将讲述[核心内容]。请给我 3 个不同风格的开头版本。

6.2 学习阅读类

文献精读模板：

你是一名严谨的学术助理。请帮我精读下面这段材料，按顺序输出：1. 核心论点；2. 支撑论据；3. 论证方法的局限性；4. 与我提供的背景问题[背景问题]的关联。 只基于材料内容回答，材料中没有的信息写"未提及"，不要补充外部知识。 材料如下： [粘贴材料]

费曼解释模板：

请用"给完全不懂这个领域的朋友讲清楚"的方式解释[概念]。要求：1. 先用一句话给出核心定义；2. 再用一个生活化类比说明；3. 最后指出这个概念的常见误解。总字数[字数]字以内，不要使用术语堆砌。

6.3 数据分析与决策类

会议纪要转待办模板：

请把下面的会议纪要整理成待办事项列表。每条待办包含：负责人、事项描述、优先级、截止时间。如果纪要中没有提到某个字段，写"待确认"。尽可能保持原意，不要新增纪要中不存在的任务。 会议纪要如下： [粘贴纪要]

方案对比模板：

请对比以下两个方案，从成本、耗时、风险、效果四个维度分析，给出对比表格，最后给出你的推荐及理由。注意：推理过程要完整，明显权衡之后再下结论。 方案 A：[描述] 方案 B：[描述]

6.4 程序开发类

代码审查模板：

你是一名资深[编程语言]工程师。请审查下面这段代码，按严重程度从高到低列出问题。每个问题包括：问题描述、可能引发的后果、修改建议。只在确有把握时提修改建议，不确定的问题标注"待确认"。 代码如下： [粘贴代码]

报错诊断模板：

我在运行[项目描述]时遇到以下报错，请根据报错信息推断可能的原因，按可能性从高到低列出排查步骤。如果信息不足，请指出还需要提供哪些信息，不要猜测。 报错信息如下： [粘贴报错]

6.5 通用输出类

结构化总结模板：

请从以下角度总结这段内容：背景、核心观点、关键数据、结论、可执行动作。每个角度不超过[字数]字。只基于原文，不要补充外部信息。 内容如下： [粘贴内容]

多版本改写模板：

请把下面这段文字改写成 3 个版本：版本一，正式书面版；版本二，口语沟通版；版本三，社交媒体版。每个版本控制在[字数]字以内，保留原文核心信息。 原文如下： [粘贴原文]

模板与模板之间还可以互相嵌套。比如把"结构化总结模板"和"费曼解释模板"叠加，就能得到一个既能精炼信息、又能把信息讲通俗的组合，在给非技术背景的同事解释复杂技术时非常好用。

从我个人的实操体会来说，提示词工程真正难的不是背技巧，而是建立"先想清楚再动手写"的习惯。每次写之前花两分钟想清楚：受众是谁、要什么格式、有哪些硬性约束、需要用例子还是用步骤。这个习惯一旦养成，输出质量的提升是很直观的。另外不同模型的差异确实存在，同一个模板在不同模型上的表现可能差不少，我的做法是在模板库里记录每个模板测试过的模型版本，实测通过后再放心推广。希望这 10 个技巧和模板库，能帮你少走一些我走过的弯路。