企业官网建设流程全解析

在团队中引入架构决策记录（Architecture Decision Record，简称 ADR）时，最大的挑战往往不是模板怎么选，而是"谁有权写、什么时候该写、写完谁来审、过期怎么办"这类组织协作问题。本指南以 architecture-decision-record 开源仓库内置的《Teamwork Questions for ADRs（ADR 团队协作问题）》文档（英文原版见 locales/en-001/documents/teamwork-questions-for-adrs/，孟加拉语译文即本文主题文档 locales/bn-001/দলিল/adr-এর-জন্য-দলগত-কাজের-প্রশ্ন/index.md）为主线，逐条拆解这份问题清单的设计意图，并结合仓库中的模板、示例、命名规范与写作建议，为你提供一套可直接在团队中落地开会的 ADR 协作机制。

一、为什么"问问题"比"给规定"更适合启动 ADR 协作

ADR 是一份记录了重要架构决策及其背景（context）与后果（consequences）的文档（详见仓库 locales/en-001/documents/what-is-an-architecture-decision-record/ 中的定义）。但仓库在 locales/en-001/documents/teamwork-advice-for-adrs/ 中特别强调：决策记录的价值在于让团队"更聪明地思考、更好地沟通"，如果它沦为事后强制的纸质流程，就毫无价值。因此，与其自上而下地颁布 ADR 制度，不如先和团队坐下来，围绕一组开放性问题达成共识。

《Teamwork Questions for ADRs》正是这样一组共 8 个问题：谁可以创建 ADR、什么理由值得创建、什么理由不值得创建、生命周期是什么、生命周期各阶段的验收标准、哪些角色与职责交互、治理如何交互、哪些原则交互。每个问题都给出了"考虑领域（consider areas）"和一份"示例答案（example answer）"，前者负责打开思路，后者展示一份组织可以如何回答——团队只需把示例答案替换成自己的实际情况即可。

这份问题清单与仓库的 locales/en-001/documents/how-to-start-using-adrs/ 一脉相承：该文档把 ADR 的使用拆成决策识别（decision identification）、决策制定（decision making）、决策落地与执行（decision enactment and enforcement）、决策共享（decision sharing）和决策记录（decision documentation）五个环节，而团队协作问题清单正是为这些环节配套的"组织级会议议程"。

二、问题 1：谁可以创建 ADR？

考虑领域：是特定个人、特定角色、特定团队，还是特定部门？还要考虑是否存在可以"委托（commission）"ADR 的人、角色、团队或部门——即他们自己不写，而是请求由其他人来撰写这份 ADR。

示例答案（原文）："我们组织中任何阅读过 architecture decision record README 页面的人都可以提出一份 ADR，即可以开始撰写并与团队分享。"

深度解读：这份示例答案有三个值得注意的设计要点：

1. 门槛极低，与信息前置绑定——"阅读过 README"意味着组织把 ADR 的规范集中放在一个所有人可及的入口，即本仓库根目录的 README.md，任何人按图索骥即可知道怎么写、写在哪。
2. 提出与撰写解耦——示例答案允许任何人"提出（propose）"，而"委托"机制则允许不懂写作者把撰写工作转交给合适的人，避免"谁提出谁就得写完"造成的阻力。
3. 与落地方式呼应——仓库在 locales/en-001/documents/how-to-start-using-adrs-with-git/ 中给出了最简落地路径：mkdir adr建目录、为每条决策创建一个文本文件（如choose-database.md）、写完提交进 git 仓库。这种"一个文件一条决策"的模式让任何有仓库读写权限的成员都能成为创建者。

三、问题 2：什么理由值得创建 ADR？

考虑领域：组织的工作方式（team ways of working）、软件系统结构、跨团队协调、长期可维护性、外部接口、你希望谁受益等。

示例答案（原文）："当我们希望未来的开发者理解我们正在做的事情的'为什么（why）'时，我们就会创建一份 ADR。"

深度解读：这份答案把 ADR 的触发条件锚定在"知识留存"上，而不是"流程合规"上。对照仓库可见：

