Prompt Engineering 实用指南：让大模型更好地为你工作

Prompt Engineering 这个词听起来很唬人，但本质上就是「如何把你的需求清楚地传达给 AI」。就像写需求文档一样——你描述得越清晰，开发出来的东西就越接近你想要的。区别在于，AI 不会主动问你「这里你想怎么处理？」，它只会根据你给的信息做最「合理」的推测。

我见过太多人抱怨「AI 不好用」「回答不准确」，但仔细看他们的 prompt，通常就是一句话甩过去，比如「帮我写个登录页面」。这就像你跟设计师说「帮我设计个 logo」但不给任何品牌信息一样——你怎么能期望得到满意的结果？

1. 提示词工程的核心原则

原则一：明确 > 简洁

与 AI 沟通时，明确性远比简洁性重要。不要担心 prompt 太长——大模型的上下文窗口很大，多给信息永远比少给好。

# 模糊的 prompt
"写一个 API"

# 明确的 prompt
"用 Node.js + Express 写一个 RESTful API 端点：
- 路径：POST /api/users/register
- 请求体：{ email: string, password: string, name: string }
- 验证规则：email 格式校验，密码至少 8 位
- 成功返回：{ id, email, name, createdAt }，状态码 201
- 错误返回：{ error: string, details?: object }，状态码 400/409
- 使用 bcrypt 加密密码，不要返回密码字段"

原则二：给示例比给描述更有效

这就是 Few-shot prompting。与其描述你想要什么格式，不如直接给一两个例子。

# 用描述（效果一般）
"把下面的 JSON 转换成 Markdown 表格，
第一列是名字，第二列是年龄"

# 用示例（效果更好）
"把 JSON 转换成 Markdown 表格，格式如下：

输入：[{"name": "Alice", "age": 25}]
输出：
| 名字 | 年龄 |
|------|------|
| Alice | 25 |

现在转换这个 JSON：
[{"name": "Bob", "age": 30}, ...]"

原则三：指定输出格式

如果你不指定输出格式，AI 会用它认为「最好」的格式——通常不是你想要的。明确告诉它：用 JSON 还是 Markdown？要不要代码注释？要不要解释？

2. 六个实战技巧

技巧 1：角色设定（System Prompt）

给 AI 一个角色，能显著提高输出的专业性和一致性。

"你是一个资深的 Vue.js 前端架构师，有 8 年以上的开发经验。
你偏好 Composition API + TypeScript + UnoCSS 的技术栈。
回答时：
- 优先推荐最佳实践，而不是「能用就行」的方案
- 如果有多种方案，列出优缺点让我选择
- 代码示例使用 <script setup lang="ts"> 语法
- 不要过度解释基础概念，我有前端开发基础"

技巧 2：思维链（Chain of Thought）

让 AI 一步一步推理，而不是直接给答案。对于复杂问题特别有效。

"分析这段代码的性能问题，请按以下步骤：
1. 先识别可能的性能瓶颈
2. 对每个瓶颈解释为什么它是问题
3. 给出具体的优化建议
4. 最后给出优化后的完整代码

[粘贴代码]"

技巧 3：约束条件

告诉 AI 什么不要做，和告诉它什么要做一样重要。

"帮我重写这个函数，要求：
- 不要使用 any 类型
- 不要使用 class 语法，用纯函数
- 不要引入新的依赖
- 保持函数签名不变
- 不要加注释，代码要自解释"

技巧 4：迭代优化

第一次的输出不满意很正常。关键是如何有效地迭代：

具体指出问题：「这个实现有问题」→「这个实现在并发场景下会有竞态条件，因为...」
提供对比：「我期望的输出是这样的：[示例]，但你给的是那样的」
缩小范围：「只修改 handleSubmit 函数，其他部分保持不变」

技巧 5：结构化输入

用清晰的结构组织你的 prompt，AI 会更好地理解你的意图。

"## 任务
将现有的 Options API 组件迁移到 Composition API

## 输入
[粘贴原始组件代码]

## 要求
- 使用 <script setup> 语法
- data → ref/reactive
- computed → computed()
- methods → 普通函数
- watch → watch/watchEffect
- 生命周期钩子使用 onMounted 等

## 输出格式
只输出完整的 .vue 文件代码，不需要解释"

技巧 6：让 AI 自我检查

在 prompt 末尾加一句自检指令，能显著减少错误。

"...生成代码后，请自行检查：
1. 是否有未处理的 null/undefined 情况？
2. 是否有潜在的内存泄漏（事件监听器、定时器）？
3. 类型定义是否完整，有没有用 any？
4. 是否符合我上面提到的所有约束条件？
如果发现问题，直接修复后再输出最终版本。"

3. 开发者常用 Prompt 模板

Code Review 模板

"Review 这段代码，关注以下方面：
- 安全性：是否有注入、XSS 等风险
- 性能：是否有不必要的渲染、内存泄漏
- 可维护性：命名是否清晰，逻辑是否简洁
- 边界情况：空值、异常输入的处理
按严重程度排序，给出具体的修改建议和代码。"

Bug 分析模板

"## 问题描述
[描述 bug 现象]

## 复现步骤
1. ...
2. ...

## 期望行为
[应该怎样]

## 实际行为
[实际怎样]

## 相关代码
[粘贴代码]

请分析可能的原因，按可能性从高到低排列，
并给出每个原因的修复方案。"

4. 常见的反模式

过于依赖角色扮演：「你是世界上最好的程序员」这类 prompt 没有实际效果。AI 不会因为你夸它就变聪明，具体的技术要求比模糊的角色设定有用得多。

信息过载：把整个项目的代码全部粘贴进去，让 AI 自己找重点。这会降低回答质量。只提供相关的代码和上下文。

不迭代就放弃：第一次输出不满意就换个模型或放弃。大多数情况下，一两轮迭代就能得到满意的结果。