Steam to Calendar 突然火了

今天非常开心，这两天其实没管 Steam to Calendar 这个项目（我周末全顾着打守望先锋了，连着打了两天啥都没干），但是晚上看 umami 的时候，居然发现怎么突然火了，还这么多印尼的

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

同时让 Codex 去分析用户卡点，去读自部署的 umami，看看事件统计，分析下用户是哪一步卡住的，然后开 goal 自己去迭代

同时在准备一篇 blog 记录全流程，我大概整了些素材和大纲出来，下面是我和 ChatGPT 的对话

我一般习惯先把要写的内容、素材等等列出来，然后再看怎么组织出来，我目前想到这些（后面可能还有更多），你帮我组织一下，列个大纲

前言：一些背景信息，包括个人，项目，和现状（项目今天有100多个访问），全程靠 AI 没写过一行代码

为什么要尝试做独立产品

目前大厂工作不满意、《纳瓦尔宝典》想做独立开发

灵感来源

在 V 站看到 weather in calendar，与 ChatGPT 称赞为什么别人总是能想到这么好的idea，并且让他发散思维

与 gstack 进行产品定位对话

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

生成多种设计效果图、生成 logo图

感觉 image2 生图确实好，使用Codex，ChatGPT，banana nano来回倒腾

开发原型

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

期间遇到的主要问题

数据源问题，调用 steamdb，以及其他数据源，最终尝试写一个独立的 Steam CLI 把这部分工作分离

我以为是在写代码，其实是在做产品

因为你后面其实花了大量时间：

Logo

Hero 区

Landing Page

域名

名字

文案

甚至比写代码时间还长。

不断重构，包括重新命名项目，重新进行用户定位，重新设计 CTA，生成新的设计图，

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

疯狂打磨 UI 与交互

关于 AI 生成 UI 方面的一些技巧和感悟（为什么 AI 生成的网站很没有品味，其实是因为大多数人本来也没有什么品味）

指出问题，让 Codex 自己在浏览器里模拟操作，截图、不断修正迭代

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

上班也在远程指挥 Codex，下班之后一直干到凌晨 3 点实在困的不行，把 plus 榨干，入了 100 刀的 Pro，然后把 Pro 的周配额榨干，最终想起来去年开了 TRAE 的一年Pro（当时因为有 Claude），现在登上去其实感觉能力差距还挺大，每天限制自己的可能有两件事，一件是困，一件是 Codex 的 5h 配额

部署上线

给他 Vercel 的 skill 以及 cli，基本上全程自己动手，以及看日志什么的

V 站推广

当天 post 有几百浏览，4 个 star，有收到几个人的鼓励

用户数据分析，与自动化迭代

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

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

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

未来架构演进展望

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

使用 Cloudflare Page + Cloudflare Worker，提升性能

最终感悟

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

最后补一个 Codex 自己总结的项目关键时间线

关键时间线 2026-05-20 晚上：项目出生。 21:00 左右 GStack /office-hours 开始，主题还是 Wishlist in Calendar。21:04 Git 初始化。21:32 左右生成设计文档 Wishlist in Calendar — Weekend Magic Feed，核心问题是：能不能把 Steam wishlist 的时间节点放进用户真正使用的系统日历。22:02 到 22:40 做了工程计划 review，定成 Weekend Prototype。

2026-05-21 凌晨：第一版原型跑起来。 00:04 feat: build Steam wishlist calendar prototype，之后很快接上 Steam wishlist service API、模拟 calendar preview、prototype progress docs 和 preview UI polish。这个阶段重点还是 wishlist release dates + .ics subscription。

2026-05-21 深夜到 2026-05-22 凌晨：你开始追问“没有用户信息时能拿什么 Steam 数据”。 Claude 记录里你说“我昨天其实用 codex 改了不少”，然后问“不提供用户信息的情况下，我们能拿到什么 steam 数据”。这里第一次把产品从纯 wishlist 往 公共 Steam 活动/促销日历 推。接着你要求研究 SteamKit，最后判断 SteamKit 不适合直接当数据源，更适合的是 Steam Store 公开 events JSON endpoint，加本地 seed fallback。

