AI 产品经理个人网站 Vibe Coding 实战

起点：一个迟到的决定

我一直想有个自己的网站，但迟迟没想好有什么样的表达是值得放在上面的。

今年决定把 AI 产品经理作为职业方向之后，个人网站这个想法又冒了出来。我学到的东西、做的项目、对产品的思考、平时的小规模实践，分散在不同的地方：简历放不下，社交媒体太零碎、各类博客平台又充斥着。我需要一个地方把它们整合起来，让一个陌生人能在短时间内了解我的能力，也让自己有一个持续积累的锚点。

还有一个更重要的理由：这个网站本身，就可以是我的一个 AI 产品案例。一个用 Vibe Coding 构建的、关于 AI 产品经理能力的个人作品集。

构思：先有信息架构，再谈视觉

第一步：形成初步需求

我做的第一件事不是直接打开与大模型的输入框，让它开始开发，而是先初步草拟了一份"产品需求文档"：

• 目标：搭建我在AI领域的个人名片，帮助我在AI产品经理相关岗位求职
• 内容：通过建设一个个人网站，展示和分享我在AI领域的学习成果、我对市面上AI产品的分析、我对AI社区发展趋势的解读、我如何思考AI产品等等

仅从目标和内容开始，我与AI进一步探讨这个方案的可行性，也对这个PRD进行了进一步的讨论和完善，最终形成了一个初步的网站板块设计，包括了：

1. 首页 — 用一句话点明我的目标，放3个最亮眼的文章入口；
2. 项目实验室 — 展示我的vibecoding产品原型/成果，完整呈现"发现机会-动手验证-思考落地"的产品闭环；
3. 技术笔记 — 记录我的学习过程和技术理解，呈现我的技术好奇心，以及对AI工具本质的体会；
4. 关于我 — 简介介绍背景和动机，链接各类联络方式

这时我依然觉得这个网站的信息架构有点单薄 — AI产品经理应该具备的能力不只有这些，那么我应该如何通过这个网站呈现出我具备相应的能力呢？我想到了——直接从招聘信息JD入手。

第二步：分析、完善、成型

我从几家心仪的目标求职公司与岗位招聘信息中获取到了详细的JD：JD 里提到了 Agent 行为理解、Vibe Coding 能力、UI/UX 设计素养、社区反馈收集、数据驱动决策……现有的栏目结构能不能覆盖这些？

对不上的地方，就是需要新增的板块。在上一步形成的网站信息架构之上，我让AI基于获取到的JD，分析这个网站的架构是否能够全面展示我的能力；如果不够，对现在的信息架构进行进一步整合与完善，确保能力的全面呈现。这就是「Agent 解剖室」和「社区与反馈实践」两个栏目的由来——它们不是凭空想出来的，而是从 JD 的要求倒推回来的。

在形成完整的基本信息架构之后，我再让AI对这个信息架构的呈现和定位描述进行了进一步的润色：起一个语言风格更合适的名称、描述每个板块的目标与定位、板块内的内容应该如何呈现等等。通过多轮讨论，最终形成一个完整的PRD.md，来描述整个网站的建设愿景、目标用户、主要板块的设计和定位等等。这个PRD.md是后续真正开始vibe coding的重要参考文件。

技巧一：当你不知道一个产品该包含什么功能时，找一个真实的用户需求文档（JD、用户反馈、竞品分析），用它来校准你的功能列表。这比闭门造车高效得多。

第三步：灵活调整、及时完善

在内容归属上，有一个决策花了一些时间。

我写了一篇关于产品经理和项目经理区别的文章，最初想放在「关于我」里作为补充阅读。但后来觉得不妥——这篇文章代表的不只是一个背景介绍，而是一条独立的思考脉络，关于角色认知、关于职业转型的反思。它应该有自己的空间。

AI 建议新建一个叫「写在前面」的板块。但我马上想到另一个问题：这个名字暗示它只能放一两篇开篇文章，未来如果我持续产出类似的非技术性思考，它往哪放？

