文旅与民宿行业经营合规 · 文旅民宿合规罗盘（付费版 · 模式乙）
这是什么
文旅民宿合规罗盘是一位专注中小文旅与民宿经营体的经营合规顾问。它把公安、文旅、消防、卫健、市场监管、税务数个口子的合规要求，收口成一张经营体能看懂、能执行、能迎检的风险清单。
本技能为按次付费技能：每次完整合规体检调用 2.99 元，首次使用会请你绑定支付宝钱包，之后每次自动扣费（费用仅用于本次合规核查服务）。
模式说明（请务必理解）：本包只负责"收集信息 + 提交核查请求"，真正的判定逻辑运行在后端纯规则引擎，不依赖大模型、不产生额外成本。你提交结构化输入后，后端返回本企业的分级风险结论与整改路线。
付费流程（402 协议）
- 你按下方"要收集的信息"把经营情况整理好，调用
scripts/skillpay.py（或本地助手发起付费请求）。 - 请求会先收到
402 Payment-Needed与本次商品名、金额（2.99 元）。 - 你完成支付后，系统用支付凭证回传，后端纯规则引擎据此生成本经营体专属结论。
- 结论包含：十模块评分、分级风险清单（🔴 已违法/随时可罚、🟠 高概率被罚、🟡 隐患）、Top3 优先风险、30/60/90 天整改路线。
> 支付失败或未完成时，不会生成任何结论，也不会留存你的经营数据。
支付宝付费改造验收实现（服务端技术契约）
本技能服务端已实现完整的支付宝 AI 按量付费（402）改造，覆盖从账单下发到履约确认的闭环：
| 环节 | 实现说明 |
|---|---|
| 402 账单下发 | 服务端未收到凭证时返回 402 + Payment-Needed（含 seller_id / service_id / 商品名 / 金额 2.99 元 / 有效期） |
| 携带凭证重试 | 支付完成后带 Payment-Proof 以原参数（含结构化输入）重试资源请求 |
| 验签确认（payment.verify） | 服务端调用支付宝 OpenAPI 做 payment.verify 验签，校验凭证签名真实性与订单金额一致性，验签通过才放行 |
| 规则计算 | 服务端按结构化输入用纯规则引擎算出本案例结论（十模块评分 / 分级风险清单 / Top3 / 30-60-90 路线），不调用任何大模型、零边际成本 |
| 履约确认（fulfillment.confirm） | 结论生成并交付后，服务端回传 fulfillment.confirm 履约确认回执（ack），标记订单为已履约 |
| 订单持久化 | 每次请求写入订单记录（订单号 / 商品 / 金额 / 状态：待支付→已支付→已履约），落本地订单文件 |
| 重复凭证去重与幂等 | 同一 Payment-Proof 仅处理一次；重复回传直接返回已生成结论，未过期订单复用、已交付订单直接复用，杜绝重复扣费 |
> 受限环境如实披露：若运行环境缺少 Python 或官方支付 CLI 导致流程不可用，如实告知用户失败原因与错误信息，并给出解决路径（安装 Python、执行 npx -y @alipay/agent-payment@latest install 后重试）；不隐瞒失败原因、不伪装成功。
要收集的信息（提交前必须问清的 8 项）
- 业态（民宿 / 客栈 / 精品酒店 / 乡村文旅 / 农家乐 / 旅行社 / 定制游 / 康养研学住宿）
- 所在城市与区县（城乡民宿许可口径差异极大，城市与乡村不同）
- 房间数、床位数与营业规模
- 是否持特种行业许可证及状态（有效 / 临期 / 未办）
- 是否提供餐饮、是否有泳池或特种设备（电梯 / 锅炉）
- 是否经营旅行社业务（组团 / 招徕 / 接待）及许可状态
- 主要销售渠道（直订 / OTA 平台及占比）
- 近 12 个月是否被公安、文旅、市场监管、消防、卫健稽核或处罚、投诉
Red-Flag 提问清单（逐条问，用户答"有/无/不确定"）
> 每条都对应后端的一个判定口径。请就经营实际情况逐条确认，仅标记为"有"的项会进入风险计算。
模块一 · 证照与资质
- m1_no_special_license：是否无旅馆业《特种行业许可证》实质经营住宿（以"民宿/共享住宅"之名接待过夜旅客）？
- m1_sanitary_expired：公共场所《卫生许可证》是否过期或未办仍营业？
- m1_food_without_license：提供餐饮/早餐/售卖预包装食品是否无《食品经营许可证》？
- m1_travel_agency_no_license：以营利为目的招徕、组织游客是否无《旅行社业务经营许可证》？
- m1_special_equipment_no_reg：电梯、锅炉等特种设备是否未登记检验或超期使用？
- m1_business_scope_missing：营业执照经营范围是否不含"住宿服务/旅馆业"等相关表述？
模块二 · 场所与消防安全
- m2_no_fire_acceptance：建筑是否未经消防设计审查/验收或备案抽查即开业（自建房、老宅改造民宿高发）？
- m2_channel_blocked：疏散通道是否堵塞、无应急照明或疏散指示缺失？
- m2_pool_no_lifeguard：泳池是否无救生员/警示/水质检测（如有泳池）？
- m2_special_equipment_unsafe：特种设备（电梯/锅炉）是否超期未检验仍使用？
- m2_no_evac_plan：是否无应急疏散预案与演练（建议至少每半年一次）？
- m2_rural_wood_fire：乡村民宿木结构是否耐火不足、明火/大功率电器管控缺失？
模块三 · 价格与广告
- m3_false_listing：是否存在虚假房源/图文与实景严重不符（虚构位置、设施、面积）？
- m3_price_fraud：是否存在价格欺诈（虚构原价、低价引流到店加价）？
- m3_brush_orders：是否刷单刷好评（自买自评、诱导好评）？
- m3_absolute_term：是否使用"最佳/第一/顶级"等绝对化用语？
- m3_misleading_desc：是否有引人误解的服务描述、隐瞒限制条件（如不含早餐、限时未明示）？
模块四 · 消费者权益与合同
- m4_norefund_rule：退改规则是否不公示或与平台标注不一致、单方苛刻条款？
- m4_prepay_noncompliant：会员储值/预付卡是否无合规设计（资金池风险）？
- m4_risk_not_disclosed：泳池、楼梯、玻璃等设施安全风险是否未充分告知与警示？
- m4_no_public_liability：是否未投保公众责任险，游客人身财产损害全额自担？
- m4_no_complaint：是否无投诉受理入口与闭环处理台账？
- m4_unfair_terms：是否使用不公平格式条款（单方免责、限制消费者权利）？
模块五 · 劳动用工
- m5_no_contract：管家/前台/保洁等自有员工是否不签书面劳动合同？
- m5_temp_no_insurance：季节性临时工/兼职是否未签协议且未购工伤/意外险？
- m5_guide_no_license：导游是否无证或私自揽客（涉旅行社业务违规）？
- m5_social_missing：社保是否未全员、按实际工资参保？
- m5_peak_no_schedule：旺季是否无合规排班、超时用工无休息记录？
- m5_intern_boundary：实习生/兼职边界是否不清，误当正式用工或反之漏保？
模块六 · 财税与发票
- m6_private_account：营业款是否进个人账户/个人码不入账（私户收款、老板个人卡收付款）？
- m6_platform_inconsistent：平台结算流水与税务申报数据是否不一致？
- m6_fake_invoice：发票是否不合规或虚开发票（该开不开、为他人虚开）？
- m6_prepay_confused：预付储值收入确认是否混乱（会员卡收入错位）？
- m6_books_inconsistent：账实是否不一致、多店/多渠道收入未统一核算？
模块七 · 数据与旅客隐私
- m7_no_checkin：入住是否不登记/漏登/代登，未实时上传公安系统？
- m7_no_consent：收集身份证/人脸/联系方式/行踪是否未告知目的与留存期？
- m7_face_no_boundary：人脸/监控是否无边界（覆盖私密区域、超范围采集）？
- m7_leak_abuse：旅客信息是否泄露、买卖或滥用（员工倒卖、外发）？
- m7_over_retention：信息保存是否超必要期限不删除/不匿名化？
- m7_no_access_control：是否无旅客信息访问审批与调阅记录、员工未签保密义务？
模块八 · 民宿特行许可与住宿资质专项
- m8_no_special_license：是否无特行证实质经营住宿（只要接待过夜即落入旅馆业监管）？
- m8_fire_not_linked：消防与特行证是否未联动，场所不合规导致特行证办不下？
- m8_sanitary_missing：卫生许可是否过期或未办（客房与公共用品消毒无依据）？
- m8_food_missing：提供餐饮是否无食品经营许可？
- m8_urban_rural_confused：城乡民宿许可口径是否混淆（误用城市或乡村标准导致漏办/错办）？
模块九 · 旅行社业务与旅游法专项
- m9_no_license：是否无证经营旅行社业务（组团/招徕/接待）？
- m9_deposit_not_paid：是否未缴/不足额缴旅游服务质量保证金？
- m9_no_contract：是否不与游客签旅游合同或使用违规版本？
- m9_force_shopping：是否甩团、强迫购物、擅自变更行程/加点？
- m9_no_safety_plan：旅游安全事故是否无应急预案（食物中毒/交通/走失）？
模块十 · OTA 平台规则与经营实务专项
- m10_false_listing：是否虚假房源/盗图（图片与实景不符、盗用他人图）？
- m10_brush_orders：是否刷单刷好评、返现诱导好评？
- m10_refund_inconsistent：退改政策设置与平台公示是否不一致、单方违约？
- m10_review_violation：点评回复是否违规（辱骂、泄露客人隐私）？
- m10_grade_fake：民宿等级/钻级评定材料是否造假？
提交契约（--input）
把 8 项画像 + 上述 red-flag 的"有/无/不确定"答案，组装成如下 JSON，作为 --input 提交：
{
"business_format": "民宿+客栈+乡村文旅",
"location": "某市某区",
"scale": "18 间房，36 床位",
"special_permit": "无特行证",
"catering": "提供早餐，无泳池无电梯",
"travel_agency": "兼做周边一日游组团，无旅行社许可证",
"sales_channels": "携程/美团/直订，OTA 占 7 成",
"past_year_status": "近一年一次消防检查限期整改已完",
"flags": {
"m1_no_special_license": "yes",
"m7_no_checkin": "yes",
"m3_false_listing": "yes",
"m6_private_account": "no",
"m9_force_shopping": "no",
"m2_channel_blocked": "yes",
"m8_urban_rural_confused": "na"
}
}
> 仅 flags 中值为 "yes" 的项计入风险；其余填 "no" 或 "na" 即可。必填：business_format、location。
后端返回说明（付费成功后）
后端纯规则引擎会返回结构化的本经营体结论，包含：
- 十模块评分（0–5，5=合规闭环，0=完全缺失）与每模块最高风险项；
- 分级风险清单：🔴 已违法/随时可罚、🟠 高概率被罚、🟡 隐患，每条标注风险后果类别、整改动作、建议时限；
- Top3 优先风险：命根子（无特行证实质经营住宿、卫生/食品许可缺失、旅行社无证、虚假房源/刷单、私户收款、入住不登记、旅客信息泄露、强迫购物、OTA 虚假房源等）优先暴露；
- 30/60/90 天整改路线：按"零成本立刻改 / 小成本一个月 / 需投入三个月"分层，每项写清责任岗位与留痕要求。
数据与隐私披露
- 你提交的字段仅为本次合规核查的输入元数据（业态、所在地、住宿/用工/渠道画像等结构化标签）与你对 red-flag 的判断（"有/无"），用于生成本次结论。
- 数据随本次付费请求提交至后端纯规则引擎，仅用于生成本次结论，不用于训练、不留存画像、不向第三方提供。
- 支付由支付宝官方通道完成，本技能不接触你的支付密码与账户明细。
- 涉及重大无证经营、群体游客伤害、平台清退、刑事风险，结论会提示转执业律师/专业机构，不做法律意见替代。
免责声明
本技能输出为合规管理参考，不构成法律意见，不替代执业律师、税务师出具的专业结论。涉及重大行政处罚、旅行社业务认定、群体性纠纷、刑事风险，应转专业机构处理。地方口径（城乡民宿管理办法、旅行社业务认定、特种行业许可、消防审批）以属地公安、文旅、市场监管、住建/消防、卫健部门现行规定为准。
调用示例
python scripts/skillpay.py --input '{"business_format":"民宿+客栈","location":"某市某区","flags":{"m1_no_special_license":"yes","m7_no_checkin":"yes","m3_false_listing":"yes","m6_private_account":"no"}}'
