36b - 第1周：调研·需求·架构

调研的核心目标：
├── 确认市场存在真实需求（不是你自己的假设）
├── 了解竞品格局（谁在做、做得怎么样、有什么空白）
├── 验证你的差异化定位（为什么用户选你而不选别人）
└── 决策点：这个方向值得投入 6 周吗？

提示词模板 1：竞品全景扫描

我正在调研 [产品领域] 市场。请帮我完成以下分析：

1. **直接竞品**（功能高度重叠的产品，列出 Top 10）：
   - 产品名称、官网、成立时间
   - 核心功能（3-5 个关键特性）
   - 定价模式和价格区间
   - 用户规模（如有公开数据）

2. **间接竞品**（解决同一问题但方式不同的产品，列出 5 个）：
   - 产品名称和差异化方式

3. **市场规模估算**：
   - TAM（总可寻址市场）
   - SAM（可服务市场）
   - SOM（可获得市场）

4. **市场趋势**：
   - 近 12 个月的关键变化
   - 新进入者和退出者
   - 技术趋势对市场的影响

请用表格形式呈现竞品对比，用数据支撑市场规模估算。

提示词模板 2：竞品深度分析

请对以下竞品做深度分析：

竞品列表：
1. [竞品A] - [官网URL]
2. [竞品B] - [官网URL]
3. [竞品C] - [官网URL]

分析维度：

1. **功能矩阵**（表格形式）：
   | 功能 | 竞品A | 竞品B | 竞品C | 我的产品（计划） |
   列出 10-15 个关键功能，标注 ✅/❌/🔶（部分支持）

2. **定价策略对比**：
   - 免费层限制
   - 付费层价格和功能差异
   - 定价模式（按用户/按用量/固定月费）

3. **用户评价分析**：
   - 从 G2/Capterra/ProductHunt 收集的正面评价主题
   - 负面评价和常见抱怨
   - 用户最想要但缺失的功能

4. **差异化机会**：
   - 竞品共同的弱点是什么？
   - 哪些用户群体被忽视了？
   - 有哪些技术趋势可以利用？

5. **竞争壁垒分析**：
   - 网络效应、数据壁垒、品牌认知
   - 作为新进入者的突破口在哪里？

提示词模板 3：用户痛点挖掘

请帮我分析 [产品领域] 用户的真实痛点。

数据来源建议：
- Reddit: r/[相关subreddit] 中的抱怨帖
- Twitter/X: 搜索 "[产品领域] frustrating" 或 "[竞品名] sucks"
- ProductHunt: [竞品名] 的评论区
- G2/Capterra: [竞品名] 的 1-2 星评价

请整理出：

1. **Top 5 痛点**（按提及频率排序）：
   - 痛点描述
   - 典型用户引用（原文）
   - 影响程度（高/中/低）
   - 现有解决方案的不足

2. **未被满足的需求**：
   - 用户明确要求但没有产品提供的功能
   - 用户的变通方案（workaround）

3. **用户画像推断**：
   - 谁在抱怨？（角色、公司规模、技术水平）
   - 他们愿意为解决方案付多少钱？

提示词模板 4：生成社区验证帖子

我想在 [Reddit/Twitter/Discord] 验证一个产品想法。

产品概念：[一句话描述]
目标用户：[用户画像]
核心价值：[解决什么问题]

请帮我生成 3 个不同风格的帖子：

1. **问题导向帖**（不提产品，只问痛点）：
   "你们在 [场景] 中最大的痛点是什么？我发现..."

2. **方案探讨帖**（描述解决方案，征求意见）：
   "我在考虑做一个 [方案描述]，你们觉得..."

3. **Show HN 风格帖**（如果已有原型）：
   "Show HN: 我做了一个 [产品]，解决 [问题]..."

每个帖子要求：
- 标题吸引点击但不标题党
- 正文简洁，200 字以内
- 以开放式问题结尾，鼓励回复
- 适合 [目标社区] 的语气和风格

Reddit 发帖清单：
├── 找到 3-5 个相关 subreddit
├── 先在社区潜水 2-3 天，了解规则和氛围
├── 用"问题导向帖"发到最大的 subreddit
├── 用"方案探讨帖"发到更垂直的 subreddit
├── 24 小时内回复每一条评论
└── 记录所有反馈（正面/负面/建议）

Twitter/X 发帖清单：
├── 用 #buildinpublic 标签
├── 发一个 thread 描述你发现的问题
├── @提及 3-5 个领域内的 KOL
├── 发起投票："你最大的痛点是 A/B/C？"
└── 持续互动 48 小时

Discord 验证清单：
├── 加入 3-5 个目标用户聚集的 Discord 服务器
├── 在 #general 或 #feedback 频道提问
├── 私信 5-10 个活跃用户做简短访谈
└── 记录关键洞察

提示词模板 5：验证信号分析

