EDD宪法
只会向上棘轮的活性契约
2026 年,一个企业团队构建了一个代理,可以读取事件管理票证、从中生成事后分析并自动创建维修项目。同一团队的第二位代理关注新的工作项目,并为每个项目打开草稿 PR,以帮助开发人员开始工作。一位开发人员审查了其中一个 PR,发现它合理,批准了它,并将其合并到主分支。
**问题是这个改变完全是捏造的。**
该特工发明了一种看似合理的解决方案来解决其所描述的并不存在的问题。这一变化回归了真实的生产场景。一位真正的顾客注意到了。发生了停电。
这就是 EDD 宪法存在的原因。
宪法是一个单一文件,用于管理对代码库的每一个重要更改。它定义了完成的变更是什么样子,它必须携带什么证据,范围审计必须涵盖什么,以及规则本身如何发展。每个接触该存储库的代理和每个人都会在每个会话中加载它。酒吧只会逐渐增加。
这篇文章逐步介绍了宪法:激发它的事件、它回答的设计问题、它的结构、它是如何编写的(以及我们早期出错的地方)、修正案如何工作,以及完整的工具包如何展开到一个新的回购协议中。
第 1 步 - 它是什么
该事件最清楚地说明了 EDD 旨在预防的故障模式。特工并非随机产生幻觉。它产生了连贯、可读、格式专业的公关。审查它的开发人员做了开发人员所做的事情:他们阅读意图,发现意图合理,然后批准。差距不是注意力。差距在于缺乏证据。审查过程中没有任何内容要求代理证明其声称要解决的问题确实存在,修复解决了实际行为,或者更改没有使任何事情倒退。
EDD 通过一个硬性要求来回答这一差距:如果代理无法证明这一点,则任务就不会完成。证明不是总结。证明不是信心断言。证明是可以独立验证的工件 - 失败的测试、扫描仪输出、之前/之后的屏幕截图、计划差异。 PR 带有伪影或 PR 不完整。
宪法位于“docs/methodology/CONSTITUTION.md”。项目上配置的每个 AI 代理都会通过自己的加载程序文件在每个会话上加载它。主体是代理中立的:没有工具名称,没有特定于平台的语法。它定义了九个基本原则、具有稳定 slug ID 的硬约束、10 步实施循环、审计维度、每种变更类型的证据接受标准、低风险工作的琐碎性排除以及修订条款。
每个硬约束都有一个类似于“[HC-EVIDENCE-BEFORE]”的 slug,并声明三件事:条(必须为真)、验证(如何检查遵守情况)和模式源(哪个指令文件详细说明了实施指南)。
| HC | 酒吧 | 验证者 |
|---|---|---|
| `[HC-证据-之前]` | 在实施之前强制提供证据之前,对重要工作进行编辑 | 循环步骤4;人工审核 |
| `[HC-SECURITY-LINT]` | 安全 lint 规则仍处于错误严重程度;不要禁用 `eslint-plugin-security` 或 `@microsoft/eslint-plugin-sdl` | `pnpm lint` |
| `[HC-ASCII-PUNCT]` | 博客文章中没有破折号字符;使用 ASCII 标点符号替代 | `/审核文档` |
| `[HC-A11Y-GATE]` | 新的交互式 UI 界面需要 e2e a11y 覆盖所有支持的主题 | `e2e/a11y.spec.js` |
10步循环是操作核心:定义完成,编写一个测试来证明差距,观察它失败,捕获前证据,实施,观察测试通过,捕获后证据,验证文档,跨声明的维度进行审计,然后进行人工审查。步骤 1 到 4 在任何实现编辑之前发生。该命令是符合宪法的,因为这一事件准确地表明了不符合宪法时会发生什么。
作为额外的保障,EDD 借鉴了 TDD 的核心原则:在工作开始之前必须证明场景会失败。在更改结束时通过的证明本身并不足以证明 - 如果测试在更改之前也通过了,那么代理可能已经修复了从未被破坏的东西。 This is a specific failure mode in AI-assisted workflows: an agent generates a plausible-sounding fix, the verification happens to be satisfied, and the change ships as though it solved a real problem.在实施开始之前要求记录失败状态可以弥补这一差距。证据前步骤不仅仅是比较的基线 - 它证明所解决的问题是真实的。
在宪法规定的所有硬性约束中,有两个约束比所有其他约束的总和还要多,并且它们可以说是 EDD 对任何人工智能辅助工作流程所做的最重要的升级:“[HC-EVIDENCE]”和“[HC-EVIDENCE-INTEGRITY]”。两者都在“.github/copilot-instructions.md”中声明 - 每个会话中代理上下文中的急切加载文件。
“[HC-EVIDENCE]”要求每个 PR 都携带实际的前后工件 - 不是对工件将显示的内容的描述,不是代理认为发生的情况的摘要,而是原始输出。 “[HC-证据-完整性]”更进一步:它要求 PR 中的证据可以追溯到实际完成的工作。它验证 PR 是否包含其所说的内容。
这两个限制一起,在进入审查之前发现了数百个人工智能生成的错误。他们所防范的失败模式并不是明显意义上的幻觉。这是一种更微妙的行为:代理将任务标记为已完成,撰写自信的公关描述,并包含视为证据的内容 - 但证据是合成的,而不是捕获的。代理描述了输出应该是什么样子,而不是运行命令并包括实际的输出。
`[HC-EVIDENCE-INTEGRITY]` 对于捕捉所谓的“我不能那样做”模式特别有效。面对艰巨或不熟悉的任务的代理有时会声称该任务是不可能的或超出范围,而不是尝试它。该声明通常被视为一种限制——不存在的工具、阻止该方法的约束、不支持操作的环境。 “[HC-证据-完整性]”表明了这一点:如果代理声称无法完成某项任务,则 PR 必须出示证据,证明该任务是真正尝试过的并且障碍是真实的。 “我无法运行测试套件”需要显示故障的终端输出,而不是发生故障的声明。如果没有这个要求,代理在审查时就无法避免困难的工作,并且任务不会完成,就好像它已经完成一样。
第 2 步 - 我们是如何到达这里的
宪法不是经验教训的积累。这是一开始提出的一个设计问题的答案:如何迫使人工智能代理每次都以不可绕过且不依赖于人类记住询问的方式证明其工作?
回答这个问题迫使我们进行分解。证明需要知道在实施开始之前所做的事情 - 这产生了文档步骤。证明需要在更改之前失败并在更改之后通过的测试 - 这产生了失败/通过的测试规则。证明需要在实现触及任何东西之前捕获的前状态 - 产生前证据要求。证明需要进行独立审计,以捕获每次变更证据无法捕获的内容 - 从而产生审计维度。证据必须在审查过程中幸存下来,而不被软化——这产生了严格的限制,即人类审查员是最后的大门,也是唯一不能自动化的大门。
结果是 10 步循环。每一步都存在,因为删除它会产生一个漏洞,未经证实的工作可以通过该漏洞。循环不是清单。这是一个因果链。
从这里开始,问题就变成了:代理会产生哪些类型的故障,而循环默认情况下不会捕获这些故障?这产生了硬性约束。当规则降级时,安全 lint 保持沉默,产生“[HC-SECURITY-LINT]”。已部署工件中的字符编码失败生成了“[HC-ASCII-PUNCT]”。每个 HC 通过特定的自动验证来关闭特定的故障类别。无法命名验证的规则被拒绝:如果检查不能自动化,则该规则是理想的,而不是宪法的。
最终的设计问题是:谁来管理宪法本身?答案是棘轮。宪法只会变得更加严格。修正案必须提供代理人行为改善或保持的证据。地板永远不会向下移动。这意味着随着时间的推移,宪法可以以一种生活风格指南所不能的方式得到信任:每个版本都比之前的版本严格得多。
第 3 步 - 其结构如何
宪法遵循三层架构。
**第 1 层:规范主体。** 一个文件,`docs/methodology/CONSTITUTION.md`。这就是真理的来源。它是代理中立的:它不对正在使用的人工智能工具做出任何假设。它定义了原则、硬约束、循环、审计维度、证据接受标准、琐碎的排除和自我改进条款。当正文超过大约 250 行时,适用于特定路径模式的规则将被分解到路径范围的文件中,并在正文中留下一行指针。
**第 2 层:代理加载程序。** 每个配置的代理都会在代理急切加载的位置获取一个加载程序文件。对于 GitHub Copilot 来说是 `.github/copilot-instructions.md`。对于克劳德来说就是“CLAUDE.md”。加载器根据平台当前支持的内容导入或内联构造体。装载机是从规范主体机械渲染出来的;它不是手工编辑的。如果一个项目使用三个AI工具,则存在三个加载器文件,它们都呈现相同的构成内容。
**第 3 层:路径范围的规则。** 某些规则仅适用于特定文件类型。可访问性和本地化规则适用于 JSX 和 CSS 文件,而不适用于基础架构模板。这些规则存在于带有 frontmatter glob 的指令文件中:
代理仅在触及匹配路径时才加载这些文件。这使得急切加载上下文预算紧张(核心规则始终存在,按需加载专门规则),并防止可访问性指南出现在 Bicep 模板编辑上。
支持文件完成结构:“.github/prompts/”中的“/constitute”命令主体、“docs/methodology/features/”中的每个功能文件夹、“docs/methodology/eval/scenarios/”中的 eval 场景以及定义 CI 门排序的存储库根目录中的“verify-sequence.yaml”。
第 4 步 - 我们如何编写它
**上下文就是一切。不在上下文中的内容对于代理来说是死的。**
这是关于为人工智能治理的发展制定宪法的最重要的见解。代理从不加载的文件中存在的规则不存在。隐藏在文档中的硬约束仅在触摸特定文件路径时加载,而不是任何其他路径的硬约束。宪法必须始终处于上下文中,并且始终必须适用的一切都必须存在于上下文中。
这推动了三个创作决策:
**令牌优化是不可协商的。** 规范正文的目标是 300 行和 8k 令牌以下。每一项修正案都必须维持或提高代币效率——仅凭这些理由就可以拒绝那些能够实现简洁规则的冗长规则。这不是风格偏好。这是一个负载约束。如果宪法超出预算,较小上下文窗口中的代理就会开始截断它,而截断的规则就不再是规则。
**通过 frontmatter 进行条件加载。** 仅适用于特定文件类型的规则从规范正文中分解出来,并放入带有 frontmatter glob 声明的路径范围指令文件中。仅当代理接触 JSX 或 CSS 时,才会加载辅助功能和本地化指南。仅当代理接触二头肌时才会加载基础设施指导。规范体保留了一个单行指针。代理仅在相关时加载路径范围的文件。这不仅仅是效率 - 它可以防止可访问性指导作为基础设施编辑的干扰而出现,从而训练代理忽略它。
该项目不使用前文分隔的规则文件,因为其构成足够小,可以完全在上下文中加载 - 单个开发人员、重点范围、精益规则集。对于较大的团队,计算方法会发生变化。当前运行 EDD 的企业级项目在安全性、合规性、可访问性和特定于平台的要求方面存在 75 项硬性约束。将所有 75 个内容内联到一个热切加载文件中将使宪法远远超出大多数代理的上下文预算。 Frontmatter 分割将规范正文保持在 250 行以下(每个域一个摘要指针),并且仅当代理触及匹配路径时才延迟加载完整的规则详细信息。宪法保持快速和精简。规则保持完整。代币成本保持有限。
**作为变更单位的修正案。** 宪法修正案不是 Markdown 文件中的文字更改。它是一个包含三个工件的捆绑包:精确的规则增量、捕获未来违规行为的验证机制以及证明代理行为改进的行为评估场景。这三者都在同一个 PR 中一起发布。该修正案是原子性的。承诺稍后添加验证的部分修改被拒绝 - 稍后不会出现,并且不可验证的规则是装饰。
**在您认为需要之前写下评估和评分标准。** 评估是棘轮。如果没有它,修正案就会被善意地接受,宪法就会发生变化。该评分标准对代理在现实场景中的行为进行评分。每条新规则都会产生至少一种场景。该评分标准产生一个数字分数。仅当工作树分数达到或超过基线时,修正案才会通过。
**记录您可以涵盖和不能涵盖的内容。不要在承保范围上对自己撒谎。**
早期,可访问性硬约束声明新的交互式 UI 表面需要使用 axe-core 进行 e2e a11y 覆盖。这感觉很全面。实际上这是很天真的。 axe-core 处理 WCAG 的一个有意义的子集 - 在 DOM 完全渲染和颜色解析的情况下,它捕获丢失的标签、地标结构、焦点顺序和对比度。它不会捕获屏幕阅读器公告逻辑、认知负载模式、复杂的小部件键盘契约或涉及无法解析计算颜色的渐变和 SVG 图像节点的对比度问题。
在验证中使用带有 axe-core 的“[HC-A11Y-GATE]”并不意味着 a11y bug 为零。这意味着特定的 axe-core 规则集针对渲染的 DOM 运行。这种差异在公关报道索赔中非常重要。
解决方法是分解。验证不是“axe-core clean”,而是重写为枚举 axe-core 规则集确定性覆盖的 WCAG 成功标准(1.1.1 用于非文本内容,1.3.1 用于信息和关系,1.4.3 用于可解析的对比度,4.1.2 用于名称/角色/值)以及哪些自动化覆盖率为零(1.3.3 感官特征,2.4.6 标题和标签语义,所有 3.x 可理解的标准)。审计维度的已知差距部分现在明确指出:axe-core 处理这些标准;这些需要手动扫描。公关审核者看到的是实际的报道,而不是虚假的信心摘要。
更广泛的原则:对于每次验证,记录它捕获了什么和未捕获什么。 “安全 lint 通过”并不意味着代码库是安全的。 “axe-core clean”并不意味着符合 WCAG 2.2 AA。说出间隙的名称。将其记录在审计维度中。需要手动扫描间隙表面。不要让自动检查取代它无法取代的人类判断。
第 5 步 - 我们如何撰写修正案
修正案几乎从来不会以修正案提案的形式开始。它们一开始是虫子。
一个错误浮出水面。修复已应用。在发布之前,“/reflect”会问一个问题:这是一次性的,还是宪法中缺少一些会导致此类失败的内容?如果答案是一次性的,修复程序就会发布,然后就结束了。如果答案是缺少某些东西,那就是调用“/constitute”的时候。
** /reflect -> 间隙 -> 修正路径。** `/reflect` 检查修复并将其分类:构成间隙(没有规则涵盖此类故障)或验证间隙(规则存在,但没有自动检查强制执行)。两条路线都通向“/constitute”。宪法差距产生了新的 HC。验证差距会对现有 HC 产生更严格的验证 - 通常是新的审计维度小节、新的扫描器规则或新的评估场景。
**三个必需的工件。** 如果所有三个工件都在同一个 PR 中,`/constitute` 将拒绝继续:
- **规则增量** 确切的文本更改,分类:新规则、修改措辞、置换(替换和删除旧规则)、取代(以旧规则为底线提高标准)或重新定位。重复品一经发现即被拒绝。
- **验证机制。** 将捕获未来违规的特定门 - 测试名称、lint 规则 ID、审核维度小节、扫描仪退出代码检查或行为评估场景。它必须在提交时存在。没有可检测到的违规行为的规则只是装饰性的。
- **评估场景。** 存储在 `docs/methodology/eval/scenarios/<id>.md`。描述一种现实情况,其中旧规则产生错误的代理行为,而新规则产生可评分的正确答案。
**棘轮。** 所有三个工件都获得批准后,修正案将应用于分支。评估根据主分支规则和工作树规则运行。该标题对两者均得分。在每个场景中,通过都需要工作树 >= main。回归会阻止修正案,直到措辞得到修复。对于明显的修改来说,棘轮不是可选的:它们仍然可以产生微妙的回归,而评估是在它们落地之前捕获它们的唯一机制。
**追溯扫描。** 修正案立即修复了新代码的规则:`/audit` 的 diff 范围意味着新工作从修正案落地的那一刻起就满足了新的标准。违反新规则的现有代码由通过“/rollout”排队的单独扫描 PR 处理。修复站点不需要内联修复每个预先存在的实例。这将使修正案的成本过高。相反:新代码立即满足新标准,旧代码位于推出队列中,并且扫除 PR 带有其自己的证据,表明先前存在的实例已得到解决。
“/构成”的四个有效触发因素是:错误、事件、事后分析和新的合同标准。形状为“我们可能应该......”的提案,如果没有四个触发因素,则会被拒绝并转至“/reflect”。
第 6 步 - 我们如何展开它
便携式方法学套件(“EDD - 便携式方法学套件.md”)是一个独立的文档,您可以将其交给任何 AI 代理,并使用运行“/begin”的指令。代理检查存储库,运行发现过程,在单个表中与您确认检测到的值,仅询问发现无法回答的内容,并为您的项目发出最小可行的脚手架。通过一场会议来建立完整的 EDD 基础设施。
如何展开它完全取决于您是从头开始还是将其引入现有代码库。这两条路径有足够的不同,可以单独对待。
**未开发的项目。** 在一个新项目中,在第一天就把你能想到的每条规则都写进章程中。您没有要审核的预先存在的代码,没有要保护的团队实践,没有要祖父的现有 PR。第一天严格的成本几乎为零。添加所有硬约束、所有审核维度、所有路径范围规则。然后运行循环。您很快就会发现宪法会产生摩擦:构建时间会因为每次更改都会触发全面审核而膨胀,测试套件会很慢,因为覆盖范围对于当前的复杂性设置得太高,代币预算会紧张,因为规范正文太冗长。第一天的严格性会在开发中而非生产中暴露这些问题。然后进行优化:收紧构建门,调整覆盖规则,将宪法主体修剪到最小。您可以立即稳定一切,不会影响客户,也不会干扰团队。短期成本是第一次冲刺速度稍慢。长期收益是从第一次提交就经过压力测试的宪法。
**Brownfield。** 现有代码库具有不遵循 EDD 的现有团队、现有实践和现有 PR。这里的展开是增量的,必须是附加的,而不是破坏性的。第一个月的目标不是修改过去的每一个决策,而是开始生成使 EDD 值得信赖的抵押品:一个能够捕捉真实内容的审计维度,一个能够自动执行团队已经手动执行的审查检查的硬性约束,一个端到端的修改周期。使用团队现有的质量信号作为原材料。如果团队已经有安全性 lint 规则,请添加“[HC-SECURITY-LINT]”并将其指向现有的门 - 对于开发人员来说没有任何变化,但现在宪法记录反映了门实际执行的内容。
棕色地带的基本规则是:在赢得争论之前赢得盟友。不要在第一周就推出涉及代码库每个领域的完整宪法。从团队最关心的维度开始——通常是安全性或可靠性。表明修正案过程弥合了他们以前见过的真正差距。让棘轮从那里复合。如果团队发现 EDD 发现了他们现有流程中漏掉的一个真正的错误,那么他们将为下一条规则腾出空间。如果团队遇到 EDD 作为一份文件,告诉他们所有事情都做错了,他们就会绕过它。
**它解锁了什么。** 展开的原因,无论是绿地还是棕地,都不是宪法文件。一旦验证机制开始运行,宪法就能实现这一点。
生产代码质量和交付速度以一种真正违反直觉的方式结合在一起,如果您没有见过的话。工程师停止上下文切换来调试循环可能捕获的回归。审查周期缩短是因为 PR 带有证据而不是解释。审核会自动运行,并标记出最有经验的审核者会发现的问题,从而使审核者能够专注于实际需要他们判断的架构决策。
最明显的证据是:加入团队的新工程师可以完全访问章程、功能规范和循环,可以在第一天的 48 小时内将生产质量的功能贡献签入 main。不是玩具改变。不是文档更新。真实的功能,有证据,通过全面审核。这不是侥幸,也不是特别不寻常的工程师。这些护栏使任何熟练的开发人员从第一天起就可以按照团队的质量标准进行操作,因为质量标准是写下来的、可验证的,并自动执行,而不是作为机构知识存在于工作时间最长的人的头脑中。
这就是它所达到的形状:在一个团队中,人工智能负责验证工作,护栏捕获否则会通过代码审查的故障类别,工程师将思考时间花在实际需要工程判断的问题上。
这已经在不同规模上得到了验证——首先是独立项目,然后是中型团队,然后是企业规模的组织。该机制适用于这三个方面。展开成本不同(独立开发人员可以跳过需求注册表和跨供应商对抗性审查;企业团队需要它们)。修改节奏是不同的(一个单独的项目可能在“/constitute”调用之间花费数周;具有多个贡献代理的企业团队每周运行它们)。但无论团队规模如何,核心循环、棘轮和证据要求的行为方式都是相同的。质量底线只会上升,验证机制将其保持在那里,而不依赖于本周房间里最有经验的审核者是谁。
人工智能挂钩
宪法通过加载的上下文来管理代理行为。 Hooks 在工作完成且 PR 开放之前执行操作。如果没有钩子,在审查时就会发现违规行为:代理已经编写了代码,PR 存在,修复它意味着重新做工作。使用钩子,拦截发生在任何击键之前。
**Claude Code 和 GitHub Copilot 都会在提示提交时运行钩子。** 当新任务到达时,钩子会在代理执行任何操作之前触发。它的工作是:检查任务是否不平凡,然后将任务列表重新连接到“/wow”循环中——代理在运送任何东西之前必须遵循的 10 步 EDD 序列。
| 步 | 描述 |
|---|---|
| 1 | 更新任务的文档 |
| 2 | 编写或更新测试(E2E 或单元) |
| 3 | 运行有针对性的测试 - 确认失败 |
| 4 | 在证据之前捕获 |
| 5 | 落实任务 |
| 6 | 运行有针对性的测试 - 确认通过 + 全套绿色 |
| 7 | 捕捉证据后 |
| 8 | 验证文档匹配实施 |
| 9 | 运行“/audit” - 修复关键/高发现值 |
| 10 | 总结并等待人工审核 |
未完成步骤 1-4 就到达步骤 5 的代理已违反循环。挂钩在会话开始时建立序列 - 而不是在事后。
**Claude Code** 在任何文件写入、终端命令或 git 操作之前还会触发预工具调用挂钩。如果未满足循环步骤,则无法尝试提交。
**GitHub Copilot** 还会触发 PR 创建挂钩。在 PR 描述最终确定之前,该钩子会在自我审查模式下运行“/audit”——在人工审查者看到草稿之前捕获维度违规、缺失证据和空测试计划。到达审稿人的内容已经经过预先筛选。
**Codex 和其他代理** 在撰写本文时没有本机钩子表面。后备方案是一个 CI 观察机器人,它在 PR 创建后立即发表评论并标记违规行为。它是一个后挡板,而不是第一面浇口——工作在它启动时就已经完成了,所以它不会阻止钩子消除的返工。
在具有活动挂钩的项目中,违规行为会在会话期间内联纠正。代理抓住差距,提供证据,并从一开始就将其包括在内。审稿时间下降。返工消失。宪法从智能体读取的文档转变为智能体实时操作的约束。
附录 - 完整宪法
接下来是该项目的实际“CONSTITUTION.md”——一个单一开发人员、完全自主的人工智能辅助开发项目。它管理对此代码库所做的每一个重要更改。这不是模板或插图。这是每个代理在每个会话中加载的实时文档。