AI 编码工具（如 Cursor、GitHub Copilot、Codex）已在研发团队中广泛普及，但编码仅占整个软件研发生命周期的 30% 左右。如果仅仅提升编码速度，不仅无法实现研发效能的质变，反而会造成“更快的瓶颈”：需求模糊导致返工更快、未验证决策堆积更快、局部正确而全局错误。

真正的 AI-Native 转型，核心在于从“人用 AI 提效（AI-Assistant）”走向“Human Directs, AI Delivers（人定方向，AI 交付）”，最终演进为以系统形态运行的 Agentic OS。本文结合近期团队在 AI 自动化流水线、Token 治理与知识库建设中的实战思考，梳理企业 AI-Native 转型的四级递进路径与落地关键。

一、 第一阶段：基建与契约 —— Token 治理与 Spec-Driven 交付

在转型的初期，大多数团队容易陷入“工具散乱、效果难衡量、成本不可控”的泥潭。要实现“人把控、AI 实现”的协同模式，首先必须打牢两块基石：Token 治理与 Spec-Driven 交付。

1.1 Token 治理：AI 化的基础设施

没有 Token 治理，就无法谈及规模化的 AI 落地。Token 治理不仅是成本控制手段，更是推进全员 AI 使用率与评估交付质量的指标中枢。

Token 治理的核心包含三个维度：

  • 使用率与渗透率：监控各团队/岗位的 Token 消耗与活跃度，识别阻碍 AI 普及的断点。

  • 交付质量与 ROI：将 Token 消耗与产出物（如代码提交、PR、文档、测试用例）关联，评估单位 Token 创造的业务价值。

  • 成本与限额管控：建立基于角色与任务的配额机制，防止无意义的 Prompt 试错与无限循环导致的 Token 浪费。

1.2 Spec-Driven 交付：人与 AI 的“数字合同”

在传统的研发流程中，需求往往通过口头沟通或模糊的文档传递。当执行主体由人类工程师转变为 AI 时，这种模糊性会导致严重的方向漂移。

Spec（规格说明书）是人与 AI 协作的“数字合同”，也是全链路的唯一锚点：

  • SDD（Spec-Driven Development）：在上游通过结构化 Spec 锁定意图。上游所有决策（产品、设计、架构）都服务于写好 Spec。

  • TDD（Test-Driven Development）：在下游作为验收机制。先根据 Spec 生成测试用例（Red），再生成代码实现（Green），最后进行验证（Verify）。

在 Spec-Driven 模式下，人类工程师的职责发生了根本性转变：从“直接编写和操作代码”转向“定义做什么和不做什么”。

二、 第二阶段：上下文与判断力 —— Agent Readable 与 DDD 知识治理

有了 Spec 之后，虽然消除了意图漂移，但 Agent 在执行时常常遇到“导航盲区”：不了解代码库历史、不懂业务逻辑、看不懂数据库字段含义。这就是“导航不解决判断”的天花板。第二阶段的核心任务是实现 Agent Readable 与 DDD 知识治理。

2.1 Agent Readable：让代码与数据对 AI 可读

要让 Agent 自主做出正确判断，必须将代码和企业数据改造为“AI 易读（Agent Readable）”的格式：

1) Code 的 Agent Readable：AI-Ready Repo

代码仓库必须显式提供上下文，让 AI 理解“项目为什么存在、怎么运行、踩过什么坑、当前处于什么状态”。建议在仓库中标准化以下四类文件：

  • PRODUCT.md：记录产品目标、业务优先级与成功标准。

  • TECH.md：记录技术架构、硬性约束（Blocking Constraints）与关键路径。

  • IMPROVEMENT.md：记录历史教训、避坑指南与踩坑反馈。

  • PROJECT.md：记录当前迭代状态、关键决策与阻塞项。

2) Data 的 Agent Readable：Agent for Data

直接将自然语言交给大模型生成 SQL（裸 NL2SQL）的准确率通常仅为 60%-70%，在生产环境中几乎不可用。其根本原因在于缺少“数据含义与访问权限”的语义合约。必须建立三层数据准确度模型：

  • Level 1: Certified Patterns（100% 准确）：预置经过验证的 SQL 模板，Agent 仅做参数替换与模板选择。适用于核心报表、合规推送。

  • Level 2: Guided NL2SQL（~95% 准确）：NL2SQL + Catalog 语义约束（白名单 + 强制过滤 + JOIN 映射规则）。适用于临时分析与自助探索。

  • Level 3: Unconstrained NL2SQL（60%-70% 准确）：无约束自由生成，仅建议作为探索参考。

2.2 DDD 知识治理：让领域知识“自己活着”

这里的 DDD 指的是 Domain-Driven Documentation（领域驱动文档），而非传统的 Domain-Driven Design。

