如何用 Claude 進行 vibe coding,一天上線香港通勝網站「今日通勝」(Next.js + Vercel + Cloudflare)
如何vibe coding一天上线一个网站(Next.js + Vercel + Cloudflare)
作者分享以 Claude Code 進行 vibe coding,並在一天內上線香港通勝網站「今日通勝」的實戰流程。方法分為定調、寫規格、實現、驗收和沉澱,並透過多個子代理分工及自動化檢查管理開發與驗收。網站首發 51 頁,生產環境 Lighthouse 效能 99、無障礙 100、SEO 99。
2026-10-26 10
版权
版权声明:
本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写 侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
简介: 本文分享用Claude实现“vibe coding”的实战经验:一天内上线香港通勝网站(tungshing.hk),采用Next.js+Vercel+Cloudflare技术栈。全程由Claude编码,作者聚焦定调、写规格、验收与沉淀五步法,确保质量与可持续迭代——非Demo,而是真实可运营的生产级网站。(239字)
用 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 把东西做出来」。做演示可以这样,做要长期运营的网站不行。常见的问题有三个:
- 越改越乱:每次对话都从零开始,AI 不记得之前的约定,改着改着风格就散了
- 看起来对,实际不对:页面能打开,但细节有错,没人发现
- 做出来和别人一样:默认配色、默认字体、默认布局,一眼就能看出是 AI 做的
我的做法是把 vibe coding 拆成五步:
定调 → 写规格 → 实现 → 验收 → 沉淀
我不写代码,但每一步都有我要做的决定。下面逐步说明。
第一步:定调——先让 Claude 知道要做成什么样
动手之前,我先让 Claude 做调研,调研结果由我拍板。
调研需求:香港用户搜什么、搜索量多大。结论是「通勝」和「農曆」是主要入口,办事吉日里「搬屋」「入伙」需求最多。
调研同类网站:它们有什么功能、缺什么。结论是同类网站都不写出处,港式用词也不地道。
对齐风格:Claude 一次只问一个问题,逐步确认配色、字体、语气。最后定下来的是纸质通勝的感觉:淡黄纸底、墨色文字,朱红标「宜」,靛蓝标「忌」。
这些结论都写进项目里的一份配置文件。之后每次开新对话,Claude 会自动读取这份文件,不需要我重复说明。
定调阶段定下的三条原则,后来所有页面都遵守:
- 只做香港繁体,用词用港式的
- 每条结论都有出处,历法数据对齐香港天文台的公开数据
- 不做占卜,只讲历法和民俗
第二步:写规格——不直接让它写代码
我不会直接说「帮我做一个吉日页面」。每个页面先让 Claude 写一份规格,我确认后再开工。
规格里有四项内容:
| 内容 | 作用 |
|---|---|
| 参考对象 | 这个页面参考什么,避免凭空发挥 |
| 同类网站对照表 | 别人有的功能逐项列出,标明我们是超过、持平还是不做 |
| 风格约束 | 从定调文件继承,保证各页面风格一致 |
| 完成标准 | 满足哪些条件才算做完 |
其中对照表必须写明「刻意不做的功能和理由」。如果不写,AI 会倾向于把所有功能都做一遍,最后页面臃肿,重点不清。
第三步:实现——拆成多个角色
我没有让一个对话从头做到尾,而是在 Claude Code 里配置了多个子代理,各自负责一个环节:
| 角色 | 职责 |
|---|---|
| 调研 | 调研方案、对齐风格 |
| 规划 | 写页面规格 |
| 开发 | 按规格实现 |
| 代码审查 | 检查代码质量和风格一致性 |
| SEO 检查 | 检查结构化数据、页面标题、收录设置 |
| 端到端测试 | 用 Playwright 跑功能测试 |
这样做有两个好处:
- 每个环节都有产出物,出了问题可以定位到具体环节
- 验收角色不改代码,只出报告,避免「自己写、自己审」
开发完成后,三个验收角色同时运行,各自出报告。发现的问题交回开发角色修复,修完再验收一轮。
另外,每个需求都在独立的工作目录和分支里完成,合并前再同步主干。这样同时开几个对话做不同的需求,也不会互相覆盖。
第四步:验收——把要求写成检查脚本
这是我认为最重要的一步。
对 AI 提的口头要求,下一次对话就可能失效。写进文档的要求,也可能被忽略。可靠的做法是把要求写成检查脚本,不通过就不能合并。
这个站目前有二十多项检查,举几个例子:
| 检查 | 防止的问题 |
|---|---|
| 港式用词检查 | 混入台湾或大陆用词 |
| 相似度检查 | 同模板页面内容过于接近 |
| 页面体积检查 | 页面过大,搜索引擎读不完整 |
| 标题长度检查 | 标题和描述过长被截断 |
| 用户文案检查 | 页面上出现开发过程中的内部说法 |
| 对比度检查 | 文字颜色不满足无障碍要求 |
相似度检查的作用最明显。曾经有两个年份页面相似度达到 43.5%,肉眼看不出来,是脚本量出来的。修改后降到 20%。
每次踩坑后,我会让 Claude 把这个坑写成一项新检查。检查项越多,后面的产出越稳定。
第五步:沉淀——让下一次更快
每个需求完成后有一个固定动作:判断这次的产出里,哪些可以留给以后的项目使用。
- 通用的组件和写法,回填到项目模板
- 踩过的坑,写进规则文档
- 重复出现的流程,整理成 Claude 的技能(skill)
这个站能在一天内上线,是因为之前做其他站时积累的模板、规则和流程都可以直接使用。vibe coding 的速度主要来自这些积累,其次才是 AI 写代码的速度。
成品:页面结构和各自的作用
下面是 今日通勝 的页面结构:
首页(今日通勝)
├── 通勝主线 月历 → 单日 → 打印版
├── 擇日主线 事项总览 → 事项年页
├── 专题 萬年曆 / 攝太歲 / 公眾假期 / 節慶 / 儀式
├── 知识层 术语总览 → 术语页
├── 工具 公历农历换算
├── 信任层 出典 / 差异说明 / 关于
└── 机器出口 日历订阅 / JSON 数据 / llms.txt / sitemap
| 层级 | 路径 | 作用 |
|---|---|---|
| 首页 | / |
打开就显示今天的农历和宜忌,并按事项分流到吉日页 |
| 月历页 | /tungshing/2026/9 |
主力页面,全年 12 页;含当月节气、吉日一览,日期格可弹出当日摘要 |
| 单日页 | /tungshing/2026-09-28 |
每天一页,列出当天全部细节;暂未开放收录 |
| 打印版 | /tungshing/2026/print |
一页排完全年,附 PDF 下载 |
| 擇日 | /gooddays、/gooddays/搬屋/2026 |
按事项查吉日,支持按生肖和日期区间筛选,可订阅到手机日历 |
| 萬年曆 | /wannianli |
全年一屏总览,点击进入月历页 |
| 攝太歲 | /taisui |
说明是什么、谁需要、什么时候办 |
| 公眾假期 | /holidays、/holidays/2026 |
入口页讲制度,年页给当年数据 |
| 節慶 / 儀式 | /festivals/中秋節、/ritual/拜四角 |
固定地址,日期每年自动更新 |
| 术语 | /term、/term/通勝 |
解释通勝上的术语,其他页面出现的术语都链接到这里 |
| 换算工具 | /convert |
公历农历互查,支持农历生日 |
| 信任层 | /sources、/why-different |
列出每条结论的出处,说明各家结论不同的原因 |
| 机器出口 | /sitemap.xml、/llms.txt |
给搜索引擎和 AI 读取 |
页面结构上有三个决定,都是我和 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,我的经验有四条:
- 先定调,再动手。 把风格和原则写成文件,让每次对话都从同一个起点开始。
- 先写规格,再写代码。 规格里要写明不做什么。
- 把要求写成检查。 用自动化检查保证产出质量,不依赖每次人工审查。
- 每次做完都沉淀。 模板、规则、流程积累得越多,下一个项目越快。
成品在这里:今日通勝,欢迎访问和提意见。
來源:阿里雲開發者社區 AI · developer.aliyun.com