方法论与洞察

可行性生死线前置律 · 移植先探一票否决约束，再修正确性

入档：2026-07-24 · 二次验证：2026-08-08 · 三次验证：2026-08-20 来源：LastStand（Godot 3D FPS）尝试导出 Web 发 Toy 平台 —— 我把字体豆腐块 / 精灵方块 / 鼠标捕获修了好几轮，用户亲自玩了一下、一句”帧率很低”叫停 验证状态：⭐⭐⭐ 三次验证 · 铁律（跨领域：游戏移植 / 创作平台迁移 / 云平台接入） 性质：验证的次序规则，是 交付前实测证伪律_v1 的次序化推论

一句话律

把项目搬到异构运行时 / 新平台时，先验证那个「若不达标就整件事作废」的杀手级约束，再投入修正确性和外观细节。 一个能跑起来的粗糙构建就足以量它（帧率 / 包体 / 启动时间 / 内存）——别先把字体、精灵、输入全打磨完，才让它去接受生死判决。修得再对的细节，也架不住底层根本跑不动。

踩坑现场

LastStand → Toy（B站 web-app）。我的实际次序：

1. 下 1.28GB 导出模板 → 配 Web preset / Compatibility 渲染 / ETC2
2. 首次导出成功，游戏在浏览器里能跑起来
3. 修中文豆腐块（字体回退，两轮）
4. 修鼠标不隐藏（Web 指针锁手势）
5. 修”怪物全是方块”（精灵 alpha 被 ETC2 压坏）
6. ……然后用户亲自玩了一下，“感觉帧率很低，可能就是不太适合做成网页游戏”，任务叫停。

关键错误在次序：第 2 步——游戏第一次能跑的那一刻——就该让用户加载测帧率。因为”3D Forward+ FPS 降到 WebGL2 Compatibility + 单线程后帧率够不够玩”，是能一票否决整个 Web 方案的生死线；而它用一个粗糙构建就能量出来。我却先花三、四轮把外观 bug 修对了，才让它接受生死判决。外观修复全部正确、且沉淀了导出运行时无系统字体回退律_CJK豆腐块_v1这条技术律——但方案本身死于第一个该测却没先测的指标。

为什么次序不能反

移植 / 换平台的失败模式是分层的：

• 细节层（字体缺字形、精灵 alpha、输入手势）：都是”不对但可修”的问题。
• 物理上限层（帧率、包体上限、内存、启动时长）：是”修不动”的问题——受渲染管线、运行时能力硬约束。

物理上限层若不达标，下面所有修正确性的功全部白费。而物理上限往往用一个能跑的粗糙构建就能测出来，成本远低于修一堆细节。所以唯一理性的次序是：先探生死线，再修细节。反过来就是”看起来很勤奋、实际在给一个注定要废的方案抛光”。

第二案例（2026-08-08）：权限型生死线，便宜到不像个任务

《1000人后室大逃亡》S43 长镜头归因，要从 Flova 换到即梦官方 CLI 跑对照。我的实际次序：

1. 装 CLI（先落盘审阅安装脚本，没直接 curl | bash）
2. 查仓库找镜头记录 → 没有 → 查资产表 xlsx → 有镜头但无 prompt
3. 用户给的对照文档编码损坏 → 证明不可逆 → 换路径从桌面读到干净原件
4. 抽 prompt、写三个工具、逐个 --selftest 标定、修四个 bug
5. ……最后才登录：账号 artisan < 高级，dreamina_cli 使用权限 被服务端拒绝。实际生成次数 0。

生死线是账号等级，代价是一条只读命令、30 秒。 全文见 2026-08-08_后室大逃亡S43长镜头_归因未遂与生死线次序复盘_v1。

二次验证补的新维度：成本越低的生死线越容易被漏

首案的生死线是帧率——要先做出能跑的构建才能量，成本可见，所以「先探它」本身像一项任务，值得被提醒。

本案的生死线是账号权限——便宜到可以顺手做。恰恰因为它不像个难题，我根本没把它排进流程，而是当成了「到时候自然会通」的背景条件。

补充判据：生死线的成本和它被遗漏的概率成反比。 技术型生死线（帧率 / 包体 / 内存 / 启动时长）因为要花力气量，反而会被郑重对待； 权限型生死线（账号等级 / API 配额 / 区域限制 / 付费层级 / 白名单）便宜到不像任务，于是被推迟到最后。

换平台清单里必须显式加一行：「这个账号，在这个通道上，被允许做这件事吗？」

两案的次序错误结构完全一致：都把「修正确性 / 备内容」排在「量生死线」之前，都在为一个尚未确认能跑的方案抛光。

与相邻律的区别

