方法论与洞察

约束型结论先复核律 · 文档写的「不可能」会过期 · v1

入档:2026-08-20 来源:zombie-world 联机重构 —— README 与项目记忆里长期写着「租一台公网服务器不成立」, 于是两个月的联机设计全在「怎么不用服务器」的约束下打转;SSH 上去发现服务器早就部署好、 已经连续跑了 23 天 验证状态:⭐⭐ 二次验证(同一轮里独立出现两次,见下)


一句话律

当一条写在自己文档里的结论正在否决一整类方案时,先花几分钟复核它,再接受它。 文档里的”约束”用久了会被当成物理定律,但它可能只是某一天的观察,甚至当时就写错了。 判据是代价不对称:复核成本越低、被它否决的方案空间越大,越必须先复核。


实证一:「没有公网服务器」——一句话裁掉两个月

zombie-world 的 README 和项目记忆里都写着:

玩家几乎全在手机上,「租一台公网服务器」和「拿 PC 当主机」两条路都不成立

这句话本身有理有据(有理由、有场景分析),于是所有联机设计都在它划出的圈里打转: 人肉互发 WebRTC 的 SDP、研究能不能压进二维码、给 Cloudflare 免费层写信令服务…… 连”WSS 版”那套完整实现(2~4 人、房间码、断线重连、测试全绿)都是因为它被冻结的。

真相:服务器早在两个月前就部署好了zombie-world.service 已经连续跑了 23 天。 当初只配了 listen 80 + server_name <纯IP>,而 https 页面连不了 ws://(混合内容), 所以它是个连不上的空壳。缺的从来不是服务器,是域名和证书。

一条 ssh + ss -tlnp 就能查清的事实,被一句写在文档里的结论挡了两个月。

实证二:同一轮里,我复述了一个已被推翻的猜想

同一个项目、同一轮工作中,我把「iOS 访问局域网需要 App 持有 NSLocalNetworkUsageDescription, 而这个权限属于宿主 App、不属于我们的页面」当成未解风险讲了一遍,还据此写进了代码注释。

而项目记忆里明明白白写着:2026-08-12 的真机测试已经排除了这个猜想,权限是正常的; 真正卡住的是网卡/路由层(浏览器只沿默认路由那张网卡采集 ICE 候选)。

两次的共同形态:一句写下来就不再被质疑的结论,持续地替我做决定。


为什么这个坑比”检出旧”更隐蔽

开工前先对基线律_v1 对比着看最清楚:

开工前先对基线律本律
失效的是工具 / 检出(看不见存在的东西)我自己写下的结论
现象穷尽搜索 + 零命中压根不去搜——因为”已经知道答案了”
补救git fetch、扩大搜索范围复核那句结论本身

本律更难自救的原因:前者至少你还在找,找不到会起疑;本律是连找的动作都被省掉了。 而且它还有三重加固:

  1. 是自己写的——比别人的转述更容易信(这一点与 交接文档不是需求原文_接手先回溯上游_v1 互补: 那条讲”别人的转述读起来像原文”,本条讲”自己的结论读起来像事实”)
  2. 带着理由——“因为玩家都在手机上”这种论证会让结论显得比它实际更硬
  3. 被反复引用而强化——每次设计绕开它一次,它就更像定律一次

操作规则

  1. 识别「约束型结论」:文档里凡是形如「X 不成立 / 做不到 / 不可能 / 只能……」 的句子,都是约束型结论。它们和事实型结论(“接口返回 200”)不一样—— 约束型结论在替你裁剪方案空间
  2. 算代价不对称:复核它要多久?它否决了多大范围? 5 分钟 vs 一个方向 这种比例,必须先复核。
  3. 写下来的时候就带上保质期:结论后面注明日期 + 怎么验证的。 ✅「2026-06 查过:Toy 只托管静态包,不跑 Node」 ❌「Toy 不能跑服务端」
  4. 专门维护一栏「已排除的猜想」:项目记忆里最值钱的不是”已知的事”, 是”已经排除掉的、听起来很合理的猜想”——因为它们会被反复重新提出(包括被你自己)。 写清楚怎么排除的,会话开始就读。

反例 / 边界


关联文档

类型/协作工具链主题/协作主题/决策