Proxyos Weekly 057

Laurence-042

May 8, 2026 - One minute read - 147 words

TL;DR 概览
核心变更都已完成，接下来完成测试后即可考虑进入beta阶段

本期目标

把 demo 从 alpha 打磨到 beta
- 第一章
  - 【低优先级】xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
  - 【低优先级】xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
- 第二章
  - 将安全内核结合内部编辑器作为小黄鸭提示来避免卡关
    - 核心系统
    - 内容补充
  - 系统测试
- 优化剧本系统架构，使存档系统以其为核心，每个 Event 完成后才存档，以此保证 Trigger+Actions 组成的 Event 的原子性
beta 打磨完成后
- 开个 itch
- 琢磨下宣传

进展速记

本期假设 / 预期

预期：

上期我搞定了剧本，当前能力基本可以支持。所以这期我应该可以把不完全支持的部分的能力补充上，然后升级第二章。同时之前那个存档系统核心的变更也可以一起合入，接下来就是测试了。

claude最近能力十分不稳定，而且也经常断连（似乎是因为内容过多，输出完成前连接就断了），我在考虑试试其他模型

结果：

……这一期睡眠质量简直要命。最好的一天是落枕，最糟的一天是半夜被蚊子叮醒，然后在即将再次睡着时被窗外的鞭炮+哀乐再次吵醒

但还是搞定了核心变更，只是没来得及测试

顺便，还得是claude

本期确定性变化

新增：

支持“消息被渲染成指定样式时才触发事件”的特性，以此让玩家查看恰当处理的消息后再触发任务
处理了所有调整/新增文案对应的游戏内容调整/新增

变更：

调整内部编辑器，进一步简化认知
重构存档系统，并让剧本系统的事件原子化，提高可维护性

修复：

删除：

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

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

调整内部编辑器，进一步简化认知

当前内部编辑器区分了“单步跳过”和“单步继续”，但这个对初学者来说应该很难理解，尤其是其还不是很理解函数的时候。而且即使是经验丰富的编程者，单步到隐藏区域/库函数后看到“丢失跟踪”也会产生困惑

这次修改将其合并成了单个“单步”，其表现为总是单步进入，但如果进入后跳转到了未显示的部分（不论是不显示的代码区还是内部函数），就表现为单步跳过

通过这种方式，可以简单地实现智能单步的效果，同时移除容易产生困惑的“丢失跟踪”

脑子昏昏沉沉的，期间差点忘记了“未显示的代码调用显示的代码，导致跟踪跳变更难理解”的边缘场景，还好GPT提醒

是的，换GPT了。因为近期发现即使是15x消耗倍率的claude opus 4.7（它啥时候把倍率从7.5x提高到15x了……），也经常出现理解偏差、忽略已有逻辑、不认真检查模块上下文的情况。Xhigh的GPT-5.4反而表现更好，claude最近真是一言难尽

重构存档系统，并让剧本系统的事件原子化

TMD 除非我以后以化能合成为生，否则我不会再对GPT有那么一丁点信任
这破玩意处理小修改是比claude sonnet顺畅，但稍微大点的变更就直接给我瞎搞
claude至少只是初始犯懒，之后会负责地实现，但GPT是初始不犯懒，但实现根本没法用——各种语法错误、自己说的计划都不按着执行、最后还TM根本不完整交付——是的，我用的就是Xhigh的，我很难想象默认的medium得是什么鬼样子

实际上，上一期结尾我进行了一次调整，也就是让剧本系统的事件原子化，以此避免以后再为了“Event的Actions执行一半，玩家直接强退，下次启动游戏后因为Event已经执行过，所以剩余Actions无法被执行0”的异常场景加各种fallback

但是在这期准备把存档管理也并入其中，完成预计的“优化剧本系统架构，使存档系统以其为核心，每个 Event 完成后才存档，以此保证 Trigger+Actions 组成的 Event 的原子性”的目标时，我意识到一个问题：这个架构会导致后续出现可维护性问题

首先说下后续规划：这个游戏预计后续会有meta要素，其中涉及让玩家“自己改应用数据来骗过npc”。因此把存档分成了控制进度、不希望玩家修改的主档ProxyOS.tres，以及控制应用显示、允许玩家修改的应用数据JSON

但在重构过程中再次审视这个系统，我意识到当前的存档机制属实分散，给维护带来了不少困难，还带来了不一致风险。而且ChapterEvent的事务也不是很能保证原子性，虽然能避免“Event trigger后actions没执行完就强退，再次启动后剩余actions再也不会执行”的问题，但是存档上还是存在“写了一个应用存档后，剩余应用存档没来得及写入游戏强退”带来的不一致风险

而更危险的是，玩家如果改坏了应用数据怎么办？如果多个备份，感觉就很冗余。但如果只有一个备份，那玩家改得合法但内容有问题，还持久化了，那就会对后续游戏内容产生严重干扰

所以我在本期做了如下变更：把所有存档收拢进主存档，并同步创建应用数据投影。如果玩家改坏了，就用主存档里的恢复。如果玩家改对了，那就触发事件写进主存档

这样就可以保证单文件写入的原子性，进而保证存档系统的一致性。同时将存档管理从GameProcessManager中心化转为各应用自行处理自己的存档数据并由GameProcessManager统一管理，以此提高可维护性

瓶颈与问题清单

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

下期计划

把 demo 从 alpha 打磨到 beta
- 第一章
  - 【低优先级】xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
  - 【低优先级】xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
- 第二章
  - 系统测试
beta 打磨完成后
- 开个 itch
- 琢磨下宣传