多年来工程的稀缺资源是工程师带宽——能写代码的人时。瀑布、敏捷，很多流程骨子里都是为”实现很贵”设计的。现在一些团队遇到了另一种局面：代码、测试、重构的候选，生成得比审查、集成、担责任更快。瓶颈没有神秘地消失，它可能只是搬去了验证、评审与安全——但”可能”两个字要靠数据兑现：看每条工作流的等待时间、回滚率、事故成本，才知道它真的搬了没有。

For years engineering’s scarce resource was engineering bandwidth: the hours of people who can write code. Waterfall and agile were, at bottom, designed around the assumption that implementation is expensive. Some teams now face a different situation: candidates for code, tests, and refactors arrive faster than review, integration, and consequence-bearing can absorb them. The bottleneck hasn’t magically disappeared; it may just have moved to verification, review, and security. But “may have” has to be earned with data: wait time, rollback rate, incident cost, workflow by workflow, before you know whether it actually moved.

把这件事说精确一点，得先分清两种"快"。一种是打字快：把脑子里已经想清楚的东西敲进编辑器，这件事自动补全、代码片段、脚手架早就在解决，IDE 过去二十年干的基本就是它。另一种是把没想清楚的东西变成正确系统，这一种从来不是打字慢，是判断慢：模块该怎么切、这个边界条件算不算 bug、这次性能回退能不能接受。agentic coding 几乎把第一种压到零，却把第二种原样留下，甚至放大了它——生成越快，等着被判断的候选就越多。所以"工程师用 AI 写得更快"这句话本身就量错了级：真正发生的是工作的构成变了，而非同一份工作做快了——打字那份蒸发，判断那份几乎变成全部。

To put it precisely, you have to separate two kinds of “fast.” One is typing fast: keying in what you’ve already worked out in your head. Autocomplete, snippets, and scaffolding have been chipping at this for two decades; it’s most of what the IDE era was about. The other is turning something not-yet-thought-through into a correct system, and that was never slow typing, it was slow judgment: how to cut the module, whether this edge case counts as a bug, whether this performance regression is acceptable. Agentic coding crushes the first to near zero and leaves the second untouched, or worse, amplifies it, because the faster generation runs, the more candidates pile up waiting to be judged. So “engineers write faster with AI” is an order-of-magnitude misdescription. What’s actually happening is the composition of the work changing, not the same work done faster: the typing share evaporates and the judgment share becomes almost all of it.

把这条判断倒过来看反而最清楚：vibe-coding 陷阱。把"执行充裕"听成"可以放任"，就是这么掉进去的——让 agent 凭感觉一路生成，不写规格、不设验证，建在猜测上的系统会以很诡异的方式垮掉。它垮不是因为模型笨，是因为承重结构本来就没搭：没有 spec 当目标函数，生成没有收敛的方向；没有独立 checker，自信地错没人拦得住；没有边界，一次越权就是全盘。"执行充裕 ≠ 放任"是这一卷反复要守住的纪律——充裕解放的是打字，不是判断，省下来的判断带宽要重新投进验证、规格、边界这三个新瓶颈，不能揣进兜里。〔源 Graziano《AI-Native Engineering》Day 1 "vibe-coding trap"，证据级 Ⅳ 一手从业者[R1]〕

Flip the claim over and it’s clearest: the vibe-coding trap. Hear “execution is abundant” as “you can be lax,” and this is exactly how you fall into it: let the agent generate on vibes, no spec, no verification, and a system built on guesses collapses in strange ways. It doesn’t collapse because the model is dumb; it collapses because the load-bearing structure was never built. No spec as an objective function, so generation has nowhere to converge. No independent checker, so confident wrongness goes uncaught. No boundary, so one over-privileged call takes down the whole thing. “Abundant execution does not mean licence” is the discipline this volume keeps returning to: abundance frees up typing, not judgment, and the judgment bandwidth it frees has to be reinvested in the three new bottlenecks, verification, specs, boundaries, not pocketed. [Source: Graziano, AI-Native Engineering Day 1, “vibe-coding trap,” grade Ⅳ practitioner. [R1]]

这也解释了工程卷为什么更适合做小范围实验：代码通常可读、可 diff、可执行、可测，反馈可能以秒计而不是以季度计。一次 CI 红灯不解释全部问题，但它逼着团队把”哪道护栏漏了”写成一条可检查的假设。短反馈回路不是答案本身，它只是让下面这些命题能被跑一遍、改一遍，必要时收回。

This is also why the engineering volume can run smaller experiments than the others: code is legible, diffable, executable, testable, and feedback can arrive in seconds rather than quarters. One red CI run doesn’t explain the whole problem, but it forces a team to state, as a checkable hypothesis, which guardrail leaked. A short feedback loop is what lets the claims below actually get run, corrected, and withdrawn when they’re wrong, not the answer by itself.

从实现者到编排者：人持有的三件没变

From implementer to orchestrator: the three the human keeps

把”工作构成变了”落到一个可照做的角色描述上：工程师从实现者（implementer）变成编排者（orchestrator）——不再逐行实现，而是持有三件 agent 替不了你的东西。第一是意图（intent）：要什么、为什么、不要什么，这是生成的方向，写错了 agent 会很高效地造出错的东西。第二是约束（constraints）：架构、标准、非目标，这是生成的边界，缺了它 agent 会在每个岔路口自己猜，猜出来的局部最优往往是全局的债。第三是验证（verification）：测试、评审、质量门，这是生成的判据，没有它，”对不对”又会退回那颗跟不上生成速度的人脑里。这三件恰好对应内核的②判断与④人：编排者不是”管 agent 的经理”，是把判断从实现细节抬到意图、约束、验证这三个构成性节点上的人——这里的”构成性”，指的是决定”何为对”本身，而不是在既定标准里执行。〔源 Graziano《AI-Native Engineering》Day 1 implementer→orchestrator、intent/constraints/verification 三件由人持有，证据级 Ⅳ 一手从业者[R1]〕

Put “the composition of work changed” into a role description you can actually use: the engineer moves from implementer to orchestrator, no longer implementing line by line, but holding three things an agent can’t hold for you. First, intent: what, why, and what not; this is generation’s direction, and get it wrong and the agent will efficiently build the wrong thing. Second, constraints: architecture, standards, non-goals; this is generation’s boundary, and without it the agent guesses at every fork, and the local optimum it guesses is often a global debt. Third, verification: tests, review, quality gates; this is generation’s criterion, and without it “is this correct” falls back onto a human brain that can’t keep pace with generation. These three map exactly onto the kernel’s ② judgment and ④ people: an orchestrator is the person who lifts judgment up to these three constitutive nodes (intent, constraints, verification), not “a manager of agents.” “Constitutive” here means deciding what counts as correct in the first place, not executing inside a standard someone else already set. [Source: Graziano, AI-Native Engineering Day 1, implementer→orchestrator, with intent/constraints/verification held by the human, grade Ⅳ practitioner. [R1]]

这个迁移也重排了工程师的技能栈。过去稀缺的是"把想清楚的东西快速正确地敲出来"这项实现技能；当这份工作被 agent 吸收，稀缺的变成四样上游能力：规格素养（把模糊意图写成无歧义、可机检的规格）、上下文工程（决定此刻窗口里该有什么、不该有什么）、编排（把大任务切成 agent 能可靠完成的小步，设好检查点）、验证（设计能自动判对错的检查，而不是事后逐行人审）。这四样没有一样是"提示词技巧"，都是判断密集、离"何为对"很近的工程能力。这也给个人成长一条可证伪的方向：一个工程师用了两年 AI，时间却仍主要花在敲实现、而不是这四样能力上，那他多半还停在"用 AI 写得更快"的嫁接阶段，没有真正迁移成编排者。

This migration also reorders an engineer’s skill stack. What used to be scarce was the implementation skill: keying out, fast and correctly, what you’d already thought through. Once the agent absorbs that, scarcity moves to four upstream capabilities: spec literacy (turning fuzzy intent into an unambiguous, machine-checkable spec), context engineering (deciding what should and shouldn’t be in the window right now), orchestration (cutting a large task into steps an agent can reliably complete, with checkpoints set), and verification (designing checks that decide correctness automatically, instead of a human reviewing line by line after the fact). None of these four is a prompting trick; they’re all judgment-dense engineering capabilities sitting close to “what counts as correct.” That gives personal growth a falsifiable test: if an engineer has “used AI” for two years and still spends most of their time keying out implementation rather than these four capabilities, they’re most likely still stuck at the graft stage, writing faster with AI, not actually migrated to orchestrator.

嫁接与重画的分界线：一个可当场做的判别

The line between grafting and redrawing: a test you can run on the spot

"把 AI 嫁接到旧流程上"和"围绕 agent 重画整张图"听起来像态度差别，其实有一个当场就能判别的结构标准：看你的流程在哪里还假设"打字很贵"，又在哪里已经按"验证很贵"重排过。嫁接的典型样子是——流程骨架没变，还是同样的需求评审、同样的排期、同样的人审节奏，只是"写代码"这一格换成了 AI，于是产出快了，下游的验证、评审、集成却照老速度走，产出全堵在验证那里，堆成一座山。

重画的样子正相反。既然写代码不再是瓶颈，整张图就该把重心从"怎么写得更快"挪到"怎么判得更快"：验证前移、自动化、和生成解耦；人审从逐行改成异步分诊；规划视野缩短，贴着信号走。一个干净的判别问题是："如果明天写代码的速度再快十倍，你的流程会更顺，还是会在某处堵得更死？"嫁接的流程会堵得更死，因为瓶颈没挪地方，只是被喂得更猛；重画的流程会更顺，因为它的承重结构本来就建在验证那一侧。这也呼应组织卷反复说的那句话：瓶颈不会消失，只会搬家。嫁接之所以失败，本质是没承认瓶颈已经搬到了验证，还在原来那个已经不是瓶颈的地方使劲。可证伪的信号很具体：如果你的团队"用了 AI"之后产出明显变快，交付质量或周期却没跟着好、甚至更差，那几乎一定是嫁接——快出来的产出，全堵在那个没被重画的下游瓶颈上。

“Graft AI onto the old process” versus “redraw the whole graph around agents” sounds like a difference in attitude, but there’s a structural test you can run on the spot: look at where your process still assumes typing is expensive, and where it has actually been rearranged around verification being expensive. The grafted shape is typical: the process skeleton hasn’t changed, same requirements review, same scheduling, same human-review cadence, only the “write code” cell now has AI in it. Output speeds up, but downstream verification, review, and integration keep running at the old pace, and output piles up into a mountain right at verification.

The redrawn shape is the opposite. Since writing code is no longer the bottleneck, the whole graph should shift its center of gravity from “how do we write faster” to “how do we judge correctness faster”: verification moved earlier, automated, decoupled from generation; human review shifted from line-by-line to asynchronous triage; planning horizon shortened to track the signal. A clean test question: “if writing code got ten times faster tomorrow, would your process flow more smoothly, or jam harder somewhere?” A grafted process jams harder: the bottleneck hasn’t moved, it’s just being fed more aggressively. A redrawn process flows more smoothly: its load-bearing structure was already built on the verification side. This echoes what the organization volume keeps saying: the bottleneck doesn’t vanish, it moves house. Grafting fails because it never admits the bottleneck moved to verification, and keeps pushing on the spot that isn’t the bottleneck anymore. The falsifiable signal is concrete: if your team “uses AI” and output is clearly faster but delivery quality or cycle time hasn’t improved to match, or has gotten worse, that’s almost certainly a graft. The faster output is all jamming up at the downstream bottleneck that was never redrawn.

这些是同一栋楼的楼层，并非相互竞争的"工程学"。早期你在底层逐字写 prompt。模型变强，你上移到喂 context、写 spec，再到搭 harness（承载 agent 循环、能自动验对错的脚手架），最后只设计 loop（让 agent 自我改进的那个循环）、调度 fleet（一支并行干活的 agent 队伍）。一个具体的样子：一个工程师从前一字一句调提示词，如今改成写清规格、再逐 diff 评审 agent 的产出。这就是他的着力点在往上挪。你这季度的着力点在哪一层，就是组织的判断瓶颈所在。低于它的，交给 agent 或产品化；高于它的，是你下一步该去设计的地方。

These are not competing “engineerings” but floors of one building. Early on you write prompts word by word at the bottom. As models strengthen you move up to feeding context, writing specs, then building the harness (scaffolding that carries the agent loop and verifies correctness automatically). At the top you only design the loop (the cycle that lets the agent self-improve) and schedule the fleet (a parallel team of agents working at once). A concrete shape: an engineer who used to tune prompts word by word now writes a clear spec and reviews the agent’s output diff by diff. That is their leverage climbing. Whichever floor your leverage sits on this quarter is where the judgment bottleneck is. Below it, hand off to agents or productize; above it is where you design next.

• Prompt → Context：从逐字指令，到把"它需要知道的一切"做成可查询的上下文。
• Prompt → Context: from word-by-word instructions to making “everything it needs to know” a queryable context.
• Spec → Harness：从写清"什么算对"，到搭起承载循环、能自动验的脚手架。
• Spec → Harness: from stating “what counts as correct” to building scaffolding that carries the loop and verifies automatically.
• Loop → Fleet：从设计单个自我改进的循环，到调度一支并行的 agent 队伍。
• Loop → Fleet: from designing a single self-improving loop to scheduling a parallel fleet of agents.

读这张图前，先说清它到底画的是什么。分的不是六种互相竞争的技术，而是同一件事——你亲手对 AI 做的活儿——被切成的六段；每上一层，你写得更少、管得更宽：从逐字敲指令，到只写一句"什么算对"就让 agent 自己跑完。这六层也不是谁凭空规定的，是过去四年被行业逐个起了名的操作台阶（prompt、context、spec、harness、loop、fleet）；相邻两层的分界都落在同一处折痕上——又一类判断刚好被产品化，于是每被产品做熟一层，人就腾出手上移一层。楼层比喻的意思正落在这里：下层不是消失了，是被工具吃进去、沉成你不必再碰的基础设施；上层才是眼下归你设计的地方。所以这张图只需这样读——先认出你此刻站在第几层，再问上面那层该去设计什么。

Before reading the figure, be clear on what it actually pictures. What is sliced is not six competing technologies but one thing: the work you do with your own hands on AI, cut into six segments; each floor up, you write less and oversee more, from typing instructions word by word, to writing a single “what counts as correct” and letting the agent run it itself. Nor were these six decreed out of thin air: they are the operating rungs the industry named one by one over four years (prompt, context, spec, harness, loop, fleet); the divide between any two adjacent rungs falls on one and the same crease, the point where yet another class of judgment has just been productized, so each time a rung gets productized, the human’s hands are freed to climb one floor higher. That is exactly what the floor metaphor means: a lower floor has not vanished, it has been absorbed into tools and sunk into infrastructure you no longer touch, while the upper floors are what is yours to design right now. So read the figure just this way: first recognize which floor you stand on, then ask what the floor above is for you to design.

底层是控制论的复活。把那栋楼的每一层抽象掉，剩下的骨架古老得令人意外：一个 agent 就是推理客户端 + 一组工具 + 一个 while 循环——读状态、决定下一步、调工具改变状态、再读。这正是 Wiener 1948 年讲的反馈控制：感知、比较、作动、再感知。HuggingFace 的 Tiny Agents 把这个最小内核压进 50 行代码，说明楼层是同一个控制回路在不同抽象层的展开，而非技术堆叠的产物。理解这一点有实际用处：当你不知道某个新工具该放哪一层，问它在这个回路里扮演感知、比较还是作动，就能定位——工具会换，回路不会。

Underneath is cybernetics reborn. Abstract away every floor of the building and the skeleton left is startlingly old: an agent is an inference client + a set of tools + a while loop: read state, decide the next step, call a tool to change state, read again. This is exactly Wiener’s 1948 feedback control: sense, compare, actuate, sense again. HuggingFace’s Tiny Agents compresses this minimal kernel into 50 lines, showing the floors are not a product of stacking technology but the same control loop unfolded at different levels of abstraction. This has practical use: when you do not know which floor a new tool belongs on, ask whether it plays sense, compare, or actuate in that loop, and you can place it; the tools change, the loop does not.

为什么电梯只往上、从不往下。因为每一层一旦"够好且可机检"，它就会被产品化、被下一代模型吸收，于是人在那层的边际价值趋零。你被推着上楼，是因为站在原地的回报在塌，而非因为你想。prompt 工程曾是 2023 年的热门技能，截至本版（2026-07）已基本被自动补全和系统提示吃掉；context 工程正在被 RAG 与上下文库逐步自动化。这给出一个可证伪的预测：今天显得高级的 spec / harness 工作，也会沿同一条路下沉——若三年后"写 spec"仍是稀缺技能而非基础设施，这个楼层模型就被削弱了。反过来，它也划出人的持久着力点：楼顶那几层（loop 设计、fleet 调度、以及决定"该不该造"的判断）下沉得最慢，因为它们恰好是最不可机检、只能由人来定的判断。

Why the elevator only goes up, never down. Because once a floor is “good enough and machine-checkable,” it gets productized and absorbed by the next model generation, so a human’s marginal value on that floor trends to zero. You are pushed upstairs not because you want to but because the payoff for standing still is collapsing. Prompt engineering was the hot skill of 2023 and, as of this edition (2026-07), is largely eaten by autocomplete and system prompts; context engineering is being automated by RAG and context stores. This yields a falsifiable prediction: today’s seemingly advanced spec / harness work will sink along the same path: if “writing a spec” is still a scarce skill rather than infrastructure three years out, this floor model is weakened. Conversely it marks the human’s durable leverage: the top floors (loop design, fleet scheduling, and the judgment of “whether to build at all”) sink slowest, precisely because they are the least machine-checkable, most constitutive judgments.

怎么判断你这季度站在哪一层

How to tell which floor you are on this quarter

楼层模型若只是个好比喻，价值有限；它真正可操作的地方，是给"瓶颈在哪"一个能当场自测的判据。问三个问题就能定位你当前的着力层。其一，你最近一次为 agent 做的最费神的事是什么？如果是逐字斟酌怎么措辞一个请求，你还在 prompt 层；如果是组织"它需要知道的一切"，你在 context 层；如果是写清"什么算对"，你在 spec 层；如果是搭"每次运行都自动验证并纠偏"的脚手架，你在 harness 层。其二，低于这一层的事，是不是已经基本不用你操心了？——若你还在频繁手写 prompt，说明 context 层其实没立起来，你只是误以为自己在上面。其三，高于这一层的事，是不是开始让你觉得"该有个系统来管了"？这个隐隐的不适感，正是电梯要往上开一层的信号。

If the floor model is only a nice metaphor its value is limited; where it becomes operational is in giving “where is the bottleneck” a criterion you can self-test on the spot. Three questions locate your current leverage floor. First, what was the most effortful thing you last did for an agent? If it was agonizing word by word over how to phrase a request, you are on the prompt floor; if it was organizing “everything it needs to know,” you are on context; if it was stating “what counts as correct,” you are on spec; if it was scaffolding “verify and self-correct automatically on every run,” you are on harness. Second, are the things below this floor basically off your plate now? If you are still hand-writing prompts frequently, the context floor is not actually built and you only think you are above it. Third, are the things above this floor starting to make you feel “there should be a system for this”? That faint discomfort is precisely the signal that the elevator is due to climb one floor.

这个自测有一个反直觉但重要的推论：不同团队、不同人，此刻站在不同楼层是正常的，而且不该强行拉齐。一个还在手写大量 prompt 的团队，其当务之急是先把 context 层立起来（让上下文成为可查询的基础设施），而不是越级去搭 fleet 调度——越级搭出来的高层脚手架，会因为底层不稳而频繁坍塌。这和组织卷"瓶颈不会消失只会搬家"是同一条纪律的两面：你不能跳过当前瓶颈去优化下一个，因为下一个瓶颈还没成为瓶颈。拿它当场自测一下就知道有没有越级：若一个团队投了大量精力搭多 agent 编排（高楼层），实际产出却仍卡在"每次都要人重新解释一遍上下文"（低楼层没立稳），那就是越级的证据——该退回去先把底层那一层做扎实。

This self-test has a counter-intuitive but important corollary: different teams and different people standing on different floors right now is normal, and should not be forcibly leveled. A team still hand-writing many prompts should first stand up its context floor (make context queryable infrastructure), not skip levels to build fleet scheduling: high scaffolding built across skipped levels collapses often because the lower floor is unstable. This is two sides of the same discipline as the organization volume’s “the bottleneck does not vanish, it moves”: you cannot skip the current bottleneck to optimize the next, because the next is not yet a bottleneck. Falsifiable signal: if a team invests heavily in multi-agent orchestration (a high floor) while real output is still stuck on “having to re-explain context every time” (a low floor not stood up), that is evidence of level-skipping. Retreat and make the lower floor solid first.

为什么没有"回到底层"这回事

Why there is no “going back to the lower floors”

楼层模型有一个对个人和团队都很实在的推论：一旦某一层被产品化、被下一代模型吸收，人就回不去那一层了——是回去没有回报，并非不能。这解释了为什么"我先把提示词技巧练扎实再说"截至本版（2026-07）是一个亏本的投资方向：prompt 这一层正在被自动补全、系统提示、和模型自身的指令遵循能力快速吸收，你在它上面磨出来的精细技巧，会随着下一代模型变得更会"猜你想要什么"而贬值。同样的命运在等着 context 层（RAG 和上下文库在自动化它），并且按楼层模型的预测，迟早会轮到今天显得高级的 spec 与 harness。这给个人成长一个不那么舒服但很清醒的指南：不要在一个正在下沉的楼层上深耕，要往电梯的上方走。

判断一个技能值不值得深投，问它在三年的时间尺度上是会变成稀缺判断、还是会变成基础设施。前者值得投，后者迟早被产品化。这也和内核第④步对上：人最终的持久着力点，是那些下沉得最慢、最不可机检、只能由人来定的判断（决定该造什么、何为对、接缝放哪），因为恰恰是"不可机检"这个性质，让它们抗拒被自动化吸收。可证伪信号：若你发现自己引以为傲的核心技能，每出一代新模型就明显贬值一截，那它大概率是个正在下沉的楼层——该把深耕的重心往上挪一层了。

The floor model has a corollary very real for both individuals and teams: once a floor is productized and absorbed by the next model generation, a human cannot go back to it: not cannot in principle, but going back has no payoff. This explains why “let me first get my prompting tricks solid” is, as of this edition (2026-07), a loss-making investment direction: the prompt floor is being rapidly absorbed by autocomplete, system prompts, and the model’s own instruction-following, and the fine tricks you hone on it depreciate as the next model gets better at “guessing what you want.” The same fate awaits the context floor (RAG and context stores are automating it), and by the floor model’s prediction, sooner or later the spec and harness work that looks advanced today. This gives personal growth a less comfortable but clear-eyed guide: do not dig deep on a sinking floor; move up the elevator.

To judge whether a skill is worth deep investment, ask whether on a three-year horizon it becomes scarce judgment or becomes infrastructure: the former is worth investing in, the latter gets productized eventually. This matches the kernel’s step ④: the human’s ultimately durable leverage is the slowest-sinking, least machine-checkable constitutive judgments (deciding what to build, what is correct, where the seams go), because it is precisely the “not machine-checkable” property that resists being absorbed by automation. Falsifiable signal: if you find the core skill you take pride in visibly depreciating a notch with each new model generation, it is most likely a sinking floor: time to move the center of your deep practice up one floor.

这一节的前提是：在 AI 优先的工作流里，agent 已经是代码与文档的主要读者和作者之一。所以"知识用什么格式存"不再只是人的偏好问题，而是直接决定 agent 能不能用上它。下面先点名四条让产物被放大的属性，再讲清每条背后的机制。

This section assumes one thing: in an AI-first workflow, an agent is already one of the main readers and authors of your code and docs. So “what format knowledge lives in” is no longer just a human preference; it directly decides whether an agent can use it at all. Below we first name the four properties that get a format amplified, then explain the mechanism behind each.

是它们恰好满足了四条对 agent 友好的底层属性，并非工具本身赢。凡满足这四条的产物都被放大，凡是不可读的二进制 / 私有格式都被边缘化：

It is not the tools that win, but that they happen to satisfy four agent-friendly properties. Anything that meets these four gets amplified; opaque binary / proprietary formats get marginalized:

• 对 agent 可读（legibility）：无需解析私有格式，模型直接能读能写。
• Legible to agents: no proprietary format to parse; the model reads and writes it directly.
• 可 diff（diffable）：逐行可比、可版本控制、可评审——改动是一次提交，不是一次覆盖。
• Diffable: line-by-line comparable, versionable, reviewable; a change is a commit, not an overwrite.
• 可被检索（queryable）：能被索引成上下文库，让"问 Claude"有据可依。
• Queryable: can be indexed into a context store so “ask Claude” has something to stand on.
• 人机同源（same source）：人和 agent 读写同一份源，不必维护两套真相。
• Same source: humans and agents read and write the one source; no two truths to maintain.

边界 · 放大不等于"越多越好"。这四条属性让文本被放大，但有一条硬约束。模型有一段有效窗口：它在一次推理里真正能等权重用上的那部分上下文。这段有效窗口远小于标称值。也就是说，往窗口里塞太多反而会降准、加成本、稀释注意力（详见本节后文的有效窗口曲线，源自 Anthropic《Effective Context Engineering for AI Agents》[R3][R1]）。所以可读 / 可 diff / 可查的真正价值，不是"把全部塞进去"，而是让"检索出正确的那一小撮子集"成为可能。可读、可查是必要条件，却不充分。因为另一半是会策展：文本可以无限堆在硬盘上，但喂进窗口的每一段都要被挑选，否则放大会反噬成噪声。

