虽然是一个半月之前的事情，但是我觉得还是值得记录一下，那种折腾的快乐令人难忘

只是一个三分钟热度的玩具项目，你现在读这篇文章的时候可能已经烂掉了，但能收获三分钟的激情与快乐，又有何不可？

同时这是我第一次纯 Vibe Coding 与上线的项目，收获了不少经验和感受（可以说这个项目的预期成果就是产出一篇博客， 一直拖着没写，看我今晚就给它写完）

TLDR，我做了什么？

Steam to Calendar：可以把 Steam 愿望单游戏的打折、发售等信息同步到系统日历里，逻辑大概是这样的

用户粘贴 Steam 个人页 URL
→ 获取愿望单
→ 补充游戏价格、折扣和发售数据
→ 生成可订阅的 ICS 日历
→ 用户添加到 Apple / Google / Outlook Calendar

PS：这里的孤山独影和苏丹的游戏我在夏促的时候入手了，爬山这因为手柄在家里没带到深圳，不是很好玩 （其实我一直也不习惯手柄） ，但是苏丹的游戏真的太上头了，非常的有意思

---

灵感

首先是在 V 站逛到 Weather in Calendar ，我想这个项目有点意思，可以在日历里看近期的天气，然后让 ChatGPT 发散下，就得到的这个项目的 idea

那一天是 5 月 20 号（你可以翻一下当时的 https://everyday.nickxu.me/ ）

当晚一直用 gstack 打磨产品定位，不断提问题挑战我，细化产品定位，受众人群，传播渠道，盈利途径等（虽然是玩具项目没考虑盈利）

---

MVP

然后就准备动手了，动手之前先设计用户界面，生成多种效果图

第一版比较吸引到我的是这样的，之后一直向这方面迭代打磨（当时项目还叫 Wishlist in Calendar）

最开始还有就是决定技术栈，本来想在 Cloudflare 部署的，以及使用一些比较前沿的框架与技术栈，最终为快和好，使用了 Next 和 Vercel 部署，毕竟这个是 AI 最拿手的

当天凌晨搓了个 Demo 出来，接 Steam API，找各个组件库里面适合的日历控件，但是找不到，后面还是指导 Codex 仿照 macOS 的日历 App 搓了个差不多的

第二天开始折腾数据源，这里的数据包含 Steam 用户、游戏详情打折、活动等信息，一开始想用 SteamDB ，但可惜不提供 API，然后去看背后用什么，当时搞了挺久

第三天开始折腾 logo，感觉 image2 生图确实好，使用Codex，ChatGPT，banana nano来回倒腾

后面还是打算把数据源的事情先解决了，我尝试把数据源的事情单出抽出来完成，做了一个 Go 写的 CLI

SteamDB 不能用，最后打折信息是用了个第三方平台

算是把 Demo 搓出来了

---

疯狂打磨

后面的就是不断重构、推倒重来、重新梳理产品定位、疯狂打磨细节，这是我觉得最疯狂的一个星期

包括产品名字转变等等（改成 Steam to Calendar）

第二版让我眼前一亮的是这个 UI， CTA 清晰了不少，后面基本就照着这个做的

当时的各种细节真的忙不过来（可以看后续一些日子的 everyday），开 Codex 窗口排队的消息就有 5、6 条

晚上折腾到 3 点多真的困的不行才上床睡觉，然后 Codex 还在那慢慢处理我那个队列里的修改意见

第二天早上起来接着看什么效果，上班了在手机上远程指挥 Codex 干活（当时也在测试移动端）

然后把 Plus 榨干了，入了 100 刀的 Pro（当时还没有重置这种东西），然后把 Pro 的周配额榨干，最终想起来去年开了 TRAE 的 一年Pro（当时因为有 Claude），现在登上去其实感觉能力差距还挺大，每天限制自己的可能有两件事，一件是困，一件是 Codex 的 5h 配额

这里当时记得有个比较严重的 AI 屎山问题，写了一个 3000 行的 ts，最终让 Codex 开 goal 模式，要求不断起 subagent 评价项目指出可修改项，并进行修改，然后再起，我当时给的目标是评价这个项目有没有到教科书级别的实例项目，最终自己跑了 3 小时 40 分

各种细节打磨吧，搞了一个多星期的样子，各种用户界面和文案的修改（想想看，我们要向用户传达哪些信息），UI 修改和 bug，就指出问题，让 Codex 自己在浏览器里模拟操作，截图、不断修正迭代

关于 AI 生成 UI 方面的一些技巧和感悟：为什么 AI 生成的网站很没有品味，其实是因为大多数人本来也没有什么品味（如果你知道想要做出怎样的效果，你最终会不断收敛到那个目标，所以，审美和设计能力很重要）

遗漏的未解决问题：感觉 AI 不是很能做成希望的那种风格，文字有时候没法描述清楚，同时我其实也不是很会画画

最终 6 月 1 号感觉可以部署上线了

---

部署与运营

部署和运营也是全部交给 Codex 的，接入 Vercel MCP，GitHub CLI，Cloudflare CLI 和 MCP

我基本没怎么动手

然后在 3 号 V 站发了个贴，当天 post 有几百浏览，4 个 star，收到几个人的鼓励

https://v2ex.com/t/1217566#reply4

随后想做用户数据分析，与自动化迭代

尝试使用 Vercel event，但是要钱，转 umami，毕竟这个我之前的 blog 也一直用

umami 的 reply 功能也要钱，幸好是开源的，直接自己部署一个，让他自己 ssh 到我的 macmini，在 k8s 集群上自己起实例，自己用 Cloudflare CLI 创建 tunnel 穿透出去

让 Codex 自己连到自托管 umami ，查看与分析数据，分析用户卡点（我们有很多事件，看用户是在哪一步卡住的，还有reply可以看）

运营其实也没怎么运营，就自然放在那，后面有一天突然火了，一堆印尼的访问

而且是真实访问，我都有 reply 能看见操作了什么

之后我让 Codex 在 CTA 各个阶段加事件，然后推断用户在哪个阶段放弃的，让 Codex 去分析用户卡点，去读自部署的 umami，看看事件统计，分析下用户是哪一步卡住的，然后开 goal 自己去迭代

未来架构演进展望，现在有个问题是单点访问 Steam 很容易 429，并且 CLI 是 Go 写的意味着要把这个集成在前端里面（我们部署是一个纯 vercel）

所以可以把 SteamCLI 改造成 ts 的 sdk，更加利于集成

同时使用 Cloudflare Page + Cloudflare Worker，分布式请求 API，提升性能

---

最终感悟

从中我愈发清醒地感觉到构建基本可以交给 AI，反而是产品、设计、运营相关的技能越来越重要

所以后面我开始读《人人都是产品经理》，短板是要去补的

设计方面我也很欠缺，一直在想新的个人站点要是怎样的设计语言，但是一直没想好

大概就这么多？折腾下来确实是非常的开心😄