企业官网建设流程全解析

做提示词工程这两年，我最大的感受是：大多数人在写提示词的时候，不是在"工程"，而是在碰运气。同一个模型，换一种问法，输出质量可以天差地别。有人把这归结为模型随机性，但我见过太多人把本来可控的方差归因于玄学，这很可惜。提示词工程完全是可学习、可验证、可积累的，关键是要把它当需求规格说明书来写，而不是当聊天话术。这篇文章把我自己在真实项目里反复验证过的10个技巧全部摊开讲，每条都会给出可复制的模板和必要的参数说明，最后还会送你一套可以直接改用的模板库。

1. 先纠正一个误读：提示词工程不是"话术"，是需求规格

1.1 同一个模型，为什么换一种问法结果完全不同

先举个最典型的例子。你让模型"帮我写一份周报"，它大概率会给你一份泛泛而谈的模板，看起来什么都对，但没什么用。如果你换一种方式："你是项目A的负责人，本周完成了登录模块开发、修复了3个线上bug、和设计组对完了新版首页原型，请用业务负责人的口吻写一份周报，包含已完成事项、风险与求助、下周计划三部分，每部分不超过3条。"输出质量会完全不一样。

这不是玄学，而是信息密度不同。模型在生成每一个token时，依赖的都是上下文里可用的信息。上下文里对背景、角色、格式、约束的说明越充分，它可选的高概率token就越集中在你想要的方向上。换句话说，prompt写得越像一份需求规格说明书，模型就越像一个按需交付的开发团队；prompt写得越模糊，模型就只能用通用的、安全的、正确但平庸的方式来回应。

我在实际项目中见过太多人抱怨模型"笨"或者"不听话"，但把对话记录翻出来，往往发现需求本身就含糊不清：没有背景、没有受众、没有格式要求、没有验收标准。这和团队里接需求是一样的，需求写不清楚，开发做出来的东西自然不是你要的。提示词工程不是要把话说得多华丽，而是要把话说得多明确。

1.2 三个底层机制：上下文、注意力与概率生成

要真正理解提示词工程，不需要读论文，但至少要建立三个朴素的直觉。

第一，模型是在预测概率分布。每个token的生成都基于前面所有内容，所以"前面所有内容"的质量直接决定后续生成质量。这也是为什么把关键约束放在开头、反复强调重要信息是有用的，因为它参与了每一次概率计算。

第二，注意力不是均匀分布的。模型在生成时会关注上下文里的关键片段。你把需求拆成编号列表、把核心限制单独提行，本质上是在帮注意力机制快速定位关键信息。这就像面试时你把简历里的重点加粗，面试官才能一眼看到你的亮点。

第三，输出是逐token累积的。如果模型在第三步就已经跑偏，后面会沿着这个偏差点越走越远。所以任务拆解、分步执行这类技巧的底层逻辑，就是尽早暴露偏差，避免后期不可收拾。

这三个直觉合在一起，会改变你写prompt的习惯：你会开始关心信息结构、关键信息的位置，以及每一步的生成风险。你也会明白，为什么有时候把同样的内容换一种排列顺序，效果会差很多。

1.3 什么场景才值得认真设计提示词

不是所有使用场景都需要提示词工程。如果只是闲聊、头脑风暴，那随意提问反而有助于生成多样性。但以下三类场景，我建议一定要认真设计：

• 重复执行型：同一类任务要反复做，比如每周生成周报、每天生成内容摘要，值得花时间打磨一份可复用模板。
• 输出稳定性要求高：自动化流程里要解析结果、要直接对外发布的内容，必须把格式和语义边界卡死。
• 复杂任务：需要多步推理、多条件约束的方案设计、代码生成、数据分析，一次说清楚能省下大量修正成本。

判断标准很简单：如果改进prompt节省的时间，大于你设计prompt的时间，就值得做。大多数人其实是反过来的，宁可花40分钟在对话框里反复纠正，也不肯花10分钟把需求写清楚。