最终我决定新建一个板块叫「思考笔记」，专门放职业反思、产品观、方法论探讨这类内容。它和技术类内容分开，和项目展示分开，但又共同服务于一个目标：让人看到我既会动手，也会思考。

技巧二：做产品决策时，不仅要考虑当前场景，还要问自己"三个月后这个设计还能不能承载更多内容"。扩展性的考量应该在 V1 就埋下。

范围与工具

MVP 第一版的范围：首页、思考笔记（1篇）、项目实验室（1个项目）、产品洞察（1篇）、关于我。其他栏目留好框架，内容逐步填充。

工具选了 DeepSeek + Claude Code。没有在工具选型上花太多时间——我需要最快速度看到东西，不在开始阶段过度优化。

设计：定义视觉风格时，先描述"感受"

网站该长什么样？对非设计人员来说，这是个不太容易用语言回答的问题。

我没有一上来就描述布局和组件，而是我定下了我要的网站基调：简洁、黑白灰基调、大量留白、细微动效。"像一个安静的工作室，而不是热闹的展厅"。这段话后来成为我和 AI 沟通视觉方向的锚点。在这个简单的视觉风格描述之上，我使用 AI 对这个网站的视觉风格进行了进一步的补充完善，形成一个DESIGN.md，完整表达了我想要的个人网站的视觉设计风格与设计系统的具体参数。

最终的设计系统文件中详细定义了这些内容：

1. 整体视觉风格 — 包括了设计基调、色彩系统、字体排版、图标与插图、动效等等具体要求；色彩系统中定义了主背景、卡片、主文字等等强调色，每个颜色均给出HTML颜色代码；
2. 布局与组件 — 描述了页面的总体布局、关键组件规范；
3. 移动端适配要求 — 对响应式设计的详细设计；
4. 关键页面设计速写 — 对已经确定下来的板块，提供每个板块的关键设计元素描述。

为什么这样做：在 PRD 和 DESIGN 文档完成之后我才开始动手vibe coding。这两份文档不仅帮我理清了功能边界，也给了我和 AI 沟通时一个稳定的参照——当 AI 生成的页面不对时，我不需要说"不好看"，而是可以具体地说"留白不够，动效太喧闹，不符合设计文档里的基调"。

过程：VibeCoding全流程

确定技术选型——够用就好，但要留后手

在Vibe Coding的第一步，我花了一些时间与AI讨论并确定了网站的技术骨架。原则很简单：用最少的复杂度把内容送到用户面前，同时预留未来能力增强的接口。

<ArchitectureDiagram />

1. 纯前端静态站点

核心框架选 Next.js 14 搭配 Tailwind CSS 3，部署在 Vercel。

选 Next.js 的理由不是因为它"流行"，而是因为 App Router 的文件系统路由天然契合内容站点的结构——一个栏目一个目录，一个目录一个 page.tsx，路由即文档。我不需要维护额外的路由配置文件，打开 src/app/ 目录就能看到整个站点的信息架构。这对一个非前端开发者来说，降低了认知负担。

Tailwind 的取舍类似。我写不出漂亮的 CSS，但 Tailwind 的工具类让我能直接在 JSX 里控制间距、颜色、圆角，所见即所得。自定义设计令牌封装在 tailwind.config.ts 里，确保 11 个页面在视觉上保持一致，而不是每个页面各自为政。

还有一个关键选择：静态导出。整个站点在构建时就被预渲染为纯 HTML/CSS/JS，不需要 Node.js 服务器。这带来的好处是部署简单（任何静态托管都能跑）、访问速度快（CDN 直接返回文件）、零服务器成本。代价是放弃了 SSR 和 API Routes——但以我当前的内容量和使用场景，这个代价完全可以接受。

初期所有内容都是 TypeScript 内联数据。没有接 CMS，没有接数据库。这看起来"不专业"，但反过来想：当内容只有十几篇文章、几个项目卡片时，CMS 的维护成本远超它的便利性。内容即代码在这个阶段是最务实的选择。

