转山钥匙锚定方案 v0.11

🕐 时效标注（2026-09-13 文档治理）：近期设计件，口径以 TASKS 现行与契约 v1.3 为准。

主笔：波波（方案制定 + 验收检测）｜日期：2026-08-30

v0.11 修订（2026-09-12 刘总拍板，波波）：汇率参数治理批——①新增 §3.4.1「汇率参数下调不溯及既往」：key_grant_real_ratio / key_redeem_real_ratio 下调只对此后新发放额度生效，存量额度按发放时点锁定的比率兑付（上调不受限）。缘起=刘总纠正波波"福钥会随人民币贬值/通胀"的错误判断（福钥结构性通缩：额度唯一来源=服务费背书禁止无对价创设 §3.8 补注、核销即销毁永不回流、存量上界=Σ服务费 ⇒ 不存在通胀通道）；但推演中暴露唯一真实的价值缩水通道=平台事后下调 L2 比率参数，属治理与信任问题而非经济必然性，故立本条封死。v0.10 批注"80% 可调"的语义限定为上线前定价决策，非上线后对存量重新定价。②§8.1 补登记三个汇率参数键（key_face_value_display_fen/key_grant_real_ratio/key_redeem_real_ratio，迁移 058 已落库、staging 实测在位，但 v0.10 批注只改正文口径、漏了参数总表回扫 ⇒ 文档与代码脱节，本批补齐）。③新增 K24（发放侧比率快照字段落库=§3.4.1 的实现依赖，key_balances 实测无快照列，落库前本条仅作运营纪律）、K25（迁移编号 058 撞号清理，两文件并存且均已入 schema_migrations，不可直接改名）。④K16 措辞修正：原"唯一未关闭项"因新增 K24/K25 不再成立，改"未关闭"，裁决状态不变仍待刘总决定。本批未改动任何机制定案与数字参数（80% 默认值、补贴比例、留存 20% 均不动）。

v0.10 修订（2026-09-07 刘总裁决「以我最新的口径为准」，小齐回扫；14:53 刘总纠偏后修订）：真实结算口径升级——机制定案、数字参数化——依据《福钥真实结算规则-刘总交底-2026-09-07》v0.3，全文凡「福钥额度 1:1 于服务费」「1 把=¥1」「80% 仅在核销补贴侧」的旧表述，一律以下列最新口径为准：①宣称 1:1、实际两端真实汇率差——商户获得侧实际价值=宣称值×key_grant_real_ratio（初始默认 80%，L2 可配，示例：交 1000 实得 800）；游客抵扣侧实际抵扣=面值×key_redeem_real_ratio（初始默认 80%，L2 可配，示例：100 福钥实抵 80）；两键默认同值、独立可配，平台留存比例随取值联动（数字不写死，80% 为刘总示例值，上线前按商务测算可调）；②福钥对内=授信额度（商户使用福钥功能时平台替商户掏钱，营销款代付框架）；③补付 100% 全额补付+实时冲减额度、不现付；④呈现红线=福钥不标面值只标抵扣额度、真实汇率不进任何对客对商户可见页面、授信/代付机制不入对外协议（对外维持 v0.7 赠送定性不变，合规价值保留）；⑤两端差额=同一笔差额的两侧呈现，与 D5「最坏情形支出=档位×80%、净留存≥20%」吻合（按初始默认值）；自刷稳亏锁=真实汇率<100% 即成立，锁力度随参数联动，§3.6.7 结论继续成立。本修订按项目惯例以行下批注标注、原文保留备查；涉及福钥结算的后端新功能按本口径开发。

性质：新立文档，替代渔佳智脑「工分」概念在神山秘境的适用；不修改任何既有合规结论

配套阅读：《三价体系与组包责任边界》§11.6（服务费收法）、《合规方案-卖券模式》、《商户工作台设计方案》

v0.2 修订：福钥定位从「游客叙事凭证」改为「商户预付营销筹码」（与工分同构）；抵扣方式确认为方案 A（直接减价）

v0.3 修订：①抵扣比例与服务费定价落为管理端可配置参数（附默认值，迁移 016）；②任务系统不再照搬工分，按朝圣场景重设计（新增 §七任务系统设计）

v0.4 修订（管理层 2026-08-30 决议回填）：①平台收入改双轨收费——新增「佣金保证金」（线下商户间佣金结算担保，平台可垫付、商户限期补足，迁移 019）+「服务费」（与福钥挂钩）；②福钥定性为商户自主营销资源——发放对象商户自定（任务发放+直接发放），平台只管总量与使用规则，不管流向；③新增出发地曝光任务——商户用福钥触发，游客授权出发地，平台获得客源数据资产（§7.7）

v0.5 修订（刘总：福钥涉及其他收益方的抵扣问题）：福钥切成两类——任务福钥（全平台通用，平台用服务费资金池线下结算给被抵扣商户）与商户直发福钥（仅限本商户，无结算闭环）；新增 §3.6 跨商户抵扣结算机制（资金地基/二清合规四防线/两类钱包/数据结构拆分/争议预案），迁移 020

v0.6 修订（刘总 2026-08-30 模拟订单拍板 + 命名定案）：①C 端正式命名「福钥」（数据库字段名不动，只改文案层）；②抽佣点定为核销时抽——福钥核销时平台按面值总额抽取抽佣比例（可配置，默认 20%），结算给核销商户面值×(100%−抽佣比例)，两种福钥合并计算一次抽完；③福钥余额兼任佣金担保信号，改为预警式——不设固定阈值与扣划数值，每笔订单实时提醒双方"福钥余额不足、佣金安全无法保证"，争议走仲裁（K12）+ 软约束，全程福钥不变现；④对齐预约登记制：下单冻结/核销销毁/爽约解冻返还、定金线下直付商户+确认收款、订单二维码分商户核销；⑤商户后台"结算账单"三合一（线下支付/收款后点确认，或约定周期自动确认落账）；⑥两种福钥可叠加使用，迁移 021

v0.7 修订（刘总 2026-08-30 十问拍板：资金模型收口）：①福钥定性终版——平台赠送的不可兑换补贴凭证（"赠送的东西怎么会跟钱扯上关系"）：商户交服务费购买的是平台服务（曝光/任务分发/记账工具/数据），福钥是随服务费赠送的营销补贴凭证，仅在平台认可的前提下当钱用；服务费=平台收入（不退），核销时平台付给商户的款项定性为平台补贴（平台花自己的钱，非资金结算）；②出水口收缩为单一现金出口（新增 §3.8）：全系统只保留"核销补贴结算"一个现金出水口；砍掉通缩抽水 5%（抽佣 20% 已完成回收职能，双抽废止）；"平台福钥池划拨"改为发放额度预算（发放福钥零现金流，现金只在核销时流出）；③服务费不退：商户退出时未使用的福钥额度作废，协议写明；④福钥抵扣不计佣金：佣金基数=游客实付金额（抵扣后），商户协议声明条款（需回扫《联合体分钱机制设计》）；⑤券款纠纷平台只记账不参与：线下收多少退多少或线下协商，平台不提供退款机制、不仲裁券款纠纷（仲裁范围收窄至佣金/保证金，见 §3.9）；⑥票据口径：平台只对服务费开票（信息技术服务），补贴支出平台自列支，商户无需反向开票；⑦自刷防线：经测算自刷净亏抽佣额（稳亏套利），保留预警不加硬机制（§3.6.7），迁移 022

v0.8 修订（2026-08-30 回扫，波波）：清偿 WIP-028 记录的四项 v0.7 回扫缺漏——①新增 §3.11 自营同构原则（六条①：自营身份与普通商户同构，方案此前全文零提及）；②落账周期 30→7 全文回扫（§8.1 配置默认值、§8.3 三合一账单段、待决区落账说明、K22 共 4 处，与双库已改值一致，六条②）；③新增 §8.6 协同订单参与确认机制（六条④：订单生成时参与商户可见、可在时限内决定参与/退出）；④K21-K23 标注定案+清理残留废止路径（§3.8 合规防线表与 K12 行仍写"销毁等额福钥+平台垫付"v0.6 旧路径→统一改为现金保证金唯一执行标的；通缩配置默认值归零标注废止）

v0.8.2 修订（2026-08-30，波波 WIP-046）：新增 §2.4.1「变相转让」与「全额抵扣」疑虑的数学回应——三方账本（帮助者/出资人/商户/平台得失）+标的物定性（已预 funded 折扣权、核销销毁、平台抽佣逐跳落袋）+监管三测试对照（预收资金/兑回现金/货币替代全 ✗）+商户"贴钱"框架（核销=回收沉没营销成本）；论证并入 K16 审查口径，防线 4"不可转让"与联合支付的边界澄清（无对价+真实服务交付+抽佣定价）。

v0.8.1 修订（2026-08-30 刘总资金模型四问定案，小齐并版）：①任务系统改商户发起制——废弃"平台线路任务"（§7.3/§7.6 改写），平台只做基础设施（点位围栏模板 L1 配置、GPS 核验、冻结/核销/销毁流水线），商户=唯一任务发起方，自营想发走 §3.11 同构商户身份同一入口；②取消抵扣上限+开放联合支付（§2.3/§2.4/§3.6.4/§六回改）——自刷稳亏锁（额度 1:1 服务费、补贴 80%<100%）已足，20% 上限属冗余装甲；联合支付按出资来源差异抽佣（本人档/帮助者档，比例 L2 可配）；③额度唯一来源写死——全系统每把福钥背后必须有一笔服务费（含自营同构缴纳），禁止无背书创设（§3.8 补注）；④K6-K20 待决区全部关闭（8 项按口径定案、K13/K18/K20 伪问题删除、K9 转实测、K19 随上限取消失效）

