$ loading_
自动沉淀架构决策记录，保留背景、备选方案与理由，便于团队长期维护代码库。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "architecture-decision-records" 技能： 1. 下载 https://raw.githubusercontent.com/affaan-m/ECC/main/docs/zh-CN/skills/architecture-decision-records/SKILL.md 2. 保存为 ~/.claude/skills/architecture-decision-records/SKILL.md 3. 装好后重载技能，告诉我可以用了
请根据我们刚才关于将主数据库从 MySQL 切换到 PostgreSQL 的讨论，生成一条 ADR，包含决策背景、备选方案、最终选择理由、影响范围和后续行动。
一条结构化 ADR，清晰记录数据库选型原因、权衡过程及实施影响。
我们决定把用户认证模块从单体应用中拆分为独立服务。请把这个决策整理成 ADR，并补充当时考虑过的不拆分方案及其利弊。
一份说明服务拆分动机、替代方案、风险与收益的 ADR 文档。
请汇总本次开发会话中已经做出的关键架构决策，生成 ADR 日志列表，并为每条补上标题、状态、日期和摘要。
一个可持续更新的 ADR 日志，帮助后续开发者快速理解历史决策。
在编码会话期间捕捉架构决策。让决策不仅存在于 Slack 线程、PR 评论或某人的记忆中，此技能将生成结构化的 ADR 文档，并与代码并存。
使用 Michael Nygard 提出的轻量级 ADR 格式，并针对 AI 辅助开发进行调整：
# ADR-NNNN: [决策标题]
**日期**: YYYY-MM-DD
**状态**: 提议中 | 已接受 | 已弃用 | 被 ADR-NNNN 取代
**决策者**: [相关人员]
## 背景
我们观察到的促使做出此决策或变更的问题是什么？
[用 2-5 句话描述当前情况、约束条件和影响因素]
## 决策
我们提议和/或正在进行的变更是什么？
[用 1-3 句话清晰地陈述决策]
## 考虑的备选方案
### 备选方案 1: [名称]
- **优点**: [益处]
- **缺点**: [弊端]
- **为何不选**: [被拒绝的具体原因]
### 备选方案 2: [名称]
- **优点**: [益处]
- **缺点**: [弊端]
- **为何不选**: [被拒绝的具体原因]
## 影响
由于此变更，哪些事情会变得更容易或更困难？
### 积极影响
- [益处 1]
- [益处 2]
### 消极影响
- [权衡 1]
- [权衡 2]
### 风险
- [风险及缓解措施]
当检测到决策时刻时：
docs/adr/ 不存在，在创建目录、一个包含索引表头（见下方 ADR 索引格式）的 README.md 以及一个供手动使用的空白 template.md 之前，询问用户进行确认。未经明确同意，不要创建文件。docs/adr/ 中的现有 ADR 并递增docs/adr/NNNN-decision-title.md。如果用户拒绝，则丢弃草稿，不写入任何文件。docs/adr/README.md当用户询问"我们为什么选择了 X？"时：
docs/adr/ 是否存在 — 如果不存在，回复："在此项目中未找到 ADR。您想开始记录架构决策吗？"docs/adr/README.md 索引以查找相关条目docs/
└── adr/
├── README.md ← 所有 ADR 的索引
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← 供手动使用的空白模板
# 架构决策记录
| ADR | 标题 | 状态 | 日期 |
|-----|-------|--------|------|
| [0001](0001-use-nextjs.md) | 使用 Next.js 作为前端框架 | 已采纳 | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | 主数据存储选用 PostgreSQL 而非 MongoDB | 已采纳 | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | 选用 REST API 而非 GraphQL | 已采纳 | 2026-02-01 |
留意对话中指示架构决策的以下模式：
显式信号
隐式信号（建议记录 ADR — 未经用户确认不要自动创建）
proposed → accepted → [deprecated | superseded by ADR-NNNN]
| 类别 | 示例 |
|---|---|
| 技术选择 | 框架、语言、数据库、云提供商 |
| 架构模式 | 单体 vs 微服务、事件驱动、CQRS |
| API 设计 | REST vs GraphQL、版本控制策略、认证机制 |
| 数据建模 | 模式设计、规范化决策、缓存策略 |
| 基础设施 | 部署模型、CI/CD 流水线、监控堆栈 |
| 安全 | 认证策略、加密方法、密钥管理 |
| 测试 | 测试框架、覆盖率目标、E2E 与集成测试的平衡 |
| 流程 | 分支策略、评审流程、发布节奏 |
通过双评审智能体对结果进行对抗式校验，提升输出发布前的可靠性
帮助团队生成软件架构文档、ADR与评审内容，提升设计决策效率与规范性。