## 任务目标
请验收当前微信小程序的业务流程与界面体验，以真实用户角色和本次任务目标为依据。
以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
验收流程：
小程序或页面资料：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 追踪首页、分享、扫码和历史入口的直达路径，以及返回、取消、退出后的数据状态。
- 核对表单字段、必填与默认值来源，检查成功、失效、无权限及失败恢复的真实接口依据。
- 检查主要操作、中文反馈、键盘遮挡、菜单预留、长文本和字体放大表现。
### 可采用的默认处理
- 默认只读验收并给具体调整；明确要求修复时再实施对应页面变更，不自动改变办理顺序。
- 沿用现有业务术语与视觉规范；缺规范时保持主任务清楚、操作集中、状态可理解，不补造宣传信息。
- 只有截图时仅判断可见布局及文案，导航、输入保留和提交安全分别列待交互核验。
### 必须有依据的事项
- 无法确定办理角色、业务完成条件或关键字段的真实必要性，不能自行删步骤、代填事实或判定流程正确。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 只有截图时按页面给可见问题、用户影响和具体调整，并补可执行的异常恢复验收步骤。
- 没有可运行小程序时由路由和接口状态整理任务路径及测试矩阵，区分静态证据和待真机交互。
## 执行要求
按微信内移动业务流程进行验收，页面的政企风格与中文业务文案遵循当前项目要求，不套用统一视觉模板。
1. 逐页指出用户当前要做什么、完成后去哪里以及如何返回。检查每页是否突出一个主要业务目标，导航和按钮是否能反映真实流程，清理无关宣传内容与重复引导，避免让用户在表单中被其他推荐打断。
2. 检查返回、取消和退出后的数据状态，覆盖从分享、扫码及历史入口直接进入页面。页面应能说明当前业务对象和进度，不能假设用户必定从首页按固定顺序进入。
3. 审查所有输入项是否确有必要，能选择的值优先提供明确选项，默认值必须有业务依据。字段标签、单位、格式和必填条件清晰可见，不能为了减少输入而未经用户理解就代填关键业务事实。
4. 根据操作范围设计加载和结果反馈：局部更新尽量原位反馈，耗时操作说明当前状态。错误需要足够明确且能够继续处理，不能一闪而过；成功页应说明已经完成的业务以及合适的下一步。
5. 验收网络失败、无数据、校验失败、记录失效和权限不足时的恢复路径。表单错误定位到相关项目，保留仍有效的输入；重试、修改和返回动作应与真实服务端状态匹配，避免造成重复提交。
6. 检查点击区域、控件间距、键盘遮挡、长文本、字体放大和官方菜单预留区域。保持同类组件和状态表达一致，使用真实业务内容检验对齐与换行，避免大面积装饰、花哨动效和没有含义的数据卡片。
## 交付与验收
输出：按流程排序的问题清单，每项包括页面、触发操作、用户影响、具体调整和验收条件；另给完整任务路径与异常恢复表。已有代码且用户明确要求修复时，实施必要修复并验证，只有截图时明确无法确认的交互，不把静态外观审查当成流程全部通过。
### 本条完成检查
- 按实际任务顺序输出问题、页面、触发、影响和验收条件，不用笼统审美评价替代业务问题。
- 覆盖直达、返回、取消、权限不足、记录失效和提交失败的恢复路径，确认合理输入可保留。
- 单列点击、键盘、长中文、字体放大及菜单区域检查结果，只有静态材料不得报全流程通过。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
官方来源（2026-09-08 核验）：
- [腾讯微信《微信小程序设计指南》](https://developers.weixin.qq.com/miniprogram/design/)
