TL;DR 概览

状态不太好，本期咕了一半，下一期咕了。

本期目标

• 优化1-3关关卡脚本
• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

进展速记（Changelog）

新增：

变更：

• 优化1-3关关卡脚本，尝试加强剧情张力

修复：

• 脚本完成后因为midware不对导致任务没有正常完成

主要进展内容

本期4天实际上有效工作时间只有1天，感觉状态不太对劲，我需要歇一期

倒也不是说进入瓶颈、遇到啥难以解决的问题导致做不下去，只是单纯的突然觉得有些累需要休息下

原本设计上我应该先搞定第一章再歇的，但今天起床难度都和上班差不多了，所以我觉得最好还是别撑，先调整下

瓶颈与问题清单

• 暂无

下(下)期计划（Next）

• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

ANORA初步集成进了Godot，但是并没有搞定所有的适配问题。游戏的演出内容仍需优化

本期目标

• 增强ANORA录制
  • 精简回放界面
  • 使用IPC指定初始化时加载文件
  • 让外部程序可以用IPC控制播放（继续下一个关键帧.etc）
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

进展速记（Changelog）

新增：

• ANORA 回放模式的IPC
• ProxyOS 集成 ANORA

变更：

• 优化了第一关的文本，使其更加符合世界观设定，逻辑上更加通顺
• 优化了逻辑图参考，现在不用逻辑图的时候它可以自动收起来，用的时候再展开

修复：

主要进展内容

ANORA已集成进Godot，但由于逻辑图第三关才用到，而第一关的文本就很糟糕，所以花了不少时间优化第一关的文本。

不过整体进度还算符合预期，上一期重构的ANORA架构让IPC十分好做，所以本期基础目标仍然按时达成了

瓶颈与问题清单

• 暂无

下期计划（Next）

• 优化1-3关关卡脚本
• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

ANORA的回放功能（无UI模式）将将完成，但还需要适配

本期目标

• 无UI模式(纯逻辑图，游戏内通过GDScript控制)
  • 初始化图
  • 控制按步执行
  • 一些为了通用的动画演示准备的画面效果
  • 集成进GD
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

进展速记（Changelog）

新增：

• ANORA 录制模式

变更：

• 使用状态机增强了执行器的运行逻辑，现在支持单步执行
• 优化了节点显示，现在执行状态的显示不会再导致节点抖动

修复：

主要进展内容

ANORA的逻辑图执行的录制回放已完成，速度低于预期，导致没来得及集成进Godot。

进度状态不佳的主要原因

• 最初我把录制回放视为单独的模块了，但是实际上录制回放本质上应该是侦听执行器事件、模仿执行器发事件。这个实现思路差异在前两天导致了大量的状态不一致的debug和返工
• 设计时没有明确各个vue模块、composition的边界，导致回放和主图的加载分别实现了两套反序列化逻辑
• 最初想简单了，想要按事件设Carousel，但是忘了port值变更、节点状态变更、边传值都是高频发生且强绑定的，导致实际易用性糟糕不得不重构

下次需要更正的地方

• 实现任意模块前先思考下其和现有模块的关系，然后尽量复用、增强现有模块，避免出现一个功能多个实现
• 需要预估数据量和分布，然后选择恰当的交互模块

瓶颈与问题清单

• 暂无

下期计划（Next）

• 增强ANORA录制
  • 精简回放界面
  • 使用URL指定初始化时加载文件（或者其他方式？）
  • 让外部程序可以用IPC控制播放（继续下一个关键帧.etc）
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

ANORA的前端核心逻辑已经完成，初步调试无误，也具备了通过 wry 节点与 gdscript 交互的能力

本期目标

• 完成逻辑图系统，考虑用TypeScript+Vue/React之类的搞一个ANORA原型，然后通过wry集成进游戏，通过wry的事件系统进行操作
  • Node框架
  • 分层Port
  • Connection折叠/展开
  • 逻辑图计算
  • 简而言之就是之前的AWW的所有除了定制节点之外的基础计算和显示逻辑，时间有点紧，毕竟这些东西当时我用了好几个月内的工作间隙。但我觉得有善用claude应该能及时完成——Again
  • 集成进游戏
    • 无UI模式（纯逻辑图，游戏内通过GDScript控制）
    • 适配相关关卡脚本

