核心价值: 一人公司最大的风险不是技术，而是做错了需求。本章讲如何用 AI + 结构化思维做产品设计。
1.1 一人公司的需求陷阱
三大常见错误
❌ 错误 1：过度工程（Over-Engineering）
你想做: 用户能搜索广告
你实际做了: 全文搜索引擎 + 向量相似度 + 实时索引 + 搜索推荐
实际需要: 一个 SQL ILIKE 查询
❌ 错误 2：需求蔓延（Scope Creep）
Week 1: "做一个广告素材保存功能"
Week 2: "顺便加个导出 Excel"
Week 3: "再加个数据可视化"
Week 4: "还需要团队协作..."
结果：3 个月后还没有一个完整版本上线。
❌ 错误 3：猜测用户需求（Build Before Validate）
错误流程: 想法 → 设计 → 开发 6 周 → 找用户 → 没人要
正确流程: 想法 → 找 5 个目标用户对话 → 确认痛点 → 最小版本 → 迭代
1.2 AI 辅助需求分析
方法：用 AI 扮演"苛刻的产品经理"
Prompt 模板：
我要做一个 [产品]，目标用户是 [用户]，解决的问题是 [问题]。
请作为一个苛刻的产品经理：
1. 指出这个需求中最模糊的3个假设
2. 列出 5 个"如果这个假设错了，整个产品就没价值"的风险
3. 建议一个最小可验证版本（MVP）只需要哪些功能
4. 哪些功能是"好有但不必须"，可以 V2 再做
Market Vault 实际输出（简化）：
- 最模糊假设: 用户愿意手动触发抓取 vs 期待全自动化
- 最大风险: Meta 修改 Ad Library API 导致整个抓取失效
- MVP 必须有: POST 保存广告列表 + 去重 + 按项目浏览
- V2 再做: AI 推荐、导出、告警、协作
需求文档结构（用 Obsidian + AI 写）
## 功能需求 - [功能名]
**用户故事**: 作为 [角色]，我想要 [行为]，这样我就能 [目的]
**验收标准**:
- [ ] 当...时，系统应该...
- [ ] 当...时，系统不应该...
**范围外 (Out of Scope)**:
- 明确排除的功能，防止 scope creep
**API 设计**:
POST /api/v1/...
请求: { ... }
响应: { ... }
错误: 400/422/429 对应场景
**数据库影响**:
- 新增/修改哪些表
- 是否需要迁移
**预估工时**: X 天（含测试）
1.3 结构化任务管理
工具选择：Obsidian Tasks + GitHub Issues
日常工作流：
- Obsidian（私人脑暴）→ 想法、设计草稿、架构图
- GitHub Issues（执行跟踪）→ 具体任务、Bug、PR
- Git commit message（历史记录）→ 每次提交关联 Issue
Sprint 拆解原则
RICE 优先级模型： $$RICE = \frac{Reach \times Impact \times Confidence}{Effort}$$
| 功能 | 覆盖用户数 | 影响（1-3） | 信心（%） | 工时（天） | RICE |
|---|---|---|---|---|---|
| AI 推荐 | 100% | 2 | 60% | 10 | 12 |
| 导出 CSV | 40% | 1 | 90% | 2 | 18 |
| 搜索 | 80% | 2 | 80% | 3 | 43 |
→ 先做搜索，再做导出，AI 推荐最后
GitHub Issues 模板
## 背景
为什么要做这个？（用户反馈/数据/战略）
## 方案
技术方案（不超过3个选项，选择理由）
## 任务分解
- [ ] 数据库 migration
- [ ] Service 层函数
- [ ] API 路由
- [ ] 测试（单元 + 集成）
- [ ] 文档更新
## 完成标准
- 所有测试通过
- make lint 通过
- 手动 Postman 测试
1.4 文档驱动开发（DDD）
核心思想：先写文档，再写代码
正确顺序：
1. 在 Obsidian 写设计文档（高层次，不含代码）
2. 用 AI 评审设计文档，找出漏洞
3. 设计确认后，在 GitHub Issues 拆任务
4. 开始写代码（此时 AI 已有上下文）
5. 代码完成后，更新文档
设计文档 Prompt（给 AI）：
我要实现以下功能：[粘贴设计文档]
请帮我：
1. 找出这个设计中的安全漏洞
2. 找出可能导致数据不一致的竞争条件
3. 找出我没考虑到的边界情况
4. 建议测试用例（正常流 + 异常流）
1.5 实战：Market Vault 产品决策记录
决策1：为什么用 ad_archive_id 作为全局唯一键？
背景: Meta Ad Library 的每条广告有唯一 ad_archive_id
选项:
- A: 每次 POST 都存一条新记录（无去重）
- B: 以
ad_archive_id全局去重，多个快照共享同一广告
决策: B
理由:
- 用户可能多次 snapshot 相同广告（不同时间），重复存储浪费空间
- 广告素材（图片/视频）一致，可以共用 CDN 资源
- 查询"某广告在哪些 snapshot 中出现"变得高效
影响: SearchSnapshot ↔ Ad 多对多，通过 snapshots_ads 中间表
决策2：为什么资产文件用 SHA-256 而不是 URL 去重？
背景: 同一张图片可能有不同 URL（A/B 测试、CDN 缓存）
决策: SHA-256 内容哈希去重
收益: 节省 30-60% CDN 存储 + 避免重复下载
小结与行动项
本章学到:
- 先验证需求，再写代码（5 个用户对话 > 1 周开发）
- 用 AI 扮演苛刻 PM，找出假设漏洞
- RICE 模型做功能优先级
- 文档驱动开发：设计 → AI 评审 → 实现
行动项:
- 为下一个功能写设计文档（用本章模板）
- 用 AI PM Prompt 检查设计是否有漏洞
- 在 GitHub Issues 拆分执行任务
下一章 → 第2章：AI Agent 协作开发