Kriki Coach 上市计划

首发产品与用户

当前方向已经形成，真正需要在发布前确认的是首发范围、首发场景和公开承诺。

当前最合理的上市方向是：

发布前还要定什么

• 跑步、睡眠或日常活动中，哪一个作为首发样板。
• 首发能力范围、公开承诺，以及是否在首发时收费。
• 美国首发的地区、支付、法务和运营范围。

这些事项分别在后面的品牌、收费、上线准备和分工主题里完成；产品与用户是否成立，则按“产品验证及用户增长”的前两阶段验证。

产品方向

Kriki Coach 是什么

Kriki 是把每一位用户当作唯一学员的个人 AI Coach。它位于 Apple Health 与穿戴设备之上，承担从数据到行动的健康决策与计划层：

身体与生活信息
  → 状态与问题判断
  → 长期方向和本周重点
  → 今日具体方案
  → 用户接受、修改或拒绝
  → 真实执行与结算
  → 日终、次日或周期验证
  → 更新对同一个人的理解

产品必须走完：

洞察 → 方案 → 协商 → 执行 → 验证 → 学习

缺少“正式方案、变化后重排、真实执行或后续验证”中的任何一层，都只能证明局部能力，不能证明 Kriki 的完整价值。

Kriki 承担什么，用户保留什么

拒绝、修改、未完成或中断计划都不能成为负面标签，也不能通过羞耻、连续打卡惩罚或焦虑刺激迫使用户服从。

已确认的产品原则

• 计划必须有明确版本；改变安排后要形成新版本并读回，不能只在对话里“说改了”。
• 真实执行才可以结算；推测、打开页面、点击卡片或发出提醒都不等于完成。
• 单次行为或短期波动不能证明健康因果。
• 判断必须区分测量事实、确定性结果、Agent 推断、不确定性和医学边界。
• 安全优先于目标、完成率、订阅权益、表达偏好和使用便利。
• 用户自己的事实、历史、导出和删除权不以有效订阅为前提。
• Demo、模拟数值、页面文案、Prompt 或临时对象不能反向成为生产规则。

首发明确不做

• 独立 watchOS App。
• Android、iPadOS、macOS 和 Web 客户端。
• 医疗诊断、治疗、急救替代或疾病管理承诺。
• 专业竞技训练服务。
• 未经证据支持的营养处方、身体改善结果或 Age 逆转承诺。
• Fitbeing 数据正式接入和 Google Health / Fitbit 生态扩展。
• Pro / Future 多目标、多设备和更长周期服务。
• 因为 Demo 已经展示就默认纳入首发的功能。

先在哪发布，服务谁

先在哪发布

计划先在美国发布。当前方案已经围绕美国 iPhone / Apple Watch 用户组织首发，但国家、地区、可服务用户、支持范围、支付、法务和运营范围仍需正式确认。

对应工作原则：

• 面向用户的官网、App Store、产品内容、合作材料和体验沟通，使用目标用户能理解的表达，并与首发地区适配。
• 中国价格和中文品牌材料仍可用于内部推导，不自动成为美国上市方案。
• 美国首发必须单独确认隐私政策、年龄、健康声明、税务、订阅和支持安排。

先服务谁

首发核心用户：已经拥有 Apple Watch，会查看 Apple Health、活动圆环或第三方健康数据，日常保持一定活动，但仍需要自己决定今天该训练、恢复还是调整安排的美国 iPhone 用户。

筛选信号：

• 最近持续佩戴 Apple Watch，并存在可用 Apple Health 历史。
• 会看睡眠、心率、活动或训练数据，但仍会犹豫今天怎么做。
• 不是精英运动员，也不是以疾病诊疗为核心诉求。
• 工作、出行、疲劳、疼痛或偏好经常打断理想计划。
• 愿意尝试由 Coach 形成安排，但要求保留最终决定权。

首发之外怎么进入

更广人群、Fitbeing 和 Android 生态不进入首发范围。它们各自为什么做、什么时候做、怎样判断是否成立，统一见“产品验证及用户增长”。完全没有穿戴数据的人属于另一项产品假设，不与更广人群一起验证。