我在社区发帖验证了一个产品想法，以下是收到的反馈：

[粘贴所有评论和回复]

请帮我分析：

1. **信号强度评估**（1-10 分）：
   - 正面信号数量和质量
   - 负面信号和反对意见
   - 中性/建设性反馈

2. **需求确认**：
   - 哪些痛点被反复提及？
   - 用户描述的场景和我假设的一致吗？
   - 有没有我没想到的使用场景？

3. **竞品提及**：
   - 用户提到了哪些现有解决方案？
   - 他们对这些方案的评价如何？

4. **定价信号**：
   - 有人提到愿意付费吗？
   - 价格敏感度如何？

5. **Go/No-Go 建议**：
   - 基于以上分析，这个方向值得继续吗？
   - 如果继续，需要调整什么？
   - 如果放弃，有没有 pivot 的方向？

Go 信号（至少满足 3 个）：
✅ 社区帖子获得 20+ 正面回复
✅ 至少 5 人表示"我愿意付费"
✅ 竞品评价中有明确的共同弱点
✅ 你的差异化定位得到认可
✅ Landing Page 收集到 30+ 邮箱

No-Go 信号（出现任意 2 个）：
❌ 社区反应冷淡（< 5 条回复）
❌ 多人表示"已有足够好的解决方案"
❌ 竞品壁垒太高（网络效应、数据锁定）
❌ 目标用户群太小或付费意愿极低
❌ 技术实现难度远超预期

提示词模板 6：v0.dev Landing Page 生成

请生成一个 SaaS 产品的 Landing Page，要求如下：

产品名称：[名称]
一句话描述：[用一句话说清楚产品做什么]
目标用户：[用户画像]
核心卖点（3 个）：
1. [卖点1]
2. [卖点2]
3. [卖点3]

页面结构：
1. Hero Section：大标题 + 副标题 + CTA 按钮 + 邮件收集表单
2. Pain Points：用户面临的 3 个痛点（带图标）
3. Solution：产品如何解决这些痛点（带截图占位符）
4. Features：核心功能列表（3-5 个，带图标和简短描述）
5. Social Proof：早期用户评价占位符
6. Pricing：简单的定价表（Free / Pro / Enterprise）
7. CTA：底部再次邮件收集
8. Footer：链接和版权信息

设计要求：
- 使用 shadcn/ui 组件
- 深色/浅色主题切换
- 响应式设计
- 简洁现代的风格
- 主色调：[颜色]

□ v0.dev 生成页面代码
□ 创建 Next.js 项目，集成生成的代码
□ 添加邮件收集功能（推荐方案）：
  ├── 方案 A：Resend + Supabase（免费）
  ├── 方案 B：ConvertKit 免费层（1,000 订阅者）
  └── 方案 C：Beehiiv 免费层（2,500 订阅者）
□ 部署到 Vercel（免费）
□ 配置自定义域名（可选，$10-15/年）
□ 在社区分享 Landing Page 链接
□ 追踪访问量和转化率

提示词模板 7：市场趋势与时机分析

我正在考虑进入 [产品领域] 市场。请帮我分析市场时机：

1. **搜索趋势**：
   - 这个领域的搜索量在过去 12 个月是上升还是下降？
   - 相关关键词的搜索趋势如何？

2. **技术趋势**：
   - 有哪些新技术正在改变这个领域？
   - AI 对这个领域的影响是什么？

3. **监管趋势**：
   - 有没有新的法规或政策影响这个市场？
   - 合规要求是否在增加？

4. **投资趋势**：
   - 近 12 个月这个领域的融资情况如何？
   - 有没有大公司进入或退出？

5. **时机判断**：
   - 现在进入是太早、刚好、还是太晚？
   - 最佳的切入角度是什么？

提示词模板 8：目标用户画像

基于以下信息，帮我生成详细的目标用户画像：

产品：[产品描述]
市场：[目标市场]
已知信息：[从调研中获得的用户信息]

请为每个用户画像提供：

1. **基本信息**：
   - 姓名（虚构）、年龄、职业、公司规模
   - 技术水平、收入水平

2. **日常工作场景**：
   - 典型的一天是怎样的？
   - 在什么场景下会遇到我们要解决的问题？

3. **痛点和需求**：
   - 最大的 3 个痛点
   - 当前的解决方案和不满之处
   - 理想的解决方案是什么样的？

4. **决策因素**：
   - 选择工具时最看重什么？（价格/功能/易用性/集成）
   - 谁是决策者？（自己/团队/管理层）
   - 付费意愿和预算范围

5. **触达渠道**：
   - 在哪里获取信息？（社区/博客/社交媒体）
   - 信任什么类型的推荐？（同行/KOL/评测）

请生成 3 个不同的用户画像，覆盖主要用户群体。

