← insider机密 · 内部
战略与商业

wellbeing-eng — 产品 / 平台实施规划 v0

状态：v0 实施规划，Claude 按 jacky「直接规划出来准备实施」推断（2026-06-16）。配 docs/product-strategy.md（为什么）与 docs/business-plan.md（商业）。⚑ = 待 Zoe/jacky 确认。 实施纪律仍是 offline-first：MVP 就是把线下 dyad runbook 数字化的那个工具（先咨询师内用、带埋点），不是另起炉灶。P1 ticket = .spec-initialization/changes/map-offline-care-flow/。

1. 一句话：我们在建什么

一个**「患者-照顾者 dyad」的心理陪伴操作系统，从围术期场景切入**（入口已拍板=围术期作为首场景，strategy §9-1）： 用户端（患者 + 照顾者各自入口）做评估、匹配、陪伴、课程、随访；咨询师端做排期、会谈、督导、产能放大；中间一层 AI 能力（评估 / 循证干预 / 危机分诊 / 课程编排 / 随访）放大稀缺的咨询师小时；一层安全子系统兜底；一层数据回流驱动飞轮。

泛化纪律：底座（dyad + 安全 + 能力 + 数据）按通用「照护-历程 care arc」设计，围术期只是第一个 arc 模板；慢病/产后/丧亲等扩展场景复用同一底座，排在围术期跑透之后（P3+），不并行铺开。

2. MVP（v0.1）定义 —— 最小可跑的「真东西」

MVP 不是给公众的 App，是给咨询师内用的「数字化 runbook + dyad 档案 + 危机闸 + 埋点」，让 §P1 线下流程在一个工具里跑，同时自动沉淀平台需要的数据。

MVP 必须有、且只有这些：

  1. Dyad 档案：一对患者+照顾者，各自的评估与时间轴。
  2. 结构化评估表单（患者一套 / 照顾者一套），录入即打分。
  3. 危机分诊闸：录入/会谈中触发危机信号 → 强制升级流程 + 资源卡片（人工，不自动闭环）。
  4. 会谈记录 + 随访排期。
  5. 埋点：每步耗时/频次/摩擦/是否需专家 —— 指明下一个该自动化的面。

MVP 故意不含：用户自助 App、AI 自动评估、自动匹配算法、支付、课程平台。这些按数据证据在 P3 加。

MVP 验收：一位咨询师能在工具里完整跑一个真实 dyad case；危机闸 0 漏报；埋点能产出「第一个该平台化的面」的结论。

3. 产品面（concrete surfaces）

A. 用户端（P3 才对外，MVP 内不开放）

  • 患者入口：自评 → 匹配结果 → 我的咨询师/课程 → 陪伴（AI 日常 + 人工会谈）→ 随访提醒。
  • 照顾者入口（独立账号，关联同一 dyad）：照护负荷自评 → 自己的陪伴节奏 → 「照顾者喘息」内容/课程 → 同样的危机资源。
  • 共享：dyad 时间轴（围术期 T-减/T0/T+，§strategy 4）、危机求助按钮（常驻）。

B. 咨询师端（MVP 即从这里起）

  • 我的 dyad 列表 + 每个 dyad 双线档案
  • 评估查看/录入、会谈记录、随访排期
  • 危机闸 + 升级面板
  • 课程交付（P3）、督导/同伴复盘（P3）

C. 运营/Admin

  • 咨询师排期与产能、匹配队列、埋点看板、内容/课程库、合规与审计日志

4. 能力层（capability/）—— 具体到 skill 契约

doctrine：AI 放大专家、不替代（strategy §3）。每个 skill 的输出都带 needs_human_review 与 evidence。

Skill输入输出人/AI 边界阶段
assessment（患者/照顾者两套）自评答案 + 基本面维度分 + 风险标记 + 建议节奏AI 出初评，咨询师定档P1 spec → P2
crisis-triage文本/评估信号危机等级 + 升级动作 + 资源AI 只升级不闭环，人工处置P1 spec → P2（最先）
intervention（CBT/ACT/正念/叙事）评估 + 阶段干预素材/脚本/练习AI 备料，咨询师施与P2-3
program-orchestrationdyad 状态课程/内容编排AI 编排，咨询师审P3
follow-up时间轴随访问卷/提醒/结果抽取AI 跑，咨询师看异常P2-3

connectors（capability/connectors/）：用户档案 · 课程/内容库 · 咨询排期 · 渠道/内容回流 —— 全部 PII 最小化 + 脱敏 + 可删除。

