用 Claude 做 vibe coding：一天上线一个香港通勝网站（Next.js + Vercel + Cloudflare）

成品：今日通勝
技术栈：Next.js 16 + React 19 + Tailwind CSS 4 + shadcn/ui，部署在 Vercel，域名走 Cloudflare
开发方式：代码全部由 Claude Code 完成，我负责拍板和验收

先说结果

今日通勝 是一个面向香港用户的通勝（黄历）网站，可以查农历、查每日宜忌、按事项挑吉日。

几个数字：

• 从立项到上线：同一天
• 首发页面：51 页
• 生产环境 Lighthouse：性能 99 / 无障碍 100 / SEO 99
• 上线第 12 天，首发页面被 Google 全部收录
• 之后一个月持续迭代，端到端测试近 200 条，目前开放收录 64 页

这篇文章不贴代码，讲的是过程：用 Claude 做 vibe coding，怎样才能得到一个能上线、能持续迭代的成品，而不是一个演示用的半成品。

我理解的 vibe coding

vibe coding 常被理解成「说一句话，AI 把东西做出来」。做演示可以这样，做要长期运营的网站不行。常见的问题有三个：

1. 越改越乱：每次对话都从零开始，AI 不记得之前的约定，改着改着风格就散了
2. 看起来对，实际不对：页面能打开，但细节有错，没人发现
3. 做出来和别人一样：默认配色、默认字体、默认布局，一眼就能看出是 AI 做的

我的做法是把 vibe coding 拆成五步：

定调 → 写规格 → 实现 → 验收 → 沉淀

我不写代码，但每一步都有我要做的决定。下面逐步说明。

第一步：定调——先让 Claude 知道要做成什么样

动手之前，我先让 Claude 做调研，调研结果由我拍板。

调研需求：香港用户搜什么、搜索量多大。结论是「通勝」和「農曆」是主要入口，办事吉日里「搬屋」「入伙」需求最多。

调研同类网站：它们有什么功能、缺什么。结论是同类网站都不写出处，港式用词也不地道。

对齐风格：Claude 一次只问一个问题，逐步确认配色、字体、语气。最后定下来的是纸质通勝的感觉：淡黄纸底、墨色文字，朱红标「宜」，靛蓝标「忌」。

这些结论都写进项目里的一份配置文件。之后每次开新对话，Claude 会自动读取这份文件，不需要我重复说明。

定调阶段定下的三条原则，后来所有页面都遵守：

• 只做香港繁体，用词用港式的
• 每条结论都有出处，历法数据对齐香港天文台的公开数据
• 不做占卜，只讲历法和民俗

第二步：写规格——不直接让它写代码

我不会直接说「帮我做一个吉日页面」。每个页面先让 Claude 写一份规格，我确认后再开工。

规格里有四项内容：

其中对照表必须写明「刻意不做的功能和理由」。如果不写，AI 会倾向于把所有功能都做一遍，最后页面臃肿，重点不清。

第三步：实现——拆成多个角色

我没有让一个对话从头做到尾，而是在 Claude Code 里配置了多个子代理，各自负责一个环节：

这样做有两个好处：

• 每个环节都有产出物，出了问题可以定位到具体环节
• 验收角色不改代码，只出报告，避免「自己写、自己审」

开发完成后，三个验收角色同时运行，各自出报告。发现的问题交回开发角色修复，修完再验收一轮。

另外，每个需求都在独立的工作目录和分支里完成，合并前再同步主干。这样同时开几个对话做不同的需求，也不会互相覆盖。

第四步：验收——把要求写成检查脚本

这是我认为最重要的一步。

对 AI 提的口头要求，下一次对话就可能失效。写进文档的要求，也可能被忽略。可靠的做法是把要求写成检查脚本，不通过就不能合并。

这个站目前有二十多项检查，举几个例子：

相似度检查的作用最明显。曾经有两个年份页面相似度达到 43.5%，肉眼看不出来，是脚本量出来的。修改后降到 20%。

每次踩坑后，我会让 Claude 把这个坑写成一项新检查。检查项越多，后面的产出越稳定。

第五步：沉淀——让下一次更快

每个需求完成后有一个固定动作：判断这次的产出里，哪些可以留给以后的项目使用。

• 通用的组件和写法，回填到项目模板
• 踩过的坑，写进规则文档
• 重复出现的流程，整理成 Claude 的技能（skill）

