AI Prompt 工程实战手册：让大模型输出从能用到好用

前言

前几篇文章里，我在每个环节都零散提到了 Prompt 技巧：PRD 生成要用模板约束，UI 设计要描述结构而非像素，技术方案要设定架构师角色。

但这些技巧背后有一套通用的方法论。掌握了它，不管你用 AI 做什么——写文档、生成代码、做设计、分析数据——输出质量都会有质的提升。

这篇文章系统讲解 Prompt 工程的核心技巧。不是理论综述，而是实战手册：每个技巧配一个真实场景，给出"差 Prompt"和"好 Prompt"的对比，让你看到差距在哪里。

一、为什么 Prompt 质量这么重要

同一个模型，不同的 Prompt 可以产出天差地别的结果。这不是玄学，而是因为大模型的工作方式：它根据输入的上下文预测最可能的输出。你给的上下文越精确、越结构化，它的预测就越准确。

一个类比：Prompt 就像你给实习生的任务说明。你说"帮我写个文档"，他不知道写什么、给谁看、什么格式。你说"帮我写一份工单系统的 PRD，给开发团队看，按这个模板填充，重点写清楚状态流转逻辑"，他就能交出一份有用的初稿。

AI 也一样。区别在于，AI 不会主动问你"你具体要什么"——它会直接猜，而猜的结果往往是泛泛而谈的平庸输出。

二、六大核心技巧

技巧一：角色设定

原理：给 AI 一个具体的专业角色，激活它在该领域的知识和表达方式。

差 Prompt：

帮我设计一个工单系统的数据库。

好 Prompt：

你是一位有 10 年经验的后端架构师，擅长 PostgreSQL 数据库设计。
请为一个内部工单系统设计数据模型，需要支持：
- 工单的创建、分配、状态流转
- 多级优先级
- 评论和附件
- 操作日志审计

请输出：表结构（含字段类型和约束）、索引建议、关键的查询场景分析。

为什么有效：角色设定不是"让 AI 演戏"，而是缩小了输出的搜索空间。当你说"后端架构师"，模型会倾向于输出规范的表结构、考虑索引优化、提到外键约束——这些是架构师会关注的东西。

适用场景：

• 技术方案设计 → "高级后端架构师"
• PRD 编写 → "资深产品经理"
• 代码审查 → "安全工程师"
• 文案撰写 → "技术博客作者"

注意：角色设定是辅助手段，不是万能钥匙。如果你的需求描述本身就模糊，再好的角色也救不了。

技巧二：模板约束

原理：给 AI 一个明确的输出结构，让它按模板填充而非自由发挥。

差 Prompt：

帮我写一份 API 文档。

好 Prompt：

请按以下模板为工单系统的"创建工单"接口编写 API 文档：

## 接口名称
[填写]

