立项 SRS 只写了三个阶段，没有时间，也没有「怎样算做完」；第一阶段还装进了几件要等别的系统出接口的事。 建议保留它的方向，把近期重切成五步：先拿现有能力找一家门店真实试点，再依次接预约写回、开第二个主动 Agent、 把治疗实例交给人、最后规模化。每一步写清进入条件和出口标准。
SRS 第 25 节把工作分成「产品闭环、规模化执行、能力扩展」三个阶段，第 24.2 节列了首期 8 个端到端验收场景。
方向合适，切法不合适。远期照它的三个阶段走；近期按「能在真实用户身上验证的闭环」重新切，外部依赖单独拎出来当关卡。
每一步三样东西：进入条件（缺了就不开始）、这一期做什么、出口标准（做到了才算完）。时间只给 M1 写了，其余几步卡在别的系统上，写死日期没有意义。
把员工的企业微信号接进来，让 AI 能以这个号的身份接待、答不了的一定叫到人、还能主动做预约确认。
待确认清单（文档 06）里记的「M1 通道数据脊柱」（08-26 完成）并进这一步，从这份起重新编号。
一家门店、两三个员工的号、真实患者，用现有能力跑起来，拿到第一份真实数据。对应 SRS 首期的「会话闭环」和「一个 Routine Task 闭环」（预约确认，先不写回）。
预约确认的结果回到业务系统，前台不用再手工同步。补齐场景 4，和场景 8 里「写入失败」那一半。
开第二件主动去做的活。被动接待天然自限，主动触达不是，所以先定上限，再开 Agent。
复诊没约上、治疗链断了，系统找出来，在工作台亮给人，附上话术。对应 SRS 首期的「一个治疗实例闭环」，和场景 2、3 里「识别」那一半。
对应 SRS 第二阶段。每一项都等试点数据证明值得再排。
SRS 第三阶段（新的 Agent、跨系统的患者 Journey、扩大自动执行范围）排在这之后，按试点证据再定。
SRS 第 24.2 节原文的 8 个场景，逐个对照现在的实现，和它落在哪一步补齐。
| # | 场景 | 现在 | 补齐在 |
|---|---|---|---|
| 1 | 患者在线咨询洁牙，AI 查信息给候选时间，患者确认，业务系统建预约 | 没做 AI 能答咨询，但查不了号源、写不回业务系统。建议改成人在工作台一键建约 | M2 |
| 2 | 正畸已有方案没预约，治疗机会 Agent 持续推进，形成预约 | 没做 没有数据源；建议先做「识别后交给人」 | M4 |
| 3 | 种植一期做完没有下一次预约，治疗链 Agent 识别异常，推动复诊 | 没做 同上，识别给人、人去联系 | M4 |
| 4 | 明天的预约，预约确认 Agent 触达，患者确认，业务系统更新为已确认 | 部分 触达、确认、没回改电话、到诊回读都做了；写回没做 | M1 验证 · M2 写回 |
| 5 | 患者要求改期，又问术后肿胀，两件事分别转给合适的人 | 部分 能认出来并交给人；还不能按岗位分给护士和前台 | M1 验证 · M5 分派 |
| 6 | 诊后随访发现异常症状，停止自动回答，转护士或医生 | 部分 接待里说到症状就不回、交给人；诊后随访 Agent 本身没做 | M3 |
| 7 | 洁牙周期到了，Patient Care Agent 触达，患者有意愿就进预约流程 | 没做 | M3 |
| 8 | 通道发送失败或业务系统写入失败，任务看得见、能重试、不重复 | 部分 通道这一半做了（排队、去重、重试、告警）；业务系统还没有写入 | M2 |
这份是草案。下面几件定了，里程碑才能落成排期。