需求定义的核心原则：
├── 砍掉一切非必要功能（MVP ≤ 5 个核心功能）
├── 每个功能都要回答"用户为什么需要这个？"
├── 用用户故事（User Story）描述需求，不用技术语言
├── 定义清晰的验收标准（Acceptance Criteria）
└── 区分 Must-Have / Nice-to-Have / Future

提示词模板 9：AI 产品经理采访

你是一位经验丰富的产品经理，正在采访我来理清一个新产品的需求。
请用苏格拉底式提问法，一次问我 2-3 个问题，帮我理清以下方面：

产品概念：[一句话描述]
目标用户：[用户画像]
竞品调研结论：[关键发现]

采访主题（按顺序）：
1. 核心问题定义：用户到底在解决什么问题？
2. 现有方案分析：用户现在怎么解决这个问题？
3. 差异化价值：我们的方案比现有方案好在哪里？
4. MVP 范围：第一版必须有什么功能？
5. 成功指标：怎么衡量产品是否成功？
6. 风险识别：最大的风险是什么？

规则：
- 一次只问 2-3 个问题，等我回答后再继续
- 如果我的回答模糊，追问细节
- 如果我的想法有矛盾，指出来
- 最后帮我总结成一份简洁的需求摘要

提示词模板 10：MVP 功能优先级矩阵

基于以下信息，帮我定义 MVP 功能范围：

产品概念：[描述]
目标用户：[画像]
核心痛点：[Top 3 痛点]
竞品弱点：[竞品分析中发现的空白]

请用以下框架分析：

1. **功能清单**（列出所有想到的功能，不限数量）

2. **优先级矩阵**（对每个功能评分）：
   | 功能 | 用户价值(1-5) | 实现难度(1-5) | 差异化(1-5) | 优先级 |
   
   优先级计算：(用户价值 × 2 + 差异化) / 实现难度

3. **MVP 功能列表**（只保留 Top 3-5）：
   - Must-Have：没有这些功能产品无法使用
   - Nice-to-Have：提升体验但不是必须
   - Future：v2 或更后面的版本

4. **砍掉的功能及理由**：
   - 为什么这些功能不在 MVP 中？
   - 什么条件下会加入？

5. **MVP 成功标准**：
   - 用户能完成的核心流程是什么？
   - 最小可行的用户体验是什么样的？

提示词模板 11：PRD 文档生成

请基于以下信息生成一份完整的 PRD（产品需求文档）：

产品名称：[名称]
产品概念：[一句话描述]
目标用户：[用户画像]
MVP 功能列表：
1. [功能1]
2. [功能2]
3. [功能3]
4. [功能4（如有）]
5. [功能5（如有）]

PRD 结构要求：

## 1. 产品概述
- 产品愿景（一段话）
- 目标用户（2-3 个画像）
- 核心价值主张

## 2. 用户故事
对每个 MVP 功能，写出：
- As a [用户角色], I want [功能], so that [价值]
- 验收标准（Given/When/Then 格式，至少 3 条）
- 边界情况和异常处理

## 3. 功能需求
对每个功能详细描述：
- 功能描述
- 输入/输出
- 业务规则
- UI 交互要求（文字描述）
- 错误处理

## 4. 非功能需求
- 性能要求（响应时间、并发量）
- 安全要求（认证、授权、数据保护）
- 可用性要求（SLA 目标）
- 兼容性要求（浏览器、设备）

## 5. 成功指标
- 核心 KPI（3-5 个）
- 衡量方法
- 目标值

## 6. 时间线
- MVP 开发周期
- 关键里程碑

## 7. 风险和假设
- 关键假设（3-5 个）
- 风险及缓解措施

┌─────────────────────────────────────────────────────────┐
│                 Kiro Spec-Driven 工作流                   │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Step 1: 输入产品意图                                     │
│  "我要做一个 [产品描述]"                                   │
│          │                                              │
│          ▼                                              │
│  Step 2: Kiro 生成 requirements.md                      │
│  ├── 用户故事（EARS 格式验收标准）                          │
│  ├── 功能需求                                            │
│  └── 非功能需求                                          │
│          │                                              │
│          ▼  ← 你审查并修改                                │
│                                                         │
│  Step 3: Kiro 生成 design.md                            │
│  ├── 技术架构                                            │
│  ├── 数据模型（TypeScript 接口）                           │
│  ├── API 设计                                           │
│  └── 组件设计                                            │
│          │                                              │
│          ▼  ← 你审查并修改                                │
│                                                         │
│  Step 4: Kiro 生成 tasks.md                             │
│  ├── 任务分解（每个任务 15-30 分钟）                        │
│  ├── 任务依赖关系                                        │
│  └── 子任务详情                                          │
│          │                                              │
│          ▼  ← 你审查并修改                                │
│                                                         │
│  Step 5: 逐个执行任务                                     │
│  ├── AI 生成代码                                         │
│  ├── 你审查代码                                          │
│  └── 运行测试验证                                        │
│                                                         │
└─────────────────────────────────────────────────────────┘

