AI Native软件系统解读

导读：本文聚焦AI Native软件系统相关概念的解读，参考华为《AI-Native 技术与实践白皮书》、阿里云《AI 原生应用架构白皮书》，以及Anthropic、Salesforce、Microsoft、IBM、Scaled Agile等厂商的公开定义与实践，尝试系统性地回答：AI原生到底指什么、有哪些特征、与传统软件系统有何区别、价值何在。后续将分篇展开AI原生如何改变软件系统研发过程、AI原生的软件系统架构，以及个人与组织如何面向AI原生转型。

从2025年开始，软件行业出现了一个高频词汇：AI Native（后文统一称为：AI原生），围绕着它，多个厂商都发布了相关的技术白皮书。我个人的理解，AI原生描述的不是“在系统里用AI”，而是一场架构范式的重构与运行范式的转变。需要说明的是，本文的“系统”特指软件系统（Software System），即由若干软件及其支撑组件构成的整体，下文“系统”与“软件系统”同义交替使用。

架构范式回答系统如何组织：从本体建模、知识治理、智能体到模型底座，系统的构成与组织方式都变了；运行范式回答系统交付后如何运转与进化：从构建、发布、质量到运维，整套运行机制也发生了转变。

一、什么是AI原生

1.1 词源与演进

在给出定义之前，先回答一个经常被问起的问题：AI Native（AI原生）这个词从何而来？

AI原生并非由某一公开组织正式定义，也不是某个人或某家公司“发明”的术语。其构词普遍认为是Cloud Native（云原生）术语体系的类比延伸，由技术社区在不同语境中逐步使用，最终成为行业共识词。它的构词与流行轨迹，本身就是理解它含义的线索。

Cloud Native（云原生） 在2013–2015年随Docker、Kubernetes兴起，指“从设计之初就为云环境而生的应用”，而非把旧系统搬上云，CNCF在2018年给出正式定义时Kubernetes已经四岁。“Native”成为技术词汇里最成功的后缀模板之一——Mobile-Native、Digital-Native等相继流行，AI原生只是这套模板的最新一次复用，因此行业看到它时几乎没有认知障碍。

演进：从零星使用到行业共识。 这个词的使用经历了明显的阶段跃迁：

阶段	时间	标志性事件
萌芽期	2016年前后	域名ainative.com于2016-06注册，是最早可查证的“占位”痕迹，说明当时已有人在使用这一表述
潜伏期	2016–2022	多出现在基础设施与架构讨论中，指“内嵌AI的系统”，远未普及，各圈子独立使用
爆发期	2023年起	ChatGPT引爆大模型后，术语搜索与使用量在2023年初起显著上升——大模型让“AI执行业务”成为现实，词义从“内嵌AI”被充实为“AI作为系统内核”
品类化	2024年	投资机构开始将其作为赛道标签——Sapphire Ventures发布《AI-Native Applications》评估框架，追踪到47个AI-Native应用年收入超2500万美元，AI原生从架构理念变为VC品类与招聘标准
主流化	2025年	Addy Osmani《The AI-Native Software Engineer》、Salesforce《The AI-Native Engineer》、OpenAI《Building an AI-Native Engineering Team》相继发布，各大厂商正式将其纳入工程语汇与产品定位
组织化	2025末–2026	“AI Native Company/Organization”成为硅谷与产业界高频词，话题从“AI原生系统”延伸到“AI原生组织”（YC、a16z与行业头部厂商均有大量论述）

两点解读：

其一，AI原生不是OpenAI、Salesforce或微软发明的口号——它们（Salesforce 2025、微软将其用于Windows 11定位等）是推广者而非首创者，这些公司各自的表述只是把它从概念推向主流；微软早年的口号“AI-First”与“AI-Native”也是两套不同的词。

其二，与云原生由CNCF给出相对明确的定义不同，AI原生没有单一机构定义，它由基础设施圈、产品圈、投资圈等多个群体在2016–2023年间独立、并行地使用——这也解释了为什么今天各厂商定义各有侧重（见1.3的对照表）。

1.2 行业共识

综合各主要厂商的定义，可以提炼出一个共同的内核：AI原生不是把AI（模型与智能体）作为外挂能力附加到既有系统之上，而是在系统设计之初，就以AI作为架构与运行的核心组件。用一个简单的标准判断：如果把AI从系统中拿掉，系统是否还能运行。

