Proxyos Weekly 098

Laurence-042

September 24, 2026 - One minute read - 197 words

TL;DR 概览
重构顺利完成，地图与时间系统正式落地，核心流程重新验证通过。ProxyOS 当前已基本转入内容补完与 Demo 发布准备阶段。

本期目标

时间系统重构
地图前端重构
更多内容
- 支线任务
- 更多任务
- 实用化任务时限
- 命令行内容？（等第三章？是否需要？）
- 远程访问？
- 更精细化管理事件而不是按章组织？mod 支持？（这个早完事了，一直忘记标了）
用英语通玩一遍
开个 itch
琢磨下宣传

进展速记

本期假设 / 预期

预期：

这期应该至少能重构完并测试核心功能，但具体内容编排可能得下期

结果：

地图系统和时间系统都重构完了，而且重新进行了整套流程验证。内容编排也补了一些，下期国庆前的两天应该能把内容也补一补，国庆后就能进入 demo 发布了

本期确定性变化

新增：

添加了非连续的时间跳转 action
- 用于在第一章结束后，让第二章开始时直接让时间快进一天。因为剧情上第一章需要花费一天，但是第一章并没有可以让玩家休眠的机会
将茶馆的广告位占位补全，这些神经小广告应该会给玩家带来些乐趣

变更：

优化 ipc 原语架构，现在不会都挤在一个类里了
将一些 ipc 原语切到了虚拟 api 实现，以此区分应用层和基础层
优化了模拟 http 的写法，这样玩家可以更方便地使用 request 的 response
优化了第二章末尾的一些表述
优化了货币系统的反馈信息

修复：

修复无法正常加载第一章课程的 bug（之前寻思不会有影响就直接跳过了，没想到改了序列化后出了问题）
修复最小化的应用窗口仍然会在窗口贴靠布局里占用空间的 bug
修正上期做了 markdown 升级后没处理全的、有旧 bbcode 的翻译
修复了如果玩家首先向某个联系人发消息，联系人名称会显示为玩家名称的 bug（本质上是因为之前偷懒不想写联系人名称，直接取了第一个发信人的名称。但这样会导致无法让玩家首先向某个联系人发消息，能力会有缺失）
修复上期改 ipc 的时候忘记改 mock 导致的玩家脚本校验失败
修复了购买的 hook 没有正确触发事件的 bug
修复“只有播放完任务完成动画才刷新任务列表里的任务状态”和“不聚焦在对应任务上时完成任务不会在其他任务上弹任务完成动画”结合起来导致出现的任务列表里任务状态可能未更新的 bug

删除：

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

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

关于 text2image

事实证明，我的美术水平超常发挥也就只是能一笔画火柴人

所以美术资源肯定得看 ChatGPT 和 Gemini 了——本地的 z-image 简单概念图能生成，但是描述一复杂就完蛋，而且修改也很难稳定修改，所以还是得用这俩

其中 ChatGPT 的相对好些，主要支持随时修改。

但是其能力依然有严重限制，比如难以保证一个物体的三视图自洽。我尝试了诸如三视图在一次生成中联合生成、写脚本拼接参考图为联合三视图然后要求其基于参考图改、生成后给它纠错等等方案，但是仍然无法生成稳定可用的资源……

不过对这个游戏应该没啥影响，这游戏主要是单视角的平面资源。主要是我还在并行开发一个 rimworld 的 mod，那里面的游戏资源需要三视图，纯 t2i 属实没啥好方案……

这期我通过给其一个大致方向生成一批风格对比，然后选定一个风格要求其固化要求成为风格指南，再之后让后续 session 参考指南的方式，实现了风格在游戏层面统一、但具体细节仍然对每个广告有特定偏向的茶馆广告位的资源

不过虽然能修改是很方便，但是再方便那也是得一次次改的……比预期的耗时还是长了不少

问题核心还是“描述太详细的话一张图 prompt 得写十分钟”和“描述太不详细的话得用十分钟一一修正 llm 错误印象”的矛盾，目前我还是只能按照经验来控制详细程度，或者直接让其批量生成后选一个作为基石进行调整

Zcode……

我真服了，这个月初我看上个月 GLM 体验十分优异，完全可以当主力，就订了个季票。

结果最近一周消耗量暴增，而且能力出现了显著退化。其之前优秀的指令遵循性在这周的两个项目里也都消失不见了，转而是我要求使用事件触发它给我写轮询之类的情况——而且反复发生

它甚至能把“而且当前 DefModExtension_BoardingProfile 的实现整个就不符合要求，doc\太空战架构。md 明明说的是默认八向，结果给写死成八向彻底堵死了自定义 shuttle 推进器布局的方向。按理说这个应该是给一个推进器 li，li 里指定每个虚拟推进器的推进矢量位置和大小”这段给解释成“只写一个 li，然后在 li 里给写死的八向推进器中的一组调推力大小”

然后查了下，发现了更难绷的 https://github.com/zai-org/feedback/issues/743

简单来说，它使用滑动窗口管理每次发的对话——完美规避了 prefix cache

真是绝了……

现在我必须和管理 codex 一样给它口述完整算法和设计背景，口述完还得看它 plan 里有没有违背，实现完还得看它实现得和 plan 是不是一致的

我甚至不能信任它的调查结果，即使我要求它检查是否有多重实现，它照样会对着明显一堆差异但功能应该相同的两个函数说是必要的差异，除非我和去年一样“你要以刻薄的、不能接受任何多重实现的、总是要求使用相同函数审查员角度，检视 xxx 流程和 xxx 流程的每一处实现，然后给我一个调用序列对比表格”这样搞 prompt，它才能正经干活

它智力（理解复杂需求并进行正确需求抽象的能力）本身就没有 codex 好，我上个月对它爱不释手纯属因为它智力够用，而且对我的方案理解没偏差、有偏差会直接和我报告——换句话说，我看中的就是它在智力满足需求的同时有良好的工程纪律，但这期它表现出的工程纪律都让我忍无可忍了

但目前确实也没啥竞品，直接上 codex pro 的话太贵，作为干活补充的话 deepseek 智力还无法满足需求，kimi……也许我下期可以订个 lite 试试，看看怎么样

瓶颈与问题清单

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

AI 美术已经能稳定生产 ProxyOS 所需的单视角素材，但一致三视图仍无可靠方案。
Zcode 当前上下文管理和工程纪律明显退化，短期需要重新评估辅助编码模型组合。
mod 元信息、依赖、锁文件和版本回滚仍需形成稳定流程。
也许加载性能还能优化一下

下期计划

更多内容
- 支线任务
- 更多任务
- 实用化任务时限
- 命令行内容？（等第三章？是否需要？）
- 远程访问？
开个 itch
琢磨下宣传