project-quote

name	project-quote
description	生成项目报价单、工时评估和 proposal：拆解需求、按 AI 辅助开发效率估算工作量、 维护技能清单、分析竞品或参考站点，并形成 Markdown 报价文档。当用户提到 "报价"、 "估价"、"工时评估"、"项目评估"、"开发报价"、"给客户报价"、"quote"、"estimate"、 "project proposal"、"development cost"、"更新技能清单"、"参考这个网站报价"、 "仿这个网站"、"分析竞品功能" 时触发。

项目报价技能

帮助用户系统化地评估项目开发量、拆解工作项、估算工时，最终生成一份专业的 Markdown 报价文档。

全程使用中文交互和输出。

---

AI 辅助开发效率说明

本技能的工时估算默认基于 AI 辅助开发的实际效率，而非传统人工开发经验值。

• 开发类工作（前端、后端、基础设施、测试）：工时 = 传统经验值 × 0.25
• 设计类工作（UI/UX 原型、视觉稿）：工时 = 传统经验值 × 0.5
• 项目管理、沟通协调：不受 AI 影响，按实际评估

在技能清单中，基线工时已经是 AI 辅助后的数值，无需额外换算。 如遇到首次使用某技术、需求非常不明确等场景，可适当叠加调整因子。

---

前置：加载技能清单

每次触发时，先尝试读取本技能目录下的 references/skill-inventory.md。

如果文件不存在或内容为空 → 进入首次初始化流程（见下方）。

如果文件已存在且有内容 → 加载后根据用户意图进入模式 A 或模式 B。

---

首次初始化：创建技能清单

当技能清单不存在时，系统性地询问用户的技术储备。分批提问，每次一个类别：

第一批：前端

• 你常用的前端框架有哪些？（React/Vue/Angular/Svelte/其他）
• 常用的 UI 组件库？（Ant Design/Element Plus/shadcn/Tailwind CSS/其他）
• 是否做移动端/小程序开发？用什么框架？

第二批：后端

• 常用的后端语言和框架？（Node.js + Express/Koa/Hono/NestJS、Python + Django/FastAPI、Go、Java、PHP、其他）
• 常用的 ORM/数据库工具？（Prisma/Drizzle/TypeORM/Sequelize/其他）

第三批：数据库与缓存

• 常用哪些数据库？（PostgreSQL/MySQL/TiDB/MongoDB/SQLite/其他）
• 是否使用缓存？（Redis/Memcached/其他）
• 是否使用搜索引擎？（Elasticsearch/Meilisearch/Algolia/其他）

第四批：部署与基础设施

• 常用的部署方式和平台？（Cloudflare Workers/Vercel/Netlify/Docker + 自建服务器/阿里云/腾讯云/AWS/GCP/其他）
• CI/CD 用什么？（GitHub Actions/GitLab CI/其他）
• 是否使用消息队列？（RabbitMQ/Kafka/其他）

第五批：第三方服务

• 常对接哪些第三方服务？（微信支付/支付宝/短信/邮件/微信公众号/OAuth/地图/其他）

收集完毕后：

1. 为用户提到的每种技术，生成一份操作类型 + 三档工时（简单/中等/复杂）的表格
2. 表格格式参考下面的模板
3. 展示给用户确认和调整
4. 确认后写入 references/skill-inventory.md

技能清单中每种技术的格式：

### 技术名称
| 操作类型 | 简单 | 中等 | 复杂 | 说明 |
|---|---|---|---|---|
| 操作A | Xh | Yh | Zh | 备注 |
| 操作B | Xh | Yh | Zh | 备注 |

按类别分区：前端框架、后端框架、数据库、缓存、部署平台、CI/CD、第三方服务集成。

末尾附上调整因子：

• 首次使用某技术：+30-50%
• 紧急交付：+20-30%
• 需求不明确：+20-40%
• 多语言支持：+15-25%

---

模式 A：管理技能清单

当用户想添加、修改或删除技术栈时：

1. 询问要操作的技术栈名称和类别
2. 如果是新增：列出该技术下常见的操作类型，让用户确认，然后评估三档工时
3. 如果是修改：展示当前内容，让用户指出要调整的部分
4. 如果是删除：确认后移除
5. 更新 references/skill-inventory.md

---

模式 B：项目报价（主流程）

阶段一：需求收集

如果用户提供了以前的报价文档作为参考：

• 先读取并分析该文档
• 提取格式风格、章节结构作为本次报价的参考模板
• 提取历史工时估算作为参照基准
• 后续报价中尽量保持风格一致

如果用户提供了需求文档/PRD：

• 先完整读取
• 提取关键信息后，只问补充性问题

如果都没有，分批向用户提问（每次 3-4 个）：

第一批：

• 项目名称是什么？客户名称？
• 这是什么类型的项目？（Web 应用/移动 App/小程序/API 服务/管理后台/其他）
• 简单描述一下项目的核心功能

第二批：

• 目标平台有哪些？（Web/iOS/Android/微信小程序/多端）
• UI/UX 设计是否包含在你的报价范围内，还是客户提供设计稿？
• 有没有需要对接的已有系统或第三方服务？

第三批：

• 有没有特殊的性能/可扩展性要求？
• 客户的期望交付时间是什么？
• 你的时薪费率是多少？（如果不想在文档中体现费率，可以跳过）

阶段二：项目拆解 + 技术选型

1. 将项目按 模块 → 功能项 分解：

   项目
   ├── 模块1（如：用户系统）
   │   ├── 功能1.1（如：注册/登录）
   │   ├── 功能1.2（如：个人资料管理）
   │   └── 功能1.3（如：权限管理）
   ├── 模块2（如：内容管理）
   │   └── ...
   └── 基础设施
       ├── 部署配置
       ├── CI/CD
       └── 监控
   

