mobile wallpaper 1
mobile wallpaper 2
mobile wallpaper 3
mobile wallpaper 4
mobile wallpaper 5
mobile wallpaper 6
mobile wallpaper 7
mobile wallpaper 8
mobile wallpaper 9
mobile wallpaper 10
mobile wallpaper 11
mobile wallpaper 12
mobile wallpaper 13
mobile wallpaper 14
mobile wallpaper 15
mobile wallpaper 16
mobile wallpaper 17
mobile wallpaper 18
mobile wallpaper 19
mobile wallpaper 20
mobile wallpaper 21
mobile wallpaper 22
mobile wallpaper 23
mobile wallpaper 24
mobile wallpaper 25
mobile wallpaper 26
mobile wallpaper 27
mobile wallpaper 28
mobile wallpaper 29
mobile wallpaper 30
字
分钟
用 Vibe Coding 写博客后,我最想说的不是“分享提示词”

这段时间经常有人问我:这个博客是怎么用 AI 写出来的?能不能分享一下提示词?

这个问题我不知道该怎么回答

因为对于这个博客项目来说,真的没有一大段可以复制过去,然后点下回车等一下午就完工的提示词

如果硬要算时间,这个 Astro 博客从 5 月 19 日第一次部署,在我写这句话时已经是第 70 天.且第一个主题fuyukawa在部署上线前就已经在本地打磨很长时间了,这是一个时间跨度为百日的创作过程.我并不是正经学前端的,最早接触前端大概在 21 年吧,那时候 ai 也没这么强,就自己学着仿着别人的案例去写动效博客,之后就因为生活原因没怎么碰了。今年回过头来一看,ai 编程已经发展的非常强大了,虽然旧博客的仓库还在,但本地的项目素材已经消失了.就想着再来重新做一个吧,还是延续着几年前的一些设计理念,纯粹的当做精神续作来做的。这个博客目前开发了两套主题: 第一套fuyukawa是我偶然刷到了武叶佐乃老师的花梨插图,突然感觉这种风格的图片很适合拿来当博客头图诶!于是就用着二次元清新手帐这种风格进行布局设计.

第二套主题Kisara是为我心爱的角色 《Engage Kiss》中的 木更(Kisara) 定制的,因为过于喜欢,鄙人又不会画画,想着通过前端动效来演绎故事和角色,以此来展示厨力.想要以某部作品某个角色为中心做作品,就得将原作反复推敲,所以这段时间内就一直将原作一帧一帧的反复观看推敲,然后筛素材,根据素材来确定前端的风格。

我当然用了 AI,而且用了很多很多.但在这个项目里,AI 更像是替我落实想法的工具.博客的主题、角色、布局、交互顺序、画面气氛,以及对问题的判断,基本都来自我自己.AI 负责把描述变成代码,我再看结果,指出问题,让它接着改,以此循环往复…

所以我并不是一开始丢给 AI 一句:

帮我生成一个好看的二次元博客

然后网站就自己长成了现在这样

真要这么写,最后大概率会得到一个很标准的AI味首页:渐变背景、几张圆角卡片、发光按钮,再放一张角色图.不能说它有什么大毛病,但实际就是各方面都与你的预期差了很多.

先有角色,再有页面#

我觉得做这种有着明确主题环绕的个人博客,最基础的一步甚至不是新建文件夹,而是先确定自己到底想做什么

你想用哪个角色,为什么是这个角色,页面整体风格是什么样的,访客进入网站后第一眼应该看到什么,这些问题都不能让 AI 替你决定.图片、音乐和视频素材也得自己找.素材的构图、清晰度、色调和人物位置,会直接决定后面的设计能不能成立.

对于Kisara 主题,最开始只有一个很模糊的念头:我想让首页中间的 Kisara 从蓝色逐渐变红,而且这段变化要由滚轮控制.是的,早期版本确实是由蓝变红,当时的想法主要是对应前后两张图的整体色调,但后来想了一番还是决定采用灰色到粉色,这后面相比直接的对应色调转换有着更深层的含义: 粉色一直象征着木更,但灰色在我这里的理解更像是一种虚无空洞/忘记/迷失自我/未完全 的感觉,像是原作里木更与修的感情线.

