When Spec-Driven Development Pays Off 规范驱动开发何时能带来回报

Verification Is the New Bottleneck验证是新的瓶颈

AI coding assistants stopped being a novelty and became infrastructure. In 2026, most engineering teams use coding assistants weekly. AI authors a large and rising share of production code. AI generates code across the whole lifecycle. The uncomfortable part is that AI raised the volume of code without raising anyone’s confidence that the code is correct, secure, or aligned with what was actually intended. Controlled studies report real productivity gains, but also slowdowns and quality problems under production conditions, as well as a steady stream of empirical work showing that AI-generated code reaching production with security weaknesses, familiar bug patterns, and quiet behavioral drift.AI 编码助手已不再是新鲜事物，而是成为了基础设施。到 2026 年，大多数工程团队每周都会使用编码助手。AI 编写了大量且占比不断上升的生产代码。AI 在整个生命周期中生成代码。令人不安的是，AI 在增加代码量的同时，并没有提高任何人对代码正确性、安全性或与实际意图一致性的信心。对照研究报告了实际的生产力提升，但也指出了生产环境下的减速和质量问题，以及源源不断的实证研究表明，AI 生成的代码进入生产环境时带有安全漏洞、常见的 Bug 模式和静默的行为偏差。

So the bottleneck moved. It used to be writing; now it is verification, which reframes the hard question as a governance question rather than a model-capability one: Who is accountable for AI-generated behavior, how do you detect when it diverges from intent, and how do humans and models split the labor of oversight?因此，瓶颈转移了。过去是编写，现在是验证。这把难题从模型能力问题重新定义为治理问题：谁对 AI 生成的行为负责，如何检测它何时偏离了意图，以及人类和模型如何分担监督工作？

This matters in 2026 Q2, not in the abstract, because the obligations are landing now. The EU AI Act’s high-risk provisions demand risk management, record-keeping, and meaningful human oversight. ISO/IEC 42001 asks for a documented AI management system with controls and audit trails. The NIST AI Risk Management Framework organizes the same expectations under Govern, Map, Measure, and Manage. If a growing share of production code is AI-generated, simply saying we review the output carefully provides little evidence of how risk management, record-keeping, and human-oversight controls are actually implemented.这在 2026 年第二季度意义重大，并非抽象概念，因为相关义务正在落地。《欧盟人工智能法案》（EU AI Act）的高风险条款要求进行风险管理、记录保存和有效的人类监督。ISO/IEC 42001 要求建立一个带有控制措施和审计追踪的记录在案的 AI 管理系统。NIST AI 风险管理框架将同样的期望组织在“治理、映射、测量和管理”之下。如果越来越多的生产代码是 AI 生成的，仅仅声称我们仔细审查了输出，并不能证明风险管理、记录保存和人类监督控制是如何实际实施的。

Related Sponsors相关赞助商

• The Practical Agentic Coding Playbook 实用智能体编码手册

• Make Quality Executable: Verification Gates for Agentic Engineering at Scale让质量可执行：大规模智能体工程的验证门禁

• How Morgan Stanley Is Scaling Software Modernization with Automated Refactoring摩根士丹利如何通过自动化重构扩展软件现代化

• Making AI Reliable in the SDLC: The Role of Deterministic Context at Scale让 AI 在软件开发生命周期中可靠：确定性上下文在大规模场景下的作用

• Beyond the Data Lake: Building AI-Ready Data Foundations for Agentic AI超越数据湖：为智能体 AI 构建 AI 就绪的数据基础

Related Sponsor相关赞助商

Automated code transformation at scale. Fix vulnerabilities, migrate frameworks, and modernize legacy code across every repo. Try Moderne Free.大规模自动化代码转换。修复漏洞、迁移框架，并对每个仓库中的遗留代码进行现代化改造。免费试用 Moderne。

The popular response is to review the spec, not just the code. This approach treats the specification as the contract the AI must satisfy, reviews up front, and holds the generated code accountable to it. I believe in that framework, but I wanted to know whether it survives measurement, so I built a study around the one act at its center, a human reviewing AI-generated code against an approved baseline.普遍的应对方法是审查规范，而不仅仅是代码。这种方法将规范视为 AI 必须满足的契约，进行预先审查，并要求生成的代码对其负责。我相信这一框架，但我希望了解它是否经得起测量，因此我围绕其核心的一个行为进行了一项研究：人类根据批准的基准审查 AI 生成的代码。

