项目背景
某智能预测产品需要做一个感知平台——把多源数据接入、清洗、展示给业务方。
需求特点：
- 时间紧（领导要"尽快看到东西"）
- 范围模糊（"先做个 POC 看看效果"）
- 多方协调（产品/算法/前端/后端/数据 5 个角色）
- 技术不确定（数据源还没定下来）
这是一个典型的"先跑起来再说"场景——但如果真的"先跑起来再说"，结局通常是：跑起来了，但说不清楚跑的是什么。
决策：用自己的框架
我决定把自己设计的 AI 开发框架用在这个项目上——不是为了验证方法论，是因为这种模糊场景正是框架设计来解决的。
核心工具链：
- 需求收敛器 — 在模糊中找到边界
- 方案设计器 — 从边界到可执行方案
- 结晶器 — 把验证后的结论固化为文档
10 天时间线
Day 1-2: 需求收敛
第一步不是"开始做"——是"搞清楚做什么"。
我的需求收敛器做了 3 件事：
- 列出所有模糊点（数据源有哪些？展示给谁？什么算"成功"？）
- 和 5 个角色分别对齐各自的期望
- 产出一份边界文档：这次做什么、不做什么
最关键的一次对齐：产品方想要"智能推荐"，算法方说"数据还没跑通基础预测"。边界文档明确写了："本期不做推荐，只做数据可视化+基础预测展示"。
Day 3: 边界锁定
产出 Ready Gate 文档——满足 5 个条件才能开始 POC：
- 数据源 API 可访问 ✅
- 展示指标已确认 ✅
- 前端技术栈已定 ✅
- 部署环境就绪 ✅
- 演示受众已确认 ✅
没有全 ✅ 就不动手。 这避免了"边做边发现前提不满足"的浪费。
Day 4-6: 技术验证 (POC)
在边界明确后开始技术验证：
- 数据源接入 → 确认可拿到数据
- 数据清洗 → 确认数据质量够用
- 前端展示 → 确认可视化方案可行
- 预测展示 → 确认算法输出可落地
每天用 AI 辅助记录进展和问题——这些记录后来直接成为 PRD 的"技术验证"章节。
POC 中的关键踩坑：主题 ≠ 配色
Day 4 上午，我试了一个看起来很自然的方案："把现有组件库的色彩 token 导入，切换出 4 套主题"。
结果：4 套颜色切出来了（深夜暖、纯白暖、暗色、亮色），切换时只有色调在变——但间距、信息层级、交互策略的问题原封不动保留着。颜色切换给人一种"在探索不同方向"的错觉，真正决定用户体验的维度完全没被触及。
这逼出了一个认知跃迁：主题 = 视觉 × 空间 × 布局 × 交互 × 节奏的协调配置，不是一组颜色变量。POC 阶段要验证的是"房间格局对不对"，不是"壁纸换哪种"。
第二个踩坑是数据嵌入方案。最初想走"外嵌"路线（设计稿和数据分离管理），但 Day 5 验证后发现设计稿匹配难度太大、可行性低。最终决策锁定 dataset 内嵌方案——数据直接作为设计系统的一部分管理。这个决策把后续"分模块出稿、分模块进开发"的策略变为可能。
这两个踩坑共用了 1.5 天——看起来是"浪费"，但它们产出了两个影响全局的架构决策，避免了后续更大的返工。
教训: POC 的价值不在于"做出 demo"——在于用最低成本暴露方向性错误。如果 Day 4 没有试错那个颜色方案，它会在正式开发第 3 周才暴露。
Day 7: 效果演示
POC 演示不是终点——是 PRD 的输入。
演示后收集反馈，分为：
- 确认项（这个可以直接进 PRD）
- 调整项（方向对但需要改）
- 否决项（这个不做了）
Day 8-9: 方案设计
方案设计器基于 POC 结论产出结构化方案：
- 架构图（前后端+数据流）
- 模块拆分（5 个核心模块）
- 里程碑（3 周迭代计划）
- 验收标准（每个模块的 AC）
Day 10: PRD 交付
结晶器把所有验证结论固化为正式 PRD，包含：
- 产品定义
- 技术方案
- 迭代计划
- 风险清单
AI 在过程中的角色
AI 不是决策者——是决策的记录者和结构化者。
它做不了"这个需求应不应该做"的判断。但它能帮你：
- 把散落的决策整理成文档
- 检查"需求文档里说要做 X，但方案里没覆盖 X"
- 从过程记录中提炼验收标准
反思：框架的价值在哪
| 环节 | 没有框架时 | 用框架后 |
|---|---|---|
| 需求 | "先做再说" → 做完发现方向错 | 先收敛边界 → 做的都是确认过的 |
| POC | 做完无记录 → PRD 时重新回忆 | 每日结构化 → 直接复用为 PRD 输入 |
| PRD | 从头写 → 2-3 天 | 基于 POC 结论结晶 → 1 天 |
| 协调 | 各说各话 → 来回对齐 | 边界文档 → 一次锁定 |
框架不是让你更慢——是让你不走回头路。 10 天交付了其他项目通常需要 3-4 周的产出量。
教训
- 边界文档是最好的沟通工具 — "我们不做什么"比"我们做什么"更能减少误解
- POC 的目标是产出"结论"不是产出"代码" — 代码可以扔掉，结论带入 PRD
- AI 辅助记录的价值在 PRD 阶段才体现 — 当天觉得"太详细了"，一周后发现"幸好记了"
- 多角色对齐要一次做到位 — 分 5 次分别对齐不如 1 次拉齐坐一起
复盘核心：方法论不怕简单——怕没人执行。在真实项目中用自己的框架，最大的收获不是"验证了方法论有效"——是发现了方法论中"理论上合理但实操中不顺手"的环节，然后优化它。