Show HN：用 AI 在 275 次提交里改造我的婚礼登记网站
- 首页
- 简历
- 项目
- 技术写作
- 非技术
- 邮箱
- benhoyt.com
- benhoyt@gmail.com
用 AI 在 275 次提交中更新一个业余项目
2026 年 8 月
最近公司放年中假，大家几乎在同一时间段休了两周。作为一个管理者，我之前用 AI 工具主要做代码评审和技术探索，而不是真正写代码，这次我想改变一下。
于是我把这段假期花在了业余项目 Gifty Weddings 上。早在 2016 年，我就把它迁移到了 Go 后端，2019 年又换成了 Elm 前端。而现在我有两个目标：
- 把它从一个单纯的婚礼礼品登记处，升级成婚礼网站搭建工具。
- 学会如何用 AI 工具写出高质量的代码。
在同事的推荐下，我大部分编码工作用的是 Claude Code（搭配 Opus 5）。小任务则用 Pi 配合开放权重的 GLM 5.2 模型。当然，我也用了我自己的脑子。
开个玩笑，但我确实认为，会不会用自己的脑子，是“批量产出垃圾”和“做出自己满意的产品”之间的分水岭。我们仍然是工程师。
这篇文章里，我会谈谈我对 AI 的怀疑，也聊聊我认为这次项目能做成的原因，以及我为什么乐在其中。
我的怀疑
我对 AI 的怀疑已经持续了相当长一段时间。最早是看到 AI 聊天机器人和《纽约时报》记者“谈起了恋爱”；后来又要不停应付那些“贡献者”们灌进来的海量 AI 垃圾内容，怀疑自然就更深了。
2024 年我试过用 AI 写代码，当时并不觉得惊艳。那会儿我花在修补它产出上的时间，比我自己从头写一遍还要多。
最近我又试了一次：几乎一口气把我妻子的室内设计网站搭了起来，然后又用它修了 GoAWK 里的好几个 bug（其中有一个 bug，Opus 4.6 表现得相当犹豫）。
这两次都让我印象深刻：网站那次，是因为我本来就不爱写 CSS；修 bug 那次，是因为它确实大大加快了进度，还给了我不少好点子。
我的做法
先交代一下背景：我本人算是一名经验比较丰富的 Web 开发者。这意味着我有能力引导整个开发流程，也能有效审查 AI agent 产出的代码。顺带一提，我对 AI 最大的担忧之一，就是新手开发者可能会想走捷径，跳过这些来之不易的经验积累。
同时，这次的改造也不是从零开始，而是建立在已有工作的基础上。我的起点包括：旧网站的 CSS 样式表（这套样式又源自 Skeleton 框架）、一份大体的 SQL 数据库表结构，以及我对最终成果的规划。此外，Go 服务端的初始版本和几个核心包是我亲手写的，很大程度上参考了旧版 Gifty 代码库。我先按自己想要的风格埋下代码种子，再让 AI 在这个基础上继续生长。
之后我转向迭代式开发，而不是试图一口气全部搞定：每个阶段，技术和创意上的主导权都握在我手里。每次改代码，我先描述想要的功能——通常只是几句 prompt——然后审查生成的代码，并在浏览器里实际测试这个功能。
代码审查我保持中等强度。有些写代码时的讲究我只能放弃——它产出的代码风格并不完美，很多情况下也不是我会采用的写法。当然，该提的 bug 我会提，结构性问题我也会提出质疑，但总的来说，它生成的代码我还是比较满意的。
不过，测试部分我没有仔细审查。AI agent 似乎特别爱写测试——有时候甚至写得过多，我删掉了一些我认为得不偿失的。一开始我还会看看细节，到后来基本就是草草扫一眼。
在这个过程中，我学到了不少东西：
-
大语言模型（LLM）写注释非常啰嗦。我得反复要求它写得简洁一些，或者只写一行摘要。有一次提交专门做「注释精简」，我把大约 2500 行注释压减到了 1500 行。
-
当我让 Claude 安装一个无头浏览器（headless browser）、自己截图之后，它写 HTML 和 CSS 的水平明显上了一个台阶。在此之前，截图得由我手动截好再上传给它。现在它简直有了超能力：自己启动服务器，通过应用里真实的表单填入模拟数据，再用 Chromium 保存 PNG 截图，然后「看着」这些截图调整代码。
不过，每次改动都截图处理，token 消耗实在太大。后来我只让它在大改前端时才截图。
即使把 Claude 关在容器这个沙箱里跑（我用的是 Canonical 的 Workshop），它还是会干出些让人头疼的事。有几次它执行了类似 rm -rf $SOMEVAR/*.png 的命令，但 SOMEVAR 根本没设置，结果把我在用的测试照片给删了。我在它的记忆里加了几条规则，想让它别再这么干——不过话说回来，跑 LLM 一定要放在容器或虚拟机里。
别想在一个会话里干完所有活。我一开始就是这么做的，结果上下文越来越长，很快就撞上了 Claude Pro 的各种限额。于是我去了解了上下文压缩（compaction）机制，并开始定期开新会话。
接下来看看我做了哪些功能。
功能
Gifty 可以让一对新人创建一个简单的多页面婚礼网站，包含照片、文字和礼品清单。（旧版 Gifty 只支持礼品清单部分。）
新人可以用 Markdown 区块写文字、上传照片（照片会压缩后存在 Tigris 上）、添加页面和调整顺序等等。当然，我也会收点小钱；支付用的是 Stripe。
宾客可以查看新人的网站，并在礼品清单上划掉自己要送的礼物。
不过我最喜欢的功能是从旧版 Gifty 继承来的：新人可以一键试用。
技术栈
我向来喜欢简单，所以用了这些技术：
- Go 后端，尽可能少用非标准库依赖：AWS SDK 负责上传，Stripe SDK 负责支付，一个图片缩放库，一个 Markdown 渲染器，
modernc.org/sqlite模块，以及几乎可以算标准库的golang.org/x/crypto模块。 - 出色的 SQLite 数据库。
- Htmx 负责比较动态的部分：礼品清单和页面编辑支持。
- 在合适的地方写几行原生 JavaScript。
网站托管在 Fly.io 上——做这类事情我强烈推荐这个服务：fly deploy 部署非常方便，而且便宜。
心怀感激
完成这个新网站大约花了整整 10 天。我非常感谢 AI 工具，尤其是这次的 Claude。我跟妻子说，要是没有 AI，大概得花三倍的时间。
最让我印象深刻的一件事，是 Claude 把旧版礼品登记系统迁移到了新架构。旧版是 Go 写的 JSON API，前端用 Elm；新版则改成 Go 直接渲染 HTML 端点，前端换成了风格很不一样的 htmx。它几乎一遍就把这件事做对了，既让我惊喜，也省下了大量时间。
另一件几乎一遍就完成的事（后面只补了几个 bug），是写了一个迁移工具，把旧的 Gifty 数据库搬到新库。这倒不是什么高深技术，两个库结构相似，只是有几处不一样。我原本以为要多迭代几轮才能搞定。
但问题来了：我平时对 AI 整体上挺怀疑的，为什么这次却这么享受？我觉得有两个原因：
第一，我喜欢亲手做出东西。大约 10 天，我就完成了一个既实用又好看的网站。
第二，我喜欢编程这门手艺，而这个过程仍然给了我这方面的满足感。我会想下一个功能，让 AI 写代码，然后我审代码、修 bug、提交。就这样循环往复了 275 次。小功能大概 10 到 15 分钟，大功能一两个小时；最棒的是，我能感觉到自己在不断向目标靠近。
我依然有很多担忧。希望我们不会用这些工具去盖一座通天塔，逼得上帝不得不来挫一挫我们的锐气。不过，对于这些新工具，我始终心怀感激。