Proxyos Weekly 110

Laurence-042

November 6, 2026 - 3 minutes read - 457 words

TL;DR 概览
不再要求玩家下载 vscode，并使用归一的内置编辑器同时处理教程和正常编程。

本期目标

Demo 发布
- 虚拟机验证 release 发布包
- 开个 itch（patron？）
- 琢磨下宣传
  - 投放平台？
  - 发布视频？
  - 完善当前的隐写小游戏
  - 上 steam？
    - steam 的规则？文案？ai 资源要求？
Demo 发布后
- 反响好
  - 细化系统、规划后续内容
    - 实用化任务时限
    - 命令行内容？（等第三章？是否需要？）
    - 远程访问？
- 反响不好
  - 找个班上

进展速记

本期假设 / 预期

预期：

上期突发恶疾，咕了一期。这期继续。

这期的核心是搞虚拟机环境，搞定 release 验证，然后看看能不能找些合适的场景截几个宣传图。

结果：

哈哈哈，需求爆炸！

搞 release 验证，验证一半发现自己彻底低估了自己 pc 上已有开发环境的环境准备优势，让玩家自己去准备 vscode 完全不现实，而且怕是得被当场差评退款然后说是微软推销员。

结果这期就在折腾内置 code oss 了……只能说这期差不多搞定了，下期应该就能完成收尾，如果顺利的话还能把 release build 打通

本期确定性变化

新增：

基于 code oss 的内置通用编辑器

变更：

实测发现一些玩家可能会搞出来的奇奇怪怪语句可能让第一章的课程引导出问题，进行了相应的可靠性改进

修复：

删除：

旧的教程专用内置编辑器
外部 vscode 接入作为专门编码工具

主要进展内容/本期关键判断点

我做出了哪些「如果错了也要付代价」的判断？

背景

实测发现，要求玩家在游戏过程中额外下载、安装和配置 VS Code，会极大消减玩家继续游玩的热情。玩家需要离开游戏，完成编辑器安装、Python 扩展安装和解释器配置，才能回到任务；这些准备工作打断了游玩过程，也把开发环境问题变成了玩家继续游戏的门槛。

外部环境还增加了支持成本。玩家安装的 VS Code、扩展和 Python 环境各不相同，个人设置、版本更新及已有插件都可能影响游戏提供的配置。即使预先准备好工作区，也难以保证所有玩家获得一致的运行和调试体验。

发布层面，项目也担心要求玩家额外安装 VS Code 容易被视为商业行为，从而带来发布阶段的法律与舆论风险。

甚至就连游戏过程层面都会产生极大负面效果：vs code 的界面也可能会让没有任何编码经验的玩家懵逼，而且它现在甚至还内置 copilot，免费版就能把教程一路自动处理完，导致经过设计的难度曲线直接被压平，然后玩家就会在第一个没有 TODO 注释提示功能的地方直接遇到难度曲线原地升天……

因此，需要让编程环境随游戏交付，由项目统一维护，使玩家能够在游戏内从教学过渡到真实编程，减少额外安装、配置和切换工具的负担。选用可定制、可分发的开源基础，也便于明确发行物的组成与许可边界。

现状

业界方案与选型判断

考虑到目前开源编辑器最流行的就是 vscode 提供的解决方案，而且大量 cursor 等基于 vscode 方案衍生的编辑器已经证实其可自定义度大概率可以支持我们的项目要求。

现有方案主要在编辑组件、完整 IDE 能力和宿主集成之间取舍。结合前期调研，对本项目有代表性的三种形态如下。

方案	特点	对 ProxyOS 的适用情况
以 Monaco 为代表的纯前端编辑器	编辑组件本身体积较小，容易嵌入网页并定制交互；提供成熟的文本编辑能力	Python 补全、真实解释器、调试、终端和工作区管理仍需分别接入。满足游戏所需的完整 Python 开发能力，要承担较多额外集成工作
以 Code - OSS Desktop 为代表的独立编辑器应用	工作台、文件管理、终端和扩展宿主较完整，可捆绑成受控的开发环境	独立应用与游戏在窗口、生命周期和交互上分离。接入教学演出、任务提交及游戏状态的成本较高，也难以形成连续的游戏内体验
Code - OSS Web 工作台＋本机 Node 后端	将工作台放入 Web 宿主，同时由本机后端提供文件访问、终端和 Node 扩展宿主	可以复用完整 IDE 的基础能力，并通过现有 Wry 纳入游戏窗口与交互；需要验证 WebView 兼容、持久化和游戏桥接

