我用 Vibe 在两个月内用 Cursor + Cloudflare 编写了每日塔罗应用——AI 目前（尚）做不到的
Source: Dev.to
Introduction
几个月前，我对一个项目有了明确的想法：打造一个干净、免费、每日塔罗阅读网站，让人们可以抽牌并获得有意义的解读——没有付费墙，没有暗黑模式，也没有“你的未来被封锁，升级解锁”。其成果是 dailytarot.io，一个功能完整的塔罗阅读网页应用，提供单卡、三卡、凯尔特十字以及是/否布局，并配备完整的 78 张牌意义库。为了实现它，我大约用了 两个月 的随性编码——这段旅程让我深刻体会到 AI 的优势所在，也明白了它绝对无法取代人类眼光的局限。
技术栈：为何我全力投入 Cloudflare
当我启动项目时，我想要一个尽可能简单的托管方案，同时还能在网站意外走红时实现扩展。我最终选择了 Cloudflare 全栈组合：
- Cloudflare Pages – 托管前端
- Cloudflare D1（边缘 SQLite）– 存储卡牌数据、牌阵和解读
- Cloudflare R2 – 存储卡牌图片和静态资源
这三者的美妙之处在于它们无缝集成。D1 绑定可以直接在 Pages 函数中使用，R2 只需通过环境变量即可访问，整个流程通过一次 GitHub 推送完成部署。零冷启动焦虑，免费额度慷慨，而且没有 AWS 账单的痛苦。如果你正在构建一个内容丰富的副项目且还未尝试 Cloudflare 的全栈方案，dailytarot.io 基本上就是它能实现的现场演示。
工具：Cursor + 两个不同的 AI 大脑
我的主要编码环境是内置 Composer 1.5 的 Cursor。它是我的主力马——生成路由处理程序、构建卡片展开 UI、编写 D1 查询逻辑、搭建组件脚手架以及迭代布局。Composer 非常适合持续的、多文件的“构建此功能”会话，你基本上是在与 AI 进行配对编程，并让它在整个代码库中保持上下文。
为了解决调试问题，我单独引入了 Claude Opus 4.6。每当出现细微或令人困惑的错误时——比如 D1 迁移未正确应用、卡片展开的状态管理 bug、R2 预签名 URL 在本地可用但在生产环境失效——我会把相关上下文粘贴到 Opus 中，让它推理问题所在。这两个模型在处理棘手调试任务时的推理深度差异十分明显。Opus 往往能找出真正的根本原因，而不仅仅是提供表面的修补建议。
工作流程
- Composer 1.5 – 快速搭建脚手架并迭代
- Claude Opus 4.6 – 当出现不合常理的情况，需要真正的推理时
- 重复上述步骤，部署到 Cloudflare Pages
Source: …
AI 真正吃力的部分：塔罗牌含义
这里有件事没人会告诉你，关于构建塔罗应用：最难的不是代码，而是内容。
dailytarot.io 包含全部 78 张塔罗牌——大阿尔克那以及小阿尔克那的两种花色——每张牌都有正位和逆位的含义，并覆盖多种解读情境（爱情、职业、健康、总体指引）。这是一大堆解释性内容。
我最初的假设是：“我只要让 AI 生成所有牌义，快速审阅一下，周末就能搞定。”我大错特错。
AI 生成的塔罗牌解释的问题
当我让 AI 模型生成塔罗牌含义时，得到的文本流畅、格式良好，但常常在对真正使用塔罗牌的人来说重要的细节上微妙地出错。这些问题大致可以归为以下几类：
- 语气不匹配 – 传统塔罗解释有其特定的语域：它是反思性的，而非指令性的。AI 生成的文本往往倾向于使用通用的自助语言（例如“拥抱你内在的力量！”），或是过于 ominous（不祥）的警告，这在有人在糟糕的一天抽到倒置的塔时会让人非常不安。
- 上下文不一致 – 一张牌的含义会根据在展开中的位置而显著变化。三剑在“过去”位置的解读与在“未来”位置的解读截然不同。AI 常常给出忽视位置细微差别的含义，甚至在不同展开类型之间自相矛盾。
- 对神秘细节的准确性漂移 – 某些牌携带特定的传统象征——如 Rider‑Waite 的图像、Thoth 系统的变体、数理关联——AI 往往随意出错或将它们混合成一个大杂烩。对塔罗有了解的用户会立刻失去信任。
- 对倒置牌的错误正负倾向 – AI 模型有明显的倾向去软化倒置牌的含义。倒置牌并非“正位含义的稍微负面版本”——它们常常承载完全不同的原型重量。AI 一直在把这种区别扁平化。
我必须采取的做法
我最终对 每一张牌的含义进行手动审查。不仅仅是粗略浏览——我对照传统来源，检查位置逻辑，调整语气，并重写了那些微妙误导的章节。这就是把原本的“两周项目”拖长到两个月的原因。
AI 在这里仍然有用——它是一个出色的初稿引擎，也是我在尝试阐明 为何 某个含义感觉不对时的好对手。但最终必须由人工对每一个实际出现在 dailytarot.io 上的解释作出决定。对于一个人们在生活中脆弱时刻抽取卡牌的产品来说，“够好”的 AI 输出是不可接受的。
实际上 Vibe 编码的样子（好的一面）
我不想对 AI 编码体验显得过于负面——因为就 code itself（代码本身）而言，Composer 确实带来了变革。它真正帮我省下的地方如下：
- 快速特性脚手架 – 说出“添加一个包含这10个位置的凯尔特十字牌阵，将抽取结果存入 D1，并使用卡片翻转动画显示结果”，然后看到 Composer 在几分钟内生成完整的路由、数据库模式和 React 组件。
- 一致的命名和类型 – AI 让我的 TypeScript 类型在前端和 D1 查询之间保持一致，减少了手动重构时常见的来回修改。
- 快速原型 UI 状态 – 我可以请求一个“卡牌抽取视图的加载骨架”，立刻得到一个与现有设计系统匹配的可复用组件。
- 零配置 CI/CD – Composer 添加了必要的
wrangler.toml和 GitHub Actions 工作流文件，使每次推送都能自动构建并部署到 Cloudflare Pages，无需额外配置。
当然，缺点在于内容方面（见上文）。但在底层实现上，AI 增强的工作流把个人两个月的工作量转变成了类似小团队冲刺的感觉。
结论
AI 可以为你编写的 代码 加速，尤其是当你对想要的架构有清晰的脑中模型时。
在涉及 特定领域、细微的内容——比如塔罗牌解读时——AI 仍然需要有经验的人类参与，进行验证、纠正和润色。
如果你对技术栈或工作流感兴趣，欢迎访问 dailytarot.io，看看这两个月实验的成果。祝编码愉快（抽牌顺利）！
Composer‑Powered “Vibe Coding”
我构建的内容
我使用 Composer 在短短两个月内搭建了一个全栈、AI 驱动的塔罗牌阅读网页应用。成果是 dailytarot.io —— 一个免费、可投入生产使用的网站，它：
- 提供完整的 78 张塔罗牌牌组
- 支持多种展开方式（例如，凯尔特十字、三张牌）
- 为每张牌提供人工审核的解释
- 完全运行在 Cloudflare 边缘（无需管理服务器）
为什么 Composer 成为游戏规则改变者
| 功能 | Composer 的帮助方式 |
|---|---|
| 全栈脚手架 | 在几秒钟内生成完整的 React + Cloudflare Pages Functions 框架。无需手动配置路由、API 端点或构建工具。 |
| Cloudflare 集成模板 | 自动填充 D1/R2 绑定声明、wrangler.toml 配置以及 Pages Functions 的环境引用。省去为每个新集成查文档的时间。 |
| CSS 与响应式布局 | 生成响应式卡片网格、展开图示和卡片翻转动画，无需在 Flexbox 与 Grid 之间纠结。 |
| 迭代速度 | “把卡片图片往左移，令解释独立滚动” → 大约 30 秒内完成。反馈循环非常流畅。 |
构建内容 + AI站点的经验教训
如果你正在规划一个 AI 生成内容为核心（而非仅作开发辅助）的产品，请记住以下要点：
-
为内容质量保证预留实时预算
AI 是首稿机器，而不是出版者。 请分配人工审阅时间，尤其在准确性或语气重要时。 -
领域知识不可替代
我之所以发现 AI 的塔罗牌含义错误，是因为我事先学习过塔罗牌。在不熟悉的领域构建几乎使 AI 内容质量保证变得不可能。 -
区分“快速构建”和“深度思考”模型
- 使用轻量模型（例如 Composer）进行快速迭代。
- 在调试和需要大量推理的任务中切换到重量级模型（例如 Opus）。
这可以在需要时节省预算，同时保留深度。
-
Cloudflare 的免费层对副项目来说出乎意料地好
D1、R2 和 Pages 组合在你花费一美元之前就能处理相当数量的流量。对于像 dailytarot.io 这样的项目，它基本上是免费生产基础设施。
结果
dailytarot.io 已上线，免费，并且涵盖完整的塔罗牌套组，提供多种排阵类型。每个含义都经过人工审查，且该应用运行在 Cloudflare 的边缘网络，无需管理任何服务器。
我会再做一次吗？当然会。
当时两个月感觉很长，但如果没有 AI 的帮助，同样的项目至少需要 六个月——或者我根本不会去做。“氛围编码”并不意味着“无需判断”；它的意思是 你负责判断，AI 提供速度。
如果你今天抽到一张牌，我希望它是好牌。 🃏