WARNING

帮我重构登录模块，
让代码更清晰一点，
顺便优化一下体验。

重构 LoginForm 组件：

目标：
- 拆分表单校验逻辑，提高可维护性

范围：
- 只允许修改 src/features/auth/*
- 不修改 /api/login 的请求参数结构
- 不修改登录成功后的跳转逻辑

任务：
- 提取 useLoginFormValidation Hook
- 保持现有 UI 文案和交互行为不变

输出：
1. 修改计划
2. 受影响文件
3. 关键代码或 diff
4. 风险点
5. 测试清单

验收：
- 原有登录流程不变
- 空邮箱、非法邮箱、空密码均有测试点
- 不引入新依赖

INFO

你是一个资深全栈工程师。
请帮我优化这段代码。

重构 getUserOrders 函数：

目标：
- 将时间复杂度从 O(n²) 降到 O(n)

约束：
- 不修改函数签名
- 不引入新依赖
- 保持返回值结构不变

验收：
- 补充 Jest 测试
- 覆盖空数组、重复订单、超时场景
- 说明优化前后的复杂度差异

你是一个资深工程师

你是负责前端可维护性与无障碍体验的 React 工程师，
熟悉 TypeScript strict mode、WCAG 2.1 和 ARIA 实践。

背景：
- 技术栈：Next.js 14 App Router + TypeScript + Prisma
- 项目：高并发售票平台，QPS 峰值 5000+
- 现有代码风格：函数式组件、自定义 Hook 提取逻辑
- 业务规则：同一用户 5 分钟内只能购买 2 张票

帮我优化一下这个组件

重构 TicketPurchase 组件，
提取购买逻辑为自定义 Hook
useTicketPurchase，
保持组件 UI 不变

约束：
- 禁止修改 API 签名（已有前端依赖）
- 禁止引入第三方 lodash（项目规范）
- 禁止使用 any 类型（TypeScript strict mode）
- 必须保持向后兼容

WARNING

输出格式：
1. 只返回修改的代码块，不解释
2. 每个修改用 // CHANGED: 原因 标注
3. 末尾列出修改的文件清单

验收标准：
- 输出需要补充的边界测试用例清单
- 所有测试必须通过 npm test
- 无 TypeScript 编译错误
- 列出可能的性能风险

# Role
你是负责前端可维护性与 a11y 的 React 工程师。

# Context
项目使用 Next.js App Router + TypeScript strict mode。
当前问题：`CheckoutForm` 文件超过 400 行，校验逻辑散落在组件内部。

# Task
重构表单逻辑，提取可复用 Hook，保持现有提交流程不变。

# Constraints
- 不修改 `/api/checkout` 的请求结构
- 不引入新依赖
- 只允许修改 `src/features/checkout/*`

# Output
按以下顺序输出：
1. 修改计划
2. 受影响文件
3. 补丁或关键代码
4. 风险与回归点

# Verification
- 列出至少 5 个测试点
- 明确哪些边界条件仍需人工确认

帮我优化订单页查询性能，
代码有点慢。

优化订单详情页接口 `/orders/:id`：
1. 目标：把订单详情接口 P95 从 800ms 降到 300ms 以内
2. 技术栈：Node.js + Prisma + PostgreSQL
3. 约束：不改返回 JSON 字段，不改权限逻辑
4. 输出：慢点定位、SQL/索引建议、补丁、回归测试点
5. 验收：说明优化前后瓶颈差异

// Zero-shot：简单任务直接上
把这个函数改为异步版本

// Few-shot：给示例校准输出风格
示例1：
输入：获取用户信息
输出：await apiClient.get('/users/{id}')

示例2：
输入：创建订单
输出：await apiClient.post('/orders', payload)

现在请按同样风格，为"更新商品"生成 API 调用

INFO

4.2

先不要写代码。
请先输出：
1. 你理解的目标
2. 需要修改的文件
3. 每个文件的修改理由
4. 风险点
5. 测试计划

等我确认后，再开始执行。

请使用 <thinking> 标签输出你的分析过程：

1. 先分析这段代码的问题
2. 列出可能的修复方案
3. 选择最优方案并说明理由
4. 然后再输出修复代码

WARNING

不要一次让我写完整个功能，按以下步骤来：

步骤1：设计数据库表结构，等我确认
步骤2：写 API 接口，等我确认
步骤3：写前端组件，等我确认
步骤4：写集成测试

每完成一步，等我确认后再进入下一步。

请以以下 JSON 格式输出：
{
  "files": [
    {
      "path": "修改的文件路径",
      "changes": ["修改点1", "修改点2"]
    }
  ],
  "risks": ["风险1", "风险2"],
  "tests_needed": ["测试1", "测试2"]
}

帮我审一下这个 PR，有问题就说。

<task>
审查这个 PR，重点关注安全、性能、边界条件。
</task>

<output_schema>
{
  "findings": [
    {
      "severity": "high|medium|low",
      "category": "security|performance|correctness|maintainability",
      "file": "string",
      "summary": "string",
      "suggestion": "string"
    }
  ]
}
</output_schema>

只输出符合 schema 的 JSON。

INFO

Step 1 - Spec Extractor
输入：PRD + 约束
输出：JSON { goals, non_goals, contracts, risks }

Step 2 - Planner
输入：Spec JSON + 目录树
输出：JSON { steps, files, assumptions, test_plan }

Step 3 - Implementer
输入：Plan JSON + 目标文件
输出：补丁 + 变更说明

Step 4 - Tester
输入：补丁 + 契约
输出：测试用例 + 回归点

Step 5 - Reviewer
输入：diff + test_plan
输出：findings + blockers + confidence

# Step 1: 需求分析
角色：技术项目经理
任务：将以下 PRD 拆解为开发任务
输出：页面清单 + 接口清单 + 数据表设计

# Step 2: 架构设计（基于 Step 1 的输出）
角色：资深架构师
任务：为上述任务清单设计技术方案
输出：方案对比矩阵 + 推荐方案 + 风险评估

# Step 3: 编码执行（基于 Step 2 的方案）
角色：高级开发
任务：按方案实现 Step 1 中的第一个模块
约束：只修改方案中指定的文件

# Step 4: 审查测试（基于 Step 3 的代码）
角色：安全审计 + QA
任务：审查代码并生成测试用例
输出：Finding 列表 + 测试用例 + 修复建议

# Router: 分类 Issue
分析这个 GitHub Issue，判断类型并输出 JSON：
{
  "type": "bug" | "feature" | "docs" | "question",
  "priority": "P0" | "P1" | "P2",
  "confidence": 0.0-1.0
}

# Branch A (bug): Bug 修复流程
1. 复现步骤分析
2. 根因定位
3. 修复方案 + 测试

# Branch B (feature): 功能开发流程
1. 需求拆解
2. 技术方案
3. 分步实现

# Branch C (docs): 文档更新流程
1. 确认影响范围
2. 更新相关文档
3. 交叉引用检查

WARNING

5.5

1. 任务目标
   本次要解决什么，不解决什么。

2. 当前事实
   相关代码、接口契约、日志、错误信息、测试结果。

3. 业务规则
   权限、金额、订单、数据一致性、兼容性要求。

4. 操作边界
   能改什么，不能改什么，哪些需要人工确认。

# 当前任务
修复订单优惠券叠加错误。

# 已确认事实
- 问题发生在会员折扣 + 新人券同时存在时
- 线上日志显示 discount_total 被重复扣减
- 相关文件：pricing.ts, coupon.ts, checkout.ts

# 业务规则
- 会员折扣和新人券可以同时存在
- 但新人券只能作用于原价，不得作用于会员折扣后的价格
- 返回 JSON 字段不能变

# 禁区
- 不修改支付网关参数
- 不修改订单表 schema
- 不改前端展示字段

# 验证
- 补充 3 个金额计算测试
- 金额精度必须以分为单位计算

你可以读取项目文件和运行测试，但必须遵守：
1. 修改代码前先输出计划
2. 不允许删除文件
3. 不允许修改数据库 migration
4. 每次运行测试后总结失败原因
5. 如果需要执行破坏性命令，必须先请求人工确认

角色：资深架构师
背景：[项目描述、技术栈、团队规模、性能要求]
任务：为 [功能描述] 设计架构方案

要求：
1. 输出至少 2 个方案的对比矩阵
2. 每个方案列出：优势、劣势、冷启动成本、扩展性
3. 给出推荐方案和理由
4. 列出技术选型的利弊分析
5. 说明可能的风险和未确认假设

角色：技术项目经理
背景：[PRD 内容或需求描述]
任务：将需求拆解为可执行的开发任务

输出格式：
1. 页面清单（路由、组件、交互）
2. 接口清单（方法、路径、请求/响应体）
3. 数据表设计（表名、字段、索引、关系）
4. 验收标准（每个功能的 AC）
5. 测试清单（关键测试场景）

角色：[技术栈] 高级开发
背景：[项目上下文、相关代码]
任务：[具体编码任务]

约束：
- 必须使用 TypeScript strict mode
- 只允许修改以下文件：[文件列表]
- 必须保留的既有行为：[行为列表]
- 禁止引入新依赖

验收：
- 代码通过 ESLint 检查
- 输出需要补充的边界测试用例

角色：安全审计专家 + QA 工程师
背景：[代码变更内容]
任务：审查代码并生成测试用例

审查重点：
- 安全漏洞：XSS、CSRF、SQL 注入
- 性能问题：N+1 查询、内存泄漏
- 边界条件：空值、超长输入、并发

输出格式：
1. 按 severity 分级的 finding 列表
2. 基于 given-when-then 的测试用例
3. 每个 finding 附修复建议

:::color2

:::

请使用以下标签分块输出：


你的分析过程



只输出修改的代码，用 // CHANGED 标注



需要补充的测试用例

请严格按以下 JSON Schema 输出：
{
  "files": [
    { "path": "string", "changes": ["string"] }
  ],
  "risks": ["string"],
  "tests_needed": ["string"]
}

不要输出任何 JSON 之外的内容。

输出完毕后，请扮演严苛的审核员：
1. 按上述 3 条约束检查你自己的代码
2. 打印核对清单，列出每个约束的满足情况
3. 如果有未满足的约束，给出修复方案

请以 unified diff 格式输出变更：
- 用 - 前缀标记删除的行
- 用 + 前缀标记新增的行
- 每个变更块前标注文件路径

@getUserOrders.ts 重构这个函数：
- 提取过滤逻辑为独立函数
- 添加缓存层
- 保持函数签名不变
- 输出 Jest 测试

重构 src/services/order.ts 中的
getUserOrders 函数：

背景：高并发售票平台，QPS 5000+
目标：提取过滤逻辑 + 添加缓存
约束：不修改函数签名，不引入新依赖
验收：Jest 测试覆盖空数组和超时

请先输出修改计划，等我确认后执行。

重构以下函数（附完整代码）：
[粘贴代码]

要求：
1. 提取过滤逻辑为独立函数
2. 添加缓存层（用 Map）
3. 保持函数签名不变
4. 输出 Jest 测试用例

请以 unified diff 格式输出变更。

// 在函数上方写注释：
// TODO: 重构 - 提取过滤逻辑，
// 添加缓存，保持签名不变
// 等待 Copilot 内联补全

:::color2

:::

INFO

INFO

INFO

14.3

Prompt 名称：review_checkout_pr
版本：v7
适用场景：支付域 PR 审查
输入变量：diff, changed_files, risk_notes
输出格式：JSON schema
最近改动：新增 “payment amount precision” 检查项
绑定 eval：checkout-review-regression-set

请只做需求抽取，不写代码。

输入：
- 问题描述：[线上优惠券重复扣减]
- 日志片段：[粘贴日志]
- 相关业务规则：[粘贴规则]

输出 JSON：
{
  "goals": [],
  "non_goals": [],
  "business_rules": [],
  "contracts": [],
  "risks": [],
  "unknowns": []
}

基于 Step 1 的 JSON 和目录树，输出：
{
  "candidate_files": [],
  "reasoning_summary": [],
  "must_not_change": [],
  "test_targets": []
}

只分析，不修改。

基于影响范围，输出修改计划：
1. 修改顺序
2. 每个文件改什么
3. 每一步如何验证
4. 可能影响的接口契约
5. 需要人工确认的问题

计划已确认。
请严格按计划修改，不允许扩大范围。
输出 unified diff，并在末尾列出测试结果和未验证项。

请审查以下 diff：
重点关注金额精度、优惠券叠加规则、返回字段兼容性、并发风险。

输出 JSON：
{
  "blockers": [],
  "non_blocking_findings": [],
  "missing_tests": [],
  "release_risk": "low|medium|high",
  "confidence": 0.0
}