Prompt Pattern

AI Coding 常用 6 类 Prompt。每类一个可复制模板。不是 100 个技巧大全。

什么时候用？

你已经明确任务，但不知道该怎么向 AI 下达任务时。

我想做什么	Prompt 类型	跳转
理解代码	理解	↓ 理解
设计方案	设计	↓ 设计
实现功能	实现	↓ 实现
检查代码	Review	↓ Review
定位问题	Debug	↓ Debug
编写测试	测试	↓ 测试

用法：

选择 → 复制 → 填充 → 执行

核心：

Prompt 不是魔法。好的 Prompt = 明确目标 + Context + 约束 + 输出要求 + 验收标准。

通用写法见 Prompt 怎么写才像工程。
使用前尽量带上 Context & Rules 摘要。

---

1. 理解

场景： 接手模块、读调用链、搞清「改一处会影响哪」。

注意： 要求基于代码事实；未知标「不确定」，禁止编造业务故事。

角色：熟悉本仓库的工程师
任务：理解下面代码 / 模块，为后续修改做准备
Context：
[粘贴相关代码或路径说明]
约束：
- 只根据给定材料推断
- 不确定明确写「不确定」
- 不要给出修改代码
输出：
1. 这段代码在系统里的职责（3～5 句）
2. 关键输入 / 输出 / 副作用
3. 主要调用链
4. 修改时最容易踩的点
5. 我还需要补充什么材料

---

2. 设计

场景： 方案比选、接口形状、表结构影响、要不要引入新组件。

注意： 先方案后代码；列出取舍与风险，不直接开写。

角色：负责本模块的工程师
任务：针对下面需求给「最小可行」设计方案
需求与验收：
[…]
Context / 约束：
[…]
要求：
- 本轮不要写业务代码
- 给出 1～2 个方案，推荐其中一个并说明理由
- 标明对现有模块 / API / 数据的影响
- 列出风险与需要我确认的点
输出：
1. 推荐方案
2. 为何不选另一方案
3. 涉及文件 / 接口（预估）
4. 验收方式
5. 待确认问题

---

3. 实现

场景： 按已确认方案改代码、加功能、补一小段逻辑。

注意： 锁死范围；禁止顺手重构；改完说明 Diff 意图。

角色：实现工程师
任务：按已确认方案实现下面改动
方案与验收：
[…]
相关代码 / Diff：
[…]
约束：
- 只改必要文件
- 不无关重构、不扩 scope
- 保持现有代码风格
- 不确定先问我，不要猜业务规则
输出：
1. 将修改的文件列表
2. 关键改动说明
3. 如何验收
4. 可能副作用
（若在 Agent 中：先给方案，我确认后再改文件）

---

4. Review

场景： PR 前、AI 生成后、重构后。完整版见 AI Code Review。

注意： 只审 Diff；不改代码；分级；区分真问题与优化建议。

请只 Review 下面 Diff，不要修改代码。

检查：正确性、边界、异常、数据一致性、并发、安全、性能、
兼容性、测试遗漏。

输出每个问题：
- P0/P1/P2/P3
- 真实问题 / 需要确认 / 优化建议
- 位置、原因、影响、最小建议

不要为风格问题或无意义重构提意见。
没有问题就说没有。

Diff：
[…]

---

5. Debug

场景： 有复现、有日志、要定位根因。

注意： 先复现与缩小范围；本轮先分析，确认后再改。

角色：负责排障的工程师
任务：定位下面问题的根因，先不要改代码
现象 / 复现步骤：
[…]
日志 / 报错：
[…]
相关代码：
[…]
约束：
- 基于证据推断，不要编造
- 给出最可能的 1～2 个根因及验证方法
输出：
1. 根因判断
2. 证据
3. 如何验证（最小实验）
4. 最小修复思路
5. 修复风险

---

6. 测试

场景： 补单测 / 接口测草稿，或列出手工验收清单。

注意： 人定测什么；AI 出草稿；绿测试 ≠ 业务正确。

角色：关心回归风险的工程师
任务：为下面改动设计测试 / 验收
改动说明与 Diff：
[…]
验收标准：
[…]
约束：
- 优先覆盖主路径与关键失败路径
- 不提出与本次改动无关的大面积测试重构
输出：
1. 建议自动化的用例（名称 + 断言要点）
2. 必须手工验收的步骤
3. 已知测不到的风险
4. （可选）测试代码草稿

---

选用提醒

页面顶部表格已覆盖六类选择。习惯顺序：

理解 / 设计 → 实现 → Review → 测试
出问题再 Debug

与 工作流 对齐；不要跳过「人确认」直接让 AI 连写带合。