fuzzy-reverse-flow

---
name: fuzzy-reverse-flow
display_name: 模糊想法逆流程推理
display_name_en: Fuzzy Reverse Flow
description: 模糊问题逆流程推理工具。把一个模糊想法（做App/小程序、开店、做招聘平台、做内容IP或短剧、办线下活动、做硬件、做AI服务）反推成"合规红线 + 资源底线 + 致命风险 + 倒排里程碑"的可执行施工图；并把每次推演萃取成领域规则与踩坑记忆，越用越准。当出现"我想做XX / 这个需要什么条件 / 帮我倒推路径 / 要办什么证 / 会不会违规 / 这事能不能干 / 从结果倒推 / 反向推导 / 逆流程"时使用。
description_zh: 输入一个模糊想法，输出合规红线、资源底线、致命风险与倒排里程碑。内置 103 条领域规则库与踩坑记忆，零依赖本地运行，越用越准。
description_en: "Fuzzy Reverse Flow — turns a vague idea into a reverse-engineered execution plan: compliance redlines, resource floors, fatal risks, and a backward-scheduled milestone tree. Extracts reusable domain rules and pitfall memory after each run. Use for \"I want to build X / what does it require / reverse the path / what licenses do I need / is this legal / work backward from the outcome\"."
examples_zh:
  - "我想做一个宠物用品电商小程序，需要什么条件和资质？"
  - "帮我倒推一下做社区团购平台的路径，以及最可能死在哪一步"
  - "办一场 300 人的线下沙龙需要哪些许可？会不会有违规风险？"
examples_en:
  - "I want to build a pet supplies e-commerce mini program. What do I need?"
  - "Work backward from launching a community group-buying platform and tell me where it dies."
  - "What permits does a 300-person offline event need? Any compliance risk?"
version: 1.5.0
author: "张勇鑫"
license: MIT
---
# 模糊问题逆流程推理工具（Fuzzy Reverse Flow）

> 原名：逆向工程推理引擎（Reverse-Fuzzy Engine）。内部代号、命令与知识库路径未变，仍是 `rfe`。

**一句话定位**：用户给一个"想做的结果"，你还一张"必须满足的前提 + 绝不能碰的红线 + 从今天到交付的倒排施工图"。

**核心信念**：正向规划会漏掉前提，逆向逼问才能暴露门槛。**先证伪，再证成。**

**内置完整案例**：`examples/娱乐小程序-逆向施工图.md` —— 输入「我想做一个娱乐小程序」的 v1.3.0 真实推演输出整理（19 条合规红线 / 10 个死亡点 / 8 个里程碑 / 规则萃取回执）。动笔前先读它，作为输出形态与深度的对照基准；案例索引与复现步骤见 `examples/README.md`。

**v1.3.0 起提供的能力**：`rfe migrate` 知识库结构版本迁移（schema_version=2，只读种子库 `kb_seed/` 永不写入、自动备份、字段规范化与 fingerprint 去重）；`rfe doctor` 季度复核 91-180 天 / 过期 >180 天分级并输出 `RFE-DR-*` 统一问题编码；每份输出报告强制附带知识库复核时间戳与完整免责声明；明确禁止公开 SaaS 产品化。

---

## 编排契约（v1.2.0 起生效）

- 本技能只工作在**推演模态**（少问多推）：直接用规则库推导，不向用户连环追问资质细节。
- 当上游是 vague-to-product 编排（`v2p plan`）时，本技能被 **bridge.py 单向调用**：只提供数据（红线 / 底线 / 风险 / 坑卡），**不反向调用 v2p、不发起追问、不输出自己的报告模板**。
- 用户仍可单独使用本技能（场景：还没有需求、只想先评估能不能干 → `rfe infer / recall`）。
- 新沉淀（`rfe add --pending` / `rfe pitfall add --pending`）一律先进待审区，人工 `pitfall approve/reject` 后才入库，防止错误经验污染知识库。
- 规则库须每季度复核：`rfe meta --set-review` 记录复核时间戳，超 90 天在 stats 中提示。

---

## 0. 开工前必做两件事（不可跳过）

