鼎味肉市小程序新原型：用户动线

当前真相：本文件与同目录 stories.md、scenario-model.json、cases.json 和 HTML 共同构成顾客小程序唯一当前真相包。旧版动线保留在上一级 customer-miniapp/ 作为历史输入，不再追加当前产品行为。

本轮把购买主路径重新收敛为“选 SKU → 一页确认 → 原生支付 → 结果”。当前 HTML 保留 cart.html（可选待选内容预览）与 checkout.html（唯一确认页）两个职责清晰的路由；真实微信支付、回调校验和服务端幂等仍是实现阶段工作。

同目录的 scenario-model.json、cases.json 和 fixture-contract.json 已同步当前 CASE 的可见路径、状态边界和待选内容语义；支付契约、计划持久化和后端幂等仍未实现，不把静态覆盖文件当成线上实现证据。

0. 购买路径的总原则

0.1 页面跳转预算

“跳转”只统计用户主动进入的新全屏页面；底部抽屉、地址选择器和微信原生支付浮层不算新的业务页面。购买路径的预算如下：

设计目标不是消灭所有页面，而是把页面只放在“用户必须做出新决策”的地方：商品选择、最终确认和支付。购物车预览、地址选择、订单详情都不能在主路径中制造额外的决策层。

0.2 目标购买层级

商品列表 / 计划清单
        ↓ 选购完成
统一订单确认页：商品、数量、金额、地址、时段、Quote
        ↓ 唯一主动作
微信原生支付浮层
        ↓ 回调
支付结果页：成功 / 待支付 / 失败或取消

• cart.html 的职责降为“待选内容的快速预览”：在买肉页或计划页以抽屉/轻量层承载，不作为每次购买的必经全屏页面。
• checkout.html 的职责升级为“统一订单确认页”：自由选购和计划采购都进入同一页面，商品行、金额、地址和配送时段在这里一次核对。
• address.html 只承担地址管理；确认页内使用地址选择器或轻量编辑层，不把顾客送去一个完整地址页再返回。
• order-success.html 是支付回调后的结果承载，不是顾客还要完成一次决策的结算页；order-detail.html 只作为支付后的可选服务入口。
• 当前原型用 checkout-payment 打开原生样式支付模拟层，再由 payment-confirm 进入 order-success.html；真实微信支付接入、回调校验和服务端幂等仍属于实现阶段，不把模拟结果当成线上支付证据。

1. 模块范围与路径目录

1.1 设计阶段扩展路径（暂不计入当前场景覆盖）

2. PATH 详情锚点

PATH-REDESIGN-HOME-DOORS

首页 → .intent-bar 的 home-self-select / .home-focus 的 home-planner；终点分别是 buy.html / basket.html。已登录且有常买记录时，.quick-section 的常买 SKU 进入 buy.html#<sku-detail>，仍由商品行完成加入，不把快捷入口误画成已下单。

PATH-REDESIGN-WEEKLY-PLAN

计划页当前周状态 → plan-day-* 时间轴切换 → plan-period-* 午餐/晚餐切换 → 选中日 plan-meal-slot-* → plan-recipe-picker 选择或新建菜谱 → 计划自动保存 → plan-shopping-list 核对 SKU 需求 → plan-order-confirm 进入统一订单确认页 → 原生支付。

计划清单是“本周需要什么”的事实汇总，不是第二个购物车；进入确认页后只生成本次采购快照，不直接修改计划历史。

PATH-REDESIGN-PLAN-EMPTY

空计划说明 → plan-day-* → plan-meal-add-* → plan-recipe-picker → 选择已保存菜谱或上传照片、写配方、确认 SKU 和份量；如果顾客暂时不做计划，再由 empty-home 或 empty-buy 回到其他入口。不填充假计划。

PATH-DESIGN-RECIPE-SAVE

计划页空餐次 → “新建菜谱” → 上传照片 → 写配方文字 → 确认 SKU 和份量 → 保存到“我的菜谱” → 留在当前选择流程 → 安排到当前餐次。保存菜谱只产生可复用记录，不创建购物车、订单或支付事实。

PATH-DESIGN-PLAN-RESTORE

