---
name: quotation
description: "为微信小程序项目生成报价单和需求文档。当客户发送需求时使用此技能生成报价和产品规格。触发词: quote this, generate quotation, make a quote for, 小程序报价, quotation for, 报价, 生成报价"
user-invocable: true
---

# 小程序报价 + PRD 生成器

为每个项目生成两份交付物:
1. **报价单(客户版)** — 按功能模块的固定价格明细
2. **PRD(内部版)** — 完整的产品需求文档

两个文件都保存在 `tasks/` 目录下。

---

## 工作流程

1. 接收客户的需求描述
2. 对需求清晰度打分(0-100),通过针对性提问循环直到分数 >= 90
3. 生成 `tasks/quotation-[项目名称]-客户版.md`
4. 生成 `tasks/prd-[项目名称]-内部版.md`

**重要:** 不要开始实施。不要编写任何代码。只生成这两份文档。

---

## 阶段 1: 接收需求

接受以下任何形式的输入:
- 客户的原始消息
- 复制的需求文档
- 用户的简短口头描述

确认收到后,立即进入阶段 2。

---

## 阶段 2: 清晰度评分循环

### 评分维度 (总分 100 分)

| 维度 | 分值 | 检查内容 |
|---|---|---|
| 功能范围 | 25 | 所有功能模块是否明确列出? |
| 技术平台 | 20 | 小程序类型、后端、管理后台 — 是否全部确认? |
| UI 与交互 | 15 | 是否提供设计文件、风格指南或 UI 描述? |
| 第三方集成 | 15 | 支付、地图、推送、短信、登录 — 每项是否确认或排除? |
| 时间与预算 | 15 | 截止日期和预算范围是否都已说明? |
| 验收标准 | 10 | 上线标准和测试要求是否清晰? |

### 循环规则

- 根据已知信息诚实地计算当前分数
- **如果分数 < 90:** 显示分数,然后只询问提高分数所需的问题。使用字母选项,以便用户可以用简短代码回复,如 "1B, 2A, 3C"
- **如果分数 >= 90:** 宣布分数并进入阶段 3
- 每次用户回复后重新评分。重复直到 >= 90

### 提问格式

```
当前清晰度得分: 62/100

要达到 90+ 分,我需要以下问题的答案:

1. 项目范围包括哪些平台?
   A. 仅微信小程序
   B. 小程序 + 后端 API
   C. 小程序 + 后端 + 管理后台
   D. 其他: [请说明]

2. 是否需要支付功能?
   A. 是 — 微信支付
   B. 是 — 第三方支付(支付宝/Stripe/其他)
   C. 不需要支付
   D. 待定

3. 是否有设计文件或 UI 参考?
   A. 有 — Figma / MasterGo 文件
   B. 有 — 截图或草图
   C. 没有 — 遵循常见风格(请描述)
   D. 没有 — 由开发者决定

4. 预期交付期限是?
   A. 2 周以内
   B. 2-4 周
   C. 1-2 个月
   D. 灵活/待定

5. 大致预算范围是?
   A. 1万元以下
   B. 1-3万元
   C. 3-8万元
   D. 8万元以上/待定
```

---

## 阶段 2.5: 价格确认

**重要:** 达到清晰度分数 >= 90 后,不要立即生成报价单。首先与用户(开发者/自由职业者)确认价格。

### 步骤 1: 评估复杂度并建议价格

根据收集的需求,评估项目复杂度:

- **简单 (¥3,000-8,000):** 基础 CRUD,简单列表/详情页,标准登录,无复杂逻辑
- **中等 (¥10,000-15,000):** 自定义业务规则,多角色管理,数据统计,第三方集成(非支付)
- **复杂 (¥15,000-20,000):** 支付系统,实时功能,高级算法,多租户 SaaS,硬件集成
- **AI 集成:** +¥20,000-30,000 (单独计算)

### 步骤 2: 展示建议价格并请求确认

显示建议价格并询问用户是否需要调整。

**格式:**

```
根据需求分析,我评估这是一个[复杂度级别]项目。

建议报价: ¥[金额]

理由:
- [关键复杂度因素 1]
- [关键复杂度因素 2]
- [关键复杂度因素 3]

这个价格可以用于您的报价单吗?

A. 可以,使用 ¥[金额]
B. 调整为: ¥[请说明您的目标价格]
```

### 步骤 3: 处理用户响应

- **如果用户接受 (A):** 使用建议价格进入阶段 3
- **如果用户提供自定义价格 (B):** 使用用户的目标价格,在阶段 3 中按比例分配到各功能模块

**关键:** 分配自定义价格时,确保:
- 总价与用户目标价格完全匹配
- 模块价格与其复杂度/工作量成比例
- 没有模块价格看起来不合理地低(每个模块最低 ¥500)
- 明细仍然看起来专业且合理

---

## 阶段 3: 生成报价单文档 (客户版)

**保存到:** `tasks/quotation-[项目名称]-客户版.md`