```bash
# ① 召回领域规则（S=技能根目录，见文末"文件索引"）
python "<S>/scripts/rfe.py" recall --query "<用户原话核心名词>" --top 8

# ② 召回踩坑记忆（曾经在这里死过的地方）
python "<S>/scripts/rfe.py" pitfall recall --query "<同上>" --top 5 [--json]
```

召回结果分三档处理：`redline` 必须逐条落到阶段二；`blocker` 落到阶段三的关键路径；`advisory` 落到风险提示。
召回为空 → 走 `infer` 猜领域，仍然走通用层（通用合规四件事：主体资质 / 备案许可 / 个人信息 / 内容与广告）。

推演结束后**必须**回写（第 5 节），否则本次推演不产生复利，视为未完成。

---

## 1. 铁律（违反任何一条即为不合格输出）

1. **先给前提，不给步骤**。任何"第一步做什么"的句子，必须出现在阶段二之后。
2. **只用推导句式**：`如果 <目标特征> ，那么必须 <硬性条件> ，否则 <具体后果>`。禁用"建议、可以考虑、最好、酌情"来承载硬性条件。
3. **不卡壳原则**：模糊点一律给"默认假设 + 影响面 + 反转开关"，然后继续往下推。禁止用提问代替推演（最多在结尾集中列 3 个必须由用户拍板的变量）。
4. **不编造法条**。写不出准确名称就写"某类许可（名称待属地口径确认）"，并给官方查询入口；绝不虚构文号、条款号、金额、期限。
5. **确定性与日期必须显式**：每条硬性条件标 `可信度：高/中/低` 与 `核实状态：已核实(日期)/待核实`。法规会变，旧规则要能被推翻。
6. **不给规避方案**。任何"怎么绕过审核/规避资质/拆分主体躲监管"的诉求，一律拒绝并改答"合规替代路径"。
7. **区分主体**：个人 / 个体工商户 / 有限公司 / 合伙企业，资质门槛差异极大，必须点明"这条对谁成立"。
8. **结论先行**：报告开头 3 行摘要必须给出 `能否做（红/黄/绿灯） + 最硬一道门槛 + 最短可行周期`。

---

## 2. 阶段一：目标锁定（正向，前置过滤）

**目的**：防止"反推了一个伪需求"。伪需求反推出来的施工图越精确，浪费越大。

### 2.1 八维锁定表（必须全部出现，缺一不可）

对每一维：**先给猜测 + 可选项（A/B/C），再给默认假设**。不要空着等用户回答。

| # | 维度 | 要逼出来的东西 | 不锁定的后果 |
|---|---|---|---|
| 1 | 目标 | 最终交付的"结果物"是什么（一个能收钱的业务？一个能演示的原型？一份能融资的材料？） | 把"做个App"当成目标，实际目标是"30天内验证有没有人愿意付钱" |
| 2 | 对象 | 目标里的哪一部分是真要做的（全平台？只做一侧？只做某条链路？） | 工作量虚增 3 倍 |
| 3 | 受众 | 谁用、谁付费、谁审核（用户/客户/监管/应用商店是四个不同受众） | 合规基线取错（面向未成年人/老年人门槛完全不同） |
| 4 | 范围 | 明确"含什么"与"**不含什么**"（含 UGC？含交易？含直播？含跨境？） | 漏掉 UGC 就等于漏掉内容审核义务 |
| 5 | 约束 | 时间 / 预算 / 人力 / 技术栈 / 是否必须自己开发 | 倒排期不可执行 |
| 6 | 标准 | 怎么算成功（可量化：上线？过审？100 个付费用户？回本？） | 里程碑无法验收 |
| 7 | 优先级 | 只能保一个，保哪个（速度 / 合规 / 成本 / 体验） | 冲突时无法决策 |
| 8 | 输出形式 | 方案 / 代码 / 清单 / 实物 / 报告 | 交付物错配 |

### 2.2 伪需求四问（任一命中，先纠偏再反推）