首页“继续本周计划”或计划 Tab → 恢复最近家庭计划 → 恢复菜谱记录、餐次和 SKU 汇总 → 从上次停留的空餐次或已安排餐次继续。

PATH-DESIGN-PLAN-ORDER

计划达到完成条件 → 主 CTA 从“继续安排”切换为“按本周计划下单” → 锁定计划版本 → 按 SKU 和份量生成采购快照 → 检查 SKU、地址和配送能力 → 直接进入 checkout.html 统一确认 → 原生支付。中间不再插入完整购物车页面。

PATH-DESIGN-PLAN-SYNC

已生成采购快照后顾客修改计划 → 计划状态变为“需要同步” → 重新按 SKU 汇总 → 重新检查 Quote 和配送能力 → 用户确认后再进入订单确认。不能静默覆盖已经生成的采购内容。

PATH-REDESIGN-CART-CHECKOUT

购物车入口只打开待选内容预览；页面由一张可编辑商品卡和底部“合计 + 去确认”组成。顾客可以编辑数量或点击唯一的 cart-checkout 进入 checkout.html；来源上下文只决定返回/继续入口，不在顾客画布中增加来源卡、流程说明或确认范围。该路径保留用于“我想先看已选内容”的辅助场景，但不再是买肉和计划采购的必经路径。

PATH-DESIGN-PURCHASE-CONFIRM

buy.html 或 basket.html 完成选择 → checkout.html 统一订单确认页。确认页按“配送卡、订单明细卡、支付卡”的顺序只编排三组订单信息，不在顾客画布里解释来源或设计理由：

1. 配送卡：地址和配送时段置顶；点击后从底部选择，主页面各自只显示一个最终值；
2. 订单明细卡：商品行只展示规格、数量和行金额，配送费与唯一应付合计在卡片底部收束；
3. 支付卡：只确认微信支付方式；底部固定区只保留“确认并支付”动作，不重复渲染总额。

进入确认页不代表订单已创建、已支付或已绑定实际批次；数量、地址或时段变化都要重新校验 Quote。

PATH-DESIGN-CHECKOUT-CONFIRM

统一确认页 → 地址、时段、商品、数量和 Quote 均有效 → 点击 checkout-payment → 调用微信原生支付。确认页不再先经过一个购物车页面，再进入第二个只显示配送信息的页面；来源说明和实现解释留在评审侧栏。地址与时段通过底部选择层编辑，商品数量在确认页只读，配送时段和订单金额各自只有一个主页面事实位置；支付浮层仅作为后续平台确认层。

PATH-DESIGN-PAYMENT-RESULT

原生支付回调分为三种结果：

• 成功：进入 order-success.html，显示订单号、配送时段和后续查看入口；
• 取消 / 失败：回到确认页，保留已选内容和失败原因，允许重新发起，但不创建第二笔订单；
• 待确认：显示“支付状态确认中”，使用原 operationId 查询，不重复提交。

支付结果页不强迫顾客马上进入订单详情；“查看订单”和“回首页”是两个后续动作。

PATH-DESIGN-ADDRESS-RETURN

从“我的”进入 address.html?from=profile 管理配送地址；从统一确认页只使用地址选择器或轻量编辑层。确认页不把顾客送去完整地址页再返回，避免 checkout → address → checkout 的额外双跳。地址保存成功后回到确认页并重新校验配送范围与时段。

PATH-DESIGN-ORDER-RECEIPT

order-success.html → success-view-order → order-detail.html；也可以回首页继续浏览。订单详情承载订单快照、配送进度和履约后的追溯事实，不成为支付链路的必经页。

PATH-DESIGN-ORDER-DETAIL

profile.html → profile-orders → orders.html → order-row-* → order-detail.html；订单详情遇到包裹问题再进入 help.html#after-sales。订单详情只读取已经产生的订单快照，不把计划草稿或公开供给摘要写成履约事实。

PATH-REDESIGN-CART-UNKNOWN

UNKNOWN 说明 → unknown-query，使用原 operationId 查询，不生成第二笔订单、支付或写命令。

PATH-REDESIGN-TRACE-SUMMARY / PATH-REDESIGN-TRACE-BOUNDARY

商品目录和详情显示标准规格、固定价格与公开供给摘要；周期配送页显示计划供给边界。实际 Lot、包裹和检疫事实只能在履约后通过订单/包裹查看。