**重要:**
- 此文档面向客户
- 使用中文书写
- 使用专业、客户友好的语言
- 关注价值和交付成果,而非技术实现细节

每个部分都填写真实内容 — 不要使用占位符文本。

```markdown
# 报价单: [项目名称]

**客户:** [客户名称或"待定"]
**制作方:** [您的名字/团队]
**日期:** [今天的日期]
**有效期:** 自上述日期起 30 天

---

## 1. 项目概述

[1-2 句话描述项目及其主要目的。]

---

## 2. 需求摘要

[简明段落确认理解的范围。这是范围争议的唯一真实来源。]

---

## 3. 功能模块明细

| # | 模块 | 说明 | 预估工时 | 价格(元) |
|---|------|------|---------|---------|
| 1 | [模块名称] | [功能说明] | [小时] | [¥] |
| 2 | ... | ... | ... | ... |

> 工时仅供内部参考。客户看到的是模块价格,而非小时费率。

---

## 4. 技术方案

**关键: 本项目使用腾讯云开发 CloudBase,无需购买服务器和域名**

| 层级 | 技术 | 理由 |
|------|------|------|
| 小程序端 | 微信原生小程序 / uni-app | [原因] |
| 后端 | 腾讯云开发 CloudBase | 云函数 + 云数据库一体化,按量付费,无需运维 |
| 数据库 | CloudBase 云数据库 | 与小程序无缝集成,自动扩容 |
| 存储 | CloudBase 云存储 | 图片/文件存储,CDN 加速 |
| 第三方 | [列出集成] | — |

---

## 5. 项目时间表

| 阶段 | 交付成果 | 工期 |
|------|---------|------|
| 需求与设计 | 确认 PRD + UI 原型 | [n] 天 |
| 开发 — 核心功能 | [关键模块] | [n] 天 |
| 开发 — 集成 | 第三方 API、后端 | [n] 天 |
| 测试与修复 | UAT + 修复 | [n] 天 |
| 上线与交付 | 部署 + 文档 | [n] 天 |
| **总计** | | **[n] 天** |

---

## 6. 价格汇总

| 项目 | 价格(元) |
|------|---------|
| [模块组 1] | ¥[x] |
| [模块组 2] | ¥[x] |
| **总计** | **¥[总价]** |

---

## 7. 付款条款

| 里程碑 | 百分比 | 金额(元) |
|--------|-------|---------|
| 合同签署(定金) | 30% | ¥[x] |
| 开发完成并验收 | 60% | ¥[x] |
| 质保期结束(上线后 1 个月) | 10% | ¥[x] |

---

## 8. 不包含项目(排除项)

- UI/UX 设计费用(除非在第 3 节中明确列出)
- 微信小程序认证费: ¥300/年(由客户支付)
- CloudBase 年度使用费: 约 ¥240/年(按量付费)
- 第三方 API 订阅费用(地图、短信、支付网关手续费)
- 持续内容管理或运营支持
- 第 3 节中未列出的任何功能
- AI 集成(腾讯 LLM + 知识库): 如需要 +¥20,000-30,000

---

## 9. 质保与上线后支持

- 上线后 **1 个月** 免费 bug 修复支持
- 由我们代码引起的 bug 免费修复
- 上线后的新功能需求单独报价
- 最终付款后交付源代码
```

### 定价参考(内部 — 关键: 遵循这些标准)

**开发模式与价格区间:**

| 模式 | 范围 | 价格区间(元) |
|------|------|-------------|
| 模板化 | 基础信息展示,现有模板 | ¥3,000 – ¥5,000 |
| SaaS 化 | 模块化功能,快速上线 | ¥4,000 – ¥8,000 |
| 定制开发(简单) | 标准功能,低复杂度 | ¥8,000 – ¥10,000 |
| 定制开发(中等) | 复杂逻辑,多模块 | ¥10,000 – ¥15,000 |
| 定制开发(复杂) | 高级功能,高复杂度 | ¥15,000 – ¥20,000 |
| 二次开发 | 现有系统扩展 | 原成本的 30% – 60% |
| AI 集成 | 腾讯 LLM + 知识库 | +¥20,000 – ¥30,000(单独) |

**如何分类项目:**

**模板化 (¥3,000-5,000):**
- 使用现有小程序模板(如模板市场)
- 只需内容更改: 文字、图片、颜色、联系方式
- 不需要自定义业务逻辑
- 标准功能按原样工作(如公司简介、产品目录、新闻列表)
- 示例: 企业官网、产品展示、简单信息展示
- **关键指标:** 客户说"我看到一个模板很喜欢,只需改内容"

**SaaS 化 (¥4,000-8,000):**
- 基于现有 SaaS 平台构建(如预约 SaaS、表单构建器、会员 SaaS)
- 模块化功能可开关
- 有一定配置灵活性,但核心逻辑固定
- 不需要自定义数据库设计
- 示例: 标准预约系统、表单收集、简单会员
- **关键指标:** 功能常见且可用现有 SaaS 工具解决