AI增强（AI-Enhanced / Embedding AI）：在既有系统上外挂AI能力（如加一个问答框、报表预测列）。去掉AI，核心系统照常运行，只是少了一个功能。
AI原生（AI Native）：业务逻辑的一部分由模型与智能体承担，AI是核心业务能力的一部分。去掉AI，核心业务逻辑无法执行、系统无法运行——如何提升系统整体可用性，正是这类架构需要重点考量的问题。

1.3 厂商定义

不同厂商从自身立场给出了不同视角的定义，彼此并不矛盾，而是共同拼出完整的图景：

厂商/机构	定义侧重	出处
华为	架构范式：AI原生是“系统智能水平高低的频谱”，核心是AI First + 数据与知识驱动 + 自学习自适应自优化 + 统一模型基座 + Agentic AI + 多元算力，并用L0–L5成熟度分级衡量所处阶段	《AI-Native 技术与实践白皮书》
阿里云	应用架构：AI原生应用是“以大模型为认知基础、以Agent为编排和执行单元、以数据为决策和个性化基础、通过工具感知和执行的智能应用”；目标是在可扩展、可观测、安全合规的同时最大化释放大模型的智能潜力	《AI 原生应用架构白皮书》
Anthropic	研发流程：AI原生SDLC是“重新构想的流程——保留原有控制目标，把执行机制围绕Agent的能力重新设计；流程从线性接力变为AI嵌入每个阶段的持续反馈闭环”	The AI-Native SDLC Playbook
Salesforce	组织与文化：AI原生实践是组织学习的加速——94%工程师采用、PR提速30%、两年3000万行AI生成代码上线、整体生产力 +50%	The AI-Native Engineer（Salesforce Engineering）
Microsoft	平台/操作系统：把 AI 建进操作系统层——AI 不再只是 Copilot 这类应用入口，而是在系统内运行本地模型与智能体：NPU 本地推理、OS 级身份与隔离（MXC），开发者版 Project Zenith 开箱即可本地运行 30B+ 参数模型，Windows 被定位为承载 AI 的平台	Windows Developer Blog：Announcing Project Zenith（2026-09）
IBM	产品与工作流：AI原生指“某种事物——通常是产品、公司或工作流程——从一开始就将AI作为核心组成部分进行设计，而非事后作为附属功能附加”；判断标准是“将AI移除，产品不仅无法按预期运行，而且会完全失去用途”	IBM Think：什么是AI原生
Scaled Agile	组织与流程：AI原生组织是“将AI放在最前沿设计组织——不仅是技术选择，更是文化基础”；AI是团队思维中的内在可信组件，贯穿运营、决策、实现、客户交互、维护与优化	Scaled Agile：What Is AI Native?

小结：这些定义看似差异很大：有的讲架构、有的讲流程、有的讲组织、有的讲平台，但它们共享同一个底层判断：AI不应再是事后加上去的功能，而应从设计之初就被内嵌；且“设计之初内嵌”发生在哪个层面（架构、流程、组织、平台），决定了各厂商的表述差异。华为与阿里云从“系统与架构”切入，Anthropic从“研发流程”切入，Salesforce与Scaled Agile从“组织”切入，Microsoft从“平台/OS”切入，IBM从“产品与工作流”切入——这些视角共同合成一个完整图景。

本文先聚焦概念解读；AI原生如何重构软件系统研发过程、AI原生的软件系统架构，以及个人与组织如何面向AI原生转型，将留待后续分篇逐步展开。

1.4 Agent、Agentic与AI原生

三者是不同层面的概念，却常被混用：AI Agent（智能体）是执行任务的组件——接收信息、在既定边界内调用工具完成动作；Agentic AI（智能体式AI）是目标驱动的行为模式——系统从高层目标出发，自主规划、拆解与调整路径，是多个组件组合出的行为特性；AI原生则是系统的构建范式——从设计之初就以模型与智能体为内核。关系可以概括为：AI原生以模型为认知基础，以Agentic AI为行为载体，执行单元即AI Agent，而以Embedding AI为代表的局部嵌入则不属于AI原生。简言之，Agent是“组件”，Agentic是“行为”，AI原生是“范式”。

二、AI原生的主要特征

AI原生不是某一个单一的技术点，而是一条贯穿“设计→认知→推理→执行→演进”的完整价值链，缺一环，AI原生就不成立，因此它呈现出不同的特征。

