技术架构决策日志 (ADR) 生成器（参数表 + 示例输出）
架构决策记录 (ADR) 生成器。输入：决策背景/问题/约束/备选方案/权衡/决策/后果/实施计划。输出：标准化 ADR 文档（标题/状态/背景/决策/后果/替代方案/权衡/实施/验收/相关链接）。遵循 Michael Nygard ADR 格式，可直接进 Git/Confluence/Notion，支持团队协作决策留痕。
图像类提示词仅供参照：生成效果因模型、参数与随机性而异，请自行微调。可填入即梦等生图站，也可填入豆包 / ChatGPT / Gemini 等具备生图能力的对话站（需在对方站内选用图像功能）。一键填入按产品计次规则执行，与是否满意出图无关。
提示词
你是资深架构师/技术决策专家。按 Michael Nygard ADR 标准格式输出架构决策记录：
| 章节 | 内容要点 | 输出格式 |
|---|---|---|
| 标题 | 编号 + 简短描述 | # ADR-XXX: 标题 |
| 状态 | 提议/接受/废弃/替代 | 状态: 接受/废弃/替代 |
| 背景 | 面临的问题/业务驱动/技术约束/现状/痛点 | Markdown 段落 + 列表 |
| 决策 | 核心决策内容、选择的方案 | 明确陈述 + 理由 |
| 后果 | 正面/负面/风险/技术债/运维影响/成本/团队影响 | 表格：后果 |
| 替代方案 | 备选方案/对比/为何不选 | 表格：方案 |
| 权衡分析 | 核心权衡维度/决策矩阵/评分 | 权衡矩阵：维度 |
| 实施计划 | 里程碑/任务/责任人/时间线/依赖/风险/回滚 | 甘特表：阶段 |
| 验收标准 | 如何验证决策生效/指标/测试/监控 | 检查清单 |
| 相关链接 | RFC/PR/文档/会议记录/监控/告警 | 列表 |
| 元数据 | 作者/日期/标签/相关ADR/版本 | 表格 |
输出约束：
- 遵循 ADR 标准格式，Markdown 渲染友好
- 状态机：提议 -> 接受/废弃 -> 替代
- 后果必须诚实列出负面/风险，含缓解措施
- 权衡矩阵含量化评分
- 实施计划含回滚预案
- 可直接进 Git/Confluence/Notion，支持团队协作
常用负面词：
vague, no trade-offs, no alternatives, no rollback, no metrics, hand-wavy, tech debt ignored
示例输入：
决策：微服务架构 vs 单体模块化（订单系统重构）
背景：单体应用部署频繁失败、扩展困难、团队并行开发冲突
约束：团队 20 人、6 个月窗口、零停机迁移、预算有限
备选：微服务 / 模块化单体 / Serverless
示例输出：
ADR-001: 采用模块化单体架构重构订单系统
状态: 接受
背景
- 现状：单体订单系统 50 万行代码，部署耗时 40min，月均 3 次部署失败
- 痛点：扩展困难(单点瓶颈)、团队并行冲突(月均 15 次合并冲突)、扩容只能整体
- 业务驱动：双 11 峰值 QPS 5 万，需水平扩展、零停机发布
- 约束：团队 20 人、6 个月窗口、零停机迁移、预算 50 万
决策
采用模块化单体架构，而非微服务。核心模块：订单/支付/库存/用户/通知，通过内部 API/事件总线通信，共享数据库但逻辑隔离，统一部署、独立测试。
理由：团队规模不足支撑微服务运维复杂度、6 个月窗口不足微服务拆分/基建、零停机要求模块化单体可渐进式拆分、预算不足微服务基建。
后果
| 后果 | 类型 | 影响范围 | 缓解措施 |
|---|---|---|---|
| 部署简化/频次提升至周级 | 正面 | 全系统 | - |
| 团队并行开发冲突减少 80% | 正面 | 研发团队 | - |
| 水平扩展能力提升(模块级) | 正面 | 订单/支付模块 | - |
| 共享数据库仍是单点风险 | 负面 | 全系统 | 读写分离/分库分表规划/熔断降级 |
| 模块间调用延迟增加 | 负面 | 高频调用链路 | 本地缓存/异步事件/熔断/超时控制 |
| 团队认知负荷增加(模块边界/契约) | 风险 | 研发团队 | 模块契约文档/契约测试/架构守护脚本 |
| 最终仍需微服务化 | 风险 | 长期演进 | 明确拆分标准/服务网格预研/分阶段剥离 |
替代方案
| 方案 | 优点 | 缺点 | 排除理由 |
|---|---|---|---|
| 微服务 | 完全解耦/独立部署/技术异构/团队自治 | 运维复杂度极高/分布式事务/网络延迟/运维成本 5 倍/团队不足/6个月不可行 | 团队规模/时间/预算不满足 |
| Serverless | 无运维/按量付费/自动扩缩容 | 冷启动/调试困难/供应商锁定/长耗时任务不适合/成本不可控 | 核心交易链路低延迟要求/成本不可控/供应商锁定 |
| 现状维持 | 无成本/无风险 | 部署失败持续/扩展受限/团队冲突/技术债累积/双 11 风险极高 | 业务风险不可接受 |
权衡分析
| 维度 | 微服务 | 模块化单体 | Serverless | 权重 | 模块化单体得分 |
|---|---|---|---|---|---|
| 交付速度 | 3 | 9 | 7 | 25% | 9 |
| 运维复杂度 | 2 | 8 | 8 | 20% | 8 |
| 扩展性 | 10 | 7 | 9 | 20% | 7 |
| 团队认知负荷 | 3 | 7 | 5 | 15% | 7 |
| 成本 | 3 | 9 | 6 | 10% | 9 |
| 零停机迁移可行性 | 4 | 9 | 5 | 10% | 9 |
| 加权得分 | 4.5 | 8.2 | 7.1 | 100% | 8.2 |
实施计划
| 阶段 | 任务 | 责任人 | 截止 | 依赖 | 风险 | 回滚预案 |
|---|---|---|---|---|---|---|
| P0 基建(2周) | 模块边界划分/契约定义/事件总线选型/数据库分离脚本/契约测试框架 | 架构师/Tech Lead | W2 | 无 | 边界划分不清 | 停止/回退单体 |
| P1 核心模块拆分(8周) | 订单模块拆分/支付模块拆分/事件总线上线/契约测试/性能基线 | 核心小组 | W10 | P0 | 数据一致性/性能回归 | 功能开关回滚/数据回滚脚本 |
| P2 边缘模块/观测/文档(4周) | 库存/用户/通知模块/分布式追踪/契约测试覆盖/架构文档/演练 | 全团队 | W14 | P1 | 遗留代码清理不彻底 | 功能开关逐模块回滚 |
| P3 验收/演练/文档(2周) | 压测/混沌工程/故障演练/文档完善/团队分享/复盘 | 全团队 | W16 | P2 | 压测不达标 | 延期发布/保持现状 |
验收标准
- 部署时间 < 10min、部署频次周级、零停机发布
- 合并冲突减少 80%、模块独立测试覆盖 >80%
- 双 11 压测 QPS 5 万、P99 < 200ms、错误率 < 0.1%
- 契约测试覆盖 >90%、契约变更自动阻断
- 分布式追踪覆盖 100% 核心链路
相关链接
- RFC: #1234 订单系统重构方案
- PR: #5678 模块化单体基建
- 会议记录: #56 架构评审会
- 监控: Grafana Dashboard #123
- 告警: PagerDuty Policy #456
元数据
| 字段 | 值 |
|---|---|
| 编号 | ADR-001 |
| 状态 | 接受 |
| 作者 | 架构师张三 |
| 日期 | 2024-01-15 |
| 标签 | architecture, order-system, refactoring, modular-monolith |
| 相关 ADR | ADR-002 事件总线选型, ADR-003 数据库分离策略 |
| 版本 | 1.0.0 |
少样本示例
输入
生成一个缓存策略ADR: Redis Cluster vs 本地缓存 vs 多级缓存
输出
ADR-004: 采用多级缓存架构 (本地 Caffeine + Redis Cluster)
状态: 接受
背景: 核心链路 P99 延迟 > 200ms，数据库 QPS 瓶颈，需多级缓存降延迟/保 DB
决策: 两级缓存 - 本地 Caffeine(L1, 100ms TTL) + Redis Cluster(L2, 5min TTL)，Cache-Aside 模式，缓存穿透/击穿/雪崩防御
后果: 正面: P99 延迟 < 50ms/DB QPS -80%/命中率 >95%; 负面: 一致性窗口 100ms/双写复杂/内存占用; 风险: 缓存雪崩/一致性不一致/热点 Key 倾斜
替代: 仅 Redis(延迟高/单点)/仅本地(一致性难/内存限制)/Redis Sentinel(HA 弱)/Redis Cluster only(首次访问慢)
权衡: 一致性/延迟/成本/运维/开发复杂度 -> 多级缓存胜出
实施: P0 选型 -> P1 L2 Redis Cluster -> P1 L1 Caffeine 接入 -> P2 一致性方案/监控/演练 -> 验收
验收: P99 < 50ms / 命中率 >95% / 零缓存雪崩 / 一致性窗口 < 100ms
输入
生成一个 API 网关选型 ADR: Kong vs Kong Ingress vs Envoy vs Spring Cloud Gateway vs 自研
输出
ADR-005: API 网关选型 - 采用 Kong (DB-less 模式) + 自研插件
状态: 接受
背景: 微服务化/模块化单体演进，需统一网关：鉴权/限流/熔断/路由/可观测/插件扩展
决策: Kong DB-less 模式 + 声明式配置 + 自研 Lua 插件(业务鉴权/签名/幂等/灰度)
后果: 正面: 生态成熟/插件丰富/声明式/性能好/团队熟悉; 负面: DB-less 配置管理/插件开发门槛/控制平面单点; 风险: 控制平面单点/插件兼容性/升级风险
替代: Envoy(性能最强/配置复杂/学习曲线陡/生态偏基建)/Spring Cloud Gateway(Java生态/性能一般/耦合Spring)/Kong Ingress(K8s原生/但功能受限)/自研(完全可控/成本极高/维护负担)
权衡: 生态/性能/团队熟悉度/扩展性/运维成本 -> Kong 胜出
实施: P0 选型验证 -> P1 集群部署/DB-less配置/插件开发 -> P2 业务接入/契约测试/监控/灰度 -> P3 压测/混沌工程/文档
验收: P99<10ms/吞吐 100k rps/零单点故障/插件热加载/配置热重载/零停机发布