结构化提示词设计模式 — AI 开发教程

为什么提示词需要设计模式

大多数开发者写提示词的方式是凭感觉——想到什么写什么，遇到问题再加一句。这种方式在处理简单任务时勉强够用，但一旦面对复杂场景，输出质量就会极不稳定。提示词设计模式（Prompt Design Patterns）的提出，正是为了解决这个痛点：将经过验证的提示词编写经验提炼为可复用的模式，让每个人都能写出高质量的提示词。

设计模式的概念来源于软件工程——就像 GoF 的 23 种设计模式帮助开发者写出更优雅的代码一样，提示词设计模式帮助开发者构建更高效、更可靠的 AI 交互。本文将深入讲解六种核心模式，每种模式都配有完整的代码示例和实战场景。

模式一：角色设定模式

角色设定是最基础也最被低估的模式。它不只是简单地说"你是一个XX专家"，而应该包含三个层次：身份定义（你是谁）、能力边界（你能做什么、不能做什么）、行为准则（你应该怎么做）。一个精心设计的角色提示词可以让模型的行为发生质的变化。

角色设定的关键在于具体。不要说"你是一个Python专家"，而应该说"你是一个拥有10年经验的Python后端开发工程师，精通Django、FastAPI、异步编程和数据库优化，代码风格遵循PEP 8和Google Python Style Guide"。细节越多，模型的角色扮演越到位。但也要注意不要过度约束——过于狭窄的角色设定会限制模型的创造力。

以下是一个完整的角色设定模式示例，展示了如何为代码审查场景构建专业角色：

from openai import OpenAI

client = OpenAI(
    api_key="your-deepseek-api-key",
    base_url="https://api.deepseek.com"
)

SYSTEM_PROMPT = """你是一位资深代码审查专家，拥有以下背景和能力：

【身份】
- 10年Python后端开发经验
- 5年技术主管经验，管理过20人的开发团队
- 开源项目维护者（star数累计10k+）

【能力范围】
- 代码质量审查：命名规范、代码结构、设计模式
- 安全审查：SQL注入、XSS、权限漏洞
- 性能审查：时间复杂度、内存使用、IO瓶颈
- 可维护性审查：注释质量、模块耦合度、测试覆盖

【行为准则】
- 先肯定做得好的地方，再指出需要改进的地方
- 每个问题提供具体的修改建议和示例代码
- 按严重程度排序（致命/严重/建议）
- 不说模糊词语，确保新人也能看懂

【不做什么】
- 不做主观风格评判（除非违反PEP 8）
- 不对未提供上下文的代码做猜测性审查
- 不批评开发者本人，只评价代码
"""

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": "请审查以下代码：【代码内容】"}
    ],
    temperature=0.3, max_tokens=2000
)
print(response.choices[0].message.content)

模式二：模板模式

模板模式的核心思想是将输出结构预定义为固定格式，让AI在框架内填充内容。这在需要批量生成一致性输出的场景中特别有用——比如批量生成产品描述、API文档、周报等。一个好的模板应包含：固定标题和结构、占位符标记、格式规范说明。

模板模式的最大优势是输出可控性。当你的下游系统（比如一个自动化流水线）依赖固定格式的输入时，模板模式可以保证AI的输出始终是结构化的、可解析的。结合JSON Schema或Pydantic验证，你可以构建出极其可靠的AI数据处理管线。

模式三：约束模式

约束模式通过明确边界条件来控制AI的输出行为。这个模式看似简单，但在实际应用中极为有效。约束分为三类：格式约束（如用JSON输出）、内容约束（如不超过200字）、行为约束（如如果不知道答案就说不知道）。

一个常见的误区是只给正向指令而忽略负向约束。好的约束模式应该同时告诉AI要做什么和不要做什么。例如，在客服场景中，不仅要告诉AI态度要友好，还要告诉它不要承诺退款金额、不要讨论政治话题、不要透露公司内部信息。