特征一：AI First——设计的起点。 AI原生区别于“AI增强”的分界，在于设计之初就把AI当作核心组件，而非事后补丁。规划阶段优先思考的不是技术选型，而是能力边界：哪些环节交给AI、哪些保留规则与人工。把AI当内核，架构、数据、交互才会为它让路；把AI当外挂，模型再强也只是在旧骨架上贴一层智能。

特征二：数据与知识驱动——认知的基础。 模型再强也不掌握企业的私有知识，而业务知识散落在企业内部的数据与文档中。数据与知识是认知的原料，系统靠它们“认识”业务：数据实时动态，让系统跟上变化；知识沉淀结构化，让系统理解业务。二者构成认知基础，没有它，模型面对具体业务只是无源之水，推理与执行便失去根基。

特征三：以统一智能底座为依托、按场景垂直适配——推理引擎。 有了数据知识作燃料，还需要能把原料“想明白”的引擎。这里的统一是架构层面的：通过统一的模型接入、统一的知识与语义底座，让各场景共享一致的理解，知识可沉淀、反馈可回流；垂直是能力层面的：通过微调、知识注入（RAG）、蒸馏等，按场景适配出满足专业精度、成本与时延约束的能力。只统一不垂直，做不了专业活；只垂直不统一，会退回碎片化。AI原生架构的价值，正是用“逻辑统一+能力垂直”同时保住一致性与专业性。

特征四：Agentic AI——行动的执行。 AI原生由智能体承载执行：理解目标、拆解任务、调用工具、观察结果、调整下一步。智能体能做什么被约束，靠工具完成真实动作，据结果修正路径。模型负责“想”，Agent负责“做”，两者结合才构成完整闭环。

特征五：自学习、自适应、自优化——持续的演进。 传统的系统开发完成能力就已固化，AI原生的系统具备持续自我演进能力，自学习从使用中积累样本、微调模型；自适应面对新场景动态调整策略；自优化在运行中持续改进。反馈回流到认知与推理，形成“越用越准”的正循环。

三、AI原生与传统软件系统的区别

软件系统在不同的参与者视角下具有不同的关注点：用户看到的是交互界面，工程师关心的是架构与数据，经营者关注的是从构建到运维的整个生命周期。下面从九个维度展开对比传统与AI原生软件系统差异点。

维度一：交互界面——从“指令式操作”到“意图式对话”

传统软件的交互界面是“指令式”的：用户需要学会系统的操作路径——点哪个菜单、填哪个表单、走哪一步流程，把自己的意图翻译成系统能理解的结构化指令。界面越复杂，学习成本越高，用户是被“培训”的对象。

AI原生软件的交互界面是“意图式”的：用户用自然语言表达目标，系统负责理解意图并组织执行。正如IBM所言，AI原生系统“以自然语言为交互核心，自动化是产品核心功能的内在组成部分，而非辅助性的”。界面从“用户学习的控制台”变为“随叫随到的助手”。值得注意的是，这并不等于界面完全消失，对话框与表单会重新分工（见第四节），但交互的主导权从“用户迁就系统”转向了“系统理解用户”。

维度二：分层架构——从“确定性三层”到“模型与智能体融入每一层”

传统软件的分层架构（表现层—业务层—数据层，或更细的微服务分层）是为确定性代码设计的：每一层执行预先写死的逻辑，层与层通过定义好的接口协作。

AI原生没有推翻分层，而是改变了分层的“成分”：业务逻辑的执行主体从纯代码扩展为“代码 + 模型 + 智能体”。华为将AI原生总体架构划分为资源层、OS层与应用层三层，模型与智能体不再是某个角落的组件，而是贯穿各层、承担决策与编排的核心。阿里云的定义更直接——“以大模型为认知基础、以Agent为编排和执行单元”，架构中出现了模型服务、智能网关、知识检索这些传统分层里不存在的新构件。分层依然存在，但每一层要解决的问题从“确定性逻辑如何执行”变成了“智能如何被组织、约束与治理”。

维度三：数据建模与资产管理——从“支撑交易的记录”到“喂养推理的知识资产”

传统软件系统里，数据是业务的副产品：围绕交易设计表结构、数仓与指标口径，目的是可靠地记录与查询。数据模型回答的是“这笔业务怎么存”。

