Consider a composite of a failure pattern that’s becoming increasingly common on teams that have scaled AI-assisted development past a handful of enthusiasts.让我们来看看一种在那些将 AI 辅助开发规模化到少数核心拥护者之外的团队中，变得越来越普遍的故障模式。
A staff engineer named Priya opens a pull request. The PR is 340 lines and adds an endpoint that writes to the customer table directly, bypassing the internal customer service API. The code is clean. The tests pass. The AI coding agent that wrote it has been the team’s most productive contributor for six months. The reviewer, three months into the team, approves. The PR ships that afternoon.一位名叫 Priya 的资深工程师提交了一个合并请求（PR）。该 PR 包含 340 行代码，增加了一个直接写入客户表的端点，绕过了内部客户服务 API。代码写得很整洁，测试也能通过。编写该代码的 AI 编码代理是团队过去六个月中最高产的贡献者。入职三个月的审阅者批准了该请求。当天下午，该 PR 就上线了。
Two weeks later, during an integration debug, someone notices that customer records written by that endpoint are missing audit-log entries. The audit hooks live in the customer service API. The team banned direct database access two years ago for exactly this reason and wrote an architectural decision record (a versioned markdown document, one of dozens the team has accumulated, that captured what was decided, why, and what was superseded) to memorialize the rule. The engineer who wrote the ADR has since left. Nobody on the current team remembered the decision. The document was sitting in a directory the current workflow never touches.两周后，在一次集成调试中，有人发现该端点写入的客户记录缺少审计日志条目。审计钩子位于客户服务 API 中。正是出于这个原因，团队在两年前就禁止了直接访问数据库，并编写了一份架构决策记录（ADR，一种带版本控制的 Markdown 文档，是团队积累的数十份此类文档之一，用于记录决策内容、原因以及被取代的决策）来纪念这一规则。编写该 ADR 的工程师已经离职，当前团队中没人记得这个决定。该文档存放在当前工作流程根本不会触及的目录中。
The endpoint gets rewritten. Audit gaps get backfilled. The team spends most of a sprint on cleanup. Nobody calls this a failure of AI-assisted development. The AI wrote functional code. It just wrote code that violated a decision the team had already made, in a document the AI had no view into.端点被重写，审计漏洞被补上，团队花费了大部分冲刺时间来做清理工作。没人称这是 AI 辅助开发的失败，因为 AI 编写了功能正常的代码。它只是违反了团队之前做出的决定，而该决定记录在 AI 无法查看的文档中。
This is a specific failure mode. It is not a hallucination since the output was grounded, syntactically valid, and idiomatic. It’s not a model-quality problem since a better model on that same prompt wouldn’t necessarily help if the decision remained absent from its context. It’s a memory problem. Not the model-internal sense of context window, but the organizational sense. The ADR was available in the repository. It was never surfaced to the agent, and the reviewer had not read it.这是一种特定的故障模式。它不是“幻觉”，因为输出是有据可查、语法正确且符合惯用法的。这也不是模型质量问题，因为如果决策在模型的上下文中依然缺失，更好的模型也不一定能解决问题。这是一个记忆问题。不是模型内部上下文窗口意义上的记忆，而是组织层面上的记忆。ADR 虽然在仓库中，但从未呈现给代理，审阅者也没有读过它。
This piece is about naming what would need to exist for that PR to have been caught, or better, never written in the first place.本文旨在定义为了捕获此类 PR（或者更好的是，从一开始就避免编写此类代码）所需要具备的条件。
The rework signal返工信号
Priya’s PR illustrates one source of a broader rework problem. Faros AI, an engineering analytics platform, published a report in 2026 based on telemetry from more than 22,000 developers across 4,000+ teams. AI-code acceptance rates had risen from 20% to 60% between periods of low and high AI adoption, while code churn (i.e., lines deleted within days of being added) had increased 861% over the same interval.Priya 的 PR 展示了更广泛的返工问题的一个来源。工程分析平台 Faros AI 在 2026 年发布了一份报告，基于 4000 多个团队中超过 22,000 名开发者的遥测数据。在 AI 应用程度从低到高的期间，AI 代码采纳率从 20% 上升到 60%，而代码流失率（即添加后几天内被删除的代码行）同期增加了 861%。
Faros is careful in how it frames the churn number. The increase may include not only rework but productive refactoring, previously unaffordable cleanup, or faster iterative improvement. But the number still exposes a gap between code entering the repository and code that survives there. A gap that has widened, at scale, alongside AI adoption. Anecdotally, engineers at teams running these tools describe returning to code they had already approved to fix issues that were not obvious at review time. Architectural drift, i.e., code that individually looks fine but collectively pulls the codebase away from where the team agreed it should go, is one plausible contributor.Faros 在界定流失率数据时非常谨慎。这一增长可能不仅包括返工，还包括生产性的重构、以前无法进行的清理工作或更快的迭代改进。但该数字依然揭示了进入仓库的代码与最终保留下来的代码之间的差距。随着 AI 的大规模应用，这一差距在不断扩大。坊间传言，使用这些工具的团队中的工程师描述称，他们不得不返回到已经批准的代码中去修复在评审时并不明显的错误。架构漂移——即代码单独看没问题，但集体导致代码库偏离团队预定方向——是一个可能的诱因。
I’ll call the discipline of preventing this failure mode architectural drift prevention: keeping generated code aligned with the architectural decisions a team has already made.我将防止这种故障模式的准则称为“架构漂移预防”：即保持生成的代码与团队已经做出的架构决策保持一致。
The pattern-matching explanation for that gap has been that the AI isn’t good enough at writing code yet, and a better model will close it. Watch enough review cycles at a team running AI-assisted development for a year, though, and a different pattern emerges. The generated code isn’t obviously bad. It compiles. It passes tests. What it doesn’t do is respect decisions the team has recorded but the AI has never seen.对于这种差距，模式匹配的解释一直是 AI 编写代码的能力还不够强，更好的模型将填补这一空白。然而，观察一个使用 AI 辅助开发一年的团队的评审周期，就会发现另一种模式。生成的代码并不明显糟糕，它能编译，能通过测试。它没有做到的是尊重团队记录在案但 AI 从未见过的决策。
Why current tools sit at the wrong layer为什么当前的工具处于错误的层级
Teams commonly reach for several existing mechanisms to close this gap. Most of them are the wrong shape for the problem.团队通常会采用几种现有的机制来缩小这一差距，但其中大多数对于这个问题来说并不合适。
The closest attempts are files like Cursor Rules and CLAUDE.md, i.e., free-text markdown documents dropped into the project root so agents read them as standing instructions. These are the right instinct at the wrong resolution. Free text has no precedence rules, no versioning, no lifecycle. When one rule contradicts another, nothing arbitrates. When a rule is violated, nothing catches it. These are documents in the shape of configuration.最接近的尝试是像 Cursor Rules 和 CLAUDE.md 这样的文件，即放入项目根目录的自由文本 Markdown 文档，以便代理将其作为现成指令读取。这些直觉是对的，但分辨率不对。自由文本没有优先级规则，没有版本控制，没有生命周期。当一条规则与另一条规则冲突时，没有任何裁决机制。当规则被违反时，没有任何东西能捕获它。这些文档只是配置的伪装。
Linters and code formatters operate a layer below. They enforce that a function has a return type annotation or that a variable name follows a convention. They can’t enforce that customer-data writes must go through the customer service API, because that’s not a syntactic property. It’s a semantic decision recorded in a document the linter has no reason to read.Linter 和代码格式化工具运行在更底层。它们强制要求函数具有返回类型注释或变量名遵循某种约定。它们无法强制要求客户数据写入必须通过客户服务 API，因为这不是语法属性，而是记录在文档中的语义决策，而 Linter 没有理由去读取该文档。
Dependency scanners, SCA tools, and lockfile audits close a related gap; they catch known vulnerable libraries, license violations, and outdated versions. They would’ve flagged nothing about Priya’s PR. Every dependency in it was current, had no known vulnerabilities, and was approved. The violation was a routing choice inside the team’s own architecture, not a library problem.依赖扫描器、SCA 工具和锁文件审计弥补了相关的差距；它们能捕获已知的易受攻击的库、许可证违规和过时版本。它们对 Priya 的 PR 毫无察觉。其中的每个依赖项都是最新的，没有已知漏洞，且已获批准。违规行为是团队自身架构内部的路由选择问题，而不是库的问题。
LLM-assisted code review is the fashionable answer. A second AI reads the pull request and comments on it. This catches surface issues like a swallowed exception, an off-by-one bug. It doesn’t catch drift, however, because the second AI has the same problem as the first: no durable access to the team’s recorded decisions. Two probabilistic passes over the same blind spot are not one deterministic pass with sight.LLM 辅助代码评审是目前流行的答案。第二个 AI 读取合并请求并发表评论。这能捕获诸如异常处理不当、越界错误等表面问题。然而，它无法捕获漂移，因为第二个 AI 和第一个 AI 面临同样的问题：无法持久访问团队记录的决策。对同一个盲点进行两次概率性的扫描，并不等同于一次具有洞察力的确定性扫描。
Human review is the last line, and it works when the reviewer knows the history and has enough time to inspect the change. Agentic development changes both conditions. Agents can produce multiple implementations, pull requests, and revisions in the time it takes a human reviewer to assess one. Code output scales; review attention does not. Asking humans to compensate by reviewing more and harder simply moves the constraint downstream.人工评审是最后一道防线，当评审者了解历史并有足够时间检查变更时，它是有效的。代理式开发改变了这两个条件。代理可以在人类评审者评估一个请求的时间内产生多个实现、合并请求和修订。代码产出是可扩展的，但评审注意力不是。要求人类通过更努力、更频繁地评审来补偿，只会将限制条件推向下游。
None of these tools are bad. They’re just the wrong layer for the drift problem.这些工具本身并不坏，只是对于漂移问题来说，它们处于错误的层级。
What the missing layer would need to do缺失的层级需要做什么
The missing layer connects recorded engineering decisions to the tools that generate, review, and merge code. Its job is to make the team’s accumulated architectural decisions machine-readable, injectable, and enforceable. I’ll call this layer engineering governance, borrowing the term from adjacent categories like data governance and security governance, where it means the same thing: A structured way for an organization to make explicit and enforceable the rules it already implicitly follows.缺失的层级将记录在案的工程决策与生成、评审和合并代码的工具连接起来。它的工作是使团队积累的架构决策变得可机读、可注入且可强制执行。我将其称为“工程治理”，借鉴了数据治理和安全治理等相邻领域的术语，其含义相同：一种让组织将其隐性遵循的规则明确化并强制执行的结构化方法。
At the shape level, the layer needs to do four things.在形态上，该层级需要完成四件事。
- It needs to hold decisions in a structured corpus with precedence and lifecycle metadata so that a tool knows which ADR wins when two conflict, and which decisions are still active. 它需要将决策保存在具有优先级和生命周期元数据的结构化语料库中，以便工具在两者冲突时知道哪个 ADR 胜出，以及哪些决策仍然有效。
- It needs to retrieve from that corpus reliably, so the same code produces the same set of relevant decisions each time. 它需要从语料库中可靠地检索，以便相同的代码每次都能产生相同的一组相关决策。
- It needs to inject those decisions into the AI’s context before the agent writes code, so the output accounts for them rather than needing to be caught afterwards. 它需要在代理编写代码之前将这些决策注入到 AI 的上下文中，以便输出结果考虑到这些决策，而不是事后再去捕获。
- It needs to enforce them in continuous integration, blocking or flagging code that violates them, with the verdict traceable to a specific ADR, a specific term that matched, a specific rule.它需要在持续集成中强制执行这些决策，拦截或标记违反决策的代码，并将裁决结果追溯到特定的 ADR、特定的匹配术语或特定的规则。
The critical property that ties those four together is a discipline about where probabilistic reasoning is allowed. Probabilistic systems may retrieve or recommend. They shouldn’t independently determine an enforcement verdict. Every block or warning has to reconstruct from artifacts on disk. That’s the code, the ADR, the retrieval log, the rule text. Then, when a developer asks “why did this fail?” or an auditor asks “on what basis?” the answer isn’t “the AI said so.” That’s what makes the layer defensible in the situations where defensibility matters: regulated environments, compliance review, incident retrospectives, and the everyday conversation where an engineer has to justify a blocked merge to the person whose code was blocked.将这四点结合在一起的关键属性是关于允许概率推理的准则。概率系统可以检索或推荐，但它们不应独立决定强制执行的裁决。每一个拦截或警告都必须从磁盘上的工件中重构出来。这就是代码、ADR、检索日志和规则文本。然后，当开发者问“为什么失败了？”或者审计员问“基于什么？”时，答案不是“AI 说的”。这就是在需要可辩护性的情况下（如受监管环境、合规性评审、事故回顾，以及工程师必须向代码被拦截的人证明拦截合理性时）使该层级具有可辩护性的原因。
AI may help surface relevant decisions, but it shouldn’t be the final authority. The enforcement path must remain deterministic: every verdict should resolve to explicit rules, observable evidence in the code, and a result that another person can reproduce.AI 可能有助于浮现相关的决策，但它不应是最终权威。强制执行路径必须保持确定性：每一个裁决都应归结为明确的规则、代码中可观察的证据，以及其他人可以重现的结果。
Defining the boundaries定义边界
Naming a category clearly requires naming what falls outside it. The engineering governance layer, done right, is not any of the following:清晰地命名一个类别需要明确其范畴之外的内容。设计得当的工程治理层不是以下任何一种：
- An agent. Nothing autonomous. Nothing iteratively deciding what to do next. The layer runs when called, produces a verdict, and stops.一个代理。没有自主性，没有迭代决定下一步做什么。该层级在被调用时运行，产生裁决，然后停止。
- Memory in the retrieval-augmented-generation sense. Retrieval methods can vary and may be probabilistic; the enforcement verdict cannot. The corpus of decisions is the source of truth.检索增强生成（RAG）意义上的记忆。检索方法可以变化且可能是概率性的，但强制执行的裁决不能是概率性的。决策语料库是真相的来源。
- Code reviewed by AI. Reviewing generated code with a second model doesn’t address the underlying problem, which is that the first model had no access to the team’s decisions.由 AI 评审的代码。用第二个模型评审生成的代码并不能解决根本问题，因为第一个模型根本没有访问团队决策的权限。
- Vendor-locked. Production teams increasingly run Cursor, Claude Code, GitHub Copilot, and Codex in parallel, sometimes on the same repository. They may also use open-weight or self-hosted models for sensitive codebases and internal workflows. Engineering governance must remain independent of both the coding tool and the underlying model, so the same architectural decisions and deterministic enforcement apply across them all.供应商锁定。生产团队越来越多地并行运行 Cursor、Claude Code、GitHub Copilot 和 Codex，有时甚至是在同一个仓库上。他们也可能在敏感代码库和内部工作流中使用开放权重或自托管模型。工程治理必须独立于编码工具和底层模型，这样相同的架构决策和确定性强制执行才能应用于所有这些工具。
The emerging engineering stack新兴的工程栈
The AI coding stack is assembling itself in the open, without anyone architecting it. Each of the major coding assistants is specializing on a different piece of the loop; editing, autonomous execution, review, planning. The layer this stack doesn’t yet have is engineering governance.AI 编码栈正在公开地自我组装，没有人对其进行架构设计。主要的编码助手都在循环的不同部分进行专业化：编辑、自主执行、评审、规划。这个栈目前缺失的层级就是工程治理。
The need isn’t limited to regulated industries. Any team that values reliable engineering, long-term product quality, and the trust of its customers needs to know that generated code respects the decisions the system depends on. In higher-risk environments, that requirement becomes formal and auditable. Elsewhere, it’s simply part of building software responsibly. In both cases, the enforcement path should be deterministic and traceable, with the rules, evidence, and verdict open to inspection rather than hidden inside another model or a proprietary black box.这种需求不仅限于受监管的行业。任何重视可靠工程、长期产品质量和客户信任的团队，都需要确保生成的代码尊重系统所依赖的决策。在高风险环境中，这种要求变得正式且可审计。在其他地方，它只是负责任地构建软件的一部分。在这两种情况下，强制执行路径都应该是确定性的且可追溯的，规则、证据和裁决应开放以供检查，而不是隐藏在另一个模型或专有的黑盒中。
For engineering leaders reading this today致今天的工程领导者
Priya’s PR is a pattern, not an incident. Three things worth doing this quarter, regardless of tooling choices.Priya 的 PR 是一种模式，而不是单一事件。无论选择什么工具，本季度有三件事值得做。
- Audit your architectural decision records. Are they current? Do they explicitly name the decisions they replace? If your team doesn’t write ADRs, this is the moment to start. The tooling that will exist in twelve months assumes structured architectural decisions as input.审计你的架构决策记录。它们是最新的吗？它们是否明确指出了所取代的决策？如果你的团队不编写 ADR，现在是开始的时候了。十二个月后出现的工具将把结构化的架构决策作为输入。
- Choose the enforcement posture deliberately. The system can either warn the developer and let them continue or block the change until the issue is resolved. Both approaches can work, but the team should agree on which applies instead of leaving the decision to each developer or each pull request.慎重选择强制执行的姿态。系统可以警告开发者并让他们继续，也可以拦截变更直到问题解决。两种方法都可以，但团队应该就适用哪种达成共识，而不是将决定权留给每个开发者或每个合并请求。
- Don’t assume a more powerful model will solve this problem. Better models can improve the code they generate, but they still can’t follow architectural decisions they’ve not been given. Preventing architectural drift requires changing the surrounding system, not simply waiting for the next model.不要假设更强大的模型能解决这个问题。更好的模型可以改进生成的代码，但它们仍然无法遵循未被告知的架构决策。防止架构漂移需要改变周围的系统，而不是仅仅等待下一个模型。
The productivity gains from AI-assisted development are real and worth having. So is the architectural coherence teams spent years building. Engineering governance is the layer that lets you keep both.AI 辅助开发带来的生产力提升是真实且值得拥有的。团队多年来建立的架构一致性同样如此。工程治理正是让你两者兼得的层级。
