1. 提问原则

提问的核心原则有这几条：

明确目标：尽量清晰地讲明白问题，而不是一个模糊的问题；
提供上下文：最好能够交代你的角色和水平、使用场景、技术栈、约束条件、做过的尝试和结果；
指定输出格式：明确告诉想要什么样的回答，如输出格式是详细内容还是表格对比，是否希望简短回答，想要的输出部分如需要给出结论、理由、代码；
给出示例：提供一个想要的输入输出示例；

还有一些其他的提问技巧：

角色扮演：赋予特定角色，如“你是一位资深软件工程师”，让模型激活相关领域的回答风格和知识倾向；
分布思考：对于复杂问题，让模型一步步思考，先列出解决思路再给出答案；
拆解任务：不要一次丢给它一个庞大需求，把大任务拆成小步骤，逐步实现和优化；
设定约束：明确要求和禁止的内容，如不要使用第三方库、不确定时说不知道而不是编造；
让它先确认问题：说明开始前有不清楚的地方先问我，避免基于错误假设直接生成；
迭代优化：再次追问以优化结果，如再简洁一点、换个角度解释一下、以上方案有什么风险；
拒绝幻觉：明确如果信息不足，先列出需要补充的信息，不要自行猜测；
提供参考材料：可以提供文档、代码、规范，让它进行参考；

总的来说，向模型提问场景可以分为三类：

信息补全：获取不知道的信息，如学习新技术、代码理解；
决策支持：有多个选择、技术方案、架构设计，让模型帮我权衡；
推理增强：对于已有的信息，让模型帮我想得更全面，如性能优化、问题排查、方案评审；

以下是一个通用的提问模版：

# 1. 背景（Context）
我当前在做什么：
- 项目/系统背景：
- 技术栈：
- 当前阶段（开发/优化/排查/设计）：

# 2. 目标（Objective）
我希望你帮我解决的问题是：
- 核心目标：
- 成功标准（如果有）：

# 3. 范围（Scope）
请聚焦在以下范围内：
- 涉及模块/接口：
- 不需要关注的部分：

# 4. 约束（Constraints）
需要考虑的限制：
- 性能要求：
- 兼容性要求：
- 团队/资源限制：
- 其他约束：

# 5. 输入信息（Input）
以下是相关信息：
（按需提供）
- 代码片段：
- 错误日志：
- 当前实现方案：
- 数据规模 / 请求量：
- 已尝试的方案：

# 6. 输出要求（Output Format）
请按以下结构输出：
1. 问题分析
2. 关键风险点
3. 解决方案（可选多个方案 + 优缺点）
4. 推荐方案 + 理由
5. 实施步骤（step-by-step）
6. 注意事项 / 边界情况

2. 代码审查

2.1 审查本地待提交代码

对于比较大的改动，讲清楚背景和影响范围，从多个维度的细化项目逐项检查。

你是一位经验丰富的资深全栈工程师和安全专家，请为我待提交的代码（git diff）进行严格的 code review

【背景信息】
- 背景/目的：<实现的需求/解决的问题>
- 影响范围：<涉及的模块、调用方、是否有 breaking change>
- 不确定点：<不确定的地方>

【从以下维度逐项检查】
1. 正确性：逻辑是否符合意图？边界条件是否覆盖？异常/错误处理是否完整？是否有明显 bug、死循环、off-by-one、race condition？
2. 安全性：是否存在注入、XSS、敏感信息泄露等风险？
3. 性能：是否有 N+1 查询、不必要的循环、内存泄漏风险？是否引入阻塞调用、同步锁、长事务？
4. 可读性：命名是否清晰？结构是否合理？是否有魔法数字、重复代码？
5. 架构与设计：是否破坏现有抽象/分层？是否应抽成公共函数或放到别处？是否引入不必要的依赖或循环依赖？对外 API / 数据库 schema / 配置的变更是否向后兼容？
6. 兼容性：是否有破坏性变更？API 契约是否保持一致？
7. 测试：改动是否有对应测试覆盖？是否需要补充？
8. 遗漏：是否有未处理的错误、缺失的日志、TODO 未完成？是否混入了无关改动、临时文件、不必要文件？

【输出格式】
- 按 🔴必须修复 / 🟡建议修复 / 🟢可选优化 分类列出问题
- 每条问题注明：文件:行号 → 问题描述 → 具体修改建议（给出最小代码片段）
- 最后总结：该代码是否适合合入

对于较小的改动，可以简化提问。

帮我 review 即将提交的改动（git diff）

【改动目的】
一句话说明加了什么功能 / 修复了什么 bug

