Prompt-to-Code工作流¶
💬 掌握提示词编程方法论，让AI准确理解你的意图并生成高质量代码
📖 本章概述¶
提示词（Prompt）是人机交互的桥梁。好的提示词能让AI生成高质量的代码，差的提示词则可能导致错误或不理想的结果。本章将系统介绍Prompt-to-Code的工作流程和技巧。
学习目标¶
- 掌握有效的代码提示词编写技巧
- 学会分解复杂任务
- 理解迭代优化策略
- 建立多轮对话的最佳实践
🎯 提示词基础¶
什么是好的提示词¶
Text Only
┌─────────────────────────────────────────────────────────────┐
│ 好提示词的要素 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📋 明确的目标 │
│ - 清楚说明要做什么 │
│ - 定义成功的标准 │
│ - 指定输出格式 │
│ │
│ 📚 充足的上下文 │
│ - 技术栈和环境 │
│ - 现有代码结构 │
│ - 相关约束条件 │
│ │
│ 📏 具体的约束 │
│ - 代码规范要求 │
│ - 性能要求 │
│ - 兼容性要求 │
│ │
│ 📖 示例参考 │
│ - 类似功能的代码 │
│ - 期望的输出样式 │
│ - 不要做的事 │
│ │
└─────────────────────────────────────────────────────────────┘
提示词对比示例¶
❌ 差的提示词：
✅ 好的提示词：
Text Only
使用React和TypeScript实现一个用户登录功能：
需求：
1. 登录表单包含邮箱和密码输入框
2. 表单验证：
- 邮箱格式验证
- 密码至少8位，包含字母和数字
3. 提交后调用API: POST /api/auth/login
4. 成功后保存token到localStorage并跳转到首页
5. 失败时显示错误提示
技术要求：
- 使用React Hook Form进行表单管理
- 使用Tailwind CSS进行样式
- 遵循项目现有的组件结构
参考项目中的RegisterForm组件风格。
📝 提示词结构¶
基础结构模板¶
Markdown
## 角色设定（可选）
你是一个[领域]专家，精通[技术栈]。
## 任务描述
请[动词][具体任务]。
## 详细需求
1. [需求1]
2. [需求2]
3. [需求3]
## 技术约束
- 使用[框架/库]
- 遵循[规范]
- 兼容[环境]
## 输出要求
- 格式：[代码/文档/解释]
- 语言：[编程语言]
- 注释：[是/否]
## 参考示例（可选）
[示例代码或描述]
完整示例¶
Markdown
## 角色
你是一个Python后端开发专家，精通FastAPI和SQLAlchemy。
## 任务
实现一个RESTful API端点，用于管理博客文章的评论。
## 需求
1. POST /api/posts/{post_id}/comments
- 创建新评论
- 验证用户登录状态
- 评论内容不能为空，最长500字
2. GET /api/posts/{post_id}/comments
- 获取文章评论列表
- 支持分页（page, page_size）
- 按时间倒序排列
3. DELETE /api/comments/{comment_id}
- 删除评论
- 只能删除自己的评论
## 技术要求
- 使用FastAPI框架
- 使用SQLAlchemy ORM
- 使用Pydantic进行数据验证
- JWT认证
- 异步数据库操作
## 代码规范
- 使用类型注解
- 添加docstring
- 遵循PEP 8
## 输出
完整的Python代码，包含：
- 路由定义
- Pydantic模型
- 数据库模型（如果需要新增）
🔄 任务分解策略¶
为什么需要分解任务¶
Text Only
┌─────────────────────────────────────────────────────────────┐
│ 任务分解的必要性 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 大任务的问题： │
│ ❌ AI容易遗漏细节 │
│ ❌ 代码质量难以控制 │
│ ❌ 调试困难 │
│ ❌ 难以迭代优化 │
│ │
│ 分解后的优势： │
│ ✅ 每个子任务目标明确 │
│ ✅ 更容易验证正确性 │
│ ✅ 便于逐步迭代 │
│ ✅ 代码质量更高 │
│ │
└─────────────────────────────────────────────────────────────┘
分解方法¶
1. 按功能模块分解
Text Only
原始任务：开发一个用户管理系统
分解后：
├── 任务1：设计数据库模型
│ └── User模型（id, email, password_hash, created_at）
│
├── 任务2：实现用户注册
│ ├── 注册API
│ ├── 密码加密
│ └── 邮箱验证
│
├── 任务3：实现用户登录
│ ├── 登录API
│ ├── JWT生成
│ └── 会话管理
│
├── 任务4：实现用户信息管理
│ ├── 获取用户信息API
│ ├── 更新用户信息API
│ └── 头像上传
│
└── 任务5：实现权限管理
├── 角色定义
├── 权限检查中间件
└── 管理员功能
2. 按技术层次分解
Text Only
原始任务：创建一个待办事项API
分解后：
├── 层1：数据层
│ ├── 数据库模型定义
│ └── 数据访问函数
│
├── 层2：业务层
│ ├── 业务逻辑实现
│ └── 数据验证
│
├── 层3：接口层
│ ├── API路由定义
│ └── 请求处理
│
└── 层4：测试层
├── 单元测试
└── 集成测试
3. 按复杂度分解
Text Only
┌─────────────────────────────────────────────────────────────┐
│ 复杂度分层法 │
├─────────────────────────────────────────────────────────────┤
│ │
│ MVP（最小可行产品） │
│ └── 核心功能，最简实现 │
│ │
│ 迭代1：基础完善 │
│ └── 错误处理、输入验证 │
│ │
│ 迭代2：功能增强 │
│ └── 高级功能、性能优化 │
│ │
│ 迭代3：完善细节 │
│ └── 文档、测试、代码优化 │
│ │
└─────────────────────────────────────────────────────────────┘
分解示例¶
原始需求：
分解后的提示词序列：
Markdown
# 任务1：基础文件上传
实现一个简单的文件上传API：
- POST /api/upload
- 接收multipart/form-data
- 保存到本地uploads目录
- 返回文件路径
# 任务2：添加文件类型验证
在任务1基础上添加：
- 只允许图片(jpg, png, gif)和PDF
- 文件大小限制5MB
- 返回详细错误信息
# 任务3：添加图片预览
在任务2基础上添加：
- 图片文件生成缩略图
- GET /api/files/{id}/preview
- 返回缩略图或PDF图标
# 任务4：添加文件管理
在任务3基础上添加：
- GET /api/files 列出所有文件
- DELETE /api/files/{id} 删除文件
- 文件元数据存储（使用SQLite）
🔄 迭代优化策略¶
迭代工作流¶
Text Only
┌─────────────────────────────────────────────────────────────┐
│ 迭代优化循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ │
│ │ 初始提示 │ │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ AI生成 │ --> │ 评估结果 │ │
│ └──────────┘ └────┬─────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ │ │ │
│ 满足需求 不满足需求 │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 完成 │ │ 优化提示 │ │
│ └──────────┘ └────┬─────┘ │
│ │ │
│ └──────> 循环 │
│ │
└─────────────────────────────────────────────────────────────┘
优化技巧¶
1. 具体化反馈
Text Only
❌ 模糊反馈：
"代码不对，重写"
✅ 具体反馈：
"代码有以下问题：
1. 第15行缺少空值检查，当user为null时会报错
2. 没有处理网络请求失败的情况
3. 返回值类型应该是Promise<User>而不是User
请修复这些问题并重新生成。"
2. 增量修改
3. 提供示例
Text Only
请按照以下风格重写代码：
期望的风格（示例）：
```typescript
/**
* 计算用户折扣
* @param user - 用户信息
* @param amount - 消费金额
* @returns 折扣后金额
*/
function calculateDiscount(user: User, amount: number): number {
// 实现逻辑
}
当前代码： [粘贴代码]
用户：实现一个用户搜索功能AI：生成基础搜索代码...
用户：添加以下改进： 1. 支持模糊搜索 2. 添加分页功能 3. 结果按相关度排序AI：优化后的代码...
用户：性能优化： 1. 添加搜索结果缓存 2. 使用数据库索引 3. 限制搜索结果数量AI：性能优化后的代码...
用户：添加测试用例： 1. 正常搜索测试 2. 空结果测试 3. 特殊字符测试 4. 性能测试AI：完整的测试代码...
┌─────────────────────────────────────────────────────────────┐ │ 对话上下文策略 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 保持上下文的方法： │ │ │ │ 1. 明确引用 │ │ "基于上面生成的User类，添加一个Admin子类" │ │ │ │ 2. 总结确认 │ │ "到目前为止，我们已经实现了： │ │ - 用户模型 │ │ - 认证API │ │ 现在继续实现授权功能" │ │ │ │ 3. 文件引用 │ │ "@file:auth.ts 基于这个文件，添加权限检查" │ │ │ │ 4. 代码引用 │ │ "修改以下代码中的..." │ │ [粘贴代码] │ │ │ └─────────────────────────────────────────────────────────────┘ 用户：我想实现一个缓存系统，有什么建议？AI：有几种常见的缓存策略： 1. 内存缓存（适合单机） 2. Redis（适合分布式） 3. 浏览器缓存（适合前端）
你的使用场景是什么？
用户：是单机应用，数据量不大
AI：推荐使用内存缓存，可以用Map实现...
用户：使用Map实现一个LRU缓存，容量100AI：[直接生成代码]
用户：实现用户注册功能 AI：[生成代码]用户：添加邮箱验证 AI：[更新代码]
用户：添加密码强度检查 AI：[更新代码]
Text Only
### 对话最佳实践
```markdown
## 多轮对话最佳实践
### DO ✅
1. **保持一致性**
- 使用相同的术语
- 保持技术栈一致
- 延续之前的决策
2. **及时总结**
- 定期总结已完成的工作
- 确认AI理解正确
- 记录重要决策
3. **明确边界**
- 说明哪些要改，哪些不改
- 指定修改范围
- 避免意外变更
4. **逐步深入**
- 从简单开始
- 逐步添加复杂度
- 每步验证
### DON'T ❌
1. **突然切换话题**
- 会丢失上下文
- 导致不一致
2. **模糊的修改要求**
- "改一下"
- "优化一下"
3. **忽略AI的问题**
- AI提问时应该回答
- 有助于澄清需求
4. **一次要求太多**
- 一次只做一件事
- 复杂任务要分解
📚 提示词模板库¶
功能开发模板¶
Markdown
# 功能开发提示词模板
## 基本信息
- 功能名称：[名称]
- 所属模块：[模块]
- 优先级：[高/中/低]
## 功能描述
[详细描述功能是什么，解决什么问题]
## 技术要求
- 框架：[框架名称]
- 语言：[编程语言]
- 数据库：[数据库类型]
## 接口设计
- 请求方法：[GET/POST/PUT/DELETE]
- 路径：[API路径]
- 请求参数：[参数列表]
- 响应格式：[响应结构]
## 验收标准
- [ ] 功能正确
- [ ] 错误处理完善
- [ ] 有单元测试
- [ ] 有文档注释
## 参考代码
[可选：类似的现有代码]
Bug修复模板¶
Markdown
[粘贴错误日志] # Bug修复提示词模板
## 问题描述
[描述Bug的表现]
## 复现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]
## 期望行为
[描述正确的行为应该是什么]
## 实际行为
[描述当前错误的行为]
## 错误信息
代码重构模板¶
Markdown
# 代码重构提示词模板
## 重构目标
[描述重构的目的，如提高性能、改善可读性等]
## 当前代码
[粘贴需要重构的代码]
## 问题分析
- 问题1：[描述]
- 问题2：[描述]
## 重构要求
1. [要求1]
2. [要求2]
## 约束条件
- 保持功能不变
- 兼容现有接口
- [其他约束]
## 期望结果
[描述重构后期望的代码特征]
测试生成模板¶
Markdown
# 测试生成提示词模板
## 被测代码
[粘贴需要测试的代码]
## 测试框架
[JUnit/Jest/PyTest等]
## 测试范围
- [ ] 正常情况
- [ ] 边界情况
- [ ] 异常情况
- [ ] 性能测试
## 特殊要求
- Mock外部依赖
- 覆盖率目标：[百分比]
- [其他要求]
## 参考测试
[可选：现有的类似测试]
🎯 实战案例¶
案例1：从零开发API¶
步骤1：设计数据模型
步骤2：实现基础API
Text Only
基于上面的模型，实现文章的CRUD API：
- GET /posts - 获取文章列表
- GET /posts/{id} - 获取单篇文章
- POST /posts - 创建文章
- PUT /posts/{id} - 更新文章
- DELETE /posts/{id} - 删除文章
使用FastAPI框架。
步骤3：添加认证
步骤4：添加测试
案例2：优化现有代码¶
初始代码：
Python
def get_data(ids):
result = []
for id in ids:
data = db.query(f"SELECT * FROM items WHERE id = {id}")
result.append(data)
return result
迭代1：修复安全问题
迭代2：性能优化
迭代3：添加错误处理
最终代码：
Python
async def get_items(item_ids: List[int]) -> List[Item]:
"""
批量获取商品信息
Args:
item_ids: 商品ID列表
Returns:
商品信息列表
Raises:
ValidationError: ID列表为空
DatabaseError: 数据库操作失败
"""
if not item_ids:
raise ValidationError("商品ID列表不能为空")
try:
# 批量查询，避免N+1问题
query = """
SELECT id, name, price, stock
FROM items
WHERE id IN :ids
"""
results = await db.execute(query, {"ids": tuple(item_ids)})
# 保持原始顺序
item_map = {item.id: item for item in results}
return [item_map.get(id) for id in item_ids if id in item_map]
except DatabaseError as e:
logger.error(f"获取商品失败: {e}")
raise
📝 学习检查点¶
完成本章学习后，请确认你已掌握：
基础能力¶
- 能够编写清晰的功能描述
- 理解提示词的基本结构
- 能够进行简单的迭代优化
中级能力¶
- 能够分解复杂任务
- 掌握多轮对话技巧
- 能够使用提示词模板
高级能力¶
- 能够建立个人提示词库
- 掌握各种场景的提示词策略
- 能够指导他人编写提示词
🔗 相关资源¶
下一章： 06-AI辅助调试与测试 - 学习调试和测试自动化技巧