5. 系统架构（tech）

        用户端 (Next.js, 患者/照顾者)         咨询师端 + Admin (Vite+React)
                    │                                  │
                    └───────────────┬──────────────────┘
                          API Gateway (FastAPI)
                                    │
        ┌───────────────┬──────────┼───────────┬────────────────┐
   能力编排           安全子系统     档案/排期     课程/内容        分析/埋点
  (LangGraph)      (crisis gate)   (Postgres)   (对象存储)       (events)
        │
   LLM: Claude Opus 4.7 默认 / Sonnet 按 task；reasoning→gpt-5/o3；语音陪伴→OpenAI Realtime
  • Backend: Python 3.11 / FastAPI / LangGraph / Pydantic（与 repo 默认栈一致）。
  • 用户端: Next.js 15 / React 19 / Tailwind 4（产品官网已是此栈）。
  • 咨询师端/Admin: Vite + React + TS + shadcn。
  • 数据: Postgres（档案/结构化）+ 对象存储（课程/媒体）+ event 流（埋点）。
  • 部署: GCP 共享 VM 起步（同 wb-eng.genprime.uk / pitch），数据量上来后独立实例 + 加密盘。
  • AI: 所有涉及评估/干预/危机的链路，输出经 needs_human_review 与审计日志；危机路径不依赖单一模型（规则 + 模型双触发）。

6. 核心数据模型（implementation-ready 草图）

CareArc(id, type{perioperative|chronic|postpartum|bereavement|...}, template)  # 通用照护-历程，围术期是首个 type
Dyad(id, care_arc_id, created_at, stage, anchor_date?, status)   # anchor_date 泛化 surgery_date
 ├─ Patient(id, dyad_id, profile, consent)
 ├─ Caregiver(id, dyad_id, relationship, profile, consent)   # 一等实体，非患者字段
Counselor(id, profile, credentials, specialties, capacity)
Match(dyad_id, counselor_id, rationale, created_at)
Assessment(id, subject_ref{patient|caregiver}, instrument, answers, scores, risk_flags, needs_review)
Session(id, dyad_id, counselor_id, type, notes, ts)
Program(id, title, modality, modules)  Enrollment(subject_ref, program_id, progress)
CrisisEvent(id, subject_ref, signal, level, escalated_to, resolved_by, ts)   # 审计级，不可删改
Event(id, actor, surface, step_id, duration, friction, needed_expert, ts)    # 埋点

关键设计点：CareArc 把「照护-历程」抽象出来（围术期是首个 type，扩展场景复用底座，不写死手术）；Caregiver 与 Patient 平级挂在 Dyad 下（落实双受众）；CrisisEvent 是审计级、不可篡改；Assessment 携带 needs_review（AI/人边界）。

7. 安全子系统（= 产品，不是免责声明，strategy §7）

  • 双触发危机识别：规则关键词 + 模型分类，任一命中即升级（降低漏报）。
  • 强制人工升级：升级面板锁定，必须有咨询师确认处置；AI 不得标记「已解决」。
  • 资源卡片：本地化危机热线 / 合作精神科转介（⚑ Zoe 提供）。
  • 边界与同意：每个 AI 交互点标注「陪伴/教育 vs 诊疗」；首用知情同意。
  • PII：最小采集、加密、可删除、可导出；真实个案不入 git；审计日志独立留存。
  • ⚑ 合规：心理咨询 vs 精神科诊疗 / 互联网医疗边界 —— 上线前法务过。

8. 实施时序与里程碑（build sequencing）

里程碑阶段交付毕业闸
M0 ✅P0repo + 双层骨架 + wb-eng.genprime.uk 双语 landing已完成 2026-06-16
M1P1线下 runbook + 表单 + 危机分诊纸面 + N case 埋点 + 两 skill specchanges/map-offline-care-flow 全 checklist 绿；定出首个平台化面
M2P2MVP：咨询师端数字 runbook（dyad 档案 + 评估录入 + 危机闸 + 会谈/随访 + 埋点）咨询师在工具里跑通真实 case；危机闸 0 漏报
M3P2→P3第一个 AI 能力上线（按 M1 埋点选：多半是 assessment 或 between-session 陪伴）AI 初评与咨询师定档一致性达阈值
M4P3用户端（患者+照顾者入口）+ 匹配 + 1 门课程交付一个真实 dyad 在产品里走完评估→匹配→陪伴→随访
M5P4内容/渠道增长引擎 + 闭环埋点 + 北极星指标看板单渠道 CAC < dyad LTV；北极星可测可环比

| M6+ | 扩展 | 第二个 CareArc 场景（慢病/产后/丧亲择一）复用同一底座 | 前提：围术期单场景已被证明可复制（M4-M5 跑透）—— 不提前并行 |

每个里程碑结束做一次复盘 + 决定下一里程碑范围（jacky 留在 loop，feedback_context_continuity）。扩展（M6+）是「证明可复制后」的动作，纪律上先把围术期跑透（strategy §9-1）。

9. 启动所需（resourcing）

  • Zoe / 咨询师：现有线下流程、评估工具、咨询师名册与专长、危机资源清单、N 个真实 case 的接入。（→ reference/）
  • jacky / 工程：MVP 咨询师端（M2）、安全子系统、AI 能力（M3+）。
  • 法务/合规（⚑）：心理咨询 vs 诊疗边界、PII、互联网医疗。
  • 内容/增长（P4）：选题、渠道、转化路径。

10. 指标（贯穿埋点）

  • 北极星：每 dyad 被有效支持的康复周数（strategy §5）。
  • 过程：评估完成率、匹配时延、会谈留存、随访应答率、危机升级响应时延（安全）。
  • 经济：dyad CAC / LTV、咨询师小时产出（每小时服务的 dyad 数）。
← 返回 insider 入口