customer-miniapp-redesign 视觉自审记录

审查日期：2026-09-09 审查范围：当前真相包全部 HTML 页面与容器入口 设备基准：iPhone 15 Pro，393 × 852 CSS px 当前设计代数：v6.5（本轮把购买主路径收敛为买肉/计划 → 统一订单确认 → 原生支付模拟层 → 支付结果）；本轮重点：让购物车降为待选内容预览，确认页一次性承载商品、Quote、地址、配送时段和支付边界

说明：用户故事与用户动线的 v6.5 规划基线已由 basket.html、home.html、profile.html、recipes.html 和 cart.html 的设计稿共同表达；保存菜谱与计划下单仍是设计阶段扩展，不把它们误报为已进入 CASE 的后端能力。

checkout.html 与 cart.html 已在 2026-09-10 完成 v6.6 页面级重构：确认页由配送卡、订单明细卡和支付卡构成；购物车只保留可编辑商品卡与底部合计栏。

已完成的修复

• phone-shell 固定为 393 × 852 CSS px；小于 393px 时等比缩小，不产生横向滚动。
• 设备框统一采用项目已有的边框、圆角、刘海和 Home Indicator 比例。
• 页面内容在 phone frame 内独立滚动；底部五 Tab 固定在 frame 内，底部安全区预留给 Home Indicator。
• 顾客画布不再使用 notice 备注块；原型验收说明、登录边界、Quote 有效期和周期变更边界均移到 phone-shell 外的评审侧栏，不干扰手机界面截图。
• 底部 Tab 使用不透底的 raised surface 背景，滚动内容不会穿透导航栏造成重影。
• 遵循 DFD-002 的传统信息架构：只有真正的任务锚点使用浅色面；商品、服务和周期事实回到开放行列表；全局购物车恢复 52px 圆形 FAB。
• 购物车 FAB 绑定在 frame 内，并位于底部 Tab 之上；购物车页本身不重复渲染 FAB。上一轮已将它放入独立停靠区，不再与页面滚动内容共用空间。
• v6.5 计划页继续收敛为“本周状态 → 七日时间轴 → 当前餐次 → 按需选菜 / 新建 → 折叠采购清单 → 统一订单确认”的连续工作区，并在顶部提供“管理我的菜谱”的次级入口；计划固定在五栏导航中间，并用动作色高亮、抬高图标和更强文字权重建立主入口层级。买肉页继续保持直接目录：左侧分类、右侧商品图/名称/规格/固定价/加号；商品详情独立成页。首页负责分流、本周计划状态、快速下单和 Top 3 热度菜谱；购物车降为待选内容预览，不承载地址和 Quote；统一确认页承载商品、金额、地址、时段和支付边界；我的页先突出身份与 Top 2 菜谱预览，再进入稳定服务入口；完整管理集中在 recipes.html。
• 删除客户界面中的 A/B 门牌、01/02/03 步骤条和“选择路径—看清事实—再确认”等评审语言；用户动线由区块顺序和动作层级表达。
• 我的页顶部采用头像—昵称—身份行，下面先展示 Top 2 菜谱预览和“管理全部”，再进入订单、地址和一个“帮助与规则”入口；售后、配送、称重和追溯说明集中在独立页，避免无关长内容抢占身份确认。
• FAB 调整到贴近底部 Tab 的独立停靠区，避免在短视口中覆盖首页主门、计划安排区或商品行；按钮、地址和状态标签统一禁止窄屏断词。
• 商品和服务行去除默认链接下划线，保持信息行的主标题、事实说明和右侧动作分层。
• 底部五 Tab 调整为：首页、买肉、计划、订阅、我的；计划固定在中间第三位，使用日历勾选图标、抬高的动作色图标和更强文字权重，其他图标保持 21px / 1.8px 描边。
• 购物车和状态审查页不标记任何 Tab 为当前项：前者是独立路由，后者是 QA 页面，不伪造导航归属。
• 补齐商品详情、回购建议、结算、未来周期和个人服务入口的内部锚点，避免点击后落到空目标。
• 所有页面补齐 proto-meta 四字段与 proto-notes 评审侧栏，侧栏不进入手机业务画布。

结构复核