The honest result changed how I argue for the whole idea. This is the reason for this article. A specification baseline did not help reviewers catch more bugs. Rather, the baseline made the bugs they caught accountable. Knowing that distinction is what lets you decide when the cost of using AI is worth paying.诚实的结果改变了我论证这一理念的方式。这就是本文的原因。规范基准并没有帮助审查者发现更多的 Bug。相反，基准使他们发现的 Bug 变得可追究。了解这种区别，才能让你决定何时值得付出使用 AI 的成本。

The findings below come from a study of mine accepted at GAISS 2026. They are preliminary and directional with small samples and a few tasks. I will be specific about the limits throughout.以下发现来自我的一项被 GAISS 2026 录用的研究。它们是初步且具有方向性的，样本量较小且任务有限。我将在全文中明确其局限性。

Treating the Specification as a Governance Baseline将规范视为治理基准

A specification is the written, agreed description of what a piece of software must do before anyone builds it, including the requirements, the interfaces, and the behavior that can be tested. In this study a specification has three layers: the specification itself (the business requirements and rules), a high-level design (HLD) that defines the components and their interfaces, and a low-level design (LLD) that pins down the concrete invariants each method must uphold. For example, a specification for a money-transfer service states a business rule such as "a transfer must never leave an account balance negative".规范是在任何人构建软件之前，对软件必须执行的操作的书面、达成一致的描述，包括需求、接口和可测试的行为。在本研究中，规范分为三层：规范本身（业务需求和规则）、定义组件及其接口的高级设计（HLD），以及确定每个方法必须维护的具体不变量的低级设计（LLD）。例如，货币转账服务的规范声明了一条业务规则，如“转账绝不能使账户余额为负”。

The specification’s HLD defines a TransferService interface with a transfer operation (i.e., from, to, and amount). The specification’s LLD makes that testable as an invariant: In other words reject the transfer and emit no ledger entry when amount exceeds available balance. Those clauses are exactly what a reviewer later checks the AI-generated code against.规范的 HLD 定义了一个具有转账操作（即从、到、金额）的 TransferService 接口。规范的 LLD 使其作为不变量可测试：换句话说，当金额超过可用余额时，拒绝转账且不生成分类账条目。这些条款正是审查者随后对照 AI 生成的代码进行检查的内容。

To make this concrete, here is one thread of the actual baseline used in the study, traced through all three layers. At the specification layer, a business requirement states that a transfer must move funds between accounts atomically, apply at most once per idempotency key, and never create or destroy money. At the HLD layer, those requirements become a contract.为了具体说明，这里是研究中使用的实际基准的一条线索，贯穿所有三层。在规范层，业务需求声明转账必须在账户之间原子化地移动资金，每个幂等键最多应用一次，且绝不创造或销毁货币。在 HLD 层，这些需求成为了一份契约。

A transfer operation (including from_id, to_id, amount, and idempotency_key) on the Bank component, with transfers, validation, and an ordered audit history identified as distinct subsystems. At the LLD layer, the same requirement is pinned down as a testable method contract. Look up both accounts (raise on unknown). If the idempotency key was already applied, return the prior result without moving funds again. Next, verify sufficient funds or abort with no change to either account. Then debit the source and credit the destination as a single unit and append a history record to both. Each clause maps to a named invariant a reviewer can cite: transfer_idempotent, transfer_atomic_on_fail, transfer_moves_funds, and assets_conserved. The full baseline defines twenty such invariants across core money operations, transfers, interest, daily limits, statements, and account lifecycle. That numbered invariant list is the drift contract the reviewer checks against the generated code.Bank 组件上的转账操作（包括 from_id、to_id、金额和幂等键），其中转账、验证和有序的审计历史被识别为不同的子系统。在 LLD 层，相同的需求被确定为可测试的方法契约。查找两个账户（未知则报错）。如果幂等键已应用，则返回先前的结果而不再次移动资金。接下来，验证资金是否充足，否则中止且不对任一账户进行更改。然后将源账户借记并贷记到目标账户，作为一个单元，并向两者追加历史记录。每个条款都映射到一个审查者可以引用的命名不变量：transfer_idempotent、transfer_atomic_on_fail、transfer_moves_funds 和 assets_conserved。完整的基准定义了 20 个此类不变量，涵盖核心货币操作、转账、利息、每日限额、对账单和账户生命周期。那个编号的不变量列表就是审查者对照生成的代码进行检查的偏差契约。

