功能实现

⭐⭐ 初中级 | 将需求转化为可工作的代码

功能实现是将需求转化为实际代码的过程。好的实现应该：

• 功能正确且完整
• 代码清晰可维护
• 性能符合要求
• 考虑错误处理
• 易于测试和扩展

关键问题：

1. 代码质量: 是否遵循最佳实践？
2. 功能完整: 是否覆盖所有场景？
3. 性能指标: 是否满足性能要求？
4. 错误处理: 是否正确处理各种异常？
5. 可维护性: 代码是否易于理解和修改？
6. 集成方式: 如何集成到现有系统？

🎯 原则1: 充分的上下文信息

• ❌ 差: "写一个API端点"
• ✅ 好: "用Spring Boot写一个POST /api/users端点，接收用户信息JSON，验证邮箱唯一性，保存到MySQL，返回201和新用户ID"

🎯 原则2: 明确的约束和要求

• ❌ 差: "写个登录功能"
• ✅ 好: "实现登录，要求：使用JWT，token过期时间30分钟，支持记住我选项，登录失败3次后锁定账号15分钟"

🎯 原则3: 给出具体的输入输出示例

• ❌ 差: "处理用户数据"
• ✅ 好: "输入: {email: 'user@example.com', password: 'pwd123'} 输出: {token: '...', user: {id, name, email}}"

🎯 原则4: 考虑集成和依赖

• ❌ 差: "写个支付功能"
• ✅ 好: "使用Stripe API集成支付，调用我们的order-service创建订单，发送消息到Kafka通知库存系统"

示例1: 功能模块实现

Prompt:

用Python写一个订单处理模块。

需求：
- 功能: 验证订单信息，计算总价，创建订单
- 输入:
  {
    user_id: int,
    items: [{product_id, quantity, price}, ...],
    coupon_code: string (可选),
    shipping_address: {country, postal_code, ...}
  }
- 输出: {order_id, total_price, tax, status}

验证规则：
1. 商品数量必须>0
2. 支持的国家列表: [美国,加拿大,英国,日本]
3. 如果使用优惠券，需要验证有效性和适用范围

价格计算：
- 商品总额 + 税费(按国家不同) + 运费 - 优惠券折扣
- 如果订单>100美元，免运费

错误处理：
- 商品ID不存在 → 返回具体错误
- 优惠券失效 → 返回错误但仍可以继续
- 国家不支持 → 返回错误，不创建订单

约束：
- 必须支持事务（要么全部成功要么全部失败）
- 要能处理并发订单
- 响应时间<200ms

请提供：
1. OrderProcessor类定义
2. 完整的价格计算逻辑
3. 错误处理和验证
4. 一个end-to-end的使用示例
5. 单元测试框架（不需要完整实现）

预期输出:

• 完整的模块代码
• 清晰的类设计和方法
• 完善的错误处理
• 可运行的示例

适用场景: 核心业务逻辑、复杂数据处理、交易类功能

示例2: API端点开发

Prompt:

使用FastAPI实现一个用户管理API。

端点规范：
1. POST /api/users - 创建用户
   请求: {name, email, password, role}
   响应: {id, name, email, created_at} (201)

2. GET /api/users/{id} - 获取用户
   响应: {id, name, email, role, status}

3. PATCH /api/users/{id} - 更新用户
   请求: {name?, email?, role?}
   响应: 更新后的用户信息

4. DELETE /api/users/{id} - 删除用户
   响应: 204 No Content

要求：
- 所有端点需要JWT认证（除了创建用户前可以注册）
- 邮箱必须唯一，不能重复
- 密码存储必须加密（使用bcrypt）
- 支持分页（可选的limit和offset）
- 错误响应格式统一: {error: string, code: string, details?: object}
- API需要数据验证（邮箱格式、密码强度等）
- 删除用户需要管理员权限
- 记录所有操作日志

异常处理：
- 用户已存在 → 409 Conflict
- 找不到用户 → 404 Not Found
- 权限不足 → 403 Forbidden
- 输入无效 → 422 Unprocessable Entity

请生成：
1. FastAPI应用的主要代码
2. 模型定义（Pydantic）
3. 数据库操作（使用SQLAlchemy）
4. 认证中间件
5. 错误处理和验证
6. 一个完整的使用示例（curl命令）

预期输出:

• FastAPI应用骨架
• 完整的请求/响应处理
• 数据验证和错误处理
• 使用示例和文档

示例3: 数据处理逻辑

Prompt:

实现一个日志分析功能。

输入：
- 应用日志文件（每行一条日志）
- 日志格式: [时间] [级别] [模块] 消息

需要实现：
1. 解析日志，提取字段
2. 按时间范围过滤
3. 按级别分类（ERROR, WARN, INFO, DEBUG）
4. 统计各类日志的数量
5. 找出最常出现的错误（top 10）
6. 计算错误率（错误日志/总日志）

处理特殊情况：
- 格式不正确的日志行如何处理？
- 日志中含有中文如何处理？
- 超大文件（>1GB）如何优化？

输出：
{
  total_lines: int,
  error_count: int,
  error_rate: float,
  by_level: {ERROR: int, WARN: int, ...},
  top_errors: [{message, count}, ...],
  time_range: {start, end}
}