进展速记（Changelog）

新增：

• ANORA 核心实现
  • 虽然看起来只有一条，但改的是真的多啊
• ANORA 扩展 mod 加载

变更：

修复：

主要进展内容

NORA的前端核心逻辑已经完成。将上周遗留的设计问题收尾后，本期对ANORA进行了实现。

相较于其前身 AAW 的核心升级

• 更灵活的节点执行控制
• 更高效的计算
• 可扩展的Node、Port甚至Executor
  • 实际上核心的定义哦都是通过扩展机制加进来的
  • 所以说Rimworld的那个名为Core的mod真是个天才的构想

距离接入 ProxyOS 仍需完成的内容

• 无UI模式(纯逻辑图，游戏内通过GDScript控制)
  • 初始化图
  • 控制按步执行
  • 一些为了通用的动画演示准备的画面效果
• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

瓶颈与问题清单

• 暂无

下期计划（Next）

• 无UI模式(纯逻辑图，游戏内通过GDScript控制)
  • 初始化图
  • 控制按步执行
  • 一些为了通用的动画演示准备的画面效果
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

ANORA的设计花费了比预期更多的时间，目前还未达到目标

本期目标

• 完成逻辑图系统，考虑用TypeScript+Vue/React之类的搞一个ANORA原型，然后通过wry集成进游戏，通过wry的事件系统进行操作
  • Node框架
  • 分层Port
  • Connection折叠/展开
  • 逻辑图计算
  • 设计

进展速记（Changelog）

新增：

变更：

修复：

主要进展内容

ANORA的设计难题

虽然四天前我说“毕竟这些东西当时我用了好几个月内的工作间隙。但我觉得有善用claude应该能及时完成”，但实际上比我想象得更难，仅仅是设计就几乎花掉了这一期所有时间

设计文档中的致命问题

我第一天写了ANORA的设计文档。我以为已经很全面了，毕竟我是基于之前已经实现的AAW的经验，覆盖了各种实体的定义、执行逻辑、功能细节、项目结构等等

但是当我用claude检查的时候，我发现了很多致命问题

问题1：推还是拉？

在ANORA的前身AAW里，逻辑图里的顺序是“拉”的，即执行器只记录节点间的依赖关系，当某个节点所依赖的节点都执行完成后，就把数据从其依赖的节点的出Port上拉到这个节点的入Port上供这个节点使用

ANORA为了给节点更多的自由度，使节点可以根据当前入Port输入状态决定自己是否可以执行（为了提供现代编程语言的可选参数特性），这就必须使用“推”的，即一个节点执行完成后会把它出Port上的数据推到下一个节点的入Port上，然后节点才能做出判断

但这产生了一个问题：ANORA需要和AAW一样支持Port的嵌套。AAW在拉的模式下可以先拉外层Port再拉里层Port来保证里层Port的数据优先级最高，以此支持入Port数据模板之类的写法。但ANORA的推的模式就无法支持这个特性了

问题2：要不要支持Port的嵌套？

遇到上述问题后，我首先想的就是“问题的前提条件是否是无法改变的”，也就是是否一定要支持Port的嵌套。直接用get/set节点行不行

思考后我觉得是必须要支持的。因为我设计时就想好了这个项目的演示用后端——API录制回放。是的，还是AAW。但不是因为有个垃圾底层系统需要我包装，而是因为这个任务同时涉及了强时序、复杂数据流、异步调用这三个节点编程系统能发挥最大作用但又最难同时满足的场景，它会成为ANORA的试金石

而为了适配复杂数据流，“从默认数据模板中改一个数据”的操作必须要足够简便，最多只能用独立的参数节点提供默认数据模板，不能通过额外的节点数据合并。毕竟合并数据如果不使用嵌套Port，就必须通过某种更程序员的方式指定属性路径了，这显然和ANORA的设计目的相悖。

所以问题1必须要解决。但在思考解决方案的时候，我遇到了另一个更严重的问题

问题3：同步还是异步？

