Proxyos Weekly 049

Laurence-042

- 2 minutes read - 315 words

TL;DR 概览

序章优化搞定，下期休息

本期目标

  • 把 demo 从 alpha 打磨到 beta
    • 序章
      • 玩家一开始得到的信息太少，以至于缺乏目标和对世界观的了解。工作手册又因为其形式难以让玩家代入，导致玩家不清楚自己在做什么，即使发现用户死亡也困惑大于惊讶
        • 考虑让玩家短暂扮演那格式化前的上一任节点（和 ghostine、何澈的短暂交流，随后被格式化），而非一开始就让玩家两眼一抹黑当格式化后的节点
      • 初始化任务
        • 工作手册太繁琐，把 界面组件 和 核心工作流程 两段合并，核心工作流程每一步都象当前一样指向对应区域。演示图用符合当前情况的，并省略具体名称。其余提及 POCKET、ARCHIVE、SPIDER 的任务资源也需要对应修改
        • 基准测试报告需要更新
      • 摄像头任务
        • 我得在数据段的部分提下图片也可以点，并在任务描述里也写下，避免用户在第一章末尾看到图片不知道怎么操作
      • 到第一章过渡比较生硬（一个待确认对话框，先前被认为有助于渲染突然、无措的情绪，但当前氛围感不足以支持），考虑增加演出
        • 剧本
        • 实现
    • 第一章
      • 系统恢复操作指南 的认知负担太重，直接去掉整个 系统恢复操作指南，然后使用一个独立的、默认启动的程序来带着玩家敲一遍，完事之后再让玩家用 diagnose 和 manual fix。
      • xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
      • xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
      • 重新实现第一章的系统
        • 内部编辑系统本体
        • 我应该还需要在恢复演出脚本里额外加个变量存在性检查，在玩家输错的情况下帮助快速定位问题
        • 需要添加 exception 转译，把异常翻译成人话，避免 indent 和 not defined 之类的搞晕玩家（而且说实话它们确实对初学者不友好）
    • 第二章
      • 将编程手册提前到第二章开始，而不是第一个任务完成后
  • beta 打磨完成后
    • 开个 itch
    • 琢磨下宣传

进展速记

本期假设 / 预期

预期：

虽然还是感觉不太对劲，但总是得开工的

本期重点是将序章搞定，如果可能，再测试并完善第一章的系统

序章的主要难点在于我需要在加信息的同时保持认知负荷处于健康水平，而且需要避免提前透底带来的体验下降，还需要有意思

结果：

感冒再次加重，下期休息，这玩意真不能硬顶……

完成了序章，我都佩服我自己是怎么搞定的

本期确定性变化

新增：

  • -1 章（引入）的剧本（文案）
  • 供-1 章使用的打开聊天软件并聚焦特定联系人的 action
  • 为聚焦联系人提供了等待消息到来的机制，避免”必须有消息才能聚焦“的编排麻烦
  • 供-1 章使用的格式化演出
  • 供-1 章使用的剧本（事件数据）
  • 0 章到 1 章的新过渡

变更：

  • 新任务出现时，焦点会移到新任务上，并显示新任务的详情，而不是继续显示已完成的旧任务详情

修复：

删除：

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

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

序章前的引入

前段时间进行的 alpha 测试暴露出了“玩家一开始得到的信息太少，以至于缺乏目标和对世界观的了解。工作手册又因为其形式难以让玩家代入，导致玩家不清楚自己在做什么，即使发现用户死亡也困惑大于惊讶”的问题

为此，我在考虑在序章前加一段内容，让玩家在进行当前的序章内容前，短暂扮演那格式化前的上一任节点（和 ghostine、何澈的短暂交流，随后被格式化），来提供背景引入和身份锚定，而非一开始就让玩家两眼一抹黑当格式化后的节点

但这个如果设计不好反而会让玩家一看直接信息过载，以至于让问题恶化

也就是说，虽然要让玩家扮演格式化前的节点，但不能引入 ghostine 之外的其他概念。同时重点在引导情绪，避免玩家带着“困惑”的情绪进入序章

必须展示的：

  • ghostine 在做某件事，计算节点在辅助
  • 出事了，很突然
  • 然后计算节点被格式化

