在前两篇文章中,我谈到了更大的 XCP 构想:将处于开发者模式的 Xbox Series X 变成一个可编程的执行目标,并让 AI 辅助的软件保持在持续的构建 → 执行 → 观察 → 纠正循环中。

但这些工作中大部分只有一个地方会变得可见。

XCP Studio。

XCP Studio project workspace

来自公开 XCP 仓库的 XCP Studio 工作区录屏。

XCP Studio 是围绕 XCP 的 Windows 开发环境。

它背后的想法刻意保持简单:

开发者、可视化界面和编码智能体不应操作项目的三个不同版本。

它们应当基于同一个项目权威来工作。

一个项目,三种使用方式

一个项目可以从不同层面来使用。

                XCP PROJECT
                     │
          ┌──────────┼──────────┐
          │          │          │
       Guided      Expert      Agent
          │          │          │
          └──────────┼──────────┘
                     │
                 same state

引导模式通过界面暴露更高层的项目操作。

专家模式直接访问详细的开发工作流。

智能体模式允许编码智能体通过相同的项目生命周期和可移植的 XCP 工具链来工作。

重要的不是存在三个界面。

而是它们不会产生三个独立的项目模型。

如果开发者修改了项目,智能体就基于该项目工作。

如果智能体创建或调整了某些内容,Studio 也基于同一个权威来工作。

不存在一个隐藏的、仅供 AI 使用的软件版本,需要事后去协调。

当开发在人类和智能体之间来回切换时,这一点会变得越来越有用。

Studio 不会止步于生成

很多 AI 开发工具实际上就到此为止:

prompt
   ↓
code
   ↓
files

XCP Studio 是围绕更长的生命周期构建的。

idea / source
     ↓
XCP Studio
     ↓
project
     ↓
validate
     ↓
build
     ↓
Xbox execution target
     ↓
result + evidence
     ↓
inspect / correct
     ↺

Studio 可以创建或打开项目、根据可用的契约对其进行验证、构建它、准备执行,并检查由此产生的证据。

编码智能体始终留在开发一侧。

Xbox 始终是执行目标。

两者通过 XCP 所认可的項目契约和执行契约相连接,而不是通过赋予智能体对主机的无限制访问权限。

这一区别很重要。

AI 构建和修改软件。Xbox 执行被认可的工作。XCP 记录发生了什么。

下一次迭代随后可以从真实执行的结果出发,而不仅仅是从模型预期会发生的事情出发。

我为什么想要 Studio

从技术上讲,XCP 的大部分内容本可以保持为一组命令行工具。

这个可移植仓库已经暴露了诸如以下的操作:

xcp project describe
xcp conformance all
xcp xvm verify ...
xcp xvm run ...

但更大的系统需要一个地方,让整个项目生命周期保持可理解。

源代码、项目状态、目标能力、验证、构建、执行和证据都是相互关联的。

一旦 AI 智能体进入这个生命周期,保持这些关系可见就变得更加重要。

所以 Studio 并不是要成为一个 AI 代码生成器,附带一个"Run on Xbox"按钮。

它是围绕生命周期的控制界面。

developer ───────┐
                 │
coding agent ────┼──► XCP Studio / project
                 │             │
tools ───────────┘             │
                               ▼
                         admitted build
                               │
                               ▼
                         Xbox Series X
                               │
                               ▼
                            evidence
                               │
                               └────► next iteration

项目在每一次单独的生成中都能存续下来。

这是我最关心的部分。

现在它是开源技术栈的一部分

XCP Studio 已包含在公开的 XCP 源代码树中。

该仓库包含可移植的 XCP 契约、XVM、项目工具、证据基础设施、源代码适配工作、重建的 Windows 开发栈以及原生 Xbox worker 组件。

可移植的部分无需拥有 Xbox 即可探索。

git clone https://github.com/Daniele-Cangi/xcp-xbox.git
cdxcp-xbox

python -m pip install -e '.[test]'
python -m pytest -q
xcp conformance all

在 Windows 上,该仓库还可以重建包含 XCP Studio 及配套运行时组件的开发发行版。

有一条证据边界值得明确保留:被保存下来的产品路径历史上是在一台实体 Xbox Series X 上运行的,而新重建的公开开发包仍被标记为NOT_TESTED_ON_XBOX直到在硬件上被独立复现为止。

这种区分是有意为之的。

XCP 将一次成功的历史运行和一个新重建的二进制文件视为两种不同的主张。

Studio 背后的小想法

UI 其实并不是有趣的部分。

有趣的部分是它底下的共享对象。

human
  │
  ├─────────┐
  │         │
  ▼         ▼
Studio    agent
  │         │
  └────┬────┘
       ▼
   XCP project
       │
       ▼
 real execution
       │
       ▼
    evidence

人类和 AI 不需要各自独立的开发世界。

他们需要一个共享的项目、明确的能力,以及来自实际执行结果的机器的证据。

这正是 XCP Studio 试图提供的。


XCP 是开源的

前几章:

  1. 我在 Xbox 沙盒里构建了一个虚拟机。然后我让 AI 智能体在它之上构建。
  2. 一个让 AI 直接与真实 Xbox 协作的系统——现已开源

AI 构建。Xbox 执行。XCP 验证。Studio 是让这个循环保持可见的地方。