Day 1【场景名称】架构决策记录 (ADR) 自动生成 — 从「口头决定」到「可追溯决策文档」

【场景名称】架构决策记录 (ADR) 自动生成 --- 从「口头决定」到「可追溯决策文档」

适用角色：架构师、技术负责人、后端开发、参与技术决策的任何角色

痛点背景：团队做了很多技术决策------选 Kafka 不选 RabbitMQ、用 MySQL 不用 PostgreSQL、前端用 Vue 不用 React。但半年后新同事问「为什么选这个」，老员工说「当时讨论过，忘了具体原因」，然后新同事重新调研了一遍，得出了和当初一样的结论。更常见的是：当初的决策前提已经变了（比如「当时选 A 是因为 B 团队用 A」，但 B 团队已经不用 A 了），但没人知道需要重新评估。

【核心做法】

用 结构化决策记录模板 (ADR Template) + 上下文关联 + 有效性评估 让 AI 扮演「架构决策记录员」：

决策提取：从会议记录、群聊讨论、技术方案评审中提取关键决策点
结构化记录：按 ADR 标准格式记录------背景、决策、备选方案、决策理由、预期后果、决策状态
上下文关联：关联相关的技术方案、需求文档、团队讨论记录
有效性评估：定期检查决策的前提条件是否仍然成立

核心逻辑：不是让 AI 帮你做决策，而是让 AI 帮你「记录决策的过程和理由」------决策本身可以错，但不记录决策理由一定会导致重复劳动和决策漂移。

【可复用提示词】

text

浅色深色

复制代码

#Role: 你是一个架构决策记录专家，擅长从技术讨论中提取关键决策点，并生成标准化的架构决策记录 (ADR)。

#Method: 结构化决策记录 + 上下文关联 + 有效性评估
每步输出完整的记录和分析过程。

#Step 1 - 决策点提取
请从以下技术讨论记录中提取所有架构相关的决策点。

技术讨论记录：
{{粘贴会议记录、群聊讨论、技术方案评审记录、或任何包含技术决策的文本}}

提取标准：
- 必须是明确的决策（如「我们决定用 X 方案」），不是讨论过程
- 必须涉及架构层面的选择（技术选型、系统设计、接口设计、部署架构）
- 排除临时性决定（如「今天先试一下」）

输出格式：
编号 | 决策描述 | 决策人 | 决策日期 | 决策类型（技术选型/系统设计/接口设计/部署架构）

#Step 2 - ADR 文档生成
对每个决策点，生成标准化的 ADR 文档：

ADR 模板：
---
标题：{{决策简述}}
日期：{{决策日期}}
状态：{{已采纳/已否决/已替换/已弃用}}
决策者：{{决策人}}
---

## 背景
{{这个决策需要解决什么问题？为什么现在需要做这个决策？}}

## 备选方案
1. 方案A：{{描述}} - 优点/缺点
2. 方案B：{{描述}} - 优点/缺点
3. 方案C：{{描述}} - 优点/缺点

## 决策
{{最终选择了哪个方案？}}

## 决策理由
{{为什么选择这个方案？基于哪些考虑？}}

## 预期后果
正面：
- {{正面影响}}
负面：
- {{负面影响}}

## 关联文档
- {{相关的技术方案、需求文档、讨论记录}}

## 前提条件
- {{这个决策成立的前提是什么？如果前提变化，需要重新评估}}

## 有效期评估
{{这个决策预计多久需要重新评估？}}

#Step 3 - 决策有效性评估
对每个已生成的 ADR，评估其当前有效性：

评估维度：
1. 前提条件是否仍然成立？
2. 技术生态是否有重大变化（如某个方案发布了重大版本、出现了新的竞争方案）？
3. 业务需求是否发生了变化？
4. 团队能力是否发生了变化（如团队现在掌握了当初不熟悉的技能）？

输出格式：
ADR编号 | 当前状态 | 前提条件是否成立 | 是否需要重新评估 | 建议行动

#Step 4 - 输出 ADR 汇总报告
1. 本次生成的 ADR 清单（标题、状态、决策者）
2. 需要关注的 ADR（前提条件可能已变化的决策）
3. 需要重新评估的 ADR（前提条件已不成立的决策）
4. ADR 维护建议（如何保持 ADR 文档的时效性）

【预期产出】

决策点清单：从讨论中提取的所有架构决策
标准化 ADR 文档：每个决策的结构化记录（背景、备选方案、决策理由、预期后果）
有效性评估表：每个 ADR 的当前状态和是否需要重新评估
ADR 汇总报告：清单 + 预警 + 维护建议

【关键注意事项】

⚠️ 决策提取不完整：AI 可能漏掉那些「没有明确说但我们默认了」的决策（如「我们默认用 MySQL 的 InnoDB 引擎」------可能没人明确说过，但所有人都这么用了）。人工校准方法：在 Step 1 输出后，回顾讨论记录，检查是否有「大家默认但没明确说」的技术选择，手动补充为 ADR。

⚠️ 决策理由失真：AI 可能根据上下文推断决策理由，但实际决策理由可能和推断的不一样（如 AI 推断「选 Kafka 是因为吞吐量大」，但实际原因是「运维团队只熟悉 Kafka」）。人工校准方法：在 Step 2 输出后，找决策人确认「决策理由」部分是否准确。如果理由不准确，ADR 的价值会大打折扣。

⚠️ ADR 文档维护成本：ADR 文档一旦生成，如果不定期维护，会变成「过时文档」。人工校准方法：在 Step 4 输出后，建立一个简单的维护机制------每个季度花 30 分钟检查一次 ADR 清单，标记已变化的决策。

【今日小练习 · 5分钟】

找你最近一次技术讨论的记录（群聊、会议纪要、或技术方案评审），复制给 AI，加上这句 Prompt：

text

浅色深色

复制代码

请从以下讨论记录中提取所有架构相关的决策点，并为每个决策点生成一个简化的 ADR 文档（只包含：决策描述、决策理由、前提条件）。

讨论记录：{{你的讨论记录}}

你大概率会发现：你原本觉得「大家讨论完了，都知道了」的技术决策，其实没有一个完整的记录。半年后，当新同事问「为什么选这个方案」时，你就没有现成的文档可以给他。这就是 ADR 的价值------不是「记录决策」，而是「让决策可追溯」。