很多人使用 WorkBuddy 时，习惯像搜索引擎一样输入简短指令——"写个函数"、"帮我重构"。这种方式能工作，但远未发挥 WorkBuddy 的全部潜力。提示词工程（Prompt Engineering）是与 AI 高效协作的核心技能，好的提示词能让输出质量从"能用"跃升到"惊艳"。本文分享 10 个经过实战验证的高级技巧，每一个都附有前后对比示例。
不要把所有信息堆在一句话里，用结构化格式提供上下文，让 WorkBuddy 精准理解每个信息的作用：
# ❌ 模糊的上下文
帮我写个用户注册的接口，项目用的是 FastAPI 和 MySQL，
密码要加密，还要发邮件验证
# ✅ 结构化上下文
帮我实现用户注册接口，上下文如下：
## 技术栈
- 框架：FastAPI
- 数据库：MySQL 8.0 (SQLAlchemy ORM)
- 认证：JWT (python-jose)
## 业务规则
- 密码使用 bcrypt 加密，cost factor = 12
- 注册后发送验证邮件，24小时内有效
- 用户名：3-20字符，字母数字下划线
- 邮箱：需唯一，格式校验
## 现有代码
- Model 定义：见 models/user.py
- 邮件服务：见 services/email.py（已实现 send_verification）
- 数据库 Session：使用 get_db 依赖注入结构化上下文让 WorkBuddy 不需要猜测，直接生成与现有代码风格一致的实现。
复杂任务不要一次性要求完成，拆分为有序步骤，每步有明确的输入和预期输出：
# ❌ 笼统要求
帮我重构整个用户模块，优化代码质量
# ✅ 分步拆分
请按以下步骤重构用户模块：
**Step 1 - 分析现状**
读取 src/user/ 下所有文件，列出当前问题：
- 代码重复、过长函数、缺失类型标注、测试覆盖不足
**Step 2 - 重构数据层**
- 将 ORM 查询抽取到 Repository 类
- 添加类型标注和输入验证
- 保持现有接口不变
**Step 3 - 重构服务层**
- 提取业务逻辑到 Service 类
- 消除重复代码
- 添加错误处理和日志
**Step 4 - 补充测试**
- 为每个重构后的类编写单元测试
- 目标覆盖率 ≥ 80%
每步完成后展示变更内容，等我确认再继续下一步。明确约束输出的格式、范围、风格，避免得到"差不多"的结果：
# ❌ 无约束
写一个 API 文档
# ✅ 严格约束
为用户管理 API 编写文档，严格遵循以下约束：
## 格式约束
- 使用 OpenAPI 3.0 YAML 格式
- 每个端点必须包含：summary、description、parameters、requestBody、responses、security
## 内容约束
- 所有描述使用中文
- 状态码覆盖：200、201、400、401、403、404、422、500
- 错误响应统一使用 ErrorResponse schema
- 分页参数统一：page (int, default=1)、per_page (int, default=20, max=100)
## 风格约束
- 路径使用 kebab-case：/api/user-groups
- Schema 名称使用 PascalCase：UserGroupResponse
- 示例数据使用真实感数据（不用 "string"、"foo"）给 WorkBuddy 设定专业角色，激活其领域知识：
# ❌ 无角色
帮我检查这段代码有没有问题
# ✅ 角色设定
你现在是一位有 10 年经验的安全审计专家，专精 Web 应用安全。
请以 OWASP Top 10 为框架审查以下代码，对每个发现的问题：
1. 标注对应的 OWASP 分类（如 A01:2021-Broken Access Control）
2. 评估风险等级（Critical/High/Medium/Low）
3. 给出具体修复代码
4. 提供验证修复是否有效的测试方法用 2-3 个示例展示你期望的输入-输出模式，比长篇描述更有效：
# ❌ 纯描述
帮我写 commit message，要简洁明了
# ✅ Few-shot 引导
帮我写 commit message，参考以下风格：
示例1：
变更：修复了用户搜索时特殊字符导致 SQL 错误的问题
Message: fix(search): escape special chars in user search query
示例2：
变更：新增了导出用户数据为 CSV 的功能
Message: feat(export): add CSV export for user data
示例3：
变更：将登录页面的按钮颜色从蓝色改为绿色
Message: style(login): update button color to green
现在请为以下变更写 commit message：
变更：{你的实际变更}要求 WorkBuddy 先推理再输出，显著提升复杂问题的准确率：
# ❌ 直接要结果
这个 SQL 查询有没有性能问题？
# ✅ 链式思考
请分析这个 SQL 查询的性能，按以下步骤思考：
1. **执行计划分析**：推断数据库会使用什么执行计划
2. **瓶颈识别**：哪个步骤是性能瓶颈（全表扫描？嵌套循环？排序？）
3. **数据量估算**：假设各表的数据量级，估算扫描行数
4. **优化方案**：给出 2-3 个优化方案，分析各自的优劣
5. **推荐方案**：选择最优方案，给出改写后的 SQL 和所需索引
请先展示思考过程，再给出最终结论。不要期望一次得到完美结果，通过多轮对话渐进精炼：
# 第一轮：快速原型
写一个 React 用户列表组件，只需要基本功能：展示、搜索、分页
# 第二轮：补充细节
在上面的基础上添加：
- 删除确认弹窗
- 批量选择和批量删除
- 空状态展示
# 第三轮：打磨体验
再优化：
- 搜索防抖 300ms
- 加载骨架屏
- 列表项进入动画
# 第四轮：质量保障
为这个组件编写：
- 单元测试（Jest + Testing Library）
- Storybook story
- 无障碍审查明确排除不想要的输出，避免常见陷阱：
# ❌ 只说想要什么
写一个 Python 数据处理脚本
# ✅ 正向 + 负向约束
写一个 Python 数据处理脚本，要求：
**必须：**
- 使用 pandas 2.x
- 处理缺失值用中位数填充
- 输出 UTF-8 编码的 CSV
**禁止：**
- 不要使用 eval() 或 exec()
- 不要硬编码文件路径，使用 argparse
- 不要忽略异常，所有 IO 操作需要 try-except
- 不要使用已废弃的 pandas API（如 .append()）
- 不要在循环中逐行处理，使用向量化操作提供一个参考样本，让 WorkBuddy 模仿其风格和结构：
# ❌ 从零开始
写一个技术方案文档
# ✅ 锚定参考
请参考以下已有方案的结构和风格，为"消息推送系统"编写技术方案：
参考文档：docs/tech-specs/payment-system.md
保持以下一致：
- 章节结构：背景 → 目标 → 架构设计 → 接口定义 → 数据模型 → 非功能需求 → 风险评估
- 详细程度：每个接口都有请求/响应示例
- 图表风格：使用 Mermaid 语法画架构图和时序图
- 术语使用：与项目 glossary.md 保持一致当你不确定怎么写好提示词时，让 WorkBuddy 帮你优化：
# 让 WorkBuddy 优化你的提示词
我需要让 AI 帮我做代码审查，但我写的提示词效果不好：
原始提示词："帮我看看代码有没有bug"
请帮我优化这个提示词，使其：
1. 明确审查维度
2. 约束输出格式
3. 设定专业角色
4. 添加思考链
输出优化后的提示词模板，我用它来审查代码。WorkBuddy 会输出一个精心设计的提示词模板，你可以保存为 Skill 的 system.md 反复使用。
将多个技巧组合使用，效果倍增。以下是一个综合示例：
你是一位资深全栈工程师，负责实现"实时协作编辑"功能。（技巧4：角色设定）
## 上下文（技巧1：结构化上下文）
- 技术栈：Vue3 + FastAPI + WebSocket + Redis
- 现有代码：见 src/collab/ 目录
- 冲突解决策略：OT (Operational Transform)
## 任务拆分（技巧2：显式拆分）
Step 1: 设计 WebSocket 消息协议
Step 2: 实现服务端 OT 引擎
Step 3: 实现客户端编辑器集成
Step 4: 编写集成测试
## 约束（技巧3+8：正负约束）
- 消息格式必须使用 JSON Schema 验证
- 延迟不超过 100ms（局域网环境）
- 禁止使用定时轮询，必须用 WebSocket 推送
- 禁止在客户端做冲突解决，必须在服务端
## 参考（技巧9：锚定）
- 参考现有 IM 模块的 WebSocket 实现：src/im/websocket.py
- 参考 OT 算法论文：docs/references/ot-paper.pdf
请先展示 Step 1 的设计，我确认后继续。（技巧7：渐进精炼）