从想法到可运行 Demo

03课程课件#

04为什么产品经理要学 Vibe Coding#

欧哟老师先给了一个很直接的定义：Vibe Coding 就是用自然语言描述目标和想法，让 Agent 去写代码、调试、优化，并把应用做出来。人不再逐行写代码，但人仍然负责更重要的部分：定义需求、规划蓝图、审核结果。

这件事对产品经理的意义很大。传统流程里，一个产品想法通常要经历调研、PRD、原型、评审、设计、开发、联调、测试。一个稍微复杂的需求，从想清楚到做出来，往往以周为单位。但在 AI 原生团队里，一个产品经理如果同时具备产品判断、设计审美和基本工程理解，可能一上午就能跑出一个能验证方向的 demo。

1. AI 拉高了能力地板 过去不会代码就很难亲手验证想法；现在只要能讲清楚目标，就能让 Agent 帮你生成页面、脚本、工具甚至完整应用。
2. 市场比拼速度和判断 许多产品形态不再有很高的技术门槛。关键变成：谁更快看到真实问题，谁更快做出第一版，谁更快根据反馈迭代。
3. PM 要变成方块型人才 AI 会补齐短板。产品经理不一定每项都做到 100 分，但要在产品、设计、工程、宣发这些环节都至少能推进到 80 分。

今天的目标不是成为工程师，而是成为自己产品的产品经理：能把一个想法推到可体验、可展示、可验证。

05Agent 和普通 AI 对话有什么不同#

普通 AI 对话工具更像一次问答：你发一条消息，它回一条答案。Agent 则会把一个目标拆成多步行动：理解目标、搜索信息、读取文件、创建文件、修改代码、执行命令、检查结果，再决定下一步做什么。

选择 Agent 和模型时，欧哟老师给了一个实用标准：按任务复杂度和性价比选。复杂、模糊、需要长期推理的任务，优先能力强的模型；日常批处理、简单页面、格式转换，可以选成本更低的模型或工具。

06从 0 到 1 做个人网站的实操流程#

这节课的主线是用 Codex 做一个个人网站。它看起来只是一个网页，但完整跑通了 AI 产品经理最该练的工作方式：补上下文、让 Agent 反问、产出方案、做第一版、审美优化、补充信息、部署上线。

1. 创建项目，而不是只开聊天项目本质是一个文件夹。Agent 在里面读写文件、积累上下文、保存方案和产物。这样新话题也能通过项目文件理解之前做过什么。
2. 先让 AI 反问你不要一上来写很长的提示词。可以直接问：「我想做一个个人网站，你需要我的什么信息？」让 Agent 帮你把信息收集清楚。
3. 用 Plan 模式收敛方案Plan 模式会更像产品访谈：它通过几个问题收集目标、受众、语言、风格，再沉淀成一份方案。这份方案本质上就是一份轻量 PRD。
4. 给真实资料，而不是空想简历、GitHub、个人主页、作品链接、文章链接都可以成为上下文。Agent 可以基于这些资料去理解你，而不是凭空编。
5. 先生成 HTML 第一版HTML 适合做可视化结果。哪怕第一版不好看，也先把信息结构和页面跑出来，再进行下一轮优化。
6. 反复审美打磨Codex 默认 UI 可能比较粗糙。要指出具体问题，比如字太大、配图太丑、风格不统一，并让它参考已有 skill 或设计规范继续优化。
7. 部署上线单文件 HTML 可以拖到 Vercel 这类平台快速上线；如果要让更多人稳定访问，后续再配置自己的域名。

07HTML、Markdown 与 Skill：AI 协作的三个基本载体#

欧哟老师特别强调了两种中间产物：HTML 和 Markdown。理解这两种格式，会明显提升你和 Agent 协作的效率。

Skill 的核心思想是渐进式加载。不是把所有知识一次性塞进上下文，而是先让 Agent 看到「什么时候该用这个 skill」，命中场景后再读取详细规则。这样既省上下文，也能让 Agent 更稳定地复用一套做事方法。