2026-05-22 01:04：Logo 方向出现。 Claude 记录里你说想做一个 Steam logo 和日历结合的 logo，已经下载了正版 Steam logo。这个时候产品还叫 wishlist in calendar，但品牌视觉已经开始往“Steam + Calendar”的组合靠。

2026-05-23 凌晨：steam-cli 成为核心数据来源。 02:41 Integrate steam-cli for Vercel deployment，03:03 Organize assets and load public preview dynamically。这很关键，项目不再只是前端/手写数据，而是开始把 steam-cli vendored 进来，服务 Vercel 部署和运行时数据。

2026-05-25：方向从 wishlist-only 转成 Steam calendar。旧 docs/current-status.md 写得很直白：产品方向已经从 “wishlist releases only” 移到 Steam to Calendar。同一天 Git 里有 Build Steam sale calendar experience、Redesign Steam sale calendar、移动端 UI、list view、event range 等提交。GStack learning 也记录了你偏好的定位：直接说“把 Steam 游戏和事件放进系统日历”，不要抽象品牌词，也不要只叫 Sale，免得窄化。

2026-05-26：疯狂 UI/产品打磨日。这一天有 35 个 commit，是整个项目最密集的一天。包括 Refine Steam to Calendar UI positioning、setup panel、ready step、subscribe CTA、mobile spacing、region/currency、game image ratio、Vercel analytics 等。这个阶段产品从“能用”变成“像一个真的应用”。

2026-05-28 凌晨：Claude 记录里开始以 steam-to-calendar 作为新项目路径做代码质量审查。 ~/.claude/projects/-Users-nx-Workspace-steam-to-calendar/… 里有多轮 senior review，关注结构是否专业、src/features/calendar-builder 是否是干净 composition root、runtime validation 和层边界是否足够好。最后一轮给了 PASS，并说 required changes 是 None。这说明在正式 commit 前后，你已经把它当成一个可教学、生产风格的 Next.js 项目在审。

2026-05-29 22:36：正式重建为 Steam to Calendar。 f4ecc8c Rebuild as Steam to Calendar 是大节点：改产品名、删除旧 docs/design assets、移除 src/lib catch-all，把架构拆成 app / features / domain / integrations / server / shared。品牌资源也从 wishlist-in-calendar-logo.png rename 成 steam-to-calendar-logo.png。

2026-05-31 凌晨：再次打磨公开定位。 GStack 新项目 nickxudotme-steam-to-calendar 里生成了 Deal-first positioning for Steam to Calendar。核心用户原话是：这个产品“能无感在日历查看最近关注的游戏打折情况”。这时定位变成：wishlist 是输入方式，不是产品本身；核心价值是低噪音地把关注游戏的折扣/发售/预购/活动放进系统日历。

2026-06-01：wishlist preview 开始流式化。 17efff5 Stream wishlist preview updates 增加 NDJSON streaming，让连接 wishlist 后可以先逐步显示 wishlist games，再等最终 calendar preview。这是体验从“等接口返回”变成“逐步有反馈”的节点。

2026-06-02 到 2026-06-03：移动端、地区、币种、文案细节收口。这里包括移动端 intro sheet、locale selector、wishlist rate-limit 友好文案、历史价格币种格式化、币种 mismatch note、region refresh 时显示 loading currency。.gstack/browse-startup-error.log 也在 2026-06-03 00:02 留下一条浏览器启动失败记录，和当时本地/浏览器验证不太顺的记忆对得上。

2026-06-03 到 2026-06-04：从产品变成可观测的生产服务。先加 observability events，再切到 Umami，后来改成 self-hosted Umami，加 server analytics、ops reporting script、session replays、preview telemetry。到 2026-06-04，项目已经不只是能生成日历，而是能看部署和用户行为信号了。

我看完之后有个感觉：

你现在列的是开发日志。

但真正有价值的其实是：

一个后端开发者如何借助 AI，在 14 天内完成第一个真实产品。

所以我建议不要按照时间顺序写。

而是按照「认知变化」组织。

因为很多读者根本不关心你哪天 commit 了什么，他们关心的是：

你为什么做？

怎么做的？

遇到了什么问题？

AI 到底能做到什么程度？

最后有什么收获？

⸻

我会这么组织：

Steam to Calendar：14 天，从一个想法到一个真实产品