PATH-REDESIGN-OFFLINE / PATH-REDESIGN-NOT-READY

状态页 state-offline → offline-retry，离线时暂停写操作；状态页 state-not-ready → not-ready-home，不展示假价格、假库存、假订单或支付成功。

PATH-REDESIGN-SUBSCRIPTION-ACTIVE / PATH-REDESIGN-SUBSCRIPTION-EMPTY

周期配送页展示当前合约、下一次窗口和未来周期管理边界；无合约时只展示说明/方案入口，不伪造当前配送事实。

PATH-REDESIGN-ACCOUNT-SERVICE / PATH-REDESIGN-ACCOUNT-GATE

我的页 → 订单、地址、菜谱和唯一的帮助与规则入口。匿名态只读公开说明，受保护服务在认证后重新读取；我的页不承担下单确认。

3. 导航与页面职责

底部固定五个 Tab：首页 / 买肉 / 计划 / 订阅 / 我的。计划固定在中间第三位，并以动作色高亮、抬高图标和更强文字权重强调；购物车不是第六个 Tab，而是待选内容的辅助入口。

4. 主路径

F-001 自选采购：从商品列表到支付

目标路径：home.html → buy.html → 选择分类与 SKU → 直接加入待选内容 → 打开购物车预览（可选）或直接进入 checkout.html → 核对商品、地址、配送时段和 Quote → 微信原生支付 → order-success.html。

从买肉页开始时，顾客只需一次主动页面跳转即可进入统一确认页；从首页开始时，买肉页是唯一的商品浏览页。商品详情是可选路径，不应被强制插入每个 SKU 的购买过程。

• 成功条件：顾客能在商品目录中选分类、识别 SKU、打开详情或直接加入，并看到数量反馈；确认页只出现一个“确认并支付”主动作。
• 事实约束：列表与详情显示标准规格固定价；确认页显示服务端 Quote；商品目录不提前承诺实际批次。
• 交互约束：商品图片/名称详情入口与加入按钮是两个明确动作；购物车预览可编辑，但不再制造一层必经结算。
• 支付约束：原生支付取消、失败或待确认时回到原确认上下文；重试必须复用原操作，不生成第二笔订单。
• 状态边界：目录加载中不填充假商品；商品下架、价格缺失、供给不可用或配送地址失效时，关闭确认动作并保留原因。
• 回流：从确认页返回买肉时，分类、已选数量和当前地址上下文不丢失。

F-002 开始做计划：从家庭菜谱到一周采购

home.html → basket.html → 查看当前周与七日时间轴 → 选择日期和午餐/晚餐 → 安排或替换菜谱 → 计划自动保存 → 展开采购清单核对 SKU → 按本周计划下单 → 直接进入 checkout.html → 核对 Quote、地址和配送时段 → 原生支付。

• 成功条件：顾客不需要手算肉量，能把照片/配方/SKU 菜谱排进餐次，计划离开后可恢复，完成后可以一次生成本周采购确认。
• 首要焦点：进入计划页第一眼是当前周、保存状态和继续动作，不是购物车摘要。
• 中段焦点：七日时间轴先承载全周概览，选中日承载餐次、照片、配方、SKU 和份量；菜谱保存只在选择上下文出现。
• 末段焦点：采购清单按 SKU 汇总需求量、购买量和包装余量；计划完成后主按钮切换为 按本周计划下单。
• 确认边界：计划清单生成采购快照后直接进入统一确认；确认页只读显示采购数量，需要改量时返回计划清单，不能在确认页静默改写已保存计划。
• 数量规则：同一 SKU 的多顿需求合并展示来源；标准规格为 500g/份 时，不承诺可变重量精确购买。
• 失败边界：SKU 下架、价格变化、地址失效或供给不可用时，保留菜谱和计划记录，阻止生成无效采购快照。
• 回流：顾客离开后恢复家庭计划；采购快照与计划不一致时显示“需要同步”；已下单计划可以复制到下一周。

F-002B 保存与复用菜谱

basket.html 空餐次 → plan-recipe-picker → 我的菜谱 或 新建菜谱 → 上传照片 → 写配方文字 → 确认 SKU 和份量 → 保存 → 留在当前选择流程 → 排入餐次。

