Foundations: Defining the AI-Native Paradigm

Foundations: Defining the AI-Native Paradigm

核心问题 / The Core Question

What does "AI-native" mean as a precise engineering category, and how does it differ from software that merely integrates an LLM API? This chapter refuses the marketing answer ("AI-native = uses AI") and instead proposes a four-layer stack and a five-level autonomy taxonomy that can be used to locate any product on a defensible engineering map. The taxonomy is not academic decoration; it is the spine that holds the remaining fourteen chapters together.

> 「AI-native」究竟是一个工程范畴，还是一句营销口号？本章将给出严格的工程定义，并以四层架构 + 五级自治谱系，为后续所有章节搭建坐标。

---

1. The AI-Native Premise: Why "Sprinkling AI" Is Not Enough

Almost every product team in 2024–2026 has shipped some form of "AI feature." A sidebar Copilot here, a summarize button there, a "magic" autofill in onboarding. From the outside, these products look AI-powered; from the inside, most of them are not. They are deterministic software products with an LLM API bolted on at the edges. We call this *AI-augmented* software, and it is structurally different from *AI-native* software in three ways: in input modality, in control flow, and in the unit of correctness.

> 2024–2026 年，几乎所有产品团队都上线过"AI 功能"——侧边栏 Copilot、摘要按钮、Onboarding 中的"魔法"自动填充。外表看似 AI 驱动，内核却仍是确定性软件加一个 LLM API。我们称这种为 *AI-augmented*（AI 增强型）软件，它在输入模态、控制流、正确性单元三个维度上与 *AI-native*（AI 原生）软件存在结构性差异。

1.1 Input Modality: From Structured Forms to Open Intent

Traditional software expects structured input. A form has fields; a database has schemas; a REST API has typed parameters. The user learns the grammar of the system, and the system responds to that grammar. The cost of this contract is rigidity: every new user intent requires a new field, a new endpoint, or a new button. The benefit is predictability: given the same input, the same output is produced, every time, bit-for-bit.

> 传统软件期待结构化输入：表单有字段、数据库有 schema、REST API 有强类型参数。用户学习系统的"语法"，系统按语法响应。代价是僵硬——任何新的用户意图都需要新增字段、接口或按钮。收益是可预测：相同输入产生相同输出，逐位一致。

AI-augmented software adds an LLM to this stack, but the contract rarely changes. The user still clicks a "summarize" button; the LLM just produces the summary. The input modality is the same; only the output channel has been upgraded. The LLM is a drop-in function call, not a first-class input surface.

> AI-augmented 软件只是在这种结构上加了一个 LLM，但契约几乎没有改变：用户依然点击"summarize"按钮，LLM 只是负责生成摘要。输入模态未变，被升级的只是输出通道。LLM 在此只是"可替换的函数调用"，而非一等输入面。

AI-native software inverts this relationship. Open-ended user intent — natural language, voice, gesture, image, an unfinished sentence — is the primary input modality. The system's job is to *resolve* intent into action, not to *constrain* intent into a fixed grammar. This inversion sounds subtle, but it cascades through every other layer of the architecture: data models become advisory, control flow becomes probabilistic, and the unit of correctness shifts from "did we produce the right byte?" to "did we produce a response the user can rely on?"

> AI-native 软件反转了这一关系。开放式的用户意图——自然语言、语音、图像、未完成的句子——成为一等输入。系统的工作不再是"约束意图到固定语法"，而是"将意图解析为行动"。这一反转听上去微妙，却会逐级向上渗透：数据模型退化为建议性，控制流成为概率性的，正确性单元从"是否产生正确的字节？"转为"是否产生用户可信赖的响应？"

1.2 Control Flow: From Branches to Plans

In AI-augmented software, control flow is still a finite state machine. The LLM is invoked from a known state, with a known prompt, and the result is funneled back into the next state. Branching is explicit; transitions are coded; failure is caught by try/except. This is comfortable for engineering teams because it preserves the mental model of imperative software: input → logic → output.

> 在 AI-augmented 软件中，控制流依然是有限状态机。LLM 在已知状态下被以已知 prompt 调用，结果回流到下一个状态。分支是显式的、迁移是编码的、失败由 try/except 兜底。这对工程团队非常友好——它保留了命令式软件的心智模型：输入 → 逻辑 → 输出。

In AI-native software, control flow is at least partially delegated to the model. The model plans a sequence of tool calls, decides when to ask a clarifying question, decides when to stop, and decides when to ask for human review. The engineer no longer writes a flowchart; the engineer writes the *space of possible plans* and the *guardrails* around them. The branches are now latent in a probability distribution, not explicit in code.