首发体验必须做到什么

1. 早晨打开 Kriki，系统说明当前数据状态和今天的身体判断。
2. 用户看到一份能直接执行的今日方案，而不是只有一个分数或一句建议。
3. 方案能说明最核心的取舍：今天为什么这样安排、做到哪里就够、什么情况要停。
4. 工作、时间、疲劳或身体感受变化后，用户可以提出修改。
5. Kriki 保留仍然有效的内容，只重排受影响部分，并保存为正式新版本。
6. 用户真实完成或明确未完成，系统形成可靠执行事实。
7. 日终或次日检查结果，不把一次变化写成已证实因果。

体验窗口先验证 Coach 会连续工作：首份判断和今日安排 → 根据执行、新数据和反馈调整 → 回顾变化并说明下一步。正式试用时长统一以“怎么收费”为准。

首发场景还要做选择

跑步训练、睡眠改善、日常活动改善只能先选一个样板，不应同时做三套获客承诺。选择标准：

• 当前正式产品能力和数据成熟度最高。
• Apple Health 数据足以形成可信且可执行的日周方案。
• 用户问题高频、容易理解，并且在连续观察期内能看到过程价值。
• 安全边界和健康表述更容易确认。
• 能完整展示变化后重排，而不是只发固定内容。

产品验证及用户增长

这条路线统一产品、招募、内容、研究和渠道工作的先后顺序。每一阶段只回答一个问题；具体接口、页面状态和研发验收仍进入各自的产品需求文档。

用户怎么来

Kriki 先用一个目标用户反复遇到、当下就要解决的问题吸引注意，再用完整的 Coach 体验建立信任，把一次体验变成持续使用、订阅和推荐。发布前先用 30–50 名目标用户验证这条路径，成立后再逐步扩大。

先用一个真实问题让用户停下来

首发获客问题候选：用户本来有锻炼安排，但昨晚睡眠、今天状态或临时日程发生变化，不知道今天应该照常、减量还是改期。

这个问题当下要做决定、会反复发生，也正是现有数据工具仍留给用户自己处理的部分。跑步可以作为最清楚的首发样板，但 Kriki 展示的必须是完整 Coach 价值：发现当前需要改善的方向，结合今天状态安排训练、基础活动和睡眠，现实变化后继续调整并检查结果。若训练剂量和负荷调整尚不可靠，就不能用跑步吸引用户，应先收窄为“昨晚没睡好，今天怎么安排”。

从看见到留下来

真实困扰出现 → 看见 Kriki 处理完整一天 → 进入场景页或 App Store → 下载并授权 → 得到首份有效判断与今日方案 → 执行或修改 → 变化后得到调整 → 回来复查 → 订阅或推荐

浏览、点击和安装都不等于获得用户。本计划把“有效新用户”定义为：符合首发条件，完成足够的数据授权，并得到首份有效判断和今日方案；执行或修改一项安排并回来复查，才说明价值开始形成。完整指标统一在“效果评估”中维护。

分三步建立获客能力

发布前｜30–50 名有效体验用户：通过定向邀请、相关社区和少量受众匹配的博主或教练，找到最容易验证 Kriki 价值的人。目标是证明问题、产品和信任是否成立，不用这批人的点击、补贴或付费结果证明规模增长。

有限开放｜100–300 名陌生用户：用首批用户验证过的同一场景，制作真实案例、短内容和完整演示，由社区、博主、视频作者和应用商店搜索带来用户，再由场景页、互动 Demo 与 App Store 连续承接。目标是证明陌生用户不靠人工解释也能走到首次价值并回来。

稳定后扩大：只有目标用户比例、首份方案、首次行动、7 日回来和订阅信号稳定后，才增加用户推荐、更多内容合作和小额付费投放。投放只放大已验证的方法，不能替产品寻找定位。

品牌怎么表达

现在采用的品牌表达

目前哲学、使命和愿景在产品营销上下文、蓝图页面和部分旧资料中存在不同版本。上市前必须确定一套统一的品牌表达，并让官网、App Store、媒体包、App 内 About 和合作材料都使用这一版本。

