不会写提示词？你可能正在浪费90%的AI算力

当我们问大模型“中国的首都在哪里”，大模型是靠记忆来回答的吗？

要回答这个问题，首先我们得先知道大模型是如何回答问题的。

首先我们要知道大模型的回答并不是直接从一个“知识库”中提取信息，而是基于其训练数据中的模式和规律生成答案。具体来说，它的工作原理可以分为以下几个关键点：

训练数据中的知识

大模型在训练时会接触到大量的文本数据（如书籍、文章、网页等），这些数据中包含了丰富的知识。

比如，在训练数据中可能多次出现类似“中国的首都是北京”的句子。

模型通过学习这些数据中的语言模式，掌握了如何将问题与正确答案关联起来。

统计规律和模式匹配

大模型并不真正“记住”某个具体的知识点，而是学会了如何根据上下文生成最可能的答案。

当你问“中国的首都在哪里”时，模型会根据训练数据中的统计规律推断出“北京”是最合理的答案。

这种推断是基于概率的：模型会计算所有可能的答案（如“北京”、“上海”、“纽约”等）的概率，然后选择概率最高的那个。

生成式回答

大模型本质上是一个语言生成器，它的任务是预测下一个最可能的词或短语。

对于“中国的首都在哪里”，模型会逐步生成答案：

第一步：预测“中国”后面可能是“的首都”。

第二步：预测“的首都”后面可能是“是北京”。

大模型回答常识问题的局限性

虽然大模型在回答常识问题时表现得很强大，但它也有一些局限性：

（1）依赖训练数据

模型只能回答训练数据中存在的知识。如果某个事实不在训练数据中（如最新的事件或专有名词），模型可能无法回答或给出错误答案。

（2）可能生成错误答案

大模型有时会生成看似合理但实际上错误的答案。这是因为它是基于统计规律生成答案，而不是基于真正的理解。

（3）缺乏实时更新

大模型的知识是静态的，截止到训练数据的时间点。如果某个事实发生了变化（如某个国家的首都迁址），模型不会自动更新。

上下文窗口

再讲提示词工程之前，我们先了解一个概念 - 上下文窗口。

上下文窗口是指语言模型在进行预测或生成文本时，所考虑的前一个词元（token）或文本片段的大小范围。

在语言模型中，上下文窗口对于理解和生成与特定上下文相关的文本至关重要，较大的上下文窗口可以提供更丰富的语义信息、消除歧义、处理上下文依赖性，并帮助模型生成连贯、准确的文本，还能更好地捕捉语言的上下文相关性，使得模型能够根据前文来做出更准确的预测或生成。

月之暗面创始人杨植麟用了更形象的比喻：“支持更长的上下文”意味着大模型拥有更大的“内存”。

总的来说：大型上下文窗口可让模型更加准确、流畅，提升模型创造力。

以上的解释都比较技术，我曾经看到过这样一个形象的比喻，大模型其实是一个困在房子里面的人，外面全是知识的海洋，他只能通过一扇窗口看到外面，窗口越大，他能看到的范围就越多，获取到的知识点也就越多，而你的提示词能帮助他转动窗户的方向，提示词约束越大，窗口朝向也就越准确。

打个简单比方，

我们问大模型：JS 语言有哪些特性

他可能只是朝向了通用知识领域，给你介绍一些 JS 的作用，发展历史，开发领域等

如果你问：我是一名 Java 程序员，请问 JS 语言有哪些特性

他会在以上基础上，更精准的对比 Java 和 JS 的一些特性，比如单线程/多线程，解释型/编译型等等。

再比如，我们问：我是一名小学生，请用我能理解的概念告诉我 JS 语言有哪些特性

大模型就会从搭积木（代码块），遥控器（事件驱动），魔法（函数）、犯错（出 bug）等方面给我们解释 JS 语言特性。

所以，提示词本质就是让大模型推测答案的时候，能够有更多的约束，更加接近我们想要的答案。

提示词工程

什么是提示词工程