Monaco 是从 VS Code 提取的浏览器编辑组件；Code - OSS 则还包含工作台、桌面入口和服务端等层次。Web 环境与 Node 环境的扩展宿主能力不同，Python 开发所需的本机能力需要后端承接。以上比较依据 Monaco 项目说明、Code - OSS 源码分层和扩展宿主说明；体积与集成成本是针对本项目需求的相对判断，尚无原型实测数据。

综合 Python 能力与游戏集成需求，本项目选择第三种形态继续验证。它能够利用现有 Wry 渲染基础，让编辑器的窗口管理可以被本项目方便地管理，同时保留 Code - OSS 工作台及 Node 扩展宿主，减少重新搭建 IDE 功能的工作。

项目当前的编辑器分工

ProxyOS 目前把编程体验分成内部编辑器和外部 VS Code 两部分。

编辑器	游戏中的职责	游戏实际需要的功能
内部编辑器	承担第一章系统恢复的教学演出，以及后续桌宠提供的示例课程；让玩家在受控代码中学习和验证操作	局部填空、只读片段、隐藏初始化代码、预设及用户断点、智能单步、执行指针、变量监视、输出与错误解释；角色对白、表情和课程成功后的游戏效果
外部 VS Code	承担后续章节的真实 Python 任务开发；玩家打开解锁到工作区的文件，编辑、运行和调试，再交回游戏验证或提交	文件树、多文件编辑、保存、查找与搜索、Python 补全和代码导航、格式化、终端、F5、断点、变量查看和停止运行；从游戏定位文件、运行后通知验证器及文件提交

内部编辑器与课程和剧情结合紧密，但目前按模板和片段组织代码，尚未承担完整工作区的自由编程。外部 VS Code 提供完整开发能力，却要求玩家自行准备环境，并在游戏与外部工具之间切换。两者各自解决了一部分需求，玩家的编程过程因此被拆成两套交互。

项目已有可复用的基础：客户端捆绑 Python 3.13.9，外部 VS Code 预设已指向该解释器；课程调试、任务验证和存档由 Godot 侧管理；Wry 已用于游戏内网页应用。统一编辑器需要承接这些能力，使教学演出和真实文件开发在同一入口下工作。

技术路线

总体目标是做出一个随 ProxyOS 安装、由游戏打开和管理的统一内部编辑器。玩家在同一应用中完成受控教学、真实 Python 编程、运行调试和任务提交，无须自行安装 VS Code 或配置 Python 插件。

采用 Code - OSS Web 工作台＋本机 Node 后端，嵌入现有 Wry：工作台提供编辑、文件管理、搜索和调试界面；Node 后端提供本机文件、终端和扩展运行能力；固定版本的 Python 扩展、语言服务和调试器使用游戏捆绑的 Python。全部组件在玩家本机运行，原型所需功能离线可用。

工作台集成层统一实现教学交互、限制编辑、隐藏代码展示、执行指针、角色对白、表情和课程控制。教学与自由编程使用同一工作台和文本编辑能力，通过课程上下文启用或解除限制，不另建教学编辑器。Godot 负责窗口、后端生命周期及游戏业务，继续拥有课程进度、验证结果、任务完成和存档的决定权。

编辑器、扩展、解释器和调试器固定成一套经过验证的发行物，随游戏更新。编辑器配置放在 ProxyOS 存档树内的独立目录，真实工作文件沿用现有开发区，隔离玩家个人 VS Code 的设置与扩展。关闭账号、同步、扩展推荐和在线 AI 等不需要的入口；先保留上游模块，通过配置和集成代码限定功能。

原型先证明以下四条流程可以在统一编辑器中完成：

在现有 Wry 中离线打开真实工作区，完成中文输入、编辑和保存。
使用捆绑 Python 完成补全、F5、断点、变量查看及停止运行。
运行后通知现有任务验证器，并验证正式文件提交链路。
迁移一个包含局部填空、隐藏代码和单步演出的现有 lesson。

原型先用一个现有 lesson 验证统一工作台的教学能力，未迁移内容列为尚未覆盖，不通过回退旧编辑器补齐。正式切换前完成全部课程和编辑入口迁移，并移除旧 InternalEditor 和游戏对外部 VS Code 的启动依赖。最终只有一套编辑器；不建立供原生编辑器和工作台长期并行的适配体系。本阶段“不裁剪模块”仅指保留 Code - OSS 上游模块，不包含保留被替换的旧编辑器。

