练手项目方法论

一套让”练手”项目学习效率最大化的方法论框架：从 BRD 定义成功标准、假设驱动开发、安全底线分层到文档三分法的完整实践体系。

简介

练手项目方法论是针对非商业导向的学习型项目所设计的系统化开发框架。它解决的核心问题是：大多数人做练手项目要么太随意（做完啥也没留下），要么太认真（把自己逼成没有用户的完美主义者）。这套方法论在”练手”和”认真”之间找到让学习效率最大化的姿势。

与传统产品开发方法论的核心区别在于：练手项目的成功标准不是”上线有用户”，而是”跑通闭环 + 学到东西”。这意味着假设可以验证失败、功能可以大幅砍减、降级版的完成也是完成——但前提是所有决策和缺口都被记录下来，成为可量化的学习成果。

这套方法论的适用场景是：个人独立开发者、AI 产品新人、想系统性积累产品认知但没有真实用户和资源的从业者。

关键信息

• 类型：方法论
• 领域：产品开发、AI 产品、个人成长
• 提出者：新伟的科技小院（基于「月光灯」AI 情绪产品实践）
• 相关概念：MVP（学习导向的 MVP）、AI产品PRD（文档链设计）、项目复盘（假设回测框架）、BRD 假设回测、技术债三分法

核心特性

BRD 成功标准前置

Day 0 不是画原型，而是写三件事：(1) 项目做成什么样算”成功”；(2) 明确列出”不做”的事；(3) 哪些假设接受在练手阶段验证失败。在 BRD 中设 is_practice_project: true 标记，这个标记是后面所有决策的锚点。实践案例中，原始需求十几项功能只保留 3 个核心，不做清单 10 项比做的还多——这不是偷懒，是纪律。

这个标记带来三个实际收益：敢砍功能（只做核心 3 项）、能接受降级（数据库没接上时 UI 层面可交互也算完成）、假设验证有边界（没真实流量的假设接受不验证）。

假设驱动而非功能驱动

BRD 阶段写出所有关键假设，每条附带”置信度”和”翻转条件”（可量化的推翻标准）。项目结束后逐条回测，填四格表：原始假设 / 翻转条件 / 实际结果 / 置信度升降。

实践案例中 6 条假设的结果是：2 条部分正向验证、0 条被推翻、4 条没机会被测（因无真实流量）。这本身就有价值——清楚知道自己在哪些地方还在”猜”。很多人做完项目说”验证了 PMF”，其实只是验证了”我能做出来”，真正的市场假设一条都没碰到。

安全底线双清单分层

对涉及用户安全的产品（如情绪类、心理健康类），把安全要求拆成两张独立打分的清单：

• 架构层（代码能不能跑通防护逻辑）：关键词拦截 → LLM 二次分类 → 兜底逻辑。允许练手项目只通过这张清单。
• 运营层（防护在真实场景下是否有效）：母语者复核、原声测试、热线实测等。架构过了只代表”技术可行”，运营过了才代表”可以上线”。

两张清单独立打分的实践意义：在案例中架构层 100% 通过但运营层 0% 完成，最终结论是”练手目标达成，但不允许导入真实用户”——这是一个诚实且有边界感的验收结论。

LLM 双 Provider 抽象

AI 产品的 LLM 调用层，第一天就做 Provider 抽象。核心三件事：统一调用接口（函数签名一致）、环境变量控制切换（不改代码）、保留未启用 Provider 代码路径。实践案例中从一个 Provider 切到另一个只改了 3 行环境变量。这个投资在第一次被迫换 Provider 时就能回本。

技术债三分法

把踩坑分成”解决”（必须修否则流程跑不起来）、“绕开”（加配置跳过但标注长期处理）、“记录但不处理”（框架 bug 不影响上线）三类。维护一张技术债表，每条标注状态。V1 结束时 13 条（原始 10 条 + 新增 3 条）。核心原则：不是所有技术问题都是你的问题，练手项目时间有限，把精力花在”能提升认知”的坑上。

鸿沟清单

练手结束后写一份”从练手到真实之间的鸿沟清单”，每条都是你现在回答不了、但真要做的话绕不开的问题。典型问题包括：专业审核找谁做、数据合规能不能过、流量入口在哪、运营成本谁来扛、AI 共情的伦理边界。这份清单就是你的第一份待办——或者诚实评估”离真正做成还有多远”的标尺。

不同素材中的观点

• 2026-05-29-woshipm-ai-emotional-product-practice-methodology：这是本方法论的原始来源。作者通过泰国 AI 情绪产品「月光灯」的完整实践，提炼出从 BRD 成功标准前置、假设回测四格表、安全底线双清单、LLM 双 Provider 架构到技术债三分法的完整框架。核心洞察是”练手项目的学习价值不在于做出了什么，而在于你对自己认知边界的诚实测量”。

实用信息

• 快速上手步骤：

  1. Day 0 花 30 分钟写 BRD，设 is_practice_project: true，定义成功标准、不做清单、接受失败的假设
  2. 每条关键假设附带翻转条件（可量化的推翻标准）
  3. 开发过程中维护技术债表（三分法标注）
  4. V1 完成后做假设回测（四格表）+ 鸿沟清单（5 问）
  5. 维护三份文档：BRD 决策文档 + POSTMORTEM 事实档案 + LEARNINGS 反思文档

• 注意事项/避坑指南：

  • 练手项目的成功标准一旦写好就不要在过程中偷偷改（否则会滑向”太随意”或”太认真”）
  • 假设回测的目的不是打分，而是制造”诚实时刻”——别用”练手嘛”来逃避未验证的假设
  • 安全底线必须在 BRD 阶段就写入，不能开发完了再补

相关页面

• MVP
• AI产品PRD
• 项目复盘
• AI产品经理工作流