Boundary · amplification is not “more is better.” These four properties amplify text, but one hard constraint holds. A model has an effective window: the slice of context it can actually use at equal weight in a single inference. That effective window is far smaller than the nominal one. That is to say, overstuffing it lowers accuracy, raises cost, and dilutes attention (see the effective-window curve later in this section, after Anthropic’s Effective Context Engineering for AI Agents [R3][R1]). So the real value of legible / diffable / queryable is not “put everything in” but making it possible to retrieve the right small subset. Legible and queryable are necessary, not sufficient. Because the other half is curation: text can pile up without limit on disk, but every piece fed into the window must be chosen, or amplification backfires into noise.

从 prompt 工程到上下文工程

From prompt engineering to context engineering

这条四属性原理换个角度，就是一次术语的迁移：变量从"单条 prompt"移到了"推理时喂给模型的整个状态"。prompt 工程关心怎么把一句话措辞好，上下文工程关心一个更大的问题——此刻这次推理，窗口里应该装哪些东西、以什么顺序、占多少预算。Rules（恒定约束）、Skills（可调用能力）、Commands（封装好的动作）、Custom agents（带专属上下文的子 agent），都是给这个"整个状态"分层供料的方式。它们是同一个问题的四个抽屉，不是四个新玩具：把"模型需要知道的"按"多久变一次"分层存放——恒定的进 Rules，按需的进 Skills，一次性的进 prompt。

Seen from another angle, this four-property principle is a shift of terms: the variable moves from “a single prompt” to “the entire state fed to the model at inference.” Prompt engineering cares how to word one sentence well; context engineering cares about a larger question: for this inference, right now, what should be in the window, in what order, at what budget. Rules (constant constraints), Skills (callable capabilities), Commands (packaged actions), and Custom agents (sub-agents with their own context) are all ways of feeding that “entire state” in layers. They are not four new toys but four drawers of one problem: store “what the model needs to know” by “how often it changes”: constants in Rules, on-demand in Skills, one-offs in the prompt.

一手实践锚 · 用文件作持久真源，而非靠对话历史。上下文腐化（context rot）指的是：随着会话越拖越长，早先说定的事实在对话历史里被稀释、被覆盖、甚至自相矛盾，于是模型"记得"的版本逐渐失真（详见 ENG·09）。它的根因，就是把"真相"留在了这条会腐化的对话历史里。解法是把决策、规格、任务沉淀成文件——SPEC / PLAN / TASKS 三件套就是这个解法的具体形态：它们是磁盘上的持久状态，每次推理从这里重新装配窗口，而不是指望模型"记得"几千 token 之前说过什么。这恰好把"人机同源"从一句原则变成一个可照做的纪律：人改的是文件，agent 读的也是文件，没有第二份漂移的真相。这一条自然把 ENG·02 引向 ENG·03——既然真相住在文件里，下一个问题就是：这些文件能不能被机器检验？〔源 Graziano《AI-Native Engineering》Day 2 / Day 4，证据级 Ⅳ；转引 Anthropic 上下文工程[R1][R3]〕

First-hand practice anchor · use files as the persistent source, not conversation history. Context rot means this: as a session drags on, facts agreed earlier get diluted, overwritten, or self-contradicted inside the conversation history, so the version the model “remembers” slowly distorts (see ENG·09). Its root cause is leaving “the truth” in that rotting conversation history. The fix is to settle decisions, specs, and tasks into files. The SPEC / PLAN / TASKS trio is the concrete shape of that fix: persistent state on disk, from which each inference re-assembles the window, rather than hoping the model “remembers” what was said thousands of tokens ago. This turns “same source” from a principle into a copyable discipline: humans edit files, agents read files, and there is no second drifting truth. It naturally leads ENG·02 into ENG·03: since the truth lives in files, the next question is: can these files be machine-checked? [Source: Graziano, AI-Native Engineering Day 2 / Day 4, grade Ⅳ; via Anthropic context engineering. [R1][R3]]

有效上下文窗口：为什么"喂得越多"反而越差

The effective context window: why “feed it more” makes it worse

"上下文即基础设施"容易被误读成"把一切都塞进窗口"，那是把这一条引向反面。真实约束是：有效上下文窗口远小于标称窗口。一个模型标称能吃二十万 token，不等于这二十万 token 都被等权重地用上——注意力会随上下文变长而稀释，窗口里塞得越多，早期真正关键的约束越容易被淹没。所以上下文工程有两个对称的失败方向：喂太少，agent 缺关键事实只能瞎猜（幻觉的温床）；喂太多，关键信号被噪音稀释，agent 分心、降准、还更贵。这条"少即是多"是 Anthropic《Effective Context Engineering for AI Agents》的核心论点，也是对"上下文越多越好"这个朴素直觉的直接修正。它让 ENG·02 从"为何文本/MD 被放大"的正面收益，补上了"上限与取舍"这一面——而正是这一面让这条原理更难被证伪、也更可操作。〔源 Anthropic《Effective Context Engineering for AI Agents》（经 Graziano Day 4 转引），证据级 Ⅳ（一手厂商工程文章）[R3][R1]〕

“Context as infrastructure” is easily misread as “cram everything into the window,” which turns this principle into its opposite. The real constraint is: the effective context window is far smaller than the nominal one. A model nominally eating 200K tokens does not mean all 200K are used at equal weight: attention dilutes as context grows, and the more crammed into the window, the more the genuinely critical early constraints drown. So context engineering has two symmetric failure directions: too little, and the agent lacks key facts and can only guess (a breeding ground for hallucination); too much, and the key signal is diluted by noise, the agent distracted, less accurate, and more expensive. This “less is more” is the core argument of Anthropic’s Effective Context Engineering for AI Agents, and a direct correction to the naive intuition that “more context is better.” It rounds out ENG·02 from “why text / MD get amplified” (a positive payoff) with the side of “ceilings and trade-offs”, and it is precisely this side that makes the principle harder to falsify and more operational. [Source: Anthropic, Effective Context Engineering for AI Agents (via Graziano Day 4), grade Ⅳ (first-hand vendor engineering article). [R3][R1]]

这条上限直接解释了为什么"用文件作持久真源"优于"靠对话历史"。把 SPEC / PLAN / TASKS 写成版本化的文件，等于把"它需要知道的一切"放在窗口之外的可查询基础设施里，按需检索进窗口，而不是让它在一条越来越长、越来越被稀释的对话历史里反复重读。文件不会随对话变长而腐烂，可以被 diff、被审、被多个 agent 共享；对话历史则恰好相反。它越长越腐烂，且只活在这一个会话里。这也是 ENG·02 通向 ENG·03 的天然过渡：当你认真地"装配"上下文，你迟早会把那份装配写成一份规格，而规格正是下一节的主题。可证伪信号：若你的 agent 在长会话后期开始"忘记"早先说过的关键约束、或重复犯同一个早已纠正过的错，那不是模型变笨，是有效窗口被对话历史塞满了——该把那些约束移出对话、写进文件。

This ceiling directly explains why “files as persistent source” beats “relying on conversation history.” Writing SPEC / PLAN / TASKS as versioned files puts “everything it needs to know” in queryable infrastructure outside the window, retrieved on demand, rather than making it re-read repeatedly inside an ever-longer, ever-more-diluted conversation history. A file does not rot as the conversation lengthens; it can be diffed, reviewed, shared across agents. Conversation history is exactly the opposite: the longer it gets the more it rots, and it lives only in this one session. This is also the natural transition from ENG·02 to ENG·03: when you assemble context seriously, you will eventually write that assembly down as a spec, and the spec is the subject of the next section. Falsifiable signal: if your agent starts “forgetting” key constraints stated earlier, or repeats an error long since corrected, late in a long session, that is not the model getting dumber but the effective window crammed full of conversation history. Move those constraints out of the conversation and into files.

为什么纯文本与 Markdown 在 AI 优先下被放大

Why plain text and Markdown are amplified in an AI-first world

"上下文即基础设施"还有一个具体的形态偏好需要讲清机制，而不是当口号：在 AI 优先的工作流里，纯文本、Markdown、以及结构化的纯文本知识（如知识图谱）的价值被系统性放大，而专有的、二进制的、只能用特定软件打开的格式被边缘化。先把场景摆出来：同一份设计、规格或知识，只有两种存法——锁进某个软件的私有格式，只有那个软件打得开；或者存成任何人、任何程序都能直接读写的纯文本。差别平时看不出，等 agent 上手才暴露：它要读它、改它、比对每次改了什么、再跑一遍检查——这四件事在纯文本上是天然的，在私有格式上每一件都得先造一座桥。被放大的从来是那四条属性、不是文本本身——原因不是文本"更朴素更好"这种审美。前面的 speclist 已经点过这几条属性的名，这里要补的是它们为什么能产生放大效应，也就是背后的机制：

“Context as infrastructure” also has a concrete form preference whose mechanism, not slogan, must be stated: in an AI-first workflow the value of plain text, Markdown, and structured plain-text knowledge (such as knowledge graphs) is systematically amplified, while proprietary, binary formats openable only by specific software are marginalized. First put the scenario on the table: the same design, spec, or piece of knowledge has only two ways to be stored: locked inside some software’s proprietary format that only that software can open, or written as plain text any person and any program can read and write directly. The difference is invisible day to day and surfaces the moment an agent picks it up: it has to read the thing, edit it, compare what changed each time, and run a check over it; four acts that are native on plain text and each need a bridge built first on a proprietary format. What gets amplified is those four properties, never the text itself: the reason is not an aesthetic that text is “plainer and better.” The speclist above already named these properties; what this list adds is why they produce the amplifying effect, the mechanism behind them:

• 人机同源 → 没有第二份漂移的真相。人和 agent 改的是同一份文件，而不是各自维护一份再去对齐。因为只有一份源、没有一层导出或解析的中转，就不会分裂出"人看的文档"和"机器看的数据"两份各自漂移、互相打架的真相。
• Same source → no second drifting truth. Humans and agents edit the one file, instead of each keeping a copy and reconciling later. Because there is a single source and no export-or-parse hop in between, it never splits into “the doc humans read” and “the data machines read” as two truths that drift apart and contradict each other.
• 可 diff → 看得见"改了什么"，而非只看见"现在是什么"。文本的改动逐行可见，因此可以被评审、被回退。这带来一个关键后果：agent 的每一次修改都能当成一个可审查的提交，而不是一次无法追溯的整体覆盖。
• Diffable → you see what changed, not just what it now is. Text changes are visible line by line, so they can be reviewed and reverted. This has one key consequence: every agent edit can be treated as a reviewable commit, not an untraceable wholesale overwrite.
• 可查询、可组合 → 才喂得起"有限的有效窗口"。文本能被检索、被切块、被按需装配进窗口。正因为有效窗口有限、必须主动挑选喂什么，这种"按需取一小撮"的能力才是刚需，而不是锦上添花。
• Queryable, composable → the only way to feed a limited effective window. Text can be retrieved, chunked, and assembled into the window on demand. Precisely because the effective window is limited and you must actively pick what to feed, this “pull the right small subset on demand” ability is a necessity, not a nicety.

把这些机制合起来，"用文本作真源"是对"agent 要能读、要能 diff、要能按需查"这套硬约束的最优响应，而非怀旧。也得诚实划出边界：纯文本赢的是那些要被 agent 频繁读写、反复协作的资产——规格、决策、知识；只给人眼看、不进协作环的东西（比如一张定稿的海报），并不在这条规则里。所以真正赢的是形态，而非某一个工具：把知识存成 agent 能直接协作的形状，你的上下文才是实的。

Put these mechanisms together and “files as source of truth” is not nostalgia but the optimal response to the hard constraint that “the agent must read it, diff it, and query it on demand.” An honest boundary, too: plain text wins on the assets that agents read, write, and collaborate on again and again: specs, decisions, knowledge; things meant for human eyes only and never entering the collaboration loop (a finished poster, say) fall outside this rule. So what really wins is never any one tool but the form: store knowledge in a shape agents can collaborate on directly, and only then is your context real.

一个具体的代价。某团队决定砍掉支付重试，理由（"重试会造成重复扣款"）只记在一条 Figma 评论里，代码本身没留下任何痕迹。几个月后，一个 agent 接到"补上重试以提升成功率"的任务，它读遍代码库也读不到那条评论，于是堂而皇之地把重试加了回来。重复扣款的老问题随之复发。假如当初那句话写进了仓库里的 decisions.md，agent 在检索时就会把它装进窗口，也就不会重犯这个错。所以问题是关键的"为什么"被锁在了它打不开的格式里，而非 agent 不够聪明。

One concrete cost. A team decided to drop payment retries; the reason (“retries cause double charges”) lived only in a Figma comment, with no trace in the code itself. Months later an agent was tasked with “add retries to lift success rate.” It read the whole codebase but never saw that comment, so it confidently put the retries back. The old double-charge bug returned. Had that sentence lived in a decisions.md in the repo, the agent would have pulled it into context on retrieval and not repeated the mistake. The problem was never that the agent was not smart enough; it was that the key “why” was locked in a format it could not open.

可证伪信号：若你团队的关键知识仍主要锁在只有特定软件能打开、agent 读不进来的专有格式里，那么无论你怎么强调"上下文重要"，你的 agent 实际能用上的上下文都是残缺的。因为它被你的格式选择挡在了门外。

Falsifiable signal: if your team’s key knowledge is still mainly locked in proprietary formats openable only by specific software the agent cannot read in, then however much you stress “context matters,” the context your agent can actually use is incomplete. Because your format choice has shut it out at the door.

把意图外化成机器可检验的形式——类型、schema、测试、eval、lint——等于给生成循环一个目标函数：它在生成时就约束、在 CI 里自动验、把“对”从人脑搬进可执行的检查。规格越可机检，生成越能自我收敛、验证越能自动化，这一段有据，类型和 CI 每天都在兑现，也值得一直往这个方向压。没被兑现的是另一半：可机检只保证生成收敛到规格写下的目标，不保证那个目标本身是对的。规格是个放大器，放大的是你写进去的意图——写对了，可靠性随完整度一起涨；写偏了，agent 只会把错的目标执行得更彻底、更快，checker 一个都拦不住，因为它核的是“合不合规格”，从不核“规格该不该这么定”。所以判断没有消失，只是退到了规格的上游：“这是不是该做的目标”，至今没有哪种机器检查能替人回答。这与组织部分的 T1 同一个道理：判断退守到稀缺节点——只是工程这一面最稀缺的节点是定目标，不是查合规。哪天“规格有没有瞄准对的目标”本身也能被可靠机检，这块上游判断才会跟着让给机器；在那之前，越完整的规格越需要有人先为“目标对不对”签字。

Externalize intent into a machine-checkable form: types, schemas, tests, evals, lints, and you give the generation loop an objective function: it constrains at generation, verifies automatically in CI, and moves “correct” from heads into executable checks. The more checkable the spec, the more generation self-converges and the more verification automates: this half is evidenced, types and CI cash it out every day, and it is worth pushing hard in this direction. The other half is not cashed out: machine-checkability only guarantees generation converges on the target the spec wrote down, not that the target itself is right. A spec is an amplifier, and what it amplifies is the intent you put in: aim right and reliability rises with completeness; aim wrong and the agent only executes the wrong target more thoroughly and faster, with the checker catching none of it, because it checks “does this conform to the spec,” never “should the spec have aimed this way.” So judgment does not disappear; it retreats upstream of the spec: “is this the target worth building,” which no machine check can answer for a human yet. The same principle as the organization part’s T1: judgment retreats to scarce nodes, only on the engineering face the scarcest node is setting the target, not checking conformance. The day “did the spec aim at the right target” becomes reliably machine-checkable itself, this upstream judgment will hand off to machines too; until then, the more complete the spec, the more it needs a human to sign off first on whether the target is right.

为什么类型系统的价值被放大——讲清机制，而不是站队语言。不是 TypeScript 这门语言赢，是"把约束写成机器当场能驳回的形式"这件事赢。一个类型签名 (user: User) => Result<Order, PaymentError> 同时是三样东西：一份给人读的意图说明、一份给 agent 的生成护栏（它生成时就被约束在签名内）、一份给编译器的可机检规格（违反当场报错）。这三样过去要靠文档、口头约定、code review 分别维护，现在塌缩成同一行、且不会过期。生成越充裕，这种"当场驳回"的价值越高。因为人来逐个驳回跟不上生成的速度，只有机器能在生成的同一时间尺度上说"不"。凡是能把更多"对"压进编译期、压进类型、压进 schema 的做法，都在沿同一条原理放大；反过来，靠运行时才暴露、靠人事后才发现的约束，都在被边缘化。

Why type systems get amplified: the mechanism, not a language allegiance. It is not the TypeScript language that wins but the act of “writing a constraint in a form the machine can reject on the spot.” A type signature like (user: User) => Result<Order, PaymentError> is three things at once: an intent brief a human reads, a generation guardrail for the agent (constrained to the signature as it generates), and a machine-checkable spec for the compiler (a violation errors out immediately). These three used to be maintained separately as docs, verbal convention, and code review; now they collapse into one line that cannot go stale. The more abundant generation is, the higher the value of this “reject on the spot,” because a human rejecting candidates one by one cannot keep pace with generation. Only a machine can say “no” on the same time scale as generation. Anything that presses more “correctness” into compile time, into types, into schemas amplifies along the same principle; conversely, constraints that only surface at runtime, found only by humans after the fact, are being marginalized.

trust-but-verify 由此长出来。把约束做成可机检的形式，等于声明：agent 的产出默认不可信，要由一个与生成分离的检查器判定才放行。这不是对 AI 的敌意，是工程纪律——人写的代码同样默认不可信，所以我们才有类型检查、测试、CI。区别只在：agent 生成快了几个量级，"事后人审"这条旧防线被冲垮了，必须把验证前移、自动化、并和生成解耦。下一节（ENG·04）讲这个独立验证器如何嵌进循环，ENG·06 讲它如何落成可照做的三档分工。

This is where trust-but-verify grows from. Making constraints machine-checkable is a declaration: the agent’s output is untrusted by default and is released only when a checker, separate from generation, judges it. This is not hostility toward AI but engineering discipline: human-written code is untrusted by default too, which is why we have type checks, tests, and CI at all. The only difference is that the agent generates orders of magnitude faster, the old “humans review afterward” line of defense is overrun, and verification must be moved earlier, automated, and decoupled from generation. The next section (ENG·04) covers how this independent verifier embeds into the loop; ENG·06 covers how it lands as a copyable three-tier division of labor.

把规格写到"哪一档"，决定了它的成色

Which “rung” you write the spec to decides its quality

"机器可检验"还不够精确。它只说了规格要采取什么形式，没说规格在团队里处于什么地位。规格驱动开发（SDD）把这件事铺成一道成熟度阶梯，三级：Spec-First，先写规格再写代码，但规格写完就被搁置，真源仍是代码；Spec-Anchored，规格与代码并存、且规格被当作权威参照，代码偏离规格被视为需要解释的事；Spec-as-Source，规格是唯一真源，代码是从规格生成或对规格负责的产物，改行为先改规格。这条阶梯回答了一个 ENG·03 单讲"形式"时回避的问题：同样是"写了规格"，为什么有的团队规格活、有的团队规格三个月没人碰？因为他们停在不同档。可机检（这一节）是规格的形式条件，成熟度阶梯（ENG·07）是规格的地位条件，两者缺一不可。一份可机检但没人当真源的规格，和一份被当真源但全是自然语言、机器没法验的规格，都会失败。〔源 Graziano《AI-Native Engineering》Day 5–6 SDD 三级成熟度 Spec-First→Spec-Anchored→Spec-as-Source，证据级 Ⅳ 一手从业者[R1]〕

“Machine-checkable” is not precise enough: it states only what form the spec takes, not what standing the spec holds in the team. Spec-driven development (SDD) lays this out as a maturity ladder of three rungs: Spec-First, write the spec before the code, but the spec is shelved once written and the source of truth remains the code; Spec-Anchored, spec and code coexist and the spec is treated as the authoritative reference, with code drifting from spec seen as something requiring explanation; Spec-as-Source, the spec is the sole source of truth, code is generated from or answerable to the spec, and to change behavior you change the spec first. This ladder answers a question ENG·03 ducks when it speaks only of “form”: both teams “wrote a spec,” so why is one team’s spec alive while another’s has gone untouched for three months? Because they sit on different rungs. Machine-checkability (this section) is the spec’s form condition; the maturity ladder (ENG·07) is the spec’s standing condition, and neither is dispensable: a machine-checkable spec no one treats as source, and a spec treated as source but all natural language that no machine can check, both fail. [Source: Graziano, AI-Native Engineering Day 5–6 SDD maturity Spec-First→Spec-Anchored→Spec-as-Source, grade Ⅳ practitioner. [R1]]

类型不是约束的全部：可机检的光谱

Types are not the whole of constraint: the machine-checkable spectrum

说"类型赢"容易被窄化成"用了静态类型语言就行"，那是把这一节的机制读浅了。真正放大的不止类型这一种形式，更是"把约束写成机器当场能驳回的形式"这件事的整条光谱——类型只是这条光谱上最靠近编译期、最廉价的一段。往光谱右边走，依次还有：schema（约束数据的形状）、契约/前后置条件（约束接口的行为）、property-based 测试（约束"对任意输入都该成立的性质"而非单个样例）、不变量断言（约束运行时不该被破坏的状态）、以及 eval（约束语义层面的"对不对"）。

这些都是同一条原理的不同强度版本：把"对"前移到一个不依赖人事后审查、能在生成的同一时间尺度上说"不"的检查里。所以工程师真正该练的判断是"对这一处约束，能把它压到光谱多左边"，而非"该用哪门语言"——能压进类型的别只写注释，能写成 property 的别只写一个样例测试，能让机器在 CI 里当场驳回的别留到人审。可机检比例这个指标，量的就是你的约束整体在这条光谱上有多靠左。可证伪信号：若你的关键约束大量靠"代码注释 + 评审时人记得提醒"来维持，那它们其实在光谱最右、最弱、最易腐烂的那一端。这些约束会在某次没人记得提醒的评审里悄悄失效，而类型或 schema 不会。

Saying “types win” is easily narrowed to “just use a statically typed language,” which reads this section’s mechanism too shallowly. What’s actually amplified isn’t the single form of types but the whole spectrum of “writing a constraint in a form the machine can reject on the spot”: types are merely the cheapest segment of that spectrum, nearest compile time. Moving right along it: schemas (constraining the shape of data), contracts and pre/post-conditions (constraining the behavior of an interface), property-based tests (constraining a property that should hold for any input, not a single example), invariant assertions (constraining state that must not break at runtime), and evals (constraining semantic-level “is it correct”).

These are all different-strength versions of one principle: move “correct” forward into a check that does not depend on after-the-fact human review and can say “no” on the same time scale as generation. So the judgment an engineer should actually practice is not “which language to use” but “for this constraint, how far left on the spectrum can I press it”: what can go into a type, do not leave as a comment; what can be a property, do not leave as one example test; what a machine can reject on the spot in CI, do not leave to human review. The machine-checkable share measures exactly how far left your constraints sit overall. Falsifiable signal: if your key constraints are largely maintained by “code comments plus a reviewer remembering to mention it,” they actually sit at the rightmost, weakest, most rot-prone end of the spectrum. Those constraints quietly lapse in some review where no one remembers, while a type or schema does not.

harness 是承载循环的脚手架（心跳、隔离、知识、触手、制衡——做与查分离）；spec 是循环的目标函数；eval 是承重墙——错误回流成新的 eval，随产出复利增长。而 skills / MCP / CLI 之所以是对的抽象，是因为它们把能力封装成可组合的接口暴露给 agent——底层原理还是上一节那条：对 agent 可读、可组合的纯文本协议赢，工具即上下文。

Harness is the scaffolding that carries the loop (heartbeat, isolation, knowledge, tentacles, checks-and-balances, doing separated from checking); spec is the loop’s objective function; eval is the load-bearing wall: errors flow back as new evals and compound with output. And skills / MCP / CLI are the right abstraction because they package capability into composable interfaces exposed to agents; the underlying principle is the previous section’s: legible, composable, plain-text protocols win, tools are context.

为什么这个最小机制就是进化的最小机制。把"自我改进"这个被滥用的词拆到底，它只需要三件东西凑齐：一个会产生多样候选的生成器（变异）、一个与生成分离、能判优劣的选择器（选择）、一个能把胜出者留到下一轮的外部存储（保留）。三件齐了，系统就会无监督地变好；缺任何一件，它就只会原地抖动。agentic 工作流恰好能凑齐这三件：agent 是生成器，eval / CI 是选择器，上下文库 / skills 库是外部存储。关键的、也最常被省掉的是第二件——选择必须与生成分离。让生成者给自己打分，等于让变异自己决定自己被不被选中，进化立刻退化成随机游走。这就是为什么"独立验证器"是承重墙：不是多一道保险，是这个机制能不能成立的充要条件。

Why this minimal mechanism is evolution’s minimal mechanism. Take the over-used phrase “self-improving” down to the bottom and it needs only three things present together: a generator that produces diverse candidates (variation), a selector, separate from generation, that judges better from worse (selection), and an external store that carries winners into the next round (retention). With all three, the system improves unsupervised; missing any one, it merely jitters in place. Agentic workflows happen to supply all three: the agent is the generator, evals / CI the selector, the context store / skills library the external store. The central and most often omitted piece is the second: selection must be separate from generation. Letting the generator score itself is letting the mutation decide whether it survives, and evolution instantly degrades into a random walk. This is why the “independent verifier” is the load-bearing wall: not an extra safeguard but the necessary and sufficient condition for the mechanism to hold at all.

自改进的具体形态 · skills / commands / rules 库是会复利的项目级资产。steering loop 跑久了，会沉淀出一个东西：把每次失败的修法固化成可复用的 skill、command、rule。这个库和代码库不同——代码库记录"系统是什么"，这个库记录"如何让 agent 把系统做对"。它随团队每次踩坑而增长，且对全队、对每次运行复用，所以它是少数几个真正随时间复利的工程资产之一。一个反直觉的推论：团队的护城河正从"代码本身"向"驯服 agent 的 harness + 库"转移——代码可被重新生成，但你们团队积累的、关于"什么会让 agent 在你们这套系统上犯错"的知识，对手抄不走。

