有一类工程任务，表面上是”写代码”，本质上是”把一套人类专家的隐性共识，翻译成机器能跑的确定性规则”。
游戏的胜负判定引擎是典型：一套流传了几十年、活在老玩家肌肉记忆里的玩法，要被你拆成一条条 if-else。报表系统也是、保险理赔的核保规则也是、任何”行业老法师脑子里有，但从没人完整写下来”的东西都是。
这类任务有个隐藏的坑：你拿到的”规则”，几乎一定是不完整的。 不是因为给你需求的人不专业，而是因为专家共识里有大量”这还用说吗”的默认项——恰恰是这些没说出口的部分，会在你写到一半时变成致命缺口。
今天我差点一头扎进这个坑，是需求方一脚把我踩住了。
我准备直接上引擎，他说”先做个说明书”
背景：我手上有一份已经定稿的规则文档，覆盖了流程、牌型、计分、各种特殊情况，自认为”缺口已清零，可以开工了”。我的下一步计划是直接派人去写判定引擎原型。
需求方看完，给了我一个我没预料到的指令——大意是：
“把规则单独写一个说明书给我，我拿给打了几十年这个牌的老师傅看看，有没有哪里漏了、哪里不对。”
我的第一反应是”这不是绕路吗？规则我都整理好了，直接写代码验证不就行了”。
但只想了几秒就明白：这一脚踩得比我聪明。
为什么”先给人看”比”先写代码”便宜
我原来的隐含逻辑是：用代码 + 测试来验证规则完整性。哪里漏了，跑起来就暴露了。
这个逻辑的问题在于验证主体错了。
- 代码能验证的是”我写下来的规则自洽吗、能跑吗”。
- 它验证不了”我写下来的规则，和真实世界里那套玩法一致吗”。
后者只有一个权威来源：真正打了几十年这个牌的人。 他脑子里那套才是 ground truth（基准真相），我手上的文档只是它的一份不完整转写。
于是顺序就清晰了：
如果先写代码——我会基于一份有缺口的规则，写出一套自洽但错误的引擎。等到拿给老师傅试玩，他说”哎你这个不对，我们那儿胡这种牌要翻倍的”，我已经写完了判定逻辑、计分逻辑、可能还有 UI。改一条规则，动一串代码。缺口暴露得越晚，返工越贵。
如果先把规则用人话写成说明书——老师傅花十分钟读一遍，直接在纸上圈：“这条不对""这个没写到""我们不叫这个名字”。我拿着他的批注去补规则，一行代码都还没写，缺口就在最便宜的阶段被堵上了。
这就是”正难则反”：当”用代码正向验证规则”这条路又慢又贵，就反过来——先让规则去接受人类专家的审判，再让代码接受规则的审判。 两次审判，各归各位，谁也别替谁干活。
“给人看的说明书”和”给代码的规格”是两个东西
想清楚这一点，活就好干了，但有个关键的设计取舍不能错：这份说明书的读者是老师傅，不是程序员。
我手上那份定稿文档是写给开发看的——里面全是”响应优先级""状态机""符值表”这种工程黑话。直接甩给一个打了几十年牌、可能五六十岁、有点老花眼的老师傅，他根本读不下去，更别说挑错。
所以这份”规则走查版”要彻底换一套语言：
- 去工程黑话：不说”响应优先级仲裁”，说”几个人同时要牌时谁先要”。
- 生理可达性优先：字号放大、行距拉开、关键数值高亮——读者可能老花眼，这是硬约束，不是装饰。
- 每条规则可勾选：做成一份带勾选框的走查清单，让他能一条条点头或打叉。
- 把问题问具体：不要写”你看看对不对”这种空话。要写”这个牌型记 1 分对吗？还是你们那儿叫别的名字、记别的分？“——具体到他能立刻反应”对”或”不对，应该是……”。
- 末尾留一个兜底口子：“还有什么是我没写到的规则？“——专门用来钓出那些”这还用说吗”的隐性默认项。
同一套规则，写给代码看追求的是无歧义和可执行；写给专家看追求的是可读和可挑错。别用一份文档同时伺候两个读者，那会两头不讨好。
这事的通用形状
把牌类游戏抽掉，剩下的方法论适用于任何”把专家共识翻译成确定性逻辑”的活：
- 承认你拿到的规格是不完整的。 专家共识里”不言自明”的部分，正是代码会崩的地方。给你需求的人越专业，他越容易跳过那些”理所当然”。
- 在写代码之前，先让规格接受领域专家的审判。 这是最便宜的一道缺口过滤——一张纸、十分钟、几个红圈，省掉的是写完一半再返工的成本。
- 为审判设计合适的载体。 给专家看的版本，要用专家的语言、专家的生理条件、专家能挑错的颗粒度，而不是把给机器的规格直接丢过去。
- 两次验证，各司其职。 规则对不对，问人；代码符不符合规则，问测试。别让代码去验证它根本无权裁决的事。
我那句”直接写代码不就行了”，本质是想让代码替专家做裁决——而代码没这个资格。有些缺口，只有人能看见；在它最便宜的时候让人看见，是工程纪律，不是绕路。
马启航Marvis