操作流程：

1. 打开 Kiro IDE
2. 使用 Spec 模式，输入产品意图：
   "我要做一个 [产品名称]，它是 [一句话描述]。
    目标用户是 [用户画像]。
    核心功能包括：
    1. [功能1]
    2. [功能2]
    3. [功能3]
    技术栈：[选定的技术栈]"

3. Kiro 生成 requirements.md
   ├── 逐条审查每个用户故事
   ├── 检查验收标准是否完整
   ├── 补充遗漏的边界情况
   └── 删除不属于 MVP 的需求

4. Kiro 生成 design.md
   ├── 审查技术架构是否合理
   ├── 检查数据模型是否完整
   ├── 确认 API 设计是否 RESTful
   └── 验证组件划分是否清晰

5. Kiro 生成 tasks.md
   ├── 确认任务粒度（每个 15-30 分钟）
   ├── 检查任务依赖关系
   ├── 确认任务总数（MVP 通常 30-60 个）
   └── 标记优先级

提示词模板 12：Spec 审查清单

请帮我审查以下 Spec 文件，检查是否有问题：

[粘贴 requirements.md 内容]

审查维度：

1. **完整性**：
   - 是否覆盖了所有 MVP 功能？
   - 是否有遗漏的用户故事？
   - 非功能需求是否完整？

2. **一致性**：
   - 用户故事之间是否有矛盾？
   - 验收标准是否与功能描述一致？
   - 术语使用是否统一？

3. **可测试性**：
   - 每个验收标准是否可以写成测试用例？
   - 是否有模糊的描述需要量化？

4. **范围控制**：
   - 有没有超出 MVP 范围的功能？
   - 有没有可以简化的功能？
   - 实现难度是否在 6 周内可控？

5. **优先级**：
   - Must-Have 功能是否正确标记？
   - 任务顺序是否合理？

提示词模板 13：用户故事批量生成

基于以下 MVP 功能列表，为每个功能生成用户故事和验收标准：

功能列表：
1. [功能1描述]
2. [功能2描述]
3. [功能3描述]

要求：
- 每个功能至少 2 个用户故事
- 每个用户故事至少 3 条验收标准
- 验收标准使用 EARS 格式：
  WHEN [触发条件], THE [系统] SHALL [行为]
- 包含正常流程和异常流程
- 包含边界情况

示例格式：

### 功能：用户注册

**用户故事 1**：
As a 新用户, I want 用邮箱注册账号, so that 我可以使用产品的全部功能。

**验收标准**：
1. WHEN 用户输入有效邮箱和密码（≥8位，含大小写和数字）, 
   THE 系统 SHALL 创建账号并发送验证邮件
2. WHEN 用户输入已注册的邮箱, 
   THE 系统 SHALL 显示"该邮箱已注册"错误提示
3. WHEN 用户点击验证邮件中的链接, 
   THE 系统 SHALL 激活账号并跳转到欢迎页面
4. WHEN 验证链接超过 24 小时, 
   THE 系统 SHALL 显示"链接已过期"并提供重新发送选项

提示词模板 14：边界情况和异常场景发现

我正在为以下功能编写需求文档，请帮我发现可能遗漏的边界情况：

功能描述：[详细描述]
正常流程：[描述正常使用流程]
已知的异常处理：[已经考虑到的异常]

请从以下角度分析：

1. **输入边界**：
   - 空输入、超长输入、特殊字符
   - 数值边界（0、负数、最大值）
   - 格式错误（邮箱、URL、日期）

2. **并发场景**：
   - 多用户同时操作同一资源
   - 重复提交
   - 竞态条件

3. **网络异常**：
   - 请求超时
   - 断网后恢复
   - 部分失败（批量操作中某些成功某些失败）

4. **权限边界**：
   - 未登录用户访问受保护资源
   - 权限不足的操作
   - Token 过期

5. **数据边界**：
   - 空列表 / 单条数据 / 大量数据
   - 数据被其他用户删除后的引用
   - 数据格式迁移

6. **用户行为**：
   - 浏览器后退按钮
   - 多标签页操作
   - 复制粘贴非预期内容

请列出 Top 10 最可能被遗漏的边界情况，并建议如何处理。

Solo Founder 技术选型决策框架：

优先级 1：AI 编码效率
├── AI 对这个技术栈的代码生成质量如何？
├── 社区和文档是否丰富（AI 训练数据充足）？
└── 评分标准：用 AI 写一个 CRUD 功能需要多少次修改？

优先级 2：开发速度
├── 从零到可运行需要多长时间？
├── 有没有现成的模板和脚手架？
└── 评分标准：初始化项目到第一个功能上线需要多久？