【检查项目】
1. 逻辑是否正确，有没有漏掉的边界情况
2. 是否残留调试代码
3. 命名和可读性有没有明显问题

【输出格式】
- 按 🔴必须修复 / 🟡建议修复 / 🟢可选优化 分类列出问题，每条附文件:行号 + 修复建议
- 给一句话结论：能否直接提交？

2.2 审查同事的代码

对于比较大的改动，讲清楚背景和影响范围，从多个维度的细化项目逐项检查。

你是一位经验丰富的资深全栈工程师和安全专家，请对给定代码合并进行严格的 code review

【背景信息】
- 合并分支：源分支(fea) → 目标分支(release)
- 背景/目的：<实现的需求/解决的问题>
- 影响范围：<涉及的模块、调用方、是否有 breaking change>
- 不确定点：<不确定的地方>

【从以下维度逐项检查】
1. 正确性：逻辑是否符合意图？边界条件是否覆盖？异常/错误处理是否完整？是否有明显 bug、死循环、off-by-one、race condition？
2. 安全性：是否存在注入、XSS、敏感信息泄露等风险？
3. 性能：是否有 N+1 查询、不必要的循环、内存泄漏风险？是否引入阻塞调用、同步锁、长事务？
4. 可读性：命名是否清晰？结构是否合理？是否有魔法数字、重复代码？
5. 架构与设计：是否破坏现有抽象/分层？是否应抽成公共函数或放到别处？是否引入不必要的依赖或循环依赖？对外 API / 数据库 schema / 配置的变更是否向后兼容？
6. 兼容性：是否有破坏性变更？API 契约是否保持一致？
7. 测试：改动是否有对应测试覆盖？是否需要补充？
8. 遗漏：是否有未处理的错误、缺失的日志、TODO 未完成？是否混入了无关改动、临时文件、不必要文件？

【输出格式】
- 按 🔴必须修复 / 🟡建议修复 / 🟢可选优化 分类列出问题
- 每条问题注明：文件:行号 → 问题描述 → 具体修改建议（给出最小代码片段）
- 最后总结：该代码是否适合合入

对于较小的改动，可以简化提问。

帮我 review 源分支(fea)合入目标分支(release)的改动

【改动目的】
一句话说明加了什么功能 / 修复了什么 bug

【检查项目】
1. 逻辑是否正确，有没有漏掉的边界情况
2. 是否残留调试代码
3. 命名和可读性有没有明显问题

【输出格式】
- 按 🔴必须修复 / 🟡建议修复 / 🟢可选优化 分类列出问题，每条附文件:行号 + 修复建议
- 给一句话结论：能否直接提交？

3. 代码优化

需要明确的点：

优化的维度：说明希望优化的维度，如性能（延迟/吞吐/内存）、可读性、可测试性、安全性、可扩展性；
量化的现状和目标：P99 从 1000ms 降到 200ms，内存占用从 200m 降到 100m，QPS 从 1000 提高到 10000；
划定边界：如实现细节是否可以改，对外接口是否可以改，数据库 schema 是否可以调整；
提供上下文：代码的明确位置（模块/接口）、调用方、数据规模、运行环境、技术栈版本；
尝试的方案：说明已经尝试的方案和结果，减少模型走的弯路；

其他技巧：

先分析原因：让模型先分析之前的问题在哪里，再给出修改方法；
多方案对比：可以让模型提供 2 - 3 种方案，分析各自的对比取舍；
分阶段交互：第一轮先分析和给方案，第二轮再进行代码改动；
可观测/可验证：要求提供可观测数据如 profiling 结果、火焰图、benchmark 数据，提供可验证产物如单元测试、benchmark 脚本、迁移步骤、回滚方案；

# 背景
- 项目类型 / 业务场景：<例如 电商订单服务，日均 500 万单>
- 技术栈：<语言+版本、框架+版本、数据库、缓存、部署环境>
- 模块定位：<这段代码在系统中扮演什么角色，被谁调用，调用什么>

# 待优化对象
<贴出完整的代码 / 接口定义 / SQL / 配置；如果较长，标注关键部分>

# 现状（可观测数据）
- 性能指标：<QPS、P50/P99 延迟、内存占用、CPU 占用>
- 数据规模：<单次请求数据量、表行数、并发量>
- 已知问题：<例如 高峰期 P99 飙到 2s，DB CPU 90%>
- 已做过的尝试：<加过哪些索引、试过哪些方案、为什么不行>

# 优化目标（请按优先级排序）
1. <主目标，例如 P99 延迟 < 200ms>
2. <次目标，例如 内存占用降低 30%>
3. <加分项，例如 提升可读性>