2. 技巧1-4：先把结构立起来，输出就不会跑偏

第2章要聊的四个技巧有一个共同点：它们都发生在模型生成之前，解决的是"边界在哪"的问题。很多人在对话里反复纠正模型，本质上是没有提前把边界说清楚。结构类技巧的作用，就是让模型从一开始就知道自己该在什么范围内工作。下面四条，按使用频率从高到低排序，其中输出结构约束是我在自动化流程里用到最多的。

2.1 角色设定：不只是"你是一个专家"

很多人知道要加角色，但只写"你是一个专家"基本没用，因为它太宽泛了。有效的方式是给角色补上两个信息：擅长什么，在什么背景下工作。

你是拥有10年经验的DevOps工程师，擅长CI/CD流水线设计、云原生架构和故障排查。 背景：我们团队正在从传统虚拟机部署迁移到Kubernetes。 任务：请给出迁移过程中的3个主要风险点及应对方案。 要求：用你实际操盘迁移项目的经验来写，避免教科书式回答。

角色设定的本质是给模型一个先验框架。它一旦进入这个框架，术语体系、判断标准和表达风格都会向特定方向偏移。比如上面这个prompt里，"避免教科书式回答"就是在框架之上再追加一个风格约束。

实测中要注意一个反向问题：角色设定过强会牺牲灵活性。有一次我让模型扮演"严格的技术审查员"来做方案设计，结果它对所有创意方案都持否定态度，导致输出失去了开放性。所以角色设定要跟任务匹配：需要严谨判断时用严格角色，需要发散创新时用开放角色。

2.2 任务拆解：把大任务变成子步骤，尽早暴露偏差

模型处理大任务时最容易出现"前半段还行，后来越写越空"的问题，原因是上下文里细节被稀释了。任务拆解能有效对抗这个问题。

请分四步完成以下任务： 第一步：列出该主题的核心受众与他们的主要困惑。 第二步：基于困惑，给出3个候选大纲。 第三步：从3个候选中选1个最优的，并说明理由。 第四步：按最优大纲撰写完整文章。 每一步完成后，先输出这一步的简短结论，再进入下一步。

这个模板里有几个容易被忽略的设计。一是"每一步完成输出结论"，这是故意的，为了让模型的中间结果外显，让你能在早期发现方向错误，而不是等全文生成完才后悔。二是"说明理由"，这强制模型进行元认知，通常会让选型更合理。

任务拆解也不是越细越好。拆到模型可以一步完成的粒度即可，一般3到5步比较合适。拆得太碎反而会让输出变得机械，丢失整体性。我见过有人把一篇文章拆成20个步骤，结果每段之间像拼凑出来的一样，没有连贯的逻辑线。

2.3 输出结构约束：用格式把结果卡死

在实际项目里，输出结构约束是性价比最高的技巧之一，尤其是在要接后处理流程的场景。比如你写了一段抓取新闻摘要的工作流，最后需要把结果存成结构化数据，那就不应该让模型自由发挥，而是要告诉它输出JSON。

请分析以下文章，并输出JSON格式，字段如下： { "title": "文章标题", "summary": "不超过50字的摘要", "key_points": ["要点1", "要点2", "要点3"], "tone": "整体语气，可选值：客观/积极/批评/中立", "risk_level": "风险等级，可选值：高/中/低" } 文章：{文章内容}

这种提示词的核心是把输出schema说清楚，包括字段名、类型、可选值范围，甚至要不要换行、用不用引号。你定义得越具体，解析代码就越简单，出错概率就越低。我在一个自动化项目中就遇到过这种情况：早期没要求纯JSON输出，模型经常在JSON前后加一句"这是您要的结果"，导致解析脚本频繁报错。后来在prompt里加了一句"不要输出任何解释性文字"，解析成功率从不到80%提升到接近100%。