前言

关于我

腾讯云 DBA / SRE

后端开发出身

不会设计

不会前端

关于项目

Steam to Calendar

一句话介绍

关于现状

上线时间

GitHub Star

V2EX 数据

当前访问量

以及最重要的一句话：

整个项目几乎完全由 AI 辅助完成，我没有手写过一行业务代码。

⸻

第一章为什么我要做独立产品

大厂工作与理想的落差

工作内容

对未来的思考

《纳瓦尔宝典》

为什么影响这么大

我想验证什么

不是赚钱

而是验证：

一个人能不能把脑海里的产品真正做出来

⸻

第二章一个偶然出现的 Idea

Weather in Calendar

V2EX 上看到的项目

那个让我羡慕的瞬间

为什么别人总能想到这种 Idea

ChatGPT 的发散

从天气开始

扩展到：

Steam

游戏

愿望单

最终形成 Wishlist in Calendar

⸻

第三章 AI 像一个产品经理一样挑战我

这里其实特别有意思。

GStack 连续追问

用户是谁

为什么需要

为什么用日历

怎么传播

为什么不是 App

产品定位不断变化

Wishlist in Calendar

↓

Steam Events

↓

Steam Sale Calendar

↓

Steam to Calendar

我第一次意识到

产品定位比代码重要

⸻

第四章我以为在写代码，其实在做产品

这是全文最精彩的一章。

Logo

域名

Hero 区

Landing Page

CTA

文案

名字

花的时间远超编码

⸻

第五章 AI 时代的开发方式

设计图生成

ChatGPT

Codex

Banana

Image2

来回切换

为什么 AI 生成的网站总有股 AI 味

这一段可以写你的思考

很有价值

我是怎么修的

截图

标注

重新生成

继续截图

继续改

AI 更像实习生

需要持续指导

而不是一句 Prompt 出奇迹

⸻

第六章开发过程中踩过的坑

数据源问题

Steam

SteamDB

SteamCLI

最后为什么独立成 CLI

⸻

AI 屎山问题

3000 行 TypeScript

越来越难维护

⸻

用 AI 审查 AI

这是非常好的标题

让 Codex 开 Goal Mode

跑 3 小时 40 分钟

几十个 Sub-Agent

互相 Review

最终重构

⸻

不断推翻自己

产品名

定位

设计

架构

全部重来过

⸻

第七章最疯狂的那几天

这里可以写得有画面感。

上班远程指挥 Codex

凌晨三点还在调 UI

Plus 配额打光

开 Pro

Pro 配额也打光

想起还有 Trae Pro

这部分其实特别有独立开发者味道。

⸻

第八章部署、上线与推广

为什么选择 Next.js + Vercel

给 AI 配置 Vercel CLI

第一次真正上线

发到 V2EX

收获几个 Star

收获一句「牛逼」

收获第一次陌生人认可

⸻

第九章产品上线后才是真正开始

这个标题很好。

Analytics

Vercel

↓

Umami

Self-hosted Umami

让 Codex 自己 SSH

自己部署

自己创建 Tunnel

自动分析用户行为

看用户卡在哪一步

自动给出改进建议

⸻

第十章 Steam to Calendar 是怎么一步步长大的

这里直接放时间线。

你的时间线素材非常好。

用 Timeline 形式即可。

2026-05-20

2026-05-21

…

2026-06-04

让读者看到：

原来这个项目真的是一点一点长出来的。

⸻

第十一章 AI 改变了什么

这是全文真正想表达的东西。

构建能力越来越廉价

产品能力越来越重要

设计能力越来越重要

运营能力越来越重要

想法不再稀缺

执行与判断才稀缺

⸻

结语

这个项目成功了吗

也许没有

这个项目失败了吗

也没有

它最大的价值是什么

让我第一次完整经历：

发现问题

产品设计

开发

上线

推广

用户反馈

迭代

这一整条链路

⸻

我觉得这样组织以后，这篇文章会从：

「Steam Calendar 开发记录」

变成：

「一个后端工程师借助 AI 完成第一个真实产品的全过程」

后者的传播性和长期价值会大很多。因为几年后你自己回来看，真正重要的也不是 Steam，而是这次从 0 到 1 的经历。