详细实现方案

发行组成与版本管理

组成	采用方式	固定与更新要求
Code - OSS	从 `microsoft/vscode` 源码构建 Web 工作台和配套 server，维护少量集成补丁	工作台与 server 使用同一 commit；不直接捆绑微软专有发行版或官方 VS Code Server 安装包
Node	捆绑该 Code - OSS 构建验证通过的 Windows x64 运行时及原生依赖	固定版本、架构与校验值，覆盖文件监听、搜索和 PTY 依赖
Python 扩展	从 `microsoft/vscode-python` 固定源码版本构建	显式列出实际必需依赖；不把安装扩展等同于自动安装其推荐项
Python Debugger	固定 `microsoft/vscode-python-debugger` 与其实际使用的 debugpy	记录扩展版本和调试器版本，确认支持当前嵌入式 Python
Python 语言服务	使用 MIT 的 Pyright 及随游戏构建的语言服务客户端	固定版本；验证标准库和 `proxy_os_ipc` 的补全、跳转及诊断；不捆绑 Pylance
Python 解释器	复用现有 `static_asset/runtime/python_embed/python-3.13.9-embed-amd64/`	原型保持 3.13.9，不另建玩家 Python 环境
格式化	配套固定版本的 Black formatter 及所需 Black，承接现有配置	核对发行许可与离线依赖，避免现有 `defaultFormatter` 指向缺失扩展
ProxyOS 集成	自有 Node 扩展、工作台集成层和 Godot 编辑器模块	工作台承接全部编辑与教学呈现；Node 提供运行能力，Godot 处理游戏业务，协议版本随游戏发布

首个构建阶段选定并记录具体 Code - OSS commit、Node、扩展、语言服务和调试器版本。计划阶段不把未经构建验证的上游 main 当作已经锁定的发行版本。交付的锁定清单必须填写精确值、来源、补丁版本与 SHA-256，不允许 latest 或运行时自动解析版本范围。

上游依据：Code - OSS 的源码分层、Web 嵌入接口和 server 构建入口支持这一组合；Python 桌面扩展需要 Node 扩展宿主。具体 API 和构建参数在锁版时重新核对，并把引用记录到固定 commit。

精简边界

考虑到 code oss 有大量可能会让没有编程经验的玩家困惑的特性，其需要被大幅精简以让其不那么令人望而生畏。除此之外，其各种在线特性也需要进行精简，避免其成为玩家电脑里的额外攻击面。

保留工作台、编辑器、文件树、搜索、终端、任务、调试和扩展运行框架。
关闭账号登录、设置同步、扩展推荐、在线 AI、遥测、实验和独立自动更新入口。扩展市场及在线资源地址不作为运行依赖。
只启用发行清单中的扩展；禁止通过运行期安装或自动更新改变扩展集合。关闭入口同时检查命令面板、快捷键、欢迎页和扩展主动弹窗，不能仅用 CSS 隐藏按钮。
Python 扩展所需的 proposed API 按固定版本明确列入许可清单，不全局开放。
教学交互、限制编辑、角色对白、表情、提交命令及课程控制集中在自有工作台集成层；Godot 保留业务验证和游戏状态。必要的上游改动采用可复核补丁，暂不做上游模块删除或构建树裁剪。
构建过程可以联网获取锁定依赖；交付物的安装、首次打开和本次四项原型能力必须离线可用。玩家自己编写的联网代码不在编辑器离线承诺内。

许可证与第三方 notices 随发行物交付。源码许可与微软商标、Marketplace 服务、扩展发行物许可分别核对，参考官方发行差异说明。

瓶颈与问题清单

哪些问题还没解，但也许我已经知道“它们不是什么”？

mod 元信息、依赖、锁文件和版本回滚仍需形成稳定流程。

下期计划

Demo 发布
- 虚拟机验证 release 发布包
- 开个 itch
- 琢磨下宣传
  - 投放平台？
  - 发布视频？
  - 完善当前的隐写小游戏
  - 上 steam？
    - steam 的规则？文案？ai 资源要求？
Demo 发布后
- 反响好
  - 细化系统、规划后续内容
    - 实用化任务时限
    - 命令行内容？（等第三章？是否需要？）
    - 远程访问？
- 反响不好
  - 找个班上