从一个个人网站开始，重新理解 Vibe Coding
这次个人网站做完，我对 Vibe Coding 的感受比一开始踏实了很多。
刚开始我以为重点在“让 AI 帮我把网站做出来”。做了一轮才发现，真正难的地方在前面：我得先想清楚这个网站给谁看、看完要记住什么、哪些内容值得放大、哪些效果会打扰阅读。
AI 写代码很快。快到有时候问题也会被放大得很快。一个导航栏、一个断点、一句文案，如果没有提前说清楚边界，后面就会反复改。
这篇记录写的就是这次过程：我做了什么，哪些提示词和 skill 真正有用，哪些地方踩了坑，以及一个没有代码基础的 PMO，下次怎么把 AI Coding 这件事做得更稳。
一、项目背景
这次做的是我的个人品牌网站 / portfolio 网站。
我不想把简历原样搬到网页上。简历适合筛选，网站更适合让人慢慢理解一个人的工作方式。所以我把方向定成了 scrollytelling：用几个真实业务案例，讲清楚我在品牌切换、AI PMO、增长项目、国际化和全球支付这些现场里做过什么。
这个项目很适合用 Vibe Coding。它同时涉及产品结构、视觉风格、前端实现、双语文案、响应式适配和学习日志。对我来说，它也像一次完整的 PMO 项目：目标会变，需求会变，审美会变，最后要靠一套节奏把事情收住。
二、这次真正有效的部分
最有效的提示词，都有一个共同点：它们没有急着让 AI 写代码。
比如我后来要求先做 PRD、先拆信息架构、先说明页面分区和交互节奏。这个动作很关键。它把“做一个好看的个人网站”这种模糊目标，拆成了页面应该承担的任务。
还有几类提示词也很有用：
- 把经历写成业务案例，减少公司和职位的堆叠
- 中文和英文分开写，英文不要照着中文硬翻
- 页面改动前先说明会动哪里，改动后说明怎么验收
- 不要把我的内部要求写到网页上
- 保守清理代码，只删确定作废的东西
这些提示词看起来普通，但它们改变了协作方式。AI 开始按我的产品判断来工作，页面变体也少了很多。
三、这次用到的 skills / agent
这次真正让我意识到 Vibe Coding 复杂性的，是不同 skill 的分工。
| Skill / Agent | 主要处理的事 | 实际效果 | 我的复盘 |
|---|---|---|---|
| UI / Design Review | 第一屏、配色、液态玻璃质感、导航和响应式布局 | 帮我快速看出页面哪里像模板、哪里不够专业 | 设计 skill 能给方向，但前提是我先说清楚网站气质和读者对象 |
| Humanizer / 文案润色 | 中文文案、英文表达、去掉内部提示词痕迹 | 很多“像在解释需求”的句子被改得更像对外表达 | 文案不能只靠润色，前面要先确定内容模型 |
| Browser / Playwright 类测试 | 页面预览、锚点跳转、移动端和桌面端检查 | 找出了不少真实问题，比如导航遮挡、浅色模式看不清、4K 排版过大 | 测试要配合明确验收标准。只说“帮我测试一下”还不够 |
| HyperFrames / 动效探索 | 背景视频、AI 氛围、科技感视觉 | 帮我确认了一个判断：动效太重会抢内容 | 有些效果看起来高级，但不一定适合个人网站阅读 |
| GitHub / 发布流程 | 本地提交、V1.0 标签、准备上传仓库 | 帮我把项目从“本地页面”收束成一个版本 | 发布本身也是交付的一部分，仓库结构和忽略规则要提前处理 |
也有一些能力没有充分发挥出来。比如早期我没有让 AI 先稳定设计系统，导致后面很多修改都在局部打补丁。再比如，我一开始没有把每个案例的内容字段设计清楚，结果页面结构和文案一起变，返工就多。
这和做项目管理很像。工具再多，如果节奏没有建立起来，现场还是会乱。
四、这次暴露的问题
最明显的问题是前期顶层设计不够。
我一开始更关注页面好不好看，后来才慢慢意识到，个人网站先要回答几个更基础的问题：
- 谁会来看这个网站
- 他会先看什么
- 哪些经历最能代表我
- 哪些内容适合展开成案例
- 哪些交互会影响阅读
这些问题没有提前定住，后面就变成了连续修补。导航吸顶反复压住内容，浅色模式里有些字看不清，4K 分辨率下标题过大，案例卡片空白太多，学习日志的位置也一度很奇怪。
代码层面的问题也不少。CSS、组件、断点、Markdown 解析、路由和构建，很多东西我都不熟。它们单独看是技术问题，放到整个网站里，其实都是产品体验问题。
另一个问题是文案。早期有些文字像内部说明，比如“把经历写成业务案例”“这里展开故事”。这些话适合给 AI 下指令，不适合给招聘方和业务 Leader 看。后来我才不断把文案往回收：少解释，多定性；少包装，多讲真实判断。
五、非代码背景的我，应该怎么做得更好
这次最消耗时间的地方，反而是一堆小问题反复出现。
导航盖住标题。 浅色模式文字发白。 4K 下标题大到失控。 移动端按钮挤在一起。 文章里的 Markdown 表格和流程图显示得不够好。
我最开始会直接说：“这里太丑了”“这里又坏了”。这当然能表达感受，但对 AI 来说还不够。它需要更明确的问题定义。
下次我会把问题拆得更像验收单：
- 先说现象：例如“滚动后导航栏挡住了 Case 标题”。
- 再说目标：例如“标题需要完整露出，导航保留或删除都可以”。
- 说明边界：例如“不要改整体视觉，只处理遮挡问题”。
- 要求验证：例如“请测试 390、768、1440、2560 宽度，并说明结果”。
- 如果连续修不好，回到产品取舍：这次导航吸顶就是这样。最后我选择删掉它，因为阅读稳定性更重要。
这个过程让我很有感触。PMO 不一定要会写 React，但要会把问题讲清楚。CSS 是工程师的语言，验收标准是 PMO 也能掌握的语言。AI 可以帮我写代码，但“什么算修好了”这件事，还是要我自己判断。
六、我对 Vibe Coding 的新理解
现在我更愿意把 Vibe Coding 看成一种带产品意识的 AI 协作开发。
它需要一点直觉，也需要很多约束。直觉负责发现“哪里不对劲”，约束负责把这种感觉变成 AI 能执行的任务。
这次之后，我不会再期待一个提示词直接生成最终结果。比较可靠的方式，是先给 AI 一个清楚的工作框架，再通过一轮轮验收把结果收紧。
我也更理解了 AI 协作里的一个风险：它很勤快，但勤快不代表方向正确。它可以快速生成十个方案，也可以快速把一个错误方向做得很完整。所以人要负责判断，尤其要负责停下来。
七、下一次的改进方向
如果再做一次类似项目，我会先准备六样东西：
- PRD：写清楚目标用户、页面目标和成功标准。
- Design System Contract：提前定好字体、颜色、标题层级、卡片、按钮和响应式规则。
- 内容模型：先定义每个案例有哪些字段，再写故事。
- 组件结构：先拆 Hero、案例、方法论、教育、日志、联系这些模块。
- 交互规则：哪些地方需要动效，哪些地方保持安静。
- 验收清单：桌面、移动端、折叠屏、浅色模式、深色模式、锚点跳转都要提前列出来。
这些准备会让开头慢一点，但后面会少很多返工。
八、最终沉淀
这次项目让我确认了一件事：AI Coding 的门槛不只在代码，也在问题定义。
对我这种没有代码基础的 PMO 来说，更现实的路径，是先学会用产品、设计和验收语言去管理 AI 的输出。
我需要知道自己要什么，也要知道什么时候该停。 这可能就是我这次最大的收获。