企业官网建设流程全解析

架构决策记录（Architecture Decision Record，ADR）解决了"把决策写下来"的问题，但写下来的决策如何确保团队真的在遵守？本篇文章以 architecture-decision-record 仓库中的《Fitnessfunktioner for beslutninger som kode》（决策即代码的适应度函数）文档为核心，讲解 fitness function 的核心概念、与 ADR 的分工、四大实战价值、基于 AI 大语言模型的检查提示词，以及 ArchUnit / ArchUnitTS 等架构单元测试工具。读完你就能在自己的项目中，把每一条架构决策固化成随每次提交与构建自动运行的客观检查。

什么是"决策即代码"的适应度函数

原文档给出一个精炼的定义：

适应度函数（fitness function）是用编程代码编写的一种客观、自动化的检查，用于验证一项决策是否仍然被遵守。

这个定义有三个关键限定词：

• 客观（objektiv）：检查结果只有"通过 / 失败"两种状态，不依赖评审者的主观印象；
• 自动化（automatiseret）：检查以代码形式存在，可以挂接到持续集成（CI）流水线中，无需人工触发；
• 针对决策（for beslutninger）：它验证的不是代码风格或单元行为，而是"我们当初做出的架构决策"是否仍然成立。

原文档同时指出两条直接收益：适应度函数让决策变得可测试、可保证（testbare og kontrollerbare），并且对**质量保证（kvalitetssikring）、合规流程（regulatoriske processer）和治理目标（governance-mål）**有显著帮助。

在 architecture-decision-record 仓库中，这篇文章是英文源文档 fitness-functions-for-decisions-as-code 的丹麦语翻译（丹麦语版本），同时被收录进仓库根 README.md 的 "Fitness functions for decisions as code" 章节（见 README.md），并作为 12 篇核心文档之一在 spec/content.md 中被明文列出。如果你想阅读同主题的中文版本，仓库还提供了 《将决策作为代码的适应度函数》 等 30 种语言的译文，方便对照学习。

适应度函数与 ADR 的分工：文档记录决策，代码执行决策

原文档用一个非常简洁的公式定义了二者关系：

决策记录（ADR）负责记录决策；适应度函数负责**执行（håndhæver）**决策。

文档中的成对示例如下：

• 决策示例：为满足审计要求，我们采用事件溯源（event sourcing）；
• 适应度函数示例：我们使用持续集成服务器来测试"所有状态变更都必须产生事件"。

也就是说，ADR 回答"我们决定怎么做、为什么这么做"，而 fitness function 回答"系统是否仍然按这个决定在运行"。二者的角色差异可以归纳为下表：

仓库中为"记录决策"这一半提供了大量模板，例如 Michael Nygard 模板（Title / Status / Context / Decision / Consequences 五段式），以及 MADR 项目模板（强调备选方案及利弊）；而"执行决策"这一半，正是本篇文档的主题。仓库的 writing-guide.md 也把"Fitness functions — making a decision testable, not just documented"（让决策可测试，而不只是被记录）单列为一节，与本文档内容相互印证。

为什么适应度函数有助于决策落地

原文档给出四个核心理由，逐一展开如下：

1. 客观度量：工作结果清晰可见

适应度函数要么通过、要么失败，不存在模糊地带。相比"代码评审时口头提醒大家遵守某某约定"，一条自动化检查给出的是确定的布尔结果，任何人都能一眼看到当前系统是否满足决策要求，团队工作状态变得透明。

2. 持续使用：随每次提交与构建运行的"活规则"

适应度函数不是一次性审计，而是常驻的规则——每次 commit、每次 build 都会执行。这意味着决策的遵守不是靠记忆或自觉，而是靠流水线强制。这与本仓库自身的工程实践是同一思路：仓库通过 scripts/audit-locales.py 把"每个语言目录必须与英文源 en-001 完全对齐（205 个文件、README.md 必须是 index.md 的软链接、所有相对链接与锚点必须可解析）"这一内容治理规则写成了可自动执行的检查，并在 .github/workflows/ci.yml 中配置为每次 push 和 pull request 都运行。从源码结构看，这正是一个针对"内容同步决策"的 fitness function 实例。

3. 重构的信心：自动捕获违反决策规则的错误

重构时最怕"结构变了但没人意识到某条决策被悄悄破坏"。适应度函数会在重构代码的构建阶段自动发现此类偏差并让流水线失败，把"事后发现"变成"提交时发现"，为持续演进提供安全网。

4. 可扩展的治理：不制造瓶颈地保证标准

人工审批会随着规则数量增长而成为瓶颈；自动化检查则可以无限扩展——每条决策对应一条检查，规则越多，流水线越严格，却不需要增加任何人力评审环节。这让治理从"人的流程"转变为"代码的流程"。

用 AI 大语言模型充当适应度函数（完整提示词）

原文档明确回答了"适应度函数可以使用 AI 吗"——可以。思路是：让 AI 大语言模型针对我们的工作成果（计划、代码、模式、API 等）提出检查性问题，从而充当一条"广义的适应度函数"。文档给出了可直接复用的完整提示词模板：

IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning. IMPORTANT: Turn on extended thinking. Turn on expert advice. Turn on search. This is a fitness function to evaluate if our work is using all our decisions, and is correct and accurate. - Our decisions are here: {url} - Our work to evaluate is here: {url} Explain any errors, problems, gaps, weaknesses. Be direct. Be decisive.