• 仓库收集了多种模板以满足不同决策场景，例如 Michael Nygard 模板（简单流行）、Jeff Tyree 与 Art Akerman 模板（更复杂完备）、MADR 项目模板（强调备选方案及其利弊）、Planguage 模板（偏质量保证）等，全部列在 locales/en-001/templates/ 目录下；
• 仓库在 locales/en-001/examples/ 收集了大量真实示例，如 时间戳格式、环境变量配置、CSS 框架选型 等，可用来向团队演示"什么级别的决策值得记录"。

四、问题 3：什么理由不值得创建 ADR？

考虑领域：与架构无关的决策；微小决策（风险极低、自包含、单人即可完成的决策）；已在别处完整覆盖的决策（如已被标准、政策或文档涵盖）；临时决策（如临时解决方案、概念验证（proof of concept）、试验性尝试）。

示例答案（原文）："当一项决策的范围、时间、风险与成本都有限，或者它已在别处被覆盖时，我们会跳过 ADR。"

深度解读：这份答案给出了四条可量化的"豁免线"——范围有限、时间有限、风险有限、成本有限——以及一条"已有归属"判断（已在别处覆盖）。这正是仓库内置 AI 技能 skills/architecture-decision-record-skill/ 所承担的核心判断之一：该技能（据 README.md 描述）会"帮助判断一项决策是否需要 ADR"，再决定是否创建adr/或decisions/目录、如何命名文件、从 11 个内置模板骨架中选择模板，并写出扎实的 Context/Decision/Consequences 章节。换言之，"不写 ADR"与"写 ADR"一样，都是一项需要明确标准支撑的决策。

五、问题 4：ADR 的生命周期是什么？

考虑领域：创建流程、研究流程、决策流程、实施流程、下线（sunsetting）流程；以及如何随时间跟踪生命周期——如何把 ADR 从一个状态推进到下一个状态，如何向利益相关者传达状态变化。

示例答案（原文）："我们希望一份 ADR 拥有五个生命周期阶段：Initiating（发起）→ Researching（研究）→ Evaluating（评估）→ Implementing（实施）→ Maintaining（维护）→ Sunsetting（下线）。"

深度解读：需要留意，示例答案自称"五个阶段"，却列出了六个阶段名——这恰好说明阶段划分本身是组织自定义的，清单的目的不是强加某个固定模型，而是促使团队明确"我的 ADR 会经历哪些阶段"。结合仓库可以观察到状态字段在真实 ADR 中的写法：

• 在示例 时间戳格式 中，其 Status 字段写作Decided.（已决策），这是 ADR 记录当前状态的最小形态；
• 仓库在 locales/en-001/documents/suggestions-for-writing-good-adrs/ 中要求"时间戳：标识 ADR 中每一项是何时写的"，这意味着状态迁移应配合时间戳记录，让"何时从研究进入评估"可追溯；
• 同一文档还规定"不可变（immutable）：不要修改 ADR 中已有的信息，而是通过追加新信息来修订，或通过创建新 ADR 来取代它"，因此状态推进应体现为对状态字段的更新与追加说明，而非重写历史。

六、问题 5：生命周期各阶段的验收标准是什么？

考虑领域：ADR 的验收标准（acceptance criteria）——你怎么知道它已经"足够好"，可以从一个生命周期阶段进入下一个？问题是否被清晰表述？备选方案是否被考虑过？权衡（trade-offs）是否被充分理解并记录？所有相关背景是否就位？所有相关利益相关者是否已参与？所有反馈是否已被纳入？

示例答案（原文）："当活跃团队 1) 完成研究，2) 完成评估，3) 将 ADR 提案连同意见征集请求发布给利益相关者并设一周的时间盒（timebox），4) 所有利益相关者的评论都被纳入并解决之后，我们才希望利益相关者对 ADR 投票。"

深度解读：这份示例答案展示了如何把抽象的"足够好"翻译成可核查的检查项：研究完成、评估完成、发布征求评论（含明确时间盒）、评论闭环。它本质上是一份"门禁（gate）"清单，与仓库的写作规范相互印证：