先讲用户得到什么，不先讲 AI

品牌传播的主次顺序必须固定：

1. 先讲用户不必再做什么：不用研究每个指标，不用每天独自做健康判断，也不用自己拼装计划。
2. 再讲 Kriki 具体做什么：读取、判断、规划、更新并检查结果。
3. 用一个完整生活场景证明：状态和生活变化时，计划真的会跟着变。
4. 最后连接长期价值：更稳定地保持身体活力和生活自由。
5. “越来越了解同一个人”只作支撑：解释后续建议为何可能更相关，不能替代具体交付。

首轮体验对外只承诺让用户在连续几天里看到 Coach 如何判断、安排和调整，不承诺短期身体改善；具体试用天数按收费规则单独确定。

对外怎么介绍 Kriki

文案怎么写

应该：

• 先给清楚判断和具体后果，再解释必要依据。
• 使用普通人的生活语言，不要求用户掌握专业指标。
• 明确不确定性、数据不足和停止条件。
• 把用户选择写成正常协作，而不是服从或失败。
• 用克制的信心代替夸张、恐惧或强迫亲密。

不应该：

• 用“闭环、Agent、价值链、投影、协同约束”等内部语言做消费者标题。
• 把相关性写成因果，把短期变化写成身体已经改善。
• 用红色警告、连续打卡、排名或损失厌恶制造焦虑。
• 把 Kriki 写成会诊断疾病、替代医生或保证效果的主体。
• 暗示 WHOOP、Apple、运动员或教练为 Kriki 背书或合作。

不再使用的文案

• 让身体，也有发言权。
• 不是更多，是更合适。
• 今天，刚刚好。
• 你不缺数据。你缺的是下一步。
• 好状态，不该只是偶然。
• 该练还是该休，早上就有答案。

“健康，不必等生活配合”“不是你跟不上计划，是计划没跟上你”“唯一学员”等可以作为研究候选，但在外部验证和品牌确认前不是正式主张。

品牌视觉和素材

上市前需要形成一套可以直接制作、审核和重复使用的品牌素材与规范：

现有 kriki-cover.html 是内部资料入口，不是消费者上市页；现有 Demo 与蓝图图片是设计和说明证据，不能直接当成正式商店素材。

怎么说明 Kriki 与其他产品的不同

竞争传播不以“指标更多”取胜，也不在没有可直接比较的证据时宣称更准确、更专业或效果更好。首发只需要清楚证明 Kriki 承担了其他方案仍留给用户的分析、安排和更新工作。

名称、商标和线上资产

上市前需要完成：

• Kriki、Kriki Coach 及 Logo 在首发地区和相关类别的商标检索、申请策略与使用边界。
• App Store 名称可用性、Bundle ID、域名、支持邮箱和主要社交账号的一致命名。
• 品牌名读法、大小写、缩写、中文名使用和产品内角色称呼规则。
• 域名、证书、账号、设计源文件和社交资产的组织所有权与续费责任。
• 字体、照片、插画、音乐、竞品截图、用户内容和第三方商标的许可与署名记录。

名称可注册、域名已购买或素材能在 Demo 中显示，都不等于完成了商标和授权审查。

哪些话能对外说

现在可以说什么

仅当能力真实存在于准备发布的候选构建中，才可以传播：

• 读取用户明确授权的 Apple Health 数据。
• 根据当前数据和用户提供的信息形成状态判断。
• 形成具体的今日方案。
• 用户可以接受、修改、拒绝和纠正。
• 情况变化后，Kriki 会重排受影响的计划内容。
• 记录真实执行，并在之后检查相关结果。
• 清楚显示数据不足、不确定性和停止条件。

现在不能说什么

• “Kriki 已经证明能改善睡眠、恢复、心肺、压力、体重或生理年龄。”
• “一次运动释放压力，所以一定改善今晚睡眠。”
• “使用 Kriki 就能保持年轻、延缓衰老或逆转 Age。”
• “Kriki 比 WHOOP、人类教练、医生或其他产品更有效。”
• “大多数用户都获得了某项效果。”
• 任何不存在真实样本、观察窗口、计算方法和审查记录的百分比、证言或因果结论。