v0.9 修订（2026-08-30 刘总终局拍板：佣金保证金机制整体废止，小齐回扫）："平台根本就没有保证金的概念"——v0.4 引入的佣金保证金（档位缴纳/垫付划扣/限期补足/专户存管，迁移 019/023 两表）全链条废除，平台收入回到服务费单轨。刘总口径原文："平台收了商户的服务费，就用这笔钱帮助商户解决问题，钱用光了要么继续交服务费兑换，要么就再见，反正平台有各种福钥的抽用机制，永远不会赔账。"违约兜底改为额度侧三连（§3.2 重写）：欠账挂账扣福钥发放额度（K15）+ 限制营销功能 + 清退，平台零垫付、零押品、不兜底。回扫范围：§2.2/§3.1/§3.2（整节重写）/§3.5/§3.7/§3.9/§3.10/§3.11/§四/§六红线/§8.1（deposit_* 五键标废止）/§8.2（两表随迁移 024 DROP）/§8.3/§九/§十/K11-K13；《分销系统v2-方案B对齐》"不设佣金保障金"条款恢复有效（v0.4 曾标注推翻，现随决议撤销而复归）。历史版本注记中的保证金表述保留原文备查，以本节为最终口径。

v0.9.1 修订（2026-08-31 刘总授权小齐定稿「不需要我指定数值，你帮我找个最佳方案」，WIP-059）：服务费档位定稿——016 占位值（500/2000/5000）改定稿三档（小微 ¥300 / 标准 ¥1200 / 大型 ¥3800 月付，迁移 027 双库落库）；内部测算锚=商户月平台流水 × 15% 贴下限取档（灯塔策略低门槛换入驻率，费率天花板=拉萨渠道抽成；内部锚禁止外露：协议/页面/发票只出现固定金额档位，永不出现百分比）；新增周期折扣键（季付 9 折/年付 8 折）与创始商户活动键（首期半价、名额 20 户、可随时关闭）两个 L2 配置。保险 B2/B3 定案随批落档（详见《高原安全保障与保险方案》v0.2）

v0.9.2 修订（2026-09-04 晚刘总定案，小齐回扫）：商户平等公理与三层分离定案——①商户平等公理（刘总原话：「所有商户是平等的，没有什么大小之分，唯一的区别就是对平台的认可度和需求」）：禁按规模给商户分档/贴标签，小微/标准/大型等规模表述全线禁用；②功能按业态开放：平台功能按酒店/餐饮/车队/零售补给/景区业态功能包在入驻审核业态时开通，同业态全商户功能完全相同、与付费无关，兼营多业态功能包可叠加；③档位=纯额度规格：档位唯一语义=预购福钥数量（¥1 服务费=1 把），商户自选、平台不审核流水（判流水=碰商户经营数据，与"不碰收银"红线同源），功能不随档位走（功能分档=变相歧视，已否）；④废除一切商户等级名目：§4.3 基础/优选/金牌/神山合伙人全废（刘总原话：「你有钱=福钥，平台就好好的给你提供服务，否则也就是个凑数的」）——商户与平台的关系只有一层：服务费↔福钥额度↔平台服务；额度=商户在平台上的全部身价，欠费=发放停；展示位/排序是付费与经营数据（核销量/履约信用）的自然结果，不立名目、不设等级权益；⑤档位数值效力降级：300/1200/3800 由"定稿数字"降为内部测算基准（流水×15% 推导、非实地调研，凭据不足），对外锁价冻结，待 K2 商务对接取得 3-5 家真实流水与拉萨渠道实价对标后回填报批；年付 8 折挂起（季付 9 折保留，创始商户首期半价活动键保留）；⑥「没有福钥=福钥不动」正解（刘总 22:35）：商户有额度不花=跟没有一样，平台靠福钥流通赚钱（发放→抵扣→核销→消耗→续费循环），平台须盯额度闲置信号（发放引导/任务模板/闲置提醒=正当动作）。回扫落点：§3.3/§3.4（档位表）/§4.2/§4.3（整节废止）/§4.4/§7.7/§8.1（档位定稿说明）/§8.3（购买话术+画像报表）/K21，均以行下批注标注、原文保留备查；依据文档=《2026-09-04-D5档位报批-服务费与B端H5功能分层》v1.1（刘总 2026-09-04 晚逐条审定入库，commit 44cdcef）。

一、概念定义

1.1 一句话

福钥是平台赠送给商户的不可兑换补贴凭证——商户交服务费购买的是平台服务（曝光、任务分发、记账工具、数据回流），福钥是随服务费赠送的营销补贴额度，商户自主决定发给谁（任务发放或直接发放），游客在预约下单时使用福钥直接抵扣（下单冻结），到店核销时销毁。福钥不是货币，不可反向兑换法币、不可在商户间流转、核销即销毁，仅在平台认可的前提下当钱用（刘总 v0.7 定性："赠送的东西怎么会跟钱扯上关系"）。

>

福钥分两类（v0.5）：任务福钥（全平台通用，核销时平台以自有资金补贴给核销商户）与店福钥（商户直发，仅限发放商户自用，无跨商户资金流）——详见 §3.6。

>

📌 【v0.10 批注·2026-09-07 刘总裁决】本段"随服务费赠送"的额度换算按最新口径执行：宣称 1:1；实际价值=宣称值×key_grant_real_ratio（初始默认 80%，L2 可配；示例：交 1000 实得价值 800）；对内框架=授信额度（平台替商户代付营销款，补付 100%+实时冲减不现付）；对外定性维持本段赠送口径不变（合规价值保留）。详见《福钥真实结算规则-刘总交底-2026-09-07》v0.3。

1.2 福钥的定性：服务费买服务，福钥是赠品（v0.7 终版定性）

福钥掌握在商户手里，商户对福钥的发放拥有自主权，但要分清两件事：

• 商户买的是平台服务，不是福钥：服务费的对价是平台提供的服务——曝光位、任务分发与核验、结算记账、客源数据。福钥是平台赠送给商户的营销补贴凭证。这个定性决定了：服务费是平台收入（不退）；福钥是赠品凭证（商户退出时未用完的作废，不存在"退钱"问题）。
• 爱给谁给谁：商户可以通过任务发（公开渠道，平台帮曝光），也可以直接发（扫码赠送/老客回馈/定向营销），平台不控制、不干预发放对象与用途。
• 平台只控总量与使用规则：商户有多少福钥额度（随服务费档位赠送）、单笔最多抵扣多少（合规红线），这两条平台管。福钥发给谁、什么时候发、配合什么活动——商户自己定。
• 手里没有福钥 = 需要续交服务费：福钥额度用完，商户要继续营销就得再交服务费获得新的赠送额度。这是平台收入的循环来源。

这个定性的合规意义：福钥不是商户花钱买的资产，而是平台的补贴凭证——"赠送的东西不跟钱扯关系"，福钥不构成预付消费权益、不构成商户的债权，商户退出时无退还争议，游客侧也不产生"充值/储值"联想。这是比 v0.6 更干净的定性。

1.3 与渔佳智脑工分的关系：同构，换名

结论：经济结构同构（场景从"渔家乐日常消费"换成"转山预售券消费"）；但任务系统不可照搬——朝圣客是一次性客群，没有工分体系依赖的"回头核销"，任务必须按行程叙事重设计（详见 §七）。定性上福钥比工分更干净：工分是商户买的，福钥是平台送的。

1.4 福钥不是货币——四条红线（继承工分铁律，v0.7 强化）

1. 福钥是平台赠送的补贴凭证，不是货币、不是债权——商户不能用福钥向平台主张任何现金权利（退出时不作价、不退还）。
2. 绝不可反向兑换法币（禁止提现）。游客不能把福钥换回钱，商户也不能。
3. 消费即销毁，不流转给商户。游客用完福钥就没了，不会回到商户手里。
4. 福钥不在商户间流转。商户可以把福钥直接发给游客，但不能转给另一家商户（商户间转让福钥 = 福钥货币化）。店福钥更不能在"非发放商户"处核销。

⚠️ 协议里必须写死：「转山福钥是平台向合作商户赠送的营销补贴凭证，不构成任何预付消费权益或有价证券，不可兑换现金、不可在商户间流转、不可向平台主张现金权利；商户在平台规则内自主决定福钥的发放对象与节奏；福钥抵扣金额不计入任何佣金计算基数（§3.10）；服务费为平台服务对价，不因商户退出或福钥未使用而退还」。任务福钥的跨商户补贴条款单独成节（平台花自己的钱补贴核销商户，非代收代付——见 §3.6.4）。

二、福钥的完整流转链路

2.1 核心循环

商户交服务费 → 获赠福钥额度（平台服务的赠品；服务费=平台收入，不退，§3.8）
    ↓
商户自主发放福钥（两条渠道，两类福钥）：
  · 任务渠道：发布推广任务 → 游客完成任务得【任务福钥】（全平台通用）
  · 直接发放：扫码赠送/老客回馈 → 指定游客得【店福钥】（仅限本商户）
    ↓