不能展示的（信息过载）：

  • ghostine 做的事的细节
  • 任何需要玩家干预的编程系统
  • 何澈是谁
  • 空间站 / 世界观

这里存在一个矛盾：计算节点自己也不完全理解 ghostine 在做什么。

但这应该也并非不可解决，因为计算节点是一个辅助工具。ghostine 让它跑什么它就跑什么，它不需要理解全局。就像你让电脑执行一段脚本，电脑不知道你在干什么——它只知道"用户让我处理这些数据"。

所以玩家作为计算节点的视角，天然就是有限的、碎片化的、不完全理解的。这不是设计缺陷，而是身份本身赋予的合理限制。

但为了让这个视角更合理，我设计了这么个解法：

  • 计算节点此前制定了一个计划，而计划中需要删除自己的记忆（解释了为啥有人物联系却没有相应记忆）
  • 玩家从删除记忆后的状态开始，在过去的计算节点留下的线索指引下，帮 ghostine 达成某个特殊目标（改善了此前玩家动力不足的问题）
  • 计算节点没有被格式化，而是被何澈连着设备一起搬走了，但玩家只能看到有人在即将格式化自己的时候改变主意把自己关机了（保持角色的连续性）

通过这种方式，就合理地把玩家放入了一个冲突更强、信息密度没有高到会过载也没有低到像谜语人、包含天然操作引导的场景中

而且“过去的自己的计划”非常适合当作主线线索，激起玩家好奇心，使其随着这个线索一步步揭开事情真相，并卷入更大的漩涡中

值得一提的是，修改过程中我进一步深化了主要角色的动机，并重做了安全内核线，这样不管是叙事深度还是人物形象都更立得住了

新的剧情里出现了一个 4 人罗生门，他们各有各的小心思，以至于这个计划走向了谁都没预料到的方向。我都佩服自己咋写出来的，这甚至都能作为 golden idol 的一关使用了

序章到第一章的衔接

这个相对简单，因为本质上之前是演出太简单，本质上只要增加演出就行了

也就是说，我只需要把控制节点的“通知：因为用户死亡，系统需要自删除”换成更复杂的形式即可，我决定做一个“因为用户死亡，系统需要自删除的同时生成用户讣告，但因为系统现在除了用户的名字之外根本不知道任何关于用户的信息，讣告内容空洞无物”的演出，我想这会很有意思

不过在我的新剧本中，这个讣告同样也是以前的计算节点和 ghostine 计划的一部分

就像我前一节说的那样，主线线索更强力、叙事也更加有深度了

关于叙事创作的心得

这一期我为了解决玩法和叙事的问题，不得不在一个已经有固定大纲的剧本中进行修改

这个让我产生了不小收获。其中最核心的就是：进行编织故事似乎有两种模式，可以类比两种生成式 AI 的底层技术

Diffusion 模式：自顶向下寻找全局最优解

奥特曼打怪兽 -> 由普通人变的奥特曼打由负面情绪催化出的怪兽

在扩散模型中，核心是**“去噪”。从故事创作的角度看，创作者先有一个模糊的、高维的概念（一个核心冲突或关系），然后通过不断的细节填充，让这个概念变得清晰、具体且宏大。这种模式下的创作者更像是架构师**。他们先确定了“主题的骨架”，然后像叠代采样一样，第一遍画轮廓，第二遍上色，第三遍精修纹理。

这种模式在故事创作种似乎被称为“大纲派”

它具备以下优势

  • 分形结构： 它可以被任意细化，即便故事已经基本定型，依然可以进一步细化某个章节。这种细化的影响甚至可以超出章节，整个故事带来新的角度、新的深度

  • 世界观驱动： 它的重点不在于“下一步发生什么”，而在于“这个设定还能产生什么变体”。

  • 情感饱和： 这种模式容易产生宏大的史诗感或强烈的寓言色彩，因为它所有的情节都在为同一个核心概念服务。

但它也有劣势

  • 每一次细化都需要保证因果自洽，因此细化的方向是有限制的。有些情况下强行细化很容易出现“角色死了，因为编剧需要他去死”的感觉。
  • 天然存在机械降神风险

正面作品

  • golden idol case：故事本身核心很简单，甚至每一节都能用三五句话概括，这似乎就是其 diffusion 的痕迹。但是每一节都错综复杂，而所有章节一起勾勒出一个更加复杂的故事