一开始我都想法很多也很膨胀,对着首屏两张图之间的切换做了一大堆效果,虽然效果是不赖,但图片换来换去还是那两张,有点太刻意了.经过一番思索果断决定,裁取原作一段故事的几个转折点关键帧,每张顺次播放,平滑过渡淡入淡出,再与最上方的KISARA大字对应状态,效果真是绝了!至少在我这边看来这样,有一种电影的播片回忆感.

后面才一点点调整优化锁链、解除封印、空间扭曲、黑洞爆发、数据重构和最终的液态玻璃状态的表现效果.再往下,还有对应画面手势放大文字的 001、打开冰箱掉落几个有着象征意义的小物件的 002、仿造二游解谜活动界面的 003、Q 版角色舞台,以及 Game、Works、Me 各自不同的页面中其他效果…

这些并不是 AI 一次规划出来的.很多想法甚至是在看到多个失败版本以后才想出来的

所以“自己有想法”并不等于一开始就得拿出完整设计稿.你可以只知道大方向,也可以边做边想.但你至少要有判断:什么是你想要的,什么不是.

提示词不是魔法咒语,是来回说人话#

我现在很少追求一条特别长、看起来特别专业的提示词

相比“请使用高级视觉设计语言,打造沉浸式交互体验”,我更愿意直接告诉它:现在看起来像什么,为什么不对,我希望它更接近什么

例如这次开发里,我说过很多非常不技术的话:

  • 黑白十字看起来像把 Twitter 的 X 图标贴了上去
  • 能量球像橡皮泥插在牙签上,头和杆子没连起来
  • 锁链碎裂像一张大饼被掰成几块,不像细小碎片被力量崩出去
  • 墨水扩散像从天上扔了个手榴弹,然后在地上炸出一个方形坑

(PS:这些都是真的,不是让 AI 编的.我真对 GPT 说过这些话,虽然中间压缩上下文都压了几百轮,没想到它还能把这些黑历史翻出来 QAQ)

这些话放在正式需求文档里可能有点怪,但 AI 反而很容易从这种反例里理解问题.你只说“再高级一点”“再自然一点”,它往往不知道该改哪里;你告诉它“贴图感”“硬切感”“这里有一圈框”“滚一下鼠标就把整段动画抽完了”等等,目标就清楚多了.

我自己最常用的描述顺序大概是:

  1. 当前看到的现象
  2. 这个现象为什么让我觉得不对
  3. 我希望它变成什么感觉
  4. 哪些已经做好的部分不要动
  5. 修改以后怎么判断算修好

这不是万能模板,更不是把某些字词换掉就能生成同款网站的公式.整个流程只是让我和 AI 之间互相少猜测对方一些,增加沟通效率来更能让双方理解到对方的想法意图.

截图比“还是不对”有用得多#

视觉问题经常很难只靠文字说清楚

比如一条只有一像素的接缝、一个蒙版边缘、人物头发上多出来的白边,或者某个按钮在 100% 浏览器缩放时刚好跑出侧边栏.只说“这里有问题”,AI 很可能会改到另一个它认为可疑的图层上.

这时候最有效的方法就是截图,最好再画框、画线、写一句“真正的问题在这里”

(PS:QQ 自带的截图就挺不错的,快捷键是 Ctrl + Alt + A.截完图后会进入编辑页面,直接在里面框选、画线做标记就行啦.)

而且截图不能只截最终坏掉的样子.有条件的话,把正常状态和异常状态一起给出来,告诉它触发步骤:从哪个页面进入、先点什么、往上滚还是往下滚、刷新后正常还是软切页面后才出错.很多前端问题并不是样式本身,而是页面返回、动画重置、缓存或多个状态同时抢控制权.

