架构决策记录 ADR 怎么写提示词（背景、可选方案、决定、后果，一页说清为什么这样选）
团队做了一个重要技术决定（换数据库、引入消息队列、选前端框架），想留下「当时为什么这样选」的记录时用：把讨论过程整理成标准的 ADR 文档，写清约束、被否决的方案和需要承担的代价，半年后的新人也能看懂。
通用大模型 对话模型通用
请把下面的讨论整理成一份架构决策记录（Architecture Decision Record，ADR）。 - 决策主题：[决策主题]（例：订单服务从 MySQL 迁到 PostgreSQL） - 编号：[如 ADR-0012] - 当前状态：[当前状态]（可选：提议中/已接受/已废弃/被某某 ADR 取代） - 讨论材料（会议纪要、聊天记录、方案文档都可以，原样粘贴）： [粘贴讨论材料] - 参与决策的角色：[如后端组、DBA、架构师] 文档结构（总长度控制在一到两页）： 1. 标题：用一句话写出决定本身，例如「订单服务使用 PostgreSQL 作为主数据库」。 2. 状态与日期。 3. 背景：现在面临什么问题、有哪些硬约束（性能、成本、团队技能、合规、时间），为什么现在必须做决定。只写事实，不写结论。 4. 考虑过的方案：每个方案写优点、缺点和关键风险；至少包括「保持现状」这个选项。可以用对比表。 5. 决定：选了哪个方案，用一段话说明决定性的理由，与背景中的约束对应起来。 6. 后果： - 好处； - 需要接受的代价和新增的风险； - 需要后续跟进的事项（迁移步骤、要补的监控、要更新的文档）。 7. 什么情况下应该重新审视这个决定（例如数据量超过某个规模、某个依赖停止维护）。 要求： - 材料中没有给出的数据（性能对比数字、成本）不要编造，标「待补充」； - 如果讨论材料中存在明显没有达成一致的分歧，在文末单独列出「未决问题」； - 使用 Markdown，标题层级清晰，适合直接放进代码仓库的 docs/adr 目录。
高亮处换成你自己的内容：[决策主题]、[如 ADR-0012]、[当前状态]、[粘贴讨论材料]、[如后端组、DBA、架构师]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[讨论材料] 越原始越好，AI 擅长从混乱的聊天记录里提炼出约束和分歧。[当前状态] 如果是「提议中」，这份文档就可以拿去评审；已经做完决定的，可以补写成「已接受」。
常见坑：
- 只写选了什么，不写为什么没选别的。ADR 最大的价值恰恰是「被否决的方案和理由」，否则新人会反复提出同样的方案。
- 把背景写成了推销结论（「因为 PostgreSQL 更好」）。背景只写问题和约束，判断留到「决定」一节。
- ADR 写好就不再改。正确做法是保留旧记录，新决定写一份新的 ADR，并把旧的状态改为「被取代」。
追问技巧：追问「站在当时反对这个方案的人的角度，这份文档有哪些地方写得不公平或遗漏了他的理由」，让记录更客观。
示例输出
示例，仅供参考（节选）
markdown
# ADR-0012：订单服务使用 PostgreSQL 作为主数据库
状态：已接受 日期：2026-10-07
## 背景
订单表需要按 JSON 扩展字段做复杂查询，当前方案依赖应用层过滤，高峰期接口耗时超过 2 秒。
约束：迁移须在 Q4 大促前完成；团队中 2 人有 PostgreSQL 运维经验；不增加新的托管服务供应商。
## 考虑过的方案
| 方案 | 优点 | 缺点 |
|---|---|---|
| 保持 MySQL，优化应用层 | 无迁移成本 | 无法解决 JSON 查询性能，只能缓解 |
| 迁移到 PostgreSQL | JSONB 索引支持此类查询 | 迁移与双写期风险，需要培训 |
## 后果
- 代价：迁移期间需要双写，预计持续 3 周（待补充具体排期）
- 重新审视的条件：订单表超过 5 亿行时评估分库分表方案同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～