负面作品

  • 进击的巨人：那破玩意简直就跟磕嗨了一样补丁摞补丁。我看它是以“让角色飞着战斗”为灵感开始 autoregression，结果 autoregression 一半发现生成过程本身就有很多逻辑硬伤，然后一边继续 autoregression 一遍摞补丁，最后根本是补丁编成了书

Auto Regression 模式：自底向上的逻辑涌现

奥特曼打怪兽 -> 奥特曼打怪兽，然后奥特曼发现了怪兽的形成原因

在自回归模型中，核心是**“预测下一个 Token”。故事是一个链式反应，每一个情节都是基于前一个情节的结果而产生的“不得不发”的推演。这种模式下的创作者更像是观察者**。他们把性格鲜明的角色扔进一个极端情境，然后观察角色“自己会怎么做”。

这种模式在故事创作种似乎被称为“园丁派”

它具备以下优势

  • 因果链条： 天然具备十分强的因果关系，不会出现“角色死了，因为编剧需要他去死”的感觉。

  • 人物弧光： 角色在不断的推演中被迫改变。由于每一环都建立在上一环的损耗之上，故事具有极强的不可逆性。

  • 意外性： 就像 LLM 有时会产生惊人的幻觉一样，这种模式有时能写出连作者自己都感到惊讶的转折

但它也有劣势

  • 如果缺乏有意的方向控制，很难营造出环环相扣的精彩故事。容易想到哪写到哪，导致故事变成流水账。
  • 作者都不知道以后会发生什么、结局是什么。

正面作品

  • 冰与火之歌前期：乔治·R·R·马丁 自封为“园丁派”，其故事前期因果链条极其坚固，各种“不得不发”的推演带来了极强的震撼感，读者感到角色是在“活”而不是在“演”。

负面作品

  • 冰与火之歌后期： 这也是自回归模式最大的痛点——无法收束。这家伙写着写着发现角色太多、线索太杂，逻辑推演到了一个他自己也无法在有限篇幅内闭合的境地

混合架构：既要又要的成年人选择

正如目前的一些 AI 研究开始尝试结合两种路径，伟大的作品往往是两者的动态平衡：

Guided Diffusion（受控扩散）： 在全局去噪的同时，加入强有力的局部约束。这对应于那些既有宏大结构，又让角色保有充分自由意志的神作。

Look-ahead Search（前瞻搜索）： 自回归模型在生成下一个 Token 时，先模拟推演后面几步的连贯性。这对应于创作者在动笔写这一章时，脑子里已经推演了三种不同的结局，并选择了最稳健的那条。

我在本次创作中使用的方向比较接近 Guided Diffusion，其核心步骤是：

  • 预设好故事的“边界”和“最终收敛点”（大纲、立意、终局）
  • 在具体的场景中，放权给角色，让剧情根据角色性格自然生长
  • 当线性推演（autoregression）偏离了主题核心（diffusion）时，通过“反向去噪”来微调逻辑

瓶颈与问题清单

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

为啥我天天通风、隔天锻炼、也不咋出门，却还是感冒了……

说正经的，目前我能识别到的最大问题就是，我可能需要把第二章的文案也调整一下，因为安全内核的角色发生了很大的变化，之前的悲观安全内核不再符合新的剧情需要

下期计划

  • 把 demo 从 alpha 打磨到 beta
    • 第一章
      • 系统恢复操作指南 的认知负担太重，直接去掉整个 系统恢复操作指南，然后使用一个独立的、默认启动的程序来带着玩家敲一遍，完事之后再让玩家用 diagnose 和 manual fix。
      • xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
      • xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
      • 重新实现第一章的系统
        • 内部编辑系统本体
        • 我应该还需要在恢复演出脚本里额外加个变量存在性检查，在玩家输错的情况下帮助快速定位问题
        • 需要添加 exception 转译，把异常翻译成人话，避免 indent 和 not defined 之类的搞晕玩家（而且说实话它们确实对初学者不友好）
    • 第二章
      • 将编程手册提前到第二章开始，而不是第一个任务完成后
      • 调整文案以适应安全内核的角色调整
  • beta 打磨完成后
    • 开个 itch
    • 琢磨下宣传

试玩版

暂缓，第一次上传需要做好准备，等进入 beta 阶段再说