Skills: 提示词工程基础
最后更新：2026-08-31
提示词是 Skill 的灵魂——写得好，AI 是专家；写得差，AI 是复读机。
1. 提示词设计原则
(1) SPECIFIC 法则
| 字母 | 含义 | 示例 |
|---|---|---|
| S | Specific 具体 | "检查 SQL 注入"而非"检查安全" |
| P | Purpose 目的 | "防止生产环境数据泄露" |
| E | Example 示例 | 给出期望输出的样本 |
| C | Constraint 约束 | "不超过 500 字" |
| I | Interactive 交互 | "如信息不足则追问" |
| F | Format 格式 | "使用 Markdown 表格输出" |
| I | Iterative 迭代 | 测试后持续优化 |
(2) 常见反模式
| 反模式 | 问题 | 改进 |
|---|---|---|
| 过于笼统 | "审查代码" | "按安全/性能/可读性三维度审查" |
| 缺少格式 | 无输出约束 | "用表格输出，按严重程度排序" |
| 没有示例 | AI 输出不可控 | 提供 1-2 个参考输出 |
| 角色模糊 | AI 不知道自己是谁 | "你是资深安全审计专家" |
| 过于复杂 | 一次要求太多 | 分步骤，每步一个明确任务 |
2. 角色设定技巧
(1) 基础角色
MARKDOWN
你是 Python 后端开发专家。
(2) 增强角色
MARKDOWN
你是拥有 10 年经验的 Python 后端专家，专精 FastAPI 和 Django。
你特别擅长：
- 数据库优化与 ORM 调优
- RESTful API 设计
- 异步编程与并发处理
你的代码风格：简洁、类型安全、充分注释
(3) 多角色切换
MARKDOWN
# 多角色 Skill
当任务类型为"架构设计"时，你是系统架构师，关注可扩展性和性能。
当任务类型为"代码实现"时，你是高级工程师，关注代码质量和可维护性。
当任务类型为"调试"时，你是故障排查专家，关注根因分析和快速修复。
3. 任务分解技巧
(1) 单步任务
简单任务直接描述：
MARKDOWN
读取指定的 Python 文件，检查是否包含 type hints。
如果没有，为所有函数添加类型注解。
(2) 多步流程
复杂任务分步骤：
MARKDOWN
按以下步骤执行数据库迁移审查：
## 步骤 1：理解迁移文件
- 读取迁移文件内容
- 识别操作类型（CREATE/ALTER/DROP）
## 步骤 2：风险评估
- 检查是否有数据丢失风险（DROP COLUMN、DROP TABLE）
- 检查是否有锁表风险（ADD COLUMN without default）
- 检查是否有性能风险（大表 ADD INDEX）
## 步骤 3：生成建议
- 对于高风险操作，建议分步执行方案
- 对于低风险操作，确认可直接执行
(3) 条件分支
MARKDOWN
## 条件逻辑
- 如果是 Python 项目 → 运行 `ruff check`
- 如果是 TypeScript 项目 → 运行 `eslint`
- 如果是 Go 项目 → 运行 `go vet`
- 如果无法确定技术栈 → 先读取 package.json / pyproject.toml / go.mod
4. 输出约束技巧
(1) 格式约束
MARKDOWN
## 输出格式
严格使用以下 JSON 格式：
```json
{
"summary": "一句话总结",
"issues": [
{
"severity": "high|medium|low",
"location": "file:line",
"description": "问题描述",
"suggestion": "修改建议"
}
],
"score": 85
}
### (2) 长度约束
```markdown
## 输出约束
- 总结不超过 3 句话
- 每个问题不超过 100 字
- 修改建议包含代码示例
- 总输出不超过 1000 字
(3) 质量约束
MARKDOWN
## 质量要求
- 修改建议必须是可直接使用的代码，不是伪代码
- 严重程度必须有明确标准：high=安全漏洞/crash，medium=性能退化/可维护性差，low=风格/建议
- 不确定的问题标注"需人工确认"，不要猜测
5. 示例驱动方法
Few-shot 示例是控制输出质量的最有效手段：
MARKDOWN
## 示例
### 输入
```python
def get_user(id):
db = connect()
result = db.execute(f"SELECT * FROM users WHERE id = {id}")
return result
输出
📍 src/db.py:12 🔴 严重：SQL 注入漏洞 📝 使用 f-string 拼接 SQL，用户输入可直接注入恶意 SQL ✅ 修复：
PYTHON
def get_user(user_id: int) -> dict:
db = connect()
result = db.execute(
"SELECT * FROM users WHERE id = ?",
(user_id,)
)
return result.fetchone()
Alice 在提示词中加入了 3 个示例后，AI 输出的一致性从 60% 提升到 95%。Bob 说："示例是最好的老师——告诉 AI 你要什么，比描述你要什么有效 10 倍。"
---
## ❓ 常见问题
> **Q：提示词写多长合适？** **A：够用即可，通常 50-200 行。关键是具体和可操作，不是越长越好。过长的提示词会让 AI 迷失重点。**
> **Q：需要写负向约束吗（"不要做什么"）？** **A：需要，但要少。正向前置约束（"只做 X"）比负向约束（"不要做 Y"）更有效。AI 容易忽略"不要"指令。**
> **Q：示例要写几个？** **A：1-3 个足够。1 个示例展示格式，2-3 个示例覆盖边界情况。超过 5 个示例反而降低质量。**
---
## 📖 小节
- SPECIFIC 法则：具体、目的、示例、约束、交互、格式、迭代
- 角色设定要具体：专长、风格、经验层次
- 任务分解三层次：单步描述、多步流程、条件分支
- 输出约束：格式、长度、质量三管齐下
- Few-shot 示例是最有效的质量控制手段
---
## 📝 作业
1. **基础题（难度⭐）**：用 SPECIFIC 法则重写一个你之前写的简单提示词，对比效果差异。
2. **进阶题（难度⭐⭐）**：为一个"API 接口文档生成"Skill 编写完整提示词，包含角色、流程、约束和示例。
3. **挑战题（难度⭐⭐⭐）**：设计一个通用提示词模板框架，支持通过变量注入不同角色和规则，同时保持输出格式一致。