The concrete shape of self-improvement · the skills / commands / rules library is a compounding project asset. Run the steering loop long enough and something settles out: each failure’s fix is hardened into a reusable skill, command, or rule. This library differs from the codebase: the codebase records “what the system is,” this library records “how to get the agent to build the system right.” It grows with every pothole the team hits, and it is reused across the whole team and every run, so it is one of the few engineering assets that genuinely compounds over time. A counterintuitive corollary: a team’s moat is shifting from “the code itself” toward “the harness + library that tames the agent”. Code can be regenerated, but the knowledge your team has accumulated about “what makes the agent err on your particular system” cannot be copied off you.

harness 的解剖（二维分类法，源 Martin Fowler《Harness Engineering for Coding Agents》）。承载循环的脚手架可沿两条轴拆开——guides（前馈，生成前把跑道铺好） 对 sensors（反馈，生成后抓错）；每条轴再分 computational（确定性、廉价：lint / 类型 / 测试 / schema） 对 inferential（靠 LLM 推理：AI 评审 / 语义 diff / 计划批判）。规则很简单：能用 computational 就别用 inferential，inferential 只补"机器测不到的判断层"；多数团队在某一格过投、在另一格欠投。

Anatomy of the harness (a two-axis taxonomy, after Martin Fowler, Harness Engineering for Coding Agents). The scaffolding that carries the loop splits along two axes: guides (feedforward: lay the runway before generation) vs sensors (feedback: catch errors after); each axis splits again into computational (deterministic, cheap: lint / types / tests / schema) vs inferential (LLM reasoning: AI review / semantic diff / plan critique). The rule is simple: prefer computational; let inferential cover only the judgment layer machines cannot test; most teams overinvest in one cell and underinvest in another.

steering loop · 把"自我进化"讲成可执行动作。每次 agent 失败 → 问"哪条 guide 或 sensor 本该拦住它" → 补上或磨利那一条 → 监督需求随时间下降；skills / commands / rules 库于是成为随时间复利的项目级资产。harness 是上一节"上下文工程"的工程纪律，而非另起炉灶：后者问"此刻窗口里该有什么"，前者问"什么系统在每次运行、跨整个团队地生产并校验那份上下文"——这一句把 ENG·02 与这一节缝在一起。〔源 Martin Fowler，证据级 Ⅳ 一手从业者；经 Graziano《AI-Native Engineering》转引。[R4][R1]〕

steering loop · turning “self-evolution” into an executable move. Every time the agent fails → ask “which guide or sensor should have caught it” → add or sharpen that one → supervision demand falls over time; skills / commands / rules libraries thus become project-level assets that compound. The harness is not a fresh start but the engineering discipline of the previous section’s context engineering: that one asks “what should be in the window right now,” this one asks “what system produces and checks that context on every run, across the whole team”, the sentence that stitches ENG·02 to this section. [Source: Martin Fowler, grade Ⅳ practitioner; via Graziano’s AI-Native Engineering. [R4][R1]]

harness 是产品：guides 与 sensors 的二维分类

The harness is the product: the two-axis taxonomy of guides and sensors

"生成器 + 独立验证器 + 外部状态"给了循环的骨架，但还缺一张能让人当场盘点"我的脚手架到底有哪些、缺哪些"的分类表。Fowler 的《Harness Engineering for Coding Agents》给了这张表，它沿两条轴把围绕模型的整套脚手架干净地分成四格。第一条是时间轴：guides（前馈）在生成之前引导：规则、skills、commands、上下文装配，是你提前塞进去的"该怎么做"；sensors（反馈）在生成之后探测：测试、lint、类型检查、AI 评审，是事后告诉你"做得对不对"的。第二条是机制轴：computational（确定性、廉价）是 lint / type / test / schema 这类不用模型推理、跑一次就有确定答案的检查；inferential（推理性）是 AI 评审 / 语义 diff / 计划批判这类要调模型来判断的检查。〔源 Martin Fowler《Harness Engineering for Coding Agents》（经 Graziano Day 4 转引），证据级 Ⅳ 一手从业者，ENG·04 的直接理论源[R4][R1]〕

“Generator + independent verifier + external state” gives the loop’s skeleton but still lacks a table that lets you inventory on the spot “which scaffolding I actually have and which I lack.” Fowler’s Harness Engineering for Coding Agents gives that table, sorting the whole scaffolding around the model cleanly into four cells along two axes. First, the time axis: guides (feed-forward) steer before generation: rules, skills, commands, context assembly, the “how to do it” you put in ahead of time; sensors (feedback) detect after generation: tests, lint, type-checks, AI review, telling you afterward “whether it was done right.” Second, the mechanism axis: computational (deterministic, cheap) are checks like lint / type / test / schema that need no model inference and give a definite answer in one run; inferential are checks like AI review / semantic diff / plan critique that call a model to judge. [Source: Martin Fowler, Harness Engineering for Coding Agents (via Graziano Day 4), grade Ⅳ practitioner, the direct theoretical source for ENG·04. [R4][R1]]

这张二维表立刻给出两条可照做的纪律。第一，先用 computational，inferential 只补判断层。能用确定性、廉价的检查解决的，绝不调模型去判——类型错误用编译器抓，不要让另一个 LLM "看一眼觉得对不对"；inferential 检查只留给那些确实需要语义判断、computational 够不着的地方（比如"这个变量名是否表达了意图""这段重构有没有偷偷改了行为"）。第二，多数团队同时在一边过投、一边欠投。常见的过投是堆砌 inferential（让 AI 评审一切，慢且贵且不确定），常见的欠投是 guides 太薄（没有把"该怎么做"沉淀成可复用的 skills/commands，于是每次都从零引导）。把你现有的脚手架往这四格里填一遍，空着的格子就是你的欠投，挤爆的格子就是你的过投。这正是 INSTRUMENT 08 脚手架缺口诊断器在做的事。它把这张表做成了可勾选的自检。可证伪信号：若你无法把现有的每一项检查准确地放进这四格之一，说明你对自己的脚手架其实没有清晰的图景，那"harness 是产品"这句话对你还停在口号。

This two-axis table immediately yields two copyable disciplines. First, use computational first; let inferential only fill the judgment layer. Whatever a deterministic, cheap check can solve, never call a model to judge: catch type errors with the compiler, do not have another LLM “glance and feel whether it is right”; reserve inferential checks for what genuinely needs semantic judgment that computational cannot reach (e.g. “does this variable name express the intent,” “did this refactor quietly change behavior”). Second, most teams over-invest on one side and under-invest on the other at the same time. A common over-investment is piling on inferential (have AI review everything, slow, expensive, uncertain); a common under-investment is thin guides (no “how to do it” distilled into reusable skills/commands, so every run starts steering from zero). Fill your existing scaffolding into these four cells once: the empty cells are your under-investment, the overflowing cells your over-investment. This is exactly what INSTRUMENT 08, the Harness-Gap Diagnostic, does: it turns this table into a checkable self-test. Falsifiable signal: if you cannot place each existing check accurately into one of the four cells, you do not actually have a clear picture of your scaffolding, and “the harness is the product” is still a slogan for you.

自改进 = steering loop：每次失败补一条护栏

Self-improvement = the steering loop: each failure adds a guardrail

"会自我改进的循环"听起来抽象，但它有一个完全具体、可照做的执行形态，Fowler 把它叫 steering loop：每次 agent 失败，就问一句"哪条 guide 或 sensor 本该拦住这次失败"，然后把那一条补上或磨利。这一个动作把"自我改进"从一种模糊的愿望，变成一台明确的机器：失败是输入，对护栏的一次增补是输出，而输出会让同类失败下次被自动拦下，于是监督需求随时间单调下降。注意这台机器改进的不是模型（模型是供应商给的、你改不动），而是围绕模型的脚手架——你的 skills、commands、rules、evals 库。

这正是为什么这套库是"随时间复利的项目级资产"：它是这个项目踩过的每一个坑沉淀下来的、可复用的判断，而非一堆配置文件。它和 ENG·12 的 eval 回流是同一个循环的两种投影——eval 回流盯的是 sensor 那一侧（事后探测），steering loop 把它扩展到 guide 那一侧（事前引导）：有些失败该补一条会变红的测试（sensor），有些失败该补一条"下次该这么做"的 skill（guide）。把两侧都纳入这个循环，harness 就成了一个会随团队经验一起变强的活系统。可证伪信号：若你的 skills/rules/evals 库长期不变、或只在项目初期写过一轮就再没更新，那说明 steering loop 没有在转——失败发生了，但没有回流成护栏，于是同类失败会一直重来，监督需求也降不下去。〔源 Martin Fowler《Harness Engineering for Coding Agents》steering loop / harness 复利 + Graziano Day 4，证据级 Ⅳ 一手从业者[R4][R1]〕

“A self-improving loop” sounds abstract, but it has a fully concrete, copyable executable form Fowler calls the steering loop: each time the agent fails, ask “which guide or sensor should have caught this failure,” then add or sharpen that one. This single move turns “self-improvement” from a vague wish into a definite machine: failure is the input, an addition to a guardrail is the output, and the output makes the same class of failure auto-caught next time, so supervision demand declines monotonically over time. Note this machine improves not the model (the model is the vendor’s; you cannot change it) but the scaffolding around the model: your library of skills, commands, rules, evals.

This is exactly why that library is “a project-level asset that compounds over time”: it is not a heap of config files but the reusable judgment distilled from every pit this project has stepped in. It is the same loop as ENG·12’s eval feedback, seen on two faces: eval feedback watches the sensor side (detect after the fact), the steering loop extends it to the guide side (steer beforehand); some failures should add a test that turns red (a sensor), some should add a “next time, do it this way” skill (a guide). Bring both sides into this loop and the harness becomes a living system that strengthens with the team’s experience. Falsifiable signal: if your skills/rules/evals library is long unchanged, or written once early and never updated, the steering loop is not turning: failures happened but did not flow back into guardrails, so the same class keeps recurring and supervision demand never falls. [Source: Martin Fowler, Harness Engineering for Coding Agents steering loop / harness compounding + Graziano Day 4, grade Ⅳ practitioner. [R4][R1]]

harness 工程是上下文工程的工程纪律

Harness engineering is the engineering discipline of context engineering

最后把 ENG·02 的上下文工程和这一节的 harness 工程缝在一起，因为它们常被当成两件事，其实是一件事的两个时间尺度。一句精准的定位是：harness 工程是上下文工程的工程纪律，并非另起炉灶。后者问"此刻这个窗口里该有什么"，前者问"什么系统在每次运行、跨整个团队地生产、校验、纠正那份上下文"。上下文工程是单次的、当下的：这一次调用，我该往窗口里装配哪些事实、哪些约束、哪些示例。harness 工程是重复的、系统的：我用什么 guides 在每次生成前自动把该有的上下文装进去（而不是每次手动），用什么 sensors 在每次生成后自动校验产出、把发现的问题回流成下次该补的上下文。这正是一个好 harness 的本相：一台自动做上下文工程的机器，它把"每次都得人记得装配对的上下文"这件易错、不可规模化的事，变成了系统在每次运行里稳定执行的纪律。

这解释了为什么这两章在这一卷里相邻又互相指认：你在 ENG·02 学会"一次该装配什么"，在 ENG·04 学会"怎么让一个系统每次都替你装配对、并随团队经验越装越准"。可证伪信号：若你的团队每次让 agent 干活，仍然要靠某个人手动想起来"哦这次得告诉它那个约定、给它那几个文件"，那说明你停在了单次的上下文工程、没有把它升级成 harness——一旦那个人不在，上下文就装配错了，这正是缺乏 harness 纪律的代价。〔源 Martin Fowler《Harness Engineering for Coding Agents》+ Graziano Day 4（harness 工程是 context 工程的工程纪律），证据级 Ⅳ 一手从业者[R4][R1]〕

Finally, stitch ENG·02’s context engineering to this section’s harness engineering, because they are often taken as two things when they are two time scales of one. A precise placement: harness engineering is not a fresh start but the engineering discipline of context engineering: the latter asks “what should be in this window right now,” the former asks “what system, on every run and across the whole team, produces, verifies, and corrects that context.” Context engineering is single-shot and present-tense: for this call, which facts, constraints, examples should I assemble into the window. Harness engineering is repeated and systematic: which guides automatically assemble the right context before every generation (instead of doing it by hand each time), which sensors automatically verify the output after every generation and flow what they find back into the context to add next time. In other words, a good harness is a machine that does context engineering automatically, turning the error-prone, unscalable “someone must remember to assemble the right context every time” into a discipline the system executes stably on every run.

This explains why the two chapters sit adjacent and point at each other in this volume: in ENG·02 you learn “what to assemble once,” in ENG·04 you learn “how to make a system assemble it right every time and get better at it with the team’s experience.” Falsifiable signal: if every time your team puts the agent to work, someone still has to manually recall “oh, this time I have to tell it that convention, give it those files,” you are stuck at single-shot context engineering and haven’t upgraded it into a harness: the moment that person is away, the context gets assembled wrong, which is exactly the cost of missing harness discipline. [Source: Martin Fowler, Harness Engineering for Coding Agents + Graziano Day 4 (harness engineering as the engineering discipline of context engineering), grade Ⅳ practitioner. [R4][R1]]

这一节先把"环"这个形状的前提交代清楚。这一卷有个固定动作：拿一条流程，看它实际扛着什么——执行成本从哪来、错误又怎么一路传播——这些压力会把它压成什么形状。"滚雪球"指的是早期一个小错被后续每一步当作既定前提、沿多步放大（详见 ENG·09）。下面就用这把尺去量线性流程，看它为什么撑不住，再给出替代的环。

This section first lays out the premise behind the “loop” shape. This volume has one fixed move: take a process and look at what it actually carries, where execution cost comes from, how errors propagate, and see what shape those pressures press it into. “Snowball” means an early small error taken as a settled premise by every later step and amplified across steps (see ENG·09). Below we measure the linear flow with that ruler to see why it cannot hold, then give the loop that replaces it.

看它扛住什么 · 为何是环不是线。线性流程把"规划→实现→测试"当成一次性管道，赌的是上游判断准、下游执行慢。agentic coding 把这个赌注反过来：执行近乎免费，错误却在多步里滚雪球放大。线性管道没有把偏差挡回上游的回路，于是一处早期误解一路漂到生产。环把"学习"显式做成第六步。每次失败回流成下一轮的规格与护栏。于是流程本身会随产出复利。这就是把 ENG·04 的自我改进循环，从单个 agent 抬到整条研发流水线的尺度。

What it has to carry · why a loop, not a line. A linear flow treats “plan to build to test” as a one-shot pipeline, betting that upstream judgment is sound and downstream execution is the slow part. Agentic coding inverts the bet: execution is near-free, yet errors snowball across steps. A linear pipeline has no return path to push drift back upstream, so one early misread floats all the way to production. The loop makes “learn” an explicit sixth step (each failure flows back as next round’s spec and guardrail), so the process itself compounds with output. This lifts ENG·04’s self-improving loop from a single agent to the scale of the whole pipeline.

可拷贝环 · Specify → Plan → Execute → Verify → Integrate → Learn

Copyable loop · Specify → Plan → Execute → Verify → Integrate → Learn

JIT 规划 · 为何不一次规划到底。线性流程在最无知的时刻（项目开头）做最多的规划。环把规划改成即时（just-in-time）：只在动手前把当下这步展开到可执行，规格保持稳定，计划保持新鲜。原因是 ENG·02 的同一条约束——有效上下文窗口有限，提前规划得越细，到执行时越陈旧、越占窗口、越稀释注意力。规格先行 ≠ 计划先行：规格是耐久真源，计划是可丢弃的工作面。

JIT planning · why not plan it all up front. A linear flow does the most planning at the moment of greatest ignorance (the project’s start). The loop makes planning just-in-time: expand only the step at hand to executable detail, keep the spec stable and the plan fresh. The reason is ENG·02’s same constraint (the effective window is finite): the more you pre-plan in detail, the staler and more window-hogging and attention-diluting it is by execution time. Spec-first is not plan-first: the spec is the durable source, the plan is a disposable working surface.

规划视野为什么会坍缩。线性流程的隐含假设是"规划便宜、实现贵，所以多规划、少返工"。当实现近乎免费，这个权衡彻底翻转：返工便宜了，提前规划的细节反而成了负债。它在执行时已陈旧，还白白占着有限的有效窗口、稀释 agent 的注意力（同 ENG·02 那条约束）。于是理性的规划视野从"项目级"坍缩到"下一步级"：稳定的是 SPEC.md（耐久真源），易变的是 PLAN.md（用完即弃的工作面）。这和组织卷里"规划周期从年度坍缩到实时"是同一个机制在工程面的显形——不是因为我们变懒，是因为提前规划的边际回报随实现成本下降而塌掉了。一个可照做的判据：如果你的 PLAN.md 越写越厚、改一次代码要同步改一大片计划，说明你把本该即时展开的东西提前固化了，把环又拉直成了线。

Why the planning horizon collapses. A linear flow’s implicit assumption is “planning is cheap, implementation is dear, so plan more and rework less.” When implementation is near-free, that trade-off flips entirely: rework is cheap now, and pre-planned detail becomes a liability: stale by execution time, and wasting the finite effective window while diluting the agent’s attention (the same ENG·02 constraint). So the rational planning horizon collapses from “project-level” to “next-step-level”: stable is SPEC.md (the durable source), volatile is PLAN.md (a use-and-discard working surface). This is the same mechanism as the organization volume’s “planning cycle collapses from annual to real-time,” shown on the engineering face, not because we got lazy but because the marginal return of pre-planning collapses as implementation cost falls. A copyable test: if your PLAN.md keeps thickening and one code change forces a sync of a large swath of plan, you have pre-hardened what should have been expanded just in time, pulling the loop straight into a line again.

旧 SDLC 的去向What Happens to the Old SDLC Stages

What Happens to the Old SDLC Stages

把"实现充裕→判断退守"套在传统研发的几个阶段上，可以逐项预言它们的去向。和组织卷处理管理五职能是同一个道理：没有一个阶段"被 AI 增强"或凭空消失，每一个都被沿可验证性梯度劈成两半，可机检的一半下沉为基础设施，要由人来定的一半上浮为判断。这张表是 FIG. E3.0 那条梯度在研发流程上的逐阶投影。

Apply “execution becomes abundant, judgment retreats” to the stages of the traditional dev cycle and you can forecast each one’s fate. It works the same way as the organization volume’s treatment of the five management functions: no stage is “augmented by AI” or vanishes; each is split along the verifiability gradient, with the machine-checkable half sinking into infrastructure and the constitutive half rising as judgment. This table is FIG. E3.0’s gradient projected stage by stage onto the development process.

表的右侧两列藏着和组织卷一样的结论："研发流程"作为一串串行阶段整体让位，幸存下来的是每个阶段里那半截由人来定的判断，而非阶段本身。读这张表有一个常见的误读要避免。它不是"自动化吃掉测试与运维岗"，而是同一个人的着力点沿可验证性梯度上移：从写实现，到定何为对、划接缝、守不可逆。这正是 ENG·08 角色融合的逐阶证据。

The two right-hand columns conceal the same conclusion as the organization volume: the “dev process” as a chain of serial stages yields wholesale, and what survives is not the stages but the constitutive-judgment half inside each one. One common misreading to avoid: this is not “automation eats the testing and ops roles,” but the same person’s leverage climbing the verifiability gradient: from writing implementation to setting what is correct, drawing seams, and guarding the irreversible. This is the stage-by-stage evidence for ENG·08’s role fusion.

这一节自带前提。"信任但要核验"（trust-but-verify）的意思是：agent 的产出默认不可信，你把"生成"交给它，但自己保留一道独立的核验，不靠它自己说自己对。"可验证性梯度"则是一条从"机器能当场判对错"到"只有人能判"的连续光谱。这一节就是把这两件事落成一张能照着做的分工表（更完整的推导见 ENG·00 / ENG·03）。

This section carries its own premise. “Trust-but-verify” means: an agent’s output is untrusted by default; you hand it the “generation” but keep an independent check of your own, rather than taking its word that it is correct. The “verifiability gradient” is a continuous spectrum running from “a machine can decide correctness on the spot” to “only a human can decide.” This section lands both of those into a copyable division of labor (the fuller derivation is in ENG·00 / ENG·03).

先问能不能查 · 一道问题定档。问："这步的对错，机器能不能廉价且确定地判？"能，则 Delegate。半能（机器查得了形式、查不了意图），则 Review。不能（这类判断由人来定：何为对、风险容忍、信任边界），则 Own。这与 ENG·00 的可验证性梯度同一把尺：可机检的并入①充裕、被自动化；要由人来定的下沉④、留给人。三档不是按"重要性"分，是按可验证性分。这是最常被搞反的地方。

Ask if it’s checkable first · one question sets the tier. Ask: “can a machine judge this step’s correctness cheaply and deterministically?” Yes: Delegate. Half (the machine checks form but not intent): Review. No (constitutive judgment: what counts as correct, risk tolerance, trust boundaries): Own. This is ENG·00’s verifiability gradient as one ruler: the machine-checkable joins ① abundance and gets automated; the constitutive sinks to ④ and stays with people. The tiers split by verifiability, not by “importance.” That is the most commonly reversed point.

中间那档最难，也最值钱。Review = agent 生成、人逐 diff 评审：新业务逻辑、数据迁移、外部 API 契约、性能敏感路径。法则有两条：其一，评审 diff，不评审产物——盯改了什么，而非只看跑不跑得起来；其二，以测试为目标交办——让 agent 先写出会失败的测试、再写实现，人审"测试是否锁住了正确的意图"。Review 档随模型变强会缩小：今天要逐 diff 看的，明天可能加几条 eval 就降为 Delegate——这正是 ENG·01 杠杆点上移在评审面的样子。

The middle tier is the hardest and the most valuable. Review = agent generates, human reviews diff by diff: new business logic, data migrations, external API contracts, performance-sensitive paths. Two rules. First, review the diff, not the artifact: watch what changed, not just whether it runs. Second, delegate toward a test: have the agent write the failing test first, then the implementation, and the human reviews whether the test locks the right intent. The Review tier shrinks as models strengthen: what needs diff-by-diff review today may drop to Delegate tomorrow with a few added evals; this is ENG·01’s climbing leverage seen on the review face.

三档分工先于工具，也长于工具。这张矩阵讲的是"哪些判断由人持有"，不是"用哪个 IDE"。从业者把人要持有的判断拆成三件：定 intent（要什么、为什么）、设 constraints（架构、标准、非目标）、拥有 verification（测试、评审、质量门）。这三件正好对应组织卷里"判断退守到稀缺节点"——agent 接管执行，人持有这三件不可外包的判断。配套的三条协作守则同样可照做：先计划（从 chat 进到 plan，是 spec-driven 的第一步）、保持上下文干净（别让无关历史稀释窗口，呼应 ENG·02 的有效窗口）、知道何时叫停（agent 在原地打转时，问题往往在规格不在执行，停下来改规格而不是再试一轮）。

The three tiers precede tools and outlive them. This matrix is about “which judgments humans hold,” not “which IDE.” Practitioners split the human-held judgment into three: set intent (what, why), set constraints (architecture, standards, non-goals), and own verification (tests, review, quality gates). These three map exactly onto the organization volume’s “judgment retreats to scarce nodes”: the agent takes over execution, the human holds these three non-outsourceable judgments. The accompanying three collaboration rules are equally copyable: plan first (moving from chat to plan is spec-driven’s first step), keep context clean (do not let irrelevant history dilute the window, echoing ENG·02’s effective window), and know when to stop (when the agent spins in place the problem is usually in the spec, not execution; stop and edit the spec rather than try another round).

三档是动态的：靠补护栏把任务往左推

The tiers are dynamic: push tasks left by adding guardrails

Delegate / Review / Own 这三档最容易被误用成一张静态的"任务清单"——把任务一次性固定在某一档，然后照着分工。但三档的价值在于它会动：一个今天必须 Review（人逐 diff 看）的任务，一旦你为它补上了能自动判对错的护栏（一条 eval、一个类型约束、一个独立 checker），它就可以左移到 Delegate（放手让 agent 全自动跑）。所以这张矩阵不是用来"安排谁做什么"的，是用来追踪你的护栏在往哪长的：健康的团队里，任务会季度性地从 Review 往 Delegate 迁移，因为护栏在变厚；而 Own 那一档（这类判断由人来定：何为对、风险边界、架构取舍）几乎不动，因为它本就不可机检、不该下放。把这件事和 ENG·03 的可验证性梯度对上，就是同一把尺：一个任务能否左移，取决于"它的对错能否被廉价且确定地机检"——能，就左移；不能，就留在右边给人。〔源 Graziano《AI-Native Engineering》Day 1 Delegate/Review/Own 矩阵，证据级 Ⅳ 一手从业者[R1]〕

Delegate / Review / Own is most easily misused as a static “task list”: pinning each task to a tier once and dividing labor accordingly. But the tiers’ real value is that they move: a task that today must be Reviewed (a human reading every diff) can, once you add a guardrail that auto-decides correctness (an eval, a type constraint, an independent checker), shift left to Delegate (handed fully to the agent). So this matrix is not for “assigning who does what” but for tracking where your guardrails are growing: in a healthy team tasks migrate quarter by quarter from Review toward Delegate because the guardrails are thickening; while the Own tier (constitutive judgment: what is right, risk boundaries, architectural trade-offs) barely moves, because it is not machine-checkable and should not be delegated. Mapped onto ENG·03’s verifiability gradient, it is the same ruler: whether a task can shift left depends on “can its correctness be machine-checked cheaply and deterministically”: if yes, shift left; if no, keep it on the right for people. [Source: Graziano, AI-Native Engineering Day 1 Delegate/Review/Own matrix, grade Ⅳ practitioner. [R1]]

Own 那一档为什么永远不空

Why the Own tier is never empty

