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

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

元原则

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

先判断：用不用、用多深

档	什么时候	做哪几步	产出
完整包	还有没定的、用户能感知的规则，并且涉及以下任一：跨模块的数据归属、规则互相影响、同步 / 调度、升级迁移、出错降级、多步写文件	第 0, 6 步全做	规则 md + 读者版 HTML（卡片、模拟器）+ 业务题页 + 边界审查留档
只出规则表	规则清楚、只有少量互相独立的变化（如「什么时候改写某个文件」）	第 0、1 步；有新选择题、或有要过目的规则（proposed、新增的用户可感知规则）就做第 2 步；边界审查并进开发流程的开工前检查	规则 md（build.py 不放 cards.json 即可）
跳过	用户能感知的行为不变的技术修复（拆代码、提速但结果不变）	,	无；高风险技术问题照常走开发流程的审核

判断看「有没有待定的业务规则、规则之间会不会互相影响、出错后果」，不看代码量，而且只看本次改动新增或改变的部分, , 功能里早就有的迁移、降级分支不算。拿不准时先按「只出规则表」做，写的过程中发现规则互相牵扯再升档并告诉用户。项目约定「设计相关要先问用户走哪条流程」的，照项目约定。

• 业务都定了、但有高风险的多步写 / 崩溃恢复：按「只出规则表」，但步骤表和边界审查必做，需要时可以加一个模拟器给自己和审核者用。
• 只出规则表时，题和审查放哪：新选择题, , 单独用写一份 业务题.md；dev 简版里并进 1-plan.md 的「规则」一节（测试清单直接引用 后-NN，不把同一件事写两遍）；dev 正式版里并进业务确认。边界审查, , 单独用自己请另一家；dev 流程里随开工前检查一起送审。

确认分工