• 首页首屏顺序：配送地 → 按部位找肉 → 本周采购主任务 → 常买 SKU 快捷入口 → Top 3 热度菜谱。
• 买肉首屏顺序：页面身份 → 左侧分类 → 右侧 SKU 商品卡 → 图片/名称进详情或加号加入；页面不再放搜索、供给公告或回购卡片。
• 计划、购物车、周期配送和我的页面均不再把内部评审编号直接放入顾客界面；计划页按“本周状态 → 餐次编辑 → 菜谱选择 / 新建 → 采购清单 → 按本周计划下单”承载用户动线。
• 参考编排记录保存在 docs/design/research/customer-miniapp-reference-study.md；借鉴的是成熟零售小程序的骨架，不是促销内容。
• 首页 Top 3 热度菜谱采用一张主视觉 + 两条紧凑承接行：菜谱只负责把浏览兴趣导向当前商品，不替代“按部位找肉”或“开始做计划”的主路径。
• 首页“快速下单”保留四个圆形快捷入口的形式，但内容语义改为有购买记录用户的常买 SKU；点击只定位到买肉页当前 SKU，仍需完成事实核对和商品行加购。
• 匿名或无历史订单时，不能把默认商品展示为“个人常买”；该模块应在数据层提供明确的公开兜底标签，或暂不展示个性化常买内容。

本轮买肉目录复核

• 左侧分类切换只改变右侧 SKU 列表；首页常买 SKU 的 hash 会同步分类并高亮目标商品。
• 商品图片和名称进入 product-detail.html?sku=...；加号只加入购物车，按钮显示数量，购物车角标同步增加。
• 列表不再放搜索框、供给公告、回购建议或解释性标题，首屏焦点集中在 SKU。
• 393 / 375 / 320 三档 Chromium 检查确认分类栏、商品图、价格、加号和底部停靠区无横向溢出；详情页同样通过检查。

本轮计划页复核

• 计划页采用参考站的“一周餐桌”编排，但收敛为当前小程序的三层工作区：本周状态 → 七日时间轴与当前餐次 → 按需展开的菜谱选择和采购清单。
• 首屏第一焦点是本周状态与时间轴；“＋安排一顿”是唯一的计划编辑主入口，没有大段推荐宣言、重复状态或条件表单抢占入口。
• 七日时间轴同时展示每天的日期和安排状态；点击日期后只展开当天餐次，避免把七天内容压成一张过长列表。
• 选中日下方提供午餐/晚餐切换；已安排时显示带图片的当天菜谱卡和替换/调整/移除动作，空餐次用虚线行承接“安排一顿”。
• 菜谱选择器默认收起，只有点击空餐次的“安排一顿”后才展开；设计阶段的选择器包含“我的菜谱 / 推荐菜谱”和“新建菜谱”，新建只需要照片、配方、SKU、份量。
• 采购清单默认收起，摘要行只提示 SKU 数量和肉品需求，展开后再核对详细事实；当前原型在计划未完成时显示“完成计划后下单”，补齐条件后切换为“按本周计划确认”，直接进入统一订单确认，不再进入完整购物车页。
• 采购清单分开显示需求量、购买量、包装余量和来源餐次；计划下单需要继续进入 Quote、地址和配送确认，不能把“生成购物车”误报成订单完成。
• 全部 15 个顾客页面均检查到 5 个底部 Tab，顺序统一为 首页 / 买肉 / 计划 / 订阅 / 我的；计划为第 3 个入口，带日历勾选图标、动作色抬高图标和更强文字权重。
• 计划页的购物车 FAB 保持降级为独立入口；购物车页自身不渲染 FAB，计划与购物车没有同名或同职责内容。
• recipes.html 是独立的菜谱资产管理页；我的页只展示两条预览，计划页顶部与我的页使用同一条管理入口，不复制第二套编辑器。
• 计划页在 393 / 375 / 320 三档 Chromium 检查确认无横向溢出；320 宽度下周计划日历和底部安全区仍保持可读。

本轮我的菜谱页复核

• profile.html 的“我的菜谱”只保留最近 Top 2，标题右侧提供“管理全部”；每条预览仍可带着菜谱意图进入计划页。
• recipes.html 独立承担菜谱资产管理：顶部显示保存数量和唯一的“新建菜谱”入口，下面用开放行列表展示照片、配方、SKU、份量和编辑 / 移除 / 排入计划动作。
• 计划页顶部仅保留一个次级“管理我的菜谱”入口，位于本周状态之后，不抢时间轴和“安排一顿”的主焦点。
• 新建、编辑和移除都留在 recipes.html；“排入计划”统一回到 basket.html#arrange-*，不在个人中心再造一套计划编辑器。

