为什么你的 Prompt 越写越长，效果却越来越差？

前言

大语言模型（LLM）在早期阶段主要以对话机器人的形式出现，用户通过自然语言向模型提问，模型返回一段看似智能的文本结果。这一阶段，模型能力的发挥高度依赖用户如何提问，同一个问题，用不同的描述方式，往往会得到质量差异巨大的结果。

在这种背景下，提示词工程作为一门面向大语言模型的输入设计方法论逐渐成型，本篇文章主要帮助大家快速了解提示词工程的本质以及在书写技巧。

什么是提示词工程？

提示词工程的本质就是在有限上下文窗口内，最大化模型输出的确定性与可用性，减少模型自由发挥的空间。简单来说，就是提供一种提示词书写范式来确保大模型能够精准地按照用户的要求输出高质量的内容。

❌ 差提示词

帮我做一个个人待办清单页面

对于这段提示词，AI 不知道用什么技术、什么风格、要哪些功能、有什么限制。结果就是 AI 自由发挥，生成的代码和项目规范不符合。

✅ 好提示词

## 角色

你是一个擅长 React 和用户体验设计的前端开发者。


## 背景

我需要做一个个人待办清单网页，用来记录每天的待办任务，现在已经完整基本功能的开发。


## 任务

实现任务的"拖拽排序"功能，让用户可以通过拖拽调整任务顺序。


## 要求

- 拖拽时被拖动的任务半透明

- 放置位置有明显的视觉指示线

- 拖拽完成后顺序立即更新


## 约束

- 技术栈为 React + TypeScript + Tailwind CSS

- 不使用第三方拖拽库（如 react-beautiful-dnd）

- 用原生 HTML5 拖拽 API

- 代码要有详细注释，我是拖拽 API 的初学者


## 输出格式

完整的 React 组件代码，包含：
1. 组件文件（TypeScript）
2. 关键逻辑的中文注释
3. 简单的使用说明

提示词常见问题

在实际使用中，提示词的质量参差不齐，以下是几类最常见的问题及其本质原因。

信息量过多

我想让 AI 帮我做一个待办清单应用，于是将所有想法一次性列出：

帮我做一个待办清单应用，要有添加任务、删除任务、编辑任务、

标记完成、设置优先级、设置截止日期、分类标签、搜索功能、

数据统计、导出功能，还要有暗黑模式，最好能同步到云端，

支持多设备使用，界面要好看，用 React 写，要有动画效果。

问题本质：无结构、无重点。AI 可能会忽略关键信息，输出与某些要求冲突。

信息量太少

我想让 AI 帮我写个按钮组件，只有一句需求，没有任何背景：

帮我写一个按钮组件

问题本质：缺少上下文。上下文可能是：

• 
  
• 项目的技术栈
  
• 按钮需要的功能
  
• 期望的样式风格
  

最终 AI 只能给一个通用的结果。

没有目标

我想让 AI 帮我优化代码，但不给优化目标：

帮我优化一下这段代码：

[粘贴了一段代码]

问题本质：只有动作，没有结果。优化指代不明确——是体积、性能还是可读性？最终输出的结果必然不符合预期。

没有约束

我想让 AI 帮我写一个输入框组件，但是没有添加相关约束：

帮我写一个输入框组件。


技术栈：React + TypeScript + SCSS

问题本质：AI 容易引入额外的假设，例如：

• 
  
• 使用不兼容的 ui 组件库，例如 antd。
  
• 使用复杂的状态管理机制。
  

导致最终输出不可控，隐性引入错误假设。

提示词模板

了解了常见问题后，我们需要一套结构化的方法来避免它们。这就是提示词模板的价值所在。

提示词的困扰

我们现在知道在使用 AI 时，提供的上下文越清晰，AI 给出的回答就会越符合预期。但是每次写提示词的时候，我们大概率还是会陷入这样的状态：

我要先给 AI 指定一个角色，告诉他背景和任务，还有约束、要求、技术栈……约束要包含什么内容？要求要写什么？技术栈要放到哪里？

这会给 AI 使用者带来很大的认知负担，我们同时要思考"说什么"和"怎么说"。而模板的价值，就是把"怎么说"变成固定格式，让你专注于"说什么"。

这与前端的开发框架（React/Vue）很类似：在没有框架之前，开发者既要关注业务，同时还需要关注 DOM 更新及性能问题；随着框架的推出，前端开发者能把更多的精力放到业务功能开发上。

模板目标

提示词模板的目标是减少使用者的思考负担并提高 AI 输出的稳定性。但模板并不是终极目标，因为固定的模板反而会限制灵活性。因此在不同阶段、不同场景，使用者可以对模板进行调整：

推荐模板

模板结构：

模板示例：

## 角色

你是一个擅长 React 和组件开发的的前端开发者。

## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件，组件名称如下xxx。

## 任务

帮我为每个组件生成一份 mdr 文件，表示该组件的使用详细说明。