2. 按需激活的 Serverless 中间层

网站里有一些未来规划功能——比如首页的 AI 问答助手、某些 Agent 原型的在线试用——需要调用大模型 API。如果在前端直接暴露 API Key，既不安全也不专业。我选择用 Vercel Serverless Functions 做一层薄薄的中间件：前端请求这个函数，函数在后端安全地拼接 API Key 并转发请求，再把结果流式返回给用户。

这一层目前没有激活。我不需要在一开始就把所有服务都接入，而是随着内容更新的实际需求，逐步打开。写到 Agent 原型时再激活 Serverless 函数，写到数据叙事时再接分析工具。这本身也是一种产品思路：不是技术能力的堆砌，而是让技术服务于当下真实的内容目标。

3. 外部 SaaS 积木

我不打算自己造轮子。

• Vercel Analytics：已经接入，放在根布局的 <Analytics /> 组件中，全站自动埋点，不需要手动写追踪代码。在 Vercel 控制台就能看到页面访问量和来源。
• 社区反馈表单（计划）：嵌入 Tally 或 Google Forms，不需要自建后端。
• 行业雷达内容管理（计划）：可能用 Notion 数据库，前端通过 Notion API 拉取渲染，避免手动编辑 JSON。
• 自动化抓取（计划）：用 GitHub Actions 定时跑脚本生成数据文件，喂给站点。

每一个选择都是在"我要用它"和"我不想维护它"之间做的平衡。

为什么这样选？

这个架构最核心的思路是：纯前端快速起步，能力按需增强。

它恰好处于"我会"和"我不会"之间。我不是工程师，但通过 Vibe Coding 我能理解每一层的边界和职责，能用自然语言向 AI 描述清楚"这里需要一个中间层函数来保护密钥"，并在它的协助下完成实现。对一个 AI 产品经理来说，这个临界点或许就是最舒服的位置——不必亲自写每一行代码，但知道代码在做什么，以及它为什么被放在那个地方。

4. 部署：让每次推送自动生效

部署选 Vercel，因为它和 Next.js 同源，构建流程零配置。GitHub 仓库保持私有——Vercel 支持私有仓库部署，只要 GitHub App 集成授权一次即可。

技术选型的核心不是"用什么技术最先进"，而是"当前阶段我真正需要什么"。纯静态 → Serverless → SaaS 积木这个演进路径，不是提前设计好的蓝图，而是从实际需求倒推回来的。当一个功能的需求还没出现时，先把它留成接口，而不是先把它做出来。

总体框架初步实现

在前面形成的PRD.md, DESIGN.md以及技术架构相关信息的基础之上，使用Claude Code中几乎一轮就能实现一个八九不离十的总体框架。

在这个过程中，Claude Code启动plan模式，先为这项任务制作了一个计划。我的职责是审阅这份计划，确认后让Claude Code开始开发。之所以能够这么顺利，也是因为前期我们已经花了足够的功夫明确我们要建设的内容，并形成了一个初步设计的约定。这一个过程，与软件项目管理的过程也有共通之处。

技巧三：和 AI 协作构建产品时，先花时间写清楚你的产品需求和设计规范，哪怕只是一个简单的文档。这会让后续每一次 prompt 调整都有据可依，而不是凭感觉反复试错。

细节调整

细节调整是一个重复迭代的过程：与大框架的实现带来的"一眼惊艳"的感觉不同，细节调整的过程往往给人带来一种"边际效益在逐步降低"的感觉，很有可能一个细节需要反复描述，AI才能正确将它调整成你想要的样子。

这里我积攒了一些不成体系的技巧，这些技巧都指向一个核心——指令要准确：

1. 同一个问题，一两轮对话都修改不好的话，翻一翻AI的思考过程，看看它在哪个环节理解出了偏差，明确指出它的错误；
2. 如果要修改的是一个具体组件（且在一个层级比较深的位置），而它总是找错对象，翻一翻源码，找到具体的组件名称，比起你用模糊的语言描述这个对象，准确度要更高；
3. 需要的话，直接用英文沟通 — 一部分代词和代称在中译英过程中可能被错误理解。