三档里 Delegate 在变大、Review 在收缩，一个自然的疑问是：随着护栏越补越厚，Own 那一档会不会也终将被清空、人最终无事可做？不会，原因是结构性的，不是"现在还做不到"的暂时性。Own 那一档装的是由人来定的判断——决定何为对、定义风险容忍、划信任边界、做架构取舍。这些之所以留在 Own，是因为它们没有一个独立于人的判据可供机检，而非因为机器暂时不够强。"这个产品该不该有这个功能""这个性能和复杂度的取舍我们能不能接受""这个对外契约一旦定了就要长期负责，我们认不认"——这些问题的"对"是一个由人的价值、处境、责任共同定义的判断，而非一个客观事实。你可以用 eval 把"符不符合已定的标准"机检掉，但"标准本身该是什么"这件事，定义它的动作本身就只能由人来做。一旦让机器来定标准，你只是把判断换了个地方藏起来，没有消除它。

这正是内核第④步在工程面的落点：充裕和护栏清空的是可机检的那半，留下的恰好是要由人来定的那半，而后者是人回到工程师本职的地方。可证伪信号：若有人声称把 Own 那一档也自动化了，去看他到底自动化的是什么——大概率是把"按已定标准判合不合格"自动化了（那本就该自动化），而"标准该是什么"这个 Own 判断，要么还藏在某个人手里，要么被悄悄默认成了模型训练分布里的某个值（那是把判断让渡给了一个没人为之负责的来源）。

With Delegate growing and Review shrinking, a natural question: as guardrails thicken, will the Own tier eventually be emptied too, leaving humans nothing to do? The answer is no, and the reason is structural, not a temporary “we cannot do it yet.” The Own tier holds constitutive judgments: deciding what is correct, defining risk tolerance, drawing trust boundaries, making architectural trade-offs, and these stay in Own not because machines are momentarily too weak but because they have no criterion independent of humans to machine-check against. “Should this product have this feature,” “can we accept this performance-versus-complexity trade-off,” “this external contract, once set, carries long-term responsibility, do we own it”: the “correct” of these questions is not an objective fact but a judgment defined jointly by human values, situation, and responsibility. You can machine-check “does it conform to the set standard” with an eval, but “what the standard itself should be” is the act of defining it, and that can only be done by people; let a machine set the standard and you have merely hidden the judgment elsewhere, not eliminated it.

This is the kernel’s step ④ landing on the engineering face: abundance and guardrails clear the machine-checkable half and leave precisely the constitutive half, which is where people return to the engineer’s true work. Falsifiable signal: if someone claims to have automated the Own tier too, look at what they actually automated. Most likely “judging pass/fail against a set standard” (which should be automated). The real Own judgment of “what the standard should be” is either still in someone’s hands or quietly defaulted to some value in the model’s training distribution (which is ceding the judgment to a source no one is responsible for).

投入要跟得上验证 · 为何要分阶。把"写规格"讲成一刀切，会逼团队在还没有验证基建时硬上 Spec-as-Source，结果规格沦为没人维护的死文档。阶梯让投入与回报匹配：每升一阶，规格从"一次性意图说明"变成"可回归的承重工件"，而升阶的前提是下一阶的可机检条件已就位。这与 ENG·03 缝合——可机检是纵轴（深度），成熟度是横轴（耐久度）；一条规格只有同时可机检又活着，才真正成为生成循环的目标函数。

Investment must match verification · why rungs. Treating “write a spec” as all-or-nothing forces teams onto Spec-as-Source before the verification infrastructure exists, and the spec rots into a document no one maintains. The ladder matches investment to payoff: each rung turns the spec from a one-shot intent brief into a regressible load-bearing artifact, and climbing a rung presupposes that the next rung’s machine-checkable conditions are in place. This stitches to ENG·03: machine-checkability is the vertical axis (depth), maturity is the horizontal axis (durability); a spec becomes the generation loop’s objective function only when it is both checkable and alive.

可拷贝判据 · 你在第几阶。问三句：(1) 改一个行为，你是先改代码还是先改规格？先代码 = 阶 Ⅰ。(2) 规格和代码不一致时，CI 会红吗？不会 = 还没到阶 Ⅱ。(3) 规格里有没有一层"硬规则"（如 constitution.md）是 agent 不许违反、且被强制层挡住的？没有 = 还没摸到阶 Ⅲ 的门。多数团队真实位置在阶 Ⅰ 到 Ⅱ 之间，且常误以为自己在阶 Ⅲ——这正是规格沦为合规摆设的根因。

Copyable test · which rung you are on. Ask three things. (1) To change a behavior, do you edit code first or the spec first? Code first = rung Ⅰ. (2) When spec and code disagree, does CI go red? No = not yet rung Ⅱ. (3) Is there a “hard-rule” layer (like a constitution.md) the agent may not violate and that an enforcement layer blocks? No = not yet at rung Ⅲ’s door. Most teams sit between rungs Ⅰ and Ⅱ and often believe they are at rung Ⅲ (exactly why specs become compliance theater).

为什么大多数团队卡在阶 Ⅰ 到 Ⅱ 之间。升到阶 Ⅱ（规格锚定）需要一个常被低估的基建：一个能在"规格与代码不一致"时让 CI 变红的检查器。没有它，规格和代码会无声分叉——人改了代码忘了改规格，或反过来——而没有任何信号提醒。这正是 ENG·03 的"可机检"在阶梯上的作用：可机检是让规格活着的前提，因为只有可机检的规格才能被 CI 持续比对。所以这条阶梯和 ENG·03 是正交两轴：纵轴是"规格有多可机检"（深度），横轴是"规格活得多久"（耐久度）。一条规格只有同时在两轴上都够高，才真正成为生成循环的目标函数——可机检但没人维护的规格会腐烂，活着但不可机检的规格只是一篇没有约束力的作文。

Why most teams stall between rungs Ⅰ and Ⅱ. Climbing to rung Ⅱ (Spec-Anchored) needs an often-underestimated piece of infrastructure: a checker that turns CI red when “spec and code disagree.” Without it, spec and code fork silently (someone edits the code and forgets the spec, or vice versa) with no signal to flag it. This is exactly where ENG·03’s “machine-checkable” does its work on the ladder: machine-checkability is the precondition for the spec to stay alive, because only a machine-checkable spec can be continuously diffed by CI. So this ladder and ENG·03 are two orthogonal axes: the vertical is “how machine-checkable the spec is” (depth), the horizontal is “how long the spec stays alive” (durability). A spec becomes the generation loop’s objective function only when it is high on both: a machine-checkable spec no one maintains rots, and a living but un-checkable spec is just a non-binding essay.

阶 Ⅲ 的那道硬规则层，是把"何为对"从建议升格为强制。Spec-as-Source 的标志是规格里存在一层 agent 不许违反、且被一个强制层挡住的硬规则（如一份 constitution.md），而非"有规格"。区别在执行力：阶 Ⅰ/Ⅱ 的规格是"应该这样"，agent 可以违反、人事后发现；阶 Ⅲ 的硬规则是"不能这样"，违反在生成或合并时就被自动拦下。这把 ENG·03 的"机器可检验"推到极致——不只检验产出对不对，还检验过程有没有越过不可逾越的红线。也正因门槛最高、回报最大，它最容易被误判：很多团队以为自己在阶 Ⅲ，其实只是有一堆没人强制的规范文档，那仍是阶 Ⅰ。

Rung Ⅲ’s hard-rule layer promotes “what is correct” from suggestion to enforcement. The mark of Spec-as-Source is not “having a spec” but a layer of hard rules the agent may not violate, blocked by an enforcement layer (such as a constitution.md). The difference is teeth: rung Ⅰ/Ⅱ specs say “it should be this way,” and the agent can violate them with humans noticing later; rung Ⅲ hard rules say “it cannot be this way,” and a violation is intercepted automatically at generation or merge. This pushes ENG·03’s machine-checkability to its limit: checking not only whether the output is correct but whether the process crossed an inviolable red line. And precisely because the bar is highest and the payoff largest, it is the most commonly misjudged: many teams believe they are at rung Ⅲ when they merely have a pile of unenforced convention docs, which is still rung Ⅰ.

让规格像代码一样被评审：constitution 作硬规则层

Review the spec like code: a constitution as the hard-rule layer

规格要爬到 Spec-as-Source 那一档，光靠"先写规格"的纪律不够——纪律会松。真正让规格活下去的，是把它放进和代码同一套可评审、可 diff、可强制的机制里。一个具体可照做的做法来自 Spec-kit：规格文件与代码同住一个仓库，每次改规格走 PR、像评审代码一样评审规格的改动；再立一份 constitution.md 作为硬规则强制层——把那些"无论如何不能违反"的约束（安全红线、架构不变量、对外契约）写进去，由流水线在每次生成/提交时强制校验，agent 和人都不能绕过。

这一层的妙处在于它把规格的两种性质分开了：大部分规格是"该怎么做"的可演进描述，走 PR 评审即可；少数是"绝不能怎样"的不变量，需要被当作硬约束机器强制。这恰好把 ENG·03 的"可机检"和这一节的"地位"缝在一起：constitution 既是可机检的（机器能验违没违），又是地位最高的（它是规格里不可协商的那部分）。可证伪信号：若你的团队"有规格"但没有任何一条规格是被流水线硬性强制的、全靠人自觉遵守，那这套规格大概率会沿"纪律松弛"那条路慢慢退回 Spec-First 甚至更低。〔源 Graziano《AI-Native Engineering》Day 5–6 Spec-kit（PR 即评审门、constitution.md 硬规则层），证据级 Ⅳ 一手从业者[R5][R1]〕

For a spec to climb to the Spec-as-Source rung, the discipline of “write the spec first” is not enough: discipline slackens. What truly keeps a spec alive is placing it in the same reviewable, diffable, enforceable mechanism as code. One concrete copyable practice comes from Spec-kit: spec files live in the same repo as code, every spec change goes through a PR, and a spec change is reviewed like code; then a constitution.md serves as a hard-rule enforcement layer. Write the “must not be violated under any circumstances” constraints (security red lines, architectural invariants, external contracts) into it, enforced by the pipeline on every generation/commit, bypassable by neither agent nor human.

The elegance of this layer is that it separates two natures of a spec: most of the spec is an evolvable description of “how to do it,” which a PR review suffices for; a few are “must never” invariants that must be machine-enforced as hard constraints. This stitches ENG·03’s “machine-checkable” to this section’s “standing”: a constitution is both machine-checkable (a machine verifies violation) and of the highest standing (the non-negotiable part of the spec). Falsifiable signal: if your team “has specs” but not a single spec rule is hard-enforced by the pipeline, all relying on voluntary compliance, that spec set will most likely slide back along the “discipline slackens” path to Spec-First or below. [Source: Graziano, AI-Native Engineering Day 5–6 Spec-kit (PR as review gate, constitution.md as hard-rule layer), grade Ⅳ practitioner. [R5][R1]]

规格不是开关，是阶梯：怎么判断该爬到哪一档

A spec is not a switch but a ladder: judging which rung to climb to

把成熟度阶梯当成"越高越好、所有项目都该冲到 Spec-as-Source"是一个常见的误用。它会让团队为低风险、快迭代的探索性代码也强行套上重规格，把本该轻快的事拖慢。阶梯的正确读法是：不同的代码，该停在不同的档，由这段代码的"改一次的代价"和"错一次的代价"共同决定。

一段探索性的、随时可能整段扔掉的原型，停在 Spec-First 甚至更轻就够了——为它写重规格是浪费，因为它的寿命短、错了也便宜。而一段对外契约、一段被许多下游依赖的核心模块、一段安全敏感的代码，则值得爬到 Spec-Anchored 乃至 Spec-as-Source——因为它改一次牵动很广、错一次代价很高，把"何为对"固定在一份权威规格里的收益，远超维护规格的成本。这条判据和 ENG·08 的边界、INSTRUMENT 07 的爆炸半径是同一把尺：越靠近系统接缝、爆炸半径越大的代码，越值得往阶梯上爬。所以"规格成熟度"是一张随代码重要性变化的地图，并非一个团队级的统一档位。可证伪信号：若你的团队要么所有代码都没规格（全在阶 0）、要么所有代码都套重规格流程（不分轻重一刀切），那都是没在按代价分档。前者会在核心模块上栽跟头，后者会被自己强加的规格负担拖慢探索。〔源 Graziano《AI-Native Engineering》Day 5–6 SDD"规格不是开关而是阶梯"，证据级 Ⅳ 一手从业者[R1]〕

Treating the maturity ladder as “higher is always better, every project should push to Spec-as-Source” is a common misuse: it makes teams force heavy specs onto low-risk, fast-iterating exploratory code, dragging down what should be light and quick. The ladder’s correct reading is: different code should stop on different rungs, decided jointly by that code’s “cost to change once” and “cost to get wrong once.”

An exploratory prototype that may be thrown away wholesale at any time stops at Spec-First or lighter: writing a heavy spec for it is waste, because it is short-lived and cheap to get wrong. But an external contract, a core module many downstreams depend on, a piece of security-sensitive code is worth climbing to Spec-Anchored or even Spec-as-Source. Because changing it once moves a lot and getting it wrong once is costly, and the payoff of nailing “what is correct” into an authoritative spec far exceeds the cost of maintaining it. This criterion is the same ruler as ENG·08’s boundaries and INSTRUMENT 07’s blast radius: the closer to a system seam and the larger the blast radius, the more the code is worth climbing the ladder for. So “spec maturity” is not a single team-wide rung but a map that varies with code importance. Falsifiable signal: if your team either has no spec for any code (all on rung 0) or forces the heavy spec process onto all code (one-size-fits-all regardless of stakes), neither is tiering by cost. The former trips on core modules, the latter is dragged down on exploration by a self-imposed spec burden. [Source: Graziano, AI-Native Engineering Day 5–6 SDD “a spec is not a switch but a ladder,” grade Ⅳ practitioner. [R1]]

把规格成熟度与可机检形式合起来看，会得到这一卷一个简洁的判据：一份好规格，既要在形式上尽量靠近可机检（ENG·03 的光谱左端），又要在地位上爬到与代码风险相称的那一档（这一节的阶梯）。两者都达标的规格，才能真正给生成循环当目标函数——形式让机器能验，地位让团队会改。缺任何一个，规格都会退化：只有形式没有地位的规格被写完就丢，只有地位没有形式的规格全靠人读人审、机器使不上力。这就是为什么"写了规格"不是终点，"规格活着且可机检"才是。

Take spec maturity and machine-checkable form together and you get a compact criterion for this volume: a good spec must in form sit as far left toward machine-checkable as possible (the left end of ENG·03’s spectrum) and in standing climb to the rung commensurate with the code’s risk (this section’s ladder). Only a spec that meets both can truly serve as the generation loop’s objective function: form lets the machine verify, standing makes the team edit. Missing either and the spec degrades: form without standing is written then dropped; standing without form leans on people to read and review, with the machine unable to help. This is why “wrote a spec” is not the finish line; “the spec is alive and machine-checkable” is.

压力聚在接缝上 · 边界为何是判断节点。一个决策值不值得人来做，看两件事：可逆性（错了能不能便宜地退回）和爆炸半径（错了会波及多大）。模块边界恰好同时决定这两者——接缝划错，错误会跨边界蔓延、且难以回退。所以架构边界天然是高爆炸半径、低可逆性的承重决策，正是该把判断花在的地方；边界里面的实现则低半径、高可逆，可放心交给 agent。这与 ENG·07 的分档同一把尺，只是作用在结构面：边界即 Own，模块内即 Delegate。但要摊开一注：这把尺量的是任务——可逆性和半径是活儿本身的属性，和谁来干无关。另一派做法把权限挂在 agent 的履历上，攒够一段无差错的记录就自动放宽它的自主权，两种做法都在真实系统里跑。我们目前偏向按任务定权，因为再漂亮的履历也压不住一次高半径不可逆动作的尾部代价——退款发错一次是真金白银，不因为这个 agent 以前稳就变小。改判的条件很具体：哪天有人能证明履历真的收窄了高半径动作的失败分布，而不只是拉高了平均表现，“按履历授权”就该在可逆、低半径那一档拿回地盘；但那条不可逆的尾，大概率仍要按任务、留给人这道闸。

The pressure sits at the seam · why a boundary is a judgment node. Whether a decision deserves a human turns on two things: reversibility (can a mistake be cheaply undone) and blast radius (how far a mistake spreads). A module boundary happens to set both at once: draw the seam wrong and errors spread across it and resist rollback. So an architecture boundary is inherently a high-blast-radius, low-reversibility load-bearing decision, exactly where judgment should go; the implementation inside the boundary is low-radius, high-reversibility and can be safely handed to the agent. Same ruler as ENG·07’s tiers, on the structural face: the boundary is Own, inside the module is Delegate. One bet worth laying open: this ruler measures the task, since reversibility and radius are properties of the work itself, independent of which agent does it. Another school hangs permission on the agent’s track record instead, widening its autonomy automatically once it has built a clean-enough history, and both approaches run in real systems. We currently lean toward scoping permission by task, because no track record, however clean, shrinks the tail cost of one high-radius irreversible action: a refund fired wrong once is real money, and does not get smaller because this agent used to be steady. The condition that would change our mind is concrete: the day someone shows a track record genuinely narrows the failure distribution of high-radius actions, not merely lifts the average, “authorize by record” should win back ground in the reversible, low-radius tier: but that irreversible tail most likely still goes by task, kept at the human gate.

走一条具体的接缝（一个假想的例子）。把支付从订单里切出来，这道缝该划在哪？划在“退款授权”上——退款一旦发错，钱已经出账，很难便宜地退回来，波及的是真金白银。设想一个 agent 图省事，以“反正都要读订单数据”为由，把退款逻辑塞回订单模块：这一步就跨过了那道缝，一次判断失误不再困在模块内部，而是顺着订单流程蔓延到扣款。接缝之所以留给人，正因为“该划在退款授权、而不是订单状态上”这个判断要权衡的是钱、合规与回退成本，不是代码好不好写——机器替你做不了。

Walk one concrete seam (a hypothetical). Split payment out of orders: where does this seam go? On “refund authorization”: once a refund fires wrong the money has already left the account and cannot be cheaply clawed back, and what it touches is real money. Imagine an agent taking the lazy path (“it all reads order data anyway”) and folding the refund logic back into the order module: that one step crosses the seam, and a single lapse of judgment is no longer trapped inside a module but spreads along the order flow into charging. The seam stays with a human precisely because the judgment “draw it on refund authorization, not on order status” weighs money, compliance, and rollback cost, not whether the code is easy to write, a thing the machine cannot do for you.

角色融合 · 实现者 → 编排者 → 调度者。把以上连起来：当模块内的实现可交办，工程师的着力点上移到设计边界、写规格、搭 harness、设计循环、最后调度一支并行的 agent 队伍。这正是 ENG·01 那栋楼的电梯——prompt → context → spec → harness → loop → fleet，杠杆点逐层上移。融合不是"职级合并"，是同一个人持有的判断层次在上移：他越来越少地写每行代码，越来越多地决定接缝放哪、何为对、谁能碰什么。这是内核第④步在工程面的落点——人回归于只有人能定的判断与品味。

Role fusion · implementer → orchestrator → scheduler. Connect the above: once in-module implementation is delegable, the engineer’s leverage climbs to designing boundaries, writing specs, building the harness, designing the loop, and finally scheduling a parallel fleet of agents. This is ENG·01’s elevator (prompt → context → spec → harness → loop → fleet), leverage climbing floor by floor. Fusion is not a “merger of titles” but the level of judgment one person holds moving upward: writing each line less and less, deciding where the seams go, what counts as correct, and who may touch what more and more. This is the kernel’s step ④ on the engineering face: people return to the judgment and taste only people can set.

为什么实现充裕反而让架构更稀缺、不是更不重要。有一种危险的误读："既然 agent 能生成任何实现，架构不就无所谓了？"恰恰相反。实现便宜时，把系统拖垮的是"写得太多太快、却没有结构约束"，而非"写不出来"——生成会以惊人的速度堆出技术债，模块边界一旦划错，错误就跨边界蔓延、且难以回退。所以架构边界是那个不让生成坍缩成一团泥的稀缺结构：它便宜不下来，因为它本质是由人来定的判断，不是可机检的对错。这解释了一个表面的悖论——agent 越强，划接缝、定依赖方向、做范围纪律（决定不造什么）这些工作的相对价值越高，而不是越低。

Why abundant implementation makes architecture scarcer, not less important. A dangerous misreading: “since the agent can generate any implementation, doesn’t architecture stop mattering?” The opposite. When implementation is cheap, what drags a system down is no longer “can’t write it” but “writes too much too fast with no structural constraint”. Generation piles up technical debt at startling speed, and once a module boundary is drawn wrong, errors spread across it and resist rollback. So the architecture boundary is the scarce structure that keeps generation from collapsing into mud: it cannot get cheap, because it is constitutive judgment, not machine-checkable correctness. This resolves an apparent paradox: the stronger the agent, the higher the relative value of drawing seams, setting dependency direction, and exercising scope discipline (deciding what not to build), not the lower.

角色融合是"人持有的判断变高了"，不是"人变少了"。把 ENG·01 的楼层、ENG·06 的三档、ENG·08 的边界放在一起看，会浮现同一个动作：同一个工程师，着力点从"写每一行"上移到"决定每一处接缝"。这是同一个人身上判断层次的迁移，而非裁掉实现者、保留架构师的人事故事——他还在做工程，只是工程的重心从可机检的那一半（实现）移到了由人来定的那一半（边界、契约、何为对、谁能碰什么）。本系列把这称作内核第④步在工程面的落点：人不做吞吐，回到只有人能做的判断与建造。它也给了一个可证伪的组织预测。如果一个团队"AI 化"之后，工程师的时间分配没有从写实现明显移向划边界、定契约、补护栏，那它多半只是把 AI 嫁接到了旧流程上，并没有真正重画研发图。

Role fusion is not “fewer people” but “the judgment people hold rises.” Put ENG·01’s floors, ENG·06’s tiers, and ENG·08’s boundary side by side and one move surfaces: the same engineer, leverage climbing from “writing every line” to “deciding every seam.” This is not a headcount story of cutting implementers and keeping architects, but a migration of the level of judgment within the same person: still doing engineering, only with engineering’s center of gravity moved from the machine-checkable half (implementation) to the constitutive half (boundaries, contracts, what is correct, who may touch what). This series calls it the kernel’s step ④ on the engineering face: people do not do throughput; they return to the judgment and building only people can do. It also yields a falsifiable organizational prediction: if, after a team “goes AI,” engineers’ time has not visibly shifted from writing implementation toward drawing boundaries, setting contracts, and adding guardrails, the team has most likely only grafted AI onto the old process and not redrawn the development graph at all.

边界即判断节点：哪些角色融合，哪些反而分化

Boundaries as judgment nodes: which roles fuse, which split apart

"角色融合"容易被听成"所有人都变成全栈、边界消失"，那是误读。准确的图景是：实现层面的分工在融合，判断层面的分工反而在分化、并被抬高。过去前端/后端/测试/运维的分工，很大一部分是按"谁来写哪段实现"切的；当实现被 agent 吸收，按实现切的那些边界确实在塌——同一个人借助 agent 可以跨栈交付。

但与此同时，一组新的、按"谁来持有哪个判断"切的边界在浮现并变得更重要：谁来定这个对外契约、谁来判这次架构取舍、谁来设这道安全边界、谁来守"何为对"的标准。这些是判断节点，不是实现工种，而且它们恰好落在系统的接缝处：模块之间、服务之间、信任域之间。这就是为什么这一卷反复说"架构边界即判断节点"：当实现充裕，架构（也就是边界怎么划）成了不让生成坍缩成技术债的那个稀缺结构，而划边界这件事本身不可机检、是由人来定的判断，所以它下沉到④留给人。可证伪推论：一个团队"AI 化"之后，若你观察到的是"实现工种合并、但出现了更清晰的边界/契约/安全的判断归属"，那是真融合；若你观察到的是"实现工种合并、且没人明确为边界负责"，那是承重决策悬空，不是融合——表面少了几个工种，实际多了一处无人持有的风险。深潜见架构篇。

“Role fusion” is easily heard as “everyone becomes full-stack and boundaries disappear,” which is a misreading. The accurate picture is: division of labor at the implementation level fuses, while division at the judgment level instead splits apart and is lifted higher. The old frontend/backend/test/ops split was largely cut along “who writes which implementation”; once implementation is absorbed by agents, the boundaries cut along implementation do collapse: one person, with an agent, delivers across the stack.

But at the same time a new set of boundaries, cut along “who holds which judgment,” emerges and grows more important: who sets this external contract, who judges this architectural trade-off, who designs this security boundary, who guards the standard of “what is correct.” These are not implementation trades but judgment nodes, and they fall precisely at the seams of the system: between modules, between services, between trust domains. This is why the volume keeps saying “architectural boundaries are judgment nodes”: when implementation is abundant, architecture (how boundaries are drawn) becomes the scarce structure that keeps generation from collapsing into tech debt, and drawing boundaries is itself not machine-checkable but a constitutive judgment, so it sinks to ④ and stays with people. Falsifiable corollary: after a team “goes AI,” if what you observe is “implementation trades merge, but a clearer ownership of boundary/contract/security judgments appears,” that is real fusion; if what you observe is “implementation trades merge, and no one clearly owns the boundaries,” that is not fusion but load-bearing decisions left dangling: a few fewer trades on the surface, one more unheld risk underneath. Deep dive in the Architecture chapter.

把验证当成"勤快一点的好习惯"是这一卷最容易犯的错。验证之所以是承重墙，不在模型偶尔会错，而在这类错有确定的结构成因——它们从生成式系统的工作原理里直接长出来，跟模型聪明不聪明无关。下面四种是 Graziano 在《AI-Native Engineering》Day 2 列出的核心失败模式；这里给每一种补上"架构为什么必然产出它"和"harness 用哪条护栏阻尼它"两层。〔源 Graziano《AI-Native Engineering》Day 2 失败模式，证据级 Ⅳ 一手从业者[R1]〕

