SeatView · 聚合日本live场馆真实座位视角图的网站 | 比起开源推广，还是聊聊零代码基础的我，怎么做这个CF全栈项目的

• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

[!tip] 观前提醒：或许这个仓库fork并二开或者使用源码的场景不太存在，于是除了 开源推广 这个tag外，更多的还是想聊聊作为真的0代码基础的我是怎么样vibe出一个这样的项目的。所以分区放在了 开发调优 板块

[!info] 因为找不到合适的tag，所以就用 动漫 和 旅行 两个tag合二为一了。至于为什么是这么合二为一的，后面会解释。

为什么做这个

在过去的两年里，为了看演唱会，大概去了几次日本旅游。我们称其为现地[1]。

[!example] 这就是为什么我打动漫和旅行tag的原因了

其中，看演唱会当然少不了抽选[2]和抢票的环节。但是抽选的时候抽哪个等级的座位，抢票的时候抢哪个等级的座位，以及开票了之后自己的座位究竟看起来怎么样[3]，都是不清楚的。

其实这就很像我们买电影票或者买剧院的票，你在买票的时候肯定是想知道这个座位具体的视野是怎么样的，有没有需要注意的事情，看看过来人有没有什么踩坑或者推荐的地方。

其实在国内有个小程序叫「梅溪湖行程单」，做这个网站很大一部分的灵感来源于它。可以查看有数据的剧院中其他用户提供的座位信息。

So，我就在想，为什么我不干脆也直接做一个网站，用户只需要在官方的座席图上点击标点，然后就可以添加自己的视角照片。上传的人多了，场馆多了，在出国看live的人群里传播起来了，就自然能发挥它的作用了。

大概梳理完自己的想法是在5.24的晚上，这个东西正式上线测试是在5.27，速度比我想象中的快。还得是朋友的Max20还有站内的GPT公益发力了。

链接在下面：

本体：

SeatView · 真实视角图集

坐进那个座位之前，先看清它真正的视角。

Github仓库（已在Readme添加L站链接）：

GitHub - Sallyn0225/seatview: 聚合日本演唱会场馆真实座位视角图的网站 · Real seat-view photo atlas...

聚合日本演唱会场馆真实座位视角图的网站 · Real seat-view photo atlas for Japanese concert venues (Astro + Cloudflare Workers/D1/R2)

这个网站能做什么？

其实已经在上面的Why部分差不多说清楚了。

• 可以在已有分享数据的场馆，查看其他人分享的座席位置和对应的照片
• 可以上传自己去过的场馆对应的位置和照片供其他人查看
• 如果场馆列表中没有场馆，可以提交场馆，进入暂存区，待开发者维护

经过周三、周四两天的测试，目前已经有 200+ 张图片，其实对这个速度来说还是比较满意的，毕竟我在小红书和B站还没来得及发呢（这两个平台群体画像会更符合一些）

设计上有什么选择

这一块确实不是我擅长描述的部分了，大概省流一下然后用截图吧。网站是Astro框架的，所有服务均依赖于Cloudflare，D1 + KV + R2 + Worker 都有，而且免费额度肯定是足足的够用了。这么设计一方面除了成本的考虑，另一方面就是我确实比较害怕把纯AI写/审的项目丢在我自己的服务器上，故考虑静态页面。

设计网站上由我想需求AI实现的

• Fuse.js：场馆多了看列表不现实，用这个进行模糊搜索，让中文/日文/罗马音都能够命中。
• 客户端做图片处理而不是服务端：browser-image-compression 压图片大小，转webp，去EXIF敏感信息
• 我做网站的习惯：深浅色模式+自动检测，i18n支持。
• KV限速+CF人机验证：KV做每日计数限制，Cloudflare Turnstile过个人机验证。
• ZeroTrust的后台管理页面：这东西蛮新颖，没有密码，管理后台只能走信任邮箱接码，CC给的方案我就直接用了。

聊聊开发的心路历程了

Trellis确实是神中神

站内佬做的Trellis这个框架应该是现在最好用的harness框架之一了。

Trellis - Trellis Doc

面向 10+ AI coding 平台的一站式 AI 框架和工具集

过去我的开发流程，在碰命令行之前，还是会先找个聊天AI，比如Gemini，让它反问我问题，我给出回答，然后逐渐完善我的需求文档。

但是Trellis本身就内置了brainstorm的流程，加feature或者某些大改动甚至像我这样从零到一的情况，基本就会先触发brainstorm的流程。在这个环节如果你的改动很大，那么可能AI会问你十几二十个问题，然后再帮你写好PRD文档和spec文档。很大程度上能让你的需求更加清晰，避免跑偏。

此外，在CC下，大改动会派发子代理，对于我这个从零到一的项目，最开始我就只有一份我自己写的PRD草稿。在经过上述的流程完成了PRD和SPEC后，CC自动拆任务，然后依次调用子代理进行实现。而主代理只负责每次的检查，跑了三个多小时下来，context才用了20%左右。