• locales/en-001/documents/suggestions-for-writing-good-adrs/ 指出优秀 ADR 应具备：理由（rationale，解释为何做这项决策）、单一主题（每条 ADR 只对应一个 AD）、时间戳、不可变性；
• 它还定义了优秀"Context"章节（解释组织处境与业务优先级、纳入基于团队社交与技能构成的理由与考量、用与需求和目标一致的语言描述利弊）和优秀"Consequences"章节（说明决策带来的影响、结果、后续步骤；包含衍生 ADR 的信息；包含事后复盘流程，团队通常在一个月后回看每条 ADR，将记录与实际发生的情况对比以学习改进）。

这些规范可以逐条映射到上述验收标准中：例如"备选方案是否被考虑"对应写作规范中的理由与利弊分析，"所有相关背景是否就位"对应 Context 章节质量，"所有反馈是否被纳入"对应时间盒内的评论闭环。

七、问题 6：哪些角色与职责与 ADR 交互？

考虑领域：提出者（proposer）、研究者（researcher）、评估者（evaluator）、审查者（reviewer）、批准者（approver）、维护者（maintainer）等角色；以及与利益相关者沟通、确保预期得到满足、在网站或内网分享、定期以及在相关变化发生时审查工作等职责。

示例答案（原文）："我们希望每条 ADR 始终有一个主要联系人、一个次要联系人以及一个责任团队（accountable team）；他们负责沟通、发布、维护、每年至少一次的定期审查，以及必要时最终的退役（sunsetting）。"

深度解读：这份答案的巧妙之处在于它没有为每个流程步骤指派不同的人，而是建立了"双联系人 + 责任团队"的常设责任结构：

• 主要/次要联系人保证任何利益相关者始终有一个明确的问询对象，且主要联系人缺席时有人兜底；
• 责任团队承担发布、维护与年度审查，避免 ADR 写完即"孤儿化"；
• 退役职责与问题 4 的 Sunsetting 阶段呼应，确保决策过时后有人负责正式下线。

仓库自身的维护实践与此高度同构：根目录 README.md 维护着全部模板、示例与文档的索引，并内置了面向维护者的 skills/architecture-decision-record-maintainer-skill/，专门记录仓库布局、README/locales 镜像约定，以及新增模板、示例、工具链接的确切步骤——这正是"维护是持续职责而非一次性动作"的工程化体现。

八、问题 7：治理（Governance）如何与 ADR 交互？

考虑领域：组织的工作方式；需要特殊合规的场景（如法律层面或人力资源层面）；你希望如何处理共识（consensus）与冲突（conflict）及上报（escalation）；是否存在相对他人对 ADR 有更大影响力的领域、个人或团队——例如拥有批准权、投票权或否决权（veto）。

示例答案（原文）："ADR 的治理按以下优先级排序：CEO、CTO、CLO、实施该 ADR 的团队、团队中对该项架构决策（AD）最了解的专家。除非 ADR 中另有说明，否则其他任何人都没有治理权。"

深度解读：这份示例答案定义了三个关键设计：

1. 显式优先级链——从高管（CEO/CTO/CLO）到执行团队再到领域专家，遇到分歧时按序升级，避免"人人都能否决"造成的僵局；
2. 默认无治理权——"除非 ADR 中另有说明"意味着治理权必须显式授予，这是一条强约束，防止隐性的非正式影响破坏流程；
3. 合规与共识策略需要单独讨论——考虑领域明确要求团队预先想清楚法律/HR 类合规场景，以及冲突时走共识、走对抗还是走上报。

仓库把"治理"进一步延伸到了自动化层面：locales/en-001/documents/fitness-functions-for-decisions-as-code/ 指出，以代码形式编写的适应性函数（fitness functions）是"验证决策是否被维持的客观自动化检查"，能显著帮助质量保证、监管流程与治理目标——例如"决策记录负责记录决策，适应性函数负责保证决策"。这意味着治理不必只靠人来审，也可以用 CI 中的自动化检查来强制。