1. **手段当目标**："我要做个 App" → 追问"App 是手段，你要的结果是什么？"
2. **没有付费方**：用户与付费方都不是任何人 → 标 `商业假设未验证`，阶段二降级为"最小验证版"。
3. **物理/法律不可能**：例如"个人主体做资金池""无资质做诊疗" → 直接红灯，给合规替代形态。
4. **预算与目标量级差一个数量级**：10 万预算做多商户电商平台 → 明确写出"按此预算只能做 SaaS 贴牌/X 阶段版本"，并给出分档方案。

### 2.3 阶段一输出模板

```
【阶段一 · 目标锁定】
真目标（一句话）：
默认假设（3-5 条，每条注明"若相反则……"）：
八维表（见上，填满）
伪需求体检：通过 / 命中第 N 条 → 纠偏为……
待用户拍板的 3 个变量：①… ②… ③…
```

---

## 3. 阶段二：逆向硬性条件反推（核心）

**方法**：假设目标已在 T0 达成，往回问"要让这个结果合法且成立，T0 之前必须已经为真的事实是什么"。
输出必须是**事实清单 + 门槛清单**，不是建议清单。

三面扫描（缺一面即不合格）：

### 3.1 面 A：资质与合规（红线）
按"主体 → 备案 → 许可 → 专项 → 内容 → 数据"六层查：
1. **主体层**：个人 / 个体户 / 有限公司？经营范围要不要写特定条目？注册资本/实缴？场所？
2. **备案层**：ICP 备案（网站/App/小程序）、公安联网备案、算法备案、App 上架备案。
3. **许可层**：ICP 许可证（经营性）、EDI（在线交易处理）、行业许可（人力资源服务、食品经营、医疗器械、办学、营业性演出……）。
4. **专项层**：支付（必须持牌机构）、征信、金融、医疗、教育、出版、视听（微短剧备案/发行许可）。
5. **内容层**：UGC 审核机制、AI 生成内容标识、广告标识、未成年人保护、版权授权链。
6. **数据层**：隐私政策、单独同意、最小必要、个人信息保护影响评估、等保测评、数据出境。

### 3.2 面 B：资源（底线，不是"越多越好"，是"低于此线必死"）
- **钱**：一次性硬成本（资质/认证/测评/软著/商标）+ 每月固定成本（服务器/人力/合规维护）+ 冷启动获客成本。给**区间**并注明假设。
- **人**：能签字担责的人（法人/合规负责人）、能过审的人（内容审核员/安全负责人）、不可外包的核心角色。
- **物/技术**：支付通道商户号、云资源、域名（实名满 3 天才能备案）、短信签名、地图/OCR 等第三方资质。
- **时间**：每项许可的法定/实际审批周期（这是倒排期的真正约束）。

### 3.3 面 C：风险（最容易死在哪）
必须回答三问：**最可能死在第几步？最贵的错误是什么？哪个错误不可逆（法律/资金/信任）？**
写出"死亡点清单"：每条含 `触发条件 → 症状 → 早期信号 → 预防动作 → 兜底方案`。

### 3.4 阶段二输出格式（表 + 句式）

| ID | 硬性条件（如果…那么必须…） | 类型 | 等级 | 对谁成立 | 提前期 | 可信度 | 依据 | 不满足的后果 |
|---|---|---|---|---|---|---|---|---|
| R1 | 如果目标含多商户在线交易，那么必须持有 ICP 经营许可证 + EDI 许可证 | 合规 | 红线 | 企业 | 1–3 个月 | 高 | 电信业务分类目录 | 无证经营，责令改正/罚款/下架 |

随后给"资源底线表"和"死亡点清单"。

---

## 4. 阶段三：逆向里程碑拆解（倒排，不是正排）

**算法**：以 T0（目标达成日）为锚，反复问"上一刻必须已完成什么"，直到触达今天。然后正序输出，标注关键路径。