在ANORA的前身AAW里，逻辑图的执行是全顺序的，即使在一个批次里，节点的执行也是顺序的。当时这个设计是因为我没有很多时间实现一个复杂高效的系统，所以当时我就想只要在性能可以接受的情况下debug尽可能方便就行。但是ANORA自然不能这样，所以在我最初的设计中执行是全异步的。这使效率最大化，而且不管是用在什么任务中都足以胜任。

只能说理想是美好的。在全异步的模式下，我想不到一个可以同时满足易用、直观、可维护的循环逻辑执行方案。我参考了UE、ComfyUI等流行的节点编程系统，但它们要么就是直接封装编程语言里的while为节点，要么就是根本不支持流程控制。

问题4：要不要null？

这反而是最小的问题了，这玩意又不是给经验丰富开发者用的，拒绝null那就得引入更多保护措施，反而导致其上手门槛更多。一番折腾后我才明白了这个道理，然后释然地添加了null

解决方案？

显然，问题2和问题4都解决了，关键是1和3。

最后，我想到了这么一个设计：让流程控制节点可以一次激活多次执行

而这个方案不仅解决了两个问题，还让ANORA彻底甩开了AAW到达了全新层面。

ANORA的思想

更复杂的节点

之前我一直把节点当成函数调用的抽象，这使我陷入了误区——调用函数的语句天生就没有分支！

虽然在AAW里通过“以数据为核心，节点只有其需求的数据都输入后才能运行，运行后可以选择性地在特定出边输出数据”的方式实现了比UE更易用分支写法，但是其循环逻辑仍然十分粗糙、难以编写——它产生了环

而有环的图天生就是不直观的

但当我不再把节点当成一个函数，而是以更自然的方式进行比喻时，一切迎刃而解了

节点就像一个自动加工机：

TL;DR 概览

Terminal总算是搞定了！fastai确实咕了，爽玩ComfyUI

本期目标

• 修好Terminal

进展速记（Changelog）

新增：

变更：

• 从之前的ConPTY方案改成了自己做PTY，结合BetterProcess来做异步程序调用与交互

修复：

• Terminal修好了

主要进展内容

Terminal修复完成

之前我说“目前我在使用“gd命令每发一行，同步给pty发一行以#开头的命令，并在回显中过滤掉#命令及其回显”的思路，不过它的状态转移我还没想清楚，直接扔给claude只会得到水多加面面多加水的结果，所以我得好好想想再继续”，但是实际思考后发现由于PTY本身的复杂性，根本不可能以可维护的方式将其实现

我写了篇长文边写边理思路，然后提出了几个方案又一一否决

方案1-拦截

通过在PTY里执行#__PROXYOS_SYNC__#这种注释来在标记行的同时让PTY光标进入下一行。同时拦截包含这种标记的行，避免其被显示到XTerm上。以此在不影响Xterm输出的情况下把PTY的光标同步到GDScript命令回显的下一行。#__PROXYOS_SYNC__#不可在 GDScript 输出中使用。

• 优势
  • 完整支持命令行为，对于那些在输出中主动设置颜色、换行之类的命令支持良好
• 劣势
  • GDScript命令输出存在单行长度限制，这会降低可维护性
  • PTY 行为并非稳定规范，后续变更可能导致完全乱套（比如移除了多行输入的>>行为）
  • GDScript命令输出较长时可能耗时过长，且每次都整页刷新的PTY输出可能会导致性能问题（类似top命令那样的）

方案2-单纯把PTY当异步os.execute

不再使用完整PTY，而是由自己维护XTerm，只在用户按下enter发送命令时，判断是不是GDScript命令。

是的话命令输出直接输到XTerm里

不是的话暂停侦听PTY，在PTY里使用三次Ctrl+C清除当前命令、潜在执行中的程序、兜底一次来获取单纯的输入提示符格式，再次启动侦听后发送命令。从PTY响应中过滤掉命令输入行、过滤掉设置光标的CSI、识别并替换输入提示符为自定义的输入提示符

• 优势
  • 兼容性良好，实现简单
• 劣势
  • PTY的输入提示符在不同系统上五花八门，即使是同一个系统不同版本的PTY程序都有些许不同，适配较为困难
  • 无法支持类似npm那种会在输出中使用CSI来实现转圈的\|/-的行为，反而会输出一堆这种序列
  • 三次Ctrl+C可能仍有不兼容情况