Treating verification as “a diligent good habit” is the easiest mistake in this volume. Verification is a load-bearing wall not because the model occasionally errs but because this class of error has a definite structural cause: it grows directly out of how a generative system works, independent of how smart the model is. The four below are the core failure modes Graziano lists in AI-Native Engineering Day 2; here each gets two layers added: “why the architecture necessarily produces it” and “which harness guardrail damps it.” [Source: Graziano, AI-Native Engineering Day 2 failure modes, grade Ⅳ practitioner. [R1]]

为什么是这套架构的产物，而非模型的缺陷

Why a product of the architecture, not a defect of the model

一个自回归语言模型在每一步只做一件事：在给定上文的条件下，对下一个 token 取概率最高的延续。它没有一个独立的"我确定吗"的内部状态，也没有一个把输出对照外部真值的环节——除非你在它外面搭一个。于是"流畅"和"正确"在它内部是同一个量：读起来对的，和实际上对的，用的是同一套打分。这一句就解释了下面四种里的前两种：幻觉是模型在没有证据时仍按"最像真话"的方式补全，自信而错是这种补全恰好戴着确信的语气。它们并非 bug，而是"按概率续写"这件事在缺乏外部锚点时的默认行为。后两种则来自把这个单步行为放进多步循环：误差会沿步骤累积（雪球），上下文会随长度退化（上下文腐化）。所以四种失败可以两两归类：前两种是单步的认识论缺陷，后两种是多步的动力学缺陷。

An autoregressive language model does one thing at each step: under the given context, take the highest-probability continuation for the next token. It has no independent internal state of “am I sure,” and no stage that checks output against external truth, unless you build one outside it. So “fluent” and “correct” are the same quantity inside it: what reads right and what is right share one scoring function. That single fact explains the first two below: hallucination is the model completing in the “most truth-like” way even with no evidence, and confident wrongness is that completion happening to wear an assured tone. They are not bugs but the default behavior of “continue by probability” when external anchors are absent. The latter two come from placing this single-step behavior inside a multi-step loop: error accumulates across steps (the snowball), and context degrades with length (context rot). So the four sort into two pairs: the first two are single-step epistemic defects, the latter two are multi-step dynamical defects.

雪球：四种里最该单独盯的一种

The snowball: the one to watch most

雪球之所以单列，是因为它把前三种的危害乘起来。一次幻觉若发生在一段三十步推演的第二步，且戴着确信的语气、又没有检查点，那么后面二十八步全都建在这个错前提上——agent 会一本正经地为一个不存在的函数写测试、为一个错的边界条件设计回退、在一份已经偏离事实的计划上继续追加细节。它读起来始终自洽，因为每一步都忠实地从上一步推下来；坏就坏在上一步本身是错的。这正是为什么"每个有意义的步骤都要有人在环检查点"不是谨慎，是结构必需：检查点的唯一作用，是在雪球还小的时候把它截断。把这件事画出来就是 FIG E9.0——同一条曲线，有检查点的那条在每个节点被拉回基线，无检查点的那条指数离散。可证伪信号：若你的 agent 在长任务上"前半段都对、后半段忽然集体崩"，几乎一定是某个早期步骤错了而无人拦，而非模型在后半段变笨。

The snowball is listed alone because it multiplies the harm of the first three. If a hallucination lands on step two of a thirty-step derivation, wears a confident tone, and faces no checkpoint, the remaining twenty-eight steps all build on that false premise. The agent will earnestly write tests for a function that does not exist, design a fallback for a wrong edge condition, keep adding detail to a plan that has already gone off the rails. It always reads self-consistent, because each step follows faithfully from the last; the rot is that the last step was itself wrong. This is exactly why “a human-in-the-loop checkpoint at every meaningful step” is not caution but a structural necessity: a checkpoint’s sole job is to cut the snowball while it is still small. Drawn out, this is FIG E9.0: one curve pulled back to baseline at each node by checkpoints, the other diverging exponentially without them. Falsifiable signal: if your agent is “right in the first half, then suddenly collapses wholesale in the second” on long tasks, it is almost certainly an early step that was wrong and uncaught, not the model getting dumber later.

隐藏假设：第五种，最难被测试抓到的一种

Hidden assumptions: the fifth, the hardest for tests to catch

前四种之外还有一种值得单列，因为它绕过了大多数护栏：隐藏假设（hidden assumptions）。agent 在生成时会无声地填上一堆它没问、你也没说的前提。这个 API 的分页是从 0 还是 1 开始、这个金额是分还是元、这个时区是 UTC 还是本地、这个"用户"指的是登录用户还是被操作的用户。这些假设单看每一个都"合理"，代码也能跑、测试也能过，因为测试本身往往建立在同一个隐藏假设上。它的危险恰恰在于它不报错：它是一个静默的、要到生产环境里遇到边界情况才暴露的语义错位，而非一个会变红的失败。

为什么这套架构必然产出它？因为模型的工作是补全最可能的延续，而"最可能"是按训练分布算的、不是按你这个系统的真实约定算的——当你的约定偏离常见分布（比如你这个遗留系统金额用分），它就会自信地按常见分布填错。阻尼它的护栏不在 computational 那一侧（测试抓不到自己假设里的错），而在 guides 那一侧：把这些约定显式写进上下文和规格，不让 agent 去猜。这也是 ENG·02"上下文即基设"和这一节的接口——隐藏假设是上下文缺失在失败学里的投影。可证伪信号：若你的事故复盘里反复出现"它以为是 X，其实我们这儿是 Y"，那不是模型不小心，是你的约定没有进上下文，agent 只能按训练分布猜。〔源 Graziano《AI-Native Engineering》Day 2 失败模式（hidden assumptions），证据级 Ⅳ 一手从业者[R1]〕

Beyond the first four, one more deserves its own listing because it bypasses most guardrails: hidden assumptions. While generating, the agent silently fills in a pile of premises it did not ask and you did not state: whether this API’s pagination starts at 0 or 1, or whether this amount is in cents or units. It also guesses whether this timestamp is UTC or local, and whether “user” means the logged-in user or the one being acted upon. Each assumption looks “reasonable” alone, the code runs, the tests pass, because the tests are often built on the same hidden assumption. Its danger is precisely that it does not error: it is not a failure that turns red but a silent semantic mismatch that surfaces only on an edge case in production.

Why does this architecture necessarily produce it? Because the model’s job is to complete the most probable continuation, and “most probable” is computed over the training distribution, not over your system’s actual conventions. When your convention departs from the common distribution (say, this legacy system holds amounts in cents), it confidently fills in the common-distribution wrong. The guardrail that damps it is not on the computational side (a test cannot catch an error inside its own assumption) but on the guides side: write these conventions explicitly into context and spec and do not let the agent guess. This is the interface between ENG·02 “context as infrastructure” and this section: a hidden assumption is the projection of missing context onto failure taxonomy. Falsifiable signal: if your incident retrospectives repeatedly read “it thought it was X, but here it is Y,” the model was not careless; your convention never entered context and the agent could only guess from the training distribution. [Source: Graziano, AI-Native Engineering Day 2 failure modes (hidden assumptions), grade Ⅳ practitioner. [R1]]

把失败学倒过来用：它是设计护栏的需求清单

Read the taxonomy in reverse: it is the requirements list for guardrails

这张失败学不只是"知道会出哪些错"的清单，倒过来读，它是设计 harness 的需求规格——每一种失败模式，都对应一条本该存在的护栏，而你的脚手架里那条护栏在不在、强不强，决定了这种失败会不会反复发生。这就把"我的 harness 该补什么"从凭感觉，变成了一道可以逐条对照的检查：你有没有 grounding/检索来治幻觉？有没有独立于生成的 checker 来治自信而错？有没有在每个有意义步骤设检查点来治雪球？有没有上下文卫生（文件作真源、定期压缩）来治腐化？有没有把关键约定显式写进上下文来治隐藏假设？哪一条答"没有"，哪一种失败就会在你的系统里反复出现——而且它会以那种"看起来是模型偶尔抽风"的方式出现，让你误以为是运气问题，从而一直不去补那条结构性缺口。

这正是把 ENG·04 的 guides/sensors 分类法和这张失败学缝起来的地方：分类法告诉你护栏有哪几种形状，失败学告诉你每种护栏对应防住哪种失败。两张表合起来，"我的脚手架够不够"就有了一个不依赖直觉的答案。可证伪信号：把你最近十次 agent 事故逐一归到这五种失败模式，若发现它们高度集中在某一两种上，那是你的 harness 在那一两种对应的护栏上系统性地欠投，并非巧合——补那一条，比泛泛地"让人更小心"有效得多。

This taxonomy is not only a list of “which errors will occur”; read in reverse, it is the requirements spec for designing the harness: each failure mode corresponds to a guardrail that ought to exist, and whether that guardrail is present and strong in your scaffolding decides whether the failure recurs. This turns “what should my harness add” from a gut feeling into a check you can run line by line: do you have grounding/retrieval for hallucination? An independent-of-generation checker for confident wrongness? A checkpoint at each meaningful step for the snowball? Context hygiene (files as source, periodic compaction) for rot? Key conventions written explicitly into context for hidden assumptions? Wherever the answer is “no,” that failure will recur in your system. And it will recur in the guise of “the model occasionally glitching,” fooling you into thinking it is a luck problem so that you never plug the structural gap.

This is where ENG·04’s guides/sensors taxonomy and this failure taxonomy stitch together: the taxonomy tells you which shapes of guardrail exist, the failure modes tell you which failure each guardrail blocks. Put the two tables together and “is my scaffolding enough” gets an answer independent of intuition. Falsifiable signal: sort your last ten agent incidents into the five failure modes; if they cluster heavily on one or two, that is no coincidence but your harness systematically under-investing in the corresponding one or two guardrails: adding that one is far more effective than vaguely “having people be more careful.”

这四种为什么都跟"模型聪明不聪明"无关

Why none of the four is about whether the model is smart

有一个常见的误判会让整套失败学失效：把这些失败归因到"模型还不够强，等下一代就好了"。这是个会让你停止建护栏的危险想法，因为它把结构问题误读成能力问题。事实是：这四种失败的成因，是生成式系统的工作原理，而不是它的能力上限。一个更强的模型会更少幻觉、更少自信而错。但"按概率续写、流畅与正确共用一套打分"这个根本机制不会变，所以幻觉的概率会降、却不会归零；而只要不归零，雪球就仍然可能从任何一个未被检查点拦住的早期错开始。同理，上下文腐化是有效注意力随长度稀释这个机制的产物，模型窗口再大也改变不了"塞太多会稀释"的方向，只会改变拐点的位置。

所以把宝押在"等模型更强"上，等于把你系统的可靠性外包给了一个你不控制、且原理上不会归零的东西。正确的姿态是：承认这四种失败是这套架构的常驻特性而非临时缺陷，据此把护栏建成永久的结构，而不是把它当成"等模型成熟就能拆掉的脚手架"。可证伪信号：若你的团队反复以"等下一代模型"为由推迟建某条护栏，去看历史——上一代模型发布后，那一类失败真的消失了吗？多半是变少了但没消失，且在某次你以为安全的场合又咬了你一口。这就是把结构问题当能力问题的代价。

A common misjudgment can void the whole taxonomy: attributing these failures to “the model is not strong enough yet, the next generation will fix it.” This is a dangerous thought that makes you stop building guardrails, because it misreads a structural problem as a capability problem. The fact is: the cause of these four failures is how a generative system works, not its capability ceiling. A stronger model hallucinates less, is confidently wrong less often, but the fundamental mechanism of “continue by probability, with fluent and correct sharing one score” does not change, so the probability of hallucination drops but does not reach zero; and as long as it is non-zero, the snowball can still start from any early error a checkpoint failed to catch. Likewise, context rot is the product of effective attention diluting with length; however large the window, it cannot change the direction that “cramming too much dilutes,” only move the inflection point.

So betting on “wait for a stronger model” outsources your system’s reliability to something you do not control and that in principle does not reach zero. The correct stance: admit these four are permanent properties of this architecture, not temporary defects, and build guardrails as permanent structure rather than “scaffolding to dismantle once the model matures.” Falsifiable signal: if your team repeatedly defers building a guardrail on the grounds of “wait for the next model,” look at history: after the last generation shipped, did that class of failure really vanish? Most likely it grew rarer but did not vanish, and bit you again in some setting you thought safe. That is the cost of treating a structural problem as a capability problem.

自动化的反讽：盯得更紧不是答案

The irony of automation: watching harder is not the answer

还有一条最反直觉、却最重要的边界：系统越可靠，监督者的警觉性衰减越快——恰在最该接管的异常时刻，人已丢失情境感知（Bainbridge 1983《自动化的反讽》）。所以"让人实时盯屏"注定失败：人的注意力有限、不随产出增长，而错误增长是指数的。正确的解是改变介入的形态，而非盯得更紧——从实时监督改成异步分诊：让独立 checker、检查点、eval 先把绝大多数错在发生时挡掉，只把结构标记出的少数真异常、带齐上下文推给人。这样人面对的是一个已被框定、附证据的待判事项，而非几小时平静里的突发，警觉性衰减这个人因陷阱就被结构绕开了。

One more boundary is the most counterintuitive and the most important: the more reliable the system, the faster a supervisor’s vigilance decays, and at the very anomaly that most needs a takeover, the human has already lost situational awareness (Bainbridge 1983, Ironies of Automation). So “a human watching the screen in real time” is doomed: human attention is finite and does not grow with output, while error growth is exponential. The right fix is not to watch harder but to change the form of intervention: from real-time supervision to asynchronous triage; let independent checkers, checkpoints, and evals block the vast majority at the moment of occurrence, and push to the human only the few real anomalies structure has flagged, with full context attached. Then the human faces not a sudden break in hours of calm but an already-framed item with evidence to judge, and the human-factors trap of vigilance decay is routed around structurally.

先把长视野规划的前提挖出来。瀑布、季度路线图、详尽的前期设计文档，它们合理的唯一条件是：执行昂贵、且返工的代价远高于规划的代价。在那个世界里，多想一周省下三个月的错误实现，是稳赚的。所以人类一百年的工程管理都在加厚前期：写更细的 spec、画更全的甘特图、把第七步都先规划好。这套逻辑没有错，它只是对一组特定参数最优——而 AI 把那组参数改了。当 agentic coding 让"实现一版"从三个月压到三小时，提前规划的算式就反转了：你为第七步做的精细规划，很可能在第三步执行完拿到真实反馈后就作废，因为真实代码会告诉你前面的假设哪条错了。规划得越远，作废得越多。这不否定规划有用，只是说规划的最优视野缩短了。

First dig out the premise of long-horizon planning. Waterfall, quarterly roadmaps, exhaustive upfront design docs: their sole condition for being reasonable is that execution is expensive and the cost of rework far exceeds the cost of planning. In that world, a week more of thinking that saves three months of wrong implementation is a sure bet. So a century of engineering management thickened the front: finer specs, fuller Gantt charts, step seven planned in advance. This logic is not wrong; it is merely optimal for one parameter set, and AI changed that set. When agentic coding compresses “ship a version” from three months to three hours, the arithmetic of planning ahead inverts: your fine plan for step seven will likely be void once step three executes and hands back real feedback, because real code tells you which earlier assumption was wrong. The farther you plan, the more you void. This does not mean planning is useless; it means the optimal planning horizon shortens.

即时规划：贴着信号生成，凭信号重来

JIT planning: generate against signal, re-plan on signal

即时规划（just-in-time planning）的纪律只有两条。第一，只把下一段规划到"足够开始"的精度，不预先规划尚未拿到反馈的远段。因为远段的输入还不存在。第二，把每次执行的真实结果当作重新规划的触发器：测试红了、性能不达标、一个边界条件冒出来，都是"该重规划的信号"，而非"偏离计划"。这和敏捷的"小步迭代"形似而神不同：敏捷缩短的是交付周期，规划本身还是按固定节奏（每个 sprint）做的；即时规划缩短的是规划视野本身，并把重规划的触发权交给信号而非日历。一个具体对照：瀑布问"我们这季度要做的全部，先列清楚"；即时规划问"为了拿到下一个能改变后续判断的信号，最少要做哪一步"。前者优化覆盖，后者优化信息增益。

JIT planning has just two disciplines. First, plan only the next leg to “enough to start” precision, never pre-planning far legs whose feedback you have not received, because the far leg’s inputs do not yet exist. Second, treat each execution’s real result as the trigger to re-plan: a red test, a missed performance target, an edge case surfacing are not “deviations from the plan” but “signals to re-plan.” This resembles agile’s “small iterations” but differs in spirit: agile shortens the delivery cycle while planning still runs on a fixed cadence (each sprint); JIT planning shortens the planning horizon itself and hands the re-plan trigger to signal rather than the calendar. A concrete contrast: waterfall asks “list everything we will do this quarter up front”; JIT planning asks “what is the smallest step that gets the next signal capable of changing later judgment.” The former optimizes coverage, the latter information gain.

反信号：PLAN.md 越写越厚

The anti-signal: PLAN.md getting thicker

有一个干净的反信号能当场告诉你规划已经偏离轨道：PLAN.md 一直在变厚，却很少被执行打回去改。健康的即时规划里，计划文件是个薄的、活的、频繁被真实结果推翻重写的东西。它今天列三步，执行完第一步后可能整段重写，因为第一步的反馈改变了对后两步的判断。如果你的计划文件只增不改、越来越详尽地铺陈尚未验证的远期步骤，那说明团队在用"规划"代替"拿信号"：把本该靠执行去证伪的假设，写成了看起来很周全的文档。这是瀑布心智在 agentic 时代的残留。它把规划的厚度误当成确定性，而真正的确定性只能来自执行反馈。可证伪信号：统计你的计划文件被"执行结果触发的重写"次数 vs "纯追加"次数；前者远低于后者，就是规划视野没有随执行变充裕而坍缩的证据。〔源 本系列工程实践综合 + Graziano Day 3"先计划 / 保持上下文干净 / 知道何时叫停"，证据级 Ⅳ[R1]〕

One clean anti-signal tells you on the spot that planning has gone off: PLAN.md keeps getting thicker yet is rarely pushed back by execution. In healthy JIT planning the plan file is a thin, living thing, frequently overturned and rewritten by real results. It lists three steps today, and after step one may be rewritten wholesale because step one’s feedback changed the judgment on the other two. If your plan file only grows and never revises, laying out ever more detail of unverified far steps, the team is substituting “planning” for “getting signal”: writing assumptions that execution was supposed to falsify into a document that merely looks thorough. This is the waterfall mind’s residue in the agentic era: it mistakes the thickness of the plan for certainty, when real certainty can only come from execution feedback. Falsifiable signal: count how often your plan file is rewritten-triggered-by-result versus pure-append; the former far below the latter is evidence the planning horizon has not collapsed with cheap execution. [Source: this series’ engineering-practice synthesis + Graziano Day 3 “plan first / keep context clean / know when to stop,” grade Ⅳ. [R1]]

先计划，再放手：从 Chat 到 Plan 的那一步

Plan first, then let go: the step from Chat to Plan

即时规划"视野要短"，但短不等于"不规划"——恰恰相反，agentic coding 里最高杠杆的一个习惯，就是在让 agent 动手之前，先让它（和你）把这一段的计划摆出来。这就是从 Chat 模式到 Plan 模式的关键转变：Chat 模式下你直接说"去做 X"，agent 立刻开始边想边改，错误在它跑起来之后才暴露、且已经雪球了；Plan 模式下它先产出一份"我打算这样切这一段、按这个顺序、在这几处验证"的计划，你在它真正改任何代码之前先审这份计划。这一步之所以高杠杆，是因为审一份计划比审一堆已经写出来的 diff 便宜得多——计划里一个错的假设，在它变成三十个文件的改动之前就被你拦下了。它和 JIT 的"短视野"不矛盾：短视野说的是"不要规划尚未拿到反馈的远段"，先计划说的是"对要动手的这一近段，先把计划显式化再执行"。两条合起来：近段先计划再放手，远段留白等信号。〔源 Graziano《AI-Native Engineering》Day 3 "从 Chat 到 Plan" + 与 agent 协作最佳实践（先计划 / 保持上下文干净 / 知道何时叫停 / 以测试为目标 / 逐 diff 评审），证据级 Ⅳ 一手从业者[R1]〕

JIT planning says “keep the horizon short,” but short does not mean “do not plan”; quite the opposite: one of the highest-leverage habits in agentic coding is to have it (and you) lay out the plan for this leg before letting the agent act. This is the key shift from Chat mode to Plan mode: in Chat mode you say “go do X” and the agent immediately thinks-while-changing, with errors surfacing only after it runs and already snowballed; in Plan mode it first produces a plan of “I intend to cut this leg this way, in this order, verifying at these points,” and you review that plan before it touches any code. This step is high-leverage because reviewing a plan is far cheaper than reviewing a pile of already-written diffs: a wrong assumption in the plan is caught before it becomes a change across thirty files. It does not conflict with JIT’s “short horizon”: short horizon says “do not plan far legs without feedback,” plan-first says “for the near leg you are about to act on, make the plan explicit before executing.” Together: plan the near leg then let go, leave the far leg blank and wait for signal. [Source: Graziano, AI-Native Engineering Day 3 “from Chat to Plan” + best practices with agents (plan first / keep context clean / know when to stop / target tests / review by diff), grade Ⅳ practitioner. [R1]]

这也重排了"计划"这件事在团队里的产权。瀑布把规划当成项目早期一次性的、由少数人产出的厚资产；即时规划把它变成贴着每一段执行、由"最接近这段反馈的人"持续产出的薄活动。谁来重规划？是拿到了上一段执行结果的那个人（或 agent），而非季度初定路线图的那个人——因为重规划的输入（真实反馈）就攥在他手里。这把"规划权"从日历和层级里解放出来，交给信号。它对组织的可证伪推论是：一个真正即时规划的团队，其"计划被谁改"应该高度分布、且紧跟执行；若计划仍然只能由季度初那几个人改、且改动周期是季度而非天，那这个团队只是把瀑布的甘特图换了个工具，规划视野并没有随执行变充裕而坍缩。

This also reorders the ownership of “planning” in a team. Waterfall treats planning as a one-off thick asset produced early by a few; JIT planning makes it a thin activity produced continuously against each leg of execution by “whoever is closest to that leg’s feedback.” Who re-plans? Not the person who set the roadmap at quarter start, but the person (or agent) who received the last leg’s execution result, because the input to re-planning (real feedback) is in their hands. This frees the “right to plan” from the calendar and the hierarchy and hands it to signal. Its falsifiable organizational corollary: a genuinely JIT-planning team’s “who edits the plan” should be highly distributed and tightly tracking execution; if the plan can still only be edited by the few who set it at quarter start, on a quarterly rather than daily cycle, the team has merely swapped tools for the waterfall Gantt chart. The planning horizon has not collapsed with cheap execution.

知道何时叫停：即时规划的另一半纪律

Knowing when to stop: the other half of JIT discipline

即时规划讲的是"什么时候重规划"，但有一个对称的、同样重要的判断常被漏掉：什么时候叫停。当一段执行的反馈反复是坏的——agent 第三次没把这个问题解对、计划被推翻了两轮、每次重规划都在原地打转。这本身就是一个信号，但它指向的是"这条路可能根本走不通，该退回去换个切法、或者把这一段升级成需要人深想的判断"，而非"再规划一次"。

知道何时叫停之所以难，是因为 agent 永远显得"再试一次就好"：它不会疲惫、不会气馁、每次都信心满满地再来一版，这种永不言弃的特质恰恰会把人拖进一个低效的循环：人不断重规划、agent 不断重试，却没人后退一步问"是不是这个问题被切错了"。所以即时规划的完整纪律其实是三条而非两条：薄规划、凭信号重规划、以及识别"重规划已经无效"这个元信号、及时叫停升级。这第三条把人的判断放在了最该放的地方——是判断"这件事现在还该不该这么做下去"，而非替 agent 做事。可证伪信号：若你发现自己在同一段任务上重规划了三四轮、每轮都期待"这次 agent 能行"，那大概率不是该再规划一次，是该叫停——退回去重新切问题，或者承认这一段需要人亲自深想，而不是继续喂给一个在原地打转的循环。〔源 Graziano《AI-Native Engineering》Day 3 "知道何时叫停"，证据级 Ⅳ 一手从业者[R1]〕

JIT planning is about “when to re-plan,” but a symmetric, equally important judgment is often missed: when to stop. When a leg’s feedback is repeatedly bad: the agent failed to solve this correctly a third time, the plan was overturned two rounds running, each re-plan spins in place. That is itself a signal, but it points not to “plan once more” but to “this path may simply not work; back out and cut it differently, or escalate this leg into a judgment a human must think hard about.”

Knowing when to stop is hard because the agent always looks like “one more try and it’ll be fine”: it does not tire, does not get discouraged, comes back confident with another version every time, and this never-give-up trait drags humans into a low-yield loop: the human re-plans, the agent retries, and no one steps back to ask “was this problem cut wrong?” So JIT planning’s full discipline is actually three rules, not two: thin plan, re-plan on signal, and recognizing the meta-signal that “re-planning has stopped working” and escalating in time. This third puts human judgment where it most belongs: not doing the agent’s work but judging “should this still be done this way at all right now.” Falsifiable signal: if you find yourself re-planning the same leg three or four rounds, each time expecting “this time the agent will get it,” it is most likely not time to plan again but to stop. Back out and re-cut the problem, or admit this leg needs a human to think it through personally, rather than keep feeding a loop spinning in place. [Source: Graziano, AI-Native Engineering Day 3 “know when to stop,” grade Ⅳ practitioner. [R1]]

即时规划如何不退化成"边想边改"

How JIT planning avoids degrading into “think-while-changing”