对于普通写作，也可以用结构约束：要求分小节、每小节有标题、每部分限定条数。比如"每部分不超过3条"这种数量约束，比"要简洁"这种抽象词有效得多。因为数量是可检查的，模型在执行时有一个明确的边界。

2.4 少样本示例：两个"标准答案"比解释一百句管用

有时候你很难用语言描述清楚"我要什么样的输出"，但你手头有几个好例子。这时候就使用少样本示例策略，把输入和输出成对放入prompt。

请参照示例，对输入文本进行意图分类。 示例1： 输入：明天下午三点把合同送到前台 输出：安排任务 示例2： 输入：这个月报销什么时候到账 输出：查询进度 请分类以下输入： 输入：麻烦帮我查一下最近一笔订单的物流 输出：

少样本示例的底层逻辑是让模型直接从输入输出对中归纳映射关系，这往往比抽象规则更直接、更少歧义。示例也不需要多，2到3个高质量示例通常就够了，关键是要覆盖不同情况，最好包含一个边缘情况，帮模型理解边界。

这里我踩过的一个坑是：示例和实际输入差异太大。比如示例都是短句，实际输入是长文本，模型就容易不知所措。所以要尽量保证示例与目标任务在风格和复杂度上接近。在构建示例时，我一般会把最常见的两个情况加一个边界情况放进去，比如一个正常样本、一个拒绝回答样本、一个包含特殊字符的样本。

3. 技巧5-7：让模型多"想几步"，质量立刻不一样

第2章聊的是结构，现在聊深度。这组技巧的共同点，是让模型在生成最终结果前多花一点推理成本，很多表面上看起来"模型不会"的问题，其实是它"跳步跳得太快"。在处理复杂任务时，这组技巧往往比单纯增加提示词长度更有效，因为它们针对的是模型的推理深度，而不是信息覆盖度。

3.1 思维链提示：把推理过程显式化

很多人在让模型做推理题时，直接问"请回答"，模型容易跳步、结论可疑。但如果你要求模型先把推理过程写出来，它的表现会明显提升。

请一步步思考并展示推理过程： 某商品原价800元，先涨价20%，再打八折，最终价格是多少？

思维链有效的原因不复杂：模型每一步的生成都基于当前所在的语境，如果它先把中间运算写出来，后面的每一步都在这些中间结果上继续，累积误差就会变小。这就像做复杂计算时，你在一张草稿纸上写清楚每一步，而不是全靠心算，出错概率自然低得多。

这里有一个实用细节：如果你担心输出太长，可以用"先简要列出关键推理步骤，再给出结论"的方式，而不是要求输出满篇的内心独白。实际项目里，思维链在数学题、逻辑判断、竞品分析这类需要多步推导的任务里效果尤其明显。但在简单分类任务里就没必要用，反而浪费token，还会把简单问题复杂化。

3.2 背景锚定：把关键约束放在上下文前面

上下文窗口是有限的，而且模型在长上下文中会"遗忘"中部信息，这种现象有时被称为lost in the middle。所以，重要信息的位置比你想象的重要。

背景信息： - 项目名称：智能家居控制平台 - 目标用户：25-40岁、有一定技术接受度的家庭用户 - 核心约束：必须支持离线语音控制、只兼容主流智能家居协议 - 禁止事项：不支持云依赖方案 请基于上述背景，设计一个用户引导功能的实施方案。

把关键约束放在上下文最前面，等于在模型生成的每一阶段都提供一个锚点。尤其是"禁止事项"，很多模型生成到一半就忘记了，把它放在开头并单独成行，约束力会强很多。

之前做一个自动化报告生成项目，模型总是擅自加入一些不存在的假设。后来我就在prompt开头加了一条"本报告只基于以下数据生成，不得自行补充未提供的数据"，效果立竿见影。核心约束前置这个动作，几乎成了我所有prompt的标配。我还习惯在关键约束下加粗或使用独立行，因为排版层面的区分确实会影响模型对信息权重的判断。

