从零到一打造AI情绪产品的背后，藏着练手项目的黄金法则。一位产品人通过「月光灯」项目，将泰语塔罗占卜与AI共情结合，实战演练了BRD假设驱动、安全底线分层、LLM双Provider架构等核心方法论。本文揭示如何在非商业项目中建立严谨框架，让每个技术债务和未验证假设都成为可量化的学习成果。

我最近独立完成了一个叫「โคมจันทร์」（Khom Chan，泰语”月光灯”）的 AI 产品，从市场研究、商业分析、产品文档到开发部署，一个人跑完了全流程。

这个产品的背景是：泰国 TikTok 上有大量深夜占卜类视频，评论区里藏着几千条真实的情绪倾诉。我做了一个 Web 端产品，让用户抽一张塔罗牌，AI 用泰语给出共情式解读，然后引导用户写下心事，再匹配”有过同样经历的人”的匿名卡片。

项目定性是「练手」，目标不是商业上线，而是让自己完整经历一次 AI 产品的 0 到 1。

但这篇文章不是讲产品本身，而是讲方法。 做完之后我发现，很多人（包括以前的我）对”练手项目”有一个误区：要么太随意，做完啥也没留下；要么太认真，把自己逼成了一个没有用户的完美主义者。

我想分享的是：怎么在”练手”和”认真”之间找到一个让学习效率最大化的姿势。

一、练手项目的第一件事，不是画原型，是写”成功标准”

很多人开始练手项目的第一步是：打开 Figma。

我的第一步是写 BRD（商业需求文档）。不是因为流程癖，而是因为 BRD 里有一个字段彻底改变了后面的所有决策——is_practice_project: true。

这个字段的意思是：我在最开始就跟自己约定好，这个项目的成功标准不是”上线有用户”，而是”跑通一个完整闭环 + 自己学到东西”。

这看起来是一句废话，但它在后面至少帮我避开了三个坑：

第一，它让我敢砍功能。 原始需求里列了十几个想做的功能，但因为明确了”练手”，我只保留了三个核心功能（塔罗抽牌 + 倾诉表单 + 同款经历卡片墙），其余全部写进了”不做清单”。不做清单有 10 项，比做的还多——这不是偷懒，是纪律。

第二，它让我能接受降级。 后面开发时，数据库（Supabase）没有接入，导致倾诉功能只能走开发环境的兜底逻辑，同款卡片墙永远是空的。如果成功标准是”上线”，这就是失败。但因为成功标准是”跑通闭环”，UI 层面三个功能全部可交互，AI 链路端到端跑通——降级版的完成也是完成。

第三，它让假设验证有了边界。 BRD 里写了 6 条关键假设，其中”流量能从 TikTok 引到 Web 端”这条置信度最低。如果是真项目，这条假设验不过就得停。但因为 is_practice_project: true，BRD 写的是”练手项目接受验证失败，不影响核心目标”。这让我不用在没有泰国 TikTok 合作资源的情况下硬去凑一个虚假的验证结果。

方法论提炼： 任何练手项目的 Day 0，花 30 分钟写下三件事——(1) 这个项目做成什么样算”成功”；(2) 明确列出”不做”的事；(3) 哪些假设你接受在练手阶段验证失败。这三条就是后面所有决策的锚点。

二、假设驱动而非功能驱动：6 条假设的回测实录

我在 BRD 阶段写了 6 条关键假设，每条都带”置信度”和”翻转条件”。翻转条件的意思是：如果现实情况满足了这个条件，这条假设就被推翻，后续决策要跟着变。

做完 V1 后，我逐条回测了这些假设。结果挺有意思：6 条假设里，2 条得到了部分正向验证，0 条被推翻，4 条根本没机会被测。

主要原因是练手项目没有真实用户流量，所有”用户行为类”假设都无法被触发。

其中最值得展开说的是假设 2 —— “LLM 的共情质量能不能达到’不假’的标准”。

原始翻转条件是”上线前测试集主观评分 < 6/10 就必须改用 AI + 人工混合”。实际的结果是：中文版的共情输出超出预期，我设定的 8 条硬约束（不预测未来、不做评判、用画面感而非说教、语气温柔、字数控制、emoji 限制、以邀请倾诉结尾、调性契合”月光灯”产品意象）全部满足。但泰语版没有找到母语者做人工评分，所以只能给”中文高置信 / 泰语中置信”的结论。

这个回测过程本身就是方法论的核心：假设不是写完就扔的东西，它是要拿回来对账的。

具体怎么做回测？我的做法是给每条假设填一张四格表：

这张表的价值不在于”验证成功”（练手项目大概率没机会验证），而在于让你清楚地知道自己在哪些地方还在”猜”。很多人做完项目说”验证了 PMF”，其实只是验证了”我能做出来”，真正的市场假设一条都没碰到。有了这张表，至少骗不了自己。

方法论提炼： 写假设时，每条附带一个可量化的翻转条件。项目结束后，逐条回测，给出”升 / 降 / 维持 / 未验证”的结论。这个动作的目的不是打分，而是制造「诚实时刻」——让你清楚知道哪些认知是有数据支撑的，哪些还是猜。

