高效提示词设计原则(CRISPE / RACE 等框架)
在提示词工程中,随意写一段自然语言往往无法获得理想输出。高效的提示词需要遵循一定的设计原则。业界常用 CRISPE 和 RACE 等结构化框架来指导提示词构建。这些原则不仅能提升模型响应质量,还能显著降低“试错成本”。
💡 对 PHP 工程师的类比:
写提示词 ≈ 编写函数签名 + 注释 + 单元测试用例。
你越明确地告诉 AI “输入是什么、输出要什么格式、边界条件如何”,AI 就越像一个可靠的函数。
✅ CRISPE 框架(推荐用于复杂任务)
CRISPE 是一种系统化提示词设计方法,包含以下六个维度:
| 字母 | 含义 | 说明 | PHP 类比 |
|---|---|---|---|
| C | Capacity and Role(能力与角色) | 明确 AI 扮演的角色(如“你是一位资深 Laravel 架构师”) | 函数的职责声明(docblock 中的 @author / @role) |
| R | Insight(背景/上下文) | 提供必要背景信息,帮助模型理解任务语境 | 函数调用前的全局状态或配置参数 |
| I | Statement(指令) | 清晰、具体地说明你要 AI 做什么 | 函数体中的核心逻辑指令 |
| S | Personality(语气/风格) | 指定输出风格(如“简洁技术文档风”或“面向新手的友好解释”) | 日志级别或输出格式(JSON vs HTML) |
| P | Experiment(示例) | 提供 1~3 个输入-输出示例(Few-shot Learning) | 单元测试中的 test cases |
| E | Expectation(预期格式) | 明确输出结构(如 JSON、Markdown 表格、数组等) | 函数返回类型声明(: array | string) |
📌 示例(使用 CRISPE):
角色(C):你是一位精通 PHP 和 Laravel 的后端工程师。
上下文(R):我们正在重构一个电商系统的订单模块,需要生成符合 PSR-12 规范的代码。
指令(I):请根据以下业务逻辑编写一个服务类方法。
风格(S):代码必须简洁、带类型声明、有 PHPDoc 注释。
示例(P):
输入:“创建订单时校验库存” → 输出:public function validateStock(array $items): bool { ... }
预期(E):仅输出 PHP 代码,不要解释,不要 markdown 包裹。
✅ RACE 框架(适用于快速任务)
RACE 更轻量,适合日常高频使用:
| 字母 | 含义 | 说明 |
|---|---|---|
| R | Role(角色) | 设定 AI 身份(如“技术面试官”、“SQL 优化专家”) |
| A | Action(行动) | 明确要执行的操作(“生成”、“分析”、“转换”) |
| C | Context(上下文) | 提供相关背景或限制条件 |
| E | Example(示例) | 给出输入输出样例(可选但强烈推荐) |
📌 示例(使用 RACE):
角色:你是 MySQL 性能调优专家。
行动:请为以下慢查询提供优化建议。
上下文:表 orders 有 500 万行,已建索引 on user_id,但查询仍慢。
示例:
输入:SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at DESC LIMIT 10;
输出:建议在 (status, created_at) 上建立复合索引,并避免 SELECT *。
🔑 六大核心原则详解(通用版)
无论使用哪种框架,以下六项原则是高质量提示词的基石:
Clear(清晰)
- 避免模糊词汇(如“更好”、“优化一下”)。
- 改为:“将响应时间从 2s 降低到 500ms 以内”。
Role-based(角色化)
- 模型行为高度依赖角色设定。
- ❌ “写一段代码” → ✅ “作为 Senior PHP Engineer,写一段符合 SOLID 原则的代码”。
Iterative(可迭代)
- 第一次输出不完美?把结果反馈回去继续优化。
- “刚才的 JSON 缺少 error_code 字段,请补充并保持其他结构不变。”
Structured(结构化输出)
- 强制要求格式,便于程序解析。
- “请以 JSON 格式返回,包含 keys: title, summary, tags(数组)”。
Precise(精准约束)
- 限制长度、语言、禁止内容等。
- “用不超过 100 字中文总结”,“不要提及竞品公司”。
Example-driven(示例引导)
- Few-shot 是最有效的提示技巧之一。
- 提供 1~3 个高质量示例,模型会自动模仿模式。
⚠️ 常见反模式(PHP 工程师需警惕)
| 反模式 | 问题 | 正确做法 |
|---|---|---|
| “帮我写个登录功能” | 太模糊,无上下文 | “用 Laravel 10 + Fortify 实现邮箱密码登录,返回 JSON API” |
| 不指定输出格式 | 返回混杂 Markdown/解释/代码 | “只输出 PHP 代码,不要任何额外文字” |
| 忽略安全边界 | 可能泄露敏感逻辑 | “不要假设数据库结构,仅基于我提供的字段生成” |
✅ 实战建议
- 模板化你的提示词:为常见任务(如生成单元测试、写 API 文档)建立提示词模板。
- 版本管理提示词:像管理代码一样用 Git 管理 prompt,记录每次优化效果。
- 结合 PHP 工具链:在 Laravel Command 或 Artisan 脚本中封装常用 AI 调用逻辑。

发表评论 取消回复