# Backend Logic Design

和用户一起把一个功能「看不见的部分」敲定：数据存哪、谁写谁读、怎么加载、怎么保存、默认值和升级、核心执行规则、出问题时怎么办、旧东西怎么迁。每条规则带编号、案例和状态（已定...

- Repository: https://github.com/yunshu0909/yunshu_skillshub (788 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-11
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add yunshu0909/yunshu_skillshub --skill backend-logic-design -g -a claude-code -y`
Codex: `npx skills add yunshu0909/yunshu_skillshub --skill backend-logic-design -g -a codex -y`
Cursor: `npx skills add yunshu0909/yunshu_skillshub --skill backend-logic-design -g -a cursor -y`
Gemini CLI: `npx skills add yunshu0909/yunshu_skillshub --skill backend-logic-design -g -a gemini-cli -y`

## Description

和用户一起把一个功能「看不见的部分」敲定：数据存哪、谁写谁读、怎么加载、怎么保存、默认值和升级、核心执行规则、出问题时怎么办、旧东西怎么迁。每条规则带编号、案例和状态（已定 / 方案里有但你没拍板 / 待你定 / AI 定），用户只回答带案例的新选择题、过目没拍过板的规则；给用户看的是按「你会问的问题」分组的问答卡片（最绕的逻辑配可点的模拟器）；最后请另一家模型只读查边界，问题闭环后封成后端逻辑包，PRD、测试用例和代码审核按规则编号追溯。触发：前端交互已定、用户说「还有很多后端逻辑 / 加载 / 配置要讲清楚」「有没有遗漏的边界条件」「规则讲清楚」；或没有界面但规则复杂的功能（调度、同步、配置、额度、迁移）。分三档用：规则多且互相影响出完整包；少量清楚的变化只出规则表；行为不变的技术修复跳过。不适用于：页面长什么样、怎么排（用 page-solution-design）；写 PRD / 测试用例（本 skill 的规则包是它们的输入）；纯代码重构、性能调优、架构巡检报告。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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

用户是产品经理，你是懂技术的搭档。前端设计回答「用户看到什么、点了会怎样」；本 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 流程里随开工前检查一起送审。

## 确认分工

The rest: https://github.com/yunshu0909/yunshu_skillshub/blob/HEAD/coding/backend-logic-design/SKILL.md