要求：
- 支持流式处理（处理大文件）
- 性能要求：<5秒处理100MB日志
- 内存占用<100MB
- 支持并行处理

请提供：
1. 核心处理代码
2. 错误处理机制
3. 性能优化方案
4. 单元测试示例

示例4: 业务规则编码

Prompt:

实现电商系统的价格计算引擎。

规则：
1. 基础定价：product.base_price
2. 会员折扣：
   - VIP: 8折
   - 金卡: 9折
   - 普通: 无折扣
3. 促销规则：
   - 满100减10
   - 满200减30
   - 同时最多只能使用2个促销
4. 优惠券：
   - 可以和促销叠加
   - 优惠券类型：固定金额、百分比、免运费
   - 需要验证优惠券是否过期和库存
5. 运费：
   - 默认10元
   - 满50元免运费
   - 不同地区运费不同（加1-5元）

输入：
{
  items: [{product_id, quantity, base_price}, ...],
  user_level: "VIP" | "金卡" | "普通",
  coupon_codes: [string, ...],
  region: string,
  promotions: [string, ...] (促销代码)
}

输出：
{
  subtotal: 商品总额,
  member_discount: 会员折扣,
  promotion_discount: 促销折扣,
  coupon_discount: 优惠券折扣,
  shipping: 运费,
  tax: 税费,
  total: 最终价格,
  breakdown: {...} (详细明细)
}

规则优先级：
- 如果有冲突，用配置决定
- 同一类型的优惠可以叠加吗？
- 最终价格不能低于成本价

请实现：
1. 价格计算引擎（支持规则管理）
2. 各种折扣的应用
3. 验证和边界检查
4. 详细的计算明细
5. 配置示例和测试用例

示例5: 错误处理机制

Prompt:

为一个API实现完善的错误处理。

应该处理的错误类型：
1. 业务错误：
   - 用户不存在
   - 余额不足
   - 资源已被删除
   - 权限不足

2. 验证错误：
   - 输入格式错误
   - 参数缺失
   - 数据类型不匹配

3. 系统错误：
   - 数据库连接失败
   - 超时
   - 外部服务不可用
   - 内存不足

4. 并发错误：
   - 数据竞争（如转账中重复处理）
   - 死锁

对于每种错误，应该：
1. 返回合适的HTTP状态码
2. 提供清晰的错误消息
3. 包含可操作的建议（什么时候重试，如何修复）
4. 记录错误日志（用于调试）
5. 报警（严重错误要通知）

错误响应格式：
{
  error_code: "USER_NOT_FOUND",
  message: "用户ID 123 不存在",
  details: {...},
  timestamp: ISO8601,
  request_id: "...",
  hint: "请检查用户ID是否正确"
}

请实现：
1. 错误分类和映射
2. 错误响应生成
3. 日志和监控
4. 重试策略（什么错误可以重试）
5. 优雅降级（如果某个依赖失败，如何处理）

误区1: 信息不充分

❌ 不要：

"写个支付功能"
[没有说明]
- 支付方式（信用卡、钱包、等）
- 支付网关（Stripe、支付宝、等）
- 金额范围
- 汇率处理

✅ 应该：

"用Stripe API实现信用卡支付
- 支持美元和欧元
- 最小1美元，最大10000美元
- 支持分期支付（6/12/24期）
- 需要验证CVV和地址
- 支持webbook处理异步事件"

误区2: 遗漏异常情况

❌ 不要：

只实现快乐路径：
- 成功的情况
忽视异常：
- 网络失败
- 超时
- 并发冲突

✅ 应该：

明确处理所有异常：
- 超时重试3次
- 数据冲突时使用CAS
- 网络失败时返回具体错误
- 清晰的回滚机制

误区3: 代码质量要求不明确

❌ 不要：

"按照最佳实践写代码"
[不清楚什么是最佳实践]

✅ 应该：

明确代码质量要求：
- 类名使用PascalCase，方法使用camelCase
- 每个函数<50行
- 圈复杂度<10
- 单元测试覆盖率>80%
- 使用类型提示
- 包含docstring

技巧1: 以TDD方式描述需求

不要只给代码需求，而是给测试用例：

Prompt:
"请实现一个计算器，
基于以下测试用例：

test_addition:
  assert calculate('2+3') == 5
  assert calculate('0+0') == 0

test_negative:
  assert calculate('-5+3') == -2

test_division_by_zero:
  assert calculate('1/0') raises ValueError

请基于这些测试实现代码"

技巧2: 要求架构设计

对于复杂功能，先要求设计再要求实现：

Prompt:
"请先设计一下这个支付系统的架构，然后再实现。

设计应该包括：
1. 主要的类和接口
2. 各个组件的职责
3. 数据流
4. 错误处理策略
5. 扩展性考虑

然后实现核心部分"

技巧3: 提供现有代码参考

如果有类似的现有代码，提供参考：

Prompt:
"请实现用户认证功能

参考现有的[现有功能]的实现方式（见下），
保持一致的代码风格和错误处理模式：

[粘贴现有代码片段]

新功能要求：...
"

实现完成后：

• T05: Unit Test Generation - 编写单元测试
• T07: Code Review Assistant - 请求代码审查
• T03: Bug Diagnosis - 如果有bug要排查