游客预约套餐/下单 → 使用福钥抵扣（下单冻结；可选定金线下直付商户+商户确认收款）
    ↓
到店出示订单二维码 → 各履约商户分别扫码核销 → 福钥核销时销毁（爽约/取消则解冻返还）
    ↓
核销补贴（v0.7：单一出水口，两种福钥合并计算）：
  · 店福钥：核销在发放商户 → 平台按面值×补贴比例补贴该商户（无跨商户资金流）
  · 任务福钥跨商户使用：平台补贴 面值×补贴比例（默认80%） 给核销商户
    ↓
抵扣促进更多券销售 → 商户赚更多 → 续交服务费 → 循环

2.2 各环节详解（v0.6：对齐预约登记制）

关键：环节①的服务费是平台唯一的服务收入（不退，v0.9：平台不设保证金/押金等任何第二资金线）。环节④⑤的券款与定金都是游客线下直付商户，平台零触碰。环节⑦是平台用自己的收入补贴核销商户（留出 20% 毛利）——这是"平台营销支出"而非"资金中转"（§3.6.4）。全系统现金出水口只有环节⑦这一个（§3.8）。

2.3 抵扣方式（方案 A：直接减价，两种福钥可叠加，v0.6）

游客预约下单时，可使用福钥直接抵扣：

示例（刘总 2026-08-30 模拟订单）：
  某商户套餐 = ¥1,000
  游客持有：任务福钥 50 把（全平台通用） + 该商户赠送的店福钥 100 把
  同单叠加抵扣 150 把 → 游客到店实付 ¥850（线下直付该商户）
  订单完成后核销结算：
    平台补贴给核销商户（补贴比例默认 80%，可配置）：150 × 80% = ¥120
    平台留存（毛利）：150 × 20% = ¥30
    商户该单总实收：¥850（游客） + ¥120（平台） = ¥970

规则：

• 1 把福钥 = 固定抵扣金额，管理端可配置（默认 ¥1，配置键 key_face_value_fen）
• 📌 【v0.10 批注·2026-09-07 刘总裁决】key_face_value_fen 为宣称面值（对客展示用）；游客实际抵扣=宣称面值×key_redeem_real_ratio（初始默认 80%，L2 可配，示例：100 福钥实抵 80），真实汇率只在结算层存在，不进任何对客对商户可见页面。前端呈现：福钥不标面值、只标"本单可抵扣 ¥X"（按真实可抵金额显示，无感知基准）。配置键拆分（key_face_value_display_fen+key_grant_real_ratio+key_redeem_real_ratio 三键）随 v0.10 开发落地，比例不写死。
• 两种福钥可叠加使用（任务福钥+店福钥同单累加），店福钥仅在对应商户的订单中生效
• 不设单笔抵扣比例上限（v0.8.1 刘总拍板，原 20% 上限废止，理由见 §2.4）；key_deduct_max_ratio 配置键保留兼容、默认改 100，不再设代码硬上限
• 开放联合支付（v0.8.1 新增）：同一订单可由多人出福钥共同抵扣（如同伴帮忙凑福钥），按出资来源分账适用差异抽佣档——本人福钥按 key_redeem_commission_ratio（初始 20%），帮助者福钥按 key_joint_pay_helper_ratio（初始 30%），均 L2 管理端可配
• 福钥下单时冻结、核销时销毁、取消/爽约解冻返还
• 抵扣记录写入 credit_journal（biz_type='key_redeem'；联合支付按出资人分笔记录）

2.4 为什么不设抵扣上限（v0.8.1 刘总拍板，原 20% 上限废止）

v0.3-v0.8 期间设 20% 单均抵扣上限，理由是"防福钥变免费券=变相货币"。v0.8.1 重新拆解后确认该上限属冗余装甲而非承重墙，予以取消：

• 自刷稳亏锁已足（§3.6.7）：福钥额度 1:1 于服务费、核销补贴只有面值的 80%——商户自发自抵每循环净亏 20% 抽佣。这把锁在，即使 100% 抵扣+联合支付全开，也没有人能拿福钥从平台套出钱。
• 合规承重墙另有其物（§3.6.4）：防"变相货币/预付卡"的是——游客零购买获取（无储值）、不可提现、不可商户间流转、核销即销毁。单均抵扣比例不是承重构件。
• 经济账上不成立（刘总原话："赚双份的钱，为什么要限制"）：组合抵扣的商品绝大多数本身有利润差，商户让利的部分被商品利润+平台核销补贴覆盖——商户接福钥只赚不亏才会抢着接，限制抵扣等于给飞轮踩刹车。

联合支付机制（v0.8.1 新增，与取消上限配套）：允许多人出福钥共同抵扣同一订单。帮助者福钥适用更高抽佣档（初始 30%，本人档 20%）——给"福钥帮付"这个流转行为定价，差额归平台；比例均为 L2 配置项，管理端可调。

2.4.1 「变相转让」与「全额抵扣」疑虑的数学回应（v0.8.2 增补，波波）

背景：v0.8.1 取消上限+开放联合支付后，交叉评审提出两问——①联合支付是否构成"变相转让"，击穿 §3.6.4 防线 4（不可转让）？②游客凑福钥全额抵扣（免单）的监管观感如何？本节记录论证结论：两问均不成立，理由并入 K16 法律审查口径（K16 审查时按本节口径正面论证）。

三方账本：一次"帮付核销"里各方的得失

标的物定性：帮付流转的从来不是"钱"，是已预 funded 的折扣权——三重属性封死了支付工具定性：①来源唯一（每把福钥背后是真实服务费+真实任务行为，无对价发行不存在）；②核销即销毁（折扣权用一次少一次，永不回流，无独立流通层）；③平台抽佣在核销时点已落袋（流转链条每一跳平台都收钱，无资金归集）。即使出现客户间"卖帮付"的灰色市场，它转移的也只是折扣权本身——属于闲鱼卖券级别的用户协议+风控标记问题，不落入《217 号文》/预付卡监管射程。监管三测试全过：预收资金（游客零购买）✗、兑回现金（补贴只付给真实履约的商户）✗、货币替代（不可提现、核销销毁）✗。

全额抵扣（免单）的敞口：全部补贴 ≤ 服务费池×80%——"游客免费游"本质是商户预付、平台执行的一次营销支出，敞口在服务费进账时已被锁定。运营卫生项（非风险项，可选）：全额抵扣订单打观察标记+人工复核抽样，补贴台账单列。

商户"贴钱"框架（帮助者档 30% 为什么不构成商户负担）：福钥是商户交服务费时白拿的赠品，营销成本在服务费支付时点已沉没。核销 70% = 从沉没成本中收回 70%，核销 0 把 = 沉没 100%——任何档位的核销都是正回收，帮助者核销还额外带来一个真实客人和一个潜在客人。帮助者档差异是平台对流转行为的定价，不是对商户的税收；市场觉得紧了，L2 调档即可（自刷稳亏锁与经济账双锁在，调档无套利风险）。

论证口径并入 K16：审查"取消抵扣上限+联合支付是否构成多用途预付卡/支付工具"时，按本节正面论证；§3.6.4 防线 4 的"不可转让"指平台不提供转让功能、福钥不可兑回，同单共同消费的联合支付与之不冲突（无对价、有真实服务交付、抽佣已定价）。

三、平台盈利保障模型（v0.9：服务费单轨 + 单出水口）

3.1 核心逻辑（v0.9 终版）

采用渔佳智脑模式 → 小程序不做线上支付（券款直付商户）→ 平台没有交易现金流 → 平台收入只来自商户侧的一笔钱——服务费：

平台现金流入（唯一）= 服务费（平台服务对价，收入，不退）

平台现金流出（全系统唯一）= 福钥核销补贴 = 核销面值 × 补贴比例（默认 80%）

安全性（数学保证永不亏本，见 §3.8）：
  核销面值 ≤ 商户额度 ≤ Σ服务费，且补贴比例 80% < 100%
  → 即使 100% 核销，平台仍留 20% 毛利
  → 到期未核销的福钥 = 零成本纯利润（平台没付过一分钱）

平台不赚"交易"的钱，赚"让交易发生"的服务费；补贴商户是平台的营销成本支出，不是资金结算。

服务费定性（v0.7 定案，v0.9 唯一化）：

为什么这个模型干净（v0.7 定性的合规价值，v0.9 进一步强化）：

• 服务费是商户买服务的钱 → 纯收入，无"预收款/储值"嫌疑；
• 福钥是赠品凭证 → 不是商户的资产、不是债权，退出时不存在"退钱"争议；
• 核销补贴是平台花自己的收入给商户发补贴 → 单向支出，不是"代收代付"、不是"资金中转"——这是"赠送的东西不跟钱扯关系"的完整表达；
• 平台没有任何第二条资金线（v0.9）：不收押金、不做垫付、账上无"其他应付款"——资金结构简到不能再简，二清/资金池/存管义务的合规讨论整体失去对象。

3.2 商户间佣金争议：平台仲裁 + 额度侧执行（v0.9 重写：零垫付、零押品）

背景：商户之间的佣金结算（领队/分销/联合体分账，见《联合体分钱机制设计》§八）走线下议价、线下结算——平台只记录结算口径，不碰钱。线下结算的最大风险是应付方赖账/拖延。v0.4 曾为此设计"佣金保证金"兜底；v0.9 刘总终局拍板：平台根本就没有保证金的概念，整套机制废止。

