名称: 愿景分析 描述: “解析和分析项目愿景，提取结构化需求。在项目开始时使用，以理解目标、范围和约束。触发条件：分析愿景、解析项目目标、理解需求。”
愿景分析技能
解析项目愿景文档并提取结构化需求以用于架构和规划。
工作区模式说明
在工作区模式下运行时，所有路径都相对于 .aha-loop/ 目录：
- 愿景文件：
.aha-loop/project.vision.md - 分析输出：
.aha-loop/project.vision-analysis.md
协调器将在提示上下文中提供实际路径。
任务
- 从项目根目录读取
project.vision.md - 验证所有必需部分是否存在
- 提取和结构化需求
- 识别项目类型和规模
- 输出分析以指导架构决策
- 将分析保存到
project.vision-analysis.md
输入：project.vision.md
愿景文档应包含：
必需部分
| 部分 | 目的 |
|---|---|
| 什么 | 项目的一句话描述 |
| 为什么 | 动机和要解决的问题 |
| 目标用户 | 谁将使用此产品 |
| 成功标准 | 成功的可衡量定义 |
可选部分
| 部分 | 目的 |
|---|---|
| 约束 | 技术、预算或时间限制 |
| 灵感来源 | 参考产品或期望风格 |
| 非目标 | 项目明确不会做的事情 |
分析过程
步骤1：验证愿景文档
检查 project.vision.md 是否存在并包含必需部分：
## 验证清单
- [ ] 什么部分存在且清晰
- [ ] 为什么部分解释动机
- [ ] 目标用户已定义
- [ ] 成功标准可衡量
如果部分缺失或不清晰，记录需要的内容后再继续。
步骤2：识别项目类型
分类项目：
| 类型 | 特征 |
|---|---|
| CLI工具 | 命令行界面，无UI |
| Web应用 | 基于浏览器，前端 + 后端 |
| API服务 | 仅后端，REST/GraphQL |
| 库 | 可重用代码包 |
| 桌面应用 | 原生桌面应用程序 |
| 移动应用 | iOS/Android应用程序 |
| 全栈 | 完整的Web应用程序 |
| 基础设施 | DevOps，部署工具 |
步骤3：估计项目规模
| 规模 | 用户故事 | 持续时间 | 复杂性 |
|---|---|---|---|
| 小型 | 5-15 | 天数 | 单个组件 |
| 中型 | 15-50 | 周数 | 多个组件 |
| 大型 | 50-200 | 月数 | 完整系统 |
| 企业级 | 200+ | 季度数 | 多个系统 |
步骤4：提取核心功能
从愿景中识别：
- 必需功能 - MVP的关键功能
- 应该具有的功能 - 重要但不阻塞
- 锦上添花的功能 - 后续的增强功能
- 范围之外 - 明确排除的内容
步骤5：识别技术影响
基于功能，注意：
- 数据存储需求（数据库类型，规模）
- 认证要求
- 外部集成
- 性能要求
- 安全考虑
- 部署环境
输出：project.vision-analysis.md
# 愿景分析
**生成时间：** [时间戳]
**愿景版本：** [vision.md的哈希或日期]
## 项目分类
- **类型：** [Web应用 | API服务 | CLI工具 | ...]
- **规模：** [小型 | 中型 | 大型 | 企业级]
- **估计用户故事：** [范围]
## 核心需求
### 必需功能（MVP）
1. [功能1]
2. [功能2]
3. ...
### 应该具有的功能（Post-MVP）
1. [功能1]
2. ...
### 锦上添花的功能（未来）
1. [功能1]
2. ...
### 范围之外
- [排除项1]
- [排除项2]
## 技术影响
### 数据与存储
- [存储需求分析]
### 认证与安全
- [认证要求]
### 集成
- [外部系统集成]
### 性能
- [性能要求]
### 部署
- [部署环境需求]
## 约束总结
| 约束 | 影响 |
|------------|--------|
| [约束1] | [如何影响决策] |
## 开放问题
- [ ] [需要澄清的问题]
- [ ] [另一个问题]
## 推荐下一步
1. 运行架构技能以确定技术栈
2. 在继续之前解决任何开放问题
3. ...
## 架构提示
基于此愿景，考虑：
- [关于架构方法的提示]
- [关于技术类别的提示]
决策点
当愿景不清晰时
如果愿景文档缺乏细节：
- 不要猜测 - 记录缺少的内容
- 列出具体问题 - 需要澄清的确切内容
- 提供选项 - 建议可能的解释
- 谨慎进行 - 做出保守假设并记录下来
当范围过大时
如果估计规模为“大型”或“企业级”：
- 推荐分阶段方法 - 分解为多个主要里程碑
- 识别MVP子集 - 最小可用版本是什么
- 标记风险 - 注意大型项目需要仔细管理
当约束冲突时
如果约束似乎与目标冲突：
- 记录冲突 - 明确关于张力
- 提出解决方案 - 建议可能的妥协
- 优先处理 - 推荐放松哪个约束
与协调器集成
愿景分析后：
- 将
project.vision-analysis.md保存到项目根目录 - 向协调器发送完成信号
- 架构技能使用此分析作为输入
分析示例
输入愿景：
# 项目愿景
## 什么
一个个人财务跟踪器，帮助用户管理预算和跟踪支出。
## 为什么
现有应用太复杂。用户需要一个简单、专注的工具。
## 目标用户
希望进行基本支出跟踪而不复杂化的个人。
## 成功标准
- 用户可以在5秒内添加支出
- 自动生成月度报告
- 离线工作
## 约束
- 必须是Web应用（PWA用于离线）
- 无付费API（保持免费）
- 单人开发，时间有限
输出分析：
# 愿景分析
## 项目分类
- **类型：** Web应用（PWA）
- **规模：** 中型
- **估计用户故事：** 20-35
## 核心需求
### 必需功能（MVP）
1. 快速支出录入（<5秒）
2. 支出分类
3. 月度报告生成
4. 离线支持（PWA）
5. 数据持久性
### 应该具有的功能（Post-MVP）
1. 预算设置和跟踪
2. 支出趋势可视化
3. 导出功能
### 锦上添花的功能（未来）
1. 多货币
2. 收据照片捕捉
3. 银行导入
### 范围之外
- 多用户/共享功能
- 投资跟踪
- 税务准备
## 技术影响
### 数据与存储
- 本地优先（IndexedDB用于离线）
- 可选的云同步后
### 认证与安全
- 初始：无（仅本地）
- 后：简单认证用于同步
### 性能
- 关键：快速支出录入
- PWA服务工作者用于离线
### 部署
- 静态托管（Netlify，Vercel）
- 初始无后端
## 约束总结
| 约束 | 影响 |
|------------|--------|
| PWA要求 | 必须使用服务工作者，IndexedDB |
| 无付费API | 仅使用免费/开源解决方案 |
| 时间有限 | 专注于MVP，推迟锦上添花功能 |
## 推荐下一步
1. 运行架构技能以选择前端框架
2. 设计离线优先的数据架构
3. 规划PWA实施策略
清单
完成愿景分析前：
- [ ] 所有必需愿景部分已验证
- [ ] 项目类型已识别
- [ ] 规模已估计
- [ ] 功能已分类（必需/应该/锦上添花/范围之外）
- [ ] 技术影响已记录
- [ ] 约束已分析
- [ ] 开放问题已列出
- [ ] 分析已保存到
project.vision-analysis.md