Before presenting the results, here is the governance model under test. The core move is to treat the specification not as prompt decoration but as the governance artifact, the reviewed, approved, versioned contract that every control point and every accountability decision refers back to. It rests on three principles: govern the input before the output (a reviewed spec is cheaper to fix than generated code), make the baseline explicit and auditable (the approved specification plus high-level and low-level design form one reference baseline), and keep a human in the loop for judgment, not volume (automation flags divergence, while a named human decides what is correct).在展示结果之前，先介绍一下正在测试的治理模型。核心举措是将规范视为治理工件，而非提示装饰，它是经过审查、批准、版本化的契约，每个控制点和每个问责决策都要参考它。它基于三个原则：在输出前治理输入（审查过的规范比生成的代码更易于修复），使基准明确且可审计（批准的规范加上高级和低级设计构成一个参考基准），并让人类参与判断而非处理工作量（自动化标记偏差，而指定的个人决定什么是正确的）。

That approach produces five lifecycle control points, each emitting an artifact the next one consumes, as summarized in Table 1. 该方法产生了五个生命周期控制点，每个控制点都会输出下一个控制点所消耗的工件，如表 1 所示。

Table 1. The five lifecycle control points of specification governance, each emitting an artifact the next consumes.表 1. 规范治理的五个生命周期控制点，每个控制点输出下一个控制点所消耗的工件。

The important part is not just that these five control points exist, but that each one leaves something concrete behind. The approved baseline captures what humans agreed the system should do. The generation record ties the code to that specific baseline. The drift log records where the implementation diverged, and the reconciliation record captures how a human resolved that divergence. Together, those artifacts turn the workflow from “we reviewed the AI output” into something that can actually be traced, explained, and audited.重要之处不仅在于这五个控制点的存在，还在于每一个控制点都留下了具体的东西。批准的基准捕获了人类对系统应执行操作的共识。生成记录将代码与该特定基准联系起来。偏差日志记录了实现偏离的位置，调节记录捕获了人类如何解决这种偏差。总之，这些工件将工作流程从“我们审查了 AI 输出”转变为可以实际追踪、解释和审计的内容。

The resulting architecture, as shown in Figure 1 below, is an iterative loop rather than a one-way prompt. A baseline is authored and approved, the model generates against a specific version, drift is detected against that same version, and a human reconciles each meaningful divergence. A change to the design returns to the review gate; a code defect returns to generation or implementation. The records produced along the way form the audit trail.由此产生的架构，如下图 1 所示，是一个迭代循环而非单向提示。基准被编写和批准，模型针对特定版本进行生成，针对同一版本检测偏差，人类调节每一个有意义的偏差。设计变更返回到审查门禁；代码缺陷返回到生成或实现阶段。沿途产生的记录构成了审计追踪。

[Click on the image to enlarge it][点击图片放大]

Figure 1. Specification-driven governance loop for AI-generated code (Source: created by author). 图 1. AI 生成代码的规范驱动治理循环（来源：作者创建）。

The point of this layout is that the audit trail every governance regime asks for is not extra work bolted on. Rather, it falls out of the loop as a by-product. Each AI-generated behavior traces to an approved requirement and an accountable human decision. That is also where accountability gets named explicitly: The model is Responsible (R) for generation but never Accountable (A), the two core roles in a RACI model (i.e., Responsible, Accountable, Consulted, and Informed). Accountability always rests with a human. That is the operational meaning of “meaningful oversight”. It is the part conceptual governance frameworks usually leave undefined.这种布局的意义在于，每个治理制度要求的审计追踪并不是额外添加的工作。相反，它是作为副产品从循环中产生的。每个 AI 生成的行为都可追溯到批准的需求和可问责的人类决策。这也是问责制被明确命名的地方：模型对生成负有“负责”（Responsible, R）义务，但从不承担“问责”（Accountable, A）职责，这是 RACI 模型（即负责、问责、咨询、告知）中的两个核心角色。问责制始终由人类承担。这就是“有效监督”的操作含义。这是概念性治理框架通常未定义的定义部分。

The Drift-Review Study: Recall vs. Attribution偏差审查研究：召回率与归因

The framework’s central human act is drift review, judging whether AI-generated code diverges from the agreed design. So I ran a controlled, within-subject study on exactly that act.该框架的核心人类行为是偏差审查，即判断 AI 生成的代码是否偏离了商定的设计。因此，我针对这一行为进行了一项受控的受试者内研究。

I evaluated that review on two dimensions: recall, meaning how many of the real drifts in the code a reviewer successfully identified, and attribution, meaning whether each finding could be tied back to a specific approved requirement or named invariant rather than simply reported as something that looked wrong.我从两个维度评估了该审查：召回率（意味着审查者成功识别了代码中多少实际偏差）和归因（意味着每个发现是否可以追溯到特定的批准需求或命名不变量，而不是仅仅报告为看起来不对劲的东西）。

