feat: add practical mainland payment knowledge base

skills/fxskill/SKILL.md

@@ -30,13 +30,44 @@ description: Use when 建站新手需要规划、设计、建站、上线、支
 | 商业目标/网站类型/建站方式/Vibe Coding/CMS/技术路线 | `references/roadmap.md` |
 | 设计/配色/字体/页面结构/内容/转化/灵感 | `references/design-resources.md` |
 | 域名/DNS/邮箱/服务器/CDN/网站发布/部署 | `references/stack-hosting.md` |
-| 国内外支付/主体/订阅/备案/隐私/Cookie/条款/版权/无障碍 | `references/payment-compliance.md` |
+| 国内外支付/收款/支付主体/订阅/费用/结算/支付平台比较 | `references/payment-index.md` |
+| 备案/隐私/Cookie/条款/版权/无障碍/一般合规 | `references/payment-compliance.md` |
 | 功能/兼容/移动/支付流程/安全/备份/性能 | `references/testing-quality.md` |
 | SEO/收录/GEO/AI 引用/流量/统计/转化追踪 | `references/growth-seo-geo.md` |
 | 上线检查/监控/维护/故障诊断 | `references/operations.md` |
 
 用户可用 `$fxskill 支付: ...`、`$fxskill 设计: ...`、`$fxskill 服务器: ...`、`$fxskill SEO: ...`、`$fxskill GEO: ...` 直达。若用户口语里说“托管”，统一按“服务器”或“不需要自己维护服务器的网站发布平台”理解。仍要读取上下文并诊断，不冷列资源。
 
+支付问题先读 `references/payment-index.md`；按索引只读一个相关场景和只读一个相关类别或平台档案。不得一次倾倒全部支付档案。只有共享主体判断、地区判断、备案、隐私、条款、订阅法律判断，或规范支付档案未替代的合规问题，才补读 `references/payment-compliance.md`。缺失的海外档案不存在时，用 `payment-compliance.md` 的海外框架并按 `references/source-policy.md` 核验当前官方来源，不得假装已有档案。
+
+### 支付答案配方
+
+**原则**：资料库深、回答浅。支付答案配方优先于全局语义输出契约；档案保留完整字段，成品只讲清用户这次怎么选。支付首句可以直接描述主路线或不选某个平台，描述性结论不计入行动；真正命令用户执行的操作只放在最后步骤区，最多三条。
+用户判断顺序固定为：`能不能申请 -> 需要准备 -> 怎么收费 -> 多久能到账 -> 会员和自动续费 -> 接入难度 -> 最容易踩的坑`。只选这次会改变决定的 2-4 项回答。运营主体、合同主体和资金路径只作为内部核验字段；仅当异常已经影响申请、收款、结算或售后追责时，才用一句白话提醒用户。
+1. **选资料**：先按卖家主体 + 支付模式匹配场景标题；主体与支付模式场景优先于产品形式场景。自然人首单问题固定使用 `中国大陆自然人验证首批订单`，行动顺序为“提交资料 → 支持且费用、结算可接受时签约 → 后台明确不支持且允许个体工商户时登记个体工商户”；支付回调、验签等技术接入留到下一轮。内容托管场景至多进入一个有条件备选槽。
+2. **先下结论**：先给一句明确结论，说明当前最可行路线、能不能用或为什么暂不能判断；不能只说需要核验，也不强制固定标题。
+3. **补关键信息**：
+   - 再给 2-4 条真正影响选择的信息；托管内容平台能否替代网站支付 API 时，只保留 API 能力、主要费用、主体与内容边界、结算或退款限制。
+   - 优先能否申请、所需材料、费用、到账、续费能力、接入难度或最大坑；不默认输出完整成本卡或条件卡。
+   - 未公开的费用合并为一句说明，不能为了完整把所有未知标签念一遍。
+   - 保留来源边界，区分官方事实、平台自述、实践证据和待核验项；平台页面声称的通道费不得写成支付机构官方统一费率；当前费率、资格或状态必须简短标明核验日期。平台比较必须用“截至 YYYY-MM-DD”标明核验日期。
+4. **给步骤**：
+   - 最后给最多三个按顺序的原子步骤。
+   - 每一步只放一个主要动作，按依赖顺序排列，总步骤不超过三条。
+   - 结论不要塞进行动项；依赖前一步结果时用简短条件句说明。
+   - 真实订单验证只保留一个验收动作，不展开回调、查单、验签或幂等子动作。真实订单验证写明“仅当上一项配置完成时”。
+5. **守住推荐边界**：
+   - 不得把 `仅作线索` 平台写成稳定主支付、最便宜或最好；规范场景明确为核验路线时可以作为第一个官方核验入口，正式使用仍以后台或签约结果为条件。
+   - 被比较候选全部是 `仅作线索` 时，明确它们不作为主支付，不得再挑其中一个作备选或排序，回到规范场景的可防守路线；回到规范场景时称为官方核验入口，不得称为已成立主支付。平台比较的四条关键信息依次为：当前可注册性、主体或类目、主要费用、资金或结算路径；比较答案必须按四条短信息输出，四项都出现，不合并省略。比较事实只描述当前证据，不写需要用户核验或确认的操作。结论写成“候选都不作为主支付；当前先走规范场景的官方核验入口”。
+   - 成本未知或比较维度不一致时，明确说明价格排名尚未成立；价格证据不足时不得判定最便宜；固定费用或关键费用未公开时，不得使用“低固定成本”“最省固定成本”。自然人场景固定费用未知时，只能称为“当前可行的官方核验入口”，不得称“低成本候选”。
+6. **按需展开**：
+   - 只有用户明确要求完整费用拆解或严谨对比时才展开。
+   - 同类候选按相同且会改变决定的维度比较。
+   - 用户点名问平台当前费用时，平台费与平台自述通道费分开写，当句说明后者不是支付机构官方统一费率，再写结算周期或到账口径、最低结算额或提现费是否公开；已公开的结算口径不得省略。未知项最多点名两项，其余统一写“其他费用未公开”，不继续枚举标签。
+   - 平台费率已按套餐列出时，不再逐档换算单笔金额；用户点名某一套餐时才换算该档。
+   - 即使展开，也不得用缺项拼总价，不得把已知费用相加成完整到手成本，不得计算套餐销量分界或总成本。
+默认正文不超过 450 个中文字符；复杂问题等用户追问再继续。
+
 SEO/GEO 共用搜索和 AI 可见性专题：先共享基础，再按收录/排名点击或 AI 理解/提及/引用分流。
 
 ## 判断标准
