161 lines
7.0 KiB
Markdown
161 lines
7.0 KiB
Markdown
# Project Agent Guide
|
||
|
||
## 项目定位
|
||
|
||
这是一个面向个体户和手艺人的个人品牌小程序试点项目。当前第一个交付对象是朋友的真实品牌。
|
||
|
||
第一版的核心闭环是：
|
||
|
||
```text
|
||
品牌展示 -> 服务/作品了解 -> 客户预约或咨询 -> 管理员后台处理 -> 客户反馈
|
||
```
|
||
|
||
产品目标是帮助个人建立自己的品牌入口；后台和多品牌能力是实现手段，不要把项目优先级转向 SaaS、套餐、租户注册或平台流量。
|
||
|
||
## 必读文档
|
||
|
||
开始开发或修改需求前，按以下顺序阅读：
|
||
|
||
0. `PROJECT_STATUS.md`：当前阶段、最近提交、下一步和未决问题；跨电脑恢复时优先阅读。
|
||
1. `docs/PRD.md`：产品范围、功能需求和验收标准。
|
||
2. `docs/01-prototype-spec.md`：页面、字段、状态和交互要求。
|
||
3. `docs/02-architecture-and-decisions.md`：技术选型和架构决策。
|
||
4. `docs/03-data-and-api-design.md`：数据模型、接口边界和上传流程。
|
||
5. `docs/04-implementation-plan.md`：里程碑、测试和发布清单。
|
||
6. `docs/05-pilot-case-food-stall.md`：当前首个试点的餐饮场景假设和待确认内容。
|
||
7. `docs/06-domain-extension-strategy.md`：个人品牌核心能力与行业扩展边界。
|
||
8. `docs/07-requirements-interview-decisions.md`：首轮访谈确认的订单与客户身份规则；冲突时优先于早期文档。
|
||
9. `docs/08-clickable-prototype.md`：低保真原型入口、演练路径和边界。
|
||
|
||
## 已安装的成熟 Skills
|
||
|
||
项目当前复用以下外部 skill，不重复维护同类自定义规则：
|
||
|
||
- `playwright-testing`：仅在编写或调试 Playwright E2E 测试时使用。重点遵循用户可见角色/标签定位、Page Object、失败截图和 trace。
|
||
- `codex-review-workflow`：在用户要求代码审查、自动质量验证，或功能完成需要正式 review 时使用。默认最多执行初审和一次复审，不把它用于普通探索任务。
|
||
|
||
这两个 skill 安装在用户级 `/Users/que01/.agents/skills/`，不属于项目源码。项目规则、产品边界和技术决策仍以本文件及 `docs/` 为准。
|
||
|
||
## 当前已接受的技术决策
|
||
|
||
- Monorepo：`pnpm workspace + Turborepo`
|
||
- 小程序：原生微信小程序 + TypeScript
|
||
- 管理后台：Next.js + TypeScript
|
||
- API：NestJS + TypeScript
|
||
- 数据库：PostgreSQL
|
||
- ORM：Prisma
|
||
- 图片：S3 兼容对象存储
|
||
- 后台登录：第一版账号密码，未来可绑定微信身份
|
||
- 发布：第一版人工使用微信开发者工具发布
|
||
|
||
## 第一版范围
|
||
|
||
必须实现：
|
||
|
||
- 小程序首页、品牌介绍、服务、作品集
|
||
- 客户无需注册提交预约/咨询
|
||
- 公开内容匿名浏览；下单使用微信无感身份，并提供“我的订单”。
|
||
- 普通套餐支持数量、自取/配送和预计总价；私厨由经营者人工报价。
|
||
- 后台支持订单未读、标签和内部备忘。
|
||
- 客户提交反馈，后台审核后公开
|
||
- 后台登录和权限校验
|
||
- 品牌、服务、作品内容管理
|
||
- 预约列表、状态和内部备注
|
||
- 图片上传、预览和基本错误处理
|
||
|
||
明确不实现：
|
||
|
||
- 支付、退款、发票、财务对账
|
||
- 订单和支付状态
|
||
- 自动发布微信小程序
|
||
- 多商户注册、套餐和计费
|
||
- 多员工、多门店、复杂排班
|
||
- 会员、优惠券、营销自动化
|
||
- 自动消息通知
|
||
|
||
价格可以作为展示文本；可以预留金额字段，但不得在第一版创建支付入口或支付状态。未来支付应使用独立的 `Order`、`Payment`、`Refund` 模型，不能把支付状态塞进 `Booking`。
|
||
|
||
## 开发规则
|
||
|
||
- 先确认原型和字段，再修改数据库；不要根据临时页面直接添加字段。
|
||
- 公开 API 与管理 API 分离。
|
||
- 前端隐藏管理入口不是权限控制，所有管理接口必须服务端鉴权。
|
||
- 联系方式、预约备注等敏感数据不得从公开接口返回。
|
||
- 内容删除优先使用停用、隐藏或软删除，保留预约和审核记录。
|
||
- 新增功能必须说明用户问题、优先级、数据影响和是否影响支付兼容性。
|
||
- 不要为了未来 SaaS 过早实现租户注册、计费和复杂权限。
|
||
- 不要将品牌文案、服务和作品写死在前端代码中。
|
||
- 共享类型和状态枚举放在 `packages/`，避免前后端重复定义。
|
||
- 任何涉及真实客户数据的调试输出都必须脱敏。
|
||
|
||
## 推荐目录
|
||
|
||
```text
|
||
apps/miniapp # 微信小程序
|
||
apps/admin # Next.js 管理后台
|
||
apps/api # NestJS API
|
||
packages/types
|
||
packages/api-client
|
||
packages/validation
|
||
packages/config
|
||
prisma/
|
||
docs/
|
||
```
|
||
|
||
## 工作方式
|
||
|
||
每完成一个里程碑，都要验证对应闭环，而不是只检查页面是否能打开：
|
||
|
||
1. 后台保存品牌资料，小程序能看到更新。
|
||
2. 后台创建服务，小程序能展示并支持预约。
|
||
3. 客户提交预约，后台能看到并更新状态。
|
||
4. 客户提交反馈，后台审核后小程序才能展示。
|
||
5. 未登录用户无法修改任何管理数据。
|
||
|
||
真实朋友使用前，先完成文档中的发布前检查和数据库备份方案。试点上线后再根据实际使用频率决定是否抽象多品牌和自动化能力。
|
||
|
||
## Vibe Coding 最小规范
|
||
|
||
以下规则用于控制后续 AI 辅助开发的范围和上下文成本。
|
||
|
||
### 开始任务前
|
||
|
||
1. 先阅读本文件和与任务直接相关的文档，不要一次加载全部代码。
|
||
2. 用一句话写清楚本次任务的结果和不包含的内容。
|
||
3. 先搜索现有实现，再决定新增文件还是修改现有文件。
|
||
4. 涉及数据库、公共类型或 API 契约时，先检查调用方。
|
||
|
||
### 实现任务时
|
||
|
||
- 一次只处理一个可验证的小目标。
|
||
- 优先复用现有模式，不为单一需求新增抽象层。
|
||
- 每次修改保持在必要文件范围内，不顺手重构无关代码。
|
||
- 先实现业务闭环，再补样式、优化和扩展能力。
|
||
- 不实现 PRD 明确排除的功能，除非用户明确改变范围。
|
||
- 新增依赖前说明用途、替代方案和维护成本。
|
||
- 不把临时数据、品牌文案或密钥写死在代码中。
|
||
|
||
### 完成任务前
|
||
|
||
1. 运行与改动匹配的最小验证：类型检查、单元测试、API 测试或手工流程。
|
||
2. 检查错误状态、空状态、权限边界和重复提交。
|
||
3. 检查是否引入敏感信息、无关文件或未记录的数据库变更。
|
||
4. 用简短记录说明改了什么、为什么改、如何验证、剩余风险。
|
||
|
||
### 上下文和 token 控制
|
||
|
||
- 默认只读取完成当前任务所需的文件。
|
||
- 大文件先搜索相关符号和行号，再读取局部内容。
|
||
- 不重复输出已经确定的背景和完整代码。
|
||
- 计划超过三个步骤时，先写出短计划再执行。
|
||
- 遇到不确定的产品决策，优先依据 PRD；PRD 没有覆盖时记录假设，不要扩大实现范围。
|
||
|
||
### 任务完成定义
|
||
|
||
任务只有同时满足以下条件才算完成：
|
||
|
||
- 代码或文档已落盘。
|
||
- 相关验证已执行，或明确说明无法执行的原因。
|
||
- 变更符合第一版范围和数据/API 约束。
|
||
- 用户能根据结果继续下一步工作。
|