Day 29：零基础做产品的真实教训

29天。1,134次commit。109个PR。9个产品线。

盘盘猫坐在代码与产品堆成的山顶，望着夕阳沉思

而我到现在查天干是什么还得翻资料。

这篇不是系列总结——前六篇已经覆盖了。这篇写的是最后两天的基础设施工作，以及那几个我留到最后才动的硬骨头。

Portal主题Bug：开发时看不出来，上线就炸（PR #67）

每个应用都有自己的CSS主题：.theme-hub深蓝色，.theme-tarot神秘紫，.theme-bazi传统红。9个应用，9种视觉风格。

然后React portals把它们全搞坏了。

createPortal(content, document.body)把DOM节点渲染到document根节点，完全跑到了应用主题wrapper外面。.theme-hub上的CSS变量，modal和dropdown里根本看不见——因为CSS继承走的是DOM树，不是React组件树。

第一次修（PR #64）很丑：每个modal组件用closest('.theme-hub')检测自己在哪个主题里，硬编码一个.theme-hub-overlay类。9个主题、13个用portal的组件，逐个打补丁。完全不可扩展。

PR #67才是正确的解法：

• ThemeProvider — React context，应用布局声明当前主题类

• useThemeClass() — hook，从context读当前主题

• ThemedPortal — 替代createPortal(content, document.body)，用正确的主题类加MutationObserver监听暗色模式包裹portal内容

9个应用布局更新，13个portal组件迁移，之前的逐组件hack全部移除。

这种bug开发时看不出来——你一次只测一个应用。到了生产环境，用户打开一个modal，颜色全是错的。

弹性AI流式传输：用户断网了怎么办（PR #105）

整个项目最大的基础设施PR。56个文件。

问题很直接：用户在流式传输过程中断网了（手机上很常见，中国网络环境尤其常见），整个测算结果丢了。积分也扣了。

用户体验：花了钱，什么都没拿到。

解决方案：服务端流式缓冲。 19条AI流式路由全部通过StreamBufferManager将数据块缓冲到stream_buffers数据库表：

AI Provider ──stream──▶ Server (ReadableStream)
                           │
                    ┌──────┴──────┐
                    │             │
              SSE to Client    Periodic flush
              (real-time)      to Supabase DB
                    │             │
                    ▼           ▼
              User sees      Buffer saved
              live stream    for recovery

客户端断开后，通过GET /api/stream/{id}恢复完整响应。一个统一的useAIStream hook替换了14个组件中3种不一致的SSE消费模式。/api/cron/cleanup-streams定时任务每15分钟清理过期缓冲。

有意思的是：加了这整套弹性基础设施，代码反而净减少了186行。统一的hook比它替换的3种模式更简洁。

加东西反而代码变少了——这是架构做对了的信号。

内容过滤器v3：被现实教训出来的三次迭代（PR #104）

• V1：DFA关键词过滤。包含敏感词的消息整条封掉。简单粗暴。

• V2（PR #78）：流感知过滤。但遇到敏感词会截断整个流——用户积分扣了，只拿到残缺的测算结果。体验极差。

• V3（PR #104）：行内遮罩。敏感词替换为**检测到违禁词**，流不中断。

V3的架构是双重过滤：

• 输入过滤（严格）：AI处理之前拦截广告、政治、色情、违法内容

• 输出过滤（宽松）：同样的分类但去掉了"广告"——因为算命AI自然会生成兼职、招聘、桑拿这类词，粗暴的关键词过滤会误杀正常内容

流式过滤器做边界安全遮罩：先对完整的累积缓冲区做遮罩处理，再分割为已释放/待判定部分，确保跨数据块边界的词也能被捕获。

6个测试文件，158个测试。

每次迭代都是被用户的真实痛点逼出来的。第一版"够用了"，第二版"好像有问题"，第三版"终于对了"。

i18n集中化（PR #102）

标签定义散落在3个地方：历史记录弹窗、积分历史映射、历史配置。180行的行内标签映射以略有不同的格式重复出现。

PR #102把所有内容整合到packages/i18n/src/labels/下的两个集中文件：features.ts（应用名称、短标签、子类型标签、图标、时间过滤器、历史标题）和actions.ts（约60个积分操作标签）。

消费方减少223行，集中源增加607行。以后新增标签只改一处。

中国AI法规合规（PR #83）

法律页面拆分成中英文两版，带语言切换UI和浏览器语言自动检测。新增内容：

• 生成式人工智能服务管理暂行办法

• 深度合成管理规定

• 算法推荐管理规定

加上PIPL跨境传输机制、敏感个人信息同意、自动化决策透明度、72小时内监管通报的5步数据泄露应急程序。

面向中国用户做AI产品，这些不是可选项。而且每一条都不简单。

这个项目到底验证了什么

这个项目从来不是关于算命的。

它验证的是一个假设：一个工程师，借助AI，能不能在一个自己完全不懂的领域，从零做出一个真正的多产品平台？

答案是能。领域知识的鸿沟可以跨越。开发速度是真实的。

而做一个完整的产品——不只是工程部分——是我这几年做过最有意思的事。

完整系列：第1篇（为什么做）、第2篇（怎么做）、第3篇（经验教训）涵盖了浓缩版的故事。这些日记是原始的、逐日记录的版本。