> 在 AI-native 软件中，控制流至少部分被委托给模型。模型规划工具调用序列、决定何时追问、决定何时停止、决定何时请求人工审核。工程师不再书写流程图，而是书写"可能规划的空间"及其护栏。分支不再显式存在于代码中，而是潜藏于概率分布里。

This is the shift that makes AI-native engineering a discipline of its own. You cannot debug a plan the way you debug a stack trace. You cannot test a policy the way you test a function. You need new tools — evaluations, traces, replay harnesses — and new vocabulary — agency, intent, affordance, supervision. We introduce this vocabulary throughout the rest of the book, but the key intuition for now is: *the locus of decision-making has moved from the developer to the model, and the developer's job is now to shape the environment in which the model decides.*

> 这正是 AI-native 工程成为独立学科的原因。规划不能像栈追踪一样被调试，策略不能像函数一样被测试。你需要新的工具——evaluations、traces、replay harness——以及新的词汇——agency、intent、affordance、supervision。本书其余部分都会逐步建立这套词汇。眼下最关键的直觉是：*决策的所在地已从开发者转移到模型，开发者的职责变成塑造模型做决策的环境*。

1.3 The Unit of Correctness: From Bytes to Outcomes

Traditional software is correct at the byte level. A function returns 7 or it does not; an HTTP response is 200 or 500; a database row matches or does not. The unit of test is a function or a service, and the unit of bug is a deviation from a specification.

> 传统软件在字节层面是正确的：函数返回 7 或者不返回；HTTP 响应是 200 或 500；数据库行匹配或不匹配。测试单元是函数或服务，缺陷单元是对规约的偏离。

AI-native software is correct at the outcome level. The model's output is a sequence of tokens, not a typed value, and the question "is this right?" is almost always a question about *meaning* and *usefulness*, not syntax. A summary can be technically accurate but useless; a research agent can take twenty correct steps and still produce a wrong conclusion; a coding agent can pass all unit tests and still miss the user's actual intent. The unit of correctness is the outcome the user experiences, and the unit of test is no longer a function but a *trajectory* — a path through tool calls, intermediate states, and final outputs.

> AI-native 软件在结果层面是正确的。模型的输出是 token 序列而非类型化值，"这是否正确"几乎总是关于*意义*与*效用*的判断，而非语法。摘要可以字面准确但毫无用处；研究 agent 可以走二十步都正确却得出错误结论；编程 agent 可以通过所有单测却未触及用户真正意图。正确性单元是用户感受到的结果，测试单元不再是函数，而是*轨迹*——经由工具调用、中间状态与最终输出的完整路径。

This is why evaluation (often abbreviated *evals*) becomes a first-class engineering concern in AI-native systems. We treat it in depth in Chapter 12, but flag it here: if you are not building evals, you are not building AI-native software; you are shipping an API call and hoping.

> 这就是 evaluation（常缩写为 *evals*）在 AI-native 系统中成为一等工程关切的原因。第 12 章会展开讨论，此处先标记：若你没有建立 evals，你做的就不是 AI-native 软件，而是一次 API 调用加一份祈祷。

The three shifts — input, control, correctness — together define the difference between AI-augmented and AI-native. They are not optional. A product can have an LLM API call and still be AI-augmented if the input is structured, the control flow is finite, and the correctness test is a function. A product is AI-native only when all three have shifted.

> 输入、控制、正确性这三处转变，共同界定了 AI-augmented 与 AI-native 的差异。这三条不是"可选项"。一个产品即使调用了 LLM API，若输入仍是结构化、控制流仍是有限、正确性测试仍是函数，那它依然是 AI-augmented。只有三处同时迁移，才是 AI-native。

---

2. The Four-Layer AI-Native Stack

To reason precisely about AI-native products, we need a stack. The classic three-tier web architecture — presentation, application, data — is no longer sufficient because it cannot express where reasoning lives, where plans are formed, or where trust is enforced. We propose a four-layer decomposition: the Model Layer, the Orchestration Layer, the Experience Layer, and the Governance Layer. Each layer has a clear responsibility, a clear interface to its neighbors, and a clear set of failure modes.

> 为了精确地讨论 AI-native 产品，我们需要一个架构。经典的 Web 三层架构——表现层、应用层、数据层——已经不够用了，因为它无法表达"推理在哪里发生、规划在哪里形成、信任在哪里被强制"。我们提出四层分解：Model Layer、Orchestration Layer、Experience Layer、Governance Layer。每层都有清晰的职责、与邻层的接口、特定的失效模式