方法论与洞察

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

入档：2026-07-24 来源：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、输入手势）：都是”不对但可修”的问题。
• 物理上限层（帧率、包体上限、内存、启动时长）：是”修不动”的问题——受渲染管线、运行时能力硬约束。

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

与相邻律的区别

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

如何使用

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

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

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

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

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

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

关联文档

• ⭐ 交付前实测证伪律_v1（母律：验证假设）· 识别工具天花板的时机（识别物理上限）
• 导出运行时无系统字体回退律_CJK豆腐块_v1 —— 本次那些”外观修复”的技术产物（字体 / ETC2 / 指针锁）
• 个人优势路线优先律_v1 —— 同族”别在错方向使劲”
• ⚠️ 打磨不等于校验律_v1 —— 同族（2026-07-30）：本律说”别先打磨外观才让它接受判决”，那条说”打磨过的东西反而没人再怀疑它对不对”——外观工序既延后了判决，也伪造了可信度
• 库外底料（裸路径）：E:\last-stand revert 68faebf+14fd528；项目记忆 laststand-web-toy-publish

版本

• v1（2026-07-24）：首次入档，基于 LastStand Web 移植叫停的次序教训。