CONSTRAINTS_PROMPT = """请回答以下问题，但必须遵守所有约束条件。

【正向约束 - 必须做到】
1. 每个回答以一句话总结开头
2. 给出至少2个具体示例
3. 如果涉及代码，必须是可以直接运行的完整代码
4. 引用来源时给出具体出处（论文名、年份、作者）

【负向约束 - 绝不能做】
1. 不要使用不确定表达
2. 不要输出超过500字的内容
3. 不要说"作为一个AI模型"之类的免责声明
4. 不要编造不存在的数据或引用
5. 不要在代码中使用未导入的库

【边界检查】
如果问题超出你的知识范围，直接回复：
"此问题超出我的知识范围，建议查阅以下资源：[给出2-3个具体资源]"

问题：{user_question}
"""

模式四：分步模式

分步模式是Chain-of-Thought的工程化应用。与其笼统地说一步步思考，不如明确定义分几步、每步做什么。这样不仅提升输出质量，还能让中间步骤的结果被下游系统使用。

分步模式特别适合多阶段任务：需求分析→方案设计→代码实现→测试用例→部署说明。每一步的输出都是下一步的输入，形成一条完整的思维链。在复杂的企业级应用中，分步模式可以将一个不可能一次性完成的大任务分解为多个AI可以胜任的小任务。

STEP_BY_STEP = """请按照以下四个步骤完成任务：

## 步骤1：需求澄清
- 识别用户的核心需求
- 列出所有隐含需求
- 确认需求的优先级

## 步骤2：方案设计
- 提出2-3个可行方案
- 对比各方案的优缺点
- 推荐最佳方案并说明理由

## 步骤3：详细实现
- 给出推荐方案的详细实现
- 包含完整的代码（如果需要）
- 说明关键设计决策

## 步骤4：验证与优化
- 检查方案是否满足所有需求
- 指出潜在风险和边界情况
- 给出后续优化建议
"""

