今天一行代码都没写。整天都埋头在产品需求文档和技术需求文档里，到头来发现这不知怎么成了迄今为止最累人的一天。
游戏的核心玩法很简单：在网格上通过点击连接相同颜色的点。一句话就能说清。但当我试图把这句话拆解成真正可开发的规格说明时，几乎立刻就碰壁了。第一个把我难住的问题是，“点击一个点”到底是什么意思。它仅指彩色的端点，还是说你可以点击同一行或同一列中的任意单元格来延伸路径？在这一点明确之前，你甚至无法判断路径是否允许转弯。没能早点意识到这么基础的问题，让我觉得自己很蠢，但直到你试着把它写下来，你才会真正注意到这些问题。
这成了这一天大部分时间的常态——修复了一条规则，旁边的另一条规则就出问题了。“修剪”（撤销你自己路径的一部分）与“自相交”之间的冲突尤其令人头疼。如果你自己的路径恰好位于直线点击延伸的中间某处，这算是“修剪”还是仅仅被阻挡了？最终的结论是：只有当被点击的单元格恰好是你路径上已存在的点时，才算是“修剪”，否则整个点击操作无效，没有例外。走到这一步花的时间比预期的要长。
不过，我遇到的最大问题是“唯一解”的要求。起初我理所当然地认为求解器必须保证唯一解——这感觉显而易见。但深入探究后，我意识到一个拥有大量空白单元格的简单难度棋盘，无论如何结构上都会存在多个解。因此，强制要求唯一解意味着你根本无法生成简单关卡。看到这一点时真是让人备受打击，老实说，我甚至找不到当初假设唯一解很重要的真正理由——那只是感觉上是“正确”的做法。我彻底废弃了这一要求，并围绕求解器在其找到的所有解中选取“最简单解”这一逻辑，重写了第13、14和15项功能，并以此作为难度判定的基础。
无尽模式在同一开发时段内诞生又被否决。最初的设计是让生成的关卡无限延续，但回过头来看，如果实时生成失败或出现延迟，玩家体验会发生什么变化，并没有任何定义。因此，我删除了该设计，改为在部署前预先生成一个包含50个关卡的固定池（6个手工设计 + 44个自动生成），并在最后一个关卡显示“更多内容即将推出”的提示。每日谜题的扩展构想也在同一轮修改中被弃用——我认为其作品集价值太低，取而代之的是一个自动生成流水线（生成 → 人工智能初审 → 开发者复审 → 部署），这感觉更能展示如何利用人工智能实现工作流的自动化。
后来，我添加了一个扩展功能——一个实时的生成器/求解器演示屏幕——但这直接撞上了早期技术需求文档中的一个决定，即生成器模块仅适用于 Node.js 环境。演示屏幕需要在浏览器中实时运行生成器，因此这两者无法兼容。最终，我将生成器和求解器都重新设计为与环境无关的纯 TypeScript 代码，以便它们既能在 Node.js 流水线中复用，也能在浏览器演示中使用。老实说，我当初想要这个演示屏幕的根本原因是一个一直困扰我的问题——一个围绕 NP 难问题构建的作品集项目，难道不应该在某处展示算法的实际运行过程，而不是将其完全隐藏在离线流水线背后吗？
看看目前的文档状况，产品需求文档已经重写了五次，技术需求文档部分也在同一天被彻底推翻并重做了两次。剩余的待确定事项列表仍然很长——颜色配对/网格尺寸的进度曲线、真实的求解器超时数值、难度阈值校准、障碍功能如何实际...
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