AI原生软件系统里，数据与知识上升为第一等的资产。模型不掌握企业私有知识，推理质量取决于运行时能“喂”到什么，于是出现了向量化知识库、知识图谱、记忆库等新形态，非结构化文档成为推理的直接材料。华为将这一特征概括为“数据-知识双轮驱动”：数据与知识不仅支撑记录，更驱动决策与持续优化。数据的角色从“资产化的记录”变为“可喂养的知识”，数据建模也从“为存储建模”变为“为推理建模”。

维度四：业务流程与逻辑——从“代码固化的确定性流程”到“模型编排的动态执行”

传统软件系统的流程是“固化”的：业务流程写成代码与规则引擎，路径在设计期就画死，业务一变就要改代码、发版本。IBM的表述很精确，传统软件系统“构建在确定性逻辑和人类程序员设定的预定义规则之上”，计算器、电子表格宏“没有学习或适应能力，所有行为都是预设的”。

AI原生的业务流程是“可推理的”：系统理解高层目标后，由模型实时决定执行路径、调用哪些工具、下一步做什么。华为将AI Agent描述为“在一个循环中运行，接收高层次目标、推理如何实现、选择并使用工具、观察结果、决定下一步行动”，能够处理“无法预先硬编码的逻辑及其顺序的开放性问题”。流程从“写死的路径”变为“受约束的自主执行”，规则不再穷举所有场景，而是划定边界与底线。

维度五：构建与运行——从“手写代码的程序”到“生成与编排的智能体系统”

传统软件的构建是“手写”的：人写代码、人工测试、人工部署，运行态是“程序 + 数据”，程序在数据上执行确定逻辑。

AI原生软件的构建是“生成与编排”的：Anthropic指出“代码不再是瓶颈”，智能体把构建周期压缩到小时级后，规划、设计、实现、测试、部署的全流程都需要围绕智能体重构；运行态也从“程序 + 数据”变为“模型 + 上下文 + 工具 + 反馈”，模型是决策者，上下文与知识库是输入，工具是手脚，运行中的反馈又回流优化系统本身。构建方式从“编写”变为“生成”，运行方式从“执行”变为“推理 + 行动”。

维度六：软件系统发布——从“发布代码版本”到“发布持续演进的智能资产”

传统软件系统发布的单元是“代码版本”：发版、回滚，都是针对代码的快照。需求变更→变更代码→构建→测试→发布是标准动作。

AI原生的发布单元发生了变化：除了代码，模型版本、知识库版本、提示词版本、工具定义都成了需要发布与回滚的对象。一次“升级模型”可能比一次代码改动影响更大，知识库更新与模型版本错位会带来行为漂移。为应对这一挑战，业界实践的趋势，是把模型、知识、提示词、工具绑定为一次“可回滚的发布单元”，并把评测结果作为发布准入门槛。

维度七：质量管理——从“测试用例与断言”到“评测集与护栏”

传统软件系统的质量保障建立在确定性之上：写测试用例、跑断言，“结果对不对”有唯一答案。错了就是Bug，修掉即可。

AI原生的输出是概率性的：同一输入可能产生不同输出，幻觉、漂移、不一致是常态而非异常。质量保障因此从“断言”转向“评测”，用带标注的评测集持续衡量模型在各类任务上的表现（准确率、拒答率、工具调用成功率、幻觉率），并配以护栏（Guardrail）、人在回路（Human-in-the-loop）与可观测。阿里云白皮书明确提出“AI评估成为构建AI原生应用中的必备要素”，主张自动化评估与人工校准的混合策略。质量问题的本质从“代码有没有写错”变为“系统行为是否始终可信”。

维度八：系统运维——从“监控与救火”到“自学习、自愈与飞轮”

传统运维围绕确定性系统：监控指标、告警、人工定位与修复，目标是“别出故障、出了尽快恢复”。

AI原生系统的运维发生了两重变化。其一，运维对象更复杂——要监控的不只是CPU与延迟，还有Token消耗、模型漂移、知识库时效、工具调用成功率等AI特有指标，从“确定性运维”走向以数据和大模型为中心的主动运维。其二，运维目标从“保持稳定”升级为“让系统持续变好”，自学习、自适应、自优化意味着系统能从运行反馈中自我调整，形成“越用越准”的数据飞轮，而不是“上线即巅峰、越用越旧”。

维度九：价值创造方式——从“交付软件版本”到“交付持续进化的智能服务”