2. 从已加载的技能清单中，选取本项目需要的技术栈

3. 用表格展示模块拆解和技术选型，让用户确认后再进入估算

阶段三：工时评估

基于技能清单中的基线工时，结合项目实际复杂度进行估算。

输出明细表格：

序号	模块	功能项	类别	技术栈	复杂度	工时(h)	备注
1	用户系统	注册/登录	前端	React	中	12	含微信OAuth
2	用户系统	注册/登录	后端	Node.js	中	16	JWT + 微信开放平台
...

表格后附加汇总：

项目	工时(h)
开发工时小计	XXX
项目管理附加（10-15%）	XXX
风险缓冲（默认 20%，与用户讨论确定）	XXX
总工时	XXX
报价金额（总工时 × 时薪）	¥XXX

展示给用户确认。如果用户认为某项估算偏高或偏低，在此阶段调整。

阶段四：技术方案

编写简要的技术方案说明，包括：

• 前端技术选型及理由
• 后端技术选型及理由
• 数据库选型及理由
• 部署方案
• 关键第三方服务

内容不需要太深入，目的是让客户了解技术选型的合理性。

阶段五：生成 Markdown 报价文档

将所有内容整理为一份结构清晰的 Markdown 文件。

如果有参考的历史报价文档，尽量保持风格一致。

默认文档结构：

# [项目名称] 开发报价单

> 报价编号：Q-YYYY-NNN
> 日期：YYYY-MM-DD
> 编制：[用户名称]

**参考页面（如有）：**

| 页面类型 | URL |
|----------|-----|
| 首页 | https://... |
| 产品列表页 | https://... |
| 产品详情页 | https://... |
| 注册/登录 | https://... |
| 下单/结账 | https://... |
| ... | ... |

---

## 一、项目概述

[简要描述项目背景、目标和核心功能]

## 二、技术方案

[技术选型及架构概述]

## 三、工作量明细

[完整的估算表格]

## 四、项目周期

[建议的开发周期和里程碑节点]

| 阶段 | 内容 | 周期 |
|------|------|------|
| 第一阶段 | ... | X 周 |
| 第二阶段 | ... | X 周 |
| ... | | |

## 五、报价汇总

| 项目 | 数值 |
|------|------|
| 开发工时 | XXX 小时 |
| 项目管理 | XXX 小时 |
| 风险缓冲 | XXX 小时 |
| **总工时** | **XXX 小时** |
| 时薪费率 | ¥XXX/小时 |
| **总报价** | **¥XXX** |

## 六、说明与假设

- 本报价基于当前需求理解，需求变更可能影响工时和报价
- [其他假设和前提条件]
- 报价有效期：30 天

### 不含在本次报价范围内：
- [列出明确排除的内容]

询问用户文件保存路径（默认当前目录），然后写入文件。

阶段六：审核与修改

生成文档后，询问用户：

• 是否需要调整某项工时估算？
• 是否需要增加或删除工作项？
• 风险缓冲比例是否合适？
• 文档格式或措辞是否需要修改？

根据反馈修改后重新生成文档。

---

模式 C：竞品 / 参考站点分析

当用户提供一个竞品或参考站点的 URL，希望以此为基础生成报价时，执行以下流程。

步骤一：系统性遍历站点

按以下顺序访问页面，每个页面访问后立即记录其实际 URL，以及发现的功能点：

1. 首页 — 核心价值主张、产品分类入口、导航结构
2. 产品列表页 — 筛选/排序方式、产品卡片信息、分页/无限滚动
3. 产品详情页 — 规格配置选项、实时报价/计算、图稿上传、加入购物车
4. 注册/登录页 — 注册字段、OAuth 方式、B2B 审核流程（如有）
5. 用户中心 / 账户页 — 个人资料、地址管理、订单历史
6. 下单/结账流程 — 配送选项、支付方式、优惠码
7. 订单追踪页 — 状态流转、物流信息
8. 帮助中心 / FAQ — 内容结构、分类方式
9. 其他内容页 — 关于我们、联系方式、博客/案例（如有）
10. 后台/管理入口（如能访问）— 管理功能概览

遍历过程中，如果发现新的重要页面类型（如定价页、API 文档、合作伙伴页等），也一并访问并记录 URL。

步骤二：整理功能清单

将遍历结果整理为两部分：

① 参考页面 URL 表：

页面类型	URL
首页	https://...
产品列表页	https://...
产品详情页	https://...
注册/登录	https://...
...	...

② 按模块分类的功能列表：

## 模块名称

- 功能点 A（描述：具体行为或交互细节）
- 功能点 B
- ...

步骤三：建议分期规划，请用户确认

根据功能重要性和依赖关系，建议一期 / 二期拆分：

• 一期（MVP）：核心业务链路必须的功能，上线即可运营
• 二期（增强）：锦上添花、可延后的功能

以表格形式展示，让用户确认或调整：

功能点	建议分期	说明
用户注册/登录	一期	核心流程
实时报价计算	一期	核心差异化功能
Dropshipping	二期	增值服务，可延后
...

用户确认一期范围后，直接进入模式 B 的阶段二（项目拆解 + 技术选型），以确认的功能列表作为需求输入。

---

注意事项

• 不要一次性问太多问题，每次最多 3-4 个，保持对话节奏
• 工时估算要务实，参考技能清单中的基线，避免虚高或虚低
• 表格数据要一致，明细加总必须等于汇总数字
• 如果用户提供了参考文档，优先参考其格式和风格
• 报价编号按 Q-年份-序号 格式自动生成（如 Q-2026-001）
• 始终用中文，包括表头、类别名称、备注等