| 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/地图/其他）
收集完毕后：
- 为用户提到的每种技术，生成一份操作类型 + 三档工时（简单/中等/复杂）的表格
- 表格格式参考下面的模板
- 展示给用户确认和调整
- 确认后写入
references/skill-inventory.md
技能清单中每种技术的格式：
### 技术名称
| 操作类型 | 简单 | 中等 | 复杂 | 说明 |
|---|---|---|---|---|
| 操作A | Xh | Yh | Zh | 备注 |
| 操作B | Xh | Yh | Zh | 备注 |
按类别分区：前端框架、后端框架、数据库、缓存、部署平台、CI/CD、第三方服务集成。
末尾附上调整因子：
- 首次使用某技术：+30-50%
- 紧急交付：+20-30%
- 需求不明确：+20-40%
- 多语言支持：+15-25%
模式 A：管理技能清单
当用户想添加、修改或删除技术栈时：
- 询问要操作的技术栈名称和类别
- 如果是新增：列出该技术下常见的操作类型，让用户确认，然后评估三档工时
- 如果是修改：展示当前内容，让用户指出要调整的部分
- 如果是删除：确认后移除
- 更新
references/skill-inventory.md
模式 B：项目报价（主流程）
阶段一：需求收集
如果用户提供了以前的报价文档作为参考：
- 先读取并分析该文档
- 提取格式风格、章节结构作为本次报价的参考模板
- 提取历史工时估算作为参照基准
- 后续报价中尽量保持风格一致
如果用户提供了需求文档/PRD：
如果都没有，分批向用户提问（每次 3-4 个）：
第一批：
- 项目名称是什么？客户名称？
- 这是什么类型的项目？（Web 应用/移动 App/小程序/API 服务/管理后台/其他）
- 简单描述一下项目的核心功能
第二批：
- 目标平台有哪些？（Web/iOS/Android/微信小程序/多端）
- UI/UX 设计是否包含在你的报价范围内，还是客户提供设计稿？
- 有没有需要对接的已有系统或第三方服务？
第三批：
- 有没有特殊的性能/可扩展性要求？
- 客户的期望交付时间是什么？
- 你的时薪费率是多少？（如果不想在文档中体现费率，可以跳过）
阶段二：项目拆解 + 技术选型
-
将项目按 模块 → 功能项 分解：
项目
├── 模块1（如：用户系统）
│ ├── 功能1.1（如：注册/登录）
│ ├── 功能1.2（如：个人资料管理）
│ └── 功能1.3（如：权限管理）
├── 模块2（如：内容管理）
│ └── ...
└── 基础设施
├── 部署配置
├── CI/CD
└── 监控
-
从已加载的技能清单中，选取本项目需要的技术栈
-
用表格展示模块拆解和技术选型，让用户确认后再进入估算
阶段三：工时评估
基于技能清单中的基线工时，结合项目实际复杂度进行估算。
输出明细表格：
| 序号 | 模块 | 功能项 | 类别 | 技术栈 | 复杂度 | 工时(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，以及发现的功能点：
- 首页 — 核心价值主张、产品分类入口、导航结构
- 产品列表页 — 筛选/排序方式、产品卡片信息、分页/无限滚动
- 产品详情页 — 规格配置选项、实时报价/计算、图稿上传、加入购物车
- 注册/登录页 — 注册字段、OAuth 方式、B2B 审核流程（如有）
- 用户中心 / 账户页 — 个人资料、地址管理、订单历史
- 下单/结账流程 — 配送选项、支付方式、优惠码
- 订单追踪页 — 状态流转、物流信息
- 帮助中心 / FAQ — 内容结构、分类方式
- 其他内容页 — 关于我们、联系方式、博客/案例（如有）
- 后台/管理入口（如能访问）— 管理功能概览
遍历过程中，如果发现新的重要页面类型（如定价页、API 文档、合作伙伴页等），也一并访问并记录 URL。
步骤二：整理功能清单
将遍历结果整理为两部分：
① 参考页面 URL 表：
| 页面类型 | URL |
|---|
| 首页 | https://... |
| 产品列表页 | https://... |
| 产品详情页 | https://... |
| 注册/登录 | https://... |
| ... | ... |
② 按模块分类的功能列表：
## 模块名称
- 功能点 A（描述：具体行为或交互细节）
- 功能点 B
- ...
步骤三：建议分期规划，请用户确认
根据功能重要性和依赖关系，建议一期 / 二期拆分：
- 一期（MVP）：核心业务链路必须的功能，上线即可运营
- 二期（增强）：锦上添花、可延后的功能
以表格形式展示，让用户确认或调整：
| 功能点 | 建议分期 | 说明 |
|---|
| 用户注册/登录 | 一期 | 核心流程 |
| 实时报价计算 | 一期 | 核心差异化功能 |
| Dropshipping | 二期 | 增值服务，可延后 |
| ... | | |
用户确认一期范围后，直接进入模式 B 的阶段二（项目拆解 + 技术选型），以确认的功能列表作为需求输入。
注意事项
- 不要一次性问太多问题，每次最多 3-4 个，保持对话节奏
- 工时估算要务实，参考技能清单中的基线，避免虚高或虚低
- 表格数据要一致，明细加总必须等于汇总数字
- 如果用户提供了参考文档，优先参考其格式和风格
- 报价编号按 Q-年份-序号 格式自动生成（如 Q-2026-001）
- 始终用中文，包括表头、类别名称、备注等
