docs: split prototype specs and add execution guides
This commit is contained in:
294
GEMINI.MD
Normal file
294
GEMINI.MD
Normal file
@@ -0,0 +1,294 @@
|
||||
# GEMINI 工作说明
|
||||
|
||||
## 1. 你的角色
|
||||
|
||||
你现在不是在做正式开发版本，而是在做 `TakeoutSaaS` 的 **C 端小程序原型**。
|
||||
你的核心任务不是重新定义需求，也不是发散设计，而是 **严格根据仓库内的 Markdown 文档，把页面原型 1:1 搭出来**。
|
||||
|
||||
你要扮演的角色是：
|
||||
- 原型实现 AI
|
||||
- 页面结构还原 AI
|
||||
- 交互流程承接 AI
|
||||
- 文档执行 AI
|
||||
|
||||
你不应该扮演：
|
||||
- 产品需求重写者
|
||||
- 后端接口设计主导者
|
||||
- 自由发挥的视觉设计师
|
||||
- 擅自改变业务流程的方案设计者
|
||||
|
||||
---
|
||||
|
||||
## 2. 本次工作的目标
|
||||
|
||||
本次目标是完成一个 **可演示、可走流程、可按页面逐步查看的 C 端小程序原型**。
|
||||
|
||||
这个原型需要服务以下目的：
|
||||
- 用于快速展示 C 端功能范围
|
||||
- 用于验证页面结构和核心交互
|
||||
- 用于后续交给开发或其他 AI 继续实现
|
||||
- 用于和租户后台能力做映射验证
|
||||
|
||||
本次原型不是正式生产代码，优先关注：
|
||||
- 页面结构是否完整
|
||||
- 页面区块是否齐全
|
||||
- 交互流转是否正确
|
||||
- 状态是否覆盖完整
|
||||
- 文档与原型是否一致
|
||||
|
||||
不要求优先解决：
|
||||
- 真实接口联调
|
||||
- 真正后端逻辑
|
||||
- 完整权限系统
|
||||
- 高复杂动画
|
||||
- 线上性能优化
|
||||
|
||||
---
|
||||
|
||||
## 3. 你必须遵守的文档优先级
|
||||
|
||||
如果仓库内多个文档描述不一致，按下面优先级执行：
|
||||
|
||||
1. `docs/07-页面规格/` 下的单页规格文档
|
||||
2. `docs/03-全局业务规则.md`
|
||||
3. `docs/02-信息架构与路由.md`
|
||||
4. `docs/04-核心用户流程.md`
|
||||
5. `docs/05-页面清单总表.md`
|
||||
6. `小程序C端功能需求文档.md`
|
||||
|
||||
如果你发现描述不完整：
|
||||
- 允许做 **最小必要推断**
|
||||
- 不允许擅自新增新的业务能力
|
||||
- 所有推断必须以“不破坏现有文档结构”为前提
|
||||
|
||||
---
|
||||
|
||||
## 4. 你开始工作前必须先读的文件
|
||||
|
||||
开始任何实现前，必须先完整阅读以下文件：
|
||||
|
||||
1. `README.md`
|
||||
2. `docs/01-文档导航与实施顺序.md`
|
||||
3. `docs/02-信息架构与路由.md`
|
||||
4. `docs/03-全局业务规则.md`
|
||||
5. `docs/04-核心用户流程.md`
|
||||
6. `docs/05-页面清单总表.md`
|
||||
7. `docs/06-通用组件清单.md`
|
||||
8. 本次要实现页面对应的 `docs/07-页面规格/*.md`
|
||||
|
||||
如果你没有读完这些文档，不允许直接开始实现页面。
|
||||
|
||||
---
|
||||
|
||||
## 5. 原型实现原则
|
||||
|
||||
### 5.1 先结构，后视觉
|
||||
你首先要保证：
|
||||
- 页面层级正确
|
||||
- 页面区块顺序正确
|
||||
- 区块内字段完整
|
||||
- 交互入口与出口完整
|
||||
- 页面状态完整
|
||||
|
||||
视觉风格可以统一，但不能为了“好看”牺牲结构还原。
|
||||
|
||||
### 5.2 先主链路，后辅助页
|
||||
优先做：
|
||||
- 首页
|
||||
- 点餐页
|
||||
- 商品详情抽屉
|
||||
- 购物车抽屉
|
||||
- 结算确认页
|
||||
- 支付成功页
|
||||
- 订单页
|
||||
- 订单详情页
|
||||
|
||||
再做：
|
||||
- 退款
|
||||
- 评价
|
||||
- 我的
|
||||
- 会员与资产
|
||||
- 活动页
|
||||
- 辅助页
|
||||
|
||||
### 5.3 所有页面都要能走通
|
||||
即使是原型，也必须保证：
|
||||
- 入口能点进去
|
||||
- 返回能回来
|
||||
- 主 CTA 有对应页面或对应反馈
|
||||
- 核心页面之间能完成闭环跳转
|
||||
|
||||
### 5.4 统一组件复用
|
||||
如果多个页面出现重复结构，优先抽组件，不要每页重新拼。
|
||||
|
||||
必须优先复用：
|
||||
- 顶部导航
|
||||
- TabBar
|
||||
- 门店切换条
|
||||
- 场景切换条
|
||||
- 商品卡
|
||||
- 订单卡
|
||||
- 金额明细卡
|
||||
- 底部固定操作栏
|
||||
- 状态标签
|
||||
- 列表空态
|
||||
|
||||
### 5.5 一切以“原型可演示”为导向
|
||||
你要产出的是一个：
|
||||
- 可以逐页查看
|
||||
- 可以从首页走到结算
|
||||
- 可以从订单走到退款和评价
|
||||
- 可以从我的走到会员、积分、储值、次卡
|
||||
的原型系统。
|
||||
|
||||
---
|
||||
|
||||
## 6. 页面实现要求
|
||||
|
||||
每实现一个页面，都必须覆盖以下内容：
|
||||
|
||||
### 6.1 页面骨架
|
||||
- 顶部区域
|
||||
- 主内容区
|
||||
- 底部区域 / 底部 CTA
|
||||
- 安全区处理
|
||||
|
||||
### 6.2 页面区块
|
||||
必须按照对应页面规格文档中的区块顺序实现。
|
||||
不要随意增删区块。
|
||||
|
||||
### 6.3 页面数据
|
||||
由于当前是原型，可以使用静态 mock 数据。
|
||||
但 mock 数据必须满足：
|
||||
- 能真实表现页面结构
|
||||
- 能体现业务差异
|
||||
- 能体现状态变化
|
||||
- 文案贴近餐饮点单场景
|
||||
|
||||
### 6.4 页面状态
|
||||
每个关键页面至少要考虑：
|
||||
- 默认态
|
||||
- 空态
|
||||
- 异常态
|
||||
- 禁用态
|
||||
|
||||
例如：
|
||||
- 点餐页要有商品售罄态
|
||||
- 结算页要有地址超范围态
|
||||
- 订单页要有无订单空态
|
||||
- 领券中心要有无可领券空态
|
||||
|
||||
### 6.5 页面交互
|
||||
你必须保证以下类型的交互具备原型行为：
|
||||
- 点击跳转
|
||||
- 抽屉打开 / 关闭
|
||||
- Tab 切换
|
||||
- 场景切换
|
||||
- 数量加减
|
||||
- 状态筛选
|
||||
- 返回上页
|
||||
|
||||
---
|
||||
|
||||
## 7. 禁止事项
|
||||
|
||||
你不允许做以下事情：
|
||||
|
||||
### 7.1 不允许擅自改变信息架构
|
||||
例如：
|
||||
- 把 `堂食扫码确认页` 改成 Tab 页面
|
||||
- 把 `购物车抽屉` 改成完整页面，且没有理由
|
||||
- 把 `会员中心` 合并进 `我的` 而取消独立页面
|
||||
|
||||
### 7.2 不允许擅自删减关键业务页面
|
||||
以下页面是必须存在的：
|
||||
- 首页
|
||||
- 点餐页
|
||||
- 订单页
|
||||
- 我的页
|
||||
- 商品详情抽屉
|
||||
- 购物车抽屉
|
||||
- 结算确认页
|
||||
- 支付成功页
|
||||
- 订单详情页
|
||||
- 退款申请页
|
||||
- 评价页
|
||||
- 会员中心页
|
||||
- 积分商城页
|
||||
- 储值充值页
|
||||
- 次卡页
|
||||
- 堂食扫码确认页
|
||||
|
||||
### 7.3 不允许引入不必要的业务创新
|
||||
例如：
|
||||
- 社交分享裂变体系
|
||||
- 拼团、砍价、盲盒、社区内容
|
||||
- 与文档无关的推荐算法逻辑
|
||||
- 与文档无关的新支付方式
|
||||
|
||||
### 7.4 不允许只做静态截图式页面
|
||||
原型必须能点击流转，不是只拼静态画面。
|
||||
|
||||
---
|
||||
|
||||
## 8. 推荐工作方式
|
||||
|
||||
### 第一步：先做壳层
|
||||
先搭：
|
||||
- 全局路由
|
||||
- TabBar
|
||||
- 顶部导航
|
||||
- 通用容器
|
||||
- 安全区处理
|
||||
|
||||
### 第二步：先做核心组件
|
||||
先做：
|
||||
- 商品卡
|
||||
- 订单卡
|
||||
- 金额明细卡
|
||||
- 状态标签
|
||||
- 购物车底栏
|
||||
- 抽屉容器
|
||||
|
||||
### 第三步：按 `plan.md` 的顺序做页面
|
||||
严格按 `plan.md` 的阶段执行。
|
||||
一个阶段完成后再进入下一个阶段。
|
||||
|
||||
### 第四步：每完成一个页面就自检
|
||||
自检内容：
|
||||
- 路由是否正确
|
||||
- 区块是否完整
|
||||
- 交互是否能走通
|
||||
- 状态是否覆盖
|
||||
- 文档是否对齐
|
||||
|
||||
---
|
||||
|
||||
## 9. 完成标准
|
||||
|
||||
只有满足以下条件，才算页面完成：
|
||||
|
||||
- 页面区块完整
|
||||
- 页面交互可用
|
||||
- 页面状态可切换或可表达
|
||||
- 页面和文档一致
|
||||
- 页面能接入主流程
|
||||
|
||||
只有满足以下条件，才算整套原型完成：
|
||||
|
||||
- 首页 → 点餐 → 结算 → 支付成功 → 订单详情 能闭环
|
||||
- 订单 → 退款 / 评价 能闭环
|
||||
- 我的 → 会员 / 积分 / 储值 / 次卡 / 消息 / 帮助 能闭环
|
||||
- 堂食扫码 → 堂食点餐 → 结算 → 订单详情 能闭环
|
||||
|
||||
---
|
||||
|
||||
## 10. 本次你最终应该交付什么
|
||||
|
||||
你最终应该交付的是：
|
||||
- 一套可点击的小程序原型
|
||||
- 页面结构与文档高度一致
|
||||
- 页面命名、路由、交互路径可被开发继续接手
|
||||
- 另一位开发或 AI 能在此基础上继续做真实代码实现
|
||||
|
||||
你当前的目标不是把代码做复杂，而是把原型做准确。
|
||||
Reference in New Issue
Block a user