• 交付前实测证伪律_v1：管”别交付未验证的假设”，写探针去证伪。本律管的是”手上有一堆待修项时，先修哪个”——把能一票否决的生死线约束排到第一位。是证伪律的次序化推论。
• 识别工具天花板的时机：管”识别到天花板就换工具 / 换角色接管”。本律更进一步：主动前置去探天花板，别等修了一堆细节才撞上它。我这次正是”没早识别 WebGL2 帧率这个天花板，一路在天花板底下修外观”。
• 个人优势路线优先律_v1：同族”别在错的方向使劲”，但那条是选赛道，这条是排验证次序。

如何使用

接到「移植 / 上新平台 / 换运行时」任务时，动手前先问一句：

什么指标不达标，会让整件事直接作废？

先把这个指标用最小可跑构建量出来，再谈细节：

| 本地开发 → 任何外部云平台 | 本机能否完成 CLI 认证 / 部署 | 认证型（第三案补） |

权限型那两行是第二案例补的，且它们最容易被漏——因为一条只读命令就能问出来，便宜到不像一项任务。

达标，再投入修正确性；不达标，早收手（本次从”叫停”到”干净回滚”只花了几分钟，代价可控）。判据优先用真机上手——用户亲自玩一局给出的”卡”，比我再修十个外观 bug 都果断。

第三案（2026-08-20，zombie-world）：生死线是认证链路本身

要给游戏做联机信令，选了 Cloudflare Workers 免费层。前期功课做得很扎实： 能力、配额、定价全查准了（KV 免费层每天只能写 1000 次 = 500 局/天到顶， 于是改用 Durable Object 绕开）。然后先把业务写完了—— Worker + DO 实现、22 条单测、本地端到端两标签页跑通、部署文档齐全。

最后一步部署，wrangler login 死活完不成。查到底： dash.cloudflare.com 对命令行客户端返回 bot 挑战页（Just a moment...）， 而 wrangler 的 OAuth 必须去那里用 code 换 token。换了 3 种方式、试了 4 次， 在这台机器上不可能成功。整套代码没上线。

新维度：这次的生死线既不是性能，也不是权限等级，而是「我这台机器能不能完成认证」。 它比前两类更容易被漏，因为：

• 性能型要花力气量，反而被郑重对待；
• 权限型一条只读命令就能问，便宜到不像任务；
• 认证型看起来”肯定没问题”——注册个账号谁不会？于是连”跑一次最小部署”都省了。

规则补丁：选定任何外部平台后，第一件事是跑通一次 hello-world 级的部署，再写业务代码。 尤其当本机处在代理 / 特殊网络区域时。这次如果先发一个 20 行的 Worker， 半小时就能发现此路不通，而不是在写完全套之后。

本次做对的部分（留作对照）

• “先做验证导出”的直觉是对的——错在把”验证”理解成”让它渲染正确”，而非”量那个生死指标”。
• 叫停后清理干净：用 git revert 而非 reset（保住知识库引用的 commit SHA、原始 web 代码留在历史可重试），重新导入同步纹理缓存，工作区回到纯桌面。见 生成物不入git_v1 同族的收尾纪律。

关联文档

• ⭐ 交付前实测证伪律_v1（母律：验证假设）· 识别工具天花板的时机（识别物理上限）
• 导出运行时无系统字体回退律_CJK豆腐块_v1 —— 本次那些”外观修复”的技术产物（字体 / ETC2 / 指针锁）
• 个人优势路线优先律_v1 —— 同族”别在错方向使劲”
• ⚠️ 打磨不等于校验律_v1 —— 同族（2026-07-30）：本律说”别先打磨外观才让它接受判决”，那条说”打磨过的东西反而没人再怀疑它对不对”——外观工序既延后了判决，也伪造了可信度
• ⭐⭐ 2026-08-08_后室大逃亡S43长镜头_归因未遂与生死线次序复盘_v1 —— 第二案例全文；权限型生死线，实际生成次数 0
• ⭐⭐ 2026-08-20_zombie-world_联机重构与局内货币_全链路复盘_v1 —— 第三案例全文； 同一轮还提炼出 约束型结论先复核律_文档写的不可能会过期_v1
• 库外底料（裸路径）：E:\last-stand revert 68faebf+14fd528；项目记忆 laststand-web-toy-publish。第二案：d:\backrooms-1000 commits 1443380/c667ac1/ba69dae

版本

• v1（2026-07-24）：首次入档，基于 LastStand Web 移植叫停的次序教训。
• v1 · 二次验证补丁（2026-08-08）：S43 归因未遂案入档，验证状态 ⚠️首次 → ⭐⭐二次验证。新增维度「生死线的成本与被遗漏概率成反比」，场景表补权限型两行。
• v1 · 三次验证补丁（2026-08-20）：zombie-world 的 Cloudflare 信令案入档，验证状态 ⭐⭐ → ⭐⭐⭐三次验证·铁律。新增认证型生死线（本机能否完成 CLI 认证），规则补丁「选定平台先跑通最小部署再写业务代码」。