两扇门，一个闸口：超越 EDD 的治理

入职规则和开发者摩擦往往看起来是同一个问题。但事实并非如此。

当你的团队规模扩大到 40 名开发者时，你不能对每个人都使用相同的培训方法。有些开发者是 AI Agent 专家，而另一些则是新手。如果你为所有人制定一套统一的规则，你就会失败。

经验丰富的开发者会无视规则，而新手则会因规则而感到挣扎。

你必须将你的方法分为两个截然不同的层级：

  • 感知工具 (Awareness tools) 这些工具改变的是一个人的认知。例如 AI 评审评论或 lint 警告。它们的作用类似于前台接待员：察觉问题并建议操作。只有当人们听取建议时，它们才会生效。

  • 治理工具 (Governance tools) 这些工具改变的是一个人的权限。例如分支保护和合并闸口 (merge gates)。它们的作用类似于旋转闸机：不接受协商。如果未满足要求，它们会直接中断流程。

错误在于，在需要闸机的地方却使用了接待员。开发者忽略的 AI 建议并不是治理，而仅仅是噪音。

要解决这个问题，请使用两个独立的层级：

  1. 治理层 (The Governance Layer) 这一层级规模较小且具有普适性。无论技能如何，它都适用于所有人。它包括诸如“禁止直接推送至受保护分支”和“强制评审”之类的规则。这无关信任，而是为了保护代码库免受 Agent 驱动变更带来的高风险。

  2. 脚手架层 (The Scaffolding Layer) 这一层级具有个性化且灵活。它包括显式规划和详细推理等步骤。新手会大量使用这些步骤来培养判断力。经验丰富的开发者可以随着能力的提升而减少使用。这并不是对资历的奖励，而是一个随着技能提高而变得不再必要的工具。

你还应该关注变更本身的风险。一名资深开发者修改一个复杂且高度耦合的文件，其风险比一名初级开发者修改一个简单的工具函数要大。系统应该对代码做出响应，而不仅仅是对人做出响应。

最后，要关注所有权。AI Agent 可能会编写代码，但开发者对结果负责。如果在评审过程中，开发者无法解释为什么要进行某项变更，那么该变更就不应被合并。

不要再用等级来划分人员。相反，应提供工具让他们能够管理自己的风险。

Source: https://dev.to/karlheinz_reichel_7ee08d/two-doors-one-gate-navigating-governance-beyond-edd-5clj

Optional learning community: https://t.me/GyaanSetuAi