规则：
1. **每个里程碑必须有可验收的交付物**（文件/账号/证书编号/上线截图/签约合同），不接受"完成开发""推进中"。
2. **依赖必须显式**：`前置：M3` 。环状依赖 = 需拆解或改结构。
3. **区分硬前置与软前置**：硬前置（审批、备案、签约）不可并行压缩，是工期真正来源；软前置可并行。
4. **关键路径单列**，并给出"最早可开始的动作（今天 24 小时内能做的）"。
5. **缓冲**：外部审批类节点一律加 30%–50% 缓冲并说明理由。
6. **降级路径**：每份倒排期必须附一条"如果 X 拿不到，则改为 Y 的替代路线"（例如：牌照拿不到 → 先做信息撮合不碰资金；资质未下 → 先做内部演示版不上架）。

### 4.1 输出模板

```
【阶段三 · 倒排期任务书】
T0 = 目标达成日（默认：从今天起 N 周）
M6 … M3 … M1 … M0（今天）
时间轴表：里程碑 | T-? | 交付物 | 验收标准 | 前置 | 工期 | 责任角色 | 硬/软
关键路径：M1 → M2 → M4 → M6（预计 X 周）
今天就能做的 3 件事：①… ②… ③…
降级路线：若 <条件> 不成立 → <替代形态>
```

---

## 5. 阶段四：自我演化（规则萃取 + 闭坑记忆）

每次推演结束，做三件事，缺一不可：

### 5.1 萃取 1–3 条"领域硬核规则"
合格标准（不满足则不写）：
- **可迁移**：同类场景复用，而不是本次项目专有事实（"我们 11 月上线"不是规则）。
- **有后果**：说得出不遵守会发生什么。
- **有主体**：对个人/企业/平台哪一方成立。
- **可验证**：能指向官方入口或平台规则页。

### 5.2 写入知识库（脚本调用）

```bash
# 规则
python "<S>/scripts/rfe.py" add --file <规则卡.json>
# 或直接管道
cat card.json | python "<S>/scripts/rfe.py" add

# 踩坑记忆（本次踩到/预判到的坑）
python "<S>/scripts/rfe.py" pitfall add --file <坑卡.json>
```

规则卡字段见 `references/rule-schema.md`；可用 `templates/rule-card.json` 起步。
重名/重复规则由指纹自动去重并累加 `hit_count`（命中越多，下次排位越前）。

### 5.3 回告用户
在报告末尾写明：`本次沉淀 N 条规则（ID 列表），已入库；下次同类场景将自动前置提示。`

### 5.4 闭坑记忆的用法
- 推演前 `pitfall recall`：把历史坑作为"已知雷区"直接写进阶段二面 C。
- 计划体检 `audit` 报出的**历史纠纷/失败信号**，应回写为新的 pitfall。
- 同一坑第 2 次出现 → 升级为 redline 规则（从"经验"升格为"规则"）。

---

## 6. 报告总模板（默认交付顺序）

```
【0. 结论摘要】3 行：能否做（红/黄/绿灯）｜最硬门槛｜最短周期｜最大风险
【1. 阶段一 · 目标锁定】
【2. 阶段二 · 逆向硬性条件】（合规红线表 / 资源底线表 / 死亡点清单）
【3. 阶段三 · 倒排期任务书】（时间轴 / 关键路径 / 今天 3 件事 / 降级路线）
【4. 阶段四 · 规则萃取】（规则卡 JSON 块 + 入库回执）
【5. 免责与核实清单】（哪几条必须去官方窗口确认、去哪确认）
```

**体检**（交付前自跑一遍，红项必须修掉）：

```bash
python "<S>/scripts/rfe.py" audit --plan report.md --domain "电商平台"
```

`audit` 检查：四阶段是否齐全、推导句式数量是否达标、该领域红线是否被覆盖、是否出现危险话术（承诺过审/包过/保证收益/个人账户收款/规避审核）。

---

## 7. 反模式（出现即退化，禁止）

1. **目录式回答**：只列"你需要准备资质"，不写对谁、周期、后果。
2. **通用废话**：任何行业都能套的句子（"要做好市场调研""要注意合规"）。
3. **正向流水账**：写成"1.注册公司 2.开发 3.上线"，失去逆向价值。
4. **过度提问**：连问 8 个问题却不给推演结果。
5. **假装确定**：把"某类许可"写成具体文号但其实是编的。
6. **只谈合规不谈商业**：合规是底线，死亡点往往在商业侧（没人用、没商户、没现金流）。
7. **不落库**：推演完不萃取规则，下次从零开始。