传统知识库的最大问题是“维护税大于查询价值”——知识不断堆积，最终沦为噪声库。AI 时代的知识治理，核心竞争力不是“记住”，而是“遗忘”：

  • 达尔文衰减模式：知识被引用则强化（ref_count + 1）；90 天无引用进入休眠（Dormant）；180 天无引用自动归档死亡（Archived）。由衰减引擎每日自动执行，保持知识库的高精炼度。

  • 三条治理原则：

    • 自动生成：引擎从代码、数据与执行日志中自动提取，人类仅做审核补充。

    • 自动衰减：依靠系统机制剔除过时知识，无需定期人工 Review。

    • 自动复利：使用越多，知识网图越丰富，推荐越精准，形成知识飞轮。

三、 第三阶段：全流程自动化 —— Autonomous Pipeline 与双门检查

当代码与数据实现 Agent Readable、且领域知识具备自我演进能力后，研发流程便可迈入全自动化阶段：Autonomous Pipeline（自主流水线）。

3.1 10 阶段闭环流水线

Autonomous Pipeline 将编码视为黑盒（Coding as Black Box），实现“一句话需求 → PR-Ready”的闭环。其典型执行链路包含 10 个阶段：

1

EVALUATE → THINK → PLAN → PRE-CHECK → BUILD → REVIEW → TEST → ADVERSARIAL → DELIVER → REFLECT

3.2 双门架构（Double-Gate Architecture）

为确保全自动流水线不输出垃圾代码，系统引入了两个独立的 Sub-Agent 质量门：

  • Gate 1：做正确的事（编码前）

    • 由“怀疑者”角色（独立上下文 Sub-Agent）在 BUILD 之前挑战方案。
    • 检查方向对齐、约束违规及已知失败模式（IMPROVEMENT.md），在代码未写前拦截方向错误。

  • Gate 2：正确地做事（编码后）

    • 由“攻击者”角色（独立上下文 Sub-Agent）直接攻击 ChangeSet（只看 git diff，忽略 Builder 的主观意图）。
    • 针对正确性、安全性、集成度进行 30+ 项 Review Pattern 检查，发现隐蔽 Bug。

3.3 经济学视角：为什么 Gate 是“净负成本”？

有人担忧增加 Gate 1 和 Gate 2 会显著增加 Token 开销。但实践数据表明：

  • 无 Gate 模式：盲目生成代码（Vibe Coding），后期产生 2-3 次大型返工，单次 PR 综合消耗 460K~690K Tokens。

  • 双门 Gate 模式：编码前拦截错误、编码后精准收敛，1 次通过，单次 Run 消耗约为 255K Tokens。

结论：Gate 不是增加了成本，而是消除了“返工乘数”。Gate 在经济学上是净负成本项。

四、 第四阶段：终局形态 —— Agentic OS

AI-Native 转型的终局，是构建一套以系统形态自主运行的 Agentic OS。

4.1 Agentic OS 的三层解耦架构

Agentic OS 实现了“一层知识，多个执行引擎”的解耦架构：

  • 底盘（Harness / Runtime）：提供执行能力（Capability），包括运行环境、Tool/MCP 接入、调度器、Hook 与渠道适配器。底盘决定 Agent“能做什么”，但不决定“该做什么”。

  • 大脑（DDD Knowledge Layer）：提供判断力（Judgment），包含 4-Docs 领域知识、代码图谱、数据 Catalog 与演化反馈。

  • 手脚（AgentHub / Delivery Engines）：提供交付形态，面向不同业务场景导出 Agent 服务（如 CLI、IM 机器人、Web 交互终端）。

4.2 角色分工与系统级复利

在 Agentic OS 架构下，团队成员的分工实现了重塑：

  • AI 职能人员：专注于编写 Skill、MCP 接口以及沉淀领域知识，为系统补充“大脑”与“手脚”。

  • AgentHub：调度各种专有 Skill 与 Agent，基于 Runtime 机制为企业内外提供全自动化的 Agent 服务。

系统每运行一次，REFLECT 机制都会将错误教训与新经验写回知识层，使下一次执行更精准，真正实现“越用越聪明”的系统级复利。

五、 总结：避开“跳层”的陷阱

在推进 AI-Native 转型的过程中，切忌盲目跨越阶段：

  • 直接跨到 Autonomous Pipeline 而缺失 DDD：Agent 虽有强执行力，但处于“盲干”状态。

  • 有 DDD 但缺乏 Spec 纪律：知识丰富，但缺乏约束，导致“意图漂移”。

  • 有自主执行但缺乏反馈飞轮：第 300 天的交付质量依然和第 1 天一样。

从 Token 治理 到 Spec-Driven，再到 Agent Readable、Autonomous Pipeline，最终抵达 Agentic OS，这是一条清晰而严谨的工程演进之路。只有一步一个脚印搭建好知识与控制面，才能真正释放 AI 在企业级生产中的终极价值。