# Stitch 移动端提示词

目标：让订单胶囊各页面沿用同一套排版与组件语言。微信原生控件提供实现基础，设计 Token 约束视觉，页面提示词约束信息组织。

## 使用方法

1. 使用同一 Stitch 项目「订单胶囊 · 小程序」`2773591929840013591`，设备选 MOBILE。
2. 将 [STITCH-DESIGN.md](STITCH-DESIGN.md) 作为设计系统资料。文件由真实主题源自动生成；数值变化后重新生成，避免复制旧颜色与圆角。
3. 布局参考原稿 `1bb0397d959a4b82a2c8b4b86bac9e04`；状态色与图标优先参考用户于 2026-10-27 确认的精修稿 `e2542ca0d0e3403db91ae6b35377c52d`（Stitch 原标题仍含「待评审」）。明确只继承表面、排版、状态语义与图标规范，不照搬订单列表的字段到其他页面。
4. 生成时显式选择本项目的小程序设计系统 `assets/7141006746995806822`，不要仅依赖项目旧的默认主题。MCP 调用必须传 `designSystem: "assets/7141006746995806822"`；页面侧在 DESIGN.md 列表选择这套规范。先核对实际回读与本文件一致，本地文件更新不代表云端设计系统自动更新。
5. 页面提示词只写任务、结构、内容、状态和交互。颜色、字体、圆角等视觉数值交给设计系统，避免两处互相冲突。
6. 一次一个页面、一个主要状态。先确定信息结构，再一次修改一两处；不要在同一轮同时补功能、换配色、改字号和重排全页。

当前完整规则见 [DESIGN.md](DESIGN.md)：新稿沿用原生控件与单层分组；旧稿中的大 TP 标题、密集描边按钮和卡片阴影不再作为通用视觉要求。业务信息和权限仍以当前 PRD 为准，不因换用新样式被删减。

没有绑定设计系统时，先提供设计规范及参考图，再发送页面任务。不能只输入模糊的风格形容词。

同步完成必须有两类证据：`list_design_systems` 回读的资产正文、主题与样式规则正确；新稿的 `designSystem.name` 指向上述资产，并且画布与导出稿符合单层表面等规则。接口返回 session、编辑器暂时显示新文字或生成建议，都不能单独算作同步完成。核对稿标记「待评审」，不把它当成业务方案确认或正式页面验收。

## 通用前缀

以下内容放在每张页面任务之前，方括号替换为本页事实：

> 为订单胶囊微信小程序设计「[页面名称]」。当前用户是[角色]，来到这里要[主要任务]；本次展示[具体状态]。
>
> 沿用本项目已绑定的移动端设计系统，并参考「我的订单 · 去嵌套与轻量卡片（精修）」的单层表面和文字层级。使用适合微信原生实现的分组列表、表单和操作结构。
>
> 平台：MOBILE，390 CSS px 宽，单列。只输出这一张页面。使用微信系统导航区域，无手机机身、页面外说明或桌面布局。
>
> 信息按主标题、辅助资料和次要元数据分层。默认使用连续列表行；必要的独立业务分组共用一级表面，内部不套卡。通过对齐、留白和弱分隔线表达归属，不通过给每个字段套框表达归属。
>
> 任务区只有一个突出主操作，复制、查看文件等辅助操作采用图标文字。操作名称完整，编号完整；长内容自然换行，不缩小整页来塞入首屏。
>
> 状态与图标严格执行设计系统的语义矩阵与用途映射：当前进行、等待、成功、失败、未开始／已跳过不可混用。保存、识别和步骤完成分别反馈。派车单动作文字与确认状态分别着色。小图标沿用项目图形语言与固定尺寸、线宽、图文对齐；导出使用可实际渲染的 SVG，不露出英文图标名、缺字方块或 emoji。
>
> 本页严格使用下述内容和流程，不新增统计、营销文案、装饰图形、字段、角色或业务规则。示例数据均为虚构，示例状态不代表真实业务已完成。

## 页面示例：我的订单

与通用前缀组合使用：

