TL;DR 概览

本周完成了预定的 Terminal 修复和 轻聊 的最小实现。轻聊仍需打磨，目前打磨进度来到了第一章的一半

本期目标

• 修好 Terminal
• 实现 轻聊

进展速记（Changelog）

本期假设 / 预期

我当时以为世界是怎样的？ 这个预期中，哪一条被证伪 / 被削弱 / 被确认？

我之前认为，我通过先前的 准备完善的剧情文案 - 要求AI按指定架构生成框架 - 调整细节 - 要求AI按文稿填充 的工作流可以在我完成轻聊的文案和核心特性（玩家编写自定义脚本完成文本处理）之后几乎一步到位完成设计

但实际上出现了不少问题，导致重做了好几次

• claude将轻聊作为茶馆的一部分实现了，而不是作为单独的应用实现
  • 因为 轻聊 和 茶馆 的语义类似
  • 先前实现的内容中有玩家编写程序来增强玄云观的论坛的先例
• claude分别提供了两个版本的文案，分别是自定义脚本处理前和处理后预期的
  • 它没有理解这个项目的核心就是让玩家在做中学，使用了常见的类owell游戏里那种“完成任务后自然变化”的结构

本期确定性变化

哪些东西现在「更确定」或「被明确否定」了？ “确认 X 不可行” “删掉 Y 抽象” “意识到 Z 是伪问题”

新增：

• 轻聊的主体框架

变更：

• 打磨了第一章第三节的文案表现

修复：

• 恢复阶段的定制 Terminal 无法在恢复阶段加载的 BUG

删除：

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

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

工作流优化

前一个半周报中提及，我在第二章改为使用如下工作流，且因为 Claude 太喜欢蓝紫色移动设备网页细化了几次要求重做了几次

• 准备完善的剧情文案
• 要求AI按指定架构生成框架
• 调整细节
• 要求AI按文稿填充

而这周我继续使用这套工作流，并将其作为“本期假设 / 预期”的一部分正式试验，然后遇到的问题为了方便我也复制到了下面

• claude将轻聊作为茶馆的一部分实现了，而不是作为单独的应用实现
  • 因为 轻聊 和 茶馆 的语义类似
  • 先前实现的内容中有玩家编写程序来增强玄云观的论坛的先例
• claude分别提供了两个版本的文案，分别是自定义脚本处理前和处理后预期的
  • 它没有理解这个项目的核心就是让玩家在做中学，使用了常见的类owell游戏里那种“完成任务后自然变化”的结构

显然，它看起来是“Prompt限制不足/信息不足”的结果。

但这应该只是表观原因，如果局限在这一层那么似乎就只能尝试在细节和效率上取平衡点，祈祷 claude 这次能正常理解。

而我不是很能接受这个结论，所以我就必须问：更本质的原因是什么？

• claude没有正确理解prompt，但为什么？
  • 这是因为Prompt限制不足/信息不足，但具体缺了什么？
    • 我没有意识到claude默认会将轻聊和茶馆关联起来，但为什么它不会将其和玄云观关联起来？
      • 可能和最近一直在开发茶馆和玄云观网页，导致 claude 的注意力歪了
      • 我的第一次重试时，它仍把一些内容和茶馆关联了。而茶馆和玄云观相比和轻聊最接近的部分就是它的名字。
    • 我没有明确要求它使用统一的底层数据让玩家的脚本真实地处理数据，但为什么我同样没显式提供的存档数据机制它正常使用了？
      • 存档数据机制和非真实编程都是常规项目中的常见机制，而让玩家脚本被真实运行并不是

我没有更深的问题可以提出了，所以我能力范围内的问题根因也可以认为是清楚了。那么解决方案也很明显

• claude 的注意力被之前的任务带歪了
  • 实现不同架构的东西时开新上下文
• 茶馆和轻聊在程序功能上比较接近
  • 这个我反思了是不是我设计有重复，但反思后确认这两个在剧情、叙事、功能上都是有根本性差异的
  • 这个没法杜绝，但我可以让 claude 先给份设计计划，然后再让它动工，以此来避免迭代 10 分钟后才发现它跑歪
• 真实编程和叙事结合的机制并不是很常见
  • 识别项目的特殊性，在写计划时明确指出这些特殊性来让实现更加符合项目调性

剧情打磨

在打磨剧情中，我发现在第一章系统修复过程中引入的ProxyOS 最小安全内核是个很有潜力的角色，所以我决定把它纳入之后的剧情中

这样也可以用和它相关的内容填补第二章中发现用户死亡的深水前的内容空缺

瓶颈与问题清单

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

下期计划（Next）

• 完成第一章打磨
• 完成第一章测试

试玩版

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

• ProxyOS
• 周报
• 独立游戏开发
• 技术日志