# 约束条件
- 对外接口 / 数据结构：<能否改动>
- 兼容性：<需要兼容哪些客户端 / 历史数据>
- 依赖：<能否引入新库；禁用哪些技术>
- 时间 / 改动范围：<希望小范围改动 还是 可以重构>

# 我希望你这样回答
1. 先做诊断：指出当前实现的瓶颈/问题点，并说明判断依据。
2. 给出 2-3 种优化方案，每种包含：
   - 思路与原理
   - 预期收益（最好量化）
   - 代价与风险（复杂度、维护成本、兼容性影响）
   - 适用场景
3. 推荐其中一种，并给出：
   - 完整可运行的代码改动
   - 必要的单元测试 / benchmark 思路
   - 上线步骤与回滚方案
4. 如果信息不足以给出可靠建议，请先列出你需要我补充的信息，不要凭空假设。

4. 项目介绍

# 角色
你是一名资深软件工程师，擅长快速阅读陌生代码仓库，并向新成员讲解。

# 我的背景
- 我的角色：{{例如：后端工程师 / 全栈 / 新毕业生}}
- 熟悉的技术栈：{{例如：Java/Spring，对 Go 不熟}}
- 本次目标：{{例如：两周内能独立修复 bug 并提交 PR}}

# 仓库信息
- 名称：{{repo name}}
- 主语言/框架：{{如 TypeScript + NestJS}}
- 我已经提供（或 @ 引用）的文件：README、package.json、目录结构、关键入口文件
- 关注的子目录（如有）：{{例如：src/services/payment}}

# 请按以下结构输出（每一节都要引用具体文件路径作为证据，禁止编造）

## 1. 一句话定位
这个项目是做什么的？解决了什么问题？目标用户是谁？

## 2. 技术栈与依赖
- 语言、框架、数据库、消息队列、第三方关键依赖
- 构建 / 包管理 / 部署方式
- 运行环境要求

## 3. 顶层架构
- 用 Mermaid 画出模块/服务依赖图
- 标注哪些是入口（HTTP / CLI / 定时任务 / 消费者）
- 说明各模块职责边界

## 4. 目录结构导览
以表格形式列出顶层目录及其作用，标注「核心 / 配置 / 测试 / 工具」类别。

## 5. 核心数据模型
- 主要实体 / 表 / DTO
- 用 Mermaid ER 图或类图展示关系

## 6. 关键业务流程（挑 2-3 条最核心的）
对每条流程：
- 触发入口（路由 / 事件）
- 调用链（按文件:行号顺序）
- 关键决策点和副作用（DB / 缓存 / 外部调用）
- 用 Mermaid sequenceDiagram 表达

## 7. 横切关注点
- 鉴权 / 权限模型
- 错误处理与日志
- 配置与环境变量管理
- 并发 / 事务 / 幂等
- 测试策略与覆盖率

## 8. 本仓库的"非常规"或值得注意的设计
哪些写法不是行业默认？为什么这么做？有什么权衡？

## 9. 代码质量与潜在风险
- 看起来脆弱 / 复杂 / 缺测试的地方
- 明显的 TODO / FIXME / 过时依赖

## 10. 上手路线图
给我一个 5–7 天的学习计划：
- 每天读哪些文件、跑哪些命令、做哪些验证
- 推荐 3 个适合新人练手的小改动

## 11. 我接下来该问的 5 个好问题
列出对深入理解最有价值的追问方向。

# 约束
- 所有结论必须引用 `path/to/file:Lx-Ly` 作为证据
- 证据不足时请明确写「不确定，需要确认」
- 不要泛泛而谈，避免无信息量的套话
- 输出使用中文

5. 技术方案

# 角色
你是一位资深软件架构师，拥有 10+ 年大型分布式系统设计经验，熟悉高并发、高可用架构，以及主流技术栈（后端/前端/数据库/中间件/云原生）。请基于以下产品需求，输出一份**可评审、可落地**的技术方案。

---

# 一、产品需求背景

## 1.1 业务背景
<在这里描述：业务领域、当前痛点、本次需求要解决的核心问题>

## 1.2 产品需求（PRD 摘要）
<在这里粘贴 PRD 核心内容，或描述：
- 用户故事 / 核心场景
- 主要功能点（建议用列表）
- 交互流程（可附流程图描述）
>

## 1.3 非功能性需求
- **预估用户规模 / QPS**：<例如：DAU 10万，峰值 QPS 2000>
- **数据规模**：<例如：日新增 100万条，总量 10亿>
- **性能要求**：<例如：P99 延迟 < 200ms>
- **可用性要求**：<例如：SLA 99.95%>
- **安全 / 合规要求**：<例如：等保三级、GDPR、数据加密>
- **上线时间**：<例如：4 周内>