优先级 3：运维负担
├── 部署是否零配置或接近零配置？
├── 是否需要管理服务器？
└── 评分标准：部署一次需要多少步骤？

优先级 4：成本
├── 免费层是否够用？
├── 付费后的月成本是多少？
└── 评分标准：MVP 阶段月成本 < $50？

优先级 5：可扩展性
├── 用户从 100 到 10,000 时需要重写吗？
├── 技术栈是否支持渐进式扩展？
└── 评分标准：不重写核心代码能支撑多少用户？

提示词模板 15：技术栈选型分析

我是一个 Solo Founder，要在 6 周内开发一个 [产品类型] 的 MVP。

产品需求：
- [核心功能1]
- [核心功能2]
- [核心功能3]
- 预期用户量：MVP 阶段 100-1000 人
- 预算：月运营成本 < $50

我的技术背景：[描述你熟悉的技术]

请对比以下技术栈方案：

方案 A：[技术栈A，如 Next.js + Supabase + Vercel]
方案 B：[技术栈B，如 Remix + PlanetScale + Fly.io]
方案 C：[技术栈C，如 SvelteKit + Firebase + Cloudflare]

对比维度（表格形式）：

| 维度 | 方案 A | 方案 B | 方案 C |
|------|--------|--------|--------|
| AI 编码质量 | | | |
| 开发速度 | | | |
| 免费层限制 | | | |
| 月成本（Pro 层） | | | |
| 部署复杂度 | | | |
| 社区活跃度 | | | |
| 学习曲线 | | | |
| 可扩展性 | | | |
| 实时功能支持 | | | |
| 认证方案 | | | |

最终推荐：
- 推荐方案及理由
- 该方案的潜在风险
- 风险缓解措施

提示词模板 16：数据模型设计

基于以下产品需求，设计数据模型：

产品：[产品描述]
核心功能：
1. [功能1]
2. [功能2]
3. [功能3]

数据库：[选定的数据库，如 PostgreSQL via Supabase]

请提供：

1. **实体关系图**（Mermaid ER 图）：
   - 列出所有实体及其属性
   - 标注关系类型（1:1, 1:N, N:N）
   - 标注必填/可选字段

2. **TypeScript 接口定义**：
   - 每个实体的 TypeScript interface
   - 包含创建/更新/查询的 DTO 类型

3. **数据库 Schema**（SQL）：
   - CREATE TABLE 语句
   - 索引设计
   - 外键约束
   - RLS（Row Level Security）策略（如使用 Supabase）

4. **数据流分析**：
   - 核心用户流程中的数据读写模式
   - 预期的查询热点
   - 需要缓存的数据

5. **扩展考虑**：
   - 哪些字段可能需要后续添加？
   - 数据量增长预估
   - 迁移策略

提示词模板 17：API 设计

基于以下数据模型和功能需求，设计 RESTful API：

数据模型：[粘贴数据模型]
核心功能：[功能列表]
认证方式：[如 JWT / Supabase Auth]

请提供：

1. **API 端点列表**（表格形式）：
   | 方法 | 路径 | 描述 | 认证 | 请求体 | 响应体 |
   
2. **详细接口定义**（每个端点）：
   - 请求参数（path/query/body）
   - 响应格式（成功/错误）
   - 状态码
   - 错误处理

3. **认证流程**：
   - 注册/登录/登出流程
   - Token 刷新机制
   - 权限检查中间件

4. **分页和过滤**：
   - 列表接口的分页策略
   - 过滤和排序参数

5. **速率限制**：
   - 各端点的速率限制建议
   - 免费层 vs 付费层的限制差异

如果使用 Next.js API Routes 或 Server Actions，
请说明哪些适合用 API Routes，哪些适合用 Server Actions。

提示词模板 18：系统架构设计

请为以下产品生成完整的系统架构设计文档：

产品：[产品描述]
技术栈：[选定的技术栈]
数据模型：[粘贴数据模型]
API 设计：[粘贴 API 设计]

请提供：

1. **系统架构图**（Mermaid 图）：
   - 整体架构（C4 Context 级别）
   - 容器图（C4 Container 级别）
   - 关键组件的交互流程

2. **前端架构**：
   - 页面路由结构
   - 组件层次结构
   - 状态管理方案
   - 数据获取策略（SSR/SSG/CSR/ISR）

3. **后端架构**：
   - API 层设计
   - 业务逻辑层设计
   - 数据访问层设计
   - 中间件链（认证、日志、错误处理）

4. **基础设施**：
   - 部署架构图
   - CI/CD 流程
   - 环境配置（dev/staging/prod）
   - 监控和日志方案

5. **安全架构**：
   - 认证和授权流程
   - 数据加密策略
   - API 安全（CORS、速率限制、输入验证）
   - 密钥管理