这份提示词可以从四个层面理解，方便你按需调整：

1. 推理模式指令：前两行要求模型"优先基于检索的推理，而非基于预训练记忆的推理"，并开启扩展思考（extended thinking）、专家建议（expert advice）和搜索（search）能力——本质上是要求模型把决策文档和工作产物当作证据来源，而不是凭训练语料里的泛化知识作答；
2. 角色声明：第三至五行明确这是一条"评估我们工作是否使用了全部决策、是否正确且准确"的 fitness function；
3. 输入占位：{url}需要替换为两处真实地址——决策存放处（如 ADR 目录或文档链接）与被评估的工作产物（如 PR 变更、设计文档、API 契约）；
4. 输出要求：最后一行要求模型"直接、果断"地指出错误、问题、缺口与弱点，避免含糊其辞。

同一份提示词也原样收录在 writing-guide.md 中，说明它是仓库推荐的、经过项目团队验证的通用形态，可以直接粘贴使用或在此基础上扩展。

架构单元测试：ArchUnit 与 ArchUnitTS

当决策本身是"代码的架构形态"时（例如分层依赖、包边界、禁止某类循环引用），最自然的实现方式是把 fitness function 写成架构单元测试。原文档推荐了两个工具：

• ArchUnit（Java）：使用任何普通的 Java 单元测试框架（如 JUnit）来检查 Java 代码的架构规则。它把"分层不得反向依赖""领域层不得引用基础设施层"这类规则写成可断言的测试，随测试套件一起在 CI 中执行。下面是一段通用示意（非本仓库代码，具体 API 以工具当前版本为准）：

// 示意：用 ArchUnit 在 JUnit 中声明一条架构规则 @AnalyzeClasses(packages = "com.example.app") public class ArchitectureRulesTest { @Test void domain_should_not_depend_on_infrastructure() { noClasses().that().resideInAPackage("..domain..") .should().dependOnClassesThat().resideInAPackage("..infrastructure..") .check(new ClassFileImporter().importPackages("com.example.app")); } }

• ArchUnitTS（TypeScript / JavaScript）：使用 Jest、Vitest、Jasmine 等测试框架检查 TypeScript 与 JavaScript 代码的架构规则，为前端与 Node.js 项目提供同样的能力。它同样把架构约束表达为测试用例，例如"某个目录下的模块不得 import 另一个目录的模块"，失败即让测试套件报错。

把这两类工具与前述 AI 提示词放在一起看，可以梳理出一条完整的"决策即代码"落地路径：能用确定性代码表达的架构决策 → 写成 ArchUnit / ArchUnitTS 之类的架构单元测试；难以用代码表达的开放性决策（如计划、文档、API 设计是否与全部决策一致）→ 用 AI 提示词充当柔性检查。两者都挂进 CI，就构成了既有硬约束又有软校验的双层保证。

在本仓库中的落地路径与相关资源

如果你希望基于本仓库进一步实践"决策即代码"，可以从这几处切入：

• 阅读原文：英文源文档 fitness-functions-for-decisions-as-code 与中文译本 《将决策作为代码的适应度函数》 内容完全对应，适合对照研读；
• 查看集成位置：根 README.md 的 "Fitness functions for decisions as code" 章节（README.md）把该主题与"决策记录模板""决策生命周期""架构图与视图"等内容并列，帮助你理解它在整套 ADR 方法论中的位置；
• 结合相邻机制：紧跟在 fitness functions 章节之后，README 还介绍了"Decision guardrails for pull requests"（见 README.md），即 ADR Guard 之类的工具在 pull request 阶段自动拦截"改动了受保护代码却未新增或更新 ADR"的情况，并支持显式的ADR-Exempt:豁免行——这是"决策执行"在代码评审环节的另一种自动化形态，与本文主题形成互补；
• 复用 AI 检查提示词：skills 目录下的 writing-guide.md 收录了同样的 fitness function 提示词，说明该项目已把这一实践固化到面向 AI 编码代理的写作指南中，可作为团队内部约定直接采用；
• 参考示例与模板：仓库 示例目录 中有 40 个 ADR 实例（如 环境变量配置、事件溯源相关的时间戳格式 等），模板目录 提供 11 种决策记录模板，可用来补齐"记录决策"这一半。

需要提醒的是：本文所述 fitness function 属于通用软件工程实践，不同工具（ArchUnit、ArchUnitTS）的 API 与版本差异较大，在关键系统中使用前请自行核验工具文档与项目实际情况，这也是仓库 README 中明确给出的注意事项。

总结

一句话概括本文档的核心主张：ADR 负责把决策写下来，fitness function 负责让决策被执行。通过客观度量、随构建持续运行、为重构提供信心、以代码实现可扩展治理这四个价值点，适应度函数把"架构决策"从纸面文档变成了可测试、可保证的工程资产。对于无法用确定性代码表达的开放性决策，还可以借助 AI 大语言模型提示词充当柔性检查——原文档提供的完整提示词模板可以直接投入实战。结合 ArchUnit / ArchUnitTS 等架构单元测试工具，你就能在 CI 中建立"硬规则 + 软校验"的双层决策保障体系。