AI 提示词工程：从随手问到稳定输出

很多工程师第一次用大模型时，得到的回复是这样的：

用户：写一个 Python 函数，把列表里的数字排序。 AI：（返回了一个用 sort() 的标准实现） 用户：能不能改成归并排序？ AI：好的（返回归并排序） 用户：再改成 stable sort？ AI：好的（返回又一个版本）

来回三轮，每次的代码风格、注释、错误处理都不一致。这不是 AI 不好用，是你的提示词在反复”重新定义”任务。

本文给出一套可复用、可学习的提示词工程方法，让你的输出第一次就接近预期。

一、三层结构：角色 / 任务 / 约束

所有稳定的提示词都可以拆成三层：

1. 角色 (Role)

告诉 AI 它是谁。角色决定了它的知识范围、表达风格、默认假设。

你是一位有 10 年 Python 工程经验的资深工程师，专注于高性能数值计算。

2. 任务 (Task)

明确说出你要它做什么。任务要具体、可验证。

请实现一个稳定的归并排序函数，输入是包含数字的列表，输出是排序后的新列表（不修改原列表）。

3. 约束 (Constraints)

列出必须满足的硬性条件：性能、格式、依赖、错误处理、测试覆盖等。

约束：
- 时间复杂度 O(n log n)，空间复杂度 O(n)
- 接受 key= 参数（参考 sorted() 签名）
- 包含类型注解（Python 3.10+ 风格）
- 包含 docstring（Google 风格）
- 至少 3 个单元测试，覆盖空列表、单元素、已排序三种情况
- 代码不超过 50 行（不含测试）

三层齐全后，第一次输出的可用率通常就能从 30% 提升到 80%。

二、完整示例

把上面三层组合起来：

你是一位有 10 年 Python 工程经验的资深工程师，专注于高性能数值计算。

任务：
请实现一个稳定的归并排序函数，输入是包含数字的列表，输出是排序后的新列表（不修改原列表）。

约束：
- 时间复杂度 O(n log n)，空间复杂度 O(n)
- 接受 key= 参数（参考 sorted() 签名）
- 包含类型注解（Python 3.10+ 风格）
- 包含 docstring（Google 风格）
- 至少 3 个单元测试，覆盖空列表、单元素、已排序三种情况
- 代码不超过 50 行（不含测试）

输出格式：
- 先简要说明实现思路（不超过 5 行）
- 然后给出完整代码
- 最后给一个使用示例

按这个提示词跑 Claude/GPT-4，首次输出通常就能直接用。

三、5 个常见误区

误区 1：把任务当聊天

“帮我写个排序”——这种提示词相当于跟新同事说”做个东西”，得到的只能是猜测。任务描述要像 PR description。

误区 2：约束放在最后，且不够具体

“代码要优雅”——什么是优雅？每个人的标准不同。要量化：行数、复杂度、命名规范、注释密度。

误区 3：缺少输出格式约束

“给我写个例子”——AI 可能给你 1 个例子，也可能给你 10 个。明确说”3 个例子，每个不超过 10 行”。

误区 4：不指定角色导致知识错位

“用 Rust 写个深度学习框架”——AI 不知道是写 high-level 的设计还是 low-level 的实现。指定角色是知识边界的快捷方式。

误区 5：一次提示问太多事

“写一个完整的高并发服务”——AI 的 attention 会被稀释，每个部分都写得浅。拆成多个有依赖的子任务。

四、把提示词模板沉淀下来

提示词工程的真正杠杆是复用。建议你维护一个提示词模板库：

  • 按场景分类（代码生成、文档撰写、数据分析、debug）
  • 每个模板标号版本号，每次迭代留 diff
  • 团队/个人共享最佳实践
  • 把特别有效的提示词固化为工具的 system prompt

我自己的做法是在 Obsidian 里维护 prompts/ 目录，按”用途”和”质量评级”两个维度组织。当我第三次需要写类似提示词时，就抽出模板，套上当前任务的具体内容。

五、小结

提示词不是”问 AI 怎么问”的玄学，是有结构、有方法、有可复用模板的工程实践。

三个核心原则：

  1. 三层结构：角色 / 任务 / 约束
  2. 可验证：每个约束都应该可以被检查（行数、复杂度、测试覆盖）
  3. 复用优先：把反复用的提示词沉淀成模板

下次你准备给 AI 发提示词时，先停 30 秒，把角色、任务、约束各写一行——你大概率会发现首次输出可用率提升 50% 以上。

相关阅读：