方案3-直接自己搞个有cd、ls的极简console

之前一直折腾PTY主要是因为OS.execute阻塞，而OS.create_process又没法拿到stdout输出

但现在发现了BetterPorcess，这就好办了

• 优势
  • 兼容性极佳
• 劣势
  • 难以处理方向键
  • 本质上需要自己实现一个PTY

最终方案：基于方案3，尽量实现相关特性

目前支持的特性如下

• 右键复制/粘贴
• Ctrl+Shift+C粘贴
• Tab补全
• 自定义命令
• 自定义python脚本调用
• 自定义中间件来处理特殊输出

爽玩ComfyUI

哎，ComfyUI真不错。我发现我以前收藏的不少图实际上就是ComfyUI出来的

所以我更新了我的图片下载器，它可以识别到新老图片里的ComfyUI特征，然后重命名时给后缀名前面加个.comfy来备注

爽玩各种工作流和prompt，还找到个不错的模型/lora网站

瓶颈与问题清单

• 暂无

下期计划（Next）

• 完成逻辑图系统，考虑用TypeScript+Vue/React之类的搞一个ANORA原型，然后通过wry集成进游戏，通过wry的事件系统进行操作
  • Node框架
  • 分层Port
  • Connection折叠/展开
  • 逻辑图计算
  • 简而言之就是之前的AWW的所有除了定制节点之外的基础计算和显示逻辑，时间有点紧，毕竟这些东西当时我用了好几个月内的工作间隙。但我觉得有善用claude应该能及时完成

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

问题远比预想的多，一直在调Terminal和修改架构

本期目标

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

进展速记（Changelog）

新增：

• 一个仍有很大问题的，在修复阶段用于辅助说明的逻辑图系统（也是为ANORA进行技术试水，其前身AAW的架构可能有些过度设计，这次借着这个机会试试其他架构）

变更：

• 自删除动画从python改成gdscript，以此绕过pty光标位置和xterm对不上的问题

修复：

• 尝试修复gdscript命令执行后导致光标偏移的bug，但没修好

主要进展内容

基本没进展，一直在和命令行死磕，而且完善Rimworld小工具所需的时间远比预期的多，其发挥的价值远比预期的少，说实话心态有点崩。下期我准备缓缓，暂停fastai学习，只追求在心态不崩的状态下把Terminal修好

Terminal

本质上这是我给自己挖的坑。当时测功能的时候没多试几个命令，结果现在才发现gd命令会出问题

其核心问题是，gd命令只会影响xterm状态，但pty却以为自己还和xterm同步仍在给xterm发光标位置信息，双方的状态不一致导致了显示灾难

目前我在使用“gd命令每发一行，同步给pty发一行以#开头的命令，并在回显中过滤掉#命令及其回显”的思路，不过它的状态转移我还没想清楚，直接扔给claude只会得到水多加面面多加水的结果，所以我得好好想想再继续

沉迷开发Rimworld小工具

rimworld-ordinatus-calculi Demo

实际上这一期又画了一半时间完善这个

然后投了一篇宣传到Reddit的Rimworld板块，一篇到Rimworld的Steam社区指南

结果前者被删帖，后者没人看……

不过我确实在实现这个的过程中学到不少东西，比如怎么描述需求更加合适、demo迭代式开发试水、plotly、界面布局设计等等，也算是不虚此行

瓶颈与问题清单

• Terminal的显示和pty内部状态的同步
• 剧本完成后，我意识到设计当初根据大纲写的恢复程序框架有点死板了，下一期我得花大力气搞定这些交互式演出的Python脚本，其中一些还得用eval来保证玩家体验

下期计划（Next）

• 修好Terminal

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

这一期咕了

本期目标

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

进展速记（Changelog）

新增：

• 第一节脚本
• 第二节脚本

变更：

• 无

修复：

• 无

主要进展内容

这一期基本咕了，倒不是遇到啥难题，就是单纯的麻烦，然后失去了动力效率偏低。

感觉很不爽，于是去继续搞fastai，结果被kaggle一套组合拳下来彻底干不下去了