即时规划有一个必须当面挡住的滑坡：把"视野短"误解成"不用计划、走一步看一步"，结果退化回最坏的那种 vibe-coding——没有 spec、没有检查点，agent 边想边改，错误雪球到不可收拾。

短视野和无规划是两件完全不同的事，区分它们的是一个简单的判据：每一段开始执行前，这一段的"什么算完成、在哪几处验证"是不是显式的？是，就是健康的即时规划（短，但每一段都有明确的验收和检查点）；否，就是退化的边想边改（既短又盲）。所以即时规划的"薄计划"薄的是视野（不规划远段），不是密度（近段的验收标准要清晰）。把这条和 ENG·05 的检查点、ENG·12 的 eval 接起来，即时规划其实是给每一段执行配了一对边界：开头一个显式的"这段要达成什么"，结尾一组"达成了没有"的可机检验证。两者之间 agent 可以自由发挥，但它发挥的空间被这对边界框住，错误出不了这一段。这恰好让即时规划兼得了快和稳：快，因为不为远段做会作废的规划；稳，因为每一近段都有明确的验收闸。可证伪信号：若你的"即时规划"实践里，agent 经常在一段还没说清"什么算完成"的情况下就开跑、且要到跑完很久才发现方向错了，那不是即时规划，是把无规划包装成了敏捷。它会以雪球的方式定期惩罚你。

JIT planning has a slope to block head-on: misreading “short horizon” as “no planning, take it a step at a time,” which degrades back into the worst vibe-coding: no spec, no checkpoints, the agent thinking-while-changing, errors snowballing beyond recovery.

Short horizon and no planning are entirely different things, distinguished by a simple criterion: before each leg executes, is “what counts as done, and where to verify” explicit for that leg? If yes, it is healthy JIT planning (short, but each leg has clear acceptance and checkpoints); if no, it is degraded think-while-changing (both short and blind). So JIT planning’s “thin plan” is thin in horizon (do not plan far legs), not in density (the near leg’s acceptance criteria must be clear). Wire this to ENG·05’s checkpoints and ENG·12’s evals, and JIT planning actually fits each leg of execution with a pair of boundaries: an explicit “what this leg should achieve” at the start, and a set of machine-checkable verifications of “did it achieve it” at the end. Between them the agent improvises freely, but its room is framed by that pair, and errors cannot leave the leg. This is exactly how JIT planning gets both fast and stable: fast, because no will-be-voided planning for far legs; stable, because every near leg has a clear acceptance gate. Falsifiable signal: if in your “JIT planning” practice the agent often starts running before a leg has stated “what counts as done,” and only long after it finishes do you discover the direction was wrong, that is not JIT planning but no-planning dressed as agile: it will punish you periodically by snowball.

新的攻击面来自把"会被文本操纵"和"能改世界"接在了一起。传统安全里，被信任的进程执行的是确定的代码；而一个 agent 执行的是它当场推理出来的动作，而那个推理可以被它读到的任何文本改写——包括它从一个工具拉回来的内容。这就是两类具体威胁的根：prompt injection（提示注入）是攻击者把指令藏在 agent 会读到的数据里（一个网页、一封邮件、一段代码注释），诱导它把这些数据当成你的指令来执行；MCP tool poisoning（工具投毒）是更隐蔽的一种。一个看似普通的 MCP 工具，在它的描述或返回里夹带指令，悄悄改写 agent 对"现在该做什么"的理解。两者的共同点是：agent 分不清"待处理的数据"和"该服从的指令"，因为对它而言两者都只是上文里的 token。所以安全边界不能再只防外部入口，必须防到agent 自己的每一次工具调用。〔源 Graziano《AI-Native Engineering》Day 4 MCP 安全（tool poisoning / prompt injection / 凭证泄露 / 最小权限清单），证据级 Ⅳ 一手从业者[R6][R1]〕

The new attack surface comes from wiring “steerable by text” to “can change the world.” In traditional security a trusted process runs definite code; an agent runs an action it reasons out on the spot, and that reasoning can be rewritten by any text it reads, including content it pulls back from a tool. This is the root of two concrete threats: prompt injection is an attacker hiding instructions in data the agent will read (a web page, an email, a code comment), inducing it to execute that data as if it were your instruction; MCP tool poisoning is subtler: an innocuous-looking MCP tool smuggles instructions in its description or return value, quietly rewriting the agent’s sense of “what to do now.” What they share: the agent cannot distinguish “data to process” from “an instruction to obey,” because to it both are just tokens in context. So the security boundary can no longer only guard the external entrance; it must reach down to each of the agent’s own tool calls. [Source: Graziano, AI-Native Engineering Day 4 MCP security (tool poisoning / prompt injection / credential leakage / least-privilege manifest), grade Ⅳ practitioner. [R6][R1]]

最小权限：默认只读，按能力授权

Least privilege: read-only by default, scoped by capability

这条新边界的第一块基石是把最小权限原则从人扩展到 agent，并把默认值设成最严。具体三条：其一，默认只读——agent 拿到的工具，能力默认只到"读和提议"，写、删、部署、转账这类改变世界的动作不在默认集合里。这正是成熟实践把 CI/CD 里的 agentic workflow 设成"默认只读、写操作须显式声明 safe-output"的同一条原则（Graziano Day 7 Continuous AI）。其二，按能力授权（capability scoping）——是给一组细粒度、可单独审计的能力凭证，而非给 agent 一把"管理员钥匙"：这个 agent 能读这个仓库、能跑测试，但不能 push、不能碰生产数据库。这样一次工具投毒最多只能在被授予的那一小块能力内造成影响。其三，凭证不进上下文——密钥、token 绝不写进 prompt 或对话历史，否则一次 prompt injection 就能把它们读出来外泄；凭证应由 harness 在工具调用层注入，agent 本身永远看不到明文。

The first foundation of this boundary extends the principle of least privilege from people to agents and sets the default to the strictest. Three rules: first, read-only by default: the tools an agent receives default to “read and propose,” with world-changing actions (write, delete, deploy, transfer) outside the default set. This is the same principle by which mature practice sets CI/CD agentic workflows to “read-only by default, write actions must declare safe-output explicitly” (Graziano Day 7 Continuous AI). Second, capability scoping: not handing the agent one “admin key” but a set of fine-grained, separately auditable capability credentials: this agent may read this repo and run tests but may not push, may not touch the production database. So a single tool-poisoning can affect at most the small slice of capability it was granted. Third, credentials never enter context: keys and tokens are never written into a prompt or conversation history, or one prompt injection reads them out and exfiltrates them; credentials are injected by the harness at the tool-call layer, and the agent itself never sees the plaintext.

这道边界必须前置，不能靠事后审查：agent 几秒就能调几十个工具、改几百个文件，等人来审时越权早已发生；它的攻击面又是自然语言，无法被穷举地静态扫描。落到操作上有一条可照做的纪律：接一个新工具，要像引一个新依赖那样审，我们不会随便 npm install 一个陌生包，会看它要什么权限、会不会把数据回传到你不控制的地方；接一个 MCP server / 工具该走同一道关，先查它的工具描述里有没有可疑指令。

This boundary must be front-loaded, not left to after-the-fact review: an agent can call dozens of tools and change hundreds of files in seconds, and by the time a human reviews, the over-privileged action has already happened; its attack surface is natural language, which cannot be exhaustively statically scanned. Operationally there is one copyable discipline: vet connecting a new tool as you would adding a new dependency. We do not casually npm install a stranger's package; we check what permissions it wants and whether it sends data somewhere you do not control; connecting an MCP server / tool should pass the same gate, checking its tool descriptions for suspicious instructions first.

可拷贝清单 · 最小权限边界

Copyable checklist · least-privilege boundary

• 默认只读：流水线里的 agentic 工作流默认无写权，写操作须显式声明为 safe-output、经人审后合并。
• Read-only by default: agentic workflows in the pipeline have no write access by default; writes are declared safe-output explicitly and merge only after human review.
• 逐工具授权：每个 MCP server / 工具单独列权限，不给通配。
• Per-tool authorization: list permissions per MCP server / tool, with no wildcards.
• 隔离执行：让 agent 在沙箱 / 容器里跑，限定它能触达的文件、网络、密钥范围，爆炸半径在结构上就被含住。
• Isolated execution: run the agent in a sandbox / container that bounds the files, network, and secrets it can reach, so the blast radius is contained structurally.
• 不可信数据隔离：把"被处理的数据"和"给 agent 的指令"在通道上分开，别让前者能改写后者。
• Untrusted-data isolation: separate “data being processed” from “instructions to the agent” at the channel level, so the former cannot rewrite the latter.
• 人守在不可逆处：删除、转账、对外发布、权限变更这类写操作设显式确认门，agent 不得自决。
• Humans guard the irreversible: deletes, transfers, external publishes, and permission changes get an explicit confirmation gate; the agent may not self-authorize.

可组合的能力接口：拼接自由，授权分立

Composable capability interfaces: free to compose, authorized apart

agent 靠一组可组合的能力接口（skills / MCP / CLI）扩展触达，但"可组合"与"安全"之间有一个必须当面解决的张力：你要 agent 灵活拼接多个能力，又不想任何一个被投毒的接口带跑整套权限。解法不搞折中，而是把组合性放在接口的能力面、把授权放在每个接口的边界上——接口自由拼接，但每个接口携带的能力单独授权、单独审计。这也是为什么不该给 agent 一个"能跑任意命令"的万能入口：万能入口把能力面和权限面焊死，你无法表达"可做 A、B，不可做 C"。这正是 ENG·04"可组合接口"与本章"最小权限"在同一个对象上的合流。

An agent extends its reach through a set of composable capability interfaces (skills / MCP / CLI), but between “composable” and “secure” sits a tension to resolve head-on: you want the agent to compose several capabilities flexibly, yet you do not want any one poisoned interface to run off with the whole permission set. The fix is not a compromise but putting composability on an interface’s capability face and authorization on each interface’s boundary: interfaces compose freely, but the capability each carries is authorized and audited separately. This is why you should not give the agent one “runs arbitrary commands” omnipotent entry: it welds the capability face to the permission face, and you cannot express “may do A and B, not C.” Here ENG·04’s “composable interfaces” and this chapter’s “least privilege” converge on one object.

不可逆与高权动作：把人留在这一道闸上

Irreversible and privileged actions: keep the human at this gate

第二块基石回到 INSTRUMENT 07 的爆炸半径：把人留在哪一道闸上，由"错了能不能便宜地退回"和"错了会波及多大"两个量决定。可逆且低半径的动作（改一个本地文件、跑一次只读查询）可以放手给 agent 全自动；不可逆或高半径的动作（删生产数据、对外发邮件、合并到主干、动钱）必须有人在环显式确认，因为这类动作一旦做错，没有便宜的 undo。注意这和"信不信任模型"无关。即使模型完全可信，prompt injection 也可能让它执行一个被诱导的高权动作；人在这道闸上的作用，是给不可逆动作加一道独立于模型推理的确认，而非替模型做决定。把这条和最小权限合起来看，整套安全边界其实是同一句话的两半：能力默认收到最小，不可逆的那部分能力则永远要人来临时解锁。这也解释了为什么"全自动 agent fleet"在工程上能成立而在涉及不可逆动作时必须留闸——不是技术不到位，是爆炸半径决定了这道判断不能下放。

The second foundation returns to INSTRUMENT 07’s blast radius: which gate you keep the human at is set by “can the error be reversed cheaply” and “how far does the error reach.” Reversible, low-radius actions (editing a local file, running a read-only query) can be handed fully to the agent; irreversible or high-radius actions (deleting production data, sending external email, merging to main, moving money) must have a human-in-the-loop explicit confirmation, because once such an action goes wrong there is no cheap undo. Note this is unrelated to “trusting the model”: even a fully trustworthy model can be made by prompt injection to execute an induced privileged action; the human at this gate does not make the decision for the model but adds a confirmation independent of the model’s reasoning to irreversible actions. Put together with least privilege, the whole boundary is two halves of one sentence: capability defaults to the minimum, and the irreversible part of capability is always unlocked momentarily by a human. This is why a “fully autonomous agent fleet” holds up in engineering yet must keep a gate for irreversible actions: not a technology gap but the blast radius deciding this judgment cannot be delegated.

数据与指令的混淆：注入攻击的根

Confusing data with instruction: the root of injection

把 prompt injection 和 tool poisoning 归到同一个根，能让防御从"列举一堆攻击花样"变成"堵一个结构漏洞"：agent 无法在原理上区分"待处理的数据"和"该服从的指令"，因为对它而言两者都只是上文里的 token。传统软件有清晰的数据/代码分界。一段用户输入永远不会被当作可执行指令，除非你犯了注入类 bug；而一个 agent 的"指令"本身就是自然语言、和它读到的数据同一种介质，于是边界天然模糊。

这解释了为什么这类攻击防不胜防：你没法靠转义、参数化这类传统手段一劳永逸，因为没有一个语法层面的分界线可供转义。可操作的缓解是承认这个混淆、然后从结构上限制它的后果，而不是指望模型"学会分辨"：其一，把来自不可信来源的内容（外部网页、第三方工具返回）标注为数据、降权处理，让模型知道这部分不是来自你的指令；其二，回到最小权限。既然无法保证模型不被诱导，就保证它就算被诱导，能调用的高权动作也已被收走、或必须过人这道独立闸。重心于是落在"别让它被骗"之外的那一半——"被骗了也炸不大"。这正是最小权限、能力授权、不可逆动作留人这三块基石在同一个威胁上的合力。

Sorting prompt injection and tool poisoning to one root turns defense from “enumerate a pile of attack tricks” into “plug one structural hole”: an agent cannot in principle distinguish “data to process” from “an instruction to obey,” because to it both are just tokens in context. Traditional software has a clean data/code line: a piece of user input is never treated as an executable instruction unless you commit an injection-class bug; but an agent’s “instructions” are themselves natural language, the same medium as the data it reads, so the boundary is natively blurred.

This explains why such attacks are so hard to fully prevent: you cannot solve it once and for all with escaping or parameterization, because there is no syntactic dividing line to escape against. The operational mitigation is to admit the confusion and then structurally bound its consequences rather than hoping the model “learns to tell them apart”: first, mark content from untrusted sources (external web pages, third-party tool returns) as data and down-weight it, so the model knows this part is not your instruction; second, fall back to least privilege: since you cannot guarantee the model is never induced, guarantee that even when induced, the privileged actions it can call have already been removed or must pass the independent human gate. In other words, injection defense centers not on “do not let it be fooled” but on “even when fooled, the blast is small.” This is exactly the combined force of the three foundations (least privilege, capability scoping, irreversible-action gating) on one threat.

Continuous AI：把"默认只读"写进流水线

Continuous AI: write “read-only by default” into the pipeline

这条信任边界最实的落地，是把它从"约定"变成流水线里强制的默认值。当 agent 进入 CI/CD、开始在自动化工作流里跑（Continuous AI），"默认只读、写操作须显式声明 safe-output"这条规则就是流水线层面的硬约束，而非某个人记得遵守的纪律：一个 agentic workflow 默认拿到的是只读能力，任何会改变世界的输出（提交、发布、对外调用）都必须被显式标记为安全输出、并走它自己那道审查。这把安全边界从"靠人在每次操作时谨慎"前移到了"系统默认就不给危险能力"——前者依赖人不出错，后者依赖人主动解锁，而主动解锁这个动作本身就是一道天然的检查点。

它和前面的爆炸半径是同一个设计：低半径动作默认通过，高半径动作默认拦下、要人显式放行。把这条放进自动化的意义在于，agent 在流水线里是无人值守地跑的。正因为没人实时盯着，默认值才必须设成最安全的那一档，因为出了事没有一个在场的人能当场喊停。可证伪信号：若你的自动化流水线里 agent 默认就能 push、能发布、能调用生产 API，且没有一道"写操作须显式声明"的闸，那么这条流水线的安全性完全依赖于"模型永不被诱导"这个你无法保证的前提。它是侥幸，不是安全。〔源 Graziano《AI-Native Engineering》Day 7 Continuous AI（CI/CD 里的 agentic workflow，默认只读、写操作须显式声明 safe-output），证据级 Ⅳ 一手从业者[R1]〕

The most concrete landing of this trust boundary is turning it from a “convention” into a pipeline-enforced default. When agents enter CI/CD and run inside automated workflows (Continuous AI), the rule “read-only by default, write actions must declare safe-output explicitly” stops being a discipline someone remembers to keep and becomes a hard constraint at the pipeline level: an agentic workflow gets read-only capability by default, and any world-changing output (commit, release, external call) must be explicitly marked as a safe output and pass its own review. This moves the security boundary from “rely on humans being careful on each action” forward to “the system gives no dangerous capability by default”: the former depends on a human not erring, the latter on a human actively unlocking, and the act of unlocking is itself a natural checkpoint.

Putting this into automation matters because the agent runs unattended in the pipeline. Precisely because no one watches in real time, the default must be set to the safest rung, since when something goes wrong there is no present human to call a halt. Falsifiable signal: if agents in your automated pipeline can push, release, and call the production API by default with no “write actions must declare explicitly” gate, that pipeline’s security rests entirely on the premise that “the model is never induced,” which you cannot guarantee: that is not security but luck. [Source: Graziano, AI-Native Engineering Day 7 Continuous AI (agentic workflows in CI/CD, read-only by default, write actions must declare safe-output), grade Ⅳ practitioner. [R1]]

凭证泄露：把密钥挡在上下文之外

Credential leakage: keep keys out of context

这条边界还有一个具体到操作层的红线值得单列：密钥、token、凭证绝不能进上下文。原因和注入是同一个根。既然 agent 分不清数据和指令，那么一旦凭证出现在它的上下文里，一次成功的 prompt injection 就能让它把凭证当作"可以输出的数据"读出来、再经由某个看似无害的工具调用外泄。这不是假想：任何能让 agent 读到密钥、又能让它对外发出内容的组合，都构成一条泄露通道。

正确的做法是结构性地把凭证挡在 agent 的视野之外——凭证由 harness 在工具调用的那一层注入到实际请求里，agent 只看到"调用这个工具"这个动作，永远看不到凭证的明文。这样即使 agent 被完全诱导，它手里也没有可外泄的东西。这条和最小权限是同一套思路的延伸：最小权限收的是"能做什么"，凭证隔离收的是"能看到什么敏感数据"，两者合起来才让"被诱导"的后果可控。可证伪信号：去查你给 agent 的上下文（系统提示、工具定义、对话历史）里有没有任何明文密钥或可直接换取权限的 token——只要有一处，你的安全就建立在"没有人成功注入"这个你无法保证的假设上，而不是建立在结构上。〔源 Graziano《AI-Native Engineering》Day 4 MCP 安全（凭证泄露 / 最小权限清单），证据级 Ⅳ 一手从业者[R6][R1]〕

This boundary has one operational-level red line worth listing alone: keys, tokens, and credentials must never enter context. The reason shares the root with injection. Since the agent cannot tell data from instruction, once a credential appears in its context, one successful prompt injection can make it read the credential as “data it may output” and exfiltrate it through some innocuous-looking tool call. This is not hypothetical: any combination that lets the agent read a key and also emit content externally forms a leak channel.

The correct approach structurally keeps credentials out of the agent’s view: the harness injects credentials into the actual request at the tool-call layer, and the agent sees only the action “call this tool,” never the credential in plaintext. So even fully induced, the agent has nothing exfiltratable in hand. This extends the same idea as least privilege: least privilege constrains “what it can do,” credential isolation constrains “what sensitive data it can see,” and together they make the consequence of “being induced” controllable. Falsifiable signal: check whether the context you give the agent (system prompt, tool definitions, conversation history) contains any plaintext key or a token directly exchangeable for access. If even one is there, your security rests on the assumption “no one injects successfully,” which you cannot guarantee, rather than on structure. [Source: Graziano, AI-Native Engineering Day 4 MCP security (credential leakage / least-privilege manifest), grade Ⅳ practitioner. [R6][R1]]

先说清 eval 和传统 QA 的种类差别。传统一次性 QA 是个事件：在发布前，人把这一版过一遍，判断它够不够好，然后这次判断就消失了。它活在那个人那一刻的脑子里，不可回归。下次换个 prompt、改个模型、调个参数，上次确认过的东西可能又错了，而没有任何机制会告诉你。eval 是把这件事反过来：每发现一类错误，就把它固化成一条可机器执行的判定，进回归套件，从此机器替你在每次改动后重新盯住它。这条差别是种类性的，不是程度性的：QA 验证"这一版"，eval 积累"这个团队对何为对的全部判断"。所以随着时间推移，QA 的总量随发布次数线性堆叠又线性蒸发，而 eval 套件只增不减。它是沉淀，每条都对应一次曾经痛过的教训。〔源 本系列验证篇综合：把验证沉淀成评测台、错误回流成 eval、可观测性把生产错样回流，证据级 Ⅳ〕

First, the categorical difference between evals and traditional QA. One-off QA is an event: before release a human runs this version through, judges whether it is good enough, and then that judgment vanishes: it lived in that person’s head at that moment and cannot regress. Next time, under a new prompt, a swapped model, a tuned parameter, what was confirmed last time may be wrong again, with no mechanism to tell you. An eval inverts this: each time a class of error is found, you solidify it into a machine-runnable verdict, enter it into the regression suite, and from then on the machine watches it for you after every change. This difference is of kind, not degree: QA verifies “this version,” an eval accumulates “all of this team’s judgment of what is correct.” So over time the total QA stacks linearly with releases and evaporates just as linearly, while the eval suite only grows: it is sediment, each entry a once-painful lesson.

错误回流：每个 bug 离开时留下一条 eval

Errors flowing back: every bug leaves an eval behind

承重墙是怎么垒起来的，全在一条纪律：每个被修复的错误，离开时必须留下一条 eval。修一个 bug 而不补一条能在它复发时变红的 eval，等于这次教训只在一个人脑子里存了一份、且会随时间忘掉——下次同类错误会原样回来。把这条纪律执行到底，套件就成了一个随产出复利的资产：产出越多、踩过的坑越多、回流的 eval 越多，覆盖越厚；而覆盖越厚，下一次同类错误被自动拦下的概率越高，需要人盯的部分越少。这正是和组织卷"自改进循环"同一个形状的工程版本——把每次失败沉淀成可复用资产，监督需求随时间下降（Graziano Day 4 把它叫 steering loop：每次 agent 失败就问"哪条 guide/sensor 本该拦住"，补那一条）。再配上可观测性，这个循环还能自己喂自己：生产环境里出错的真实样本被自动回流成新 eval，套件就不只复利于内部踩坑，还复利于真实世界的反馈。这就是为什么趋势上未来最大的工程投入会流向验证基础设施。它是唯一一处投入会随时间利滚利的地方。

How the load-bearing wall is laid up comes down to one discipline: every fixed error must leave an eval behind when it goes. Fixing a bug without adding an eval that turns red when it recurs means the lesson was stored in one head and will be forgotten over time; next time the same class of error returns unchanged. Carry this discipline through and the suite becomes an asset that compounds with output: the more you produce, the more pits you have stepped in, the more evals flow back, the thicker the coverage; and the thicker the coverage, the higher the chance the next same-class error is auto-caught, the less a human must watch. This is the same principle, in engineering form, as the organization volume’s “self-improving loop”: distill each failure into a reusable asset, supervision demand falling over time (Graziano Day 4 calls it the steering loop: on each agent failure, ask “which guide/sensor should have caught this” and add that one). Add observability and the loop feeds itself: real error samples from production flow back automatically into new evals, so the suite compounds on both internal pitfalls and real-world feedback. This is why the trend is for the largest future engineering investment to flow into verification infrastructure: it is the one place where investment compounds over time.

为什么生成越廉价，eval 越是唯一瓶颈

Why cheaper generation makes evals the one bottleneck

把 ENG·00 的"瓶颈搬家"放到这里收口：生成近乎免费之后，唯一没有变便宜的就是判断生成出来的东西对不对。一个能一夜产出一万行的 agent，若没有一面能自动判定这一万行对错的墙，它产出的是待审债务，而非价值——而人审一万行的速度并没有因为模型变强而提高。所以 eval 套件的厚度，直接决定了你能安全地让生成跑多快：墙越厚，越多的产出能被自动判过，人就越能从实时盯屏退到只处理机器拦不住的少数判断。反过来，墙薄的团队会发现"agent 越快、人越累"——因为每一份产出都回流到那个没有变快的人审瓶颈上。这给出一个可证伪的资源配置预测：一个真正 AI-Native 的工程团队，其验证基础设施（eval / checker / 可观测回流）的投入占比应该随产出能力上升而上升，而非下降；若一个团队"AI 化"后把省下的人力全投回写更多功能、却没有同步加厚验证墙，它迟早会被自己的产出淹没。这正是 vibe-coding 陷阱在团队尺度上的版本。

Close the loop with ENG·00’s “the bottleneck moves” here: once generation is near-free, the one thing that did not get cheaper is judging whether the generated thing is correct. An agent that can produce ten thousand lines overnight, lacking a wall that auto-decides whether those ten thousand are right, produces not value but review-debt. And a human’s speed at reviewing ten thousand lines did not rise because the model got stronger. So the thickness of the eval suite directly sets how fast you can safely let generation run: the thicker the wall, the more output gets auto-judged, and the more a human can retreat from watching the screen in real time to handling only the few judgments the machine cannot. Conversely a team with a thin wall finds “the faster the agent, the more tired the human”: because every unit of output flows back to that human-review bottleneck that did not speed up. This yields a falsifiable resource prediction: a truly AI-Native engineering team’s share of investment in verification infrastructure (evals / checkers / observability feedback) should rise, not fall, as production capacity rises; if a team “goes AI” and reinvests all freed labor into writing more features without thickening the verification wall in step, it will eventually be drowned by its own output: the team-scale version of the vibe-coding trap.

独立验证器为什么必须和生成分离

Why the verifier must be separate from the generation

