01
场景不是泛流量，是明确同行场景。
亲子、朋友、约会、雨天室内这类语境会进入成行包。
商家承接的不是“附近推荐”，而是带同行人、时间窗、预算和偏好的可行动需求。
Demand signal一次成行前，商家已经知道这些。
02
排队等位时间会被提前编排。
15-45 分钟可进入 TimeBank，超过阈值会提示替换或保留。
餐厅不用只承受用户临门离开，系统会把等待解释成附近微体验、加购或可接受缓冲。
03
供给票券、套餐和加购能进入同一张包。
活动、餐厅、团购、儿童椅、布置和外卖小单不再割裂。
接口侧先做可用性和规则校验，确认前只展示可执行候选，不提前触发写动作。
04
回执成交结果回到同一条链路。
确认、分享、到店、替换和反馈能形成可复核记录。
复盘时可以看到需求从哪来、为什么选中、哪一步被改过，而不是只有一个孤立点击。
Merchant value
不是多一个广告位，而是多一个可执行的需求入口。
旧页面里“用户、商家、平台”的价值被重新压进商家视角：需求更明确，等待可经营，结果可复盘。
需求带上下文
商家知道用户是亲子、约会、朋友还是独行，以及预算、忌口和时间窗。
等位被利用
等位不只是损耗，可转成周边加购、替代方案或可解释等待。
履约可归因
确认、分享、到店和反馈可以回到同一张成行回执里。
Proof board
商家价值用成行包里的数字证明。
这里展示的是当前系统的参考测算口径，不声明外部交易。它说明商家为什么不是只买曝光，而是进入一条可归因的本地生活执行链。
平台订单额¥555
活动 ¥160 + 餐饮 ¥280 + TimeBank 加购 ¥115。
组合篮子¥645
平台订单 + 出行估算，出行单列不混入平台订单额。
等待转化¥115
低糖小蛋糕 ¥80 + 减脂咖啡 ¥35。
决策节省93%
23 分钟手动决策对比 1.5 分钟 agent 决策。
订单额口径activity + dining + TimeBankAddon
transportEstimateGmv 单列，避免夸大平台订单。
归因路径自然语言目标 → 确认 → 回执
商家能看到需求来源、替换原因和确认状态。
证据等级参考测算 / 试点假设
不声明真实订单额、授权转化或用户验证。
Pilot loop
试点不需要一上来全量写入，先把供给读清楚。
旧文档里的安全预览、增强读取、受控执行三档接入被整理成商家可理解的试点路径：先看得见，再可确认，最后受控执行。
01
01授权和供给读取
先接商家、票务、排队、库存或菜单读取能力。
增强读取阶段允许授权服务优先；没有授权的写动作继续保持安全预览。
02
02进入成行包排序
供给不单独展示，而是参与路线、天气、等位和预算判断。
商家卡能被选中，是因为它让这次出门更能成行，而不是因为单点排名更靠前。
03
03用户确认后再写入
取号、预约、票务和分享都经过确认门禁。
写动作需要用户确认、版本校验、幂等字段和服务回执；供给变化要重新确认。
04
04回执归因和复盘
结果回到成行回执，记录确认项、替换原因和服务状态。
这部分适合做试点复盘：哪些场景带来需求，哪些等待被经营，哪些写动作需要补齐接口。