本轮帮助与规则页复核

• profile.html 的帮助区域只保留一个 profile-help 入口，个人中心不再平铺售后、配送、称重和追溯说明。
• help.html 独立承载售后与帮助、配送与称重规则、追溯说明三类内容；顶部返回我的页，底部导航仍保持五栏不变。
• 393 / 320 两档 Chromium 检查确认帮助页主题入口、说明段落和底部安全区无横向溢出；从我的页点击入口可以进入帮助页，从帮助页可以返回我的页。

本轮跨页动线复核

• home → buy → product-detail → cart(可选预览) → checkout → 原生支付模拟层 → order-success → order-detail(可选) 已形成目标自选采购闭环；计划采购从 basket.html 汇总后直接进入 checkout.html。
• 待选内容预览的数量编辑会同步份数摘要、金额和订单确认路由；统一确认页继续同步商品、地址、配送时段和 Quote，不出现“改了数量、确认页又变回默认值”的断裂。
• profile → orders → order-detail → help#after-sales → orders 保留订单上下文；帮助页不再只是说明终点，售后说明能回到订单列表继续处理。
• home / buy / profile / cart / checkout 的地址入口统一进入 address.html?from=<source>，确认或返回后回到原操作，不再把地址修改误导到泛化的个人中心。
• checkout.html 改为三块稳定卡片：配送卡置顶并只显示当前地址/时段，订单明细卡承载商品与唯一应付合计，支付卡确认微信支付；地址和时段候选只在底部选择层出现，底部固定区只保留“确认并支付”动作。
• cart.html 删除来源卡、下一步教学卡、确认范围和重复数量摘要；主画布只显示已选 SKU、数量步进器和行金额，底部只显示一个合计与“去确认”。
• 点击唯一“确认并支付”动作后打开原生支付模拟层，取消/未知状态回到确认上下文，order-success.html 只表达已确认的支付结果。
• 320 宽度下确认页仍采用紧凑商品行、页内地址选择器和双列时段；底部提交栏保持应付金额、主 CTA 与导航安全区之间的清晰边界。

跨页眼位自审

眼位与意群自审

这页不是把所有能力平铺出来，而是让用户沿着“先看这一周，再处理某一天，最后生成采购”前进。以 393 × 852 为主基准，关键任务的前三个眼位如下：

这里的两个“安排一顿”不是两个并列主按钮：进度行里的 ＋安排一顿 是全局主入口，已经提升为带边框和浅色底的计划编辑动作；空餐次里的 安排一顿 + 是选中具体日期后提供的就地承接，视觉权重低于主入口，点击后直接滚动到菜谱选择器。这样既不要求用户记住当前日期，也不会让空状态失去明确动作。

本轮反向检查的结论是：时间轴承担“选哪一天”，午/晚餐切换承担“选哪一餐”，当天卡或空档承担“做什么”，折叠采购区承担“怎么买”。保存菜谱只作为第二眼位里的上下文动作，计划完成后才把“按本周计划下单”提升为第三眼位主动作；没有发现标题、推荐文案或内部解释抢在这些任务入口之前。

机械检查结果

本轮首页热度菜谱复核

• 本周热做 替换原“继续使用”模块；Top 1 使用统一暖纸色菜品图，Top 2 / Top 3 使用同一视觉语法的缩略图。
• 三个入口均落到公开商品目录或商品详情，不制造历史订单、不展示批次或结算承诺；回购不插入买肉目录。
• 393px 与 320px 视口均确认无横向溢出；滚动到菜谱模块后，Top 1 主卡、Top 2 / Top 3 紧凑行和底部导航均保持可辨识与可点击。

反证与剩余风险

• 本轮未依赖 CUA 连接；已使用 Playwright headless Chrome 完成 393×852 截图级检查，并补查 320 / 375 / 393 宽度、滚动和导航遮挡。
• 原生设备字号放大、安全区和真实触控反馈仍需在真机或已连接的浏览器中复查，重点观察长文案换行和 FAB 与内容的视觉间距。
• 浏览器 CASE/PATH 已声明，但当前真相包还没有永久 E2E spec；这不影响设计真相状态，但不能作为浏览器自动化覆盖已完成的证据。
• 320 宽度属于压力检查，不是 iPhone 15 Pro 主基准；其内容已通过截图检查，但仍需在真实小程序安全区和系统字体放大条件下复核。