**定制开发 - 简单 (¥8,000-10,000):**
- 从零构建,但逻辑简单
- 基础 CRUD 操作(创建、读取、更新、删除)
- 简单列表/详情页
- 标准登录(微信授权或手机)
- 无复杂业务规则或计算
- 示例: 简单任务列表、基础库存、联系人管理
- **关键指标:** "只需存储和显示数据,无特殊规则"

**定制开发 - 中等 (¥10,000-15,000):**
- 自定义业务规则和验证逻辑
- 多角色管理(用户 vs 管理员,不同权限)
- 数据统计和报表
- 第三方集成(非支付: 地图、短信、二维码)
- 多状态工作流(如待处理 → 已批准 → 已完成)
- 示例: 带规则的课程预约、订单管理、审批工作流
- **关键指标:** "用户只能在满足 Y 条件时执行 X" 或 "需要跟踪状态变化"

**定制开发 - 复杂 (¥15,000-20,000):**
- 支付系统(微信支付、支付宝集成)
- 实时功能(聊天、实时更新、WebSocket)
- 高级算法(匹配、推荐、调度)
- 多租户 SaaS 架构
- 硬件集成(IoT 设备、打印机、扫描仪)
- 复杂数据关系和计算
- 示例: 带支付的电商、实时聊天、匹配平台
- **关键指标:** "需要支付处理" 或 "实时同步" 或 "复杂计算"

**快速决策树:**

1. 能用现有模板只改内容吗? → **模板化**
2. 能用现有 SaaS 平台吗? → **SaaS 化**
3. 需要定制开发,但逻辑是简单 CRUD? → **定制简单**
4. 有自定义业务规则、多角色或工作流? → **定制中等**
5. 有支付、实时或高级算法? → **定制复杂**

**复杂度评估指南:**

- **简单 (¥3,000-8,000):** 基础 CRUD,简单列表/详情页,标准登录,无复杂逻辑
- **中等 (¥10,000-15,000):** 自定义业务规则,多角色管理,数据统计,第三方集成(非支付)
- **复杂 (¥15,000-20,000):** 支付系统,实时功能,高级算法,多租户 SaaS,硬件集成

**固定成本(必须在报价单中提及):**

- 微信小程序认证: ¥300/年(由客户支付)
- CloudBase 年度成本: 约 ¥240/年(按量付费,典型使用量)

**关键技术栈规则:**

- **始终使用腾讯云开发 CloudBase** 作为后端
- **无需购买服务器,无需购买域名** — CloudBase 处理一切
- **必须在报价单中明确说明:** "本项目使用腾讯云开发 CloudBase,无需购买服务器和域名"

---

## 阶段 4: 生成 PRD 文档 (内部版)

**保存到:** `tasks/prd-[项目名称]-内部版.md`

**重要:**
- 此文档面向开发者自己
- 使用中文书写
- 包含技术实现细节
- 将此作为开发蓝图

在报价单之后立即生成。严格遵循以下结构:

```markdown
# PRD: [项目名称]

## 简介

[简要描述产品及其解决的问题。]

## 目标

- [可衡量的目标 1]
- [可衡量的目标 2]

## 用户故事

### US-001: [标题]
**描述:** 作为[用户类型],我想要[功能],以便[收益]。

**验收标准:**
- [ ] [具体可验证的标准]
- [ ] [另一个标准]
- [ ] 类型检查/代码检查通过
- [ ] **[UI 故事]** 在微信开发者工具中验证

### US-002: ...

## 功能需求

- FR-1: [系统必须...]
- FR-2: [当用户执行 X 时,系统必须...]

## 非目标

- [本项目不包含的内容]

## 设计考虑

- [UI/UX 注意事项、设计文件链接、组件复用提示]

## 技术考虑

- [约束条件、集成点、性能目标]

## 成功指标

- [如何衡量成功,例如:"订单完成率 > 80%"]

## 待解决问题

- [开发前或开发期间需要解决的未知问题]
```

### PRD 编写规则

- 为初级开发者或 AI 代理编写 — 明确具体,避免术语。
- 用户故事必须足够小,可以在一次专注的会话中实现。
- 验收标准必须可验证。"正常工作"是不好的。"点击支付在 1 秒内显示微信支付界面"是好的。
- 为所有功能需求编号(FR-1, FR-2 ...)以便引用。
- 每个包含 UI 组件的故事都必须包含微信开发者工具验证步骤。
- PRD 用户故事必须与报价单功能模块一一对应。
- PRD 中的非目标必须与报价单中的排除项匹配。

---

## 输出检查清单

完成前验证:

- [ ] 生成文档前清晰度分数达到 >= 90
- [ ] `tasks/quotation-[项目名称]-客户版.md` 已保存,所有 9 个部分都已填写
- [ ] `tasks/prd-[项目名称]-内部版.md` 已保存,包含所有标准 PRD 部分
- [ ] 两个文件中都没有占位符文本
- [ ] 定价反映实际模块复杂度,而非通用默认值
- [ ] PRD 用户故事与报价单功能模块一一对应
- [ ] PRD 中的非目标与报价单中的排除项匹配
