2026 年 10 月 20 日 · 产品机制评审
让猫自然出门，
也让陪伴值得继续。
次数目标可以实现。当前瓶颈是出门机会太依赖“连续不理猫”；建议把出门改为独立累计陪伴时间，再用周期计划安排次数与礼物。
当前行为来自本次本地源码评审；图中次数与建议参数尚未实施。线上实际规则与留存效果未在本次验证。
评审结论：保留图中的总量目标，先调整触发条件与首次体验。单独提高礼物概率，无法解决“猫始终不出门”。
现在怎样触发，建议怎样调整
| 对比项 | 当前源码行为 | 建议方案 · 尚未实施 |
|---|---|---|
| 出门入口 | 完成两轮未回应的找人流程后，才向服务端申请出门。 | 独立累计有效陪伴时间，到自然动作边界申请出门；未回应找人可保留为一种出门情境。 |
| 频繁互动 | 点击、拖动等互动清除忽略次数；悬停也会重置找人计时。喜欢互动的用户，也可能长期凑不齐条件。 | 摸猫、喂猫和玩耍不清零出门进度；正在互动时顺延出发。 |
| 人离开电脑 | 在场检查未通过时，正式云端链路不会从“无人”分支直接出门。 | 已累计进度保留；锁屏、休眠与隐藏不计入新陪伴时间，恢复正常使用后再安排。 |
| 出门频率 | 符合条件后，再由服务端按 Standard 15% / Max 30% 判断是否出门。 | 服务端保存周期总量与分周计划；合适窗口内兑现机会，不再叠加旧的低概率抽签。 |
| 礼物数量 | 默认每次返程按 Standard 8% / Max 12% 判断礼物。 | 先确定周期礼物总数，再分配到具体出门；如要承诺最低数量，必须有保底。 |
| 关闭客户端 | 已开始的云端出门有持久化返程期限；重新打开时恢复并结算。 | 复用这条链路。出门后无需继续挂机；尚未开始的出门不按离线时长补跑。 |
| 共同边界 | Starter 禁止出门；服务端验证订阅权益、深夜、冷却及已有出门。 | 保留 Starter 禁止出门、深夜禁出发、返程后 2 小时冷却、单猫单次在途；新增正式试用权益。 |
首次抽到出门前，等待已经很长
默认每轮间隔 40 分钟，需完成两轮未回应找人。这只是无互动、两轮都顺利触发的理想估算，还未计入动作、自然醒与时段跳过。
出门 8 次，也可能没有一个礼物
按旧概率、每次独立抽取的近似模型：零礼物概率为 0.92⁸ / 0.88⁸。属于数学示意，不是线上用户统计；“每周至少一个”不能只靠概率。
图片中的次数目标，可以保留
以下忠实整理用户提供的候选表；不是当前已生效的产品权益。
| 用户阶段 / 套餐 | 周期 | 每 7 天出门 | 连续 4 周出门 | 每 7 天礼物 | 连续 4 周礼物 |
|---|---|---|---|---|---|
| Starter | 任意 | 0 次 | 0 次 | 0 个 | 0 个 |
| 试用 Standard | 免费 7 天 | 固定 2 次 | — | 固定 1 个 | — |
| 试用 Max | 免费 7 天 | 随机 2–3 次 | — | 随机 1–2 个 | — |
| Standard 订阅 | 付费后 | 2–3 次 | 随机 8–9 次 | 1–2 个 | 4–5 个 |
| Max 订阅 | 付费后 | 2–3 次 | 随机 8–10 次 | 1–2 个 | 4–6 个 |
要同时满足周边界与四周总量，应先抽周期总数，再分配到各周；额外次数落在哪周也应随机。每次出门至多一个礼物，周礼物数不得超过该周出门数。
四周如何分配：一个合法示例
示意计划，不是真实账号数据。随机的是合法总量、周分布与时点，不能每次重开客户端重新抽取。
先让用户体验到一次完整的出门
累计陪伴
首次累计 30–60 分钟作为候选起点，可分多次打开累计。互动不重置进度。
自然出发
避开正在进行的互动、深夜与冷却，到合适动作边界再由服务端确认出门。
按期返程
复用服务端 20–60 分钟返程期限。用户可以关闭客户端，回来后恢复结果。
看见惊喜
建议试用首趟带回礼物，让新用户尽早体验完整链路；后续按周期安排。
“有效陪伴”至少区分正常使用、主动隐藏、锁屏/休眠与完全离线；具体在场判定和累计阈值需在实施合同中冻结。没有使用机会时，不能无条件保证实际出门次数。
实现需要改哪里，怎样验证
客户端：把出门进度与找人计时分开
- 累计进度持久化，短会话、重开与互动不清零。
- 统一隐藏、锁屏、休眠和动作边界的处理。
- 新增出门触发原因，贯通渲染层、IPC、持久化请求和接口。
- 只在服务端确认后进入出门状态。
服务端：计划、权益和结果统一保存
- 保存试用/付费周期及次数计划，重试不重抽。
- 分配时同时约束周总量、四周总量和礼物数量。
- 多设备不重复消耗机会，同一次出门不重复发礼物。
- 礼物生成或交付失败时保留重试与明确恢复路径。
验收要覆盖真实使用方式
至少验证：每天开 20–30 分钟、工作时频繁互动、出门后关闭再打开，以及多设备并发。先做可复现的计划与状态测试，再做真实客户端验收。记录首次出门耗时、首次看见礼物耗时、返程前关闭比例与七日留存；目前没有数据证明新机制会提高留存。
实施前需要明确的四个边界
次数是保证交付，还是正常使用下的目标？
若承诺固定次数，要定义最低使用条件和机会顺延规则。完全不开客户端时，不应制造“实际已出门”的记录；重开也不集中补跑。
四周按 28 天，还是跟订阅自然月走？
图中按连续四个 7 天分配；月订阅周期未必等于 28 天。试用转付费、续费和到期时的计划衔接需统一口径。
试用多久第一次出门、第一次带礼物？
建议首次累计 30–60 分钟，试用首趟带礼物；需要验证短会话也可触达，并明确试用起点和领取资格。
Max 的差异是否足够明显？
图中两档每周出门都为 2–3 次，Max 主要增加四周上限与礼物数。是否还要通过内容丰富度体现差异，应单独决定，避免仅靠更频繁打断用户。
证据与口径说明
- 用户提供的套餐次数截图：本页“次数目标”表的来源。保留原始上下限；不代表已上线权益。
StateEngine.ts：点击重置计时与忽略次数（约 257 行）；完成两轮未回应找人后申请（约 1062 行）；正式云端无人分支不直接出门（约 1171 行）。petRuntimeConfig.ts：默认找人间隔 40 分钟，出门时长 20–60 分钟，返程后冷却 2 小时。main/index.ts：用户在场检查使用系统空闲时间与系统可用状态。companion-service.ts：服务端检查月订阅、深夜、两轮完成、已有出门、冷却与概率；保存返程期限并支持到期恢复。gift-domain.ts：默认 Standard 出门/礼物 15%/8%，Max 30%/12%。docs/product-contract.md与20260905-gift-subscription-outing/requirements-contract.md：云端权威、持久化返程与幂等边界。源码本地存在未提交改动，因此本页不将 HEAD 视为完整源码快照，也不推断已安装版本或线上状态。- 零礼物估算：P(0) = (1 − p)⁸；Standard 约 51.3%，Max 约 36.0%。只展示独立抽取近似模型，不作为实测概率或留存结论。