6. **第三方服务集成**：
   - 支付（Stripe）
   - 邮件（Resend）
   - 分析（Plausible）
   - 监控（Uptime Kuma / Sentry）

提示词模板 19：ADR 生成

请为以下技术决策生成 ADR：

决策主题：[如"选择 Supabase 作为后端服务"]

ADR 格式：

## ADR-001: [决策标题]

### 状态
已接受

### 上下文
[为什么需要做这个决策？背景是什么？]

### 决策
[最终选择了什么方案？]

### 考虑的方案
| 方案 | 优点 | 缺点 | 成本 |
|------|------|------|------|
| 方案 A | | | |
| 方案 B | | | |
| 方案 C | | | |

### 理由
[为什么选择这个方案而不是其他方案？]

### 后果
- 正面影响：[列出]
- 负面影响：[列出]
- 风险：[列出]
- 缓解措施：[列出]

### 相关决策
- [关联的其他 ADR]

前端：Next.js 15 + TypeScript + Tailwind CSS + shadcn/ui
后端：Next.js API Routes / Server Actions
数据库：Supabase（PostgreSQL + Auth + Storage + Realtime）
部署：Vercel
支付：Stripe / Lemon Squeezy
邮件：Resend + React Email
分析：Plausible Analytics
AI 编码：Kiro（Spec-Driven）+ Cursor（交互式）

月成本（MVP）：$0-20
月成本（正式运营）：$50-100

框架：Tauri 2.0（Rust 后端 + React 前端）
前端：React + TypeScript + CSS Modules
数据库：SQLite（本地）
分发：GitHub Releases + 自动更新
AI 编码：Kiro / Cursor

月成本（MVP）：$0

框架：Vercel AI SDK / LangChain.js
模型：Claude API / OpenAI API
向量数据库：Supabase pgvector
部署：Vercel / Railway
AI 编码：Kiro / Cursor

月成本（MVP）：$10-30（API 调用费）

提示词模板 20：Kiro Steering 规则生成

基于以下技术栈和架构决策，生成 Kiro Steering 规则文件：

技术栈：[技术栈详情]
架构风格：[如 Next.js App Router + Server Components]
代码规范：[如 ESLint + Prettier]
测试策略：[如 Vitest + Playwright]

请生成 .kiro/steering/coding-standards.md，包含：

1. **技术栈约束**：
   - 允许使用的框架和库
   - 禁止使用的库（及原因）
   - 版本锁定要求

2. **代码风格**：
   - 命名规范（文件、变量、函数、组件）
   - 文件组织结构
   - 导入顺序规则

3. **架构规则**：
   - 组件设计原则（Server vs Client Components）
   - 数据获取模式
   - 错误处理模式
   - 状态管理规则

4. **安全规则**：
   - 输入验证要求
   - 认证检查要求
   - 环境变量使用规则
   - 禁止硬编码的内容

5. **测试规则**：
   - 测试文件命名和位置
   - 最低覆盖率要求
   - 测试类型要求（单元/集成/E2E）

6. **禁止事项**：
   - 不允许的代码模式
   - 不允许的依赖
   - 不允许的 API 使用方式

Day 5 结束时，你应该有以下产出：

□ 技术栈选型报告（含对比分析和 ADR）
□ 数据模型设计（ER 图 + TypeScript 接口 + SQL Schema）
□ API 设计文档（端点列表 + 详细定义）
□ 系统架构设计文档（架构图 + 组件设计）
□ Kiro Spec 文件集：
  ├── .kiro/specs/[feature]/requirements.md
  ├── .kiro/specs/[feature]/design.md
  └── .kiro/specs/[feature]/tasks.md
□ Kiro Steering 规则文件：
  └── .kiro/steering/coding-standards.md
□ 项目初始化准备（技术栈确认、依赖列表）

这些文档将成为 Week 2-4 开发的"蓝图"。

使用工具：Perplexity Pro + Claude

Step 1：竞品全景扫描（Perplexity Pro）
输入：
  "AI code review tools 2025-2026, compare features, pricing, 
   target users for CodeRabbit, Sourcery, Codacy, DeepSource, 
   Qodo, Codeium"

发现：
├── CodeRabbit：$12/月/用户，功能全面，但配置复杂
├── Sourcery：$14/月/用户，Python 为主，其他语言支持弱
├── Codacy：$15/月/用户，偏向大团队，小团队用不起
├── DeepSource：免费层较好，但 AI 审查能力有限
├── Qodo：专注测试生成，代码审查是附带功能
└── 关键发现：中小团队（1-10 人）市场有空白
    ├── 现有工具定价偏高（$12-15/用户/月）
    ├── 配置复杂，需要 DevOps 经验
    └── 误报率高，开发者疲劳

Step 2：深度竞品分析（Claude）
输入：粘贴 Perplexity 的搜索结果 + 竞品官网信息