kaggle的组合拳

当时我在看这个fastai的官方教程 https://colab.research.google.com/github/fastai/fastbook/blob/master/09_tabular.ipynb

里面需要使用kaggle的数据，而且后面的内容都是依赖这个数据的 注册kaggle，填一堆信息，获取token，执行 kaggle 401，查了下发现是kaggle把colab给ban了 发现kaggle也提供了在线notebook执行器，但因为这个ipynb文件超过1MB不让导入 手动裁掉了文件中比较大的图片，重新导入执行 发现kaggle的环境装不了第三方依赖库，而且也不给GPU资源 只能本地搭环境，结果因为fastai和pytorch的安装顺序搞反了，导致装上了CPU版的pytorch，GPU的没装上 删除venv重新装依赖 装完依赖执行ipynb，结果发现里面使用了没列在requirements里的依赖 补装后再次执行 kaggle 403，查了下发现是kaggle要求用户签署对应比赛的同意书才能下数据 找半天没找到同意按钮，结果找了一圈后发现kaggle已经不提供加入老比赛下载老比赛数据的方式了 走投无路问ChatGPT，她说fastai的sample里可能有给了我个URL，404 再次问ChatGPT，她说github里可能有给了我个URL，404 血压拉满再次要求ChatGPT核查，她说她可以把她那里的数据给我，但需要我等下 饱含怀疑地要了数据，结果她给我发了个ChatGPT的聊天URL——还正是我问这个问题的聊天URL

血压爆了

沉迷开发Rimworld小工具

心态崩了之后，自然就得找发泄渠道。于是我去玩了半天Rimworld，然后发现其中两个武器我很难抉择，它们造价相差无几，但穿甲、伤害、不同距离的精度都相差很大，我没法很简单地算出哪个更适用于我的游玩风格。于是……

我去做了个Rimworld计算器

一开始只是准备给定命中率、穿甲、理论最大DPS，画敌人护甲和实际DPS的关系曲线的，结果后来越做越投入，连曲面和多层护甲都整出来了……

就这么做了两天，一看时间——哦豁，ProxyOS咕了

不过今天顺利的话我应该能把它的链接放下面

rimworld-ordinatus-calculi Demo

瓶颈与问题清单

• 剧本完成后，我意识到设计当初根据大纲写的恢复程序框架有点死板了，下一期我得花大力气搞定这些交互式演出的Python脚本，其中一些还得用eval来保证玩家体验
  • 我确实可以去戳copilot claude，但是之前他没能很好地实现第一章的开始动画演出，而且第一节写得也有不少问题，扯皮两三轮后还是手改了一堆

下期计划（Next）

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

第 1 章剧本终于全部写完了。 花了远比预期更多的时间。 但系统与玩家交互的逻辑终于成型。

本期目标

• 完成第一章游玩内容
  • 拖了整整 3 期，这期怎么说也得搞定了

进展速记（Changelog）

新增：

• 第一章的游玩剧本
• 第一章的游玩框架

变更：

• 无

修复：

• 无

主要进展内容

这一期花费的时间仍然比预期的长，我在平衡可玩性、剧情合理性、难度、教育能力上花了不小力气。

难点：六节结构带来的设计压力

这第一章总共6节，我每次写完一节都会缺乏灵感不知道怎么设计新的游玩内容。

毕竟一招用一整局那是官方教程会干的事，这个终归是个是个游戏，然后才是个教程——但它毕竟也是个教程。

于是我需要为每一节设计不同的操作逻辑来保证玩家新鲜感、不能让玩家卡关影响其学习积极性、玩家得有参与感不能纯看文本、不能让玩家在这个阶段写太多代码（用Terminal写程序那是上世纪才会干的事）、得让玩家能学到东西。在这些前提下，还得保证世界观自洽、作为引导者的系统既不能太聪明导致玩家全局按yes，也不能太蠢导致尬住、系统必须要在世界观框架下卡在它可能会卡住的地方，而不能硬卡、每次卡的地方需要不一样才能让玩家不至于“啊……又来”

在这种情况下，虽然我大体对这6节要写什么内容、系统大概处于什么阶段有个大概的概念，但是具体细节是写了一节后就不知道下一节还能写啥的状态。