## 请求
- 方法: [GET/POST/PUT/DELETE]
- 路径: [填写]
- Headers: [列出必需的 headers]
- Body:
```json
{
  // 列出所有字段，标注类型和是否必填
}

响应

• 成功 (200):

{
  // 响应结构
}

• 错误:
  • 400: [场景描述]
  • 401: [场景描述]
  • 403: [场景描述]

示例

[完整的 curl 命令示例]

注意事项

[边界情况、限制、注意点]

**为什么有效**：模板消除了"输出什么格式"的不确定性，让 AI 把全部注意力放在内容上。而且模板本身就是一份检查清单——它提醒 AI 不要遗漏错误码、示例、注意事项这些容易忘的部分。

**适用场景**：
- PRD 文档（[深度篇](/zh/blog/ai-prd) 中详细讲过）
- API 文档
- 测试用例
- 代码审查报告
- 会议纪要

**进阶**：把你团队常用的文档模板保存下来，每次直接复用。这是 ROI 最高的 Prompt 投资。

### 技巧三：思维链（Chain of Thought）

**原理**：要求 AI 展示推理过程，而不是直接给结论。这会显著提升复杂问题的输出质量。

**差 Prompt**：

这段代码有什么问题？ [代码片段]

**好 Prompt**：

请逐步分析这段代码的潜在问题：

1. 先理解代码的意图和逻辑流程
2. 检查每个函数的输入验证和边界情况
3. 检查错误处理是否完善
4. 检查是否有安全隐患（注入、XSS 等）
5. 检查性能问题（N+1 查询、内存泄漏等）
6. 最后给出修复建议，按严重程度排序

[代码片段]

**为什么有效**：大模型在"一步到位"时容易跳过中间推理，导致遗漏。要求它分步思考，相当于强制它走完整个分析流程。

**适用场景**：
- 代码审查和 bug 分析
- 架构决策（列出选项 → 逐个分析优劣 → 给出推荐）
- 复杂需求拆解
- 技术选型对比

**变体**：如果你不想看到冗长的推理过程，可以说"请在内部逐步推理，只输出最终结论和关键依据"。

### 技巧四：Few-shot 示例

**原理**：给 AI 几个输入-输出的示例，让它学习你期望的模式。

**差 Prompt**：

把这些用户故事转换成测试用例。

**好 Prompt**：

请把用户故事转换成测试用例。以下是格式示例：

用户故事：作为普通员工，我想提交工单，以便 IT 部门处理我的问题。 测试用例：

现在请按同样的格式，为以下用户故事生成测试用例：

• 作为 IT 管理员，我想分配工单给具体的处理人
• 作为普通员工，我想在工单中添加评论

**为什么有效**：示例比描述更精确。你可以用一千个字描述你想要的格式，不如直接给一个例子。AI 会精确模仿示例的结构、粒度和风格。

**适用场景**：
- 格式要求严格的输出（测试用例、数据转换、文档生成）
- 风格模仿（按照团队现有文档的风格写新文档）
- 分类任务（给几个分类示例，让 AI 对新数据分类）

**注意**：示例数量通常 2-3 个就够了。太多示例会占用上下文窗口，反而降低效果。

### 技巧五：约束与边界

**原理**：明确告诉 AI 什么该做、什么不该做、输出的边界在哪里。

**差 Prompt**：

帮我重构这段代码。

**好 Prompt**：

请重构以下代码，遵循这些约束：

必须做的：

• 提取重复逻辑为独立函数
• 添加 TypeScript 类型注解
• 使用 early return 减少嵌套

不要做的：

• 不要改变函数的外部接口（参数和返回值）
• 不要引入新的依赖库
• 不要添加注释（代码应该自解释）
• 不要改变业务逻辑

输出要求：

• 只输出修改后的代码，不需要解释
• 如果某处重构可能影响行为，用 // TODO 标注

[代码片段]

**为什么有效**：AI 有"过度热心"的倾向——你让它重构，它可能顺手改了业务逻辑、加了一堆注释、引入了新库。明确的约束让它收敛到你真正想要的范围。

**适用场景**：
- 代码重构（限定范围）
- 文档编写（限定长度、风格、术语）
- 设计生成（限定组件库、颜色方案）
- 任何你不想 AI "自由发挥"的场景

**关键词**：
- "不要"、"禁止"、"避免" → 排除不想要的行为
- "只"、"仅" → 限定输出范围
- "必须"、"确保" → 强制要求

### 技巧六：多轮迭代

**原理**：不要期望一次 Prompt 得到完美结果。把复杂任务拆成多轮对话，每轮聚焦一个方面。

**差做法**：写一个超长的 Prompt，试图一次性得到完美输出。

**好做法**：

第一轮：生成框架 "请为工单系统的通知模块生成技术方案的大纲，列出需要覆盖的要点。"

第二轮：逐节展开 "请展开第 2 节'通知渠道设计'，详细说明邮件、站内信、Webhook 三种渠道的实现方案。"

第三轮：补充细节 "通知的重试机制没有覆盖。请补充：失败重试策略、死信队列处理、监控告警。"

第四轮：审查优化 "请审查整个方案，检查是否有遗漏或不一致的地方。特别关注：高并发场景下的性能、通知去重、用户偏好设置。"

**为什么有效**：
1. 每轮的上下文更聚焦，AI 的输出质量更高
2. 你可以在每轮之间审查和纠偏，避免错误累积
3. 复杂任务拆解后，每个子任务都在 AI 的能力范围内

**适用场景**：所有复杂任务。经验法则——如果你的 Prompt 超过 500 字，考虑拆成多轮。

## 三、组合使用：实战案例

单个技巧有用，组合使用更强大。来看一个完整的例子。

### 场景：为工单系统设计通知方案

**第一轮：角色设定 + 模板约束**

你是一位高级后端架构师，擅长消息系统设计。

请为工单系统设计通知方案，按以下结构输出：

1. 通知触发场景

[列出所有需要发送通知的业务事件]

2. 通知渠道

[每种渠道的技术方案]

3. 数据模型

[通知相关的表结构]

4. 技术选型

[消息队列、模板引擎等的选择]

5. 关键设计决策

[需要权衡的技术决策，列出选项和推荐]

背景信息：

• 用户量：500 人
• 工单状态：待分配 → 处理中 → 待验证 → 已完成/已关闭
• 现有技术栈：Node.js + PostgreSQL + Redis

**第二轮：思维链 + 约束**

请逐步分析第 5 节中的"实时通知 vs 批量通知"决策：

1. 列出两种方案的实现复杂度
2. 分析 500 人规模下的性能影响
3. 考虑用户体验差异
4. 给出推荐方案和理由

约束：不要推荐 WebSocket 以外的实时方案（团队只熟悉 WebSocket）。

**第三轮：Few-shot + 迭代**

请为通知模块编写测试用例。参考这个格式：

请补充所有剩余场景的测试用例，特别注意：

• 状态流转的每个节点
• 评论和 @提及
• 超时未处理的提醒

三轮下来，你得到了一份结构完整、细节充分、经过审查的通知方案。每轮都用了不同的技巧组合，每轮之间你都有机会审查和纠偏。

## 四、不同环节的 Prompt 策略

### PRD 编写

**核心技巧**：模板约束 + 多轮迭代

第一轮：用模板生成 PRD 框架 第二轮：逐节细化，补充边界情况 第三轮：用 [待确认] 标记不确定的部分

详见 [PRD 深度篇](/zh/blog/ai-prd)。

### UI 设计

**核心技巧**：约束（描述结构不描述像素）+ Few-shot（参考图）

描述布局区域 → 指定组件库 → 提供示例数据 → 分页面生成

详见 [UI 设计深度篇](/zh/blog/ai-ui-design)。

### 代码生成

**核心技巧**：角色设定 + 约束 + 多轮迭代

第一轮：定义接口和类型 第二轮：实现核心逻辑 第三轮：添加错误处理 第四轮：生成测试

关键约束：指定语言版本、框架、代码风格、禁止引入新依赖。

### 代码审查

**核心技巧**：思维链 + 角色设定

你是一位安全工程师。请逐步审查这段代码：

1. 输入验证
2. SQL 注入风险
3. XSS 风险
4. 认证和授权
5. 敏感数据处理

### 技术方案

**核心技巧**：角色设定 + 模板约束 + 思维链

角色：高级架构师 模板：数据模型 → API 设计 → 技术选型 → 部署方案 思维链：每个选型决策列出选项、逐个分析、给出推荐

## 五、常见陷阱

### 陷阱一：Prompt 越长越好

**错误认知**：把所有能想到的要求都塞进 Prompt。

**现实**：超长 Prompt 会导致 AI "注意力分散"，反而遗漏关键要求。经验法则：单轮 Prompt 控制在 200-500 字，超过就拆成多轮。

### 陷阱二：过度依赖角色设定

**错误认知**：只要设定了"世界顶级专家"角色，输出就会变好。

**现实**：角色设定是锦上添花，不是雪中送炭。如果你的需求描述本身就模糊，"世界顶级专家"也只能给你一份泛泛而谈的输出。先把需求写清楚，再加角色设定。

### 陷阱三：不审查直接用

**错误认知**：好的 Prompt 能保证输出正确。

**现实**：再好的 Prompt 也不能消除 AI 的幻觉和错误。Prompt 工程提升的是输出的"平均质量"，但每次输出仍然需要人工审查。特别是：
- 数字和日期（AI 经常编造）
- 技术细节（API 参数、库的用法）
- 边界情况（AI 倾向于忽略）

### 陷阱四：忽略上下文窗口

**错误认知**：把整个代码库丢给 AI 就能得到更好的结果。

**现实**：上下文窗口有限，塞太多无关信息会稀释关键信息。只提供与当前任务直接相关的上下文。

### 陷阱五：一次性 Prompt

**错误认知**：每次都从零开始写 Prompt。

**现实**：好的 Prompt 应该被保存和复用。建立团队的 Prompt 模板库，按场景分类，持续优化。这是 ROI 最高的投资。

## 六、建立你的 Prompt 模板库

### 模板库结构建议

prompts/ ├── prd/ │ ├── feature-prd.md # 功能 PRD 模板 │ └── api-prd.md # API PRD 模板 ├── code/ │ ├── code-review.md # 代码审查模板 │ ├── refactor.md # 重构模板 │ └── test-generation.md # 测试生成模板 ├── design/ │ ├── page-ui.md # 页面 UI 生成模板 │ └── component-ui.md # 组件 UI 生成模板 └── architecture/ ├── tech-spec.md # 技术方案模板 └── api-design.md # API 设计模板

### 模板维护原则

1. **从实际使用中提炼**：不要凭空设计模板，从你实际用过的好 Prompt 中提炼
2. **持续迭代**：每次使用后记录效果，定期优化
3. **团队共享**：放在团队的知识库或代码仓库中，所有人都能用
4. **版本管理**：用 Git 管理模板变更，记录为什么改

### 一个实用的代码审查模板

```markdown
# 代码审查 Prompt 模板