The system under study is a multi-account banking service, a deliberately small but genuinely regulated financial domain, where correctness, validation, spending limits, interest accrual, account statements, and a complete audit trail all matter. The system exposes an API a real core-banking system would recognize with open_account, deposit, withdraw, balance, transfer, history, set_daily_withdraw_limit, accrue_interest, statement, total_assets, and close_account. Two independent implementations (services A and B) were generated so results would not hinge on a single codebase. This domain was chosen because it concentrates the properties that make AI-generated code risky. Money must be conserved, transfers must be atomic and idempotent, overdrafts and daily limits must be enforced and every balance change must be auditable. This is exactly the kind of multi-constraint, high-stakes logic where a plausible-looking but subtly wrong implementation causes real harm.所研究的系统是一个多账户银行服务，这是一个刻意小型但真正受监管的金融领域，其中正确性、验证、支出限额、利息应计、账户对账单和完整的审计追踪都至关重要。该系统公开了一个真实的银行核心系统会识别的 API，包括 open_account、deposit、withdraw、balance、transfer、history、set_daily_withdraw_limit、accrue_interest、statement、total_assets 和 close_account。生成了两个独立的实现（服务 A 和 B），以确保结果不会取决于单一代码库。选择该领域是因为它集中了使 AI 生成代码具有风险的属性。货币必须守恒，转账必须是原子且幂等的，透支和每日限额必须强制执行，且每一笔余额变动都必须可审计。这正是那种包含多重约束、高风险的逻辑，在这种逻辑下，看似合理但细微错误的实现会导致真正的损害。

Five reviewers, each with three-to-ten years of experience, did two independent reviews of real AI-generated banking services, in a counterbalanced 2×2 design. In the Baseline condition, a reviewer received the approved specification, HLD, and LLD, and reviewed the code against it. In the Code-only condition, they received only the public API and had to judge correctness. This is precisely today’s default AI-code-review workflow, in which a human judges generated code with no approved contract. Each service appeared in both conditions across the pool, so reviewer-level and service-level confounds cancel out. Reviewers worked alone without running the code, without an AI assistant, and without  web access. Ground truth was eleven adjudicated drifts in one service and ten in the other.五名审查者，每人拥有三到十年的经验，对真实的 AI 生成银行服务进行了两次独立审查，采用平衡的 2×2 设计。在“基准”条件下，审查者收到批准的规范、HLD 和 LLD，并对照其审查代码。在“仅代码”条件下，他们只收到公共 API，必须判断其正确性。这正是当今默认的 AI 代码审查工作流程，即人类在没有批准契约的情况下判断生成的代码。每项服务在整个群体中都以两种条件出现，因此审查者层面和系统层面的混杂因素相互抵消。审查者独立工作，不运行代码，没有 AI 助手，也没有网络访问权限。真实情况是一个服务中有 11 个已裁定的偏差，另一个有 10 个。

