feat(docs): integrate version2 curriculum and stage-3 updates

概要
- 将 version2 分支的课程结构重构、第三阶段章节新增、示例资源迁移、高级 RAG 文档与 Vercel 部署配置等整合为 main 上的一次汇总提交

内容导航与 README 调整
- 更新 README 的总体介绍文案，引入“第零阶段 + 第一到第三阶段”的完整学习路径描述
- 将原先的“三阶段实战路径”说明替换为新版分阶段描述，突出从小游戏到跨平台复杂应用的学习节奏
- 删除已过时的“第二次更新将在分支 version2 合并到主分支”的提示，改为直接以 main 为主线
- 统一 README 顶部标题和排版风格，保证中英文导航、徽章展示等视觉结构一致

课程结构与章节导航更新
- 调整 docs 目录下的学习阶段导航结构，使 README 中的导航表与各 stage 实际目录对齐
- 补全并创建 stage-3 相关章节入口文件，用于承载高级阶段的课程内容
- 新增或更新以下章节入口：
  - 高级核心技能：
    - docs/stage-3/core-skills/3.1-mcp-claudecode-skills/index.md
    - docs/stage-3/core-skills/3.2-long-running-tasks/index.md
  - 多平台开发：
    - docs/stage-3/cross-platform/3.3-wechat-miniprogram/index.md
    - docs/stage-3/cross-platform/3.4-wechat-miniprogram-backend/index.md
    - docs/stage-3/cross-platform/3.5-android-app/index.md
    - docs/stage-3/cross-platform/3.6-ios-app/index.md
  - 个人品牌：
    - docs/stage-3/personal-brand/3.7-personal-website-blog/index.md
- 保持 stage-0、stage-1、stage-2 既有章节结构不变的前提下，对导航表格进行排版和链接校正，使整体课程地图清晰、可点击

示例与图片资源重组
- 将原先位于 docs/examples/example1/images/ 下的微信小程序示例图片，整体迁移到 stage-3 的正式课程路径中：
  - 目标路径：docs/stage-3/3.3-how-to-build-a-wechat-miniprogram/example1/images/
- 通过 rename 方式保留 git 历史关系，避免图片资源被视为完全新增，从而方便后续追踪
- 为微信小程序示例新增 index 页面：
  - docs/stage-3/3.3-how-to-build-a-wechat-miniprogram/example1/index.md
- 使该示例在“高级三：多平台开发：如何构建微信小程序”章节中有清晰的入口，对应实际实战内容

高级 RAG 与 AI 进阶文档
- 新增一篇系统介绍 RAG 的高级文档：
  - docs/stage-3/ai-advanced/3.a1-rag-introduction/extra5-what-is-rag-and-how-does-it-work-and-future.md
- 覆盖内容包括：RAG 的基本概念、典型架构、工作流程以及未来演进方向，为第三阶段的复杂应用提供知识检索基础
- 配套引入多张插图，帮助读者从架构图和流程视角理解 RAG：
  - docs/stage-3/ai-advanced/3.a1-rag-introduction/images/image1.png ~ image15.png

部署与工程配置
- 新增 vercel.json 配置文件，为项目在 Vercel 上的部署提供基础配置
  - 明确文档构建产物的输出路径和静态站点托管方式
  - 为之后的一键部署和自动化预览打下基础

依赖与锁文件更新
- 调整 package.json 中与新版文档结构和部署相关的配置，保持脚本和依赖与当前课程形态同步
- 更新 package-lock.json，以反映最新的依赖树和版本锁定状态
- 保证在执行 npm install / npm run build 时，依赖环境与 version2 中的实际使用情况一致

兼容性与行为说明
- 该提交通过 npm run build 验证，确保在整合 version2 内容后，VitePress 构建过程正常完成
- main 分支上的历史被压缩为一条有语义的“第二次大更新”提交，详细的开发过程仍保留在 version2 分支，用于后续需要时回溯

docs/stage-1/1.2-building-prototype/index.md