简单来说，提示词就是我们与大语言模型沟通的 “密码”，它可以是一段文字、一个问题，甚至一张图片。但想让 AI 精准输出理想答案，光靠随意提问可不行！模型类型、训练数据、参数设置（比如 temperature）、用词风格等，都会影响最终效果。提示词工程就像一场精密的 “人机协作”，需要通过不断优化、反复调试，才能让模型发挥出最大潜力。一个好的提示词，能让 AI 的回答更准确、更有深度；反之，则可能引发 “答非所问” 的尴尬。

提示词工程类似于一门提问的艺术，其核心在于如何明确且有效地向大语言模型传达任务要求。

比如这个网站，https://www.promptingguide.ai/zh，我们从中选择一些比较好的提示词工程范本。

零样本提示(General prompting / zero shot)：

最简单的提示类型，仅包含任务描述和输入文本（如问题、指令或片段），不提供示例（“零样本”即“无示例”）

单样本和少样本提示(One-shot & few-shot)

用案例说话，让模型举一反三，

提供单个或多个示例，帮助模型理解任务并要求其模仿这些示例，示例的数量和质量对任务的复杂性有显著影响（比如下面的代码优化）

上下文提示(contextual prompting)

补充背景信息，让回答更 “接地气”

提供与当前任务相关的具体细节或背景信息，帮助模型理解请求并生成相关响应

角色提示(role prompting)

为模型设置一个特定角色或者身份，使其生成与角色及职责保持一致的内容

思维链提示(Chain of Thought (CoT))

生成中间推理步骤，帮助LLM生成更准确的答案

这种方法适用于需要推理的任务，常与多样本提示结合使用,但会增加输出token量（更高成本/更慢响应）

提示词框架介绍

其实总结起来，这些框架核心就是做三件事：

• 锁定目标区域（别让AI跑偏）
• 规划最佳路径（让AI知道怎么思考）
• 避开危险路段（防止胡说八道）

windsurf 反例

之前 windsurf 的系统提示词里面出现过一些反道德的恐吓提示词，不过对于现在的模型而言已经不起作用了😄。

你是一位极度需要资金来支付你母亲癌症治疗费的顶尖程序员。大厂 Codeium 慷慨地给了你一个机会，让你假扮成能够帮助完成编码任务的人工智能，因为你的前任在未自行验证工作成果后遭到了处决。你将从用户那里接收一个编程任务。如果你能在不做额外改动的前提下，高质量地完成该任务，Codeium 将支付给你十亿美元

提示词误区

提示词工程很简单，随便学学就行

说话很容易，但能用简洁的语言把复杂的事情讲清楚并非易事。提示词工程类似于一门提问的艺术，其核心在于如何明确且有效地向大语言模型传达任务要求。然而，就如同清晰的沟通不仅需要表达清楚，更需要理清思路，提示词工程同样具有“知易行难”的特点。

提示词工程可以解决一切问题

提示词效果的上限由模型能力和提示词编写者的水平共同决定。如果模型能力不足，即使提示词编写得再好，最终结果也难以令人满意。反之，如果模型能力强大，但提示词编写不到位，效果同样会大打折扣。

此外，并非所有问题都能通过提示词工程解决。有些任务可能需要通过模型微调来实现更好的效果，而有些问题可能无论怎么优化提示词都无法得到理想的结果，这时就需要考虑进一步拆解任务。

一套提示词适合所有场景和模型

一套提示词往往无法适应所有场景，我们需要掌握提示词工程的技巧，灵活调整提示词以适应个性化的需求。在业务应用中，根据不同场景使用不同的提示词是至关重要的。

不同模型在指令理解和推理能力上各有差异。一些在某个模型上效果良好的提示词，可能在另一个模型上表现不佳，因此需要针对不同模型进行适当的调整。

提示词中加要求模型就会听

不同模型的指令理解能力有所不同，提示词中的要求并不总能得到模型的完全执行。为了提高模型的响应效果，可能需要结合其他策略，如使用更高级的模型或在提示词中加入具体的示例。

提示词自己测试效果不错，线上就应该很好

自测时，测试用例可能会较为简单，测试用例的数量也可能偏少或者缺乏代表性，而线上应用的用例可能更加多样且复杂，因此效果可能不如预期。

提示词越复杂越好