这个站能在一天内上线，是因为之前做其他站时积累的模板、规则和流程都可以直接使用。vibe coding 的速度主要来自这些积累，其次才是 AI 写代码的速度。

成品：页面结构和各自的作用

下面是 今日通勝 的页面结构：

首页（今日通勝）
├── 通勝主线      月历 → 单日 → 打印版
├── 擇日主线      事项总览 → 事项年页
├── 专题          萬年曆 / 攝太歲 / 公眾假期 / 節慶 / 儀式
├── 知识层        术语总览 → 术语页
├── 工具          公历农历换算
├── 信任层        出典 / 差异说明 / 关于
└── 机器出口      日历订阅 / JSON 数据 / llms.txt / sitemap

页面结构上有三个决定，都是我和 Claude 讨论后定下的。

1. 同一份数据，两个入口。 通勝主线按日期查，擇日主线按事项查。用户的问法不同，入口也分开。

2. 入口页和年页分工。 以公众假期为例，入口页讲不变的内容（制度、顺延规则），年页只放当年数据。两个页面的内容重合度不到 1%。

3. 不是所有页面都开放收录。 站里实际存在的页面远多于 64 个，365 个单日页和 2027 年的全套页面都已做好，但暂不开放给搜索引擎。新站一次放出几百个结构相似的页面，容易被判定为低质量内容。所以首发只放最有把握的 50 多页，其余页面用一个配置开关控制，根据收录数据分批开放。

部署：Vercel + Cloudflare

GitHub (feat → dev → main)
        │  只有 main 触发构建
        ▼
     Vercel  ──── 静态页面
        ▲
        │  DNS 解析
   Cloudflare ──── 域名 + 邮箱转发

• Vercel 负责托管。只构建 main 分支，日常改动都合到 dev，我确认后才发到 main。
• Cloudflare 负责域名解析和 contact@ 邮箱转发。

上线当天的基础配置（DNS 记录、Vercel 项目、域名绑定、分支保护、搜索引擎提交）也是 Claude 通过命令行和接口完成的。我只做了几件必须本人操作的事：购买域名、修改 NS、在搜索引擎后台验证域名所有权。

有一点需要注意：Cloudflare 的 NS 是按域名分配的，不是按账号固定的。我账号下其他域名用的是同一对 NS，这个域名分到的是另一对，第一次填错了。添加新域名时要以后台显示的为准。

必须由人来做的事

Claude 可以调研、写代码、跑测试，但下面这些事需要我自己做：

• 方向性的决定：是否做某个页组、用哪个域名、选哪套配色
• 看实际效果：第一版上线后，页面上红色用得太多，和设计方案不符。自动化检查查不出这种问题。我指出后，定了一条规则「每屏实心红色元素不超过 3 处」，之后没有再出现
• 母语审校：文案是否地道，需要懂粤语的人检查
• 决定发布时间：改动自动合到 dev，发到生产环境必须由我确认

踩过的坑

1. 模板页容易只换变量。 同一套模板生成的页面，如果只有日期和名称不同，就是重复内容。解决办法是让每个栏位都放该页独有的内容，通用说明集中放在入口页。

2. 页面拆得太细。 最初做了「事项 × 年份 × 生肖」的三级页面，共 168 页。这些页面只是上一级页面去掉十二分之一的结果，后来全部撤掉，改为页面内筛选。

3. 触屏设备没有悬停。 日期格的悬停提示在手机上无法触发，后来改成桌面端悬停、手机端点击。

4. 测试也会固定错误。 文案改了，测试断言没有同步修改，测试就会一直失败，或者一直在验证错误的内容。修改文案时要同时修改测试。

5. IndexNow 不通知 Google。 IndexNow 只覆盖 Bing 等搜索引擎。时效性强的页面需要在 Google Search Console 手动提交。

总结

用 Claude 做 vibe coding，我的经验有四条：

1. 先定调，再动手。 把风格和原则写成文件，让每次对话都从同一个起点开始。
2. 先写规格，再写代码。 规格里要写明不做什么。
3. 把要求写成检查。 用自动化检查保证产出质量，不依赖每次人工审查。
4. 每次做完都沉淀。 模板、规则、流程积累得越多，下一个项目越快。

成品在这里：今日通勝，欢迎访问和提意见。