## 要求
- 文档要包含组件的 API、使用示例、xxx。

## 约束
- 使用 md 语法。
- 必须保证 API 的完整，不能漏掉内容。

## 输出格式

Title: 组件名称


description: 组件描述


API：

xxx


Examples：

xxx

## 示例


Title: Alert


description: 警示组件


API:


| 参数 | 说明 | 类型 | 默认值 | 版本 |

| --- | --- | --- | --- | --- |

| action | 自定义操作项 | ReactNode | - | 4.9.0 |

| afterClose | 关闭动画结束后触发的回调函数 | () => void | - |  |

| banner | 是否用作顶部公告 | boolean | false |  |

进阶提示词技巧

Few-shot Prompting

Few-shot 的核心思想就是给 AI 几个例子，让他先按照例子学习，理解任务处理流程及最终的内容输出。这种模式能够更高效的让 AI 理解用户的意图，这和人学习新东西一样，直接看示范比读文档更高效。

任务：为 React 组件生成 TypeScript Props 类型定义


示例1：

组件描述：一个显示任务标题的组件，标题必填，可选显示完成状态

输出：

interface TaskTitleProps {
title: string;           // 任务标题，必填

  isCompleted?: boolean;   // 完成状态，可选

}


示例2：

组件描述：一个按钮组件，显示文字必填，点击事件必填，可选禁用状态

输出：

interface ButtonProps {
label: string;           // 按钮文字，必填
onClick: () => void;     // 点击事件，必填

  disabled?: boolean;      // 禁用状态，可选

}

示例虽然能够更高效的帮助 AI 理解任务，但是过多的示例也会加大 token 的消耗，因此示例不是越多越好，要遵循少而精的原则，通过 2～5 个例子将典型的场景、多样性场景以及边界场景列举出来。

Chain of Thought

Chain of Thought 的核心思想是告诉 AI 让他一步步思考推理，输出推理内容，而不是直接给答案。就像解数学题一样，把解题的每一步都写出来，这样往往能让 AI 输出更准确的答案。

## 角色

你是一个擅长 React 和组件开发的的前端开发者。


## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件。


## 任务

帮我给修改的 react 组件补充新的单测。


### 修改点分析步骤

- 分析组件的 props，找出新增/删减/修改的参数，并输出出来。

- 分析组件的内部逻辑，找出新增/删除/修改的逻辑，并输出出来。

这种模式在复杂的场景中会大大提升输出效果，但是也存在一些局限：

• 
  
• 输出内容的长度会大大增加，增加 Token 的消耗。
  
• 对于某些简单任务，强行使用该模式可能反而会降低效果。
  
• 如果推理的过程中某一步出错，可能会导致接下来步骤都会出错，需要配合 Self-Critique 来检查。
  

Self-Critique

与人类一样，AI 并非总能在首次尝试时就生成最佳输出，Self-Critique 的核心思想是在 AI 生成内容之后，让 AI 再自我检查一遍，发现并修复问题。这个和我们考试答题一样，做完之后再检查一遍往往能发现遗漏的细节或者写错的题。

## 角色

你是一个擅长 React 和组件开发的的前端开发者。


## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件。


## 任务

帮我给修改的 react 组件补充新的单测。


## 修改点分析步骤

- 分析组件的 props，找出新增/删减/修改的参数，并输出出来。

- 分析组件的内部逻辑，找出新增/删除/修改的逻辑，并输出出来。


## 要求


- 生成完之后，请严格自查

	- 是否覆盖了所有修改点。

	- 每个修改点是否覆盖了所有边界情况（空值、空字符串、只有空格）

这种模式下会让 AI 扮演一个审查者的角色重新审下生成的内容，提高内容的准确性，但是也有它的局限：

• 
  
• 增加 Token 的消耗，这种模式更推荐在复杂的场景中使用。
  
• AI 可能出现自我认可的偏差，认为输出是没问题的，此时需要严格给 AI 设定审查者的角色。
  

总结

本文围绕「提示词工程」展开，从背景、核心目标、常见问题、结构化模板，到 Few-shot、Chain of Thought、Self-Critique 等进阶技巧，系统性地说明了一件事：

提示词工程的本质，不是“如何把话说得更漂亮”，而是如何通过结构化上下文，降低大模型输出的不确定性。

然而，这种提示词优化的思路也带来了新的工程问题：提示词越来越长、结构越来越复杂，最终直接反映为 Token 体积的持续膨胀。

因此，在实际工程中，提示词优化并不等同于写得越详细越好，而是需要在信息充分性与 Token 成本之间取得平衡。如何控制上下文规模、避免无效信息堆积、并在复杂任务中持续提供刚刚好的上下文，成为提示词工程之后必须面对的核心问题。

参考资料

• 
  
• OpenAI Prompt Engineering Guide
  
• Anthropic Prompt Engineering
  
• Few-shot Prompting
  
• Chain of Thought
  
• Self-Critique