刘总口径（2026-08-30，原文在案）："就定为'欠账扣额度+限制营销+清退'，平台零垫付、零押品。平台收了商户的服务费，就用这笔钱帮助商户解决问题，钱用光了要么继续交服务费兑换，要么就再见，反正平台有各种福钥的抽用机制，永远不会赔账。"

机制设计（额度侧三连）：

商户间线下佣金结算发生争议：应付方拖延/拒付，且证据链完整（小票+定位+时间戳或确认记录）
    ↓
平台仲裁（K12 两级：平台初审+商户代表复核）→ 裁决生效
    ↓
① 欠账挂账：裁决金额记入应付方「待支付欠账」台账
    ↓
② 额度冻结：欠账直接抵扣福钥可发额度（K15：可发额度 = 剩余额度 − 待支付欠账 − 预留）
   + 限制营销功能（任务发布/直接发放/曝光位冻结）
    ↓
③ 限期清偿（默认 7 天可配）：应付方与应收方线下结清 → 平台凭双方确认销账解冻
    ↓
逾期不清偿 → 清退（解除协议，未使用福钥额度作废，欠账转为合作方间线下债权，平台不兜底）

四条铁律：

1. 平台零垫付、零押品：平台没有保证金、不设专户、不动自有资金垫付任何商户间债务。应收方的救济=裁决留证+应付方被限制经营能力，债务本身由双方线下了结。
2. 执行打在额度上，不打在钱上：商户违约的代价是失去平台营销资源（福钥发放权/任务发布/曝光位），不是被扣钱——这与"平台只碰服务费一根资金线"完全一致。
3. 裁决必须证据链完整（小票+定位+时间戳或商户确认记录），不凭空裁决——仲裁是信用裁判，不是资金执行。
4. 退出先清账：商户退出时未了结的裁决欠账不销，列入平台信用档案；未使用福钥额度作废（服务费不退）。

合规定性：

• 平台对商户间债务只记账、只裁判、不兜底——无资金归集、无垫付义务，自然不触及资金池/二清/存管任何问题，此前 v0.4 围绕保证金的整套合规章节（专户存管/动态充实/连带清偿）随之失去对象。
• 额度限制属于平台对自有营销资源的配置权，协议写明即有效；裁决程序规则见《商户间结算与争议处理规则》（随 v0.9 同步重写）。

3.3 服务费：平台服务的对价（按档位固定，不按 GMV 抽成）

【v0.9.2 批注】本节"档位"=纯额度规格（预购福钥数量），不含功能差异、不含商户规模标签；平台功能按业态开放（入驻审核时开通，同业态全商户功能相同，与付费无关），功能分档已否决（=变相歧视）。详见 §3.4 表下批注与 D5 文档 v1.1。

名目：技术服务费 / 平台服务费（禁用"佣金""分成""返点"）

发票：信息技术服务\*技术服务费

可退性：不退（刘总拍板）。商户退出时未使用的福钥额度作废，协议写明"服务费为平台服务对价，不因商户退出或福钥未使用而退还"。

3.4 福钥额度与服务费的换算（v0.7：服务费买服务，福钥是赠品）

服务费档位管理端可配置（配置键 key_service_fee_tiers，JSON 数组，迁移 016 已落默认值）。下表为默认值：

【v0.9.2 回扫批注】本表为迁移 016 占位值原文，数值已被 027（300/1200/3800）取代（见 §8.1），且按 2026-09-04 晚定案：①「适用商户」列废止——禁按规模分档贴标签（小微/中型/大型表述禁用，商户平等公理），档位由商户按自身额度需求自选，平台不审核流水；②「高级档+优先展示位」废止——展示位是付费与经营数据的自然结果，不立名目、不作档位权益承诺；③「定制档·战略合作」名目废止——需要更多额度=续费/加购，无战略档。档位唯一语义=「¥1 服务费=1 把福钥额度」。

换算逻辑（v0.7 定性）：商户交 ¥1 服务费 → 获得平台服务 + 获赠 1 把福钥额度。福钥面值 ¥1，游客可抵扣 ¥1 券款。商户把福钥发给游客 → 游客核销 → 平台补贴核销商户 ¥0.8（80%，可配置）。商户的视角：花 ¥1 服务费，换来曝光+任务分发+记账工具+500 把可自主发放的补贴凭证。平台的视角：收 ¥1 服务费，核销时支出 ¥0.8 补贴，毛利 ¥0.2 + 未核销沉淀。

续购循环：福钥发出去并被核销销毁后，商户额度减少；额度归零时，商户需再交服务费获得新的赠送额度。"手里没福钥就要续交服务费"是平台收入的永续引擎。

配置调整守则：档位改价属于商业决策，管理端可自由调整；但配置里永远不出现"按交易额百分比"字段——服务费与福钥额度必须是固定数量关系，与商户营业额脱钩（合规红线，见 §六）。

3.4.1 汇率参数下调不溯及既往（v0.11 新增，刘总 2026-09-12 拍板）

条款：key_grant_real_ratio / key_redeem_real_ratio（v0.10 引入的两个真实汇率键）下调时只对此后新发放的福钥额度生效；存量额度一律按发放时点锁定的比率兑付。上调不受此限（上调对商户有利，无争议）。

为什么必须有这条：v0.10 批注（本文档头部）写明「数字不写死，80% 为刘总示例值，上线前按商务测算可调」——"可调"指的是上线前的定价决策，不是上线后对存量重新定价。两键落库为 L2 可配（迁移 058，staging 实测 key_grant_real_ratio=0.8 / key_redeem_real_ratio=0.8 已在 system_settings），意味着运营侧随时可改。若改值溯及存量：

商户交服务费是已履行的付费义务，福钥额度是其对价。平台事后下调比率减少兑付，在合同法上属单方面变更已成立的对价关系，在商业上是信任自杀（商户会立刻要求退费，而 §3.3 已定"服务费不退"，两边都堵死 ⇒ 必然纠纷）。

与既有机制的关系：本条不是新增原则，而是把已有原则前移一个环节——key_settlements 表已有 retain_ratio 字段（迁移 023），即结算时点已对比率做快照；本条要求把同一做法前移到发放时点。

⚠️ 实现依赖（待落库，本条不自行实现）：staging 实测 key_balances 表当前列为 id, user_id, scope_type, merchant_id, balance, frozen, is_test, created_at, updated_at——无比率快照字段。本条款要成立，需新增迁移给额度记录补发放时点比率快照（如 granted_real_ratio），由福钥域后端（WIP-243 任务系统后端 / 结算域）排期实现。在快照字段落库前，本条仅作为运营纪律生效：管理端下调比率前须人工确认存量兑付口径，不得直接改值上线。

登记位置：§8.1 参数总表（两键补登记，本批同步修正文档与代码脱节）+ 待决区 K24。

3.5 平台的真实收益（v0.7 终版）

平台现金流入 = Σ 商户服务费（平台服务对价，收入）
平台现金流出（全系统唯一出水口）= Σ 核销补贴 = Σ(核销面值 × 80%)

平台净收益 = Σ服务费 − Σ核销补贴
安全性：核销面值 ≤ 商户额度 ≤ Σ服务费，且 80% < 100%
→ 即使 100% 核销，平台仍留 20% 毛利（数学保证永不亏本）
→ 到期未核销的福钥 = 零成本纯利润（平台没付过一分钱）

平台不赚：券款差价、旅游交易佣金、资金沉淀利息

商户为什么愿意付服务费？（v0.9 改写）

1. 服务费买的是增长：曝光、内容素材、客源数据、券销售增量、福钥营销工具；
2. 守信用才留得住工具：在联合体里"说话算数"的商户，领队和分销方才敢放心带客来；赖账的代价是欠账挂账→福钥发放冻结→营销功能受限→清退（§3.2）——不需要押金，失去平台资源本身就是最大的违约成本。

⚠️ 名目纪律：平台核销补贴支出是"平台营销费用"（平台花自己的钱给商户发补贴），不是"从商户池子里扣钱再还给商户"。话术上禁用"抽佣/抽成/分成"，统一表述为"平台补贴结算"。

3.6 两类福钥与跨商户抵扣结算（v0.5 核心新增）

管理层决议：福钥一旦跨商户使用，就必然产生"谁补偿谁"的结算问题。为此把福钥切成两类——任务福钥（全平台通用） 与 商户直发福钥（仅限本商户），两类走完全不同的结算路径。这是本章的核心，也是福钥系统能否成立的资金地基。

3.6.1 问题的本质：跨商户抵扣=一笔必须有人买单的账

游客在商户 A 的任务里挣到福钥，跑去商户 B 的券上抵扣 ¥1——B 的券款实收少了 ¥1，但营销好处（任务完成、曝光、内容）是 A 拿走的。这笔 ¥1 谁出？ 不解决这个，商户 B 就会拒绝接受福钥，福钥的"通用性"立刻崩塌。

切两类，就是把这个账算清楚：

为什么这样切是对的：

• 店福钥无跨商户资金流、零争议——商户自己发、游客只在自家店用、抵扣减的是自家券款。这和商户"发一张自家折扣券"完全等价，不涉及任何跨主体资金，系统只要锁死"店福钥只能匹配发放商户的券订单"即可。
• 任务福钥是全平台的公共激励——游客在哪都能用，体验最顺滑、福钥最"值钱"、最能驱动做任务；但代价是跨商户使用必须有人买单，所以由平台补贴核销商户（§3.8 单一出水口）。
• 叠加使用（v0.6）：两类福钥可在同一订单叠加抵扣（各自规则不变：店福钥仅在本店生效），合并计入核销面值，一次补贴结算——游客侧体验最顺，账也最平。