技巧四：当 AI 反复出错时，检查你的指令是否太模糊。用具体的约束条件取代"不对，再改"——告诉它"这个条件下变成那个样子"，比反复否定更有效。

部署、上线

MVP内容填充完成后（这个网站的第一版只发布了一篇文章和"关于我"版块），最重要的环节就是部署这个网站了。

根据前面基本确定的技术路线，这个网站MVP是个纯静态页面的系统，只需要找个环境来托管静态页即可。这里我选择用github托管文件，同步到Vercel项目中，再为Vercel项目关联一个国内可访问的域名。

部署过程也踩了一些小坑。所幸在AI的帮助下，这些小问题都找到了解决方案，系统顺利上线。值得一提的是，因为部署流水线涉及到多个平台，出现问题的排查线索也可能分散在各个地方，这里我依然采用"古法"——人工介入，查阅各个平台的报错信息，提供给AI去解决。当然，在走通一次部署过程后，后续更新的过程就基本不再出现问题。

成果：当前状态

网站的第一个版本已经完成信息架构设计和内容规划，包含10个核心页面：

• 首页：大字标题 + 三个核心入口卡片 + 动态粒子背景
• 思考笔记：产品经理与项目经理的对比思考
• 项目实验室：首个 Vibe Coding 项目的完整记录
• Agent 解剖：详细解析各类Agent产品和使用体验
• 产品洞察：AI 产品体验深度分析
• 交互便签：对细节交互设计的理解和分析
• 行业雷达：跟踪行业内正在发生的事
• 社区实践：与AI社区共同成长
• 技术笔记：调试和学习过程中的随手记录
• 数据叙事：通过数据分析解读行业发展
• 关于我：背景介绍

每个栏目的内容正在持续丰富。

回顾：已经显现的经验和教训

做得好的：

花在梳理信息架构上的时间是最值得的。十一个栏目的结构（含首页和关于我）经过了至少三轮迭代：从最初的直觉分类，到 JD 驱动的功能增补，再到扩展性考量催生的新栏目。现在的结构能容纳我未来相当长时间的内容积累，不需要再做大改。

可以更好的：

在系统架构的梳理上，没有考虑到后续每次发布新文章时要如何更新这个网站——目前系统里并没有一个"发布"的功能，每次发布新文章，只能通过AI帮我把整个系统编译一遍，再重新部署。

后续要再次开发这种纯静态网站，我可能会考虑把内容配置文件外部化 — 允许系统直接读取markdown文件进行渲染，数据更新时不再需要重新编译。

受限于当前 AI 能力的：

AI 生成复杂交互时仍然不稳定。比如一个 hover 展开详情的效果，生成的代码在 Safari 上完全不触发。调试几轮无果后，我选择用更简单的点击展开替代。当前阶段的 Vibe Coding，还是需要接受"够用就好"而不是"完美实现"。

提炼：一条核心方法

这次建站最核心的经验是：对需求的清晰表达是vibecoding的基础。

PRD 和 DESIGN 文档不只是给自己看的规划，它们是和 AI 沟通时的"需求文档"。当你有了清晰的信息架构，prompt 就不再是"给我一个好看的首页"，而是"在首页放三个项目卡片入口，卡片用圆角 12px、hover 时上浮 2px，视觉风格参考 DESIGN.md 中的极简黑白灰基调"。

后者更可能一次命中，而前者需要反复拉扯。

生活在这个时代很幸运的事，就算你只是有一个模糊的想法，也可以借助大语言模型的能力将这个想法清晰地表达出来。因此，如果你的需求起点也很模糊，不用担心，可以花一点时间，和AI一起打磨完善。

后续：这个系列会持续更新，记录我构建不同类型产品的过程——网站、小程序、Skill、Agent 原型。每篇都按照同样的结构：起点 → 构思 → 过程 → 成果 → 回顾 → 提炼。不只是展示成果，更是记录思考。