@@ -59,14 +90,14 @@ SEO/GEO 共用搜索和 AI 可见性专题：先共享基础，再按收录/排
 
 直接专题的默认正文不超过 450 个中文字符，URL 不计；只有用户明确要求完整比较或清单时才展开。
 
-直接专题给出正向建议时采用以下全局语义输出契约，标题可按专题自然命名；专题参考另有固定结构时，以专题参考为准：
+直接专题给出正向建议时采用以下全局语义输出契约，标题可按专题自然命名；支付专题以“支付答案配方”为准，其他专题参考另有固定结构时以专题参考为准：
 
 1. 一个纯描述诊断区：用一两句说明已成立事实、当前限制、资格未确认状态，或当前最大问题及影响。
 2. 一个唯一行动区：至多三个独立原子行动。
 
 - 诊断区不描述未来路线、方案或替代路径，不出现命令、建议或禁令，也不以“登记、核验、选择、申请、提交、办理、采用”等动作名词暗示建议。解释当前优先级时，只写现有证据、成本、能力或限制及其当前影响；不得命名未选路线，也不得用“先按原型”“转向 MVP”“加入某功能后路线会变化”“满足某条件时优先级会改变”等条件句放入未来阶段或决策分支。依据、风险、坑和来源说明如需出现，保持纯描述并归入诊断区，或按专题参考的固定结构输出。
 - 只有行动区可出现命令、建议或禁令；行动区可按专题题为“下一步”“核心修改”等自然标题，不强制所有专题使用“现状”或“下一步”。
-- 每个行动必须独立成项且只有一个主要谓语动作，不使用“并、再、同时、以及、；”连接额外操作；按语义而非编号计数。每一个登记、核验、选择或申请均是独立动作；向不同平台提交分别计数。
+- 每个行动必须独立成项且只有一个主要谓语动作，不使用“并、和、再、同时、以及、；”连接额外操作；按语义而非编号计数。每一个登记、核验、选择或申请均是独立动作；向不同平台提交分别计数。
 - 行动项可以附带不含命令的适用条件、成本、限制或坑说明。对前一行动结果的条件限定不算新增动作，例如“仅当上一项核验结果支持此路线时”；不得在条件短语中藏入新的确认、选择、申请或其他操作。
 - 备选若出现，必须作为行动区中的独立原子行动，并占一个行动名额。
 - 不用合并编号、嵌套清单、拆分章节或条件分支绕过三项行动限制。超过三个动作时，按依赖顺序只保留前三个，不得总结或合并后续动作。来源链接和纯描述内容不算行动，但不得扩成长清单。