3.6.2 资金地基：服务费=平台收入，补贴=平台支出（v0.7 拍板）

关键结论：商户交的服务费是平台的服务对价（纯收入）；福钥核销后平台付给商户的款项是平台花自己的钱发的补贴（纯支出）。 一进一出都是平台自己的钱，不碰游客、不中转商户，资金上天然自洽。

商户交服务费（如 ¥2,000/月 → 获赠 2,000 把福钥额度）
        ↓  服务费 = 平台收入（不退）
福钥发放给游客（任务福钥/店福钥均可，发放环节零现金流）
        ↓
游客下单抵扣（福钥冻结）
        ↓
到店核销（订单二维码被商户扫码）→ 福钥销毁
        ↓
核销补贴结算（两种福钥合并计算）：
  · 该单福钥核销面值总额 = 任务福钥 + 店福钥 之和
  · 平台补贴给核销商户 = 面值总额 × 补贴比例（默认 80%，可配置）
  · 平台留存 = 面值总额 ×（100% − 补贴比例）= 平台毛利
        ↓
补贴单进入商户后台"结算账单"（与协议价成本/佣金应收应付同屏）

用刘总的模拟订单走一遍：套餐 ¥1,000，游客用 50 任务福钥 + 100 店福钥（同店叠加 150 把）→ 游客到店付 ¥850 → 核销后平台补贴给该商户 150×80% = ¥120，平台留存 150×20% = ¥30 毛利。商户该单总实收 ¥970，游客实付 ¥850，平台留 ¥30。账平。

五条结算铁律（v0.7）：

1. 补贴只在核销时发生，两种福钥合并计算——发放环节零现金流，不存在"发放时扣钱"。
2. 平台花自己的钱（服务费收入）补贴核销商户，不碰游客的钱、不中转商户之间的钱——这是"平台营销支出"，不是资金二清（合规要害，见 §3.6.4）。
3. 补贴比例 < 100% 即永不亏本：核销面值 ≤ 商户额度 ≤ Σ服务费，且补贴 80% < 100%，数学保证平台留 ≥20% 毛利。
4. 沉淀即纯利（breakage）：到期未核销的福钥 = 平台零成本纯利润（没付过一分钱补贴）。
5. 店福钥核销同样补贴——商户自己发的店福钥核销在自家店，平台仍按面值×80% 补贴给该商户。店福钥"无跨商户资金流"指的是不产生跨商户资金流，不是平台不补贴。

3.6.3 店福钥（商户直发）的闭环规则

• 店福钥只能在发放商户处抵扣，系统硬性锁定：核销请求必须匹配发放商户自己的券订单，否则拒绝。
• 抵扣减少的是该商户自己的券款实收——自己发的券自己担，无跨商户资金流、无对账争议。
• 核销补贴照走（§3.6.2）：平台按面值×补贴比例补贴给该商户。
• 店福钥的额度来自该商户获赠的福钥额度，发完即止，用完要续交服务费。

3.6.4 合规要害：为什么这套补贴不构成"二清"

任务福钥"全平台可用 + 平台付现金给核销商户"，表面看像一个跨商户预付凭证/代币，是监管最敏感的地带。五条设计把它按死在"平台赠送的补贴凭证"而非"资金结算工具"上（v0.7 定性强化了第 5 条）：

1. 平台不向游客收钱——福钥只能靠做任务挣或商户赠送，游客没有一分钱进入平台，无资金归集。
2. 平台补贴用的是自己的服务费收入——不是代收游客钱再转付商户，无第三方资金中转。
3. 补贴率 <100% = 自刷稳亏锁——商户额度 1:1 于已交服务费，核销补贴只有面值 80%（可配），任何"自发自抵套现"每循环净亏抽佣金（§3.6.7），福钥无法成为从平台取现的通道。（v0.8.1 改写：原"抵扣上限 ≤20%"防线废止，见 §2.4）
4. 福钥不可提现、不可转让、到期作废——不具货币属性。
5. 福钥是平台赠送的凭证，不是商户的资产（v0.7 新增）——商户买的是平台服务，福钥是赠品。商户对福钥没有债权，退出时不可主张退还。"赠送的东西不跟钱扯关系"——这条把福钥与"预付卡/储值/商户债权"彻底切割。

⚠️ 尽管设计上自洽，「跨商户通用+平台补贴现金给商户」仍属合规高敏区，上线前必须过一次专项法律审查（重点：是否被认定为多用途预付卡/支付工具；票据口径——平台只对服务费开票，补贴支出平台自列支，商户无需反向开票，见 §3.10）。

3.6.5 游客侧的两类钱包呈现

• 钱包页显示两栏：「通用福钥 N 把（全平台可用）」+「店福钥：XX店 M 把 / YY店 K 把（仅限本店）」
• 抵扣时优先扣通用福钥（通用性强、对游客最划算），店福钥仅在对应商户结算页可用
• 两类福钥各自独立有效期、独立销毁

3.6.6 数据结构变更（现有单一余额不够用了）

现有 user_wallets.balance 是单一余额，无法区分两类福钥，必须拆：

3.6.7 争议场景预案（v0.7 更新）

3.7 福钥余额的担保信号作用：预警式、不变现（v0.6 新增，v0.7 强化）

刘总决议：福钥余额兼任商户佣金结算的担保信号——但不设固定阈值、不设固定扣划数值，改为预警式：

每笔含佣金结算的订单（下单/结算时）
    ↓
系统检查应付方商户的福钥余额与该笔佣金的关系
    ↓
余额不足 → 实时预警【双方】：「该商户福钥余额不足，本单佣金安全无法保证」
    ↓
· 商户补服务费/福钥 → 预警解除
· 不补 → 预警持续挂起，交易照常（不阻断），但双方知情
    ↓
真发生佣金争议 → 走仲裁（K12），执行=欠账挂账+额度侧三连（§3.2），与福钥余额本身无关

三条设计原则：

1. 预警不阻断：余额不足只提醒，不拦交易——福钥是营销资源不是交易许可，拦交易会伤用户体验和商户经营。提醒本身就是约束：对面商户看到预警，自己会掂量要不要继续合作。
2. 全程福钥不变现、不被执行（红线，v0.7 强化）：福钥是平台赠送的凭证，不是商户的资产——任何场景下福钥都不能转换成现金，也不能被仲裁扣押或强制执行。v0.9 终局口径：佣金争议的执行方式是欠账挂账+冻结福钥发放额度+限制营销+清退（§3.2 额度侧三连）——限制的是"继续获取福钥的资格"，不是把存量福钥变成钱。v0.6 中"销毁等额福钥+平台垫付"、v0.4-v0.8 中"现金保证金划扣垫付"两条执行路径均已废止——前者把福钥和钱扯上关系，后者引入了平台本不该有的资金线。
3. 软约束梯度（"没钱不陪你玩"）：长期余额不足的商户 → 降权（任务发布限流）→ 降曝光（展示位降权）→ 风险提示（对合作方公示信用状态）。不罚钱、不封号，让市场自己淘汰。

福钥余额预警=唯一担保机制（v0.9）：保证金机制废止后，福钥余额预警就是商户间信用的全部基础设施——它是动态担保信号（实时、连续、预警式），解决"出事之前怎么让双方心里有数"；出事之后走 §3.2 的额度侧执行。福钥永远不是执行标的——它是赠品凭证，不是商户的钱；被冻结的是"发放资格"，被扣减的是"可发额度"，存量福钥本身不动。

3.8 资金模型收口：单一现金出水口（v0.7 新增，刘总拍板"出水口要收缩"）

v0.3-v0.6 期间福钥系统叠出了多个资金概念（资金池/通缩/福钥池划拨），刘总要求收口。v0.7 定案：全系统只有一个现金出水口。

现金流入（1 个入口）：
  服务费（商户→平台，收入）

现金流出（1 个出口）：
  核销补贴结算（平台→核销商户，面值×80%）

已废止的出水口：
  ✗ 通缩抽水 5%（key_deflation_ratio）——v0.7 废止，默认改 0；
    抽佣 20%（留存比例）已完成"回收"职能，再抽一刀是双收
  ✗ "平台福钥池划拨 10%"（key_common_pool_ratio）——不再表述为现金划拨；
    任务发放福钥本身零现金流（现金只在核销补贴时流出）
  ✗ "平台线路任务/平台自有额度"（v0.8.1 废止）——任务系统改商户发起制（§7.3），
    平台不做任务发起方、不设任何自有福钥池

数学安全（永不亏本证明）：
  补贴支出 = Σ(核销面值 × 80%)
  核销面值 ≤ 商户额度 ≤ Σ服务费（商户不超额发放，1:1 赠送）
  → 补贴支出 ≤ Σ服务费 × 80% < Σ服务费 = 现金流入
  → 即使 100% 核销，平台仍留 ≥20% 毛利
  → 到期未核销的福钥 = 零成本纯利润