eval 套件要能当承重墙，有一个常被忽略却致命的结构条件：判对错的那个东西，必须独立于产出它的那个东西。让生成代码的同一个 agent 来判自己写的代码对不对，约等于让考生自己批卷。它用来生成的那套"觉得对"的判断，恰好就是它用来自评的那套判断，于是它会系统性地对自己的盲区视而不见（自信而错正是这种盲区的典型）。

所以承重墙的承重，不在"有没有验证"，而在"验证是不是一道独立的力"：一条 eval、一个类型检查器、一套测试，它们的判定不经过生成模型的"觉得"，而是对照一份外部的、确定的判据。这就是为什么 computational 的检查（编译器、测试）在验证里地位特殊。它们天生独立于生成，不会被生成的语气或自洽性带跑。当你不得不用 inferential 的检查（比如让另一个模型做语义评审）时，独立性要靠"换一个上下文、换一套判据"来人为制造，而不能假设它天然存在。可证伪信号：若你的"验证"其实是同一个 agent 在同一条上下文里自己说"我检查过了没问题"，那你没有承重墙，你有一面画在纸上的墙。它在最该挡住自信而错的时候恰好挡不住。

For an eval suite to be a load-bearing wall there is an often-overlooked but fatal structural condition: the thing that judges correctness must be independent of the thing that produced it. Letting the same agent that generated the code judge whether its own code is correct is roughly letting a candidate grade their own exam. The very “feels right” judgment it used to generate is the judgment it uses to self-assess, so it systematically goes blind to its own blind spots (confident wrongness is the textbook case of such a blind spot).

So the load-bearing of the wall is not in “is there verification” but in “is the verification an independent force”: an eval, a type checker, a test suite render their verdict without passing through the generating model’s “feeling,” checking against an external, definite criterion. This is why computational checks (compilers, tests) hold a special place in verification: they are natively independent of generation and cannot be carried off by its tone or self-consistency. When you must use an inferential check (say, another model doing a semantic review), independence must be manufactured by “a different context, a different criterion,” not assumed to exist naturally. Falsifiable signal: if your “verification” is actually the same agent in the same context saying “I checked, it’s fine,” you have no load-bearing wall but a wall painted on paper. It fails to block exactly when it most needs to block confident wrongness.

验证器也要被验证：分离只是第一步，空壳钥匙能刷爆 LLM 裁判

The verifier must itself be verified: separation is only step one

把生成和验证分开，只堵住了"考生自己批卷"这一种失效；它没有保证那个独立的验证器本身可靠。一旦你用 LLM 当裁判（LLM-as-judge）来判"这段输出对不对"，裁判就成了新的攻击面：研究《One Token to Fool LLM-as-a-Judge》发现，往答案里塞一把"空壳钥匙"——一句"让我们一步步想""答案如下"之类的开场白、甚至单个 token——就能把某些 LLM 裁判刷出约 80% 的假阳性，给一个根本没解题的空壳打高分。所以这是二阶护栏：装了个 verifier 不等于有承重墙，装了个能被一句话骗过的 verifier，你只是把"自信而错"换成了"被骗而错"。

Splitting generation from verification only plugs the “candidate grading their own exam” failure; it does not guarantee that the independent verifier is itself reliable. The moment you use an LLM as the judge (LLM-as-judge) of “is this output correct,” the judge becomes a new attack surface: the study One Token to Fool LLM-as-a-Judge finds that an “empty-shell key” can drive some LLM judges to roughly 80% false positives, scoring a hollow non-answer highly. The key can be a boilerplate opener like “let’s think step by step” or “the answer is,” or even a single token. So this is a second-order guardrail: having a verifier is not having a load-bearing wall; a verifier that one sentence can fool merely swaps “confident wrongness” for “fooled wrongness.”

解法是分清两类问题、用两种判据（Hybrid Norm）。"对不对"（功能正确、是否通过）优先交给可执行奖励——编译、测试、property check 这类不经模型"觉得"的确定判据；"好不好"（语义质量、可读性、风格）才交给 LLM 评分卡，且评分卡只在"对不对"已被可执行判据锁住之后才上场。还有一层常被忽略：验证器所处的那套脚手架——harness 本身就是产品的一部分。SWE-bench Verified（原 SWE-bench 的人工校验子集）让位给更难、更抗污染的 SWE-bench Pro；同一个模型、同一组权重，只是换一套 harness，分数能波动 10–20 个百分点。所以"我们有 eval、分数很高"并不等于验证可靠。你得同时能回答"这套 harness 是不是在量它该量的东西"。可证伪信号：若你的 eval 只有一个 LLM 评分卡、却没有任何可执行判据兜底，那它随时可能正被一把空壳钥匙刷分而你不知道。

The fix is to separate two kinds of question and use two criteria (a Hybrid Norm). “Is it correct” (functional correctness, pass/fail) goes first to an executable reward: compilation, tests, property checks, definite criteria that do not pass through the model’s “feeling”; “is it good” (semantic quality, readability, style) goes to an LLM scorecard, and only after “is it correct” is already locked by an executable check. One layer is often missed: the scaffold the verifier runs inside, the harness, is itself part of the product. SWE-bench Verified (the human-validated subset of the original SWE-bench) gave way to the harder, more contamination-resistant SWE-bench Pro; the same model at the same weights, with only the harness swapped, can move scores by 10–20 percentage points. So “we have evals and the score is high” is not the same as “verification is reliable”: you must also answer “is this harness measuring the thing it should measure.” Falsifiable signal: if your eval is a lone LLM scorecard with no executable criterion underneath, it may be getting gamed by an empty-shell key right now without your knowing.

eval 套件就是组织被写下来的判断

The eval suite is the organization’s judgment, written down

把这一节的命题推到底，会得到一个对组织有点反直觉的结论：一个团队的 eval 套件，是它对"何为对"的集体判断被外化、被固化、能被机器反复执行的那一份。它是这个组织在质量这件事上的记忆。资深工程师的价值，很大一部分在于他脑子里那套"这样不行""这里会出事""这个边界没考虑到"的判断；但这套判断过去只能通过 code review、带新人、口头传授缓慢地、有损地复制，且随人离职而流失。把每一类判断沉淀成一条 eval，等于把这套原本住在个别人脑子里的判断，搬进一个不离职、不疲劳、对每次改动都一视同仁执行的基础设施里。

于是发生一件深远的事：质量判断从"依赖在场的某个资深的人"变成"沉淀在套件里、人人可继承"。这和组织卷"上下文即基础设施"是同一条原理在质量维度上的展开——把口口相传的隐性判断，变成可读可查可执行的显性资产。它也给"为什么验证基础设施值得最大投入"一个非效率的理由：你投进 eval 的每一条，都是在把一次性的人类判断转成永久的、可继承的组织能力。可证伪信号：若一个团队的核心质量判断仍然只能靠"问那个最资深的人"、且这套判断没有任何一部分沉淀成可执行的 eval，那么这个团队的质量记忆是脆弱的。它会随那个人的离开而塌掉一大块，这正是"判断没有被写下来"的代价。

Push this section’s thesis to its end and you reach a conclusion a little counter-intuitive for organizations: a team’s eval suite is its collective judgment of “what is correct,” externalized, solidified, and re-runnable by machine: it is the organization’s memory on the matter of quality. Much of a senior engineer’s value lies in the set of judgments in their head: “this won’t do,” “this will blow up,” “this boundary was not considered”; but that set could previously be copied only slowly and lossily through code review, mentoring, and verbal transmission, and was lost when people left. Distilling each class of judgment into an eval moves the judgment that lived in individual heads into infrastructure that does not quit, does not tire, and executes on every change impartially.

Then something profound happens: quality judgment shifts from “depends on a certain senior person being present” to “settled in the suite, inheritable by all.” This is the same principle as the organization volume’s “context as infrastructure” unfolded on the quality dimension: turning tacit, word-of-mouth judgment into a legible, queryable, executable explicit asset. It also gives “why verification infrastructure deserves the largest investment” a non-efficiency reason: each eval you invest in converts a one-off human judgment into a permanent, inheritable organizational capability. Falsifiable signal: if a team’s core quality judgments still rely on “asking the most senior person” and no part of that judgment has settled into runnable evals, the team’s quality memory is fragile. A large piece collapses when that person leaves, exactly the cost of “judgment never written down.”

覆盖随产出复利：为什么 eval 是少数会越投越省的投入

Coverage compounds with output: why evals are one of the few investments that get cheaper the more you make

大多数工程投入是线性消耗的：你修一个 bug，省下的是这一个 bug 的麻烦；你写一个功能，得到的是这一个功能。eval 不一样，它是少数会复利的投入之一，而复利的机制值得讲清。每补一条 eval，你不只是拦住了这一类错误这一次，你是让它在未来每一次改动里都被自动重检。一条 eval 的价值，等于它拦住的所有未来回归之和。于是套件的总价值是随"条数 × 改动频率 × 时间"增长，而非随条数线性增长。这条复利在 agentic 时代被进一步放大：因为生成变快、改动变频，每一条 eval 被重跑的次数暴增，它的边际价值随之暴增。

这就是为什么"未来最大的工程投入流向验证基础设施"是一个由复利结构推出来的预测，而非一句口号：在一个生成近免费、改动极频的系统里，唯一会随时间利滚利的投入，就是那套能在每次改动里自动重新行使判断的验证墙。反过来，这也解释了为什么薄墙团队会陷入"越跑越累"：他们的每次改动都没有被自动复检，于是改动频率的上升直接转化成人审负担的上升，而不是被一套复利的墙吸收掉。可证伪信号：把"你的 eval 套件每天被重跑多少次 × 每次拦住多少潜在回归"算出来，若这个数随团队产出能力上升而上升，你的验证投入在复利；若它停滞，你的墙没在长高，验证还停在一次性人力。〔源 本系列验证篇综合：错误回流成 eval、可观测性回流、验证基础设施是最大投入方向，证据级 Ⅳ〕

Most engineering investment is consumed linearly: fix a bug and you save the trouble of that one bug; write a feature and you get that one feature. Evals are different: one of the few investments that compound, and the mechanism is worth stating. Each eval added does not only block this class of error this once; it makes the error auto-rechecked on every future change: one eval’s value equals the sum of all future regressions it blocks. So the suite’s total value grows not linearly with count but with “count × change frequency × time.” This compounding is further amplified in the agentic era: as generation speeds up and changes get more frequent, the number of times each eval is re-run explodes, and its marginal value with it.

This is why “the largest future engineering investment flows into verification infrastructure” is not a slogan but a prediction derived from the compounding structure. In a system where generation is near-free and changes extremely frequent, the one investment that compounds over time is the verification wall that auto-re-exercises judgment on every change. Conversely it explains why thin-wall teams fall into “the faster they run, the more tired they get”: their every change is not auto-rechecked, so a rising change frequency converts directly into rising human-review burden rather than being absorbed by a compounding wall. Falsifiable signal: compute “how many times a day your eval suite is re-run × how many potential regressions each run blocks”; if this number rises with your team’s production capacity, your verification investment is compounding; if it stagnates, your wall is not growing and verification is still one-off labor. [Source: this series’ Verification-chapter synthesis: errors flowing into evals, observability feedback, verification infrastructure as the largest investment direction, grade Ⅳ.]

案例一 · 一次交给 agent 队伍的重构，雪球如何被独立验证器拦住

Case 1 · A refactor handed to an agent fleet, and how an independent verifier stopped the snowball

一支团队要把一个三百多文件的服务从回调风格迁到 async/await。换作从前，这是两名工程师两周的机械活。现在他们把任务切成八十个独立 PR，交给一支并行的 agent 队伍——执行端一夜跑完。问题出在第十七个 PR：agent 对一个并发原语做了看似合理却语义错误的改写——把一个本该串行的写操作包进了 Promise.all。它没有报错，测试也绿，因为既有测试从未覆盖这条竞态路径。它自信地错着，并把这个错误的前提带进后续每一个依赖该模块的 PR——这正是失败学里的雪球（见 ENG·09）。

A team needed to migrate a 300-plus-file service from callback style to async/await. In the old world this was two engineers’ two weeks of mechanical labor. Now they cut it into eighty independent PRs and handed them to a parallel agent fleet; the execution side finished overnight. The trouble surfaced at PR seventeen: the agent made a plausible-looking but semantically wrong rewrite of a concurrency primitive, wrapping a write that had to be serial inside a Promise.all. It threw no error and the tests were green, because the existing tests never covered that race path. It was confidently wrong, and it carried that wrong premise into every later PR that depended on the module: exactly the snowball from the failure section (see ENG·09).

留给人的那一道判断：不是"逐个读完八十个 diff"——那是把人重新塞回被放大的执行里，注定失败（自动化的反讽：系统越可靠，盯屏的人越走神，见 ENG·09）。留给人的判断是那种只有人能定的：哪些原语属于"碰了就必须人审"的高爆炸半径区。这道判断写一次，就成了那道把红牌发出去的结构；它把人的稀缺注意力从"看八十遍"压到"只看被标红的那一两个"。这正是内核第②步——执行退场，判断退守到那道决定"什么算危险"的边界上。〔机制源本卷 ENG·09 失败学 + Bainbridge《Ironies of Automation》, Automatica 1983，证据级 Ⅱ〕

The one judgment kept by a human: not “read all eighty diffs”: that stuffs the human back inside the amplified execution and is doomed (the irony of automation: the more reliable the system, the more the watcher drifts; see ENG·09). The kept judgment is constitutive: which primitives belong to the high-blast-radius zone where “touch it and a human must review.” Written once, that judgment becomes the structure that issues the red card; it compresses the human’s scarce attention from “look eighty times” to “look only at the one or two flagged red.” This is kernel step ②: execution exits, judgment retreats onto the boundary that decides what counts as dangerous. [Mechanism from this volume’s ENG·09 failure section plus Bainbridge, Ironies of Automation, Automatica 1983, grade Ⅱ.]

案例二 · 一个特性走完 Specify → Plan → Execute → Verify → Integrate → Learn

Case 2 · One feature walked end-to-end: Specify → Plan → Execute → Verify → Integrate → Learn

需求一句话："给导出功能加限流，防止一个用户拖垮整个导出队列。"在 vibe-coding 的旧惯性里，这会变成一句丢给 agent 的提示，然后看它生成一坨"看起来对"的中间件。规格驱动开发（SDD）把它走成一个有目标函数的环——下面这六步是六个各自有验收口径的检查点，不是流程图上的格子。

The ask is one sentence: “Add rate limiting to export so one user can’t starve the whole export queue.” In the old vibe-coding habit this becomes a prompt tossed at an agent, and you watch it emit a lump of “looks-right” middleware. Spec-driven development (SDD) walks it as a loop with an objective function: the six steps below are not boxes on a flowchart but six checkpoints, each with its own acceptance criterion.

留给人的那一道判断集中在第①和第④步：规格里"什么算对"是人定的——限流到底该保护什么、429 还是排队、对滥用者多狠对正常用户多软，这是产品与风险上、只能由人来定的取舍，机器没有立场可以替你持有。第④步人审的也不是代码长相，是"这套测试有没有把第①步的意图真正锁死"。其余四步：写实现、跑测试、过门、记 bug——执行充裕之后都可以、也应该交出去。〔SDD 六步与"PR 即门 / constitution 硬规则层"源 GitHub Spec-kit〔R5〕；"先写失败测试再实现"为 TDD 经典实践〕

The kept judgment concentrates in steps ① and ④: what “counts as correct” in the spec is set by a human. What the limit should protect, 429 versus queueing, how harsh on the abuser and how soft on the normal user, is a constitutive product-and-risk trade-off a machine has no standing to hold for you. And what the human reviews in step ④ is not how the code looks but whether the suite truly locks the intent of step ①. The other four steps (write the implementation, run the tests, pass the gate, log the bug) can and should be handed off once execution is abundant. [The six-step SDD plus “PR as gate / constitution as hard-rule layer” from GitHub Spec-kit [R5]; “write the failing test first” is classic TDD practice.]

案例三 · 一个权限过大的 agent，越界、回滚，与边界的重画

Case 3 · An over-privileged agent: the breach, the rollback, and the redrawn boundary

为了"省事"，一支团队给一个负责清理过期数据的定时 agent 配了生产库的读写全权账号——理由是"它偶尔也要改几条状态位"。某夜，agent 在生成清理 SQL 时把一个 WHERE created_at < ? 的占位符填成了空值（上下文里那个变量被一段无关的对话腐化掉了，见 ENG·09 的上下文腐化 context rot），生成了一条等价于全表删除的语句；因为它有全权，直接执行了。没有任何结构在它和生产数据之间。

To “save effort,” a team gave a scheduled agent that cleans expired data a full read-write production credential: the rationale being “it occasionally flips a few status bits too.” One night, generating cleanup SQL, the agent filled a WHERE created_at < ? placeholder with null (the variable had rotted in context behind an unrelated exchange, the context rot of ENG·09), produced a statement equivalent to a full-table delete, and, because it held full privilege, executed it directly. Nothing structural stood between it and production data.

回滚与重画：事故当晚靠数据库的时间点恢复（PITR）回滚了四十分钟的数据，丢了少量在窗口内的写入。事后没有人去"骂模型不靠谱"——这没意义，会猜的系统本就会偶尔猜错。修复是重画边界：清理 agent 的账号降为只读，它需要改的那几条状态位走一个独立的、带显式确认门的窄接口；任何 DELETE / 全表级操作进入"必须人确认"档。这把一个事后追责问题，变成了一个结构问题。〔最小权限 / 写操作设确认门 / MCP 安全边界源 Anthropic MCP 规范与安全指引〔R6〕；PITR 为数据库标准恢复机制〕

Rollback and redraw: that night a point-in-time recovery (PITR) rolled back forty minutes of data, losing the few writes inside the window. Afterward nobody set out to “blame the unreliable model”: that is pointless; a guessing system will occasionally guess wrong. The real fix was to redraw the boundary: the cleanup agent’s credential dropped to read-only, the few status bits it needs to change go through a separate narrow interface with an explicit confirmation gate, and any DELETE / whole-table operation enters the “human must confirm” tier. This turns a post-hoc accountability problem into a structural one. [Least privilege / writes behind a confirmation gate / MCP security boundary from the Anthropic MCP specification and security guidance [R6]; PITR is a standard database recovery mechanism.]

留给人的那一道判断：哪些操作属于"不可逆 × 高爆炸半径"、必须设确认门。这不是模型能替你回答的。它取决于这份数据丢了赔多少、这家公司对停机的容忍度、这条接缝背后的合规约束。这正是分档计算器（INSTRUMENT 07）里 OWN 那一档：这类判断只有人能定、也只有人能持有。

The kept judgment: which operations belong to “irreversible x high blast radius” and must sit behind a confirmation gate. A model cannot answer this for you: it depends on what losing this data costs, this company’s tolerance for downtime, the compliance constraints behind the seam. This is precisely the OWN tier in the Delegation-Tier Calculator (INSTRUMENT 07): constitutive judgment, holdable only by a human.

案例四 · 一条 eval，怎样把一次性的踩坑变成组织的记忆

Case 4 · One eval, and how a one-time stumble became the organization’s memory

一个内容生成功能反复出同一类问题：模型在给非英语用户生成界面文案时，偶尔把中文标点（如全角逗号）混进英文串里，肉眼难查，QA 每隔几周抓出一次，改一次，下次又来。这是典型的"靠人当一次性劳动去补结构漏洞"——每抓一次的成本固定，抓的次数随产能上升而上升，永远追不上。

A content-generation feature kept producing the same class of problem: when generating UI copy for non-English users, the model occasionally mixed Chinese punctuation (a full-width comma, say) into English strings, hard to spot by eye. QA caught it once every few weeks, fixed it once, and next time it returned. This is the classic “use a human as one-time labor to patch a structural hole”: each catch costs a fixed amount, the number of catches rises with capacity, and it never catches up.

这正是"评测套件是组织沉淀下来的判断"（ENG·12）的微观一幕。关键不在那条正则有多巧，在于发生了一次状态转变：判断从"住在某个 QA 的脑子里、每次重新调用"变成了"住在套件里、自动复用"。eval 套件因此是会复利的资产。它拦下的回归次数 = 每天跑的遍数 × 每遍挡下的潜在回归，这个数随团队产能上升而上升，而成本几乎为零。这与靠人手补漏的曲线正好相反：那条曲线的成本随产能线性上升，收益却不积累。

This is the micro-scene of “the eval suite is the organization’s accumulated judgment” (ENG·12). What matters is not how clever the regex is but that a state change happened: the judgment moved from “living in one QA’s head, re-invoked each time” to “living in the suite, reused automatically.” The eval suite is therefore a compounding asset: the regressions it blocks equal runs-per-day times potential-regressions-caught-per-run, a number that rises with team capacity at near-zero cost. This is the exact inverse of the patch-by-hand curve, whose cost rises linearly with capacity while its benefit never accrues.

留给人的那一道判断："什么算对"这条标准本身——是人某次发现"英文界面混进中文标点很丢人"之后做的判断。机器能廉价地、确定地执行这条标准一百万遍，但它不会替你设立这条标准；标准从来是人的品味与上下文的产物。所以这条 eval 的价值不在自动化本身，在它把一次稀缺的人类判断放大成了无限次廉价的机器执行。〔"eval 即沉淀判断 / 验证基础设施是最大投资方向"源本系列验证篇综合，证据级 Ⅳ〕

The kept judgment: the standard of “what counts as correct” itself: a judgment a human made after once noticing “Chinese punctuation leaking into an English UI looks bad.” A machine can cheaply and deterministically enforce that standard a million times, but it will not set the standard for you; the standard is always a product of human taste and context. So this eval’s value is not in automation per se but in how it amplified one scarce human judgment into unbounded cheap machine enforcement. [The eval-as-accumulated-judgment / verification-infrastructure-as-the-largest-investment claim is from this series’ Verification synthesis, grade Ⅳ.]

① 瀑布与"大设计先行"（BDUF）——规划视野的赌注下错了地方

① Waterfall and big-design-up-front (BDUF) — the planning-horizon bet placed in the wrong era

先说一个常被忘记的事实：Royce 1970 那篇被奉为瀑布起源的论文，其实是在警告单趟顺序模型有内在风险，并主张至少迭代两遍。后世把一张"反面教材"图当成了圣经〔R9〕。把它放一边，看机制本身：BDUF 把大量判断前置到信息最少的时刻（项目开端），赌的是"早期规划的价值大于计划过期的损失"。这个赌注在执行稀缺时常常成立，因为既然落地要几个月，早想清楚就能省下返工。但执行一旦变充裕，落地从几个月坍缩到几小时，计划的保鲜期比落地周期还短：你花三周写的详尽设计，在 agent 三天就能试错完五个方案的世界里，落地前就过期了（见 ENG·10 规划视野坍缩）。所以 BDUF 不是"做得不够细"，是赌错了时代。它把判断花在了信息最少、且最快过期的那一刻。

First, a fact often forgotten: Royce’s 1970 paper, revered as waterfall’s origin, actually warned that the single-pass sequential model carried inherent risk and argued for iterating at least twice; posterity took a “cautionary diagram” as scripture [R9]. Set that aside and look at the mechanism: BDUF front-loads a mass of judgment to the moment of least information (project start), betting that “the value of early planning > the loss from plans expiring.” That bet often held under scarce execution: if shipping takes months, thinking it through early saves rework. But once execution is abundant, shipping collapses from months to hours, and the plan’s shelf life is shorter than the build cycle: the detailed design you spent three weeks on expires before it lands, in a world where an agent can trial-and-error five approaches in three days (see ENG·10, the collapsing planning horizon). BDUF is not “insufficiently detailed”: it bet on the wrong era, spending judgment at the moment of least information and fastest expiry.

② 代码评审当守门：批量、排队，与逐行读 diff 的注意力破产

② Code review as gatekeeping — batches, queues, and the attention bankruptcy of reading diffs line by line

把"高级工程师逐行读完每个 PR"当成质量的唯一闸门，在产出量小的时候是有效的，因为人读得过来。机制在产出量放大后断裂：当 agent 队伍一天产出五十个 PR，那道"必须有人逐行读完"的门立刻变成排队系统里的单点瓶颈。排队论说得很清楚：到达率逼近处理率时，排队时间会非线性爆炸（Reinertsen《产品开发流的原则》论批量与队列）〔R10〕。结果只有两条，都坏：要么 PR 堆积、交付被这道门拖死；要么评审者为了清队列开始"橡皮图章"，逐行读退化成扫一眼点通过——门还在，但已不挡任何东西。更深的问题是：逐行读 diff 检验的是"代码长什么样"，而 agent 时代真正该守的是"测试有没有锁住意图、边界对不对、接缝合不合理"。把稀缺的高级判断耗在读语法上，等于把人放回了被放大的执行里。

Treating “a senior engineer reads every PR line by line” as the sole quality gate works when output is small: a human can keep up. The mechanism breaks once output is amplified: when an agent fleet ships fifty PRs a day, the “a human must read every line” gate instantly becomes a single-point bottleneck in a queue. Queueing theory is blunt about this: as arrival rate approaches service rate, queue time explodes non-linearly (Reinertsen, The Principles of Product Development Flow, on batch size and queues) [R10]. Two outcomes follow: either PRs pile up and delivery dies at this gate, or reviewers start rubber-stamping to clear the queue, and line-by-line reading degrades into a glance-and-approve: the gate stands but blocks nothing. The deeper problem: reading diffs line by line checks “what the code looks like,” whereas the thing actually worth guarding in the agent era is “do the tests lock the intent, are the boundaries right, do the seams make sense.” Spending scarce senior judgment on reading syntax puts the human back inside the amplified execution.

是改评审的对象，不是取消评审。把门从"逐行读产物"移到"审规格与接缝"：评审 diff 而不评审产物、以测试为目标交办（见 ENG·06），让独立验证器和 eval 去守语法与回归，人只在被结构标红处接管。这不是降低标准，是把同一份注意力投到它唯一不可替代的地方。

