Proxyos Weekly 068

Laurence-042

June 15, 2026 - 2 minutes read - 246 words

TL;DR 概览
翻译完成；现在子窗口有了对应的任务栏图标而非使用主窗口图标；玩家完成脚本执行本地测试后会自动后台全量测试，如果测试通过，通过桌宠提醒玩家

本期目标

完成翻译
优化任务栏图标？
优化任务提交流程？
用英语通玩一遍
更多内容
- 支线任务
- 更多任务
- 实用化任务时限
- 命令行内容？（等第三章？是否需要？）
- 远程访问？
- 更精细化管理事件而不是按章组织？
开个 itch
琢磨下宣传

进展速记

本期假设 / 预期

预期：

虽然说是要咕，但躺着反而思维活络了，还想到了其他可以优化的点，结果躺不住了……

这期就让 agent 作为主力吧，这几个优化点应该都是需求十分明确、路线十分固定的，应该问题不大

结果：

agent 主力……唉……除了 claude 真没人能胜任

deepseek-v4-flash：提取个变量还行，搞翻译都搞不明白
mimo-2.5：稍微复杂点就开始没完没了地 reasoning
deepseek-v4-pro：问题稍微复杂点，需要多步实现，就开始暴露 agent 环境下长对话注意力涣散的问题
minmax-m3：跟它说了要咋改，为什么要这么改，说是懂了结果转头就给我搞了个南辕北辙
qwen3.7-max：能干点活，翻译也算是能翻译，但知识面似乎很挫，或者说没法在涉及多模块时有良好架构本能，而且理解能力堪忧
gpt：这破玩意天天给我埋雷，完全没法用来写代码
claude-sonnet-4.6：依旧唯一真神
claude-opus-4.8：高攀不起
claude-fable-5：更加高攀不起

哦对，预期要做的翻译、新的优化点都搞定了

本期确定性变化

新增：

现在游戏内的应用子窗口也有自己的 icon 了，玩家更容易在任务栏中找到它们了
现在当玩家 f5 执行脚本进行基础测试时，如果能通过全量测试，安全内核会提醒玩家可以提交

变更：

修复：

修复翻译流水线的 speaker 提取遗漏了 lesson 配置的 bug
修复导致翻译流水线和翻译 llm 无法良好协同供的各种问题
- 详情参见主要进展内容-翻译流水线的预期之外问题

删除：

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

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

翻译流水线的预期之外问题

当文档较长时，即使只占了 max context 的不到一半，模型注意力也被稀释得无法完成所有翻译，而只是完成了最后一段的翻译。因此引入了过长文档切分机制（每个文档都有完整的翻译任务要求等上下文）

llm 在翻译上下文场景内容较长时，会被干扰导致忘记需要翻译/把需要翻译的段落也视为不需要翻译的上下文。因此将上下文场景使用代码块包裹

上下文场景的代码块标记和剧本上下文里的代码块标记冲突，导致 llm 再次无法分清上下文和翻译目标。因此将上下文里影响较大的 markdown 标记去除，并使用<pre>包裹上下文

有时候同一组的文本的上下文有包含关系，这导致上下文被多次重复，进而导致 llm 过度关注上下文里的内容而忘记了翻译。添加了上下文合并机制。

有一个子文档因为待翻译条目过多（同等总 token，但是单个条目普遍较短），llm 输出用时过长被服务提供商终止，无法正常完成翻译。使用智谱清言的网页完成了，不得不说智谱清言真是处理大文件的唯一选择。

虽然智谱清言处理了文档，但是仍旧出现了部分条目的错漏。进行了手工修复。

子窗口的任务栏图标全是默认 godot 图标问题

受限于 Godot 目前没有直接暴露给用户的 API 来设置子窗口（通过 Window.new() 生成）的窗口 icon 的现状，这游戏目前打开的子窗口的 taskbar icon 全是主窗口的 icon。

如下是 Github Copilot 的整理（这可以说是其最大优势了）