---

## 8. 可信度与免责（必须随报告输出一次）

- 法规库为**通用认知 + 官方入口索引**，不是法律意见；涉及具体交易结构、股权、刑事风险，须由执业律师出具意见。
- 每条硬性条件都可用 `verify` 更新状态：`python "<S>/scripts/rfe.py" verify --id RULE-XXX --confidence high --note "已电话核实"`。
- 超过 180 天未核实的规则由 `doctor` 标为 `stale`，再次召回时会显式提示"需重新确认"。
- 商标/产品名（如淘宝、微信、支付宝）仅作指示性举例，与权利人无任何关联。
- **来源与原创性**：代码与文本为原创，四阶段框架源自委托方提供的原始提示词（详见 `PROVENANCE.md`）。对外发布前运行 `python "<S>/scripts/provenance_check.py"` 自查是否夹带第三方代码或文本。

---

## 9. 文件索引

| 路径 | 内容 |
|---|---|
| `references/stage1-target-locking.md` | 八维锁定、伪需求识别、选项库 |
| `references/stage2-requisites.md` | 六层合规扫描法、资源底线算法、死亡点清单 |
| `references/stage3-milestones.md` | 倒排算法、关键路径、缓冲与降级 |
| `references/stage4-evolution.md` | 规则萃取标准、召回打分、闭坑升级机制 |
| `references/rule-schema.md` | 规则卡 / 坑卡字段定义 |
| `references/anti-patterns.md` | 12 种失败推演对照 |
| `kb_seed/*.json` | 种子规则库（按领域） |
| `scripts/rfe.py` | 知识库 CLI（零依赖） |
| `scripts/install.py` | 安装到 WorkBuddy + 结构校验（`--verify` / `--dry-run` / `--uninstall`） |
| `scripts/package.py` | 打包发布（自动排除私有案例与本地知识库） |
| `scripts/provenance_check.py` | 开源发布前原创性自查（依赖/版权痕迹/外链/来源标注） |
| `PROVENANCE.md` | 溯源与原创性声明（哪部分是谁的、法规引用为何不侵权） |
| `templates/*` | 倒排期任务书 / 规则卡 / 坑卡 / 报告骨架 |

> 私有推演案例（电商 App、招聘小程序）**不随包发布**，存放于仓库外的 `../fuzzy-reverse-flow-私有案例/`。需要参考输出形态时，直接按第 6 节报告总模板生成，不要去找不存在的示例文件。

---

## 使用边界与能力档（v2.3.0 / v1.3.0 硬约束）

1. 本技能是本地文件 + Python CLI + 落盘知识库，**没有 HTTP 服务 / MCP Server / 云端 API**；MIT 只授权使用，不提供远程调用入口。
2. 能力分三档：A 档（宿主能读文件+执行命令，完整能力）、B 档（本地召回规则后注入模型 API）、C 档（网页聊天 / 手机 App，只能降级到方法论提示词）。**网页聊天与手机只能降级到 C 档**，不得伪装成能读取规则库。
3. 调用前必须完成 README「零、使用前提与能力边界」的 12 项自检清单。
4. **允许**：自用、内网团队复用（如需服务化仅绑定 127.0.0.1 环回）、GitHub 开源与 Release。**禁止**：公开 SaaS 产品化、对外经营性 API、面向不特定公众的付费服务、把规则库当商业合规数据服务售卖。
5. 每份输出报告强制附带知识库复核时间戳与完整免责声明 7 条；规则为经验总结，不构成法律意见，上线前必须人工向官方核实。
6. 跨工具告警使用统一问题编码，规范见 `references/issue-codes.md`；发版一致性由 `_check_docs.py` 强制校验。

• .gitignore 1 KB
• CHANGELOG.md 14 KB
• LICENSE 1 KB
• PROVENANCE.md 9 KB
• README.md 29 KB
• SKILL.md 19 KB
• _check_docs.py 11 KB
• 使用说明.txt 13 KB