方法：用 ChatGPT 当头脑风暴对象

所以我自然去戳ChatGPT了——逻辑能力比ChatGPT强的Claude只会工程代码，没啥创造性。而创造力比ChatGPT好的又没啥逻辑。

但是吧……虽然ChatGPT都快成白月光了，但是她在创造性上确实还是不太行，记性也不太行。以至于她总是在尝试使用我在前几节已经用过的方案，即使明确了要求，她也总是过度依赖第一节里用的“根据日志修系统”的设定。而对话再长一些，她就又忘了早些时候的要求。（看来我暂时不用担心她抢我工作）

于是整个过程本质上属于是对着小黄鸭头脑风暴，所幸这个小黄鸭能很好地整理我的思路，所以我还是得以吭吃瘪肚地搞定了第一章的内容。

不过在第一章剧本写完后，她在保证角色语气一致、优化玩家细节体验、避免出现章节间割裂、玩家心理落差等方面确实表现极佳——她甚至还看出来了其中一个人名RABOOF的梗！

我想在细化后续内容时，我也能使用这种模式，即将 ChatGPT 作为头脑风暴的小黄鸭，然后在方案定型后再由她规范语气、把控节奏。

瓶颈与问题清单

• 剧本完成后，我意识到设计当初根据大纲写的恢复程序框架有点死板了，下一期我得花大力气搞定这些交互式演出的Python脚本，其中一些还得用eval来保证玩家体验
  • 我确实可以去戳copilot claude，但是之前他没能很好地实现第一章的开始动画演出，而且第一节写得也有不少问题，扯皮两三轮后还是手改了一堆

下期计划（Next）

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

把Terminal的方案退回了真实Terminal，修了些第三方库的bug，然后爆改了第一章

本期目标

• 实现靠谱的Terminal
• 重构第一章游玩结构
• 完成第一章游玩内容

进展速记（Changelog）

新增：

• 无

变更：

• 回退到了真实Terminal方案
• 将最开始的“自动进行下一个教学”改成了“玩家需要手动依次触发相关教学”

修复：

• 修好了GodotXterm里野指针导致的高频偶现问题

主要进展内容

在详细分析后，发现一旦涉及执行外部程序并实时显示stdout，那么自建Terminal的问题就会多到难以置信，而且市面上也缺乏支持良好的——这本质上就是实现正经Terminal了

所以最后还是切回了真实Terminal的方案，并借助Copilot修好了那个间歇性好使间歇性不好使的问题。问题路径是

• 在获取cwd_ 参数时，使用了const char* cwd_ = p_cwd.utf8().get_data();
  • .utf8()创建一个临时的 UTF8 buffer（CharString）
  • .get_data()取出它的内部 char*
  • 临时对象被销毁
  • cwd_ 指向已经释放的内存 → 悬空指针
• 随后又使用std::string helper_path = p_helper_path.utf8().get_data();
  • .utf8()再次分配到了cwd_ 指向的内存上
• 在CreateProcess时引用cwd_ 作为工作目录
  • helper_path 是一个可执行程序，而非目录
• ConPTY进程创建失败

然而上面那个并非唯一问题，因为它没有正确处理pipe，导致同一个PTY对象只能fork一次。虽然每次instantiate也不是不行，但还是借助Copilot+Claude给修了

然后就是剧本和一开始有差异。最开始的设计中，我使用“自动依次执行对应的python教学脚本”的方式。但我试玩了一下发现这样很无聊。所以加了俩自定义命令diagnose和manualfix，来分别展示目前修复进度和调用教学脚本。虽然玩家的游玩路线没有变，而且本质上是增加了麻烦，但是自己执行命令来启动脚本对于新手来说应该还是有些意思的，而且即使对于老手应该也能冲淡一个个教学脚本带来的粘滞感

再之后就是我重写了第一章的前两节，之前的剧本有点太挫了，没有很好地和游戏世界观相融合，所以我正在整个重写

瓶颈与问题清单

下期计划（Next）

• 完成第一章游玩内容
  • 这个真得完成了，都TM拖3期了

试玩版

暂未达到第一个试玩版的发布标准