额度唯一来源铁律（v0.8.1 刘总拍板）：
  全系统每一把福钥背后必须有一笔真实服务费（含自营按 §3.11 同构缴纳），
  禁止任何无服务费背书的额度创设——平台自身也不例外。
  否则数学锁脱锚（印多少未来掏多少），且构成"裁判不守规则"的体外循环（§3.11）。

这个收口的意义：商户对账只需要看两笔账——"我交了多少服务费、我被补贴了多少"，没有池子、没有通缩、没有划拨，账目一目了然。对监管也最干净：一进一出，都是平台自己的钱。

3.9 争议与纠纷的边界：平台只记账，不参与券款纠纷（v0.7 新增，刘总拍板）

券款纠纷（游客⇄商户）：券款是游客线下直付商户的，平台零触碰。发生服务纠纷（服务不符/退款/爽约）时：

• 线下收多少就退多少，或者线下协商——退款是游客与商户之间的线下行为；
• 平台只记账，不参与纠纷、不做仲裁、不提供退款机制——平台记录订单/核销/抵扣数据，但不裁决谁对谁错；
• 协议写明："平台仅提供信息撮合与记账服务，券款结算与纠纷处理由游客与商户自行解决。"

仲裁范围收窄：平台仲裁（§3.2、K12）只处理商户间佣金争议（领队/分销/联合体分账的线下佣金拖欠）——裁决生效后按额度侧三连执行（欠账挂账→冻结发放额度+限制营销→逾期清退），平台零垫付、零押品。

福钥永远不进入仲裁标的——它是平台赠送的补贴凭证，不是任何一方的财产（§3.7 原则 2）。

3.10 佣金计算基数与票据口径（v0.7 新增，刘总拍板）

佣金基数：福钥抵扣金额不计入任何佣金计算基数。佣金按游客实付金额（抵扣后）计算：

示例：套餐 ¥1,000，福钥抵扣 ¥150 → 游客实付 ¥850
佣金（如领队 10%）= ¥850 × 10% = ¥85（不是 ¥100）

必须在商户协议中声明："福钥抵扣金额不计入佣金、分账、返点的计算基数；各方佣金按游客实际支付金额计算。"（需回扫《联合体分钱机制设计》§八补入此条）

票据口径：

3.11 自营同构原则（v0.8 新增，刘总六条①定案）

平台自营业务（自营商城、自营线路、直营服务）在福钥与结算体系内与普通商户完全同构，不设特殊通道：

• 同一身份结构：自营业务以「自营商户」账号入驻平台，与普通商户走同一套入驻、服务费缴纳、福钥额度获取流程；
• 同一结算路径：自营核销福钥同样按"核销→平台补贴（面值×80%，可配）"结算并计入补贴结算台账（key_settlements）；涉及佣金结算的同样按游客实付计基数——账目口径与普通商户完全一致，可逐笔对审（即六条①所谓"1P 同样按档位获福钥额度、核销抽佣照计=内部回收不走对商户结算"）；
• 同一约束规则：双约束（§4.1）、损管与禁刷（§3.6.7）、话术红线（六条⑥：任何文案禁现"兑付现金"类字眼）对自营同样适用；
• 为什么必须同构：自营若走体外循环，商户会质疑"平台既当裁判又当运动员还不守同样规则"；监管视角下，自营体外结算也构成隐蔽的资金池路径。同构=全体系一笔账，审计可过、商户服气。

自营商户账号由平台指定人员管理，全部运营操作留痕；自营与普通商户的区分仅体现在后台统计标签（如 is_self_operated），不体现在任何流程与费率差异。

四、商户规范机制（服务费+福钥余额预警双约束，v0.9）

4.1 双约束模型（v0.9：保证金线废止，信用约束全部落在额度侧）

商户在平台受到两条线的约束，一条管"增长意愿"，一条管"履约信用"：

两条线互为犄角：商户想获客就得有福钥（增长线），想在联合体里被信任就得守信用（信用线）。欠账挂账 = 增长线同步受限——被裁决未清偿的商户，任务发布/直接发放/曝光位全部冻结（§3.2 额度侧三连）。

4.2 商户行为与福钥/信用的挂钩

【v0.9.2 批注】表内"等级提升""影响商户等级→影响展示位""降级"三处的"等级"名目已废（§4.3 整节废止）：奖惩落点改读为展示排序与曝光权重（按核销量/履约信用等行为数据自然计算，不立名目）及额度侧措施（§3.2 三连），激励与约束逻辑本身不变。

4.3 商户等级与展示位

【v0.9.2 整节废止】 2026-09-04 晚刘总定案：废除一切商户等级名目（基础/优选/金牌/神山合伙人全废）。刘总原话：「所有商户是平等的，没有什么大小之分，唯一的区别就是对平台的认可度和需求」「你有钱=福钥，平台就好好的给你提供服务，否则也就是个凑数的」。正解：商户与平台的关系只有一层——服务费↔福钥额度↔平台服务；额度=商户在平台上的全部身价。展示位/排序是付费与经营数据（核销量/履约信用）的自然结果（由排序与推荐规则体现），不立名目、不设等级权益、不作协议承诺。下表保留备查，不再作为执行依据。

4.4 与防漏记机制的衔接

福钥系统是防漏记的正向激励层：

• 游客扫码记录到店消费 → 完成任务/商户直接发放 → 获得福钥 → 商户消费数据回流
• 商户消费数据越完整 → 福钥核销量越高 → 商户等级越高 → 商户越有动力维护消费记录
• 福钥系统把"商户记录消费"从被动合规变成主动追求

【v0.9.2 批注】上链"商户等级越高"改读为"展示排序自然靠前"（等级名目已废，§4.3）：数据完整→核销量高→曝光自然多→更有动力维护记录，正向激励逻辑不变。

五、游客侧体验

5.1 游客怎么获得福钥

游客不花钱获得福钥，两个渠道（详细任务体系见 §七 任务系统设计）：

5.2 游客怎么用福钥（两类钱包可叠加，v0.6）

在预约下单时，选择"使用福钥抵扣"：

钱包呈现（两栏）：

• 「通用福钥 N 把」——全平台任意商户可用
• 「店福钥：XX店 M 把 / YY店 K 把」——仅限对应商户

抵扣规则：

• 结算页自动显示可用福钥：通用福钥恒可用；店福钥仅当该券属于发放商户时出现
• 两类福钥可同单叠加（如 50 把通用 + 100 把店福钥 = 抵扣 150 把），系统按默认顺序扣（优先店福钥，锁住本店转化；可手动调整）
• 勾选使用 → 券款直接减价 → 应到店付金额减少 → 下单时福钥冻结
• 到店出示订单二维码 → 商户扫码核销 → 福钥核销时销毁；取消订单/爽约 → 福钥解冻返还
• 定金（如订单需要）：线下直付商户，商户在后台确认收款；界面话术：「定金 ¥200 已线下支付，待商户确认」
• 界面话术：「您有 15 把福钥，可抵扣 ¥15」

5.3 游客侧的叙事包装

虽然底层是"商户营销补贴"，但对游客的呈现是转山修行的奖励：

• 福钥余额页：显示为"福钥串"（通用福钥=主福钥串；店福钥=各家商户的"专属福钥"挂在串上）
• 任务页：显示为"转山修行任务"（不是"帮商户打工"）
• 抵扣页：显示为"用修行成果抵扣券款"（不是"用优惠券"）

游客感知：我转山/打卡/拍照 → 获得福钥 → 福钥能帮我省钱 → 继续转山。正向循环。通用福钥让"省钱"贯穿整个行程，店福钥让"回头到店"有利可图——一个锁住行程，一个锁住商户。

六、合规红线（不可逾越）

⚠️ 协议定性：福钥是「平台向合作商户发行的营销服务凭证」，不是「预付消费卡」「积分」「代币」「有价证券」「货币」。

⚠️ 跨商户结算专项法律审查（上线前必过）：任务福钥全平台通用 + 平台结算现金给商户，是福钥系统合规敏感度最高的设计。四防线见 §3.6.4。上线前需律师专项审查是否构成多用途预付卡/支付工具，并确定结算票据口径（按营销服务费开票，不按货款）。

七、任务系统设计（不可照搬工分任务）

7.1 为什么不能照搬

渔佳智脑的任务系统是按「商户营销外包」设计的：商户发任务 → 游客做任务 → 审核30% → 到店核销发70%。这套机制的内核假设是：

结论：神山秘境的任务系统必须以"行程叙事"为主线，而不是以"商户营销"为主线。

7.2 三层任务架构（v0.8.1：商户发起制）

┌──────────────────────────────────────────────────┐
│  线路打卡任务（商户发起，福钥主来源）                │
│  · 平台预置转山线路模板+地理围栏（L1 配置）          │
│  · 商户用任务福钥额度发布，系统自动判定，零人工审核    │
├──────────────────────────────────────────────────┤
│  消费凭证任务（商户发起，福钥补充来源）               │
│  · 到店扫码核销，无内容审核                         │
│  · 商户只确认"人到过、消费过"                       │
├──────────────────────────────────────────────────┤
│  内容分享任务（商户发起，可选，福钥增量来源）          │
│  · 种草/评价/打卡照片                              │
│  · 发布者自审；可选"平台代管"（K10 定案）            │
└──────────────────────────────────────────────────┘
        平台 = 基础设施（模板/围栏/核验/冻核销流水线）
        商户 = 唯一发起方（含自营，走 §3.11 同构入口）