九、问题 8：哪些原则与 ADR 交互？

考虑领域：组织的工作方式，包括：快速推进 vs 缓慢推进、决策共识 vs 决策冲突、风险偏好 vs 安全偏好、公开讨论 vs 私下讨论等。

示例答案（原文）："我们使用这些领导力原则：行动偏好（bias for action）、异议但承诺（disagree-and-commit）、对于容易撤销且容易隔离的决策，70% 的把握估算就已足够好，以及除组织保密协议中描述的机密信息外，采用公开的工作方式。"

深度解读：这份示例答案给出了四条可直接照搬或改造的原则，它们共同回答了 ADR 流程中最常见的两个摩擦点：

• "什么时候可以不完美"：70% 估算原则为"容易撤销、容易隔离"的决策放低了启动门槛，避免团队为了一个小决策陷入过度分析（analysis paralysis）；
• "分歧怎么处理"：disagree-and-commit 让持异议者可以在记录中表达反对意见后仍承诺执行，而行动偏好则防止流程拖沓。

仓库在 locales/en-001/documents/teamwork-advice-for-adrs/ 中还提供了几条与原则直接相关的实操经验：有些团队更偏好用 "decisions" 目录名而非 "ADR" 缩写，因为全称词汇更容易被理解、去掉 "record" 后人们更愿意写进行中的文档、且部分开发者与管理者反感 "architecture" 一词；理论上不可变（immutability）是理想，但实践中可变（mutability）对团队更有效——向既有 ADR 插入新信息并附上日期戳与"该信息晚于决策到达"的说明，使其成为团队可共同更新的"活文档（living document）"。

十、把这 8 个问题变成一次可落地的团队工作坊

综合以上逐条拆解，这 8 个问题实际上构成了一份完整的团队工作坊议程。推荐的落地步骤是：

1. 召集跨角色与会者：至少包含开发者、架构师、项目经理，必要时包含 CTO/合规代表，对应问题 6、7 的角色与治理议题。
2. 逐题讨论并产出"我们的答案"：把示例答案作为起点，替换为组织实际情况；重点先敲定问题 1、2、3（谁能写、何时写、何时不写），因为它们是流程的入口。
3. 用问题 4、5 定义状态机：确定 ADR 的阶段划分与每个阶段的验收门禁，例如照抄示例中的"研究完成 → 评估完成 → 发布征求评论（一周时间盒）→ 评论闭环 → 投票"。
4. 用问题 6、7、8 定义责任与裁决规则：明确双联系人、责任团队、年度审查、治理优先级与领导力原则，并写进团队的 ADR 规范文档。
5. 选择模板并试点：从 locales/en-001/templates/ 中挑选适合团队的模板（轻量选 Nygard，重流程选 Tyree/Akerman，重质量保证选 Planguage），对照 locales/en-001/examples/ 中的真实示例撰写 1～2 条试点 ADR，一个月后按 locales/en-001/documents/suggestions-for-writing-good-adrs/ 建议的事后复盘流程回看校准。
6. 把规范固化到工具链：按照 locales/en-001/documents/how-to-start-using-adrs-with-git/ 用 git 管理 ADR 文件，并按 locales/en-001/documents/file-name-conventions-for-adrs/ 的命名约定（现在时祈使动词短语、小写加连字符、Markdown 扩展名，如choose-database.md）命名；如需 AI 辅助，可选用仓库内置的 skills/architecture-decision-record-skill/ 让编码 Agent 按项目推荐方式撰写与审查 ADR。

结语

《Teamwork Questions for ADRs》的价值不在于它给出了标准答案，而在于它把"如何让 ADR 在组织中真正运转"拆成了 8 个可讨论、可决策、可固化为制度的问题。从谁有权创建，到何时豁免，再到生命周期门禁、责任结构与治理优先级，每一个问题都能在 architecture-decision-record 仓库的模板、示例与规范文档中找到对应的落地素材。把这份清单带进你的下一次团队会议，用"我们的答案"替换"示例答案"，一套适合你们组织的 ADR 协作机制就能从这份清单中生长出来。