> 用户：创建者／货主，正在查找自己创建的订单。展示按合集浏览的状态，其中一个合集展开。
>
> 1. 微信顶栏标题「我的订单」，右侧系统胶囊；无角色切换。
> 2. 一条搜索输入「搜索订舱号、车牌、客户」，右侧文字入口「查询TP」。下方左侧为「按合集／按单柜」下划线切换，选中按合集；右侧为「全部日期⌄」「批量管理」两项文字操作。
> 3. 正文两个一级分组：展开的两柜合集，以及一张独立订单。不为合集成员增加第二层表面。
> 4. 合集组头：主标题「COSU641820」，右侧折叠箭头；下面依次为「远航贸易 · 2柜」、普通资料行「总TP TP20261027A1B2C3D4E5F6」、地点「宁波北仑集货仓」。
> 5. 第一条成员：主行左侧「COSU641820-1」，右侧普通状态文字「装货中」；次行「浙B·A1234 · 10月27日」；随后完整 TP「TP2026102701A2B3C4D5E6」。底部一行左侧文件入口「派车单 · 待确认 ›」，右侧「复制TP」「分享单柜」图标文字操作。
> 6. 第二条成员结构一致：编号「COSU641820-2」、状态「待提柜」、资料「浙B·B5678 · 10月28日」、TP「TP2026102711A2B3C4D5E6」、文件「派车单 · 已确认 ›」。成员之间仅一条弱分隔线。
> 7. 合集组尾：左侧轻量「复制总TP与说明」，右侧紧凑主操作「分享合集」。
> 8. 独立订单组头「COSU783120-1」，右侧「待提柜」；随后「海川贸易 · 浙B·C9012 · 10月28日」、地点「宁波镇海装货仓」、TP「TP2026102721A2B3C4D5E6」、文件入口「派车单 · 待确认 ›」。组尾左侧「复制TP与说明」，右侧主操作「分享订单」。
> 9. 固定底部三入口「创建订单／我的订单／我的」，选中我的订单；正文留足安全距离。
>
> SO、车牌、当前阶段容易扫描；TP为次级但可读的普通文本。状态不做药丸，文件入口不做按钮框。不要把TP、文件和成员画成独立小卡片。派车单是模板生成的文件入口，没有上传按钮。完整TP精确抄写，不使用省略号。

## 页面示例：手动建单

与通用前缀组合使用：

> 用户：创建订单的人。任务：填写并核对订单资料。本次只展示必填资料已填写、选填资料未填写的编辑状态。
>
> 微信导航标题「手动建单」。正文按照「基础调度信息」「装货与箱柜信息 · 选填」「作业要求」组织，字段明细与必填/选填从当前 PRD 的建单字段表读取，不从参考列表推测。
>
> 每个分组由标题和连续字段组成，标签在输入区域上方。输入区域有清楚的可编辑感，不把整个字段再包成一张卡片；帮助和错误在对应字段下方。
>
> 作业要求只展示「需要过磅」开关，默认关闭，旁边说明「创建后无法更改」。底部突出「确认创建订单」；原始资料用弱入口查看，不与主操作争夺注意力。
>
> 长表单自然滚动，输入与按钮避开安全区。只展示当前编辑状态，不把成功、错误和加载三种状态堆在一屏。

## 定向修改：再次出现套框时

> 本轮只调整容器层级，保留所有业务文案、字段顺序、数据和操作。
> 保留[明确列出需要保留的一级分组]，移除组内成员、TP、状态及文件入口的独立背景、圆角、描边和阴影。移除的容器用连续行、对齐、留白及弱分隔线代替。
> 输入框保留可编辑反馈，错误和焦点保留必要边界。不要把移除边框理解为删除输入区或隐藏状态。

## 定向修改：操作过重时

> 本轮只调整操作权重。保留[主操作名称]为突出主操作；把[复制/文件入口等具体名称]改为图标文字，文字完整。保持正文结构、字段值与设计系统不变，不额外增加按钮或说明。

## 定向修改：状态色或图标不一致时

> 本轮只校正状态语义与图标，保留信息结构、字段、真实状态和原有操作。按设计系统逐项匹配进行、等待、已确认、失败、中性状态；不要把正常待提柜画成错误、把已跳过画成成功、把原图已保存画成识别成功或整单完成。
> 派车单的文件入口与确认状态分别表达，复制和分享仍是动作。状态文字完整，订单阶段不新增彩色药丸或逐行装饰图标。
> 同类图标保持相同尺寸、笔画和图文间距；搜索、地点、文件、复制、分享、折叠与三项底部导航沿用设计系统映射。用实际可见的 SVG 图形替换英文图标名和缺字，不加载额外图标字体、不混搭 emoji，不用旋转加载图标表示业务装货中。

## 稿件评审要点

- 首先能识别本页任务及主要动作，再扫描辅助资料。
- 一个业务路径最多一层卡片；业务层级没有被机械翻译成容器层级。
- 图标、文字、行距和左右边界一致；TP等完整编号可读，次操作没有变成一排小方框。
- 状态色与状态文字逐项符合语义矩阵；同语义跨页一致，保存、识别与步骤完成没有混写；派车单待确认与已确认可区分。
- 图标用途、尺寸、线宽、间距与首行对齐一致，导出截图实际显示图形，没有英文名称、缺字、拉伸或裁切。
- 主要、辅助、弱提示三种权重有区分，必要信息不会淡到难读。
- 页面只出现指定角色、状态、字段与流程；没有借设计补充业务假设。
- 记录稿件状态和屏幕 ID。设计规范、设计稿、代码、真机验收分别确认，不能互相替代。