v0.8.1 发起方定案（刘总）：福钥唯一来源=商户服务费赠品，平台不印福钥、不做任务发起方——"平台线路任务"设计废弃。平台提供任务系统基础设施（点位/围栏模板、GPS 核验、冻结/核销/销毁流水线），任何商户都可用自己的任务福钥额度发布线路打卡类任务；自营想发起，走同构商户身份同一入口，无特殊通道。

7.3 线路打卡任务（v0.8.1：商户发起制，核心创新）

这是神山秘境独有、渔佳智脑没有的任务类型。把"转山路线"本身拆成打卡任务，游客走完即得福钥，零人工审核。

平台与商户的分工：

线路模板任务清单（平台预置默认值，福钥数由发券商户在上限内自定）：

与工分任务的关键差异：

为什么模板归平台、发起归商户：转山线路的点位、围栏、海拔是公共地理信息，由平台作为 L1 站点配置统一维护（改一个点位不用每个商户改一遍）；但每一把奖励福钥都必须有服务费背书（§3.8 额度唯一来源铁律），所以发起和出资只能是商户。多家商户可发布同一模板的任务，游客按奖励多寡自主选择做哪家的——任务市场自然形成竞争。

7.4 商户层：消费凭证任务

商户发的任务砍掉内容审核，只保留"到店凭证"核验——商户只需确认游客真的到店消费过：

与工分任务的关键差异：

这一层直接复用现有 tasks_full.py 的到店核销链路，但把"内容审核"环节跳过：游客扫商户码 → 商户点确认 → 福钥立即到账。商户零负担。

7.5 内容分享任务（可选，v0.8.1：发布者自审）

种草/评价类任务审核权归发布者（K10 定案）——谁发任务谁审核，平台只有提醒义务、不强制处理：

审核机制（K10 定案口径）：

• 谁发任务谁审核——商户对自己发布的任务拥有审核控制权，平台不接管、不强制处理
• 平台只有提醒义务：待审核任务超时未处理时提醒发券商户（默认 48 小时，可配）
• 发布时可选项：商户发布任务时可勾选"同意平台自动控制"（超时自动通过或驳回），不勾选则完全自管

与工分任务的差异：审核从"平台统一队列"改为"发布者自审为原则"。原因：任务和奖励都是商户的，审核责任自然也归商户；平台做提醒者和可选的代管者，不做裁判。

7.6 平台的角色：基础设施，不出资、不发起（v0.8.1 整节重写，原"平台福钥池"废止）

v0.3-v0.8 曾设"平台福钥池"（从服务费收入划拨比例支撑平台线路任务）。v0.8.1 刘总三连问定案：福钥的唯一来源=商户服务费赠品，平台不得成为规则外的一方——

商户（含自营同构）交服务费 → 获赠福钥额度（唯一来源，§3.8 铁律）
    ↓
商户自主发布任务（线路打卡/消费凭证/内容分享/出发地曝光）
    ↓
平台提供：线路模板 + 围栏核验 + 冻核销流水线 + 记账对账
    ↓
平台不创设额度、不设资金池、不做任务发起方

为什么必须废止平台池：

• 平台给自己创设无服务费背书的额度 = 自己印钞——数学锁脱锚（Σ补贴≤80%×Σ服务费的前提是每把福钥都有服务费背书，白印的额度没有）
• 商户视角：商户交 5000 才有额度，平台不交钱就能发 = 裁判不守自己的规则（§3.11："既当裁判又当运动员"）
• 监管视角：无背书发行可抵扣凭证，正是预付卡/代币监管盯的形态

平台想推转山打卡怎么办——走 §3.11 自营同构：自营主体以普通商户身份同档缴纳服务费（集团内部记账划转，真金白银进服务费收入科目），获赠额度后与任何商户一样从模板发布任务。同一入口、同一规则、同一本账。

7.7 出发地曝光任务：商户出钱、平台得数据（v0.4 新增）

管理层决议中特别点出的机制：商户用福钥触发"出发地曝光任务"，平台本身也获得好处。

机制：

商户发布"出发地曝光任务"（消耗商户福钥额度，默认 2 把/次）
    ↓
游客参与：授权上报本次行程的出发地城市（一次性勾选，明示告知）
    ↓
游客获得福钥奖励
    ↓
平台沉淀客源画像：哪些城市在来神山、走什么线路、住几晚、买什么券

三方收益：

为什么平台必须拿到这个数据：

• 神山秘境的商户多为本地小商户，单家没有客源分析能力——平台聚合后的客源画像是"联合体的公共智慧"，反哺给商户（按等级开放不同粒度的报表）

【v0.9.2 批注】本行"反哺给商户（按等级开放不同粒度）"为 K14 定案前旧表述——K14 已定案：客源画像平台自用、不向商户开放（"按等级分粒度开放"建议已撤销）；且等级名目已废（§4.3）。以 K14 为最终口径。

• 客源数据是平台对商户的增量价值证明：商户花服务费买的不只是福钥，还有"知道客人从哪来"的能力——这是续费的理由
• 全域客源画像是对政府/景区/赞助商汇报的硬通货（马年转山旺季的游客来源结构）

隐私合规铁律：

• 出发地上报必须明示授权（单独勾选框+文案说明用途），不得默认勾选、不得与登录授权捆绑（《个人信息保护法》第 14 条：单独同意）
• 只采集城市级出发地（不采集精确位置、不采集身份证号），最小必要原则
• 游客可随时在"我的"页关闭授权并删除已上报记录
• 客源画像只向商户开放聚合统计（"本月成都客源占 23%"），永不开放个体级数据（"张三从成都来"）

与工分体系的差异：渔佳智脑没有这个机制——渔村客群是周边熟客，出发地信息无价值；神山客群来自全国，客源结构是稀缺的战略数据。

7.8 任务系统改造清单（相对现有代码）

复用不动的：credit_tasks/credit_task_claims/user_wallets/credit_journal 表结构、接单/提交证据/核销的基础链路。

八、与现有系统的衔接

8.1 管理端可配置参数（迁移 016 + 019 + 020 + 021 + 027）

所有商业参数落 system_settings 表，复用现有管理端接口 /api/miniapp/admin/settings（settings.py，管理员身份校验已具备），零新增接口。默认值由 backend/sql/016_key_system_settings.sql（福钥）、backend/sql/020_key_settlement.sql（跨商户补贴）、backend/sql/021_key_redeem_settlement.sql（补贴结算与落账，v0.6）、backend/sql/022_fund_model_cleanup.sql（资金模型收口：通缩废止，v0.7）、backend/sql/023_key_domain_tables.sql（福钥域五表+联合支付配置，v0.8.1）、backend/sql/024_deposit_abolish.sql（保证金机制废止，v0.9）、backend/sql/027_service_fee_tiers.sql（服务费档位定稿+周期折扣+创始商户活动，v0.9.1）落库，双库（生产 kailash / staging kailash_staging）均已执行。

福钥参数（016）：

福钥发放参数（019，v0.4 新增；v0.9 回扫）：

已废止参数（019 保证金五键，v0.9 废止，024 标注）：

跨商户结算参数（020，v0.5 新增）：

真实汇率参数（058，v0.10 引入 · 本批补登记）：

⚠️ 登记状态说明：三键由迁移 058_wip267_content_three_domains.sql（阿仁 · WIP-267）落库，staging 实测已在 system_settings 表（key_grant_real_ratio=0.8 / key_redeem_real_ratio=0.8 / key_face_value_display_fen=100），但此前未登记进本参数总表——v0.10 批注只改了正文口径，漏了 §8.1 回扫。本批补登记（波波，2026-09-12）。

另记一处编号撞号：backend/sql/ 下并存 058_seed_demo_support.sql 与 058_wip267_content_three_domains.sql 两个 058（违反 §2 铁律 3「只增编号迁移」的编号唯一性）；两文件均已入 staging schema_migrations、实际执行未受影响，但编号语义已乱，待派单清理（见待决区 K25）。

补贴结算与落账参数（021，v0.6 新增；v0.7 更名）：

档位定稿说明（027，v0.9.1）：

• 定档逻辑：内部测算锚=商户月平台相关流水 × 15%（刘总 2026-08-31 授权小齐定稿），贴测算下限定档——小微（流水锚 2,000~5,000 → 300~750）定 ¥300；标准（8,000~15,000 → 1,200~2,250）定 ¥1,200；大型（25,000+ → 3,750+）定 ¥3,800。贴下限=试点期低门槛换入驻率（§六灯塔策略）；档位 L2 可配，跑顺后管理端上调。
• 红线：15% 仅为内部测算锚，永不出现在协议/页面/发票/商户沟通中——商户看到的只有固定金额档位（按交易额百分比抽成=共同经营表征→旅行社证风险，§六红线+三价 §11.6）。
• 费率天花板=拉萨渠道抽成（商户参照系）：档位换算有效费率显著低于拉萨渠道抽成，商户签约有直观比较优势。

【v0.9.2 回扫批注】①档位命名去规模标签："小微/标准/大型"名称废止（商户平等公理），配置、页面与协议仅以金额标识额度规格（如 ¥300/¥1200/¥3800），不出现规模称谓；②数值效力降级：300/1200/3800 由"定稿"降为内部测算基准（流水×15% 推导、非实地调研，凭据不足之质疑成立），对外锁价冻结——待 K2 商务对接取得 3-5 家真实流水与拉萨渠道实价对标后回填报批，报批前不对商户报价；③商户自选档位：平台不审核流水（判流水=碰商户经营数据，与"不碰收银"红线同源），"贴测算下限定档"仅作内部测算参考，不构成给商户分档的依据；④年付 8 折挂起：service_fee_period_discount 年付档暂不启用（冷启动无人买年付=少收 2.4 个月费换 12 个月锁定不成立），季付 9 折保留；创始商户首期半价活动键保留（名额 20 户，成本上限 3.8 万一次性）。

