平台
面向严肃 AI 软件交付的自定义沙箱
自定义沙箱镜像把 AI 辅助工程能力包裹在 Rails、Java、Go、Python、Node 与多进程后端之上——让交付闭环运行在你已经在运维的技术栈上。
自定义沙箱是 Ciao 基于自定义镜像构建的环境,把 AI 辅助工程能力包裹在 Rails、Java、Go、Python、Node 与多进程后端之上。与那些假定你从一个空的 JavaScript 项目开始的 AI 构建工具不同,自定义沙箱会在隔离的 Pod 中运行你的运行时、依赖项与服务——因此 Ciao 的 Builder、QA、Security 与 Guardrails 会作用在你业务已经依赖的系统之上。
发布日期 2026-07-03 · 最近更新 2026-07-03
你的生产技术栈,不是一个绿地 React 应用
大多数 AI 应用搭建工具都假定世界始于一个空的 JavaScript 项目。真实的资产版图并不长这样。它们看起来是一个承载着十年业务规则的 Rails 单体应用、没人愿意碰的 Java 服务、承受着真实负载的 Go API、Python 数据平台,以及必须按正确顺序启动三样东西才能正常工作的多进程后端。
对一个严肃的组织而言,真正有意思的问题不是 AI 能否启动一个新项目——而是 AI 能否在你已经在运行的东西上安全地工作。自定义沙箱是 Ciao 的答案:自定义沙箱镜像把 AI 辅助工程能力包裹在 Rails、Java、Go、Python、Node 与多进程后端之上,把完整的交付闭环带到你的技术栈上,而不是要求你的技术栈变成别人的样子。
这份资产版图,通常正是“什么都不做”的理由:太过盘根错节以至于不敢动,太过关键以至于不敢冒险。自定义沙箱把这个逻辑反转了过来——让绿地 AI 构建变得安全的那套测试、审核与审计纪律,恰恰也是让棕地 AI 工作成为可能的关键。
自定义沙箱是如何工作的
接入过程是刻意的:镜像只需定义一次,由它构建出的每个工作区都是可复现的。
1. 定义镜像
运行时版本、系统依赖、服务与进程拓扑,会与你的团队一起被捕获进一个自定义沙箱镜像——你的技术栈,被编码了下来。
2. 在隔离的 Pod 中运行
沙箱运行在 Ciao 为规模而设计的基础设施上——Kubernetes、隔离的 Pod、休眠与唤醒——因此每个工作区都是受控且可复现的。
3. 在 Builder 中针对你的代码库工作
简单语言的请求会变成对你真实系统的改动,附带真实 Git 分支上的差异对比,实时行为一路可见。
4. 通过相同的关卡
Security 会运行静态扫描、依赖项检查与访问控制探测;QA 会检验运行中的系统;Guardrails 会应用你的简明英文政策并记录人工审核。
5. 部署到你需要的地方
Ciao 云、你自己的 AWS、Azure 或 GCP 账户、私有 VPC——或在另行约定条款下部署到本地环境。
为什么这很重要
那些让你今天赚到钱的系统,恰恰是 AI 辅助最能帮上忙的地方——也恰恰是消费级 AI 构建工具碰不到的地方。自定义沙箱把受治理的 AI 辅助工程带到了这份资产版图上,却不落入那个经典的陷阱:一次耗费两年、产出却不如原单体应用的“大爆炸式”重写。
现代化因此变成了渐进式的。新能力、修复与重构会通过一个经审核、经测试、留有记录的闭环落在现有技术栈上——而在真正需要重写的地方,它会按系统逐一进行,新旧世界都处于同一套交付纪律之下。
谁在使用自定义沙箱
自定义沙箱是为那些最有价值的系统早于 AI 时代就已存在的组织而设计的:
- 企业 IT — 拥有 Rails、Java 与 Python 系统资产版图的团队,需要变更速度,却不想要变更带来的混乱。
- 软件公司 — 多语言后端,产品太有价值以至于不能重写,又太重要以至于不能拖慢。
- 现代化项目 — 遗留系统在治理之下渐进式地演进,而不是把宝押在一次重写上。
- MSP 与咨询公司 — 混合技术栈中的客户系统,用一套一致的、可审计的交付闭环来运营所有系统。
安全与治理说明
企业级控制措施对沙箱的适用方式,和对平台其余部分完全一致:
- ✓ 沙箱运行在基于 Kubernetes 的基础设施上的隔离 Pod 中。
- ✓ 通过 SAML 与 OIDC 实现的 SSO、可选的多因素认证,以及基于角色的访问控制。
- ✓ 跨越提示词、合并、部署与管理员操作的只增不减审计日志。
- ✓ 客户代码不会被用于训练模型;推理运行在零保留期模型合约之下。
- ✓ SOC 2 Type II 报告可在 NDA 下提供。
- ✓ 私有 VPC 与本地部署可在另行约定的条款下提供。
自定义沙箱支持的技术栈
一个交付闭环,六种技术栈形态:
| 技术栈 | 典型资产版图 | 沙箱提供什么 |
|---|---|---|
| Rails | 承载着十年业务规则的单体应用 | Ruby 运行时、gem 与服务被编码进镜像 |
| Java | 拥有严格依赖关系的长期运行服务 | JVM、构建工具与服务拓扑在每个工作区中被复现 |
| Go | 承受真实负载的 API 与基础设施 | 工具链与依赖项被固定在镜像中 |
| Python | 数据平台、内部服务、成长为系统的脚本 | 解释器、包与系统库,符合你技术栈的预期 |
| Node | 超出默认绿地形态的后端 | 你的 Node 版本与进程布局,而不是一个全新的脚手架 |
| 多进程后端 | 必须协同运行才有意义的多个服务 | 完整的进程拓扑运行在一个隔离的沙箱内 |
常见问题
沙箱能匹配我们确切的运行时版本和依赖项吗?
这正是自定义镜像存在的意义:运行时版本、系统依赖、服务与进程拓扑会与你的团队一起定义,让沙箱复现出你的系统真正需要的技术栈。它作为企业接入流程的一部分被限定范围。
我们的代码必须离开我们的网络吗?
部署目标包括你自己的 AWS、Azure 或 GCP 账户和私有 VPC,本地部署可在另行约定的条款下提供。客户代码不会被用于训练模型,推理运行在零保留期模型合约之下。请与销售团队沟通你的安全团队所要求的边界。
这和标准的 Ciao Builder 有什么不同?
标准 Builder 生成全新的 React、TypeScript 与 Supabase 应用。自定义沙箱把同一套 AI 辅助工程闭环——Builder、QA、Security、Guardrails——包裹在你现有的 Rails、Java、Go、Python、Node 或多进程技术栈之上。
我们能把自定义沙箱和自己的模型结合使用吗?
可以。企业计划支持接入你自己的大模型——自有供应商密钥、兼容 OpenAI 的接口与私有模型路由——因此对敏感代码库的工作,会针对你组织已经批准的模型运行。
我们该如何开始?
自定义沙箱是一项企业能力:严肃的生产项目起价为每年 10,000 美元,镜像会在接入过程中与你的平台团队一起被限定范围。请联系销售团队,描述你的技术栈以开始这个流程。