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