挂号页做出来之后，下一步是什么？用户确认挂号后，要看到候诊号；医生接诊后，图文会话要接上；处方生成、支付成功，还得有消息能把人带回对应页面。只展示几张界面图，这条链路其实没有跑起来。
这次我用墨刀 AI 客户端的"生成应用"能力，做了一个"青柠问诊"演示项目，产物是一套可交互的移动端APP。下面不讨论一句话能生成多漂亮的首页，而是拆开看它如何把"登录建档→科室挂号→候诊叫号→图文问诊→处方支付→消息推送"串成一件事。文中的医生、药品、价格和诊断均是演示数据；接口为本地 Mock，没有真实医疗、短信或支付服务。
一、先看首页能不能把人送进就诊流程
登录后，首页没有把所有功能平铺成一组入口。上方先显示"还没有进行中的就诊"，主按钮直接通向"选择科室挂号"；下方才是图文问诊、视频问诊、预约挂号、处方支付等常用服务。底部固定四个入口：首页、挂号、消息、我的。
这个层级是有作用的，用户已经挂号时，首页应当优先展示正在进行的就诊；尚未挂号时，首要动作是找科室和医生，两种状态不能共用同一张静态首页。检查 AI 生成应用时，可以先问一句：页面是否随着业务状态改变主操作？若首页始终只展示功能图标，后面的流程再完整，用户也难找到当前该做的事。
二、再看挂号不是选中医生就结束
在这个案例里，挂号入口支持按科室、症状或医生查找。科室页列出专科、症状标签、费用和预计接诊时间；进入医生主页，还要选日期、时段、图文或视频方式，最后确认就诊人和费用。确认后才出现候诊号。
这里最值得检查的是"选择是否真的传下去了"。医生、就诊人、日期、时段、问诊方式与费用，应当在确认页和候诊页保持一致。演示中的候诊票据会带出医生、专科、时间和图文问诊方式，号段如 A050 只用于演示。若前一页选的是视频问诊，后一页仍显示图文，或者切换就诊人后处方写给了默认用户，那只是页面看起来连贯，数据并没有连贯。
日期和号源也要留给人工核对。演示页上有"剩余 7 号""约 3 分钟接诊"之类的数字，但它们来自模拟数据，不能被当成真实医院承诺。正式产品需要接入号源、定价与排班服务，并处理无号、重复挂号、支付失败等情况。
三、候诊页要解释状态，而不只是显示进度条
挂号成功后，页面出现候诊号、前方人数、预计等待时间和就诊流程时间线。随着演示控制台触发状态，前方人数从 3 位变为 1 位，顶部弹出"下一位就是你"的提醒；医生接诊后，入口变为"进入诊室"。消息中心也留下相应记录。
这个细节把两个常被分开生成的页面接了起来：候诊页负责回答"我现在排到哪里"，消息负责在用户离开页面后把状态带回来。演示中的推送由本地 Mock 时间轴产生，也可以在右侧控制台手动触发。它证明的是原型能够演示状态联动，不等于已经接入真实的实时叫号系统。
要把这一步交给开发，至少还得定义：排队人数从哪里来、多久更新一次、超时未进入诊室怎么办、取消挂号后退款状态如何同步。尤其是"预计等待 14 分钟"这种数字，应该标出计算口径和更新时间，而不是写死在界面里。
四、图文问诊、处方和支付有没有接成同一单
进入诊室后，图文问诊页显示医生身份、候诊号、消息列表、图片入口和转视频入口。演示里医生接诊消息会进入会话；继续交互后，处方生成通知把用户带到处方页。处方页有诊断、医嘱、药品明细、应付金额和支付按钮；支付完成后，支付结果页保留订单号、处方号、配送方式，并给出"查看消息"的下一步。
这里不能只数页面，更关键的是同一笔就诊的标识能否贯穿：候诊号、医生、就诊人、处方、金额和支付结果应对应同一个就诊记录。演示数据中，处方应付 ¥124.58，支付成功页仍是 ¥124.58。对演示原型而言，这种前后对应比单页视觉精致更能说明应用已经形成流程。
但医疗业务的底线不能靠生成结果自证，处方由谁审核、药品是否可售、禁忌与过敏如何校验、支付失败后能否重试，都是上线前必须由业务与技术团队明确的规则。演示里的医生回复和处方是预设脚本，不应当解读成真实诊疗能力。
五、消息中心是检查流程是否闭合的地方
这个应用的消息中心按就诊、挂号、处方、系统分类，能看到叫号、接诊、处方生成和支付成功等记录。未读角标也会随着消息增加。点"查看详情"时，消息需要回到对应的候诊、问诊或处方页面。若只能显示一条通知，却无法定位业务对象，消息就成了装饰。
用生成应用做评审，可以沿着消息倒查整条链：支付成功通知对应哪个处方？处方对应哪次问诊？问诊对应哪个候诊号与就诊人？倒查不通，就算每个页面都能点开，也不能算闭环。
六、这类 AI 生成应用，评审时怎么验收
AI生成应用，评审时从登录到支付至少走一遍，记录每次页面跳转和状态变化；不要只看首页截图。在不同页面核对就诊人、医生、时间、费用、候诊号和处方号，找出不一致的字段。分别触发"未挂号""候诊中""已接诊""待支付""支付成功"等状态，看主按钮与消息入口是否随状态改变。
另外，把所有演示数字和 Mock 行为标出来，避免在评审材料中被误认成真实号源、服务时效或支付能力。再列出异常流程：无号、取消、掉线、医生未接诊、处方审核失败、支付失败、推送未达。现有演示走通正常路径，不代表这些情况已经解决。
这次用墨刀AI生成的"青柠问诊"APP，看点是它把挂号、候诊、问诊、开方、支付和通知放到了同一条可操作的路径里。拿这种demo做需求讨论，团队能直接指出哪个状态缺了、哪项规则需要后端支撑。准备进入真实开发时，先把 Mock 接口、虚构医疗数据和未定义的异常流程逐项替换或补齐。