1. 把好结果沉淀为规范 如果你调到一个满意的网页风格，就让 Agent 总结成 skill。下一次再做类似 HTML，就能稳定复现。
2. 让信息有来源 调研时要求 Agent 给出 source。现实来源越清楚，幻觉越少，也越方便你人工复核。
3. 上下文要少而准 上下文越长，Agent 找重点越难。无关问题放 side chat，主链路只保留会影响执行的信息。

08把信息补全：搜索、浏览器和子 Agent#

一个个人网站最难的不是写页面，而是把「你是谁」讲清楚。欧哟老师演示了几种补充信息的办法：

1. 公开网络搜索让 Agent 搜索 GitHub、博客、技术社区、B 站、少数派、掘金等公开页面，把可验证的信息补进网站。
2. 浏览器自动化对于小红书、公众号、视频平台这类搜索引擎不容易抓到的内容，可以用专门的浏览器自动化工具，让 Agent 像人一样打开页面、点击、截图、读取 DOM。
3. 多模态理解页面如果 DOM 文本不完整，Agent 可以截图，再用模型识别页面结构和内容。它不只是读文本，也能看界面。
4. 并行子 Agent 深度调研把调研任务拆给多个子 Agent：一个查平台身份，一个查内容主题，一个查技术项目。主 Agent 只接收总结，既省上下文，也提升并行效率。
5. side chat 处理支线问题HTML 和 Markdown 的区别、某个技术概念这种支线问题，放 side chat 问，不污染主任务上下文。

09UI 不好看怎么办#

课堂里有同学问：用 Codex 做 UI 设计时，前端界面容易乱、风格不统一，该怎么办？欧哟老师给了两个方向。

这背后有一个很重要的产品判断：设计能力很多时候来自模型的默认审美，也来自你给它的约束。如果你只说「做得好看」，它会输出很泛的 AI 味；如果你明确告诉它「克制、留白、字体层级、少用装饰、不要大面积渐变」，结果会稳定很多。

AI 能把执行成本降到很低，但 taste 不会自动出现。你要有判断力，知道什么叫好，才能把 Agent 带到好结果。

10从个人网站到真实 AI 产品：MultiCore 的案例#

第二位嘉宾超级峰分享了 MultiCore 的产品演进。它不是第一天就被规划成完整产品，而是从一个很具体的个人痛点长出来：本地 AI 伙伴和多个 Agent 越用越多，配置、调试、排查、定时任务、群组协作都变得很难管理。

MultiCore 的定位可以概括为一个桌面上的AI 炼丹炉：把 OpenClaw、Hermes 这类本地 AI 能力，以及技能、工具、知识库、定时任务、协作群组，都包装成普通人能看懂、能配置、能组合的可视化系统。

1. 先服务自己 产品起点不是宏大平台，而是「我已经管理不过来自己的 AI 员工了」。真实痛点先发生在自己身上，才更容易做深。
2. 把技术封装掉 用户不应该面对一堆文件夹、CLI、配置项。好的 AI 产品要把复杂留给自己，把简单给到用户。
3. 让结果所见即所得 AI 不是越玄越好。用户关心的是：这个伙伴是谁、会什么、在哪工作、什么时候汇报、出了问题怎么修。

超级峰把 MultiCore 的演进总结成「点、线、面」：

11今天真正要练的能力#

这节课信息密度很高，但对真正动手最关键的能力可以收敛成四件事：

1. 把模糊想法讲成任务不要只说「帮我做个网站」。说清楚目标、受众、资料来源、风格偏好、必须出现的信息和不想要的效果。
2. 让 Agent 帮你收集上下文不会一次性写完整提示词没关系。让它反问你、让它调研你、让它把方案先写出来。
3. 审核和修正第一版第一版只是起点。你要指出哪里不对、哪里不好看、哪里信息缺失、哪里表达不准确。
4. 把成果发布出来能打开的链接，比一段描述更有说服力。上线不是终点，而是获得反馈的入口。