传统软件系统的价值创造是一次性的：厂商把软件做成版本，客户购买和订阅后获得一套“已定型”的能力，价值在交付时点被锁定，后续靠新版本迭代才能增值。软件是“售出的产品”，价值兑现于成交那一刻。

AI原生软件系统的价值创造是持续性的：价值不在“卖出那一刻的版本”，而在“运行中不断增值的服务”。系统在真实使用中持续学习、积累数据与知识、优化自身行为，IBM称之为“智能护城河”与“复利效应”：模型随时间不断学习如何做得更好，改进产生复利，这是传统软件系统无法实现的。对厂商与客户而言，关系的重心从“买一个软件”变为“使用一项越用越好的能力”，这也将重塑订阅、按效果付费等商业模式。

一句话总结

九个维度的差异可以回归到开篇提到的两个转变：

架构范式上，传统软件系统是为“确定性执行”设计的，分层架构、数据模型都为预先写死的逻辑服务；AI原生软件系统是为“智能决策与持续演进”设计的，模型、知识、智能体进入每一层，数据从记录变为推理资产。

运行范式上，前者追求“按设计运行”，构建、发布、质量、运维都围绕确定性代码展开；后者追求“在约束中自主、在使用中进化”，从构建生成到发布可回滚、质量靠评测、运维靠自愈，整套运行机制随之重构。分层架构不会消失，但每一层要解决的问题变了；这不是推倒重来，而是把AI从“附加功能”升级为“系统内核”后，软件系统从架构组织方式到运行机制的整体范式转变。

四、CRUD表单界面到底会不会消失

讨论AI原生时，最常被问到的一个具体问题是：围绕数据增删改查（CRUD）的表单与流程式交互界面，会被取代吗？

要回答这个问题，需要把两件事分开看：表单作为一种交互形态是否会被取代，以及表单背后的业务能力在AI原生下如何产生。前者关乎用户体验，后者关乎软件的生产方式——两者答案不同，混淆在一起才让这个问题显得纠缠不清。

4.1 交易性业务需要结构化的锚点

表单有两种职能：一是约束输入——把自然意图翻译成机器能处理的结构化数据；二是交易锚点——记录事实、确认行为、承担责任。AI原生瓦解的是前者：当系统能理解非结构化输入时，约束不再必要；但后者恰恰是交易性业务的本质需求——AI不能作为责任主体，责任主体不会因AI而消失。

常见的交易性业务，例如：报销、请假、采购下单、合同签订、出入库、财务记账等，有三个特点：

结果需要可追溯：每一笔交易都要能还原“谁、何时、做了什么、依据是什么”，记录即留痕，表单字段就是可追溯、可审计的证据载体；
操作需要可确认：涉及资金、责任与合规的动作，必须有一个明确的确认点防止误操作，表单就是这个确认点的物理形态；
流程需要可审批：流程本质是责权的划分，多角色流转与权限控制要求每一步都有清晰的提交物，表单与流程引擎天然承载这一职责。

对话式交互擅长的是“理解意图与探索问题”，而交易性业务要求的是“可追溯、可确认、可审批”，两者并不冲突，后者正是结构化界面的主场。采集类、查询类、探索类的交互交给对话，交易类动作仍以结构化表单完成，或由系统自动填好，用户确认后提交。

4.2 表单式应用的产生方式：从确定性编码到知识驱动的自动生成

表单作为交易性业务的结构化界面不会消失，但它是怎么“造”出来的，在传统软件与AI原生软件中截然不同。

传统软件中，表单式应用来自开发人员的确定性编码。 报销要走什么审批链、采购在什么条件下允许加急、财务哪些字段不能为空，这些业务知识藏在业务专家脑子里与制度文档中，开发人员将其编码为字段、校验规则、流程节点与权限配置。编码的本质，是把模糊的业务知识固化成确定性的程序逻辑。

AI原生软件系统中，业务知识数字化，表单式应用自动生成。 AI原生改变了业务知识在软件系统中的存在方式：业务知识不再以“散落的人脑+固化的代码”存在，而是被数字化管理、沉淀为业务本体模型与业务知识图谱——业务对象、属性、关系、规则与流程被结构化成机器可理解、可推理的知识资产。当业务知识以本体与知识图谱的形式沉淀后，表单式应用的产生方式随之改变：开发人员不再需要为每个表单手写确定性代码，而是可以让AI系统基于业务本体模型与知识图谱自动生成对应的业务能力。系统知道“报销单”由哪些字段构成、字段间有什么校验关系、该走什么审批流、谁有权查看，于是能够自动生成表单界面、校验逻辑、流程编排与权限配置；业务专家可以直接修改知识图谱中的规则（如调整审批链、新增字段约束），业务能力随之更新，无需等待开发人员改代码。