不过截图也不是绝对答案.一个页面可能会有多种效果和图层,AI只能看着截图和描述,从一堆代码中倒推问题最大概率出在哪里,但最后是不是修好了,修的效果怎么样还是得看你自己.AI 能检查代码和大范围布局,但不能替你决定“这个感觉到底对不对”.

模糊的地方,别急着让 AI 开写#

有些时候我自己只有一个念头,例如“黑洞后半段太干了”“这个页面想做成二游活动界面”“底边栏想塞一个角色互动舞台”,但具体怎么落地还没想好

这种情况我更建议先用计划模式 Plan Mode,让 AI 反过来问问题,然后再给给几套方向,说明各自的效果、代价和风险.等方向选定以后再写.

否则它会很积极地替你补全所有空白.补得快是快,但那些空白一旦被它用最常见的方案填满,页面就很容易变成圆角框、状态标签、装饰线和一堆意义不明的小字.后面再推倒,反而更费时间.

计划模式真正有用的地方,不是让 AI 写一份很长的计划,而是让AI逼问你把自己把没想明白的地方想清楚.

一定要给自己留后悔药#

很多新接触 Vibe Coding 的人是没有计科相关的基础的,工程经验的缺失在这种需要长线程来与用户需求互相对齐的开发过程会越来越暴露问题,你无法保证AI能完全记住每一次改动,你也不能保证AI一定不会误删文件,所以我们需要借助Git来进行项目内的改动存档点.

开发笔记也很重要.这个博客前后改过的东西太多,AI 的上下文不可能永远装着所有细节.哪些方案试过但失败了、哪个提交是能用的基线、哪些素材不能覆盖、哪些视觉细节必须由我自己验收,都需要单独记下来.关于具体的细节请看:Codex App 用久以后,我留下的这些使用习惯 - 给项目留一张能接住上下文的便签

AI很全能并不代表可以不管理项目.恰恰相反,AI越厉害 写得越快,就越需要有人进行监督.

本地能跑,不等于真的没问题#

这个博客还有不少问题只会在真实环境里出现

本地默认缩放时正常,网页端 100% 时页面布局就会出问题;本地页面切换很快,部署到实际域名后会因为缓存,资源加载而变得很慢;桌面端顺滑的动效,到了移动端缩就会明显掉帧;浏览器自动播放策略还会让音乐在不同访问状态下表现不一样…

所以本地能跑时,恭喜你过了第一关,但真实体验还得放在真实网页浏览器进行验证,别人不可能通过你的本地端口来访问,大家看到的是你真实上线时的效果.

AI 降低了实现门槛,没有替我做审美决定#

我觉得 Vibe Coding 最有价值的地方,是它让我能把以前只停留在脑子里的东西真正做出来

我不需要先把 Canvas、WebGL、Astro 页面生命周期和每一种动画 API 全部学完,才有资格尝试一个效果.可以先描述、先看到、再修改,也可以在出现问题时让 AI 帮我写代码、查性能和补兼容.

但这不代表“有 AI 就不需要会任何东西”.至少你得学会观察,学会拆问题,知道什么时候该否定结果,也得愿意花时间测试.不会写某段代码没关系,连自己想要什么都不愿意想,那 AI 最后只能给你一个平均意义上的“好看”.

如果有人继续问我能不能分享提示词,我大概还是会说:可以分享某一次修改是怎么描述的,也可以分享我的工作方式,但没法分享一句能复刻整个博客的提示词

这个博客真正的提示词,不是某一段文字

是百天来里不断冒出来的想法,是找到的一张张素材,是那些“有点不对”“再往左一点”“这个像贴上去的”“上一版其实更好”,也是每次写坏以后还能退回去,再换个方向继续试

AI 确实写了很多代码

但最后决定这个网站长什么样的,还是那个一直坐在屏幕前挑毛病的人

分享

如果这篇文章对你有帮助,欢迎分享给更多人!

用 Vibe Coding 写博客后,我最想说的不是“分享提示词”
https://sxz-blog.xyz/themes/blank/posts/vibe-coding-blog-notes/
作者
牛耕田
发布于
2026-07-26
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

目录