三、安全底线前置：AI 情绪产品的”不出事”比”体验好”重要

这个产品有一个特殊之处：用户是深夜情绪状态下来的，倾诉内容可能涉及自杀风险。

BRD 阶段我就把”自杀风险识别”列为四条硬约束之首，PRD 里设计了三层防护架构：

第一层是 HARD 关键词拦截。如果用户输入命中了预设的高风险词（比如泰语中明确表达自杀意图的表述），直接跳过 AI 判断，立刻触发防护流程。第二层是 LLM 二次分类。如果没有命中关键词，让 AI 判断这段文字的风险等级。第三层是兜底逻辑：如果 AI 调用失败（网络超时、模型报错），默认按高风险处理，宁可误报也不漏报。

同时产品里有一个常驻的 1413 热线引导横幅（1413 是泰国心理援助热线），设计要求是：绿色而非红色（不制造恐慌）、不阻断用户操作、可以关闭但不强制。

V1 跑完后，这三层架构在代码层 100% 通过了测试用例。但 PRD 里还有一份”上线前 5 项强制检查清单”：

1. 关键词词表由泰语母语者复核
2. AI 分类 prompt 用高风险原声测试全部命中
3. AI 分类 prompt 用普通倾诉测试无误报
4. 热线横幅在 320px 小屏正常展示
5. tel：1413 在泰国实测可拨通

5 项全部未通过。

这是一个很有意思的结论：架构层面的安全设计可以做到 100% 通过，但运营层面的安全验证 0% 完成。两者的差距就是”代码写好了”和”真的能保护用户”之间的距离。

我在 BRD 里写过一句话：”不通过不能上线。” 所以 V1 部署后的验收结论是：练手目标达成，但不允许导入真实用户。

方法论提炼： 做涉及用户安全的产品时，把安全要求拆成”架构层”和”运营层”两张清单。架构层是代码能不能跑通防护逻辑，运营层是这些防护在真实场景下是否有效。两张清单独立打分。架构过了只代表”技术可行”，运营过了才代表”可以上线”。练手项目允许只过第一张，但要明确记录第二张的缺口，不要自己骗自己说”安全做完了”。

四、LLM 选型不要押单注：双 Provider 架构省了我几个小时

PRD 原定用 Claude Sonnet 作为 AI 底座。实际开发中因为网络环境和成本因素，我切换到了另一个国产大模型。

切换过程中踩了不少坑，但有一个架构决策帮了大忙：从一开始就在代码里做了双 Provider 抽象。

具体做法是：AI 调用层不直接依赖任何一家 SDK，而是通过一个工厂函数根据环境变量决定走哪条路径。最终从一个 Provider 切到另一个时，只改了 3 行环境变量，重新部署就跑通了。

这件事让我理解了一个道理：在 AI 产品里，LLM 是最不稳定的依赖。 价格会变、接口会变、服务可用性会变、甚至政策都会变。如果你的代码和某一个 Provider 深度绑定（比如直接在业务代码里 import 某家的 SDK 写调用逻辑），切换成本会非常高。

这个双 Provider 架构不复杂，核心就三件事：

一是统一调用接口。不管底层用谁的模型，业务代码调用的函数签名是一致的。二是 Provider 切换通过环境变量控制，不用改代码。三是保留未启用的 Provider 代码路径作为”死代码”——虽然当前没用，但下次切换时可以直接激活。

方法论提炼： AI 产品的 LLM 调用层，第一天就做 Provider 抽象。不需要过度设计，一个工厂函数 + 环境变量切换就够。这个投资在第一次被迫换 Provider 时就能回本。

五、技术踩坑里也有方法论：区分”值得解决”和”记录跳过”

整个开发过程我记录了大大小小十几个坑。但不是每个坑都值得花时间去填。我发现一个有用的分类方式：把踩坑分成”解决”、”绕开”和”记录但不处理”三类。

举几个例子：

解决类： 开发服务器缓存损坏导致所有页面 500。这种必须解决，否则开发流程都跑不起来。修复方式是先强杀所有残留进程、等进程退出、清缓存、再重启——这个操作后来又复发了几次，变成了标准流程。

绕开类： 包管理工具对原生构建脚本有安全检查，每次都拦住。对于单人练手项目来说，这层防御意义不大，加一行配置跳过即可。但我会在技术债清单里标注”长期应该正式声明白名单”。

记录但不处理类： 开发环境热更新时偶发一个框架内部的竞态错误，生产环境不触发。这种属于框架自身的 bug，我既没能力修也不影响上线，记录下来留个档就行。

这个分类方式的核心在于：不是所有技术问题都是你的问题，也不是所有你的问题都需要现在解决。 练手项目的时间是有限的，把精力花在”能提升认知”的坑上，其他的记录清楚就好。

我维护了一张技术债表，V1 结束时有 13 条（原始 10 条 + 新增 3 条），每条标注了当前状态和是否需要处理。这张表的作用不是催你还债，而是让你对”当前系统还欠着什么”有清醒的认知。

方法论提炼： 踩坑记录三分法——解决 / 绕开 / 记录但不处理。维护一张技术债表，每条标注状态。这张表是给未来的自己（或接手的人）看的，不是用来制造焦虑的。