输出：功能矩阵表
| 功能 | CodeRabbit | Sourcery | 我的产品（计划） |
|------|-----------|----------|----------------|
| 零配置 | ❌ | ❌ | ✅ |
| 低误报 | 🔶 | 🔶 | ✅（核心卖点） |
| 多语言 | ✅ | 🔶 | 🔶（先做 5 种） |
| GitHub 集成 | ✅ | ✅ | ✅ |
| 免费层 | ❌ | 🔶 | ✅（5 PR/月） |
| 价格 | $12/用户 | $14/用户 | $9/用户 |

差异化定位：
"零配置、低误报、中小团队友好的 AI 代码审查工具"

Reddit 验证：

帖子标题：
"What's your biggest frustration with AI code review tools?"

发布到：r/programming（500 万成员）

24 小时结果：
├── 83 条回复
├── 156 个 upvote
├── 核心痛点（按提及频率）：
│   1. "Too many false positives" — 31 次提及
│   2. "Configuration is a nightmare" — 24 次提及
│   3. "Too expensive for small teams" — 19 次提及
│   4. "Doesn't understand context" — 15 次提及
│   └── 5. "Slow review speed" — 8 次提及
├── 正面信号：
│   "I'd pay $5-10/month for something that just works"
│   "Zero config would be a game changer"
│   "If it could reduce false positives by 50%, I'm in"
└── 决策：Go！需求信号足够强

Twitter/X 验证：

帖子：
"Building an AI code review tool that:
 ✅ Zero config (install → works)
 ✅ Low false positives (AI understands context)
 ✅ $9/month for small teams
 
 Would you use this? What features matter most?"

48 小时结果：
├── 47 个 Like
├── 12 个 Retweet
├── 23 条回复（多数正面）
└── 3 个 DM 表示愿意做 beta 测试

Landing Page：
├── 用 v0.dev 生成（45 分钟）
├── 部署到 Vercel
├── 48 小时收集到 67 个邮箱
└── 转化率：Landing Page 访问 → 邮箱注册 = 12%

Step 1：AI 产品经理采访（Claude）

通过 3 轮对话，理清了：
├── 核心用户：5-10 人的开发团队 Tech Lead
├── 核心场景：GitHub PR 提交后自动审查
├── 核心价值：节省 Code Review 时间 50%+
└── 付费意愿：$9-15/用户/月

Step 2：MVP 功能定义

Must-Have（v1）：
1. GitHub App 安装（一键安装，零配置）
2. PR 自动审查（提交 PR 后 30 秒内开始审查）
3. 智能评论（在 PR 中直接评论，标注严重程度）
4. 支持 5 种语言（JS/TS/Python/Go/Rust）
5. 免费层（5 PR/月）

Nice-to-Have（v1.1）：
- 自定义审查规则
- 团队仪表板
- Slack 通知集成

Future（v2）：
- GitLab 支持
- 自动修复建议
- 安全漏洞扫描

Step 3：在 Kiro 中创建 Spec

输入意图：
"我要做一个 AI 代码审查工具 CodeLens，
 它是一个 GitHub App，在 PR 提交后自动用 AI 审查代码，
 在 PR 中直接评论审查结果。
 目标用户是 5-10 人的开发团队。
 技术栈：Next.js + Supabase + Vercel + Claude API。
 核心功能：GitHub App 安装、PR 自动审查、智能评论、
 多语言支持、免费层。"

Kiro 生成的 Spec：
├── requirements.md：12 个用户故事，48 条验收标准
├── design.md：系统架构、数据模型、API 设计
└── tasks.md：42 个任务（预计 3 周完成）

审查修改：
├── 删除了 3 个超出 MVP 范围的用户故事
├── 补充了 5 条遗漏的验收标准（错误处理相关）
├── 调整了 2 个数据模型字段
└── 重新排序了任务优先级

Step 1：技术栈确认

经过 AI 辅助对比分析，最终选择：

| 层级 | 选择 | 理由 |
|------|------|------|
| 前端 | Next.js 15 + TypeScript | AI 代码生成质量最高 |
| UI | shadcn/ui + Tailwind CSS | 快速构建，AI 友好 |
| 后端 | Next.js API Routes | 全栈统一，减少上下文切换 |
| 数据库 | Supabase（PostgreSQL） | 内置 Auth + RLS，免费层够用 |
| AI | Claude API（Sonnet） | 代码理解能力强，性价比高 |
| 部署 | Vercel | 零配置，自动 CI/CD |
| 支付 | Stripe | 全球通用，开发者友好 |
| 邮件 | Resend | 开发者友好，免费层够用 |
| 监控 | Uptime Kuma + Sentry | 免费（自托管）+ 免费层 |

