一个人跑完 AI 情绪产品从 0 到 1，我沉淀了一套练手项目复盘方法论
一位产品人独立完成 AI 情绪产品「月光灯」全链路后，提炼出练手项目从定义成功标准、假设回测、安全底线前置到文档沉淀的完整方法论。
基本信息
- 来源类型：文章（网页）
- 原文位置：raw/articles/2026-05-29-232241-tg-51aba4.md
- 原文 URL：https://www.woshipm.com/pd/6398208.html
- 作者：新伟的科技小院
- 发布日期：2026-05-19
- 消化日期：2026-05-29
核心观点
-
练手项目 Day 0 先写”成功标准”而非画原型：在 BRD 里设
is_practice_project: true，明确成功标准是”跑通闭环 + 学到东西”而非”上线有用户”。原始需求十几项功能只保留 3 个核心（塔罗抽牌 + 倾诉表单 + 同款经历卡片墙），不做清单 10 项比做的还多。这个字段后来帮作者避开三个坑：敢砍功能、能接受降级、让假设验证有边界。 -
假设驱动而非功能驱动的回测框架：BRD 阶段写 6 条关键假设，每条带”置信度”和”翻转条件”（可量化的推翻标准）。V1 完成后逐条回测——6 条中 2 条部分正向验证、0 条被推翻、4 条没机会被测（因无真实流量）。核心收获：假设不是写完就扔的东西，要做四格表（原始假设 / 翻转条件 / 实际结果 / 置信度升降），制造”诚实时刻”。
-
AI 情绪产品安全底线必须分”架构层”和”运营层”独立打分：产品涉及深夜情绪倾诉和自杀风险。架构层设计三层防护（HARD 关键词拦截 → LLM 二次分类 → 兜底高风险），100% 通过测试。但运营层 5 项强制检查（泰语母语者复核词表、AI 原声测试、热线实测等）全部 0% 完成。结论：架构过了只代表”技术可行”，运营过了才代表”可以上线”。产品允许只过架构层，但必须明确记录运营层缺口。
-
LLM 双 Provider 架构是 AI 产品的第一天投资：原定用 Claude Sonnet，实际因网络和成本切换到国产大模型。因代码里从一开始做了 Provider 抽象（工厂函数 + 环境变量切换），切换只改 3 行环境变量。核心三件事：统一调用接口、环境变量控制切换、保留未启用 Provider 代码路径。LLM 是 AI 产品中最不稳定的依赖——价格/接口/可用性/政策都会变。
-
技术踩坑三分法 + 技术债表：把坑分成”解决”（必须修否则开发跑不起来）、“绕开”（加配置跳过但标注长期应正式处理）、“记录但不处理”（框架 bug 不影响上线）三类。V1 结束时技术债表 13 条，每条标注状态。核心原则：不是所有技术问题都是你的问题，也不是所有问题都需要现在解决。练手项目时间有限，把精力花在”能提升认知”的坑上。
-
练手到真实产品之间的 5 个鸿沟问题：(1) 专业审核找谁做（泰语母语心理咨询师）；(2) 数据合规能不能过（TikTok 公开评论做二次使用是否符合泰国 PDPA）；(3) 流量入口在哪（需本地化商务能力与占卜账号合作）；(4) 运营成本谁来扛（API + 服务器持续费用 + 付费模式假设未验证）；(5) AI 共情的伦理边界（产品越温柔用户越可能产生情感依赖而远离真人支持）。
-
练手项目的三份核心文档：POSTMORTEM（事实档案，只记录”发生了什么”）、LEARNINGS（第一人称反思，主观感受和情绪）、BRD（决策文档，为什么做/不做什么）。刻意把事实和反思分开——接手人只需看 POSTMORTEM，不用在情绪文字里筛选信息。文档是写给三个月后的自己看的外部记忆。
实操内容保留
操作步骤：BRD 假设四格表
每条假设填一张四格表进行回测：
| 格 | 内容 |
|---|---|
| 原始假设 | 具体描述 |
| 翻转条件 | 可量化的推翻标准 |
| 实际结果 | V1 后的真实数据/观察 |
| 置信度变化 | 升 / 降 / 维持 / 未验证 |
操作步骤：安全底线双清单架构
架构层清单（代码层面）：
- HARD 关键词拦截 → 高风险词直接跳过 AI 触发防护
- LLM 二次分类 → 未命中关键词时 AI 判断风险等级
- 兜底逻辑 → AI 调用失败默认按高风险处理
运营层清单（上线前强制）：
- 关键词词表由泰语母语者复核
- AI 分类 prompt 用高风险原声测试全部命中
- AI 分类 prompt 用普通倾诉测试无误报
- 热线横幅在 320px 小屏正常展示
tel:1413在泰国实测可拨通
操作步骤：双 Provider 架构三件事
- 统一调用接口：不管底层用谁的模型，业务代码调用的函数签名一致
- Provider 切换通过环境变量控制，不用改代码
- 保留未启用的 Provider 代码路径作为”死代码”
操作步骤：技术踩坑三分法
| 分类 | 判断标准 | 处理方式 |
|---|---|---|
| 解决 | 不修则开发流程跑不起来 | 立即修复，记录为标准流程 |
| 绕开 | 单人练手项目下该层防御意义不大 | 加配置跳过，标注到技术债清单 |
| 记录但不处理 | 框架自身 bug，生产环境不触发 | 留档记录 |
操作步骤：练手结束后 5 问鸿沟清单
- 专业审核找谁做？
- 数据合规能不能过？
- 流量入口在哪？
- 运营成本谁来扛？
- AI 共情的伦理边界在哪？
关键概念
- MVP — 本文的练手项目本质是”学习导向的 MVP”，成功标准不是上线有用户而是跑通闭环
- AI产品PRD — 作者维护了完整的 BRD → PRD 文档链，PRD 包含 10 个模块、不做清单和上线前强制检查清单
- 项目复盘 — 本文核心就是一套练手项目的复盘方法论：假设回测 + 鸿沟清单 + 文档三分法
- 练手项目方法论 — BRD 假设驱动 + 成功标准前置 + 安全底线分层 + 技术债管理的完整框架
- AI产品安全底线 — AI 情绪产品的架构层+运营层双清单安全设计范式
- LLM多Provider架构 — AI 产品第一天就做 Provider 抽象，工厂函数+环境变量切换
- BRD假设回测 — 6 条假设各带翻转条件，项目结束后逐条填四格表制造”诚实时刻”
- 技术债三分法 — 解决 / 绕开 / 记录但不处理，维护技术债表标注状态
与其他素材的关联
- 与 2026-05-18-woshipm-ai-product-prd 的关系：后者讲 AI 产品的 PRD 重构实践，本文提供了更完整的 BRD → PRD → POSTMORTEM 全链路文档体系，并且重点区分了”事实档案”和”反思文档”
- 与 2026-05-27-woshipm-project-review-sop 的关系：后者提供通用复盘 SOP 流程，本文提供了练手项目特有的复盘框架——假设回测四格表和鸿沟清单
- 与 2026-05-09-ai-pm-c-end-0-to-1 的关系：后者讲 AI PM 的 C 端从 0 到 1 MVP 实战，本文更侧重”练手”而非”正式产品”的定位差异和方法论
原文精彩摘录
很多人（包括以前的我）对”练手项目”有一个误区：要么太随意，做完啥也没留下；要么太认真，把自己逼成了一个没有用户的完美主义者。我想分享的是：怎么在”练手”和”认真”之间找到一个让学习效率最大化的姿势。
架构层面的安全设计可以做到 100% 通过，但运营层面的安全验证 0% 完成。两者的差距就是”代码写好了”和”真的能保护用户”之间的距离。
在 AI 产品里，LLM 是最不稳定的依赖。价格会变、接口会变、服务可用性会变、甚至政策都会变。如果你的代码和某一个 Provider 深度绑定，切换成本会非常高。
不是所有技术问题都是你的问题，也不是所有你的问题都需要现在解决。练手项目的时间是有限的，把精力花在”能提升认知”的坑上，其他的记录清楚就好。
AI 输出”你比自己以为的更靠近答案”这类话时，确实能让人感到被理解。但产品做得越温柔、越像真人，用户越可能对 AI 产生情感依赖而远离真正的人际支持。