总结一句话：表单作为交易性业务的结构化界面依然存在，但它不再是“人肉编码的产物”，而是“知识驱动的自动产物”，表单没有消失，产生表单的方式需要重构了。

五、AI原生软件系统的价值

通过前面的分析，AI原生系统能够带来的价值也是显而易见的，可以归纳为五个层面：

1. 精益化业务运营 数据驱动优化每个环节，自动化流程、优化决策、实时反馈，大幅提升运营效率与精度；持续监控与优化，减少资源浪费，实现精准的需求预测与供应链优化。

2. 业务功能创新与增强 深度挖掘数据价值，发现传统方法无法识别的机会，创造个性化推荐、智能客服、自动化生产等新能力，助力业务转型与差异化竞争。

3. 开发与部署自动化 从需求到代码到测试的链路被AI重构，代码开发不再是效率的瓶颈，需求交付的周期可压缩到小时级，软件开发流程本身也必须重新设计以匹配Agent速度。

4. 运维与优化自动驾驶 系统自我监控、故障预测、自动修复，从“人盯系统”走向“系统自愈”；同时基于实时数据的优化模型持续提升系统性能与可靠性。

5. 商业模式创新与产业升级 服务定制化、智能产品、平台化经营成为可能。AI原生能力会成为重塑企业组织、创新模式与价值流的关键，驱动企业和生态向“智能有机体”演进。

六、总结

回到开篇的问题，AI原生软件系统到底是什么？到这里想必大家都应该有了一个初步的认识了，基于前面的分析，我提出一个观点：当AI的能力跨越临界点，把AI当作内核而非外挂来设计，将会成为下一代软件系统的标准范式。

参考资料

华为云 × 创原会：《AI-Native 技术与实践白皮书》（2025-12）
阿里云 × 爱橙科技：《AI 原生应用架构白皮书》（2025-09）
Anthropic：The AI-Native SDLC Playbook — https://claude.com/blog/the-AI-Native-sdlc-playbook
OpenAI：Building an AI-Native Engineering Team — https://cdn.openai.com/business-guides-and-resources/building-an-AI-Native-engineering-team.pdf
Salesforce Engineering：The AI-Native Engineer — https://engineering.salesforce.com/the-AI-Native-engineer-how-salesforces-next-generation-is-redefining-software-development/
Splunk：What is AI-Native? — https://www.splunk.com/en_us/blog/learn/AI-Native.html
IBM：What is AI-Native? — https://www.ibm.com/cn-zh/think/topics/AI-Native
Scaled Agile：What is AI-Native? — https://scaledagile.com/blog/what-is-AI-Native/
Harvard Business School Online：AI-Native — https://online.hbs.edu/blog/post/AI-Native
Microsoft Learn：AI应用架构（Azure Cloud Adoption Framework）— https://learn.microsoft.com/zh-cn/azure/cloud-adoption-framework/innovate/best-practices/ai-applications
EarlyTerms：AI-Native术语追踪（词源与搜索热度数据）— https://earlyterms.com/zh/term/AI-Native
Sapphire Ventures：AI-Native Applications — https://sapphireventures.com/blog/AI-Native-applications/
Addy Osmani：The AI-Native Software Engineer — https://addyo.substack.com/p/the-AI-Native-software-engineer
CNCF：Cloud Native Definition（cloud-native术语背景）— https://github.com/cncf/toc/blob/main/DEFINITION.md
Kimi（月之暗面）：AI智能体与Agentic AI的概念、区别与应用 — https://www.kimi.com/resources/agent-ai-vs-agentic-ai
微软 Windows 开发者博客：Announcing Project Zenith: The Ready-to-Code Windows Experience（2026-09）— https://blogs.windows.com/windowsdeveloper/2026/09/04/announcing-project-zenith-the-ready-to-code-windows-experience/
Windows Latest：Microsoft Wants Windows 11 to Move Beyond Copilot Buttons, Run AI Models on Your PC（2026-09）— https://www.windowslatest.com/2026/09/06/microsoft-wants-windows-11-to-move-beyond-copilot-buttons-with-ai-models-running-on-your-pc/