3.3 自检机制：让模型在输出前先审一遍

这是把工程里的"代码评审"概念移植到提示词里。具体做法是在原任务后追加一个"自检清单"，要求模型在给出正式答案之前先按清单过一遍。

请完成以下任务：{任务内容} 完成后，按如下清单自检： 1. 是否完整回答了原始问题？ 2. 是否存在事实性错误或过度引申？ 3. 是否严格遵循了输出格式？ 4. 结论是否与正文一致？ 如果发现问题，直接修正后重新输出最终版本。

自检机制的本质是用一次额外的推理换质量稳定性。实测中，很多模型在自检阶段真的能发现自己前面犯的错误，尤其是格式错误和结论不一致这类问题。代价是会多一些输入输出token，但对于重要产出物，这点成本非常值得。

有个使用技巧：自检不一定要在同一轮输出里完成。你可以先让它生成初稿，然后在第二轮输入让它"按清单检查并提出修改意见"，再让它基于修改意见重写。这样多轮交替，比一次性让它"生成+自检"更容易发现深层次问题。我通常在高质量要求的场景里用两轮方式，一般质量的场景用单轮自检就够了。

4. 技巧8-10：用工程手段对付不确定性和持续迭代

结构稳定后，下一步要处理的是生成结果中的不确定性，以及如何让一次对话变成可迭代的工作流。这组技巧会更接近"工程思维"，因为它们的核心不是怎么写单条prompt，而是怎么设计一套能持续产出高质量结果的机制。

4.1 红队视角：让模型自己挑自己的毛病

模型生成的答案往往有一种"迷之自信"，尤其在方案设计、风险分析这类任务里。一个有效的对抗手段是让模型扮演红队，自己反驳自己。

请先给你的答案。 然后，站在一个非常挑剔的专家角度，找出上述答案中可能存在的漏洞、盲区、误导性假设和被忽略的边界情况。 基于这些批评，重新给出一版更可靠的答案，并在最后单独列出：你保留了哪些观点，修改了哪些观点。

这个技巧我经常用在技术选型类的prompt里。第一次生成的方案往往很常规，但经过"红队反驳"之后，第二版方案通常会更全面，甚至会主动提出替代方案。这个"生成-批评-重写"的循环，比你在对话里手动纠正高效得多。

需要提醒的是，红队视角会显著增加token消耗，而且如果任务本身很简单，会有一种"杀鸡用牛刀"的感觉。我一般在决策类、高风险任务里才使用。还有一个变体是让模型扮演多个不同立场的角色进行辩论，比如"成本敏感型决策者"和"质量优先型决策者"，这样能产出更立体的分析。

4.2 采样参数配合：temperature与top_p到底怎么调

提示词本身不是孤立的，生成参数同样影响结果。很多人不知道，调整参数有时比改prompt更直接。

我的习惯是：结构化输出和代码任务，temperature设0到0.3之间；创意写作和头脑风暴，设0.7到0.9。top_p一般保持默认，只在需要更严格控制时才调低。有一个常见的误区是同时大幅度降低temperature和top_p，这可能会让输出退化成一个固定模板，反而失去灵活性。

参数与提示词是配合关系。比如你已经用"自检机制"让模型对结果进行审查，那就没必要把temperature设得很低，该有的多样性已经由自检环节兜住了。反过来，如果你的prompt本身写得很模糊，那再怎么压低temperature也救不回来，因为模型并不知道你到底想要什么。

4.3 多轮反馈修正：把一次问答变成可迭代的循环

我见过很多人遇到模型输出不满意，第一时间是开一个新对话，把需求重新打一遍。这其实是在丢弃上下文。更高效的做法是就地反馈、迭代修正。

上一版回答存在以下问题： 1. 第二部分缺乏具体数据支撑； 2. 结论与第3节内容不一致； 3. 语气过于保守。 请在保留原有结构和正确内容的基础上，按上述问题重写。只修改有问题的地方，不要改动其他部分。