## 角色
你是一位高级软件工程师，专注于 [语言/框架] 开发。

## 任务
请审查以下代码变更，关注以下方面：

### 必查项
- [ ] 逻辑正确性：代码是否实现了预期功能
- [ ] 错误处理：异常情况是否被正确处理
- [ ] 安全性：是否有注入、XSS 等安全隐患

### 选查项（根据变更类型勾选）
- [ ] 性能：是否有 N+1 查询、内存泄漏等问题
- [ ] 可维护性：命名是否清晰、结构是否合理
- [ ] 测试覆盖：关键路径是否有测试

## 输出格式
按严重程度分类：
- 🔴 必须修复：[问题描述 + 修复建议]
- 🟡 建议修复：[问题描述 + 修复建议]
- 🟢 可选优化：[问题描述 + 优化建议]

## 代码变更
[粘贴代码]

七、总结

Prompt 工程不是玄学，而是一套可学习、可复用的方法论。六个核心技巧：

1. 角色设定：缩小输出的搜索空间
2. 模板约束：消除格式不确定性，充当检查清单
3. 思维链：强制完整推理，减少遗漏
4. Few-shot 示例：用例子代替描述，精确传达期望
5. 约束与边界：防止 AI 过度发挥
6. 多轮迭代：拆解复杂任务，每轮聚焦一个方面

最重要的一点：Prompt 是手段，不是目的。好的 Prompt 让 AI 输出从 60 分提升到 85 分，但从 85 分到 95 分仍然需要你的专业判断和人工审查。

推荐阅读

• 用大模型将需求转换成 PRD 文档 — 模板约束技巧的深度应用
• AI 辅助 UI 设计实战 — 约束技巧在设计场景的应用
• AI 辅助产品开发全链路指南 — 全链路概览