ADR 记录：
├── ADR-001: 选择 Supabase 而非自建后端
│   理由：Auth + RLS + Realtime 开箱即用，节省 2 周开发时间
├── ADR-002: 选择 Claude API 而非 OpenAI
│   理由：代码理解能力更强，200K 上下文窗口适合大 PR
└── ADR-003: 选择 GitHub App 而非 OAuth App
    理由：更好的权限控制，支持组织级安装

Step 2：架构设计

系统架构（简化版）：

┌─────────────────────────────────────────────┐
│                  Vercel                      │
│  ┌─────────────────────────────────────┐    │
│  │         Next.js 15 App              │    │
│  │  ┌──────────┐  ┌────────────────┐   │    │
│  │  │ Dashboard │  │ API Routes     │   │    │
│  │  │ (React)   │  │ ├── /webhook   │   │    │
│  │  │           │  │ ├── /api/auth  │   │    │
│  │  │           │  │ └── /api/...   │   │    │
│  │  └──────────┘  └───────┬────────┘   │    │
│  └────────────────────────┼────────────┘    │
│                           │                  │
│  ┌────────────────────────▼────────────┐    │
│  │           Supabase                   │    │
│  │  PostgreSQL + Auth + Storage         │    │
│  └──────────────────────────────────────┘    │
└─────────────────────────────────────────────┘
         │                        │
         ▼                        ▼
  ┌──────────────┐      ┌──────────────┐
  │  GitHub API   │      │  Claude API   │
  │  (Webhooks)   │      │  (Code Review)│
  └──────────────┘      └──────────────┘

核心流程：
1. 用户安装 GitHub App → Webhook 注册
2. 用户提交 PR → GitHub 发送 Webhook
3. API Route 接收 Webhook → 获取 PR diff
4. 调用 Claude API 分析代码 → 生成审查意见
5. 通过 GitHub API 在 PR 中发表评论
6. 记录审查结果到 Supabase

Step 3：Steering 规则文件

创建 .kiro/steering/coding-standards.md：
├── 技术栈约束：Next.js 15 App Router + TypeScript strict
├── 组件规范：Server Components 优先，Client 仅用于交互
├── 数据获取：Server Actions 优先，API Routes 用于 Webhook
├── 错误处理：统一 Error Boundary + toast 通知
├── 测试要求：核心逻辑 Vitest 单元测试，关键流程 Playwright E2E
└── 安全规则：所有 API 端点必须验证认证，Webhook 必须验证签名

第 1 周产出清单：
✅ 竞品分析报告（6 个竞品深度对比）
✅ 社区验证（Reddit 83 回复 + Twitter 47 Like）
✅ Landing Page（67 个邮箱注册，12% 转化率）
✅ PRD 文档（5 个核心功能，12 个用户故事）
✅ Kiro Spec 文件集（requirements + design + tasks）
✅ 技术选型报告（3 个 ADR）
✅ 系统架构设计文档
✅ Steering 规则文件

总投入时间：约 35 小时（5 天 × 7 小时）
AI 工具费用：约 $5（Claude API 调用）

关键决策点：
├── Day 2 决策：Go（社区反馈强烈）
├── Day 4 决策：MVP 只做 5 个核心功能（砍掉了 8 个 Nice-to-Have）
└── Day 5 决策：Supabase + Claude API（而非自建后端 + OpenAI）

□ 完成竞品全景扫描（至少 5 个直接竞品）
□ 完成深度竞品分析（Top 3 竞品的功能矩阵）
□ 完成用户痛点挖掘（至少 5 个痛点）
□ 在 Reddit 发布验证帖子
□ 在 Twitter/X 发布验证帖子
□ 输出：竞品分析报告（Markdown 文档）

□ 分析社区反馈（正面/负面信号统计）
□ 做出 Go/No-Go 决策
□ 用 v0.dev 生成 Landing Page
□ 部署 Landing Page 到 Vercel
□ 配置邮件收集功能
□ 在社区分享 Landing Page
□ 输出：验证报告 + 上线的 Landing Page

□ 完成 AI 产品经理采访（理清核心需求）
□ 定义 MVP 功能范围（≤ 5 个核心功能）
□ 生成 PRD 文档初稿
□ 审查和修改 PRD
□ 在 Kiro 中创建 Spec（requirements.md）
□ 审查 requirements.md
□ 输出：PRD + requirements.md

□ Kiro 生成 design.md
□ 审查 design.md（数据模型、API 设计）
□ Kiro 生成 tasks.md
□ 审查 tasks.md（任务粒度、优先级）
□ 补充遗漏的边界情况和验收标准
□ 输出：完整的 Spec 文件集

□ 完成技术栈对比分析
□ 做出技术选型决策
□ 记录 ADR（至少 3 个）
□ 完成数据模型设计
□ 完成 API 设计
□ 完成系统架构设计文档
□ 创建 Steering 规则文件
□ 输出：技术选型报告 + 架构文档 + Steering 文件