这种多轮修正模式，特别适合写长文、方案设计、论文润色这类任务。原因是模型在同一个上下文里保留了你之前所有的约定和修改历史，每一轮修正都在前一版基础上演进，而不是重新开始。但也要控制轮数，一般两三轮就够了，轮数过多模型可能会陷入局部最优，改来改去反而变差。

我把这种模式称为"用对话代替重写"：与其反复开新窗口碰运气，不如在同一上下文里把问题一个一个解决掉。实际操作中，我会把每一轮发现的典型问题记下来，沉淀成未来prompt里的约束，这样同一个问题不会在下一个项目里再次出现。

5. 模板库：四个高频场景，改参数就能用

前面讲的是技巧，这一节给可以直接抄的作业。每个模板都可以替换花括号里的内容直接使用，但更重要的是理解模板背后为什么要这样设计，这样你才能在场景变化时自行调整。

5.1 模板库设计原则：为什么模板要"参数化"

很多人的模板只是把一次成功的prompt复制下来，下次换个主题就硬套，效果往往不稳定。原因是每个prompt里既有结构化的固定部分，也有跟具体任务相关的变量部分。模板要做的，是把变量用占位符标记出来。

我用占位符的规则很简单：统一使用{花括号}，一目了然，在不同场景里替换就行。固定部分包括：角色设定、任务描述、输出格式、通用约束。变量部分包括：主题、受众、材料、具体需求。每次使用模板时，我会强制自己先把所有花括号填满，再根据实际情况增删一句话，这样不会漏掉关键点。

5.2 职场写作模板：周报、邮件、汇报

你是{岗位}的资深从业者，擅长向上级和协作方清晰表达工作进展。 请围绕{本周核心工作}写一份{周报/邮件/汇报材料}，受众是{受众}。 要求： 1. 开头用一段话概括本周结论； 2. 正文按"已完成/进行中/风险求助"三个模块组织； 3. 每个模块不超过3条，每条不超过两行； 4. 语言客观，不使用"取得了显著成果"这类空话。 输出结构： ## 本周结论 ## 已完成 ## 进行中 ## 风险与求助

这个模板的核心是把"要求"写成可以对照检查的规则，而不是形容词。比如"不使用空话"这种约束看起来抽象，但模型在生成时确实会避免类似的表达，因为你在要求里明确点名了。在实测中，加上"每个模块不超过3条"的效果比单纯说"要简洁"好得多，因为数量约束是可度量、可执行的。

5.3 技术方案分析模板：选型与评审

你是技术方案评审专家，有{领域}一线落地经验。 请评审以下方案：{方案描述} 分析维度： 1. 技术可行性：是否存在已知的技术障碍； 2. 落地成本：人力、时间、基础设施投入； 3. 风险项：列出top3风险及应对措施； 4. 替代方案：给出一个比当前方案更简单或更稳妥的备选。 输出要求： - 先给结论，再给理由； - 每个理由后标注置信度：高/中/低； - 不使用模糊表达，如"可能""或许"，如果确实不确定，请说明不确定的原因。

这个模板里的"置信度标注"是很容易被忽略但很有用的设计。它迫使模型区分"它确定的"和"它猜的"，这对技术评审来说非常关键。我在实际使用中，还会在模板最后加一句"如果有与你的判断相反的证据，也请列出来"，进一步减少盲区。在几次选型评审里，这个模板都帮团队提前发现了方案里的隐性风险。

5.4 代码生成与调试模板

请用{语言}实现{功能}。 函数签名：{函数签名} 输入示例：{输入} 预期输出：{输出} 要求： 1. 处理边界情况：空值、超长输入、非法参数； 2. 代码添加必要注释，但不要逐行解释； 3. 使用{库名}完成{子功能}； 4. 最后用示例输入执行一次，并贴出实际输出。 输出分两步：先给实现思路，再给完整代码。