参数联动关系：

服务费档位（key_service_fee_tiers）
   → 决定商户福钥额度（credit_budgets，唯一来源，§3.8）
   → 决定可发任务总量

任务默认奖励（key_task_default_reward）× 任务数
   → 不得超过商户额度（可发额度 = 剩余额度 − 待支付欠账 − 预留，K15 定案）

联合支付抽佣（key_redeem_commission_ratio / key_joint_pay_helper_ratio）
   → 按出资来源分账：本人部分 × 本人档 + 帮助者部分 × 帮助者档

调整权限：以上全部仅管理员（user_identities.identity_type='admin'）可改，商户只读。

8.2 数据库层

福钥部分——复用现有表 + v0.5 拆分：

v0.5 新增（跨商户结算，编号随 019 之后顺延）：

保证金部分——机制已废止（v0.9）：v0.4 设计的 merchant_deposits / deposit_ledger 两表随佣金保证金机制一并废除；两表在迁移 023 中误建（无任何代码引用），由迁移 024 DROP 清除，不再出现在数据模型中。商户间争议的欠账记录复用额度侧既有结构（credit_budgets 待支付欠账扣减 + credit_journal 裁决流水），不新增表。

出发地画像——需新增一张表（可并入下一个迁移）：

只改用户可见层：界面文案改成"福钥"，数据库字段名不动。

8.3 与商户工作台的衔接

商户工作台增加：

• 「福钥额度」面板：显示已购额度/已发放/剩余
• 「购买福钥」入口：选择服务费档位→支付→额度到账

> 【v0.9.2 批注】入口话术按 v0.7 定性必须为「交服务费获赠送额度」——福钥是赠品、不可买卖，"购买福钥"表述禁上页面；选择项=纯额度规格（金额标识，无规模标签）。

• 「福钥发放」双渠道：发布任务 / 直接发放（扫码赠送）
• 「推广任务」发布：设定福钥奖励数（含出发地曝光任务）
• 「福钥核销报表」：哪些游客用了福钥、抵扣了多少、补贴结算明细
• 「结算账单」（v0.6 三合一）：订单完成后自动生成，同屏展示三块——①协议价成本应付（酒店协议价 ¥200、车队协议价 ¥200…）②佣金应收应付（该付谁多少/该收谁多少）③福钥补贴行（核销面值×补贴比例=平台补贴本商户金额）。商户对账：线下支付/收到后点确认落账；约定周期过了（默认 7 天，可配置，六条②定案）自动确认落账
• 「欠账与争议」面板（v0.9 替换原"保证金"面板）：本商户待支付欠账/裁决记录/清偿期限/额度冻结状态；合作方欠账在身的风险提示
• 「福钥担保预警」（v0.6）：本商户作为应付方时福钥余额是否充足；合作方余额不足的实时提醒（§3.7）
• 「客源画像」报表（按商户等级开放不同粒度）

> 【v0.9.2 批注】本行废止：K14 已定案客源画像平台自用、不向商户开放；等级名目已废（§4.3）。工作台不上线该报表。

8.4 与小程序前端的衔接

• 游客余额页：显示"福钥串"（可视化）
• 任务页：显示"转山修行任务"
• 预约下单页：增加"使用福钥抵扣"选项（两类可叠加）+ 可选定金线下支付确认
• 订单详情页：展示订单二维码（到店出示，各履约商户扫码核销）
• 核销后：福钥销毁动画 + 已抵扣金额更新；取消/爽约→福钥解冻返还提示

8.5 与预售券系统的衔接

• 预售券预约下单流程中增加"福钥抵扣"步骤（v0.6：线上支付暂停，下单=预约登记+冻结福钥，非支付）
• 抵扣金额 = 福钥数 × 单把抵扣值（¥1）
• 福钥下单冻结、核销时销毁；核销流程不变（商户扫订单码）
• 抵扣记录关联到券订单（可追溯）；定金（如有）为线下直付+商户确认收款，平台零触碰

8.6 协同订单参与确认机制（v0.8 新增，刘总六条④定案）

组合/协同订单（游客一次预约多个商户服务，见《套餐产品与交易系统设计》）在订单生成时引入参与商户确认环节，与协议第 3.1 条"各参与商户均可在平台查看该订单并各自决定参与或退出"口径一致：

• 可见：订单生成后，各参与商户在商户工作台可见该订单及其涉及自己的部分（服务项、时段、协议价、佣金口径）；
• 可决定：各参与商户在订单生成后 24 小时内（与主商户接单时限一致，协议 3.2）在工作台确认参与或退出；
• 超时处理：超时未确认视为不参与；主商户可更换协作商户、调整组包或取消该服务项；
• 与结算衔接：确认参与的商户才进入该订单的三合一账单（§8.3）与佣金/福钥结算范围；「谁打包谁负责」口径不变（协议 4.8）；
• 数据落地：订单参与表记录各商户确认时间与动作，作为三合一账单分摊与争议仲裁（见《商户间结算与争议处理规则》）的证据留痕。

九、实施路径

⚠️ 前置条件：二期福钥抵扣与三期跨商户结算上线前，必须完成 §3.6.4 的专项法律审查（跨商户通用福钥是否构成多用途预付卡/支付工具）。

十、与渔佳智脑工分的差异对照

核心结论：结构同构，场景适配。不可照搬的部分是任务系统（一次性客群没有"回头核销"）、消耗频率、抵扣上限和发放控制权（福钥是商户的自主资源）。

十一、待决项

v0.3 起，K1-K5 已落为管理端可配置参数（迁移 016，默认值见 §8.1），不再是阻塞项。v0.4 管理层决议后新增 K11-K15，v0.5 两类福钥结算后新增 K16-K20，v0.6 刘总模拟订单拍板后新增 K21-K23。v0.8.1（2026-08-30 刘总定案）：K6-K20 全部关闭——8 项按口径定案、3 项伪问题删除（K13/K18/K20）、K19 随抵扣上限取消失效，唯一保留=K16 法律审查（审查口径随"上限取消+联合支付开放"更新）。

v0.6 已拍板（不再是待决）：

• 补贴结算点 = 核销时（两种福钥合并计算），平台留存比例默认 20% 可配置（话术为"补贴结算"，禁"抽佣"）
• 福钥担保 = 预警式（不设固定阈值/扣划数值，每笔订单实时提醒双方），全程不变现
• 福钥销毁时点 = 下单冻结、核销销毁、取消/爽约解冻返还
• 定金 = 线下直付商户 + 商户后台确认收款（保留定金，平台零触碰）
• 结算落账 = 商户线下支付/收到后点确认，或约定周期过了自动确认（默认 7 天可配，v0.8 回扫）
• 命名 = 福钥（数据库字段名不动）

遗留待决（v0.8.1 已全部关闭，刘总 2026-08-30 定案）：

v0.4 新增待决（保证金与数据侧；v0.8.1 关闭，v0.9 随保证金废止重标）：

v0.5 新增待决（两类福钥结算侧，v0.8.1 已全部关闭）：

v0.6 新增待决（补贴结算与落账侧）：

【v0.9.2 批注】K21 行"跑顺后可按等级评估激励调档"的"等级"名目已废（§4.3）：一期统一留存 20% 的定案不变；未来如需差异化激励，按行为数据（核销量/履约信用）在规则层体现，不立商户等级名目。

v0.11 新增待决（2026-09-12，波波 · 汇率参数治理批）：

附：本方案未改动的部分

• 《三价体系与组包责任边界》全部结论（合规分档/招徕判据/分项标价）
• 《合规方案-卖券模式》全部结论（卖券不卖服务/不需旅行社证）
• 《商户工作台设计方案》的资金流/结算/防漏记机制
• 《分销系统》的归因模型/佣金资金流
• 现有积分表结构（全部复用；配置默认值迁移 016/019/020/021）

本文只新增福钥概念重定义（平台赠送的补贴凭证，v0.7）、流转链路、抵扣规则、服务费单轨盈利模型（v0.9 终版）、核销补贴结算与结算账单（§3.5/§3.6/§3.8/§8.3）、商户双约束机制（含福钥余额担保预警 §3.7）、争议与票据口径（§3.2/§3.9/§3.10，v0.9 额度侧执行）、任务系统设计（§七，含出发地曝光任务）、管理端可配置参数（§8.1）、两类福钥与跨商户补贴（§3.6），不动任何既有方案。

⚠️ 跨文档口径回扫结论（v0.9 终局）：

1. 《分销系统v2-方案B对齐.md》§「不设佣金保障金：平台不付佣金，故无垫付义务」——该条款自始正确、恢复有效：v0.4 管理层决议曾标注"推翻"，v0.9 刘总撤销保证金机制后，该条款即为本平台最终口径，作为实施依据。
2. 《合规方案-卖券模式》§"商户跑路"风险行建议"接入保险或保证金机制"——保证金路径已废止，该风险行的应对以保险路径（《高原安全保障与保险方案》）为准。