程序员提示词工程完整指南
引言：为什么需要系统性的提示词方法论？
在 AI 编程工具普及的今天，许多开发者仍在用"试错法"编写提示词——反复修改直到获得满意结果。这种方法效率低下、结果不稳定，且难以复用。
本指南将提供一套系统性的提示词工程方法论，帮助你：
- 理解 LLM 的工作原理，从根本上优化提示词
- 掌握 6 种核心提示词模式及其应用场景
- 建立可复用的提示词模板库
- 实现提示词的版本控制与持续优化
第一部分：理解 LLM 的"思维方式"
1.1 Token 与上下文窗口
LLM 不像人类那样"理解"语言，它处理的是 Token（词元）。理解这一点对编写高效提示词至关重要。
// 一个简单的 Token 估算函数
function estimateTokens(text) {
// 英文约 1 token/4 字符，中文约 1 token/1.5 字符
const englishTokens = (text.match(/[a-zA-Z]+/g) || [])
.join('').length / 4;
const chineseTokens = (text.match(/[\u4e00-\u9fa5]/g) || [])
.length / 1.5;
const otherTokens = text.replace(/[a-zA-Z\u4e00-\u9fa5]/g, '')
.length / 4;
return Math.ceil(englishTokens + chineseTokens + otherTokens);
}
// 示例
console.log(estimateTokens('实现一个 Vue 3 分页组件')); // 约 12 tokens
上下文窗口限制：
| 模型 | 上下文窗口 | 建议用量 |
|---|---|---|
| GPT-4o | 128K | < 100K |
| Claude 3.5 | 200K | < 150K |
| DeepSeek | 64K | < 50K |
| 本地 7B 模型 | 4K-8K | < 3K |
实践建议： 保留 20-30% 的窗口空间给模型输出，避免截断问题。
1.2 注意力机制与位置效应
LLM 的注意力并非均匀分布：
┌─────────────────────────────────────────────┐
│ 提示词开头 中间部分 提示词结尾 │
│ ████████ ░░░░░░░░ ████████████ │
│ 高注意力 注意力衰减 高注意力 │
└─────────────────────────────────────────────┘
实践技巧：
- 首位效应：最重要的指令放在开头
- 近因效应：关键约束重复放在结尾
- 中间填充：详细上下文放在中间
# 高效提示词结构模板
## 开头：角色定义与核心目标（高注意力区）
你是一位精通 Vue 3 和 TypeScript 的高级前端工程师...
## 中间：详细上下文与示例（信息密集区）
项目背景：电商平台购物车模块...
当前代码：[代码块]
已尝试方案：[方案列表]
## 结尾：输出格式与关键约束（高注意力区）
请严格按照以下格式输出：
1. 问题分析（不超过 3 点）
2. 解决方案代码
3. 注意：必须使用 Composition API，禁止使用 Options API
1.3 Temperature 与输出控制
Temperature 参数控制输出的"创造性"：
interface LLMConfig {
temperature: number; // 0-2，默认 1
top_p: number; // 0-1，与 temperature 互斥使用
max_tokens: number; // 最大输出长度
}
// 不同场景的推荐配置
const configs = {
// 代码生成：需要精确、确定性输出
codeGeneration: {
temperature: 0.2,
top_p: 0.95,
max_tokens: 4096
},
// 代码审查：需要一定创造性发现问题
codeReview: {
temperature: 0.5,
top_p: 0.9,
max_tokens: 2048
},
// 创意命名：需要高创造性
naming: {
temperature: 0.8,
top_p: 0.85,
max_tokens: 512
},
// 文档生成：平衡准确性和可读性
documentation: {
temperature: 0.4,
top_p: 0.9,
max_tokens: 4096
}
};
第二部分：六大核心提示词模式
模式一：角色扮演（Role Playing）
角色设定不只是"装饰"，它实际上激活了模型在训练数据中学到的特定知识领域。
基础角色模板：
你是一位 [具体职称]，拥有 [年限] 年 [领域] 经验，
专注于 [细分方向1] 和 [细分方向2]。
你的工作风格：
- [特点1]
- [特点2]
- [特点3]
你擅长解决的问题：
- [问题类型1]
- [问题类型2]
进阶：多角色协作
请以以下三个角色的视角分析这段代码：
【架构师视角】
评估：整体设计是否合理？有无扩展性问题？
【安全专家视角】
评估：是否存在安全漏洞？如何防护？
【性能工程师视角】
评估：有无性能瓶颈？如何优化？
请依次输出三个角色的分析，最后给出综合建议。
模式二：思维链（Chain of Thought, CoT）
思维链是引导模型显式展示推理过程的技术，能显著提升复杂问题的解决质量。
标准 CoT 模板：
请按以下步骤分析问题，在每一步输出你的思考过程：
步骤 1：理解问题
- 问题的核心是什么？
- 有哪些已知条件？
- 有哪些约束限制？
步骤 2：拆解子问题
- 这个问题可以分解为哪些子问题？
- 子问题之间的依赖关系是什么？
步骤 3：逐一解决
- 解决每个子问题
- 记录关键决策和理由
步骤 4：整合方案
- 将子问题的解决方案整合
- 检查是否满足所有约束
步骤 5：验证与优化
- 方案是否正确？
- 有无优化空间？
零样本 CoT（Zero-shot CoT）：
最简单但有效的 CoT 触发方式：
请分析以下代码的性能问题。
[代码块]
让我们一步步思考（Let's think step by step）。
自一致性 CoT（Self-Consistency CoT）：
让模型从多个角度分析，取共识结论：
请从以下三个角度分析这个设计方案：
角度 A：时间复杂度优先
角度 B：空间复杂度优先
角度 C：代码可维护性优先
分别给出每个角度的推荐方案，最后说明哪种方案最适合当前场景及理由。
模式三：Few-shot 学习
通过提供示例，让模型学习你期望的输出模式。
Few-shot 代码生成模板：
请按照以下示例风格生成 Vue 组件。
### 示例 1
输入：用户头像组件
输出：
```vue
<script setup lang="ts">
/**
* 用户头像组件
* @description 显示用户头像，支持多种尺寸和占位图
*/
interface Props {
/** 图片地址 */
src: string
/** 尺寸 */
size?: 'sm' | 'md' | 'lg'
/** 加载失败时的占位图 */
fallback?: string
}
const props = withDefaults(defineProps<Props>(), {
size: 'md',
fallback: '/default-avatar.png'
})
const sizeMap = {
sm: 'w-8 h-8',
md: 'w-12 h-12',
lg: 'w-16 h-16'
} as const
const sizeClass = computed(() => sizeMap[props.size])
</script>
<template>
<img
:src="src"
:class="['rounded-full object-cover', sizeClass]"
:alt="'用户头像'"
@error="$event.target.src = fallback"
/>
</template>
示例 2
输入：加载按钮组件 输出：
<script setup lang="ts">
/**
* 加载按钮组件
* @description 带加载状态的按钮，加载时禁用点击
*/
interface Props {
/** 是否加载中 */
loading?: boolean
/** 按钮类型 */
variant?: 'primary' | 'secondary' | 'outline'
/** 是否禁用 */
disabled?: boolean
}
const props = withDefaults(defineProps<Props>(), {
loading: false,
variant: 'primary',
disabled: false
})
const emit = defineEmits<{
click: [event: MouseEvent]
}>()
const isDisabled = computed(() => props.disabled || props.loading)
</script>
<template>
<button
:disabled="isDisabled"
:class="['btn', `btn-${variant}`, { 'opacity-50': isDisabled }]"
@click="emit('click', $event)"
>
<span v-if="loading" class="loading-spinner mr-2" />
<slot />
</button>
</template>
你的任务
输入：通知徽章组件 输出：
**Few-shot 最佳实践：**
| 原则 | 说明 |
|------|------|
| 示例数量 | 2-5 个为宜，过多会占用上下文 |
| 多样性 | 示例应覆盖不同场景 |
| 一致性 | 所有示例遵循相同风格 |
| 边界情况 | 至少包含一个边界情况示例 |
### 模式四：结构化输出（Structured Output）
当需要 JSON、表格等结构化输出时，明确指定格式至关重要。
**JSON 输出模板：**
```markdown
请分析以下代码，以 JSON 格式输出分析结果。
[代码块]
输出格式要求：
```json
{
"summary": "一句话总结",
"issues": [
{
"type": "bug|performance|style|security",
"severity": "high|medium|low",
"line": 10,
"description": "问题描述",
"suggestion": "修复建议"
}
],
"score": {
"readability": 8,
"performance": 7,
"maintainability": 6
},
"recommendations": ["建议1", "建议2"]
}
注意：
- 输出必须是合法的 JSON 格式
- 不要在 JSON 外添加任何说明文字
- 数组为空时使用 ，不要省略字段
**表格输出模板：**
```markdown
请对比以下三个状态管理库，以 Markdown 表格格式输出。
对比维度：
- 学习曲线
- Bundle 大小
- TypeScript 支持
- 开发者体验
- 生态系统
对比对象：Pinia、Zustand、Jotai
输出格式：
| 特性 | Pinia | Zustand | Jotai |
|------|-------|---------|-------|
| ... | ... | ... | ... |
模式五：约束编程（Constraint Programming）
通过明确的约束条件，精确控制输出范围。
约束清单模板：
请实现一个日期选择器组件，需满足以下约束：
## 必须满足的约束（MUST）
- [ ] 使用 Vue 3 Composition API
- [ ] 使用 TypeScript 严格模式
- [ ] 支持日期范围选择
- [ ] 禁止选择过去的日期
## 应该满足的约束（SHOULD）
- [ ] 支持键盘导航
- [ ] 支持国际化
- [ ] 响应式布局
## 不得包含的约束（MUST NOT）
- [ ] 不使用 moment.js（使用 dayjs 或 date-fns）
- [ ] 不使用 any 类型
- [ ] 不使用内联样式
## 可选约束（MAY）
- [ ] 支持周起始日配置
- [ ] 支持农历显示
模式六：迭代优化（Iterative Refinement）
复杂任务通常需要多轮迭代，每轮聚焦一个方面。
迭代工作流模板：
# 第一轮：生成基础版本
请实现一个表单验证函数，支持以下规则：
- required：必填
- minLength/maxLength：长度限制
- pattern：正则匹配
- custom：自定义验证函数
---
# 第二轮：类型优化（基于第一轮输出）
请优化上述代码的 TypeScript 类型定义：
1. 使用泛型提升类型推断
2. 添加完整的 JSDoc 注释
3. 导出所有公共类型
---
# 第三轮：错误处理优化
请增强错误处理能力：
1. 自定义错误类
2. 错误信息国际化支持
3. 支持异步验证
---
# 第四轮：性能优化
请优化性能：
1. 添加验证结果缓存
2. 支持防抖验证
3. 大表单的分组验证
第三部分：领域特定提示词策略
3.1 代码审查提示词
请审查以下代码，从以下维度评估：
## 代码
[代码块]
## 审查维度
### 1. 正确性（权重 40%）
- 逻辑是否正确
- 边界条件处理
- 错误处理完整性
### 2. 可维护性（权重 25%）
- 命名规范
- 函数单一职责
- 模块化程度
### 3. 性能（权重 20%）
- 时间复杂度
- 内存使用
- 不必要的计算
### 4. 安全性（权重 15%）
- 输入验证
- XSS/CSRF 防护
- 敏感信息处理
## 输出要求
1. 每个维度给出 1-10 分评分
2. 列出具体问题及修复建议
3. 计算加权总分
4. 给出优先修复的 Top 3 问题
3.2 重构提示词
请将以下遗留代码重构为现代 TypeScript：
## 原始代码
[代码块]
## 重构目标
1. **现代化**：ES2022+ 语法
2. **类型安全**：完整的 TypeScript 类型
3. **可测试**：便于单元测试
4. **可维护**：清晰的模块结构
## 重构约束
- 保持 API 向后兼容
- 不改变函数签名（除非有明确说明）
- 不引入新的外部依赖
## 输出内容
1. 重构后的代码
2. 变更说明（改了什么、为什么改）
3. 迁移指南（如有 breaking changes）
4. 单元测试用例
3.3 测试生成提示词
请为以下函数生成单元测试：
## 被测代码
[函数代码]
## 测试框架
Vitest + @testing-library/vue
## 测试要求
### 覆盖场景
- [ ] 正常输入
- [ ] 边界值
- [ ] 异常输入
- [ ] 异步场景（如适用）
### 测试风格
- 使用 describe/it 组织
- 测试名称采用 "should [expected behavior] when [condition]" 格式
- 每个测试只验证一个行为
### 输出格式
```typescript
import { describe, it, expect, vi } from 'vitest'
import { functionName } from './module'
describe('functionName', () => {
describe('正常场景', () => {
it('should [behavior] when [condition]', () => {
// Arrange
// Act
// Assert
})
})
describe('边界场景', () => {
// ...
})
describe('异常场景', () => {
// ...
})
})
## 第四部分：提示词工程工作流
### 4.1 提示词版本控制
```typescript
// prompts/code-review.ts
export const codeReviewPrompt = {
version: '2.1.0',
lastUpdated: '2026-01-15',
// 模板定义
template: `
你是一位资深代码审查专家...
## 审查代码
{{code}}
## 审查重点
{{focus_areas}}
## 输出格式
{{output_format}}
`,
// 变量定义
variables: {
code: { type: 'string', required: true },
focus_areas: { type: 'array', default: ['correctness', 'performance'] },
output_format: { type: 'string', default: 'markdown' }
},
// 使用示例
examples: [
{
input: { code: '...', focus_areas: ['security'] },
output: '...'
}
],
// 变更记录
changelog: [
{ version: '2.1.0', date: '2026-01-15', changes: '添加安全维度' },
{ version: '2.0.0', date: '2026-01-01', changes: '重构输出格式' }
]
};
// 渲染函数
export function renderPrompt(
template: string,
variables: Record<string, unknown>
): string {
return template.replace(
/\{\{(\w+)\}\}/g,
(_, key) => String(variables[key] ?? '')
);
}
4.2 提示词测试
// prompts/__tests__/code-review.test.ts
import { describe, it, expect } from 'vitest'
import { codeReviewPrompt, renderPrompt } from '../code-review'
describe('Code Review Prompt', () => {
it('should render all required variables', () => {
const rendered = renderPrompt(codeReviewPrompt.template, {
code: 'const x = 1',
focus_areas: ['performance'],
output_format: 'json'
});
expect(rendered).toContain('const x = 1');
expect(rendered).toContain('performance');
expect(rendered).not.toContain('{{');
});
it('should use default values for optional variables', () => {
const rendered = renderPrompt(codeReviewPrompt.template, {
code: 'const x = 1'
});
expect(rendered).toContain('correctness');
expect(rendered).toContain('markdown');
});
});
4.3 提示词优化循环
┌─────────────────────────────────────────────────┐
│ 提示词优化循环 │
├─────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 编写 │───▶│ 测试 │───▶│ 评估 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌─────────┐ ┌─────────┐ │
│ │ 优化 │◀──────────────────│ 分析 │ │
│ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────┘
评估指标：
- 输出准确率
- Token 效率
- 响应稳定性
- 边界处理能力
总结
提示词工程不是"玄学"，而是可以系统学习和持续优化的工程实践。
关键要点回顾
- ✅ 理解 LLM 原理：Token、注意力、Temperature
- ✅ 掌握六大模式：角色扮演、思维链、Few-shot、结构化输出、约束编程、迭代优化
- ✅ 领域特定策略：代码审查、重构、测试生成
- ✅ 工程化管理：版本控制、自动测试、持续优化
立即行动
- 从本文提供的模板开始，建立你的提示词库
- 为常用场景定制专属提示词
- 建立评估机制，持续迭代优化
- 分享和复用团队的最佳实践