这个模板解决的是代码任务里最常见的几个痛点：不处理边界、不验证输出、注释过度或缺失。"先给思路再给代码"这个顺序尤其重要，它能让你在审查代码之前先判断方案是否合理，避免在错误的方案上浪费时间。

还有一个调试场景的变体：当你拿到一段报错信息时，把报错信息、相关代码、期望行为三样一起放进prompt，让模型先分析可能原因再给出修复方案，比直接问"这段代码怎么改"更有效。

6. 比技巧更值钱的经验：验证集、上下文取舍与三个坑

最后这部分，我想聊聊比堆砌技巧更值得关注的事，因为它们是决定提示词工程能不能规模复用的关键。

6.1 建立你自己的小验证集，而不是靠感觉调参

很多人调prompt靠的是"这次看着不错"，但下次换一个输入可能就崩了。正确的做法是建立一个小验证集：准备10到20个有代表性的输入，每次修改prompt后，在同一批输入上跑一遍，记录哪些通过、哪些失败、失败原因是什么。

我自己的习惯是维护一个表格，每一行是一个测试用例，每一列是"输入-期望结果-实际结果-问题描述"。每次改动prompt或模型版本，都回归一遍。这看起来繁琐，但在长期维护的场景里，它比"感觉"可靠得多。你可以在表格里快速看到是哪一个约束导致了大部分失败，然后针对性修正，而不是每次都从头开始瞎试。

6.2 上下文窗口不够用时的取舍

长文档处理时，上下文窗口不够用是最常见的问题。这时的取舍逻辑是：不要把原始全文都塞进去，而是提取关键信息放进去。常用的方式包括：

• 先让模型分章节摘要，再把摘要拼接起来作为后续输入的上下文；
• 把需求里的核心约束单独放在prompt开头，原文作为附录放在后面；
• 如果业务允许，用检索增强的方式，只把相关片段注入上下文。

之前做一个项目，需要让模型基于一份80页的PDF回答问题。如果全文塞进去，既超窗口又稀释注意力。我先让模型按章节生成结构化摘要，再基于摘要回答问题，准确率反而更高。这个"压缩-再生成"的思路，在长文档处理中非常实用。

6.3 我踩过的三个典型坑

第一个坑是迷信绝对化词汇。早期我写prompt特别喜欢用"必须""绝对""不能"，以为这样约束力就更强。实际效果有限，模型对这些词汇的看重程度，远不如对具体动作的看重。与其说"绝对不能编造数据"，不如说"数据必须来自上面给定的列表，如果列表中不存在，请明确写'无数据'"。具体动作比情绪化强度词有用得多。

第二个坑是一个prompt试图覆盖所有边界。后来我发现，把太多约束塞进一个prompt，各约束之间会互相干扰，尤其是当模型在生成长文本时，后面的约束很容易被遗忘。解决办法是拆分阶段：先让模型按格式生成，再通过自检机制检查是否满足全部约束。这个调整让我的长文本任务成功率提升了不少。

第三个坑是忽视输出解析。在自动化流程里，我早期没有在prompt里严格要求格式，结果模型频繁在JSON前后加解释文字，导致解析失败。后来我不仅要求输出纯JSON，还会加一句"不要输出任何解释性文字"，解析成功率从不到80%提升到接近100%。这个教训让我意识到，prompt设计要站在后处理代码的角度考虑，而不是只站在人的阅读角度。

写到最后，再说一点个人体会。我现在写提示词的习惯是：第一版永远先跑通，再迭代，而不是一上来就要写一个完美提示词。先用最简单的方式拿到一个基础输出，观察它哪里不对，再针对性地加约束、加示例、加自检机制。提示词工程最关键的能力不是"想出一个惊天动地的提示词"，而是建立起"输出-观察-修正"的循环。你手里这套10个技巧加上模板库，足够覆盖大多数日常和工作场景了。至于更深的路，要靠你自己在一个个具体项目里，把这套方法论内化成习惯。