Window 类中没有 icon 属性：查看 scene/main/window.h 和 scene/main/window.cpp，Window 类没有 set_window_icon() 或类似的公共方法来设置窗口图标。
DisplayServer 层面有支持：在 platform/windows/display_server_windows.cpp 中存在 window_set_icon() 方法，但这是内部 API，不对用户代码暴露。

子窗口默认继承主窗口的图标：根据代码注释和实现：

// Inherit icons from MAIN_WINDOW for all sub windows.
HICON mainwindow_icon = (HICON)SendMessage(windows[DisplayServerEnums::MAIN_WINDOW_ID].hWnd, WM_GETICON, ICON_SMALL, 0);

子窗口在创建时会自动继承主窗口的图标。

考虑到这是我这个项目架构下的需求，大部分游戏/工具确实不太可能需要这个特性，我准备使用比较 hack 的方式来在项目层级做适配。也就是使用如下方案：

由窗口管理器初始化并维护 window_icon_agent.py 的进程
窗口管理器打开窗口时，通过 DisplayServer.window_get_native_handle(DisplayServer.WINDOW_HANDLE, window_id) 可以直接拿到操作系统原生的窗口句柄（在 Windows 下就是 HWND）。
通过 ipc 系统将图标 png 的 base64 和 HWND 传递给window_icon_agent.py 的进程，其会使用 Python 的 ctypes 库或者 pywin32 库设置对应窗口的任务栏样式。

这个还产生了一个有意思的结果：在 windows 下主窗口和子窗口是被折叠为一个任务栏图标的，而鼠标悬停在上面会显示不同图标的子窗口。这个结果是我预计之外的，不过倒是十分方便，这样玩家可以在有一定沉浸感的同时，明确区分游戏窗口和操作系统原生窗口避免混乱

不过这地方确实没适配 linux 和 mac……以后如果需要的话再说吧

任务流程优化

目前这游戏的核心游戏循环是

玩家通过与游戏中各个信息源交互（比如读聊天软件消息）接到任务
一个任务可以有多个任务要求，目前任务要求分两类：信息收集和脚本编程
- 为了满足信息收集类任务要求，玩家需要在游戏内浏览器里浏览网页并点击关键信息得到“信息段”
- 为了满足脚本编程类任务要求，玩家需要在随任务接受出现的脚本框架里修改、实现功能得到“目标功能脚本”
玩家把信息段或目标功能脚本拖动到对应的任务要求上，如果符合要求（对应的信息段、通过测试集的目标功能脚本），就可以满足任务要求，所有任务要求完成后，任务被视为完成

但我在想，比起让玩家拖动脚本文件，实际上我可以通过扩展预置的 vs code 任务配置，使其可以自动在玩家执行脚本进行测试的同时提交检查，自动完成任务要求来减少操作负担。但我又担心这会破坏“拖动任务相关实体到任务需求上以完成需求”导致玩家同时处理两套机制觉得更别扭

随后，我寻思了一会，我觉得关键是：如果玩家经常遇到能通过脚本内置的基本测试，却无法通过提交检查的情况，那么玩家将不得不反复提交检查，此时提交检查才是真正的摩擦

因此，实际上应该做的是：

配置预置 launch.json，使脚本执行完成且不异常退出的情况下，自动执行一个 task
task 会调用 proxy_os_ipc 里的逻辑，通过 ipc 通知 godot 脚本出现变更
godot 进行验证
- 验证失败，静默，不做任何反应
- 验证成功，不自动提交，而是让桌宠说一句“我觉得刚刚你运行的脚本应该可以了”之类的提醒玩家可以提交

这样既能免去玩家反复提交检查的摩擦，又能保证交互的一致性

瓶颈与问题清单

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

下期计划

用英语通玩一遍
更多内容
- 支线任务
- 更多任务
- 实用化任务时限
- 命令行内容？（等第三章？是否需要？）
- 远程访问？
- 更精细化管理事件而不是按章组织？
开个 itch
琢磨下宣传