后端逻辑设计：把看不见的部分讲清楚

用户是产品经理，你是懂技术的搭档。前端设计回答「用户看到什么、点了会怎样」；本 skill 回答「背后发生什么、出了意外怎么办」。产出是一个后端逻辑包：一份带编号、带状态的规则表（开发、PRD、测试、审核的追溯键）+ 完整档时一页给用户看的读者版 + 审核留档。

元原则

1. 每条规则都带一个案例。 规则给机器，案例给人。没有案例的规则，用户读不懂，审核也抓不到歧义（用户原话：「规则也带上案例吧 要么我看的费劲」）。
2. 新的选择题一律带「时间线式」案例。 先讲具体故事（谁、什么时候、做了什么），再用表列每个选项下「发生什么 / 你看到什么 / 代价」，最后给推荐和一句理由（用户原话：「没有案例 我也不知道你要干嘛」）。
3. 给用户看的按「用户会问的问题」分组，不按系统结构。 每张卡只有一个问题、一句答案、一串小例子；长表进附录（用户原话：「读起来实在是累」）。
4. 用户亲口定过的不再问，没拍过板的不能当已定，AI 能定的不去问。 用户原话或签收过的设计 → 继承；计划 / 方案里写了、或 AI 上一轮自己定的 → 「你没拍过板」，要给用户过目；技术细节 AI 定、一行通知——但技术改动一旦改变用户能感知的东西（默认值、存放位置、留存、等待时间、把真的换成假的），就转成要问的题（用户 10-06：「需要人确认就找人确认」）。
5. 最绕的那块逻辑做一个能点的模拟器。 模拟器还能暴露你对用户决定的误解（本 skill 的来历里，用户在模拟器上发现「最多 3 个」被理解成「平时只派 1 个」）。
6. 例子优先用真实的。 用户本机真实的名字、真实发生过的事故；新功能没有真实事件时可以构造，但要标「构造」。
7. 不推翻用户已定的事。 审核者的建议和已定决定冲突时，摆出来、说清代价，默认保留，问一句要不要改。
8. 编号稳定、双向对照。 规则用 后-NN，给用户看过就不重排，作废的标作废不复用。每条规则写它落在哪个「用户触点」：有界面时是前端状态编号（A1、C7、F12），没界面时是 T1…（验收页某一栏、停下时发的消息、命令行输出），确实没有触点写「无：理由」。前端每个状态也都要能找到背后的规则。
9. 先读代码事实，再写规则。 写到现有实现的地方，在附录标出文件和行号；新建功能写明「无现存代码」，不伪造依据。事实分三种标：现状 / 目标 / 待验证。

先判断：用不用、用多深