这个网站是用提示词搭起来的

一切从 Kraftwerk 开始，那是我自己做的力量训练应用。它是我用 Codex 设计的。之后我发现，AWS 账户里那个旧的 WordPress 站点已经跑不起来了。berndkuhlen.de 这个域名我早就有了。那么，为什么不干脆把网站也用 Codex 重新搭一遍？

我提的第一个问题很实在：什么架构做这件事比较省钱？Codex 建议用 S3 加 CloudFront。对个人站点来说，我走了这条路，而没有去用 ECS 加负载均衡器跑容器。

把旧站点再开一次

我把 berndkuhlen.de 下那台装着 WordPress 的旧 EC2 实例又启动了一次，只是为了把内容读出来。与此同时，新站点临时搭在 new.berndkuhlen.de 上。

直到确认我的文章都已经迁移过来，我才把旧的 EC2 实例、WordPress 订阅和负载均衡器都停掉。随后，新的 S3/CloudFront 站点迁到 berndkuhlen.de，还通过 AWS Certificate Manager 配了新证书。我的培训课程和认证是从 LinkedIn 账户搬过来的。

迁移的技术过程我已经在一篇更长的文章里写过。这里我更想说的是，这一切在日常使用中是怎么长起来的。

之后就是一个接一个的想法：显示访问量。接入 Kraftwerk，分享我的训练进度——再见了，跑步 App……；）把之前用 Codex 做的小游戏放进来。写新文章，再把内容翻译成更多语言。

这些全靠提示词。我自己一行代码都没写。 到目前为止最费劲的主要是前端问题：某个东西在一台设备上看着不一样，或者在某个浏览器里不工作。那就打开开发者工具，找问题，再把结果交回给 Codex。

额度也是个限制：我的 OpenAI 订阅大约 23 美元，token 经常比我的想法先用完。那就只能等，或者额外花钱。

十五美元买来的一课

一开始我并没有建立像样的成本控制。一次 CloudFront URL 的全局失效，花掉了我大约十五美元。对这么小的一个网站来说，这是个相当让人心疼的意外。

现在每次改动前都会先做成本检查。在我的项目里，缓存失效是明令禁止的。对象可以让它自然走完正常的缓存时间；并不是每个改动都必须立刻在所有地方可见。

如今这个站点也成了我的小游乐场：彩蛋、更多小游戏，还有一个由 AI 支持的天气页面。我可以随手试试，看看能做到什么。