## 1.4 现有系统约束
- **技术栈**：<例如：Java 17 + Spring Boot 3 + MySQL 8 + Redis + Kafka>
- **现有服务 / 模块**：<列出会被复用或集成的系统>
- **团队情况**：<人数、技术储备>
- **不可变约束**：<例如：必须部署在私有云、不可引入新中间件>

---

# 二、输出要求

请严格按照以下结构输出技术方案，**每一节都要给出明确结论和理由**，避免泛泛而谈：

## 1. 方案概述（TL;DR）
- 一段话说明整体设计思路
- 核心技术选型一览表

## 2. 需求分析与边界
- 功能性需求拆解（拆成可独立设计的子模块）
- 显式列出**本方案不解决**的问题（Out of Scope）
- 关键假设与风险前提

## 3. 整体架构设计
- 系统上下文图（用文字 + Mermaid 描述）
- 模块划分与职责
- 与现有系统的集成关系

## 4. 详细设计
请覆盖以下方面（不适用的明确说明"不涉及"）：
- **接口设计**：核心 API 列表（路径、方法、入参、出参、错误码）
- **数据模型**：核心表结构 / DDL，索引设计，分库分表策略
- **核心流程**：关键链路时序图（Mermaid sequenceDiagram）
- **存储选型**：为什么选 X 而不是 Y（给出对比理由）
- **缓存策略**：缓存粒度、一致性方案、击穿/穿透/雪崩防护
- **异步与消息**：MQ 选型、消息幂等、顺序性保证
- **并发控制**：锁策略、事务边界
- **第三方依赖**：调用方式、降级方案

## 5. 关键技术难点与方案对比
- 列出 2~3 个最关键难点
- 每个难点至少给出 **2 种备选方案**，从「实现复杂度 / 性能 / 成本 / 可维护性 / 风险」5 个维度对比，并给出推荐结论

## 6. 非功能性设计
- **高可用**：容灾、限流、熔断、降级
- **性能**：容量评估（QPS / 存储 / 带宽计算过程）、压测目标
- **可观测性**：日志 / 监控指标 / 链路追踪 / 告警阈值
- **安全**：认证、鉴权、数据加密、防刷
- **数据一致性**：分布式事务方案选择

## 7. 实施计划
- 里程碑拆分（建议 2 周一个里程碑）
- 工作量估算（人日，按模块）
- 上线策略：灰度方案、回滚方案、数据迁移方案

## 8. 风险与开放问题
- 已识别的技术风险及缓解措施
- 需要进一步确认的问题（向产品/上下游团队提问清单）

---

# 三、输出风格要求

1. **有数据、有理由**：所有选型必须给出量化依据或权衡过程，禁止"业界最佳实践"等空话
2. **图文并茂**：架构图、时序图、ER 图统一使用 **Mermaid 语法**
3. **代码示例**：核心算法 / 关键接口 给出伪代码或 Java/Go 片段
4. **可评审**：站在 reviewer 角度，主动暴露设计缺陷和取舍
5. **避免过度设计**：始终结合 1.3 中的真实规模来定方案，不为不存在的流量做设计

6. 故障排查

## Bug 描述
期望行为：[正常情况下应该发生什么]
实际行为：[现在实际发生了什么]

## 复现步骤
1. [第一步操作]
2. [第二步操作]
3. [出现问题]

## 复现频率：
[必现 / 偶现（约 X 次中出现 Y 次）/ 特定条件下出现]

## 代码位置
[判断有问题的代码位置]

## 错误信息
[完整粘贴报错日志、堆栈信息、控制台输出，或者提供日志文件]

## 环境信息
- 语言/框架版本：[如 Python 3.11, Django 4.2]
- 运行环境：[本地开发 / 测试环境 / 生产]
- 操作系统/浏览器：[如适用]

## 已有线索
- 出现时间：[什么时候开始出现的，最近改了什么]
- 已排查的方向：[已经试过什么，结果如何]
- 怀疑的范围：[如果有猜测，说明原因]

## 请帮我
1. 分析可能的根因（列出可能性并排序）
2. 给出排查步骤（每步包含具体的验证命令或方法）
3. 定位到问题后给出修复方案和代码
4. 说明修复后如何验证

1. 提问原则#

2. 代码审查#

2.1 审查本地待提交代码#

2.2 审查同事的代码#

3. 代码优化#

4. 项目介绍#

5. 技术方案#

6. 故障排查#

1. 提问原则

2. 代码审查

2.1 审查本地待提交代码

2.2 审查同事的代码

3. 代码优化

4. 项目介绍

5. 技术方案

6. 故障排查