另外，Trellis的有个“错题本”的功能，其实就是 trellis-update-spec 这个命令，也会自动触发。在完成了一个任务之后他会自动沉淀这次可以沉淀的经验，如果中间他犯错了而你把他纠正回来了，那么这个触发的概率就会大大提高（当然最好你手动）下次碰到类似的情况的时候，他就不会再犯。

另外就是完成了一个任务之后他会把这次的内容记录下来存档。而.trellis是共用的，也就是说，你可以CC干完了活，然后让Codex继续的时候，他可以接着上次的记忆继续干。当然如果任务没干完的话，直接 /trellis:continue 换Agent也能读到同一份需求。

前端真得用 impeccable

之前应该是分享过，这东西已经越更新越好用了。

[!fail] 但是还是不要让GPT从零到一做前端捏

在过去我一直使用的是 A\ 官方的 frontend-design 和 ui-ux-pro-max 以及其他一些零零散散的 skill 来帮我写前端，总体来说比较分散，没有形成一个比较好的流程。 今天搜到了一个类似整合包的内容： 下载下来之后是一个压缩包，包含了多个 skills，但每个 skill 都有不同的用途。 [image] 比方如果我想要从实际的体验角度来审查一下我的 UI…

做这个网站的时候，就先teach一下，让它出一份 PRODUCT.MD 和一份 DESIGN.MD，确定整体的设计方向。然后可以考虑先 impeccable shape 一下你要确定什么部分大致长什么样，我配合Trellis好像会自动保存到Trellis的Research文件夹下面。

出文档这一部分比较花时间，但是基本上是可以出和你设计方向大差不差的前端的。

不过很神奇的是我明明没有提任何A\相关的设计风格，给我做出来还是一股子A\的味道

善用Git和Github

之前已经讲过一次，issue, branch都用起来

2.5 使用git做好版本、分支管理

当这个项目属于是“能跑”但是功能还没有完全完善的程度，不要着急，可以开始进行你的第一个git了，因为这个的版本已经经过了你的测试，是可以用于生产的了。写好你的提交，提交不用AI写也行，自己标注好就可以。

我不太确定我这么做的流程是否正确，望大佬指正。

然后！不要在这个分支进行更改了！创建一个新的分支，叫什么 dev, test 啥的都行，让你自己可以看懂这是一个“不稳定”的版本就可以。你的操作应该在这个分支上进行改动。在测试过后OK了，你才应当进行PR然后merge到main分支的操作。

理论上，在加一个新功能的时候，你应该创建更细的分支，如 dev/add-fallback 这样的分支，这样你可以同时开发多个功能，并且测试单个功能是否的可靠程度，然后在merge进dev分支和其他的功能进行测试。在测试完成并且合并之后，如果这个功能之后你不打算迭代或者更新了，那么也可以选择把这个子分支给删除，保证你仓库的简洁美观。

在之前我是一直在main分支上改的只能说真的不符合操作规范的地方太多了。还好项目是只有我一个人自己用所以暂时影响不大，团队开发这么做是要命的。

在提交了第一个git之后，我还会让AI根据当前仓库的进度，根据最开始生成的那一份开发文档，列出当前的进度，完成了什么内容，还有什么内容没有完成。然后根据自己的想法和AI的计划模式，将剩下的任务拆分成更细小的任务来一步步完成。Git的核心就是在于小提交，这样对后续维护代码会比较方便。

2.5.1 我对issue的用法

一般我做小玩具，基本上这个仓库只会有我一个人用，但是Issue我也是照样自己提。自己找BUG，找可以加的功能，然后自己提交issue。在dev分支自己调试，commit的时候带上issue编号。测试无误之后，PR然后merge的时候close掉issue。

2.5.2 我对release的用法

其实这个地方我用的不是很多，我的大部分玩具都是网页版且可以直接丢到serverless平台玩玩的东西。所以这个地方我能发的附件也就只有自动打包的源码，不过在我感觉比较重要的commit或者merge之后，我会发布一次，按照以下的原则：

• 大的提交原则：eg. v1.0.0 数字分成三个部分
• 第一部分数字：大版本，觉得做的很牛逼的，大升级的加这个
• 第二部分数字：小版本，加了新的功能新的特性改这个
• 第三部分数字：修复版本，一般代码疏忽了或者发现自己写出屎了紧急修复了改这个

也是门外汉理解，不知道这么命名是否真的符合开发规范。

基本上就是这些了！现在有了5.5，Opus 4.8, DS-V4-PRO，比我之前折腾自己的玩具项目的时候已经要轻松不少了。

或许什么时候我得踏出一直在做静态页面的舒适圈，去做点真正跑在服务端的项目了。当然，在保证代码安全性和壮硕性的前提下。

不过暂时没有什么灵感了，技术还是服务于产品的，没有灵感的话那我选择暂时先不做

1. 在当地/现场观看Live演出（即亲自到场看演唱会、Live表演等） ↩︎

2. 指通过抽签或摇号 ，来决定谁能获得购买限量商品、演唱会门票或参与特定活动的资格 。 ↩︎

3. 日本的大部分演唱会座位为开演前3天公布或入场的时候才能知晓 ↩︎

1 个帖子 - 1 位参与者

阅读完整话题