张艺泷.

独立开发者。喜欢把"看起来很复杂"的产品拆成可解释的小块，再用尽量少的依赖把它们组装回去。 Yilong 是我用来证明这条路径的项目。

工程信条

宁可少做一个动效，也要多写一行类型。视觉上的高级感来自留白和节奏，不是更多的渐变。

我会在 README 里写清楚什么是 Roadmap、什么是已实现 — 装做『全都做完了』是面试一眼的扣分项。

AI 推荐如果讲不清打分逻辑，就不要叫 AI。Yilong 的推荐是规则化协同过滤，每一项分数都能溯源。

一个项目的质量不只由"做了什么"决定，更由"刻意没做什么"决定。下面是 Yilong 的关键取舍：

为什么是 Next.js App Router 而不是 Vite + React?
需要 SEO + 动态 metadata + ISR 边缘缓存。RSC 还让我把 Supabase 调用直接放进组件，省掉一层 API 路由。
为什么是 Zustand 而不是 Redux/Jotai?
购物车是高频写入但作用域窄的全局态，Zustand 50 行解决；远端态交给 React Query，本地与远端分离是当前最佳实践。
为什么 RLS 写在数据库而不是应用层?
权限下沉到 Postgres 层。即使应用代码出 bug，用户也读不到别人的订单。多租户场景里『安全是默认开』。
为什么没接 LLM?
餐饮推荐场景不需要黑盒。规则化协同过滤透明、可调试、零成本，效果对 11 道菜的样本足够好。引入 LLM 反而是反向工程。
为什么没上 Redis?
现在没有真实热点 key、没有跨实例需求。Next.js 的 ISR 已经在边缘缓存。如果接入 Redis，我会先在 Supabase 边上跑 Upstash，把订单状态机的派生值缓存（如门店队列长度），不会乱缓存菜单。

如果你在做相关的产品 / 工程问题，或者只是想对项目提建议，欢迎直接在 GitHub 开 Issue 或 Discussion。