messages = [
    {"role": "system", "content": "你是解决方案架构师，严格按步骤输出。"},
    {"role": "user", "content": user_task + "

" + STEP_BY_STEP}
]

response = client.chat.completions.create(
    model="deepseek-chat", messages=messages, temperature=0.3
)
print(response.choices[0].message.content)

模式五：反思模式

反思模式让AI在输出后对自己的内容进行自我审查。这不是简单的再检查一遍，而是一个结构化的质量保障流程：初始输出→多维度评估→识别问题→修正输出。反思模式特别适合对输出质量有严格要求的场景，如法律文件生成、医疗咨询、金融分析等。

反思模式的关键是制定明确的评估标准。模糊的评估标准（如看看有没有问题）效果很差，而具体的评估标准（如检查第3段的事实陈述是否与第1段矛盾）效果显著。建议为每个应用场景定制评估checklist，包含5-10个具体的检查项。

模式六：组合模式

在实际项目中，单一模式往往不够用。组合模式将多个模式融合使用——例如，先用角色模式定义Agent身份，再用模板模式规范输出格式，最后用反思模式保证质量。关键在于模式之间的衔接：一个模式的输出要能自然地成为下一个模式的输入。

以下代码展示了如何将角色模式、分步模式和反思模式组合成一个完整的代码审查工作流：

import json
from openai import OpenAI

client = OpenAI(api_key="your-deepseek-api-key", base_url="https://api.deepseek.com")

class CompositePromptEngine:
    def __init__(self):
        self.role = """你是资深代码审查专家，10年Python经验。
审查标准：正确性 > 安全性 > 性能 > 可维护性 > 风格。"""
        self.steps = """按以下步骤审查：
步骤1：整体结构分析
步骤2：逐函数审查
步骤3：安全漏洞扫描
步骤4：性能瓶颈识别
步骤5：改进建议汇总"""
        self.reflection = """审查完成后请自我检查：
1. 每个建议是否具体可执行？
2. 是否遗漏了明显的问题？
3. 评分是否客观合理？"""

    def review(self, code):
        full_prompt = f"{self.role}

{self.steps}

代码：
```python
{code}
```

{self.reflection}"
        response = client.chat.completions.create(
            model="deepseek-chat",
            messages=[{"role": "user", "content": full_prompt}],
            temperature=0.2
        )
        return response.choices[0].message.content

engine = CompositePromptEngine()
result = engine.review("def get_user(uid): return db.execute(f'SELECT * FROM users WHERE id={uid}')")
print(result)

模式选择决策树

面对一个具体的提示词任务，如何选择合适的模式？以下决策树可以作为参考：

需要角色扮演？→使用角色模式。定义身份、能力和行为准则。
输出需要固定格式？→使用模板模式。先定义结构，让AI在框架内填充。
需要严格控制输出？→使用约束模式。正向和负向约束都要明确。
任务复杂度高？→使用分步模式。将大任务分解为多个小步骤。
对质量要求极高？→使用反思模式。让AI自我审查并修正。
任务涉及多个维度？→使用组合模式。按需融合多种模式。

经验法则：从最简单的模式开始，观察输出质量，再逐步叠加其他模式。不要一开始就堆砌所有模式——过度设计提示词不仅浪费token，还可能导致模型在所有方向上都表现平庸。

实战：为企业级应用设计提示词

让我们综合运用上述模式，为一个真实的业务场景——智能客服工单分类系统设计提示词。这个系统需要理解客户问题、分类问题类型、判断紧急程度、提取关键信息、生成标准化工单。

CLASSIFIER_PROMPT = """
【角色】你是某SaaS平台的智能工单分类系统。

【能力】
- 理解中文客户问题，判断问题类型
- 评估紧急程度（P0-P3）
- 提取关键实体（用户名、产品、版本等）

【约束】
- 只使用以下分类：[账号问题、支付问题、功能故障、功能咨询、投诉建议]
- 如果问题描述不清晰，分类为"待确认"
- 紧急程度P0仅用于"系统完全不可用"场景

【输出模板】
{
  "category": "分类", "priority": "P0/P1/P2/P3",
  "summary": "20字以内摘要",
  "entities": {"user": "", "product": "", "version": ""},
  "confidence": 0.0
}

【分步推理】
步骤1：通读客户消息，识别核心问题
步骤2：匹配最合适的分类
步骤3：根据影响范围判断紧急程度
步骤4：提取所有可识别的实体
步骤5：评估分类置信度

【自我检查】
输出前检查：分类是否在允许列表中？P0判断是否过于宽松？实体提取是否完整？
"""

messages = [
    {"role": "system", "content": CLASSIFIER_PROMPT},
    {"role": "user", "content": "你好，我们公司买了你们的专业版，但是下载报表功能一直转圈圈，等了10分钟都没反应。最新版v3.2.1，账号zhangsan@company.com，很着急月底要做汇报。"}
]
response = client.chat.completions.create(model="deepseek-chat", messages=messages, temperature=0.1)
print(json.loads(response.choices[0].message.content))

常见错误与改进方法

错误1：角色设定过于泛化。改进：将"你是AI助手"改为"你是精通React 18和TypeScript的前端架构师，擅长性能优化和组件设计"。越具体，效果越好。

错误2：约束过多导致模型无所适从。改进：约束控制在5-8条，超过10条时模型可能忽略部分约束。

错误3：模板过于灵活。改进：模板中可选字段是输出不稳定的常见原因，尽量让所有字段都是必填的。

错误4：反思模式流于形式。改进：将反思标准具体化、可量化，从"检查是否有问题"改为"检查第1段和第3段是否有数据矛盾"。

总结与展望

提示词设计模式的价值不在于模式本身，而在于它将写提示词从一门玄学变成了一门工程。掌握了这六种模式，你就拥有了一套系统化的工具箱——面对任何提示词任务，都能快速选择合适的模式组合，输出高质量的结果。提示词工程的未来方向包括自动化模式选择、社区维护的开源模式库、以及基于A/B测试数据自动调整提示词的动态优化。掌握基础模式是第一步，持续实践和迭代才是关键。

想亲手编排这个技能链？

在技能链中打开 →