这段时间经常有人问我：这个博客是怎么用 AI 写出来的？能不能分享一下提示词？
这个问题我每次都不知道该从哪一句开始回答
因为它真的没有一个可以复制过去,然后点下回车就完工的提示词
如果硬要算时间,这个 Astro 博客从 5 月 19 日第一次部署,到今天已经是第 70 天.现在看到的 Kisara 主题,则是从 7 月 18 日开始连续折腾了 10 天.中间的对话、修改、推翻和重做早就不是一句两句能概括的量了.
我当然用了 AI,而且用了很多.但在这个项目里,AI 更像是替我落实想法的工具.博客的主题、角色、布局、交互顺序、画面气氛,以及“这里看着不对劲”的判断,基本都来自我自己.AI 负责把描述变成代码,我再看结果,指出问题,让它接着改.
并不是一开始丢给 AI 一句：
帮我生成一个好看的二次元博客
然后网站就自己长成了现在这样
真要这么写,最后大概率会得到一个很标准的首页：渐变背景、几张圆角卡片、发光按钮,再放一张角色图.不能说它错,但它通常也不属于任何人.
先有角色,再有页面#
我觉得做这种个人博客,最基础的一步甚至不是写代码,而是先确定自己到底想做什么
你想用哪个角色,为什么是这个角色,页面整体偏明亮还是偏压抑,访客进入网站后第一眼应该看到什么,这些问题都不能让 AI 替你决定.图片、音乐和视频素材也得自己找.素材的构图、清晰度、色调和人物位置,会直接决定后面的设计能不能成立.
Kisara 主题最开始只有一个很模糊的念头：我想让首页中间的 Kisara 从蓝色逐渐变红,而且这段变化要由滚轮控制
后面才一点点长出锁链、回忆画面、解除封印、刀光、黑白预警、空间扭曲、黑洞爆发、数据重构和最终的液态玻璃状态.再往下,还有做旧课文一样的 001、打开冰箱的 002、解谜活动界面的 003、文章区域、Q 版角色舞台,以及 Game、Works、Me 各自不同的页面.
这些并不是 AI 一次规划出来的.很多想法甚至是在看到一个失败版本以后才冒出来的
所以“自己有想法”并不等于一开始就得拿出完整设计稿.你可以只知道大方向,也可以边做边想.但你至少要有判断：什么是你想要的,什么不是.
提示词不是咒语,是来回说人话#
我现在很少追求一条特别长、看起来特别专业的提示词
相比“请使用高级视觉设计语言,打造沉浸式交互体验”,我更愿意直接告诉它：现在看起来像什么,为什么不对,我希望它更接近什么
例如这次开发里,我说过很多非常不技术的话：
- 黑白十字看起来像把 Twitter 的 X 图标贴了上去
- 能量球像橡皮泥插在牙签上,头和杆子没连起来
- 锁链碎裂像一张大饼被掰成几块,不像细小碎片被力量崩出去
- 墨水扩散像从天上扔了个手榴弹,然后在地上炸出一个方形坑
（PS：这些都是真的,不是让 AI 编的.我真对 GPT 说过这些话,虽然中间压缩上下文都压了几百轮,没想到它还能把这些黑历史翻出来 QAQ）
这些话放在正式需求文档里可能有点怪,但 AI 反而很容易从这种反例里理解问题.你只说“再高级一点”“再自然一点”,它往往不知道该改哪里；你告诉它“像贴图”“像硬切”“这里有一圈框”“滚一下就把整段动画抽完了”,目标就清楚多了.
我自己最常用的描述顺序大概是：
- 当前看到的现象
- 这个现象为什么让我觉得不对
- 我希望它变成什么感觉
- 哪些已经做好的部分不要动
- 修改以后怎么判断算修好
这不是万能模板,更不是把括号里的词换掉就能生成同款网站的公式.它只是让我和 AI 少猜一点
截图比“还是不对”有用得多#
视觉问题经常很难只靠文字说清楚
比如一条只有一像素的接缝、一个蒙版边缘、人物头发上多出来的白边,或者某个按钮在 100% 浏览器缩放时刚好跑出侧边栏.只说“这里有问题”,AI 很可能会改到另一个它认为可疑的图层上.
这时候最有效的方法就是截图,最好再画框、画线、写一句“真正的问题在这里”
（PS：QQ 自带的截图就挺不错的,快捷键是 Ctrl + Alt + A.截完图后会进入编辑页面,直接在里面框选、画线做标记就行啦.）
而且截图不能只截最终坏掉的样子.有条件的话,把正常状态和异常状态一起给出来,告诉它触发步骤：从哪个页面进入、先点什么、往上滚还是往下滚、刷新后正常还是软切页面后才出错.很多前端问题并不是样式本身,而是页面返回、动画重置、缓存或多个状态同时抢控制权.
不过截图也不是绝对答案.微小的动画手感、粒子方向、锁链有没有纵深、光泽像不像贴上去的,这些最终还是得自己看.AI 能检查代码和大范围布局,但不能替你决定“这个感觉到底对不对”.
模糊的地方,别急着让 AI 开写#
有些时候我自己只有一个念头,例如“黑洞后半段太干了”“这个页面想做成二游活动界面”“底边栏想塞一个角色互动舞台”,但具体怎么落地还没想好
这种情况我更建议先用计划模式,让 AI 反过来问问题,或者先给几套方向,说明各自的效果、代价和风险.等方向选定以后再写.
否则它会很积极地替你补全所有空白.补得快是快,但那些空白一旦被它用最常见的方案填满,页面就很容易变成圆角框、状态标签、装饰线和一堆意义不明的小字.后面再推倒,反而更费时间.
计划模式真正有用的地方,不是让 AI 写一份很长的计划,而是逼自己把没想明白的部分暴露出来
一定要给自己留后悔药#
Vibe Coding 很容易进入一种状态：这个版本差一点,再改一下；改完又冒出新问题,那就再补一下.等回过神,已经不知道哪一版最好了.
所以这个项目后来形成了一条很死的规则：每轮改动前先留 Git 回滚点
有些效果不是“新版一定比旧版好”.刀光、黑白十字、空间扭曲、锁链和页面过渡都出现过越改越偏的情况.没有提交记录,就只能靠记忆把旧效果重新拼回来,通常还拼不准.
开发笔记也很重要.这个博客前后改过的东西太多,AI 的上下文不可能永远装着所有细节.哪些方案试过但失败了、哪个提交是能用的基线、哪些素材不能覆盖、哪些视觉细节必须由我自己验收,都需要单独记下来.
所谓 Vibe Coding,并不代表可以不管理项目.恰恰相反,AI 写得越快,越需要有人管住修改范围.
本地能跑,不等于真的没问题#
这个博客还有不少问题只会在真实环境里出现
本地默认 90% 缩放时正常,网页端 100% 时播放器会被挤出去；本地页面切换很快,部署到实际域名后会慢一步；桌面端顺滑的锁链,到了移动端缩在一起就会明显掉帧；浏览器自动播放策略还会让音乐在不同访问状态下表现不一样
还有一次为了修黑色方块频闪,补丁确实把频闪压住了,CPU 和内存也一起被拉爆.视觉上看起来修好了,不代表实现就是对的.
所以我现在会把“能显示”与“能长期正常运行”分开看.动画需要反复跑,页面要来回切,浏览器返回要测,后台放一段时间再回来也要测.移动端不是把桌面页面缩小一遍,它经常需要单独减少效果、重排控件,甚至更换实现方式.
AI 降低了实现门槛,没有替我做审美决定#
我觉得 Vibe Coding 最有价值的地方,是它让我能把以前只停留在脑子里的东西真正做出来
我不需要先把 Canvas、WebGL、Astro 页面生命周期和每一种动画 API 全部学完,才有资格尝试一个效果.可以先描述、先看到、再修改,也可以在出现问题时让 AI 帮我追代码、查性能和补兼容.
但这不代表“有 AI 就不需要会任何东西”.至少你得学会观察,学会拆问题,知道什么时候该否定结果,也得愿意花时间测试.不会写某段代码没关系,连自己想要什么都不愿意想,那 AI 最后只能给你一个平均意义上的“好看”.
如果有人继续问我能不能分享提示词,我大概还是会说：可以分享某一次修改是怎么描述的,也可以分享我的工作方式,但没法分享一句能复刻整个博客的提示词
这个博客真正的提示词,不是某一段文字
是 70 天里不断冒出来的想法,是找到的一张张素材,是那些“有点不对”“再往左一点”“这个像贴上去的”“上一版其实更好”,也是每次写坏以后还能退回去,再换个方向继续试
AI 确实写了很多代码
但最后决定这个网站长什么样的,还是那个一直坐在屏幕前挑毛病的人