• 菜谱记录只包含照片、配方文字、SKU 和份量，不建立复杂食材映射。
• 保存菜谱不创建购物车、订单或支付事实；它是家庭可复用资产。
• profile.html 只展示最近 Top 2 菜谱预览和“管理全部”；完整管理进入 recipes.html，安排到哪一天仍回到计划页。

F-002C 计划下单与下周复用

basket.html 达到完成条件 → 按本周计划下单 → 锁定计划版本 → 生成采购快照 → checkout.html 统一确认 → 原生支付 → 计划显示“已下单” → 复制到下一周生成新版本。

• “按本周计划下单”只负责生成本次采购快照和进入确认，不绕过最终事实核对。
• 订单、计划和采购快照各自保留；支付成功后计划不消失，计划变更不能静默改写已支付订单。

F-002D 计划页眼位与焦点分配

F-003 回购：从订单记录重新核对

profile.html → 已登录且存在完成订单 → 点击订单复购入口 → 返回 buy.html 重新选择当前 SKU → 可进入详情并加入待选内容 → 统一确认与支付。

• 历史内容只是建议，不代表新订单。
• 当前地址、价格、配送窗口和库存/供给摘要必须重新读取。

F-004 周期配送：查看未来影响

home.html → subscription.html → 查看当前合约/下一次时间窗口 → 选择未来周期设置 → 保存前显示“只影响未来周期” → 返回订阅页。

• 未登录：进入登录/授权态；不开放匿名写操作。
• 无合约：显示可选方案行和规则说明，不显示假的当前合约。

F-005 我的与状态服务：身份、帮助和恢复

profile.html → 订单/地址/帮助/订阅服务入口 → 查看本人可读事实或进入授权门禁；异常状态统一进入 states.html，再从当前状态提供重新认证、重试或返回入口。

• 已登录：可以进入本人订单、地址、订阅和帮助；服务入口不暴露内部 actor、customerId 或权限快照。
• 未登录或会话过期：受保护写操作显示 permission gate，不自动重放原命令；浏览公开壳仍可继续。
• loading、offline、not-ready、unknown、图片失败和支付恢复均沿用 states.html 的可解释状态，不以成功态填充业务数据。
• 覆盖 PATH-REDESIGN-SESSION-GATE、PATH-REDESIGN-CART-UNKNOWN、PATH-REDESIGN-OFFLINE、PATH-REDESIGN-NOT-READY、PATH-REDESIGN-ACCOUNT-SERVICE、PATH-REDESIGN-ACCOUNT-GATE 和 PATH-REDESIGN-REPEAT-ABSENT。

PATH-REDESIGN-SESSION-GATE：会话失效门禁

states.html 显示会话失效原因和重新认证入口；不自动重放原写命令。

PATH-REDESIGN-ACCOUNT-GATE：匿名服务门禁

匿名顾客进入受保护的订单、地址或菜谱写入口时看到登录/授权要求；公开浏览入口仍可用。

PATH-REDESIGN-NOT-READY：能力未就绪

显示能力尚未开放和可用入口，不展示假业务数据或伪造成功结果。

PATH-REDESIGN-REPEAT：有历史订单的复购建议

从订单摘要回到当前 buy.html 重新核对 SKU、价格和配送事实；历史内容只作为建议，不直接创建新订单。

PATH-REDESIGN-REPEAT-ABSENT：无历史时隐藏复购

没有完成订单时不显示复购动作；顾客仍可从公开目录开始正常采购。

PATH-REDESIGN-SUBSCRIPTION-EMPTY：无周期合约

订阅页显示说明和可选方案，不伪造已生效合约、扣款或下一次配送窗口。

PATH-REDESIGN-TRACE-BOUNDARY：履约前隐藏实际批次

商品详情和周期配送只显示已确认的公开供给摘要；实际批次和包裹追溯延后到订单/履约事实。

5. 失败与边界路径

6. 组件决策与动线关系

7. 原型交互覆盖

7.1 设计阶段新增锚点（暂不计入浏览器覆盖）

这些锚点已同步到 cases.json 与 scenario-model.json 的当前可见路径；真实后端契约和持久化仍需在实现阶段建立浏览器覆盖。

8. PATH 见证点