各类说法的使用范围

提到 WHOOP 时要注意什么

WHOOP 可作为恢复、负荷、睡眠机制和交互研究来源，但 Kriki 不复制其命名、颜色、算法目标或品牌语言，不暗示合作，也不将 WHOOP 的用户结果转写为 Kriki 的证据。

收费方式和成本

已确定的收费原则

• Free 提供有限判断和单次帮助。
• Coach 收费价值是完整日周计划、现实变化后重排、持续跟进、执行记录、回顾与长期学习。
• 分层依据是 Kriki 承担多少持续管理，而不是用户能看多少自己的数据。
• 用户不为取回自己的数据付费。
• 到期后仍保留合法历史、事实、个人资料、明确维护记忆、导出和删除等权利。

还没确定的收费内容

这里要区分两个时间：Fitbeing 的 3 天是入口体验，Kriki App 的 7 天是订阅试用候选；两者都不是身体改善承诺。

当前 AI 成本估算

此处只是基于新版调用场景的模型成本模拟，不是完整毛利。正式商业模型还必须加入：

• App Store 分成和支付相关成本。
• 云服务、数据库、队列、存储、监控和网络。
• 语音转写或其他第三方接口。
• 客服、人工安全升级、运营和值守。
• 税费、退款、欺诈和优惠。
• 免费用户与试用用户的服务成本。

上线前要算清的成本

每付费用户月收入
- App Store 分成
- 模型调用
- 基础设施
- 第三方服务
- 支持与退款准备
= 贡献毛利

同时按渠道拆分：获客成本、试用成本、试用转付费、首月退款、月留存、年付占比和回收周期。不能只用月价减模型调用得出“商业成立”。

什么时候可以开始收费

• 商品、国家 / 地区、价格、试用、促销和展示顺序批准。
• Free / Coach 能力矩阵逐项确认，并与 Agent 门控使用同一版本。
• StoreKit、服务端收据、恢复购买、退款、撤销、宽限、支付重试、离线和跨设备状态验收。
• 到期时不删除或隐藏用户自己的事实与数据权利。
• App Store 文案、订阅页、首次使用和个人页的说法一致。
• 订阅问题支持入口、处理时限和操作记录可用。

如果以上内容不能在候选版确定前解决，应明确选择“首发不收费 / 继续 TestFlight”，并从公开材料中移除未实现的订阅承诺，而不是用临时权益上线。

首发预算

上市预算应独立列出，不与研发日常成本混在一起，至少包含：

• 品牌、官网、商店素材和视频制作。
• 用户研究、体验激励和研究工具。
• 创作者、教练、社区和 PR 合作。
• 付费投放试验及明确停投上限。
• 法务、商标、隐私和专业健康审查。
• App Store、第三方工具、监控和支持。
• 发布期值守、事故准备和不可预见费用。

每笔预算对应目标、负责人、采购 / 合同状态、可归因结果和停止条件。CAC 在产品激活与留存尚未成立前只能作为探索指标，不能反向要求团队为降低获客成本夸大承诺。

怎么判断产品有没有用

要看哪些数据

最重要的指标

每周至少完成一次“判断 → 方案 → 执行或修改 → 结果验证”的目标用户数。

这是当前候选，不应在事件定义、自然周计算方式、有效执行、有效修改和验证标准确定前直接成为团队 KPI。

首批用户要验证什么

1. 用户能否准确说出 Kriki 与 Apple Health、恢复评分和通用 AI 的差别？
2. 用户愿意授权哪些数据，拒绝的真正原因是什么？
3. 首份判断是否与自我感受和现实条件一致？
4. 方案为什么被接受、修改、拒绝或忽略？
5. 现实变化时，用户会不会想到找 Kriki 重排？
6. 用户是否理解 Kriki 的不确定性和非医疗边界？
7. 七天内最清楚的价值时刻是什么？
8. 用户愿意为什么持续付费，不愿意为什么付费？
9. 哪种表达既能快速理解，又不会过度承诺？
10. 哪个目标型场景最适合作为首发样板？