@@ -0,0 +1,635 @@
+# 初级三：动手做出原型
+
+在本节中，我们会从零开始，借助 AI IDE 动手搭建一个可以实际运行的 Web 应用原型。你将学会如何把脑海中抽象的产品想法，逐步拆解并落地为具体的界面与代码，同时在遇到问题时，能够有条理地排查原因并解决错误。
+
+你能体会到从产品分析拆解，到多页面产品原型实现的完整闭环
+
+## 本章导读
+
+在这一节，你将把一个真实工作场景，完整走一遍“从业务梳理到可运行原型”的流程。我们会以**内容生产工作台（内容创作任务管理）**为示例业务，先用自然语言把需求说明白，再借助对话式 AI 和 AI IDE，从一个单页面应用做起，逐步扩展到多页面的 Web 应用原型，并对界面和交互做一轮“像那么回事”的打磨。
+
+和传统“先学完一堆技术再写代码”不同，本章刻意弱化技术细节，把重点放在：**你如何用业务语言跟 AI 合作，把一个内容相关的想法快速做成能跑的工具**。  
+这也为下一节“接入大语言模型（LLM）和文生图能力”做好铺垫——我们会在同一个工作台中，实现“AI 帮你写文案、起标题、生成配图”的能力。
+
+- 预计时间：约 **4–6 小时**，可分多次完成
+- 预期产出：
+  - 1 份围绕真实工作场景写出的“内容生产工作台”业务需求说明
+  - 1 个可运行的单页面业务原型（例如内容任务列表页）
+  - 1 个包含首页、任务列表页、设置页在内的多页面 Web 应用原型
+- Assignment：
+  - 以你自己的工作场景为蓝本，完整完成一次：业务梳理 → 单页原型 → 多页原型的闭环
+  - （可选）参考 vibe coding 社区项目，对你的原型做一轮界面和交互的体验升级，并思考下一节要如何接入“AI 写文案 / 生成配图”
+
+---
+
+# 初级三：动手做出原型
+
+随着 AI IDE 能力的增强，我们越来越不必纠结每一个技术细节，而是可以把注意力更多地放在业务梳理和产品逻辑上。本节的目标，是带你完成一次从业务需求出发、借助 AI IDE 快速搭建 Web 应用原型的完整过程。
+
+在这个过程中，你会亲手把一个在很多团队里都存在的高频场景——**内容生产工作台（内容创作任务管理）**，逐步拆解为可以落地的页面与交互逻辑。我们会从一个最简单的单页面开始，再扩展为多页面应用，最终得到一个“能用、好改、可扩展”的业务原型。
+
+当你学完本节，你不需要自己写很多代码，也能：
+
+- 把内容相关的真实业务需求，转成自然语言“规格说明”
+- 借助 AI IDE 快速搭建出可以运行的单页面和多页面原型
+- 在遇到报错时，按照固定步骤排查问题、与 AI 协作修复错误
+- 初步打磨界面与交互，让原型从“能跑起来”迈向“用着顺手”
+- 为下一节“AI 写文案、起标题、生成配图”打好应用基础
+
+---
+
+## 1. 写代码前确定需求
+
+### 1.1 选择一个经典业务场景：内容生产工作台
+
+在真实工作中，几乎所有团队都会遇到类似的需求：
+
+- 市场和运营要按节奏发公众号文章、短视频、小红书笔记、活动海报
+- 产品和设计要整理功能更新公告、版本说明、上线物料
+- 内部团队要发布通知、周报、知识文章等
+
+大家常见的痛点是：
+
+- 任务散落在微信、邮件、飞书文档、线下讨论中，很难统一管理
+- 每天不知道“今天到底要发哪些内容、哪些已经写好、哪些已经发布”
+- 同一个主题在不同渠道发布时，很难统一规划和复用素材
+
+因此，本节我们选取一个足够简单又非常常见的场景——**内容生产工作台**。你可以把它理解为一个轻量的“内容任务管理工具”：
+
+- 每一条内容任务，对应一篇要发的文章、一条要拍的视频、一个要做的海报
+- 任务上有几个最基本的信息：标题、投放渠道、状态（未开始 / 进行中 / 已发布）
+- 后续我们会在这个工作台上接入 LLM 和文生图，帮助你自动生成文案和配图。
+
+### 1.2 业务梳理：从模糊想法到清晰需求
+
+很多团队最初的想法可能只是：
+
+> 想做个简单的内容排期表，把要发的东西都记一下。
+
+从 AI 或工程师的角度，这仍然过于抽象。我们需要把问题拆解得更具体。可以用下面几组问题来梳理业务：
+
+1. 使用者是谁
+   - 是一个人（比如你自己），还是一个小团队（市场组、内容组）？
+   - 是否需要区分“自己负责的任务”和“整个团队的任务”？
+
+2. 需要记录哪些信息
+   - 最少必须有哪些字段（内容标题、投放渠道、计划发布时间、当前状态）
+   - 将来可能会增加哪些字段（目标受众、优先级、关联活动、负责人等）
+
+3. 每天/每周的典型操作流程
+   - 创建新的内容任务（例如下周要发的活动预热）
+   - 更新任务状态（从未开始到进行中，再到已发布）
+   - 按渠道或状态筛选任务，快速知道今天/本周要做什么
+
+4. 成功的结果是什么
+   - 例如：
+     - 每天打开工作台，一眼看到“今天还有哪些内容没写 / 没排期 / 没发布”
+     - 团队内部不再在各种聊天记录里反复确认“这条内容到底发了没”
+
+把这些问题的答案写下来，就是一份简单的“内容生产工作台业务说明”。这一步，你仍然只需要用自然语言描述工作流程和痛点即可。
+
+### 1.3 从业务到页面：画出最简页面草图
+
+梳理完业务之后，下一步是把它转化为“页面结构”。我们先从一个**单页面版本**开始，保持尽量简单：
+
+- 顶部：标题，例如“内容生产工作台”
+- 中间左侧：新增内容任务表单
+  - 内容标题输入框
+  - 渠道下拉选择（例如 公众号 / 抖音 / 小红书 / B 站 / 内部通知）
+  - 状态下拉框（默认“未开始”）
+  - 计划发布时间（可选）
+  - “添加任务”按钮
+- 中间右侧：内容任务列表
+  - 每行显示：标题、渠道、状态、计划时间
+  - 每行右侧预留两个按钮：修改状态、删除
+- 列表上方：简单统计区域
+  - 显示任务总数
+  - 显示未开始 / 进行中 / 已发布的数量
+
+在纸上画出这些区域的方框和大致布局，哪怕只是草图，也能帮助你更清楚地跟 AI 表达“我要的页面长什么样”。
+
+### 1.4 用自然语言写“需求说明”给 AI IDE
+
+接下来，我们把上面的想法整理成一段可以直接发给 AI IDE 的自然语言需求。例如：
+
+> 我要做一个和内容创作相关的小工具，用来管理我的内容任务，是一个内容生产工作台。  
+> 请帮我先做一个单页面的 Web 应用，页面结构如下：
+>
+> 1. 顶部显示标题：内容生产工作台
+> 2. 左侧是新增内容任务表单，包含：内容标题、投放渠道、当前状态（默认为未开始）、计划发布时间 四个字段，以及一个“添加任务”按钮
+> 3. 右侧是任务列表区域，用表格展示所有任务，每行至少要显示：内容标题、投放渠道、当前状态、计划时间
+> 4. 每条任务右边预留两个按钮：修改状态、删除
+> 5. 在任务列表上方增加一个统计区域：显示任务总数、未开始任务数量、进行中任务数量、已发布任务数量  
+>    要求是：当我在左侧输入信息并点击“添加任务”后，右侧列表能立即出现一条新记录，同时统计区域自动更新。
+
+这就是 AI IDE 理解和生成代码所需要的信息。你做的，是产品经理平时写的那种“页面与交互说明”，只是换成自然语言和 AI 对话。
+
+### 1.5 本次原型做到哪里？不做到哪里？
+
+“内容生产工作台”可以发展出非常多功能，但**本章不会试图一次性做完所有事**。先明确：
+
+**本次原型“要做”的两件核心事情：**
+
+1. 快速录入和查看内容任务：让所有要做的内容任务不再散落在各种文档和聊天中
+2. 一眼看清当前任务的状态分布：未开始 / 进行中 / 已发布 有多少
+
+**本次原型“暂时不做”的事情：**
+
+- 多人协作、权限管理（某些任务只给特定同学看）
+- 复杂的排期视图（横跨多周的日历视图、拖拽排期等）
+- 复杂报表和图表分析（按渠道统计发布量、转化效果等）
+- 和其他平台的自动集成（自动同步到公众号、短视频平台等）
+
+这些内容会在后续章节（尤其是接入 LLM、文生图、甚至外部 API 之后）再逐步展开。  
+现在你只需要专注：**先让“记录任务 + 看状态”这个最小闭环跑起来**。
+
+### 1.6 实践任务：写出你自己的业务说明
+
+如果内容工作台本身就与你的工作高度相关，可以直接以它为主线。  
+如果你有更贴切的内容场景，例如：
+
+- 只做短视频脚本管理
+- 只管理内部知识文章/技术博客
+- 只管理版本发布公告和更新日志
+
+也可以换成你自己的内容对象，但可以沿用同样的结构：
+
+1. 说明你管理的“内容任务”是什么（文章、视频、公告）
+2. 说明最小需要记录哪些字段（标题、渠道、状态、发布时间等）
+3. 描述每天/每周是怎么使用这个工具的
+4. 列出“本次原型只解决哪两三件事”，暂时不解决哪些高级问题
+
+把这些写成一段话，就是你可以直接复制给 AI IDE 的“需求说明”。
+
+---
+
+## 2. 从一个单页面开始
+
+完成业务梳理后，我们先从最小可用版本开始：**单页面内容生产工作台**。这一节的重点，是让你真正体验到：通过自然语言和 AI 协作，可以在很短时间内得到一个“能跑起来”的内容管理工具。
+
+### 2.1 在 AI IDE 中创建项目
+
+1. 打开 AI IDE，新建一个空项目（可以命名为 content-workbench-demo 或更贴合你业务的名字）
+2. 在项目中创建一个基础 Web 应用，如果不确定，可以直接在聊天框问 AI：
+
+   请帮我创建一个可以在浏览器里访问的简单 Web 项目，用来做内容生产工作台的演示。
+
+AI 会自动为你搭好最基础的文件结构，例如首页文件、样式文件和必要的脚本文件。
+
+### 2.2 用自然语言让 AI 搭出首个单页面
+
+在 AI 聊天框中粘贴你在 1.4 写好的“需求说明”，并补一句：
+
+> 接下来，请在当前项目中根据上面的描述，帮我实现一个单页面的内容生产工作台原型。
+
+AI 会为你生成或修改前端代码，完成：
+
+- 页面基本布局（标题、左右区域、统计区）
+- 新增内容任务的表单
+- 展示任务的列表
+
+在 AI 的引导下打开浏览器预览页面，尝试一次完整操作：
+
+1. 在左侧表单中输入一条内容任务（例如“618 大促预热海报”）
+2. 选择渠道（例如“公众号”），状态保持“未开始”
+3. 设置一个计划发布时间，点击“添加任务”
+4. 在右侧列表中确认看到这条任务
+5. 查看顶部统计区是否同步更新任务数量
+
+### 2.3 功能分级：必须 / 建议 / 进阶
+
+为了让你更有“范围感”，我们对单页面要实现的能力做一个分级：
+
+**必须完成（MVP）：**
+
+1. 新增内容任务
+   - 表单至少包含：内容标题、投放渠道
+   - 点击“添加任务”，能在列表中看到新记录
+
+2. 基础列表展示
+   - 能在页面上看到所有已添加的任务
+   - 每一条有基本可辨识信息（至少标题）
+
+3. 删除任务
+   - 对某条任务可以执行删除操作，删除后不再出现在列表里
+
+**建议完成（推荐）：**
+
+4. 状态字段 + 简单统计
+   - 表单中增加状态字段（未开始 / 进行中 / 已发布）
+   - 列表上方显示：总任务数、未开始数量、进行中数量、已发布数量，并随新增/删除自动更新
+
+5. 计划发布时间字段
+   - 表单增加计划发布时间（日期或日期+时间）
+   - 列表中展示这个字段，方便后续按日期排序或筛选
+
+**进阶挑战（可选）：**
+
+6. 状态筛选
+   - 在任务列表上方增加状态筛选下拉框，可只看“未开始/进行中/已发布”
+
+7. 快速状态切换
+   - 每条任务右侧有一个“标记为已发布”的按钮，点击即可更新状态并刷新统计
+
+8. 最近更新时间
+   - 在列表中增加“最近更新”字段，每次修改状态或标题时自动更新为当前时间
+
+建议你先完成“必须 + 建议”部分，保证闭环存在，再尝试进阶功能。
+
+### 2.4 验证你的“单页面闭环”
+
+当单页面基本成型时，可以用一个完整的小闭环来验收它：
+
+1. 新建 3 条内容任务：
+   - 公众号文章：状态“未开始”
+   - 短视频脚本：状态“进行中”
+   - 活动总结文章：状态“未开始”
+2. （如果你做了筛选）使用筛选功能，只看“未开始”的任务，检查列表是否正确
+3. 把其中一条标记为“已发布”，观察统计区是否更新
+4. 删除一条已经不需要的任务，再次确认统计和列表是否一致
+
+如果这一轮流程走下来没有明显障碍，你的单页面原型就已经达到“可用”的标准了。
+
+### 2.5 实践任务：完成一个可用的单页面内容工作台
+
+本小节的实践目标，是让你得到一个真正可以用来管理内容任务的单页面应用。请你保证页面至少具备以下特性：
+
+- 完成“必须”和“建议”级别的功能
+- 至少实现一个“进阶挑战”（如状态筛选或快速状态切换）
+- 可以支持你用真实的几条内容任务试着用上一两天
+
+你可以在心里问自己两个问题：
+
+- 如果这个页面明天就要给同事用，他们还会问你哪些问题？
+- 把“内容任务”换成“项目任务”或“需求事项”，是否只需要换字段名即可复用？
+
+---
+
+## 3. 遇到报错了怎么办
+
+当你开始频繁修改和扩展页面时，报错就成了日常。与其试图一口气搞懂所有技术细节，不如先建立一套“遇到报错的标准动作”。
+
+### 3.1 常见报错形态
+
+在搭建内容生产工作台的过程中，你可能会遇到几类典型错误：
+
+1. 页面完全空白
+   - 打开浏览器，什么都不显示，或者只显示标题
+   - 常见原因：代码语法错误、某个关键文件加载失败
+
+2. 页面部分功能失效
+   - 表单能看到，但点击“添加任务”没反应
+   - 常见原因：按钮事件没有正确绑定，或者某处变量名写错
+
+3. 控制台出现红色报错信息
+   - 打开浏览器开发者工具（F12），在 Console 中看到一堆英文
+   - 常见原因：访问了不存在的属性或方法，引用了不存在的文件等
+
+4. 样式错乱
+   - 按钮位置跑偏、列表显示变形、文字对不齐
+   - 常见原因：样式文件修改冲突、类名被误删等
+
+### 3.2 报错处理四步法
+
+无论遇到哪一种现象，你都可以按照下面四个步骤来处理：
+
+1. 复述问题
+   - 用一两句话客观描述现象，而不是只说“坏了”：
+     - 页面完全空白
+     - 添加任务时没有任何反应
+     - 点击删除按钮时出现一条红色错误提示
+     - 筛选下拉框变了，列表不变
+
+2. 收集信息
+   - 打开浏览器开发者工具
+   - 在 Console 中找到最新的红色报错信息
+   - 把完整报错内容复制出来（尽量一行不落）
+
+3. 提交给 AI
+   - 在 AI IDE 的聊天框中，先用自己的话描述现象，再粘贴报错信息，例如：
+
+     我在做一个内容生产工作台，现在遇到如下问题：
+     - 现象：点击“添加任务”按钮没有任何反应
+     - 操作步骤：在表单里填写标题和渠道后点击按钮  
+       下面是浏览器控制台中的完整错误信息：  
+       ……（粘贴错误）  
+       请帮我分析可能的原因，指出需要修改的文件和代码位置，并给出修改后的示例。
+
+4. 跟着 AI 一步步修改
+   - AI 通常会告诉你在哪个文件、哪一段代码里需要调整
+   - 先照着修改一次，如果看不懂，也可以要求 AI 用更通俗的描述解释原因
+   - 修改保存后，刷新页面再次测试
+
+通过多次这样的循环，你会逐渐对“错误长什么样”“通常卡在哪些地方”形成直觉。即使你暂时不懂技术名词，也可以有效推进问题解决。
+
+### 3.3 实践任务：刻意“制造一个错误”
+
+为了真正掌握报错处理的节奏，你可以刻意“制造一个小错误”，然后用上面的四步法来解决。例如：
+
+1. 找到新增任务的那段代码，把某个变量名刻意改错（例如 taskList 改成 tasksList）
+2. 保存并刷新页面，尝试添加任务，观察页面行为
+3. 打开控制台查看报错信息
+4. 当作一个真实问题提交给 AI，让它帮你分析并修复
+
+通过这样“可控的练习”，你会对错误的来源和定位方式更加熟悉，遇到真实问题时就不会慌张。
+
+---
+
+## 4. 做多个页面的应用
+
+当单页面已经能稳定记录和展示内容任务后，你会发现：业务本身其实可以拆成几个逻辑板块。例如：
+
+- 某个页面专门用来“看整体情况”（当前任务数量、不同状态占比）
+- 某个页面专门用来“管理具体任务列表”
+- 某个页面专门用来“配置个人偏好、默认渠道、默认状态”等
+
+这就是从单页面走向多页面的自然契机。
+
+### 4.1 为什么不是一个“超长页面”？
+
+从技术上讲，我们可以把所有内容堆在一个很长的页面上：上面是统计，中间是列表，下面是设置。但随着功能逐渐增多，这样做会出现几个问题：
+
+- 新用户很难在第一次打开时搞清楚“这里能做什么”
+- 常用操作（添加任务、查看进度）和不常用操作（调整个人偏好）混在一起，容易误操作
+- 页面越堆越长，后续想增加新模块（例如任务详情、AI 生成文案页面）时，会越来越难维护
+
+因此，我们按照“使用频率”和“信息类型”把它拆成多个页面：
+
+- 高频、概览性的内容放在首页
+- 日常操作性内容放在任务列表页
+- 低频、配置性的内容放在设置页
+
+这就是最基础的信息架构思路。
+
+### 4.2 设计一个最小多页面结构
+
+以内容生产工作台为例，可以先规划一个三页结构：
+
+1. 首页（内容概览）
+   - 展示关键数据：任务总数、未开始数量、进行中数量、已发布数量
+   - 显示当前使用者名称，例如“欢迎你，内容运营小王”
+   - 提供快速入口：去任务列表、去设置页
+   - （为下一节埋点）预留一个区域，用来展示“AI 已为你生成了多少条文案/图片”（暂为空）
+
+2. 任务列表页
+   - 展示所有内容任务的列表
+   - 支持根据状态筛选
+   - 预留“查看详情”入口，未来我们会在详情页里接入 LLM/文生图
+
+3. 设置页
+   - 可以修改当前使用者名称（例如“小王”“品牌内容组”）
+   - 可以配置一个“默认渠道”（例如默认选中公众号）
+   - 可以配置一个“默认显示状态”（例如默认只显示进行中任务）
+   - 设置保存后，在其他页面中生效
+
+在纸上画一张简单的“页面导航图”，用箭头标出：  
+首页 ↔ 任务列表页 ↔（未来的）任务详情页  
+首页 ↔ 设置页
+
+这张图，就是接下来 AI 帮你搭建多页面结构的“蓝图”。
+
+### 4.3 向 AI IDE 请求：从单页扩展为多页
+
+在 AI IDE 聊天框中，你可以这样发出指令：
+
+> 现在我希望在现有单页应用的基础上，改造成一个包含多个页面的内容生产工作台。  
+> 请帮我实现三种页面：
+>
+> 1. 首页：展示内容任务的整体统计数据（总数、未开始、进行中、已发布），并显示当前使用者名称，例如“欢迎你，内容运营小王”，同时提供“查看任务列表”和“打开设置页”的按钮。
+> 2. 任务列表页：展示所有任务，提供按状态筛选的功能。点击某条任务时，后续可以扩展为跳转到“任务详情页”。
+> 3. 设置页：可以修改当前使用者名称，并配置“默认渠道”和“默认显示状态”；保存后，在首页和任务列表页中生效。  
+>    请帮我配置好页面路由和跳转逻辑，使我可以在浏览器中通过菜单或按钮在这些页面之间切换。
+
+AI 会在项目中增加必要的路由配置，并为你创建或拆分对应的页面文件。
+
+### 4.4 跨页面的数据传递
+
+多页面应用中，一个核心能力是“不同页面之间共享信息”。在我们的内容工作台场景里，典型的例子包括：
+
+- 设置页中修改当前使用者名称后，首页欢迎语也要同步更新
+- 设置页中配置的“默认渠道”和“默认显示状态”，要影响任务列表页的默认筛选
+- 未来在任务详情页中更新某条任务的状态或文案摘要，回到任务列表页和首页概览时，相关统计也要更新
+
+你暂时不需要理解所有技术实现细节，可以先只关注“现象”是否正确发生：
+
+1. 在设置页修改名称，例如改成“内容运营小李”
+2. 返回首页，看顶部欢迎语是否同步成“欢迎你，内容运营小李”
+3. 在设置页修改“默认显示状态”为“进行中”
+4. 返回任务列表页，看列表是否自动按照“进行中”进行过滤
+5. 在列表页手动修改一条任务状态为“已发布”，返回首页，看“已发布任务数量”是否自动加一
+
+如果这些行为都符合预期，就说明你的多页面数据流已经“连通”了。
+
+### 4.5 功能分级：多页面的必须 / 建议 / 进阶
+
+和单页面类似，我们也对多页面部分做一个分级：
+
+**必须完成：**
+
+1. 三个页面结构本身：首页 / 任务列表页 / 设置页
+2. 可以通过明显的导航或按钮在三个页面之间跳转
+3. 设置页修改使用者名称后，首页欢迎语能实时更新
+
+**建议完成：**
+
+4. 首页展示关键统计数据（总任务数、未开始数、进行中数、已发布数）
+5. 任务列表页具备状态筛选功能
+6. 设置页中的“默认显示状态”能影响列表页的默认筛选效果
+
+**进阶挑战（可选）：**
+
+7. 预留“任务详情页”空壳：
+   - 列表每条记录后有“查看详情”按钮
+   - 点击后跳转到详情页，显示该任务的基础信息（标题、渠道、状态、计划时间、备注）
+
+8. 在详情页中支持修改状态或备注，并能同步回列表页和首页统计
+
+你可以根据自己的时间和精力，选择做到“必须 + 建议”或者再挑战“进阶”。
+
+### 4.6 实践任务：完成一个三页面内容工作台原型
+
+在本小节结束前，请确保你的应用至少满足以下条件：
+
+- 完成“必须”和“建议”级别的功能
+- 页面导航清晰、跳转路径不绕圈
+- 你可以实际用它来浏览和更新真实的几条内容任务
+- 为下一节“在详情页里接入 AI 写文案 / 生成配图”留有一个明显的“任务详情页”入口（哪怕暂时内容很少）
+
+---
+
+## 5. 把原型做得像那么回事
+
+当功能和结构基本成型后，下一步就是“打磨质感”。这一节我们从界面、交互和参考项目三个角度，帮你把原型从“勉强能用”拉到“看上去靠谱，用起来顺手”。
+
+### 5.1 界面结构：从“拼凑”走向“有秩序”
+
+先从最直观的地方入手：页面布局是否清晰、有层次。对于内容生产工作台，可以按下面几个原则逐步调整：
+
+1. 页面分区清楚
+   - 每个页面都应该有一个清晰的标题，例如：内容概览、内容任务列表、系统设置
+   - 主要操作区域（表单、筛选条件、保存按钮）与背景有明显区分
+
+2. 信息有主次
+   - 在首页中，整体统计数字（总任务、未开始、进行中、已发布）应放在页面上部或中央，引导用户视线
+   - 列表和详细任务信息安排在其下方
+   - 辅助信息（提示文案、版本号）可以放在页脚
+
+3. 风格基本统一
+   - 按钮样式统一：形状、颜色、圆角、文字风格保持一致
+   - 标题层级统一：一级标题、二级标题的字号和粗细有规律
+   - 颜色数量适度，避免页面到处是不同的颜色和字体
+
+你可以对 AI 这样提出需求：
+
+> 请根据当前这个内容生产工作台的结构，帮我优化整体布局和样式。  
+> 要求：
+>
+> 1. 每个页面的主标题更醒目，和正文区有明显区分
+> 2. 主要操作按钮的位置更明显，与次要按钮在颜色和样式上有区分
+> 3. 统一所有按钮和表单控件的样式与配色
+> 4. 适当增加留白和分割线，让统计区、表单区、列表区的边界更清晰。
+
+### 5.2 交互体验：让操作自然顺手
+
+一个“像那么回事”的原型，不仅要能点，还要让用户知道自己点了什么、接下来该做什么。以内容生产工作台为例，可以重点检查以下几个场景：
+
+1. 关键操作的反馈是否明确
+   - 添加新任务成功后，是否有明显反馈，例如：
+     - 在页面上方显示一条“添加成功”的绿色提示，几秒后自动消失
+     - 表单自动清空
+     - 新任务出现在列表顶部
+   - 删除任务时，是否有简单的确认对话框，避免误删
+
+2. 流程是否顺手
+   - 在列表页中修改状态后，是否可以即时更新当前行，而不用刷新整个页面
+   - 从列表跳转到详情页、再返回列表，是否保持原有筛选条件和滚动位置
+
+3. 错误提示是否友好
+   - 如果用户尝试添加一条“标题为空”的任务，系统如何提醒
+   - 提示文字是否用日常语言解释问题，例如：
+     - 内容标题不能为空，请先填写标题，再点击添加
+
+你可以让 AI 具体帮你实现这些改动，例如：
+
+> 请为新增任务、删除任务和修改状态这三个操作加上明显的用户反馈。  
+> 要求：
+>
+> - 添加成功时，在页面上方显示一条绿色提示，并将新任务插入到列表最上方
+> - 删除前弹出确认对话框，文案为“确定要删除这条内容任务吗”
+> - 修改状态后，在该行右侧短暂显示“状态已更新”，同时刷新首页统计数字。
+
+### 5.3 三个“土办法”自测你的体验是否及格
+
+在没有设计师和正式用户测试的前提下，你可以用几个简单的方法，自己评估原型是否“像那么回事”：
+
+1. 10 秒规则
+   - 找一个没参与过项目的人，让 TA 打开首页
+   - 不给任何说明，看 TA 能否在 10 秒内说出：
+     - 这个页面大概是干什么的
+     - 这里最主要的一两个操作是什么
+
+2. 三次点击规则
+   - 从首页出发，数一数一个典型任务需要几步：
+     - 例如“新增一条内容任务并确认它出现在列表中”，是否可以在三次点击内完成
+   - 如果步骤太多，可以考虑简化流程、减少中间页面或按钮
+
+3. 无说明书测试
+   - 不给任何使用说明，看对方是否能自主找到“添加任务、筛选状态、删除任务”这三类基础功能
+   - 观察 TA 卡住的地方，往往就是你需要补提示、改布局的位置
+
+你不需要做到完美，但至少要做到：**三次测试中，大多数人都能在不依赖你口头指导的前提下，完成一到两个典型任务**。
+
+### 5.4 参考项目：来自 vibe coding 社区的案例
+
+在 vibe coding 社区中，已经有不少同学用类似方式，搭建了与内容和知识相关的小工具。这里简要分享两类典型项目，帮助你建立“原型完成度”的直觉。
+
+#### 案例一：多渠道内容排期板
+
+业务背景：  
+一个中小团队的市场负责人，需要统筹管理公众号、小红书、抖音、视频号等多个渠道的内容排期。
+
+核心特征：
+
+1. 多页面结构清晰
+   - 首页：展示不同渠道的内容任务数量、发布节奏概览
+   - 任务列表页：按渠道和状态查看所有任务
+   - 设置页：配置渠道列表、内容模版等
+
+2. 和业务高度贴合
+   - 每个任务绑定到特定渠道，可以看到每个渠道的计划和发布完成情况
+   - 首页提供简单的“本周内容日历视图”，帮助团队提前规划产能
+
+3. 界面简洁但不简陋
+   - 使用统一的配色、按钮样式和标题层级
+   - 在每个任务旁边预留 “用 AI 生成文案” 的入口（与下一节内容自然衔接）
+
+#### 案例二：内部知识文章工作台
+
+业务背景：  
+一个技术团队希望把分散在个人文档里的技术分享、踩坑记录收拢到一个统一的知识库中。
+
+核心特征：
+
+1. 单页面起步，多页面演化
+   - 初始版本只是一个表单加列表页面，用于录入和浏览文章记录
+   - 很快扩展出“文章详情页”“标签管理页”“导出页”等，让知识更容易被整理和复用
+
+2. 巧妙利用 AI 能力（后续章节会讲）
+   - 在录入文章后，可以一键调用 AI 对内容做初步摘要，生成“阅读前要点”
+   - AI 可以根据文章内容自动建议标签、相关主题
+
+3. 界面与交互足够顺手
+   - 支持按标签筛选文章
+   - 支持简单的排序和搜索
+   - 关键操作都有明确提示
+
+这些真实项目有一个共同点：  
+**一开始都非常简单，只解决一个具体的小问题，然后在使用过程中不断补足“应该有的那一点点”**。  
+本节带你完成的内容生产工作台原型，其实就是走在同一条路径上。
+
+### 5.5 实践任务：为你的原型做一次“体验升级”
+
+请针对你当前的内容工作台原型，完成下面三件事：
+
+1. 写下一条你认为最重要的使用场景
+   - 例如：每天早上 10 分钟内，快速确认今天必须完成的内容任务列表
+   - 或者：为某个主题活动统一规划多渠道的内容任务
+
+2. 从“界面结构”和“交互反馈”两个角度，各列出 2–3 个可以改进的点
+   - 界面结构：是否需要调整布局、字号、按钮位置；是否有信息过于拥挤或过于空白
+   - 交互反馈：是否缺少成功/失败提示；某些操作是否流程太绕、步骤过多
+
+3. 将这些改进点整理成自然语言，让 AI IDE 帮你一次性或分步执行
+   - 改完后，邀请同事或朋友试玩 5–10 分钟，让他们用你的工具完成第 1 步里的使用场景
+   - 根据他们的反馈，再补一轮小改动
+
+完成这一轮，你的原型就不再只是“你自己知道怎么用的小玩具”，而是具备一定使用体验、可以逐步推广的业务工具。
+
+---
+
+## 总结
+
+通过本节的学习，你已经经历了一次从业务梳理到多页面原型搭建与打磨的完整闭环，核心包括：
+
+- 从真实内容场景出发（以内容生产工作台为例），学会用自然语言梳理业务需求
+- 把业务流程映射为页面结构，用清晰描述驱动 AI IDE 搭建单页面应用
+- 在此基础上扩展出包含首页、任务列表页、设置页在内的多页面应用，并实现数据在页面间的简单传递
+- 建立遇到报错时的“标准动作”，通过现象描述、控制台信息和 AI 协作完成排查
+- 从界面布局和交互反馈两个维度，对原型做初步体验升级，并参照 vibe coding 社区中的实际项目，形成对“像那么回事”的共同标准
+
+更重要的是，你已经体验了一次**AI 原生开发**和传统开发的关键差异：
+
+- 传统模式：先深入学习技术栈，再自己写代码实现业务
+- 本章模式：先把内容业务讲清楚，再让 AI 负责大部分实现细节，你更多在扮演“产品和架构的决策者”
+
+当你能反复完成这样的闭环，你就已经具备了“用 AI 把内容相关的业务想法快速做成可用原型”的关键能力。
+
+## 下一步
+
+在下一节中，我们将在这个内容生产工作台的基础上，接入具体的 AI 能力，例如：
+
+- 为某条内容任务自动生成文案初稿和多个标题备选
+- 根据任务描述自动生成配图草稿（文生图）
+- 对历史内容任务做自动归类和摘要，帮助你规划下一个活动的选题
+
+届时，你搭建的将不再只是一个“任务列表”，而是一个真正具备智能创作辅助能力的 AI 内容工作台。