ENZH

Day 1:不懂算命的我开始做算命了

今天推了21个commit。到最后,一个5个应用、多个共享包的monorepo跑起来了,还有了一个可能真会变成产品的雏形。

一只戴着玄学帽子的可爱猫咪坐在电脑前写代码一只戴着玄学帽子的可爱猫咪坐在电脑前写代码

但先倒回来说——一个在Airbnb、Apple和AWS写过CTO级别基础设施的工程师,怎么就去做算命了?

写了这么多年代码,我腻了

在大厂当工程师有个问题:你会变得特别特别擅长实现别人定义好的需求。

做基础设施,搞系统扩展,做影响千万用户的架构决策。但你永远不碰那些最乱的部分——GTM策略、定价页文案、"为什么转化率是2%而不是4%"这种让人头疼的问题。

那些事,都有人干。你只管写代码。

我想做一个完整的产品已经好几年了。不只是工程。产品设计、用户反馈闭环、商业决策,所有环节,全部自己来。

没有PM写PRD,没有设计师递Figma稿,没有增长团队帮你搞留存。

所以我找副项目时,就给自己定了一个限制条件:它必须在一个我完全不懂的领域。

偏偏选了算命

八字、占星、塔罗、解梦、六壬——我一无所知。零。连"日柱"是什么都说不上来,更不知道出生时辰为什么重要。

这正是重点。

我想验证一个假设:AI能不能完全弥补一个领域的知识盲区? 不是"AI能不能帮专家提高效率"——而是一个对某领域零基础的人,能不能仅靠AI,做出一个可信、有用的产品?

还有个现实角度。中文市场的命理分析需求巨大,但数字化严重不足。现有的大部分应用不是广告农场就是一段话生成器。

说白了,这个赛道又大又烂,正适合搅局。

搭Monorepo:概念简单,实操全是坑

第一个commit:"Initial monorepo setup with Turborepo。"5个现有的Next.js应用搬进apps/,共享代码抽成packages/

概念上很简单对吧?实际操作——每一个import路径都会报错,每一处Tailwind配置冲突都冒出来。

最终的包结构:

  • packages/api — AI模型抽象层、SSE流式传输工具

  • packages/auth — Supabase认证上下文、弹窗、匿名用户处理

  • packages/credits — 积分扣减、余额检查、费用常量

  • packages/database — Supabase客户端、生成的类型定义、SQL迁移

  • packages/ui — 共享组件(AppHeader、Footer、ChatPanel)

  • packages/config — 统一的Tailwind、ESLint、TypeScript配置

第4步和第5步(修import、验证构建)占了80%的时间。

但前期这些痛苦,就是后面一切变轻松的原因。

AI不只是写代码的工具

我把Claude Code当主要开发工具。不是那种把代码贴进去的聊天机器人——是一个真正的编码agent,能读代码库、理解包结构、跨文件做修改、跑测试、反复迭代。

领域知识这块更有意思。我问"八字日柱的计算原理是什么?",得到的不只是解释,而是可运行的TypeScript代码——天干地支循环表、五行生克矩阵,甚至夏令时切换的边界情况,全写好了。

你想想这种感觉:我在做一个AI比我更懂业务的产品。

AI是领域专家,我是产品经理和架构师。角色完全反转了。

第一天收工

到午夜,monorepo能构建了。5个应用全部跑起来。共享认证正常。Supabase客户端统一了。

一次登录,一个积分余额,五个产品。

21次commit。一个monorepo。对算命的了解——依然是零。

技术栈

  • Monorepo:Turborepo

  • 框架:Next.js(App Router)

  • 数据库/认证:Supabase(Postgres + RLS + 实时订阅)

  • AI:Claude + Gemini — 多模型架构,通过PostHog feature flags控制每个端点

  • 样式:Tailwind CSS,每个应用有独立的design token主题

  • 语言:全栈TypeScript(strict模式,16个包共享类型)

  • 部署:Vercel

盘盘猫手记Part 1 of 7
← PrevNext →

© Xingfan Xia 2024 - 2026 · CC BY-NC 4.0