对外信息要有依据

每项对外事实或数字至少记录：声明文本、声明类型、适用地区与渠道、产品版本、数据来源、样本、时间窗、统计方法、审查人、到期 / 复核时间和允许的表述范围。

没有记录依据的健康结果、客户数字、推荐语或比较结论，不进入公开材料。

上线前要准备哪些内容

用户会看到的内容

招募和合作需要的内容

• 首批体验招募页与筛选问卷。
• 体验同意、隐私说明和联系渠道。
• 连续 7 天用户验证指南与预期说明。
• 用户访谈提纲和行为日记模板。
• 创作者 / 教练合作 Brief。
• 禁用声明、可用事实和披露模板。
• 产品截图、B-roll、Logo 和品牌规范包。
• 发布事实表、常见问题和媒体问答。
• 客户案例授权、事实核验和撤回流程。

团队内部需要的内容

• 唯一产品与品牌事实表。
• 首发范围和明确不做清单。
• 公开内容与依据清单。
• Demo、候选构建和公开素材的版本映射。
• App Store 审核说明和测试账号指南。
• 客服问题分类、回复模板和升级路径。
• 发布日值守表、监控看板和回滚手册。
• 决策日志、风险接受记录和发布签字页。

合规与用户信任

账号和协议还缺什么

当前更完整的登录注册稿仍未完成。新用户注册上线前至少必须有：

• 已批准的用户协议和隐私政策正文。
• 协议版本、展示入口、明确同意和留痕规则。
• 首发允许注册的国家 / 地区。
• 最低注册年龄及监护人政策。
• 邮箱注册、验证、密码、找回、会话和风控规则。
• 账号合并、迁移、注销和数据删除边界。

临时网页、自拟协议、App Store 年龄分级或工程默认值都不能替代正式决定。

健康与隐私

• Apple Health 权限按功能和最小必要原则申请，不在未授权前伪装已了解用户。
• 清楚说明读取什么、为什么需要、拒绝后仍可做什么。
• 健康数据、对话、资料、记忆、推断和执行事实分别定义用途、保留、导出、更正和删除。
• 退订、退出登录、注销、删除和撤销授权是不同动作，不能互相替代。
• 跨账号隔离事故的发布门槛为 0。
• 日志、埋点、支持和模型上下文不保存不必要的原始敏感内容。
• 外部分析、客服、创作者案例和研究再利用都要有单独、明确的合法基础。

App Store 上架准备

• App 名称、副标题、关键词、分类、年龄分级和首发地区。
• 隐私标签、数据收集用途和 Apple Health 相关披露。
• 隐私政策、支持页、营销页和联系信息的公开 URL。
• 订阅商品、价格、试用、恢复购买和审核截图。
• 审核说明、测试账号和完整功能演示路径。
• 出口合规、加密问卷和适用声明。
• 真实候选构建、版本号、发布说明和已知问题。
• 分批发布、暂停、撤回和紧急版本安排。
• Apple Developer 组织账号、角色权限、Bundle ID、证书、描述文件、HealthKit entitlement、Push、StoreKit 和生产环境配置。
• Privacy Manifest、第三方 SDK 声明、崩溃符号、依赖许可和数据用途核对。

具体法律适用性和 Apple 最新要求必须由专业人员及提交时的 App Store Connect 实际表单确认，这份上市计划不代替法律意见。

第三方服务

所有会接触账号、健康、行为、支付、日志或支持数据的供应商必须登记：用途、数据字段、存储地区、保留期限、分包方、删除能力、安全措施、合同 / 数据处理条款和退出迁移方案。

分析、崩溃监控、邮件、客服、模型、云服务和创作者工具不能因为“行业常用”就默认获准读取健康内容。Apple Health / HealthKit 数据用途、广告和再利用限制须在实现与营销方案中单独核对。

美国法规需要确认什么

美国作为当前首发方向，需要由合格法律与隐私负责人建立逐项适用性清单，不能只依赖一份通用隐私政策。清单至少评估：