六、”如果真要做下去”清单：练手结束时最该问自己的 5 个问题

V1 做完后，我写了一份”如果真要做下去必须先回答的问题”清单。这份清单比前面所有文档都重要，因为它标记的是从练手到真实产品之间的鸿沟。

我的 5 个问题是：

第一，专业审核找谁做？ 这个产品涉及心理健康领域，关键词词表、AI 分类规则、热线引导文案都需要泰语母语的心理咨询专业人士审核。理想的人选是泰国心理援助机构的志愿者或大学心理系的从业者，但找到这些人本身就是一个从零开始的问题。

第二，数据合规能不能过？ 产品的冷启动数据来源是公开的 TikTok 评论。即使是公开内容，在情绪敏感产品里做二次使用，是否符合泰国的个人数据保护法（PDPA）？这需要一次法律咨询，费用不低，但绕不开。

第三，流量入口在哪？ 练手项目可以接受零流量，但如果要验证”用户愿不愿意从短视频评论区迁移到独立产品”这个核心假设，唯一现实路径是和泰国本地的 TikTok 占卜类账号合作导流。这需要本地化的商务能力，目前不具备。

第四，运营成本谁来扛？ 项目活着一天就有成本——模型 API 调用费、服务器费用、数据库费用，一个月可能几百块。量不大但会持续涨。什么时候需要开始想付费模式？用户对”被 AI 倾听”这件事愿意付多少钱？这是一个完全没有数据的假设。

第五，AI 共情的伦理边界在哪？ 这个问题是我做完后想得最多的。AI 输出”你比自己以为的更靠近答案”这类话时，确实能让人感到被理解。但产品做得越温柔、越像真人，用户越可能对 AI 产生情感依赖而远离真正的人际支持。这个矛盾不是技术能解决的，需要专门的产品策略——比如在适当时机引导用户去联系真人咨询师，而不是继续和 AI 对话。

方法论提炼： 练手项目结束后，花 1 小时写一份”从练手到真实之间的鸿沟清单”。每一条都应该是你现在回答不了、但真要做的话绕不开的问题。这份清单的价值是：如果你将来真要把练手项目变成正式产品，它就是你的第一份待办；如果你不打算继续，它也能帮你诚实地评估”我到底离真正做成一个产品还有多远”。

七、完整文档体系：一个人的项目也值得留档

最后说一下整体的文档结构。我这个项目最终沉淀了一套完整的文档链：

• MRD（市场需求文档） → 基于近 3000 条 TikTok 评论的原始分析，回答”市场上有没有这个需求”。
• BRD（商业需求文档） → 回答”值不值得做”，包含 6 条关键假设和每条假设的翻转条件，以及最关键的”练手项目”定性。
• PRD（产品需求文档） → 10 个模块的完整规范，从技术栈到错误处理到路线图。最重要的是”不做清单”和”上线前强制检查清单”。
• DESIGN.md → 视觉规范。超过 1000 行，包含暗色和亮色两套设计 token、11 个组件样式定义。
• POSTMORTEM.md → 事实性技术档案。只记录”发生了什么”，不夹带情绪和反思。
• LEARNINGS.md → 第一人称随笔。所有主观感受、情绪、自我反思放这里。

这里有一个刻意的设计：把事实档案和个人反思分成两个文件。 POSTMORTEM 只回答”是什么”，LEARNINGS 回答”我怎么看”。分开写的好处是：如果将来有人接手，他只需要看 POSTMORTEM 就能理解项目全貌，不用在你的情绪文字里筛选信息。

很多人觉得”一个人做的项目不需要写文档”。但我的体会是：文档不是写给别人看的，是写给三个月后的自己看的。那个时候你不会记得当初为什么选了这个模型、为什么砍了那个功能、为什么某个安全检查没做。文档就是你的外部记忆。

方法论提炼： 即使是练手项目，也建议维护三份核心文档——(1) 一份”为什么做 / 不做什么”的决策文档（BRD 级别）；(2) 一份”发生了什么”的事实档案（POSTMORTEM 级别）；(3) 一份”我学到了什么”的反思文档（LEARNINGS 级别）。前两份追求客观，第三份允许主观。

写在最后

回头看，这个项目最大的收获不是”我学会了某个框架”或”我调通了某个 API”——这些技术细节半年后就过时了。

真正留下来的是一套做事的结构：先定义成功标准，再写假设和翻转条件，开发时记录踩坑和技术债，结束后做假设回测和鸿沟清单。这套结构适用于任何从 0 到 1 的项目，不管是练手还是正式的。

如果你也在考虑用一个练手项目来提升自己的 AI 产品能力，我的建议是：

别急着写代码，先跟自己签一份”练手合同”——写清楚做什么、不做什么、怎样算成功、哪些假设允许失败。 然后每做完一个阶段就回头对账。

这些”看起来在浪费时间”的事情，恰恰是让练手不白练的关键。

作者注：โคมจันทร์（Khom Chan）是泰语”月光灯”的意思。本文内容基于项目的完整复盘文档整理。