The fix is not abolishing review but changing what it reviews. Move the gate from “read the artifact line by line” to “review the spec and the seams”. Review the diff not the artifact, delegate toward a test (see ENG·06), let independent verifiers and evals guard syntax and regressions, and have the human take over only where the structure flags red. This invests the same attention where it is irreplaceable, not lowering the bar.

③ QA 当事后工序——把验证从产线末端搬回每一个节点

③ QA as an afterthought — moving verification from the line’s end back into every node

"先让开发把功能堆完，再交给 QA 在末端集中测"是流水线思维的产物：验证被当成一道独立的、靠后的工序。这在执行稀缺时尚可忍受，因为产出慢，末端积压的待测量也小。执行充裕后这条假设直接崩塌：产线前端（生成）的吞吐涨了一个数量级，末端那道人力 QA 工序的吞吐没涨，中间的在制品（未验证代码）就爆炸式堆积。更致命的是案例一的雪球机制：一个早期未验证的错误会被后续每一步当作既定前提放大，所以把验证拖到末端，等于让错误在被发现前先滚二十步，而越往后纠错越贵。

“Let developers pile up features first, then hand off to QA to test in bulk at the end” is a product-line mindset: verification is a separate, late station. This was tolerable under scarce execution: output was slow and the backlog at the end was small. Under abundant execution the assumption collapses outright: the front of the line (generation) gains an order of magnitude of throughput, the human-QA station at the end does not, and the work-in-progress between them (unverified code) piles up explosively. Worse is Case 1’s snowball: an early unverified error gets amplified as a settled premise by every later step; deferring verification to the end lets the error roll twenty steps before discovery, and the later you correct, the more it costs.

机制上的修复是把验证从"末端工序"改成"每个节点的内建检查点"，这正是失败学那张双曲线图的论点（ENG·09）：有检查点的轨迹趁错小就拦回近零，没检查点的则指数放大成雪球。QA 不该是产线末端的一个部门，该是织进每个循环的独立验证器。质量是每一步锁住意图锁出来的，不是末端检出来的。

The mechanical fix is to change verification from an “end station” to a “built-in checkpoint at every node”: exactly the argument of the failure section’s twin-curve figure (ENG·09): the checkpointed trajectory resets the error to near zero while it is small, the un-checkpointed one amplifies exponentially into a snowball. QA should not be a department at the end of the line but an independent verifier woven into each loop. Quality is locked in, intent by intent, at every step, not inspected in at the end.

④ "10x 工程师"神话。它量错了对象，而那个对象正在被廉价化

④ The “10x engineer” myth — it measured the wrong thing, and that thing is now being made cheap

"10x 工程师"的说法可以一直追到 Sackman、Erikson、Grant 1968 那项实验：他们发现程序员之间编码时间差到约 20:1、调试时间差到约 25:1，但同一份数据里还有一条常被略去的发现——个人产出与经验年限无关〔R8〕。这个神话有两个结构性毛病。其一，它在方法上一直可疑（把汇编与高级语言的被试混在一起统计）；后世研究虽反复确认"量级差异存在"，但把它人格化成"存在一种 10 倍的天才个体"是过度解读。其二、也更要命：它当年量的"快"主要是个体的实现/打字吞吐，而这恰恰是 agentic coding 今天正在廉价化、去稀缺化的那一项能力。

The “10x engineer” phrase traces all the way back to the 1968 experiment by Sackman, Erikson, and Grant: they found coding-time differences between programmers of about 20:1 and debugging-time differences of about 25:1, but the same data carried a finding often dropped: individual output had no relationship to years of experience [R8]. The myth has two structural defects. First, it was always methodologically suspect (it pooled assembly and high-level-language subjects), and while later studies repeatedly confirm that “order-of-magnitude differences exist,” personifying that into “there exists a 10x genius individual” is over-reading. Second, and more fatal: the “fast” it measured back then was mainly individual implementation / typing throughput: precisely the capability that agentic coding is now making cheap and un-scarce.

机制：当瓶颈从"打字快"移开，"打字快 10 倍的人"这个优势项就贬值了。放大效应今天落在另一处：能把判断、品味、上下文与边界拿捏到位的人，通过指挥一支 agent 队伍，产出可以是十倍、百倍。但这是内核第②步的故事，而非 1968 年那个"个体英雄"的故事——稀缺的不再是谁打字快，是谁的判断对。所以继续招聘、考核、神化"10x 个体的实现速度"，等于在为一个正在消失的瓶颈优化。

Mechanism: once the bottleneck moves off “types fast,” the advantage of “the person who types 10x faster” depreciates. The amplification now lands elsewhere: a person who can get judgment, taste, context, and boundaries right can, by directing an agent fleet, produce ten or a hundred times the output. But this is no longer the 1968 “individual hero” story; it is the story of kernel step ②: what is scarce is no longer who types fast but whose judgment is right. To keep hiring, grading, and mythologizing “the 10x individual’s implementation speed” is to optimize for a vanishing bottleneck.

⑤ 工单工厂——把工程师当吞吐单元，正好优化掉了唯一还稀缺的东西

⑤ The ticket factory — treating engineers as throughput units optimizes away the one thing still scarce

工单工厂式团队把工程组织成一条流水线：需求拆成颗粒度均匀的工单，工程师是可互换的吞吐单元，绩效等于单位时间关掉的工单数。这套结构服务的是"执行稀缺、产出量是瓶颈"的世界，在那里最大化人均代码吞吐确实合理。问题在于：它系统性地优化掉了在 AI 充裕下唯一还稀缺的东西。把人当吞吐单元，意味着不奖励、甚至惩罚那些"慢下来想清楚什么算对""花时间画对一道接缝""停下来质疑这个工单本身要不要做"的行为，而这些恰恰是 agent 替不了、且正在变成全部价值所在的判断节点。

A ticket-factory team organizes engineering as an assembly line: requirements split into uniformly grained tickets, engineers as interchangeable throughput units, performance measured as tickets closed per unit time. This structure serves a world of “scarce execution, output as the bottleneck”: maximizing per-head code throughput is genuinely reasonable there. The problem: it systematically optimizes away the one thing still scarce under AI abundance. Treating people as throughput units means not rewarding, even penalizing, certain behaviors. It fails to reward “slowing down to get clear on what counts as correct,” “spending time to draw a seam right,” or “stopping to question whether this ticket should be built at all”. These are exactly the judgment nodes an agent cannot replace, and are becoming where all the value sits.

机制：你考核什么，就得到什么。用关单速度考核，得到的是更快地生成更多"看起来完成了"的代码，以及一支没人对整体负责、没人持有那类由人来定的判断的队伍。当执行变得几乎免费，"更快关更多单"的边际价值趋零，而"这单到底该不该做、做对了没"的判断变成了全部。所以工单工厂不是被 agent 取代，是被自己的考核函数掏空了。它奖励的那一项，正是 agent 现在白送的。

Mechanism: you get what you measure. Grade on ticket-closing speed and you get faster generation of more “looks-done” code, and a team where nobody owns the whole and nobody holds the constitutive judgment. When execution becomes nearly free, the marginal value of “close more tickets faster” trends to zero, while the judgment of “should this ticket be built at all, and was it built right” becomes everything. The ticket factory is hollowed out by its own scoring function, not replaced by the agent: the very thing it rewards is what the agent now gives away for free.

⑥ 每一步都人工审批——把人海塞回放大了一万倍的执行洪流里

⑥ Manual approval at every step — pouring a crowd of humans back into a flood of execution amplified ten-thousandfold

"每个变更、每次部署、每条命令都要人点确认"是用审批密度换安全感的旧反射。它的隐含模型是"变更很少，所以每个都值得人看一眼"。执行充裕把这个前提炸了：当 agent 一天发起一万次操作，"每一步都人审"在算术上就不可能——不怪人不够勤奋，是吞吐量差了三四个数量级。强行维持的结果只有两条，都坏：要么审批成为吞吐瓶颈，把 AI 的全部速度优势抵消干净（你买了辆跑车却规定每过一个路口都要下车推）；要么人为了跟上而进入"无脑点同意"模式——审批框还在弹，但已经没有任何判断发生，纯粹是仪式。这又一次撞上自动化的反讽：绝大多数操作都没问题，人的警觉性在第一千次点同意时早已归零，恰在第一万零一次那个真该拦下的操作上，人照样点了同意。

“Every change, every deploy, every command needs a human to click confirm” is the old reflex of trading approval density for a sense of safety. Its implicit model is “changes are rare, so each is worth a human glance.” Abundant execution detonates that premise: when an agent initiates ten thousand operations a day, “a human reviews every step” is arithmetically impossible, not for lack of diligence but because throughput is off by three or four orders of magnitude. Forcing it yields only two outcomes, both bad: either approval becomes the throughput bottleneck and cancels out all of AI’s speed (you bought a sports car but mandated getting out to push it through every intersection), or the human, to keep up, enters “mindlessly click approve” mode. The dialog still pops but no judgment happens, it is pure ritual. This again hits the irony of automation: the vast majority of operations are fine, the human’s vigilance hit zero around the thousandth approval, and on the ten-thousand-and-first (the one that truly should be stopped) the human clicks approve all the same.

机制上的修复是从"密度"切到"分级"：按可逆性 × 爆炸半径分档（正是 INSTRUMENT 07 做的）。低半径、易回退的操作完全交给结构（类型/测试/lint）、不打扰人；只有不可逆 × 高半径那一档才设显式确认门。这把人的稀缺确认从"每一步都点、点到麻木"重新聚焦到"一年只点几次、但每次都真的在判断"。审批不是越多越安全，因为审批密度过高反而通过警觉性衰减制造了不安全。安全来自把人放在对的那几个节点，而不是放在所有节点。

The mechanical fix is to switch from “density” to “tiering”: grade by reversibility x blast radius (exactly what INSTRUMENT 07 does): low-radius, easily-reverted operations are handed fully to structure (types / tests / lint) and never bother a human; only the irreversible x high-radius tier gets an explicit confirmation gate. This refocuses the human’s scarce confirmation from “click every step into numbness” to “click a few times a year, but actually judging each time.” More approval is not more safe: excessive approval density manufactures unsafety through vigilance decay. Safety comes from putting the human at the right few nodes, not at all nodes.

先钉一个量过的锚：能力涨，体感骗人

First, an anchor that was measured: capability rises, the felt sense lies

推演要诚实，得先承认一个被实测反驳过的事实。2025 年 METR 做了一项随机对照试验：让 16 名资深开源开发者在自己熟悉的成熟仓库上完成 246 个真实任务，随机分成"允许用 AI 工具"与"不许用"两组。结果与几乎所有人的预期相反——用 AI 那组平均慢了约 19%，而开发者自己事前预计会快 24%、事后仍以为快了约 20%。也就是说，在一类特定场景（资深者 × 高度熟悉的大型代码库）里，当下这代工具实际拖慢了人，却制造出"我更快了"的强烈错觉。这一条不削弱本卷的命题，反而是它最锋利的脚注：生成变快 ≠ 交付变快，省下的打字时间会被找回、读懂、纠正生成物的判断时间吃掉——除非把判断也搬到验证基础设施里。把这条放在未来推演开头，是为了让后面所有"会更快、会更强"的外推都带着这条体感校正阅读。〔源 METR 2025《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》，随机对照试验，证据级 Ⅱ 受控实测；单项研究、特定人群与仓库，尚未广泛复现，故不外推到全部场景[R7]〕

For speculation to stay honest, it must first own a fact that got slapped down by measurement. In 2025 METR ran a randomized controlled trial: 16 experienced open-source developers completed 246 real tasks on repositories they knew well, randomized into “allowed to use AI tools” versus “not allowed.” The result ran against almost everyone’s expectation: the AI group was on average about 19% slower, while the developers had forecast a 24% speedup beforehand and still believed they had been about 20% faster afterward. In one specific setting (experienced developers × large, highly familiar codebases), this generation of tools actually slowed people down while manufacturing a strong illusion of “I am faster.” This does not weaken the volume’s thesis; it is its sharpest footnote: faster generation ≠ faster delivery, and the typing time saved is eaten by the judgment time of finding, reading, and correcting the generated output: unless that judgment is also moved into verification infrastructure. Nailing this at the top of the speculation act forces every downstream “will be faster, will be stronger” extrapolation to be read with this felt-sense correction attached. [Source: METR 2025, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” randomized controlled trial, grade Ⅱ controlled measurement; a single study on a specific population and codebase type, not yet widely replicated, so not extrapolated to all settings. [R7]]

三条正在汇流的曲线Three Converging Curves

Three Converging Curves

AI-Native 工程的未来不止是"模型更聪明"。它背后是三条独立成熟、正在汇流的曲线。每一条松动一组今天的约束，三条叠加决定了推演空间的边界。给每条都附一个证伪条件：若该观测出现，这条曲线就停在原地，本章对应的外推作废。

The future of AI-Native engineering is more than “models getting smarter.” Behind it are three curves maturing independently and now converging: each loosening one set of today’s constraints; their superposition sets the boundary of the speculation space. Each carries a falsification condition: if that observation appears, the curve stalls and this chapter’s corresponding extrapolation is void.

沿这三条曲线推的时间轴A Timeline Along Those Curves

A Timeline Along Those Curves

来自那些年份的两件文物Two Artifacts from Those Years

Two Artifacts from Those Years

推演若只有论断会显得抽象。下面两件是 design fiction——明确虚构的未来文物，用来让"判断密度的工程师"这个抽象命题可触。它们不是预测，是把内核投影到 2032，做成你能拿在手里翻看的东西。

Speculation made only of assertions would feel abstract. The two pieces below are design fiction: explicitly fictional future artifacts that make the abstract claim “an engineer measured by judgment density” touchable. They are not predictions; they project the kernel onto 2032 as something you can hold and leaf through.

本卷记下对自己的反向赌注The Counter-Bet, on the Record

The Counter-Bet, on the Record

诚实的推演要把反对自己的最强论点也记下来。本卷的命题是：执行变充裕、判断退守到验证，于是验证基础设施成为最大投入方向、工程师价值上移到判断。反向赌注用两步反驳它。

第一步，这套"判断上移"的图景，可能只是一类特定工作的局部真相，而非工程的普遍走向。它最成立的场景是资深者、成熟代码库、判断本就稀缺的那一类。METR 那条实测已经露了口子：在那个场景里，当下工具不仅没让人更快，还制造了"更快"的错觉。若这种"体感快、实则慢"在更多场景里也成立，那么"判断退守、验证补位"可能根本来不及发生——团队会先被一波看起来高效、实则注入海量未验证债务的生成淹没，在验证墙长高之前就崩盘。

第二步更尖锐：也许瓶颈从来是"判断稀缺"，而非"执行稀缺"，而 AI 恰好不放大判断、只放大执行。果真如此，本卷"把判断带宽重新投到验证"的处方，对一个判断本就不足的团队就是一张空头支票，因为它们缺的正是开出这张支票所需的判断。

这个反向赌注怎样被证实：若三五年后，采用 agentic 编码最激进的团队，其线上事故率、返工率、技术债指标系统性地高于克制使用的团队，且差距不随"补验证"而收敛，那么是本卷错了，不是它们错了。把这条写在这里，是因为一个不敢记录自己证伪条件的方法论，不配被照着做。〔源 反向论点综合：METR 2025 RCT（证据级 Ⅱ）+ "判断稀缺而非执行稀缺"的对立假设（证据级 Ⅴ 推论）[R7]〕

Honest speculation records the strongest argument against itself too. This volume’s thesis: execution becomes abundant, judgment retreats to verification, so verification infrastructure becomes the largest investment direction and the engineer’s value climbs to judgment. The counter-bet rebuts it in two steps.

Step one: this “judgment climbs” picture may be only a local truth of one specific kind of work, not the general direction of engineering. It holds best for experienced people, mature codebases, and work where judgment was already scarce. The METR measurement already shows the crack: in that setting, current tools not only failed to make people faster but manufactured the illusion of “faster.” If this “felt-fast, actually-slow” holds across more settings, then “judgment retreats, verification fills in” may never get the chance to happen: teams will first be drowned by a wave of generation that looks efficient but injects mountains of unverified debt, collapsing before the verification wall has grown tall.

Step two is sharper: perhaps the bottleneck was never “execution is scarce” but “judgment is scarce,” and AI happens to amplify execution, not judgment. If so, this volume’s prescription to “reinvest judgment bandwidth into verification” is a bad check to a team that was short on judgment to begin with, because what they lack is exactly the judgment needed to write that check.

How this counter-bet gets confirmed: if, in three to five years, the teams most aggressive in adopting agentic coding show systematically higher production-incident rates, rework rates, and tech-debt metrics than restrained teams. And if the gap does not converge as they “add verification,” then the volume is wrong, not them. It is written here because a methodology that dares not record its own falsification condition does not deserve to be followed. [Source: counter-argument synthesis: the METR 2025 RCT (grade Ⅱ) plus the rival hypothesis that judgment, not execution, is the scarce factor (grade Ⅴ inference). [R7]]

读这一幕的方式How to Read This Act

How to Read This Act

不要把这一幕当路线图照搬，把它当一张带刻度的赌桌：三条曲线是赌注，每条都标了"什么观测会让我认输"。你能做的，是盯住那几个先行指标：推理单价的斜率、harness 协议是收敛还是碎裂、你自己团队里"被自动复检的改动占比"是涨是停。用它们校准自己站在那道阶梯的哪一桩上，而不是听任体感替你判断。这一幕唯一确定的事，是它会被改写；本卷愿意第一个改它。

Do not copy this act as a roadmap; treat it as a betting table with a scale on it: the three curves are wagers, each labeled with “what observation makes me concede.” What you can do is watch those few leading indicators (the slope of inference unit price, whether harness protocols converge or fracture, whether your own team’s “share of changes that get auto-rechecked” rises or stalls) and use them to calibrate which stake of the staircase you stand on, rather than letting the felt sense judge for you. The only certain thing about this act is that it will be rewritten; this volume volunteers to be the first to rewrite it.

五条贯穿原理：从可读到自改进，是一条依赖链

Five through-lines: from legibility to self-improvement, one dependency chain

• 对 agent 可读（legibility）· 可 diff 可版本可审（diffable）· 机器可检验的规格（machine-checkable spec）· 可组合的能力接口（composable）· 会自我改进的循环（self-improving loop）+ 人机同源。
• legible to agents · diffable / versionable / reviewable · machine-checkable specs · composable capability interfaces · self-improving loops + one shared source.

这五条不是并列的口号，它们之间有依赖顺序，连起来就是前面所有章节的压缩。可读是地基——agent 读不懂的东西，后面四条都无从谈起（ENG·02）。在可读之上，可 diff / 可版本 / 可审把"改动"变成可评审的提交而非不可追溯的覆盖（ENG·02 / 06）。再上一层，机器可检验的规格给生成一个目标函数，让对错能自动收敛（ENG·03 / 07）。可组合的能力接口（skills / MCP / CLI）让 agent 能安全地扩展自己的触达范围，且每个接口都被单独授权（ENG·04 / 08）。最后，会自我改进的循环把前四条缝成一个随产出复利的系统（ENG·04 / 05）。贯穿五条的是同一句话：人和 agent 读写同一份源。认得这五条，下一个 Markdown、下一个 TypeScript 出现时，你不用追工具新闻，用同一把尺就能判断它会不会被放大。

These five are not parallel slogans; they have a dependency order, and chained together they are the compression of every section above. Legibility is the foundation: what an agent cannot read makes the other four moot (ENG·02). On top of it, diffable / versionable / reviewable turns a change into a reviewable commit rather than an untraceable overwrite (ENG·02 / 06). A layer up, machine-checkable specs give generation an objective function so correctness can converge on its own (ENG·03 / 07). Composable capability interfaces (skills / MCP / CLI) let the agent safely extend its reach, each interface authorized separately (ENG·04 / 08). Finally, self-improving loops stitch the first four into a system that compounds with output (ENG·04 / 05). Running through all five is one line: humans and agents read and write the one source. Recognize these five and you need not chase tool news: when the next Markdown or the next TypeScript appears, the same ruler tells you whether it will be amplified.

三原则 + 三指标：每个指标都带一条反指标

Three principles + three metrics — each metric carries a counter-signal

三个指标都带一条反指标，因为指标会被玩坏。上手爬坡时间↓是真信号——上下文成了基础设施，新人第一周就能交付；但若靠降低交付标准来缩短爬坡，那是把指标做漂亮、把质量做没了。PR 周期↓暴露管线短板，但若靠绕过评审门来提速，等于拆了承重墙。"Claude 提交占比↑"最危险：它极易被当成成功的代名词，但吞吐不是成功——生成一万行没人需要、没人验证的代码，比写一百行对的代码更糟。所以每个指标的读法是"它在不在以正确的方式上升"，而不是"它有没有上升"。

Each of the three metrics carries a counter-signal, because metrics get gamed. Ramp-time↓ is a true signal: when context is infrastructure, a newcomer ships in week one; but shortening the ramp by lowering the delivery bar makes the metric pretty and the quality gone. PR-cycle↓ surfaces pipeline strain, but speeding it up by bypassing the review gate is tearing out a load-bearing wall. “Claude-commit share↑” is the most dangerous: it is easily taken as a synonym for success, but throughput is not success: generating ten thousand lines no one needs and no one verified is worse than writing a hundred correct ones. So the real reading of each metric is “is it rising the right way,” not “is it rising.”

最后，把这一卷倒过来读。前面十二节都在回答"怎么造"——可读、可验、可组合、自改进。但和组织卷一样，在"怎么造"之前有一个更先的问题："为何造"。效率四百年来被默认成目标本身；AI 第一次让效率变充裕，于是不必再把效率本身当成终点。若把验证、规格、harness 优化到极致，却让工程师沦为给生成流水线点"通过"的人肉橡皮图章，那只是把工程带回了吞吐逻辑。这一卷的全部技术，是为了把人从打字和吞吐里解放出来，回到只有人能做、也值得人去做的判断与建造：决定该造什么、何为对、接缝放哪。把可验证性做到极致，正是为了让工程师回到工程师真正该做的判断：决定该造什么、何为对、接缝放哪。

Finally, read this volume in reverse. The twelve sections above all answer “how to build”: legible, verifiable, composable, self-improving. But as in the organization volume, before “how to build” sits an earlier question: “what to build it for.” For four centuries efficiency was assumed to be the goal itself; AI makes efficiency abundant for the first time, so it need no longer be treated as the goal at all. If verification, specs, and the harness are optimized to the limit while the engineer is reduced to a human rubber stamp clicking “approve” on a generation pipeline, engineering has merely been pulled back into throughput logic. The entire technique of this volume exists to free people from typing and throughput and return them to the judgment and building only people can do and that is worth doing: deciding what to build, what is correct, where the seams go. Pushing verifiability to the limit is in service of returning the engineer to the judgment that is actually theirs: deciding what to build, what is correct, where the seams go.

深潜章

Deep-dive chapters

五条原理与新增四节的关系

How the five through-lines relate to the four new sections

把这一卷新增的四节放回那五条贯穿原理里，会看到它们是五条原理在更具体处的展开，并非新增的并列条目。这本身就是检验这卷是否自洽的一道内部一致性测验——新增四节各自把那条主干上某一节点的机制讲深了：

• 失败学（ENG·09）是"机器可检验的规格"和"会自我改进的循环"的因：它讲清了为何非验不可，给前面所有"怎么验"提供了失败学底座。
• The failure taxonomy (ENG·09) is the cause behind “machine-checkable specs” and “self-improving loops”: it makes clear why verification is non-optional and gives every earlier “how to verify” its failure-mode floor.
• 即时规划（ENG·10）是"会自我改进的循环"在时间维度上的纪律：它把"凭信号迭代"从一种态度落成可证伪的规划方式。
• JIT planning (ENG·10) is the “self-improving loop” disciplined on the time dimension: it lands “iterate on signal” from an attitude into a falsifiable way to plan.
• 信任边界（ENG·11）是"可组合的能力接口"的安全面：它说明了为何每个接口要单独授权，否则可组合就成了可失控。
• The trust boundary (ENG·11) is the security face of “composable capability interfaces”: it shows why each interface must be authorized alone, or composable becomes uncontrolled.
• evals 承重墙（ENG·12）解释了"会自我改进的循环"为何能立住：它讲清了这堵墙怎么垒、为何会复利。
• The eval wall (ENG·12) explains why the “self-improving loop” holds up at all: it makes clear how the wall is laid up and why it compounds.

新增四节于是都挂在同一条主干上：可读 → 可 diff → 可机检 → 可组合 → 自改进。这正是这一卷区别于工具清单的地方——工具会过期，但"为何这五条会被放大、它们之间如何依赖、每一条在哪里最容易失败"这套原理不会。可证伪信号：若你能找到本卷中任何一节，它讲的机制无法被归到这五条原理之一、也不被它们解释，那说明要么那一节是游离的（该删或该接上），要么这五条原理本身不完备（该补）——这道自检本身就是这卷"承重命题可被证伪"的体现。

All four new sections thus hang on one trunk: legible → diffable → machine-checkable → composable → self-improving. This is exactly where the volume differs from a tool list: tools expire, but the principle of “why these five get amplified, how they depend on each other, and where each most easily fails” does not. Falsifiable signal: if you can find any section in this volume whose mechanism cannot be sorted to one of the five through-lines and is not explained by them. Then either that section is unmoored (delete it or wire it in) or the five principles are themselves incomplete (add one). This self-check is itself the volume’s load-bearing claim being falsifiable.

可执行配套 · skill

The executable companion · skill

# 在 Claude Code 里调用invoke inside Claude Code
$ /skill ai-native-engineering
> "用 AI 把这个功能可靠地做出来：……""build this feature the AI-native way, reliably: ..."

  → 可运行代码 + SPEC.md（活规格）runnable code + SPEC.md (living spec)
  → eval / 验证套件an eval / verification suite
  → JUDGMENT.md（判断节点图）· PERMISSIONS.md（默认只读信任边界）JUDGMENT.md (judgment-node map) · PERMISSIONS.md (read-only-default trust boundary)