大家好，r/SoloDevelopment。刚刚完成了第一个真正的个人项目，花费了约6周的晚上和周末时间（每天约2-3小时），并且在一份日常工作（一家SaaS公司的软件开发总监）和两个孩子和一位妻子的情况下。
这是什么：Deduce — 每日的浏览器谜题游戏。每个案件都有4-8名嫌疑人、证人陈述、证据和一个类似克莱朵（Cluedo）风格的指控网格（杀手×武器×地点）。有5个难度级别，每个难度级别的解决时间约为5-20分钟。每天都会推出新案件，现有案件库有250多个。
技术栈：
-
React + Vite 前端（TypeScript）
-
Node + Express 后端（TypeScript）
-
Postgres
-
Playwright用于PDF渲染（用于KDP印刷书籍）——在PDFKit出现布局一致性问题后，改用Playwright
-
Coolify在一台本地Proxmox机器上（通过Cloudflare隧道）
-
自建的Umami用于分析（无cookie，无防御）
-
运行该项目的实际成本：R0/月。案件生成所需的LLM API费用（Anthropic + OpenAI）是根据项目付费的，按批处理，不按每次游戏付费。
难点在哪儿：
- 案件生成流程。LLMs会草拟场景，但经常产生矛盾或模糊的解决方案。
写了一个自定义的解答程序，验证每个案件都有一个逻辑上的唯一解答，才会发布。约有40%的LLM草案被拒绝。
-
指控网格的用户体验。重写了三次。仍然不完全信任它。
-
KDP印刷书籍导出。花费了约5次发布时间来调试一个PDF缓存，结果是它是一个CSS min-height/max-height冲突问题——
min-height: 11in在一个遗留样式表中默默地超越了max-height: 864px !important。教训：在Playwright中使用getComputedStyle，当CSS表现出不正常的行为时。
什么是成功的：
-
日常内容发布计划作为一个强制函数。如果每天必须在午夜发布一个新的案件，就不会再进行无限的润色。
-
将印刷版视为一个侧边产品，而不是一个端口——同样生成案件数据，但渲染为6×9 KDP内页。一个引擎，两个产品。
-
平凡的技术栈。React + Postgres + Node = 没有惊喜，所有问题都是自己的问题。
下一步：
-
移动端用户体验很糟糕（指控网格在窄屏幕上很拥挤）。已知。
-
已经为Instagram的Reels变体做好准备，但尚未渲染。
-
有5本KDP印刷书籍在排队中。
如果你想玩：https://deduce.studio
很高兴回答任何关于技术栈、案件验证器、LLM成本数学或KDP管道的问题。特别是欢迎 Solo dev 的问题。
评论 (0)