• FTC 对消费者健康、广告证据、推荐与披露、订阅和不公平 / 欺骗性行为的要求。
• FTC Health Breach Notification Rule 是否及如何适用。
• 首发州的消费者健康数据、综合隐私、数据泄露通知和未成年人规则。
• HIPAA、COPPA 及其他健康或儿童规则是适用、不适用还是需要特定产品限制，依据是什么。
• 健康声明、用户案例、创作者合作、评分和比较广告需要什么证据与披露。
• 跨境传输、供应商、模型服务、数据处理条款和事件通知义务。

确定首发方向前，至少要明确评估范围、首发州、责任人和会改变产品范围的硬性要求；准备公开试用前，要完成正式适用性结论，并把要求写入协议、产品、数据流、供应商合同、营销审查和事故流程。这份上市计划只记录工作，不预判任何具体法律一定适用或不适用。

上市准备进度

确定首发方向

这一步要解决：团队把“为谁、在哪、用什么产品、承诺什么、怎么收费”说清楚并达成一致。

要完成的事：

• 美国首发正式确认，或明确选择其他国家。
• 首发目标用户、一个目标型场景和排除人群确定。
• 八个首发功能、首发隐藏项和发布后项确定。
• 统一品牌表达、品类、口号、核心承诺和公开表述规则确认。
• 首发是否收费、试用基本形态和验证方式决定。
• 美国法规适用性评估范围、首发州、法律 / 隐私负责人和潜在硬约束确定。
• 每项上市工作有负责人、截止、依赖和完成标准。

验证用户能否看懂价值

这一步要解决：目标用户看得懂、愿意进一步体验，且不会因表达产生错误期待。

要完成的事：

• 产品定位、首页首屏、App Store 核心信息和场景脚本完成理解测试。
• 目标用户能区分 Kriki 与数据看板、恢复分和聊天工具。
• 数据授权前后的价值表达与信任问题得到验证。
• 目标型场景选择有用户和产品依据。
• 所有准备公开使用的说法都已列入公开内容清单。

核心体验能用

预计时间：08.15–08.28，完成规则、数据、首次使用、三项状态、周计划、今日方案、执行和文字调整。

要完成的事：

• 核心范围对应的正式产品需求文档已评审。
• 账号、Apple Health、三项状态、周 / 日方案、调整、执行和回顾能在真机串通。
• 数据不足、失败、取消、撤权、冲突和安全停止可用。
• 方案改变形成正式新版本并读回，执行事实可可靠结算。
• AI 任务有版本、日志、停止和回滚能力。

30–50 人连续体验

预计时间：09.25–10.07，使用稳定候选版连续体验。

要完成的事：

• 样本符合美国 iPhone + Apple Watch 筛选条件。
• 候选主版本和小版本关系可追溯。
• 至少覆盖授权、首份方案、首次行动、一次变化、一次重排和一次验证。
• 产品、理解、信任、安全、支持和成本数据完整。
• 10.08–10.16 解决影响继续推进的问题并完成一期回顾，不因单个好案例提前扩大开放范围。

准备公开试用

预计时间：10.12–11.06，完成账号、隐私、订阅和发布准备。

要完成的事：

• 账号协议、隐私、年龄、地区和数据权利完成确认。
• 美国消费者健康数据、广告、订阅、未成年人和供应商义务的适用性结论完成，并已写回产品与运营。
• 若收费，Kriki App 商业试用、试用起点、付费墙、到期权益和 StoreKit 生命周期完成验收。
• Logo、App Icon、基础品牌规范和商店素材模板完成。
• 生产环境、迁移、监控、容量、备份和回滚可验证。
• 健康内容、安全规则、AI 任务版本与评测标准完成确认。
• 首个可重复归档的 TestFlight 构建形成。

完成 14 天 TestFlight

预计时间：11.09–11.22。

要完成的事：

• 使用同一候选主版本进行连续试用，关键问题的修复可追溯。
• 八个首发功能按正式清单完成验收。
• 界面、无障碍、健康内容、安全、隐私、订阅和 AI 任务回归通过。
• App Store 最终素材只来自真实稳定候选构建。
• 发布指标、阈值、值守、支持和事故流程演练完成。
• 尚未解决的问题有明确影响、应对方法、负责人、期限，以及是否会改变发布决定。

