工程与产品模板
模板让你更容易清晰地思考与设计，并排除盲点。它们也会引入新的盲点——结构本身就是一种关于"什么重要"的观点，模板告诉你写什么，但不告诉你想什么。好模板的重点不是产出一份文档，而是在工作开始之前，强制进行一场特定类型的对话。
为什么模板有效
三个原因，大致按我经验中重要性的顺序：
- 它们把分歧前置。 大多数项目失败并非执行问题，而是两个人在一个标签上达成一致（例如"发布支付功能"），却对标签背后的内容暗自分歧。一份填好的模板会把分歧拉进书面讨论，这里解决分歧的成本很低，而在代码中发现再回滚代价高昂。
- 它们把记忆外化。 一年后，没人会记得你为什么选 gRPC 而非 REST，或为什么阈值设在 95% 而非 99%。一份带"决策驱动因素"或"备选方案"小节的模板会把短暂的讨论变成可检索的历史。
- 它们压缩 onboarding。 新人读三份 ADR 对系统演进的理解，可能比开一周会议还多。每份模板都是一种制度知识的沉淀。
模板何时会有害
模板是成本，不是白送的。它们在以下情况下有害：
- 产出文档的成本超过了决策本身的成本。为一个 10 行配置改动写一份两页的 ADR，是对速度的税收。
- 模板变成了目标。如果评审者问的是"你填了 4.2 节吗？"而不是"这个决策对吗？"——仪式已经取代了思考。
- 模板的观点与工作不匹配。ADR 假设的是一个离散决策；对每季度都会被重新讨论的持续性权衡来说，ADR 的形状是错的。
经验规则：模板是为那些会超越做出决策的人本身而存在的决策准备的。如果一个决策只涉及你一个人、且明天完全可以撤回，就不要用模板。
这些模板
1. PRFAQ —— 新闻稿与常见问题
亚马逊"从客户反向工作"的机制。你在构建产品之前，先为它写新闻稿。它强制一种特定的诚实：如果新闻稿读起来无聊，那功能就是无聊的。当你启动一个新产品或重大功能、需要团队在任何人写 spec 之前就对准"这是给谁用的"时，使用它。
最适合： 产品启动、功能优先级、创意阶段的 go/no-go。 不适合： 对现有产品的增量改动。
2. ADR —— 架构决策记录
一份短小、结构化的说明，记录一个架构选择：问题是什么、考虑过哪些方案、选了哪个、为什么选。ADR 写起来便宜，六个月后当有人问"我们当初为什么这么做？"时价值巨大。它们最管用的做法是保持不可变——如果决策变了，就写一份新的 ADR 来取代旧的。
最适合： 任何影响超过一个团队、或影响一人超过六个月的架构选择。 不适合： 常规实现选择、单个服务的库选型、以及容易回滚的工作。
3. OKR —— 目标与关键结果
由 Intel 和 Google 推广的经典目标设定模板。结构看似简单——一个有野心的目标、三到五个可度量的关键结果——但真正的价值在于坚持写出客观可验证的 KR（不能是"改进"或"优化"）。OKR 是优先级的强制函数；如果一切都是 OKR，就没有什么是 OKR。
最适合： 团队级或公司级的季度/年度规划。 不适合： 个人贡献者任务列表、工程 backlog，或任何变化速度快于季度的事物。
4. 工程设计文档（Eng Design Doc）
比 ADR 更长、更自由。ADR 捕捉一个决策，而设计文档捕捉一个设计——完整的系统图、数据模型、API 约定、故障模式、迁移计划和开放问题。我把设计文档用于任何大到我无法一次在脑中装下的项目。检验标准是：如果我明天被公交车撞了，另一个工程师能从这份文档继续工作吗？如果不能，这份文档就还没完成。
最适合： 新服务、跨团队集成、非平凡重构、任何涉及数据迁移的工作。 不适合： 单 PR 改动或已充分理解的模式。
5. GitHub Issue 与 PR
列表中仪式感最轻的模板，却也是最容易被滥用的。好的 issue 模板强制报告人区分症状、复现步骤和预期行为——没有这些，bug 就只是感觉。好的 PR 模板按顺序询问"改了什么、为什么改、怎么测试的"，因为我认识的每个评审者都是先读"什么"再读"为什么"、再看 diff。
最适合： 每个仓库。即便是一个三字段模板（背景、改动、测试计划）也能在第一次评审就回本。 不适合： 只有你一个贡献者的个人沙盒。
6. 投资备忘录
最初是 VC 的产物；越来越适用于公司内部任何重要的资本配置决策。纪律与 PRFAQ 相似——在花钱前写论点——但结构更重：显式的财务情景、风险/缓解对，以及投后复盘节奏。
最适合： VC 投资决策、并购、内部 R&D 押注、大额采购决策。 不适合： 战术性支出或你裁量范围内的事。
在它们之间选择
一个粗略的决策树：
- 这是一个新产品或重大功能吗？ PRFAQ。
- 这是一个有长期后果的架构选择吗？ ADR。
- 这是一个为期数月的工程项目吗？ 工程设计文档。
- 这是一个季度的目标吗？ OKR。
- 这是一个重要的金钱押注吗？ 投资备忘录。
- 这是一个 bug 报告或代码改动吗？ Issue / PR 模板。
你能做的最糟糕的事就是用错模板——用 PRFAQ 做一次库升级，或用 ADR 启动一个产品。错配的模板不仅浪费时间，还会悄悄把思考推向错误的方向。