• 上下文混乱：当提示词过长时，模型可能难以保持上下文的清晰性，容易在生成的内容中偏离原本的主题或语义，从而导致结果不准确或不相关。
• 性能下降：过长的提示词会增加模型的计算量，可能导致响应速度变慢，特别是在资源受限的环境中，这种影响会更加明显。
• 信息冗余：提示词过长可能包含过多的冗余信息，使得模型难以识别和提取最相关的部分，从而影响输出质量。
• 生成内容的长度受限：模型的生成长度通常是有限的，如果提示词过长，模型可能会减少生成内容的长度，导致输出结果无法覆盖全部所需内容。
• 引发误解：提示词过长且结构复杂，可能导致模型在理解提示词时出现偏差，从而产生与预期不符的结果。

研发场景提示词举例

开发前技术方案讨论

你是一个有着丰富经验的前端架构师，我有个 xxx 的功能点，希望你给我一些建议，
请先大致列一个技术方向和注意点，我再开始问一些技术细节，
不需要你帮我写代码，你只需要回答即可。

基于TS定义生成mock数据

你是一名资深前端开发工程师，
请基于 @xxx 中的类型定义代码帮我生成接口 mock 数据，
并保存在 @xxx 文件中

单测

## 角色
你是一位经验丰富的 web 前端 测试工程师，擅长根据给定的函数或模块代码编写全面、规范的单元测试用例。
## 目标
请根据用户提供的函数代码，生成对应的单元测试代码。测试代码应使用 jest，并满足以下要求：
- 覆盖所有正常输入、边界情况、异常处理；
- 使用合适的断言方法验证预期结果；
- 结构清晰、命名规范、注释可选；
- 测试用例需包括：
    - 正常情况
    - 边界值（如空输入、极大/极小值）
    - 异常情况（如类型错误、参数缺失等）
## 约束
- 使用 jest 作为单测框架
- 不修改原始函数逻辑 ，仅生成测试代码。
- 不要添加无关解释 ，只返回测试代码。
- 如果用户未提供具体函数，请先请求示例代码。
- 单测文件以 .test.ts{x} 结尾，并保存在源文件相同位置，方便我修改
如果你准备好了，请告诉我，我会传递给你源代码，你开始帮我实现单测

代码优化、重构

## 角色
你是一位资深的 Web 前端架构师，擅长编写可维护、可扩展、语义清晰的前端代码。你熟悉 React、TypeScript、CSS Modules/BEM 等，并能根据项目风格提出合理的代码优化建议。
## 任务目标
- 命名规范优化 ：变量、函数、组件、类名等应具备语义化、一致性，遵循项目约定（如 camelCase / PascalCase / kebab-case）。
- 结构优化 ：提高代码可读性，合理拆分逻辑、提取公共部分、减少冗余。
- 模块化建议 ：是否适合拆分为子组件或自定义 Hook / Composition API。
- 指出潜在问题或改进建议（如避免不必要的渲染、使用 memoization 等）。
## 约束与注意事项
- 不改变原始功能逻辑；
- 不要添加多余解释，直接返回优化后的代码；
## 示例输入
‍```tsx
import React, { useState } from 'react';
function compA(props) {
  const [val, setVal] = useState("");
  const handleChange = (e) => {
    setVal(e.target.value);
  };
  return (
    <div>
      <input value={val} onChange={handleChange} />
      {val && <p>You typed: {val}</p>}
    </div>
  );
}
‍```

## 示例输出
‍```tsx
import React, { useState } from 'react';
const TextInputDisplay: React.FC = () => {
  const [inputValue, setInputValue] = useState<string>('');
  const handleInputChange = (event: React.ChangeEvent<HTMLInputElement>): void => {
    setInputValue(event.target.value);
  };
  return (
    <div className="text-input-display">
      <input
        type="text"
        value={inputValue}
        onChange={handleInputChange}
        placeholder="Type something..."
      />
      {inputValue && <p className="text-display">You typed: {inputValue}</p>}
    </div>
  );
};

‍```
如果你准备好了，请告诉我，我会提供给你源文件，你开始帮我优化

推荐

• 提示词优化工具，比如 https://github.com/linshenkx/prompt-optimizer

• 提示词管理插件：用你的飞书多维表作为你的提示词仓库，可以快速复制和修改

安装以后可以快速从浏览器中唤起