这个提示词用来做什么

几个月后有人问「当初为什么这么定」，谁也说不清，只能靠回忆互相说服

提示词全文

帮我把下面这次技术决策写成一份可以直接放进仓库的 ADR（架构决策记录）。只写当时掌握的事实，不要做事后的合理化，不确定的地方标注「未验证」。

## 输入
要决定什么：{……}
候选方案：{A / B / C}
最后选了：{……}
当时掌握的事实：{能给数就给数：延迟、成本、团队熟悉度、期限、上下游限制}
当时的假设：{哪些是推测、哪些已经验证过}
谁参与了决定：{写角色就行}

## 输出结构
1）标题与状态：一句话说清这个决定，状态写「已接受 / 待定 / 已被 X 取代」。
2）背景：是什么约束逼着我们必须现在做决定；顺带写一行「不做决定」的代价。
3）候选与取舍：每个候选写「它最擅长什么 / 它在哪个约束下过不了关」，过不了关的那条要落到具体的数字或事实。
4）决定：一句话，再写清它的适用范围，以及什么情况下不适用。
5）后果：接受这个决定之后我们要长期承担的代价，写具体的——多一层部署、某个指标的上限、团队要补的知识。
6）被否掉的理由：每个落选方案写一条，免得半年后有人重新提一遍。
7）复审条件：出现什么情况就该重新讨论（规模、成本、依赖变化、期限），以及大概什么时候复查。

## 纪律
不要为了行文流畅加点缀性的判断；不要把「大家都这么用」写成理由。写完给我一段 50 字以内的摘要，我要贴在 issue 里。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

ADR 的价值不在记录「我们选了 B」，而在记录「当时 A 因为哪条具体的约束过不了关」。写的时候最容易犯的错是把背景写成愿景，把候选的取舍写成优缺点清单——那样半年后没人能判断这个决定还算不算数。7）复审条件那一节最实用：它把「什么时候可以翻案」提前写死了。

基本信息

  • 分类：工程
  • 标签：架构决策 · ADR · 文档 · 可追溯 · 团队协作
  • 收录日期：2026-10-16

同类提示词