决定是否上架

预计时间：11.25–11.27。

唯一允许的决定：

• 分批发布。
• 继续试用。
• 暂缓发布。
• 回退候选版本。

发布决定只使用当前候选版本的真实证据。“基本完成”、口头保证、正在修复或其他版本通过不能算本版本通过。

首发后先扩大已经验证的 Apple Watch 主线；更广人群、Fitbeing 和 Android 生态的进入顺序与条件，统一见“产品验证及用户增长”。

上线前要完成什么

产品开发、测试、候选版本和 App Store 提交继续按详细项目计划执行；这里仅记录项目计划之外的上市配套事项。

谁负责什么

以下姓名来自现有项目计划，只用于梳理，不代替新的责任确认：

品牌、增长、商业、法务和支持如果没有明确单一责任人，即使开发完成，上市仍然会在最后阶段集中卡住。

上线后的运营与支持

上线后要管哪些情况

• Apple Health 未授权、部分授权、数据不足、同步延迟和撤权。
• 身体状态或计划形成中、失败、超时、取消和结果过期。
• 无网络、服务维护、客户端版本过低和后台任务中断。
• 账号验证、会话失效、密码找回和疑似串号。
• 订阅处理中、待核验、宽限、退款、到期和恢复。
• 安全限制、证据不足、需要专业帮助和用户申诉。
• 通知错误、重复、迟到、越时区和无法关闭。
• 导出、删除、注销和隐私请求。

怎么帮助用户

运营支持指定一名单一负责人；发布日明确值守时段、接单入口、替补和升级对象。

上市前需要确定：

• App 内和网页支持入口。
• 支持范围、服务时间和首次响应目标。
• 账号、支付、Apple Health 同步、Coach 结果、隐私和安全问题分别由谁先接、何时升级。
• 哪些问题必须升级给产品、健康、安全、法务或工程。
• 支持人员可以读取什么，不可以读取什么。
• 用户身份核验和敏感数据处理方法。
• 退款、删除、注销和安全事件的操作记录。
• 已知问题、状态页和大面积故障通知方式。

监控与提醒

至少建立：

• 启动、崩溃、卡顿、网络和同步质量。
• 账号注册、登录、会话和跨账号隔离。
• 健康数据新鲜度、缺失率和异常分布。
• 各 Agent 任务成功率、耗时、超时、取消、重试和成本。
• 方案提交、读回、版本冲突和迟到结果。
• 安全任务、降级和人工升级。
• 订阅购买、收据验证、权益同步、退款和恢复。
• 核心漏斗、留存与渠道归因。

任何指标都必须先定义事件、计算方法、窗口、数据延迟、阈值、接收人、升级和恢复条件；不能上线当天临时定经验阈值。

出问题时怎么处理

必须支持：

• 远程停止某类 Agent 任务、Prompt、Skill、Tool 或知识版本。
• 回退模型与任务配置，而不破坏已保存事实和历史。
• 暂停分批发布、订阅入口或特定高风险能力。
• 撤销错误计划并保留审计，不伪造用户执行事实。
• 数据迁移前备份、失败停止、回退和实际版本读回。
• 对受影响用户进行准确告知和后续处理。

用户沟通和评价

• 首次使用引导、数据同步、首份方案、日终 / 次日验证、周回顾、试用结束和到期沟通必须来自同一正式状态。
• 通知默认使用计划形成时已经批准的内容和条件，不为每次发送临时调用模型。
• 用户拒绝、未完成或状态差时不催促评分，也不以羞耻或焦虑推动回访。
• App Store 评分提示只在用户完成真实价值节点后出现，频率和关闭规则可控。
• 运营支持把差评、退款、社交反馈和支持工单统一分类，关联版本与用户旅程节点，并定期回传产品。
• 发布后的案例、评论和推荐语须核验真实性、取得授权，并避免把个人体验推广为普遍健康结果。