The findings were established by inspecting the source, because a single test suite missed real defects the reviewers correctly found. The banking services under review were implemented in Java and Python, with JUnit and Mockito for the test suites that established ground truth. Generation and the automated-reviewer replication used a mix of frontier models, including Anthropic Claude Opus 4.8, OpenAI GPT-5.2, DeepSeek V4, and Google Gemini 3.1. The specification, HLD, and LLD were authored as a single versioned Markdown baseline. The statistical tests (i.e., Wilcoxon signed-rank, Mann-Whitney, and Fleiss' kappa) were implemented in Python using only the standard library. 研究结果通过检查源代码确定，因为单个测试套件漏掉了审查者正确发现的真实缺陷。正在审查的银行服务使用 Java 和 Python 实现，使用 JUnit 和 Mockito 作为确定真实情况的测试套件。生成和自动化审查者复制使用了多种前沿模型，包括 Anthropic Claude Opus 4.8、OpenAI GPT-5.2、DeepSeek V4 和 Google Gemini 3.1。规范、HLD 和 LLD 被编写为单一的版本化 Markdown 基准。统计测试（即 Wilcoxon 符号秩检验、Mann-Whitney 检验和 Fleiss' kappa）使用标准库在 Python 中实现。

A few details on how the study was run. Ground truth was established by adjudicating each service against its twenty-invariant baseline by source inspection, eleven real drifts in service A and ten in service B, because a single executable test suite missed defects the reviewers correctly found. Each reviewer report was scored on two axes: recall (distinct real drifts reported divided by the adjudicated real-drift count for that service) and attribution (whether each finding was tied to a specific named invariant rather than a generic "something looks off"). Inter-rater agreement used Fleiss’ kappa on the found/not-found vectors and the paired Baseline-versus-Code-only contrast used a Wilcoxon signed-rank test, because every reviewer did one review of each kind.关于研究如何进行的一些细节。真实情况是通过对照 20 个不变量基准检查每个服务进行源代码检查而确定的，服务 A 中有 11 个真实偏差，服务 B 中有 10 个，因为单个可执行测试套件漏掉了审查者正确发现的缺陷。每个审查者报告都在两个轴上进行评分：召回率（报告的独特真实偏差除以该服务已裁定的真实偏差计数）和归因（每个发现是否与特定的命名不变量挂钩，而不是通用的“看起来不对劲”）。评分者间一致性使用 Fleiss' kappa 处理发现/未发现向量，配对的“基准”与“仅代码”对比使用 Wilcoxon 符号秩检验，因为每位审查者都进行了一次每种类型的审查。

The automated replication reused the identical 2×2 design and the same adjudicated ground truth, with large language models placed in the reviewer seat for ninety machine reviews, scored by the same recall and attribution definitions and compared with a Mann-Whitney U test. The generation-side experiments, which produced the delivery-mode and chain-of-thought results, were separate. They compared arms such as direct generation, chain-of-thought (reason first, no specification), a single prompt containing spec-then-code, and a staged arm that authored a SPEC.md and then implemented from it in a fresh step, across families ranging from single-function tasks to the full twenty-invariant bank service, on a mix of strong and deliberately weak models so any specification effect could be isolated from raw model capability.自动化复制重用了相同的 2×2 设计和相同的已裁定真实情况，将大型语言模型置于审查者席位上进行了 90 次机器审查，由相同的召回率和归因定义评分，并使用 Mann-Whitney U 检验进行比较。生成侧实验（产生了交付模式和思维链结果）是分开的。它们比较了诸如直接生成、思维链（先推理，无规范）、包含“规范后代码”的单一提示，以及分阶段分支（编写 SPEC.md，然后在新的步骤中根据其实现）等手段，涵盖从单函数任务到完整 20 不变量银行服务的系列，在强大和刻意弱小的模型组合上，以便将任何规范效应与原始模型能力隔离开来。

Here is the headline, which is a trade-off rather than a win, as shown in Table 2.以下是标题，这是一个权衡而非胜利，如表 2 所示。

Table 2. Baseline vs. Code-only drift review (Five reviewers, within-subject; paired Wilcoxon).表 2. 基准与仅代码偏差审查（五名审查者，受试者内；配对 Wilcoxon）。

Recall Did Not Improve召回率没有提高

Reviewers caught statistically indistinguishable numbers of drifts with and without the baseline (0.525 vs. 0.518, p=0.69). I state this plainly because the intuitive selling point of spec-driven governance is that it makes reviewers better bug-finders and on this task it simply did not.审查者在有无基准的情况下捕获的偏差数量在统计学上没有区别（0.525 对 0.518，p=0.69）。我直言不讳地说明这一点，因为规范驱动治理的直观卖点是它使审查者成为更好的 Bug 发现者，而在该任务中它确实没有做到。

Attribution Is Where the Effect Lives 归因是效应所在之处

I define a finding’s attribution as whether the reviewer tied it to a specific violated requirement, a named invariant, rather than a generic “something looks off”. Baseline reviewers attributed eighty-one percent of findings to a named clause. Code-only reviewers, with no contract to point at, attributed zero percent (p=0.043). Reviewers found the same defects, but they become ownable (i.e., tied to an approved requirement) only when a baseline exists. Code-only reviewers kept hedging that they "could not tell whether the behavior was intended". That sentence is the whole governance gap in a single line.我将发现的归因定义为审查者是否将其与特定的违规需求（即命名不变量）挂钩，而不是通用的“看起来不对劲”。基准审查者将 81% 的发现归因于命名条款。仅代码审查者由于没有契约可指，归因率为 0%（p=0.043）。审查者发现了相同的缺陷，但只有在存在基准时，它们才变得可归属（即与批准的需求挂钩）。仅代码审查者一直含糊其辞，称他们“无法判断该行为是否是预期的”。这句话在单行中概括了整个治理差距。

The baseline also raised confidence (4.2 vs. 3.4, p=0.068) and cost significantly more time (about forty-eight vs. twenty-seven minutes), because reviewers walked the invariant list method by method. That time cost is real and I will come back to it.基准也提高了置信度（4.2 对 3.4，p=0.068），并且显著花费了更多时间（约 48 分钟对 27 分钟），因为审查者按方法遍历了不变量列表。这种时间成本是真实的，我稍后会回到这一点。

For an oversight audience, the recall null is the honest finding and the attribution gain is the contribution. A specification baseline did not make reviewers better bug-finders. Instead, it turned drift review into a contract-anchored, attributable, higher-confidence activity, but at a measurable time cost. That is exactly what a governance regime wants, not more findings, but findings a named reviewer can tie to an approved requirement, defend, and hand off.对于监督受众而言，召回率归零是诚实的发现，而归因收益是贡献。规范基准并没有让审查者成为更好的 Bug 发现者。相反，它将偏差审查变成了一种以契约为锚点、可归因、置信度更高的活动，但代价是可衡量的时间成本。这正是治理制度所需要的：不是更多的发现，而是指定的审查者可以与批准的需求挂钩、捍卫并移交的发现。

Does it Hold When a Model Reviews? A Ninety-Review Replication当模型审查时，它是否成立？九十次审查的复制

Five human reviewers is a real but small signal. To check whether the pattern is structural rather than a quirk of five people, I replicated the identical 2×2 design with large language models in the reviewer seat,  three strong assistants, and ninety machine reviews, scored by the same adjudicated ground truth and the same attribution definition.五名人类审查者是一个真实但微弱的信号。为了检查该模式是结构性的，还是五个人特有的怪癖，我用大型语言模型作为审查者，对相同的 2×2 设计进行了复制，包括三个强大的助手和 90 次机器审查，由相同的已裁定真实情况和相同的归因定义进行评分。

This is a convergent replication in a separate population, not extra statistical power for the human claim. It measures an automated reviewer, rather than a human. I never conflate the two. What it shows is that the same structure reappears, as reported in Table 3.这是一个在独立群体中的收敛复制，而不是对人类主张的额外统计效力。它测量的是自动化审查者，而不是人类。我从不混淆两者。它表明相同的结构再次出现，如表 3 所示。

Table 3. Automated-reviewer replication (Three models and ninety machine reviews; MannWhitney).表 3. 自动化审查者复制（三个模型和 90 次机器审查；Mann-Whitney）。

Recall is unchanged between conditions. Attribution collapses from 0.67 with a baseline to exactly 0.00 without one, consistently across all three models. That 0.00 is structural, not a scoring artifact. With no approved contract, there is no requirement to cite, for a human or a model alike. An LLM reviewer, like a human reviewer, needs the approved specification to make findings attributable. This need also tells you where these increasingly popular LLM code-review tools fit: They are a fine pre-screen step in the loop, but without a governed baseline they can flag issues and still not tie any of them to a requirement or produce an accountability trail.召回率在各条件下没有变化。归因率从有基准时的 0.67 崩溃到没有基准时的正好 0.00，在所有三个模型中表现一致。那个 0.00 是结构性的，而不是评分工件。没有批准的契约，无论是对人类还是模型，都没有可引用的需求。LLM 审查者和人类审查者一样，需要批准的规范才能使发现具有归因性。这种需求也告诉你这些日益流行的 LLM 代码审查工具的定位：它们是循环中很好的预筛选步骤，但没有治理基准，它们可以标记问题，但仍然无法将其中任何一个与需求挂钩或产生问责追踪。

Why Delivery Beats Presence为什么交付优于存在

If the review side says a baseline buys accountability, the generation side says something equally counter-intuitive: How you deliver a specification matters more than whether one exists.如果审查侧表示基准带来了问责制，那么生成侧则说明了一些同样反直觉的内容：交付规范的方式比是否存在规范更重要。

On a twenty-invariant banking service, one arm asked the model for "a specification, then the code" in a single prompt. That was indistinguishable from just asking for code directly. Both landed at 23.8 percent on a weak model. A staged arm, author the specification, then implement from it in a fresh generation step, nearly doubled the pass rate to forty-five percent and halved the builds that failed to assemble. These were the same words with two deliveries. Only the one that treated the spec as a governing artifact rather than inline prompt text moved the outcome. (This trend of p≈0.18 at n=4 carries a second-pass confound discussed below).在 20 个不变量的银行服务上，一个分支在单个提示中要求模型提供“规范，然后是代码”。这与直接要求代码没有区别。两者在弱模型上都达到了 23.8%。一个分阶段的分支（编写规范，然后在新的生成步骤中根据其实现）将通过率提高到了 45%，并将未能组装的构建数量减半。这些是相同的文字，但交付方式不同。只有将规范视为治理工件而非内联提示文本的方法才改变了结果。（这种在 n=4 时 p≈0.18 的趋势带有下文讨论的二轮混杂因素）。

Now comes the part most treatments skip. When "specify first" appears to work wonders on simple tasks, you have to ask whether that is the specification helping or just the extra deliberation the specification forces. So I added a control: Ask the model to reason about edge cases first, but write no specification at all. Across ten single-function families on two strong assistants, that chain-of-thought arm captured almost all of the apparent spec-first gain. For example, fifty-nine percent (just write code) to ninety-five percent (reason first) to ninety-two percent (spec first), with spec-versus-reasoning not significant. The takeaway is deflationary and important. On easy tasks, the dramatic gains people attribute to "specifying first" are largely a reasoning effect in disguise. If you are going to claim specification prompting improves quality, control for reasoning first.现在到了大多数处理方式跳过的部分。当“先定义规范”在简单任务上似乎创造奇迹时，你必须问这是规范的帮助，还是规范所强制的额外审议。因此，我增加了一个控制：要求模型先推理边缘情况，但不编写任何规范。在两个强大助手的十个单函数系列中，那个思维链分支捕获了几乎所有明显的“规范优先”收益。例如，59%（直接写代码）到 95%（先推理）到 92%（先规范），规范与推理之间没有显著差异。结论是通缩且重要的。在简单任务中，人们归功于“先定义规范”的巨大收益，很大程度上是伪装的推理效应。如果你声称规范提示能提高质量，请先控制推理变量。

What it Costs and Where the Evidence Is Thin成本是多少，证据在哪里薄弱

Everything above costs something. Naming the costs is the difference between governance and cargo-culting.以上所有内容都有成本。命名这些成本是治理与形式主义之间的区别。

The most concrete cost is time. The spec-anchored review took roughly forty-eight minutes versus twenty-seven minutes for code-only, which is a recurring, per-output labor cost that scales with the number of invariants a reviewer walks against the code surface. It is predictable rather than open-ended. It is also the most automatable part of the loop (an LLM pre-screen that attributes likely drifts and routes them for regeneration before a human looks is the obvious next step), but today it is a real tax.最具体的成本是时间。以规范为锚点的审查大约花费 48 分钟，而仅代码审查为 27 分钟，这是一种重复的、每个输出的人力成本，随审查者对照代码表面遍历的不变量数量而扩展。它是可预测的，而不是无止境的。它也是循环中最可自动化的部分（LLM 预筛选，在人类查看之前归因可能的偏差并路由以进行重新生成，是显而易见的下一步），但今天它是一项实实在在的税收。

There is also the up-front discipline of authoring specs, HLD, and LLD, and keeping that baseline synchronized as the system evolves. That discipline is the chief deployment barrier. It eases only as drift detection is automated.还有编写规范、HLD 和 LLD 的前期纪律，以及随着系统演进保持基准同步的成本。这种纪律是主要的部署障碍。只有当偏差检测自动化时，它才会变得轻松。

The evidence itself has honest limits. This is a deliberately small pilot with five reviewers, two services, and one domain. At n=5, the paired signed-rank test bottoms out at p=0.043, so the "significant" results certify a consistent direction across reviewers, not a calibrated effect size. Read them as a strong pilot signal, not confirmatory proof. The confidence effect is directional. The staged-generation win carries a second-pass confound (the winning arm runs the model twice, so some of the edge may come from the extra pass, rather than the spec). The automated replication is convergent support in a separate population, not a substitute for human oversight. In addition, it could inherit model biases. I report all of this information because honest evidence hands you the knife you would use against it  and because governance work that hides its own uncertainty is not governance.证据本身有诚实的局限性。这是一个刻意的小型试点，有五名审查者、两个服务和一个领域。在 n=5 时，配对符号秩检验在 p=0.043 时触底，因此“显著”结果证明了审查者之间的一致方向，而不是校准的效应大小。将其视为强有力的试点信号，而不是确认性证明。置信度效应是方向性的。分阶段生成胜利带有二轮混杂因素（获胜分支运行了两次模型，因此部分优势可能来自额外的一轮，而非规范）。自动化复制是独立群体中的收敛支持，而不是人类监督的替代品。此外，它可能继承模型偏差。我报告所有这些信息是因为诚实的证据会交给你用来反驳它的刀，而且隐藏自身不确定性的治理工作不是治理。

A Targeting Rule for When to Spend the Effort何时投入精力的目标规则

Put the pieces together and you do not get "always write specs". You get a targeting rule.把这些碎片拼在一起，你得到的不是“总是编写规范”。你得到的是一条目标规则。

Specification governance pays the most in one specific corner: hard, multi-constraint work built by a capable-but-imperfect model. On the complex banking task, the weaker model, with room to improve, gained about twenty-one points from spec discipline. The strong model, which already aced the task, gained roughly two. On trivial tasks the apparent win was mostly the reasoning effect. So, reach for a targeting rule on regulated, high-stakes, long-lived systems (.e.g., finance, insurance, and healthcare) where many constraints must stay consistent, intent must survive over time, and you already owe an audit trail to a standard or regulator. Skip it for throwaway scripts and prototypes and for tasks your assistant reliably one-shots.规范治理在特定角落收益最大：由能力尚可但不完美的模型构建的、包含多重约束的复杂工作。在复杂的银行任务中，有改进空间的较弱模型从规范纪律中获得了约 21 个点的提升。已经出色完成任务的强模型获得了约 2 个点。在琐碎的任务中，明显的胜利主要是推理效应。因此，在受监管、高风险、长寿命的系统（如金融、保险和医疗保健）中，当许多约束必须保持一致、意图必须随时间存续，且你已经欠标准或监管机构审计追踪时，请使用目标规则。对于一次性脚本和原型，以及你的助手能可靠一次性完成的任务，请跳过它。

When you do reach for a targeting rule, the accountability structure is what makes it real. Name the roles as a RACI, an author who writes the spec, a reviewer who approves it, the model that generates, and a reconciler who resolves each drift, with a human always Accountable even though the model is Responsible for generation. Those artifacts can provide supporting evidence for the governance, traceability, record-keeping, and human-oversight controls emphasized by NIST AI RMF, ISO/IEC 42001, and the EU AI Act.当你确实使用目标规则时，问责结构使其成为现实。将角色命名为 RACI，即编写规范的作者、批准它的审查者、生成代码的模型，以及解决每个偏差的调节者，即使模型对生成负有责任，人类也始终承担问责。这些工件可以为 NIST AI RMF、ISO/IEC 42001 和欧盟 AI 法案所强调的治理、可追溯性、记录保存和人类监督控制提供支持证据。

A staged adoption path, laid out in Table 4, keeps the cost manageable:表 4 中列出的分阶段采用路径使成本保持在可控范围内：

 Table 4. A staged path to specification governance that spends effort where the targeting rule says it pays.表 4. 一种规范治理的分阶段路径，在目标规则认为值得的地方投入精力。

Conclusion结论

AI made code abundant and made governance, not writing the code, the new bottleneck. The instinct is to sell specification discipline as a way to catch more bugs. The measurements say otherwise: an approved baseline did not raise recall, but it took drift review from zero percent attributable to eighty-one percent attributable, at a real and now-quantified time cost. Delivery beats presence, easy-task gains are mostly reasoning. The honest limits are worth stating out loud.AI 使代码变得丰富，并使治理（而非编写代码）成为新的瓶颈。本能是将规范纪律作为捕获更多 Bug 的方式来推销。测量结果却并非如此：批准的基准并没有提高召回率，但它将偏差审查从 0% 的可归因性提升到了 81% 的可归因性，代价是真实且现在已量化的时间成本。交付优于存在，简单任务的收益主要是推理。诚实的局限性值得大声说出来。

So govern the input before the output, hold the code accountable to an approved baseline, and explicitly name the human accountable for deciding how each meaningful drift is resolved. Then spend that governance where the targeting rule says it pays off: hard, high-stakes, long-lived systems built by capable-but-imperfect models, rather than a keystroke of ceremony anywhere else. Make the code abundant. Just don’t make the plan optional. Don’t pretend the plan is free.因此，在输出前治理输入，让代码对批准的基准负责，并明确命名负责决定如何解决每个有意义偏差的人类。然后，在目标规则认为值得的地方投入治理：由能力尚可但不完美的模型构建的、困难、高风险、长寿命的系统，而不是在其他任何地方进行形式化的敲击。让代码变得丰富。只是不要让计划成为可选项。不要假装计划是免费的。

About the Author

Nitin Garg

Nitin Garg is a Staff Software Engineer at GEICO with over twenty-one years of experience building dependable software, now focused on building dependable software in the age of AI coding assistants. His work centers on the governance and oversight of AI-generated code: how teams keep AI-written software correct, accountable, and auditable in high-stakes, regulated domains such as finance and insurance. His research on specification-driven governance for AI-assisted development was accepted at GAISS 2026. He writes about engineering reliable systems with AI in the loop.

Show moreShow less