用 GPT-5 Codex 搭建小网站的乐趣与挫折

用 GPT-5 Codex 搭建小网站，最后发现，与其说是在敲代码，不如说是在合作。从粗糙草图到精致网站，模型承担了大量实现工作，我则引导方向和设计。

过程中，我既体会到快速迭代的快乐，也发现了依赖 AI 搭档的边界。这些项目渐渐不再只是关于网站本身，也是在探索一种新的编程方式：通过对话、富有创意、有时会出错，却始终让人大开眼界。

# 引言

我一直在尝试用 GPT-5 Codex 搭建小型单页网站。这些项目乍看可能微不足道，却成了新编程方式的试验场。令我意外的不只是结果，还有过程本身的感受：快速、协作，偶尔又以某种令人沮丧的方式，教给我和成功时一样多的东西。

# 为什么选小项目？

我喜欢做小而专注的项目，周末就能完成的小实验。它们快、有趣，还能带来可以分享的实际成果。它们也很宽容：某个方案行不通，很容易转向或重来。这也是它们适合拿来试验 Codex 的原因，风险低，而学到的经验可以带到更大的项目里，在那里，各种限制和注意事项会更加重要。

# 工作流：对话与迭代

整个过程更像聊天，而不是传统编程。我在 Apple Notes 里画个粗略想法，交给 Codex，几分钟后就能得到可运行的网站。然后来回交流：我指出不足，它调整，我们继续迭代。让我印象深刻的不只是速度，还有我可以一直待在规划者和设计者的位置，让 Codex 处理细节。当然，来回配合并不总是完美，有时我们两个都会卡住，这也与后面要谈的局限有关。

# 处理繁琐修改

最令人开心的一次，是我让 Codex 把下面这些私有项目改造成更通用的网站，并公开发布。通常，重命名所有东西、删除私人信息、整理到适合公开的状态，都是苦差事。Codex 一次就完成了其中 95%，我只需微调最后一点细节。

# 项目展示

# 🐾 Project Luna：宠物寻回页面

• 项目：https://github.com/TheClooneyCollection/project-luna
• 演示：https://princessluna.pages.dev/

最初是为我自己的猫 Luna 做的个人工具。在 Codex 帮助下，它很快变成了一个精致、可分享的模板，适合任何需要宠物寻回页面的人。我的角色是勾勒结构、说明细节如何展示，Codex 则处理重命名和布局。

# 🎂 Project Joy：生日与庆祝页面

• 项目：https://github.com/TheClooneyCollection/project-joy
• 演示：https://project-joy.pages.dev/

一开始只是一个用 HTML/CSS 做的惊喜礼物，后来变成了带动画和悬停效果、样式完整的交互式 11ty 网站。我提供概念并引导创意方向，Codex 生成样式，让网站变得精致。

# 🔐 Project Top Secret：Eleventy 口令访问门

• 项目：https://github.com/TheClooneyCollection/project-top-secret
• 演示：https://project-top-secret.pages.dev/

为了让生日内容保持半私密，我做了一套加密与解密机制：Node.js 负责加密，浏览器里的问答负责解密。我确定目标和需求，Codex 编写大部分样板代码，确保流程安全又简单。

# 🚀 Subspace Builder：11ty 博客起步模板

• 项目：https://github.com/NicholasClooney/11ty-subspace-builder
• 演示：https://blog.nicholas.clooney.io/

这是一个采用 Tachyons 实用类的快速 Eleventy 博客起步模板，包含主题切换、无障碍导航和响应式布局。我专注于建立灵活、支持主题的基础，Codex 则处理结构和可复用组件。

# 我学到了什么

下面是进展顺利时，我观察到的一些主要收获。它们不能概括所有情况，下一节也会说明需要留意的限制，但足以看出 Codex 的长处：

• 草图和模糊描述就足以起步，Codex 能很快补齐结构。
• 模型很擅长繁琐、机械的编辑，让我可以专注设计和流程。
• 不用精通 CSS，也能得到现代、干净的网站。
• 和 AI 结对编程，感觉更像合作，而不是委派。

# 挑战与限制

尽管过程顺畅，仍有一些边界和不足需要注意：

• 知识缺口：如果你不知道自己在做什么，Codex 能帮忙，但它给的不一定始终是最好或最可靠的方案。
• 共同盲区：有时你和 AI 都不知道最佳答案，就可能困在死路里反复尝试。
• 方案质量：花了很多时间让东西“能用”，不代表它就是正确或最优的解决办法。
• 缺少反对意见：Codex 会很乐意继续完善一个有缺陷的方案，却不指出“其实有更好的办法”。等你意识到需要换方向，可能已经浪费了不少时间。

# 例子：主题切换的兔子洞

一个具体例子，是我尝试用 YAML 文件中定义的 Tachyons CSS 类来实现博客配色主题，切换主题时用 JavaScript 替换这些类。最初可行，但随着每个主题增加更多颜色，JS 代码越来越臃肿。

后来我才意识到，有一个简单得多、扩展性也更好的方案：把主题颜色定义为 CSS 自定义属性，用 data-theme 属性限定作用范围。每个主题只是一组颜色 token 配置，切换主题变成切换一个属性。尽量交给 CSS，尽量少写 JS。

因为我不知道这个技巧，而 Codex 又没有质疑最初的想法，我们就在一个次优方案里越钻越深，不断打磨。直到发现更好的路径，已经花掉了时间和精力。我的教训是：方向错了，GPT-5 Codex 不会阻止你；但一开始问得更开放，例如“实现主题切换的最佳方式是什么？”，有助于更早找到聪明的方案。

# 与 ChatGPT 合作的建议

这些项目让我意识到，工作流和输出同样重要。我吃早餐或伸展身体时，GPT 可以不断产出实现；但我如何与它合作，决定了事情是顺畅推进，还是陷入混乱。以下做法让过程更有效：

0. 清楚交代上下文。 动手写代码前，先提供整体背景，让模型知道你的目标。
1. 问开放的问题。 不要立刻指定方案，先问有哪些最佳做法，尤其是你不熟悉的领域。
2. 先规划。 让 GPT 在实现前先列出推进路径。
3. 讨论并迭代。 把它当作合作者，一起质疑计划、调整、完善。
4. 让它实现。 达成一致后，让 GPT 承担大量实现工作。
5. 快速迭代。 小而快的修改周期，能避免在错误方向上越走越远。
6. 经常提交。 每次可用的改动都值得保存，避免丢失进展。
7. 对过程负责。 工具加了额外内容，不要只怪工具。如果你只要 A，它却给了 A+B，要么自己删掉 B，要么重置后把要求说得更清楚。
8. 识别上下文限制。 对话开始混乱时，可能该开一个干净的新会话了。

这些习惯让合作有条理、有效率，同时保留创意和探索的空间。

# 最后的想法

这些项目规模虽小，但用 GPT-5 Codex 构建它们的过程让我大开眼界。我不用埋头处理细节，而能享受创造东西时更有创意、更高层的部分。不过，这种编程方式显然仍需要人的判断来把握方向，避开前面提到的陷阱。对我来说，正是速度、创造力和审慎把关之间的平衡，让我相信这种对话式方法不只是方便，也是未来的一瞥。