生成项目报价单和工时评估文档。当用户提到"报价"、"估价"、"工时评估"、"项目评估"、 "开发报价"、"给客户报价"、"报价单"、"工作量评估"时触发。也适用于用户提到 "quote"、"estimate"、"project proposal"、"development cost"等场景。 同时支持：管理技能清单（"更新技能清单"、"添加技术栈"）；分析竞品/参考站点并生成报价 （"参考这个网站报价"、"仿这个网站"、"分析竞品功能"、"遍历这个网站"）。
帮助用户系统化地评估项目开发量、拆解工作项、估算工时，最终生成一份专业的 Markdown 报价文档。
全程使用中文交互和输出。
本技能的工时估算默认基于 AI 辅助开发的实际效率，而非传统人工开发经验值。
在技能清单中，基线工时已经是 AI 辅助后的数值，无需额外换算。 如遇到首次使用某技术、需求非常不明确等场景，可适当叠加调整因子。
每次触发时，先尝试读取本技能目录下的 references/skill-inventory.md。
如果文件不存在或内容为空 → 进入首次初始化流程（见下方）。
如果文件已存在且有内容 → 加载后根据用户意图进入模式 A 或模式 B。
当技能清单不存在时，系统性地询问用户的技术储备。分批提问，每次一个类别：
第一批：前端
第二批：后端
第三批：数据库与缓存
第四批：部署与基础设施
第五批：第三方服务
收集完毕后：
references/skill-inventory.md技能清单中每种技术的格式：
### 技术名称
| 操作类型 | 简单 | 中等 | 复杂 | 说明 |
|---|---|---|---|---|
| 操作A | Xh | Yh | Zh | 备注 |
| 操作B | Xh | Yh | Zh | 备注 |
按类别分区：前端框架、后端框架、数据库、缓存、部署平台、CI/CD、第三方服务集成。
末尾附上调整因子：
当用户想添加、修改或删除技术栈时：
references/skill-inventory.md如果用户提供了以前的报价文档作为参考：
如果用户提供了需求文档/PRD：
如果都没有，分批向用户提问（每次 3-4 个）：
第一批：
第二批：
第三批：
将项目按 模块 → 功能项 分解：
项目
├── 模块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 文件。
如果有参考的历史报价文档，尽量保持风格一致。
默认文档结构：
# [项目名称] 开发报价单
> 报价编号：Q-YYYY-NNN
> 日期：YYYY-MM-DD
> 编制：[用户名称]
**参考页面（如有）：**
| 页面类型 | URL |
|----------|-----|
| 首页 | https://... |
| 产品列表页 | https://... |
| 产品详情页 | https://... |
| 注册/登录 | https://... |
| 下单/结账 | https://... |
| ... | ... |
---
## 一、项目概述
[简要描述项目背景、目标和核心功能]
## 二、技术方案
[技术选型及架构概述]
## 三、工作量明细
[完整的估算表格]
## 四、项目周期
[建议的开发周期和里程碑节点]
| 阶段 | 内容 | 周期 |
|------|------|------|
| 第一阶段 | ... | X 周 |
| 第二阶段 | ... | X 周 |
| ... | | |
## 五、报价汇总
| 项目 | 数值 |
|------|------|
| 开发工时 | XXX 小时 |
| 项目管理 | XXX 小时 |
| 风险缓冲 | XXX 小时 |
| **总工时** | **XXX 小时** |
| 时薪费率 | ¥XXX/小时 |
| **总报价** | **¥XXX** |
## 六、说明与假设
- 本报价基于当前需求理解，需求变更可能影响工时和报价
- [其他假设和前提条件]
- 报价有效期：30 天
### 不含在本次报价范围内：
- [列出明确排除的内容]
询问用户文件保存路径（默认当前目录），然后写入文件。
生成文档后，询问用户：
根据反馈修改后重新生成文档。
当用户提供一个竞品或参考站点的 URL，希望以此为基础生成报价时，执行以下流程。
按以下顺序访问页面，每个页面访问后立即记录其实际 URL，以及发现的功能点：
遍历过程中，如果发现新的重要页面类型（如定价页、API 文档、合作伙伴页等），也一并访问并记录 URL。
将遍历结果整理为两部分：
① 参考页面 URL 表：
| 页面类型 | URL |
|---|---|
| 首页 | https://... |
| 产品列表页 | https://... |
| 产品详情页 | https://... |
| 注册/登录 | https://... |
| ... | ... |
② 按模块分类的功能列表：
## 模块名称
- 功能点 A（描述：具体行为或交互细节）
- 功能点 B
- ...
根据功能重要性和依赖关系，建议一期 / 二期拆分：
以表格形式展示，让用户确认或调整：
| 功能点 | 建议分期 | 说明 |
|---|---|---|
| 用户注册/登录 | 一期 | 核心流程 |
| 实时报价计算 | 一期 | 核心差异化功能 |
| Dropshipping | 二期 | 增值服务，可延后 |
| ... |
用户确认一期范围后，直接进入模式 B 的阶段二（项目拆解 + 技术选型），以确认的功能列表作为需求输入。